web-dev-qa-db-fra.com

MongoDB + Elasticsearch ou seulement Elasticsearch?

Nous avons là un nouveau projet pour indexer une grande quantité de données et pour fournir en temps réel. J'ai aussi une recherche complexe avec des facettes, du texte intégral, géospatial ...

Le premier prototype consiste à indexer dans MongoDB et ensuite à Elasticsearch, car j'avais lu qu'Elasticsearch n'applique pas de somme de contrôle aux fichiers stockés et que l'index ne peut pas être entièrement fiable. Mais depuis les dernières versions (dans la version 1.5), il y a maintenant une somme de contrôle et je suppose que nous pouvons utiliser Elasticsearch comme magasin de données principal? Et quel est l'avantage d'utiliser MongoDB en plus d'Elasticsearch?

Je ne trouve pas de réponse à jour sur ces fonctionnalités dans Elasticsearch

Merci beaucoup

mongodbelasticsearchnosql
33
user1853777

Parler des arguments pour utiliser Mongo au lieu de/avec ES:

  1. Gestion des utilisateurs/rôles.

    • Intégré dans MongoDB. Peut ne pas répondre à tous vos besoins, peut être maladroit quelque part, mais il existe et il a été mis en œuvre il y a assez longtemps.
    • La seule chose pour la sécurité dans ES est shield . Mais il n'est expédié que pour un abonnement Gold/Platinum à des fins de production.

  2. Schéma

    • ES est sans schéma, mais il est construit au-dessus de Lucene et écrit en Java. L'idée de base de cet outil - indexer et rechercher des documents, et travailler de cette façon nécessite la cohérence de l'index. À l'arrière-plan, tous les documents doivent être ajustés dans un index plat lucene, ce qui nécessite une certaine compréhension de la façon dont ES doit traiter vos valeurs et documents imbriqués, et comment vous devez organiser vos index pour maintenir l'équilibre entre la vitesse et l'exhaustivité des données. /cohérence. Travailler avec ES vous oblige à garder constamment à l'esprit certaines choses sur le schéma. C'est-à-dire: comme vous pouvez indexer presque n'importe quoi sur ES sans mettre à l'avance le mappage correspondant, ES peut "deviner" le mappage à la volée mais parfois le faire mal et parfois le mappage implicite est mauvais, car une fois qu'il est mis, il ne peut pas être changé w/o réindexation de tout l'indice. Donc, il vaut mieux ne pas traiter ES comme un magasin sans schéma, car vous pouvez marcher sur un râteau un certain temps (et ce sera douleur :)), mais Traitez-le plutôt comme un schéma intensif, au moins lorsque vous travaillez avec des documents, qui peut être découpé en champs concrets.
    • Mongo, d'autre part, peut "mâcher et ne laisser aucune miette" de presque tout ce que vous y mettez. Et la plupart de vos requêtes fonctionneront bien, `jusqu'à ce que vous vous souveniez comment Mongo traitera vos données du point de vue JavaScript. Et comme JS est faiblement typé, vous pouvez travailler avec un workflow vraiment sans schéma (bien sûr, si vous en avez besoin)

  3. Gestion des données non de type table.

    • ES est limité pour gérer les données sans les mettre dans l'index de recherche. Et cette solution est assez bonne, lorsque vous devez stocker et récupérer des données supplémentaires (en les comparant aux données que vous souhaitez rechercher).
    • MongoDB prend en charge gridFS . Cela vous permet de gérer de gros morceaux de données derrière la même interface. C'est-à-dire que vous pouvez stocker des données binaires dans Mongo et les récupérer dans la même interface, du point de vue de votre code.
46
Slam

Eh bien, choisissez le bon outil pour le bon travail. Si vous avez besoin de capacités de recherche telles que la recherche en texte intégral, les facettes, etc., rien ne peut battre un moteur de recherche à part entière. ElasticSearch (ES) ou Solr n'est qu'une question de choix.

