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 aMySQL
para las consultas ya era más del doble que eso), pero si manejamos del orden deGBs
, 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 conrequirepass
).slaveof
: con parámetrosIP
ypuerto
, 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.
Hay 1 comentario
Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.
por pfreixes, en 2010-06-15 23:07:54 ∞