Multiple Row_Number() Llamadas en una única consulta SQL

Question

Estoy intentando configurar algunos datos para calcular varias medianas en SQL Server 2008, pero tengo un problema de rendimiento. En este momento, estoy usando este pattern ([otro ejemplo bottom). Sí, no estoy usando un CTE, pero usar uno no solucionará el problema que estoy teniendo de todos modos y el rendimiento es pobre porque las subconsultas row_numeros se ejecutan en serie, no en paralelo.

Aquí hay un ejemplo completo. Debajo del SQL explico más el problema.

-- build the example table  

CREATE TABLE #TestMedian (
    StateID INT, 
    TimeDimID INT, 
    ConstructionStatusID INT, 

    PopulationSize BIGINT, 
    SquareMiles BIGINT 
); 

INSERT INTO #TestMedian (StateID, TimeDimID, ConstructionStatusID, PopulationSize, SquareMiles) 
VALUES (1, 1, 1, 100000, 200000); 

INSERT INTO #TestMedian (StateID, TimeDimID, ConstructionStatusID, PopulationSize, SquareMiles) 
VALUES (1, 1, 1, 200000, 300000); 

INSERT INTO #TestMedian (StateID, TimeDimID, ConstructionStatusID, PopulationSize, SquareMiles) 
VALUES (1, 1, 1, 300000, 400000); 

INSERT INTO #TestMedian (StateID, TimeDimID, ConstructionStatusID, PopulationSize, SquareMiles) 
VALUES (1, 1, 1, 100000, 200000); 

INSERT INTO #TestMedian (StateID, TimeDimID, ConstructionStatusID, PopulationSize, SquareMiles) 
VALUES (1, 1, 1, 250000, 300000); 

INSERT INTO #TestMedian (StateID, TimeDimID, ConstructionStatusID, PopulationSize, SquareMiles) 
VALUES (1, 1, 1, 350000, 400000); 

--TruNCATE TABLE TestMedian 

    SELECT 
     StateID 
     ,TimeDimID 
     ,ConstructionStatusID 
     ,NumberOfRows = COUNT(*) OVER (PARTITION BY StateID, TimeDimID, ConstructionStatusID) 
     ,PopulationSizeRowNum = ROW_NUMBER() OVER (PARTITION BY StateID, TimeDimID, ConstructionStatusID ORDER BY PopulationSize) 
     ,SquareMilesRowNum = ROW_NUMBER() OVER (PARTITION BY StateID, TimeDimID, ConstructionStatusID ORDER BY SquareMiles) 
     ,PopulationSize 
     ,SquareMiles 
    INTO #MedianData 
    FROM #TestMedian 

    SELECT MinRowNum = MIN(PopulationSizeRowNum), MaxRowNum = MAX(PopulationSizeRowNum), StateID, TimeDimID, ConstructionStatusID, MedianPopulationSize= AVG(PopulationSize) 
    FROM #MedianData T 
    WHERE PopulationSizeRowNum IN((NumberOfRows + 1)/2, (NumberOfRows + 2)/2) 
    GROUP BY StateID, TimeDimID, ConstructionStatusID 

    SELECT MinRowNum = MIN(SquareMilesRowNum), MaxRowNum = MAX(SquareMilesRowNum), StateID, TimeDimID, ConstructionStatusID, MedianSquareMiles= AVG(SquareMiles) 
    FROM #MedianData T 
    WHERE SquareMilesRowNum IN((NumberOfRows + 1)/2, (NumberOfRows + 2)/2) 
    GROUP BY StateID, TimeDimID, ConstructionStatusID 


    DROP TABLE #MedianData 
    DROP TABLE #TestMedian 

El problema con esta consulta es que SQL Server ejecuta tanto de la "ROW__NUMBER() OVER ..." sub-consultas en serie, no en paralelo. Entonces, si tengo 10 de estos cálculos de ROW__NUMBER, los calculará uno después del otro y obtendré un crecimiento lineal, que huele mal. Tengo un sistema de 32 GB de 8 vías Estoy ejecutando esta consulta y me gustaría un poco de paralelismo. Estoy intentando ejecutar este tipo de consulta en una tabla de filas de 5,000,000.

Esto se puede ver mirando el plan de consulta y viendo los Sorts en la misma ruta de ejecución (mostrar el XML del plan de consulta no funcionaría muy bien en SO).

