Lucene versus SGBD

La bataille n'est pas courante... néanmoins, toute connaisseur de Nutch désireux d'employer l'indexeur Lucene dans toute sa potentialité sera confronté à la question suivante :

Quand faut-il utiliser une SGBD plutot que Lucene.

Prenons un cas concret : réaliser un compteur de "mots de recherche" pour Nutch.

Pour l'instant je m'accorde aux choses suivantes :

* Lucene est un indexeur, c'est à dire un outil permettant de retrouver au plus vite une entrée d'index associée à des données.
* MySQL (ou autres SGBD) est un système de gestion de base de données. C'est à dire un ensemble d'index englobant l'implémentation d'un ensemble d'opération sans se préoccuper des problemes sous-jacents (multi-ultisateurs, synchronisation, lecture/écriture).

A mes yeux, Lucene est théoriquement plus lent lorsque les scéances d'écriture se succèdent aux étapes de lecture. J'aurais tendance à affirmer que Lucene est un indexeur exclusivement consacré à un construction d'index suivie d'un ensemble de lecture. Ainsi, si l'on veut implémenter un outil de statistique qui incrémente une entrée de l'index à chaque fois que l'occurence est enregistrée sur le moteur, j'aurais tendance à dire que les performances devraient etre moins bonnes.

En pratique cela n' a pas vraiment l'air d'etre le cas.

Vous meme, avez vous été confronté à cet grave question existentielle : Lucene ou SGBD ?

Algorithme de Ranking à code ouvert

Certains se demandent : n'est-ce pas dangereux de présenter en open-source l'algorithme de ranking utilisé pour un moteur de recherche. Je parle ici du projet Nutch...

Sans vouloir copier Doug Cutting, voici quelques réflexions intéressantes :

• Google qui garde pourtant son algorithme secret, n'empêche pas les webmasters habiles de monter leurs rankings.
• Rien n'empêche les utilisateurs du projet Nutch de customiser l'algorithme de ranking (ce qui est chose facile) et de ne pas publier le code de cet algorithme.
• Annoncer l'algorithme, et pour peu, dans un projet open-source, permet de plus facilement les failles de la méthode employée. Cela permettra à plus long terme, d'obtenir un algorithme plus fiable, plus performant, moins influencés par les techniques diverses de boost de ranking.

En conclusion, je crois que la publication, dans le cadre du projet Nutch, est une très bonne chose.

Tutoriel de Nutch sur Frutch

Je suis inscrit désormais sur le groupe Frutch , c'est-à-dire le groupe de Nutch francophone.

Nutch est un moteur de recherche open-source plein d'avenir. La version 0.6 donnait déjà de très bon résultat, on attend avec impatience la prochaine version stable permettant de gérer pas mal de choses supplémentaires.

En matière de moteur de recherche, je pense que le projet Nutch est sans doute la meilleure chose qui soit arrivée depuis pas mal d'année.

Notons au passage que Nutch utilise l'indexeur Lucene dont le principal développeur Doug Cutting, est le principal acteur du projet Nutch.

J'ai publié ma traduction avec commentaires du tutoriel de Nutch sur le Wiki de Frutch : tutoriel de Nutch

Crawling distribué

Suite à une discussion concernant l'intérêt du crawling distribué pour un moteur de recherche voici ma réponse suite au message suivant :

En fait, ce que j'entends par crawling P2P, c'est d'utiliser un réseau
de machine pour effectuer le téléchargement des pages et en effectuer
l'indexation. En fait à bien y réfléchir, ça serait plus une approche à
la Seti@home. Le terme P2P n'est peut-être pas très approprié.

Ce qui caractérise le P2P, c'est l'indétermination de la relation client-serveur entre les pairs. Donc ici il s'agit plus généralement de technologie GRID.

L'intérêt à fetcher (télécharger) et indexer les pages est moindre : les pages que les noeuds de la grille auront indexées ainsi que leur contenu devront inévitablement être envoyé au serveur de recherche, et la bande passante gagnée sera donc reperdue... (mis à part comme l'a souligné Jerome dans l'un de ses articles, si la quantité de données envoyée au final est plus faible que la quantité engloutie par les noeuds).

Dans tous les cas, la bande passante gagnée est tellement minime que les efforts déployés pour ce faible gain sont minimes...

Pour aller dans ton sens néanmoins, je dirai que tous les grands noms du domaine des moteurs de recherche, Doug Cutting compris, sont très intéressés par une expérimentation de la chose, afin de confirmer qu'effectivement, le crawling distribué est inutile.

Maintenant, si tu étends le crawling distribué, à une recherche distribuée : tu n'as plus besoin de transférer le contenu des pages, mais uniquement tes index. Néanmoins dans ce cas, la rapidité du service de recherche est directement lié aux temps de latence des différents noeuds de recherche.

Si un noeud est très lent, certains résultats de recherche peuvent durer très longtemps. Dans tous les cas, la rapidité d'une seconde de Google ne sera jamais atteinte.

A cela on peut répondre que l'on peut dupliquer les index, mais à quel nombre ? Le système ne deviendrait que fiable à 99 % que lorsque le nombre de noeuds deviendrait très important (et le nombre de duplication également). Reste alors à implémenter des mécanismes permettant de gérer les duplications afin de lutter contre les problemes de pannes ou lenteur de noeuds.

Pour conclure sur cette dernière remarque, je dirai que tous les experts en GRID s'accordent sur une chose : là où il faut éviter les Desktop Grid (on peut les appeler des Peer to peer grid si l'on veut) c'est bien lorsqu'une fiabilité en vitesse réseau est demandée... La seule issue possible est un GRID de machine puissante, et dans ce cas là, nous nous retrouvons purement et simplement avec une architecture typiquement à la Google.

Salutations.

Christophe Noel
Information Retrieval & Grid Systems
CETIC
Charleroi, Belgique

Lucene Fuzzy Query

Cet article naît d'une incohérence déconcertante apparue lorsque j'ai utilisé pour la première fois les "fuzzy query" de Lucene.

Les fuzzy query permettent d'obtenir des résultats de recherche sur des mots "proches" les uns des autres. Le concept de proximité est issu ici de la notion de distance entre mot, correspondant à l'algorithme de Levenshtein.

Une distance de 1 entre deux mots correspond à soit un échange de lettre, un retrait ou un ajout de lettre pour passer de la premiere occurence de mot à l'autre.

La méthode FuzzyQuery(Term, float, int), permet de créer une FuzzyQuery pour un taux d'erreur donné en float, et un préfixe de longueur donné en int.

Si la longueur de préfixe est de 2, Lucene va alors parcourir tous les mots commencant par ce préfrixe et calculer les distances par rapport au terme donné.

Ce que le bouquin Lucene in action ne dit pas, c'est que le taux d'erreur de 1 - (distance / longueur de mot) n'est pas calcul sur le mot entier, mais uniquement sur le suffixe.

Ce point de détail expliquera bien des comportements anormaux constaté lors de vos premiers tests.

Nouvelle guitare folk

Ce week-end j'ai eu la joie de découvrir le son d'une magnifique guitare folk XP dans les tons d'un beau rouge bordeau. Tout ceci grâce à ma merveilleuse amoureuse à qui j'envois plein de bisous ! ;)

Vive les gammes penthatoniques et autres joyeusetés pour terminer chacune des dures journées de labeurs passées derrière les machines infernales...

Factbites : moteur encyclopédique

Factbites est un moteur de recherche basé sur une encyclopédie.

Tout d'abord, je vous recommande les commentaires d'Olivier Ertzscheid : commentaires

Ce moteur de recherche est intéressant pour les recherches encyclopédiques. Je ne m'étenderai pas sur le sujet, car je pense que son intérêt est moindre pour le domaine de la recherche.Toutefois je noterai une petite caractéristique élégante : les pages de résultats sont affichées de façon plus consistante. A la place d'un extrait ("summary") à la Google pour chaque page, trois phrases de la page HTML contenant les mots de recherche sont affichés. Ce ne sont pas des phrases choisies au hazard, mais bien des extraits sémantiquement intéressants. Au final, il est plus facile de se faire une idée des pages affichées dans les résultats.

Création

Et bien ce post sera le premier d'une sans doute longue série de commentaires au sujet de mes recherches et découverte en matière de technologies de l'information.

Le temps de me familiariser avec ce nouveau phénomène de mode qu'est le blog.