могу показаться назойливым, но, как я уже писал (да и не только я), твоя
главная проблема - операции с диском, соответственно надо думать в двух
направлениях
1. ускорить дисковую подсистему (тут уже по этому поводу рекомендации
давали) - это даст определеный выйгрышь, но полностью не решит задачу за
тебя
2. уменьшить количество дисковых операций и разнести их более равномерно во
времени (если у тебя 24х7 система, то абсолютно нелогично делать ночные
плановые операции по сборке мусора).
при таком подходе к разработке самым лучшим решением для тебя будет
использовать плоские файлы - таким образом достигнешь максимальной скорости
(за счет предельного уменьшения количества дисковых операций). Разбей,
например, все данные по часам (насколько я помню тебе надо только 7 дней), у
тебя получится 168 файлов и накапливай там инфу по револьверному принципу.
Файлы добавляются с каждым часом, перевалил через неделю - удалил
соответствующий файл, потом следующий и т.д. Как только приходит запрос
просмотреть состояние датчиков, выбираешь интересующий час, закачиваешь
клиенту файл, там парсишь (данные можно хранить в максимально подготовленном
к этой операции виде) и строишь тренд.
Это будет самый быстрый способ. Но если все-таки хочешь в работе
использовать СУБД, то необходимо понять и принять, что СУБД, для управления
данными, выполняет ряд дополнительных операций, объем которых зачастую
превышает объем "полезных" операций. Соответственно базу необходимо
проектировать, а не просто создать одну единственную таблицу и надеятся, что
сервер все сделает за тебя.
Например, на вопрос за какой промежуток времени могут понадобиться данные ты
пишешь "обычно все пляшет вокруг пары часов, в худших случаях - до дней". Ты
прикидывал сколько записей тебе придется прокачать на клиента? Миллионы...
сколько времени на это уйдет???? товарищь будет не рад что задал такой
вопрос "какой же там тренд за сутки?". Куда логичнее иметь в базе таблице
где бы данные были уже подготовлены к просмотру с необходимой точностью.
Условно говоря усредненные значения по датчикам за сутки, 2 часа, 15 минут
(т.е. 3 таблицы). Соответственно отдавть клиенту подготовленные данные с
такой же точностью. Если надо оценить общую ситуацию за неделю - значит
берем данные из таблицы по дням, если за последние пару часов - из таблицы с
15-и минутным интервалом, просмотреть сотояние датчиков - исходные данные.
Заполнение таблиц с подготовленными отчетами можно конечно поставить по
расписанию, если периоды анализа небольшие - это в принципе допустимо, но
если ты попытаешься это сделать за сутки, можешь всерьез и надолго поставить
систему раком. Мое мнение в этом плане - лучше заполнять эти таблицы
он-лайн, т.е. так только появляется новая информация по датчику, сразу же
идет пересчет (update) в таблицах с отчетами. Это конечно же добавит версий,
но поскольку операции во ремении более равномерно распределяются, серверу
будет куда проще все это проглотить (и не поперхнуться).
Далее - нафига тебе 3 индекса, да еще подозреваю составных, на грязные
данные????? Оставь только ОДИН по времени, все операции, которые ты
выполняешь над этой таблицей полностью покрываются этим индексом. Во-первых,
ты уменьшаешь количество структур и, соответственно, объем данных на диске.
За счет этого (не могу утверждать однозначно, но ориентируясь на свои
эксперименты с большими объемами) ты сократишь на 60% время удаления
устаревших данных. Во-вторых, если необходим диапазонный поиск (аля
between), то ФБ с индексами работает далеко не так идеально как хотелось бы,
особенно с составными. Если парметр времени в индексе не один (т.е. индекс
составной) то для диапазонной выборки такой индекс фактически не работает
совсем. В-третьих, время (я так понимаю timestamp) - это составной параметр,
можно попробовать (вот здесь надо будет эксперементировать) добавить еще
одно поле в таблицу - номер минуты, например от 2008 года. Интежера будет
достаточно на тысячи лет вперед. По нему и строить индекс, а поиск проводить
по этому полю с уточнением по времени.
Насчет разделения данных по таблицам здесь уже много писали, повторяться не
буду. Только вот не помню почему была отвергнута идея хранить данные по
каждому датчику+параметру в отдельной таблице (таблиц конечно же много
будет, но работать с ними может даже и проще).
и последнее. Опять же уже писалось, но повторюсь.
Если данные заходят с с такой интенсивностью и равномерно в течение суток,
то и выходить они оттуда должны соответственно. Вполне логично, что пытаясь
удалить накопившуюся инфу за сутки ты ставишь сервер в такую позу из которой
он не может выйти очень долго. Удаляй данные пропорционально их добавлению.
Например если задачу очистки поставить раз в 10 мин. - серверу будет надо
удалить 170.000 записей (исходя из твоих исходных данных). Серверу будет
куда проще пережевать такой объем и через 10 мин. быть готовым к повторению
этой операции (естественно с учетом, что он продолжает добавлять).
