Comments 19
А не пробовали Dragonfly https://github.com/dragonflydb/dragonfly ? По их тестам он еще быстрее, чем KeyDB, при этом тоже совместимое API
У меня на домашнем компьютере dragonfly в 2 раза медленнее чем redis и в 1.8 раза медленнее чем keyDB. Тестил на set, get, rpush, lrange без pipe. Запускал через докер.
upd. на всякий случай сбилдил, всё равно медленно.
Про совместимость API:
> Из возможностей, доступных в первом выпуске DragonFly отмечается поддержка протокола RESP2 и 130 команд Redis, что примерно соответствует функциональности выпуска Redis 2.8
Это было полгода назад. Разработчики постепенно добавляют поддержку команд из более новых версий Redis, но о полной совместимости говорить рано.
Про быстродействие:
По бенчмаркам команды Redis (ниже приводил ссылку на офсайт), они быстрее чем DragonFly. При этом они конечно запускали не один инстанс Redis на многопоточном процессоре, а несколько.
А вот еще одно небольшое сравнение redis vs keyDB, и тут тоже не вышло превосходства keyDB в 5-25х маркетинговых раз.
На всякий случай примечание для тех, кому это может быть важно: Dragonfly — это не Open Source, а BSL (Business Source License).
Ммм... А что за линии на графиках? Одна линия на один под редиски?
Распределение нагрузки выглядит как-то оч не оч. Шардинг по хешу ключа или по подстроке ключа в лоб?
Шардинг по хэшу ключа.
Из документации: The base algorithm used to map keys to hash slots is the following (read the next paragraph for the hash tag exception to this rule) HASH_SLOT = CRC16(key) mod 16384
На графиках видно 3 нагруженных мастера (один из них действительно чуть менее нагружен, чем два других) и 6 почти бездействующих реплик.
Шардинг по хэшу ключа позволяет как-то более или менее равномерно распределить ключи между шардами - количественно, но не частоту обращений к ним.
Вероятно есть какие-то ключи, которые заметно более популярны, чем какие-то другие. Или значения ключей заметно большего размера.
Можно пораспределять слоты между шардами (мастерами), как-то их подвигать, чтобы выровнять нагрузку на мастеры. Но я большого смысла не вижу, будут другие ключи - и картинка поменяется.
Коллеги, а в каких сетапах тестировали KeyDB? Мы пробовали внедрить Active-Active, но кластер разваливался даже на Stage под E2E тестами. Такое чувство, что multi-master, который заявлен как одна из фич keyDB, просто не работает.
В статье вижу, что просто заменили Redis на KeyDB в готовом Redis Cluster. Соответственно, как я понимаю, модель записи и работы с Shard у вас не поменялась.
В описанном в статье кейсе в итоге остался Redis Custer ( шарды + реплики), keydb задействовали чтобы выйти за лимит в 1 ядро без перешардирования.
Из документации я так и не понял, как для Keydb Cluster включить active-active (хотя очень хотелось, что-то подобное). Казалось бы, что каждый шард - это мастер с набором реплик, почему бы нет. Но нигде не описано, что такая конфигурация возможна, разе что взять и попробовать.
Вообще, так как из редиса идет в основном чтение, можно на клиенте включать READONLY для запросов чтения. Тогда можно будет читать в том числе из реплик, и таким образом снизить нагрузку на мастеры. Но это нужно дорабатывать приложения, работающие с redis. А режим active-active решил бы эту проблему прозрачно для приложения. Но увы...
Ясно. Жаль что не пробовали. У нас не взлетело.
Так, в итоге, я так понял, не стоит Redis не стоит менять на Keydb пока.
Зависит от ситуации наверное.
Если вы упираетесь в одно ядро на существующем редисе и при этом не хотите особо заморачиваться с шардированием редиса в несколько инстансов по разным ядрам - можно просто запустить бинарь keydb-server вместо redis-server на той же конфигурации, и доутилизировать другие ядра (если они есть конечно)
Остальное конечно требует исследований, однозначных ответов "кто лучше" конечно не существует.
какую версию keydb использовали? Для 6.3.1 уже больше месяца висит issue, о проблемах с производительностью
Почему нельзя запустить столько redis, сколько ядер на сервере? Ключи растекаться на каждый из них, нагрузка выровняется и все будет хорошо, в теории. Интересно мнение практиков.
можно, более того, именно это и советуют на официальном сайте Redis, в ответ на критику со стороны разработчиков многопоточных форков. И в ответ приводят бенчмарки, в которых видно что правильно приготовленный Redis даже быстрее конкурентов
См. тут https://redis.com/blog/redis-architecture-13-years-later/
На практике деплоить и менеджить такой кластер сильно сложнее. Плюс если требуется таки какая-то надежность с репликами, то начинается гемор с распределением реплик правильным. Все таки сильно проще поднять один сервис и наблюдать, как он забирает все ресурсы из коробки.
"В одном из клиентских проектов" - этот проект случайно не состоит из двух слов на "Л" и "О"?
Наша новая удачная попытка бесшовной замены Redis на KeyDB