|
|
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Есть задача разработки системы управления, состоящей из центрального узла и удаленных клиентов. Обмен данными между узлами осуществляется с помощью БД. На узле и клиентах работают серверы БД, при этом запущен процесс репликации данных между уровнем центрального узла и уровнем удаленных клиентов. Основная проблема заключается в канале передачи данных - это 9600 бит (!) с пингами порядка 600мс - 1000мс. При этом связь не отличается стабильностью: дисконнекты - обычное явление. В данный момент в первой опытной версии используется Firebird (2.0, пробовали и на 2.1), однако все работает чудовищно медленно (даже тривиальный запрос выполняется по 5 - 10 секунд). Уже поняли, что это недостаток протокола Firebird. Вопрос: какую СУБД в данном случае какую лучше выбрать при таком канале связи? Будет ли ощутимая разница в скорости относительно текущей реализации? СУБД желательно брать бесплатную. Существуют ли решения, позволяющие пробрасывать запросы и их результаты выполнения по более шустрому протоколу и в сжатом виде? Продумываем вариант написания своего протокола с архивированием результатов работы FBExport и последующей вставкой содержимого архива в целевую базу, но не хотелось бы изобретать велосипед или слишком сложное решение проблемы. Я пробовал найти описание протоколов разных БД, но безуспешно. Ставить всевозможные варианты и анализировать сниффером тоже не очень хочется. Буду благодарен за любую информацию по этому вопросу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2007, 22:33 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Dmitry Levchenko пишет: > Существуют ли решения, позволяющие пробрасывать запросы и их результаты > выполнения по более шустрому протоколу и в сжатом виде? Продумываем Субд -то тут при чем ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2007, 10:37 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
А это вторая альтернатива. Если не будет найдена СУБД с "легким" протоколом. Главный вопрос: "какую СУБД лучше выбрать при таком канале связи?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2007, 11:28 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
любую. для таких каналов связи все равно придется на клиенте держать копию, и делать синхронизацию. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2007, 11:38 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
В этой системе на обоих уровнях все программы, кроме репликатора, работают с локальными базами. Репликатор - единственное приложение, имеющее 2 коннекта: к локальной базе и удаленной. В этом случае сильно тормозит только репликатор. Но тормоза все-таки критичные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2007, 23:52 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Ну так надо взять репликатор, способный работать в оффлайне и гнать данные не через бедный IB протокол, а, скажем, по FTP. Я, правда, знаю всего один такой и тот полудохлый - www.2p.cz Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2007, 09:10 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Dmitry LevchenkoВ этой системе на обоих уровнях все программы, кроме репликатора, работают с локальными базами. Репликатор - единственное приложение, имеющее 2 коннекта: к локальной базе и удаленной. В этом случае сильно тормозит только репликатор. Но тормоза все-таки критичные. У меня есть давно и успешно эксплуатируемый репликатор, таскающий именно по таким каналам данные для Oracle. Если интересно побеседовать - мыло в профиле. P.S. Тот репликатор, который я выкинул, тоже пытался держать коннекты к двум базам :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2007, 10:35 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Dmitry Levchenko "какую СУБД лучше выбрать при таком канале связи?" Зависит от задачи. Сталкивался несколько раз с подобными проблемами. Основных решений было два: - перенес всю обработку на сервер (но у нас пересылка данных каждый раз была не очень большая) (главный недостаток - невозможность работы при отсутсвии соединения, но такое случалось не очень часто в течении дня) - написал свой сервер для репликации... Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2007, 12:27 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Dmitry LevchenkoЕсть задача разработки системы управления, состоящей из центрального узла и удаленных клиентов. Обмен данными между узлами осуществляется с помощью БД. На узле и клиентах работают серверы БД, при этом запущен процесс репликации данных между уровнем центрального узла и уровнем удаленных клиентов. Основная проблема заключается в канале передачи данных - это 9600 бит (!) с пингами порядка 600мс - 1000мс. При этом связь не отличается стабильностью: дисконнекты - обычное явление. Вопрос: какую СУБД в данном случае какую лучше выбрать при таком канале связи? Будет ли ощутимая разница в скорости относительно текущей реализации? СУБД желательно брать бесплатную. Уважаемый Дмитрий. Могу посоветовать посмотреть в сторону Sybase Adaptive Server Anywhere. Для Ваших условий - отличное решение. Данный сервер БД имеет встроенный (а не самописный -:) ) механизм репликации данных, в т.ч. в режиме офф-лайн по электронной почте. Сервер отлично себя зарекомендовал на многих проектах, в частности в страховых компаниях, где со многими филиалами (в деревне Гадюкино) также имеются проблемы с каналами связи. Да не бесплатный, но всего 150$ на одно рабочее место. Попутно вопрос, неужели все Заказчики или работодатели такие жадные и не понимают, что за удобство надо платить!!!! С уважением, Александр Старшинин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2007, 12:21 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Sybase Adaptive Server Anywhere он же SQL Anywhere Studio ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2007, 12:43 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
SoftBusinessConsultingДа не бесплатный, но всего 150$ на одно рабочее место. Попутно вопрос, неужели все Заказчики или работодатели такие жадные и не понимают, что за удобство надо платить!!!! Что меня прикалывает - если бы речь шла об Oracle, лейтмотив был бы "нету у меня миллионов, чтобы платить по $150 за одно рабочее место". Это не к Вам, просто по общему настроению высказывающихся :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2007, 13:49 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
softwarer Что меня прикалывает - если бы речь шла об Oracle, лейтмотив был бы "нету у меня миллионов, чтобы платить по $150 за одно рабочее место". Это не к Вам, просто по общему настроению высказывающихся :) кто на свадьбу в самосвале ездит? это тоже не к вам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2007, 16:13 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
А кроме Sybase ASA к нему Mobilink и центральный сервер СУБД в тех же компаниях не докуплен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2007, 17:14 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
а если абстрагироваться от БД - начать использовать апп сервер с сжимающим протоколом - например тот же http+gzip? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2007, 05:04 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
В зависимости от качества реализации будет либо "полная жопа" либо "нечто вроде ухудшенного ftp сервера". В последнем случае, приложив усилия, можно будет даже догнать до уровня ftp-сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2007, 08:30 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
Надеюсь поможет : - введение сервера приложения с шифрованием/сжатием трафика - шифрованный/сжатый канал по TCP/IP (например: zebedee) Удачи ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 09:05 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
softwarerВ зависимости от качества реализации будет либо "полная жопа" либо "нечто вроде ухудшенного ftp сервера". В последнем случае, приложив усилия, можно будет даже догнать до уровня ftp-сервера.Интересно, а ваш репликатор как работает? Сервер очередей работающий по запросам на протоколе хттп? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:39 |
|
||
|
СУБД для медленного канала связи с большими задержками
|
|||
|---|---|---|---|
|
#18+
DB2Adventurer_Интересно, а ваш репликатор как работает? Сервер очередей работающий по запросам на протоколе хттп? 1. Я.... (подбирая формулировку....) не планирую использовать протокол хттп хоть для чего-нибудь, слишком уж он плох. Хотя, возможно, за последние несколько лет его дыры и закрыли - не знаю, не смотрел. Будем считать, уже предубежден. Так или иначе, его единственное достоинство - повсеместная открытость 80-го порта. 2. Мой репликатор работает по расписанию. Ему задается некоторое количество задач, которые он и запускает, обычно раз в минуту. Задача чаще всего - двусторонний обмен данными с некоторым узлом, хотя можно наконфигурить что угодно (скажем, одна задача - отправка данных всем, другая - прием данных ото всех). 3. Транспортные протоколы подключаются к репликатору как плагины. Обычно используется ftp. Было место, где данные слали через smtp, было - где носили на переносном винте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:58 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=34752786&tid=1553240]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 141ms |

| 0 / 0 |
