Barrapunto

...enhorabuena por contribuir así.

Ahora bien, ¿seguro que tus benchmarks son correctos?

Comparar bases de datos MySQL con transacciones y demás a bases de datos NoSQL no es correcto.

Cada cosa, para lo que es. Si MySQL es más lento o más rápido grabando una serie de millones de registros seguidos, es por alguna razón, no porque los programadores no sepan programar con el rendimiento en mente. Es simplemente que no se puede hacer (mucho) más rápido. Y lo mismo para PostgreSQL, Oracle y demás.

Una "base de datos" como MongoDB es simplemente un fichero JSON escalable, replicable, etc. Que está muy bien, si sólo necesitas eso.

sus benchmarks son correctos?>

Sí, lo son. Dos posibilidades para un problema que las dos pueden resolver. Lo que no se podría comparar es que tal bien resuelve MongoDB las foreign keys si no las implementa.

Comparar bases de datos MySQL con transacciones y demás a bases de datos NoSQL no es correcto.

¿Ah no? Quizás sea correcto pero no te guste. ¿Cuanto tiempo tarda vi en abrir un documento para su lectura y cuanto tarda Word/Write? Ahh, claro, que no son comparables, uno es un editor de textos y otro un procesador de textos. Para el señor que solo quiere leer un documento y que el programa que utilice sea el más rápido, seguro que la distinción es importante.

Para mí lo que ha sacado este caballero es algo que ya estaba más que asumido, pero ha tenido la gentileza de hacerlo, documentarlo y ponerlo a mi disposición, y por eso se lo agradezco y mucho.

Si MySQL es más lento o más rápido grabando una serie de millones de registros seguidos, es por alguna razón, no porque los programadores no sepan programar con el rendimiento en mente

Vaya vaya, quizás esa razón sea la misma que hace que MySQL para agrupar por más de un valor sea un auténtico caracol, o que para ejecutar una subquery, una babosa recorra antes toda la calle, o que la diferencia sintáctica de hacer 1000 inserciones seguidas insert into en lugar de hacer insert into (), () ... de lugar a una caída del rendimiento de 6000%.

Una "base de datos" como MongoDB

y ahora toca el desprestigio. Puedes leer que MongoDB [wikipedia.org] es Document-oriented database en lugar de Relational database, así que "bases de datos" como las conoces tú ya vienen explicadas desde hace mucho en los libros de "bases de datos" tradicionales.

¿Sabes el dicho "matar moscas a cañonazos"?
Al 99'9 % de los programadores no saben ni lo que es el rendimiento y van muy de divas, cóctel explosivo.

Lo mismo se aplica a los programadores nosql, que son programadores igual y también van de divas. Jamas en la vida del 99% de los informáticos se les quedará corto el SQL.

En mis tiempo eran los oracle de licencia gold sobre solaris, para paginas web estupidas donde se pulieron millones para cerrar al año. Y estos miraban por encima del hombro a los linux/mysql. Y ahora son los java/mysql los que miran por encima del hombro a los nodejs/mongo.

Al final todo se reduce al ego y la moda de turno.

Tienes toda la razon, cada cosa para lo que es.

Las soluciones NoSQL [wikipedia.org] se emplean cuando se tratan cantidades masivas de datos (pensemos en Facebook, Twitter, Google ...) y el rendimiento en las lecturas y escrituras es algo crítico. Imagínate, por ejemplo, que estas recogiendo de forma continua resultados de diferentes sistemas repartidos por todo el mundo y pretendes obtener una visión global.

Para aquellos problemas en los que la integridad referencial no es algo prioritario (por que no nos interesa gestionar relaciones entre tablas o preferimos repetir datos) las bases de datos relacionales no son la solución más indicada.

Con estos tests he querido comparar la solución que actualmente empleamos (MySQL con tablas MyISAM) con uno de las muchas opciones posibles NoSQL, en este caso MongoDB [mongodb.org] para gestionar la información contenido en logs.

Esta es la primera incursión en el mundo NoSQL Open Source de mi empresa y de lo que se trata con este trabajo es de verificar si tal y como se dice, una solución NoSQL es más recomendable. Y con cifras concretas. Estamos centrando el estudio, por tanto, en un contexto muy particular.

Fíjate que en la tercera transparencia de la presentación [ciges.net], "Why NoSQL?", la imagen incluída es una imagen que muestra la frase "Not Only SQL". Con esta imagen destaco el hecho de que no buscamos un sustituto de los servidores de bases datos relacionales "clasicos" que usan SQL si no un complemento. Queremos ampliar nuestro arsenal de herramientas y sobre todo, tener una idea clara de cuando emplear una u otra.

De hecho, en las conclusiones MySQL gana a MongoDB a la hora de obtener informes basados en consultas agregadas ("group by" en SQL), con lo que para una aplicación en la que se usara de forma intensiva consultas agregados MySQL sería más conveniente.

Podemos ir más allá (y habrá que hacerlo) y dada la variedad de tipos y soluciones NoSQL disponibles en función del problema deberíamos emplear uno u otro sistema de gestión de bases de datos (CouchDB, Riak, Cassandra, HBase, Redis .... por citar sólo unos cuantos).

Buff! Acabamos simplemente de empezar, el mundo BigData [wikipedia.org], el de tratamiento de grandes cantidades de datos es simplemente enorme. Nos queda mucho por aprender, y éste pretende ser el primer paso.

Un saludo