Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Постраничное сжатие в SQL17 (+/-) ?  [new]
senn
Member

Откуда:
Сообщений: 403
У кого есть опыт использования страничного сжатия таблиц? (SQL 2017)

Интересует положительный/отрицательный (последний больше) опыт. Особенность, как я понимаю, относительно свежая (SQL 2016).
Положительные стороны более или менее очевидны. Интересуют грабли, на которые можно наступить (кроме анонсированного MS требовательности к cpu).
Имеет ли смысл в DWH включать эту опцию по умолчанию, или все же от определенного (от какого?) объема данных в таблице.
Влияние сжатия на разные форматы данных понятно.
Надо ли, для часто обновляемых таблиц, повторять инструкцию
ALTER TABLE MyTab REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE);

по аналогии с ребилдом индекса, или это происходит автоматически? Как я понял - нет, но где-то проскочило, что вроде бы нужно..

Спасибо!
25 окт 19, 09:45    [22002255]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
Yasha123
Member

Откуда:
Сообщений: 1621
senn
Особенность, как я понимаю, относительно свежая (SQL 2016).

ваша осетрина второй свежести.
page compression появилось в 2008.
опыт положителен.
очень не хватает этого в Стандарде
25 окт 19, 10:02    [22002277]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
senn
Member

Откуда:
Сообщений: 403
Yasha123,

"осетрина второй свежести" имеет отрицательную коннотацию, а опыт положительный))

Спасибо, я исходил из того, что статья в MSDN, на версии ниже 2016 не давала инфу (вероятно изменился источник ссылки).

Опыт у меня тоже положительный, а хотелось бы услышать что-то плохое))
25 окт 19, 10:06    [22002282]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6680
senn,

Всё подрят не знаю зачем, смотрите sp_estimate_data_compression_savings и решаете
25 окт 19, 10:11    [22002288]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6949
senn,

используйте, если изменение схем таблиц происходит крайне редко, т.к. при этом происходит полная перепаковка с потреблением ресурсов и даунтаймом.
25 окт 19, 11:52    [22002400]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
Yasha123
Member

Откуда:
Сообщений: 1621
senn
"осетрина второй свежести" имеет отрицательную коннотацию, а опыт положительный))

я всегда точно цитирую фразу, на которую отвечаю,
фиче 10+ лет, поэтому и свежесть соответствующая :)

разумеется, компрессию не надо всюду включать,
но текстового мусора всегда хватает и там это помогает.
+ на всех мне достающихся серверах вечный нехват оперативки,
так что компрессия спасала, пока были Энтерпрайзы.
на Стандарде ни компрессии, ни колумнсторов, все продумано,
чтобы заставить покупать 2016 или же Энтерпрайз...
25 окт 19, 11:53    [22002401]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
msLex
Member

Откуда:
Сообщений: 6959
senn
У кого есть опыт использования страничного сжатия таблиц? (SQL 2017)

Интересует положительный/отрицательный (последний больше) опыт. Особенность, как я понимаю, относительно свежая (SQL 2016).
Положительные стороны более или менее очевидны. Интересуют грабли, на которые можно наступить (кроме анонсированного MS требовательности к cpu).
Имеет ли смысл в DWH включать эту опцию по умолчанию, или все же от определенного (от какого?) объема данных в таблице.
Влияние сжатия на разные форматы данных понятно.
Надо ли, для часто обновляемых таблиц, повторять инструкцию
ALTER TABLE MyTab REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE);

по аналогии с ребилдом индекса, или это происходит автоматически? Как я понял - нет, но где-то проскочило, что вроде бы нужно..

Спасибо!


Никаких отрицательных момент (ну кроме чуть большего расхода CPU) не обнаружено.
У нас, постраничное сжатие данных включено на всех таблицах.
Помимо явного плюса "освобождение дискового пространства", есть и более приятный бонус - большее количество данных, вмещающихся в тот же объем RAM, а значит уменьшение IOPS.

Польза второго бонуса в DWH сильно зависит от структуры запросов и соотношения RAM/DB Size

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

Сообщение было отредактировано: 25 окт 19, 12:02
25 окт 19, 12:01    [22002408]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29549
senn
Интересует положительный/отрицательный (последний больше) опыт. Особенность, как я понимаю, относительно свежая (SQL 2016).
Положительные стороны более или менее очевидны. Интересуют грабли, на которые можно наступить (кроме анонсированного MS требовательности к cpu).
Имеет ли смысл в DWH включать эту опцию по умолчанию, или все же от определенного (от какого?) объема данных в таблице.
Катастрофически деградирует скорость вставки bulk insert, в связи с тем, что компрессия делается одним ядром, и скорость вставки ограничена единицами мб/сек, независимо от железа.

