Redis capacity and usage Plan)

ArticleDirectory

• 1. Schema
• 2. capacity and bandwidth Planning
• 3. Performance planning (QPS)
• 4. scalability
• Summary

The author of this article is timyang from Sina Weibo.RedisI have done some tests and research. This is a summary article that is closer to practical application. What I mentioned in this ArticlePlanningNot only applies to redis, but also to our commonly used databases and CacheUseThe planning idea also has guiding significance.

When using redis, we found that redis is different from memcached and also different from MySQL.

(This article mainly discusses the situation where VM support is not enabled for redis)

1. Schema

MySQL: requires prior Design
Memcached: no design required
Redis: small systems do not need to be used. However, if you want to properly plan and use redis, you need to make the following plans in advance:

• Data items: What is stored by value, such as user data
• Redis data type: such as string, list
• Data size: such as 100 bytes
• Number of records: for example, 1 million (determines whether to split)
• Zookeeper

The above plan is a schema. Why does redis need to design a schema in advance for large projects? Because the redis server hasCapacityRestrictions: The data capacity cannot exceed the physical memory size. Considering the scalability of business data, the number of records will increase continuously and the content of a single record will also increase. Therefore, you need to plan the capacity in advance, the data architect uses schema to determine whether redis of the current business needs "database sharding and table sharding" to meet scalability requirements.

2. capacity and bandwidth Planning

Capacity Planning
MySQL: Memcached: <Ram
Redis: <Ram

Bandwidth Planning
Because redis is more than 10 times faster than MySQL, you need to plan the bandwidth in advance to avoid bottlenecks when the bandwidth is full.

3. Performance planning (QPS)

When a bottleneck occurs in system read/write, how can this problem be solved?
MySQL
Write: Split to multiple servers
Read: (1) Split (2) less write can also be solved by adding slave

Memcached
Read/write: all are split to more nodes through hash.

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

4. scalability

MySQL: database/table sharding
Memcached: Hash Distribution
Redis: Database sharding or hash Distribution

Summary

Through the above analysis, redis has the features of MySQL and memcached in many aspects, and is more like MySql in some aspects.
Because redis data cannot exceed the memory size, on the one hand, we need to carry out capacity planning in advance to ensure sufficient capacity; on the other hand, we need to prevent the unlimited increase in data size, which leads to redis not being scalable.
Redis needs to pre-design the sharding scheme like MySQL.

Minor issues

In MySQL, multiple tables or databases can be created in advance to deploy these tables or databases on more servers during business growth.
In redis, how should we implement "database/table sharding? What are the good design patterns?

Link: http://timyang.net/data/redis-capacity/