SQL + Hadoop para hacer páginas web y aplicaciones móviles

[Iván de Praadoo]

Últimamente no hacemos más que poner aquí cosas que hacemos :P No me gusta, parece que estamos siempre auto-promocionandonos... 

Pero en fin, nos gusta compartir con la comunidad hispana lo que hacemos. Y hemos liberado otro proyecto Open Source: Splout SQL. Una base de datos escalable que se integra con Hadoop, y que permite realizar páginas webs o aplicaciones móviles a partir de volúmenes de datos Big Data. Por resumir, si quisieras realizar un Google Analytics, te haría falta un Splout SQL. 

Aquí tenéis toda la información sobre el proyecto: http://www.datasalt.es/2013/01/presentando-splout-sql-un-conector-sql-de-muy-baja-latencia-para-hadoop/

Por compartir otras cosas interesantes que he visto por ahí en los últimos días: 

- Tempo DB (http://tempo-db.com/) -> BD en la nube para series temporales muy largas, por ejemplo para sensores. 

- Joyent (http://joyent.com/) -> nuevo proveedor de cloud que compite con Amazon

- http://www.wired.com/wiredenterprise/2012/08/google-as-xerox-parc/all/ -> la historia de Jeff Dean y otros ingenieros de Google. Menudos piezas. 

Un saludo!

Iván

[Roberto Morandeira Aparicio]

Hola,

Muy interesante. Me surge una duda. 

Al margen de la integración con hadoop y el potente sistema de deploys, que ventajas ofrece sobre una solución newsql como VoltDB? Especialmente en el tema de consultas, y teniendo en cuenta que es de sólo lectura, al contrario que VoltDB. Es que leyendo el artículo tengo la impresión que el particionamiento elegido limita las consultas que se pueden realizar,  ya que como indicas sólo se pueden realizar consultas sobre una partición. Si no me equivoco, en VoltDB se lanza la query sobre todos los nodos y se agrupa el resultado. Entiendo que el objetivo es muy distinto y no se pueden comparar.

Enhorabuena por Splout y  por el artículo en highscalability.

Un saludo

[Pere Ferrera]

Hola Roberto,

Buena pregunta.

Se trata de un tipo diferente de sistemas. Nosotros tenemos experiencia en sistemas cuya lógica de proceso está basada en batch, usando Hadoop. Por eso nos interesan las bases de datos que puedan servir fácilmente datos generados por Hadoop. Como la lógica "dura" la pones en Hadoop, la base de datos no hace falta que sea muy compleja ni que pueda responder queries muy sofisticadas - ya que lo "complicado" normalmente lo pre-calculas. Es una manera de hacer las cosas que encaja bien con bastantes problemas Big Data, aunque no con todos.

Por otro lado los sistemas basados en NewSQL y demás (lo que se podría llamar "database-centric" systems) ofrecen algo que un sistema en Hadoop no puede ofrecer: real-time. El coste que pagas por ello es, generalmente, un sistema más complejo. La complejidad suele venir de mantener el estado en la base de datos, y ejecutar la lógica "dura" de tu sistema de manera incremental. Suele haber problemas, corrupción de datos, errores de programador, etc. Pero para según qué tipo de problemas no queda otra, es lo que hay.

Yo siempre digo que si el problema Big Data que vas a resolver no requiere real-time (los datos se pueden actualizar una vez al día, por ejemplo), suele ser más sencillo tirar por una solución batch. Al guardar todos los datos en plano, puedes recalcularlo todo bajo demanda y eso te da mucha libertad y seguridad.

Un saludo,

2013/1/17 Roberto Morandeira Aparicio <roberto.m...@gmail.com>

[Iván de Praadoo]

Por aportar algo más, veamos algunas caracteristicas de VoltDB (una BD muy interesante, por otro lado):

VoltDB es una base de datos particionada en memoria que soporta transacciones y cuya principal ventaja es la velocidad. La razón proviene de su peculiar arquitectura. Los datos en VoltDB están particionados (como en Splout SQL). Las queries en VoltDB han de ser precompiladas a un JAR (al menos aquellas que quieras que soporten transacciones). Esta es la particularidad más importante de VoltDB. Y es que VoltDB soporta transacciones gracias a tener un único hilo de ejecución por cada partición. Así pues, es seguro que la ejecución de una función precompilada con varias consultas SQL se va a ejecutar en situación de aislamiento en determinada partición. 

Esta peculiar arquitectura es lo que hace de VoltDB una BD muy atractiva para situaciones con grandes volumenes de transacciones no complejas, como por ejemplo cotizaciones bursátiles. Ahora bien, pensemos en las debilidades:

1) Las transacciones solo valen para datos que estén en la misma partición. En otros casos con datos en varias particiones, supongo que las transacciones no son posibles (lo desconozco). En cualquier caso, ya no serían tan eficientes. 

2) El particionamiento es algo clave en VoltDB. Por lo tanto, queries que ataquen datos de varias particiones, aunque quizas posibles, no creo que sean muy eficientes, sobre todo si las realizamos baja mucha carga. 

Splout SQL vs VoltDB

Y ahora volvamos  la comparación con Splout SQL. Algo que comparten ambas BD's es que en ambas los datos están particionados. Diferencias:

1) VoltDB es en memoria. Splout puede hacer uso de disco -> Splout puede almacenar más datos

2) VoltDB no se adapta bien a un sistema batch donde los datos se generan en Hadoop. Si bien últimamente han añadido capacidades de exportación a Hadoop (http://blog.voltdb.com/sqoop-voltdb-export-and-hadoop-integration/), lo que no parece que fuese a funcionar muy bien sería la importación desde Hadoop, que es justamente el punto fuerte de Splout SQL. ¿Por que no funcionaría bien? Imaginemos el caso de un sistema de recomendación, en el que los datos (los scores de cada item/usuario) cambian completamente de un día para otro. Hadoop podría generar los nuevos scores, pero cada día debería importar todos esos scores de nuevo a VoltDB. Esto generaría una grandísima carga en VoltDB, afectando a su servicio habitual de queries. Y por otro lado, los datos, durante la importación, permanecerían inconsistentes, con ciertos usuarios con los nuevos scores y otros aún con los antiguos. 

3) Splout SQL no soporta transacciones, ni siquiera operaciones de actualización/inserción. Todo ha de hacerse via Hadoop

4) Splout SQL no soporta queries fuera del particionamiento elegido. Una query se ejecuta sólo en el espacio de una partición. Así pues, si ha particionado por "cliente", no vas a poder hacer queries agregadas por "ciudad". Creo que VoltDB si soporta esto (no estoy seguro). Más de esto en el siguiente punto.

Particionamiento y limitaciones

Roberto, en tu email indicas que consideras que elegir el particionamiento podría limitarte tu campo de actuación. Tienes razón. Consideremos un dataset con ofertas de trabajo. Podrías particionar por empresa, y entonces servirías queries como "todos los trabajos ofertados por una empreas" de modo fantastico... ¿Pero y si luego quieres una query que permita revistar todos los puestos de trabajo en determinada población? Con ese particionamiento no podrías. 

Eso se soluciona muy fácil en Splout SQL, ya que es muy sencillo crear varios "Tablespaces" con los mismos datos pero diferente particionamiento. Así pues, lo normal será que cada aplicación tenga el mismo dataset particionado por aquellas dimensiones que le van a ser habituales. Para el ejemplo, habría un tablespace particionado por "empresa" y otro particionado por "población". 

Esto naturalmente duplica el numero de datos a servir... Pero esto es tan barato en un sistema Hadoop, frente a la ventajas que aporta (aseguramiento de los tiempos de respuesta y rendimientos para cualquier volumen de datos), que es de lo más conveniente. 

Y es que, no hay ningún particionamiento que salga grátis... si en VoltDB eliges particionar por "empresa" y luego haces una query por "población"... ten seguro que los tiempos de respuesta no serán tan buenos y no soportará tanta carga... Y tener multiple particionamiento en VoltDB, como tenemos Splout SQL no creo que sea posible. Esto se puede extender a cualquier BD distribuida en la que haya un particionamiento (que son casi todas).

Bueno, vaya parrafada :P

Iván

2013/1/18 Pere Ferrera <ferrera...@gmail.com>

[Roberto Morandeira Aparicio]

Muchísimas gracias a los dos por vuestras respuestas.

Un saludo