La arquitectura de Digg

aNieto2k me ha pasado (así, sin nada, ni un comentario ¿indirecta para que traduzca? :-P) por correo el enlace a la última entrada de High Scalability que trata sobre la arquitectura de Digg.

Y es que el Martes sin ir más lejos ya mencione éste sitio por el tema de la arquitectura de Youtube. Así que allá vamos:

Digg soporta 1.2 millones de usuarios con un alto nivel de páginas vistas sedientos de información, sin embargo la arquitectura de Digg se podría definir como "simplista".

Digg funciona bajo un LAMP clásico de Linux-Apache-MySQL y PHP junto a Lucene (un motor de búsqueda de alto rendimiento de Apache), MCache 2.0 y APC.

Empezaron en el 2004 con un solo servidor con GNU/Linux, Apache 1.3, PHP 4 y MySQL 4.0 usando MyISAM como sistema por defecto para la base de datos. Ahora con 200 millones de páginas vistas al mes y 30GB de datos reparten la carga entre 100 servidores en múltiples centros de datos.

Llama la atención tanto la cantidad como que de los 100 servidores, 20 son de bases de datos, 30 para servidores web, unos pocos para Lucene y el resto para redundancia.

Ninguno de los retos de escalabilidad que han tenido que afrontar ha sido con PHP. Los mayores problemas han sido relacionados a tema de base de datos. La naturaleza ligera de PHP ha permitido mover tareas de la base de datos a PHP para mejorar la escalabilidad. Ebay hace esto mismo de forma radical. Han movido casi todo el trabajo fuera de la base de datos hacia aplicaciones, incluyendo uniones (joins), un trabajo que normalmente hace la base de datos.

Los puntos más interesantes de la parte interna de Digg son:

• Se hace balanceo de carga a la hora de enviar querys a servidores PHP.
• Se usa MySQL en una configuración maestro-esclavo.
• Los servidores de transacciones pesadas usan InnoDB.
• Los servidores de transacciones pesadas OLAP usan MyISAM.
• Al migrar de MySQL 4.1 a 5 no han notado ninguna degradación del rendimiento.
• Se usa Memcached para el cache.
• El sharding al igual que en YouTube está presente para dividir la base de datos en partes más pequeñas.
• El patrón de comportamiento de uso en Digg ayuda a escalar. Mucha gente ve la página principal y se va. Por ello el 98% de los accesos a la base de datos de Digg son lecturas. Esto permite no tener que preocuparse mucho para generar una arquitectura compleja para optimizar las escrituras, por lo tanto es mucho más fácil escalar el sitio.

La parte más interesante sin duda son algunos puntos de la sección de lecciones aprendidas:

• Afina MySQL para el motor de base de datos de tu elección. Usa InnoDB cuando necesites transacciones y MyISAM cuando no. Por ejemplo, las tablas transaccionales del master pueden usar MyISAM para los slaves de solo lectura.
• En cierto punto de la curva de crecimiento se vuelve imposible crecer añadiendo más RAM, toca crecer en arquitectura.
• La gente a menudo dice que Digg es lento. Esto es debido al uso de las -- muchas -- bibliotecas Javascript y no a la arquitectura del backend.
• Las características nuevas pueden matar el rendimiento, hay que tener cuidado en no lanzar aplicaciones que usan mucha CPU. Los ingenieros a menudo tienen muchas buenas novedades que quieren lanzar, pero estas novedades pueden arrasar con la infraestructura si no crece de forma uniforme al nuevo consumo. Es mejor dejarlas fuera hasta que el sistema pueda soportarlas.
• La capa de datos es donde más problemas de rendimiento y escalabilidad se encuentran. Y esto pasa usando Java, PHP, Ruby o inserta aquí tu lenguaje favorito.