Pourquoi devrais-je utiliser ElasticSearch si j'utilise déjà une base de données graphique?

Je ne trouve aucune explication approfondie sur le Web concernant une comparaison entre ElasticSearch et les bases de données graphiques.

Les deux sont optimisés pour parcourir les données.
ElasticSearch semble être optimisé pour l'analyse.
Cependant, Neo4j est également basé sur Lucene pour gérer les index et certaines fonctionnalités de texte intégral.

Pourquoi devrais-je utiliser ElasticSearch si j'utilise déjà une base de données graphique?

Dans mon cas, j'utilise Neo4j pour construire un réseau social.
Quels avantages réels ElasticSearch peut-il apporter?

MISE À JOUR ----------

Je viens de trouver ce paragraphe:

Il existe une myriade de cas dans lesquels elasticsearch est utile. Certains cas d'utilisation le demandent plus clairement que d'autres. Voici quelques tâches pour lesquelles elasticsearch est particulièrement bien adapté.

• Recherche d'un grand nombre de descriptions de produits pour la meilleure correspondance pour une phrase spécifique (par exemple, "couteau de chef") et retour des meilleurs résultats
• Dans l'exemple précédent, décomposer les différents départements où apparaît le «couteau de chef» (voir Faceting plus loin dans ce livre)
• Recherche dans le texte de mots qui sonnent comme «saison»
• Remplissage automatique d'une zone de recherche basée sur des mots partiellement dactylographiés basés sur des recherches précédemment émises tout en tenant compte des fautes d'orthographe
• Stockage d'une grande quantité de données semi-structurées (JSON) de manière distribuée, avec un niveau de redondance spécifié sur un cluster de machines

Il convient de noter, cependant, que si elasticsearch est excellent pour résoudre les problèmes susmentionnés, ce n'est pas le meilleur choix pour les autres. Il est particulièrement mauvais pour résoudre des problèmes pour lesquels les bases de données relationnelles sont optimisées. Problèmes tels que ceux répertoriés ci-dessous.

• Calcul du nombre d'articles restant dans l'inventaire
• Calculer la somme de tous les postes sur toutes les factures envoyées au cours d'un mois donné
• Exécution de deux opérations de manière transactionnelle avec prise en charge de la restauration
• Créer des enregistrements qui sont garantis d'être uniques sur plusieurs termes donnés, par exemple un numéro de téléphone et un poste
• Elasticsearch est généralement fantastique pour fournir des réponses approximatives à partir de données, telles que la notation des résultats par qualité. Bien qu'elasticsearch puisse effectuer une correspondance exacte et des calculs statistiques, sa tâche principale de recherche est une tâche intrinsèquement approximative.
• La recherche de réponses approximatives est une propriété qui sépare elasticsearch des bases de données plus traditionnelles. Cela dit, les bases de données relationnelles traditionnelles excellent en matière de précision et d'intégrité des données, pour lesquelles elasticsearch et Lucene ont peu de dispositions.

Puis-je affirmer que si je n'ai pas besoin de réponses approximatives, ElasticSearch serait inutile par rapport à une base de données de graphiques déjà utilisée?

J'hésite à appeler ElasticSearch une base de données. Il ne remplace pas une base de données, mais il constitue un bon ajout pour ajouter des fonctionnalités, en particulier la recherche de texte avancée, aux côtés de votre base de données existante.

Je vois où vous pouvez les confondre. Ils peuvent en fait répondre au même besoin, mais pas toujours. ElasticSearch fait exactement ce que cela ressemble, recherches . Une base de données graphique ne spécifie pas de relations ou d'index, comme le fait ElasticSearch. Donc, fondamentalement, ils fonctionnent très différemment. ElasticSearch analyse les documents avec, par exemple, un analyseur anglais. Pour ce faire, il faudra des mots et analyser différentes variantes de ce mot ou même des synonymes. Par exemple, digserait analysé comme dig,digs,dug,digging,digger .... Lorsque vous exécutez une requête sur elasticsearch, vos requêtes peuvent également être analysées, puis ces mots sont recherchés et peuvent être notés par pertinence.

ElasticSearch est un excellent outil, car il est vraiment flexible. Vous pouvez trouver un large éventail de contenu relatif, ou vous pouvez trouver une aiguille dans la pile de foin, et c'est relativement facile.

Les bases de données graphiques ont également leur avantage. Recherche de pertinence / relations entre des choses comme des balises de hachage par exemple, ou des choses avec de nombreuses relations mutables. Ce sont des technologies formidables et intéressantes, mais je dois dire que ce n'est pas aussi puissant qu'ElasticSearch. Principalement parce qu'ElasticSearch est orienté vers ce genre de chose et qu'il gère l'analyse pour vous afin que vous puissiez faire une recherche en texte intégral. Cependant, si vous cherchez à utiliser un système plus comme la recherche de Twitter qui est basé sur des tags / mots-clés prédéfinis, vous feriez mieux d'utiliser la base de données graphique que vous utilisez déjà.

La question est de savoir à quel point voulez-vous que votre recherche soit robuste? Si vous avez besoin de faire des recherches à grain très fin (texte intégral), j'utiliserais elasticsearch. Sinon, vous pouvez toujours implémenter une recherche relativement facilement sur une base de données de graphiques. Une fois la recherche implémentée, il n'est pas impossible de migrer vers elasticsearch si vous vous trouvez plus tard besoin d'un moteur de recherche plus robuste, implémentez simplement votre recherche dans cet esprit.

Ces deux bases de données ont leur besoin spécifique de résoudre un problème spécifique à un certain niveau d'exigence d'application. Bien que nous n'ayons pas utilisé Graph Database. Mais nous utilisons elasticsearch avec MySQL dans l'un de nos projets des 5 dernières années. Ce projet a des données massives à rechercher dans des documents de 6 millions et a des relations massives entre ces entités (documents de relation de 10 millions).

Cas d'utilisation: comme rechercher dans les hôtels qui ont été aimés par mes amis et trier tous les hôtels avec le nombre de likes qu'ils ont. Et si vous le voyez de près. cette affaire a impliqué 2 relations (Friend, Like). Je dois donc rechercher dans la relation Like Ship entre les hôtels et mes amis, puis les hôtels doivent être triés par nombre total de likes. Donc, pour de telles recherches, la base de données graphique est bonne.

Elasticsearch fait un excellent travail pour la recherche de test complète dans les documents, mais quand il s'agit de rechercher des relations comme ci-dessus, ce n'est pas si bon. Liste des documents (entités) qui sont mes fans et triez-les par leur nombre de fans. Mais ce sont un niveau de profondeur et quand il s'agit de rechercher plus en profondeur. Elasticsearch n'est pas assez bon.

Alors, comprenez les exigences de votre application et optez pour la base de données. Vous devrez peut-être avoir les deux.