Не хочется повторяться. Я уже высказался. Сначала спрашивал, потом экспериментировал. Можно посмотреть (в верхнем регистре наиболее информативные постинги):
Здесь1, здесь2, здесь3, здесь4, здесь5, здесь6 , здесь7, здесь8, ЗДЕСЬ9, здесь10, ЗДЕСЬ11, здесь11, ЗДЕСЬ12, здесь13, здесь14, здесь15, ЗДЕСЬ16 (два слова о быстродействии), здесь17, повтор кашистом Maxim UM теста на быстродействие, здесь18, здесь19, здесь20, здесь21, ЗДЕСЬ22, ЗДЕСЬ23, здесь23, здесь24, здесь25, здесь26, здесь26, здесь27, http://]здесь28 (важно - отличие репликации от распределенных БД), ЗДЕСЬ29 (имхо, наиболее объективная оценка быстродействия), здесь30
Другой тред:
Здесь31, здесь32, здесь33, здесь34, здесь35, здесь36, ЗДЕСЬ36

Прошу извинить за техническую ошбику со ссылкой:
здесь28 (важно - отличие репликации от распределенных БД)

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

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

Честно говоря, для решения тех задач, которые стоят передо мной, полностью меня устраивающих инструментариев просто нет. Приходится выбирать из совсем неподходящих и плохо подходящих. Сейчас я рассматриваю два варианта - либо Oracle, либо Yukon. Cache из списка претендентов исключен.

2 MX-ALEX. Можно чуточку подробнее? Связь между серверами постояная? Что происходит, если какое-либо соединение на время внезапно прервется?

Имеется ли какой-то центр репликации и как оно организован?

Лев Кассиль GaryaДобиться этого можно только если в качестве идентификаторов записей используются GUID (а не целочисленные идентификаторы). Можно небольшой ликбез в другой ветке или ссылку на ветку, где это обсуждалось?
Я знаю лишь, что GUID позволяет охватить очень большое чисто экземпляров исключая возможность совпадения GUID для двух разных сущностей. А почему целочисленныыми идентификаторами нельзя ограничиться, напр. 64-битными? Тоже довольно огромное число экземпляров можно получить.Да, можно получить большое число экземпляров. Но, во-первых, в Cache родной целочисленный идентификатор объектов НЕ 64-хбитный, так что и для этого случая его переопределения не избежать. Во-вторых, во избежание генерации одинаковых идентификаторов на разных площадках необходимо самим придумывать правила, по которым эти идентификаторы генерятся так, чтобы нигде и никаким образом не смогли сгенериться одинаковые идентификаторы. Например, это можно сделать разбиением на диапазоны, в которых на каждой площадке работает автоприращение целочисленного идентификатора. Но, во-первых, зачем изобретать велосипед, когда уже существует программно-аппаратный способ генерации глобально-уникальных идентификаторов, реализованный в API для GUID - с учетом уникальных MAC-адресов сетевых карт? Во-вторых, я пытаюсь найти ОБЩЕЕ решение для задач подобного класса, а не только для моего частного случая. Общность решения поможет избежать проблем в будущем, если окажется, что репликация, предполагаемая в каком-то месте однонаправленной вдруг должна превратиться в двунаправленную, а при распределении диапазонов генерации ключей с автоприращением это не было учтено.
Одним словом, GUID - это удобное универсальное решение.

2 MX-ALEX. Очень трудно с наскока разобраться во всех ваших нюансах, но у меня такое ощущение (на интуитивном уровне), что проблем у вас много. Одна из причин - отсутствие центра управления информационным обменом (всё взаимодействует со всем). Это очень неудачная схема по множеству причин. Но прежде всего давайте определимся, о чем идет речь - о репликации или о распределенных базах данных. Это принципиально разные вещи. Cache предоставляет достаточно удобные средства работы с распределенными базами данных, но не предоставляет средств репликации (хотя другие СУБД предоставляют и то, и другое). В распределенных базах данных информация физически хранится на многих серверах, но только в одном экземпляре. Сервера просто обращаются в случае необходимости за этой информацией к другому серверу. Это - НЕ репликация. Репликация подразумевает копирование инофрмации на несколько разных серверов и приведение их содержимого к синхронному состоянию. Локальные рабочие станции, взаимодействующие ТОЛЬКО с собственным сервером для получения ЛЮБОЙ информации получают в этом случае большую конфету в виде высокой скорости работы, потому что они работают со своим сервером в 100-мгабитной, а может быть и гигабитной сети. Моментально работает выборка и запись. А механизмы репликации, используя специальный координирующий центр, отслеживающий изменения на всех серверах, задействованных в репликации, передают нужную информацию в нужном направлении постоянно или эпизодически для того, чтобы синхронизировать содержимое серверов между собой.

