Notas sobre la arquitectura de Linkedin

Una de las sesiones más jugosas de la pasada QCon 2007 fue la que presentaba la arquitectura de Linkedin. He hecho un pequeño resumen de la información que se puede encontrar en la presentación de Jean-Luc Vaillant, CTO y cofundador de la web.

Pongo aquí algunas notas que se pueden extraer de las transparencias muy al estilo High Scalability.

• 16 millones de miembros. Más de 1 millón de nuevos miembros por mes. Teniendo en cuenta que la web salió al público en 2003 habrá que asumir que esa tendencia se produce en los últimos meses.


• 50% de miembros son de fuera de los Estados Unidos.


• 30% de los miembros acceden a su cuenta cada mes. Sería interesante saber un dato sobre miembros activos cada día.


• 180 empleados.


• Da beneficios desde el 2006. Este dato también es bastante interesante.



• Principalmente es código Java, y también algo de C++ y Ruby.


• El sistema de producción es Unix (Solaris), y el de desarrollo es Mac OS X


• Oracle 10g para bases de datos críticas. MySQL para el resto.


• Utilizan Spring, ActiveMQ, Tomcat, Jetty y Lucene.



• Los diferentes algoritmos sociales ejecutados no funcionan demasiado bien BD. La única forma de obtener un buen rendimiento es ejecutándolos en memoria.


• Las aplicaciones y los diferentes grafos en memoria se sincronizan con la base de datos utilizando un algoritmo propio (databus) implementado sobre funcionalidades propias de Oracle. Tuvieron problemas con otras aproximaciones tradicionales como JMS o multicast que derivaban en el problema de commit en dos fases.


• Ese databus lo han implementado sobre HTTP con balanceo de carga. Hay un pool de trabajadores que acceden a base de datos para no sobrecargarla con demasiadas peticiones. Ningún cliente accede directamente a la base de datos.


• El sistema de caché es aparentemente propio. No nombran ningún producto en concreto.


• Índices especializados para consultas concretas


• Los diferentes motores de grafos son entidades en si mismas. Tienen un servidor RPC por el que reciben peticiones, varios sistemas para ejecutar algoritmos, un motor de persistencia para almacenar datos en disco y una librería de acceso al databus.


• Problemas al implementar el patrón de bloqueo read/write. 100% CPU. Problema: si una lectura lleva demasiado tiempo, la escritura tiene que esperar y bloquea al resto de lecturas. La solución fue migrar a un algoritmo copy-on-write.


• Determinadas redes crecen demasiado. Solución: comprimirlas para poder seguir manteniéndolas en memoria.

Nota: Justo después de escribir esto, he visto que alguien ha escrito también sobre ello.