Redis key value design problem?

WBOY
Release: 2016-07-06 13:51:16
Original
950 people have browsed it

As a novice, I recently learned about Redis cache, and I have a question in my mind:
Suppose there is a user table in mysql to save user-related information. The main fields of the table are: id, username, password, email , nick, born, sex, status, etc. Now I want to cache all the data in the user data table into the redis database server. How should the key values ​​​​of redis be set?
is set to something like:

<code>user:[id]:username username_value
user:[id]:password password_value
user:[id]:email email_value
user:[id]:nick nick_value
...
</code>
Copy after login
Copy after login

Or should it be set in this form:

<code>user:[id] json_string
// json_string 是将一条用户信息的二维数组转换成json字符串
</code>
Copy after login
Copy after login

Which of these two forms is better? Which one saves more memory?
I hope you guys can answer my questions, and I’m very grateful for this =.=

Reply content:

As a novice, I recently learned about Redis cache, and I have a question in my mind:
Suppose there is a user table in mysql to save user-related information. The main fields of the table are: id, username, password, email , nick, born, sex, status, etc. Now I want to cache all the data in the user data table into the redis database server. How should the key values ​​​​of redis be set?
is set to something like:

<code>user:[id]:username username_value
user:[id]:password password_value
user:[id]:email email_value
user:[id]:nick nick_value
...
</code>
Copy after login
Copy after login

Or should it be set in this form:

<code>user:[id] json_string
// json_string 是将一条用户信息的二维数组转换成json字符串
</code>
Copy after login
Copy after login

Which of these two forms is better? Which one saves more memory?
I hope you guys can answer my questions, and I’m very grateful for this =.=

To store the hash, add a prefix to the user ID and set it as key. For example, user:888
The hash set stores commonly used user attributes.
In addition, it is not recommended for all users to store cache without thinking...This is a bit putting the cart before the horse. .mysql will look confused (what’s the use for me←_←)... You can try to create a simple hot user cache for hot statistics

If that doesn’t work, just set a timeout for the hash. Each user’s information will be saved for a period of time after logging in for the first time.... This will save you the trouble...

I have never studied the relationship between different data types and memory
From a business logic perspective, how to design storage depends on the needs
For example, caching is just for query convenience and information display, choose the second option, mysql Or mongodb has relevant operations and then updates the corresponding cache
If you need to assign login, data CURD and other logic, the same as above, it is recommended to use hash, such as HMSET, instead of String type

The first one is better, you can find a certain one without coding

Personally, I think the first method is better, which is convenient for individual acquisition and modification. If it is the latter, you have to get all of them every time you get or modify a single attribute, and parsing json to get other serialization and deserialization forms will bring additional consumption.
In most cases, the query does not need to query all fields. If it is modified, most of them only modify 1 field

I have also encountered the problem of data table caching. My solution is to use multiple data types to complete it

First, each data record is stored in a dictionary, encrypted with the table name ID and md5 as the name of the dictionary
Then use an ordered set to store the dictionary name and sorting weight of each record (I have sorting here) requirements, so use ordered sets, otherwise you can use sets or lists)

PS: Operations such as where queries cannot be performed in redis, so if necessary, you can filter at the code level and then save it into redis by category. For example, I filter the data and save it into several different categories. Sorted sets, and then maintain the names of these sorted sets into a list

The latter.
It is easy to operate and can avoid the bottomless pit phenomenon.

Bottomless cache phenomenon

Don’t use json. It seems convenient to get the value, but it is simply indescribable when the cached data is updated in multiple places at the same time. There is no convenience or inconvenience in writing a program, only what you write is unreliable.

There is no need to cache all of them. For example, gender does not need to be cached. Only those that are frequently accessed need to be cached.

How to use json under redis. . It’s not that it’s impossible, it’s just that the value of redis is not fully utilized. Just be happy

Use hash structure. The second option is recommended. The first meaning of data caching is to speed up browsing. For some data that will be modified, I usually build an extra cache to store the data to be modified. The actual displayed data will be the normal cache and modified cache. data.

The general industry practice is to
store values ​​in binary form instead of strings. This saves memory and is highly efficient. The disadvantage is that you cannot read the plain text through redis-cli because it is already in binary form.
For example, your
key=user:[id]
value=the binary form converted by this user object

Then next time you use java to read this value, it will automatically be converted to your object. It’s so simple. You don’t need to set attributes one by one

However, you should note that once it is involved like this, you will not be able to search through other attributes of the user. The premise is that you need to understand your business. If there are searches in other fields, you need to add a set of other key values. In nosql Data redundancy is common

NoSQL is like this. Those who write programs must understand the business, otherwise the data structure design will not be good. Although the usage threshold of NoSQL is very low, there is still a design threshold

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