Redis new storage mode diskstore

ArticleDirectory

• 1. Schema
• 2. capacity and bandwidth Planning
• 3. Performance planning (QPS)
• 4. scalability
• Summary
• 1. What is redis?
• 2. redis cannot be faster than memcache
• 3. data stored in a single redis instance must be smaller than the physical memory.
• 4. redis's Vm implementation is repetitive.
• 5. Use redis in get/set mode
• 6. Use aof instead of snapshot
• Summary

Redis author antirez is a very diligent developer who continues to develop new features when redis's performance is amazing, such as from the new clusterSource codeWe can see that the author has taken some core ideas of dynamo and paxos into consideration and implemented some concise implementations. Compared with other products such as memcached, memcached has not changed much in a few years. In the Web 2.0 era, memcached is not enough, technical staff need to consider a lot of extra work to adapt memcached to new changes and needs.

In January 5, Google groups published an article on redis diskstore, which reflected on the redis VM mode and considered whether there is a better way to access redis of big data.

A few months after VM started to work my feeling about it started to be not very good... That VM was not the way to go for the future of redis

The best way to access web 2.0 data is completely memory-based, such as using memcached or redis snapshot. However, in more business scenarios, the data size will exceed the ram capacity, so there are several different design modes.

1.VM Mode. Store data by page. applications (such as redis) or operating systems (such as varnish) Send cold data swap pages with less traffic to the disk, multiple pages are automatically swapped out from the disk to the memory. Disadvantages of VM implementation for applications:CodeThe logic is complex. If the cold and hot data boundaries in the business are not clear, the exchange cost is too high and the overall system performance is low. Many netizens have also reported on Weibo the instability of VM usage. Disadvantages of implementing VM in the operating system the misunderstandings of redis have been introduced in the previous article.

2.Disk ModeAll data read/write accesses are based on disks, and the operating system can only cache the accessed data. Because modern operating systems are very smart and frequently accessed data is added to the memory, applications do not need too many special logics. MongoDB is designed in this way. This method also has some known disadvantages. For example, the operation of writing MMAP to a disk is controlled by the operating system. The operation system writes data first and then writes data where the application is unaware, if a crash occurs during the write process, data consistency will be faulty. This is also the controversial standalone durability issue of MongoDB,

MongoDB is not designed around single-server durability, but rather multi-server durability.

However, MongoDB does not think this is a problem. Their opinion is: Is it necessary to consider whether a single machine is completely reliable in the current era? Is it necessary?

3.Hard Disk Storage + Cache. The actual principle is similar to that of MySQL + memcache, but the two functions are combined into an underlying service, simplifying the call.

In the above methods, in addition to the VM, antirez finds that the MongoDB method is not suitable either. Therefore, the disktore method is used to implement new disk storage. The details are as follows:

1) read operations: Read through and LRU. Data that does not exist in the memory is pulled from the disk and put into the memory. data that cannot be stored in the memory is eliminated by LRU.

2) write operations are handled independently by another spawn thread. The write thread is usually asynchronous. Of course, you can set cache-flush-delay to 0. redis tries its best to ensure instant writing. However, in many cases, delayed writing can provide better performance. For example, some counters are stored in redis. If a certain count is modified repeatedly in a short time, redis only needs to write the final result to the disk. The author of this practice is per key persistence. Since writes are merged by key, there is still a difference with snapshot, and disk store does not guarantee time consistency.

Since the write operation is a single thread, even if the cache-flush-delay is set to 0, multiple clients need to wait in queue for simultaneous writing, if the queue capacity exceeds the cache-max-memory redis design, it enters the waiting state, causing the caller to get stuck.

On Google group, enthusiastic netizens quickly completed the stress test. When the memory is used up, the processing speed of set per second dropped from 25 K to 10 K, and then almost got stuck. Although cache-flush-delay can improve the duplicate Write Performance of the same key, it can cope with temporary Peak write by adding cache-max-memory. However, the write bottleneck of diskstore is still in Io.

3) Relationship between RDB and the new diskstore format
RDB is the storage format of the traditional redis memory mode, and diskstore is another format. What is the relationship between the two?

• You can use bgsave to save the diskstore format as RDB at any time, and the RDB format is also used for redis replication and intermediate formats between different storage methods.
• You can use tools to convert the RDB format to the diskstore format.

