Storing hundreds of millions of simple key-value pairs in Redis – Instagram Engineering

When transitioning systems, sometimes you have to build a little scaffolding. At Instagram, we recently had to do just that: for legacy reasons, we need to keep around a mapping of about 300 million photos back to the user ID that created them, in order to know which shard to query (see more info about

). While eventually all clients and API applications will have been updated to pass us the full information, there are still plenty who have old information cached. We needed a solution that would:

 

 

Add your annotatio

To take advantage of the hash type, we bucket all our Media IDs into buckets of 1000 (we just take the ID, divide by 1000 and discard the remainder). That determines which key we fall into; next, within the hash that lives at that key, the Media ID is the lookup key *within* the hash, and the user ID is the value. An example, given a Media ID of 1155315, which means it falls into bucket 1155 (1155315 / 1000 = 1155):

 

De 17go à 5go, beau gain de place!

 

Vous aimerez aussi...

2 réponses

  1. terrien dit :

    Le calcul de clé de répartition est ultra simple (MEDIAID / 1000). Et au final, c’est comme si j’avais accès à une propriété UserId de Media et que cette propriété portait l’info de l’endroit ou la trouver (c’est moi qui la calcule).

    Avec les hashes il y aurait aussi moyen de stocker des stats précalculées par objet suivant un hash sur la date par exemple ?

    Ex: Somme du nombre de VU à 10h aujourd’hui pour la page d’id 3556 :

    HSET statvu:1412892000 3556 2229

    Ensuite je peux utiliser du HMGET (http://redis.io/commands/hmget) pour lister les compteurs de toutes les heures de ma journée.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *