Сжатие данных SQL Server категорически хорошо для баз данных только для чтения?

В некоторых литературных источниках, посвященных сжатию данных в SQL Server, говорится, что стоимость записи возрастает примерно в четыре раза по сравнению с тем, что обычно требуется. Также представляется, что это является основным недостатком сжатия данных, что подразумевает, что для архивной базы данных только для чтения производительность (за некоторыми исключениями) улучшится за счет использования сжатия данных на 100% заполненных страниц.

Верны ли утверждения выше?
Каковы основные «вариации» между сжатием данных и прочим (для чтения)
- "Процессор + х%"?
- "IO -y%"?
- возникновение разбиения страницы?
- использование tempdb?
- Использование оперативной памяти?
А для написания?

Для целей этого вопроса вы можете ограничить контекст сжатием на уровне PAGE большой (> 1 ТБ) базы данных, но всегда приветствуются дополнительные комментарии.

Использованная литература:

Блог SQL Server Storage Engine (сценарий DW показывает, что сжатие является очень выгодным)
Сжатие данных: стратегия, планирование емкости и лучшие практики

Более детальный подход к решению, что сжимать, включает анализ характеристик рабочей нагрузки для каждой таблицы и индекса. Он основан на следующих двух метриках:

U: процент операций обновления для определенной таблицы, индекса или раздела по отношению к общему количеству операций с этим объектом. Чем ниже значение U (то есть таблица, индекс или раздел редко обновляются), тем лучше он подходит для сжатия страниц.
S: процент операций сканирования в таблице, индексе или разделе относительно общего количества операций над этим объектом. Чем выше значение S (т. Е. Таблица, индекс или раздел в основном сканируются), тем лучше он подходит для сжатия страниц.

Оба вышеперечисленных явно демонстрируют тенденцию к рекомендованию сжатия страниц для баз данных в стиле DW (интенсивное чтение / эксклюзивные операции с большими данными).

— 孔夫子
источник

Какая литература конкретно? Сжатие / распаковка всегда будет связано с загрузкой ЦП, но, как и в случае чтения, вы также пишете на меньшее количество страниц. На самом деле, я думаю, что сторона записи выиграет даже больше, чем сторона чтения, поскольку сторона чтения часто хранит сжатые страницы в памяти (это не всегда, но в лучшем случае зависит от размера данных и выделенной памяти).

— Аарон Бертран

Будет очень трудно предоставить какую-либо метрику, которую вы запрашиваете, потому что она полностью зависит от характера данных и возможности их сжатия (и это будет отличаться в зависимости от строки и страницы, а также ). Некоторые люди сообщают о степени сжатия до 90%, которая будет влиять как на использование памяти (в позитивном ключе), так и на процессор, чтобы выполнить такое большое сжатие. Эта статья учитывает накладные расходы процессора на 10% для сжатия строк и выше для страницы . То, что вы наблюдаете, может быть совсем другим.

— Аарон Бертран

Я предполагаю, что для архивной базы данных, доступной только для чтения, она может поместиться в памяти. Если все это может уместиться в памяти, то после загрузки в буферный пул нет смысла сжимать его. Однако, если он не может все уместиться в памяти, вы все равно можете увидеть некоторую выгоду в том, чтобы поменять местами меньшее количество страниц в кеше и вне его, даже если будет выполнена работа по его распаковке.

— Аарон Бертран

Кажется, что ни одна из добавленных вами ссылок не содержит упоминаний об этом 4-кратном штрафе за написание. Ты помнишь, где ты это взял? Хотелось бы увидеть контекст.

— Аарон Бертран

Ну, если вы не можете поместить данные в память, тогда этот сценарий спорный, верно? :-)

— Аарон Бертран

Ответы:

Просто мои 2цента из моих собственных экспериментов на 1-2-летнем оборудовании:

Операции только для чтения (сканирование в стиле DW, сортировка и т. Д.) В таблицах со сжатием страниц (~ 80 строк / страница), которые я обнаружил, безубыточны при уменьшении размера сжатия в ~ 3 раза.

Т.е. если таблицы в любом случае помещаются в память, сжатие страниц повышает производительность только в том случае, если размер данных сократился более чем в 3 раза. Вы сканируете меньше страниц в памяти, но сканирование каждой страницы занимает больше времени.

Я предполагаю, что ваш пробег может отличаться, если ваши планы сложны и требуют больших усилий. Помимо прочего, это также зависит от аппаратного обеспечения (штрафы за доступ к сторонним узлам NUMA, скорость памяти и т. Д.).

Выше приведено лишь приблизительное практическое правило, основанное на моих собственных тестовых прогонах с использованием моих собственных запросов на моем собственном оборудовании (Dell Poweredge 910 и младше). Это не Евангелие, а!

Редактировать: Вчера отличная презентация Томаса Кейзера на SQLBits XI была представлена в виде видео. Весьма актуально для этого обсуждения, оно показывает «уродливую» стоимость процессора для сжатия страниц - обновления замедляются в 4 раза, блокировки держатся немного дольше.

Тем не менее , Томас использует хранилище FusionIO и выбрал таблицу, которая «только» подходит для сжатия страниц. Если бы хранилище находилось в типичной сети хранения данных, а данные использовали сжатые 3x-4x, то картина могла бы быть менее драматичной.

— Джон Алан
источник

Это может быть старое оборудование? На новом оборудовании, чистый SSD Для хранения я считаю, что ядра не в состоянии легко поспевать за дисками. Я полагаю, что эта выгода станет намного легче - сокращение IO на 50% того стоит, если не вносить столько изменений.

— TomTom

TomTom, хранилище не входит в игру для этих фигур. Сравнение проводится между несжатыми таблицами в памяти и сжатыми таблицами в памяти.

— Джон Алан

Никогда не видел DWH, который был бы достаточно хорош для памяти. Шутки в сторону. Вы вернетесь к диску.

— TomTom

Да, конечно, вы иногда будете возвращаться к диску - чтение с диска - это то, где сжатие страниц почти всегда имеет преимущество (если данные достаточно сжаты!). Но если ваша рабочая нагрузка загружается с диска один раз, а затем манипулирует всем в памяти до конца дня - какой вес вы бы уделили чтению с диска и сколько операций в памяти?

— Джон Алан

Только что натолкнулся на соответствующую слайд-презентацию презентации от SQLBits 2013 от Томаса Кейзера

— Джон Алан

Я могу добавить несколько слов из своей среды хранилища данных.

Реализация сжатия (в моем случае PAGE) на тестовой таблице с 30 миллионами строк (18 ГБ) уменьшает размер таблицы с 18 ГБ до 3 ГБ! (эффективность хранения точно), но увеличьте время загрузки (записи) с 22 до 36 минут.

Поэтому для чтения или чтения и размещения данных в памяти это может быть хорошим решением, но при ежедневной загрузке данных это может привести к снижению производительности.

— Томаш Вечорковский
источник