Procedimientos recomendados de indexación en el núcleo virtual de Azure Cosmos DB for MongoDB
SE APLICA A: 
núcleo virtual de MongoDB
Los campos consultables siempre deben tener índices creados
Las operaciones de lectura basadas en predicados y agregados consultan el índice de los filtros correspondientes. Cuando no haya índices, el motor de base de datos realiza un examen de documentos para recuperar los documentos coincidentes. Los exámenes siempre son caros y, a medida que crece el volumen de datos de una colección, cada vez son más caros. Para obtener un rendimiento óptimo de las consultas, los índices siempre deben crearse para todos los campos consultables.
Prevención de índices innecesarios e indexación de todos los campos de manera predeterminada
Los índices solo deben crearse para campos consultables. La indexación con caracteres comodín solo debe usarse cuando los patrones de consulta son impredecibles, donde cualquier campo de la estructura del documento puede formar parte de los filtros de consulta.
Sugerencia
El núcleo virtual de Azure Cosmos DB for MongoDB solo indexa el campo _id de manera predeterminada. De manera predeterminada, el resto de campos no están indexados. Los campos que se van a indexar deben planearse con antelación para maximizar el rendimiento de las consultas, a la vez que se minimiza el impacto en las escrituras que supone la indexación de demasiados campos.
Cuando se inserta un nuevo documento por primera vez, o bien se actualiza o se elimina un documento existente, cada uno de los campos especificados en el índice también se actualiza. Si la directiva de indexación contiene muchos campos (o todos los campos del documento), el servidor consume más recursos al actualizar los índices correspondientes. Cuando se ejecuta a gran escala, solo se deben indexar los campos consultables, mientras que todos los campos restantes que no se usan en predicados de consulta deben permanecer excluidos del índice.
Creación de los índices necesarios antes de la ingesta de datos
Para obtener un rendimiento óptimo, los índices deben crearse por adelantado antes de cargar los datos. Todas las escrituras, actualizaciones y eliminaciones del documento actualizarán sincrónicamente los índices correspondientes. Si los índices se crean después de ingerir datos, se consumen más recursos de servidor para indexar los datos históricos. En función del tamaño de los datos históricos, esta operación consume mucho tiempo y afecta al rendimiento de lectura y escritura de estado estable.
Nota:
En escenarios en los que los patrones de lectura cambian y los índices deben agregarse, se debe habilitar la indexación en segundo plano, que se puede realizar mediante una incidencia de soporte técnico.
Para varios índices creados en datos históricos, debes emitir comandos createIndex sin bloqueo para cada campo.
No siempre es posible planear todos los patrones de consulta por adelantado, especialmente a medida que evolucionan los requisitos de la aplicación. El cambio de aplicación inevitablemente requiere que los campos se agreguen al índice de un clúster con una gran cantidad de datos históricos.
En estos escenarios, cada comando createIndex se debe emitir de forma asincrónica sin esperar una respuesta del servidor.
Nota:
De manera predeterminada, el núcleo virtual de Azure Cosmos DB for MongoDB responde a una operación createIndex solo después de que el índice se base completamente en los datos históricos. Según el tamaño del clúster y el volumen de datos ingeridos, esto puede tardar tiempo y aparecer como si el servidor no respondiera al comando createIndex.
Si los comandos createIndex se emiten mediante el Shell de Mongo, usa Ctrl + C para interrumpir el comando a fin de dejar de esperar una respuesta y emitir el siguiente conjunto de operaciones.
Nota:
El uso de Ctrl + C para interrumpir el comando createIndex después de que se haya emitido no finaliza la operación de compilación de índice en el servidor. Simplemente impide que el Shell espere una respuesta del servidor, mientras que el servidor sigue compilando el índice a través de los documentos existentes de forma asincrónica.
Creación de índices compuestos para consultas con predicados en varios campos
Los índices compuestos deben usarse en los escenarios siguientes:
- Consultas con filtros en varios campos
- Consultas con filtros en varios campos y con uno o varios campos ordenados en orden ascendente o descendente
Considera el siguiente documento dentro de la base de datos "cosmicworks" y la colección "employee".
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Considera la siguiente consulta para buscar todos los empleados con el apellido "Smith" en la organización durante más de 5 años:
db.employee.find({"lastName": "Smith", "timeInOrgInYears": {"$gt": 5}})
Un índice compuesto en "lastName" y "timeInOrgInYears" optimiza esta consulta:
use cosmicworks;
db.employee.createIndex({"lastName" : 1, "timeInOrgInYears" : 1})
Seguimiento del estado de una operación createIndex
Cuando se agregan índices y es necesario indexar datos históricos, se puede realizar un seguimiento del progreso de la operación de compilación de índices mediante db.currentOp().
Considera este ejemplo para realizar un seguimiento del progreso de la indexación de la base de datos "cosmicworks".
use cosmicworks;
db.currentOp()
Cuando una operación createIndex esté en curso, la respuesta será similar a la siguiente:
{
"inprog": [
{
"shard": "defaultShard",
"active": true,
"type": "op",
"opid": "30000451493:1719209762286363",
"op_prefix": 30000451493,
"currentOpTime": "2024-06-24T06:16:02.000Z",
"secs_running": 0,
"command": { "aggregate": "" },
"op": "command",
"waitingForLock": false
},
{
"shard": "defaultShard",
"active": true,
"type": "op",
"opid": "30000451876:1719209638351743",
"op_prefix": 30000451876,
"currentOpTime": "2024-06-24T06:13:58.000Z",
"secs_running": 124,
"command": { "createIndexes": "" },
"op": "workerCommand",
"waitingForLock": false,
"progress": {},
"msg": ""
}
],
"ok": 1
}
Habilitación de claves de índice grandes de manera predeterminada
Incluso si los documentos no contienen claves que tienen un gran número de caracteres o los documentos no contienen varios niveles de anidamiento, especificar claves de índice grandes garantiza que se tratan estos escenarios.
Considera este ejemplo para habilitar claves de índice grandes en la colección "large_index_coll" de la base de datos "cosmicworks".
use cosmicworks;
db.runCommand(
{
"createIndexes": "large_index_coll",
"indexes": [
{
"key": { "ikey": 1 },
"name": "ikey_1",
"enableLargeIndexKeys": true
}
]
})
Priorización de compilaciones de índices a través de nuevas operaciones de escritura mediante la opción de bloqueo
En los escenarios en los que se debe crear el índice antes de cargar los datos, debe usarse la opción de bloqueo para bloquear las escrituras de entrada hasta que se complete la compilación del índice.
Establecer { "blocking": true } es especialmente útil en las utilidades de migración en las que los índices se crean en colecciones vacías antes de que comiencen las escrituras de datos.
Considera un ejemplo de la opción de bloqueo para la creación de índices en la colección "employee" en la base de datos "cosmicworks":
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"name":1}, "name":"name_1"}],
blocking: true
})
Contenido relacionado
Consulte indexación de texto, lo que permite realizar búsquedas y consultas eficaces de datos basados en texto.