Чи категорично добре стиснення даних SQL Server для баз даних лише для читання?

Деяка література про стиснення даних SQL Server, яку я читаю, стверджує, що вартість запису збільшується приблизно в чотири рази, ніж зазвичай потрібно. Також, мабуть, мається на увазі, що це головний недолік стиснення даних, що сильно означає, що для архівної бази даних, доступної лише для читання, продуктивність (за кількома винятками) буде покращена за рахунок стиснення даних на 100% заповнених сторінок.

1. Чи правдиві твердження вище?

2. Які основні "варіації" між стисненням даних та іншими способами (для читання)

   • "CPU + x%"?
   • "IO -y%"?
   • виникнення розділеної сторінки?
   • використання tempdb?
   • Використання оперативної пам’яті?
3. А для написання?

Для цього питання можна обмежити контекст стисненням на рівні PAGE великої бази даних (> 1 ТБ) , однак додаткові коментарі завжди вітаються.

Список літератури:

Блог двигуна зберігання SQL Server (сценарій DW показує, що стиснення є дуже вигідним)
Стиснення даних: стратегія, планування потенціалу та найкращі практики

Більш детальний підхід до вирішення питання, що потрібно стиснути, включає аналіз характеристик навантаження для кожної таблиці та індексу. Він базується на таких двох показниках:

U: Відсоток операцій по оновленню певної таблиці, індексу або розділу, відносно загальних операцій на цьому об'єкті. Чим менше значення U (тобто таблиця, індекс або розділ нечасто оновлюється), тим кращим є кандидат на стиснення сторінки.
S: Відсоток операцій сканування на таблиці, індексі чи розділі відносно загальних операцій на цьому об'єкті. Чим вище значення S (тобто в основному сканується таблиця, індекс або розділ), тим кращим є кандидат на стиснення сторінки.

І те, і інше є демонстративно упередженим щодо рекомендування стиснення сторінок для баз даних у стилі DW (читання / ексклюзивні операції з великими даними).

Тільки мої 2 відсотки від моїх власних експериментів на апараті 1-2 років:

Операції лише для читання (сканування у стилі DW, сортування тощо) на таблицях, стиснених сторінками (~ 80rowrows / page) Я виявив беззбитковість при зменшенні розміру стиснення ~ 3x.

Тобто, якщо таблиці так чи інакше вписуються в пам'ять, стиснення сторінок приносить користь лише тоді, коли розмір даних зменшився більш ніж в 3 рази. Ви скануєте меншу кількість сторінок у пам'яті, але це потребує більше часу, щоб сканувати кожну сторінку.

Я думаю, що ваш пробіг може відрізнятися, якщо ваші плани є вкладеними і важкими. Окрім іншого, це також залежатиме від обладнання (штрафи за доступ до чужорідних вузлів NUMA, швидкість пам'яті тощо).

Наведене вище - лише грубе правило, яке я дотримуюся, на основі моїх власних тестових запусків, використовуючи власні запити на власному апаратному забезпеченні (Dell Poweredge 910 і молодші). Це не євангеліє, е-е!

Редагувати: Вчора відмінна презентація SQLBits XI Томаса Кейзера стала доступною як відео. Цілком актуально для цієї дискусії, вона показує «потворне» обличчя вартості процесора для стиснення сторінки - оновлення уповільнені на 4 рази, блокування утримується зовсім трохи довше.

Однак Томас використовує сховище FusionIO, і він вибрав таблицю, яка відповідає лише стисканню сторінки. Якщо зберігання було на типовому SAN, а використовувані дані стискали 3x-4x, то зображення, можливо, було б менш драматичним.

Я можу додати кілька слів із свого середовища зберігання даних.

Реалізація стиснення (PAGE в моєму випадку) на тестовому столі з 30 мільйонами рядків (18 Гб) зменшує розмір таблиці з 18 ГБ до 3 ГБ! (ефективність зберігання точно), але збільшуйте час завантаження (записуйте) з 22 до 36 хвилин.

Отже, для читання чи читання та розміщення даних у пам'яті це може бути хорошим рішенням, але для щоденного завантаження даних це може спричинити зниження продуктивності.