por Sergio Montoro Ten, 11 julio 09

Los sistemas de almacenamiento distribuido no relacional no son algo nuevo. Google lleva muchos años proporcionando servicio basado en sus granjas de servidores clónicos procesando la información con MapReduce e Hypertable (aunque los servidores individuales siguen llevando cada uno una base de datos MySQL). Pero quizá a sido Facebook (otro servicio que usa MySQL) el que ha marcado un punto de inflexión. Desde que se liberó Cassandra en Apache ha habido una proliferación de los sistemas de almacenamiento distribuido mayor que nunca: Voldemort , HBase , CouchDB o mongoDB sólo por citar algunos ejemplos. Esfuerzos que han culminado en la aparición del grupo nosql en contra de las bases de datos relacionales. En ComputerWorld Eric Lai compara la disrupción de los sistemas de almacenamiento distribuidos con la revuelta bostoniana por los impuestos del té de 1773 mientras que al mismo tiempo muestra informes que afirman que una base de datos relacional paralela es más de seis veces más rápida que MapReduce

Algunos argumentan que las bases de datos relacionales ofrecen demasiadas funcionalidades, mientras que otros opinan que todas esas funcionalidades son necesarias, y que implementarlas por fuera del SGBDR es igualmente costoso, si no más, que hacerlo dentro.

Una cosa al menos si está clara para mi, y es que el futuro del almacenamiento de datos es necesariamente distribuido y con una o varias capas de caches de gran tamaño.

Ciertamente, el maridaje entre el SQL y los lenguajes procedurales de programación nunca ha sido muy bueno requiriendo middleware extraño como JDBC y mapeos objeto-relacionales nunca del todo bien conseguidos.

Pero quizá el problema de fondo de las bases de datos relacionales no sea tanto su rendimiento o sus interfaces de programación como lo fácil que es abusar de ellas. Es cierto que muchos sistemas de información basados en una base de datos relacional requieren un servidor ENOOORME que cuesta una millonada. Pero no es menos cierto que ello se debe en la mayoría de los casos no a la propia tecnología de la base de datos sino a que cuando analizar el SQL te das cuenta de que le está metiendo unos zambombazos al SGBDR del calibre de un pepino nuclear, sobre todo en forma de joins múltiples, búsquedas por campos sin indexar, y exceso de tráfico de datos entre el cliente y el servidor.