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

Откуда:
Сообщений: 3
Есть задача разработки системы управления, состоящей из центрального узла и удаленных клиентов. Обмен данными между узлами осуществляется с помощью БД. На узле и клиентах работают серверы БД, при этом запущен процесс репликации данных между уровнем центрального узла и уровнем удаленных клиентов.
Основная проблема заключается в канале передачи данных - это 9600 бит (!) с пингами порядка 600мс - 1000мс. При этом связь не отличается стабильностью: дисконнекты - обычное явление.

В данный момент в первой опытной версии используется Firebird (2.0, пробовали и на 2.1), однако все работает чудовищно медленно (даже тривиальный запрос выполняется по 5 - 10 секунд). Уже поняли, что это недостаток протокола Firebird.

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

Существуют ли решения, позволяющие пробрасывать запросы и их результаты выполнения по более шустрому протоколу и в сжатом виде? Продумываем вариант написания своего протокола с архивированием результатов работы FBExport и последующей вставкой содержимого архива в целевую базу, но не хотелось бы изобретать велосипед или слишком сложное решение проблемы.

Я пробовал найти описание протоколов разных БД, но безуспешно. Ставить всевозможные варианты и анализировать сниффером тоже не очень хочется. Буду благодарен за любую информацию по этому вопросу.
24 авг 07, 22:33    [4574821]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Dmitry Levchenko пишет:

> Существуют ли решения, позволяющие пробрасывать запросы и их результаты
> выполнения по более шустрому протоколу и в сжатом виде? Продумываем

Субд -то тут при чем ?

Posted via ActualForum NNTP Server 1.4

25 авг 07, 10:37    [4575211]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Dmitry Levchenko
Member

Откуда:
Сообщений: 3
А это вторая альтернатива. Если не будет найдена СУБД с "легким" протоколом.
Главный вопрос:
"какую СУБД лучше выбрать при таком канале связи?"
25 авг 07, 11:28    [4575238]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472

любую. для таких каналов связи все равно придется на клиенте держать копию,
и делать синхронизацию.


Posted via ActualForum NNTP Server 1.4

25 авг 07, 11:38    [4575246]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Dmitry Levchenko
Member

Откуда:
Сообщений: 3
В этой системе на обоих уровнях все программы, кроме репликатора, работают с локальными базами. Репликатор - единственное приложение, имеющее 2 коннекта: к локальной базе и удаленной. В этом случае сильно тормозит только репликатор. Но тормоза все-таки критичные.
25 авг 07, 23:52    [4575900]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Dimitry Sibiryakov
Member

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

Ну так надо взять репликатор, способный работать в оффлайне и гнать
данные не через бедный IB протокол, а, скажем, по FTP. Я, правда, знаю
всего один такой и тот полудохлый - www.2p.cz

Posted via ActualForum NNTP Server 1.4

27 авг 07, 09:10    [4577236]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Dmitry Levchenko
В этой системе на обоих уровнях все программы, кроме репликатора, работают с локальными базами. Репликатор - единственное приложение, имеющее 2 коннекта: к локальной базе и удаленной. В этом случае сильно тормозит только репликатор. Но тормоза все-таки критичные.

У меня есть давно и успешно эксплуатируемый репликатор, таскающий именно по таким каналам данные для Oracle. Если интересно побеседовать - мыло в профиле.

P.S. Тот репликатор, который я выкинул, тоже пытался держать коннекты к двум базам :)
27 авг 07, 10:35    [4577657]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Dmitry Levchenko
"какую СУБД лучше выбрать при таком канале связи?"

Зависит от задачи. Сталкивался несколько раз с подобными проблемами. Основных решений было два:

- перенес всю обработку на сервер (но у нас пересылка данных каждый раз была не очень большая) (главный недостаток - невозможность работы при отсутсвии соединения, но такое случалось не очень часто в течении дня)

- написал свой сервер для репликации...

Good luck!
27 авг 07, 12:27    [4578620]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
SoftBusinessConsulting
Guest
Dmitry Levchenko
Есть задача разработки системы управления, состоящей из центрального узла и удаленных клиентов. Обмен данными между узлами осуществляется с помощью БД. На узле и клиентах работают серверы БД, при этом запущен процесс репликации данных между уровнем центрального узла и уровнем удаленных клиентов.
Основная проблема заключается в канале передачи данных - это 9600 бит (!) с пингами порядка 600мс - 1000мс. При этом связь не отличается стабильностью: дисконнекты - обычное явление.

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

