Comments 9
Непонятен смысл заголовка - зачем это сравнивать? Такое ощущение, что БД и бэкап(ы) хранятся на одном диске и очень надо по максимуму сжать все данные. Это так?
Нет. Просто в худшем случае могла бы быть такая ситуация: компрессия данных могла бы раздувать бы бэкап
Бэкап конечно хранится в другом месте. Но его размер тоже важен. Если, например, как у нас, базы 95тб и бэкап идёт двое суток. Вы тогда очень будете беспокоиться о размере
По-моему, бэкапить уже сжатые данные всегда быстрее, потому что их просто меньше, а 90% потери скорости - это сеть. И обычно место на бэкапе не так дорого/важно, как на проде.
Здесь скорость не всегда первична. Если делать нормальную структуру хранения бэкапов, типа трехуровневой. то объем занимаемого места очень даже важен, особенно для больших баз. А сам бэкап обычно идет с аппаратного снапшота, и время бэкапа так не так чтобы очень критично.
Во всяком случае, я бы выбрал на 10% меньше места в долгосрочном хранении, чем на 15% быстрее скорость бэкапа.
Не слышал даже про аппаратный снэпшот, но автор написал что бэкап идёт 2 суток.
У нас чисто железные сервера с локальными SSD, так как экстремальные нагрузки, так что бэкапы у нас обычные
Если делать бэкап с локальных SSD дисков, то скорее всего самое критичное будет - это время бэкапа, так как в это время база находиться под доп.нагрузкой и еще и блокировки и дополнительные ожидания появляются.
Тут уже место и т.п. вторично, лишь бы высоконагруженную базу побыстрее отпустило.
Как вариант поднимать асинхронный AlwaysOn и снимать бэкап со второй реплики, а не с рабочего сервера. На время бэкапа будет отставние слейва от мастера, но потом догонит.
Сжатие на уровне строк полезно по факту только если много числовых (numeric) полей с нулями или небольшими значениями (при больших допустимых). Тогда все эти нули будут храниться компактно. Другие выгодные варианты придумать можно, конечно, но базовый, наверное, такой.
Сжатие на уровне страниц - если есть много повторяющихся (но не длинных строковых/бинарных) значений. Повторения могут быть частичными. Способ сжатия описан тут. Доступ к таким данным на чтение и запись дороже по CPU, но для таблиц с кучей похожих чисел и ссылками на другие записи (всеми типовыми способами: уидами, строками, числами, бинарными) жмутся очень хорошо и это часто даёт такой выигрыш при чтении/записи с диска, что становится оправданным. Даже для неплохих систем хранения.
Сжатие бэкапов явно алгоритм не описан, но судя по появлению в 2022 выбора между MS_XPRESS (по умолчанию) and QAT_DEFLATE (для аппаратного ускорения) и по некоторым другим признакам - штатный алгоритм сильно похож на обычный deflate - умеренно хорошо подходит для любых избыточных потоков.
Отсюда уже можно сделать все выводы данной статьи, но по другим соображениям :) Плюс есть всякие хитрозадые опции хранения типа sparse columns, column sets, columnstore indexes и другие. Плюс есть еще соображения разницы между Standard/Enterprise.
И есть еще куча граничных случаев. Так, например "таблица-лог" с большими сообщениями не будет нормально сжиматься ни rows, ни page, зато может в десяток раз сжаться в бэкапе. Таблица с большим количеством низкоселективных ссылочных полей будет отлично жаться в page, зато потом плохо в бэкапе. А может для конкретно случая лучше подойдёт columnstore.
Так что всё равно придётся смотреть по месту, экспериментировать и замерять.
MSSQL: сравниваем data compression и backup compression