Pull to refresh

Comments 9

статя интересное — но вот форматинг скриптов страдает…
Спасибо за отзыв.
Согласен, над «форматингом» можно было бы поработать, но т.к. скрипты использовались по сути единожды, плюс использовались готовые участки(из сети), то получилось так, как получилось.
Учту на будущее.
Проводили ли вы тестирование вариантов со сжатием данных? Интересно увидеть ваши цифры нагрузки на CPU со включенным сжатием и без.

Сами активно используем page compression при аналогичном порядке размера БД и некоторых таблиц. Какого либо существенного прироста нагрузки на CPU не заметили (на уровне шума 2-3%). При этом оно заметно снижает нагрузку на диск, объём хранимых данных на диске и в памяти (buffer pool).

Очень полезная фича, с учётом того, что она стала доступна в SQL Standard 2016 (после SP1).
Проводили ли вы тестирование вариантов со сжатием данных?

касаемо page compression — то тут было явное подтверждение как в мануалах MS, так и подтверждение непосредственно от специалиста MS, что нагрузка на CPU с высокой долей вероятности вырастет.
по row compression — выполняли даже предварительное сжатие, результат по сжатию был достаточно хорошим, но поскольку в пиковые часы нагрузки загрузка CPU была на уровне 60%, a однозначного ответа по увеличению загрузки CPU даже от специалистов MS не получили, то решили не рисковать. Нагрузочного стенда же в тот момент не было.

Тут наверное, интересно было бы потестировать сжатие columnstore в реальных условиях, но пока до этого еще не дошли.
Наша ситуация при внедрении page compression была аналогичной, но риск полностью оправдался.

Мануалы и специалист MS всегда скажут что оно потребляет ресурсы, но никогда не скажут сколько т.к. не будут брать на себя ответственность за то что творится в вашей БД. Да и в тех же мануалах написано что для каждого случая надо тестировать и цифр нет.

Даже если само page compression потребляет ресурсы CPU с одной стороны, то с другой — оно позволяет транзакциям проходить быстрее за счёт меньшей нагрузки на диск и buffer pool и т.о. снижает потребление ресурсов CPU на блокировках.

В целом — рекомендую вам протестировать этот способ, он может дать заметно больший эффект чем sparse columns.

Чтобы снизить риски — начните с применения сжатия на не самых критичных таблицах.
Думаю по возможности обязательно проверим!
Если уж назвали таблица X, то стоило затереть MBAnalit ).
Значит как минимум один читатель, прочел статью внимательно )
А если по делу — текст на картинках не распознается поисковыми системами, поэтому оставил так как есть.
Sign up to leave a comment.

Articles