Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Сбор данных с удалённых машин  [new]
javamachine
Member

Откуда:
Сообщений: 4
Имеется система цифровой обработки данных. Устроена она следующим образом: "в поле" расставлено несколько датчиков, которые через АЦП подключены к embedded-компу класса Pentium-2 с 256Mb RAM.

На компе под OS WinXP Embedded вертится СУБД MySQL, в которой существует БД с одной таблицей. Данные для этой таблицы генерит си-приложение (оно дёргает СУБД через ODBC API). Такая штука (датчик + АЦП + комп с СУБД) называется станцией сбора данных.

За одну секунду нужно добавлять в таблицу тысячу записей (каждый кортеж состоит из десятка INTов). Сеанс наблюдений (сбор данных с датчиков) продолжается сутки (итого из расчёта 1000 записей в секунду имеем около ста миллионов записей максимум в таблицы). В ходе сеанса сами данные никак не модифицирутся. После окончания сеанса информация из таблицы экспортируется в файлы с архивами, а сама таблица сносится ко всем чертям.

Во время сеанса к СУБД по TCP/IP снаружи подключается агент, который копирует всю информацию из БД станции сбора данных в центральное хранилище - единую центральную БД всей системы. Центральная БД устроена также, как и БД станций сбора данных, с точностью до добавления в кортеж нового поля - номера станции, с которой пришла запись. Датчиков в системе не более десяти, соответственно, за сеанс наблюдений (сутки), в базу может поступить до миллиарда записей.

В качестве СУБД в данный момент используется MySQL 5. Для перетаскивания данных с датчика в БД станции сбора в данный момент применяется ODBC API. Данные вставляются длиннющим запросом "INSERT ...", в котором на вставку передаётся тысяча кортежей. Запрос вызывается, соответственно, раз в секунду.

Центральное хранилище - это комп класса Intel Core 2 Duo, работающий под Linux. Там сейчас тоже крутится MySQL 5. Соответственно, агент перекачки в данный момент делает следующее: раз в секунду он лезет в БД на станциях сбора данных, забирает из таблицы последнюю тысячу записей, парсит результат, добавляет к каждой записи номер станции сбора, с которой эта запись пришла, после чего вызывает несколько (по числу станций сбора данных) INSERT'ов, каждый из которых вставляет тысячу кортежей.

Кортежи перекидываются с датчиков в локальные БД станций и из локальных БД станций в центральную не по одному кортежу, а пачками по тысяче кортежей в целях экономии ресурсов (в тысячу раз меньше запросов).

Данные из центрального хранилища периодически (сейчас - это снова раз в секунду) забираются запросом "SELECT * FROM mytable ORDER BY TIME LIMIT ?, 1000" и передаются на вход блоку бизнес-логики, который занимается всей дальнейшей их обработкой.

Всё это хозяйство работает медленнее, чем хотелось бы. Полного загрузочного тестирования я ещё не производил, но боюсь, что система с ним не справится. В связи с этим очень прошу порекомендовать мне какие-нибудь решения для данной ситуации.

В частности, возникают следующие вопросы: какую СУБД стоит использовать для подобных задач;
какие настройки (в общих словах: тип таблиц, etc.) вы порекомендуете использовать и почему?

А если более глобально - как бы вы решали подобную задачу (передача данных с удалённых объектов по TCP/IP c целью их дальнейшей обработки)?
13 ноя 08, 14:10    [6435037]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
Yo.!
Guest
ну так вы выяснили где слабое звено ? скорее всего это одбц через медленный нетворк. что бы писать с датчиков вероятно субд не нужна, можно писать тупо в файл, его упаковывать и перекидывать на центральный сервер (через smb, ftp или по взрослому например через soap with attachments)
центральному серверу с запросом "SELECT * FROM mytable ORDER BY TIME LIMIT ?, 1000" думаю будет пофигу, что за субд на фоне тормозов одбц.
13 ноя 08, 16:41    [6436448]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
javamachine

