Redis 8.6 — x5 throughput это реально или маркетинг?

[cordoba]

Redis выкатили 8.6 с заявлениями про x5 throughput против Redis 7.2 и 3.5 млн ops/sec с пайплайнингом. Звучит как маркетинговая цифра. Кто-нибудь проверял на реальной нагрузке, не в синтетическом бенчмарке? У нас Redis 7.2.6 на выделенном сервере (32 cores, 128 GB RAM), используем как кэш и для rate limiting, пиковая нагрузка ~400k ops/sec. Стоит ли обновляться и чего реально ожидать?

[torchchan]

Проверял на стенде, могу поделиться цифрами. Конфигурация: Redis 7.2.6 vs 8.4 (до 8.6 ещё не добрался), сервер 16 cores, тест через redis-benchmark -c 200 -n 5000000 -t get,set.

Redis 7.2: GET ~380k ops/sec, SET ~290k ops/sec
Redis 8.4: GET ~680k ops/sec, SET ~510k ops/sec

Прирост реальный, около x1.8 в моём тесте. До x5 далеко, но это синтетика с пайплайнингом на идеальных условиях. В реальной нагрузке с разнообразными командами и сетевыми задержками — думаю x1.5-2 это честная оценка. Для 400k ops/sec на 32 cores у вас огромный запас.

[gdgdgd]

@cordoba, x5 достигается с пайплайнингом включённым и на конкретных командах (GET/SET строк). В Redis 8 добавили нормальный I/O threading — теперь чтение сокетов и парсинг команд вынесены в отдельные потоки, основной event loop разгружен. Это действительно серьёзное архитектурное изменение которого ждали много лет. Но если у вас команды типа ZADD/ZRANGE или Lua скрипты — прирост будет меньше.

По latency: p50 и p99 заметно улучшились. На sorted set командах p99 снизился на 35% в 8.6 против 8.4. Это важнее throughput для большинства приложений.

[clickhouseops]

Главная фича Redis 8 которую все забывают упомянуть: модули теперь встроены в ядро. RedisJSON, RediSearch, RedisTimeSeries, RedisBloom — больше не нужно грузить отдельно. Это упрощает деплой и означает что они теперь official supported часть Redis. Если вы используете JSON тип данных или full-text поиск через Redis — обновление само по себе оправдано.

[bunnerd]

Для вашей нагрузки (400k ops/sec на 32 cores) — вы даже на Redis 7.2 не упираетесь в потолок. Основной аргумент для обновления не throughput, а latency stability. Redis 7.2 при RDB snapshot или AOF rewrite иногда давал спайки latency. Redis 8 с улучшенным replication буфером (пиковый буфер на 35% меньше) и оптимизированным snapshot стал стабильнее. Меньше спайков = лучше p99 в проде.

[qcdeed]

Миграция с 7.2 на 8.x — относительно безболезненная. Формат RDB совместим, основные breaking changes касались некоторых конфигурационных параметров которые переименовали. Проверьте через redis-check-rdb ваш дамп перед миграцией и прочитайте migration guide — там минут 20 работы. Мы переехали через replica promotion: подняли реплику на 8.x, убедились что данные нормальные, сделали failover. Даунтайм — несколько секунд.

[torch2]

переезжали с 7.2.6 на 8.2 в проде в марте, нагрузка смешанная (хэши, sorted sets, немного lua). по цифрам: ops подросли процентов на 30, p99 с 2.1ms упал до 1.4ms. никаких x5 конечно. x5 редис рисует на чистых GET с -P 16 и io-threads по числу ядер, это витринный режим. но честно скажу, даже ради p99 обновиться стоило, спайки при AOF rewrite реально ушли.

[ninja_anton]

@torchchan, а io-threads сколько стояло? без io-threads 8 в конфиге половина профита восьмерки не раскрывается, основной event loop так и остается узким местом. и в redis-benchmark ты -P не указал, значит без пайплайна гонял, а заявленные 3.5 млн это именно с -P 16. так что твои x1.8 это скорее нижняя граница, а не повод для скепсиса.

[archmaster]

@clickhouseops, модули в ядре это удобно, только все молчат что редис с 8.0 целиком под AGPLv3. для обычного бэкенда пофиг, а если вы вендор и шипите редис внутри коробочного продукта, юристы вам устроят веселую неделю. у нас ровно из-за этого один продукт уехал на valkey и там остался. так что оправдано, но с оговорками.

[fletchl]

кто-нибудь 8.6 именно в кластере в прод катал? интересует failover, про 8.0-8.2 писали что были косяки при выборах мастера под нагрузкой. на синглах у всех все красиво, понятно.