Односторонняя синхронизация базы данных

Question

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

Исходные данные в бэкэнд-системе сильно нормализованы, с десятками таблиц и ограничениями внешнего ключа. Это хорошо разработанная система СУБД OLTP. Многие из рассматриваемых таблиц содержат миллионы строк. Необходимо регулярно передавать эти данные в другие базы данных. Так часто, как это возможно; задержка может быть допущена. Прежде всего, максимальное время безотказной работы как внутренней, так и удаленной баз данных является обязательным.

Я использую SQL Server и знаком с отслеживанием изменений, изменением строк, триггерами и так далее. Я знаю, что Microsoft активно использует репликацию, SyncFx и SSIS для этих сценариев. Однако между техническими документами поставщиков и обзорами, рекомендующими технологии, и фактической реализацией, развертыванием и обслуживанием решения существует существенная разница. В мире SQL Server репликация часто рассматривается как решение «под ключ», но я пытаюсь найти альтернативные решения. (Есть некоторые опасения, что репликацию сложно администрировать, что затрудняет изменение схемы, и в случае, когда когда-либо потребуется повторная инициализация, для критически важных систем будет большое время простоя.)

Есть много ошибок. Из-за сложных взаимосвязей внешних ключей между большим количеством таблиц определение порядка выполнения захвата или применения обновлений не является тривиальным. Из-за уникальных индексов две строки могут быть заблокированы таким образом, что обновление по одной строке даже не будет работать (необходимо выполнить промежуточные обновления для каждой строки перед окончательным обновлением). Это не обязательно ограничители показа, поскольку уникальные индексы часто можно изменить на обычные, а внешние ключи можно отключить (хотя отключение внешних ключей крайне нежелательно). Часто вы услышите, что «просто» используете отслеживание изменений SQL 2008 и SSIS или SyncFx. Такие ответы на самом деле не соответствуют практическим трудностям. (И, конечно же, клиентам действительно трудно понять, как копирование данных может быть настолько сложным, что еще больше усугубляет сложную ситуацию!)

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

Answer 1

Лучше спросить на serverfault.com (я не могу оставлять комментарии, скрипты не работают в SO, поэтому я должен опубликовать полный ответ)

Обновление: (перешел на Safari, скрипты снова работают, могу выложить правильно)

Серебряной пули нет. Для простоты использования и развертывания «одним поворотом ключа» ничто не может сравниться с репликацией. Это единственное решение, которое охватывает глубоко обнаружение и разрешение конфликтов, имеет поддержку для внесения изменений в схему и поставляется с полным набором инструментов для его настройки и мониторинга. В течение многих лет, до того, как эта «повестка дня» перешла к рассмотрению .Net, эта тема была детищем MS в области синхронизации данных. Репликация имеет две основные проблемы, на мой взгляд:

• Технология, используемая для продвижения изменений, примитивна, медленна и ненадежна. Для инициализации реплик требуются общие файловые ресурсы, и от T-SQL зависит фактическая репликация данных, что приводит к всевозможным проблемам масштабируемости: потоки репликации используют рабочие потоки сервера и тот факт, что они взаимодействуют с произвольными таблицами, а запросы приложений приводят к блокировке. и тупики. Самые большие развертывания, о которых я слышал, - это 400-500 сайтов, которые выполняются сверхчеловеческими MVP и ведущими консультантами. На этом останавливается множество проектов, которые запускают на 1500 сайтах (намного больше, чем крупнейшие развернутые проекты репликации). Мне любопытно услышать, если я ошибаюсь, и вы знаете о решении для репликации SQL Server, развернутом с более чем 500 сайтами.
• Метафора репликации слишком ориентирована на данные. Он не учитывает требования распределенных приложений: необходимость версий и формализованных контрактов, автономность данных « fiefdoms », слабая связь с доступностью и безопасностью. В результате решение на основе репликации решает насущную необходимость «сделать данные доступными там», но не решает истинную проблему «мое приложение должно общаться с вашим приложением».

На другом конце спектра вы найдете решения, которые действительно решают проблему взаимодействия приложений, например услуги, основанные на обмене сообщениями в очереди. Но либо мучительно медлительны, либо пронизаны проблемами, связанными с разделением механизма связи (веб-сервисы и / или msmq) и хранением данных (транзакции DTC между comm и db, нет общей истории высокой доступности, нет общей истории восстановления и т. Д. И т. Д.). Решения, которые невероятно быстрые и полностью интегрированы с БД, существуют в стеке MS , но никто не знает, как их использовать. Где-то между ними и репликацией вы найдете различные промежуточные решения, такие как OCS / Synch framework и специализированные решения на основе SSIS. Никто не предложит простоту настройки и мониторинга репликации, но они могут масштабироваться и работать лучше.

Я принимал участие в нескольких проектах, которые требовали «синхронизации данных» в очень крупном масштабе (+1200 сайтов, +1600 сайтов), и мое решение состояло в том, чтобы превратить проблему в проблему «связи между приложениями». Как только мышление меняется на это, и поток данных больше не рассматривается как «запись с ключом X таблицы Y», а как «сообщение, сообщающее о покупке товара X покупателем Y», решение становится более простым для понимания и применения. Вы больше не думаете с точки зрения «вставки записей в порядке X-Y-Z, чтобы отношения FK не разрывались», а с точки зрения «процесса покупки, как описано в сообщении XYZ».

На мой взгляд, репликация и ее производные (то есть отслеживание данных и доставка грамм данных) - это решения, основанные на технологиях 80-х и представлении данных / приложений. Устаревшие динозавры (и ни в коем случае не превращающиеся в птиц).

Я знаю, что это даже не начинает решать все ваши (очень законные) проблемы, но выписывание всего, что я скажу / rant / rable по этой теме, наполнило бы тома в мягкой обложке ...