Подходы к секционированию таблиц в SQL Server

База данных, с которой я работаю, в настоящее время превышает 100 ГиБ и обещает значительно вырасти в течение следующего года или около того. Я пытаюсь разработать схему разделения, которая будет работать с моим набором данных, но до сих пор безуспешно. Моя проблема в том, что запросы к этой базе данных обычно проверяют значения нескольких столбцов в этой одной большой таблице, что приводит к получению наборов результатов, которые перекрываются непредсказуемым образом.

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

Вот структура двух наших основных таблиц, чтобы представить это в перспективе.

Table: Case
Columns:
Year
Type
Status
UniqueIdentifier
PrimaryKey
etc.

Table: Case_Participant
Columns:
Case.PrimaryKey
LastName
FirstName
SSN
DLN
OtherUniqueIdentifiers

Обратите внимание, что любой из вышеперечисленных столбцов можно использовать в качестве параметров запроса.


sql-server partitioning
person Jeff Swensen    schedule 11.06.2009    source источник
comment
Возможно, вам лучше спросить об этом на serverfault.   -  person Joel Coehoorn    schedule 12.06.2009
comment
Согласитесь с Джоэлем. Я повторил это. Сотрудники ServerFault являются экспертами в этой области.   -  person RBarryYoung    schedule 12.06.2009
comment
У меня возникло искушение опубликовать его там, но после рассмотрения некоторых вопросов он мне не подошел.   -  person Jeff Swensen    schedule 12.06.2009

Ответы (3)


arrow_upward
5
arrow_downward

Вместо того, чтобы гадать, измерьте. Сбор статистики использования (запросы выполняются), посмотрите на собственную статистику движка, например sys.dm_db_index_usage_stats, а затем принять обоснованное решение: хорошим кандидатом будет раздел, который лучше всего сбалансирует размер данных и дает наилучшее соответствие для наиболее часто выполняемых запросов. Конечно, вам придется пойти на компромисс.

Также не забывайте, что секционирование выполняется по индексу. (где «таблица» = один из индексов), а не для каждой таблицы, поэтому вопрос не в том, что разбивать, а в том, какие индексы секционировать или нет и какую функцию секционирования использовать. Очевидно, что ваши кластерные индексы в двух таблицах будут наиболее вероятными кандидатами (не имеет большого смысла разбивать только некластеризованный индекс, а не кластеризованный), поэтому, если вы не рассматриваете редизайн кластеризованных ключей, вопрос действительно, какую функцию разделения выбрать для кластерных индексов.

Если бы я рискнул предположить, я бы сказал, что для любых данных, которые накапливаются с течением времени (например, «случаи» с «годом»), наиболее естественным разделом является скользящее окно.

person Remus Rusanu    schedule 11.06.2009

arrow_upward
0
arrow_downward

Если у вас нет другого выбора, вы можете разделить по ключевым модулям количество таблиц разделов. Допустим, вы хотите разделить на 10 таблиц. Вы определите таблицы:
Case00
Case01
...
Case09

И разделите ваши данные с помощью модуля 10 UniqueIdentifier или PrimaryKey и поместите каждую запись в соответствующую таблицу (в зависимости от вашего уникального идентификатора UniqueIdentifier вам может потребоваться ручное выделение идентификаторов).

При выполнении запроса вам нужно будет выполнить один и тот же запрос для всех таблиц и использовать UNION, чтобы объединить набор результатов в один результат запроса.

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

person Alex Shnayder    schedule 11.06.2009
comment
Несомненно, цель - не достичь предела размера таблицы, но я также пытаюсь сохранить производительность запросов. - person Jeff Swensen; 12.06.2009

arrow_upward
0
arrow_downward

Еще одна возможная вещь, на которую можно посмотреть (перед разбиением), - это ваша модель.

Вы в нормализованной базе данных? Существуют ли дальнейшие шаги, которые могут улучшить производительность с помощью различных вариантов нормализации / де- / частичной нормализации? Есть ли варианты преобразования данных в модель размерной звезды в стиле Кимбалла, которая оптимальна для отчетов / запросов?

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

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

person Cade Roux    schedule 13.06.2009