Хранение всего объёма данных в одном месте удобно, но часто нерационально из-за стоимости хранения, ограничений масштабирования баз данных, усложнения администрирования и других издержек. Поэтому лучшей практикой при работе с большими объёмами данных является управление жизненным циклом информации (Information Lifecycle Management, ILM) с применением соответствующих методологий и инструментов для автоматизации процесса.
В Postgres Pro Enterprise 17 появилась возможность использовать ILM благодаря расширению pgpro_ilm, которое позволяет переносить редко используемые данные в более дешёвое хранилище по аналогии с функцией ILM в Oracle.
Проблема больших баз данных и их решение
Данные — один из важных активов любой компании. Но по мере роста компании объем генерируемых данных непрерывно увеличивается.
Если на начальных этапах для хранения информации достаточно небольшой базы данных, которую легко использовать и администрировать, то по мере разрастания БД, компании, как правило, сталкиваются с типовыми проблемами:
стоимость хранения обратно пропорциональна времени доступа к данным;
быстрых накопителей мало, и они дорогие;
актуальность данных и активность работы с ними со временем снижается;
активные операции над данными зачастую производятся только в течение относительно короткого времени (недель или месяцев) жизни данных;
со временем самый большой объем начинают занимать исторические данные, которые может быть нерационально хранить на быстрых накопителях.
Вариант с единым хранилищем для всех данных, как часто используемых, так и исторических, не самый рациональный. Поэтому бизнес вынужден искать компромисс между скоростью доступа и объёмом данных, а также способы минимизировать существующие издержки. Но когда данных и таблиц становится очень много (сотни и тысячи таблиц и секций), то хотелось бы иметь какой-то инструмент, некую большую кнопку, которая позволила бы автоматизировать этот процесс в соответствии с политиками и регламентами, применяемыми в компании.
Примечание: Чтобы понять всю суть описанных проблем, можно рассмотреть простой бытовой пример. Допустим, у вас есть гардеробная, куда вы складываете все свои вещи. В ней есть удобные полки, которые легко доступны, но их мало. Постепенно количество вещей увеличивается и рано или поздно придётся увеличивать гардеробную, поскольку количество старых и малоиспользуемых вещей со временем растет. Чтобы этого избежать, часть старых вещей надо вынести, например, в гараж или отвезти на дачу. Так они будут всё равно доступны, но не будут неоправданно занимать ограниченное место.
Что такое Information Lifecycle Management
Information Lifecycle Management — концепция управления информацией, основанная на разделении данных по критерию их ценности для бизнеса и автоматизации управлении ими с учетом политик и регламентов принятых в организации. Она помогает понять, какие данные нужны в оперативном доступе, какие могут понадобиться, но их допустимо вынести на медленные носители, а от хранения каких в оперативной базе данных можно отказаться, чтобы освободить место для новой, актуальной информации.
Примечание: Например, интернет-магазин ежедневно обрабатывает большие объёмы данных о заказах клиентов: текущие заказы и недавние покупки крайне ценны для оперативной деятельности и требуют быстрого доступа, поэтому хранятся на высокопроизводительных носителях; в то же время исторические данные о заказах, сделанных несколько лет назад, уже не столь актуальны для ежедневных операций и, хотя могут понадобиться для аналитики или отчётности, нет необходимости держать их там же где и оперативные данные — с помощью ILM эти данные можно перенести на более медленные и экономичные носители, освобождая ресурсы для актуальной информации и снижая затраты на хранение; данные, утратившие ценность и допустимые к удалению по политике компании и законодательству, могут быть архивированы или удалены, что позволяет эффективно управлять информацией на протяжении всего её жизненного цикла и поддерживать высокую производительность систем.
ILM подразумевает разделение данных на четыре основные группы:
Active. Это данные, которые часто меняются (OLTP) и для них характерны случайные чтения. Например, это может быть таблица финансовых транзакций текущего месяца.
Less Active. Данные, которые меняются редко (OLTP, OLAP), а их чтения преимущественно сканирующие по колонкам. Пример таких данных — история финансовых транзакций текущего квартала или года.
Historical. Данные, которые не меняются (OLAP). Редко выполняются сканирующие чтения по колонкам. К таким данным можно отнести, например, историческую информацию о финансовых транзакциях за предыдущие годы.
Archive. Архивные данные, которые хранят, как правило, только для соблюдения требований регуляторов.
Исходя из ценности данных и их востребованности, для каждой категории рационально выбирать свой тип носителя. Например:
активных данных зачастую относительно мало. Их можно расположить на дорогих, но быстрых NVMe-носителях;
менее востребованные данные рационально переносить на более дешевые носители — например, на классические SSD;
исторические данные оптимально переносить на HDD и/или хранить в сжатом виде;
для архивных данных достаточно простых и дешевых отчуждаемых носителей.
Примечание: В pgpro_ilm в настоящее время нет возможности вынести данные на отчуждаемые носители, такие как ленты.
Хватит лирики и теории, перейдем к деталям нашей реализации управления жизненным циклом информации. В pgpro_ilm участвует три сущности:
объект (таблица или секция), над которым совершают действие;
условие, от которого зависит выполняемое действие — например, «данные долго не менялись» или «данные давно никто не читал»;
действие — например, данные можно перенести на другой носитель или сжать.
С помощью них можно настроить правила в зависимости от потребностей и стратегии ILM в организации, например так:
Сначала, менее активные данные переносятся в табличное пространство, расположенное на более дешевых дисках, а после того, как данные переходят в категорию исторических, они переносятся в табличное пространство, расположенное на дешевых дисках большой емкости.
Примечание: Правила обрабатываются в порядке убывания периода. Это сделано специально, потому что логично сначала обработать самое «старое» правило: если оно сработало, то все остальные правила уже нет смысла обрабатывать.
Обработка условий
Для корректного использования ILM нужна статистика обращения к данным — без этого нельзя понять, какие данные «свежие», а какие «старые». Но такой статистики в Postgres Pro не было. Соответственно, мы начали искать варианты реализации сбора требуемой статистики. При этом нам было важно, чтобы решение соответствовало требованиям:
статистика не должна учитывать системных пользователей (postgres) и системные процессы (vacuum);
для отдельных пользователей должна быть возможность дополнительно задавать исключения. Это важно на случай, если при формировании статистики нужно игнорировать действия с данными отдельных специалистов;
статистика должна быть долговременной. В случае перезагрузки сервера она не должна теряться. Соответственно, ее надо хранить не только в памяти, но и на диске.
Одновременно с поиском решения для сбора статистики обращений к таблице (DML-операции), мы занималась задачами по поиску неиспользуемых привилегий в рамках расширения pgpro_usage. В итоге мы объединили усилия, чтобы реализовать сбор всей необходимой статистики в рамках расширения pgpro_usage. Теперь статистика собирается вместе, но разделена — сброс статистики для поиска неиспользуемых привилегий по умолчанию не сбрасывает статистику, используемую для ILM.
Примечание: Чтобы понять принцип раздельного хранения статистики, достаточно вспомнить одометр автомобиля. Он может отображать как пробег авто за определенный период (путевой), так и общий пробег. Причем, если сбросить путевой пробег, данные об общем пробеге останутся незатронутыми.
Статистику времени последнего доступа к таблицам pgpro_ilm получает в разрезе пользователей из функций и представлений pgpro_usage. Из всего доступного массива информации для задач ILM нужны только отдельные сведения, в зависимости от выбранного правила:
для правила NO_MODIFICATION учитываем UPDATE, INSERT, DELETE или TRUNCATE;
для правила NO_ACCESS — не только UPDATE, INSERT, DELETE, TRUNCATE, но и чтение с помощью команды SELECT.
На основе этой статистики можно понять, когда, кто и как обращался к конкретным объектам в базе данных.
От теории к практике
Теперь, когда понятен сам механизм работы нашей реализации ILM, перейдем к тому, как именно работать с расширением pgpro_ilm для Postgres Pro Enterprise 17.
Установка
Для корректной работы pgpro_ilm должно быть установлено расширение pgpro_usage. Поэтому, прежде всего, добавляем расширение pgpro_usage в переменную shared_preload_libraries в файле postgresql.conf и перезапускаем сервер базы данных.
Далее создаем расширение pgpro_usage:
CREATE EXTENSION pgpro_usageСледом — создаем расширение pgpro_ilm.
CREATE EXTENSION pgpro_ilmНа этом подключение ilm будет завершено.
Управление списком пользователей
Используя SQL-интерфейс в pgpro_ilm, можно определить пользователей, действия которых будут игнорироваться для задач ILM. Как правило, такие исключения нужны, чтобы на статистику не оказывали влияния обращения к данным со стороны:
служебных пользователей информационной системы;
внутренних и внешних аудиторов, которым информация нужна разово;
пользователей, формирующих редкие, разовые отчеты, например выписку по счёту за определенный месяц 2020 года для контролирующих органов (если исторические данные запросили один раз в году, это не значит, что они до сих пор находятся в категории Less Active);
пользователей, выполняющих пакетные операции со старыми данными.
Для управления исключениями в pgpro_ilm предусмотрено несколько функций.
SELECT user_name, exclude_access, exclude_modification FROM pgpro_ilm.get_exclude_users(); — возвращает список исключаемых пользователей;
SELECT pgpro_ilm.set_exclude_users(array['exclude_access_user'], array['exclude_write_user']); — задает список пользователей, действия которых игнорируются при проверке правил NO_ACCESS и правил NO_MODIFICATION.
Управление правилами
Для управления правилами в pgpro_ilm предусмотрено три группы функций.
Функция для добавления нового правила
add_rule(iv_object_name text, iv_rule_type text, iv_period interval, iv_action text, iv_parameter text) returns void.
Здесь:
iv_object_name — имя объекта;
iv_rule_type — тип правила (NO_ACCESS или NO_MODIFICATION);
iv_period — период, после которого правило должно сработать;
iv_action — действие, которое надо сделать (например, перенести данные);
iv_parameter — параметр действия (например, куда надо перенести данные).
Например:
SELECT pgpro_ilm.add_rule('sales_table_section_q1_2021', 'NO_ACCESS', interval '12 mons', 'ALTER_TS', 'low_cost_sales_tablespace');Для корректного управления правилами и перемещением данных важно предварительно выработать единый регламент, который определит, когда переносить данные и куда.
Например:
данные, которые не модифицируются более 3 месяцев, переносят на SSD;
данные не запрашивали более 6 месяцев — на HDD;
данные не читали более 12 месяцев — хранятся в сжатом виде.
Функция для удаления правил
remove_rule(iv_object_name text, iv_rule_type text, iv_period interval, iv_action text) returns void
Здесь:
iv_object_name — имя объекта;
iv_rule_type — тип правила (NO_ACCESS или NO_MODIFICATION);
iv_period — период, после которого правило должно сработать;
iv_action — действие, которое надо сделать.
Функция для получения текущего списка правил для таблицы или всех правил
get_rules([iv_object_name text]) returns table
iv_object_name — имя объекта.
Обработка правил
Теперь к функциям pgpro_ilm, которые запускают обработку правил.
В Postgres Pro можно вызывать функции обработки правил как в ручном режиме, так и автоматически с помощью планировщика задания. Второй вариант приоритетнее, поскольку снижает нагрузку на специалистов.
Для обработки правил в СУБД Postgres Pro предусмотрены две функции.
process_rules (iv_object_name text) returns void — выполняет правила для одной таблицы, где iv_object_name text — имя таблицы.
process_all_rules() returns void — выполняет все правила для всех таблиц.
Например запуск обработки правил для отдельной секции:
SELECT pgpro_ilm.process_rules('sales_table_section_q1_2021');Примечание: Если таблица разделена на секции, то сначала проверяются правила для родительских секций, начиная с самого нижнего уровня иерархии. На каждом уровне правила рассматриваются в порядке, обратном периоду их действия. Как только для таблицы будет найдено подходящее правило, функции выполняют соответствующее действие и завершают обработку таблицы.
Что еще нужно знать
Теперь кратко остановимся на некоторых нюансах ILM.
Правила можно создавать как для секционированной таблицы в целом, так и для отдельной ее секции. Если вы создаете правила для секционированной таблицы, они автоматически наследуются для всех секций этой таблицы.
Правила для отдельных секций секционированных таблиц приоритетнее общих правил для таблиц. При этом правила, относящиеся к родительским таблицам, продолжают действовать.
Правила не обрабатываются при вызове process_rules для секционированной таблицы. Поскольку в секционированных таблицах нет данных (они хранятся в секциях), функция завершится успешно, но ничего не выполнит.
В текущей реализации при обработке правил индексы переносятся вместе с целевой таблицей/секцией. В следующих минорных релизах мы планируем реализовать возможность создания отдельных правил для таблиц/секций и индексов.
Если таблица уже была перенесена, то повторно правило обрабатываться не будет.
Операция ALTER TABLE … SET TABLESPACE … захватывает блокировку AccessExclusiveLock. Соответственно повторный вызов функции process_rules, до того, как завершится предыдущая операция, безопасен.
Если ALTER TABLE завершается ошибкой, то повторный вызов process_rules повторяет операцию.
Для того, чтобы было проще понять, от какой даты отсчитываются периоды и как обрабатываются правила, ниже представлена небольшая анимация. Надеюсь она позволит лучше понять внутреннюю логику нашей реализации ILM:
Дополнительные инструменты
В отдельных сценариях работы с Postgres Pro Enterprise 17 одного расширения pgpro_ilm может оказаться недостаточно. Поэтому для работы с большими объемами данных можно также применять другие расширения и инструменты.
В частности:
SPLIT PARTITION и MERGE PARTITIONS — команды для разделения одной секции на несколько и объединения нескольких секций в одну соответственно.
Механизм CFS для сжатия таблиц и индексов внутри табличного пространства. В СУБД Postgres Pro поддерживаются разные алгоритмы и степени сжатия.
pgpro_autopart — расширение Postgres Pro для автоматического секционирования при добавлении или изменении данных в таблице.
pgpro_bfile — расширение, которое добавляет составной тип bfile для доступа ко внешнему файлу, то есть позволяет выносить неструктурированные данные за пределы СУБД.
pgpro_scheduler — расширение, с помощью которого можно планировать, контролировать и управлять выполнением заданий.
Shardman — технология для создания распределенной реляционной СУБД, предоставляющая строгие гарантии целостности данных.
Вместо выводов
Postgres Pro Enterprise 17 и расширения к нему позволяют выстроить полноценный пайплайн работы с данными в разных кейсах и сценариях. ILM, с помощью которого можно перемещать редко используемые данные в более дешевое хранилище, — один из таких механизмов.
Расширение pgpro_ilm включено в состав Postgres Pro Enterprise 17 как стандартное расширение и не требует отдельного лицензирования и сложной настройки.
