규칙 엔진이 얼마나 잘 수행됩니까?
https://stackoverflow.com/questions/1471750
-
16-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는보고있다 WF 규칙 엔진 그리고 nxbre 그리고 그것은 흥미로워 보이지만 실제 시나리오에서 얼마나 잘 수행 될지 잘 모르겠습니다.
내가 염두에두고있는 것은 10 ~ 1 억 사이의 사실과 다음과 같은 규칙을 가진 사실 기반과 같습니다.
Object.field <5000 및 Object.field> 1000 및 Isproperty (Object.field2)
C# 및 .NET을 사용하고 있습니다.
편집하다: 나는 나 자신을 명확하게하지 않았다 (전적으로 내 잘못) :) 나는 Rete 알고리즘 자체를 사용하는 내 자신의 규칙 평가 시스템을 가지고있다 ... 그것은 매우 빠르며, 약 10 초 안에 천만 개의 사실 시나리오를 평가할 수있다 ... Comaparison에서 Comercial Solutions는 얼마나 빠르게입니까?
해결책
짧은 대답은 규칙 수가 일부 (정확한 값을 모른다) 임계 값을 초과하면 규칙 엔진이 명령 솔루션을 능가 할 것으로 예상한다는 것입니다.
규칙 엔진의 규칙 부분은 일련의 조건과 행동입니다. 단일 규칙은 (거의) 기능적으로 IF- 다음 명령문과 동일합니다. 규칙 엔진의 실제 힘은 엔진의 선언적 특성으로 인해 빛납니다.
전통적인 명령 프로그램에서는 논리를 평가하는 방법을 코딩해야합니다. 규칙 엔진을 사용할 때는 몇 개의 진술이 평가되는지 결정합니다. 나는 엔진과 같은 엔진 만 사용했습니다 발목 끈 또는 클립, a RETE 알고리즘 어떤 규칙을 해고 해야하는지 알아 내기 위해. 규칙 발사 알고리즘의 효율성은 규칙 엔진이 기존의 필수 솔루션을 통해 얼마나 더 효율적인지를 유도 할 것입니다.
Rete 알고리즘은 속도를 높이기 위해 메모리를 희생하도록 설계되었습니다. LHS 측면 패턴을 규칙에 매핑하는 노드 네트워크를 유지합니다. 규칙과 사실이 많을수록 Rete Network가 시스템의 규칙 수와 이론적으로 독립적이기 때문에 Rete Network가 명령 솔루션을 능가 할 수 있습니다.
당신은 많은 사실을 계획하고 있습니다. 많은 규칙을 가질 계획이라면 메모리 문제가 발생할 수 있습니다.
Martin Fowler의 기사를 살펴보십시오 규칙 엔진. 좋고 (매우) 짧은 개요입니다.
거기 있습니다 긴 토론 MS-BRE (Microsoft Business Rules Engine) ADN에서 Jess & Drools와 비교하여 성능을 발휘합니다. 제기 된 몇 가지 요점은 이러한 평가가 어려운 이유를 강조합니다.
다른 팁
"충실한 망상 구현이 아니라는 소문"은 Biztalk 서버에 포함 된 비즈니스 규칙 엔진이 Rete Algorithm을 올바르게 구현하지 못한다는 주장에 관한 고대 문제를 말합니다. 그건 그렇고 주장은 잘못되었습니다. Bre는 확실히 Rete를 구현합니다. WF Rules Engine은 BRE와 완전히 다른 기술입니다. Karl이 말했듯이 WF Rules Engine은 RETE를 전혀 구현하지 않습니다. 이는 느슨하게 '순차적'엔진이라고 불릴 수있는 예입니다. 전방 사슬의 형태를 구현합니다. 그러나 실제 문제는 이것보다 조금 더 복잡합니다. '포워드'비트는 엔진이 할 수있는 논리적 추론의 유형을 나타냅니다. 이 용어는 실제로 런타임과 관련된 메커니즘에 대해 아무것도 말하지 않습니다. 실제 문제는 엔진이 얼마나 좋은지에 관한 것입니다. 그렇습니다. WF는 전진 체인을 할 수 있습니다. Rete Engine은 더 강력한 추론 기능을 제공하지만 실제로는 Rete Atgorithm의 사용과 관련이 없습니다. 이는 실제로 '생산 시스템'이라고하는 특정 클래스의 규칙 엔진에 대한 최적화 일뿐입니다. 그것은 생산 시스템이 전체 '사실 기반'을 추론 할 수있는 방식과 관련이있는 반면, 순차적 WF 규칙 엔진은 단일 사실에 해당하는 거친 것보다 직접적으로 추론 할 수 있습니다. 사람들이 전방 체인 자체의 논리적 프로세스와 전진 연쇄를 가능하게하는 특정 런타임 메커니즘을 혼동하기 때문에 문제가 발생합니다. WF의 관련 메커니즘은 확실히 '전진'방식으로 제한된 범위로 추론하는 데 사용될 수 있지만, 주요 사용은 순차적 규칙을 반 선자 방식으로 표현할 수 있도록하는 것입니다. 즉, 규칙은 모든 순서로 표현 될 수 있습니다. 해당 규칙 간의 절차 적 의존성에 관계없이. 그것은 전진 추론이나 실제로 전방 사슬의 로컬 과정과 관련이 없습니다.
이 문제는 조금 복잡하고 모호하며, MS의 일부 사람들이 이것에 대해 나와 동의하지 않는다는 것을 알고 있습니다 (우리는 자주 논의했습니다).
WF 규칙 엔진은 실제로 자체 파서를 구현하고 결과적으로 표현성이 다소 제한되어 있으며 규칙을 해석하기 위해 문자열 구문 분석을 수행하기 때문에 성능 고려 사항이 있다는 것입니다. 런타임시 코드 (실행 가능한 조치)로.
우리는 7 분 만에 1500 개의 규칙을 통해 2,400 만 개의 테스트를 기록했습니다. JBOSS 침물 두 개의 JVM이 예쁜 평균 서버에서 실행됩니다. 모든 조합을 실행하면 30 억 개 이상의 테스트가 실행되며 대부분의 테스트에는 여러 논리 선택이 있습니다. (예를 들어, 예를 들어 세 가지 선택이 있습니다.)
또한 규칙이 시작되기 시작한 것처럼 데이터가 규칙 엔진으로 전달되는 방법을 고려해야하며 일부 규칙은 DB를 호출하면 성능 문제가 발생합니다. 모범 사례는 시작 자체에서 규칙 실행에 필요한 모든 데이터를 제공하는 것입니다.
