Redis, Mongo o Hazelcast?

Question

Tenemos una aplicación web JAVA que usa postgres (base de datos única con un esclavo) para almacenar todos los datos importantes.

Ahora estamos pasando de una configuración de servidor único a varios servidores, por lo que debo realizar algunos cambios para cumplir con los nuevos requisitos.

1) Identificadores de sesión no adhesivos para el equilibrio de carga y la tolerancia de partición.

2) Caché de datos de lectura frecuente accesibles desde todos los servidores web (en la alternativa Memoria/Memcache).

3) Colas (Correo electrónico, SMS, Tareas para ejecutar sobre el clúster). Por lo general, todos deben ejecutarse en una API xml o raspado de pantalla.
Evitar el procesamiento duplicado de tareas es importante, pero a veces puede suceder :-)

4) Almacenamiento persistente de solicitudes y respuestas API (muchos XML, muchas filas pero pocas columnas). (probablemente archivando eliminando solicitudes y respuestas antiguas para mantener el conjunto de datos pequeño).

5) Inicio de sesión en un lugar común. La mesa seguirá creciendo. También necesitaría una herramienta para acceder a los registros de producción sin detenerlos. Algún tipo de búsqueda debería ser posible en función del tiempo o la cadena de búsqueda.

Quiero una solución única para abordar todos estos requisitos y considerar redis, mongo y hazelcast (en orden de preferencia personal) como posibles alternativas.

Otras consideraciones importantes: 1) Menos intrusión en nuestro código. 2) Estrategias fáciles de copia de seguridad/replicación. Al menos Maestro Esclavo. 3) Manejabilidad, comunidad y probado (en producción).

¿Cuál podrá realizar todas o la mayoría de estas características y requisitos?

EDITAR - lo que hice

1. Redis gestor de sesiones respaldado por tomact.
2. Redis para almacenar en caché
3. Jesque (versión java de Respue) respaldada por redis.
4. Postgres
5. SLF4J respaldados por Log4j2

Answer 1

que pueden abordar algunos de estos desde la perspectiva de MongoDB.

Lo primero que noté es que está pasando de una configuración de servidor único a una configuración de servidor múltiple. MongoDB hace que sea increíblemente fácil configurar replicación y fragmentación. A su vez, la replicación y la fragmentación, junto con algunas de las otras funciones de Mongo, pueden ayudarlo a lograr mucho de lo que se propone hacer.

En primer lugar, echar un vistazo a la documentación de un poco para conseguir una sensación para ella:

Replica Sets y Sharding

Algunos otros pensamientos sobre la base de sus necesidades:

• En comparación con otros métodos de escalado con diferentes almacenes de datos El método de escala horizontal de mongo con hardware básico es muy simple de instalar, escalar y mantener. Esto significa que puede gastar más tiempo en crear su aplicación en lugar de ser un DBA.
• También puede saltear una capa de almacenamiento en caché si va con mongo. MongoDB utiliza archivos mapeados de memoria, lo que significa que si su conjunto de trabajo se puede mantener en la memoria física, básicamente ya tiene un caché en la memoria .
• MongoDB es muy bueno para iniciar sesión. Los usuarios generalmente no necesitan escrituras seguras para este tipo de aplicaciones, por lo que el rendimiento será excelente si se mantiene el modelo predeterminado de "olvidar y olvidar" para la escritura.
• Si esto significa que se inmiscuirá en su código, menos es discutible, sin embargo, en comparación con lo que hace un mapeador de relaciones de objeto típico, Mongo es mucho menos intrusivo para sus datos. ¡Es capaz de almacenar los datos en su estado natural utilizable, el objeto!

Hope that helps, cheers.

Answer 2

Yo diría que use sql. Ya que quiere todo lo que las bases de datos relacionales se han perfeccionado durante años. Por lo que veo, usted quiere una solución de datos no para fines "específicos" (eso es lo que intenta NOSQL cubrir) sino para el escenario "todo en uno". Para eso es SQL.

Mongodb sería el almacén de datos más cercano si desea elegir entre los 3 que está nombrando, pero de nuevo: use sql.

Answer 3

Tiene razón en que Redis resolverá los 3 primeros requisitos: sesiones no pegajosas, caché y colas.

En cuanto al registro centralizado, no es un caso de uso trivial, pero se puede hacer en Redis, aquí hay un blog post que explica cómo. Tenga en cuenta que el gurú de NoSQL Alex Popescu plantea algunas reservas sobre el enfoque en this post.

En cuanto a la persistencia, aquí está una descripción en Redis.io del persistence options - tiene algunos problemas pero es realizable.