Компании ежедневно генерируют большие объемы данных, но далеко не вся информация одинаково важна: со временем многие данные становятся менее востребованными, продолжая занимать дорогие и высокопроизводительные накопители (SSD, RAM). В результате хранение таких «холодных» данных обходится неоправданно дорого, поскольку потребность в постоянном доступе к ним минимальна.

Решение проблемы — технология охлаждения данных, которая предполагает перемещение редко используемой информации на более дешевые и емкие носители, то есть файлы остаются доступными, но перестают нагружать дорогие и быстрые устройства. Именно такой механизм охлаждения данных мы добавили в Tarantool DB 3.0.

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. В этой статье я расскажу, как именно мы реализовали механизм охлаждения и какие бизнес-выгоды могут получить компании при его использовании.

О Tarantool DB и точках роста

Традиционно Tarantool DataBase использовался в качестве транзакционной in-memory NoSQL СУБД с поддержкой схем, репликации, шардирования. Соответственно, изначально все данные хранились в RAM — это гарантировало максимальную скорость и производительность работы, но имело и обратную сторону: RAM стоит дорого, поэтому по мере роста объемов хранения TCO увеличивается пропорционально объему данных.

Вместе с тем практика показывает, что до 80% данных в БД используются редко. То есть хранить их в дорогой оперативной памяти зачастую просто нерационально. Понимая это, в рамках обновления Tarantool DB 3.0 мы решили добавить технологию, которая позволит разгрузить основные системы и сократить расходы на инфраструктуру при сохранении полного доступа к любым данным по требованию бизнеса. Так Tarantool DataBase 3.0 получил охлаждающий слой Cooling Tier и механизм Cooler.

Немного контекста

В Tarantool DataBase 3.0 добавлена поддержка Vinyl — встроенного движка хранения данных, разработанного специально для высокопроизводительных OLTP-приложений. В Vinyl в качестве структуры хранения применяется LSM-дерево (Log-Structured Merge Tree), благодаря чему он оптимизирован для быстрого чтения и записи данных, минимизации задержек и эффективной одновременной обработки большого количества запросов.

Чтобы интеграция была максимально рациональной, а движок полезен, в рамках поддержки Vinyl в Tarantool DataBase:

• реализован сценарий архивации данных через модуль cooler;

• улучшена поддержка Vinyl в модуле crud;

• добавлена документация по работе с Vinyl: примеры и рекомендации по настройке. 

На последнем пункте остановимся чуть подробнее.

Рекомендации по настройке Vinyl для Tarantool DataBase

В рекомендациях по настройке Vinyl мы выделили отдельный раздел с оптимальными параметрами для Tarantool DataBase. Так, рекомендовано:

• использовать только один индекс;

• назначать Vinyl.memory > 2G;

• следить за нагрузкой по тредам (vinyl.read_threads, vinyl.write_threads);

• в первую очередь настраивать vinyl.page_size — размер страницы, с которой работает Vinyl при записи и чтении с диска (дефолтные 8 Кб можно смело повышать).

Все рекомендуемые параметры определены опытным путем на основе нагрузочных тестов. 

Например, тест на запись 30 000 rps по одному таплу (tuples) размером около 500 байт показал, что увеличение размера страницы положительно влияет на производительность записи. 

Аналогично увеличение размера страницы дает прирост производительности и при точечных чтениях.

Также увеличение vinyl.page_size позволяет получить буст и в случае диапазонных чтений. 

Одновременно увеличение vinyl.page_size положительно сказывается и на объеме занимаемой памяти под индексы: чем больше страница, тем меньше памяти требуется.

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

Здесь можно видеть, что увеличение числа индексов приводит к заметному снижению производительности: при трех индексах она почти в 4 раза ниже, чем при одном.

Вместе с тем, поскольку кластера шардированные, а индекс оптимально использовать один, bucket_id в первичном ключе для модуля crud становится обязательным полем. 

Примечание: При построении первичного индекса оптимально сначала указывать bucket_id, а только после основные поля индекса. При этом для операций get, update и delete мы добавили в Crud возможность не указывать в первом ключе bucket_id, а записывать box.NULL, чтобы Crud сам его определял.

От контекста к сути

Как я уже упоминал ранее, не все данные одинаково полезны постоянно, а хранить всё в memtx дорого и неэффективно. Примечательно, что в Tarantool был движок Vinyl, с помощью которого можно было распределять данные по «температуре»: горячие данные оставлять в оперативной памяти, а холодные — переносить на диск без потери доступности. Но сложность была в том, что ранее при использовании Tarantool DB разработчикам приходилось вручную реализовывать логику архивации, в том числе писать фоновые скрипты для обхода namespaces, их фильтрации и переноса записей из Memtx на диск.

В Tarantool DB 3.0 мы исключили необходимость ручной настройки, добавив уровень охлаждения и Cooler — инструмент для охлаждения данных в Vinyl «из коробки», который работает в фоновом режиме, устойчив к сбоям и поддерживает MVCC.

Архитектурно Cooler состоит из двух компонентов:

• модуля cooler;

• роли cooler.

Остановимся на каждом.

Основные функциональные возможности модуля cooler

