Google si basa su un numero enorme (presumibilmente milioni) di (molto) semplici macchine Linux che sono configurate e costruite su misura secondo le specifiche di Google.
Ognuna di queste macchine ha 8 DIMM, due CPU multi-core e due dischi. Ogni computer ha anche una batteria interna da 12V sul lato DC, che agisce come un UPS per macchina. Potete controllare la piattaforma di Google su Wikipedia come un buon riferimento.
La ricerca è da anni ormai un gioco di RAM, al fine di abbassare il più possibile le latenze e con il costo della RAM che scende costantemente.
I tempi di accesso al disco (tempo iniziale al primo dato) sono cinque ordini di grandezza superiori alla RAM (millisecondi contro decine di nanosecondi) quindi avere l'intero indice in RAM accelera molto il tempo di risposta (anche se non in modo proporzionale).
Viste queste priorità, la RAM è la risorsa più importante, con i dischi quasi buttati dentro come bonus 🙂
C'è un'eccellente serie di numeri di performance dati da Jeff Dean, un collega di Google - High Scalability - High Scalability - Numbers Everyone Should Know dove si possono confrontare queste latenze.
Quindi è chiaro che Google si basa su enormi quantità di RAM (centinaia di TB almeno IMHO, probabilmente petabyte) ma non si dovrebbe pensare che tutta quella RAM dalle singole macchine possa essere semplicemente sommata. Ci sono latenze aggiuntive ad ogni livello della gerarchia che rendono il problema molto più complesso.
Ogni volta che è necessario passare dalla RAM locale di una macchina ad un'altra, si paga una penalità di prestazioni per l'accesso alla rete.
Questi ritardi aggiuntivi possono essere minori, se si va nello stesso rack, nel qual caso si passa attraverso uno switch locale top-of-rack (TOR, come li chiama Google). Nel caso di andare in un cluster, il ritardo aumenta, e aumenta ancora di più se si sta andando verso una macchina al di fuori del proprio cluster.
In cima alle latenze fisse di passare attraverso questi livelli di gerarchia, ci sono anche penalità di congestione a causa della quantità di traffico di rete che decine di migliaia di macchine con un sacco di RAM generano comunicando tra loro all'interno di un data-center.
A causa di queste considerazioni, la progettazione della rete all'interno di un data-center è molto importante, si desidera avere quanti più livelli e switch ridondanti possibile, al contrario di metterli tutti su un singolo 10 GigE:)
Luis Andre Barroso e Urs Hoelzle di Google hanno pubblicato un eccellente libro, disponibile in PDF, che discute questi problemi in grande dettaglio - Synthesis Lectures on Computer Architecture
Nota che la maggior parte delle macchine di Google non sono usate per la ricerca, ci sono molti servizi che Google offre che richiedono più risorse. Gmail è un esempio ed è noto che la pubblicità è un problema computazionalmente più difficile e che richiede più risorse della ricerca.
Io credo che usino solo circa il 10% delle loro macchine per la ricerca principale. Naturalmente, invito la gente di Google a correggermi su questa stima, se è sbagliata 🙂
I progressi nelle prestazioni dei computer continuano ad andare avanti, anche se più sul lato dello storage e della rete rispetto alle prestazioni della CPU.
Per esempio, gli SSD sono un'eccellente alternativa di archiviazione con numeri di prestazioni tra la RAM e il disco, tuttavia usarli sulla scala di Google è costo-proibitivo per ora anche per loro. Sostituire milioni di dischi rigidi con SSD più recenti ogni pochi anni costerebbe centinaia di milioni, se non miliardi. Gli azionisti di Google non sarebbero molto contenti di questo 🙂
Ci sono aziende, come Facebook, Baidu e Blekko che stanno usando gli SSD su larga scala.