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

Откуда:
Сообщений: 20
Добрый день,

Есть несколько приложений (до 10) работающих в цикле и создающих типовые str сообщения 256 символов.
Нужно сообщения как то принимать в одно приложение, складывать в одну таблицу, обрабатывать, логировать. В принципе после обработки можно и удалять, вопрос в производительности.

С одной стороны задача вроде ерундовая, с другой они могут одновременно пачками начать сыпать сообщения которые должны по возможности быстро обрабатываться. За рабочий день туда будет валиться скажем до 100 000 сообщений.

Таким образом мне нужна простая и легкая СУБД, минимально потребляющая ресурсы, которая позволит максимально быстро принимать INSERT от нескольких одновременно подключенных по ODBC клиентов и отдавать новые строки обработчику который будет по таймеру спрашивать сколько строк в таблице, и читать то что не прочитал если поялвяются новые.

Дальше вопросы.
Какую СУБД посоветуете? Есть небольшой опыт с firebird.
Как наименее затратно по скорости добавлять новую строку в таблицу и опрашивать по новым строкам?
Стоит ли удалять обработанные или пусть висят до конца дня?

С уважением,
3 янв 13, 17:46    [13719782]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
vvm
Member

Откуда: Не помню
Сообщений: 9968
nuts577
Добрый день,

Есть несколько приложений (до 10) работающих в цикле и создающих типовые str сообщения 256 символов.
Нужно сообщения как то принимать в одно приложение, складывать в одну таблицу, обрабатывать, логировать. В принципе после обработки можно и удалять, вопрос в производительности.

С одной стороны задача вроде ерундовая, с другой они могут одновременно пачками начать сыпать сообщения которые должны по возможности быстро обрабатываться. За рабочий день туда будет валиться скажем до 100 000 сообщений.

Таким образом мне нужна простая и легкая СУБД, минимально потребляющая ресурсы, которая позволит максимально быстро принимать INSERT от нескольких одновременно подключенных по ODBC клиентов и отдавать новые строки обработчику который будет по таймеру спрашивать сколько строк в таблице, и читать то что не прочитал если поялвяются новые.

Дальше вопросы.
Какую СУБД посоветуете? Есть небольшой опыт с firebird.
Как наименее затратно по скорости добавлять новую строку в таблицу и опрашивать по новым строкам?
Стоит ли удалять обработанные или пусть висят до конца дня?

С уважением,

Файер бёрд, конечно.
"Наименее затратно добавлять" - с помощью insert, а "опрашивать новые по строкам" - с помощью select.
Пусть висят. А если будут мешать - удаляй.
3 янв 13, 18:11    [13719910]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
Барсук-копатель
Member [заблокирован]

Откуда: Московский парк
Сообщений: 94884
Mssql + change tracking
3 янв 13, 18:25    [13719944]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
Dimitry Sibiryakov
Member

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

А назачем тут вообще СУБД? Пусть сообщения сразу посылаются обрабатывающему сообщению.

Posted via ActualForum NNTP Server 1.5

3 янв 13, 18:50    [13719996]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
автор
Как наименее затратно по скорости добавлять новую строку в таблицу и опрашивать по новым строкам?
Плоский файл
4 янв 13, 04:12    [13721522]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
nuts577,

Для этого разработаны различные MQ (Message Queue).
Например MSMQ или Java MQ
Они делают то, что Вам нужно.
Создают очередь сообщений.
Одна программа кладет в очередь сообщения, другая их считывает.
Причем обмен данными асинхронный.
Еще гарантируется доставка сообщений и их сохранность.

По моему Вам стоит посмотреть в этом направлении.
4 янв 13, 09:01    [13721593]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Насколько я понял "сообщения" - это некий термин, используемый ТС. На самом деле у ТС обычное К\С приложение (не распределенное). Ради 100 000 сообщений в день связываться с тем или иным сервисом обмена сообщениями - это перебор. А такое кол-во сообщений "выдержит" любая современная СУБД. Вот автор про "обработку" ничего не рассказал. Тут могут быть ньюансы...
4 янв 13, 11:02    [13721812]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
nuts577
Member

Откуда:
Сообщений: 20
Спасибо всем за ответы!

Dimitry Sibiryakov
А назачем тут вообще СУБД? Пусть сообщения сразу посылаются обрабатывающему сообщению.


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

mad_nazgul
Для этого разработаны различные MQ (Message Queue).
Например MSMQ или Java MQ


Спасибо, этот вариант не знал. Буду изучать.

SERG1257
Плоский файл


