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

Question

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

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

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

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

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

Вариант 1 Single Main Database [Это мой предпочтительный вариант].

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

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

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

DB1 - клиенты, счета, клиентские ресурсы и т.д.

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

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

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

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

Извинения за длительный вопрос. Итак, вопрос: 1 DB или 2?

Спасибо заранее,

Лиам

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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