1. Comment se consoler quand on n’a pas d’ami mais qu’on
veut faire comme si on en avait plein en faisant genre les
amis de mes amis, même s’ils n’ont jamais vu ma tronche,
on va dire que c’est mes amis quand même ou même que
leurs amis le sont aussi dès fois que quelqu’un dont j’ai
vaguement entendu parler ait dans ses amis un ami qui
connaisse une amie qui a un jour ajouté une top-modèle
sur un site de réseau social et la top-modèle a accepté par
erreur l’invitation comme Louise Attaque et du coup je vais
pouvoir frimer en ayant peut-être le nom de la top-modèle
affiché sur ma fiche sur le site, sauf que sans ami je sais pas
qui va le voir, sauf un autre type désespéré car les réseaux
sociaux permettent de socialiser les réseaux. Ou pas.
Et vice-versa.
2. Leçons tirées de LinkedIn, Mixi et Friendster :
•Des outils permettant de mémoriser des réseaux sociaux
existent, mais en dehors d’outils développés en interne, il
ne semble pas y en avoir susceptibles de prendre en charge
de gros réseaux dynamiques.
•Les développeurs de ces sites sont des tronches. Il a
pourtant fallu 6 mois à l’équipe de développement de
Friendster pour créer la version actuelle de son “graph
server”, malgré son expérience précédente.
•Bref, c’est pas gagné.
3. LinkedIn :
“Only way to get the performance needed is to run the
algorithms on data stored in RAM!”
4. Application
Serveurs SQL (“slaves”)
Serveur de graphs Serveur de graphs Serveur de graphs
5. Application
Serveurs SQL (“slaves”)
Relai / tampon
getChangesSince(timestamp)
Serveur de graphs Serveur de graphs Serveur de graphs
7. Les allocations / libérations de mémoire :
•Elles seront très fréquentes.
•Les structures seront très petites.
•L’espace requis peut excéder la taille de la
mémoire physique.
•Tout risque de fragmentation est à éviter.
•Essayons de profiter des systèmes actuels
(caches et plusieurs coeurs).
•Ces contraintes existent déjà dans les noyaux
des systèmes d’exploitation.
•mmap() et allocations par slabs.
8.
9.
10.
11.
12.
13.
14. Un utilisateur : environ 24 octets
•UID
•Nombre de liens
•Nombre de rétroliens
•Liste de liens
•Liste de rétroliens
15. Un lien : 20 octets
762 Mo suffisent à stocker 40 millions de liens
Un lien connaît la référence du rétrolien réciproque.
Un rétrolien connaît la référence du lien réciproque.
16.
17. Pour la suppression d’un lien, on peut tirer profit des
informations dont on dispose pour trouver le moyen le
plus rapide de localiser ce lien et le rétrolien :
•La cardinalité des liens et des rétroliens d’un
utilisateur
•La référence entre un lien et son rétrolien réciproque
(et inversement)
18.
19.
20.
21.
22. Les splay-tree
Un splay-tree est un arbre de recherche qui s’auto-
optimise.
Les noeuds les plus fréquemment recherchés deviennent
les plus rapides d’accès.
23. Le marquage :
un système bien pratique pour parcourir un graphe.
24.
25.
26.
27.
28. Un marqueur simple ne permet pas de parcours sans
verrou.
Un marqueur sous forme d’une liste associée à chaque
utilisateur a un coût important (mémoire) et ne permet pas
de savoir de façon simple quels sont les goulots
d’engorgement.
29. Un splay-tree crée au fur et à mesure du parcours :
•Permet des parcours sans utiliser de verrou
•Nécessite très peu de mémoire
•Permet de connaître les goulots d’engorgement, pour
les mémoriser sous forme compressée dans un cache
partagé.
30. Code préliminaire
Générateur de graphs denses :
Chaque utilisateur a entre 8 et 128 amis directs, qui ont 1
chance sur 16 d’avoir l’utilisateur en ami réciproque.
Création du graphe jusqu’à 1000000 d’amis : 373 000
insertions par seconde.
Parcours du graphe (sérialisé), sur 3 niveaux : 79 000
recherches par seconde.
31. La distribution
•Les adresses virtuelles pourraient désigner plusieurs
machines physiques.
•Peer 2 Peer ?
http://qdbm.sourceforge.net/mikio/he-sigmodj.pdf
http://hyperestraier.sourceforge.net/nguide-en.html