1
00:00:00,000 --> 00:00:04,969
>> [Muzikos grojimo]

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: Visos dešinę.

3
00:00:06,010 --> 00:00:06,600
Labas visiems.

4
00:00:06,600 --> 00:00:07,670
Mano vardas yra Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Aš vyresnysis pagrindinis
sprendimai architektas AWS.

6
00:00:10,330 --> 00:00:14,070
Aš sutelkti dėmesį į NoSQL ir
DynamoDB technologijos.

7
00:00:14,070 --> 00:00:16,930
Aš čia šiandien kalbėti
Jūs šiek tiek apie tuos.

8
00:00:16,930 --> 00:00:18,970
>> Mano fonas
visų pirma duomenų sluoksnis.

9
00:00:18,970 --> 00:00:21,390
Aš praleido pusę savo plėtrą
Karjera raštu duomenų bazę,

10
00:00:21,390 --> 00:00:25,930
prieigos prie duomenų, sprendimai
įvairių programų.

11
00:00:25,930 --> 00:00:30,000
Aš jau Cloud Virtualizacija
apie 20 metų.

12
00:00:30,000 --> 00:00:33,460
Taigi prieš Cloud buvo Cloud
mes naudojome jį pavadinti naudingumo skaičiavimo.

13
00:00:33,460 --> 00:00:37,170
Ir idėja buvo, tai kaip
PG & E, jūs mokate už tai, ką naudojate.

14
00:00:37,170 --> 00:00:38,800
Šiandien mes jį vadiname debesis.

15
00:00:38,800 --> 00:00:41,239
>> Bet per tuos metus aš dirbau
už įmonių pora

16
00:00:41,239 --> 00:00:42,530
jūs tikriausiai niekada girdėjote apie.

17
00:00:42,530 --> 00:00:47,470
Bet aš parengė techninių sąrašą
pasiekimus, manau, norite pasakyti.

18
00:00:47,470 --> 00:00:51,620
Turiu aštuonias patentų Cloud sistemos
Virtualizacija, mikroprocesorius dizainas,

19
00:00:51,620 --> 00:00:54,440
kompleksas renginys apdorojimo,
ir kitose srityse, taip pat.

20
00:00:54,440 --> 00:00:58,290
>> Taigi šių dienų, aš daugiausia orientavosi į NoSQL
technologijas ir naujos kartos

21
00:00:58,290 --> 00:00:59,450
duomenų bazė.

22
00:00:59,450 --> 00:01:03,370
Ir tai dažniausiai ką aš ruošiuosi
būti čia su jumis kalbėti šiandien apie tai.

23
00:01:03,370 --> 00:01:06,030
Taigi, ką jūs galite tikėtis
iš šios sesijos

24
00:01:06,030 --> 00:01:08,254
mes eiti per trumpas
Istorija duomenis.

25
00:01:08,254 --> 00:01:10,420
Jis visada naudinga
suprasti, kur mes atėjo iš

26
00:01:10,420 --> 00:01:12,400
ir kodėl mes, kur mes esame.

27
00:01:12,400 --> 00:01:15,600
Ir mes kalbame šiek tiek
tiek apie NoSQL technologijos

28
00:01:15,600 --> 00:01:17,500
iš pagrindinių požiūriu.

29
00:01:17,500 --> 00:01:19,870
>> Mes patekti į kai kuriuos
kad DynamoDB vidinės.

30
00:01:19,870 --> 00:01:24,350
DynamoDB yra AWS anketa Nr skonio.

31
00:01:24,350 --> 00:01:27,340
Tai visiškai valdoma ir
Patalpinta NoSQL sprendimas.

32
00:01:27,340 --> 00:01:32,420
Ir mes kalbame šiek tiek apie stalo
struktūra, API, duomenų tipai, indeksai,

33
00:01:32,420 --> 00:01:35,177
o kai kurie iš vidinės
tos DynamoDB technologija.

34
00:01:35,177 --> 00:01:37,760
Mes patekti į kai kuriuos dizaino
modeliai ir geriausia praktika.

35
00:01:37,760 --> 00:01:39,968
Mes kalbame apie tai, kaip
naudoja šią technologiją kai

36
00:01:39,968 --> 00:01:41,430
šiandienos programas.

37
00:01:41,430 --> 00:01:44,820
Ir tada mes kalbame šiek tiek
apie evoliucijos arba atsiradimas

38
00:01:44,820 --> 00:01:48,980
naujos paradigmos programavimo
vadinamas įvykiu pagrįsti prašymai

39
00:01:48,980 --> 00:01:51,580
ir kaip DynamoDB vaidina tuo, kad taip pat.

40
00:01:51,580 --> 00:01:54,690
Ir mes palikti jums šiek tiek
nuoroda architektūra diskusijos

41
00:01:54,690 --> 00:01:59,540
todėl mes galime kalbėti apie kai
būdų, kaip galite naudoti DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Taigi, pirmiausia off-- tai klausimas
Girdžiu daug yra, kas duomenų bazę.

43
00:02:04,116 --> 00:02:06,240
Daug žmonių galvoja, kad jie
žinau, kas yra duomenų bazė yra.

44
00:02:06,240 --> 00:02:08,360
Jei Google, pamatysite tai.

45
00:02:08,360 --> 00:02:11,675
Tai struktūrinė duomenų rinkinys vyksta
į kompiuterį, ypač vienas, kad

46
00:02:11,675 --> 00:02:13,600
yra prieinama įvairiais būdais.

47
00:02:13,600 --> 00:02:16,992
Aš manau, kad tai geras
apibrėžimas modernią bazę.

48
00:02:16,992 --> 00:02:19,450
Bet man nepatinka tai, nes
tai reiškia keletą dalykų.

49
00:02:19,450 --> 00:02:20,935
Tai reiškia, struktūrą.

50
00:02:20,935 --> 00:02:23,120
Ir tai reiškia, kad ji kompiuteryje.

51
00:02:23,120 --> 00:02:25,750
Ir duomenų bazių nebuvo
visada egzistuoja kompiuteriuose.

52
00:02:25,750 --> 00:02:28,020
Duomenų bazės tikrųjų egzistavo įvairiais būdais.

53
00:02:28,020 --> 00:02:32,000
>> Taigi geriau apibrėžimas
duomenų bazė yra kažkas panašaus į tai.

54
00:02:32,000 --> 00:02:34,786
Yra organizuotas duomenų
mechanizmas saugoti, valdyti,

55
00:02:34,786 --> 00:02:35,910
ir išrinkti informaciją.

56
00:02:35,910 --> 00:02:36,868
Tai iš About.com.

57
00:02:36,868 --> 00:02:42,080
Taigi man patinka tai, nes ji tikrai kalba
apie duomenų bazė yra saugykloje,

58
00:02:42,080 --> 00:02:44,800
iš saugyklos
informacija, nebūtinai

59
00:02:44,800 --> 00:02:46,780
kažkas, kad sėdi ant kompiuterio.

60
00:02:46,780 --> 00:02:49,290
Ir per visą istoriją, mes
ne visada turėjo kompiuterius.

61
00:02:49,290 --> 00:02:52,110
>> Dabar, jei aš prašau vidurkį
kūrėjas šiandien kas

62
00:02:52,110 --> 00:02:54,770
duomenų bazė, tai atsakymas man.

63
00:02:54,770 --> 00:02:56,070
Kažkur galiu klijuoti medžiagą.

64
00:02:56,070 --> 00:02:56,670
Teisė?

65
00:02:56,670 --> 00:02:58,725
Ir tai tiesa.

66
00:02:58,725 --> 00:02:59,600
Bet tai gaila.

67
00:02:59,600 --> 00:03:02,700
Kadangi duomenų yra tikrai
šiuolaikinės app pamatas.

68
00:03:02,700 --> 00:03:04,810
Tai pamatai
apie kiekvieną paraišką.

69
00:03:04,810 --> 00:03:07,240
Ir kaip jums sukurti, kad
duomenų, kaip jūs struktūrizuoti

70
00:03:07,240 --> 00:03:11,750
kad duomenys ketina diktuoti, kaip kad
taikymas atlieka kaip jūs mastelį.

71
00:03:11,750 --> 00:03:14,640
>> Taigi mano darbas šiandien daug
yra susijusios su tuo, ką

72
00:03:14,640 --> 00:03:17,180
atsitinka, kai kūrėjai
šio požiūrio

73
00:03:17,180 --> 00:03:19,510
ir susijusius su padariniais
Paraiškos, kad

74
00:03:19,510 --> 00:03:24,966
dabar mastelio už originalą
ketinimų ir kenčia nuo blogo dizaino.

75
00:03:24,966 --> 00:03:26,840
Taigi, tikiuosi, kai jūs
pėsčiomis šiandien, jums

76
00:03:26,840 --> 00:03:29,010
turėti įrankių pora
Jūsų diržo, kad bus jus

77
00:03:29,010 --> 00:03:32,566
nuo priėmimo tuos pačius klaidų.

78
00:03:32,566 --> 00:03:33,066
Gerai.

79
00:03:33,066 --> 00:03:36,360
Taigi pakalbėkime apie šiek tiek
iš duomenų bazių technologija tvarkaraštis.

80
00:03:36,360 --> 00:03:38,830
Manau, kad skaityti
Straipsnis ne taip seniai,

81
00:03:38,830 --> 00:03:43,020
ir ji sakė kažką apie lines--
tai labai poetiška pareiškimas.

82
00:03:43,020 --> 00:03:46,590
Jis sakė, kad istorija
Duomenų tvarkymas

83
00:03:46,590 --> 00:03:49,350
pilnas aukštų vandens ženklais
duomenų gausą.

84
00:03:49,350 --> 00:03:49,920
GERAI.

85
00:03:49,920 --> 00:03:52,532
Dabar, aš manau, kad tai rūšies tiesa.

86
00:03:52,532 --> 00:03:54,990
Bet aš iš tikrųjų pažvelgti į tai, kaip
istorija iš tikrųjų yra užpildytas

87
00:03:54,990 --> 00:03:56,820
su aukštos vandenženkliui duomenų slėgiui.

88
00:03:56,820 --> 00:04:00,040
Kadangi duomenų tarifą
Prarijus niekada krinta.

89
00:04:00,040 --> 00:04:01,360
Tai tik pakyla.

90
00:04:01,360 --> 00:04:03,670
>> Ir inovacijos atsiranda, kai
matome duomenų spaudimą, kuris

91
00:04:03,670 --> 00:04:07,825
yra duomenų kiekis, kuris yra
dabar ateina į sistemą.

92
00:04:07,825 --> 00:04:12,027
Ir jis negali būti apdoroti
efektyviai vienu metu arba sąnaudų.

93
00:04:12,027 --> 00:04:14,110
Ir tai, kai mes pradedame
ieškoti duomenų spaudimą.

94
00:04:14,110 --> 00:04:15,920
>> Taigi, kai mes žiūrime ne
pirmoji duomenų bazė, šis

95
00:04:15,920 --> 00:04:17,180
yra vienas, kad buvo tarp mūsų ausų.

96
00:04:17,180 --> 00:04:18,310
Mes visi gimė su juo.

97
00:04:18,310 --> 00:04:19,194
Tai gražus duomenų.

98
00:04:19,194 --> 00:04:21,110
Ji turi aukštą prieinamumą.

99
00:04:21,110 --> 00:04:21,959
Tai visada.

100
00:04:21,959 --> 00:04:23,930
Jūs visada galite jį gauti.

101
00:04:23,930 --> 00:04:24,890
>> Bet tai vienas vartotojas.

102
00:04:24,890 --> 00:04:26,348
Aš negaliu pasidalinti savo mintimis su jumis.

103
00:04:26,348 --> 00:04:28,370
Jūs negalite gauti savo mintimis
kai norite juos.

104
00:04:28,370 --> 00:04:30,320
Ir jų abilitiy yra ne taip gerai.

105
00:04:30,320 --> 00:04:32,510
Mes pamirštame dalykų.

106
00:04:32,510 --> 00:04:36,540
Kas dabar ir tada, vienas iš mūsų lapai
ir pereina į kitą egzistencijos

107
00:04:36,540 --> 00:04:39,110
ir mes prarasti viską
kad buvo toje duomenų bazėje.

108
00:04:39,110 --> 00:04:40,640
Taigi tai dar ne viskas, kad geras.

109
00:04:40,640 --> 00:04:43,189
>> Ir tai gerai dirbo per tam tikrą laiką
kai mes buvome atgal per dieną

110
00:04:43,189 --> 00:04:46,230
kai visi mes tikrai reikia žinoti, yra
kur mes ketiname eiti rytoj

111
00:04:46,230 --> 00:04:49,630
arba kai mes renkame geriausią maistą.

112
00:04:49,630 --> 00:04:52,820
Bet kaip mes pradėjo augti kaip
civilizacija ir Vyriausybė pradėjo

113
00:04:52,820 --> 00:04:55,152
ateiti į būties ir
įmonės pradėjo vystytis,

114
00:04:55,152 --> 00:04:57,360
mes pradėjome suvokti, mes
reikia šiek tiek daugiau nei

115
00:04:57,360 --> 00:04:58,210
galėtume įdėti mūsų galvos.

116
00:04:58,210 --> 00:04:58,870
Gerai?

117
00:04:58,870 --> 00:05:00,410
>> Mums reikėjo sistemas įrašo.

118
00:05:00,410 --> 00:05:02,220
Mums reikia vietos, kad būtų galima saugoti duomenis.

119
00:05:02,220 --> 00:05:05,450
Taigi mes pradėjo rašyti dokumentus,
kurti bibliotekas ir archyvus.

120
00:05:05,450 --> 00:05:08,000
Mes pradėjo kurti
A sistema knygos apskaita.

121
00:05:08,000 --> 00:05:12,200
Ir kad Didžiosios knygos skaičiavimo sistema
bėgo pasaulį daugelį šimtmečių,

122
00:05:12,200 --> 00:05:15,580
o gal net tūkstantmečius kaip
mes rūšies išaugo iki taško,

123
00:05:15,580 --> 00:05:18,420
kur tie duomenys apkrova pranoko
šių sistemų gebėjimas

124
00:05:18,420 --> 00:05:19,870
gebėti jį apriboti.

125
00:05:19,870 --> 00:05:22,070
>> Ir tai iš tiesų nutiko 1880.

126
00:05:22,070 --> 00:05:22,570
Teisė?

127
00:05:22,570 --> 00:05:24,390
Per 1880 JAV surašymas.

128
00:05:24,390 --> 00:05:26,976
Tai tikrai kur tekinimo
atkreipti modernią duomenis.

129
00:05:26,976 --> 00:05:28,850
Tai yra ne taškas
kurioje duomenų kiekis

130
00:05:28,850 --> 00:05:32,060
kuri buvo surinkta, padarytais
JAV vyriausybė gavo iki taško

131
00:05:32,060 --> 00:05:34,005
kur jis paėmė aštuonerius metus apdoroti.

132
00:05:34,005 --> 00:05:36,350
>> Dabar, aštuoni years-- kaip
žinote, surašymą

133
00:05:36,350 --> 00:05:39,180
kursuoja kiekvieną 10 years-- todėl
gana akivaizdu, kad laiko mes

134
00:05:39,180 --> 00:05:41,419
gavo 1890 surašymą,
duomenų kiekis, kad

135
00:05:41,419 --> 00:05:43,210
ketino būti tvarkomi
vyriausybės buvo

136
00:05:43,210 --> 00:05:46,335
ketina viršyti 10 metų, kad jame
būtų imtis, kad atidarė naują surašymo.

137
00:05:46,335 --> 00:05:47,250
Tai buvo problema.

138
00:05:47,250 --> 00:05:49,000
>> Taigi vyrukas vardu Hermanas
Hollerith atėjo kartu

139
00:05:49,000 --> 00:05:52,640
ir jis išrado vieneto rekordinį Punch
kortelės, Punch kortelės skaitytuvas, perfokortų

140
00:05:52,640 --> 00:05:58,420
Tabulator, o lyginimas
už šios technologijos mechanizmai.

141
00:05:58,420 --> 00:06:01,860
Ir tai kompanija, kuri subūrė ne
laikas, kartu su kitų, pora,

142
00:06:01,860 --> 00:06:05,450
iš tikrųjų tapo vienu iš A statramsčių
maža įmonė žinome šiandien vadinama IBM.

143
00:06:05,450 --> 00:06:08,417
>> Taigi IBM pradžių buvo
duomenų bazė verslas.

144
00:06:08,417 --> 00:06:09,750
Ir tai tikrai tai, ką jie padarė.

145
00:06:09,750 --> 00:06:11,110
Jie padarė duomenis.

146
00:06:11,110 --> 00:06:15,400
>> Kaip todėl Punch platinimu
kortelės, An originalių mechanizmai

147
00:06:15,400 --> 00:06:18,560
kad galėtų išnaudoti, kad
technologija apklausti surūšiuotas rezultatas rinkinius.

148
00:06:18,560 --> 00:06:20,726
Jūs galite pamatyti šiame paveikslėlyje
ten mes turime little--

149
00:06:20,726 --> 00:06:23,970
tai šiek tiek small-- bet jūs galite pamatyti
labai išradinga mechaninis mechanizmas

150
00:06:23,970 --> 00:06:26,970
kur mes turime Punch kortelės denio.

151
00:06:26,970 --> 00:06:28,720
Ir kažkieno paėmimas
šiek tiek atsuktuvas

152
00:06:28,720 --> 00:06:31,400
ir gyvuos per
lizdai ir kėlimo jį

153
00:06:31,400 --> 00:06:34,820
gauti, kad rungtynės, kad
rūšiuojami rezultatai nustatyti.

154
00:06:34,820 --> 00:06:36,270
>> Tai agregacija.

155
00:06:36,270 --> 00:06:38,690
Mes tai visą laiką
šiandien į kompiuterį,

156
00:06:38,690 --> 00:06:40,100
kur tai padaryti duomenų bazėje.

157
00:06:40,100 --> 00:06:41,620
Mes naudojome tai padaryti rankiniu būdu, tiesa?

158
00:06:41,620 --> 00:06:42,994
Žmonės įdėti šiuos dalykus kartu.

159
00:06:42,994 --> 00:06:45,440
Ir tai buvo proliferacija
Šių Punch korteles

160
00:06:45,440 --> 00:06:50,070
į tai, ką mes vadinami duomenų būgnai
ir duomenų ritės, popieriaus juosta.

161
00:06:50,070 --> 00:06:55,980
>> Duomenų perdirbimo pramonė buvo
pamoka iš grotuvo fortepijonams.

162
00:06:55,980 --> 00:06:57,855
Žaidėjo fortepijonams atgal
iš amžių sandūroje

163
00:06:57,855 --> 00:07:02,100
jį naudoti popierinius rites su grioveliais
nuo pasakyti, kuri klavišus žaisti.

164
00:07:02,100 --> 00:07:05,380
Taigi, kad technologija buvo pritaikyta
galiausiai saugoti skaitmeninius duomenis,

165
00:07:05,380 --> 00:07:08,070
nes jie gali įdėti, kad duomenis
ant tų popieriaus juosta ritės.

166
00:07:08,070 --> 00:07:10,870
>> Dabar, kaip rezultatas, duomenų
buvo actually-- kaip

167
00:07:10,870 --> 00:07:14,960
jums prieigą šie duomenys buvo tiesiogiai
priklauso nuo to, kaip įrašėte ją.

168
00:07:14,960 --> 00:07:17,825
Taigi, jei aš įdėti duomenis į vaizdajuostę,
Aš turėjau prieiti prie duomenų tiesiškai.

169
00:07:17,825 --> 00:07:20,475
Turėjau sukite visą
juosta prieiti prie visų duomenis.

170
00:07:20,475 --> 00:07:22,600
Jei aš įdėti duomenis Punch
kortelės, galėčiau jį pasiekti

171
00:07:22,600 --> 00:07:26,270
Šiek tiek daugiau atsitiktinių
mada, o gal ir ne taip greitai.

172
00:07:26,270 --> 00:07:30,770
>> Bet ten buvo ribojami, kaip mes
prieiga prie duomenų pagal tai, kaip buvo saugomi.

173
00:07:30,770 --> 00:07:32,890
Ir taip, tai buvo problema
vyksta į '50s.

174
00:07:32,890 --> 00:07:37,890
Vėlgi, mes galime pradėti rodyti, kad mes
kurti naujas technologijas apdoroti

175
00:07:37,890 --> 00:07:41,670
duomenys, tiesa, ji atveria
už naujų sprendimų durys,

176
00:07:41,670 --> 00:07:45,852
naujų programų, nauja
paraiškos dėl šių duomenų.

177
00:07:45,852 --> 00:07:47,810
Ir tikrai, valdymas
galėjo būti priežastis,

178
00:07:47,810 --> 00:07:49,435
kodėl mes sukūrė kai kurie iš šių sistemų.

179
00:07:49,435 --> 00:07:52,290
Tačiau verslo greitai tapo
vairuotojas už evoliuciją

180
00:07:52,290 --> 00:07:54,720
Šiuolaikinės duomenų bazės ir
modernus failų sistema.

181
00:07:54,720 --> 00:07:56,870
>> Taigi kitas dalykas, kad
atėjo buvo '50s

182
00:07:56,870 --> 00:08:00,780
buvo failų sistema ir
plėtra laisvosios kreipties saugojimui.

183
00:08:00,780 --> 00:08:02,050
Tai buvo gražus.

184
00:08:02,050 --> 00:08:06,230
Dabar, visi staiga, mes galime įdėti mūsų
failus kur šių kietieji diskai

185
00:08:06,230 --> 00:08:09,760
ir mes galime pasiekti šiuos duomenis atsitiktinai.

186
00:08:09,760 --> 00:08:11,950
Galime apdoroti, kad
informaciją iš failų.

187
00:08:11,950 --> 00:08:14,920
Ir mes išspręsti visų pasaulio
problemos su duomenų tvarkymu.

188
00:08:14,920 --> 00:08:17,550
>> Ir tai truko apie 20 ar
30 metų, kol evoliucija

189
00:08:17,550 --> 00:08:22,100
iš reliacinės duomenų bazės, kuri
yra kai pasaulis nusprendė dabar

190
00:08:22,100 --> 00:08:27,940
reikia turėti saugyklą, kad nugali
duomenų plėtra visoje failą

191
00:08:27,940 --> 00:08:29,540
sistemos, kad mes pastatyti. Teisė?

192
00:08:29,540 --> 00:08:34,270
Per daug duomenų platinami per daug
vietos, de-dubliavimo duomenų,

193
00:08:34,270 --> 00:08:37,120
ir laikymo kaina buvo didžiulė.

194
00:08:37,120 --> 00:08:43,760
>> Per 70-ųjų, pats brangiausias šaltinis
kad kompiuteris buvo, saugojimo.

195
00:08:43,760 --> 00:08:46,200
Procesorius buvo
žiūrima kaip fiksuota kaina.

196
00:08:46,200 --> 00:08:49,030
Kai aš pirkti langelį,
CPU daro tam tikrą darbą.

197
00:08:49,030 --> 00:08:51,960
Tai bus verpimo ar
tai tikrai dirba, ar ne.

198
00:08:51,960 --> 00:08:53,350
Tai tikrai sumažėjusių sąnaudų.

199
00:08:53,350 --> 00:08:56,030
>> Bet kas man kainuos kaip
verslas yra sandėlys.

200
00:08:56,030 --> 00:09:00,020
Jeigu aš turiu pirkti daugiau diskus Kitas
mėnesį, tai reali kaina, kurią moku.

201
00:09:00,020 --> 00:09:01,620
Ir kad saugykla yra brangus.

202
00:09:01,620 --> 00:09:05,020
>> Dabar mes Fast Forward 40 metų
ir turime kitą problemą.

203
00:09:05,020 --> 00:09:10,020
Apskaičiuoti dabar
Brangiausia išteklių.

204
00:09:10,020 --> 00:09:11,470
Saugojimo yra pigus.

205
00:09:11,470 --> 00:09:14,570
Aš turiu galvoje, mes galime eiti bet kur
debesis ir mes galime rasti pigūs saugykla.

206
00:09:14,570 --> 00:09:17,190
Bet ką aš nerandu yra pigus apskaičiuoti.

207
00:09:17,190 --> 00:09:20,700
>> Taigi šiandienos evoliucija
technologijų, duomenų bazių technologija,

208
00:09:20,700 --> 00:09:23,050
tikrai sutelktas aplink
Paskirstyta duomenų bazės

209
00:09:23,050 --> 00:09:26,960
kad ne kenčia nuo
to paties tipo skalę

210
00:09:26,960 --> 00:09:29,240
apribojimai reliacinių duomenų bazių.

211
00:09:29,240 --> 00:09:32,080
Mes kalbame šiek tiek apie
ką tai iš tikrųjų reiškia.

212
00:09:32,080 --> 00:09:34,760
>> Tačiau viena iš priežasčių, ir
vairuotojas už this-- mes

213
00:09:34,760 --> 00:09:38,290
kalbėjo apie duomenų spaudimą.

214
00:09:38,290 --> 00:09:41,920
Duomenų slėgis yra kažkas
kad diskai naujoves.

215
00:09:41,920 --> 00:09:44,610
Ir jei peržvelgsite per
per pastaruosius penkerius metus,

216
00:09:44,610 --> 00:09:48,180
tai, ką duomenų diagrama
apkrova visoje bendrojo įmonė

217
00:09:48,180 --> 00:09:49,640
atrodo per pastaruosius penkerius metus.

218
00:09:49,640 --> 00:09:52,570
>> Ir bendra taisyklė nykščio
Šie days-- jei jūs einate Google--

219
00:09:52,570 --> 00:09:55,290
yra 90%, kad duomenų, kad
mes aukštesnėje šiandien, ir tai buvo

220
00:09:55,290 --> 00:09:57,330
sukurtas per pastaruosius dvejus metus.

221
00:09:57,330 --> 00:09:57,911
GERAI.

222
00:09:57,911 --> 00:09:59,410
Dabar, tai yra ne tendencija, kad naujo.

223
00:09:59,410 --> 00:10:01,230
Tai yra tendencija, kad buvo
vakarėliai 100 metų.

224
00:10:01,230 --> 00:10:03,438
Nuo Herman Hollerith
sukūrė perfokortų,

225
00:10:03,438 --> 00:10:08,040
mes jau pastato duomenų saugyklas
ir rinkti duomenis fenomenaliai normos.

226
00:10:08,040 --> 00:10:10,570
>> Taigi per pastaruosius 100 metų,
mes matėme šią tendenciją.

227
00:10:10,570 --> 00:10:11,940
Štai nesiruošia keisti.

228
00:10:11,940 --> 00:10:14,789
Žvelgiant į ateitį, mes ketiname pamatyti
tai, jei ne pagreitinto tendencija.

229
00:10:14,789 --> 00:10:16,330
Ir jūs galite pamatyti, ką tai atrodo.

230
00:10:16,330 --> 00:10:23,510
>> Jeigu 2010 metais verslo turėjo vieną
terabaito duomenų pagal valdymo,

231
00:10:23,510 --> 00:10:27,080
šiandien tai reiškia, kad jie
valdant 6,5 petabaitus duomenų.

232
00:10:27,080 --> 00:10:30,380
Štai 6500 kartų daugiau duomenų.

233
00:10:30,380 --> 00:10:31,200
Ir aš žinau tai.

234
00:10:31,200 --> 00:10:33,292
Aš dirbu su šių įmonių kiekvieną dieną.

235
00:10:33,292 --> 00:10:35,000
Prieš penkerius metus aš
būtų pasikalbėti su įmonių

236
00:10:35,000 --> 00:10:38,260
kuris būtų kalbėti su manimi apie tai, kas skausmo
tai yra valdyti terabaitų duomenų.

237
00:10:38,260 --> 00:10:39,700
Ir jie kalba
man apie tai, kaip mes matome

238
00:10:39,700 --> 00:10:41,825
kad tai tikriausiai vyksta
būti Petabaitas arba du

239
00:10:41,825 --> 00:10:43,030
per porą metų.

240
00:10:43,030 --> 00:10:45,170
>> Tos pačios įmonės
šiandien aš susitikti su,

241
00:10:45,170 --> 00:10:48,100
ir jie su manim kalbi apie
problema ten, turintys tvarkymą

242
00:10:48,100 --> 00:10:51,440
dešimtys, 20 petabytes duomenų.

243
00:10:51,440 --> 00:10:53,590
Taigi sprogimo
duomenys pramonėje

244
00:10:53,590 --> 00:10:56,670
vairuoja milžiniškas
reikia geresnių sprendimų.

245
00:10:56,670 --> 00:11:00,980
Ir reliacinės duomenų bazės yra
tik ne gyvena iki paklausa.

246
00:11:00,980 --> 00:11:03,490
>> Ir taip ten linijinis
koreliacija tarp duomenų slėgio

247
00:11:03,490 --> 00:11:05,210
ir technikos naujovės.

248
00:11:05,210 --> 00:11:07,780
Istorija mums parodė
tai, kad, laikui bėgant,

249
00:11:07,780 --> 00:11:11,090
kiekvieną kartą, kai kiekis duomenų
kad turi būti apdorojami

250
00:11:11,090 --> 00:11:15,490
viršija sistemos pajėgumą
apdoroti ją per priimtiną laiką

251
00:11:15,490 --> 00:11:18,870
arba už priimtiną kainą,
Tada naujos technologijos

252
00:11:18,870 --> 00:11:21,080
išrado išspręsti šias problemas.

253
00:11:21,080 --> 00:11:24,090
Šios naujos technologijos,
savo ruožtu, atidaryti duris

254
00:11:24,090 --> 00:11:27,840
į kitą problemų rinkinys, kuris
yra surinkti dar daugiau duomenų.

255
00:11:27,840 --> 00:11:29,520
>> Dabar mes nesiruošia sustoti tai.

256
00:11:29,520 --> 00:11:30,020
Teisė?

257
00:11:30,020 --> 00:11:31,228
Mes neketiname sustoti tai.

258
00:11:31,228 --> 00:11:31,830
Kodėl?

259
00:11:31,830 --> 00:11:35,520
Kadangi jūs negalite žinoti viską
yra žinoti visatoje.

260
00:11:35,520 --> 00:11:40,510
Ir tol, kol mes jau gyvas,
visoje žmonijos istorijoje,

261
00:11:40,510 --> 00:11:43,440
mes visada skatino sužinoti daugiau.

262
00:11:43,440 --> 00:11:49,840
>> Taigi atrodo, kad kiekvieną colių mes einame
žemyn mokslinių atradimų keliu,

263
00:11:49,840 --> 00:11:54,620
mes dauginant duomenų kiekį
kad mums reikia apdoroti eksponentiškai

264
00:11:54,620 --> 00:11:59,920
kaip mes atskleisti vis daugiau ir daugiau ir daugiau
apie vidaus darbu gyvenime,

265
00:11:59,920 --> 00:12:04,530
apie tai, kaip visata veikia, apie
vairavimo mokslinį atradimą,

266
00:12:04,530 --> 00:12:06,440
ir šis išradimas, kad
mes darome šiandien.

267
00:12:06,440 --> 00:12:09,570
Duomenų apimtis tik
nuolat didėja.

268
00:12:09,570 --> 00:12:12,120
Taigi, kad galėtų susidoroti su
Ši problema yra milžiniškas.

269
00:12:12,120 --> 00:12:14,790

270
00:12:14,790 --> 00:12:17,410
>> Taigi, viena iš ko
mes žiūrime kaip, kodėl NoSQL?

271
00:12:17,410 --> 00:12:19,200
Kaip NoSQL išspręsti šią problemą?

272
00:12:19,200 --> 00:12:24,980
Na, reliacinės duomenų bazės,
Struktūrinių užklausų kalba,

273
00:12:24,980 --> 00:12:28,600
SQL--, kad tikrai iš konstruktas
reliacinės database-- šie dalykai yra

274
00:12:28,600 --> 00:12:30,770
optimizuotas saugojimui.

275
00:12:30,770 --> 00:12:33,180
>> Atgal į 70-ųjų, vėlgi,
diskas yra brangus.

276
00:12:33,180 --> 00:12:36,990
Atidėjinių pratybų saugojimo
įmonėje yra nesibaigiantis.

277
00:12:36,990 --> 00:12:37,490
Aš žinau.

278
00:12:37,490 --> 00:12:38,020
Aš gyvenau ją.

279
00:12:38,020 --> 00:12:41,250
Parašiau saugojimo tvarkykles
enterprised superserver įmonė

280
00:12:41,250 --> 00:12:42,470
atgal į "90s.

281
00:12:42,470 --> 00:12:45,920
Ir Esmė yra stelažai kitą
saugojimo masyvas buvo tiesiog kažkas, kad

282
00:12:45,920 --> 00:12:47,600
atsitiko kiekvieną dieną įmonėje.

283
00:12:47,600 --> 00:12:49,030
Ir ji niekada sustojo.

284
00:12:49,030 --> 00:12:52,690
Didesnio tankio saugojimo, paklausa
už didelio tankio saugojimo,

285
00:12:52,690 --> 00:12:56,340
ir efektyviau saugojimo
devices-- jis nesiliovė.

286
00:12:56,340 --> 00:13:00,160
>> Ir NoSQL yra puikus technologijų
nes jis normalizuoja duomenis.

287
00:13:00,160 --> 00:13:02,210
Ji de dublikatų duomenis.

288
00:13:02,210 --> 00:13:07,180
Ji pateikia duomenis į struktūrą, kuri
yra agnostikas, kad kiekviena prieiga modelio.

289
00:13:07,180 --> 00:13:11,600
Įvairios taikymo sritys gali smūgį
SQL duomenų bazės, paleisti ad hoc užklausas,

290
00:13:11,600 --> 00:13:15,950
ir gauti duomenis formos, kad jie
reikia apdoroti jų darbo krūvis.

291
00:13:15,950 --> 00:13:17,570
Tai skamba fantastiškai.

292
00:13:17,570 --> 00:13:21,350
Bet Esmė yra su bet
sistema, jei ji agnostikas viską,

293
00:13:21,350 --> 00:13:23,500
jis yra optimizuotas nieko.

294
00:13:23,500 --> 00:13:24,050
GERAI?

295
00:13:24,050 --> 00:13:26,386
>> Ir tai, ką mes gauname su
reliacinės duomenų bazės.

296
00:13:26,386 --> 00:13:27,510
Jis optimizuotas saugojimui.

297
00:13:27,510 --> 00:13:28,280
Tai normalizuotas.

298
00:13:28,280 --> 00:13:29,370
Tai santykinė.

299
00:13:29,370 --> 00:13:31,660
Jis remia ad hoc užklausas.

300
00:13:31,660 --> 00:13:34,000
Ir jį, ir jis svarstyklės vertikaliai.

301
00:13:34,000 --> 00:13:39,030
>> Jei man reikia gauti didesnę SQL duomenų bazės
arba galingesnis SQL duomenų bazės,

302
00:13:39,030 --> 00:13:41,090
Aš einu pirkti didesnį gabalėlį geležies.

303
00:13:41,090 --> 00:13:41,600
GERAI?

304
00:13:41,600 --> 00:13:44,940
Aš dirbau su daug klientų
kad buvo per didelių atnaujinimų

305
00:13:44,940 --> 00:13:48,340
savo SQL infrastruktūrai
sužinoti šešių mėnesių,

306
00:13:48,340 --> 00:13:49,750
jie pataikyti sienos dar kartą.

307
00:13:49,750 --> 00:13:55,457
Ir iš "Oracle" ar MSSQL atsakymas
ar kas nors kitas yra gauti didesnį langelį.

308
00:13:55,457 --> 00:13:58,540
Na, anksčiau ar vėliau, jūs negalite pirkti
didesnis langas, ir tai reali problema.

309
00:13:58,540 --> 00:14:00,080
Turime iš tikrųjų kažką pakeisti.

310
00:14:00,080 --> 00:14:01,080
Taigi, kur tai veikia?

311
00:14:01,080 --> 00:14:06,560
Jis gerai dirba neprisijungus
Google Analytics, OLAP tipo darbo krūviai.

312
00:14:06,560 --> 00:14:08,670
Ir tai tikrai, jei SQL priklauso.

313
00:14:08,670 --> 00:14:12,540
Dabar jis naudojamas šiandien daugelis interneto
sandorio apdorojimo tipo

314
00:14:12,540 --> 00:14:13,330
programos.

315
00:14:13,330 --> 00:14:16,460
Ir tai veikia tik bauda už
kai panaudojimo lygis,

316
00:14:16,460 --> 00:14:18,670
bet tai tiesiog nėra masto
taip, kad NoSQL daro.

317
00:14:18,670 --> 00:14:20,660
Ir mes kalbame šiek tiek
tiek apie tai, kodėl tai yra.

318
00:14:20,660 --> 00:14:23,590
>> Dabar, NoSQL, kita vertus,
yra daugiau optimizuotas Compute.

319
00:14:23,590 --> 00:14:24,540
GERAI?

320
00:14:24,540 --> 00:14:26,830
Tai nėra agnostikas į
prieigos modelis.

321
00:14:26,830 --> 00:14:31,620
Ar tai, ką mes vadiname de normalizuotas
konstrukcijos arba hierarchinė struktūra.

322
00:14:31,620 --> 00:14:35,000
Į reliacinės duomenų bazės duomenys
sujungtos iš kelių lentelių

323
00:14:35,000 --> 00:14:36,850
gaminti, kad jums reikia.

324
00:14:36,850 --> 00:14:40,090
Sprendimo A NoSQL duomenis į duomenų bazę
yra saugomi dokumento, kuris

325
00:14:40,090 --> 00:14:42,100
yra hierarchinės struktūros.

326
00:14:42,100 --> 00:14:45,670
Visi duomenų, kad paprastai būtų
sujungtos tarpusavyje, kad pagaminti minėtą vaizdą

327
00:14:45,670 --> 00:14:47,160
yra saugomi viename dokumente.

328
00:14:47,160 --> 00:14:50,990
Ir mes kalbame šiek tiek apie
kaip tai veikia daugelyje topų pora.

329
00:14:50,990 --> 00:14:55,320
>> Bet idėja čia yra, kad jums laikyti
Jūsų duomenys, nes šios instantiated nuomonę.

330
00:14:55,320 --> 00:14:56,410
GERAI?

331
00:14:56,410 --> 00:14:58,610
Jūs masto horizontaliai.

332
00:14:58,610 --> 00:14:59,556
Teisė?

333
00:14:59,556 --> 00:15:02,100
Jei man reikia padidinti
dydis mano NoSQL klasterį,

334
00:15:02,100 --> 00:15:03,700
Man nereikia, kad gauti didesnį langelį.

335
00:15:03,700 --> 00:15:05,200
Gaunu kitą langelį.

336
00:15:05,200 --> 00:15:07,700
Ir aš klasteris tie kartu,
ir aš galiu Shard, kad duomenis.

337
00:15:07,700 --> 00:15:10,780
Mes kalbame tiek apie
kas sharding yra, būti

338
00:15:10,780 --> 00:15:14,270
sugebėti masto, kad duomenų bazės
keliose fizinių įrenginių

339
00:15:14,270 --> 00:15:18,370
ir pašalinti kliūtis, kad
reikia man masto vertikaliai.

340
00:15:18,370 --> 00:15:22,080
>> Taigi tai tikrai pastatytas internete
sandorių apdorojimas ir masto.

341
00:15:22,080 --> 00:15:25,480
Yra didelis skirtumas
čia tarp ataskaitų, tiesa?

342
00:15:25,480 --> 00:15:27,810
Ataskaitos, aš nežinau
Klausimai aš ruošiuosi paklausti.

343
00:15:27,810 --> 00:15:28,310
Teisė?

344
00:15:28,310 --> 00:15:30,570
Reporting--, jei kas nors iš
mano Marketingo skyrius

345
00:15:30,570 --> 00:15:34,520
nori just-- kiek iš mano klientų
turėti šią konkrečią charakteristiką, kas

346
00:15:34,520 --> 00:15:37,850
nusipirkau šį day-- nežinau
kas užklausa jie ketina prašyti.

347
00:15:37,850 --> 00:15:39,160
Taigi man reikia būti agnostikas.

348
00:15:39,160 --> 00:15:41,810
>> Dabar, internete
taikymo sandorio,

349
00:15:41,810 --> 00:15:43,820
Aš žinau, kokius klausimus aš prašau.

350
00:15:43,820 --> 00:15:46,581
Aš pastatė už paraišką
labai specifinė darbo eigos.

351
00:15:46,581 --> 00:15:47,080
GERAI?

352
00:15:47,080 --> 00:15:50,540
Taigi, jei aš optimizuoti duomenis
saugoti paremti šį eigą,

353
00:15:50,540 --> 00:15:52,020
jis bus greitesnis.

354
00:15:52,020 --> 00:15:55,190
Ir štai kodėl NoSQL gali
tikrai paspartinti pristatymas

355
00:15:55,190 --> 00:15:57,710
iš šių paslaugų rūšys.

356
00:15:57,710 --> 00:15:58,210
Gerai.

357
00:15:58,210 --> 00:16:00,501
>> Taigi mes ketiname patekti į
šiek tiek teorijos čia.

358
00:16:00,501 --> 00:16:03,330
Ir kai kurie iš jūsų, jūsų akys
gali įvirsta truputį.

359
00:16:03,330 --> 00:16:06,936
Bet aš pabandysiu ją išlaikyti
kaip aukšto lygio, kaip aš galiu.

360
00:16:06,936 --> 00:16:08,880
Taigi, jei esate projektą
valdymo, ten

361
00:16:08,880 --> 00:16:12,280
konstrukciją, vadinamas
trikampis apribojimus.

362
00:16:12,280 --> 00:16:12,936
GERAI.

363
00:16:12,936 --> 00:16:16,060
Iš riboja diktato trikampis
jūs negalite turėti visko laiką.

364
00:16:16,060 --> 00:16:17,750
Negali turėti savo tortą ir valgo jis taip pat.

365
00:16:17,750 --> 00:16:22,310
Taigi projekto valdymą, kad trikampis
apribojimai yra, galite ją pigus,

366
00:16:22,310 --> 00:16:24,710
Jums jis gali būti greitai,
ar jūs galite turėti tai gerai.

367
00:16:24,710 --> 00:16:25,716
Pick du.

368
00:16:25,716 --> 00:16:27,090
Kadangi jūs negalite turėti visus tris.

369
00:16:27,090 --> 00:16:27,460
Teisė?

370
00:16:27,460 --> 00:16:27,820
GERAI.

371
00:16:27,820 --> 00:16:28,920
>> Taigi sužinojote apie šį daug.

372
00:16:28,920 --> 00:16:31,253
Tai triguba apribojimas,
trikampis triguba apribojimų,

373
00:16:31,253 --> 00:16:34,420
arba geležies trikampis yra oftentimes--
kai jūs kalbate su projektų vadovams,

374
00:16:34,420 --> 00:16:35,420
jie apie tai kalbėti.

375
00:16:35,420 --> 00:16:37,640
Dabar, duomenų bazės turi
savo geležies trikampis.

376
00:16:37,640 --> 00:16:40,350
Ir geležis trikampis duomenų
yra tai, ką mes vadiname BŽŪP teorema.

377
00:16:40,350 --> 00:16:41,580
GERAI?

378
00:16:41,580 --> 00:16:43,770
>> BŽŪP teorema diktuoja
kaip duomenų bazės veikia

379
00:16:43,770 --> 00:16:45,627
pagal labai konkrečią būklę.

380
00:16:45,627 --> 00:16:47,460
Ir mes kalbame apie
ką ši sąlyga.

381
00:16:47,460 --> 00:16:52,221
Tačiau trys taškai trikampio,
taip sakant, yra C, nuoseklumas.

382
00:16:52,221 --> 00:16:52,720
GERAI?

383
00:16:52,720 --> 00:16:56,760
Taigi BŽŪP, nuoseklumas reiškia, kad visi
klientai, kurie gali prieiti prie duomenų bazės

384
00:16:56,760 --> 00:16:59,084
visada turės labai
nuoseklų duomenų.

385
00:16:59,084 --> 00:17:00,750
Niekieno gonna mato du skirtingus dalykus.

386
00:17:00,750 --> 00:17:01,480
GERAI?

387
00:17:01,480 --> 00:17:04,020
Jei matau duomenų bazę,
Matau tą patį vaizdą

388
00:17:04,020 --> 00:17:06,130
kaip mano partnerio, kuris mato
tas pats duomenų.

389
00:17:06,130 --> 00:17:07,470
Štai nuoseklumas.

390
00:17:07,470 --> 00:17:12,099
>> Likutis reiškia, kad jei
duomenų bazė internete, jei ji gali būti pasiektas,

391
00:17:12,099 --> 00:17:14,760
kad visi klientai bus visada
gebėti skaityti ir rašyti.

392
00:17:14,760 --> 00:17:15,260
GERAI?

393
00:17:15,260 --> 00:17:17,010
Taigi kiekvienas klientas,
gali skaityti duomenų bazę

394
00:17:17,010 --> 00:17:18,955
visada galės Skaityti
duomenų ir rašyti duomenis.

395
00:17:18,955 --> 00:17:21,819
Ir jei tai toks atvejis,
tai yra prieinama sistema.

396
00:17:21,819 --> 00:17:24,230
>> Ir trečias dalykas yra ką
mes vadiname skirsnių toleranciją.

397
00:17:24,230 --> 00:17:24,730
GERAI?

398
00:17:24,730 --> 00:17:28,160
Pasiskirstymo tolerancijos priemonės
kad sistema veikia gerai

399
00:17:28,160 --> 00:17:32,000
nepaisant fizinio tinklo
pertvaros tarp mazgų.

400
00:17:32,000 --> 00:17:32,760
GERAI?

401
00:17:32,760 --> 00:17:36,270
Taigi mazgų klasterius negali
kalbėtis tarpusavyje, kas atsitiks?

402
00:17:36,270 --> 00:17:36,880
Gerai.

403
00:17:36,880 --> 00:17:39,545
>> Taigi reliacinės duomenų bazės choose--
galite pasirinkti du iš jų.

404
00:17:39,545 --> 00:17:40,045
GERAI.

405
00:17:40,045 --> 00:17:43,680
Taigi reliacinės duomenų bazės pasirinkti
būti nuoseklūs ir prieinama.

406
00:17:43,680 --> 00:17:47,510
Jei skaidinys vyksta tarp
Į duomenų saugyklos DataNodes,

407
00:17:47,510 --> 00:17:48,831
duomenų bazė sugenda.

408
00:17:48,831 --> 00:17:49,330
Teisė?

409
00:17:49,330 --> 00:17:50,900
Jis tiesiog krinta.

410
00:17:50,900 --> 00:17:51,450
GERAI.

411
00:17:51,450 --> 00:17:54,230
>> Ir tai, kodėl jie turi
augti su didesniais dėžės.

412
00:17:54,230 --> 00:17:54,730
Teisė?

413
00:17:54,730 --> 00:17:58,021
Nes ten no-- paprastai klasteris
duomenų bazė, ten nėra labai daug iš jų

414
00:17:58,021 --> 00:17:59,590
kad veikia, kad taip.

415
00:17:59,590 --> 00:18:03,019
Tačiau dauguma duomenų bazės mastelį
vertikaliai per vieną langelį.

416
00:18:03,019 --> 00:18:05,060
Kadangi jie turi būti
nuosekli ir prieinama.

417
00:18:05,060 --> 00:18:10,320
Jei skaidinys būtų švirkščiamas,
tada jums reikės rinktis.

418
00:18:10,320 --> 00:18:13,720
Jūs turite rinktis tarp
yra nuoseklus ir prieinama.

419
00:18:13,720 --> 00:18:16,080
>> Ir tai, ką NoSQL duomenų bazės daryti.

420
00:18:16,080 --> 00:18:16,580
Gerai.

421
00:18:16,580 --> 00:18:20,950
Taigi NoSQL duomenų bazę,
yra dviejų skonių.

422
00:18:20,950 --> 00:18:22,990
Mes have-- Na, tai
ateina daug skonių,

423
00:18:22,990 --> 00:18:26,140
bet ji ateina su dviejų pagrindinių
characteristics-- ką

424
00:18:26,140 --> 00:18:30,050
mes vadiname CP duomenų bazę arba
nuosekli ir pertvarų tolerancija

425
00:18:30,050 --> 00:18:31,040
sistema.

426
00:18:31,040 --> 00:18:34,930
Šie vaikinai padaryti pasirinkimą, kad kai
mazgai praranda kontaktą vienas su kitu,

427
00:18:34,930 --> 00:18:37,091
mes neketiname leisti
žmonių rašyti, bet daugiau.

428
00:18:37,091 --> 00:18:37,590
GERAI?

429
00:18:37,590 --> 00:18:41,855
>> Iki skaidinys bus pašalintas,
Rašymo prieiga užblokuotas.

430
00:18:41,855 --> 00:18:43,230
Tai reiškia, kad jie nėra prieinami.

431
00:18:43,230 --> 00:18:44,510
Jie nuoseklūs.

432
00:18:44,510 --> 00:18:46,554
Kai matome, kad
Pasiskirstymo švirkšti pats,

433
00:18:46,554 --> 00:18:48,470
dabar mes esame nuoseklūs,
nes mes neketiname

434
00:18:48,470 --> 00:18:51,517
leisti pakeisti duomenis dėl dviejų
pusės disko savarankiškai

435
00:18:51,517 --> 00:18:52,100
viena nuo kitos.

436
00:18:52,100 --> 00:18:54,130
Turėsime
atkurti ryšį

437
00:18:54,130 --> 00:18:56,930
prieš bet kokį atnaujintoje
duomenys yra leidžiamas.

438
00:18:56,930 --> 00:18:58,120
GERAI?

439
00:18:58,120 --> 00:19:02,650
>> Kitas skonis būtų AP sistema,
arba prieinama ir suskirstyti

440
00:19:02,650 --> 00:19:03,640
tolerancija sistema.

441
00:19:03,640 --> 00:19:05,320
Šie vaikinai nerūpi.

442
00:19:05,320 --> 00:19:06,020
Teisė?

443
00:19:06,020 --> 00:19:08,960
Bet mazgas, kad gauna
rašyti, mes jį priimti.

444
00:19:08,960 --> 00:19:11,480
Taigi, aš atkartoti savo duomenis
keliose mazgų.

445
00:19:11,480 --> 00:19:14,730
Šie mazgai gauti kliento, kliento ateina
į, sako, aš ruošiuosi rašyti kai kuriuos duomenis.

446
00:19:14,730 --> 00:19:16,300
Mazgas sako, jokių problemų.

447
00:19:16,300 --> 00:19:18,580
Mazgas šalia jo gauna
ant to paties įrašo rašymo,

448
00:19:18,580 --> 00:19:20,405
jis ketina pasakyti jokių problemų.

449
00:19:20,405 --> 00:19:23,030
Kažkur atgal ant nugaros pabaigoje,
kad duomenys ketina atkartoti.

450
00:19:23,030 --> 00:19:27,360
Ir tada kažkas vyksta suvokti,
Oi, jie sistema suprasite, uh-oh,

451
00:19:27,360 --> 00:19:28,870
ten buvo panaudotas dviejų pusių atnaujinti.

452
00:19:28,870 --> 00:19:30,370
Ką mes darome?

453
00:19:30,370 --> 00:19:33,210
Ir ką jie daro, tada yra
jie kažką,

454
00:19:33,210 --> 00:19:36,080
leidžia jiems išspręsti, kad Valstybinė duomenų.

455
00:19:36,080 --> 00:19:39,000
Ir mes kalbame apie
kad kitam diagramos.

456
00:19:39,000 --> 00:19:40,000
>> Dalykas atkreipti dėmesį į čia.

457
00:19:40,000 --> 00:19:42,374
Ir aš nesiruošia gauti per
daug į tai, nes šis

458
00:19:42,374 --> 00:19:43,510
patenka į gilią duomenų teorija.

459
00:19:43,510 --> 00:19:46,670
Bet ten sandorio
sistema,

460
00:19:46,670 --> 00:19:50,680
Veikia reliacinės sistemos,
leidžia man saugiai padaryti atnaujinimai

461
00:19:50,680 --> 00:19:53,760
keliems subjektams duomenų bazėje.

462
00:19:53,760 --> 00:19:58,320
Ir tie atnaujinimai įvyks
visos iš karto arba ne visi.

463
00:19:58,320 --> 00:20:00,500
Ir tai vadinama RŪGŠTIS sandorius.

464
00:20:00,500 --> 00:20:01,000
GERAI?

465
00:20:01,000 --> 00:20:06,570
>> RŪGŠTIS suteikia mums nedalomumo, nuoseklumo,
izoliacija ir ilgaamžiškumą.

466
00:20:06,570 --> 00:20:07,070
GERAI?

467
00:20:07,070 --> 00:20:13,550
Tai reiškia, kad atominio, sandorius, visa
Mano atnaujinimai arba atsitiks ar jie neturi.

468
00:20:13,550 --> 00:20:16,570
Derėjimas reiškia, kad
duomenų bazę visada

469
00:20:16,570 --> 00:20:19,780
būti įtraukti į nuoseklią
būklė po atnaujinimo.

470
00:20:19,780 --> 00:20:23,900
Aš niekada palikti duomenų bazėje
blogos būklės tepdami atnaujinti.

471
00:20:23,900 --> 00:20:24,400
GERAI?

472
00:20:24,400 --> 00:20:26,720
>> Taigi tai šiek tiek kitoks
nei BŽŪP nuoseklumo.

473
00:20:26,720 --> 00:20:29,760
BŽŪP nuoseklumas reiškia visų mano
klientai visada gali matyti duomenis.

474
00:20:29,760 --> 00:20:34,450
RŪGŠTIS nuoseklumas reiškia, kad kai
sandoris padaryta, duomenų gera.

475
00:20:34,450 --> 00:20:35,709
Mano santykiai yra viskas gerai.

476
00:20:35,709 --> 00:20:38,750
Nesiruošiu ištrinti patronuojanti eilutę
ir palikti našlaičiai krūva

477
00:20:38,750 --> 00:20:40,970
kai kitos lentelės.

478
00:20:40,970 --> 00:20:44,320
Tai negali atsitikti, jei aš nuosekliai
rūgštinėje sandorį.

479
00:20:44,320 --> 00:20:49,120
>> Izoliacija reiškia, kad sandoriai
visada įvyks vienas po kito.

480
00:20:49,120 --> 00:20:51,920
Galutinis rezultatas duomenis
bus tas pats būklė

481
00:20:51,920 --> 00:20:54,770
kaip jei šie sandoriai
kad buvo išduotas kartu

482
00:20:54,770 --> 00:20:57,340
buvo įvykdyta serijiniu.

483
00:20:57,340 --> 00:21:00,030
Taigi, tai lygiagrečiai
valdymo duomenų bazėje.

484
00:21:00,030 --> 00:21:04,130
Taigi, iš esmės, aš negaliu prieaugio
pačios vertės du kartus su dviejų operacijų.

485
00:21:04,130 --> 00:21:08,580
>> Bet jei aš sakau, pridėti 1 iki šios vertės,
ir du sandoriai būna

486
00:21:08,580 --> 00:21:10,665
ir pabandykite tai padaryti, vienas yra
vyksta pirmasis ten patekti

487
00:21:10,665 --> 00:21:12,540
o kitas s
ketina po ten.

488
00:21:12,540 --> 00:21:15,210
Taigi, galų gale, aš pridėjo du.

489
00:21:15,210 --> 00:21:16,170
Jūs matote, ką turiu galvoje?

490
00:21:16,170 --> 00:21:16,670
GERAI.

491
00:21:16,670 --> 00:21:19,220

492
00:21:19,220 --> 00:21:21,250
>> Ilgaamžiškumas yra gana paprasta.

493
00:21:21,250 --> 00:21:23,460
Kai sandoris
Pripažįstama, kad tai

494
00:21:23,460 --> 00:21:26,100
bus ten net
jei sistema sugenda.

495
00:21:26,100 --> 00:21:29,230
Kai ši sistema susitraukia, kad
sandoris, kuris buvo padarytas

496
00:21:29,230 --> 00:21:30,480
iš tikrųjų bus ten.

497
00:21:30,480 --> 00:21:33,130
Taigi, kad garantijos
Rūgščių sandorius.

498
00:21:33,130 --> 00:21:35,470
Tai yra labai gražus garantijos
turėti į duomenų bazę,

499
00:21:35,470 --> 00:21:36,870
bet jie tuo kainą.

500
00:21:36,870 --> 00:21:37,640
Teisė?

501
00:21:37,640 --> 00:21:40,520
>> Kadangi problemos
su šia sistema yra

502
00:21:40,520 --> 00:21:44,540
jei yra į duomenų pertvara
rinkinys, turiu priimti sprendimą.

503
00:21:44,540 --> 00:21:48,000
Aš ruošiuosi leisti
atnaujinimai vieną ar kitą pusę.

504
00:21:48,000 --> 00:21:50,310
Ir jei tai atsitiks,
tada aš nebėra vyksta

505
00:21:50,310 --> 00:21:52,630
kad būtų galima palaikyti
šios savybės.

506
00:21:52,630 --> 00:21:53,960
Jie nebus nuoseklūs.

507
00:21:53,960 --> 00:21:55,841
Jie nebus izoliuota.

508
00:21:55,841 --> 00:21:58,090
Tai kur jis skyla
už reliacinių duomenų bazių.

509
00:21:58,090 --> 00:22:01,360
Tai yra priežastis, reliacinė
duomenų bazės mastelį vertikaliai.

510
00:22:01,360 --> 00:22:05,530
>> Kita vertus, turime
tai, kas vadinama BASE technologiją.

511
00:22:05,530 --> 00:22:07,291
Ir tai yra jūsų NoSQL duomenų bazės.

512
00:22:07,291 --> 00:22:07,790
Gerai.

513
00:22:07,790 --> 00:22:10,180
Taigi, mes turime CP, ap duomenų bazių.

514
00:22:10,180 --> 00:22:14,720
Ir tai yra tai, ką jūs vadinate esmės
galima, minkštas valstybė, galiausiai

515
00:22:14,720 --> 00:22:15,740
nuoseklūs.

516
00:22:15,740 --> 00:22:16,420
GERAI?

517
00:22:16,420 --> 00:22:19,690
>> Iš esmės galima, nes
jie pertvarų tolerantiškas.

518
00:22:19,690 --> 00:22:21,470
Jie visada bus
ten, net jei ten

519
00:22:21,470 --> 00:22:23,053
tinklo disko tarp mazgų.

520
00:22:23,053 --> 00:22:25,900
Jei aš galiu pasikalbėti su mazge, aš
bus galima skaityti duomenis.

521
00:22:25,900 --> 00:22:26,460
GERAI?

522
00:22:26,460 --> 00:22:30,810
Aš ne visada gali būti suteikta galimybė rašyti
duomenys, jei aš nuosekliai platforma.

523
00:22:30,810 --> 00:22:32,130
Bet aš galės skaityti duomenis.

524
00:22:32,130 --> 00:22:34,960

525
00:22:34,960 --> 00:22:38,010
>> Minkštas būklė rodo
kad, kai aš perskaičiau, kad duomenys,

526
00:22:38,010 --> 00:22:40,790
jis gali būti toks pat, kaip kitų mazgų.

527
00:22:40,790 --> 00:22:43,390
Jei teisė buvo išduotas mazgas
kažkur kitur klasterio

528
00:22:43,390 --> 00:22:46,650
ir tai nebuvo pakartotas visoje
klasteris dar kai aš perskaičiau, kad duomenys,

529
00:22:46,650 --> 00:22:48,680
kad valstybės gali būti nuoseklūs.

530
00:22:48,680 --> 00:22:51,650
Tačiau, ji bus
galiausiai nuosekliai,

531
00:22:51,650 --> 00:22:53,870
Tai reiškia, kad, kai rašymo
yra pagamintas prie sistemos,

532
00:22:53,870 --> 00:22:56,480
jis pasidaugina visoje mazgų.

533
00:22:56,480 --> 00:22:59,095
Ir, galų gale, kad valstybės
bus pradėta tam,

534
00:22:59,095 --> 00:23:00,890
ir ji bus nuosekliai būklė.

535
00:23:00,890 --> 00:23:05,000
>> Dabar, BŽŪP teorema tikrai
vaidina tik viena sąlyga.

536
00:23:05,000 --> 00:23:08,700
Ši sąlyga yra tada, kai tai atsitiks.

537
00:23:08,700 --> 00:23:13,710
Nes kai jis veikia
normalus režimas, nėra pertvarų,

538
00:23:13,710 --> 00:23:16,370
viskas atitinka ir prieinama.

539
00:23:16,370 --> 00:23:19,990
Jums tik nerimauti BŽŪP
kai mes turime tą skyrių.

540
00:23:19,990 --> 00:23:21,260
Taigi tie, kurie retai.

541
00:23:21,260 --> 00:23:25,360
Bet, kaip sistema reaguoja, kai tie
įvyksta, diktuoja, kokio tipo sistemos

542
00:23:25,360 --> 00:23:26,750
mes susiduriame su.

543
00:23:26,750 --> 00:23:31,110
>> Taigi leiskite pažvelgti, kas
kad atrodo už AP sistemas.

544
00:23:31,110 --> 00:23:32,621
GERAI?

545
00:23:32,621 --> 00:23:34,830
AP sistemos būna dviejų skonių.

546
00:23:34,830 --> 00:23:38,514
Jie būna skonį, kuris yra
Meistras, 100%, visada prieinama.

547
00:23:38,514 --> 00:23:40,430
Ir jie ateina į
Kitų skonių, kurie sako,

548
00:23:40,430 --> 00:23:43,330
jūs žinote, ką aš ruošiuosi jaudintis
apie šį skaidymo dalykas

549
00:23:43,330 --> 00:23:44,724
kai faktinis pertvarų pasitaiko.

550
00:23:44,724 --> 00:23:47,890
Priešingu atveju, ten bus pagrindinis
mazgai, kuris ketina imtis teises.

551
00:23:47,890 --> 00:23:48,500
GERAI?

552
00:23:48,500 --> 00:23:50,040
>> Taigi, jei mes kažką panašaus Kasandra.

553
00:23:50,040 --> 00:23:54,440
Kasandra būtų meistras
meistras, tegul man rašyti į bet mazgas.

554
00:23:54,440 --> 00:23:55,540
Taigi, kas atsitiks?

555
00:23:55,540 --> 00:23:58,270
Taigi turiu objekte
duomenų, kad egzistuoja dviejų mazgų.

556
00:23:58,270 --> 00:24:01,705
Pavadinkime šį objektą S.
Taigi, mes turime būseną S.

557
00:24:01,705 --> 00:24:04,312
Mes turime keletą operacijų
nuo S, kad tebevyksta.

558
00:24:04,312 --> 00:24:06,270
Kasandra leidžia man
rašyti kelių mazgų.

559
00:24:06,270 --> 00:24:08,550
Taigi tarkim gaunu
rašyti s iki dviejų mazgų.

560
00:24:08,550 --> 00:24:12,274
Na, ką baigiasi vyksta,
mes vadiname, kad tam skaidymo atveju.

561
00:24:12,274 --> 00:24:14,190
Gali būti ne
fizinė tinklo pertvara.

562
00:24:14,190 --> 00:24:15,950
Bet todėl, kad konstrukcijos
iš sistemos, tai yra

563
00:24:15,950 --> 00:24:18,449
iš tikrųjų atitvarų kuo greičiau
kaip aš galiu gauti dėl dviejų mazgų rašyti.

564
00:24:18,449 --> 00:24:20,830
Tai ne privertė mane
rašyti visi per vieną mazgą.

565
00:24:20,830 --> 00:24:22,340
Aš rašau dėl dviejų mazgų.

566
00:24:22,340 --> 00:24:23,330
GERAI?

567
00:24:23,330 --> 00:24:25,740
>> Taigi dabar turiu dvi valstybes.

568
00:24:25,740 --> 00:24:26,360
GERAI?

569
00:24:26,360 --> 00:24:28,110
Kas nutiks
anksčiau ar vėliau,

570
00:24:28,110 --> 00:24:29,960
ten bus replikacijos įvykis.

571
00:24:29,960 --> 00:24:33,300
Ten bus ką mes
vadinamas disko atkūrimo, kuris

572
00:24:33,300 --> 00:24:35,200
kur šių dviejų
narės grįžti kartu

573
00:24:35,200 --> 00:24:37,310
ir ten bus algoritmas
kuri veikia viduje duomenų bazėje,

574
00:24:37,310 --> 00:24:38,540
nusprendžia, ką daryti.

575
00:24:38,540 --> 00:24:39,110
GERAI?

576
00:24:39,110 --> 00:24:43,057
Pagal nutylėjimą, Paskutiniai pakeitimai
laimi daugelyje AP sistemas.

577
00:24:43,057 --> 00:24:44,890
Taigi ten paprastai
Numatytasis algoritmas, kas

578
00:24:44,890 --> 00:24:47,400
jie vadina atg
funkcija, kažkas, kad

579
00:24:47,400 --> 00:24:51,000
vadinsis jei ši sąlyga
aptinkamas vykdyti tam tikrą logiką

580
00:24:51,000 --> 00:24:52,900
išspręsti šio konflikto.

581
00:24:52,900 --> 00:24:53,850
GERAI?

582
00:24:53,850 --> 00:24:58,770
Numatytoji atgalinių nevykdymas
Resolverio daugumoje AP duomenų bazėse

583
00:24:58,770 --> 00:25:01,130
yra atspėti, ką, laiko žymos laimi.

584
00:25:01,130 --> 00:25:02,380
Tai buvo Paskutiniai pakeitimai.

585
00:25:02,380 --> 00:25:04,320
Aš ruošiuosi įdėti, kad atnaujinti ten.

586
00:25:04,320 --> 00:25:08,440
Aš gali sąvartynas šį įrašą, kad aš
dempingo ne į atkūrimo Prisijungti

587
00:25:08,440 --> 00:25:11,670
taip, kad vartotojas gali grįžti vėliau
ir sako, ei, ten buvo susidūrimas.

588
00:25:11,670 --> 00:25:12,320
Kas atsitiko?

589
00:25:12,320 --> 00:25:16,370
Ir jūs iš tikrųjų galite iškelties įrašus
visi susidūrimai ir rollbacks

590
00:25:16,370 --> 00:25:17,550
ir pamatyti, kas atsitiks.

591
00:25:17,550 --> 00:25:21,580
>> Dabar, kaip vartotojas, taip pat galite
įtraukti logika į tą atg.

592
00:25:21,580 --> 00:25:24,290
Taigi jūs galite pakeisti, kad
atgalinių operacija.

593
00:25:24,290 --> 00:25:26,730
Galite pasakyti, ei, aš noriu
priemonių atitaisyti šiuos duomenis.

594
00:25:26,730 --> 00:25:28,880
Ir aš noriu pabandyti ir
sujungti šiuos du įrašus.

595
00:25:28,880 --> 00:25:30,050
Bet tai priklauso nuo jūsų.

596
00:25:30,050 --> 00:25:32,880
Duomenų bazė neturi žinoti, kaip
padaryti, kad pagal nutylėjimą. Dauguma laiko,

597
00:25:32,880 --> 00:25:34,850
vienintelis dalykas, duomenų bazės
žino, kaip padaryti, tai pasakyti,

598
00:25:34,850 --> 00:25:36,100
tai vienas buvo paskutinis įrašas.

599
00:25:36,100 --> 00:25:39,183
Štai vienas, kad laimės,
ir tai vertė Aš ruošiuosi įdėti.

600
00:25:39,183 --> 00:25:41,490
Kai tą Partition Recovery
ir replikacija įvyksta,

601
00:25:41,490 --> 00:25:43,930
mes turime savo valstybę, kuri
dabar yra S svarbiausias, kuris yra

602
00:25:43,930 --> 00:25:46,890
suliejimo valstybė visų tų objektų.

603
00:25:46,890 --> 00:25:49,700
Taigi AP sistemos turi tai.

604
00:25:49,700 --> 00:25:51,615
CP sistemos nereikia
nerimauti tai.

605
00:25:51,615 --> 00:25:54,490
Nes kaip tik skaidinys ateina
į žaidimą, jie tiesiog nustoti vartoti

606
00:25:54,490 --> 00:25:55,530
rašo.

607
00:25:55,530 --> 00:25:56,180
GERAI?

608
00:25:56,180 --> 00:25:58,670
Taigi, kad labai lengva
spręsti yra suderinamas

609
00:25:58,670 --> 00:26:01,330
kai jūs nesutinkate visus atnaujinimus.

610
00:26:01,330 --> 00:26:04,620
Štai su CP sistemos padaryti.

611
00:26:04,620 --> 00:26:05,120
Gerai.

612
00:26:05,120 --> 00:26:07,590
>> Taigi pakalbėkime šiek tiek
tiek apie prieigos modelius.

613
00:26:07,590 --> 00:26:11,580
Kai kalbame apie NoSQL, tai
Viskas apie prieigos modelio.

614
00:26:11,580 --> 00:26:13,550
Dabar, SQL ad hoc užklausas.

615
00:26:13,550 --> 00:26:14,481
Tai reliacinės parduotuvė.

616
00:26:14,481 --> 00:26:16,480
Neturime nerimauti
apie prieigos modelis.

617
00:26:16,480 --> 00:26:17,688
Aš rašau labai sudėtingą užklausą.

618
00:26:17,688 --> 00:26:19,250
Jis eina ir gauna duomenis.

619
00:26:19,250 --> 00:26:21,210
Štai ką tai atrodo
kaip, normalizavimas.

620
00:26:21,210 --> 00:26:24,890
>> Taigi, šio konkretaus struktūrą,
mes ieškome ne produktų katalogą.

621
00:26:24,890 --> 00:26:26,640
I turi skirtingas produktų rūšis.

622
00:26:26,640 --> 00:26:27,217
Turiu knygas.

623
00:26:27,217 --> 00:26:27,800
Turiu albumus.

624
00:26:27,800 --> 00:26:30,090
Turiu vaizdo įrašus.

625
00:26:30,090 --> 00:26:33,370
Skirtumas tarp produktų santykiai
ir bet kurios šių knygų, albumų viena,

626
00:26:33,370 --> 00:26:34,860
ir video lentelės yra 1: 1.

627
00:26:34,860 --> 00:26:35,800
Gerai?

628
00:26:35,800 --> 00:26:38,860
Aš turiu produkto ID,
ir tokiu ID Atitinka

629
00:26:38,860 --> 00:26:41,080
į knygą, albumą arba įrašą.

630
00:26:41,080 --> 00:26:41,580
GERAI?

631
00:26:41,580 --> 00:26:44,350
Štai 1: 1 santykis
visoje tose lentelėse.

632
00:26:44,350 --> 00:26:46,970
>> Dabar books-- visi jie
turi root savybės.

633
00:26:46,970 --> 00:26:47,550
Jokiu problemu.

634
00:26:47,550 --> 00:26:48,230
Tai puiku.

635
00:26:48,230 --> 00:26:52,130
Vienas prie vieno santykiai, gaunu visus
duomenys man reikia apibūdinti šią knygą.

636
00:26:52,130 --> 00:26:54,770
Albums-- Fotoalbumai takelius.

637
00:26:54,770 --> 00:26:56,470
Tai yra tai, ką mes vadiname vienas su daugeliu.

638
00:26:56,470 --> 00:26:58,905
Kiekvienas albumai galėtų turėti daug takelius.

639
00:26:58,905 --> 00:27:00,780
Taigi už kiekvieną kūrinį
albumas, galėčiau

640
00:27:00,780 --> 00:27:02,570
dar vienas rekordas šiame vaikų stalo.

641
00:27:02,570 --> 00:27:04,680
Taigi aš sukurti vieną įrašą
į Mano albumai stalo.

