5 Comments

It looks like you had a markdown table that substack failed to render, and now it looks like this:

> Memcached Redis Sub-millisecond latency Yes Yes Developer ease of use Yes Yes Data partitioning Yes Yes Support for a broad set of programming languages Yes Yes Advanced data structures - Yes Multithreaded architecture Yes - Snapshots - Yes Replication - Yes Transactions - Yes Pub/Sub - Yes Lua scripting - Yes Geospatial support - Yes

Expand full comment

I will take a look. Thanks for heads up.

Expand full comment

It's still not rendering properly

Expand full comment

What insturments do you use to create such a beautiful illustrations?

Expand full comment

The below para looks like because of hash slot algo used by redis, the data movement is avoided when a new node is added to the redis cluster but which is not the case. The real advantage of the hash slot algorithm I guess is more about simplicity and being able to reason the key to slot mapping.

>>>Assuming the key 'foo' was mapped to shard zero after introducing a new shard, it may map to shard five. However, moving data around to reflect the new shard mapping would be slow and unrealistic if we need to grow the system quickly. It also has adverse effects on the availability of the Redis Cluster.

Redis Cluster has devised a solution to this problem called Hashslot, to which all data is mapped. There are 16K hashslot. This gives us a reasonable way to spread data across the cluster, and when we add new shards, we simply move hashslots across the systems. By doing this, we just need to move hashslots from shard to shard and simplify the process of adding new primary instances into the cluster.<<<<

Expand full comment