Небольшой экскурс в механизмы репликации MS SQL Server, чтобы можно было представить, о чем идет речь. для управления репликацией имеет сервер, специально заточенный для подобных задач - Distributor. Именно он управляет репликацией. Его можно сравнить с почтовым отделением. Простые сервера, участвующие в репликации, представляются либо в роли Publish-серверов, которые сообщают на "почту" (то есть, серверу-дистрибутору) однократно - структуру публикуемой информации, схему и выбранный метод репликации, а после оформления публикации многократно - сами реплицируемые данные. Сервера-подписчики взаимодействуют тоже с Distributor-ом (почтовым отделением), если хотят получить доступ к опубликованной другими серверами информации. Получается, что через дистрибутор можно работать, организовывая совершенно разные схемы взаимодействия:
1. Множество серверов, публикующих информацию, могут передать ее одному серверу-подписчику (очень распространенная схема для холдиноговых структур с центральной компанией, получающей сводные отчеты от дочерних компаний).
2. Множество серверов-подписчиков может получать информацию от одного сервера публикации (когда необходимо в едином центре ввести информацию и распространить ее на множество узлов).
3. Множество серверов публикации может взаимодействовать со множеством серверов-подписчиков (смешанная схема).
Это только при наличии одного сервера-дистрибутора. А их может быть множество. Можно задействовать схемы вида "снежинка", а не только "звезда".
MS SQL Server предоставляет на выбор четыре вида репликации:
1. Snapshot - репликация (репликация снимком)
2. Репликация транзакций
3. Репликация непосредственно обновляемых подписчиков
4. Репликация слиянием
Одни методы требуют наличия постоянной связи (3 - обязательно, 2 - желательно), другие не требуют (1 и 4). Метод 3 - специфический, ориентирован на распределенные транзакции, охватывающие множество серверов - гарантирует выполнение операций записи одновременно на множестве серверов, либо невыполнение подобных операций ни на одном в случае возникновения где-либо проблем, использует механизмы двуступенчатой фиксации транзакций (на межсерверном уровне и на уровне каждого отдельного сервера). Одни методы позволяют накладывать горизонтальные и вертикальные фильтры на источники информации (1, 2, 3), другие не позволяют (4). Одни методы позволяют передавать информацию только в одну сторону - от сервера публикации к серверу-подписчику (1 и 2), другие позволяют осуществлять двусторонний обмен информацией (3 и 4). Одни используются для однократного копирования больших объемов информации (1), другие позволяют вполседствии передавать только порции изменившейся информациии (2, 3 и 4).
И, наконец, многие методы репликации могут настраивать участвующие в репликации сервера на Push- и Pull- репликацию. То есть, является ли данный сервер инициатором информационного обмена между серверами, либо он просто ждет когда информация сама на него свалится.
Distributor совершенно точно знает, что, откуда и когда от какого сервера какому серверу уже было передано, что еще не было передано, хотя уже от сервера публикации десять раз поступили новые порции информации. Он не станет без надобности передавать одну и ту же информацию на тот сервер, на который уже ее передал. И сервер, целый месяц простоявший без связи, может быть уверен, что после возобновления связи сможет с помощью Distributor-а синхронизироваться с остальной сотней серверов, хотя они все это время синхронизировались между собой мелкими порциями информации и "ушли далеко вперед". Вот это и есть - та самая РЕПЛИКАЦИЯ , которая в Cache отсутствует, несмотря на всю ее " пост реляционность".

