Вопрос

я посмотрел на Механизм правил WF и NxBRE и это кажется интересным, но я не уверен, насколько хорошо он будет работать в реальных сценариях.

Я имею в виду что-то вроде базы фактов, содержащей от 10 до 100 миллионов фактов и правил, например:

Object.Field < 5000 И Object.Field > 1000 И IsProperty(Object.Field2)

Я использую C# и .NET.

Редактировать: Я не совсем ясно выразился (полностью моя вина) :) У меня есть собственная система оценки правил, которая использует сам алгоритм RETE...он довольно быстрый, он может оценить сценарий из 10 миллионов фактов примерно за 10 секунд...насколько быстро коммерческие решения сравниваются?

Это было полезно?

Решение

Короткий ответ: я ожидаю, что механизм правил превзойдет императивное решение, как только количество правил превысит некоторое (я не знаю точное значение) пороговое значение.

Частью механизма правил является набор условий и действий.Единственное правило (почти) функционально эквивалентно оператору if-then.Реальная мощь механизма правил проявляется благодаря декларативному характеру механизма.

В традиционной императивной программе вам необходимо закодировать способ оценки логики.При использовании механизма правил он определяет, сколько ваших утверждений будет оценено.Я использовал только такие двигатели, как Джесс или КЛИПЫ, которые используют алгоритм сети чтобы выяснить, какие правила активировать.Именно эффективность вашего алгоритма применения правил будет определять, насколько эффективнее ваш механизм правил будет работать по сравнению с традиционным императивным решением.

Алгоритм Rete предназначен для того, чтобы пожертвовать памятью ради увеличения скорости.Он поддерживает сеть узлов, сопоставляющих побочные шаблоны LHS с правилами.Чем больше у вас правил и фактов, тем лучше ваша сеть Rete превзойдет ваше императивное решение, поскольку производительность Rete теоретически не зависит от количества правил в системе.

Вы планируете много фактов.Если вы планируете использовать много правил, вы можете столкнуться с проблемами с памятью.

Прочтите статью Мартина Фаулера о механизмы правил.Это хороший и (очень) краткий обзор.

Есть долгое обсуждение на платформе Microsoft Business Rules Engine (MS-BRE) и ее производительность по сравнению с Jess & Drools.Некоторые из поднятых вопросов подчеркивают, почему эти оценки сложны.

Другие советы

«Слух о том, что это неточная реализация Rete» относится к древней проблеме, связанной с утверждением о том, что механизм бизнес-правил, включенный в BizTalk Server, не может правильно реализовать алгоритм Rete.Кстати, утверждение было неверным.BRE, безусловно, реализует Rete.Механизм правил WF — это совершенно другая технология, чем BRE.Как говорит Карл, механизм правил WF вообще не реализует Rete ни правильно, ни неправильно.Это пример того, что можно условно назвать «последовательным» двигателем.Он реализует форму прямой цепочки.Однако реальные проблемы немного сложнее.Бит «вперед» относится к типу логических рассуждений, которые может выполнять механизм.Этот термин на самом деле ничего не говорит о механизмах, задействованных во время выполнения.Настоящая проблема заключается в том, насколько хорошо машина умеет рассуждать.Да, WF может пересылать цепочки, и да, он может рассуждать, но только весьма ограниченными способами.Механизм Rete предлагает более сильные возможности рассуждения, НО на самом деле это не имеет ничего общего с использованием алгоритма Rete, который на самом деле является просто оптимизацией для определенного класса механизма правил, называемого «производственной» системой.Это связано с тем, как производственная система может рассуждать на основе всей «базы фактов», тогда как механизм последовательных правил WF может непосредственно рассуждать только на основе грубого эквивалента одного факта.Проблемы иногда возникают из-за того, что люди путают конкретный механизм времени выполнения, который обеспечивает прямое связывание, с логическим процессом самого прямого связывания (и, в конце концов, это довольно тонкое различие).Соответствующий механизм в WF, конечно, может быть использован для «прямого» рассуждения в ограниченной степени, но его основное использование состоит в том, чтобы позволить последовательным правилам быть выраженными полудекларативным способом, т. е. правила могут быть выражены в любой последовательности. независимо от процедурных зависимостей между этими правилами.Это не имеет ничего общего с упреждающими рассуждениями или, по сути, с локальным процессом построения прямой цепочки.

Вопрос немного сложный и неясный, и я знаю, что некоторые ребята из MS не согласны со мной в этом (мы обсуждали это достаточно часто), но это мое мнение.

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

Мы провели 24 миллиона тестов по 1500 правилам за семь минут, используя Джей Босс пускает слюни с двумя JVM, работающими на чертовски средних серверах.Это более тридцати шести миллиардов тестов, которые нужно выполнить, если вы запустите каждую комбинацию, и в большинстве тестов есть несколько вариантов логики.(Например, в вашем примере есть три варианта выбора.)

вам также придется учитывать, как данные передаются в ваш механизм правил, например, когда правила начинают срабатывать, а некоторые правила совершают вызовы к БД, тогда наверняка возникнут проблемы с производительностью.Лучше всего предоставлять все данные, необходимые для выполнения правила, в самом начале, хотя это также имеет некоторые недостатки.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top