MongoDB, la startup de los 1.200 millones de dólares

Según Bloomberg, este es el valor que ha alcanzado esta «pequeña» compañía después de que la enorme popularidad que ha cosechado en Internet su sistema gestor de bases de datos le permitiese obtener un capital de 150 millones de dólares a través de un fondo de capital riesgo. Poco a poco, el modelo de negocio de esta startup, sostenido por un sistema de bases de datos innovador «no SQL» y orientado a documentos que tiene muy poco en común con las bases de datos relacionales tradicionales, ha dado sus frutos.

[#3 procesd]

No es un sustituto de mysql

Esta orientada a un ciclo de versiones muy rápido,tiene un schema no rígido, puedes cambiarlo muy facilmente y la representacion de los datos (como documento, tipo xml)es casi como si pusieras directamente una estructura en la BBDD
Es muy escalable y con sistema de replicación sencillo para no perder mucho tiempo configurando si tienes que añadir nodos.

La parte mala? no hay claves foraneas, no hay transacciones(excepto dentro del mismo documento) y basicamente no hay un schema correcto tipo 3ª forma normal en sql, así que tiene una parte de artesania.

Lo mejor para mi es que tienen varios cursos, equivalentes a lo que seria una certificación, gratis en https://education.mongodb.com/ con lo que es una tecnologia que no tiene una barrera de entrada fuerte.

[#13 vickop]

#3 (como documento, tipo xml)

De acuerdo contigo salvo en lo que te señalo. El esquema de los datos es de tipo JSON (BSON lo llaman en MongoDB), no XML. El parseo del formato JSON es mucho menos complejo que el de XML.

[#30 procesd]

#13 mmm, yo pensaba que de json a xml y viceversa era traducción directa, por eso lo he usado como comparativa, pero buscando un poco veo que xml es mas extensible y por tanto mas complejo( aunque el ejemplo de integrar un powerpoint en xml me ha provocado un escalofrio) Gracias!

[#14 RubenC]

#3 Básicamente, hoy en día hay mucho aborregamiento becerril en demasiados CTO's de empresas que a la que les va mal el MySQL de turno, ya empiezan (pomposamente, eso si) con "se nos ha quedado pequeño, tenemos que pasar a otra cosa". Y todo porque son unos necios, no configuran ni dimensionan las cosas (y no voy a hacer ahora un tutorial de qué hacer y cómo y por qué) y se creen que cambiando el motor de base de datos, van a solucionar algo. La gracia está en hacer coexistir las cosas, y utilizar cada herramienta donde procede.

[#23 elzahr]

#19 Pues que ganas velocidad en gestión documental y mantenimiento de estructuras de datos complejas. Pero pierdes en "versatilidad", es decir, que hay cosas que no se podrán hacer, o que tardarán más tiempo que en una BDD relacional normal "de toda la vida".

Como dice #14, lo que hay que hacer es utilizar bien las herramientas. De hecho, yo pienso que si configuras bien una BDD normal, no perderá mucho en velocidad en relación a una no-SQL.

[#28 procesd]

#23 La diferencia esta en el numero de nodos que necesitas. Configurar varios servidores de mysql para que trabajen juntos sin perder funcionalidades es complicado y cada servidor añadido lo complica mas. En estos casos usas una BBDD nosql. Otra cosa es que no puedas renunciar a las transacciones (por ejemplo, en un banco).

Entonces te toca sufrir un oracle multimaster con forlayos y juntas de trocola y todo lo que el comercial le cuele a tu jefe (a 90 euros/hora o mas por consultor, y costes de licencia impresionantes, creo que eso le vendieron a la web del congresoque salio por medio millon de leuros)

[#19 Desactivado]

alguien podía explicarme #3 como si fuera un niño de cinco años? gracias

[#21 Ferran]

#19 caca culo pedo pis

[#22 Desactivado]

#21 te falta un hervor.

[#25 Ferran]

#22 y a ti te falta sentido del humor

[#39 kurroman]

#19 Que va follao mientras no tengas que tener datos muy relacionados entre ellos

En lugar de tablas y filas con campos digamos que cada fila contiene un JSON. Cada fila es un documento y un conjunto de documentos una colección (que sería mas o menos una tabla).

[#24 AaLiYaH]

#1 Como dice #3 no es un sustituto de SQL.

Yo hice la certificación para desarrolladores Java y sinceramente me pareció que estaba muy bien, pero se pasaba todo el control de las formas normales, la integridad de la BBDD, transacciones, etc. a la parte de programación, es decir, a la CPU. Para esquemas muy complejos no me parece muy buena solución, aunque sí para esquemas de datos más o menos simples de clave-valor, en ese caso aumenta muchísimo el tiempo. Cuando empiezas a hacer joins en las tablas la complejidad se dispara.

Por cierto, el curso para desarrolladores Java fue un poco desastre. Los tíos son de Python basicamente, y muchos validadores de ejercicios (con lo fácil que es hacer un .jar) estaban en Python, por lo que te pedían instalarte y configurar Python (yo ya lo tenía hecho, pero es un paso extra que no tiene sentido). Por otra parte, más de una respuesta a los ejercicios er igual a las del curso de Python (que se había cursado un mes antes) o estaban directamente en los ejemplos de la propia documentación .

Eso sí, la certificación es completamente gratuita, un detalle que compensa lo demás.

[#34 Observer]

#24 En el de java también estaba la cosa de que utilizaban métodos de las clases que no estaban en el controlador.

El diseño del blog, al decir la cantidad de tablas con una base de datos relacional se les fue la mano en al menos dos de mas. Lo suyo no era precisamente las bases de datos relacionales.

PD: De todas formas, se nota que se integra mucho mejor con python que con Java o NodeJS

[#35 Zeioth]

#24 Que tio mas quejica, pero si python es un melocoton en almibar

[#37 Desactivado]

#35 Python es el Pascal del siglo XXI, otro lenguaje "educativo" más, de la línea de LOGO, BASIC, Pascal, Modula.

[#43 kahun]

#37 Claro, porque Python no se usa para nada en el mundo real, ...

[#44 Desactivado]

#43 Aha, porque claramente dije que no se usaba, ¿no?

En fin, una pena que confundamos los méritos de algo en sí, con la popularidad que tenga. Pero si ya te empeñas... http://lang-index.sourceforge.net/

[#45 kahun]

#44 Dime, ¿Pascal se usa en el mundo real?

[#46 Desactivado]

#45 ¿Has oído hablar de Delphi? Si te hubieses molestado en mirar el enlace que puse, verías que Pascal se usa más que JavaScript.
Claro que ninguno de ellos puede competir con BASIC... pero qué quieres que te diga, sigue con tu argumento a ver a dónde te lleva.

[#48 kahun]

#46 Ese enlace es tan fiable como las estadísticas de Alexa. Que Pascal se usa más que Javascript ... seguro, vamos, sin ninguna duda, prácticamente ya no hay web en el mundo que no tenga un par de líneas de Javascript pero claro no se puede comparar con el uso de Pascal ...

[#47 in0de]

#29 y no te vale la arquitectura con "delayed slaves"? Es algo que no entiendo. Si ya tienes una arquitectura shardeada es porque una máquina no rinde lo suficiente para tener todos los datos dentro, por lo que hacer un backup es una operación costosa (tanto en el palo que le mete a la máquina cuando hace el mongodump como el tamaño que ocupa).

En arquitecturas con sharding lo lógico es relegar en uno (o varios) esclavos y tenerlos retrasados 12/24h si tu oplog te da. Supongo que si estás haciendo backup no tendrás un 'throughput' tan grande como para no tener un oplog de 24h.

#24 ¿por qué dices eso? No vi ningún problema de integración con la integración del driver en Java. Además, utilizan las, tan de moda, fluent interfaces en casi todas las factorías.

Esta base de datos tiene sus cosas buenas y sus cosas malas. Hay que saber donde cojea y qué estás dispuesto a dar. En la empresa para la que trabajo la usamos bastante y ya hemos tenido algún susto y hemos tenido que hacer algún remiendo: http://samuelgmartinez.tumblr.com/post/42211065919/mejorando-aggregation-framework-mongodb

[#49 Observer]

#47 "y no te vale la arquitectura con "delayed slaves"? Es algo que no entiendo."
No estarás insinuando no hacer backups ¿verdad?
Eso seria el mismo error que no hacer backups porque tienes un raid.

"por lo que hacer un backup es una operación costosa (tanto en el palo que le mete a la máquina cuando hace el mongodump como el tamaño que ocupa)."
Para una cantidad grande de datos no utilices mongodump. Por el tiempo que puede tardar en crearse/restaurarse y porque es muy difícil que represente una copia de los datos en un momento dado(recuerda que no tiene snapshots).
El espacio no es importante, siempre será barato si lo comparas con perder todos los datos por no tener una buena politica de backups.

Ya puede ser malo perder 24h de datos si sucede algo, peor será si añades otras 12/24h de datos a esa perdida si lo haces de un esclavo que no tiene una copia actual de los datos.

[#50 in0de]

#49 si tú realizas un backup cada 24h es lo mismo que tener un esclavo con un delay de 24h y restaurar a partir de él. Así que no entiendo muy bien lo que dices . Bueno, igual, igual, no. Porque para el delay, el tiempo 't' de restauración es siempre 'delay', mientras que con snapshooting es (now.t - lastSnapshot.t).

No es cuestión de no hacer backup, es cuestión de tener un nodo con los datos de backup. Dicho nodo es un clon de cada réplica solo que N segundos por detrás. En los escenarios de bigdata (la de verdad, no 100Gb), es una práctica habitual delegar esto en las propias capacidades de replicación del sistema. (http://docs.mongodb.org/manual/core/replica-set-delayed-member/#replica-set-delayed-members)

Otro ejemplo de lo que te cuento es Hadoop. Normalmente no se mantienen snapshoots de HDFS fuera del propio sistema, si no que el propio backup se almacena en el mismo sistema que se backupea. (por ejemplo: http://hortonworks.com/blog/snapshots-for-hdfs/)

[#51 Observer]

#50
Del mismo enlace de hdfs que has puesto:
A snapshot is a point-in-time image of the entire filesystem or a subtree of a filesystem. Some of the scenarios where snapshots are very useful:
2 Backup: Admin wants backup the entire file system, a subtree in the file system or just a file. Depending on the requirements, admin takes a read-only (henceforth referred to as RO) snapshot and uses this snapshot as the starting point of a full backup. Incremental backups are then taken by doing a diff between two snapshots.

Las copias de respaldo nunca se guardan en la misma maquina y mucho menos en el mismo disco. A ser posible ni siquiera en la misma localización geográfica.
Una copia de respaldo es algo que solo se guarda. No modificas la copia para añadir las diferencias, haces una nueva o una incremental.
El tener el nodo con demora no sustituye a una copia de respaldo, solo la complementa igual que un raid no las sustituye, las complementa y te evitan tener que echar mano de esa copia.

[#52 in0de]

#51 el caso de HDFS lo que te quiero decir es que el propio snapshoot se está guardando en el mismo sistema que se backupea. El motivo es simplemente porque el sistema es bastante fiable a la pérdida gracias al esquema de como se guardan los datos. Así que el motivo de hacer un snapshoot es más para prevenir errores humanos (borrado manual de esos ficheros) que una recuperación ante una catástrofe.

[#53 Observer]

#52 El snapshot no es el backup, el snapshot no se puede mover del sistema en que se guarda porque son imágenes que se generan en el mismo disco.
Lo que puedes sacar es una copia de sus datos y es lo que se hace con esa imagen.

Como ya te he dicho, eso no sustituye a los backups, los complementa igual que lo hace un raid. Te permite recuperar datos de forma mas rápida que accediendo a una copia de seguridad pero no la sustituye.

[#54 Desactivado]

#53 Si tienes datos WORM con replicación por triplicado en distintos nodos Hadoop, no tiene mucho sentido añadir una cuarta copia a modo de "backup". Con realizar un snapshot para que no sean borrados, es más que suficiente.

No es exactamente comparable a tener los mismos datos sobre RAID, que suele estar en un solo nodo.

[#29 Observer]

#3 Necesitan simplificar algunas cosas a la hora de hacer y restaurar backups

El realizar backups y restaurarlo de un servidor o de un grupo de replicas es sencillo, hacerlo cuando distribuyes carga es otro cantar.
Detener el balanceo, hacer copias independientes de cada uno de los servidores manualmente y luego activar el balanceo de nuevo.

Y en equipos de 32 bits mejor no utilizarla, ya que el limite de las dbs para esas maquinas está en 2GiB y si lo superas el servidor se apaga y no puedes arrancarlo hasta que no borras esos ficheros(almenos hasta la 2.4.4 es así).

[#32 procesd]

#29 De acuerdo con lo del backup, pero respecto a los 32 bits, creo que tienen esa version solo para desarrollar, por el problema que has dicho y porque de hecho al ser monothread estas creando un cuello de botella con la CPU

[#31 kaoD]

#3 y la parte aún peor: ¡para ser NoSQL es lenta de cojones!

[#33 procesd]

#31 si, pero es que la idea no es aumentar la velocidad de un servidor de BBDD. La idea detras de mongodb es permitir escalar horizontalmente, es decir, cuando se te quede corto el servidor, en lugar de comprar una bestia de 20000 euros, comprar unos cuantos servidores basicos de 700

[#55 kaoD]

#33 pero eso no es una capacidad exclusiva de MongoDB, ¿eh? De hecho me gusta mucho más el escalado horizontal que permite PostgreSQL que MongoDB... y el de MariaDB con MyISAM tampoco es muy diferente al no tener capacidades relacionales. El sharding y la replicación no son inventos de MongoDB

La gran ventaja de MongoDB frente a otros NoSQL más rápidos es su facilidad para realizar queries, y que está más a medio camino entre SQL/NoSQL que por ejemplo Redis, que es un datastore puro y duro.

[#15 Desactivado]

#11 ¿Y qué tiene que ver que MariaDB se utilice aquí o allí en una noticia sobre MongoDB, un sistema que es totalmente diferente y que se gasta en casos específicos donde no es necesaria una BD relacional?

Es decir, si lo que querías era cagarte en MongoDB y decir lo muy guay que es MariaDB, pues no me parece correcto, más que nada porque la tecnicidades de un modelo de BD y otro no es de lo que trata la noticia ni es lo que se está discutiendo aquí. O sea, hablar de lo cojonuda que es MariaDB está totalmente fuera de tema aquí.

Otra cosa sería que te fueras a una noticia que hablase sobre las muchas cosas mejores que PostgreSQL tiene sobre MySQL a decir que MariaDB es mejor. El único problema es que no podrías hacerlo

[#10 Desactivado]

#7 ¿Te parece "relevante" colgar una 5 noticias sobre una base de datos SQL en una noticia sobre MongoDB?

[#11 silosenovengo]

#10 Sí: grandes proyectos de BBDD. Si quieres puedes colgar tú 5 noticias de grandes proyectos donde se haya implantado MongoDB.

[#18 Desactivado]

#11 MongoDB no tiene nada que ver con MariaDB . Son para cosas completamente distintas. No es viable la competencia ni la comparación entre ambas.

[#1 Desactivado]

Hay vida más allá del SQL...

[#2 lordeath]

#1 Yo los veo aún por las empresas usando DBFs... viendo que SQL les queda lejos.. un NoSQL es un invento del tebeo

[#12 ktzar]

Para el que quiera aprenderlo. Un libro rápido sencillo y gratuito.

http://openmymind.net/2011/3/28/The-Little-MongoDB-Book/

[#26 Dikastis]

#7 ¿Traer a María o traértela fumada de casa?

[#17 Desactivado]

Espero con regocijo las futuras ofertas de empleo de infojobs redactadas por los patanes de recursos esclavos pidiendo becarios con 2 carreras y 5 años de experiencia en mongodb para un contrato en practicas en empresa lider en su sector.

[#27 Desactivado]

¿Nadie va a decir nada del nombre? Desde luego hay que tener poca visión comercial para llamarle MongoDB. Podían haberlo llamado MonguerDB

[#8 Desactivado]

¿En qué se diferencia de Apache Cassandra? Ahora mismo estoy trabajando muchísimo con Cassandra + Hadoop

[#9 kahun]

#8 Aquí tienes una comparativa de las distintas bases de datos NoSQL: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

[#16 Desactivado]

en decharlas teneis una charla amena sobre nosql y mongo

y otra de mongo y con symfony

[#4 Desactivado]

A ver, aunque no utilice los mismos métodos que SQL para organizar los datos, sigue siendo una BD al uso. Lo que pasa es que tienen menos garantías de funcionamiento que si las necesitas debes implementadas por tu cuenta o encontrar sustitutivos equivalentes, aparte claro la forma de almacenamiento.

[#36 derecks]

Aunque ya lo comente alguna vez, para los que queráis empezar a usar MongoDB, CouchBase o incluso Node.js en esta web http://www.hispabigdata.es/ muestran bastantes ejemplos.

[#41 SeñorDonGato]

Llevo 2 horas intentanto arrancar el MySQL del xampp, y no me había dado cuenta de que ya tenia un MySQL instalado.
Ya se que no viene a cuento de la noticia, pero es he comentado a mi marido, no ha entendido una mierda de lo que le estaba contando y me tenia que desahogar con alguien.

[#20 Zeioth]

Mi forma de proceder favorita es crear una base de datos relacional, normalizarla, implementarla con mariaDB y ponerla en producción hasta que el sistema requiera mas rendimiento. Entoces, es el momento para plantearse una solución como mongoDB.

Tampoco tiene sentido matar moscas a cañonazos.

[#40 uberhumanista]

Tantas mariconadas, para al final volver al dBase, verás tú...

[#42 f5inet]

#40 yo aun espero el dia en el que el mundo de la programacion vuelva a Cobol... a este paso, no pasara mas de una decada.

[#5 silosenovengo]

Google está migrando a MariaDB
Google está migrando a MariaDB

Google está migrando a MariaDB

Red Hat abandona MySQL en favor de MariaDB [ENG]
Red Hat abandona MySQL en favor de MariaDB [ENG]

Red Hat abandona MySQL en favor de MariaDB [ENG]

La Wikipedia comienza a migrar de MySQL a MariaDB
La Wikipedia comienza a migrar de MySQL a MariaDB

La Wikipedia comienza a migrar de MySQL a MariaDB

Arch Linux es la siguiente en adoptar MariaDB después de Slackware, Fedora, OpenSUSE y Mageia
Arch Linux es la siguiente en adoptar MariaDB después de Slackware, Fedora, OpenSUSE y Mageia

Arch Linux es la siguiente en adoptar MariaDB desp...

Fedora y openSUSE cambiarán MySQL por MariaDB
Fedora y openSUSE cambiarán MySQL por MariaDB

Fedora y openSUSE cambiarán MySQL por MariaDB

[#6 DaniTC]

#5 ¿Te has dado cuenta que estamos hablando de MongoDB? Nada de MariaDB.

[#7 silosenovengo]

#6 Sí, por eso me parece relevante traer a María.

[#38 kurroman]

#5 No debiste venir