Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД для потока данных от датчиков/сенсоров / 24 сообщений из 24, страница 1 из 1
07.06.2007, 14:39
    #34581140
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
Здравствуйте.

Мне предстоит задача разработать некую БД для хранения потока данных от сенсоров.
Предполагается что будет несколько (пока не известно сколько, но что более 100 точно) объектов у которых будет по несколько сенсоров.

Беспокоит то, что поток получается довольно большой... Т.е. каждый объект скидывает показания своих сенсоров раз секунд в 10.

Как бы лучше все это организовать?
И вообще стоит ли использовать РСУБД для таких задач?

От данных потребуется:
- Оперативная информация (т.е. состояние сенсоров на текущий момент)
- В дальнейшем аналитика по этим данным (ну там про отклонения от нормы и.т.д)

Сейчас склоняюсь к тому, чтобы разделить систему как можно сильнее.
В том смысле, что для каждого объекта заводить свою БД и хранить данные только для этого объекта.

Даст ли это какой-либо выигрыш?

Будут ли еще идеи/ссылки о том, как лучше организовать подобную систему?

Заранее благодарен.
...
Рейтинг: 0 / 0
07.06.2007, 16:58
    #34581801
Интересно
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
имхо стоит использовать. ~ 300-500 инсертов в 10 сек? нормально. 100 баз это круто :(
как они будут инсертиться? из одной проги все скопом или каждый датчик сам будет пихать в базу отдельно?
...
Рейтинг: 0 / 0
07.06.2007, 17:24
    #34581903
мод
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
anonymouzБудут ли еще идеи/ссылки о том, как лучше организовать подобную систему?

Стандартный подход - буферизация. Данные пишем в ОП, изредка скидываем в БД.
...
Рейтинг: 0 / 0
07.06.2007, 20:38
    #34582407
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
автор100 баз это круто :(
всмысле это плохо?
чем плохо?

Просто на сколько я понимаю у любого хостера крутится баз поболее...

А при таком подходе если мне понадобятся данные по одному из объектов, данные об остальных "мешать не будут"...
Или я совсем не прав?

авторкак они будут инсертиться? из одной проги все скопом или каждый датчик сам будет пихать в базу отдельно?
предполагается что будет сервер (отдельная прога), к которому будут цепляться датчики через интернет. В БД будет скидывать уже сервер...
+ от этого есть еще один...
Данных с сенсоров идет несколько потоков. По некоторым потокам не нужны настолько детализированные данные, и поэтому часть из них можно отбрасывать уже на нем.
...
Рейтинг: 0 / 0
07.06.2007, 20:40
    #34582411
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
модСтандартный подход - буферизация. Данные пишем в ОП, изредка скидываем в БД.

ОП == оперативная память?
...
Рейтинг: 0 / 0
07.06.2007, 21:16
    #34582463
Yuraz.com
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
У нас как делается:
1. разбивается на глубину хранения, примерно так: за неделю храним секундные
данные, за 3 месяца 10 сек, за год - минутные
2. Секундные данные хранятся в двоичных данных, типа БДРВ (база данных
реального времени), непрерывно крутится софтина, которая высчитывает среднее
за 10 сек, и кидает это в MSSQL.
3. В MSSQL данные 10 сек - новые пишутся, старые от 3 мес - стираются.
В кратце так.

К слову, 10сек база отдельная, минутная тоже отдельная. Всего более 700
каналов данных. Разнесено на 3 сервера в каждом по 4 процессора, вроде все
фурычит годами, есть конечно проблемы, но не значительные.


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.06.2007, 22:49
    #34582603
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
О какой СУБД идёт речь? Оракл умеет работать с VLDB (очень большие БД) и нет надобности поднимать кучу экземпляров для каждого объекта учёта.

Несколько БД может создать проблему согласованности.

Возможно, текущее состояние имеет смысл отражать непосредственно в БД, тогда как отдельные сообщения можно накапливать в файлах, и время от времени обрабатывать их и скопом загружать в БД для дальнейшего анализа.
...
Рейтинг: 0 / 0
08.06.2007, 05:31
    #34582793
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
Кстати, подумал о буферизации...

А как тогда отображать текущее состояние?
...
Рейтинг: 0 / 0
08.06.2007, 05:36
    #34582795
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
Yuraz.comК слову, 10сек база отдельная, минутная тоже отдельная. Всего более 700
каналов данных.

При 100 объектах у меня получается как раз порядка 300-700 (зависит от датчика) каналов данных...

Yuraz.comРазнесено на 3 сервера
С помощью чего разнесены?
На уровне СУБД или еще как?
...
Рейтинг: 0 / 0
08.06.2007, 05:42
    #34582797
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
mcureenabО какой СУБД идёт речь?
Склоняюсь к PostgreSQL

mcureenabОракл умеет работать с VLDB (очень большие БД) и нет надобности поднимать кучу экземпляров для каждого объекта учёта.
Можно по подробнее что значит "поднимать кучу экземпляров для _каждого_ объекта учёта."

Я имел ввиду что для одного объекта -- одна БД

[quot mcureenab]Несколько БД может создать проблему согласованности.[/quote]
Как раз и хотелось бы знать проблемы какого рода могут возникнуть...

[quot mcureenab]Возможно, текущее состояние имеет смысл отражать непосредственно в БД, тогда как отдельные сообщения можно накапливать в файлах[/quote]
Так вообщем и собираюсь...
Только не в файлы... Хранить в оперативной памяти... Проводить некую агрегацию, потом уже кидать в БД.
...
Рейтинг: 0 / 0
08.06.2007, 16:45
    #34584661
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
anonymouzМожно по подробнее что значит "поднимать кучу экземпляров для _каждого_ объекта учёта."

Я имел ввиду что для одного объекта -- одна БД


Оракл под БД понимает набор файлов данных, оперативных и архивных журналов и контрольные файлы. Под экземпляром понимает структуры в оперативной памяти и набор процессов.
Если мы запустили notepad.exe два раза, то пулучили два экземпляра notepad.exe.
Есть ещё понятие схемы, это некое именованное пространство имён. В разных схемах одной БД можно определить разные одноимённые объекты. Я часто встречал людей, которые по привычке схему называли БД, хотя в оракле все схемы БД образуют единую, согласованную БД.

anonymouz[quot mcureenab]Возможно, текущее состояние имеет смысл отражать непосредственно в БД, тогда как отдельные сообщения можно накапливать в файлах[/quote]
Так вообщем и собираюсь...
Только не в файлы... Хранить в оперативной памяти... Проводить некую агрегацию, потом уже кидать в БД.

Как угодно. Зависит от требований к надёжности/производительности. Если накапливать большие объёмы данных в оперативной памяти, то в случае сбоя велик риск потерять слишком много данных. После такой потери оперативные и исторические данные могут оказаться противоречивыми. Т.е. по неполной истории видим, что сенсор показывает, положим 58C, а по оперативным данным зафиксированным в БД - 60C. Нестыковочка, ибо данные несогласованы. В прочем, этот вопрос почти полностью решается на уровне правильного построения распределённых транзакций.
...
Рейтинг: 0 / 0
10.06.2007, 07:43
    #34587013
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
[quot mcureenab]Оракл под БД понимает набор файлов данных, оперативных и архивных журналов и контрольные файлы. Под экземпляром понимает структуры в оперативной памяти и набор процессов.
Если мы запустили notepad.exe два раза, то пулучили два экземпляра notepad.exe.
Есть ещё понятие схемы, это некое именованное пространство имён. В разных схемах одной БД можно определить разные одноимённые объекты. Я часто встречал людей, которые по привычке схему называли БД, хотя в оракле все схемы БД образуют единую, согласованную БД.[/quote]

Спасибо про разъяснения насчет экземпляров. Про схемы я знал (по postgres).

[quot mcureenab]Как угодно. Зависит от требований к надёжности/производительности. Если накапливать большие объёмы данных в оперативной памяти, то в случае сбоя велик риск потерять слишком много данных.[/quote]
Если писать в файлы, надежность не повышается (данные то все равно буферизируются), а вот нагрузка на дисковую подсистему возврастает.
Да и надежность ИМХО другими способами лучше организовывать...

Вообщем всем спасибо за помощь...
...
Рейтинг: 0 / 0
13.06.2007, 10:43
    #34590921
dc93
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
По БД на каждый сенсор, имхо, имеет смысл заводить, если в будущем есть вероятность, что несколько сенсоров может "переехать" куда подальше...

но, даже в этом случае, я бы ограничился бы одной базой.

зы в качестве off: существуют специальные энергонезависимые буфера, которые хранят данные, пока их с них не заберут
...
Рейтинг: 0 / 0
15.06.2007, 07:29
    #34596398
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
Сенсоры и так будут не близко. Канал связи gprs.

Просто я думаю если количество объектов увеличится значительно увеличится, то гораздо проще будет масштабировать систему с такой структурой.

Жаль, что никто так и не ответил на вопрос плохая это идея или нет (и почему)... :(

зы в качестве off: существуют специальные энергонезависимые буфера, которые хранят данные, пока их с них не заберут

а можно поподробнее?
...
Рейтинг: 0 / 0
15.06.2007, 12:16
    #34597187
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
У меня была похожая задача и мы пришли к тому что:
- Самое оптимальное - это буферизировать данные и писать в БД только макс/мин/тек значения за период (каждые 10-30 сек.)
- Можно еще попробовать писать в несколько потоков.

Почему много баз - это плохо:
1. Сложность настройки при добавлении нового датчика/объекта
2. Сложность/невозможность консолидации информации
3. Сложность управления консолидированной БД (изменение справочноков и т.д.)
4. Не намного увеличится производительность, если все это будет на одной машине, т.к. сетевуха одна и проц один
...
Рейтинг: 0 / 0
15.06.2007, 13:04
    #34597416
sn175
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
А почему не использовать уже существующие промышленные БД для хранения исторических данных?

Например, посмотрите по ссылке обсуждение таких БД:
http://iprog.pp.ru/forum/read.php?f=1&i=15386&t=15196&v=t

Или, если хотите использовать собственную разработку, посмотрите какую БД используют готовые коммерческие решения.

Например:
http://]http://www.complexsystems.ru/unidb.html
...
Рейтинг: 0 / 0
18.06.2007, 13:47
    #34601803
ex_dc93
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
anonymouz

а можно поподробнее?


меня забанили :(
...
Рейтинг: 0 / 0
19.06.2007, 10:27
    #34603770
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
basСамое оптимальное - это буферизировать данные и писать в БД только макс/мин/тек значения за период
Писать надо все. В любом случае...
basМожно еще попробовать писать в несколько потоков.
В БД? Т.е. вроде сделать вроде пула соединений и его пользовать?
Сейчас не об этом речь...
bas1. Сложность настройки при добавлении нового датчика/объекта
А в чем сложность, если подобный функционал заложить изначально?
bas2. Сложность/невозможность консолидации информации
Над этим надо подумать...
bas3. Сложность управления консолидированной БД (изменение справочноков и т.д.)
Ну это вроде не проблема...
автор4. Не намного увеличится производительность, если все это будет на одной машине, т.к. сетевуха одна и проц один
Это понятно... Но хочется сделать так, чтоб система масштабировалась довольно легко...

Такой подход позволит довольно безболезненно этого добиться... Ставим еще один сервер для БД и все...

А если будет одна база, как можно заложить "масштабируемость" на начальном этапе проектирования системы?
...
Рейтинг: 0 / 0
19.06.2007, 10:28
    #34603771
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
2 sn175
спасибо, посмотрю...
...
Рейтинг: 0 / 0
19.06.2007, 11:58
    #34604235
Bely
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
anonymouzА если будет одна база, как можно заложить "масштабируемость" на начальном этапе проектирования системы?Кластер спасет отца русской демократии.
Или просто многопроцессорные системы с внешними DataStorage.
По этому поводу железок много наработано, а нормальные СУБД умеют ими пользоваться.
...
Рейтинг: 0 / 0
19.06.2007, 17:29
    #34605729
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
Bely anonymouzА если будет одна база, как можно заложить "масштабируемость" на начальном этапе проектирования системы?Кластер спасет отца русской демократии.
Или просто многопроцессорные системы с внешними DataStorage.
По этому поводу железок много наработано, а нормальные СУБД умеют ими пользоваться.

Кластер не поможет для OLTP систем. Тут узкое место будет доступ к данным на запись и блокировки. Так что это не выход. Мы пробовали ....
...
Рейтинг: 0 / 0
19.06.2007, 18:20
    #34605914
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
anonymouz basСамое оптимальное - это буферизировать данные и писать в БД только макс/мин/тек значения за период
Писать надо все. В любом случае...

Зачем??

anonymouz
bas3. Сложность управления консолидированной БД (изменение справочноков и т.д.)
Ну это вроде не проблема...

Что не проблема??? Т.е. у вас будет еще одна БД со справочниками??

авторА если будет одна база, как можно заложить "масштабируемость" на начальном этапе проектирования системы?
Надо понять нужна ли она и на сколько. Потом провести следственный эксперимент по максимуму. У вас же получается 1000 записей в сек. - это легко обрабатывает один более-менее приличный сервер.
...
Рейтинг: 0 / 0
19.06.2007, 19:16
    #34606022
Bely
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
bas Bely anonymouzА если будет одна база, как можно заложить "масштабируемость" на начальном этапе проектирования системы?Кластер спасет отца русской демократии.
Или просто многопроцессорные системы с внешними DataStorage.
По этому поводу железок много наработано, а нормальные СУБД умеют ими пользоваться.

Кластер не поможет для OLTP систем. Тут узкое место будет доступ к данным на запись и блокировки. Так что это не выход. Мы пробовали ....Расскажите как именно пробовали.
Мне кажется, что кластер + внешний накопитель(ели) + партиционирование + распаралеливание потоков к накопителям - вполне могут справиться с задачей приема потока данных с датчиков в одну БД.

Где тут блокировкам взяться - я тожен не очень понимаю, если делать все по нормальному.
...
Рейтинг: 0 / 0
22.06.2007, 13:13
    #34613479
anonymouz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД для потока данных от датчиков/сенсоров
Всем спасибо за участие.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД для потока данных от датчиков/сенсоров / 24 сообщений из 24, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]