Использование Drools в тяжелом пакетном процессе

Я не работал с последней версией Drools (последний раз я использовал ее около года назад), но тогда наши тесты с высокой нагрузкой показали, что она очень медленная. Огромное разочарование после того, как на нем была основана большая часть нашей архитектуры.

По крайней мере, что-то хорошее, что я помню о drools, это то, что их команда разработчиков была доступна в IRC и очень помогла, вы можете попробовать, в конце концов, они эксперты: irc.codehaus.org #drools

Вид зависит от ваших правил — 500 000 объектов разумно при достаточном объеме памяти (он должен заполнить сеть RETE в памяти, поэтому использование памяти кратно 500 000 объектам — т. е. пространство для объектов + пространство для сетевой структуры, индексов и т. д.) — его возможно, вы выполняете подкачку на диск, что будет очень медленно.

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

Я использовал Drools с оперативной памятью с отслеживанием состояния, содержащей более 1 миллиона фактов. При некоторой настройке как ваших правил, так и лежащей в их основе JVM производительность может быть довольно хорошей уже через несколько минут при первоначальном запуске. Дайте мне знать, если вы хотите получить более подробную информацию.

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

Если это не так, то, возможно, вы могли бы использовать сеанс без сохранения состояния и утверждать один объект за раз. Я предполагаю, что в этом случае правила будут работать в 500 000 раз быстрее.

Даже если это так, нужны ли всем вашим правилам доступ ко всем 500 тыс. объектов? Не могли бы вы ускорить процесс, применяя правила для каждого элемента по одному, а затем на втором этапе обработки применяя правила пакетного уровня, используя другую базу правил и рабочую память? Это не изменило бы объем данных, но сеть RETE стала бы меньше, потому что простые правила были бы удалены.

Альтернативным подходом было бы попытаться идентифицировать связанные группы объектов и утвердить объекты в группах во время второй фазы, еще больше уменьшив объем данных в рабочей памяти, а также разделив сеть RETE.

Drools на самом деле не предназначен для запуска на огромном количестве объектов. Он оптимизирован для запуска сложных правил на нескольких объектах.

Инициализация рабочей памяти для каждого дополнительного объекта слишком медленная, а стратегии кэширования рассчитаны на работу с каждым объектом рабочей памяти.

Использовать сеанс без сохранения состояния и добавлять объекты по одному?

У меня были проблемы с ошибками OutOfMemory после разбора нескольких тысяч объектов. Установка другого оптимизатора по умолчанию решила проблему.

OptimizerFactory.setDefaultOptimizer(OptimizerFactory.SAFE_REFLECTIVE);

Мы тоже смотрели на слюни, но для нас количество объектов невелико, так что это не проблема. Я помню, как читал, что существуют альтернативные версии одного и того же алгоритма, которые больше учитывают использование памяти и оптимизированы для скорости, но при этом основаны на том же алгоритме. Не уверен, что хоть один из них превратился в настоящую полезную библиотеку.

этот оптимизатор также можно установить с помощью параметра -Dmvel2.disable.jit=true