1
00:00:00,000 --> 00:00:04,969
>> [TÓNLIST spila]

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: Allt í lagi.

3
00:00:06,010 --> 00:00:06,600
Hæ allir.

4
00:00:06,600 --> 00:00:07,670
Mitt nafn er Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Ég er eldri skólastjóri
lausnir arkitekt á AWS.

6
00:00:10,330 --> 00:00:14,070
Ég leggja áherslu á NoSQL og
DynamoDB tækni.

7
00:00:14,070 --> 00:00:16,930
Ég er hér í dag til að tala við
þú svolítið um þá.

8
00:00:16,930 --> 00:00:18,970
>> Bakgrunnur minn er
fyrst og fremst í gögnum lag.

9
00:00:18,970 --> 00:00:21,390
Ég eyddi hálfri þróun mína
Ferill skrifa gagnagrunn,

10
00:00:21,390 --> 00:00:25,930
gögn aðgangur, lausnir
fyrir ýmsum forritum.

11
00:00:25,930 --> 00:00:30,000
Ég hef verið í Cloud virtualization
fyrir um 20 árum.

12
00:00:30,000 --> 00:00:33,460
Svo áður en Cloud var Cloud,
við notuðum til að kalla það gagnsemi computing.

13
00:00:33,460 --> 00:00:37,170
Og hugmyndin var, það er eins og
PG & E, greiðir þú fyrir það sem þú notar.

14
00:00:37,170 --> 00:00:38,800
Í dag við köllum það skýið.

15
00:00:38,800 --> 00:00:41,239
>> En í gegnum árin hef ég unnið
fyrir a par af fyrirtækjum

16
00:00:41,239 --> 00:00:42,530
þú hefur sennilega aldrei heyrt um.

17
00:00:42,530 --> 00:00:47,470
En ég hef tekið saman lista yfir tæknilega
Afrekum, held ég að þú myndir segja.

18
00:00:47,470 --> 00:00:51,620
Ég hef átta einkaleyfi í Cloud kerfi
virtualization, örgjörvi hönnun,

19
00:00:51,620 --> 00:00:54,440
flókið atburður vinnslu,
og á öðrum sviðum eins og heilbrigður.

20
00:00:54,440 --> 00:00:58,290
>> Svo þessa dagana, einbeita ég aðallega á NoSQL
tækni og næsta kynslóð

21
00:00:58,290 --> 00:00:59,450
gagnagrunnur.

22
00:00:59,450 --> 00:01:03,370
Og það er yfirleitt það sem ég ætla
að vera hér að tala við þig í dag um.

23
00:01:03,370 --> 00:01:06,030
Svo það sem þú getur búist við
frá þessum fundi,

24
00:01:06,030 --> 00:01:08,254
við munum fara í gegnum stutta
Saga gagnavinnslu.

25
00:01:08,254 --> 00:01:10,420
Það er alltaf gagnlegt að
skilja hvaðan við komum

26
00:01:10,420 --> 00:01:12,400
og hvers vegna við erum þar sem við erum.

27
00:01:12,400 --> 00:01:15,600
Og við munum tala svolítið
hluti um NoSQL tækni

28
00:01:15,600 --> 00:01:17,500
frá grundvallar sjónarmiði.

29
00:01:17,500 --> 00:01:19,870
>> Við munum fá inn í sumir af
að DynamoDB innri.

30
00:01:19,870 --> 00:01:24,350
DynamoDB er ekkert bragð AWS er.

31
00:01:24,350 --> 00:01:27,340
Það er fullkomlega tekist og
hýst NoSQL lausn.

32
00:01:27,340 --> 00:01:32,420
Og við munum tala svolítið um borð
uppbyggingu, API, gögn tegundir, vísitölur,

33
00:01:32,420 --> 00:01:35,177
og sumir af the innri
þeirrar DynamoDB tækni.

34
00:01:35,177 --> 00:01:37,760
Við munum fá inn í sumir af the hönnun
mynstur og bestu starfsvenjur.

35
00:01:37,760 --> 00:01:39,968
Við munum tala um hvernig þú
nota þessa tækni fyrir nokkrum

36
00:01:39,968 --> 00:01:41,430
umsókna dag.

37
00:01:41,430 --> 00:01:44,820
Og þá munum við tala svolítið
um þróun eða tilkomu

38
00:01:44,820 --> 00:01:48,980
af nýrri hugmyndafræði í forritun
kallast atburður-ekin forrit

39
00:01:48,980 --> 00:01:51,580
og hvernig DynamoDB spilar í það eins vel.

40
00:01:51,580 --> 00:01:54,690
Og við munum láta þér smá
tilvísun arkitektúr umræða

41
00:01:54,690 --> 00:01:59,540
svo við getum talað um tiltekin
leiðir sem þú getur notað DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Svo fyrst off-- þetta er spurning
Ég heyri mikið er, hvað er gagnagrunnur.

43
00:02:04,116 --> 00:02:06,240
A einhver fjöldi af fólk hugsa þeir
vita hvað gagnagrunnurinn er.

44
00:02:06,240 --> 00:02:08,360
Ef þú Google, munt þú sjá þetta.

45
00:02:08,360 --> 00:02:11,675
Það er a skipulögð sett af gögnum haldið
í tölvu, sérstaklega einn sem

46
00:02:11,675 --> 00:02:13,600
er aðgengileg á ýmsa vegu.

47
00:02:13,600 --> 00:02:16,992
Ég geri ráð fyrir það er gott
Skilgreining á nútíma gagnagrunninum.

48
00:02:16,992 --> 00:02:19,450
En ég er ekki eins og það, vegna þess að
það felur í sér nokkra hluti.

49
00:02:19,450 --> 00:02:20,935
Það felur í sér uppbyggingu.

50
00:02:20,935 --> 00:02:23,120
Og það felur í sér að það er á tölvunni.

51
00:02:23,120 --> 00:02:25,750
Og gagnagrunna ekki
alltaf vera til á tölvum.

52
00:02:25,750 --> 00:02:28,020
Gagnagrunnar í raun verið á margan hátt.

53
00:02:28,020 --> 00:02:32,000
>> Svo betri skilgreining á a
Gagnagrunnurinn er eitthvað eins og þetta.

54
00:02:32,000 --> 00:02:34,786
A gagnagrunnur er skipulögð
vélbúnaður til að geyma, stjórna,

55
00:02:34,786 --> 00:02:35,910
og sækja upplýsingar.

56
00:02:35,910 --> 00:02:36,868
Þetta er frá About.com.

57
00:02:36,868 --> 00:02:42,080
Svo ég svona vegna þess að það er í raun viðræður
um gagnagrunn vera geymsla,

58
00:02:42,080 --> 00:02:44,800
geymsla
upplýsingar, ekki endilega

59
00:02:44,800 --> 00:02:46,780
eitthvað sem situr á tölvunni.

60
00:02:46,780 --> 00:02:49,290
Og í gegnum söguna, við
hafa ekki alltaf haft tölvur.

61
00:02:49,290 --> 00:02:52,110
>> Nú, ef ég spyrja meðaltali
verktaki í dag hvað er

62
00:02:52,110 --> 00:02:54,770
gagnagrunnur, það er svarið sem ég fá.

63
00:02:54,770 --> 00:02:56,070
Einhvers staðar ég get standa efni.

64
00:02:56,070 --> 00:02:56,670
Ekki satt?

65
00:02:56,670 --> 00:02:58,725
Og það er satt.

66
00:02:58,725 --> 00:02:59,600
En það er óheppilegt.

67
00:02:59,600 --> 00:03:02,700
Þar sem gagnagrunnurinn er mjög
grundvöllur nútíma app.

68
00:03:02,700 --> 00:03:04,810
Það er grunnurinn
af hverjum umsókn.

69
00:03:04,810 --> 00:03:07,240
Og hvernig þú byggja það
gagnagrunnur, hvernig þið byggið

70
00:03:07,240 --> 00:03:11,750
þessi gögn er að fara að fyrirmæli hvernig það
umsókn framkvæma eins og þú mælikvarði.

71
00:03:11,750 --> 00:03:14,640
>> Svo mikið af starfi mínu í dag
er að takast á við það sem

72
00:03:14,640 --> 00:03:17,180
gerist þegar verktaki
að taka þessa nálgun

73
00:03:17,180 --> 00:03:19,510
og takast á við eftirmála
umsóknar sem

74
00:03:19,510 --> 00:03:24,966
er nú stigstærð utan upprunalega
ásetningur og þjást af slæmur hönnun.

75
00:03:24,966 --> 00:03:26,840
Svo vonandi þegar þér
ganga í burtu í dag, munt þú

76
00:03:26,840 --> 00:03:29,010
hafa a par af verkfærum í
Beltið sem mun halda þér

77
00:03:29,010 --> 00:03:32,566
frá því að gera sömu mistök.

78
00:03:32,566 --> 00:03:33,066
Allt í lagi.

79
00:03:33,066 --> 00:03:36,360
Svo skulum við tala um smá
Tímalína á tækni gagnasafn.

80
00:03:36,360 --> 00:03:38,830
Ég held að ég las
grein ekki fyrir löngu

81
00:03:38,830 --> 00:03:43,020
og það sagði eitthvað á lines--
það er mjög ljóðræn yfirlýsingu.

82
00:03:43,020 --> 00:03:46,590
Það sagði sögu
gagna vinnsla er

83
00:03:46,590 --> 00:03:49,350
fullt af hár vatnsmerki
gagna gnægð.

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

85
00:03:49,920 --> 00:03:52,532
Nú held ég að sé eins konar satt.

86
00:03:52,532 --> 00:03:54,990
En ég lít reyndar á er eins og
Saga er í raun fyllt

87
00:03:54,990 --> 00:03:56,820
með hár vatnsmerki gagna þrýstingi.

88
00:03:56,820 --> 00:04:00,040
Vegna þess að gögn hlutfall af
inntaka fer aldrei niður.

89
00:04:00,040 --> 00:04:01,360
Það fer bara allt.

90
00:04:01,360 --> 00:04:03,670
>> Og nýsköpun á sér stað þegar
sjáum gögn þrýstingi, sem

91
00:04:03,670 --> 00:04:07,825
er því gagnamagni sem er
nú í að koma inn í kerfið.

92
00:04:07,825 --> 00:04:12,027
Og það er ekki hægt að vinna
duglegur annaðhvort í tíma eða í kostnaði.

93
00:04:12,027 --> 00:04:14,110
Og það er þegar við byrjum
að líta á gögn þrýstingi.

94
00:04:14,110 --> 00:04:15,920
>> Svo þegar við skoðum
Fyrsta gagnasafn þetta

95
00:04:15,920 --> 00:04:17,180
er sá sem var á milli eyrnanna á okkur.

96
00:04:17,180 --> 00:04:18,310
Við erum öll fædd með það.

97
00:04:18,310 --> 00:04:19,194
Það er gott gagnasafn.

98
00:04:19,194 --> 00:04:21,110
Það hefur mikið framboð.

99
00:04:21,110 --> 00:04:21,959
Það er alltaf á.

100
00:04:21,959 --> 00:04:23,930
Þú getur alltaf fengið það.

101
00:04:23,930 --> 00:04:24,890
>> En það er einn notandi.

102
00:04:24,890 --> 00:04:26,348
Ég get ekki að deila hugsunum mínum með þér.

103
00:04:26,348 --> 00:04:28,370
Þú getur ekki fá hugsanir mínar
þegar þú vilt þá.

104
00:04:28,370 --> 00:04:30,320
Og abilitiy þeirra er ekki svo gott.

105
00:04:30,320 --> 00:04:32,510
Við gleyma hlutum.

106
00:04:32,510 --> 00:04:36,540
Sérhver nú og þá, einn af okkur leyfi
og færist á annan tilvist

107
00:04:36,540 --> 00:04:39,110
og við missa allt
sem var í því gagnagrunninum.

108
00:04:39,110 --> 00:04:40,640
Svo er það ekki allt sem gott.

109
00:04:40,640 --> 00:04:43,189
>> Og þetta virkaði vel með tímanum
þegar við vorum aftur í dag

110
00:04:43,189 --> 00:04:46,230
þegar allt við þurftum virkilega að vita er
þar erum við að fara að fara á morgun

111
00:04:46,230 --> 00:04:49,630
eða þar sem við safna bestu mat.

112
00:04:49,630 --> 00:04:52,820
En eins og við byrjuðum að vaxa eins og a
menningu og ríkisstjórnin byrjaði

113
00:04:52,820 --> 00:04:55,152
að koma inn að vera, og
fyrirtæki byrjuðu að þróast,

114
00:04:55,152 --> 00:04:57,360
við byrjuðum að við gerum við
þurfa aðeins meira en það sem

115
00:04:57,360 --> 00:04:58,210
við gætum sett í höfði okkar.

116
00:04:58,210 --> 00:04:58,870
Allt í lagi?

117
00:04:58,870 --> 00:05:00,410
>> Við þurftum kerfi skrá.

118
00:05:00,410 --> 00:05:02,220
Við þurftum staði til að vera fær gögn geyma.

119
00:05:02,220 --> 00:05:05,450
Svo við byrjuðum að skrifa skjöl,
búa bóka- og skjalasafna.

120
00:05:05,450 --> 00:05:08,000
Við byrjuðum að þróa
kerfi a höfuðbók bókhald.

121
00:05:08,000 --> 00:05:12,200
Og það kerfi höfuðbók telja
hljóp heim fyrir mörgum öldum,

122
00:05:12,200 --> 00:05:15,580
og kannski jafnvel árþúsundir og
við ólumst konar að benda

123
00:05:15,580 --> 00:05:18,420
þar sem gögn hlaða bera
getu þessara kerfa

124
00:05:18,420 --> 00:05:19,870
að vera fær um að innihalda það.

125
00:05:19,870 --> 00:05:22,070
>> Og þetta raunverulega gerðist í 1880s.

126
00:05:22,070 --> 00:05:22,570
Ekki satt?

127
00:05:22,570 --> 00:05:24,390
Í 1880 US Census.

128
00:05:24,390 --> 00:05:26,976
Þetta er í raun þar sem beygja
benda nútíma gagnavinnslu.

129
00:05:26,976 --> 00:05:28,850
Þetta er punkturinn þar
sem magn gagna

130
00:05:28,850 --> 00:05:32,060
sem var verið innheimt af
US ríkisstjórnin fékk til að benda

131
00:05:32,060 --> 00:05:34,005
þar sem það tók átta ár að vinna úr.

132
00:05:34,005 --> 00:05:36,350
>> Nú, átta years-- sem
þú veist, manntal

133
00:05:36,350 --> 00:05:39,180
keyrir á 10 years-- svo það er
nokkuð augljóst að með tímanum við

134
00:05:39,180 --> 00:05:41,419
fékk 1890 manntal,
magn af gögnum sem

135
00:05:41,419 --> 00:05:43,210
var að fara til að vinna
af stjórnvöldum var

136
00:05:43,210 --> 00:05:46,335
að fara að vera hærri en 10 ár sem það
myndi taka að stokkunum nýju manntal.

137
00:05:46,335 --> 00:05:47,250
Þetta var vandamál.

138
00:05:47,250 --> 00:05:49,000
>> Svo strákur sem heitir Herman
Hollerith kom með

139
00:05:49,000 --> 00:05:52,640
og hann fann eining met bolla
spil, kýla lesandi, kýla kort

140
00:05:52,640 --> 00:05:58,420
tabulator og samanburði á
Fyrirkomulag þessa tækni.

141
00:05:58,420 --> 00:06:01,860
Og að fyrirtæki sem hann myndast á
tími, ásamt nokkrum öðrum,

142
00:06:01,860 --> 00:06:05,450
raun varð einn af grunnstoðum a
lítil fyrirtæki við þekkjum í dag sem heitir IBM.

143
00:06:05,450 --> 00:06:08,417
>> Svo IBM var upphaflega í
gagnagrunnurinn fyrirtæki.

144
00:06:08,417 --> 00:06:09,750
Og það er í raun það sem þeir gerðu.

145
00:06:09,750 --> 00:06:11,110
Þeir gerðu gagnavinnslu.

146
00:06:11,110 --> 00:06:15,400
>> Eins og svo útbreiðslu kýla
spil, snjallt kerfi

147
00:06:15,400 --> 00:06:18,560
af því að vera fær um að nýta sem
tækni að kosning flokkuð útkoma setur.

148
00:06:18,560 --> 00:06:20,726
Þú getur séð á þessari mynd
þar sem við höfum little--

149
00:06:20,726 --> 00:06:23,970
það er lítið small-- en þú getur séð
mjög snjallt vélrænni kerfi

150
00:06:23,970 --> 00:06:26,970
þar sem við höfum kýla kort þilfari.

151
00:06:26,970 --> 00:06:28,720
Og taka einhver er
smá skrúfjárn

152
00:06:28,720 --> 00:06:31,400
og stafur í gegnum
rifa og lyfta henni upp

153
00:06:31,400 --> 00:06:34,820
að fá að passa, sem
flokkuð niðurstöður sett.

154
00:06:34,820 --> 00:06:36,270
>> Þetta er samansafn.

155
00:06:36,270 --> 00:06:38,690
Við gerum þetta allan tímann
í dag í tölvunni,

156
00:06:38,690 --> 00:06:40,100
þar sem þú gerir það í dag.

157
00:06:40,100 --> 00:06:41,620
Við notuðum til að gera það handvirkt, ekki satt?

158
00:06:41,620 --> 00:06:42,994
Fólk setti þetta saman.

159
00:06:42,994 --> 00:06:45,440
Og það var útbreiðsla
þessara gatakortum

160
00:06:45,440 --> 00:06:50,070
í það sem við kölluð gögn trommur
og gögn hjóla, pappír borði.

161
00:06:50,070 --> 00:06:55,980
>> The gagnavinnslu iðnaður tók
lexía frá the leikmaður píanó.

162
00:06:55,980 --> 00:06:57,855
Player Pianos aftur á
að aldamótin

163
00:06:57,855 --> 00:07:02,100
er notað til að nota pappír hjóla með afgreiðslutíma
á að segja það sem takkana til að spila.

164
00:07:02,100 --> 00:07:05,380
Þannig að tæknin var aðlöguð
loksins að geyma stafræn gögn,

165
00:07:05,380 --> 00:07:08,070
vegna þess að þeir gætu sett þessi gögn
á þeim pappír borði hjóla.

166
00:07:08,070 --> 00:07:10,870
>> Nú, eins og a afleiðing, gögn
var actually-- hvernig

167
00:07:10,870 --> 00:07:14,960
þér aðgang að þessum gögnum var beint
háð því hvernig þú geyma það.

168
00:07:14,960 --> 00:07:17,825
Þannig að ef ég setti gögn á borði,
Ég hafði aðgang að gögnum línulega.

169
00:07:17,825 --> 00:07:20,475
Ég þurfti að rúlla allri
borði til að fá aðgang að öllum gögnum.

170
00:07:20,475 --> 00:07:22,600
Ef ég setti gögnin í bolla
spil, gæti ég nálgast það

171
00:07:22,600 --> 00:07:26,270
í aðeins meira handahófi
tíska, kannski ekki eins fljótt.

172
00:07:26,270 --> 00:07:30,770
>> En það voru takmarkanir á því hvernig við
aðgang að gögnum á grundvelli hvernig var geymt.

173
00:07:30,770 --> 00:07:32,890
Og svo þetta var vandamál
að fara í '50s.

174
00:07:32,890 --> 00:07:37,890
Aftur getum við byrjað að sjá að eins og við
þróa nýja tækni til að vinna

175
00:07:37,890 --> 00:07:41,670
gögn, hægri, opnast það upp
dyrnar að nýjum lausnum,

176
00:07:41,670 --> 00:07:45,852
fyrir nýjum verkefnum, nýjum
umsóknir um þessi gögn.

177
00:07:45,852 --> 00:07:47,810
Og í raun, stjórnun
kann að hafa verið ástæðan

178
00:07:47,810 --> 00:07:49,435
hvers vegna við þróað sumir af þessum kerfum.

179
00:07:49,435 --> 00:07:52,290
En fyrirtækið hratt varð
ökumaður á bak við þróun

180
00:07:52,290 --> 00:07:54,720
nútíma gagnagrunn og
nútíma skráarkerfi.

181
00:07:54,720 --> 00:07:56,870
>> Svo the næstur hlutur sem
kom upp var í '50s

182
00:07:56,870 --> 00:08:00,780
var skrá kerfi og
þróun handahófi aðgangur geymslu.

183
00:08:00,780 --> 00:08:02,050
Þetta var falleg.

184
00:08:02,050 --> 00:08:06,230
Nú, allt í einu, við getum sett okkar
skrár hvar sem er á þessum harða diska

185
00:08:06,230 --> 00:08:09,760
og við getum nálgast þessi gögn af handahófi.

186
00:08:09,760 --> 00:08:11,950
Við getum flokka sem
upplýsingar úr skrám.

187
00:08:11,950 --> 00:08:14,920
Og við leyst öll heimsins
vandamál með gagnavinnslu.

188
00:08:14,920 --> 00:08:17,550
>> Og það stóð um 20 eða
30 ára þar til þróun

189
00:08:17,550 --> 00:08:22,100
af Venslagagnagrunnur, sem
er þegar heimurinn ákváðum við nú

190
00:08:22,100 --> 00:08:27,940
þurfa að hafa geymsla sem tekst
sem borganna gagna yfir skrá

191
00:08:27,940 --> 00:08:29,540
kerfi sem við höfum byggt. Ekki satt?

192
00:08:29,540 --> 00:08:34,270
Of mikið af gögnum sem dreift er of margir
stöðum, de-fjölföldun gagna,

193
00:08:34,270 --> 00:08:37,120
og kostnaður við geymslu var gríðarlegur.

194
00:08:37,120 --> 00:08:43,760
>> Í '70s, dýrasta auðlind
sem tölvan hafði var geymsla.

195
00:08:43,760 --> 00:08:46,200
The gjörvi var
litið á sem föstum kostnaði.

196
00:08:46,200 --> 00:08:49,030
Þegar ég kaupa kassa,
CPU er sumir vinna.

197
00:08:49,030 --> 00:08:51,960
Það er að fara að snúast um hvort
það er í raun að vinna eða ekki.

198
00:08:51,960 --> 00:08:53,350
Það er í raun sökkt kostnaður.

199
00:08:53,350 --> 00:08:56,030
>> En hvað kosta mig sem
fyrirtæki er geymsla.

200
00:08:56,030 --> 00:09:00,020
Ef ég þarf að kaupa fleiri diska næsta
mánuði, sem er raunverulegur kostnaður sem ég borga.

201
00:09:00,020 --> 00:09:01,620
Og að geymsla er dýrt.

202
00:09:01,620 --> 00:09:05,020
>> Nú erum við hratt áfram 40 ár
og við höfum mismunandi vandamál.

203
00:09:05,020 --> 00:09:10,020
The reikna er nú
Dýrasta auðlind.

204
00:09:10,020 --> 00:09:11,470
Geymsla er ódýr.

205
00:09:11,470 --> 00:09:14,570
Ég meina, við getum farið hvert sem er á
ský og við getum fundið ódýr geymslu.

206
00:09:14,570 --> 00:09:17,190
En það sem ég get ekki fundið er ódýr reikna.

207
00:09:17,190 --> 00:09:20,700
>> Svo þróun í dag er
tækni, gagnasafn tækni,

208
00:09:20,700 --> 00:09:23,050
er í raun snýst um
Úthluta Gagnasafn

209
00:09:23,050 --> 00:09:26,960
sem ekki þjást af
samskonar mælikvarða

210
00:09:26,960 --> 00:09:29,240
takmarkanir Vensla gagnagrunna.

211
00:09:29,240 --> 00:09:32,080
Við munum tala svolítið um
hvað það þýðir í raun.

212
00:09:32,080 --> 00:09:34,760
>> En ein af ástæðunum og
ökumaður á bak this-- vér

213
00:09:34,760 --> 00:09:38,290
talaði um gögn þrýstingi.

214
00:09:38,290 --> 00:09:41,920
Gögn þrýstingur er eitthvað
sem rekur nýsköpun.

215
00:09:41,920 --> 00:09:44,610
Og ef þú horfir á yfir
á síðustu fimm árum,

216
00:09:44,610 --> 00:09:48,180
þetta er graf af hvaða gögnum
hlaða yfir almenna framtak

217
00:09:48,180 --> 00:09:49,640
lítur út eins og á síðustu fimm árum.

218
00:09:49,640 --> 00:09:52,570
>> Og Almenna þumalputtaregla
þessi days-- ef þú ferð Google--

219
00:09:52,570 --> 00:09:55,290
er 90% af gögnum sem
geymum í dag, og það var

220
00:09:55,290 --> 00:09:57,330
mynda á síðustu tveimur árum.

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

222
00:09:57,911 --> 00:09:59,410
Nú, þetta er ekki stefna sem er nýtt.

223
00:09:59,410 --> 00:10:01,230
Þetta er stefna sem hefur verið
fara út fyrir 100 árum.

224
00:10:01,230 --> 00:10:03,438
Allt frá því að Herman Hollerith
þróað kýla kort,

225
00:10:03,438 --> 00:10:08,040
við höfum verið að byggja upp gögn geymsla
og safna gögnum á stórkostlegum afslætti.

226
00:10:08,040 --> 00:10:10,570
>> Svo á síðustu 100 árum,
við höfum séð þessa þróun.

227
00:10:10,570 --> 00:10:11,940
Það er ekki að fara að breytast.

228
00:10:11,940 --> 00:10:14,789
Fara fram, við erum að fara að sjá
þetta, ef ekki að flýta þróun.

229
00:10:14,789 --> 00:10:16,330
Og þú getur séð hvað það lítur út.

230
00:10:16,330 --> 00:10:23,510
>> Ef fyrirtæki árið 2010 hafði einn
terabæti af gögnum í stýringu,

231
00:10:23,510 --> 00:10:27,080
í dag sem þýðir að þeir eru
stjórna 6,5 ​​petabytes gagna.

232
00:10:27,080 --> 00:10:30,380
Það er 6.500 sinnum fleiri gögn.

233
00:10:30,380 --> 00:10:31,200
Og ég veit þetta.

234
00:10:31,200 --> 00:10:33,292
Ég vinn með þessum fyrirtækjum á hverjum degi.

235
00:10:33,292 --> 00:10:35,000
Fimm árum síðan, ég
myndi tala við fyrirtæki

236
00:10:35,000 --> 00:10:38,260
hver myndi tala við mig um hvað sársauki
það er að stjórna terabytes gagna.

237
00:10:38,260 --> 00:10:39,700
Og þeir myndu tala
við mig um hvernig við sjáum

238
00:10:39,700 --> 00:10:41,825
að þetta er líklega að fara
til að vera petabyte eða tveir

239
00:10:41,825 --> 00:10:43,030
innan fárra ára.

240
00:10:43,030 --> 00:10:45,170
>> Þessi sömu fyrirtæki
í dag ætla ég að hitta,

241
00:10:45,170 --> 00:10:48,100
og þeir eru að tala við mig um
Vandamálið er það að hafa stjórna

242
00:10:48,100 --> 00:10:51,440
tugir, 20 petabytes gagna.

243
00:10:51,440 --> 00:10:53,590
Svo sprengingu af
gögn í greininni

244
00:10:53,590 --> 00:10:56,670
er að aka gífurleg
þörf fyrir betri lausnir.

245
00:10:56,670 --> 00:11:00,980
Og Venslagagnagrunnur er
bara ekki lifandi upp til eftirspurn.

246
00:11:00,980 --> 00:11:03,490
>> Og svo er það línulegt
fylgni milli gögnum þrýstingi

247
00:11:03,490 --> 00:11:05,210
og tæknilega nýsköpun.

248
00:11:05,210 --> 00:11:07,780
Sagan hefur sýnt okkur
þetta, að með tímanum,

249
00:11:07,780 --> 00:11:11,090
Í hvert skipti sem magn gagna
sem þarf til að vinna

250
00:11:11,090 --> 00:11:15,490
meiri en afkastagetu þess
að vinna það innan hæfilegs tíma

251
00:11:15,490 --> 00:11:18,870
eða á sanngjörnu verði,
þá ný tækni

252
00:11:18,870 --> 00:11:21,080
eru fundin til að leysa þau vandamál.

253
00:11:21,080 --> 00:11:24,090
Þeir ný tækni,
aftur á móti, opna hurðina

254
00:11:24,090 --> 00:11:27,840
að annað sett af vandamálum, sem
er að safna saman jafnvel fleiri gögn.

255
00:11:27,840 --> 00:11:29,520
>> Nú erum við ekki að fara að hætta þessu.

256
00:11:29,520 --> 00:11:30,020
Ekki satt?

257
00:11:30,020 --> 00:11:31,228
Við erum ekki að fara að hætta þessu.

258
00:11:31,228 --> 00:11:31,830
Hvers vegna?

259
00:11:31,830 --> 00:11:35,520
Þar sem þú getur ekki vita allt
það er að vita í alheiminum.

260
00:11:35,520 --> 00:11:40,510
Og svo lengi sem við höfum verið á lífi,
um sögu mannsins,

261
00:11:40,510 --> 00:11:43,440
við höfum alltaf ekið að vita meira.

262
00:11:43,440 --> 00:11:49,840
>> Svo það virðist eins og hvert tomma við flytja
niður leið vísindalegum uppgötvun,

263
00:11:49,840 --> 00:11:54,620
við erum að margfalda magn gagna
að við þurfum að vinna veldishraða

264
00:11:54,620 --> 00:11:59,920
eins og við afhjúpa meira og meira og meira
um innri starfsemi lífsins,

265
00:11:59,920 --> 00:12:04,530
um hvernig alheimurinn virkar, um
akstur vísindalegar uppgötvun,

266
00:12:04,530 --> 00:12:06,440
og uppfinningin, sem
við erum að gera í dag.

267
00:12:06,440 --> 00:12:09,570
Það gagnamagn bara
stöðugt eykst.

268
00:12:09,570 --> 00:12:12,120
Svo að vera fær um að takast á við
þetta vandamál er gríðarlegur.

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

270
00:12:14,790 --> 00:12:17,410
>> Svo einn af þeim hlutum
við lítum eins hverju NoSQL?

271
00:12:17,410 --> 00:12:19,200
Hvernig virkar NoSQL leysa þetta vandamál?

272
00:12:19,200 --> 00:12:24,980
Jæja, Vensla gagnagrunna,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- það er í raun hugsmíð af
Vensla database-- þetta eru

274
00:12:28,600 --> 00:12:30,770
bjartsýni fyrir geymslu.

275
00:12:30,770 --> 00:12:33,180
>> Aftur í '70s, aftur,
diskur er dýr.

276
00:12:33,180 --> 00:12:36,990
The úthlutun æfing geymslu
í fyrirtækinu er aldrei-endir.

277
00:12:36,990 --> 00:12:37,490
Ég veit.

278
00:12:37,490 --> 00:12:38,020
Ég bjó hana.

279
00:12:38,020 --> 00:12:41,250
Ég skrifaði geymslu ökumenn fyrir að
enterprised superserver fyrirtæki

280
00:12:41,250 --> 00:12:42,470
aftur í '90s.

281
00:12:42,470 --> 00:12:45,920
Og botn lína er rekki annar
geymsla fylking var bara eitthvað sem

282
00:12:45,920 --> 00:12:47,600
gerðist á hverjum degi í fyrirtækinu.

283
00:12:47,600 --> 00:12:49,030
Og það stoppaði aldrei.

284
00:12:49,030 --> 00:12:52,690
Meiri þéttleika geymslu, eftirspurn
fyrir hár þéttleiki geymslu,

285
00:12:52,690 --> 00:12:56,340
og skilvirkari geymslu
devices-- það er aldrei hætt.

286
00:12:56,340 --> 00:13:00,160
>> Og NoSQL er frábær tækni
því það normalizes gögn.

287
00:13:00,160 --> 00:13:02,210
Það de-afrit gagna.

288
00:13:02,210 --> 00:13:07,180
Það setur gögnin í uppbyggingu sem
er efasemdarmaður öllum aðgang mynstur.

289
00:13:07,180 --> 00:13:11,600
Mörg forrit geta högg að
SQL gagnagrunn, hlaupa tilfallandi fyrirspurnir,

290
00:13:11,600 --> 00:13:15,950
og fá gögn í laginu sem þeir
þurfa að vinna fyrir vinnuálag þeirra.

291
00:13:15,950 --> 00:13:17,570
Það hljómar frábærlega.

292
00:13:17,570 --> 00:13:21,350
En botn lína er með eitthvað
kerfi, ef það er efasemdarmaður að öllu,

293
00:13:21,350 --> 00:13:23,500
það er bjartsýni fyrir ekki neitt.

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

295
00:13:24,050 --> 00:13:26,386
>> Og það er það sem við fáum með
sem Venslagagnagrunnur.

296
00:13:26,386 --> 00:13:27,510
Það er bjartsýni fyrir geymslu.

297
00:13:27,510 --> 00:13:28,280
Það er eðlileg.

298
00:13:28,280 --> 00:13:29,370
Það er Vensla.

299
00:13:29,370 --> 00:13:31,660
Það styður tilfallandi fyrirspurnir.

300
00:13:31,660 --> 00:13:34,000
Og það og það vog lóðrétt.

301
00:13:34,000 --> 00:13:39,030
>> Ef ég þarf að fá stærri SQL gagnagrunn
eða öflugri SQL gagnagrunn,

302
00:13:39,030 --> 00:13:41,090
Ég fara kaupa stærri stykki af járni.

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

304
00:13:41,600 --> 00:13:44,940
Ég hef unnið með fullt af viðskiptavinum
sem hafa verið í gegnum helstu uppfærslu

305
00:13:44,940 --> 00:13:48,340
í SQL innviði þeirra aðeins
til að finna út sex mánuðum síðar,

306
00:13:48,340 --> 00:13:49,750
þeir fara á vegginn aftur.

307
00:13:49,750 --> 00:13:55,457
Og svarið frá Oracle eða MSSQL
eða einhver annar er að fá stærri kassa.

308
00:13:55,457 --> 00:13:58,540
Jæja fyrr eða síðar, þú getur ekki keypt a
stærri kassi, og það er raunverulegt vandamál.

309
00:13:58,540 --> 00:14:00,080
Þurfum við að breyta hlutum.

310
00:14:00,080 --> 00:14:01,080
Svo hvar er þetta?

311
00:14:01,080 --> 00:14:06,560
Það virkar vel fyrir offline
greinandi OLAP-gerð vinnuálag.

312
00:14:06,560 --> 00:14:08,670
Og það er í raun þar sem SQL tilheyrir.

313
00:14:08,670 --> 00:14:12,540
Nú, það er notað í dag í mörgum netinu
viðskiptalegs vinnslu-gerð

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

315
00:14:13,330 --> 00:14:16,460
Og það virkar bara fínt í
sumir láréttur flötur af nýtingu,

316
00:14:16,460 --> 00:14:18,670
en það bara virkar ekki mælikvarði
á þann hátt að NoSQL gerir.

317
00:14:18,670 --> 00:14:20,660
Og við munum tala svolítið
hluti um hvers vegna það er.

318
00:14:20,660 --> 00:14:23,590
>> Nú, NoSQL, á hinn bóginn,
er meira bjartsýni fyrir óendanlegur.

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

320
00:14:24,540 --> 00:14:26,830
Það er ekki efasemdarmaður að
aðgangur mynstur.

321
00:14:26,830 --> 00:14:31,620
Er það sem við köllum de-eðlileg
uppbygging eða valdakerfi.

322
00:14:31,620 --> 00:14:35,000
Gögnin í Venslagagnagrunnur er
byrjuðu að dansa frá mörgum borðum

323
00:14:35,000 --> 00:14:36,850
til að framleiða þá skoðun sem þú þarft.

324
00:14:36,850 --> 00:14:40,090
Gögnin í NoSQL gagnagrunni
er geymt í skjali sem

325
00:14:40,090 --> 00:14:42,100
inniheldur valdakerfi.

326
00:14:42,100 --> 00:14:45,670
Öll gögn sem myndi venjulega vera
sameinaðir til að framleiða þessi sýn

327
00:14:45,670 --> 00:14:47,160
er geymt í einu skjali.

328
00:14:47,160 --> 00:14:50,990
Og við munum tala svolítið um
hvernig það virkar í nokkra töflur.

329
00:14:50,990 --> 00:14:55,320
>> En hugmyndin hér er að þú geymir
gögn sem þessi smíða útsýni.

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

331
00:14:56,410 --> 00:14:58,610
Þú mælikvarði lárétt.

332
00:14:58,610 --> 00:14:59,556
Ekki satt?

333
00:14:59,556 --> 00:15:02,100
Ef ég þarf að auka
Stærð NoSQL þyrping minn,

334
00:15:02,100 --> 00:15:03,700
Ég þarf ekki að fá stærri kassa.

335
00:15:03,700 --> 00:15:05,200
Ég fæ annað box.

336
00:15:05,200 --> 00:15:07,700
Og ég þyrping þeim saman,
og ég get Shard þessi gögn.

337
00:15:07,700 --> 00:15:10,780
Við munum tala svolítið um
hvað sharding er, að vera

338
00:15:10,780 --> 00:15:14,270
fær til mælikvarði sem gagnagrunn
á mörgum líkamlegt tæki

339
00:15:14,270 --> 00:15:18,370
og fjarlægja hindrun sem
krefst mig til að skala lóðrétt.

340
00:15:18,370 --> 00:15:22,080
>> Svo það er í raun byggt á netinu
viðskipti vinnslu og umfang.

341
00:15:22,080 --> 00:15:25,480
Það er stór munur
hér á milli skýrslugerð, ekki satt?

342
00:15:25,480 --> 00:15:27,810
Skýrslur, ég veit ekki
spurningar sem ég ætla að spyrja.

343
00:15:27,810 --> 00:15:28,310
Ekki satt?

344
00:15:28,310 --> 00:15:30,570
Reporting-- ef einhver frá
markaðssetning deild minn

345
00:15:30,570 --> 00:15:34,520
vill just-- hversu margir af mínum viðskiptavinum
hafa þessa tilteknu eiginleika sem

346
00:15:34,520 --> 00:15:37,850
keypti á þessum day-- ég veit ekki
hvað fyrirspurn hann ætlar að biðja.

347
00:15:37,850 --> 00:15:39,160
Þannig að ég þarf að vera efahyggjumaður.

348
00:15:39,160 --> 00:15:41,810
>> Nú, í netinu
viðskiptalegs umsókn,

349
00:15:41,810 --> 00:15:43,820
Ég veit hvaða spurningar ég er að spyrja.

350
00:15:43,820 --> 00:15:46,581
Ég byggði umsókn um
mjög sérstakur workflow.

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

352
00:15:47,080 --> 00:15:50,540
Þannig að ef ég hámarkað gögn
geyma að styðja að workflow,

353
00:15:50,540 --> 00:15:52,020
það er að fara að vera hraðari.

354
00:15:52,020 --> 00:15:55,190
Og þess vegna NoSQL getur
virkilega flýta afhendingu

355
00:15:55,190 --> 00:15:57,710
af þeim tegundum þjónustu.

356
00:15:57,710 --> 00:15:58,210
Allt í lagi.

357
00:15:58,210 --> 00:16:00,501
>> Þannig að við erum að fara að fá inn
smá kenningu hér.

358
00:16:00,501 --> 00:16:03,330
Og sumir af þú, augun
gæti snúið til baka smá.

359
00:16:03,330 --> 00:16:06,936
En ég ætla að reyna að halda því
eins mikil og ég get.

360
00:16:06,936 --> 00:16:08,880
Svo ef þú ert í verkefni
stjórnun, það er

361
00:16:08,880 --> 00:16:12,280
hugsmíð heitir
þríhyrningur þvingun.

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

363
00:16:12,936 --> 00:16:16,060
Þríhyrningur af þrengir ræður
þú getur ekki hafa allt allan tímann.

364
00:16:16,060 --> 00:16:17,750
Get ekki baka og borða hana líka.

365
00:16:17,750 --> 00:16:22,310
Svo í verkefnastjórnun, sem þríhyrningur
þvingun er hægt að hafa það ódýrt,

366
00:16:22,310 --> 00:16:24,710
þú getur haft það hratt,
eða þú getur haft það gott.

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

368
00:16:25,716 --> 00:16:27,090
Þar sem þú getur ekki hafa öll þrjú.

369
00:16:27,090 --> 00:16:27,460
Ekki satt?

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

371
00:16:27,820 --> 00:16:28,920
>> Svo þú heyrir um þetta mikið.

372
00:16:28,920 --> 00:16:31,253
Það er þrefalt þvingun,
þríhyrningur þrefaldur þvingun,

373
00:16:31,253 --> 00:16:34,420
eða járn þríhyrningur er oftentimes--
þegar þú talar við verkefnastjóra

374
00:16:34,420 --> 00:16:35,420
þeir tala um þetta.

375
00:16:35,420 --> 00:16:37,640
Nú hafa gagnagrunna
eigin járn þríhyrningur þeirra.

376
00:16:37,640 --> 00:16:40,350
Og járn þríhyrningur gagna
er það sem við köllum CAP setning.

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

378
00:16:41,580 --> 00:16:43,770
>> CAP theorem ræður
hvernig gagnagrunnar starfa

379
00:16:43,770 --> 00:16:45,627
undir mjög tilteknu ástandi.

380
00:16:45,627 --> 00:16:47,460
Og við munum tala um
hvað það ástand er.

381
00:16:47,460 --> 00:16:52,221
En þrjú stig í þríhyrningi,
svo að segja, eru C, samkvæmni.

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

383
00:16:52,720 --> 00:16:56,760
Svo í CAP, samkvæmni þýðir að allir
viðskiptavinir sem geta fengið aðgang að gagnagrunninum

384
00:16:56,760 --> 00:16:59,084
verður alltaf að hafa mjög
í samræmi sýn á gögn.

385
00:16:59,084 --> 00:17:00,750
Ađ enginn er að sjá tvo mismunandi hluti.

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

387
00:17:01,480 --> 00:17:04,020
Ef ég sé gagnagrunninn,
Ég ætla að sjá sama útsýni

388
00:17:04,020 --> 00:17:06,130
sem félagi minn sem sér
sama gagnasafn.

389
00:17:06,130 --> 00:17:07,470
Það er samræmi.

390
00:17:07,470 --> 00:17:12,099
>> Aðgengi þýðir að ef
gagnagrunnur á netinu, ef það er hægt að ná,

391
00:17:12,099 --> 00:17:14,760
að allir viðskiptavinir munu alltaf
vera fær um að lesa og skrifa.

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

393
00:17:15,260 --> 00:17:17,010
Svo hvert viðskiptavinur sem
getur lesið gagnagrunn

394
00:17:17,010 --> 00:17:18,955
verður alltaf að vera fær um að lesa
gögn og skrifa gögn.

395
00:17:18,955 --> 00:17:21,819
Og ef það er málið,
það er í boði kerfi.

396
00:17:21,819 --> 00:17:24,230
>> Og þriðja lið er hvað
við köllum skipting umburðarlyndi.

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

398
00:17:24,730 --> 00:17:28,160
Skipting umburðarlyndi leið
að kerfið virkar vel

399
00:17:28,160 --> 00:17:32,000
þrátt líkamlegri net
skipting milli hnúður.

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

401
00:17:32,760 --> 00:17:36,270
Svo hnúður í klasanum geta ekki
tala við hvert annað, hvað gerist?

402
00:17:36,270 --> 00:17:36,880
Allt í lagi.

403
00:17:36,880 --> 00:17:39,545
>> Svo Vensla gagnagrunna choose--
þú getur tekið tvær þeirra.

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

405
00:17:40,045 --> 00:17:43,680
Svo Vensla gagnagrunna velja
að vera í samræmi og í boði.

406
00:17:43,680 --> 00:17:47,510
Ef skipting gerist milli
að DataNodes í gögn geyma,

407
00:17:47,510 --> 00:17:48,831
gagnagrunnurinn hrun.

408
00:17:48,831 --> 00:17:49,330
Ekki satt?

409
00:17:49,330 --> 00:17:50,900
Það fer bara niður.

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

411
00:17:51,450 --> 00:17:54,230
>> Og þetta er hvers vegna þeir hafa
að vaxa með stærri kassa.

412
00:17:54,230 --> 00:17:54,730
Ekki satt?

413
00:17:54,730 --> 00:17:58,021
Vegna þess að það er no-- yfirleitt, þyrping
gagnagrunnur, það er ekki mjög margir af þeim

414
00:17:58,021 --> 00:17:59,590
sem starfa þannig.

415
00:17:59,590 --> 00:18:03,019
En flestir gagnagrunnar skala
í lóðréttri stöðu innan einum kassa.

416
00:18:03,019 --> 00:18:05,060
Vegna þess að þeir þurfa að vera
samræmi og í boði.

417
00:18:05,060 --> 00:18:10,320
Ef skipting væri á að sprauta,
þá myndi þurfa að gera val.

418
00:18:10,320 --> 00:18:13,720
Þú þarft að gera val á milli
vera í samræmi og í boði.

419
00:18:13,720 --> 00:18:16,080
>> Og það er það sem NoSQL gagnagrunna gera.

420
00:18:16,080 --> 00:18:16,580
Allt í lagi.

421
00:18:16,580 --> 00:18:20,950
Svo NoSQL gagnasafn, það
kemur í tveimur bragði.

422
00:18:20,950 --> 00:18:22,990
Við have-- vel, það
kemur í mörgum bragði,

423
00:18:22,990 --> 00:18:26,140
en það kemur með tveimur undirstöðu
characteristics-- hvað

424
00:18:26,140 --> 00:18:30,050
við viljum kalla CP gagnagrunn eða
samræmi og skipting umburðarlyndi

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

426
00:18:31,040 --> 00:18:34,930
Þessir krakkar gera val sem þegar
hnútar tapa samband við hvert annað,

427
00:18:34,930 --> 00:18:37,091
við erum ekki að fara að leyfa
fólk að skrifa eitthvað meira.

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

429
00:18:37,590 --> 00:18:41,855
>> Fram að þeim skipting er fjarlægt,
skrifa aðgangur er læst.

430
00:18:41,855 --> 00:18:43,230
Það þýðir að þeir eru ekki í boði.

431
00:18:43,230 --> 00:18:44,510
Þeir eru stöðug.

432
00:18:44,510 --> 00:18:46,554
Þegar við sjáum að
skipting sprauta sig,

433
00:18:46,554 --> 00:18:48,470
við erum nú í samræmi,
vegna þess að við erum ekki að fara

434
00:18:48,470 --> 00:18:51,517
til að leyfa gögn breytingu á tveimur
hliðar á þilinu óháð öðru

435
00:18:51,517 --> 00:18:52,100
af hvort öðru.

436
00:18:52,100 --> 00:18:54,130
Við verðum að
endurreisa samskipti

437
00:18:54,130 --> 00:18:56,930
áður en uppfærslu
gögn er leyfð.

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

439
00:18:58,120 --> 00:19:02,650
>> Næsta bragðefni væri AP kerfi,
eða í boði sem og skipt upp á

440
00:19:02,650 --> 00:19:03,640
umburðarlyndi kerfi.

441
00:19:03,640 --> 00:19:05,320
Þessir krakkar ekki sama.

442
00:19:05,320 --> 00:19:06,020
Ekki satt?

443
00:19:06,020 --> 00:19:08,960
Allir hnút sem fær
skrifa, við munum taka það.

444
00:19:08,960 --> 00:19:11,480
Þannig að ég ætla afrit gagna minn
á mörgum hnúður.

445
00:19:11,480 --> 00:19:14,730
Þessir hnútar fá viðskiptavinur, viðskiptavinur kemur
í, segir, ég ætla að skrifa nokkur gögn.

446
00:19:14,730 --> 00:19:16,300
Hnútur segir, ekkert vandamál.

447
00:19:16,300 --> 00:19:18,580
Hnúturinn hliðina á honum fær
skrifað á sömu skrá,

448
00:19:18,580 --> 00:19:20,405
hann er að fara að segja ekkert vandamál.

449
00:19:20,405 --> 00:19:23,030
Einhvers staðar aftur á bak endir,
þessi gögn er að fara að endurtaka.

450
00:19:23,030 --> 00:19:27,360
Og þá einhver er að fara að átta sig á,
uh-ó, kerfi sem þeir vilja ná, uh-ó,

451
00:19:27,360 --> 00:19:28,870
það er verið að uppfæra að tveimur hliðum.

452
00:19:28,870 --> 00:19:30,370
Hvað gerum við?

453
00:19:30,370 --> 00:19:33,210
Og hvað þeir gera þá er
þeir gera eitthvað sem

454
00:19:33,210 --> 00:19:36,080
gerir þeim kleift að leysa þessi gögn ástand.

455
00:19:36,080 --> 00:19:39,000
Og við munum tala um
að á næstu töflu.

456
00:19:39,000 --> 00:19:40,000
>> Hlutur að benda á hér.

457
00:19:40,000 --> 00:19:42,374
Og ég ætla ekki að fá of
mikið inn í þetta, vegna þess að þetta

458
00:19:42,374 --> 00:19:43,510
fær í djúpum gögn kenningu.

459
00:19:43,510 --> 00:19:46,670
En það er viðskiptalegs
ramma sem

460
00:19:46,670 --> 00:19:50,680
keyrir í Vensla kerfi sem
leyfa mér að örugglega gera uppfærslur

461
00:19:50,680 --> 00:19:53,760
til margra aðila í gagnagrunninum.

462
00:19:53,760 --> 00:19:58,320
Og þeim uppfærslum gerist
allt í einu eða ekki.

463
00:19:58,320 --> 00:20:00,500
Og þetta er kallað acid viðskipti.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID gefur okkur atomicity, samræmi,
einangrun og endingu.

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

467
00:20:07,070 --> 00:20:13,550
Það þýðir lotukerfinu, viðskipti, öll
uppfærslur mínir annaðhvort gerst eða þeir gera ekki.

468
00:20:13,550 --> 00:20:16,570
Samræmi þýðir að
Gagnagrunnurinn mun alltaf

469
00:20:16,570 --> 00:20:19,780
að flytja inn í samræmi
Ríkið eftir uppfærslu.

470
00:20:19,780 --> 00:20:23,900
Ég mun aldrei yfirgefa gagnagrunninum í
slæmt ástand eftir að sækja uppfærslu.

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

472
00:20:24,400 --> 00:20:26,720
>> Svo það er svolítið öðruvísi
en CAP samkvæmni.

473
00:20:26,720 --> 00:20:29,760
CAP samkvæmni þýðir allt mitt
viðskiptavinir geta alltaf séð gögnin.

474
00:20:29,760 --> 00:20:34,450
ACID samkvæmni þýðir að þegar
a viðskipti er gert, gögn er gott.

475
00:20:34,450 --> 00:20:35,709
Sambönd mín eru öll góð.

476
00:20:35,709 --> 00:20:38,750
Ég ætla ekki að eyða foreldri röð
og láta fullt af munaðarlausum börnum

477
00:20:38,750 --> 00:20:40,970
í sumum öðrum töflunni.

478
00:20:40,970 --> 00:20:44,320
Það getur ekki gerst ef ég er í samræmi
í súrum færslu.

479
00:20:44,320 --> 00:20:49,120
>> Einangrun þýðir að viðskipti
mun alltaf eiga sér stað á eftir öðru.

480
00:20:49,120 --> 00:20:51,920
The endir afleiðing af gögnum
verður sama ástand

481
00:20:51,920 --> 00:20:54,770
eins og ef þeim viðskiptum
sem voru gefin út samtímis

482
00:20:54,770 --> 00:20:57,340
voru teknir af lífi í framhaldsþáttum.

483
00:20:57,340 --> 00:21:00,030
Svo það er concurrency
stjórna í gagnagrunninum.

484
00:21:00,030 --> 00:21:04,130
Svo í rauninni, ég get ekki hækka að
Sama gildi tvisvar með tveimur aðgerðum.

485
00:21:04,130 --> 00:21:08,580
>> En ef ég segi að bæta 1 til þetta gildi,
og tvær færslur koma í

486
00:21:08,580 --> 00:21:10,665
og reyna að gera það, einn er
fara að komast þangað fyrst

487
00:21:10,665 --> 00:21:12,540
og hinn er
fara að komast þangað eftir.

488
00:21:12,540 --> 00:21:15,210
Svo í lok, ég bætti tveimur.

489
00:21:15,210 --> 00:21:16,170
Þú sérð hvað ég meina?

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

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

492
00:21:19,220 --> 00:21:21,250
>> Ending er nokkuð augljóst.

493
00:21:21,250 --> 00:21:23,460
Þegar viðskipti
er getið, það er

494
00:21:23,460 --> 00:21:26,100
fara að vera þar enn
ef kerfið hrynur.

495
00:21:26,100 --> 00:21:29,230
Þegar það kerfi batna, sem
viðskipti sem var framið

496
00:21:29,230 --> 00:21:30,480
er í raun að fara að vera þar.

497
00:21:30,480 --> 00:21:33,130
Svo er að ábyrgðum
á sýru viðskiptum.

498
00:21:33,130 --> 00:21:35,470
Þeir eru nokkuð ágætur ábyrgðir
að hafa á gagnagrunni,

499
00:21:35,470 --> 00:21:36,870
en þeir koma á þann kostnað.

500
00:21:36,870 --> 00:21:37,640
Ekki satt?

501
00:21:37,640 --> 00:21:40,520
>> Vegna þess að vandamálið
með þetta ramma er

502
00:21:40,520 --> 00:21:44,540
Ef það er þil í gögnum
sett, ég verð að taka ákvörðun.

503
00:21:44,540 --> 00:21:48,000
Ég ætla að hafa til að leyfa
uppfærslur á annarri hlið eða hinni.

504
00:21:48,000 --> 00:21:50,310
Og ef það gerist,
þá er ég ekki lengur að fara

505
00:21:50,310 --> 00:21:52,630
til að vera fær um að halda
þessir eiginleikar.

506
00:21:52,630 --> 00:21:53,960
Þeir munu ekki vera í samræmi.

507
00:21:53,960 --> 00:21:55,841
Þeir munu ekki vera einangruð.

508
00:21:55,841 --> 00:21:58,090
Þetta er þar sem það brýtur niður
fyrir Vensla gagnagrunna.

509
00:21:58,090 --> 00:22:01,360
Þetta er ástæðan Vensla
gagnagrunna mælikvarða lóðrétt.

510
00:22:01,360 --> 00:22:05,530
>> Á hinn bóginn, höfum við
hvað heitir BASE tækni.

511
00:22:05,530 --> 00:22:07,291
Og þetta eru NoSQL gagnagrunnum.

512
00:22:07,291 --> 00:22:07,790
Allt í lagi.

513
00:22:07,790 --> 00:22:10,180
Þannig að við höfum CP okkar, AP gagnagrunna.

514
00:22:10,180 --> 00:22:14,720
Og þetta eru það sem þú kallar í rauninni
í boði, mjúkur ástand, loksins

515
00:22:14,720 --> 00:22:15,740
stöðug.

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

517
00:22:16,420 --> 00:22:19,690
>> Í grundvallaratriðum boði, því
þeir eru skipting umburðarlyndur.

518
00:22:19,690 --> 00:22:21,470
Þeir munu alltaf vera
það, jafnvel ef það er

519
00:22:21,470 --> 00:22:23,053
net skipting milli hnúta.

520
00:22:23,053 --> 00:22:25,900
Ef ég get talað við hnút, ég
að fara að vera fær um að lesa gögn.

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

522
00:22:26,460 --> 00:22:30,810
Ég var kannski ekki alltaf fær um að skrifa
gögn ef ég er í samræmi vettvang.

523
00:22:30,810 --> 00:22:32,130
En ég ætla að vera fær um að lesa gögn.

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

525
00:22:34,960 --> 00:22:38,010
>> The mjúkur ástandinu gefur til kynna
að þegar ég las þessi gögn,

526
00:22:38,010 --> 00:22:40,790
það gæti ekki verið það sama og annarra hnúta.

527
00:22:40,790 --> 00:22:43,390
Ef rétt var gefin út á hnút
annars staðar í þyrping

528
00:22:43,390 --> 00:22:46,650
og það hefur ekki endurtaka þvert yfir
þyrping enn þegar ég las þessi gögn,

529
00:22:46,650 --> 00:22:48,680
sem ríkið gæti ekki verið í samræmi.

530
00:22:48,680 --> 00:22:51,650
Hins vegar mun það vera
lokum í samræmi,

531
00:22:51,650 --> 00:22:53,870
sem þýðir að þegar skrifað
er gerð á kerfinu,

532
00:22:53,870 --> 00:22:56,480
það mun endurtaka yfir hnúta.

533
00:22:56,480 --> 00:22:59,095
Og að lokum, að ástand
verður fært í röð,

534
00:22:59,095 --> 00:23:00,890
og það verður í samræmi ríkisins.

535
00:23:00,890 --> 00:23:05,000
>> Nú, CAP setningin raunverulega
spilar aðeins í einu skilyrði.

536
00:23:05,000 --> 00:23:08,700
Það ástand er þegar þetta gerist.

537
00:23:08,700 --> 00:23:13,710
Vegna þegar það er starfrækt í
normal mode, það er engin skipting,

538
00:23:13,710 --> 00:23:16,370
allt er í samræmi og í boði.

539
00:23:16,370 --> 00:23:19,990
Þú áhyggjur aðeins um CAP
þegar við höfum þessi skipting.

540
00:23:19,990 --> 00:23:21,260
Þannig að þeir eru mjög sjaldgæf.

541
00:23:21,260 --> 00:23:25,360
En hvernig kerfið bregst þegar þeir
koma fram fyrirmæli hvaða tegund af kerfi

542
00:23:25,360 --> 00:23:26,750
við erum að fást við.

543
00:23:26,750 --> 00:23:31,110
>> Svo skulum taka a líta á það
sem lítur út eins fyrir AP kerfi.

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

545
00:23:32,621 --> 00:23:34,830
AP kerfi koma í tveimur bragði.

546
00:23:34,830 --> 00:23:38,514
Þeir koma í bragði sem er
Meistari Meistari, 100%, alltaf til staðar.

547
00:23:38,514 --> 00:23:40,430
Og þeir koma í
annað bragð, sem segir,

548
00:23:40,430 --> 00:23:43,330
þú veist hvað, ég er að fara að hafa áhyggjur
um þetta skipting hlutur

549
00:23:43,330 --> 00:23:44,724
þegar raunveruleg skipting á sér stað.

550
00:23:44,724 --> 00:23:47,890
Annars, það er að fara að vera aðal
hnúður sem er að fara að taka rétt.

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

552
00:23:48,500 --> 00:23:50,040
>> Þannig að ef við eitthvað eins og Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra væri snillingur
herra, við skulum mér að skrifa að allir hnút.

554
00:23:54,440 --> 00:23:55,540
Svo gerist það?

555
00:23:55,540 --> 00:23:58,270
Þannig að ég hef á hlut í
gagnagrunnur sem til er á tveimur hnúður.

556
00:23:58,270 --> 00:24:01,705
Við skulum kalla að mótmæla S.
Þannig að við höfum ástand fyrir S.

557
00:24:01,705 --> 00:24:04,312
Við höfum nokkrar aðgerðir
á S sem eru í gangi.

558
00:24:04,312 --> 00:24:06,270
Cassandra leyfir mér að
skrifa til margra hnúður.

559
00:24:06,270 --> 00:24:08,550
Svo skulum segja að ég fá
skrifa fyrir s tveimur hnúður.

560
00:24:08,550 --> 00:24:12,274
Jæja, hvað endar gerast er
við köllum það í skipting atburð.

561
00:24:12,274 --> 00:24:14,190
Það má ekki vera
líkamlegur net skipting.

562
00:24:14,190 --> 00:24:15,950
En vegna þess að hönnun
kerfisins, það er

563
00:24:15,950 --> 00:24:18,449
reyndar sneiða eins fljótt
eins og ég fá að skrifa á tveimur hnúður.

564
00:24:18,449 --> 00:24:20,830
Það er ekki að neyða mig til að
skrifa allt í gegnum einn hnút.

565
00:24:20,830 --> 00:24:22,340
Ég ætla að skrifa á tveimur hnúður.

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

567
00:24:23,330 --> 00:24:25,740
>> Svo nú hef ég tvö ríki.

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

569
00:24:26,360 --> 00:24:28,110
Hvað er að fara að gerast
er fyrr eða síðar,

570
00:24:28,110 --> 00:24:29,960
það er að fara til vera a afritunar atburður.

571
00:24:29,960 --> 00:24:33,300
Það er að fara að vera það sem við
kallað skipting bati, sem

572
00:24:33,300 --> 00:24:35,200
er þar sem þessi tvö
ríki koma aftur saman

573
00:24:35,200 --> 00:24:37,310
og það er að fara að vera reiknirit
sem keyrir inni í gagnagrunninum,

574
00:24:37,310 --> 00:24:38,540
ákveður hvað á að gera.

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

576
00:24:39,110 --> 00:24:43,057
Sjálfgefið, Síðast uppfært
vinnur í flestum AP kerfum.

577
00:24:43,057 --> 00:24:44,890
Svo er það yfirleitt
Sjálfgefið reiknirit, það

578
00:24:44,890 --> 00:24:47,400
þeir kalla svarhringingu
virka, eitthvað sem

579
00:24:47,400 --> 00:24:51,000
verður kallað þegar þetta ástand
greinist að framkvæma nokkur rökfræði

580
00:24:51,000 --> 00:24:52,900
til að leysa það átök.

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

582
00:24:53,850 --> 00:24:58,770
Sjálfgefna svarhringingu og vanræksla
resolver í flestum AP gagnagrunna

583
00:24:58,770 --> 00:25:01,130
er, giska á hvað, timestamp vinnur.

584
00:25:01,130 --> 00:25:02,380
Þetta var síðasta uppfærsla.

585
00:25:02,380 --> 00:25:04,320
Ég ætla að setja þessi uppfærslu í það.

586
00:25:04,320 --> 00:25:08,440
Ég kann að afrita þessa skrá sem ég
varpað burt í bata log

587
00:25:08,440 --> 00:25:11,670
þannig að notandi getur komið aftur seinna
og segja, hey, það var árekstur.

588
00:25:11,670 --> 00:25:12,320
Hvað gerðist?

589
00:25:12,320 --> 00:25:16,370
Og þú getur raunverulega afrita skrá yfir
allir árekstrar og bakfærslur

590
00:25:16,370 --> 00:25:17,550
og sjá hvað gerist.

591
00:25:17,550 --> 00:25:21,580
>> Nú, sem notandi, getur þú einnig
fela rökfræði í þann svarhringingu.

592
00:25:21,580 --> 00:25:24,290
Svo þú getur breytt því
svarhringingu aðgerð.

593
00:25:24,290 --> 00:25:26,730
Þú getur sagt, hey, ég vil
að remediate þessi gögn.

594
00:25:26,730 --> 00:25:28,880
Og ég vil reyna að
sameina þessar tvær færslur.

595
00:25:28,880 --> 00:25:30,050
En það er komið að þér.

596
00:25:30,050 --> 00:25:32,880
Gagnagrunnurinn veit ekki hvernig á að
gera það sjálfkrafa. Flestir tími,

597
00:25:32,880 --> 00:25:34,850
það eina sem gagnagrunnur
veit hvernig á að gera er að segja,

598
00:25:34,850 --> 00:25:36,100
þetta var síðasta platan.

599
00:25:36,100 --> 00:25:39,183
Það er eitt sem er að fara að vinna,
og það er gildi sem ég ætla að setja.

600
00:25:39,183 --> 00:25:41,490
Þegar þessi skipting bati
og fjölgun er,

601
00:25:41,490 --> 00:25:43,930
við höfum okkar ástand, sem
er nú s Prime, sem er

602
00:25:43,930 --> 00:25:46,890
sameiningu stöðu allra þessara hluta.

603
00:25:46,890 --> 00:25:49,700
Svo AP kerfi hafa þetta.

604
00:25:49,700 --> 00:25:51,615
CP kerfi þurfa ekki
að hafa áhyggjur af þessu.

605
00:25:51,615 --> 00:25:54,490
Því um leið og a skipting kemur
í leik, hætta þeir bara að taka

606
00:25:54,490 --> 00:25:55,530
skrifar.

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

608
00:25:56,180 --> 00:25:58,670
Svo er það mjög auðvelt að
takast á við að vera í samræmi

609
00:25:58,670 --> 00:26:01,330
þegar þú samþykkir engar uppfærslur.

610
00:26:01,330 --> 00:26:04,620
Það er með CP kerfi gera.

611
00:26:04,620 --> 00:26:05,120
Allt í lagi.

612
00:26:05,120 --> 00:26:07,590
>> Svo skulum við tala svolítið
hluti um aðgang mynstrum.

613
00:26:07,590 --> 00:26:11,580
Þegar við tölum um NoSQL, það er
allt um aðgang mynstur.

614
00:26:11,580 --> 00:26:13,550
Nú, SQL er tilfallandi, fyrirspurnir.

615
00:26:13,550 --> 00:26:14,481
Það er Vensla verslun.

616
00:26:14,481 --> 00:26:16,480
Við þurfum ekki að hafa áhyggjur
um aðgang mynstur.

617
00:26:16,480 --> 00:26:17,688
Ég skrifa mjög flókið fyrirspurn.

618
00:26:17,688 --> 00:26:19,250
Það fer og fær gögnin.

619
00:26:19,250 --> 00:26:21,210
Það er það sem þetta lítur
eins eðlileg.

620
00:26:21,210 --> 00:26:24,890
>> Þannig að í þessu tiltekna uppbyggingu,
við erum að horfa á vörur verslun.

621
00:26:24,890 --> 00:26:26,640
Ég hef mismunandi tegundir af vörum.

622
00:26:26,640 --> 00:26:27,217
Ég hef bækur.

623
00:26:27,217 --> 00:26:27,800
Ég hef plötur.

624
00:26:27,800 --> 00:26:30,090
Ég hef myndbönd.

625
00:26:30,090 --> 00:26:33,370
Sambandið á milli vara
og einhver af þessum bókum, albúm,

626
00:26:33,370 --> 00:26:34,860
og myndbönd töflur er 1: 1.

627
00:26:34,860 --> 00:26:35,800
Allt í lagi?

628
00:26:35,800 --> 00:26:38,860
Ég hef fengið Vörunúmer,
og finnst þetta samsvarar

629
00:26:38,860 --> 00:26:41,080
við bók, plötu, eða myndskeið.

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

631
00:26:41,580 --> 00:26:44,350
Það er 1: 1 samband
yfir þeim töflum.

632
00:26:44,350 --> 00:26:46,970
>> Nú books-- allir þeir
hafa er rót eignir.

633
00:26:46,970 --> 00:26:47,550
Ekkert mál.

634
00:26:47,550 --> 00:26:48,230
Það er frábært.

635
00:26:48,230 --> 00:26:52,130
Einn-á-einn samband, fá ég allt
gögn sem ég þarf að lýsa þá bók.

636
00:26:52,130 --> 00:26:54,770
Albums-- plötur hafa lög.

637
00:26:54,770 --> 00:26:56,470
Þetta er það sem við köllum einu að mörgum.

638
00:26:56,470 --> 00:26:58,905
Sérhver plata gæti hafa mörg lög.

639
00:26:58,905 --> 00:27:00,780
Svo fyrir hvert lag á
platan, gæti ég

640
00:27:00,780 --> 00:27:02,570
annað met í þessum barna töflu.

641
00:27:02,570 --> 00:27:04,680
Svo ég búa til eina færslu
í albúm mitt borð.

642
00:27:04,680 --> 00:27:06,700
Ég búið til margar færslur
í lögin töflunni.

643
00:27:06,700 --> 00:27:08,850
Einn-á-marga tengsl.

644
00:27:08,850 --> 00:27:11,220
>> Þetta samband er það
við köllum margir-til-margir.

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

646
00:27:11,750 --> 00:27:17,000
Þú sérð að aðilar gætu verið
í mörgum kvikmyndum, mörgum myndböndum.

647
00:27:17,000 --> 00:27:21,450
Svo það sem við gerum er að við setja þetta kortlagning
borð á milli þeirra, sem það bara

648
00:27:21,450 --> 00:27:24,040
kortin leikari ID til the vídeó ID.

649
00:27:24,040 --> 00:27:28,464
Nú get ég búið fyrirspurn á tengir
myndbönd í gegnum leikarann ​​vídeó til leikara,

650
00:27:28,464 --> 00:27:31,130
og það gefur mér ágætur listi af
allar kvikmyndir og alla leikarar

651
00:27:31,130 --> 00:27:32,420
sem voru í þeirri mynd.

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

653
00:27:33,290 --> 00:27:33,880
Svo hér við fara.

654
00:27:33,880 --> 00:27:38,040
Einn-á-mann er efsta
sambandið; einn-til-margir,

655
00:27:38,040 --> 00:27:40,240
plöturnar lögin; margir til margra.

656
00:27:40,240 --> 00:27:44,990
Þeir eru þrír efstu
sambönd í öllum gagnagrunninum.

657
00:27:44,990 --> 00:27:48,050
Ef þú veist hvernig þeir
sambönd vinna saman,

658
00:27:48,050 --> 00:27:51,490
þá þú veist mikið
um gagnagrunn þegar.

659
00:27:51,490 --> 00:27:55,660
Svo NoSQL virkar svolítið öðruvísi.

660
00:27:55,660 --> 00:27:58,930
Við skulum hugsa um fyrir annað það það
Útlit eins og að fara að fá allar vörur mínar.

661
00:27:58,930 --> 00:28:01,096
>> Á samræmdum verslun, ég
langar að fá allar vörur mínar

662
00:28:01,096 --> 00:28:02,970
á lista yfir allar vörur mínar.

663
00:28:02,970 --> 00:28:04,910
Það er mikið af fyrirspurnum.

664
00:28:04,910 --> 00:28:07,030
Ég fékk fyrirspurn fyrir allar bækurnar mínar.

665
00:28:07,030 --> 00:28:08,470
Ég fékk fyrirspurn frá albúmum mínum.

666
00:28:08,470 --> 00:28:09,970
Og ég fékk fyrirspurn fyrir allar hreyfimyndir mínum.

667
00:28:09,970 --> 00:28:11,719
Og ég fékk að setja það
allt saman á lista

668
00:28:11,719 --> 00:28:15,250
og þjóna því aftur upp til
forrit sem er að biðja hana.

669
00:28:15,250 --> 00:28:18,000
>> Til að fá bækurnar mínar, taka þátt I
Vörur og bækur.

670
00:28:18,000 --> 00:28:21,680
Til að fá plötur mínar, fékk ég að taka þátt
Vörur, Albums, og lög.

671
00:28:21,680 --> 00:28:25,330
Og til að fá minn vídeó, ég hef
til að taka þátt vörur til myndbönd,

672
00:28:25,330 --> 00:28:28,890
ganga í gegnum leikari myndbönd,
og koma í Actors.

673
00:28:28,890 --> 00:28:31,020
Svo er það þrjár fyrirspurnir.

674
00:28:31,020 --> 00:28:34,560
Mjög flókin fyrirspurnir til
saman einn vegna sett.

675
00:28:34,560 --> 00:28:36,540
>> Það er minna en ákjósanlegur.

676
00:28:36,540 --> 00:28:39,200
Þetta er ástæðan þegar við tölum
um gögn uppbygging sem er

677
00:28:39,200 --> 00:28:42,900
byggt til að vera efahyggjumaður til aðgang
pattern-- vel sem er frábært.

678
00:28:42,900 --> 00:28:45,730
Og þú getur séð þetta er í raun
gott hvernig við höfum skipulagt gögnin.

679
00:28:45,730 --> 00:28:46,550
Og þú veist hvað?

680
00:28:46,550 --> 00:28:49,750
Ég hef bara eina met leikari.

681
00:28:49,750 --> 00:28:50,440
>> Það er flott.

682
00:28:50,440 --> 00:28:53,750
Ég hef deduplicated öll leikarar mín,
og ég haldið samtök mín

683
00:28:53,750 --> 00:28:55,200
í slíkri kortlagningu töflu.

684
00:28:55,200 --> 00:29:00,620
Hins vegar að fá gögnin
út verður dýr.

685
00:29:00,620 --> 00:29:04,500
Ég ætla að senda CPU allan kerfinu
tengja þessar gögn uppbygging saman

686
00:29:04,500 --> 00:29:05,950
að vera fær um að draga að gögn aftur.

687
00:29:05,950 --> 00:29:07,310
>> Svo hvernig fæ ég í kringum það?

688
00:29:07,310 --> 00:29:11,200
Í NoSQL það er um
samansafn, ekki eðlileg.

689
00:29:11,200 --> 00:29:13,534
Þannig að við viljum segja að við viljum
styðja aðgang mynstur.

690
00:29:13,534 --> 00:29:15,283
Ef aðgang mynstur
til forrit,

691
00:29:15,283 --> 00:29:16,770
Ég þarf að fá allar vörur mínar.

692
00:29:16,770 --> 00:29:19,027
Við skulum setja allar vörur í einu borði.

693
00:29:19,027 --> 00:29:22,110
Ef ég setti allar vörur í einu borði,
Ég get bara valið allar vörur

694
00:29:22,110 --> 00:29:23,850
frá þeirri töflu og ég fæ það allt.

695
00:29:23,850 --> 00:29:25,240
Jæja hvernig geri ég það?

696
00:29:25,240 --> 00:29:28,124
Jæja í NoSQL það er engin
uppbyggingu að borðinu.

697
00:29:28,124 --> 00:29:30,540
Við munum tala svolítið um
hvernig þetta virkar í Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
En þú ert ekki með sama
eiginleika og sömu eiginleika

699
00:29:33,570 --> 00:29:37,751
í hvert einasta röð, í hverjum einasta
atriði, eins og þú gerir í SQL töflunni.

700
00:29:37,751 --> 00:29:39,750
Og hvað þetta gerir mér
að gera er að margt

701
00:29:39,750 --> 00:29:41,124
og gefa mér mikið af sveigjanleika.

702
00:29:41,124 --> 00:29:45,360
Í þessu tiltekna tilviki, ég
hafa vöru skjöl mín.

703
00:29:45,360 --> 00:29:49,090
Og í þessu tiltekna
dæmi, allt

704
00:29:49,090 --> 00:29:51,930
er skjal í Products töflunni.

705
00:29:51,930 --> 00:29:56,510
Og vara fyrir bók gæti
hafa auðkennisgerð sem skilgreinir bók.

706
00:29:56,510 --> 00:29:59,180
Og umsókn
myndi skipta á þeim ID.

707
00:29:59,180 --> 00:30:02,570
>> Á notkunarstað flokkaupplýsingar, ég ætla
að segja ó, hvað met tegund er þetta?

708
00:30:02,570 --> 00:30:04,100
Oh, það er bók met.

709
00:30:04,100 --> 00:30:05,990
Bók færslur hafa þessa eiginleika.

710
00:30:05,990 --> 00:30:08,100
Leyfðu mér að búa til bók mótmæla.

711
00:30:08,100 --> 00:30:11,289
Þannig að ég ætla að fylla
bók mótmæla með þessu verki.

712
00:30:11,289 --> 00:30:13,080
Næsta atriði kemur og
segir, hvað er þetta atriði?

713
00:30:13,080 --> 00:30:14,560
Jæja þetta atriði er plata.

714
00:30:14,560 --> 00:30:17,340
Oh, ég fékk allt annað
vinnslu venja fyrir það,

715
00:30:17,340 --> 00:30:18,487
vegna þess að það er plata.

716
00:30:18,487 --> 00:30:19,320
Þú sérð hvað ég meina?

717
00:30:19,320 --> 00:30:21,950
>> Svo forritið tier-- I
bara velja allar þessar færslur.

718
00:30:21,950 --> 00:30:23,200
Þeir allir byrja að koma í.

719
00:30:23,200 --> 00:30:24,680
Þeir gætu verið allt mismunandi gerðir.

720
00:30:24,680 --> 00:30:27,590
Og það er rökfræði forritsins
sem skiptir yfir þær tegundir

721
00:30:27,590 --> 00:30:29,530
og ákveður hvernig á að vinna úr þeim.

722
00:30:29,530 --> 00:30:33,640
>> Aftur, þannig að við erum að hagræða í
stefið fyrir aðgang mynstur.

723
00:30:33,640 --> 00:30:36,390
Við erum að gera það með því að
hrynja þeim töflum.

724
00:30:36,390 --> 00:30:39,670
Við erum í rauninni að taka
þessi eðlileg mannvirki,

725
00:30:39,670 --> 00:30:42,000
og við erum að byggja
Innbyrðis mannvirki.

726
00:30:42,000 --> 00:30:45,130
Inni hvert og eitt þessara gagna
Ég ætla að sjá array eiginleika.

727
00:30:45,130 --> 00:30:49,400
>> Inni þessu skjali fyrir albúm,
Ég ætla að sjá fylki af lögum.

728
00:30:49,400 --> 00:30:53,900
Þeir slóðir become-- nú er það
grundvallaratriðum þetta barn borð sem

729
00:30:53,900 --> 00:30:56,520
er til hérna í þessari uppbyggingu.

730
00:30:56,520 --> 00:30:57,975
Svo er hægt að gera þetta í DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Þú getur gert þetta í MongoDB.

732
00:30:59,810 --> 00:31:01,437
Þú getur gert þetta í hvaða NoSQL gagnagrunninum.

733
00:31:01,437 --> 00:31:03,520
Búa til þessar tegundir af
Innbyrðis gögn uppbygging

734
00:31:03,520 --> 00:31:07,120
að leyfa þér að sækja gögn
mjög fljótt því nú er ég

735
00:31:07,120 --> 00:31:08,537
þurfa ekki að vera í samræmi.

736
00:31:08,537 --> 00:31:11,620
Þegar ég setja röð í lögin
borð, eða röð í Albums borð,

737
00:31:11,620 --> 00:31:13,110
Ég verð að vera í samræmi við þá stefið.

738
00:31:13,110 --> 00:31:18,060
Ég verð að hafa eigindi eða á
eign sem er skilgreint á þeirri töflu.

739
00:31:18,060 --> 00:31:20,480
Hver og einn þeirra,
þegar ég setja röðinni.

740
00:31:20,480 --> 00:31:21,910
Það er ekki raunin í NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Ég get haft allt öðruvísi
eignir í hvert skjal

742
00:31:24,440 --> 00:31:26,100
sem ég setja í safn.

743
00:31:26,100 --> 00:31:30,480
Svo mjög öflugt kerfi.

744
00:31:30,480 --> 00:31:32,852
Og það er í raun hvernig þú
hagræða í kerfinu.

745
00:31:32,852 --> 00:31:35,310
Vegna þess að nú þeirri fyrirspurn, í stað
um að taka þátt alla þessar töflur

746
00:31:35,310 --> 00:31:39,160
og framkvæmd a hálfa tylft fyrirspurnir
að draga til baka gögn sem ég þarf,

747
00:31:39,160 --> 00:31:40,890
Ég er að keyra eitt fyrirspurn.

748
00:31:40,890 --> 00:31:43,010
Og ég er iterating
yfir niðurstöður settar.

749
00:31:43,010 --> 00:31:46,512
það gefur þér hugmynd
af krafti NoSQL.

750
00:31:46,512 --> 00:31:49,470
Ég ætla að eins konar fara til hliðar hér
og tala svolítið um þetta.

751
00:31:49,470 --> 00:31:53,240
Þetta er meira svona að
markaðssetningu eða technology--

752
00:31:53,240 --> 00:31:55,660
markaðssetningu tækni
tegund af umræðu.

753
00:31:55,660 --> 00:31:58,672
En það er mikilvægt að skilja
því ef við líta á the toppur

754
00:31:58,672 --> 00:32:00,380
hér á þessari töflu,
það sem við erum að horfa á

755
00:32:00,380 --> 00:32:04,030
er það sem við köllum
tækni efla bugða.

756
00:32:04,030 --> 00:32:06,121
Og hvað þýðir þetta er
nýtt efni kemur inn í leik.

757
00:32:06,121 --> 00:32:07,120
Fólk heldur að það er frábært.

758
00:32:07,120 --> 00:32:09,200
Ég hef leyst öll vandamál mín.

759
00:32:09,200 --> 00:32:11,630
>> Þetta gæti verið í lok
allt, vera allt að öllu.

760
00:32:11,630 --> 00:32:12,790
Og þeir byrja að nota það.

761
00:32:12,790 --> 00:32:14,720
Og þeir segja, þetta dót virkar ekki.

762
00:32:14,720 --> 00:32:17,600
Þetta er ekki rétt.

763
00:32:17,600 --> 00:32:19,105
Gamla efni var betri.

764
00:32:19,105 --> 00:32:21,230
Og þeir fara aftur til að gera
hlutina eins og þeir voru.

765
00:32:21,230 --> 00:32:22,730
Og þá loksins
þeir fara, þú veist hvað?

766
00:32:22,730 --> 00:32:24,040
Þetta efni er ekki svo slæmt.

767
00:32:24,040 --> 00:32:26,192
Oh, það er hvernig það virkar.

768
00:32:26,192 --> 00:32:28,900
Og þegar þeir reikna út hvernig það
verk, þeir byrja að fá betra.

769
00:32:28,900 --> 00:32:32,050
>> Og fyndna um það
er það eins konar línur upp á það

770
00:32:32,050 --> 00:32:34,300
við köllum Technology Ættleiðing Bugða.

771
00:32:34,300 --> 00:32:36,910
Svo er það sem gerist við höfum
einhvers konar tækni gikkur.

772
00:32:36,910 --> 00:32:39,100
Þegar um er að ræða gagnagrunna,
það er gögn þrýstingur.

773
00:32:39,100 --> 00:32:42,200
Við töluðum um hátt stig vatn
gagna þrýstingi allan tíma.

774
00:32:42,200 --> 00:32:46,310
Þegar þessi gögn þrýstingur hits ákveðin
lið, það er tækni gikkur.

775
00:32:46,310 --> 00:32:47,830
>> Það er að fá of dýrt.

776
00:32:47,830 --> 00:32:49,790
Það tekur of langan tíma að vinna úr gögnum.

777
00:32:49,790 --> 00:32:50,890
Við þurfum eitthvað betra.

778
00:32:50,890 --> 00:32:52,890
Þú færð frumkvöðla
þarna hlaupandi um,

779
00:32:52,890 --> 00:32:55,050
að reyna að finna út hvað er lausnin.

780
00:32:55,050 --> 00:32:56,050
Hvað er nýtt hugmynd?

781
00:32:56,050 --> 00:32:58,170
>> Hvað er næsta besti
Leiðin til að gera þetta?

782
00:32:58,170 --> 00:32:59,530
Og þeir koma upp með eitthvað.

783
00:32:59,530 --> 00:33:03,140
Og fólk með alvöru sársauka,
krakkar á fjandans brún,

784
00:33:03,140 --> 00:33:06,390
þeir stökkva um allt það,
vegna þess að þeir þurfa að svara.

785
00:33:06,390 --> 00:33:09,690
Nú hvað óhjákvæmilega happens-- og
það er að gerast núna í NoSQL.

786
00:33:09,690 --> 00:33:11,090
Ég sé það allan tímann.

787
00:33:11,090 --> 00:33:13,610
>> Hvað óhjákvæmilega gerist er
fólk byrja að nota nýja tól

788
00:33:13,610 --> 00:33:15,490
á sama hátt og þeir nota gamla tól.

789
00:33:15,490 --> 00:33:17,854
Og þeir finna út það
virkar ekki svo vel.

790
00:33:17,854 --> 00:33:20,020
Ég man ekki hver ég var
að tala við fyrr í dag.

791
00:33:20,020 --> 00:33:22,080
En það er eins og þegar
jackhammer var fundið upp,

792
00:33:22,080 --> 00:33:24,621
fólk ekki sveifla henni yfir
höfuð þeirra til að mölva steypu.

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

794
00:33:27,360 --> 00:33:30,610
>> En það er það sem er
gerast með NoSQL dag.

795
00:33:30,610 --> 00:33:33,900
Ef þú gengur í flestum verslunum,
þeir eru að reyna að vera NoSQL verslanir.

796
00:33:33,900 --> 00:33:36,510
Hvað þeir eru að gera er
þeir eru að nota NoSQL,

797
00:33:36,510 --> 00:33:39,900
og þeir eru að hlaða það
fullt af Vensla stefið.

798
00:33:39,900 --> 00:33:41,630
Því það er hvernig
þeir hanna gagnagrunna.

799
00:33:41,630 --> 00:33:44,046
Og þeir eru að spá, af hverju er
ekki gengur vel?

800
00:33:44,046 --> 00:33:45,230
Boy, þetta stinks.

801
00:33:45,230 --> 00:33:49,900
Ég þurfti að halda öllum mínum
tengir in-- það er, nei, nei.

802
00:33:49,900 --> 00:33:50,800
Halda tengir?

803
00:33:50,800 --> 00:33:52,430
Hvers vegna ert þú að ganga gögnum?

804
00:33:52,430 --> 00:33:54,350
Þú ganga ekki gögn í NoSQL.

805
00:33:54,350 --> 00:33:55,850
Þú samanlagður það.

806
00:33:55,850 --> 00:34:00,690
>> Svo ef þú vilt að forðast þetta, læra
hvernig tól virkar áður en þú raunverulega

807
00:34:00,690 --> 00:34:02,010
byrja að nota það.

808
00:34:02,010 --> 00:34:04,860
Ekki reyna að nota ný tæki sem
sama hátt og þú notaðir gamla verkfæri.

809
00:34:04,860 --> 00:34:06,500
Þú ert að fara að hafa slæma reynslu.

810
00:34:06,500 --> 00:34:08,848
Og í hvert einasta skipti
það er það sem þetta snýst um.

811
00:34:08,848 --> 00:34:11,389
Þegar við byrjum að koma upp hér,
það er vegna þess að fólk mynstrağur út

812
00:34:11,389 --> 00:34:13,449
hvernig á að nota verkfæri.

813
00:34:13,449 --> 00:34:16,250
>> Þeir gerðu það sama þegar
Vensla gagnagrunna voru fundin,

814
00:34:16,250 --> 00:34:17,969
og þeir voru að skipta kerfi skrá.

815
00:34:17,969 --> 00:34:20,420
Þeir reyndu að byggja kerfi skrá
með Vensla gagnagrunna

816
00:34:20,420 --> 00:34:22,159
því það er það fólk skilið.

817
00:34:22,159 --> 00:34:23,049
Það virkaði ekki.

818
00:34:23,049 --> 00:34:26,090
Svo skilja bestu starfsvenjur
af tækni sem þú ert að vinna með

819
00:34:26,090 --> 00:34:26,730
er mikil.

820
00:34:26,730 --> 00:34:29,870
Mjög mikilvægt.

821
00:34:29,870 --> 00:34:32,440
>> Þannig að við erum að fara að fá inn DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB er AWS er
fullkomlega tekist NoSQL vettvang.

823
00:34:36,480 --> 00:34:37,719
Hvað gerir fullkomlega tekist meina?

824
00:34:37,719 --> 00:34:40,010
Það þýðir að þú þarft ekki að
virkilega hafa áhyggjur af neinu.

825
00:34:40,010 --> 00:34:42,060
>> Þú kemur í, þú segir
okkur, ég þarf borð.

826
00:34:42,060 --> 00:34:43,409
Það þarf svona mikla getu.

827
00:34:43,409 --> 00:34:47,300
Þú högg the hnappur og við ákvæði
allt innviði bak við the vettvangur.

828
00:34:47,300 --> 00:34:48,310
Nú er þessi gríðarlegur.

829
00:34:48,310 --> 00:34:51,310
>> Vegna þess að þegar þú talar
um stigstærð gagnagrunn,

830
00:34:51,310 --> 00:34:53,917
NoSQL gögn klösum á
mælikvarða, gangi petabytes,

831
00:34:53,917 --> 00:34:55,750
gangi milljónir
viðskipti á sekúndu,

832
00:34:55,750 --> 00:34:58,180
þetta eru ekki lítil þyrping.

833
00:34:58,180 --> 00:35:00,830
Við erum að tala þúsundir tilvikum.

834
00:35:00,830 --> 00:35:04,480
Annast þúsundir tilfella,
jafnvel raunverulegur tilvikum,

835
00:35:04,480 --> 00:35:06,350
er a raunverulegur sársauki í rassinn.

836
00:35:06,350 --> 00:35:09,110
Ég meina, hugsa um í hvert sinn sem
stýrikerfi plástur kemur út

837
00:35:09,110 --> 00:35:11,552
eða ný útgáfa af gagnagrunninum.

838
00:35:11,552 --> 00:35:13,260
Hvað þýðir það
þér rekstrarlega?

839
00:35:13,260 --> 00:35:16,330
Það þýðir að þú got 1.200
netþjónum sem þarf að vera uppfærð.

840
00:35:16,330 --> 00:35:18,960
Nú jafnvel með sjálfvirkni,
sem getur tekið langan tíma.

841
00:35:18,960 --> 00:35:21,480
Það getur valdið miklum
rekstrar höfuðverk,

842
00:35:21,480 --> 00:35:23,090
vegna þess að ég gæti hafa þjónustu niður.

843
00:35:23,090 --> 00:35:26,070
>> Eins og ég uppfæra þessa gagnagrunna, ég
gæti gert Blue Green dreifing

844
00:35:26,070 --> 00:35:29,420
þar sem ég senda á vettvang og uppfærsla helmingur minn
hnúður, og síðan uppfæra hinn helminginn.

845
00:35:29,420 --> 00:35:30,490
Taktu þá niður.

846
00:35:30,490 --> 00:35:33,410
Svo stjórna innviði
mælikvarði er gríðarlega sársaukafullt.

847
00:35:33,410 --> 00:35:36,210
Og AWS taka þessi sársauka út af því.

848
00:35:36,210 --> 00:35:39,210
Og NoSQL gagnagrunna getur
verið ótrúlega sársaukafullt

849
00:35:39,210 --> 00:35:41,780
vegna þess hvernig þeir mælikvarða.

850
00:35:41,780 --> 00:35:42,926
>> Scale lárétt.

851
00:35:42,926 --> 00:35:45,550
Ef þú vilt til að fá stærri NoSQL
gagnagrunnur, þú kaupir fleiri hnútar.

852
00:35:45,550 --> 00:35:48,660
Hver hnútur sem þú kaupir er
annar rekstur höfuðverkur.

853
00:35:48,660 --> 00:35:50,830
Svo láta einhvern annan gera það fyrir þig.

854
00:35:50,830 --> 00:35:52,000
AWS getur gert það.

855
00:35:52,000 --> 00:35:54,587
>> Við styðjum skjal helstu gildi.

856
00:35:54,587 --> 00:35:56,670
Nú erum við ekki að fara of mikið
í hinum töfluna.

857
00:35:56,670 --> 00:35:58,750
There 'a einhver fjöldi af mismunandi
keim af NoSQL.

858
00:35:58,750 --> 00:36:02,670
Þeir eru alls konar fá
munged saman á þessum tímapunkti.

859
00:36:02,670 --> 00:36:06,260
Þú getur litið á DynamoDB og segja já,
við erum bæði skjal og lykill gildi

860
00:36:06,260 --> 00:36:08,412
geyma þetta atriði.

861
00:36:08,412 --> 00:36:10,620
Og þú getur rökrætt aðgerðir
af einn yfir annan.

862
00:36:10,620 --> 00:36:13,950
Til mín, mikið af þessu er í raun sex
einn helmingur a tylft af öðrum.

863
00:36:13,950 --> 00:36:18,710
Hver og einn af þessum tækni er
fínn tækni og fínn lausn.

864
00:36:18,710 --> 00:36:23,390
Ég myndi ekki segja MongoDB er betri eða
verra en sófanum, þá Cassandra,

865
00:36:23,390 --> 00:36:25,994
þá Dynamo, eða öfugt.

866
00:36:25,994 --> 00:36:27,285
Ég meina, þetta eru bara möguleikar.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Það er fljótur og það er
samræmi við hvaða mælikvarða.

869
00:36:32,700 --> 00:36:36,210
Svo er þetta eitt af stærstu
bónus sem þú færð með AWS.

870
00:36:36,210 --> 00:36:40,850
Með DynamoDB er hæfni
að fá lágt einn tölustafur

871
00:36:40,850 --> 00:36:44,040
millísekúnda leynd á hvaða mælikvarða.

872
00:36:44,040 --> 00:36:45,720
Það var hönnun markmið kerfisins.

873
00:36:45,720 --> 00:36:49,130
Og við höfum viðskiptavini sem eru að gera
milljónir færslna á sekúndu.

874
00:36:49,130 --> 00:36:52,670
>> Nú ég fara í gegnum sumir af þeim
nota tilvikum í nokkrar mínútur hér.

875
00:36:52,670 --> 00:36:55,660
Innbyggt aðgang control--
við höfum það sem við köllum

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, eða IAM.

877
00:36:57,920 --> 00:37:01,980
Það síast hvert kerfi,
alla þjónustu sem AWS býður.

878
00:37:01,980 --> 00:37:03,630
DynamoDB er engin undantekning.

879
00:37:03,630 --> 00:37:06,020
Þú getur stjórnað aðgangi
til DynamoDB borðum.

880
00:37:06,020 --> 00:37:09,960
Yfir allt AWS reikningana með
skilgreina hlutverk aðgang og heimildir

881
00:37:09,960 --> 00:37:12,140
í Iam innviði.

882
00:37:12,140 --> 00:37:16,630
>> Og það er lykillinn og óaðskiljanlegur hluti í
það sem við köllum atburður ekið Forritun.

883
00:37:16,630 --> 00:37:19,056
Nú er þetta nýja hugmyndafræði.

884
00:37:19,056 --> 00:37:22,080
>> Áhorfendur: Hvernig er hlutfall af satt
Jákvæður móti falskur neikvæður

885
00:37:22,080 --> 00:37:24,052
á aðgang eftirlitskerfi þinn?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: True jákvæður
móti falskur neikvæður?

887
00:37:26,260 --> 00:37:28,785
Áhorfendur: Reglulegur hvað
þú ættir að vera að koma aftur?

888
00:37:28,785 --> 00:37:33,720
Öfugt við einu sinni í a á meðan það
ekki aftur þegar það ætti að staðfesta?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: Ég gat ekki sagt þér það.

891
00:37:38,050 --> 00:37:40,140
Ef það er einhver bilun
hvað á að

892
00:37:40,140 --> 00:37:42,726
Ég er ekki manneskja til að spyrja
sem einkum spurning.

893
00:37:42,726 --> 00:37:43,850
En það er góð spurning.

894
00:37:43,850 --> 00:37:45,905
Ég væri forvitinn að vita
það sjálfur, í raun.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Og svo þá aftur, nýja hugmyndafræði
er atburður ekið forritun.

897
00:37:51,320 --> 00:37:55,160
Þetta er hugmynd sem þú getur
senda flókin forrit sem

898
00:37:55,160 --> 00:37:59,720
geta starfað mjög, mjög hár mælikvarða
án innviði neinu tagi.

899
00:37:59,720 --> 00:38:02,120
Án fastra
innviði alls.

900
00:38:02,120 --> 00:38:04,720
Og við munum tala svolítið
um hvað það þýðir eins og við

901
00:38:04,720 --> 00:38:06,550
fá á næstu töflur.

902
00:38:06,550 --> 00:38:08,716
>> The fyrstur hlutur sem við munum gera
er að við munum tala um borðum.

903
00:38:08,716 --> 00:38:10,857
API gagnatög fyrir Dynamo.

904
00:38:10,857 --> 00:38:13,190
Og það fyrsta sem þú munt
taka eftir þegar þú horfir á þetta,

905
00:38:13,190 --> 00:38:17,930
ef þú ert kunnuglegur með öllum gagnagrunninum,
gagnasöfn hafa raunverulega tvennskonar API

906
00:38:17,930 --> 00:38:18,430
Ég myndi kalla það.

907
00:38:18,430 --> 00:38:21,570
Eða tvö sett af API.

908
00:38:21,570 --> 00:38:23,840
Einn af þeim væri
stjórnsýslu API.

909
00:38:23,840 --> 00:38:26,710
>> Það sem þeir gæta
störf gagnagrunninum.

910
00:38:26,710 --> 00:38:31,340
Stilla geymsla vél,
setja upp og bæta töflur.

911
00:38:31,340 --> 00:38:35,180
búa gagnasafn
bæklingum og dæmi.

912
00:38:35,180 --> 00:38:40,450
Þetta things-- í DynamoDB, þú
hafa mjög stutta, stutta listum.

913
00:38:40,450 --> 00:38:43,120
>> Svo í öðrum gagnagrunnum,
þú gætir séð heilmikið

914
00:38:43,120 --> 00:38:45,680
af skipunum, af stjórn
skipanir, til að stilla

915
00:38:45,680 --> 00:38:47,290
þessi viðbótar valkostur.

916
00:38:47,290 --> 00:38:51,234
Í DynamoDB þú þarft ekki þá vegna þess að
þú stilla ekki kerfið, gera við.

917
00:38:51,234 --> 00:38:54,150
Svo það eina sem þú þarft að gera er að
segðu mér hvað stærð borð þarf ég.

918
00:38:54,150 --> 00:38:55,660
Þannig að þú færð mjög
takmarkað sett af skipunum.

919
00:38:55,660 --> 00:38:58,618
>> Þú færð Búa Table Update, Table,
Eyða töflu, og lýsa töflu.

920
00:38:58,618 --> 00:39:01,150
Þeir eru einungis hluti
þú þarft að DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Þú þarft ekki geymslu
vél stillingar.

922
00:39:03,294 --> 00:39:04,960
Ég þarf ekki að hafa áhyggjur af afritunar.

923
00:39:04,960 --> 00:39:06,490
Ég þarf ekki að hafa áhyggjur af sharding.

924
00:39:06,490 --> 00:39:07,800
>> Ég þarf ekki að hafa áhyggjur
um eitthvað af þessu efni.

925
00:39:07,800 --> 00:39:08,740
Við gerum það fyrir þig.

926
00:39:08,740 --> 00:39:11,867
Svo það er a gríðarstór magn af kostnaður
það er bara lyft af diskinn þinn.

927
00:39:11,867 --> 00:39:13,200
Þá höfum við crud rekstraraðila.

928
00:39:13,200 --> 00:39:17,740
CRUD er eitthvað sem við
kalla hjá sem er

929
00:39:17,740 --> 00:39:19,860
Búa til, uppfæra Eyða rekstraraðila.

930
00:39:19,860 --> 00:39:24,180
Þetta eru algeng þitt
gagnasafn aðgerðir.

931
00:39:24,180 --> 00:39:31,299
Hluti eins og sölurétti lið, fá atriði, uppfæra
atriði, eyða hlutum, hópur fyrirspurn, skanna.

932
00:39:31,299 --> 00:39:32,840
Ef þú vilt að skanna allt borðið.

933
00:39:32,840 --> 00:39:34,220
Draga allt út af borðinu.

934
00:39:34,220 --> 00:39:37,130
Einn af the ágætur hluti um DynamoDB
er það gerir samhliða skönnun.

935
00:39:37,130 --> 00:39:40,602
Svo þú getur raunverulega að láta mig vita hversu margir
þræðir þú vilt keyra á þeim grannskoða.

936
00:39:40,602 --> 00:39:41,810
Og við getum keyrt þá þræði.

937
00:39:41,810 --> 00:39:43,985
Við getum snúast að skanna allt
á mörgum þráðum

938
00:39:43,985 --> 00:39:49,060
svo þú getur skanna allt borðið
rúm mjög, mjög fljótt í DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Hin API sem við höfum er
það sem við köllum Straumar API okkar.

940
00:39:51,490 --> 00:39:52,940
Við erum ekki að fara að tala of
mikið um þetta núna.

941
00:39:52,940 --> 00:39:55,189
Ég hef fengið nokkrar efni síðar
á í þilfari um þetta.

942
00:39:55,189 --> 00:39:59,910
En Straumar er í raun running--
hugsa um það sem tíminn bauð

943
00:39:59,910 --> 00:40:01,274
og skipting Change Log.

944
00:40:01,274 --> 00:40:03,940
Allt sem er að gerast á
sýnir taflan upp á straumi.

945
00:40:03,940 --> 00:40:05,940
>> Sérhver skrifa að borðinu
sýnir sig á straumi.

946
00:40:05,940 --> 00:40:08,370
Þú getur lesið það á, og
þú getur gert hluti með það.

947
00:40:08,370 --> 00:40:10,150
Við munum tala um það
tegundir af hlutum sem þú

948
00:40:10,150 --> 00:40:13,680
gera með það eins og afritunar,
búa efri stuðla.

949
00:40:13,680 --> 00:40:17,620
Alls konar virkilega flott
hlutir sem þú getur gert við það.

950
00:40:17,620 --> 00:40:19,150
>> Gagnatög.

951
00:40:19,150 --> 00:40:23,320
Í DynamoDB, styðja við bæði lykil
gildi og skjal gagnatög.

952
00:40:23,320 --> 00:40:26,350
Á vinstri hönd hlið af the skjár
hér höfum við fengið helstu tegundir okkar.

953
00:40:26,350 --> 00:40:27,230
Helstu gerðir gildi.

954
00:40:27,230 --> 00:40:30,040
Þetta eru strengir,
tölur og tvöfaldur.

955
00:40:30,040 --> 00:40:31,640
>> Svo bara þrjú helstu tegundir.

956
00:40:31,640 --> 00:40:33,700
Og þá er hægt að hafa sett af þeim.

957
00:40:33,700 --> 00:40:37,650
Einn af the ágætur hluti um NoSQL er
þú getur innihaldið fylki sem eignir.

958
00:40:37,650 --> 00:40:42,050
Og með DynamoDB þú getur innihaldið fylki
af helstu tegundir sem rót eign.

959
00:40:42,050 --> 00:40:43,885
>> Og þá er það skjalið tegundir.

960
00:40:43,885 --> 00:40:45,510
Hversu margir eru kunnugir JSON?

961
00:40:45,510 --> 00:40:47,130
Þið kannast við JSON svo mikið?

962
00:40:47,130 --> 00:40:49,380
Það er í grundvallaratriðum JavaScript,
Object, Ritháttur.

963
00:40:49,380 --> 00:40:52,510
Það gerir þér kleift að í grundvallaratriðum
skilgreina valdakerfi.

964
00:40:52,510 --> 00:40:58,107
>> Þú getur geymt JSON skjal á
DynamoDB nota algeng hluti

965
00:40:58,107 --> 00:41:00,940
eða byggja blokkir sem eru í boði
í flestum forritunarmál.

966
00:41:00,940 --> 00:41:03,602
Svo ef þú ert með Java, þú ert
horfa á kort og listum.

967
00:41:03,602 --> 00:41:05,060
Ég get búið til hluti sem svæði kort.

968
00:41:05,060 --> 00:41:08,030
A Kort sem helstu gildi
geymt sem eignir.

969
00:41:08,030 --> 00:41:10,890
Og það gæti hafa lista yfir
gildi innan þessara eiginleika.

970
00:41:10,890 --> 00:41:13,490
Þú getur geymt þetta flókið
valdakerfi

971
00:41:13,490 --> 00:41:16,320
sem einn eiginleiki
af DynamoDB hlut.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Svo borðum í DynamoDB, eins og flest
NoSQL gagnagrunna, hafa töflur atriði.

974
00:41:24,460 --> 00:41:26,469
Í MongoDB þú myndir
kalla þessi skjöl.

975
00:41:26,469 --> 00:41:27,760
Og það væri í sófanum stöð.

976
00:41:27,760 --> 00:41:28,900
Einnig skjal gagnasafn.

977
00:41:28,900 --> 00:41:29,941
Þér kallið þessi skjöl.

978
00:41:29,941 --> 00:41:32,930
Skjöl eða hlutir hafa eiginleika.

979
00:41:32,930 --> 00:41:35,850
Eiginleiki getur til eða
ekki til á hlutnum.

980
00:41:35,850 --> 00:41:38,520
Í DynamoDB, það er
einn nauðsynlegur eiginleiki.

981
00:41:38,520 --> 00:41:43,880
Rétt eins og í Venslagagnagrunnur,
þú hafa grunn takka á borðinu.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB hefur það sem við köllum kjötkássa takkann.

983
00:41:46,010 --> 00:41:48,280
Hash lykillinn verður að vera einstakt.

984
00:41:48,280 --> 00:41:52,580
Svo þegar ég skilgreina kjötkássa borð,
grundvallaratriðum það sem ég er að segja

985
00:41:52,580 --> 00:41:54,110
er hvert atriði mun hafa kjötkássa takkann.

986
00:41:54,110 --> 00:41:58,520
Og sérhver kjötkássa lykill verður að vera einstakt.

987
00:41:58,520 --> 00:42:01,200
>> Hvert atriði er skilgreint
af því einstaka kjötkássa lykill.

988
00:42:01,200 --> 00:42:02,940
Og það getur aðeins verið einn.

989
00:42:02,940 --> 00:42:05,820
Þetta er í lagi, en oftsinnis
það sem fólk þarf

990
00:42:05,820 --> 00:42:08,170
er þeir vilja er þetta kjötkássa
takkann til að gera smá meira

991
00:42:08,170 --> 00:42:11,010
en bara vera einstakt auðkenni.

992
00:42:11,010 --> 00:42:15,240
Oftsinnis við viljum nota þessi kjötkássa lykill
sem efst stigi samansafn fötu.

993
00:42:15,240 --> 00:42:19,160
Og hvernig við gera sem er með
bæta það sem við köllum ýmsum lykil.

994
00:42:19,160 --> 00:42:22,460
>> Þannig að ef það er kjötkássa aðeins
borð, þetta verður að vera einstakt.

995
00:42:22,460 --> 00:42:27,040
Ef það er kjötkássa og svið borð,
Samsetningin af tæti og á bilinu

996
00:42:27,040 --> 00:42:28,640
verður að vera einstakt.

997
00:42:28,640 --> 00:42:30,110
Svo hugsa um það með þessum hætti.

998
00:42:30,110 --> 00:42:32,140
Ef ég er með umræðum.

999
00:42:32,140 --> 00:42:39,010
Og formið hefur efni, það hefur
innlegg, og það hefur svör.

1000
00:42:39,010 --> 00:42:42,630
>> Svo ég gæti hafa kjötkássa
lykill, sem er rakin ID.

1001
00:42:42,630 --> 00:42:46,650
Og ég gæti hafa svið lykill,
sem er að bregðast ID.

1002
00:42:46,650 --> 00:42:49,650
Þannig ef ég vil fá allar
Svörun tilteknu efni,

1003
00:42:49,650 --> 00:42:52,370
Ég get bara fyrirspurn kjötkássa.

1004
00:42:52,370 --> 00:42:55,190
Ég get bara sagt að gefa mér allt
atriði sem hafa þetta kjötkássa.

1005
00:42:55,190 --> 00:43:01,910
Og ég ætla að fá öllum spurningum
eða senda fyrir viðkomandi efni.

1006
00:43:01,910 --> 00:43:03,910
Þessar efstu stigi útfellingarnar
eru mjög mikilvæg.

1007
00:43:03,910 --> 00:43:07,370
Þeir styðja aðal aðgang
Mynstur af forritinu.

1008
00:43:07,370 --> 00:43:09,420
Almennt talað, þetta
er það sem við viljum gera.

1009
00:43:09,420 --> 00:43:11,780
Við viljum að table--
og þú hleður borð,

1010
00:43:11,780 --> 00:43:16,640
við viljum að skipuleggja gögnin
í töflunni á þann hátt

1011
00:43:16,640 --> 00:43:20,140
að forritið getur mjög
fljótt sækja þær niðurstöður.

1012
00:43:20,140 --> 00:43:24,510
Og oftsinnis leiðin til að gera það er
að viðhalda þessum heildarniðurstöðum sem vér

1013
00:43:24,510 --> 00:43:25,650
setja gögnin.

1014
00:43:25,650 --> 00:43:31,110
Í grundvallaratriðum erum við að dreifa gögnum
í björtu fötu eins og það kemur í.

1015
00:43:31,110 --> 00:43:35,210
>> Hóflegt lyklar leyfa me-- kjötkássa
Lyklar að vera jafnrétti.

1016
00:43:35,210 --> 00:43:39,490
Þegar ég fyrirspurn kjötkássa, ég verð að segja
gefa mér kjötkássa sem jafngildir þetta.

1017
00:43:39,490 --> 00:43:41,950
Þegar ég fyrirspurn svið, ég
getur sagt gefa mér mikinn

1018
00:43:41,950 --> 00:43:47,040
sem er að nota hvers konar
ríkur rekstraraðili sem við styðjum.

1019
00:43:47,040 --> 00:43:49,200
Gefðu mér alla atriði fyrir kjötkássa.

1020
00:43:49,200 --> 00:43:52,520
Er það jafn, stærra en,
minna en, það að byrja með,

1021
00:43:52,520 --> 00:43:54,145
er það til á milli þessara tveggja gilda?

1022
00:43:54,145 --> 00:43:56,811
Svo þessar tegundir af svið fyrirspurnir
að við erum alltaf áhuga á.

1023
00:43:56,811 --> 00:43:59,650
Nú eitt um gögn, þegar
þú horfir á aðgang að gögnum, þegar

1024
00:43:59,650 --> 00:44:02,360
þú aðgang að gögnum, það er
alltaf um að samloðun.

1025
00:44:02,360 --> 00:44:05,770
Það er alltaf um færslur
sem eru tengdar þessu.

1026
00:44:05,770 --> 00:44:10,390
Gefðu mér allt hér that's-- allt
viðskiptin skráðir greiðslukorti

1027
00:44:10,390 --> 00:44:12,500
í síðasta mánuði.

1028
00:44:12,500 --> 00:44:13,960
Það er samansafn.

1029
00:44:13,960 --> 00:44:17,490
>> Næstum allt sem þú gerir í
Gagnagrunnurinn er einhvers konar samansafn.

1030
00:44:17,490 --> 00:44:21,530
Svo að vera fær um að vera fær um að skilgreina
þessir fötunum og gefa þér þessar svið

1031
00:44:21,530 --> 00:44:24,950
eiginleika til að vera fær um að fyrirspurn á,
þessir ríkur fyrirspurnir styðja margir,

1032
00:44:24,950 --> 00:44:27,165
margir, margir umsókn aðgang mynstur.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Svo annar hlutur kjötkássa lykill
gerir er að það gefur okkur kerfi

1035
00:44:35,000 --> 00:44:37,740
að vera fær um að dreifa gögnunum kring.

1036
00:44:37,740 --> 00:44:40,390
NoSQL gagnagrunna virka best
þegar gögnum er jafnt

1037
00:44:40,390 --> 00:44:41,740
dreift yfir þyrping.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Hversu margir eru kunnugir
með hass reiknirit?

1040
00:44:47,050 --> 00:44:49,860
Þegar ég segi kjötkássa og hashing--
vegna hökkunarkerfis reiknirit

1041
00:44:49,860 --> 00:44:54,140
er leið til að vera fær um að búa til
a handahófi gildi frá hverjum gildi.

1042
00:44:54,140 --> 00:44:59,300
Þannig að í þessu tiltekna tilviki,
kjötkássa reiknirit hlaupum er ND 5 byggist.

1043
00:44:59,300 --> 00:45:04,765
>> Og ef ég hef kenni, og þetta
er kjötkássa lykillinn minn, ég hef 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Þegar ég keyra kjötkássa reiknirit,
það er að fara að koma aftur og segja,

1045
00:45:07,390 --> 00:45:10,800
vel 1 er 7B, 2
jafngildir 48, 3 er CD.

1046
00:45:10,800 --> 00:45:13,092
Þeir eru dreift um allt lykill rúm.

1047
00:45:13,092 --> 00:45:14,050
Og af hverju ertu að gera þetta?

1048
00:45:14,050 --> 00:45:17,120
Vegna þess að það gerir viss um að ég get
setja færslur á mörgum hnúður.

1049
00:45:17,120 --> 00:45:19,574
>> Ef ég er að gera þetta
smám saman eftir þörfum, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Og ég er með kjötkássa svið sem
keyrir í þessu tiltekna tilfelli,

1051
00:45:21,990 --> 00:45:24,785
lítið kjötkássa pláss,
það liggur frá 00 til FF,

1052
00:45:24,785 --> 00:45:27,951
þá færslur eru að fara að koma í
og hann ætlar að fara 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
Hvað gerist?

1055
00:45:31,800 --> 00:45:34,860
Sérhver innskotið er að fara á sama hnút.

1056
00:45:34,860 --> 00:45:36,070
Þú sérð hvað ég meina?

1057
00:45:36,070 --> 00:45:40,910
>> Vegna þess að þegar ég skipt rými,
Ég breiddi þessar skrár yfir,

1058
00:45:40,910 --> 00:45:45,950
og ég skipting, ég ætla að segja
skipting 1 hefur lykil pláss 0 til 54.

1059
00:45:45,950 --> 00:45:47,720
Skipting 2 er 55 til 89.

1060
00:45:47,720 --> 00:45:49,780
Skipting 3 er AA til FF.

1061
00:45:49,780 --> 00:45:53,740
Svo ef ég er að nota línulega incrementing
Auðkenni, getur þú séð hvað er að gerast.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, alla leið í allt að 54.

1063
00:45:57,410 --> 00:46:00,030
Svo eins og ég hamar
færslur inn í kerfið,

1064
00:46:00,030 --> 00:46:02,030
allt endar að fara að einum hnút.

1065
00:46:02,030 --> 00:46:03,160
>> Það er ekki gott.

1066
00:46:03,160 --> 00:46:04,820
Það er óákveðinn greinir í ensku antipattern.

1067
00:46:04,820 --> 00:46:08,760
Í MongoDB þeir hafa þetta vandamál
ef þú notar ekki kjötkássa takkann.

1068
00:46:08,760 --> 00:46:11,325
MongoDB gefur þér kost
af hass takkann gildi.

1069
00:46:11,325 --> 00:46:13,950
Þú ættir alltaf að gera það, ef
þú ert að nota incrementing kjötkássa

1070
00:46:13,950 --> 00:46:17,380
Lykillinn í MongoDB, eða þú munt vera
negla alla skrifa á einum hnút,

1071
00:46:17,380 --> 00:46:21,290
og þú verður að takmarka
skrifa afköst þín illa.

1072
00:46:21,290 --> 00:46:24,896
>> Áhorfendur: Er það A9 169 í aukastaf?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Já, það er
einhvers staðar í kringum það.

1074
00:46:28,450 --> 00:46:29,950
A9, ég veit ekki.

1075
00:46:29,950 --> 00:46:32,200
Þú vilt verða að fá tvöfaldur minn
að aukastaf reiknivél.

1076
00:46:32,200 --> 00:46:34,237
Heilinn minn virkar ekki eins og þessi.

1077
00:46:34,237 --> 00:46:36,320
Áhorfendur: Just a fljótur einn
af Mongo athugasemdum þínum.

1078
00:46:36,320 --> 00:46:39,530
Svo er að mótmæla auðkenni sem kemur
innfæddur með Mongo gera það?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Er það að gera það?

1081
00:46:41,470 --> 00:46:42,970
Ef þú tilgreinir það.

1082
00:46:42,970 --> 00:46:45,030
Með MongoDB, hefur þú möguleika á.

1083
00:46:45,030 --> 00:46:48,930
Þú getur specify-- hvert skjal í
MongoDB hefur að hafa undirstrika ID.

1084
00:46:48,930 --> 00:46:50,300
Það er einstakt gildi.

1085
00:46:50,300 --> 00:46:55,240
>> Í MongoDB þú getur tilgreint
hvort að kjötkássa það eða ekki.

1086
00:46:55,240 --> 00:46:56,490
Þeir gefa bara þér möguleika.

1087
00:46:56,490 --> 00:46:58,198
Ef þú veist að það er
handahófi, ekkert vandamál.

1088
00:46:58,198 --> 00:46:59,640
Þú þarft ekki að gera það.

1089
00:46:59,640 --> 00:47:04,260
Ef þú veist að það er ekki af handahófi, sem
það er incrementing, þá gera kjötkássa.

1090
00:47:04,260 --> 00:47:06,880
>> Nú hlutur óður
hass, þegar þú kjötkássa

1091
00:47:06,880 --> 00:47:08,800
a value-- og þetta er
hvers vegna kjötkássa takkarnir eru alltaf

1092
00:47:08,800 --> 00:47:13,740
einstakar fyrirspurnir, vegna þess að ég hef breytt
gildi, nú get ég ekki gert upp á úrval fyrirspurn.

1093
00:47:13,740 --> 00:47:15,640
Ég get ekki sagt að þetta
milli þessa eða að

1094
00:47:15,640 --> 00:47:20,800
vegna þess að kjötkássa gildi er ekki að fara
jafngilda verðgildi.

1095
00:47:20,800 --> 00:47:24,570
Svo þegar þú kjötkássa sem
lykill, er það jafnrétti aðeins.

1096
00:47:24,570 --> 00:47:28,700
Þetta er ástæðan fyrir í DynamoDB kjötkássa lykill
fyrirspurnir eru alltaf jafnrétti aðeins.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Svo nú í ýmsum key--
þegar ég bæta við að svið takkann,

1099
00:47:34,700 --> 00:47:38,180
þessir svið helstu færslur koma inn og
þeir fá geymd á sama skipting.

1100
00:47:38,180 --> 00:47:42,430
Svo þeir eru mjög fljótt, auðveldlega
sótt vegna þess að þetta er kjötkássa,

1101
00:47:42,430 --> 00:47:43,220
þetta er svið.

1102
00:47:43,220 --> 00:47:44,928
Og þú sérð allt
með sama kjötkássa

1103
00:47:44,928 --> 00:47:48,550
fær geymd á sama skipting pláss.

1104
00:47:48,550 --> 00:47:53,889
Þú getur notað þessi svið takkann til að hjálpa
finndu gögn nálægt foreldri sínu.

1105
00:47:53,889 --> 00:47:55,180
Svo hvað er ég að gera í raun hér?

1106
00:47:55,180 --> 00:47:57,320
Þetta er einn til margra samband.

1107
00:47:57,320 --> 00:48:01,490
Sambandið milli kjötkássa lykill
og svið lykillinn er að margir.

1108
00:48:01,490 --> 00:48:03,490
Ég get verið með marga lykla kjötkássa.

1109
00:48:03,490 --> 00:48:07,610
Ég get bara haft mörg svið
lyklar innan alls kjötkássa takka.

1110
00:48:07,610 --> 00:48:11,910
>> Kjötkássa skilgreinir foreldri,
svið skilgreinir börn.

1111
00:48:11,910 --> 00:48:15,240
Svo er hægt að sjá er það flaumi hér
milli Vensla reisa

1112
00:48:15,240 --> 00:48:18,840
og sömu tegundir
býr í NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Fólk talar um
NoSQL sem nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Það er ekki nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Gögn er ætíð tengdur.

1116
00:48:24,680 --> 00:48:28,172
Þeim samböndum bara
eru byggð á annan hátt.

1117
00:48:28,172 --> 00:48:29,880
Við skulum tala svolítið
hluti um endingu.

1118
00:48:29,880 --> 00:48:34,860
Þegar þú skrifar að DynamoDB, skrifar
eru alltaf þrír-vegur endurtaka.

1119
00:48:34,860 --> 00:48:37,550
Sem þýðir að við höfum þrjá AZ er.

1120
00:48:37,550 --> 00:48:39,160
AZ er eru framboð svæði.

1121
00:48:39,160 --> 00:48:43,430
Þú getur hugsað um Framboð
Zone sem gagna

1122
00:48:43,430 --> 00:48:45,447
eða safn af miðstöðvum gögn.

1123
00:48:45,447 --> 00:48:47,780
Þetta eru landfræðilega
einangraðar hver um sig

1124
00:48:47,780 --> 00:48:51,610
yfir mismunandi svæðum kenna, yfir
mismunandi máttur grids og flæðiengjar.

1125
00:48:51,610 --> 00:48:54,510
A bilun í einni AZ er ekki
að fara að taka niður annan.

1126
00:48:54,510 --> 00:48:56,890
Þeir eru einnig tengd
ásamt ljósleiðari.

1127
00:48:56,890 --> 00:49:01,240
Það styður einn undir 1
millísekúnda leynd milli AZS.

1128
00:49:01,240 --> 00:49:05,390
Svo rauntíma gögn replications
fær í multi AZS.

1129
00:49:05,390 --> 00:49:09,990
>> Og oftsinnis multi AZ dreifing
uppfylla hár framboð kröfur

1130
00:49:09,990 --> 00:49:12,930
af flestum framtak stofnana.

1131
00:49:12,930 --> 00:49:16,139
Svo DynamoDB er dreift
í þremur AZS sjálfgefið.

1132
00:49:16,139 --> 00:49:19,430
Við erum bara að fara að þekkingu skrifa
þegar tveir af þeim þremur hnúður koma aftur

1133
00:49:19,430 --> 00:49:21,470
og segja, já, ég fékk það.

1134
00:49:21,470 --> 00:49:22,050
Afhverju er það?

1135
00:49:22,050 --> 00:49:25,950
Þar á lesa hlið við erum aðeins
að fara að gefa þér gögn til baka þegar

1136
00:49:25,950 --> 00:49:27,570
við fáum það úr tveimur hnúður.

1137
00:49:27,570 --> 00:49:30,490
>> Ef ég er afrit yfir
þrír, og ég er að lesa úr tveimur,

1138
00:49:30,490 --> 00:49:32,840
Ég er alltaf tryggt
að hafa að minnsta kosti einn

1139
00:49:32,840 --> 00:49:35,720
af þeim sem les til að vera
nýjustu afrit af gögnum.

1140
00:49:35,720 --> 00:49:38,340
Það er það sem gerir DynamoDB stöðug.

1141
00:49:38,340 --> 00:49:42,450
Nú getur þú valið um að snúa
þá sem í samræmi les burt.

1142
00:49:42,450 --> 00:49:45,070
Í því tilviki er ég að fara að segja,
Ég bara las úr einum hnút.

1143
00:49:45,070 --> 00:49:47,430
Og ég get ekki ábyrgst það er að fara
að vera sem mest núverandi gögn.

1144
00:49:47,430 --> 00:49:49,450
>> Svo ef skrifa er að koma í,
það hefur ekki endurtaka enn,

1145
00:49:49,450 --> 00:49:50,360
þú ert að fara að fá að afrita.

1146
00:49:50,360 --> 00:49:52,220
Það er að lokum í samræmi lesa.

1147
00:49:52,220 --> 00:49:54,640
Og hvað það er sem er helmingur kostnaðar.

1148
00:49:54,640 --> 00:49:56,140
Svo er þetta eitthvað til að hugsa um.

1149
00:49:56,140 --> 00:50:00,160
Þegar þú ert að lesa út DynamoDB og
þú ert að setja upp lesa getu þína

1150
00:50:00,160 --> 00:50:04,430
einingar, ef þú velur að lokum
samræmi les, það er mikið ódýrara,

1151
00:50:04,430 --> 00:50:06,010
það er um helmingur kostnaðar.

1152
00:50:06,010 --> 00:50:09,342
>> Og svo sparar það þér pening.

1153
00:50:09,342 --> 00:50:10,300
En það er val þitt.

1154
00:50:10,300 --> 00:50:12,925
Ef þú vilt samræmi lesa eða
sem að lokum í samræmi lesa.

1155
00:50:12,925 --> 00:50:15,720
Það er eitthvað sem þú getur valið.

1156
00:50:15,720 --> 00:50:17,659
>> Við skulum tala um stuðla.

1157
00:50:17,659 --> 00:50:19,450
Þannig að við nefna að
efsta þrepi samansafn.

1158
00:50:19,450 --> 00:50:23,720
Við höfum fengið kjötkássa lykla, og
við höfum fengið svið lykla.

1159
00:50:23,720 --> 00:50:24,320
Það er gott.

1160
00:50:24,320 --> 00:50:26,950
Og það er á aðal borðið, ég
fékk einn kjötkássa lykill, ég fékk einn svið takkann.

1161
00:50:26,950 --> 00:50:27,783
>> Hvað þýðir það?

1162
00:50:27,783 --> 00:50:30,410
Ég hef fengið eina eigind sem ég
getur keyrt ríkur fyrirspurnir gegn.

1163
00:50:30,410 --> 00:50:31,800
Það er á bilinu lykillinn.

1164
00:50:31,800 --> 00:50:35,530
Önnur eigindi á þeim item--
Ég get sía á þeim eiginleika.

1165
00:50:35,530 --> 00:50:40,050
En ég get ekki gert hlutina eins, það
hefst með, eða er meiri en.

1166
00:50:40,050 --> 00:50:40,820
>> Hvernig geri ég það?

1167
00:50:40,820 --> 00:50:42,860
Ég að búa til yfirlit.

1168
00:50:42,860 --> 00:50:45,340
Það er tvær tegundir af
Vísitölur í DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Vísitala er mjög
Önnur mynd af borðinu.

1170
00:50:49,002 --> 00:50:50,490
Og sveitarfélaga efri vísitölu.

1171
00:50:50,490 --> 00:50:51,781
>> Sú fyrsta sem við munum tala um.

1172
00:50:51,781 --> 00:50:57,740
Svo staðbundin secondaries eru coexisted
á sama skipting og gögn.

1173
00:50:57,740 --> 00:51:00,240
Og eins og svo, eru þeir á
sama líkamlega hnút.

1174
00:51:00,240 --> 00:51:01,780
Þeir eru það sem við köllum í samræmi.

1175
00:51:01,780 --> 00:51:04,599
Merkingu, þeir vilja viðurkenna
sem skrifa með töflunni.

1176
00:51:04,599 --> 00:51:06,890
Þegar skrifa kemur í,
við munum skrifa í gegnum vísitölu.

1177
00:51:06,890 --> 00:51:09,306
Við munum skrifa upp að borðinu,
og þá munum við að viðurkenna.

1178
00:51:09,306 --> 00:51:10,490
Svo er það í samræmi.

1179
00:51:10,490 --> 00:51:13,174
Þegar skrifa hefur verið
viðurkenndi frá borðinu,

1180
00:51:13,174 --> 00:51:15,090
það tryggt að
sveitarfélaga efri vísitölu

1181
00:51:15,090 --> 00:51:18,380
mun hafa sömu sýn á gögn.

1182
00:51:18,380 --> 00:51:22,390
En það sem þeir leyfa þér að gera er
skilgreina varamaður svið lykla.

1183
00:51:22,390 --> 00:51:25,260
>> Verð að nota sama kjötkássa
lykill sem aðal borðið,

1184
00:51:25,260 --> 00:51:29,050
vegna þess að þeir eru sam-staðsettir á
Sama skipting, og þeir eru í samræmi.

1185
00:51:29,050 --> 00:51:33,110
En ég get búið til yfirlit
með mismunandi lykla svið.

1186
00:51:33,110 --> 00:51:41,590
Svo til dæmis, ef ég hefði framleiðanda
sem hafði hrár hlutar borð koma inn.

1187
00:51:41,590 --> 00:51:44,590
Og hrár hlutar koma í, og
þeir eru lagðar saman af þinginu.

1188
00:51:44,590 --> 00:51:46,840
Og kannski er það muna.

1189
00:51:46,840 --> 00:51:50,240
>> Allir hlutar, sem var gerð af þessu
Framleiðanda eftir þessa dagsetningu,

1190
00:51:50,240 --> 00:51:52,840
Ég þarf að draga úr minn línu.

1191
00:51:52,840 --> 00:51:55,950
Ég get snúast vísitölu
sem væri að leita,

1192
00:51:55,950 --> 00:52:00,760
samtals á þeim degi
Framleiðsla á viðkomandi hluta.

1193
00:52:00,760 --> 00:52:03,930
Svo ef efsta þrep mitt borð var
þegar tætt eftir framleiðanda,

1194
00:52:03,930 --> 00:52:07,655
kannski var það komið á hluta ID, ég
getur búið til yfirlit burt borðið

1195
00:52:07,655 --> 00:52:11,140
eins tætt eftir framleiðanda og
bilinu á framleiðsludegi.

1196
00:52:11,140 --> 00:52:14,490
Og þannig að ég gæti sagt, nokkuð sem
var framleidd milli þessar dagsetningar,

1197
00:52:14,490 --> 00:52:16,804
Ég þarf að draga úr línu.

1198
00:52:16,804 --> 00:52:18,220
Svo er það staðbundin efri vísitölu.

1199
00:52:18,220 --> 00:52:22,280
>> Þessir hafa þau áhrif að
takmarka kjötkássa lykill rúm.

1200
00:52:22,280 --> 00:52:24,360
Vegna þess að þeir sam-verið
á sama geymslu hnút,

1201
00:52:24,360 --> 00:52:26,860
þeir takmarka kjötkássa lykill
rúm 10 gígabæta.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, undir
töflur, mun skipting

1203
00:52:28,950 --> 00:52:31,380
taflan á 10 gígabæta.

1204
00:52:31,380 --> 00:52:34,760
Þegar þú setur 10 gigs af gögnum í, við
fara [PHH], og við bætum við öðrum hnút.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Við munum ekki skipta LSI
á mörgum skipting.

1207
00:52:42,070 --> 00:52:43,200
Við munum skipta töflunni.

1208
00:52:43,200 --> 00:52:44,679
En við munum ekki skipta LSI.

1209
00:52:44,679 --> 00:52:46,470
Svo það er eitthvað
mikilvægt að skilja

1210
00:52:46,470 --> 00:52:50,070
er ef þú ert að gera mjög,
mjög, mjög stór útfellingarnar,

1211
00:52:50,070 --> 00:52:53,860
þá þú ert að fara að vera takmörkuð
10 gígabæta á LSIs þinn.

1212
00:52:53,860 --> 00:52:56,640
>> Ef það er málið, við getum
nota alþjóðlegum secondaries.

1213
00:52:56,640 --> 00:52:58,630
Altækir secondaries eru
virkilega annað borð.

1214
00:52:58,630 --> 00:53:01,720
Þeir eru alveg af að
hlið aðal töflunni.

1215
00:53:01,720 --> 00:53:04,680
Og þeir leyfa mér að finna
allt öðruvísi uppbyggingu.

1216
00:53:04,680 --> 00:53:08,010
Svo hugsa um það sem verið er að sett
í tvo mismunandi töflur, skipulögð

1217
00:53:08,010 --> 00:53:09,220
á tvo mismunandi vegu.

1218
00:53:09,220 --> 00:53:11,360
>> Ég get skilgreina algerlega
öðruvísi kjötkássa lykill.

1219
00:53:11,360 --> 00:53:13,490
Ég get skilgreina algerlega
mismunandi svið lykill.

1220
00:53:13,490 --> 00:53:15,941
Og ég get keyrt þetta
alveg sjálfstætt.

1221
00:53:15,941 --> 00:53:18,190
Eins spurning um staðreynd, ég hef
skilyrtri lesa getu mína

1222
00:53:18,190 --> 00:53:21,090
og skrifa getu til mín
Alþjóðlegar efri Vísitölur

1223
00:53:21,090 --> 00:53:24,240
alveg óháð
aðal mitt borð.

1224
00:53:24,240 --> 00:53:26,640
Ef ég skilgreina þá vísitölu, segi ég
það hversu mikið lesa og skrifa

1225
00:53:26,640 --> 00:53:28,610
getu það er að fara að vera með.

1226
00:53:28,610 --> 00:53:31,490
>> Og það er aðskilið
frá aðal mitt borð.

1227
00:53:31,490 --> 00:53:35,240
Nú bæði af Vísitölur leyfa okkur að
ekki aðeins skilgreina kjötkássa og svið lykla,

1228
00:53:35,240 --> 00:53:38,610
en þeir leyfa okkur að
verkefnið fleiri gildi.

1229
00:53:38,610 --> 00:53:44,950
Svo ef ég vil lesa af vísitölu,
og ég vil fá sett af gögnum,

1230
00:53:44,950 --> 00:53:48,327
Ég þarf ekki að fara aftur til the aðalæð
borð til að fá frekari eiginleika.

1231
00:53:48,327 --> 00:53:50,660
Ég get verkefni þeirra viðbótar
eiginleika í töflunni

1232
00:53:50,660 --> 00:53:53,440
til að styðja við aðgang mynstur.

1233
00:53:53,440 --> 00:53:57,700
Ég veit að við erum líklega að fá inn í sumir
virkilega, really-- hafa komist illgresi

1234
00:53:57,700 --> 00:53:58,910
hér á sumir af þessum hlutum.

1235
00:53:58,910 --> 00:54:02,725
Nú fékk ég að reka út úr þessu.

1236
00:54:02,725 --> 00:54:07,320
>> Áhorfendur: [inaudible]
--table lykillinn ætlað var kjötkássa?

1237
00:54:07,320 --> 00:54:08,840
Upprunalega kjötkássa?

1238
00:54:08,840 --> 00:54:09,340
Multi-slats?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Já.

1240
00:54:10,200 --> 00:54:11,070
Já.

1241
00:54:11,070 --> 00:54:15,260
Grundvallaratriðum borðið lykillinn
bendir aftur til lið.

1242
00:54:15,260 --> 00:54:19,280
Svo er vísitala bendi aftur til
sjálfgefnir hlutir á borðinu.

1243
00:54:19,280 --> 00:54:22,910
Nú getur þú valið um að byggja upp
Vísitala sem aðeins hefur töflunni takkann,

1244
00:54:22,910 --> 00:54:24,840
og engin önnur eignir.

1245
00:54:24,840 --> 00:54:26,570
Og hvers vegna gæti ég það?

1246
00:54:26,570 --> 00:54:28,570
Jæja, kannski hef ég mjög stór atriði.

1247
00:54:28,570 --> 00:54:31,660
>> Ég virkilega þarf aðeins að vita which--
Aðgangur mynstur minn gæti sagt,

1248
00:54:31,660 --> 00:54:33,760
hvaða atriði innihalda þessa eign?

1249
00:54:33,760 --> 00:54:35,780
Ekki þarf að skila hlut.

1250
00:54:35,780 --> 00:54:37,800
Ég þarf bara að vita
hvaða atriði innihalda það.

1251
00:54:37,800 --> 00:54:40,700
Svo er hægt að byggja Vísitölur
sem aðeins hafa borð takkann.

1252
00:54:40,700 --> 00:54:43,360
>> En það er fyrst og fremst það
vísitala hjá er fyrir.

1253
00:54:43,360 --> 00:54:46,280
Það er fyrir að vera fær til fljótt
þekkja sem skráir,

1254
00:54:46,280 --> 00:54:49,470
hvaða raðir, sem
atriði í töflunni hafa

1255
00:54:49,470 --> 00:54:51,080
eiginleikar sem ég er að leita að.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIs, svo hvernig virka þau?

1258
00:54:54,860 --> 00:54:58,340
GSIs eru í grundvallaratriðum ósamstilltur.

1259
00:54:58,340 --> 00:55:02,570
Uppfærslan kemur í töflunni,
Taflan er þá asynchronously uppfærð

1260
00:55:02,570 --> 00:55:03,720
öll GSIs þinn.

1261
00:55:03,720 --> 00:55:06,680
Þetta er ástæðan fyrir GSIs eru
lokum í samræmi.

1262
00:55:06,680 --> 00:55:09,440
>> Það er mikilvægt að hafa í huga að
þegar þú ert að byggja GSIs,

1263
00:55:09,440 --> 00:55:13,110
og þú skilja að þú ert að búa
annar þáttur aggregation--

1264
00:55:13,110 --> 00:55:16,594
nú skulum segja gott dæmi
hér er framleiðandi.

1265
00:55:16,594 --> 00:55:19,260
Ég held að ég gæti verið að tala um
lækningatæki framleiðanda.

1266
00:55:19,260 --> 00:55:23,870
Medical tæki framleiðandi
oftsinnis hafa serialized hluta.

1267
00:55:23,870 --> 00:55:28,070
Þeim hlutum sem fara í
a hip skipti öllu

1268
00:55:28,070 --> 00:55:30,200
hafa smá raðnúmer á þeim.

1269
00:55:30,200 --> 00:55:33,584
Og þeir gætu hafa milljónir og
milljónir og milljarða hlutum

1270
00:55:33,584 --> 00:55:35,000
í öllum tækjum sem þeir skipið.

1271
00:55:35,000 --> 00:55:37,440
Jæja, þeir þurfa að samanlagður undir
mismunandi stærðum, allir hlutar

1272
00:55:37,440 --> 00:55:39,520
í samsetningu, allt
hlutum sem voru gerðar

1273
00:55:39,520 --> 00:55:41,670
á ákveðnu línu, allt
hlutar sem kom

1274
00:55:41,670 --> 00:55:44,620
frá ákveðnum framleiðanda
á ákveðnum degi.

1275
00:55:44,620 --> 00:55:47,940
Og þessar útfellingarnar stundum
fá upp í milljörðum.

1276
00:55:47,940 --> 00:55:50,550
>> Svo ég vinna með nokkrum af
þessir krakkar sem eru að þjást

1277
00:55:50,550 --> 00:55:53,156
vegna þess að þeir búa
þessi ginormous útfellingarnar

1278
00:55:53,156 --> 00:55:54,280
í efri Vísitölur þeirra.

1279
00:55:54,280 --> 00:55:57,070
Þeir gætu hafa hrátt hluta
Taflan sem kemur kjötkássa aðeins.

1280
00:55:57,070 --> 00:55:59,090
Sérhver hluti hefur einstakt raðnúmer.

1281
00:55:59,090 --> 00:56:00,975
Ég nota raðnúmer sem kjötkássa.

1282
00:56:00,975 --> 00:56:01,600
Það er fallegt.

1283
00:56:01,600 --> 00:56:04,160
Hrár gögn mín borð er dreift
allt yfir helstu rými.

1284
00:56:04,160 --> 00:56:05,930
[Mitt? skrifa?]
[? inntaka?] er ógnvekjandi.

1285
00:56:05,930 --> 00:56:07,876
Ég tek mikið af gögnum.

1286
00:56:07,876 --> 00:56:09,500
Þá hvað þeir gera er að þeir búa til GSI.

1287
00:56:09,500 --> 00:56:12,666
Og ég segi, þú veist hvað, ég þarf að sjá
allir hlutar fyrir þessum framleiðanda.

1288
00:56:12,666 --> 00:56:15,060
Jæja, allt í einu er ég
taka milljarð raðir,

1289
00:56:15,060 --> 00:56:17,550
og efni þeim á
einn hnút, vegna þess að þegar

1290
00:56:17,550 --> 00:56:21,170
Ég safhast saman sem er
Framleiðanda ID sem hökkun,

1291
00:56:21,170 --> 00:56:25,410
og hluta númer the range,
þá allt í einu er ég

1292
00:56:25,410 --> 00:56:30,530
setja milljarð hluta í það
Þessi framleiðandi hefur afhent mér.

1293
00:56:30,530 --> 00:56:34,447
>> Það getur valdið miklum
þrýstings á GSI,

1294
00:56:34,447 --> 00:56:36,030
aftur, því ég er að hamra einum hnút.

1295
00:56:36,030 --> 00:56:38,350
Ég er að setja allt þetta
setur inn einum hnút.

1296
00:56:38,350 --> 00:56:40,940
Og það er alvöru vandamál nota málið.

1297
00:56:40,940 --> 00:56:43,479
Nú, ég fékk góð hönnun
fyrirmynd fyrir hvernig þú forðast að.

1298
00:56:43,479 --> 00:56:45,770
Og það er eitt af þeim vandamálum
sem ég vinn alltaf með.

1299
00:56:45,770 --> 00:56:49,590
En hvað gerist, er GSI gæti
ekki nóg til að geta skrifað getu

1300
00:56:49,590 --> 00:56:52,330
að vera fær um að ýta öllum þeim
raðir í einum hnút.

1301
00:56:52,330 --> 00:56:55,390
Og hvað gerist þá er
fyrst og fremst, viðskiptavinurinn borð,

1302
00:56:55,390 --> 00:57:00,180
aðal borð verður eldneytisgjöf
vegna þess að GSI getur ekki haldið upp.

1303
00:57:00,180 --> 00:57:02,980
Svo settu hlutfall minn heldur
falla á aðal borðið

1304
00:57:02,980 --> 00:57:06,230
eins GSI minn reynir að halda í.

1305
00:57:06,230 --> 00:57:08,850
>> Allt í lagi, svo GSI er, LSI er,
hver einn ætti ég að nota?

1306
00:57:08,850 --> 00:57:12,290
LSI er í samræmi.

1307
00:57:12,290 --> 00:57:13,750
GSI er eru loksins samræmi.

1308
00:57:13,750 --> 00:57:17,490
Ef það er allt í lagi, ég mæli með
GSI, þá eru þeir mun sveigjanlegri.

1309
00:57:17,490 --> 00:57:20,270
LSI er hægt að líkja sem GSI.

1310
00:57:20,270 --> 00:57:27,040
Og ef gögn stærð fyrir kjötkássa lykla í
safn yfir 10 gígabæta,

1311
00:57:27,040 --> 00:57:31,050
þá þú ert að fara til að vilja nota það
GSI því það er bara fast hámark.

1312
00:57:31,050 --> 00:57:32,035
>> Allt í lagi, svo stigstærð.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Afköst í Dynamo DB, þú
dós ákvæði [inaudible]

1315
00:57:37,460 --> 00:57:38,680
afköstum við borð.

1316
00:57:38,680 --> 00:57:42,740
Við höfum viðskiptavini sem hafa
skilyrtri 60 billion--

1317
00:57:42,740 --> 00:57:45,970
eru að gera 60 milljarða beiðnir, reglulega
keyra á yfir milljón beiðnir

1318
00:57:45,970 --> 00:57:47,790
á sekúndu á borðum okkar.

1319
00:57:47,790 --> 00:57:50,360
Það er í raun engin
fræðileg takmörk á hversu mikið

1320
00:57:50,360 --> 00:57:53,730
og hversu hratt borðið
getur keyrt í Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Það eru sumir mjúkur
takmarkanir á reikninginn þinn

1322
00:57:55,920 --> 00:57:58,170
sem við setjum í það svo
að þú ekki fara brjálaður.

1323
00:57:58,170 --> 00:58:00,070
Ef þú vilt meira en
það, ekki vandamál.

1324
00:58:00,070 --> 00:58:00,820
Þú kemur segja okkur.

1325
00:58:00,820 --> 00:58:02,810
Við munum snúa upp skífunni.

1326
00:58:02,810 --> 00:58:08,210
>> Sérhver reikningur er takmörkuð að einhverju stigi
í alla þjónustu, bara the kylfa

1327
00:58:08,210 --> 00:58:11,920
svo fólk sem ekki fara brjálaður
ná sér í vandræði.

1328
00:58:11,920 --> 00:58:12,840
Engin takmörk á stærð.

1329
00:58:12,840 --> 00:58:14,940
Þú getur sett hvaða númer
atriði á borð.

1330
00:58:14,940 --> 00:58:17,620
Stærð söluhlutar er
takmörkuð við 400 kílóbæti hvor,

1331
00:58:17,620 --> 00:58:20,050
það væri liður ekki eiginleika.

1332
00:58:20,050 --> 00:58:24,200
Þannig að summa allra eiginleika
er takmörkuð við 400 kílóbæti.

1333
00:58:24,200 --> 00:58:27,300
Og svo aftur, höfum við
að lítið LSI mál

1334
00:58:27,300 --> 00:58:30,405
með 10 gígabæti takmörk á kjötkássa.

1335
00:58:30,405 --> 00:58:33,280
Áhorfendur: Small númer ég vantar
hvað þú ert að segja mér, að is--

1336
00:58:33,280 --> 00:58:36,830
Áhorfendur: Oh, 400 kílóbæti
er hámarks stærð á hlut.

1337
00:58:36,830 --> 00:58:39,570
Svo hefur hlut alla eiginleika.

1338
00:58:39,570 --> 00:58:43,950
Svo er 400 K heildarstærð
af þeim lið, 400 kílóbæti.

1339
00:58:43,950 --> 00:58:46,170
Svo á öllum eiginleikum
sameina, öll gögn

1340
00:58:46,170 --> 00:58:49,140
það er í öllum þeim eiginleikum,
vals upp í samtals stærð,

1341
00:58:49,140 --> 00:58:51,140
nú í dag hluturinn takmörk er 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Svo stigstærð aftur, náð
gegnum skipting.

1344
00:58:57,046 --> 00:58:58,920
Afköst er skilyrtri
á borð stigi.

1345
00:58:58,920 --> 00:59:00,160
Og það er í raun tveir hnúðar.

1346
00:59:00,160 --> 00:59:02,400
Við höfum lesið getu
og skrifa getu.

1347
00:59:02,400 --> 00:59:05,530
>> Svo þetta eru leiðrétt
óháð hvert öðru.

1348
00:59:05,530 --> 00:59:08,640
Mál RCU er stranglega í samræmi les.

1349
00:59:08,640 --> 00:59:13,005
OK, þannig að ef þú ert að segja að ég vil 1.000
RCU er þeir eru stranglega í samræmi,

1350
00:59:13,005 --> 00:59:14,130
þeir eru í samræmi les.

1351
00:59:14,130 --> 00:59:17,130
Ef þú segir að ég vil
hugsanlega í samræmi les,

1352
00:59:17,130 --> 00:59:19,402
þú getur ákvæði 1000
RCU er, þú ert að fara

1353
00:59:19,402 --> 00:59:21,840
að fá 2.000 lokum
samræmi les.

1354
00:59:21,840 --> 00:59:25,940
Og helmingur the verð fyrir þá
lokum felast í les.

1355
00:59:25,940 --> 00:59:28,520
>> Aftur, leiðrétt
óháð hvert öðru.

1356
00:59:28,520 --> 00:59:32,900
Og þeir hafa throughput--
Ef þú neyta 100% af RCU þinn,

1357
00:59:32,900 --> 00:59:35,960
þú ert ekki að fara að hafa áhrif á
Upplýsingar um réttindi.

1358
00:59:35,960 --> 00:59:40,161
Svo þeir eru alveg
óháð hvert öðru.

1359
00:59:40,161 --> 00:59:43,160
Allt í lagi, svo einn af þeim hlutum sem
Ég nefndi stuttlega var eldneytisgjöf.

1360
00:59:43,160 --> 00:59:44,320
Sogið er slæmt.

1361
00:59:44,320 --> 00:59:47,311
Sogið bendir slæmt enga SQL.

1362
00:59:47,311 --> 00:59:50,310
Það eru hlutir sem við getum gert til að hjálpa
þú draga úr eldneytisgjöf sem þér

1363
00:59:50,310 --> 00:59:51,040
eru að upplifa.

1364
00:59:51,040 --> 00:59:53,240
En besta lausnin
að þetta er að láta taka

1365
00:59:53,240 --> 00:59:58,000
a líta á það sem þú ert að gera, vegna þess að
það er and-mynstur í leik hér.

1366
00:59:58,000 --> 01:00:02,140
>> Þetta, hlutir eins og non-samræmdu
vinnuálag, heitum lyklana, heitt skipting.

1367
01:00:02,140 --> 01:00:06,210
Ég er hitting ákveðna takka pláss
mjög erfitt fyrir einhverjum tilteknum ástæðum.

1368
01:00:06,210 --> 01:00:07,080
Hvers vegna er ég að þessu?

1369
01:00:07,080 --> 01:00:08,710
Við skulum reikna það út.

1370
01:00:08,710 --> 01:00:10,427
Ég er að blanda heitt gögnum mínum með kalt gögnum.

1371
01:00:10,427 --> 01:00:12,510
Ég er að láta töflur mínar fá
mikið, en það er í raun

1372
01:00:12,510 --> 01:00:15,970
aðeins sumir hlutmengi af gögnum
það er mjög áhugavert að mér.

1373
01:00:15,970 --> 01:00:20,290
Svo fyrir þig inn gögn, til dæmis, a einhver fjöldi af
viðskiptavini, fá þeir skrá gögn á hverjum degi.

1374
01:00:20,290 --> 01:00:22,490
Þeir fengu mikið af gagna.

1375
01:00:22,490 --> 01:00:25,940
>> Ef þú ert bara að undirboð allt sem þig inn
gögn í eina stóra borðið, yfir tíma

1376
01:00:25,940 --> 01:00:28,070
Borð er að fara að fá gegnheill.

1377
01:00:28,070 --> 01:00:30,950
En ég er í raun aðeins áhuga á
last 24 hours, síðustu sjö daga,

1378
01:00:30,950 --> 01:00:31,659
síðustu 30 daga.

1379
01:00:31,659 --> 01:00:34,074
Whatever glugga tíma
sem ég hef áhuga á að leita

1380
01:00:34,074 --> 01:00:37,010
fyrir the atburður sem þreytandi mig, eða
atburður sem er áhugavert að mér,

1381
01:00:37,010 --> 01:00:39,540
það er eina gluggi sinn sem ég þarf.

1382
01:00:39,540 --> 01:00:42,470
Svo hvers vegna er ég að setja 10 ára
virði af gagna í töflunni?

1383
01:00:42,470 --> 01:00:45,030
Hvað sem veldur er
borðið sem brotið.

1384
01:00:45,030 --> 01:00:45,880
>> Það fær mikið.

1385
01:00:45,880 --> 01:00:48,340
Það byrjar að breiða út
yfir þúsundir hnúður.

1386
01:00:48,340 --> 01:00:51,380
Og þar getu þína
er svo lágt, að þú ert

1387
01:00:51,380 --> 01:00:54,090
reyndar gefa takmarka á hverja
einn af þeim einstaka hnúður.

1388
01:00:54,090 --> 01:00:57,120
Svo skulum byrja að horfa á hvernig
gera við rúlla þeirri töflu yfir.

1389
01:00:57,120 --> 01:01:01,502
Hvernig eigum við að stjórna því að gögn smá
betra að forðast þetta vandamál.

1390
01:01:01,502 --> 01:01:02,710
Og hvað þýðir það líta út?

1391
01:01:02,710 --> 01:01:04,370
Þetta er það sem lítur út eins og.

1392
01:01:04,370 --> 01:01:06,790
Þetta er það sem slæmt NoSQL lítur út.

1393
01:01:06,790 --> 01:01:07,830
>> Ég fékk heitt inni hér.

1394
01:01:07,830 --> 01:01:10,246
Ef þú horfir á hlið hér,
þetta eru allt skipting mín.

1395
01:01:10,246 --> 01:01:12,630
Ég fékk 16 skipting upp hér
á þessu tiltekna dag.

1396
01:01:12,630 --> 01:01:13,630
Við gerum þetta allan tímann.

1397
01:01:13,630 --> 01:01:15,046
Ég keyrt þetta fyrir viðskiptavini allan tímann.

1398
01:01:15,046 --> 01:01:16,550
Það er kallað hita kort.

1399
01:01:16,550 --> 01:01:20,590
Hitakort segir mér hvernig þú ert
aðgang lykill rúm.

1400
01:01:20,590 --> 01:01:23,700
Og hvað er þetta að segja mér
að það er ein ákveðin kjötkássa

1401
01:01:23,700 --> 01:01:26,330
að þessi strákur finnst að
ansi mikið, vegna þess að hann er

1402
01:01:26,330 --> 01:01:28,250
hitting það virkilega, virkilega erfitt.

1403
01:01:28,250 --> 01:01:29,260
>> Svo er blár gott.

1404
01:01:29,260 --> 01:01:29,900
Við eins og blátt.

1405
01:01:29,900 --> 01:01:30,720
Við líkar ekki rautt.

1406
01:01:30,720 --> 01:01:33,120
Rauða þar sem þrýstingur
fær allt að 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, nú þú ert að fara að eldneytisgjöf.

1408
01:01:35,560 --> 01:01:39,030
Svo þegar þú sérð einhverjar rauðar línur eins
this-- og það er ekki bara Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
hvert NoSQL gagnasafn hefur þetta vandamál.

1410
01:01:41,630 --> 01:01:44,640
Það eru and-mynstur sem getur
aka þessar tegundir af aðstæðum.

1411
01:01:44,640 --> 01:01:49,070
Það sem ég geri er að ég að vinna með viðskiptavinum
til að draga þessar aðstæður.

1412
01:01:49,070 --> 01:01:51,840
>> Og hvað þýðir það líta út?

1413
01:01:51,840 --> 01:01:54,260
Og þetta er að fá sem mest
úr Dynamo DB afköst,

1414
01:01:54,260 --> 01:01:56,176
en það er í raun að fá
sem mest út úr NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Þetta er ekki bundin við Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Þetta er definitely-- I
er notað til að vinna á Mongo.

1417
01:02:02,050 --> 01:02:04,090
Ég þekki marga NoSQL kerfum.

1418
01:02:04,090 --> 01:02:06,830
Hver og einn hefur þessar tegundir
af heitu helstu vandamálum.

1419
01:02:06,830 --> 01:02:10,320
Til að fá sem mest út úr öllum NoSQL
gagnagrunnur, sérstaklega Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
þú vilt að búa til töflur
þar sem kjötkássa lykilatriði hefur

1421
01:02:13,320 --> 01:02:18,590
fjölda mismunandi gildi,
mikla cardinality.

1422
01:02:18,590 --> 01:02:22,530
Því það þýðir að ég er að skrifa
til fullt af mismunandi fötunum.

1423
01:02:22,530 --> 01:02:24,870
>> Því fleiri fötunum Ég er
skriflega, þeim mun líklegra

1424
01:02:24,870 --> 01:02:29,100
Ég er að dreifa sem skrifa álag eða
lesa hlaða út á mörgum hnúður,

1425
01:02:29,100 --> 01:02:33,560
því líklegri er ég að hafa
hár afkasta á borðinu.

1426
01:02:33,560 --> 01:02:37,440
Og þá vil ég gildin að vera
óskað nokkuð jafnt yfir tíma

1427
01:02:37,440 --> 01:02:39,430
og jafnt og af handahófi og mögulegt er.

1428
01:02:39,430 --> 01:02:42,410
Jæja, það er góður af áhugavert,
því ég get ekki raunverulega

1429
01:02:42,410 --> 01:02:43,960
stjórna þegar notendur koma.

1430
01:02:43,960 --> 01:02:47,645
Svo nægja að segja, ef við dreifa
það út yfir helstu rými,

1431
01:02:47,645 --> 01:02:49,270
við munum líklega vera í betra form.

1432
01:02:49,270 --> 01:02:51,522
>> Það er ákveðin
Fjárhæð afhendingu tíma

1433
01:02:51,522 --> 01:02:53,230
að þú ert ekki að fara
Til að geta stjórn.

1434
01:02:53,230 --> 01:02:55,438
En þeir eru í raun
tvær víddir sem við höfum,

1435
01:02:55,438 --> 01:02:58,800
rúm, aðgangur jafnt
útbreiðslu, tími, beiðnir

1436
01:02:58,800 --> 01:03:01,040
Koma jafnt dreift í tíma.

1437
01:03:01,040 --> 01:03:03,110
Og ef þessir tveir
skilyrði sé fullnægt,

1438
01:03:03,110 --> 01:03:05,610
þá er það sem það er
fara að líta út.

1439
01:03:05,610 --> 01:03:07,890
Þetta er miklu betur.

1440
01:03:07,890 --> 01:03:08,890
Við erum mjög ánægð hér.

1441
01:03:08,890 --> 01:03:10,432
Við höfum fengið mjög jafnvel aðgang mynstur.

1442
01:03:10,432 --> 01:03:13,098
Já, kannski þú ert að fá a
lítill þrýstingur sérhver nú og þá,

1443
01:03:13,098 --> 01:03:14,830
en ekkert í raun of mikið.

1444
01:03:14,830 --> 01:03:17,660
Svo það er ótrúlegt hversu oft,
þegar ég vinn við viðskiptavini,

1445
01:03:17,660 --> 01:03:20,670
sem fyrst línurit með stóru rauðu
bar og allt sem ljótur gulur það er

1446
01:03:20,670 --> 01:03:23,147
um allt, sem við
fá gert með æfingu

1447
01:03:23,147 --> 01:03:24,980
eftir nokkra mánuði
endurtekinna arkitektúr,

1448
01:03:24,980 --> 01:03:28,050
þeir eru að keyra á nákvæmlega sama
vinnuálag á nákvæmlega sama álag.

1449
01:03:28,050 --> 01:03:30,140
Og þetta er það sem það er að leita eins og núna.

1450
01:03:30,140 --> 01:03:36,600
Svo það sem þú færð með NoSQL er
gögn stefið sem er algerlega

1451
01:03:36,600 --> 01:03:38,510
bundin við aðgang mynstur.

1452
01:03:38,510 --> 01:03:42,170
>> Og þú getur hagrætt þessi gögn stefið
að styðja þessi aðgang mynstur.

1453
01:03:42,170 --> 01:03:45,490
Ef þú ert ekki, þá þú ert að fara
að sjá þær tegundir af vandamálum

1454
01:03:45,490 --> 01:03:46,710
með þeim heitum lyklana.

1455
01:03:46,710 --> 01:03:50,518
>> Áhorfendur: Jæja, óhjákvæmilega sumir staðir
eru að fara að vera heitara en aðrir.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Alltaf.

1457
01:03:51,450 --> 01:03:51,960
Alltaf.

1458
01:03:51,960 --> 01:03:54,620
Já, ég meina það er alltaf
a-- og aftur, það er

1459
01:03:54,620 --> 01:03:56,980
sumir hönnun mynstur sem við munum komast í gegnum
sem mun tala um hvernig þú takast á

1460
01:03:56,980 --> 01:03:58,480
með þessum frábær stór útfellingarnar.

1461
01:03:58,480 --> 01:04:01,260
Ég meina, ég fékk að hafa þá,
hvernig eigum við að bregðast við þeim?

1462
01:04:01,260 --> 01:04:03,760
Ég fékk mjög gott að nota mál
sem við munum tala um fyrir það.

1463
01:04:03,760 --> 01:04:05,940
>> Allt í lagi, þannig að við skulum tala
um sumir viðskiptavinir núna.

1464
01:04:05,940 --> 01:04:06,950
Þessir krakkar eru AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Ég veit ekki hvort þú ert
þekki AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Þú sérð líklega þá
mikið á vafranum.

1467
01:04:10,781 --> 01:04:14,230
Þeir eru ad aftur miða, þeir eru
stærsta auglýsing aftur miða fyrirtæki

1468
01:04:14,230 --> 01:04:14,940
þarna úti.

1469
01:04:14,940 --> 01:04:17,792
Þeir venjulega reglulega hlaupa yfir
60 milljarða viðskipti á dag.

1470
01:04:17,792 --> 01:04:20,000
Þeir eru að gera yfir milljón
viðskipti á sekúndu.

1471
01:04:20,000 --> 01:04:22,660
Þeir hafa fengið mjög einföld borð
uppbyggingu, the viðskipti borð.

1472
01:04:22,660 --> 01:04:26,450
Það er í rauninni bara
kjötkássa lykill er kex,

1473
01:04:26,450 --> 01:04:29,010
svið er lýðfræðileg
flokki, og þá

1474
01:04:29,010 --> 01:04:31,220
þriðja eiginleiki er staðan.

1475
01:04:31,220 --> 01:04:33,720
>> Þannig að við höfum öll fótspor í
Vafrinn okkar frá þessum krakkar.

1476
01:04:33,720 --> 01:04:35,900
Og þegar þú ferð til a
þátt kaupmanns,

1477
01:04:35,900 --> 01:04:39,390
þeir skora grundvallaratriðum þér yfir
ýmsar lýðfræðiflokkar.

1478
01:04:39,390 --> 01:04:42,070
Þegar þú ferð inn á vefsíðu og
þú segja að ég vil sjá þessa ad--

1479
01:04:42,070 --> 01:04:44,920
eða í rauninni þú segir ekki that--
en þegar þú ferð á vef

1480
01:04:44,920 --> 01:04:47,550
þeir segja að þú viljir sjá þessa auglýsingu.

1481
01:04:47,550 --> 01:04:49,370
Og þeir fara að fá þá auglýsingu frá AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll horfir upp á borð þeirra.

1483
01:04:51,130 --> 01:04:52,115
Þeir finna kex þinn.

1484
01:04:52,115 --> 01:04:53,990
Auglýsendur segja
þá vil ég einhvern

1485
01:04:53,990 --> 01:04:58,632
sem er miðaldra,
40 ára gamall maður, í íþróttum.

1486
01:04:58,632 --> 01:05:01,590
Og þeir skora á þig í þessum lýðfræði
og þeir ákveða hvort eða ekki

1487
01:05:01,590 --> 01:05:02,740
það er gott auglýsing fyrir þig.

1488
01:05:02,740 --> 01:05:10,330
>> Nú hafa þeir SLA með
auglýsingar veitendur þeirra

1489
01:05:10,330 --> 01:05:14,510
að veita undir-10 millísekúnda
Viðbrögð á hverjum einasta beiðni.

1490
01:05:14,510 --> 01:05:16,090
Svo þeir eru að nota Dynamo DB fyrir þetta.

1491
01:05:16,090 --> 01:05:18,131
Þeir eru hitting okkur upp
milljón beiðnir á sekúndu.

1492
01:05:18,131 --> 01:05:21,120
Þeir eru færir um að gera allt sitt
leit, Triage allt sem gögn,

1493
01:05:21,120 --> 01:05:26,130
og fá að bæta við tengil til baka til að
auglýsendum á undir 10 millisekúndur.

1494
01:05:26,130 --> 01:05:29,800
Það er í raun nokkuð stórkostlegum
framkvæmd sem þeir hafa.

1495
01:05:29,800 --> 01:05:36,210
>> Þessir krakkar actually--
þetta eru krakkar.

1496
01:05:36,210 --> 01:05:38,010
Ég er ekki viss um að ef það er þessir gaurar.

1497
01:05:38,010 --> 01:05:40,127
Gæti verið að þessir gaurar.

1498
01:05:40,127 --> 01:05:42,210
Í raun sagt us-- nei, ég
held ekki að það var þá.

1499
01:05:42,210 --> 01:05:43,000
Ég held að það var einhver annar.

1500
01:05:43,000 --> 01:05:44,750
Ég var að vinna með
viðskiptavinur sem sagði mér

1501
01:05:44,750 --> 01:05:47,040
að nú að þeir eru búnir
farið til Dynamo DB, þá eru þeir

1502
01:05:47,040 --> 01:05:50,330
eyða meiri peningum í snakk fyrir
þróun lið þeirra í hverjum mánuði

1503
01:05:50,330 --> 01:05:52,886
en þeir eyða í gagnagrunni sínum.

1504
01:05:52,886 --> 01:05:54,760
Svo það verður að gefa þér
Hugmyndin um kostnað sparnaðar

1505
01:05:54,760 --> 01:05:57,889
sem þú getur fengið í Dynamo DB er mikil.

1506
01:05:57,889 --> 01:05:59,430
Allt í lagi, Dropcam er annað fyrirtæki.

1507
01:05:59,430 --> 01:06:02,138
Þetta strákur er góður of-- ef þú heldur
internetið af hlutum, Dropcam

1508
01:06:02,138 --> 01:06:05,150
er í grundvallaratriðum öryggi video.

1509
01:06:05,150 --> 01:06:06,660
Þú setur myndavél þarna úti.

1510
01:06:06,660 --> 01:06:08,180
Myndavélin hefur hreyfiskynjara.

1511
01:06:08,180 --> 01:06:10,290
Einhver kemur með,
kallar á hvíta lið.

1512
01:06:10,290 --> 01:06:13,540
Camera byrjar upptöku um stund uns
það sér ekki neitt hreyfingu lengur.

1513
01:06:13,540 --> 01:06:15,310
Setur þessi vídeó upp á internetinu.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam var fyrirtæki sem er
grundvallaratriðum skipta yfir Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
vegna þess að þeir voru að upplifa
gífurlegur vaxtarverkir.

1516
01:06:22,200 --> 01:06:25,820
Og hvað þeir sögðu okkur,
skyndilega petabytes gagna.

1517
01:06:25,820 --> 01:06:28,070
Þeir höfðu ekki hugmynd um þjónustu þeirra
væri svo vel.

1518
01:06:28,070 --> 01:06:32,310
Meira heimleið video en YouTube
er hvað þessir krakkar eru að fá.

1519
01:06:32,310 --> 01:06:36,780
Þeir nota DynamoDB að fylgjast með öllum
lýsigögn á öllum sínum vídeó lykilatriði.

1520
01:06:36,780 --> 01:06:40,282
>> Svo þeir hafa S3 fötunum þeir ýta
allir tvöfaldur artifacts í.

1521
01:06:40,282 --> 01:06:41,990
Og þá hafa þeir
Dynamo DB færslur sem

1522
01:06:41,990 --> 01:06:44,070
benda fólki á að þeim S3 þremur hlutum.

1523
01:06:44,070 --> 01:06:47,070
Þegar þeir þurfa að líta á myndband,
þeir líta upp met í Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Þeir smella á tengilinn.

1525
01:06:47,903 --> 01:06:49,770
Þeir rífa niður vídeó frá S3.

1526
01:06:49,770 --> 01:06:51,590
Svo er það eins konar hvað þetta lítur út.

1527
01:06:51,590 --> 01:06:53,580
Og þetta er beint úr liði sínu.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB dregur þeirra
afhendingartími fyrir vídeó viðburði

1529
01:06:56,010 --> 01:06:57,590
frá fimm til 10 sekúndur.

1530
01:06:57,590 --> 01:07:00,470
Í gamla Vensla verslun sinni,
þeir nota til að þurfa að fara og framkvæma

1531
01:07:00,470 --> 01:07:03,780
margar flóknar fyrirspurnir til mynd
út sem vídeó til að rífa niður,

1532
01:07:03,780 --> 01:07:06,690
minna en 50 millisekúndur.

1533
01:07:06,690 --> 01:07:08,990
Svo það er ótrúlegt, ótrúlegt
hversu mikið árangur

1534
01:07:08,990 --> 01:07:12,990
þú getur fengið þegar þú bjartsýni og
þú stillir undirliggjandi gagnagrunn

1535
01:07:12,990 --> 01:07:15,110
til að styðja við aðgang mynstur.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, þessir krakkar, hvað er það,
Fruit Ninja Ég giska á er hlutur þeirra.

1537
01:07:20,500 --> 01:07:22,590
Að allar keyrir á Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
Og þessir krakkar, þau eru frábær
þróun lið, mikil þróun

1539
01:07:26,810 --> 01:07:27,670
búð.

1540
01:07:27,670 --> 01:07:29,364
>> Ekki góð Ops lið.

1541
01:07:29,364 --> 01:07:31,280
Þeir vildu ekki hafa a einhver fjöldi
af rekstri auðlinda.

1542
01:07:31,280 --> 01:07:33,940
Þeir voru í erfiðleikum að reyna að halda
umsókn uppbygging þeirra upp

1543
01:07:33,940 --> 01:07:34,290
og keyra.

1544
01:07:34,290 --> 01:07:35,000
Þeir komu til okkar.

1545
01:07:35,000 --> 01:07:36,251
Þeir litu á þessi Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Þeir sögðu, það er fyrir okkur.

1547
01:07:37,291 --> 01:07:39,470
Þeir byggðu heilu þeirra
umsókn ramma á það.

1548
01:07:39,470 --> 01:07:43,640
Sumir raunverulega ágætur athugasemdir hér
frá liðinu á getu þeirra

1549
01:07:43,640 --> 01:07:46,800
að nú áherslu á að byggja
leikurinn og ekki

1550
01:07:46,800 --> 01:07:49,010
þurfa að viðhalda
uppbygging, sem

1551
01:07:49,010 --> 01:07:51,910
var að verða gríðarlegt magn
af kostnaður fyrir liði sínu.

1552
01:07:51,910 --> 01:07:56,170
Svo er þetta eitthvað that-- á
gagnast sem þú færð frá Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Allt í lagi, hafa komist
gögn líkan hér.

1554
01:08:00,930 --> 01:08:03,440
Og við ræddum aðeins um
þetta einn, einn til margra,

1555
01:08:03,440 --> 01:08:05,060
og margir til margra tegund samböndum.

1556
01:08:05,060 --> 01:08:07,630
Og hvernig halda þér þá í Dynamo.

1557
01:08:07,630 --> 01:08:10,500
Í Dynamo DB við notum
Vísitölur, almennt séð,

1558
01:08:10,500 --> 01:08:12,910
að snúa gögn frá
eitt bragð til annars.

1559
01:08:12,910 --> 01:08:15,210
Kjötkássa lyklar, svið lykla, og stuðla.

1560
01:08:15,210 --> 01:08:18,540
>> Í þessu tiltekna
dæmi, sem flestum ríkjum

1561
01:08:18,540 --> 01:08:23,802
hafa leyfi kröfu að
aðeins leyfi einn ökumanns á mann.

1562
01:08:23,802 --> 01:08:26,510
Þú getur ekki farið til að fá tvö ökumanns
leyfi í stöðu Boston.

1563
01:08:26,510 --> 01:08:27,500
Ég get ekki gert það í Texas.

1564
01:08:27,500 --> 01:08:28,708
Það er góður af því hvernig það er.

1565
01:08:28,708 --> 01:08:32,779
Og svo í DMV, höfum við leit, við
vilja til að líta upp leyfi ökumanns

1566
01:08:32,779 --> 01:08:35,180
með kennitölu.

1567
01:08:35,180 --> 01:08:39,990
Ég vil líta upp notanda upplýsingar
með leyfi númer ökumanns.

1568
01:08:39,990 --> 01:08:43,620
>> Svo héldum borð notanda sem
hefur kjötkássa takkann á raðnúmer,

1569
01:08:43,620 --> 01:08:47,830
eða kennitala og
ýmsar eiginleika skilgreind á hlutnum.

1570
01:08:47,830 --> 01:08:49,859
Nú á þessi borð I
gæti skilgreina GSI sem

1571
01:08:49,859 --> 01:08:53,370
selbiti að um sem segir ég vil
a kjötkássa lykill á skírteinið og þá

1572
01:08:53,370 --> 01:08:54,252
allir aðrir hlutir.

1573
01:08:54,252 --> 01:08:57,210
Nú ef ég vil fyrirspurn og finna
leyfisveitandi tala fyrir hverjum Social

1574
01:08:57,210 --> 01:08:59,609
Kennitölu, ég get
fyrirspurn helstu borð.

1575
01:08:59,609 --> 01:09:02,130
>> Ef ég vil að fyrirspurn og ég vil
til að fá félagslegt öryggi

1576
01:09:02,130 --> 01:09:05,735
númer eða aðra eiginleika eftir a
leyfi númer, get ég fyrirspurn GSI.

1577
01:09:05,735 --> 01:09:08,689
Það líkan er að einn
á eina.

1578
01:09:08,689 --> 01:09:12,460
Bara mjög einfalt GSI,
Flip þá hluti í kring.

1579
01:09:12,460 --> 01:09:13,979
Nú, tala um einn til margir.

1580
01:09:13,979 --> 01:09:16,450
Einn til margir er í grundvallaratriðum
kjötkássa range-ið þitt lykillinn.

1581
01:09:16,450 --> 01:09:20,510
Þar sem við fáum mikið með þetta
nota málið er fylgjast með gögnum.

1582
01:09:20,510 --> 01:09:23,880
Monitor gögn kemur í reglulegum
bil, eins internetið af hlutum.

1583
01:09:23,880 --> 01:09:26,890
Við fáum alltaf allt þetta
færslur koma í öllum þeim tíma.

1584
01:09:26,890 --> 01:09:31,420
>> Og ég vil að finna allar lestur
á milli ákveðnu tímabili.

1585
01:09:31,420 --> 01:09:34,220
Það er mjög algengt fyrirspurn í
eftirlit innviði.

1586
01:09:34,220 --> 01:09:38,430
Leiðin fara um það er að finna
einfalt borð uppbyggingu, eitt borð.

1587
01:09:38,430 --> 01:09:42,250
Ég hef fengið mælingar tæki borð
með kjötkássa takkann á auðkenni tækisins.

1588
01:09:42,250 --> 01:09:47,340
Og ég er með svið takka á
timestamp, eða í þessu tilfelli, Epic.

1589
01:09:47,340 --> 01:09:50,350
Og það gerir mig framkvæma flókin
fyrirspurnir gegn því lykill

1590
01:09:50,350 --> 01:09:54,950
og aftur þær færslur sem
eru miðað við niðurstöðu

1591
01:09:54,950 --> 01:09:56,310
sett sem ég er að leita að.

1592
01:09:56,310 --> 01:09:58,360
Og það byggir að einn
til margra tengsl

1593
01:09:58,360 --> 01:10:02,340
í aðal borðið með því að nota
kjötkássa lykill, svið lykill uppbyggingu.

1594
01:10:02,340 --> 01:10:04,600
>> Svo það er góður af innbyggður
í töflunni í Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Þegar ég skilgreina kjötkássa
og svið T borð, ég er

1596
01:10:07,290 --> 01:10:09,240
skilgreina hver við margra tengsl.

1597
01:10:09,240 --> 01:10:12,770
Það er foreldri barns samband.

1598
01:10:12,770 --> 01:10:14,620
>> Við skulum tala um margar
til margra sambönd.

1599
01:10:14,620 --> 01:10:19,170
Og fyrir þetta tiltekna dæmi,
aftur, við erum að fara að nota GSI er.

1600
01:10:19,170 --> 01:10:23,500
Og við skulum tala um gaming
atburðarás þar sem ég hef gefið notanda.

1601
01:10:23,500 --> 01:10:26,500
Mig langar að finna út alla leiki sem
hann er skráður fyrir eða spila í.

1602
01:10:26,500 --> 01:10:29,600
Og fyrir tiltekið leik, ég
langar til að finna alla notendur.

1603
01:10:29,600 --> 01:10:31,010
Svo hvernig á ég að gera það?

1604
01:10:31,010 --> 01:10:34,330
Leikjanotanda minn borð, ég er að fara
að hafa kjötkássa lykill af kenni

1605
01:10:34,330 --> 01:10:35,810
og ýmsum lykillinn af leiknum.

1606
01:10:35,810 --> 01:10:37,810
>> Svo sem notandi getur haft marga leiki.

1607
01:10:37,810 --> 01:10:41,380
Það er ein til margra samband milli
notandi og leikirnir sem hann spilar.

1608
01:10:41,380 --> 01:10:43,410
Og síðan á GSI,
Ég flettir að um.

1609
01:10:43,410 --> 01:10:46,679
Ég kjötkássa á leiknum og
Ég svið á notanda.

1610
01:10:46,679 --> 01:10:48,970
Þannig að ef ég vil fá allar
leikur notandans að spila í,

1611
01:10:48,970 --> 01:10:49,950
Ég fyrirspurn helstu borð.

1612
01:10:49,950 --> 01:10:52,699
Ef ég vil fá alla notendur
sem eru að spila tiltekna leik,

1613
01:10:52,699 --> 01:10:53,887
Ég fyrirspurn GSI.

1614
01:10:53,887 --> 01:10:54,970
Þannig að þú sérð hvernig við gerum þetta?

1615
01:10:54,970 --> 01:10:58,369
Þú byggja til að styðja þessar GSI er að
nota málið, umsókn, aðgangur

1616
01:10:58,369 --> 01:10:59,410
mynstur, umsókn.

1617
01:10:59,410 --> 01:11:01,440
>> Ef ég þarf að fyrirspurn á
þessi vídd, láta

1618
01:11:01,440 --> 01:11:03,500
mér að búa til yfirlit um þessi vídd.

1619
01:11:03,500 --> 01:11:05,850
Ef ég geri það ekki, ég hugsa ekki.

1620
01:11:05,850 --> 01:11:09,060
Og eftir notkun tilfelli, ég
getur þurft vísitölu eða ég gæti það ekki.

1621
01:11:09,060 --> 01:11:12,390
Ef það er einföld að margir,
aðal borðið er fínt.

1622
01:11:12,390 --> 01:11:15,860
Ef ég þarf að gera þetta margir til
margir er, eða þarf ég að gera eitt til sjálfur,

1623
01:11:15,860 --> 01:11:18,390
þá kannski ég þarf
að annað vísitalan.

1624
01:11:18,390 --> 01:11:20,840
Svo það veltur allt á
það sem ég er að reyna að gera

1625
01:11:20,840 --> 01:11:24,550
og það sem ég er að reyna að fá leikinn.

1626
01:11:24,550 --> 01:11:28,000
>> Sennilega ég ætla ekki að eyða of
mikill tími að tala um skjöl.

1627
01:11:28,000 --> 01:11:31,460
Þetta fær smá, líklega,
dýpra en við þurfum að fara inn í.

1628
01:11:31,460 --> 01:11:33,710
Við skulum tala svolítið
um ríkur fyrirspurn tjáningu.

1629
01:11:33,710 --> 01:11:37,831
Svo í Dynamo DB við höfum
getu til að búa

1630
01:11:37,831 --> 01:11:39,330
það sem við köllum vörpun tjáning.

1631
01:11:39,330 --> 01:11:42,660
Vörpun orðasambönd eru einfaldlega
tína reitina eða gildi

1632
01:11:42,660 --> 01:11:44,290
sem þú vilt birta.

1633
01:11:44,290 --> 01:11:46,000
OK, svo ég gera upp á úrval.

1634
01:11:46,000 --> 01:11:48,010
Ég geri fyrirspurn gegn Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
Og ég segi, þú veist hvað ég á, sýna
mig aðeins fimm stjörnu umsagnir

1636
01:11:51,730 --> 01:11:54,544
fyrir þessa tilteknu vöru.

1637
01:11:54,544 --> 01:11:55,710
Svo er það allt sem ég vil sjá.

1638
01:11:55,710 --> 01:11:57,320
Ég vil ekki að sjá alla
aðra eiginleika í röð,

1639
01:11:57,320 --> 01:11:58,319
Ég vil bara að sjá þetta.

1640
01:11:58,319 --> 01:12:01,209
Það er bara eins og í SQL þegar þú
segja velja stjörnu eða frá borði,

1641
01:12:01,209 --> 01:12:02,000
þú færð allt.

1642
01:12:02,000 --> 01:12:05,450
Þegar ég segi að velja nafn úr
borð, ég fæ bara eina eigind.

1643
01:12:05,450 --> 01:12:09,070
Það er sama tegund af hlutur í
Dynamo DB eða annað NoSQL gagnagrunna.

1644
01:12:09,070 --> 01:12:14,510
Sía orðasambönd leyfa mér að
grundvallaratriðum skera úrslit sett niður.

1645
01:12:14,510 --> 01:12:15,540
Svo ég gera fyrirspurn.

1646
01:12:15,540 --> 01:12:17,260
Fyrirspurn komið aftur með 500 atriði.

1647
01:12:17,260 --> 01:12:20,255
En ég vil bara þá hluti sem
hafa eigindi sem segir þetta.

1648
01:12:20,255 --> 01:12:23,380
OK, þannig að við skulum sía út þau atriði
sem passa ekki þessa tilteknu fyrirspurn.

1649
01:12:23,380 --> 01:12:25,540
Þannig að við höfum sía tjáning.

1650
01:12:25,540 --> 01:12:28,310
>> Sía orðasambönd getur
að keyra á hvaða eiginleiki.

1651
01:12:28,310 --> 01:12:30,260
Þeir eru ekki eins svið fyrirspurnir.

1652
01:12:30,260 --> 01:12:32,690
Hækka fyrirspurnir eru meira vali.

1653
01:12:32,690 --> 01:12:36,470
Sía fyrirspurnir þurfa mig til að fara
fá allt Niðurstöður sett og þá

1654
01:12:36,470 --> 01:12:39,170
móta út gögn sem ég vil ekki.

1655
01:12:39,170 --> 01:12:40,660
Hvers vegna er það mikilvægt?

1656
01:12:40,660 --> 01:12:42,770
Því ég las það allt.

1657
01:12:42,770 --> 01:12:46,597
Í fyrirspurn, ég ætla að lesa og
það er að fara að vera risastór um gögn.

1658
01:12:46,597 --> 01:12:48,430
Og þá er ég að fara að
móta út það sem ég þarf.

1659
01:12:48,430 --> 01:12:52,080
Og ef ég er bara að útskorið út
par af línum, þá er það í lagi.

1660
01:12:52,080 --> 01:12:53,620
Það er ekki svo óhagkvæmt.

1661
01:12:53,620 --> 01:12:57,800
>> En ef ég er að lesa í heild stafli af
gögn, bara til að móta út einn hlut,

1662
01:12:57,800 --> 01:13:01,490
þá er ég að fara að vera betri
burt með ýmsum fyrirspurn,

1663
01:13:01,490 --> 01:13:03,030
vegna þess að það er miklu meira vali.

1664
01:13:03,030 --> 01:13:06,330
Það er að fara að spara mér mikið af
peningar, því ég borga fyrir að lesa.

1665
01:13:06,330 --> 01:13:10,430
Ef niðurstöðurnar sem koma aftur
yfir þessi vír gæti verið minni,

1666
01:13:10,430 --> 01:13:11,890
en ég er að borga fyrir að lesa.

1667
01:13:11,890 --> 01:13:14,340
Svo að skilja hvernig
þú ert að fá gögn.

1668
01:13:14,340 --> 01:13:16,420
Það er mjög mikilvægt í Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Skilyrtum orðasamböndum, þetta er það
þú getur hringt bjartsýnn læsa.

1670
01:13:19,710 --> 01:13:28,470
Update ef til staðar, eða ef þetta gildi
jafngildir það sem ég tilgreina.

1671
01:13:28,470 --> 01:13:31,494
Og ef ég er með tíma stimpil á a
met, ég gæti lesið gögnin.

1672
01:13:31,494 --> 01:13:32,535
Ég gæti breyst þessi gögn.

1673
01:13:32,535 --> 01:13:35,030
Ég gæti farið að skrifa sem
gögn aftur til gagnagrunn.

1674
01:13:35,030 --> 01:13:38,100
Ef einhver hefur breytt met,
timestamp gæti hafa breyst.

1675
01:13:38,100 --> 01:13:40,370
Og þannig skilyrt mín
uppfærsla gæti sagt uppfærslu

1676
01:13:40,370 --> 01:13:42,340
ef timestamp jafngildir þetta.

1677
01:13:42,340 --> 01:13:46,290
Eða uppfærslu mun mistakast vegna þess að einhver
uppfærði met í millitíðinni.

1678
01:13:46,290 --> 01:13:48,290
>> Það er það sem við köllum bjartsýnn læsa.

1679
01:13:48,290 --> 01:13:50,670
Það þýðir að einhver
getur komið í og ​​breyta því,

1680
01:13:50,670 --> 01:13:53,100
og ég ætla að uppgötva það
þegar ég fer aftur að skrifa.

1681
01:13:53,100 --> 01:13:56,106
Og þá get ég í raun að lesa það
gögn og segja, ó, hann breytti þessu.

1682
01:13:56,106 --> 01:13:57,230
Ég þarf að gera grein fyrir því.

1683
01:13:57,230 --> 01:14:00,490
Og ég get breytt upplýsingunum í mínum
taka upp og beita aðra uppfærslu.

1684
01:14:00,490 --> 01:14:04,330
Svo er hægt að ná þeim stigvaxandi
uppfærslur sem eiga sér stað á milli tíma

1685
01:14:04,330 --> 01:14:08,740
að þú lesa gögn og þess
Hvenær sem þú getur skrifað gögn.

1686
01:14:08,740 --> 01:14:11,520
>> Áhorfendur: Og sía
hugtakið þýðir í raun ekki

1687
01:14:11,520 --> 01:14:13,020
í fjölda eða not--

1688
01:14:13,020 --> 01:14:14,316
>> [Interposing raddir]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: Ég mun ekki
fá of mikið inn í þetta.

1690
01:14:16,232 --> 01:14:17,700
Þetta er frátekið leitarorð.

1691
01:14:17,700 --> 01:14:20,130
Pund útsýni er áskilinn
leitarorð í Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Sérhver gagnasafn hefur eigin áskilinn
nöfn og söfn sem þú getur ekki notað.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, ef þú tilgreinir
pund fyrir framan þetta,

1694
01:14:27,240 --> 01:14:29,310
þú getur skilgreint þau nöfn upp hér að ofan.

1695
01:14:29,310 --> 01:14:31,840
Mögulegt er að vísað gildi.

1696
01:14:31,840 --> 01:14:34,880
Það er líklega ekki besta setningafræði til
hafa það upp fyrir þessari umræðu,

1697
01:14:34,880 --> 01:14:38,090
vegna þess að það fær í sumum real--
Ég hefði verið að tala meira

1698
01:14:38,090 --> 01:14:41,360
um það á dýpra stig.

1699
01:14:41,360 --> 01:14:46,130
>> En nægja að segja, þetta gæti
vera fyrirspurn skanna þar sem þeir views--

1700
01:14:46,130 --> 01:14:50,190
né pund skoðanir er meiri en 10.

1701
01:14:50,190 --> 01:14:54,660
Það er tölugildi, já.

1702
01:14:54,660 --> 01:14:57,322
Ef þú vilt, við getum talað um
að eftir umræðu.

1703
01:14:57,322 --> 01:15:00,030
Allt í lagi, þannig að við erum að fá inn
sumum tilfellum í bestu starfsvenjur

1704
01:15:00,030 --> 01:15:02,000
þar sem við erum að fara að tala
um nokkur apps hér.

1705
01:15:02,000 --> 01:15:03,810
Hvað eru nota tilvikum til Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Hvað eru hönnun
mynstur í Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> Og sá fyrsti sem við erum að fara að
tala um er internetið af hlutur.

1708
01:15:09,110 --> 01:15:15,010
Þannig að við fáum mikið of-- ég giska,
hvað er it-- meira en 50%

1709
01:15:15,010 --> 01:15:19,370
af umferð á internetinu þessa dagana
er í raun mynda af vélum,

1710
01:15:19,370 --> 01:15:21,930
sjálfvirkum ferlum, ekki af mönnum.

1711
01:15:21,930 --> 01:15:25,140
Ég meina þetta þetta, sem
þú bera í kring í vasa,

1712
01:15:25,140 --> 01:15:28,840
hversu mikið af gögnum sem þessi hlutur er
í raun að senda kringum án þín

1713
01:15:28,840 --> 01:15:30,550
vitandi það er alveg ótrúlegt.

1714
01:15:30,550 --> 01:15:34,970
Staðsetningu þína, upplýsingar
um hversu hratt þú ert að fara.

1715
01:15:34,970 --> 01:15:38,400
Hvernig finnst þér Google Maps verk
þegar þeir segja þér hvað umferðin er.

1716
01:15:38,400 --> 01:15:41,275
Það er vegna þess að það eru milljón og
milljónir manna að aka í kring

1717
01:15:41,275 --> 01:15:44,667
með síma sem eru að senda
gögn um allan stað allan tímann.

1718
01:15:44,667 --> 01:15:46,500
Svo einn af þeim hlutum
um þessa tegund af gögnum

1719
01:15:46,500 --> 01:15:50,980
sem kemur í, fylgjast með gögnum, skráðu þig
gögn, Tímaraðir gögn, er að það er

1720
01:15:50,980 --> 01:15:53,540
yfirleitt bara áhugavert
fyrir smá tíma.

1721
01:15:53,540 --> 01:15:55,580
Eftir þann tíma, það er
ekki svo áhugavert.

1722
01:15:55,580 --> 01:15:58,390
Þannig að við töluðum um, ekki láta
töflunum vaxa án marka.

1723
01:15:58,390 --> 01:16:03,410
Hugmyndin hér er að kannski ég hef fengið 24
klst virði af atburðum í heitu mitt borð.

1724
01:16:03,410 --> 01:16:06,160
Og það heitt borð er að fara að vera
skilyrtri á mjög hátt hlutfall,

1725
01:16:06,160 --> 01:16:07,950
vegna þess að það tekur a einhver fjöldi af gögnum.

1726
01:16:07,950 --> 01:16:10,920
Það tekur a einhver fjöldi af gögnum
í og ég er að lesa það mikið.

1727
01:16:10,920 --> 01:16:14,560
Ég hef fengið mikið af rekstri
fyrirspurnir í gangi gegn þeim gögnum.

1728
01:16:14,560 --> 01:16:18,120
>> Eftir 24 klukkustundir, hey, þú
Veistu hvað, ég er ekki sama.

1729
01:16:18,120 --> 01:16:21,150
Svo kannski á hverjum miðnætti I rúlla
mitt borð yfir í nýja töflu

1730
01:16:21,150 --> 01:16:22,430
og ég deprovision þessa töflu.

1731
01:16:22,430 --> 01:16:26,440
Og ég ætla að taka RCU er og
WCU er niður vegna 24 tímum síðar

1732
01:16:26,440 --> 01:16:28,630
Ég er ekki í gangi eins og margir
fyrirspurnir gegn þessum gögnum.

1733
01:16:28,630 --> 01:16:30,200
Þannig að ég ætla að fara að spara peninga.

1734
01:16:30,200 --> 01:16:32,940
Og kannski 30 dögum síðar var ég ekki
jafnvel þurfa að hugsa um það allt.

1735
01:16:32,940 --> 01:16:35,020
Ég gæti tekið að WCU er
alla leið niður í eitt,

1736
01:16:35,020 --> 01:16:36,990
vegna þess að þú veist hvað, það er
aldrei að fara að fá skrifað á.

1737
01:16:36,990 --> 01:16:38,300
Gögnin er 30 daga gömul.

1738
01:16:38,300 --> 01:16:40,000
Það breytist aldrei.

1739
01:16:40,000 --> 01:16:44,200
>> Og það er nánast aldrei að fara að fá að lesa,
þannig að við skulum bara taka þessi RCU niður í 10.

1740
01:16:44,200 --> 01:16:49,372
Og ég er að safna a tonn af peningar á þetta
gögn, og aðeins að borga fyrir heita gögnum mínum.

1741
01:16:49,372 --> 01:16:52,330
Svo er það mikilvægast að líta
á þegar þú horfir á tímaröð

1742
01:16:52,330 --> 01:16:54,716
gögn koma í í bindi.

1743
01:16:54,716 --> 01:16:55,590
Þetta eru aðferðir.

1744
01:16:55,590 --> 01:16:58,010
Nú, ég gat bara láta það
allir til sama borð

1745
01:16:58,010 --> 01:16:59,461
og bara láta það borð vaxa.

1746
01:16:59,461 --> 01:17:01,460
Að lokum, ég ætla að
sjá árangur málefni.

1747
01:17:01,460 --> 01:17:04,060
Ég ætla að hafa til að byrja að geyma
sumir af þessum gögnum út af borðinu,

1748
01:17:04,060 --> 01:17:04,720
hvað ekki.

1749
01:17:04,720 --> 01:17:07,010
>> Skulum miklu betra
hanna umsókn þína

1750
01:17:07,010 --> 01:17:08,900
þannig að þú getur starfað með þessum hætti rétt.

1751
01:17:08,900 --> 01:17:11,460
Svo það er bara sjálfvirkt
í kóða forritsins.

1752
01:17:11,460 --> 01:17:13,580
Á miðnætti á hverju kvöldi
það rúlla borðið.

1753
01:17:13,580 --> 01:17:17,170
Kannski það sem ég þarf er að renna
glugga 24 klukkustundir af gögnum.

1754
01:17:17,170 --> 01:17:20,277
Þá reglulega ég
kalla gögn út af borðinu.

1755
01:17:20,277 --> 01:17:22,360
Ég snyrtur með
Cron starf og ég er að setja það

1756
01:17:22,360 --> 01:17:24,160
á þessum öðrum borðum,
hvað þú þarft.

1757
01:17:24,160 --> 01:17:25,940
Svo ef rollover virkar, það er frábært.

1758
01:17:25,940 --> 01:17:27,080
Ef ekki, klippt það.

1759
01:17:27,080 --> 01:17:29,640
En við skulum halda að heita gögn
burt frá köldum gögnunum.

1760
01:17:29,640 --> 01:17:32,535
Það mun spara þér mikið af peningum og
gera töflur meira skila.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Svo the næstur hlutur sem við munum tala
um er vörulisti.

1763
01:17:38,210 --> 01:17:42,000
Vörulisti er
nokkuð algengt nota málið.

1764
01:17:42,000 --> 01:17:46,600
Þetta er í raun mjög algengt mynstur
sem við munum sjá í ýmsum hlutum.

1765
01:17:46,600 --> 01:17:48,870
Þú veist, Twitter fyrir
dæmi, heitt kvak.

1766
01:17:48,870 --> 01:17:51,280
Allir er að koma og
grabbing að kvak.

1767
01:17:51,280 --> 01:17:52,680
Vörulisti, ég fékk sölu.

1768
01:17:52,680 --> 01:17:54,120
Ég fékk heitt sölu.

1769
01:17:54,120 --> 01:17:57,277
Ég fékk 70.000 beiðnir á
endurkomu fyrir vöru

1770
01:17:57,277 --> 01:17:58,860
lýsing úr verslun vöru mína.

1771
01:17:58,860 --> 01:18:02,384
Við sjáum þetta á smásölu
Rekstur töluvert.

1772
01:18:02,384 --> 01:18:03,550
Svo hvernig gera við að takast á við það?

1773
01:18:03,550 --> 01:18:04,924
Það er engin leið til að takast á við það.

1774
01:18:04,924 --> 01:18:07,110
Allir notendur mínir vilja sjá
á sama stykki af gögnum.

1775
01:18:07,110 --> 01:18:09,410
Þeir eru eru að koma í, samtímis.

1776
01:18:09,410 --> 01:18:11,920
Og þeir eru allir að gera beiðnir
fyrir sama stykki af gögn.

1777
01:18:11,920 --> 01:18:16,240
Þetta gefur mér að heitur lykill, sem stór rauður
rönd á töfluna mína sem við gerum ekki eins.

1778
01:18:16,240 --> 01:18:17,720
Og það er það sem það lítur út.

1779
01:18:17,720 --> 01:18:22,290
Svo yfir helstu my space ég er að fá
hammered í sölu atriði.

1780
01:18:22,290 --> 01:18:24,070
Ég fæ ekkert annars staðar.

1781
01:18:24,070 --> 01:18:26,050
>> Hvernig get ég draga úr þessum vanda?

1782
01:18:26,050 --> 01:18:28,410
Jæja, draga við þetta með skyndiminni.

1783
01:18:28,410 --> 01:18:33,630
Cache, þú setur í grundvallaratriðum í minni
skipting framan gagnagrunninum.

1784
01:18:33,630 --> 01:18:37,260
Okkur hefur tekist
[Inaudible] skyndiminni, hvernig þér

1785
01:18:37,260 --> 01:18:40,260
getur sett upp eigin skyndiminni, [inaudible]
skyndiminni [? d,?] hvað sem þú vilt.

1786
01:18:40,260 --> 01:18:42,220
Setja það upp fyrir framan gagnagrunninum.

1787
01:18:42,220 --> 01:18:47,250
Og þannig að þú getur geymt þessi gögn
frá þeim heitum lyklana upp í því skyndiminni

1788
01:18:47,250 --> 01:18:49,390
rúm og lesa í gegnum skyndiminni.

1789
01:18:49,390 --> 01:18:51,962
>> Og þá mest af þínum les
byrja að leita svona.

1790
01:18:51,962 --> 01:18:54,920
Ég fékk allt þetta skyndiminni hits upp hér
og ég fékk ekkert að gerast hérna

1791
01:18:54,920 --> 01:18:59,330
vegna gagnasafn situr á bak við
skyndiminni og les aldrei koma í gegnum.

1792
01:18:59,330 --> 01:19:02,520
Ef ég breyti gögnunum í
gagnagrunnur, ég verð að uppfæra skyndiminni.

1793
01:19:02,520 --> 01:19:04,360
Við getum notað eitthvað
eins steams að gera það.

1794
01:19:04,360 --> 01:19:07,360
Og ég skal útskýra hvernig það virkar.

1795
01:19:07,360 --> 01:19:09,060
Allt í lagi, skilaboð.

1796
01:19:09,060 --> 01:19:11,180
Email notum við öll email.

1797
01:19:11,180 --> 01:19:12,540
>> Þetta er nokkuð gott dæmi.

1798
01:19:12,540 --> 01:19:14,950
Við höfum fengið einhverskonar skilaboð borð.

1799
01:19:14,950 --> 01:19:17,040
Og við fengum innhólf og úthólf.

1800
01:19:17,040 --> 01:19:19,760
Þetta er það sem SQL myndi
líta út eins og að byggja þessi pósthólfið.

1801
01:19:19,760 --> 01:19:23,350
Við konar nota sams konar
af stefnu að nota GSI er, GSI er

1802
01:19:23,350 --> 01:19:25,320
fyrir pósthólfið mitt og úthólfinu mínu.

1803
01:19:25,320 --> 01:19:27,600
Svo fékk ég hrátt skilaboð koma
í skilaboð mitt borð.

1804
01:19:27,600 --> 01:19:30,194
Og fyrsta nálgun að þessu
gæti verið, segja, OK, ekkert vandamál.

1805
01:19:30,194 --> 01:19:31,110
Ég hef fengið hrátt skilaboð.

1806
01:19:31,110 --> 01:19:33,710
Skilaboðum [inaudible],
Skilaboð ID, sem er frábært.

1807
01:19:33,710 --> 01:19:35,070
Það er einstakt kjötkássa minn.

1808
01:19:35,070 --> 01:19:38,280
Ég ætla að búa til tvær GSI, einn
fyrir pósthólfið mitt, eitt fyrir úthólfinu mínu.

1809
01:19:38,280 --> 01:19:40,530
Og það fyrsta sem ég mun gera
er ég segi kjötkássa lykillinn minn er

1810
01:19:40,530 --> 01:19:43,310
að fara að vera viðtakandi og
Ég ætla að raða á þeim degi.

1811
01:19:43,310 --> 01:19:44,220
Þetta er frábært.

1812
01:19:44,220 --> 01:19:45,890
Ég fékk gott útsýni mitt hér.

1813
01:19:45,890 --> 01:19:47,780
En það er smá mál hér.

1814
01:19:47,780 --> 01:19:50,891
Og þú keyrir inn í þetta í
Vensla gagnagrunna eins og heilbrigður.

1815
01:19:50,891 --> 01:19:52,390
Þeir kölluðu lóðrétt skipting.

1816
01:19:52,390 --> 01:19:55,840
Þú vilt halda stóra gögnum
frá litlu gögnunum.

1817
01:19:55,840 --> 01:20:00,470
>> Og ástæðan fyrir því er vegna þess að ég verð að
fara lesa atriði til að fá eiginleika.

1818
01:20:00,470 --> 01:20:05,570
Og ef aðilar mínir eru allir á hér,
þá lesa bara nokkur atriði

1819
01:20:05,570 --> 01:20:08,560
ef Lengdin minn er
meðaltali 256 kílóbæti hvor,

1820
01:20:08,560 --> 01:20:10,991
stærðfræði fær ansi ljót.

1821
01:20:10,991 --> 01:20:12,490
Svo segi ég að lesa pósthólfið Davíðs.

1822
01:20:12,490 --> 01:20:14,520
Innanborðs Davíðs hefur 50 atriði.

1823
01:20:14,520 --> 01:20:17,880
Meðaltal og stærð er 256 kílóbæti.

1824
01:20:17,880 --> 01:20:21,730
Hér er ummyndun hlutfall mitt
fyrir RCU er fjögur kílóbæti.

1825
01:20:21,730 --> 01:20:24,450
>> OK, við skulum fara með
loksins samræmi les.

1826
01:20:24,450 --> 01:20:28,640
Ég er enn að borða 1.600 RCU er
bara að lesa pósthólfið Davíðs.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
OK, nú skulum hugsa
um hvernig app virkar.

1829
01:20:31,980 --> 01:20:35,340
Ef ég er í email app og
Ég er að horfa á pósthólfinu mínu,

1830
01:20:35,340 --> 01:20:39,680
og ég lít á líkama hvert skeyti,
nei, ég er að horfa á samantektir.

1831
01:20:39,680 --> 01:20:41,850
Ég er að horfa á aðeins haus.

1832
01:20:41,850 --> 01:20:46,310
Svo skulum byggja borð uppbygging
sem lítur meira eins og þessi.

1833
01:20:46,310 --> 01:20:49,470
>> Svo hér er upplýsingar
að workflow minn þarf.

1834
01:20:49,470 --> 01:20:50,890
Það er í pósthólfinu mínu GSI.

1835
01:20:50,890 --> 01:20:53,800
Það er dagsetning, sendanda,
efni, og þá

1836
01:20:53,800 --> 01:20:56,790
ID boðskapur, sem bendir
aftur til skilaboða töflu

1837
01:20:56,790 --> 01:20:57,850
hvar ég get fengið líkamann.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Jæja, þetta væri met auðkenni.

1840
01:21:04,420 --> 01:21:09,850
Þeir myndu benda aftur til
Liðurinn auðkenni á Dynamo DB borð.

1841
01:21:09,850 --> 01:21:12,220
Sérhver Vísitala alltaf creates--
alltaf hefur hlutinn

1842
01:21:12,220 --> 01:21:15,750
ID sem hluta of-- að
kemur með vísitölu.

1843
01:21:15,750 --> 01:21:17,414
>> Allt í lagi.

1844
01:21:17,414 --> 01:21:19,080
Áhorfendur: Það segir það þar sem það er geymt?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Já, það segir
exactly-- það er einmitt það sem það gerir.

1846
01:21:21,420 --> 01:21:22,644
Það segir hér er aftur met mitt.

1847
01:21:22,644 --> 01:21:24,310
Og það skal benda hana aftur hljómplata minn.

1848
01:21:24,310 --> 01:21:26,460
Nákvæmlega.

1849
01:21:26,460 --> 01:21:29,490
OK, svo nú er pósthólfið mitt
reyndar mun minni.

1850
01:21:29,490 --> 01:21:32,210
Og þetta í raun styður
workflow af tölvupósti app.

1851
01:21:32,210 --> 01:21:34,230
Svo pósthólfinu mínu, ég smelli.

1852
01:21:34,230 --> 01:21:38,160
Ég fer eftir og ég smelli á skilaboðin,
það er þegar ég þarf að fara að fá líkamann,

1853
01:21:38,160 --> 01:21:40,180
vegna þess að ég ætla að
fara í aðra sýn.

1854
01:21:40,180 --> 01:21:43,870
Svo ef þér finnst um MVC tegund
ramma, líkan skoða stjórnandi.

1855
01:21:43,870 --> 01:21:46,120
>> Líkanið inniheldur
gögn að skoða þarfir

1856
01:21:46,120 --> 01:21:48,130
og stjórnandi í samskiptum við.

1857
01:21:48,130 --> 01:21:51,670
Þegar ég breytt ramma, þegar
Ég breyta sjónarhorni,

1858
01:21:51,670 --> 01:21:55,080
það er í lagi að fara aftur til
miðlara og endumema líkan,

1859
01:21:55,080 --> 01:21:56,860
því það er það sem notandinn ætlast.

1860
01:21:56,860 --> 01:22:00,530
Þegar þeir breytt skoðunum, það er þegar
við getum farið aftur að gagnagrunninum.

1861
01:22:00,530 --> 01:22:02,480
Svo email, smelltu.

1862
01:22:02,480 --> 01:22:03,710
Ég er að leita fyrir líkamann.

1863
01:22:03,710 --> 01:22:04,330
Hringferð.

1864
01:22:04,330 --> 01:22:05,680
Go fá líkamann.

1865
01:22:05,680 --> 01:22:06,950
>> Ég las mikið minna gögnum.

1866
01:22:06,950 --> 01:22:09,960
Ég er bara að lesa þá aðila sem
David þarf þegar hann þarf á þeim að.

1867
01:22:09,960 --> 01:22:14,230
Og ég er ekki að brenna í 1600
RCU er bara að sýna pósthólfið hans.

1868
01:22:14,230 --> 01:22:17,670
Svo nú that-- þetta er leiðin
sem LSI eða GSI-- Fyrirgefðu,

1869
01:22:17,670 --> 01:22:19,900
GSI, myndi vinna út.

1870
01:22:19,900 --> 01:22:25,450
Við höfum fengið kjötkássa okkar á viðtakanda.

1871
01:22:25,450 --> 01:22:27,030
Við höfum fengið svið takkann á þeim degi.

1872
01:22:27,030 --> 01:22:31,380
Og við höfum fengið varpað eiginleika
að við þurfum aðeins að styðja þá skoðun.

1873
01:22:31,380 --> 01:22:34,300
>> Við snúa að fyrir úthólfinu.

1874
01:22:34,300 --> 01:22:35,770
Hash á sendanda.

1875
01:22:35,770 --> 01:22:39,612
Og í raun, við höfum
mjög gott, hreint útsýni.

1876
01:22:39,612 --> 01:22:41,570
Og það er basically-- við
hafa þennan flotta skilaboð

1877
01:22:41,570 --> 01:22:45,870
borð sem er verið að dreifa vel vegna
það er kjötkássa aðeins tætt skilaboð ID.

1878
01:22:45,870 --> 01:22:51,750
Og við höfum tvo vísitölur sem
eru snúningur burt af þeirri töflu.

1879
01:22:51,750 --> 01:22:57,411
Allt í lagi, svo hugmynd hér er ekki
halda stór gögn og þessa litlu gögn

1880
01:22:57,411 --> 01:22:57,910
saman.

1881
01:22:57,910 --> 01:23:00,700
Skipting lóðrétt,
skipta þeim töflum.

1882
01:23:00,700 --> 01:23:03,150
Ekki lesa gögn sem þú þarft ekki að.

1883
01:23:03,150 --> 01:23:04,850
Allt í lagi, gaming.

1884
01:23:04,850 --> 01:23:06,990
Við eins og allir leikir.

1885
01:23:06,990 --> 01:23:10,902
Að minnsta kosti ég eins leikjum þá.

1886
01:23:10,902 --> 01:23:12,735
Svo sumir af þeim hlutum
að við að takast á við þegar

1887
01:23:12,735 --> 01:23:14,193
við erum að hugsa um gaming, ekki satt?

1888
01:23:14,193 --> 01:23:16,999
Gaming þessa dagana, sérstaklega farsíma
gaming, er allt um hugsun.

1889
01:23:16,999 --> 01:23:19,540
Og ég ætla að snúa hér
svolítið í burtu frá DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Ég ætla að koma með í
sumir af umræðu

1891
01:23:21,373 --> 01:23:24,240
um sumir af the
önnur AWS tækni.

1892
01:23:24,240 --> 01:23:28,930
>> En hugmyndin um gaming er að hugsa
um hvað varðar API, API sem eru,

1893
01:23:28,930 --> 01:23:31,730
almennt séð, HTTP og JSON.

1894
01:23:31,730 --> 01:23:34,550
Það er hvernig farsíma leikir konar
samskipti við bak endunum.

1895
01:23:34,550 --> 01:23:35,850
Þeir gera JSON staða.

1896
01:23:35,850 --> 01:23:40,660
Þeir fá gögn, og það er allt,
almennt séð, í fallegu API JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Hluti eins og að fá vini, fá
Topplistinn, skiptast á upplýsingum,

1898
01:23:44,950 --> 01:23:47,699
notandi mynda efni,
ýta aftur upp til the kerfi,

1899
01:23:47,699 --> 01:23:49,740
þetta eru tegundir af hlutum
sem við erum að fara að gera.

1900
01:23:49,740 --> 01:23:52,542
Tvöfaldur eign gögn, þessi gögn
gæti ekki setið í dag.

1901
01:23:52,542 --> 01:23:54,250
Þetta gæti sitja í
hlut verslun, ekki satt?

1902
01:23:54,250 --> 01:23:56,541
En gagnagrunnurinn er að fara að
á endanum að segja kerfið,

1903
01:23:56,541 --> 01:23:59,140
segja umsókn
hvar á að fara að fá það.

1904
01:23:59,140 --> 01:24:03,550
Og óhjákvæmilega, multiplayer
netþjónum bak endir innviði,

1905
01:24:03,550 --> 01:24:06,180
og hannað fyrir hár
framboð og sveigjanleika.

1906
01:24:06,180 --> 01:24:09,400
Svo þetta eru hlutir sem við viljum öll
í gaming innviði dag.

1907
01:24:09,400 --> 01:24:12,160
>> Svo skulum taka a líta á
hvað það lítur út.

1908
01:24:12,160 --> 01:24:16,070
Fékk algerlega aftur enda,
mjög einfalt.

1909
01:24:16,070 --> 01:24:19,880
Við höfum fengið kerfi hér með
margar framboð svæði.

1910
01:24:19,880 --> 01:24:23,780
Við ræddum um AZS sem being-- hugsa
þeirra sem sjálfstæðar gagnaver.

1911
01:24:23,780 --> 01:24:26,040
Fleiri en einn gagna
á AZ, en það er allt í lagi,

1912
01:24:26,040 --> 01:24:28,831
bara hugsa um þá sem aðskilin gögn
miðstöðvar sem eru landfræðilega

1913
01:24:28,831 --> 01:24:30,090
og kenna einangruð.

1914
01:24:30,090 --> 01:24:32,172
>> Við erum að fara að hafa
par EC2 tilvikum.

1915
01:24:32,172 --> 01:24:33,880
Við erum að fara að hafa
sumir aftur endir framreiðslumaður.

1916
01:24:33,880 --> 01:24:35,800
Kannski ef þú ert a arfur
arkitektúr, við erum

1917
01:24:35,800 --> 01:24:38,920
með það sem við köllum RDS,
Venslagagnagrunnur þjónustu.

1918
01:24:38,920 --> 01:24:42,040
Gæti verið MSSQL, MySQL,
eða eitthvað svoleiðis.

1919
01:24:42,040 --> 01:24:47,080
Þetta er hátt og mikið umsóknir
eru hönnuð í dag.

1920
01:24:47,080 --> 01:24:49,594
>> Jæja við might vilja til að fara með
þetta er þegar við skala út.

1921
01:24:49,594 --> 01:24:51,510
Við munum fara á undan og setja
S3 fötu þarna.

1922
01:24:51,510 --> 01:24:54,200
Og það S3 fötu í stað þess að þjóna
upp þeim hlutum frá servers-- okkar

1923
01:24:54,200 --> 01:24:55,220
við gætum gert það.

1924
01:24:55,220 --> 01:24:57,210
Þú setur alla tvöfaldur þitt
hlutir á þjónum þínum

1925
01:24:57,210 --> 01:24:59,751
og þú getur notað þá miðlara
dæmi til að þjóna sem gögn upp.

1926
01:24:59,751 --> 01:25:01,860
En það er frekar dýrt.

1927
01:25:01,860 --> 01:25:05,107
>> Betri leið til að gera er að fara á undan og
setja þá hluti í S3 fötu.

1928
01:25:05,107 --> 01:25:06,315
S3 er hlutur geymsla.

1929
01:25:06,315 --> 01:25:10,860
Það er byggt sérstaklega fyrir
þjóna upp þessar tegundir af hlutum.

1930
01:25:10,860 --> 01:25:13,690
Og láta þá viðskiptavini beiðni
beint frá þeim hlut fötunum,

1931
01:25:13,690 --> 01:25:15,390
selja netþjóna.

1932
01:25:15,390 --> 01:25:17,020
Þannig að við erum að byrja að skala út hér.

1933
01:25:17,020 --> 01:25:19,140
>> Nú fengum notendur um allan heim.

1934
01:25:19,140 --> 01:25:19,730
Ég fékk notendur.

1935
01:25:19,730 --> 01:25:23,380
Ég þarf að hafa efni á staðnum
staðsett nálægt þessum notendum, ekki satt?

1936
01:25:23,380 --> 01:25:26,200
Ég hef búið til S3 fötu
sem uppspretta geymsla minn.

1937
01:25:26,200 --> 01:25:29,370
Og ég ætla að framan að með
sem CloudFront dreifingu.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront er CD og
innihald sending net.

1939
01:25:31,720 --> 01:25:35,750
Í grundvallaratriðum tekur það gögn sem þú tilgreinir
og felustaður það allt í gegnum netið

1940
01:25:35,750 --> 01:25:39,230
svo notendur alls staðar er hægt að hafa
mjög fljótur viðbrögð þegar

1941
01:25:39,230 --> 01:25:40,960
þeir óska ​​þá hluti.

1942
01:25:40,960 --> 01:25:41,960
>> Þannig að þú færð hugmynd.

1943
01:25:41,960 --> 01:25:48,230
Þú ert góður af fá meira alla
þætti AWS hér til að fá það gert.

1944
01:25:48,230 --> 01:25:50,790
Og að lokum, henda okkur
með sjálfvirkri stigstærð hóp.

1945
01:25:50,790 --> 01:25:52,737
Svo AC2 tilvikum okkar
af leiknum netþjónum okkar,

1946
01:25:52,737 --> 01:25:54,820
og þeir byrja að fá uppflettingar
og viðskipti og viðskipti,

1947
01:25:54,820 --> 01:25:57,236
þeir ætla bara að snúast annað
dæmi, snúast annað dæmi,

1948
01:25:57,236 --> 01:25:58,210
snúast annað dæmi.

1949
01:25:58,210 --> 01:26:02,090
Svo tækni AWS hefur, það
gerir þér kleift að tilgreina breytur

1950
01:26:02,090 --> 01:26:04,650
kring sem netþjónum mun vaxa.

1951
01:26:04,650 --> 01:26:08,110
Svo er hægt að hafa n fjölda netþjóna
þarna úti á hverjum tíma.

1952
01:26:08,110 --> 01:26:11,870
Og ef álag fer í burtu, þeir '
skreppa saman, tala vilja skreppa.

1953
01:26:11,870 --> 01:26:15,250
Og ef álag kemur aftur,
það verður að vaxa aftur út, teygjanlega.

1954
01:26:15,250 --> 01:26:17,050
>> Svo lítur þetta vel út.

1955
01:26:17,050 --> 01:26:19,800
Við höfum fengið mikið af EC2 tilvikum.

1956
01:26:19,800 --> 01:26:21,671
Við getum sett skyndiminni
framan gagnagrunna,

1957
01:26:21,671 --> 01:26:23,045
reyna að flýta gagnagrunna.

1958
01:26:23,045 --> 01:26:25,030
Næsta þrýstingur benda
yfirleitt fólk sjá

1959
01:26:25,030 --> 01:26:28,850
er þeir hækka leik með
Venslagagnagrunnur kerfi.

1960
01:26:28,850 --> 01:26:30,790
Jeez, gagnasafn
árangur er hræðileg.

1961
01:26:30,790 --> 01:26:31,932
Hvernig eigum við að bæta það?

1962
01:26:31,932 --> 01:26:33,640
Við skulum reyna að setja
skyndiminni fyrir framan það.

1963
01:26:33,640 --> 01:26:36,780
>> Jæja, skyndiminni virkar ekki
svo mikill í leikjum, ekki satt?

1964
01:26:36,780 --> 01:26:39,330
Fyrir leiki, skrifa er sársaukafullt.

1965
01:26:39,330 --> 01:26:40,930
Leikir eru mjög skrifa þungur.

1966
01:26:40,930 --> 01:26:43,610
Cache virkar ekki þegar þú ert
skrifa þungur vegna þess að þú hefur alltaf

1967
01:26:43,610 --> 01:26:44,610
fékk að uppfæra skyndiminni.

1968
01:26:44,610 --> 01:26:47,780
Þú uppfæra skyndiminni, það er
óviðkomandi að flýtiminni.

1969
01:26:47,780 --> 01:26:49,780
Það er í raun bara auka vinna.

1970
01:26:49,780 --> 01:26:51,970
>> Svo þar sem við förum hér?

1971
01:26:51,970 --> 01:26:54,400
Þú hefur got a stór flöskuháls
þarna niðri í dag.

1972
01:26:54,400 --> 01:26:57,661
Og staður til að fara
augljóslega er skipting.

1973
01:26:57,661 --> 01:26:59,410
Skipting er ekki
auðvelt að gera þegar þú ert

1974
01:26:59,410 --> 01:27:01,900
að takast á við Vensla gagnagrunna.

1975
01:27:01,900 --> 01:27:05,080
Með Vensla gagnagrunna, þú ert
ábyrgð á að stjórna, í raun,

1976
01:27:05,080 --> 01:27:06,210
lykillinn pláss.

1977
01:27:06,210 --> 01:27:10,527
Þú ert að segja notendur milli A og M
fara hér, milli N og Z fara þangað.

1978
01:27:10,527 --> 01:27:12,360
Og þú ert að skipta
yfir umsókn.

1979
01:27:12,360 --> 01:27:15,000
Svo þú ert að takast á við
þessi skipting gögn uppspretta.

1980
01:27:15,000 --> 01:27:18,670
Þú ert viðskiptalegs þvingun
sem ekki span skipting.

1981
01:27:18,670 --> 01:27:20,560
Þú hefur fengið allar tegundir af
messiness að þú ert

1982
01:27:20,560 --> 01:27:23,040
að takast á við þarna niðri að reyna
að takast á við stigstærð út

1983
01:27:23,040 --> 01:27:25,120
og byggja upp stærri innviði.

1984
01:27:25,120 --> 01:27:27,284
Það er bara ekkert gaman.

1985
01:27:27,284 --> 01:27:30,930
>> Áhorfendur: Svo þú ert að segja að
auka uppspretta stig hraða upp

1986
01:27:30,930 --> 01:27:31,430
ferlið?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Aukin?

1988
01:27:32,513 --> 01:27:33,520
Áhorfendur: Heimild stig.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Source stig?

1990
01:27:34,410 --> 01:27:37,500
Áhorfendur: Frá upplýsingar
þar sem upplýsingar er að koma frá?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: Nei

1992
01:27:38,250 --> 01:27:41,820
Það sem ég er að segja er að hækka
Fjöldi skipting í gögn geyma

1993
01:27:41,820 --> 01:27:44,060
bætir afköst.

1994
01:27:44,060 --> 01:27:48,300
Svo er það sem er að gerast hér notendur
koma inn í EC2 dæmis upp hér,

1995
01:27:48,300 --> 01:27:50,780
vel, ef ég þarf notandi
Það er til M, ég fer hér.

1996
01:27:50,780 --> 01:27:53,560
Frá N til p, ég fer hér.

1997
01:27:53,560 --> 01:27:55,060
Frá P til Z, ég fer hér.

1998
01:27:55,060 --> 01:27:57,120
>> Áhorfendur: OK, þá þannig að þeir eru
allt geymt í mismunandi hnútar?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Já.

2000
01:27:57,911 --> 01:28:00,210
Hugsaðu um þetta eins og
mismunandi síló af gögnum.

2001
01:28:00,210 --> 01:28:01,660
Svo þú ert að þurfa að gera þetta.

2002
01:28:01,660 --> 01:28:02,910
Ef þú ert að reyna að gera
þetta, ef þú ert að reyna

2003
01:28:02,910 --> 01:28:05,730
að skala á samræmdum vettvang,
þetta er það sem þú ert að gera.

2004
01:28:05,730 --> 01:28:08,100
Þú ert að taka gögn og
þú ert að skera það niður.

2005
01:28:08,100 --> 01:28:10,975
Og þú ert að sneiða það yfir
margfeldi dæmi af gagnagrunninum.

2006
01:28:10,975 --> 01:28:13,580
Og þú ert að stjórna öllu sem
á umsókn flokkaupplýsingar.

2007
01:28:13,580 --> 01:28:14,729
Það er ekki gaman.

2008
01:28:14,729 --> 01:28:15,770
Svo hvað við viljum fara?

2009
01:28:15,770 --> 01:28:20,240
Við viljum fara DynamoDB, fullkomlega tekist,
NoSQL gögn geyma ákvæði afköst.

2010
01:28:20,240 --> 01:28:22,680
Við notum efri stuðla.

2011
01:28:22,680 --> 01:28:26,154
Það er í grundvallaratriðum HTTP API og
felur skjal stuðning.

2012
01:28:26,154 --> 01:28:28,570
Svo þú þarft ekki að hafa áhyggjur
um neitt af þessu skipting.

2013
01:28:28,570 --> 01:28:30,740
Við gerum það fyrir þig.

2014
01:28:30,740 --> 01:28:33,260
Svo nú, í stað þess, þú
bara skrifa að borðinu.

2015
01:28:33,260 --> 01:28:36,490
Ef borðið þarf að vera skipt,
sem gerist á bak við tjöldin.

2016
01:28:36,490 --> 01:28:40,642
Þú ert alveg einangruð
frá því sem verktaki.

2017
01:28:40,642 --> 01:28:42,350
Svo skulum við tala um
sum nota tilvikum

2018
01:28:42,350 --> 01:28:47,564
að við að keyra inn í gaming, algengar
gaming atburðarás, Topplistinn.

2019
01:28:47,564 --> 01:28:49,980
Svo þú hefur fengið notendur koma í,
að BoardNames að þeir séu

2020
01:28:49,980 --> 01:28:52,930
á, skorar fyrir þennan notanda.

2021
01:28:52,930 --> 01:28:57,700
Vér hass á UserId,
og þá höfum við mikinn á leikinn.

2022
01:28:57,700 --> 01:28:59,960
Svo í hvert notandinn vill sjá
allt leikur hann lék

2023
01:28:59,960 --> 01:29:01,770
og allt hans stigamet
yfir öllum leiknum.

2024
01:29:01,770 --> 01:29:04,000
Svo er það persónuleg Topplistinn hans.

2025
01:29:04,000 --> 01:29:10,010
>> Nú vil ég að fara í og ​​ég vil get--
þannig að ég fá þessar persónulega leaderboards.

2026
01:29:10,010 --> 01:29:12,827
Það sem ég vil gera er að fara að fá
efst skora yfir alla notendur.

2027
01:29:12,827 --> 01:29:13,660
Svo hvernig á ég að gera það?

2028
01:29:13,660 --> 01:29:18,070
Þegar vitnisburður minn er tætt á
sem UserId, var á bilinu á leiknum,

2029
01:29:18,070 --> 01:29:20,740
jæja ég ætla að fara á undan
og endurskipuleggja, búa til GSI,

2030
01:29:20,740 --> 01:29:22,370
og ég ætla að endurskipuleggja þessi gögn.

2031
01:29:22,370 --> 01:29:27,310
>> Nú ætla ég að kjötkássa á
BoardName, sem er leikur.

2032
01:29:27,310 --> 01:29:29,800
Og ég ætla að svið á efsta stig.

2033
01:29:29,800 --> 01:29:31,540
Og nú hef ég búið til mismunandi hópa.

2034
01:29:31,540 --> 01:29:34,790
Ég er að nota sama borð,
sama hlut gögn.

2035
01:29:34,790 --> 01:29:39,870
En ég er að búa til fötu sem gefur
mér samansafn af stigamet eftir leik.

2036
01:29:39,870 --> 01:29:43,180
>> Og ég get fyrirspurn borðið
til að fá þær upplýsingar.

2037
01:29:43,180 --> 01:29:50,890
Þannig að ég hef sett það fyrirspurn mynstur upp
vera studd af efri vísitölu.

2038
01:29:50,890 --> 01:29:54,556
Nú eru þeir geta vera flokkaður eftir BoardName
og er flokkaður eftir TopScore eftir.

2039
01:29:54,556 --> 01:29:57,180
Svo þú sérð, eru þessar tegundir
tilvika nota færðu í gaming.

2040
01:29:57,180 --> 01:30:02,190
Annar góður nota málið sem við fáum í gaming
er verðlaun og hver er vann verðlaun.

2041
01:30:02,190 --> 01:30:05,340
Og þetta er frábær nota málið
þar sem við köllum rýr stuðla.

2042
01:30:05,340 --> 01:30:07,340
Dreifður Vísitölur eru
getu til að búa til

2043
01:30:07,340 --> 01:30:10,850
vísitölu sem þýðir ekki endilega
innihalda hvert einasta atriði á borð.

2044
01:30:10,850 --> 01:30:11,470
Og hvers vegna ekki?

2045
01:30:11,470 --> 01:30:14,540
Þar sem eiginleiki sem er að vera
verðtryggð er ekki til á hverjum lið.

2046
01:30:14,540 --> 01:30:16,460
>> Svo í þessu tiltekna
nota málið, ég er að segja,

2047
01:30:16,460 --> 01:30:19,240
þú veist hvað, ég ætla að
búa eigindi sem heitir Award.

2048
01:30:19,240 --> 01:30:22,970
Og ég ætla að gefa öllum notendum
sem hefur verðlaun sem eigindi.

2049
01:30:22,970 --> 01:30:25,950
Notendur sem hafa ekki verðlaun eru
ekki að fara að hafa þessi eiginleiki.

2050
01:30:25,950 --> 01:30:27,800
Svo þegar ég bý í
Vísitala, aðeins notendur

2051
01:30:27,800 --> 01:30:28,960
sem eru að fara að sýna
upp á vísitölunni eru

2052
01:30:28,960 --> 01:30:31,050
þau sem í raun hafa unnið til verðlauna.

2053
01:30:31,050 --> 01:30:34,440
Svo er það frábær leið til að vera fær um
til að búa til síaðar vísitölur sem

2054
01:30:34,440 --> 01:30:40,580
eru mjög, mjög sértækur sem ekki
að kemba allt borðið.

2055
01:30:40,580 --> 01:30:43,050
>> Þannig að við erum að fá lágt á tíma hér.

2056
01:30:43,050 --> 01:30:49,190
Ég ætla að fara á undan og sleppa
út og sleppa þessu tilviki.

2057
01:30:49,190 --> 01:30:52,625
Tala svolítið about--

2058
01:30:52,625 --> 01:30:54,460
>> Áhorfendur: Má ég spyrja fljótur spurningu?

2059
01:30:54,460 --> 01:30:56,722
Eitt er að skrifa þungur?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Hvað er?

2061
01:30:57,680 --> 01:30:58,596
Áhorfendur: Skrifa þungur.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Skrifa þungur.

2063
01:31:01,270 --> 01:31:03,460
Leyfðu mér að sjá.

2064
01:31:03,460 --> 01:31:06,220
>> Áhorfendur: Eða er það ekki
eitthvað sem þú getur bara

2065
01:31:06,220 --> 01:31:08,809
rödd í nokkrum sekúndum?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Við förum
gegnum atkvæðagreiðslu atburðarás.

2067
01:31:10,850 --> 01:31:11,670
Það er ekki svo slæmt.

2068
01:31:11,670 --> 01:31:14,580
Gera þú krakkar hafa nokkrar mínútur?

2069
01:31:14,580 --> 01:31:15,860
OK.

2070
01:31:15,860 --> 01:31:17,890
>> Þannig að við munum tala um atkvæðagreiðslu.

2071
01:31:17,890 --> 01:31:20,250
Svo rauntíma atkvæðagreiðslu, höfum við
kröfur um atkvæðagreiðslu.

2072
01:31:20,250 --> 01:31:25,250
Kröfur eru sem við leyfum
hver maður að kjósa aðeins einu sinni.

2073
01:31:25,250 --> 01:31:28,060
Við viljum enginn að vera fær um
til að breyta atkvæði sínu.

2074
01:31:28,060 --> 01:31:31,045
Við viljum rauntíma samloðun
og greinandi fyrir lýðfræði

2075
01:31:31,045 --> 01:31:34,210
sem við erum að fara að vera
birtist notendum á síðuna.

2076
01:31:34,210 --> 01:31:35,200
>> Hugsaðu um þessa atburðarás.

2077
01:31:35,200 --> 01:31:37,550
Við vinnum mikið af veruleika
TV sýnir hvar þeir eru

2078
01:31:37,550 --> 01:31:38,960
gera þessar nákvæmlega tegund af hlutur.

2079
01:31:38,960 --> 01:31:41,584
Svo er hægt að hugsa um aðstæður,
við höfum margar milljónir

2080
01:31:41,584 --> 01:31:43,959
unglingsstúlkna þar
með klefi sími þeirra

2081
01:31:43,959 --> 01:31:46,250
og atkvæðagreiðslu, og greiða atkvæði, og
að greiða atkvæði um hver þau eru

2082
01:31:46,250 --> 01:31:48,610
finna að vera vinsæll.

2083
01:31:48,610 --> 01:31:50,830
Svo þetta eru nokkrar af the
kröfur við hlaupum út.

2084
01:31:50,830 --> 01:31:52,990
>> Og svo fyrst að taka
í að leysa þetta vandamál

2085
01:31:52,990 --> 01:31:55,090
væri að byggja upp
mjög einfalt forrit.

2086
01:31:55,090 --> 01:31:56,490
Svo ég hef fengið þetta forrit.

2087
01:31:56,490 --> 01:31:57,950
Ég hef nokkrar kjósendur þarna úti.

2088
01:31:57,950 --> 01:31:59,980
Þeir koma í, þeir högg the atkvæðagreiðslu app.

2089
01:31:59,980 --> 01:32:03,440
Ég hef fengið nokkrar hrár atkvæði borð
Ég ætla bara að afrita þau atkvæði í.

2090
01:32:03,440 --> 01:32:05,780
Ég hef fengið samanlagt
atkvæði borð sem

2091
01:32:05,780 --> 01:32:09,490
mun gera Analytics og lýðfræði,
og við munum setja allt þetta í það.

2092
01:32:09,490 --> 01:32:11,420
>> Og þetta er frábært.

2093
01:32:11,420 --> 01:32:12,332
Lífið er gott.

2094
01:32:12,332 --> 01:32:15,040
Lífið er gott þar til við að finna út að
það er alltaf bara einn eða tveir

2095
01:32:15,040 --> 01:32:16,879
fólk sem eru vinsælar í kosningum.

2096
01:32:16,879 --> 01:32:19,420
Það er aðeins einn eða tveir hlutir
að fólk virkilega vænt um.

2097
01:32:19,420 --> 01:32:22,340
Og ef þú ert að greiða atkvæði á
mælikvarða, allt í einu er ég

2098
01:32:22,340 --> 01:32:26,360
fara að hamar í helvíti út af
tveir frambjóðendur, einn eða tveir frambjóðendur.

2099
01:32:26,360 --> 01:32:29,390
A mjög takmarkaður fjöldi atriða
fólk finnur til að vera vinsæll.

2100
01:32:29,390 --> 01:32:31,710
>> Þetta er ekki góð hönnun mynstur.

2101
01:32:31,710 --> 01:32:33,549
Þetta er í raun
mjög slæmt hönnun mynstur

2102
01:32:33,549 --> 01:32:36,340
vegna þess að það skapar nákvæmlega hvað við
talaði um sem var heitum lyklana.

2103
01:32:36,340 --> 01:32:38,960
Heitum lyklana eru eitthvað við líkar ekki.

2104
01:32:38,960 --> 01:32:40,470
>> Svo hvernig gera við lagfærum það?

2105
01:32:40,470 --> 01:32:47,640
Og í raun, hvernig á að laga þetta er
með því að taka þá frambjóðanda fötunum

2106
01:32:47,640 --> 01:32:51,490
og hvers frambjóðanda sem við höfum,
við erum að fara að bæta handahófi gildi,

2107
01:32:51,490 --> 01:32:54,192
eitthvað sem við vitum, af handahófi
gildi milli einn og 100,

2108
01:32:54,192 --> 01:32:56,620
milli 100 og 1.000,
eða á milli eitt og 1.000,

2109
01:32:56,620 --> 01:32:59,940
þó margir handahófi gildi sem þú vilt
auka á lok þess frambjóðandi.

2110
01:32:59,940 --> 01:33:01,330
>> Og hvað hef ég gert í raun þá?

2111
01:33:01,330 --> 01:33:05,830
Ef ég er að nota frambjóðandi ID sem
fötu til samanlagðra atkvæða,

2112
01:33:05,830 --> 01:33:08,780
ef ég hef bætt við handahófi
númer til loka að

2113
01:33:08,780 --> 01:33:12,000
Ég hef búið nú 10 fötunum, a
hundrað fötunum, þúsund fötur

2114
01:33:12,000 --> 01:33:14,160
að ég er að leggja saman atkvæði yfir.

2115
01:33:14,160 --> 01:33:18,030
>> Þannig að ég hef milljónir og milljónir,
og milljónir af skrám koma í

2116
01:33:18,030 --> 01:33:22,050
fyrir þessum frambjóðendum, ég er nú að breiðast út
þessir atkvæði yfir Frambjóðandi a_1

2117
01:33:22,050 --> 01:33:24,630
gegnum Frambjóðandi A_100, því
í hvert skipti sem atkvæði koma í,

2118
01:33:24,630 --> 01:33:26,530
Ég mynda af handahófi
gildi milli eitt og 100.

2119
01:33:26,530 --> 01:33:29,446
Ég klísturvamandi það á the endir af the
frambjóðandi sem maður er að greiða atkvæði um.

2120
01:33:29,446 --> 01:33:31,120
Ég varp það inn í þessi fötu.

2121
01:33:31,120 --> 01:33:33,910
>> Nú á rass, ég veit
að ég fékk hundrað fötunum.

2122
01:33:33,910 --> 01:33:36,350
Svo þegar ég vil fara á undan
og samanlagður atkvæði,

2123
01:33:36,350 --> 01:33:38,244
Ég las úr öllum þeim fötunum.

2124
01:33:38,244 --> 01:33:39,160
Svo ég fara á undan og bæta.

2125
01:33:39,160 --> 01:33:42,410
Og þá er ég ekki að dreifa safna
þar sem ég fer út og segja hey,

2126
01:33:42,410 --> 01:33:45,399
þú veist hvað, lykill þessa frambjóðanda
rými er yfir hundrað fötunum.

2127
01:33:45,399 --> 01:33:47,940
Ég ætla að safna öllum
atkvæði frá þeim hundrað fötunum.

2128
01:33:47,940 --> 01:33:49,981
Ég ætla að samanlagður
þá og ég ætla að segja,

2129
01:33:49,981 --> 01:33:53,830
Frambjóðandi A er nú
alls atkvæði telja x.

2130
01:33:53,830 --> 01:33:55,690
>> Nú bæði skrifa
fyrirspurn og lesa fyrirspurn

2131
01:33:55,690 --> 01:33:58,160
eru vel dreift
vegna þess að ég er að skrifa yfir

2132
01:33:58,160 --> 01:34:00,320
og ég er að lesa á hundruðum lykla.

2133
01:34:00,320 --> 01:34:03,500
Ég ætla ekki að skrifa og
lesa yfir einum lykli núna.

2134
01:34:03,500 --> 01:34:04,950
Svo er það mikill mynstur.

2135
01:34:04,950 --> 01:34:08,090
>> Þetta er í raun sennilega einn
af mikilvægustu hönnun

2136
01:34:08,090 --> 01:34:10,420
mynstur fyrir mælikvarða í NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Þú munt sjá þessa tegund af
hönnun mynstur í öllum bragði.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, er það ekki
Sama, við verðum öll að gera þetta.

2139
01:34:19,100 --> 01:34:21,840
Vegna þess að þegar þú ert að takast á
með þeim gríðarlega útfellingarnar,

2140
01:34:21,840 --> 01:34:26,650
þú þarft að reikna út a vegur til
dreifa þeim út yfir fötunum.

2141
01:34:26,650 --> 01:34:29,512
Svo er þetta eins og þú gerir það.

2142
01:34:29,512 --> 01:34:31,220
Allt í lagi, svo hvað
þú ert að gera núna

2143
01:34:31,220 --> 01:34:35,252
er þú ert viðskipti burt lesa
kostnaður fyrir skrifa sveigjanleika.

2144
01:34:35,252 --> 01:34:37,085
Kostnaður við að lesa mitt er
svolítið flóknari

2145
01:34:37,085 --> 01:34:40,220
og ég verð að fara að lesa úr
hundrað fötunum staðinn fyrir eitt.

2146
01:34:40,220 --> 01:34:41,310
En ég er fær um að skrifa.

2147
01:34:41,310 --> 01:34:44,860
Og afköst mín, skrifa minn
afköst er ótrúlegt.

2148
01:34:44,860 --> 01:34:49,450
Svo það er yfirleitt mikilvægt
tækni fyrir stigstærð DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
eða NoSQL gagnagrunnur fyrir þessi mál.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Þannig að við mynstrağur út hvernig á að skala það.

2152
01:34:55,240 --> 01:34:56,930
Og við mynstrağur hvernig
útrýma heitum lyklana okkar.

2153
01:34:56,930 --> 01:34:57,820
Og þetta er frábært.

2154
01:34:57,820 --> 01:34:58,960
Og við fengum þessa fallegu kerfi.

2155
01:34:58,960 --> 01:35:02,043
Og það er gefið okkur mjög rétt atkvæðagreiðslu
vegna þess að við höfum met atkvæði de-dupe.

2156
01:35:02,043 --> 01:35:03,130
Það er byggt inn DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Við ræddum um skilyrtan réttindi.

2158
01:35:05,380 --> 01:35:08,170
>> Þegar kjósandi kemur inn, setur
innskot á borðið,

2159
01:35:08,170 --> 01:35:11,220
þeir setja með kjósandi ID þeirra,
ef þeir reyna að setja annað atkvæði,

2160
01:35:11,220 --> 01:35:13,320
Ég skilyrt skrifa.

2161
01:35:13,320 --> 01:35:16,960
Segja aðeins skrifa þetta
ef þetta er ekki til.

2162
01:35:16,960 --> 01:35:19,270
Svo um leið og ég sé að
að atkvæði er högg á borð,

2163
01:35:19,270 --> 01:35:20,460
enginn annar er að fara að vera
fær um að setja atkvæði sitt í.

2164
01:35:20,460 --> 01:35:21,634
Og það er frábært.

2165
01:35:21,634 --> 01:35:23,550
Og við erum incrementing
umsóknarríki gegn okkar.

2166
01:35:23,550 --> 01:35:25,466
Og við erum að gera okkar
lýðfræði og allt það.

2167
01:35:25,466 --> 01:35:29,110
En hvað gerist ef minn
umsókn fellur yfir?

2168
01:35:29,110 --> 01:35:31,350
Nú allt í einu atkvæði
eru að koma í, og ég

2169
01:35:31,350 --> 01:35:34,840
veit ekki hvort þeir eru að fá afgreidd
í greinandi mínum og lýðfræði

2170
01:35:34,840 --> 01:35:36,040
lengur.

2171
01:35:36,040 --> 01:35:38,462
Og þegar umsóknin
kemur aftur upp, hvernig

2172
01:35:38,462 --> 01:35:41,420
helvíti veit ég hvað atkvæði hafa
verið unnin og þar fæ ég að byrja?

2173
01:35:41,420 --> 01:35:44,530
>> Svo er þetta alvöru vandamál þegar þú
byrja að líta á þessa tegund af atburðarás.

2174
01:35:44,530 --> 01:35:45,571
Og hvernig eigum við að leysa þetta?

2175
01:35:45,571 --> 01:35:48,070
Við leysa það með það sem við
kalla DynamoDB lækjum.

2176
01:35:48,070 --> 01:35:53,470
Straumar er tími panta og
skipt breyting log hverjum aðgang

2177
01:35:53,470 --> 01:35:55,700
að borðinu, hver skrifar
aðgang að borðinu.

2178
01:35:55,700 --> 01:35:58,810
Öll gögn sem er skrifað til
Taflan sýnir sig á straumi.

2179
01:35:58,810 --> 01:36:01,815
>> Það er í grundvallaratriðum a 24 klst biðröð.

2180
01:36:01,815 --> 01:36:03,690
Atriði högg á,
að þær lifa í 24 klukkustundir.

2181
01:36:03,690 --> 01:36:05,990
Þau er hægt að lesa mörgum sinnum.

2182
01:36:05,990 --> 01:36:09,400
Guaranteed til afhendingar
aðeins einu sinni að læknum,

2183
01:36:09,400 --> 01:36:11,180
lesa mátti n fjölda sinnum.

2184
01:36:11,180 --> 01:36:14,910
Svo þó margir aðferðir sem þú vilt
neyta að gögn, getur þú neyta það.

2185
01:36:14,910 --> 01:36:16,350
Það mun birtast í hvert uppfærslu.

2186
01:36:16,350 --> 01:36:18,455
Sérhver skrifa mun aðeins
birtast einu sinni á straumi.

2187
01:36:18,455 --> 01:36:20,621
Svo þú þarft ekki að hafa áhyggjur
um vinnslu það tvisvar

2188
01:36:20,621 --> 01:36:22,500
frá sama ferli.

2189
01:36:22,500 --> 01:36:25,350
>> Það er stranglega skipað í lið.

2190
01:36:25,350 --> 01:36:28,180
Þegar við segjum tíma
pantað og skipt,

2191
01:36:28,180 --> 01:36:30,680
þú munt sjá á skipting á straumi.

2192
01:36:30,680 --> 01:36:33,169
Þú munt sjá atriði, uppfærslur í röð.

2193
01:36:33,169 --> 01:36:35,210
Við erum ekki að tryggja
á straumi sem þú ert

2194
01:36:35,210 --> 01:36:40,240
fara að fá hverja færslu
í því skyni yfir atriði.

2195
01:36:40,240 --> 01:36:42,440
>> Svo vatnsföll eru idempotent.

