¿Por qué las consultas de Azure Cosmos tienen RU más altas al especificar la clave de partición?
Tengo una pregunta similar a esta . Básicamente, he estado probando diferentes formas de usar la clave de partición y he notado que, en cualquier momento, cuanto más se hace referencia a una clave de partición en una consulta, mayores son las RU. Es bastante consistente y ni siquiera importa cómo se use la clave de partición. Así que lo reduje a las consultas básicas para la prueba.
Para empezar, esta base de datos tiene alrededor de 850K documentos, todos de más de 1KB de tamaño. La clave de partición es básicamente un módulo 100 de la identificación en forma de número, se establece en / partitionKey y el contenedor usa una política de indexación predeterminada:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/\"_etag\"/?"
}
]
}
Aquí está mi prueba de consulta básica:
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 documentación de Azure Cosmos dice que sin la clave de partición, la consulta se " desplegará " a todas las particiones lógicas. Por lo tanto, esperaría que la primera consulta se dirija a una sola partición y la segunda a todas, lo que significa que la primera debería tener RU más bajas. Supongo que estoy usando los resultados de RU como evidencia de si el Cosmos está desplegando y escaneando cada partición, y comparándolo con lo que la documentación dice que debería suceder.
Sé que estos resultados tienen una diferencia de solo 0,1 RU. Pero mi punto es que cuanto más compleja es la consulta, mayor es la diferencia. Por ejemplo, aquí hay otra consulta ligeramente más compleja:
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 las RU continúan creciendo y se separan de no haber especificado una clave de partición en absoluto. En su lugar, esperaría que la consulta anterior solo apunte a dos particiones, en comparación con la verificación de clave de partición que supuestamente se expande a todas las particiones.
Estoy empezando a sospechar que la verificación de la clave de partición se realiza después de los otros filtros (o dentro de cada escaneo de partición). Por ejemplo, volviendo a la primera consulta pero cambiando la identificación a algo que no 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 las RU son exactamente iguales y ambas (incluido el que tiene el filtro de partición) tienen menos RU que cuando existe un documento. Esto parece ser un síntoma de que el filtro de partición se está ejecutando en los resultados, sin restringir un abanico. Pero esto no es lo que dice la documentación.
¿Por qué Cosmos tiene RU más altas cuando se especifica una clave de partición?
Respuestas
como el comentario especifica si está probando a través del portal (o mediante el código, pero con la consulta que proporcionó) se volverá más costoso, porque no está consultando una partición específica, sino consultando todo y luego introduciendo otro filtro, que es más gasto.
lo que debería hacer en su lugar es utilizar la forma correcta en el código para pasar la clave de partición. mi resultado fue bastante impresionante: 3 ru \ s con el PK y 20.000 ru \ s sin el PK, así que tengo bastante confianza en las redes (he tenido un conjunto de datos realmente grande)