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 software ingeniør på 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 hoved TF til CS50

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

8
00:00:13,660 --> 00:00:17,010
Jeg var allerede blevet undervist
CS50 to semestre

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

10
00:00:20,700 --> 00:00:25,310
>> ALEX ALLAIN: Så faktisk gjorde jeg ikke
tage CS50, men jeg gjorde TF det to gange.

11
00:00:25,310 --> 00:00:29,050
Når som en almindelig TF,
og så min senior år

12
00:00:29,050 --> 00:00:32,520
Jeg var faktisk leder TF af
CS50, som var en masse sjov.

13
00:00:32,520 --> 00:00:34,270
THOMAS Carriero: So
da David nåede ud

14
00:00:34,270 --> 00:00:38,647
til mig om opsætning
Dropbox i CS50 apparatet

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

16
00:00:41,230 --> 00:00:46,270
så de fleste af vores brugere anvender enten
Windows eller Macintosh-klienter,

17
00:00:46,270 --> 00:00:50,940
men Linux, Macintosh og Windows
kunder er alle meget ens.

18
00:00:50,940 --> 00:00:55,590
>> Så hvad vi gjorde er vi pre-installeret
Dropbox Linux klient i CS50

19
00:00:55,590 --> 00:00:59,990
apparat, og det kører ligesom
alle vores andre Linux-brugere.

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

21
00:01:02,210 --> 00:01:08,590
kører som en klient på mange forskellige
operativsystemer og enheder.

22
00:01:08,590 --> 00:01:11,387
Dropbox desktop-klient er
en af ​​de mest velkendte,

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

24
00:01:12,720 --> 00:01:15,460
>> THOMAS Carriero: So Dropbox
dybest set tager alle filer

25
00:01:15,460 --> 00:01:19,500
at du lægger i den mappe og det klumper
disse filer i fire megabyte bidder.

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

27
00:01:23,270 --> 00:01:26,070
luns IT i 25 fire-megabyte bidder.

28
00:01:26,070 --> 00:01:30,670
Disse klumper krypteres og
så sender vi dem til vores blok servere.

29
00:01:30,670 --> 00:01:35,980
>> ALEX ALLAIN: Spærringen servere er
opbevaring for blokkene selv,

30
00:01:35,980 --> 00:01:39,570
og så hver blok er lagret i
blokken server med data

31
00:01:39,570 --> 00:01:43,990
og en Shaw 356 hash af denne blok.

32
00:01:43,990 --> 00:01:48,280
Det er en meget grundlæggende kryptering primitive
der opsummerer, i en vis forstand,

33
00:01:48,280 --> 00:01:53,140
data i en meget unik måde
der er unik for den pågældende data.

34
00:01:53,140 --> 00:01:55,540
>> Du kan uploade
hele filen på én gang,

35
00:01:55,540 --> 00:02:00,120
men det viser sig, hvis du gør
, at virkelig store filer tager

36
00:02:00,120 --> 00:02:03,616
en virkelig lang tid at uploade, og hvis
har du en fiasko, er du ude af lykke

37
00:02:03,616 --> 00:02:04,740
og du er nødt til at genstarte den.

38
00:02:04,740 --> 00:02:07,620
>> Hvad vi så gør, er vi fortæller
en anden server i vores system,

39
00:02:07,620 --> 00:02:11,550
og det, vi kalder metadata
server, at hey dette er en fil,

40
00:02:11,550 --> 00:02:14,200
og det er sammensat af
Følgende liste af blokke.

41
00:02:14,200 --> 00:02:17,030
Og vi passerer op hashes
at identificere de blokke

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

43
00:02:18,770 --> 00:02:20,820
Den Metaserver derefter
kontrollerer blok servere,

44
00:02:20,820 --> 00:02:22,153
gør sikker på 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 godt.

47
00:02:24,040 --> 00:02:26,400
>> THOMAS Carriero: Når vi
ønsker at dybest set downloade

