Warum haben Azure Cosmos-Abfragen höhere RUs, wenn der Partitionsschlüssel angegeben wird?

Jan 03 2021

Ich habe eine ähnliche Frage wie diese . Grundsätzlich habe ich verschiedene Möglichkeiten zur Verwendung des Partitionsschlüssels getestet und festgestellt, dass die RUs zu jedem Zeitpunkt umso höher sind, je mehr auf einen Partitionsschlüssel in einer Abfrage verwiesen wird. Es ist ziemlich konsistent und spielt keine Rolle, wie der Partitionsschlüssel verwendet wird. Also habe ich es auf die grundlegenden Testabfragen eingegrenzt.

Zu Beginn enthält diese Datenbank ungefähr 850 KB Dokumente mit einer Größe von mehr als 1 KB. Der Partitionsschlüssel ist im Grunde ein 100-Modul der ID in Zahlenform, wird auf / partitionKey gesetzt und der Container verwendet eine Standardindexierungsrichtlinie:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/\"_etag\"/?"
        }
    ]
}

Hier ist mein grundlegender Abfragetest:

SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.95 RUs
SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.85 RUs

In der Azure Cosmos-Dokumentation heißt es, dass die Abfrage ohne den Partitionsschlüssel auf alle logischen Partitionen " auffächert ". Daher würde ich voll und ganz erwarten, dass die erste Abfrage auf eine einzelne Partition und die zweite auf alle abzielt, was bedeutet, dass die erste eine niedrigere RUs haben sollte. Ich nehme an, ich verwende RU-Ergebnisse als Beweis dafür, ob der Cosmos jede Partition auffächert und scannt, und vergleiche sie mit dem, was in der Dokumentation angegeben ist.

Ich weiß, dass diese Ergebnisse nur 0,1 RU Unterschied sind. Mein Punkt ist jedoch, je komplexer die Abfrage ist, desto größer ist der Unterschied. Hier ist zum Beispiel eine andere Abfrage, die etwas komplexer ist:

SELECT c.id, c.partitionKey
FROM c
WHERE (c.partitionKey = 98 OR c.partitionKey = 99) AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 3.05 RUs

Beachten Sie, dass die RUs weiter wachsen und sich davon trennen, überhaupt keinen Partitionsschlüssel angegeben zu haben. Stattdessen würde ich erwarten, dass die obige Abfrage nur auf zwei Partitionen abzielt, verglichen mit keiner Partitionsschlüsselprüfung, die angeblich auf alle Partitionen verteilt wird.

Ich fange an zu vermuten, dass die Überprüfung des Partitionsschlüssels nach den anderen Filtern (oder innerhalb jedes Partitionsscans) erfolgt. Zurück zur ersten Abfrage, aber Ändern der ID in etwas, das nicht vorhanden ist:

SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs
SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs

Beachten Sie, dass die RUs genau gleich sind und beide (einschließlich der mit dem Partitionsfilter) weniger RUs haben als wenn ein Dokument vorhanden ist. Dies scheint ein Symptom dafür zu sein, dass der Partitionsfilter für die Ergebnisse ausgeführt wird, ohne ein Fan-Out einzuschränken. Dies steht jedoch nicht in der Dokumentation.

Warum hat Cosmos höhere RUs, wenn ein Partitionsschlüssel angegeben wird?

Antworten

3 4c74356b41 Jan 03 2021 at 15:39

Wie der Kommentar angibt, wird das Testen über das Portal (oder über den Code, jedoch mit der von Ihnen angegebenen Abfrage) teurer, da Sie nicht eine bestimmte Partition abfragen, sondern alles abfragen und dann einen weiteren Filter einführen ist mehr Aufwand.

Stattdessen sollten Sie den Partitionsschlüssel auf die richtige Weise im Code übergeben. Mein Ergebnis war ziemlich beeindruckend: 3 Ru \ s mit der PK und 20.000 Ru \ s ohne die PK, daher bin ich ziemlich zuversichtlich, dass Intworks (ich hatte einen wirklich großen Datensatz)