Что лучший способ состоит в том, чтобы разделить большие таблицы в SQL Server?

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

Мой первый вопрос - Вы, относятся просто к размещению больших объектов таблицы в отдельных группах файлов (на отдельных шпинделях), или Вы обращаетесь к разделению данных в объекте таблицы?

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

я предложил бы вместо того, чтобы использовать дополнительные базы данных для содержания больших таблиц, Вы изучаете тему Группы файлов в SQL Server Books Online, или для быстрого обзора посмотрите этот статья:

, Если Вы интересуетесь разделением данных (включая разделение в несколько групп файлов) тогда, я рекомендую читать статьи Kimberly Tripp, которая дала превосходное представление в то время SQL Server, 2005 вышел об улучшениях, доступных там. Хорошее место для запуска является этим техническое описание

Какую версию SQL Server Вы используете? 2005 SQL Server имеет разделенные таблицы, но в 2000 (или 7.0) необходимо было использовать представления раздела.

кроме того, каково было обоснование для помещения разделов таблицы в отдельной базе данных?

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

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

Ищут "разделенную таблицу" в MSDN, и необходимо быть в состоянии найти более полное учебное руководство для разделенных таблиц SQL Server 2005 года, а также совета относительно того, как настроить их для максимальной производительности.

Вы спрашиваете о лучших практиках с точки зрения проектирования баз данных или убеждаете свой вывод передумать?:)

С точки зрения дизайна... Назад в goode olde дни, вертикальное разделение было иногда необходимо для работы вокруг ограничений механизма базы данных, где число столбцов в таблице было жестким пределом, как 255 столбцов. В эти дни основные преимущества просто для производительности: помещение редко используемых столбцов или блобов на массиве отдельного диска. Но если Вы регулярно вытянете вещи от обеих таблиц, то это, вероятно, будет потеря. Это кажется, что Ваш вывод страдает от случая преждевременной оптимизации.

С точки зрения сообщения Вашего вывода является неправильным..., что это требует дипломатии. Если он знает о бормотании недовольства с точки зрения производительности, сравнительный тест является, вероятно, лучшим способом показать различие.

Составляют новую физическую таблицу где-нибудь с, 'создают таблицу t1 как выбор * от view1' и затем выполняют некоторый длинный пакет с вертикально разделенной таблицей и Вашей новой таблицей. Если это настолько плохо, как Вы говорите, различие должно быть очевидным.

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

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

Если данные секционирования выровнены физически и логически, то потенциальный ввод-вывод запросов должен быть резко сокращен.

] Например, у нас есть таблица с полем пакета как INT, представляющим INT.

Если мы разделим данные по этому полю и затем повторно запустим запрос для определенного пакета, мы сможем запустить set статистика io ON до и после разделения и увидеть сокращение ввода-вывода,

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

Я не делал много разделов на SQL Server, но у меня есть опыт создания разделов в Sybase ASE, и это известно как устранение разделов.

Существует определенная польза от разделения таблиц (независимо от того, на одной или разных файловых группах / дисках). Если столбец раздела выбран правильно, вы поймете, что ваши запросы будут попадать только в нужный раздел. Представьте, что у вас 100 миллионов записей (я разбивал таблицы гораздо большего размера - около 20+ миллиардов строк), и если по большей части более 70% доступа к данным приходится только на определенную категорию, временную шкалу или тип данных, то это поможет сохранить наиболее доступные данные в отдельном разделе. Кроме того, вы можете выровнять раздел с отдельными файловыми группами на различных типах дисков (SATA, Fiber channel, SSD) так, чтобы наиболее доступные/занятые данные находились на самом быстром хранилище, а наименее/редко доступные - на более медленных дисках.

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

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

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