Transient свойства объектов

[ai91]

Я создал feature request ( https://github.com/sergejey/majordomo/issues/1105 ), однако после поймал себя на мысли что возможно я просто неправильно настраиваю систему.

Может кто-нибудь из бывалых подсказать как вы решаете следующую проблему:
имеется большое количество входных данных (mqtt с ежесекундными обновлениями более двух десятков параметров), и необходимо разбирать и записывать в историю усреднённые значения раз в минуту.
В моём случае я имею более 300 запросов к БД в секунду. В случае "икоты" сервера, мгновенный рост phistory_queue до более 1700 записей.

Есть какие-нибудь трики которые я не знаю?

[ai91]

Ок, нашёл в старых темах ссылку на Фильтрация и округление данных от датчиков. Оказывается можно избежать первоначальной записи свойств настроив mqtt мэппинг не на свойство объекта, а на метод. Как-то никогда не обращал внимания на такую возможность. Таким образом избавился первого шага:

1. ежесекундная запись значения из mqtt в исходное свойство
2. ежесекундное добавление в буферное свойство xxxBuffer (т.е. чтение + запись)
3. ежеминутное чтение xxxBuffer рассчёт среднего значения
4. ежеминутная запись среднего значения в xxx-свойство с историей
5. ежеминутная очистка xxxBuffer

Если появится возможность держать свойство xxxBuffer только в памяти, то останется только 4-ый пункт. А это значит что количество обращений к базе уменьшится более чем в 120 раз. Т.е. всё еще востребованная фича.

[AK1]

Я создал feature request ( https://github.com/sergejey/majordomo/issues/1105 ), однако после поймал себя на мысли что возможно я просто неправильно настраиваю систему.

Может кто-нибудь из бывалых подсказать как вы решаете следующую проблему:
имеется большое количество входных данных (mqtt с ежесекундными обновлениями более двух десятков параметров), и необходимо разбирать и записывать в историю усреднённые значения раз в минуту.
В моём случае я имею более 300 запросов к БД в секунду. В случае "икоты" сервера, мгновенный рост phistory_queue до более 1700 записей.

Есть какие-нибудь трики которые я не знаю?

Лучше сделать вычисление среднего в самом устройстве. У меня на ESP все это выполняется, а на сервер отсылается конечный результат.

[ai91]

Лучше сделать вычисление среднего в самом устройстве.

К сожалению нет такой возможности, т.к. это закрытый продукт. Впрочем даже если и была бы возможность, то совершенно не хотелось бы, т.к. речь идёт об управлении токами до 22квт и теоретической возможностью сжеть не только само устройство стоимостью несколько сотен евро, но и автомобиль.

[xor]

Лучше сделать вычисление среднего в самом устройстве.

К сожалению нет такой возможности, т.к. это закрытый продукт. Впрочем даже если и была бы возможность, то совершенно не хотелось бы, т.к. речь идёт об управлении токами до 22квт и теоретической возможностью сжеть не только само устройство стоимостью несколько сотен евро, но и автомобиль.

1. напишите свой цикл ежесекундный с буфером не в свойстве, а в массиве, обрабатывайте его, а в свойство пишите оттуда раз в минуту
2. попробуйте поиграться с Проверка значений - там вы можете навернуть свой код перед записью в свойство (чтение останется). Возвращаете нулл после обработки - записи не будет в историю. а раз в минуту, например, возвращайте из кода своё среднее, которое запишется

[Logrus]

Ок, нашёл в старых темах ссылку на Фильтрация и округление данных от датчиков. Оказывается можно избежать первоначальной записи свойств настроив mqtt мэппинг не на свойство объекта, а на метод. Как-то никогда не обращал внимания на такую возможность. Таким образом избавился первого шага:

1. ежесекундная запись значения из mqtt в исходное свойство
2. ежесекундное добавление в буферное свойство xxxBuffer (т.е. чтение + запись)
3. ежеминутное чтение xxxBuffer рассчёт среднего значения
4. ежеминутная запись среднего значения в xxx-свойство с историей
5. ежеминутная очистка xxxBuffer

Если появится возможность держать свойство xxxBuffer только в памяти, то останется только 4-ый пункт. А это значит что количество обращений к базе уменьшится более чем в 120 раз. Т.е. всё еще востребованная фича.

у себя при подобном тз реализую хранение в кэше, с чтением из него и расчетом скользящего среднего
не обязательно писать в свойство по сетглобал, можно в кэш saveToCache
, ну а далее формат записи и своя логика ....

[ai91]

не обязательно писать в свойство по сетглобал, можно в кэш saveToCache

Воу воу! Почти то что надо!
Не идеально, конечно, но подойдёт для workaround'а.
Мне даже мой код почти не надо переделывать - только заменить пару setGlobal/getGlobal на кэш, и добавить имя объекта к имени проперти вместо ключа.

Читать их кэша, я так понимаю, через checkFromCache?

[Logrus]

не обязательно писать в свойство по сетглобал, можно в кэш saveToCache

Воу воу! Почти то что надо!
Не идеально, конечно, но подойдёт для workaround'а.
Мне даже мой код почти не надо переделывать - только заменить пару setGlobal/getGlobal на кэш, и добавить имя объекта к имени проперти вместо ключа.

Читать их кэша, я так понимаю, через checkFromCache?

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

[xor]

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

[Logrus]

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

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

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