Разделение таблицы SQL Server на основе функции модуля?
У меня есть действительно большая таблица (10 + миллион строк), который начинает показывать знаки снижения производительности для запросов. Так как эта таблица, вероятно, удвоится или утроится в размере относительно скоро, я изучаю разделение таблицы для отжимания некоторой производительности запросов.
Таблица выглядит примерно так:
CREATE TABLE [my_data] (
[id] [int] IDENTITY(1,1) NOT NULL,
[topic_id] [int] NULL,
[data_value] [decimal](19, 5) NULL
)
Так, набор значений для любой данной темы. Запросы на этой таблице всегда будут идентификатором темы, таким образом, будет кластерный индекс на (идентификатор, topic_id).
Так или иначе, так как идентификаторы темы не ограничены (любое количество тем могло быть добавлено), я хотел бы попытаться делить эту таблицу на функции модуля идентификаторов темы. Так что-то как:
topic_id % 4 == 0 => partition 0
topic_id % 4 == 1 => partition 1
topic_id % 4 == 2 => partition 2
topic_id % 4 == 3 => partition 3
Однако я не видел, что любой способ сказать "создает функцию раздела", или "создают схему выделения разделов" для выполнения этой операции при выборе раздела.
Это даже возможно? Как мы можем сделать функцию раздела на основе операции выполненной на входном значении?
4 ответа
Вам просто нужно создать столбец модуля в качестве сохраненного компьютерного столбца.
Синий стиль Питера, вот один, который я сделал ранее (хотя я не на 100% уверен, что у меня есть правое предложение ценностей раздела):
CREATE PARTITION FUNCTION [PF_PartitonFour] (int)
AS RANGE RIGHT
FOR VALUES (
0,
1,
2)
GO
CREATE PARTITION SCHEME [PS_PartitionFourScheme]
AS PARTITION [PF_PartitonFour]
TO ([TestPartitionGroup1],
[TestPartitionGroup2],
[TestPartitionGroup3],
[TestPartitionGroup4])
GO
CREATE TABLE [my_data] (
[id] [int] IDENTITY(1,1) NOT NULL,
[topic_id] [int] NULL,
[data_value] [decimal](19, 5) NULL
[PartitionElement] AS [topic_id] % 4 PERSISTED,
) ON [PS_PartitionFourScheme] (PartitionElement);
GO
10 миллионов строк не так много для SQL Server для обработки; Регулярный индекс, вероятно, решит это без необходимости разбиения. Как было отмечено, попробуйте кластеризировать на разных наборах колонн; Кластеризация на Topicid, ID кажется, что что-то, что нужно проверить, особенно если у большинства запросов есть топицид как критерий. Клагаторный индекс, подобный тому, что имеет примерно такой же эффект, что и PARITING, по крайней мере, в том, что он группирует связанные строки данных вместе на диске и позволяет быстро определять сканирование.
Если этот дизайн работает, все, что вам нужно беспокоиться, это фрагментация из вкладышей, но это управляемое. После получения индексации убедитесь, что у вас недостаточно RAM, а у вас нет узкого места диска.
Из документации кажется, что для создания 4 разделов необходимо дать значения функции:
...
CREATE PARTITION FUNCTION myRangePF1 (int)
AS RANGE LEFT FOR VALUES (1, 100, 1000);
Не могли бы вы просто сделать свои вычисления выше этого вызова и найти нужные значения для разделения? Подставить значения в вызов? Или я пропустил, почему вы хотите использовать модуль? Основываясь на вероятности наличия пробелов в вашем идентификаторе, вам, возможно, понадобится использовать некоторую статистическую математику, чтобы узнать, где разбиться на разделы.
CREATE PARTITION FUNCTION myRangePF1 (int)
AS RANGE LEFT FOR VALUES (@low, @Med, @High);
Хэш-разметка недоступна в SQL Server 2005/2008. Вы должны использовать разметку по диапазону.
При этом следует помнить, что разметка в первую очередь является вариантом хранения, см. Концепции разделов и индексов:
Разбиение на разделы позволяет создавать большие таблицы или индексы более управляемые , потому что Разбиение на разделы позволяет управлять и получить быстрый доступ к подмножествам данных эффективно, при сохранении целостность сбора данных. По адресу . используя разделение, операция такая как загрузка данных из ОБПС в Система OLAP занимает всего несколько секунд, вместо минут и часов работает в более ранних версиях SQL Server. Maintenance operations которые выполняются на подмножествах данных также выполняются более эффективно потому что эти операции направлены только необходимые данные, а не весь стол.
Как видите, введение разметки в MSDN сфокусировано на обслуживании, управляемости и загрузке данных. По моему опыту разметка дает, в лучшем случае, 0 прирост производительности. Особенно в SQL 2005. Обычно это приводит к снижению производительности. Для повышения производительности необходимо использовать правильный кластерный индекс и правильно спроектированные некластерные индексы.
В SQL 2008 есть улучшения в параллельных операторах в отношении разделов, если они правильно распределены с точки зрения ввода-вывода, см. Проектирование разделов для улучшения производительности запросов . Однако их преимущество является незначительным и затмевается преимуществами правильно спроектированного набора кластерных и некластерных индексов. Пример, указывающий на кластерный индекс в (id, topic_id), где id - это идентификатор, полезен только для поиска одного элемента по идентификатору. С другой стороны, кластеризованный индекс по (topic_id, id) пойдет на пользу любым запросам, которые ищут конкретную тему (темы). Я не знаю ваших системных требований и выполняемых вами запросов, но проблемы с производительностью 10М строк в такой узкой таблице пахнут как проблема с индексацией и запросами, никакой проблемы с разметкой.