Qu'est-ce que la recherche de texte intégral par rapport à LIKE

Je viens de lire un article mentionnant "recherche de texte intégral" dans SQL.

Je me demandais juste quelle était la différence entre FTS et LIKE. J'ai lu quelques articles mais je n'ai rien trouvé qui l'explique bien.

En général, il y a un compromis entre «précision» et «rappel». Une précision élevée signifie que moins de résultats non pertinents sont présentés (pas de faux positifs), tandis qu'un rappel élevé signifie qu'il manque moins de résultats pertinents (pas de faux négatifs). L'utilisation de l'opérateur LIKE vous donne une précision de 100% sans concession pour le rappel. Une fonction de recherche de texte intégral vous offre une grande flexibilité pour affiner la précision pour un meilleur rappel.

La plupart des implémentations de recherche en texte intégral utilisent un "index inversé". Il s'agit d'un index dans lequel les clés sont des termes individuels et les valeurs associées sont des ensembles d'enregistrements contenant le terme. La recherche en texte intégral est optimisée pour calculer l'intersection, l'union, etc. de ces ensembles d'enregistrements, et fournit généralement un algorithme de classement pour quantifier dans quelle mesure un enregistrement donné correspond aux mots-clés de recherche.

L'opérateur SQL LIKE peut être extrêmement inefficace. Si vous l'appliquez à une colonne non indexée, une analyse complète sera utilisée pour trouver des correspondances (comme toute requête sur un champ non indexé). Si la colonne est indexée, la correspondance peut être effectuée par rapport aux clés d'index, mais avec beaucoup moins d'efficacité que la plupart des recherches d'index. Dans le pire des cas, le modèle LIKE aura des caractères génériques en tête qui nécessitent que chaque clé d'index soit examinée. En revanche, de nombreux systèmes de recherche d'informations peuvent permettre la prise en charge des principaux caractères génériques en précompilant les arborescences de suffixes dans les champs sélectionnés.

Les autres fonctionnalités typiques de la recherche en texte intégral sont

• analyse lexicale ou tokenisation: décomposition d'un bloc de texte non structuré en mots individuels, phrases et jetons spéciaux
• analyse morphologique, ou dérivation - regroupement des variations d'un mot donné en un seul terme d'index; par exemple, traiter «souris» et «souris», ou «électrification» et «électrique» comme le même mot
• classement: mesure de la similitude d'un enregistrement correspondant avec la chaîne de requête

FTS implique l'indexation des mots individuels dans un champ de texte afin de rendre la recherche rapide dans de nombreux enregistrements. L'utilisation de LIKE vous oblige toujours à effectuer une recherche de chaîne (linéaire ou similaire) dans le champ.

MySQL crée un index à partir des mots de la colonne de recherche de texte intégral activée et effectue des recherches sur cet index. MySQL utilise un algorithme sophistiqué pour déterminer les lignes correspondant à la requête de recherche.

Aussi, à partir de cette réponse SO :

La recherche de texte intégral présente quelques avantages.

Indexage:

Quelque chose comme:

WHERE Foo LIKE '%Bar';

Impossible de tirer parti d'un index. Il doit regarder chaque ligne et voir si cela correspond. Un index de texte intégral, cependant, peut. En fait, les index de texte intégral peuvent offrir beaucoup plus de flexibilité en ce qui concerne l'ordre des mots correspondants, la proximité de ces mots, etc.

Tige:

Une recherche plein texte peut entraîner des mots. Si vous recherchez run, vous pouvez obtenir des résultats pour «run» ou «running». La plupart des moteurs de texte intégral ont des dictionnaires souches dans une variété de langues.

Résultats pondérés:

Un index de texte intégral peut englober plusieurs colonnes. Par exemple, vous pouvez rechercher "tarte aux pêches", et l'index peut inclure un titre, des mots clés et un corps. Les résultats qui correspondent au titre peuvent être pondérés plus haut, car ils sont plus pertinents, et peuvent être triés pour s'afficher vers le haut.

Désavantages:

Un index de texte intégral peut potentiellement être énorme, plusieurs fois plus grand qu'un index B-TREE standard. Pour cette raison, de nombreux fournisseurs hébergés qui proposent des instances de base de données désactivent cette fonctionnalité ou facturent au moins des frais supplémentaires. Par exemple, la dernière fois que j'ai vérifié, Windows Azure ne prenait pas en charge les requêtes de texte intégral.

Les index de texte intégral peuvent également être plus lents à mettre à jour. Si les données changent beaucoup, il peut y avoir un décalage de mise à jour des index par rapport aux index standard.

Like utilise uniquement des caractères génériques et n'est pas si puissant.

Le texte intégral permet une recherche beaucoup plus complexe, y compris And, Or, Not, même des résultats similaires (SOUNDEX) et bien d'autres éléments.

Je commencerais à regarder le SQL CONTAINS () FREETEXT () et les éléments de recherche de texte intégral associés pour aider à mieux comprendre ce qui est disponible.

La vraie différence réside dans les méthodologies de numérisation. Pour la recherche en texte intégral, les mots (termes) sont utilisés comme clés de hachage - dont chacune est associée à un tableau de documents dans lesquels les clés (termes) apparaissent. C'est comme ça:

Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}

Maintenant, la matrice terme-document (quel terme membre de quel document) peut être représentée par:

t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}

Lorsque la demande arrive en demandant "Obtenez-moi tous les documents contenant le mot / terme t1" - alors l'ensemble de documents {d1, d5, d9,.. dn} est retourné.

Vous pouvez pirater un schéma de table dé-normalisé pour stocker des documents - chaque ligne de la table MySQL sera considérée comme "document" et une colonne TEXT peut contenir un paragraphe etc. L'index inversé contiendra les termes sous forme de clés de hachage et les ID de ligne comme les identifiants du document.

N'oubliez pas que cette requête SQL aura plus ou moins de performances O (1). La requête sera indépendante de

1. Nombre de mots / termes dans la colonne TEXT
2. Le nombre de lignes / documents correspondant aux critères
3. La longueur des mots / termes

Par exemple, ce SQL pourrait être déclenché pour extraire toutes les lignes correspondant au mot XYZ donné:

SELECT * 
FROM   my_table 
WHERE  MATCH (my_text_column) against ('XYZ' IN boolean mode) ;

Attention: si vous ajoutez ORDER BY à cette requête, vos exécutions varieront en fonction de plusieurs paramètres, dont l'un est le nombre de lignes / documents correspondants. Alors méfiez-vous.

Le LIKE n'a cependant rien de tout cela. Il est obligé de parcourir linéairement la phrase / chaîne et de trouver tous les termes correspondants. L'ajout d'un joker ajoute au désordre. Cela fonctionne très bien pour les chaînes de petite longueur, comme vous pouvez l'imaginer, mais échouera lamentablement pour les phrases plus longues. Et certainement pas comparable avec un paragraphe ou une page entière de texte, etc.

FTS est plus efficace, plus puissant (surtout pour les Word Breakers et les fonctionnalités de dérivation) ... mais vérifiez vos besoins car parfois les DB ne supportent pas toutes les langues par exemple MSSQL ne supporte pas le grec (vérifiez sur cette page http: // msdn. microsoft.com/en-us/library/ms176076(v=sql.110).aspx )