redis - Is it possible to implement the login function purely using reids?

Question

Consider whether it is feasible to store user data completely in redis instead of using a SQL-like database.

The first trouble is how to retrieve when the user inputs the username and password.
It is absolutely impossible to use the keys command, it is terrible.

The envisaged structure is as follows:

每一个用户数据存储为一个hash类型：
key    user:info:unique-identification（int or uuid）
    hash-key-email:        hash-value-email
    hash-key-cellphone:    hash-value-cellphone
    hash-key-password:     hash-value-password
    hash-key-nickname:     hash-value-nickname
    hask-key-right01:      hash-value-right01
    ……

用hash类型存储email=>unique-identification检索数据
key    email:index
    hash-key-valueOfEmial:        hash-value-unique-identification

用hash类型存储cellphone=>unique-identification检索数据
key    cellphone:index
    hash-key-valueOfCellphone:        hash-value-unique-identification

1. Determine whether the user inputs email or cellphone

2. Use the hget command to obtain the corresponding unique-identification from the corresponding data

3. If hget obtains data, use user:unique-identification as key to obtain user data

4. Compare the password, if the verification is consistent, create the corresponding session and cookies, and the login is completed.

Consider the problems you will encounter:
The response time of hget is acceptable. This is much faster than the keys command for retrieval. We have not yet considered whether LUA can be used to complete login verification with one access.
However, data storage has become another problem that is difficult to solve. If there are 3 million users, just one email=>unique-identification retrieval data will be about 300M. If there are 10 million users, two searches will be about 2G. Data.

I would like to ask if there is a more reasonable structure to solve this problem. Looking forward to expert advice.

Answer 1

Personally, I think it is definitely unreasonable to use redis for storage, but it is feasible.