For a website with 6 million users, a user may generate up to 30 points increases per day, such as 1, 2, 5. It can also generate several points expenditures, such as -50, -100.
Is there any good solution to store these user change details? Mysql does not seem to be a good solution because the amount of data is too large.
For a website with 6 million users, a user may generate up to 30 points increases per day, such as 1, 2, 5. It can also generate several points expenditures, such as -50, -100.
Is there any good solution to store these user change details? Mysql does not seem to be a good solution because the amount of data is too large.
Let me calculate for the questioner. Assuming that all users are active and all have 30 points added every day, then the number of requests per second is calculated as follows:
<code>600w * 30 = 18000w 18000w / 86400秒 = 2083条/秒</code>
As far as I know, with this amount of requests, MySQL
can completely handle it, but you must index the user ID.
In fact, it is definitely impossible to have so many requests online. A website with a 6 million user level will not have too many active users, and it is impossible for each user to add 30 requests every day. The volume here will be higher than expected here. The estimate is much less (estimated to be more than half).
Therefore, it is recommended that the subject analyze the data carefully first, and do not slap your head and do it premature optimization
.
If the subject wants to know the performance of MySQL
, here is an official page for reference: https://dev.mysql.com/tech-resources/articles/mysql-5.6.html
The author can consider using redis to store user points, then count the points every day and store them in MySQL
Part of it depends on which tools the DBA team is proficient in. If there is a problem with the storage application, it must be able to recover quickly. If the team mainly uses mysql, then you still need to take the test to use mysql first.