Правда, это было на 2008 R2, может, сейчас пофиксили?
25 окт 19, 17:01    [22002867]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
Remind
Member

Откуда: UK
Сообщений: 454
В DWH имееть смысл подумать над columnstore
25 окт 19, 18:01    [22002943]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
VicSO
Member

Откуда:
Сообщений: 176
Еще насколько я понял (DATA_COMPRESSION = PAGE);
для ALTER INDEX [еее] ON [ее] REBUILD WITH ( ONLINE = ON ) обрабатывается по другому.
28 окт 19, 09:19    [22003864]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
vitkhv
Member

Откуда: Москва
Сообщений: 943
senn,
Вполне положительный опыт на редко используемых данных. На часто используемых стараюсь не включать компрессию.
Хотя работал и с полностью сжатыми базами с достаточно высокой нагрузкой как разработчик, не сказал бы что там был прям критичный провал в производительности.
28 окт 19, 18:37    [22004521]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
msLex
Member

Откуда:
Сообщений: 6959
VicSO
Еще насколько я понял (DATA_COMPRESSION = PAGE);
для ALTER INDEX [еее] ON [ее] REBUILD WITH ( ONLINE = ON ) обрабатывается по другому.

А что именно другого?
28 окт 19, 18:41    [22004523]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
VicSO
Member

Откуда:
Сообщений: 176
msLex,

Как выяснил, если работать с жатой таблицей и делать REBUILD WITH ( ONLINE = ON )
То данная операция разжимает и потом повторно сжимает. Естественно лог в этом случае забивается хорошо.
то есть если сделать REBUILD WITH ( ONLINE = OFF ) то лог транзакций будет 50 гб, но если сделать REBUILD WITH ( ONLINE = ON ) то лог транзакций будет уже под 300гигов
Пока обратного подтверждения не получил, более подробно ссылка ниже.
https://www.sql.ru/forum/1318488/problema-s-alter-index-rebuild-online-on
31 окт 19, 13:21    [22007107]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 3998
senn,

COLUMSTRORE жмет сильней чем PAGE COMPRESSION. Попробуйте его, если не наткнетесь на ограничения. На 2016 он уже хорошо оптимизирован под вставку
31 окт 19, 13:36    [22007124]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 3998
senn
Имеет ли смысл в DWH включать эту опцию по умолчанию, или все же от определенного (от какого?) объема данных в таблице.


Конкретно в DWH очень сильно не рекомендую. Юзайте COLUMNSTORE COLUMNSTORE_ARCHIVE
31 окт 19, 13:37    [22007127]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
msLex
Member

Откуда:
Сообщений: 6959
VicSO
msLex,

Как выяснил, если работать с жатой таблицей и делать REBUILD WITH ( ONLINE = ON )
То данная операция разжимает и потом повторно сжимает. Естественно лог в этом случае забивается хорошо.
то есть если сделать REBUILD WITH ( ONLINE = OFF ) то лог транзакций будет 50 гб, но если сделать REBUILD WITH ( ONLINE = ON ) то лог транзакций будет уже под 300гигов
Пока обратного подтверждения не получил, более подробно ссылка ниже.
https://www.sql.ru/forum/1318488/problema-s-alter-index-rebuild-online-on



rebuild всегда будет "разжимать/сжимать" данные, т.к. он перераспределяет данные по страницам.
31 окт 19, 13:43    [22007132]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6949
Расщепление страниц также должно выполнять перепаковку.
31 окт 19, 14:01    [22007148]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
VicSO
Member

Откуда:
Сообщений: 176
msLex,
Но такого при REBUILD WITH ( ONLINE = OFF ) нету, лог не забивается. как при ON
1 ноя 19, 07:19    [22007666]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
msLex
Member

Откуда:
Сообщений: 6959
VicSO
msLex,
Но такого при REBUILD WITH ( ONLINE = OFF ) нету, лог не забивается. как при ON

У этого могут быть разные причины, но с постраничным сжатием это не связанно.
1 ноя 19, 07:37    [22007670]     Ответить | Цитировать Сообщить модератору
 Re: Постраничное сжатие в SQL17 (+/-) ?  [new]
VicSO
Member

Откуда:
Сообщений: 176
msLex,

Какие можете назвать?
Пока только нашел в этом проблему.
то есть если взять оригинальный индекс (не сжатый) то он на генерит 300гиг в OFF и 340гигов в ON ту то понятно и это норма.
Но вот если его упаковать, и получится он 50 гигов, то при OFF получится 50гигов, но вот при ON то получится уже 340гигов, то есть обрабатывает его как не жатый.
1 ноя 19, 11:47    [22007932]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить