В некоторых литературных источниках, посвященных сжатию данных в SQL Server, говорится, что стоимость записи возрастает примерно в четыре раза по сравнению с тем, что обычно требуется. Также представляется, что это является основным недостатком сжатия данных, что подразумевает, что для архивной базы данных только для чтения производительность (за некоторыми исключениями) улучшится за счет использования сжатия данных на 100% заполненных страниц.
- Верны ли утверждения выше?
Каковы основные «вариации» между сжатием данных и прочим (для чтения)
- "Процессор + х%"?
- "IO -y%"?
- возникновение разбиения страницы?
- использование tempdb?
- Использование оперативной памяти?
- А для написания?
Для целей этого вопроса вы можете ограничить контекст сжатием на уровне PAGE большой (> 1 ТБ) базы данных, но всегда приветствуются дополнительные комментарии.
Использованная литература:
Блог SQL Server Storage Engine (сценарий DW показывает, что сжатие является очень выгодным)
Сжатие данных: стратегия, планирование емкости и лучшие практики
Более детальный подход к решению, что сжимать, включает анализ характеристик рабочей нагрузки для каждой таблицы и индекса. Он основан на следующих двух метриках:
U: процент операций обновления для определенной таблицы, индекса или раздела по отношению к общему количеству операций с этим объектом. Чем ниже значение U (то есть таблица, индекс или раздел редко обновляются), тем лучше он подходит для сжатия страниц.
S: процент операций сканирования в таблице, индексе или разделе относительно общего количества операций над этим объектом. Чем выше значение S (т. Е. Таблица, индекс или раздел в основном сканируются), тем лучше он подходит для сжатия страниц.
Оба вышеперечисленных явно демонстрируют тенденцию к рекомендованию сжатия страниц для баз данных в стиле DW (интенсивное чтение / эксклюзивные операции с большими данными).
Ответы:
Просто мои 2цента из моих собственных экспериментов на 1-2-летнем оборудовании:
Операции только для чтения (сканирование в стиле DW, сортировка и т. Д.) В таблицах со сжатием страниц (~ 80 строк / страница), которые я обнаружил, безубыточны при уменьшении размера сжатия в ~ 3 раза.
Т.е. если таблицы в любом случае помещаются в память, сжатие страниц повышает производительность только в том случае, если размер данных сократился более чем в 3 раза. Вы сканируете меньше страниц в памяти, но сканирование каждой страницы занимает больше времени.
Я предполагаю, что ваш пробег может отличаться, если ваши планы сложны и требуют больших усилий. Помимо прочего, это также зависит от аппаратного обеспечения (штрафы за доступ к сторонним узлам NUMA, скорость памяти и т. Д.).
Выше приведено лишь приблизительное практическое правило, основанное на моих собственных тестовых прогонах с использованием моих собственных запросов на моем собственном оборудовании (Dell Poweredge 910 и младше). Это не Евангелие, а!
Редактировать: Вчера отличная презентация Томаса Кейзера на SQLBits XI была представлена в виде видео. Весьма актуально для этого обсуждения, оно показывает «уродливую» стоимость процессора для сжатия страниц - обновления замедляются в 4 раза, блокировки держатся немного дольше.
Тем не менее , Томас использует хранилище FusionIO и выбрал таблицу, которая «только» подходит для сжатия страниц. Если бы хранилище находилось в типичной сети хранения данных, а данные использовали сжатые 3x-4x, то картина могла бы быть менее драматичной.
источник
Я могу добавить несколько слов из своей среды хранилища данных.
Реализация сжатия (в моем случае PAGE) на тестовой таблице с 30 миллионами строк (18 ГБ) уменьшает размер таблицы с 18 ГБ до 3 ГБ! (эффективность хранения точно), но увеличьте время загрузки (записи) с 22 до 36 минут.
Поэтому для чтения или чтения и размещения данных в памяти это может быть хорошим решением, но при ежедневной загрузке данных это может привести к снижению производительности.
источник