642
00:27:04,680 --> 00:27:06,700
Galiu sukurti kelis įrašus
Takeliai stalo.

643
00:27:06,700 --> 00:27:08,850
Vienas su daugeliu santykiai.

644
00:27:08,850 --> 00:27:11,220
>> Šis ryšys yra tai, ką
mes vadiname daugelis su daugeliu ".

645
00:27:11,220 --> 00:27:11,750
GERAI?

646
00:27:11,750 --> 00:27:17,000
Jūs matote, kad aktoriai galėtų būti
daug filmų, daug video.

647
00:27:17,000 --> 00:27:21,450
Taigi, ką mes darome, yra mes įdėti šią kartografavimo
Lentelėje tarp tų, kurių ji tiesiog

648
00:27:21,450 --> 00:27:24,040
žemėlapiai aktorius ID į vaizdo įrašo ID.

649
00:27:24,040 --> 00:27:28,464
Dabar galiu kurti užklausą, prisijungia
video per aktorius video į veikėjų,

650
00:27:28,464 --> 00:27:31,130
ir tai man suteikia gražią sąrašą
visi filmai ir visi aktoriai

651
00:27:31,130 --> 00:27:32,420
kurie buvo tame filme.

652
00:27:32,420 --> 00:27:33,290
>> GERAI.

653
00:27:33,290 --> 00:27:33,880
Taigi čia mes einame.

654
00:27:33,880 --> 00:27:38,040
Vienas prie vieno yra aukščiausio lygio
santykiai; vienas su daug,

655
00:27:38,040 --> 00:27:40,240
Fotoalbumai į takelius; daugelis su daugeliu ".

656
00:27:40,240 --> 00:27:44,990
Tie trys aukščiausio lygio
santykiai į jokią duomenų bazę.

657
00:27:44,990 --> 00:27:48,050
Jei žinote, kaip tie,
santykiai dirbti kartu,

658
00:27:48,050 --> 00:27:51,490
tuomet jūs žinote, daug
apie duomenų bazėje jau.

659
00:27:51,490 --> 00:27:55,660
Taigi NoSQL veikia šiek tiek kitaip.

660
00:27:55,660 --> 00:27:58,930
Pagalvokime apie sekundę, kas tai
Atrodo, kad eiti gauti visus savo produktus.

661
00:27:58,930 --> 00:28:01,096
>> Be reliacinės parduotuvėje, aš
nori gauti visas savo produktus

662
00:28:01,096 --> 00:28:02,970
nuo visų mano produktų sąrašą.

663
00:28:02,970 --> 00:28:04,910
Štai užklausų daug.

664
00:28:04,910 --> 00:28:07,030
Gavau visų mano knygų užklausą.

665
00:28:07,030 --> 00:28:08,470
Gavau iš mano albumų užklausą.

666
00:28:08,470 --> 00:28:09,970
Ir aš turiu visų mano video užklausą.

667
00:28:09,970 --> 00:28:11,719
Ir aš įdėti jį
visi kartu į sąrašą,

668
00:28:11,719 --> 00:28:15,250
ir tarnauti jį atgal į viršų į
programa, kuri manimi prašydamas.

669
00:28:15,250 --> 00:28:18,000
>> Norėdami gauti savo knygas, aš prisijungti
Produktai ir knygos.

670
00:28:18,000 --> 00:28:21,680
Norėdami gauti savo albumus, gavau prisijungti
Produktai, albumai, ir kelio protokolai.

671
00:28:21,680 --> 00:28:25,330
Ir gauti savo vaizdo įrašus, turiu
prisijungti Produktai video,

672
00:28:25,330 --> 00:28:28,890
prisijungti per aktorius video,
ir atnešti Aktoriai.

673
00:28:28,890 --> 00:28:31,020
Štai trys užklausas.

674
00:28:31,020 --> 00:28:34,560
Labai sudėtingas užklausas
surinkti vieną rezultatų rinkinį.

675
00:28:34,560 --> 00:28:36,540
>> Štai mažiau nei optimalus.

676
00:28:36,540 --> 00:28:39,200
Tai kodėl kai kalbame
apie duomenų struktūros ŠTAI

677
00:28:39,200 --> 00:28:42,900
pastatytas būti agnostikas į prieigos
pattern-- gerai tai puiku.

678
00:28:42,900 --> 00:28:45,730
Ir jūs galite pamatyti tai tikrai
gražus kaip mes organizuotas duomenis.

679
00:28:45,730 --> 00:28:46,550
Ir žinote ką?

680
00:28:46,550 --> 00:28:49,750
Aš turiu tik vieną rekordą aktorius.

681
00:28:49,750 --> 00:28:50,440
>> Tai kieta.

682
00:28:50,440 --> 00:28:53,750
Aš deduplicated visus mano veikėjus,
ir aš išlaikė savo asociacijas

683
00:28:53,750 --> 00:28:55,200
Šiame žemėlapių lentelę.

684
00:28:55,200 --> 00:29:00,620
Tačiau vis duomenis
iš tampa brangus.

685
00:29:00,620 --> 00:29:04,500
Aš siunčiant CPU visame sistema
prisijungti šių duomenų struktūras kartu

686
00:29:04,500 --> 00:29:05,950
gebėti ištraukti tą duomenis atgal.

687
00:29:05,950 --> 00:29:07,310
>> Taigi, kaip man gauti aplink, kad?

688
00:29:07,310 --> 00:29:11,200
Be NoSQL tai apie
agregacija, o ne normalizavimas.

689
00:29:11,200 --> 00:29:13,534
Taigi mes norime pasakyti, kad mes norime
remti prieigos modelis.

690
00:29:13,534 --> 00:29:15,283
Jei prieigos modelį
į paraiškas,

691
00:29:15,283 --> 00:29:16,770
Man reikia gauti visus savo produktus.

692
00:29:16,770 --> 00:29:19,027
Leiskite įdėti visus produktus į vieną lentelę.

693
00:29:19,027 --> 00:29:22,110
Jei aš įdėti visas produktus į vieną lentelę,
Aš galiu tik pasirinkti visus produktus

694
00:29:22,110 --> 00:29:23,850
Iš šios lentelės ir man visa tai.

695
00:29:23,850 --> 00:29:25,240
Na, kaip man tai padaryti?

696
00:29:25,240 --> 00:29:28,124
Na NoSQL nėra
struktūra į lentelę.

697
00:29:28,124 --> 00:29:30,540
Mes kalbame šiek tiek apie
kaip tai veikia Dinamo dB.

698
00:29:30,540 --> 00:29:33,570
Bet jūs neturite pats
požymiai ir tie patys savybės

699
00:29:33,570 --> 00:29:37,751
į kiekvieną eilutę, į kiekvieną
elementą, kaip jūs padaryti SQL lentelę.

700
00:29:37,751 --> 00:29:39,750
Ir ką tai leidžia man
padaryti yra daug dalykų,

701
00:29:39,750 --> 00:29:41,124
ir man labai lanksčiai.

702
00:29:41,124 --> 00:29:45,360
Šiuo konkrečiu atveju, aš
turiu produktų dokumentus.

703
00:29:45,360 --> 00:29:49,090
Ir tai ypač
Pavyzdžiui, viskas

704
00:29:49,090 --> 00:29:51,930
yra šių produktų stalo dokumentas.

705
00:29:51,930 --> 00:29:56,510
Ir už knygą produktas gali
turėti tipo ID, kuriame nurodoma knygą.

706
00:29:56,510 --> 00:29:59,180
Ir paraiška
būtų pereiti tą ID.

707
00:29:59,180 --> 00:30:02,570
>> Tuo paraiškos pakopos, aš ruošiuosi
pasakyti O, koks tipo įraše tai yra?

708
00:30:02,570 --> 00:30:04,100
Oi, tai knyga įrašas.

709
00:30:04,100 --> 00:30:05,990
Rezervuokite įrašai turi šias savybes.

710
00:30:05,990 --> 00:30:08,100
Leiskite sukurti knyga objektą.

711
00:30:08,100 --> 00:30:11,289
Taigi, aš ruošiuosi užpildyti
knyga objektas šią prekę nėra.

712
00:30:11,289 --> 00:30:13,080
Sekanti prekė ateina ir
sako, kas tai daiktas?

713
00:30:13,080 --> 00:30:14,560
Na šis straipsnis yra albumas.

714
00:30:14,560 --> 00:30:17,340
Oi, aš gavau visai kita
apdorojimas rutina, kad

715
00:30:17,340 --> 00:30:18,487
nes tai albumas.

716
00:30:18,487 --> 00:30:19,320
Jūs matote, ką turiu galvoje?

717
00:30:19,320 --> 00:30:21,950
>> Taigi prašymas tier-- aš
tiesiog pasirinkite visus šiuos įrašus.

718
00:30:21,950 --> 00:30:23,200
Jie visi pradėti ateina.

719
00:30:23,200 --> 00:30:24,680
Jie gali būti visų skirtingų rūšių.

720
00:30:24,680 --> 00:30:27,590
Ir tai paraiška logika
kad persijungia per šių tipų

721
00:30:27,590 --> 00:30:29,530
ir nusprendžia, kaip juos apdoroti.

722
00:30:29,530 --> 00:30:33,640
>> Vėlgi, todėl mes optimizuojant
schema, skirta prieigos modelio.

723
00:30:33,640 --> 00:30:36,390
Mes darome jį
griūva tas lenteles.

724
00:30:36,390 --> 00:30:39,670
Mes iš esmės atsižvelgiant
Šie normalizuoja struktūros,

725
00:30:39,670 --> 00:30:42,000
ir mes pastatas
hierarchinės struktūros.

726
00:30:42,000 --> 00:30:45,130
Viduje kiekvieno iš šių įrašų
Aš ruošiuosi pamatyti masyvo savybes.

727
00:30:45,130 --> 00:30:49,400
>> Viduje šio dokumento Albumai,
Matau matricos takelius.

728
00:30:49,400 --> 00:30:53,900
Šios trasos dabar become-- tai
Iš esmės tai vaiko stalo, kad

729
00:30:53,900 --> 00:30:56,520
egzistuoja čia, šioje struktūroje.

730
00:30:56,520 --> 00:30:57,975
Taigi jūs galite tai padaryti DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Jūs galite tai padaryti MongoDB.

732
00:30:59,810 --> 00:31:01,437
Jūs galite tai padaryti bet kuriuo NoSQL duomenų bazę.

733
00:31:01,437 --> 00:31:03,520
Sukurti šių tipų
hierarchinės duomenų struktūros

734
00:31:03,520 --> 00:31:07,120
kad leidžia jums gauti duomenis
labai greitai, nes dabar aš

735
00:31:07,120 --> 00:31:08,537
neturi, kad atitiktų.

736
00:31:08,537 --> 00:31:11,620
Kai aš įterpti eilutę į Takeliai
stalo arba eilutė į albumų stalo,

737
00:31:11,620 --> 00:31:13,110
Turiu atitikti tą schemą.

738
00:31:13,110 --> 00:31:18,060
Aš turėti atributą arba parengimą
nuosavybė, kuri yra apibrėžta toje lentelėje.

739
00:31:18,060 --> 00:31:20,480
Kiekvienas iš jų,
kai aš įdėti šią eilutę.

740
00:31:20,480 --> 00:31:21,910
Tai ne į NoSQL atveju.

741
00:31:21,910 --> 00:31:24,440
>> Galiu turėti visiškai skirtingas
savybės kiekvieną dokumentą

742
00:31:24,440 --> 00:31:26,100
kad aš įterpti į kolekciją.

743
00:31:26,100 --> 00:31:30,480
Taigi labai galingas mechanizmas.

744
00:31:30,480 --> 00:31:32,852
Ir tai tikrai, kaip jūs
optimizuoti sistemą.

745
00:31:32,852 --> 00:31:35,310
Nes dabar, kad užklausą, o ne
Stojant į visas šias lenteles

746
00:31:35,310 --> 00:31:39,160
ir vykdyti pusė tuzino užklausas
atsitraukti duomenis man reikia,

747
00:31:39,160 --> 00:31:40,890
Aš surašant vieną užklausą.

748
00:31:40,890 --> 00:31:43,010
Ir aš Iteracja
visoje nustatytus rezultatus.

749
00:31:43,010 --> 00:31:46,512
ji suteikia jums idėja
iš NoSQL galia.

750
00:31:46,512 --> 00:31:49,470
Aš ruošiuosi rūšies eiti į šoną čia
ir kalbėti šiek tiek apie tai.

751
00:31:49,470 --> 00:31:53,240
Tai yra daugiau rūšies iš
rinkodaros ar technology--

752
00:31:53,240 --> 00:31:55,660
technologijų rinkodara
tipo diskusija.

753
00:31:55,660 --> 00:31:58,672
Tačiau svarbu suprasti,
nes jei pažvelgsime į viršų

754
00:31:58,672 --> 00:32:00,380
čia ne šioje schemoje,
mes ieškome, kas

755
00:32:00,380 --> 00:32:04,030
yra tai, ką mes vadiname
technologija hype kreivė.

756
00:32:04,030 --> 00:32:06,121
Ir ką tai reiškia
naujų dalykų ateina į žaidimą.

757
00:32:06,121 --> 00:32:07,120
Žmonės galvoja, tai puiku.

758
00:32:07,120 --> 00:32:09,200
Aš išspręsti visas savo problemas.

759
00:32:09,200 --> 00:32:11,630
>> Tai gali būti galas
gale, būti visiems viskuo.

760
00:32:11,630 --> 00:32:12,790
Ir jie pradeda jį naudoti.

761
00:32:12,790 --> 00:32:14,720
Ir jie sako, ši medžiaga neveikia.

762
00:32:14,720 --> 00:32:17,600
Tai nėra teisinga.

763
00:32:17,600 --> 00:32:19,105
Senas dalykų buvo geriau.

764
00:32:19,105 --> 00:32:21,230
Ir jie grįžti į darai
dalykai, kaip jie buvo.

765
00:32:21,230 --> 00:32:22,730
Ir tada galiausiai
jie išeina, žinote, ką?

766
00:32:22,730 --> 00:32:24,040
Ši medžiaga yra ne taip jau blogai.

767
00:32:24,040 --> 00:32:26,192
Oi, tai, kaip ji veikia.

768
00:32:26,192 --> 00:32:28,900
Ir kai jie išsiaiškinti, kaip ją
darbai, jie pradeda vis geriau.

769
00:32:28,900 --> 00:32:32,050
>> Ir juokingas dalykas apie tai
yra, tai kokios linijos iki ko

770
00:32:32,050 --> 00:32:34,300
mes vadiname technologijų įdiegimą kreivė.

771
00:32:34,300 --> 00:32:36,910
Taigi, kas atsitinka, yra mes turime
kai rūšiuoti technologija gaiduką.

772
00:32:36,910 --> 00:32:39,100
Atsižvelgiant į duomenų bazių atveju,
tai duomenys spaudimo.

773
00:32:39,100 --> 00:32:42,200
Mes kalbėjome apie didelių vandens kiekis
Duomenų slėgio visoje laiką.

774
00:32:42,200 --> 00:32:46,310
Kai kurie duomenys slėgio hitai tam tikras
taškas, tai technologija gaiduką.

775
00:32:46,310 --> 00:32:47,830
>> Tai vis per brangu.

776
00:32:47,830 --> 00:32:49,790
Tai užtrunka pernelyg ilgai apdoroti duomenis.

777
00:32:49,790 --> 00:32:50,890
Mes turime kažką geriau.

778
00:32:50,890 --> 00:32:52,890
Jūs gaunate novatoriai
ten bėgioja,

779
00:32:52,890 --> 00:32:55,050
bando išsiaiškinti, kas yra sprendimas.

780
00:32:55,050 --> 00:32:56,050
Kokia naujoji idėja?

781
00:32:56,050 --> 00:32:58,170
>> Kas yra šalia geriausias
būdas tai padaryti šį dalyką?

782
00:32:58,170 --> 00:32:59,530
Ir jie sugalvoti kažką.

783
00:32:59,530 --> 00:33:03,140
Ir su nekilnojamojo skausmo žmonės,
kad tuo kraujavimo krašto vaikinai,

784
00:33:03,140 --> 00:33:06,390
jie šokinėti per jį,
nes jie turi atsakyti.

785
00:33:06,390 --> 00:33:09,690
Dabar, kas neišvengiamai happens-- ir
tai vyksta dabar į NoSQL.

786
00:33:09,690 --> 00:33:11,090
Matau jį visą laiką.

787
00:33:11,090 --> 00:33:13,610
>> Kas atsitinka, yra neišvengiamai
žmonės pradeda naudoti naują nuorodą

788
00:33:13,610 --> 00:33:15,490
tas pats, kaip jie panaudojo seną nuorodą.

789
00:33:15,490 --> 00:33:17,854
Ir jie išsiaiškinti ją
neveikia taip pat.

790
00:33:17,854 --> 00:33:20,020
Aš negaliu prisiminti, kas man buvo
kalbėti anksčiau šiandien.

791
00:33:20,020 --> 00:33:22,080
Bet tai kaip, kai
Pneumatinis Gręžimo plaktukas buvo išrastas,

792
00:33:22,080 --> 00:33:24,621
žmonės neturėjo sūpynės jį per
jų galvos sutriuškinti betoną.

793
00:33:24,621 --> 00:33:27,360

794
00:33:27,360 --> 00:33:30,610
>> Bet tai, kas
vyksta su NoSQL šiandien.

795
00:33:30,610 --> 00:33:33,900
Jei eisi į daugumos parduotuvių,
jie bando būti NoSQL parduotuvės.

796
00:33:33,900 --> 00:33:36,510
Ką jie daro yra
jie naudoja NoSQL,

797
00:33:36,510 --> 00:33:39,900
ir jie dėdami
pilnas reliacinės schemos.

798
00:33:39,900 --> 00:33:41,630
Nes tai, kaip
jos dizainas duomenų bazes.

799
00:33:41,630 --> 00:33:44,046
Ir jie įdomu, kodėl
jis neatlieka labai gerai?

800
00:33:44,046 --> 00:33:45,230
Vaikinas, šis dalykas dvokia.

801
00:33:45,230 --> 00:33:49,900
Aš turėjau išlaikyti visas mano
prisijungia in-- tai kaip, ne, ne.

802
00:33:49,900 --> 00:33:50,800
Išlaikyti prisijungia?

803
00:33:50,800 --> 00:33:52,430
Kodėl jūs sujungiant duomenis?

804
00:33:52,430 --> 00:33:54,350
Jūs neturite prisijungti prie duomenų NoSQL.

805
00:33:54,350 --> 00:33:55,850
Jūs apdoroja ją.

806
00:33:55,850 --> 00:34:00,690
>> Taigi, jei norite to išvengti, išmokti
kaip įrankis veikia kol jūs iš tikrųjų

807
00:34:00,690 --> 00:34:02,010
pradėti jį naudoti.

808
00:34:02,010 --> 00:34:04,860
Nesistenkite ir naudoti Naujomis priemonėmis
Tas pats būdas, kurį naudojote senus įrankius.

809
00:34:04,860 --> 00:34:06,500
Jūs ketinate turėti blogos patirties.

810
00:34:06,500 --> 00:34:08,848
Ir kiekvieną kartą
tai, kas tai yra apie.

811
00:34:08,848 --> 00:34:11,389
Kai mes pradedame artėja čia
tai, nes žmonės suprato,

812
00:34:11,389 --> 00:34:13,449
kaip naudoti įrankius.

813
00:34:13,449 --> 00:34:16,250
>> Jie padarė tą patį, kai
reliacinės duomenų bazės buvo išrastas,

814
00:34:16,250 --> 00:34:17,969
ir jie buvo pakeisti failų sistemas.

815
00:34:17,969 --> 00:34:20,420
Jie bandė sukurti failų sistemas
su reliacinių duomenų bazių

816
00:34:20,420 --> 00:34:22,159
nes tai, ką žmonės supranta.

817
00:34:22,159 --> 00:34:23,049
Tai neveikia.

818
00:34:23,049 --> 00:34:26,090
Taigi suprasti geriausią praktiką
technologijos dirbate su

819
00:34:26,090 --> 00:34:26,730
yra didžiulis.

820
00:34:26,730 --> 00:34:29,870
Labai svarbus.

821
00:34:29,870 --> 00:34:32,440
>> Taigi mes ketiname patekti į DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB yra AWS s
visiškai valdoma NoSQL platformą.

823
00:34:36,480 --> 00:34:37,719
Ką visiškai valdoma reiškia?

824
00:34:37,719 --> 00:34:40,010
Tai reiškia, kad jūs nereikia
tikrai jaudintis dėl nieko.

825
00:34:40,010 --> 00:34:42,060
>> Jūs ateiti, pasakyti
mums, man reikia staliuką.

826
00:34:42,060 --> 00:34:43,409
Jis turi tai daug pajėgumus.

827
00:34:43,409 --> 00:34:47,300
Paspausite mygtuką, ir mes nuostata
visa infrastruktūra, už scenos.

828
00:34:47,300 --> 00:34:48,310
Dabar tai yra milžiniškas.

829
00:34:48,310 --> 00:34:51,310
>> Nes kai jūs kalbate
apie mastelio duomenų bazę,

830
00:34:51,310 --> 00:34:53,917
NoSQL duomenų klasteriai at
masto, veikia petabaitus,

831
00:34:53,917 --> 00:34:55,750
veikia milijonus
Pirkimas per sekundę,

832
00:34:55,750 --> 00:34:58,180
šie dalykai yra ne mažas grupes.

833
00:34:58,180 --> 00:35:00,830
Mes kalbame tūkstančius egzempliorių.

834
00:35:00,830 --> 00:35:04,480
Valdymas tūkstančius atvejų,
net virtualių atvejų,

835
00:35:04,480 --> 00:35:06,350
yra tikras skausmas užpakalis.

836
00:35:06,350 --> 00:35:09,110
Aš turiu galvoje, manau, kad apie kiekvieną kartą, kai
operacinė sistema pleistras išeina

837
00:35:09,110 --> 00:35:11,552
arba naujas duomenų bazės versija.

838
00:35:11,552 --> 00:35:13,260
Ką tai reiškia
Jums operatyviai?

839
00:35:13,260 --> 00:35:16,330
Tai reiškia, kad jūs turite 1,200
serveriai, kurie turi būti atnaujintas.

840
00:35:16,330 --> 00:35:18,960
Dabar net su automatika,
kad gali būti ilgą laiką.

841
00:35:18,960 --> 00:35:21,480
Tai gali sukelti daug
veiklos galvos skausmas,

842
00:35:21,480 --> 00:35:23,090
nes aš gali turėti paslaugas žemyn.

843
00:35:23,090 --> 00:35:26,070
>> Kaip atnaujinti šias duomenų bazes, aš
gali padaryti mėlyna žalia diegimą

844
00:35:26,070 --> 00:35:29,420
kur aš įdiegti ir atnaujinti pusė mano
mazgai, ir tada atnaujinti kitą pusę.

845
00:35:29,420 --> 00:35:30,490
Paimkite tuos žemyn.

846
00:35:30,490 --> 00:35:33,410
Taigi valdyti infrastruktūrą
skalė yra labai skausminga.

847
00:35:33,410 --> 00:35:36,210
Ir AWS imtis, kad skausmas iš jo.

848
00:35:36,210 --> 00:35:39,210
Ir NoSQL duomenų bazės gali
būti ypač skausminga

849
00:35:39,210 --> 00:35:41,780
dėl to, kad, kaip jie skalę.

850
00:35:41,780 --> 00:35:42,926
>> Scale horizontaliai.

851
00:35:42,926 --> 00:35:45,550
Jei norite gauti didesnį NoSQL
duomenų, perkate daugiau mazgų.

852
00:35:45,550 --> 00:35:48,660
Kiekvienas mazgas perkate
Kita veiklos galvos skausmas.

853
00:35:48,660 --> 00:35:50,830
Tad kažkas tai padaryti už jus.

854
00:35:50,830 --> 00:35:52,000
AWS gali tai padaryti.

855
00:35:52,000 --> 00:35:54,587
>> Mes palaikome dokumentas pagrindines vertybes.

856
00:35:54,587 --> 00:35:56,670
Dabar mes nėjo per daug
į kita diagramos.

857
00:35:56,670 --> 00:35:58,750
Yra įvairių daug
skonių NoSQL.

858
00:35:58,750 --> 00:36:02,670
Jie visi gauti natūra
munged kartu šiuo klausimu.

859
00:36:02,670 --> 00:36:06,260
Jūs galite peržvelgti DynamoDB ir pasakyti "taip",
mes abu dokumentas ir rakto

860
00:36:06,260 --> 00:36:08,412
laikyti šį punktą.

861
00:36:08,412 --> 00:36:10,620
Ir jūs galite ginčytis savybes
viena virš kitos.

862
00:36:10,620 --> 00:36:13,950
Man Daug tai yra tikrai šešių
vieno pusę nuo kito dešimčių.

863
00:36:13,950 --> 00:36:18,710
Kiekvienas iš šių technologijų vienas yra
FINE technologijos ir bauda sprendimas.

864
00:36:18,710 --> 00:36:23,390
Nepasakyčiau MongoDB yra geresnė ar
blogiau nei sofos, tada Cassandra,

865
00:36:23,390 --> 00:36:25,994
tada Dinamo, arba atvirkščiai.

866
00:36:25,994 --> 00:36:27,285
Aš turiu galvoje, tai yra tik galimybės.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Tai greitas ir tai
atitinka bet skalę.

869
00:36:32,700 --> 00:36:36,210
Taigi tai yra viena iš didžiausių
premijas jūs gaunate su AWS.

870
00:36:36,210 --> 00:36:40,850
Su DynamoDB yra gebėjimas
gauti mažą vienaženklis

871
00:36:40,850 --> 00:36:44,040
milisekundės latentinis bet skalę.

872
00:36:44,040 --> 00:36:45,720
Kad buvo projektavimo tikslas sistemos.

873
00:36:45,720 --> 00:36:49,130
Ir mes turime klientų, kurie yra daro
milijonai operacijų per sekundę.

874
00:36:49,130 --> 00:36:52,670
>> Dabar aš eisiu per kai kurias iš tų,
naudoti atvejus per kelias minutes čia.

875
00:36:52,670 --> 00:36:55,660
Integruotą prieigą control--
mes turime, ką mes vadiname

876
00:36:55,660 --> 00:36:57,920
Tapatybės prieigos valdymo arba Iam.

877
00:36:57,920 --> 00:37:01,980
Jis persmelkia kiekvieną sistemą,
kas paslauga, kuri siūlo AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB yra ne išimtis.

879
00:37:03,630 --> 00:37:06,020
Jūs galite kontroliuoti prieigą
į DynamoDB lentelėse.

880
00:37:06,020 --> 00:37:09,960
Visose savo AWS sąskaitos pagal
apibrėžti prieigos vaidmenis ir leidimus

881
00:37:09,960 --> 00:37:12,140
į IAM infrastruktūrą.

882
00:37:12,140 --> 00:37:16,630
>> Ir tai labai svarbus ir neatsiejamas komponentas
ką mes vadiname įvykį Skatinami Programavimas.

883
00:37:16,630 --> 00:37:19,056
Dabar tai yra nauja paradigma.

884
00:37:19,056 --> 00:37:22,080
>> Auditorija: Kaip tavo kursas tiesa
pozityvai, palyginti su netikrų neigiamų

885
00:37:22,080 --> 00:37:24,052
Jūsų prieigos kontrolės sistema?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: Tikrai teigiamų
palyginti su netikrų neigiamų?

887
00:37:26,260 --> 00:37:28,785
Auditorija: Grįžimas ką
Jums reikia grąžinti?

888
00:37:28,785 --> 00:37:33,720
Skirtingai nei vieną kartą, o tai
negrąžina, kai ji turi patvirtinti?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: aš negalėjau pasakyti, kad.

891
00:37:38,050 --> 00:37:40,140
Jei yra kokių nors nesėkmes
kokia apie tai,

892
00:37:40,140 --> 00:37:42,726
Nesu asmuo paklausti
kad visų pirma klausimas.

893
00:37:42,726 --> 00:37:43,850
Bet tai geras klausimas.

894
00:37:43,850 --> 00:37:45,905
Būčiau įdomu žinoti
kad aš, iš tikrųjų.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Ir taip, tada vėl nauja paradigma
yra įvykis, vykdomas programas.

897
00:37:51,320 --> 00:37:55,160
Tai yra idėja, kad jūs galite
dislokuoti sudėtingas programas,

898
00:37:55,160 --> 00:37:59,720
gali veikti labai, labai didelis skalę
be jokios infrastruktūros kokia.

899
00:37:59,720 --> 00:38:02,120
Be jokios fiksuotos
infrastruktūra apskritai.

900
00:38:02,120 --> 00:38:04,720
Ir mes kalbame šiek tiek
apie tai, ką tai reiškia, kaip mes

901
00:38:04,720 --> 00:38:06,550
gauti į kitą porą diagramas.

902
00:38:06,550 --> 00:38:08,716
>> Pirmas dalykas, kurį mes padarysime
yra mes kalbame apie lentelių.

903
00:38:08,716 --> 00:38:10,857
API duomenų tipai Dynamo.

904
00:38:10,857 --> 00:38:13,190
Ir pirmas dalykas, kurį jūs
pastebėsite, kai jums pažvelgti į tai,

905
00:38:13,190 --> 00:38:17,930
Jei esate susipažinę su bet duomenų bazėje,
duomenų bazės tikrai du rūšies API

906
00:38:17,930 --> 00:38:18,430
Aš jį vadiname.

907
00:38:18,430 --> 00:38:21,570
Arba dvi API.

908
00:38:21,570 --> 00:38:23,840
Vienas iš tų, būtų
administracinis API.

909
00:38:23,840 --> 00:38:26,710
>> Tai, ką jie rūpinasi
Duomenų bazės funkcijos.

910
00:38:26,710 --> 00:38:31,340
Saugojimo variklį konfigūravimas,
steigti ir pridedant lentelių.

911
00:38:31,340 --> 00:38:35,180
sukurti duomenų
katalogai ir atvejų.

912
00:38:35,180 --> 00:38:40,450
Tai Quake į DynamoDB, jums
turi labai trumpus, trumpus sąrašus.

913
00:38:40,450 --> 00:38:43,120
>> Taigi kitomis duomenų bazėmis,
jūs galite pamatyti dešimtis

914
00:38:43,120 --> 00:38:45,680
komandų, iš administracinių
komandas, konfigūravimas

915
00:38:45,680 --> 00:38:47,290
Šios papildomos galimybės.

916
00:38:47,290 --> 00:38:51,234
Be DynamoDB jums nereikia tiems nes
Jums nereikia konfigūruoti sistemą, mes darome.

917
00:38:51,234 --> 00:38:54,150
Taigi vienintelis dalykas, ką jums reikia padaryti, tai
pasakykite man, ką Dydžių lentelė man reikia.

918
00:38:54,150 --> 00:38:55,660
Taigi Jūs gaunate labai
ribotas rinkinys komandas.

919
00:38:55,660 --> 00:38:58,618
>> Gauni CREATE TABLE Update, Stalo,
Ištrinti lentelę, ir aprašyti lentelę.

920
00:38:58,618 --> 00:39:01,150
Tie, kurie tik ką
jums reikia DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Jums nereikia saugojimo
Variklio konfigūracija.

922
00:39:03,294 --> 00:39:04,960
Man nereikia nerimauti replikacija.

923
00:39:04,960 --> 00:39:06,490
Man nereikia nerimauti sharding.

924
00:39:06,490 --> 00:39:07,800
>> Man nereikia jaudintis
apie bet kokį šio stuff.

925
00:39:07,800 --> 00:39:08,740
Mes visa tai už jus.

926
00:39:08,740 --> 00:39:11,867
Taigi, kad didžiulis pridėtinių
kad tiesiog nuimti savo plokštelę.

927
00:39:11,867 --> 00:39:13,200
Tada mes turime CRUD operatorius.

928
00:39:13,200 --> 00:39:17,740
CRUD yra kažkas, ką mes
skambinti duomenų bazėje ŠTAI

929
00:39:17,740 --> 00:39:19,860
Kurti, atnaujinti, naikinti operatorius.

930
00:39:19,860 --> 00:39:24,180
Tai yra jūsų bendra
duomenų bazės operacijų.

931
00:39:24,180 --> 00:39:31,299
Dalykų, pavyzdžiui, pripilk punkte, gauti elementą, atnaujinimas
daiktų, ištrinti elementus, partijos užklausą, nuskaityti.

932
00:39:31,299 --> 00:39:32,840
Jei norite nuskaityti visą lentelę.

933
00:39:32,840 --> 00:39:34,220
Ištraukite viską nuo stalo.

934
00:39:34,220 --> 00:39:37,130
Vienas iš gražumynai apie DynamoDB
tai leidžia lygiagrečiai skenavimas.

935
00:39:37,130 --> 00:39:40,602
Taigi jūs iš tikrųjų galite leiskite man žinoti, kiek
Siūlai norite paleisti tą nuskaitymas.

936
00:39:40,602 --> 00:39:41,810
Ir mes galime paleisti tuos temas.

937
00:39:41,810 --> 00:39:43,985
Mes galime nugara, kad nuskaityti iki
keliose temas

938
00:39:43,985 --> 00:39:49,060
todėl jūs galite nuskaityti visą lentelę
vietos labai, labai greitai DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Kitas API mes turime yra
ką mes vadiname mūsų Srautai API.

940
00:39:51,490 --> 00:39:52,940
Mes neketiname kalbėti per
daug apie tai dabar.

941
00:39:52,940 --> 00:39:55,189
Aš turiu kai turinys vėliau
On, apie tai denio.

942
00:39:55,189 --> 00:39:59,910
Bet Srautai yra tikrai running--
galvoti apie tai, kaip laikas užsisakyti

943
00:39:59,910 --> 00:40:01,274
ir pertvarų Pakeitimai registruojami.

944
00:40:01,274 --> 00:40:03,940
Viskas, kas vyksta ant
Lentelėje rodo ant upelio.

945
00:40:03,940 --> 00:40:05,940
>> Kiekvienas rašyti prie stalo
rodo ant upelio.

946
00:40:05,940 --> 00:40:08,370
Galite skaityti, kad srautą ir
galite daryti tai, ko su juo.

947
00:40:08,370 --> 00:40:10,150
Mes kalbame apie tai, ką
rūšių dalykų, kuriuos

948
00:40:10,150 --> 00:40:13,680
daryti su, pavyzdžiui, replikacijos dalykų,
kuriant antrinius rodiklius.

949
00:40:13,680 --> 00:40:17,620
Visi tikrai cool rūšių
dalykų, kuriuos galite padaryti, kad.

950
00:40:17,620 --> 00:40:19,150
>> Duomenų tipai.

951
00:40:19,150 --> 00:40:23,320
Be DynamoDB, mes remiame tiek raktą
Pigūs ir dokumentų duomenų tipai.

952
00:40:23,320 --> 00:40:26,350
Kairėje pusėje ekrano
čia mes turime mūsų pagrindinius tipus.

953
00:40:26,350 --> 00:40:27,230
Pagrindiniai vertės rūšių.

954
00:40:27,230 --> 00:40:30,040
Tai yra įsipareigojimų,
numeriai ir dvejetainius.

955
00:40:30,040 --> 00:40:31,640
>> Taigi tik trys pagrindinės rūšys.

956
00:40:31,640 --> 00:40:33,700
Ir tada jūs galite turėti rinkiniai tie.

957
00:40:33,700 --> 00:40:37,650
Vienas iš gražumynai apie NoSQL yra
Jums gali būti masyvus, kaip savybėmis.

958
00:40:37,650 --> 00:40:42,050
Ir su DynamoDB galite būti masyvus
Pagrindinių tipų kaip šaknis turtą.

959
00:40:42,050 --> 00:40:43,885
>> Ir tada ten dokumentų tipus.

