Share Redis Use the full Raiders: How to jump out of the SQL this pit

With the proliferation of data volume, Mysql+memcache has not met the needs of large-scale Internet applications, many organizations have chosen Redis as its architectural complement, however, redis the use of the threshold is not low, such as not supporting SQL, here for everyone to share the Redis use of the full raiders.

Redis, one of the most closely watched NoSQL databases, has been used by many well-known internet companies, such as Sina Weibo, Pinterest and Viacom. However, by nature does not support SQL but it makes him look very difficult to approach, here we look at @utopiar Bowen-Explore Redis.

One of the explorations: Redis? What is it?

In short, Redis is a powerful key-value database, powerful with two points: fast response (so data memory storage, written to disk only when necessary), feature-rich (support for multiple data types, and complex operations on various types).

In fact, an important feature of Redis is that it is not a database in its usual sense, although it is called a database because it can store and maintain data for you, but it does not provide any SQL dialect like a relational database. But don't worry, Redis is not a black hole that eats data, it just doesn't support SQL and related functionality, but it provides a robust protocol for interacting with it.

In Redis, there is no concept of a datasheet, no need to care about Select, join, view, and other operations or functions, nor does it provide a data field similar to int or varchar. You will be faced with relatively primitive data sets and data types.

Explore the second: Available datatypes

Let's take a closer look at how this strange database works. As seen above, Redis is based on the Key-value paradigm to store data, so first focus on the concept of "key".

Key is essentially a simple string, such as "username", "password", and so on. In the definition of key, in addition to the use of space, you can arbitrarily use ordinary characters, numbers, etc., such as ".", ":", "_" and so on in the definition of key can be used normally, so like "user_name", "User:123:age", "User:123:username "is the definition of a good key.

Unlike the name of a field in an RDBMS, the key here is an important part of Redis, so we have to be more careful with key. In the following narration, Redis does not have the concept of table, so it looks like "Select username from users WHERE user_id=123;" This simple task can only be implemented in a different way, in order to achieve this goal, in Redis, a way is through the key "User:123:username" to obtain the result value. As you can see, the definition of key carries mysterious information (like user IDs). In Redis, the importance of key can be seen. (The same is true for key in other Key-value databases.) )

Now that you have a clear idea of key, let's take you to the magical world of available data types.

Strings

String is the most basic data type in Redis and is a normal binary secure string that supports a maximum data length of 1Gb.

You can set string data for a key by using the SET command, and you can obtain results from a GET command based on a key. If you want to store digital information, such as a counter, you can also store it in string data and use INCR and DECR to do the self-increase and decrement operation.

Lists

A list is a collection of string data in which entries are arranged in the order in which they are inserted. You can take the list as a chain (chain), so you can add a new link (link) to the left (chain) or rightmost (chain end), but you can also put it in the middle of a chain, but break a knot.

You can add data to the list (L:left, r:right) by using the Lpush and Rpush commands, and the lpop or Rpop command pops up the element (deleting the element at the same time) or by Lrange to get the specified range of elements (only data is returned and no elements are deleted). Additional elements can also be added at the specified location by LSet, but usually this is much slower than simple lpush or rpush.

Hashes

Hashes stores more tightly related data in a concise way. Hashes implements a built-in key-value pair for each stored key to store data, for example, for the "user" key, its value can be multiple fields and a data set that corresponds to each character's value pair. If you are familiar with programming languages like Ruby or JavaScript, the hashes here are similar to the hash concepts in those languages.

Sets

Sets and its mathematical concept of the same name "set" meaning the same, is a collection of distinct elements. In Redis, these objects become string types in Redis. As you can imagine, sets differs from lists in that the elements in sets are unordered and cannot be repeated, and you cannot put two identical data in sets.

You can add data to set by Sadd, Srem delete data, or return and delete this data by Spop. In addition, through Sunion, sinter, Sdiff commands to implement the set of "set", "intersection", "difference set" operation.

Ordered Sets

Ordered sets is similar to sets, where each element in the Ordered set has a weight that is used to compare and sort with other elements.

Of course ordered set has similar operations to ordinary sets, Zadd and Zrem are adding and deleting elements, respectively. Ordered set also has its own unique operations: ZINCR and Zscore, which are used to weigh +1 of the element, and then return the weight value of the element.

Explore the third: Where are my tables?

Using Redis is completely different from the SQL datasheet we used before, there is no language to support you in querying the data on the server, there are only a few commands to help you manipulate the keys in the database. The commands in Redis are data type sensitive, which means that you cannot execute the SET command on the list, otherwise you will get a hint of executing the error. You can send commands to Redis server by REDIS-CLI or other interfaces in the programming language you use. In the following example, we only emphasize the command itself, not the way you submit it to Redis server.

Imagine a simple SQL database table, like a table in some applications that holds user data:

Storing data

If we wanted to store the above data in Redis, how would you design a database solution in Redis? Maybe it's more intuitive in terms of application vision. With SQL, we get a user's information in the select by specifying a user ID, in other words, the way we need to differentiate between different data entities, so we can identify and get user information through a unique identity. So if you add the user ID information to the Redis key, then our query needs are resolved, and in Redis, the data is stored in the following form:

