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

Откуда:
Сообщений: 408
Пожалуйста, проведите ликбез по распределенным базам данных.

Входит ли в понятие распределенной базы данных, то что база не имеет единного ядра?

Или ядро располагается на центральном сервере, а клиентские данные на других серверах?

Каким образом производится синхронизация (репликация) данных при вводе новых параметров, например, в справочники?

Имеется ли какой-нибудь метод синхронизации данных между серверами в распределенных базах данных, кроме репликации.
23 янв 06, 16:55    [2279106]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

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

PVB пишет:

> Входит ли в понятие распределенной базы данных, то что база не имеет
> единного ядра?

Распределенная - значит распределенная. Часть здесь, часть там и т.д.

> Или ядро располагается на центральном сервере, а клиентские данные на
> других серверах?

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

> Каким образом производится синхронизация (репликация) данных при вводе
> новых параметров, например, в справочники?

Можно путем отправки изменений, вносимых в базу

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

Масло масляное, то есть, говоря по научному, тавтология :) Иногда
полезно заглядывать в словари, чтобы выяснить смысл и происхождение
терминов. В данном контексте можно считать репликацию и синхронизацию
синонимами.

Задавай лучше вопросы по-существу. Или это опять что-нибудь типа диплома
или курсовика?

Posted via ActualForum NNTP Server 1.3

24 янв 06, 21:55    [2283901]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
К распределенным БД относятся прежде всего те системы, которые позволяют связать два сервера между собой так, что из одного сервера видны таблицы расположенные на другом сервере и к этим таблицам можно обращаться при помощи DML операторов. Т.е. один сервер бд. может быть клиентом другого.
Это один из самых тормознутых способов организации работы.

Системы репликации (ИМХО) это нечто большее. Это скорее всего возможность отложенного удаленного изменения в таблицах, которые являются общими для нескольких серверов (вне зависимости от того, однонаправленная или двунаправленная репликация). Двунаправленная репликация - это самый большой геморрой, какой только можно вообразить. Потому как добиться целостности в этом случае очень и очень сложно.
Однонаправленная репликация хороша для организации DSS, DWH.

Если говорить о взаимодействии удаленных бд, то на мой взгляд - это системы на основе очередей сообщений. Это третий вариант и самый (ИМХО) перспективный, самый производительный и самый гибкий и не такой ресурсоемкий как репликация.
25 янв 06, 10:48    [2284957]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
gardenman
Двунаправленная репликация - это самый большой геморрой, какой только можно вообразить. Потому как добиться целостности в этом случае очень и очень сложно.

Да что Вы говорите. То то на ASA эти самые двунаправленные репликации с кодами подписчиков, возможностью своего указания направления движения информации и даже перераспределения информации между узлами в случае изменения ее области видимости поднимаются на раз, глобальные инкременты, автоматически ведущие счетчики в разрезах под каждую БД ставятся на два, триггера обработки ситуации одновременного изменения одной записи разными узлами пишутся на три, одним кликом мыши выгружается готовая БД из консолидированной со схемой и нужными данными для узла на четыре и все это визуально управляется на пять Так что не надо - двунаправленные репликации - это просто и удобно, если готовить на подходящей платформе.
25 янв 06, 10:57    [2285013]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
2 ASCRUS
Не знаю как между ASA-ASA, но ASA-ASE - это выглядело чудовищно... :(
25 янв 06, 11:09    [2285084]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
gardenman
2 ASCRUS
Не знаю как между ASA-ASA, но ASA-ASE - это выглядело чудовищно... :(

А вот не надо мазохизмом заниматься просто :)
25 янв 06, 11:26    [2285198]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ASCRUS
Так что не надо - двунаправленные репликации - это просто и удобно, если готовить на подходящей платформе.

А если добавить возможность отложенного обновления? Тогда (в зависимости от структуры базы) проблемы с целостностью могут быть большими или очень большими :) .
25 янв 06, 11:55    [2285400]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

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

Локшин Марк пишет:

> А если добавить возможность отложенного обновления?

Что понимается под отложенным обновлением?

> Тогда (в зависимости
> от структуры базы) проблемы с целостностью могут быть большими или очень
> большими :) .

Чудес не бывает. Головой думать надо при проектировании. Просто при
использовании ASA больше времени остается на обдумывание этого самого
проектирования, т.к. отлаженные механизмы и технологии репликации уже
готовы.

Posted via ActualForum NNTP Server 1.3

