I’ve been using Redis for a long time as one of my favorite utilities to integrate into projects. For anyone who isn’t familiar with it, Redis has traditionally been considered an in-memory key-value storage service.
But Redis has long been much more than that: it supports a range of data structures that make it more capable and useful in many different ways.
It’s not just an application used as a cache for metrics, user sessions, and so on. For certain applications whose data storage needs aren’t necessarily relational, Redis can perfectly well be used as a database.
There are similar in-memory servers, such as Memcached. However, at Picly.io—an advanced image server currently in development—we decided to use Redis as our database. This is an important design decision that will, in some way, shape how the service is deployed and used.
What I want to emphasize is that Redis can, in some cases, perfectly well replace databases such as MySQL, MongoDB, SQL Server, and others.
In this case, these are the reasons that led me to choose Redis as the data store for Picly.io:
- Picly’s core needs to be small, but very robust and efficient.
- Picly’s data storage needs are relatively simple: flat data structures with very simple relationships.
- Performance needs to be outstanding so images can be served, processed, and transformed as quickly as possible.
- Redis is a mature product that is free to use, with extensive documentation and a large community.
- Installation is simple, as you can see in this guide for Ubuntu 16; maintenance is simple too.
- For large Picly instances—with millions of images or image-transformation requests—Redis can scale across multiple servers and is supported by various cloud service providers, such as Azure Redis Cache.
One interesting thing is that Redis’s performance—the time it takes to return an object—is deterministic. That’s not the case with a relational database unless it’s configured correctly and backed by significant resources.
Some of the data structures Redis supports include key-value objects, hashes, lists, and sorted lists with pagination. That’s enough for an application to rely on Redis without needing a heavier database server. In addition, a feature introduced in later versions is the ability to use Lua scripts, which makes more complex queries and calculations possible.
That said, directly using Redis through its basic commands (such as HSET, ZRANGE, and so on) can tangle or obscure a high-level application that uses it.
To address this, and since Picly.io is being developed with Node.js, I’m building a small library to make it easier for an application to encapsulate its use of Redis.
I’ve called it Blue Entities, and it’s available on GitHub. Although we’re using it in Picly, I wouldn’t yet say it’s production-ready, and we still have quite a few improvements to make over the coming months.
For example, with this Node.js module and a schema like this:
var schema = {
name: "users",
properties: [
{ name: "mail", type: "string" },
{ name: "password", type: "string" },
{ name: "active", type: "boolean" },
{ name: "age", type: "integer" }
]
};
You can add entities like this:
var redisConfig = { host: "localhost", port: 6379 };
var blueEntities = require("blueentities")(schema, redisConfig);
var newUser = {
mail: "info@solidstack.es",
password: "123454321",
active: true,
age: 43
};
blueEntities.addEntity("users", newUser)
.then(function(id) {
// User added!!!
});
Retrieving an entity from the database is trivial (and high-level, which is the interesting part):
blueEntities.getEntity("users", id)
.then(function(user) {
// User retrieved!!!
});
Internally, entities are converted into Redis objects, transparently and efficiently for Blue Entities users.
There are other, much more comprehensive projects that work like ORMs for Redis and Node.js, but they seemed too heavyweight for Picly.io’s storage needs.
In any case, I strongly recommend carefully evaluating how Redis fits into the projects we build and considering it as an important tool.