Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
 Re: Выбор СУБД для медленного канала  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9882
Зимаргл
Пробегала статья сравнения трафика постгрес с ораклом. Что разница в трафике вдвое.

Погуглил, похоже в mssql компрессии TDS нет. Хм.

Трафик нужно сравнивать cколько на одну ODBC / JDBC инструкцию будет round-trip'ов. Собственно "байты" достаточно пофиг.

Тот же Oracle, до версии 11 не умел делать array fetch / bulk fetch с полями типа Blob. Т.ч. стоило бы в запросе появится Blob'полю или любому производному от него (например гео-данные) - тормоза по сети были бы обеспечены.

Т.ч. IMHO для задачи топикстартера, если канал реально никак не расширить - то одно из:
1) решения на базе аппликейшен сервера
В крайнем случае, можно посмотреть есть ли поддержка RPC /remote procedure call/ в Delphi и сделать свой "сервер". Разделить проект на две части - серверная, клиентская. И общаться через какой-то механизм взаимодействия
2) терминальные решения
3) что-то "смешанное". Например Oracle Forms при работе в режиме Web-Forms работает фактически как терминальный сервер. Отсылает туда-обратно нажатия клавиш и информацию которую нужно обновить на экране.

IMHO На каналах с большой задержкой - все протоколы работающие с БД скорее всего пойдут лесом. А, подозреваю, а автора задержки на канале будут из разряда "тушите свет".
13 май 16, 11:31    [19168032]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
Тема жадных Блобов заинтересовала. Еще лет 10 назад у меня была мысль мелкие
блобы складывать в VARCHAR2(4000 bytes) в кодировке BASE64 той-же data-row при условии что размер
подходит (не больше кодированной строки).

Разумеется моя оптимизация базировалсь на предположении что 80-90% блобов будут мелкие.

Но сектор разработки тогда не поддержал мою идею. Хотя проблемы на канале были (ASDL модем между филиалами).
13 май 16, 11:52    [19168152]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9882
В начале 2000-х занимался оптимизацией для Oracle Forms.

Очень радовало, полное не совпадение данных по моем тестам и то, что было указано в нотах/инструкциях Oracle для Oracle Forms разработчиков. Например, их тесты которые якобы считали round trip'ы, считали совершенно другое. И с round-trip'ами на канале не совпадали, чуть более, чем полностью. Т.е. те советы которые давали ноты/примеры для Oracle Forms по оптимизации - делали хуже, чем стандартное поведение.

mayton
Тема жадных Блобов заинтересовала. Еще лет 10 назад у меня была мысль мелкие
блобы складывать в VARCHAR2(4000 bytes) в кодировке BASE64 той-же data-row при условии что размер
подходит (не больше кодированной строки).

А нафига? У Oracle есть RAW, правда не уверен, может ли он быть переменного размера. Скорее всего может.
mayton
Разумеется моя оптимизация базировалсь на предположении что 80-90% блобов будут мелкие.

Но сектор разработки тогда не поддержал мою идею. Хотя проблемы на канале были (ASDL модем между филиалами).

У нас не так много было BLOB'ов.

Но зато часто было обращение к настроечным справочникам, которые не меняются

Т.ч. сделал механизм кэширования справочников на клиенте (просто свою реализацию вместо/поверх CREATE_RECORD_GROUP_WITH_QUERY) - на канале 32 Kbit ADSL все залетало.

Но на радио-канале с задержками до 0.5 - 1 sec. - тушите свет. Читал доки от оборудования (провайдер прислал доки на их базовые станции) откуда берутся такой разброс в задержках, даже не понял. Но так как провайдер, понятное дело, ради нас настраивать QoS (quality of service) отказался, то делать было нечего. Поставили Windows терминальный сервер - он не так с задержкам критичен, хотя ряд модулей пришлось доделывать (например работу с изображениями, т.к. он терминал тогда только 256 цветов давал).
13 май 16, 12:24    [19168371]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
На docs.oracle.com висит предупреждающая тряпочка.

The LONG RAW datatype is provided for backward
compatibility with existing applications. For new applications,
use the BLOB and BFILE datatypes for large amounts of binary data.

