Redis Vs Hazelcast Если мое приложение:
Мои вопросы - Какой из них между Redis и Hazelcast следует выбрать для хранения и запроса данных - что быстрее для чтения и записи? - какой из них более надежный? - Может ли Кассандра стать лучшим вариантом?
Ответ на любой из вопросов помогает
Мы перешли от redis к hazelcast для наших потребностей в кешировании.
Мы используем protostuff для сериализации beans, которые дорого создавать. Механизм стандартной сериализации Hazelcasts намного медленнее. Наша среда - Glassfish 3.1.
Hazelcast выглядит так, будто у них только java libs, у Redis есть один для каждого языка.
True. Hazelcast предоставляет только API REST и реализацию протокола memcached.
Существует очень удобный lib - Redisson. Он предоставляет распределенные Java-объекты и сервисы (BitSet, BloomFilter, Set, SortedSet, Map, ConcurrentMap, List, Queue, Deque, BlockingQueue, BlockingDeque, ReadWriteLock, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, RemoteService, ExecutorService, LiveObjectService, ScheduledExecutorService) поверх сервера Redis!
Он поддерживает режимы кластера, дозорного, ведущего/ведомого и одного подключения.
Прекрасно работает в облаке и поддерживает AWS Elasticache и Azure Redis Cloud
Ниже приведены некоторые истории успеха от клиентов Redisson:
Переход от Hazelcast к Redis
Распределенная блокировка с Redis (миграция из Hazelcast)
Начиная с 2017 года, как Redis, так и Hazelcast предлагают доступное\масштабируемое хранилище ключей\значение. С очень быстрым временем отклика < 10ms.
Redis уникален тем, что он поддерживает другие структуры данных, такие как загруженные наборы, хэш-множества и механизм pub\sub. Он также расширяется с помощью сценариев lua. Это, вероятно, самый популярный и широко используемый из двух продуктов. Особенно за пределами экосистемы Java.
Hazelcast уникален тем, что он может быть встроен в хост-процесс Java, что делает его отличным для создания микроконтроллеров с сохранением состояния без зависимости от внешней базы данных. Он также имеет некоторые другие небольшие различия, такие как возможность получить звонок от истечения срока действия ключа. В некотором смысле, он делает меньше всего, но немногие вещи он делает, он делает их лучше. Особенно, если вы используете Java.
В целом это аналогичные решения, предназначенные для подобных случаев использования, таких как кэширование внешних данных, создание объединительной платы связи или состояния общей памяти для микросервиса с сохранением состояния или, возможно, даже хранение (небольшие количества нереляционных) бизнес-данных с некоторой степенью долговечности.
Чтобы решить, какой из них является хорошим, существует проблема использования клиентского потока.
В соответствии с этим benchmark Hazelcast лучше, чем Redis, если вы используете больше потоков. Может быть, это нечестный ориентир компании, но показывает что-то о потоковом использовании.
Оба Redis и Hazelcast являются базами данных на основе памяти, поэтому теоретически они должны обеспечивать такую же скорость и производительность. Просмотрев документы для Hazelcast, вы получите лучшую поддержку с Redis из-за большого количества библиотек для взаимодействия с базой данных. Hazelcast выглядит так, что у них только java libs, у Redis есть один для каждого языка.
Ответы:
Вам придется протестировать это самостоятельно, насколько я могу сказать, разные сравнения показывают Redis как быстрее один из них здесь, но я не буду говорить, что эти тесты 100%
Они должны быть надежными, но я не могу ручаться за Hazelcast.
Может быть...
Я бы пошел с Redis, потому что считаю, что он наиболее удобен и имеет отличную документацию.