Индексы columnstore

Статья
10/31/2013

Оптимизированный для памяти xVelocity индекс Columnstore группирует и сохраняет данные каждого столбца с последующим соединением всех столбцов для завершения индекса в целом. Они отличаются от традиционных индексов, которые группируют и сохраняют данные для каждого ряда, затем объединяют все ряды, чтобы завершить создание всего индекса. Для некоторых типов запросов обработчик запросов SQL Server может воспользоваться возможностями макета columnstore, что позволяет значительно сократить время выполнения запросов. Взрывоподобный рост хранения данных, поддержка решений и приложений BI вызвали необходимость в быстром и точном чтении и обработке очень больших наборов данных в полезные сведения и знания. Данный рост объемов данных и повышающиеся ожидания требуют обслуживания или улучшения с помощью добавочных повышений производительности. Технология индексов SQL Server columnstore особенно подходит для типовых наборов данных хранилища данных. Индексы columnstore могут преобразовать опыт работы с хранилищем данных для пользователей, предоставляя улучшенную производительность для таких стандартных запросов хранилища данных, как фильтрация, статистическая обработка, группирование и запросы соединения типа «звезда».

Содержание

Основы

Основы. Описание индексов columnstore
Основы. Ограничения индекса Columnstore
Демонстрационный пример. Columnstore индексы с секционированной таблицей
Основы. Типичные сценарии индекса Columnstore
Основы. Оптимизации фильтра по битовым картам

Рекомендации

Рекомендации. Обновление данных в индексе columnstore
Рекомендации. Выбор столбцов для индекса columnstore
Рекомендации. Секционированные таблицы

Как

Как создать индекс columnstore
Как определить размер нового индекса columnstore
Как устранить неполадки производительности индекса columnstore

Основы. Описание индексов columnstore

С помощью индексов columnstore в Компонент SQL Server Database Engine можно значительно сократить время обработки распространенных запросов хранилища данных. Типичная рабочая нагрузка хранилища данных связана с обобщением большого объема данных. Методы, обычно используемые в системах хранения данных и поддержки решений для повышения производительности, включают предварительно вычисляемые сводные таблицы, индексированные представления, кубы OLAP и т. п. Несмотря на то что все перечисленное может значительно ускорить обработку запросов, эти методы могут быть негибкими, трудными в обслуживании и должны разрабатываться специально для каждой задачи с запросами.

Например, рассмотрим таблицу фактов F1 с ключевыми столбцами измерений dk1 и dk2. Пусть M будет такой агрегатной функцией, как SUM. Вместо вычисления M по колонке dk1 каждый раз, когда выполняется запрос, ссылающийся на M(dk1), создается и используется сводная таблица F2(dk1, M), чтобы результаты были предварительно вычислены и запрос выполнялся быстрее. Тем не менее если требуется ссылка запроса на M(dk2), должна быть создана новая сводная таблица F3(dk2, M) с этой информацией. При увеличении количества столбцов в таблице и многими возможными функциями, этот метод становится трудным в обслуживании и не покрывает всех требуемых запросов.

Эти издержки могут быть значительными для пользователя. С помощью индексов columnstore SQL Server можно снизить издержки других решений. Индексы columnstore также позволяют запросам вычислять результат, поэтому предварительное вычисление не требуется.

Основные характеристики технологии SQL Server columnstore заключаются в следующем:

Столбчатый формат данных — в отличие от традиционной организации данных по строкам (называемом форматом rowstore), в столбчатых системах баз данных, например, SQL Server с индексами columnstore, данные группируются и хранятся по одному столбцу за раз. Обработка запросов SQL Server может воспользоваться преимуществами нового макета данных и значительно улучшить время выполнения запросов.
Результаты запроса быстрее — индексы columnstore могут быстрее выдавать результаты по следующим причинам:
- Должны быть прочитаны только необходимые столбцы. Таким образом, меньше данных читается из диска в память и позже перемещается из памяти в кэш процессора.
- Столбцы сильно сжимаются. Это уменьшает число байтов, которые необходимо прочесть и переместить.
- Большинство запросов не трогают все столбцы таблицы. Таким образом, многие столбцы никогда не будут передаваться в память. Это, в сочетании с отличным сжатием, улучшает использование буферного пула, что уменьшает общее число операций ввода-вывода.
- Расширенная технология выполнения запросов быстро обрабатывает фрагменты столбцов под названием пакеты, снижая загрузку ЦП.
Ключевые столбцы — В индексе columnstore не существует понятия ключевых столбцов, так что ограничение числа ключевых столбцов в индексе (16) не применяется к индексам columnstore.
Ключ кластеризованного индекса — если базовая таблица является кластеризованным индексом, то все столбцы в ключе кластеризации должны присутствовать в некластеризованном индексе columnstore. Если столбец в ключе кластеризации не указан в инструкции создания индекса, то он будет добавлен в индекс columnstore автоматически.
Секционирование — индексы Columnstore работают с секционированием таблиц. Никаких изменений в синтаксис разделов таблицы вносить не требуется. Индекс columnstore на секционированной таблице должен быть выровнен по секциям с базовой таблицей. Таким образом, некластеризованный индекс columnstore может быть создан только на секционированной таблице, если столбец секционирования является одним из столбцов в индексе columnstore.
Размер записи — ограничение размера записи ключа индекса в 900 байт также не применяется к индексам columnstore.
Обработка запросов — вместе с индексом columnstore SQL Server представляет пакетную обработку для получения преимущества от столбчатого расположения данных. Структура columnstore и пакетная обработка способствуют приросту производительности, но исследование проблем производительности может быть более сложным, как если бы присутствовал только один фактор.
Невозможно обновить таблицу — для SQL Server 2012 таблица с индексом columnstore не может быть обновлена. Возможные варианты решения см. в Рекомендации: Обновление данных в индексе columnstore

Синтаксис создания индекса columnstore см. в разделе CREATE COLUMNSTORE INDEX (Transact-SQL).

Типы данных

Общие типы бизнес-данных могут быть включены в индекс columnstore. Следующие типы данных могут быть включены в индекс columnstore.

char и varchar
nchar и nvarchar (кроме varchar(max) и nvarchar(max))
decimal (и numeric) (кроме как при точности более 18 цифр)
int, bigint, smallint и tinyint
float (и real)
bit
money и smallmoney
Все типы данных даты и времени (за исключением datetimeoffset, масштаб которых превышает 2)

Следующие типы данных не могут быть включены в индекс columnstore.

binary и varbinary
ntext, text и image
varchar(max) и nvarchar(max)
uniqueidentifier
rowversion (и timestamp)
sql_variant
decimal (и numeric) с точностью более 18 цифр
Значения типа datetimeoffset, масштаб которых превышает 2
Типы CLR (hierarchyid и пространственные типы)
xml

Потенциал для низкой производительности

Производительность запросов поддержки решений часто улучшается при использовании индексов columnstore в больших таблицах, но некоторые запросы и даже рабочие нагрузки могут работать хуже. Используя подход на основе стоимости, оптимизатор запросов обычно решает использовать индекс columnstore только тогда, когда происходит общее повышение производительности запроса. Однако модели стоимости, используемые оптимизатором, приблизительны и иногда оптимизатор выбирает использовать индекс columnstore для таблицы, когда было бы лучше использовать хранилище строк (сбалансированное дерево или кучу) для доступа к таблице. Если происходит подобное, используйте указание запроса IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX или используйте указание индекса для направления оптимизатора в индекс хранилища строк. Оптимизатор может по-прежнему включать некоторую информацию из индекса columnstore. Таким образом, в редких случаях этот параметр может не решить проблемы производительности. Если производительность рабочей нагрузки не улучшилась с использованием индекса columnstore, и невозможно использовать указания индекса для исправления проблемы, удалите индекс columnstore и вернитесь к обработке хранилища строк.

Проблемные области

Индексы columnstore и обработка запросов на основе столбцов SQL Server оптимизированы для типовых запросов хранилища данных, в которые входит большая таблица фактов, а таблицы средних и малых измерений объединены в конфигурацию схемы типа «звезда», затем сгруппированы и статистически обработаны. Хотя число строк в таблице фактов велико, эти запросы обычно возвращают сравнительно небольшой результирующий набор, поскольку данные статистически обработаны. Производительность запросов с помощью индекса columnstore может быть небольшой, если выполняются какие-либо из приведенных ниже условий.

