Quelle infrastructure pour le meilleur rapport prix/performance/fiabilité ?
Par Reivilo le jeudi, janvier 11 2007, 20:21 - Infrastructure - Lien permanent
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é.
Commentaires
Ton infrastructure soufre d'un énorme défaut tu n'a pas de politique de crawl tu dit "Ces serveurs ne sont sollicités que localement par les serveurs ValizBot pour lui fournir les adresses à explorer, mettre à jour ou à découvrir" une telle approche est suicidaire car les bots vont ce mettre a faire n'importe quoi ( je parle par experience ), le mieux en fait la seul solution viable est de programmer un scheduler qui vas répartir les liens a visiter entre les bots et gérer la façon dont est fait la crawling car il y a différent mode tu peut faire du crawling basé sur les domaines ou du crawling basé sur des stats que tu as etc... le scheduler est le chef d'orchestre des robots.
tu dit aussi cela " 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."
les robots.txt au niveau gestion le mieux est de laisser chaque robots gérer les fichiers robots.txt qu'il trouve de façon indépendante biensur pour ne pas avoir a redemander a chaque fois le fichier ( et pas ce faire bannir ausi ) le mieux est de fondre la structure des fichiers dans un DBM ( je parle la encore d'expérience)
donc le meilleur système le plus scalable et le plus évolutif est d'avoir un scheduler qui envoie aux robots les pages a pomper les robots écrivent sur disque les données téléchargés (ainso que certaines informations bien utile par la suite) la une application vas lire le code html des pages télécharger puis extraire les liens et écrire des fichiers texte tout simplement contenant les liens extrait dans un second dépot qui lui est lu en permanence par le scheduler ce qui implique que celui-ci soit multithread le thread en question lit chaque fichier vérifie pour chaque url si elle n'a pas déjà été parsé si le domaine d'ou elle vient n'est pas bannie , et si elle n'est pas présente dans la base de données puis l'ajoute a la db du scheduler !!!
A coté de sa l'application lisant les ficiers html créer des "batch" si ont peut dire contenant le html biensur mais aussi un fichier xml avec des infos venant de la requete http ( code d'erreur, type mime, taille, titre, descripion etc... ) qu'elle met dans un autre dépot biensur il ne faut pas oublier de virer le html du dépot des crawler.
La une autre application le repository check sont dépot afin de dresser une liste des "batch" qui ont été créer, l'adresse des batchs est stocké dans un tableau en mémoire les indexeurs ce connecte au répository qui envoie a chacun d'eux l'adresse d'un des batchs.
La les indexeus lise leur batch et index quoi
Désolé pour l'orthographe
"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) "
effectivement mais un point important la granularité général du système ne garantie pas forcément sa performance il te faut aussi au niveau de chaque serveur partionner les tables de ta base de données de façon judicieuse. Le truc c'est qu'aucune base de données open source ne fait ce genre de chose de meme mysql est très très mauvaix quand il s'agit de traite beaucoup de donner sur du matos raisonnable (c'est un gouffre a ram et cpu), oriente toi plutot vers du sql server 2005 ou oracle mysql c'est peanuts
Concernant les serveurs matheux la encore attention déjà essaie de faire un max de calcul lors de l'indexation positions de chaque mots, TFIDF local etc...
puis il te faut la attention sa vas faire mal un serveur SQL contenant une base de données des liens le mieux est d'avoir deux niveaux d'analyse c'est a dire calculer le "pagerank" global et local(dans le domaine) de chaque document. Bon cette base de liens est exploité par un logiciel que j'ai nomé le Matrix server il créer pour chaque document sa matrice local au niveau glocal et local (le hic c'est que cela consomme énormément de puissance cpu et de mémoire ca) puis envoie chaque matrice a des serveurs plus petit mais très doué en math qui calcul les "pagerank" et insère les données dans la Rank database.