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

[Logger]

***** выделено отсюда Посоветуйте по чистке 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)?

Аналогичные фичи для оракла кто-нибудь использовал ?

[Vadik]

Цитата:

Сообщение от Logger

я немного разочарован - ожидал что производительность улучшится за счет сокращения объема операций ввода вывода

Vardecimal storage стоит рассматривать прежде всего как средство уменьшить использование дискового пространства при минимальных накладных расходах. Влияние на производительность стоит рассматривать скорее как побочный эффект, тем более что для разных систем оно будет разным. Да, IO теоретически может улучшиться, однако нагрузка на процессор увеличится хоть и незначительно, но гарантированно. Конечный результат будет зависеть от того, что в данный момент является узким местом системы.

Цитата:

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

Применять можно везде, так как накладные расходы невелики. В случае OLTP просто нужно учитывать некоторые моменты

Цитата:

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

Ну, журналы я скорее предпочту чистить, нежели сжимать. Знаю, что выглядит немного радикально Знаю, что не всегда возможно (например, локализованные отчеты построенные на складских журналах)
INVENTSUM - скорее всего нет. Даже при использовании партий, палет и серийных номеров размер таблицы недостаточно велик, чтобы при включении VARDECIMAL получить хоть какую-то значимую экономию дискового пространства. Кроме того, при высокой частоте обновления (UPDATE) повышается вероятность того, что ранее "сжатая" запись должна "разжаться" (новое значение требует большей размерности по сравнению со старым) и на странице не свободного места, что ведет либо к расщеплению страницы, либо к появлению forwarded record (все это описано в whitepaper по ссылке, которую я привел)
INVENTTRANS, INVENTSETTLEMENT, LEDGERTRANS - тут выигрыш в занимаемом таблицей пространстве имеет место быть, какого-либо заметного влияния на производительность не ощутил (да и не ставил такой цели, если честно)

[mazzy]

Т.е. ты рекомендуешь скорее trans-таблицы.

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

2.
Насколько стоит геморроится сегментированием таких таблиц, чтобы задать разные режимы сжатия для разных сегментов?

[Vadik]

Цитата:

Сообщение от mazzy

Т.е. ты рекомендуешь скорее trans-таблицы

Перефразирую - большие таблицы

Цитата:

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

Я пока не встречался с ситуацией, когда остатки по GL представляли собой сколько-нибудь существенную долю от общего объема БД. Сжать - можно (за компанию с транзакционными таблицами), сожмется хорошо (в процентном отношении)

Цитата:

Насколько стоит геморроится сегментированием таких таблиц, чтобы задать разные режимы сжатия для разных сегментов?

Это уже не VARDECIMAL, а DATA_COMPRESSION и соответственно следующая версия СУБД - SQL Server 2008. Стоит ли геморроиться - это уже решать DBA в каждом конкретном случае

[egorych]

Цитата:

Сообщение от mazzy

Т.е. ты рекомендуешь скорее trans-таблицы...

Цитата:

Сообщение от Vadik

Перефразирую - большие таблицы ..

Добавлю мое ИМХО - и еще из которых МНОГО читается. Много не в смысле часто, а много в смысле много записей.
Например у нас INVENTSETTLEMENT у нас ~50млн. Но читается из него по объему не много и в большинстве случаев по индексу - т.е. проблем не доставляет и в top запросов не фигурирует.
А вот SYSDATABASELOG подумываю сжать, ибо как что найти нужно, так IO начинает расти здорово! Ибо интексов ненастроешься на нее!

palleagermark: Intelligent Data Management Framework For Microsoft Dynamics AX (Pre-Release)

Вот эту штуку кто-нибудь попробовал?

[Vadik]

Цитата:

Сообщение от Logger

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

Как под заказ, Storage engine team выпустили вчера статью
Update on Data Compression as available in SQL Server 2008 RTM and links to white papers