SQL Server no optimiza la combinación de combinación paralela en dos tablas con particiones equivalentes

Disculpas de antemano por la pregunta muy detallada. He incluido consultas para generar un conjunto de datos completo para reproducir el problema, y ​​estoy ejecutando SQL Server 2012 en una máquina de 32 núcleos. Sin embargo, no creo que esto sea específico de SQL Server 2012, y he forzado un MAXDOP de 10 para este ejemplo en particular.

Tengo dos tablas que están particionadas usando el mismo esquema de partición. Al unirlos en la columna utilizada para la partición, noté que SQL Server no puede optimizar una combinación de fusión paralela tanto como uno podría esperar y, por lo tanto, elige usar una UNIÓN HASH. En este caso particular, puedo simular manualmente una MERGE JOIN paralela mucho más óptima dividiendo la consulta en 10 rangos disjuntos basados ​​en la función de partición y ejecutando cada una de esas consultas simultáneamente en SSMS. Usando WAITFOR para ejecutarlos todos al mismo tiempo, el resultado es que todas las consultas se completan en ~ 40% del tiempo total utilizado por la HASH JOIN paralela original.

¿Hay alguna manera de hacer que SQL Server haga esta optimización por sí solo en el caso de tablas con particiones equivalentes? Entiendo que SQL Server generalmente puede incurrir en una sobrecarga para hacer que MERGE JOIN sea paralelo, pero parece que hay un método de fragmentación muy natural con una sobrecarga mínima en este caso. ¿Quizás es solo un caso especializado que el optimizador aún no es lo suficientemente inteligente como para reconocerlo?

Aquí está el SQL para configurar un conjunto de datos simplificado para reproducir este problema:

/* Create the first test data table */
CREATE TABLE test_transaction_properties 
    ( transactionID INT NOT NULL IDENTITY(1,1)
    , prop1 INT NULL
    , prop2 FLOAT NULL
    )

/* Populate table with pseudo-random data (the specific data doesn't matter too much for this example) */
;WITH E1(N) AS (
    SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 
    UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1
)
, E2(N) AS (SELECT 1 FROM E1 a CROSS JOIN E1 b)
, E4(N) AS (SELECT 1 FROM E2 a CROSS JOIN E2 b)
, E8(N) AS (SELECT 1 FROM E4 a CROSS JOIN E4 b)
INSERT INTO test_transaction_properties WITH (TABLOCK) (prop1, prop2)
SELECT TOP 10000000 (ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) % 5) + 1 AS prop1
                , ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) * rand() AS prop2
FROM E8

/* Create the second test data table */
CREATE TABLE test_transaction_item_detail
    ( transactionID INT NOT NULL
    , productID INT NOT NULL
    , sales FLOAT NULL
    , units INT NULL
    )

 /* Populate the second table such that each transaction has one or more items
     (again, the specific data doesn't matter too much for this example) */
INSERT INTO test_transaction_item_detail WITH (TABLOCK) (transactionID, productID, sales, units)
SELECT t.transactionID, p.productID, 100 AS sales, 1 AS units
FROM test_transaction_properties t
JOIN (
    SELECT 1 as productRank, 1 as productId
    UNION ALL SELECT 2 as productRank, 12 as productId
    UNION ALL SELECT 3 as productRank, 123 as productId
    UNION ALL SELECT 4 as productRank, 1234 as productId
    UNION ALL SELECT 5 as productRank, 12345 as productId
) p
    ON p.productRank <= t.prop1

/* Divides the transactions evenly into 10 partitions */
CREATE PARTITION FUNCTION [pf_test_transactionId] (INT)
AS RANGE RIGHT
FOR VALUES
(1,1000001,2000001,3000001,4000001,5000001,6000001,7000001,8000001,9000001)

CREATE PARTITION SCHEME [ps_test_transactionId]
AS PARTITION [pf_test_transactionId]
ALL TO ( [PRIMARY] )

/* Apply the same partition scheme to both test data tables */
ALTER TABLE test_transaction_properties
ADD CONSTRAINT PK_test_transaction_properties
PRIMARY KEY (transactionID)
ON ps_test_transactionId (transactionID)

ALTER TABLE test_transaction_item_detail
ADD CONSTRAINT PK_test_transaction_item_detail
PRIMARY KEY (transactionID, productID)
ON ps_test_transactionId (transactionID)

¡Ahora finalmente estamos listos para reproducir la consulta subóptima!

/* This query produces a HASH JOIN using 20 threads without the MAXDOP hint,
    and the same behavior holds in that case.
    For simplicity here, I have limited it to 10 threads. */
SELECT COUNT(*)
FROM test_transaction_item_detail i
JOIN test_transaction_properties t
    ON t.transactionID = i.transactionID
OPTION (MAXDOP 10)

Sin embargo, el uso de un solo hilo para procesar cada partición (ejemplo para la primera partición a continuación) conduciría a un plan mucho más eficiente. Probé esto ejecutando una consulta como la siguiente para cada una de las 10 particiones exactamente en el mismo momento, y las 10 terminaron en poco más de 1 segundo:

SELECT COUNT(*)
FROM test_transaction_item_detail i
INNER MERGE JOIN test_transaction_properties t
    ON t.transactionID = i.transactionID
WHERE t.transactionID BETWEEN 1 AND 1000000
OPTION (MAXDOP 1)

Tiene razón en que el optimizador de SQL Server prefiere no generar MERGEplanes de unión en paralelo (esta alternativa cuesta bastante). Paralelo MERGEsiempre requiere intercambiar reparticiones en ambas entradas de unión y, lo que es más importante, requiere que se mantenga el orden de las filas en esos intercambios.

El paralelismo es más eficiente cuando cada hilo puede ejecutarse independientemente; la preservación del pedido a menudo conduce a esperas de sincronización frecuentes y, en última instancia, puede provocar que los intercambios se derramen tempdbpara resolver una condición de punto muerto intraconsulta.

Estos problemas se pueden eludir ejecutando múltiples instancias de la consulta completa en un hilo cada uno, con cada hilo procesando un rango exclusivo de datos. Sin embargo, esta no es una estrategia que el optimizador considere de forma nativa. Tal como están las cosas, el modelo original de SQL Server para el paralelismo interrumpe la consulta en los intercambios y ejecuta los segmentos del plan formados por esas divisiones en varios subprocesos.

Hay formas de lograr ejecutar planes de consulta completos en múltiples subprocesos sobre rangos de conjuntos de datos exclusivos, pero requieren trucos con los que no todos estarán contentos (y Microsoft no los respaldará ni garantizará que funcionen en el futuro). Uno de estos enfoques es iterar sobre las particiones de una tabla particionada y asignar a cada subproceso la tarea de producir un subtotal. El resultado es el SUMrecuento de filas devuelto por cada subproceso independiente:

Obtener números de partición es bastante fácil a partir de metadatos:

DECLARE @P AS TABLE
(
    partition_number integer PRIMARY KEY
);

INSERT @P (partition_number)
SELECT
    p.partition_number
FROM sys.partitions AS p 
WHERE 
    p.[object_id] = OBJECT_ID(N'test_transaction_properties', N'U')
    AND p.index_id = 1;

Luego usamos estos números para conducir una unión correlacionada ( APPLY), y la $PARTITIONfunción para limitar cada hilo al número de partición actual:

SELECT
    row_count = SUM(Subtotals.cnt)
FROM @P AS p
CROSS APPLY
(
    SELECT
        cnt = COUNT_BIG(*)
    FROM dbo.test_transaction_item_detail AS i
    JOIN dbo.test_transaction_properties AS t ON
        t.transactionID = i.transactionID
    WHERE 
        $PARTITION.pf_test_transactionId(t.transactionID) = p.partition_number
        AND $PARTITION.pf_test_transactionId(i.transactionID) = p.partition_number
) AS SubTotals;

