AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.08.2009, 15:41   #1  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?
***** выделено отсюда Посоветуйте по чистке CustInvoiceTrans *****

Почитал описание
http://technet.microsoft.com/en-us/l...3(SQL.90).aspx
Описан реальный пример при работе с олап кубами в САП
Цитата:
Production Workload SAP BI

SAP BI is the primary workload targeted by vardecimal storage format. To measure the impact on an SQL BI application, we worked with one of our SAP BI customers in Germany to test the impact of vardecimal storage format both in terms of space savings and the impact on the performance of the real-life workload. This customer was very interested in the new storage format to reduce the size of fact tables within SAP BI info cubes that often included a large number of decimal columns. The customer was able to reduce the size of their fact tables up to 80% in some cases without any noticeable impact on the performance of their workload in spite of the extra CPU cycles required to convert decimal data between fixed-length format and vardecimal storage format. This was because the customer's workload was running complex queries involving many joins, aggregates, and other expensive relational operators. These constituted the significant portion of the cost of the query as compared to the cost of scan operators, which pay the additional cost of conversion from vardecimal storage format to fixed-length format. Another way to look at this is that if the 95% CPU cost of your query is in executing relational operators other than scan, even if the CPU cost of scanning goes up by 40%, it is still 2% (that is, 40% of the 5% query cost) of the overall query cost. Here is a summary of the results:

* For the majority of the fact tables, the disk space savings was between 20 and 50%.
* As expected, the space savings were dependent on the table schema (the relative number of decimal and numeric columns), the size of the table, and the data distribution. Thus, for one table that had just one decimal column out of nine total columns, the saving was only 4.76%. Another table, which had 94 decimal columns out of 109 total columns, became 80% smaller in size.
* There were no space savings for indexes because the indexes defined on the SAP BI fact tables did not have any decimal or numeric key columns
* As mentioned earlier, there was no noticeable impact on the query or load performance with vardecimal storage format.
Если я правильно понял данное описание - объем таблиц фактов удалось значительно уменьшить (до 80 % освобожденного места на диске), а производительность при этом не поменялась. (Если неверно перевел - поправьте меня) - я немного разочарован - ожидал что производительность улучшится за счет сокращения объема операций ввода вывода - видимо затраты на распаковку компенсировали выигрыш от сжатия (авторы утверждают что запросы сами по себе были сложные так что время на сканирование таблиц сильно не влияло на скорость выполнения запросов - в общем, по сути, ушли от обсуждения вопроса).

Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?

Если применять к Аксапте, то для каких таблиц ?
Редко обновляемые большие таблицы (строки журналов, заказов, закупок) ?
Часто обновляемые большие таблицы с большим количеством числовых полей (InventSum)?

Аналогичные фичи для оракла кто-нибудь использовал ?
Старый 15.08.2009, 22:53   #2  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Logger Посмотреть сообщение
я немного разочарован - ожидал что производительность улучшится за счет сокращения объема операций ввода вывода
Vardecimal storage стоит рассматривать прежде всего как средство уменьшить использование дискового пространства при минимальных накладных расходах. Влияние на производительность стоит рассматривать скорее как побочный эффект, тем более что для разных систем оно будет разным. Да, IO теоретически может улучшиться, однако нагрузка на процессор увеличится хоть и незначительно, но гарантированно. Конечный результат будет зависеть от того, что в данный момент является узким местом системы.
Цитата:
Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?
Применять можно везде, так как накладные расходы невелики. В случае OLTP просто нужно учитывать некоторые моменты
Цитата:
Если применять к Аксапте, то для каких таблиц ?
Редко обновляемые большие таблицы (строки журналов, заказов, закупок) ?
Часто обновляемые большие таблицы с большим количеством числовых полей (InventSum)?
Ну, журналы я скорее предпочту чистить, нежели сжимать. Знаю, что выглядит немного радикально Знаю, что не всегда возможно (например, локализованные отчеты построенные на складских журналах)
INVENTSUM - скорее всего нет. Даже при использовании партий, палет и серийных номеров размер таблицы недостаточно велик, чтобы при включении VARDECIMAL получить хоть какую-то значимую экономию дискового пространства. Кроме того, при высокой частоте обновления (UPDATE) повышается вероятность того, что ранее "сжатая" запись должна "разжаться" (новое значение требует большей размерности по сравнению со старым) и на странице не свободного места, что ведет либо к расщеплению страницы, либо к появлению forwarded record (все это описано в whitepaper по ссылке, которую я привел)
INVENTTRANS, INVENTSETTLEMENT, LEDGERTRANS - тут выигрыш в занимаемом таблицей пространстве имеет место быть, какого-либо заметного влияния на производительность не ощутил (да и не ставил такой цели, если честно)
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: mazzy (5), Logger (8).
Старый 16.08.2009, 08:55   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Т.е. ты рекомендуешь скорее trans-таблицы.

