Оптапланер с директором счета Drools - почему бы не пустое решение - PullRequest
Новая
       69

Оптапланер с директором счета Drools - почему бы не пустое решение

1 голос
/ 19 февраля 2020

Я ознакомился с демонстрацией Cloud Balancing OptaPlanner с реализацией Drools.

Есть 2 правила для этой демонстрации (на самом деле их 4, но 3 из них имеют одинаковые логики c) - 

rule "requiredCpuPowerTotal"
when
    $computer : CloudComputer($cpuPower : cpuPower)
    accumulate(
        CloudProcess(
            computer == $computer,
            $requiredCpuPower : requiredCpuPower);
        $requiredCpuPowerTotal : sum($requiredCpuPower);
        $requiredCpuPowerTotal > $cpuPower
    )
then
    scoreHolder.addHardConstraintMatch(kcontext, $cpuPower - $requiredCpuPowerTotal);
end

и 

rule "computerCost"  // "Minimize the total maintenance cost."
when
    $computer : CloudComputer($cost : cost)
    exists CloudProcess(computer == $computer)
then
    scoreHolder.addSoftConstraintMatch(kcontext, - $cost);
end

Опираясь на эти правила, оптимальным решением НЕ будет назначать ЛЮБОЙ из процессов кому-либо из компьютеров. Это будет полностью удовлетворять первому правилу - емкость cpuPower никогда не исчерпывается, не говоря уже о том, чтобы ее преодолеть. И никакие компьютеры не будут использоваться, и, следовательно, не будет затрат на техническое обслуживание.

Но система находит решение только с этими двумя правилами - субоптимизирует назначение процессов, которые есть на компьютерах.

что мне не хватает, где?

Где OptaPlanner / Drools сказали выделить как можно больше процессов?

новинка для Drools. извините за наивный вопрос, если это так.

// --- ОБНОВЛЕНИЕ

@PlanningEntity() экземпляров, которые должны быть инициализированы и помещены в @PlanningSolution() - это ключ, который я думаю. либо явно в коде, либо с помощью конфигурации Construction Heuristi c, как предложено @ yurlo c, или .. {не знаю, что еще здесь, если есть}

1 Ответ

1 голос
/ 19 февраля 2020

https://docs.optaplanner.org/latest/optaplanner-docs/html_single/#localSearchOverview:

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

По умолчанию Local Search ожидает, что все объекты инициализированы, и ему не разрешается деинициализировать их при внесении изменений в решение. Ответ на ваш последний вопрос заключается в том, что фаза Construction Heuristi c назначает компьютер для каждого процесса , даже если это фактически ухудшает оценку. Локальный поиск улучшит оценку на следующем этапе.

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

Для Для полноты обратите внимание, что вы можете сделать переменные планирования обнуляемыми , но это продвинутая топи c. Обнуляемые переменные планирования обычно полезны только для чрезмерно ограниченного планирования.

...