1
00:00:00,000 --> 00:00:04,969
>> [Speel van musiek]

2
00:00:04,969 --> 00:00:06,010
Rick Houlihan: Alle reg.

3
00:00:06,010 --> 00:00:06,600
Hallo almal.

4
00:00:06,600 --> 00:00:07,670
My naam is Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Ek is 'n senior skoolhoof
oplossings argitek by AWS.

6
00:00:10,330 --> 00:00:14,070
Ek fokus op NoSQL en
DynamoDB tegnologie.

7
00:00:14,070 --> 00:00:16,930
Ek is vandag hier om te praat
jy 'n bietjie oor hulle.

8
00:00:16,930 --> 00:00:18,970
>> My agtergrond is
hoofsaaklik in die data laag.

9
00:00:18,970 --> 00:00:21,390
Ek het die helfte van my ontwikkeling
loopbaan skryf databasis,

10
00:00:21,390 --> 00:00:25,930
toegang data, oplossings
vir verskeie toepassings.

11
00:00:25,930 --> 00:00:30,000
Ek het in Wolk skynwerklikmaking is
vir ongeveer 20 jaar.

12
00:00:30,000 --> 00:00:33,460
Dus, voordat die wolk die wolk
ons gebruik om dit te noem nut afreken.

13
00:00:33,460 --> 00:00:37,170
En die idee is, dit is soos
PG & E, jy betaal vir wat jy gebruik.

14
00:00:37,170 --> 00:00:38,800
Vandag noem ons dit die wolk.

15
00:00:38,800 --> 00:00:41,239
>> Maar oor die jare, het ek gewerk
vir 'n paar maatskappye

16
00:00:41,239 --> 00:00:42,530
jy het waarskynlik nog nooit gehoor van.

17
00:00:42,530 --> 00:00:47,470
Maar ek het 'n lys van die tegniese saamgestel
prestasies, ek dink jy wil sê.

18
00:00:47,470 --> 00:00:51,620
Ek het agt patente in Wolk stelsels
skynwerklikmaking, mikroverwerker ontwerp,

19
00:00:51,620 --> 00:00:54,440
komplekse gebeurtenis verwerking,
en ander gebiede as well.

20
00:00:54,440 --> 00:00:58,290
>> So hierdie dae, fokus ek meestal op NoSQL
tegnologie en die volgende generasie

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

22
00:00:59,450 --> 00:01:03,370
En dit is oor die algemeen wat ek gaan
om hier te wees met jou praat vandag oor.

23
00:01:03,370 --> 00:01:06,030
So wat jy kan verwag
van hierdie sessie

24
00:01:06,030 --> 00:01:08,254
Ons gaan deur 'n kort
geskiedenis van data verwerking.

25
00:01:08,254 --> 00:01:10,420
Dit is altyd nuttig om
verstaan ​​waar ons vandaan kom

26
00:01:10,420 --> 00:01:12,400
en hoekom ons waar ons is.

27
00:01:12,400 --> 00:01:15,600
En ons sal 'n bietjie praat
bietjie oor NoSQL tegnologie

28
00:01:15,600 --> 00:01:17,500
van 'n fundamentele oogpunt.

29
00:01:17,500 --> 00:01:19,870
>> Ons sal kry in 'n paar van
die DynamoDB internals.

30
00:01:19,870 --> 00:01:24,350
DynamoDB is AWS se geen smaak.

31
00:01:24,350 --> 00:01:27,340
Dit is 'n ten volle beheer en
aangebied NoSQL oplossing.

32
00:01:27,340 --> 00:01:32,420
En ons sal 'n bietjie oor Table Talk
struktuur, APIs, datatipes, indekse,

33
00:01:32,420 --> 00:01:35,177
en 'n paar van die internals
van daardie DynamoDB tegnologie.

34
00:01:35,177 --> 00:01:37,760
Ons kry in 'n paar van die ontwerp
patrone en beste praktyke.

35
00:01:37,760 --> 00:01:39,968
Ons sal praat oor hoe jy
gebruik hierdie tegnologie vir 'n paar

36
00:01:39,968 --> 00:01:41,430
van aansoeke vandag se.

37
00:01:41,430 --> 00:01:44,820
En dan sal ons 'n bietjie praat
oor die evolusie of die opkoms

38
00:01:44,820 --> 00:01:48,980
van 'n nuwe paradigma in programmering
genoem gebeurtenis gedrewe programme

39
00:01:48,980 --> 00:01:51,580
en hoe DynamoDB speel in wat as goed.

40
00:01:51,580 --> 00:01:54,690
En ons sal jou laat 'n bietjie van
'n verwysing argitektuur bespreking

41
00:01:54,690 --> 00:01:59,540
sodat ons kan praat oor 'n paar van
die maniere waarop jy kan DynamoDB gebruik.

42
00:01:59,540 --> 00:02:04,116
>> So eerste off-- dit is 'n vraag
Ek hoor 'n baie is, wat is 'n databasis.

43
00:02:04,116 --> 00:02:06,240
Baie mense dink hulle
weet wat 'n databasis is.

44
00:02:06,240 --> 00:02:08,360
As jy Google, sal jy dit sien.

45
00:02:08,360 --> 00:02:11,675
Dit is 'n 'n gestruktureerde stel data gehou
in 'n rekenaar, veral die een wat

46
00:02:11,675 --> 00:02:13,600
toeganklik is op verskeie maniere.

47
00:02:13,600 --> 00:02:16,992
Ek veronderstel dit is 'n goeie
definisie van 'n moderne databasis.

48
00:02:16,992 --> 00:02:19,450
Maar ek hou nie daarvan nie, want
impliseer dit 'n paar van die dinge.

49
00:02:19,450 --> 00:02:20,935
Dit impliseer struktuur.

50
00:02:20,935 --> 00:02:23,120
En dit impliseer dat dit op 'n rekenaar.

51
00:02:23,120 --> 00:02:25,750
En databasisse het nie
bestaan ​​altyd op rekenaars.

52
00:02:25,750 --> 00:02:28,020
Databasisse eintlik in baie maniere bestaan.

53
00:02:28,020 --> 00:02:32,000
>> So 'n beter definisie van 'n
databasis is iets soos hierdie.

54
00:02:32,000 --> 00:02:34,786
'N databasis 'n georganiseerde
meganisme vir die stoor, bestuur

55
00:02:34,786 --> 00:02:35,910
en die herwinning van inligting.

56
00:02:35,910 --> 00:02:36,868
Dit is van About.com.

57
00:02:36,868 --> 00:02:42,080
So ek hou hiervan, want dit is werklik gesprekke
oor 'n databasis wat 'n bron,

58
00:02:42,080 --> 00:02:44,800
'n bron van
inligting, nie noodwendig

59
00:02:44,800 --> 00:02:46,780
iets wat sit op 'n rekenaar.

60
00:02:46,780 --> 00:02:49,290
En deur die geskiedenis, ons
het nie altyd rekenaars.

61
00:02:49,290 --> 00:02:52,110
>> Nou, as ek vra die gemiddelde
ontwikkelaar vandag wat is

62
00:02:52,110 --> 00:02:54,770
'n databasis, wat is die antwoord wat ek kry.

63
00:02:54,770 --> 00:02:56,070
Iewers kan ek dinge vashou.

64
00:02:56,070 --> 00:02:56,670
Reg?

65
00:02:56,670 --> 00:02:58,725
En dit is waar.

66
00:02:58,725 --> 00:02:59,600
Maar dit is jammer.

67
00:02:59,600 --> 00:03:02,700
Omdat die databasis is regtig
die fondament van die moderne jeug.

68
00:03:02,700 --> 00:03:04,810
Dit is die grondslag
van elke aansoek.

69
00:03:04,810 --> 00:03:07,240
En hoe jy dit bou
databasis, hoe jy te struktureer

70
00:03:07,240 --> 00:03:11,750
dat die data gaan dikteer hoe dit
aansoek doen as jy op die skaal.

71
00:03:11,750 --> 00:03:14,640
>> So 'n baie van my werk vandag
is besig met wat

72
00:03:14,640 --> 00:03:17,180
gebeur wanneer ontwikkelaars
neem hierdie benadering

73
00:03:17,180 --> 00:03:19,510
en die hantering van die nadraai
van 'n program wat

74
00:03:19,510 --> 00:03:24,966
nou skalering buite die oorspronklike
bedoeling en lyding van slegte ontwerp.

75
00:03:24,966 --> 00:03:26,840
So hopelik wanneer jy
loop vandag weg, sal jy

76
00:03:26,840 --> 00:03:29,010
het 'n paar van die gereedskap in
jou gordel wat jy hou

77
00:03:29,010 --> 00:03:32,566
van die maak van die dieselfde foute.

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

79
00:03:33,066 --> 00:03:36,360
So laat ons praat oor 'n bietjie van
die tydlyn van databasis tegnologie.

80
00:03:36,360 --> 00:03:38,830
Ek dink ek lees 'n
artikel nie so lank gelede

81
00:03:38,830 --> 00:03:43,020
en dit het gesê iets op die lines--
dit is 'n baie poëtiese verklaring.

82
00:03:43,020 --> 00:03:46,590
Daar word gesê dat die geskiedenis
van data verwerking is

83
00:03:46,590 --> 00:03:49,350
vol hoë water
van data oorvloed.

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

85
00:03:49,920 --> 00:03:52,532
Nou, ek dink dit is soort van 'n ware.

86
00:03:52,532 --> 00:03:54,990
Maar ek eintlik kyk is as
Die geskiedenis is eintlik gevul

87
00:03:54,990 --> 00:03:56,820
met 'n hoë watermerk van data druk.

88
00:03:56,820 --> 00:04:00,040
Omdat die data koers van
inname gaan nooit af.

89
00:04:00,040 --> 00:04:01,360
Dit gaan net op.

90
00:04:01,360 --> 00:04:03,670
>> En innovasie gebeur wanneer
sien ons data druk, wat

91
00:04:03,670 --> 00:04:07,825
is die bedrag van die data wat
nou in kom in die stelsel.

92
00:04:07,825 --> 00:04:12,027
En dit kan nie verwerk word nie
doeltreffend óf in die tyd of in die koste.

93
00:04:12,027 --> 00:04:14,110
En dit is wanneer ons begin
om te kyk na data druk.

94
00:04:14,110 --> 00:04:15,920
>> So wanneer ons kyk na die
eerste databasis, hierdie

95
00:04:15,920 --> 00:04:17,180
is die een wat tussen ons ore.

96
00:04:17,180 --> 00:04:18,310
Ons is almal gebore met dit.

97
00:04:18,310 --> 00:04:19,194
Dis 'n lekker databasis.

98
00:04:19,194 --> 00:04:21,110
Dit het 'n hoë beskikbaarheid.

99
00:04:21,110 --> 00:04:21,959
Dit is altyd op.

100
00:04:21,959 --> 00:04:23,930
Jy kan altyd dit kry.

101
00:04:23,930 --> 00:04:24,890
>> Maar dit is enkele gebruiker.

102
00:04:24,890 --> 00:04:26,348
Ek kan nie deel van my gedagtes met jou.

103
00:04:26,348 --> 00:04:28,370
Jy kan nie my gedagtes te kry
wanneer jy wil hê hulle.

104
00:04:28,370 --> 00:04:30,320
En hulle abilitiy is nie so goed nie.

105
00:04:30,320 --> 00:04:32,510
Ons vergeet dinge.

106
00:04:32,510 --> 00:04:36,540
Elke nou en dan, een van ons blare
en beweeg na 'n ander bestaan

107
00:04:36,540 --> 00:04:39,110
en ons alles verloor
dit was in daardie databasis.

108
00:04:39,110 --> 00:04:40,640
So dit is nie al wat goed is.

109
00:04:40,640 --> 00:04:43,189
>> En dit het goed gewerk met verloop van tyd
toe ons terug in die dag

110
00:04:43,189 --> 00:04:46,230
wanneer al wat ons regtig nodig het om te weet, is
waar gaan ons om te gaan op môre

111
00:04:46,230 --> 00:04:49,630
of waar ons versamel die beste kos.

112
00:04:49,630 --> 00:04:52,820
Maar as ons begin om te groei as 'n
beskawing en die regering begin

113
00:04:52,820 --> 00:04:55,152
tot stand te kom, en
besighede begin om te ontwikkel,

114
00:04:55,152 --> 00:04:57,360
ons begin om te besef ons
moet 'n bietjie meer as wat

115
00:04:57,360 --> 00:04:58,210
ons kon in ons kop sit.

116
00:04:58,210 --> 00:04:58,870
Alles reg?

117
00:04:58,870 --> 00:05:00,410
>> Ons benodig stelsels van rekord.

118
00:05:00,410 --> 00:05:02,220
Ons benodig plekke om in staat te stoor nie.

119
00:05:02,220 --> 00:05:05,450
So het ons begin skryf dokumente,
skep biblioteke en argiewe.

120
00:05:05,450 --> 00:05:08,000
Ons het begin die ontwikkeling van '
stelsel 'n grootboek rekeningkundige.

121
00:05:08,000 --> 00:05:12,200
En dat die stelsel van grootboek tel
hardloop die wêreld vir baie eeue,

122
00:05:12,200 --> 00:05:15,580
en miskien selfs millennia as
Ons soort gegroei tot die punt

123
00:05:15,580 --> 00:05:18,420
waar daardie data vrag oortref
die vermoë van die stelsels

124
00:05:18,420 --> 00:05:19,870
in staat wees om dit te bevat.

125
00:05:19,870 --> 00:05:22,070
>> En dit werklik gebeur het in die 1880's.

126
00:05:22,070 --> 00:05:22,570
Reg?

127
00:05:22,570 --> 00:05:24,390
In die 1880 Amerikaanse Sensus.

128
00:05:24,390 --> 00:05:26,976
Dit is regtig waar die draaipunt
wys moderne verwerking van data.

129
00:05:26,976 --> 00:05:28,850
Dit is die punt
wat die bedrag van die data

130
00:05:28,850 --> 00:05:32,060
wat ingesamel is deur die
Amerikaanse regering het tot die punt

131
00:05:32,060 --> 00:05:34,005
waar dit het agt jaar te verwerk.

132
00:05:34,005 --> 00:05:36,350
>> Nou, agt years-- as
jy weet, die sensus

133
00:05:36,350 --> 00:05:39,180
lopies elke 10 years-- so dit is
redelik duidelik dat deur die tyd wat ons

134
00:05:39,180 --> 00:05:41,419
het die sensus 1890,
die bedrag van die data wat

135
00:05:41,419 --> 00:05:43,210
gaan verwerk
deur die regering was

136
00:05:43,210 --> 00:05:46,335
gaan na die 10 jaar oorskry dat dit
sou neem om van stapel gestuur die nuwe sensus.

137
00:05:46,335 --> 00:05:47,250
Dit was 'n probleem.

138
00:05:47,250 --> 00:05:49,000
>> So 'n man met die naam Herman
Hollerith het saam

139
00:05:49,000 --> 00:05:52,640
en hy uitgevind eenheid rekord punch
kaarte, punch card reader, punch kaart

140
00:05:52,640 --> 00:05:58,420
tabel leer, en die versameling van
die meganismes vir hierdie tegnologie.

141
00:05:58,420 --> 00:06:01,860
En dat die maatskappy dat hy by die gevorm
tyd, saam met 'n paar van die ander,

142
00:06:01,860 --> 00:06:05,450
eintlik het een van die pilare van 'n
klein maatskappy wat ons vandag ken genoem IBM.

143
00:06:05,450 --> 00:06:08,417
>> So IBM oorspronklik in
die databasis besigheid.

144
00:06:08,417 --> 00:06:09,750
En dit is werklik wat hulle gedoen het.

145
00:06:09,750 --> 00:06:11,110
Hulle het die verwerking van data.

146
00:06:11,110 --> 00:06:15,400
>> As so die verspreiding van punch
kaarte, 'n vernuftige meganismes

147
00:06:15,400 --> 00:06:18,560
om te kan benut wat
tegnologie om gesorteerde gevolg stelle poll.

148
00:06:18,560 --> 00:06:20,726
Jy kan sien in hierdie foto
daar het ons 'n little--

149
00:06:20,726 --> 00:06:23,970
dit is 'n bietjie small-- maar jy kan sien
'n baie vernuftige meganiese meganisme

150
00:06:23,970 --> 00:06:26,970
waar ons 'n punch kaart dek.

151
00:06:26,970 --> 00:06:28,720
En neem iemand se
'n bietjie skroewedraaier

152
00:06:28,720 --> 00:06:31,400
en vas deur die
slots en hom ophef

153
00:06:31,400 --> 00:06:34,820
om die wedstryd te kry, wat
gesorteer resultate stel.

154
00:06:34,820 --> 00:06:36,270
>> Dit is 'n samevoeging.

155
00:06:36,270 --> 00:06:38,690
Ons doen dit al die tyd
vandag in die rekenaar,

156
00:06:38,690 --> 00:06:40,100
waar jy dit doen in die databasis.

157
00:06:40,100 --> 00:06:41,620
Ons gebruik word om dit te doen met die hand, reg?

158
00:06:41,620 --> 00:06:42,994
Mense het hierdie dinge saam.

159
00:06:42,994 --> 00:06:45,440
En dit was die verspreiding
van hierdie ponskaarte

160
00:06:45,440 --> 00:06:50,070
in wat ons genoem data dromme
en data rolle, papier tape.

161
00:06:50,070 --> 00:06:55,980
>> Die data verwerking bedryf het
'n les uit die speler klaviere.

162
00:06:55,980 --> 00:06:57,855
Speler klaviere terug by
die draai van die eeu

163
00:06:57,855 --> 00:07:02,100
gebruik om papier rolle met slots gebruik
op om dit te vertel wat sleutels om te speel.

164
00:07:02,100 --> 00:07:05,380
So dat die tegnologie is aangepas
uiteindelik na digitale data stoor,

165
00:07:05,380 --> 00:07:08,070
omdat hulle die data kan sit
op die papier tape rolle.

166
00:07:08,070 --> 00:07:10,870
>> Nou, as 'n gevolg, data
is actually-- hoe

167
00:07:10,870 --> 00:07:14,960
jy toegang tot hierdie data was direk
afhanklik van hoe jy dit gestoor word.

168
00:07:14,960 --> 00:07:17,825
So as ek die data op 'n band,
Ek het toegang tot die data lineêr.

169
00:07:17,825 --> 00:07:20,475
Ek moes die hele rol
band om toegang tot al die data.

170
00:07:20,475 --> 00:07:22,600
As ek die data in punch
kaarte, kon ek dit toegang

171
00:07:22,600 --> 00:07:26,270
in 'n bietjie meer random
mode, miskien nie so vinnig.

172
00:07:26,270 --> 00:07:30,770
>> Maar daar was beperkinge in hoe ons
toegang tot data op grond van hoe gestoor.

173
00:07:30,770 --> 00:07:32,890
En so was dit 'n probleem
gaan in die '50s.

174
00:07:32,890 --> 00:07:37,890
Weereens, kan ons begin om te sien dat soos ons
nuwe tegnologie te ontwikkel om te verwerk

175
00:07:37,890 --> 00:07:41,670
die data, regs, dit maak
die deur vir nuwe oplossings,

176
00:07:41,670 --> 00:07:45,852
vir nuwe programme, nuwe
aansoeke vir die data.

177
00:07:45,852 --> 00:07:47,810
En regtig, bestuur
kan die rede gewees het

178
00:07:47,810 --> 00:07:49,435
waarom ons ontwikkel 'n paar van hierdie stelsels.

179
00:07:49,435 --> 00:07:52,290
Maar besigheid vinnig geword
die bestuurder agter die evolusie

180
00:07:52,290 --> 00:07:54,720
van die moderne databasis en
die moderne lêer stelsel.

181
00:07:54,720 --> 00:07:56,870
>> So die volgende ding wat
vorendag gekom het in die jare 50

182
00:07:56,870 --> 00:08:00,780
was die lêerstelsel en die
ontwikkeling van ewetoeganklike stoor.

183
00:08:00,780 --> 00:08:02,050
Dit was pragtig.

184
00:08:02,050 --> 00:08:06,230
Nou, almal van 'n skielike, kan ons ons
lêers op enige plek op die hardeskyf

185
00:08:06,230 --> 00:08:09,760
en ons kan hierdie inligting lukraak toegang.

186
00:08:09,760 --> 00:08:11,950
Ons kan ontleed wat
inligting uit lêers.

187
00:08:11,950 --> 00:08:14,920
En ons opgelos al die wêreld se
probleme met die verwerking van data.

188
00:08:14,920 --> 00:08:17,550
>> En dat duur ongeveer 20 of
30 jaar tot die evolusie

189
00:08:17,550 --> 00:08:22,100
van die relasionele databasis, wat
is wanneer die wêreld het ons besluit nou

190
00:08:22,100 --> 00:08:27,940
moet 'n bewaarplek wat nederlae het
die uitbreiding van data oor die lêer

191
00:08:27,940 --> 00:08:29,540
stelsels wat ons gebou het. Reg?

192
00:08:29,540 --> 00:08:34,270
Te veel data versprei in te veel
plekke, die de-duplisering van data,

193
00:08:34,270 --> 00:08:37,120
en die koste van die stoor was enorm.

194
00:08:37,120 --> 00:08:43,760
>> In die 70's, die duurste hulpbron
dat 'n rekenaar gehad het, was die stoor.

195
00:08:43,760 --> 00:08:46,200
Die verwerker was
beskou as 'n vaste koste.

196
00:08:46,200 --> 00:08:49,030
Toe ek die koop van die boks,
die CPU doen 'n bietjie werk.

197
00:08:49,030 --> 00:08:51,960
Dit gaan spin of
dit is eintlik werk of nie.

198
00:08:51,960 --> 00:08:53,350
Dit is regtig 'n gesink koste.

199
00:08:53,350 --> 00:08:56,030
>> Maar wat my kos as 'n
besigheid is stoor.

200
00:08:56,030 --> 00:09:00,020
As ek meer skywe koop volgende
maand, dit is 'n werklike koste wat ek betaal.

201
00:09:00,020 --> 00:09:01,620
En dat die stoor is duur.

202
00:09:01,620 --> 00:09:05,020
>> Nou is ons vinnig vorentoe 40 jaar
en ons het 'n ander probleem.

203
00:09:05,020 --> 00:09:10,020
Die bereken is nou die
duurste hulpbron.

204
00:09:10,020 --> 00:09:11,470
Die stoor is goedkoop.

205
00:09:11,470 --> 00:09:14,570
Ek bedoel, ons kan enige plek gaan op die
wolk en ons kan goedkoop stoorplek vind.

206
00:09:14,570 --> 00:09:17,190
Maar wat ek nie kan kry nie goedkoop is bereken.

207
00:09:17,190 --> 00:09:20,700
>> So het die evolusie van vandag se
tegnologie, van die databasis tegnologie,

208
00:09:20,700 --> 00:09:23,050
regtig om gefokus
verspreide databasisse

209
00:09:23,050 --> 00:09:26,960
wat nie ly
dieselfde tipe skaal

210
00:09:26,960 --> 00:09:29,240
beperkinge van relasionele databasisse.

211
00:09:29,240 --> 00:09:32,080
Ons sal 'n bietjie praat oor
wat dit eintlik beteken.

212
00:09:32,080 --> 00:09:34,760
>> Maar een van die redes en
die bestuurder agter this-- ons

213
00:09:34,760 --> 00:09:38,290
gepraat oor die data druk.

214
00:09:38,290 --> 00:09:41,920
Data druk is iets
wat dryf innovering.

215
00:09:41,920 --> 00:09:44,610
En as jy kyk na oor
die afgelope vyf jaar,

216
00:09:44,610 --> 00:09:48,180
dit is 'n grafiek wat die data
vrag oor die algemene onderneming

217
00:09:48,180 --> 00:09:49,640
lyk soos in die laaste vyf jaar.

218
00:09:49,640 --> 00:09:52,570
>> En die algemene reël
hierdie days-- as jy gaan Google--

219
00:09:52,570 --> 00:09:55,290
is 90% van die data wat
wat ons vandag op te slaan, en dit was

220
00:09:55,290 --> 00:09:57,330
gegenereer in die laaste twee jaar.

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

222
00:09:57,911 --> 00:09:59,410
Nou, dit is nie 'n tendens wat nuut is.

223
00:09:59,410 --> 00:10:01,230
Dit is 'n tendens wat al
gaan uit vir 100 jaar.

224
00:10:01,230 --> 00:10:03,438
Herman Hollerith sedert
ontwikkel die punch kaart,

225
00:10:03,438 --> 00:10:08,040
Ons het die bou van data repositories
en versamel data op fenomenale pryse.

226
00:10:08,040 --> 00:10:10,570
>> So oor die laaste 100 jaar,
ons het hierdie tendens gesien.

227
00:10:10,570 --> 00:10:11,940
Dit gaan nie verander nie.

228
00:10:11,940 --> 00:10:14,789
Vorentoe, ons gaan om te sien
hierdie, indien nie 'n versnelde tendens.

229
00:10:14,789 --> 00:10:16,330
En jy kan sien wat dit lyk.

230
00:10:16,330 --> 00:10:23,510
>> As 'n besigheid in 2010 het een
terabyte van data onder bestuur,

231
00:10:23,510 --> 00:10:27,080
vandag beteken hulle is
besturende 6,5 petabytes van data.

232
00:10:27,080 --> 00:10:30,380
Dit is 6500 keer meer data.

233
00:10:30,380 --> 00:10:31,200
En ek weet dit.

234
00:10:31,200 --> 00:10:33,292
Ek werk met hierdie besighede elke dag.

235
00:10:33,292 --> 00:10:35,000
Vyf jaar gelede het ek
maatskappye sal praat

236
00:10:35,000 --> 00:10:38,260
wat my sou praat oor wat 'n pyn
dit is om terabyte van data te bestuur.

237
00:10:38,260 --> 00:10:39,700
En hulle sou praat
my oor hoe ons sien

238
00:10:39,700 --> 00:10:41,825
dat dit waarskynlik gaan
'n petabyte of twee wees

239
00:10:41,825 --> 00:10:43,030
binne 'n paar jaar.

240
00:10:43,030 --> 00:10:45,170
>> Hierdie selfde maatskappye
Vandag is ek die vergadering met,

241
00:10:45,170 --> 00:10:48,100
en hulle praat met my oor die
probleem is daar met die bestuur

242
00:10:48,100 --> 00:10:51,440
tien 20 petabytes van data.

243
00:10:51,440 --> 00:10:53,590
So het die ontploffing van die
data in die bedryf

244
00:10:53,590 --> 00:10:56,670
ry die enorme
nodig vir 'n beter oplossings.

245
00:10:56,670 --> 00:11:00,980
En die relasionele databasis
net nie lewe tot die vraag.

246
00:11:00,980 --> 00:11:03,490
>> En so is daar 'n lineêre
korrelasie tussen data druk

247
00:11:03,490 --> 00:11:05,210
en tegniese innovasie.

248
00:11:05,210 --> 00:11:07,780
Die geskiedenis het ons gewys
dit nie, dat met verloop van tyd,

249
00:11:07,780 --> 00:11:11,090
wanneer die volume van data
wat moet verwerk

250
00:11:11,090 --> 00:11:15,490
oorskry die kapasiteit van die stelsel
om dit te verwerk in 'n redelike tyd

251
00:11:15,490 --> 00:11:18,870
of teen 'n redelike koste,
dan nuwe tegnologie

252
00:11:18,870 --> 00:11:21,080
is uitgevind om die probleme op te los.

253
00:11:21,080 --> 00:11:24,090
Diegene nuwe tegnologie,
op sy beurt, die deur oopmaak

254
00:11:24,090 --> 00:11:27,840
na 'n ander stel probleme, wat
versamel nog meer data.

255
00:11:27,840 --> 00:11:29,520
>> Nou, ons is nie van plan om dit te stop.

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

257
00:11:30,020 --> 00:11:31,228
Ons is nie van plan om dit te stop.

258
00:11:31,228 --> 00:11:31,830
Hoekom?

259
00:11:31,830 --> 00:11:35,520
Want jy kan nie alles weet
daar is om te weet in die heelal.

260
00:11:35,520 --> 00:11:40,510
En so lank as wat ons lewe is,
regdeur die geskiedenis van die mens,

261
00:11:40,510 --> 00:11:43,440
ons het altyd gedryf om meer te leer ken.

262
00:11:43,440 --> 00:11:49,840
>> So dit lyk asof elke duim beweeg ons
af in die pad van wetenskaplike ontdekking,

263
00:11:49,840 --> 00:11:54,620
ons die bedrag van data te vermenigvuldig
wat ons nodig het om eksponensieel te verwerk

264
00:11:54,620 --> 00:11:59,920
soos ons ontbloot meer en meer en meer
oor die innerlike werking van die lewe,

265
00:11:59,920 --> 00:12:04,530
oor hoe die heelal werk, oor
ry die wetenskaplike ontdekking,

266
00:12:04,530 --> 00:12:06,440
en die uitvinding wat
ons vandag doen.

267
00:12:06,440 --> 00:12:09,570
Die volume van die data net
voortdurend toeneem.

268
00:12:09,570 --> 00:12:12,120
So in staat om te gaan met
hierdie probleem is enorm.

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

270
00:12:14,790 --> 00:12:17,410
>> So een van die dinge
ons kyk as die rede waarom NoSQL?

271
00:12:17,410 --> 00:12:19,200
Hoe NoSQL hierdie probleem op te los?

272
00:12:19,200 --> 00:12:24,980
Wel, relasionele databasisse,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- dit is regtig 'n konstruk van die
relasionele database-- hierdie dinge

274
00:12:28,600 --> 00:12:30,770
geskik vir die stoor.

275
00:12:30,770 --> 00:12:33,180
>> Terug in die 70's, weer,
skyf is duur.

276
00:12:33,180 --> 00:12:36,990
Die voorsiening van die stoor oefening
in die onderneming is nimmereindigende.

277
00:12:36,990 --> 00:12:37,490
Ek weet.

278
00:12:37,490 --> 00:12:38,020
Ek het dit.

279
00:12:38,020 --> 00:12:41,250
Ek het vir 'n stoor bestuurders
enterprised Super maatskappy

280
00:12:41,250 --> 00:12:42,470
terug in die '90s.

281
00:12:42,470 --> 00:12:45,920
En die onderste lyn is racking ander
stoor array was net iets wat

282
00:12:45,920 --> 00:12:47,600
gebeur elke dag in die onderneming.

283
00:12:47,600 --> 00:12:49,030
En dit het nooit gestop.

284
00:12:49,030 --> 00:12:52,690
Stoor hoër digtheid, vraag
vir 'n hoë digtheid stoor,

285
00:12:52,690 --> 00:12:56,340
en vir meer doeltreffende stoor
devices-- dit nooit gestop.

286
00:12:56,340 --> 00:13:00,160
>> En NoSQL is 'n groot tegnologie
want dit normaliseer die data.

287
00:13:00,160 --> 00:13:02,210
Dit de-duplikate die data.

288
00:13:02,210 --> 00:13:07,180
Dit plaas die data in 'n struktuur wat
is agnostikus elke toegang patroon.

289
00:13:07,180 --> 00:13:11,600
Verskeie programme kan getref dat
SQL databasis, hardloop ad hoc-navrae,

290
00:13:11,600 --> 00:13:15,950
en kry data in die vorm dat hulle
nodig om te verwerk vir hul werklading.

291
00:13:15,950 --> 00:13:17,570
Dit klink fantasties.

292
00:13:17,570 --> 00:13:21,350
Maar die bottom line is met enige
stelsel, as dit agnostikus alles,

293
00:13:21,350 --> 00:13:23,500
dit is geskik vir niks.

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

295
00:13:24,050 --> 00:13:26,386
>> En dit is wat ons kry met
die relasionele databasis.

296
00:13:26,386 --> 00:13:27,510
Dit is geskik vir die stoor.

297
00:13:27,510 --> 00:13:28,280
Dit is genormaliseer.

298
00:13:28,280 --> 00:13:29,370
Dit is relasionele.

299
00:13:29,370 --> 00:13:31,660
Dit ondersteun die ad hoc-navrae.

300
00:13:31,660 --> 00:13:34,000
En dit en dit skale vertikaal.

301
00:13:34,000 --> 00:13:39,030
>> As ek nodig om 'n groter SQL databasis te kry
of 'n meer kragtige SQL databasis,

302
00:13:39,030 --> 00:13:41,090
Ek gaan koop 'n groter stuk yster.

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

304
00:13:41,600 --> 00:13:44,940
Ek het gewerk met 'n baie kliënte
wat deur middel van die groot opgraderings gewees

305
00:13:44,940 --> 00:13:48,340
in hul SQL infrastruktuur net
om uit te vind ses maande later,

306
00:13:48,340 --> 00:13:49,750
hulle weer slaan die muur.

307
00:13:49,750 --> 00:13:55,457
En die antwoord van Oracle of MSSQL
of enigiemand anders is kry 'n groter boks.

308
00:13:55,457 --> 00:13:58,540
Wel vroeër of later, kan jy nie koop 'n
groter boks, en dit is die werklike probleem.

309
00:13:58,540 --> 00:14:00,080
Ons moet eintlik dinge verander.

310
00:14:00,080 --> 00:14:01,080
So waar werk dit?

311
00:14:01,080 --> 00:14:06,560
Dit werk goed vir die regte
analytics, OLAP-tipe werklading.

312
00:14:06,560 --> 00:14:08,670
En dit is regtig waar SQL behoort.

313
00:14:08,670 --> 00:14:12,540
Nou, dit vandag gebruik word in baie online
transaksionele verwerking-tipe

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

315
00:14:13,330 --> 00:14:16,460
En dit werk net mooi op
'n sekere vlak van benutting,

316
00:14:16,460 --> 00:14:18,670
maar dit is net nie die skaal
die manier waarop NoSQL doen.

317
00:14:18,670 --> 00:14:20,660
En ons sal 'n bietjie praat
bietjie oor waarom dit.

318
00:14:20,660 --> 00:14:23,590
>> Nou, NoSQL, aan die ander kant,
is meer geskik vir bereken.

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

320
00:14:24,540 --> 00:14:26,830
Dit is nie agnosties te
die toegang patroon.

321
00:14:26,830 --> 00:14:31,620
Is wat ons noem de-genormaliseer
struktuur of 'n hiërargiese struktuur.

322
00:14:31,620 --> 00:14:35,000
Die data in 'n relasionele databasis is
saamgevoeg uit verskeie tafels

323
00:14:35,000 --> 00:14:36,850
die siening wat jy nodig het te produseer.

324
00:14:36,850 --> 00:14:40,090
Die data in 'n databasis NoSQL
word gestoor in 'n dokument wat

325
00:14:40,090 --> 00:14:42,100
bevat die hiërargiese struktuur.

326
00:14:42,100 --> 00:14:45,670
Al die data wat normaalweg sou wees
saamgevoeg om daardie siening te produseer

327
00:14:45,670 --> 00:14:47,160
word gestoor in 'n enkele dokument.

328
00:14:47,160 --> 00:14:50,990
En ons sal 'n bietjie praat oor
hoe dit werk in 'n paar van die kaarte.

329
00:14:50,990 --> 00:14:55,320
>> Maar die idee hier is dat jy te slaan
jou data as hierdie geïnstantieert uitsig.

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

331
00:14:56,410 --> 00:14:58,610
Jy skaal horisontaal.

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

333
00:14:59,556 --> 00:15:02,100
As ek nodig het om die verhoog
grootte van my NoSQL cluster,

334
00:15:02,100 --> 00:15:03,700
Ek het nie nodig om 'n groter boks te kry.

335
00:15:03,700 --> 00:15:05,200
Ek kry 'n ander boks.

336
00:15:05,200 --> 00:15:07,700
En ek cluster wat saam
en ek kan die data segment.

337
00:15:07,700 --> 00:15:10,780
Ons sal 'n bietjie praat oor
wat sharding is, te wees

338
00:15:10,780 --> 00:15:14,270
in staat wees om die skaal wat databasis
oor verskeie fisiese toestelle

339
00:15:14,270 --> 00:15:18,370
en verwyder die versperring wat
vereis dat my vertikaal skaal.

340
00:15:18,370 --> 00:15:22,080
>> So dit is regtig gebou vir aanlyn
transaksie verwerking en skaal.

341
00:15:22,080 --> 00:15:25,480
Daar is 'n groot onderskeid
hier tussen verslaggewing, reg?

342
00:15:25,480 --> 00:15:27,810
Verslagdoening, weet ek nie die
vrae ek gaan om te vra.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- as iemand uit
my bemarking afdeling

345
00:15:30,570 --> 00:15:34,520
wil hoeveel van my kliënte just--
hierdie besondere kenmerk wat

346
00:15:34,520 --> 00:15:37,850
gekoop op hierdie day-- Ek weet nie
wat navraag hulle gaan om te vra.

347
00:15:37,850 --> 00:15:39,160
So ek moet agnostikus te wees.

348
00:15:39,160 --> 00:15:41,810
>> Nou, in 'n aanlyn
transaksionele aansoek,

349
00:15:41,810 --> 00:15:43,820
Ek weet watter vrae wat ek vra.

350
00:15:43,820 --> 00:15:46,581
Ek, die aansoek om gebou
'n baie spesifieke workflow.

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

352
00:15:47,080 --> 00:15:50,540
So as ek optimaliseer die data
stoor wat workflow ondersteun,

353
00:15:50,540 --> 00:15:52,020
dit gaan vinniger.

354
00:15:52,020 --> 00:15:55,190
En dit is hoekom NoSQL kan
regtig versnel die lewering

355
00:15:55,190 --> 00:15:57,710
van hierdie tipe van dienste.

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

357
00:15:58,210 --> 00:16:00,501
>> So ons gaan om te kry in
'n bietjie van die teorie hier.

358
00:16:00,501 --> 00:16:03,330
En 'n paar van julle, julle oë
kan rol terug 'n bietjie.

359
00:16:03,330 --> 00:16:06,936
Maar ek sal probeer om dit te hou
as hoë vlak as wat ek kan.

360
00:16:06,936 --> 00:16:08,880
So as jy in die projek
bestuur, is daar

361
00:16:08,880 --> 00:16:12,280
'n konstruk genoem
driehoek van beperkings.

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

363
00:16:12,936 --> 00:16:16,060
Die driehoek van beperkings voorskrifte
jy kan nie alles het al die tyd.

364
00:16:16,060 --> 00:16:17,750
Kan nie jou pie en eet dit ook.

365
00:16:17,750 --> 00:16:22,310
So in die projek bestuur, die driehoek
beperkings is, kan jy dit goedkoop te hê,

366
00:16:22,310 --> 00:16:24,710
jy kan dit vinnig het,
of jy kan dit goed.

367
00:16:24,710 --> 00:16:25,716
Kies twee.

368
00:16:25,716 --> 00:16:27,090
Want jy kan nie al drie.

369
00:16:27,090 --> 00:16:27,460
Reg?

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

371
00:16:27,820 --> 00:16:28,920
>> So jy hoor oor hierdie 'n baie.

372
00:16:28,920 --> 00:16:31,253
Dit is 'n driedubbele beperking,
driehoek van driedubbele beperking,

373
00:16:31,253 --> 00:16:34,420
of die yster driehoek is oftentimes--
wanneer jy praat met bestuurders projekteer,

374
00:16:34,420 --> 00:16:35,420
hulle sal praat oor hierdie.

375
00:16:35,420 --> 00:16:37,640
Nou, databasisse
hul eie yster driehoek.

376
00:16:37,640 --> 00:16:40,350
En die yster driehoek van data
is wat ons CAP stelling noem.

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

378
00:16:41,580 --> 00:16:43,770
>> CAP stelling voorskrifte
hoe databasisse bedryf

379
00:16:43,770 --> 00:16:45,627
onder 'n baie spesifieke toestand.

380
00:16:45,627 --> 00:16:47,460
En ons sal praat oor
wat daardie toestand is.

381
00:16:47,460 --> 00:16:52,221
Maar die drie punte van die driehoek,
om so te praat, is C, konsekwentheid.

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

383
00:16:52,720 --> 00:16:56,760
So in CAP, konsekwentheid beteken dat alle
kliënte wat toegang tot die databasis

384
00:16:56,760 --> 00:16:59,084
sal altyd 'n baie
konsekwent siening van data.

385
00:16:59,084 --> 00:17:00,750
Gaan niemand kyk twee verskillende dinge.

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

387
00:17:01,480 --> 00:17:04,020
As ek sien die databasis,
Ek sien dieselfde siening

388
00:17:04,020 --> 00:17:06,130
as my vennoot wat sien
dieselfde databasis.

389
00:17:06,130 --> 00:17:07,470
Dit is konsekwentheid.

390
00:17:07,470 --> 00:17:12,099
>> Beskikbaarheid beteken dat indien die
databasis online, as dit bereik kan word,

391
00:17:12,099 --> 00:17:14,760
dat alle kliënte sal altyd
in staat wees om te lees en skryf.

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

393
00:17:15,260 --> 00:17:17,010
Sodat elke kliënt wat
kan die databasis te lees

394
00:17:17,010 --> 00:17:18,955
sal altyd in staat wees lees
data en skryf data.

395
00:17:18,955 --> 00:17:21,819
En as dit die geval is,
dit is 'n beskikbare stelsel.

396
00:17:21,819 --> 00:17:24,230
>> En die derde punt is wat
ons noem partisie verdraagsaamheid.

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

398
00:17:24,730 --> 00:17:28,160
Partition verdraagsaamheid middel
dat die stelsel werk goed

399
00:17:28,160 --> 00:17:32,000
ondanks fisiese netwerk
mure tussen die nodes.

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

401
00:17:32,760 --> 00:17:36,270
So nodusse in die cluster kan nie
met mekaar praat, wat gebeur?

402
00:17:36,270 --> 00:17:36,880
Alles reg.

403
00:17:36,880 --> 00:17:39,545
>> So relasionele databasisse choose
kan jy twee van hierdie te kies.

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

405
00:17:40,045 --> 00:17:43,680
So relasionele databasisse te kies
wees konsekwent en beskikbaar is.

406
00:17:43,680 --> 00:17:47,510
As die verdeling gebeur tussen
die DataNodes in die data stoor,

407
00:17:47,510 --> 00:17:48,831
die databasis ineenstortings.

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

409
00:17:49,330 --> 00:17:50,900
Dit gaan net af.

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

411
00:17:51,450 --> 00:17:54,230
>> En dit is die rede waarom hulle
om te groei met 'n groter bokse.

412
00:17:54,230 --> 00:17:54,730
Reg?

413
00:17:54,730 --> 00:17:58,021
Want daar is no-- gewoonlik, 'n cluster
databasis, daar is nie baie van hulle

414
00:17:58,021 --> 00:17:59,590
wat werk op die manier.

415
00:17:59,590 --> 00:18:03,019
Maar die meeste databasisse skaal
vertikaal binne 'n enkele vak.

416
00:18:03,019 --> 00:18:05,060
Omdat hulle nodig het om te wees
konsekwent en beskikbaar is.

417
00:18:05,060 --> 00:18:10,320
As 'n partisie was ingespuit,
dan sou jy 'n keuse te maak.

418
00:18:10,320 --> 00:18:13,720
Jy het 'n keuse te maak tussen
konsekwent en beskikbaar is.

419
00:18:13,720 --> 00:18:16,080
>> En dit is wat NoSQL databasisse te doen.

420
00:18:16,080 --> 00:18:16,580
Alles reg.

421
00:18:16,580 --> 00:18:20,950
So 'n NoSQL databasis, is dit
kom in twee geure.

422
00:18:20,950 --> 00:18:22,990
Ons have-- Wel, dit
kom in baie geure,

423
00:18:22,990 --> 00:18:26,140
maar dit kom met twee basiese
characteristics-- wat

424
00:18:26,140 --> 00:18:30,050
sou ons CP databasis, of 'n roep
konsekwent en verdeling verdraagsaamheid

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

426
00:18:31,040 --> 00:18:34,930
Hierdie ouens die keuse maak dat wanneer
die nodes verloor kontak met mekaar,

427
00:18:34,930 --> 00:18:37,091
ons gaan nie toelaat dat
mense om meer te skryf.

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

429
00:18:37,590 --> 00:18:41,855
>> Tot op daardie verdeling verwyder word,
skryftoegang is geblokkeer.

430
00:18:41,855 --> 00:18:43,230
Dit beteken hulle is nie beskikbaar nie.

431
00:18:43,230 --> 00:18:44,510
Hulle is konsekwent.

432
00:18:44,510 --> 00:18:46,554
Wanneer ons sien dat
partisie spuit self,

433
00:18:46,554 --> 00:18:48,470
ons is nou konsekwent,
want ons gaan nie

434
00:18:48,470 --> 00:18:51,517
om die data verandering op twee toelaat
kante van die verdeling onafhanklik

435
00:18:51,517 --> 00:18:52,100
van mekaar.

436
00:18:52,100 --> 00:18:54,130
Ons sal moet
herstel kommunikasie

437
00:18:54,130 --> 00:18:56,930
voordat enige werk na
die data word toegelaat nie.

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

439
00:18:58,120 --> 00:19:02,650
>> Die volgende geur sou 'n AP stelsel,
of 'n beskikbare en verdeel

440
00:19:02,650 --> 00:19:03,640
verdraagsaamheid stelsel.

441
00:19:03,640 --> 00:19:05,320
Hierdie ouens nie omgee nie.

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

443
00:19:06,020 --> 00:19:08,960
Enige node dat 'n kry
skryf, ons sal dit vat.

444
00:19:08,960 --> 00:19:11,480
So ek replicerende my data
oor verskeie nodes.

445
00:19:11,480 --> 00:19:14,730
Hierdie nodes kry 'n kliënt, kliënt kom
in, sê, ek gaan 'n paar data te skryf.

446
00:19:14,730 --> 00:19:16,300
Node sê, geen probleem.

447
00:19:16,300 --> 00:19:18,580
Die node langs hom kry
'n skryf op dieselfde rekord,

448
00:19:18,580 --> 00:19:20,405
hy gaan nie 'n probleem te sê.

449
00:19:20,405 --> 00:19:23,030
Iewers weer op die einde terug,
dat die data gaan herhaal.

450
00:19:23,030 --> 00:19:27,360
En dan iemand gaan om te besef,
uh-oh, het hulle stelsel sal besef, uh-oh,

451
00:19:27,360 --> 00:19:28,870
daar is 'n werk na twee kante.

452
00:19:28,870 --> 00:19:30,370
Wat doen ons?

453
00:19:30,370 --> 00:19:33,210
En wat hulle doen dan is
hulle iets doen wat

454
00:19:33,210 --> 00:19:36,080
hulle toelaat om die data staat te los.

455
00:19:36,080 --> 00:19:39,000
En ons sal praat oor
dat in die volgende grafiek.

456
00:19:39,000 --> 00:19:40,000
>> Ding om te wys hier.

457
00:19:40,000 --> 00:19:42,374
En ek is nie van plan om te kry
veel in hierdie, want dit

458
00:19:42,374 --> 00:19:43,510
kry in diep data teorie.

459
00:19:43,510 --> 00:19:46,670
Maar daar is 'n transaksionele
raamwerk wat

460
00:19:46,670 --> 00:19:50,680
lopies in 'n relasionele stelsel wat
laat my toe om veilig te maak updates

461
00:19:50,680 --> 00:19:53,760
verskeie entiteite in die databasis.

462
00:19:53,760 --> 00:19:58,320
En diegene updates sal plaasvind
alles op een slag, of glad nie.

463
00:19:58,320 --> 00:20:00,500
En dit is genoem ACID transaksies.

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

465
00:20:01,000 --> 00:20:06,570
>> Suur gee ons atomiciteit, konsekwentheid,
isolasie, en duursaamheid.

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

467
00:20:07,070 --> 00:20:13,550
Dit beteken atoom, transaksies, al
my updates óf gebeur of hulle doen nie.

468
00:20:13,550 --> 00:20:16,570
Konsekwentheid beteken dat
die databasis sal altyd

469
00:20:16,570 --> 00:20:19,780
in 'n bestendige gebring
staat na 'n update.

470
00:20:19,780 --> 00:20:23,900
Ek sal nooit die databasis in 'n los
swak toestand na die toepassing van 'n update.

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

472
00:20:24,400 --> 00:20:26,720
>> So dit is 'n bietjie anders
as CAP konsekwentheid.

473
00:20:26,720 --> 00:20:29,760
CAP konsekwentheid beteken al my
kliënte kan altyd die data.

474
00:20:29,760 --> 00:20:34,450
ACID konsekwentheid beteken dat wanneer
'n transaksie gedoen is, se data goed.

475
00:20:34,450 --> 00:20:35,709
My verhoudings is alles goed.

476
00:20:35,709 --> 00:20:38,750
Ek is nie van plan om 'n ouer ry verwyder
en laat 'n klomp van die weeskinders

477
00:20:38,750 --> 00:20:40,970
in 'n ander tafel.

478
00:20:40,970 --> 00:20:44,320
Dit kan nie gebeur as ek is konsekwent
in 'n suur transaksie.

479
00:20:44,320 --> 00:20:49,120
>> Isolasie beteken dat transaksies
sal altyd voorkom een ​​na die ander.

480
00:20:49,120 --> 00:20:51,920
Die eindresultaat van die data
sal dieselfde wees staat

481
00:20:51,920 --> 00:20:54,770
asof daardie transaksies
wat gelyktydig uitgereik

482
00:20:54,770 --> 00:20:57,340
is in volgorde uitgevoer word.

483
00:20:57,340 --> 00:21:00,030
So dit is concurrency
beheer in die databasis.

484
00:21:00,030 --> 00:21:04,130
So basies, ek kan nie inkrementeer die
dieselfde waarde twee keer met twee operasies.

485
00:21:04,130 --> 00:21:08,580
>> Maar as ek sê voeg 1 op hierdie waarde,
en twee transaksies kom in

486
00:21:08,580 --> 00:21:10,665
en probeer om dit te doen, is die een
gaan om daar eers

487
00:21:10,665 --> 00:21:12,540
en die ander een se
gaan om daar na te kry.

488
00:21:12,540 --> 00:21:15,210
So op die ou end, het ek nog twee.

489
00:21:15,210 --> 00:21:16,170
Jy sien wat ek bedoel?

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
>> Duursaamheid is redelik eenvoudig.

493
00:21:21,250 --> 00:21:23,460
Wanneer die transaksie
erken word, is dit

494
00:21:23,460 --> 00:21:26,100
gaan om daar te wees, selfs
As die stelsel ineenstort.

495
00:21:26,100 --> 00:21:29,230
Wanneer die stelsel herstel, wat
transaksie wat gepleeg is

496
00:21:29,230 --> 00:21:30,480
is eintlik gaan om daar te wees.

497
00:21:30,480 --> 00:21:33,130
So wat is die waarborg
suur transaksies.

498
00:21:33,130 --> 00:21:35,470
Dit is redelik mooi waarborge
om op 'n databasis,

499
00:21:35,470 --> 00:21:36,870
maar hulle kom op daardie koste.

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

501
00:21:37,640 --> 00:21:40,520
>> Want die probleem
met hierdie raamwerk is

502
00:21:40,520 --> 00:21:44,540
indien daar 'n muur in die data
stel, ek het 'n besluit te neem.

503
00:21:44,540 --> 00:21:48,000
Ek gaan om te laat
updates aan die een kant of die ander.

504
00:21:48,000 --> 00:21:50,310
En as dit gebeur,
dan is ek nie meer gaan

505
00:21:50,310 --> 00:21:52,630
in staat wees om in stand te hou
daardie eienskappe.

506
00:21:52,630 --> 00:21:53,960
Hulle sal nie konsekwent wees.

507
00:21:53,960 --> 00:21:55,841
Hulle sal nie geïsoleer word.

508
00:21:55,841 --> 00:21:58,090
Dit is waar dit breek
vir relasionele databasisse.

509
00:21:58,090 --> 00:22:01,360
Dit is die rede relasionele
databasisse skaal vertikaal.

510
00:22:01,360 --> 00:22:05,530
>> Aan die ander kant, het ons
wat genoem BASE tegnologie.

511
00:22:05,530 --> 00:22:07,291
En dit is jou NoSQL Databasisse.

512
00:22:07,291 --> 00:22:07,790
Alles reg.

513
00:22:07,790 --> 00:22:10,180
So het ons ons CP, AP databasisse.

514
00:22:10,180 --> 00:22:14,720
En dit is wat jy basies noem
beskikbaar, sagte staat, uiteindelik

515
00:22:14,720 --> 00:22:15,740
konsekwent.

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

517
00:22:16,420 --> 00:22:19,690
>> Basies beskikbaar nie, omdat
hulle is partisie verdraagsaam.

518
00:22:19,690 --> 00:22:21,470
Hulle sal altyd
daar, selfs al is daar

519
00:22:21,470 --> 00:22:23,053
'n netwerk afskorting tussen die nodes.

520
00:22:23,053 --> 00:22:25,900
As ek 'n node kan praat, ek is
gaan in staat wees om data te lees.

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

522
00:22:26,460 --> 00:22:30,810
Ek kan nie altyd in staat wees om te skryf
data as ek 'n konsekwente platform.

523
00:22:30,810 --> 00:22:32,130
Maar ek sal in staat wees om data te lees.

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

525
00:22:34,960 --> 00:22:38,010
>> Die sagte staat dui
dat wanneer ek lees dat data,

526
00:22:38,010 --> 00:22:40,790
dit kan nie dieselfde as die ander nodes wees.

527
00:22:40,790 --> 00:22:43,390
As 'n reg op 'n node is uitgereik
iewers anders in die cluster

528
00:22:43,390 --> 00:22:46,650
en dit het nie herhaal oor die
cluster nog toe ek lees dat die data,

529
00:22:46,650 --> 00:22:48,680
dat die staat kan nie konsekwent wees.

530
00:22:48,680 --> 00:22:51,650
Dit sal egter wees
uiteindelik konsekwent,

531
00:22:51,650 --> 00:22:53,870
Dit beteken dat wanneer 'n skryf
gemaak om die stelsel,

532
00:22:53,870 --> 00:22:56,480
dit sal herhaal oor die nodes.

533
00:22:56,480 --> 00:22:59,095
En uiteindelik, dat die staat
in orde gebring sal word,

534
00:22:59,095 --> 00:23:00,890
en dit sal 'n konsekwente staat.

535
00:23:00,890 --> 00:23:05,000
>> Nou, CAP stelling regtig
speel net in een voorwaarde.

536
00:23:05,000 --> 00:23:08,700
Dit toestand wanneer dit gebeur.

537
00:23:08,700 --> 00:23:13,710
Want wanneer dit wat in
normale modus, daar is geen partisie,

538
00:23:13,710 --> 00:23:16,370
alles is konsekwent en beskikbaar is.

539
00:23:16,370 --> 00:23:19,990
Jy bekommer slegs sowat CAP
wanneer ons dat partisie.

540
00:23:19,990 --> 00:23:21,260
So dit is skaars.

541
00:23:21,260 --> 00:23:25,360
Maar hoe die stelsel reageer wanneer daardie
voorkom dikteer watter tipe stelsel

542
00:23:25,360 --> 00:23:26,750
ons te doen het met.

543
00:23:26,750 --> 00:23:31,110
>> So laat ons neem 'n blik op wat
wat lyk soos vir AP stelsels.

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

545
00:23:32,621 --> 00:23:34,830
AP stelsels kom in twee weergawes.

546
00:23:34,830 --> 00:23:38,514
Hulle kom in die geur wat 'n
meester meester, 100%, altyd beskikbaar.

547
00:23:38,514 --> 00:23:40,430
En hulle kom in die
ander geur, wat sê,

548
00:23:40,430 --> 00:23:43,330
jy weet wat, ek gaan om te bekommer
oor hierdie skeiding ding

549
00:23:43,330 --> 00:23:44,724
wanneer 'n werklike verdeling plaasvind.

550
00:23:44,724 --> 00:23:47,890
Andersins, daar gaan primêre wees
nodes wie gaan die regte te neem.

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

552
00:23:48,500 --> 00:23:50,040
>> So as ons iets soos Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra sal 'n meester wees
meester, laat my skryf aan enige node.

554
00:23:54,440 --> 00:23:55,540
So wat gebeur?

555
00:23:55,540 --> 00:23:58,270
So ek het 'n voorwerp in die
databasis wat bestaan ​​op twee nodes.

556
00:23:58,270 --> 00:24:01,705
Kom ons noem daardie voorwerp S.
So ons het die staat vir die S.

557
00:24:01,705 --> 00:24:04,312
Ons het 'n paar operasies
op S wat aan die gang.

558
00:24:04,312 --> 00:24:06,270
Cassandra laat my toe om
skryf aan verskeie nodes.

559
00:24:06,270 --> 00:24:08,550
So kom ons sê ek kry 'n
skryf s twee nodes.

560
00:24:08,550 --> 00:24:12,274
Wel, wat eindig gebeur is
ons noem dat 'n skeiding gebeurtenis.

561
00:24:12,274 --> 00:24:14,190
Daar kan nie 'n
fisiese netwerk partisie.

562
00:24:14,190 --> 00:24:15,950
Maar as gevolg van die ontwerp
van die stelsel, dit is

563
00:24:15,950 --> 00:24:18,449
eintlik skeiding so gou
as ek 'n skryf op twee nodes.

564
00:24:18,449 --> 00:24:20,830
Dit is vir my nie dwing om
skryf al deur een knoop.

565
00:24:20,830 --> 00:24:22,340
Ek skryf op twee nodes.

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

567
00:24:23,330 --> 00:24:25,740
>> So nou het ek twee state.

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

569
00:24:26,360 --> 00:24:28,110
Wat gaan gebeur
is vroeër of later,

570
00:24:28,110 --> 00:24:29,960
daar gaan 'n replikasie gebeurtenis.

571
00:24:29,960 --> 00:24:33,300
Daar gaan wees wat ons
bekend as 'n partisie herstel, wat

572
00:24:33,300 --> 00:24:35,200
is waar hierdie twee
state saam te kom terug

573
00:24:35,200 --> 00:24:37,310
en daar gaan 'n algoritme wees
wat loop in die databasis,

574
00:24:37,310 --> 00:24:38,540
besluit wat om te doen.

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

576
00:24:39,110 --> 00:24:43,057
By verstek, laaste update
wen in die meeste AP stelsels.

577
00:24:43,057 --> 00:24:44,890
So is daar gewoonlik 'n
standaard algoritme, wat

578
00:24:44,890 --> 00:24:47,400
hulle noem 'n terugbel
funksie, iets wat

579
00:24:47,400 --> 00:24:51,000
sal genoem word wanneer hierdie toestand
bespeur 'n paar logika voer

580
00:24:51,000 --> 00:24:52,900
dat die konflik op te los.

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

582
00:24:53,850 --> 00:24:58,770
Die standaard terugbel en standaard
resolver in die meeste AP databasisse

583
00:24:58,770 --> 00:25:01,130
is, raai wat, tyd stempel wen.

584
00:25:01,130 --> 00:25:02,380
Dit was die laaste update.

585
00:25:02,380 --> 00:25:04,320
Ek gaan dit update daar sit.

586
00:25:04,320 --> 00:25:08,440
Ek kan hierdie rekord stort dat ek
gestort af in 'n herstel log

587
00:25:08,440 --> 00:25:11,670
sodat die gebruiker later terug kan kom
en sê, hey, was daar 'n botsing.

588
00:25:11,670 --> 00:25:12,320
Wat het gebeur?

589
00:25:12,320 --> 00:25:16,370
En jy kan eintlik stort 'n rekord van
al die botsings en die rollbacks

590
00:25:16,370 --> 00:25:17,550
en kyk wat gebeur.

591
00:25:17,550 --> 00:25:21,580
>> Nou, as 'n gebruiker, kan jy ook
sluit logika in die callback.

592
00:25:21,580 --> 00:25:24,290
So jy kan dit verander
terugbel operasie.

593
00:25:24,290 --> 00:25:26,730
Jy kan sê, hey, ek wil
om hierdie data te remedieer.

594
00:25:26,730 --> 00:25:28,880
En ek wil om te probeer en
saamsmelt daardie twee rekords.

595
00:25:28,880 --> 00:25:30,050
Maar dit is aan jou.

596
00:25:30,050 --> 00:25:32,880
Die databasis weet nie hoe om
dit doen deur verstek. Die meeste van die tyd,

597
00:25:32,880 --> 00:25:34,850
die enigste ding wat die databasis
weet hoe om te doen is sê,

598
00:25:34,850 --> 00:25:36,100
hierdie een was die laaste rekord.

599
00:25:36,100 --> 00:25:39,183
Dit is die een wat gaan om te wen,
en dit is die waarde ek gaan sit.

600
00:25:39,183 --> 00:25:41,490
Sodra dit partisie herstel
en replisering plaasvind,

601
00:25:41,490 --> 00:25:43,930
ons het ons staat, wat
is nou se prima, wat

602
00:25:43,930 --> 00:25:46,890
die merge toestand van al die voorwerpe.

603
00:25:46,890 --> 00:25:49,700
So AP stelsels hierdie.

604
00:25:49,700 --> 00:25:51,615
CP stelsels hoef nie
te bekommer hieroor.

605
00:25:51,615 --> 00:25:54,490
Want sodra 'n partisie kom
in die spel, het hulle net ophou om

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

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

608
00:25:56,180 --> 00:25:58,670
So dit is baie maklik om te
hanteer konsekwent

609
00:25:58,670 --> 00:26:01,330
as jy nie enige updates te aanvaar.

610
00:26:01,330 --> 00:26:04,620
Dit is met CP stelsels te doen.

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

612
00:26:05,120 --> 00:26:07,590
>> So laat ons praat 'n bietjie
bietjie oor toegang patrone.

613
00:26:07,590 --> 00:26:11,580
Wanneer ons praat oor NoSQL, dit is
alles oor die toegang patroon.

614
00:26:11,580 --> 00:26:13,550
Nou, SQL is ad hoc, navrae.

615
00:26:13,550 --> 00:26:14,481
Dit is relasionele winkel.

616
00:26:14,481 --> 00:26:16,480
Ons hoef nie te bekommer
oor die toegang patroon.

617
00:26:16,480 --> 00:26:17,688
Ek skryf 'n baie komplekse navraag.

618
00:26:17,688 --> 00:26:19,250
Dit gaan en die data kry.

619
00:26:19,250 --> 00:26:21,210
Dit is wat dit lyk
soos, normalisering.

620
00:26:21,210 --> 00:26:24,890
>> So in hierdie spesifieke struktuur,
Ons is op soek na 'n produk katalogus.

621
00:26:24,890 --> 00:26:26,640
Ek het verskillende tipes van produkte.

622
00:26:26,640 --> 00:26:27,217
Ek het boeke.

623
00:26:27,217 --> 00:26:27,800
Ek het albums.

624
00:26:27,800 --> 00:26:30,090
Ek het video's.

625
00:26:30,090 --> 00:26:33,370
Die verhouding tussen produkte
en enige een van hierdie boeke, albums,

626
00:26:33,370 --> 00:26:34,860
en videos tafels is 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Ek het 'n produk ID,
en dat ID ooreenstem

629
00:26:38,860 --> 00:26:41,080
om 'n boek, 'n album, of 'n video.

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

631
00:26:41,580 --> 00:26:44,350
Dit is 'n 1: 1 verhouding
oor die tafels.

632
00:26:44,350 --> 00:26:46,970
>> Nou, al wat hulle books--
het, is die wortel eienskappe.

633
00:26:46,970 --> 00:26:47,550
Geen probleem.

634
00:26:47,550 --> 00:26:48,230
Dit is 'n groot.

635
00:26:48,230 --> 00:26:52,130
Een-tot-een verhouding, ek kry al
die data wat ek nodig het om daardie boek beskryf.

636
00:26:52,130 --> 00:26:54,770
Albums-- albums het spore.

637
00:26:54,770 --> 00:26:56,470
Dit is wat ons een baie bel.

638
00:26:56,470 --> 00:26:58,905
Elke album kon baie spore.

639
00:26:58,905 --> 00:27:00,780
So vir elke snit op
die album, kon ek

640
00:27:00,780 --> 00:27:02,570
nog 'n rekord in hierdie kind tafel.

641
00:27:02,570 --> 00:27:04,680
So ek een skep rekord
in my albums tafel.

642
00:27:04,680 --> 00:27:06,700
Ek verskeie rekords te skep
in die tabel spore.

643
00:27:06,700 --> 00:27:08,850
Een-tot-baie-verhouding.

644
00:27:08,850 --> 00:27:11,220
>> Hierdie verhouding is wat
noem ons baie-tot-baie.

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

646
00:27:11,750 --> 00:27:17,000
Jy sien dat die akteurs kan wees
in baie films, baie videos.

647
00:27:17,000 --> 00:27:21,450
So wat ons doen, is sit ons dit kartering
tabel tussen die wat dit net

648
00:27:21,450 --> 00:27:24,040
kaarte van die akteur ID om die video ID.

649
00:27:24,040 --> 00:27:28,464
Nou kan ek 'n navraag van die sluit skep
videos deur akteur video om akteurs,

650
00:27:28,464 --> 00:27:31,130
en dit gee my 'n lekker lys van
al die films en al die akteurs

651
00:27:31,130 --> 00:27:32,420
wat in daardie fliek was.

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

653
00:27:33,290 --> 00:27:33,880
So hier gaan ons.

654
00:27:33,880 --> 00:27:38,040
Een-tot-een is die top-vlak
verhouding; een-tot-baie,

655
00:27:38,040 --> 00:27:40,240
albums om spore; baie-tot-baie.

656
00:27:40,240 --> 00:27:44,990
Dit is die drie top-vlak
verhoudings in 'n databasis.

657
00:27:44,990 --> 00:27:48,050
As jy weet hoe die
verhoudings werk saam,

658
00:27:48,050 --> 00:27:51,490
dan weet jy 'n baie
oor databasis reeds.

659
00:27:51,490 --> 00:27:55,660
So NoSQL werk 'n bietjie anders.

660
00:27:55,660 --> 00:27:58,930
Kom ons dink oor vir 'n tweede wat dit
lyk om te gaan kry al my produkte.

661
00:27:58,930 --> 00:28:01,096
>> In 'n relasionele winkel, ek
wil al my produkte te kry