Результирующий набор большой, поскольку данные статистически не обработаны. (Очевидно, что возврат большого результирующего набора происходит дольше, чем небольшого.)
Нет соединения, фильтрации или статистической обработки. В этом случае пакетная обработка отсутствует. Таким образом, преимущество индекса columnstore ограничено преимуществами сжатия и чтения меньшего числа столбцов.
Необходимо объединить две большие таблицы так, чтобы создать большие хэш-таблицы, которые не помещаются в память и должны быть сброшены на диск.
Возвращается много столбцов, что увеличивает извлекаемую часть индекса columnstore.
Условие соединения с таблицей с индексом columnstore содержит более чем один столбец.

Можно использовать методы, описанные ранее в данном разделе для обхода медленной обработки с columnstore, если это происходит по одной из этих причин.

В начало

Основы. Ограничения индекса Columnstore

Основные ограничения

Индекс columnstore.

Не более 1024 столбцов.
Не пригоден для кластеризации. Доступны только некластеризованные индексы columnstore.
Не может быть уникальным индексом.
Не может быть создан для представления или индексированного представления.
Не может содержать разреженный столбец.
Не может использоваться в качестве первичного ключа или внешнего ключа.
Не может быть изменен с помощью инструкции ALTER INDEX. Вместо этого удалите и заново создайте индекс columnstore. (Инструкцию ALTER INDEX можно использовать, чтобы отключить и перестроить индекс columnstore.)
Не может быть создан с помощью ключевого слова INCLUDE.
Нельзя включать ключевые слова ASC и DESC для сортировки индексов. Индексы columnstore упорядочены в соответствии с алгоритмами сжатия. В индексе сортировка не допускается. Значения, выбранные из индекса columnstore, могут быть отсортированы при помощи алгоритма поиска, однако необходимо использовать условие ORDER BY, чтобы гарантировать сортировку результирующего набора.
Не использует и не хранит статистические данные в форме традиционного индекса.
Не может содержать столбец с атрибутом FILESTREAM. Другие столбцы в таблице, неиспользуемые в индексе, могут содержать атрибут FILESTREAM.

Невозможно обновить таблицу с индексом columnstore.

Чтобы обойти эту проблему, см. Рекомендации. Обновление данных в индексе columnstore.

Последствия ограниченной памяти

Обработка columnstore оптимизирована для обработки в памяти. SQL Server внедряет механизмы, позволяющие сбрасывать данные и большинство структур данных на диск при недостатке памяти. При наличии серьезных ограничений памяти обработка использует хранилище строк. Могут быть экземпляры, в которых индекс columnstore выбран как метод доступа, но не хватает памяти для построения требуемых структур данных. Если обработка начинается с операции columnstore, затем включается режим по умолчанию с более медленным путем к коду, то может наблюдаться некоторое снижение производительности в тех случаях, когда запросы сталкиваются со значительной нехваткой памяти. Фактические требования к объему памяти для любого запроса зависят от конкретного запроса. Для построения индекса columnstore требуется объем примерно 8 МБ, умноженный на число столбцов в индексе и умноженный на DOP (степень параллелизма). Обычно требования к объему памяти увеличиваются по мере увеличения доли столбцов, являющихся строками. Поэтому уменьшение DOP может снизить требования к объему памяти для создания индекса columnstore.

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

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

Индекс columnstore не поддерживает SEEK

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

Индексы columnstore нельзя использовать вместе со следующими функциями:

Сжатие страниц и строк, а также формат хранения vardecimal (индекс columnstore уже сжат в другом формате).
Репликация
Отслеживание изменений
Система отслеживания измененных данных
Файловый поток

В начало

Демонстрационный пример. Columnstore индексы с секционированной таблицей

В примерах в этом разделе используется секционированная таблица с именем FactResellerSalesPtnd, созданная в образце базы данных AdventureWorksDW2012 . Для проверки индекса columnstore в секционированной таблице подключитесь к базе данных AdventureWorksDW2012 и выполните следующий код, чтобы создать секционированную версию таблицы фактов.

Примечание
Сведения об образцах баз данных и инструкции по загрузке базы данных см. в разделе Образцы баз данных AdventureWorks.

Создайте таблицу FactResellerSalesPtnd

Выполните следующий код для создания секционированной версии таблицы FactResellerSales с именем FactResellerSalesPtnd.

