Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обмен сообщениями через СУБД, что выбрать? / 17 сообщений из 17, страница 1 из 1
03.01.2013, 17:46
    #38099461
nuts577
nuts577
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обмен сообщениями через СУБД, что выбрать?
Добрый день,

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


Сообщение это в буквальном смысле текстовая строка, подтверждение или ответ не требуется.
Обработчик парсит и некоторые форвардит.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.01.2013, 12:26
    #38099913
nuts577
nuts577
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обмен сообщениями через СУБД, что выбрать?
Мда, ошибочка по файлу. Конфликтов при одном пишущем и одном читающем в принципе не будет. При нескольких пишущих и одном читающем могут кмк.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.01.2013, 12:50
    #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, 14:39
    #38100016
AlexKB
AlexKB
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обмен сообщениями через СУБД, что выбрать?
nuts577,

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

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

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

nuts577 ,

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

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


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