Google, Facebook mm. - Hvordan?

Du forventer vel ikke at faa en kopi af source code til G eller FB?

Google har aldrig offentliggjordt hvordan deres soegemaskine virker.

Baseret paa rygter saa:
- bruger den en crawler skrevet i Python
- gemmer data i deres eget fil system (GFS)
- har al data i memory fordelt paa hundredetusinder af servere spredt ud over hele jorden
- bruger deres egen web server som via smarte algoritmer ved hvilken server der har de data som spoerges efter

FB er saa vidt vides en helt "normal" web app baseret paa PHP og MySQL.

Bare i lidt stoerre skala. De siges at have 1800 MySQL servere koerende.

Men der er ikke nogle geniale snuptags loesninger til den slags. Fornuftig infrastruktur. Fornuftig database struktur. Fornuftig SQL.

Det er muligt at du synes at optimering af indexes er kedeligt, men det er altsaa en vigtig ting for stoerre databaser.

Med databaser i FB stoerrelse er partitionering nok mindst lige saa vigtig. Men som tommelfinger regel har du ikke brug for at partitionere med <1TB data (og nu kommer DBA'erne sikker efter mig fordi det naturligvis afhaenger af data, men en tommelfinger regel er jo lige netop det).

arne_v > Nej jeg forventede ingen kildekode.

Jeg var samtidig heller ikke så interesseret i hvordan søgemaskinen virker. Men mere som du kommer ind på med "normale web-app's baseret på php & mysql".

Jeg takker derfor mange gange for forklaringen med databasen.

Men hvad med mit andet spørgsmål, har du et bud der?

Jeg er ikke helt sikker paa hvad du leder efter med spoergsmaal 2.

Beregnede data kan beregnes naar der er brug for dem eller de kan beregnes med bestemte tidsintervaller.

Det afgoerende i den sammenhaeng er vel om data skal vaere 100% uptodate hele tiden.

Hvis noget skal beregnes en gang i doegnet er cron vel helt fint. Selvom der findes alternativer.

Taet beslaeget paa denne problem stilling er spoergsmaalet om cache (i applikationen, cache i databasen er en helt anden sag). Brug af cache kan forbedre performance rigtigt meget. Men der er nogle problemer som skal haandteres lige saa snart vi taler clustering.

arne_v > Lad mig give dig et konkret eksempel..

Et brugersystem ønsker at vide noget om brugeren. Hvad han har købt, hvad han har lavet osv osv.. Systemet tjekker en masse historik igennem for således at vise det mest relevante data til brugeren når han ønsker det.

Et sådant tjek går jeg ikke ud fra skal gøres i det øjeblik en bruger ønsker at få vist noget data?

Skal disse data regnes på en gang i døgnet vha. cron? Eller hvordan fungerer det?

En saadan rapport tror jeg man vil generere on the fly.

antal brugere x antal mulige soegninger er saa stort at det vil vaere haabloest at pregenerere dem.

Hvis det vil belaste online systemet for meget, saa replikerer man data til et DWH og koerer sine rapporter mod dette.

Nogle gang emed en lidt anden tabelstruktur som er mere gearet mod rapporter.

arne_v > Hmm bare lige så vi er helt enige..

Så når brugeren "Tester13" klikker på "Køb varer", så genereres de relevante varer on-the-fly. Dette kunne foregå ved at tjekke tidligere køb, søgningener, visninger osv osv..

I mit hoved vil det komme til at køre ret tungt?

- Såfremt vi er enige nævner du DWH som en løsning, kan du kort forklare/introducere dette?

DWH er en loesning for back office brug - du vil slaa et eller andet op omkring en bruger.

Salget af groenne sodavandsis fordelt paa maaneder for de sidste 3 aar hvis det er betakt med credit card.

Ingen grund til at ramme online databasen med den slags crap.

At komme med forslag til koeb udfra brugerens hidtidige koeb vil nok normalt laves mod online databasen omend det sagtens kunne laves mod en readonly DWH lignende database.

Med et index paa bruger boer det ikke vaere saa tungt.

Naar du rammer svaervaegts klassen vil du putte den slags paa separate servere. Men indtil da kan du godt bare slaa det op.

At generere dem fra et batch job lyder ikke tiltalende for mig. Databasen bliver draebt hvis alle koeres samtidigt. Saa man skal til at have lavet noget schedulering som koerer brugerne paa forskellige tidspunkter. Lidt besvaerligt.

Og hvis brugerne logger ind 5 minutter efter at have koebt en dims vil de nok foretraekke at der vises tilbehoer til den dims.

arne_v > Jeg takker mange gange. Dine svar har været nyttige. Send venligst et svar, så du kan få dine fortjente points. Og god aften :)

svar