960
00:40:43,885 --> 00:40:45,510
Kiek žmonių yra susipažinę su JSON?

961
00:40:45,510 --> 00:40:47,130
Vaikinai susipažinę su JSON tiek daug?

962
00:40:47,130 --> 00:40:49,380
Tai iš esmės Javaskriptą,
Objektas, Žymėjimai.

963
00:40:49,380 --> 00:40:52,510
Jis leidžia jums esmės
apibrėžti hierarchinis struktūrą.

964
00:40:52,510 --> 00:40:58,107
>> Galite išsaugoti JSON dokumentą
DynamoDB naudojant bendrus komponentus

965
00:40:58,107 --> 00:41:00,940
arba statybiniai blokai, kurie yra prieinami
daugeliu programavimo kalbų.

966
00:41:00,940 --> 00:41:03,602
Taigi, jei turite Java, jūs
žiūri žemėlapius ir sąrašus.

967
00:41:03,602 --> 00:41:05,060
Galiu sukurti objektai, kad Apylinkių žemėlapis.

968
00:41:05,060 --> 00:41:08,030
Žemėlapį kaip pagrindinių vertybių
saugomi kaip savybėmis.

969
00:41:08,030 --> 00:41:10,890
Ir tai gali turėti sąrašus
vertės per šių savybių.

970
00:41:10,890 --> 00:41:13,490
Galite išsaugoti šį kompleksą
hierarchinė struktūra

971
00:41:13,490 --> 00:41:16,320
kaip vieną atributą
iš DynamoDB prekę nėra.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Taigi lenteles DynamoDB, kaip ir dauguma
NoSQL duomenų bazės, lentelės turi daiktų.

974
00:41:24,460 --> 00:41:26,469
Be MongoDB darytumėte
skambinti šiuos dokumentus.

975
00:41:26,469 --> 00:41:27,760
Ir tai būtų sofos bazę.

976
00:41:27,760 --> 00:41:28,900
Dokumentas taip pat duomenų.

977
00:41:28,900 --> 00:41:29,941
Jūs vadinate šiuos dokumentus.

978
00:41:29,941 --> 00:41:32,930
Dokumentai arba turėti atributus.

979
00:41:32,930 --> 00:41:35,850
Atributai gali egzistuoti arba
nėra ant elemento.

980
00:41:35,850 --> 00:41:38,520
Be DynamoDB, ten
vienas privalomas atributas.

981
00:41:38,520 --> 00:41:43,880
Tiesiog norėčiau į reliacinės duomenų bazės,
turite pirminį raktą ant stalo.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB turi tai, ką mes vadiname maišos klavišą.

983
00:41:46,010 --> 00:41:48,280
Hash raktas turi būti unikalus.

984
00:41:48,280 --> 00:41:52,580
Taigi, kai aš apibrėžti maišos lentelę,
Iš esmės, ką aš sakau

985
00:41:52,580 --> 00:41:54,110
yra kiekvienas daiktas turi maišos klavišą.

986
00:41:54,110 --> 00:41:58,520
Ir kas maišos raktas turi būti unikalus.

987
00:41:58,520 --> 00:42:01,200
>> Kiekvienas elementas yra apibrėžta
tos unikalios maišos raktu.

988
00:42:01,200 --> 00:42:02,940
Ir ten gali būti tik vienas.

989
00:42:02,940 --> 00:42:05,820
Tai gerai, bet dažnai
ką žmonės turi

990
00:42:05,820 --> 00:42:08,170
yra jie nori tai maišos
raktas padaryti šiek tiek daugiau

991
00:42:08,170 --> 00:42:11,010
nei tiesiog būti nurodomas unikalus identifikatorius.

992
00:42:11,010 --> 00:42:15,240
Dažnai mes norime naudoti šią maišos raktą
kaip aukščiausio lygio agregavimo kibirą.

993
00:42:15,240 --> 00:42:19,160
Ir kaip mes tai padaryti yra
pridedant tai, ką mes vadiname nuotolio klavišą.

994
00:42:19,160 --> 00:42:22,460
>> Taigi, jei tai tik maišos
stalo, tai turi būti unikalus.

995
00:42:22,460 --> 00:42:27,040
Jei tai maišos ir asortimentas lentelė,
derinys maišos ir intervale

996
00:42:27,040 --> 00:42:28,640
turi būti unikalus.

997
00:42:28,640 --> 00:42:30,110
Taigi manau, apie tai šiuo būdu.

998
00:42:30,110 --> 00:42:32,140
Jei turiu forumą.

999
00:42:32,140 --> 00:42:39,010
Ir forma yra temos, ji turi
pareigų, jis turi atsakymus.

1000
00:42:39,010 --> 00:42:42,630
>> Taigi, aš gali turėti maišos
raktas, kuris yra tema ID.

1001
00:42:42,630 --> 00:42:46,650
Ir aš gali turėti nuotolio raktą,
kuris yra atsakas ID.

1002
00:42:46,650 --> 00:42:49,650
Tokiu būdu, jei noriu gauti visi
Atsakymai tikra tema,

1003
00:42:49,650 --> 00:42:52,370
Aš galiu tik užklausti maišos.

1004
00:42:52,370 --> 00:42:55,190
Galiu tik pasakyti, man visi
elementus, kurie turi šį maišos.

1005
00:42:55,190 --> 00:43:01,910
Ir aš ruošiuosi gauti kiekvieną klausimą
arba rašyti šiuo konkrečiu klausimu.

1006
00:43:01,910 --> 00:43:03,910
Šie aukščiausio lygio agregavimai
yra labai svarbūs.

1007
00:43:03,910 --> 00:43:07,370
Jie remia pagrindinį prieigą
modelio taikymo.

1008
00:43:07,370 --> 00:43:09,420
Apskritai, šis
yra tai, ką mes norime daryti.

1009
00:43:09,420 --> 00:43:11,780
Mes norime, kad table--
kaip jums įkelti lentelę,

1010
00:43:11,780 --> 00:43:16,640
norime struktūrizuoti duomenis
per tokiu būdu, stalo

1011
00:43:16,640 --> 00:43:20,140
kad paraiška gali labai
greitai gauti tuos rezultatus.

1012
00:43:20,140 --> 00:43:24,510
Ir dažnai būdas tai padaryti yra
išlaikyti šias sankaupas, kaip mes

1013
00:43:24,510 --> 00:43:25,650
įterpti duomenis.

1014
00:43:25,650 --> 00:43:31,110
Iš esmės, mes skleisti duomenis
į šviesią kibirą, nes ji ateina.

1015
00:43:31,110 --> 00:43:35,210
>> Klasės raktai leidžia me-- maišos
raktai turi būti lygybė.

1016
00:43:35,210 --> 00:43:39,490
Kai aš užklausą maišos, turiu pasakyti,
duok man maišos, lygią tai.

1017
00:43:39,490 --> 00:43:41,950
Kai aš užklausti asortimentą, aš
galima sakyti, duok man asortimentą

1018
00:43:41,950 --> 00:43:47,040
kad yra naudojant bet kokios rūšies
turtingas operatorius, mes remiame.

1019
00:43:47,040 --> 00:43:49,200
Duok man visas maišos elementus.

1020
00:43:49,200 --> 00:43:52,520
Ar tai lygūs, didesnė
mažiau nei, ji prasideda,

1021
00:43:52,520 --> 00:43:54,145
ji egzistuoja tarp šių dviejų verčių?

1022
00:43:54,145 --> 00:43:56,811
Todėl šie diapazono užklausų tipai
kad mes visada domina.

1023
00:43:56,811 --> 00:43:59,650
Dabar vienas dalykas apie duomenis, kai
pažvelgti prieigą prie duomenų, kai

1024
00:43:59,650 --> 00:44:02,360
Jums prieiti prie duomenų, tai
visada apie An agregaciją.

1025
00:44:02,360 --> 00:44:05,770
Jis visada apie įrašų
, kurie yra susiję su tai.

1026
00:44:05,770 --> 00:44:10,390
Duok man viską čia that's-- visi
dėl šio kredito kortelės sandorių

1027
00:44:10,390 --> 00:44:12,500
paskutinį mėnesį.

1028
00:44:12,500 --> 00:44:13,960
Tai labai agregacija.

1029
00:44:13,960 --> 00:44:17,490
>> Beveik viską, ką daryti į
duomenų bazė yra keletas sumavimo natūra.

1030
00:44:17,490 --> 00:44:21,530
Taigi, kad galėtų būti suteikta apibrėžti
Šie kaušai ir duoti jums šias asortimentą

1031
00:44:21,530 --> 00:44:24,950
atributus, kad būtų galima užklausti apie,
turtuoliams užklausos remti daug,

1032
00:44:24,950 --> 00:44:27,165
daug, daug taikymas prieigos modelius.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Taigi kitas dalykas maišos pagrindinis
Ar tai suteikia mums mechanizmą

1035
00:44:35,000 --> 00:44:37,740
kad būtų galima skleisti duomenis aplink.

1036
00:44:37,740 --> 00:44:40,390
NoSQL duomenų bazės geriausiai veikia
kai duomenys yra tolygiai

1037
00:44:40,390 --> 00:44:41,740
pasiskirstęs klasterius.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Kiek žmonių yra susipažinę
su maišos algoritmai?

1040
00:44:47,050 --> 00:44:49,860
Kai aš sakau, maišos ir hashing--
nes yra maišos algoritmą

1041
00:44:49,860 --> 00:44:54,140
yra, kad galėtų generuoti būdas
atsitiktinis vertė iš bet kurios vertė.

1042
00:44:54,140 --> 00:44:59,300
Taigi, šiame konkrečiu atveju
maišos algoritmas mes paleisti ND 5 pagrįsta.

1043
00:44:59,300 --> 00:45:04,765
>> Ir jei turiu ID, ir tai
mano maišos raktas, turiu 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Kai aš paleisti maišos algoritmą,
jis ketina grįžti ir pasakyti,

1045
00:45:07,390 --> 00:45:10,800
gerai 1 lygu 7B, 2
lygi 48, 3 yra lygus CD.

1046
00:45:10,800 --> 00:45:13,092
Jie išplito visame rakto erdvėje.

1047
00:45:13,092 --> 00:45:14,050
Ir kodėl jums tai padaryti?

1048
00:45:14,050 --> 00:45:17,120
Nes tai užtikrina, kad galiu
įdėti įrašus keliose mazgų.

1049
00:45:17,120 --> 00:45:19,574
>> Jei darau tai
pakopomis, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Ir aš turiu maišos asortimentą, kuris
Veikia šiuo konkrečiu atveju,

1051
00:45:21,990 --> 00:45:24,785
mažas maišos erdvės,
ji veikia nuo 00 iki FF,

1052
00:45:24,785 --> 00:45:27,951
tada įrašai ketinate ateiti
ir jie ketina eiti 1, 2, 3, 4, 5,

1053
00:45:27,951 --> 00:45:30,390
6, 7, 8, 9, 10, 11, 12.

1054
00:45:30,390 --> 00:45:31,800
Kas atsitinka?

1055
00:45:31,800 --> 00:45:34,860
Kiekvienas įdėklas vyksta prie to paties mazge.

1056
00:45:34,860 --> 00:45:36,070
Jūs matote, ką turiu galvoje?

1057
00:45:36,070 --> 00:45:40,910
>> Nes kai aš padalinti erdvę,
ir aš skleisti šiuos įrašus visoje,

1058
00:45:40,910 --> 00:45:45,950
ir aš pertvarų, aš ruošiuosi pasakyti
1 skaidinys turi svarbų vietos 0 iki 54.

1059
00:45:45,950 --> 00:45:47,720
Pasiskirstymo 2 yra nuo 55 iki 89.

1060
00:45:47,720 --> 00:45:49,780
Pasiskirstymo 3 AA FF.

1061
00:45:49,780 --> 00:45:53,740
Taigi, jei aš naudoju tiesiškai incrementing
ID, jūs galite pamatyti, kas vyksta.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, visi būdas iki 54.

1063
00:45:57,410 --> 00:46:00,030
Taigi, kaip aš kala
įrašų į sistemą,

1064
00:46:00,030 --> 00:46:02,030
viskas baigiasi vyksta į vieną mazgą.

1065
00:46:02,030 --> 00:46:03,160
>> Tai nėra gerai.

1066
00:46:03,160 --> 00:46:04,820
Tai labai antipattern.

1067
00:46:04,820 --> 00:46:08,760
Be MongoDB jie turi šią problemą
Jei nenorite naudoti maišos klavišą.

1068
00:46:08,760 --> 00:46:11,325
MongoDB suteikia jums galimybę
iš maišos pagrindinį vertę.

1069
00:46:11,325 --> 00:46:13,950
Jūs visada turėtumėte daryti, jei
Jūs naudojate incrementing maišos

1070
00:46:13,950 --> 00:46:17,380
raktas MongoDB, ar jums bus
vinimis kas rašyti į vieną mazgą,

1071
00:46:17,380 --> 00:46:21,290
ir jums bus apriboti
Jūsų Parašyti pralaidumas blogai.

1072
00:46:21,290 --> 00:46:24,896
>> Auditorija: Ar tai A9 169 dešimtosios?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Taip, tai
kažkur aplink ten.

1074
00:46:28,450 --> 00:46:29,950
A9, aš nežinau.

1075
00:46:29,950 --> 00:46:32,200
Jūs norite turėti gauti mano dvejetainis
į dešimtainį skaičiuoklė.

1076
00:46:32,200 --> 00:46:34,237
Mano smegenys neveikia, kaip kad.

1077
00:46:34,237 --> 00:46:36,320
Auditorija: Tiesiog greitai vienas
Jūsų Mongo komentarus.

1078
00:46:36,320 --> 00:46:39,530
Taigi yra Objekto ID, kuris ateina
gimtoji su Mongo tai padaryti?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Ar tai padaryti?

1081
00:46:41,470 --> 00:46:42,970
Jei tai nurodyti.

1082
00:46:42,970 --> 00:46:45,030
Su MongoDB, jūs turite galimybę.

1083
00:46:45,030 --> 00:46:48,930
Galite specify-- kiekvieną dokumentą
MongoDB turi turėti pabraukimo ID.

1084
00:46:48,930 --> 00:46:50,300
Štai unikalus vertė.

1085
00:46:50,300 --> 00:46:55,240
>> Be MongoDB galite nurodyti
ar maišos, ar ne.

1086
00:46:55,240 --> 00:46:56,490
Jie tiesiog suteikti jums galimybę.

1087
00:46:56,490 --> 00:46:58,198
Jei žinote, kad tai
atsitiktinai, ne problema.

1088
00:46:58,198 --> 00:46:59,640
Jums nereikia daryti.

1089
00:46:59,640 --> 00:47:04,260
Jei žinote, kad tai nėra atsitiktiniai, kad
tai pokyčio, tada padaryti maišos.

1090
00:47:04,260 --> 00:47:06,880
>> Dabar apie ką
maišos, kai jūs maišos

1091
00:47:06,880 --> 00:47:08,800
value-- ir tai yra
kodėl maišos raktai visada

1092
00:47:08,800 --> 00:47:13,740
unikalių užklausos, nes aš pasikeitė
vertė, dabar aš negaliu padaryti nuotolio užklausą.

1093
00:47:13,740 --> 00:47:15,640
Aš negaliu pasakyti, ar tai
tarp tą ar aną,

1094
00:47:15,640 --> 00:47:20,800
nes maišos vertė nesiruošia
būtų lygiavertė tikrosios vertės.

1095
00:47:20,800 --> 00:47:24,570
Taigi, kai jūs maišos, kad
raktas, tai tik lygybė.

1096
00:47:24,570 --> 00:47:28,700
Tai kodėl DynamoDB maišos raktą
užklausos visada tik lygybė.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Taigi, dabar tam tikrame intervale key--
kai aš pridėti, kad svyruoja raktą,

1099
00:47:34,700 --> 00:47:38,180
tie klasės pagrindiniai fiksuoja visus ateiti ir
jie gauti saugomi ant tos pačios disko.

1100
00:47:38,180 --> 00:47:42,430
Taigi jie yra labai greitai, lengvai
Gauta, nes tai yra maišos,

1101
00:47:42,430 --> 00:47:43,220
tai yra intervalas.

1102
00:47:43,220 --> 00:47:44,928
Ir jūs matote viską
su tuo pačiu maišos

1103
00:47:44,928 --> 00:47:48,550
pasireiškia saugomi ant tos pačios pasiskirstymo erdvėje.

1104
00:47:48,550 --> 00:47:53,889
Jūs galite naudoti tą intervalą raktą padėti
rasti savo duomenis arti savo tėvų.

1105
00:47:53,889 --> 00:47:55,180
Taigi, ką aš tikrai čia darai?

1106
00:47:55,180 --> 00:47:57,320
Tai yra vienas su daugeliu santykius.

1107
00:47:57,320 --> 00:48:01,490
Skirtumas tarp maišos rakto santykiai
ir asortimentas raktas yra vienas, kad daugelis.

1108
00:48:01,490 --> 00:48:03,490
Galiu turėti kelis maišos raktus.

1109
00:48:03,490 --> 00:48:07,610
Aš gali turėti tik kelis asortimentą
raktai per kiekvieną maišos klavišą.

1110
00:48:07,610 --> 00:48:11,910
>> Maišos apibrėžia tėvų,
diapazonas apibrėžia vaikus.

1111
00:48:11,910 --> 00:48:15,240
Taigi jūs galite pamatyti ten analoginis čia
tarp reliacinės konstrukto

1112
00:48:15,240 --> 00:48:18,840
ir tie patys tipai
stato į NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Žmonės kalbėti apie
NoSQL kaip nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Tai ne nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Duomenų visada turi santykius.

1116
00:48:24,680 --> 00:48:28,172
Šie santykiai tik
modeliuojami skirtingai.

1117
00:48:28,172 --> 00:48:29,880
Pakalbėkime šiek tiek
tiek apie ilgaamžiškumą.

1118
00:48:29,880 --> 00:48:34,860
Rašydami į DynamoDB, rašo
visada trieigis pakartotas.

1119
00:48:34,860 --> 00:48:37,550
Tai reiškia, kad mes turime tris AZ-aisiais.

1120
00:48:37,550 --> 00:48:39,160
AZ produkto "yra prieinamumas zonose.

1121
00:48:39,160 --> 00:48:43,430
Jūs galite galvoti prieinamumas
Zona, kaip duomenų centre

1122
00:48:43,430 --> 00:48:45,447
arba duomenų centrų kolekcija.

1123
00:48:45,447 --> 00:48:47,780
Šie dalykai yra geografiškai
izoliuotos viena nuo kitos

1124
00:48:47,780 --> 00:48:51,610
įvairiose gedimų zonų visoje
skiriasi elektros tinklų ir salpos.

1125
00:48:51,610 --> 00:48:54,510
A viena AZ nepakankamumas nėra
ketina imtis žemyn kitą.

1126
00:48:54,510 --> 00:48:56,890
Jie taip pat susijęs
kartu su tamsiai pluošto.

1127
00:48:56,890 --> 00:49:01,240
Jis palaiko vieną sub 1
milisekundės latentinis tarp AZS.

1128
00:49:01,240 --> 00:49:05,390
Taigi realaus laiko duomenų atsikirtimai
gali daugiabučiuose AZS.

1129
00:49:05,390 --> 00:49:09,990
>> Ir dažnai multi AZ dislokavimo
atitinka aukštus prieinamumo reikalavimus

1130
00:49:09,990 --> 00:49:12,930
Daugumos įmonių organizacijų.

1131
00:49:12,930 --> 00:49:16,139
Taigi DynamoDB plinta
per tris AZS pagal nutylėjimą.

1132
00:49:16,139 --> 00:49:19,430
Mes tik ketina žinių įrašymo
kai du iš šių trijų mazgų grįžti

1133
00:49:19,430 --> 00:49:21,470
ir pasakyti, Taip, aš turiu jį.

1134
00:49:21,470 --> 00:49:22,050
Kodėl taip yra?

1135
00:49:22,050 --> 00:49:25,950
Kadangi ant nuskaitymo pusėje mes tik
ketina suteikti jums duomenis atgal, kai

1136
00:49:25,950 --> 00:49:27,570
mes gauti iš dviejų mazgų.

1137
00:49:27,570 --> 00:49:30,490
>> Jei aš atkartojantis visoje
trys, o aš skaitau iš dviejų,

1138
00:49:30,490 --> 00:49:32,840
Aš visada garantuota
turėti bent vieną

1139
00:49:32,840 --> 00:49:35,720
iš tų, skaito būti
Naujausią kopija duomenis.

1140
00:49:35,720 --> 00:49:38,340
Štai ką daro DynamoDB nuoseklūs.

1141
00:49:38,340 --> 00:49:42,450
Dabar galite pasirinkti pasukti
tie nuosekliai skaito išjungtas.

1142
00:49:42,450 --> 00:49:45,070
Tokiu atveju aš ruošiuosi pasakyti,
Aš perskaičiau tik iš vienos mazgas.

1143
00:49:45,070 --> 00:49:47,430
Ir aš negaliu garantuoti, kad jis ketina
būti naujausią duomenų.

1144
00:49:47,430 --> 00:49:49,450
>> Taigi, jei Parašyti ateina,
ji nėra pakartotas dar,

1145
00:49:49,450 --> 00:49:50,360
jūs ketinate gauti, kad kopija.

1146
00:49:50,360 --> 00:49:52,220
Tai labai galiausiai nuosekliai skaityti.

1147
00:49:52,220 --> 00:49:54,640
Ir kas tai yra pusė išlaidų.

1148
00:49:54,640 --> 00:49:56,140
Taigi tai yra kažkas galvoti apie tai.

1149
00:49:56,140 --> 00:50:00,160
Kai jūs skaitote iš DynamoDB ir
jūs įkurti savo skaitymo gebėjimus

1150
00:50:00,160 --> 00:50:04,430
vienetai, jei pasirinksite galiausiai
nuosekliai skaito, tai daug pigiau,

1151
00:50:04,430 --> 00:50:06,010
tai apie pusę kainos.

1152
00:50:06,010 --> 00:50:09,342
>> Ir todėl taupo jūsų pinigus.

1153
00:50:09,342 --> 00:50:10,300
Bet tai yra jūsų pasirinkimas.

1154
00:50:10,300 --> 00:50:12,925
Jei norite nuosekliai skaityti ar
ir galiausiai jas nuosekliai skaityti.

1155
00:50:12,925 --> 00:50:15,720
Štai kažkas, kad jūs galite pasirinkti.

1156
00:50:15,720 --> 00:50:17,659
>> Pakalbėkime apie indeksus.

1157
00:50:17,659 --> 00:50:19,450
Taigi mes paminėti, kad
aukščiausio lygio agregacija.

1158
00:50:19,450 --> 00:50:23,720
Mes turime maišos raktus ir
mes turime nuotolio raktus.

1159
00:50:23,720 --> 00:50:24,320
Štai gražus.

1160
00:50:24,320 --> 00:50:26,950
Ir tai pirminėje stalo, aš
gavo vieną maišos raktą, aš vieną diapazoną klavišą.

1161
00:50:26,950 --> 00:50:27,783
>> Ką tai reiškia?

1162
00:50:27,783 --> 00:50:30,410
Aš turiu vieną atributą, kad aš
galite paleisti turtingas užklausas.

1163
00:50:30,410 --> 00:50:31,800
Tai diapazonas raktas.

1164
00:50:31,800 --> 00:50:35,530
Kiti atributai tą item--
Galiu filtruoti tuos atributus.

1165
00:50:35,530 --> 00:50:40,050
Bet aš negaliu daryti dalykus, pavyzdžiui, ją
prasideda, arba yra didesnis nei.

1166
00:50:40,050 --> 00:50:40,820
>> Kaip man tai padaryti?

1167
00:50:40,820 --> 00:50:42,860
Galiu sukurti indeksą.

1168
00:50:42,860 --> 00:50:45,340
Yra dviejų tipų
indeksai DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Indeksas yra tikrai
kitą lentelės vaizdas.

1170
00:50:49,002 --> 00:50:50,490
Ir vietinių antrinių indeksas.

1171
00:50:50,490 --> 00:50:51,781
>> Pirmasis mes kalbame apie.

1172
00:50:51,781 --> 00:50:57,740
Taigi vietos antrinių yra egzistavo
ant to paties disko, kaip ir duomenys.

1173
00:50:57,740 --> 00:51:00,240
Ir kaip toks, jie yra ant
tas pats fizinis mazgas.

1174
00:51:00,240 --> 00:51:01,780
Jie yra tai, ką mes vadiname nuoseklūs.

1175
00:51:01,780 --> 00:51:04,599
Kitaip tariant, jie bus pripažinti
išilgai su stalo rašymo.

1176
00:51:04,599 --> 00:51:06,890
Kai Parašyti ateina,
mes rašyti per indeksą.

1177
00:51:06,890 --> 00:51:09,306
Mes parašyti į lentelę,
ir tada mes pripažįstame.

1178
00:51:09,306 --> 00:51:10,490
Taigi, kad nuoseklūs.

1179
00:51:10,490 --> 00:51:13,174
Kai rašymo buvo
pripažino iš lentelės,

1180
00:51:13,174 --> 00:51:15,090
tai garantuoja, kad
vietinių antrinių puslapis

1181
00:51:15,090 --> 00:51:18,380
turės tą pačią viziją duomenimis.

1182
00:51:18,380 --> 00:51:22,390
Bet ką jie leidžia jums padaryti, tai
nustatyti pakaitinių nuotolio raktus.

1183
00:51:22,390 --> 00:51:25,260
>> Turi naudoti tą patį maišos
klavišą pirminės stalo,

1184
00:51:25,260 --> 00:51:29,050
nes jie yra bendrai, esantį ant
pats pertvarų, ir jie nuoseklūs.

1185
00:51:29,050 --> 00:51:33,110
Bet aš galiu sukurti indeksą
su įvairiais nuotolio raktus.

1186
00:51:33,110 --> 00:51:41,590
Taigi, pavyzdžiui, jei aš turėjo gamintojas
kad buvo žalias dalys lentelė ateina.

1187
00:51:41,590 --> 00:51:44,590
Ir žaliavinį dalys būna ir
jie sudedami surenkant.

1188
00:51:44,590 --> 00:51:46,840
O gal ten atminties.

1189
00:51:46,840 --> 00:51:50,240
>> Bet dalis, kuri buvo padaryta ši
Gamintojas po šios datos,

1190
00:51:50,240 --> 00:51:52,840
Man reikia traukti iš mano linija.

1191
00:51:52,840 --> 00:51:55,950
Galiu nugara indeksą
kad būtų ieškote,

1192
00:51:55,950 --> 00:52:00,760
sumuojant nuo dienos
Gaminame tos tikrą dalį.

1193
00:52:00,760 --> 00:52:03,930
Taigi, jei mano aukščiausio lygio stalo buvo
jau sumaišomas Gamintojo,

1194
00:52:03,930 --> 00:52:07,655
gal tai buvo išdėstyti dalis ID, aš
gali sukurti išjungti, kad stalo indeksą

1195
00:52:07,655 --> 00:52:11,140
kaip sumaišomas pagal gamintoją ir
svyravo nuo pagaminimo datos.

1196
00:52:11,140 --> 00:52:14,490
Ir tokiu būdu galėčiau pasakyti, nieko, kad
buvo pagamintas tarp šių datų,

1197
00:52:14,490 --> 00:52:16,804
Man reikia traukti iš geležinkelio linijos.

1198
00:52:16,804 --> 00:52:18,220
Taigi, kad vietos vidurinė indeksas.

1199
00:52:18,220 --> 00:52:22,280
>> Tai turi poveikį,
apriboti savo maišos pagrindinį erdvę.

1200
00:52:22,280 --> 00:52:24,360
Nes jie bendrai egzistavo
ant tos pačios saugojimo mazgas,

1201
00:52:24,360 --> 00:52:26,860
jie riboja maišos raktą
erdvė 10 gigabaitų.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB pagal
stalai, bus išskaidyti

1203
00:52:28,950 --> 00:52:31,380
jūsų stalo kas 10 gigabaitų.

1204
00:52:31,380 --> 00:52:34,760
Kai jūs galėsite įdėti 10 koncertai duomenų, mes
eiti [PhH], ir mes pridėsime dar vieną mazgą.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Mes ne padalinti LSI
visoje keletą skirsnių.

1207
00:52:42,070 --> 00:52:43,200
Mes padalinti lentelę.

1208
00:52:43,200 --> 00:52:44,679
Bet mes ne padalinti LSI.

1209
00:52:44,679 --> 00:52:46,470
Taigi, kad kažkas
Svarbu suprasti

1210
00:52:46,470 --> 00:52:50,070
yra, jei jūs darote labai,
labai, labai dideli apibendrinus,

1211
00:52:50,070 --> 00:52:53,860
tada jūs ketinate būti apribota
10 gigabaitų jūsų LSIs.

1212
00:52:53,860 --> 00:52:56,640
>> Jei tai toks atvejis, mes galime
naudoti pasaulinius antrinių.

1213
00:52:56,640 --> 00:52:58,630
Global antrinių yra
tikrai kito stalo.

1214
00:52:58,630 --> 00:53:01,720
Jie egzistuoja visiškai išjungti
Jūsų pirminės lentelės pusėje.

1215
00:53:01,720 --> 00:53:04,680
Ir jie leidžia man rasti
visiškai kitokia struktūra.

1216
00:53:04,680 --> 00:53:08,010
Taigi manau, apie tai, kaip duomenys yra įdėta
į dvi skirtingas lenteles, struktūra

1217
00:53:08,010 --> 00:53:09,220
dviem skirtingais būdais.

1218
00:53:09,220 --> 00:53:11,360
>> Galiu apibrėžti visiškai
skiriasi maišos raktas.

1219
00:53:11,360 --> 00:53:13,490
Galiu apibrėžti visiškai
skiriasi asortimentas raktas.

1220
00:53:13,490 --> 00:53:15,941
Ir aš galiu paleisti tai
visiškai nepriklausomai.

1221
00:53:15,941 --> 00:53:18,190
Kaip iš tiesų, aš
numatęs mano skaitymo gebėjimus

1222
00:53:18,190 --> 00:53:21,090
ir rašyti pajėgumus Mano
pasauliniai vidurinės indeksai

1223
00:53:21,090 --> 00:53:24,240
visiškai nepriklausomai
mano pirminės stalo.

1224
00:53:24,240 --> 00:53:26,640
Jei aš apibrėžti šio indekso, sakau
tai, kiek skaityti ir rašyti

1225
00:53:26,640 --> 00:53:28,610
talpa tai ketinate naudoti.

1226
00:53:28,610 --> 00:53:31,490
>> Ir tai yra atskiras
nuo mano pirminio stalo.

1227
00:53:31,490 --> 00:53:35,240
Dabar abi indeksų leisti mus
ne tik apibrėžti maišos ir nuotolio raktus,

1228
00:53:35,240 --> 00:53:38,610
tačiau jie leidžia mums
projekto papildomos vertės.

1229
00:53:38,610 --> 00:53:44,950
Taigi, jei aš noriu skaityti nuo indekso,
ir aš noriu kažkiek duomenų rinkinys,

1230
00:53:44,950 --> 00:53:48,327
Man nereikia grįžti į pagrindinis
Lentelėje gauti papildomus atributus.

1231
00:53:48,327 --> 00:53:50,660
Galiu projektuoti šias papildomas
atributus į lentelę

1232
00:53:50,660 --> 00:53:53,440
remti prieigos modelis.

1233
00:53:53,440 --> 00:53:57,700
Aš žinau, mes tikriausiai patekti į kai
tikrai, really-- patekti į piktžolių

1234
00:53:57,700 --> 00:53:58,910
čia kai šios medžiagos.

1235
00:53:58,910 --> 00:54:02,725
Dabar aš turiu dreifas iš šio.

1236
00:54:02,725 --> 00:54:07,320
>> Auditorija: [nesigirdi]
--table raktas reiškė buvo maišos?

1237
00:54:07,320 --> 00:54:08,840
Originali maišos?

1238
00:54:08,840 --> 00:54:09,340
Multi-skersiniai?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Taip.

1240
00:54:10,200 --> 00:54:11,070
Taip.

1241
00:54:11,070 --> 00:54:15,260
Lentelėje raktas iš esmės
atkreipia atgal į elementą.

1242
00:54:15,260 --> 00:54:19,280
Taigi indeksas yra rodyklė atgal į
originalūs daiktai ant stalo.

1243
00:54:19,280 --> 00:54:22,910
Dabar galite pasirinkti statyti
puslapis, kuris turi tik stalo raktą,

1244
00:54:22,910 --> 00:54:24,840
ir jokių kitų savybių.

1245
00:54:24,840 --> 00:54:26,570
Ir kodėl gali tai padaryti?

1246
00:54:26,570 --> 00:54:28,570
Na, gal aš turiu labai daug daiktų.

1247
00:54:28,570 --> 00:54:31,660
>> Aš tikrai tik reikia žinoti which--
Mano prieiga modelis gali pasakyti,

1248
00:54:31,660 --> 00:54:33,760
kokie daiktai yra šį objektą?

1249
00:54:33,760 --> 00:54:35,780
Nereikia grąžinti daiktą.

1250
00:54:35,780 --> 00:54:37,800
Aš tiesiog reikia žinoti
kokie daiktai yra ją.

1251
00:54:37,800 --> 00:54:40,700
Taigi galite sukurti indeksus
kad tik stalo klavišą.

1252
00:54:40,700 --> 00:54:43,360
>> Bet tai daugiausia ką
in indeksas, duomenų bazės yra.

1253
00:54:43,360 --> 00:54:46,280
Tai už tai, kad galėtų greitai
nustatyti, kurie fiksuoja,

1254
00:54:46,280 --> 00:54:49,470
kurios eilutės, kurios
Produktai stalo turi

1255
00:54:49,470 --> 00:54:51,080
savybės, kad aš ieško.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIs, taip, kaip jie veikia?

1258
00:54:54,860 --> 00:54:58,340
GSIs esmės yra asinchroninis.

1259
00:54:58,340 --> 00:55:02,570
Atnaujinimo ateina į lentelę,
lentelė tada asinchroniškai atnaujinama

1260
00:55:02,570 --> 00:55:03,720
visus savo GSIs.

1261
00:55:03,720 --> 00:55:06,680
Tai kodėl GSIs yra
galiausiai suderintos.

1262
00:55:06,680 --> 00:55:09,440
>> Svarbu pažymėti, kad
jei esate pastate GSIs,

1263
00:55:09,440 --> 00:55:13,110
ir jūs suprantate, kuriate
Kitas aspektas aggregation--

1264
00:55:13,110 --> 00:55:16,594
Dabar tarkime, gerą pavyzdį
čia yra gamintojas.

1265
00:55:16,594 --> 00:55:19,260
Manau, kad galėjo kalbėjo apie
medicinos prietaiso gamintojas.

1266
00:55:19,260 --> 00:55:23,870
Medicinos prietaisų gamintojai
Neretai turi išspausdintas dalių.

1267
00:55:23,870 --> 00:55:28,070
Dalys, kad pereiti į
klubo keitimas visiems

1268
00:55:28,070 --> 00:55:30,200
turėti šiek tiek serijinį numerį ant jų.

1269
00:55:30,200 --> 00:55:33,584
Ir jie gali turėti milijonus ir
milijonai ir milijardai dalys

1270
00:55:33,584 --> 00:55:35,000
visose prietaisų, kad jie laivą.

1271
00:55:35,000 --> 00:55:37,440
Na, jiems reikia sumuoti pagal
įvairių matmenų, visos dalys

1272
00:55:37,440 --> 00:55:39,520
agregate, visi
dalys, kurie buvo pagaminti

1273
00:55:39,520 --> 00:55:41,670
tam tikra linija, visa
dalys, atėjo

1274
00:55:41,670 --> 00:55:44,620
nuo tam tikro gamintojo
tam tikrą dieną.

1275
00:55:44,620 --> 00:55:47,940
Ir šie apibendrinus kartais
keltis į milijardus.

