Очистка данных

Очистка данных#

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

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

Когда проектировать очистку#

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

  • какие записи можно удалять;

  • по какой дате определяется срок хранения;

  • должна ли выполняться бизнес-логика удаления;

  • какой объем данных ожидается;

  • как проверить результат и восстановиться после ошибки.

Индексы

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

Секционирование

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

Размер транзакции

При удалении через объектный API учитывайте ограничения maxTxCellCount и maxTxRowCount. Стандартное удаление через API обрабатывает записи партиями по 1000 и фиксирует каждую партию отдельно.

Прямой Delete выполняет один SQL-запрос для всех подходящих записей. Он не делит удаление на партии и может создать крупную транзакцию PostgreSQL. Если объем нельзя надежно ограничить, используйте скриптовый способ с управляемыми партиями либо другое проектное решение. Для пакетной обработки можно использовать Btk_BulkProcessPkg, включая chunkedQuery: обработка выборки управляемыми порциями ограничивает размер одной транзакции и нагрузку на систему.

Настройка через интерфейс#

Путь: Приложение «Настройка системы» > Настройки и сервисы > Менеджер заданий.

  1. Создайте или выберите задание типа Очистка данных.

  2. Настройте и включите расписание.

  3. На вкладке Настройка очистки создайте строку.

  4. Укажите класс или таблицу, срок хранения, атрибут даты и способ удаления.

  5. Заполните дополнительные параметры выбранного способа.

  6. Включите настройку очистки.

  7. После проверки всех строк включите само задание.

  8. После первого запуска проверьте событие и его сообщения в журнале.

Признак активности настройки и признак включения задания действуют независимо. Выключенная строка пропускается даже при работающем задании. Включенная строка не выполняется, если выключено задание или его расписание.

Система регистрирует стандартное задание Очистка таблиц. Конкретный состав, активность и расписание его настроек зависят от поставки и проекта; не следует считать все преднастроенные строки автоматически включенными.

Порядок выполнения#

Во время запуска система:

  1. Выбирает активные настройки текущего задания.

  2. Для каждой настройки определяет срок хранения и атрибут даты.

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

  4. Фиксирует изменения успешно выполненной настройки.

  5. Переходит к следующей настройке.

  6. Сохраняет итог события и ошибки в журнале задания.

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

Внимание

Настройки выполняются последовательно, а результат каждой успешно выполненной настройки фиксируется отдельно. Удаление через API дополнительно выполняется и фиксируется партиями по 1000 записей.

Если последующая настройка или партия завершится ошибкой, ранее зафиксированные удаления не откатываются. Задание может завершиться с ошибкой после частичной очистки данных.

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

  1. Откройте журнал события и определите настройку, на которой возникла ошибка.

  2. Проверьте, какие записи уже были удалены.

  3. Устраните причину ошибки.

  4. Убедитесь, что повторное выполнение не повредит оставшиеся данные и не вызовет нежелательные побочные действия.

  5. После проверки повторно запустите задание.

Выбор способа удаления#

Способ

Когда применять

Особенности

Удаление через Delete

У записей нет обязательной логики удаления API, а объем заранее ограничен

Выполняет один SQL-запрос без разбиения на партии и обходит действия API

Удаление через API

При удалении должны работать проверки и обработка связанных данных

Вызывает delete API-класса партиями по 1000 объектов и фиксирует каждую партию

Удаление скриптом

Правило нельзя выразить стандартным отбором либо требуется собственная пакетная обработка

JEXL самостоятельно управляет отбором, транзакциями, партиями и удалением

Пользовательский вариант

Нужен повторно используемый тип с отдельной формой параметров

Настройка хранится в JSON и передается скрипту как jpSetting

Удаление через Delete

Система одним SQL-запросом удаляет все записи, дата которых вышла за срок хранения. Этот способ не вызывает объектную логику delete API-класса.

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

Удаление через API

Система разрешает API-класс по системному имени, выбирает устаревшие объекты партиями по 1000, вызывает для них delete и фиксирует каждую партию.

Используйте этот способ, если удаление должно выполнять прикладные проверки или обработку связанных данных. Корректность системного имени класса необходимо проверить в целевой конфигурации; регистр имени не следует использовать как документированное правило без отдельного теста.

Удаление скриптом

JEXL-скрипт самостоятельно отбирает и удаляет данные. Ему доступны:

  • nDaysKeep — срок хранения в днях;

  • sAttrCreateDate — системное имя атрибута даты.

Поле Класс/Таблица в такой настройке может содержать условное наименование. Один скрипт может очищать несколько связанных таблиц, но должен самостоятельно контролировать размер транзакций и журналировать значимые результаты.

Если скрипт фиксирует изменения частями, его повторный запуск должен корректно обрабатывать уже удаленные или обработанные записи.

Пользовательский вариант удаления

Пользовательский тип подходит для повторно используемой очистки с отдельной формой настройки. Он содержит:

  • скрипт выполнения очистки;

  • клиентский сеттер, который открывает форму и возвращает параметры.