USE AdventureWorksDW2012;
GO

CREATE PARTITION FUNCTION [ByOrderDateMonthPF](int) AS RANGE RIGHT 
FOR VALUES (
    20050701, 20050801, 20050901, 20051001, 20051101, 20051201, 
    20060101, 20060201, 20060301, 20060401, 20060501, 20060601, 
    20060701, 20060801, 20060901, 20061001, 20061101, 20061201, 
    20070101, 20070201, 20070301, 20070401, 20070501, 20070601, 
    20070701, 20070801, 20070901, 20071001, 20071101, 20071201, 
    20080101, 20080201, 20080301, 20080401, 20080501, 20080601, 
    20080701, 20080801, 20080901, 20081001, 20081101, 20081201
) 
GO

CREATE PARTITION SCHEME [ByOrderDateMonthRange] 
AS PARTITION [ByOrderDateMonthPF] 
ALL TO ([PRIMARY]) 
GO

-- Create a partitioned version of the FactResellerSales table
CREATE TABLE [dbo].[FactResellerSalesPtnd]( 
    [ProductKey] [int] NOT NULL, 
    [OrderDateKey] [int] NOT NULL, 
    [DueDateKey] [int] NOT NULL, 
    [ShipDateKey] [int] NOT NULL, 
    [CustomerKey] [int] NOT NULL, 
    [EmployeeKey] [int] NOT NULL, 
    [PromotionKey] [int] NOT NULL, 
    [CurrencyKey] [int] NOT NULL, 
    [SalesTerritoryKey] [int] NOT NULL, 
    [SalesOrderNumber] [nvarchar](20) NOT NULL, 
    [SalesOrderLineNumber] [tinyint] NOT NULL, 
    [RevisionNumber] [tinyint] NULL, 
    [OrderQuantity] [smallint] NULL, 
    [UnitPrice] [money] NULL, 
    [ExtendedAmount] [money] NULL, 
    [UnitPriceDiscountPct] [float] NULL, 
    [DiscountAmount] [float] NULL, 
    [ProductStandardCost] [money] NULL, 
    [TotalProductCost] [money] NULL, 
    [SalesAmount] [money] NULL, 
    [TaxAmt] [money] NULL, 
    [Freight] [money] NULL, 
    [CarrierTrackingNumber] [nvarchar](25) NULL, 
    [CustomerPONumber] [nvarchar](25) NULL,
    OrderDate [datetime] NULL,
    DueDate [datetime] NULL,
    ShipDate [datetime] NULL
) ON ByOrderDateMonthRange(OrderDateKey);
GO

-- Using simple or bulk logged recovery mode, and then the TABLOCK 
-- hint on the target table of the INSERT…SELECT is a best practice
-- because it causes minimal logging and is therefore much faster.
ALTER DATABASE AdventureWorksDW2012 SET RECOVERY SIMPLE;
GO

-- Copy the data from the FactResellerSales into the new table
INSERT INTO dbo.FactResellerSalesPtnd WITH(TABLOCK)
SELECT * FROM dbo.FactResellerSales;
GO

-- Create the columnstore index
CREATE NONCLUSTERED COLUMNSTORE INDEX [csindx_FactResellerSalesPtnd]
ON [FactResellerSalesPtnd]
( 
    [ProductKey], 
    [OrderDateKey], 
    [DueDateKey], 
    [ShipDateKey], 
    [CustomerKey], 
    [EmployeeKey], 
    [PromotionKey], 
    [CurrencyKey], 
    [SalesTerritoryKey], 
    [SalesOrderNumber], 
    [SalesOrderLineNumber], 
    [RevisionNumber], 
    [OrderQuantity], 
    [UnitPrice], 
    [ExtendedAmount], 
    [UnitPriceDiscountPct], 
    [DiscountAmount], 
    [ProductStandardCost], 
    [TotalProductCost], 
    [SalesAmount], 
    [TaxAmt], 
    [Freight], 
    [CarrierTrackingNumber], 
    [CustomerPONumber], 
    [OrderDate],
    [DueDate],
    [ShipDate]
);

Теперь выполните запрос, который может выиграть от индекса columnstore и подтвердите, что был использован именно индекс columnstore.

Проверка индекса columnstore

