Valiz : Moteur de recherche open-source

Aller au contenu | Aller au menu | Aller à la recherche

Mot clé - serveur

Fil des billets - Fil des commentaires

dimanche, octobre 19 2008

Compte-rendu de la discussion jabber du 18 octobre 2008

J'ai été invité par le salon exalead de JabberFR à venir discuter de Valiz et plus généralement du principe d'un moteur de recherche open-source. Cela s'est donc déroulé hier, samedi 18 octobre 2008 de 20h30 à 22h30. J'ai décidé d'en faire un compte-rendu ici ce qui permet de faire le point sur l'état du projet mais aussi d'informer les absents.

L'indexation et le contenu

Nous avons parlé de la cible de Valiz, le contenu accessible. Indexer uniquement des sites pleinement conformes aux recommandation sur l'accessibilité est illusoire, il y en a trop peu. Mieux vaut se concentrer sur des sites faisant des efforts d'accessibilité.

Un moteur modulaire

L'intérêt d'un moteur de recherche modulaire a été souligné. Ce lui assure son évolution, lui permet d'évoluer dynamiquement. Cela permet également d'interfacer beaucoup d'outils au travers d'API.

BOINC et le calcul distribué

Une des faiblesse de Valiz sera sa faible infrastructure hardware comme nos moyens seront forcément limités. Une idée avancée lors de cette discussion était de sous-traiter des calculs à une plate-forme de calcul distribué via BOINC par exemple. Une partie du travail pourrait ainsi être traité en-dehors des serveurs de Valiz. Il ne s'agirait évidemment pas de calcul en temps réel mais plutôt de traitements de l'index, d'analyse de contenu, etc...

Faire participer les universités

Une autre idée qui a été proposé est de soumettre Valiz, ou du moins certains modules aux universités qui ont les moyens de le faire avancer et de mettre des serveurs à disposition. C'est probablement le chemin le plus plausible pour que Valiz devienne réalité.

Le site de Valiz

Le blog

Plusieurs personnes ont critiqué le blog comme support de discussion pour les débats. Ce n'est pas un support adapté, il devrait plutôt être utilisé pour faire des annonces sur l'avancement du projet. Ce n'est pas faux.

La page d'accueil

Cette page n'est pas suffisamment compréhensible, elle prête à confusion. Surtout la partie en anglais qui est du pure massacre (issu de Google Translate), il faudrait au minimum que je la réécrive. Je pense plutôt la remplacer par une explication beaucoup plus concise et mettrait en avant le blog et le wiki.

Le wiki

Beaucoup étaient de l'avis que le wiki était la forme la plus adaptée au projet. Il y en avait déjà un en place, un Dokuwiki. Mais il semblerait qu'il y ait besoin de quelque chose de plus costaud pour notamment y intégrer les discussions. C'est pourquoi je vais remplacer le Dokuwiki par un Mediawiki très prochainement.

Structure et cadre du projet

J'ai profité de la discussion pour situer le cadre de Valiz. Il s'agit d'un projet bénévole entretenu par des passionnés. Valiz sera un des projets de l'association Texuma, une association à but non-lucratif dont l'objectif et de faciliter le développement de projets software ou touchant à internet.

Le budget et la publicité

Le thème de la publicité a été abordé également. Allons-nous intégrer de la publicité dans les résultats des recherches ? Non évidemment. Pourquoi ?
Proposer de la publicité sur une page souhaitant présenter du contenu accessible dans ses résultats implique que la publicité aboutisse également vers des sites accessibles. Et si le site visé par la publicité était accessible, il figurerait naturellement en bonne place dans les résultats et n'aurait donc pas à payer. Par ailleurs le but de Valiz n'est pas lucratif.
Évidemment ça ne rend pas les choses simples pour autant, un moteur de recherche a besoin d'importantes ressources hardware (serveurs, baies, bande passante, switchs, routeurs ,spares, etc...) ce qui est extrêmement onéreux. Évidemment une partie du budget pourrait être constituée de dons, mais il faudrait avoir une popularité similaire à Wikipedia pour que ce soit significatif.
Même si cela reste un point capital, je préfère ne pas trop m'y attarder tant que nous n'avons pas un cahier des charges concret et réaliste.

Et maintenant ?

Vous êtes plus que jamais invité à continuer de débattre. Valiz n'est pas mort et cherche à avoir un maximum de contributeurs pour discuter du cahier des charges. Il n'y a pas besoin de compétences particulières, être un utilisateur d'un moteur de recherche suffit amplement pour dire ce qui nous manque, comment on veut obtenir l'information, ce qui ne va pas avec les résultats, etc... Pour cela je vais mettre en place le wiki sous quelques jours.
Comme l'expérience était concluante, il n'est pas impossible que de nouvelles discussions de ce type aient lieu, que ce soit sur le salon d'exalead ou ailleurs. L'idéal à moyen terme serait de réunir les personnes intéressées sur un salon dédié permanent. Le log complet de la discussion

lundi, janvier 29 2007

Réflexion sur une architecture externe

Le fait

Je l'ai déjà dit assez souvent, mais ça ne fait pas de mal de le répéter : un moteur de recherche, ça prend des ressources, beaucoup de ressources (humaines et systèmes). Des serveurs puissants sont requis, et il en faut en nombre pour garantir un minimum de réactivité pour l'indexation et la prise en compte de modification.

Contribuer efficacement

Valiz visant le 100% open-source (donc gratuit, libre, aucun profit financier, etc..., le financement de ces serveurs sera un beau problème, j'espère que les dons en couvriront une partie et peut-être même qu'un ou plusieurs partenaires seront intéressés à soutenir le projet (financièrement ou matériellement).
Pour l'infrastructure, j'en avait déjà vaguement parlé dans un précédent article, mais j'ai eu récemment une autre idée : créer une architecture atome Pourquoi atome ? Parce que ça y ressemble :

  • Un noyau avec les bases de données et serveurs pour les résultats à la volée. C'est toujours le noyau qui affiche le résultat.
  • Des électrons qui gravitent autour du noyau : des serveurs (ou plus précisément des ressources serveurs) mises à disposition par des particuliers, entreprise ou autre association qui désire soutenir Valiz et qui auraient un ou plusieurs serveurs qui tournent à vide ou presque.

Serveur électron

(Le nom sert juste de lien avec l'atom, c'est juste un modèle, un nom plus convenable sera probablement trouvé).
Ces serveurs font le lien entre le web et le noyau, ils peuvent servir de ValizBot (en mode indexation, mise à jour,... ou encore 100% réservé à son site) ou de générateur de cache (mise à jour des requêtes populaires, pré-formatage,...),. Cela permet non seulement d'alléger la charge du noyau, mais également d'augmenter de manière proportionnel à sa popularité sa réactivité.

Problème de sécurité

Valiz est open-source et facilement modifiable, mais il ne faut en aucun cas que les paramètres d'indexation et autres critères puissent être modifiés extérieurement. Un serveur satellite signifie un accès au noyau ainsi que des accès sql (très limités), pour éviter des problèmes, il sera impératif de valider les accès un par un avec vérification des intentions de la personne souhaitant contribuer.
Ensuite vient le problème de l'environnement installé sur le serveur permettant d'exécuter ValizBot ou autre générateur de cache. Il ne faut surtout pas qu'il soit en langage interprété (beaucoup trop facilement modifiable par le propriétaire pour avantager ses sites ou injecter n'importe quoi dans les bases de données. Je pense qu'un langage compilé comme le C++ a davantage sa place. Ensuite il faut simplifier la mise à jour. Pour ça, je pense à une gestion par paquet binaire (dpkg et rpm) et pour ce qui est de l'auhentification, l'astuce reste à trouver (probablement sous la forme d'un clef).

Conclusion

Je pense que ce concept pourrait donner pas mal de potentiel à Valiz, néanmoins sa conception devra faire face à énormément de défis. Qu'en pensez-vous ?

jeudi, janvier 11 2007

Quelle infrastructure pour le meilleur rapport prix/performance/fiabilité ?

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é.