Модуль cooler предназначен для задания архивации в миграциях, выполняет DDL-операции по созданию спейса Vinyl, предоставляет параметры и статистику архивации.

При работе с cooler.API можно использовать разные методы, в том числе:

• cooler.set_func() — для создания функции для проверки условия архивации;

• cooler.setup() — для настройки архивации для memtx-спейса;

• cooler.resetup() — для создания vinyl-спейса с актуальным форматом;

• cooler.stats() — для получения статистики архивации (например, время выполнения текущего прохода, количество и объем просканированных данных, количество и объем архивированных данных, скорость архивации и ETA и другие);

• cooler.info() — для получения параметров архивации (например, количество кортежей в memtx- и vinyl-спейсах, информация об архивном vinyl-спейсе, имя хранимой функции с условием архивации, индексы архивации, количество перезапусков спейса).

Роль cooler

Роль cooler применяется для запуска и остановки фоновых задач охлаждения на доступных для записи инсталляциях. При этом роль поддерживает автоматическую обработку смены мастера в наборе реплик: если мастер теряет статус, задача на нем завершается и повторно запускается на новом мастере.

Роль cooler «под капотом» использует expirationd — модуль Tarantool DataBase, который позволяет контролировать время жизни кортежей в спейсе и обрабатывать кортежи, время жизни которых истекло. Подобное заимствование модуля обусловлено тем, что cooler фактически решает задачу expirationd.

У роли cooler есть несколько особенностей. Например:

• может быть задана только одна задача на каждый индекс спейса;

• задача запускается на узле, доступном для записи;

• при переходе узла в режим чтения задача завершается.

Конфигурация задач охлаждения основывается на параметрах expirationd. Среди основных из них:

• full_scan_time — время полного прохода по списку (чем больше время, тем дольше архивация, но меньше нагрузка на транспортный поток);

• tuples_per_iteration — количество кортежей итерации (чем больше tuples_per_iteration, тем быстрее выполняется архивация, но больше нагрузка на поток);

• start_key — стартовый ключ прохода;

• iterator_type — тип итератора.

Для наглядности рассмотрим, как конфигурация роли cooler выглядит на уровне кода. 

Сначала задаем сценарий миграции. Создаем пространство memtx space sessions. С помощью метода set_funk устанавливаем условия архивации для этого пространства, а методом setup запускаем процесс архивации. 

После задания условий архивации мы можем инициировать выполнение задачи с использованием конфигурации роли roles.cooler.

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

Далее следует ключевая секция expirationd, внутри которой определяются индексы для процесса охлаждения: первично и вторично по полю updated_at.

Таким образом, будут запущены две задачи охлаждения по каждому указанному индексу.

Результаты внедрения и потенциальная бизнес-ценность

Благодаря внедрению уровня охлаждения и механизма Cooler Tarantool DataBase получил возможность автоматически распределять данные по «температуре» доступа, например: 

• горячие данные (активные транзакции, последние 30 минут) — остаются в RAM;

• холодные данные (история транзакций) — хранятся в охлажденном сегменте.

Как результат, Tarantool DataBase с версии 3.0 получил преимущества гибридной реализации (RAM + диск в одном решении), в рамках которой предоставляет скорость горячих данных за счет использования RAM и оптимизацию затрат за счет автоматического охлаждения данных.

Теперь об эффективности внедренного механизма. В условиях постоянного роста данных компании обычно идут по привычному пути: расширяют инфраструктуру (например, докупают 50–100 дополнительных инстансов, чтобы все уместить в памяти). Это влечет прямой рост затрат на миллионы рублей в месяц.

Для оценки эффективности внедренного механизма охлаждения данных мы провели сравнение стоимости хранения при использовании ИТ-ландшафта, состоящего из 2 кластеров по 150 инстансов на 32 Гб RAM (общий объем — 9,6 Тб оперативной памяти) — с Cooling Tier и без него.

Так, изначально средняя стоимость эксплуатации подобной инфраструктуры — около 4,8 млн рублей в месяц (около 48 000 долларов в месяц). При использовании Cooling Tier анализ показал, что до 74% данных можно охладить на диск, разгрузив RAM. В результате можно снизить потребление RAM до 2,5 Тб (вместо 9,6 Тб) и экономить около 3,5 млн рублей в месяц, или около 42,6 млн рублей в год. То есть при росте объемов не придется масштабироваться, а текущий бюджет останется без изменений: вы не тратите деньги на новые инстансы, храните больше данных за те же деньги, сохраняете производительность для горячих данных.

Безусловно, реальное снижение TCO зависит от архитектуры, но потенциал очевиден.

При этом важно, что внедренный механизм:

• позволяет охлаждать данные без потери производительности для горячих данных (они остаются в RAM);

• совместим с текущими кластерами Tarantool DataBase;

• автоматизирует управление хранением.

Благодаря этому Tarantool DataBase становится не просто быстрой, но и умной базой данных, которую можно эффективно применять в большинстве сценариев работы с данными — в финансовых и e-commerce системах, для хранения медиаконтента и логов информационных систем, в ML (можно подключать ML прямо к охлажденным данным, не трогая боевой контур).