Vous pouvez réellement alimenter (indexer) des documents dans ES pour les rechercher, puis récupérer les détails complets d'une entrée particulière à partir de MongoDB ou de toute autre base de données.

Je peux vous faciliter la tâche, jetez un oeil à mon travail open source qui utilise MongoDB, ES, Redis et RabbitMQ, tous intégrés en un seul endroit, ici sur github

Veuillez noter que l'application est intégrée en .Net C #.

2
Amit Kr

J'ai récemment développé une fonctionnalité dans mon entreprise,

nous voulions effectuer quelques recherches et classer le résultat en fonction de sa pertinence sur plusieurs facteurs et conditions.

Donc, dans mon application, nous utilisions déjà MongoDB comme Db,

Donc, sur l'index ElasticSearch, j'ai exporté certains des champs de MongoDB sur lesquels je veux effectuer des recherches et des filtres. Donc, selon les conditions requises, j'ai également préparé ma requête mongo et ma requête elasticsearch et effectué la recherche. Ensuite, j'ai filtré et trié le résultat selon mes besoins. L'ensemble du testament a été conçu de telle manière que, même en cas d'erreur de ES, mongo récupère les enregistrements. Si j'obtiens le résultat d'ES alors, le résultat de mongo dépendra du résultat d'ES. C'est ainsi que j'ai utilisé mongo et ES en combinaison.

N'oubliez pas non plus de gérer correctement toutes les mises à jour, suppressions et nouvelles insertions d'enregistrements.

Et juste pour savoir, les résultats pour moi étaient vraiment bons.

0
niranjan harpale

Après avoir utilisé Elasticsearch sur la production, je peux ajouter à ce fil quelques notes:

  • Nous avons sécurisé notre cluster Elasticsearch via un proxy inverse qui vérifie l'authenticité du certificat client au moment de la demande avant de laisser la requête entrer: cela prouve qu'il existe de multiples façons d'ajouter l'authentification de toute façon. (Si vous avez besoin de plus de précision dans la sécurité, comme en utilisant des rôles, il y a peu de plugins qui peuvent être ajoutés pour gérer les autorisations)
  • La cartographie et les paramètres d'Elasticsearch (optimisation) sont des concepts vraiment importants à comprendre avant de commencer la production, et ce n'est pas si facile de savoir comment tout fonctionne rapidement.
  • Le clustering et la mise à l'échelle horizontale sont très flexibles et faciles à configurer
  • Les outils de la suite (Kibana, beats, etc.) sont un moyen très pratique de rassembler les journaux, d'exposer les données clés, etc ...
  • Les fonctionnalités de recherche sont extrêmement avancées, vous pouvez vraiment faire des choses incroyables lorsque vous maîtrisez un peu le fonctionnement de la recherche en texte intégral (flou, boost, scoring, stemming, tokenizer, analyseurs, etc.).
  • Les API sont un peu dispersées et il n'y a pas de moyens uniques pour réaliser quelque chose. Et certaines API sont vraiment WTF à utiliser, comme l'API d'insertion en bloc: vous devez transmettre des données binaires, au format JSON (bien sûr, n'oubliez pas les caractères de fin de ligne) et en répétant plusieurs champs plusieurs fois. C'est très verbeux et je suppose que c'est du code hérité comme nous l'avons tous dans nos projets;).
  • Dernière chose: si vous développez un projet Java, n'utilisez pas Hibernate Search pour dupliquer les données d'une source de données vers votre cluster ES, nous avions tellement de problèmes avec Hibernate Search, si nous devions le faire encore une fois, nous le ferions manuellement.

Maintenant sur la vraie question:

À mon avis, utiliser uniquement Elasticsearch est suffisant et peut réduire la complexité d'avoir plusieurs systèmes de stockage NoSQL.

Je pense que cela vaut la peine lorsque vous faites un duo de base de données relationnelle et transactionnelle + moteur de recherche NoSQL, mais avoir deux systèmes qui servent à peu près les mêmes fins est un peu trop qualifié

0
Alex