Por que as consultas do Azure Cosmos têm RUs mais altas ao especificar a chave de partição?
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
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)