Что означают горячие и холодные данные, как частота чтения влияет на место хранения и почему дешёвый архив не всегда экономит деньги.
Одна компания, разные сроки обращения
Сервис хранит сегодняшние заказы и историю заказов за несколько лет. К первым обращаются постоянно: сотрудники уточняют доставку, покупатели проверяют статус, отчёты обновляются. Старые записи тоже нужны, например для редкой проверки, но открывают их значительно реже. Держать оба массива в одинаковых условиях не всегда разумно.
Слова «горячие» и «холодные» описывают прежде всего частоту обращения. Это не оценка важности данных: редкий архив может быть критичным для бизнеса. Вопрос в том, как быстро требуется получить запись и сколько будет стоить постоянное хранение вместе с последующим чтением.
Как устроен выбор уровня
Горячим данным нужен частый доступ. Холодные обычно размещают там, где хранение может обходиться дешевле, но чтение связано с дополнительными расходами или другими ограничениями. Между ними бывают промежуточные уровни. Конкретные цены и условия зависят от поставщика и меняются, поэтому универсального порога по возрасту файла нет.
Например, в документации Google Cloud классы хранения различаются минимальным сроком хранения и платой за извлечение. Microsoft описывает похожий выбор между затратами на хранение и доступ к объектам. Эти правила относятся к конкретным облачным продуктам, а не ко всем базам данных сразу.
Условный пример без прайс-листа
Представим магазин с миллионом файлов заказов. Каждый день сотрудники открывают недавние записи, а документы двухлетней давности просматривают только при отдельных обращениях. Если старые файлы перенести на подходящий уровень, ежемесячное хранение может стать дешевле. Но если маркетинговая команда каждую ночь перечитывает весь архив, расходы на доступ меняют расчёт.
Такую выгоду нельзя вычислить только по размеру архива. Нужно знать, сколько раз данные читают, как долго они должны храниться и требуется ли мгновенный ответ. Даже «старый» год может стать горячим перед аудитом или сезонным анализом.
Холодное не значит недоступное
Перенос в более дешёвый класс не равен удалению. Однако способ получения данных и время ожидания следует проверить заранее: в разных сервисах и классах они различаются. Команда должна знать, какие отчёты продолжают работать сразу, а какие потребуют отдельного восстановления или дополнительных затрат.
Также не стоит путать уровни доступа с озером и хранилищем данных. Озеро и хранилище описывают организацию и назначение данных, а «горячее» и «холодное» — режим обращения и связанные затраты. Один и тот же тип данных может проходить разные уровни по мере старения.
Что согласовать перед переносом
Начните с конкретного набора: кто им пользуется, как часто и сколько времени допустимо ждать ответа. Затем проверьте требуемый срок хранения, правила удаления, стоимость чтения и возможного раннего переноса. Отдельно оцените редкие, но важные сценарии: проверку спорного заказа, восстановление после ошибки, годовой отчёт.
Решение об уровнях хранения — часть работы архитектора данных. Если хочется разобраться, как проектируют такие системы в целом, посмотрите программу «Архитектор данных». Публичная карточка курса описывает обучение; конкретные условия хранения для вашей компании придётся выбирать по её нагрузке.
Как не ошибиться с автоматическим переносом
Многие сервисы позволяют переводить объекты между уровнями хранения по правилу возраста или частоты доступа. Автоматизация удобна, когда поведение набора предсказуемо. Но правило «через месяц всё в архив» может навредить отчёту, который регулярно перечитывает прошлый квартал. Перед включением перехода полезно изучить фактические обращения за несколько периодов.
Уточните также, кто сможет вернуть данные в активную работу и как команда заметит неожиданное увеличение затрат на чтение. Перенос должен следовать задаче пользователей, а не только желанию снизить стоимость хранения на бумаге.
Курс по теме
Подходящая программа для дальнейшего изучения темы: Архитектор данных.
