Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Сжатие таблицы  [new]
Епифанцев
Guest
Добрый день, имеется таблица размером ~550ГБ, хочу сделать там сжатие на уровне страниц, но операция очень затратная, 16 ядер забиваются в мгновение ока + очень долго.
Интересует вопрос, если я сделаю секционирование, допустим, на 5 секций, и к каждой отдельно применю сжатие, а потом уберу секционирование, сжатие останется?
15 авг 14, 12:41    [16445797]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
Епифанцев
Интересует вопрос, если я сделаю секционирование, допустим, на 5 секций, и к каждой отдельно применю сжатие, а потом уберу секционирование, сжатие останется?

Сделаю секционирование = ребилд или переливка всех данных.
Отдельно применю сжатие = ребилд всего за несколько подходов.
Уберу секционировани = ребилд или переливка всех данных.

Один ребилд делать накладно, поэтому сделаем три? O_o

Епифанцев
16 ядер забиваются в мгновение ока + очень долго.
maxdop'ом зажмите и в онлайне жмите. Было бы место.
15 авг 14, 12:45    [16445838]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Гавриленко Сергей Алексеевич
Епифанцев
Интересует вопрос, если я сделаю секционирование, допустим, на 5 секций, и к каждой отдельно применю сжатие, а потом уберу секционирование, сжатие останется?

Сделаю секционирование = ребилд или переливка всех данных.
Отдельно применю сжатие = ребилд всего за несколько подходов.
Уберу секционировани = ребилд или переливка всех данных.

Один ребилд делать накладно, поэтому сделаем три? O_o

Епифанцев
16 ядер забиваются в мгновение ока + очень долго.
maxdop'ом зажмите и в онлайне жмите. Было бы место.


Я только что прорабатывал оптимизацию самой крупной таблицы в БД. Среди прочего рассматривалось сжатие исторической партиции. Результат фактического тестирования оказался крайне отрицательным. Выборка из сжатой партиции идет медленнее в два раза и жрет ЦПУ. А объём особо не сократился. Впрочем у меня одни цифры в таблице.

Я несколько раз на нескольких проектах порывался включать сжатие, но фактические результат всегда оказывался отрицательным. Зато перенос исторической части таблицы в readonly партицию дал куба дольше пользы. Время сканов сократилось в 1.5-2 раза. Особенно readonly хорошо себя показывает, когда запрос делается параллельно с другой нагрузкой.

Меня вот интересует у кого-то был положительный результат от включения сжатия.
15 авг 14, 12:58    [16445959]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Епифанцев
Добрый день, имеется таблица размером ~550ГБ, хочу сделать там сжатие на уровне страниц, но операция очень затратная, 16 ядер забиваются в мгновение ока + очень долго.
Интересует вопрос, если я сделаю секционирование, допустим, на 5 секций, и к каждой отдельно применю сжатие, а потом уберу секционирование, сжатие останется?


Можно сжимать отдельные партиции. Посмотрите внимательно хелп по перестроению индексов.
15 авг 14, 12:59    [16445974]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
a_voronin
Гавриленко Сергей Алексеевич
пропущено...

Сделаю секционирование = ребилд или переливка всех данных.
Отдельно применю сжатие = ребилд всего за несколько подходов.
Уберу секционировани = ребилд или переливка всех данных.

Один ребилд делать накладно, поэтому сделаем три? O_o

пропущено...
maxdop'ом зажмите и в онлайне жмите. Было бы место.


Я только что прорабатывал оптимизацию самой крупной таблицы в БД. Среди прочего рассматривалось сжатие исторической партиции. Результат фактического тестирования оказался крайне отрицательным. Выборка из сжатой партиции идет медленнее в два раза и жрет ЦПУ. А объём особо не сократился. Впрочем у меня одни цифры в таблице.

Я несколько раз на нескольких проектах порывался включать сжатие, но фактические результат всегда оказывался отрицательным. Зато перенос исторической части таблицы в readonly партицию дал куба дольше пользы. Время сканов сократилось в 1.5-2 раза. Особенно readonly хорошо себя показывает, когда запрос делается параллельно с другой нагрузкой.

Меня вот интересует у кого-то был положительный результат от включения сжатия.
Прежде всего, перед сжатием надо оценивать его профитность процедурой sys.sp_estimate_data_compression_savings. В некоторых случаях сжатые данные занимают больше места, чем оригинал.

Сжатие работает хорошо, когда у вас узкое место -- диски и/или память. Если вам не хватает процессоров, то смысла в нем скорее всего не будет.

Сообщение было отредактировано: 15 авг 14, 13:05
15 авг 14, 13:05    [16446020]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Епифанцев
Guest
Это будет отдельня виртуалка с базой чисто под архив, пока что там 16 ядер, но потом сократим до 8. Сжатие я использую потому что возникает проблема с нехваткой места, раньше я применял сжатие на мелких таблицах ~100-200ГБ, результат давало положительный
15 авг 14, 13:08    [16446035]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Я думаю вам вот что надо сделать