Нажмите Ctrl+M или в меню Запрос выберите Включить действительный план выполнения. Это включает графическое представление действительного плана выполнения, используемого средой Среда SQL Server Management Studio.

В редакторе запросов среды выполните следующий запрос.

SELECT SalesTerritoryKey, SUM(ExtendedAmount) AS SalesByTerritory
FROM FactResellerSalesPtnd
GROUP BY SalesTerritoryKey;

В окне Результаты на вкладке План выполнения подтвердите, что план запроса выбрал сканирование некластеризованного индекса csindx_FactResellerSalesPtnd.

Примечание
Дополнительные сведения о значках Showplan см. в разделе Справочник по логическим и физическим операторам Showplan.

В начало

Основы. Типичные сценарии индекса Columnstore

Схемы баз данных типов «звезда» и «снежинка» обычно можно найти в многомерных хранилищах данных и витринах данных, где скорость извлечения данных важна больше, чем производительность обработки данных. Технология columnstore в SQL Server 2012 может обнаруживать и ускорять запросы, нацеленные на схемы типов «звезда» и «снежинка».

Примеры:

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

А. Агрегатный запрос соединения двух таблиц

Рассмотрите запрос типа «звезда», который вычисляет, сколько продукта 215 было продано в каждом квартале. Таблица фактов с именем FactResellerSalesPtnd секционирована по столбцу OrderDateKey. Одна из таблиц измерений с именем DimDate ссылается на таблицу фактов посредством связи «первичный-внешний ключ» в ключе даты.
```
SELECT d.CalendarYear,
    d.CalendarQuarter,
    COUNT(*) AS NumberSold
FROM dbo.FactResellerSalesPtnd AS f
    JOIN dbo.DimDate AS d
    ON f.OrderDateKey = d.DateKey
WHERE ProductKey = 215
GROUP BY d.CalendarYear, d.CalendarQuarter
ORDER BY d.CalendarYear, d.CalendarQuarter;
```

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

Б. Простой агрегатный запрос на одной таблице

Таблица фактов FactResellerSalesPtnd секционированная по столбцу OrderDateKey. Следующий запрос возвращает число строк и число заказов.
```
SELECT COUNT(*) AS NumberOfRows, 
    COUNT(DISTINCT(f.SalesOrderNumber)) AS NumberOfOrders
FROM dbo.FactResellerSalesPtnd AS f;
```
Для типовых запросов сценариев хранилища данных обычно наблюдается повышение скорости в пределах от 1,5 до 10 раз, когда индексы columnstore и режим пакетной обработки используется при выполнении запроса. Для некоторых запросов типа «звезда» ускорение составляет гораздо больше.

Основы. Оптимизации фильтра по битовым картам

Помимо макета данных в формате столбцов, SQL Server использует фильтры по битовым картам, которые передаются в подсистему хранилища для повышения производительности при выполнении запросов. Фильтры по битовым картам повышают скорость выполнении запросов путем снижения числа включаемых строк до внедрения соединений, сокращая тем самым число строк, которые обрабатываются оператором соединения. Битовая карта создается на элементе хэш-соединения, но фактические проверки битовой карты выполняются на стороне пробного входа хэш-соединения. Можно заметить использование фильтра по битовым картам, используя либо графический, либо план выполнения в формате xml.

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

Как создать индекс columnstore

Создание индекса columnstore похоже на создание любого другого индекса. Можно создать индекс columnstore с помощью Transact-SQL или с помощью графических инструментов среды Среда SQL Server Management Studio.

Создание индекса columnstore с помощью Transact-SQL

В редакторе запросов выполните инструкцию CREATE COLUMNSTORE INDEX. См. пример Создание таблицы FactResellerSalesPtnd выше. Дополнительные сведения см. в разделе CREATE COLUMNSTORE INDEX (Transact-SQL).

Создание индекса columnstore с помощью среды Среда SQL Server Management Studio

В среде Среда Management Studio воспользуйтесь обозревателем объектов, чтобы подключиться к экземпляру Компонент SQL Server Database Engine.
В обозревателе объектов разверните экземпляр SQL Server, затем Базы данных, разверните базу данных, разверните таблицу, щелкните ее правой кнопкой мыши, наведите курсор на Новый индекс и выберите Некластеризованный индекс columnstore.
В диалоговом окне Имя индекса на вкладе Общие введите имя нового индекса, после чего щелкните Добавить.
В диалоговом окне Выбор столбцов выберите столбцы для участия в индексе columnstore и нажмите кнопку ОК два раза, чтобы создать индекс.

