Как настроить новую базу данных SQL Server для обеспечения возможной репликации в будущем?
Я создаю систему, которая имеет потенциал для требования поддержки 500 + параллельные пользователи, каждое создание десятки запросов (выбирает, вставляет И обновляет), каждую минуту. На основе этих требований и таблиц со многими миллионами строк я подозреваю, что будет потребность использовать репликацию баз данных в будущем для сокращения части загрузки запросов.
Не используя репликацию в прошлом, я задаюсь вопросом, существует ли что-нибудь, которое я должен рассмотреть в дизайне схемы?
Например, мне когда-то сказали, что необходимо использовать GUID для первичных ключей для включения репликации. Действительно ли это верно?
Что особые условия или лучшие практики для проектирования баз данных там для базы данных, которая будет копироваться?
Из-за ограничений времени на проект я не хочу тратить впустую любое время путем реализации репликации, когда это не может быть необходимо. (У меня есть достаточно определенных проблем для преодоления в данный момент, не волнуясь о необходимости решить возможные.) Однако я не хочу должным быть вносить потенциально преодолимые изменения схемы, когда/если репликация требуется в будущем.
Любой другой совет относительно этого предмета, включая хорошие места для приобретения знаний о реализации репликации, также ценился бы.
3 ответа
Хотя каждая строка должна иметь столбец rowguid , вы не обязаны использовать Guid для основного ключ. На самом деле от вас даже не требуется иметь первичный ключ (хотя вы будете забиты камнями до смерти за то, что не смогли его создать). Даже если вы определите свой первичный ключ как guid, если вы не сделаете его столбцом rowguid , службы репликации создадут для вас дополнительный столбец. Вы определенно можете сделать это, и это неплохая идея, но ни в коем случае не является необходимой и не особенно выгодной.
Вот несколько советов:
- Сохраняйте размеры таблицы (или, скорее, строки ) небольшими; если вы не используете репликацию на уровне столбца, вы будете загружать / выгружать все содержимое строки, даже если изменяется только один столбец. Кроме того, меньшие таблицы делают разрешение конфликтов проще и реже.
- Не используйте последовательные или детерминированные первичные ключи на основе алгоритмов. Сюда входят столбцы идентификаторов . Да, службы репликации будут обрабатывать столбцы идентификаторов и выделять ключи самостоятельно, но это головная боль, с которой вы не хотите иметь дело. Уже одно это является отличным аргументом в пользу использования Guid для вашего первичного ключа.
- Не позволяйте вашим приложениям выполнять ненужные обновления. Очевидно, это плохая идея для начала, но эта проблема экспоненциально усугубляется в сценариях репликации как с точки зрения использования полосы пропускания, так и с точки зрения разрешения конфликтов.
Возможно, вы захотите использовать идентификаторы GUID для первичных ключей - в реплицируемой системе строки должны быть уникальными во всей топологии, и PK GUID - один из способов достижения этого. .
Вот небольшая статья об использовании GUID в SQL Server
Я бы сказал, что ваш реальный вопрос не в том, как обрабатывать репликацию, а в том, как управлять масштабированием или, по крайней мере, горизонтально для удобства запросов. И хотя есть разные ответы на эту загадку, один ответ будет очевиден: , а не с использованием репликации.
Проблема с репликацией, особенно с репликацией слиянием, заключается в том, что количество записей увеличивается при репликации. Допустим, у вас есть система, которая обрабатывает нагрузку в 100 запросов (90 операций чтения и 10 записей) в секунду. Вы хотите масштабировать и выбираете репликацию. Теперь у вас есть 2 системы, каждая из которых обрабатывает 50 запросов, 45 операций чтения и 5 записей каждая . Теперь эти записи должны быть реплицированы, поэтому фактическое количество записей будет не 5 + 5, а 5 + 5 (исходные записи), а затем еще 5 + 5 (записи реплики), так что у вас будет 90 операций чтения и 20 записей. Таким образом, хотя нагрузка на каждую систему была уменьшена, соотношение операций записи и чтения увеличилось. Это не только изменяет шаблоны ввода-вывода, но, что наиболее важно, изменяет шаблон согласованности нагрузки. Добавьте третью систему, и у вас будет 90 операций чтения и 30 записей и так далее, и так далее. Скоро у вас будет больше записей, чем чтений, и задержка обновления репликации в сочетании с проблемами параллелизма и конфликтами слияния сорвет ваш проект.Суть в том, что «скоро» наступит гораздо раньше, чем вы ожидаете. Достаточно скоро, чтобы оправдать поиск масштабирования вместо этого, поскольку в любом случае вы говорите о масштабировании из 6-8 равноправных узлов, а увеличение емкости в 6-8 раз с помощью масштабирования будет быстрее, намного проще и, возможно, даже дешевле. начнем с.
И имейте в виду, что все это всего лишь чисто теоретические числа. На практике происходит то, что инфраструктура репликации не свободна, она добавляет свою собственную нагрузку на систему. Записи должны отслеживаться, изменения должны быть прочитаны, дистрибьютор должен существовать, чтобы хранить изменения до тех пор, пока они не будут распространены среди подписчиков, затем изменения должны быть записаны и опосредованы для возможных конфликтов . Вот почему я видел очень мало развертываний, которые могли бы претендовать на успех со стратегией горизонтального масштабирования на основе репликации.
Одной из альтернатив является горизонтальное масштабирование только чтения, и здесь репликация работает , обычно с использованием репликации транзакций, но то же самое происходит с доставкой журналов или зеркалированием с моментальным снимком базы данных.
Реальной альтернативой является разделение (т. Е. Сегментирование). Запросы направляются в приложении в соответствующий раздел и попадают на сервер, содержащий соответствующие данные. Изменения в одном разделе, которые необходимо отразить в другом разделе, доставляются асинхронными (обычно на основе обмена сообщениями) средствами. Данные могут быть объединены только внутри раздела. Для более подробного обсуждения того, о чем я говорю, прочтите , как это делает MySpace . Излишне говорить, что такая стратегия имеет большое влияние на дизайн приложения и не может быть просто внедрена после v1.