25 янв 06, 12:01    [2285442]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Локшин Марк
ASCRUS
Так что не надо - двунаправленные репликации - это просто и удобно, если готовить на подходящей платформе.

А если добавить возможность отложенного обновления? Тогда (в зависимости от структуры базы) проблемы с целостностью могут быть большими или очень большими :) .

Думать головой при проектировании БД это второе, первое - нужно просто еще думать головой и при построении правильных технологических процессов. Для реализации репликации любого уровня сложности в ASA все необходимое уже есть. Однако каким узлам принадлежит та или иная информация, как часто будет идти обмен изменениями, кто, что и где имеет право изменять, почему и зачем информация должна изменятся на разных удаленных узлах одновременно и чья версия записи будет считаться правильной в данном случае - на все эти и прочие вопросы и необходимо первоначально знать ответ перед тем, как спроектировать БД и схему репликации. Так что я и моими коллеги по ASA в не частой периодической сеансовой репликации сложностей совсем не видим (хоть раз в год), главное знать что нужно, как правильно это сделать и иметь подходящий инструмент, функционально покрывающий потребности поставленных задач.
25 янв 06, 12:14    [2285534]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Александр Гoлдун
Что понимается под отложенным обновлением?

Изменения передаются на другой сервер не в транзакции, от нескольких секунд, до достаточно большого промежутка времени.
Александр Гoлдун
Чудес не бывает. Головой думать надо при проектировании. Просто при использовании ASA больше времени остается на обдумывание этого самого проектирования, т.к. отлаженные механизмы и технологии репликации уже готовы.

Это если известно на момент проектирования, что система будет распределенной. Отлаженные механизмы - это хорошо, но в них тоже не всегда все есть. Вот например, есть ли в ASA подокументная репликация, а репликация последовательности документов для сохранения целостности базы? А если что-нибудь поэкзотичнее придумать? :)
25 янв 06, 12:24    [2285589]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Здесь восможно есть разница междк понятиями распределенная БД и распределенная СУБД. Первая это просто распределенная в сети БД любого качества. В частности файловые системы БД не имеют СУБД, но могут быть распределены. Ко второй предявляется ред требваний. В частности, чтобы пользователь воспринимал ее как цетрализованную и при написании DML (не указывал ссылок на локальные БД), по времени доступа (для этого и применяют репликацию) и т.д. По моему? Дейт выдвинул 12 требований, чтобы СУБД имело право на такое название. И вроде есть такие, которые ни одна СУБД не может выполнить на сегодняшний день. С другой стороны выполнение всех может привести к значительному усложнению администрирования.

Асинхронная двунаправленная репликация наверняка опасна - допустим она 3 месяца не работала и этого не заметили или не поняли парни. Теперь поди отличи правильное неправильного. Например, если репликация одноранговая, (все мастера), то тада все эти отложенные транзакции не могут выполняться из-за разных причин, которые тоже надо устранять в общем случае с помощью моментальных снимков структуры объектов. Например, в какой-то момент были отключены констрейны. Теперь их оже надо отключать для транзакций того времени и т.д.
25 янв 06, 12:29    [2285626]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ASCRUS
Для реализации репликации любого уровня сложности в ASA все необходимое уже есть.

Очень похоже на заявления из отдела продаж :) Ну тогда и в MS SQL для реализации репликации любого уровня сложности все есть. Доработать только чуть-чуть необходимо :). Как впрочем, и в ASA.
ASCRUS
на все эти и прочие вопросы и необходимо первоначально знать ответ перед тем, как спроектировать БД и схему репликации.

А, так вот пока это выясните, большая часть времени и уйдет. Пока объясните заказчику, что если проводить репликацию раз в день, и требовать чтобы все было "как в одной базе" - вещи несовместимые.
25 янв 06, 12:35    [2285651]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
vadiminfo
По моему? Дейт выдвинул 12 требований, чтобы СУБД имело право на такое название. И вроде есть такие, которые ни одна СУБД не может выполнить на сегодняшний день. С другой стороны выполнение всех может привести к значительному усложнению администрирования.

Дык все вместе они и не могут быть удовлетворены в полном объеме. По-моему у него же про это и рассуждения идут... Требование локальной автономии узлов и непротеворечивости данных - они несколько взаимоисключающие.
25 янв 06, 12:41    [2285680]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Вот например, есть ли в ASA подокументная репликация, а репликация последовательности документов для сохранения целостности базы?

Что такое "подокументная репликация" и "репликация последовательности документов" ?

