Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Для типа ROW в основном производится сжатие численных типов, а varchar и т.п. не сжимается. Сжатие производится в строке.
Для типа PAGE сначала производится сжатие в строке, потом потом сжатие префикса, потом сжатие словаря. В этом случае хорошо сжимаются строчные типы. Так часто повторяющиеся подстроки помещаются в специальную область страницы, а уже в самих столбцах хранятся ссылки на эти подстроки в спецобласти.

Вопрос в следующем.

Будет индекс на большой таблице типа nonclustered index on dbo.Table(type_id,object_id,dt), где столбцы имеют следующие типы: type_id int, object_id int, dt datatime.
Какой тип сжатия выбрать для такого индекса? Если смысл в сжатии PAGE? Ведь все столбцы индекса целочисленных типов. Мне кажется, что для них сжатие префикса и сжатие словаря или вообще не будет производится, или ссылки на префикс и словарь займут больше места, чем сами данные.
Может быть для такого индекса воообще не производить сжатие?
27 сен 17, 12:41    [20826440]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36696
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-estimate-data-compression-savings-transact-sql
27 сен 17, 12:42    [20826444]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Гавриленко Сергей Алексеевич, спасибо! Я читал про эту процедуру. Но для неё сначала нужно создать индекс, а уже потом с помощью этой процедуры можно будет проверить какой выигрыш от сжатия мы получим при разных типах. И если это другой тип, то индекс нужно будет пересоздать.
27 сен 17, 12:59    [20826483]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 189
Дело не только в сжатии как таковом. Неоднократно наталкивался на ситуацию, когда кластерный индекс сжат, строишь еще один покрывающий не кластерный для какого то частого запроса и забываешь добавить сжатие. Оптимизатор все равно идет по сжатому кластерному. И все равно просит тот индекс который вроде как только что создали. А если создаешь его сжатым - все в порядке, и работает быстрее и бежит по нужному индексу.
27 сен 17, 13:00    [20826485]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5112
Prolog,

адекватный ответ вы можете получить только сделав тест на вашей системе.
а если сферически, то как правило page лучше показывает себя на селектах.
27 сен 17, 13:14    [20826524]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
o-o
Guest
LogrusAS
Дело не только в сжатии как таковом. Неоднократно наталкивался на ситуацию, когда кластерный индекс сжат, строишь еще один покрывающий не кластерный для какого то частого запроса и забываешь добавить сжатие. Оптимизатор все равно идет по сжатому кластерному. И все равно просит тот индекс который вроде как только что создали. А если создаешь его сжатым - все в порядке, и работает быстрее и бежит по нужному индексу.

видимо етот "покрывающий" содержал столько полей,
что сжатый кластерный весил меньше
27 сен 17, 13:18    [20826535]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
архивариус
Member

Откуда:
Сообщений: 149
есть таблица (7M row), вот её размеры в зависимости от типа сжатия:
NONE ROW PAGE COLUMNSTORE COLUMNSTORE_ARCHIVE
size (MB) 1672 656 495 173 87
(data+index) 1507+165 513+142 404+91 173+0 87+0


CREATE TABLE [dbo].[123](
[1] [int] NOT NULL,
[2] [smallint] NULL,
[3] [smallint] NULL,
[4] [int] NULL,
[5] [bigint] NULL,
[6] [bigint] NULL,
[7] [bigint] NULL,
[8] [bigint] NULL,
[9] [bigint] NULL,
[10] [bigint] NULL,
[11] [bigint] NULL,
[12] [bigint] NULL,
[13] [bigint] NULL,
[14] [bigint] NULL,
[15] [bigint] NULL,
[16] [bigint] NULL,
[17] [bigint] NULL,
[18] [bigint] NULL,
[19] [bigint] NULL,
[20] [bigint] NULL,
[21] [bigint] NULL,
[22] [bigint] NULL,
[23] [smallint] NULL,
[24] [smallint] NULL,
[25] [smallint] NULL,
[26] [smallint] NULL,
[27] [char](2) NOT NULL,
[28][char](2) NOT NULL,
[29] [bigint] NULL,
[30] [bigint] NULL,
[31] [datetime] NULL
) ON [PRIMARY]
GO
27 сен 17, 13:55    [20826628]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Нашел среднюю по размеру таблицу (15,955,742 строк). Создал три одинаковых по набору столбцов индекса (fillfactor=100, pad_index=off) c типами int, datetime, bigint, но с разными типами сжатия. Размер индексов следующий:

CompessionSize (KB)
NONE 416288
ROW 254376
PAGE 141616


Всем спасибо!
27 сен 17, 14:10    [20826688]     Ответить | Цитировать Сообщить модератору
 Re: Тип сжатия для индекса (data_compression): ROW или PAGE.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5112
Prolog
Всем спасибо!
для вас важен именно размер?? проведите тест на инсерты\селекты, а то как бы потом не было сюрпризов.
27 сен 17, 14:21    [20826747]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить