Redis, NoSQL y esas hierbas (y III)

Con esta entrega finalizo mi pequeña serie sobre la experiencia de migrar este blog a Redis.

Ya comenté mis conclusiones, y el modelo de datos que he implementado, ahora me queda hablar de las copias de seguridad y de algunas particularidades de Redis como almacenamiento (en mi caso, la versión 2.0.0-RC1).

Almancén en memoria, con persistencia

El primer punto importante deriva de la necesidad de ser lo más rápido posible: todo el almacén se mantiene en memoria, con la posibilidad de hacer snapshots a disco periódicamente o bajo demanda.

Esto tiene un par de consecuencias:

• Nos tiene que caber toda la base de datos en memoria. En este blog hablamos de menos de 4MB, lo que no es un problema (el caché que le daba a MySQL para las consultas ya era más del doble que eso), pero si manejamos del orden de GBs, puede ser un problema :D.
• La idea de persistencia mediante snapshots es buena para la velocidad, pero no es perfecta: puede darse el caso de que perdamos datos si hay un problema entre snapshots (esto se puede mitigar mucho, como veremos).

Así que ya hay muchos escenarios en los que no me plantearía desplegar una solución basada en Redis.

Por ejemplo nos encajará muy bien como un reemplazo de un caché tipo memcached (con el añadido de la persistencia), aplicaciones en tiempo real que requieran mucha velocidad, y por supuesto para aplicaciones web sencillas (como esta); pero no podremos manejar bases de datos de 200GB (como en algún proyecto que manejamos con PostgreSQL en el trabajo).

Configurar el servidor

El fichero de configuración de Redis viene comentado con información suficiente para que no tengamos problemas a la hora de ajustar los valores (y tampoco hay tantos).

Solo voy a destacar algunas de las cosas más imporantes.

databases

Podemos gestionar n bases de datos aisladas, cada una identificada por un número (que usaremos con SELECT por conexión para ponernos a trabajar con ella). Por defecto se limita a 16 (¡yo solo uso una!).

Como tampoco hay controles de acceso por base de datos, este es más bien un límite para acotar el uso de memoria (imagino).

save

Se indican dos parámetros: segundos y cambios (escritura). Si se dan ambos, entonces se realiza un snapshot, que es una imagen en disco de los datos en memoria.

Podemos indicar cuantas lineas save queramos, por ejemplo:

# snapshot si hay al menos 1 cambio en 5 minutos
save 300 1
# snapshot si hay al menos 100 cambios en 60 segundos
save 60 100

Además hay que tener en cuenta que podemos llamar al comando SAVE cuando queramos desde nuestra aplicación (por ejemplo, tras publicar un post), algo que no tendrá penalización si hacemos pocas escrituras.

Combinando ambos tipos de snapshots (periódicos y bajo demanda), es poco probable que perdamos datos.

appendonly

Si no podemos permitirnos el riesgo de perder información bajo ningún concepto, Redis implementa una especide de journaling, a costa de una pequeña penalización.

Si activamos este modo, el servidor llevará un registro de las escrituras en un fichero, que utilizará para reconstruir la base de datos al arrancar (ignorando los snapshots, aunque podemos generarlos en paralelo a este sistema).

Podremos controlar cómo se sincroniza contra disco con appendfsync indicando always (en cada operación, lo que es muy lento), everysec (cada segundo, con buena relación seguridad/velocidad), o no (dejando al sistema operativo gestionar la sincronización).

maxmemory

Podemos indicar cuál debe ser el límite de memoria que puede usar Redis, algo conveniente si nuestra aplicación puede hacer crecer la base de datos y no queremos que la máquina se quede sin recursos (recordemos que toda la base de datos estará en memoria).

requirepass

Con esta directiva podemos indicar una contraseña que tendrán que proporcionar los clientes para trabajar con el servidor.

Es importante utilizar un contraseña robusta para aguantar bien los ataques por fuerza bruta, ya que Redis es muy rápido, y podrían hacerse cientos de miles de pruebas por segundo en una máquina con cierta potencia.

En realidad no creo que tenga mucho sentido correr Redis en un entorno que pueda estar expuesto a posibles usuarios malintencionados, esta opción también la utilizaremos en la replicación.

Replicación y copias de seguridad

Mención aparte merecen los dos parámetros para configurar la replicación:

• masterauth: la contraseña que usará el esclavo para conectarse al maestro (indicada con requirepass).
• slaveof: con parámetros IP y puerto, que nos servirá para identificar al servidor maestro.

No hay más, porque todo servidor es susceptible de ser maestro. Así de sencillo :).

La replicación de Redis es bastante eficiente, enviándose un snapshot inicial, para posteriormente comunicar todos los cambios (escrituras) que se produzcan en el servidor.

La replicación es trivial de implementar, y es el complemento perfecto a las copias de seguridad.

Copias de seguridad

La forma de hacer los snapshots empleada por Redis es atómica, así que realizar un backup es tan sencillo como:

$ cp dump.rdb backup_dump.rdb

En mi caso, con una base de datos pequeña, es instantáneo.

Conclusiones

Hasta ahora no sé si mis anotaciones han sido lo suficientemente interesantes como para contrarrestar la parte menos bonita de trabajar con Redis :P.

Recuerdo que cuando empecé a ojear la documentación no dejaba de pensar: esto no puede ser gratis, alguna pega tiene que tener. Para mi problema, estas pegas no son demasiado importantes, pero no será así siempre.

Por eso mantengo mi opinión: NoSQL debe ser Not Only SQL, como una herramienta más que hay que tener presente cuando un sistema de bases de datos relacional no es la solución óptima, pero sin significar una ruptura (por ahora) con el modelo relacional.