Руководство по архитектуре SQL Server

Question

Мы разрабатываем новую версию нашего существующего продукта по новой схеме.Это внутреннее веб-приложение с возможно 100 одновременными пользователями (макс.). Оно будет работать в базе данных SQL Server 2008.

В последнее время обсуждается вопрос о том, должна ли у нас быть одна база данных для разделения базы данных по соображениям производительностив двух отдельных базах данных.

База данных может вырасти из 50-100 ГБ в течение 5 лет.

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

[Я знаю, что ответ не простой, так как он зависит от схемы, политики архивирования, объема данных и т. Д.]

Вариант 1 Одна основная база данных [Это мой предпочтительный вариант].

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

Для создания отчетов у нас может быть отдельная отчетностьБД, но это все еще обсуждается.

Вариант 2 Разделить базу данных на 2 отдельные базы данных

DB1 - клиенты, учетные записи, ресурсы клиентов и т. Д.

DB2 - эта информация будет содержать большую часть данных [т.е. данные отслеживания транспортных средств, таблицы финансовых транзакций и т. Д.].

Эти таблицы обычно содержат много данных.[При необходимости он может находиться на отдельном сервере]

Этот план будет включать хранение основных данных в небольшой базе данных [DB1] и сохранение [главным образом] данных типа транзакции только для чтения в отдельной БД [DB2],Пользовательский интерфейс будет в основном читать из DB1 и, следовательно, будет более отзывчивым.[Мне известно, что этот параметр затрудняет применение ссылочной целостности.]

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

Извинения за длинный вопрос.В итоге вопрос 1 БД или 2?

Заранее спасибо,

Лиам

Answer 1

Вариант 1, на мой взгляд, это путь.

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

Производительность вашей дисковой подсистемы будет вашей самой большой проблемой. На ваши проектные решения будет влиять используемое вами решение для хранения данных, которое, как я полагаю, будет использовать технологию SAN.

Как минимум вы захотите разместить файлы LOG (RAID 1) и DATA (RAID 10 или 5 в зависимости от рабочей нагрузки) на отдельных LUNS.

В зависимости от вашего доступа к таблице, вы можете рассмотреть возможность размещения разных групп файлов на отдельных LUN. Разделение данных вашей таблицы может оказаться полезным для вас, но только для больших таблиц.

Answer 2

Я согласен с другими комментариями, утверждающими, что в наши дни между 50 и 100 ГБ мало. Я также согласен, что вы не должны переоценивать силы.

Но, если существует очевидное (или не столь очевидное) логическое разделение между объектами, которые вы храните (как вы говорите, одна из которых предназначена для чтения-записи, а другие части в основном только для чтения), я все равно разделю ее разные дбс. По крайней мере, я бы спроектировал его так, чтобы можно было легко выделить одну часть. Безопасность была бы одной из причин, управление / резервное копирование / восстановление - другой, более простое обслуживание (потому что по своей сути дизайн будет лучше разложен, а части лучше изолированы друг от друга), а в SQL Server - возможность масштабирования (или его отсутствие, если оно это единая база данных). Например, разделение логинов и баз данных контента часто имеет смысл для больших веб-приложений.

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

Все продукты Microsoft, такие как SharePoint, TFS и BizTalk, используют несколько разных баз данных (хотя я не претендую на то, что знаю причины / возможно, просто результат организации их команд).

Особенно в связи с тем, что вы не можете масштабировать один экземпляр базы данных на SQL Server (для кластеризации требуется несколько экземпляров), у меня возникнет соблазн разделить его.

@ Джон: Я бы никогда не использовал бы RAID5. Не решает никакой цели, кроме как ухудшить производительность. Я согласен с подходом RAID10.

Answer 3

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

Answer 4

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

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