“MongoDB” (del inglés humongous, “enorme”) es un sistema de base de datos “NoSQL” orientado a documentos de código abierto y escrito en “C++”, que en lugar de guardar los datos en tablas lo hace en estructuras de datos “BSON” (similar a “JSON”) con un esquema dinámico. Al ser un proyecto de código abierto, sus binarios están disponibles para los sistemas operativos “Windows, GNU/Linux, OS X y Solaris” y es usado en múltiples proyectos o implementaciones en empresas como “MTV Network, Craigslist, BCI o Foursquare”.

“MongoDB” es la más representativa de las bases de datos conocidas como “NoSQL”, acrónimo de “Not only SQL”. También podemos denominarla con el término de base de datos documental, ya que lo que almacenamos son puros documentos “JSON” y no registros, como sucede en las tablas de las bases de datos relacionales.

Las bases de datos “NoSQL” vienen a ocupar una parcela específica entre las soluciones de base de datos actuales. Resuelven necesidades habituales, tanto aplicaciones web, apps móviles o en el Internet de las Cosas. Pero no se puede decir que se adapten a todo tipo de proyectos. En general, podemos encontrar de utilidad una base de datos “NoSQL” cuando nuestras necesidades son las siguientes, conocidas como las “3V”.

Velocidad. Si una aplicación necesita almacenar o acceder a mucha información en poco tiempo, se necesita una base de datos que aporte gran velocidad. Las bases de datos documentales son capaces de ser mucho más rápidas que las relacionales, pudiendo atender clientes que necesiten realizar muchas operaciones por segundo.

Volumen. En cuanto al tamaño de la base de datos, si tenemos una cantidad de información gigante o enorme, entonces tenemos unas necesidades importantes de volumen. Las bases de datos relacionales tienen tendencia a funcionar más lentamente cuando en una tabla se encuentran cantidades muy grandes de registros (del orden de un millón para arriba). Situaciones así obligan a los administradores a buscar soluciones, como dividir las tablas en diversos segmentos, produciendo un coste en el acceso a los datos y la operativa. Este no es un problema en las bases de datos “NoSQL”, que son capaces de administrar volúmenes gigantescos de datos en sus entidades.

Variabilidad. Las necesidades enormes de velocidad y volumen suelen darse juntas y afectan a muchas aplicaciones actuales. Sin embargo, hay otra característica de la información que es todavía más representativa para decantarse por las “NoSQL”, como es la variabilidad. En bases de datos relacionales el esquema de la información está minuciosamente definido de antemano. Por ejemplo, no puedes inventarte campos en los registros sobre la marcha. En las bases de datos documentales, como “MongoDB”, no hay problema en que cada documento almacene campos distintos, pudiendo ser flexibles en cuanto al esquema de la información.

Ante cualquiera de estas situaciones, las bases de datos pueden aportar una solución ideal para los proyectos. Sin embargo, siempre conviene recordar que no existen las balas de plata y las bases de datos relacionales todavía son muy importantes para la mayoría de las aplicaciones. Sobre todo, porque las ventajas de las “NoSQL” son en detrimento de ciertas operaciones básicas sobre los datos.

Por ejemplo, la necesidad de “joins” (acceder a información de varias tablas a la vez, relacionando datos entre unas tablas y otras) son el día a día de cualquier motor de base de datos tradicional pero no resulta una funcionalidad habitual en las “NoSQL”. Esto está cambiando ya que la nueva versión 3.2 de “MongoDB” ha comenzado a implementar funcionalidades de “joins” en ciertas operaciones. Esto es interesante, porque cada vez más las bases de datos “NoSQL” serán capaces de entrar en terrenos donde las relacionales son más indicadas, y viceversa.

Lo que a día de hoy no se encuentra disponible en las “NoSQL” son los mecanismos para hacer transacciones entre varios documentos. Debido a esto, pueden no ser la opción más adecuada para ciertas operativas de negocio, ya que se tendrá que profundizar mucho en los mecanismos para almacenar la información y puede no compensar el esfuerzo.