662
00:28:01,096 --> 00:28:02,970
op 'n lys van al my produkte.

663
00:28:02,970 --> 00:28:04,910
Dit is 'n baie navrae.

664
00:28:04,910 --> 00:28:07,030
Ek het 'n navraag vir al my boeke.

665
00:28:07,030 --> 00:28:08,470
Ek het 'n navraag van my albums.

666
00:28:08,470 --> 00:28:09,970
En ek het 'n navraag vir al my videos.

667
00:28:09,970 --> 00:28:11,719
En ek het om dit te sit
almal saam in 'n lys

668
00:28:11,719 --> 00:28:15,250
en dien dit terug na die
program wat is wat dit versoek.

669
00:28:15,250 --> 00:28:18,000
>> Om my boeke te kry, sluit ek by
Produkte en boeke.

670
00:28:18,000 --> 00:28:21,680
Om my albums te kry, ek het om aan te sluit
Produkte, albums en liedjies.

671
00:28:21,680 --> 00:28:25,330
En om my video's te kry, ek het
na Produkte sluit in video's,

672
00:28:25,330 --> 00:28:28,890
sluit deur akteur video's,
en bring die akteurs.

673
00:28:28,890 --> 00:28:31,020
So dit is drie navrae.

674
00:28:31,020 --> 00:28:34,560
Baie komplekse navrae aan
vergader een gevolg stel.

675
00:28:34,560 --> 00:28:36,540
>> Dit is minder as optimale.

676
00:28:36,540 --> 00:28:39,200
Dit is hoekom wanneer ons praat
oor 'n datastruktuur wat

677
00:28:39,200 --> 00:28:42,900
gebou agnostikus die toegang te wees
pattern-- goed dit is groot.

678
00:28:42,900 --> 00:28:45,730
En jy kan sien dit is regtig
mooi hoe ons die data het georganiseer.

679
00:28:45,730 --> 00:28:46,550
En jy weet wat?

680
00:28:46,550 --> 00:28:49,750
Ek het net een rekord vir 'n akteur.

681
00:28:49,750 --> 00:28:50,440
>> Dis koel.

682
00:28:50,440 --> 00:28:53,750
Ek het al my akteurs deduplicated,
en ek behou my verenigings

683
00:28:53,750 --> 00:28:55,200
in hierdie kartering tafel.

684
00:28:55,200 --> 00:29:00,620
Maar, kry die data
uit raak duur.

685
00:29:00,620 --> 00:29:04,500
Ek stuur die CPU regoor die stelsel
by hierdie data strukture saam

686
00:29:04,500 --> 00:29:05,950
in staat wees om die data terug te trek.

687
00:29:05,950 --> 00:29:07,310
>> So hoe kry ek rond dit?

688
00:29:07,310 --> 00:29:11,200
In NoSQL dit gaan oor
samevoeging, nie normalisering.

689
00:29:11,200 --> 00:29:13,534
So wil ons sê ons wil
ondersteun die toegang patroon.

690
00:29:13,534 --> 00:29:15,283
As die toegang patroon
om die aansoeke,

691
00:29:15,283 --> 00:29:16,770
Ek moet al my produkte te kry.

692
00:29:16,770 --> 00:29:19,027
Kom ons sit al die produkte in een tabel.

693
00:29:19,027 --> 00:29:22,110
As ek al die produkte in een tabel,
Ek kan net kies al die produkte

694
00:29:22,110 --> 00:29:23,850
uit daardie tafel en ek kry dit alles.

695
00:29:23,850 --> 00:29:25,240
Goed hoe doen ek dit?

696
00:29:25,240 --> 00:29:28,124
Wel, in NoSQL daar is geen
struktuur na die tafel.

697
00:29:28,124 --> 00:29:30,540
Ons sal 'n bietjie praat oor
hoe dit werk in Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Maar jy hoef nie dieselfde te hê
eienskappe en dieselfde eienskappe

699
00:29:33,570 --> 00:29:37,751
in elke enkele ry, in elke enkele
item, soos jy doen in 'n SQL tafel.

700
00:29:37,751 --> 00:29:39,750
En wat dit moontlik maak om my
te doen, is 'n baie dinge

701
00:29:39,750 --> 00:29:41,124
en gee my 'n baie buigsaamheid.

702
00:29:41,124 --> 00:29:45,360
In hierdie spesifieke geval, ek
het my produk dokumente.

703
00:29:45,360 --> 00:29:49,090
En in hierdie spesifieke
Byvoorbeeld, alles

704
00:29:49,090 --> 00:29:51,930
is 'n dokument wat in die tabel produkte.

705
00:29:51,930 --> 00:29:56,510
En die produk vir 'n boek mag
'n soort ID wat 'n boek spesifiseer.

706
00:29:56,510 --> 00:29:59,180
En die toepassing
sou oorskakel op daardie ID.

707
00:29:59,180 --> 00:30:02,570
>> Aan die aansoek toegeroep, ek gaan
om te sê o, wat rekord tipe is dit?

708
00:30:02,570 --> 00:30:04,100
O, dit is 'n boek rekord.

709
00:30:04,100 --> 00:30:05,990
Book rekords het hierdie eienskappe.

710
00:30:05,990 --> 00:30:08,100
Laat my 'n boek voorwerp te skep.

711
00:30:08,100 --> 00:30:11,289
So ek gaan die vul
boek voorwerp met hierdie item.

712
00:30:11,289 --> 00:30:13,080
Volgende item kom en
sê, wat is hierdie item?

713
00:30:13,080 --> 00:30:14,560
Wel hierdie item is 'n album.

714
00:30:14,560 --> 00:30:17,340
O, ek het 'n hele ander
verwerking roetine vir wat,

715
00:30:17,340 --> 00:30:18,487
want dit is 'n album.

716
00:30:18,487 --> 00:30:19,320
Jy sien wat ek bedoel?

717
00:30:19,320 --> 00:30:21,950
>> So het die aansoek tier-- ek
kies al hierdie rekords.

718
00:30:21,950 --> 00:30:23,200
Hulle het almal begin kom in.

719
00:30:23,200 --> 00:30:24,680
Hulle kan wees al die verskillende tipes.

720
00:30:24,680 --> 00:30:27,590
En dit is logika die aansoek se
wat wissel oor die tipes

721
00:30:27,590 --> 00:30:29,530
en besluit hoe om dit te verwerk.

722
00:30:29,530 --> 00:30:33,640
>> Weereens, so ons die optimalisering van die
skema vir die toegang patroon.

723
00:30:33,640 --> 00:30:36,390
Ons doen dit deur
ineenstort die tafels.

724
00:30:36,390 --> 00:30:39,670
Ons is basies neem
hierdie genormaliseer strukture,

725
00:30:39,670 --> 00:30:42,000
en ons bou
hiërargiese strukture.

726
00:30:42,000 --> 00:30:45,130
Binne elkeen van hierdie rekords
Ek gaan verskeidenheid eiendomme te sien.

727
00:30:45,130 --> 00:30:49,400
>> Binne hierdie dokument vir Albums,
Ek sien skikkings van spore.

728
00:30:49,400 --> 00:30:53,900
Diegene spore nou become-- dit
basies hierdie kind tabel

729
00:30:53,900 --> 00:30:56,520
bestaan ​​hier in hierdie struktuur.

730
00:30:56,520 --> 00:30:57,975
So jy kan dit doen in DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Jy kan dit doen in MongoDB.

732
00:30:59,810 --> 00:31:01,437
Jy kan dit doen in enige NoSQL databasis.

733
00:31:01,437 --> 00:31:03,520
Skep hierdie tipe
hiërargiese datastrukture

734
00:31:03,520 --> 00:31:07,120
dat jy data toelaat haal
baie vinnig, want nou is ek

735
00:31:07,120 --> 00:31:08,537
hoef nie te voldoen.

736
00:31:08,537 --> 00:31:11,620
Toe ek voeg 'n ry in die Tracks
tafel, of 'n ry in die tabel in Albums,

737
00:31:11,620 --> 00:31:13,110
Ek het om te voldoen aan die skema.

738
00:31:13,110 --> 00:31:18,060
Ek moet die kenmerk of die het
eiendom wat gedefinieer word op die tafel.

739
00:31:18,060 --> 00:31:20,480
Elke een van hulle,
toe ek voeg die ry.

740
00:31:20,480 --> 00:31:21,910
Dit is nie die geval in NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Ek kan heeltemal anders het
eiendomme in elke dokument

742
00:31:24,440 --> 00:31:26,100
dat ek voeg in die versameling.

743
00:31:26,100 --> 00:31:30,480
So baie kragtige meganisme.

744
00:31:30,480 --> 00:31:32,852
En dit is regtig hoe jy
optimaliseer die stelsel.

745
00:31:32,852 --> 00:31:35,310
Want nou die soektog, in plaas
van die aansluiting by al hierdie tafels

746
00:31:35,310 --> 00:31:39,160
en uitvoering van 'n half dosyn navrae
om terug te trek die data wat ek nodig het,

747
00:31:39,160 --> 00:31:40,890
Ek is die uitvoering van 'n navraag.

748
00:31:40,890 --> 00:31:43,010
En ek iterating
oor die stel resultate.

749
00:31:43,010 --> 00:31:46,512
dit gee jou 'n idee
van die krag van NoSQL.

750
00:31:46,512 --> 00:31:49,470
Ek gaan soort van sywaarts hier gaan
en praat 'n bietjie oor hierdie.

751
00:31:49,470 --> 00:31:53,240
Dit is meer van die soort
bemarking of technology--

752
00:31:53,240 --> 00:31:55,660
die bemarking van tegnologie
tipe bespreking.

753
00:31:55,660 --> 00:31:58,672
Maar dit is belangrik om te verstaan
want as ons kyk na die top

754
00:31:58,672 --> 00:32:00,380
hier op hierdie grafiek,
wat ons is op soek na

755
00:32:00,380 --> 00:32:04,030
is wat ons noem die
tegnologie hype kurwe.

756
00:32:04,030 --> 00:32:06,121
En wat dit beteken is
nuwe dinge kom in die spel.

757
00:32:06,121 --> 00:32:07,120
Mense dink dit is wonderlik.

758
00:32:07,120 --> 00:32:09,200
Ek het al my probleme opgelos.

759
00:32:09,200 --> 00:32:11,630
>> Dit kan die einde
alles, wees almal om alles.

760
00:32:11,630 --> 00:32:12,790
En hulle begin om dit te gebruik.

761
00:32:12,790 --> 00:32:14,720
En hulle sê: hierdie dinge nie werk nie.

762
00:32:14,720 --> 00:32:17,600
Dit is nie reg nie.

763
00:32:17,600 --> 00:32:19,105
Die ou dinge was beter.

764
00:32:19,105 --> 00:32:21,230
En hulle gaan terug om te doen
dinge wat die manier waarop hulle was.

765
00:32:21,230 --> 00:32:22,730
En dan uiteindelik
hulle gaan, jy weet wat?

766
00:32:22,730 --> 00:32:24,040
Hierdie dinge is nie so sleg nie.

767
00:32:24,040 --> 00:32:26,192
O, dit is hoe dit werk.

768
00:32:26,192 --> 00:32:28,900
En sodra hulle uitvind hoe dit
werke, het hulle begin beter.

769
00:32:28,900 --> 00:32:32,050
>> En die snaakse ding oor dit
is, is dit soort van lyne tot watter

770
00:32:32,050 --> 00:32:34,300
noem ons die Tegnologie Aanneming Curve.

771
00:32:34,300 --> 00:32:36,910
So wat gebeur is ons het
'n soort tegnologie sneller.

772
00:32:36,910 --> 00:32:39,100
In die geval van 'n databasis,
dit is data druk.

773
00:32:39,100 --> 00:32:42,200
Ons het gepraat oor die hoë waterpunte
van data druk regdeur tyd.

774
00:32:42,200 --> 00:32:46,310
Wanneer die data druk treffers van 'n sekere
punt, dit is 'n tegnologie sneller.

775
00:32:46,310 --> 00:32:47,830
>> Dit raak te duur.

776
00:32:47,830 --> 00:32:49,790
Dit neem te lank om die data te verwerk.

777
00:32:49,790 --> 00:32:50,890
Ons moet iets beter.

778
00:32:50,890 --> 00:32:52,890
Jy kry die innoveerders
daar rondhardloop,

779
00:32:52,890 --> 00:32:55,050
probeer om uit te vind wat is die oplossing.

780
00:32:55,050 --> 00:32:56,050
Wat is die nuwe idee?

781
00:32:56,050 --> 00:32:58,170
>> Wat is die volgende beste
manier om hierdie saak te doen?

782
00:32:58,170 --> 00:32:59,530
En hulle kom met iets.

783
00:32:59,530 --> 00:33:03,140
En die mense met die werklike pyn,
die ouens by die bloeding rand,

784
00:33:03,140 --> 00:33:06,390
hulle sal almal spring oor dit,
omdat hulle nodig het 'n antwoord.

785
00:33:06,390 --> 00:33:09,690
Nou wat onvermydelik happens-- en
dit gebeur nou in NoSQL.

786
00:33:09,690 --> 00:33:11,090
Ek sien dit al die tyd.

787
00:33:11,090 --> 00:33:13,610
>> Wat gebeur is onvermydelik
mense begin met behulp van die nuwe instrument

788
00:33:13,610 --> 00:33:15,490
op dieselfde manier het hulle die ou instrument.

789
00:33:15,490 --> 00:33:17,854
En hulle uitvind dit
nie so goed werk.

790
00:33:17,854 --> 00:33:20,020
Ek kan nie onthou wie ek is
praat vroeër vandag.

791
00:33:20,020 --> 00:33:22,080
Maar dit is soos wanneer die
jackhammer is uitgevind,

792
00:33:22,080 --> 00:33:24,621
mense het nie swaai dit oor
hulle hoof na die konkrete smash.

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

794
00:33:27,360 --> 00:33:30,610
>> Maar dit is wat is
gebeur met NoSQL vandag.

795
00:33:30,610 --> 00:33:33,900
As jy loop in die meeste winkels,
hulle probeer om te wees NoSQL winkels.

796
00:33:33,900 --> 00:33:36,510
Wat hulle doen, is
hulle gebruik NoSQL,

797
00:33:36,510 --> 00:33:39,900
en hulle is die laai dit
vol relasionele skema.

798
00:33:39,900 --> 00:33:41,630
Want dit is hoe
hulle ontwerp databasisse.

799
00:33:41,630 --> 00:33:44,046
En hulle wonder, hoekom is
dit nie presteer baie goed?

800
00:33:44,046 --> 00:33:45,230
Boy, hierdie ding stink.

801
00:33:45,230 --> 00:33:49,900
Ek moes al my handhaaf
sluit in-- dit is soos, nee, nee.

802
00:33:49,900 --> 00:33:50,800
Handhaaf sluit?

803
00:33:50,800 --> 00:33:52,430
Hoekom is jy by data?

804
00:33:52,430 --> 00:33:54,350
Jy hoef nie aan te sluit in data NoSQL.

805
00:33:54,350 --> 00:33:55,850
Jy saamvoeg nie.

806
00:33:55,850 --> 00:34:00,690
>> So as jy wil om dit te vermy, leer
hoe die program werk voordat jy eintlik

807
00:34:00,690 --> 00:34:02,010
begin dit te gebruik.

808
00:34:02,010 --> 00:34:04,860
Moenie probeer en gebruik die nuwe gereedskap die
op dieselfde manier wat jy gebruik die ou gereedskap.

809
00:34:04,860 --> 00:34:06,500
Jy gaan 'n slegte ervaring.

810
00:34:06,500 --> 00:34:08,848
En elke keer
dit is wat dit is oor.

811
00:34:08,848 --> 00:34:11,389
Wanneer ons begin kom hier,
dit is omdat mense uitgepluis

812
00:34:11,389 --> 00:34:13,449
hoe om die gereedskap te gebruik.

813
00:34:13,449 --> 00:34:16,250
>> Hulle het dieselfde ding wanneer
relasionele databasisse uitgevind,

814
00:34:16,250 --> 00:34:17,969
en hulle is vervang lêer stelsels.

815
00:34:17,969 --> 00:34:20,420
Hulle het probeer om lêerstelsels bou
met relasionele databasisse

816
00:34:20,420 --> 00:34:22,159
want dit is wat mense verstaan.

817
00:34:22,159 --> 00:34:23,049
Dit het nie gewerk nie.

818
00:34:23,049 --> 00:34:26,090
So verstaan ​​die beste praktyke
van die tegnologie jy werk met

819
00:34:26,090 --> 00:34:26,730
is groot.

820
00:34:26,730 --> 00:34:29,870
Baie belangrik.

821
00:34:29,870 --> 00:34:32,440
>> So ons gaan om te kry in DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB is AWS se
ten volle beheer NoSQL platform.

823
00:34:36,480 --> 00:34:37,719
Wat beteken ten volle beheer beteken?

824
00:34:37,719 --> 00:34:40,010
Dit beteken dat jy nie nodig het om te
regtig bekommerd oor enige iets.

825
00:34:40,010 --> 00:34:42,060
>> Jy kom in, vertel
ons, ek moet 'n tafel.

826
00:34:42,060 --> 00:34:43,409
Dit moet soveel kapasiteit.

827
00:34:43,409 --> 00:34:47,300
Jy druk die knoppie, en ons voorsiening
al die infrastruktuur agter die toneel dood.

828
00:34:47,300 --> 00:34:48,310
Nou dat is enorm.

829
00:34:48,310 --> 00:34:51,310
>> Want wanneer jy praat
oor skalering 'n databasis,

830
00:34:51,310 --> 00:34:53,917
NoSQL data trosse aan
skaal, hardloop petabytes,

831
00:34:53,917 --> 00:34:55,750
hardloop miljoene
transaksies per sekonde,

832
00:34:55,750 --> 00:34:58,180
hierdie dinge is nie klein trosse.

833
00:34:58,180 --> 00:35:00,830
Ons praat van duisende gevalle.

834
00:35:00,830 --> 00:35:04,480
Besturende duisende gevalle
selfs virtuele gevalle

835
00:35:04,480 --> 00:35:06,350
is 'n ware pyn in die boude.

836
00:35:06,350 --> 00:35:09,110
Ek bedoel, dink oor elke keer 'n
bedryfstelsel kol kom uit

837
00:35:09,110 --> 00:35:11,552
of 'n nuwe weergawe van die databasis.

838
00:35:11,552 --> 00:35:13,260
Wat beteken dit
om jou operasioneel?

839
00:35:13,260 --> 00:35:16,330
Dit beteken dat jy het 1200
bedieners wat moet verander.

840
00:35:16,330 --> 00:35:18,960
Nou selfs met outomatisasie,
wat kan 'n lang tyd neem.

841
00:35:18,960 --> 00:35:21,480
Dit kan 'n baie laat
operasionele hoofpyn,

842
00:35:21,480 --> 00:35:23,090
want ek kan dienste af.

843
00:35:23,090 --> 00:35:26,070
>> As ek werk hierdie databasisse, ek
dalk blou groen ontplooi doen

844
00:35:26,070 --> 00:35:29,420
waar ek sit en op te gradeer helfte van my
nodes, en dan die opgradering van die ander helfte.

845
00:35:29,420 --> 00:35:30,490
Neem dié van.

846
00:35:30,490 --> 00:35:33,410
So die bestuur van die infrastruktuur
skaal is geweldig pynlik.

847
00:35:33,410 --> 00:35:36,210
En AWS neem dat die pyn uit.

848
00:35:36,210 --> 00:35:39,210
En NoSQL databasisse kan
wees buitengewoon pynlike

849
00:35:39,210 --> 00:35:41,780
as gevolg van die manier waarop hulle die skaal.

850
00:35:41,780 --> 00:35:42,926
>> Skaal horisontaal.

851
00:35:42,926 --> 00:35:45,550
As jy wil 'n groter NoSQL kry
databasis, jy koop meer nodes.

852
00:35:45,550 --> 00:35:48,660
Elke node jy koop is
'n ander operasionele hoofpyn.

853
00:35:48,660 --> 00:35:50,830
So laat iemand anders dit doen vir jou.

854
00:35:50,830 --> 00:35:52,000
AWS kan dit doen.

855
00:35:52,000 --> 00:35:54,587
>> Ons ondersteun dokument kernwaardes.

856
00:35:54,587 --> 00:35:56,670
Nou het ons nie te veel gaan
in die ander grafiek.

857
00:35:56,670 --> 00:35:58,750
Daar is 'n baie verskillende
geure van NoSQL.

858
00:35:58,750 --> 00:36:02,670
Hulle is al die soort van kry
saam munged op hierdie punt.

859
00:36:02,670 --> 00:36:06,260
Jy kan kyk na DynamoDB en sê ja,
Ons is albei 'n dokument en 'n sleutel waarde

860
00:36:06,260 --> 00:36:08,412
stoor hierdie punt.

861
00:36:08,412 --> 00:36:10,620
En jy kan die eienskappe argumenteer
een oor die ander.

862
00:36:10,620 --> 00:36:13,950
Vir my is 'n baie van hierdie is regtig ses
een helfte van 'n dosyn van die ander.

863
00:36:13,950 --> 00:36:18,710
Elkeen van hierdie tegnologie is 'n
fyn tegnologie en 'n boete oplossing.

864
00:36:18,710 --> 00:36:23,390
Ek sou nie sê MongoDB is beter of
erger as Couch, dan Cassandra,

865
00:36:23,390 --> 00:36:25,994
dan Dynamo, of andersom.

866
00:36:25,994 --> 00:36:27,285
Ek bedoel, dit is net 'opsies.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Dit is vinnig en dit is
konsekwent op enige skaal.

869
00:36:32,700 --> 00:36:36,210
So dit is een van die grootste
bonusse wat jy kry met AWS.

870
00:36:36,210 --> 00:36:40,850
Met DynamoDB is die vermoë
om 'n lae enkelsyfers te kry

871
00:36:40,850 --> 00:36:44,040
millisekonde latency op enige skaal.

872
00:36:44,040 --> 00:36:45,720
Dit was 'n ontwerp doel van die stelsel.

873
00:36:45,720 --> 00:36:49,130
En ons het kliënte wat doen
miljoene transaksies per sekonde.

874
00:36:49,130 --> 00:36:52,670
>> Nou sal ek gaan deur 'n paar van daardie
gebruik gevalle in 'n paar minute hier.

875
00:36:52,670 --> 00:36:55,660
Geïntegreerde toegang control--
ons het wat ons noem

876
00:36:55,660 --> 00:36:57,920
Identiteit Access Management, of IAM.

877
00:36:57,920 --> 00:37:01,980
Dit deurdring elke stelsel,
elke diens wat AWS bied.

878
00:37:01,980 --> 00:37:03,630
DynamoDB is geen uitsondering nie.

879
00:37:03,630 --> 00:37:06,020
Jy kan toegang beheer
die DynamoDB tafels.

880
00:37:06,020 --> 00:37:09,960
In al jou AWS rekeninge deur
definieer toegang rolle en regte

881
00:37:09,960 --> 00:37:12,140
in die IAM infrastruktuur.

882
00:37:12,140 --> 00:37:16,630
>> En dit is 'n belangrike en integrale komponent in
wat ons Event noem gedrewe programmering.

883
00:37:16,630 --> 00:37:19,056
Nou is dit 'n nuwe paradigma.

884
00:37:19,056 --> 00:37:22,080
>> GEHOOR: Hoe is jou tempo van die ware
positiewe versus vals negatiewe

885
00:37:22,080 --> 00:37:24,052
op jou toegangsbeheer stelsel?

886
00:37:24,052 --> 00:37:26,260
Rick Houlihan: True positiewe
versus vals negatiewe?

887
00:37:26,260 --> 00:37:28,785
GEHOOR: Returning wat
jy moet terugkeer word?

888
00:37:28,785 --> 00:37:33,720
In teenstelling met een keer in 'terwyl dit
nie terug wanneer dit moet bekragtig?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> Rick Houlihan: Ek kon nie vertel nie.

891
00:37:38,050 --> 00:37:40,140
As daar enige mislukkings
hoegenaamd op dat

892
00:37:40,140 --> 00:37:42,726
Ek is nie die persoon om te vra
daardie spesifieke vraag.

893
00:37:42,726 --> 00:37:43,850
Maar dit is 'n goeie vraag.

894
00:37:43,850 --> 00:37:45,905
Ek sou nuuskierig wees om te weet
wat myself, eintlik.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> En so dan weer, nuwe paradigma
is gebeurtenis gedrewe programmering.

897
00:37:51,320 --> 00:37:55,160
Dit is die idee dat jy kan
ontplooi komplekse programme wat

898
00:37:55,160 --> 00:37:59,720
kan 'n baie, baie hoë skaal bedryf
sonder enige infrastruktuur hoegenaamd nie.

899
00:37:59,720 --> 00:38:02,120
Sonder enige vaste
infrastruktuur hoegenaamd nie.

900
00:38:02,120 --> 00:38:04,720
En ons sal 'n bietjie praat
oor wat dit beteken as ons

901
00:38:04,720 --> 00:38:06,550
kry op die volgende paar kaarte.

902
00:38:06,550 --> 00:38:08,716
>> Die eerste ding wat ons sal doen
is ons praat oor tafels.

903
00:38:08,716 --> 00:38:10,857
Tipes API data vir Dynamo.

904
00:38:10,857 --> 00:38:13,190
En die eerste ding wat jy sal
oplet wanneer jy kyk na hierdie,

905
00:38:13,190 --> 00:38:17,930
As jy vertroud is met enige databasis,
databasisse regtig twee soort van API's

906
00:38:17,930 --> 00:38:18,430
Ek sal dit noem.

907
00:38:18,430 --> 00:38:21,570
Of twee stelle API.

908
00:38:21,570 --> 00:38:23,840
Een van dié sou wees
administratiewe API.

909
00:38:23,840 --> 00:38:26,710
>> Die dinge wat hulle sorg
die funksies van die databasis.

910
00:38:26,710 --> 00:38:31,340
Die stoor enjin instel,
opstel en die toevoeging van tafels.

911
00:38:31,340 --> 00:38:35,180
skep van databasis
katalogusse en gevalle.

912
00:38:35,180 --> 00:38:40,450
Hierdie things-- in DynamoDB jy
het 'n baie kort, kort lyste.

913
00:38:40,450 --> 00:38:43,120
>> So in ander databasisse,
jy dalk dekades sien

914
00:38:43,120 --> 00:38:45,680
instruksies, van administratiewe
opdragte, vir die instel

915
00:38:45,680 --> 00:38:47,290
hierdie bykomende opsies.

916
00:38:47,290 --> 00:38:51,234
In DynamoDB jy hoef nie die gevolg
jy nie die stelsel instel, ons doen.

917
00:38:51,234 --> 00:38:54,150
Dus is die enigste ding wat jy hoef te doen is
vertel my wat grootte tafel het ek nodig.

918
00:38:54,150 --> 00:38:55,660
Sodat jy 'n baie te kry
beperkte stel van opdragte.

919
00:38:55,660 --> 00:38:58,618
>> Jy kry 'n Skep Table Update, Table,
Verwyder Table, en beskryf Table.

920
00:38:58,618 --> 00:39:01,150
Dit is die enigste dinge
jy nodig het vir DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Jy hoef nie 'n stoor nodig
enjin opset.

922
00:39:03,294 --> 00:39:04,960
Ek het nie nodig om te bekommer oor replikasie.

923
00:39:04,960 --> 00:39:06,490
Ek het nie nodig om te bekommer oor sharding.

924
00:39:06,490 --> 00:39:07,800
>> Ek het nie nodig om te bekommer
oor enige van hierdie dinge.

925
00:39:07,800 --> 00:39:08,740
Ons doen dit alles vir jou.

926
00:39:08,740 --> 00:39:11,867
So dit is 'n groot hoeveelheid van die oorhoofse
wat net gelig jou bord.

927
00:39:11,867 --> 00:39:13,200
Dan het ons die CRUD operateurs.

928
00:39:13,200 --> 00:39:17,740
CRUD is iets wat ons
noem in die databasis wat

929
00:39:17,740 --> 00:39:19,860
Skep, Update, verwyder operateurs.

930
00:39:19,860 --> 00:39:24,180
Dit is jou algemene
databasis bedrywighede.

931
00:39:24,180 --> 00:39:31,299
Dinge soos put item, kry item, update
items, items te verwyder, joernaal navraag, scan.

932
00:39:31,299 --> 00:39:32,840
As jy wil hê dat die hele tabel scan.

933
00:39:32,840 --> 00:39:34,220
Trek alles van die tafel af.

934
00:39:34,220 --> 00:39:37,130
Een van die mooi dinge oor DynamoDB
is dit laat parallel skandering.

935
00:39:37,130 --> 00:39:40,602
Sodat jy kan eintlik laat my weet hoeveel
drade wat jy wil om te hardloop op daardie scan.

936
00:39:40,602 --> 00:39:41,810
En ons kan hardloop diegene drade.

937
00:39:41,810 --> 00:39:43,985
Ons kan spin dat scan up
oor verskeie drade

938
00:39:43,985 --> 00:39:49,060
sodat jy kan die hele tabel scan
ruimte baie, baie vinnig in DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Die ander API ons het, is
wat ons noem ons Streams API.

940
00:39:51,490 --> 00:39:52,940
Ons gaan nie te praat om
veel oor hierdie nou.

941
00:39:52,940 --> 00:39:55,189
Ek het 'n paar inhoud later het
in die dek oor hierdie.

942
00:39:55,189 --> 00:39:59,910
Maar Streams is regtig 'n running--
dink aan dit as die tyd bestel

943
00:39:59,910 --> 00:40:01,274
en verdeling verandering log.

944
00:40:01,274 --> 00:40:03,940
Alles wat gebeur op
die tabel toon op die stroom.

945
00:40:03,940 --> 00:40:05,940
>> Elke skryf aan die tafel
dui op die stroom.

946
00:40:05,940 --> 00:40:08,370
Jy kan daardie stroom lees en
jy kan doen met dit.

947
00:40:08,370 --> 00:40:10,150
Ons sal praat oor wat
tipes dinge wat jy

948
00:40:10,150 --> 00:40:13,680
doen met die dinge soos replikasie,
skep sekondêre indekse.

949
00:40:13,680 --> 00:40:17,620
Alle vorme van regtig cool
dinge wat jy kan doen met dit.

950
00:40:17,620 --> 00:40:19,150
>> Datatipes.

951
00:40:19,150 --> 00:40:23,320
In DynamoDB, sowel sleutel ondersteun ons
waarde en die dokument data tipes.

952
00:40:23,320 --> 00:40:26,350
Op die linkerkant van die skerm
hier, ons het ons basiese tipes.

953
00:40:26,350 --> 00:40:27,230
Sleutel tipes waarde.

954
00:40:27,230 --> 00:40:30,040
Dit is snare,
getalle en installasie.

955
00:40:30,040 --> 00:40:31,640
>> Dus net drie basiese tipes.

956
00:40:31,640 --> 00:40:33,700
En dan kan jy stelle van daardie het.

957
00:40:33,700 --> 00:40:37,650
Een van die mooi dinge oor NoSQL is
jy kan skikkings as eienskappe bevat.

958
00:40:37,650 --> 00:40:42,050
En met DynamoDB kan jy skikkings bevat
basiese tipes soos 'n wortel eiendom.

959
00:40:42,050 --> 00:40:43,885
>> En dan is daar die dokument tik.

960
00:40:43,885 --> 00:40:45,510
Hoeveel mense is vertroud met into?

961
00:40:45,510 --> 00:40:47,130
Julle vertroud met into so baie?

962
00:40:47,130 --> 00:40:49,380
Dit is basies JavaScript,
Voorwerp, notasie.

963
00:40:49,380 --> 00:40:52,510
Dit kan jy basies
definieer 'n hiërargiese struktuur.

964
00:40:52,510 --> 00:40:58,107
>> Jy kan 'n dokument oor te slaan into
DynamoDB die gebruik van gemeenskaplike komponente

965
00:40:58,107 --> 00:41:00,940
of boustene wat beskikbaar is
in die meeste programmeertale.

966
00:41:00,940 --> 00:41:03,602
So as jy Java, is jy
op soek na kaarte en lyste.

967
00:41:03,602 --> 00:41:05,060
Ek kan voorwerpe te skep daardie gebied kaart.

968
00:41:05,060 --> 00:41:08,030
A kaart as kernwaardes
gestoor as eienskappe.

969
00:41:08,030 --> 00:41:10,890
En dit kan lyste van het
waardes binne daardie eienskappe.

970
00:41:10,890 --> 00:41:13,490
Jy kan hierdie komplekse stoor
hiërargiese struktuur

971
00:41:13,490 --> 00:41:16,320
as 'n enkele kenmerk
van 'n DynamoDB item.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> So tafels in DynamoDB, soos die meeste
NoSQL databasisse, tabelle items.

974
00:41:24,460 --> 00:41:26,469
In MongoDB jy sou
noem hierdie dokumente.

975
00:41:26,469 --> 00:41:27,760
En dit sou die rusbank basis.

976
00:41:27,760 --> 00:41:28,900
Ook 'n dokument databasis.

977
00:41:28,900 --> 00:41:29,941
Jy noem hierdie dokumente.

978
00:41:29,941 --> 00:41:32,930
Dokumente of items eienskappe.

