Как мы сжимаем данные в больших проектах

Привет! Меня зовут Александр Кленов, и я работаю в Tarantool. В апреле вышел Tarantool 2.10 Enterprise Edition – обновленная версия платформы in-memory вычислений. В версии 2.10 появилось несколько новых функций, о которых уже немного рассказывали на Хабре ^[1]. 

В этой статье я хочу подробнее остановиться на одной из фичей — сжатии данных в оперативной памяти. Далее я расскажу, как ей пользоваться, что может, а чего не может данный механизм, как его применять и какие существуют особенности.

Как включить сжатие

Все просто — нужно указать в настройках поля, что его надо сжимать: compression = '<вариант>'.

Доступно два варианта сжатия:

• zstd,

• lz4.

Например:

local space = box.schema.space.create(space_name, { if_not_exists = true })
space:format({
    {name = 'uid', type = 'string'},
    {name = 'body', type = 'string', compression = 'zstd'},
})

Если это не новый, а существующий проект с данными, понадобится также вызвать фоновую миграцию:

box.schema.func.create('noop', {
    is_deterministic = true, body = 'function(t) return t end'
})

space:upgrade{func = 'noop', format = {
    {name = 'uid', type = 'string'},
    {name = 'body', type = 'string', compression = 'zstd'},
}}

Подробнее смотрите в документации ^[2]

Каких результатов можно добиться за счет сжатия?

Итак, мы подключили фичу. Давайте посмотрим, что хорошего она может нам дать. В качестве примера возьмем реальный проект – данные крупного телеком-оператора. Это 100 тысяч  различных JSON-документов общим объемом 316 МБ.

По очереди мы применим разные варианты сжатия. CPU в нашем случае = 3,6 ГГц. Для лучшего сравнения методов добавим сжатие с помощью внешней библиотеки ZLIB.

Тестирование показало следующие результаты:

* Внешняя библиотека ZLIB

Исходник теста можно посмотреть на Гитхабе ^[3].

Ключевой вывод – все три метода работают по-разному. ZSTD сжимает эффективно, но медленно и при этом достаточно быстро распаковывает документы. LZ4 – быстро сжимает и разжимает, но коэффициент сжатия уступает остальным методам. Сжатие с использованием ZLIB сопоставимо с результатами ZSTD и при этом не слишком медленно, однако проседает скорость разжатия.

Сжатие в кластере

В реальных продуктовых проектах экземпляры Tarantool разделены по ролям. Для нашего примера важно выделить две:

• маршрутизатор (router),

• хранилище (storage).

Сжатие данных в кластере – не такая линейная задача, как сжатие одного узла. Это можно организовать разными способами в зависимости от места сжатия и разжатия. У каждого способа есть свои плюсы и минусы. Рассмотрим три варианта.

Вариант первый — быстрый эффект

Сжимаем и разжимаем в хранилище. Этот вариант обеспечивает описываемая в статье функциональность. Подходит, если нужно быстро и при ничтожных изменениях проекта высвободить кучу места.

Звучит здорово, но это вызывает дополнительную нагрузку на ЦП хранилища и его замедление. Более того, каждая реплика будет повторять то же самое сжатие. Как следствие — снижение производительности кластера. Хранилище со встроенным упаковщиком дороже масштабировать. То есть вместо одного дополнительного упаковщика придется поставить рядом хранилище с упаковщиком.

Посмотреть пример, как сделать, можно здесь:

Локальная переменная enable_zlib в роутере должна иметь значение = false. В хранилище в 11-й строке нужно указать тип сжатия.

Такой вариант подойдет – если срочно нужно освободить место. То есть как временное решение. Если нагрузка позволяет – это может быть постоянным решением. Это про быстро и дешево.

Если вы хотите сохранить производительность кластера, потребуется больше усилий.

Вариант второй — максимальная производительность

Сжимаем и разжимаем на роутере. Это дает больше производительности, но встроенное сжатие никак не поможет — придется подключать внешнюю библиотеку и реализовывать дополнительную логику работы с ней. В мастер и на реплики тогда будут попадать уже упакованные данные.

