1
00:00:00,000 --> 00:00:00,409

2
00:00:00,409 --> 00:00:01,950
THOMAS Carriero: Jeg er Thomas Carriero.

3
00:00:01,950 --> 00:00:03,640
Jeg er en programvareingeniør hos Dropbox.

4
00:00:03,640 --> 00:00:05,250
>> ALEX ALLAIN: Jeg er Alex Allain.

5
00:00:05,250 --> 00:00:08,200
Jeg er en ingeniør her på Dropbox.

6
00:00:08,200 --> 00:00:11,320
>> THOMAS Carriero: Ja, jeg var
faktisk den første lederen TF for CS50

7
00:00:11,320 --> 00:00:13,660
da David Malin tok over klassen.

8
00:00:13,660 --> 00:00:17,010
Jeg hadde allerede vært undervisning
CS50 for to semestre

9
00:00:17,010 --> 00:00:20,700
med Mike Smith, som var
tidligere professor der.

10
00:00:20,700 --> 00:00:25,310
>> ALEX ALLAIN: Så jeg faktisk gjorde ikke
ta CS50, men jeg gjorde TF den to ganger.

11
00:00:25,310 --> 00:00:29,050
En gang som en vanlig TF,
og deretter mitt siste år

12
00:00:29,050 --> 00:00:32,520
Jeg var faktisk hodet TF av
CS50, som var mye moro.

13
00:00:32,520 --> 00:00:34,270
THOMAS Carriero: Så
når David nådde ut

14
00:00:34,270 --> 00:00:38,647
til meg om å sette opp
Dropbox i CS50 apparatet,

15
00:00:38,647 --> 00:00:41,230
Jeg var veldig spent, fordi
vi har faktisk en Linux-klient,

16
00:00:41,230 --> 00:00:46,270
slik at de fleste av våre brukere bruker enten
Windows eller Macintosh-klienter,

17
00:00:46,270 --> 00:00:50,940
men Linux, Macintosh og Windows
klienter er alt faktisk veldig like.

18
00:00:50,940 --> 00:00:55,590
>> Så det vi gjorde er vi forhåndsinstallert
Dropbox Linux-klienten i CS50

19
00:00:55,590 --> 00:00:59,990
apparatet, og det går akkurat som
alle våre andre Linux-brukere.

20
00:00:59,990 --> 00:01:02,210
>> ALEX ALLAIN: Så
måte Dropbox fungerer er det

21
00:01:02,210 --> 00:01:08,590
Kjører som en klient på mange forskjellige
operativsystemer og enheter.

22
00:01:08,590 --> 00:01:11,387
Dropbox desktop klient er
en av de mest kjente,

23
00:01:11,387 --> 00:01:12,720
og en av de mest interessante.

24
00:01:12,720 --> 00:01:15,460
>> THOMAS Carriero: Så Dropbox
utgangspunktet tar alle filene

25
00:01:15,460 --> 00:01:19,500
som du putter i den mappen og det biter
disse filene inn i fire megabyte biter.

26
00:01:19,500 --> 00:01:23,270
Så får vi ta en 100-megabyte
PDF-fil, og vi vil

27
00:01:23,270 --> 00:01:26,070
blings det inn 25 fire-megabyte biter.

28
00:01:26,070 --> 00:01:30,670
De biter blir så kryptert og
Da vi sende dem til våre blokk servere.

29
00:01:30,670 --> 00:01:35,980
>> ALEX ALLAIN: Blokken servere er
lagring for blokkene selv,

30
00:01:35,980 --> 00:01:39,570
og slik at hver blokk er lagret i
blokken server med dataene

31
00:01:39,570 --> 00:01:43,990
og en Shaw 356 hash av den blokken.

32
00:01:43,990 --> 00:01:48,280
Det er en helt grunnleggende kryptering primitive
som oppsummerer, i en viss forstand,

33
00:01:48,280 --> 00:01:53,140
dataene i en meget unik måte
som er unikt for disse dataene.

34
00:01:53,140 --> 00:01:55,540
>> Du kan laste opp
hele filen på en gang,

35
00:01:55,540 --> 00:02:00,120
men det viser seg hvis du gjør
det, egentlig store filer tar

36
00:02:00,120 --> 00:02:03,616
en virkelig lang tid å laste opp, og hvis
du har en fiasko, er du ute av lykken

37
00:02:03,616 --> 00:02:04,740
og du må starte den.

38
00:02:04,740 --> 00:02:07,620
>> Det vi da gjør er vi fortelle
en annen server i systemet vårt,

39
00:02:07,620 --> 00:02:11,550
og hva vi kaller metadata
server, hei dette er at en fil,

40
00:02:11,550 --> 00:02:14,200
og det er sammensatt av
følgende liste over blokker.

41
00:02:14,200 --> 00:02:17,030
Og vi passerer opp hashes
å identifisere disse blokkene

42
00:02:17,030 --> 00:02:18,770
snarere enn re-opplasting
hele blokken.

43
00:02:18,770 --> 00:02:20,820
Den metaserver deretter
kontrollerer blokk servere,

44
00:02:20,820 --> 00:02:22,153
gjør at blokkene er der.

45
00:02:22,153 --> 00:02:23,140
Hvis de er, perfekt.

46
00:02:23,140 --> 00:02:24,040
Alt er bra.

47
00:02:24,040 --> 00:02:26,400
>> THOMAS Carriero: Når vi
vil i utgangspunktet laste ned

48
00:02:26,400 --> 00:02:30,050
filen fra internett, la oss
si, vi vil si til den siste metaserver

49
00:02:30,050 --> 00:02:33,090
første, hei kan du fortelle meg
om hvor denne filen ligger?

50
00:02:33,090 --> 00:02:37,230
Og metaserver vil si, oh denne filen
faktisk 25 fire-megabyte biter,

51
00:02:37,230 --> 00:02:38,210
og her er de.

52
00:02:38,210 --> 00:02:41,712
Og så skal vi gå en blokk server og
faktisk laste ned hver av de biter.

53
00:02:41,712 --> 00:02:43,670
Og så får vi rekonstruere
filen derfra,

54
00:02:43,670 --> 00:02:45,086
og så får vi starte nedlastingen.

55
00:02:45,086 --> 00:02:47,580
Ja, så Dropbox avtaler
med skala i utgangspunktet

56
00:02:47,580 --> 00:02:50,460
av svært, svært aggressiv sharding.

57
00:02:50,460 --> 00:02:56,400
>> ALEX ALLAIN: Sharding er når du
ta alle brukerne i din starter opp

58
00:02:56,400 --> 00:03:00,010
eller din bedrift og kanskje de
benyttes til å være i en database,

59
00:03:00,010 --> 00:03:02,620
og som fungerer bra til du
treffer et visst antall brukere.

60
00:03:02,620 --> 00:03:04,578
Og egentlig hva du vil
å gjøre er å finne en måte

61
00:03:04,578 --> 00:03:07,410
å splitte de over to
databaser, eller kanskje mer enn to.

62
00:03:07,410 --> 00:03:10,830
Ideelt sett, nok til at du kan
har hver bruker i verden.

63
00:03:10,830 --> 00:03:13,080
>> Og så når du glasskår,
hva du gjør er du

64
00:03:13,080 --> 00:03:16,830
finne en måte å avgjøre
hvilken database for å gå

65
00:03:16,830 --> 00:03:20,240
I tillegg krever
treffer en sentral katalog.

66
00:03:20,240 --> 00:03:23,670
Eller kanskje det er en veldig rask,
billig look-up sentral katalog.

67
00:03:23,670 --> 00:03:27,189
>> THOMAS Carriero: Vi har aldri
alt som er lagret i en database,

68
00:03:27,189 --> 00:03:28,980
fordi det er nesten
aldri kommer til å skalere.

69
00:03:28,980 --> 00:03:33,970
Så i stedet, hva vi vil gjøre er å ta alle
denne informasjonen, alle filene som

70
00:03:33,970 --> 00:03:36,610
er lagret på metadataene,
glasskår på tvers av hundrevis

71
00:03:36,610 --> 00:03:38,710
eller tusenvis av logiske databaser.

72
00:03:38,710 --> 00:03:42,900
Og det betyr at når vi har en
be om en brukers informasjon,

73
00:03:42,900 --> 00:03:46,890
Vi vil først si, hei hvilken database
er denne brukerens informasjon som er lagret i?

74
00:03:46,890 --> 00:03:49,852
Da skal vi i utgangspunktet
bruke at beslutningen om å gå

75
00:03:49,852 --> 00:03:51,560
finne den databasen
og det er der vi vil

76
00:03:51,560 --> 00:03:55,080
laste alle filene eller alt
metadata om filene.

77
00:03:55,080 --> 00:03:56,464
>> Så vi bruker mye sharding.

78
00:03:56,464 --> 00:03:57,880
Men sharding er ikke alltid nok.

79
00:03:57,880 --> 00:04:00,380
Du er faktisk trenger å cache
mange av de vanlige forespørsler,

80
00:04:00,380 --> 00:04:04,010
fordi selv de database
spørringer kan bli dyrt

81
00:04:04,010 --> 00:04:07,570
så vi også gjøre aggressive fange
strategier for å sørge for at de mest

82
00:04:07,570 --> 00:04:10,310
vanlige forespørsler er
ganske lett å beregne.

83
00:04:10,310 --> 00:04:14,630
Og i utgangspunktet som gjør mye
raskere, og det gjør det fungerer ex skala.

84
00:04:14,630 --> 00:04:17,320
Så det er på et svært
høyt nivå hvordan Dropbox fungerer.

85
00:04:17,320 --> 00:04:19,149
>> ALEX ALLAIN: Jeg er Alex Allain.

86
00:04:19,149 --> 00:04:20,857
>> THOMAS Carriero: Og
Jeg er Thomas Carriero.

87
00:04:20,857 --> 00:04:22,579
ALEX ALLAIN: Og dette er CS50.

88
00:04:22,579 --> 00:04:23,936