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

Откуда:
Сообщений: 35345
artemana
vadiminfo

или сервера приложений.

На сервер приложений, работающий со своим клиентом через SQL? И при этом клиент не догадывается к кому он подключен, к серверу БД или к серверу приложений? И у этого сервера приложений, кроме пула коннектов, и зашитой в него бизнес логики, есть еще и самостоятельно поддерживаемый свой кеш данных из центральной БД? И в нем он, по возможности, выполняет SQL-запросы своих клиентов, блокируя их отправку на центральный сервер? Ух ты! Не слышал о таком! Ссылки есть? Если это так, то я признаю что MDT похожа на этот сервер приложений. А так же укажу на то, что систему, включающую такой сервер приложений можно считать системой управления распределенными данными. Чуть ранее я писал, прочтите, если не трудно, какое наполнения я вкладываю в это понятие

При работе с сервером приложений клиент подключен к этому серверу приложений, а уже сервер - к одной или десятку БД. То о чем идет речь в теме известно давно, под именем Briefcase.
3 сен 10, 14:05    [9379306]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
iscrafm

При работе с сервером приложений клиент подключен к этому серверу приложений, а уже сервер - к одной или десятку БД.

Это концептуальное положение понятно и очевидно. Вопрос в том, можно ли считать такой сервер-приложение системой управление распределенными данными?
ИМХО, можно, особенно если он работает со своими клиентами посредством чистого SQL и не обязывает их конкретизировать местоположение запрашиваемых источников данных- таблиц, процедур и view. А по вашему?
iscrafm

То о чем идет речь в теме известно давно, под именем Briefcase.

К сожалению не знаком. Я правильно понял из поверхностного чтения, что Briefcase это синхронизация файлов?
3 сен 10, 14:27    [9379627]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6641
artemana,

Это "Портфель" из Windows 95 =)

Нифига не понял из описания на вашем сайте. Уж подробно так ПОДРОБНО....
3 сен 10, 14:29    [9379659]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Siemargl
artemana,

Это "Портфель" из Windows 95 =)

Если и да, то гораздо мощнее, но специализация явно уже.
Siemargl

Нифига не понял из описания на вашем сайте. Уж подробно так ПОДРОБНО....

Ну спроси что нибудь что ли. ;)
3 сен 10, 14:33    [9379723]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6641
Точнее не "не понял", а "не осилил мого букофф".

Подробности как когерентность кэша обеспечивается не вник. Серверах этак на пяти.
Глобальные таблицы отслеживания обновлений - не будут ли одним общим тормозом?
3 сен 10, 14:41    [9379836]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
artemana
iscrafm

При работе с сервером приложений клиент подключен к этому серверу приложений, а уже сервер - к одной или десятку БД.

Это концептуальное положение понятно и очевидно. Вопрос в том, можно ли считать такой сервер-приложение системой управление распределенными данными?
ИМХО, можно, особенно если он работает со своими клиентами посредством чистого SQL и не обязывает их конкретизировать местоположение запрашиваемых источников данных- таблиц, процедур и view. А по вашему?

по моему тоже. По общепринятому, так сказать, определению - тоже

iscrafm

То о чем идет речь в теме известно давно, под именем Briefcase.

К сожалению не знаком. Я правильно понял из поверхностного чтения, что Briefcase это синхронизация файлов?[/quot]
да, в общем-то. Это модель, позволяющая клиенту работать с локальными источниками данных, которые, в свою очередь, синхронизируются с центральным сервером(ами).

Siemargl конечно же пошутил.
3 сен 10, 14:41    [9379837]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
цитирование слетело. правильно так:

artemana
iscrafm

То о чем идет речь в теме известно давно, под именем Briefcase.

К сожалению не знаком. Я правильно понял из поверхностного чтения, что Briefcase это синхронизация файлов?

да, в общем-то. Это модель, позволяющая клиенту работать с локальными источниками данных, которые, в свою очередь, синхронизируются с центральным сервером(ами).

Siemargl конечно же пошутил.
3 сен 10, 14:44    [9379880]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6641
iscrafm
Siemargl конечно же пошутил.
Наполовину.
Briefcase в левом нижнем углу.
3 сен 10, 14:44    [9379892]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Siemargl
iscrafm
Siemargl конечно же пошутил.
Наполовину.
Briefcase в левом нижнем углу.

речь идет о Briefcase-модели, применительно к обсуждаемой теме. Вы при слове ORACLE на форуме о СУБД провидца не упоминаете.
3 сен 10, 14:48    [9379940]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
artemana
Ну и в чем и где углядели похожесть?
Многопользовательские файл-серверные СУБД так не работают. Они не качают к себе файлы, они самостоятельно и напрямую обрабатывают их (читают, пишут) в том месте, где они размещены (общие файловые шары). Собственно отсюда и все их основные проблемы

файл-серверные СУБД находятся на клиенте, и могут только качать к себе данные файл сервера, и у себя выполнять запросы. На основе чего могут и менять сами файлы. Ну как я писал Аксцесса моно юзать в качестве приложения к клиент-серверной СУБД. В общем похожесть в том, что он читает данные из файла, а запросы выполняет у себя. В этом азбучное отличие от клиент серверных, которые на сервере и там же выполняют запросы.


artemana

На сервер приложений, работающий со своим клиентом через SQL? И при этом клиент не догадывается к кому он подключен, к серверу БД или к серверу приложений? И у этого сервера приложений, кроме пула коннектов, и зашитой в него бизнес логики, есть еще и самостоятельно поддерживаемый свой кеш данных из центральной БД? И в нем он, по возможности, выполняет SQL-запросы своих клиентов, блокируя их отправку на центральный сервер? Ух ты! Не слышал о таком! Ссылки есть? Если это так, то я признаю что MDT похожа на этот сервер приложений. А так же укажу на то, что систему, включающую такой сервер приложений можно считать системой управления распределенными данными. Чуть ранее я писал, прочтите, если не трудно, какое наполнения я вкладываю в это понятие

И не тока через SQL. Моно ОЛАПы там строить. Кеш есть. Я Вам писал про Оракловый.
Распределенной СУБД это считать нельзя. Это можно считать трехуровневой клиентсерверной архитектурой с сервером прилрожений. А распределенной СУБД Оракл и так является
даже в двух уровневой, но с многими локальными БД, в общем случае в разных городах и даже странах и даже космосах. У него ваще есть Грид технология. Там даже встроенный БД могут участвовать. Встроенный в пулеметы на вертолетах. А Вы говорите.
Я Вам намекаю, что такие простые идеи реализованы. Я Вам даже намекал куда копать. Но Вы не верите.

artemana

Теперь понятно. Vadiminfo встретив в тексте слово 'компоненты' не может от него отвязаться. Надо переделывать главную страницу сайта. ;)

Думаю не тока я. Без компонентов не сразу буит ясно, что Вы там налабали. А компонты есть - ясно это клиент, либо подобие сервера приложений. Не СУБД же на Дельфи лабать?
Если Вы хотитет толкать это как распределенную СУБД не смотря ни на что, то надо убрать слова про Птицу: если она не распределенная, то и у Вас не распределенная. А если распределенная то зачем Вы с Вашими компонентами? Распределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути.
3 сен 10, 14:56    [9380051]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo
Распределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути.

а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение.
3 сен 10, 15:01    [9380134]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Siemargl
Точнее не "не понял", а "не осилил мого букофф".

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

1. MDT - обеспечивает синхронизацию центральных данных с локальной копией. Ну почти как портфель, только намного эффективней.;) Это один из основных текущих вариантов, уже почти скоро будет и другая ветка многопользовательских альтернативных копий, но сейчас предлагаю для хоть какой-нибудь ясности ее не цеплять.

2. Центральные данные могут находится как в одной базе так и в нескольких. При этом не должно быть пересечений по именам метаданных. Проще говоря, каждая таблица только в одной центральной БД. Соответственно никакого общего журнала синхронизации нет, в каждой центральной базе он свой.

4. MDT использует максимально эффективное журналирование, согласно которому для логирования операций вставки и изменения записей не выделяется отдельных таблиц. В каждую таблицу добавляется лишь одно целочисленное поле и индекс по нему. Синхронизация выполняется методом приращений (тянуться только новые записи) и только по необходимости, то есть если клиент таблицу "A" не использует, то она у него синхронизировать не будет

3. В случае нескольких центральных БД, MDT-слой (боюсь употребить слово компонента ;), зная положение каждой из них, объединяет все их данные в одну локальную копию и при выполнении на этой копии поступившего от клиента читающего запроса уже не нужно знать, откуда поступили реальные данные, из одной ЦБ или из нескольких. Таким образом одну логическую модель данных приложения, можно в зависимости от требований развернуть на одной или нескольких ЦБ. В любом случае читающие запросы выполняются без использования центральных серверов, что увеличивает пиковую производительность по читающим операциям всей системы в целом прямо порпорционально количеству ее клиентов.
3 сен 10, 15:13    [9380286]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
iscrafm
vadiminfo
Распределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути.

а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение.

Ни себя и ни других!
3 сен 10, 15:16    [9380317]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
iscrafm
vadiminfo
Распределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути.

а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение.