Oracle also recommends that you convert existing LONG RAW
columns to LOB columns. LOB columns are subject to far fewer
restrictions than LONG columns. Further, LOB functionality is
enhanced in every release, whereas LONG RAW functionality
has been static for several releases.

Я не очень верю что они задепрекейтят LONG* типы. Но имеет смысл
учитывать что LOB будут улучшать в части оптимизации хранения
и сжатия места.
13 май 16, 12:40    [19168457]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9882
Я не про Long raw, а про просто Raw. Т.е. извращение с base64 и Varchar2 не нужно.
13 май 16, 13:22    [19168703]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Leonid Kudryavtsev,

автор
В крайнем случае, можно посмотреть есть ли поддержка RPC /remote procedure call/ в Delphi и сделать свой "сервер". Разделить проект на две части - серверная, клиентская. И общаться через какой-то механизм взаимодействия


Вызов хранимых процедур на стороне MS SQL через любой клиентский механизм доступа к данным это и есть RPC. Так что не надо никаких дополнительных серверов.
13 май 16, 13:27    [19168740]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
Leonid Kudryavtsev
Я не про Long raw, а про просто Raw. Т.е. извращение с base64 и Varchar2 не нужно.

Я как-то портировал одну СМС-ку с MS-SQL на оракл. И возникла задача перетащить SYS_GUIDS.
До меня кодеры успели наколотить OVER 9000 табличек где в оракле они заменяли MS-овскеий
SYS_GUID на оракловый RAW. Начали мигрировать клиента. Полная лажа. С кастингами замучались в PLSQL.
Тогда я плюнул. И заменил RAW на VARCHAR2 ... не помню какой длины ну вобщем это сериализованное
128 битное целое в строку + 3 или 4 дефиса в середине. Сразу стало легче. Об экономии особо не думали.
Главная задача была проект запустить. Но и щас я думаю что если эта ЦМС-ка жива - то там так и остался
VARCHAR2
13 май 16, 13:55    [19168913]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5949
mayton
заменяли MS-овскеий SYS_GUID на оракловый RAW
так они ж оба физически 16 байт, только в ms sql отображается с -

mayton
С кастингами замучались в PLSQL.
в чем проблема оказалась?
13 май 16, 14:16    [19169016]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
Уже и точно не вспомню. Но кажется они участвовали в строковых операциях. И публиковались.
13 май 16, 14:19    [19169025]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3789
mayton
Leonid Kudryavtsev
Я не про Long raw, а про просто Raw. Т.е. извращение с base64 и Varchar2 не нужно.

Я как-то портировал одну СМС-ку с MS-SQL на оракл. И возникла задача перетащить SYS_GUIDS.
До меня кодеры успели наколотить OVER 9000 табличек где в оракле они заменяли MS-овскеий
SYS_GUID на оракловый RAW. Начали мигрировать клиента. Полная лажа. С кастингами замучались в PLSQL.
Тогда я плюнул. И заменил RAW на VARCHAR2 ... не помню какой длины ну вобщем это сериализованное
128 битное целое в строку + 3 или 4 дефиса в середине. Сразу стало легче. Об экономии особо не думали.
Главная задача была проект запустить. Но и щас я думаю что если эта ЦМС-ка жива - то там так и остался
VARCHAR2

который раз убеждаюсь - вреда от guid больше чем пользы
13 май 16, 15:27    [19169402]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Dimitry Sibiryakov
Member

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

Ivan Durak
вреда от guid больше чем пользы

Если от дураков вообще нет никакой пользы кроме вреда, при чём тут GUID?..

Posted via ActualForum NNTP Server 1.5

13 май 16, 16:17    [19169732]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Сейчас ещё призрак Валеры налетит.
13 май 16, 16:26    [19169820]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
asphix
Member

Откуда: Петрозаводск
Сообщений: 52
pkarklin, дельфа XE4
13 май 16, 16:40    [19169939]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
asphix
Member

Откуда: Петрозаводск
Сообщений: 52
pkarklin, в это трудно поверить, но там самые настоящие старые модемы :)
13 май 16, 16:41    [19169946]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
asphix
Member

