оптимизация истории значений переменных

[Amarok]

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

Этот скрипт делает две вещи. Во-первых, выводит информацию о том, сколько данных хранится в таблице и по каким переменным и, во-вторых, оптимизирует (объединяет) устаревающие данные по определённому алгоритму.

Предупреждение: перед началом экспериментов с этим скриптом, сохраните резервную копию таблицы phistory, на всякий случай.

Скрипт нужно распаковать из архива и положить в папку /htdocs/scripts/ и вызывать http://адрес_сервера/scripts/optimize_history.php

Для работы скрипта надо в коде раскоментировать массив $rules, где задаются параметры оптимизации свойств класса
Вот пример моего массива:

Код: Выделить всё

 $rules=array(
  'tempSensors.temp'=>array('optimize'=>'avg'), // оптимизировать значения свойства temp всех объектов класса tempSensors по среднему значению
  'uptime'=>array('keep'=>30, 'optimize'=>'max'), // удалять данные свойства uptime (любого класса), старше 30 дней и оптимизировать остальные по максимальнму значению
  'Relays.status'=>array('keep'=>0), // удалять все данные Relays.status, попавшие в историю
  'WeatherStations.tempOutside'=>array('optimize'=>'avg') // оптимизировать все данные WeatherStations.tempOutside по среднему значению
 );

Таким образом, задаётся класс.свойство (либо только свойство), количество дней хранения (в принципе, это лучше задавать при настройке свойства класса), а так же способ оптимизации (avg/max/sum -- по среднему, по максимальному, по сумме). Оптимизация заключается в том, что система выбирает набор значений за период из истории и заменяет его одним по указанному способу. На данный момент, по коду скрипта заданы жёсткие условия оптимизации, так что для того чтобы их изменить, надо внести соответствующие изменения в код.

Сейчас используется следующаяя "этапность" оптимизации:
1. Данные старше 1 месяца оптимизируются по двух-часовым отрезкам (если за каждые два часа в базе больше чем одно значение, то они все заменяются одним по указанному алгоритму оптимизации -- среднему за период, максимальному, либо сумме значений)
2. Данные старше 1 недели (но младше месяца) оптимизируются по часовым отрезкам.
3. Старше суток (но младше недели) оптимизируются по 20-минутным отрезкам
4. Старше часа (но младше суток) по 3-х минутным отрезкам
5. Младше часа не оптимизируются

В общем, я смог сократить таблицу phistory с 250 000 значений до 60 000, что, теоретически, ускоряет работу системы в целом (особенно построение графиков).

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

[Alex]

Просто отлично. То, что нужно.

[Urbas81]

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

[sergejey]

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

Надо смотреть родительский для объектов класс, в нём вкладку свойства и далее редактировать соответствующее свойство и там есть параметр "Хранить историю (дней)"

[Urbas81]

Спасибо, нашел, стояло 7 дней, интересно, можно восстановить предыдущие данные, если остались резервные sql по некоторым дням, когда происходил перезапуск системы.

[DiArt]

Хочу оптимизировать таблицу с новостями (набралось около ста тысяч записей). Хочу чтобы более 2-х недель новости удалялись.
Таблица rss_items
Столбцы ID, Title, Body, URL и т.д.
В Majordomo Объект ThisNews
ThisNews.NewsHead - имя новости вытаскивается с базы со столбца Title
ThisNews.NewsBody - Тело новости вытаскивается с базы со столбца Body
Как лучше сделать оптимизацию? В таблице или в объекте?
Если сделать так:

Код: Выделить всё

$rules=array(
'ThisNews'=>array('keep'=>15)
);

Он удалит все строки объекта ThisNews старше 15 дней, т.е. теоретически уменьшит таблицу со ста тысяч например до 2 тысяч. Я прав?

[sergejey]

Запись 'ThisNews.NewsHeadr'=>array('keep'=>15) позволит удалять из истории объекта записи старше 15 дней, но на rss_items оно не влияет.

А для чего хранить историю этого объекта в принципе? Пусть себе лежат новости в rss_items.
Последнюю таблицу можно так чистить:
SQLExec("DELETE FROM rss_items WHERE TO_DAYS(NOW())-TO_DAYS(ADDED)>15");

[DiArt]

Просто мне кажется из -за такого большого объёма растёт и сама база. Хотел уменьшить. Вот спасибо за код по очистки базы.

[NightRider]

Запустил скриптик, оптимизировал историю почти с 500 тысяч до 110, супер!

Единственно заметил странность в выводимых сообщениях:

Before last WEEK
Value ID: 176
Interval from 2015-12-21 17:57:57 to 2016-01-13 17:57:58 (every 3600 seconds)
Total values: 1650
Optimizing (should be about 552 records)... . . . . . . . . . . . . . . . . . . . Done (removed: 1686)

[smoker_vvo]

Все бы хорошо...... но заканчивается сообщением что время истекло.... записей более 1000000......
Calculating stats:
systemStates.stateColor (object: Astra): 26109
systemStates.stateColor (object: System): 18
systemStates.stateColor (object: Security): 8
systemStates.stateColor (object: Septic): 294
systemStates.stateColor (object: Communication): 32
tempSensors.temp (object: sensorT4): 40324
tempSensors.direction (object: sensorT4): 41954
tempSensors.updated (object: sensorT4): 42804
tempSensors.updatedTime (object: sensorT4): 42803
tempSensors.temp (object: sensorT0): 10647
tempSensors.direction (object: sensorT0): 42255
tempSensors.updated (object: sensorT0): 44282
tempSensors.updatedTime (object: sensorT0): 44282
tempSensors.temp (object: sensorT1): 2174
tempSensors.direction (object: sensorT1): 43447
tempSensors.updated (object: sensorT1): 43668
tempSensors.updatedTime (object: sensorT1): 43661
tempSensors.temp (object: sensorT2): 1796
tempSensors.direction (object: sensorT2): 32408
tempSensors.updated (object: sensorT2): 32414
tempSensors.updatedTime (object: sensorT2): 32408
tempSensors.temp (object: sensorT3): 6611
tempSensors.direction (object: sensorT3): 47844
tempSensors.updated (object: sensorT3): 48132
tempSensors.updatedTime (object: sensorT3): 48129
tempSensors.temp (object: sensorT5): 6736
tempSensors.direction (object: sensorT5): 39601
tempSensors.updated (object: sensorT5): 40752
tempSensors.updatedTime (object: sensorT5): 40751
tempSensors.temp (object: sensorT6): 1898
tempSensors.direction (object: sensorT6): 41206
tempSensors.updated (object: sensorT6): 42476
tempSensors.updatedTime (object: sensorT6): 42476
tempSensors.temp (object: sensorT7): 48836
tempSensors.direction (object: sensorT7): 48938
tempSensors.updated (object: sensorT7): 51222
tempSensors.updatedTime (object: sensorT7): 51219
keySensor.status (object: sensorSeptic): 2
systemStates.stateColor (object: ALM): 21
keySensor.status (object: sensorPereliv): 3

Grand-total: 1244501

И тут возник вопрос... а можно как то конкретные записи чистить?? КАК?