Теперь два слова по поводу того, как с решением подобных задач все-таки можно выкрутиться в Cache. Я долго ломал над этим голову, и кое-что придумал.
1. Простейшая односторонняя репликация (аналог Snapshot-репликации) между парой серверов может быть сделана с помощью утилиты от MS SQL Server, именуемой MS DTS (проверено на практике). Используя интерфейс ODBC, можно с помощью мастера настроить передачу информации с одного сервера Cache на другой. Можно даже создать JOB, который будет выполнять подобную синхронизацию по заданному расписанию.
2. Однако, при взаимодеействии большого количества серверов (более двух) и передаче информации малыми порциями обязательно необходим некий координирующий центр репликации. Его роль в усеченном виде может играть MS BizTalk Server, взаимодействующий со множеством Cache-серверов, например, через ODBC. Возможно, придется самостоятельно создать служебные специальные поля в реплицируемых таблицах для маркировки реплицированных записей, борьбы с конфликтами репликации и т.п. Но все-таки с BizTalk Server эта задача упрощается. BizTalk может произвести также некоторые преобразования данных при передаче их с одного сервера на другой. Может самостоятельно выявить конфликты репликации и разрулить их по нужному алгоритму (алгоритм реализуется руками).

MX-ALEXИменно так наша самопальная система и работает..Ну так может расскажете подробнее, как именно? Особенно меня интересует, что происходит, если на одном сервере изменили содержиоме записи одним способом, например, присвоили некоторому полю "Значение1", а на другом сервере присвоили этому же самому полю этой же самой записи "Значение2", а потом появилась связь между серверами, которой только что не было и запустилась репликация. Как разруливается этот конфликт репликации?

А можно еще подробнее? :)
Какие механизмы задействованы для организации репликации? Что сделано руками, что использовано из стандартного функционала? Несколько слов о принципах организации обмена. Что откуда и куда передается? Однонаправленная репликация или двунаправленная? Имеется ли единцы координирующий центр управления репликацией? Если да, то в двух словах что он из себя представляет? Если у вас хотя бы в одном месте реализована двусторонняя репликация, то как вы выкручивыетесь с целочисленными идентификаторами записей с автоприращением? Или у вас одна и та же запись на разных серверах может иметь разные идентификаторы? Или вы каким-то образом изменили стандартные механизмы присвоения новых идентификаторов записей? Насчет конфликтов репликации - это УЖЕ СДЕЛАНО, или вы описали, как МОЖНО СДЕЛАТЬ? Если уже сделано, то прерывается ли у вас репликация в случае конфликта? Если не прерывается, то передаются все записи кроме конфликтых? Как вы при этом избегаете возможные нарушения логической целостности (например, передались записи detail, ссылающиеся на master, а при попытке передачи записи master возник конфликт репликации). Используете ли вы вспомогательные поля для маркировки источников репликации? Если нет, то каким образом вы определяете источники при репликации? Если понадобится новый сервер подключить к вашей схеме репликации, то какими в двух словах будут ваши действия? Каким образом вы сделаете стартовую базу данных при подготовке ее к репликации? При репликации у вас передаются только изменившиеся записи? Если да, то как это организовано? Если до сеанса репликации три раза изменить одну и ту же запись, то передается только ее последнее состояние? Каким образом, в двух словах, реплицируется удаление записи? Если вы в самой записи храните первоисточник, то как вы задаете служебную информацию для удаленных записей - ведь если запись уже удалена, то вместе со служебными полями?

2 MX-ALEX. Спасибо за Ваши ответы и за Ваше терпение. :)
авторКаким образом вы сделаете стартовую базу данных при подготовке ее к репликации?
--??У вас содержимое на всех серверах совершенно одинаковое или имеются расхождения? Если совершенно одинаковое, то как вы различаете места формирования информации? Если различается, то как вы в случае необходимости вводите в действие новый сервер? Ведь на сервер необходимо изначально выложить базу данных с какой-то бизнес-логикой, хотя бы с бизнес-логикой той же репликации. У вас есть какая-то шаблонная база данных, в которой уже реализованы основные алгоритмы работы, определены базовые структуры данных и т.п., и в снимаете копию с нее копию? Или делаете базу данных с нуля? Если снимаете копию с шаблонной базы данных, то каким образом вы это делаете?

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

Спасибо за ответ.