1276
00:55:47,940 --> 00:55:50,550
>> Taigi dirbu su kai
Šie vaikinai, kurie kenčia

1277
00:55:50,550 --> 00:55:53,156
nes jie sukurti
Šie Ginormous agregavimai

1278
00:55:53,156 --> 00:55:54,280
jų antrinių rodiklių.

1279
00:55:54,280 --> 00:55:57,070
Jie gali turėti žalią dalys
stalo, kad ateina kaip tik maišos.

1280
00:55:57,070 --> 00:55:59,090
Kiekviena dalis turi unikalų serijinį numerį.

1281
00:55:59,090 --> 00:56:00,975
Aš naudoju serijos numerį kaip maišos.

1282
00:56:00,975 --> 00:56:01,600
Gražu.

1283
00:56:01,600 --> 00:56:04,160
Mano žalias duomenų lentelė plinta
visoje rakto erdvėje.

1284
00:56:04,160 --> 00:56:05,930
Mano [? rašyti?]
[? Prarijus?] yra awesome.

1285
00:56:05,930 --> 00:56:07,876
Aš daug duomenų.

1286
00:56:07,876 --> 00:56:09,500
Tada, ką jie padaryti, tai jie sukurti GSI.

1287
00:56:09,500 --> 00:56:12,666
Ir aš sakau, jūs žinote, ką, man reikia pamatyti
visi šio gamintojo dalys.

1288
00:56:12,666 --> 00:56:15,060
Na, visi staiga aš
atsižvelgiant milijardo eilutes,

1289
00:56:15,060 --> 00:56:17,550
ir kita juos į
vienas mazgas, nes kai

1290
00:56:17,550 --> 00:56:21,170
I agreguoja kaip
Gamintojas ID kaip maišos,

1291
00:56:21,170 --> 00:56:25,410
ir dalies numeris kaip diapazone,
tada visi staiga aš

1292
00:56:25,410 --> 00:56:30,530
Eksploatacijos mlrd dalis į ką
tai gamintojas ir išlaisvino mane.

1293
00:56:30,530 --> 00:56:34,447
>> Tai gali sukelti daug
slėgio dėl GSI,

1294
00:56:34,447 --> 00:56:36,030
vėl, nes aš kala vieną viršūnę.

1295
00:56:36,030 --> 00:56:38,350
Aš pradėti visa tai
įterpia į vieną mazge.

1296
00:56:38,350 --> 00:56:40,940
Ir tai tikra problemiškas naudojimo atveju.

1297
00:56:40,940 --> 00:56:43,479
Dabar, aš turiu gerą dizainą
raštas, kaip jūs išvengti.

1298
00:56:43,479 --> 00:56:45,770
Ir tai viena iš problemų
kad aš visada dirbti.

1299
00:56:45,770 --> 00:56:49,590
Bet kas atsitinka, yra GSI gali
neturi pakankamai pajėgumų rašymo

1300
00:56:49,590 --> 00:56:52,330
kad būtų galima stumti visi tie,
eilutės į vieną mazgą.

1301
00:56:52,330 --> 00:56:55,390
Ir kas atsitinka tada yra
pagrindinis klientas lentelė,

1302
00:56:55,390 --> 00:57:00,180
pirminė lentelė bus paminti
nes GSI negali suspėti.

1303
00:57:00,180 --> 00:57:02,980
Taigi, mano įterpti norma
kristi ant pirminės lentelės

1304
00:57:02,980 --> 00:57:06,230
kaip mano GSI bando suspėti.

1305
00:57:06,230 --> 00:57:08,850
>> Visos teisės, todėl GSI-ųjų LSI s,
kurį iš jų turėčiau naudoti?

1306
00:57:08,850 --> 00:57:12,290
LSI s yra nuoseklūs.

1307
00:57:12,290 --> 00:57:13,750
GSI s yra galiausiai suderintos.

1308
00:57:13,750 --> 00:57:17,490
Jei tai gerai, aš rekomenduoju, naudojant
GSI, jie daug lankstesnis.

1309
00:57:17,490 --> 00:57:20,270
LSI s gali būti modeliuojama kaip GSI.

1310
00:57:20,270 --> 00:57:27,040
Ir jei duomenų dydis vienam maišos raktų
savo kolekciją viršija 10 gigabaitų,

1311
00:57:27,040 --> 00:57:31,050
tada jūs ketinate norite naudoti, kad
GSI, nes tai tik sunku riba.

1312
00:57:31,050 --> 00:57:32,035
>> Visos teisės, todėl pleiskanojimas.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Pralaidumas Dinamo BP jūs
CAN nuostata [nesigirdi]

1315
00:57:37,460 --> 00:57:38,680
pralaidumas prie stalo.

1316
00:57:38,680 --> 00:57:42,740
Mes turime klientų, kurie
numatęs 60 billion--

1317
00:57:42,740 --> 00:57:45,970
darai 60 milijardų prašymus, nuolat
veikia daugiau kaip milijono prašymų

1318
00:57:45,970 --> 00:57:47,790
per sekundę ant mūsų stalų.

1319
00:57:47,790 --> 00:57:50,360
Yra tikrai ne
teorinė riba, kiek

1320
00:57:50,360 --> 00:57:53,730
ir kaip greitai lentelė
galima paleisti "Dinamo" DB.

1321
00:57:53,730 --> 00:57:55,920
Yra keletas minkštas
ribas savo paskyros

1322
00:57:55,920 --> 00:57:58,170
kad mes įdėti ten,
kad jums nereikia eiti iš proto.

1323
00:57:58,170 --> 00:58:00,070
Jei norite daugiau nei
, kad nėra problema.

1324
00:58:00,070 --> 00:58:00,820
Jūs ateiti mums pasakyti.

1325
00:58:00,820 --> 00:58:02,810
Mes riesti ratuką.

1326
00:58:02,810 --> 00:58:08,210
>> Kiekviena sąskaita yra tik tam tikru lygiu
kiekvienoje tarnyboje, vos ne šikšnosparnis

1327
00:58:08,210 --> 00:58:11,920
todėl žmonės neturi išprotėti
gauti sau į bėdą.

1328
00:58:11,920 --> 00:58:12,840
Jokia riba dydžio.

1329
00:58:12,840 --> 00:58:14,940
Jūs galite įdėti bet kokį skaičių
daiktų ant stalo.

1330
00:58:14,940 --> 00:58:17,620
Iš elemento dydis
tik 400 kilobaitų kiekvienas,

1331
00:58:17,620 --> 00:58:20,050
kad būtų punktas nėra atributai.

1332
00:58:20,050 --> 00:58:24,200
Taigi visų atributų suma
yra ribojamas iki 400 kilobaitų.

1333
00:58:24,200 --> 00:58:27,300
Ir tada vėl, mes turime
kad mažai LSI klausimas

1334
00:58:27,300 --> 00:58:30,405
su 10 gigabaitų dydžio vienam maišos.

1335
00:58:30,405 --> 00:58:33,280
Auditorija: Mažas skaičius, aš trūksta
ką jūs man sakai, kad is--

1336
00:58:33,280 --> 00:58:36,830
AUDITORIJA: Oi, 400 kilobaitų ilgio
yra maksimalus dydis už vienetą.

1337
00:58:36,830 --> 00:58:39,570
Taigi elementas turi visus atributus.

1338
00:58:39,570 --> 00:58:43,950
Taigi, 400 k yra bendras dydis
to elemento, 400 kilobaitų.

1339
00:58:43,950 --> 00:58:46,170
Taigi, visų požymius
kartu, visi duomenys

1340
00:58:46,170 --> 00:58:49,140
tai visų tų savybių,
suvyniotos į viso dydžio

1341
00:58:49,140 --> 00:58:51,140
Šiuo metu šiandien punktas riba yra 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Taigi mastelio vėl pasiekti
per padalijimo.

1344
00:58:57,046 --> 00:58:58,920
Pralaidumas atidėjiniai
tuo stalo lygiu.

1345
00:58:58,920 --> 00:59:00,160
Ir ten tikrai dvi rankenėles.

1346
00:59:00,160 --> 00:59:02,400
Mes perskaitėme pajėgumus
ir rašyti pajėgumus.

1347
00:59:02,400 --> 00:59:05,530
>> Taigi jie yra reguliuojamas
nepriklausomai vienas nuo kito.

1348
00:59:05,530 --> 00:59:08,640
NVP matas griežtai atitinka skaito.

1349
00:59:08,640 --> 00:59:13,005
Gerai, kad jei jūs sakote noriu 1000
RCU s tas yra griežtai nuoseklus,

1350
00:59:13,005 --> 00:59:14,130
tie, kurie atitinka skaito.

1351
00:59:14,130 --> 00:59:17,130
Jei sakai, kad aš noriu
galiausiai nuosekliai skaito,

1352
00:59:17,130 --> 00:59:19,402
galite nuostata 1000
RCU s, jūs ketinate

1353
00:59:19,402 --> 00:59:21,840
gauti 2,000 galiausiai
nuosekliai skaito.

1354
00:59:21,840 --> 00:59:25,940
Ir pusė tiems kaina
galiausiai susideda iš skaito.

1355
00:59:25,940 --> 00:59:28,520
>> Vėlgi, reguliuojamas
nepriklausomai vienas nuo kito.

1356
00:59:28,520 --> 00:59:32,900
Ir jie turi throughput--
Jei suvartojama 100% savo NVP,

1357
00:59:32,900 --> 00:59:35,960
esate nesiruošia POVEIKIS
Prieinamumas savo teises.

1358
00:59:35,960 --> 00:59:40,161
Taigi jie yra visiškai
nepriklausomi vienas nuo kito.

1359
00:59:40,161 --> 00:59:43,160
Visos teisės, todėl vienas iš dalykų, kad
Minėjau trumpai buvo pristabdyta.

1360
00:59:43,160 --> 00:59:44,320
Greičio yra blogai.

1361
00:59:44,320 --> 00:59:47,311
Greičio rodo blogai ne SQL.

1362
00:59:47,311 --> 00:59:50,310
Yra dalykų, mes galime padaryti, siekiant padėti
Jums sumažinti droselio kad jus

1363
00:59:50,310 --> 00:59:51,040
patiriame.

1364
00:59:51,040 --> 00:59:53,240
Bet geriausias sprendimas
yra tai, galime imtis

1365
00:59:53,240 --> 00:59:58,000
pažvelgti, ką jūs darote, nes
ten anti-modelis žaisti čia.

1366
00:59:58,000 --> 01:00:02,140
>> Šie dalykai, dalykų, pavyzdžiui, ne uniforma
darbo krūviai, karštieji klavišai, karšto pertvaros.

1367
01:00:02,140 --> 01:00:06,210
Aš pataikyti ypatingą pagrindinį erdvę
labai sunku dėl kokios nors ypatingos priežasties.

1368
01:00:06,210 --> 01:00:07,080
Kodėl aš darau tai?

1369
01:00:07,080 --> 01:00:08,710
Leiskite suprasti, kad iš.

1370
01:00:08,710 --> 01:00:10,427
Aš maišymo Mano karštas duomenis šalto duomenis.

1371
01:00:10,427 --> 01:00:12,510
Aš nuomos Mano stalai gauti
didžiulis, bet ten tikrai

1372
01:00:12,510 --> 01:00:15,970
tik kai kurie iš duomenų poaibis
tai tikrai įdomu man.

1373
01:00:15,970 --> 01:00:20,290
Taigi, log duomenų, pavyzdžiui, daug
klientai, jie gauna prisijunkite duomenis kiekvieną dieną.

1374
01:00:20,290 --> 01:00:22,490
Jie gavo didžiulę sumą žurnalo duomenis.

1375
01:00:22,490 --> 01:00:25,940
>> Jei jūs tik dempingo visą tą žurnalą
duomenis į vieną didelį stalo, per tam tikrą laiką

1376
01:00:25,940 --> 01:00:28,070
Ši lentelė ketina gauti masyvi.

1377
01:00:28,070 --> 01:00:30,950
Bet aš tikrai domina tik
paskutiniai 24 valandas per pastarąsias septynias dienas,

1378
01:00:30,950 --> 01:00:31,659
paskutinių 30 dienų.

1379
01:00:31,659 --> 01:00:34,074
Nepriklausomai nuo laiko langas
kad aš domiuosi ieško

1380
01:00:34,074 --> 01:00:37,010
už įvykį, kad trukdo me, arba
įvykis, įdomu man,

1381
01:00:37,010 --> 01:00:39,540
tai vienintelis langas laikas, kad man reikia.

1382
01:00:39,540 --> 01:00:42,470
Tad kodėl aš išleisti 10 metų
Verta Rąstinių duomenų lentelėje?

1383
01:00:42,470 --> 01:00:45,030
Ką tai sukelia yra
Lentelėje fragmentas.

1384
01:00:45,030 --> 01:00:45,880
>> Ji gauna milžiniškas.

1385
01:00:45,880 --> 01:00:48,340
Jis prasideda išskleidimas
visoje tūkstančių mazgų.

1386
01:00:48,340 --> 01:00:51,380
Ir nuo jūsų pajėgumas
yra toks mažas, jūs

1387
01:00:51,380 --> 01:00:54,090
iš tikrųjų, greitį ribojantis vienas nuo
vienas iš tų atskirų mazgų.

1388
01:00:54,090 --> 01:00:57,120
Taigi pradėkime žiūri kaip
mes įdiegti šią lentelę virš.

1389
01:00:57,120 --> 01:01:01,502
Kaip mes valdyti, kad duomenys šiek tiek
geriau išvengti šių problemų.

1390
01:01:01,502 --> 01:01:02,710
Ir ką tai atrodo?

1391
01:01:02,710 --> 01:01:04,370
Tai, ką tai atrodo.

1392
01:01:04,370 --> 01:01:06,790
Tai yra tai, ką blogai NoSQL atrodo.

1393
01:01:06,790 --> 01:01:07,830
>> Gavau klavišų čia.

1394
01:01:07,830 --> 01:01:10,246
Jei pažvelgti į šoną čia
visa tai yra mano pertvaros.

1395
01:01:10,246 --> 01:01:12,630
Aš turiu 16 pertvaros čia
dėl šio konkretaus duomenų bazę.

1396
01:01:12,630 --> 01:01:13,630
Mes tai visą laiką.

1397
01:01:13,630 --> 01:01:15,046
Aš paleisti šio klientams visą laiką.

1398
01:01:15,046 --> 01:01:16,550
Tai vadinama šilumos žemėlapis.

1399
01:01:16,550 --> 01:01:20,590
Šilumos žemėlapis pasakoja man, kaip jūs
gauti savo pagrindinį erdvę.

1400
01:01:20,590 --> 01:01:23,700
Ir ką tai sako man yra
kad ten vienas pirma maišos

1401
01:01:23,700 --> 01:01:26,330
kad šis vaikinas sako, kad patinka
siaubingai daug, nes jis

1402
01:01:26,330 --> 01:01:28,250
pataikyti ją tikrai, tikrai sunku.

1403
01:01:28,250 --> 01:01:29,260
>> Taigi mėlyna yra gražus.

1404
01:01:29,260 --> 01:01:29,900
Mums patinka mėlyna spalva.

1405
01:01:29,900 --> 01:01:30,720
Mums nepatinka raudona spalva.

1406
01:01:30,720 --> 01:01:33,120
Red kur slėgis
gauna iki 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, dabar jūs ketinate būti paminti.

1408
01:01:35,560 --> 01:01:39,030
Taigi, jei matote bet raudonąsias linijas, pavyzdžiui,
this-- ir tai ne tik Dinamo DB--

1409
01:01:39,030 --> 01:01:41,630
kas NoSQL duomenų turi šią problemą.

1410
01:01:41,630 --> 01:01:44,640
Yra anti-modeliai, kurie gali
vairuoti šias sąlygas tipus.

1411
01:01:44,640 --> 01:01:49,070
Kas man yra Dirbu su klientais
sumažinti šias sąlygas.

1412
01:01:49,070 --> 01:01:51,840
>> Ir ką tai atrodo?

1413
01:01:51,840 --> 01:01:54,260
Ir tai vis labiausiai
iš Dinamo DB pralaidumą,

1414
01:01:54,260 --> 01:01:56,176
bet tai tikrai gauti
labiausiai iš NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Tai ne tik Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Tai definitely-- aš
naudojami dirbti Mongo.

1417
01:02:02,050 --> 01:02:04,090
Aš esu susipažinęs su daugeliu NoSQL platformų.

1418
01:02:04,090 --> 01:02:06,830
Kiekvienas iš jų turi šių rūšių
karšto pagrindinių problemų.

1419
01:02:06,830 --> 01:02:10,320
Norėdami gauti maksimalią naudą iš bet NoSQL
duomenų, konkrečiai Dinamo DB

1420
01:02:10,320 --> 01:02:13,320
norite sukurti lenteles
kur maišos pagrindinis elementas yra

1421
01:02:13,320 --> 01:02:18,590
daug skirtingų reikšmių,
didelis galingumo.

1422
01:02:18,590 --> 01:02:22,530
Nes tai reiškia, kad aš rašau
į daug įvairių kaušų.

1423
01:02:22,530 --> 01:02:24,870
>> Kuo daugiau kaušai aš
raštu, tuo labiau tikėtina,

1424
01:02:24,870 --> 01:02:29,100
Esu skleisti tą rašymo apkrovos arba
skaityti įkelti iš visoje kelių mazgų,

1425
01:02:29,100 --> 01:02:33,560
tuo labiau tikėtina, Esu turėti
didelio našumo ant stalo.

1426
01:02:33,560 --> 01:02:37,440
Ir tada aš noriu vertybės turi būti
paprašė gana tolygiai per tam tikrą laiką

1427
01:02:37,440 --> 01:02:39,430
ir vienodai, nes atsitiktinai, kaip įmanoma.

1428
01:02:39,430 --> 01:02:42,410
Na, tai kokios įdomios,
nes aš tikrai negali

1429
01:02:42,410 --> 01:02:43,960
kontrolė, kai vartotojai ateiti.

1430
01:02:43,960 --> 01:02:47,645
Taigi pakanka pasakyti, jei mes skleisti
viskas iš visos rakto erdvėje,

1431
01:02:47,645 --> 01:02:49,270
mes tikriausiai bus geresnės formos.

1432
01:02:49,270 --> 01:02:51,522
>> Yra tam tikras
dydis pristatymo laiko

1433
01:02:51,522 --> 01:02:53,230
kad jūs nesiruošia
, kad būtų galima kontroliuoti.

1434
01:02:53,230 --> 01:02:55,438
Tačiau tie, kurie tikrai
du matmenys, kad mes turime,

1435
01:02:55,438 --> 01:02:58,800
vietos, prieigos tolygiai
plitimą, laikas, prašymai

1436
01:02:58,800 --> 01:03:01,040
Pavėlavus tolygiai išdėstyti laike.

1437
01:03:01,040 --> 01:03:03,110
Ir jei tie du
sąlygos yra įvykdytos,

1438
01:03:03,110 --> 01:03:05,610
tada tai, ką jis
atrodys.

1439
01:03:05,610 --> 01:03:07,890
Tai daug gražiau.

1440
01:03:07,890 --> 01:03:08,890
Mes tikrai laimingas čia.

1441
01:03:08,890 --> 01:03:10,432
Mes turime labai net prieigos modelis.

1442
01:03:10,432 --> 01:03:13,098
Taip, gal jūs gaunate
tiek spaudimo, kas dabar ir tada,

1443
01:03:13,098 --> 01:03:14,830
bet nieko tikrai per platus.

1444
01:03:14,830 --> 01:03:17,660
Taigi, tai nuostabu, kiek kartų,
kai dirbu su klientais,

1445
01:03:17,660 --> 01:03:20,670
kad pirmasis grafikas su Big Red
baras ir visi, kad negraži geltona tai

1446
01:03:20,670 --> 01:03:23,147
visur, mes
gauti padaryti su pratybų

1447
01:03:23,147 --> 01:03:24,980
Po porą mėnesių
pakartotinio architektūra,

1448
01:03:24,980 --> 01:03:28,050
jie veikia lygiai toks pats
darbo krūvis per tą patį krovinį.

1449
01:03:28,050 --> 01:03:30,140
Ir tai, ką jis atrodo kaip dabar.

1450
01:03:30,140 --> 01:03:36,600
Taigi, ką jūs gaunate su NoSQL yra
duomenų schemos, kuri yra absoliučiai

1451
01:03:36,600 --> 01:03:38,510
susieta su prieigos modelio.

1452
01:03:38,510 --> 01:03:42,170
>> Ir jūs galite optimizuoti, kad duomenų schema
siekiant remti šį prieigos modelis.

1453
01:03:42,170 --> 01:03:45,490
Jei ne, tada jūs ketinate
pamatyti tuos problemas rūšys

1454
01:03:45,490 --> 01:03:46,710
su tais karštieji klavišai.

1455
01:03:46,710 --> 01:03:50,518
>> Auditorija: Na, neišvengiamai keletas vietų
ketinate būti šilčiau nei kiti.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Visada.

1457
01:03:51,450 --> 01:03:51,960
Visada.

1458
01:03:51,960 --> 01:03:54,620
Taip, aš turiu galvoje, visada
a-- ir vėl, ten

1459
01:03:54,620 --> 01:03:56,980
kai dizaino modelius mes gauti per
kad kalbės apie tai, kaip jums susidoroti

1460
01:03:56,980 --> 01:03:58,480
su šiomis super didelių apibendrinimo.

1461
01:03:58,480 --> 01:04:01,260
Aš turiu galvoje, aš turiu juos,
kaip mes su jais susidoroti?

1462
01:04:01,260 --> 01:04:03,760
Aš turiu labai gerą naudojimo atveju
kad mes kalbame apie, kad.

1463
01:04:03,760 --> 01:04:05,940
>> Visos teisės, todėl pakalbėkime
apie kai klientai dabar.

1464
01:04:05,940 --> 01:04:06,950
Šie vaikinai yra Adroll.

1465
01:04:06,950 --> 01:04:08,990
Aš nežinau, jei esate
susipažinęs su Adroll.

1466
01:04:08,990 --> 01:04:10,781
Jūs tikriausiai pamatyti juos
ant naršyklėje aikštelė.

1467
01:04:10,781 --> 01:04:14,230
Jie ad naujo nukreipimas, jie
didžiausia skelbimą Re nukreipimą verslo

1468
01:04:14,230 --> 01:04:14,940
ten.

1469
01:04:14,940 --> 01:04:17,792
Jie paprastai reguliariai suvažinėti
60 milijardų sandorių per dieną.

1470
01:04:17,792 --> 01:04:20,000
Jie daro per milijoną
Pirkimas per sekundę.

1471
01:04:20,000 --> 01:04:22,660
Jie gavo gana paprastą lentelę
struktūra, judriausių stalo.

1472
01:04:22,660 --> 01:04:26,450
Tai iš esmės tik
maišos raktas yra slapukas,

1473
01:04:26,450 --> 01:04:29,010
diapazonas yra demografinis
kategorija, ir tada

1474
01:04:29,010 --> 01:04:31,220
trečiasis požymis yra rezultatas.

1475
01:04:31,220 --> 01:04:33,720
>> Taigi, mes visi turime slapukus
Mūsų naršyklė iš šių vaikinai.

1476
01:04:33,720 --> 01:04:35,900
Ir kai jūs einate į
dalyvauja pirklys,

1477
01:04:35,900 --> 01:04:39,390
jie iš esmės rezultatas jus per
įvairūs demografiniai kategorijos.

1478
01:04:39,390 --> 01:04:42,070
Kai jūs einate į svetainę ir
jūs sakote, aš noriu pamatyti šį ad--

1479
01:04:42,070 --> 01:04:44,920
arba iš esmės jūs neturite pasakyti that--
bet kai jūs einate į svetainę

1480
01:04:44,920 --> 01:04:47,550
jie sako norite matyti šį skelbimą.

1481
01:04:47,550 --> 01:04:49,370
Ir jie eikite gauti tą reklamą Adroll.

1482
01:04:49,370 --> 01:04:51,130
Adroll atrodo jus ant savo stalo.

1483
01:04:51,130 --> 01:04:52,115
Jie suprato, kad savo slapuką.

1484
01:04:52,115 --> 01:04:53,990
Reklamuotojai pasakojantys
juos, aš noriu ką nors

1485
01:04:53,990 --> 01:04:58,632
kas vidutinio amžiaus,
40-metų vyras, į sportą.

1486
01:04:58,632 --> 01:05:01,590
Ir jie nesunkiai jus tose demografija
ir jie sprendžia, ar ne

1487
01:05:01,590 --> 01:05:02,740
kad tai geras skelbimą Jums.

1488
01:05:02,740 --> 01:05:10,330
>> Dabar jie turi SLA su
jų reklamos teikėjai

1489
01:05:10,330 --> 01:05:14,510
teikti subrangos 10 milisekundės
atsakas į kiekvieną prašymą.

1490
01:05:14,510 --> 01:05:16,090
Taigi jie naudoja Dinamo DB už tai.

1491
01:05:16,090 --> 01:05:18,131
Jie pradeda mums
milijonas per sekundę.

1492
01:05:18,131 --> 01:05:21,120
Jie gali padaryti visi jų
paieška ", pagalbos pirmumo nustatymas visiems, kad duomenys,

1493
01:05:21,120 --> 01:05:26,130
ir gauti, kad pridėti nuorodą į tai
reklamuotojas, pagal 10 milisekundžių.

1494
01:05:26,130 --> 01:05:29,800
Tai tikrai gana fenomenalus
įgyvendinimas, kad jie turi.

1495
01:05:29,800 --> 01:05:36,210
>> Šie vaikinai actually--
Ar šie vaikinai.

1496
01:05:36,210 --> 01:05:38,010
Aš nesu įsitikinęs, jei tai šie vaikinai.

1497
01:05:38,010 --> 01:05:40,127
Gali būti šie vaikinai.

1498
01:05:40,127 --> 01:05:42,210
Iš esmės pasakė us-- ne, aš
nemanau, kad tai buvo jų.

1499
01:05:42,210 --> 01:05:43,000
Manau, tai buvo kažkas.

1500
01:05:43,000 --> 01:05:44,750
Dirbau su
klientų, kurie man pasakė,

1501
01:05:44,750 --> 01:05:47,040
kad dabar jie jau
nuėjo į "Dinamo" DB, jie

1502
01:05:47,040 --> 01:05:50,330
išleidžia daugiau pinigų užkandžiai
jų kūrimo komanda kiekvieną mėnesį

1503
01:05:50,330 --> 01:05:52,886
nei jie išleidžia savo duomenų bazę.

1504
01:05:52,886 --> 01:05:54,760
Taigi duosiu jums
Idėja iš sutaupytų

1505
01:05:54,760 --> 01:05:57,889
kad jūs galite gauti Dinamo DB yra didžiulis.

1506
01:05:57,889 --> 01:05:59,430
Gerai, dropcam kita bendrovė.

1507
01:05:59,430 --> 01:06:02,138
Tai vaikinas natūra of--, jei jūs manote
interneto dalykų, dropcam

1508
01:06:02,138 --> 01:06:05,150
iš esmės yra Internet Security vaizdo.

1509
01:06:05,150 --> 01:06:06,660
Jūs įdėti savo fotoaparatą ten.

1510
01:06:06,660 --> 01:06:08,180
Kamera turi judesio detektorius.

1511
01:06:08,180 --> 01:06:10,290
Kažkas ateina kartu,
sukelia duotąja tašką.

1512
01:06:10,290 --> 01:06:13,540
Kamera pradeda įrašinėti, o iki
jis neturi aptikti bet kokį judesį nebėra.

1513
01:06:13,540 --> 01:06:15,310
Pateikia kad vaizdo į internetą.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam buvo įmonė, kuri yra
iš esmės perėjo į "Dinamo DB

1515
01:06:19,800 --> 01:06:22,200
nes jie buvo patirti
milžiniški augimo skausmus.

1516
01:06:22,200 --> 01:06:25,820
Ir ką jie mums pasakė,
staiga petabytes duomenų.

1517
01:06:25,820 --> 01:06:28,070
Jie neturėjo jokio supratimo, savo paslaugas
būtų toks sėkmingas.

1518
01:06:28,070 --> 01:06:32,310
Daugiau atvykstamasis vaizdo nei "YouTube"
yra tai, ką šie vaikinai gauti.

1519
01:06:32,310 --> 01:06:36,780
Jie naudoja DynamoDB sekti visus
metaduomenis apie visus savo vaizdo pagrindinių punktų.

1520
01:06:36,780 --> 01:06:40,282
>> Taigi jie turi S3 kibirai jie stumti
visi dvejetainiai artefaktai į.

1521
01:06:40,282 --> 01:06:41,990
Ir tada jie turi
Dinamo DB įrašus,

1522
01:06:41,990 --> 01:06:44,070
žmonių atkreipti dėmesį į tuos S3 tris objektus.

1523
01:06:44,070 --> 01:06:47,070
Kai jiems reikia pažvelgti vaizdo,
jie atrodo iki Dinamo DB rekordą.

1524
01:06:47,070 --> 01:06:47,903
Jie spustelėkite nuorodą.

1525
01:06:47,903 --> 01:06:49,770
Jie išgriauti video iš S3.

1526
01:06:49,770 --> 01:06:51,590
Taigi, kad tipo kas tai atrodo.

1527
01:06:51,590 --> 01:06:53,580
Ir tai yra tiesiai iš savo komanda.

1528
01:06:53,580 --> 01:06:56,010
>> Dinamo DB sumažina jų
pristatymo laikas vaizdo renginių

1529
01:06:56,010 --> 01:06:57,590
nuo penkių iki 10 sekundžių.

1530
01:06:57,590 --> 01:07:00,470
Savo senosios reliacinės parduotuvėje,
jie naudojami turite eiti ir vykdyti

1531
01:07:00,470 --> 01:07:03,780
daug sudėtingas užklausas išsiaiškinti
iš kurios video traukti žemyn,

1532
01:07:03,780 --> 01:07:06,690
iki mažiau nei 50 milisekundžių.

1533
01:07:06,690 --> 01:07:08,990
Taigi, tai nuostabi, nuostabi
kiek veiklos

1534
01:07:08,990 --> 01:07:12,990
Jūs galite gauti, kai jūs optimizuoti ir
klausantis pagrindinės duomenų

1535
01:07:12,990 --> 01:07:15,110
remti prieigos modelis.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, šie vaikinai, kas tai yra,
Vaisiai Ninja spėju yra jų dalykas.

1537
01:07:20,500 --> 01:07:22,590
Kad visi veikia Dinamo dB.

1538
01:07:22,590 --> 01:07:26,810
Ir šie vaikinai, jie yra puikus
plėtros komanda, puikus plėtra

1539
01:07:26,810 --> 01:07:27,670
parduotuvė.

1540
01:07:27,670 --> 01:07:29,364
>> Nėra geras ops komanda.

1541
01:07:29,364 --> 01:07:31,280
Jie neturėjo daug
Veiklos išteklius.

1542
01:07:31,280 --> 01:07:33,940
Jie buvo sunkiai bando išlaikyti
jų taikymas infrastruktūra iki

1543
01:07:33,940 --> 01:07:34,290
ir veikia.

1544
01:07:34,290 --> 01:07:35,000
Jie atėjo pas mus.

1545
01:07:35,000 --> 01:07:36,251
Jie atrodė tuo Dinamo dB.

1546
01:07:36,251 --> 01:07:37,291
Jie sakė, kad tai už mus.

1547
01:07:37,291 --> 01:07:39,470
Jie pastatė visą jų
taikymo pagrindas ant jo.

1548
01:07:39,470 --> 01:07:43,640
Tikrai gražus komentarų čia
iš jų gebėjimo komanda

1549
01:07:43,640 --> 01:07:46,800
dabar sutelkti dėmesį į pastato
žaidimas, o ne

1550
01:07:46,800 --> 01:07:49,010
turintys išlaikyti
infrastruktūros, kuri

1551
01:07:49,010 --> 01:07:51,910
buvo tapti milžiniška suma
važtaraščius jų komanda.

1552
01:07:51,910 --> 01:07:56,170
Taigi tai yra kažkas that--
naudos, kad jūs gaunate iš "Dinamo" DB.

1553
01:07:56,170 --> 01:08:00,930
>> Gerai, patekti į
duomenų modeliavimo čia.

1554
01:08:00,930 --> 01:08:03,440
Ir mes kalbėjomės apie mažai
tai vienas prie vieno, vienas daug,

1555
01:08:03,440 --> 01:08:05,060
ir daug daug tipo santykius.

1556
01:08:05,060 --> 01:08:07,630
Ir kaip jums išlaikyti tuos Dynamo.

1557
01:08:07,630 --> 01:08:10,500
Dinamo DB mes naudojame
indeksai, apskritai kalbant,

1558
01:08:10,500 --> 01:08:12,910
pasukti duomenis iš
vienas skonio į kitą.

1559
01:08:12,910 --> 01:08:15,210
Hash raktai, klasės klavišai ir indeksai.

1560
01:08:15,210 --> 01:08:18,540
>> Šiuo konkrečiu
Pavyzdžiui, daugelyje valstybių

1561
01:08:18,540 --> 01:08:23,802
turėti licencijavimo reikalavimas, kad
Tik vienas vairuotojo pažymėjimas vienam asmeniui.

1562
01:08:23,802 --> 01:08:26,510
Jūs negalite eiti, kad gauti du vairuotojo
licencijas Bostono narėje.

1563
01:08:26,510 --> 01:08:27,500
Aš negaliu padaryti Teksase.

1564
01:08:27,500 --> 01:08:28,708
Tai tipo kaip ji yra.

1565
01:08:28,708 --> 01:08:32,779
Ir būdamas DMV, turime paieška ", mes
norite ieškoti vairuotojo pažymėjimą

1566
01:08:32,779 --> 01:08:35,180
pagal socialinio draudimo numerį.

1567
01:08:35,180 --> 01:08:39,990
Noriu ieškoti naudotojo duomenis
Iki vairuotojo licencijos numeris.

1568
01:08:39,990 --> 01:08:43,620
>> Taigi, mes galime turėti vartotojo anketa lentelę,
turi maišos klavišą serijos numerį,

1569
01:08:43,620 --> 01:08:47,830
arba socialinio draudimo numeris, ir
įvairūs atributai apibrėžta ant elemento.

1570
01:08:47,830 --> 01:08:49,859
Dabar tos lentelės I
gali apibrėžti GSI, kad

1571
01:08:49,859 --> 01:08:53,370
salto, kad aplink, kad sako noriu
maišos klavišą ant licencijos ir tada

1572
01:08:53,370 --> 01:08:54,252
visi kiti daiktai.

1573
01:08:54,252 --> 01:08:57,210
Dabar, jei aš noriu užklausą ir rasti
licencijos numeris bet kokiam teikti socialinę

1574
01:08:57,210 --> 01:08:59,609
Draudimo numeris, galiu
užklausti pagrindinę lentelę.

1575
01:08:59,609 --> 01:09:02,130
>> Jei aš noriu užklausti, ir aš noriu
gauti socialinę apsaugą

1576
01:09:02,130 --> 01:09:05,735
numeris arba kitus atributus pagal
licencijos numeris, galiu užklausti GSI.

1577
01:09:05,735 --> 01:09:08,689
Tai modelis, kad vienas
į vieną santykius.

1578
01:09:08,689 --> 01:09:12,460
Tiesiog labai paprastas GSI,
apversti tuos dalykus aplink.

1579
01:09:12,460 --> 01:09:13,979
Dabar kalbame apie vieną, kad daugelis.

1580
01:09:13,979 --> 01:09:16,450
Vienas su daugeliu iš esmės yra
Jūsų maišos asortimentas raktas.

1581
01:09:16,450 --> 01:09:20,510
Kur mes gauti daug su šia
naudojimo atveju yra stebėti duomenis.

1582
01:09:20,510 --> 01:09:23,880
Monitorius duomenys ateina reguliariai
intervalas, pavyzdžiui, daiktų interneto.

1583
01:09:23,880 --> 01:09:26,890
Mes visada gausite visa tai
įrašų ateina visą laiką.

1584
01:09:26,890 --> 01:09:31,420
>> Ir aš noriu surasti visus rodmenis
tarp tam tikrą laikotarpį.

1585
01:09:31,420 --> 01:09:34,220
Tai labai dažna užklausą
stebėsenos infrastruktūrą.

1586
01:09:34,220 --> 01:09:38,430
Būdas eiti apie tai rasti
paprasta lentelės struktūrą, vienas stalas.

1587
01:09:38,430 --> 01:09:42,250
Aš turiu prietaiso matavimų lentelę
su grotelėmis raktu ant prietaiso ID.

1588
01:09:42,250 --> 01:09:47,340
Ir aš turiu range klavišą
timestamp, ar šiuo atveju, epas.

1589
01:09:47,340 --> 01:09:50,350
Ir tai leidžia man atlikti kompleksą
užklausas, kad svyruoja raktą

1590
01:09:50,350 --> 01:09:54,950
ir grąžinti tuos įrašus, kad
yra santykinės rezultato

1591
01:09:54,950 --> 01:09:56,310
nustatyti, kad aš ieškojau.

1592
01:09:56,310 --> 01:09:58,360
Ir tai stato, kad vienas
į daugelį santykių

1593
01:09:58,360 --> 01:10:02,340
į pirminę lentelės naudojant tiesiogiai
maišos raktas, raktas asortimentas struktūra.

1594
01:10:02,340 --> 01:10:04,600
>> Taigi, kad tipo pastatytas
į "Dinamo" DB lentelėje.

1595
01:10:04,600 --> 01:10:07,290
Kai aš apibrėžti maišos
ir asortimentas T stalo, aš

1596
01:10:07,290 --> 01:10:09,240
apibrėžti vieną daugeliui santykius.

1597
01:10:09,240 --> 01:10:12,770
Tai tėvų ir vaikų santykiai.

1598
01:10:12,770 --> 01:10:14,620
>> Pakalbėkime apie daug
daug santykius.

1599
01:10:14,620 --> 01:10:19,170
Ir šiuo konkrečiu pavyzdžiui,
vėl, mes ketiname naudoti GSI-aisiais.

1600
01:10:19,170 --> 01:10:23,500
Ir pakalbėkime apie žaidimų
scenarijus, kai turiu tam tikrą vartotoją.

1601
01:10:23,500 --> 01:10:26,500
Noriu išsiaiškinti visus žaidimus,
jis registruotas, arba žaisti.

1602
01:10:26,500 --> 01:10:29,600
Ir už tam tikrą žaidimą, aš
nori surasti visus vartotojus.

1603
01:10:29,600 --> 01:10:31,010
Taigi, kaip man tai padaryti?

1604
01:10:31,010 --> 01:10:34,330
Mano vartotojo žaidimai stalo, aš ruošiuosi
turėti maišos raktą vartotojo ID

1605
01:10:34,330 --> 01:10:35,810
ir asortimentas raktas į žaidimą.

1606
01:10:35,810 --> 01:10:37,810
>> Taigi vartotojas gali turėti kelis žaidimus.

1607
01:10:37,810 --> 01:10:41,380
Tai vienas į daugelį santykių
vartotojas ir žaidimai groja.

1608
01:10:41,380 --> 01:10:43,410
Ir tada ant GSI,
Aš apversti, kad aplink.

1609
01:10:43,410 --> 01:10:46,679
Aš maišos ant žaidimo ir
Aš svyruoja nuo vartotojo.

1610
01:10:46,679 --> 01:10:48,970
Taigi, jei aš noriu gauti visi
žaidimas vartotojo anketa žaisti,

1611
01:10:48,970 --> 01:10:49,950
Aš užklausą pagrindinę lentelę.

1612
01:10:49,950 --> 01:10:52,699
Jei aš noriu gauti visus vartotojus
kurie vaidina ypatingą žaidimą,

1613
01:10:52,699 --> 01:10:53,887
Aš užklausą GSI.

1614
01:10:53,887 --> 01:10:54,970
Taigi, kaip matote, kaip mes tai darome?

1615
01:10:54,970 --> 01:10:58,369
Jūs pastatyti šie GSI s remti
naudojimo atveju, prašymas, prieigos

1616
01:10:58,369 --> 01:10:59,410
modelis, prašymas.

1617
01:10:59,410 --> 01:11:01,440
>> Jei man reikia užklausti apie
Šis matmuo, tegul

1618
01:11:01,440 --> 01:11:03,500
man sukurti apie tą aspektą indeksą.

1619
01:11:03,500 --> 01:11:05,850
Jei aš ne, man tai nerūpi.

1620
01:11:05,850 --> 01:11:09,060
Ir, priklausomai nuo panaudojimo atveju, aš
gali prireikti indeksą ar man gali nebūti.

1621
01:11:09,060 --> 01:11:12,390
Jei tai paprasta daug,
pirminė lentelė yra gerai.

1622
01:11:12,390 --> 01:11:15,860
Jei man reikia padaryti tai daugelis
daug s, arba man reikia padaryti vieną į tuos,

1623
01:11:15,860 --> 01:11:18,390
tada gal man tikrai reikia
antrosios indeksas.

1624
01:11:18,390 --> 01:11:20,840
Taigi viskas priklauso nuo
ką aš bandau padaryti

1625
01:11:20,840 --> 01:11:24,550
ir ką aš bandau gauti vykdymą.

1626
01:11:24,550 --> 01:11:28,000
>> Tikriausiai aš nesiruošia praleisti per
kiek laiko kalbėti apie dokumentus.

1627
01:11:28,000 --> 01:11:31,460
Tai pasireiškia šiek tiek, turbūt,
giliau nei mums reikia eiti į.

1628
01:11:31,460 --> 01:11:33,710
Pakalbėkime šiek tiek
apie turtingą užklausos išraiška.

1629
01:11:33,710 --> 01:11:37,831
Taigi Dinamo DB turime
gebėjimas sukurti

1630
01:11:37,831 --> 01:11:39,330
ką mes vadiname projektavimo išraiškas.

1631
01:11:39,330 --> 01:11:42,660
Projekciniai išraiškos yra tiesiog
skinti laukus ar vertybes

1632
01:11:42,660 --> 01:11:44,290
kad norite rodyti.

1633
01:11:44,290 --> 01:11:46,000
Gerai, kad aš padaryti pasirinkimą.

1634
01:11:46,000 --> 01:11:48,010
Aš padaryti prieš Dinamo DB užklausą.

1635
01:11:48,010 --> 01:11:51,730
Ir aš sakau, jūs žinote, ką, rodyti
man tik penkių žvaigždučių atsiliepimai

1636
01:11:51,730 --> 01:11:54,544
šiuo konkrečiu produktu.

1637
01:11:54,544 --> 01:11:55,710
Taigi, kad viskas, ką aš noriu pamatyti.

1638
01:11:55,710 --> 01:11:57,320
Aš nenoriu matyti visi
kiti atributai eilės,

1639
01:11:57,320 --> 01:11:58,319
Aš tik noriu pamatyti tai.

1640
01:11:58,319 --> 01:12:01,209
Tai kaip SQL, kai jūs
sako pasirinkite žvaigždę arba stalo,

1641
01:12:01,209 --> 01:12:02,000
gausite viską.

1642
01:12:02,000 --> 01:12:05,450
Kai aš sakau, pasirinkite vardą iš
stalo, aš tik gauti vieną atributą.

1643
01:12:05,450 --> 01:12:09,070
Tai tos pačios rūšies dalykas
Dinamo dB ar dar NoSQL duomenų bazės.

1644
01:12:09,070 --> 01:12:14,510
Filtruoti posakiai leisti man
iš esmės sumažinti rezultatą išlaipinti.

1645
01:12:14,510 --> 01:12:15,540
Taigi, aš padaryti užklausą.

1646
01:12:15,540 --> 01:12:17,260
Užklausa gali grįžti su 500 daiktų.

1647
01:12:17,260 --> 01:12:20,255
Bet aš tik noriu elementus,
turi atributą, kuris sako tai.

1648
01:12:20,255 --> 01:12:23,380
Gerai, kad galime filtruoti tuos elementus
kad nesutampa, kad ypač užklausą.

1649
01:12:23,380 --> 01:12:25,540
Taigi, mes turime filtro išraiškas.

1650
01:12:25,540 --> 01:12:28,310
>> Filtruoti išraiškos
būti paleisti bet atributas.

1651
01:12:28,310 --> 01:12:30,260
Jie nemėgsta nuotolio užklausas.

1652
01:12:30,260 --> 01:12:32,690
Pakelkite užklausos daugiau selektyvus.

1653
01:12:32,690 --> 01:12:36,470
Filtruoti užklausos reikalauja mane eiti
Gaukite visą rezultatai nustatyti ir tada

1654
01:12:36,470 --> 01:12:39,170
nesivadovauti duomenis nenoriu.

1655
01:12:39,170 --> 01:12:40,660
Kodėl tai svarbu?

1656
01:12:40,660 --> 01:12:42,770
Nes aš visa tai skaityti.

1657
01:12:42,770 --> 01:12:46,597
Į užklausą, aš ruošiuosi skaityti ir
tai bus milžiniškas apie duomenis.

1658
01:12:46,597 --> 01:12:48,430
Ir tada aš ruošiuosi
nesivadovauti, ko man reikia.

1659
01:12:48,430 --> 01:12:52,080
Ir jei aš tik išskirti
pora eilučių, tada, kad viskas OK.

1660
01:12:52,080 --> 01:12:53,620
Tai nėra taip neefektyvu.

1661
01:12:53,620 --> 01:12:57,800
>> Bet jei aš skaitau visa krūva
duomenys, tiesiog nesivadovauti vieną elementą,

1662
01:12:57,800 --> 01:13:01,490
tada aš ruošiuosi būti geriau
išjungti naudojant spektrą užklausą

1663
01:13:01,490 --> 01:13:03,030
nes tai daug daugiau selektyvus.

1664
01:13:03,030 --> 01:13:06,330
Jis ketina išsaugoti man daug
pinigų, nes aš mokėti už tą skaityti.

1665
01:13:06,330 --> 01:13:10,430
Jeigu rezultatai, kad grįžta
kirsti tą laidą gali būti mažesnis,

1666
01:13:10,430 --> 01:13:11,890
bet aš mokėti už skaityti.

1667
01:13:11,890 --> 01:13:14,340
Taigi suprasti, kaip
jūs gaunate duomenis.

1668
01:13:14,340 --> 01:13:16,420
Tai labai svarbu Dinamo dB.

1669
01:13:16,420 --> 01:13:19,710
>> Sąlyginis išraiška, tai yra tai, ką
galite skambinti optimistiškai užblokavimo.

1670
01:13:19,710 --> 01:13:28,470
Atnaujinti JEI egzistuoja, arba jei šios vertės
yra lygiavertė tai, ką galiu nurodyti.

1671
01:13:28,470 --> 01:13:31,494
Ir jei turiu laiko spaudą
įrašo, galiu skaityti duomenis.

1672
01:13:31,494 --> 01:13:32,535
Galėčiau pakeisti, kad duomenis.

1673
01:13:32,535 --> 01:13:35,030
Galėčiau eiti parašyti, kad
duomenis į duomenų bazę.

1674
01:13:35,030 --> 01:13:38,100
Jei kas nors pasikeitė įrašą,
laiko žyma gali būti pasikeitę.

1675
01:13:38,100 --> 01:13:40,370
Ir kad taip mano sąlyga
atnaujinimas, galima sakyti atnaujinimas

1676
01:13:40,370 --> 01:13:42,340
jei timestamp lygi tai.

1677
01:13:42,340 --> 01:13:46,290
Arba atnaujinimas žlugs, nes kažkam
atnaujino Tuo tarpu rekordą.

1678
01:13:46,290 --> 01:13:48,290
>> Štai ką mes vadiname optimistiškai užblokavimo.

1679
01:13:48,290 --> 01:13:50,670
Tai reiškia, kad kažkas
gali ateiti ir jį pakeisti,

1680
01:13:50,670 --> 01:13:53,100
ir aš ruošiuosi aptikti jį
kai aš grįžti rašyti.

1681
01:13:53,100 --> 01:13:56,106
Ir tada aš iš tikrųjų gali skaityti, kad
duomenys ir sako, oi, jis pakeitė tai.

1682
01:13:56,106 --> 01:13:57,230
Man reikia atsiskaityti už tai.

1683
01:13:57,230 --> 01:14:00,490
Ir aš galiu pakeisti duomenis Mano
įrašyti ir taikyti kitą naujinimą.

1684
01:14:00,490 --> 01:14:04,330
Taigi jūs galite sugauti tuos pažangus
atnaujinimai, kurie atsiranda nuo to momento,

1685
01:14:04,330 --> 01:14:08,740
kad jūs skaityti duomenis ir
laikas jums gali rašyti duomenis.

1686
01:14:08,740 --> 01:14:11,520
>> Auditorija: Ir filtras
išraiška iš tikrųjų reiškia ne

1687
01:14:11,520 --> 01:14:13,020
numerį arba not--

1688
01:14:13,020 --> 01:14:14,316
>> [Tarpines BALSAS]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: aš ne
gauti per daug į tai.

1690
01:14:16,232 --> 01:14:17,700
Tai saugomos raktinį žodį.

1691
01:14:17,700 --> 01:14:20,130
Svaras vaizdas yra saugomos
raktinį žodį "Dinamo" DB.

1692
01:14:20,130 --> 01:14:24,500
Kiekvienas duomenų turi savo saugomos
pavadinimai kolekcijų jūs negalite naudoti.

1693
01:14:24,500 --> 01:14:27,240
Dinamo DB, jei nurodysite
yra vienas priešais šį svaras,

1694
01:14:27,240 --> 01:14:29,310
galite nustatyti tuos pavadinimus iki viršaus.

1695
01:14:29,310 --> 01:14:31,840
Tai yra nurodoma vertė.

1696
01:14:31,840 --> 01:14:34,880
Tai tikriausiai ne geriausias sintaksė
turėti iki ten šią diskusiją,

1697
01:14:34,880 --> 01:14:38,090
nes jis gauna į kai real--
Norėčiau buvo kalbama daugiau

1698
01:14:38,090 --> 01:14:41,360
apie tai ne gilesniame lygmenyje.

1699
01:14:41,360 --> 01:14:46,130
>> Tačiau pakanka pasakyti, tai gali
būti užklausa nuskaityti kur jie views--

1700
01:14:46,130 --> 01:14:50,190
nei svaras peržiūros yra didesnis nei 10.

1701
01:14:50,190 --> 01:14:54,660
Tai yra skaitmeninė vertė, taip.

1702
01:14:54,660 --> 01:14:57,322
Jei norite, mes galime kalbėti apie
kad po diskusijų.

1703
01:14:57,322 --> 01:15:00,030
Visos teisės, todėl mes vis į
Kai kurie geriausios praktikos scenarijai

1704
01:15:00,030 --> 01:15:02,000
kur mes ketiname kalbėti
apie kai kurias programas čia.

1705
01:15:02,000 --> 01:15:03,810
Kokie naudojimo atvejai Dynamo dB.

1706
01:15:03,810 --> 01:15:06,120
Kas yra dizainas
modeliai Dinamo dB.

1707
01:15:06,120 --> 01:15:09,110
>> Ir pirmasis mes ketiname
kalbėti apie tai, ko internete.

1708
01:15:09,110 --> 01:15:15,010
Taigi mes gauname daug of-- Spėju,
kas it-- daugiau nei 50%

1709
01:15:15,010 --> 01:15:19,370
eismo internete šių dienų
iš tikrųjų sukuriama mašinos,

1710
01:15:19,370 --> 01:15:21,930
automatiniai procesai, o ne žmonėms.

1711
01:15:21,930 --> 01:15:25,140
Aš turiu galvoje tai, ką šis dalykas, kad
Jums nešiotis kišenėje,

1712
01:15:25,140 --> 01:15:28,840
kiek duomenų, kad šis dalykas yra
iš tikrųjų siunčiant aplink be tavęs

1713
01:15:28,840 --> 01:15:30,550
žinant tai yra absoliučiai nuostabios.

1714
01:15:30,550 --> 01:15:34,970
Jūsų vieta, informacija
apie tai, kaip greitai jūs einate.

1715
01:15:34,970 --> 01:15:38,400
Kaip manote, Google Maps darbus
kai jie pasakys, ką eismas yra.

1716
01:15:38,400 --> 01:15:41,275
Tai todėl, kad yra milijonai ir
milijonai žmonių važinėjantis

1717
01:15:41,275 --> 01:15:44,667
su telefonais kurie yra siunčiančiosios
duomenys visame vietoje visą laiką.

1718
01:15:44,667 --> 01:15:46,500
Taigi, viena iš ko
apie šį duomenų tipą

1719
01:15:46,500 --> 01:15:50,980
kuris ateina, stebėti duomenų, prisijunkite
duomenys, laiko eilučių duomenų, tai yra

1720
01:15:50,980 --> 01:15:53,540
paprastai tik įdomu
už šiek tiek laiko.

1721
01:15:53,540 --> 01:15:55,580
Po to laiko, tai
ne taip įdomu.

1722
01:15:55,580 --> 01:15:58,390
Taigi, mes kalbėjome apie, neleiskite
tas lenteles augti be ribų.

1723
01:15:58,390 --> 01:16:03,410
Idėja yra tai, kad gal aš turiu 24
valandos verta įvykių mano karšto lentelėje.

1724
01:16:03,410 --> 01:16:06,160
Ir tai karšta lentelė bus
numatęs labai dideliu greičiu,

1725
01:16:06,160 --> 01:16:07,950
nes jis, atsižvelgiant daug duomenų.

1726
01:16:07,950 --> 01:16:10,920
Tai atsižvelgiant daug duomenų
ir aš jį skaityti daug.

1727
01:16:10,920 --> 01:16:14,560
Aš turiu eksploatavimo daug
užklausos veikia nuo šių duomenų.

1728
01:16:14,560 --> 01:16:18,120
>> Po 24 valandų, ei, jūs
žinoti, kas, man tai nerūpi.

1729
01:16:18,120 --> 01:16:21,150
Taigi gal kas vidurnakčio Aš ritinys
mano stalo perkelti į naują lentelę

1730
01:16:21,150 --> 01:16:22,430
ir aš deprovision šią lentelę.

1731
01:16:22,430 --> 01:16:26,440
Ir Imsiu RCU "ir
WCU anketa žemyn, nes po 24 valandų

1732
01:16:26,440 --> 01:16:28,630
Nesu veikia kaip daugelis
užklausas šių duomenų.

1733
01:16:28,630 --> 01:16:30,200
Taigi, aš ruošiuosi sutaupyti pinigų.

1734
01:16:30,200 --> 01:16:32,940
O gal 30 dienų, aš ne
net nereikia rūpintis visa tai.

1735
01:16:32,940 --> 01:16:35,020
Galėčiau imtis WCU s
visą kelią žemyn į vieną,

1736
01:16:35,020 --> 01:16:36,990
nes jūs žinote, ką tai
niekada gauti parašyta.

1737
01:16:36,990 --> 01:16:38,300
Duomenys yra 30 dienų.

1738
01:16:38,300 --> 01:16:40,000
Jis niekada nesikeičia.

1739
01:16:40,000 --> 01:16:44,200
>> Ir tai beveik niekada ketinate gauti skaityti,
tad tiesiog imtis, kad NVP iki 10.

1740
01:16:44,200 --> 01:16:49,372
Ir aš sutaupyti pinigų ton apie tai
duomenys, ir tik mokėti už mano karšto duomenis.

1741
01:16:49,372 --> 01:16:52,330
Taigi, kad svarbiausia ieškoti
ne, kai jūs pažvelgti laiko eilučių

1742
01:16:52,330 --> 01:16:54,716
duomenys ateina apimtis.

1743
01:16:54,716 --> 01:16:55,590
Tai yra strategijos.

1744
01:16:55,590 --> 01:16:58,010
Dabar, galėčiau tiesiog leiskite ją
visi eiti į tą pačią lentelę

1745
01:16:58,010 --> 01:16:59,461
ir leiskite, kad stalo augti.

1746
01:16:59,461 --> 01:17:01,460
Galų gale, aš ruošiuosi
matyti našumo problemas.

1747
01:17:01,460 --> 01:17:04,060
Aš ruošiuosi pradėti archyvas
kai kurie iš minėtų duomenų išjungimo stalo,

1748
01:17:04,060 --> 01:17:04,720
kas ne.

1749
01:17:04,720 --> 01:17:07,010
>> Leiskite daug geriau
dizainas jūsų prašymą

1750
01:17:07,010 --> 01:17:08,900
taip, kad jūs galite valdyti šį kelią dešinėje.

1751
01:17:08,900 --> 01:17:11,460
Taigi tai tik automatinė
paraiškos kodą.

1752
01:17:11,460 --> 01:17:13,580
Vidurnaktį kiekvieną naktį
jis ritininis stalą.

1753
01:17:13,580 --> 01:17:17,170
Gal ko man reikia yra stumdomas
langas 24 valandas nuo duomenų.

1754
01:17:17,170 --> 01:17:20,277
Tada reguliariai Aš
paskambinę duomenis nuo stalo.

1755
01:17:20,277 --> 01:17:22,360
Aš apkarpymas su
Cron ir aš pradėti jį

1756
01:17:22,360 --> 01:17:24,160
ant šių kitų lentelių,
ką reikia.

1757
01:17:24,160 --> 01:17:25,940
Taigi, jei virtimo veikia, tai puiku.

1758
01:17:25,940 --> 01:17:27,080
Jei ne, apdaila ją.

1759
01:17:27,080 --> 01:17:29,640
Bet tegul laikyti, kad karšto duomenis
nuo savo šalto duomenis.

1760
01:17:29,640 --> 01:17:32,535
Tai bus jums sutaupyti daug pinigų ir
Padarykite savo lenteles daugiau našumą.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Taigi kitas dalykas mes kalbame
apie tai, produktų katalogas.

1763
01:17:38,210 --> 01:17:42,000
Prekių katalogas yra
gana bendro naudojimo atveju.

1764
01:17:42,000 --> 01:17:46,600
Tai iš tikrųjų labai dažnas modelis
kad mes matome įvairių dalykų.

1765
01:17:46,600 --> 01:17:48,870
Žinote, Twitter
Pavyzdžiui, karšto Čivināšana.

1766
01:17:48,870 --> 01:17:51,280
Kiekvienas ateina ir
greiferiniai kad Čivināšana.

1767
01:17:51,280 --> 01:17:52,680
Prekių katalogas, aš turiu parduoti.

1768
01:17:52,680 --> 01:17:54,120
Gavau karštą pardavimą.

1769
01:17:54,120 --> 01:17:57,277
Gavau 70.000 prašymus per
Antrasis ateina produkto

1770
01:17:57,277 --> 01:17:58,860
Aprašymas iš mano produktų katalogą.

1771
01:17:58,860 --> 01:18:02,384
Mes tai matome mažmeninės
operacija gana šiek tiek.

1772
01:18:02,384 --> 01:18:03,550
Taigi, kaip mes susidoroti su tuo?

1773
01:18:03,550 --> 01:18:04,924
Nėra būdas kovoti su tuo.

1774
01:18:04,924 --> 01:18:07,110
Visi mano vartotojai nori pamatyti
tas pats gabalas duomenimis.

1775
01:18:07,110 --> 01:18:09,410
Jie ateina iš, kartu.

1776
01:18:09,410 --> 01:18:11,920
Ir jie visi padaryti prašymus
už tą patį gabalas duomenimis.

1777
01:18:11,920 --> 01:18:16,240
Tai suteikia man, kad karšto klavišą, kad didelis raudonas
juostele ant mano diagramą, kad mums nepatinka.

1778
01:18:16,240 --> 01:18:17,720
Ir tai, kas, kad atrodo.

1779
01:18:17,720 --> 01:18:22,290
Taigi per mano pagrindinis erdvėje gaunu
įkalama į pardavimo daiktais.

1780
01:18:22,290 --> 01:18:24,070
Gaunu nieko niekur kitur.

1781
01:18:24,070 --> 01:18:26,050
>> Kaip man sumažinti šią problemą?

1782
01:18:26,050 --> 01:18:28,410
Na, mes sumažinti tai su talpyklą.

1783
01:18:28,410 --> 01:18:33,630
Cache, jūs įtraukėte esmės in-atminties
pertvarų priešais duomenų bazėje.

1784
01:18:33,630 --> 01:18:37,260
Mums pavyko
[Nesigirdi] talpyklą, kaip jūs

1785
01:18:37,260 --> 01:18:40,260
galite sukurti savo talpyklą, [nesigirdi]
talpyklos [? D,?] ką nori.

1786
01:18:40,260 --> 01:18:42,220
Įdėti, kad priešais duomenų bazėje.

1787
01:18:42,220 --> 01:18:47,250
Ir tokiu būdu jūs galite laikyti, kad duomenys
iš tų karštų klavišų iki toje talpyklos

1788
01:18:47,250 --> 01:18:49,390
erdvė ir skaityti per talpyklą.

1789
01:18:49,390 --> 01:18:51,962
>> Ir tada dauguma jūsų skaito
pradėti ieškoti, kaip šis.

1790
01:18:51,962 --> 01:18:54,920
Aš turiu visa tai talpyklos hitai čia
ir aš nieko vyksta žemyn čia

1791
01:18:54,920 --> 01:18:59,330
nes duomenų sėdi atsilieka nuo
talpyklos ir skaito niekada ateiti per.

1792
01:18:59,330 --> 01:19:02,520
Jei aš pakeisti duomenų
duomenų, turiu atnaujinti talpyklą.

1793
01:19:02,520 --> 01:19:04,360
Mes galime naudoti kažką
kaip Garų tai padaryti.

1794
01:19:04,360 --> 01:19:07,360
Ir aš paaiškinti, kaip tai veikia.

1795
01:19:07,360 --> 01:19:09,060
Gerai, pranešimų.

1796
01:19:09,060 --> 01:19:11,180
Paštas, mes visi naudotis elektroniniu paštu.

1797
01:19:11,180 --> 01:19:12,540
>> Tai gana geras pavyzdys.

1798
01:19:12,540 --> 01:19:14,950
Mes turime tam tikrą pranešimų stalo rūšiuoti.

1799
01:19:14,950 --> 01:19:17,040
Ir mes turime "Gautieji" ir katalogą Siunčiamieji.

1800
01:19:17,040 --> 01:19:19,760
Tai yra tai, ką SQL būtų
atrodyti statyti tą dėžutę.

1801
01:19:19,760 --> 01:19:23,350
Mes rūšies naudoti tos pačios rūšies
strategiją naudoti GSI-ųjų GSI s

1802
01:19:23,350 --> 01:19:25,320
mano pašto dėžutę ir mano Siunčiami.

1803
01:19:25,320 --> 01:19:27,600
Taigi gavau žaliavos pranešimai ateina
į mano messages stalo.

1804
01:19:27,600 --> 01:19:30,194
Ir pirmasis požiūris į tai
gali būti, tarkim, gerai, jokių problemų.

1805
01:19:30,194 --> 01:19:31,110
Aš turiu žaliavų pranešimus.

1806
01:19:31,110 --> 01:19:33,710
Pranešimus, gaunamus [nesigirdi]
žinutė ID, tai puiku.

1807
01:19:33,710 --> 01:19:35,070
Štai mano unikalus maišos.

1808
01:19:35,070 --> 01:19:38,280
Aš ruošiuosi sukurti du GSI s, vieną
mano pašto dėžutę, vienas mano Siunčiami.

1809
01:19:38,280 --> 01:19:40,530
Ir aš pirmas dalykas, tai padaryti
yra pasakysiu mano maišos raktas

1810
01:19:40,530 --> 01:19:43,310
bus gavėjas ir
Aš ruošiuosi organizuoti ant datos.

1811
01:19:43,310 --> 01:19:44,220
Tai fantastinis.

1812
01:19:44,220 --> 01:19:45,890
Aš gavau mano gražus vaizdas čia.

1813
01:19:45,890 --> 01:19:47,780
Bet yra šiek tiek klausimas čia.

1814
01:19:47,780 --> 01:19:50,891
Ir jūs paleisti į tai
reliacinių duomenų bazių, taip pat.

1815
01:19:50,891 --> 01:19:52,390
Jie paragino vertikaliai atitvarų.

1816
01:19:52,390 --> 01:19:55,840
Jūs norite, kad jūsų didelis duomenis
nuo jūsų mažai duomenų.

1817
01:19:55,840 --> 01:20:00,470
>> Ir priežastis, kodėl, nes aš turiu
eiti skaityti elementus gauti atributus.

1818
01:20:00,470 --> 01:20:05,570
Ir jei mano organai yra viskas čia
tada skaityti tik keli daiktai

1819
01:20:05,570 --> 01:20:08,560
jei mano kūnas ilgis yra
vidutiniškai 256 kilobaitų kas,

1820
01:20:08,560 --> 01:20:10,991
matematika gauna gana negraži.

1821
01:20:10,991 --> 01:20:12,490
Taigi pasakyti, kad aš noriu skaityti Dovydo dėžutę.

1822
01:20:12,490 --> 01:20:14,520
Dovydo Gautieji yra 50 elementai.

1823
01:20:14,520 --> 01:20:17,880
Vidutinis ir dydis yra 256 kilobaitų.

1824
01:20:17,880 --> 01:20:21,730
Štai mano konvertavimo santykis
už RCU s yra keturi kilobaitų.

1825
01:20:21,730 --> 01:20:24,450
>> Gerai, eikime su
galiausiai nuosekliai skaito.

1826
01:20:24,450 --> 01:20:28,640
Aš vis dar valgo 1600 RCU s
tik skaityti Dovydo dėžutę.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
Gerai, dabar pagalvokime
apie tai, kaip programa veikia.

1829
01:20:31,980 --> 01:20:35,340
Jei aš elektroninio pašto programą ir
Žiūriu mano pašto dėžutę,

1830
01:20:35,340 --> 01:20:39,680
ir aš pažvelgti į kiekvieną pranešimą, kūno,
Ne, aš žiūriu santraukos.

1831
01:20:39,680 --> 01:20:41,850
Žiūriu tik antraštėse.

1832
01:20:41,850 --> 01:20:46,310
Taigi leiskite sukurti lentelės struktūrą
kad atrodo labiau patinka.

1833
01:20:46,310 --> 01:20:49,470
>> Taigi čia informacija
kad mano darbo eigos poreikius.

1834
01:20:49,470 --> 01:20:50,890
Tai mano pašto dėžutę GSI.

1835
01:20:50,890 --> 01:20:53,800
Tai data, siuntėjas,
objektas, ir tada

1836
01:20:53,800 --> 01:20:56,790
pranešimas ID, kuris nurodo
Atgal į pranešimus stalo

1837
01:20:56,790 --> 01:20:57,850
kur galiu gauti kūną.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Na, tai būtų įrašyti idėjas.

1840
01:21:04,420 --> 01:21:09,850
Jie norėtų atkreipti atgal į
punktas ID dėl Dinamo DB lentelėje.

1841
01:21:09,850 --> 01:21:12,220
Kiekvienas puslapis visada creates--
visada turi elementą

1842
01:21:12,220 --> 01:21:15,750
ID numeris dalis of-- kad
ateina su indeksu.

1843
01:21:15,750 --> 01:21:17,414
>> Gerai.

1844
01:21:17,414 --> 01:21:19,080
Auditorija: Jis pasakoja, jeigu jis saugomas?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Taip, tai pasako
exactly-- tai, ką jis daro.

1846
01:21:21,420 --> 01:21:22,644
Ji sako čia mano naujo įrašo.

1847
01:21:22,644 --> 01:21:24,310
Ir jis bus nukreipti jį atgal į savo naujo įrašo.

1848
01:21:24,310 --> 01:21:26,460
Būtent.

1849
01:21:26,460 --> 01:21:29,490
Gerai, kad dabar mano pašto dėžutė
iš tikrųjų daug mažesnis.

1850
01:21:29,490 --> 01:21:32,210
Ir tai iš tikrųjų palaiko
elektroninio pašto app eiga.

1851
01:21:32,210 --> 01:21:34,230
Taigi mano pašto dėžutę, aš spustelėkite.

1852
01:21:34,230 --> 01:21:38,160
Aš einu kartu ir aš spustelėkite pranešimą,
tai kai man reikia eiti gauti kūną,

1853
01:21:38,160 --> 01:21:40,180
nes aš ruošiuosi
pereiti prie kitokios nuomonės.

1854
01:21:40,180 --> 01:21:43,870
Taigi, jei jūs manote apie MVC tipą
sistema, modelis vaizdas valdiklis.

1855
01:21:43,870 --> 01:21:46,120
>> Šis modelis būtų pateikiama
duomenų, kad peržiūrėti poreikiai

1856
01:21:46,120 --> 01:21:48,130
ir kontroleris bendrauja su.

1857
01:21:48,130 --> 01:21:51,670
Kai aš pakeisti rėmo kai
Pakeisti perspektyvą,

1858
01:21:51,670 --> 01:21:55,080
viskas OK, jei norite grįžti į
serveris ir repopulate modelį,

1859
01:21:55,080 --> 01:21:56,860
nes tai, ką vartotojas tikisi.

1860
01:21:56,860 --> 01:22:00,530
Kai jie pakeisti požiūrį, kad, kai
galime grįžti prie duomenų bazės.

1861
01:22:00,530 --> 01:22:02,480
Taigi siųsti, paspauskite.

1862
01:22:02,480 --> 01:22:03,710
Aš ieškau kūno.

1863
01:22:03,710 --> 01:22:04,330
Jei kūdikiui kelionės.

1864
01:22:04,330 --> 01:22:05,680
Grįžti gauti kūną.

1865
01:22:05,680 --> 01:22:06,950
>> Aš perskaičiau daug mažiau duomenų.

1866
01:22:06,950 --> 01:22:09,960
Aš tik skaityti įstaigas,
Davidas reikia, kai jis turi juos.

1867
01:22:09,960 --> 01:22:14,230
Ir aš nedegina 1600
RCU tiesiog parodyti savo dėžutę.

1868
01:22:14,230 --> 01:22:17,670
Taigi dabar that-- tai yra būdas
kad LSI arba GSI-- aš atsiprašau,

1869
01:22:17,670 --> 01:22:19,900
GSI, būtų dirbti.

1870
01:22:19,900 --> 01:22:25,450
Mes turime mūsų maišos gavėjui.

1871
01:22:25,450 --> 01:22:27,030
Mes turime spektrą klavišą dienos.

1872
01:22:27,030 --> 01:22:31,380
Ir mes turime numatomus atributus
kad mums reikia tik patvirtina nuomonę.

1873
01:22:31,380 --> 01:22:34,300
>> Mes pasukti, kad už Siunčiami.

1874
01:22:34,300 --> 01:22:35,770
Hash nuo siuntėjo.

1875
01:22:35,770 --> 01:22:39,612
Ir iš esmės, mes turime
labai gražus, švarus vaizdas.

1876
01:22:39,612 --> 01:22:41,570
Ir tai basically-- mes
turi šį gražus pranešimus

1877
01:22:41,570 --> 01:22:45,870
stalo, kad manimi skleidžiamas gražiai, nes
tai maišos tik sumaišomas žinutė ID.

1878
01:22:45,870 --> 01:22:51,750
Ir mes turime du indeksus, kad
sukasi ne iš tos lentelės.

1879
01:22:51,750 --> 01:22:57,411
Visos teisės, todėl idėja čia yra ne
išlaikyti didelius duomenis ir šį nedidelį duomenis

1880
01:22:57,411 --> 01:22:57,910
kartu.

1881
01:22:57,910 --> 01:23:00,700
Pasiskirstymo vertikaliai,
padalyti šias lenteles.

1882
01:23:00,700 --> 01:23:03,150
Negalima skaityti duomenis jūs neturite.

