Камунда - база данных быстро растет проблема - PullRequest
Новая
       13

Камунда - база данных быстро растет проблема

0 голосов
/ 05 января 2019

У меня проблема с базой данных. Это растет так быстро. Я использую MySQL 5.7.24, Spring Boot и History Level Audit. Теперь моя база данных ~ 100 ГБ.

Кто-нибудь знает методику или совет, как уменьшить размер базы данных? Могу ли я удалить байтовые массивы из ACT_GE_BYTEARRAY или переместить некоторые исторические данные в другую базу данных?

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

Текущий размер моего стола:

  • ACT_HI_VARINST => 10,66 ГБ
  • ACT_HI_PROCINST => 0,46 ГБ
  • ACT_HI_TASKINST => 0,01 ГБ
  • ACT_HI_ACTINST => 15,92 ГБ
  • ACT_GE_BYTEARRAY => 29,49 ГБ
  • ACT_HI_DETAIL => 16,02 ГБ

P.S. Я начал модифицировать процессы, чтобы использовать маленькие (простые) переменные вместо «больших» переменных - сериализованных объектов, которые слишком велики, чтобы уменьшить размер ACT_HI_VARINST .

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 07 января 2019

Вам придется изучить функцию «Время жизни в истории» (TTL), которая была представлена ​​в прошлом году. Вы можете определить интервал времени, после которого старые экземпляры будут удалены. Если вам все еще нужны данные для составления отчетов, рассмотрите возможность их экспорта в подходящее хранилище, возможно, решение Camunda Optimize / эластичное здесь. Итак, вкратце: определите TTL и напишите экспортеров, которые хранят важные данные где-то еще до того, как они будут удалены.

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

0 голосов
/ 05 января 2019

Возможно, вам стоит задуматься о создании разделов на существующих таблицах.

Из-за отсутствия достаточного количества информации о упомянутых таблицах было бы трудно предоставить фрагмент кода, но, возможно, нижеупомянутый фрагмент SQL поможет вам: 

ALTER TABLE data_table 
PARTITION BY RANGE( UNIX_TIMESTAMP(last_updated) ) ( 
PARTITION p_first VALUES LESS THAN (UNIX_TIMESTAMP('2000-01-01 00:00:00')), 
PARTITION p200001 VALUES LESS THAN (UNIX_TIMESTAMP('2005-01-01 00:00:00')), 
PARTITION p200501 VALUES LESS THAN (UNIX_TIMESTAMP('2010-01-01 00:00:00')), 
PARTITION p201001 VALUES LESS THAN (UNIX_TIMESTAMP('2015-01-01 00:00:00')),
PARTITION p_future VALUES LESS THAN (MAXVALUE) );

После создания этих разделов вы сможете удалить старые разделы.

...