P.S. Для справки - в ASA репликация идет по лог-файлу БД, то есть на удаленные узлы и обратно в консолидированные реплицируются не данные, а SQL скрипты, которые были зафиксированны в лог-файле на момент их удачного выполнения. Причем в механизме лог-файла сразу предусмотренны различные расширения для репликации, позволяющие по области видимости информации указывать, по каким узлам пойдут зафиксированные DML скрипты, будут ли на узлы пересылаться все DML-операторы, выполненные внутри триггеров, есть режим прямой трансляции по узлам любых, в т.ч. DDL операторов для изменения схем удаленных БД. К примеру в консолидированной БД в таблицу добавляется поле и потом оно обновляется:
PASSTHROUGH FOR SUBSCRIPTION TO Pub_User.Pub_Name;
ALTER TABLE Table1 
  ADD NewField int NOT NULL DEFAULT 0;

...

PASSTHROUGH STOP;

UPDATE Table1
SET NewField = 1;
Здесь по консолидированному подписчику Pub_User на публикацию Pub_Name будет на консолидированной БД выполнено добавление столбца в таблицу и в случае успешного выполнения скрипта, разослано всем подписчикам публикации. Далее будет обновленно добавленное поле таблицы, изменения которого разойдутся по всем подписчикам в зависимости от информации, описанных в правилах репликации подписчиков. Соотвествующе в лог-файле эти SQL-операторы будут зафиксированны, в дальнейшем передадуться по удаленным БД и будут выполнены. Естественно через утилиту трансляции лог-файла их можно будет спокойно поднять из лога в SQL-скрипт чтобы посмотреть, как это выглядит на самом деле и естественно в случае потери пакетов или отката удаленной БД с бакупа ранее точки выполнения этих операторов, репликация их снова выполнит на удаленной БД. Так что лично я никаких сложностей в ссылочной целостности двусторонних репликаций ASA до сих пор не заметил

автор
А, так вот пока это выясните, большая часть времени и уйдет. Пока объясните заказчику, что если проводить репликацию раз в день, и требовать чтобы все было "как в одной базе" - вещи несовместимые.

Это что то новенькое - а как же не выяснять то ТЗ, перед написанием проекта ? И на это действительно больше всего времени уходит, если мы не хотим получить безнадежный проект. А обьяснять заказчику я ничего не буду, это он мне будет обьяснять, а я ему задавать грамотные профессиональные вопросы. И кстати опять не понимаю фразы "требовать, чтобы было все как в одной базе" ? У меня различные схемы репликаций на проектах есть - и с централизованными справочниками и разделением данных по узлам и общим владением данных по узлам, даже форумы по узлам,новостные каналы и единая админстраторская консоль управления всеми узлами с любого узла - все это как бы не испытывает проблем и я не помню, что мне реализация каких либо ньюансов на ASA доставило хлопоты или геммор.

автор
Очень похоже на заявления из отдела продаж :)

Это не заявления, а факты. На Украине есть пару проектов на ASA, филиалы которых периодически и не часто поднимают информацию на верх, где имеется 500-700 удаленных узлов. За рубежом реально работают проекты продаж, имеющие 10000 удаленных узлов (я уж молчу про КПК решения, там узлы никто не считает). В России так же уже имеются подобные проекты, начиная от автоматизации казино и бензоколонок, заканчивая обменом информации в крупных холдингах, где каждый узел - это огромные предприятия и большое кол-во информации. Странно, что в реальности все это прекрасно работает, причем само, без админов на узлах, а в теории Вы рассуждаете, что это невозможно или сложно
25 янв 06, 12:49    [2285712]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

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

Локшин Марк пишет:

>> Что понимается под отложенным обновлением?
> Изменения передаются на другой сервер не в транзакции, от нескольких
> секунд, до достаточно большого промежутка времени.

Это называется офф-лайн репликация, в противовес онлайновой. У меня
практически вся такая. От 10-минутных интервалов с отправкой сообщений
по email или ftp до интервалов в несколько дней с обменом при помощи
курьера с дискетой. Причем все делалось штатными средствами ASA

> Это если известно на момент проектирования, что система будет
> распределенной.

Мне приходилось налаживать удаленные рабочие места с off-line
репликацией для существующих баз, при разработке которых было еще
неизвестно про подобную надобность. Если структура просто грамотно
спроектирована, то все реально. Делалось даже без изменения структуры.
Просто первичные ключи, которые автоинкрементные, разбивались на
диапазоны, кстати тоже штатными средствами

