El movimiento NoSQL va cogiendo fuerza
Patxi Echarte,
23. Jul, 2009,
4 Comentarios
Otros Informática
Este mes de Julio está siendo especialmente movidito en el ámbito de las bases de datos, a raíz de un encuentro en San Francisco, en el que se han reunido alrededor de 150 desarrolladores partícipes de la comunidad «nosql». El objetivo del encuentro era presentar a los participantes el funcionamiento de las bases de datos distribuidas no relacionales, así como un repaso a diversos proyectos existentes.
En Computerworld, en su artículo No to SQL? Anti-database movement gains steam hacen un interesante repaso de las características de este movimiento.
Los miembros de esta comunidad comparten una visión común en cuanto a que los sistemas de bases de datos relacionales (RDBMS) clásicos son lentos, complejos, caros e ineficientes para muchos de los problemas existentes en las aplicaciones de Internet actuales, especialmente en el ámbito de la Web 2.0 y las redes sociales. Frente a estos sistemas clásicos, proponen la utilización de sistemas más eficientes y baratos para gestionar la información, como los almacenes de datos basados en clave-valor como BigTable (Google) o Cassandra (Facebook), o incluso almacenes en memoria como Memcached, la utilización de shardings sobre estos almacenes para ofrecer almacenamiento distribuido, y sistemas como Hadoop que permitan el trabajo sobre estos almacenes distribuidos.
Hay de todo en este mundo… un «movimiento no-sql»… lo que me faltaba oir 😀 😀 😀
A ver si algún día me entero cual es la alternativa
Pues la verdad es que no creo que Facebook esté hecho usando bases de datos no relacionales.
Por otro lado MySQL no me parece ni lento ni complejo, ni caro ni ineficiente. Estoy de acuerdo en que muchas veces se peca de sobreingenieria y se intentan hacer unos sistemas demasiado complejos para lo que se necesita. Por ejemplo, en Java, usar los framework y que todo funcione correctamente es un infierno para mi gusto, pero las bases de datos relacionales, en mi opinión son completamente necesarias para mantener una integridad en los datos y que no se te valla al garete toda la información.
Aún así pienso que los nuevos sistemas de almacenamiento distribuido son interesantísimos, pero no creo que se hayan pensado para sustituir a nadie, sino para convivir ellos.
Saludos!!
Efectivamente David, este movimiento no plantea la sustitución de los sistemas relacionales, sino que su aplicación a todo tipo de problemas de almacenamiento de datos tal como se ha estado haciendo hasta ahora no es la mejor solución en algunos casos. Por ejemplo plantean que las bases de datos relacionales escalan correctamente hasta varios cientos de servidores pero empiezan a ser menos eficientes a partir de estas cifras, sobretodo debido a características como ACID y los commit en dos fases de las bases de datos distribuidas. En en muchas redes sociales y webs de la Web 2.0, hace falta manejar mucha más información, por lo que se plantea la utilización de miles de servidores pequeños que no utilicen bases de datos relacionales, sino sistemas de almacenamiento en disco o incluso en memoria, que permitan un manejo más eficiente de los datos, a costa de perder alguna de las características clásicas de las bases de datos relacionales, como la atomicidad y que la consistencia de la bbdd no sea determinista sino estadística. Con este sistema Google es capaz de manejar varios Petabytes de información todos los días con BigTable y lo mismo hace Facebook con Cassandra. Pero esto no quiere decir en ningún caso que sea conveniente utilizar estos sistemas para todo, es simplemente una tecnología más que hay que conocer y saber aplicar.
Me parece genial que muchos administradores y diseñadores vean más allá de los Oracles y los MySQL, porque en muchos casos el modelo relacional no es suficiente (o se usan ORM). No obstante, el hype aquí es «las bases de datos están muertas», «la integridad relacional no es útil» y «todos los sitios web son como Facebook». Evidentemente, para cada problema una solución.
Alguien dijo una vez que la optimización prematura es la base de todos los males, y creo que apicándolo al almacenamiento de información es cierto. Hay una decisión muy importante antes de elegir un DBMS, y es si vamos a mantener la estructura de la información. Por ejemplo, si usamos MySQL con un ORM o escribiendo consultas manualmente podemos hacer una traducción relacional-objeto, si nuestro software es OO. Sin embargo, podemos seguir usando MySQL y no almacenar nuestros objetos en tablas separadas, sino en un esquema fijo, como hace eZ (PHP), lo que permite mantener versiones, traducciones y status de los objetos.
Fuera de las bases de datos relacionales, si queremos mantener los esquemas de la información podemos acudir a bases de datos orientadas a objetos, pero fuera de ahí (clave-valor, BD orientadas a documentos como CouchDB) nos vemos obligados a descomponer la información desestructurándola en cierto sentido, lo cual puede ser una gran ventaja en rendimiento (como lo puede ser también no utilizar POO en aplicaciones web) pero una desventaja desde la mantenibilidad del software y las buenas prácticas «de toda la vida».