TL; DR:
Ils utilisent une architecture de pile avec des graphiques en cache pour tout ce qui se trouve au-dessus du bas de MySQL de leur pile.
Longue réponse:
J'ai fait des recherches à ce sujet moi-même parce que j'étais curieux de savoir comment ils gèrent leur énorme quantité de données et les recherchent rapidement. J'ai vu des gens se plaindre de la lenteur des scripts de réseaux sociaux personnalisés lorsque la base d'utilisateurs augmente. Après avoir moi-même effectué des analyses comparatives avec seulement 10 000 utilisateurs et 2,5 millions de connexions d' amis - sans même essayer de me soucier des autorisations de groupe, des likes et des publications sur le mur - il s'est rapidement avéré que cette approche était imparfaite. J'ai donc passé du temps à chercher sur le Web comment le faire mieux et je suis tombé sur cet article officiel de Facebook:
Je vous recommande vraiment de regarder la présentation du premier lien ci-dessus avant de continuer la lecture. C'est probablement la meilleure explication du fonctionnement de FB dans les coulisses que vous puissiez trouver.
La vidéo et l'article vous disent plusieurs choses:
- Ils utilisent MySQL tout en bas de leur pile
- Au - dessus de la base de données SQL se trouve la couche TAO qui contient au moins deux niveaux de mise en cache et utilise des graphiques pour décrire les connexions.
- Je n'ai rien trouvé sur le logiciel / la base de données qu'ils utilisent réellement pour leurs graphiques en cache
Jetons un coup d'œil à ceci, les connexions d'amis sont en haut à gauche:
Eh bien, c'est un graphique. :) Il ne vous dit pas comment le construire en SQL, il y a plusieurs façons de le faire mais ce site a un bon nombre d'approches différentes. Attention: Considérez qu'une base de données relationnelle est ce qu'elle est: on pense qu'elle stocke des données normalisées, pas une structure graphique. Il ne fonctionnera donc pas aussi bien qu'une base de données de graphes spécialisée.
Considérez également que vous devez faire des requêtes plus complexes que de simples amis d'amis, par exemple lorsque vous souhaitez filtrer tous les emplacements autour d'une coordonnée donnée que vous et vos amis d'amis aimez. Un graphique est la solution parfaite ici.
Je ne peux pas vous dire comment le construire pour qu'il fonctionne bien, mais cela nécessite clairement des essais et des erreurs et une analyse comparative.
Voici mon test décevant pour trouver juste des amis d'amis:
Schéma de base de données:
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;
Requête des amis d'amis:
(
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
)
Je vous recommande vraiment de créer des exemples de données avec au moins 10k enregistrements d'utilisateurs et chacun d'entre eux ayant au moins 250 connexions d'amis, puis d'exécuter cette requête. Sur ma machine (i7 4770k, SSD, 16 Go de RAM), le résultat était d' environ 0,18 seconde pour cette requête. Peut-être qu'il peut être optimisé, je ne suis pas un génie de la DB (les suggestions sont les bienvenues). Cependant, si cela évolue de manière linéaire, vous êtes déjà à 1,8 seconde pour seulement 100 000 utilisateurs, 18 secondes pour 1 million d'utilisateurs.
Cela peut sembler correct pour ~ 100 000 utilisateurs, mais considérez que vous venez de récupérer des amis d'amis et que vous n'avez pas fait de requête plus complexe comme " affichez-moi uniquement les messages d'amis d'amis d'amis + vérifiez les autorisations si je suis autorisé ou non pour voir certains d'entre eux + faire une sous-requête pour vérifier si je les ai aimés ". Vous voulez laisser la base de données vérifier si vous avez déjà aimé un message ou non ou si vous devrez le faire dans le code. Considérez également que ce n'est pas la seule requête que vous exécutez et que vous avez plus d'utilisateurs actifs en même temps sur un site plus ou moins populaire.
Je pense que ma réponse répond à la question de savoir comment Facebook a très bien conçu sa relation entre amis, mais je suis désolé de ne pas pouvoir vous dire comment la mettre en œuvre de manière à ce qu'elle fonctionne rapidement. La mise en œuvre d'un réseau social est facile mais s'assurer qu'il fonctionne bien n'est clairement pas - à mon humble avis.
J'ai commencé à expérimenter avec OrientDB pour faire les requêtes de graphes et mapper mes bords à la base de données SQL sous-jacente. Si jamais je le fais, j'écrirai un article à ce sujet.
