Desmontando los principales mitos sobre MongoDB frente a las bases de datos relacionales

Recientemente estaba hablando con un amigo sobre decidir entre bases de datos para un próximo proyecto. Le pregunté qué pensaba de MongoDB. Me dijo que no pensaba que funcionara basándose en lo que sabía de ello. El único problema era que todo lo que había aprendido sobre MongoDB era de 2013. No se había mantenido al día con más de una década de mejoras y actualizaciones. Al hablar con otros desarrolladores, parece que esta es una situación bastante común. Muchos desarrolladores tuvieron su primera impresión de MongoDB entre 2012 y 2014 y tomaron una decisión en función de ello. En esta publicación, profundizaremos en la historia de las bases de datos y veremos cómo se compara MongoDB con las bases de datos relacionales actuales.

Como repaso rápido, existen varios tipos de bases de datos, pero nos centraremos en las bases de datos relacionales y de documentos NoSQL, ya que son dos de los tipos más populares en uso hoy en día. Las bases de datos relacionales se introdujeron en la década de 1970 y almacenan datos en tablas. Aunque el término NoSQL fue acuñado en 1998 por Carlo Strozzi, las bases de datos NoSQL y su enfoque más flexible para almacenar datos tardaron algunos años más en despegar. En 2009, MongoDB se lanzó con la idea de almacenar los datos en documentos similares a los objetos JSON. Cuando explico la diferencia fundamental entre las bases de datos relacionales y de documentos a mi familia, suelo decir que una es como una hoja de cálculo y la otra es como un Google Doc. Aún no estoy seguro de cuánto entiende mi abuela sobre cuál es mi trabajo, pero al menos ya conoce la diferencia entre los tipos de bases de datos.

Bien, ahora que ya conocemos lo básico, vamos a ver algunos conceptos erróneos que surgen al comparar MongoDB con las bases de datos relacionales.

Mito 1: MongoDB no tiene un esquema

Los esquemas definen la estructura de los datos en una base de datos. Con las bases de datos relacionales, normalmente se diseña el esquema en función de la normalización de los datos. Normalizar significa dividir los datos en diferentes tablas para no duplicarlos. Estos esquemas definidos son excelentes si puede anticipar todas sus futuras necesidades de datos y diseñarlos con elegancia con antelación. Actualizar estos esquemas para agregar nuevos campos puede agregar trabajo y tiempo de inactividad a su aplicación.

Con MongoDB, su esquema depende de las necesidades de su aplicación. Este es un enfoque más flexible para el diseño de esquemas. Ahora, aunque existe flexibilidad, todavía existen mejores prácticas, como la regla de que “los datos a los que se accede juntos deben almacenarse juntos”.

A continuación, se muestra un ejemplo de los datos relacionales anteriores almacenados en MongoDB:

Como se ve en este ejemplo, se puede obtener toda la información sobre “Paul Miller” sin tener que realizar JOINS en tres tablas diferentes. Se pueden hacer JOINS en MongoDB, pero volveremos a esto más adelante.

Gracias a un esquema flexible, los desarrolladores pueden empezar a crear aplicaciones sin tener que diseñar primero el esquema definitivo para luego verse limitados por él. Puede añadir fácilmente nuevos campos a su esquema siempre que la aplicación lo requiera. Si desea tener un esquema más estructurado, puede usar la funcionalidad de validación de esquema de MongoDB. Si necesita que su esquema evolucione con el tiempo, también puede implementar fácilmente el patrón de versionado del esquema.

En última instancia, creo que este mito de que MongoDB no tiene esquema se reduce a dos cosas. En primer lugar, no tenía validación de esquema en los primeros días (se agregó en la versión 3.6 en 2017). La otra razón proviene de la flexibilidad que tienen los desarrolladores al crear su esquema en función de las necesidades de sus aplicaciones. La libertad y la flexibilidad no significan no tener un esquema; simplemente significa que es importante seguir las mejores prácticas para crear un esquema elegante que haga que su aplicación funcione de manera óptima.

Mito 2: MongoDB no cumple con ACID

Las bases de datos necesitan formas de asegurar que las operaciones y los datos resultantes sean confiables incluso cuando se producen errores o cortes de energía. La forma principal en que lo hacen es mediante la implementación de cuatro propiedades: atomicidad, coherencia, aislamiento y durabilidad, también conocidas como ACID.

MongoDB es compatible con ACID. Cada vez que se realiza cualquier operación de creación, lectura, actualización y eliminación en un solo documento, se preserva la integridad de los datos. MongoDB gestiona los datos de un documento a la vez. De lo contrario, no sería una base de datos de documentos. Sería una base de datos caótica e impredecible. ¿Puede imaginarse a muchos escritores tratando de sobrescribir el mismo documento al mismo tiempo? He estado en algunos documentos de Google con más de 10 escritores contribuyendo al mismo tiempo, y sin duda no parece compatible con ACID.

Eso cubre documentos únicos, pero ¿qué sucede con las transacciones multidocumento? Las transacciones multidocumento se utilizan con frecuencia en bases de datos relacionales, ya que a menudo tiene que acceder a varias tablas al realizar actividades como la actualización de un registro de cliente. MongoDB garantiza transacciones ACID multidocumento desde y hacia cualquier ubicación en su clúster de MongoDB. Ha admitido esta garantía desde la versión 4.0 en 2018.

De hecho, la transaccionalidad es una de las mayores fortalezas de MongoDB. Muchas empresas de servicios financieros confían en las transacciones de MongoDB para los casos de uso de la banca central y el comercio. La garantía todo o nada de las transacciones multidocumento de MongoDB lo respalda.

Mito 3: MongoDB no puede realizar JOINS para gestionar datos relacionales

Anteriormente mostramos cómo las bases de datos relacionales confían en la división de datos en varias tablas para un diseño de esquema eficiente. Para trabajar con datos relacionales, a menudo es necesario extraer datos de dichas tablas y combinarlos con JOINS.

MongoDB puede realizar JOINS con el comando $lookup. Pero el hecho de que se pueda hacer algo no significa que se deba hacer. Los datos de MongoDB se modelan de una manera diferente a los datos relacionales. En MongoDB, los datos a los que se accede en conjunto se almacenan en conjunto. Con la mayor parte de los datos en un solo documento en lugar de distribuidos en varias tablas, no es necesario realizar operaciones JOINS, ya que los datos ya se encuentran en el lugar correcto. Este cambio del modelo relacional al modelo orientado a documentos supone un gran cambio de mentalidad, pero una vez que se experimentan los beneficios, es difícil volver atrás. Sin embargo, si aún necesita realizar JOINS con MongoDB, el comando $lookup es su mejor aliado. Incluso puede crear una VIEW (añadida en 2016) para unir dos colecciones.

El mito de que los JOINS no son posibles se reduce, en última instancia, a la diferencia básica entre el modelo relacional y el modelo orientado a documentos. El acceso a los datos en tablas y el acceso a los datos en documentos requieren enfoques diferentes, pero, por lo general, aunque se pueden realizar JOINS en MongoDB, no será necesario si se ha diseñado bien el esquema para los documentos.