Tout d'abord, il y a une distinction importante à faire ici :MongoDB est une base de données à usage général, Elasticsearch est un moteur de recherche de texte distribué soutenu par Lucene. Les gens ont parlé d'utiliser Elasticsearch comme base de données à usage général, mais savent que ce n'était pas sa conception originale. Je pense que les bases de données NoSQL à usage général et les moteurs de recherche se dirigent vers la consolidation, mais dans l'état actuel des choses, les deux appartiennent à 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 Elasticsearch exclusivement pour ses capacités de recherche en texte intégral. Nous envoyons uniquement un sous-ensemble des champs de données mongo que nous devons interroger à elastic. Notre cas d'utilisation diffère du vôtre en ce 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, ce qui peut nécessiter une réindexation de cet enregistrement vers elastic. Pour cette seule raison, utiliser elastic comme seul magasin de données n'est pas une bonne option pour nous, car nous ne pouvons pas mettre à jour les champs sélectionnés; nous aurions besoin de réindexer un document dans son intégralité. Ce n'est pas une limitation élastique, c'est ainsi que fonctionne Lucene, le moteur de recherche sous-jacent derrière élastique. Dans votre cas, le fait que les enregistrements ne seront pas modifiés une fois stockés vous évite d'avoir à faire ce choix. Cela 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 se peut qu'il y parvienne à un moment donné, mais je ne suis pas sûr qu'il y soit encore.
En termes de vitesse, non seulement Elastic/Lucene est à égalité avec la vitesse d'interrogation de Mongo, dans votre cas où il y a "très peu de constante en termes de champs utilisés pour le filtrage à tout moment", cela pourrait être des ordres de ampleur 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êtes sous-jacentes :
- Elastic/Lucene utilisent le modèle d'espace vectoriel et des index inversés pour la récupération d'informations, qui sont des moyens très efficaces de comparer la similarité des enregistrements par rapport à 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 pour vous en fonction de ceux qui correspondent le mieux aux termes de votre requête. C'est un point important :les moteurs de recherche, contrairement aux bases de données, ne peuvent pas 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 à usage plus général ; il compare les documents JSON entre eux. Vous pouvez en tirer d'excellentes performances par tous les moyens, mais vous devez créer soigneusement vos index pour qu'ils correspondent aux requêtes que vous exécuterez. Plus précisément, si vous souhaitez interroger plusieurs champs, vous devez créer soigneusement vos clés composées afin qu'elles réduisent le plus rapidement possible l'ensemble de données qui sera interrogé. Par exemple. votre première clé doit filtrer la majorité de votre ensemble de données, votre seconde doit filtrer davantage ce qui reste, 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 chuteront un peu. D'un autre côté, Mongo est une véritable base de données, donc si la précision est ce dont vous avez besoin, les réponses qu'il donnera seront exactes.
Pour l'expiration des anciens enregistrements, Elastic dispose d'une fonctionnalité TTL intégrée. Mongo vient de l'introduire à partir de la version 2.2 je pense.
Étant donné que je ne connais pas vos autres exigences telles que la taille des données attendues, les transactions, la précision ou à quoi ressembleront vos filtres, il est difficile de faire des recommandations spécifiques. J'espère qu'il y en a assez ici pour vous aider à démarrer.
