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

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

"для просмотра изменения параметров во времени, оценки стабильности работы системы" - если "на ходу", то в первую группу, если постфактум, то во вторую.

Как не делать запрос в 10000 точек? допустим процесс медленный (наполнение бочки жидкостью) занимает ну минимум 2 часа а это уже как минимум более 7 тысяч точек. Ведь нельзя запретить пользователю просматривать только 1000 секунд за раз, теряется общая картина происходящего.

а чем лучше делать обработку не в БД? Да же пусть он неспешный, обычно производится вывод нескольких графиков, они просматриваются визуально. Автоматическая обработка от системы не требуется (допустим определение "провалов" или другой какой анализ)

реализовали пока выборка данных из БД.
в БД уже более 26 млн. записей, время выборки суток (86400 точек БД "сжимаются" до 1000 точек) 2 секунды.

iv_an_ru,

спасибо. интересный материал.

pirovindosЗависит от того, какие данные. Например, при простом прореживании, ты не отправишь из БД данные, которые больше всего интересуют пользователя. Какой-нибудь резкий всплеск. Решение нужно принимать исходя из прикладной задачи. Для чего график нужен пользователю?

Подскажите где можно посмотреть алгоритмы прореживания данных?
Важно что бы всплески отображались.
Допустим выводим данные по какому-то более менее стабильному процессу за месяц (более 2 млн. записей в БД), пользователю необходимо просмотреть были ли сильные изменения режимы работы.

pirovindos,

спасибо.
пока думаю сделать так: находить среднее для набора точек и отбирать максимально отличающееся значение от среднего.

неплохая подборка книг по обработке сигналов тынц