Reducción de los costes de RU con indexación estratégica

  • 12 minutos

El consumo de unidades de solicitud (RU) afecta directamente al costo operativo de las cargas de trabajo de Azure Cosmos DB. Las consultas que pueden usar índices consumen RU proporcionales al tamaño del resultado, mientras que las consultas que realizan exámenes completos consumen RU proporcionales al tamaño de los datos. La indexación estratégica reduce los costos de consulta, a la vez que evita la sobrecarga innecesaria de las propiedades de indexación que no se consultan. En esta unidad se enseñan estrategias prácticas para diseñar directivas de indexación que equilibran el rendimiento de las consultas con la rentabilidad de las aplicaciones de inteligencia artificial.

Análisis de patrones de consulta antes de diseñar índices

La indexación eficaz comienza con la comprensión de cómo la aplicación consulta los datos. Revise las consultas que ejecuta su aplicación e identifique qué propiedades aparecen en las cláusulas WHERE, las cláusulas ORDER BY y las funciones de agregado. Cree índices que admitan patrones de consulta reales en lugar de posibilidades teóricas.

Para empezar, puede catalogar los patrones de consulta de la aplicación:

  • Propiedades de filtro: ¿Qué propiedades aparecen en WHERE las cláusulas? ¿Son filtros de igualdad (=) o filtros de intervalo (>, <)?
  • Propiedades de ordenación: ¿Qué propiedades aparecen en ORDER BY las cláusulas? ¿Qué direcciones de ordenación (ascendentes o descendentes) usa la aplicación?
  • Combinaciones de propiedades: ¿Qué propiedades aparecen juntas en la misma consulta? ¿Las consultas filtran una propiedad y ordenan por otra?
  • Frecuencia de acceso: ¿Con qué frecuencia se ejecuta cada patrón de consulta? Priorice los índices para las consultas frecuentes.

Este análisis revela qué índices proporcionan el máximo valor. Una consulta que ejecuta miles de veces por minuto justifica más sobrecarga de índice que una consulta que se ejecuta una vez al día.

Uso de métricas de consulta para identificar índices que faltan

Azure Cosmos DB proporciona métricas de consulta que revelan la eficacia de las consultas que usan índices. Cuando las consultas funcionan mal, las métricas pueden ayudar a identificar si los índices que faltan son la causa.

El SDK devuelve métricas de consulta mediante encabezados de respuesta al habilitar la recopilación de métricas. Entre las métricas clave que se van a examinar se incluyen:

  • Uso del índice: Porcentaje de la consulta que usa índices frente al escaneo.
  • Recuento de documentos recuperado: Número de documentos capturados del almacenamiento. Los recuentos altos con respecto a los resultados devueltos indican un filtrado ineficaz.
  • Recuento de documentos de salida: Número de documentos devueltos en los resultados.

En el ejemplo de Python siguiente se muestra cómo recuperar y examinar las métricas de consulta:

from azure.cosmos import CosmosClient

client = CosmosClient(endpoint, credential)
database = client.get_database_client("documents-db")
container = database.get_container_client("documents")

query = "SELECT * FROM c WHERE c.documentType = @type ORDER BY c.uploadDate DESC"
parameters = [{"name": "@type", "value": "pdf"}]

# Use response_hook to capture query metrics from response headers
query_metrics_output = {}

def response_hook(headers, results):
    query_metrics_output["metrics"] = headers.get("x-ms-documentdb-query-metrics", "")
    query_metrics_output["request_charge"] = headers.get("x-ms-request-charge", "")

results = container.query_items(
    query=query,
    parameters=parameters,
    populate_query_metrics=True,
    response_hook=response_hook
)

# Process results (this triggers the query execution and response_hook callback)
items = list(results)

# Access captured query metrics
print(f"Query metrics: {query_metrics_output.get('metrics', '')}")
print(f"Request charge: {query_metrics_output.get('request_charge', '')} RUs")

Cuando las métricas de consulta muestran un uso de índice bajo o una alta relación de recuperación a salida, investigue si la adición o modificación de índices mejora el rendimiento. Cree el índice que falta, espere a que se complete la transformación y, a continuación, mida los costos de consulta de nuevo.

