Ann:Познакомьтесь с нашей технологией зеркалирования данных

Добрый день!

Предлагаю Всем познакомится с материалами на нашем ресурсе www.mirrordatabase.com , посвященном средствам зеркалирования данных для серверов ряда Interbase/Firebird/Yaffil. Главная цель - повышение производительности информационных систем. Клиентская часть этих средств - это набор компонент для среды Delphi, чем и обусловлена публикация сего анонса в данном разделе форума.

Основная цель анонса - это получить какие-либо Ваши отзывы, о востребованности данного направления. Нам будут интересны любые замечания, которые помогут нам разобраться со следующим ключевыми, на сегодня, вопросами:
1.Насколько с технической стороны интересен подход, реализованный в данных средствах?
2.Поможет ли они решать проблемы, с которыми Вы, возможно, сталкивались в своей практике?
3.Существует ли рынок для будущего распространения? Или все так плохо, что лучше дальше не продолжать исследований и не тратить сил. ;)

Отдельно хотел бы обратиться к разработчикам компонент для работы с базами данных. Господа, если Вы сочтете, что MDT имеет потенциал для успешного широкого применения, то хотел бы пригласить Вас к интересному сотрудничеству, основанному на совместной поддержке и распространении MDT – технологии.

artemana

1.Насколько с технической стороны интересен подход, реализованный в данных средствах?

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

Posted via ActualForum NNTP Server 1.4

репликация уже не рулит??

artemana

1.Насколько с технической стороны интересен подход, реализованный в данных средствах? 2.Поможет ли они решать проблемы, с которыми Вы, возможно, сталкивались в своей практике? 3.Существует ли рынок для будущего распространения? Или все так плохо, что лучше дальше не продолжать исследований и не тратить сил. ;)

1. Слишком сложный подход. Для реализации описанного на сайте функционала достаточно средств репликации СУБД (?).
2. нет. В основном задачи синхронизации требовались в территориально-распределенных системах и между различными серверами СУБД (FB < -> Oracle, FB <-> MS SQL, FB <-> FB и т.п.).
3. Возможно кому-то понадобится.

имхо.

artemana,

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

А всё же как решаются проблемы конфликтов модификаций?
Вот такая банальная ситуация например. Из двух филиалах модифицируют одну и ту же запись. Временно связь с основным сервером рвется или плохая так,
что синхронизация сразу же после изменений не проводится и потом как разбирать? Или если транзакц. изолированы, то синхрон. после завершения транзакций. Какого клиента предпочесть?
Если всех по приоритетам и прочим рангам, то уже не синхронизация, а возвращение к репликации.

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

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

...

P.S. Пробовали для организации с одним филиалом в другом городе. Впечатление, что более, чем репликация не получается, то есть для каждого случая своё программирование. То есть компонент сколько-нибудь универсальный какой тогда может быть?

AlexandrPlus

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

Это "чуть больше чем репликация" обычно "административными мерами"
зовётся. С какого перепою два филиала полезли в одну запись?

Posted via ActualForum NNTP Server 1.4

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

Вот это было бы востребовано, репликация по бизнес правилам + отсутсвие Инета не должно быть проблемой, в конце концов туды вечерняя лошадь ходит, можно ямщику флешку дать он доставит:)

В этом топике просьба не флеймить (он не для
того создан) и не заниматься [анти]рекламой.

Dimitry Sibiryakov

AlexandrPlus Вот такая банальная ситуация например. Из двух филиалах модифицируют одну и ту же запись. Это "чуть больше чем репликация" обычно "административными мерами" зовётся. С какого перепою два филиала полезли в одну запись?

Речь идет о КОМПОНЕНТАХ, что подразумевает достаточно общий вид решения задачи, а не "административные заплатки".

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

Вообще авторам надо бы назвать НЕ ЗЕРКАЛО, так как в сознании масс ЗЕРКАЛО уже прочно ассоциируется с RAID. Здесь же не "зеркало", а равноправные и всегда активные БД (у которых должны стоять зеркала на RAID).

Dimitry Sibiryakov

artemana 1.Насколько с технической стороны интересен подход, реализованный в данных средствах? Довольно странный подход, надо сказать.

Да, обычным этот подход назвать нельзя! А уж кто какие прилагательные применит для его описания - право каждого.

Dimitry Sibiryakov

Раз уж сделали репликацию, то зачем ещё модифицированные компоненты доступа?

Репликация - это очень широкий термин, обозначающий перемещение данных между различными источниками. В этом плане к MDT также можно было бы «лепить» этот термин. С таким же успехом его можно использовать в описании многих вещей например - TClientDataSet. Вместе с тем, часто в термин «Репликация» вкладывают конкретное представление. Например, программу репликации (уровня СУБД, или внешнюю) которая обеспечивает отложенный однонаправленный или двунаправленный обмен, между двумя или более базами данных. У каждой из этих баз есть свои клиенты, которые работают с ними «не догадываясь» о существовании соседей. Цель – та же что у MDT. Сложность настройки репликации различна. Правила обмена могут учитывать прикладную логику ИС или игнорировать ее – все это пока не суть важно. Ключевым моментом является то, что реализуется отложенный обмен и самодостаточность каждой из баз.
Так вот, MDT - не подходит под это представление. Архитектура MDT подразумевает возможность обращения клиента как к копиям базы так и к центральной СУБД. Причем в случаи обращения к копии, клиент сам себе выполняет ее синхронизацию, обеспечивая 100% актуальность данных, делая для прикладного слоя неотличимым работу в распределенной сети от работы в режиме одной базы. Это достигается, в том числе, за счет того, что все пишущие операция выполняются на центральном сервере. Вот ключевое отличие, которое существуют между MDT и одним из описанных только что представлений о репликации. Именно этим отличием вызвано модификация компонент, нет другого слоя, где это мы могли бы это реализовать. Разработчики серверов, могли бы реализовать такое решение на слой ниже, - на уровне сервера. Кстати сказать, так наверно и делается в кластерных системах (Oracle RAC). Другое дело то, что насколько такое отличие важно. Здесь каждый прикидывает на себя. Мы собираем мнения.
Пока приведу один пример. Десятки раз встречал здесь и в других местах, обсуждения с одобрением следующего регламента эксплуатация ИС. Днем вводим данные, на ночь запускаем сложный и длинный расчет, который к утру формирует некие доп. данные, например готовые агрегаты, облегчающие дальнейшую работу. Основная цель понятна - не загружать сервер днем, освободив его максимально для работы операторов (формирование первички). Если представить что большую часть нагрузки такого расчета занимает SQL чтение, то MDT является идеальным средствам, позволяющим запускать такой расчет в любое время суток. Аналогичное по эффективности решение такой задачи на любом репликаторе, ИМХО, реализовать сложнее.