1) Используя

ALTER PARTITION SCHEME

и

ALTER PARTITION FUNCTION

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

2) Rebuild с такими опциями

REBUILD WITH
(
DATA_COMPRESSION = NONE ON PARTITIONS (1),
DATA_COMPRESSION = ROW ON PARTITIONS (2, 4, 6 TO 8),
DATA_COMPRESSION = PAGE ON PARTITIONS (3, 5)
)

Но прежде чем приступать к этому протестируйте результат на отдельном сервере.
15 авг 14, 13:09    [16446038]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Епифанцев
Guest
Гавриленко Сергей Алексеевич,

Да с процессорами-то все нормально, дисковая подсистема хорошая, а вот место надо сэкономить. Я степень сжатия оценил, где-то в 2.5 раза примерно получается
15 авг 14, 13:10    [16446043]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
Епифанцев
Гавриленко Сергей Алексеевич,

Я степень сжатия оценил, где-то в 2.5 раза примерно получается
А сервер во сколько оценил?

Сообщение было отредактировано: 15 авг 14, 13:11
15 авг 14, 13:10    [16446045]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Епифанцев
Guest
a_voronin,

Да, я аналогично прикинул, сервак пока что полностью в моем распоряжении - играйся сколько влезет, а т.к. задача не особо срочная (больше просто делать нечего), то решил рассмотреть все варианты и найти лучший.
15 авг 14, 13:12    [16446058]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Епифанцев
Guest
Гавриленко Сергей Алексеевич,

я через estimate_data_compresion посмотрел, раза в 2.5
15 авг 14, 13:14    [16446067]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
Епифанцев
Гавриленко Сергей Алексеевич,

я через estimate_data_compresion посмотрел, раза в 2.5
Тогда жмите. Оффлайновый реблилд будет быстрее и правильнее, если "сервак пока что полностью в моем распоряжении - играйся сколько влезет".
15 авг 14, 13:15    [16446069]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
автор
Результат фактического тестирования оказался крайне отрицательным. Выборка из сжатой партиции идет медленнее в два раза и жрет ЦПУ. А объём особо не сократился.


Интересный момент! Сжатие страниц или записей?
Сжатие разнородных данных по записям показывает эффективное сокращение времени запроса приблизительно на процент уменьшения количества чтений.

Судя по технике сжатия сжатие именно числовых данных уровня страницы должно быть неэффективным при рандом заполнении.
15 авг 14, 13:44    [16446283]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Владислав Колосов
автор
Результат фактического тестирования оказался крайне отрицательным. Выборка из сжатой партиции идет медленнее в два раза и жрет ЦПУ. А объём особо не сократился.


Интересный момент! Сжатие страниц или записей?
Сжатие разнородных данных по записям показывает эффективное сокращение времени запроса приблизительно на процент уменьшения количества чтений.

Судя по технике сжатия сжатие именно числовых данных уровня страницы должно быть неэффективным при рандом заполнении.


Сжатие страниц. При этом у меня была задача сократить время выборки, вот здесь результат был прямо противоположным.
15 авг 14, 14:06    [16446466]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
o-o
Guest
так чего все подряд-то жать?
наверное, можно прочитать, за счет чего ужимается, и, зная собственные данные, прикинуть, будет толк или нет.
ну и как выше писали, когда самому неясно, ну попроси ты сервер оценить(sys.sp_estimate_data_compression_savings),
он же не в хрустальном шаре смотрит, а делает реальную выборку и пробует сжать.
a_voronin
Меня вот интересует у кого-то был положительный результат от включения сжатия.

у нас DWH, данные в основном строковые, денормализованные, сжалось в 8 раз -- PAGE COMPRESSION
15 авг 14, 14:14    [16446523]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
автор
Сжатие страниц.


Вот собака и порылась здесь. Для чисел сжимать следует строки, т.к. построение словаря будет неэффективным и затратным.
И не каждый вид символьных данных будет эффективно сжат страницами - только телефонные справочники подобные им, т.е. отсортированные медленно изменяющиеся.
15 авг 14, 14:29    [16446658]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
o-o
Guest
Владислав Колосов
автор
Сжатие страниц.


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


можно ссылочку на необходимость "отсортированных" данных?
не вижу этого требования (или даже рекомендации) в документации.
+ PAGE COMPRESSION это не ROW COMPRESSION в смысле увеличения объема
ROW COMPRESSION потребовали -- применилось, возможно, ухудшив ситуацию в плане объема, а вот PAGE COMPRESSION, если не приносит профита, сервер просто не применяет.
пока вот это процитирую, но если надо, найду из другого источника, мне неоднократно попадалось:

Row compression is always performed when requested, but page compression depends on the
amount of space that can be saved.

