Как я могу установить приоритет для потоков событий в wso2cep?

#priority-queue #wso2cep #siddhi

#приоритет-очередь #siddhi #wso2-cep

Вопрос:

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

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

Это поможет нам поддерживать согласованность справочных данных во всех потоках обработки событий.

Комментарии:

1. Другими словами, можем ли мы запускать и останавливать каждый отдельный поток событий вручную?

Ответ №1:

Я не вижу другого варианта, кроме загрузки внутри отдельных планов выполнения. Есть два варианта:

  1. Используйте триггер для периодической загрузки справочных данных из СУБД в Hazelcast. Фактический процесс будет использовать таблицу Hazelcast (этот план выполнения приведен ниже)
  2. Загрузка из СУБД и кэширование.

Итак, на данный момент мои вопросы:

  1. Какой из них лучше с точки зрения использования памяти?
  2. Какой из них лучше с точки зрения скорости обработки событий?
  3. Пожалуйста, предложите, есть ли какой-либо другой лучший способ.

План выполнения

 @Plan:name('ExecutionPlan')

/* define streams/tables and write queries here ... */
/* Facts/Events streams definition */
@Import('actions:1.0.0')
define stream actions (meta_name string, correlation_id int);

@Export('userActions:1.0.0')
define stream userACtions (meta_username string, meta_actionname string);

/* Dimension tables(Event Tables) definition */
-- table from RDBMS
@from(eventtable = 'rdbms' , datasource.name = 'PG' , table.name = 'users')
@IndexBy('id')
define table DBUsers (id int, name string);

-- table from Hazelcast
@from(eventtable = 'hazelcast', collection.name='hzUsers')
@IndexBy('id')
define table hzUsers (id int, name string);

/* Load dimension tables, from RDBMS to Hazelcast, periodically using trigger */
define trigger periodicTrigger at every 30 sec;

from periodicTrigger join DBUsers
select DBUsers.id as id, DBUsers.name as name
insert into hzUsers;

/* Actual execution plan */

from actions as A 
join hzUsers as H
on A.correlation_id == H.id
select H.name as meta_username, A.meta_name as meta_actionname
insert into userACtions;
  

Комментарии:

1. Что вы имели в виду под «загрузкой из СУБД и кэшированием»?. Вы имеете в виду прямой доступ к таблице СУБД? Или получать доступ к таблицам СУБД из каждого плана выполнения и периодически кэшировать их в таблицах в памяти? И сколько планов выполнения мы рассматриваем? И каков интервал кэширования?

2. С помощью «Загрузить из СУБД и кэшировать его»: Я имею в виду «доступ к таблицам СУБД из каждого плана выполнения и периодически кэшировать их в таблицах в памяти». И сколько планов выполнения мы рассматриваем? : Это может быть 30-50. И каков интервал кэширования?: В зависимости от вариантов использования, но в большинстве случаев это может быть один раз в день, а для немногих — всего 10 секунд.

3. Если мы рассмотрим время чтения каждой таблицы событий, оно будет несколько похоже на In-Memory (та же виртуальная машина) < Hz < RDBMS. Поэтому вам следует сосредоточиться на минимизации частоты доступа к СУБД. Что вы можете сделать, так это использовать СУБД для кэширования с часто кэшируемыми таблицами (которые имеют небольшой интервал кэширования и совместно используются в нескольких планах выполнения). Для других используйте RDBMS для кэширования в памяти. А также для огромных справочных таблиц, которые являются общими для EPS, используйте RDBMS для кэширования Hz.

4. Я думаю, если я смогу подключиться к внешнему кластеру hazelcast, моя проблема будет решена. Есть ли какая-либо документация о том, «как я могу подключиться к внешнему кластеру hazelcast?»

5. @Grainier, спасибо за разъяснения, у меня тоже есть подобное понимание, но я хочу уточнить у экспертов. В любом случае, как я упоминал в своем последнем комментарии, могу ли я подключиться к внешнему кластеру hazelcast? Я мог бы все упростить.

Ответ №2:

Я проверил внешний кластер hazelcast и, похоже, это дополнительные накладные расходы, необходимо создать класс DataSerializable для каждого типа таблиц.

Итак, я решил, как показано ниже, для хранения данных измерений / справочных данных для CEP:

  1. Для проекта с полностью открытым исходным кодом я пойду, как я уже упоминал в другом ответе, опубликованном мной, и, пожалуйста, прочитайте комментарии там, specialty 2nd (Obaid) amp; 3rd (Grainier).

  2. Для коммерческих проектов я буду использовать voltdb.

Спасибо всем, особенно @Grainier.