ElasticSearch comme unique DB ou pas ?

Bonjour à tous !

Je suis en pleine phase de réflexion pour un nouveau projet et j'ai besoin de vos conseils pour le choix de mes solutions de stockages.

Pour remettre dans le contexte, je vais, en gros, développer un moteur de recherche de salle de sports avec des features "sociales" (les utilisateurs peuvent commenter/noter les salles etc...).

Après moultes recherche, je suis tombé sur ElasticSearch, une solution NoSQL de stockage de document, sans schéma et qui utilise une interface REST utilisant JSON sur HTTP. ElasticSearch est construit autours de Lucene, un moteur de recherche de texte.

ES semble plutôt adaptés à mon besoin : je stocke chaque salle de sport dans un index ES puis je fais mes recherches sur cet index.

MAIS !

J'ai besoin de stocker autre choses que des salles de sports. Par exemple, il faut que je puisse stocker mes utilisateurs ou encore les commentaires que chaque utilisateur met sur une salle (ça sent le relationnel ici ... ).

Donc je voulais savoir, est-ce une bonne idée de stocker TOUTES mes données dans des index ES et grâce aux filtres je récupère mes utilisateurs/commentaires "à la" SQL.
Ou alors, est-ce qu'il vaut mieux construire mon système de stockage autours d'une BDD SQL (MySQL) et en parallèle un index ES uniquement pour la recherche de salle de sport ?

Merci d'avance !
Pierre.

Salut,

Bonne question !
J'aurais tendance à conseiller deux systèmes de stockage, un primaire (relationnel ou non) et un secondaire basé sur ES.
ES sera un vue à part pour ton système qui ne se prêtera pas à une administration de gestion.
Considérer ES comme une vue te permettra de le reconstruire from scratch à chaque fois que ce sera nécessaire, notamment si tu changes de stratégie d'indexation (et ca arrivera certainement).
C'est la stratégie que j'utilise pour www.hopwork.com ou nous avons un MongoDb en stockage primaire et un ES en secondaire.

Bonjour,

Je me permet de remonter ce sujet (qui date un peu ^^) car j'ai une question liée.
Je part du principe que j'utilise deux systèmes de stockage (ES et MangoDB). Cependant j'ai tout de même une crainte :
Est ce que le fait de compresser la BDD MangoDB (WiredTiger avec une compression Snappy ou Zlib) posera problème à ElasticSearch pour indexer les données ?
En gros, est-ce que les requêtes et réponses seront lues sans problèmes ? Ou bien dois-je obligatoirement laisser la BDD telle quelle ?

Cette architecture n'est pas encore mise en place, c'est dans le cadre d'une étude.

Merci à vous

ES n'est absolument pas intéressé par la facon dont sont stockés les données internalement dans Mongo.
La réplication vers ES se se déroule avec un outil que ce soit logstash, flume, un outil maison etc... et même cet outil se moque de la méthode de stockage interne, il se repose sur un driver pour aller discuter avec Mongo.

Très bien merci pour cette réponse complète.
En effet je voulais parler de l'échange entre mongoDB et Graylog2 (et non ES).

je ne sais pas comment fonctionne Graylog2 mais j'imagine qu'il bosse comme les autres, il doit s'appuyer sur les oplog de Mongo pour répliquer l'info en temps réel vers son propre système.
Les oplogs ont un format qui ne change pas quelque soit le format interne utilisé pour stocker les données.
Donc ca ne changera rien pour Graylog non plus.