Несколько приложений пишущих в один файл и одно читающее, или даже одно пишущее и одно читающее (каждое пишет в отдельный а обработчик читает все). Конфликтов не будет? Так то если без конфликтов и чтобы не читать файл с начала каждый раз а только вновь добавленные записи то никакой SQL и не нужен.

pkarklin
Насколько я понял "сообщения" - это некий термин, используемый ТС.
Вот автор про "обработку" ничего не рассказал. Тут могут быть ньюансы...


Сообщение это в буквальном смысле текстовая строка, подтверждение или ответ не требуется.
Обработчик парсит и некоторые форвардит.
4 янв 13, 11:49    [13721957]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
nuts577
Member

Откуда:
Сообщений: 20
Мда, ошибочка по файлу. Конфликтов при одном пишущем и одном читающем в принципе не будет. При нескольких пишущих и одном читающем могут кмк.
4 янв 13, 12:26    [13722092]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
Dimitry Sibiryakov
Member

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

nuts577
Приложения генерирующие сообщения могут писать в файл или слать в sql базу,
остальное надо делать.

Ну а в чём проблема-то написать три строки типа таких:
h = CreateFile("\\\\server\\pipe\\MyServ", .....);
WriteFile(h, MyMessage);
CloseFile(h);

Программиста нет?.. Так это в раздел "Работа".

Posted via ActualForum NNTP Server 1.5

4 янв 13, 12:50    [13722171]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
nuts577,

Вам идеально подойдет СУБД Cache - в ней есть все необходимые Вам возможности:
1. Прием сообщений от внешних устройств - отдельные процессы написанные Вами на встроенном языке позволят организовать прием данных по сокетам. Вы даже сможете написать драйвера, например ModBusTCP.
2. Логирование до каждой отдельной команды, причем в логе можно отражать события, происходящие в разных процессах, в точном хронологическом порядке их возникновения.
3. Передача данных от процессов принимающих, можно предварительно фильтровать, в процесс (процессы) обработки сообщений через MailBox, или другими внутренними средствами.
4. Для обрабатывающих процессов доступны все средства обработки строковых данных (сравнения, преобразования, вычисления, выделение подстрок и многое другое).
5. Отправка на хранение обработанных данных либо в реляционное хранилище, либо в файловую систему, либо в глубоко структурированные массивы, где индексами могут выступать содержательные данные.
6. Организация обработки и хранения данных в строгой последовательности возникающих событий у поставщиков информации, или наоборот, в соответствии со строгой или адаптируемой логикой, определяемой Вами.
7. Доступны многие средства координации работы отдельных процессов, средствами встроенного языка.
8. Возможность создания ВЕБ-интерфейса для доступа к данным, управления, координации и мониторинга всего происходящего в Вашем решении, отображение статистики и текущих показателей на графиках или цифровыми, стрелочными индикаторами.
9. Главное - все это в рамках единой технологии.
4 янв 13, 14:39    [13722537]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
AlexKB,

То же самое делает MSMQ и Java MQ :-)
Плюс асинхронная передача данных.
Грубо говоря даже на флопонете будет работать ;-)
4 янв 13, 16:25    [13722851]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
mad_nazgul,
Наивное сравнение из-за невнимательности прочтенного...(((
4 янв 13, 16:27    [13722860]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
AlexKB,

При такой постановке задачи и нагрузке должно справиться то, что уже предложили.

nuts577,

У нас вставала задача от 400 до 1500 датчиков до 70 раз в секунду фиксировать данные тут же с их индивидуальной на сервере СУБД обработкой по каждому датчику и с учётом времени поступления.
4 янв 13, 17:45    [13723119]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
servit,
Вы уточняйте на чем Вы делали (я догадываюсь).

С задачей справится минимум сто решений, а вот какое будет наиболее простое, надежное - это еще вопрос.
4 янв 13, 17:57    [13723167]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
AlexKB
Вы уточняйте на чем Вы делали (я догадываюсь)
Уточняется в один клик по профилю или блогу.
AlexKB
С задачей справится минимум сто решений, а вот какое будет наиболее простое, надежное - это еще вопрос.
ТС ещё не затронул финансовую сторону вопроса.
4 янв 13, 18:29    [13723298]     Ответить | Цитировать Сообщить модератору
 Re: Обмен сообщениями через СУБД, что выбрать?  [new]
nuts577
Member

Откуда:
Сообщений: 20
Всем огромное спасибо за советы, буду разбираться.
6 янв 13, 18:15    [13729329]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить