Кластерные индексы хранилища столбцов и внешние ключи


18

Я настраиваю производительность хранилища данных, используя индексы. Я довольно новичок в SQL Server 2014. Microsoft описывает следующее:

«Мы рассматриваем кластеризованный индекс columnstore как стандарт для хранения больших таблиц фактов хранилища данных и ожидаем, что он будет использоваться в большинстве сценариев хранилища данных. Поскольку кластеризованный индекс columnstore является обновляемым, ваша рабочая нагрузка может выполнять большое количество операций вставки, обновления, и удалить операции. " http://msdn.microsoft.com/en-us/library/gg492088.aspx

Однако, если вы будете читать дальше в документации, вы найдете под ограничениями и ограничениями:

«Не может быть уникальных ограничений, ограничений первичного ключа или ограничений внешнего ключа».

Это меня сильно смущает! Рекомендуется (не обязательно) иметь внешние ключи в хранилище данных по разным причинам (целостность данных, отношения, видимые для семантического уровня ...)

Поэтому Microsoft поддерживает кластерные индексы хранилища столбцов для сценариев хранилища данных; тем не менее, он не может справиться с отношениями внешнего ключа ?!

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


По мере развития функции вы увидите, что все больше и больше этих функций становятся поддерживаемыми (черт возьми, в 2012 году индексы columnstore были только для чтения!). В то же время вам предлагается компромисс - отличная производительность с ограничениями или такая же старая, такая же старая. Я также не думаю, что они предполагали, что это означает, что каждая таблица в вашем DW должна иметь кластеризованные индексы columnstore и что никакие таблицы не должны иметь каких-либо ограничений - вероятно, в любом DW есть ограниченное количество таблиц, что дало бы вам огромный удар по бакс.
Аарон Бертран

3
Осторожно - он может справиться с соединениями. Отношения ФК совершенно не нужны для объединения. Он предназначен для обработки ссылочной целостности - это приятно иметь, но в хранилище данных МОЖЕТ быть опущено. С риском, да, но также с увеличением производительности.
TomTom

8
Кроме того - "нет реальной новой стоимости"? Ты имеешь в виду, что возможность записи и кластеризации не звучит для тебя как улучшение? Предоставление пользователям возможности запрашивать данные в режиме реального времени вместо того, чтобы ждать отбрасывания и перестроения для получения более актуальных данных, не кажется хорошей вещью для ваших пользователей и требует меньшего количества обслуживания? пожимает плечами
Аарон Бертран

Вы можете иметь (уникальные) индексы, создав индексированное представление. Кажется, инфраструктура для ведения индекса уже существует. Просто нормальные индексы (пока) не реализованы.
USR

@AaronBertrand В сценарии DWH с таблицами фактов с внешним ключом индекс Clustered Columnstore не работает. Это в целом контрастирует с тем, что Microsoft ожидает, что в качестве стандарта будут храниться большие таблицы фактов. Я надеюсь, что вы можете доказать, что я не прав ...? Потому что мне нравится SQL Server.
OverflowStack

Ответы:


13

У вас есть много вопросов здесь:

Q: (отсутствие внешних ключей) меня сильно смущает! Хорошей практикой (не обязательно) иметь Fk в DWH по разным причинам (целостность данных, отношения, видимые для семантического уровня, ....)

Ответ: Правильно, обычно рекомендуется иметь внешние ключи в хранилище данных. Однако кластерные индексы columnstore пока не поддерживают это.

Q: Таким образом, MS поддерживает индексы хранилища Clustered Column для сценариев DWH, однако она не может обрабатывать отношения FK ?!

A: Microsoft предоставляет вам инструменты. Это зависит от вас, как вы используете эти инструменты.

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

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

Q: Однако SQL 2014 не добавляет реального нового значения для DWH ??

Ответ: К счастью, кластерное хранилище столбцов было не единственной новой функцией в SQL Server 2014. Например, ознакомьтесь с новой оценкой количества элементов.

