Discussion :

[Merfolk]

Bonjour,

ce serait pour un moteur de recherche multi-critères, (utilisé sur un site relativement fréquenté, pas une fonctionnalité inutile sur un blog inconnu)

problème :
on ne veut pas faire de jointure entre 15 tables...
article - motsclés -geographies - auteurs - categories - ... blababla
structure classique d'une bdd en 3eme forme normale

de même, sur la page de résultats, ça afficherait différentes informations, (le lien sur l'article par exemple, sa rubrique, ses mots clés, sa rubrique parent, le tout bien évidement cliquable etc.)
Pareil : chaque élément a besoin d'infos venant de beaucoup de tables à la base

- ça rend la recherche complexe à écrire déjà
- c'est pas optimal vu le nombre d'infos à charger partout

(ps : oui les champs sont indexés)


----

On a testé :

faire une "table de recherche", où on "exporte" les articles concernés
avec toutes les informations. (l'id du mot clé, son label etc. etc.)
qui est reconstruire régulièrement...
1 ligne = 1 enregistrement archi complet
même des champs multivalués
listeMotsCles = "10,92,67"

et au lieu de faire
select join articles / join rubriques / join mots clés / ...
on fait simplement
select from index_recherche where listeMotsCles like %,92,%

et on obtient tout ce qu'il faut pour l'affichage directement, aucune jointure, aucune table principale n'est jamais impactée... (pas de copying to tmp tables...)


----

"bilan"
ça fonctionne bien, c'est rapide et stable.


je voulais avoir l'avis de quelques spécialistes sur cette façon de faire. C'est bcp de redondance de données pour les performances, mais ça ne nous dérange pas.
(j'étais un peu inquiet d'une requête de ce genre
select from index_recherche where listeMotsCles like %,92,%
mais c'est extrêmement rapide)

merci

[Antoun]

Fondamentalement, l'idée de dénormaliser une appli de pure recherche qui ne demande pas de saisie et qui n'a pas besoin d'être mise à jour en temps réel ne me choque pas.

Ceci dit, je pense que le postulat de départ "on ne veut pas faire 15 jointures" est une erreur. Il n'y a rien de bizarre ni de sous-performant à faire 15 jointures, du moment que les colonnes en jeu sont correctement indexées.

A mon sens, le vrai point de comparaison serait entre ta table dénormalisée et une vue qui calculerait dynamiquement les mêmes informations, et simplifierait tout autant les requêtes de recherche.

Au passage, tes champs multivalués peuvent être générés simplement avec GROUP_CONCAT (c'est peut-être ce que tu fais déjà) et requêtés avec FIND_IN_SET. Je pense que cette fonction peut être plus rapide que du LIKE, mais je n'ai jamais testé.

[Sivrît]

je voulais avoir l'avis de quelques spécialistes sur cette façon de faire. C'est bcp de redondance de données pour les performances, mais ça ne nous dérange pas.
(j'étais un peu inquiet d'une requête de ce genre
select from index_recherche where listeMotsCles like %,92,%
mais c'est extrêmement rapide)

Le point critique est le volume de données. Quelle quantité y en a-t-il pour les test, combien y en aura-t-il plus tard. Un "like '%,92,%'" n'utilise aucun index, donc il parcourt tout. Tant que le volume reste raisonnable (et que la quantité de recherches reste aussi raisonnable) et que ça tient en mémoire, pourquoi pas. Mais je suggère de faire des tests de montée en charge et surtout en volume de données... et de comparer avec les jointures. Ont-elles été prises en flagrant délit de lenteur ?

Tant qu'à faire une table plate, il y aurait peut-être moyen de coller un FULLTEXT dessus. Ce qui me fait penser que Sphinx sait indexer directement le résultat d'une requête (celle qui donne cette table par exemple), et est très efficace pour ce genre de recherches. Des recherches comme le coup du "like '%,92,%'" peuvent aussi se faire par son intermédiaire.

[Antoun]

Tant qu'à faire une table plate, il y aurait peut-être moyen de coller un FULLTEXT dessus.

+1 ! en cas de gros volume, cela permettrait d'utiliser un index adapté plutôt que de tout parcourir. Attention toutefois à la longueur minimale de quatre lettres (donc 0092 est un mot alors que 92 est ignoré).

[vodnok]

Bonjour,

Je me permet de squater le sujet vu que je m'interroge en ce moment à trouver la façon la plus adaptée à mon contexte pour réaliser un moteur de recherche.


Pour expliquer le contexte, un petit exemple

Table Actualité
Table Video
Table ...

Table Content (qui contient des champs génériques aux tables du dessus)


Table Content contiendra certainement des millions de records
Les contents sont multilangue et geolocalisé (pays-langue)
La Table Content sera certainement partitionnée (en fonction de l'anciennté et la geolocalisation)


Avant de débuter mes recherches j'avais également en tête la création d'une table de recherche ou d'utiliser la table Content pour cela.

Je compte créer un champs l_search qui contiendrait la concaténation de tous les champs sujet à une recherche

Pour actualité : titre + sous titre + text + auteur + source + lien
Pour video : tite + description + source + etc

Je mets ensuite un fulltext sur l_search.


Es-ce pour vous une bonne manière ?


Je n'ai pas encore tester cela et j'aimerais bien coupler cela au partitionnement Temporel et Geolocalisé. Mais je ne sais pas si on peut combiner fulltext et partionnement. J'aimerais que le fulltext adapte son algo (taux d'apparition, stop words) en fonction de la geolocalisation

Pour les stop word, je peux traiter avant d'executer la requête mais pour le taux d'apparition et le relevance qui y est liée je sèche...