Of course, diskstore works well, but it is still in alpha version. It is also a simple demo, diskstore. C adds only 300 lines of comments. The implementation method is to save each value as an independent file, and the file name is the hash value of the key. Therefore, diskstore must have a more efficient and stable implementation in the future to be used in the production environment. However, with a clear interface design, diskstore. C can easily be converted into a B-tree implementation. Many developers are also actively exploring the feasibility of using bdb or InnoDB to replace default diskstore. C.

I have also introduced several misunderstandings about redis. redis has a rich memory data structure, which is inherently in conflict with persistent data storage, if you use diskstore to save a large list/set (such as a ranking list), the performance will be poor. Each time you modify a list element, you need to re-save the entire large list. The overhead is much higher than that of traditional RDBMS.

End with a design philosophy of MongoDB

Databases are specializing-the "one size fits all" approach no longer applies.

Redis capacity and use plan Wednesday, Jan 5th, 2011 by tim | 14 comments
Filed under: Data | tags: memcache, memcached, MySQL, redis

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 has a capacity limit, 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, we need to plan the capacity in advance. The data architect uses the schema to determine whether redis of the current business needs "database/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?

Several misunderstandings about redis: Saturday, Dec 4th, 2010 by tim | 42 comments
Filed under: Data | tags: Key Value Store, redis

A major system fault occurred on Weibo a few days ago, and many technical friends are concerned about it. The reason is not as high as James Hamilton's on design and deploying Internet-scale service (1) in summary, James's first experience "design for failure" is a key to the success of all Internet architectures. The engineering theory of Internet systems is actually very simple. James paper's content is almost not a theory, but a number of practical experiences are shared. Each company's understanding and execution of these experiences determine the success or failure of the architecture.

Now I have studied redis. Last year, I had a memcachedb, Tokyo tyrant, and redis performance test. So far, this benchmark still works. Over the past year, we have experienced the temptation of a lot of dazzling key-value storage products to fade out from Cassandra (Twitter is suspended for main services) to the rise of hbase (Facebook's new mailbox business uses hbase (2), when we look back at redis, we find that there are only over 10 thousand lines of source codeProgramIt is full of magical and unexplored features. The performance of redis is amazing. The sub-products of the top 10 websites in China are estimated to be able to meet the storage and cache needs with one redis. In addition to the performance impression, there are some misunderstandings about redis in the industry. This article provides some ideas for your discussion.

1. What is redis?

This problem affects how we use redis. If you think redis is a key value store, it may be used to replace MySQL; if you think it is a persistent cache, it may only save some temporary data that is frequently accessed. Redis is the abbreviation of remote dictionary server. On redis's official website, the subtitle is a persistent key-value database with built-in net interface written in ANSI-C for POSIX systems, this definition is biased towards key value store. There are also some rules that hold that redis is a memory database, because its high performance is based on memory operations. Others think that redis is a data structure server, because redis supports complex data features, such as list and set. Different interpretations of the role of redis determine how you use redis.

Currently, Internet data is stored in relational databases or key values in two ways. However, these Internet businesses do not belong to these two data types. For example, the relationship between users in the social platform is a list, if you want to store data in a relational database, you need to convert it into a multi-row record format, which has a lot of redundant data, and each row needs to store some duplicate information. If the key value is used for storage, modification and deletion are troublesome. You need to read all the data before writing it. Redis has designed various data types in the memory, allowing businesses to access these data structures at high speed and without the need to worry about persistent storage, the architecture solves the problems that the first two types of storage need to take some detours.

2. redis cannot be faster than memcache

Many developers believe that redis cannot be faster than memcached. memcached is fully memory-based, while redis has the persistence storage feature. Even asynchronous redis cannot be faster than memcached. However, the test result is basically the absolute advantage of redis. I have been thinking about this reason. The reasons for this are as follows.

• Libevent. Unlike memcached, redis does not select libevent. In order to cater to the versatility, libevent causes huge code (currently redis code is less than 1/3 of libevent) and sacrifices a lot of performance on specific platforms. Redis uses two files in libevent to modify its epoll event loop (4 ). Many developers in the industry also suggested using another libevent to replace libev with high performance, but the author insisted that redis should be small and dependent. One impressive detail is that you do not need to execute./configure before compiling redis.
• CAS problems. CAS is a convenient method in memcached to prevent competition for resource modification. The CAS implementation needs to set a hidden CAS token for each cache key. The CAS version is equivalent to the value version number, and the token needs to increase each set. Therefore, the CPU and memory overhead is generated, although these overhead are small, however, after a single machine has 10 Gb + cache and tens of thousands of QPS, these overhead will bring some minor performance differences (5) to the two sides ).

