¿Cuál es la anatomía de un índice de almacén de columnas?

Una de las nuevas características en SQL Server 2012 con nombre en código Denalies el índice Columnstore.

Sé bastante sobre los índices antiguos de almacenes de filas, como la estructura del árbol b, las diferencias de almacenamiento entre el nivel de hoja y las páginas del árbol b, los efectos de los campos incluidos, la optimización para usarlos, el orden de las claves, etc.

Tengo dificultades para obtener buena información sobre las partes internas de un índice de almacén de columnas.

¿Cómo está estructurado?
¿Hay un árbol b? Alguna otra estructura en su lugar?
¿Cómo se organizan los datos?
¿Qué tipo de operadores específicos son los más adecuados para usarlo?
¿Algún otro antipatrón que se debe evitar al usarlos?

Mucho de lo que puedo descubrir sobre ellos es básicamente exactamente lo opuesto a un índice "normal", es decir, sin ordenar claves, sin campos incluidos, SOLO sin agrupar.

Cualquier idea es apreciada.

— JNK
fuente

Hay bastante fanfarria sobre las implementaciones técnicas de las bases de datos del almacén de columnas en la página de wikipedia. Me imagino que el índice es solo una estructura de datos de almacenamiento de columna para una sola columna junto con sus claves. Tal vez use un índice de mapa de bits, tal vez un BTree.

— Preocupado por

En realidad es para múltiples columnas. También supongo que con otras implementaciones de SS será un poco diferente a otros productos

— JNK

Para MySQL pero se aplica lo mismo: developer.bazaarvoice.com/why-columns-are-cool También Sybase IQ es el gran papá

— gbn

@ConcernedOfTunbridgeWells: ¿los índices de almacén de columnas usan índices de mapa de bits? No. Los índices del almacén de columnas usan una representación de datos patentada basada en Vertipaq. No es lo mismo que un índice de mapa de bits y no usa uno. Pero tiene algunos beneficios similares a los índices de mapa de bits, como la reducción del tiempo que lleva filtrar en una columna con un pequeño número de valores distintos.

— Martin Smith

Remus Rusanu, miembro del equipo de Microsoft que desarrolló esta característica, acaba de publicar un artículo sobre esto: Dentro de los índices de COLUMNSTORE de SQL Server 2012

— Nick Chammas

Estructura del almacén de columnas

Los datos del almacén de columnas se almacenan físicamente en uno o más segmentos (unidades de asignación de LOB regulares) por columna, y también se pueden particionar de la manera habitual. Cada segmento contiene aproximadamente un millón de filas de valores altamente comprimidos o referencias de valores (varias técnicas de compresión están disponibles). Una referencia de valor enlaza a una entrada en uno de hasta dos diccionarios hash .

Los diccionarios se fijan en la memoria durante la ejecución de la consulta, y las ID de los valores de datos del segmento se buscan en el diccionario cada vez que la ejecución requiere el valor de datos real (esta búsqueda se difiere el mayor tiempo posible por razones de rendimiento).

Los segmentos también tienen un registro de encabezado que contiene metadatos, como los valores mínimos y máximos almacenados en el segmento. La información del encabezado a menudo se puede usar para eliminar particiones completas del procesamiento en el momento de la ejecución. La información de registro de encabezado se almacena en la estructura raíz de datos LOB habitual, por lo que eliminar un segmento significa que Storage Engine puede omitir por completo la lectura de las páginas de datos LOB del almacenamiento físico. Maximizar el potencial de eliminación puede requerir un diseño cuidadoso , incluida una dependencia del orden del índice agrupado en el momento en que se crea el índice Columnstore.

Operadores de planes específicos

SQL Server 2012 presenta un nuevo modo de ejecución llamado Modo por lotes. En este modo, se pasan paquetes de aproximadamente 1000 filas entre operadores, lo que mejora significativamente la eficiencia de utilización del procesador. Dentro de cada paquete, los datos en columna se representan como un vector. No todos los operadores de planes admiten la operación en modo por lotes, pero ejemplos de los que sí incluyen Columnstore Index Scan, Hash Inner Join, Batch Hash Table Build, Bitmap Filter, Hash Aggregate (no escalar agregados), Filter y Compute Scalar (para proyección y expresión) evaluación). Los planes de ejecución de consultas se han mejorado para mostrar el modo de ejecución estimado y real.

Antipatrones

Hay una gran cantidad de restricciones en la primera versión, incluidas las restricciones sobre los tipos de datos permitidos . Se admiten los tipos más comunes; tipos de datos no soportados incluyen DECIMALcon una mayor precisión de 18 dígitos, (N)VARCHAR(MAX), UNIQUEIDENTIFIER, tipos CLR, y (VAR)BINARY.

El uso de tipos de cadena , OUTER JOIN, IN,EXISTS , NOT IN, OR, UNION ALLpuede resultar en un rendimiento reducido significativamente (Fila ejecución Mode), a menos que se emplean soluciones que implican típicamente reescrituras de sintaxis inusual como se muestra en los artículos vinculados en esta sección.

Más información

Remus Rusanu ha publicado en el blog una gran descripción aquí .

— Paul White
fuente