Una de las características más publicitadas de MongoDB es su capacidad de ser "sin esquema". Esto significa que MongoDB no impone ningún esquema en ningún documento almacenado dentro de una colección. Normalmente, MongoDB almacena documentos en formato JSON para que cada documento pueda almacenar varios tipos de esquema/estructura. Esto es beneficioso para las etapas iniciales de desarrollo, pero en las etapas posteriores, es posible que desee aplicar alguna validación de esquema al insertar nuevos documentos para mejorar el rendimiento y la escalabilidad. En resumen, "Schemaless" no significa que no necesite diseñar su esquema. En este artículo, discutiré algunos consejos generales para planificar su esquema MongoDB.
Encontrar el mejor diseño de esquema que se adapte a su aplicación puede volverse tedioso a veces. Estos son algunos puntos que puede considerar al diseñar su esquema.
Evitar el crecimiento de documentos
Si su esquema permite crear documentos que aumentan de tamaño continuamente, entonces debe tomar medidas para evitarlo, ya que puede provocar la degradación del rendimiento de E/S del disco y de la base de datos. De forma predeterminada, MongoDB permite un tamaño de 16 MB por documento. Si el tamaño de su documento aumenta más de 16 MB durante un período de tiempo, es una señal de un diseño de esquema incorrecto. A veces puede llevar al fracaso de las consultas. Puede utilizar depósitos de documentos o técnicas de preasignación de documentos para evitar esta situación. En caso de que su aplicación necesite almacenar documentos de más de 16 MB, entonces puede considerar usar MongoDB GridFS API.
Evite actualizar documentos completos
Si intenta actualizar todo el documento, MongoDB reescribirá todo el documento en otro lugar de la memoria. Esto puede degradar drásticamente el rendimiento de escritura de su base de datos. En lugar de actualizar todo el documento, puede usar modificadores de campo para actualizar solo campos específicos en los documentos. Esto activará una actualización en el lugar en la memoria, por lo tanto, mejorará el rendimiento.
Intente evitar las uniones a nivel de aplicación
Como todos sabemos, MongoDB no admite uniones a nivel de servidor. Por lo tanto, tenemos que obtener todos los datos de la base de datos y luego realizar la unión a nivel de la aplicación. Si está recuperando datos de varias colecciones y uniendo una gran cantidad de datos, debe llamar a DB varias veces para obtener todos los datos necesarios. Obviamente, esto requerirá más tiempo ya que involucra a la red. Como solución para este escenario, si su aplicación depende en gran medida de las uniones, la desnormalización del esquema tiene más sentido. Puede usar documentos incrustados para obtener todos los datos requeridos en una sola llamada de consulta.
Utilice la indexación adecuada
Al realizar búsquedas o agregaciones, a menudo se ordenan los datos. Aunque solicite ordenar en la última etapa de una canalización, aún necesita un índice para cubrir la ordenación. Si el índice en el campo de clasificación no está disponible, MongoDB se ve obligado a clasificar sin un índice. Hay un límite de memoria de 32 MB del tamaño total de todos los documentos que están involucrados en la operación de clasificación. Si MongoDB alcanza ese límite, puede producir un error o devolver un conjunto vacío.
Habiendo discutido la adición de índices, también es importante no agregar índices innecesarios. Cada índice que agrega en la base de datos, debe actualizar todos estos índices mientras actualiza los documentos en la colección. Esto puede degradar el rendimiento de la base de datos. Además, cada índice ocupará algo de espacio y memoria, por lo que la cantidad de índices puede generar problemas relacionados con el almacenamiento.
Una forma más de optimizar el uso de un índice es anular el campo _id predeterminado. El único propósito de este campo es mantener un único campo por documento. Si sus datos contienen una marca de tiempo o cualquier campo de identificación, puede anular el campo _id y guardar un índice adicional.
Varios nueves Conviértase en un administrador de bases de datos de MongoDB - Llevando MongoDB a la producción Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar MongoDBDescargar gratisRelación de lectura frente a escritura
El diseño de un esquema para cualquier aplicación depende en gran medida de si una aplicación requiere mucha lectura o escritura. Por ejemplo, si está creando un tablero para mostrar datos de series temporales, debe diseñar su esquema de tal manera que maximice el rendimiento de escritura. Si su aplicación se basa en el comercio electrónico, la mayoría de las operaciones serán operaciones de lectura, ya que la mayoría de los usuarios revisarán todos los productos y explorarán varios catálogos. En tales casos, debe usar un esquema desnormalizado para reducir la cantidad de llamadas a la base de datos para obtener datos relevantes.
Tipos de datos BSON
Asegúrese de definir correctamente los tipos de datos BSON para todos los campos al diseñar el esquema. Porque cuando cambia el tipo de datos de cualquier campo, MongoDB reescribirá todo el documento en un nuevo espacio de memoria. Por ejemplo, si intenta almacenar (int)0 en lugar del campo (float)0.0, MongoDB reescribe todo el documento en una nueva dirección debido al cambio en el tipo de datos BSON.
Conclusión
En pocas palabras, es aconsejable diseñar un esquema para su base de datos Mongo, ya que solo mejorará el rendimiento de su aplicación. A partir de la versión 3.2, MongoDB comenzó a admitir la validación de documentos donde puede definir qué campos son necesarios para insertar un nuevo documento. A partir de la versión 3.6, MongoDB introdujo una forma más elegante de hacer cumplir la validación de esquemas mediante la validación de esquemas JSON. Con este método de validación, puede aplicar la verificación de tipos de datos junto con la verificación de campos obligatorios. Puede utilizar los enfoques anteriores para comprobar si todos los documentos utilizan el mismo tipo de esquema o no.