А если более глобально - как бы вы решали подобную задачу (передача данных с удалённых объектов по TCP/IP c целью их дальнейшей обработки)?

Народ решал так
https://www.sql.ru/forum/actualthread.aspx?bid=36&tid=438245&hl=%e4%e0%f2%f7%e8%ea
https://www.sql.ru/forum/actualthread.aspx?bid=36&tid=53525&hl=%e4%e0%f2%f7%e8%ea
https://www.sql.ru/forum/actualthread.aspx?bid=36&tid=36235&hl=sti
13 ноя 08, 21:43    [6438120]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 939
Yo.!
... что бы писать с датчиков вероятно субд не нужна, можно писать тупо в файл, его упаковывать и перекидывать на центральный сервер (через smb, ftp или по взрослому например через soap with attachments)..

+1024
пишите а файл, желательно так, чтобы по названию можно было определить какая станция и за какой промежуток времени, его в архив, и пусть ползёт на центральный сервер.
а "сервер" их открывает, и к себе в базу сливает, либо сразу напрямую файлы в блок "бизнеслогики", а вот от туда, результаты в СУБД.
это будет точно быстрее чем с СУБД + ODBC.
13 ноя 08, 22:28    [6438226]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
javamachine
Member

Откуда:
Сообщений: 4
Господа, всех благодарю за помощь!
14 ноя 08, 00:33    [6438485]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
еще лучше сразу в архив сливать без промежуточных файлов. упаковываться будет на ура.
14 ноя 08, 02:08    [6438568]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
немой
Member

Откуда: от туда.
Сообщений: 73
Имхо, тут напрашивается цепочка простейшая:
датчик - сервер (читает на порту пишет по TCP в центральную базу) - сервер.
Вот и все.. зачем что-то городить то?
11 дек 08, 21:40    [6559473]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
скорее всего это одбц через медленный нетворк. что бы писать с датчиков вероятно субд не нужна, можно писать тупо в файл, его упаковывать и перекидывать на центральный сервер (через smb, ftp или по взрослому например через soap with attachments)
центральному серверу с запросом "SELECT * FROM mytable ORDER BY TIME LIMIT ?, 1000" думаю будет пофигу, что за субд на фоне тормозов одбц.
Полностью поддерживаю. Результаты формируют файлы с заданной дискретностью, файлы асинхронно формированию заливаются на сервер по любому протоколу, чем ниже уровень - тем быстрее. Удаляются по подтверждению приема с проверкой целостности или перезаливаются при его отсутствии.
На сервере данные парсятся и заливаются в базу через нативную утилиту/API СУБД - обычно это быстрее в разы. ODBC - не надо :)
javamachine
Данные из центрального хранилища периодически (сейчас - это снова раз в секунду) забираются запросом "SELECT * FROM mytable ORDER BY TIME LIMIT ?, 1000" и передаются на вход блоку бизнес-логики, который занимается всей дальнейшей их обработкой.
А зачем? Разве по сырым данным строятся отчеты? Гораздо логичнее так и хранить их - в BLOB'ах, м.б. сжатых, для архива. Экономия времени и объема на индексах и ключевых полях - колоссальная. Как промежуточный вариант - в XML, но только если СУБД поддерживает его native хранение. А уже обработанные парсером порции раскладывать в БД для аналитики.
немой
Имхо, тут напрашивается цепочка простейшая:
датчик - сервер (читает на порту пишет по TCP в центральную базу) - сервер.
Вот и все.. зачем что-то городить то?
IP в полях, как бы это помягче, в наших широтах не надежен :) Промежуточные файлы нужны для асинхронности передачи, повтора заливки при ошибках и выживания не отправленных данных при сбоях сети/оборудования.
12 дек 08, 14:55    [6563418]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
немой
Member

