Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 СУБД почти реального времени  [new]
Guest22
Guest
Есть достаточно типовая задача хранения телеметрических данных в СУБД. Несколько десятков датчиков (программные модули), опрашиваются ежесекундно, каждый генерит от 20 до 200 строк попарных данных типа уровень такой-то -> значение такое-то. Т.е. одна большая таблица с колонками Время, Датчик, Уровень, Значение. Простой расчет показывает, что за секунду в такую таблицу добавляется несколько тысяч записей.

Нужно подобрать виндовую СУБД, которая сможет это все принять и отдавать несложную агрегацию за текущие сутки максимум с двух-трех секундной задержкой (с момента получения данных). Пока я склоняюсь к FireBird. Есть другие предложения? Монстров вроде оракла ставить не хотелось бы, да и тормозить оно будет на такой задаче, как мне мыслится...
28 сен 05, 18:07    [1919923]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, Guest22!
Ты пишешь:

Guest22
G> Есть достаточно типовая задача хранения телеметрических данных в СУБД. Несколько десятков датчиков (программные
модули),
G> опрашиваются ежесекундно, каждый генерит от 20 до 200 строк попарных данных типа уровень такой-то -> значение такое-то. Т.е.
G> одна большая таблица с колонками Время, Датчик, Уровень, Значение. Простой расчет показывает, что за секунду в такую таблицу
G> добавляется несколько тысяч записей.
Если в одной транзакции, то это одно,
а если каждая запись в отдельной транзакции, то это другое...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

28 сен 05, 18:12    [1919961]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Yo!!
Guest
раз склоняетесь к FB значит про$%^ть показания не так страшно, значит можно показания просто валить в текстовые файлы и раз в минуту их загружать в субд. в какую субд зависит что вы с этими показаниями дальше делаете.
28 сен 05, 18:13    [1919963]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
У нас биллинг реализован на связке TMeter + ASA, где TMeter фигачит в себе логи на винт и параллейным потоком грузит их в ASA. Если даже сервак остановить или он просядет, то как только он появится, поток продолжит работу и данные все равно в СУБД окажутся. Кажется мне как раз Вам так сделать и нужно, как у TMeter реализовано - в секунду конечно у нас тысячи пакетов не набираются (в день где то по 60-100 тысяч записей по всем таблицам TMeter), но принцип такой же - нереально это дело напрямую спустить к любой РСУБД.
28 сен 05, 18:19    [1919999]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
Как по мне, так тут по любому через файл надо делать и потом уже в БД заливать...
28 сен 05, 18:27    [1920044]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Yo!!
Guest
ASCRUS
нереально это дело напрямую спустить к любой РСУБД.


да почему ?
http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=105022401
1 проц - 28K транзакций в секунду, причем транзакции посложней + индексы строят. наверника какой-нибудь mysql/mSql гораздо больше чем 20K tps вытянет, главный вопрос что еще с этим будут делать. если еще и аналитику по базе в пару сотен М записей пускать, то тогда да, сурово.
28 сен 05, 18:35    [1920084]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ggv
Member

Откуда:
Сообщений: 1810
вместо фала более правильно будет сервис очередей использовать.
Так как тогда связку "взять данные -> вставить в базу" можно будет в рамках транзакции делать - гарантировано
А файловые операции по XA протоколу в транзакцию не включишь.
То есть распредененные системы лучше строить на асинхронном обмене сообщениями, используя сервис очередей и XA транзакции для заливки в базу. Многопоточным приложением, которое будет брать из очередей и заливать в базу, можно окучить офигительный трафик.
Ну остальное уже детали реализации.
Плюс асинхронность на распределенных системах - самый идеологически правильный вид работы, где синхронность всего лишь частный случай асинхронности.
28 сен 05, 18:37    [1920098]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
если еще и аналитику по базе в пару сотен М записей пускать, то тогда да, сурово.

Вот и я про тоже говорю. Плюс еще мало ли что с сервером может случиться, по любому придется механизм отложенной записи в СУБД делать.

автор
вместо фала более правильно будет сервис очередей использовать.
Так как тогда связку "взять данные -> вставить в базу" можно будет в рамках транзакции делать - гарантировано
А файловые операции по XA протоколу в транзакцию не включишь.
То есть распредененные системы лучше строить на асинхронном обмене сообщениями, используя сервис очередей и XA транзакции для заливки в базу. Многопоточным приложением, которое будет брать из очередей и заливать в базу, можно окучить офигительный трафик.
Ну остальное уже детали реализации.
Плюс асинхронность на распределенных системах - самый идеологически правильный вид работы, где синхронность всего лишь частный случай асинхронности.

