Параллельная обработка в SQL Server 2008 R2

SQL Server не поддерживает функции горизонтального масштабирования. Это на самом деле довольно сложно и, как правило, требует много редизайн приложения, чтобы быть сделано правильно.

Вы уверены, что база данных была правильно настроена так, что все в базе данных работает с максимальной эффективностью? Правильная настройка базы данных (если это еще не сделано) будет НАМНОГО дешевле, чем масштабирование рабочей нагрузки приложений на нескольких физических серверах. У меня был клиент, который думал, что их приложение превзойдет сервер баз данных, на котором оно работает, поскольку компания в возрасте 3 лет уже работала с 24-ядерным SQL Server до 60%+ в течение рабочего дня. С некоторыми изменениями схемы и небольшим изменением кода мы смогли снизить нагрузку на процессор примерно до 5% на том же оборудовании.

Существует несколько различных способов масштабирования приложения на нескольких серверах.

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

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

3. Настроить представления на нескольких серверах, которые указывают на локальную копию таблицы, а также на удаленную копию таблицы на одном или нескольких серверах. Ограничения устанавливаются в физических таблицах, в которых указывается, какие части данных будут существовать на каком сервере. Каждый сервер содержит только часть базы данных. Представления помещаются на каждый сервер, так что любой пользователь может подключиться к любому серверу. Это требует МНОГО перемещения данных и очень тщательного планирования, чтобы гарантировать, что схема редко изменяется, поскольку изменения схемы должны выполняться очень осторожно.

Независимо от того, по какому маршруту вы идете, необходимо выполнить МНОГО планирования, чтобы убедиться, что выбран правильный вариант. Я очень рекомендую работать с консультантом, имеющим опыт работы с подобными конфигурациями. Положительным моментом является то, что есть несколько человек, которые раньше занимались подобными вещами, а недостатком является то, что их не так много, и они будут очень дорогими. Если вы решите пойти по этому пути, зайдите на мой веб-сайт, и я свяжу вас с несколькими консультантами (включая меня), чтобы вы могли быть уверены, что подбираете подходящего человека для этой работы.

Для вариантов 1 и 3 высокая доступность через что-то вроде кластеризации Windows становится очень важной очень быстро. Если доступный для записи сервер в первом варианте переходит в автономный режим, тогда все приложение отключается. Если какой-либо сервер в варианте 3 переходит в автономный режим, то все приложение отключается. С вариантом 2 он немного более способен справиться с отключением сервера, но если приложение генерирует такую ​​большую нагрузку, вам нужно запланировать N+1 узлов для варианта 2.

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