1883
01:23:03,150 --> 01:23:04,850
Gerai, žaidimų.

1884
01:23:04,850 --> 01:23:06,990
Mes visi norėtume žaidimai.

1885
01:23:06,990 --> 01:23:10,902
Bent jau aš norėčiau žaidimai tada.

1886
01:23:10,902 --> 01:23:12,735
Taigi keletas dalykų
kad mes dirbame su kai

1887
01:23:12,735 --> 01:23:14,193
mes galvoti apie žaidimų, tiesa?

1888
01:23:14,193 --> 01:23:16,999
Žaidimų šių dienų, ypač mobiliųjų
Žaidimų, yra visa informacija apie mąstymą.

1889
01:23:16,999 --> 01:23:19,540
Ir aš ruošiuosi sukti Čia
Šiek tiek atokiau nuo DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Aš ruošiuosi atnešti
kai diskusijos

1891
01:23:21,373 --> 01:23:24,240
aplink vieni iš
kiti AWS technologijos.

1892
01:23:24,240 --> 01:23:28,930
>> Bet apie žaidimų idėja yra galvoti
apie pagal API API, kurie,

1893
01:23:28,930 --> 01:23:31,730
apskritai kalbant, HTTP ir JSON.

1894
01:23:31,730 --> 01:23:34,550
Tai kaip mobiliųjų žaidimų natūra
bendrauti su savo užpakalinių galų.

1895
01:23:34,550 --> 01:23:35,850
Jie JSON komandiravimo.

1896
01:23:35,850 --> 01:23:40,660
Jie gauna duomenis, ir viskas,
Apskritai kalbant, gražus JSON API.

1897
01:23:40,660 --> 01:23:44,950
>> Dalykų, pavyzdžiui, gauti draugų, gauti
Iškabos, keistis duomenimis,

1898
01:23:44,950 --> 01:23:47,699
vartotojų kuriamo turinio,
stumti atgal iki sistemos,

1899
01:23:47,699 --> 01:23:49,740
tai tipų dalykų
kad mes ketiname daryti.

1900
01:23:49,740 --> 01:23:52,542
Dvejetainiai turto duomenys, šie duomenys
gali ne sėdėti duomenų bazę.

1901
01:23:52,542 --> 01:23:54,250
Tai gali sėdėti
objektas parduotuvė, tiesa?

1902
01:23:54,250 --> 01:23:56,541
Bet duomenų bazė ketina
galų gale pasako sistemai,

1903
01:23:56,541 --> 01:23:59,140
sakau paraišką
kur eiti jį gauti.

1904
01:23:59,140 --> 01:24:03,550
Ir neišvengiamai Multiplayer
serveriai, atgal pabaigoje infrastruktūra,

1905
01:24:03,550 --> 01:24:06,180
ir skirtas aukštos
prieinamumas ir mastelio.

1906
01:24:06,180 --> 01:24:09,400
Taigi tai yra tai, kas mes visi norime
į žaidimų infrastruktūros šiandien.

1907
01:24:09,400 --> 01:24:12,160
>> Taigi leiskite pažvelgti
ką tai atrodo.

1908
01:24:12,160 --> 01:24:16,070
Turite pagrindinę atgal pabaigoje,
labai paprasta.

1909
01:24:16,070 --> 01:24:19,880
Mes turime sistemą, čia su
kelis prieinamumas zonose.

1910
01:24:19,880 --> 01:24:23,780
Mes kalbėjome apie AZS kaip being-- manote
iš jų, kaip atskirų duomenų centruose.

1911
01:24:23,780 --> 01:24:26,040
Daugiau nei vienas duomenų centras
už AZ, bet tai gerai,

1912
01:24:26,040 --> 01:24:28,831
tiesiog galvoti apie juos kaip atskirą duomenų
centrai, kurie yra geografiškai

1913
01:24:28,831 --> 01:24:30,090
ir gedimų izoliuota.

1914
01:24:30,090 --> 01:24:32,172
>> Mes ketiname turėti
pora EC2 atvejų.

1915
01:24:32,172 --> 01:24:33,880
Mes ketiname turėti
kai atgal end serveris.

1916
01:24:33,880 --> 01:24:35,800
Galbūt, jei esate palikimas
architektūra, mes

1917
01:24:35,800 --> 01:24:38,920
naudojant, ką mes vadiname RDS,
reliacinės duomenų bazės paslaugos.

1918
01:24:38,920 --> 01:24:42,040
Galėtų būti MSSQL, MySQL,
ar kažkas panašaus.

1919
01:24:42,040 --> 01:24:47,080
Tai būdas daug paraiškų
yra skirtos šiandien.

1920
01:24:47,080 --> 01:24:49,594
>> Na mes galbūt norėsite eiti su
tai kai mes mastelį iš.

1921
01:24:49,594 --> 01:24:51,510
Mes eiti į priekį ir padėkite
S3 kibiras ten.

1922
01:24:51,510 --> 01:24:54,200
Ir tai S3 kibiras, o ne tarnauja
iki šių objektų iš mūsų servers--

1923
01:24:54,200 --> 01:24:55,220
mes galime padaryti, kad.

1924
01:24:55,220 --> 01:24:57,210
Jūs įdėti visą savo dvejetainis
objektus į savo serverius

1925
01:24:57,210 --> 01:24:59,751
ir jūs galite naudoti šiuos serverį
atvejų tarnauti, kad duomenų aukštyn.

1926
01:24:59,751 --> 01:25:01,860
Bet tai gana brangu.

1927
01:25:01,860 --> 01:25:05,107
>> Geriau būdas tai padaryti yra eiti į priekį ir
įdėti tuos objektus į S3 kibirą.

1928
01:25:05,107 --> 01:25:06,315
S3 objektas saugyklos.

1929
01:25:06,315 --> 01:25:10,860
Jis pastatytas specialiai
tarnauja iki šių dalykų tipus.

1930
01:25:10,860 --> 01:25:13,690
Ir tegul tie klientai prašyti
tiesiogiai iš šių objektų kibirai,

1931
01:25:13,690 --> 01:25:15,390
iškrauti serverius.

1932
01:25:15,390 --> 01:25:17,020
Taigi mes pradedame mastelį čia.

1933
01:25:17,020 --> 01:25:19,140
>> Dabar mes turime vartotojams visame pasaulyje.

1934
01:25:19,140 --> 01:25:19,730
Gavau vartotojams.

1935
01:25:19,730 --> 01:25:23,380
Man reikia turėti turinį vietoje
netoli šių vartotojų, tiesa?

1936
01:25:23,380 --> 01:25:26,200
Aš sukūriau S3 kibirą
kaip mano kodo saugyklą.

1937
01:25:26,200 --> 01:25:29,370
Ir aš priekyje, kad su
CloudFront platinimas.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront yra CD ir
turinio pristatymo tinklo.

1939
01:25:31,720 --> 01:25:35,750
Iš esmės ji mano duomenis, kad jums nurodyti
ir išsaugo ją visame internete

1940
01:25:35,750 --> 01:25:39,230
todėl vartotojai gali turėti visur
labai greitai reaguoti, kai

1941
01:25:39,230 --> 01:25:40,960
jie prašo tuos objektus.

1942
01:25:40,960 --> 01:25:41,960
>> Taigi jūs gaunate idėja.

1943
01:25:41,960 --> 01:25:48,230
Jūs esate rūšies sverto visi
aspektai AWS čia Norėdami gauti šią padaryta.

1944
01:25:48,230 --> 01:25:50,790
Ir, galų gale, mes išmetame
į auto skalių grupei.

1945
01:25:50,790 --> 01:25:52,737
Taigi mūsų AC2 atvejais
mūsų žaidimų serverių,

1946
01:25:52,737 --> 01:25:54,820
kaip jie pradeda gauti užsiėmęs
ir užsiėmęs ir užsiėmęs,

1947
01:25:54,820 --> 01:25:57,236
jie bus tiesiog nugara kitą
pavyzdžiui, nugara kitą atvejį,

1948
01:25:57,236 --> 01:25:58,210
nugara kitą atvejį.

1949
01:25:58,210 --> 01:26:02,090
Taigi technologiją AWS turi, tai
Leidžia nustatyti parametrus

1950
01:26:02,090 --> 01:26:04,650
aplink kurį jūsų serveriai bus augti.

1951
01:26:04,650 --> 01:26:08,110
Taigi jūs galite turėti n skaičių serveriuose
ten bet kuriuo metu.

1952
01:26:08,110 --> 01:26:11,870
Ir jei jūsų apkrovos nueina, jie
trauktis, skaičius mažės.

1953
01:26:11,870 --> 01:26:15,250
Ir jei apkrovos grįžta,
jis bus atauga iš, elastingai.

1954
01:26:15,250 --> 01:26:17,050
>> Taigi, tai atrodo puikiai.

1955
01:26:17,050 --> 01:26:19,800
Mes gavome EC2 atvejais daug.

1956
01:26:19,800 --> 01:26:21,671
Mes galime įdėti talpyklos
Priešais duomenų bazių,

1957
01:26:21,671 --> 01:26:23,045
pabandyti ir pagreitinti duomenų bazes.

1958
01:26:23,045 --> 01:26:25,030
Kitas spaudimo taškas
paprastai žmonės mato

1959
01:26:25,030 --> 01:26:28,850
yra jie masto žaidimą naudojant
reliacinės duomenų bazės sistema.

1960
01:26:28,850 --> 01:26:30,790
Pas duomenų bazė
veikimas yra baisi.

1961
01:26:30,790 --> 01:26:31,932
Kaip mes pagerinti, kad?

1962
01:26:31,932 --> 01:26:33,640
Pabandykime išleidimą
talpyklos priešais, kad.

1963
01:26:33,640 --> 01:26:36,780
>> Na, talpyklos neveikia
toks didelis žaidimų, tiesa?

1964
01:26:36,780 --> 01:26:39,330
Žaidimų, rašymas yra skausminga.

1965
01:26:39,330 --> 01:26:40,930
Žaidimai yra labai rašyti sunkus.

1966
01:26:40,930 --> 01:26:43,610
Laikinoji neveikia, kai esate
rašyti sunki, nes jūs visada

1967
01:26:43,610 --> 01:26:44,610
turiu atnaujinti talpyklą.

1968
01:26:44,610 --> 01:26:47,780
Jūs atnaujinti talpyklą, tai
nesvarbus būti spartinimo.

1969
01:26:47,780 --> 01:26:49,780
Tai iš tikrųjų tik papildomas darbas.

1970
01:26:49,780 --> 01:26:51,970
>> Taigi, kur mes einame čia?

1971
01:26:51,970 --> 01:26:54,400
Jūs turite didelį butelio
ten į duomenų bazę.

1972
01:26:54,400 --> 01:26:57,661
Ir kur eiti
akivaizdžiai yra atitvarų.

1973
01:26:57,661 --> 01:26:59,410
Pertvara yra ne
lengva padaryti, kai esate

1974
01:26:59,410 --> 01:27:01,900
susiduriame su reliacinių duomenų bazių.

1975
01:27:01,900 --> 01:27:05,080
Su reliacinių duomenų bazių, jūs
atsakinga už, efektyviai,

1976
01:27:05,080 --> 01:27:06,210
pagrindinis plotas.

1977
01:27:06,210 --> 01:27:10,527
Jūs sakote vartotojams tarp A ir M
eikite čia, tarp N ir Z ten.

1978
01:27:10,527 --> 01:27:12,360
Ir jūs perjungimo
visoje paraiškoje.

1979
01:27:12,360 --> 01:27:15,000
Taigi jūs susiduriame su
šiame skirsnyje duomenų šaltinis.

1980
01:27:15,000 --> 01:27:18,670
Turite sudaryti sandorį apribojimus
kad ne span skirsnius.

1981
01:27:18,670 --> 01:27:20,560
Jūs turite visų rūšių
Bałaganienie, kad esate

1982
01:27:20,560 --> 01:27:23,040
bendraujant su ten bando
susidoroti su mastelio dėmesį

1983
01:27:23,040 --> 01:27:25,120
ir kurti didesnę infrastruktūrą.

1984
01:27:25,120 --> 01:27:27,284
Tai tiesiog nėra įdomus.

1985
01:27:27,284 --> 01:27:30,930
>> Auditorija: Taigi tu sakai, kad
padidinti šaltinio taškų pagreitina

1986
01:27:30,930 --> 01:27:31,430
procesas?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Didinti?

1988
01:27:32,513 --> 01:27:33,520
Auditorija: Source taškai.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Source taškai?

1990
01:27:34,410 --> 01:27:37,500
Auditorija: Nuo informacijos
kur informacija yra iš?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: Ne

1992
01:27:38,250 --> 01:27:41,820
Ką aš sakau, didinant
skaičius pertvaromis į duomenų saugykloje

1993
01:27:41,820 --> 01:27:44,060
pagerina pralaidumą.

1994
01:27:44,060 --> 01:27:48,300
Taigi, kas vyksta čia yra vartotojai
ateina į EC2 pavyzdžiui čia,

1995
01:27:48,300 --> 01:27:50,780
Na, jei man reikia vartotoją
tai A iki M, aš eisiu čia.

1996
01:27:50,780 --> 01:27:53,560
Iš N P, aš eisiu čia.

1997
01:27:53,560 --> 01:27:55,060
Iš P Z, aš eisiu čia.

1998
01:27:55,060 --> 01:27:57,120
>> Auditorija: Gerai, tie taip tie, kurie
visi saugomi skirtingose ​​mazgų?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Taip.

2000
01:27:57,911 --> 01:28:00,210
Pagalvokite apie tai, kaip
skirtingų bunkeriai duomenų.

2001
01:28:00,210 --> 01:28:01,660
Taigi jūs, turintys tai padaryti.

2002
01:28:01,660 --> 01:28:02,910
Jei bandote padaryti
tai, jei jūs bandote

2003
01:28:02,910 --> 01:28:05,730
mastelį ant reliacinės platforma,
Tai yra tai, ką jūs darote.

2004
01:28:05,730 --> 01:28:08,100
Jūs vartojate duomenis ir
jūs sumažinate jį žemyn.

2005
01:28:08,100 --> 01:28:10,975
Ir jūs atitvarų jį per
keli atvejai duomenų bazę.

2006
01:28:10,975 --> 01:28:13,580
Ir jūs valdyti visa tai
klijavimo pakopos.

2007
01:28:13,580 --> 01:28:14,729
Tai nėra smagu.

2008
01:28:14,729 --> 01:28:15,770
Taigi, ką mes norime eiti?

2009
01:28:15,770 --> 01:28:20,240
Mes norime eiti DynamoDB, pilnai valdomas,
NoSQL duomenų saugyklos, nuostata pralaidumas.

2010
01:28:20,240 --> 01:28:22,680
Mes naudojame antrinių indeksus.

2011
01:28:22,680 --> 01:28:26,154
Tai iš esmės HTTP API ir
apima dokumento paramą.

2012
01:28:26,154 --> 01:28:28,570
Taigi jūs neturite jaudintis
apie bet kokius šio padalijimo.

2013
01:28:28,570 --> 01:28:30,740
Mes visa tai už jus.

2014
01:28:30,740 --> 01:28:33,260
Taigi dabar, vietoj to, galite
tiesiog parašyti į lentelę.

2015
01:28:33,260 --> 01:28:36,490
Jei lentelėje turi būti padalintas,
tai atsitiks užkulisiuose.

2016
01:28:36,490 --> 01:28:40,642
Jūs esate visiškai izoliuotas
nuo kaip kūrėjas.

2017
01:28:40,642 --> 01:28:42,350
Taigi pakalbėkime apie
kai naudojimo atvejais

2018
01:28:42,350 --> 01:28:47,564
kad mes paleisti į lošimo, bendra
žaidimų scenarijai, Iškabos.

2019
01:28:47,564 --> 01:28:49,980
Taigi, jūs turite vartotojai ateina,
kad BoardNames, kad jie

2020
01:28:49,980 --> 01:28:52,930
ant, už šį klientą balai.

2021
01:28:52,930 --> 01:28:57,700
Mes galime būti maišos ant UserId,
ir tada mes turime įvairių apie žaidimą.

2022
01:28:57,700 --> 01:28:59,960
Taigi kiekvienas vartotojas nori pamatyti
visi žaidimas jis grojo

2023
01:28:59,960 --> 01:29:01,770
ir visi jo geriausias rezultatas
visose žaidimo.

2024
01:29:01,770 --> 01:29:04,000
Taigi, kad jo asmens Iškabos.

2025
01:29:04,000 --> 01:29:10,010
>> Dabar aš noriu eiti, ir aš noriu get--
todėl aš gauti šiuos asmens Lyderių.

2026
01:29:10,010 --> 01:29:12,827
Ką aš noriu padaryti, tai eikite gauti
top rezultatas visiems vartotojams.

2027
01:29:12,827 --> 01:29:13,660
Taigi, kaip man tai padaryti?

2028
01:29:13,660 --> 01:29:18,070
Kai mano įrašas yra sumaišomas su
userid, svyravo nuo žaidimo,

2029
01:29:18,070 --> 01:29:20,740
gerai aš ruošiuosi eiti į priekį
ir restruktūrizuoti, sukurti GSI,

2030
01:29:20,740 --> 01:29:22,370
ir aš ruošiuosi pertvarkyti, kad duomenis.

2031
01:29:22,370 --> 01:29:27,310
>> Dabar aš ruošiuosi maišos ant
BoardName, kuri yra žaidimas.

2032
01:29:27,310 --> 01:29:29,800
Ir aš ruošiuosi svyruoja ant viršaus rezultatą.

2033
01:29:29,800 --> 01:29:31,540
Ir dabar aš sukūriau skirtingus kibirus.

2034
01:29:31,540 --> 01:29:34,790
Aš naudoju tą patį stalą,
to paties objekto duomenų.

2035
01:29:34,790 --> 01:29:39,870
Bet aš sukurti kibirą, kuris suteikia
man aukščiausios rezultatas agregaciją žaidimą.

2036
01:29:39,870 --> 01:29:43,180
>> Ir aš galiu užklausti šią lentelę
gauti šią informaciją.

2037
01:29:43,180 --> 01:29:50,890
Taigi aš nustatyti, kad užklausos modelio iki
būti palaikoma antrinio indekso.

2038
01:29:50,890 --> 01:29:54,556
Dabar jie gali būti rūšiuojami pagal BoardName
ir rūšiuojami pagal geriausias rezultatas, priklausomai nuo.

2039
01:29:54,556 --> 01:29:57,180
Taigi matote, tai yra rūšys
naudojimo atvejais jūs gaunate žaidimų.

2040
01:29:57,180 --> 01:30:02,190
Dar viena gera naudojimo atveju mes gauname iš žaidimų
yra apdovanojimai ir kas laimėjo apdovanojimus.

2041
01:30:02,190 --> 01:30:05,340
Ir tai yra puiki naudojimo atveju
kur mes vadiname retus indeksus.

2042
01:30:05,340 --> 01:30:07,340
Sparse indeksai yra
Gebėjimas generuoti

2043
01:30:07,340 --> 01:30:10,850
indeksas, kad nebūtinai
būti kiekvieną elementą ant stalo.

2044
01:30:10,850 --> 01:30:11,470
Ir kodėl gi ne?

2045
01:30:11,470 --> 01:30:14,540
Kadangi atributas, kad manimi yra
indeksuotą neegzistuoja kiekvieną elementą.

2046
01:30:14,540 --> 01:30:16,460
>> Taigi, šis konkretus
naudojimo atveju, aš sakau,

2047
01:30:16,460 --> 01:30:19,240
jūs žinote, ką aš ruošiuosi
sukurti atributas vadinamas apdovanojimas.

2048
01:30:19,240 --> 01:30:22,970
Ir aš ruošiuosi duoti kiekvienam vartotojui
kad turi apdovanojimą, kad atributas.

2049
01:30:22,970 --> 01:30:25,950
Vartotojai, kurie neturi apdovanojimai
nesiruošia turėti, kad atributas.

2050
01:30:25,950 --> 01:30:27,800
Taigi, kai aš sukurti
indeksas, tik vartotojai

2051
01:30:27,800 --> 01:30:28,960
kad ketiname parodyti
iki indekse yra

2052
01:30:28,960 --> 01:30:31,050
tie, kurie iš tikrųjų turi laimėjo apdovanojimus.

2053
01:30:31,050 --> 01:30:34,440
Štai puikus būdas, kad būtų galima
sukurti filtruojami indeksus, kad

2054
01:30:34,440 --> 01:30:40,580
yra labai, labai selektyvus, kad ne
turi indeksuoti visą lentelę.

2055
01:30:40,580 --> 01:30:43,050
>> Taigi mes vis mažai laiko čia.

2056
01:30:43,050 --> 01:30:49,190
Aš ruošiuosi eiti į priekį ir praleisti
, ir praleisti šį scenarijų.

2057
01:30:49,190 --> 01:30:52,625
Kalbėti šiek tiek about--

2058
01:30:52,625 --> 01:30:54,460
>> Auditorija: Ar galiu paklausti, greitai klausimą?

2059
01:30:54,460 --> 01:30:56,722
Vienas iš jų yra parašyti sunki?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Kas yra?

2061
01:30:57,680 --> 01:30:58,596
Auditorija: Rašyti sunkus.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Rašyti sunkus.

2063
01:31:01,270 --> 01:31:03,460
Leisk pažiūrėti.

2064
01:31:03,460 --> 01:31:06,220
>> Auditorija: ar tai, kad nėra
ką jūs galite tiesiog

2065
01:31:06,220 --> 01:31:08,809
balsas per kelias sekundes klausimu?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Mes einame
per balsavimo scenarijų.

2067
01:31:10,850 --> 01:31:11,670
Tai nereiškia, kad blogai.

2068
01:31:11,670 --> 01:31:14,580
Ar vaikinai turi keletą minučių?

2069
01:31:14,580 --> 01:31:15,860
GERAI.

2070
01:31:15,860 --> 01:31:17,890
>> Taigi mes kalbame apie balsavimo.

2071
01:31:17,890 --> 01:31:20,250
Taigi realaus laiko balsavimo, mes turime
reikalavimai balsavimo.

2072
01:31:20,250 --> 01:31:25,250
Reikalavimai yra tai, kad mes leidžiame
kiekvienas asmuo balsuoti tik vieną kartą.

2073
01:31:25,250 --> 01:31:28,060
Mes norime, kad niekas, kad būtų galima
pakeisti savo balsą.

2074
01:31:28,060 --> 01:31:31,045
Mes norime, kad realaus laiko agregaciją
ir analitikai demografija

2075
01:31:31,045 --> 01:31:34,210
kad mes ketiname būti
rodo, kad vartotojams svetainėje.

2076
01:31:34,210 --> 01:31:35,200
>> Pagalvokite apie šį scenarijų.

2077
01:31:35,200 --> 01:31:37,550
Mes dirbame realybės daug
TV šou, kur jie

2078
01:31:37,550 --> 01:31:38,960
daro šias tikslaus tipo dalykų.

2079
01:31:38,960 --> 01:31:41,584
Taigi jūs galite galvoti scenarijų,
mes turime milijonus

2080
01:31:41,584 --> 01:31:43,959
iš paauglės ten
su savo mobiliuosius telefonus

2081
01:31:43,959 --> 01:31:46,250
ir balsuoti, ir balsuoti, ir
balsuosiu už tas, kas jie yra

2082
01:31:46,250 --> 01:31:48,610
rasti labiausiai populiarus.

2083
01:31:48,610 --> 01:31:50,830
Taigi jie yra vieni iš
reikalavimai mes baigsis.

2084
01:31:50,830 --> 01:31:52,990
>> Ir taip pirmasis imtis
sprendžiant šią problemą

2085
01:31:52,990 --> 01:31:55,090
būtų pastatyti
labai paprasta programa.

2086
01:31:55,090 --> 01:31:56,490
Taigi aš turiu šią programą.

2087
01:31:56,490 --> 01:31:57,950
Turiu kai kurių rinkėjų ten.

2088
01:31:57,950 --> 01:31:59,980
Jie būna, jie nukentėjo balsavimo programą.

2089
01:31:59,980 --> 01:32:03,440
Aš turiu šiek tiek žalio balsų lentelę
Aš tiesiog iškelties tuos balsus į.

2090
01:32:03,440 --> 01:32:05,780
Aš turiu šiek tiek agregatas
balsų stalas,

2091
01:32:05,780 --> 01:32:09,490
darysiu Analytics ir demografija,
ir mes įdėti visa tai ten.

2092
01:32:09,490 --> 01:32:11,420
>> Ir tai yra didelis.

2093
01:32:11,420 --> 01:32:12,332
Gyvenimas yra geras.

2094
01:32:12,332 --> 01:32:15,040
Gyvenimas geras, kol randame, kad
visada tik vienas ar du

2095
01:32:15,040 --> 01:32:16,879
žmonės, kurie populiarūs rinkimus.

2096
01:32:16,879 --> 01:32:19,420
Yra tik vienas ar du dalykai
kad žmonės tikrai rūpi.

2097
01:32:19,420 --> 01:32:22,340
Ir jei jūs balsuodamas
masto, visi staiga aš

2098
01:32:22,340 --> 01:32:26,360
bus kala pragarą iš
du kandidatai, vienas arba du kandidatų.

2099
01:32:26,360 --> 01:32:29,390
Labai nedaug daiktų
žmonių mano, kad būtų populiarus.

2100
01:32:29,390 --> 01:32:31,710
>> Tai nėra geras dizainas modelis.

2101
01:32:31,710 --> 01:32:33,549
Tai iš tikrųjų
labai blogas dizainas modelis

2102
01:32:33,549 --> 01:32:36,340
nes ji sukuria būtent tai, ko mes
kalbėjo apie kurį buvo karštieji klavišai.

2103
01:32:36,340 --> 01:32:38,960
Klavi kažkas mums nepatinka.

2104
01:32:38,960 --> 01:32:40,470
>> Taigi, kaip mes nustatyti, kad?

2105
01:32:40,470 --> 01:32:47,640
Ir tikrai, būdas išspręsti šią problemą yra
atsižvelgiant tas kandidates kibirai

2106
01:32:47,640 --> 01:32:51,490
ir kiekvieno kandidato mes,
mes ketiname pridėti atsitiktinis vertę,

2107
01:32:51,490 --> 01:32:54,192
kažkas, kad mes žinome, atsitiktinai
vertė tarp vieno ir 100,

2108
01:32:54,192 --> 01:32:56,620
tarp 100 ir 1000,
arba tarp vieno ir 1000,

2109
01:32:56,620 --> 01:32:59,940
Tačiau daugelis atsitiktinių dydžių norite
prideda ant tos kandidato pabaigoje.

2110
01:32:59,940 --> 01:33:01,330
>> Ir ką aš tikrai padaryti tada?

2111
01:33:01,330 --> 01:33:05,830
Jei aš naudojant kandidato ID, kaip
į suvestinius balsų kibiras,

2112
01:33:05,830 --> 01:33:08,780
jei aš pridėjome atsitiktinis
numeris, kad pabaigoje,

2113
01:33:08,780 --> 01:33:12,000
Aš sukūriau dabar 10 kibirai A
šimtą kibirai, tūkstantis kaušai

2114
01:33:12,000 --> 01:33:14,160
kad aš sudedant balsus visoje.

2115
01:33:14,160 --> 01:33:18,030
>> Taigi turiu milijonus ir milijonus,
ir milijonai įrašų ateinantį

2116
01:33:18,030 --> 01:33:22,050
šių kandidatų, aš dabar plinta
tie balsai visoje A_1 kandidatinį

2117
01:33:22,050 --> 01:33:24,630
per A_100 kandidačių, nes
kiekvieną kartą, kai balsas ateina,

2118
01:33:24,630 --> 01:33:26,530
Aš generuoti atsitiktinis
vertė tarp vieno ir 100.

2119
01:33:26,530 --> 01:33:29,446
Aš sujungdamas jį į galutinio
Kandidatas kad asmens balsuoti už.

2120
01:33:29,446 --> 01:33:31,120
Aš dempingo ją į tą kibirą.

2121
01:33:31,120 --> 01:33:33,910
>> Dabar reversas, aš žinau,
kad aš turiu šimtus kibirų.

2122
01:33:33,910 --> 01:33:36,350
Taigi, kai aš noriu eiti į priekį
ir apibendrinti balsus,

2123
01:33:36,350 --> 01:33:38,244
Aš perskaičiau iš visų tų kibirų.

2124
01:33:38,244 --> 01:33:39,160
Taigi aš eiti į priekį ir pridėti.

2125
01:33:39,160 --> 01:33:42,410
Ir tada aš sklaida surinkti
kur aš išeiti ir pasakyti ei,

2126
01:33:42,410 --> 01:33:45,399
Žinai ką, Kandidatą raktas
tarpai yra daugiau nei šimtą kaušai.

2127
01:33:45,399 --> 01:33:47,940
Aš ruošiuosi surinkti visus
balsus iš tų šimto kibirų.

2128
01:33:47,940 --> 01:33:49,981
Aš ruošiuosi kaupti
juos ir aš ruošiuosi pasakyti,

2129
01:33:49,981 --> 01:33:53,830
Kandidatas dabar
Iš viso balsų skaičiavimo x.

2130
01:33:53,830 --> 01:33:55,690
>> Dabar tiek rašymo
Užklausa ir skaityti užklausa

2131
01:33:55,690 --> 01:33:58,160
gražiai pasiskirsto
nes aš rašau visoje

2132
01:33:58,160 --> 01:34:00,320
ir aš skaitau visoje šimtus raktus.

2133
01:34:00,320 --> 01:34:03,500
Aš ne rašyti ir
skaityti per vieną raktą dabar.

2134
01:34:03,500 --> 01:34:04,950
Štai puikus modelis.

2135
01:34:04,950 --> 01:34:08,090
>> Tai iš tikrųjų turbūt vienas
iš svarbiausių dizaino

2136
01:34:08,090 --> 01:34:10,420
modelius masto NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Jūs pamatysite šį tipą
projektavimo šablono kiekvieną skonį.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, ji neturi
Nesvarbu, mes visi turime tai padaryti.

2139
01:34:19,100 --> 01:34:21,840
Nes kai jūs susiduriame
su tais didžiuliais apibendrinimo,

2140
01:34:21,840 --> 01:34:26,650
jūs turite išsiaiškinti, kaip į
skleisti juos visoje kibirai.

2141
01:34:26,650 --> 01:34:29,512
Taigi tai yra būdas jums tai padaryti.

2142
01:34:29,512 --> 01:34:31,220
Gerai, kad tai, kas
jūs darote dabar

2143
01:34:31,220 --> 01:34:35,252
yra jūs prekybos išjungti skaityti
išlaidos rašymo mastelio.

2144
01:34:35,252 --> 01:34:37,085
Mano perskaitytą kaina
šiek tiek daugiau kompleksas

2145
01:34:37,085 --> 01:34:40,220
ir aš turiu eiti perskaityti iš
šimtas vienas kibirai vietoj.

2146
01:34:40,220 --> 01:34:41,310
Bet aš galėtų parašyti.

2147
01:34:41,310 --> 01:34:44,860
Ir mano pralaidumas, mano rašymo
pralaidumas yra neįtikėtinas.

2148
01:34:44,860 --> 01:34:49,450
Taigi, tai paprastai yra vertingas
technika mastelio DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
ar NoSQL duomenų šiuo klausimu.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Taigi, mes suprato, kaip jo mastelį.

2152
01:34:55,240 --> 01:34:56,930
Ir mes sugalvojome kaip
pašalinti mūsų sparčiuosius klavišus.

2153
01:34:56,930 --> 01:34:57,820
Ir tai yra fantastinis.

2154
01:34:57,820 --> 01:34:58,960
Ir mes turime šį gražią sistemą.

2155
01:34:58,960 --> 01:35:02,043
Ir tai mums suteikė labai teisingą balsavimo
nes mes turime įrašyti balsų de-Dupe.

2156
01:35:02,043 --> 01:35:03,130
Jis pastatytas į DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Mes kalbėjome apie sąlyginių teisių.

2158
01:35:05,380 --> 01:35:08,170
>> Kai rinkėjas ateina, užsideda
on stalo įterpti,

2159
01:35:08,170 --> 01:35:11,220
jie įterpti savo rinkėjų ID,
jei jie bando įterpti dar vieną balsą,

2160
01:35:11,220 --> 01:35:13,320
Aš sąlyginį rašyti.

2161
01:35:13,320 --> 01:35:16,960
Pasakykite rašyti tik ši
jei tai neegzistuoja.

2162
01:35:16,960 --> 01:35:19,270
Taigi kuo greičiau matau, kad
kad balsas hito lentelę,

2163
01:35:19,270 --> 01:35:20,460
niekas ketina būti
galėtų įdėti savo balsą.

2164
01:35:20,460 --> 01:35:21,634
Ir tai fantastinis.

2165
01:35:21,634 --> 01:35:23,550
Ir mes incrementing
Mūsų kandidatės skaitikliai.

2166
01:35:23,550 --> 01:35:25,466
Ir mes darome
demografijos ir visa kita.

2167
01:35:25,466 --> 01:35:29,110
Bet kas atsitinka, jei mano
taikymas patenka per?

2168
01:35:29,110 --> 01:35:31,350
Dabar visi staiga balsų
yra ateinantį ir man

2169
01:35:31,350 --> 01:35:34,840
nežinau, jei jie gauti perdirbti
į mano analitikai ir demografija

2170
01:35:34,840 --> 01:35:36,040
nebėra.

2171
01:35:36,040 --> 01:35:38,462
Ir kai paraiška
grįžta iki, kaip

2172
01:35:38,462 --> 01:35:41,420
po velnių aš žinau, ką balsai
buvo tvarkomi ir kur man pradėti?

2173
01:35:41,420 --> 01:35:44,530
>> Taigi tai yra tikra problema, kai jūs
pradėti ieškoti šio scenarijaus tipo.

2174
01:35:44,530 --> 01:35:45,571
Ir kaip mes sprendžiame, kad?

2175
01:35:45,571 --> 01:35:48,070
Mes ją išspręsti, ką mes
skambinti DynamoDB srautus.

2176
01:35:48,070 --> 01:35:53,470
Srautai yra laikas užsisakyti ir
atitverta Pakeitimai registruojami kiekvieno galimybės

2177
01:35:53,470 --> 01:35:55,700
į lentelę, kiekvienas rašyti
prieiga prie stalo.

2178
01:35:55,700 --> 01:35:58,810
Bet duomenys, parašyta į
Lentelėje parodyta, ant upelio.

2179
01:35:58,810 --> 01:36:01,815
>> Tai iš esmės 24 valandų eilėje.

2180
01:36:01,815 --> 01:36:03,690
Daiktai nukentėjo srautą,
jie gyvena 24 valandas.

2181
01:36:03,690 --> 01:36:05,990
Jie gali būti skaitomos kelis kartus.

2182
01:36:05,990 --> 01:36:09,400
Garantuotas turi būti pristatytas
tik vieną kartą į srautą,

2183
01:36:09,400 --> 01:36:11,180
galėtų būti skaitomos n skaičių kartų.

2184
01:36:11,180 --> 01:36:14,910
Taigi, tačiau daugelis procesų norite
vartojame tuos duomenis, galite jį valgo.

2185
01:36:14,910 --> 01:36:16,350
Jis bus rodomas kiekvieną atnaujinimą.

2186
01:36:16,350 --> 01:36:18,455
Kiekvienas Parašyti bus tik
kartą ant upelio.

2187
01:36:18,455 --> 01:36:20,621
Taigi jūs neturite jaudintis
apie ją apdoroti du kartus

2188
01:36:20,621 --> 01:36:22,500
iš to paties proceso metu.

2189
01:36:22,500 --> 01:36:25,350
>> Jis griežtai įsakė už vienetą.

2190
01:36:25,350 --> 01:36:28,180
Kai mes sakome laikas
užsisakyti ir atitverta,

2191
01:36:28,180 --> 01:36:30,680
pamatysite už pertvaros nuo upelio.