Откуда: Петрозаводск
Сообщений: 52
softwarer, вот забано получается - сегодня много говорят о хайлоаде, а тут обратная задача =)))
13 май 16, 16:44    [19169973]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Dimitry Sibiryakov
Member

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

asphix
в это трудно поверить, но там самые настоящие старые модемы :)

А это невозможно поверить. У настоящих старых модемов предел скорости обмена 32 килобита.
64 для ISDN. 128 это уже DSL.

Posted via ActualForum NNTP Server 1.5

13 май 16, 16:48    [19170013]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
А на каких скоростях работают банкоматы? Платежные терминалы?

Я не думаю что там мегабиты.

Ану банкиры колитесь.
13 май 16, 16:51    [19170046]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
Банкомат, это не толстый, а просто жирный клиент.
Его пакет данных это номер карты, какието пару ключей, банк эмитента, может быть чтото еще.
Все что делает банкомат, отправляет байт 100-200 в центр при транзакции, при этом еще умудряется на секунд 5-10 подвисать
и получает Ок или код ошибки и всё. Какое он имеет отношение к клиентам, которым грид может приехать от базы.

Ну я правда с банкоматами не работал, это просто инженерная мысль.
Банкомату хватит и 8кбит канал.
13 май 16, 17:01    [19170108]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Dimitry Sibiryakov
asphix
в это трудно поверить, но там самые настоящие старые модемы :)

А это невозможно поверить. У настоящих старых модемов предел скорости обмена 32 килобита.
64 для ISDN. 128 это уже DSL.
Да почему невозможно-то?
До эпохи DSL были кабельные модемы, которые примерно такие скорости и выдавали. Вот, например.
А в промышленности, да на большие расстояния - вполне возможно и сейчас.
13 май 16, 17:01    [19170110]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
mayton
А на каких скоростях работают банкоматы? Платежные терминалы?
Им хватает обычного GPRS.
А кассовые терминалы для оплаты картами еще не так давно со встроенным диалап-модемом были.
13 май 16, 17:04    [19170125]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
stop
Ну я правда с банкоматами не работал, это просто инженерная мысль. Банкомату хватит и 8кбит канал.

У банкомата основной траффик - это реклама. В смысле та муть, которую он крутит в заставке.
13 май 16, 17:04    [19170126]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
softwarer
stop
Ну я правда с банкоматами не работал, это просто инженерная мысль. Банкомату хватит и 8кбит канал.

У банкомата основной траффик - это реклама. В смысле та муть, которую он крутит в заставке.


На самом деле не реклама, а видео, которое пишут даже старые досовские банкоматы.
Но он это видео на локальный сторадж скорей всего сохраняет, потом удаляет по истечении времени.
13 май 16, 17:06    [19170139]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
stop
На самом деле не реклама, а видео, которое пишут даже старые досовские банкоматы. Но он это видео на локальный сторадж скорей всего сохраняет, потом удаляет по истечении времени.

Наверняка сохраняет. И так же наверняка качает с центра. Вот в жизни не поверю, что банковским программистам нравится разъезжать и обновлять эти ролики на 100500-х банкоматах.
13 май 16, 17:15    [19170197]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
В самом худшем раскладе я-бы предложил автору публиковать обновления справочников
в вебе или в NFS и раз в сутки синкать их через rsync или wget
13 май 16, 17:17    [19170216]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
stop
Банкомат, это не толстый, а просто жирный клиент.
Его пакет данных это номер карты, какието пару ключей, банк эмитента, может быть чтото еще.
Все что делает банкомат, отправляет байт 100-200 в центр при транзакции, при этом еще умудряется на секунд 5-10 подвисать
и получает Ок или код ошибки и всё. Какое он имеет отношение к клиентам, которым грид может приехать от базы.

Ну я правда с банкоматами не работал, это просто инженерная мысль.
Банкомату хватит и 8кбит канал.

Не уверен. Если заказать выписку по движению средств то наверное траф будет чуть поболее.

Хотя в 99% случаев это операции типа пополнить баланс или чето снять.

P.S. Тоже инженерная мысль.
13 май 16, 17:19    [19170224]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить