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

Question

Je viens de lire un article mentionnant la "recherche plein texte" en 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.

Answer 1

En général, il existe un compromis entre la "précision" et le "rappel". Une précision élevée signifie que moins de résultats non pertinents sont présentés (aucun faux positif), tandis qu'un rappel élevé signifie que moins de résultats pertinents sont manquants (aucun faux négatif). L'utilisation de l'opérateur LIKE permet d'obtenir une précision de 100 %, sans concession sur le rappel. Une fonction de recherche en texte intégral vous offre une grande souplesse pour réduire la précision et améliorer le rappel.

La plupart des implémentations de recherche en texte intégral utilisent un "index inversé". Il s'agit d'un index où les clés sont des termes individuels et les valeurs associées sont des ensembles d'enregistrements qui contiennent 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 le degré de correspondance entre un enregistrement donné et les mots-clés recherchés.

L'opérateur SQL LIKE peut être extrêmement inefficace. Si vous l'appliquez à une colonne non indexée, un balayage complet sera utilisé 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 une efficacité bien moindre que la plupart des recherches dans les index. Dans le pire des cas, le motif LIKE comportera des caractères génériques de tête qui nécessiteront l'examen de chaque clé d'index. En revanche, de nombreux systèmes de recherche d'informations peuvent prendre en charge les caractères génériques de tête en précompilant des arbres de suffixes dans des champs sélectionnés.

Les autres caractéristiques typiques de la recherche en texte intégral sont

• l'analyse lexicale ou la tokenisation - en brisant un bloc de texte non structuré en mots individuels, phrases et jetons spéciaux
• morphologique l'analyse morphologique, ou le stemming, qui consiste à regrouper les variations d'un mot donné en un seul terme d'indexation ; par exemple, traiter "souris" et "souris", ou "électrification" et "électrique" comme le même mot
• classement - mesure de la similarité d'un enregistrement correspondant à la chaîne de caractères de la requête

Answer 2

FTS consiste à indexer les mots individuels dans un champ de texte afin de rendre la recherche rapide dans de nombreux enregistrements. L'utilisation de LIKE vous oblige à effectuer une recherche de chaîne (linéaire ou autre) dans le champ.

Answer 3

MySQL crée un index à partir des mots de la colonne de recherche en 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.

De plus, de cette réponse SO :

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

L'indexation :

Quelque chose comme :

WHERE Foo LIKE '%Bar';

Impossible de profiter d'un indice. Il doit examiner chaque ligne, et voir si elle correspond. Un index plein texte, en revanche, le peut. En fait, les index plein texte peuvent offrir beaucoup plus de flexibilité en termes d'ordre des mots correspondants, de proximité des mots, etc.

Tirage au sort :

Une recherche en texte intégral permet d'extraire des mots. Si vous recherchez run, vous pouvez obtenir des résultats pour "ran" ou "running". La plupart des moteurs de recherche en texte intégral disposent de dictionnaires de racines dans différentes langues.

Résultats pondérés :

Un index plein texte 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 avoir une pondération plus élevée, car ils sont plus pertinents, et peuvent être triés pour apparaître en tête de liste.

Inconvénients :

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

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

Answer 4

Like n'utilise que des caractères génériques et n'est pas très puissant.

Le texte intégral permet des recherches beaucoup plus complexes, notamment And, Or, Not, même des résultats à consonance similaire (SOUNDEX) et bien d'autres éléments.

Je commencerais par examiner les éléments de recherche SQL CONTAINS() FREETEXT() et Full Text connexes pour mieux comprendre ce qui est disponible.

Answer 5

La véritable différence réside dans les méthodes de numérisation. Pour la recherche en texte intégral, les mots (termes) sont utilisés comme des clés de hachage, chacune d'entre elles étant associée à un ensemble 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 est membre de quel document) peut être représentée comme suit :

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

Lorsque la requête arrive et demande "Obtenez-moi tous les documents contenant le mot/terme t1" - alors le jeu de documents {d1, d5, d9,.. dn } est retourné.

Vous pourriez modifier un schéma de table dé-normalisé pour stocker les documents - chaque ligne de la table MySQL sera considérée comme un "document" et une colonne TEXT pourrait contenir un paragraphe, etc. L'index inversé contiendra les termes en tant que clés de hachage et les ID des lignes en tant qu'ID des documents.

Rappelez-vous que cette requête SQL aura des performances plus ou moins O(1). La requête sera indépendante de

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

Par exemple, ce SQL peut être utilisé pour extraire toutes les lignes correspondant au mot XYZ donné :

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

Avertissement : si vous ajoutez ORDER BY à cette requête, vos temps d'exécution varieront en fonction de plusieurs paramètres, dont l'un est le nombre de lignes/documents correspondants. Prenez donc garde.

Le LIKE n'a cependant rien compris à cela. Il est obligé de balayer linéairement la phrase/chaîne et de trouver tous les termes correspondants. L'ajout de caractères génériques ne fait qu'ajouter au désordre. Comme vous pouvez l'imaginer, cela fonctionne très bien pour les chaînes de petite longueur, mais échouera lamentablement pour les phrases plus longues. Et certainement pas comparable lorsqu'il s'agit d'un paragraphe ou d'une page entière de texte, etc.