"Alexey Popov" ...
Khorsun Vlad wrote:
Во-первых *а*приори. Во-вторых - писать из датчика напрямую в БД
это и есть через жопу. Впрочем я выше написал что такое не лечу :)
Буфер есть, но только для нештатных ситуаций.
Я так и не понял, как ты предлагаешь вставлять записи, идущие от датчика например раз в 1 сек? Ждать 10штук, потом оптом
вставлять? Только не это.
Если тебе нужно отражать показания сотен датчиков *немедленно*, то никакая
СУБД тебе не подойдёт. И тысячи файлов тоже, кстати (покажите мне систему,
которая опрашивает одновременно тысячи файлов, часть из которых ещё не создана).
Тебе *придётся* писать агентов, которые будут получать данные с датчиков,
хранить локальную историю показаний, реагировать на мгновенные отклонения и
передавать эти данные в центральный апп-сервер, который уже будет раздавать
их клиентам для отображения. Ну и потом уже спокойно, не торопясь писать данные
в центральную БД для менее срочных отчётов и истории. Но, в первую очередь,
сохранять полученные данные в *локальный* лог, причём без кеширования и иной
буферизации в системе.
Это если ты действительно хочешь постороить *надёжную* *и* *оперативную*
систему. Есс-но, я не претендую на истину в последней инстанции, но поработать
тебе всё равно придётся, и схема хранения данных будет не самым острым вопросом.
Угу, 2^31 анализов за полгода... Сам понял, что написал ?
Ну тогда и нам объясни :)
Вставка И анализы вместе. В распределённой системе (много клиентов и писателей) будет очень непросто контролировать расход номеров
транзакций.
См. выше.
А кто - очень ? NTFS ? Ну так я же не заставляю мучать ФБ, у меня
другой интерес, но ты его не удовлетворяешь (алгоритмы, алгоритмы...).
Для начала нужен всего лишь кластерный индекс по паре (id датчика, время).
Подумай о скорости его обновления, особенно при конкурентном доступе...
Ну сделай выборку за последний день с 20 датчиков. Читая 8x20GB в
сервере приложений :) А, ты будешь каждый день новый файл создавать ?
Внутри файла с показаниями датчика измерения будут лежать в порядке времени. Поэтому полное чтение файла не нужно при выборке по
интервалу времени.
А, массив в файле. Да, можно выкрутиться. Но ты всё равно попробуй.
Создай десяток тысяч скажем мегабайтных файлов и почитай по 1КБ из середины
нескольких десятков. И так - много раз.
А ведь при наличии СУБД (любой, не обязательно ФБ) апп-сервер
становится не нужен.
Мы уже тут очертили основные проблемы на этом пути. Есть три метода:
1) Свалить все измения в одну таблицу.
2) Партиционировать по разным таблицам
3) Аналогично по разным БД
Я приемлю только первый способ. Но его сервер не осилит.
"Я приемлю" - это не аргумент. Думать нужно. И считать. И опять думать.
Впрочем, я твои задачи решать не хочу, тебе жить, да и голова у тебя своя.
Расскажешь потом к чему пришёл и какие хар-ки получил, будет интересно ;)
--
Хорсун Влад.