Excluir propiedades no usadas en consultas

Las propiedades que lee la aplicación, pero nunca filtran o ordenan, no necesitan índices. Los campos de texto grandes almacenados para mostrar, datos binarios e incrustar matrices que se usan solo para el almacenamiento deben excluirse de la indexación.

Considere un documento con la siguiente estructura:

{
  "id": "doc-123",
  "title": "Quarterly Report Q4 2024",
  "documentType": "report",
  "category": "finance",
  "uploadDate": "2024-12-15T10:30:00Z",
  "content": "Full document text spanning thousands of words...",
  "summary": "AI-generated summary of the document...",
  "embedding": [0.123, 0.456, ...1536 values...],
  "rawMetadata": { "author": "...", "pageCount": 50, "fileSize": 2048000 }
}

Si la aplicación consulta por documentType, categoryy uploadDate, pero solo muestra content y summary en resultados, la directiva de indexación debe incluir solo las propiedades consultadas:

{
  "indexingMode": "consistent",
  "includedPaths": [
    { "path": "/title/?" },
    { "path": "/documentType/?" },
    { "path": "/category/?" },
    { "path": "/uploadDate/?" }
  ],
  "excludedPaths": [
    { "path": "/*" }
  ],
  "vectorIndexes": [
    { "path": "/embedding", "type": "diskANN" }
  ]
}

Esta directiva solo indexa las cuatro propiedades usadas en las consultas, además de un índice vectorial para insertar búsqueda. El campo grande content , summary, y rawMetadata no se indexan porque no aparecen en los filtros de consulta.

Incluir clave de partición en el índice

Aunque las claves de partición enrutan las consultas a particiones específicas, las consultas que aplican filtros basados en propiedades de claves de partición siguen beneficiándose de los índices de intervalo dentro de cada partición. Azure Cosmos DB no indexa la clave de partición automáticamente cuando se usa la estrategia exclude-by-default.

Si la clave de partición es /tenantId y las consultas filtran por inquilino:

SELECT * FROM c WHERE c.tenantId = 'tenant-123' AND c.status = 'active'

Puede incluir la ruta de acceso de la clave de partición en la directiva de indexación:

{
  "includedPaths": [
    { "path": "/tenantId/?" },
    { "path": "/status/?" },
    { "path": "/createdDate/?" }
  ],
  "excludedPaths": [
    { "path": "/*" }
  ]
}

Sin la clave de partición en el índice, las consultas que filtran por ella realizan exámenes dentro de cada partición, consumiendo más RU de las necesarias.

Diseño de índices compuestos para combinaciones de consultas comunes

Los índices compuestos proporcionan la mayor ventaja para las consultas ejecutadas con frecuencia. Analice qué combinaciones de propiedades aparecen juntas en las consultas de la aplicación y cree índices compuestos para los patrones más comunes.

Priorice la creación de índices compuestos en función de:

  • Frecuencia de consulta: Las consultas que ejecutan miles de veces se benefician más de la optimización que las consultas poco frecuentes.
  • Volumen de datos: Las consultas en conjuntos de datos grandes obtienen una reducción más significativa de RU gracias a los índices compuestos.
  • Complejidad del filtro: Las consultas con varios filtros en propiedades de alta cardinalidad se benefician sustancialmente de los índices compuestos.

Cada índice compuesto agrega sobrecarga de escritura porque Azure Cosmos DB mantiene el índice durante cada operación de escritura. La creación de docenas de índices compuestos para casos perimetrales aumenta los costos de escritura sin ventajas de lectura proporcionales. Céntrese en los patrones de consulta de cinco a diez más impactantes.

La siguiente directiva incluye índices compuestos para patrones comunes de aplicación de IA:

{
  "indexingMode": "consistent",
  "includedPaths": [
    { "path": "/title/?" },
    { "path": "/documentType/?" },
    { "path": "/category/?" },
    { "path": "/department/?" },
    { "path": "/uploadDate/?" },
    { "path": "/tags/[]" },
    { "path": "/metadata/author/?" }
  ],
  "excludedPaths": [
    { "path": "/*" }
  ],
  "compositeIndexes": [
    [
      { "path": "/documentType", "order": "ascending" },
      { "path": "/uploadDate", "order": "descending" }
    ],
    [
      { "path": "/category", "order": "ascending" },
      { "path": "/department", "order": "ascending" },
      { "path": "/uploadDate", "order": "descending" }
    ]
  ]
}

