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