scalability - ver - que paso con facebook 2018
¿Cómo calculan las actualizaciones de amigos los sitios web de redes sociales? (4)
El sitio web de redes sociales probablemente mantenga mesas para usuarios, amigos y eventos ...
¿Cómo utilizan estas tablas para calcular eventos de amigos de una manera eficiente y escalable?
La principal estructura de datos de los sitios de redes sociales es el graph . En Facebook, el gráfico no está dirigido (cuando eres amigo de alguien, eres amigo). En Twitter, el gráfico está dirigido (Sigues a alguien, pero no necesariamente te siguen).
Las dos formas populares de representar gráficos son las listas de adyacencia y las matrices de adyacencia .
Una lista de adyacencia es simplemente una lista de bordes en el gráfico. Considere un usuario con un ID de usuario entero.
User1, User2
1 2
1 3
2 3
La interpretación no dirigida de estos registros es que el usuario 1 es amigo de los usuarios 2 y 3 y el usuario 2 también es amigo del usuario 3.
Representar esto en una tabla de base de datos es trivial. Estamos familiarizados con la tabla de unión de muchas a muchas relaciones. Las consultas SQL para encontrar amigos de un usuario en particular son bastante fáciles de escribir.
Ahora que conoce a los amigos de un usuario en particular, solo necesita unir esos resultados a la tabla de actualizaciones. Esta tabla contiene todas las actualizaciones del usuario indexadas por ID de usuario.
Siempre que todas estas tablas estén correctamente indexadas, le resultaría muy fácil diseñar consultas eficientes para responder a las preguntas que le interesan.
Muchos de los sitios de redes sociales como Twitter no usan RDBMS en absoluto, sino una aplicación de Message Queue. Muchos de ellos comienzan con una aplicación ya presente como RabbitMQ. Algunos de ellos se vuelven lo suficientemente grandes como para personalizarlos o construirlos. Twitter está en proceso de hacer esto por segunda vez.
Una aplicación de cola de mensajes funciona al mantener mensajes de un servicio para uno o más servicios. Por ejemplo, digamos que el servicio Frank está publicando mensajes en una cola foo. Joe y Jill están suscritos a Franks foo queue. la aplicación mantendrá un registro de si Joe o Jill han recibido o no los mensajes y una vez que cada suscriptor de la cola ha recibido el mensaje, lo descarta. Frank dispara mensajes y se olvida de ello. Joe y Jill le piden mensajes a Foo y reciben cualquier mensaje que aún no hayan recibido. Joe y Jill hacen lo que tienen que hacer con el mensaje. Tal vez mantenerlo alrededor tal vez no.
La aplicación de cola de mensajes garantiza que todos los que deben recibir el mensaje pueden recibirlo y lo recibirán cuando lo soliciten. El editor puede enviar los mensajes con la seguridad de que el suscriptor puede obtenerlos eventualmente. Esto tiene la ventaja de ser completamente asíncrono y no requerir uniones costosas.
EDITAR: Debería mencionar también que generalmente el almacenamiento para este tipo de cosas a gran escala está muy desnormalizado. Así que Joe y Jill pueden estar almacenando una copia del mismo mensaje exacto. Esto se considera correcto porque ayuda a que la aplicación se amplíe a miles de millones de usuarios.
Otra lectura:
Para la pequeña escala, una unión en users.friends y users.events y el caché de consultas probablemente esté bien, pero se ralentiza bastante rápido a medida que crecen los amigos y los eventos. También puede probar un modelo basado en eventos en el que cada vez que un usuario crea un evento se crea una entrada en una tabla de unión (tal vez llamada "friends_events"). Por lo tanto, cada vez que un usuario desea ver qué eventos han creado sus amigos, simplemente puede hacer una unión entre su propia ID y la tabla friends_events y descubrirlo. De esta manera, evitará atrapar a todos los usuarios con amigos y luego unirse a sus amigos con la tabla de eventos.
Travis escribió un gran post sobre esto,