> Отлаженные механизмы - это хорошо, но в них тоже не
> всегда все есть. Вот например, есть ли в ASA подокументная репликация, а
> репликация последовательности документов для сохранения целостности
> базы?

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

> А если что-нибудь поэкзотичнее придумать? :)

Для теоретизирования или для практических нужд.

Posted via ActualForum NNTP Server 1.3

25 янв 06, 14:03    [2286133]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ASCRUS
Что такое "подокументная репликация" и "репликация последовательности документов" ?

Пример: у нас есть документ, который хранится в базе в виде двух таблиц шапка/подвал. Допустим, какой-то документ уже среплицировался между двумя базами. И тут обнаружилось, что в документ в забили внести одну строку в подвал. Набивают в обоих базах. Происходит репликация. В результате имеем документ с лишней строкой. Это самый тривиальный пример. Если поредактировать какой-нибудь иерархический документ можно тоже много веселого поиметь (даже редактируя только различные записи на разных узлах). Можно вместо дерева запросто произвольный граф получить :)
ASCRUS
P.S. Для справки - в ASA репликация идет по лог-файлу БД, то есть на удаленные узлы и обратно в консолидированные реплицируются не данные, а SQL скрипты, которые были зафиксированны в лог-файле на момент их удачного выполнения

И только? Других вариантов нет?
ASCRUS
Это что то новенькое - а как же не выяснять то ТЗ, перед написанием проекта ?

Я про то, что это отнимет времени как бы не больше, чем реализация самой репликации на уровне послать строку/скрипт вставить сроку/запустить скрипт.
ASCRUS
И кстати опять не понимаю фразы "требовать, чтобы было все как в одной базе" ?

А вот так. Чтобы остатки всегда актуальные были, чтобы конфликтов при изменении данных не было. Типа как с одной базой в одной сети работают. Внес и забыл...
ASCRUS
Так что лично я никаких сложностей в ссылочной целостности двусторонних репликаций ASA до сих пор не заметил

Не с сылочной целостностью, а с согласованностью изменений на различных узлах, улыбчивый вы наш.
25 янв 06, 14:06    [2286147]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
мод
Guest
основное отличие распределенной БД от просто набора БД с репликацией это поддержка распределенных транзакций
25 янв 06, 14:16    [2286219]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Александр Гoлдун
Это называется офф-лайн репликация, в противовес онлайновой.

Тут можно еще и поспорить, что такое офф-лайн репликация. Но в терминологии репликации MS SQL как ни странно, такой термин есть (отложенное обновление) и означает он именно репликацию с последующим обновлением других баз данных не в рамках одной транзакции (а возможно через большие промежутки времени).
Александр Гoлдун
Публикация - набор таблиц, причем не только таблиц целиком, но и частей таблиц как по горизонтали, так и по вертикали. Что такое документ, как не набор записей в нескольких таблицах?

Набор то он набор, но хотелось бы иметь целостность этого набора. (см. пример в предыдущем посте).
25 янв 06, 14:21    [2286267]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Локшин Марк
ASCRUS
Что такое "подокументная репликация" и "репликация последовательности документов" ?

Пример: у нас есть документ, который хранится в базе в виде двух таблиц шапка/подвал. Допустим, какой-то документ уже среплицировался между двумя базами. И тут обнаружилось, что в документ в забили внести одну строку в подвал. Набивают в обоих базах. Происходит репликация. В результате имеем документ с лишней строкой. Это самый тривиальный пример. Если поредактировать какой-нибудь иерархический документ можно тоже много веселого поиметь (даже редактируя только различные записи на разных узлах). Можно вместо дерева запросто произвольный граф получить :)

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

Локшин Марк
ASCRUS
P.S. Для справки - в ASA репликация идет по лог-файлу БД, то есть на удаленные узлы и обратно в консолидированные реплицируются не данные, а SQL скрипты, которые были зафиксированны в лог-файле на момент их удачного выполнения

И только? Других вариантов нет?

Насколько мне известно: оффлайн репликация по лог-файлу - это самый надежный, мало потребляющий ресурсов сервера и выдерживающий огромные нагрузки способ репликации серверов, гарантирующий доставку информации, ссылочную целостность, поддержку изменения схемы БД и т.д. Уж все лучше, чем срезы, timestamp и прочие танцы с бубнами, которые кстати поддерживаются в другом штатном механизме репликации ASA Mobilink, что правда было сделано из за того, что он предназначен для гетерогенных репликаций ASA с серверами других производителей и я мало видел ASA-шников, которые хотели бы иметь лишний геммор, имея на всех узлах только ASA и используя вместо SQLRemote репликацию MobiLink.

