Principales limitations de la recherche jusqu'en 3.4

Le principal avantage de la méthode d'indexation jusqu'en 3.4 est que le nombre de lignes à inspecter lors d'une recherche est équivalent au nombre de notices. C'est à dire qu'une augmentation raisonnable du nombre de notices (un accroissement de 10% par an par exemple) a peu d'influence sur les performances. L'augmentation de puissance nécessaire à un accroissement du fonds est très amortie.

L'utilisation de la valeur des champs pour les recherches exactes évite de doubler l'information et limite donc le volume de stockage de la base de données. D'autre part, la répartition des index (les index sont éclatés entre les tables autorités et la table des notices) facilite leur manipulation par MySQL.

Si les performances sont peu sensibles à une augmentation modérée du nombre de notices, une forte augmentation peut amener un effet de seuil marqué. En effet, compte tenu que l'index d'un champ contient l'ensemble des mots de ce champ de recherche, sa taille varie fortement et sa taille n'est pas prévisible. Cela oblige MySQL dans les opérations sur les tables à créer des tables temporaires sur disque dur. Les temps d'accès aux disques durs sont très lents en regard d'un accès mémoire.

Autre effet de seuil possible : MySQL dispose d'un cache pour les requêtes. Ce cache peut être vite saturé si le nombre de réponses augmente avec des index importants. La performance chute d'autant.

MySQL est capable d'optimiser l'accès à des enregistrements d'une table de données s'il est capable de trier le champ de recherche questionné. Ainsi, si l'on cherche dans un index de recherche PMB ce qui commence par une valeur xxx , MySQL est capable de retrouver rapidement (sans parcourir toute la table) la zone des enregistrements de la table pour laquelle l'index, trié de manière alphabétique est susceptible de répondre à la recherche.

L'utilisation d'une troncature à gauche ne permet pas à MySQL d'utiliser cette possibilité, car il n'est pas possible de déterminer où se situe "quelque chose qui commence par n'importe quoi" !

L'utilisation des tables temporaires sur disque, la saturation des caches et la troncature à gauche, l'ensemble de ces effets peut aboutir à une chute importante des performances pour des gros volumes de données, avec un effet de seuil important. Le nombre de notices dépend beaucoup de la configuration du serveur (matériel, OS, etc.).

Un ordre de grandeur peut-être de l'ordre de 150 000 notices pour une bonne machine de bureau.

Le calcul de la pertinence est parfois simpliste : afin d'obtenir une meilleure pertinence, il faudrait pondérer chaque terme inversement proportionnellement à la fréquence d'apparition du mot dans les notices.

Pour calculer la pertinence, il faudrait pouvoir compter le nombre de fois où le mot apparaît. Tel que sont construits les index (un champ qui contient tous les mots), il est impossible en une seule requête SQL de distinguer chaque mot automatiquement pour les compter.

De même, on pourrait donner plus d'importance à deux mots recherchés s'ils sont près l'un de l'autre. Ce calcul est impossible avec la recherche actuelle car il n'y a pas moyen de compter le nombre de mots entre deux mots dans le même champ.

Une autre pondération impossible avec le système de recherche de la 3.4 concerne la recherche tous les champs. Il serait intéressant de pouvoir pondérer les termes en fonction du champ de la notice auquel il appartient. On peut supposer qu'un mot du titre ou d'une catégorie a plus de signification qu'un mot du résumé.

L'index PMB de tous les champs n'étant qu'une agrégation des mots de tous les champs, il n'est pas possible de donner plus d'importance à un mot qu'à un autre.