Хорошо сложные механизмы обработки событий обычно используются для удовлетворения сложных требований.Как следует из названия, мы ищем сложные отношения между событиями и временем, поэтому его сложная обработка событий.
Простая обработка событий будет соответствовать простым требованиям.Простые требования могут быть проверены только с двумя сценариями.Например, предположим, что мы хотим найти событие с температурой выше 100. Дизайн для этого в Esper EPL - «выбрать * из события (температура> 100)».Это может быть проверено двумя или, может быть, тремя сценариями: например, Event = {temp = 99}, Event = {temp = 100} и Event = {temp = 101}.
Есть несколько вариантов использования дляобработка событий средней сложности.Обычно для тестирования требуется от 4 до 9 сценариев.Например, предположим, что мы хотим найти более 100 событий, поступающих в течение одной скользящей минуты (скользящий, а не скачкообразный).Конструкция для этого в Esper EPL: «выберите количество () из Event # time (60), имеющего счет ()> 100».Теперь для тестирования этого правила требуется множество сценариев, таких как отсутствие событий, 100 событий, 101 событие, 101 событие в течение 61 секунды и т. Д. И т. Д. Здесь есть время, которое усложняет описание и тестирование этих сценариев.
Я бы сказал, что обработка сложных событий предназначена для случаев обработки событий средней и высокой сложности.Это тот тип вещей, где вы должны сначала четко определить требования.Перед тем, как приступить к разработке Esper EPL, вам необходимо записать различные сценарии событий и времени прохождения.
Требования к инструменту.Esper хорошо справляется с более сложными требованиями, но есть и кривая обучения.По моему опыту масштабирование может быть сделано, но требует планирования.Когда речь идет об анализе с низкой задержкой и масштабировании в одном предложении, не существует простого подхода «серебряной пули».Esper обладает высокой доступностью, но это не бесплатно, но хорошо масштабируется в стеке Kafka.