979
00:41:32,930 --> 00:41:35,850
Eienskappe kan bestaan ​​of
bestaan ​​nie op die item.

980
00:41:35,850 --> 00:41:38,520
In DynamoDB, daar is
een verpligte kenmerk.

981
00:41:38,520 --> 00:41:43,880
Net soos in 'n relasionele databasis,
jy het 'n primêre sleutel op die tafel.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB het wat ons 'n hash sleutel noem.

983
00:41:46,010 --> 00:41:48,280
Hash sleutel moet uniek wees.

984
00:41:48,280 --> 00:41:52,580
So toe ek 'n hash tafel definieer,
basies wat ek sê

985
00:41:52,580 --> 00:41:54,110
is elke item sal 'n gemors sleutel.

986
00:41:54,110 --> 00:41:58,520
En elke hash sleutel moet uniek wees.

987
00:41:58,520 --> 00:42:01,200
>> Elke item word gedefinieer
deur daardie unieke hash sleutel.

988
00:42:01,200 --> 00:42:02,940
En daar kan net een wees.

989
00:42:02,940 --> 00:42:05,820
Dit is OK, maar dikwels
wat mense nodig

990
00:42:05,820 --> 00:42:08,170
is wat hulle wil hê, is hierdie hash
sleutel tot 'n bietjie meer te doen

991
00:42:08,170 --> 00:42:11,010
as net 'n unieke identifiseerder wees.

992
00:42:11,010 --> 00:42:15,240
Dikwels wil ons dat hash sleutel
as die boonste vlak samevoeging emmer.

993
00:42:15,240 --> 00:42:19,160
En die manier waarop ons dit doen, is deur
toevoeging van wat ons 'n reeks belangrike skakel.

994
00:42:19,160 --> 00:42:22,460
>> So as dit is net 'n hash
tafel, moet hierdie unieke wees.

995
00:42:22,460 --> 00:42:27,040
As dit is 'n hash en omvang tafel, die
kombinasie van die hash en die reeks

996
00:42:27,040 --> 00:42:28,640
moet uniek wees.

997
00:42:28,640 --> 00:42:30,110
So dink oor dit op hierdie manier.

998
00:42:30,110 --> 00:42:32,140
As ek 'n forum.

999
00:42:32,140 --> 00:42:39,010
En die vorm het onderwerpe, dit het
poste, en dit het die antwoorde.

1000
00:42:39,010 --> 00:42:42,630
>> So ek kan 'n hash het
sleutel, wat is die onderwerp ID.

1001
00:42:42,630 --> 00:42:46,650
En ek kan 'n verskeidenheid sleutel,
wat is die reaksie ID.

1002
00:42:46,650 --> 00:42:49,650
So as ek wil al die kry
antwoorde vir spesifieke onderwerp,

1003
00:42:49,650 --> 00:42:52,370
Ek kan net navraag die hash.

1004
00:42:52,370 --> 00:42:55,190
Ek kan net sê gee my al
die items wat hierdie hash het.

1005
00:42:55,190 --> 00:43:01,910
En ek gaan elke vraag te kry
of pos vir daardie spesifieke onderwerp.

1006
00:43:01,910 --> 00:43:03,910
Hierdie top vlak swerms
is baie belangrik.

1007
00:43:03,910 --> 00:43:07,370
Hulle ondersteun die primêre toegang
patroon van die aansoek.

1008
00:43:07,370 --> 00:43:09,420
Oor die algemeen, hierdie
is wat ons wil doen.

1009
00:43:09,420 --> 00:43:11,780
Ons wil hê dat die table--
as jy die tafel te laai,

1010
00:43:11,780 --> 00:43:16,640
ons wil die data te struktureer
binne die tafel in so 'n manier

1011
00:43:16,640 --> 00:43:20,140
dat die aansoek kan baie
vinnig die resultate op te haal.

1012
00:43:20,140 --> 00:43:24,510
En dikwels die manier om dit te doen, is
hierdie swerms as ons handhaaf

1013
00:43:24,510 --> 00:43:25,650
voeg die data.

1014
00:43:25,650 --> 00:43:31,110
Basies, ons die data versprei
in die helder emmer as dit kom in.

1015
00:43:31,110 --> 00:43:35,210
>> Range sleutels toelaat me-- hash
sleutels het om gelykheid te wees.

1016
00:43:35,210 --> 00:43:39,490
Toe ek navraag n hash, ek het om te sê
gee my 'n hash dat dit gelyk.

1017
00:43:39,490 --> 00:43:41,950
Toe ek navraag van 'n reeks, ek
kan sê gee my 'n verskeidenheid

1018
00:43:41,950 --> 00:43:47,040
wat die gebruik van enige soort
ryk operateur wat ons ondersteun.

1019
00:43:47,040 --> 00:43:49,200
Gee my al die items vir 'n hash.

1020
00:43:49,200 --> 00:43:52,520
Is dit gelyk, groter as,
minder as, beteken dit mee te begin,

1021
00:43:52,520 --> 00:43:54,145
dit bestaan ​​tussen hierdie twee waardes?

1022
00:43:54,145 --> 00:43:56,811
So hierdie tipe reeks navrae
dat ons altyd geïnteresseerd in.

1023
00:43:56,811 --> 00:43:59,650
Nou een ding oor data, wanneer
jy kyk na die toegang tot data, wanneer

1024
00:43:59,650 --> 00:44:02,360
jy toegang tot die data, is dit
altyd oor 'n samevoeging.

1025
00:44:02,360 --> 00:44:05,770
Dit is altyd oor die rekords
wat verband hou met hierdie.

1026
00:44:05,770 --> 00:44:10,390
Gee my alles hier that's-- al
die transaksies op hierdie kredietkaart

1027
00:44:10,390 --> 00:44:12,500
vir die afgelope maand.

1028
00:44:12,500 --> 00:44:13,960
Dit is 'n samevoeging.

1029
00:44:13,960 --> 00:44:17,490
>> Byna alles wat jy doen in die
databasis is 'n soort van samevoeging.

1030
00:44:17,490 --> 00:44:21,530
So in staat is om in staat wees om te definieer
hierdie emmers en gee jou die reeks

1031
00:44:21,530 --> 00:44:24,950
eienskappe om in staat wees om 'n navraag op,
diegene wat ryk navrae ondersteun baie,

1032
00:44:24,950 --> 00:44:27,165
baie, baie toegang aansoek patrone.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> So het die ander ding wat die hash sleutel
doen, is dit gee ons 'n meganisme

1035
00:44:35,000 --> 00:44:37,740
in staat wees om die data te versprei.

1036
00:44:37,740 --> 00:44:40,390
NoSQL databasisse werk die beste
wanneer die data is eweredig

1037
00:44:40,390 --> 00:44:41,740
versprei oor die cluster.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Hoeveel mense is vertroud
met hashing algoritmes?

1040
00:44:47,050 --> 00:44:49,860
Toe ek en 'n hash hashing-- sê
omdat 'n hashing algoritme

1041
00:44:49,860 --> 00:44:54,140
is 'n manier om te kan genereer
'n ewekansige waarde van enige gegewe waarde.

1042
00:44:54,140 --> 00:44:59,300
So in hierdie spesifieke geval, die
hash algoritme loop ons is ND 5 gebaseer.

1043
00:44:59,300 --> 00:45:04,765
>> En as ek 'n ID, en dit
is my hash sleutel, ek het 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Wanneer ek hardloop die hash algoritme,
dit gaan om terug te kom en sê:

1045
00:45:07,390 --> 00:45:10,800
goed 1 gelyk 7B, 2
gelyk 48, 3 gelyk CD.

1046
00:45:10,800 --> 00:45:13,092
Hulle is versprei oor die sleutel ruimte.

1047
00:45:13,092 --> 00:45:14,050
En hoekom doen jy dit?

1048
00:45:14,050 --> 00:45:17,120
Want dit maak seker dat ek kan
sit die rekords oor verskeie nodes.

1049
00:45:17,120 --> 00:45:19,574
>> As ek dit doen
inkrementeel, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
En ek het 'n hash reeks wat
lopies in hierdie spesifieke geval,

1051
00:45:21,990 --> 00:45:24,785
'n klein hash ruimte,
dit loop van 00 tot VF,

1052
00:45:24,785 --> 00:45:27,951
dan is die rekords gaan om in te kom
en hulle gaan om te gaan 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
Wat gebeur?

1055
00:45:31,800 --> 00:45:34,860
Elke insetsel gaan dieselfde knoop.

1056
00:45:34,860 --> 00:45:36,070
Jy sien wat ek bedoel?

1057
00:45:36,070 --> 00:45:40,910
>> Want toe ek verdeel die ruimte,
en ek versprei hierdie rekords oor,

1058
00:45:40,910 --> 00:45:45,950
en ek partisie, ek gaan om te sê
partisie 1 het die sleutel ruimte 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partition 2 is 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partition 3 is AA VF.

1061
00:45:49,780 --> 00:45:53,740
So as ek gebruik lineêr die verhoog
ID's, kan jy sien wat gebeur.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, al manier tot 54.

1063
00:45:57,410 --> 00:46:00,030
So as ek gehamer die
rekords in die stelsel,

1064
00:46:00,030 --> 00:46:02,030
alles eindig gaan een knoop.

1065
00:46:02,030 --> 00:46:03,160
>> Dit is nie goed nie.

1066
00:46:03,160 --> 00:46:04,820
Dit is 'n antipattern.

1067
00:46:04,820 --> 00:46:08,760
In MongoDB hulle hierdie probleem
As jy nie 'n hash sleutel te gebruik.

1068
00:46:08,760 --> 00:46:11,325
MongoDB gee jou die opsie
van hashing die sleutel waarde.

1069
00:46:11,325 --> 00:46:13,950
Jy moet altyd doen, as
jy 'n verhoog van hash

1070
00:46:13,950 --> 00:46:17,380
sleutel MongoDB, of jy sal
spyker elke skryf een knoop,

1071
00:46:17,380 --> 00:46:21,290
en jy sal die beperking
jou skryf deurset sleg.

1072
00:46:21,290 --> 00:46:24,896
>> GEHOOR: Is dit A9 169 in desimale?

1073
00:46:24,896 --> 00:46:28,450
>> Rick Houlihan: Ja, dit is
iewers daar rond.

1074
00:46:28,450 --> 00:46:29,950
A9, ek weet nie.

1075
00:46:29,950 --> 00:46:32,200
Jy wil hê om my binêre kry
om desimale sakrekenaar.

1076
00:46:32,200 --> 00:46:34,237
My brein werk nie so nie.

1077
00:46:34,237 --> 00:46:36,320
GEHOOR: Net 'n vinnige een
jou Mongo kommentaar.

1078
00:46:36,320 --> 00:46:39,530
So is die voorwerp ID wat kom
native met Mongo dit doen?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
Rick Houlihan: Is dit dit?

1081
00:46:41,470 --> 00:46:42,970
As jy dit spesifiseer.

1082
00:46:42,970 --> 00:46:45,030
Met MongoDB, jy het die opsie.

1083
00:46:45,030 --> 00:46:48,930
Jy kan elke dokument in specify--
MongoDB het om 'n underscore ID het.

1084
00:46:48,930 --> 00:46:50,300
Dit is die unieke waarde.

1085
00:46:50,300 --> 00:46:55,240
>> In MongoDB jy kan spesifiseer
of om dit hash of nie.

1086
00:46:55,240 --> 00:46:56,490
Hulle gee jou net die opsie.

1087
00:46:56,490 --> 00:46:58,198
As jy weet dat dit
random, geen probleem.

1088
00:46:58,198 --> 00:46:59,640
Jy hoef nie om dit te doen.

1089
00:46:59,640 --> 00:47:04,260
As jy weet dat dit is nie random, wat
dit is die verhoog, doen dan die hash.

1090
00:47:04,260 --> 00:47:06,880
>> Nou is die ding oor
hashing, sodra jy hash

1091
00:47:06,880 --> 00:47:08,800
'n value-- en dit is
Hoekom hash sleutels is altyd

1092
00:47:08,800 --> 00:47:13,740
unieke navrae, want ek het verander
die waarde, nou kan ek nie 'n reeks navraag te doen.

1093
00:47:13,740 --> 00:47:15,640
Ek kan nie sê dit is
tussen hierdie of daardie,

1094
00:47:15,640 --> 00:47:20,800
omdat die hash waarde is nie van plan
gelykstaande aan die werklike waarde.

1095
00:47:20,800 --> 00:47:24,570
So wanneer jy hash wat
sleutel, dit is net gelykheid.

1096
00:47:24,570 --> 00:47:28,700
Dit is die rede waarom in DynamoDB hash sleutel
navrae is altyd net gelykheid.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> So nou in 'n reeks key--
toe ek byvoeg dat reeks sleutel,

1099
00:47:34,700 --> 00:47:38,180
diegene reeks sleutel rekords almal kom in en
hulle kry gestoor word op dieselfde partisie.

1100
00:47:38,180 --> 00:47:42,430
So hulle is baie vinnig, maklik
opgespoor, want dit is die hash,

1101
00:47:42,430 --> 00:47:43,220
dit is die reeks.

1102
00:47:43,220 --> 00:47:44,928
En jy sien alles
met dieselfde hash

1103
00:47:44,928 --> 00:47:48,550
kry gestoor op dieselfde partisie ruimte.

1104
00:47:48,550 --> 00:47:53,889
Jy kan daardie reeks sleutel gebruik om te help
soek jou data naby aan sy ouer.

1105
00:47:53,889 --> 00:47:55,180
So, wat ek eintlik hier?

1106
00:47:55,180 --> 00:47:57,320
Dit is 'n baie-verhouding.

1107
00:47:57,320 --> 00:48:01,490
Die verhouding tussen 'n hash sleutel
en die reeks sleutel is een van baie.

1108
00:48:01,490 --> 00:48:03,490
Ek kan verskeie hash sleutels het.

1109
00:48:03,490 --> 00:48:07,610
Ek kan net het verskeie reeks
sleutels in elke hash sleutel.

1110
00:48:07,610 --> 00:48:11,910
>> Die hash definieer die ouer,
die reeks definieer die kinders.

1111
00:48:11,910 --> 00:48:15,240
Sodat jy kan sien daar is analoog hier
tussen die relasionele konstruk

1112
00:48:15,240 --> 00:48:18,840
en dieselfde tipes
bou in NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Mense praat oor
NoSQL as nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Dit is nie nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Data het altyd verhoudings.

1116
00:48:24,680 --> 00:48:28,172
Daardie verhoudings net
is anders geskoei.

1117
00:48:28,172 --> 00:48:29,880
Kom ons praat 'n bietjie
bietjie oor duursaamheid.

1118
00:48:29,880 --> 00:48:34,860
Wanneer jy skryf DynamoDB, skryf
is altyd drie-manier herhaal.

1119
00:48:34,860 --> 00:48:37,550
Dit beteken dat ons drie AZ se.

1120
00:48:37,550 --> 00:48:39,160
AZ se Beskikbaarheid sones.

1121
00:48:39,160 --> 00:48:43,430
Jy kan dink van 'n Beskikbaarheid
Sone as 'n data-sentrum

1122
00:48:43,430 --> 00:48:45,447
of 'n versameling van data sentrums.

1123
00:48:45,447 --> 00:48:47,780
Hierdie dinge is geografies
geïsoleerd van mekaar

1124
00:48:47,780 --> 00:48:51,610
oor verskillende skuld sones, oor
verskillende krag roosters en vloedvlaktes.

1125
00:48:51,610 --> 00:48:54,510
'N versuim in een AZ is nie
gaan om af te haal 'n ander.

1126
00:48:54,510 --> 00:48:56,890
Hulle is ook gekoppel
saam met 'n donker vesel.

1127
00:48:56,890 --> 00:49:01,240
Dit ondersteun die een sub 1
millisekonde latency tussen AZS.

1128
00:49:01,240 --> 00:49:05,390
So real time data herhalings
staat in 'n multi AZS.

1129
00:49:05,390 --> 00:49:09,990
>> En dikwels multi AZ ontplooi
voldoen aan die hoë beskikbaarheid vereistes

1130
00:49:09,990 --> 00:49:12,930
van die meeste onderneming organisasies.

1131
00:49:12,930 --> 00:49:16,139
So DynamoDB versprei
oor drie AZS by verstek.

1132
00:49:16,139 --> 00:49:19,430
Ons gaan net om kennis van die skryf
wanneer twee van die drie nodes terug te kom

1133
00:49:19,430 --> 00:49:21,470
en sê: Ja, ek het dit.

1134
00:49:21,470 --> 00:49:22,050
Hoekom is dit?

1135
00:49:22,050 --> 00:49:25,950
Want op die lees kant ons is net
gaan jy die data terug te gee wanneer

1136
00:49:25,950 --> 00:49:27,570
ons kry dit uit twee nodes.

1137
00:49:27,570 --> 00:49:30,490
>> As ek replicerende oor
drie, en ek lees van twee,

1138
00:49:30,490 --> 00:49:32,840
Ek is altyd gewaarborg
om ten minste een het

1139
00:49:32,840 --> 00:49:35,720
van daardie lui die wees
mees onlangse afskrif van data.

1140
00:49:35,720 --> 00:49:38,340
Dit is wat maak DynamoDB konsekwent.

1141
00:49:38,340 --> 00:49:42,450
Nou kan jy kies om te draai
diegene konsekwent lees af.

1142
00:49:42,450 --> 00:49:45,070
In welke geval ek gaan om te sê,
Ek sal net lees van een knoop.

1143
00:49:45,070 --> 00:49:47,430
En ek kan nie waarborg dit gaan
te wees van die mees onlangse data.

1144
00:49:47,430 --> 00:49:49,450
>> So as 'n skryf kom in,
dit is nog nie herhaal,

1145
00:49:49,450 --> 00:49:50,360
jy gaan om dit te kry kopie.

1146
00:49:50,360 --> 00:49:52,220
Dit is 'n uiteindelik konsekwent lees.

1147
00:49:52,220 --> 00:49:54,640
En wat dit is, is die helfte van die koste.

1148
00:49:54,640 --> 00:49:56,140
So dit is iets om oor te dink.

1149
00:49:56,140 --> 00:50:00,160
Wanneer jy lees uit DynamoDB en
jy die oprigting van jou lees kapasiteit

1150
00:50:00,160 --> 00:50:04,430
eenhede, as jy uiteindelik kies
konsekwent lees, is dit 'n baie goedkoper,

1151
00:50:04,430 --> 00:50:06,010
dit gaan oor die helfte van die koste.

1152
00:50:06,010 --> 00:50:09,342
>> En so dit spaar jy geld.

1153
00:50:09,342 --> 00:50:10,300
Maar dit is jou keuse.

1154
00:50:10,300 --> 00:50:12,925
As jy wil 'n konsekwente lees of
'n uiteindelik konsekwent lees.

1155
00:50:12,925 --> 00:50:15,720
Dit is iets wat jy kan kies.

1156
00:50:15,720 --> 00:50:17,659
>> Kom ons praat oor indekse.

1157
00:50:17,659 --> 00:50:19,450
So ons dat genoemde
boonste vlak samevoeging.

1158
00:50:19,450 --> 00:50:23,720
Ons het hash sleutels, en
ons het reeks sleutels.

1159
00:50:23,720 --> 00:50:24,320
Dit is lekker.

1160
00:50:24,320 --> 00:50:26,950
En dit is op die primêre tafel, ek
een gekry hash sleutel, ek het een reeks sleutel.

1161
00:50:26,950 --> 00:50:27,783
>> Wat beteken dit?

1162
00:50:27,783 --> 00:50:30,410
Ek het een spesifieke eienskap het dat ek
kan ryk navrae teen hardloop.

1163
00:50:30,410 --> 00:50:31,800
Dit is die reeks sleutel.

1164
00:50:31,800 --> 00:50:35,530
Die ander eienskappe op daardie item--
Ek kan filter op daardie eienskappe.

1165
00:50:35,530 --> 00:50:40,050
Maar ek kan nie dinge doen soos dit
begin met, of is groter as.

1166
00:50:40,050 --> 00:50:40,820
>> Hoe kan ek dit doen?

1167
00:50:40,820 --> 00:50:42,860
Ek skep 'n indeks.

1168
00:50:42,860 --> 00:50:45,340
Daar is twee tipes
indekse in DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
'N indeks is regtig
'n ander siening van die tafel.

1170
00:50:49,002 --> 00:50:50,490
En die plaaslike sekondêre indeks.

1171
00:50:50,490 --> 00:50:51,781
>> Die eerste een wat ons sal praat oor.

1172
00:50:51,781 --> 00:50:57,740
So plaaslike sekondêre word saambestaan
op dieselfde partisie as die data.

1173
00:50:57,740 --> 00:51:00,240
En as sodanig, is hulle op
dieselfde fisiese knoop.

1174
00:51:00,240 --> 00:51:01,780
Hulle is wat ons konsekwent te bel.

1175
00:51:01,780 --> 00:51:04,599
Betekenis, sal hulle erken
die skryf saam met die tafel.

1176
00:51:04,599 --> 00:51:06,890
Wanneer die skryf kom in,
ons sal skryf deur die indeks.

1177
00:51:06,890 --> 00:51:09,306
Ons sal tot die tafel te skryf,
en dan sal ons erken.

1178
00:51:09,306 --> 00:51:10,490
So dit is konsekwent.

1179
00:51:10,490 --> 00:51:13,174
Sodra die skryf was
erken van die tafel,

1180
00:51:13,174 --> 00:51:15,090
dit is gewaarborg dat die
plaaslike sekondêre indeks

1181
00:51:15,090 --> 00:51:18,380
sal dieselfde visie van data het.

1182
00:51:18,380 --> 00:51:22,390
Maar wat hulle toelaat om te doen, is
definieer alternatiewe reeks sleutels.

1183
00:51:22,390 --> 00:51:25,260
>> Moet dieselfde hash gebruik
sleutel as die primêre tafel,

1184
00:51:25,260 --> 00:51:29,050
omdat hulle saam geleë op die
dieselfde partisie, en hulle is konsekwent.

1185
00:51:29,050 --> 00:51:33,110
Maar ek kan 'n indeks te skep
met verskillende reeks sleutels.

1186
00:51:33,110 --> 00:51:41,590
So byvoorbeeld, as ek 'n vervaardiger
Dit was 'n rou dele tafel kom.

1187
00:51:41,590 --> 00:51:44,590
En rou dele kom, en
hulle saamgevoeg word deur die gemeente.

1188
00:51:44,590 --> 00:51:46,840
En miskien is daar 'n herroeping.

1189
00:51:46,840 --> 00:51:50,240
>> Enige deel wat gemaak is deur hierdie
vervaardiger na hierdie datum,

1190
00:51:50,240 --> 00:51:52,840
Ek nodig het om te trek uit my lyn.

1191
00:51:52,840 --> 00:51:55,950
Ek kan 'n indeks spin
wat sal kyk,

1192
00:51:55,950 --> 00:52:00,760
saamgevoeg op die datum van
vervaardig van daardie spesifieke deel.

1193
00:52:00,760 --> 00:52:03,930
So as my top vlak tafel was
reeds hashed deur vervaardiger,

1194
00:52:03,930 --> 00:52:07,655
Miskien was dit gereël op 'n deel ID, ek
kan 'n indeks af die tafel te skep

1195
00:52:07,655 --> 00:52:11,140
as hashed deur vervaardiger en
gewissel op die datum van vervaardiging.

1196
00:52:11,140 --> 00:52:14,490
En op die manier wat ek kan sê, iets wat
vervaardig tussen hierdie datums,

1197
00:52:14,490 --> 00:52:16,804
Ek nodig het om te trek uit die lyn.

1198
00:52:16,804 --> 00:52:18,220
So dit is 'n plaaslike sekondêre indeks.

1199
00:52:18,220 --> 00:52:22,280
>> Hulle het die effek van
beperking van jou hash sleutel ruimte.

1200
00:52:22,280 --> 00:52:24,360
Omdat hulle mede-bestaan
op dieselfde stoor knoop,

1201
00:52:24,360 --> 00:52:26,860
hulle beperk die hash sleutel
ruimte om 10 GB.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, onder die
tafels, sal partisie

1203
00:52:28,950 --> 00:52:31,380
jou tafel elke 10 GB.

1204
00:52:31,380 --> 00:52:34,760
Wanneer jy 10 gigs van data in ons
gaan [PHH], en ons nog 'n knoop.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Ons sal nie verdeel die LSI
oor verskeie partisies.

1207
00:52:42,070 --> 00:52:43,200
Ons sal die tafel te verdeel.

1208
00:52:43,200 --> 00:52:44,679
Maar ons sal nie verdeel die LSI.

1209
00:52:44,679 --> 00:52:46,470
So dit is iets
belangrik om te verstaan

1210
00:52:46,470 --> 00:52:50,070
is as jy baie doen,
baie, baie groot swerms,

1211
00:52:50,070 --> 00:52:53,860
dan is jy gaan beperk
10 GB op jou LSI.

1212
00:52:53,860 --> 00:52:56,640
>> As dit die geval is, kan ons
gebruik globale sekondêre.

1213
00:52:56,640 --> 00:52:58,630
Global sekondêre is
regtig 'n ander tafel.

1214
00:52:58,630 --> 00:53:01,720
Hulle bestaan ​​heeltemal af te
die kant van jou primêre tafel.

1215
00:53:01,720 --> 00:53:04,680
En hulle laat my 'n te vind
heeltemal ander struktuur.

1216
00:53:04,680 --> 00:53:08,010
So dink aan dit as data word ingevoeg
in twee verskillende tafels, gestruktureerde

1217
00:53:08,010 --> 00:53:09,220
in twee verskillende maniere.

1218
00:53:09,220 --> 00:53:11,360
>> Ek kan 'n heeltemal definieer
verskillende hash sleutel.

1219
00:53:11,360 --> 00:53:13,490
Ek kan 'n heeltemal definieer
verskillende reeks sleutel.

1220
00:53:13,490 --> 00:53:15,941
En ek kan dit loop
heeltemal onafhanklik.

1221
00:53:15,941 --> 00:53:18,190
As 'n saak van die feit, ek het
bevoorraad my lees kapasiteit

1222
00:53:18,190 --> 00:53:21,090
en skryf kapasiteit vir my
globale sekondêre indekse

1223
00:53:21,090 --> 00:53:24,240
heeltemal onafhanklik
van my primêre tafel.

1224
00:53:24,240 --> 00:53:26,640
As ek definieer die indeks, sê ek
dit hoeveel lees en skryf

1225
00:53:26,640 --> 00:53:28,610
kapasiteit dit gaan gebruik.

1226
00:53:28,610 --> 00:53:31,490
>> En dit is aparte
uit my primêre tafel.

1227
00:53:31,490 --> 00:53:35,240
Nou beide van die indekse ons toelaat om
nie net definieer hash en omvang sleutels,

1228
00:53:35,240 --> 00:53:38,610
maar hulle ons toelaat om
projekteer bykomende waardes.

1229
00:53:38,610 --> 00:53:44,950
So as ek wil om te lees van die indeks,
en ek wil 'n paar stel data te kry,

1230
00:53:44,950 --> 00:53:48,327
Ek het nie nodig om terug te gaan na die hoof
tabel om die bykomende eienskappe kry.

1231
00:53:48,327 --> 00:53:50,660
Ek kan daardie bykomende projekteer
eienskappe in die tabel in

1232
00:53:50,660 --> 00:53:53,440
ter ondersteuning van die toegang patroon.

1233
00:53:53,440 --> 00:53:57,700
Ek weet ons is waarskynlik om in sommige
regtig, really-- om in die onkruid

1234
00:53:57,700 --> 00:53:58,910
hier op sommige van hierdie dinge.

1235
00:53:58,910 --> 00:54:02,725
Nou het ek om weg te dryf uit hierdie.

1236
00:54:02,725 --> 00:54:07,320
>> GEHOOR: [onhoorbaar]
--table sleutel bedoel was 'n gemors?

1237
00:54:07,320 --> 00:54:08,840
Die oorspronklike hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-stroke?

1239
00:54:09,340 --> 00:54:10,200
>> Rick Houlihan: Ja.

1240
00:54:10,200 --> 00:54:11,070
Ja.

1241
00:54:11,070 --> 00:54:15,260
Die tabel sleutel basies
wys terug na die item.

1242
00:54:15,260 --> 00:54:19,280
So 'n indeks is 'n wyser terug na
die oorspronklike items op die tafel.

1243
00:54:19,280 --> 00:54:22,910
Nou kan jy kies om 'n te bou
indeks wat net het die tafel sleutel,

1244
00:54:22,910 --> 00:54:24,840
en geen ander eienskappe.

1245
00:54:24,840 --> 00:54:26,570
En hoekom kan ek dit doen?

1246
00:54:26,570 --> 00:54:28,570
Wel, miskien is ek het baie groot items.

1247
00:54:28,570 --> 00:54:31,660
>> Ek het regtig net nodig om te weet which--
my toegang patroon kan sê,

1248
00:54:31,660 --> 00:54:33,760
watter items hierdie eiendom bevat?

1249
00:54:33,760 --> 00:54:35,780
Hoef nie die item terug te keer.

1250
00:54:35,780 --> 00:54:37,800
Ek het net nodig om te weet
watter items bevat nie.

1251
00:54:37,800 --> 00:54:40,700
Sodat jy kan indekse bou
wat net die tafel sleutel.

1252
00:54:40,700 --> 00:54:43,360
>> Maar dit is hoofsaaklik wat
'n indeks in die databasis is vir.

1253
00:54:43,360 --> 00:54:46,280
Dit is vir die feit dat in staat om vinnig
identifiseer wat rekords,

1254
00:54:46,280 --> 00:54:49,470
wat rye, wat
items in die tabel het

1255
00:54:49,470 --> 00:54:51,080
die eienskappe wat ek soek.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> AVIP, so hoe werk dit?

1258
00:54:54,860 --> 00:54:58,340
AVIP basies asynchrone.

1259
00:54:58,340 --> 00:55:02,570
Die update kom in die tafel,
tafel is dan asynchroon opgedateer

1260
00:55:02,570 --> 00:55:03,720
al jou AVIP.

1261
00:55:03,720 --> 00:55:06,680
Dit is die rede waarom AVIP is
uiteindelik konsekwent.

1262
00:55:06,680 --> 00:55:09,440
>> Dit is belangrik om daarop te let dat
wanneer jy die bou van AVIP,

1263
00:55:09,440 --> 00:55:13,110
en jy verstaan ​​wat jy skep
'n ander dimensie van aggregation--

1264
00:55:13,110 --> 00:55:16,594
nou kom ons sê 'n goeie voorbeeld
hier is 'n vervaardiger.

1265
00:55:16,594 --> 00:55:19,260
Ek dink ek het dalk gepraat oor
'n mediese toestel vervaardiger.

1266
00:55:19,260 --> 00:55:23,870
Mediese toestel vervaardigers
dikwels het serialized dele.

1267
00:55:23,870 --> 00:55:28,070
Die dele wat gaan in
'n heupvervanging al

1268
00:55:28,070 --> 00:55:30,200
'n bietjie reeksnommer op hulle.

1269
00:55:30,200 --> 00:55:33,584
En hulle kon miljoene het en
miljoene en miljarde dele

1270
00:55:33,584 --> 00:55:35,000
in al die toerusting wat hulle skip.

1271
00:55:35,000 --> 00:55:37,440
Wel, wat hulle nodig het om saam te voeg onder
verskillende dimensies, al die dele

1272
00:55:37,440 --> 00:55:39,520
in 'n vergadering, al die
dele wat gemaak is

1273
00:55:39,520 --> 00:55:41,670
op 'n sekere lyn, al
die dele wat gekom

1274
00:55:41,670 --> 00:55:44,620
in van 'n sekere vervaardiger
op 'n sekere datum.

1275
00:55:44,620 --> 00:55:47,940
En dit swerms soms
opstaan ​​in die biljoene.

1276
00:55:47,940 --> 00:55:50,550
>> So ek werk met 'n paar van
hierdie ouens wat ly

1277
00:55:50,550 --> 00:55:53,156
want hulle is die skep van
hierdie ginormous swerms

1278
00:55:53,156 --> 00:55:54,280
in hul sekondêre indekse.

1279
00:55:54,280 --> 00:55:57,070
Hulle kan 'n rou dele het
tafel wat kom as net hash.

1280
00:55:57,070 --> 00:55:59,090
Elke deel het 'n unieke reeksnommer.

1281
00:55:59,090 --> 00:56:00,975
Ek gebruik die reeksnommer as die hash.

1282
00:56:00,975 --> 00:56:01,600
Dis pragtig.

1283
00:56:01,600 --> 00:56:04,160
My rou data tafel is versprei
regoor die sleutel ruimte.

1284
00:56:04,160 --> 00:56:05,930
My [? skryf?]
[? inname?] is awesome.

1285
00:56:05,930 --> 00:56:07,876
Ek neem 'n baie van die data.

1286
00:56:07,876 --> 00:56:09,500
Dan wat hulle doen, is hulle 'n GSI.

1287
00:56:09,500 --> 00:56:12,666
En ek sê, jy weet wat ek nodig het om te sien
al die dele vir hierdie vervaardiger.

1288
00:56:12,666 --> 00:56:15,060
Wel, almal van 'n skielike Ek is
neem van 'n miljard rye,

1289
00:56:15,060 --> 00:56:17,550
en stop hulle op
een knoop, want toe

1290
00:56:17,550 --> 00:56:21,170
Ek saam te voeg as die
vervaardiger ID as die hash,

1291
00:56:21,170 --> 00:56:25,410
en 'n deel nommer as die reeks,
dan sal al die skielike Ek is

1292
00:56:25,410 --> 00:56:30,530
om 'n miljard dele wat
hierdie vervaardiger het my gered.

1293
00:56:30,530 --> 00:56:34,447
>> Dit kan 'n baie laat
druk op die GSI,

1294
00:56:34,447 --> 00:56:36,030
weer, want ek gehamer een knoop.

1295
00:56:36,030 --> 00:56:38,350
Ek sit al hierdie
voeg in een knoop.

1296
00:56:38,350 --> 00:56:40,940
En dit is 'n ware problematies gebruik geval.

1297
00:56:40,940 --> 00:56:43,479
Nou, ek het 'n goeie ontwerp
patroon vir hoe jy vermy.

1298
00:56:43,479 --> 00:56:45,770
En dit is een van die probleme
dat ek altyd werk met.

1299
00:56:45,770 --> 00:56:49,590
Maar wat gebeur, is die GSI kan
genoeg skryf kapasiteit nie

1300
00:56:49,590 --> 00:56:52,330
in staat wees om te stoot almal
rye in 'n enkele knoop.

1301
00:56:52,330 --> 00:56:55,390
En wat gebeur dan is die
primêre, die kliënt tafel,

1302
00:56:55,390 --> 00:57:00,180
die primêre tabel sal gewurg
omdat die GSI nie kan byhou nie.

1303
00:57:00,180 --> 00:57:02,980
So my insetsel koers sal
val op die primêre tafel

1304
00:57:02,980 --> 00:57:06,230
as my GSI probeer om tred te hou.

1305
00:57:06,230 --> 00:57:08,850
>> Alle reg, sodat GSI se LSI se
watter een moet ek gebruik?

1306
00:57:08,850 --> 00:57:12,290
LSI se stem ooreen.

1307
00:57:12,290 --> 00:57:13,750
GSI se uiteindelik konsekwent.

1308
00:57:13,750 --> 00:57:17,490
As dit is OK, ek beveel die gebruik van 'n
GSI, hulle is baie meer buigsaam.

1309
00:57:17,490 --> 00:57:20,270
LSI se gemodelleer kan word as 'n GSI.

1310
00:57:20,270 --> 00:57:27,040
En as die data grootte per hash sleutels in
jou versameling van meer as 10 GB,

1311
00:57:27,040 --> 00:57:31,050
dan is jy gaan wil om dit te gebruik
GSI want dit is net 'n harde limiet.

1312
00:57:31,050 --> 00:57:32,035
>> Alle reg, sodat skalering.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Deurset in Dynamo DB, jy
kan voorsiening [onhoorbaar]

1315
00:57:37,460 --> 00:57:38,680
deurset om 'n tafel.

1316
00:57:38,680 --> 00:57:42,740
Ons het kliënte wat
bevoorraad 60 billion--

1317
00:57:42,740 --> 00:57:45,970
doen 60000000000 versoeke, gereeld
loop op oor 'n miljoen versoeke

1318
00:57:45,970 --> 00:57:47,790
per sekonde op ons tafels.

1319
00:57:47,790 --> 00:57:50,360
Daar is werklik geen
teoretiese beperking op hoeveel

1320
00:57:50,360 --> 00:57:53,730
en hoe vinnig die tafel
kan hardloop in Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Daar is 'n paar sagte
beperkings op jou rekening

1322
00:57:55,920 --> 00:57:58,170
dat ons sit daar in so
dat jy nie gaan mal.

1323
00:57:58,170 --> 00:58:00,070
As jy wil meer as
dat nie 'n probleem nie.

1324
00:58:00,070 --> 00:58:00,820
Jy kom vertel ons.

1325
00:58:00,820 --> 00:58:02,810
Ons sal draai die inbel.

1326
00:58:02,810 --> 00:58:08,210
>> Elke rekening word beperk tot 'n sekere vlak
in elke diens nie, net van die kolf af

1327
00:58:08,210 --> 00:58:11,920
So het die volk nie gaan mal
kry hulself in die moeilikheid.

1328
00:58:11,920 --> 00:58:12,840
Geen beperking in grootte.

1329
00:58:12,840 --> 00:58:14,940
Jy kan enige aantal sit
van die items op 'n tafel.

1330
00:58:14,940 --> 00:58:17,620
Die grootte van 'n item is
beperk tot 400 kilogrepe elk,

1331
00:58:17,620 --> 00:58:20,050
dit sou wees item nie die eienskappe.

1332
00:58:20,050 --> 00:58:24,200
So die som van al die eienskappe
is beperk tot 400 kilogrepe.

1333
00:58:24,200 --> 00:58:27,300
En dan weer, ons het
wat min LSI kwessie

1334
00:58:27,300 --> 00:58:30,405
met die 10 gigagreep limiet per hash.

1335
00:58:30,405 --> 00:58:33,280
GEHOOR: Klein nommer, ek mis
wat jy my nou vertel dat is--

1336
00:58:33,280 --> 00:58:36,830
GEHOOR: O, 400 kilogreep
is die maksimum grootte per item.

1337
00:58:36,830 --> 00:58:39,570
So 'n item het al die eienskappe.

1338
00:58:39,570 --> 00:58:43,950
So 400 k is die totale grootte
van daardie item, 400 kilogrepe.

1339
00:58:43,950 --> 00:58:46,170
So van al die eienskappe
gekombineer word, al die data

1340
00:58:46,170 --> 00:58:49,140
dit is in al die eienskappe,
opgerol in 'n totale grootte,

1341
00:58:49,140 --> 00:58:51,140
tans vandag die item limiet is 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
So weer skalering, bereik
deur skeiding.

1344
00:58:57,046 --> 00:58:58,920
Deurset is bevoorraad
by die tafel vlak.

1345
00:58:58,920 --> 00:59:00,160
En daar is eintlik twee knoppe.

1346
00:59:00,160 --> 00:59:02,400
Ons het gelees kapasiteit
en skryf kapasiteit.

1347
00:59:02,400 --> 00:59:05,530
>> So hierdie is aangepas
onafhanklik van mekaar.

1348
00:59:05,530 --> 00:59:08,640
RCU se maat streng in ooreenstemming lees.

1349
00:59:08,640 --> 00:59:13,005
OK, so as jy sê ek wil 1000
RCU se dit is streng in ooreenstemming,

1350
00:59:13,005 --> 00:59:14,130
dit is in ooreenstemming lees.

1351
00:59:14,130 --> 00:59:17,130
As jy sê ek wil
uiteindelike konsekwent lees,

1352
00:59:17,130 --> 00:59:19,402
jy kan voorsiening 1000
RCU se, jy gaan

1353
00:59:19,402 --> 00:59:21,840
om uiteindelik 2000
konsekwent lees.

1354
00:59:21,840 --> 00:59:25,940
En die helfte van die prys vir diegene
uiteindelik bestaan ​​in lees.

1355
00:59:25,940 --> 00:59:28,520
>> Weereens, aangepas
onafhanklik van mekaar.

1356
00:59:28,520 --> 00:59:32,900
En hulle het die throughput--
As jy verbruik 100% van jou RCU,

1357
00:59:32,900 --> 00:59:35,960
jy is nie van plan om die impak
beskikbaarheid van jou regte.

1358
00:59:35,960 --> 00:59:40,161
Sodat hulle is heeltemal
onafhanklik van mekaar.

1359
00:59:40,161 --> 00:59:43,160
Alle reg, sodat een van die dinge wat
Ek het genoem is kort wurg.

1360
00:59:43,160 --> 00:59:44,320
Wurgend is sleg.

1361
00:59:44,320 --> 00:59:47,311
Wurgend dui slegte geen SQL.

1362
00:59:47,311 --> 00:59:50,310
Daar is dinge wat ons kan doen om te help
jy die wurgend verlig dat jy

1363
00:59:50,310 --> 00:59:51,040
ervaar.

1364
00:59:51,040 --> 00:59:53,240
Maar die beste oplossing
hierdie is laat ons

1365
00:59:53,240 --> 00:59:58,000
'n blik op wat jy doen nie, want
daar is 'n anti-patroon in die spel hier.

1366
00:59:58,000 --> 01:00:02,140
>> Hierdie dinge, dinge soos nie-uniform
werklading, warm sleutels, warm mure.

1367
01:00:02,140 --> 01:00:06,210
Ek slaan 'n spesifieke sleutel ruimte
baie moeilik vir 'n paar spesifieke rede.

1368
01:00:06,210 --> 01:00:07,080
Hoekom doen ek dit?

1369
01:00:07,080 --> 01:00:08,710
Kom ons vind dat uit.

1370
01:00:08,710 --> 01:00:10,427
Ek meng my warm data met koue data.

1371
01:00:10,427 --> 01:00:12,510
Ek laat my tafels kry
groot, maar daar is regtig

1372
01:00:12,510 --> 01:00:15,970
slegs 'n paar van die data subset
dit is baie interessant vir my.

1373
01:00:15,970 --> 01:00:20,290
So vir log data, byvoorbeeld, 'n baie
kliënte, hulle kry teken data elke dag.

1374
01:00:20,290 --> 01:00:22,490
Hulle het 'n groot hoeveelheid van die log data.

1375
01:00:22,490 --> 01:00:25,940
>> As jy net die storting alles wat log
data in een groot tafel, met verloop van tyd

1376
01:00:25,940 --> 01:00:28,070
tafel gaan massiewe kry.

1377
01:00:28,070 --> 01:00:30,950
Maar ek is eintlik net in belangstel
afgelope 24 uur, die afgelope sewe dae,

1378
01:00:30,950 --> 01:00:31,659
die laaste 30 dae.

1379
01:00:31,659 --> 01:00:34,074
Wat ook al die venster van die tyd
dat ek belangstel in soek

1380
01:00:34,074 --> 01:00:37,010
vir die geleentheid wat my pla, of
die geval dat is interessant vir my,

1381
01:00:37,010 --> 01:00:39,540
dit is die enigste venster tyd wat ek nodig het.

1382
01:00:39,540 --> 01:00:42,470
So hoekom is ek om 10 jaar
waarde van log data in die tabel?

1383
01:00:42,470 --> 01:00:45,030
Wat is wat veroorsaak dat
die tafel van die fragment.

1384
01:00:45,030 --> 01:00:45,880
>> Dit raak groot.

1385
01:00:45,880 --> 01:00:48,340
Dit begin sprei
oor duisende nodes.

1386
01:00:48,340 --> 01:00:51,380
En sedert jou vermoë
is so laag is, is jy

1387
01:00:51,380 --> 01:00:54,090
eintlik koers beperking op elke
een van daardie individu nodes.

1388
01:00:54,090 --> 01:00:57,120
So laat ons begin kyk na hoe
doen ons rol tafel verby.

1389
01:00:57,120 --> 01:01:01,502
Hoe kry ons dat die data 'n bietjie
beter om hierdie probleme te vermy.

1390
01:01:01,502 --> 01:01:02,710
En wat beteken dit lyk?

1391
01:01:02,710 --> 01:01:04,370
Dit is wat dit lyk.

1392
01:01:04,370 --> 01:01:06,790
Dit is wat slegte NoSQL lyk.

1393
01:01:06,790 --> 01:01:07,830
>> Ek het hier 'n warm sleutel.

1394
01:01:07,830 --> 01:01:10,246
As jy kyk op die kant hier,
dit is al my mure.

1395
01:01:10,246 --> 01:01:12,630
Ek het 16 partisies hier
op hierdie spesifieke databasis.

1396
01:01:12,630 --> 01:01:13,630
Ons doen dit al die tyd.

1397
01:01:13,630 --> 01:01:15,046
Ek hardloop vir kliënte alle tye.

1398
01:01:15,046 --> 01:01:16,550
Dit is bekend as die hitte kaart.

1399
01:01:16,550 --> 01:01:20,590
Verhit kaart vertel my hoe jy
toegang tot jou sleutel ruimte.

1400
01:01:20,590 --> 01:01:23,700
En wat is dit vir my sê is
dat daar 'n bepaalde hash

1401
01:01:23,700 --> 01:01:26,330
dat dit 'n man hou van
verskriklik baie, want hy is '

1402
01:01:26,330 --> 01:01:28,250
slaan dit regtig, regtig hard.

1403
01:01:28,250 --> 01:01:29,260
>> So die blou is lekker.

1404
01:01:29,260 --> 01:01:29,900
Ons hou van blou.

1405
01:01:29,900 --> 01:01:30,720
Ons hou nie van rooi.

1406
01:01:30,720 --> 01:01:33,120
Red se waar die druk
kry tot 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, nou is jy gaan om gewurg.

1408
01:01:35,560 --> 01:01:39,030
So wanneer jy sien 'n rooi lyne soos
this-- en dit is nie net Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
elke NoSQL databasis het hierdie probleem.

1410
01:01:41,630 --> 01:01:44,640
Daar is anti-patrone wat kan
ry hierdie tipe van toestande.

1411
01:01:44,640 --> 01:01:49,070
Wat ek doen, is ek werk met kliënte
om hierdie toestande te verlig.

1412
01:01:49,070 --> 01:01:51,840
>> En wat beteken dit lyk?

1413
01:01:51,840 --> 01:01:54,260
En dit is om die mees
uit Dynamo DB deurset,

1414
01:01:54,260 --> 01:01:56,176
maar dit is regtig om
die meeste uit van NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Dit is nie beperk tot Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Dit is definitely-- ek
gebruik om te werk aan Mongo.

1417
01:02:02,050 --> 01:02:04,090
Ek is vertroud met baie NoSQL platforms.

1418
01:02:04,090 --> 01:02:06,830
Elke mens het hierdie tipe
warm sleutel probleme.

1419
01:02:06,830 --> 01:02:10,320
Om die meeste uit van 'n NoSQL
databasis, spesifiek Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
jy wil die tabelle te skep
waar die hash sleutel element het

1421
01:02:13,320 --> 01:02:18,590
'n groot aantal van verskillende waardes,
'n hoë graad van kardinaliteit.

1422
01:02:18,590 --> 01:02:22,530
Want dit beteken ek skryf
om baie van die verskillende emmers.

1423
01:02:22,530 --> 01:02:24,870
>> Die meer emmers Ek is
skriftelik aan, hoe meer waarskynlik

1424
01:02:24,870 --> 01:02:29,100
Ek is te skryf dat lading versprei of
lees laai uit oor verskeie nodusse,

1425
01:02:29,100 --> 01:02:33,560
die meer geneig om 'n ek het
hoë deurset op die tafel.

1426
01:02:33,560 --> 01:02:37,440
En dan wil ek die waardes te wees
versoek redelik eweredig oor tyd

1427
01:02:37,440 --> 01:02:39,430
en egalig lukraak as moontlik.

1428
01:02:39,430 --> 01:02:42,410
Wel, dit is soort van interessante,
want ek kan nie regtig

1429
01:02:42,410 --> 01:02:43,960
beheer wanneer die gebruikers kom.

1430
01:02:43,960 --> 01:02:47,645
So voldoende om te sê, as ons versprei
dinge uit oor die sleutel ruimte,

1431
01:02:47,645 --> 01:02:49,270
ons sal waarskynlik in 'n beter vorm.

1432
01:02:49,270 --> 01:02:51,522
>> Daar is 'n sekere
bedrag van die tyd aflewering

1433
01:02:51,522 --> 01:02:53,230
dat jy nie gaan
om in staat te beheer.

1434
01:02:53,230 --> 01:02:55,438
Maar dit is eintlik die
twee dimensies wat ons het,

1435
01:02:55,438 --> 01:02:58,800
ruimte, toegang eweredig
verspreiding, tyd, versoeke

1436
01:02:58,800 --> 01:03:01,040
aankom eweredig in die tyd.

1437
01:03:01,040 --> 01:03:03,110
En as daardie twee
voorwaardes voldoen word,

1438
01:03:03,110 --> 01:03:05,610
dan is dit wat dit is
gaan lyk.

1439
01:03:05,610 --> 01:03:07,890
Dit is baie lekkerder.

1440
01:03:07,890 --> 01:03:08,890
Ons is hier regtig gelukkig.

1441
01:03:08,890 --> 01:03:10,432
Ons het 'n baie, selfs toegang patroon.

1442
01:03:10,432 --> 01:03:13,098
Ja, miskien is jy kry 'n
bietjie druk elke nou en dan,

1443
01:03:13,098 --> 01:03:14,830
maar niks regtig te omvangryk.

1444
01:03:14,830 --> 01:03:17,660
So dit is ongelooflik hoe baie keer,
wanneer ek werk met kliënte,

1445
01:03:17,660 --> 01:03:20,670
dat die eerste grafiek met die groot rooi
bar en alles wat lelik geel dis

1446
01:03:20,670 --> 01:03:23,147
al oor die plek, ons
gedoen te kry met die oefening

1447
01:03:23,147 --> 01:03:24,980
na 'n paar maande
van re-argitektuur,

1448
01:03:24,980 --> 01:03:28,050
hulle loop presies dieselfde
werklading op presies dieselfde lading.

1449
01:03:28,050 --> 01:03:30,140
En dit is wat dit is op soek soos nou.

1450
01:03:30,140 --> 01:03:36,600
So, wat jy kry met NoSQL is 'n
data skedule dit is absoluut

1451
01:03:36,600 --> 01:03:38,510
gekoppel aan die toegang patroon.

1452
01:03:38,510 --> 01:03:42,170
>> En jy kan die data skema te optimaliseer
te ondersteun wat toegang patroon.

1453
01:03:42,170 --> 01:03:45,490
As jy dit nie doen nie, dan is jy gaan
om hierdie tipe van probleme sien

1454
01:03:45,490 --> 01:03:46,710
met dié warm sleutels.

1455
01:03:46,710 --> 01:03:50,518
>> GEHOOR: Wel, onvermydelik sommige plekke
gaan warmer wees as ander.

1456
01:03:50,518 --> 01:03:51,450
>> Rick Houlihan: Altyd.

1457
01:03:51,450 --> 01:03:51,960
Altyd.

1458
01:03:51,960 --> 01:03:54,620
Ja, ek bedoel daar is altyd
a-- en weer, daar is

1459
01:03:54,620 --> 01:03:56,980
sommige ontwerp patrone ons sal deurkom
wat sal praat oor hoe jy dit hanteer

1460
01:03:56,980 --> 01:03:58,480
met hierdie super groot swerms.

1461
01:03:58,480 --> 01:04:01,260
Ek bedoel, ek het om hulle te hê,
Hoe hanteer ons met hulle?

1462
01:04:01,260 --> 01:04:03,760
Ek het 'n goeie gebruik geval
dat ons oor sal praat vir wat.

1463
01:04:03,760 --> 01:04:05,940
>> Alle reg, so laat ons praat
oor 'n paar kliënte nou.

1464
01:04:05,940 --> 01:04:06,950
Hierdie ouens is AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Ek weet nie of jy
vertroud is met AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Jy sien hulle waarskynlik
'n baie op die leser.

1467
01:04:10,781 --> 01:04:14,230
Hulle is ad re-fokus, hulle is
die grootste advertensie re-teiken besigheid

1468
01:04:14,230 --> 01:04:14,940
daar buite.

1469
01:04:14,940 --> 01:04:17,792
Hulle gewoonlik gereeld loop oor
60000000000 transaksies per dag.

1470
01:04:17,792 --> 01:04:20,000
Hulle doen oor 'n miljoen
transaksies per sekonde.

1471
01:04:20,000 --> 01:04:22,660
Hulle het 'n mooi eenvoudige tafel het
struktuur, die besigste tafel.

1472
01:04:22,660 --> 01:04:26,450
Dit is basies net 'n
hash sleutel is die koekie,

1473
01:04:26,450 --> 01:04:29,010
die reeks is die demografiese
kategorie, en dan

1474
01:04:29,010 --> 01:04:31,220
die derde kenmerk is die telling.

1475
01:04:31,220 --> 01:04:33,720
>> So het ons almal koekies in
ons leser van hierdie ouens.

1476
01:04:33,720 --> 01:04:35,900
En wanneer jy gaan na 'n
deelnemende handelaar,

1477
01:04:35,900 --> 01:04:39,390
hulle basies kan jy score oor
verskeie demografiese kategorieë.

1478
01:04:39,390 --> 01:04:42,070
Wanneer jy na 'n webwerf en
jy sê ek wil hierdie ad-- sien

1479
01:04:42,070 --> 01:04:44,920
of basies het jy nie that-- sê
maar wanneer jy gaan na die webwerf

1480
01:04:44,920 --> 01:04:47,550
hulle sê jy wil hierdie advertensie te sien.

1481
01:04:47,550 --> 01:04:49,370
En hulle gaan kry dat die advertensie van AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll lyk jy op hul tafel.

1483
01:04:51,130 --> 01:04:52,115
Hulle vind jou koekie.

1484
01:04:52,115 --> 01:04:53,990
Die adverteerders vertel
hulle, ek wil iemand

1485
01:04:53,990 --> 01:04:58,632
wie se middeljarige,
40-jarige man, in sport.

1486
01:04:58,632 --> 01:05:01,590
En hulle kan jy score in die demografie
en hulle besluit of nie

1487
01:05:01,590 --> 01:05:02,740
dit is 'n goeie advertensie vir jou.

1488
01:05:02,740 --> 01:05:10,330
>> Nou het hulle 'n SLA met
hul advertensies verskaffers

1489
01:05:10,330 --> 01:05:14,510
om sub-10 millisekonde verskaf
reaksie op elke enkele aanvraag.

1490
01:05:14,510 --> 01:05:16,090
So hulle gebruik Dynamo DB vir hierdie.

1491
01:05:16,090 --> 01:05:18,131
Hulle is vir ons 'n tref
miljoen versoeke per sekonde.

1492
01:05:18,131 --> 01:05:21,120
Hulle is in staat om alles te doen hul
soektogte, triage alles wat data,

1493
01:05:21,120 --> 01:05:26,130
en kry wat add skakel terug na daardie
adverteerders in onder 10 millisekondes.

1494
01:05:26,130 --> 01:05:29,800
Dit is regtig mooi fenomenale
implementering wat hulle het.

1495
01:05:29,800 --> 01:05:36,210
>> Hierdie ouens actually--
is hierdie die ouens.

1496
01:05:36,210 --> 01:05:38,010
Ek is nie seker of dit hierdie ouens.

1497
01:05:38,010 --> 01:05:40,127
Dalk hierdie ouens.

1498
01:05:40,127 --> 01:05:42,210
Basies gesê us-- nee, ek
dink nie dit was hulle.

1499
01:05:42,210 --> 01:05:43,000
Ek dink dit was iemand anders.

1500
01:05:43,000 --> 01:05:44,750
Ek is besig met 'n
kliënt wat my vertel

1501
01:05:44,750 --> 01:05:47,040
wat nou dat hulle het
gegaan om Dynamo DB, hulle is

1502
01:05:47,040 --> 01:05:50,330
spandeer meer geld op snacks vir
hul ontwikkeling span elke maand

1503
01:05:50,330 --> 01:05:52,886
as wat hulle spandeer op hul databasis.

1504
01:05:52,886 --> 01:05:54,760
So dit gee jou 'n gee
idee van die kostebesparings

1505
01:05:54,760 --> 01:05:57,889
wat jy kan kry in Dynamo DB is groot.

1506
01:05:57,889 --> 01:05:59,430
Alle reg, dropcam is 'n ander maatskappy.

1507
01:05:59,430 --> 01:06:02,138
Hierdie man is soort of-- as jy dink
van internet van dinge, dropcam

1508
01:06:02,138 --> 01:06:05,150
is basies internet sekuriteit video.

1509
01:06:05,150 --> 01:06:06,660
Jy sit jou kamera daar buite.

1510
01:06:06,660 --> 01:06:08,180
Kamera het 'n mosie detector.

1511
01:06:08,180 --> 01:06:10,290
Iemand kom saam,
snellers 'n wit punt.

1512
01:06:10,290 --> 01:06:13,540
Kamera begin opname vir 'n rukkie totdat
dit nie enige beweging meer op te spoor.

1513
01:06:13,540 --> 01:06:15,310
Plaas dat die video op die internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam was 'n maatskappy wat
basies oorgeskakel na Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
omdat hulle ervaar
enorme groeipyne.

1516
01:06:22,200 --> 01:06:25,820
En wat hulle vir ons gesê,
skielik petabytes van data.

1517
01:06:25,820 --> 01:06:28,070
Hulle het geen idee gehad hulle diens
sou so suksesvol te wees.

1518
01:06:28,070 --> 01:06:32,310
Meer inkomende video as YouTube
is wat hierdie ouens kry.

1519
01:06:32,310 --> 01:06:36,780
Hulle gebruik DynamoDB te spoor al die
metadata op al hul video belangrike punte.

1520
01:06:36,780 --> 01:06:40,282
>> So het hulle S3 emmers hulle stoot
al die binêre artefakte in.

1521
01:06:40,282 --> 01:06:41,990
En dan het hulle
Dynamo DB rekords wat

1522
01:06:41,990 --> 01:06:44,070
wys mense aan diegene S3 drie voorwerpe.

1523
01:06:44,070 --> 01:06:47,070
Wanneer hulle nodig het om te kyk na 'n video,
hulle kyk op die rekord in Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Hulle klik op die skakel.

1525
01:06:47,903 --> 01:06:49,770
Hulle trek die video van S3.

1526
01:06:49,770 --> 01:06:51,590
So dit is soort van wat dit lyk soos.

1527
01:06:51,590 --> 01:06:53,580
En dit is reguit uit hul span.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB verminder hul
lewering tyd vir video gebeure

1529
01:06:56,010 --> 01:06:57,590
van vyf tot 10 sekondes.

1530
01:06:57,590 --> 01:07:00,470
In hul ou relasionele winkel,
hulle gebruik het om te gaan en uit te voer

1531
01:07:00,470 --> 01:07:03,780
verskeie komplekse navrae aan figuur
watter videos af te trek,

1532
01:07:03,780 --> 01:07:06,690
tot minder as 50 millisekondes.

1533
01:07:06,690 --> 01:07:08,990
So dit is ongelooflik, amazing
hoeveel prestasie

1534
01:07:08,990 --> 01:07:12,990
wat jy kan kry as jy optimaliseer en
jy tune die onderliggende databasis

1535
01:07:12,990 --> 01:07:15,110
ter ondersteuning van die toegang patroon.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, hierdie ouens, wat is dit,
Vrugte Ninja ek dink is hulle ding.

1537
01:07:20,500 --> 01:07:22,590
Dat alle lopies op Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
En hierdie ouens, hulle is 'n groot
ontwikkeling span, groot ontwikkeling

1539
01:07:26,810 --> 01:07:27,670
winkel.

1540
01:07:27,670 --> 01:07:29,364
>> Nie 'n goeie span ops.

1541
01:07:29,364 --> 01:07:31,280
Hulle het nie 'n baie
van die operasie hulpbronne.

1542
01:07:31,280 --> 01:07:33,940
Hulle sukkel om aan te hou probeer
hul aansoek infrastruktuur up

1543
01:07:33,940 --> 01:07:34,290
en hardloop.

1544
01:07:34,290 --> 01:07:35,000
Hulle het gekom om ons.

1545
01:07:35,000 --> 01:07:36,251
Hulle kyk na wat Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Hulle het gesê, dit is vir ons.

1547
01:07:37,291 --> 01:07:39,470
Hulle het hul hele
aansoek raamwerk op dit.

1548
01:07:39,470 --> 01:07:43,640
Hier 'n paar baie mooi kommentaar
uit die span op hul vermoë

1549
01:07:43,640 --> 01:07:46,800
nou fokus op die bou
die spel en nie

1550
01:07:46,800 --> 01:07:49,010
om te handhaaf die
infrastruktuur, wat

1551
01:07:49,010 --> 01:07:51,910
was besig om 'n enorme bedrag
van oorhoofse vir hul span.

1552
01:07:51,910 --> 01:07:56,170
So dit is iets that-- die
voordeel wat jy kry van Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Alle reg, om in
data modelle hier.

1554
01:08:00,930 --> 01:08:03,440
En ons het gepraat 'n bietjie oor
hierdie een tot een, een vir baie,

1555
01:08:03,440 --> 01:08:05,060
en baie baie tipe verhoudings.

1556
01:08:05,060 --> 01:08:07,630
En hoe kan jy in stand te hou wat in Dynamo.

1557
01:08:07,630 --> 01:08:10,500
In Dynamo DB gebruik ons
indekse algemeen

1558
01:08:10,500 --> 01:08:12,910
om die data van roteer
een geur aan die ander kant.

1559
01:08:12,910 --> 01:08:15,210
Hash sleutels, reeks sleutels, en indekse.

1560
01:08:15,210 --> 01:08:18,540
>> In hierdie spesifieke
Byvoorbeeld, as die meeste lande

1561
01:08:18,540 --> 01:08:23,802
'n vereiste dat die lisensiëring
net een bestuurder lisensie se per persoon.

1562
01:08:23,802 --> 01:08:26,510
Jy kan nie na twee bestuurder kry
lisensies in die staat van Boston.

1563
01:08:26,510 --> 01:08:27,500
Ek kan dit nie doen nie in Texas.

1564
01:08:27,500 --> 01:08:28,708
Dit is soort van die manier waarop dit is.

1565
01:08:28,708 --> 01:08:32,779
En so by die DMV, ons het soektogte, ons
wil om te kyk up die rybewys

1566
01:08:32,779 --> 01:08:35,180
deur die sosiale sekerheid nommer.

1567
01:08:35,180 --> 01:08:39,990
Ek wil om te kyk die gebruiker besonderhede
deur die bestuurder se lisensie nommer.

1568
01:08:39,990 --> 01:08:43,620
>> So kan ons tafel 'n gebruiker se het dat
het 'n hash sleutel op die reeksnommer,

1569
01:08:43,620 --> 01:08:47,830
of die sosiale sekerheid nommer, en
verskeie eienskappe gedefinieer op die item.

1570
01:08:47,830 --> 01:08:49,859
Nou op die tafel ek
'n GSI kan definieer wat

1571
01:08:49,859 --> 01:08:53,370
flips dat ongeveer wat sê ek wil
'n hash sleutel op die lisensie en dan

1572
01:08:53,370 --> 01:08:54,252
al die ander items.

1573
01:08:54,252 --> 01:08:57,210
Nou as ek wil navraag en vind die
lisensie nommer vir enige gegewe Maatskaplike

1574
01:08:57,210 --> 01:08:59,609
Security nommer, ek kan
navraag die hooftafel.

1575
01:08:59,609 --> 01:09:02,130
>> As ek wil navraag en ek wil
om die sosiale sekerheid te kry

1576
01:09:02,130 --> 01:09:05,735
nommer of ander eienskappe deur 'n
lisensie nommer, kan ek navraag die GSI.

1577
01:09:05,735 --> 01:09:08,689
Dit model is dat 'n mens
tot een verhouding.

1578
01:09:08,689 --> 01:09:12,460
Net 'n baie eenvoudige GSI,
flip die dinge rondom.

1579
01:09:12,460 --> 01:09:13,979
Nou, praat oor een vir baie.

1580
01:09:13,979 --> 01:09:16,450
Een baie basies
jou hash reeks sleutel.

1581
01:09:16,450 --> 01:09:20,510
Waar kry ons 'n baie met hierdie
gebruik geval is monitor data.

1582
01:09:20,510 --> 01:09:23,880
Monitor data kom in gereelde
interval, soos die internet van die dinge.

1583
01:09:23,880 --> 01:09:26,890
Ons kry altyd al hierdie
rekords kom in al die tyd.

1584
01:09:26,890 --> 01:09:31,420
>> En ek wil al die lesings vind
tussen 'n bepaalde tydperk.

1585
01:09:31,420 --> 01:09:34,220
Dit is 'n baie algemene navraag in
monitering infrastruktuur.

1586
01:09:34,220 --> 01:09:38,430
Die pad gaan oor wat 'n te vind
eenvoudige tafel struktuur, 'n tafel.

1587
01:09:38,430 --> 01:09:42,250
Ek het 'n tafel metings toestel het
met 'n hash sleutel op die toestel ID.

1588
01:09:42,250 --> 01:09:47,340
En ek het 'n reeks-sleutel op die
tyd stempel, of in hierdie geval, die epiese.

1589
01:09:47,340 --> 01:09:50,350
En dat laat my kompleks voer
navrae teen daardie reeks sleutel

1590
01:09:50,350 --> 01:09:54,950
en terug te keer die rekords wat
relatief tot die resultaat

1591
01:09:54,950 --> 01:09:56,310
stel dat ek is op soek na.

1592
01:09:56,310 --> 01:09:58,360
En dit bou dat 'n mens
baie-verhouding

1593
01:09:58,360 --> 01:10:02,340
in die primêre tabel deur die
hash sleutel, reeks sleutel struktuur.

1594
01:10:02,340 --> 01:10:04,600
>> So dit is soort van 'n ingeboude
in die tabel in Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Toe ek 'n hash definieer
en verskeidenheid t tafel, ek is

1596
01:10:07,290 --> 01:10:09,240
definisie van 'n een tot baie-verhouding.

