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