ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обмен сообщениями через СУБД, что выбрать?
17 сообщений из 17, страница 1 из 1
Обмен сообщениями через СУБД, что выбрать?
    #38099461
nuts577
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nuts577
Гость
Добрый день,

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

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

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

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

С уважением,
...
Рейтинг: 0 / 0
03.01.2013, 17:46
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099472
vvm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vvm
Участник
nuts577Добрый день,

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

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

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

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

С уважением,
Файер бёрд, конечно.
"Наименее затратно добавлять" - с помощью insert, а "опрашивать новые по строкам" - с помощью select.
Пусть висят. А если будут мешать - удаляй.
...
Рейтинг: 0 / 0
03.01.2013, 18:11
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099480
Фотография Барсук-копатель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Барсук-копатель
Участник
Mssql + change tracking
...
Рейтинг: 0 / 0
03.01.2013, 18:25
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099496
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
А назачем тут вообще СУБД? Пусть сообщения сразу посылаются обрабатывающему сообщению.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.01.2013, 18:50
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099828
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
авторКак наименее затратно по скорости добавлять новую строку в таблицу и опрашивать по новым строкам?Плоский файл
...
Рейтинг: 0 / 0
04.01.2013, 04:12
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099852
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
nuts577,

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

По моему Вам стоит посмотреть в этом направлении.
...
Рейтинг: 0 / 0
04.01.2013, 09:01
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099875
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Насколько я понял "сообщения" - это некий термин, используемый ТС. На самом деле у ТС обычное К\С приложение (не распределенное). Ради 100 000 сообщений в день связываться с тем или иным сервисом обмена сообщениями - это перебор. А такое кол-во сообщений "выдержит" любая современная СУБД. Вот автор про "обработку" ничего не рассказал. Тут могут быть ньюансы...
...
Рейтинг: 0 / 0
04.01.2013, 11:02
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099891
nuts577
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nuts577
Гость
Спасибо всем за ответы!

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


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

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


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

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


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

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


Сообщение это в буквальном смысле текстовая строка, подтверждение или ответ не требуется.
Обработчик парсит и некоторые форвардит.
...
Рейтинг: 0 / 0
04.01.2013, 11:49
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099913
nuts577
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nuts577
Гость
Мда, ошибочка по файлу. Конфликтов при одном пишущем и одном читающем в принципе не будет. При нескольких пишущих и одном читающем могут кмк.
...
Рейтинг: 0 / 0
04.01.2013, 12:26
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38099923
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
nuts577Приложения генерирующие сообщения могут писать в файл или слать в sql базу,
остальное надо делать.
Ну а в чём проблема-то написать три строки типа таких:
Код: plaintext
1.
2.
3.
h = CreateFile("\\\\server\\pipe\\MyServ", .....);
WriteFile(h, MyMessage);
CloseFile(h);


Программиста нет?.. Так это в раздел "Работа".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.01.2013, 12:50
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38100016
AlexKB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexKB
Участник
nuts577,

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

То же самое делает MSMQ и Java MQ :-)
Плюс асинхронная передача данных.
Грубо говоря даже на флопонете будет работать ;-)
...
Рейтинг: 0 / 0
04.01.2013, 16:25
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38100083
AlexKB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexKB
Участник
mad_nazgul,
Наивное сравнение из-за невнимательности прочтенного...(((
...
Рейтинг: 0 / 0
04.01.2013, 16:27
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38100154
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
AlexKB ,

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

nuts577 ,

У нас вставала задача от 400 до 1500 датчиков до 70 раз в секунду фиксировать данные тут же с их индивидуальной на сервере СУБД обработкой по каждому датчику и с учётом времени поступления.
...
Рейтинг: 0 / 0
04.01.2013, 17:45
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38100165
AlexKB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexKB
Участник
servit,
Вы уточняйте на чем Вы делали (я догадываюсь).

С задачей справится минимум сто решений, а вот какое будет наиболее простое, надежное - это еще вопрос.
...
Рейтинг: 0 / 0
04.01.2013, 17:57
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38100192
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
AlexKBВы уточняйте на чем Вы делали (я догадываюсь)Уточняется в один клик по профилю или блогу.AlexKBС задачей справится минимум сто решений, а вот какое будет наиболее простое, надежное - это еще вопрос.ТС ещё не затронул финансовую сторону вопроса.
...
Рейтинг: 0 / 0
04.01.2013, 18:29
| Ответить | Цитировать | Написать  
Обмен сообщениями через СУБД, что выбрать?
    #38101106
nuts577
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nuts577
Гость
Всем огромное спасибо за советы, буду разбираться.
...
Рейтинг: 0 / 0
06.01.2013, 18:15
| Ответить | Цитировать | Написать  
17 сообщений из 17, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обмен сообщениями через СУБД, что выбрать?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&fpage=9&tid=1552490]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 35ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 75ms
get tp. blocked users:
 2ms
others: 12ms
total:  171ms
созд. / загр.: 171ms
x
x
Закрыть


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