elasticsearch c. s. MongoDB pour l'application du filtrage

Question

Cette question est à propos de faire un choix architectural avant d'entrer dans les détails de l'expérimentation et de la mise en œuvre. C'est à propos de la pertinence, de l'évolutivité et les performances d'elasticsearch c. s. MongoDB, pour un peu le but spécifique.

Hypothétiquement à la fois de stocker les données des objets qui ont des champs et des valeurs, et de permettre l'interrogation de ce corps d'objets. Donc vraisemblablement le filtrage des sous-ensembles d'objets selon les champs sélectionnés ad-hoc, est quelque chose d'ajustement pour les deux.

Ma demande va s'articuler autour de la sélection d'objets selon des critères. Il serait de sélectionner les objets par filtrage simultanément par plus d'un seul champ, autrement dit, sa requête critères de filtrage serait comportent généralement entre 1 et 5 champs, peut-être plus dans certains cas. Alors que les champs choisis comme des filtres serait un sous-ensemble d'une bien plus grande quantité de champs. Image 20 noms de champs existants, et chaque requête est une tentative pour filtrer les objets par quelques champs de ces total de plus de 20 champs (Ça peut être moins ou de plus de 20 ensemble des noms de champs existants, je viens d'utiliser ce numéro pour démontrer le ratio de champs utilisés comme filtres dans chaque discret de la requête). Le filtrage peut être par l'existence de champs choisis, ainsi que par les valeurs de champ, par exemple le filtrage des objets qui ont Un champ, et leur champ B est entre x et y, et leur champ de C est égale à w.

Mon application sera constamment faire ce genre de filtrage, alors qu'il n'y aurait rien, ou très peu, constante en termes de champs qui sont utilisés pour le filtrage à tout moment. Peut-être dans elasticsearch les index doivent être définies, mais peut-être même sans les indices de vitesse est au pair avec celle de MongoDB.

Selon les données à entrer dans le magasin, il n'y a pas de détails à ce sujet.. les objets seraient presque jamais changé après avoir été inséré. Peut-être de vieux objets devront être abandonné, je tiens à supposer que les deux banques de données à l'appui expiration de la suppression de choses en interne ou par une demande de requête. (De moins en moins souvent, des objets qui correspondent à une certaine requête devra être abandonnée).

Qu'en pensez-vous? Et, avez-vous expérimenté cet aspect?

Je suis intéressé par la performance et l'évolutivité, de chacune des deux banques de données, pour ce genre de tâche. C'est le genre de l'architecture desing question, et les détails de stocker les options spécifiques à la requête ou de piliers qui doit faire bien conçue sont les bienvenus en tant que manifestation d'une pensée de la suggestion.

Merci!

Answer 1

Tout d'abord, il y a une importante distinction à faire ici: MongoDB est une base de données polyvalente, Elasticsearch est un texte réparti moteur de recherche soutenu par Lucene. On parle beaucoup de l'aide d'Elasticsearch comme un objectif général de base de données, mais de savoir qu'il n'était pas son design original. Je pense que l'objectif général des bases de données NoSQL et les moteurs de recherche sont à la tête de consolidation, mais comme il est, les deux viennent de deux camps différents.

Nous utilisons à la fois MongoDB et Elasticsearch dans mon entreprise. Nous stocker nos données dans MongoDB et utiliser Elasticsearch exclusivement pour le texte intégral des capacités de recherche. Nous n'envoyer qu'un sous-ensemble de la mongo champs de données que nous avons besoin de la requête à l'élastique. Notre cas d'utilisation diffère de la vôtre que notre Mongo données change tout le temps: un record, ou un sous-ensemble des champs d'un enregistrement, peuvent être mis à jour plusieurs fois par jour et cela peut appeler pour ré-indexation de ce disque à l'élastique. Pour cette seule raison, en utilisant des élastiques comme la seule banque de données n'est pas une bonne option pour nous, comme nous ne pouvons pas mettre à jour des champs; nous aurions besoin de ré-indexer un document dans son intégralité. Ce n'est pas un élastique de limitation, c'est comment Lucene fonctionne, le moteur de recherche derrière élastique. Dans votre cas, le fait que les enregistrements ne seront pas changés une fois stockées vous évite d'avoir à faire ce choix. Ayant dit que, si la sécurité des données est une préoccupation, je pense que deux fois sur l'utilisation d'Elasticsearch comme le seul mécanisme de stockage pour vos données. Il peut y arriver à un certain point, mais je ne suis pas sûr qu'elle y est encore.

En termes de vitesse, non seulement est Élastique/Lucene sur le pair avec l'interrogation de la vitesse de Mongo, dans votre cas, où il y a "très peu de constante en termes de champs qui sont utilisés pour le filtrage à tout moment", il pourrait être à des ordres de grandeur plus rapide, en particulier que les ensembles de données deviennent de plus. La différence réside dans la requête sous-jacente implémentations:

• Élastique/Lucene utiliser le Modèle Vectoriel et l'index inversés pour l' Extraction de l'Information, qui sont très efficaces moyens de comparaison de l'enregistrement de la similitude à l'encontre d'une requête. Lorsque vous interrogez Élastique/Lucene, il connaît déjà la réponse; la plupart de son travail réside dans le classement des résultats par les plus probables pour correspondre à vos termes de la requête. C'est un point important: les moteurs de recherche, par opposition à des bases de données, ne peut pas vous garantir des résultats précis; ils classer les résultats par quel point ils arrivent à votre requête. Il se trouve que la plupart du temps, les résultats sont proches exacte.
• Mongo de l'approche est que plus fins générales de banque de données; il compare JSON documents les uns contre les autres. Vous pouvez obtenir d'excellentes performances en sortir par tous les moyens, mais vous devez soigneusement préparer votre index afin de correspondre à la demande de renseignements, vous sera en cours d'exécution. Plus précisément, si vous avez de multiples domaines qui vous permettra de requête, vous devez soigneusement préparer vos clés composées de sorte qu'elles permettent de réduire l'ensemble de données qui va être interrogé aussi vite que possible. E. g. votre première clé à filtre en bas de la majorité de vos données, votre deuxième devraient, en outre, le filtre vers le bas ce qui à gauche, et ainsi de suite et ainsi de suite. Si vos questions ne correspondent pas, les touches et l'ordre de ces clés dans la définition des index, votre rendement va baisser un peu. D'autre part, Mongo est une véritable base de données, de sorte que si la précision est ce que ce dont vous avez besoin, les réponses qu'il donnera sera sur place.

Pour expirant vieux enregistrements, Élastique a un construit en fonction TTL. Mongo juste introduit à partir de la version 2.2, je pense.

Depuis je ne sais pas vos autres besoins tels que les attendus de la taille des données, des transactions, de l'exactitude, ou de ce que vos filtres ressemblera, il est difficile de donner des recommandations spécifiques. Heureusement, il y a assez de place ici pour obtenir vous avez commencé.

Answer 2

Dans ElasticSearch, découvrez à l'aide de FilteredQuery. Ils peuvent filtrer les matchs sans donner une note aux résultats, économiser un peu de temps et des ressources où vous ne voulez pas ou besoin de la partition.

elasticsearch.org/query-dsl-filtered