Why use redis to cache the latest N comments, only ID, does not save the comment content?

assume that the mysql database comment table has many fields, such as ID, time, content, commentator, and so on. When using redis cache, why does someone on the Internet say that just use the list data type to store ID? In that case, after getting the comment ID from redis, don"t you also have to go to the mysql table to query the specific content of each comment ID?

Mar.23,2022

there is no reason why the trade-off between memory space and response time is just you are willing to save the comment content
in this scenario redis is to exchange a space for time. If you do not want to use more space, it must be more efficient to save the whole content if you do not want to use more space.


in addition to space
assume that all fields are cached for the latest n comments, the hottest n comments and the most xxx n comments. If the content / sort value / status of a comment changes, all the caches need to be updated, so the general approach is to cache the entity content corresponding to id list, and id. In this way, we only need to update the record of the entity during the update operation to analyze the specific problem


. If you only save the latest five, if you don't insert a new one, you will delete the oldest one, and the overall occupation is small. Then you can save all the data.
but if you need to edit and block the comments, you should only store the ID.sql part and store it in redis by caching the query results


the question of the landlord, I also thought that list saving comments id can indeed reduce a mysql return table operation

Database Design field-"comment id ( primary key ) article id ( foreign key ) articles and comments are one-to-many relationships, so
you can know the comment id directly through the redis cache and then go directly to the database primary key index ( clustered index ) to get

.

but if you search through the article id, and the foreign key ( non-clustered index ) only stores the primary key id, of the current line, and then check the full content of the comment (back to the table)

however, the amount of data of goose comments is huge. The query efficiency of reducing the number of times to return to the table will double

.

the current practice of this kind of problem on our side.
in some performance-seeking scenarios, it is also a routine operation for us to directly cram the entire returned JSON into the Redis.
there is no saying that only ID exists.

have your own thinking and judgment.

Update at 2018.12.29:
take this question.
A. Redis when the database uses
B. Redis as the database data cache
C. Redis as the database data index ID cache
D. Redis does not need

I think this question is to discuss these uses (all of which can be used, of course).
as a result, the subject unexpectedly asked, why is it faster to use ID than to use conditions?
my God, ID, indexed with positive integer + primary key is no faster than using a bunch of criteria to find out. Why do you need ID?

Menu