Out of Core Rules Engine

Существуют ли какие-либо реализации систем производственных правил, которые работают вне ядра?

Я проверил реализации с открытым исходным кодом, такие как CLIPS и Jess, но они работают только в памяти, поэтому они, как правило, приводят к сбою или принудительной подкачке жесткого диска при работе с большим количеством фактов и правил (например, с миллиардами / триллионами) .

Я обдумываю идею переноса простого движка правил, такого как Pychinko, на серверная часть SQL, использующая ORM Django. Однако поддержка уровня функциональности, найденного в CLIPS, была бы очень нетривиальной, и я не хочу изобретать велосипед.

Есть ли альтернативы расширению системы производственных правил?


python machine-learning rules rule-engine
person Cerin    schedule 10.06.2011    source источник
comment
Есть ли альтернативы расширению системы производственных правил? Да побольше оперативной памяти!   -  person Sven Marnach    schedule 11.06.2011
comment
Дайте алгоритму дополнительную оперативную память и исправьте его на день. Измените алгоритм, чтобы не использовать оперативную память, и исправьте это навсегда.   -  person Cerin    schedule 11.06.2011
comment
Мой комментарий был, конечно, насмешливым. Я просто не знаю ответа на ваш вопрос.   -  person Sven Marnach    schedule 11.06.2011
comment
Тупой вопрос, но как вы вообще управляете / определяете миллиарды и / или триллионы правил?   -  person Matthew Flynn    schedule 21.06.2011

Ответы (2)


arrow_upward
1
arrow_downward

вы можете проверить JENA и аналогичные механизмы правил RDF, которые предназначены для работы с очень большими базами данных фактов.

person yura    schedule 12.06.2011
comment
Йена хранит свои правила в памяти. Насколько мне известно, все механизмы правил RDF одинаковы. Большие базы данных фактов! = Вне основных правил. - person Cerin; 18.06.2011

arrow_upward
1
arrow_downward

Это не прямой ответ на ваш вопрос, но он может дать вам линию атаки на проблему.

Еще в 80-х и 90-х годах мы использовали систему поиска информации, которая позволяла обрабатывать очень большое количество постоянных запросов. В частности, у нас были системы с 64 МБ памяти (что было прикладной нагрузкой в те дни), которые обрабатывали до миллиона сообщений в день и применяли от 10 000 до 100 000+ постоянных запросов к этому потоку.

Если бы все, что мы сделали, - это итеративно применять каждый постоянный запрос к самым последним документам, мы были бы мертвым мясом. Мы сделали что-то вроде инверсии запросов. , в частности, с указанием условий обязательно иметь и может иметь в запросе. Затем мы использовали список терминов из документа, чтобы найти те запросы, у которых были хоть какие-то шансы на успех. Заказчик научился создавать запросы, которые сильно отличались друг от друга, и в результате иногда требовалось полностью оценить только 10 или 20 запросов.

Я не знаю вашего набора данных и не знаю, как выглядят ваши правила, но вы могли бы попробовать что-то подобное.

person Peter Rowell    schedule 23.06.2011