сохраняющихся Drools знаний Сессия

Question

Я работаю для школьного округа, и мы планируем использовать Drools для реализации следующих типов для правил для учащихся из районов учредительных школ:

• Если студент имеет 3 Отсутствие в течение года метрики посещаемости переходит в состояние WARN.
• Если студент имеет 6 отсутствий в течение года, их показатель посещаемости переходит в статус КРИТИЧЕСКОГО.
• Если у студента 3 основных случая поведения в течение года, их показатель поведения переходит в состояние WARN.
• Если учащийся имеет 2 младших и 2 основных случая поведения в течение года, их показатель поведения переходит в статус КРИТИЧЕСКОГО.
• ... это только примеры из верхней части моей головы, но есть еще много правил аналогичного характера.

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

1. С одной стороны это можно рассматривать как систему мониторинга потока событий. Это заставило меня подумать о создании сеанса с состоянием, в которое будет вставлено каждое новое событие. Однако события происходят в течение 9 месяцев и являются относительно нечастыми. Кроме того, мы могли бы построить сеанс в школе или сеанс для каждого учащегося.

   • Будет ли держать сессию в памяти на долгое время проблемой?
   • Если сервер не удался, нам нужно было бы перестроить состояние сеанса с нуля или было бы целесообразно делать регулярные снимки и просто восстанавливать факты, которые произошли со времени моментального снимка.

2. Другим вариантом является сохранение сеанса для каждого учащегося после обработки события для этого учащегося. Когда придет следующее событие, мы извлечем их сессию из хранилища и вставим новый факт. Таким образом, нам не нужно будет извлекать все факты для каждого запуска двигателя, чтобы получить статус студента. Будет ли поддерживаться такая конфигурация? Есть ли недостатки в этом?

3. Третий подход заключается в том, чтобы отреагировать на новый факт для учащегося, извлекая все другие факты, которые необходимо выполнить правилам, создать новую KnowledgeSession и запустить правила.

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

Dave

Answer 1

Я бы с раствором № 2: один сеанс на одного студента. Учитывая тот факт, что вы не собираетесь слишком много взаимодействовать с сеансом, я бы сохранил его в db и только восстанавливал его по мере необходимости: появляется новое отсутствие/инцидент, сеанс для этого ученика восстанавливается с db, факты вставляются, выполняются правила и восстанавливается полученный статус.

Главный недостаток, который я вижу в этом сценарии, заключается в том, что создание правил о более чем одном ученике не является простым, и вы должны кормить свои факты более чем за один сеанс.Например, если вы хотите получить предупреждение, если у вас более 10 студентов с статусом CRITICAL в одном классе. В этом случае сеанса на класс будет достаточно. Итак, как вы можете видеть, вы должны решить, что лучше для вас. Но независимо от того, какой вы выбрали «единица» (школа, класс, ученик), я бы порекомендовал вам поток выполнения, о котором я упоминал ранее.

Drools уже поставляется с поддержкой сохранения базы данных с использованием JPA. Вы можете получить дополнительную информацию об этой функции здесь: http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html_single/#d0e3961

Основная идея заключается в том, что вместо создания ваших ksessions с использованием kbase.newStatefulKnowledgeSession() вы используете вспомогательный класс под названием JPAKnowledgeService. Этот класс вернет оболочку StatefulKnowledgeSession, которая будет сохранять свое состояние после каждого вызова метода. В этом классе вы найдете 2 важных метода: newStatefulKnowledgeSession(), чтобы создать новый ksession и loadStatefulKnowledgeSession() для извлечения существующего сеанса из базы данных.

Надеется, что это помогает,

Answer 2

бездельничать Я хотел бы пойти на третий подход. Я буду хранить все события в БД, Затем я буду обрабатывать всех студентов в пакетном режиме один раз в день, неделю, месяц (по мере необходимости). Это позволит вам создать только один сеанс с правилами, охватывающими несколько учеников, классы и т. Д. Если у вас нет учеников из 3+ миллионов, у вас все будет хорошо, и это будет приложение для исполнителей.

Answer 3

Благодарим за предложения и рекомендации. Я склоняюсь к # 2 в течение нескольких причин:

• Я думаю, что собрать все факты для данного студента перезапускать их с нуля для каждого события, которое приходит в будет процессом тяжелого веса, Я бы предпочел избежать.
• Вариант использования Я имею дело с моделями как очень длительный процесс мониторинга, который заставляет меня поверить (после прочтения вариантов использования для Fusion), что вставка событий в постоянное KnowledgeSession - это путь.
• Я не думаю, что проблема проблемного пространства (то есть ученика и классной комнаты, школы или всего района) является проблемой. Если нам нужны показатели в классе, то мы просто новый для классов базы правил, которые также потребляют соответствующие события (тесты, прогулы и т.д.)

Одно предостережение, что если правила меняются, мы должны пересмотреть все затронутые ученики против новой нормативной базы, что означает сбор всех фактов и с начала учебного года. Это не должно происходить вообще, но если он станет более частым, я могу перейти к 3-му подходу.

Еще раз спасибо за помощь.

Answer 4

Существует четвертый вариант упрощения обслуживания. Создайте единую сессию знаний по состоянию здоровья для всего школьного округа для всех учащихся. После успешного завершения каждого события сохраняется сессия, если вам нужно восстановить рабочую память в случае сбоя JVM. Вам понадобится более крупное ОЗУ и распределение пространства кучи, но в сегодняшнее время ОЗУ дешево. (Мы используем 32 ГБ оперативной памяти и выделяем 16 ГБ XM и Xmx). Скорее всего, ваша JVM никогда не снизится, если у вас есть сервер 24x7.