Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 COMPRESSION страниц данных  [new]
Alx65
Member

Откуда: МО
Сообщений: 402
В ходе исследований по переходу с 2005 на SQL2008 для задачи с оч.большими базами, обсуждавшейся в параллельных ветках, решил попробовать на новом сервере без нагрузки эффективность сжатия страниц данных.

select @@VERSION
Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64)   Mar 29 2009 10:11:52   Copyright (c) 1988-2008 Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: ) 


Создаем таблицу в трех вариантах NONE, ROW, PAGE. Делаем вставку в нее 8 млн.записей.
DROP TABLE StatVV;
CREATE TABLE [dbo].[StatVV](...) ON [PRIMARY]
ALTER TABLE StatVV REBUILD WITH(DATA_COMPRESSION = ROW );
INSERT INTO StatVV WITH(TABLOCK)SELECT TOP(80000000) * FROM StatVV0;

Чистим буффера, считаем сумму поля.
DBCC DROPCLEANBUFFERS;
select SUM(CAST(nums as bigint)) from dbo.StatVV
После этого аналогичный вызов, но без сброса буферов
select SUM(CAST(nums as bigint)) from dbo.StatVV


Тип сжатияРазмер(МБ)Экономия(%)INSERT(сек)Потеря(%)SELECT SUM c CLEAN(сек)Выигрыш(%)SELECT SUM без CLEAN(сек)Проигрыш(%)
NONE4 4010%68100%210%6100%
ROW3 47021%128188%1719%9150%
PAGE2 63940%570982%1433%10166%


Вобщем, получилось следующее:
1. Выигрыш от сжатия по месту ощутим - 20 и 40% соотвественно. Но за 40% придется расплачиваться 10 кратным увеличением времени записи.
2. Если данные читаются с диска, то сжатые данные обрабатываются быстрее.
3. Если данные подкэшированы, то сжатые данные обрабатываются медленнее.

Что удивило:
1. Существенная трата времени на сжатие(1,8 раза) и разжатие(1,5 раза) типа ROW. Ожидал, что оно вообще не должно увеличивать время.
2. Очень малая потеря на разжатии типа PAGE.

Может быть я что-то делаю не так?


--------------------------------------------------------------------------------------------------------------------------------------------------
Не сортируй отсортированное! (с) Д.Кнут. Искусство программирования. Том 3. Сортировка и поиск.
1 дек 10, 11:21    [9867479]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
Maks Bragar
Member

Откуда: UA->AT
Сообщений: 165
Alx65,

тоже играюсь в эту сторону

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1746.0 (X64)

табличка с 66819367rows, сделал ей DATA_COMPRESSION = PAGE
в лоб гоняю репорт (чтение) до и после, на сервере один, после заметил увеличение времени выполнения.
Переделал индексы и вынес в отдельную ФГ, время репорта снизилось.
1 дек 10, 18:05    [9871285]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
Balbidon
Member

Откуда: Donetsk->Emerald City
Сообщений: 358
А конфигурация сервера какая? Память, процессоры, диски? Счетчики производительности по CPU что показывают?
1 дек 10, 18:26    [9871392]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Сжатие данных явно "поможет" только тем запросам, для выполнения которых требуется чтение данных с диска.
Если же памяти и без сжатия достаточно, то оно конечно только снизит производительность.

Кроме того, я бы не рекомендовал применять сжатие в случае, если коэффициент сжатия индекса (heap) меннее, чем 1,5.
Аналогично для небольших и активно используемых таблиц вроде справочников - будет больше расхода CPU, чем выигрыша от сжатия.
Ну и принимать решение о том, что нужно сжимать и как (страницы/строки) нужно конечно индивидуально для каждого индекса (heap), а не для таблицы в целом.

PS для индексов по монотонно возрастающим полям сначала лучше изменить fillfactor на значение, близкое к 100 - возможно пользы будет больше.
1 дек 10, 19:26    [9871585]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
Alx65
Member

Откуда: МО
Сообщений: 402
Balbidon
А конфигурация сервера какая? Память, процессоры, диски? Счетчики производительности по CPU что показывают?

HP DL360G7 12 ядер. 84 Гб ОП. Игрался пока на локальных дисках. Важна была закономерность.
Запись шла в один поток(одно ядро под плешку). SELECT SUM параллелился(все ядра прыгали слегка).
1 дек 10, 20:34    [9871835]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
Alx65
Member

Откуда: МО
Сообщений: 402
DeColo®es
Сжатие данных явно "поможет" только тем запросам, для выполнения которых требуется чтение данных с диска.
Если же памяти и без сжатия достаточно, то оно конечно только снизит производительность.

Мне не очень понятно, почему вариант ROW дает именно в памяти проигрыш. Если почитать алгоритм сжатия, то не понятно куда они тратят время...
DeColo®es
Кроме того, я бы не рекомендовал применять сжатие в случае, если коэффициент сжатия индекса (heap) меннее, чем 1,5.

В данном случае была куча. Планируется использовать для RO архивных данных, плотненько забитых по единственному кластерному индексу.
DeColo®es
Аналогично для небольших и активно используемых таблиц вроде справочников - будет больше расхода CPU, чем выигрыша от сжатия.
Ну и принимать решение о том, что нужно сжимать и как (страницы/строки) нужно конечно индивидуально для каждого индекса (heap), а не для таблицы в целом.

Что, вобщем-то и подтверждают результаты

DeColo®es
PS для индексов по монотонно возрастающим полям сначала лучше изменить fillfactor на значение, близкое к 100 - возможно пользы будет больше.

Таковых, слава богу, не имеется
1 дек 10, 20:45    [9871874]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Alx65
Таковых, слава богу, не имеется


Интересный подход...
1 дек 10, 21:12    [9871935]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Alx65
DeColo®es
PS для индексов по монотонно возрастающим полям сначала лучше изменить fillfactor на значение, близкое к 100 - возможно пользы будет больше.

Таковых, слава богу, не имеется
То есть ни одного индекса по полям, в которые при вставке заносится результат getdate() и все ключи GUID-based?
1 дек 10, 22:42    [9872295]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
Alx65
Member

Откуда: МО
Сообщений: 402
DeColo®es
Alx65
пропущено...

Таковых, слава богу, не имеется
То есть ни одного индекса по полям, в которые при вставке заносится результат getdate() и все ключи GUID-based?


Там единственный индекс - кластерный примари кей по 7 полям. Дата (без времени) присутствует как первое поле, оно же поле секционирования. Значение одно для всех записей дня. Smallint как номер дня от 01.01.10. Требуемый порядок поддерживается остальными 6-ю полями. Т.е. структура хранения оптимизируется не под загрузку, а под выборку.
2 дек 10, 10:51    [9873490]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: COMPRESSION страниц данных  [new]
_SiMBA_
Member

Откуда: Almaty
Сообщений: 157
Весьма интересные тесты

а подобные тесты не проводились для индексов ?
14 фев 13, 09:43    [13924191]     Ответить | Цитировать Сообщить модератору
 Re: COMPRESSION страниц данных  [new]
_SiMBA_
Member

Откуда: Almaty
Сообщений: 157
И еще, смысл есть подобное повторить на 2012 сервере ?
14 фев 13, 09:43    [13924196]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить