Подтвердить что ты не робот

Сколько слишком много баз данных на SQL Server?

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

Есть ли дополнительные накладные расходы для каждой создаваемой новой базы данных? Мы, в конце концов, попали в стену, где у нас есть только многие базы данных на одном сервере? Спецификации SQL Server говорят, что у вас может быть что-то вроде 32000 баз данных, но это возможно, у кого-то есть большое количество базы данных на одном сервере и с какими проблемами вы сталкиваетесь.

Спасибо,

Франк

4b9b3361

Ответ 1

Верхние пределы

  • дисковое пространство
  • память
  • содержание

Примеры:

  • Восстановление индексов для 32k баз данных? Когда?
  • Если 10% из 32 тыс. баз данных имеют активный набор из 100 Мбайт данных в памяти за один раз, вы уже на целевой серверной памяти 320 ГБ
  • зная, к какой базе данных вы подключены.
  • ...

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

Изменить: и пропускная способность, как упоминал Уайетт Барнетт. Я забыл о сети, узкое место, о котором все забывают...

Ответ 2

Самая большая проблема со всеми несколькими базами данных заключается в том, чтобы синхронизировать их с изменениями схемы. Что касается реалистичного количества баз данных, которые вы можете иметь, и система работает хорошо, как обычно, это зависит. Это зависит от того, насколько мощный сервер и насколько велики базы данных. Вероятно, вы захотите иметь несколько серверов в какой-то момент не только потому, что они будут быстрее для ваших клиентов, но потому, что когда-нибудь у вас будет меньше клиентов, если что-то случится с сервером. В какой момент это может решить только ваша компания. Разумеется, если вы начнете получать много тайм-аутов, то может быть указан другой сервер (или это может сделать исправление ваших бедных запросов). Большие клиенты часто платят премию за то, чтобы быть на отдельном сервере, поэтому учтите это в ваших ценах. У нас был один клиент, который был параноиком относительно своих данных, у нас должен был быть отдельный сервер, который даже не был совместно расположен с другими серверами. Они заплатили большие деньги за это, поскольку нам пришлось снимать дополнительное пространство.

Ответ 3

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

Ответ 4

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

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

Ответ 5

То, о чем вы действительно спрашиваете, - это масштабируемость; Хотя, в идеале установка 32 000 баз данных на одном сервере, вероятно, не выгодна, но это возможно (хотя и не рекомендуется).

Чтение - http://www.sql-server-performance.com/articles/clustering/massive_scalability_p1.aspx

Ответ 6

Я знаю, что это старый поток, но он имеет ту же структуру, что и у нас в течение последних 2 лет, и текущие версии 1768 баз данных на трех серверах.

У нас есть следующая настройка (не включая зеркала и т.д.):

  • 2 сервера веб-фермы и 4 сервера содержимого
  • экземпляр SQL только для основной базы данных клиентов, который запрашивается, когда они получают доступ к своей веб-странице по идентификатору, чтобы получить имя сервера/экземпляра и базы данных, в которых находятся их данные. Затем он сохраняется в билете проверки подлинности.
  • 3 SQL-сервера для размещения баз данных клиентов с распределением нагрузки при создании на основе текущего общего количества учащихся, которые существуют во всех базах данных на каждом сервере (быстро вычисляется по полю номера лицензии в основной базе данных).
  • На каждом SQL Server существует небольшая основная база данных, которая содержит общие статические данные, которые используются всеми клиентами, поэтому позволяет создавать более мелкие клиентские базы данных и более быстрое обновление содержимого.

Самое большое, что упоминалось выше, - синхронизация структур баз данных! Для этого я закончил программирование небольшой формы Windows.NET, которая просматривает всех клиентов в основной базе данных, и вы вставляете код для выполнения, и он будет проходить через получение базы данных и выполнение SQL, который вы использовали.

Создание новых клиентов также вызвало некоторые проблемы для нас, поэтому я закончил программирование системы управления для наших продавцов и создал новую базу данных на основе резервной копии неактивной "пустой" базы данных, поэтому у нас есть последняя БД без необходимо повторно script создать всю базу данных script. Затем он вставляет детали клиента в основную базу данных с указанием места создания базы данных и переноса любых старых данных из старой версии нашего программного обеспечения. Все это делается на отдельном экземпляре перед перемещением, поэтому уменьшается любые блокировки SQL.

Теперь мы переходим к одной базе данных для нашей следующей версии программного обеспечения, так как избыточность базы данных почти невозможна с таким количеством баз данных! Это огромная вещь, которую следует учитывать, поскольку SQL создает пару ожидающих задач, которые отражают ваши данные на базу данных, как только вы начнете умножать базы данных, которые он выходит из-под контроля, и системе почти исключительно поручено синхронизация и может заблокироваться из-за сдвига количество потоков. См. Стр. 30 документа Microsoft ниже:

Руководство по SQLCAT для аварийного восстановления с высокой доступностью .pdf

Однако у меня есть сомнения по поводу перехода на одну базу данных из-за некоторых проблем, о которых упоминалось выше, например, постоянной проверки каждой процедуры, которую текущий клиент имеет доступ только к своим данным, а также к вещам, проблема теперь будет влиять на каждую базу данных, такую ​​как индексирование таблиц и так далее. Также в тот момент, когда наш клиент находится на трех серверах, но единственная база данных будет иметь в виду да, у нас есть избыточность, но если ошибка была в базе данных, а не в том, что происходит с сервером, то каждый отдельный клиент, а не только одна клиентская база данных.

В целом, это зависит от того, что вы делаете, и если вы хотите избыточности; для меня избыточность теперь ключевая, и все остальное в идеальном мире не должно происходить (например, ошибка, которая вызывает ошибки в базе данных для всех). Мы только начали с того, что ожидали сотню или около того, чтобы перейти к системе со старого самодостаточного программного обеспечения, и это быстро превратилось в 200 500 1000 000... Теперь у нас более 750 000 пользователей используют нашу систему каждый год, а в августе/сентябре мы имеют более 15 000 одновременных пользователей в Интернете (ожидается, что в этом году они достигнут 20 000).

Надеюсь, что это поможет кому-то по линии: -)

Привет

Лиам