RobertViseur.be

[Mes centres d'intérêt (Logiciel libre et Open Source)]
[28-07-2008] Atelier de présentation du mode FULLTEXT de PostgreSQL 8.3 aux RMLL 2008

La recherche FULLTEXT a été intégrée à la version 8.3 de PostgreSQL. Avant, il fallait installer un programme externe, avec les types de données adéquats, comme Tsearch2.

En matière de requêtes FULLTEXT, le SQL propose les opérateurs LIKE (recherche d'une sous-chaîne dans une chaîne de caractères) ou ~= (recherche par expression rationnelle). Selon l'orateur, les expressions régulières n'ont pas vraiment d'incidence négative sur les performances.

Le mode FULLTEXT de PostgreSQL 8.3 possède un mécanisme de lemmatisation capable, donc, de ramener les mots à une forme canonique. En pratique, PostgreSQL propose en standard un seul analyseur, capable d'accepter différentes langues: anglais, français, espagnol, etc. Les recherches sont dès lors basées sur une racine, ce qui est mieux qu'une recherche brute.

Comme dit plus haut, le mode FULLTEXT nécessite de nouvelles structures de données: tsvector et tsquery.

En pratique, PosgreSQL va, pour chaque expression entrée, récupérer sa racine et son emplacement. Il va également supprimer les ''mots noirs''. La fonction ''to_tsvector'' va réaliser ce travail pour le texte à indexer; la fonction ''to_tsquery'', pour les expressions de recherche. Il est possible de passer au ts_query un seul ou plusieurs mots avec des opérateurs booléens comme & (ET) et ! (NON). Par contre, il n'est pas possible de faire des recherches ''à la Google'' avec des guillemets (l'orateur suggère de réaliser un post-traitement des résultats pour améliorer la pertinence).

Le programme ''psql'' entré dans un terminal GNU/Linux permet de saisir les commandes SQL correspondantes. Côté syntaxe, \d permet de voir les tables; \d tpages permet de voir la structure de la table tpages.

Exemple de requête: SELECT * FROM docs WHERE to_tsvector(contenu) @@ to_tsquery('mot');

Concrètement, si on indexe la documentation française de PostgreSQL (ce qui a été fait dans le cadre de l'atelier), la requête SELECT * FROM docs WHERE to_tsvector(titre) @@ to_tsquery('tsearch2'); permettra de récupérer tous les documents contenant le terme ''tsearch2'' dans le titre.

Ici, le tsvector est calculé à chaque exécution, ce qui n'est pas performant. Il faut donc conserver le vecteur calculé. On peut pour ce faire créer une colonne pour stocker le tsvector (l'opération prend plusieurs secondes):

ALTER TABLE tpages ADD COLUMN vecteur tsvector;
UPDATE tpages SET vecteur=to_tsvector(contenu);

A noter qu'il est possible de mettre différentes colonnes contenant des vecteurs dans une table dédicacée.

La même requête que précédemment peut dès lors être écrite comme suit:

SELECT * FROM docs WHERE vecteur @@ to_tsquery('tsearch2');

Il est en plus possible d'ajouter un index sur la colonne ''vecteur''. Il existe deux modes d'index: GIN (rapide; pour petit index) ou GIST (rapide en recherche, lent en mise à jour; pour gros index). Le choix du type d'index dépend donc des conditions d'utilisation des données; il est possible d'utiliser les deux types d'index sur une même base de données.

Fonctions avancées

''ts_rank'' et ''ts_rank_cd'' permettent d'avoir les scores de pertinence associés aux résultats d'une requête. Il faut donc faire, par exemple, ts_rank (vecteur, to_tsquery('tsearch2') ). Si cette instruction est placée en seconde position dans le SELECT, un ORDER BY 2 (ou un alias via AS) permettra de procéder à un tri par pertinence. A noter qu'il est possible, à la création du vecteur, de mettre quatre poids, allant de A à D, à un vecteur, de manière à le booster.

''ts_headline'' permet d'obtenir un extrait des résultats (ce que l'on appelle parfois un snippet), dans lequel il met par défaut le terme de recherche en évidence avec <b></b>.

Sinon, côté commandes: \dF permet de voir les langues disponibles; \dFp, les analyseurs disponibles; \dFt, d'autres modules installés (comme par exemple les synonymes, les thésaurus, etc). Il est ainsi possible de nativement gérer une table de synonymes. Pour la lemmatisation, Snowball est dans la liste et est utilisé par défaut. iSpell est utilisé pour les racines. Par contre, il n'y a pas d'accès à iSpell pour, par exemple, générer des suggestions de mots-clefs.

A noter que, dans PostgreSQL, le stockage est réalisé en UTF-8.

Comparaison à MySQL FULLTEXT

Pour ceux qui ne connaîtraient pas la fonctionnalité MySQL FULLTEXT, une aide est disponible sur le site officiel: ''Recherche en texte intégral (Full-text) dans MySQL''.

Le mode plein texte de PostgreSQL permet une gestion plus fine de l'indexation, avec un contrôle de la lemmatisation. C'est un ''plus'' important. Par contre, il ne propose par de mécanisme d'extension de requête ni, surtout, d'interprétation des requêtes entrées par l'utilisateur. Une pénible étape préalable de traitement des requêtes se révèlera donc nécessaire.

Point en suspens: je ne sais pas s'il est possible d'utiliser le champs stockant le vecteur de termes, par exemple pour la réalisation de nuages de tags.

Les présentations des ateliers PostgreSQL aux RMLL (il y en avait d'autres) sont disponibles sur le site communautaire francophone: [1].

Source :

[1] http://www.postgresqlfr.org/?q=node/1682

[Commentaires (0)]     [Lien permanent]

Faites connaître ce billet:

Publicité: