Valiz : Moteur de recherche open-source

Catégories de serveurs

Dans l'infrastructure de Valiz je vois...

• Les serveurs SQL exploités par ValizBot (liste d'attente, résultats de l'exploration,..)
• Les serveurs pour nourrir ValizBot
• Les serveurs matheux qui traitent les résultats obtenus par ValizBot pour pré-formater les résultats et autres algorithmes
• Les serveurs SQL utilisés pour construire les requêtes
• Les serveurs Web qui assemblent les résultats SQL et/ou issus du cache
• Les serveurs de cache
• Les annexes (serveurs dns, mail, load balancing, monitoring, backup,...)

Bref, c'est toute une famille à concevoir et il faut surtout que ce soit totalement modulable afin de simplifier l'évolution : agrandissement, changement de mode de fonctionnement, ...

On regarde de plus près...

À présent que les catégories de serveurs composants l'infrastructure sont définies, examinons le tout de plus près.

Serveurs SQL de ValizBot

Ces serveurs ne sont sollicités que localement par les serveurs ValizBot pour lui fournir les adresses à explorer, mettre à jour ou à découvrir, il y a d'une part cette liste, mais aussi les résultats des sitemaps, robots.txt et autre, et d'autre part l'index brut : tout ce qui est retenu par ValizBot. Ces bases sont donc énormes mais relativement peu sollicitées.
Au début, cette catégorie pourrait être réunie sur un gros serveur, mais par la suite elle serait probablement répartie sur un ou plusieurs gros NFS (pour cet usage, du SATA II suffirait) avec un gros serveur maître.

Serveurs pour ValizBot

Valiz sera conçu de manière à pouvoir disposer de plusieurs ValizBot simultanément sur la toile. La limite concernant le nombre provient principalement de la catégorie précédente. Ces serveurs n'ont pas besoin de beaucoup de puissance.

Serveurs matheux

Ces serveurs seront en quelque sort le cerveau de Valiz, et un cerveau ça réfléchit vite et avec une bonne mémoire svp ! Ils se servent dans le serveur SQL de ValizBot, traitent les données et les renvoies aux serveurs SQL des requêtes après épluchage.

Serveurs SQL

Là évidemment, plus c'est fort mieux ça, il faudrait également des disques puissants (10 ou 15 krpm), je pense à du SAS/SCSI ou encore à du raptor... Je pense que pour de bonnes performances il faut exploiter plusieurs serveurs par requête sql (il me semble que Google exploite 1000 nodes par requête). Chaque serveur aurait une petite tranche de l'index (10-50 go) et se chargerait de traiter ses données pour les mettre en commun avec les autres par la suite. Il me semble que pgtool fait cela, je vais encore me documenter. Ces serveurs servent également pour tous les services externes proposés par Valiz.

Serveurs Web

C'est la face visible de l'infrastructure pour les utilisateurs : le site (interface de recherche et documentation). Ces serveurs mettent en forme les données récupérées et les affiches. Ils exploitent avant tout le cache et sinon envoie et récupère les données des serveurs sql. Si le cache de la requête n'existe pas ils le crée et le place sur les serveurs de cache.

Serveurs de cache

Comme toutes les autres catégories, il faudra explorer à fond la configuration, mais ça pourrait se résumer à un NFS.

Serveurs annexes

Ces serveurs ne sont pas des bêtes de puissance, mais sont indispensables au fonctionnement de Valiz.

Conclusion

C'était une première ébauche simplifiée de l'infrastructure possible de Valiz, les valeurs fondamentales devraient être : fiabilité, performances et évolutivité.
Bien sûr, tout dépend des moyens à disposition et du succès rencontré.

Calculer les résultats pour une requête requiert beaucoup de ressources, il serait suicidaire d'appliquer un calcul en temps réel pour chaque requête. Même les plus grands moteurs ne font pas du calcul instantané (et si plus est la base est de 8 milliards de pages...).
Comment économiser les ressources tout en restant le plus possible à jour ?

• Diminuer l'étendue de la recherche en séparant par thématique et autres flags attribués lors de l'indexation
• Effectuer des calculs de pertinence permanents en arrière-plan
• Générer de manière autonome les requêtes courantes
• Mettre en cache les requêtes effectuées
• Calcul instantané basé sur les requêtes proches en cache ?
• etc...

Mais à quelle fréquence mettre à jour le cache ? On pourrait établir des niveaux de popularités/fréquence de nouveautés et ainsi faire des mises à jour toutes les 24/48h voir une fois par semaine. Mais le plus important serait probablement un cache intelligent :

• Mise à jour lorsque de nouveaux résultats détectés comme pertinents sont ajoutés ou mis à jour dans l'index
• Requêtes chaudes (actualité, débats, évènement) où les informations évoluent très rapidement : donc mise à jour très fréquentes

Un autre domaine à examiner serait la catégorie actualité des résultats, je pense que le plus pertinent serait de se baser sur les flux rss (pour avoir le plus récent sans avoir à aller le chercher avec valizbot) et cette sous-catégorie serait gérée indépendamment du cache ou alors bénéficierait d'un cache séparé (reconstruit selon le même principe).
Dans la même lancée, nous pourrions nous interroger sur la fréquence de mise à jour par valizbot, la solution la plus simple de se baser sur le couple sitemaps/lastmod, mais ce concept est encore très peu utilisé et souvent de manière incorrecte. Mais ceci fera l'objet d'un autre article...