В качестве примера можно использовать пару роутер ^[4]-хранилище ^[5], приведенную выше. Только переменная enable_zlib в роутере должна иметь значение = true. В хранилище тип сжатия не указываем.

Плюсы:

• не нагружаем хранилище;

• уменьшаем трафик между роутером и стораджем;

• легче масштабируем — ставим нужное количество роутеров с упаковщиком до требуемой производительности.

Минусы:

• нужно реализовать логику упаковщика на роутере;

• появляется задержка на роутере на сжатие и распаковку.

Если хочется большего, то можно управлять сжатием в виде отдельной роли. Это позволит регулировать число роутеров отдельно от числа инстансов сжатия. Более гибко регулировать утилизацию ресурсов. В этом случае можно рассмотреть третий вариант.

Вариант третий — ленивое сжатие

Сжимаем на отдельном экземпляре, разжимаем на роутере. То есть пишем в хранилище как есть с признаком «не упакован». Далее реализуем отдельную роль «упаковщик», которая проходит по мастер-хранилищам и упаковывает все не упакованное. Если данные поступают быстро и надо паковать быстрее — добавляем ещё экземпляры упаковщика. На реплики будут попадать уже упакованные данные.

Посмотреть пример реализации, чтобы понять идею, можно здесь ^[6].

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

Плюсы:

• нет задержки на роутере на запись данных;

• процесс сжатия масштабируется максимально выгодно;

• меньше экземпляров кластера;

• не нагружаем хранилище как в первом варианте.

Минусы:

• дополнительный трафик в кластере — между хранилищем и упаковщиком;

• некоторая дополнительная нагрузка на хранилище — плюс по одной операции чтения и записи;

• нужно реализовать отдельную роль — упаковщик;

• нужно реализовать логику распаковки на роутере.

Это может быть полезно:

• если вы хотите быстро записывать данные - сразу записывать не сжимая;

• регулировать скорость сжимания - либо уменьшить число инстансов, либо наоборот - увеличить, и через это более гибко расходовать свои ресурсы.

Эффект переноса сжатия на роутер

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

Реализация стенда:

• Реализация роутера ^[4].

• Реализация хранилища ^[5].

• Модуль для нагрузочного обстрела на запись модуль ^[7]. И вспомогательный модуль для генерации данных ^[8].

Максимальная продолжительность испытаний выбрана 30 секунд. Потому, что с одной стороны не слишком долго ждать выполнения тестов, с другой – этого достаточно для тестирования нагрузки.  За это время мы генерируем 100 тысяч запросов на запись на роутер от лица 10 виртуальных пользователей. Консольный вывод результатов можно посмотреть здесь ^[9]. Ниже результаты сведены в одну таблицу.

Итак мы видим, что по ключевым параметрам, таким как число запросов в секунду (RPS), задержке (http_req_duration) и общему времени выполнения запроса (iteration_duration) - вариант со сжатием на роутере выгодно отличается от сжатия в хранилище.

В первую очередь это происходит потому, что сжатие методом ZSTD происходит дольше, чем методом ZLIB. Также свой вклад вносит то, что данные от роутера до хранилища идут уже сжатые и таким образом в само хранилище нужно записывать меньше данных. Также плюсом идёт то, что не нужно нагружать хранилище сжатием.

Выводы

Tarantool развивается и обрастает новыми фичами. Встроенный в 2.10EE механизм сжатия полезен, но не является панацеей. Порядок действий зависит от конкретной ситуации — отсюда и возникают рекомендации по применению.

Если у нас нет желания или возможности использовать внешнюю библиотеку - мы можем использовать встроенное сжатие методом LZ4. Данный метод позволяет высвободить 40% места почти без просадки по RPS (6351 LZ4 против 7076 без сжатия). При этом включается фактически «одной галочкой» — на мой взгляд весьма неплохо.

Если требуется жать сильнее, или производительнее, или дешевле — нужны дополнительные усилия, которые описаны выше.

Скачать Tarantool можно на официальном сайте ^[10], а получить помощь — в Telegram-чате ^[11].