Considere las cargas de trabajo intensivas en escritura frente a las intensivas en lectura.

El perfil de carga de trabajo de la aplicación influye en la estrategia de indexación óptima. Las aplicaciones con mucha escritura se benefician de la indexación mínima, mientras que las aplicaciones de lectura intensiva se benefician de una indexación completa.

Características de alta carga de escritura:

  • Ingesta de documentos de gran volumen
  • Actualizaciones frecuentes de documentos existentes
  • Streaming de datos en tiempo real
  • Procesamiento por lotes con consultas periódicas

Para cargas de trabajo con mucha escritura, minimice el número de propiedades indexadas y índices compuestos. Cada índice aumenta la latencia de escritura y el consumo de RU. Si las consultas son poco frecuentes, el costo de consulta ocasionalmente más alto podría ser aceptable en comparación con los costos de escritura constantemente elevados.

Características predominantemente de lectura:

  • Consultas frecuentes de muchos usuarios simultáneos
  • Aplicaciones de búsqueda y recuperación
  • Cargas de trabajo de análisis e informes
  • Paneles en tiempo real

Para cargas de trabajo intensivas de lectura, invierta en una indexación completa. Los costos de consulta reducidos en muchas consultas superan el modesto aumento de los costos de escritura. Cree índices compuestos para patrones de consulta comunes y asegúrese de que se indexan todas las propiedades filtradas.

La mayoría de las aplicaciones de inteligencia artificial son de lectura intensiva: muchos usuarios buscan y recuperan documentos, mientras que la ingesta se produce en lotes o con una frecuencia menor. Puede diseñar su directiva de indexación para lecturas eficientes a menos que su perfil de carga de trabajo específico indique lo contrario.

Supervisar el progreso de la transformación del índice

Al modificar una directiva de indexación, Azure Cosmos DB realiza una transformación asincrónica. La transformación actualiza los índices en segundo plano sin afectar a la disponibilidad, pero las consultas no se benefician de nuevos índices hasta que se complete la transformación.

Supervise el progreso de la transformación para comprender cuándo los nuevos índices son efectivos:

# Check indexing progress through container properties
container_properties = container.read()
indexing_policy = container_properties.get("indexingPolicy", {})

# The Azure portal shows transformation progress as a percentage
# SDK access provides the policy but not real-time progress
# Use Azure portal or CLI for detailed progress monitoring

En el caso de contenedores grandes con millones de elementos, las transformaciones de índice pueden tardar horas. Puede planear los cambios de índice durante períodos de tráfico bajo y permitir tiempo suficiente para las transformaciones antes de esperar un rendimiento mejorado de las consultas.

Sugerencia

Al reemplazar una configuración de índice por otra, agregue primero el nuevo índice y espere a que se complete la transformación. A continuación, quite el índice anterior. Este enfoque garantiza que las consultas siempre tengan compatibilidad con índices adecuada.

Prueba del consumo de RU con datos realistas

El rendimiento del índice varía con la distribución de datos y la cardinalidad. Pruebe las consultas en volúmenes de datos realistas y distribuciones para medir el consumo real de RU.

Es posible que los datos de prueba sintéticos con distribuciones uniformes no muestren características de rendimiento de producción. Si los datos de producción tienen distribuciones sesgadas (algunas categorías tienen muchos documentos, otros tienen pocos), el rendimiento de las consultas varía entre particiones.

Puede crear escenarios de prueba que reflejen los patrones de producción:

  1. Carga de datos con cardinalidad y distribución realistas
  2. Ejecutar patrones de consulta representativos
  3. Medición del consumo de RU para cada tipo de consulta
  4. Comparación de costos con y sin índices específicos
  5. Ajustar la directiva de indexación en función de los resultados medidos

Este enfoque empírico valida que la estrategia de indexación logra la reducción de costos esperada para la carga de trabajo específica.

Recursos adicionales