Архитектурный вопрос одностороннего хранения и прямой репликации БД - PullRequest
Новая
       9

Архитектурный вопрос одностороннего хранения и прямой репликации БД

0 голосов
/ 15 января 2009

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

Каждая локальная установка этой системы должна реплицировать свои записи на один центральный сервер. Этот сервер не доступен напрямую пользователям установленного приложения базы данных, и Интернет является единственным путем к нему. Центральная база данных используется только для отчетов, поэтому репликация должна осуществляться только в одном направлении на центральный сервер.

Основная задача - как можно быстрее доставить записи в центральную базу данных, чтобы получить снимок «в реальном времени».

Вот что я получил до сих пор:

  1. Использование веб-сервера в Интернете (служба SOAP) для загрузки сжатых / зашифрованных файлов (данные XML). «Центральный» db-сервер опрашивает веб-сервер для регулярного сбора и импорта данных.

  2. Локальные системы БД не удаляют записи, но помечают их как удаленные.

  3. Каждая таблица в базе данных имеет первичный ключ, использующий GUID-подобный суррогатный ключ (то есть нет полей auto-inc) для предотвращения нарушений ключа в центральной базе данных.

  4. Я сделал скидку, используя клиентский сервер базы данных для запуска процесса извлечения и загрузки, так как будет очень мало ИТ-поддержки для этой системы на сайтах клиентов, поэтому в случае неудачной загрузки (из-за проблем локального брандмауэра / прокси-сервера) ) тогда я хочу, чтобы пользователь знал как можно скорее чтобы они могли его отсортировать.

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

Бит, с которым я борюсь, - это структура базы данных, позволяющая эффективно (и точно) извлекать недавно измененные записи. Также это будет происходить во время работы пользователей, то есть нужно быть осторожным с тем, чтобы у пользователя была открыта запись для редактирования во время извлечения, и она должна выполняться «в фоновом режиме», чтобы не слишком прерывать пользователя.

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

Извиняюсь за длинный пост, но я ценю любой опыт разработки этого решения.

ТИА,

Stuart

1 Ответ

1 голос
/ 15 января 2009

Возможно, вы захотите взглянуть на то, как Slony для PostgreSQL делает это.

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

Конечно, есть несколько деталей, которые могут усложнить ситуацию в зависимости от вашей базы данных. оригинальный проектный документ Slony хорошо освещает проблемы и причины, по которым он делает то, что делает. Даже если вы не используете PostgreSQL, его, вероятно, стоит прочитать.

...