2196
01:36:42,440 --> 01:36:44,037
Ekki við vitum öll hvað idempotent þýðir?

2197
01:36:44,037 --> 01:36:46,620
Idempotent þýðir að þú getur gert það
yfir, og aftur, og aftur.

2198
01:36:46,620 --> 01:36:48,200
Niðurstaðan er að fara til vera the sami.

2199
01:36:48,200 --> 01:36:49,991
>> Vatnsföll eru idempotent,
en þeir verða að vera

2200
01:36:49,991 --> 01:36:54,860
lék frá upphafið,
hvar sem þú velur, allt til enda,

2201
01:36:54,860 --> 01:36:57,950
eða þeir vilja ekki leiða
í sömu gildi.

2202
01:36:57,950 --> 01:36:59,727
>> Sama með MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB hefur reisa
þeir kalla oplog.

2204
01:37:01,560 --> 01:37:04,140
Það er nákvæmlega sömu byggingu.

2205
01:37:04,140 --> 01:37:06,500
Margir NoSQL gagnagrunna
hafa þetta reisa.

2206
01:37:06,500 --> 01:37:08,790
Þeir nota það til að gera hlutina
eins afritunar, sem

2207
01:37:08,790 --> 01:37:10,475
er einmitt það sem við gerum með lækjum.

2208
01:37:10,475 --> 01:37:12,350
Áhorfendur: Kannski
heretical spurning, en þú

2209
01:37:12,350 --> 01:37:13,975
tala um forrit gera niður svo framvegis.

2210
01:37:13,975 --> 01:37:16,089
Eru vatnsföll tryggt að
aldrei hugsanlega fara niður?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Já, læki
eru tryggð að fara aldrei niður.

2212
01:37:18,630 --> 01:37:21,040
Við stjórna innviði
bak. læki sjálfkrafa

2213
01:37:21,040 --> 01:37:22,498
dreifa í farartæki stigstærð hópi þeirra.

2214
01:37:22,498 --> 01:37:25,910
Við munum fara í gegnum smá
hluti um hvað gerist.

2215
01:37:25,910 --> 01:37:30,060
>> Ég ætti ekki að segja að þeir eru ekki
tryggt að aldrei fara niður.

2216
01:37:30,060 --> 01:37:33,110
Þættir eru tryggð
að birtast í straumi.

2217
01:37:33,110 --> 01:37:36,740
Og straumi mun vera aðgengilegur.

2218
01:37:36,740 --> 01:37:40,580
Svo fer það niður eða kemur aftur
upp, það gerist undir.

2219
01:37:40,580 --> 01:37:43,844
Það covers-- það er allt í lagi.

2220
01:37:43,844 --> 01:37:46,260
Allt í lagi, þannig að þú færð annað
skoða tegundir af skjánum.

2221
01:37:46,260 --> 01:37:51,040
Útsýnið tegundir sem eru mikilvæg til að a
forritari yfirleitt eru, hvað var það?

2222
01:37:51,040 --> 01:37:52,370
Ég fæ gömlu viðhorfi.

2223
01:37:52,370 --> 01:37:55,630
Þegar uppfærsla hits the borð, verður það
ýta gömlu viðhorfi að læknum

2224
01:37:55,630 --> 01:38:02,070
þannig að gögn geta skjalasafn, eða breyta
stjórna, breyta auðkenni, breyting

2225
01:38:02,070 --> 01:38:03,600
stjórnun.

2226
01:38:03,600 --> 01:38:07,160
>> Nýja myndin, hvað það er nú eftir
endurnýja, það er önnur tegund af ljósi

2227
01:38:07,160 --> 01:38:07,660
þú getur fengið.

2228
01:38:07,660 --> 01:38:09,660
Þú getur fengið bæði gamla og nýjar myndir.

2229
01:38:09,660 --> 01:38:10,660
Kannski ég vil þá báða.

2230
01:38:10,660 --> 01:38:11,790
Mig langar að sjá hvað það var.

2231
01:38:11,790 --> 01:38:13,290
Mig langar að sjá hvað það breytt í.

2232
01:38:13,290 --> 01:38:15,340
>> Ég er með farið tegund
af ferli sem keyrir.

2233
01:38:15,340 --> 01:38:17,430
Það þarf að staðfesta að
þegar þessir hlutir breytast,

2234
01:38:17,430 --> 01:38:21,840
sem þeir eru innan ákveðinna marka
eða innan ákveðnum þáttum.

2235
01:38:21,840 --> 01:38:23,840
>> Og þá kannski bara ég
þarf að vita hvað breyttist.

2236
01:38:23,840 --> 01:38:26,240
Mér er alveg sama hvaða atriði breyst.

2237
01:38:26,240 --> 01:38:28,580
Ég þarf ekki að þurfa að vita
hvað eiginleika breytt.

2238
01:38:28,580 --> 01:38:30,882
Ég þarf bara að vita að
atriði eru snert.

2239
01:38:30,882 --> 01:38:33,340
Svo þetta eru tegundir af skoðunum
sem þú færð af straum

2240
01:38:33,340 --> 01:38:35,960
og þú getur samskipti við.

2241
01:38:35,960 --> 01:38:37,840
>> Forritið sem
eyðir á,

2242
01:38:37,840 --> 01:38:39,298
þetta er góður af því hvernig þetta virkar.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB viðskiptavinur spyrja að
ýta gögn til borðum.

2244
01:38:42,570 --> 01:38:44,750
Straumar senda á það sem við köllum Pottbrot.

2245
01:38:44,750 --> 01:38:47,380
Pottbrot eru minnkaðar
óháð töflunni.

2246
01:38:47,380 --> 01:38:50,660
Þeir lína ekki upp alveg
að skipting á töflunni.

2247
01:38:50,660 --> 01:38:52,540
Og ástæðan fyrir því er
vegna þess að þeir stilla upp

2248
01:38:52,540 --> 01:38:55,430
í sambandi við hæfni, núverandi
getu töflunni.

2249
01:38:55,430 --> 01:38:57,600
>> Þeir dreifa í þeirra
eigin farartæki stigstærð hópur,

2250
01:38:57,600 --> 01:39:00,800
og þeir byrja að snúast út eftir
því hversu margir skrifar eru að koma í,

2251
01:39:00,800 --> 01:39:03,090
hversu margir reads-- í raun er það skrifar.

2252
01:39:03,090 --> 01:39:05,820
Það er engin reads-- en hvernig
margir skrifar eru að koma inn.

2253
01:39:05,820 --> 01:39:08,200
>> Og þá á bak
enda höfum við það sem við

2254
01:39:08,200 --> 01:39:11,390
kalla KCl eða Kinesis viðskiptavinur bókasafn.

2255
01:39:11,390 --> 01:39:19,190
Kinesis er straum gögn
vinnsla tækni frá Amazon.

2256
01:39:19,190 --> 01:39:22,040
Og lækir er byggt á því.

2257
01:39:22,040 --> 01:39:25,670
>> Svo þú notar KCL virkt
forrit til að lesa straum.

2258
01:39:25,670 --> 01:39:28,752
The Kinesis Client Library raun
stýrir starfsmenn fyrir þig.

2259
01:39:28,752 --> 01:39:30,460
Og það er einnig sumir
áhugavert.

2260
01:39:30,460 --> 01:39:35,630
Það verður að búa til nokkrar töflur upp
í DynamoDB tablespace þinn

2261
01:39:35,630 --> 01:39:38,410
að fylgjast með hvaða liði
hafa verið afgreidd.

2262
01:39:38,410 --> 01:39:41,190
Svo Þannig ef það fellur aftur, ef
það fellur yfir og kemur og fær

2263
01:39:41,190 --> 01:39:45,570
stóð aftur upp, það er hægt að ákvarða hvar
var það í vinnslu strauminn.

2264
01:39:45,570 --> 01:39:48,360
>> Það er mjög mikilvægt þegar
þú ert að tala um eftirmyndun.

2265
01:39:48,360 --> 01:39:50,350
Ég þarf að vita hvað
Gögnin voru verið afgreidd

2266
01:39:50,350 --> 01:39:52,810
og hvaða gögn enn að vinna.

2267
01:39:52,810 --> 01:39:57,380
Svo KCL bókasafn fyrir læki mun
gefa þér mikið af því virkni.

2268
01:39:57,380 --> 01:39:58,990
Það sér um alla umgengni.

2269
01:39:58,990 --> 01:40:01,140
Það stendur upp starfsmann fyrir hvert Shard.

2270
01:40:01,140 --> 01:40:04,620
Það skapar stjórnsýslu borð
fyrir hvert Shard, fyrir hvern starfsmann.

2271
01:40:04,620 --> 01:40:07,560
Og eins og þeim starfsmönnum eldi,
þeir halda þeim borðum

2272
01:40:07,560 --> 01:40:10,510
svo þú veist þetta met
var að lesa og vinna.

2273
01:40:10,510 --> 01:40:13,850
Og þá þannig að ef ferlið
deyr og kemur aftur á netinu,

2274
01:40:13,850 --> 01:40:17,940
það er hægt að halda áfram rétt þar sem það tók burt.

2275
01:40:17,940 --> 01:40:20,850
>> Þannig að við notum þetta fyrir
kross-svæðinu afritunar.

2276
01:40:20,850 --> 01:40:24,680
A einhver fjöldi af viðskiptavinum hafa þörf til
færa gögn eða hluta af töflum sínum

2277
01:40:24,680 --> 01:40:25,920
um að mismunandi svæðum.

2278
01:40:25,920 --> 01:40:29,230
Það eru níu svæði
um allan heiminn.

2279
01:40:29,230 --> 01:40:32,100
Þannig að það gæti verið need-- I
gæti hafa notendur í Asíu, notendur

2280
01:40:32,100 --> 01:40:34,150
í austurströnd Bandaríkjanna.

2281
01:40:34,150 --> 01:40:38,980
Þeir hafa mismunandi gögn sem
þarf að vera á staðnum dreift.

2282
01:40:38,980 --> 01:40:42,510
Og kannski notandi flýgur frá
Asia yfir til Bandaríkjanna,

2283
01:40:42,510 --> 01:40:45,020
og ég vil endurtaka
gögn hans með honum.

2284
01:40:45,020 --> 01:40:49,340
Svo þegar hann fær af flugvél, hefur hann
góð reynsla að nota farsíma app hans.

2285
01:40:49,340 --> 01:40:52,360
>> Þú getur notað kross-svæðinu
afritunar bókasafn til að gera þetta.

2286
01:40:52,360 --> 01:40:55,730
Í grundvallaratriðum erum við að hafa
veitt tvær tækni.

2287
01:40:55,730 --> 01:40:59,400
Eitt er hugga umsókn þú getur
standa upp á eigin EC2 dæmi þitt.

2288
01:40:59,400 --> 01:41:01,240
Það liggur hreint afritunar.

2289
01:41:01,240 --> 01:41:02,720
Og þá erum við gaf þér bókasafn.

2290
01:41:02,720 --> 01:41:06,070
Bókasafnið er hægt að nota til að byggja upp
eigin umsókn þína ef þú

2291
01:41:06,070 --> 01:41:10,740
langar að gera brjálaður hlutina með að data--
sía, endurtaka aðeins hluti af því,

2292
01:41:10,740 --> 01:41:14,120
snúa gögn, færa það inn í a
mismunandi borð, svo framvegis og svo framvegis.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Svo er þannig hvað það lítur út.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Straumar geta verið
unnin með það sem við köllum lambda.

2296
01:41:23,690 --> 01:41:27,394
Við umtal svolítið um atburði
ekin umsókn arkitektúr.

2297
01:41:27,394 --> 01:41:28,810
Lambda er lykilþáttur í því.

2298
01:41:28,810 --> 01:41:32,840
Lambda er númerið sem skýtur á eftirspurn
til að bregðast við ákveðnu atviki.

2299
01:41:32,840 --> 01:41:36,020
Einn af þeim atburðum gæti verið
met birtast á straumi.

2300
01:41:36,020 --> 01:41:39,100
Ef met birtist á straumi,
við munum kalla þetta Java aðgerð.

2301
01:41:39,100 --> 01:41:44,980
Jæja, þetta er JavaScript, og Lambda
styður Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
og mun brátt styðja
önnur tungumál eins og heilbrigður.

2303
01:41:47,820 --> 01:41:50,940
Og nægja að segja, að það er hreint númer.

2304
01:41:50,940 --> 01:41:53,610
skrifa í Java, skilgreina flokk.

2305
01:41:53,610 --> 01:41:55,690
Þú ýta JAR upp í Lambda.

2306
01:41:55,690 --> 01:42:00,200
Og þá þú tilgreinir hvaða tegund
að hringja til að bregðast við þeim tilvikum.

2307
01:42:00,200 --> 01:42:04,770
Og þá Lambda innviði
á bak við það mun keyra þessi númer.

2308
01:42:04,770 --> 01:42:06,730
>> Það merkjamál geta afgreitt
færslur burt straumnum.

2309
01:42:06,730 --> 01:42:08,230
Það getur gert neitt það vill með það.

2310
01:42:08,230 --> 01:42:11,650
Í þessu tiltekna dæmi, eru öll við
í raun að gera er að skrá þig á eiginleika.

2311
01:42:11,650 --> 01:42:13,480
En þetta er bara númer.

2312
01:42:13,480 --> 01:42:15,260
Merkjamál geta gert neitt, ekki satt?

2313
01:42:15,260 --> 01:42:16,600
>> Svo er hægt að snúa þessum gögnum.

2314
01:42:16,600 --> 01:42:18,160
Þú getur búið til þitt eigið efni útsýni.

2315
01:42:18,160 --> 01:42:21,160
Ef það er skjal uppbyggingu,
þú getur fletja uppbyggingu.

2316
01:42:21,160 --> 01:42:24,300
Þú getur búið til aðra stuðla.

2317
01:42:24,300 --> 01:42:27,100
Alls konar hlutir sem þú getur
gera með DynamoDB lækjum.

2318
01:42:27,100 --> 01:42:28,780
>> Og í raun, það er það sem það lítur út.

2319
01:42:28,780 --> 01:42:29,940
Þannig að þú færð þær uppfærslur koma í.

2320
01:42:29,940 --> 01:42:31,190
Þeir eru að koma af streng.

2321
01:42:31,190 --> 01:42:32,720
Þeir eru að lesa af Lambda virka.

2322
01:42:32,720 --> 01:42:37,480
Þeir eru að snúa gögn og
ýta henni upp í afleiddum borðum,

2323
01:42:37,480 --> 01:42:42,200
tilkynna ytri kerfi breytinga,
og þrýsta gögn inn ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Við ræddum um hvernig á að setja skyndiminni
framan gagnagrunn fyrir að sala

2325
01:42:45,900 --> 01:42:46,450
atburðarás.

2326
01:42:46,450 --> 01:42:50,049
Jæja hvað gerist ef ég
uppfæra atriði lýsingu?

2327
01:42:50,049 --> 01:42:52,340
Jæja, ef ég hafði Lambda
virka í gangi á þeirri töflu,

2328
01:42:52,340 --> 01:42:55,490
ef ég uppfæri hlutinn lýsingu, verður það
taka upp met af straumi,

2329
01:42:55,490 --> 01:42:58,711
og það mun uppfæra ElastiCache
dæmi með nýjum gögnum.

2330
01:42:58,711 --> 01:43:00,460
Svo er það mikið af
Hvað við gerum við Lambda.

2331
01:43:00,460 --> 01:43:02,619
Það er lím númer, tengjum.

2332
01:43:02,619 --> 01:43:04,410
Og það gefur í raun
getu til að ráðast

2333
01:43:04,410 --> 01:43:07,930
og að keyra mjög flókin forrit
án þess að hollur framreiðslumaður

2334
01:43:07,930 --> 01:43:10,371
uppbygging, sem er mjög flott.

2335
01:43:10,371 --> 01:43:13,100
>> Svo við skulum fara aftur til okkar
rauntíma atkvæðagreiðslu arkitektúr.

2336
01:43:13,100 --> 01:43:17,984
Þetta er ný og endurbætt með okkar
lækir og KCL virkt umsókn.

2337
01:43:17,984 --> 01:43:20,150
Sama og áður, við getum
séð hvaða mælikvarða kosningum.

2338
01:43:20,150 --> 01:43:21,100
Við eins og þetta.

2339
01:43:21,100 --> 01:43:24,770
Við erum að gera út tvístra safnar
á mörgum fötunum.

2340
01:43:24,770 --> 01:43:26,780
Við höfum fengið bjartsýnn læsa gerast.

2341
01:43:26,780 --> 01:43:30,192
Við getum haldið kjósendur okkar
breyti atkvæði.

2342
01:43:30,192 --> 01:43:31,400
Þeir geta aðeins kjósa einu sinni.

2343
01:43:31,400 --> 01:43:32,880
Þetta er frábært.

2344
01:43:32,880 --> 01:43:35,895
Real-tími kenna umburðarlyndi,
stigstærð samansafn núna.

2345
01:43:35,895 --> 01:43:38,270
Ef hlutur fellur yfir, það
veit hvar á að endurræsa sig

2346
01:43:38,270 --> 01:43:41,300
þegar það kemur aftur upp vegna
við erum að nota KCl app.

2347
01:43:41,300 --> 01:43:45,700
Og þá getum við líka notað sem
KCL umsókn að ýta gögn út

2348
01:43:45,700 --> 01:43:48,820
að rauðvik fyrir aðra
app greinandi eða notkun

2349
01:43:48,820 --> 01:43:51,990
teygju MapReduce að keyra
rauntíma straumspilunartenglar útfellingarnar burt

2350
01:43:51,990 --> 01:43:53,180
þessi gögn.

2351
01:43:53,180 --> 01:43:55,480
>> Svo þetta eru hlutir sem við
hef ekki talað um mikið.

2352
01:43:55,480 --> 01:43:57,375
En þeir eru fleiri
tækni sem koma

2353
01:43:57,375 --> 01:44:00,310
að bera þegar þú ert að leita
á þessar aðstæður.

2354
01:44:00,310 --> 01:44:03,160
>> Allt í lagi, svo það er um
greinandi með DynamoDB lækjum.

2355
01:44:03,160 --> 01:44:05,340
Hægt er að safna de-dupe
gögn, gera alls konar

2356
01:44:05,340 --> 01:44:09,490
Nice efni, samanlagður gögn í
minni, skapa þeim afleidd töflur.

2357
01:44:09,490 --> 01:44:13,110
Það er a gríðarstór nota málið
að mikið af viðskiptavinum

2358
01:44:13,110 --> 01:44:16,950
eru í tengslum við, taka hreiður
eiginleikar þeirra JSON skjölum

2359
01:44:16,950 --> 01:44:18,946
og búa til fleiri vísitölur.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Við erum í lokin.

2362
01:44:23,150 --> 01:44:26,689
Þakka þér fyrir að bera með mér.

2363
01:44:26,689 --> 01:44:28,480
Svo skulum við tala um
tilvísun arkitektúr.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB situr í miðju svo
mikið af AWS innviði.

2365
01:44:33,440 --> 01:44:37,090
Í grundvallaratriðum þú getur krókur það
upp til nokkuð sem þú vilt.

2366
01:44:37,090 --> 01:44:45,600
Umsóknir byggð með Dynamo eru
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
ýta gögn út í Elastic
MapReduce, útflutningur innflutningur frá DynamoDB

2368
01:44:49,890 --> 01:44:52,370
í S3, alls konar Verkferlar.

2369
01:44:52,370 --> 01:44:54,120
En sennilega besta
hlutur til að tala um,

2370
01:44:54,120 --> 01:44:56,119
og þetta er það sem er raunverulega
áhugavert er þegar við

2371
01:44:56,119 --> 01:44:58,350
tala um atburði ekið forrit.

2372
01:44:58,350 --> 01:45:00,300
>> Þetta er dæmi um
innri verkefni

2373
01:45:00,300 --> 01:45:04,850
sem við höfum þar sem við erum í raun og veru
útgáfu til að safna niðurstöðum könnunarinnar.

2374
01:45:04,850 --> 01:45:07,700
Svo í netfangatengil sem
við sendum út, það verður

2375
01:45:07,700 --> 01:45:11,350
vera svolítið hlekkur segja smellur
hér að bregðast við könnuninni.

2376
01:45:11,350 --> 01:45:14,070
Og þegar maður smellir
sem tengjast, hvað gerist

2377
01:45:14,070 --> 01:45:18,020
er þeir rífa niður örugg
HTML könnun form úr S3.

2378
01:45:18,020 --> 01:45:18,980
Það er ekki framreiðslumaður.

2379
01:45:18,980 --> 01:45:20,600
Þetta er bara S3 hlut.

2380
01:45:20,600 --> 01:45:22,770
>> Sem form kemur upp,
hleðst upp í vafranum.

2381
01:45:22,770 --> 01:45:24,240
Það fékk burðarás.

2382
01:45:24,240 --> 01:45:30,160
Það fékk flókið JavaScript
að það er í gangi.

2383
01:45:30,160 --> 01:45:33,557
Svo það er mjög ríkur umsókn
gangi í vafranum viðskiptavinarins.

2384
01:45:33,557 --> 01:45:36,390
Þeir vita ekki að þeir eru ekki
samskipti við bak endir framreiðslumaður.

2385
01:45:36,390 --> 01:45:38,220
Á þessum tímapunkti, það er allt vafra.

2386
01:45:38,220 --> 01:45:41,780
>> Þeir birta niðurstöðurnar hvað
við köllum Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway er einfaldlega vefur API
að þú getur skilgreint og krókur upp

2388
01:45:46,270 --> 01:45:47,760
að hvað sem þú vilt.

2389
01:45:47,760 --> 01:45:50,990
Í þessu tiltekna tilviki, við erum
boginn upp til a Lambda virka.

2390
01:45:50,990 --> 01:45:54,797
>> Svo er gangur POST minn
gerast án miðlara.

2391
01:45:54,797 --> 01:45:56,380
Í grundvallaratriðum situr að API Gateway það.

2392
01:45:56,380 --> 01:45:58,770
Það kostar mig ekkert fyrr en fólk
byrja að senda á það, ekki satt?

2393
01:45:58,770 --> 01:46:00,269
Lambda virka situr bara þarna.

2394
01:46:00,269 --> 01:46:03,760
Og það kostar mig ekkert fyrr en
fólk byrja hitting það.

2395
01:46:03,760 --> 01:46:07,270
Svo er hægt að sjá, sem bindi
eykst, það er þegar gjöld koma.

2396
01:46:07,270 --> 01:46:09,390
Ég ætla ekki að keyra miðlara 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Svo ég draga formið
niður úr fötu,

2398
01:46:12,310 --> 01:46:15,719
og ég skrifa í gegnum API
Gateway í Lambda virka.

2399
01:46:15,719 --> 01:46:17,510
Og þá Lambda
virka segir, þú veist

2400
01:46:17,510 --> 01:46:20,600
hvað, ég hef fengið nokkrar Piis, sumir
persónugreinanlegar upplýsingar

2401
01:46:20,600 --> 01:46:21,480
í þessum svörum.

2402
01:46:21,480 --> 01:46:23,020
Ég fékk athugasemdir sem koma frá notendum.

2403
01:46:23,020 --> 01:46:24,230
Ég hef fengið netföng.

2404
01:46:24,230 --> 01:46:26,190
Ég hef fengið notendanöfn.

2405
01:46:26,190 --> 01:46:27,810
>> Leyfðu mér að skipta á því.

2406
01:46:27,810 --> 01:46:30,280
Ég ætla að búa til nokkur
lýsigögn burt þessa færslu.

2407
01:46:30,280 --> 01:46:32,850
Og ég ætla að ýta á
lýsigögn í DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Og ég gæti dulkóða öll gögn
og ýta því inn DynamoDB ef ég vil.

2409
01:46:36,059 --> 01:46:38,600
En það er auðveldara fyrir mig, í þessu
nota málið, að fara á undan með að segja,

2410
01:46:38,600 --> 01:46:42,800
Ég ætla að ýta hrár gögn
í dulkóðuðu S3 fötu.

2411
01:46:42,800 --> 01:46:47,240
Svo ég nota innbyggða í S3 miðlara megin
dulkóðun og Lykill Stjórnun Amazon

2412
01:46:47,240 --> 01:46:51,600
Þjónusta svo að ég hafa lykil að
getur snúið á reglulegu millibili,

2413
01:46:51,600 --> 01:46:55,010
og ég get að vernda þessi PII gögn
sem hluta af öllu workflow.

2414
01:46:55,010 --> 01:46:55,870
>> Svo hvað hef ég gert?

2415
01:46:55,870 --> 01:47:00,397
Ég hef bara sent í heild
umsókn, og ég hef enga framreiðslumaður.

2416
01:47:00,397 --> 01:47:02,980
Svo er það atburður ekið umsókn
arkitektúr gerir fyrir þig.

2417
01:47:02,980 --> 01:47:05,730
>> Nú ef þér finnst um
að nota málið til this--

2418
01:47:05,730 --> 01:47:08,730
við höfum aðra viðskiptavini ég er að tala
að um þetta nákvæmlega arkitektúr sem

2419
01:47:08,730 --> 01:47:14,560
hlaupa gríðarlega stór herferðir, sem
eru að horfa á þetta og fara, ó minn.

2420
01:47:14,560 --> 01:47:17,840
Því nú geta þeir
grundvallaratriðum ýta því út þar,

2421
01:47:17,840 --> 01:47:21,900
láta þessi herferð bara sitja
þar til það opnar, og ekki

2422
01:47:21,900 --> 01:47:24,400
að hafa áhyggjur a Fig um
hvers konar uppbygging

2423
01:47:24,400 --> 01:47:26,120
er að fara að vera þarna til að styðja það.

2424
01:47:26,120 --> 01:47:28,600
Og þá eins fljótt og
þessi herferð er gert,

2425
01:47:28,600 --> 01:47:31,520
það er eins og innviði
bara strax fer í burtu

2426
01:47:31,520 --> 01:47:33,680
vegna þess að það í raun
er engin uppbygging.

2427
01:47:33,680 --> 01:47:35,660
Það er bara númer sem situr á lambda.

2428
01:47:35,660 --> 01:47:38,560
Það er bara gögn sem situr í DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Það er ótrúlega hátt
að byggja forrit.

2430
01:47:41,340 --> 01:47:43,970
>> Áhorfendur: Svo er það meira
skammlífa en það væri

2431
01:47:43,970 --> 01:47:45,740
ef það var geymt á raunverulegum miðlara?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Algjörlega.

2433
01:47:46,823 --> 01:47:49,190
Vegna þess miðlara dæmis
þyrfti að vera 24/07.

2434
01:47:49,190 --> 01:47:51,954
Það þarf að vera til staðar fyrir
einhver að svara.

2435
01:47:51,954 --> 01:47:52,620
Jæja giska á hvaða?

2436
01:47:52,620 --> 01:47:55,410
S3 er í boði 24/7.

2437
01:47:55,410 --> 01:47:57,100
S3 bregst alltaf.

2438
01:47:57,100 --> 01:47:59,320
Og S3 er mjög, mjög gott
að þjóna upp hluti.

2439
01:47:59,320 --> 01:48:02,590
Þeir hlutir geta verið HTML skrár, eða
JavaScript skrár eða hvað sem þú vilt.

2440
01:48:02,590 --> 01:48:07,430
Þú getur keyrt mjög ríkur vefur umsókn
úr S3 fötunum, og fólk.

2441
01:48:07,430 --> 01:48:10,160
>> Og svo er það hugmyndin hér
er að komast í burtu frá því

2442
01:48:10,160 --> 01:48:11,270
við notuðum til að hugsa um það.

2443
01:48:11,270 --> 01:48:14,270
Við notuðum til að hugsa í
Skilmálar netþjónum og vélar.

2444
01:48:14,270 --> 01:48:16,580
Það er ekki um það lengur.

2445
01:48:16,580 --> 01:48:19,310
Það er um innviði sem kóða.

2446
01:48:19,310 --> 01:48:22,470
Dreifa kóðann til ský og
láta skýið keyra það fyrir þig.

2447
01:48:22,470 --> 01:48:24,980
Og það er það sem AWS er ​​að reyna að gera.

2448
01:48:24,980 --> 01:48:29,690
>> Áhorfendur: Svo gull kassi í miðjunni
af API Gateway er ekki framreiðslumaður-eins,

2449
01:48:29,690 --> 01:48:30,576
en í staðinn er just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Hægt er að hugsa
um það sem miðlara framhlið.

2451
01:48:32,850 --> 01:48:38,040
Allt það er er það mun taka HTTP
óska og landakort það í annað ferli.

2452
01:48:38,040 --> 01:48:39,192
Það er allt það gerir.

2453
01:48:39,192 --> 01:48:41,525
Og í þessu tilfelli erum við að kortleggja
það að Lambda virka.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Allt í lagi, svo það er allt sem ég fékk.

2456
01:48:45,410 --> 01:48:46,190
Þakka þér kærlega.

2457
01:48:46,190 --> 01:48:46,800
Ég þakka það.

2458
01:48:46,800 --> 01:48:48,100
Ég veit að við viljum smá tímanum.

2459
01:48:48,100 --> 01:48:49,980
Og vonandi þú krakkar fékk
a lítill hluti af upplýsingum

2460
01:48:49,980 --> 01:48:51,410
að þú getur tekið burt í dag.

2461
01:48:51,410 --> 01:48:53,520
Og ég biðst afsökunar ef ég fór
yfir sumir höfuð yðar,

2462
01:48:53,520 --> 01:48:56,697
en það er gott mikið af
grundvallaratriði foundational þekkingu

2463
01:48:56,697 --> 01:48:58,280
sem ég held að sé mjög mikilvæg fyrir þig.

2464
01:48:58,280 --> 01:48:59,825
Svo þakka þér fyrir að hafa mig.

2465
01:48:59,825 --> 01:49:00,325
[Applause]

2466
01:49:00,325 --> 01:49:02,619
Áhorfendur: [inaudible]
er þegar þú varst að segja

2467
01:49:02,619 --> 01:49:05,160
þú þurftir að fara í gegnum málið
frá upphafi til enda

2468
01:49:05,160 --> 01:49:07,619
að fá rétta gildi
eða sömu gildi,

2469
01:49:07,619 --> 01:49:09,410
hvernig væri gildin
breyst ef [inaudible].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Hvernig væri gildin breytast?

2472
01:49:11,800 --> 01:49:15,180
Jæja, vegna þess að ef ég vissi ekki að hlaupa
það alla leið til enda,

2473
01:49:15,180 --> 01:49:19,770
þá veit ég ekki hvaða breytingar
voru gerðar í síðustu míla.

2474
01:49:19,770 --> 01:49:22,144
Það er ekki að fara að vera
sömu upplýsingar og það sem ég sá.

2475
01:49:22,144 --> 01:49:24,560
Áhorfendur: Ó, svo þú bara
hafa ekki fengið allt inntak.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Hægri.

2477
01:49:24,770 --> 01:49:26,895
Þú þarft að fara frá upphafi
til enda, og þá er það

2478
01:49:26,895 --> 01:49:29,280
að fara að vera í samræmi ríkisins.

2479
01:49:29,280 --> 01:49:31,520
Cool.

2480
01:49:31,520 --> 01:49:35,907
>> Áhorfendur: Svo þú sýndi okkur DynamoDB
getur gert skjal eða lykill gildi.

2481
01:49:35,907 --> 01:49:38,740
Og við eyddum miklum tíma á
lykill gildi með kjötkássa og leiðir

2482
01:49:38,740 --> 01:49:40,005
að Flip það í kring.

2483
01:49:40,005 --> 01:49:43,255
Þegar þú horfði á borðum, er að
fara á bak skjal nálgun?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: Ég myndi ekki
segja þannig það á bak.

2485
01:49:44,600 --> 01:49:45,855
>> Áhorfendur: Þeir voru aðskilin frá the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Með skjalinu
nálgun, tegund skjals í DynamoDB

2487
01:49:49,140 --> 01:49:50,880
er bara hugsa um sem annar eiginleiki.

2488
01:49:50,880 --> 01:49:53,560
Það er eiginleiki sem inniheldur
a hierarchic gögn uppbygging.

2489
01:49:53,560 --> 01:49:56,980
Og þá í leitirnar,
þú getur notað eiginleika

2490
01:49:56,980 --> 01:49:59,480
af þeim hlutum sem nota Object Ritháttur.

2491
01:49:59,480 --> 01:50:03,562
Svo ég geti síað á hreiður
eign JSON skjalinu.

2492
01:50:03,562 --> 01:50:05,520
Áhorfendur: Svo hvenær ég
gera skjal nálgun,

2493
01:50:05,520 --> 01:50:07,906
Ég get konar koma á tabular--

2494
01:50:07,906 --> 01:50:08,780
Áhorfendur: Algjörlega.

2495
01:50:08,780 --> 01:50:09,800
Áhorfendur: --indexes og
hlutir sem þú talaði bara um.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Já,
Vísitölur og allt það,

2497
01:50:11,280 --> 01:50:13,363
þegar þú vilt að kemba
eiginleika JSON,

2498
01:50:13,363 --> 01:50:18,230
á þann hátt að við myndum þurfa að gera það er ef
þú setja JSON hlut eða skjal

2499
01:50:18,230 --> 01:50:20,780
í Dynamo, myndir þú nota læki.

2500
01:50:20,780 --> 01:50:22,400
Straumar myndi lesa inntak.

2501
01:50:22,400 --> 01:50:24,340
Þú vilt fá að JSON
mótmæla og þú vilt segja OK,

2502
01:50:24,340 --> 01:50:26,030
hvað er eign sem ég vil vísitölu?

2503
01:50:26,030 --> 01:50:28,717
>> Þú búa til afleitt borð.

2504
01:50:28,717 --> 01:50:30,300
Nú það er hvernig það virkar núna.

2505
01:50:30,300 --> 01:50:32,650
Við leyfum þér ekki að kemba
beint þeim eiginleika.

2506
01:50:32,650 --> 01:50:33,520
>> Áhorfendur: Tabularizing skjöl.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Einmitt, fletja
það, tabularizing það nákvæmlega.

2508
01:50:36,230 --> 01:50:37,415
Það er það sem þú gerir við það.

2509
01:50:37,415 --> 01:50:37,860
>> Áhorfendur: Þakka þér.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Já,
algerlega, þakka þér.

2511
01:50:39,609 --> 01:50:42,240
Áhorfendur: Svo það er góður af
Mongo uppfyllir Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Já,
það er mikið eins og þessi.

2513
01:50:43,990 --> 01:50:45,940
Það er góð lýsing á því.

2514
01:50:45,940 --> 01:50:47,490
Cool.

2515
01:50:47,490 --> 01:50:49,102