Форма сохраняет параметры в JSON. При запуске распарсенное значение доступно скрипту в переменной jpSetting.

Порядок настройки:

  1. Выберите способ Пользовательский вариант удаления.

  2. Выберите или создайте тип в поле Выборочный способ удаления.

  3. Откройте настройку JEXL-скрипта и задайте параметры.

  4. Сохраните и включите строку.

Пример выполняемого скрипта для истории состояний:

Btk_JobCleanupDeleteTypeApi.cleanStateHistory(jpSetting);

Пример клиентского сеттера:

var jScriptData = jpSetting;
var data = Btk_ClassForChoiceAvi.listForChooseToCleanStateHistory()
    .newForm()
    .params({
        'nDayKeep#': nDaysKeep,
        'jScriptClearInfo#': jScriptData
    })
    .openLookup();
if (data.getLookupResult() == LookupResult.ok()) {
    data.getResultObject();
} else {
    jScriptData
};

Регистрация настройки из Scala#

Прикладной модуль должен использовать контракт Btk_JobCleanupSettingApic, а не прямую зависимость от реализации Btk_JobCleanupSettingApi.

Btk_JobCleanupSettingApic().register(
  idpJob = Btk_JobApic().findByMnemoCode("CleanupJob"),
  spClass = "Prs_IntWarrTempPkg",
  npDaysKeep = 1.nr,
  npDeleteType = Btk_JobCleanupSettingApi.DeleteType.script,
  spAttrCreateDate = "",
  spJexlScript = "Prs_IntWarrTempPkg.clearOldAndNonActive();",
  bpActive = 1.nr
)

Параметры:

  • idpJob — идентификатор задания очистки;

  • spClass — системное или условное имя объекта очистки;

  • npDaysKeep — срок хранения в днях;

  • npDeleteType — способ удаления;

  • spAttrCreateDate — атрибут даты для определения устаревших записей;

  • spJexlScript — скрипт способа DeleteType.script;

  • bpActive — активность настройки;

  • idpAdditionalDeleteType и jpConfig — пользовательский тип и его JSON-настройка.

Пример регистрирует фактически используемую настройку очистки временных данных PRS. Метод Prs_IntWarrTempPkg.clearOldAndNonActive() и значение поля spClass относятся к этому прикладному сценарию; для другого модуля замените их собственными подтвержденными значениями.

Очистка таблиц аудита#

После очистки таблицы аудита система регистрирует соответствующий бизнес-объект для последующего полного пересчета кеша размера аудита атрибутов. Пересчет предотвращает отображение устаревшего объема аудита после удаления записей.

Для распознавания таблицы spClass должен ссылаться на таблицу вида {схема аудита}.{имя класса}_dzaud. AUD — стандартное имя схемы, но фактическая схема задается настройками системы и может отличаться.

Журналирование и проверка результата#

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

Перед первым запуском в рабочем контуре:

  1. Проверьте условие отбора записей отдельным запросом без удаления.

  2. Оцените количество устаревших записей.

  3. Проверьте настройку на тестовом контуре или копии данных.

  4. Убедитесь, что данные можно восстановить из резервной копии при ошибочной настройке.

  5. Включите настройку и проконтролируйте первый запуск.

После тестового запуска проверьте:

  • состояние события и текст ошибки;

  • сообщения по каждой настройке;

  • количество удаленных записей;

  • отсутствие записей моложе срока хранения;

  • выполнение необходимых действий API;

  • длительность и объем транзакций;

  • влияние на блокировки и размер таблицы.

Срок хранения событий самого менеджера задается в поле Срок хранения логов, дней (Btk_Job.nPeriodStorageLogs). Это другой механизм: он очищает историю запусков, а не данные, перечисленные на вкладке Настройка очистки.

Диагностика#

Записи остались после очистки#

Проверьте последовательно:

  1. Включена ли нужная строка настройки.

  2. Верно ли указаны срок хранения и атрибут даты.

  3. Разрешается ли класс или таблица по указанному имени.

  4. Переданы ли nDaysKeep, sAttrCreateDate или jpSetting в ожидаемом виде.

  5. Фиксирует ли пользовательский скрипт изменения.

  6. Не выполняется ли отбор по другой дате или часовому поясу.

Задание завершилось с ошибкой#

Откройте событие в журнале, определите последнюю начатую настройку и проверьте ее сообщения. Успешно завершенные ранее настройки и API-партии уже зафиксированы. Для удаления через API проверьте прикладные ограничения delete. Для прямого или скриптового удаления проверьте размер транзакции, блокировки и корректность SQL/JEXL.

Очистка выполняется слишком долго#

Проверьте план запроса по атрибуту даты, наличие индекса, размер одного пакета, объем просроченных данных и целесообразность секционирования. Не заменяйте API-удаление прямым Delete, пока не подтверждено, что его побочные действия не нужны.

Содержание