Масштабирование SQL Server для Интернета (один автор и несколько читателей)

Question

Был ли у кого-нибудь опыт масштабирования SQL Server с использованием нескольких программ чтения и записи.Если нет, может ли кто-нибудь предложить подходящую альтернативу для веб-приложения с интенсивным чтением, с которым у них есть опыт

Answer 1

Это зависит, вероятно, от двух вещей:

1. Насколько велика каждая отдельная запись?
2. Нужны ли читателям данные в режиме реального времени?

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

Если вы выгружаете, скажем, отчеты на конец дня, то вы загружаете их на отдельный сервер, поскольку читателям не требуются данные в реальном времени.В этом есть смысл

Запись на вашем основном сервере должна быть синхронизирована с вашим дополнительным сервером разгрузки...который в любом случае будет заблокирован как часть процесса синхронизации + вы добавляете дополнительную нагрузку для управления синхронизацией.

Большинство приложений в любом случае читаются на 95%+ постоянно.Например, обновление или удаление - это чтение, за которым следует запись.

Моим выбором было бы (вероятно, исходя из малого объема записи и того, что это веб-приложение) масштабировать вверх и запихать как можно больше оперативной памяти на сервер БД с отдельными дисковыми путями для файлов данных и журналов базы данных.

Answer 2

У меня нет никакого опыта масштабирования SQL Server для вашего сценария.Однако для приложения, требующего интенсивного чтения, я бы хотел снизить нагрузку на базу данных и использовать стратегию кэширования, используя что-то вроде Кэш памяти или Скорость в МС

Есть два подхода, о которых я знаю:

1. Загрузите всю базу данных в кэш и управляйте добавлением и обновлением элементов в кэше.

2. Добавляйте элементы в кэш только тогда, когда они запрашиваются, и удаляйте их при выполнении операции записи.

Answer 3

Какая-то репликация сделала бы свое дело.
http://msdn.microsoft.com/en-us/library/ms151827.aspx

Вам, конечно, нужно изменить код вашего приложения.

Некоторые люди используют секционированные таблицы, в которых разные диапазоны строк хранятся на разных серверах, объединенных представлениями.Это было бы невидимо для приложения.Федерация за эту практику, я думаю.

Проектируя свою базу данных, приложение и конфигурацию сервера (сведения о SQL - расположение данных / журнал / система / двоичные файлы sql / tempdb), вы должны быть в состоянии обрабатывать довольно хорошую нагрузку.Старайтесь не усложнять ситуацию, если в этом нет необходимости.