mboost-dp1

Facebook

Sådan håndteres 300 millioner brugere

- Via Technology Review - , redigeret af Net_Srak

I sidste uge kunne stifteren af Facebook, Mark Zuckerberg, oplyse, at der nu var 300 millioner brugere på den sociale netværkstjeneste. Hos hjemmesiden Technology Review har man haft fat i teknisk ansvarlig hos Facebook, Mike Schroepfer, for at høre, hvordan de har lavet et system, der kan klare de mange brugere.

Tallene bag Facebook afslører, at der håndteres meget data, ved spidsbelastninger vises op til 1,2 millioner billeder i sekundet. Set som hjemmeside er Facebook utaknemmelig, idet næsten hver enkelt side, der vises, er unik, hvorfor cachede sider, der ellers anvendes mange steder til at øge hastigheden, er ubrugelige.

Til at holde styr på, hvad ens venner laver, har de udviklet en database, der afvikles fra RAM, således at svartider minimeres, gerne til under et sekund. Denne trækker på tusinde af andre databaser, der indeholder alle de andre oplysninger, der gemmes om en selv, venner og venners venner.

Facebook indeholder verdens største samling af billeder, hvilket har givet helt unikke udfordringer til lagring af disse. I starten anvendte de købeløsninger, men selv med optimeringer, der gav 5-6 gange forbedringer i hastighed, var de ikke gode nok. I dag har de udviklet deres eget system, der anvender hyldevarer, som er meget hurtigere og billigere.

Schroepfer kommer i interviewet også ind på, hvordan deres system er lavet til at håndtere ændringer, som pludselig skal skaleres fra en lille testgruppe, til at 300 millioner brugere pludselig får adgang til dem.





Gå til bund
Gravatar #1 - Odyssey
22. sep. 2009 06:50
Jeg gad godt li at vide hvor stor deres DB er og hvilket udstyr det kører på :) Man kan få nogle store RAMSAN som er ideelle til disse formål men de er bestemt ikke billige.
Gravatar #2 - Nielson
22. sep. 2009 07:04
Jeg har svært ved at holde styr på en meget lille nyheds db! Kan slet ikke forstille mig hvordan de gør! :P
Gravatar #3 - p1x3l
22. sep. 2009 07:44
og jeg ved at få fat af at håndtere db´s med 10m entries -.-

håbe for dem de ik ska til at flytte det lol
Gravatar #4 - bvoid
22. sep. 2009 07:51
Jeg skal kunne håndterer op til 150m entries, som nulstilles hver 12 uge. Håber det går. Det værste er insert, da select godt må tage nogle sekunder.

Jeg er altid imponeret over sider der kan holde til så meget belastning. De har selvfølgelig også en masse resourcer og folk med meget erfaring.
Gravatar #5 - Dijkstra
22. sep. 2009 07:58
Facebook indeholder verdens største samling af billeder, hvilket har givet helt unikke udfordringer til lagring af disse. I starten anvendte de købeløsninger, men selv med optimeringer, der gav 5-6 gange forbedringer i hastighed, var de ikke gode nok. I dag har de udviklet deres eget system, der anvender hyldevarer, som er meget hurtigere og billigere.


Øh før tilpassede man noget standardsoftware og nu ... tilpasser man noget standard software?

Eller har jeg misforstået?
Gravatar #6 - Huleboeren
22. sep. 2009 07:59
At være med til at bygge og vedligeholde det bag scenerne hos Facebook skal nok se godt ud på CVet :D
Gravatar #7 - Hald
22. sep. 2009 08:06
Huleboeren (6) skrev:
At være med til at bygge og vedligeholde det bag scenerne hos Facebook skal nok se godt ud på CVet :D


Ja der er meget forskel på sætningerne:

1. På arbejdet har jeg facebooket en del

2. På facebook har jeg arbejdet en del

hehe..
Gravatar #8 - Xirg
22. sep. 2009 08:14
Eller

Jeg har lavet en del opdateringer på facebook
Gravatar #9 - XorpiZ
22. sep. 2009 08:20
Eller

Jeg har været med til at lave stresstest på facebook over en længere periode
Gravatar #10 - quadcore
22. sep. 2009 17:33
Kald mig bare fanboy, men Novell's eDirectory er super til formål som dette ..

Jeg erindrer at have set et directory med 6 mia bruger-accounts, som kunne gennemsøges på under 4 sekunder. Så vidt jeg husker, lå dette directory på 4 eller 5 servere, som var "almindelige" dobbelt-processor Pentium-III boards - dog fyldt godt op med RAM.

Med nutidens hardware kunne antallet af servere (eller søgetiden) sikkert reduceres betragteligt...

Gravatar #11 - jayjakes
22. sep. 2009 17:35
#10

af ren nysgerrighed - i hvilken sammenhæng har man brug for 6 mia bruger accounts??
Gravatar #12 - XorpiZ
22. sep. 2009 17:50
jayjakes (11) skrev:
#10

af ren nysgerrighed - i hvilken sammenhæng har man brug for 6 mia bruger accounts??


Det har Google om 5 år, når de har overtaget verden.
Gravatar #13 - DrHouseDK
22. sep. 2009 18:39
Håndteres og håndteres, hvis vi taler rent datamæssigt går det ikke ret godt for tiden, damn Facebook er blevet ustabil. :)
Gravatar #14 - quadcore
22. sep. 2009 20:40
#10: Det var en demonstration - og tallet 6 mia var blot et udtryk for, hvor mange personer der formodedes at være i live her på planeten - og således hypotetisk have en account.
Gravatar #15 - arne_v
24. sep. 2009 01:25
#0 & #1

Den artikel fortæller jo nul og niks om hvordan man håndterer 300 millioner brugere !

Men GIYF.

Baseret på diverse mere eller mindre pålidelige kilder finder man:


Web - PHP, Thrift framework for interoperability other languages
Data cache - 800 servers, 28 TB RAM, 99% cache hit rate, accessed via UDP
Image cache - 6.5 billion images, cached at Akamai, 92-99% cache hit rate
Database - MySQL, InnoDB tables, replication
DataWareHouse - Hive & Hadoop (Java based), 2 PB data
Chat system - Erlang & C++, hardware for 100 million dollar
total - 10000 servers
Gravatar #16 - arne_v
24. sep. 2009 01:30
quadcore (10) skrev:
Kald mig bare fanboy, men Novell's eDirectory er super til formål som dette ..

Jeg erindrer at have set et directory med 6 mia bruger-accounts, som kunne gennemsøges på under 4 sekunder. Så vidt jeg husker, lå dette directory på 4 eller 5 servere, som var "almindelige" dobbelt-processor Pentium-III boards - dog fyldt godt op med RAM.

Med nutidens hardware kunne antallet af servere (eller søgetiden) sikkert reduceres betragteligt...


Hvis "gennemsøges" betyder finde en bruger synes jeg ikke at 4 sekunder til at finde en record ud af 6 milliarder records lyder specielt imponerende.

Det kunne man da gøre hurtigere fra disk uden brug af cache (antal B træ niveauer * gennemsnitlig tid for at læse blok fra disk).
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login