What are the common key-value designs of Redis databases?

　User login system

It is a system that records user login information. After we simplify the business, we only have one table left.

Design of relational database

mysql>select*fromlogin;

　 --------- ------------ ---- ------------- ---------------------

|user_id|name|login_times |last_login_time|

　 --------- ---------------- ---------------- --- ------------------

|1|kenthompson|5|2011-01-0100:00:00|

|2| dennisritchie|1|2011-02-0100:00:00|

|3|JoeArmstrong|2|2011-03-0100:00:00|

------- ------------------------------------------------------------------ --

The primary key of the user_id table, name represents the user name, and login_times represents the number of logins of the user. After each user logs in, login_times will increase by itself, and last_login_time is updated to the current time.

Design of REDIS

Convert relational data into KV database, my method is as follows:

Key table name: Primary key value: Column name

Value column value

Generally, colon is used as the separator. This is an unwritten rule. For example, in the php-adminforredis system, the keys are separated by colon by default, so user:1user:2 and other keys will be divided into one group. So the above relational data is converted into kv data and recorded as follows:

Setlogin:1:login_times5

Setlogin:2:login_times1

Setlogin:3:login_times2

Setlogin:1:last_login_time2011-1-1

Setlogin:2:last_login_time2011-2-1

Setlogin:3:last_login_time2011-3-1

setlogin:1 :name"kenthompson"

setlogin:2:name"dennisritchie"

setlogin:3:name"JoeArmstrong"

If the primary key is known, you can use the get and set methods Get or modify the user's name, login times, and last login time.

Generally, users cannot know their own ID, they only know their username, so there must be a mapping relationship from name to ID. The design here is different from the above.

　set"login:kenthompson:id"1

　set"login:dennisritchie:id"2

　set"login:JoeArmstrong:id"3

In this way, every time a user logs in, the business logic is as follows (python version), r is the redis object, and name is the known user name.

　#Get the user's id

uid=r.get("login:%s:id"%name)

　#Automatically increase the number of user logins

The following is a possible rephrased sentence: ret = r.incr("login:%s:login_times" % uid)

　#Update the user's last login time

ret=r.set("login:%s:last_login_time "%uid,datetime.datetime.now())

If the requirement is only to know the ID, update or obtain the last login time and number of logins of a user, there is no difference between the relational database and the kv database. One is through btreepk and the other is through hash, both of which work very well.

Assume that there is the following requirement to find the N users who logged in recently. Developers have a look and it is relatively simple and can be done with just one SQL statement.

Please select all columns from the "login" table, sort in descending order by the "last_login_time" column, and limit the result set size to N

After the DBA understands the requirements, consider the future table if It is relatively large, so create an index on last_login_time. By accessing N records starting from the rightmost side of the index, and then performing N table return operations, the execution plan has a significant effect.

What are the designs of common Redis database key values? Two days later, another request came, and I needed to know who has logged in the most times. How to deal with the same relational type? DEV said it is simple

　select*fromloginorderbylogin_timesdesclimitN

The DBA takes a look and needs to create an index on login_time. Do you think there is something wrong? Every field in the table has a prime quote.

The source of the problem is that the data storage of the relational database is not flexible enough, and the data can only be stored using a heap table arranged in rows. A unified data structure means that you must use indexes to change the SQL access path to quickly access a certain column, and the increase in access paths means that you must use statistical information to assist, so a lot of problems arise.

There is no index, no statistical plan, and no execution plan. This is the kv database.

In response to the need to obtain the latest N pieces of data, in Redis, the last-in-first-out feature of the linked list is very suitable. We add a piece of code after the above login code to maintain a login linked list and control its length so that the most recent N logged-in users are always stored in it.

　#Add the current login person to the linked list

ret=r.lpush("login:last_login_times",uid)

　#Keep the linked list with only N bits

ret=redis.ltrim("login:last_login_times",0,N-1)

In this way, you need to get the id of the latest login person, the following code can be used