3. data stored in a single redis instance must be smaller than the physical memory.

Putting all redis data in the memory brings high-speed performance, but it also brings some unreasonable points. For example, a medium-sized website has 1 million registered users. If the data is stored in redis, the memory capacity must be able to accommodate these 1 million users. However, the actual business situation is that 1 million users only have 50 thousand active users, and only 0.15 million users have accessed the service once in a week. Therefore, the data of all 1 million users is not properly stored in the memory, ram needs to pay for cold data.

This is very similar to the operating system. All applications in the operating system access data in the memory, but if the physical memory cannot accommodate new data, the operating system intelligently switches some data that has not been accessed for a long time to the disk, leaving space for new applications. Modern Operating systems provide applications with virtual memory instead of physical memory.

Based on the same considerations, redis 2.0 also adds VM features. This allowed the redis data capacity to break through the physical memory limit. The cold/hot data separation is realized.

4. redis's Vm implementation is repetitive.

Redis's Vm is still implemented by itself based on the previous epoll Implementation ideas. However, as mentioned in the previous introduction of the operating system, the OS can also automatically help the program to achieve hot and cold data separation. redis only requires the OS to apply for a large memory, and the OS will automatically put hot data into the physical memory, the varnish, also known as "understanding modern operating system (3)", implements cold data exchange to hard disks and achieves great success.

The author explained several reasons for self-Implementation of the VM (6 ). The VM swap-in and swap-out of major OS is based on the page concept. For example, if the OS VM1 page is 4 kb, if one element exists in 4 kb, even if only one byte is accessed, this page will not be swap, and it is also true that reading a byte may be converted into 4 K useless memory. Redis can achieve the granularity of control switch-in. In addition, when accessing the swap memory area of the operating system, the block process is also one of the reasons that redis needs to implement its own VM.

5. Use redis in get/set mode

As a key value, many developers naturally use redis in the Set/get method. In fact, this is not the optimal method. Especially when the VM is not enabled, all redis data needs to be stored in the memory, which is especially important to save memory.

Assume that a key-value unit occupies a minimum of 512 bytes, even if only one byte is saved, the unit occupies 512 bytes. At this time, there is a design mode that can reuse keys, put several key-values into a key, and store values as a set, so that 512 bytes will store 10-times of capacity.

To save memory, we recommend using hashset instead of set/get to use redis. For details, see references (7 ).

6. Use aof instead of snapshot

Redis can be stored in two ways. The default mode is snapshot. The implementation method is to regularly save the snapshot of the memory to the hard disk, the disadvantage of this method is that if a crash occurs after persistence, a piece of data will be lost. Therefore, driven by the perfectionist, the author adds the aof method. Aof is append only mode. When writing memory data, the Operation Command is saved to the log file. In a system with tens of thousands of concurrent changes, the command log is a very large data, management and maintenance costs are very high, and the restoration and reconstruction time will be very long, leading to the loss of aof High Availability intent. What's more, redis is a memory data structure model. All its advantages are based on efficient atomic operations on complex memory data structures, this shows that aof is a very uncoordinated part.

In fact, aof mainly aims at data reliability and high availability. There is another method in redis to achieve the goal: replication. Because of redis's high performance, there is basically no replication latency. This prevents spof and achieves high availability.

Summary

To successfully use a product, we need to have a deep understanding of its features. Redis has outstanding performance. If you are proficient in controlling redis, it will be of great help to many large domestic applications. We hope that more colleagues will join redis usage and code research.

References

1. On Designing and deploying Internet-scale service (PDF)
2. Facebook's new real-time messaging system: hbase to store 135 + billion messages a month
3. What's wrong with 1975 Programming
4. Linux epoll is now supported (Google groups)
5. CAS and why I don't want to add it to redis (Google groups)
6. Plans for virtual memory (Google groups)
7. Full of keys (Salvatore antirez sanfilippo)

From: http://timyang.net/tag/redis/