Использование кластеризованных индексов columnstore

Задачи по использованию кластеризованных индексов columnstore в SQL Server.

Общие сведения об индексах columnstore см. в разделе Columnstore Indexes Described.

Дополнительные сведения о кластеризованных индексах columnstore см. в разделе Using Clustered Columnstore Indexes.

Содержимое

• Создание кластеризованного индекса columnstore

• Удаление кластеризованного индекса columnstore

• Загрузка данных в кластеризованный индекс columnstore

• Информация об изменениях в кластеризованном индексе columnstore

• Перестроение кластеризованного индекса columnstore

• Реорганизация кластеризованного индекса columnstore

Создание кластеризованного индекса columnstore

Чтобы создать кластеризованный индекс columnstore, сначала создайте таблицу rowstore в виде кучи или кластеризованного индекса, а затем используйте инструкцию CREATE CLUSTERED COLUMNSTORE INDEX (Transact-SQL) для преобразования таблицы в кластеризованный индекс columnstore. Если кластеризованный индекс columnstore должен иметь то же имя, что и кластеризованный индекс, используйте параметр DROP_EXISTING.

В этом примере создается таблица как куча, затем преобразуется в кластеризованный индекс с именем columnstore cci_Simple. В результате таблица rowstore становится таблицей columnstore.

CREATE TABLE T1(
    ProductKey [int] NOT NULL, 
    OrderDateKey [int] NOT NULL, 
    DueDateKey [int] NOT NULL, 
    ShipDateKey [int] NOT NULL);
GO
CREATE CLUSTERED COLUMNSTORE INDEX cci_T1 ON T1;
GO

Дополнительные примеры см. в разделе Примеры статьи CREATE CLUSTERED COLUMNSTORE INDEX (Transact-SQL).

Удаление кластеризованного индекса columnstore

Используйте инструкцию DROP INDEX (Transact-SQL), чтобы удалить кластеризованный индекс columnstore. Эта операция удаляет индекс columnstore и преобразует таблицу columnstore в кучу rowstore.

Загрузка данных в кластеризованный индекс columnstore

Можно добавлять данные к существующим кластеризованным индексам columnstore с помощью любого из стандартных методов загрузки. Например, средство массовой загрузки bcp, службы Integration Services и INSERT... Select может загружать данные в кластеризованный индекс columnstore.

Кластеризованные индексы columnstore используют deltastore, чтобы исключить фрагментацию сегментов столбца в columnstore.

Загрузка в секционированную таблицу

Для секционированных данных SQL Server сначала назначает каждую строку секции, а затем выполняет операции columnstore для данных в секции. Каждая секция имеет собственную rowgroups и как минимум одно deltastore.

Сценарии загрузки Deltastore

Строки накапливаются в каждом deltastore до тех пор, пока число строк не достигнет максимального количества строк, допустимого для rowgroup. Если deltastore содержит максимальное количество строк на группу строк, SQL Server помечает группу строк как "CLOSED". Фоновый процесс, называемый "кортеж-перемещением", находит группу строк CLOSED и перемещается в columnstore, где группа строк сжимается в сегменты столбцов, а сегменты столбцов хранятся в columnstore.

Для каждого кластеризованного индекса columnstore может быть несколько deltastore.

• Если deltastore заблокирован, SQL Server попытается получить блокировку для другого deltastore. Если доступных хранилищ deltastore нет, SQL Server создаст новый deltastore.

• Для секционированной таблицы может быть одно или несколько deltastore для каждой секции.

Только для кластеризованных индексов columnstore в следующих сценариях показывается, когда загруженные строки перейдут непосредственно в columnstore, а когда в deltastore.

В примере каждая rowgroup может иметь 102 400-1 048 576 строк на rowgroup.

В следующем примере показаны результаты загрузки 1 048 577 строк в секцию. Результаты показывают наличие одной СЖАТОЙ rowgroup в columnstore (в виде сжатых сегментов столбцов) и 1 строки в deltastore.

SELECT * FROM sys.column_store_row_groups;

Информация об изменениях в кластеризованном индексе columnstore

Кластеризованные индексы columnstore поддерживают операции DML вставки, обновления и удаления.

Используйте инструкцию INSERT (Transact-SQL) для вставки строки. Строка будет добавлена в deltastore.

Используйте delete (Transact-SQL) для удаления строки.

• Если строка находится в columnstore, SQL Server помечает строку как логически удаленную, но не освобождает физическое хранилище строки до тех пор, пока индекс не будет перестроен.

• Если строка находится в deltastore, SQL Server логически и физически удаляет строку.

Используйте update (Transact-SQL) для обновления строки.

• Если строка находится в columnstore, SQL Server помечает строку как логически удаленную, а затем вставляет обновленную строку в deltastore.

• Если строка находится в deltastore, SQL Server обновляет строку в deltastore.

Перестроение кластеризованного индекса columnstore

Используйте инструкции CREATE CLUSTERED COLUMNSTORE INDEX (Transact-SQL) или ALTER INDEX (Transact-SQL) для выполнения полного перестроения существующего кластеризованного индекса columnstore. Кроме того, можно использовать ALTER INDEX... REBUILD для перестроения определенной секции.

Процесс перестроения

Чтобы перестроить кластеризованный индекс columnstore, SQL Server:

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

• Дефрагментирует таблицу columnstore, физически удаляя строки, которые были логически удалены из таблиц; удаленные байты освобождают место на физическом носителе.

• Объединяет данные rowstore в deltastore с данными в columnstore перед перестроением индекса. После завершения перестроения все данные хранятся в формате columnstore, а deltastore пустует.

• Повторно сжимает все данные в columnstore. Во время перестроения существуют две копии индекса columnstore. После завершения перестроения SQL Server удаляет исходный индекс columnstore.

Рекомендации по перестраиванию кластеризованного индекса Columnstore

Перестраивание кластеризованного индекса columnstore полезно для устранения фрагментации и перемещения всех строк в columnstore. Предлагаются следующие рекомендации.

• Перестраивайте секцию, а не всю таблицу.

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

  2. Для секционированных таблиц нет необходимости перестраивать весь индекс columnstore, поскольку фрагментация вероятна только в секциях, которые были недавно изменены. Таблицы фактов и большие таблицы измерений обычно бывают секционированы для выполнения операций резервного копирования и управления с фрагментами данных таблицы.

• Перестраивайте секцию после масштабных операций DML.

  Перестроение секции дефрагментирует ее и уменьшит занимаемое место на диске. Перестроение удалит все строки из columnstore, помеченные для удаления, и переместит все строки из deltastore в columnstore.

• Перестраивайте секцию после загрузки данных.

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

Реорганизация кластеризованного индекса columnstore

Реорганизация кластеризованный индекса columnstore перемещает все ЗАКРЫТЫЕ rowgroups в columnstore. Чтобы выполнить реорганизацию, используйте инструкцию ALTER INDEX (Transact-SQL) с параметром REORGANIZE.

Реорганизация не требуется для перемещения ЗАКРЫТЫХ rowgroup в columnstore. Процесс перемещения кортежей в конечном счете находит все группы строк CLOSED и перемещает их. Но процесс перемещения кортежей является однопотоковым и может не перемещать группы строк достаточно быстро применительно к конкретной рабочей нагрузке.

Рекомендации по реорганизации

Когда реорганизовать кластеризованный индекс columnstore:

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