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

Question

У нас есть веб-приложение ASP.NET, размещенное во множестве веб-ферм с использованием SQL Server 2008, в котором мы выполняем агрегацию и предварительную обработку данных из нескольких источников в формат, оптимизированный для быстрой обработки запросов конечного пользователя (создание 5 -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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

Вариант 5 . Откажитесь и научитесь продавать страховку. :)