Perché le query di Azure Cosmos hanno RU superiori quando si specifica la chiave di partizione?
Ho una domanda simile a questa . Fondamentalmente, ho testato diversi modi per utilizzare la chiave di partizione e ho notato che in qualsiasi momento, più si fa riferimento a una chiave di partizione in una query, maggiori sono le RU. È abbastanza coerente e non importa nemmeno come viene utilizzata la chiave di partizione. Quindi l'ho ristretto alle query di base per il test.
Per iniziare, questo database contiene circa 850.000 documenti, tutti di dimensioni superiori a 1 KB. La chiave di partizione è fondamentalmente un modulo 100 dell'id in forma numerica, è impostata su / partitionKey e il contenitore utilizza una politica di indicizzazione predefinita:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/\"_etag\"/?"
}
]
}
Ecco il mio test di query di base:
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
La documentazione di Azure Cosmos dice che senza la chiave di partizione, la query "si espanderà " su tutte le partizioni logiche. Pertanto, mi aspetto che la prima query abbia come destinazione una singola partizione e la seconda come destinazione tutte, il che significa che la prima dovrebbe avere RU inferiori. Suppongo di utilizzare i risultati RU come prova per stabilire se il Cosmos sta aprendo a ventaglio e scansionando ogni partizione e confrontandolo con ciò che la documentazione dice che dovrebbe accadere.
So che questi risultati sono solo 0,1 RU di differenza. Ma il punto è che più complessa è la query, maggiore è la differenza. Ad esempio, ecco un'altra query leggermente più complessa:
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
Notare che le RU continuano a crescere e separarsi dall'aver specificato una chiave di partizione. Invece mi aspetterei che la query di cui sopra miri solo a due partizioni, rispetto a nessun controllo della chiave di partizione che presumibilmente si apre a tutte le partizioni.
Comincio a sospettare che il controllo della chiave di partizione avvenga dopo gli altri filtri (o all'interno di ogni scansione della partizione). Ad esempio, tornando alla prima query ma cambiando l'id in qualcosa che non esiste:
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
Notare che le RU sono esattamente le stesse ed entrambe (inclusa quella con il filtro di partizione) hanno meno RU rispetto a quando esiste un documento. Sembra che sarebbe un sintomo del filtro di partizione eseguito sui risultati, non limitando un fan-out. Ma questo non è ciò che dice la documentazione.
Perché Cosmos ha RU superiori quando viene specificata una chiave di partizione?
Risposte
come il commento specifica se stai testando tramite il portale (o tramite il codice, ma con la query che hai fornito) diventerà più costoso, perché non stai interrogando una partizione specifica, ma piuttosto interrogando tutto e quindi introducendo un altro filtro, che è più costoso.
quello che dovresti fare invece - è usare il modo corretto nel codice per passare la chiave di partizione. il mio risultato è stato piuttosto impressionante: 3 ru \ s con il PK e 20.000 ru \ s senza il PK, quindi sono abbastanza fiducioso nel lavoro (ho avuto un set di dati davvero grande)