Классические базы данных в современных высоконагруженных сценариях быстро упираются в потолок: когда от одной системы требуются миллионы транзакций в секунду и тяжелые аналитические срезы по всей истории событий, традиционный стек просто не вывозит. Поэтому компании всё чаще переходят на in-memory HTAP-системы, которые объединяют OLTP- и OLAP-нагрузки под капотом и дают нужную скорость за счет того, что держат горячие данные в оперативной памяти (RAM).
Но для нагруженных продовых проектов это преимущество может быстро превратиться в архитектурное ограничение: горизонтальное масштабирование упирается в объем доступной RAM, а каждый новый сервер обходится кратно дороже дискового пространства. Вместе с тем автоматическое охлаждение данных может нивелировать такие издержки.
Меня зовут Екатерина Силецкая. Я старший менеджер продукта Tarantool Column Store (TCS) — in-memory HTAP СУБД от VK Tech для транзакций и аналитики в реальном времени. В статье расскажу на примере Tarantool Column Store, как работает механизм охлаждения в HTAP-системах и в каких сценариях может быть полезен.
Об in-memory HTAP и предпосылках для охлаждения
По данным Центра стратегических разработок (ЦСР), российский рынок СУБД в 2025 году достиг отметки в 101,9 млрд рублей (+13,9% к 2024-му). В том числе растет и сегмент in-memory HTAP-систем — баз данных, которые объединяют обработку транзакций (OLTP) и аналитику (OLAP) в едином контуре. Тренд на их внедрение во многом обусловлен возможностью держать активные данные максимально близко к ядру процессора: это обеспечивает миллисекундный отклик для смешанных нагрузок без необходимости постоянно перекачивать информацию между разными системами хранения.
Но здесь возникает два нюанса:
RAM стоит существенно дороже дискового хранилища, и хранить в нем всё просто нерационально (например, транзакции месячной давности, исторические логи, завершенные сессии).
Зачастую удалять исторические данные нельзя — например, их хранение может быть требованием со стороны регуляторов (финмониторинг, налоговые).
Таким образом нужен механизм, который позволит «выводить» часть данных из оперативной памяти, не снижая скорости доступа к той информации, которая нужна для мгновенной обработки «здесь и сейчас».
Процесс автоматического переноса устаревших записей из горячего хранилища (in memory) в холодное (диск) и называется охлаждением данных.
Следует различать охлаждение (cooling) и архивацию (archiving). Охлаждение — это перемещение данных на более медленный, но все еще онлайн-доступный носитель в рамках активной системы. Архивация же предполагает выгрузку данных в офлайн- или nearline-хранилище с латентностью доступа в часы, для долгосрочного хранения и соответствия регуляторным требованиям.
Для наглядности разберем, как это работает, на примере колоночной in-memory HTAP СУБД для транзакционно-аналитической обработки данных в реальном времени Tarantool Column Store.
Работа механизма охлаждения на примере Tarantool Column Store
Механизм автоматического охлаждения данных был добавлен в Tarantool Column Store (TСS) в марте 2026 года. А в июле вышел релиз TCS 1.3, в котором появилась функция охлаждения для шардированных данных.
В Tarantool Column Store запись всегда находится только в одном слое: либо в памяти, либо на диске. При этом СУБД выстраивает двухуровневую иерархию: слой памяти, RAM (быстрый, дорогой) и диск (медленный, дешевый), автоматически перемещая данные между ними по заданным правилам. Сам процесс перемещения данных из памяти на диск в Tarantool Column Store полностью автоматизирован.
Конфигурирование охлаждения производится на новой таблице — структура закладывается на этапе CREATE TABLE, то есть для миграции существующих данных требуется пересоздание таблицы.
Механизм охлаждения срабатывает на основе указанных политик TTL (Time-to-Live), которые определяют время жизни данных в горячем слое. При этом в реализации добавлена возможность задавать минимальный интервал запуска процедуры вытеснения — это позволяет настроить охлаждение под потребности клиента, и не делать вытеснение слишком часто, чтобы не создавать избыточную нагрузку на дисковую подсистему.
Создавайте решения на Tarantool
Ускоряйте цифровые сервисы и снижайте нагрузку на сore‑системы
Смещение происходит по следующему алгоритму:
Мониторинг возраста записей. Каждая запись в таблице получает временную метку. Фоновый процесс СУБД сканирует горячий слой, вычисляя записи, чей возраст превысил установленный лимит TTL (например, старше 24 часов). Сканирование производится с частотой в соответствии с выставленным параметром при конфигурации охлаждения.
Формирование пакета. Устаревшие данные не сбрасываются по одной строчке, так как это вызвало бы колоссальный деградационный эффект для дисковой подсистемы. Система собирает их в крупные пакеты.
Фиксация на диске. Блок атомарно записывается на диск в формате Parquet (Iceberg), после чего занимаемая им оперативная память очищается и возвращается СУБД для новых транзакций.
Мониторинг охлаждения
Для контроля над процессом охлаждения доступны метрики для мониторинга производительности и объема вытеснения. Они позволяют строить дашборды в Grafana и настраивать алерты.
Помимо метрик, система пишет в логи ключевые события каждого цикла охлаждения. Администратор может отследить:
Сколько раз сработал планировщик по расписанию (например, каждые 5 секунд).
Количество строк, которые фоновый процесс отобрал для выгрузки. Позволяет оценить объем работы за один цикл.
Сколько строк реально перенесено на диск. Если оно меньше предыдущей метрики, часть строк могла быть удалена или изменена после отбора — полезно для выявления гонок.
Время, затраченное на поиск устаревших записей в памяти и на запись в Parquet. Помогает диагностировать проблемы с производительностью диска.
Каждое событие фиксируется с меткой времени и числом затронутых записей. Посмотреть логи можно через стандартные механизмы Tarantool.
Специфика механизма охлаждения в Tarantool Column Store
Механизм охлаждения строится по единому принципу, но в разных in-memory HTAP-системах он может иметь свою специфику. Подобную обуславливает и текущая архитектура охлаждения Tarantool Column Store. Разберем некоторые аспекты.
Работа с неизменяемыми данными (append-only). Механизм спроектирован под паттерн append-only (добавления без перезаписи). Это подходит для исторических логов, транзакционных лент и потоковых событий, но не используется для таблиц, где постоянно обновляются существующие строки.
Однонаправленное перемещение данных. Текущая реализация предусматривает однонаправленное перемещение, это исключает сложные сценарии синхронизации данных и гарантирует, что логика охлаждения остается линейной и прозрачной. Если вам понадобились старые данные — они всегда доступны через SQL. Записи, попавшие в Parquet на диск, являются архивными для аналитики, их нельзя изменить или удалить средствами SQL. В дальнейшем в продукте появится функция прогрева данных..
Устойчивость к сбоям через снапшоты Iceberg. Процесс вытеснения защищен механизмом атомарной фиксации. Так, если во время записи блока на диск происходит отказ системы, механизм определяет рассинхрон между готовым файлом в Iceberg и метаданными СУБД. При следующей попытке запуска система выполняет откат (rollback) к последнему известному корректному снапшоту, предотвращая дублирование строк или потерю согласованности кластера. Эта логика реализована через синхронизацию снапшотов перед каждой операцией сброса данных на диск (flush).
-
Поддержка работы в шардированном режиме. Начиная с версии Tarantool Column Store 1.3, механизм охлаждения полноценно работает и в распределенном кластере — теперь можно создавать внешние тома (CREATE VOLUME) и таблицы с политиками TTL в конфигурации из нескольких шардов. При этом каждый узел управляет своим сегментом холодного хранилища независимо: при создании внешнего тома через координатора, он реплицируется на все узлы с использованием их уникальных идентификаторов, что исключает конфликты имен файлов. Кроме того, в режиме union сканирование учитывает не только данные на диске, но и записи во временном буфере, обеспечивая полную консистентность результатов запроса даже в процессе активной миграции данных между слоями хранения.
Сценарии применения механизма охлаждения
Механизм автоматического переноса данных востребован везде, где оперативная аналитика по свежим событиям соседствует с необходимостью хранить многолетнюю историю. На практике это позволяет бизнесу не увеличивать бюджет на инфраструктуру и сохранять высокую скорость работы сервисов.
Динамическое ценообразование в ритейле. Для оперативного пересчета цен магазинам критически важен доступ к данным о свежем спросе за последние часы или дни. Исторические данные за прошлые кварталы для этой задачи бесполезны, но удалять их нельзя — они необходимы отделу аналитики для выявления сезонных трендов. В таком сценарии охлаждение позволяет автоматически освобождать память под актуальную нагрузку: цены текущего дня остаются в RAM для мгновенного обновления витрины, а срезы прошлых сезонов уходят на диск.
Рекомендательные системы и машинное обучение. Сервисам с миллионами пользователей важно мгновенно реагировать на текущие клики и просмотры, чтобы формировать ленту «здесь и сейчас». Однако для периодического переобучения моделей ранжирования требуются исторические данные за месяцы. Если держать всю эту массу событий в RAM, система будет тратить ресурсы на обработку старой информации вместо обслуживания живых запросов. Автоматический перенос данных месячной и более давности на диск очищает горячую зону для актуальных взаимодействий, при этом дата-сайентисты могут продолжать строить выборки для обучения напрямую через SQL, не выгружая файлы вручную.
ERP-системы и управленческий учет. Оперативные отчеты должны строиться по свежим данным об отгрузках, остатках на складах и открытых накладных — задержки здесь недопустимы. Архивные же записи (закрытые периоды, завершенные финансовые годы) нужны бухгалтерам исключительно для аудита и подготовки налоговой отчетности пару раз в квартал — держать их в оперативной памяти неэффективно. Охлаждение переносит завершенные операции в дешевое хранилище, гарантируя, что работа кассира или кладовщика не замедлится из-за фоновой обработки миллионов строк исторического архива.
Пример работы охлаждения
Tarantool Column Store предлагает две стратегии доступа к данным под разные задачи.
Только горячее хранилище. Запрос ищет данные исключительно в памяти. Минимальная задержка (единицы миллисекунд), но холодные данные не видны. Идеально, где важно только «здесь и сейчас».
-
Горячее и холодное хранилище одновременно. Запрос обращается к обоим слоям параллельно. Система объединяет результаты из памяти и диска. Поддерживаются любые агрегации (MAX, MIN, COUNT, AVG, SUM) по всему массиву данных. Например, подходит для квартальных отчетов или аналитики по полной истории.
Чтобы разобрать, как строится работа в каждом из сценариев, рассмотрим применение механизма в рамках антифрод-системы банка, которая ежесекундно обрабатывает тысячи платежей на наличие подозрительных паттернов, и одновременно должна уметь строить отчеты за месяцы и годы. Возьмем несколько типовых сценариев на одной и той же таблице transactions.
Сценарий 1: онлайн-проверка платежа (AML)
Когда пользователь нажимает кнопку «Оплатить», у алгоритма есть доли секунды на анализ. Ему критически важны только самые свежие паттерны поведения (например, за 3 дня), а транзакции месячной давности никак не влияют на решение здесь и сейчас.
SELECT * FROM transactions WHERE status = 'suspicious' AND ts > now() - INTERVAL '3 days';
Чтобы добиться минимальной задержки, выставляется режим чтения skip. В этом случае Tarantool Column Store обращается исключительно к оперативной памяти (RAM), полностью игнорируя холодный слой. Ответ приходит за 1–2 мс. Поскольку запрос сам отсекает старые даты с помощью фильтра ts > ..., механизм охлаждения дополнительно гарантирует, что оперативная память не забивается историей: все лишнее уже переехало на диск и не участвует в поиске.
Сценарий 2: ежеквартальный отчет для ЦБ
Здесь задача меняется: нужно проанализировать весь массив данных за год, объединив свежие платежи из памяти и архив из Parquet.
SELECT count(*), sum(amount) FROM transactions WHERE ts > now() - INTERVAL '1 year';
Работа осуществляется в режиме union. Теперь Tarantool Column Store параллельно сканирует горячий слой (памяти) и холодный слой (Parquet в Iceberg). Например, система берет 3 миллиона строк из RAM и 100 миллионов с диска, объединяет их на лету и выдает агрегированный результат. Отчет строится за минуты, а не за часы — и без выгрузки данных во внешнее аналитическое хранилище вроде ClickHouse или Greenplum.
SQL-запросы во всех сценариях одинаковые. Меняется только стратегия доступа (skip/union). Никакого переписывания кода под разные слои — это решает администратор одной переменной сессии.
Что в итоге
Механизм охлаждения в in-memory HTAP-системах позволяет обеспечить баланс, при котором можно хранить терабайты данных без чрезмерных требований к ресурсам RAM, не снижая скорости доступа по горячим записям. Возможность автоматизировать этот процесс кратно повышает эффективность контроля и снижает нагрузку на инженеров — при корректной настройке данные автоматически перемещаются между быстрым (дорогим) и медленным (дешевым) слоями хранения строго по заданным политикам TTL. Весь процесс можно прозрачно контролировать с помощью стандартных метрик Prometheus.
Функция уже доступна в Tarantool Column Store, поэтому каждый может протестировать ее в рамках своего проекта, чтобы получить предсказуемые расходы на хранение, высокую производительность по горячим данным и уверенность, что система справится с ростом нагрузки без экстренных вложений в память.