Я изучаю возможности масштабирования sql server 2008R2. просто увеличения масштаба будет недостаточно.
"p2p-репликация" и "распределенные секционированные представления" выглядят интересно, но оба требуют (нескольких ?!) корпоративных лицензий, которые очень дороги, и все же не являются идеальными решениями.
Одна очень простая идея была:
Read from Random Server - Write to all Servers
Красиво завернутая в транзакцию, чтобы ее можно было откатить, если она не прошла успешно на всех серверах. Я боюсь некоторых серьезных проблем с блокировкой, если что-то пойдет не так на одном сервере или он ждет из-за какой-либо другой блокировки на одном сервере.
Очень похожее решение:
Read from Random Server - Write to Server A (which replicates automaticly to all others)
Это будет дороже, потому что необходима стандартная лицензия, а первую можно было бы сделать с помощью экспресс, но будет ли это лучше с точки зрения производительности? Насколько быстры эти автоматические реплики? Имеет ли все это смысл или есть способ получше?
Основываясь на ответах, которые OP предоставил в разделе комментариев выше, это действительно не похоже на решение для горизонтального масштабирования. Думаю, вам лучше потратить время на следующее:
1.) Проектирование базы данных и производительность запросов -> Проанализируйте рабочую нагрузку, выполняемую в SQL на этом экземпляре, и убедитесь, что она выполняется должным образом. Ищите запросы, которые занимают больше времени, чем вы ожидаете, посмотрите на базовый дизайн таблиц и задействованный хранимые процедуры / код SQL.
2.) Посмотрите, какие ресурсы вы используете на сервере. Вы исчерпываете какие-либо ограничения SQL Express? Если это так, то я бы рассмотрел возможность запуска некоторых тестовых сценариев и анализа рабочей нагрузки, чтобы увидеть, поможет ли переход на сервер с более высокими техническими характеристиками и, возможно, переход на стандартную или корпоративную версию, а также увеличенное распределение ресурсов. Вы развертываете 64-битные боксы? Сколько памяти? Проведите анализ узких мест, чтобы определить, какие узкие места вас замедляют.
3.) Убедитесь, что ведется обслуживание базы данных (перестроение индексов, обновление статистики и надлежащее обслуживание резервного копирования - я часто нахожу, что поставщики устанавливают выпуск SQL Server Express без резервного копирования и обслуживания). http://expressmaint.codeplex.com/ для сценария, который поможет автоматизировать и запланировать некоторые из этих задач)
4.) Вы размещаете свое приложение и ядро базы данных SQL Server на одном сервере? Возможно, пришло время рассмотреть возможность их разделения. Приложения и SQL Server часто имеют конкурирующие приоритеты в отношении системных ресурсов и не часто хорошо дополняют друг друга в одном устройстве. Протестируйте и посмотрите. Посмотрите на perfmon, чтобы понять влияние.
Если после внесения всех этих изменений у вас по-прежнему возникают проблемы с производительностью, вы можете подумать о применении подхода горизонтального масштабирования, но я думаю, что эти шаги являются более простыми и менее затратными для вас и ваших клиентов в долгосрочной перспективе.
Настройте репликацию слиянием с вашего централизованного сервера на каждый из этих экземпляров Express; Express не может выступать в качестве издателя, но может быть сателлитом, включая обновления слияния.
Мне кажется, вам нужно немного настроить производительность SQL. Если база данных достаточно мала для работы в SQL Express, то, скорее всего, вам не нужно настраивать какую-то масштабную установку. Вероятно, вам просто нужно начать с настройки индекса, чтобы исправить неэффективные запросы и настроить некоторые задания по обслуживанию индекса.