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

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

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

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

Существует много глюков. Из-за сложных отношений внешнего ключа среди больших количеств таблиц, определяя, что порядок выполнить получения или применить обновления не тривиально. Из-за уникальных индексов, две строки могли бы взаимно блокироваться таким способом, которым обновление row-at-a-time даже не будет работать (должен выполнить промежуточные обновления каждой строки перед заключительным обновлением). Это не обязательно выставочные стопоры, поскольку уникальные индексы могут часто изменяться на регулярные индексы, и внешние ключи могут быть отключены (хотя отключение внешних ключей чрезвычайно нежелательно). Часто, Вы услышите, "просто" использовать отслеживание изменений SQL 2008 и SSIS или SyncFx. Эти виды ответов действительно не отдают должное практическим трудностям. (И конечно, клиентам действительно нелегко переносить их головы по тому, как копирование данных могло быть настолько трудным, делая трудную ситуацию всем худшим!)

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

6
задан MarredCheese 10 September 2019 в 17:24
поделиться

1 ответ

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

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

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

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

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

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

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

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

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

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

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

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

7
ответ дан 17 December 2019 в 00:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: