"Alexey Popov" ...
Khorsun Vlad wrote:
Если тебе нужно отражать показания сотен датчиков *немедленно*, то никакая
СУБД тебе не подойдёт.
Это ещё почему?
Потому что ты ещё и хочешь потоковый анализ показаний делать, насколько я
понял. Т.е. кто-то должен держать в памяти последние N показаний, и *быстро*
реагировать на резкие их изменения. Вытягивать каждый раз их из СУБД - напрасная
трата времени.
Впрочем это уже мои домыслы, сам думай :)
Вполне быстро можно выбрать 100 последных записей по индексу. Минимальный уровень латентности не реалтаймовский, но и 10сек это
много. Все показания отображать не надо, только те, которые выбрали активные юзеры.
Вообщем мгновенной производительности БД вполне хватает чтобы преваривать
оцениваемый поток данных.
Ты уж определись - хватает, или не хватает ? :-D
Единственная видимая пока грабля - предел номера транзакции, которая хотя
вылезет через годы, но тоже неприятно.
Раз в год сделать бекап\рестор не смертельно. Заодно с удалением совсем
старых данных.
Тебе *придётся* писать агентов, которые будут получать данные с датчиков,
хранить локальную историю показаний, реагировать на мгновенные отклонения и
передавать эти данные в центральный апп-сервер, который уже будет раздавать
их клиентам для отображения. Ну и потом уже спокойно, не торопясь писать данные
в центральную БД для менее срочных отчётов и истории. Но, в первую очередь,
сохранять полученные данные в *локальный* лог, причём без кеширования и иной
буферизации в системе.
Это только если поток данных столь высок, что БД не справится.
Нет. Это на тот случай, если ляжет сеть или СУБД будет в оффлайне по другой
причине.
Для начала нужен всего лишь кластерный индекс по паре (id датчика, время).
Подумай о скорости его обновления, особенно при конкурентном доступе...
Дык смотря как его реализовать. Например в виде индекса, но вместе с данными.
Это и есть кластерный индекс :-D
Причём страницы аллоцировать сразу помногу, чтобы уменьшить разброс по диску.
Не поможет, в общем случае. Никто не гарантирует строго последовательной
вставки
ключей строго в конец индекса. А если таки так и будет, то получишь большую
конкуренцию
за ту самую последнюю страницу, плюс за путь доступа к ней.
Расскажешь потом к чему пришёл и какие хар-ки получил, будет интересно ;)
У есть менее нагруженная аналогичная система. При тестировании на слабом железе вылезают ньюансы связанные механизмом работы
индесов в FB, которые негде толком не расписаны. Вот я спрашивал уже:
http://groups.google.com/group/ru-firebird/browse_thread/thread/b88a40cf580fbd30
И что тебе там не объяснили ?
--
Хорсун Влад
