Todo pintaba bien cuando transformamos nuestras base de datos de históricos desde un sistema relacional a un sistema NoSQL documental (MongoDB). Tras darle vueltas a las diferentes posibilidades, las piezas encajaban como si de un puzzle se tratara… pero al final vimos el no deseado y tan temido cuello de botella.

El gran problema es la cantidad elevadísima de datos que almacenamos y su crecimiento exponencial diario. Al indexar la colección de Mongo, tuvimos que despedirnos de la memoria RAM de nuestros servidores, por lo que únicamente nos quedaba la posibilidad de repartir la carga en un conjunto de máquinas con una técnica conocida como Sharding muy similar a la que utiliza Hadoop. Para que os hagáis una idea, solo una de las colecciones se iba a los +40GB de información.
Así que decidimos buscar una alternativa en cuanto a base de datos se refiere en vez de realizar el mencionado sharding, que además de ser un parche a corto plazo resultaría económicamente deficiente. Exploramos muchísimas posibilidades que el mercado tiene actualmente (gracias, comunidad de desarrolladores). Entre ellas había alguna especialmente atractiva para el guardado de información histórica, pero necesitábamos algo que se estuviera usando a mayor escala: Redis.
La siguiente clave fue cómo guardar información histórica en Redis… ¿¡cómo!? Navegando por la red, las recomendaciones principales son los sorted sets, poniendo en el “score” un “timestamp” para las fechas. ¿Problema? El valor no puede ser repetido. Es decir, ayer y hoy no puedo tener el mismo valor, eeerrooooor. Se pueden leer chapuzas espectaculares como “añádele una cadena de texto única al value”. Aún así, lo probamos… y tanto la velocidad con gran cantidad de datos como el espacio ocupado no eran para nada deseables.
La solución final estaba en la propia documentación de Redis: siempre que puedas utilizar hashes, hazlo. Esto, unido a un post del blog de Instagram en el que se chivaban de cómo lo tenían ellos y unos cuantos ajustes de configuración, nos dio la solución.
El resultado final: una base de datos que ocupa menos de 6GB, unos tiempos de respuesta inferiores a medio segundo y la reducción de gran cantidad de código debido a la simplicidad de Redis. Aquí comenzamos una nueva historia de amor.