Después de haber dado un repaso a Riak, MongoDB y Cassandra, ya era hora de hacer algo con Redis.

Redis es una base de datos NoSQL, de tipo clave-valor. Los valores pueden ser de varios tipos: cadenas, hashes, listas, conjuntos o conjuntos ordenados. Tiene sistemas get/set, incrementos/decrementos de números, operaciones de listas, de conjuntos, ....; también dispone de mecanismos publicación/subscripción (para uso como si fuese un sistema MQ), expiración de datos (para uso como sistema de caché), replicación maestro-esclavo y evaluación de código escrito en Lua.

Además de todo esto, Redis se destaca por ser una base de datos con un rendimiento muy elevado, esto es porque se define como una base de datos en memoria con persistencia para datos (que puede ser desactivada). Sus creadores indican que la comparación con otros sistemas tiene matices. En su página web oficial, la sección de benchmark, reseñan algunos datos a tener en cuenta en las comparaciones:

• Redis es un servidor, por lo que la comparación con sistemas de almacenaje de datos integrados como SQLite, Berkeley DB, Tokyo/Kyoto Cabinet, etc... no es posible, ya que Redis tiene comunicación a través de un protocolo y la red.
• Redis responde siempre a las peticiones, a diferencia de otros sistemas como MongoDB que no notifica o no da conocimiento sobre las operaciones de escritura, o MySQL que permite retrasar las inserciones.
• Redis es síncrono, por lo que para realizar un benchmark no se puede hacer sobre una sola y misma conexión, hay que habilitar varias conexiones hacia el servidor.
• Redis es una base de datos en memoria, por lo que sería raro o extraño compararla con sistemas transaccionales como MySQL o PostgreSQL, entre otros. Para estar en igualdad de condiciones habría que emplear AOF en Redis y alguna política de fsync.
• Redis es un servidor mono-hilo, esto quiere decir que no aprovecha los beneficios de los sistemas con varias CPUs o multi-core, por lo que su comparación con sistemas multi-hilo en los que sí se aprovechan estas características, es igualmente desventajoso para Redis. No obstante se pueden lanzar varios Redis en modelo maestro-esclavo si se requiere.

Con estas anotaciones, queda bastante claro que Redis se puede asemejar más a memcached que a una base de datos convencional, pero realmente, está entre ambos mundos. Revisaremos la forma en la que podemos trabajar con la base de datos.

Primeros pasos

En la propia página web nos aconsejan emplear Redis en sistemas GNU/Linux, por lo que, desde Debian, haciendo caso y tirando de paquetería, podemos ejecutar directamente:

  apt-get install redis-server

La instalación de este paquete nos deja a Redis funcionando sin problemas en el sistema. Perfecto. A través del cliente podemos realizar algunas pruebas básicas:

$ redis-cli set midato 'Hola mundo!'
OK
$ redis-cli get midato
"Hola mundo!"

Por defecto, aunque reiniciemos el servidor, el dato se mantiene almacenado y nos lo proporciona cada vez que realizamos una solicitud, los datos son persistentes por defecto (a menos que se indique lo contrario). Una forma de eliminarlo, según los comandos básicos puede ser con el comando del o a través del comando expire (dándole un tiempo de expiración bajo).

Probando ambos:

$ redis-cli del midato
(integer) 1
$ redis-cli get midato
(nil)
$ redis-cli set midato 'Hola mundo!'
OK
$ redis-cli expire midato 1
(integer) 1
$ redis-cli get midato
(nil)

En la web oficial podemos encontrar un tutorial (en inglés) que nos guía a través de las operaciones básicas con todos los tipos de datos de Redis. No obstante, viendo el cómo se usa cada comando, y teniendo la lista de comandos, no tiene mayor problema el ponerse a probar y comprobar lo que nos retornan los mismos.

Integración de Lua

Hace tiempo, comentaba que Lua, era un lenguaje muy liviano, de alto rendimiento que permitía su integración dentro de cualquier sistema sin problemas. En este caso, saliendo un poco del ámbito de los videojuegos, encontramos que Redis tiene integrado en su core, a través de las operaciones de scripting, este mismo lenguaje.

Desgraciadamente, de momento, la instalación del paquete Redis en Debian Wheezy anda por la 2.4 y la integración de Lua viene a partir de la versión 2.6, por lo que es una característica muy reciente. En cuanto tenga algo más de tiempo instalaré la versión 2.6 para hacer pruebas con Lua, de momento lo dejo solo comentado.

Maestro-Esclavo

El sistema permite también mantener la replicación de maestro/esclavo. Haciendo pruebas, instalando otro servidor en otro equipo de la red, y cambiando la configuración del servidor (ya que por defecto se mantiene escuchando solo desde la interfaz local), lanzo el comando en el segundo servidor (tomaremos en cuenta de que el master está en 192.168.1.1 y el esclavo es 192.168.1.2):

$ redis-cli slaveof 192.168.1.1 6379

En este momento, todo lo que se escriba en el maestro, será replicado inmediatamente al esclavo. No obstante, debemos de tener cuidado, ya que, lo que sea escrito en el esclavo no será replicado al maestro, con lo que deberemos de dejar al maestro para las escrituras, mientras que las lecturas podrán llevarse a cabo desde cualquiera de ellos.

Conclusiones

Ha sido una primera aproximación a este sistema de base de datos que me ha dejado con bastante buen sabor de boca. En principio, he visto una buena opción como competencia de memcached, un sistema bastante simple para uso al estilo MQ (cola de mensajes) y finalmente, un buen sistema de base de datos de alto rendimiento, escalable (gracias a su esquema maestro/esclavo) y, ante todo, muy sencillo y simple de usar.