DP-900: cómo usar índices secundarios en Azure Cosmos DB

Te enseñaré la competencia: comprender y usar índices secundarios en Azure Cosmos DB. Esta habilidad aparece en la sección de datos no relacionales del DP-900 y es útil en la práctica para optimizar el rendimiento de lectura y el coste de RU en aplicaciones que usan Cosmos DB.

Qué necesitas saber

Azure Cosmos DB es una base de datos no relacional multimodelo que indexa automáticamente documentos JSON. Los índices secundarios (secondary indexes) permiten consultas rápidas en propiedades que no son la clave primaria. Por defecto, Cosmos DB crea un índice para todas las propiedades, haciendo que la mayoría de las consultas sean rápidas sin esquema adicional. No obstante, el índice automático puede aumentar costes y latencia de escritura; por eso, es importante entender cómo configurar la política de indexación.

Ejemplo simple: tienes documentos con esta estructura en un contenedor:

{
  "id": "1",
  "nome": "Ana",
  "idade": 30,
  "cidade": "Lisboa",
  "tags": ["clientes", "premium"]
}

Si quieres consultar por cidade (WHERE cidade = 'Lisboa'), un índice secundario en la propiedad cidade acelera la consulta. Si rara vez consultas por una propiedad, puedes excluirla del índice para reducir costes de escritura.

Cómo funciona

La política de indexación en Cosmos DB define qué rutas JSON se indexan y con qué tipo de índice (Hash, Range) y precisión. Puntos clave:

• Included paths: rutas a indexar (ej.: "/cidade/?", "/tags/*").
• Excluded paths: rutas a excluir del índice para reducir el coste de escritura.
• Tipos de índice: Range para operadores <, >, ORDER BY y consultas de rango; Hash para igualdad (==), más eficiente en espacio.
• Consistencia y RU: los índices aumentan el coste de RU en las operaciones de escritura. Ajustar la política altera el trade‑off entre lecturas rápidas y escrituras más costosas.

Ejemplo de política de indexación (simplificado) en JSON:

{
  "indexingMode": "consistent",
  "includedPaths": [
    { "path": "/cidade/?" },
    { "path": "/idade/?" }
  ],
  "excludedPaths": [
    { "path": "/comentarios/*" }
  ]
}

En la práctica

Pasos para optimizar índices secundarios en una base de producción:

1. Identifica los patrones de consulta: analiza las queries más frecuentes — qué propiedades aparecen en WHERE, JOIN, ORDER BY o en filtros de rango.
2. Elige el tipo de índice según el uso: usa Range si necesitas ORDER BY o filtros de rango (ej.: idade > 18); usa Hash para igualdad (ej.: cidade = 'Porto').
3. Excluye propiedades de bajo uso: campos grandes (ej.: blobs en base64, arrays muy extensos) o raramente consultados deben ser excluidos.
4. Prueba y mide RU: antes y después de cambiar la política, mide el RU consumido en las escrituras y en las lecturas y la latencia de las queries.

Ejemplo práctico con Azure Portal / SDK: cambia la política vía portal o ARM/SDK — aquí un fragmento de JSON para incluir un índice de tipo Range en una propiedad de texto para la que se espera un ORDER BY:

{
  "includedPaths": [
    {
      "path": "/nome/?",
      "indexes": [
        { "kind": "Range", "dataType": "String", "precision": -1 }
      ]
    }
  ],
  "excludedPaths": [
    { "path": "/largeBlob/*" }
  ]
}

Tras aplicarla, reevalúa el rendimiento de las consultas. Si es necesario, reindexa contenidos (en algunos escenarios puede ser preciso recrear el contenedor para una reindexación completa, dependiendo de los cambios).

Errores comunes

1) Suponer que el índice automático es siempre ideal: tenerlo todo indexado aumenta el coste de escritura. Ajusta la política según los patrones de lectura/escritura.

2) Usar Range sin necesidad: Range consume más espacio y RU; para igualdad prefiere Hash.

3) Olvidar medir RU tras cambios: modificar la política sin monitorización puede degradar el coste o la latencia. Prueba siempre antes de pasar a producción.

Cómo practicar

Crea un contenedor de prueba en Azure Cosmos DB (modo Core/SQL) y realiza experimentos: inserta documentos con diferentes formatos y simula cargas de lectura/escritura. Usa el portal y los SDKs para modificar la política de indexación y observa el RU y las latencias.

Para la preparación del examen DP-900, haz el Practice Assessment OFICIAL gratuito de Microsoft y consulta la study guide oficial (gratuita). Estos recursos oficiales ayudan a validar el conocimiento sin recurrir a materiales prohibidos.

En resumen

• Los índices secundarios en Cosmos DB aceleran consultas en propiedades que no son clave primaria.
• Configurar included/excluded paths y escoger entre Hash y Range ayuda a equilibrar el coste de RU y el rendimiento.
• Mide siempre RU y latencia antes y después de cambios; optimiza en base a patrones reales de consulta.
• Practica en Azure y usa el Practice Assessment y la study guide oficiales y gratuitos de Microsoft.