TMeter так и работает - асинхронно, очередями пуляя в БД данные. Однако при протоколировании данных с датчиков особо транзакционность не нужна - датчик дал показания, программа записала показания, откатит то датчик все равно возможности нет. А вот сохранять куда то очереди на диск нужно - в текстовые файлы или другим форматом без разницы. Иначе вполне возможно потерять часть данных, когда СУБД не успела вставить, а программа приема показаний датчиков взяла, да навернулась. Кстати вполне возможно использовать связку MySQL 4 -> Мощная РСУБД, где в MySQL все шустро пишется по таблицам, а потом асинхронный поток все это переносит уже в мощную РСУБД для аналитики.
28 сен 05, 18:57    [1920173]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну про датчики и отсутсвие транзакций у них - фих с ними.
Вот далее чего с данными происходит интересно.
Если в файло - то не транзакционно, риски при эксплуатации даже на не очень больших потоках, а ужо на больших....
Куда данные девать до записи в базу? Как TMeter (никогда не ивдал его) пишет асинхронно в базу? пока не записал, где хранит? Короче, как транзакции построены, поток данных.
Ну и mysql не самый идеальный выбор как сервис очередей, как ни крути.
28 сен 05, 19:10    [1920225]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Я же обьяснил - в логи он свои на винт пишет, а уж по ним параллейный процесс все это переносит в СУБД. Даже если СУБД отвалится или еще чего случится, не страшно - как коннект поток сможет восстановить, он дальше продолжить писать с того места, где остановился на момент потери коннекта с СУБД.
28 сен 05, 19:18    [1920255]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Иван FXS
Member

Откуда:
Сообщений: 2369
ASCRUS
нереально это дело напрямую спустить к любой РСУБД.

- о птичках ... Я запускаю под MS Access 10-20-30-(сколько памяти хватит) окон IE в виде ActiveX, раздаю им урлы, а по мере загрузки контента - по событиям объектов MSHTML.HTMLDocument - вызываю функцю, которая парсит HTML и складывает его в таблицы MS Access. И так по кругу ...

Это называется "напрямую спустить", или как?


_________________________________
SQL @ SemantiCat
28 сен 05, 19:18    [1920258]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ggv
Member

Откуда:
Сообщений: 1810
ASCRUS - так вот вот это "в логи он свои на вин пишет" и не внушает оптимизма.
Ну и способ работы с фацлом, и заливка потом в базу онлайново из файла...
Не весело как-то в плане надежности.
28 сен 05, 19:26    [1920287]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ggv
ASCRUS - так вот вот это "в логи он свои на вин пишет" и не внушает оптимизма.
Ну и способ работы с фацлом, и заливка потом в базу онлайново из файла...
Не весело как-то в плане надежности.

Тогда я не понимаю - что - веселее в память что ли писать или сразу пакеты по сети пускать до СУБД ?
28 сен 05, 19:40    [1920308]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Иван FXS
- о птичках ... Я запускаю под MS Access 10-20-30-(сколько памяти хватит) окон IE в виде ActiveX, раздаю им урлы, а по мере загрузки контента - по событиям объектов MSHTML.HTMLDocument - вызываю функцю, которая парсит HTML и складывает его в таблицы MS Access. И так по кругу ...


Иван, Вы как всегда всех веселите :o) Ну какое отношение эта ваша карусель имеет к поставленной задаче ???
29 сен 05, 09:35    [1921051]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кстати, тогоже эффекта и большей производительности можно было добиться существенно меньшей кровью, просто написав свой многопоточный HTTP клиент с доспом в нормальную РСУБД.
29 сен 05, 09:37    [1921062]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
glebofff
Member

Откуда: Оренбург
Сообщений: 72
ggv
ASCRUS - так вот вот это "в логи он свои на вин пишет" и не внушает оптимизма.
Ну и способ работы с фацлом, и заливка потом в базу онлайново из файла...
Не весело как-то в плане надежности.


Я, заради такого случая написал демон, который аггрегирует данные в памяти (хэш по ip-шникам), потом с заданным интервалом сливает в БД. И никакого файла.
29 сен 05, 09:45    [1921094]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
А что это НАДЕЖНЕЕ ? При исчезновении питалова скажем
29 сен 05, 09:57    [1921132]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ggv
Member