1597
01:10:09,240 --> 01:10:12,770
Dit is 'n ouer-kind verhouding.

1598
01:10:12,770 --> 01:10:14,620
>> Kom ons praat oor baie
baie verhoudings.

1599
01:10:14,620 --> 01:10:19,170
En vir hierdie spesifieke voorbeeld,
weer, gaan ons GSI se gebruik.

1600
01:10:19,170 --> 01:10:23,500
En laat ons praat oor die spel
scenario waar ek 'n gegewe gebruiker.

1601
01:10:23,500 --> 01:10:26,500
Ek wil om uit te vind al die speletjies wat
hy geregistreer of speel in.

1602
01:10:26,500 --> 01:10:29,600
En vir 'n gegewe spel, ek
wil al die gebruikers te vind.

1603
01:10:29,600 --> 01:10:31,010
So hoe kan ek dit doen?

1604
01:10:31,010 --> 01:10:34,330
My gebruiker speletjies tafel, ek gaan
'n hash sleutel van gebruiker ID het

1605
01:10:34,330 --> 01:10:35,810
en 'n reeks sleutel van die spel.

1606
01:10:35,810 --> 01:10:37,810
>> So 'n gebruiker kan het veelvuldige speletjies.

1607
01:10:37,810 --> 01:10:41,380
Dit is 'n een tot baie-verwantskap tussen
die gebruiker en die games wat hy speel.

1608
01:10:41,380 --> 01:10:43,410
En dan op die GSI,
Ek sal dat ongeveer flip.

1609
01:10:43,410 --> 01:10:46,679
Ek op die spel sal hash en
Ek sal wissel op die gebruiker.

1610
01:10:46,679 --> 01:10:48,970
So as ek wil al die kry
spel die gebruiker se speel in,

1611
01:10:48,970 --> 01:10:49,950
Ek sal die hooftafel navraag.

1612
01:10:49,950 --> 01:10:52,699
As ek wil al die gebruikers kry
wat speel 'n spesifieke spel,

1613
01:10:52,699 --> 01:10:53,887
Ek bevraagteken die GSI.

1614
01:10:53,887 --> 01:10:54,970
So jy sien hoe ons dit doen?

1615
01:10:54,970 --> 01:10:58,369
Jy bou hierdie GSI om die steun
gebruik geval, die aansoek, die toegang

1616
01:10:58,369 --> 01:10:59,410
patroon, die aansoek.

1617
01:10:59,410 --> 01:11:01,440
>> As ek nodig om 'n navraag op
hierdie dimensie, laat

1618
01:11:01,440 --> 01:11:03,500
my te skep 'n indeks op daardie dimensie.

1619
01:11:03,500 --> 01:11:05,850
As ek dit nie doen nie, kan ek nie om nie.

1620
01:11:05,850 --> 01:11:09,060
En afhangende van die gebruik geval, ek
kan die indeks nodig het of ek dalk nie.

1621
01:11:09,060 --> 01:11:12,390
As dit is 'n eenvoudige een tot baie
die primêre tafel is goed.

1622
01:11:12,390 --> 01:11:15,860
As ek nodig het om hierdie baie doen om
baie se, of ek moet die een na kinders te doen,

1623
01:11:15,860 --> 01:11:18,390
dan miskien ek hoef
tweede die indeks.

1624
01:11:18,390 --> 01:11:20,840
So dit hang alles af
wat ek probeer om te doen

1625
01:11:20,840 --> 01:11:24,550
en wat ek probeer om te kry voldonge.

1626
01:11:24,550 --> 01:11:28,000
>> Waarskynlik Ek gaan nie te spandeer
veel tyd praat oor dokumente.

1627
01:11:28,000 --> 01:11:31,460
Dit kry 'n bietjie, waarskynlik,
dieper as wat ons nodig het om in te gaan.

1628
01:11:31,460 --> 01:11:33,710
Kom ons praat 'n bietjie
oor ryk navraag uitdrukking.

1629
01:11:33,710 --> 01:11:37,831
So in Dynamo DB ons het
die vermoë om te skep

1630
01:11:37,831 --> 01:11:39,330
wat ons noem projeksie uitdrukkings.

1631
01:11:39,330 --> 01:11:42,660
Projeksie uitdrukkings is eenvoudig
pluk die velde of die waardes

1632
01:11:42,660 --> 01:11:44,290
wat jy wil om te wys.

1633
01:11:44,290 --> 01:11:46,000
OK, so ek maak 'n keuse.

1634
01:11:46,000 --> 01:11:48,010
Ek maak 'n navraag teen Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
En ek sê, jy weet wat, show
my net die vyf ster resensies

1636
01:11:51,730 --> 01:11:54,544
vir hierdie produk.

1637
01:11:54,544 --> 01:11:55,710
So dit is al wat ek wil sien.

1638
01:11:55,710 --> 01:11:57,320
Ek wil nie al die sien
ander eienskappe van die ry,

1639
01:11:57,320 --> 01:11:58,319
Ek wil net om dit te sien.

1640
01:11:58,319 --> 01:12:01,209
Dit is net soos in SQL wanneer jy
sê kies ster of van die tafel,

1641
01:12:01,209 --> 01:12:02,000
jy alles.

1642
01:12:02,000 --> 01:12:05,450
Wanneer ek sê kies naam
tafel, ek kry net een kenmerk.

1643
01:12:05,450 --> 01:12:09,070
Dit is dieselfde soort ding in
Dynamo DB of ander NoSQL databasisse.

1644
01:12:09,070 --> 01:12:14,510
Filter uitdrukkings toelaat om my te
basies sny die stel af gevolg.

1645
01:12:14,510 --> 01:12:15,540
So maak ek 'n navraag.

1646
01:12:15,540 --> 01:12:17,260
Navraag kan terug kom met 500 items.

1647
01:12:17,260 --> 01:12:20,255
Maar ek wil net die items wat
'n kenmerk dat dit sê.

1648
01:12:20,255 --> 01:12:23,380
OK, so laat filter diegene items
wat nie ooreenstem met die spesifieke navraag.

1649
01:12:23,380 --> 01:12:25,540
So het ons filter uitdrukkings.

1650
01:12:25,540 --> 01:12:28,310
>> Filter uitdrukkings kan
uitgevoer word op 'n kenmerk.

1651
01:12:28,310 --> 01:12:30,260
Hulle is nie soos reeks navrae.

1652
01:12:30,260 --> 01:12:32,690
Samel navrae is meer selektief.

1653
01:12:32,690 --> 01:12:36,470
Navrae Filter vereis my om te gaan
kry die hele resultate stel en dan

1654
01:12:36,470 --> 01:12:39,170
kerf uit die data wat ek wil nie.

1655
01:12:39,170 --> 01:12:40,660
Hoekom is dit belangrik?

1656
01:12:40,660 --> 01:12:42,770
Want ek lees dit alles.

1657
01:12:42,770 --> 01:12:46,597
In 'n navraag, ek gaan om te lees en
dit gaan 'n reuse-oor die data wees.

1658
01:12:46,597 --> 01:12:48,430
En dan gaan ek
kerf uit wat ek nodig het.

1659
01:12:48,430 --> 01:12:52,080
En as ek net 'n kerf
paar rye, dan is dit OK.

1660
01:12:52,080 --> 01:12:53,620
Dit is nie so ondoeltreffend.

1661
01:12:53,620 --> 01:12:57,800
>> Maar as ek lees van 'n hele stapel
data, net om uit te kerf een item,

1662
01:12:57,800 --> 01:13:01,490
dan gaan ek beter wees
af met behulp van 'n verskeidenheid navraag,

1663
01:13:01,490 --> 01:13:03,030
want dit is baie meer selektief.

1664
01:13:03,030 --> 01:13:06,330
Dit gaan om my te red 'n baie
geld, want ek betaal vir daardie lees.

1665
01:13:06,330 --> 01:13:10,430
Waar die resultate wat terug kom
steek wat draad kleiner mag wees,

1666
01:13:10,430 --> 01:13:11,890
maar ek betaal vir die lees.

1667
01:13:11,890 --> 01:13:14,340
So verstaan ​​hoe
jy kry die data.

1668
01:13:14,340 --> 01:13:16,420
Dit is baie belangrik in Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Voorwaardelike uitdrukkings, dit is wat
jy dalk optimisties locking noem.

1670
01:13:19,710 --> 01:13:28,470
Update indien bestaan, of indien hierdie waarde
is gelykstaande aan wat ek spesifiseer.

1671
01:13:28,470 --> 01:13:31,494
En as ek 'n tyd stempel op 'n
rekord, kan ek die data te lees.

1672
01:13:31,494 --> 01:13:32,535
Ek kan die data verander.

1673
01:13:32,535 --> 01:13:35,030
Ek kan gaan skryf dat
data terug na die databasis.

1674
01:13:35,030 --> 01:13:38,100
As iemand het verander die rekord,
die tyd stempel verander het.

1675
01:13:38,100 --> 01:13:40,370
En op die manier my voorwaardelike
update kan update sê

1676
01:13:40,370 --> 01:13:42,340
indien die tyd stempel gelyk hiervan.

1677
01:13:42,340 --> 01:13:46,290
Of die update sal misluk omdat iemand
opgedateer die rekord in die tussentyd.

1678
01:13:46,290 --> 01:13:48,290
>> Dit is wat ons optimisties locking noem.

1679
01:13:48,290 --> 01:13:50,670
Dit beteken dat iemand
kan in te kom en dit verander,

1680
01:13:50,670 --> 01:13:53,100
en ek gaan om dit te spoor
wanneer ek terug gaan om te skryf.

1681
01:13:53,100 --> 01:13:56,106
En dan kan ek eintlik lees dat
data en sê: Ag, hierdie verander hy gesê.

1682
01:13:56,106 --> 01:13:57,230
Ek nodig het om rekenskap te gee.

1683
01:13:57,230 --> 01:14:00,490
En ek kan die data in te verander my
teken en 'n ander update toe te pas.

1684
01:14:00,490 --> 01:14:04,330
So kan jy die inkrementele vang
updates wat plaasvind tussen die tyd

1685
01:14:04,330 --> 01:14:08,740
dat jy die data en die lees
tyd wat jy kan die data te skryf.

1686
01:14:08,740 --> 01:14:11,520
>> GEHOOR: En die filter
uitdrukking beteken eintlik nie

1687
01:14:11,520 --> 01:14:13,020
in die aantal of not--

1688
01:14:13,020 --> 01:14:14,316
>> [INTERPOSING VOICES]

1689
01:14:14,316 --> 01:14:16,232
Rick Houlihan: Ek sal nie
kry te veel in hierdie.

1690
01:14:16,232 --> 01:14:17,700
Dit is 'n gereserveerde navraag.

1691
01:14:17,700 --> 01:14:20,130
Die pond View is 'n voorbehou
navraag in Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Elke databasis het sy eie voorbehou
name versamelings kan jy nie gebruik nie.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, as jy spesifiseer
'n pond in die voorkant van hierdie,

1694
01:14:27,240 --> 01:14:29,310
kan jy die name bo definieer up.

1695
01:14:29,310 --> 01:14:31,840
Dit is 'n gekla waarde.

1696
01:14:31,840 --> 01:14:34,880
Dit is waarskynlik nie die beste sintaksis om
het daar vir hierdie bespreking,

1697
01:14:34,880 --> 01:14:38,090
want dit kry in 'n paar real--
Ek sou gewees praat meer

1698
01:14:38,090 --> 01:14:41,360
oor dat op 'n dieper vlak.

1699
01:14:41,360 --> 01:14:46,130
>> Maar voldoende om te sê nie, kan dit
wees navraag scan waar hulle views--

1700
01:14:46,130 --> 01:14:50,190
nie menings pond is groter as 10.

1701
01:14:50,190 --> 01:14:54,660
Dit is 'n numeriese waarde, ja.

1702
01:14:54,660 --> 01:14:57,322
As jy wil, kan ons praat oor
dat na die bespreking.

1703
01:14:57,322 --> 01:15:00,030
Alle reg, sodat ons kry in
sommige gevalle in die beste praktyke

1704
01:15:00,030 --> 01:15:02,000
waar ons gaan om te praat
oor 'n paar apps hier.

1705
01:15:02,000 --> 01:15:03,810
Wat is die gebruik gevalle vir Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Wat is die ontwerp
patrone in Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> En die eerste een wat ons gaan
praat oor die internet van die dinge.

1708
01:15:09,110 --> 01:15:15,010
So kry ons 'n baie of-- dink ek,
Wat is it-- meer as 50%

1709
01:15:15,010 --> 01:15:19,370
van die verkeer op die internet hierdie dae
is eintlik deur masjiene gegenereer word,

1710
01:15:19,370 --> 01:15:21,930
outomatiese prosesse, nie deur die mens.

1711
01:15:21,930 --> 01:15:25,140
Ek bedoel hierdie ding ding wat
jy rond te dra in jou sak,

1712
01:15:25,140 --> 01:15:28,840
hoeveel data dat ding is
eintlik stuur om sonder jou

1713
01:15:28,840 --> 01:15:30,550
wetende dat dit is absoluut amazing.

1714
01:15:30,550 --> 01:15:34,970
Jou plek, inligting
oor hoe vinnig jy gaan.

1715
01:15:34,970 --> 01:15:38,400
Hoe dink jy Google Maps werke
wanneer hulle jou vertel wat die verkeer is.

1716
01:15:38,400 --> 01:15:41,275
Dit is omdat daar miljoene en
miljoene mense rondry

1717
01:15:41,275 --> 01:15:44,667
met selfone wat stuur
data oor die hele tyd plaasvind.

1718
01:15:44,667 --> 01:15:46,500
So een van die dinge
oor hierdie tipe van data

1719
01:15:46,500 --> 01:15:50,980
wat kom in, monitor data, teken
data, tydreeksdata, is dit

1720
01:15:50,980 --> 01:15:53,540
gewoonlik net interessante
vir 'n bietjie van die tyd.

1721
01:15:53,540 --> 01:15:55,580
Na daardie tyd, is dit
nie so interessant.

1722
01:15:55,580 --> 01:15:58,390
So het ons gepraat oor, moenie toelaat
die tafels groei sonder grense.

1723
01:15:58,390 --> 01:16:03,410
Die idee hier is dat miskien ek het 24
uur se gebeure in my warm tafel.

1724
01:16:03,410 --> 01:16:06,160
En dat warm tafel gaan wees
bevoorraad op 'n baie hoë koers,

1725
01:16:06,160 --> 01:16:07,950
want dit is die neem van 'n baie data.

1726
01:16:07,950 --> 01:16:10,920
Dit neem 'n baie van die data
in en ek lees dit baie.

1727
01:16:10,920 --> 01:16:14,560
Ek het 'n baie van die operasie het
navrae hardloop teen daardie data.

1728
01:16:14,560 --> 01:16:18,120
>> Na 24 uur, hey, jy
weet wat, ek gee nie om nie.

1729
01:16:18,120 --> 01:16:21,150
So miskien elke middernag ek roll
my tafel oor na 'n nuwe tabel

1730
01:16:21,150 --> 01:16:22,430
en ek deprovision hierdie tabel.

1731
01:16:22,430 --> 01:16:26,440
En Ek neem die RCU en
WCU se af, want 24 uur later

1732
01:16:26,440 --> 01:16:28,630
Ek hardloop nie soveel
navrae teen daardie data.

1733
01:16:28,630 --> 01:16:30,200
So ek gaan om geld te spaar.

1734
01:16:30,200 --> 01:16:32,940
En miskien 30 dae later het ek nie
eens nodig om te sorg oor dit alles.

1735
01:16:32,940 --> 01:16:35,020
Ek kon neem die WCU se
al die pad af aan die een,

1736
01:16:35,020 --> 01:16:36,990
omdat jy weet wat, dis
nooit gaan kry geskryf na.

1737
01:16:36,990 --> 01:16:38,300
Die data is 30 dae oud.

1738
01:16:38,300 --> 01:16:40,000
Dit verander nooit.

1739
01:16:40,000 --> 01:16:44,200
>> En dit is byna nooit gaan kry te lees,
so laat ons neem net wat RCU af na 10.

1740
01:16:44,200 --> 01:16:49,372
En Ek spaar 'n ton geld op hierdie
data, en slegs betaal vir my warm data.

1741
01:16:49,372 --> 01:16:52,330
So wat is die belangrikste ding om te kyk
op as jy kyk na 'n tyd reeks

1742
01:16:52,330 --> 01:16:54,716
data kom in volume.

1743
01:16:54,716 --> 01:16:55,590
Hierdie is strategieë.

1744
01:16:55,590 --> 01:16:58,010
Nou, ek kan net laat dit
al gaan na die tafel

1745
01:16:58,010 --> 01:16:59,461
en net laat die tafel te groei.

1746
01:16:59,461 --> 01:17:01,460
Uiteindelik, ek gaan
sien prestasie.

1747
01:17:01,460 --> 01:17:04,060
Ek gaan om te begin na argief
sommige van daardie data van die tafel af,

1748
01:17:04,060 --> 01:17:04,720
wat nie.

1749
01:17:04,720 --> 01:17:07,010
>> Kom ons baie beter
ontwerp jou aansoek

1750
01:17:07,010 --> 01:17:08,900
sodat jy kan op hierdie manier te werk.

1751
01:17:08,900 --> 01:17:11,460
So dit is net 'n outomatiese
in die aansoek-kode.

1752
01:17:11,460 --> 01:17:13,580
Middernag elke aand
dit rolle die tafel.

1753
01:17:13,580 --> 01:17:17,170
Miskien wat ek nodig het, is 'n gly
venster van 24 uur van data.

1754
01:17:17,170 --> 01:17:20,277
Dan op 'n gereelde basis Ek is
roep data van die tafel af.

1755
01:17:20,277 --> 01:17:22,360
Ek is dit met 'n snoei
Cron en ek sit dit

1756
01:17:22,360 --> 01:17:24,160
op die ander tafels,
alles wat jy nodig het.

1757
01:17:24,160 --> 01:17:25,940
So as 'n roll werk, dit is 'n groot.

1758
01:17:25,940 --> 01:17:27,080
Indien nie, snoei nie.

1759
01:17:27,080 --> 01:17:29,640
Maar laat ons hou dat warm data
weg van jou koue data.

1760
01:17:29,640 --> 01:17:32,535
Dit sal red jy 'n klomp geld en
jou tafels meer presteer.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
So die volgende ding wat ons sal praat
oor is 'n produk katalogus.

1763
01:17:38,210 --> 01:17:42,000
Produk katalogus is
redelik algemeen gebruik geval.

1764
01:17:42,000 --> 01:17:46,600
Dit is eintlik 'n baie algemene patroon
dat ons sal sien in 'n verskeidenheid van dinge.

1765
01:17:46,600 --> 01:17:48,870
Jy weet, Twitter vir
Byvoorbeeld, 'n warm tweet.

1766
01:17:48,870 --> 01:17:51,280
Almal se koms en
gryp wat tweet.

1767
01:17:51,280 --> 01:17:52,680
Produk katalogus, ek het 'n verkoop.

1768
01:17:52,680 --> 01:17:54,120
Ek het 'n warm verkoop.

1769
01:17:54,120 --> 01:17:57,277
Ek het 70.000 versoeke per
wederkoms vir 'n produk

1770
01:17:57,277 --> 01:17:58,860
beskrywing uit my produk katalogus.

1771
01:17:58,860 --> 01:18:02,384
Ons sien dit op die kleinhandel
werking nogal 'n bietjie.

1772
01:18:02,384 --> 01:18:03,550
So hoe hanteer ons dit?

1773
01:18:03,550 --> 01:18:04,924
Daar is geen manier om te gaan met dit.

1774
01:18:04,924 --> 01:18:07,110
Al my gebruikers wil sien
dieselfde stuk data.

1775
01:18:07,110 --> 01:18:09,410
Hulle is kom in, gelyktydig.

1776
01:18:09,410 --> 01:18:11,920
En hulle is almal versoeke
vir dieselfde stuk data.

1777
01:18:11,920 --> 01:18:16,240
Dit gee my dat warm sleutel, dat die groot rooi
streep op my grafiek dat ons nie hou nie.

1778
01:18:16,240 --> 01:18:17,720
En dit is wat die lyk.

1779
01:18:17,720 --> 01:18:22,290
So oor my sleutel ruimte Ek kry
gehamer in die verkoop items.

1780
01:18:22,290 --> 01:18:24,070
Ek kry niks nêrens anders.

1781
01:18:24,070 --> 01:18:26,050
>> Hoe kan ek hierdie probleem te verlig?

1782
01:18:26,050 --> 01:18:28,410
Wel, ons dit verlig met kas.

1783
01:18:28,410 --> 01:18:33,630
Kas, basies 'n sit jy in-geheue
partisie in die voorkant van die databasis.

1784
01:18:33,630 --> 01:18:37,260
Ons het daarin geslaag
[Onhoorbaar] kas, hoe jy

1785
01:18:37,260 --> 01:18:40,260
kan die opstel van jou eie kas, [onhoorbaar]
kas [? d,?] wat jy wil.

1786
01:18:40,260 --> 01:18:42,220
Sit dit in die voorkant van die databasis.

1787
01:18:42,220 --> 01:18:47,250
En op die manier wat jy kan stoor data
van dié warm sleutels in daardie kas

1788
01:18:47,250 --> 01:18:49,390
ruimte en lees deur die kas.

1789
01:18:49,390 --> 01:18:51,962
>> En dan die meeste van jou lees
begin soek soos hierdie.

1790
01:18:51,962 --> 01:18:54,920
Ek het al hierdie kas treffers hier
en ek het niks aan die gang hier af

1791
01:18:54,920 --> 01:18:59,330
omdat databasis sit agter die
kas en die lui nooit deur.

1792
01:18:59,330 --> 01:19:02,520
As ek die data in die verander
databasis, ek het in die kas te werk.

1793
01:19:02,520 --> 01:19:04,360
Ons kan iets gebruik
soos stoom om dit te doen.

1794
01:19:04,360 --> 01:19:07,360
En Ek sal verduidelik hoe dit werk.

1795
01:19:07,360 --> 01:19:09,060
Alle reg, boodskappe.

1796
01:19:09,060 --> 01:19:11,180
E-pos, ons almal gebruik e-pos.

1797
01:19:11,180 --> 01:19:12,540
>> Dit is 'n baie goeie voorbeeld.

1798
01:19:12,540 --> 01:19:14,950
Ons het 'n soort van boodskappe tafel.

1799
01:19:14,950 --> 01:19:17,040
En ons het posbus en outbox.

1800
01:19:17,040 --> 01:19:19,760
Dit is wat die SQL sou
kyk graag dat posbus te bou.

1801
01:19:19,760 --> 01:19:23,350
Ons soort van gebruik dieselfde soort
strategie om GSI se gebruik GSI se

1802
01:19:23,350 --> 01:19:25,320
vir my inbox en outbox my.

1803
01:19:25,320 --> 01:19:27,600
So ek het rou boodskappe kom
in my boodskappe tafel.

1804
01:19:27,600 --> 01:19:30,194
En die eerste benadering tot hierdie
mag wees, sê OK, geen probleem.

1805
01:19:30,194 --> 01:19:31,110
Ek het rou boodskappe gekry.

1806
01:19:31,110 --> 01:19:33,710
Boodskappe kom [onhoorbaar],
boodskap ID, dit is 'n groot.

1807
01:19:33,710 --> 01:19:35,070
Dit is my unieke hash.

1808
01:19:35,070 --> 01:19:38,280
Ek gaan om te skep twee GSI se een
vir my inbox, een vir my outbox.

1809
01:19:38,280 --> 01:19:40,530
En die eerste ding wat ek sal doen
is ek sal sê my hash sleutel is

1810
01:19:40,530 --> 01:19:43,310
gaan na die ontvanger en
Ek gaan om te reël op die datum.

1811
01:19:43,310 --> 01:19:44,220
Dit is fantasties.

1812
01:19:44,220 --> 01:19:45,890
Ek het my mooi uitsig hier.

1813
01:19:45,890 --> 01:19:47,780
Maar daar is hier 'n bietjie kwessie.

1814
01:19:47,780 --> 01:19:50,891
En jy loop in hierdie in
relasionele databasisse sowel.

1815
01:19:50,891 --> 01:19:52,390
Hulle het vertikaal skeiding.

1816
01:19:52,390 --> 01:19:55,840
Jy wil jou groot data hou
weg van jou min data.

1817
01:19:55,840 --> 01:20:00,470
>> En die rede hoekom is omdat ek moet
gaan lees die items na die eienskappe kry.

1818
01:20:00,470 --> 01:20:05,570
En as my liggaam is almal hier,
dan lees net 'n paar items

1819
01:20:05,570 --> 01:20:08,560
As my liggaam lengte is
gemiddeld 256 kilogrepe elk,

1820
01:20:08,560 --> 01:20:10,991
die wiskunde kry redelik lelik.

1821
01:20:10,991 --> 01:20:12,490
So sê Ek wil Dawid se posbus te lees.

1822
01:20:12,490 --> 01:20:14,520
David se posbus het 50 items.

1823
01:20:14,520 --> 01:20:17,880
Die gemiddelde grootte en is 256 kilogrepe.

1824
01:20:17,880 --> 01:20:21,730
Hier is my bekering verhouding
vir RCU se vier kilogrepe.

1825
01:20:21,730 --> 01:20:24,450
>> OK, laat ons gaan met
uiteindelik konsekwent lees.

1826
01:20:24,450 --> 01:20:28,640
Ek is nog steeds eet 1600 RCU se
net na Dawid se posbus te lees.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
OK, nou, laat ons dink
oor hoe die jeug werk.

1829
01:20:31,980 --> 01:20:35,340
As ek in 'n e-pos app en
Ek is op soek na my inbox,

1830
01:20:35,340 --> 01:20:39,680
en ek kyk na die liggaam van elke boodskap,
Nee, ek is op soek na die opsommings.

1831
01:20:39,680 --> 01:20:41,850
Ek is op soek na net die headers.

1832
01:20:41,850 --> 01:20:46,310
So laat bou 'n tafel struktuur
wat lyk meer soos dit.

1833
01:20:46,310 --> 01:20:49,470
>> So hier is die inligting
dat my workflow nodig het.

1834
01:20:49,470 --> 01:20:50,890
Dit is in my inbox GSI.

1835
01:20:50,890 --> 01:20:53,800
Dit is die datum, die sender,
die onderwerp, en dan

1836
01:20:53,800 --> 01:20:56,790
die boodskap ID, wat dui
terug na die tafel boodskappe

1837
01:20:56,790 --> 01:20:57,850
waar ek die liggaam kan kry.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Wel, hierdie sou wees rekord ID.

1840
01:21:04,420 --> 01:21:09,850
Hulle sou wys terug na die
item-ID's op die Dynamo DB tafel.

1841
01:21:09,850 --> 01:21:12,220
Elke indeks altyd creates--
het altyd die item

1842
01:21:12,220 --> 01:21:15,750
ID as deel of-- dat
kom met die indeks.

1843
01:21:15,750 --> 01:21:17,414
>> Alles reg.

1844
01:21:17,414 --> 01:21:19,080
GEHOOR: Dit vertel dit waar dit gestoor word?

1845
01:21:19,080 --> 01:21:21,420
Rick Houlihan: Ja, dit vertel
exactly-- dit is presies wat dit doen.

1846
01:21:21,420 --> 01:21:22,644
Dit sê hier is my re-rekord.

1847
01:21:22,644 --> 01:21:24,310
En dit sal wys dit terug na my re-rekord.

1848
01:21:24,310 --> 01:21:26,460
Presies.

1849
01:21:26,460 --> 01:21:29,490
OK, so nou is my inbox is
eintlik baie kleiner.

1850
01:21:29,490 --> 01:21:32,210
En dit eintlik ondersteun
die workflow van 'n e-pos artikels.

1851
01:21:32,210 --> 01:21:34,230
So my inbox, ek klik.

1852
01:21:34,230 --> 01:21:38,160
Ek gaan saam en ek op die boodskap,
Dis toe dat ek nodig het om te gaan kry die liggaam,

1853
01:21:38,160 --> 01:21:40,180
want ek gaan om
gaan na 'n ander siening.

1854
01:21:40,180 --> 01:21:43,870
So as jy dink oor MVC tipe
raamwerk, model oog kontroleerder.

1855
01:21:43,870 --> 01:21:46,120
>> Die model bevat die
data wat in die behoeftes oog

1856
01:21:46,120 --> 01:21:48,130
en die beheerder interaksie het.

1857
01:21:48,130 --> 01:21:51,670
Toe ek die raam verander, wanneer
Ek verander die perspektief,

1858
01:21:51,670 --> 01:21:55,080
dit is OK om terug te gaan na die
bediener en repopulate die model,

1859
01:21:55,080 --> 01:21:56,860
want dit is wat die gebruiker verwag.

1860
01:21:56,860 --> 01:22:00,530
Wanneer hulle verander sienings, dit is wanneer
ons terug na die databasis kan gaan.

1861
01:22:00,530 --> 01:22:02,480
So e-pos, klik.

1862
01:22:02,480 --> 01:22:03,710
Ek is op soek na die liggaam.

1863
01:22:03,710 --> 01:22:04,330
Ronde trip.

1864
01:22:04,330 --> 01:22:05,680
Gaan kry die liggaam.

1865
01:22:05,680 --> 01:22:06,950
>> Ek lees 'n baie minder data.

1866
01:22:06,950 --> 01:22:09,960
Ek is maar net die lees van die liggame wat
David moet toe hy hulle nodig het.

1867
01:22:09,960 --> 01:22:14,230
En ek is nie brand in 1600
RCU se net sy posbus te wys.

1868
01:22:14,230 --> 01:22:17,670
So nou that-- dit is die manier
dat LSI of GSI-- Ek is jammer,

1869
01:22:17,670 --> 01:22:19,900
GSI, sou uitwerk.

1870
01:22:19,900 --> 01:22:25,450
Ons het ons hash op die ontvanger.

1871
01:22:25,450 --> 01:22:27,030
Ons het die reeks sleutel op die datum.

1872
01:22:27,030 --> 01:22:31,380
En ons het die geprojekteerde eienskappe het
dat ons net nodig het om die siening te ondersteun.

1873
01:22:31,380 --> 01:22:34,300
>> Ons draai dat vir die outbox.

1874
01:22:34,300 --> 01:22:35,770
Hash op sender.

1875
01:22:35,770 --> 01:22:39,612
En in wese, ons het
die baie mooi, skoon uitsig.

1876
01:22:39,612 --> 01:22:41,570
En dit is wat ons basically--
het hierdie mooi boodskappe

1877
01:22:41,570 --> 01:22:45,870
tabel word mooi, want is versprei
dit is hash slegs hashed boodskap ID.

1878
01:22:45,870 --> 01:22:51,750
En ons het twee indekse wat
roteer af van daardie tafel.

1879
01:22:51,750 --> 01:22:57,411
Alle reg, sodat idee hier is nie
hou die groot data en dié klein data

1880
01:22:57,411 --> 01:22:57,910
saam.

1881
01:22:57,910 --> 01:23:00,700
Partisie vertikaal,
afskort die tafels.

1882
01:23:00,700 --> 01:23:03,150
Moenie data nie lees jy nie hoef te.

1883
01:23:03,150 --> 01:23:04,850
Alle reg, speel.

1884
01:23:04,850 --> 01:23:06,990
Ons almal wil speletjies.

1885
01:23:06,990 --> 01:23:10,902
Ten minste het ek graag speletjies dan.

1886
01:23:10,902 --> 01:23:12,735
So 'n paar van die dinge
dat ons hanteer wanneer

1887
01:23:12,735 --> 01:23:14,193
ons dink oor die spel, reg?

1888
01:23:14,193 --> 01:23:16,999
Gaming hierdie dae, veral mobiele
speel, is al oor die denke.

1889
01:23:16,999 --> 01:23:19,540
En ek gaan om hier 'n draai
bietjie weg van DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Ek gaan in te bring
sommige van die bespreking

1891
01:23:21,373 --> 01:23:24,240
rondom 'n paar van die
ander AWS tegnologie.

1892
01:23:24,240 --> 01:23:28,930
>> Maar die idee oor die spel is om te dink
oor in terme van API's, APIs wat,

1893
01:23:28,930 --> 01:23:31,730
algemeen, HTTP en into.

1894
01:23:31,730 --> 01:23:34,550
Dit is hoe mobiele speletjies soort
interaksie met hulle rug eindig.

1895
01:23:34,550 --> 01:23:35,850
Hulle doen into plaas.

1896
01:23:35,850 --> 01:23:40,660
Hulle kry data, en dit is al,
algemeen in mooi into APIs.

1897
01:23:40,660 --> 01:23:44,950
>> Dinge soos te kry vriende, kry
die leader, ruil data,

1898
01:23:44,950 --> 01:23:47,699
gebruiker-gegenereerde inhoud,
stoot terug tot die stelsel,

1899
01:23:47,699 --> 01:23:49,740
dit is soort dinge
dat ons gaan om dit te doen.

1900
01:23:49,740 --> 01:23:52,542
Binary bate data, hierdie data
dalk nie sit in die databasis.

1901
01:23:52,542 --> 01:23:54,250
Dit kan in 'n sit
voorwerp winkel, reg?

1902
01:23:54,250 --> 01:23:56,541
Maar die databasis gaan
beland vertel die stelsel,

1903
01:23:56,541 --> 01:23:59,140
vertel die aansoek
waar om te gaan kry.

1904
01:23:59,140 --> 01:24:03,550
En onvermydelik, multiplayer
bedieners, agterkant infrastruktuur,

1905
01:24:03,550 --> 01:24:06,180
en is ontwerp vir 'n hoë
beskikbaarheid en scalability.

1906
01:24:06,180 --> 01:24:09,400
So dit is die dinge wat ons almal wil hê
in die spel infrastruktuur vandag.

1907
01:24:09,400 --> 01:24:12,160
>> So laat ons neem 'n blik op
wat dit lyk.

1908
01:24:12,160 --> 01:24:16,070
Het jy 'n kern agterkant,
baie eenvoudig.

1909
01:24:16,070 --> 01:24:19,880
Ons het 'n stelsel het hier met
verskeie beskikbaarheid sones.

1910
01:24:19,880 --> 01:24:23,780
Ons het gepraat oor AZS as being-- dink
van hulle as afsonderlike data sentrums.

1911
01:24:23,780 --> 01:24:26,040
Meer as een data sentrum
per AZ, maar dit is OK,

1912
01:24:26,040 --> 01:24:28,831
dink net aan hulle as afsonderlike data
sentrums wat geografies

1913
01:24:28,831 --> 01:24:30,090
en skuld geïsoleer.

1914
01:24:30,090 --> 01:24:32,172
>> Ons gaan 'n het
paar EC2 gevalle.

1915
01:24:32,172 --> 01:24:33,880
Ons gaan hê
sommige agterkant bediener.

1916
01:24:33,880 --> 01:24:35,800
Miskien as jy 'n nalatenskap
argitektuur, ons is

1917
01:24:35,800 --> 01:24:38,920
die gebruik van wat ons RDS noem,
relasionele databasis dienste.

1918
01:24:38,920 --> 01:24:42,040
Kan wees MSSQL, MySQL,
of iets soos dit.

1919
01:24:42,040 --> 01:24:47,080
Dit is 'n baie aansoeke manier
is ontwerp vandag.

1920
01:24:47,080 --> 01:24:49,594
>> Wel, ons kan wil om te gaan met
Dit is wanneer ons die skaal uit.

1921
01:24:49,594 --> 01:24:51,510
Ons sal voortgaan en sit
die S3 emmer daar.

1922
01:24:51,510 --> 01:24:54,200
En dat S3 emmer, in plaas daarvan om
up die voorwerpe van ons servers--

1923
01:24:54,200 --> 01:24:55,220
ons kon doen.

1924
01:24:55,220 --> 01:24:57,210
Jy het al jou binêre
voorwerpe op jou bedieners

1925
01:24:57,210 --> 01:24:59,751
en jy kan die bediener gebruik
gevalle dat die data op te dien.

1926
01:24:59,751 --> 01:25:01,860
Maar dit is redelik duur.

1927
01:25:01,860 --> 01:25:05,107
>> Beter manier om dit te doen is gaan voort en
sit die voorwerpe in 'n S3 emmer.

1928
01:25:05,107 --> 01:25:06,315
S3 is 'n voorwerp repositories.

1929
01:25:06,315 --> 01:25:10,860
Dit is spesifiek gebou vir
dien tot hierdie tipe van dinge.

1930
01:25:10,860 --> 01:25:13,690
En laat die kliënte versoek
direk van die voorwerp emmers,

1931
01:25:13,690 --> 01:25:15,390
laai die bedieners.

1932
01:25:15,390 --> 01:25:17,020
So ons begin hier uit te skaal.

1933
01:25:17,020 --> 01:25:19,140
>> Nou het ons gebruikers oor die hele wêreld.

1934
01:25:19,140 --> 01:25:19,730
Ek het die gebruikers.

1935
01:25:19,730 --> 01:25:23,380
Ek het nodig om inhoud plaaslik het
geleë naby die gebruikers, reg?

1936
01:25:23,380 --> 01:25:26,200
Ek het 'n S3 emmer geskep
as my bron repository.

1937
01:25:26,200 --> 01:25:29,370
En ek sal voor die wat saam met
die CloudFront verspreiding.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront is 'n CD en 'n
inhoud aflewering netwerk.

1939
01:25:31,720 --> 01:25:35,750
Eintlik is dit die data wat jy spesifiseer neem
en caches dit alles oor die internet

1940
01:25:35,750 --> 01:25:39,230
sodat gebruikers oral kan hê
'n baie vinnige reaksie wanneer

1941
01:25:39,230 --> 01:25:40,960
hulle versoek die voorwerpe.

1942
01:25:40,960 --> 01:25:41,960
>> Sodat jy 'n idee kry.

1943
01:25:41,960 --> 01:25:48,230
Jy soort van gebruik te maak van al die
aspekte van AWS hier te kry dit gedoen.

1944
01:25:48,230 --> 01:25:50,790
En uiteindelik, ons gooi
in 'n motor skalering groep.

1945
01:25:50,790 --> 01:25:52,737
So ons AC2 gevalle
van ons game servers,

1946
01:25:52,737 --> 01:25:54,820
as hulle begin om te kry besiger
en besiger en besiger,

1947
01:25:54,820 --> 01:25:57,236
hulle sal net nog 'n draai
Byvoorbeeld, spin 'n ander geval,

1948
01:25:57,236 --> 01:25:58,210
spin n ander geval.

1949
01:25:58,210 --> 01:26:02,090
So het die tegnologie AWS het, is dit
laat jou die parameters spesifiseer

1950
01:26:02,090 --> 01:26:04,650
rondom jou bedieners sal groei.

1951
01:26:04,650 --> 01:26:08,110
Sodat jy kan n aantal bedieners
daar op enige gegewe tyd.

1952
01:26:08,110 --> 01:26:11,870
En as jou las gaan weg, sal hulle
krimp, sal die aantal krimp.

1953
01:26:11,870 --> 01:26:15,250
En as die las terug kom,
dit sal groei terug uit elastiche.

1954
01:26:15,250 --> 01:26:17,050
>> So dit lyk groot.

1955
01:26:17,050 --> 01:26:19,800
Ons het 'n baie EC2 gevalle.

1956
01:26:19,800 --> 01:26:21,671
Ons kan kas sit in
voorkant van die databasisse

1957
01:26:21,671 --> 01:26:23,045
Probeer en versnel die databasisse.

1958
01:26:23,045 --> 01:26:25,030
Die volgende druk punt
tipies mense sien

1959
01:26:25,030 --> 01:26:28,850
is hulle skaal 'n spel met 'n
relasionele databasis stelsel.

1960
01:26:28,850 --> 01:26:30,790
Jeez, die databasis
prestasie is verskriklik.

1961
01:26:30,790 --> 01:26:31,932
Hoe weet ons dat verbeter?

1962
01:26:31,932 --> 01:26:33,640
Kom ons probeer om
kas in die voorkant van dit.

1963
01:26:33,640 --> 01:26:36,780
>> Wel, kas nie werk nie
so groot in die speletjies, reg?

1964
01:26:36,780 --> 01:26:39,330
Vir speletjies, skryf is pynlik.

1965
01:26:39,330 --> 01:26:40,930
Speletjies is baie skryf swaar.

1966
01:26:40,930 --> 01:26:43,610
Kas nie werk nie wanneer jy
skryf swaar omdat jy altyd

1967
01:26:43,610 --> 01:26:44,610
het in die kas te werk.

1968
01:26:44,610 --> 01:26:47,780
Jy werk die kas, dit is
irrelevant word kas.

1969
01:26:47,780 --> 01:26:49,780
Dit is eintlik net ekstra werk.

1970
01:26:49,780 --> 01:26:51,970
>> So, waar ons hier gaan?

1971
01:26:51,970 --> 01:26:54,400
Jy het 'n groot knelpunt het
af daar in die databasis.

1972
01:26:54,400 --> 01:26:57,661
En die plek om te gaan
natuurlik is skeiding.

1973
01:26:57,661 --> 01:26:59,410
Skeiding is nie
maklik om te doen wanneer jy

1974
01:26:59,410 --> 01:27:01,900
hantering van relasionele databasisse.

1975
01:27:01,900 --> 01:27:05,080
Met relasionele databasisse, is jy
verantwoordelik vir die bestuur, doeltreffend,

1976
01:27:05,080 --> 01:27:06,210
die sleutel ruimte.

1977
01:27:06,210 --> 01:27:10,527
Jy sê gebruikers tussen A en M
gaan hier tussen N en Z daar gaan.

1978
01:27:10,527 --> 01:27:12,360
En jy skakel
oor die aansoek.

1979
01:27:12,360 --> 01:27:15,000
So jy met
hierdie partisie data bron.

1980
01:27:15,000 --> 01:27:18,670
Jy het transaksionele beperkings
wat nie mure strek.

1981
01:27:18,670 --> 01:27:20,560
Jy het alle vorme van het
messiness dat jy

1982
01:27:20,560 --> 01:27:23,040
hantering af daar probeer
om te gaan met skalering uit

1983
01:27:23,040 --> 01:27:25,120
en die bou van 'n groter infrastruktuur.

1984
01:27:25,120 --> 01:27:27,284
Dis net nie lekker.

1985
01:27:27,284 --> 01:27:30,930
>> GEHOOR: So jy sê dat
toenemende bron punte versnel

1986
01:27:30,930 --> 01:27:31,430
die proses?

1987
01:27:31,430 --> 01:27:32,513
Rick Houlihan: Toenemende?

1988
01:27:32,513 --> 01:27:33,520
GEHOOR: Bron punte.

1989
01:27:33,520 --> 01:27:34,410
Rick Houlihan: Bron punte?

1990
01:27:34,410 --> 01:27:37,500
GEHOOR: Van die inligting,
waar die inligting vandaan kom?

1991
01:27:37,500 --> 01:27:38,250
Rick Houlihan: No.

1992
01:27:38,250 --> 01:27:41,820
Wat ek sê, is die verhoging van die
aantal partisies in die data store

1993
01:27:41,820 --> 01:27:44,060
verbeter deurvoer.

1994
01:27:44,060 --> 01:27:48,300
So wat hier gebeur is gebruikers
kom in die EC2 byvoorbeeld hier,

1995
01:27:48,300 --> 01:27:50,780
Wel, as ek 'n gebruiker
Dit is 'n M, ek sal hier gaan.

1996
01:27:50,780 --> 01:27:53,560
Van N na p, sal ek hier gaan.

1997
01:27:53,560 --> 01:27:55,060
Vanaf P tot Z, sal ek hier gaan.

1998
01:27:55,060 --> 01:27:57,120
>> GEHOOR: OK, diegene So dit is
al gestoor in verskillende nodes?

1999
01:27:57,120 --> 01:27:57,911
>> Rick Houlihan: Ja.

2000
01:27:57,911 --> 01:28:00,210
Dink aan hierdie as
verskillende silo's van data.

2001
01:28:00,210 --> 01:28:01,660
So jy hoef te doen.

2002
01:28:01,660 --> 01:28:02,910
As jy probeer om te doen
hierdie, as jy probeer

2003
01:28:02,910 --> 01:28:05,730
skaal op 'n relasionele platform,
dit is wat jy doen.

2004
01:28:05,730 --> 01:28:08,100
Jy neem data en
jy sny dit af.

2005
01:28:08,100 --> 01:28:10,975
En jy skeiding dit oor
verskeie gevalle van die databasis.

2006
01:28:10,975 --> 01:28:13,580
En jy bestuur alles wat
by die toepassing vlak.

2007
01:28:13,580 --> 01:28:14,729
Dit is geen pret.

2008
01:28:14,729 --> 01:28:15,770
So, wat wil ons gaan?

2009
01:28:15,770 --> 01:28:20,240
Ons wil gaan DynamoDB, ten volle beheer,
NoSQL data stoor, voorsiening deurvoer.

2010
01:28:20,240 --> 01:28:22,680
Ons gebruik sekondêre indekse.

2011
01:28:22,680 --> 01:28:26,154
Dit is basies HTTP API en
sluit dokument ondersteuning.

2012
01:28:26,154 --> 01:28:28,570
Sodat jy nie hoef te bekommer
oor enige van daardie skeiding.

2013
01:28:28,570 --> 01:28:30,740
Ons doen dit alles vir jou.

2014
01:28:30,740 --> 01:28:33,260
So nou, in plaas daarvan, jy
net skryf om die tafel.

2015
01:28:33,260 --> 01:28:36,490
As die tafel moet verdeel,
wat gebeur agter die skerms.

2016
01:28:36,490 --> 01:28:40,642
Jy heeltemal geïsoleer
uit dat 'n ontwikkelaar.

2017
01:28:40,642 --> 01:28:42,350
So laat ons praat oor
sommige van die gebruik gevalle

2018
01:28:42,350 --> 01:28:47,564
dat ons loop in in die spel, 'n gemeenskaplike
spel scenario's, leader.

2019
01:28:47,564 --> 01:28:49,980
So jy het die gebruikers kom,
die BoardNames dat hulle

2020
01:28:49,980 --> 01:28:52,930
op die tellings vir hierdie gebruiker.

2021
01:28:52,930 --> 01:28:57,700
Ons kan hashing op die UserID,
en dan het ons reeks op die spel.

2022
01:28:57,700 --> 01:28:59,960
Sodat elke gebruiker wil sien
al die spel wat hy gespeel

2023
01:28:59,960 --> 01:29:01,770
en al sy hoogste telling
oor al die spel.

2024
01:29:01,770 --> 01:29:04,000
So dit is sy persoonlike leader.

2025
01:29:04,000 --> 01:29:10,010
>> Nou wil ek om in te gaan en ek wil get--
so ek kry hierdie persoonlike puntelys.

2026
01:29:10,010 --> 01:29:12,827
Wat ek wil doen, is gaan kry
die hoogste telling in alle gebruikers.

2027
01:29:12,827 --> 01:29:13,660
So hoe kan ek dit doen?

2028
01:29:13,660 --> 01:29:18,070
Toe my rekord hashed op
die UserID, het gewissel van die spel,

2029
01:29:18,070 --> 01:29:20,740
Wel, ek is van plan om voort te gaan
en te herstruktureer, skep 'n GSI,

2030
01:29:20,740 --> 01:29:22,370
en ek gaan die data te herstruktureer.

2031
01:29:22,370 --> 01:29:27,310
>> Nou gaan ek oor die hash
BoardName, wat is die spel.

2032
01:29:27,310 --> 01:29:29,800
En ek gaan wissel op die top telling.

2033
01:29:29,800 --> 01:29:31,540
En nou het ek verskillende emmers geskep.

2034
01:29:31,540 --> 01:29:34,790
Ek gebruik dieselfde tafel,
dieselfde item data.

2035
01:29:34,790 --> 01:29:39,870
Maar ek skep 'n emmer wat gee
vir my 'n samevoeging van top telling deur spel.

2036
01:29:39,870 --> 01:29:43,180
>> En ek kan daardie tafel navraag
om daardie inligting te kry.

2037
01:29:43,180 --> 01:29:50,890
So ek gestel dat navraag patroon tot
word ondersteun deur 'n sekondêre indeks.

2038
01:29:50,890 --> 01:29:54,556
Nou kan hulle gesorteer word deur BoardName
en gesorteer volgens topscore, afhangende van.

2039
01:29:54,556 --> 01:29:57,180
Sodat jy kan sien, dit is tipes
van gebruik gevalle jy in die spel.

2040
01:29:57,180 --> 01:30:02,190
Nog 'n goeie gebruik geval kry ons in die spel
is toekennings en wie het die toekennings.

2041
01:30:02,190 --> 01:30:05,340
En dit is 'n groot gebruik geval
waar ons noem yl indekse.

2042
01:30:05,340 --> 01:30:07,340
Yl indekse is die
vermoë om te genereer

2043
01:30:07,340 --> 01:30:10,850
'n indeks wat nie noodwendig beteken
bevat elke enkele item op die tafel.

2044
01:30:10,850 --> 01:30:11,470
En hoekom nie?

2045
01:30:11,470 --> 01:30:14,540
Omdat die eienskap wat die wese
geïndekseer bestaan ​​nie op elke item.

2046
01:30:14,540 --> 01:30:16,460
>> So in hierdie spesifieke
gebruik geval, ek sê,

2047
01:30:16,460 --> 01:30:19,240
jy weet wat, ek gaan
skep 'n kenmerk genaamd Award.

2048
01:30:19,240 --> 01:30:22,970
En ek gaan elke gebruiker te gee
wat 'n toekenning wat toe te skryf.

2049
01:30:22,970 --> 01:30:25,950
Gebruikers wat nie toekennings is
gaan nie daardie kenmerk het.

2050
01:30:25,950 --> 01:30:27,800
So wanneer ek die skep van die
indeks, die enigste gebruikers

2051
01:30:27,800 --> 01:30:28,960
wat gaan om te wys
in die indeks is

2052
01:30:28,960 --> 01:30:31,050
die mense wat eintlik toekennings gewen het.

2053
01:30:31,050 --> 01:30:34,440
So dit is 'n goeie manier om in staat wees om
om gefiltreer te skep wat indekse

2054
01:30:34,440 --> 01:30:40,580
is baie, baie selektiewe wat nie
het na die indeks die hele tafel.

2055
01:30:40,580 --> 01:30:43,050
>> So ons laag op tyd om hier.

2056
01:30:43,050 --> 01:30:49,190
Ek gaan om voort te gaan en oor te slaan
uit en slaan hierdie scenario.

2057
01:30:49,190 --> 01:30:52,625
Praat 'n bietjie about--

2058
01:30:52,625 --> 01:30:54,460
>> GEHOOR: Kan ek 'n vinnige vraag vra?

2059
01:30:54,460 --> 01:30:56,722
Een daarvan is skryf swaar?

2060
01:30:56,722 --> 01:30:57,680
Rick Houlihan: Wat is?

2061
01:30:57,680 --> 01:30:58,596
GEHOOR: Skryf swaar.

2062
01:30:58,596 --> 01:31:01,270
Rick Houlihan: Skryf swaar.

2063
01:31:01,270 --> 01:31:03,460
Laat ek sien.

2064
01:31:03,460 --> 01:31:06,220
>> GEHOOR: Of is dit nie
iets wat jy kan net

2065
01:31:06,220 --> 01:31:08,809
stem in 'n kwessie van sekondes?

2066
01:31:08,809 --> 01:31:10,850
Rick Houlihan: Ons gaan
deur die stem scenario.

2067
01:31:10,850 --> 01:31:11,670
Dit is nie so sleg nie.

2068
01:31:11,670 --> 01:31:14,580
Het jy ouens het 'n paar minute?

2069
01:31:14,580 --> 01:31:15,860
OK.

2070
01:31:15,860 --> 01:31:17,890
>> So sal ons praat oor stem.

2071
01:31:17,890 --> 01:31:20,250
So reële tyd te stem, het ons
vereistes om te stem.

2072
01:31:20,250 --> 01:31:25,250
Vereistes is dat ons toelaat dat
elke persoon om net een keer stem.

2073
01:31:25,250 --> 01:31:28,060
Ons wil niemand in staat wees om
om hul stem te verander.

2074
01:31:28,060 --> 01:31:31,045
Ons wil real-time samevoeging
en analytics vir demografie

2075
01:31:31,045 --> 01:31:34,210
dat ons gaan om te wees
toon aan gebruikers op die werf.

2076
01:31:34,210 --> 01:31:35,200
>> Dink aan hierdie scenario.

2077
01:31:35,200 --> 01:31:37,550
Ons werk baie van die werklikheid
TV-programme waar hulle

2078
01:31:37,550 --> 01:31:38,960
doen hierdie presiese tipe dinge.

2079
01:31:38,960 --> 01:31:41,584
So jy kan dink van die scenario,
ons het miljoene

2080
01:31:41,584 --> 01:31:43,959
tienermeisies daar
met hul selfone

2081
01:31:43,959 --> 01:31:46,250
en stem, en stem, en
stem vir wie hulle is

2082
01:31:46,250 --> 01:31:48,610
vind die mees gewild te wees.

2083
01:31:48,610 --> 01:31:50,830
So dit is 'n paar van die
vereistes wat ons loop uit.

2084
01:31:50,830 --> 01:31:52,990
>> En so het die eerste te neem
in die oplossing van die probleem

2085
01:31:52,990 --> 01:31:55,090
sou wees om 'n te bou
baie eenvoudige toepassing.

2086
01:31:55,090 --> 01:31:56,490
So ek het hierdie inligting.

2087
01:31:56,490 --> 01:31:57,950
Ek het 'n paar kiesers daar buite.

2088
01:31:57,950 --> 01:31:59,980
Hulle kom in, hulle druk op die stem app.

2089
01:31:59,980 --> 01:32:03,440
Ek het 'n paar rou stemme tafel het
Ek sal net stort die stemme in.

2090
01:32:03,440 --> 01:32:05,780
Ek sal 'n paar totaal het
stemme tabel

2091
01:32:05,780 --> 01:32:09,490
sal my analytics en demografie te doen,
en ons sal dit alles in daar te vestig.

2092
01:32:09,490 --> 01:32:11,420
>> En dit is groot.

2093
01:32:11,420 --> 01:32:12,332
Die lewe is goed.

2094
01:32:12,332 --> 01:32:15,040
Die lewe se goeie totdat ons uitvind dat
daar is altyd net een of twee

2095
01:32:15,040 --> 01:32:16,879
mense wat gewild is in 'n verkiesing.

2096
01:32:16,879 --> 01:32:19,420
Daar is net een of twee dinge
dat mense regtig omgee.

2097
01:32:19,420 --> 01:32:22,340
En as jy op stem
skaal, almal van 'n skielike Ek is

2098
01:32:22,340 --> 01:32:26,360
gaan word gehamer die hel uit
twee kandidate, een of twee kandidate.

2099
01:32:26,360 --> 01:32:29,390
'N baie beperkte aantal items
mense vind gewild te wees.

2100
01:32:29,390 --> 01:32:31,710
>> Dit is nie 'n goeie ontwerp patroon.

2101
01:32:31,710 --> 01:32:33,549
Dit is eintlik 'n
baie slegte ontwerp patroon

2102
01:32:33,549 --> 01:32:36,340
want dit skep presies wat ons
gepraat oor wat warm sleutels was.

2103
01:32:36,340 --> 01:32:38,960
Warm sleutels is iets wat ons nie hou nie.

2104
01:32:38,960 --> 01:32:40,470
>> So hoe doen ons dit regmaak?

2105
01:32:40,470 --> 01:32:47,640
En regtig, die manier om dit op te los, is
deur die neem van die kandidaat emmers

2106
01:32:47,640 --> 01:32:51,490
en vir elke kandidaat wat ons het,
ons gaan 'n ewekansige waarde heg,

2107
01:32:51,490 --> 01:32:54,192
iets wat ons weet, ewekansige
waarde tussen een en 100,

2108
01:32:54,192 --> 01:32:56,620
tussen 100 en 1000,
of tussen een en 1000,

2109
01:32:56,620 --> 01:32:59,940
egter baie ewekansige waardes wat jy wil
voeg op die einde van daardie kandidaat.

2110
01:32:59,940 --> 01:33:01,330
>> En wat het ek regtig dan gedoen?

2111
01:33:01,330 --> 01:33:05,830
As ek met behulp van die kandidaat ID as
die emmer om totaal stemme,

2112
01:33:05,830 --> 01:33:08,780
as ek het bygevoeg 'n ewekansige
nommer die einde van daardie,

2113
01:33:08,780 --> 01:33:12,000
Ek het nou geskep 10 emmers, 'n
honderd emmers, 'n duisend emmers

2114
01:33:12,000 --> 01:33:14,160
dat ek saamgevoeg stemme oor.

2115
01:33:14,160 --> 01:33:18,030
>> So ek het miljoene en miljoene,
en miljoene rekords kom in

2116
01:33:18,030 --> 01:33:22,050
vir hierdie kandidate, ek is nou versprei
die stemme oor Kandidaat A_1

2117
01:33:22,050 --> 01:33:24,630
deur Kandidaat A_100, want
elke keer 'n stem kom in,

2118
01:33:24,630 --> 01:33:26,530
Ek genereer 'n ewekansige
waarde tussen een en 100.

2119
01:33:26,530 --> 01:33:29,446
Ek koppel dit op die einde van die
kandidaat daardie persoon se stem vir.

2120
01:33:29,446 --> 01:33:31,120
Ek is die storting dit in die emmer.

2121
01:33:31,120 --> 01:33:33,910
>> Nou op die agterkant, ek weet
dat ek 'n honderd emmers.

2122
01:33:33,910 --> 01:33:36,350
So wanneer ek wil om voort te gaan
en die geheel het die stemme,

2123
01:33:36,350 --> 01:33:38,244
Ek lees van al die emmers.

2124
01:33:38,244 --> 01:33:39,160
So ek gaan voort en voeg.

2125
01:33:39,160 --> 01:33:42,410
En dan het ek nie die strooi versamel
waar ek gaan uit en sê hey,

2126
01:33:42,410 --> 01:33:45,399
jy weet wat, hierdie kandidaat sleutel
ruimtes is oor 'n honderd emmers.

2127
01:33:45,399 --> 01:33:47,940
Ek gaan om te versamel al die
stemme van daardie honderd emmers.

2128
01:33:47,940 --> 01:33:49,981
Ek gaan om te versamel
hulle en ek gaan om te sê,

2129
01:33:49,981 --> 01:33:53,830
Kandidaat A het nou
totale aantal stemme van x.

2130
01:33:53,830 --> 01:33:55,690
>> Nou beide die skryf
navraag en die lees navraag

2131
01:33:55,690 --> 01:33:58,160
is mooi versprei
omdat ek oor skryf

2132
01:33:58,160 --> 01:34:00,320
en ek lees oor honderde sleutels.

2133
01:34:00,320 --> 01:34:03,500
Ek skryf nie en
lees oor een van die belangrikste nou.

2134
01:34:03,500 --> 01:34:04,950
So dit is 'n groot patroon.

2135
01:34:04,950 --> 01:34:08,090
>> Dit is eintlik waarskynlik een
van die belangrikste ontwerp

2136
01:34:08,090 --> 01:34:10,420
patrone vir skaal in NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Jy sal hierdie soort sien
ontwerp patroon in elke smaak.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, is dit nie
saak, ons almal het om dit te doen.

2139
01:34:19,100 --> 01:34:21,840
Want as jy te doen
met dié groot swerms,

2140
01:34:21,840 --> 01:34:26,650
jy het om uit te vind 'n manier om
versprei hulle uit oor emmers.

2141
01:34:26,650 --> 01:34:29,512
So, dit is die manier waarop jy dit doen.

2142
01:34:29,512 --> 01:34:31,220
Alle reg, so what
jy nou doen

2143
01:34:31,220 --> 01:34:35,252
is jy die handel af lees
koste vir skryf scalability.

2144
01:34:35,252 --> 01:34:37,085
Die koste van my lees is
'n bietjie meer kompleks

2145
01:34:37,085 --> 01:34:40,220
en ek het om te gaan lees van 'n
honderd emmers in plaas van een.

2146
01:34:40,220 --> 01:34:41,310
Maar ek is in staat om te skryf.

2147
01:34:41,310 --> 01:34:44,860
En my deurset, my skryf
deurset is ongelooflik.

2148
01:34:44,860 --> 01:34:49,450
So dit is gewoonlik 'n waardevolle
tegniek vir skalering DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
of enige NoSQL databasis vir die saak.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Sodat ons uitgepluis het hoe om dit te skaal.

2152
01:34:55,240 --> 01:34:56,930
En ons het gedink hoe om
skakel ons warm sleutels.

2153
01:34:56,930 --> 01:34:57,820
En dit is fantasties.

2154
01:34:57,820 --> 01:34:58,960
En ons het hierdie mooi stelsel.

2155
01:34:58,960 --> 01:35:02,043
En dit is aan ons gegee baie korrekte stem
want ons het rekord stem de-bedrieg.

2156
01:35:02,043 --> 01:35:03,130
Dit is gebou in DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Ons het gepraat oor voorwaardelike regte.

2158
01:35:05,380 --> 01:35:08,170
>> Wanneer 'n kieser kom in, sit
'n insetsel op die tafel,

2159
01:35:08,170 --> 01:35:11,220
hulle steek met hul kieser ID,
as hulle probeer om 'n ander stemming te plaas,

2160
01:35:11,220 --> 01:35:13,320
Ek doen 'n voorwaardelike skryf.

2161
01:35:13,320 --> 01:35:16,960
Sê net skryf dit
As dit nie bestaan ​​nie.

2162
01:35:16,960 --> 01:35:19,270
So gou as ek sien dat
daardie stem se druk op die tafel,

2163
01:35:19,270 --> 01:35:20,460
niemand anders gaan wees
in staat wees om hul stem in plaas.

2164
01:35:20,460 --> 01:35:21,634
En dit is fantasties.

2165
01:35:21,634 --> 01:35:23,550
En ons is die verhoog
ons kandidaat tellers.

2166
01:35:23,550 --> 01:35:25,466
En ons van ons doen
demografie en alles wat.

2167
01:35:25,466 --> 01:35:29,110
Maar wat gebeur as my
aansoek omval?

2168
01:35:29,110 --> 01:35:31,350
Nou het al van 'n skielike stemme
kom in, en ek

2169
01:35:31,350 --> 01:35:34,840
weet nie of hulle kry verwerk
in my analytics en demografie

2170
01:35:34,840 --> 01:35:36,040
meer.

2171
01:35:36,040 --> 01:35:38,462
En toe die aansoek
kom terug, hoe

2172
01:35:38,462 --> 01:35:41,420
die hel moet ek weet wat stemme het
verwerk en waar begin ek?

2173
01:35:41,420 --> 01:35:44,530
>> So, dit is 'n werklike probleem wanneer jy
begin om te kyk na hierdie tipe van scenario.

2174
01:35:44,530 --> 01:35:45,571
En hoe los ons dit?

2175
01:35:45,571 --> 01:35:48,070
Ons los dit met wat ons
noem DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Strome is 'n tyd bestel en
verdeel verandering log elke toegang

2177
01:35:53,470 --> 01:35:55,700
na die tafel, elke skryf
toegang tot die tafel.

2178
01:35:55,700 --> 01:35:58,810
Enige data wat geskryf om die
tabel toon op die stroom.

2179
01:35:58,810 --> 01:36:01,815
>> Dit is basies 'n 24 uur ry.

2180
01:36:01,815 --> 01:36:03,690
Items getref die stroom,
hulle leef vir 24 uur.

2181
01:36:03,690 --> 01:36:05,990
Hulle kan verskeie kere gelees word.

2182
01:36:05,990 --> 01:36:09,400
Gewaarborg om gered te word
slegs een keer na die spruit

2183
01:36:09,400 --> 01:36:11,180
kon N aantal kere gelees word.

2184
01:36:11,180 --> 01:36:14,910
So egter baie prosesse wat jy wil
verteer wat data, kan jy dit verteer.

2185
01:36:14,910 --> 01:36:16,350
Dit sal elke update verskyn.

2186
01:36:16,350 --> 01:36:18,455
Elke skryf, sal net
verskyn een keer op die stroom.

2187
01:36:18,455 --> 01:36:20,621
Sodat jy nie hoef te bekommer
oor die verwerking van dit twee keer

2188
01:36:20,621 --> 01:36:22,500
van dieselfde proses.

2189
01:36:22,500 --> 01:36:25,350
>> Dit is streng beveel per item.

2190
01:36:25,350 --> 01:36:28,180
Wanneer ons tyd sê
bestel en verdeel,

2191
01:36:28,180 --> 01:36:30,680
jy sal sien per partisie op die stroom.

2192
01:36:30,680 --> 01:36:33,169
Jy sal items, updates sien in orde is.

2193
01:36:33,169 --> 01:36:35,210
Ons is nie die waarborg
op die stroom wat jy

2194
01:36:35,210 --> 01:36:40,240
gaan elke transaksie te kry
in die volgorde oor items.

2195
01:36:40,240 --> 01:36:42,440
>> So strome is idempotente.

2196
01:36:42,440 --> 01:36:44,037
Het ons almal weet wat idempotente beteken?

2197
01:36:44,037 --> 01:36:46,620
Idempotente beteken jy kan dit doen
oor en oor en oor weer.

2198
01:36:46,620 --> 01:36:48,200
Die gevolg gaan dieselfde wees.

2199
01:36:48,200 --> 01:36:49,991
>> Strome is idempotente,
maar hulle moet wees

2200
01:36:49,991 --> 01:36:54,860
gespeel vanaf die beginpunt,
waar jy kies om die einde,

2201
01:36:54,860 --> 01:36:57,950
of hulle sal nie lei
in dieselfde waardes.

2202
01:36:57,950 --> 01:36:59,727
>> Dieselfde ding met MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB het 'n konstruk
hulle noem die oplog.

2204
01:37:01,560 --> 01:37:04,140
Dit is presies dieselfde konstruk.

2205
01:37:04,140 --> 01:37:06,500
Baie NoSQL databasisse
hierdie konstruk.

2206
01:37:06,500 --> 01:37:08,790
Hulle gebruik dit om dinge te doen
soos replisering, wat

2207
01:37:08,790 --> 01:37:10,475
is presies wat ons doen met strome.

