Cómo decidir si MongoDB es adecuado para usted

Durante los últimos años, construí aplicaciones web en torno a MongoDB. En este breve artículo me gustaría responder algunas de las preguntas recurrentes o malentendidos que la mayoría de los desarrolladores tienen al evaluarlo:

  • ¿Qué es la licencia?
  • ¿Qué significa que MongoDB es una base de datos NoSQL?
  • ¿Qué pasa con las actuaciones de MongoDB?

Licencia

Sí, MongoDB tiene la licencia GNU AGPL v3.0 de la Free Software Foundation . En la práctica, esto significa que las mejoras que realice en MongoDB deben enviarse a la comunidad. El código fuente de cualquier trabajo derivado también debe distribuirse.

Quizás se pregunte si su aplicación es un trabajo derivado. Debo confesar que nunca encontré una definición simple de tal término. Sin embargo, en el caso específico de MongoDB, simplemente reconocen que las aplicaciones que usan su base de datos son un trabajo separado. Además, sus controladores compatibles se publican bajo la licencia Apache v2.0. Esta es una licencia permisiva. No requiere que publiques tu código fuente, y tu aplicación generalmente solo habla con MongoDB usando un controlador.

Como consecuencia, no necesita preocuparse por la licencia de MongoDB para crear su aplicación a su alrededor. Incluso envían cartas firmadas afirmando la promesa a los departamentos legales si hay preguntas. También proporcionan licencias comerciales si la carta firmada no es suficiente.

Nota: aunque la gran experiencia me hace confiar en este análisis, no soy abogado. La vista que se presenta aquí es mi entendimiento personal y no es oficial.

NoSQL

Sí, MongoDB es una base de datos NoSQL. Esta palabra puede resultar bastante confusa. Intentaré analizar las ideas más comunes centrándome en cómo esto se aplica a MongoDB.

Orientado a documentos

En las bases de datos SQL tradicionales, los datos se organizan en forma de tablas y filas. Cada fila tiene un número fijo de columnas que solo pueden almacenar datos de un tipo específico (por ejemplo, Integer, Text, Datetime). Esto define el esquema de sus datos.

En MongoDB, los datos se almacenan en forma de objetos BSON organizados en colecciones. Los datos songeneralmente se maneja en forma de objetos JSON. Esto hace que el mapeo de objetos en la base de datos sea una tarea simple, normalmente eliminando cualquier cosa similar a un mapeo relacional de objetos .

Transaccional

Antes de la v4, MongoDB solo proporcionaba transacciones en todo el documento. Las escrituras nunca se aplicaron parcialmente a un documento insertado o actualizado. La operación fue atómica en el sentido de que falla o tiene éxito. Para el documento en su totalidad, se dijo que era ACID a nivel de documento. Como consecuencia, no había posibilidad de cambios atómicos que abarcaran varios documentos. Tenías que emular las transacciones de la base de datos requeridas (por ejemplo, usando el compromiso de 2 fases).

Desde v4, MongoDB admite transacciones ACID de varios documentos, lo que la convierte en la única base de datos de código abierto que combina el modelo de documento con garantías ACID.

Sin esquema (¿de verdad?)

Esto significa que no tiene que decirle a la base de datos la estructura de sus datos y los tipos primitivos que se utilizarán antes de poder administrarlos. Esto también significa que puede mezclar documentos que tienen diferentes estructuras en la misma colección de datos.

Uno de los grandes beneficios es que las migraciones de esquemas se vuelven más fáciles (la mayoría de los ajustes a la base de datos son transparentes y automáticos). Es poco probable que la reversión cause problemas. Otra ventaja es que extender dinámicamente los modelos de datos existentes con atributos personalizados en tiempo de ejecución es sencillo .

Perotodo esto no significa que no tenga ningún esquema en absoluto. Si no se declara explícitamente , brilla implícitamente en la lógica de su aplicación. Puede declararse de otras formas para manejar la validación de formularios / datos. De todos modos, todavía tiene que decirle explícitamente a la base de datos cómo crear índices para garantizar un buen rendimiento.

De hecho, el diseño de esquemas es la piedra angular para crear bases de datos increíbles, ya sea SQL o no. Si no comprende sus datos y las limitaciones del hardware y software, no podrá diseñar un esquema de manera eficaz.

No relacional (¿de verdad?)

Esto significa que no siempre es necesario crear una relación entre dos documentos para manejar estructuras de datos agregadas.

De hecho, en las bases de datos relacionales, la cláusula SQL JOIN le permite combinar filas de dos o más tablas utilizando un campo común entre ellas. Las bases de datos orientadas a documentos como MongoDB están diseñadas para almacenar datos desnormalizados . Idealmente, no debería haber relación entre colecciones: si se requieren los mismos datos en dos o más documentos, se deben repetir. Uno de los grandes beneficios es que se requiere una sola operación de lectura para obtener todos los datos.

Pero aún puede crear relaciones y consultar otro documento si lo desea o tiene la necesidad:

  • por ID, luego puede "completarlo" manualmente con una segunda consulta o usando DBRefs
  • por cualquier otro campo, entonces puede usar el $lookupoperador

Esto hace que MongoDB sea realmente flexible y le permite elegir cómo manejar las relaciones entre sus objetos caso por caso .

Actuación

Leer escribir

Sí, MongoDB, como cualquier otra base de datos "verdadera", está diseñada para manejar un gran volumen de datos. En pocas palabras, cientos o miles de objetos no son nada para una base de datos, por lo que no tiene que preocuparse si tiene esos números. Puede encontrar muchos puntos de referencia. Aquí hay uno simple para darle un orden de magnitud aproximado. Los documentos almacenados son realmente simples y generalmente representan una medida con marca de tiempo:

{ value: random(0,100), timestamp: date}

Debido a la forma en que MongoDB delega la administración de la memoria al sistema operativo, tener documentos más complejos (que generalmente contienen decenas de atributos) no afecta los resultados de manera significativa

Ambos atributos se han indexado. MongoDB agrega e indexa automáticamente el ID único del documento. Probé tres solicitudes:

  • encontrar el valor máximo de la colección utilizando el marco de agregación
  • encontrar los 100 valores máximos superiores a 99,9
  • obtener un solo documento por identificación

La "solicitud máxima" no se beneficia de los índices debido a la agregación, mientras que las solicitudes "mayor que" y "por ID" pueden usarla. Verá lo importante que es esto para el rendimiento.

La configuración de prueba fue MongoDB 3.4.1 64 bits - SO Windows 7 Pro SP1 - CPU Core i7–4712HQ 2.3GHz - 16Go RAM - SSD HD, y los resultados de la prueba fueron los siguientes:

Por lo tanto, si crea los índices correctos consultando mil millones de documentos, todavía tiene el rendimiento suficiente para la mayoría de las aplicaciones en un solo servidor. Si es necesario, puede aumentar el rendimiento mediante la fragmentación.

Here are the scripts used to create/query the database for this test:

And the run commands:

// Launch server./mongod --dbpath "C:\Program Files\MongoDB\Server\3.4\data" --port 27018// Insertion exemple for 10e7./mongo --port 27018 --eval "var arg1=10000000" create_collection.js// Requests./mongo --port 27018 --eval "" query_collection.js

Memory

Yes, MongoDB often looks like it uses all available RAM. It actually relies on different storage engines. WiredTiger is the default starting in MongoDB 3.2, and MMAPv1 is the default for MongoDB versions before 3.2. However, they work pretty similarly. Via the file system cache, they automatically use all free memory that is not used by the engine cache or by other processes. And this is coherent if you’d like to have maximum performances.

So system resource monitors often show that MongoDB uses a lot of memory, but its usage is dynamic. If another process suddenly needs half the server’s RAM, MongoDB will yield cached memory to the other process.

As a consequence, the single parameter you can tune to optimize memory usage is the engine cache size. For example, by default, the WiredTiger engine uses 50% of RAM minus 1 GB, which can be pretty large on servers with a lot of memory. This can even cause some trouble if you use containers with limited memory, so simply find out the right balance for your use case.

Conclusion

I hope you know have a more precise idea of the benefits provided by MongoDB if it suits your needs. Recently, MongoDB has started a Database as a Service offer called MongoDB Atlas that might be useful for you to test out.

If you liked this article feel free to have a look at our Open Source solutions, the Kalisio team !