Google cuenta con un gran número (supuestamente millones) de máquinas Linux (muy) sencillas que están configuradas y construidas a medida según las especificaciones de Google.
Cada una de estas máquinas tiene, al parecer, 8 DIMMs, dos CPUs multinúcleo y dos discos. Cada ordenador tiene también una batería interna de 12V en el lado de la corriente continua, que actúa como un SAI por máquina. Puedes consultar la plataforma de Google en Wikipedia como una buena referencia.
Desde hace años, la búsqueda es un juego de memoria RAM, con el fin de bajar las latencias lo máximo posible y con el coste de la RAM bajando constantemente.
Los tiempos de acceso al disco (tiempo inicial hasta el primer dato) son cinco órdenes de magnitud superiores a los de la RAM (milisegundos frente a decenas de nanosegundos) por lo que tener todo el índice en la RAM acelera mucho el tiempo de respuesta (aunque ni de lejos proporcionalmente).
Dadas estas prioridades, la RAM es el recurso más importante, con los discos casi lanzados como un bono 🙂
Hay un excelente conjunto de números de rendimiento dados por Jeff Dean, un compañero de Google - High Scalability - High Scalability - Numbers Everyone Should Know donde se pueden comparar estas latencias.
Así que está claro que Google depende de enormes cantidades de RAM (cientos de TB al menos en mi opinión, probablemente petabytes) pero no hay que pensar que toda esa RAM de las máquinas individuales se puede sumar simplemente. Hay latencias adicionales en cada nivel de la jerarquía que hacen que el problema sea mucho más complejo.
Cuando se necesite pasar de la RAM local de una máquina a otra, se pagará una penalización de rendimiento por el acceso a la red.
Estos retrasos adicionales pueden ser menores, si se trata de un mismo rack, en cuyo caso se pasa por un switch local top-of-rack (TOR, como los llama Google). En el caso de ir a un clúster, el retraso aumenta, y aumenta aún más si vas a una máquina fuera de tu clúster.
Además de las latencias fijas de ir a través de estos niveles de jerarquía, también hay penalizaciones por congestión debido a la cantidad de tráfico de red que decenas de miles de máquinas con mucha RAM generan comunicándose entre sí dentro de un centro de datos.
Debido a estas consideraciones, el diseño de la red dentro de un centro de datos es muy importante, se quieren tantas capas y conmutadores redundantes como sea posible, en lugar de ponerlos todos en un único 10 GigE 🙂
Luis Andre Barroso y Urs Hoelzle de Google han publicado un excelente libro, disponible en PDF, en el que se discuten estas cuestiones con gran detalle - Synthesis Lectures on Computer Architecture
Nótese que la mayoría de las máquinas de Google no se utilizan para la búsqueda, hay muchos servicios que Google ofrece que requieren más recursos. Gmail es un ejemplo de ello y es bien sabido que la publicidad es un problema computacionalmente más difícil y más intensivo en recursos que la búsqueda.
Mi opinión sería que utilizan sólo un 10% de sus máquinas para la búsqueda principal. Por supuesto, invito a la gente de Google a que me corrija en esta estimación, si está equivocada 🙂
Los avances en el rendimiento de los ordenadores siguen avanzando, aunque más en el lado del almacenamiento y de la red que en el rendimiento de la CPU.
Por ejemplo, los discos SSD son una excelente alternativa de almacenamiento con cifras de rendimiento entre la RAM y el disco, sin embargo usarlos a la escala de Google es de momento prohibitivo incluso para ellos. Sustituir millones de discos duros por unidades SSD más nuevas cada pocos años costaría cientos de millones, si no miles de millones. Los accionistas de Google no estarían muy contentos con eso 🙂
Hay empresas, como Facebook, Baidu y Blekko que ahora están usando SSDs a gran escala.