SploutSQL: Una base de datos SQL sobre Hadoop!

(Luis, Paco, Julián! este tenemos que probarlo :D)

SploutSQL es una base de datos SQL (quizás viendo su arquitectura este no sea el término más correcto 🙂 ) sobre Hadoop que ofrece muy baja latencia (menos de 1 s).

Esta slide resume conceptualmente lo que pretende:

SploutSQL tiene una Arquitectura muy diferente a otras piezas enfocadas a permitir las consultas sobre infraestructura Hadoop estilo Impala.

SploutSQL desacopla la creación de la base de datos del servicio de esta (usando Pangool), lo que permite que la actualización de los datos no afecte al servicio de estos.

Sus principales características son:

· Funciona sobre Hadoop: permitiendo cargar ficheros con Hive, Pig, fs,…

· Interfaz 100% SQL: soportando JOINs, agregaciones real-time, aunque limitado a una Partición:

· Latencia Web: Cualquier agregación en tiempo real debería poder ejecutarse en menos de 200 milisegundos aún con muchos usuarios concurrentes.

· Escalado Horizontal:. Añadiendo más nodos se puede incrementar el rendimiento linealmente. Splout coordina un clúster de máquinas para proveer tolerancia a fallos en caso de particiones de red o hardware corrupto.

· Fácil de manejar

· API avanzada Java

· Interfaz Restful que devuelve JSON

· Línea de comando y Consola

· Open Source

Su versión actual es la 0.2.5 que podéis descargar desde este repositorio de Maven: http://search.maven.org/#browse%7C-1223220128 y ejecutar de una forma tan sencilla como:

Un escenario de uso de Splout es el análisis de los eventos recibidos, que con Splout podría resolverse:

En esta presentación podéis ver un resumen completo de lo que ofrece.

Si estáis interesados podéis probar a ejecutar su Getting Started.

También es interesante el benchmark que han desarrollado cargando 350 Gb de datos del “Wikipedia pagecounts dataset” y el throughput que se consigue con un cluster de 2 máquinas (cada una con 175 Gb de información) que llega a las 868 queries/segundo o con 4 máquinas donde se llegan a las 3156 operaciones/segundo.

Tratamiento de Errores en APIS RESTful

Existen diversas aproximaciones al tratamiento de Errores en REStful.

Veamos varios ejemplos:

Facebook por ejemplo siempre devuelve un 200 (OK),

Twilio alinea los errores con los códigos de estado HTTP y además devuelve un código de error propio.

SimpleGeo también devuelve código estándar pero sin valor adicional.

Siguiendo las recomendaciones de Apigee

las recomendaciones a la hora de modelar errores en nuestro API Web serían:

Usar códigos de estado HTTP

Usar códigos de estado HTTP e intentar mapearlos con códigos relevantes de la aplicación.

Existen 70 códigos HTTP que nadie conoce completamente, por lo que se usará un subconjunto de estos.

Códigos de estado HTTP a usar

Existen 3 códigos básicos:

  • Todo OK
  • Error de aplicación à error cliente
  • Error del API à error servidor

Que mapearemos así:

  • Todo OK à 200 (OK)
  • Error de aplicación à 400 (Bad Request)
  • Error del API à 500 (Internal Server Error)

Adicionalmente podemos usar:

  • 201 – Created
  • 304 – Not Modified
  • 404 – Not Found
  • 401 – Unauthorized
  • 403 – Forbidden

Devolver mensajes detallados en el payload

Publicado en API, Web. Leave a Comment »

Estudio Comparativo de RDF Stores

Aunque el informe

tiene ya más de 2 años sigue siendo una fuente muy interesante que permite comparar los principales Stores RDF en base a una gran cantidad de características.

La tabla resumen:

Ver Informe

Humor:Viendo código mío de hace 5 años!

Publicado en Humor. Leave a Comment »
A %d blogueros les gusta esto: