Cette question appelle une réponse très large pour répondre à tous les aspects. Il existe très bien certaines spécificités qui peuvent rendre un système supérieur à un autre pour un cas d'utilisation particulier, mais je veux couvrir les bases ici.
Je traiterai entièrement de Solr comme exemple pour plusieurs moteurs de recherche qui fonctionnent à peu près de la même manière.
Je veux commencer par quelques faits concrets :
-
Vous ne pouvez pas compter sur Solr/Lucene comme base de données sécurisée. Il existe une liste de faits expliquant pourquoi, mais ils consistent principalement en des options de récupération manquantes, un manque de transactions acides, des complications possibles, etc. Si vous décidez d'utiliser solr, vous devez remplir votre index à partir d'une autre source comme une table SQL. En fait, solr est parfait pour stocker des documents qui incluent des données de plusieurs tables et relations, qui nécessiteraient autrement la construction de jointures complexes.
-
Solr/Lucene fournit des fonctions époustouflantes d'analyse de texte/de radical/de notation de recherche de texte intégral/de flou. Des choses que vous ne pouvez tout simplement pas faire avec MySQL. En fait, la recherche en texte intégral dans MySql est limitée à MyIsam et la notation est très triviale et limitée. Pondérer les champs, booster les documents sur certaines métriques, noter les résultats en fonction de la proximité de la phrase, faire correspondre la précision, etc. est un travail très difficile, voire presque impossible.
-
Dans Solr/Lucene, vous avez des documents. Vous ne pouvez pas vraiment stocker des relations et des processus. Eh bien, vous pouvez bien sûr indexer les clés d'autres documents à l'intérieur d'un champ à plusieurs valeurs d'un document, de cette façon, vous pouvez réellement stocker des relations 1:n et le faire dans les deux sens pour obtenir n:n, mais sa surcharge de données. Ne vous méprenez pas, c'est parfaitement bien et efficace pour beaucoup de choses (par exemple pour un catalogue de produits où vous voulez stocker les distributeurs pour les produits et vous voulez rechercher uniquement les pièces qui sont disponibles chez certains distributeurs ou quelque chose comme ça). Mais vous atteignez la fin des possibilités avec HAS / HAS NOT. Vous ne pouvez presque pas faire quelque chose comme "obtenir tous les produits disponibles chez au moins 3 distributeurs".
-
Solr/Lucene a de très belles fonctionnalités de facettage et une analyse post-recherche. Par exemple :après une recherche très large contenant 40 000 coups, vous pouvez afficher que vous n'obtiendrez que 3 coups si vous affinez votre recherche en combinant ce champ avec cette valeur et ce champ avec cette valeur. Les tâches nécessitant des requêtes supplémentaires dans MySQL sont effectuées de manière efficace et pratique.
Résumons donc
-
La puissance de Lucene est la recherche/analyse de texte. Il est également incroyablement rapide en raison de la structure d'index inversée. Vous pouvez vraiment faire beaucoup de post-traitement et satisfaire d'autres besoins. Bien qu'il soit orienté document et n'ait pas de "requête de graphes" comme le font les magasins triples avec SPARQL, les relations N:M de base sont possibles pour stocker et interroger. Si votre application est axée sur la recherche de texte, vous devez absolument opter pour Solr/Lucene si vous n'avez pas de bonnes raisons, comme des requêtes de filtre de plage multidimensionnelles très complexes, pour faire autrement.
-
Si vous n'avez pas de recherche de texte, mais plutôt quelque chose où vous pouvez pointer et cliquer quelque chose mais pas entrer de texte, les bonnes vieilles bases de données relationnelles sont probablement une meilleure solution.
