redis vs hazelcast

(5)

A partir de 2017, tanto Redis como Hazelcast ofrecen almacenamiento de alta disponibilidad / clave escalable / valor. Con tiempos de respuesta muy rápidos <10ms.

Redis es único, ya que admite otras estructuras de datos como conjuntos almacenados, conjuntos de hash y un mecanismo de publicación / sub. También es extensible a través de scripts lua. Es probablemente el más popular y ampliamente utilizado de los dos productos. Especialmente fuera del ecosistema de Java.

Hazelcast es único en que se puede incrustar en un proceso de host Java, lo que lo hace ideal para crear microservicios con estado sin una dependencia de base de datos externa. También tiene algunas otras pequeñas diferencias, como la capacidad de obtener una devolución de llamada de una clave de caducidad. En cierto sentido, lo hace menos en general, pero las pocas cosas que hace, las hace mejor. Especialmente si estás utilizando Java.

En general, se trata de soluciones similares diseñadas para casos de uso similares, como el almacenamiento en caché de datos externos, la creación de un backplane de comunicación o el estado de la memoria compartida para un microservicio con estado, o posiblemente incluso el almacenamiento (pequeñas cantidades de datos comerciales no relacionales) con cierto grado de durabilidad.

Redis Vs Hazelcast Si mi aplicación:

Tengo muchas solicitudes de http (6.000 por minuto, recopilo información de clics) que se deben guardar.
Tiene muchas solicitudes http que consultan los datos previamente guardados.

Mis preguntas son: ¿Cuál entre Redis y Hazelcast debería elegir para almacenar y consultar datos? ¿Cuál es más rápido para leer y escribir? - ¿Cuál es más confiable? - ¿Podría Cassandra ser una mejor opción?

Responder a cualquiera de las preguntas ayuda.

Cambiamos de redis a hazelcast para nuestras necesidades de almacenamiento en caché.

Protostuff + Hazelcast es mucho más rápido para nosotros que
Protostuff + Jedis (agrupados) + Redis

Utilizamos protostuff para serializar beans que son caros de crear. El mecanismo de serialización estándar de Hazelcasts es mucho más lento. Nuestro entorno es Glassfish 3.1.

Hazelcast parece que solo tienen java libs, Redis tiene uno para cada idioma.

Cierto. Hazelcast proporciona solo una API REST y una implementación del protocolo memcached.

Para decidir cuál es el bueno, hay un problema sobre el uso del subproceso del cliente.

De acuerdo con este benchmark Hazelcast es mejor que Redis si usas más hilo. Tal vez este es un punto de referencia injusto de la empresa, pero muestra algo sobre el enhebrado.

Tanto Redis como Hazelcast son bases de datos basadas en memoria, por lo que, en teoría, deberían proporcionar la misma velocidad y rendimiento. Al revisar los documentos de Hazelcast, obtendrá un mejor soporte con Redis debido a la gran cantidad de bibliotecas para interactuar con la base de datos. Hazelcast parece que solo tienen java libs, Redis tiene uno para cada idioma.

Respuestas:

Tendrá que probar esto por su cuenta, por lo que puedo decir que las diferentes comparaciones muestran que Redis es más rápido que uno de ellos , pero no diré que estos puntos de referencia son del 100%.
Deben ser confiables, pero no puedo responder por Hazelcast.
Tal vez...

Me gustaría ir con Redis, porque me parece que es el más útil y tiene una gran documentación.

Hay una lib muy útil - Redisson . Proporciona objetos y servicios distribuidos de Java ( BitSet , BloomFilter , Set , SortedSet , Map , ConcurrentMap , List , Queue , Deque , BlockingQueue , BlockingDeque , ReadWriteLock , Semaphore , ExecutorService , LiveObjectService ScheduledExecutorService ) en la parte superior del servidor Redis!

Admite modos de conexión en clúster, centinela, maestro / esclavo y de conexión única.

Funciona perfectamente en la nube y admite AWS Elasticache y Azure Redis Cloud

A continuación hay algunas historias de éxito de los clientes de Redisson:

Pasando de Hazelcast a Redis
Bloqueo distribuido con Redis (Migración desde Hazelcast)