@Meshko

Сжатие БД в MS SQL?

Поставлена задача каким-то способом высвободить свободное место на диске.

БД уже отшринкованы, встал вопрос - попробовать попользоваться функцией: compression.

У меня вопрос, как с помощью compression уменьшить размер БД? Это функция предполагает запускать compression для определенных таблиц? А если я хочу скомпрессировать всё сразу?
  • Вопрос задан
  • 154 просмотра
Пригласить эксперта
Ответы на вопрос 2
@rPman
Но при нынешних ценах на дисковое пространство попытка добыть пару лишних мегабайт сжатием - крайне неразумное занятие. Дополнительные процессорные ресурсы на него стоят куда как дороже.
люто плюсую.

Но если прямо очень нужно, то советую вместо сжатия средствами БД, попробовать сжать средствами файловой системы (например btrfs - zstd, 16 уровней сжатия), можно поиграть с разным размером кластера, что может сильно повлиять на результат... особенно если в базе данных соседние поля с одинаковыми данными, а движок их упаковывает независимо.

Скорость записи в базу данных на сжатом диске сильно упадет, особенно если делать большой размер кластера (так как это увеличивает степень сжатия), но вот скорость чтения, особенно с hdd, даже может подрасти (особенно при хорошей степени сжатия), но должно много всего совпасть.
spoiler
Можно придумать абсурдно дикую комбинацию файловых систем и bcache, когда быстрый несжатый диск ssd (который не жалко или с хорошим ресурсом на запись) выставлен как кеш к диску, который будет размещен на сжатом хранилище, типа cloop, в этом случае запись на медленный носитель будет отложена на потом, а данные будут быстро складываться на ssd кеш.. пока скорость поступления данных на запись в этом буфере не превысит скорость записи на сжатый носитель, конструкция будет работать очень эффективно (занимая ресурсы процессора само собой, но там скорее всего однопоточная реализация будет).

НАСТОЯТЕЛЬНО рекомендую файлы индексов не сжимать, за исключением случаев, когда они целиком и полностью влезают в оперативную память и запись в базу данных не производится.

ОБЯЗАТЕЛЬНОЕ тестирование всей конструкции на реальных данных перед запуском в продакшен, иначе можно получить проблему, и конечно же бакапы, без них ничего делать даже не начинай.

p.s. наилучшее сжатие можно получить, если грамотно его реализовать на стороне самого приложения, ведь его разработчик знает, где какие данные как лежат, как их можно эффективно перераспределить и главное, есть библиотеки типа того же zstd, когда можно держать несколько словарей для сжимаемых данных, специально собранных под свои наборы данных,.. отличный пример сжатие xml/json файлов, где теги/атрибуты могут занимать до 90% пространства,.. и при маленьком размере сжимаемого куска, словарь на них будет в каждом куске свой.. а вот общий словарь для всего пакета файлов позволит на порядок сократить их объем.

p.p.s. само собой, замена xml/json на правильно созданный protobuf исключит эту проблему в зачатке
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Я просоединяюсь к совету выше. На тему того что самое эффективное уплотение информции
можно сделать на уровне разработки приложения.

Я-бы предложил не сжимать всю базу а проанализировать, какие таблицы и какие поля занимают
80%
всего пространства. (Процены я взял с головы по принципу Паретто. Вы можете взять любой
процент. Можно 90 или 70 не суть важно. Важно чтобы не закапыватья м мелочах.)


Из опыта других БД. (Не MS-SQL). Часто бывало что потребителем места были BLOB-поля где
лежали какие-то несуразные и никому не нужные документы. Аттачменты. Картинки. Копии
email из переписок с пользователем и многое другое. Были ситуации когда причиной роста
БД были старые архивные записи в таблице которые почему-то были забыты. Они должны
были удаляться но из за бага не удалялись.

Хорошая практика в данном случае - убрать из БД все длинные текстовые документы
или положить их в gzip
на уровне самого приложения например. Обычно такие поля
не участвуют напрямую в операциях OLTP и их сжатие ни на что особо не влияет.

Почти все современные БД имеют очень хорошую плотность информации на мегабайт
и если админ что-то там шринковал или уплотнял - то это носит временную меру. Через
некоторое время БД возвращается к той плотности как и была раньше вследствие
updates например.

По поводу ROW level/block level сжатия. Я не специалист в MS_SQL, но обычно это надо
предварительно тестировать под нагрузкой на PROD для всех DBMS в общем то.
Велика вероятность падения производительности а это, сами понимаете слишком
большая цена за экономию. И диски в наше время значительно дешевле скажем чем 10 лет назад.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы