Abro este hilo para comentar una empresa que he conocido casi accidentalmente este fin de semana y que hoy presenta resultados: MongoDB.
De hecho, descubrí esta empresa mientras ojeaba las empresas que iban a presentar resultados y encontrarme con este nombre tan curioso, sobre todo por el sufijo DB que delata a lo que se dedica esta empresa: bases de datos (DB: databases).
Adelanto que lo novedoso de esta empresa es que su principal ventaja es que la estructura interna de sus bases de datos es totalmente diferente de las que tradicionalmente se han venido usando hasta la fecha. Su modelo de base de datos BSON está optimizada para un acceso más fácil a la información, especialmente cuando hay que acceder a conjuntos enormes de datos, lo cual cada vez es más frecuente. De hecho, el nombre Mongo viene, según Wikipedia, de “humongous” (gigante).
FUNCIONAMIENTO DE UNA BASE DE DATOS TRADICIONAL
Respecto a las bases de datos, a primera vista puede parecer un mercado más limitado de lo que en realidad es en la actualidad. Intentaré hacer una introducción de cosecha propia acerca de su importancia y de funcionamiento básico.
A finales del siglo pasado, las bases de datos básicamente servían para almacenar datos en redes la mayoría de veces relativamente pequeñas, como puede ser una oficina, un negocio tradicional y, más excepcionalmente, algunas redes más grandes como las de algunas multinacionales y algunas oficinas gubernamentales. Sin embargo, en la actualidad prácticamente cualquier proyecto web de cierta envergadura requiere guardar información en bases de datos. Prácticamente todas las webs, y múltiples servicios online (incluyendo servicios bancarios, reservas de vuelos, videojuegos, streaming, etc) requieren en última instancia de una base de datos donde se almacenen los datos referidos a sus clientes y los contenidos que ofrecen
La aplicación Access incluida en Microsoft Office permite hacerse una idea de cómo funciona una base de datos. Posiblemente es la aplicación menos usada del paquete de Office, pero permite utilizar una base de datos de una forma visual al usuario medio que no conoce un lenguaje de programación, y sacarle bastante partido permitiéndole crear formularios para la introducción de datos e informes para visualizarlos.
Se podrían almacenar datos en cualquier tipo de archivos, como por ejemplo una tabla de una hoja de Excel, pero esto tiene serias limitaciones: no podrían estar generando (y actualizando) datos dos usuarios simultáneamente, y además, el número y complejidad de los datos que se podrían almacenar sería más limitado.
La forma más simple de base de datos se basaría en una única tabla, por ejemplo, una lista de clientes de una librería. En esta tabla, habría una serie de filas, que representarían a cada cliente, y una serie de columnas, que representarían los distintos datos que nos interesa guardar de cada cliente (es obligatorio para el funcionamiento que exista un identificador único y, a partir de ahí, todo lo que consideremos útil: nombre, apellidos, dirección, etc).
Tabla clientes en una base de datos Access
El problema surge cuando queremos adjudicar otro tipo de datos al cliente, por ejemplo, un historial de sus compras. Si cada cliente solo pudiera realizar una compra, bastaría con añadir más columnas (código de producto, precio, etc), pero como se puede imaginar, esta sería una solución que no nos permitiría registrar más que una compra por cliente.
Algunos usuarios de Excel podrían pensar que tampoco supondría un gran problema: si el cliente realizara una nueva compra, podríamos insertar líneas nuevas en las que o bien volveríamos a copiar los datos del cliente o bien podríamos dejar líneas en blanco, o con comillas, indicando que se refieren al cliente anterior. Sin embargo, por motivos técnicos, esto no era posible en la estructura de archivos de ese tipo de bases de datos (aunque adelanto que esa forma de trabajar sí se parece a las bases de datos con las que trabaja mongoDB).
La solución de las bases de datos tradicionales se basa en tablas relacionadas (de ahí el nombre de este tipo de bases de datos; bases de datos relacionales).
En el caso anterior, los datos no podrían ser almacenados en una misma tabla porque un solo cliente podría realizar varias compras. Habría que crear una relación de uno a varios.
Lo que haríamos sería distribuir los datos en varias tablas:
- Una tabla de clientes.
- Una tabla de compras.
tabla compras en una base de datos Access
Cada registro de la tabla compras tendría un número que identificaría esa transacción, pero aparecería también un campo en el que aparecería el código del cliente. Y ambas tablas se podrían relacionar cruzando los datos de ambas:
- Dado un cliente determinado, podemos buscar su identificación, y filtrar en la tabla de compras para buscar las compras ha realizado ese mismo cliente (en las que aparecería esa id en el campo “cliente”).
- Si partimos de la tabla compras y queremos saber más sobre el cliente que ha realizado la compra, bastaría con anotar su identificación y buscar en la tabla de clientes.
Es obvio decir que para tablas del tamaño de los ejemplos podríamos realizar ese trabajo a mano, pero cuando tenemos cientos o miles de clientes y miles de compras, la cosa se complica para los humanos, pero es algo muy sencillo para un ordenador.
Para realizar las búsquedas, normalmente se recurrirá a Access u otro programa que buscará en estas tablas. En realidad, la manipulación de las bases de datos relacionales se hace con un lenguaje de programación específico, que viene integrado con el resto del software, orientado específicamente a realizar este tipo de búsquedas. Este lenguaje es el SQL (structured query language) que también es muy característico de este tipo de bases de datos, a las que a veces se las llama indistintamente bases de datos relacionales o bases de datos SQL.
Si queremos tener una base de datos con más funcionalidades, se nos podrían ocurrir otras mejoras:
- Por ejemplo, que en cada compra se pueda identificar el libro de entre una lista de los libros que se venden en esa librería. Esto podría hacerse generando otra tabla adicional con datos sobre el libro (nombre, ISBN, autor…) y nos evitaría problemas como el de que el vendedor teclee mal el nombre del libro al registrar la compra.
- Si se trata de un negocio de venta online, quizás queramos una tabla con los comentarios de los usuarios. Esto requeriría crear una nueva tabla en la que cada comentario ocuparía una fila, y en el estaría identificado el libro al que hace referencia, opcionalmente el usuario que escribe el comentario, etc.
Y por último, podrían existir relaciones aún más complejas, como relaciones de varios elementos de una tabla con varios elementos de otra. Por ejemplo, podríamos querer tener acceso al autor de un libro determinado. Pero sabemos que, especialmente en el ámbito de divulgación y académico, muchos libros tienen varios autores. Cada uno de esos autores puede tener otros libros que, a su vez, puede haber realizado en solitario o con autores distintos. Para cruzar este tipo de de relaciones libro(s)-autor(es) habría que contar no solo con una tabla de libros y otra de autores, sino también una tabla en la que aparecieran este tipo de interconexiones.
#2
MongoDB (2)
EXTENSION ACTUAL DEL USO DE BASES DE DATOS EN LA WEB
Como hemos visto, esa base de datos de nuestro ejemplo, que inicialmente empezó en una pequeña cadena de tiendas físicas, se puede modificar para albergar información de los usuarios, como comentarios, valoraciones, etc y dar el salto a una plataforma de ventas web.
Pero esto se puede utilizar también para todo tipo de diseños web.
Para quien haya creado una pequeña web estática (es decir, que no use bases de datos), sabrá que en realidad se trata de un conjunto de páginas, hasta cierto punto parecidas a un documento de Word, interconectadas por hipervínculos. Estas páginas se suben al servidor, pero también podrían usarse desde una carpeta de un pc y se podría navegar entre ellas de forma similar. Todas las páginas web han sido creadas explícitamente por una persona y se localizan en el servidor. Pero en realidad esto no es lo habitual.
En la mayoría de webs comerciales, con cantidades de productos y otros tipos de información que se actualiza constantemente (pongamos el ejemplo de Amazon, para seguir con las “librerías”) el funcionamiento es distinto. Cuando entramos en la descripción de un producto, donde nos aparecen las valoraciones, especificaciones, foto, precio, vinculo al carro de la compra…. En realidad se trata de una plantilla que accede a una base de datos en un servidor y utiliza la información que extrae de ésta para reconstruir la página web.
En realidad, podemos ir más allá del comercio electrónico y pensar en cualquier red social, como por ejemplo la misma Rankia. Cuando escribimos un post como este, no se está generando una página nueva, sino que guardando información en una base de datos. Cuando se actualiza la página de los foros, se recurre a una base de datos para regenerar la página con los últimos hilos en los que se ha escrito.
En realidad, prácticamente cualquier servicio basado en la web va a requerir este tipo de tecnología.
COMPLEJIDAD Y ESCALABILIDAD LIMITADA DE BASES DE DATOS TRADICIONALES
Este apartado es importante para entender una de las ventajas de MongoDB, la ESCALABILIDAD de las bases de datos.
Según el tamaño y complejidad de la base de datos, aumenta la cantidad de trabajo que el ordenador (o más concretamente el servidor) tiene que realizar.
Y aquí volvemos al principio: tenemos instalado un programa de gestión en nuestro PC, o en nuestro móvil, que accede a la nube, donde hay una base de datos de la que extrae información. ¿Pero dónde está, físicamente, esa base de datos?. En un servidor o unos pocos servidores. Ahí tenemos un problema, puesto que el numero de servidores no puede ser infinito: en una red grande (pensemos de nuevo en Amazon o Facebook) hay muchos usuarios accediendo al mismo tiempo a los datos, modificando esta información, haciendo compras, escribiendo comentarios, valorando (puntuando) esos productos… El archivo que contiene todos estos datos se va actualizando en tiempo real, y si hay muchos servidores con copias de ese archivo, los cambios que se hacen en uno deben trasladar a los demás de una forma rápida para evitar inconsistencias en la información de la web.
Supongamos por ejemplo que en una gran red social se crea una funcionalidad que permite ver todos los “me gusta” que ha indicado un usuario. Existiría una enorme tabla de “me gustas”, en los que cada “me gusta” escrito por cada usuario aparecería como un registro independiente. Cada registro tendría, al menos, además del identificador propio del registro, un campo con el identificador del comentario al que se refiere y otro campo con un identificador del usuario. Imaginad el enorme tamaño de una tabla como esta.
Pues bien, si entramos en nuestro usuario y revisamos nuestros “me gusta”, estamos obligando al servidor a buscar en esa enorme tabla todos y cada uno de los registros en los que aparece nuestro identificador. Aunque la capacidad de procesamiento de los ordenadores actuales permite realizar la búsqueda relativamente pronto, teniendo en cuenta que ese servidor tiene que dar servicio a muchos usuarios, es fácil imaginar la sobrecarga que este tipo de procesos.
Además, según como esté organizada la base de datos, ciertos tipos de búsquedas pueden ser bastante complicadas: por ejemplo, podríamos tener que acceder a un usuario y cruzar su id con una tabla en la que aparezcan todos los comentarios escritos en esa web y tener que separar aquellos hechos por este usuario, y cruzar con una tercera tabla para ver las valoraciones que han hecho otros usuarios de ese comentario… y el proceso se podría hacer tan complejo como se quiera imaginar.
Concluyo este apartado con una matización que quizás se salga del tema principal, porque muchos preferirán saltar hasta el siguiente apartado.
En realidad, existe algún truco para agilizar este tipo de búsquedas, que consistiría en guardar información redundante, pero que nos permitiría reducir el número de búsquedas realizadas por el servidor. Por ejemplo, para la forma teóricamente idónea para saber cuantos me gusta ha recibido uno de nuestros estados en Facebook sería que el servidor buscara el código interno de ese estado y lo usara para, en esa tabla enorme de “me gustas”, contara cuantos hay referidos a ese estado. Pero una alternativa sería que en la tabla donde se almacena la información del estado se añadiera un campo que indicara el número de “Me gustas”, y cada vez que un usuario hiciera click, se incrementara en 1. Solo en el caso de que alguien quisiera comprobar a quien le ha gustado el comentario sería necesario recurrir a la otra tabla. Pero eso, en teoría, violaría uno de los principios ideales de las bases de datos relacionales, la normalización, que viene a decir que la información no debería aparecer de forma redundante (duplicada).
Desde el punto de vista teórico, la normalización puede estar bien, pero en la práctica,
conforme aumenta el tamaño (numero de registros por tabla) y la complejidad (número de tablas relacionadas) de nuestra base de datos, aumenta ingentemente el consumo de recursos que el servidor dedica a las búsquedas.
Sin embargo, el hecho de tener que realizar este tipo de “arreglos” (saltarse las reglas de “normalización”) para mejorar el rendimiento ya indica que el modelo original empieza a tener problemas.
#3
Re: MongoDB (3)
Y AHORA SÍ, HABLAMOS DE MongoDB…
Las bases de datos diseñadas por MongoDB tienen, desde sus cimientos, un formato diferente a las de las bases de datos relacionales (o bases de datos basadas en tablas y SQL).
Utiliza un sistema de almacenaje de información diferente, llamado BSON (binary JSON), que a su vez procede del JSON (JavaScript Object Notation).
Realmente no tengo experiencia con BSON, aunque sí un poco con JSON, pero para hacernos una idea, puede servir.
La forma de almacenar datos en JSON y BSON es muy parecida a la forma en la que realizaríamos, por ejemplo, al hacer un esquema-resumen de unos apuntes de clase.
La información es organizada de una forma jerárquica: se crean puntos o elementos de una lista, y cada uno de esos puntos puede a su vez subdividirse libremente en el número de puntos que sea necesario. Además, ya no tenemos la rigidez de formato de las tablas de las bases de datos tradicionales y, según sea necesario, cada nivel del esquema puede almacenar tipos de datos muy diferentes.
Volviendo al ejemplo de antes de la librería, la información de los clientes tendría una estructura como la que sigue:
Cliente: Fulano Fulanez (Dirección, datos contacto, etc…)
Compra: El conde de Mostecristo (ISBN, editorial, precio, etc)
Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc)
Compra: La legión maldita
Cliente: John Doe (Dirección, datos contacto, etc…)
Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc)
Cliente: Pedro Falso (Dirección, datos contacto, etc…)
Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc)
Este formato de almacenaje de datos es más flexible a la hora de incorporar nueva información, incluso de datos que en principio no estuvieran previstos. Imaginemos que hemos creado una web de nuestra librería y queremos añadir las valoraciones que hacen los clientes: bastaría añadirlos a la misma lista, con lo que seguimos teniendo un rápido acceso a la información. Si hubiéramos usado bases de datos relacionales / SQL, habríamos tenido que crear nuevas tablas, nuevas relaciones, y aumentar la complejidad del sistema para cuando planeáramos realizar búsquedas de esta nueva información.
Lo anterior quedaría como (cambios en negrita):
Cliente: Fulano Fulanez (Dirección, datos contacto, etc…)
Compra: El conde de Mostecristo (ISBN, editorial, precio, etc)
Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc)
Compra: La legión maldita
Valoración: Acerca de: “El conde de Montecristo”, Comentario: “Clásico de imprescindible lectura”.
Valoración: Acerca de: “Mis años con Carmele”, Comentario: “No lo recomiendo”.
Cliente: John Doe (Dirección, datos contacto, etc…)
Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc)
Cliente: Pedro Falso (Dirección, datos contacto, etc…)
Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc)
Una alternativa sería, si así lo decidiera el diseñador de la web, limitar los comentarios a aquellos libros que el cliente haya comprado en la web, y hacer que aparecieran referidos a la compra correspondiente:
Cliente: Fulano Fulanez (Dirección, datos contacto, etc…)
Compra: El conde de Mostecristo (ISBN, editorial, precio, etc)
Valoración: Comentario: “Clásico de imprescindible lectura”.
Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc)
Compra: La legión maldita
Cliente: John Doe (Dirección, datos contacto, etc…)
Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc)
Cliente: Pedro Falso (Dirección, datos contacto, etc…)
Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc)
A la hora de acceder a la información, esto supone que va a ser más fácil para el motor de la base de datos: la información que necesitamos está ordenada de una forma sencilla.
#4
Re: MongoDB (4)
VENTAJAS DE MongoDB
Si nos vamos a lo práctico, las ventajas de las bases de datos de MongoDB (BSON) son:
- Escalabilidad:
A la hora de consumo de recursos, menos sobrecarga del servidor, lo que permite manejar conjuntos de datos más grandes. Las bases de datos de MongoDB, para grandes cantidades de información, son más eficientes. Es obvio que resulta más fácil acceder a la parte del fichero donde aparecen los datos de un usuario concreto y allí buscar sus “me gusta”, que no tener que identificarlos de entre todos los registros una tabla de tamaño ingente que incluye los “me gusta” de todos los usuarios. Intuyo que el formato de MongoDB requiera un mayor consumo de espacio de almacenaje en disco aunque, como hemos comentado, este no es el factor limitante en la actualidad.
o A nivel organizativo, en empresas basadas en la nube, al parecer es más fácil organizar el crecimiento a nivel de hardware. En el caso de un sistema de bases de datos tradicionales, parte del personal de la base de datos tendría que encargarse de gestionar cuantos servidores deben contratar o comprar, configurar todos esos servidores, como se van a interconectar, etc… lo que supone consumo de recursos materiales y humanos. Y si la empresa (y la información que procesa) crece, esto hay que actualizarlo periódicamente. Al parecer, con las soluciones en la nube de MongoDB, solo hay que contratar el servicio y la empresa se encarga de los requerimientos de hardware, sin tener que contratar explícitamente un numero determinado de servidores. Adjunto imagen explicativa de una de las presentaciones de MongoDB:
Complejidad del mantenimiento en la nube de una base de datos relacional de gran envergadura
A la derecha, solución ofrecida por MongoDB (AtlasDB) para encargarse de la gestión del hardware necesario para mantener sus bases de datos
- Uso más intuitivo para los programadores: La estructura de datos de las bases BSON se parece más a la forma en la que estos van a ser usados por nuestra web, lo que implica que esta estructura facilita la programación. A nivel de empresa, esto supone poder abarcar proyectos más grandes con menor necesidad de personal, y los programadores pueden concentrarse en otros aspectos de la programación y avanzar más rápidamente en la creación y mantenimiento de la web.
Según MongoDB, según datos del sitio web stackoverflow, que sirve de punto de encuentro entre informáticos (y algún aficionado como yo) para consultar y solucionar dudas, MongoDB se está convirtiendo por ello en el sistema de almacenado de información preferido por sus usuarios.
Por mi parte, he curioseado en Amazon la cantidad de libros publicados sobre MongoDB y se pueden encontrar bastantes, incluso en español, lo que resulta indicativo del interés de la comunidad de desarrolladores por este sistema.
SITUACIÓN ACTUAL DEL SECTOR
Actualmente, aunque existen varias versiones de servidores de bases de datos relacionales (como el SQL Server de Microsoft, o versiones de acceso libre como SQLite o MariaDB), este sector está dominado por la empresa Oracle. Oracle desarrolló en su momento su gestor de bases de datos (como curiosidad, su primer cliente fue la CIA), y también han ido realizando otras adquisiciones de otros motores de bases de datos, como sería el caso de MySQL.
Aunque el motor original de Oracle es exclusivamente de pago, sería interesante hablar del modelo de negocio de MySQL, porque se parece mucho al de MongoDB.
MySQL se lanzó inicialmente como una versión de bases de datos libres. Aunque se puede utilizar localmente, está ideado para usar en servidores web.
Cuando Oracle lo adquirió, aunque mantuvo la versión libre, que puede servir para webs pequeñas, pero ofrece la posibilidad de funcionalidades más avanzadas para empresas en su versión de pago.
Como puede verse en la gráfica de ingresos de Oracle, y como suele ser habitual en empresas de informática de calidad, es un negocio con buenos márgenes (aunque el crecimiento se ha detenido en la última década).
Ingresos anuales de Oracle últimos 20 años (ingresos y beneficio neto)
#5
MongoDB (5)
NEGOCIO DE MongoDB
El funcionamiento como empresa de MongoDB es parecido al que hace Oracle con MySQL.
MongoDB desarrolla y mantiene una versión libre (gratuita) de su base de datos. El objetivo de esto es atraer a programadores a esta plataforma, y que los proyectos menos ambiciosos, incluyendo las startups, comiencen a usar el sistema. Pero a las empresas grandes habitualmente les interesa contratar los servicios de pago, que ofrecen funcionalidades avanzadas como por ejemplo una mejor seguridad (encriptación). Esto permite ir creando un efecto de red; según los programadores se familiarizan con esta estructura de datos y conocen las ventajas, habitualmente van a preferir utilizarla en sus futuros proyectos, o incluso migrar los datos de sus bases de datos tradicionales de proyectos anteriores al BSON de MongoDB.
Los ingresos de MongoDB proceden:
En torno a un 5%, de servicios de asesoramiento para desarrolladores. Incluye aplicaciones que permiten migrar la información contenida en bases de datos tradicionales (SQL) a las bases de datos de Mongo.
Licencias del motor de la base de datos (versión de pago) y otras aplicaciones relacionadas. Anteriormente constituía la principal fuente de ingresos, pero actualmente está siendo desplazado por AtlasDB.
AtlasDB es el servicio de MongoDB que gestiona la adaptación de sus bases de datos a la nube. Funciona perfectamente con los servidores en la nube de Amazon (AWS), Google y Microsoft (Azure). Como he adelantado anteriormente, a diferencia de las bases de datos tradicionales, este servicio simplifica el trabajo de los equipos de informática de las empresas cliente.
De momento, MongoDB no produce beneficio neto. Consumen caja, por lo que es posible que en el futuro requieran ampliar capital o endeudarse. En este punto, reconozco que habitualmente no invierto en este tipo de empresas y no sabría estimar en qué momento es previsible que empiece a ser rentable, pero como puede verse, hasta ahora sí que ha mantenido un previsible y pronunciado aumento de ingresos a un nivel anual del 40%. Si nos fiamos en la cifra de negocio de Oracle, con solo que alcanzara una pequeña fracción de su cuota de mercado sería una inversión muy interesante.
Ingresos trimestrales de Mongo (desde 2016)
A este respecto, agradecería la opinión de usuarios de Rankia con experiencia en este tipo de empresas en crecimiento que aún no producen ingresos netos.
Respecto al crecimiento, decir que varias compañías muy conocidas ya trabajan con MongoDB, destacando entre ellas a Amadeus, Verizon, 7eleven y SEGA.
#6
MongoDB (conclusión)
CONCLUSIÓN:
MongoDB me parece una inversión interesante, con los siguientes puntos fuertes:
1. Producto novedoso y con ventajas con respecto a la tecnología de la competencia.
2. Hasta la fecha, crecimiento interanual a doble dígito alto de forma sostenida (aunque con pocos años de track record).
3. A la vez que crece, está propiciando un efecto red, propiciando el uso de su motor entre los desarrolladores, lo que le permite desarrollar cierta ventaja con respecto a futuros competidores.
Y veo, por el contrario, los siguientes inconvenientes:
1. Es una empresa que todavía no produce ingresos y consume caja.
2. A consecuencia de lo anterior, puede ser objeto de OPA.
3. Previsiblemente tenga que recurrir a endeudamiento o nuevas aplicaciones de capital.
4. En el caso de los puntos 2 y 3, una bajada de cotización (aun cuando se debiera a circunstancias del mercado ajenas a la empresa) le perjudicaría notablemente, al poder ser opada a un precio bajo o diluirse más si precisa ampliar capital en el caso de que su cotización esté por los suelos.
5. Desconozco hasta que punto disfruta de una ventaja competitiva superior frente a la competencia, que podría desarrollar un sistema equivalente o superior (patentes, posibilidad de desarrollos alternativos, etc).
#7
Re: MongoDB (conclusión)
Parece que se pega un buen leñazo despues de resultados. Yo no los veo tan malos... supongo q mas por el guidance, pero los ingresos siguen para arriba trimestre tras trimestre.
#8
Re: MongoDB
Gracias por la currada!
Muy interesante.
#9
Re: MongoDB (conclusión)
Sin ser totalmente experto, en un proyecto muy gordo en el que estamos el departamento correspondiente estaba entre mondodb y elastichsearch. La relación de pros y contras se decantó con diferencia por elastichsearch. No sé si puede ayudar en algo
#10
Re: MongoDB (conclusión)
Te comentó algunas ideas que tengo un poco desordenadas: - MongoDB no es algo tan novedoso. Yo la utilicé en un proyecto en el 2015, y ya la conocía de un par de años antes. - mongodb es una base de datos no relacional. - mongodb es una base de datos schemaless. Para algunos proyecto puede ser buena idea o por ejemplo cuando estás haciendo una demo. En un proyecto no sueles tener la necesidad de cambiar el schema con tanta frecuencia. A parte de no tener necesidad de cambiarlo con frecuencia, el cambiarlo suele conllevar cambios no solo en la BBDD sino también en el código. Así que aunque se pueda añadir nuevos registros a la base de datos con un schema diferente. Vas a tener que hacer muchos cambios en el código del proyecto. - mongodb no es la solución definitiva a todos los problemas. - Las bases de datos relacionales se seguirán utilizando mucho. - a día de hoy hay un montón de bases de datos no relacionales. Algunas con unas características muy particulares como Neo4j, que para algún tipo de caso de uso pueda ser la mejor solución. - el rival de mongodb no son las bases relaciones, ej Oracle, sino otras bbdd no relacionales, algunas con cloud propia como "AWS Amazon DynamoDB". - no le veo ventaja competitivas a largo plazo a mongodb. - mira a ver si encuentras alguna ventaja competitiva que la proteja de por ejemplo "AWS Amazon DynamoDB".
una empresa que he conocido casi accidentalmente este fin de semana
El forero acaba de descubrir las BD NoSQL y cree que es una novedad y tecnologia de punta. Es lo que desata la burbuja del Nasdaq, todos ven pepitas de oro donde no hay.
Las BD NoSQL es lo primero que te enseñan en informatica, un array, lista o diccionario que puedes almacenar en un archivo plano.
