Каков наилучший подход для разделения базы данных с точки зрения обмена данными?

Question

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

Какие альтернативные подходы вы использовали для обмена данными между базами данных Oracle?

Обновление после пары ответов ...

Я думал не столько о репликации, сколько о доступе к "основным данным". Например, если у меня есть центральная база данных с курсами конвертации валют, и я хочу перенести курс в отдельную базу данных (приложение). Для такого небольшого набора данных предложение igor-db о материализованных представлениях по ссылкам на БД прекрасно работает. Однако, когда вы динамически выбираете данные из очень большого набора данных, возможность локального кэширования становится более сложной. Какие варианты вы бы выбрали в этих обстоятельствах. Я задавался вопросом об услуге XML, но tuinstoel (в комментарии к ответу le dorfier) ​​справедливо поставил под сомнение связанные с этим накладные расходы.

Сводка ответов ...

В целом я думаю, что igor-db наиболее близок, поэтому я принял этот ответ, но я подумал, что добавлю немного, чтобы выделить некоторые другие ответы.

Для моих целей, где я смотрю только на репликацию данных, похоже, что репликация Oracle BASIC (в отличие от ADVANCED) - это моя репликация. Использование материализованных журналов представлений на главном сайте и материализованных представлений на сайте снимков выглядит как отличный путь вперед.

Если это не вариант, возможно, когда объемы данных делают полную репликацию таблиц проблемой, тогда решение для обмена сообщениями кажется наиболее подходящим решением Oracle. Oracle Advanced Queuing кажется самым быстрым и простым способом настройки решения для обмена сообщениями.

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

Answer 1

Streams - это технология репликации Oracle. Вы можете использовать MV над ссылками на базу данных (таким образом, база данных «A» имеет материализованное представление данных из базы данных «B». Если «B» выключается, MV не может быть обновлена, но данные все еще находятся в «A») .

Пробег может зависеть от объемов БД, изменения объемов ...

Answer 2

Почему они должны быть отдельными базами данных?

Может быть проще иметь одну базу данных / экземпляр с несколькими схемами.

Поддержание одной базы данных (с соответствующими резервными базами данных и т. Д.) Будет проще, чем сохранение N.

Answer 3

Почему бы не использовать Advanced Queuing? Зачем катать свой собственный XML-сервис для перемещения сообщений (DML) между экземплярами Oracle - он уже там. Вы можете иметь распространение сообщений перемещения из одного экземпляра в другой, когда они оба вверх. Вы можете обрабатывать их по мере необходимости на серверах назначения. AQ действительно довольно прост в настройке и использовании.

Answer 4

ОП предоставил больше информации. Он утверждает, что набор данных очень большой. Ну, насколько велика велика? И как часто меняются основные таблицы?

С использованием журналов материализованного представления Oracle будет распространять только изменения, внесенные в основную таблицу. Полное обновление данных не требуется. Потоки Oracle также передают изменения только на другую сторону.

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

Служба XML не помогает вам, когда ее база данных недоступна, поэтому я не понимаю, почему это поможет? У Oracle есть много вариантов репликации, изучите их.

1010 * редактировать *

Я создал службы XML. Они обеспечивают взаимодействие между различными системами с понятным интерфейсом (контракт). Вы можете создать сервис XML в C # и использовать сервис с Java. Однако службы XML не являются быстрыми.

Answer 5

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

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

Answer 6

Какая непосредственность вам нужна и насколько двунаправлена? Если данные могут быть немного старше и могут быть извлечены из одного «основного источника», создайте серию простых сценариев ETL, запускаемых по расписанию, для передачи данных из базы данных «источника» в другие.

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