Производительность и индексы в репозитории процессов Camunda

Я тестировал camunda для использования встраиваемого в моем приложении Tomcat в течение нескольких дней, но я поднимаю некоторые проблемы с производительностью в отношении правопреемников и переменных, чтобы дополнительно отфильтровать мой репозиторий. . Вот несколько простых сценариев использования, которые будут мне полезны:

1) Отфильтруйте все активные задачи, назначенные конкретному пользователю.

2) Отфильтруйте все активные экземпляры процесса, связанные с клиентом.

3) Отфильтруйте все активные задачи из экземпляров процессов, связанных с клиентом.

Итак, меня больше всего беспокоит:

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

б - Чтобы выполнить вариант использования 2, я добавлю идентификатор клиента в качестве переменной уровня процесса в свои экземпляры процесса для дальнейшей их фильтрации. Подлежат ли индексированию также переменные - предположим, исполнители? (скажем, мне нужно запросить 20 процессов в 1 миллионной таблице процессов с заданным набором переменных)

c - Наконец, с точки зрения производительности, должен ли я реплицировать переменную идентификатора клиента в каждой задаче, а затем фильтровать их, не проверяя соответствующие экземпляры процесса?

ps1: я использую базу данных postgres в качестве репозитория и не имею полного представления о базовой структуре и индексах, лежащих в основе механизма BPM. Если для создания индексов, недоступных по умолчанию, необходимо некоторое понимание, я был бы признателен за некоторые подсказки, над какими таблицами / столбцами мне следует работать.

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


camunda
person Cléssio Mendes    schedule 21.05.2016    source источник
comment
Рассмотрите возможность использования businessKey для идентификации процессов и задач по идентификатору клиента.   -  person Jan Galinski    schedule 22.05.2016

Ответы (1)


arrow_upward
1
arrow_downward

Если вас интересует структура базы данных и т. Д., Есть несколько вещей, на которые вы можете взглянуть. Структура базы данных описана в [1]

Вы также можете увидеть сценарии создания базы данных, просмотрев предварительно упакованные дистрибутивы. Для Tomcat посмотрите папку sql / create.

Чтобы ответить на ваши конкретные вопросы; Есть таблица ACT_RU_TASK. Это задачи времени выполнения. Глядя на сценарий SQL для Postgresql, можно увидеть индекс ACT_IDX_TASK_ASSIGNEE на ACT_RU_TASK (ASSIGNEE_). Следовательно, похоже, что есть указатель на исполнителя задачи.

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

На businessKey есть индекс, поэтому, если вы используете businessKey для хранения идентификатора клиента, вы можете получить некоторую поддержку от businessKey.

Помимо добавления индексов в соответствующих местах, если это необходимо, следует рассмотреть еще один способ - добавить вашу собственную таблицу, которая является индексом в движок. Например, используя прослушиватели событий жизненного цикла задачи или процесса и т. Д., Вы можете поддерживать таблицу в актуальном состоянии с помощью значений поиска. Следовательно, вы можете сохранить таблицу идентификаторов клиентов и идентификаторов процессов или задач, или определенных переменных и идентификаторов задач и т. Д. После создания таблиц вы можете добавить клиентский sql или плагины для использования этой возможности.

[1] https://docs.camunda.org/manual/7.4/user-guide/process-engine/database/

(Ответ Webcyberrob на https://forum.camunda.org/t/performance-and-indexes-in-camunda-process-repository/650)

person Cléssio Mendes    schedule 22.05.2016