Сколько слишком многих баз данных по SQL Server?
Я работаю с приложением, где мы храним наши клиентские данные в отдельных базах данных SQL для каждого клиента. До сих пор это работало отлично, был даже случай, где некоторый плохой код выбрал неправильные идентификаторы клиентов из базы данных и так как единственные данные в базе данных принадлежали тому клиенту, повреждение не было так плохо, как это, возможно, было. Мои проблемы о количестве баз данных, которые Вы реалистично имеете на SQL Server.
Есть ли какие-либо дополнительные издержки для каждой новой базы данных, которую Вы создаете? Мы мы в конечном счете врезаемся в стену, где мы имеем только ко многим базам данных по одному серверу? Спецификации SQL Server говорят, что у Вас может быть что-то как 32 000 баз данных, но это возможно, у кого-либо есть большое количество базы данных по одному серверу и каковы проблемы, с которыми Вы встречаетесь.
Спасибо,
Frank
5 ответов
Верхние пределы:
- дисковое пространство
- память
- обслуживание
Примеры:
- Перестроить индексы для 32-килобайтных баз данных? Когда?
- Если у 10% из 32k баз данных есть активный набор данных в 100MB за один раз, у вас уже есть 320GB памяти целевого сервера
- , зная, к какой БД вы подключены
- .. .
Эффективный предел зависит от нагрузки, использования, размера базы данных и т. Д.
Правка: И пропускная способность, как упомянул Вятт Барнетт .. Я забыл о сети, узком месте, о котором все забывают ...
Интернет-провайдеры обычно имеют один сервер баз данных, который используется сотнями или тысячами баз данных.
Самая большая проблема с несколькими базами данных - синхронизировать их все по мере внесения изменений в схему. Что касается реалистичного количества баз данных, которые вы можете иметь, и чтобы система работала хорошо, как обычно, это зависит от ситуации. Это зависит от того, насколько мощный сервер и насколько велики базы данных. Скорее всего, в какой-то момент вы захотите иметь несколько серверов не только потому, что это будет быстрее для ваших клиентов, но и потому, что это подвергнет меньшее количество клиентов риску в одно время, если что-то случится с сервером. В какой момент это произойдет, может решить только ваша компания. Конечно, если вы начнете получать большое количество тайм-аутов, вам может быть показан другой сервер (или исправление ваших плохих запросов также может сделать это). Крупные клиенты часто платят за размещение на отдельном сервере, поэтому учитывайте это при формировании цены. У нас был один клиент, который настолько параноидально относился к своим данным, что ему пришлось выделить отдельный сервер, который даже не был расположен в одном месте с другими серверами. Они заплатили за это большие деньги, поскольку нам пришлось арендовать дополнительное пространство.
На самом деле вы спрашиваете о масштабируемости; Хотя в идеале установка 32 000 баз данных на одном сервере, вероятно, невыгодна, это возможно (хотя и не рекомендуется).
Прочтите - http://www.sql-server-performance.com/articles/clustering/massive_scalability_p1.aspx
С архитектурной точки зрения, это в целом правильный выбор. Вы увидели первое огромное преимущество - часто ущерб может быть ограничен одним клиентом, и у вас практически нулевой риск того, что клиент попадет в данные другого клиента. Но вы упускаете другое большое преимущество - вам не нужно держать всех клиентов на одном сервере базы данных. Когда вы действительно станете настолько большим, что ваш сервер пострадает, вы сможете полностью разгрузить клиентов на другой сервер с минимальными усилиями.
Я также готов поспорить, что у вас закончится пропускная способность для управления базами данных, прежде чем ваш сервер выйдет из строя для обработки большего количества баз данных. . .