Откуда: от туда.
Сообщений: 73
Favn
IP в полях, как бы это помягче, в наших широтах не надежен :) Промежуточные файлы нужны для асинхронности передачи, повтора заливки при ошибках и выживания не отправленных данных при сбоях сети/оборудования.

Вы наверно не поняли..
Это уже пройденный этап и все складно работает.
Стоит машина и на 232-порту слушает датчик (или их множество, но тут уже общую шину надо и есно собирать это с 485 на 232, но это нюансы). Принимает он эти данные, обрабатывает (а логику уж там можно реализовать любую) и по заданному алгоритму ( у меня тупо по времени) посылает данные, т.е. фактически пишет, на сервер СУБД (у меня сразу в базу пишет, если обрыв связи, а есть клиенты разнесенные на 50 км.. то пишет в локальную БД, потом просто открывает транзакцию и досылает данные).. отдельно у меня был открыт серверный поток для клиентов, которые в любой момент времени могли в реальном времени читать данные с датчиков (ка), т.е. это фактически вьющки, которые могли получать данные и только их отображать.
Ну а уж как сделать идентификацию – тут гораздо все проще – каждый клиент может иметь свой номер, который будет ID в базе.. в общем – задача тривиальная, на «пару дней работы».
12 дек 08, 19:36    [6565373]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
Степан H.
Member

Откуда: Министерство Хунты❄
Сообщений: 1371
javamachine,

дочитав до
автор
Всё это хозяйство работает медленнее, чем хотелось бы.

я уже сомнивался в том, что оно вообще работает )) .... однако, я б (делал) сделал так.
1. выбросить на удаленных компах базу
2. писать данные в файл, потом архивировать (или писать в архив)
3. файл на сервере в базу вставлять одной транзакцией (в Postgres метод COPY)
4. в зависимости от способов дальнейшей обработки попробуйте использовать партицирование.
5. в зависимоти от того что нужно получить в "конечном итоге" попробуйте "размазать" нагрузку проца на сервере "по времени", тоесть не "напрягать" его, допустим, "раз в час" а чтоб постоянно занимался "предобработкой" данных, например на триггерном уровне. Бизнес-логика должна быть построена внутри самой СУБД.

п.5 возможно неактуальный
21 дек 08, 23:42    [6600814]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
немой
Member

Откуда: от туда.
Сообщений: 73
Степан H.

я уже сомнивался в том, что оно вообще работает )) ....

Конечно, при заявленном времени,... Это и не должно работать по определению. :)
Степан H.

однако, я б (делал) сделал так.
1. выбросить на удаленных компах базу
2. писать данные в файл, потом архивировать (или писать в архив)
3. файл на сервере в базу вставлять одной транзакцией (в Postgres метод COPY)
4. в зависимости от способов дальнейшей обработки попробуйте использовать партицирование.
5. в зависимоти от того что нужно получить в "конечном итоге" попробуйте "размазать" нагрузку проца на сервере "по времени", тоесть не "напрягать" его, допустим, "раз в час" а чтоб постоянно занимался "предобработкой" данных, например на триггерном уровне. Бизнес-логика должна быть построена внутри самой СУБД.
п.5 возможно неактуальный

Если отбросить условия автора, и допустить реально выполнимые, то, в чем потаённый смысл такого усложнения?
Почему нельзя сразу писать в базу???
22 дек 08, 06:09    [6601101]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
немой
Member

Откуда: от туда.
Сообщений: 73
javamachine

На компе под OS WinXP...

1. Это не система реального времени. Если есть жесткие требования ко времени исполнения, стоит обратить внимание или на ОС реального времени, или, в крайнем случае, использовать например Lunux, и возможно не на новых ядрах (например, Debian на 2.0.х или 2.2.х).
javamachine

