Sobre NoSQL, escalabilidad y otras yerbas

Creo que todos quienes hemos trabajado en desarrollo de sistemas, sobre todo en empresas, pensamos que existe solo un tipo de base datos y todas tienen en común que son SQL.

La vieja guardia es una amplia lista de implementaciones de bases relacionales que utilizan SQL para la definición y consulta de los datos. Estas implementaciones del modelo relacional de Codd han monopolizado el mercado de las bases de datos desde 1970.  40 y tantos anios de hegemonía lo hacen hoy el standard de base de datos mas aceptado, utilizado y probado del mundo.

Pero la tecnología cambia, y hoy las redes y los servicios en la nube imponen nuevos desafíos, y nuevas tecnologías comienzan a demostrar que la vieja guardia no puede adaptarse.

Los nuevos desafios son:

Escalabilidad lineal

Se entiende por escalabilidad a la habilidad de una aplicación de crecer para satisfacer la demanda, sin cambiar el codigo cumpliendo con los parámetros de aceptabilidad del usuario. Una vez de acuerdo en el significado de escalabilidad, decimos que la escalabilidad lineal es la capacidad de crecer tanto como se necesite a un precio fijo por unidad de capacidad de procesamiento adicional.

Escalabilidad elástica

Si ser escalable significa solo crecer para adaptarse a la demanda, ser elástico implica también reducirse. Puede parecer algo trivial pero un sistema que escala no siempre logra reducirse y disminuir su costo de mantenimiento ante una baja en la demanda. En resumen se trata de la capacidad de un sistema de adaptarse a la demanda variable.

Llevar a la practica este concepto necesita mucho mas que la elección correcta de una base datos. Implica que la arquitectura del sistema sea acorde, pero no es el punto de este articulo. Para mas info leer The Scalability Revolution: From Dead End to Open Road .

Tolerante a fallos

Es la capacidad de una base de seguir funcionando (proporcionando acceso r/w a los datos) a pesar de que uno de sus nodos/instancias haya dejado de funcionar. Normalmente esto se resuelve con replicacion pero en los sistemas de base de datos de la vieja guardia esto requiere algun tipo de centralización y por consiguiente genera a la larga un SPOF (Single Point of Failure).

Descentralizada

Que cada nodo en el cluster sea idéntico y no exista un SPOF o cuello de botella de red.

Bemoles

Todas estas cualidades no existen si no se hacen algunas concesiones. Existe un principio o un teorema sobre computacion distribuido conocido como CAP. Que dice que es imposible para un sistema distribuido garantizar que estas tres cualidades se cumplan al mismo tiempo:

1. Consistencia: todos los nodos ven la misma información todo el tiempo.
2. Disponibilidad: todos los requests tienen una respuesta siempre.
3. Tolerante a partición: el sistema continua operando a pesar de perdida de datos.

El teorema dice que solo dos de estas cualidades, a la vez, puede ser satisfechas por el sistema, pero no las tres. En la mayoría de los casos 2 y 3 son garantizadas por las bases NoSQL,  y la 1 es algo que pasa a ser una responsabilidad de la aplicación.

Otra complicación a tener en cuenta es que al ser key-value, sobre todo en las distribuidas, tareas como paginar, buscar o sumarizar  que pueden parecer triviales en en los clásicos SQL, son un verdadero dolor de cabeza en las NoSQL. Lo cual es natural si tenemos en cuenta que los objetos se encuentran replicados en los nodos que componen el cluster. Riak por ejemplo ha incorporando en su versión 1.0 un motor de full-text search Raik Search pero a la hora de una simple paginacion tenemos que recurrir a estructuras complejas que nos permitan simularlo.

Bases de datos NoSQL

Esta una lista de las mas importantes. De las cuales he trabajado con Redis, RavenDB y Riak:

• HBase
• MongoDB
• Riak
• Voldemort
• Neo4J
• Cassandra
• Hypertable
• HyperGraphDB
• Memcached
• Redis
• CouchDB
• RavenDB

Un paseo por alguna de ellas

RavenDB

Base datos key-value codificada en C#. La misma provee soporte de:

• Map Reduce
• Indexing
• Full-text search
• Replication (master-slave ok, master-master aun no lo he probado)
• Key expiration
• Transactions
• Slice queries (facil de paginar)
• Silverlight/HTML  Administration Console.

Pero aun no soporta:

• Sharding: si bien el codigo del cliente soporta sharding de una manera similar a como lo hace NHibernate, aun falta mucho para que sea aceptable. Hay una serie de bugs reportados y no resueltos con los queries sin indices, y aun no provee soporte de Linq sobre los queries al sharding. Y esta aun lejos de hacerlo dado que debe falta mucho trabajo antes de que RavenDB pueda hacer un query slice, o un map reduce sobre los shards. Si bien permite distribuir el contenido en shard por medio de una estrategia definida por el usuario, una vez implementado se pierden habilidades de consulta claves.
• Fault tolerant: se que implementa un mecanismo desde el cliente, que aun no he podido probar, pero se basa en la existencia de otras instancias interconectadas por replicacion master-master o master-slave con opción de promover el slave en caso de que el master caiga.

En resumen RavenDB hoy por hoy no es escalable linealmente, el sharding es una mera intención, que en palabras de su creador aun no ha sido probado y por experiencia personal con el codigo fuente de RavenDB dista de estar siquiera en alfa.

Redis

Luego de mi paso por RavenDB, Redis me dio muchas mas satisfacciones pero trajo sus problemas. Hay que reconocer que es realmente veloz pero esta mas cerca de una cache “distribuida” con opción a persistencia que de una base de datos.

Hay que pensar a Redis como una cache con opcion a persistencia y que provee una serie de estructuras de datos sobre el formato key-value como:

• Hashes
• Lists
• Sets
• Sorted Sets
• Pub/Sub
• Transactions

Lo mas interesante es que la API provee comandos atómicos para modificar estas estructuras para garantizar completo soporte de concurrencia. Es muy facil implementar sobre Redis, por ejemplo, una queue dado que las Listas tienen comando LPOP, RPOP, LPUSH, LINSERT, etc. Incluso podemos implementar un rudimentaro sistema de notificaciones para esta queue sobre el servicio Pub/Sub de Redis.

Pub/Sub nos permite hacer broadcast de mensajes por medio de canales a los cuales podemos subscribirnos o publicar mensajes (una cadena de texto plana o un objeto JSON). Sin duda un feature que la distingue del resto.

Algunas librerias que dan soporte de Queues:

• C# Resques.Net:
  • soporta New Item Notification using Pub/Sub
  • Capped collections
  • Stacks
  • Queues
• Python QR
• RestMQ

Como contras, Redis no posee Indices, ni MapReduce, las búsquedas sobre un un dato de los objetos almacenados se debe efectuar uno por uno o en su defecto contemplando el problema en la aplicación desde un comienzo.

En cuanto a escalabilidad, se encuentra planificado Redis Cluster e incluso creo que se puede ser probado una versión alfa, pero actualmente lo único que permite Redis es la replicacion  master-slave.

Para proporcionar Faul-tolerance sobre esta estructura hay que adicionar a nuestra aplicación código para que promueva un slave en caso de error en el master.  Algo realmente poco practico.

En Conclusion, Redis no escalable linealmente. Pero esta efectuando al parecer un intento bastante serio de querer serlo en el futuro. Espero que para 2012 pueda competir con los grandes.

Riak

Actualmente me encuentro probando Riak con un cliente NodeJS llamado riak-js. Riak es una base inspirada en Dynamo y que provee una verdadera arquitectura distribuida. Y lo que es mas importante permite escalabilidad elastica ya que proporciona comandos para atachar nodos al cluster y removerlos sin perdida de datos.

También proporciona Map Reduce e Indices Secundarios y Links (feature muy interesante).  Pero como contra no podemos hacer query slices (escensiales en la paginacion) y ordenamientos. Cada query retorna los datos en un orden diferente ya que depende de como los entreguen los nodos. Link walking y Secondary Indexes son features muy interesantes para tener en cuenta.

En conclusión Riak promete ser escalable linealmente y elástica voy a seguir trabajando con Riak, para entender mejor como resolver problemas básicos como un query slice.

Cassandra

Pronto. Durante el próximo mes me he propuesto instalar y probar esta base de datos que promete, dado su amplia utilización, ser muy completa.

Algunos links de interés:

http://www.elasticvapor.com/

http://www.spotcloud.com/

The Scalability Revolution: From Dead End to Open Road 
An SBA Concept Paper
By Nati Shalom, CTO  |  February 2007

Advertisement