48
00:02:26,400 --> 00:02:30,050
filen fra internettet, så lad os
sige, at vi vil sige til den sidste Metaserver

49
00:02:30,050 --> 00:02:33,090
første, hej kan du fortælle mig
om, hvor denne fil er placeret?

50
00:02:33,090 --> 00:02:37,230
Og Metaserver vil sige, åh denne fil
faktisk 25 fire megabyte stykker,

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

52
00:02:38,210 --> 00:02:41,712
Og så vil vi gå en blok server og
faktisk hente hver af disse stykker.

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

54
00:02:43,670 --> 00:02:45,086
og så vil vi starte overførslen.

55
00:02:45,086 --> 00:02:47,580
Ja, så Dropbox af tilbud
med skala dybest set

56
00:02:47,580 --> 00:02:50,460
ved meget, meget aggressiv sharding.

57
00:02:50,460 --> 00:02:56,400
>> ALEX ALLAIN: sharding er, når du
tage alle brugere i din opstart

58
00:02:56,400 --> 00:03:00,010
eller din virksomhed og måske de
bruges til at være i en database,

59
00:03:00,010 --> 00:03:02,620
og det virker fint, indtil du
ramme et bestemt antal brugere.

60
00:03:02,620 --> 00:03:04,578
Og virkelig, hvad du ønsker
at gøre, er at finde en måde

61
00:03:04,578 --> 00:03:07,410
at splitte dem på tværs af to
databaser, eller måske mere end to.

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

63
00:03:10,830 --> 00:03:13,080
>> Og så når du shard,
hvad du skal gøre er du

64
00:03:13,080 --> 00:03:16,830
finde en måde at afgøre
hvilken database til at gå

65
00:03:16,830 --> 00:03:20,240
at der ikke kræver
rammer en central bibliotek.

66
00:03:20,240 --> 00:03:23,670
Eller måske er det en meget hurtig,
billige look-up central bibliotek.

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

68
00:03:27,189 --> 00:03:28,980
fordi det er næsten
aldrig kommer til at skalere.

69
00:03:28,980 --> 00:03:33,970
Så i stedet for, hvad vi vil gøre, er at tage alle
at oplysninger, alle de filer,

70
00:03:33,970 --> 00:03:36,610
er gemt på metadata,
shard på tværs af hundredvis

71
00:03:36,610 --> 00:03:38,710
eller tusindvis af logiske databaser.

72
00:03:38,710 --> 00:03:42,900
Og det betyder, at når vi har en
anmode om en brugers oplysninger,

73
00:03:42,900 --> 00:03:46,890
Vi vil først sige, hey hvilken database
denne brugers information gemt i?

74
00:03:46,890 --> 00:03:49,852
Så vil vi dybest set
bruge beslutningen om at gå

75
00:03:49,852 --> 00:03:51,560
finder, at databasen
og det er, hvor vi vil

76
00:03:51,560 --> 00:03:55,080
indlæse alle de filer eller alle
metadata om filerne.

77
00:03:55,080 --> 00:03:56,464
>> Så vi bruger en masse sharding.

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

79
00:03:57,880 --> 00:04:00,380
Du er faktisk nødt til at cache
en masse af de fælles anmodninger

80
00:04:00,380 --> 00:04:04,010
fordi selv dem database
forespørgsler kan være dyrt

81
00:04:04,010 --> 00:04:07,570
så gør vi også aggressive fanger
strategier for at gøre sikker på, at den mest

82
00:04:07,570 --> 00:04:10,310
fælles anmodninger
ganske let at beregne.

83
00:04:10,310 --> 00:04:14,630
Og dybest set, der gør en masse
hurtigere og det gør det arbejde ex skala.

84
00:04:14,630 --> 00:04:17,320
Så det er på et meget
højt niveau hvordan Dropbox virker.

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 hedder Thomas Carriero.

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

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