5M -> 50M keys on Redis
От: Antei США  
Дата: 08.03.21 00:15
Оценка:
Привет, Форум!

В проекте планируется использовать 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,
подскажите сколько партиций/шард нужно чтобы выдержать нагрузку?

Спасибо!
redis
Re: 5M -> 50M keys on Redis
От: Слава  
Дата: 08.03.21 07:24
Оценка: 2 (1)
Здравствуйте, Antei, Вы писали:

A>Привет, Форум!

A>Спасибо!

А вы не хотите ли взять ScyllaDB? У них и инструментарий для планирования нагрузок есть, и протокол имеется, совместимый с Redis.
Re: 5M -> 50M keys on Redis
От: scf  
Дата: 08.03.21 08:09
Оценка: 7 (1)
Здравствуйте, Antei, Вы писали:

A>У кого есть реальный опыт нагрузок с Redis,

A>подскажите сколько партиций/шард нужно чтобы выдержать нагрузку?

Про нагрузку не скажу, но знаю, что кластеризованный редис может терять данные, это написано в официальной документации.
Re: 5M -> 50M keys on Redis
От: Anton Batenev Россия https://github.com/abbat
Дата: 08.03.21 15:42
Оценка:
Здравствуйте, Antei, Вы писали:

A> 5780 read/sec


~5-6 vCPU

A> 57800 read/sec


~50-60 vCPU

A> подскажите сколько партиций/шард нужно чтобы выдержать нагрузку?


Нагрузку в общем-то выдержит один современный сервер. Дальше все зависит от твоих требований к отказоустойчивости, гео-распределенности, запасу прочности (нагрузка может быть неравномерной в течении суток) и т.д.
Re[2]: 5M -> 50M keys on Redis
От: L.K. Марс  
Дата: 08.03.21 15:58
Оценка:
A>> 5780 read/sec
AB>~5-6 vCPU
A>> 57800 read/sec
AB>~50-60 vCPU

Во-первых, редиска однопоточная. От 50 ядер мало что изменится (если конечно, не вешать на каждое ядро по slave-процессу).

Во-вторых, 50000 rps редиска легко выполнит на одном ядре. Так что нужно думать не о редиске, а о серверном приложении, обрабатывающем данные редиски.
Re: 5M -> 50M keys on Redis
От: Anton Batenev Россия https://github.com/abbat
Дата: 08.03.21 16:10
Оценка: +1
Здравствуйте, Antei, Вы писали:

A> — на каждый ключ будет приходить ~100 чтений в день: 50M * 100read/day = 5000M read/day = 57800 read/sec


Да, тут еще такой момент. Если твоя нагрузка зависит от поведения людей (которые ночью спят, а условно в 8 утра все разом могут начать использовать систему), то делить число запросов в сутки на число секунд в сутках будет не совсем корректно. Я бы использовал пропорцию 1M хитов в сутки ≈ 100 rps в пике.
Re[3]: 5M -> 50M keys on Redis
От: Anton Batenev Россия https://github.com/abbat
Дата: 08.03.21 16:20
Оценка:
Здравствуйте, L.K., Вы писали:

LK> Во-первых, редиска однопоточная. От 50 ядер мало что изменится (если конечно, не вешать на каждое ядро по slave-процессу).

LK> Во-вторых, 50000 rps редиска легко выполнит на одном ядре. Так что нужно думать не о редиске, а о серверном приложении, обрабатывающем данные редиски.

Да, согласен, не на ту чиселку разделил. Значения выше надо делить на 100 (т.е. 50krps ~ 60% ядра).
Re[2]: 5M -> 50M keys on Redis
От: Je suis Mamut  
Дата: 08.03.21 16:43
Оценка:
С>А вы не хотите ли взять ScyllaDB? У них и инструментарий для планирования нагрузок есть, и протокол имеется, совместимый с Redis.

Если не секрет, за что такая любовь к ScyllaDB?
Re[3]: 5M -> 50M keys on Redis
От: Слава  
Дата: 09.03.21 07:55
Оценка: 11 (2)
Здравствуйте, Je suis Mamut, Вы писали:

С>>А вы не хотите ли взять ScyllaDB? У них и инструментарий для планирования нагрузок есть, и протокол имеется, совместимый с Redis.


JSM>Если не секрет, за что такая любовь к ScyllaDB?


Это та же Кассандра, на которой работают очень многие высоконагруженные проекты. Только переписанная на С++, изначально асинхронная, да ещё и поверх проекта Seastar, который работает поверх DPDK. На все планете нет ничего бесплатного и сравнимого по производительности.

В рамках этого топика, возможно топикстартеру хватит и одной Сциллы на мощной машине, вместо кластера Redis, потому что Сцилла требует в разы меньше ресурсов при высокой нагрузке. Также, кластер Сциллы не станет терять данные — в отличие от кластера Redis.
Re[4]: 5M -> 50M keys on Redis
От: chaotic-kotik  
Дата: 09.03.21 08:40
Оценка:
Здравствуйте, Слава, Вы писали:

С>В рамках этого топика, возможно топикстартеру хватит и одной Сциллы на мощной машине, вместо кластера Redis, потому что Сцилла требует в разы меньше ресурсов при высокой нагрузке. Также, кластер Сциллы не станет терять данные — в отличие от кластера Redis.


ванильный редис вполне себе потянет эту нагрузку на одной машние (чуть больше 10МБ/с), тут больше одной машины нужно только для отказоустойчивости
Re[4]: 5M -> 50M keys on Redis
От: Je suis Mamut  
Дата: 09.03.21 10:42
Оценка: 7 (1)
JSM>>Если не секрет, за что такая любовь к ScyllaDB?
С>Это та же Кассандра, на которой работают очень многие высоконагруженные проекты. Только переписанная на С++, изначально асинхронная, да ещё и поверх проекта Seastar, который работает поверх DPDK. На все планете нет ничего бесплатного и сравнимого по производительности.

не, я в общих чертах читал, но руками никогда не трогал

The only safe use of these 2 software is basically: 1) add new unique rows (no updates) 2) much later (granted only after repairs, which take a real lot) you can read, but only up to a certain time in the past. 3) basically almost avoid deleting. Compared to SQL, it feels worse than navigating blind on a minefield of special cases.

We found seven issues in Scylla 4.2-rc3. LWT updates could return UnavailableException for writes which actually committed. Batch updates could fail to return results for freshly inserted rows. Non-LWT updates claimed to be isolated, but were not. With LWT, healthy clusters exhibited stale reads and split-brain scenarios in which values fluctuated between multiple apparent timelines. Membership changes could also induce split-brain behavior in LWT operations for a variety of reasons.

ну и если я правильно помню, оно еще и место жрет как не в себя

безусловно, хорошо что ScyllaDB есть — они взялись за сложную задачу которая очень нужна, и jepsen очень суровый тест, который почти все остальные тоже проваливают, но разве ее стоит брать для решения любых проблем кроме "захлебываемся от количества insert-ов, остальное пофиг?"

я правда не знаю, потому и спрашиваю
Re[4]: 5M -> 50M keys on Redis
От: AndrewJD США  
Дата: 09.03.21 19:09
Оценка:
Здравствуйте, Слава, Вы писали:

С>На все планете нет ничего бесплатного и сравнимого по производительности.


Так она и не бесплатная.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.