Объёмы данных в корпоративных системах растут экспоненциально, и вместе с ними растут и затраты на инфраструктуру. Хранить информацию в оперативной памяти в разы дороже, чем на диске, хотя исследования показывают: до 80% записей в БД используются редко или вовсе не востребованы. Если понимать разницу между горячими и холодными данными и грамотно проектировать схемы хранения, можно сильно сократить расходы без потери производительности. В этой статье разберёмся, что такое горячие и холодные данные, как разгрузить горячие участки БД и какие практики хранения применять на практике — в том числе на примере горячего и холодного хранения в Tarantool DB.

Что такое горячие и холодные данные

Термины «горячие» и «холодные» данные описывают частоту обращения к информации и требования к скорости доступа.

Горячие данные — это информация, к которой система обращается постоянно:

• активные пользовательские сессии,
• текущие транзакции и заказы,
• кэшированные результаты аналитики,
• данные за последние 30 минут–24 часа.

Горячие данные требуют минимальной задержки при обращении — миллисекунды или микросекунды. Поэтому их размещают в оперативной памяти (RAM) или на быстрых SSD-накопителях.

Холодные данные — это редко запрашиваемая информация:

• история транзакций старше 30–90 дней,
• архивные логи и отчёты,
• резервные копии,
• данные для compliance и аудита.

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

Между этими категориями выделяют тёплые данные — информацию со средней частотой обращения. Например, заказы за последнюю неделю: они уже не горячие, но ещё востребованы для отчётов.

Как хранение данных в оперативной памяти влияет на стоимость

Оперативная память — самый быстрый и одновременно самый дорогой уровень хранения. В облаке или на собственных серверах RAM обходится в 10–50 раз дороже дискового пространства:

• 1 ГБ оперативной памяти: ~600–1200 ₽/мес.
• 1 ГБ SSD-диска: ~50–100 ₽/мес.
• 1 ГБ обычного диска или облачного архива: ~5–20 ₽/мес.

Если база весит 10 ТБ, полное размещение в памяти съедает 5–10 млн ₽/мес. Но стоит перенести 80% холодных данных на диск — и ежемесячный счёт за память падает до 1–2 млн ₽/мес.

Реальный кейс. Тестирование механизма охлаждения данных во внутренних проектах на Tarantool DB показало: потребление оперативной памяти сократилось с 9,6 ТБ до 2,5 ТБ после переноса 74% данных на дисковое хранилище. Экономия получилась около 3,5 млн рублей в месяц.

Проблема в том, что большинство систем по умолчанию держат все данные в памяти или на быстрых накопителях. Архитектура получается проще, но за это приходится переплачивать. Но выход есть — классифицировать данные по «температуре» и выстроить многоуровневое хранение.

Как разгрузить горячие точки в БД

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

Такое происходит, потому что существуют следующие явления:

• Товары-бестселлеры или профили знаменитостей, к которым тысячи пользователей обращаются в одно и то же время.
• Временные данные, когда все запросы направлены к сегодняшним записям, а вчерашние при этом никому не нужны
• Глобальные счётчики, например, поле «количество просмотров», которое обновляется при каждом визите и постоянно блокирует одну и ту же строку
• Последовательная нумерация — новые записи всё время добавляются в одно место индекса, и оно превращается в узкое горлышко

К счастью, есть несколько способов разгружать горячие точки.

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

Кэширование горячих данных. Часто читаемые данные можно вынести в отдельный быстрый кэш — и основная база сразу вздохнёт свободнее. Популярные решения для этого: Redis, Memcached и как раз Tarantool. Кэш хранит копии востребованных записей и отдаёт их напрямую, без обращения к диску.

Оптимизация структуры таблиц. Правильный выбор типов данных способен сократить размер таблиц на 30–50%. Чем меньше данных — тем быстрее чтение и тем меньше нагрузка на память и диск.

Пакетная обработка обновлений. Массовые изменения создают дополнительную нагрузку: база вынуждена сохранять историю версий каждой записи. Если обновлять данные небольшими порциями с паузами, система успевает почистить за собой и не захлёбывается.

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

Теперь перейдём от разгрузки точек к оптимизации горячих и холодных данных в целом.

Основные подходы к оптимизации горячих и холодных данных

Существует несколько стратегий хранения данных в зависимости от архитектуры системы и требований бизнеса.

Многоуровневое хранение (Tiered Storage)

Данные автоматически перемещаются между уровнями хранения по заданным правилам:

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

Архивирование холодных данных

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

Базы данных с гибридным хранением

Современные СУБД поддерживают двухуровневую архитектуру «память + диск» в рамках одного продукта. Одной из таких СУБД является Tarantool DB. Она содержит встроенный механизм Cooler для автоматического охлаждения. Cooler работает в фоновом режиме и переносит данные между слоями по заданным условиям — например, по времени создания или последнего обновления записи. При этом он устойчив к сбоям, поддерживает MVCC и корректно обрабатывает смену мастера в наборе реплик: если текущий мастер теряет статус, задача охлаждения автоматически перезапускается на новом.

