TL; DR:
Ellos usan una arquitectura de pila con gráficos almacenados en caché para todo, por encima de la parte inferior de MySQL de su pila.
Respuesta larga:
Hice algunas investigaciones en este mismo porque tenía curiosidad cómo manejan su enorme cantidad de datos y la búsqueda de una manera rápida. He visto a gente quejándose de secuencias de comandos de redes sociales a medida convertirse lento cuando el número de usuarios crece. Después hice un poco de la evaluación comparativa de mí mismo con sólo 10k usuarios y 2,5 millones amigo conexiones - ni siquiera tratan de preocuparse de permisos y gustos de grupos y publicaciones en el muro - que rápidamente resultó que este enfoque es defectuoso. Así que he pasado algún tiempo buscando en la web sobre la manera de hacerlo mejor y me encontré con este artículo oficial de Facebook:
Yo realmente recomiendo que ver la presentación del primer eslabón anterior antes de seguir leyendo. Es probablemente la mejor explicación de cómo FB trabaja detrás de las escenas que se pueden encontrar.
El vídeo y el artículo se explica algunas cosas:
- Están usando MySQL en la parte inferior de su pila
- Por encima de la SQL DB no es la capa TAO que contiene al menos dos niveles de almacenamiento en caché y está utilizando gráficos para describir las conexiones.
- No pude encontrar nada de qué software / DB que realmente utilizan por sus gráficos en caché
Vamos a echar un vistazo a esto, amigos conectados son parte superior izquierda:

Bueno, esto es una gráfica. :) No te dice cómo construirlo en SQL, hay varias maneras de hacerlo, pero este sitio tiene una buena cantidad de diferentes enfoques. Atención: Tenga en cuenta que una base de datos relacional es lo que es: Se piensa para almacenar datos normalizados, no una estructura gráfica. Para que no se realice tan bueno como una base de datos gráfica especializada.
También considere que usted tiene que hacer consultas más complejas que amigos de amigos, por ejemplo cuando se desea filtrar todos los lugares en torno a una coordenada dada que usted y sus amigos de amigos como. Un gráfico es la solución perfecta aquí.
No puedo decirle cómo construir de modo que tenga un buen rendimiento pero requiere claramente un poco de ensayo y error y la evaluación comparativa.
Aquí está mi decepcionante prueba para sólo hallazgos amigos de amigos:
DB esquema:
CREATE TABLE IF NOT EXISTS `friends` (
`id` int(11) NOT NULL,
`user_id` int(11) NOT NULL,
`friend_id` int(11) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
Amigos de Amigos de consulta:
(
select friend_id
from friends
where user_id = 1
) union (
select distinct ff.friend_id
from
friends f
join friends ff on ff.user_id = f.friend_id
where f.user_id = 1
)
Realmente recomiendo que usted cree que algunos datos de la muestra con al menos 10k registros de usuarios y cada uno de ellos tiene por lo menos 250 amigos conectados y luego ejecutar esta consulta. En mi máquina (4770k i7, SSD, 16 GB de RAM) el resultado fue ~ 0,18 segundos para esa consulta. Tal vez se puede optimizar, no soy un genio DB (sugerencias son bienvenidos). Sin embargo, si esta escalas lineales ya se encuentra a 1.8 segundos por sólo 100 mil usuarios, 18 segundos para 1 millón de usuarios.
Esto todavía puede sonar OKish de ~ 100 mil usuarios pero tenga en cuenta que sólo amigos inverosímiles de amigos y no hizo ninguna consulta más compleja como " Me mostrar sólo los mensajes de amigos de amigos + hacer la comprobación de permisos si se me permite o no se permite a ver algunos de ellos + hacer una consulta sub para comprobar si me gustaba ninguno de ellos ". Desea que el PP haga la comprobación de si le gusta un puesto ya o no, o que tendrá que hacer en el código. Ten en cuenta también que esta no es la única consulta se ejecuta y que el tener más de usuarios activos al mismo tiempo en un sitio más o menos popular.
Creo que mi respuesta responde a la pregunta de cómo Facebook ha diseñado su relación amigos muy bien pero me siento que no puedo decir cómo implementar de una manera que va a funcionar rápidamente. La implementación de una red social es fácil, pero asegurándose de que no funciona bien es claramente - en mi humilde opinión.
He comenzado a experimentar con OrientDB que ver el gráfico-consultas y la cartografía de mis bordes de la base de datos SQL subyacente. Si alguna vez se haga voy a escribir un artículo sobre él.