Локшин Марк
ASCRUS
Это что то новенькое - а как же не выяснять то ТЗ, перед написанием проекта ?

Я про то, что это отнимет времени как бы не больше, чем реализация самой репликации на уровне послать строку/скрипт вставить сроку/запустить скрипт.

Репликацию реализовывать не нужно, она есть и все умеет. Нужно точно знать только, что нужно реализовать, а не гадать на кофейной гуще.


Локшин Марк
ASCRUS
И кстати опять не понимаю фразы "требовать, чтобы было все как в одной базе" ?

А вот так. Чтобы остатки всегда актуальные были, чтобы конфликтов при изменении данных не было. Типа как с одной базой в одной сети работают. Внес и забыл...

Так и есть - есть логика движения информации, есть разделение информации по узлам и понятие общей информации, есть триггера конфликтов версий - все при правильном сложении дает искомый результат.

Локшин Марк
ASCRUS
Так что лично я никаких сложностей в ссылочной целостности двусторонних репликаций ASA до сих пор не заметил

Не с сылочной целостностью, а с согласованностью изменений на различных узлах,

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

Локшин Марк
улыбчивый вы наш.

Спасибо, Вам тоже желаю хорошего настроения
25 янв 06, 14:38    [2286397]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
мод
основное отличие распределенной БД от просто набора БД с репликацией это поддержка распределенных транзакций

про двухфазное принятие - это в яблочко.Такая фигня с репликацией не прокатит.
25 янв 06, 14:39    [2286401]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

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

Локшин Марк пишет:

> двумя базами. И тут обнаружилось, что в документ в забили внести одну
> строку в подвал. Набивают в обоих базах.

Пример некорректного проектирования. Не проектирования БД, а на более
раннем этапе - некорретная постановка методики работы с документами.

> Если поредактировать какой-нибудь иерархический документ можно
> тоже много веселого поиметь

Много веселого можно поиметь и безо всякой репликации, если много
извращаться, при этом мало думая. Надо четко расписывать документооборот
- кто где чего и когда может делать.

>> P.S. Для справки - в ASA репликация идет по лог-файлу БД, то есть на
>> удаленные узлы и обратно в консолидированные реплицируются не данные, а
>> SQL скрипты, которые были зафиксированны в лог-файле на момент их
>> удачного выполнения

> И только? Других вариантов нет?

А этого недостаточно? Какие нужны другие варианты? Такая технология
позволяет, например, легко и безболезненно организовать одновременную
правку в разных базах разных полей ОДНОЙ И ТОЙ ЖЕ записи. При построчной
репликации измененных записей такое сделать проблематично.

Posted via ActualForum NNTP Server 1.3

25 янв 06, 14:46    [2286474]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
gardenman
про двухфазное принятие - это в яблочко.Такая фигня с репликацией не прокатит.

Смотря в каком смысле. У Оракла есть синхронная репликация. Она конечно прокатикат тока на реальных сетевых устройствах - иначе они набегаются.
25 янв 06, 14:56    [2286543]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Александр Гoлдун
Пример некорректного проектирования. Не проектирования БД, а на более раннем этапе - некорретная постановка методики работы с документами.

А, я понял. На ASA можно сделать все. То, что не укладывается в схему репликации ASA является ошибочным. Почему сотрудники разных филиалов не могут вносить изменения в один и тот же документ? Чем это отличается от возможности изменения документа на разных рабочих местах? Т.е. по вашему внесли мы документ на компьютере 1, и все не редактировать не удалить его с других компьютеров мы не можем?
Александр Гoлдун
А этого недостаточно? Какие нужны другие варианты? Такая технология позволяет, например, легко и безболезненно организовать одновременную правку в разных базах разных полей ОДНОЙ И ТОЙ ЖЕ записи. При построчной репликации измененных записей такое сделать проблематично.

Та же построчная репликация позволяет снизить траффик при частом обновлении одних и тех же строк за периоды между репликациями. И представляете, с полями одной и той же записи - ну никаких проблем. А моментальными снимками - при больших периодах между сеансами. Естественно, есть и свои недостатки, но...
gardenman
про двухфазное принятие - это в яблочко.Такая фигня с репликацией не прокатит.

Безотлагательное обновление, которое использует 2PC в MS SQL относится к репликации.
25 янв 06, 15:09    [2286611]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

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

Локшин Марк пишет:

> А, я понял. На ASA можно сделать все. То, что не укладывается в схему
> репликации ASA является ошибочным.