Не в курсах какую кучу Вы имеет в виду, и сверху чего и как налеплено. Оракл поддерживает реляционную МД, потому его относят к RDBMS. Если эти парни налабают свое СУБД тада ве равно, что там внутри. Я ему предлагал залезть внутрь Птицы, и там налабать хоть сверхзу, хоть снизу поддержку распределенности. Ну назвал бы распределенная СУБД МТДПТИЦА.
3 сен 10, 15:19    [9380347]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo
iscrafm
vadiminfo
Распределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути.

а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение.

Не в курсах какую кучу Вы имеет в виду, и сверху чего и как налеплено.

странно. Я думал, что вы специалист по ораклу и знаете его устройство и историю. Ладно, тогда проехали.
3 сен 10, 15:22    [9380370]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
iscrafm
странно. Я думал, что вы специалист по ораклу и знаете его устройство и историю. Ладно, тогда проехали.

Меньше думать надо, а соображать больше (С) Брат2. Я, например, думал что, Вы тоже не специалист в БД. Мало ли кто о чем думал.
Это никак не поможет выдать ему его слой за распределенную СУБД. Вроде, видно же, что это похоже на сервер приложений: он уже сам это слоем назвал. Вот о чем бы Вы луче подумали в этой ветке.
А я даже не пользуюсь такими терминами как "устройство" по отношению к Ораклу, тока по отношению к своему авто.
3 сен 10, 15:31    [9380448]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
vadiminfo
Я ему предлагал залезть внутрь Птицы, и там налабать хоть сверхзу, хоть снизу поддержку распределенности. Ну назвал бы распределенная СУБД МТДПТИЦА.

А Вам еще раз, 3 раз, говорю, что уже залез во внутрь, и поддержку распределенности осуществляет специальная библиотека (dll), заменяющая стандартную из поставки FB.
Я понимаю что Вы возможно не знаете как устроено взаимодействие клиента FB с сервером FB, но прошу, поверьте мне на слово - Нет Delphi, нет компонент, а распределенность есть.

Кстати название МТДПТИЦА мне понравилось, но лучше поменять местами. Да и вопрос то в другом, летает или не летает, и как будет летать дальше. Для наших потребностей (www.grossbee.com) самое то, а как для других сказать не могу - пока нет реальных проектов, увы.
3 сен 10, 15:37    [9380511]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo
iscrafm
странно. Я думал, что вы специалист по ораклу и знаете его устройство и историю. Ладно, тогда проехали.

Меньше думать надо, а соображать больше (С) Брат2. Я, например, думал что, Вы тоже не специалист в БД. Мало ли кто о чем думал.
Это никак не поможет выдать ему его слой за распределенную СУБД. Вроде, видно же, что это похоже на сервер приложений: он уже сам это слоем назвал. Вот о чем бы Вы луче подумали в этой ветке.
А я даже не пользуюсь такими терминами как "устройство" по отношению к Ораклу, тока по отношению к своему авто.

набор слов, да еще и с ошибками. Кто, в том же оракле, делает БД распределенной наверное не в курсе. Ладно, занимайтесь своим авто, не буду мешать.
3 сен 10, 15:48    [9380608]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
artemana
А Вам еще раз, 3 раз, говорю, что уже залез во внутрь, и поддержку распределенности осуществляет специальная библиотека (dll), заменяющая стандартную из поставки FB.
Я понимаю что Вы возможно не знаете как устроено взаимодействие клиента FB с сервером FB, но прошу, поверьте мне на слово - Нет Delphi, нет компонент, а распределенность есть.

Если говорите о распределенной СУБД, то не должно иметь значения взаимодействие клиента с сервером - это взаимодействие серверов БД.
Ну так тада Вы типа модифицировали Птицу? Но все за пределами птицы это не относится к управлению распределенностью БД. Такскание на клиентов или куда там данных это другие уровни или там слои - это не управление БД.
3 сен 10, 15:51    [9380654]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6641
artemana
Siemargl
Точнее не "не понял", а "не осилил мого букофф".

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

1. MDT - обеспечивает синхронизацию центральных данных с локальной копией. Ну почти как портфель, только намного эффективней.;) Это один из основных текущих вариантов, уже почти скоро будет и другая ветка многопользовательских альтернативных копий, но сейчас предлагаю для хоть какой-нибудь ясности ее не цеплять.

Вопрос был "как?". Считал один клиент себе копию и с ней работает только читающими запросами. А другой клиент - изменил в центральной базе. Первый как узнает, что его данные уже устарели?

artemana

2. Центральные данные могут находится как в одной базе так и в нескольких. При этом не должно быть пересечений по именам метаданных. Проще говоря, каждая таблица только в одной центральной БД. Соответственно никакого общего журнала синхронизации нет, в каждой центральной базе он свой.

