Por que as consultas do Azure Cosmos têm RUs mais altas ao especificar a chave de partição?

Jan 03 2021

Eu tenho uma pergunta semelhante a esta . Basicamente, tenho testado diferentes maneiras de usar a chave de partição e percebi que, a qualquer momento, quanto mais uma chave de partição é referenciada em uma consulta, maiores são as RUs. É bastante consistente e não importa como a chave de partição é usada. Então, eu reduzi para as consultas básicas para teste.

Para começar, este banco de dados tem cerca de 850 mil documentos, todos com mais de 1 KB de tamanho. A chave de partição é basicamente um módulo de 100 do id em forma de número, é definida como / partitionKey e o contêiner usa uma política de indexação padrão:

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

Aqui está meu teste básico de consulta:

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

A documentação do Azure Cosmos diz que sem a chave de partição, a consulta "se espalhará " para todas as partições lógicas. Portanto, eu esperaria que a primeira consulta visasse uma única partição e a segunda visasse todas elas, o que significa que a primeira deve ter RUs mais baixos. Suponho que estou usando os resultados do RU como evidência para saber se o Cosmos está se espalhando e examinando cada partição e comparando com o que a documentação diz que deve acontecer.

Eu sei que esses resultados têm apenas 0,1 RUs de diferença. Mas meu ponto é que quanto mais complexa a consulta, maior a diferença. Por exemplo, aqui está outra consulta um pouco mais complexa:

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

Observe que as RUs continuam a crescer e se separar de não terem especificado uma chave de partição. Em vez disso, eu esperaria que a consulta acima visasse apenas duas partições, em comparação com nenhuma verificação de chave de partição que supostamente se espalha para todas as partições.

Estou começando a suspeitar que a verificação da chave de partição está acontecendo após os outros filtros (ou dentro de cada verificação de partição). Por exemplo, voltando à primeira consulta, mas alterando o id para algo que não existe:

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

Observe que as RUs são exatamente as mesmas e ambos (incluindo aquela com o filtro de partição) têm menos RUs do que quando existe um documento. Isso parece ser um sintoma do filtro de partição sendo executado nos resultados, não restringindo um fan-out. Mas não é isso que diz a documentação.

Por que o Cosmos tem RUs mais altas quando uma chave de partição é especificada?

Respostas

3 4c74356b41 Jan 03 2021 at 15:39

como o comentário especifica se você está testando através do portal (ou através do código, mas com a consulta que você forneceu) ficará mais caro, porque você não está consultando uma partição específica, mas sim consultando tudo e, em seguida, introduzindo outro filtro, que é mais despesa.

o que você deve fazer em vez disso - é usar a maneira correta no código para passar a chave de partição. meu resultado foi bastante impressionante: 3 ru \ s com o PK e 20.000 ru \ s sem o PK, então estou bastante confiante em trabalhos (eu tive um conjunto de dados muito grande)