Answer the question
In order to leave comments, you need to log in
Is it rational to use Redis in this case?
There is a shard of MySQL servers, and each server stores 200,000 users who consistently access their profile data in one of the servers ~15 times a day with a simple SELECT. Is it rational to use Redis or can we limit ourselves to vertical scaling? It seems logical to me to first use vertical scaling, and then, if necessary, connect Redis.
Answer the question
In order to leave comments, you need to log in
From the question we conclude that a) there is not much data b) they are unique for the user c) the request is simple.
200,000 * 15 = 3,000,000,000 requests per day, let's take into account that it is most likely a working day, let's say 8 hours, and the load is distributed approximately evenly. 3M/8/60/60 = 104 requests per second, let it be 300-400 requests at peak load.
I think for now you will have enough even without scaling resources, in the future, if necessary, you can introduce caching, although I'm not sure that it will give a big increase, because:
1) The data must be hot, that is, the cache for such data must be short, and the same requests most likely greatly separated in time, so the cache will be forever rotten.
2) Data for "narrow" queries are generally poorly cached, since they contain not an array of selections, but 1 row, that is, a lot of small data is obtained instead of 20-30 lists for many lines.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question