Потоковая репликация изменений

Все изменения в основной базе автоматически передаются в холодное хранилище или озеро данных. Это происходит в реальном времени, без влияния на производительность основной системы.

Оптимизация горячего и холодного хранения в Tarantool DB

Tarantool DB реализует встроенный механизм cooling, который автоматически разделяет горячие и холодные данные внутри одной системы, без необходимости вручную писать скрипты или создавать отдельную инфраструктуру.

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

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

Результаты внедрения

Ключевое преимущество очевидно: скорость работы с горячими данными не изменилась, при этом расходы на инфраструктуру сократились почти в 4 раза.

Преимущества и бизнес-ценность охлаждения данных

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

Финансовые преимущества. Перенос 70–80% данных на диск сокращает расходы на память в 3–5 раз. Вслед за этим можно пересмотреть конфигурацию облачных серверов и перейти на машины с меньшим объёмом RAM — счёт за инфраструктуру снижается ощутимо. Отдельный бонус для корпоративных систем: некоторые базы данных лицензируются по объёму используемой памяти, так что меньше памяти означает ещё и меньше лицензионных платежей.

Технические преимущества. Меньше данных в памяти — быстрее создаются резервные копии, потому что системе не нужно сбрасывать на диск гигабайты оперативного состояния. Горячие данные, сосредоточенные в компактном «активном слое», проще распределять между серверами при масштабировании. А снижение нагрузки на память напрямую влияет на стабильность: сбои из-за её нехватки случаются реже.

Операционные преимущества. При правильной реализации приложение вообще не замечает, что данные разделены: код остаётся прежним, а система сама решает, откуда отдавать запись. При этом правила охлаждения можно настраивать по-разному для разных типов данных — например, сессии охлаждать через час, а транзакции через месяц. Холодные данные при этом никуда не исчезают: они доступны и хранятся дольше, что упрощает соответствие требованиям регуляторов и аудиторов.

Когда охлаждение данных особенно эффективно

Риски и ограничения

Стратегия охлаждения данных работает, но у неё есть и обратная сторона.

Самое очевидное ограничение — увеличение времени ответа на запросы к холодным данным. Если горячие данные отвечают за микросекунды, то обращение к SSD занимает уже 5–10 мс, а чтение с обычного диска или из архивного облачного хранилища может растянуться до нескольких секунд. Для большинства аналитических запросов это приемлемо, но для интерактивных сценариев нужно тщательно продумывать границу охлаждения.

Внедрение тоже требует усилий: прежде чем что-то охлаждать, нужно разобраться, какие данные действительно можно перенести на диск без ущерба для пользователей. Ошибиться здесь легко — и тогда вместо экономии получится деградация производительности в самый неподходящий момент.

Наконец, у облачных архивных тарифов есть свои сюрпризы:

• Провайдеры берут отдельную плату за извлечение данных из холодного хранилища.
• Большинство архивных тарифов предусматривают минимальные сроки хранения — от 30 до 180 дней — и штрафуют за досрочное удаление.

Это стоит учитывать при проектировании политики хранения.

Рекомендации по внедрению

Чтобы внедрение не превратилось в эксперимент над продакшеном, лучше двигаться поэтапно.

1. Анализ. Посмотрите, как реально распределяется «температура» ваших данных. Скорее всего, окажется, что большая часть записей давно никому не нужна — и именно здесь скрыт основной потенциал для экономии.
2. Пилотный проект. Выберите одну таблицу или один сервис и запустите пилот: так проще контролировать риски и оценить эффект до того, как менять всю архитектуру.
3. Мониторинг. После запуска важно не отпускать ситуацию: следите за скоростью ответов и за тем, как часто система всё же обращается к холодным данным.
4. Корректировка. Если холодные записи запрашиваются чаще, чем ожидалось, — порог охлаждения стоит сдвинуть. Настройка правил должна вестись по результатам реальных наблюдений, а не по интуиции — это ключ к тому, чтобы система работала предсказуемо.

Заключение

Разделение данных на горячие и холодные — базовая практика оптимизации хранения в современных системах. До 80% информации в типичной базе данных используется редко и не требует дорогостоящего места в оперативной памяти.

Классификация по частоте доступа — это первый и самый важный шаг: без неё невозможно понять, где именно система переплачивает. Кэширование горячих данных и архивирование холодных снимают нагрузку с основной базы, а гибридные СУБД вроде Tarantool DB делают реализацию многоуровневого хранения значительно проще — не нужно строить отдельную инфраструктуру или переписывать логику приложения. При правильной настройке политик охлаждения экономия достигает 3–5 раз.

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