Comments 9
статя интересное — но вот форматинг скриптов страдает…
0
Проводили ли вы тестирование вариантов со сжатием данных? Интересно увидеть ваши цифры нагрузки на CPU со включенным сжатием и без.
Сами активно используем page compression при аналогичном порядке размера БД и некоторых таблиц. Какого либо существенного прироста нагрузки на CPU не заметили (на уровне шума 2-3%). При этом оно заметно снижает нагрузку на диск, объём хранимых данных на диске и в памяти (buffer pool).
Очень полезная фича, с учётом того, что она стала доступна в SQL Standard 2016 (после SP1).
Сами активно используем page compression при аналогичном порядке размера БД и некоторых таблиц. Какого либо существенного прироста нагрузки на CPU не заметили (на уровне шума 2-3%). При этом оно заметно снижает нагрузку на диск, объём хранимых данных на диске и в памяти (buffer pool).
Очень полезная фича, с учётом того, что она стала доступна в SQL Standard 2016 (после SP1).
0
Проводили ли вы тестирование вариантов со сжатием данных?
касаемо page compression — то тут было явное подтверждение как в мануалах MS, так и подтверждение непосредственно от специалиста MS, что нагрузка на CPU с высокой долей вероятности вырастет.
по row compression — выполняли даже предварительное сжатие, результат по сжатию был достаточно хорошим, но поскольку в пиковые часы нагрузки загрузка CPU была на уровне 60%, a однозначного ответа по увеличению загрузки CPU даже от специалистов MS не получили, то решили не рисковать. Нагрузочного стенда же в тот момент не было.
Тут наверное, интересно было бы потестировать сжатие columnstore в реальных условиях, но пока до этого еще не дошли.
0
Наша ситуация при внедрении page compression была аналогичной, но риск полностью оправдался.
Мануалы и специалист MS всегда скажут что оно потребляет ресурсы, но никогда не скажут сколько т.к. не будут брать на себя ответственность за то что творится в вашей БД. Да и в тех же мануалах написано что для каждого случая надо тестировать и цифр нет.
Даже если само page compression потребляет ресурсы CPU с одной стороны, то с другой — оно позволяет транзакциям проходить быстрее за счёт меньшей нагрузки на диск и buffer pool и т.о. снижает потребление ресурсов CPU на блокировках.
В целом — рекомендую вам протестировать этот способ, он может дать заметно больший эффект чем sparse columns.
Чтобы снизить риски — начните с применения сжатия на не самых критичных таблицах.
Мануалы и специалист MS всегда скажут что оно потребляет ресурсы, но никогда не скажут сколько т.к. не будут брать на себя ответственность за то что творится в вашей БД. Да и в тех же мануалах написано что для каждого случая надо тестировать и цифр нет.
Даже если само page compression потребляет ресурсы CPU с одной стороны, то с другой — оно позволяет транзакциям проходить быстрее за счёт меньшей нагрузки на диск и buffer pool и т.о. снижает потребление ресурсов CPU на блокировках.
В целом — рекомендую вам протестировать этот способ, он может дать заметно больший эффект чем sparse columns.
Чтобы снизить риски — начните с применения сжатия на не самых критичных таблицах.
0
Если уж назвали таблица X, то стоило затереть MBAnalit ).
0
Значит как минимум один читатель, прочел статью внимательно )
А если по делу — текст на картинках не распознается поисковыми системами, поэтому оставил так как есть.
А если по делу — текст на картинках не распознается поисковыми системами, поэтому оставил так как есть.
0
Sign up to leave a comment.
Разреженные столбцы или sparse columns в MS SQL Server. Реальный опыт применения