Redis Data Layout

0

Redis Data Layout

To better understand the data layout, it helps to identify the main "domain" objects inside RetwisJ.

In its current form, RetwisJ allows users to be created, to postmessages, to follow and be followed by other users.

Each user automatically sees the posts of the ones she follows but also see other users posts from the timeline. 

Each italic word represents a "domain" object and its relationship to other objects that need to be represented in Redis.

With a "traditional" database, one would use tables and indexes and so on however Redis is not a RDBMS rather, it is a key-value store.

That is, it allows simple values (called strings in Redis terminology), lists, sets and sorted or z-sets to be stored under a unique key.

So rather the storing data in a certain table at a certain id, we can store data directly under a key (using a key pattern of choice for easy retrieval) and take advantage of the various Redis key types. Again, for more details, see the "Data Layout" section in Retwis docs.

The user data (name and password) is stored in a hash (or a map). To generate the key for each new user, a dedicated counter is used (called global:uid); 

 thanks to Redis atomic operations, the key can be simply incremented to generate a new user id (uid). 

We can now store the user data under the key uid:[uid] where [uid]represents the value generated by the global:uid key.

For example, with two users "springrod" and "costinl", Redis will contain the following keys:

The uid is used internally to store and lookup all user information but we need to store also the relationship between the username and its internal uid - so for example, when a user logs on we can find the uid for the user name.

 A simple way to do that is to create a lookup or reverse key that relies on the username as the key and the uid as the value, such as user:[name]:uid. 

We can also add a key that holds the names of all users for easy retrieval - we will use a list for that called users. Following our example above, the layout becomes:

The posts can be stored in a similar way - we can use a key (global:pid) as a counter to generate the post id (pid) and save the post content information (content, data and author) in a hash (pid:[pid]. We can use a list to store the posts for each user or rather their IDs (pids) - say under uid:[uid]:posts and all posts under thetimeline key: