Redis learns a

First, Introduction:

In the past few years, NoSQL databases have become synonymous with high-concurrency, massive data storage solutions, and the corresponding products have sprung up. However, there are only a handful of products that can stand out, such as Redis, MongoDB, BerkeleyDB and Couchdb. Because each product has different characteristics, so there are some differences in their application scenarios, the following is only a simple explanation:
1). BerkeleyDB is an extremely popular open-source embedded database that can be used in more situations for storage engines, such as BerkeleyDB, which was previously used as a storage engine for MySQL before it was acquired by Oracle, thus anticipating the excellent concurrency scalability of the product. Supporting transactions and nested transactions, massive data storage and other important features, in the storage of real-time data for the very high value available. However, it should be noted that the licence of the product is the GPL, which means that it is not used for free in all cases.
2). The definition for MongoDB is oriented-document database server, and unlike BerkeleyDB, the database can run independently as other relational database servers and provide related data services. From the official documentation of this product we can be informed that MongoDB is mainly applicable to high-concurrency forums or blog sites, these sites have the main characteristics of high concurrent access, read less write, large data volume, simple logic relationship, as well as document data as the main data source. Like BerkeleyDB, the license of the product is the same as the GPL.
3). Redis, a typical NoSQL database server, can operate independently of its own server host as a service program, compared to BerkeleyDB. In many cases, people just treat Redis as a Key/value database server, but that's not the case, and in the current version, Redis supports data structures such as list, Hash, set, and ordered set in addition to Key/value. So it's also more broadly used. For this misunderstanding, the Redis official website has also been clarified accordingly. Unlike the above two products, Redis's License is Apache License, and for now it is completely free.
4). memcached, data cache server. Why should we give an explanation of the product here? Very simple, because I think it is most similar to Redis in the way it is used. After all, this is a technical blog about Redis, and for this reason, we will briefly compare the two products. First of all, the biggest difference between them, memcached just provides the data caching service, once the server is down, the previously cached data in memory will all disappear, so you can see that memcached does not provide any form of data persistence, and Redis provides such a function. Another is that Redis provides a richer data storage structure, such as hash and set. As for their similarities, there are two main points, one of which is completely free, and then there is the very close order form they provide.

second, the advantages of Redis:

1). Redis is extremely easy to use compared to other NoSQL products, so for developers with similar product experience, Redis can be used to build their own platform for a day or two or even a few hours.
2). While solving a lot of commonality problems, it also provides some relevant solutions for some personalization problems, such as index engine, ranking of statistics, Message Queuing service, etc.

third, the current version of the main problems of Redis:

1). There is no support for the Windows platform in the official version, only the Unix-like and MACOSX platforms are supported in the released official version.
2). The cluster support is not provided, however, according to the official website, this feature is expected to be included in version 2.6.
3). publication/subscription function, if Master is down, slave cannot be automatically promoted to master.

Iv. Comparison of relational databases:

In the current version (2.4.7) of Redis, there is support for five different data types, with only one type, which can be treated as a key-value structure, while other data types have scenarios for their own characteristics. As for the details, we will explain it in the blog behind the series.
Because of its relatively simple storage structure compared to relational databases, Redis does not provide good support for complex logical relationships, but in the case of Redis, we can achieve significant efficiencies. Even so, Redis provides us with some basic concepts that the database should have, such as the option to open different databases in the same connection, but the database in Redis is named by numbers, and the database opened by default is 0. If the program is going to switch databases while it is running, you can use the Redis Select command to open other databases, such as Select 1, if you want to switch back to the default database later, just select 0.
In the area of data storage, Redis follows the mainstream idea of the existing NoSQL database, that is, key as the unique identifier of the data retrieval, we can simply understand it as the key of the index in the relational database, and value as the main object of the data storage. Each of these value has a key associated with it, which is like where the physical data in the index is stored in the data table. In Redis, value is treated as a binary byte stream for storing data in any format, such as a byte stream of JSON, XML, and serialized objects, so we can also think of it as a blob type field in an RDB. Thus, in the case of data query, we can only be based on key as a condition of our query, of course, we can also apply some of the techniques available in Redis to use value as a key to other data, which we will be described in the following blog.

Five, how to persist the memory data:

By default, Redis references the amount of data that is being modified in the current database, and when a certain threshold is reached, a snapshot of the database is stored on disk, which we can set by the configuration file. In general, we can also set Redis to be saved on a timed basis. If more than 1000 key data is modified, Redis will persist data persistence every 60 seconds. The default setting is that Redis will persist every 15 minutes if there are 9 or 9 of the following data modifications.
As can be seen from the scenario mentioned above, if this is the case, Redis's runtime efficiency will be very efficient, and whenever new data modifications occur, only the memory cache data changes, and such changes are not immediately persisted to disk, This avoids the occurrence of disk IO in the vast majority of modification operations. However, things tend to be two-sided, and in this approach we do get an efficiency boost, but we lose the reliability of the data. If the server on which Redis resides is down before the memory snapshot is persisted to disk, the modified data that is not written to the disk will be lost. To ensure high data reliability, Redis also provides another data persistence mechanism--append mode. If the Redis server is configured for this mode, it is immediately persisted to disk whenever a data modification occurs.

Redis learns a