Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los campos consultables siempre deben tener índices creados
Las operaciones de lectura basadas en predicados y agregados consultan el índice de los filtros correspondientes. En ausencia de índices, el motor de base de datos realiza un examen de documentos para recuperar los documentos coincidentes. Los escaneos siempre son costosos y se vuelven progresivamente más caros a medida que crece el volumen de datos de una colección. Para obtener un rendimiento óptimo de las consultas, los índices siempre deben crearse para todos los campos consultables.
Evitar índices innecesarios e indexación de todos los campos de forma 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
Azure DocumentDB solo indexa el campo _id de forma predeterminada. Todos los demás campos no se indexan de forma predeterminada. 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 de la indexación de demasiados campos.
Cuando se inserta un nuevo documento por primera vez o 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 un gran número de campos (o todos los campos del documento), el servidor consume más recursos al actualizar los índices correspondientes. Cuando se ejecuta a 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.
Estrategia de indexación para una ingesta de datos eficaz
Para migraciones de cargas de trabajo de gran tamaño a Azure DocumentDB, se recomienda crear índices después de la carga de datos para una ejecución eficaz. Esto reduce significativamente la sobrecarga de escritura, minimiza el consumo de recursos y acelera el rendimiento de la ingesta de datos. Mantener índices durante la carga masiva de datos puede ralentizar las inserciones, ya que cada operación de escritura tiene que actualizar todos los índices aplicables.
Para varios índices creados en datos históricos, emita 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 forma predeterminada, Azure DocumentDB 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 a través del shell de Mongo, use Ctrl + C para interrumpir el comando para 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
Considere 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
}
Tenga en cuenta la siguiente consulta para buscar todos los empleados con el apellido "Smith" que han estado en la organización por más de cinco 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().
Considere este ejemplo para realizar un seguimiento del progreso de la indexación en la base de datos "cosmicworks".
use cosmicworks;
db.currentOp()
Cuando una operación createIndex está en curso, la respuesta es 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
}
Habilitar claves de índice grandes de forma predeterminada
Incluso si los documentos no contienen claves con un gran número de caracteres o no tienen múltiples niveles de anidamiento, definir claves de índice grandes asegura que se aborden estos escenarios. Ahora la clave de índice grande es el comportamiento predeterminado del motor.
Considere 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 la construcción de índices sobre 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, la opción de bloqueo debe usarse para bloquear las escrituras entrantes hasta que se complete la compilación del índice.
La configuración { "blocking": true } es ú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.
Considere 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 la indexación de texto, lo que permite realizar búsquedas y consultas eficaces de datos basados en texto.