Шаблон для обновления ведомых баз данных SQL Server 2008 с главного устройства при минимальном сбое

Question

У нас есть веб-приложение ASP.NET, размещенное в веб-ферме многих экземпляров с использованием SQL Server 2008, в которой мы выполняем агрегацию и предварительную обработку данных из нескольких источников в формат, оптимизированный для быстрой обработки запросов конечного пользователя (создание -10 миллионов строк в некоторых таблицах). Агрегирование и оптимизация выполняются службой на внутреннем сервере, которую мы затем хотим распространить на несколько копий только для чтения, которые используются экземплярами веб-приложения для обеспечения максимальной масштабируемости.

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

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

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

Выполнение удаления и массовой вставки приведет к периодам без данных для пользовательских запросов.

Я действительно не хочу писать сложный кластерный подход, когда мы удаляем копии из кластера во время обновления - есть ли что-то в этом роде, что мы можем сделать без особых усилий, или есть лучшая альтернатива?

Answer 1

На самом деле в SQL Server 2005 (и 2008) встроена технология, предназначенная для решения подобных проблем. Service Broker (далее я буду называть SSB). Проблема в том, что у него очень крутая кривая обучения.

Я знаю, что MySpace обнародовал информацию об использовании SSB для управления своим парком SQL-серверов: MySpace использует SQL Server Service Broker для защиты целостности 1 петабайта данных . Я знаю еще несколько (крупных) сайтов, которые используют похожие шаблоны, но, к сожалению, они не стали общедоступными, поэтому я не могу ссылаться на названия. Я был лично связан с некоторыми проектами, связанными с этой технологией (я бывший член команды SQL Server).

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

Почему некоторые компании все же предпочитают SSB перед репликацией в задаче, которую вы описываете, потому что SSB гораздо лучше справляется с вопросами надежности и масштабируемости. Я знаю о проектах, которые обмениваются данными между 1500+ сайтами, далеко за пределами возможностей репликации. SSB также абстрагируется от физической топологии: вы можете перемещать базы данных, переименовывать машины, перестраивать серверы - все без изменения приложения. Поскольку поток данных происходит по логическим маршрутам , приложение может оперативно добавлять новые топологии. SSB также устойчив к длительным периодам отключения и простоям и способен возобновить поток данных после часов, дней и даже месяцев отключения. Высокая пропускная способность достигается за счет интеграции движка (SSB является частью самого движка SQL, а не набором приложений и процессов спутников, таких как репликация), что означает, что отставание от изменений может быть обработано в разумные сроки (я знаю сайты, которые проходят половину миллион транзакций в минуту). Приложения SSB обычно используют внутреннюю активацию для обработки поступающих данных. SSB также обладает некоторыми уникальными функциями, такими как встроенная балансировка нагрузки (по маршрутам) с семантикой липких сессий, поддержка корреляция без специфической для приложения корреляционной обработки , приоритет данных доставка, специальная поддержка зеркального отображения базы данных, аутентификация на основе сертификатов для междоменных операций, встроенные постоянные таймеры и многие другие.

Это не конкретный ответ «как переместить данные из таблицы T на сервере A на сервер B». Более универсальная технология о том, как «обмениваться данными между сервером A и сервером B».

Answer 2

Опция 1 : написать приложение для передачи данных с использованием транзакций на уровне строк. Это может занять больше времени, но не приведет к прерыванию работы сайта с использованием данных, поскольку строки находятся там до и после чтения, только с новыми данными. Эта обработка будет выполняться на отдельном сервере для минимизации нагрузки.

В SQL Server 2008 вы можете установить READ_COMMITTED_SNAPSHOT на ON, чтобы гарантировать, что обновляемая строка не вызывает блокировку.

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

Опция 2 : переместить данные (таблицы или всю базу данных) с сервера агрегации на сервер переднего плана. Автоматизируйте это, если это возможно. Затем переключите ваше веб-приложение, чтобы указать на новую базу данных или таблицы для будущих запросов. Это работает, но требует контроля над веб-приложением, которого у вас может не быть.

Вариант 3 : Если вы говорили об одной таблице (или это может работать со многими), то вы можете сделать это обмен представлением. Таким образом, вы пишете свой код для представления SQL, которое указывает на таблицу A. Вы работаете с таблицей B, и когда оно будет готово, вы обновляете представление так, чтобы оно указывало на таблицу B. Вы даже можете написать функцию, которая определяет активную таблицу и автоматизирует ее. вся своп вещь.

Опция 4 : Возможно, вы сможете использовать что-то вроде репликации на уровне байтов сервера. Это звучит страшно, хотя. Который в основном копирует сервер из точки А в точку Б точно до самого байта. В основном это используется в ситуациях DR, что звучит так, как будто это может быть ситуация типа DR / своего рода DRTA, но не совсем.

Вариант 5 : Сдайся и научись продавать страховку. :)

Answer 3

Мне никогда раньше не приходилось сталкиваться с этим сценарием, но я нашел возможное решение для этого. По сути, это потребует изменения в вашей основной структуре базы данных. Вместо хранения данных вы должны вести учет изменений этих данных. Таким образом, если запись добавлена, вы сохраняете «Таблицу X, вставили новую запись со следующими значениями: ...» С изменениями просто сохраните таблицу, поле и измененное значение. При удалении просто сохраните, какая запись удалена. Каждая модификация будет храниться с отметкой времени.

Ваши клиентские системы будут хранить свои локальные копии базы данных и будут регулярно запрашивать все модификации базы данных после определенной даты / времени. Затем вы выполните эти изменения в локальной базе данных, и они снова будут обновлены.

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

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

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