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?