Not every page in a compressed table has both an anchor record for prefixes and a dictionary.
If there are no useful prefix values, the page might just have a dictionary. If no values repeat
often enough that replacing them with symbols saves space, the page might just have an
anchor record. And, of course, there may be pages that have neither an anchor record nor a
dictionary, if there are no patterns at all in the data on the page.
15 авг 14, 15:29    [16447088]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
o-o
Guest
уточню, а то можно подумать, что включаешь сжатие страниц, и оно никогда "не изгадит".
может изгадить, но не в части, относящейся именно к "PAGE", а том же самом "ROW COMPRESSION",
потому что PAGE COMPRESSION сперва делает ROW COMPRESSION:

Page compression always includes row compression. (That is, if you enable page
compression for a table, row compression is automatically enabled.)

и только при построении словаря начинает задумываться, стОит оно того или нет.
т.е. включив любую компрессию, что-то будет сделано всегда, внутренний формат страниц меняется,
никакого больше FixedVar format
15 авг 14, 15:49    [16447208]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
o-o
Владислав Колосов
пропущено...


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


можно ссылочку на необходимость "отсортированных" данных?
не вижу этого требования (или даже рекомендации) в документации.
+ PAGE COMPRESSION это не ROW COMPRESSION в смысле увеличения объема
ROW COMPRESSION потребовали -- применилось, возможно, ухудшив ситуацию в плане объема, а вот PAGE COMPRESSION, если не приносит профита, сервер просто не применяет.
пока вот это процитирую, но если надо, найду из другого источника, мне неоднократно попадалось:

Row compression is always performed when requested, but page compression depends on the
amount of space that can be saved.

Not every page in a compressed table has both an anchor record for prefixes and a dictionary.
If there are no useful prefix values, the page might just have a dictionary. If no values repeat
often enough that replacing them with symbols saves space, the page might just have an
anchor record. And, of course, there may be pages that have neither an anchor record nor a
dictionary, if there are no patterns at all in the data on the page.


Я прогнал оптимизатор. Он дает чуть лучший результат (%сжатия ) для ROW COMPRESSION. Но отличие незначительное -- в обоих случаях 2-2.5 раза. Меня не устроило в этой оптимизации другое обстоятельство -- скорость чтения возраста из-за значительно увеличившегося расхода CPU. Да хранится компактнее, но выбирается медленнее.


А на таблице из одних цифр да ROW COMPRESSION получше, но на каких-то 10-20%, а не кардинально.
15 авг 14, 18:19    [16447903]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
o-o
Guest
смотрите, я не админ, кроме как на своем компе, ок?
но я овнер рабочей базы, т.е. я вижу, что делают с моими таблицами по ночам,
у меня DDL-триггера на свои базы.
так вот, сжатие у нас где-то незамечено прошло, где-то быстрее отчеты стали считаться,
тормозов не появилось, что там у них с CPU -- понятия не имею,
но, видимо, когда большие объемы данных значительно уменьшаются (8 раз), эффект положительный,
может, у них диски медленные, и раз меньше читается, нам оно быстрее выходит.
а когда как у вас --2-2,5 раза -- может оно того и не стОит.
15 авг 14, 21:22    [16448462]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
o-o
смотрите, я не админ, кроме как на своем компе, ок?
но я овнер рабочей базы, т.е. я вижу, что делают с моими таблицами по ночам,
у меня DDL-триггера на свои базы.
так вот, сжатие у нас где-то незамечено прошло, где-то быстрее отчеты стали считаться,
тормозов не появилось, что там у них с CPU -- понятия не имею,
но, видимо, когда большие объемы данных значительно уменьшаются (8 раз), эффект положительный,
может, у них диски медленные, и раз меньше читается, нам оно быстрее выходит.
а когда как у вас --2-2,5 раза -- может оно того и не стОит.
Еще раз. Сжатие помогает траты одних ресурсов заменить на другие. Я тут уже писал: 16446020
15 авг 14, 23:51    [16449008]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
a_voronin
Зато перенос исторической части таблицы в readonly партицию дал куба дольше пользы. Время сканов сократилось в 1.5-2 раза. Особенно readonly хорошо себя показывает, когда запрос делается параллельно с другой нагрузкой.
Это такая экономия на блокировках что-ли? Или за счет чего еще прирост производительности?
16 авг 14, 02:25    [16449436]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
Епифанцев
Guest
Отлично пожалось, прошлый размер базы - 1.4ТБ, сейчас она весит ~350ГБ, запросы к ней проходят адекватно, мониторил через перфмон
18 авг 14, 10:22    [16454342]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Mind
a_voronin
Зато перенос исторической части таблицы в readonly партицию дал куба дольше пользы. Время сканов сократилось в 1.5-2 раза. Особенно readonly хорошо себя показывает, когда запрос делается параллельно с другой нагрузкой.
Это такая экономия на блокировках что-ли? Или за счет чего еще прирост производительности?


Да на блокировках, это все равно что на запросе всё время NOLOCK стоит и при этом данные целостны.

Я кстати попробовал readonly + сжатие и Readonly без сжатия. Readonly без сжатия гораздо лучше.

Ещё один момент -- это перед переходом в readonly сделал REBUILD INDEX c FILLFACTOR = 100
18 авг 14, 14:39    [16456437]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить