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

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

  1. Являются ли утверждения выше true?
  2. Каковы первичные «вариации» между сжатием данных и в противном случае (для чтения)

    • "CPU + x%"?
    • "IO -y%"?
    • Разбиение страницы
    • Использование tempdb?
    • Использование ОЗУ
  3. И для написания?

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


Литература:

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

  

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

     

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

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

11 голосов | спросил 孔夫子 4 AMpThu, 04 Apr 2013 01:48:21 +040048Thursday 2013, 01:48:21

2 ответа


6

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

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

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

I guess ваш пробег может измениться, если ваши планы вложенные и тяжелые. Среди прочего, это также будет аппаратно-зависимым (внешние ограничения доступа к узлу NUMA, скорость памяти и т. Д.).

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

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

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

ответил John Alan 3 J0000006Europe/Moscow 2013, 11:26:25
0

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

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

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

ответил Tomasz Wieczorkowski 12 Mayam17 2017, 11:43:35

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132