mboost-dp1

- Forside
- ⟨
- Forum
- ⟨
- Nyheder
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.
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.
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?
At være med til at bygge og vedligeholde det bag scenerne hos Facebook skal nok se godt ud på CVet :D
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...
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...
#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:
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
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).
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.