So, to be a user ID, we can read the user information in the form of key user:id:username,user:id:password,user:id:name,user:id:surname.

User Login

The storage form above can also be used for user login, but it requires a way to query the user's ID based on username. That means we also need to establish a connection between username and IDs. This can be done by adding another Redis key "User:username:id".

Now if Mario Rossi wants to log in, we can find the username through key "User:user2:id" and get all the information from the user.

Primary key

How to guarantee the uniqueness of ID value in Redis? In SQL, you can use the ID int primary key auto_increment to define your own primary key to implement, and now we need a similar way to generate a different ID for each user. The scenario in Redis is this: Create a key "user:next_id" and use it as a counter that executes the INCR command on the key "user:next_id" whenever a new user is added, depending on the numeric data mentioned in the previous data type.

SELECT * from users;

The next challenge is to query the user list. Maybe you think our data store is enough to query the user list: You can get the current value of "user:next_id" counter, and then iterate through 0 to counter to get the user's data in one or more steps. But if a user is removed from the system (the deletion is described below), and we traverse all IDs from 0 to counter, some IDs will not query any data.

Although this is usually not a problem, we do not want to waste time on nonexistent user data, so we need to create another key "User:list", which is the list or set type, for storing each new user ID and, if necessary, from "User:list" Remove the ID from the I prefer to use list because it may implement paging through the Lrange command.

Delete User

Another problem to face is "data integrity" and see what happens when we delete users. We need to delete each reference to this user, that is, to delete all the following key "user:id:*", "User:username:id", and "User:list" in the user ID.

Explore the four: A simple use case

In order to learn practical, we try to design a virtual library, and can be grouped according to the theme of the book. The following example is slightly more complex than the user table above, but you will learn how to handle the association relationship in Redis.

In applications, we need to collect books and store their title,author (s), topic (s), pages, Price, ISBN and description. Obviously some books have more than one author, and it may cover a different topic (for example, a book can be a programming subject or a description of Ruby programming). Another author may have written many books, and a subject will inevitably contain many books. As you can see, there is a many-to-many relationship between authors and books, themes and books.

SQL scenario

First, we try to use the SQL datasheet to build a data model for this scenario so that we can simulate in the Redis realm more intuitively:

Redis scene

We've already covered how to store data in Redis, so it's not a problem to understand the three tables books,authors and topics. But when faced with the Many-to-many association between Books-authors and Book-topics tables, the problem becomes complicated. Take topic as an example to see how to solve the relationship between book and topic, once the relation is clear, the relationship between book and author will be solved.

For each book, we need to know which topics it belongs to, and also for each topic, to process each book it contains. In other words, for each book, you need a list of IDs that store the topic associated with it, and for each topic, you need a list of IDs that stores the books associated with it. This is where the set is doing. We will create two sets: "Book:id:topic" and "Topic:id:books", which hold the book's Topics ' ID list, which stores the topic Books ' ID list. Take the data in the previous SQL scenario as an example, the book "Programming Erlang" (ID 2 in the Books table) will have a key of "book:2:topics", the value is set type and the data is (1,3) data information; Programming "There will be a dataset with a key of" topic:1:books "and a value (1,2).

After analysis, we get the data model of Redis scene:

As you can see, a many-to-many association in SQL can be implemented with two sets in Redis. You'll find this to be quite useful, and it gives us the ability to freely access other information: You can get books that belong to multiple topics by working in the intersection of all the "topic:id:books" collections of interest. For example, the intersection of the set "Topic:1:books" (programming Theme) and "Topic:2:books" (Ruby theme) will result in a collection of only one element (1) to obtain the Id=1 book: Programming Ruby.

For this implementation, you must pay special attention to the deletion of the data. Because there is a reference to books in topics, and there is a reference to topics in books, how is deletion done? To delete the data in books as an example, the first thought is to delete each key is "book:id:*" data, but to do this before you need to traverse topics all the key to "Topic:id:books" collection, and remove the ID of the book to be deleted, And, of course, remove this ID from the list in books where key is "book:list". If you want to remove a topic, the operation is similar: you need to traverse the topic ID set in books with the key "Books:id:topics" before removing all key "topic:id:*" messages from topics. and remove the ID from the topic you want to delete, and remove the ID from the Topic:list list. The same operation applies to authors.

Explore the five: back home

For Redis's exploration to a passage, now look back to see what wonderful things we have harvested in our bags.

We learned the data types and operation commands in Redis, and there are some other interesting things. Is there a few memorable stories:

Resolve unique self-adding primary key problems by executing the INCR command on string data

Handle user login scenarios with rich key: "User:username:id"

Multi-Many-to-many association between data through set implementation

So far, the journey of Redis is over, and hope has not brought you unhappiness. Finally sent a pair of good Ji: having fun job free software!

Original link: http://www.cnblogs.com/enjiex/p/3618546.html