James Gosling y la reinvención de la rueda
domingo, mayo 15, 2011 at 9:06PM Leía el artículo aquí en JavaHispano sobre las últimas declaraciones de James Gosling y me llamaron mucho la atención tres cosas:
1) Que cualquier cosa, brillante o tontería como un piano, que diga James Gosling va a generar montones de rios de tinta electrónica.
2) Que la retrotecnología está de moda.
3) Que esta industria tiene un NULO sentido histórico, la frase de Newton "sobre hombros de gigantes" apenas se aplica, asusta leer como "nuevas" ideas tienen décadas de historia detrás.
El propósito de este artículo de opinión es el de reflexionar sobre los procesos de creación (y adopción) de tecnología, nuestro sector es uno de los pocos en los que podríamos hablar de que existe una, en mi opinión, inmadurez crónica, de otra manera es difícil de entender ciertas tendencias, tendencias que afortunadamente en algunos casos no duran mucho.
Y no, no estoy pensando en que NoSQL es una tendencia pasajera, al contrario, el que las bases relacionales sean la tecnología abrumadoramente mayoritaria hace pensar que el mundo IT es mucho menos innovador y rico de lo que parece.
Sin embargo en cierto modo algunas opciones del mundo NoSQL en mi opinión sufren de un síndrome de reinvención de la rueda brutal, y en esa reinvención tienen mucho que ver las palabras de Gosling sobre las bases de datos "en memoria", y esto lo digo por el comentario sobre Redis en el hilo de JavaHispano:
por defecto todo en memoria con snapshots cada segundo. Si se cae el servidor pierdes los datos generados en el último segundo. Con esta configuración tiene un rendimiento de 100.000 operaciones por segundo en una máquina normalita.
Alguien que leyera este comentario en los años 70 pensaría "es genial", en esos años los volúmenes de datos que manejamos hoy día no tenían nada que ver, los requisitos en transaccionalidad no son los de hoy en día etc etc, pero es que estamos hablando de 2011 en donde una tecnología pretende venderse como novedosa:
1) Intentando cargar todo en memoria
2) Guardando los cambios durante un periodo de tiempo de una vez
Es decir, podríamos hablar de una base de datos de los años 70, es decir:
1) No preparada para grandes cantidades de datos
2) Transaccionalidad dudosa (transacciones ya realizadas realmente no han sido guardadas).
Evidentemente alguien cercano a Redis matizará y dirá "se puede ajustar el tiempo de snapshot y sólo cargar parcialmente los datos en memoria", es decir, si buscamos transaccionalidad segura la unidad de registro persistente será de 1 operación, o al menos no volveremos de la llamada persistente hasta que haya seguridad de que se ha escrito en archivo, lo cual disminuirá mucho el rendimiento, y a su vez cobrará especial relevancia en procesado multihilo para no parar absurdamente el motor de la base de datos (pues algunas de estas bases de datos presumen de lo que yo llamo "mono-hilo mágico").
Por otra parte si sólo cargamos parcialmente la base de datos en memoria porque el archivo de datos es muy grande, entonces ya no hablamos de una base de datos en memoria sino más bien de una caché, y por tanto el rendimiento fabuloso disminuye drásticamente al ir a buscar datos de archivo.
Es decir al final poco a poco vamos creando de nuevo una base de datos más... convencional, es decir una rueda que se parece mucho a la rueda que queremos substituir...
El comentario de supertorpe me parece magistral:
Lo que pasa con las Hashtables es que luego vas a querer transacciones y vas a tener que montar un sistema transaccional a mano. Después vas a querer persistencia para no perder los datos. Después vas a empezar a crear métodos para simplificar la creación de consultas a la hashtable, para devolver datos relacionados y vas a acabar creando un DSL para ello. Después vas a querer que varios usuarios accedan concurrentemente y vas a crear una arquitectura y unos protocolos de acceso por encima para soportarlo. Después... vas a acabar implementando un sistema de gestión de BBDD a mano, eso sí, con unas Hashtables en memoria en su núcleo :D :D :D
¿Esto significa que las bases de datos NoSQL no aportan nada que merezca la pena?
NO, pero el aspecto diferencial está en el PARADIGMA, sólo se puede competir con las bases de datos relacionales a través de paradigmas diferentes, el paradigma relacional por ejemplo es MUY difícil de escalar porque requiere que todas las tablas estén "juntas", cuanto más escalas a base de partir la base de datos "menos relacional" es y más sentido cobran las alternativas.
Pero competir con el paradigma relacional sólo es posible aportando al menos similares resultados en rendimiento unido a fiabilidad unido a capacidad de gestionar ingentes cantidades de datos (ya que en flexibilidad es un terreno muy díficil), no en argumentos tipo "base de datos en memoria, snapshots cada segundo y proceso mono-hilo" que suenan a Oracle v0.1 pues por ejemplo ¿es que creemos que los de Oracle son idiotas y no tienen una enorme caché en memoria?
Es en el terreno de la flexibilidad donde yo creo que las bases de datos NoSQL tienen un largo camino que recorrer, como dice janatic (peloteo mode-on)
"la gente que lo hace es muy pragmatica y no reniega del SQL. De hecho están haciendo muchos esfuerzos para incluir en lo posible funcionalidades típicas de SQL"
Porque la escalabilidad y el rendimiento no lo es todo, también es importante la extracción de datos de mil combinaciones posibles y ahí quizás la rueda no esté inventada.
Volviendo a la reinvención de la rueda, leyendo las palábras de Gosling sobre "bases de datos en memoria", Gosling está hablando de un único nodo a la vez "cliente y servidor" haciendo operaciones él solito en memoria y archivo. Vale muchos ya han mostrado que eso es una tontería como un piano por mucho Gosling que lo diga... ¡O NO! cuando lo leí pensé "joder pero si eso bien hecho y de verdad ya está inventado desde hace más de 15 años ¡¡Y YO LO HE USADO!!", y estaba pensando en ObjectStore y su cache forward cuya idea básicamente es que el servidor envía de forma asíncrona una parte de la base de datos a la memoria del cliente (de los clientes) y que no es exclusiva de ObjectStore.
Pero claro estamos hablando de bases de datos orientadas a objetos
* que no son nuevas (no nuevo=no molo)
* que encajan exactamente en el modelo de datos orientado a objetos sin impedancia con la base de datos (¿para qué si hay bases de datos sin esquema y mis aplicaciones son tan dinámicas que no uso esquemas basados en clases?)
* que son particionables automáticamente pues cada dato persistente puede saber donde está físicamente el relacionado incluso en un archivo diferente (¿para qué si hay trucos tan ingeniosos como los números hash?.
* gestionadas por empresas propietarias que están felices y contentas con sus nichitos de mercado
Con esto no quiero decir que las bases de datos orientadas a objetos sean una "gran opción", las empresas que hay detrás (Progress, Versant) quizás no se lo merezcan dado su enorme desinterés es favorecer su propio mercado (no hay más que ver como dbObjects de Versant ha casi desaparecido del mapa).
Volviendo al tema Gosling, ahora que resulta que la "tontería" de Gosling no es tan tonta y resulta que es una técnica madura y que funciona (aunque ni mucho menos en la versión simplona del ejemplo de Gosling), es cuando merece la pena repensar en reinventar la rueda y empezar a superar el modelo de cliente tonto relacional JDBC mero "forwarder" de cadenas SQL en el que hemos vivido tantos años y quizás pensar en una nueva generación de bases de datos verdaderamente transparentes que residan parcialmente en el cliente en donde una simple Collection.size() no suponga cargar toda la colección como ocurre en los inevitablemente tontorrones Hibernate y JPAs... quizás el nuevo Hibernate vendrá por la via de DataNucleus JDO...
Aunque lo siento para llenar ese hueco siempre me vienen a la mente bases de datos orientadas a objetos... ¡joder qué fijación!