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