В проекте планируется использовать Redis для следующих данных:
изначально будет 5М ключ-значение
— ключ 20 байт
— значение 100-200байт (примем ключ+значение в среднем 200 байт)
— общий размер данных 5M * ~200байт = ~1Гб
— на каждый ключ будет приходить ~10 апдейтов в день: 5M * 10upd/day = 50M upd/day = 578 upd/sec
— на каждый ключ будет приходить ~100 чтений в день: 5M * 100read/day = 500M read/day = 5780 read/sec
Планируется рост до 50М ключей:
— общий размер данных 50M* ~200байт = ~10Гб
— на каждый ключ будет приходить ~10 апдейтов в день: 50M * 10upd/day = 500M upd/day = 5780 upd/sec
— на каждый ключ будет приходить ~100 чтений в день: 50M * 100read/day = 5000M read/day = 57800 read/sec
У кого есть реальный опыт нагрузок с Redis,
подскажите сколько партиций/шард нужно чтобы выдержать нагрузку?
~50-60 vCPU
A> подскажите сколько партиций/шард нужно чтобы выдержать нагрузку?
Нагрузку в общем-то выдержит один современный сервер. Дальше все зависит от твоих требований к отказоустойчивости, гео-распределенности, запасу прочности (нагрузка может быть неравномерной в течении суток) и т.д.
Здравствуйте, Antei, Вы писали:
A> — на каждый ключ будет приходить ~100 чтений в день: 50M * 100read/day = 5000M read/day = 57800 read/sec
Да, тут еще такой момент. Если твоя нагрузка зависит от поведения людей (которые ночью спят, а условно в 8 утра все разом могут начать использовать систему), то делить число запросов в сутки на число секунд в сутках будет не совсем корректно. Я бы использовал пропорцию 1M хитов в сутки ≈ 100 rps в пике.
Здравствуйте, L.K., Вы писали:
LK> Во-первых, редиска однопоточная. От 50 ядер мало что изменится (если конечно, не вешать на каждое ядро по slave-процессу). LK> Во-вторых, 50000 rps редиска легко выполнит на одном ядре. Так что нужно думать не о редиске, а о серверном приложении, обрабатывающем данные редиски.
Да, согласен, не на ту чиселку разделил. Значения выше надо делить на 100 (т.е. 50krps ~ 60% ядра).
Здравствуйте, Je suis Mamut, Вы писали:
С>>А вы не хотите ли взять ScyllaDB? У них и инструментарий для планирования нагрузок есть, и протокол имеется, совместимый с Redis.
JSM>Если не секрет, за что такая любовь к ScyllaDB?
Это та же Кассандра, на которой работают очень многие высоконагруженные проекты. Только переписанная на С++, изначально асинхронная, да ещё и поверх проекта Seastar, который работает поверх DPDK. На все планете нет ничего бесплатного и сравнимого по производительности.
В рамках этого топика, возможно топикстартеру хватит и одной Сциллы на мощной машине, вместо кластера Redis, потому что Сцилла требует в разы меньше ресурсов при высокой нагрузке. Также, кластер Сциллы не станет терять данные — в отличие от кластера Redis.
Здравствуйте, Слава, Вы писали:
С>В рамках этого топика, возможно топикстартеру хватит и одной Сциллы на мощной машине, вместо кластера Redis, потому что Сцилла требует в разы меньше ресурсов при высокой нагрузке. Также, кластер Сциллы не станет терять данные — в отличие от кластера Redis.
ванильный редис вполне себе потянет эту нагрузку на одной машние (чуть больше 10МБ/с), тут больше одной машины нужно только для отказоустойчивости
JSM>>Если не секрет, за что такая любовь к ScyllaDB? С>Это та же Кассандра, на которой работают очень многие высоконагруженные проекты. Только переписанная на С++, изначально асинхронная, да ещё и поверх проекта Seastar, который работает поверх DPDK. На все планете нет ничего бесплатного и сравнимого по производительности.
не, я в общих чертах читал, но руками никогда не трогал
ну и если я правильно помню, оно еще и место жрет как не в себя
безусловно, хорошо что ScyllaDB есть — они взялись за сложную задачу которая очень нужна, и jepsen очень суровый тест, который почти все остальные тоже проваливают, но разве ее стоит брать для решения любых проблем кроме "захлебываемся от количества insert-ов, остальное пофиг?"