elasticsearch vs MongoDB pour l’application de filtrage

Cette question concerne le choix architectural avant de se pencher sur les détails de l’expérimentation et de la mise en œuvre. Il s’agit de l’adaptabilité, de l’évolutivité et des conditions de performance d’elasticsearch par rapport à MongoDB, dans un but quelque peu spécifique.

Hypothétiquement, stockez tous deux des objects de données dotés de champs et de valeurs, et autorisez l’interrogation de ce corps d’objects. Par conséquent, on peut supposer que filtrer les sous-ensembles des objects en fonction des champs sélectionnés au cas par cas est adapté aux deux.

Mon application tournera autour de la sélection des objects en fonction de critères. Il sélectionnerait les objects en les filtrant simultanément par plusieurs champs, autrement dit, ses critères de filtrage des requêtes comprendraient généralement entre 1 et 5 champs, voire plus dans certains cas. Alors que les champs choisis comme filtres seraient un sous-ensemble d’un nombre beaucoup plus grand de champs. Imaginez quelques 20 noms de champs existants, et chaque requête est une tentative de filtrer les objects par peu de champs parmi ces 20 champs globaux (il peut y avoir moins ou plus de 20 noms de champs globaux, j’ai juste utilisé ce nombre pour montrer le ratio de champs aux champs utilisés comme filtres dans chaque requête discrète). Le filtrage peut se faire par l’existence des champs choisis, ainsi que par les valeurs des champs, par exemple en filtrant les objects qui ont le champ A et leur champ B est compris entre x et y et leur champ C est égal à w.

Mon application effectuera ce type de filtrage en continu, alors qu’il n’y aura rien ou très peu de constantes en termes de champs utilisés pour le filtrage à tout moment. Peut-être dans les elasticsearch les index doivent-ils être définis, mais peut-être même sans index, la vitesse est au même niveau que celle de MongoDB.

En ce qui concerne les données entrant dans le magasin, il n’y a pas de détails particuliers à ce sujet. Les objects ne seraient presque jamais modifiés après avoir été insérés. Peut-être faudrait-il supprimer les anciens objects, je suppose que la prise en charge des deux magasins de données expire en supprimant des éléments en interne ou par une requête créée par une application. (Moins fréquemment, les objects qui correspondent à une requête spécifique doivent également être supprimés).

Qu’est-ce que tu penses? Et avez-vous expérimenté cet aspect?

Je m’intéresse à la performance et à l’évolutivité de chacun des deux magasins de données pour ce type de tâche. C’est le genre de question de conception architecturale, et les détails des options spécifiques au magasin ou des pierres angulars de la requête qui devraient le rendre bien architecturé sont les bienvenus en tant que démonstration d’une suggestion bien pensée.

Merci!

Tout d’abord, il y a une distinction importante à faire ici: MongoDB est une firebase database polyvalente, Elasticsearch est un moteur de recherche de texte dissortingbué soutenu par Lucene. Les gens ont parlé d’utiliser Elasticsearch comme firebase database générale, mais ils savent que ce n’est pas sa conception originale. Je pense que les bases de données et les moteurs de recherche NoSQL d’usage général sont destinés à la consolidation, mais en l’état actuel des choses, ils proviennent de deux camps très différents.

Nous utilisons à la fois MongoDB et Elasticsearch dans mon entreprise. Nous stockons nos données dans MongoDB et utilisons exclusivement Elasticsearch pour ses capacités de recherche en texte intégral. Nous n’envoyons qu’un sous-ensemble des champs de données mongo que nous devons interroger pour les rendre élastiques. Notre cas d’utilisation diffère de la vôtre en ce sens que nos données Mongo changent tout le temps: un enregistrement, ou un sous-ensemble des champs d’un enregistrement, peut être mis à jour plusieurs fois par jour. Pour cette seule raison, utiliser élastique comme magasin de données unique n’est pas une bonne option pour nous, car nous ne pouvons pas mettre à jour certains champs; nous aurions besoin de réindexer un document dans son intégralité. Ce n’est pas une limitation élastique, c’est ainsi que Lucene fonctionne, le moteur de recherche sous-jacent derrière élastique. Dans votre cas, le fait que les enregistrements ne soient pas modifiés une fois stockés vous évite d’avoir à faire ce choix. Cela étant dit, si la sécurité des données est une préoccupation, je réfléchirais à deux fois avant d’utiliser Elasticsearch comme seul mécanisme de stockage de vos données. Il peut arriver à un moment donné, mais je ne suis pas sûr que ce soit là.

En termes de rapidité, Elastic / Lucene est non seulement comparable à la vitesse de requête de Mongo, mais dans votre cas, il y a “très peu de constantes pour savoir quels champs sont utilisés pour le filtrage”. magnitude plus rapide, d’autant plus que les ensembles de données deviennent plus grands. La différence réside dans les implémentations de requête sous-jacentes:

  • Elastic / Lucene utilise le modèle d’espace vectoriel et les index inversés pour la récupération d’informations , qui sont des moyens très efficaces de comparer la similarité des enregistrements à une requête. Lorsque vous interrogez Elastic / Lucene, il connaît déjà la réponse. La majeure partie de son travail consiste à classer les résultats par les plus susceptibles de correspondre à vos termes de requête. C’est un point important: les moteurs de recherche, contrairement aux bases de données, ne peuvent vous garantir des résultats exacts. Ils classent les résultats en fonction de leur proximité avec votre requête. Il se trouve que la plupart du temps, les résultats sont presque exacts.
  • L’approche de Mongo est celle d’un magasin de données plus généraliste; Il compare les documents JSON les uns contre les autres. Vous pouvez obtenir d’excellentes performances, mais vous devez soigneusement concevoir vos index pour qu’ils correspondent aux requêtes que vous exécuterez. Plus précisément, si vous interrogez plusieurs champs, vous devez soigneusement concevoir vos clés composées de manière à réduire le jeu de données qui sera interrogé aussi rapidement que possible. Par exemple, votre première clé devrait filtrer la majorité de votre jeu de données, votre seconde devrait filtrer davantage ce qui rest, et ainsi de suite. Si vos requêtes ne correspondent pas aux clés et à l’ordre de ces clés dans les index définis, vos performances diminueront considérablement. D’un autre côté, Mongo est une véritable firebase database, donc, si la précision est ce dont vous avez besoin, les réponses seront précises.

Pour les anciens enregistrements expirant, Elastic dispose d’une fonctionnalité TTL intégrée. Mongo vient de le présenter à partir de la version 2.2 je pense.

Comme je ne connais pas vos autres exigences, telles que la taille des données attendue, les transactions, la précision ou l’apparence de vos filtres, il est difficile de formuler des recommandations spécifiques. Si tout va bien, il y en a assez ici pour vous aider à démarrer.