Categories
Bigdata General NoSQL OpenSource Social

Datos en formato Grafo (NoSQL) – 1a Entrega

Actualmente las base de datos NoSQL están en auge (http://nosql-database.org). Podemos encontrar una gran diversidad según su arquitectura; las más utilizadas son del tipo Key-Value (como Cassandra o Voldemort) 
o las documentales (por ejemplo MongoDB y CouchDB). Aunque existen otras no tan conocidas como las que os queremos presentar; BBDD NoSQL basadas en grafos o tripletas como DEX y Neo4j. (http://stackoverflow.com/questions/5689091/how-to-choose-which-type-of-nosql-to-use). A parte luego ya hay base de datos NoSQL que ya son casos híbridos que es el caso de OrientDB (http://www.orientechnologies.com/orientdb) que es un híbrido orientado entre base de datos en formato grafo y documentales.
dex
Dex introducción
Os queríamos introducir DEX una base de datos NoSQL de grafos con muchos casos de éxitos. DEX (http://www.sparsity-technologies.com/dex) está escrita en C++ aunque se puede utilizar con muchos otros lenguajes de programación y una de sus características principales es que permite analizar grandes volúmenes de datos.
DEX está basado en el modelo2 de base de datos en grafo, que está caracterizado por cumplir 3 propiedades: las estructuras de los datos son grafos o estructuras similares a un grafo o tripleta, la manipulación de los datos y las consultas se realizan con operaciones orientadas a grafo y existen restricciones para garantizar la integridad de los datos y de sus relaciones.
Un grafo de DEX es un multigrafo dirigido etiquetado y con atributos. Está etiquetado porque tanto nodos como aristas pertenecen a tipos. El grafo es dirigido porque permite que existan tanto aristas dirigidas como no dirigidas. Nodos y aristas pueden tener tantos atributos como se desee. Finalmente también decimos que es un multigrafo porque permite que existan múltiples aristas entre dos nodos aunque éstas sean del mismo tipo.
La principal característica de DEX es su capacidad de almacenamiento de datos y rendimiento, con órdenes de magnitud de miles de millones de nodos, aristas y atributos, gracias a una implementación con estructuras ligeras especializadas. (Wikipedia)

Ref: http://www.cbsolution.net/techniques/ontarget/databases_relational_vs_object_vs

Dex comparación con mysql

Depende mucho de cada caso de uso para saber cuando es más recomendado usar DEX u otro tipo de base de datos. Hemos querido hacer una típica comparación comparando DEX con MySQL. Elegimos MySQL ya que es una de las base de datos más usadas actualmente. Podemos ver en el siguiente listado que ventajas y desventajas nos aportan una base de datos relacional como el MySQL en comparación con una de grafos como DEX.

Ventajas del Mysql:
  • Mejor medición del performance (DEX tiene herramientas pero no suelen ser en tiempo real como pueden ser en MySQL)
  • Madurez. Está claro que las RDB como el MySQL son más maduras que DEX. Este hecho aporta que a nivel seguridad el MySQL es también más maduro y su interfície de gestión es más avanzada.
  • Claramente hay muchos más casos de éxito del MySQL
  • La implementación de MySQL es sencilla y además la mayoría de gente tiene más experiencia en este ámbito de las RDB. Siguiendo a nivel coste, DEX vuelca todos sus datos en RAM por lo cual es más costoso a nivel Hardware que las RDBs. Aunque actualmente el precio de la RAM se está reduciendo cada vez más.
  • Escalabilidad. Curioso caso, el NoSQL suele ser muy utilizado por las carencias de MySQL a nivel escalabilidad. El DEX en sus primeras versiones cojeaba un poco a nivel escalabilidad. Aunque tenemos que estar atentos porque las últimas versiones de DEX mejoran mucho esta característica y quizás este punto ahora sea más favorable para DEX.
Ventajas DEX sobre Mysql:

Ahora viene la parte interesante:

  • Aparentemente MySQL es más ineficiente para modelos de datos complejos o datos flexibles.
  • Es ineficiente para consultas estructurales. O para uso intenso de JOINS.
  • El DEX permite gran capacidad de tratamiento de grandes volumes con un alto rendimiento
  • Los Grafos suelen ser muy utilizado en redes sociales y en el mundo del Big Data.
  • El DEX se puede integrar con dos base de datos públicas.
  • WordNet: definiciones y diccionarios.
  • ConceptNet: relaciones entre conceptos.
  • Muy flexible para manejar Schemas desconocidos o dinámicos
  • El DEX tiene unas consultas estructurales y permite la navegación entre consultas.
  • Fácil mapeo entre ficheros CSV a DEX.
  • Tal como hemos comentado la escalabilidad a mejorado mucho en las últimas versiones. Cosa que seguramente ahora será mejor que el MySQL en este ámbito. Está aun por probar por parte nuestra.

Algunos casos para usarse de forma mucho mejor que MySQL u otras base de datos RDB y NoSQL:
– Encontrar todos los caminos entre 2 saltos de distancia (http://docs.neo4j.org/chunked/stable/cypher-query-lang.html)
– Encontrar amigo con el que tienes más amigos en común. Como también dar recomendaciones de grupos o música.
– Encontrar el camino más cortos entre dos elementos.
– Dijkstraa con DEX: http://architects.dzone.com/articles/graph-databases-features-graph
– Poner pesos entre diversos nodos con un coste. De esta forma podemos buscar el coste más pequeño entre nodos de distintos intereses entre todos . http://docs.neo4j.org/chunked/stable/tutorials-java-embedded-graph-algo.html
Ejemplo simple de un HelloWorld con DEX

public class HelloWorld {
DEX dex = new DEX();
GraphPool gpool = dex.create("/tmp/image.dex");
gpool.close();
dex.close;
System.out.println("Hello, World");
}

En la web de DEX podeis encontrar muchos más ejemplos. (http://www.sparsity-technologies.com/dex)

Las alternativa a DEX

La más conocida y más utilizada a parte de DEX es Neo4j. http://en.wikipedia.org/wiki/Neo4j . También tiene varias versiones como DEX. En el caso del Neo4j, tiene 3 versiones:

  • Comunidad está licenciado bajo GPL, y contiene toda la graphiness impresionante que deseas
  • Advanced es AGPL licencia, y agrega capacidades de seguimiento para su base de datos
  • Enterprise es también AGPL licencia, y agrega el monitoreo, las copias de seguridad en vivo y alta disponibilidad.

A parte de DEX y Neo4j que son las más utilizadas también hay muchas otras más, os recomendamos la siguiente lectura: http://jasperpeilee.wordpress.com/2011/11/25/a-survey-on-graph-databases/
Y por cierto, esta imagen hace un muy buen resumen y clasificación del estado del arte de como esta actualmente el mundo del SQL, NoSQL y el Big data.
451db_map_06.13
Ref: https://blogs.the451group.com/information_management/files/2013/06/451db_map_06.13.jpg

Categories
Bigdata General Hybrid Clouds In detail OpenSource

Cassandra, analizado en la última edición de Sudoers

Hemos tenido el placer de asistir a la reunión de Mayo de Sudoers donde Roger Torrentsgenerós expuso Keepalived y Tomàs Núñez explicó Cassandra para sysadmins.

Ya hablamos de Keepalived. Y Cassandra se nombró muy brevemente aquí, pero sin entrar en muchos detalles. Así que vamos a aprovechar para hacer un resumen de la presentación sobre Cassandra.

Como ya sabéis Cassandra es una base de datos NoSQL descentralizada. Está diseñada para trabajar con grandes volumenes de datos y permite escalar horizontalmente de una manera muy fácil.

Está basada en Google Bigtable y Amazon Dynamo, fue desarrollada inicialmente por Facebook. Des de febrero de 2010 es un Top Level Project de Apache y la última versión es la 1.2.5.

Actualmente es un projecto con una comunidad muy activa y existen diversas compañías que se dedican a dar soporte, como por ejemplo Datastax. Grandes compañías tienen Cassandra en sus entornos de producción: Facebook, Twitter, Netflix, Digg, Groupalia, etc.

Los puntos fuertes de Cassandra son:

  • Las escrituras son realmente rápidas (3000x respecto a MySQL).
  • Al ser descentralizada no tiene un Single Point of Failure.
  • Alta disponibilidad viene de serie.
  • Escala horizontalmente.
  • Requiere de muy poca administración.
  • Está pensada para correr sobre hardware barato.

Respecto al modelo de datos destacar que cada objeto tiene un ID y una serie key-value-timestamp. Al ser un modelo ‘sparse’ esto le da gran flexibilidad ya que no todos los elementos de una tabla deben tenen los mismos atributos e incluso se puede alterar el número de atributos sin bloquear la tabla o tener que parar el servicio.

Respecto a la arquitectura decir que se basa en un modelo DHT (Distributed Hash Table) donde los nodos se distribuyen en forma de anillo y cada nodo es el reponsable principal para una partición y el responsable secundario para una o más particiones (dependiendo del factor de replicación que es configurable). También es posible configurar la arquitectura de manera que sea multirack o multidatacenter.

Gracias al proceso de Gossip, todos los nodos saben en todo momento los nodos disponibles, su carga y si están bajo mantenimiento o la versión de Cassandra que están corriendo.

Como ya hemos comentado las escrituras en Cassandra son muy rápidas, ya que no se preocupa de recuperar el valor (si existe) para actualizarlo, sino que escribe directamente como si el valor fuese nuevo. Esto hace que en el momento de la lectura, se tengan que recoger los valores y ver cual es el más reciente.

Como curiosidad decir que se puede definir índice secundarios y des de la versión 0.8 hay soporte para contadores.

Existe una herramienta para el mantenimiendo y admininistración de los nodos llamada nodetool, recomiendo echar un vistazo a la wiki de Apache para ver los detalles de esta versátil herramienta.

Una manera muy sencilla de hacer una copia de seguridad es definir un cluster de backup con un nodo donde se almacenaránn todos los datos, y hacer la copia de este nodo.

La parte más interesante de la presentación fue cuando el ponente hizo gala de su dilatada experiencia con Apache Cassandra y nos explicó una serie de errores frecuentes y algunas optimizaciones. Recomiendo encarecidamente su lectura http://www.tomas.cat/blog/en/cassandra-frequent-mistakes.

Tan solo felicitar a Tomas por su excelente presentación.

Por último podéis encontrar la presentación original aquí.

Espero que lo disfrutéis 😉

Lorenzo  Cubero – CloudAdmin