Хранение только бинарного изменения

[gorec2005]

Подскажите пожалуйста возможно ли subj ?
т.е.

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

[Kos]

В голову приходит только корявое решение с парой элементов данных: один хранит собственно длинное текстовое значение и имеет минимальный срок хранения (1 день), а второй - calculated item с функцией diff() от первого и более длительным сроком хранения.

[gorec2005]

В голову приходит только корявое решение с парой элементов данных: один хранит собственно длинное текстовое значение и имеет минимальный срок хранения (1 день), а второй - calculated item с функцией diff() от первого и более длительным сроком хранения.

Хм... так даже если "короткое" хранение = 1 день при условии частоты опроса раз в минуту это получается 60*24= 1440 значений, а если это умножить на несколько таких полей (firmware rew,mac,hardware rew...) и на несколько сот устройств то получается огромная и бестолковая работа!
а состояние порта (operstate/adminstate) их изменения (в нормальном режиме ) должно быть гораздо меньше 1440 - зачем хранить промежуточные изменения, если большую часть времени значение статично? может есть какое-то стандартное решение вроде:
если предыдущее значение=новому то новое просто не пишем! я понимаю, что это повлечет за собою изменение многих алгоритмов ядра, но если это реализовать на уровне ядра - мне кажется будет ощутимая экономия всех ресурсов (ну или существенное повышение производительности)

[yukra]

может есть какое-то стандартное решение

SNMP-трапы в случае сетевых железок и zabbix-трапы в случае агентов. Изменения произошли - присылаете данные в заббикс, не произошли - не присылаете.

[gorec2005]

SNMP-трапы в случае сетевых железок и zabbix-трапы в случае агентов. Изменения произошли - присылаете данные в заббикс, не произошли - не присылаете.

Это понятно - для мониторинга operstatus, но это только одна сторона... а как быть с железками которые то-же надо мониторить, но они не отдают трапы по изменению параметра (например прошивки)...

[yukra]

Это понятно - для мониторинга operstatus, но это только одна сторона... а как быть с железками которые то-же надо мониторить, но они не отдают трапы по изменению параметра (например прошивки)...

я вижу 2 варианта: 1) Купить диск побольше
2) Сделать внешний скрипт, который будет присылать трап, если он нужен

[gorec2005]

я вижу 2 варианта: 1) Купить диск побольше
2) Сделать внешний скрипт, который будет присылать трап, если он нужен

:-)
да диск то большой, но когда INNO таблица в mysql вырастает за 15 гиг - оно ощутимую нагрузку на систему хранения начинает давать и в результате загрузка bd-sync процессов взлетает, вот и появилось желание попробовать оптимизировать алгоритм хранения...
и первое что пришло в голову это дифференциальное хранение - может кто-то уже с подобным заморачивался? или есть что-то в ядре для реализации этого...
даже если просто периодично удалять из history_uint записи о нулевых значениях value - уже ощутимая разгрузка в моем случае, однако в графиках это выглядит как отсутствие данных вообще... т.е. надо и графики доделывать под такой механизм хранения...
А вообще не могу понять - какой смысл в housekeeper-е, он ведь для своих нужд то-же немало ресурсов расходует, может перенести логику его работы в хранимые процедуры/эвенты/триггеры mysql?

[yukra]

А вообще не могу понять - какой смысл в housekeeper-е, он ведь для своих нужд то-же немало ресурсов расходует, может перенести логику его работы в хранимые процедуры/эвенты/триггеры mysql?

Так вам партиционирование нужно В сети примеров куча.

Зы Вот еще 1 неплохой способ бороться с "большой базой" http://www.slideshare.net/BadooDev/z...badoo-49949205