А я не понял иронии. Есть достойные альтернативные предложения? Готов
выслушать и ознакомиться - я не догматик в этом плане и не являюсь
сотрудником маркетингового отдела Sybase. Чудес не бывает, так же как и
не бывает волшебной кнопки, по нажатию которой сама собой реализуется
репликация чего угодно куда угодно. Дело не в схеме репликации ASA, а в
самой идеологии офф-лайновой репликации, когда физически невозможно
получить моментальную прямую связь с удаленной БД.

> Почему сотрудники разных филиалов не
> могут вносить изменения в один и тот же документ? Чем это отличается от
> возможности изменения документа на разных рабочих местах?

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

> Т.е. по вашему
> внесли мы документ на компьютере 1, и все не редактировать не удалить
> его с других компьютеров мы не можем?

Можем. Только надо четко понимать, как это организовать и к чему это
может привести. У меня, например, в некоторых документах допускается
одновременная правка в разных базах, но специфика рабочих мест и
доступов такая, что в разных базах правятся разные поля. Есть и другие
варианты - правка всего документа, но в разных статусах. Например в
одном филиале документ могут создать и править пока он имеет статус
черновика. После смены статуса в том месте с ним уже ничего сделать не
смогут, но он становится доступен для редактирования в другом офисе. И т.п.

> Та же построчная репликация позволяет снизить траффик при частом
> обновлении одних и тех же строк за периоды между репликациями.

Или увеличить траффик при незначительном изменении большого кол-ва
строк. А так же усложняет отслеживание элементарной ссылочной
целостности и упомянутой последовательности изменений.

> Естественно, есть и свои недостатки, но...

Ну, везде есть недостатки и достоинства. Из всего, что я видел и
анализировал, для решения задач с которыми я сталкиваюсь более всего
подходит ASA, причем с большим отрывом. В других условиях возможно
подойдет что-то более другое, но в плане поддержки репликации, особенно
offline, многими ASA признается лучшим выбором.

Posted via ActualForum NNTP Server 1.3

25 янв 06, 15:38    [2286784]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Локшин Марк
Та же построчная репликация позволяет снизить траффик при частом обновлении одних и тех же строк за периоды между репликациями. И представляете, с полями одной и той же записи - ну никаких проблем. А моментальными снимками - при больших периодах между сеансами. Естественно, есть и свои недостатки, но...

Есть у меня проекты, где одна и та же расчетная информация мутузиться сколько угодно раз, добавляется, изменяется, удаляется в пределах открытого расчетного периода в специально отведенных под это таблицах (кэшах). Если бы я ее постоянно реплицировал, то вместо репликации был бы сплошной спам. Однако все проще - как только период закрывается, данные фиксируются в таблицы фиксированного хранения информации, которые уже подвязаны на репликацию и все конечные изменения уходят наверх в консолидированную БД и по другим удаленным узлам, имеющим область видимости этой информации. Еще можно вспомнить фильтры WHERE на информацию, что позволяет помимо распределения информации по кодам подписчиков отсылать не все записи таблиц (например по флагу готовности).

Локшин Марк
Почему сотрудники разных филиалов не могут вносить изменения в один и тот же документ? Чем это отличается от возможности изменения документа на разных рабочих местах? Т.е. по вашему внесли мы документ на компьютере 1, и все не редактировать не удалить его с других компьютеров мы не можем?

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

Александр Гoлдун
Ну, везде есть недостатки и достоинства. Из всего, что я видел и
анализировал, для решения задач с которыми я сталкиваюсь более всего
подходит ASA, причем с большим отрывом. В других условиях возможно
подойдет что-то более другое, но в плане поддержки репликации, особенно
offline, многими ASA признается лучшим выбором.

Полностью подписываюсь. Правда сейчас насколько я читал, достаточно неплохо подтянули уровень механизма репликаций в Юконе, однако как мне показалось, по функциональным возможностям он все таки не дотягивает до уровня ASA, хотя в описаниях тоже выглядит неплохо и в дальнейшем я надеюсь будет возможность рассмотреть и сравнить достоинства и недостатки репликаций MSSQL2005 с репликациями ASA на живых проектах, а не только по описаниям.

P.S. И я тоже кстати навряд ли тяну на маркетингового представителя Sybase, как раз наверное наоборот, я в данном случае провожу антимаркетинговую политику, так как в представительствах Sybase признается исключительно ASE. Но против истины не попрешь - ASA действительно хороша и многое умеет :)
25 янв 06, 15:54    [2286910]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить