¿Cuándo usar NoSQL y qué familia usar?

La primera decisión a tomar es si realmente tenemos la necesidad de usar una base de datos NoSQL o simplemente es una tecnología que queremos probar a toda costa (je,je, que suele pasarnos ;))

Para tomar la decisión debemos considerar los siguientes criterios:

NoSQL

• Parte de almacenamiento debe ser capaz de manejar muy alta carga * Se realizan muchas operaciones de escritura
• Almacenamiento debe escalar horizontalmente (metiendo nuevas máquinas) * Se prioriza la simplicidad
• Lenguaje de consultas simple (normalmente sin JOINS)
• Cambios de esquemas frecuentes

RDBMS

• Almacenamiento soporta alta carga, pero sobre todo operaciones de consulta * Rendimiento pero sobre una estructura de datos sofisticada * Estructura de datos predefinidas
• Lenguaje de consultas potente: SQL

Una vez decidido el uso de una base de datos NoSQL queda elegir el tipo de base de datos NoSQL.

Las bases de datos NoSQL se organizan en 4 familias:

• Stores Key-Value: fundamentalmente se trata de usar una tabla hash donde hay una clave única y un puntero a un elemento de datos en particular.
• Column Family Stores. Todavía hay claves, pero apuntan a varias columnas. Las columnas se organizan por familias de columnas.
• Document databases: similares a stores clave-valor, es el siguiente nivel. El modelo de datos es una colección de documentos que contienen colecciones de clave-valor
• Graph Databases: en lugar de de tablas de filas y columnas y estructura rígida de SQL usan un modelo grafo flexible que puede escalar entre máquinas.

Familia	Ventajas	Inconvenientes	Algunos productos /Usos típicos
Stores Key-value	-Modelo más simple-Fácil de implementar y usar	-Ineficiente cuando se realizan búsquedas, se quiere actualizar parte de un valor,…	(Dynamo,Redis,Oracle NoSQL,Voldemort)-Cacheo de datos -Logging
Column Family Stores	-Almacenamiento distribuido-Soportan un gran crecimiento -Alta disponibilidad -Escrituras masivas -Soporte MapReduce -Mecanismos de replicación	-APIs de bajo nivel-Complejidad modelos -No hay joins -No permite ordenar resultados	(BigTable,Cassandra,HBase,Riak)-Sistemas de ficheros distribuidos -MapReduce -Estadísticas tiempo real
Document Databases	-Modelado de datos natural y amigables-Flexibilidad -Desarrollo rápido -API de consulta potentes -Trabajo con formato JSON -Consultas más eficientes que key-value -Relación entre documentos -Indices -Consultas espaciales	-Rendimiento frente a Colum-Family Stores-Sintaxis de consulta no estándar -Unsafe	(CouchDB,MongoDB)-Aplicaciones web: Wikis, Blogs -Gestión documental –
Graph Databases	-Algoritmos de grafos (camino más corto,…)	-No hay lenguaje de consultas estilo SQL-Tiene que recorrerse todo el grafo para obtener la respuesta -Complicado el clustering -Problemas para cumplir el teorema CAP	(Neo4J,InfroGrid,AllegoGraph)-Redes sociales: recomendaciones