Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Система собирает данные с железки, которая подключена к ноутбуку. Количество данных около 1000 цифирь в секунду. Время сбора около 20 минут. Хотелось бы все это затолкать в БД, поскольку потом их (цифири) нужно долго маслать, анализировать, хранить и т.д.
Итого:
1. Бесплатно
2. Маленький вес и малая прожорливость (усё пашет на буках)
3. Чтоб не опустила рога от напруги (за 20 минут приходит 1 200 000 данных)
Drinkins
Итого:
1. Бесплатно
2. Маленький вес и малая прожорливость (усё пашет на буках)
3. Чтоб не опустила рога от напруги (за 20 минут приходит 1 200 000 данных)
рекомендации + линки плз
При таких ИТОГО я думаю, что вас спасет только DBF - формат...
Если нужно за 20 мин собрать 1.2М цифр, а следующий сбор буедт через несколько часов, то лучше всего писать в txt файл, а затем импортировать из файла в любую СУБД.
Александр СпелицинЕсли нужно за 20 мин собрать 1.2М цифр, а следующий сбор буедт через несколько часов, то лучше всего писать в txt файл, а затем импортировать из файла в любую СУБД.
Вы правы что в БД данные лучше писать не налету, а перегонять после съема, но вот в какую БД? (итого остаётся неизменным)
Александр СпелицинА с какой периодичностью делаете изменения? Т.е. как часто наступают эти 20 минут?
Это зависит от оператора, будет ли он повторять измерение или нет.
Думаю для чистоты измерений будет как минимум 3 повтора. (эти 20 минут)
И все это с периодичностью 1 раз в день.
А точно ли в дальнейшем для истории потребуется хранить все эти бешеные миллионы чисел? Может, их целесообразно как-то агрегировать?
Тогда вырисовывается примерно такая схема. Первичный вывод в txt или dbf, затем процедура закачивания в промежуточную таблицу БД-хранилища, затем агрегирование и перенос на постоянное место хранения.
3Mb * 3повтора * 22раб.дня * 12 мес = 2376 МБ в год. Но если в результате агрегирования от 3 Мб останется 200 Кб, то это всего лишь примерно 160 Мб в год. С учетом того, что индексы тоже место занимают, лет на 10 (плюс-минус) хватит СУБД с БД, ограниченной размером 2 Гб.
Первичные файлы тоже не выбрасываем, а архивируем и собираем для истории, как есть.
Александр СпелицинМожет все-таки посмотреть на платные СУБД? Хотя бы для одног центрального хранилища.
А операторы пусть раз в неделю сливают их данные с ноутов и чистят их базы.
Там уже и *.mdb и MSDE и IB можно будет поставить.
с центральным хранилищем байга еще та будет, эти измерительные системы расползутся по клиентам, так потом на сопровождении жизнь потерять можно, поэтому склоняемся к однопользовательскому варианту
Urri
3Mb * 3повтора * 22раб.дня * 12 мес = 2376 МБ в год. Но если в результате агрегирования от 3 Мб останется 200 Кб, то это всего лишь примерно 160 Мб в год. С учетом того, что индексы тоже место занимают, лет на 10 (плюс-минус) хватит СУБД с БД, ограниченной размером 2 Гб.
Первичные файлы тоже не выбрасываем, а архивируем и собираем для истории, как есть.
Низя. Данные нужны в чистом виде, идут под анализ, даже годичной давности..
наука ёптыть
Александр Спелицин3Mb * 3повтора * 22раб.дня * 12 мес = 2376 МБ в год.
Это на одного оператора.
Значит *.dbf, *.mdb отпадают. MSDE тоже.А почему MSDE отпадает?
mir Александр Спелицин3Mb * 3повтора * 22раб.дня * 12 мес = 2376 МБ в год.
Это на одного оператора.
Значит *.dbf, *.mdb отпадают. MSDE тоже.А почему MSDE отпадает?А потому что размер базы ограничен 2-мя или 4-мя Гб (в зависимости от версии).
Итого: начитался в дым, диаметр головы увеличился на 40%...
думаю использовать firebird embendded, но вот вопрос
что лучше использовать для доступа к нему DBExpress, IBX, али FIBPlus?
буду рад советам, ибо "грабли - если их нет, то они сразу есть"
DrinkinsСистема собирает данные с железки, которая подключена к ноутбуку. Количество данных около 1000 цифирь в секунду. Время сбора около 20 минут. Хотелось бы все это затолкать в БД, поскольку потом их (цифири) нужно долго маслать, анализировать, хранить и т.д.
Итого:
1. Бесплатно
2. Маленький вес и малая прожорливость (усё пашет на буках)
3. Чтоб не опустила рога от напруги (за 20 минут приходит 1 200 000 данных)
рекомендации + линки плз
Писал такую задачу на FoxPro (DBF) - собирались данные с датчиков... За час более 10 Mb... Ничего, все просто летало - хотя ноутбуки были очень старые...
Потом через Web service передавал на удаленный сервер, иногда несколько сеансов, так-как связь у нас была очень плохая...
DrinkinsИтого: начитался в дым, диаметр головы увеличился на 40%...
думаю использовать firebird embendded, но вот вопрос
что лучше использовать для доступа к нему DBExpress, IBX, али FIBPlus?
буду рад советам, ибо "грабли - если их нет, то они сразу есть"
FireBird только не embendded. А про компоненты доступа что лучше использовать спросить непосредственно на форуме IB/FB. Там люди отзывчивые :-), если сразу не пошлют, то обязательно ответят. :-)
