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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

Еще одна возможная вещь (до разделения) - это ваша модель.

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

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

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

Answer 3

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

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

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

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