Entonces mi pregunta es esta: ¿Cómo puedo alterar esta consulta para que las consultas ROW_NUMBER se ejecuten en paralelo? ¿Existe una técnica completamente diferente que pueda usar para preparar los datos para cálculos de mediana múltiple?

Answer 1

Cada ROW_NUMBER requiere que las filas se ordenen primero. Dado que sus dos RN tienen diferentes condiciones ORDER BY, la consulta debe producir el resultado, luego ordenarlo para primeros RN (puede ordenarse ya), producir el RN, luego ordenarlo para el segundo RN y producir el segundo resultado de RN. Simplemente no hay polvo mágico de duendes que pueda materializar el valor de un número de fila sin contar dónde está la fila en el orden requerido.

Answer 2

No estoy seguro de que pueda paralelizar esto, porque necesita hacer escaneos no particionados (población vs millas cuadradas). Conflictarán con cada uno en el disco, por lo que tiene que tener todo en la memoria al menos una vez, primero y luego podría ser elegible para la paralelización, si es lo suficientemente grande.

En cualquier caso, el siguiente realiza de forma significativa (40%) más rápido para mí:

;WITH cte AS (
    SELECT 
     StateID 
     ,TimeDimID 
     ,ConstructionStatusID 
     ,NumberOfRows = COUNT(*) OVER (PARTITION BY StateID, TimeDimID, ConstructionStatusID) 
     ,PopulationSizeRowNum = ROW_NUMBER() OVER (PARTITION BY StateID, TimeDimID, ConstructionStatusID ORDER BY PopulationSize) 
     ,SquareMilesRowNum = ROW_NUMBER() OVER (PARTITION BY StateID, TimeDimID, ConstructionStatusID ORDER BY SquareMiles) 
     ,PopulationSize 
     ,SquareMiles 
    FROM TestMedian 
) 
, ctePop AS (
    SELECT MinPopNum = MIN(PopulationSizeRowNum) 
    , MaxPopNum = MAX(PopulationSizeRowNum) 
    , StateID, TimeDimID, ConstructionStatusID 
    , MedianPopulationSize= AVG(PopulationSize) 
    FROM cte T 
    WHERE PopulationSizeRowNum IN((NumberOfRows + 1)/2, (NumberOfRows + 2)/2) 
    GROUP BY StateID, TimeDimID, ConstructionStatusID 
) 
, cteSqM AS (
    SELECT MinSqMNum = MIN(SquareMilesRowNum) 
    , MaxSqMNum = MAX(SquareMilesRowNum) 
    , StateID, TimeDimID, ConstructionStatusID 
    , MedianSquareMiles= AVG(SquareMiles) 
    FROM cte T 
    WHERE SquareMilesRowNum IN((NumberOfRows + 1)/2, (NumberOfRows + 2)/2) 
    GROUP BY StateID, TimeDimID, ConstructionStatusID 
) 
SELECT s.StateID, s.TimeDimID, s.ConstructionStatusID 
, MinPopNum, MaxPopNum, MedianPopulationSize 
, MinSqMNum, MaxSqMNum, MedianSquareMiles 
FROM ctePop p 
JOIN cteSqM s ON s.StateID = p.StateID 
    AND s.TimeDimID = p.TimeDimID 
    AND s.ConstructionStatusID = p.ConstructionStatusID 

Además, los mismos tipos hay que dejarse paralelizados una vez que llegan lo suficientemente grande. Sin embargo, necesitará filas de prueba al menos 100.000 antes de que eso suceda.

---

OK, sí, consigo paralelismo después de lo cargo suficiente con esta declaración:

INSERT INTO TestMedian 
SELECT abs(id)%3,abs(id)%2,abs(id)%5, abs(id), colid * 10000 
    From master.sys.syscolumns, (select top 10 * from master.dbo.spt_values)a 

Answer 3

Algunos pensamiento lateral: Si necesita estos datos a menudo y/o rápidamente, y los datos subyacentes el conjunto no cambia con frecuencia (para valores razonablemente altos de "con frecuencia"), ¿podría precalcular cualquiera de estos valores y almacenarlos en algún tipo de tabla agregada previamente?

(Sí, esto es demonormalization, pero si usted necesita un rendimiento por encima de todo, vale la pena considerar.)