Предложение по структуре данных для хранения действующих РНР

Описание

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

Предложение

Для проверки работающего РНР необходимо 2 поля - идентификатор РНР и время начала. В связи с этим можно предложить несколько подходов:

Список РНР вместо со временем начало:

• В объект добавляется список affected_maintenances (ListDict)
  • maintenance_id - идентификатор Maintenance
  • start - время начала РНР

Проверка на наличие РНР выглядит как найти РНР со временем начала больше текущего.

Список идентификаторов РНР с отдельным поле maintenance_start:

• affected_maintenances (List) - массив идентификаторов РНР
• start_maintenance (Datetime)- время начала следующего РНР

Такой вариант может подойти для Postgres, в нём есть сложности с работой списками JSON и для него понадобится 2 запроса (одина на изменение РНР, второй на исправление времени).

Механизм выглядит следующим образом

• В объекты, поддерживающие РНР добавляется метод - in_maintenance с необязательным параметром timestamp, проверяющий есть ли действующий РНР
• При сохранении РНР происходит расчёт устройств, на которые действует РНР и происходит операция добавления push в массив идентификатора РНР и/или модификация времени начала.
• При завершении РНР соответствующая запись удаляется из массива (pop). Если время начала РНР хранится отдельно, то новое время рассчитывается как минимальное из действующих РНР

Добавления:

• Возможно по завершении РНР сохранять историю (начало, конец, объект)
• Появляется возможность поднимать групповую аварию на действующие РНР
• Возможна реализация РНР не только по ManagedObject но и по другим сущностям (Service, Agent). Также при открытии РНР на сегмент (или пул) можно не транслировать его в ManagedObject, а проверять через метод in_maintenance

Сложности

В отличие от текущего вариант необходимо инвалидировать кэш ManagedObject. Для лучшей работы