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