Синхронизация однонаправленной базы данных

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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