Повышение производительности приложения за счет балансировки нагрузки SQL-запросов на Всегда на узлах группы доступности?

Question

У нас есть приложение для браузера в интрасети, написанное на ASP.NET с MS SQL Server в качестве базы данных.У одного из наших клиентов всегда есть группы доступности с двумя узлами.Наши запросы приложений направляются (через прослушиватель группы доступности) на основной узел R / W, и наш клиент использует узел R / O для своих пользовательских отчетов (Crystal Reports).

Поскольку число пользователей растетмы сталкиваемся с проблемами производительности - в основном это связано с процессором.

Мы бы хотели, чтобы заказчик добавил больше процессоров, в то время как он хочет, чтобы мы начали маршрутизировать запросы только для чтения к узлу R / O.

Мы очень сомневаемся, потому что это будут изменения приложения и действительно нетривиальные:

1. Мы понимаем, что отчетность - это идеальный случай для отправки в R /Узел O (уменьшает нагрузку, блокировку,…).Рекомендуется ли балансировать нагрузку, отправляя запросы только для чтения в узлы только для чтения?

2. Мне кажется, нам нужно быть очень осторожными с точки зрения того, что мы можем себе позволить.Для синхронизации узла R / O требуется некоторое время, поэтому нам нужно всегда понимать, что мы можем читать старые данные.Например, пользователь нажимает кнопку «Сохранить» и после сохранения записи мы перечитываем список записей для отображения.Я предполагаю, что мы должны были бы пойти к узлу R / W, чтобы гарантировать, что новые записи будут там.Это правильно?

3. Если мы отправляем запросы в узел R / O, не ухудшаем ли мы надежность системы?В случае сбоя одного узла другой узел должен быть способен выдержать нагрузку на себя.Существуют ли рекомендуемые сценарии, когда имеет смысл отправлять запросы на узел R / O, а когда нет?

Answer 1

Предпочтительно отправлять запросы, связанные с отчетностью (только), на вторичные узлы, чтобы интенсивная загрузка ЦП не снижала производительность вашей онлайн-базы данных.На ваши транзакции не влияет не транзакционное использование.

Однако это не означает, что вам нужно выполнять все запросы R / O на вторичном узле.Допустим, у вас есть транзакционная операция, для которой сначала требуется операция выбора с блокировкой строки, вам не следует выполнять операцию чтения с пассивного узла и операцию DML на активном узле.

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

Для вашего второго вопроса Если второйузел сконфигурирован как Async , тогда да, может быть некоторая задержка, а также в случае сбоя при доставке журнала. Можно увидеть старые данные.

Для третьего вопроса это действительно зависитна текущую / будущую / пиковую нагрузку системы.Трудно сказать то или иное.Это также зависит от бюджета, если вы можете себе это позволить, у вас может быть еще 1 узел.Все это зависит.Но имейте в виду, что системы RDBMS не очень выполнимы для горизонтального масштабирования.