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.
Small problem
In MySQL, by pre-establishing multiple tables or libraries, you can deploy these tables or libraries in Split to more servers when your business grows.
In Redis, how should the "Library sub-table" be implemented? What are the good design patterns?
Redis, Memcache, MySQL differences