Comments 29
"работает исключительно в памяти. В отличие от традиционных баз данных, которые хранят данные на диске"... диск по вашей логике это не память?
По всей общепринятой логике и терминологии память это именно оперативка. Диск это накопитель.
По общепринятой логике и терминологии есть энергонезависимая память и энергозависимая. И если оба типа памяти упоминаются рядом, то стоит уточнять. Хотя когда многие ещё и SSD называют диском, то ничего удивительного, что оперативку называют просто памятью.
Увы, есть те, кто постоянно сдвигает терминологию.
Вот я зашёл например на price.ru в раздел смартфонов. Есть "встроенная память" и есть "оперативная память". "Встроенная" это как раз накопитель-диск, постоянная память (ну да, на каком-то флэше и может быть даже продвинутый до уровня SSD).
Так что на сейчас я оцениваю вопрос вашего оппонента как придирку, но не без оснований.
Откройте окно, душно
Можно добавить, что "традиционная база" вполне себе может быть развернута на условном tmpfs (in memory).
Это конечно далеко не основной сценарий использования (для тестов гуд), но такая возможность есть, т.е. они тоже могут работать "исключительно в памяти"
Преимущества - отсутствие блокировок. Недостатки - блокировка операция.
Я понимаю, что речь идет о разных объектах для блокирования, но все таки....
У меня только вопрос, по какой причине это может не понимать пользователь Redis, или тот, кто выбирает его из альтернатив? Это как бы такая, самая базовая база.
Ну скорее всего статья рассчитана для новичков.
А те кто вообще не знает про redis, новички которые только изучают что либо и так далее? Или все рождаются по дефолту с базой по redis? :)
Верно подмечено про базу. Дополнил перевод картинками для улучшения восприятия материала про озвученную базу Redis.
Хорошо бы дополнить статью, что сейчас есть ей достойные альтернативы.
Хорошая идея. Какие на ваш взгляд и почему? На летнем HighLoad++ они упоминались. Не увидел точь-в-точь замены для бесшовного переезда. Везде какие-то нюансы.
Сложность поиска будет не o(1), скорее о(n), или если с индексами/отсортирован то o(log n). По памяти поиск займет о(1)
redis не работает быстро, и его однопоточность это беда, а не достоинство.
До 100 тыс запросов
Только вот проблема, в том, сколько приложение на 1 запрос делает запросов к redis. Да, можно решить проблему подняв кластер, но опять же - это убивает всю простоту его использования.
Да, и как вспомню, там уже пошла попытка сделать его проприетарным
Из аналогов, получше выглядит dragonfly, а keydb в последних версиях вообще поломан...
Режим sentinel и шардирование спасет. Но ванильный sentinel ужасен. И есть его форк valkey - свободен и быстрее.
Не спасёт. Например, мне надо что-бы было вот так и за мало денег, и с обращением к одному серверу:
# time memtier_benchmark -s testhost -p6379 -Predis -c 10 -t 100 -n 100000 --ratio 1:2 --data-size-pattern=S --key-minimum=10000000 --key-maximum=1000000000 --key-pattern=G:G --key-stddev=100000 --key-median=900000000 --hide-histogram -x 1 --distinct-client-seed
Writing results to stdout
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
[RUN #1 100%, 40 secs] 0 threads: 100000000 ops, 2749168 (avg: 2471008) ops/sec, 203.62MB/sec (avg: 183.02MB/sec), 0.37 (avg: 0.40) msec latency
100 Threads
10 Connections per thread
100000 Requests per client
ALL STATS
============================================================================================================================
Type Ops/sec Hits/sec Misses/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
----------------------------------------------------------------------------------------------------------------------------
Sets 945987.37 --- --- 0.40542 0.17500 6.17500 18.55900 74829.08
Gets 1891917.98 1891624.65 293.33 0.40421 0.17500 6.17500 18.55900 140406.05
Waits 0.00 --- --- --- --- --- --- ---
Totals 2837905.35 1891624.65 293.33 0.40461 0.17500 6.17500 18.55900 215235.13
real 1m0.451s
user 6m10.112s
sys 33m27.304s
# time memtier_benchmark -s testhost -p6379 -Predis -c 10 -t 100 -n 1000000 --ratio 1:2 --data-size-pattern=S --key-minimum=10000000 --key-maximum=1000000000 --key-pattern=G:G --key-stddev=100000 --key-median=900000000 --hide-histogram -x 1 --distinct-client-seed --pipeline=64
Writing results to stdout
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
[RUN #1 100%, 13 secs] 0 threads: 1000000000 ops, 85802627 (avg: 71912335) ops/sec, 6.21GB/sec (avg: 5.20GB/sec), 0.73 (avg: 0.88) msec latency
100 Threads
10 Connections per thread
1000000 Requests per client
ALL STATS
============================================================================================================================
Type Ops/sec Hits/sec Misses/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
----------------------------------------------------------------------------------------------------------------------------
Sets 27150918.62 --- --- 0.87741 0.38300 11.26300 32.76700 2147680.09
Gets 54301674.34 54270844.21 30830.13 0.87712 0.38300 11.26300 32.76700 4029178.74
Waits 0.00 --- --- --- --- --- --- ---
Totals 81452592.96 54270844.21 30830.13 0.87722 0.38300 11.26300 32.76700 6176858.82
real 0m36.307s
user 11m28.721s
sys 7m17.801s
Странно,что только в конце комментариев вспомнили про valkey. Он насколько я помню уже не однопоточный. Да и кому сейчас нужен редис с их новой лицензией.
100000 запросов в секунду это не так много для kv хранилища
быстро по сравнению с чем? 100000 операций kv это довольно скромно и узкое место здесь сеть, любая Map на уровне приложения была бы быстрее на 2 порядка минимум. Просто исторически redis появился давно, когда многопроцессорные серваки были дорогие и использовался как подпорка для php - python - ruby, в которых проблемно было сделать нормальную Map (желатильно off-heap). Даже удивительно что redis до сих пор популярен. 1 поток для обработки хорошо, когда он делает примитивную работу, как только ему придет "транзакция" на 20-30 шагов и таких транзакций будет много, то все ограничения такой реализации себя проявятся.
"Отсутствие переключения контекста " те системы, где невозможно создать больше одного потока на процесс любят повторять эту мантру, однако переключения контекста становятся проблемой когда у вас одно ядро и тысячи процессов. А если вы арендуете виртуалку с одним дохлым vcpu, то думаю от фактического переключения контекста вас ничего не спасет. Все это хорошо только когда у вас выделенный сервер, где вы жестко биндите конкретное ядро под конкретный поток-процесс и вы уверены, что можете загрузить это ядро на 100%. Во всех остальных случаев пул потоков будет лучше.
мне показалось, что эта статья - это несколько склеенных между собой ответов от LLM
Почему Redis работает так быстро, несмотря на то, что он однопоточный?