Уважаемый Дмитрий. Могу посоветовать посмотреть в сторону Sybase Adaptive Server Anywhere. Для Ваших условий - отличное решение. Данный сервер БД имеет встроенный (а не самописный -:) ) механизм репликации данных, в т.ч. в режиме офф-лайн по электронной почте. Сервер отлично себя зарекомендовал на многих проектах, в частности в страховых компаниях, где со многими филиалами (в деревне Гадюкино) также имеются проблемы с каналами связи. Да не бесплатный, но всего 150$ на одно рабочее место. Попутно вопрос, неужели все Заказчики или работодатели такие жадные и не понимают, что за удобство надо платить!!!!
С уважением, Александр Старшинин.
28 авг 07, 12:21    [4584738]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
Sybase Adaptive Server Anywhere он же SQL Anywhere Studio
28 авг 07, 12:43    [4584963]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
SoftBusinessConsulting
Да не бесплатный, но всего 150$ на одно рабочее место. Попутно вопрос, неужели все Заказчики или работодатели такие жадные и не понимают, что за удобство надо платить!!!!

Что меня прикалывает - если бы речь шла об Oracle, лейтмотив был бы "нету у меня миллионов, чтобы платить по $150 за одно рабочее место".

Это не к Вам, просто по общему настроению высказывающихся :)
28 авг 07, 13:49    [4585577]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
softwarer

Что меня прикалывает - если бы речь шла об Oracle, лейтмотив был бы "нету у меня миллионов, чтобы платить по $150 за одно рабочее место".

Это не к Вам, просто по общему настроению высказывающихся :)


кто на свадьбу в самосвале ездит?
это тоже не к вам
28 авг 07, 16:13    [4586799]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Someбади
Member [заблокирован]

Откуда: Moscow Suburban
Сообщений: 1822
А кроме Sybase ASA к нему Mobilink и центральный сервер СУБД в тех же компаниях не докуплен?
29 авг 07, 17:14    [4593467]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
Александр12
Guest
а если абстрагироваться от БД - начать использовать апп сервер с сжимающим протоколом - например тот же http+gzip?
3 сен 07, 05:04    [4610749]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
В зависимости от качества реализации будет либо "полная жопа" либо "нечто вроде ухудшенного ftp сервера". В последнем случае, приложив усилия, можно будет даже догнать до уровня ftp-сервера.
3 сен 07, 08:30    [4610840]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
___void
Guest
Надеюсь поможет :

- введение сервера приложения с шифрованием/сжатием трафика
- шифрованный/сжатый канал по TCP/IP (например: zebedee)

Удачи ...
24 сен 07, 09:05    [4704519]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
DB2Adventurer_
Guest
softwarer
В зависимости от качества реализации будет либо "полная жопа" либо "нечто вроде ухудшенного ftp сервера". В последнем случае, приложив усилия, можно будет даже догнать до уровня ftp-сервера.
Интересно, а ваш репликатор как работает? Сервер очередей работающий по запросам на протоколе хттп?
27 сен 07, 17:39    [4726357]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для медленного канала связи с большими задержками  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
DB2Adventurer_
Интересно, а ваш репликатор как работает? Сервер очередей работающий по запросам на протоколе хттп?

1. Я.... (подбирая формулировку....) не планирую использовать протокол хттп хоть для чего-нибудь, слишком уж он плох. Хотя, возможно, за последние несколько лет его дыры и закрыли - не знаю, не смотрел. Будем считать, уже предубежден. Так или иначе, его единственное достоинство - повсеместная открытость 80-го порта.

2. Мой репликатор работает по расписанию. Ему задается некоторое количество задач, которые он и запускает, обычно раз в минуту. Задача чаще всего - двусторонний обмен данными с некоторым узлом, хотя можно наконфигурить что угодно (скажем, одна задача - отправка данных всем, другая - прием данных ото всех).

3. Транспортные протоколы подключаются к репликатору как плагины. Обычно используется ftp. Было место, где данные слали через smtp, было - где носили на переносном винте.
27 сен 07, 17:58    [4726512]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить