Масштабирование SQL Server для Интернета (один считыватель, несколько читателей) - PullRequest
0 голосов
/ 17 декабря 2008

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

Ответы [ 3 ]

2 голосов
/ 17 декабря 2008

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

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

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

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

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

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

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

1 голос
/ 17 декабря 2008

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

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

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

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

1 голос
/ 17 декабря 2008

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

Мне известны два подхода:

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

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

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