1.
А стоит ли LedgerBalances*-таблицы?
Обычно они и большие, и содержат числовые данные, и в них много необновляемых чисел за старые периоды...

2.
Насколько стоит геморроится сегментированием таких таблиц, чтобы задать разные режимы сжатия для разных сегментов?
__________________
полезное на axForum, github, vk, coub.
Старый 17.08.2009, 04:05   #4  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от mazzy Посмотреть сообщение
Т.е. ты рекомендуешь скорее trans-таблицы
Перефразирую - большие таблицы
Цитата:
А стоит ли LedgerBalances*-таблицы?
Обычно они и большие, и содержат числовые данные, и в них много необновляемых чисел за старые периоды...
Я пока не встречался с ситуацией, когда остатки по GL представляли собой сколько-нибудь существенную долю от общего объема БД. Сжать - можно (за компанию с транзакционными таблицами), сожмется хорошо (в процентном отношении)
Цитата:
Насколько стоит геморроится сегментированием таких таблиц, чтобы задать разные режимы сжатия для разных сегментов?
Это уже не VARDECIMAL, а DATA_COMPRESSION и соответственно следующая версия СУБД - SQL Server 2008. Стоит ли геморроиться - это уже решать DBA в каждом конкретном случае
__________________
-ТСЯ или -ТЬСЯ ?
Старый 17.08.2009, 12:22   #5  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от mazzy Посмотреть сообщение
Т.е. ты рекомендуешь скорее trans-таблицы...
Цитата:
Сообщение от Vadik Посмотреть сообщение
Перефразирую - большие таблицы ..
Добавлю мое ИМХО - и еще из которых МНОГО читается. Много не в смысле часто, а много в смысле много записей.
Например у нас INVENTSETTLEMENT у нас ~50млн. Но читается из него по объему не много и в большинстве случаев по индексу - т.е. проблем не доставляет и в top запросов не фигурирует.
А вот SYSDATABASELOG подумываю сжать, ибо как что найти нужно, так IO начинает расти здорово! Ибо интексов ненастроешься на нее!
Старый 17.08.2009, 13:05   #6  
AX2009
Гость
 
n/a
palleagermark: Intelligent Data Management Framework For Microsoft Dynamics AX (Pre-Release)

Вот эту штуку кто-нибудь попробовал?
Старый 17.08.2009, 20:44   #7  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Logger Посмотреть сообщение
где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?
Как под заказ, Storage engine team выпустили вчера статью
Update on Data Compression as available in SQL Server 2008 RTM and links to white papers
__________________
-ТСЯ или -ТЬСЯ ?
Теги
sql 2005, sql 2008, как правильно, полезное, производительность, сжатие

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Как использовать OLAP для Oracle Beast-L DAX: Программирование 5 03.10.2007 16:06
Опять вопрос про OLAP? Hidden DAX: Функционал 2 30.05.2006 16:19
Где взять материалы и еще один конкретный вопрос Andronov DAX: Программирование 6 19.02.2003 10:48
Введение в Аксапту Роман Кошелев DAX: Прочие вопросы 0 18.12.2001 14:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:20.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.