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.
Comentarios