Introduction to Redis

Redis is an advanced in memory key-value store designed for a world where "Memory is the new disk and disk is the new tape". Redis has some unique properties -- like blazing read and write speed, rich
…

Redis is an advanced in memory key-value store designed for a world where "Memory is the new disk and disk is the new tape". Redis has some unique properties -- like blazing read and write speed, rich atomic operations and asynchronous persistence -- which make it ideally suited for a number of situations.

Will have demos &amp; recaps in between. Aim is to inspire you to dig deeper into Redis and use it to solve your hard problems and use-cases in a very elegant way Please ask questions in between

Not only Strings (Not just parathas) Redis is a way to share memory over the network

– TCP / Text based API Keys are binary safe strings

It scales up and down. Small VPS friendly as well as can scale up to hundreds of GB of RAM Real time access to analytics data – solves this problem very elegantly Size of values &lt; 512 MB Redis provides few low level primitives and you can use those primitives for your use-cases. Just like you use the constructs provided by your favorite programming language.

Salvatore started Redis to support his product start-up LLOOGG. VMWare hired Salvatore in March 2010 Shortly thereafter, VMWare hired Pieter Noordhuis, one of the main committers

There is no race condition, since everything is single-threaded, no locking required.

Set is very good for keeping circle of friends Redis datatypes resemble datatypes in programming languages. So, Redis datatypes are very natural to us. Simple data structures makes Redis flexible and powerful Sorted set is very good for keeping an index of words in a document List is good for implementing a queue Hash is good for keeping complex objects, its also very efficient. Hash have a limitation that they values can only be strings. Use of BLPOP to prevent excessive polling or latency and for implementation of priority queues SET Intersection to find common contacts in 2 circles SET intersection to find “online” friends Set intersection to find friends who have purchased “Redis in action” Sorted Set to implement a simple Chat system Some people also use Redis as the Primary data store. Essentially, persistence is a side effect and we shouldn’t be too much worried about persistence at the time of designing or developing the application Setting-up schema ahead of time is a real pain The fact that Redis data-structures mimic the programming data-structures is a big advantage String / Numeric values for auto-increment sequences List and Hash are stand-alone, Set and Sorted Set are comparable, Sorted-set and list are sorted, set and hash are not-sorted. Hashes are small in size and very efficient. Redis supports several built-in data-types, allowing developers to structure their data in meaningful semantic ways, with the added benefit of being able to perform data-type specific operations inside Redis

It is not possible to run a query on the values. Just like in RDBMS, you can fire-up a query to find all employees whose name is ‘Deepak’, You can-not do that with unless you have stored your data like that.

-1 stands for last index in the list Lrange key 0 -1 (gets all elements in the list)

Set contains unique entries

ZRANGE and ZREVRANGE are expensive commands ZUNIONSTORE and ZINTERSTORE are quite commonly used to store temporary results When using sorted sets, the top operations are much more efficient, because the data is already ordered, but the memory usage is higher.

- With hashes, No de-serialization is necessary to get one field from the hash map

Querying keys is expensive. Keys * Keys h*llo Keys h[ae]llo If you need all keys or a sub-set of keys as a use-case, then consider storing all keys in a set

Configuration can be changed on the fly using redis-cli or by making changes to redis.conf file.

Compare that with ~ 6K transactions/sec on MySQL

- Choose persistence strategy based on the usage scenarios. Can trade performance for improved durability At the time of snap-shotting, memory consumption increases considerably.

Even if you are using memcache and you don’t need any of the additional functionality offered by Redis, data durability is a good enough reason for you to switch to Redis

The amount of RAM that Redis needs is proportional to the size of the dataset. Large datasets in Redis are going to be fast, but expensive

Instagram stores images as keys Instagram did some re-design of the way keys were stored, made use of Hash and got some performance improvement

If you have a big data-set or a data-set that doesn’t change often, use AOF. AOF can be used together with snapshotting. Use pipe-lining to improve the performance when executing multiple commands (and where output from previous command is not required) Network latency might be the biggest bottleneck when using Redis

Going with the default configuration can make you lose data. Often times, the persistence strategy depends upon the usage patterns and your own data type. The fact that Redis does not have any index, makes you think about the usage pattern from the very beginning, which is unlike RDBMS world, where usually, the usage pattern is secondary.

MULTI and EXEC commands allow transactional behavior in Redis Using DISCARD inside a transaction will abort the transaction, discarding all the commands and return to the state before the transaction began. Use of WATCH command to read a value in the middle of a transaction.

Redis is ridiculously fast. Redis is built for speed, developers talk about speed in microseconds. Can also be used as the primary data store Memory hungry (you should determine what kind of data you want to store) Doesn’t have schema, but the way you store your data depends a lot upon your use-case Redis is very flexible – VPS friendly (512 RAM), as well as can scale to hundreds of GBs of RAM

17.
Atomicity of Commands• All of the built-in commands of Redis are atomic• Commands can be chained together (pipelined) to create complex atomic transactions• Redis is single threaded and therefore, no locking is necessary• In other words, commands like INCR won’t tread on each other’s toes coming from multiple clients simultaneously! 17

18.
Key Expiration• When caching, we don’t want things to live forever• Any item in Redis can be made to expire after or at a certain time EXPIRE my_key 60 EXPIREAT my_key 1293840000 18

30.
Advantages of Persistence• On server restart, Redis re-populates its cache from files stored on disk• No issue of “cache warm-up”• It is possible to back-up and replicate the files/cache 30

31.
Memory Requirements?• Depends upon the payload size, and the data- type used• Instagram reports that they stored 300 million key-value pairs in about 5 GB of memory => 16 MB/million pairs (they also report that Memcache requires 52 MB for the same million keys) 31

34.
Design Considerations / Best Practices• Avoid excessively long keys• Use consistent key namespace nomenclature• Have human readable keys• Since there is no querying on values, keys should be thought-out before hand• Store data based on use-cases. Ad-hoc queries can-be very expensive• Multiple databases are useful for segmenting key namespaces, especially where key queries are needed 34

35.
Design Considerations / Best Practices• All data must fit in memory• Data duplication/redundancy is OK• Persistence strategy should be chosen based on the kind of data that you are storing and performance trade-off must be understood• Good for write-heavy, frequently changing and non-relational data• Polyglot-persistence is a smart choice• Start by using Redis to augment, and then replace 35