ALTER TABLE ADD RETENTION

Содержание раздела
  1. Связанные запросы
  2. Поддерживаемые датасорсы
  3. Как работает запрос
    1. Регистрация запроса
    2. Обработка запроса
    3. Успешный результат
    4. Неуспешный результат
  4. Синтаксис
  5. Варианты ответа
  6. Ограничения
    1. Ограничения выполнения
    2. Другие ограничения
  7. Примеры
    1. Retention-правило для остужения данных
    2. Retention-правило для удаления данных

Поддерживается в версиях: 7.7 / 7.6 / 7.5 / 7.4 / 7.3 / 7.2 / 7.1 / 7.0 / 6.12 / 6.11 / 6.10 / 6.9 / 6.8 / 6.7 / 6.6 / 6.5 / 6.4 / 6.3.

Запрос добавляет retention-правило для таблицы:

Retention-правило невозможно изменить, но можно удалить и создать заново. При удалении правил также удаляются накопленные по ним холодные данные.

  • CREATE TABLE с ключевым словом RETENTION — создает таблицу с retention-правилом;
  • ALTER TABLE DROP RETENTION — удаляет retention-правило вместе с холодными данными, накопленными по нему;
  • GET_ENTITY_DDL — возвращает информацию о таблице, включая ее текущие retention-правила.

Поддерживаемые датасорсы

Retention-правила поддерживаются для датасорсов типа ADB и ADP. Остужение данных доступно для логических таблиц:

  • в пределах одного датасорса (например, adp2adp2);
  • между разными датасорсами одного типа (например, adp2adp3).

Каждый датасорс таблицы может иметь свое retention-правило.

Как работает запрос

Регистрация запроса

Каждое добавление retention-правила записывается в журнал, доступный с помощью запроса GET_CHANGES.

Обработка запроса

Запрос попадает в очередь операций и обрабатывается в порядке его поступления в очередь.

Успешный результат

При успешном выполнении запроса система создает:

  • retention-правило;
  • [для правила остужения данных] физическую таблицу для хранения холодных данных в датасорсе-приемнике.

Неуспешный результат

При ошибке исполнения корректного запроса система блокирует все последующие DDL-запросы в логической БД. О снятии такой блокировки см. в разделе Снятие блокировки DDL-запросов.

Синтаксис

ALTER TABLE [db_name.]table_name
ADD RETENTION ('source_datasource', retention_period[, 'archive_datasource'])

Параметры:

db_name

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

table_name

Имя таблицы, для которой добавляется retention-правило.

source_datasource

Имя датасорса-источника — датасорса, исторические данные которого должны остужаться или удаляться по истечении срока их хранения. Должно соответствовать конфигурации.

retention_period

Срок хранения исторических данных (для логической таблицы или материализованного представления) или информации об удаленных записях (для снапшот-таблицы) в датасорсе-источнике. Указывается в секундах.

Если равен 0, данные остужаются или удаляются при каждом исполнении правила.

archive_datasource

Имя датасорса-приемника для данных, остужаемых правилом. Должно соответствовать конфигурации.

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

Если отсутствует, правило удаляет данные, а не остужает.

Варианты ответа

В ответе возвращается:

  • пустой объект ResultSet при успешном выполнении запроса;
  • исключение при неуспешном выполнении запроса.

Ограничения

Ограничения выполнения

Другие ограничения

  • Датасорс-источник и датасорс-приемник в retention-правиле должны быть одного типа.
  • Retention-правила партиционированной таблицы не применяются к ее партициям.
  • Retention-правила снапшот-таблиц могут только удалять информацию об удаленных записях; остужение этой информации не поддерживается.

Примеры

Retention-правило для остужения данных

Запрос на добавление retention-правила, согласно которому исторические данные будут храниться в adp не меньше недели, а затем будут перемещаться в adp_archive:

ALTER TABLE marketing.sales
ADD RETENTION ('adp', 604800, 'adp_archive')

Retention-правило для удаления данных

Запросы на добавление retention-правил, согласно которым исторические данные будут храниться в adp и adp2 не меньше месяца, а затем будут удаляться:

ALTER TABLE marketing.stores_snapshot
ADD RETENTION ('adp2', 2678400);

ALTER TABLE marketing.stores_snapshot
ADD RETENTION ('adp', 2678400);