Он же один для всех клиентов этой ц.базы. И они конкурентно в него обращаются. Должны мешать друг другу. Интересный эффект как обходится - если данные обновил, полез дописать в журнал и обломился?
3 сен 10, 16:03    [9380781]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
iscrafm
набор слов, да еще и с ошибками. Кто, в том же оракле, делает БД распределенной наверное не в курсе. Ладно, занимайтесь своим авто, не буду мешать.

Ваш набор слов про кучи и сверху граматически, возможно, грамотен.
Но и только.
Не в "том же Оракле делает БД распределенной", а тот же Оракл обеспечиваент управление распределенной БД в соотвествии с некими требованиям, которые позволяют или не позволяют СУБД относить к распределенным. Не важен фрагмент кода, библиотеки: важно как поддерживаетсмя распределенность данной СУБД. Но именно СУБД.
А БД то вы можете распределить в сети, клиентом приконектиться к нескольким, выполнить к кажной запрос, а потом в цикле обработать. Это не относят к распределенным СУБД.
3 сен 10, 16:03    [9380786]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
vadiminfo

Ну так тада Вы типа модифицировали Птицу?

Plugin, расширение - эти термины Вам знакомы?
vadiminfo

Но все за пределами птицы это не относится к управлению распределенностью БД. Такскание на клиентов или куда там данных это другие уровни или там слои - это не управление БД.

Очень даже управление и очень даже распределенными данными. Вы спорите, не приведя ни одной ссылки с общепризнанным или авторитетным мнением, на то, что можно считать системой управление распределенными данными, а что нет. Ваше представление в этом вопросе, ИМХО, выглядит так: если все средства (всю систему) управления распределенностью выпустила одна компания и ее имя начинается на О, значит это действительно средства для управление распределенными данными, все остальное на звание "система управление распределенными данными" претендовать не может. Мне грустно-смешно.
3 сен 10, 16:09    [9380859]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Siemargl
Вопрос был "как?". Считал один клиент себе копию и с ней работает только читающими запросами. А другой клиент - изменил в центральной базе. Первый как узнает, что его данные уже устарели?

По мере изменения данных центральной базы активные клиенты получают асинхронные сообщения с данными о том, в каких таблицах и какие операции были сделанны.
Siemargl

Он же один для всех клиентов этой ц.базы. И они конкурентно в него обращаются. Должны мешать друг другу.

Если Вы имеет ввиду взаимные блокировки при одновременном чтении журналов, то их нет в IB\FB\Ya с самого рождения.
Siemargl

Интересный эффект как обходится - если данные обновил, полез дописать в журнал и обломился?

Формирование данных и журналов производится в одной транзакции.
Кроме того каждый клиент не формирует журнал самостоятельно, за это отвечаю триггера.
И еще кроме того, как я говрил ранее, отдельный журнал (таблица) только для удалений, вставка и изменения отдельнными таблицами не логируется.
3 сен 10, 16:20    [9381013]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6641
artemana,

>Если Вы имеет ввиду взаимные блокировки при одновременном чтении журналов, то их нет в IB\FB\Ya с самого рождения.
Речь о записи конечно.

Со второй попытки дочитал до середины. Основные идеи понял.
Все разделяемые таблицы обвешиваются триггерами. Тяжеловато.

В общем идея хорошая, но основное ее достоинство в том, что она для IB/FB, где такого нет.
Можно ее распространить на другие СУБД без репликации, но их мало.

А стандартная поддержка таких решений от вендора Sybase ASA, MS, ORA конечно приятнее для надежности и спокойствия, но не для кошелька )
3 сен 10, 16:31    [9381188]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo
iscrafm
набор слов, да еще и с ошибками. Кто, в том же оракле, делает БД распределенной наверное не в курсе. Ладно, занимайтесь своим авто, не буду мешать.

Ваш набор слов про кучи и сверху граматически, возможно, грамотен.
Но и только.
Не в "том же Оракле делает БД распределенной", а тот же Оракл обеспечиваент управление распределенной БД в соотвествии с некими требованиям, которые позволяют или не позволяют СУБД относить к распределенным. Не важен фрагмент кода, библиотеки: важно как поддерживаетсмя распределенность данной СУБД. Но именно СУБД.
А БД то вы можете распределить в сети, клиентом приконектиться к нескольким, выполнить к кажной запрос, а потом в цикле обработать. Это не относят к распределенным СУБД.

бла-бла-бла. Ответьте на простой вопрос: в том же оракле, грид это работа DBMS или целого стека технологий, объединенных по именем оракла? RAC - это DBMS или система "над" Ora..DBMS?
3 сен 10, 16:31    [9381191]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить