Google s'appuie sur un très grand nombre (supposément des millions) de machines Linux (très) simples qui sont configurées et construites sur mesure selon les spécifications de Google'
Chacune de ces machines disposerait de 8 DIMM, de deux CPU multicœurs et de deux disques. Chaque ordinateur dispose également d'une batterie interne de 12V sur le côté DC, agissant comme un onduleur par machine. Vous pouvez consulter la plateforme Google sur Wikipedia comme une bonne référence.
La recherche est depuis des années un jeu de mémoire vive, afin de faire baisser les latences autant que possible et avec un coût de la mémoire vive en baisse constante.
Les temps d'accès au disque (temps initial jusqu'à la première donnée) sont cinq ordres de grandeur plus élevés que ceux de la RAM (millisecondes contre dizaines de nanosecondes), donc avoir l'index entier en RAM accélère beaucoup le temps de réponse (même si c'est loin d'être proportionnel).
Vu ces priorités, la RAM est la ressource la plus importante, avec les disques presque jetés en prime 🙂
Il existe un excellent ensemble de chiffres de performance donnés par Jeff Dean, un boursier de Google - High Scalability - High Scalability - Numbers Everyone Should Know où vous pouvez comparer ces latences.
Il est donc clair que Google s'appuie sur d'énormes quantités de RAM (des centaines de To au moins IMHO, probablement des pétaoctets) mais il ne faut pas penser que toute cette RAM provenant d'individus individuels peut être simplement additionnée. Il existe des latences supplémentaires à chaque niveau de la hiérarchie qui rendent le problème beaucoup plus complexe.
Dès lors que vous devez passer de la RAM locale d'une machine à une autre, vous payez une pénalité de performance pour l'accès au réseau.
Ces délais supplémentaires peuvent être plus faibles, si vous un dans le même rack, auquel cas vous passez par un commutateur top-of-rack (TOR, comme Google les appelle) local. Dans le cas d'aller vers un cluster, le délai augmente, et il augmente encore plus si vous a allez vers une machine en dehors de votre cluster.
En plus des latences fixes de passer par ces niveaux de hiérarchie, il y a aussi des pénalités de congestion en raison de la quantité de trafic réseau que des dizaines de milliers de personnes avec beaucoup de RAM génèrent en communiquant entre elles dans un centre de données.
En raison de ces considérations, la conception du réseau au sein d'un centre de données est très importante, vous voulez autant de couches et de commutateurs redondants que possible, par opposition à simplement les mettre tous sur un seul 10 GigE 🙂
Luis Andre Barroso et Urs Hoelzle de Google ont publié un excellent livre, disponible en PDF, discutant de ces questions en détail - Synthesis Lectures on Computer Architecture
Note que la plupart des machines de Google's ne sont pas utilisées pour la recherche, il y a beaucoup de services que Google offre qui nécessitent plus de ressources. Gmail est un tel exemple et il est bien connu que la publicité est un problème plus difficile à calculer et plus gourmand en ressources que la recherche.
Mon avis serait qu'ils utilisent seulement environ 10% de leurs machines pour la recherche de base. Bien sûr, j'invite les gens de Google à me corriger sur cette estimation, si elle est erronée 🙂
Les progrès en matière de performance des ordinateurs continuent d'aller de l'avant, mais plutôt du côté du stockage et du réseau, par opposition aux performances des CPU.
Par exemple, les SSD sont une excellente alternative de stockage avec des chiffres de performance entre la RAM et le disque, cependant les utiliser à l'échelle de Google a un coût prohibitif pour l'instant même pour eux. Remplacer des millions de disques durs par des SSD plus récents tous les quelques années coûterait des centaines de millions, voire des milliards. Les actionnaires de Google ne seraient pas très heureux de cela 🙂
Il existe des entreprises, telles que Facebook, Baidu et Blekko, qui utilisent désormais les SSD à grande échelle.