Я прочитал (здесь, здесь и здесь) о кластеризованных индексах columnstore, представленных в SQL Server 2014. По сути, сейчас:
- Индексы хранилища столбцов можно обновлять
- Схема таблицы может быть изменена (без индексов хранилища отбрасываемых столбцов)
- Структура базовой таблицы может быть столбчатой.
- Экономия места за счет эффектов сжатия (с индексом хранилища столбцов можно сэкономить от 40 до 50 процентов начального пространства, используемого для таблицы)
Кроме того, они поддерживают:
- Строчный режим и обработка в пакетном режиме
- Оператор BULK INSERT
- Больше типов данных
Как я понял, есть некоторые ограничения, например:
- Неподдерживаемые типы данных
- Другие индексы не могут быть созданы
Но как сказано:
С кластеризованным индексом хранилища столбцов уже охвачены все возможности фильтрации; Обработчик запросов, использующий исключение сегментов, сможет рассматривать только те сегменты, которые требуются в предложениях запроса. В столбцах, где нельзя применить исключение сегмента, все проверки будут быстрее, чем сканирование индекса B-Tree, потому что данные сжимаются, поэтому потребуется меньше операций ввода-вывода.
Меня интересует следующее:
- Говорит ли приведенное выше утверждение, что кластерный индекс хранилища столбцов всегда лучше для извлечения данных, чем индекс B-Tree, когда существует много повторяющихся значений?
- Как насчет производительности между кластеризованным индексом хранилища столбцов и некластеризованным индексом B-Tree
covering
, например, когда в таблице много столбцов? - Могу ли я использовать комбинацию кластеризованных и некластеризованных индексов columnstores в одной таблице?
- И, что наиболее важно, может ли кто-нибудь сказать, как определить, является ли таблица подходящим кандидатом на роль хранимого индекса с колонками?
Говорят, что лучшими кандидатами являются таблицы, для которых операции обновления / удаления / вставки выполняются нечасто. Например, у меня есть таблица с размером хранилища более 17 ГБ (около 70 миллионов строк), и новые записи постоянно вставляются и удаляются. С другой стороны, выполняется множество запросов с использованием его столбцов. Или у меня есть таблица с размером хранилища около 40 ГБ (около 60 миллионов строк) с множеством вставок, выполняемых каждый день - она не запрашивается часто, но я хочу уменьшить ее размер.
Я знаю, что ответ в основном заключается в проведении производственных тестов, но перед этим мне нужно выбрать лучших кандидатов.