Сжимать или не сжимать: как FTData работает со сжатием данных

Назначением любой СУБД является централизованное управление данными, в том числе их хранение. Любое хранилище имеет тенденцию к росту, и на горизонте десятилетий транзакционные базы данных растут до десятков и сотен терабайт. В условиях развития искусственного интеллекта накопление структурированных данных становится особенно востребованным.

И с самого появления первых коммерческих СУБД разработчики начали задумываться о сжатии данных. Первыми методами были удаление незначащих нулей и устранение пробелов, далее начали применяться и совершенствоваться алгоритмы сжатия.

В настоящее время есть несколько подходов к сжатию данных в транзакционных СУБД. Первый и наиболее часто применяемый — сжатие на уровне файловой системы (ZFS, Btrfs, NTFS и др.). Метод отличается тем, что сжимается все, что сохраняется на диск, и из этого следуют основные недостатки: бесполезность или вред для уже сжатых данных, риски для целостности и сложности восстановления. Еще один — предоставление администратору баз данных возможности выбрать таблицы, индексы и другие объекты базы данных, подлежащие сжатию. Такой подход предлагает большую точность в настройке сжатия под конкретную задачу.

В СУБД FTData реализован второй вариант сжатия. Администратору предоставляется возможность выбирать не только сжимаемые объекты, но и алгоритмы сжатия, а также трансформировать объекты, используя различные алгоритмы и степени сжатия. В качестве первых результатов от реализации сжатия удалось существенно увеличить скорость резервного копирования и восстановления. Разные алгоритмы сжатия и количество потоков дают разные показатели скоростей резервного копирования и восстановления, но общий итог в том, что при наличии свободных вычислительных ресурсов (менее 30% на тот момент) скорость резервного копирования и восстановления пропорциональна степени сжатия.

Это был тест на относительно небольшой базе данных размером 4,84 ТБ. Далее была проведена проверка базы данных большего размера — 62 ТБ, и результаты полностью повторились: аналогичная утилизация ресурсов процессора, степень сжатия и увеличение скорости резервного копирования и восстановления.

Небольшое увеличение скорости резервного копирования в этом тесте — результат более корректной настройки сетевых адаптеров системы хранения данных.

Сокращение времени при резервном копировании прогнозируемо. Но как поведут себя прикладные системы с применением сжатия? На этот вопрос ответ получен в рамках публичных испытаний на полигонах индустриального центра компетенций «Финансы».

Условия испытаний СУБД FTData и автоматизированной банковской системой ЦФТ-Банк полностью повторяли описанные в предыдущей статье: те же сервера баз данных и приложений, версия СУБД, программа и методика испытаний и инструмент нагрузочного тестирования, за исключением включения режима сжатия базы данных. Вместо исходного размера 76 ТБ, база данных стала занимать 26 ТБ.

Результаты испытаний можно рассмотреть в двух проекциях.

Во-первых, сравнить производительность СУБД FTData с применением и без применения сжатия:

Результаты показывают, что, вопреки ожиданиям, сжатие приводит к увеличению производительности во всех проведенных тестах!

Утилизация ресурсов сервера СУБД при этом практически (<3% в среднем) не изменилась:

А во-вторых, сравнить поведение СУБД FTData с другой СУБД, проходившей аналогичные испытания с применением сжатия ранее:

И в этом сравнении СУБД FTData не так значительно, как в прошлой статье, но опережает другую СУБД по производительности.

Как зафиксировано в п. 6 итогового протокола испытаний АБС ЦФТ-Банк и СУБД FTData с применением сжатия: «По результатам нагрузочного тестирования установлено, что значения всех зафиксированных метрик демонстрируют положительную динамику по сравнению с результатами теста АБС «ЦФТ-Банк» на несжатой версии СУБД ФТДата от 26.05.2026. Полученные данные свидетельствуют о более высокой производительности СУБД ФТДата при использовании механизма сжатия». То есть ответ на вопрос заголовка статьи дан однозначно. Команда разработчиков СУБД FTData уже ведет интеграцию нескольких альтернативных алгоритмов сжатия, что даст пользователям возможность найти собственную границу между степенью сжатия и производительностью.