Dans mon dernier article, j’explique que les serveurs de Google peuvent calculer des informations en 6 secondes dans 120 Go de données soit 600 000 livres parcourus pour cela. C’est l’exemple montré dans une vidéo de présentation.
Précisons les calculs.
La démonstration se base sur une requête qui compte les occurrences d’un mot dans une base de données. Le programme est simple.
Je considère qu’une page de livre contient 1000 caractères et qu’un livre comporte 200 pages. 1 caractère est stocké sur 1 octet. Un livre représente donc en 200 000 octets ou 200 Ko.
Pour arriver à 120 000 000 000 octets (ou 120 Go), il faut donc 600 000 livres multipliés par 200 000 caractères. Cela fait beaucoup de zéros.
Le calcul dure 6 secondes. Donc chaque seconde, le serveur parcourt 20 Go de données. Et incrémente un compte à chaque fois qu’il trouve le mot cherché.
Un ordinateur standard peut-il parcourir autant de données ?
Google vend le fait que eux seuls proposent de telles performances. Pourtant, il est facile d’assembler un ordinateur avec les composants nécessaires : mémoire et microprocesseur. La partie logicielle est aussi réalisable. Mais faisons le calculs.
La mémoire
Il existe plusieurs technologies pour stocker l’information. Elles se distinguent notamment selon leur bande passante, la quantité de données transmises par seconde.
La RAM (Random Access Memory)
Elle permet un accès quasi immédiat de la donnée et une bande passante largement suffisante.
Un kit de 32 Go de RAM trouvé sur LDLC à 100 € assure un accès à l’information en 20 ns (‘nano seconde’ soit 0, 000 000 002 secondes). Pour 120 Go de données, il m’en faut 4. La bande passante est de 25,6 Go/s. Les 20 Go par seconde passent largement.
Seul inconvénient de la RAM, c’est cher et cela nécessite de l’énergie en continue sinon toute l’information disparaît. Il faut 5 W pour maintenir l’information en continu. À 0,20 € le kWh, pour 4 slots de RAM soit 20 W (0,02 kW), et 8760 heures par an, cela fait 35 € d’énergie annuel.
Le SSD (Solid Slate Disc)
La version moderne du disque dur permet d’atteindre des bandes passantes de 8 Go/s. C’est en deça des 20 Go/s promises par Google.
Mais le SSD peut être monté par parallèle pour multiplier les débits. On parle de système RAID. Un tour sur LDLC pour voir si ce type d’équipement est accessible à tout un chacun. Il existe des cartes mères qui acceptent le RAID mais c’est du duplexing.
Bien exploité, on peut doubler le débit mais il faudrait au minimum le tripler. Maintenant, il est possible de poser sur ces cartes mères jusqu’à 3 disques durs M2. Par contre, le programme qui exploite ce type d’architecture doit être sympa.
Le coût est plus faible que la solution RAM : 120 € pour 1 To de données, soit 8 fois plus d’espace pour le tiers du prix. Donc 24 fois moins cher que l’option RAM. Le SSD a aussi l’avantage d’être conserver les données lorsque le système est éteint. Cela évite la phase de rechargement des données d’un autre support.
Le SSD présente des inconvénients. Il a besoin d’un bon système de ventilation au risque d’être inopérant à cause de la surchauffe liée à la lecture d’autant de données sur un si court laps de temps.
En pratique, c’est sûrement la solution retenue par les ingénieurs Google pour limiter les coûts. Ils ont les compétences pour optimiser leurs programmes à l’architecture logicielle. Mais je pense qu’ils utilisent des architectures professionnelles qui permettent d’avoir du RAID 5 sur des cartes mères professionnelles.
Le processeur
Pour la bande passante, le processeur de 13ème génération Intel Core l’a largement. Estimé à 75 Go par seconde pour de l’entrée de gamme. La question est de savoir s’il peut traiter correctement ce flux d’information.
Ou faut-il passer à la gamme au-dessus ?
Ou faut-il paralléliser les traitements ?
Un GPU serait-il mieux dans ce type de calculs ? Oui, mais il faut s’assurer que la bande passante entre la RAM et le GPU se fasse sans accroc.
Beaucoup de questions et peu de réponses techniques car mon article commence à devenir long. Mais dans l’ensemble, ce n’est pas le traitement qui posera problème.
A condition de bien l’écrire. Ce qui nous emmène à la partie logicielle.
Le logiciel
La stratégie de Google est de stocker les données en colonnes et non en ligne. Superbe idée, sûrement reprise de la logique Nosql mais cela nécessite d’associer à chaque donnée un ID unique. Ce n’est pas terrible pour la maîtrise de la taille de la base des données. Mais c’est efficace.
Tout le talent des ingénieurs de Google est d’optimiser l’accès aux informations entre le support et le processeur. Chaque quantité de CPU et de mémoire économisée, ce sont des milliers de dollars en énergie gagnés.
Le logiciel ne s’arrête pas là puisqu’il autorise l’application d’outils statistiques sur les modèles de données. Une pincée d’intelligence artificielle permettrait aussi d’extraire des connaissances au travers de règles SQL.
Je pense que de tels outils existent dans le domaine du libre, mais les combiner, les maîtriser, ce n’est pas à la portée de tout le monde. Les centres de recherche qui emploie des centaines d’informaticiens spécialisés peuvent se le permettre.
Qui sait si quelqu’un ne proposera pas de tels outils accessibles depuis Github.
Conclusion
Pour un budget supportable par un individu et donc par une petite entreprise, si on accepte d’attendre 3 secondes au lieu d’une, il est possible de traiter autant de données d’un coup. Pour un budget semi-professionnel, il est possible d’arriver au même niveau que Google.
Mais cela pose 2 interrogations :
- A-t’on les compétences techniques et le temps de mettre en place un tel système ?
- A-t’on besoin de parcourir 100 000 livres par seconde dans la vie de tous les jours ?
C’est là que se pose Google en proposant un service qui fait la même chose pour moins d’un centime par utilisation. Quelques requêtes par jour ne devraient pas vous ruiner …