Как настроить новую базу данных SQL Server для возможной репликации в будущем? - PullRequest
6 голосов
/ 08 февраля 2010

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

Не использовав репликацию в прошлом, мне интересно, есть ли что-то, что мне нужно учитывать при проектировании схемы?

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

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

Буду также признателен за любые другие советы по этому вопросу, включая полезные советы по внедрению репликации.

Ответы [ 3 ]

3 голосов
/ 08 февраля 2010

Хотя в каждой строке должен быть столбец rowguid, вы не обязаны использовать Guid для своего первичного ключа. В действительности вам даже не требуется, чтобы имел первичный ключ (хотя вы будете забиты камнями до смерти за то, что не смогли его создать). Даже если вы определите свой первичный ключ как guid, не указав его в столбце rowguid, службы репликации создадут для вас дополнительный столбец. Вы определенно можете сделать это, и это неплохая идея, но это ни в коем случае не необходимо и не особенно выгодно.

Вот несколько советов:

  1. Сохраняйте размеры таблицы (или, скорее, строки ) небольшими; если вы не используете репликацию на уровне столбцов, вы будете загружать / выгружать все содержимое строки, даже если изменяется только один столбец. Кроме того, таблицы меньшего размера делают разрешение конфликтов более простым и менее частым.
  2. Не используйте первичные ключи с последовательным или детерминированным алгоритмом. Сюда входят столбцы идентификаторов . Да, службы репликации будут обрабатывать столбцы идентификаторов и выделять ключевые распределения самостоятельно, но это головная боль, с которой вы не хотите иметь дело. Уже одно это отличный аргумент в пользу использования Guid для вашего первичного ключа.
  3. Не позволяйте вашим приложениям выполнять ненужные обновления. Это, очевидно, плохая идея для начала, но эта проблема значительно ухудшается в сценариях репликации, как с точки зрения использования полосы пропускания, так и с точки зрения разрешения конфликтов.
1 голос
/ 09 февраля 2010

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

Проблема с репликацией, особенно с репликацией слиянием, заключается в том, что при записи записи умножается . Допустим, у вас есть система, которая обрабатывает загрузку 100 запросов (90 операций чтения и 10 операций записи) в секунду. Вы хотите масштабировать, и вы выбираете репликацию. Теперь у вас есть 2 системы, каждая из которых обрабатывает 50 запросов, 45 операций чтения и 5 операций записи каждая . Теперь эти записи должны быть реплицированы, поэтому фактическое количество записей составляет не 5 + 5, а 5 + 5 (оригинальные записи), а затем еще 5 + 5 (запись реплики), так что у вас есть 90 операций чтения и 20 операций записи. Таким образом, хотя нагрузка на каждую систему была снижена, соотношение операций записи и чтения увеличилось. Это не только меняет шаблоны ввода-вывода, но, что наиболее важно, меняет модель параллелизма нагрузки. Добавьте третью систему, и у вас будет 90 операций чтения и 30 операций записи и так далее, и так далее. Вскоре у вас будет больше записей, чем операций чтения, и задержка обновления репликации в сочетании с проблемами параллелизма и конфликтами слияний приведут к сбою в вашем проекте. Суть в том, что «скоро» гораздо раньше, чем вы ожидаете. Достаточно скоро, чтобы оправдать взор на увеличение масштаба, так как вы в любом случае говорите о масштабировании из 6-8 пиров в лучшем случае, а увеличение емкости в 6-8 раз при увеличении будет быстрее, намного проще и возможно даже дешевле начать с.

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

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

Реальная альтернатива - разбиение (т.е. разбиение). Запросы направляются в приложение на соответствующий раздел и попадают на сервер, содержащий соответствующие данные. Изменения в одном разделе, которые необходимо отразить в другом разделе, отправляются с помощью асинхронных (обычно основанных на обмене сообщениями) средств. Данные могут быть объединены только внутри раздела. Для более подробного обсуждения того, о чем я говорю, прочитайте как это делает MySpace . Излишне говорить, что такая стратегия оказывает большое влияние на дизайн приложения и не может быть просто вставлена ​​после v1.

1 голос
/ 08 февраля 2010

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

Вот короткая статья об использовании GUID в SQL Server

...