Redis tutorial of I: introduction to Redis

1. Introduction:

Over the past few years, the NoSQL database has become synonymous with high-concurrency, massive data storage solutions, and its products have mushrooming. However, only a few products stand out from the crowd, such as Redis, MongoDB, BerkeleyDB and CouchDB. Due to the different characteristics of each product, there are some differences in their application scenarios. The following is a simple explanation:

1). BerkeleyDB is a kind of very popular open source embedded database, in more cases can be used to store the engine, such as BerkeleyDB before being Oracle acquisitions as MySQL storage engines, predictably, the product has excellent concurrent scalability, support services and nested transaction, mass data storage and other important characteristics, in the aspect of real-time data is used to store has a very high value. However, it should be noted that the Licence of the product is GPL, which means that it is not free to use in all cases.

2). MongoDB is defined as Oriented-Document database server. Different from BerkeleyDB, this database can run independently and provide related data services like other relational database servers. We can learn from the official documentation of the product that MongoDB is mainly suitable for high concurrency forums or blog sites, which are characterized by high concurrent traffic, more reading and less writing, large amount of data, simple logic, and document data as the main data source. Like BerkeleyDB, the product's License is GPL.

3). Redis, a typical NoSQL database server, can run as a service program on its own server host, compared to BerkeleyDB. Most of the time, Redis is viewed as an Key/Value database server, but this is not the case. In the current version, Redis supports data structures such as List, Hash, Set, and Ordered Set in addition to Key/Value, so it is used more broadly. For this misunderstanding, the Redis website has also made a corresponding clarification. Unlike the above two products, Redis's License is Apache License, which is completely free for now.

4). memcached, data cache server. Why is the product explained here? Very simple, because I think it is the most similar to Redis in the way of use. After all, this is a technical blog about Redis, so with that in mind, we'll briefly compare the two products. First of all, the biggest difference between them is that memcached only provides data caching service. If the server goes down, the data previously cached in memory will all disappear. Therefore, it can be seen that memcached does not provide any form of data persistence, while Redis does. Moreover, Redis provides a richer data storage structure, such as Hash and Set. As for their similarities, there are two main ones, one is completely free, and the other is that the form of command they provide is extremely close.
     
ii. Advantages of Redis:

          1). Redis is extremely easy to use compared to other NoSQL products, so developers who have experience with similar products can use Redis to build their own platform in a day or two, or even a few hours.
          2). While solving many general problems, it also provides relevant solutions for some personalized problems, such as indexing engine, statistical ranking, message queue service, etc.

3. Main problems with Redis in the current version:

         
          2). No clustering support is provided, however, according to the website, this feature is expected to be added in version 2.6.
          3). In Publication/Subscription, if master goes down, slave cannot be automatically upgraded to master.
     
iv. Comparison with relational databases:

          Redis in the current version (2.4.7), provide the support for five different data types, of which only one type, both string types can be seen as Key - Value structure, while the rest of the data types are applicable to their respective characteristics of application scenarios, as for the details we will be behind the series of blog.
Compared with relational databases,           does not provide good support for complex logical relationships due to its relatively simple storage structure. However, in the scenario applicable to Redis, we can get a significant improvement in efficiency. Even so, Redis provides us with some basic concepts that a database should have. For example, you can choose to open different databases in the same connection, but the difference is that the database in Redis is named by number, and the database opened by default is 0. If you want to switch databases while the program is running, you can use Redis's select command to open other databases, such as select 1, and if you want to switch back to the default database later, you can simply execute select 0.
          in terms of data storage, Redis follow the mainstream of the existing NoSQL database, namely Key as unique identification of data retrieval, we can understand the simple as relational database index key, while Value as the main object of data storage, each Value has a Key associated with it, it's like the index physical data in the location of the data stored in the table. In Redis, Value will be treated as a binary byte stream for storing data in any format, such as Json, XML, and byte streams of serialized objects, so we can also think of it as an BLOB type field in RDB. Therefore, when making a data query, we can only use Key as our query condition. Of course, we can also use Value as Key of other data by applying some techniques provided in Redis, which we will introduce in the following blog.
     
5. How to persist memory data:

          by default, Redis stores a snapshot of the database on disk after a certain threshold is reached, depending on how much data has been modified in the current database, which can be set by configuration files. In general, we can also set Redis to be saved regularly. If more than 1000 key data are modified, Redis will persist the data every 60 seconds. By default, Redis persists every 15 minutes if there are 9 or fewer data changes.
          can be seen from the above mentioned scheme, if by the way, Redis runtime efficiency will be very efficient, as every time a new data change occurs, is only an in-memory cache data change, and this change will not be persisted to disk immediately, and in the operation of the vast majority of modified disk IO are avoided. However, there are always two sides to the problem. In this method, we really gain an improvement in efficiency, but lose the reliability of data. If the server where Redis resides goes down before the memory snapshot is persisted to disk, the modified data that was not written to disk is lost. To ensure high data reliability, Redis also provides another data persistence mechanism --Append mode. If the Redis server is configured in this manner, it is persisted to disk immediately whenever data changes occur.