Redis, Mongo ou Hazelcast?

Nous avons une application Web JAVA qui utilise postgres (firebase database unique avec un esclave) pour stocker toutes les données importantes.

Nous passons maintenant d’une configuration de serveur unique à plusieurs serveurs, ce qui nécessite des modifications pour répondre aux nouvelles exigences.

1) Identifiants de session non collants pour l’équilibrage de la charge et la tolérance de partition.

2) Cache de données fréquemment lues accessibles depuis tous les serveurs Web (alternative In Memory / Memcache).

3) Files d’attente (Email, SMS, tâches à exécuter sur le cluster). Généralement, ils doivent tous être exécutés sur une API xml ou un grattage d’écran.
Éviter le traitement en double des tâches est important, mais cela peut parfois arriver 🙂

4) Stockage persistant des requêtes et réponses de l’API (beaucoup de XML, beaucoup de lignes mais peu de colonnes). (archivez probablement en supprimant les anciennes requêtes et réponses afin de conserver un dataset réduit).

5) Se connecter à un lieu commun. La table continuera à grossir. J’aurais aussi besoin d’un outil pour accéder aux journaux de production sans les arrêter. Une sorte de recherche devrait être possible en fonction du temps et / ou de la chaîne de recherche.

Je souhaite une solution unique pour répondre à toutes ces exigences et envisager Redis, Mongo et Hazelcast (par ordre de préférence) en tant que solutions de remplacement possibles.

Autres considérations importantes: 1) Moins d’intrusion dans notre code. 2) Stratégies simples de sauvegarde / réplication. Au moins, maître esclave. 3) Facilité de gestion, communauté et essayé et testé (en cours de production).

Qui sera capable de réaliser tout ou la plupart de ces fonctionnalités et exigences?

EDIT – Ce que j’ai fait

  1. Redis a pris en charge le gestionnaire de session pour tomact.
  2. Redis pour la mise en cache
  3. Jesque (version java de Respue) soutenu par redis.
  4. Postgres
  5. SLF4J soutenu par Log4j2

Je peux en aborder certaines du sharepoint vue de MongoDB.

La première chose que j’ai remarquée est que vous passez d’une configuration de serveur unique à une configuration de plusieurs serveurs. MongoDB facilite incroyablement l’installation de la réplication et du sharding. À leur tour, la réplication et le partage, ainsi que certaines autres fonctionnalités de Mongo, peuvent vous aider à atteindre vos objectives.

Tout d’abord, jetez un coup d’œil à la documentation pour vous en faire une idée:

Jeux de répliques et fragmentation

Quelques autres reflections basées sur vos besoins:

  • Comparée à d’autres méthodes de mise à l’échelle avec différents datastores, la méthode de mise à l’échelle horizontale de mongo avec du matériel standard est très simple à configurer, à mettre à l’échelle et à maintenir. Cela signifie que vous pouvez passer plus de temps à créer votre application au lieu d’être un administrateur de firebase database.
  • Vous pouvez également pouvoir ignorer une couche de mise en cache si vous utilisez mongo. MongoDB utilise des fichiers mappés en mémoire, ce qui signifie que si votre poste de travail peut être placé dans la mémoire physique, vous avez déjà un cache en mémoire.
  • MongoDB est très bon pour la journalisation. Les utilisateurs n’ont généralement pas besoin d’écritures sécurisées pour ce type d’application. Par conséquent, les performances seront excellentes si vous vous en tenez au modèle par défaut feu et oublie pour l’écriture.
  • Le fait de savoir si cela empêchera moins votre code d’entrer dans le code est sujet à discussion, mais comparé à ce qu’un mappeur de relations d’objects typique fait, Mongo est beaucoup moins intrusif pour vos données. Il est capable de stocker les données dans son état naturel utilisable, l’object!

J’espère que ça aide, acclamations.

Je dirais utiliser SQL. Puisque vous voulez tout ce que les bases de données relationnelles ont été perfectionnées pendant des années. Autant que je sache, vous souhaitez une solution de données non pas à des fins “spécifiques” (c’est ce que NOSQL essaie de couvrir), mais pour un scénario “tout-en-un”. Cest ce que SQL est pour.

Mongodb serait le magasin de données le plus proche si vous voulez choisir parmi les 3 que vous nommez, mais encore une fois: utilisez sql .

Vous avez raison de dire que Redis répondra aux 3 premières exigences: sessions non-collantes, cache et files d’attente.

En ce qui concerne la journalisation centralisée, ce n’est pas un cas d’utilisation sortingvial, mais peut être fait sur Redis, voici un article de blog qui explique comment. Notez que le gourou de NoSQL, Alex Popescu, émet des réserves sur l’approche proposée dans ce billet .

En ce qui concerne la persistance, voici un aperçu de Redis.io des options de persistance – présente quelques problèmes, mais est réalisable.