2192
01:36:30,680 --> 01:36:33,169
Pamatysite elementus, atnaujinimus tvarka.

2193
01:36:33,169 --> 01:36:35,210
Mes nesame garantuoti
ant upelio, kad jūs

2194
01:36:35,210 --> 01:36:40,240
ketinate gauti kiekvienas sandoris
į visoje daiktų tvarka.

2195
01:36:40,240 --> 01:36:42,440
>> Taigi srautai yra idempotent.

2196
01:36:42,440 --> 01:36:44,037
Ar mes visi žinome, kas idempotent reiškia?

2197
01:36:44,037 --> 01:36:46,620
Idempotent reiškia, kad jūs galite tai padaryti
daugiau, ir daugiau, ir vėl.

2198
01:36:46,620 --> 01:36:48,200
Rezultatas ketina būti ta pati.

2199
01:36:48,200 --> 01:36:49,991
>> Srautai yra idempotent,
tačiau jie turi būti

2200
01:36:49,991 --> 01:36:54,860
grojo nuo pradinio taško,
kur jums pasirinkti iki galo,

2201
01:36:54,860 --> 01:36:57,950
ar jie nebus
tose pačiose vertėmis.

2202
01:36:57,950 --> 01:36:59,727
>> Tas pats su MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB turi konstruktą
jie vadina oplog.

2204
01:37:01,560 --> 01:37:04,140
Tai yra lygiai toks pats konstruktas.

2205
01:37:04,140 --> 01:37:06,500
Daugelis NoSQL duomenų bazės
turi šį konstruktą.

2206
01:37:06,500 --> 01:37:08,790
Jie naudoja jį daryti tai, ko
kaip replikacija, kuris

2207
01:37:08,790 --> 01:37:10,475
yra būtent tai, ką mes darome su upelių.

2208
01:37:10,475 --> 01:37:12,350
Auditorija: Gal
erezija klausimas, bet jūs

2209
01:37:12,350 --> 01:37:13,975
kalbėti apie programos daro žemyn kt.

2210
01:37:13,975 --> 01:37:16,089
Ar srautai garantuotai
niekada galbūt eiti?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Taip, upelių
garantuoja, kad niekada eiti.

2212
01:37:18,630 --> 01:37:21,040
Mes valdyti infrastruktūrą
atsilieka. upelių automatiškai

2213
01:37:21,040 --> 01:37:22,498
dislokuoti savo Automatinis mastelio grupei.

2214
01:37:22,498 --> 01:37:25,910
Mes eiti per mažai
tiek apie tai, kas vyksta.

2215
01:37:25,910 --> 01:37:30,060
>> Aš ne pasakyti, kad jie nėra
garantuoja, kad niekada eiti.

2216
01:37:30,060 --> 01:37:33,110
Elementai yra garantuotas
atvykti į srautą.

2217
01:37:33,110 --> 01:37:36,740
Ir srautas bus prieinama.

2218
01:37:36,740 --> 01:37:40,580
Taigi, kas krinta arba grįžta
aukštyn, kad vyksta apačioje.

2219
01:37:40,580 --> 01:37:43,844
Tai covers-- viskas OK.

2220
01:37:43,844 --> 01:37:46,260
Gerai, taigi, galėsite gauti skirtingi
Peržiūrėti tipai išjungti ekrano.

2221
01:37:46,260 --> 01:37:51,040
Į view tipų, kurie yra svarbūs iki A
programuotojas paprastai yra, kas tai buvo?

2222
01:37:51,040 --> 01:37:52,370
Man seną vaizdą.

2223
01:37:52,370 --> 01:37:55,630
Kai atnaujinimas hitai lentelę, jis bus
stumti seną vaizdą į upelį

2224
01:37:55,630 --> 01:38:02,070
todėl duomenys gali archyvuoti ar pakeitimas
valdymo, pokyčių nustatymas, pakeitimas

2225
01:38:02,070 --> 01:38:03,600
valdymas.

2226
01:38:03,600 --> 01:38:07,160
>> Naujas įvaizdis, kas jis yra dabar, po
atnaujinimas, tai kita nuomone tipas

2227
01:38:07,160 --> 01:38:07,660
galite gauti.

2228
01:38:07,660 --> 01:38:09,660
Jūs galite gauti tiek senų ir naujų nuotraukų.

2229
01:38:09,660 --> 01:38:10,660
Gal aš noriu juos abu.

2230
01:38:10,660 --> 01:38:11,790
Noriu pamatyti, kas tai buvo.

2231
01:38:11,790 --> 01:38:13,290
Noriu pamatyti, ką ji pasikeitė.

2232
01:38:13,290 --> 01:38:15,340
>> Turiu atitikties tipą
proceso, kuris veikia.

2233
01:38:15,340 --> 01:38:17,430
Ji turi patikrinti, ar
kai šie dalykai pakeisti,

2234
01:38:17,430 --> 01:38:21,840
kad jie tam tikrose ribose
arba per tam tikrus parametrus.

2235
01:38:21,840 --> 01:38:23,840
>> Ir tada gal aš tik
reikia žinoti, kas pasikeitė.

2236
01:38:23,840 --> 01:38:26,240
Man nerūpi, ką punktas pakeistas.

2237
01:38:26,240 --> 01:38:28,580
Man nereikia, kad reikia žinoti
kas atributus pasikeitė.

2238
01:38:28,580 --> 01:38:30,882
Aš tiesiog reikia žinoti, kad
elementai yra palietė.

2239
01:38:30,882 --> 01:38:33,340
Taigi tai yra nuomonėmis tipai
kad jūs išlipti srautas

2240
01:38:33,340 --> 01:38:35,960
ir jūs galite bendrauti su.

2241
01:38:35,960 --> 01:38:37,840
>> Prašymas, kad
sunaudoja srautą,

2242
01:38:37,840 --> 01:38:39,298
tai yra rūšies, kaip ši dirba.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB klientas paprašys
stumti duomenis lentelėse.

2244
01:38:42,570 --> 01:38:44,750
Srautai dislokuoti apie tai, ką mes vadiname šukių.

2245
01:38:44,750 --> 01:38:47,380
Šukės yra mastelis
nepriklausomai lentelėje.

2246
01:38:47,380 --> 01:38:50,660
Jie neturi išsirikiuoti visiškai
prie jūsų stalo pertvaros.

2247
01:38:50,660 --> 01:38:52,540
Ir priežastis, kodėl yra
nes jie išsirikiuoja

2248
01:38:52,540 --> 01:38:55,430
su gebėjimu, dabartinis
talpa lentelėje.

2249
01:38:55,430 --> 01:38:57,600
>> Jie dislokuoti savo
savo auto mastelio grupė

2250
01:38:57,600 --> 01:39:00,800
ir jie pradeda suktis iš priklausomai
kiek rašo ateina į,

2251
01:39:00,800 --> 01:39:03,090
kiek reads-- tikrai tai rašo.

2252
01:39:03,090 --> 01:39:05,820
Nėra reads-- bet kaip
daug rašo ateina į.

2253
01:39:05,820 --> 01:39:08,200
>> Ir tada ant nugaros
Galų gale, mes turime tai, ką mes

2254
01:39:08,200 --> 01:39:11,390
skambinti KCl, ar kineziterapeutai Client biblioteka.

2255
01:39:11,390 --> 01:39:19,190
Kinesis yra upelis duomenys
apdorojimo technologija iš "Amazon".

2256
01:39:19,190 --> 01:39:22,040
Ir upelių yra pastatytas, kad.

2257
01:39:22,040 --> 01:39:25,670
>> Taigi jūs naudojate "KCL įjungta
taikymas skaityti srautą.

2258
01:39:25,670 --> 01:39:28,752
Kinesis Klientas biblioteka iš tikrųjų
valdo darbuotojams už jus.

2259
01:39:28,752 --> 01:39:30,460
Ir jis taip pat daro kai
įdomių dalykų.

2260
01:39:30,460 --> 01:39:35,630
Ji sukurs keletą lentelių iki
Jūsų DynamoDB tablespace

2261
01:39:35,630 --> 01:39:38,410
sekti, kokie daiktai
buvo tvarkomi.

2262
01:39:38,410 --> 01:39:41,190
Taigi tokiu būdu, jei jis patenka atgal, jei
jis patenka daugiau ir ateina ir gauna

2263
01:39:41,190 --> 01:39:45,570
stovėjo atgal, ji gali nustatyti, kur
Tai buvo perdirbti srautas.

2264
01:39:45,570 --> 01:39:48,360
>> Tai labai svarbu, kai
jūs kalbate apie replikacija.

2265
01:39:48,360 --> 01:39:50,350
Man reikia žinoti, ką
duomenys buvo apdorotas

2266
01:39:50,350 --> 01:39:52,810
ir kokie duomenys dar turi būti tvarkomi.

2267
01:39:52,810 --> 01:39:57,380
Taigi KCL biblioteka srautai
duoti jums tą funkcionalumą daug.

2268
01:39:57,380 --> 01:39:58,990
Ji rūpinasi visais buityje.

2269
01:39:58,990 --> 01:40:01,140
Ji atsistoja už kiekvieną Shard darbuotoją.

2270
01:40:01,140 --> 01:40:04,620
Jis sukuria administracinę lentelę
už kiekvieną Shard, kiekvienam darbuotojui.

2271
01:40:04,620 --> 01:40:07,560
Ir kaip tiems darbuotojams, gaisro,
jie gali išlaikyti tas lenteles

2272
01:40:07,560 --> 01:40:10,510
kad jūs žinote šį įrašą
buvo skaityti ir tvarkomi.

2273
01:40:10,510 --> 01:40:13,850
Ir tada, kad taip, jei procesas
miršta ir grįžta internete,

2274
01:40:13,850 --> 01:40:17,940
jis gali tęsti ten, kur jis išskrido.

2275
01:40:17,940 --> 01:40:20,850
>> Taigi, mes naudoti šį
kryžminio regionas replikacija.

2276
01:40:20,850 --> 01:40:24,680
Daug klientų turime poreikį
perkelti duomenis ar dalį savo duomenų lenteles

2277
01:40:24,680 --> 01:40:25,920
aplink skirtingų regionų.

2278
01:40:25,920 --> 01:40:29,230
Yra devyni regionai
visame pasaulyje.

2279
01:40:29,230 --> 01:40:32,100
Taigi gali būti need-- aš
gali turėti vartotojams Azijoje, vartotojai

2280
01:40:32,100 --> 01:40:34,150
į rytinėje JAV.

2281
01:40:34,150 --> 01:40:38,980
Jie turi skirtingus duomenis,
reikia lokaliai paskirstytas.

2282
01:40:38,980 --> 01:40:42,510
O gal vartotojas skrenda iš
Azija daugiau į Jungtines Amerikos Valstijas,

2283
01:40:42,510 --> 01:40:45,020
ir aš noriu pakartoti
jo duomenys su juo.

2284
01:40:45,020 --> 01:40:49,340
Taigi, kai jis gauna iš lėktuvo, jis turi
gera patirtis naudojant savo mobilųjį app.

2285
01:40:49,340 --> 01:40:52,360
>> Galite naudoti kryžminio regioną
replikacijos biblioteka tai padaryti.

2286
01:40:52,360 --> 01:40:55,730
Iš esmės mes turime
jeigu dvi technologijas.

2287
01:40:55,730 --> 01:40:59,400
One konsolės programa jūs galite
atsistoti ant savo EC2 pavyzdžiui.

2288
01:40:59,400 --> 01:41:01,240
Jis veikia grynas replikaciją.

2289
01:41:01,240 --> 01:41:02,720
Ir tada mes davė jums biblioteką.

2290
01:41:02,720 --> 01:41:06,070
Biblioteka galite naudoti norėdami sukurti
savo paraišką, jei jums

2291
01:41:06,070 --> 01:41:10,740
nori daryti beprotiškus dalykus, kad data--
filtras, atkartoti tik dalį jo,

2292
01:41:10,740 --> 01:41:14,120
pasukti duomenis, perkelti jį į "A
skiriasi lentelėje, taip toliau ir taip toliau.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Taigi, kad tipo kas tai atrodo.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Srautai gali būti
tvarkomi, ką mes vadiname Lambda.

2296
01:41:23,690 --> 01:41:27,394
Mes paminėti šiek tiek apie renginį
orientuotų technologijų taikymo architektūros.

2297
01:41:27,394 --> 01:41:28,810
Lambda "yra pagrindinė sudedamoji dalis, kad.

2298
01:41:28,810 --> 01:41:32,840
Lambda "yra kodas, kuris gaisrai pagal pareikalavimą
reaguojant į tam tikrą atveju.

2299
01:41:32,840 --> 01:41:36,020
Vienas iš šių įvykių gali būti
įrašas rodomas upelio.

2300
01:41:36,020 --> 01:41:39,100
Jei ant upelio atrodo įrašas,
mes tai vadiname "Java" funkciją.

2301
01:41:39,100 --> 01:41:44,980
Na, tai yra JavaScript ir "Lambda"
palaiko Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
ir netrukus remti
Kitos kalbos taip pat.

2303
01:41:47,820 --> 01:41:50,940
Ir pakanka pasakyti, kad tai grynas kodą.

2304
01:41:50,940 --> 01:41:53,610
rašyti Java, galite apibrėžti klasę.

2305
01:41:53,610 --> 01:41:55,690
Jūs stumti JAR aukštyn į Lambda.

2306
01:41:55,690 --> 01:42:00,200
Ir tada jūs nurodote kurią klasę
skambinti reaguojant į kurį renginį.

2307
01:42:00,200 --> 01:42:04,770
Ir tada "Lambda infrastruktūra
atsilieka, kad bus paleisti tą kodą.

2308
01:42:04,770 --> 01:42:06,730
>> Tas kodas gali apdoroti
įrašų off upelio.

2309
01:42:06,730 --> 01:42:08,230
Jis gali daryti ką ji nori su juo.

2310
01:42:08,230 --> 01:42:11,650
Šiuo konkrečiu Pavyzdžiui, visi mes
tikrai daro prisijungia atributus.

2311
01:42:11,650 --> 01:42:13,480
Bet tai tik kodas.

2312
01:42:13,480 --> 01:42:15,260
Kodas nieko negali padaryti, tiesa?

2313
01:42:15,260 --> 01:42:16,600
>> Taigi, galite pasukti, kad duomenis.

2314
01:42:16,600 --> 01:42:18,160
Jūs galite kurti išvestinį vaizdą.

2315
01:42:18,160 --> 01:42:21,160
Jei tai dokumentas, struktūra,
galite priploti struktūrą.

2316
01:42:21,160 --> 01:42:24,300
Jūs galite kurti pakaitinius rodiklius.

2317
01:42:24,300 --> 01:42:27,100
Visi rūšių dalykų galite
daryti su DynamoDB srautus.

2318
01:42:27,100 --> 01:42:28,780
>> Ir tikrai, tai ką tai atrodo.

2319
01:42:28,780 --> 01:42:29,940
Taigi Jūs gaunate tie atnaujinimai ateina.

2320
01:42:29,940 --> 01:42:31,190
Jie atskilimas eilutę.

2321
01:42:31,190 --> 01:42:32,720
Jie skaitys Lambda funkcija.

2322
01:42:32,720 --> 01:42:37,480
Jie sukasi duomenis ir
stumia jį į išvestines lenteles,

2323
01:42:37,480 --> 01:42:42,200
pranešdama apie išorines sistemas kaita,
ir stumia duomenis į ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Mes kalbėjome apie tai, kaip įdėti atminties turinį
priešais duomenų bazėje, kad pardavimo

2325
01:42:45,900 --> 01:42:46,450
scenarijus.

2326
01:42:46,450 --> 01:42:50,049
Na, kas atsitinka, jei aš
atnaujinti elemento aprašymą?

2327
01:42:50,049 --> 01:42:52,340
Na, jei aš buvo "Lambda"
funkcija veikia toje lentelėje,

2328
01:42:52,340 --> 01:42:55,490
jei aš atnaujinti elemento aprašymą, jis bus
pasiimti įrašą išjungti srovę,

2329
01:42:55,490 --> 01:42:58,711
ir jis bus atnaujinti ElastiCache
pavyzdžiui, su naujais duomenimis.

2330
01:42:58,711 --> 01:43:00,460
Taigi, kad daug
Ką mes darome su Lambda.

2331
01:43:00,460 --> 01:43:02,619
Tai klijai kodas, jungtys.

2332
01:43:02,619 --> 01:43:04,410
Ir tai iš tikrųjų suteikia
gebėjimas pradėti

2333
01:43:04,410 --> 01:43:07,930
ir paleisti labai sudėtingas programas
be serveris

2334
01:43:07,930 --> 01:43:10,371
infrastruktūra, kuri yra tikrai cool.

2335
01:43:10,371 --> 01:43:13,100
>> Taigi grįžkime prie mūsų
realaus laiko balsavimo architektūra.

2336
01:43:13,100 --> 01:43:17,984
Tai naujas ir patobulintas su mūsų
upelių ir KCL leido paraišką.

2337
01:43:17,984 --> 01:43:20,150
Tas pats, kaip ir anksčiau, mes galime
dirbti bet rinkimuose mastą.

2338
01:43:20,150 --> 01:43:21,100
Mums patinka tai.

2339
01:43:21,100 --> 01:43:24,770
Mes darome iš sklaida, renkasi
kelis kibirus.

2340
01:43:24,770 --> 01:43:26,780
Mes turime optimistiškai fiksavimo vyksta.

2341
01:43:26,780 --> 01:43:30,192
Mes galime išlaikyti mūsų rinkėjus
keisti savo balsus.

2342
01:43:30,192 --> 01:43:31,400
Jie gali balsuoti tik vieną kartą.

2343
01:43:31,400 --> 01:43:32,880
Tai fantastinis.

2344
01:43:32,880 --> 01:43:35,895
Realaus laiko kaltė, tolerancija,
keičiamo dydžio agregacija dabar.

2345
01:43:35,895 --> 01:43:38,270
Jei dalykas patenka daugiau, tai
žino, kur iš naujo save

2346
01:43:38,270 --> 01:43:41,300
kai kalbama apie atsargines kopijas, nes
mes naudojant KCl programą.

2347
01:43:41,300 --> 01:43:45,700
Ir tada mes taip pat galime naudoti, kad
KCL taikymas stumti duomenis iš

2348
01:43:45,700 --> 01:43:48,820
į Redshift kitiems
App Analytics "arba naudoti

2349
01:43:48,820 --> 01:43:51,990
elastinga MapReduce paleisti
realaus laiko transliacijos apibendrinus išjungt

2350
01:43:51,990 --> 01:43:53,180
tos duomenų.

2351
01:43:53,180 --> 01:43:55,480
>> Taigi tai yra tai, ką mes
ne kalbėjo apie daug.

2352
01:43:55,480 --> 01:43:57,375
Bet jie papildomai
technologijos, kurios ateina

2353
01:43:57,375 --> 01:44:00,310
padengti, kai jūs ieškote
Šiuose scenarijų tipų.

2354
01:44:00,310 --> 01:44:03,160
>> Gerai, kad yra apie
Analytics DynamoDB srautus.

2355
01:44:03,160 --> 01:44:05,340
Jūs galite rinkti de-Dupe
duomenys, tai visų rūšių

2356
01:44:05,340 --> 01:44:09,490
Nicos stuff, Užpildų duomenys
atmintis, sukurti tų išvestinių lentelių.

2357
01:44:09,490 --> 01:44:13,110
Tai didžiulis naudojimo atveju
kad daug klientų

2358
01:44:13,110 --> 01:44:16,950
yra susiję su, atsižvelgiant lizdinė
savybės tų JSON dokumentų

2359
01:44:16,950 --> 01:44:18,946
ir sukurti papildomų rodykles.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Mes pabaigoje.

2362
01:44:23,150 --> 01:44:26,689
Dėkojame už guolis su manimi.

2363
01:44:26,689 --> 01:44:28,480
Taigi pakalbėkime apie
Pamatinė architektūra.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB sėdi viduryje taip
daug AWS infrastruktūrą.

2365
01:44:33,440 --> 01:44:37,090
Iš esmės, galite jį prijungti
iki ko norite.

2366
01:44:37,090 --> 01:44:45,600
Programos sukurta naudojant "Dinamo" apima
Lambda ", ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
stumti duomenis iš į Elastinis
MapReduce, importas eksportas iš DynamoDB

2368
01:44:49,890 --> 01:44:52,370
į S3, visų rūšių darbo krūvius.

2369
01:44:52,370 --> 01:44:54,120
Bet turbūt geriausias
dalykas kalbėti apie,

2370
01:44:54,120 --> 01:44:56,119
ir tai, kas iš tikrųjų
Įdomu tai, kai mes

2371
01:44:56,119 --> 01:44:58,350
kalbėti apie įvykį lėmė programų.

2372
01:44:58,350 --> 01:45:00,300
>> Tai yra pavyzdys
vidinis projektas

2373
01:45:00,300 --> 01:45:04,850
kad mes turime kur mes iš tikrųjų
leidyba surinkti tyrimo rezultatus.

2374
01:45:04,850 --> 01:45:07,700
Taigi saitą el, kad
mes siunčiame, ten

2375
01:45:07,700 --> 01:45:11,350
būti šiek tiek nurodo sakydamas paspaudimas
čia atsakyti į apklausos.

2376
01:45:11,350 --> 01:45:14,070
Ir kai žmogus spustels
kurie nurodo, kas atsitinka,

2377
01:45:14,070 --> 01:45:18,020
yra jos išgriauti saugus
HTML apklausos forma nuo S3.

2378
01:45:18,020 --> 01:45:18,980
Nėra serveris.

2379
01:45:18,980 --> 01:45:20,600
Tai yra tik S3 objektas.

2380
01:45:20,600 --> 01:45:22,770
>> Tai forma ateina,
krovinius iki naršyklėje.

2381
01:45:22,770 --> 01:45:24,240
Jis gavo pagrindas.

2382
01:45:24,240 --> 01:45:30,160
Jis gavo kompleksas "JavaScript"
kad jis veikia.

2383
01:45:30,160 --> 01:45:33,557
Taigi tai labai turtingas programa
veikia kliento naršyklėje.

2384
01:45:33,557 --> 01:45:36,390
Jie nežino, kad jie ne
bendrauja su nugaros pabaigos serveryje.

2385
01:45:36,390 --> 01:45:38,220
Šiuo metu, tai visi naršyklėje.

2386
01:45:38,220 --> 01:45:41,780
>> Jie paskelbia į rezultatus kas
mes vadiname Amazonės API Vartai.

2387
01:45:41,780 --> 01:45:46,270
API Vartai yra tiesiog Web API
kad jūs galite nustatyti ir Pajungti

2388
01:45:46,270 --> 01:45:47,760
į ką nori.

2389
01:45:47,760 --> 01:45:50,990
Šiuo konkrečiu atveju, mes
užsikabinęs Lambda funkcija.

2390
01:45:50,990 --> 01:45:54,797
>> Taigi, mano siuntimo operacija
vyksta be serverio.

2391
01:45:54,797 --> 01:45:56,380
Iš esmės, kad API Vartai sėdi ten.

2392
01:45:56,380 --> 01:45:58,770
Tai kainuoja man nieko, kol žmonės
Pradėti rašyti į ją, tiesa?

2393
01:45:58,770 --> 01:46:00,269
Lambda funkcija tiesiog sėdi ten.

2394
01:46:00,269 --> 01:46:03,760
Ir tai kainuoja man nieko, kol
žmonės pradeda pataikyti ją.

2395
01:46:03,760 --> 01:46:07,270
Taigi matote, kaip tūrio
padidėja, tai kai mokesčiai ateis.

2396
01:46:07,270 --> 01:46:09,390
Nesu veikia serverio 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Taigi aš traukti formą
krinta iš kibiro,

2398
01:46:12,310 --> 01:46:15,719
ir aš rašyti per API
Vartai į Lambda funkcija.

2399
01:46:15,719 --> 01:46:17,510
Ir tada "Lambda"
funkcija sako, žinote,

2400
01:46:17,510 --> 01:46:20,600
ką, aš turiu keletą PIIs, kai
asmeniškai identifikuojančią informaciją

2401
01:46:20,600 --> 01:46:21,480
Šiose atsakymų.

2402
01:46:21,480 --> 01:46:23,020
Gavau komentarus mašinos iš vartotojų.

2403
01:46:23,020 --> 01:46:24,230
Aš turiu elektroninio pašto adresus.

2404
01:46:24,230 --> 01:46:26,190
Aš turiu vardus.

2405
01:46:26,190 --> 01:46:27,810
>> Leiskite padalinti šią funkciją.

2406
01:46:27,810 --> 01:46:30,280
Aš ruošiuosi generuoti kai
metaduomenų išjungti šio įrašo.

2407
01:46:30,280 --> 01:46:32,850
Ir aš ruošiuosi stumti
metaduomenis į DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Ir aš galėčiau užšifruoti visus duomenis
ir stumti jį į DynamoDB jei noriu.

2409
01:46:36,059 --> 01:46:38,600
Bet tai lengviau man, šiame
naudojimo atveju, eiti į priekį žinutę nuomonę,

2410
01:46:38,600 --> 01:46:42,800
Aš ruošiuosi stumti neapdorotus duomenis
į saugiame S3 kibirą.

2411
01:46:42,800 --> 01:46:47,240
Tad aš naudoju pastatytas S3 serverio pusėje
šifravimo ir "Amazon" raktų valdymo

2412
01:46:47,240 --> 01:46:51,600
Paslaugų kad turiu raktą,
galima pasukti reguliariai intervalu,

2413
01:46:51,600 --> 01:46:55,010
ir aš galiu apsaugoti, kad PCAD duomenis
kaip visą šią darbo eigą.

2414
01:46:55,010 --> 01:46:55,870
>> Taigi, ką aš padariau?

2415
01:46:55,870 --> 01:47:00,397
Aš ką tik įdiegta visa
taikymo, ir aš neturiu serverio.

2416
01:47:00,397 --> 01:47:02,980
Taigi, kas įvykis lėmė taikymą
architektūra daro už jus.

2417
01:47:02,980 --> 01:47:05,730
>> Dabar, jei jūs manote apie
naudojimo atveju už this--

2418
01:47:05,730 --> 01:47:08,730
turime kitų klientų Aš kalbu
iki maždaug taisyti architektūros, kuris

2419
01:47:08,730 --> 01:47:14,560
paleisti fenomenaliai didelės kampanijas, kurie
žiūri tai ir vyksta, Oh my.

2420
01:47:14,560 --> 01:47:17,840
Nes dabar, jie gali
iš esmės stumti jį iš ten,

2421
01:47:17,840 --> 01:47:21,900
leisti, kad kampaniją tiesiog sėdėti
ten tol, kol ji pradeda, o ne

2422
01:47:21,900 --> 01:47:24,400
jaudintis figos apie
kokios infrastruktūros

2423
01:47:24,400 --> 01:47:26,120
bus ten ją paremti.

2424
01:47:26,120 --> 01:47:28,600
Ir tada, kai tik
kad kampanija bus padaryta,

2425
01:47:28,600 --> 01:47:31,520
tai kaip infrastruktūros
tiesiog iš karto nueina

2426
01:47:31,520 --> 01:47:33,680
nes ten tikrai
jokios infrastruktūros.

2427
01:47:33,680 --> 01:47:35,660
Tai tiesiog kodas, kuris sėdi ant Lambda.

2428
01:47:35,660 --> 01:47:38,560
Tai tiesiog duomenų, kad sėdi DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Tai nuostabi būdas
kurti programas.

2430
01:47:41,340 --> 01:47:43,970
>> Auditorija: Taigi tai daugiau
efemeriška, nei ji būtų

2431
01:47:43,970 --> 01:47:45,740
jei jis buvo saugomi faktinė serverio?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Absoliučiai.

2433
01:47:46,823 --> 01:47:49,190
Nes Server
turėtų būti 7/24.

2434
01:47:49,190 --> 01:47:51,954
Ji turi būti prieinama
nors reaguoti į.

2435
01:47:51,954 --> 01:47:52,620
Na atspėti, ką?

2436
01:47:52,620 --> 01:47:55,410
S3 yra 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 visada reaguoja.

2438
01:47:57,100 --> 01:47:59,320
Ir S3 yra labai, labai gera
ne tarnauja iki objektus.

2439
01:47:59,320 --> 01:48:02,590
Šie objektai gali būti HTML failus, arba
JavaScript failus, arba ką nori.

2440
01:48:02,590 --> 01:48:07,430
Galite paleisti labai turtingą interneto programas
iš S3 kaušai, ir žmonės.

2441
01:48:07,430 --> 01:48:10,160
>> Ir taip tai idėja čia
yra gauti iš to, kaip toli

2442
01:48:10,160 --> 01:48:11,270
mes naudojome apie tai galvoti.

2443
01:48:11,270 --> 01:48:14,270
Mes visi naudojami galvoti
sąlygos serverių ir šeimininkai.

2444
01:48:14,270 --> 01:48:16,580
Tai ne apie tai daugiau.

2445
01:48:16,580 --> 01:48:19,310
Tai apie infrastruktūrą, kaip kodą.

2446
01:48:19,310 --> 01:48:22,470
Pasinaudokite kodą į debesis ir
tegul debesis paleisti jį už jus.

2447
01:48:22,470 --> 01:48:24,980
Ir tai, ką AWS bando daryti.

2448
01:48:24,980 --> 01:48:29,690
>> Auditorija: Taigi savo aukso lauke viduryje
API Vartai yra ne serveris-kaip,

2449
01:48:29,690 --> 01:48:30,576
bet vietoj yra just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Jūs galite galvoti
apie tai, kaip serverio fasadas.

2451
01:48:32,850 --> 01:48:38,040
Visa tai yra tai paimsiu HTTP
prašyti ir map jį į kitą procesą.

2452
01:48:38,040 --> 01:48:39,192
Štai visa tai daro.

2453
01:48:39,192 --> 01:48:41,525
Ir šiuo atveju, mes kartografavimo
jį į Lambda funkcija.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Gerai, kad viskas, ką aš turiu.

2456
01:48:45,410 --> 01:48:46,190
Labai ačiū.

2457
01:48:46,190 --> 01:48:46,800
Aš tai vertinu.

2458
01:48:46,800 --> 01:48:48,100
Aš žinau, mes norime šiek tiek per tam tikrą laiką.

2459
01:48:48,100 --> 01:48:49,980
Ir tikiuosi jus vaikinai gavo
šiek tiek informacijos

2460
01:48:49,980 --> 01:48:51,410
kad jūs galite pasiimti šiandien.

2461
01:48:51,410 --> 01:48:53,520
Ir aš atsiprašau, jei aš
per kai kurie iš jūsų galvų,

2462
01:48:53,520 --> 01:48:56,697
bet ten geras daug
pagrindinė pamatinių žinių

2463
01:48:56,697 --> 01:48:58,280
kad aš manau, yra labai vertinga už jus.

2464
01:48:58,280 --> 01:48:59,825
Taigi ačiū už tai, kad mane.

2465
01:48:59,825 --> 01:49:00,325
[Plojimai]

2466
01:49:00,325 --> 01:49:02,619
Auditorija: [nesigirdi]
yra, kai jums buvo sakydamas

2467
01:49:02,619 --> 01:49:05,160
Jums teko eiti per dalykas
nuo pradžios iki pabaigos

2468
01:49:05,160 --> 01:49:07,619
gauti teisingas vertybes
arba tie patys dydžiai,

2469
01:49:07,619 --> 01:49:09,410
Kaip vertybės
jei [nesigirdi] keistis.

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oi, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Kaip vertybės pakeisti?

2472
01:49:11,800 --> 01:49:15,180
Na, nes jei aš ne paleisti
visa tai būdas iki galo,

2473
01:49:15,180 --> 01:49:19,770
tada aš nežinau, ką keičia
buvo padaryta paskutinės mylios.

2474
01:49:19,770 --> 01:49:22,144
Jis nesiruošia būti
patys duomenys, kaip tai, ką aš pamačiau.

2475
01:49:22,144 --> 01:49:24,560
AUDITORIJA: O, todėl jūs tiesiog
ne Dotarłeś visą įvestį.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Teisė.

2477
01:49:24,770 --> 01:49:26,895
Jūs turite eiti nuo pradžios
iki pabaigos, ir tada jis

2478
01:49:26,895 --> 01:49:29,280
bus nuosekliai valstybė.

2479
01:49:29,280 --> 01:49:31,520
Saunus.

2480
01:49:31,520 --> 01:49:35,907
>> Auditorija: Taigi jūs mums parodė DynamoDB
gali padaryti dokumentą arba rakto.

2481
01:49:35,907 --> 01:49:38,740
Ir mes praleido daug laiko ant
rakto su maišos ir būdų

2482
01:49:38,740 --> 01:49:40,005
apversti jį aplink.

2483
01:49:40,005 --> 01:49:43,255
Kai pažvelgė tose lentelėse, yra tai, kad
paliekant dokumento požiūrį?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: aš ne
sako paliekant nuošalyje.

2485
01:49:44,600 --> 01:49:45,855
>> Auditorija: Jie buvo atskirti nuo the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Su dokumento
požiūris, dokumentas tipas DynamoDB

2487
01:49:49,140 --> 01:49:50,880
tiesiog manau, kaip ir kitas atributas.

2488
01:49:50,880 --> 01:49:53,560
Tai požymis, kad yra
hierarchinė duomenų struktūra.

2489
01:49:53,560 --> 01:49:56,980
Ir tada į užklausas,
galite naudoti savybes

2490
01:49:56,980 --> 01:49:59,480
iš tų objektų, naudojant Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Taigi aš galiu filtruoti lizdinė
nuosavybė JSON dokumentą.

2492
01:50:03,562 --> 01:50:05,520
Auditorija: Taigi bet kuriuo metu aš
padaryti dokumento požiūrį,

2493
01:50:05,520 --> 01:50:07,906
Galiu rūšiuoti atvykti į tabular--

2494
01:50:07,906 --> 01:50:08,780
Auditorija: Absoliučiai.

2495
01:50:08,780 --> 01:50:09,800
Auditorija: --indexes ir
dalykų, kuriuos tiesiog kalbama.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Taip,
indeksai ir visa tai,

2497
01:50:11,280 --> 01:50:13,363
kai norite indeksuoti
savybės JSON,

2498
01:50:13,363 --> 01:50:18,230
būdas, kad mes norime daryti, kad yra, jei
įdedate JSON ar dokumentą

2499
01:50:18,230 --> 01:50:20,780
į Dynamo, turėtumėte naudoti srautus.

2500
01:50:20,780 --> 01:50:22,400
Srautai būtų perskaityti įvestį.

2501
01:50:22,400 --> 01:50:24,340
Norite gauti, kad JSON
objektas ir norite pasakyti Gerai,

2502
01:50:24,340 --> 01:50:26,030
kas yra nuosavybė Aš noriu indeksas?

2503
01:50:26,030 --> 01:50:28,717
>> Jūs sukuriate išvestinį lentelę.

2504
01:50:28,717 --> 01:50:30,300
Dabar tai, kaip ji veikia dabar.

2505
01:50:30,300 --> 01:50:32,650
Mes neleidžiame jums indeksą
tiesiogiai tos savybės.

2506
01:50:32,650 --> 01:50:33,520
>> Auditorija: Tabularizing savo dokumentus.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Būtent, plokštesnės
IT, tabularizing jį tiksliai.

2508
01:50:36,230 --> 01:50:37,415
Štai ką jūs darote su juo.

2509
01:50:37,415 --> 01:50:37,860
>> Auditorija: Ačiū.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Yep,
absoliučiai, ačiū.

2511
01:50:39,609 --> 01:50:42,240
Auditorija: Taigi tai tipo
Mongo atitinka REDIS classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Taip,
tai patinka, kad daug.

2513
01:50:43,990 --> 01:50:45,940
Tai geras aprašymas už jį.

2514
01:50:45,940 --> 01:50:47,490
Saunus.

2515
01:50:47,490 --> 01:50:49,102