Откуда:
Сообщений: 1810
ASCRUS - веселее пользоваться сервисом очередей, как я уже сказал, MOM так называемый - Message Oriented Middleware, где последовательность шагов "взять данные - произвести действия в базе - общий commit" выполняется под управлением транзакций.
Ну если так не понятно, то расшифрую - если commit успешен, но данные убираются из очереди о добавляются в базе.
Если commit не успешен или любойй другой сбой - в базе rollback и данные остаются в базе.
Ну плюс возможность иметь базу удаленно, перекладывая заботу о доставке данных на сервис очередей - не надо городить никакой базы локально. Ну и многое другое, что дает сервис очередей.
Единственный минус - не встречал сервис очередей задаром.
29 сен 05, 11:27    [1921631]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну я и понаписал.
попробую еще раз и без ошибок
если commit успешен - данные удаляются из очереди и комитятся в базе
если commit не успешен или любой другой сбой - данные остаются в очереди и никаких изменений в базе не производится.
От начала транзакции и до ее завершения данные не доступны другим процессам/нитям, работающим с той же очередью
29 сен 05, 11:31    [1921660]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

ggv wrote:
> ASCRUS - так вот вот это "в логи он свои на вин пишет" и не внушает
> оптимизма.
> Ну и способ работы с фацлом, и заливка потом в базу онлайново из файла...
> Не весело как-то в плане надежности.
ну, все ведь на винт пишут, СУБД тоже...
Отключить нах кэш на запись, отключить кэш на хандл, после каждой записи
делать FlushFileBuffers... организовать регулярную смену файла... пока в
следующий пишем, предыдущий льется в базу... достаточно просто и надежно.

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

29 сен 05, 11:33    [1921675]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ggv
Member

Откуда:
Сообщений: 1810
locky, вы невнимательно читаете.
Пока не сделали XA расширения к какой-нибудь файловой системе, это на уровне дилетанства, а не промышленного внедрения.
Вы не можете включить дисковые операции и базовые операции в одну транзакцию.
29 сен 05, 11:49    [1921793]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

ggv wrote:
> locky, вы невнимательно читаете.
> Пока не сделали XA расширения к какой-нибудь файловой системе, это на
> уровне дилетанства, а не промышленного внедрения.
> Вы не можете включить дисковые операции и базовые операции в одну
> транзакцию.
ну, мне то это и не надо... на самом деле...
я ведь могу устроить транзакцию при заливке файла лога в базу.
то бишь, как только очередной лог отваливает, я заливаю его в
промежуточную таблицу на сервере и потом фиксирую. если не получилось
залить файл или не получилось зафикировать - я попторю попытку. если
получилось - я больше не буду пытаться заливать этот файл.


--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

29 сен 05, 11:54    [1921831]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

ggv wrote:
> locky, вы невнимательно читаете.
хотя может я не до конца понял постановку, в части "отдавать несложную
агрегацию за текущие сутки максимум с двух-трех секундной задержкой (с
момента получения данных)". Это понимать как то, что в отчете показания
датчика должны появлятся буквально тут-же после снятия?

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

29 сен 05, 11:57    [1921854]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
hvlad
Guest
ggv
ASCRUS - веселее пользоваться сервисом очередей, как я уже сказал, MOM так называемый - Message Oriented Middleware, где последовательность шагов "взять данные - произвести действия в базе - общий commit" выполняется под управлением транзакций.
Ну если так не понятно, то расшифрую - если commit успешен, но данные убираются из очереди о добавляются в базе.
Если commit не успешен или любойй другой сбой - в базе rollback и данные остаются в базе.
Ну плюс возможность иметь базу удаленно, перекладывая заботу о доставке данных на сервис очередей - не надо городить никакой базы локально. Ну и многое другое, что дает сервис очередей.
Единственный минус - не встречал сервис очередей задаром.
В данном случае это элементарно и гораздо надёжнее решается через локальные файлы.
MOM тоже может навернуться, а свои файлы ближе к телу в случае чего. Да и избыточно оно для данной задачи, imho

В случае с FB - можно складывать данные с датчиков в embedded и потом уже - в общую БД. Тут и 2PC пригодится.

Но через файловый буфер - проще и, вообще говоря, надёжнее. Когда-то сам так и делал (когда FB ещё не было ;)
29 сен 05, 11:58    [1921861]     Ответить | Цитировать Сообщить модератору
 Re: СУБД почти реального времени  [new]
ggv
Member

Откуда:
Сообщений: 1810
hvlad

MOM тоже может навернуться, а свои файлы ближе к телу в случае чего. Да и избыточно оно для данной задачи, imho

Но через файловый буфер - проще и, вообще говоря, надёжнее. Когда-то сам так и делал (когда FB ещё не было ;)

Навернуться может все, но MOM специально предназначен для таких задач.
Про избыточность - этого нельзя сказать, исходя из "постановки задачи"
И еще раз - пока нет XA примочки к фаловой системе, типа адаптора или расширения, то файловый буфер по определению не может быть надежным в последовательности "взять из файла - действия в базе - действия в файле типа удаления"
Впрочем, RDBMS как раз этим и отличаются от файловых баз. Ну и XA для этого же приворочили.
Дураки, наверное, делали.
29 сен 05, 12:08    [1921959]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить