El modelado de datos de aplicaciones para MongoDB debe considerar diversos factores operativos que afectan el rendimiento de MongoDB. Por ejemplo, diferentes modelos de datos pueden permitir consultas más eficientes, aumentar el rendimiento de las operaciones de inserción y actualización, o distribuir la actividad a un clúster fragmentado de forma más eficaz.
Al desarrollar un modelo de datos, analice todas las funciones de su aplicación. operaciones de lectura y escritura en conjunto con las siguientes consideraciones.
Atomicidad
En MongoDB, una operación de escritura es atómica a nivel de un solo documento, incluso si modifica varios documentos incrustados dentro de un mismo documento. Cuando una sola operación de escritura modifica varios documentos (p. ej., db.collection.updateMany()), la modificación de cada documento es atómica, pero la operación en su conjunto no es atómica.
Modelo de datos integrado
El modelo de datos integrado combina todos los datos relacionados en un solo documento, en lugar de normalizarlos en varios documentos y colecciones. Este modelo de datos facilita las operaciones atómicas.
Consulte Datos del modelo para operaciones atómicas para obtener un ejemplo de modelo de datos que proporciona actualizaciones atómicas para un solo documento.
Transacción de múltiples documentos
Para los modelos de datos que almacenan referencias entre piezas de datos relacionadas, la aplicación debe emitir operaciones de lectura y escritura separadas para recuperar y modificar estas piezas de datos relacionadas.
Para situaciones que requieren atomicidad de las lecturas y escrituras en varios documentos (en una sola colección o en varias), MongoDB admite transacciones distribuidas, incluidas las transacciones en sets de réplica y clústeres fragmentados.
Para obtener más información, consulta transacciones
Importante
En la mayoría de los casos, una transacción distribuida incurre en un costo de rendimiento mayor que las escrituras de documentos individuales, y la disponibilidad de transacciones distribuidas no debería ser un sustituto para un diseño de esquema efectivo. Para muchos casos, el modelo de datos desnormalizado (documento incrustado y matrices) seguirá siendo óptimo para tus datos y casos de uso. Es decir, en muchos casos, modelar tus datos de forma adecuada minimizará la necesidad de transacciones distribuidas.
Para consideraciones adicionales sobre el uso de transacciones (como el límite de tiempo de ejecución y el límite de tamaño del oplog), consulta también las consideraciones de producción.
particionado
MongoDB utiliza fragmentación para proporcionar escalabilidad horizontal. Estos clústeres admiten implementaciones con grandes conjuntos de datos y operaciones de alto rendimiento. La fragmentación permite a los usuarios particionar una colección dentro de una base de datos para distribuir sus documentos entre varias mongod instancias o fragmentos.
Para distribuir los datos y el tráfico de aplicaciones en una colección fragmentada, MongoDB utiliza la clave de fragmento. Seleccionar la clave de fragmento adecuada tiene implicaciones significativas para el rendimiento y puede habilitar o impedir el aislamiento de consultas y aumentar la capacidad de escritura. Si bien puede cambiar su clave de fragmento más adelante, es importante considerar cuidadosamente su elección.
Consulte Fragmentación y claves de fragmentación para obtener más información.
Indexes
Utilice índices para mejorar el rendimiento de las consultas comunes. Cree índices en los campos que aparecen con frecuencia en las consultas y para todas las operaciones que devuelven resultados ordenados. MongoDB crea automáticamente un índice único en el campo _id.
Al crear índices, tenga en cuenta los siguientes comportamientos de los índices:
Cada índice requiere al menos 8 kB de espacio de datos.
Añadir un índice tiene un impacto negativo en el rendimiento de las operaciones de escritura. En colecciones con una alta tasa de escritura a lectura, los índices son costosos, ya que cada inserción también debe actualizar los índices.
Las colecciones con una alta tasa de lectura-escritura suelen beneficiarse de índices adicionales. Los índices no afectan las operaciones de lectura no indexadas.
Cuando está activo, cada índice consume espacio en disco y memoria. Este uso puede ser significativo y debe monitorizarse para la planificación de la capacidad, especialmente por cuestiones relacionadas con el tamaño del conjunto de trabajo.
Consulte Estrategias de Indexación para obtener más información sobre los índices y analizar el rendimiento de las consultas. Además, el generador de perfiles de bases de datos de MongoDB puede ayudar a identificar consultas ineficientes.
Gran número de colecciones
En determinadas situaciones, es posible que elija almacenar información relacionada en varias colecciones en lugar de en una sola.
Considera una colección de muestra, logs, que almacena documentos de registro para varios entornos y aplicaciones. La colección logs contiene documentos del siguiente formato:
{ log: "dev", ts: ..., info: ... } { log: "debug", ts: ..., info: ...}
Si el número total de documentos es bajo, puede agruparlos en colecciones por tipo. Para los registros, considere mantener colecciones de registros distintas, como logs_dev y logs_debug. La colección logs_dev contendría solo los documentos relacionados con el entorno de desarrollo.
Generalmente, tener un gran número de colecciones no supone una pérdida significativa de rendimiento y resulta en un rendimiento muy bueno. Disponer de colecciones diferenciadas es fundamental para el procesamiento por lotes de alto rendimiento.
Cuando utiliza modelos que tienen una gran cantidad de colecciones, tenga en cuenta los siguientes comportamientos:
Cada colección tiene una sobrecarga mínima determinada de unos pocos kilobytes.
Cada índice, incluido el índice en
_id, requiere al menos 8 kB de espacio de datos.Para cada base de datos, un único archivo de espacio de nombres (es
<database>.nsdecir,) almacena todos los metadatos de esa base de datos, y cada índice y colección tiene su propia entrada en el archivo de espacio de nombres. Consulte los límites de longitud del espacio de nombres de lugares para conocer las limitaciones específicas.
La colección contiene una gran cantidad de documentos pequeños
Si tiene una colección con una gran cantidad de documentos pequeños, debería considerar la incrustación por razones de rendimiento. Si puede agruparlos mediante una relación lógica y los recupera con frecuencia mediante esta agrupación, podría considerar agruparlos en documentos más grandes que contengan una matriz de documentos incrustados.
Agrupar estos documentos pequeños en grupos lógicos implica que las consultas para recuperar un grupo de documentos implican lecturas secuenciales y menos accesos aleatorios al disco. Además, agrupar los documentos y mover los campos comunes al documento más grande beneficia el índice de estos campos. Habría menos copias de los campos comunes y menos entradas clave asociadas en el índice correspondiente. Consulte Índices para obtener más información sobre los índices.
Sin embargo, si a menudo solo necesita recuperar un subconjunto de los documentos dentro del grupo, la acumulación de documentos podría no ofrecer un mejor rendimiento. Además, si los documentos pequeños e independientes representan el modelo natural para los datos, debería mantener ese modelo.
Optimización del almacenamiento para documentos pequeños
Cada documento de MongoDB conlleva una cierta cantidad de sobrecarga. Esta sobrecarga suele ser insignificante, pero se vuelve significativa si todos los documentos ocupan solo unos pocos bytes, como podría ocurrir si los documentos de su colección solo tienen uno o dos campos.
Tenga en cuenta las siguientes sugerencias y estrategias para optimizar la utilización del almacenamiento para estas colecciones:
Utilice el campo
_idexplícitamente.Los clientes de MongoDB añaden automáticamente un
_idcampo a cada documento y generan un 12 ObjectId único de bytes para el_idcampo. Además, MongoDB siempre indexa el_idcampo. En documentos pequeños, esto puede ocupar mucho espacio.Para optimizar el uso del almacenamiento, los usuarios pueden especificar explícitamente un valor para el campo
_idal insertar documentos en la colección. Esta estrategia permite que las aplicaciones almacenen un valor en el campo_idque habría ocupado espacio en otra parte del documento.Puede almacenar cualquier valor en el campo
_id, pero como este valor sirve como clave principal para los documentos de la colección, debe identificarlos de forma única. Si el valor del campo no es único, no puede servir como clave principal, ya que se producirían colisiones en la colección.Utilice nombres de campo más cortos.
Nota
Si bien acortar los nombres de campo puede reducir el tamaño de BSON en MongoDB, suele ser más efectivo modificar el modelo general del documento para reducirlo. Acortar los nombres de campo puede reducir la expresividad y no afecta el tamaño de los índices, ya que estos tienen una estructura predefinida que no incorpora nombres de campo.
MongoDB almacena todos los nombres de campo en cada documento. Para la mayoría de los documentos, esto representa una pequeña fracción del espacio utilizado; sin embargo, para documentos pequeños, los nombres de campo pueden representar una cantidad de espacio proporcionalmente grande. Considere una colección de documentos pequeños similar a la siguiente:
{ last_name : "Smith", best_score: 3.9 } Si acorta el campo llamado
last_namealnamey el campo llamadobest_scoreascore, de la siguiente manera, podría ahorrar 9 bytes por documento.{ lname : "Smith", score : 3.9 } Incrustar documentos.
En algunos casos, puede que desee incrustar documentos en otros documentos y ahorrarse el trabajo por documento.Consulte "La colección contiene una gran cantidad de documentos pequeños".
Optimizar el modelo del documento.
Gestión del ciclo de vida de los datos
Las decisiones de modelado de datos deben tener en cuenta la gestión del ciclo de vida de los datos.
La funcionalidad de Time to Live o TTL de las colecciones elimina los documentos tras un período de tiempo. Considera usar la funcionalidad TTL si tu aplicación requiere que algunos datos persistan en la base de datos durante un periodo limitado de tiempo.
Además, si su aplicación solo utiliza documentos insertados recientemente, considere las Colecciones Limitadas. Estas colecciones permiten la gestión FIFO (primero en entrar, primero en salir) de los documentos insertados y facilitan la inserción y lectura de documentos según el orden de inserción.