last_login_list=r .lrange("login:last_login_times",0,N-1)

In addition, to find the person who has logged in the most times, sortedset is very suitable for needs such as sorting and standings. We combine users and login times Stored uniformly in a sortedset.

zaddlogin:login_times51

zaddlogin:login_times12

zaddlogin:login_times23

In this way, if a user logs in, an additional sortedset is maintained, the code is as follows

#The number of login times for this user is increased by 1

ret=r.zincrby("login:login_times",1,uid)

So how to get the user with the most login times, sort in reverse order Just take the Nth ranked user

ret=r.zrevrange("login:login_times",0,N-1)

It can be seen that DEV needs to add 2 lines of code. The DBA does not need to consider indexes or anything.

TAG system

Tags are especially common in Internet applications. If designed with a traditional relational database, it would be a bit nondescript. Let's take the example of searching for a book to see the advantages of redis in this regard.

Design of relational database

Two tables, one for book details and one for tags, indicating the tags of each book. There are multiple tags in a book.

　mysql>select*frombook;

　 ------ --------------------------- ---------------------

　|id|name|author|

　 ------ ---- ------------------------------------------

　| 1|TheRubyProgrammingLanguage|MarkPilgrim|

　|1|Rubyonrail|DavidFlanagan|

　|1|ProgrammingErlang|JoeArmstrong|

　 ------ ------ ------------------------------------------

　mysql>select *fromtag;

　 --------- ---------

　|tagname|book_id|

　 ------ --- ---------

|ruby|1|

|ruby|2|

|web|2|

　|erlang|3|

　 --------- ---------

If you have such a need, the search is both ruby ​​and web. Books, how will they be handled if a relational database is used?

　selectb.name,b.authorfromtagt1,tagt2,bookb

　wheret1.tagname='web'andt2.tagname='ruby'andt1. book_id=t2.book_idandb.id=t1.book_id

The tag table is associated twice and then associated with the book. This SQL is quite complicated. What if the requirement is ruby ​​but not a web book?

Relational data is actually not very suitable for these set operations.

Design of REDIS

First of all, the book data must be stored, the same as above.

Setbook:1:name”TheRubyProgrammingLanguage”

Setbook:2:name”Rubyonrail”

Setbook:3:name”ProgrammingErlang”

setbook: 1:author"MarkPilgrim"

Setbook:2:author"DavidFlanagan"

Setbook:3:author"JoeArmstrong"

tag table We use sets to store data because Sets are good at finding intersections and unions

　saddtag:ruby1

　saddtag:ruby2

　saddtag:web2

　saddtag:erlang3

Then , a book that belongs to ruby ​​but also belongs to the web?

　inter_list=redis.sinter("tag.web","tag:ruby")

　That is, a book that belongs to ruby ​​but does not belong to the web ?

　inter_list=redis.sdiff("tag.ruby","tag:web")

　A collection of books belonging to ruby ​​and web?

　inter_list=redis .sunion("tag.ruby","tag:web")

It’s so simple.

From the above two examples, we can see that in some scenarios, relational databases are not suitable. You may be able to design a system that meets your needs, but it always feels weird and weird. It feels like something is being done mechanically.

Especially in the example of logging in to the system, indexes are frequently created for the business. In a complex system, ddl (create index) may change the execution plan. Since the SQL in the old system with complex business is all kinds of strange, causing other SQL to use different execution plans, this problem is difficult to predict. It is too difficult to require the DBA to understand all the SQL in this system. This problem is particularly serious in Oracle, and every DBA has probably encountered it. Although there are online DDL methods now, DDL is still not very convenient for systems like MySQL. When it comes to big tables, the DBA gets up early in the morning to operate during the low business hours. I have done this often. It is very convenient to use Redis to handle this demand, and only requires the DBA to estimate the capacity.

The above is the detailed content of What are the common key-value designs of Redis databases?. For more information, please follow other related articles on the PHP Chinese website!