Рационально ли использовать Redis в данном случае?

Question

[SET1]

Имеется шард серверов MySQL, и каждый сервер хранит 200 000 пользователей, которые стабильно ~15 раз в день обращаются к данным своего профиля в один из серверов простым SELECT. Рационально ли использовать Redis или можно ограничиться вертикальным масштабированием? Мне кажется логичным сначала использовать вертикальное масштабирование, а затем, если потребуется, подключать уже Redis.

Answer 1

[ThunderCat]

Из вопроса делаем вывод что а) данных не много б) они уникальны для пользователя в) запрос простой.
200 000 * 15 = 3 000 000 000 запросов в день, учтем что подразумевается скорее всего рабочий день, пусть 8 часов, и нагрузка распределена примерно равномерно. 3М/8/60/60 = 104 запроса в секунду, пусть в пике загрузки это будет 300-400 запросов.
Думаю пока вам хватит даже без масштабирования ресурсов, в дальнейшем при необходимости можно ввести кеширование, правда я не уверен что оно даст большой прирост, так как:
1) Данные должны быть горячие, то есть кеш на такие данные должен быть короткий, а одинаковые запросы скорее всего сильно разнесены по времени, по этому кеш будет вечно протухшим.
2) Данные на "узкие" запросы вообще плохо кешируются, так как содержат не массив выборки, а 1 строку, то есть получается много мелких данных вместо 20-30 списков на много строк.

Comments

[SET1]

Не уверен, что стоит задавать такой вопрос в комментариях, поэтому извините. Если на этих серверах хранится информация не о профилях, а о контенте, который относится к конкретному пользователю? Для каждого пользователя может быть 1 запись, а может быть и миллион записей, при этом их могут запрашивать по 100-200 раз в секунду. Не за раз, а используя пейджинг. Как быть в этом случае?

[ThunderCat]

SET1, тогда кеш будет вполне неплохим решением, естественно, вопрос только в имени ключа, который должен быть уникальным для каждого набора данных, то есть строиться из параметров (например юзер_ид + пэйдж).

[ThunderCat]

SET1, И еще - учитывайте что при изменении этих данных пользователем кеш нужно удалять, чтобы не получить дисконсистентность данных.

[SET1]

ThunderCat, Мне бы не хотелось использовать кеш, поскольку это усложняет систему, а как известно - чем система проще, тем она стабильнее работает. Мне кажется стоит остановиться на вертикальном масштабировании с использованием реплик чтения и настройкой query cache. Да, это затронет финансовый вопрос, однако это сделает систему проще. В любом случае - благодарю за Ваш ответ. Однозначно отмечаю его как решение.

[ThunderCat]

SET1, кеширование - простой и достаточно надежный способ быстрого поднятия производительности. Рано или поздно вы упретесь в потолок производительности на голом кластере, по этому кеширования в принципе избежать сложно, да и не нужно.

поскольку это усложняет систему, а как известно - чем система проще, тем она стабильнее работает.

В целом верно, но нельзя опускаться до уровня гуано и ветвей, кеш уже давно не рокет сайнс.

Я бы на вашем месте СЕЙЧАС вводил, чтобы потом, при поднятии нагрузки у вас не резко встал вопрос "что делать и куда бежать, все пропало!", а плавно вводилось кеширование в узких местах. Реально это 4-5 строчек на все места использующие кеш. По профилированию можно отдельный топик завести.