Стратегия очистки таблиц Spring Batch в Postgres

Question

Среда Spring Batch определяет несколько BATCH_ таблиц с префиксами .

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

Нам не нужно хранить исторические BATCH_* данные в течение более 1 недели.

Я не могу придумать стратегию отклонения для Postgres, которая нене требует остановки всех наших пакетных процессов.

Если пакетные задания легко остановить, то я могу truncate или drop BATCH_* таблиц.Это требует координации между обслуживанием БД и пакетным обслуживанием.

Я думаю о delete данных, основанных на BATCH_JOB_EXECUTION.CREATE_TIME < current_date - 7 с соответствующими объединениями.Особое внимание следует уделить Postgres, чтобы вернуть использованную память через vacuum.Как я понимаю, невозможно восстановить табличное хранилище без vacuum full, но full блокирует BATCH_ таблиц.Это блокирует пакетные процессы ...

ОБНОВЛЕНИЕ Мой текущий план очистки (со статистикой производительности в единицах + секунды):

-- 2.1M  43s
-- Quick cleanup of majority of records.
DELETE FROM batch_step_execution_context bsec
WHERE
  EXISTS (
    SELECT 1 FROM batch_step_execution bse
    WHERE bse.start_time < current_date - 22 and bsec.step_execution_id = bse.step_execution_id);
-- 2.5s
vacuum batch_step_execution_context;

-- 2.1M  40s
-- Quick cleanup of majority of records.
DELETE FROM batch_step_execution bse
WHERE bse.start_time < current_date - 22;
-- 59s
vacuum batch_step_execution;

-- 0  1.4s
-- Full cleanup.
DELETE FROM batch_step_execution_context bsec
WHERE
  EXISTS (
    SELECT 1 FROM batch_step_execution bse
    join batch_job_execution bje on bje.job_execution_id = bse.job_execution_id
    WHERE bje.start_time < current_date - 22 and bsec.step_execution_id = bse.step_execution_id);

-- 0  1.2s
-- Full cleanup.
DELETE FROM batch_step_execution bse
WHERE
  EXISTS (
    SELECT 1 FROM batch_job_execution bje
    WHERE bje.start_time < current_date - 22 and bje.job_execution_id = bse.job_execution_id);

-- 122k  .49s
DELETE FROM batch_job_execution_params bjep
WHERE
  EXISTS (
    SELECT 1 FROM batch_job_execution bje
    WHERE bje.start_time < current_date - 22 and bje.job_execution_id = bjep.job_execution_id);
-- 1.2s
vacuum batch_job_execution_params;

-- 61k  .31s
DELETE FROM batch_job_execution_context bjec
WHERE
  EXISTS (
    SELECT 1 FROM batch_job_execution bje
    WHERE bje.start_time < current_date - 22 and bje.job_execution_id = bjec.job_execution_id);
-- .68s
vacuum batch_job_execution_context;

-- 61k  4.4s
DELETE FROM batch_job_execution bje
WHERE bje.start_time < current_date - 22;
-- .21s
vacuum batch_job_execution;

-- 61k  1.1s
DELETE FROM batch_job_instance bji
WHERE NOT EXISTS (SELECT 1 FROM batch_job_execution bje WHERE bje.job_instance_id = bji.job_instance_id);
-- .33s
vacuum batch_job_instance;

Answer 1

может быть дубликатом .... отправив тот же ответ снова, надеюсь, это поможет

Я долго боролся с этим, но для этого нет стандартной реализации.

Затем я придумал собственную хранимую процедуру,

Я создал собственную переменную - для очистки данных за последние 6 месяцев AGO_SIX_MONTH_DATE

Вы можете использовать свое значение.

Решение по ссылке ниже -

Очистка таблиц метаданных Spring Batch