El plan de consulta muestra una MERGEunión que se realiza para cada fila de la tabla @P. Las propiedades de exploración de índice agrupado confirman que solo se procesa una única partición en cada iteración:

Desafortunadamente, esto solo da como resultado un procesamiento secuencial en serie de particiones. En el conjunto de datos que proporcionó, mi computadora portátil de 4 núcleos (hiperprocesado a 8) devuelve el resultado correcto en 7 segundos con todos los datos en la memoria.

Para que los MERGEsubplanes se ejecuten simultáneamente, necesitamos un plan paralelo en el que los identificadores de partición se distribuyan entre los subprocesos disponibles ( MAXDOP) y cada MERGEsubplan se ejecute en un solo subproceso utilizando los datos en una partición. Desafortunadamente, el optimizador con frecuencia decide contra el paralelo MERGEpor razones de costos, y no existe una forma documentada de forzar un plan paralelo. Hay una forma no documentada (y no compatible), utilizando el indicador de traza 8649 :

SELECT
    row_count = SUM(Subtotals.cnt)
FROM @P AS p
CROSS APPLY
(
    SELECT
        cnt = COUNT_BIG(*)
    FROM dbo.test_transaction_item_detail AS i
    JOIN dbo.test_transaction_properties AS t ON
        t.transactionID = i.transactionID
    WHERE 
        $PARTITION.pf_test_transactionId(t.transactionID) = p.partition_number
        AND $PARTITION.pf_test_transactionId(i.transactionID) = p.partition_number
) AS SubTotals
OPTION (QUERYTRACEON 8649);

Ahora, el plan de consulta muestra que los números de partición @Pse distribuyen entre subprocesos en una operación por turnos. Cada subproceso ejecuta el lado interno de la unión de bucles anidados para una única partición, logrando nuestro objetivo de procesar datos disjuntos simultáneamente. El mismo resultado ahora se devuelve en 3 segundos en mis 8 hiper-núcleos, con los ocho al 100% de utilización.

No le recomiendo que use esta técnica necesariamente (consulte mis advertencias anteriores), pero responde a su pregunta.

Consulte mi artículo Mejora del rendimiento de la unión de tabla particionada para obtener más detalles.

Almacén de columnas

Al ver que está utilizando SQL Server 2012 (y suponiendo que sea Enterprise), también tiene la opción de usar un índice de almacén de columnas. Esto muestra el potencial de las combinaciones hash en modo por lotes donde hay suficiente memoria disponible:

CREATE NONCLUSTERED COLUMNSTORE INDEX cs 
ON dbo.test_transaction_properties (transactionID);

CREATE NONCLUSTERED COLUMNSTORE INDEX cs 
ON dbo.test_transaction_item_detail (transactionID);

Con estos índices en su lugar, la consulta ...

SELECT
    COUNT_BIG(*)
FROM dbo.test_transaction_properties AS ttp
JOIN dbo.test_transaction_item_detail AS ttid ON
    ttid.transactionID = ttp.transactionID;

... da como resultado el siguiente plan de ejecución desde el optimizador sin ningún truco:

Resultados correctos en 2 segundos , pero eliminar el procesamiento en modo fila para el agregado escalar ayuda aún más:

SELECT
    COUNT_BIG(*)
FROM dbo.test_transaction_properties AS ttp
JOIN dbo.test_transaction_item_detail AS ttid ON
    ttid.transactionID = ttp.transactionID
GROUP BY
    ttp.transactionID % 1;

La consulta optimizada del almacén de columnas se ejecuta en 851 ms .

Geoff Patterson creó el informe de errores Partition Wise Joins, pero se cerró como No soluciona.

La forma de hacer que el optimizador funcione de la manera que usted piensa mejor es a través de sugerencias de consulta.

En este caso, OPTION (MERGE JOIN)

O puedes ir todo el cerdo y usar USE PLAN