Índices de almacén de columnas en clúster y claves externas

Estoy ajustando el rendimiento de un almacén de datos usando índices. Soy bastante nuevo en SQL Server 2014. Microsoft describe lo siguiente:

"Vemos el índice de almacén de columnas en clúster como el estándar para almacenar grandes tablas de hechos de almacenamiento de datos, y esperamos que se use en la mayoría de los escenarios de almacenamiento de datos. Dado que el índice de almacén de columnas en clúster es actualizable, su carga de trabajo puede realizar una gran cantidad de inserción, actualización, y eliminar operaciones ". http://msdn.microsoft.com/en-us/library/gg492088.aspx

Sin embargo, si sigue leyendo la documentación, encontrará limitaciones y restricciones:

"No puede tener restricciones únicas, restricciones de clave principal o restricciones de clave externa".

Esto me confunde mucho! Es una buena práctica (no obligatoria) tener claves externas en el almacén de datos por una variedad de razones (integridad de datos, relaciones visibles para la capa semántica ...)

Por lo tanto, Microsoft aboga por los índices de almacén de columnas agrupados para escenarios de almacenamiento de datos; sin embargo, ¿no puede manejar relaciones de claves externas?

¿Estoy en lo correcto en esto? ¿Qué otros enfoques recomendarías? En el pasado, he usado un índice de almacén de columnas no agrupado en escenarios de almacenamiento de datos, con caída y reconstrucción para cargas de datos. Sin embargo, SQL Server 2014 no agrega ningún valor real nuevo para los almacenes de datos.

Tienes muchas preguntas aquí:

P: (La falta de claves foráneas) me confunde mucho. Es una buena práctica (no obligatoria) tener Fk's en el DWH por una variedad de razones (integridad de datos, relaciones visibles para la capa semántica, ...)

R: Correcto, normalmente es una buena práctica tener claves foráneas en un almacén de datos. Sin embargo, los índices de almacén de columnas agrupados aún no lo admiten.

P: Por lo tanto, MS aboga por los índices de almacén de Columna agrupada para escenarios DWH. ¡Sin embargo, no puede manejar las relaciones FK?

A: Microsoft te da herramientas. Depende de usted cómo usa esas herramientas.

Si su mayor desafío es la falta de integridad de datos en su almacén de datos, entonces la herramienta que desea son las tablas convencionales con claves foráneas.

Si su mayor desafío es el rendimiento de las consultas, y está dispuesto a verificar su propia integridad de datos como parte del proceso de carga, entonces la herramienta que desea son los índices de almacén de columnas agrupados.

P: ¿Sin embargo, SQL 2014 no agrega ningún valor real nuevo para DWH?

R: Afortunadamente, el almacén de columnas en clúster no fue la única característica nueva en SQL Server 2014. Por ejemplo, consulte el nuevo estimador de cardinalidad.

P: ¿Por qué estoy tan enojado y amargado por la forma en que se implementó mi función favorita?

R: Me atrapaste, realmente no hiciste esa pregunta, pero la responderé de todos modos. Bienvenido al mundo del software de terceros, donde no todo está construido de acuerdo con sus especificaciones exactas. Si le apasiona un cambio que le gustaría ver en un producto de Microsoft, consulte Connect.Microsoft.com . Es su proceso de comentarios donde puede enviar un cambio, otras personas pueden votarlo, y luego el equipo del producto lo lee y le dice por qué no lo implementarán. A veces. La mayoría de las veces simplemente lo marcan como "no se arregla, funciona en mi máquina" pero bueno, a veces obtienes algunas respuestas.

Puedo entender que sientes que faltan algunas piezas a las que estás acostumbrado. Pero eso es solo porque faltan.

Sin embargo, SQL Server se estaba utilizando con éxito cuando las claves externas eran solo un concepto (que implementamos a través de desencadenantes en esos días), no una implementación física como una restricción. La integridad referencial declarativa estaba allí al menos por SQL Server 7.0, pero mucho más débil que la implementación actual.

En cuanto al valor del índice ColumnStore agrupado, proporciona un índice y las filas son actualizables. Puede encontrar valiosa esta discusión: http://sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Manoj señala que hay una manera de crear una Vista indexada / materializada en la parte superior de esta tabla, con Clustering Key como PK (primera columna de la tabla / vista). Si eso le conviene, por supuesto, es una decisión que debe tomar.

Pero, como comentaron Aaron Bertrand y TomTom, se trata de un mejor rendimiento. Si puede manejar los otros problemas que le preocupan (y creo que son manejables), obtendrá bastantes beneficios. Por lo tanto, use ColumnStore para lo que puede hacer y administre las características que faltan usted mismo.

Esta pregunta se refiere a SQL 2014, pero quiero proporcionar información adicional a la luz de los cambios realizados en SQL 2016 en los índices de almacén de columnas, ya que puede ser difícil resolver las limitaciones en diferentes versiones y esta pregunta aún es bastante alta en Google:

Para SQL 2016, Microsoft describe un método para usar índices btree no agrupados (que ahora se pueden agregar como índices secundarios en una tabla de almacén de columnas en clúster) para aplicar restricciones de clave externa, siempre que la restricción se agregue antes del índice de almacén de columnas: https: // docs .microsoft.com / es-es / sql / relational-database / indexes / columnastore-indexes-design-guide

Niko Neugebauer también tiene una publicación de blog sobre esto; En realidad, es posible crear restricciones únicas / externas en las tablas del almacén de columnas (he estado aplicando este enfoque en mi trabajo): http://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- more-clustered-columnastore-mejoras-en-sql-server-2016 /