Работа с огромным количеством правил (условия и ограничения )CEP-системы

Я работаю над приложением, которое принимает более 100 тыс. уникальных входов -для простоты предположим, что каждый вход представляет собой значение с плавающей запятой (a,b,c...etc)-хотя они также могут быть строками и т.д. Приложение имеет множество правил/событий/триггеров, связанных с эти входы.

Пример 1:

Rule[(a > b) and (c <= d)] --> [execute EventX]

Определение 1:Приведенное выше правило говорит :, когда значение входных данных 'a' больше, чем значение 'b', а значение входных данных 'c' меньше или равно значению 'd' выполнить EventX

Пример 2:

Rule[x != x.prev] --> [execute EventZ]

Определение 2:Приведенное выше правило гласит :Если после обновления значения текущее значение ввода 'x' не равно его предыдущему значению (, значение изменилось ). выполнить EventZ

Я обнаружил, что по мере увеличения количества входных данных и увеличения количества правил общий объем вычислений, необходимых для оценки «конкретных» правил и определения того, должно ли инициироваться событие, становится вышел из-под контроля -Увеличение скорости и количества ч/б для решения проблемы не приводит к ожидаемому масштабированию.

В настоящее время при каждом новом обновлении ввода связанный ввод/переменная просматривается -в хэш-таблице, -которая сопоставляет переменную с правилами, которые ее содержат. Каждое из этих правил затем оценивается, и если результат верен или требует действия, соответствующее событие запускается асинхронно.

Эта проблема относится к сфере обработки сложных событий, к сожалению, большинство архитектур в этой области используют тот же подход, описанный выше -, возможно, с некоторыми уточнениями, касающимися частоты, с которой оцениваются/переоцениваются объекты. Идея состоит в том, чтобы иметь систему, которая может реагировать почти в реальном -времени. Распределение правил и входных данных по нескольким узлам тоже не работает, так как в некоторых ситуациях в более чем 95% активных правил существует меньшинство входных данных.

Я надеялся, что есть какие-нибудь товарищи по SO, которые знают лучшие методы решения этой проблемы, данные/структуры или алгоритмы.

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

Если есть два подобных правила:

Rule[a < b] --> [exec E1]
Rule[b >= a] --> [exec E2]

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

Входные данные могут представлять такие вещи, как курсы акций, датчики температуры и т. д.

Еще одно замечание: некоторые входные данные имеют временные ограничения, а это означает, что правило может требовать, чтобы состояние переменной находилось в определенной позиции. /state в течение некоторого времени (например :цена MSFT > 20 долларов за последние 30 секунд ), в настоящее время это достигается с помощью «представляющей переменной» (фасада ), которая имеет значение либо 0, либо 1 /false или true (значение переменной определяется отдельным механизмом, который обычно является результатом срабатывания правила ).

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

5
задан Xander Tulip 16 April 2012 в 05:24
поделиться