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