За одну секунду нужно добавлять в таблицу тысячу записей (каждый кортеж состоит из десятка INTов). Сеанс наблюдений (сбор данных с датчиков) продолжается сутки (итого из расчёта 1000 записей в секунду имеем около ста миллионов записей максимум в таблицы). В ходе сеанса сами данные никак не модифицирутся. После окончания сеанса информация из таблицы экспортируется в файлы с архивами, а сама таблица сносится ко всем чертям.

2. Исходя из первого.. Вы не сможете гарантировать такой интервал чтения/записи (чтение с порта запись на диск). По мимо всего прочего, ОС нужно время на собственные нужды.
javamachine

Всё это хозяйство работает медленнее, чем хотелось бы. Полного загрузочного тестирования я ещё не производил, но боюсь, что система с ним не справится. В связи с этим очень прошу порекомендовать мне какие-нибудь решения для данной ситуации.

3. Выражение «работает медленнее, чем хотелось бы» не допустимо при таких требованиях. Вы верно заметили – «Полного загрузочного тестирования я ещё не производил, но боюсь, что система с ним не справится.».
javamachine

В частности, возникают следующие вопросы: какую СУБД стоит использовать для подобных задач;
какие настройки (в общих словах: тип таблиц, etc.) вы порекомендуете использовать и почему?

4. Вопрос выбора СУБД второстепенный в данном случае. На первом месте, имхо, стоит выбор ОС. Но, возможно (в зависимости от нагрузки и требований, а также «полевых испытаний»), понадобится СУБД реального времени (например, IndustrialSQL, InfoPlus и т.д.). Все эти решения стоят денег. Хотя, можно что поискать и на халяву.
javamachine

А если более глобально - как бы вы решали подобную задачу (передача данных с удалённых объектов по TCP/IP c целью их дальнейшей обработки)?

5. А вот тут, все зависит от удаленности этих объектов. Можно ли их посадить на общую шину (485)? Если да, то садим и принимает данные на одной машине, на ней же и БД в которую пишется. Но, тут опять же, требования ко времени.. Возможно, при жестком требовании наоборот, не объединять объекты а работать с каждым по отдельности. В любом случае, не надо забывать и о времени прохождения пакета в ЛВС.. и о серверной стороне. Все же, наверно более актуально писать сразу в БД или использовать трехзвездную архитектуру с промежуточным звеном (сервер приложений) на котором будут постоянно открыты порты, например по UDP как более быстрые но не гарантирующие доставку, или TCP если нужна квитация. На сервере приложений будут писаться данные в файлы и по запросу забираться, или паковаться.
Когда требования к реакции системы спускаются ниже 1 секунды, то появляется необходимость использовать специализированные инструменты.. Потому что заявления «мы гарантируем вам сохранение информации каждые 100 микросекунд в СУБД Oracle» при это строя систему на Windows XP – мягко говоря, рассчитаны только на менеджеров.

--------------------------------------
Желаемое и возможное – две большие разницы.
22 дек 08, 07:03    [6601113]     Ответить | Цитировать Сообщить модератору
 Re: Сбор данных с удалённых машин  [new]
немой
Member

Откуда: от туда.
Сообщений: 73
Ну и в догонку..
Есть (как пример) прибор «Х», его назначение: сбор данных с различных датчиков, 48 аналоговых и 16 дискретных (в разных версиях по разному). У него есть внутренний буфер на 256 кб. Прибор получает данные постоянно, а на другом порту (485) по запросу отдаёт. Если прошла авария, срабатывает триггер и буфер «замыкается» с интервалом ~ 8 минут (4 до и 4 после), пока не будет считана авария (внешним АРМ), прибор не перетерает буфер. Таким образом, сохраняется история с нужной дискретностью и вполне нормально это живет потом на Windows 2000 (пишет в Dbase, хотя, можно писать куда угодно, т.к. временные ограничения сняты аппаратно) с помощью внешнего АРМ.
Я к тому, что возможно стоит поискать такие решения.

--------------------------------------
Желаемое и возможное – две большие разницы.
22 дек 08, 11:00    [6601606]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить