Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

Almacenamiento distribuido no relacional

La última moda disruptiva son los sistemas de almacenamiento distribuido no relacional pero ¿está realmente lista esta tecnología para dejar su etapa de adoptadores tempranos y entrar en una fase de uso generalizado mainstream?

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.

Comentarios
1 Eduardo Cabrera
12 julio 2009, 09:14

Por no mencionar la ausencia de esfuerzo en refactorizar el modelo de datos para (des/re)normalizarlo según sea lo más apropiado.

En mi experiencia, lo ecléctico vence: tera-petabytes de datos en modelos simples van mejor distribuidos, cacheados y no relacionales.

Cantidades similares y sobre todo inferiores de datos, bien estructurads y modelizados las gestiono con SGBDRs.

Mismamente esta pasada semana hemos postergado unos meses generar desde un TPS el correspondiente datawarehouse para continuar soportando análisis dinámico y cuadro de mandos que ¡lleva 1 año tirando directamente del TPS sin colapsar el proceso on line diario! Pero claro, la refactorización del modelo de datos de ese TPS es trimestral…

Un saludo


2 Alfredo Novoa
12 julio 2009, 20:56

Lo que pasa es que crear una birria de sistema de almacenamiento distribuido pre-relacional y pre-SGBD es infinitamente más fácil que crear un buen SGBD distribuido relacional.

Esto son solo productos de transición que en muchos aspectos son un enorme paso hacia atrás.

Todo el mundo sabe que no hay ninguna alternativa viable al Modelo Relacional y que probablemente nunca la haya.

También hay que separar el Modelo Relacional de las implementaciones que existen actualmente que son muy poco satisfactorias.

Un buen SGBD relacional tendría que optimizar bien hasta la consulta peor hecha, crear índices automáticamente en caso de necesidad y ajustar el modelo físico para que las consultas con multiples joins sean igual de rápidas que las consultas a una sola tabla.


3 Sergio Montoro Ten
12 julio 2009, 22:03

Yo no me atrevería a afirmar con tanta rotundidad que la arquitectura de Facebook o servicios similares sea directamente un “birria”.
Es posible que Facebook pudiere correr igual, o mejor, en un SGBDR, y que por coste, tiempo, u otros factores lo implementaran en PHP contra MySQL y Cassandra con memcached a saco.
La cuestión en ese caso creo que es ¿Podrían haber implementado Facebook sobre una infraestructura Open Source de SGBDR que fuese para ellos asequible en costes?


4 Alfredo Novoa
12 julio 2009, 23:06

Pues lo es sin duda, y que lo haga Facebook y similares es completamente irrelevante.

No es que sea posible que Facebook pudiese correr igual o mejor con un SGBDR, es que es una tautología. El rendimiento es siempre independiente del modelo lógico de datos.

Respecto a que haya sido una buena elección o no, pues es posible que sí lo haya sido. Si no encontraron un SGBD que les sirviese pues no les quedó más remedio que hacer una chapuza a pelo. O también es posible que lo hayan hecho así por ignorancia.

Para mi la cuestión es que el grupo nosql es un movimiento neo-ludita que quiere que volvamos a la oscura época pre-SGBD en lugar de que se mejoren los SGBD para que también sirvan para sitios como Facebook.


5 Eduardo Cabrera
12 julio 2009, 23:13

Suscribo tu último párrafo, Alfredo.

No estoy de acuerdo sin embargo con lo de que el rendimiento sea independiente del modelo lógico. Eso es sólo en teoría. En la práctica el modelo lógico elegido/diseñado implica una serie de dependencias del código, de la implementación del backend de datos, etc.


6 Alfredo Novoa
13 julio 2009, 00:32

Eduardo, estamos de acuerdo en que eso es así en la teoría.

En la práctica el rendimiento sigue siendo independiente del modelo lógico, pero no lo es del modelo físico.

Lo que pasa es que con los SGBD de los que disponemos la independencia del modelo lógico con respecto al modelo físico está muy poco conseguida. Entonces por una pobre implementación el rendimiento depende indirectamente del modelo lógico.

Cuanta más flexibilidad tengamos en la definición de los modelos físicos más nos acercaremos en la práctica a la independencia de la que nos habla la teoría (y menos necesitaremos las primitivas herramientas de las que estamos hablando).

El problema es que se está trabajando muy poco para conseguir esto.


7 Eduardo Cabrera
13 julio 2009, 14:07

Concordamos, Alfredo. El mundo TIC está en muchos aspectos en una continua huida hacia adelante y una vez que se consolida una tecnología (la relacional, mismamente) hasta el punto de estar en producción establemente (y muchas tecnologías, especialmente en el mundo de la web 2.0, a veces ni eso) ya se paran los esfuerzos en la consolidación y profundización de las bases de la tecnología y continuan en las features más absurdas que cualquiera proponga o abandere. Fuegos artificiales.

Si Oracle, un poner, hubiese dejado de invertir esfuerzos en grid y toda esa parafernalia, en atajos para dar rendimiento con pobres diseños del modelo lógico y se hubiese dedicado por ejemplo a profundizar en técnicas heurísticas de optimización de consultas complejas, en modularización del gestor para poder generar versiones ligeras para competir (en consumo y rendimiento, no hablo de mercado) con mysql y similares, en contribuir a la estandarización oficial de extensiones procedimentales abiertas del SQL porque tuvo una posición de privilegio para hacerlo, etc etc otro gallo nos cantaría y la base de facebook a lo mejor estaría sobre oracle pero lo más importante, el modelo relacional habría avanzado para ser la una base tecnológica más amplia aún.


8 Sergio Montoro Ten
13 julio 2009, 18:16

Oracle hace tiempo que ha dejado de ser una empresa de desarrollo de software. Ahora sólo son una gigantesca maquinaria financiera de engullir y asimilar otras empresas al estilo Borg.


9 Andrés Panitsch
18 julio 2009, 16:46

“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”.

… y a veces, a fuerza de darse contra la pared, terminamos aprendiendo que hay que pensar dos veces antes de hacer CUALQUIER COSA con SQL.

Ahora, si a los mismos monos con navaja que hacen delirios en sql les das un soporte de almacenamiento en el que no hay ninguna regla más que clave=valor y que encima NUNCA te va a obligar a optimizar nada porque no tiene problemas de performance…. yo no quiero hacer mantenimiento de esos sitemas.

Las bases de datos relacionales tienen un efecto colateral en el código, y es que hacen que éste, en general, sea un poco más prolijo, justamente pq hay que encapsular llamadas a store procedures, hacer una capa de acceso a datos, tener el sql separado para poder optimizarlo, etc. etc. etc. (esto no es SIEMPRE así, recalco, hablo “en promedio”).

No van a “matar a las bases de datos relacionales” por el simple hecho de que éstas tienen su ámbito de aplicación y las no relacionales el suyo propio, y si bien hay un espacio en el que se puede dudar entre una y otra tecnología, en el 99% de los casos es bastante claro lo que corresponde.


10 Alfredo Novoa
19 julio 2009, 22:05

Eso de encapsular llamadas a procedimientos almacenados y crear una capa de acceso a datos no tiene porque ser así. El promedio es que la mayoría de la gente no tiene mucha idea de como usar bien un SGBD SQL.

Las bases de datos relacionales tienen un ámbito muy grande, pero los productos concretos como Oracle o SQL Server tienen un ámbito bastante más reducido. No hay que confundir el Modelo Relacional con lo que implementan Oracle o Microsoft. Es más, estrictamente hablando ni el lenguaje SQL ni SQL Server ni Oracle son relacionales sino solo un sucedaneo.

Por cierto, he leido por ahí que Facebook sigue usando fundamentalmente MySQL y que eso de Cassandra lo usa solo para cosas muy puntuales.


11 Sergio Montoro Ten
20 julio 2009, 02:11

Si le prestas una excavadora a alguien, puede acabar matando a unas cuantas personas. Eso no implica que las excavadoras sean intrínsecamente inseguras, sino que su peligrosidad depende de quien las maneje. Y SQL es una excavadora muy grande.


12 Alfredo Novoa
20 julio 2009, 12:23

Pero tienes el mecanismo de seguridad del SGBD para recortar todo lo que quieras las posibilidades de los usuarios.

Lo malo es que hay muy poca gente que sepa usar esas cosas.

Si una base de datos está bien configurada te debería de dar igual si el usuario entra con una aplicación o con una consola SQL.


13 Sergio Montoro Ten
20 julio 2009, 12:53

Ya, bueno, pero lo de las limitaciones a los zambombazos es en teoría, porque ¿cuantas veces se ha visto una aplicación que lo primero que hace al abrir la pantalla inicial es SELECT * FROM EMPLEADOS? Y cuanto pones a optimizarla, simplemente quitas esa consulta que no sirve para nada y se está lanzando chopocientas mil veces, y mejoras el rendimiento de un plumazo.
Lo bueno de tener un API que funciona como un mapa asociativo que sólo puede recuperar un único valor dada una clave es que obligas al programador a pensar mucho más si realmente necesita recuperar un porrón de datos de golpe o se podría apañar con menos.


14 Alfredo Novoa
20 julio 2009, 14:04

Ah, te referías a eso.

Ya, hay muchas aplicaciones que hacen un uso poco eficiente el SGBD, y muchas herramientas de programación que te ocultan complejidad pero también son muy ineficientes. Yo me he llevado muchas sorpresas con el depurador viendo como eventos que tienen que leer de la base de datos saltan varias veces seguidas sin motivo.

Pero eso se soluciona examinando el log de las consultas a la base de datos y preguntandole al programador el por que de los zambombazos.

Lo del SELECT * FROM EMPLEADOS se soluciona haciendo paginación. Eliminar la consulta está bien en una aplicación Web, pero en una de escritorio es muy cutre.

Yo veo que hay muchas aplicaciones que están diseñadas para que el programador se complique la vida lo menos posible en lugar de para ser utilizadas cómodamente. Lo que hay que pensar es si el usuario necesita que se recuperen un porrón de datos de golpe.

Lo de una API que solo puede recuperar un único valor dada una clave es trogodítico total.


15 elmundoalreves
22 julio 2009, 23:43

Me paso la vida revisando código y echando broncas de por que se hacen las select de tal o cual forma en pl/sql, jsps o clases.

Cuando veo subselects o uniones siempre digo sin pensar “está mal”, desgraciadamente suelo acertar en un 99%.

Si se hacen chapuzas o se trabajan en lenguajes que no se domina, dará problemas sea cual sea el sistema que utilices.


16 Alfredo Novoa
23 julio 2009, 19:13

Una consulta está mal cuando no devuelve los resultados esperados.

Si el optimizador no es muy bueno y hace falta escribir las consultas de una forma determinada para que sean más rápidas, es sobre todo un problema del producto. Se supone que el optimizador está para que solo tengamos que preocuparnos de que las consultas sean correctas y no óptimas para un SGBD en particular.


Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.