В: Почему я так зол и горько из-за того, как реализована моя любимая функция?

A: Вы поймали меня - вы на самом деле не задавали этот вопрос - но я все равно отвечу на него. Добро пожаловать в мир стороннего программного обеспечения, где не все построено в соответствии с вашими требованиями. Если вы с энтузиазмом относитесь к изменениям, которые хотели бы увидеть в продукте Microsoft, посетите Connect.Microsoft.com . Это процесс обратной связи, в котором вы можете отправить изменение, другие люди могут проголосовать за него, а затем команда разработчиков прочитает его и скажет вам, почему они не будут его реализовывать. Иногда. В большинстве случаев они просто помечают его как «не исправит, работает на моей машине», но, эй, иногда вы получаете ответы на некоторые вопросы.


«Правильно, обычно рекомендуется иметь внешние ключи в хранилище данных» -> SQLCAT - 10 лучших рекомендаций по созданию крупномасштабного реляционного хранилища данных ... «Создавать некластеризованные индексы для каждого внешнего ключа». -> Ничего об обязательном соблюдении отношения FK, упомянутого в ссылке, и не-CI является избыточным из-за columnstore, поэтому вы бы согласились, что нет необходимости в FK в таблице фактов? Интересуют ваши мысли по этому поводу.
Адриан Торри

1
... и для измерений: "Избегайте принудительного применения отношений внешнего ключа между таблицами фактов и измерений, чтобы обеспечить более быструю загрузку данных. Вы можете создавать ограничения внешнего ключа с помощью NOCHECK для документирования отношений; но не применять их. Обеспечивать целостность данных хотя Transform Lookups или выполнять проверки целостности данных в источнике данных "
Адриан Торри

6

Я могу понять, что вы чувствуете, что некоторые части, к которым вы привыкли, отсутствуют. Но это только потому, что они отсутствуют.

Тем не менее, SQL Server успешно использовался, когда внешние ключи были просто концепцией (которую мы реализовывали с помощью триггеров в те дни), а не физической реализацией, такой как ограничение. Декларативная ссылочная целостность существовала, по крайней мере, в SQL Server 7.0, но намного слабее, чем текущая реализация.

Что касается значения Clustered ColumnStore Index, оно предоставляет индекс, и строки могут быть обновлены. Вы можете найти это обсуждение ценным: http://sqlwithmanoj.com/2014/07/24/maintenance-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Маной указывает, что есть способ создать индексированное / материализованное представление поверх этой таблицы с ключом кластеризации в качестве PK (1-й столбец таблицы / представления). Разумеется, то, что вам подходит, - это решение, которое вы должны принять.

Но, как прокомментировали Аарон Бертран и TomTom, это все о лучшей производительности. Если вы можете управлять и другими вопросами , которые волнуют вас (и я считаем , что они являются управляемыми) , то вы получите немало преимуществ. Так что используйте ColumnStore для того, что в состоянии сделать, и управляйте отсутствующими функциями самостоятельно.


2

Этот вопрос относится к SQL 2014, но я хочу предоставить дополнительную информацию в свете изменений, внесенных в SQL 2016, в индексы columnstore, поскольку может быть трудно разобраться с ограничениями в разных версиях, и этот вопрос все еще остается довольно высоким в Google:

Для SQL 2016 Microsoft описывает метод использования некластеризованных индексов btree (которые теперь можно добавлять в качестве вторичных индексов в кластеризованной таблице columnstore) для принудительного применения ограничений внешнего ключа при условии, что ограничение добавлено до индекса columnstore: https: // docs .microsoft.com / EN-US / SQL / реляционные базы данных / индексы / columnstore-индексы-дизайн-руководство

Нико Нойгебауэр также имеет пост в блоге об этом; на самом деле можно напрямую создавать уникальные / внешние ограничения для таблиц columnstore (я применяю этот подход в своей работе): http://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- более кластерные-columnstore-улучшения-в-SQL-Server-2016 /

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.