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

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

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

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

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

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

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

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

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

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 . Это процесс обратной связи, в котором вы можете отправить изменение, другие люди могут проголосовать за него, а затем команда разработчиков прочитает его и скажет вам, почему они не будут его реализовывать. Иногда. В большинстве случаев они просто помечают его как «не исправит, работает на моей машине», но, эй, иногда вы получаете ответы на некоторые вопросы.

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

Тем не менее, 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 для того, что в состоянии сделать, и управляйте отсутствующими функциями самостоятельно.

Этот вопрос относится к 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 /