Как определить размер нового индекса columnstore

Индекс columnstore состоит как из сегментов, так и из словарей. В следующем примере демонстрируется, как определить общий размер индекса columnstore (в таблице FactResellerSalesPtnd), объединив столбцы on_disk_size из представлений sys.column_store_segments и sys.column_store_dictionaries.

SELECT SUM(on_disk_size_MB) AS TotalSizeInMB
FROM
(
   (SELECT SUM(css.on_disk_size)/(1024.0*1024.0) on_disk_size_MB
    FROM sys.indexes AS i
    JOIN sys.partitions AS p
        ON i.object_id = p.object_id 
    JOIN sys.column_store_segments AS css
        ON css.hobt_id = p.hobt_id
    WHERE i.object_id = object_id('FactResellerSalesPtnd') 
    AND i.type_desc = 'NONCLUSTERED COLUMNSTORE') 
  UNION ALL
   (SELECT SUM(csd.on_disk_size)/(1024.0*1024.0) on_disk_size_MB
    FROM sys.indexes AS i
    JOIN sys.partitions AS p
        ON i.object_id = p.object_id 
    JOIN sys.column_store_dictionaries AS csd
        ON csd.hobt_id = p.hobt_id
    WHERE i.object_id = object_id('FactResellerSalesPtnd') 
    AND i.type_desc = 'NONCLUSTERED COLUMNSTORE') 
) AS SegmentsPlusDictionary

Как устранить неполадки производительности индекса columnstore

Чтобы определить, используется ли индекс columnstore, изучите план выполнения запроса. При оптимальной производительности присутствуют три вещи.

индекс columnstore в плане выполнения запроса.

значок оператора индекса columnstore

Если индекс columnstore не используется и предполагается, что он сделает запрос эффективнее, оцените производительность запроса, форсируя использование индекса columnstore с помощью указания WITH (INDEX(<indexname>)). В следующем примере демонстрируется запрос с указанием индекса.
```
SELECT d.CalendarYear,
    d.CalendarQuarter,
    COUNT(*) AS NumberSold
FROM dbo.FactResellerSalesPtnd AS f WITH (INDEX(csindx_FactResellerSalesPtnd))
    JOIN dbo.DimDate AS d
    ON f.OrderDateKey = d.DateKey
WHERE ProductKey = 215
GROUP BY d.CalendarYear, d.CalendarQuarter
ORDER BY d.CalendarYear, d.CalendarQuarter;
```
При перемещении курсора над значком индекса columnstore в графическом плане запроса фактический режим выполнения указан как пакет вместо строки.
Значок физического оператора bitmap присутствует в графическом плане выполнения, указывая, что фильтр по битовым картам уменьшает число строк перед операцией соединения.

значок оператора Bitmap

В начало

Связанные задачи

CREATE COLUMNSTORE INDEX (Transact-SQL)

См. также

sys.column_store_dictionaries (Transact-SQL)

sys.column_store_segments (Transact-SQL)

Индексы columnstore

Содержание

Основы. Описание индексов columnstore

Типы данных

Потенциал для низкой производительности

Основы. Ограничения индекса Columnstore

Демонстрационный пример. Columnstore индексы с секционированной таблицей

Создайте таблицу FactResellerSalesPtnd

Проверка индекса columnstore

Основы. Типичные сценарии индекса Columnstore

Примеры:

А. Агрегатный запрос соединения двух таблиц

Б. Простой агрегатный запрос на одной таблице

Основы. Оптимизации фильтра по битовым картам

Рекомендации. Обновление данных в индексе columnstore

Рекомендации. Выбор столбцов для индекса columnstore

Рекомендации. Секционированные таблицы

Как создать индекс columnstore

Создание индекса columnstore с помощью Transact-SQL

Создание индекса columnstore с помощью среды Среда SQL Server Management Studio

Как определить размер нового индекса columnstore

Как устранить неполадки производительности индекса columnstore

Связанные задачи

См. также

Дополнительные ресурсы