2208
01:37:10,475 --> 01:37:12,350
GEHOOR: Miskien is 'n
ketterse vraag, maar jy

2209
01:37:12,350 --> 01:37:13,975
praat oor apps doen teen 'n so meer.

2210
01:37:13,975 --> 01:37:16,089
Is gewaarborg om strome
nooit moontlik gaan af?

2211
01:37:16,089 --> 01:37:18,630
Rick Houlihan: Ja, strome
is gewaarborg om nooit gaan af.

2212
01:37:18,630 --> 01:37:21,040
Ons bestuur die infrastruktuur
agter. strome outomaties

2213
01:37:21,040 --> 01:37:22,498
ontplooi in hul motor skalering groep.

2214
01:37:22,498 --> 01:37:25,910
Ons gaan deur 'n bietjie
bietjie oor wat gebeur.

2215
01:37:25,910 --> 01:37:30,060
>> Ek moet sê nie hulle is nie
gewaarborg om nooit gaan af.

2216
01:37:30,060 --> 01:37:33,110
Die elemente is gewaarborg
om te verskyn in die stroom.

2217
01:37:33,110 --> 01:37:36,740
En die stroom sal toeganklik wees.

2218
01:37:36,740 --> 01:37:40,580
So, wat gaan af of kom terug
up, dit gebeur onder.

2219
01:37:40,580 --> 01:37:43,844
Dit covers-- dit is OK.

2220
01:37:43,844 --> 01:37:46,260
Alle reg, sodat jy verskillende kry
tipes siening van die skerm af.

2221
01:37:46,260 --> 01:37:51,040
Die tipes siening dat belangrik om 'n is
programmeerder tipies is, wat was dit?

2222
01:37:51,040 --> 01:37:52,370
Ek kry die ou siening.

2223
01:37:52,370 --> 01:37:55,630
Wanneer 'n update treffers die tafel, dit sal
stoot die ou oog op die stroom

2224
01:37:55,630 --> 01:38:02,070
so data kan argief, of verandering
beheer, identifikasie verandering, verandering

2225
01:38:02,070 --> 01:38:03,600
bestuur.

2226
01:38:03,600 --> 01:38:07,160
>> Die nuwe beeld, wat dit nou is ná
die werk, dit is 'n ander tipe van die oog

2227
01:38:07,160 --> 01:38:07,660
wat jy kan kry.

2228
01:38:07,660 --> 01:38:09,660
Jy kan kry beide die ou en nuwe beelde.

2229
01:38:09,660 --> 01:38:10,660
Miskien wil ek hulle albei.

2230
01:38:10,660 --> 01:38:11,790
Ek wil om te sien wat dit was nie.

2231
01:38:11,790 --> 01:38:13,290
Ek wil om te sien wat dit verander na.

2232
01:38:13,290 --> 01:38:15,340
>> Ek het 'n tipe nakoming
van die proses wat loop.

2233
01:38:15,340 --> 01:38:17,430
Dit moet seker maak dat
En as hierdie dinge verander,

2234
01:38:17,430 --> 01:38:21,840
dat hulle binne sekere perke
of binne sekere parameters.

2235
01:38:21,840 --> 01:38:23,840
>> En dan slegs miskien is ek
nodig om te weet wat verander.

2236
01:38:23,840 --> 01:38:26,240
Ek gee nie om wat item verander.

2237
01:38:26,240 --> 01:38:28,580
Ek het nie nodig om te weet
wat veranderde eienskappe.

2238
01:38:28,580 --> 01:38:30,882
Ek het net nodig om te weet dat
die items word geraak.

2239
01:38:30,882 --> 01:38:33,340
So dit is die tipes van aansigte
dat jy uit die stroom

2240
01:38:33,340 --> 01:38:35,960
en jy kan interaksie met.

2241
01:38:35,960 --> 01:38:37,840
>> Die program wat
verorber die stroom,

2242
01:38:37,840 --> 01:38:39,298
dit is soort van die wyse waarop hierdie werk.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB kliënt vra om
stoot data na die tafels.

2244
01:38:42,570 --> 01:38:44,750
Strome ontplooi op wat ons skerwe noem.

2245
01:38:44,750 --> 01:38:47,380
Skerwe afgeskaal
onafhanklik van die tafel.

2246
01:38:47,380 --> 01:38:50,660
Hulle het nie heeltemal in lyn
om die mure van jou tafel.

2247
01:38:50,660 --> 01:38:52,540
En die rede hoekom is
omdat hulle line-up

2248
01:38:52,540 --> 01:38:55,430
om die kapasiteit, die huidige
kapasiteit van die tafel.

2249
01:38:55,430 --> 01:38:57,600
>> Hulle sit in hul
eie motor skalering groep

2250
01:38:57,600 --> 01:39:00,800
en hulle het begin om te draai, afhangende
hoeveel skryf kom in,

2251
01:39:00,800 --> 01:39:03,090
hoeveel reads-- regtig dis skryf.

2252
01:39:03,090 --> 01:39:05,820
Daar is geen reads-- maar hoe
baie skryf kom in.

2253
01:39:05,820 --> 01:39:08,200
>> En dan op die rug
einde, ons het wat ons

2254
01:39:08,200 --> 01:39:11,390
noem 'n KCL, of Kinesis kliënt biblioteek.

2255
01:39:11,390 --> 01:39:19,190
Kinesis is 'n stroom data
verwerking tegnologie van Amazon.

2256
01:39:19,190 --> 01:39:22,040
En strome is gebou op dit.

2257
01:39:22,040 --> 01:39:25,670
>> So gebruik jy 'n KCL enabled
aansoek om die stroom te lees.

2258
01:39:25,670 --> 01:39:28,752
Die Kinesis kliënt Biblioteek eintlik
bestuur die werkers vir jou.

2259
01:39:28,752 --> 01:39:30,460
En dit nie ook 'n paar
interessante dinge.

2260
01:39:30,460 --> 01:39:35,630
Dit sal 'n paar tafels skep up
in jou DynamoDB table space

2261
01:39:35,630 --> 01:39:38,410
waartoe items op te spoor
verwerk.

2262
01:39:38,410 --> 01:39:41,190
So op hierdie manier as dit val terug, as
dit val oor en kom en kry

2263
01:39:41,190 --> 01:39:45,570
staan ​​terug, kan dit bepaal waar
was dit in die verwerking van die stroom.

2264
01:39:45,570 --> 01:39:48,360
>> Dit is baie belangrik wanneer
jy praat replikasie.

2265
01:39:48,360 --> 01:39:50,350
Ek moet weet wat
data is verwerk

2266
01:39:50,350 --> 01:39:52,810
en wat data het nog verwerk moet word.

2267
01:39:52,810 --> 01:39:57,380
So die KCL biblioteek vir strome sal
gee jou 'n baie van daardie funksie.

2268
01:39:57,380 --> 01:39:58,990
Dit sorg vir al die huishouding.

2269
01:39:58,990 --> 01:40:01,140
Dit staan ​​op 'n werker vir elke segment.

2270
01:40:01,140 --> 01:40:04,620
Dit skep 'n administratiewe tafel
vir elke segment, vir elke werker.

2271
01:40:04,620 --> 01:40:07,560
En as dié werkers vuur
hulle handhaaf die tafels

2272
01:40:07,560 --> 01:40:10,510
sodat jy weet hierdie rekord
gelees en verwerk.

2273
01:40:10,510 --> 01:40:13,850
En dan so as die proses
sterf en kom terug online,

2274
01:40:13,850 --> 01:40:17,940
dit kan hervat reg waar dit opgestyg het.

2275
01:40:17,940 --> 01:40:20,850
>> Sodat ons dit gebruik vir
kruis-streek replikasie.

2276
01:40:20,850 --> 01:40:24,680
Baie kliënte het die behoefte om
data of dele van hul data tafels beweeg

2277
01:40:24,680 --> 01:40:25,920
om na die verskillende streke.

2278
01:40:25,920 --> 01:40:29,230
Daar is nege streke
oor die hele wêreld.

2279
01:40:29,230 --> 01:40:32,100
So is daar 'n need-- ek dalk
kan gebruikers in Asië, gebruikers

2280
01:40:32,100 --> 01:40:34,150
in die ooskus van die Verenigde State van Amerika.

2281
01:40:34,150 --> 01:40:38,980
Hulle het verskillende data wat
moet plaaslik versprei word.

2282
01:40:38,980 --> 01:40:42,510
En miskien 'n gebruiker vlieg van
Asië na die Verenigde State,

2283
01:40:42,510 --> 01:40:45,020
en ek wil om te herhaal
sy data met hom.

2284
01:40:45,020 --> 01:40:49,340
So wanneer hy kry uit die vliegtuig, het hy
'n goeie ervaring met behulp van sy foon.

2285
01:40:49,340 --> 01:40:52,360
>> Jy kan die kruis-streek gebruik
replikasie biblioteek om dit te doen.

2286
01:40:52,360 --> 01:40:55,730
Basies het ons
verskaf twee tegnologie.

2287
01:40:55,730 --> 01:40:59,400
Een is 'n konsole aansoek wat jy kan
staan ​​op jou eie EC2 byvoorbeeld.

2288
01:40:59,400 --> 01:41:01,240
Dit loop pure replikasie.

2289
01:41:01,240 --> 01:41:02,720
En dan het ons u die biblioteek.

2290
01:41:02,720 --> 01:41:06,070
Die biblioteek wat jy kan gebruik om te bou
jou eie aansoek as jy

2291
01:41:06,070 --> 01:41:10,740
wil mal dinge te doen met daardie data--
filter, herhaal net deel van dit,

2292
01:41:10,740 --> 01:41:14,120
draai die data, beweeg dit in 'n
ander tafel, so aan en so voort.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
So dit is soort van wat dit lyk.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB strome kan
verwerk deur wat ons Lambda noem.

2296
01:41:23,690 --> 01:41:27,394
Ons genoem 'n bietjie oor gebeurtenis
gedryf aansoek argitekture.

2297
01:41:27,394 --> 01:41:28,810
Lambda is 'n belangrike komponent van daardie.

2298
01:41:28,810 --> 01:41:32,840
Lambda is kode wat vure op aanvraag
in reaksie op 'n spesifieke gebeurtenis.

2299
01:41:32,840 --> 01:41:36,020
Een van die gebeure kan 'n
rekord wat op die stroom.

2300
01:41:36,020 --> 01:41:39,100
As 'n rekord verskyn op die stroom,
ons sal hierdie Java funksie noem.

2301
01:41:39,100 --> 01:41:44,980
Wel, dit is JavaScript en Lambda
ondersteun Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
en sal binnekort ondersteun
ander tale.

2303
01:41:47,820 --> 01:41:50,940
En voldoende om te sê, dit is suiwer-kode.

2304
01:41:50,940 --> 01:41:53,610
skryf In Java, jy 'n klas te definieer.

2305
01:41:53,610 --> 01:41:55,690
Jy druk die JAR tot in Lambda.

2306
01:41:55,690 --> 01:42:00,200
En dan spesifiseer watter klas wat jy
om te skakel in reaksie op wat geval.

2307
01:42:00,200 --> 01:42:04,770
En dan is die Lambda infrastruktuur
agter wat daardie kode hardloop.

2308
01:42:04,770 --> 01:42:06,730
>> Dit kode kan verwerk
rekords van die stroom.

2309
01:42:06,730 --> 01:42:08,230
Dit kan enigiets wat dit wil doen met dit.

2310
01:42:08,230 --> 01:42:11,650
In hierdie spesifieke voorbeeld, al wat ons is
eintlik doen is teken die eienskappe.

2311
01:42:11,650 --> 01:42:13,480
Maar dit is net die kode.

2312
01:42:13,480 --> 01:42:15,260
Kode kan niks doen nie, reg?

2313
01:42:15,260 --> 01:42:16,600
>> So kan jy die data te draai.

2314
01:42:16,600 --> 01:42:18,160
Jy kan 'n afgeleide oog te skep.

2315
01:42:18,160 --> 01:42:21,160
As dit is 'n dokument struktuur,
kan jy die struktuur plat.

2316
01:42:21,160 --> 01:42:24,300
Jy kan alternatiewe indekse skep.

2317
01:42:24,300 --> 01:42:27,100
Alle vorme van dinge wat jy kan
doen met die DynamoDB Streams.

2318
01:42:27,100 --> 01:42:28,780
>> En regtig, dit is wat die lyk.

2319
01:42:28,780 --> 01:42:29,940
So jy diegene updates kom in.

2320
01:42:29,940 --> 01:42:31,190
Hulle kom uit die string.

2321
01:42:31,190 --> 01:42:32,720
Hulle is gelees deur die Lambda funksie.

2322
01:42:32,720 --> 01:42:37,480
Hulle is die draai van die data en
stoot dit in afgeleide tafels,

2323
01:42:37,480 --> 01:42:42,200
kennis te stel eksterne stelsels van verandering,
en stoot data in ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Ons het gepraat oor hoe om die kas te sit
in die voorkant van die databasis vir daardie verkope

2325
01:42:45,900 --> 01:42:46,450
scenario.

2326
01:42:46,450 --> 01:42:50,049
Wel, wat gebeur as ek
werk die item beskrywing?

2327
01:42:50,049 --> 01:42:52,340
Wel, as ek 'n Lambda
funksie wat uitgevoer word op die tafel,

2328
01:42:52,340 --> 01:42:55,490
as ek werk die item beskrywing, sal dit
haal die rekord van die stroom,

2329
01:42:55,490 --> 01:42:58,711
en dit sal die ElastiCache werk
byvoorbeeld met die nuwe data.

2330
01:42:58,711 --> 01:43:00,460
So dit is 'n baie
wat ons doen met Lambda.

2331
01:43:00,460 --> 01:43:02,619
Dit is die gom kode, aansluiting.

2332
01:43:02,619 --> 01:43:04,410
En dit is eintlik gee
die vermoë om te loods

2333
01:43:04,410 --> 01:43:07,930
en baie komplekse toepassings hardloop
sonder 'n toegewyde bediener

2334
01:43:07,930 --> 01:43:10,371
infrastruktuur, wat is regtig cool.

2335
01:43:10,371 --> 01:43:13,100
>> So laat ons gaan terug na ons
real-time stem argitektuur.

2336
01:43:13,100 --> 01:43:17,984
Dit is 'n nuwe en verbeterde met ons
strome en KCL enabled aansoek.

2337
01:43:17,984 --> 01:43:20,150
Dieselfde as voorheen, kan ons
hanteer enige skaal van die verkiesing.

2338
01:43:20,150 --> 01:43:21,100
Ons hou van hierdie.

2339
01:43:21,100 --> 01:43:24,770
Ons doen uit strooi versamel
oor verskeie emmers.

2340
01:43:24,770 --> 01:43:26,780
Ons het optimisties locking aangaan.

2341
01:43:26,780 --> 01:43:30,192
Ons kan nie ons kiesers te hou
van die verandering van hul stemme.

2342
01:43:30,192 --> 01:43:31,400
Hulle kan net een keer stem.

2343
01:43:31,400 --> 01:43:32,880
Dit is fantasties.

2344
01:43:32,880 --> 01:43:35,895
Real-time skuld verdraagsaamheid,
skaalbare samevoeging nou.

2345
01:43:35,895 --> 01:43:38,270
As die ding val oor dit
weet waar om te begin self

2346
01:43:38,270 --> 01:43:41,300
wanneer dit kom terug omdat
Ons gebruik die KCL app.

2347
01:43:41,300 --> 01:43:45,700
En dan kan ons ook dat
KCL aansoek om data uit te druk

2348
01:43:45,700 --> 01:43:48,820
om rooi verschuiving vir ander
app analytics, of gebruik

2349
01:43:48,820 --> 01:43:51,990
Die elastiese MapReduce om te hardloop
real-time streaming swerms af

2350
01:43:51,990 --> 01:43:53,180
van daardie data.

2351
01:43:53,180 --> 01:43:55,480
>> So dit is dinge wat ons
het nie gepraat oor veel.

2352
01:43:55,480 --> 01:43:57,375
Maar hulle is addisionele
tegnologie wat kom

2353
01:43:57,375 --> 01:44:00,310
om te dra wanneer jy op soek is
by hierdie tipe van scenario's.

2354
01:44:00,310 --> 01:44:03,160
>> Alle reg, sodat dit is oor
analytics met DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
Jy kan de-bedrieg samel
data, doen allerhande

2356
01:44:05,340 --> 01:44:09,490
mooi dinge, totaal data in
geheue, skep die afgeleide tafels.

2357
01:44:09,490 --> 01:44:13,110
Dit is 'n groot gebruik geval
dat baie van die kliënte

2358
01:44:13,110 --> 01:44:16,950
is betrokke by, neem die geneste
eienskappe van die into dokumente

2359
01:44:16,950 --> 01:44:18,946
en die skep van bykomende indekse.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Ons is aan die einde.

2362
01:44:23,150 --> 01:44:26,689
Dankie vir julle geduld met my.

2363
01:44:26,689 --> 01:44:28,480
So laat ons praat oor
verwysing argitektuur.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB sit in die middel van so
baie van die AWS infrastruktuur.

2365
01:44:33,440 --> 01:44:37,090
Basies kan jy dit haak
tot enigiets wat jy wil.

2366
01:44:37,090 --> 01:44:45,600
Aansoeke gebou met behulp van Dynamo sluit
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
stoot die data uit in Elastiese
MapReduce, invoer uitvoer van DynamoDB

2368
01:44:49,890 --> 01:44:52,370
in S3, alle vorme van werkstromen.

2369
01:44:52,370 --> 01:44:54,120
Maar waarskynlik die beste
ding om te praat oor,

2370
01:44:54,120 --> 01:44:56,119
en dit is wat regtig
interessant is, is wanneer ons

2371
01:44:56,119 --> 01:44:58,350
praat oor gebeurtenis gedrewe programme.

2372
01:44:58,350 --> 01:45:00,300
>> Dit is 'n voorbeeld van
'n interne projek

2373
01:45:00,300 --> 01:45:04,850
dat ons waar ons is eintlik
publishing opname resultate te samel.

2374
01:45:04,850 --> 01:45:07,700
So in 'n e-pos skakel wat
ons stuur, sal daar

2375
01:45:07,700 --> 01:45:11,350
'n bietjie skakel gesê kliek
hier om te reageer op die opname.

2376
01:45:11,350 --> 01:45:14,070
En wanneer 'n persoon druk
wat verwys, wat gebeur

2377
01:45:14,070 --> 01:45:18,020
is hulle trek 'n veilige
HTML opname vorm van S3.

2378
01:45:18,020 --> 01:45:18,980
Daar is geen bediener.

2379
01:45:18,980 --> 01:45:20,600
Dit is net 'n S3 voorwerp.

2380
01:45:20,600 --> 01:45:22,770
>> Dit vorm kom,
laai in die leser.

2381
01:45:22,770 --> 01:45:24,240
Dit het Backbone.

2382
01:45:24,240 --> 01:45:30,160
Dit het komplekse JavaScript
dat dit loop.

2383
01:45:30,160 --> 01:45:33,557
So dit is 'n baie ryk aansoek
hardloop in die leser van die kliënt.

2384
01:45:33,557 --> 01:45:36,390
Hulle weet nie dat hulle nie
interaksie met 'n agterkant bediener.

2385
01:45:36,390 --> 01:45:38,220
Op hierdie punt, dit is alles leser.

2386
01:45:38,220 --> 01:45:41,780
>> Hulle publiseer die resultate wat
ons die Amazon API Gateway noem.

2387
01:45:41,780 --> 01:45:46,270
API Gateway is bloot 'n web API
wat jy kan definieer en haak

2388
01:45:46,270 --> 01:45:47,760
om alles wat jy wil.

2389
01:45:47,760 --> 01:45:50,990
In hierdie spesifieke geval, ons is
verslaaf aan 'n Lambda funksie.

2390
01:45:50,990 --> 01:45:54,797
>> So my POST werking is
gebeur met geen bediener.

2391
01:45:54,797 --> 01:45:56,380
Basies dat API Gateway sit daar.

2392
01:45:56,380 --> 01:45:58,770
Dit kos my niks totdat mense
begin plaas om dit, reg?

2393
01:45:58,770 --> 01:46:00,269
Die Lambda funksie sit net daar.

2394
01:46:00,269 --> 01:46:03,760
En dit kos my niks te gebruik totdat
mense begin slaan het.

2395
01:46:03,760 --> 01:46:07,270
Sodat jy kan sien, as die volume
toeneem, dit is wanneer die koste kom.

2396
01:46:07,270 --> 01:46:09,390
Ek is nie 'n bediener 24/07.

2397
01:46:09,390 --> 01:46:12,310
>> So ek trek die vorm
af uit die emmer,

2398
01:46:12,310 --> 01:46:15,719
en ek plaas deur die API
Gateway na die Lambda funksie.

2399
01:46:15,719 --> 01:46:17,510
En dan is die Lambda
funksie sê, jy weet

2400
01:46:17,510 --> 01:46:20,600
wat, het ek 'n paar PIIs het, 'n paar
persoonlike inligting

2401
01:46:20,600 --> 01:46:21,480
in hierdie antwoorde.

2402
01:46:21,480 --> 01:46:23,020
Ek het kommentaar kom van die gebruikers.

2403
01:46:23,020 --> 01:46:24,230
Ek het e-pos adresse.

2404
01:46:24,230 --> 01:46:26,190
Ek het gebruikers.

2405
01:46:26,190 --> 01:46:27,810
>> Laat my verdeel dit af.

2406
01:46:27,810 --> 01:46:30,280
Ek gaan 'n paar te genereer
metadata uit hierdie rekord.

2407
01:46:30,280 --> 01:46:32,850
En ek gaan na die druk
metadata in DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
En ek kon al die data te enkripteer
en druk dit in DynamoDB as ek wil.

2409
01:46:36,059 --> 01:46:38,600
Maar dit is makliker vir my, in hierdie
gebruik geval, om voort te gaan 'n sê,

2410
01:46:38,600 --> 01:46:42,800
Ek gaan die rou data te stoot
in 'n geïnkripteer S3 emmer.

2411
01:46:42,800 --> 01:46:47,240
So ek gebruik gebou in S3 bediener kant
enkripsie en Sleutel Management Amazon se

2412
01:46:47,240 --> 01:46:51,600
Service so dat ek 'n sleutel wat
kan draai op 'n gereelde interval,

2413
01:46:51,600 --> 01:46:55,010
en ek kan dit PII data te beskerm
as deel van hierdie hele workflow.

2414
01:46:55,010 --> 01:46:55,870
>> So, wat het ek gedoen?

2415
01:46:55,870 --> 01:47:00,397
Ek het net 'n hele ontplooi
aansoek, en ek het geen bediener.

2416
01:47:00,397 --> 01:47:02,980
So is wat gebeurtenis gedrewe aansoek
argitektuur doen vir jou.

2417
01:47:02,980 --> 01:47:05,730
>> Nou as jy dink oor
die gebruik geval vir this--

2418
01:47:05,730 --> 01:47:08,730
ons het ander kliënte ek praat
om oor hierdie presiese argitektuur wat

2419
01:47:08,730 --> 01:47:14,560
hardloop fenomenaal groot veldtogte, wat
is op soek na hierdie en gaan, oh my.

2420
01:47:14,560 --> 01:47:17,840
Want nou het, kan hulle
stoot dit basies daar buite,

2421
01:47:17,840 --> 01:47:21,900
laat die veldtog net sit
daar tot dit lanseer, en nie

2422
01:47:21,900 --> 01:47:24,400
'n vyeboom bekommer oor
watter soort infrastruktuur

2423
01:47:24,400 --> 01:47:26,120
gaan daar wees om dit te ondersteun.

2424
01:47:26,120 --> 01:47:28,600
En dan so gou as
die veldtog gedoen word,

2425
01:47:28,600 --> 01:47:31,520
dit is soos die infrastruktuur
net onmiddellik gaan weg

2426
01:47:31,520 --> 01:47:33,680
want daar is regtig
is geen infrastruktuur.

2427
01:47:33,680 --> 01:47:35,660
Dis net-kode wat sit op Lambda.

2428
01:47:35,660 --> 01:47:38,560
Dis net data wat sit in DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Dit is 'n ongelooflike manier
om programme op te bou.

2430
01:47:41,340 --> 01:47:43,970
>> GEHOOR: So is dit meer
efemere as wat dit sou wees

2431
01:47:43,970 --> 01:47:45,740
As dit is gestoor op 'n werklike bediener?

2432
01:47:45,740 --> 01:47:46,823
>> Rick Houlihan: Absoluut.

2433
01:47:46,823 --> 01:47:49,190
Want dit bediener byvoorbeeld
sou 'n 24/7 te wees.

2434
01:47:49,190 --> 01:47:51,954
Dit het tot die beskikbare wees vir
iemand om te reageer op.

2435
01:47:51,954 --> 01:47:52,620
Wel raai wat?

2436
01:47:52,620 --> 01:47:55,410
S3 is beskikbaar 24/7.

2437
01:47:55,410 --> 01:47:57,100
S3 reageer altyd.

2438
01:47:57,100 --> 01:47:59,320
En S3 is baie, baie goed
om te dien op voorwerpe.

2439
01:47:59,320 --> 01:48:02,590
Diegene voorwerpe kan wees HTML-lêers, of
JavaScript-lêers, of wat jy wil.

2440
01:48:02,590 --> 01:48:07,430
Jy kan 'n baie ryk web programme te hardloop
uit S3 emmers, en mense doen.

2441
01:48:07,430 --> 01:48:10,160
>> En so dit is die idee hier
is om weg van die pad te kry

2442
01:48:10,160 --> 01:48:11,270
ons gebruik om te dink oor dit.

2443
01:48:11,270 --> 01:48:14,270
Ons almal gebruik om te dink in
terme van bedieners en gashere.

2444
01:48:14,270 --> 01:48:16,580
Dit gaan nie oor wat nie.

2445
01:48:16,580 --> 01:48:19,310
Dit gaan oor die infrastruktuur-kode.

2446
01:48:19,310 --> 01:48:22,470
Ontplooi die kode om die wolk en
laat die wolk loop dit vir jou.

2447
01:48:22,470 --> 01:48:24,980
En dit is wat AWS probeer om te doen.

2448
01:48:24,980 --> 01:48:29,690
>> GEHOOR: So jou goue boks in die middel
van die API Gateway is nie bediener-agtige,

2449
01:48:29,690 --> 01:48:30,576
maar in plaas daarvan is just--

2450
01:48:30,576 --> 01:48:32,850
>> Rick Houlihan: Jy kan dink
dit as bediener gevel.

2451
01:48:32,850 --> 01:48:38,040
Al wat dit is, is dit sal 'n HTTP neem
versoek en kaart na 'n ander proses.

2452
01:48:38,040 --> 01:48:39,192
Dit is al wat dit doen nie.

2453
01:48:39,192 --> 01:48:41,525
En in hierdie geval, ons kartering
dat dit 'n Lambda funksie.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Alle reg, so dit is al wat ek het.

2456
01:48:45,410 --> 01:48:46,190
Baie dankie.

2457
01:48:46,190 --> 01:48:46,800
Ek waardeer dit.

2458
01:48:46,800 --> 01:48:48,100
Ek weet ons wil 'n bietjie oor die tyd.

2459
01:48:48,100 --> 01:48:49,980
En hopelik het julle ouens
'n bietjie van inligting

2460
01:48:49,980 --> 01:48:51,410
dat jy vandag kan wegneem.

2461
01:48:51,410 --> 01:48:53,520
En ek is jammer as ek gaan
oor 'n paar van julle hoofde,

2462
01:48:53,520 --> 01:48:56,697
maar daar is 'n goeie klomp
fundamentele kennis fundamentele

2463
01:48:56,697 --> 01:48:58,280
wat ek dink is baie waardevol vir jou.

2464
01:48:58,280 --> 01:48:59,825
So dankie vir die feit dat my.

2465
01:48:59,825 --> 01:49:00,325
[Applous]

2466
01:49:00,325 --> 01:49:02,619
GEHOOR: [onhoorbaar]
is wanneer jy sê

2467
01:49:02,619 --> 01:49:05,160
jy het om te gaan deur middel van die ding
van die begin tot die einde

2468
01:49:05,160 --> 01:49:07,619
om die regte waardes te kry
of dieselfde waardes,

2469
01:49:07,619 --> 01:49:09,410
hoe sou die waardes
verander as [onhoorbaar].

2470
01:49:09,410 --> 01:49:10,480
>> Rick Houlihan: O, idempotente?

2471
01:49:10,480 --> 01:49:11,800
Hoe sou die waardes verander?

2472
01:49:11,800 --> 01:49:15,180
Wel, want as ek nie hardloop
dit al die pad tot die einde,

2473
01:49:15,180 --> 01:49:19,770
dan weet ek nie wat verander
gemaak in die laaste myl.

2474
01:49:19,770 --> 01:49:22,144
Dit gaan nie om die wees
dieselfde data as wat ek gesien het.

2475
01:49:22,144 --> 01:49:24,560
GEHOOR: O, so jy net
het nie die hele insette gekry.

2476
01:49:24,560 --> 01:49:24,770
Rick Houlihan: Right.

2477
01:49:24,770 --> 01:49:26,895
Jy het om te gaan van die begin
aan die einde, en dan is dit

2478
01:49:26,895 --> 01:49:29,280
gaan om 'n konsekwente staat.

2479
01:49:29,280 --> 01:49:31,520
Koel.

2480
01:49:31,520 --> 01:49:35,907
>> GEHOOR: So jy ons gewys DynamoDB
kan dokument of die sleutel waarde nie.

2481
01:49:35,907 --> 01:49:38,740
En ons het 'n baie tyd op die
sleutel waarde met 'n hash en die maniere

2482
01:49:38,740 --> 01:49:40,005
om dit te draai om.

2483
01:49:40,005 --> 01:49:43,255
Wanneer jy kyk na die tafels, is dat
vertrek agter die dokument benadering?

2484
01:49:43,255 --> 01:49:44,600
>> Rick Houlihan: Ek sou nie
sê laat dit agter.

2485
01:49:44,600 --> 01:49:45,855
>> GEHOOR: Hulle was geskei van the--

2486
01:49:45,855 --> 01:49:49,140
>> Rick Houlihan: Met die dokument
benadering, die tipe dokument DynamoDB

2487
01:49:49,140 --> 01:49:50,880
is dink net as 'n ander kenmerk.

2488
01:49:50,880 --> 01:49:53,560
Dit is 'n eienskap wat bevat
'n hiërargiese struktuur data.

2489
01:49:53,560 --> 01:49:56,980
En dan in die navrae,
kan jy die eienskappe te gebruik

2490
01:49:56,980 --> 01:49:59,480
van daardie voorwerpe met Object notasie.

2491
01:49:59,480 --> 01:50:03,562
So ek kan filter op 'n sub-
eiendom van die into dokument.

2492
01:50:03,562 --> 01:50:05,520
GEHOOR: So enige tyd wat ek
doen 'n dokument benadering,

2493
01:50:05,520 --> 01:50:07,906
Ek kan soort van kom by die tabular--

2494
01:50:07,906 --> 01:50:08,780
GEHOOR: Absoluut.

2495
01:50:08,780 --> 01:50:09,800
GEHOOR: --indexes en
dinge wat jy net gepraat oor.

2496
01:50:09,800 --> 01:50:11,280
Rick Houlihan: Ja, die
indekse en alles wat,

2497
01:50:11,280 --> 01:50:13,363
wanneer jy wil die indeks die
eienskappe van die into

2498
01:50:13,363 --> 01:50:18,230
die manier waarop ons wil hê om dit te doen, is as
'n into voorwerp of 'n dokument voeg

2499
01:50:18,230 --> 01:50:20,780
in Dynamo, sou jy strome te gebruik.

2500
01:50:20,780 --> 01:50:22,400
Strome sal die insette te lees.

2501
01:50:22,400 --> 01:50:24,340
Jy wil kry dat into
beswaar en jy wil sê OK,

2502
01:50:24,340 --> 01:50:26,030
wat is die eiendom wil ek indeks?

2503
01:50:26,030 --> 01:50:28,717
>> Jy skep 'n afgeleide tafel.

2504
01:50:28,717 --> 01:50:30,300
Nou dit is die manier waarop dit nou werk.

2505
01:50:30,300 --> 01:50:32,650
Ons vra nie dat jy toelaat dat indeks
direk daardie eiendomme.

2506
01:50:32,650 --> 01:50:33,520
>> GEHOOR: Tabularizing jou dokumente.

2507
01:50:33,520 --> 01:50:36,230
>> Rick Houlihan: Presies, plat te slaan
dit tabularizing dit, presies.

2508
01:50:36,230 --> 01:50:37,415
Dit is wat jy doen met dit.

2509
01:50:37,415 --> 01:50:37,860
>> GEHOOR: Dankie.

2510
01:50:37,860 --> 01:50:39,609
>> Rick Houlihan: Yep,
absoluut, dankie.

2511
01:50:39,609 --> 01:50:42,240
GEHOOR: So dit is soort van
Mongo vergader Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> Rick Houlihan: Ja,
dit is 'n baie soos dit.

2513
01:50:43,990 --> 01:50:45,940
Dit is 'n goeie beskrywing vir dit.

2514
01:50:45,940 --> 01:50:47,490
Koel.

2515
01:50:47,490 --> 01:50:49,102