Home > Database > Redis > How to do paging in redis

How to do paging in redis

(*-*)浩
Release: 2019-11-21 09:20:11
Original
4119 people have browsed it

How to do paging in redis

The user comments under each topic are assembled and written into Redis. Each topic will have a topicId, and each comment will be associated with the topicId. Approximate data The model is as follows: (Recommended learning: Redis video tutorial)

{ topicId: 'xxxxxxxx', comments: [ { username: 'niuniu', createDate: 1447747334791, content: '在Redis中分页', commentId: 'xxxxxxx', reply: [ { content: 'yyyyyy' username: 'niuniu' }, ... ] }, ... ]}
Copy after login

After querying the comment data from MySQL, assembling it and saving it to Redis, you can get the assembly from Redis every time in the future Good comment data, as can be seen from the above data model, the data is all key-value data, and it must be stored using hash. However, every time the comment data is retrieved, it needs to be paged and sorted by the createDate field. The hash must be Paging and sorting are not possible.

So, let’s take a look at the data types supported by Redis one by one:

1. String: Mainly used to store strings, and obviously does not support paging and sorting.

2. Hash: Mainly used to store key-value data. The comment model is all key-value data, so Hash will undoubtedly be used here.

3. List: Mainly used to store a list. Each element in the list is saved in the order in which the elements are inserted. If we sort the comment models by createDate and then insert them into the List, it seems that Sorting can be done, and paging can also be done by using the LRANGE key start stop command in List.

Well, the List here seems to meet our paging and sorting requirements, but comments will still be deleted, so the data in Redis needs to be updated. If every time a comment is deleted, the data in Redis will be deleted. Rewriting all the data once is obviously not elegant enough and the efficiency will be greatly reduced. It will undoubtedly be better if the specified data can be deleted. The only two instructions in the List that involve deleting data are LPOP and RPOP, but LPOP and RPOP Only the data at the head and tail of the list can be deleted, and the data at the specified position cannot be deleted. (Note: There is actually a LREM command that can be deleted, but it is very inconvenient). Moreover, when there is high concurrent access to the interface, this list may It can be extended indefinitely, and there will be a lot of duplication in the data, which will affect normal business, so List is not suitable.

4. Set: Mainly stores unordered sets, unordered! exclude.

5. SortedSet: Mainly stores ordered sets. The add element instruction ZADD key score member [[score, member]...] of SortedSet will bind a value score for sorting to each added element member. , SortedSet will sort the elements according to the size of the score value. Here you can use createDate as score for sorting.

The instruction ZREVRANGE key start stop in SortedSet can return members in the specified range, which can be used for paging. The instruction ZREM key member in SortedSet can remove specified members according to the key, which can satisfy deletion requirements. As requested by the comments, SortedSet is the most suitable here (time complexity O(log(N))).

So, the data types that need to be used are SortSet and Hash. SortSet is used for paging sorting, and Hash is used to store specific key-value pair data. In the SortSet structure, the topicId of each topic is used as the key of the set, and the createDate and commentId of the comments associated with the topic are used as the score and member of the set respectively. The order of the commentId is arranged according to the size of the createDate.

When you need to query the comments on a certain page of a certain topic, you can use the topicId of the topic through the command zrevrange topicId (page-1)×10 (page-1)×10 perPage, so that you can find out a certain The commitId of all comments in chronological order on a page under the topic. page is the page number of the query page, and perPage is the number of items displayed on each page.

After finding the commentId of all comments, you can use these commentIds as keys to query the content corresponding to the comment in the Hash structure.

In this way, the two structures of SortSet and Hash are used to achieve the purpose of paging and sorting in Redis.

Of course, you can also directly use only the SrotedSet type instead of the Hash type, and store the comments directly in the member.

But why put comments and sorting into different types? The advantage is that you can set different sorting types for comments, such as positive and negative order by time, positive and negative order by likes, positive and negative order by number of views, etc. In this way, you only need to maintain different SrotedSet sortings, and there is no need to maintain the content of multiple sets of comments.

The above is the detailed content of How to do paging in redis. For more information, please follow other related articles on the PHP Chinese website!

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template