SQL Server n'optimise pas la jointure de fusion parallèle sur deux tables partitionnées de manière équivalente

Toutes mes excuses à l'avance pour la question très détaillée. J'ai inclus des requêtes pour générer un ensemble de données complet pour reproduire le problème et j'exécute SQL Server 2012 sur une machine à 32 cœurs. Cependant, je ne pense pas que cela soit spécifique à SQL Server 2012, et j'ai forcé un MAXDOP de 10 pour cet exemple particulier.

J'ai deux tables qui sont partitionnées en utilisant le même schéma de partition. En les joignant ensemble sur la colonne utilisée pour le partitionnement, j'ai remarqué que SQL Server n'est pas en mesure d'optimiser une jointure de fusion parallèle autant qu'on pourrait s'y attendre et choisit donc d'utiliser à la place un HASH JOIN. Dans ce cas particulier, je suis capable de simuler manuellement un MERGE JOIN parallèle beaucoup plus optimal en divisant la requête en 10 plages disjointes en fonction de la fonction de partition et en exécutant chacune de ces requêtes simultanément dans SSMS. En utilisant WAITFOR pour les exécuter toutes exactement en même temps, le résultat est que toutes les requêtes se terminent en ~ 40% du temps total utilisé par le HASH JOIN parallèle d'origine.

Existe-t-il un moyen pour que SQL Server procède à cette optimisation seul dans le cas de tables partitionnées de manière équivalente? Je comprends que SQL Server peut généralement entraîner beaucoup de surcharge afin de rendre un MERGE JOIN parallèle, mais il semble qu'il existe une méthode de partitionnement très naturelle avec une surcharge minimale dans ce cas. Peut-être s'agit-il simplement d'un cas spécialisé que l'optimiseur n'est pas encore assez intelligent pour reconnaître?

Voici le SQL pour configurer un ensemble de données simplifié afin de reproduire ce problème:

/* 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)

Maintenant, nous sommes enfin prêts à reproduire la requête sous-optimale!

/* 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)

Cependant, l'utilisation d'un seul thread pour traiter chaque partition (exemple pour la première partition ci-dessous) conduirait à un plan beaucoup plus efficace. J'ai testé cela en exécutant une requête comme celle ci-dessous pour chacune des 10 partitions exactement au même moment, et toutes les 10 ont terminé en un peu plus d'une seconde:

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)

Vous avez raison de dire que l'optimiseur SQL Server préfère ne pas générer de MERGEplans de jointure parallèle (cela coûte assez cher cette alternative). Parallèle MERGEnécessite toujours la répartition des échanges sur les deux entrées de jointure, et plus important encore, il nécessite que l'ordre des lignes soit préservé sur ces échanges.

Le parallélisme est plus efficace lorsque chaque thread peut s'exécuter indépendamment; la conservation des ordres conduit souvent à des attentes de synchronisation fréquentes et peut finalement provoquer un débordement des échanges tempdbpour résoudre une condition de blocage intra-requête.

Ces problèmes peuvent être contournés en exécutant plusieurs instances de la requête entière sur un thread chacun, chaque thread traitant une plage exclusive de données. Cependant, ce n'est pas une stratégie que l'optimiseur considère nativement. En l'état, le modèle SQL Server d'origine pour le parallélisme rompt la requête lors des échanges et exécute les segments de plan formés par ces divisions sur plusieurs threads.

Il existe des moyens pour exécuter des plans de requête entiers sur plusieurs threads sur des plages d'ensembles de données exclusives, mais ils nécessitent une ruse qui ne plaira pas à tout le monde (et ne sera pas prise en charge par Microsoft ou garantie de fonctionner à l'avenir). Une telle approche consiste à parcourir les partitions d'une table partitionnée et à confier à chaque thread la tâche de produire un sous-total. Le résultat est le nombre SUMde lignes renvoyé par chaque thread indépendant:

Obtenir des numéros de partition est assez facile à partir des métadonnées:

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;

Nous utilisons ensuite ces nombres pour piloter une jointure corrélée ( APPLY) et la $PARTITIONfonction pour limiter chaque thread au numéro de partition actuel:

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;

Le plan de requête montre une MERGEjointure en cours d'exécution pour chaque ligne du tableau @P. Les propriétés d'analyse d'index en cluster confirment qu'une seule partition est traitée à chaque itération:

Malheureusement, cela n'entraîne qu'un traitement séquentiel en série des partitions. Sur l'ensemble de données que vous avez fourni, mon ordinateur portable à 4 cœurs (hyperthreadé à 8) renvoie le résultat correct en 7 secondes avec toutes les données en mémoire.

Pour que les MERGEsous-plans s'exécutent simultanément, nous avons besoin d'un plan parallèle dans lequel les ID de partition sont répartis sur les threads disponibles ( MAXDOP) et chaque MERGEsous-plan s'exécute sur un seul thread en utilisant les données d'une partition. Malheureusement, l'optimiseur décide fréquemment contre le parallèle MERGEpour des raisons de coût, et il n'existe aucun moyen documenté de forcer un plan parallèle. Il existe une méthode non documentée (et non prise en charge), utilisant l' indicateur de trace 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);

Le plan de requête montre maintenant que les numéros de partition @Psont distribués entre les threads sur une base de round robin. Chaque thread exécute le côté interne de la jointure des boucles imbriquées pour une seule partition, atteignant notre objectif de traitement simultané des données disjointes. Le même résultat est maintenant retourné en 3 secondes sur mes 8 hyper-cœurs, avec les huit à 100% d'utilisation.

Je ne vous recommande pas d'utiliser cette technique nécessairement - voir mes avertissements précédents - mais elle répond à votre question.

Consultez mon article Amélioration des performances de jointure de table partitionnée pour plus de détails.

Columnstore

Étant donné que vous utilisez SQL Server 2012 (et en supposant qu'il s'agit de Enterprise), vous avez également la possibilité d'utiliser un index columnstore. Cela montre le potentiel des jointures de hachage en mode batch où suffisamment de mémoire est disponible:

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

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

Avec ces index en place, la requête ...

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

... entraîne le plan d'exécution suivant de l'optimiseur sans aucune astuce:

Des résultats corrects en 2 secondes , mais l'élimination du traitement en mode ligne pour l'agrégat scalaire aide encore plus:

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 requête de stockage de colonnes optimisée s'exécute en 851 ms .

Geoff Patterson a créé le rapport de bogue Partition Wise Joins mais il a été fermé en tant que Won't Fix.

La façon de faire fonctionner l'optimiseur comme vous le pensez est via des conseils de requête.

Dans ce cas, OPTION (MERGE JOIN)

Ou vous pouvez aller tout le porc et utiliser USE PLAN