A lot of data volume of user points change details what is the good storage plan?

A user at level 6 million of the site, a user can produce up to 30 points per day increase, such as +1,+2,+5. You can also generate several points to spend, such as -50,-100.
Is there a good plan to store the user's details of these changes? MySQL doesn't seem like a good solution because the amount of data is too large.

Reply content:

A user at level 6 million of the site, a user can produce up to 30 points per day increase, such as +1,+2,+5. You can also generate several points to spend, such as -50,-100.
Is there a good plan to store the user's details of these changes? MySQL doesn't seem like a good solution because the amount of data is too large.

I calculate for the title, assuming that all users are active, and that all 30 points are added each day, the number of requests per second is calculated as follows:

600w * 30 = 18000w18000w / 86400秒 = 2083条/秒

As far as I know, the amount of this request is MySQL fully carried down, but you have to index the user ID.

In fact, there is no way that there are so many requests on the line, 600w user-level Web site, there are not too many active users, and it is not possible for each user to have 30 per day to increase, the volume here will be much less than estimated here (less than half).

So the main problem is to carefully analyze the data, do not shoot the head, engage premature optimization .

If the owner wants to know MySQL the performance, here is an official page for reference: https://dev.mysql.com/tech-resources/articles/mysql-5.6.html

The landlord may consider using Redis to store user points and then count the points every day and then save them to MySQL.

In part, depending on which tools the DBA team is proficient in, the application of the storage class is a problem and can be quickly restored. If the team is mainly using MySQL, then we still need to test the MySQL filter.

