Redis usage Scenarios by Yang Weihua

Reprinted from Sina Weibo architect Yang Weihua's blog http://timyang.net/tag/redis/, omitted part of the content

By: Yang Weihua has tested the performance of Redis in 2010, and has given a preliminary conclusion: "Redis performance is amazing, the top ten sites in China estimated the sub-products with 1 Redis can meet the storage and cache needs." "And I started looking at Redis today, and I've fallen behind for 6 years.

What is Redis?
The result of this problem affects how we use Redis. If you think that Redis is a key value store, it might be used instead of MySQL, and if you think of it as a persistent cache, it might just save some of the temporary data that is frequently accessed. Redis is an abbreviation for remote DIctionary server, and the subtitle on Redis on the official website is a persistent key-value database with built-in NET interface written in Ansi-c for Posix systems, this definition is biased toward key value store. There are also some views that Redis is a memory database because its high performance is based on the operation of the RAM. Others argue that Redis is a data structure server because Redis supports complex data features such as list, set, and so on. Different interpretations of the role of Redis determine how you use Redis.

Internet data is currently used in two different ways to store, relational database or key value. But these internet services do not belong to these two types of data, such as the user's relationship in the social platform, it is a list, if you want to use relational database storage needs to be converted into a multi-row record form, this form has a lot of redundant data, each row needs to store some duplicate information. If you store with key value it is cumbersome to modify and delete, you need to read out all the data and write again. Redis has designed a variety of data types in memory, allowing the business to access these data structures at high speed, and without concern for persistent storage issues, from an architecture that addresses some of the previous two types of storage needs.

Redis is a key value or key list data for small-scale memory types, and several Redis usage scenarios are:

• Large number of visits
• Key value or key list data structure
• Small capacity, controllable, can be all put into memory. Because Redis is a single-threaded design, large value results in a certain blockage of subsequent requests. In addition HashSet when Hgetall due to the presence of traversal operations, it is also not suitable for collections too large. If the data exceeds the single machine capacity can be distributed to multiple machines using the conventional sharding method
• Scenarios that need to be persisted

Above four o'clock the general condition should be the necessary condition. As a result, the user profiles and friends List of common websites are available for use with Redis. Since Redis has all the features of memcached, is there any discussion that memcache can quit? I would prefer to choose memcached rather than redis in the following cases

• Simple key value that does not need to be persisted, such as 100 bytes or less. In this case, the use of memcached space is more economical and easier to maintain.
• There are rolling expiration requirements, such as the session of the website, each new logged-on user periodically expires.

In the process of using Redis, we found that many Redis are different from memcached, and also different from MySQL features.
(This article mainly discusses Redis not enabling VM support)

1. Schema
MySQL: Need to be designed beforehand
Memcached: No design required
Redis: Small systems can be used, but if you want to plan and use Redis properly, you'll need to do some planning like this in advance.

Data item: What is the content of value saved, such as user profile
Redis data types: such as String, List
Data size: 100 bytes
Number of records: 1 million (determine if splitting is required)
??
The plan above is a schema, why does Redis need to design schema in a large project beforehand? Because the Redis server has a capacity limit, the data capacity cannot exceed the physical memory size, taking into account the scalability of business data, the number of records will continue to increase, the content of a single record will grow, so you need to plan the capacity in advance. The data architect uses the schema to determine whether Redis for the current business needs a "sub-database table" to meet the scalability requirements.

2. Capacity and bandwidth planning
Capacity Planning
MySQL: < HDD size
Memcached: < RAM
Redis: < RAM

Bandwidth planning
Since Redis is more than 10 times times faster than MySQL, bandwidth needs to be planned beforehand to avoid bottlenecks in bandwidth runs.

3. Performance Planning (QPS)
When the system read and write bottlenecks, usually how to solve?
Mysql
Write: Split to multiple servers
READ: (1) split (2) write less can also be solved by adding slave

Memcached
Read and write: Both are split into more nodes by hash.

Redis:
Write: Split
READ: (1) split (2) write less can also be solved by adding slave

4. Extensibility
MySQL: Sub-database sub-table
Memcached:hash distribution
Redis: Also can be divided into libraries, can also hash distribution

Summary
With the above analysis, Redis has both MySQL and memcached features in many ways and is more like MySQL in some ways.
Because Redis data cannot exceed memory size, it requires prior capacity planning to ensure sufficient capacity and, on the other hand, is designed to prevent unlimited data size increases, which can result in Redis being non-extensible.
Redis needs to be pre-engineered with a split plan like MySQL.

End with a design philosophy of MongoDB

Databases is specializing–the "one size fits all" approach no longer applies.

Redis usage Scenarios by Yang Weihua