1
00:00:00,000 --> 00:00:04,969
>> [MUSIC SPILLE]

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: All right.

3
00:00:06,010 --> 00:00:06,600
Hei alle sammen.

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

5
00:00:07,670 --> 00:00:10,330
Jeg er en senior rektor
løsningsarkitekt på AWS.

6
00:00:10,330 --> 00:00:14,070
Jeg fokuserer på NoSQL og
DynamoDB teknologier.

7
00:00:14,070 --> 00:00:16,930
Jeg er her i dag for å snakke med
du litt om dem.

8
00:00:16,930 --> 00:00:18,970
>> Min bakgrunn er
primært i datalaget.

9
00:00:18,970 --> 00:00:21,390
Jeg tilbrakte halve min utvikling
karriere skriver database,

10
00:00:21,390 --> 00:00:25,930
datatilgang, løsninger
for ulike bruksområder.

11
00:00:25,930 --> 00:00:30,000
Jeg har vært i Cloud virtualisering
for ca 20 år.

12
00:00:30,000 --> 00:00:33,460
Så før Cloud var Cloud,
vi pleide å kalle det utility computing.

13
00:00:33,460 --> 00:00:37,170
Og ideen var, er det som
PG & E, du betaler for det du bruker.

14
00:00:37,170 --> 00:00:38,800
I dag kaller vi det skyen.

15
00:00:38,800 --> 00:00:41,239
>> Men i løpet av de årene jeg har jobbet
for et par selskaper

16
00:00:41,239 --> 00:00:42,530
du har sikkert aldri hørt om.

17
00:00:42,530 --> 00:00:47,470
Men jeg har samlet en liste over teknisk
prestasjoner, tror jeg du ville si.

18
00:00:47,470 --> 00:00:51,620
Jeg har åtte patenter i Cloud-systemer
virtualisering, mikroprosessor design,

19
00:00:51,620 --> 00:00:54,440
kompleks hendelse behandling,
og andre områder også.

20
00:00:54,440 --> 00:00:58,290
>> Så disse dager, fokuserer jeg mest på NoSQL
teknologier og neste generasjon

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

22
00:00:59,450 --> 00:01:03,370
Og det er som regel hva jeg skal
å være her å snakke med dere i dag om.

23
00:01:03,370 --> 00:01:06,030
Så hva du kan forvente
fra denne sesjonen,

24
00:01:06,030 --> 00:01:08,254
vi vil gå gjennom en kort
historie med databehandling.

25
00:01:08,254 --> 00:01:10,420
Det er alltid nyttig å
forstå hvor vi kom fra

26
00:01:10,420 --> 00:01:12,400
og hvorfor vi er der vi er.

27
00:01:12,400 --> 00:01:15,600
Og vi skal snakke litt
litt om NoSQL teknologi

28
00:01:15,600 --> 00:01:17,500
fra et fundamentalt synspunkt.

29
00:01:17,500 --> 00:01:19,870
>> Vi vil få inn noen av
de DynamoDB innvendige.

30
00:01:19,870 --> 00:01:24,350
DynamoDB er AWS er ​​ingen smak.

31
00:01:24,350 --> 00:01:27,340
Det er et fullstendig styrt og
hosted NoSQL løsning.

32
00:01:27,340 --> 00:01:32,420
Og vi skal snakke litt om bord
struktur, APIer, datatyper, indekser,

33
00:01:32,420 --> 00:01:35,177
og noen av de innvendige
av at DynamoDB teknologi.

34
00:01:35,177 --> 00:01:37,760
Vi vil få inn noen av design
mønstre og beste praksis.

35
00:01:37,760 --> 00:01:39,968
Vi skal snakke om hvordan du
bruker denne teknologien for noen

36
00:01:39,968 --> 00:01:41,430
av dagens programmer.

37
00:01:41,430 --> 00:01:44,820
Og så får vi snakke litt
om utviklingen eller fremveksten

38
00:01:44,820 --> 00:01:48,980
av et nytt paradigme i programmering
kalles hendelsesdrevne applikasjoner

39
00:01:48,980 --> 00:01:51,580
og hvordan DynamoDB spiller i det også.

40
00:01:51,580 --> 00:01:54,690
Og vi vil gi dere en liten bit av
en referansearkitektur diskusjon

41
00:01:54,690 --> 00:01:59,540
slik at vi kan snakke om noen av
måtene du kan bruke DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Så først off-- dette er et spørsmål
Jeg hører mye er, hva som er en database.

43
00:02:04,116 --> 00:02:06,240
Mange mennesker tror de
vet hva en database er.

44
00:02:06,240 --> 00:02:08,360
Hvis du Google, vil du se dette.

45
00:02:08,360 --> 00:02:11,675
Det er en en strukturert sett av data holdt
i en datamaskin, spesielt en som

46
00:02:11,675 --> 00:02:13,600
er tilgjengelig på forskjellige måter.

47
00:02:13,600 --> 00:02:16,992
Jeg antar det er en god
Definisjonen av en moderne database.

48
00:02:16,992 --> 00:02:19,450
Men jeg liker det ikke, fordi
det innebærer et par ting.

49
00:02:19,450 --> 00:02:20,935
Det innebærer struktur.

50
00:02:20,935 --> 00:02:23,120
Og det innebærer at det er på en datamaskin.

51
00:02:23,120 --> 00:02:25,750
Og databaser gjorde ikke
alltid eksistere på datamaskiner.

52
00:02:25,750 --> 00:02:28,020
Databaser faktisk eksisterte på mange måter.

53
00:02:28,020 --> 00:02:32,000
>> Så en bedre definisjon av en
Databasen er noe sånt som dette.

54
00:02:32,000 --> 00:02:34,786
En database er en organisert
mekanisme for lagring, håndtering,

55
00:02:34,786 --> 00:02:35,910
og hente informasjon.

56
00:02:35,910 --> 00:02:36,868
Dette er fra About.com.

57
00:02:36,868 --> 00:02:42,080
Så jeg liker dette fordi det egentlig snakker
om en database være et oppbevaringssted,

58
00:02:42,080 --> 00:02:44,800
et oppbevaringssted for
informasjon, ikke nødvendigvis

59
00:02:44,800 --> 00:02:46,780
noe som sitter på en datamaskin.

60
00:02:46,780 --> 00:02:49,290
Og gjennom historien, vi
har ikke alltid hatt datamaskiner.

61
00:02:49,290 --> 00:02:52,110
>> Nå, hvis jeg spør den gjennomsnittlige
utbygger i dag hva som er

62
00:02:52,110 --> 00:02:54,770
en database, er at svaret jeg får.

63
00:02:54,770 --> 00:02:56,070
Et sted jeg kan stikke ting.

64
00:02:56,070 --> 00:02:56,670
Høyre?

65
00:02:56,670 --> 00:02:58,725
Og det er sant.

66
00:02:58,725 --> 00:02:59,600
Men det er uheldig.

67
00:02:59,600 --> 00:03:02,700
Fordi databasen er virkelig
grunnlaget for den moderne app.

68
00:03:02,700 --> 00:03:04,810
Det er stiftelsen
av hver søknad.

69
00:03:04,810 --> 00:03:07,240
Og hvordan du bygger som
database, hvordan du strukturere

70
00:03:07,240 --> 00:03:11,750
at data kommer til å diktere hvordan det
programmet utfører som du skalerer.

71
00:03:11,750 --> 00:03:14,640
>> Så mye av min jobb i dag
arbeider med hva

72
00:03:14,640 --> 00:03:17,180
skjer når utviklere
ta denne tilnærmingen

73
00:03:17,180 --> 00:03:19,510
og håndtere kjølvannet
av et program som

74
00:03:19,510 --> 00:03:24,966
er nå skalering utover den opprinnelige
intensjon og lider av dårlig design.

75
00:03:24,966 --> 00:03:26,840
Så forhåpentligvis når du
gange unna i dag, vil du

76
00:03:26,840 --> 00:03:29,010
har et par verktøy i
beltet som vil holde deg

77
00:03:29,010 --> 00:03:32,566
fra å gjøre de samme feilene.

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

79
00:03:33,066 --> 00:03:36,360
Så la oss snakke om en liten bit av
tidslinjen av databaseteknologi.

80
00:03:36,360 --> 00:03:38,830
Jeg tror jeg leste et
artikkelen er ikke så lenge siden

81
00:03:38,830 --> 00:03:43,020
og det sa noe på lines--
det er en veldig poetisk statement.

82
00:03:43,020 --> 00:03:46,590
Det sa historien
databehandling er

83
00:03:46,590 --> 00:03:49,350
full av høye vannmerker
av data overflod.

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

85
00:03:49,920 --> 00:03:52,532
Nå, jeg antar det er slags sant.

86
00:03:52,532 --> 00:03:54,990
Men jeg faktisk ser på er som
historien er faktisk fylt

87
00:03:54,990 --> 00:03:56,820
med høy vannmerke av data press.

88
00:03:56,820 --> 00:04:00,040
På grunn av at datahastigheten
Inntak aldri går ned.

89
00:04:00,040 --> 00:04:01,360
Det går bare opp.

90
00:04:01,360 --> 00:04:03,670
>> Og innovasjon oppstår når
vi se data press, noe som

91
00:04:03,670 --> 00:04:07,825
er mengden av data som er
nå i å komme inn i systemet.

92
00:04:07,825 --> 00:04:12,027
Og det kan ikke behandles
effektivt, enten i tid eller i pris.

93
00:04:12,027 --> 00:04:14,110
Og det er når vi starter
å se på data trykk.

94
00:04:14,110 --> 00:04:15,920
>> Så når vi ser på
første database, dette

95
00:04:15,920 --> 00:04:17,180
er det en som var mellom våre ører.

96
00:04:17,180 --> 00:04:18,310
Vi er alle født med det.

97
00:04:18,310 --> 00:04:19,194
Det er en fin database.

98
00:04:19,194 --> 00:04:21,110
Den har en høy tilgjengelighet.

99
00:04:21,110 --> 00:04:21,959
Det er alltid på.

100
00:04:21,959 --> 00:04:23,930
Du kan alltid få det.

101
00:04:23,930 --> 00:04:24,890
>> Men det er enkelt bruker.

102
00:04:24,890 --> 00:04:26,348
Jeg kan ikke dele mine tanker med deg.

103
00:04:26,348 --> 00:04:28,370
Du kan ikke få mine tanker
når du vil ha dem.

104
00:04:28,370 --> 00:04:30,320
Og deres abilitiy er ikke så bra.

105
00:04:30,320 --> 00:04:32,510
Vi glemmer ting.

106
00:04:32,510 --> 00:04:36,540
Hver nå og da, en av oss blader
og går videre til en annen tilværelse

107
00:04:36,540 --> 00:04:39,110
og vi mister alt
som var i denne databasen.

108
00:04:39,110 --> 00:04:40,640
Så det er ikke alt som godt.

109
00:04:40,640 --> 00:04:43,189
>> Og det fungerte bra over tid
da vi var tilbake i dag

110
00:04:43,189 --> 00:04:46,230
når alt vi virkelig trengte å vite er
hvor skal vi gå på i morgen

111
00:04:46,230 --> 00:04:49,630
eller der vi samler den beste maten.

112
00:04:49,630 --> 00:04:52,820
Men som vi begynte å vokse som en
sivilisasjon og regjeringen startet

113
00:04:52,820 --> 00:04:55,152
å bli til, og
bedrifter begynte å utvikle seg,

114
00:04:55,152 --> 00:04:57,360
vi begynte å innse vi
trenger litt mer enn hva

115
00:04:57,360 --> 00:04:58,210
vi kunne sette i vårt hode.

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

117
00:04:58,870 --> 00:05:00,410
>> Vi trengte systemer av posten.

118
00:05:00,410 --> 00:05:02,220
Vi trengte steder å kunne lagre data.

119
00:05:02,220 --> 00:05:05,450
Så vi begynte å skrive dokumenter,
lage biblioteker og arkiver.

120
00:05:05,450 --> 00:05:08,000
Vi begynte å utvikle en
systemet en hovedbok regnskap.

121
00:05:08,000 --> 00:05:12,200
Og at ordningen med hovedbok telling
kjørte hele verden i mange århundrer,

122
00:05:12,200 --> 00:05:15,580
og kanskje til og med årtusener som
vi slags vokste til et punkt

123
00:05:15,580 --> 00:05:18,420
hvor dataene belastning gått
evnen til disse systemene

124
00:05:18,420 --> 00:05:19,870
å være i stand til å inneholde det.

125
00:05:19,870 --> 00:05:22,070
>> Og dette faktisk skjedde på 1880-tallet.

126
00:05:22,070 --> 00:05:22,570
Høyre?

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

128
00:05:24,390 --> 00:05:26,976
Dette er virkelig der vende
punkt moderne databehandling.

129
00:05:26,976 --> 00:05:28,850
Dette er punktet
hvilken mengden av data

130
00:05:28,850 --> 00:05:32,060
som ble samlet inn av
USAs regjering kom til et punkt

131
00:05:32,060 --> 00:05:34,005
der det tok åtte år å behandle.

132
00:05:34,005 --> 00:05:36,350
>> Nå, åtte years-- som
du vet, den folketellingen

133
00:05:36,350 --> 00:05:39,180
går hver 10 years-- så det er
ganske åpenbart at etter tid vi

134
00:05:39,180 --> 00:05:41,419
fikk 1890 folketelling,
den mengde data som

135
00:05:41,419 --> 00:05:43,210
skulle bli behandlet
av regjeringen var

136
00:05:43,210 --> 00:05:46,335
kommer til å overstige 10 årene at det
ville ta å lansert den nye folketellingen.

137
00:05:46,335 --> 00:05:47,250
Dette var et problem.

138
00:05:47,250 --> 00:05:49,000
>> Så en fyr som heter Herman
Hollerith kom sammen

139
00:05:49,000 --> 00:05:52,640
og han oppfant enhet posten punsj
kort, punsj kortleser, klippekort

140
00:05:52,640 --> 00:05:58,420
tabulator, og sammenstilling av
mekanismene for denne teknologien.

141
00:05:58,420 --> 00:06:01,860
Og at selskapet som han dannet på
tid, sammen med et par andre,

142
00:06:01,860 --> 00:06:05,450
faktisk ble en av bærebjelkene i et
lite selskap vi kjenner i dag kalt IBM.

143
00:06:05,450 --> 00:06:08,417
>> Så IBM opprinnelig var i
databasen virksomhet.

144
00:06:08,417 --> 00:06:09,750
Og det er virkelig hva de gjorde.

145
00:06:09,750 --> 00:06:11,110
De gjorde databehandling.

146
00:06:11,110 --> 00:06:15,400
>> Som så spredning av slag
kort, en genial mekanismer

147
00:06:15,400 --> 00:06:18,560
for å være i stand til å utnytte denne
teknologi for å hente fra sorterte resultatsett.

148
00:06:18,560 --> 00:06:20,726
Du kan se på dette bildet
der har vi en little--

149
00:06:20,726 --> 00:06:23,970
det er litt small-- men du kan se
en svært genial mekanisk mekanisme

150
00:06:23,970 --> 00:06:26,970
hvor vi har et slag kort dekk.

151
00:06:26,970 --> 00:06:28,720
Og noen tar
en liten skrutrekker

152
00:06:28,720 --> 00:06:31,400
og stikker gjennom
slots og løfte den opp

153
00:06:31,400 --> 00:06:34,820
å få den kampen, som
sortert resultater innstilt.

154
00:06:34,820 --> 00:06:36,270
>> Dette er en samling.

155
00:06:36,270 --> 00:06:38,690
Vi gjør dette hele tiden
dag i datamaskinen,

156
00:06:38,690 --> 00:06:40,100
hvor du gjør det i databasen.

157
00:06:40,100 --> 00:06:41,620
Vi pleide å gjøre det manuelt, ikke sant?

158
00:06:41,620 --> 00:06:42,994
Folk setter disse tingene sammen.

159
00:06:42,994 --> 00:06:45,440
Og det var proliferasjonen
av disse hullkort

160
00:06:45,440 --> 00:06:50,070
inn i det vi kalte data trommer
og data hjulene, papir tape.

161
00:06:50,070 --> 00:06:55,980
>> Databehandlingsindustrien tok
en leksjon fra spilleren pianoer.

162
00:06:55,980 --> 00:06:57,855
Spiller pianoer tilbake på
den århundreskiftet

163
00:06:57,855 --> 00:07:02,100
pleide å bruke papirruller med spalter
på å fortelle det som tastene for å spille.

164
00:07:02,100 --> 00:07:05,380
Slik at teknologien ble tilpasset
slutt å lagre digitale data,

165
00:07:05,380 --> 00:07:08,070
fordi de kunne sette disse dataene
på disse papir tape hjulene.

166
00:07:08,070 --> 00:07:10,870
>> Nå, som et resultat av data
ble actually-- hvordan

167
00:07:10,870 --> 00:07:14,960
du tilgang til denne informasjonen var direkte
avhengig av hvor du har lagret det.

168
00:07:14,960 --> 00:07:17,825
Så hvis jeg legger data på en tape,
Jeg hadde tilgang til data lineært.

169
00:07:17,825 --> 00:07:20,475
Jeg måtte rulle hele
båndet for å få tilgang til alle data.

170
00:07:20,475 --> 00:07:22,600
Hvis jeg legger data i slag
kort, jeg kunne få tilgang til det

171
00:07:22,600 --> 00:07:26,270
i litt mer tilfeldig
mote, kanskje ikke så raskt.

172
00:07:26,270 --> 00:07:30,770
>> Men det var begrensninger i hvordan vi
tilgang til data basert på hvordan ble lagret.

173
00:07:30,770 --> 00:07:32,890
Og så dette var et problem
går inn i 50-tallet.

174
00:07:32,890 --> 00:07:37,890
Igjen kan vi begynne å se at når vi
utvikle nye teknologier for å behandle

175
00:07:37,890 --> 00:07:41,670
dataene, høyre, åpner det opp
døren for nye løsninger,

176
00:07:41,670 --> 00:07:45,852
for nye programmer, nye
applikasjoner for at data.

177
00:07:45,852 --> 00:07:47,810
Og virkelig, styresett
kan ha vært årsaken

178
00:07:47,810 --> 00:07:49,435
Derfor har vi utviklet noen av disse systemene.

179
00:07:49,435 --> 00:07:52,290
Men virksomheten ble raskt
driveren bak utviklingen

180
00:07:52,290 --> 00:07:54,720
av den moderne database og
den moderne filsystemet.

181
00:07:54,720 --> 00:07:56,870
>> Så det neste som
kom opp var på 50-tallet

182
00:07:56,870 --> 00:08:00,780
var filsystemet og
Utviklingen av direktetilgangs lagring.

183
00:08:00,780 --> 00:08:02,050
Dette var vakkert.

184
00:08:02,050 --> 00:08:06,230
Nå, alle plutselig, kan vi sette vår
filer hvor som helst på disse harddisker

185
00:08:06,230 --> 00:08:09,760
og vi får tilgang til denne informasjonen tilfeldig.

186
00:08:09,760 --> 00:08:11,950
Vi kan analysere det
informasjon ut av filer.

187
00:08:11,950 --> 00:08:14,920
Og vi løste all verdens
problemer med databehandling.

188
00:08:14,920 --> 00:08:17,550
>> Og det varte omtrent 20 eller
30 år inntil utviklingen

189
00:08:17,550 --> 00:08:22,100
av relasjonsdatabasen, som
er når verden vi bestemte oss nå

190
00:08:22,100 --> 00:08:27,940
trenger å ha et depot som nederlagene
bre av data på tvers av filen

191
00:08:27,940 --> 00:08:29,540
systemer som vi har bygget. Høyre?

192
00:08:29,540 --> 00:08:34,270
For mye data fordelt på for mange
stedene, de-duplisering av data,

193
00:08:34,270 --> 00:08:37,120
og kostnadene for lagring var enorm.

194
00:08:37,120 --> 00:08:43,760
>> På 70-tallet, den dyreste ressursen
at en datamaskin hadde var lagring.

195
00:08:43,760 --> 00:08:46,200
Prosessoren var
sett på som en fast kostnad.

196
00:08:46,200 --> 00:08:49,030
Når jeg kjøper boksen,
CPU gjør noe arbeid.

197
00:08:49,030 --> 00:08:51,960
Det kommer til å spinne om
det er faktisk fungerer eller ikke.

198
00:08:51,960 --> 00:08:53,350
Det er virkelig en sunk cost.

199
00:08:53,350 --> 00:08:56,030
>> Men det kostet meg som en
virksomhet er lagring.

200
00:08:56,030 --> 00:09:00,020
Hvis jeg må kjøpe flere disker neste
måned, det er en reell kostnad som jeg betaler.

201
00:09:00,020 --> 00:09:01,620
Og at lagring er dyrt.

202
00:09:01,620 --> 00:09:05,020
>> Nå er vi raske frem 40 år
og vi har et annet problem.

203
00:09:05,020 --> 00:09:10,020
Den databehandlings er nå
dyreste ressurs.

204
00:09:10,020 --> 00:09:11,470
Lagringen er billig.

205
00:09:11,470 --> 00:09:14,570
Jeg mener, vi kan gå hvor som helst på
sky og vi kan finne billig lagring.

206
00:09:14,570 --> 00:09:17,190
Men det jeg finner ikke er billig beregne.

207
00:09:17,190 --> 00:09:20,700
>> Så utviklingen av dagens
teknologi, database teknologi,

208
00:09:20,700 --> 00:09:23,050
er veldig fokusert rundt
distribuerte databaser

209
00:09:23,050 --> 00:09:26,960
som ikke lider av
den samme type målestokk

210
00:09:26,960 --> 00:09:29,240
begrensninger av relasjonsdatabaser.

211
00:09:29,240 --> 00:09:32,080
Vi skal snakke litt om
hva det egentlig betyr.

212
00:09:32,080 --> 00:09:34,760
>> Men en av grunnene og
driveren bak dette-- vi

213
00:09:34,760 --> 00:09:38,290
snakket om data press.

214
00:09:38,290 --> 00:09:41,920
Data trykket er noe
som driver innovasjon.

215
00:09:41,920 --> 00:09:44,610
Og hvis du ser på over
de siste fem årene,

216
00:09:44,610 --> 00:09:48,180
Dette er et diagram av det data
lasten over den generelle bedriften

217
00:09:48,180 --> 00:09:49,640
ser ut i de siste fem årene.

218
00:09:49,640 --> 00:09:52,570
>> Og den generelle tommelfingerregel
disse days-- hvis du går Google--

219
00:09:52,570 --> 00:09:55,290
er 90% av de data som
vi lagrer i dag, og det var

220
00:09:55,290 --> 00:09:57,330
generert i løpet av de siste to årene.

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

222
00:09:57,911 --> 00:09:59,410
Nå er ikke dette en trend som er nytt.

223
00:09:59,410 --> 00:10:01,230
Dette er en trend som har vært
gå ut i 100 år.

224
00:10:01,230 --> 00:10:03,438
Helt siden Herman Hollerith
utviklet slag kort,

225
00:10:03,438 --> 00:10:08,040
vi har vært å bygge dataregistre
og samle inn data på fenomenale priser.

226
00:10:08,040 --> 00:10:10,570
>> Så i løpet av de siste 100 årene,
vi har sett denne trenden.

227
00:10:10,570 --> 00:10:11,940
Det kommer ikke til å endre seg.

228
00:10:11,940 --> 00:10:14,789
Fremover kommer vi til å se
dette, hvis ikke en akselererende trend.

229
00:10:14,789 --> 00:10:16,330
Og du kan se hva som ser ut som.

230
00:10:16,330 --> 00:10:23,510
>> Hvis en virksomhet som i 2010 hadde en
terabyte med data til forvaltning,

231
00:10:23,510 --> 00:10:27,080
i dag det betyr at de er
administrerende 6,5 petabyte med data.

232
00:10:27,080 --> 00:10:30,380
Det er 6500 ganger mer data.

233
00:10:30,380 --> 00:10:31,200
Og jeg vet dette.

234
00:10:31,200 --> 00:10:33,292
Jeg jobber med disse virksomhetene hver dag.

235
00:10:33,292 --> 00:10:35,000
Fem år siden, jeg
ville snakke med selskaper

236
00:10:35,000 --> 00:10:38,260
som ville snakke med meg om hva en smerte
det er å administrere terabyte med data.

237
00:10:38,260 --> 00:10:39,700
Og de ville snakke
til meg om hvordan vi ser

238
00:10:39,700 --> 00:10:41,825
at dette er sannsynligvis kommer
å være en eller to petabyte

239
00:10:41,825 --> 00:10:43,030
innen et par år.

240
00:10:43,030 --> 00:10:45,170
>> De samme selskapene
i dag skal jeg møte med,

241
00:10:45,170 --> 00:10:48,100
og de snakker til meg om
Problemet er det å ha styring

242
00:10:48,100 --> 00:10:51,440
tiere, 20 petabyte med data.

243
00:10:51,440 --> 00:10:53,590
Slik at eksplosjonen av
data i industrien

244
00:10:53,590 --> 00:10:56,670
driver den enorme
trenger for bedre løsninger.

245
00:10:56,670 --> 00:11:00,980
Og relasjonsdatabasen er
bare ikke leve opp til etterspørselen.

246
00:11:00,980 --> 00:11:03,490
>> Og så det er en lineær
korrelasjon mellom data press

247
00:11:03,490 --> 00:11:05,210
og teknisk innovasjon.

248
00:11:05,210 --> 00:11:07,780
Historien har vist oss
dette, at over tid,

249
00:11:07,780 --> 00:11:11,090
når volumet av data
som må bearbeides

250
00:11:11,090 --> 00:11:15,490
overskrider kapasiteten til systemet
å behandle det i rimelig tid

251
00:11:15,490 --> 00:11:18,870
eller til en rimelig pris,
deretter ny teknologi

252
00:11:18,870 --> 00:11:21,080
er oppfunnet for å løse disse problemene.

253
00:11:21,080 --> 00:11:24,090
De nye teknologier,
i sin tur åpner døren

254
00:11:24,090 --> 00:11:27,840
til et annet sett med problemer, noe
samler enda mer data.

255
00:11:27,840 --> 00:11:29,520
>> Nå er vi ikke kommer til å stoppe dette.

256
00:11:29,520 --> 00:11:30,020
Høyre?

257
00:11:30,020 --> 00:11:31,228
Vi kommer ikke til å stoppe dette.

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

259
00:11:31,830 --> 00:11:35,520
Fordi du ikke kan vite alt
det er å vite i universet.

260
00:11:35,520 --> 00:11:40,510
Og så lenge vi har vært i live,
Gjennom historien til mannen,

261
00:11:40,510 --> 00:11:43,440
Vi har alltid drevet å vite mer.

262
00:11:43,440 --> 00:11:49,840
>> Så det virker som at hver tomme vi flytter
nedover stien av vitenskapelige funn,

263
00:11:49,840 --> 00:11:54,620
vi multiplisere mengden av data
at vi trenger å behandle eksponentielt

264
00:11:54,620 --> 00:11:59,920
som vi avdekke mer og mer og mer
om den interne driften av livet,

265
00:11:59,920 --> 00:12:04,530
om hvordan universet fungerer, om
drive vitenskapelig oppdagelse,

266
00:12:04,530 --> 00:12:06,440
og oppfinnelsen at
vi gjør i dag.

267
00:12:06,440 --> 00:12:09,570
Volumet av data bare
øker stadig.

268
00:12:09,570 --> 00:12:12,120
Så å være i stand til å håndtere
dette problemet er enormt.

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

270
00:12:14,790 --> 00:12:17,410
>> Så en av de tingene
vi ser så hvorfor NoSQL?

271
00:12:17,410 --> 00:12:19,200
Hvordan NoSQL løse dette problemet?

272
00:12:19,200 --> 00:12:24,980
Vel, relasjonsdatabaser,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- det er egentlig en konstruksjon av
relasjons database-- disse tingene er

274
00:12:28,600 --> 00:12:30,770
optimalisert for lagring.

275
00:12:30,770 --> 00:12:33,180
>> Tilbake på 70-tallet, igjen,
disk er dyrt.

276
00:12:33,180 --> 00:12:36,990
Klargjørings utøvelse av lagring
i bedriften tar aldri slutt.

277
00:12:36,990 --> 00:12:37,490
Jeg vet.

278
00:12:37,490 --> 00:12:38,020
Jeg levde det.

279
00:12:38,020 --> 00:12:41,250
Jeg skrev lagringsdrivere for en
enterprised superserver selskap

280
00:12:41,250 --> 00:12:42,470
tilbake på 90-tallet.

281
00:12:42,470 --> 00:12:45,920
Og bunnlinjen er reoler annen
lagringsarray var bare noe som

282
00:12:45,920 --> 00:12:47,600
skjedde hver dag i bedriften.

283
00:12:47,600 --> 00:12:49,030
Og det har aldri stoppet.

284
00:12:49,030 --> 00:12:52,690
Høyere tetthet lagring, etterspørsel
for høy tetthet lagring,

285
00:12:52,690 --> 00:12:56,340
og for mer effektiv lagring
devices-- det har aldri stoppet.

286
00:12:56,340 --> 00:13:00,160
>> Og NoSQL er en stor teknologi
fordi det normaliserer dataene.

287
00:13:00,160 --> 00:13:02,210
Det de-dupliserer data.

288
00:13:02,210 --> 00:13:07,180
Det setter dataene i en struktur som
er agnostiker til hver tilgang mønster.

289
00:13:07,180 --> 00:13:11,600
Flere applikasjoner kan treffe som
SQL database, kjøre ad hoc-spørringer,

290
00:13:11,600 --> 00:13:15,950
og få data i den form som de
trenger å behandle for sine arbeidsoppgaver.

291
00:13:15,950 --> 00:13:17,570
Det høres fantastisk.

292
00:13:17,570 --> 00:13:21,350
Men bunnlinjen er med noen
system, hvis det er agnostiker til alt,

293
00:13:21,350 --> 00:13:23,500
den er optimalisert for ingenting.

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

295
00:13:24,050 --> 00:13:26,386
>> Og det er det vi får med
relasjonsdatabasen.

296
00:13:26,386 --> 00:13:27,510
Det er optimalisert for lagring.

297
00:13:27,510 --> 00:13:28,280
Det er normalisert.

298
00:13:28,280 --> 00:13:29,370
Det er relasjonell.

299
00:13:29,370 --> 00:13:31,660
Den støtter ad hoc-spørringer.

300
00:13:31,660 --> 00:13:34,000
Og det og det skalerer vertikalt.

301
00:13:34,000 --> 00:13:39,030
>> Hvis jeg trenger å få en større SQL database
eller en kraftigere SQL database,

302
00:13:39,030 --> 00:13:41,090
Jeg går kjøpe et større stykke jern.

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

304
00:13:41,600 --> 00:13:44,940
Jeg har jobbet med en rekke kunder
som har vært gjennom store oppgraderinger

305
00:13:44,940 --> 00:13:48,340
i sin SQL bare Infrastruktur
å finne ut seks måneder senere,

306
00:13:48,340 --> 00:13:49,750
de treffer veggen igjen.

307
00:13:49,750 --> 00:13:55,457
Og svaret fra Oracle eller MSSQL
eller noen andre er å få en større boks.

308
00:13:55,457 --> 00:13:58,540
Vel før eller senere, kan du ikke kjøpe en
større boks, og det er reelt problem.

309
00:13:58,540 --> 00:14:00,080
Vi må faktisk endre ting.

310
00:14:00,080 --> 00:14:01,080
Så hvor kommer dette arbeidet?

311
00:14:01,080 --> 00:14:06,560
Det fungerer bra for offline
analytics, OLAP-type arbeidsoppgaver.

312
00:14:06,560 --> 00:14:08,670
Og det er egentlig der SQL tilhører.

313
00:14:08,670 --> 00:14:12,540
Nå er det som brukes i dag i mange online
transaksjonsbehandling-type

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

315
00:14:13,330 --> 00:14:16,460
Og det fungerer helt fint på
noen grad av utnyttelse,

316
00:14:16,460 --> 00:14:18,670
men det bare ikke skalere
den måten at NoSQL gjør.

317
00:14:18,670 --> 00:14:20,660
Og vi skal snakke litt
litt om hvorfor det er.

318
00:14:20,660 --> 00:14:23,590
>> Nå, NoSQL, på den annen side,
er mer optimalisert for compute.

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

320
00:14:24,540 --> 00:14:26,830
Det er ikke agnostiker til
tilgangen mønster.

321
00:14:26,830 --> 00:14:31,620
Er det vi kaller de-normalisert
struktur eller en hierarkisk struktur.

322
00:14:31,620 --> 00:14:35,000
Dataene i en relasjonsdatabase er
sluttet seg sammen fra flere tabeller

323
00:14:35,000 --> 00:14:36,850
å produsere den oppfatning at du trenger.

324
00:14:36,850 --> 00:14:40,090
Dataene i en NoSQL database
lagres i et dokument

325
00:14:40,090 --> 00:14:42,100
inneholder den hierarkiske strukturen.

326
00:14:42,100 --> 00:14:45,670
Alle de data som normalt ville bli
sluttet seg sammen for å produsere denne visningen

327
00:14:45,670 --> 00:14:47,160
er lagret i et enkelt dokument.

328
00:14:47,160 --> 00:14:50,990
Og vi skal snakke litt om
hvordan det fungerer i et par diagrammer.

329
00:14:50,990 --> 00:14:55,320
>> Men ideen her er at du lagrer
dataene som disse instansiert utsikt.

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

331
00:14:56,410 --> 00:14:58,610
Du skalere horisontalt.

332
00:14:58,610 --> 00:14:59,556
Høyre?

333
00:14:59,556 --> 00:15:02,100
Hvis jeg trenger å øke
størrelsen på min NoSQL klyngen,

334
00:15:02,100 --> 00:15:03,700
Jeg trenger ikke å få en større boks.

335
00:15:03,700 --> 00:15:05,200
Jeg får en annen boks.

336
00:15:05,200 --> 00:15:07,700
Og jeg cluster dem sammen,
og jeg kan glasskår som data.

337
00:15:07,700 --> 00:15:10,780
Vi skal snakke litt om
hva sharding er, for å bli

338
00:15:10,780 --> 00:15:14,270
stand til å skalere den databasen
tvers av flere fysiske enheter

339
00:15:14,270 --> 00:15:18,370
og fjerne barrieren som
krever meg å skalere vertikalt.

340
00:15:18,370 --> 00:15:22,080
>> Så det er egentlig bygget for online
transaksjonsbehandling og skala.

341
00:15:22,080 --> 00:15:25,480
Det er en stor forskjell
her mellom rapportering, ikke sant?

342
00:15:25,480 --> 00:15:27,810
Rapportering, jeg vet ikke det
spørsmål jeg kommer til å spørre.

343
00:15:27,810 --> 00:15:28,310
Høyre?

344
00:15:28,310 --> 00:15:30,570
Reporting-- hvis noen fra
min markedsavdelingen

345
00:15:30,570 --> 00:15:34,520
ønsker å just-- hvor mange av mine kunder
har denne spesielle kjennetegn som

346
00:15:34,520 --> 00:15:37,850
kjøpt på denne day-- Jeg vet ikke
hva spørre de kommer til å spørre.

347
00:15:37,850 --> 00:15:39,160
Så jeg trenger å være agnostiker.

348
00:15:39,160 --> 00:15:41,810
>> Nå, i en online
transaksjons søknad,

349
00:15:41,810 --> 00:15:43,820
Jeg vet hvilke spørsmål jeg spør.

350
00:15:43,820 --> 00:15:46,581
Jeg bygde søknaden om
en veldig spesifikk arbeidsflyt.

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

352
00:15:47,080 --> 00:15:50,540
Så hvis jeg optimalisere data
lagre for å støtte den arbeidsflyten,

353
00:15:50,540 --> 00:15:52,020
det kommer til å være raskere.

354
00:15:52,020 --> 00:15:55,190
Og det er derfor NoSQL kan
virkelig akselerere levering

355
00:15:55,190 --> 00:15:57,710
av de typer tjenester.

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

357
00:15:58,210 --> 00:16:00,501
>> Så vi kommer til å komme inn
litt teori her.

358
00:16:00,501 --> 00:16:03,330
Og noen av dere, dine øyne
kan rulle tilbake litt.

359
00:16:03,330 --> 00:16:06,936
Men jeg skal prøve å holde det
så høyt nivå som jeg kan.

360
00:16:06,936 --> 00:16:08,880
Så hvis du er i prosjektet
ledelse, er det

361
00:16:08,880 --> 00:16:12,280
en konstruksjon kalt
trekant av begrensninger.

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

363
00:16:12,936 --> 00:16:16,060
Trekanten av begrenser dikterer
du kan ikke ha alt hele tiden.

364
00:16:16,060 --> 00:16:17,750
Kan ikke ha din kaken og spise den også.

365
00:16:17,750 --> 00:16:22,310
Så i prosjektledelse, som trekant
begrensninger er at du kan ha det billig,

366
00:16:22,310 --> 00:16:24,710
du kan ha det raskt,
eller du kan ha det godt.

367
00:16:24,710 --> 00:16:25,716
Plukk to.

368
00:16:25,716 --> 00:16:27,090
Fordi du ikke kan ha alle tre.

369
00:16:27,090 --> 00:16:27,460
Høyre?

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

371
00:16:27,820 --> 00:16:28,920
>> Så du høre om dette mye.

372
00:16:28,920 --> 00:16:31,253
Det er en trippel begrensning,
trekant av triple begrensning,

373
00:16:31,253 --> 00:16:34,420
eller jern trekant er oftentimes--
når du snakker til prosjektledere,

374
00:16:34,420 --> 00:16:35,420
de vil snakke om dette.

375
00:16:35,420 --> 00:16:37,640
Nå, databaser har
sin egen jern trekant.

376
00:16:37,640 --> 00:16:40,350
Og jern trekant av data
er det vi kaller CAP teorem.

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

378
00:16:41,580 --> 00:16:43,770
>> CAP teoremet dikterer
hvordan databaser opererer

379
00:16:43,770 --> 00:16:45,627
under en veldig spesifikk tilstand.

380
00:16:45,627 --> 00:16:47,460
Og vi skal snakke om
hva som tilstanden er.

381
00:16:47,460 --> 00:16:52,221
Men de tre punktene i trekanten,
så å si, er C, konsistens.

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

383
00:16:52,720 --> 00:16:56,760
Så i CAP, betyr konsistens som all
klienter som har tilgang til databasen

384
00:16:56,760 --> 00:16:59,084
vil alltid ha en meget
konsistent visning av data.

385
00:16:59,084 --> 00:17:00,750
Ingens skal se to forskjellige ting.

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

387
00:17:01,480 --> 00:17:04,020
Hvis jeg ser i databasen,
Jeg ser det samme syn

388
00:17:04,020 --> 00:17:06,130
som min partner som ser
den samme databasen.

389
00:17:06,130 --> 00:17:07,470
Det er konsistens.

390
00:17:07,470 --> 00:17:12,099
>> Tilgjengelighet betyr at dersom
database på nettet, hvis det kan nås,

391
00:17:12,099 --> 00:17:14,760
at alle kunder vil alltid
kunne lese og skrive.

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

393
00:17:15,260 --> 00:17:17,010
Så hver klient som
kan lese databasen

394
00:17:17,010 --> 00:17:18,955
vil alltid kunne lese
data og skrive data.

395
00:17:18,955 --> 00:17:21,819
Og hvis det er tilfelle,
det er et tilgjengelig system.

396
00:17:21,819 --> 00:17:24,230
>> Og det tredje punkt er hva
vi kaller partisjon toleranse.

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

398
00:17:24,730 --> 00:17:28,160
Partition toleranse midler
at systemet fungerer godt

399
00:17:28,160 --> 00:17:32,000
til tross for fysisk nettverk
skillevegger mellom nodene.

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

401
00:17:32,760 --> 00:17:36,270
Så noder i klyngen kan ikke
snakke med hverandre, hva skjer?

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

403
00:17:36,880 --> 00:17:39,545
>> Så relasjonsdatabaser choose--
du kan plukke to av disse.

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

405
00:17:40,045 --> 00:17:43,680
Så relasjonsdatabaser velge
å være konsekvent og tilgjengelig.

406
00:17:43,680 --> 00:17:47,510
Hvis partisjonen som skjer mellom
de DataNodes i datalageret,

407
00:17:47,510 --> 00:17:48,831
databasen krasjer.

408
00:17:48,831 --> 00:17:49,330
Høyre?

409
00:17:49,330 --> 00:17:50,900
Det går bare ned.

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

411
00:17:51,450 --> 00:17:54,230
>> Og dette er grunnen til at de har
å vokse med større bokser.

412
00:17:54,230 --> 00:17:54,730
Høyre?

413
00:17:54,730 --> 00:17:58,021
Fordi det er no-- vanligvis, en klynge
database, er det ikke så veldig mange av dem

414
00:17:58,021 --> 00:17:59,590
som opererer på den måten.

415
00:17:59,590 --> 00:18:03,019
Men de fleste databaser skalere
vertikalt i en enkelt boks.

416
00:18:03,019 --> 00:18:05,060
Fordi de trenger å bli
konsekvent og tilgjengelig.

417
00:18:05,060 --> 00:18:10,320
Hvis en skillevegg skulle injiseres,
så du må gjøre et valg.

418
00:18:10,320 --> 00:18:13,720
Du må foreta et valg mellom
være konsekvent og tilgjengelig.

419
00:18:13,720 --> 00:18:16,080
>> Og det er det NoSQL-databaser gjør.

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

421
00:18:16,580 --> 00:18:20,950
Så en NoSQL database, det
kommer i to utgaver.

422
00:18:20,950 --> 00:18:22,990
Vi have-- vel, det
kommer i mange varianter,

423
00:18:22,990 --> 00:18:26,140
men det kommer med to grunnleggende
characteristics-- hva

424
00:18:26,140 --> 00:18:30,050
vi vil kalle CP database, eller en
konsekvent og partisjon toleranse

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

426
00:18:31,040 --> 00:18:34,930
Disse gutta gjør valget at når
nodene miste kontakten med hverandre,

427
00:18:34,930 --> 00:18:37,091
Vi kommer ikke til å tillate
folk til å skrive noe mer.

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

429
00:18:37,590 --> 00:18:41,855
>> Inntil denne partisjonen er fjernet,
skrivetilgang blokkert.

430
00:18:41,855 --> 00:18:43,230
Det betyr at de ikke er tilgjengelige.

431
00:18:43,230 --> 00:18:44,510
De er konsekvent.

432
00:18:44,510 --> 00:18:46,554
Når vi ser at
partisjon injisere seg selv,

433
00:18:46,554 --> 00:18:48,470
vi er nå konsekvent,
fordi vi ikke kommer

434
00:18:48,470 --> 00:18:51,517
for å tillate dataendring på to
sider av skilleveggen uavhengig

435
00:18:51,517 --> 00:18:52,100
fra hverandre.

436
00:18:52,100 --> 00:18:54,130
Vi blir nødt til å
reetablere kommunikasjon

437
00:18:54,130 --> 00:18:56,930
før noen oppdatering til
dataene er tillatt.

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

439
00:18:58,120 --> 00:19:02,650
>> Den neste Smaken ville være en AP system,
eller en tilgjengelig og partisjonert

440
00:19:02,650 --> 00:19:03,640
toleranse system.

441
00:19:03,640 --> 00:19:05,320
Disse gutta ikke bryr seg.

442
00:19:05,320 --> 00:19:06,020
Høyre?

443
00:19:06,020 --> 00:19:08,960
Enhver node som får en
skrive, vi tar det.

444
00:19:08,960 --> 00:19:11,480
Så jeg replikere min data
tvers av flere noder.

445
00:19:11,480 --> 00:19:14,730
Disse nodene får en klient, kommer kunden
i, sier, kommer jeg til å skrive noen data.

446
00:19:14,730 --> 00:19:16,300
Node sier, ikke noe problem.

447
00:19:16,300 --> 00:19:18,580
Noden ved siden av ham får
en skrive på den samme posten,

448
00:19:18,580 --> 00:19:20,405
han kommer til å si noe problem.

449
00:19:20,405 --> 00:19:23,030
Et sted tilbake på bakenden,
at data kommer til å gjenskape.

450
00:19:23,030 --> 00:19:27,360
Og så noen kommer til å realisere,
uh-oh, de system vil innse, uh-oh,

451
00:19:27,360 --> 00:19:28,870
det har vært en oppdatering til to sider.

452
00:19:28,870 --> 00:19:30,370
Hva skal vi gjøre?

453
00:19:30,370 --> 00:19:33,210
Og hva de gjør så er
de gjør noe som

454
00:19:33,210 --> 00:19:36,080
tillater dem å løse disse dataene staten.

455
00:19:36,080 --> 00:19:39,000
Og vi skal snakke om
at i neste figur.

456
00:19:39,000 --> 00:19:40,000
>> Ting å påpeke her.

457
00:19:40,000 --> 00:19:42,374
Og jeg kommer ikke til å bli for
mye inn i dette, fordi denne

458
00:19:42,374 --> 00:19:43,510
kommer inn dypt data teori.

459
00:19:43,510 --> 00:19:46,670
Men det er en transaksjons
rammeverk som

460
00:19:46,670 --> 00:19:50,680
kjører i en relasjonssystem som
tillater meg å trygt gjøre oppdateringer

461
00:19:50,680 --> 00:19:53,760
til flere enheter i databasen.

462
00:19:53,760 --> 00:19:58,320
Og disse oppdateringene vil skje
alt på en gang, eller ikke i det hele tatt.

463
00:19:58,320 --> 00:20:00,500
Og dette kalles ACID transaksjoner.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID gir oss atomicity, konsistens,
isolasjon og holdbarhet.

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

467
00:20:07,070 --> 00:20:13,550
Det betyr at atom, transaksjoner, alle
mine oppdateringer enten skje eller de ikke.

468
00:20:13,550 --> 00:20:16,570
Konsistens betyr at
Databasen vil alltid

469
00:20:16,570 --> 00:20:19,780
bli brakt til en konsekvent
tilstand etter en oppdatering.

470
00:20:19,780 --> 00:20:23,900
Jeg vil aldri forlate databasen i en
dårlig tilstand etter bruk av en oppdatering.

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

472
00:20:24,400 --> 00:20:26,720
>> Så det er litt annerledes
enn CAP konsistens.

473
00:20:26,720 --> 00:20:29,760
CAP konsistens betyr all min
klienter kan alltid se dataene.

474
00:20:29,760 --> 00:20:34,450
ACID konsistens betyr at når
en transaksjon er gjort, data er bra.

475
00:20:34,450 --> 00:20:35,709
Mine relasjoner er alt bra.

476
00:20:35,709 --> 00:20:38,750
Jeg kommer ikke til å slette en forelder rad
og la en haug med foreldreløse barn

477
00:20:38,750 --> 00:20:40,970
i en annen tabell.

478
00:20:40,970 --> 00:20:44,320
Det kan ikke skje hvis jeg er konsekvent
i et surt transaksjon.

479
00:20:44,320 --> 00:20:49,120
>> Isolasjon betyr at transaksjoner
vil alltid forekomme etter hverandre.

480
00:20:49,120 --> 00:20:51,920
Sluttresultatet av data
vil være den samme tilstanden

481
00:20:51,920 --> 00:20:54,770
som om disse transaksjonene
som ble utgitt samtidig

482
00:20:54,770 --> 00:20:57,340
ble henrettet serielt.

483
00:20:57,340 --> 00:21:00,030
Så det er samtidighet
kontroll i databasen.

484
00:21:00,030 --> 00:21:04,130
Så i utgangspunktet, jeg kan ikke øke den
samme verdi to ganger med to operasjoner.

485
00:21:04,130 --> 00:21:08,580
>> Men hvis jeg sier legge en til denne verdien,
og to transaksjoner kommer i

486
00:21:08,580 --> 00:21:10,665
og prøve å gjøre det, man er
skal komme dit først

487
00:21:10,665 --> 00:21:12,540
og den andre ens
kommer til å få det etter.

488
00:21:12,540 --> 00:21:15,210
Så til slutt, la jeg to.

489
00:21:15,210 --> 00:21:16,170
Du skjønner hva jeg mener?

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
>> Holdbarheten er ganske grei.

493
00:21:21,250 --> 00:21:23,460
Når transaksjonen
er anerkjent, er det

494
00:21:23,460 --> 00:21:26,100
kommer til å være der selv
hvis systemet krasjer.

495
00:21:26,100 --> 00:21:29,230
Når dette systemet gjenoppretter, som
transaksjon som ble begått

496
00:21:29,230 --> 00:21:30,480
faktisk kommer til å være der.

497
00:21:30,480 --> 00:21:33,130
Så det er de garantier
av syre transaksjoner.

498
00:21:33,130 --> 00:21:35,470
De er ganske fine garantier
å ha på en database,

499
00:21:35,470 --> 00:21:36,870
men de kommer på som koster.

500
00:21:36,870 --> 00:21:37,640
Høyre?

501
00:21:37,640 --> 00:21:40,520
>> Fordi problemet
med dette rammeverket er

502
00:21:40,520 --> 00:21:44,540
hvis det er en skillevegg i data
sett, jeg må ta en beslutning.

503
00:21:44,540 --> 00:21:48,000
Jeg er nødt til å tillate
oppdateringer på den ene siden eller den andre.

504
00:21:48,000 --> 00:21:50,310
Og hvis det skjer,
da er jeg ikke lenger kommer

505
00:21:50,310 --> 00:21:52,630
å være i stand til å opprettholde
disse egenskapene.

506
00:21:52,630 --> 00:21:53,960
De vil ikke være konsekvent.

507
00:21:53,960 --> 00:21:55,841
De vil ikke bli isolert.

508
00:21:55,841 --> 00:21:58,090
Det er der det bryter ned
for relasjonsdatabaser.

509
00:21:58,090 --> 00:22:01,360
Dette er grunnen til relasjons
databaser skalere vertikalt.

510
00:22:01,360 --> 00:22:05,530
>> På den annen side har vi
det som kalles BASE-teknologi.

511
00:22:05,530 --> 00:22:07,291
Og disse er dine NoSQL-databaser.

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

513
00:22:07,790 --> 00:22:10,180
Så vi har vår CP, AP databaser.

514
00:22:10,180 --> 00:22:14,720
Og dette er hva du kaller utgangspunktet
tilgjengelig, myk tilstand, til slutt

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

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

517
00:22:16,420 --> 00:22:19,690
>> I utgangspunktet tilgjengelig, fordi
de er partisjon tolerant.

518
00:22:19,690 --> 00:22:21,470
De vil alltid bli
der, selv om det er

519
00:22:21,470 --> 00:22:23,053
et nettverk skillevegg mellom nodene.

520
00:22:23,053 --> 00:22:25,900
Hvis jeg kan snakke med en node, er jeg
skal være i stand til å lese data.

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

522
00:22:26,460 --> 00:22:30,810
Jeg kan ikke alltid være i stand til å skrive
data om jeg er en konsekvent plattform.

523
00:22:30,810 --> 00:22:32,130
Men jeg vil være i stand til å lese data.

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

525
00:22:34,960 --> 00:22:38,010
>> Den myke tilstand indikerer
at når jeg leste at data,

526
00:22:38,010 --> 00:22:40,790
det kan ikke være det samme som andre noder.

527
00:22:40,790 --> 00:22:43,390
Hvis en rett ble utstedt på en node
et annet sted i klyngen

528
00:22:43,390 --> 00:22:46,650
og det har ikke kopiert over
klynge ennå da jeg leste at data,

529
00:22:46,650 --> 00:22:48,680
at staten ikke kan være konsekvent.

530
00:22:48,680 --> 00:22:51,650
Imidlertid vil det bli
slutt konsekvent,

531
00:22:51,650 --> 00:22:53,870
noe som betyr at når en skrive
Det vises til systemet

532
00:22:53,870 --> 00:22:56,480
Det vil gjenskape tvers nodene.

533
00:22:56,480 --> 00:22:59,095
Og til slutt, at staten
vil bli brakt i orden,

534
00:22:59,095 --> 00:23:00,890
og det vil være en konsistent tilstand.

535
00:23:00,890 --> 00:23:05,000
>> Nå CAP teorem virkelig
spiller bare i én betingelse.

536
00:23:05,000 --> 00:23:08,700
Denne tilstand er når dette skjer.

537
00:23:08,700 --> 00:23:13,710
Fordi når det er drift i
normal modus, er det ingen partisjon,

538
00:23:13,710 --> 00:23:16,370
alt er konsekvent og tilgjengelig.

539
00:23:16,370 --> 00:23:19,990
Du bare bekymre CAP
når vi har den partisjonen.

540
00:23:19,990 --> 00:23:21,260
Så de er sjeldne.

541
00:23:21,260 --> 00:23:25,360
Men hvordan systemet reagerer når de
oppstår diktere hva slags system

542
00:23:25,360 --> 00:23:26,750
vi arbeider med.

543
00:23:26,750 --> 00:23:31,110
>> Så la oss ta en titt på hva
som ser ut som for AP systemer.

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

545
00:23:32,621 --> 00:23:34,830
AP systemer kommer i to varianter.

546
00:23:34,830 --> 00:23:38,514
De kommer i smaken som er en
herre master, 100%, alltid tilgjengelig.

547
00:23:38,514 --> 00:23:40,430
Og de kommer i
annen smaken, som sier:

548
00:23:40,430 --> 00:23:43,330
vet du hva, jeg kommer til å bekymre
om dette partisjone ting

549
00:23:43,330 --> 00:23:44,724
når en faktisk partisjon oppstår.

550
00:23:44,724 --> 00:23:47,890
Ellers kommer det til å være primær
noder som kommer til å ta rettighetene.

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

552
00:23:48,500 --> 00:23:50,040
>> Så hvis vi noe sånt som Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra ville være en mester
master, lar meg skrive til enhver node.

554
00:23:54,440 --> 00:23:55,540
Så hva skjer?

555
00:23:55,540 --> 00:23:58,270
Så jeg har et objekt i
database som eksisterer på to noder.

556
00:23:58,270 --> 00:24:01,705
La oss kalle dette objektet S.
Så vi har staten for S.

557
00:24:01,705 --> 00:24:04,312
Vi har noen operasjoner
på S som er pågående.

558
00:24:04,312 --> 00:24:06,270
Cassandra tillater meg å
skrive til flere noder.

559
00:24:06,270 --> 00:24:08,550
Så la oss si jeg får en
skrive for s til to noder.

560
00:24:08,550 --> 00:24:12,274
Vel, hva som ender opp som skjer er
Vi kaller det en partisjone hendelsen.

561
00:24:12,274 --> 00:24:14,190
Det kan ikke være en
fysisk nettverk partisjon.

562
00:24:14,190 --> 00:24:15,950
Men på grunn av utformingen
av systemet, er det

563
00:24:15,950 --> 00:24:18,449
faktisk partisjonering så snart
som jeg får en skrive på to noder.

564
00:24:18,449 --> 00:24:20,830
Det er ikke å tvinge meg til
skrive alt gjennom én node.

565
00:24:20,830 --> 00:24:22,340
Jeg skriver på to noder.

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

567
00:24:23,330 --> 00:24:25,740
>> Så nå har jeg to stater.

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

569
00:24:26,360 --> 00:24:28,110
Hva kommer til å skje
er før eller senere,

570
00:24:28,110 --> 00:24:29,960
det kommer til å bli en replikering hendelse.

571
00:24:29,960 --> 00:24:33,300
Det kommer til å bli det vi
kalles en partisjon utvinning, som

572
00:24:33,300 --> 00:24:35,200
er hvor disse to
landene kommer sammen igjen

573
00:24:35,200 --> 00:24:37,310
og det kommer til å bli en algoritme
som går inne i databasen,

574
00:24:37,310 --> 00:24:38,540
bestemmer hva du skal gjøre.

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

576
00:24:39,110 --> 00:24:43,057
Som standard, siste oppdatering
vinner i de fleste AP systemer.

577
00:24:43,057 --> 00:24:44,890
Så det er vanligvis en
standard algoritme, hva

578
00:24:44,890 --> 00:24:47,400
de kaller en tilbakeringing
funksjon, noe

579
00:24:47,400 --> 00:24:51,000
vil bli kalt når denne tilstanden
detekteres for å utføre noen logikk

580
00:24:51,000 --> 00:24:52,900
å løse den konflikten.

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

582
00:24:53,850 --> 00:24:58,770
Standardtilbakeringing og standard
resolver i de fleste AP databaser

583
00:24:58,770 --> 00:25:01,130
er, gjett hva, vinner tidsstempel.

584
00:25:01,130 --> 00:25:02,380
Dette var den siste oppdateringen.

585
00:25:02,380 --> 00:25:04,320
Jeg kommer til å sette det oppdatering i det.

586
00:25:04,320 --> 00:25:08,440
Jeg kan dumpe denne posten at jeg
dumpet ut i en recovery log

587
00:25:08,440 --> 00:25:11,670
slik at brukeren kan komme tilbake senere
og si hei, det var en kollisjon.

588
00:25:11,670 --> 00:25:12,320
Hva skjedde?

589
00:25:12,320 --> 00:25:16,370
Og du kan faktisk dumpe en registrering av
alle kollisjoner og rollbacks

590
00:25:16,370 --> 00:25:17,550
og se hva som skjer.

591
00:25:17,550 --> 00:25:21,580
>> Nå, som en bruker, kan du også
inkludere logikk i at tilbakeringing.

592
00:25:21,580 --> 00:25:24,290
Så du kan endre det
tilbakeringing drift.

593
00:25:24,290 --> 00:25:26,730
Du kan si, hei, jeg vil ha
å avhjelpe disse dataene.

594
00:25:26,730 --> 00:25:28,880
Og jeg ønsker å prøve og
flette disse to postene.

595
00:25:28,880 --> 00:25:30,050
Men det er opp til deg.

596
00:25:30,050 --> 00:25:32,880
Databasen ikke vet hvordan de skal
gjøre det som standard. Mesteparten av tiden,

597
00:25:32,880 --> 00:25:34,850
den eneste databasen
vet hvordan å gjøre er å si,

598
00:25:34,850 --> 00:25:36,100
dette var den siste posten.

599
00:25:36,100 --> 00:25:39,183
Det er den som kommer til å vinne,
og det er verdien jeg kommer til å sette.

600
00:25:39,183 --> 00:25:41,490
Når det partisjon utvinning
og replikering skjer,

601
00:25:41,490 --> 00:25:43,930
vi har vår stat, som
Nå er S prime, som er

602
00:25:43,930 --> 00:25:46,890
flettingen tilstanden til alle disse stedene.

603
00:25:46,890 --> 00:25:49,700
Slik at AP-systemer har dette.

604
00:25:49,700 --> 00:25:51,615
CP-systemer trenger ikke
å bekymre deg for dette.

605
00:25:51,615 --> 00:25:54,490
Fordi så snart en partisjon kommer
inn i bildet, de bare slutte å ta

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

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

608
00:25:56,180 --> 00:25:58,670
Så det er veldig lett å
forholde seg til å være konsekvent

609
00:25:58,670 --> 00:26:01,330
når du ikke godta noen oppdateringer.

610
00:26:01,330 --> 00:26:04,620
Det er med CP systemer gjør.

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

612
00:26:05,120 --> 00:26:07,590
>> Så la oss snakke litt
litt om tilgangs mønstre.

613
00:26:07,590 --> 00:26:11,580
Når vi snakker om NoSQL, er det
handler om tilgang mønster.

614
00:26:11,580 --> 00:26:13,550
Nå er SQL ad hoc, spørringer.

615
00:26:13,550 --> 00:26:14,481
Det er relasjons butikken.

616
00:26:14,481 --> 00:26:16,480
Vi trenger ikke å bekymre deg
om tilgang mønster.

617
00:26:16,480 --> 00:26:17,688
Jeg skriver en svært kompleks spørring.

618
00:26:17,688 --> 00:26:19,250
Det går og får dataene.

619
00:26:19,250 --> 00:26:21,210
Det er hva dette ser
aktig, normalisering.

620
00:26:21,210 --> 00:26:24,890
>> Så i denne strukturen,
vi ser på en produkter katalog.

621
00:26:24,890 --> 00:26:26,640
Jeg har forskjellige typer produkter.

622
00:26:26,640 --> 00:26:27,217
Jeg har bøker.

623
00:26:27,217 --> 00:26:27,800
Jeg har album.

624
00:26:27,800 --> 00:26:30,090
Jeg har videoer.

625
00:26:30,090 --> 00:26:33,370
Forholdet mellom produktene
og en av disse bøker, album,

626
00:26:33,370 --> 00:26:34,860
og videoer tabeller er 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Jeg har en produkt-ID,
og at ID tilsvarer

629
00:26:38,860 --> 00:26:41,080
til en bok, et album eller en video.

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

631
00:26:41,580 --> 00:26:44,350
Det er en 1: 1 forhold
over disse tabellene.

632
00:26:44,350 --> 00:26:46,970
>> Nå books-- alt de
har er rot egenskaper.

633
00:26:46,970 --> 00:26:47,550
Ikke noe problem.

634
00:26:47,550 --> 00:26:48,230
Det er flott.

635
00:26:48,230 --> 00:26:52,130
En-til-en forhold, får jeg alle
dataene jeg trenger å beskrive den boken.

636
00:26:52,130 --> 00:26:54,770
Albums-- album har spor.

637
00:26:54,770 --> 00:26:56,470
Dette er hva vi kaller en til mange.

638
00:26:56,470 --> 00:26:58,905
Hvert album kan ha mange spor.

639
00:26:58,905 --> 00:27:00,780
Så for hvert spor på
albumet, jeg kunne ha

640
00:27:00,780 --> 00:27:02,570
en annen post i dette barnet tabellen.

641
00:27:02,570 --> 00:27:04,680
Så lager jeg en post
i mitt album tabellen.

642
00:27:04,680 --> 00:27:06,700
Jeg opprette flere poster
i spor tabellen.

643
00:27:06,700 --> 00:27:08,850
En-til-mange-relasjon.

644
00:27:08,850 --> 00:27:11,220
>> Dette forholdet er hva
vi kaller mange-til-mange.

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

646
00:27:11,750 --> 00:27:17,000
Du ser at aktører kan være
i mange filmer, mange videoer.

647
00:27:17,000 --> 00:27:21,450
Så det vi gjør er at vi setter denne kartleggingen
bordet mellom dem, som det bare

648
00:27:21,450 --> 00:27:24,040
kartlegger skuespiller ID til video ID.

649
00:27:24,040 --> 00:27:28,464
Nå kan jeg lage en spørring sammenføyningene
videoer gjennom skuespiller video til skuespillere,

650
00:27:28,464 --> 00:27:31,130
og det gir meg en fin liste over
alle filmene og alle aktører

651
00:27:31,130 --> 00:27:32,420
som var i den filmen.

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

653
00:27:33,290 --> 00:27:33,880
Så her vi går.

654
00:27:33,880 --> 00:27:38,040
En-til-en er på øverste nivå
forhold; en-til-mange,

655
00:27:38,040 --> 00:27:40,240
albumene til spor; mange-til-mange.

656
00:27:40,240 --> 00:27:44,990
De er de tre øverste nivå
relasjoner i noen database.

657
00:27:44,990 --> 00:27:48,050
Hvis du vet hvordan de
relasjoner arbeide sammen,

658
00:27:48,050 --> 00:27:51,490
så du vet mye
om database allerede.

659
00:27:51,490 --> 00:27:55,660
Så NoSQL fungerer litt annerledes.

660
00:27:55,660 --> 00:27:58,930
La oss tenke på for andre hva det
Ser ut som å gå får alle mine produkter.

661
00:27:58,930 --> 00:28:01,096
>> I en relasjons butikken, jeg
ønsker å få alle mine produkter

662
00:28:01,096 --> 00:28:02,970
på en liste over alle mine produkter.

663
00:28:02,970 --> 00:28:04,910
Det er en masse spørsmål.

664
00:28:04,910 --> 00:28:07,030
Jeg fikk en forespørsel for alle mine bøker.

665
00:28:07,030 --> 00:28:08,470
Jeg fikk en forespørsel fra mine album.

666
00:28:08,470 --> 00:28:09,970
Og jeg fikk en spørring for alle mine videoer.

667
00:28:09,970 --> 00:28:11,719
Og jeg fikk for å si det
alle sammen i en liste

668
00:28:11,719 --> 00:28:15,250
og serverer den tilbake til
applikasjon som er ber om det.

669
00:28:15,250 --> 00:28:18,000
>> For å få bøkene mine, blir jeg
Produkter og bøker.

670
00:28:18,000 --> 00:28:21,680
For å få mine album, fikk jeg til å bli med
Produkter, Album og spor.

671
00:28:21,680 --> 00:28:25,330
Og for å få videoene mine, jeg har
å bli med produkter til videoer,

672
00:28:25,330 --> 00:28:28,890
delta gjennom skuespiller Videoer,
og bringe i Actors.

673
00:28:28,890 --> 00:28:31,020
Så det er tre spørsmål.

674
00:28:31,020 --> 00:28:34,560
Svært komplekse spørringer til
montere ett resultat sett.

675
00:28:34,560 --> 00:28:36,540
>> Det er mindre enn optimalt.

676
00:28:36,540 --> 00:28:39,200
Dette er grunnen til at når vi snakker
om en datastruktur som er

677
00:28:39,200 --> 00:28:42,900
bygget for å være agnostiker til tilgangs
pattern-- vel det er flott.

678
00:28:42,900 --> 00:28:45,730
Og du kan se dette er virkelig
hyggelig hvordan vi har organisert dataene.

679
00:28:45,730 --> 00:28:46,550
Og vet du hva?

680
00:28:46,550 --> 00:28:49,750
Jeg har bare en rekord for en skuespiller.

681
00:28:49,750 --> 00:28:50,440
>> Det er greit.

682
00:28:50,440 --> 00:28:53,750
Jeg har dedupliserte alle mine skuespillere,
og jeg holdt mine assosiasjoner

683
00:28:53,750 --> 00:28:55,200
i denne kartleggingen tabellen.

684
00:28:55,200 --> 00:29:00,620
Men får de data
ut blir dyrt.

685
00:29:00,620 --> 00:29:04,500
Jeg sender CPU hele systemet
å bli med disse datastrukturer sammen

686
00:29:04,500 --> 00:29:05,950
å være i stand til å trekke den tilbake data.

687
00:29:05,950 --> 00:29:07,310
>> Så hvordan får jeg rundt det?

688
00:29:07,310 --> 00:29:11,200
I NoSQL handler det om
aggregering, ikke normalisering.

689
00:29:11,200 --> 00:29:13,534
Så vi ønsker å si at vi ønsker å
støtter tilgang mønster.

690
00:29:13,534 --> 00:29:15,283
Hvis tilgangsmønsteret
til programmene,

691
00:29:15,283 --> 00:29:16,770
Jeg trenger å få alle mine produkter.

692
00:29:16,770 --> 00:29:19,027
La oss legge alle produktene i én tabell.

693
00:29:19,027 --> 00:29:22,110
Hvis jeg legge alle produktene i én tabell,
Jeg kan bare velge alle produkter

694
00:29:22,110 --> 00:29:23,850
fra det bordet og jeg får det hele tatt.

695
00:29:23,850 --> 00:29:25,240
Vel hvordan gjør jeg det?

696
00:29:25,240 --> 00:29:28,124
Vel i NoSQL det er ingen
Strukturen til bordet.

697
00:29:28,124 --> 00:29:30,540
Vi skal snakke litt om
hvordan dette fungerer i Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Men du trenger ikke ha samme
attributter og de samme egenskapene

699
00:29:33,570 --> 00:29:37,751
i hver enkelt rad, i hver enkelt
element, som du gjør i en SQL-tabell.

700
00:29:37,751 --> 00:29:39,750
Og hva gjør dette for meg
å gjøre er mange ting

701
00:29:39,750 --> 00:29:41,124
og gi meg en stor fleksibilitet.

702
00:29:41,124 --> 00:29:45,360
I dette spesielle tilfelle, jeg
har mine produkt dokumenter.

703
00:29:45,360 --> 00:29:49,090
Og i dette spesielle
eksempel alt

704
00:29:49,090 --> 00:29:51,930
er et dokument i Produkter tabellen.

705
00:29:51,930 --> 00:29:56,510
Og produktet for en bok kanskje
har en type ID som angir en bok.

706
00:29:56,510 --> 00:29:59,180
Og programmet
ville slå på at ID.

707
00:29:59,180 --> 00:30:02,570
>> På programmet tier, jeg kommer
å si oh, hva oppføringstype er dette?

708
00:30:02,570 --> 00:30:04,100
Å, det er en bok posten.

709
00:30:04,100 --> 00:30:05,990
Bokoppføringene har disse egenskapene.

710
00:30:05,990 --> 00:30:08,100
La meg lage en bok objekt.

711
00:30:08,100 --> 00:30:11,289
Så jeg kommer til å fylle
Boken objekt med dette elementet.

712
00:30:11,289 --> 00:30:13,080
Neste element kommer og
sier, hva er dette?

713
00:30:13,080 --> 00:30:14,560
Vel dette elementet er et album.

714
00:30:14,560 --> 00:30:17,340
Åh, jeg fikk en helt annen
behandling rutine for det,

715
00:30:17,340 --> 00:30:18,487
fordi det er et album.

716
00:30:18,487 --> 00:30:19,320
Du skjønner hva jeg mener?

717
00:30:19,320 --> 00:30:21,950
>> Så programmet tier-- jeg
bare velge alle disse postene.

718
00:30:21,950 --> 00:30:23,200
De begynner å komme.

719
00:30:23,200 --> 00:30:24,680
De kunne være alle forskjellige typer.

720
00:30:24,680 --> 00:30:27,590
Og det er programmets logikk
som bytter over de typer

721
00:30:27,590 --> 00:30:29,530
og bestemmer hvordan å behandle dem.

722
00:30:29,530 --> 00:30:33,640
>> Igjen, så vi optimalisere
skjema for tilgangsmønster.

723
00:30:33,640 --> 00:30:36,390
Vi gjør det ved å
kollapser disse tabellene.

724
00:30:36,390 --> 00:30:39,670
Vi er i utgangspunktet tar
disse normaliserte strukturer,

725
00:30:39,670 --> 00:30:42,000
og vi bygger
hierarkiske strukturer.

726
00:30:42,000 --> 00:30:45,130
Inni hver og en av disse postene
Jeg kommer til å se array-egenskaper.

727
00:30:45,130 --> 00:30:49,400
>> Inne i dette dokumentet for Albums,
Jeg ser matriser av låter.

728
00:30:49,400 --> 00:30:53,900
Disse sporene nå become-- det er
utgangspunktet dette barnet tabell som

729
00:30:53,900 --> 00:30:56,520
Det finnes rett her i denne strukturen.

730
00:30:56,520 --> 00:30:57,975
Så du kan gjøre dette i DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Du kan gjøre dette i MongoDB.

732
00:30:59,810 --> 00:31:01,437
Du kan gjøre dette i noen NoSQL database.

733
00:31:01,437 --> 00:31:03,520
Lag disse typene
hierarkiske datastrukturer

734
00:31:03,520 --> 00:31:07,120
som lar deg hente data
svært raskt fordi nå jeg

735
00:31:07,120 --> 00:31:08,537
trenger ikke å samsvare.

736
00:31:08,537 --> 00:31:11,620
Når jeg setter inn en rad inn i Tracks
bord, eller en rad inn i Albums bordet,

737
00:31:11,620 --> 00:31:13,110
Jeg må samsvare med at skjema.

738
00:31:13,110 --> 00:31:18,060
Jeg må ha attributtet eller
Eiendommen som er definert på det bordet.

739
00:31:18,060 --> 00:31:20,480
Hver og en av dem,
når jeg setter den raden.

740
00:31:20,480 --> 00:31:21,910
Det er ikke tilfelle i NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Jeg kan ha helt forskjellig
eiendommer i alle dokumenter

742
00:31:24,440 --> 00:31:26,100
som jeg setter inn i samlingen.

743
00:31:26,100 --> 00:31:30,480
Så veldig kraftig mekanisme.

744
00:31:30,480 --> 00:31:32,852
Og det er egentlig hvordan du
optimalisere systemet.

745
00:31:32,852 --> 00:31:35,310
Fordi nå at søket, i stedet
av å bli med alle disse tabellene

746
00:31:35,310 --> 00:31:39,160
og gjennomføre et halvt dusin forespørsler
å trekke tilbake den data jeg trenger,

747
00:31:39,160 --> 00:31:40,890
Jeg utfører ett søk.

748
00:31:40,890 --> 00:31:43,010
Og jeg gjentar
over de resultater som er.

749
00:31:43,010 --> 00:31:46,512
det gir deg en idé
av kraften i NoSQL.

750
00:31:46,512 --> 00:31:49,470
Jeg kommer til å slags gå sidelengs her
og snakke litt om dette.

751
00:31:49,470 --> 00:31:53,240
Det er flere typer av
markedsføring eller technology--

752
00:31:53,240 --> 00:31:55,660
markedsføring av teknologien
type diskusjon.

753
00:31:55,660 --> 00:31:58,672
Men det er viktig å forstå
fordi hvis vi ser på toppen

754
00:31:58,672 --> 00:32:00,380
her på denne oversikten,
hva vi ser på

755
00:32:00,380 --> 00:32:04,030
er det vi kaller
teknologi hype-kurven.

756
00:32:04,030 --> 00:32:06,121
Og hva dette betyr er
nye ting kommer inn i bildet.

757
00:32:06,121 --> 00:32:07,120
Folk synes det er flott.

758
00:32:07,120 --> 00:32:09,200
Jeg har løst alle mine problemer.

759
00:32:09,200 --> 00:32:11,630
>> Dette kan være slutten
alt, være alt til alt.

760
00:32:11,630 --> 00:32:12,790
Og de begynner å bruke den.

761
00:32:12,790 --> 00:32:14,720
Og de sier, dette ting ikke fungerer.

762
00:32:14,720 --> 00:32:17,600
Dette er ikke riktig.

763
00:32:17,600 --> 00:32:19,105
Den gamle ting var bedre.

764
00:32:19,105 --> 00:32:21,230
Og de går tilbake til å gjøre
ting slik de var.

765
00:32:21,230 --> 00:32:22,730
Og så til slutt
de går, vet du hva?

766
00:32:22,730 --> 00:32:24,040
Dette ting er ikke så ille.

767
00:32:24,040 --> 00:32:26,192
Oh, det er hvordan det fungerer.

768
00:32:26,192 --> 00:32:28,900
Og når de finne ut hvordan det
verk, begynner de å bli bedre.

769
00:32:28,900 --> 00:32:32,050
>> Og det morsomme med det
er det slags linjer opp til hva

770
00:32:32,050 --> 00:32:34,300
vi kaller Technology Adoption Curve.

771
00:32:34,300 --> 00:32:36,910
Så hva skjer er at vi har
en slags teknologi trigger.

772
00:32:36,910 --> 00:32:39,100
I tilfelle av databaser
det er data press.

773
00:32:39,100 --> 00:32:42,200
Vi snakket om de høye vannpunkter
av data press hele tiden.

774
00:32:42,200 --> 00:32:46,310
Når disse dataene trykket treffer en viss
punkt, som er en teknologi trigger.

775
00:32:46,310 --> 00:32:47,830
>> Det begynner å bli for dyrt.

776
00:32:47,830 --> 00:32:49,790
Det tar for lang tid å behandle dataene.

777
00:32:49,790 --> 00:32:50,890
Vi trenger noe bedre.

778
00:32:50,890 --> 00:32:52,890
Du får innovatørene
der ute som kjører rundt,

779
00:32:52,890 --> 00:32:55,050
prøver å finne ut hva som er løsningen.

780
00:32:55,050 --> 00:32:56,050
Hva er den nye ideen?

781
00:32:56,050 --> 00:32:58,170
>> Hva er den nest beste
måten å gjøre dette?

782
00:32:58,170 --> 00:32:59,530
Og de kommer opp med noe.

783
00:32:59,530 --> 00:33:03,140
Og folk med reell smerte,
gutta på blødning kanten,

784
00:33:03,140 --> 00:33:06,390
de vil hoppe over det,
fordi de trenger et svar.

785
00:33:06,390 --> 00:33:09,690
Nå hva uunngåelig happens-- og
det skjer akkurat nå i NoSQL.

786
00:33:09,690 --> 00:33:11,090
Jeg ser det hele tiden.

787
00:33:11,090 --> 00:33:13,610
>> Hva uunngåelig skjer er
folk begynner å bruke det nye verktøyet

788
00:33:13,610 --> 00:33:15,490
på samme måte som de anvendes på gamle verktøyet.

789
00:33:15,490 --> 00:33:17,854
Og de finner ut det
ikke fungerer så godt.

790
00:33:17,854 --> 00:33:20,020
Jeg kan ikke huske hvem jeg var
snakket med tidligere i dag.

791
00:33:20,020 --> 00:33:22,080
Men det er som når
Jackhammer ble oppfunnet,

792
00:33:22,080 --> 00:33:24,621
folk ikke svinge den over
hodet for å knuse betongen.

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

794
00:33:27,360 --> 00:33:30,610
>> Men det er det som er
skjer med NoSQL dag.

795
00:33:30,610 --> 00:33:33,900
Hvis du går inn på de fleste butikker,
de prøver å være NoSQL butikker.

796
00:33:33,900 --> 00:33:36,510
Det de gjør er
de bruker NoSQL,

797
00:33:36,510 --> 00:33:39,900
og de legger det
full av relasjonsskjema.

798
00:33:39,900 --> 00:33:41,630
Fordi det er sånn
de designe databaser.

799
00:33:41,630 --> 00:33:44,046
Og de lurer på, hvorfor er
det ikke presterer godt?

800
00:33:44,046 --> 00:33:45,230
Gutt, stinker denne tingen.

801
00:33:45,230 --> 00:33:49,900
Jeg måtte holde alle mine
tiltrer in-- det er, nei, nei.

802
00:33:49,900 --> 00:33:50,800
Oppretthold tiltrer?

803
00:33:50,800 --> 00:33:52,430
Hvorfor er du bli med data?

804
00:33:52,430 --> 00:33:54,350
Du trenger ikke bli med data i NoSQL.

805
00:33:54,350 --> 00:33:55,850
Du samle det.

806
00:33:55,850 --> 00:34:00,690
>> Så hvis du vil unngå dette, lære
hvordan verktøyet fungerer før du faktisk

807
00:34:00,690 --> 00:34:02,010
begynne å bruke det.

808
00:34:02,010 --> 00:34:04,860
Ikke prøv og bruke de nye verktøyene
samme måte som du brukte de gamle verktøyene.

809
00:34:04,860 --> 00:34:06,500
Du kommer til å ha en dårlig opplevelse.

810
00:34:06,500 --> 00:34:08,848
Og hver eneste gang
det er hva dette handler om.

811
00:34:08,848 --> 00:34:11,389
Når vi begynner å komme opp her,
det er fordi folk har funnet ut

812
00:34:11,389 --> 00:34:13,449
hvordan å bruke verktøyene.

813
00:34:13,449 --> 00:34:16,250
>> De gjorde det samme når
relasjonsdatabaser ble oppfunnet,

814
00:34:16,250 --> 00:34:17,969
og de var erstatte filsystemer.

815
00:34:17,969 --> 00:34:20,420
De prøvde å bygge filsystemer
med relasjonsdatabaser

816
00:34:20,420 --> 00:34:22,159
fordi det er det folk forstått.

817
00:34:22,159 --> 00:34:23,049
Det fungerte ikke.

818
00:34:23,049 --> 00:34:26,090
Så forstå de beste praksis
av teknologien du arbeider med

819
00:34:26,090 --> 00:34:26,730
er enorme.

820
00:34:26,730 --> 00:34:29,870
Veldig viktig.

821
00:34:29,870 --> 00:34:32,440
>> Så vi kommer til å komme inn DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB er AWS s
fullt klarte NoSQL-plattformen.

823
00:34:36,480 --> 00:34:37,719
Hva gjør fullt klarte bety?

824
00:34:37,719 --> 00:34:40,010
Det betyr at du ikke trenger å
virkelig bekymre deg for noe.

825
00:34:40,010 --> 00:34:42,060
>> Du kommer inn, fortelle deg
oss, jeg trenger et bord.

826
00:34:42,060 --> 00:34:43,409
Den trenger dette mye kapasitet.

827
00:34:43,409 --> 00:34:47,300
Du trykker på knappen, og vi bestemmelsen
alle infrastrukturen bak scenen.

828
00:34:47,300 --> 00:34:48,310
Nå som er enorm.

829
00:34:48,310 --> 00:34:51,310
>> Fordi når du snakker
om skalering en database,

830
00:34:51,310 --> 00:34:53,917
NoSQL data klynger på
skala, kjører petabyte,

831
00:34:53,917 --> 00:34:55,750
kjører millioner av
transaksjoner per sekund,

832
00:34:55,750 --> 00:34:58,180
disse tingene er ikke små klynger.

833
00:34:58,180 --> 00:35:00,830
Vi snakker tusenvis av tilfeller.

834
00:35:00,830 --> 00:35:04,480
Administrerende tusenvis av tilfeller
selv virtuelle instanser,

835
00:35:04,480 --> 00:35:06,350
er en reell smerte i baken.

836
00:35:06,350 --> 00:35:09,110
Jeg mener, tenk om hver gang en
operativsystemet patch kommer ut

837
00:35:09,110 --> 00:35:11,552
eller en ny versjon av databasen.

838
00:35:11,552 --> 00:35:13,260
Hva betyr det
til deg operasjonelt?

839
00:35:13,260 --> 00:35:16,330
Det betyr at du fikk 1200
servere som trenger å bli oppdatert.

840
00:35:16,330 --> 00:35:18,960
Nå selv med automatisering,
som kan ta lang tid.

841
00:35:18,960 --> 00:35:21,480
Som kan føre til mye
operative hodepine,

842
00:35:21,480 --> 00:35:23,090
fordi jeg kanskje har tjenester ned.

843
00:35:23,090 --> 00:35:26,070
>> Som jeg oppdatere disse databasene, jeg
kan gjøre blågrønne distribusjoner

844
00:35:26,070 --> 00:35:29,420
hvor jeg distribuere og oppgradere halv min
noder, og deretter oppgradere den andre halvparten.

845
00:35:29,420 --> 00:35:30,490
Ta dem ned.

846
00:35:30,490 --> 00:35:33,410
Så forvalte infrastrukturen
Skalaen er enormt smertefullt.

847
00:35:33,410 --> 00:35:36,210
Og AWS ta smerten ut av det.

848
00:35:36,210 --> 00:35:39,210
Og NoSQL-databaser kan
være usedvanlig smertefull

849
00:35:39,210 --> 00:35:41,780
på grunn av måten de målestokk.

850
00:35:41,780 --> 00:35:42,926
>> Skalere horisontalt.

851
00:35:42,926 --> 00:35:45,550
Hvis du ønsker å få en større NoSQL
database, kjøper du flere noder.

852
00:35:45,550 --> 00:35:48,660
Hver node du kjøper er
en annen operativ hodepine.

853
00:35:48,660 --> 00:35:50,830
Så la noen andre gjøre det for deg.

854
00:35:50,830 --> 00:35:52,000
AWS kan gjøre det.

855
00:35:52,000 --> 00:35:54,587
>> Vi støtter dokumentet sentrale verdier.

856
00:35:54,587 --> 00:35:56,670
Nå vi ikke gå for mye
inn på den andre figuren.

857
00:35:56,670 --> 00:35:58,750
Det er mye forskjellig
smaker av NoSQL.

858
00:35:58,750 --> 00:36:02,670
De er alle slags få
munged sammen på dette punktet.

859
00:36:02,670 --> 00:36:06,260
Du kan se på DynamoDB og si ja,
vi er både et dokument og en nøkkelverdi

860
00:36:06,260 --> 00:36:08,412
lagre dette punktet.

861
00:36:08,412 --> 00:36:10,620
Og du kan argumentere funksjonene
av en over den andre.

862
00:36:10,620 --> 00:36:13,950
For meg er mye av dette virkelig seks
av en halvt dusin av den andre.

863
00:36:13,950 --> 00:36:18,710
Hver og en av disse teknologiene er en
FINE-teknologi og en fin løsning.

864
00:36:18,710 --> 00:36:23,390
Jeg vil ikke si MongoDB er bedre eller
verre enn Couch, så Cassandra,

865
00:36:23,390 --> 00:36:25,994
da Dynamo, eller vice versa.

866
00:36:25,994 --> 00:36:27,285
Jeg mener, dette er bare alternativer.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Det er raskt og det er
konsekvent på noen skala.

869
00:36:32,700 --> 00:36:36,210
Så dette er en av de største
bonuser du får med AWS.

870
00:36:36,210 --> 00:36:40,850
Med DynamoDB er evnen
for å få en lav ensifret

871
00:36:40,850 --> 00:36:44,040
millisekund ventetid på noen skala.

872
00:36:44,040 --> 00:36:45,720
Det var et mål utforming av systemet.

873
00:36:45,720 --> 00:36:49,130
Og vi har kunder som gjør
millioner transaksjoner per sekund.

874
00:36:49,130 --> 00:36:52,670
>> Nå skal jeg gå gjennom noen av de
bruke saker i et par minutter her.

875
00:36:52,670 --> 00:36:55,660
Integrert tilgang control--
har vi det vi kaller

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, eller IAM.

877
00:36:57,920 --> 00:37:01,980
Det gjennomsyrer alle system,
hver tjeneste som AWS tilbyr.

878
00:37:01,980 --> 00:37:03,630
DynamoDB er intet unntak.

879
00:37:03,630 --> 00:37:06,020
Du kan kontrollere tilgangen
til DynamoDB tabeller.

880
00:37:06,020 --> 00:37:09,960
Across all din AWS kontoer ved
definere tilgangsroller og tillatelser

881
00:37:09,960 --> 00:37:12,140
i IAM infrastruktur.

882
00:37:12,140 --> 00:37:16,630
>> Og det er en viktig og integrert komponent i
det vi kaller hendelsesdrevet programmering.

883
00:37:16,630 --> 00:37:19,056
Nå er dette et nytt paradigme.

884
00:37:19,056 --> 00:37:22,080
>> PUBLIKUM: Hvordan er din hastighet på ekte
positive versus falske negativer

885
00:37:22,080 --> 00:37:24,052
på adgangskontrollsystem?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: Sanne positive
versus falske negative?

887
00:37:26,260 --> 00:37:28,785
PUBLIKUM: Retur hva
du bør komme tilbake?

888
00:37:28,785 --> 00:37:33,720
I motsetning til en gang i blant det
kommer ikke tilbake når det skal validere?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: Jeg kunne ikke fortelle deg det.

891
00:37:38,050 --> 00:37:40,140
Hvis det er noen feil
overhodet på det,

892
00:37:40,140 --> 00:37:42,726
Jeg er ikke den personen å spørre
det aktuelle spørsmålet.

893
00:37:42,726 --> 00:37:43,850
Men det er et godt spørsmål.

894
00:37:43,850 --> 00:37:45,905
Jeg vil være glad i å vite
som meg selv, faktisk.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Og så igjen, nye paradigmet
er hendelsesdrevet programmering.

897
00:37:51,320 --> 00:37:55,160
Dette er ideen om at du kan
distribuere komplekse applikasjoner som

898
00:37:55,160 --> 00:37:59,720
kan operere en veldig, veldig høy skala
uten infrastruktur overhodet.

899
00:37:59,720 --> 00:38:02,120
Uten fast
infrastruktur overhodet.

900
00:38:02,120 --> 00:38:04,720
Og vi skal snakke litt
om hva det betyr som vi

901
00:38:04,720 --> 00:38:06,550
komme videre til neste par diagrammer.

902
00:38:06,550 --> 00:38:08,716
>> Det første vi skal gjøre
er vi skal snakke om bord.

903
00:38:08,716 --> 00:38:10,857
API datatyper for Dynamo.

904
00:38:10,857 --> 00:38:13,190
Og det første du vil
legge merke til når du ser på dette,

905
00:38:13,190 --> 00:38:17,930
hvis du er kjent med noen database,
databaser har egentlig to slags APIer

906
00:38:17,930 --> 00:38:18,430
Jeg vil kalle det.

907
00:38:18,430 --> 00:38:21,570
Eller to sett med API.

908
00:38:21,570 --> 00:38:23,840
En av disse ville bli
administrative API.

909
00:38:23,840 --> 00:38:26,710
>> De tingene de tar vare på
funksjoner i databasen.

910
00:38:26,710 --> 00:38:31,340
Konfigurering av lagringsmotoren,
sette opp og legge bordene.

911
00:38:31,340 --> 00:38:35,180
etablering av databasen
kataloger og instanser.

912
00:38:35,180 --> 00:38:40,450
Disse things-- i DynamoDB, du
har svært korte, korte lister.

913
00:38:40,450 --> 00:38:43,120
>> Så med andre databaser,
du kan se dusinvis

914
00:38:43,120 --> 00:38:45,680
av kommandoer, av administrative
kommandoer, for å konfigurere

915
00:38:45,680 --> 00:38:47,290
disse ekstra alternativer.

916
00:38:47,290 --> 00:38:51,234
I DynamoDB du ikke trenger dem fordi
trenger du ikke konfigurere systemet, gjør vi.

917
00:38:51,234 --> 00:38:54,150
Så det eneste du trenger å gjøre er å
Fortell meg hvilken størrelse tabellen trenger jeg.

918
00:38:54,150 --> 00:38:55,660
Så du får en veldig
begrenset sett med kommandoer.

919
00:38:55,660 --> 00:38:58,618
>> Du får en Create Table Update, Table,
Slett tabell, og Beskriv Table.

920
00:38:58,618 --> 00:39:01,150
De er de eneste tingene
du trenger for DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Du trenger ikke en oppbevarings
motorkonfigurasjon.

922
00:39:03,294 --> 00:39:04,960
Jeg trenger ikke å bekymre deg for replikering.

923
00:39:04,960 --> 00:39:06,490
Jeg trenger ikke å bekymre deg sharding.

924
00:39:06,490 --> 00:39:07,800
>> Jeg trenger ikke å bekymre deg
om noen av disse tingene.

925
00:39:07,800 --> 00:39:08,740
Vi gjør alt for deg.

926
00:39:08,740 --> 00:39:11,867
Så det er en enorm mengde overhead
det er bare løftes av tallerkenen din.

927
00:39:11,867 --> 00:39:13,200
Da har vi crud operatører.

928
00:39:13,200 --> 00:39:17,740
CRUD er noe hva vi
ringe i databasen som er

929
00:39:17,740 --> 00:39:19,860
Opprette, oppdatere, slette operatører.

930
00:39:19,860 --> 00:39:24,180
Dette er sunn
databaseoperasjoner.

931
00:39:24,180 --> 00:39:31,299
Ting som put element, får varen, oppdatering
elementer, slette elementer, batch spørring, skanne.

932
00:39:31,299 --> 00:39:32,840
Hvis du ønsker å skanne hele tabellen.

933
00:39:32,840 --> 00:39:34,220
Trekk alt av bordet.

934
00:39:34,220 --> 00:39:37,130
En av de fine tingene om DynamoDB
er det tillater parallell skanning.

935
00:39:37,130 --> 00:39:40,602
Så du kan faktisk la meg vite hvor mange
tråder du ønsker å kjøre på at skanningen.

936
00:39:40,602 --> 00:39:41,810
Og vi kan kjøre disse trådene.

937
00:39:41,810 --> 00:39:43,985
Vi kan spinne som skanner opp
tvers av flere tråder

938
00:39:43,985 --> 00:39:49,060
slik at du kan skanne hele tabellen
plass veldig, veldig fort i DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Den andre API vi har er
det vi kaller vår Streams API.

940
00:39:51,490 --> 00:39:52,940
Vi kommer ikke til å snakke for
mye om dette akkurat nå.

941
00:39:52,940 --> 00:39:55,189
Jeg har fått noen innhold senere
på i dekk om dette.

942
00:39:55,189 --> 00:39:59,910
Men Strømmer er virkelig en running--
Tenk på det som den gang bestilt

943
00:39:59,910 --> 00:40:01,274
og partisjon endringslogg.

944
00:40:01,274 --> 00:40:03,940
Alt som skjer på
tabellen viser opp på strømmen.

945
00:40:03,940 --> 00:40:05,940
>> Hver skrive til bordet
dukker opp på strømmen.

946
00:40:05,940 --> 00:40:08,370
Du kan lese at strøm, og
du kan gjøre ting med den.

947
00:40:08,370 --> 00:40:10,150
Vi skal snakke om hva
typer ting du

948
00:40:10,150 --> 00:40:13,680
gjøre med de tingene som replikering,
skape sekundære indekser.

949
00:40:13,680 --> 00:40:17,620
Alle typer kult
ting du kan gjøre med det.

950
00:40:17,620 --> 00:40:19,150
>> Datatyper.

951
00:40:19,150 --> 00:40:23,320
I DynamoDB støtter vi både nøkkelen
verdi og dokumentere datatyper.

952
00:40:23,320 --> 00:40:26,350
På venstre side av skjermen
her har vi våre grunnleggende typer.

953
00:40:26,350 --> 00:40:27,230
Viktige typer verdi.

954
00:40:27,230 --> 00:40:30,040
Dette er strenger,
tall og binærfiler.

955
00:40:30,040 --> 00:40:31,640
>> Så bare tre grunnleggende typer.

956
00:40:31,640 --> 00:40:33,700
Og så kan du ha sett på dem.

957
00:40:33,700 --> 00:40:37,650
En av de fine tingene om NoSQL er
du kan inneholde arrays som egenskaper.

958
00:40:37,650 --> 00:40:42,050
Og med DynamoDB kan du inneholde arrays
av grunnleggende typer som root eiendom.

959
00:40:42,050 --> 00:40:43,885
>> Og så er det dokumenttypene.

960
00:40:43,885 --> 00:40:45,510
Hvor mange mennesker er kjent med JSON?

961
00:40:45,510 --> 00:40:47,130
Dere er kjent med JSON så mye?

962
00:40:47,130 --> 00:40:49,380
Det er i utgangspunktet Javascript,
Objekt, Notation.

963
00:40:49,380 --> 00:40:52,510
Den lar deg i utgangspunktet
definere en hierarkisk struktur.

964
00:40:52,510 --> 00:40:58,107
>> Du kan lagre en JSON dokument på
DynamoDB bruker felleskomponenter

965
00:40:58,107 --> 00:41:00,940
eller byggesteinene som er tilgjengelige
i de fleste programmeringsspråk.

966
00:41:00,940 --> 00:41:03,602
Så hvis du har Java, er du
se på kart og lister.

967
00:41:03,602 --> 00:41:05,060
Jeg kan lage objekter som området kartet.

968
00:41:05,060 --> 00:41:08,030
Et kart som sentrale verdier
lagres som egenskaper.

969
00:41:08,030 --> 00:41:10,890
Og det kan ha lister over
verdier innenfor disse egenskapene.

970
00:41:10,890 --> 00:41:13,490
Du kan lagre denne komplekse
hierarkisk struktur

971
00:41:13,490 --> 00:41:16,320
som en enkelt attributt
av en DynamoDB element.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Så tabeller i DynamoDB, som de fleste
NoSQL-databaser, tabeller har elementer.

974
00:41:24,460 --> 00:41:26,469
I MongoDB du ville
kalle disse dokumentene.

975
00:41:26,469 --> 00:41:27,760
Og det ville være sofaen basen.

976
00:41:27,760 --> 00:41:28,900
Også en dokumentdatabase.

977
00:41:28,900 --> 00:41:29,941
Du kaller disse dokumentene.

978
00:41:29,941 --> 00:41:32,930
Dokumenter eller elementer har attributter.

979
00:41:32,930 --> 00:41:35,850
Attributter kan eksistere eller
ikke eksisterer på elementet.

980
00:41:35,850 --> 00:41:38,520
I DynamoDB, det er
én obligatorisk attributt.

981
00:41:38,520 --> 00:41:43,880
Akkurat som i en relasjonsdatabase,
du har en primærnøkkel på bordet.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB har det vi kaller en firkanttasten.

983
00:41:46,010 --> 00:41:48,280
Firkanttasten må være unikt.

984
00:41:48,280 --> 00:41:52,580
Så når jeg definerer en hash table,
utgangspunktet hva jeg sier

985
00:41:52,580 --> 00:41:54,110
er hvert element vil ha en firkanttasten.

986
00:41:54,110 --> 00:41:58,520
Og hver firkanttasten må være unikt.

987
00:41:58,520 --> 00:42:01,200
>> Hvert element er definert
av det unike firkanttasten.

988
00:42:01,200 --> 00:42:02,940
Og det kan bare være ett.

989
00:42:02,940 --> 00:42:05,820
Dette er OK, men ofte
hva folk trenger

990
00:42:05,820 --> 00:42:08,170
er de ønsker er dette hash
Nøkkelen til å gjøre litt mer

991
00:42:08,170 --> 00:42:11,010
enn bare være en unik identifikator.

992
00:42:11,010 --> 00:42:15,240
Ofte ønsker vi å bruke som firkanttasten
som øverste nivå aggregering bøtte.

993
00:42:15,240 --> 00:42:19,160
Og måten vi gjør det på er ved
legge det vi kaller en rekke nøkkel.

994
00:42:19,160 --> 00:42:22,460
>> Så hvis det er en hash bare
tabell, dette må være unikt.

995
00:42:22,460 --> 00:42:27,040
Hvis det er en hash og rekkevidde tabellen,
Kombinasjonen av hasj og utvalget

996
00:42:27,040 --> 00:42:28,640
må være unikt.

997
00:42:28,640 --> 00:42:30,110
Så tenk på det på denne måten.

998
00:42:30,110 --> 00:42:32,140
Hvis jeg har et forum.

999
00:42:32,140 --> 00:42:39,010
Og formen har emner, det har
poster, og det har svarene.

1000
00:42:39,010 --> 00:42:42,630
>> Så jeg har kanskje en hash
tasten, som er tema ID.

1001
00:42:42,630 --> 00:42:46,650
Og jeg kan ha en rekke nøkkel,
som er responsen ID.

1002
00:42:46,650 --> 00:42:49,650
På den måten hvis jeg ønsker å få alle
svar for spesielle tema,

1003
00:42:49,650 --> 00:42:52,370
Jeg kan bare spørre hasj.

1004
00:42:52,370 --> 00:42:55,190
Jeg kan bare si gi meg alt
elementene som har denne hash.

1005
00:42:55,190 --> 00:43:01,910
Og jeg kommer til å få alle spørsmål
eller legge til det aktuelle emnet.

1006
00:43:01,910 --> 00:43:03,910
Disse topp samlinger
er svært viktig.

1007
00:43:03,910 --> 00:43:07,370
De støtter den primære tilgang
mønster av søknaden.

1008
00:43:07,370 --> 00:43:09,420
Generelt sett, denne
er det vi ønsker å gjøre.

1009
00:43:09,420 --> 00:43:11,780
Vi ønsker at table--
som du legger på bordet,

1010
00:43:11,780 --> 00:43:16,640
vi ønsker å strukturere data
i tabellen på en slik måte

1011
00:43:16,640 --> 00:43:20,140
at søknaden kan veldig
raskt hente disse resultatene.

1012
00:43:20,140 --> 00:43:24,510
Og ofte den måten å gjøre det på er
for å opprettholde disse samlinger som vi

1013
00:43:24,510 --> 00:43:25,650
sette inn data.

1014
00:43:25,650 --> 00:43:31,110
I utgangspunktet er vi spre data
inn i den lyse bøtte som det kommer inn.

1015
00:43:31,110 --> 00:43:35,210
>> Range tastene lar me-- hash
nøklene må være likestilling.

1016
00:43:35,210 --> 00:43:39,490
Når jeg spørre en hash, må jeg si
gi meg en hash som tilsvarer dette.

1017
00:43:39,490 --> 00:43:41,950
Når jeg spørre et utvalg, jeg
kan si gi meg et utvalg

1018
00:43:41,950 --> 00:43:47,040
som ved hjelp av en hvilken som helst slags
rik operatør som vi støtter.

1019
00:43:47,040 --> 00:43:49,200
Gi meg alle elementer for en hash.

1020
00:43:49,200 --> 00:43:52,520
Er det like, større enn,
mindre enn, begynner det med,

1021
00:43:52,520 --> 00:43:54,145
eksisterer det mellom disse to verdier?

1022
00:43:54,145 --> 00:43:56,811
Så disse typer områdespørringer
at vi er alltid interessert i.

1023
00:43:56,811 --> 00:43:59,650
Nå er en ting om data, når
du ser på tilgang til data, når

1024
00:43:59,650 --> 00:44:02,360
du tilgang til data, er det
alltid om en aggregering.

1025
00:44:02,360 --> 00:44:05,770
Det handler alltid om postene
som er relatert til dette.

1026
00:44:05,770 --> 00:44:10,390
Gi meg alt her that's-- alle
transaksjonene på dette kredittkortet

1027
00:44:10,390 --> 00:44:12,500
for den siste måneden.

1028
00:44:12,500 --> 00:44:13,960
Det er en samling.

1029
00:44:13,960 --> 00:44:17,490
>> Nesten alt du gjør i
Databasen er noen form for aggregering.

1030
00:44:17,490 --> 00:44:21,530
Så være i stand til å være i stand til å definere
disse bøtter og gi deg disse spenner

1031
00:44:21,530 --> 00:44:24,950
attributter som skal være i stand til å søke på,
de rike spørringer støtter mange,

1032
00:44:24,950 --> 00:44:27,165
mange, mange søknad tilgang mønstre.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Så den andre tingen på firkanttasten
gjør er det gir oss en mekanisme

1035
00:44:35,000 --> 00:44:37,740
å være i stand til å spre data rundt.

1036
00:44:37,740 --> 00:44:40,390
NoSQL databaser fungerer best
når dataene er jevnt

1037
00:44:40,390 --> 00:44:41,740
fordelt på klyngen.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Hvor mange mennesker er kjent
med hashing algoritmer?

1040
00:44:47,050 --> 00:44:49,860
Når jeg sier hasj og en hashing--
fordi en hashing-algoritme

1041
00:44:49,860 --> 00:44:54,140
er en måte å være i stand til å generere
en tilfeldig verdi fra en hvilken som helst gitt verdi.

1042
00:44:54,140 --> 00:44:59,300
Så i dette tilfellet,
hash algoritme vi kjører er ND 5 basert.

1043
00:44:59,300 --> 00:45:04,765
>> Og hvis jeg har en ID, og ​​dette
er min firkanttasten, jeg har en, to, tre.

1044
00:45:04,765 --> 00:45:07,390
Når jeg kjører hash algoritmen,
det kommer til å komme tilbake og si:

1045
00:45:07,390 --> 00:45:10,800
vel en lik 7B, 2
tilsvarer 48, 3 tilsvarer CD.

1046
00:45:10,800 --> 00:45:13,092
De er spredt over hele nøkkelen plass.

1047
00:45:13,092 --> 00:45:14,050
Og hvorfor gjør du dette?

1048
00:45:14,050 --> 00:45:17,120
Fordi det gjør at jeg kan
sette rekorder på tvers av flere noder.

1049
00:45:17,120 --> 00:45:19,574
>> Hvis jeg gjør dette
trinnvis, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Og jeg har en hash utvalg som
kjører i dette tilfellet,

1051
00:45:21,990 --> 00:45:24,785
en liten hash plass,
det går fra 00 til FF,

1052
00:45:24,785 --> 00:45:27,951
deretter postene kommer til å komme i
og de kommer til å gå 1, 2, 3, 4, 5,

1053
00:45:27,951 --> 00:45:30,390
6, 7, 8, 9, 10, 11, 12.

1054
00:45:30,390 --> 00:45:31,800
Hva skjer?

1055
00:45:31,800 --> 00:45:34,860
Hver innsats er kommer til den samme node.

1056
00:45:34,860 --> 00:45:36,070
Du skjønner hva jeg mener?

1057
00:45:36,070 --> 00:45:40,910
>> Fordi når jeg delt plass,
og jeg spre disse postene over,

1058
00:45:40,910 --> 00:45:45,950
og jeg partisjon, kommer jeg til å si
partisjon 1 har nøkkelen plass 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partisjon 2 er 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partition 3 er AA til FF.

1061
00:45:49,780 --> 00:45:53,740
Så hvis jeg bruker lineært økes
ID-er, kan du se hva som skjer.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, hele veien opp til 54.

1063
00:45:57,410 --> 00:46:00,030
Så som jeg hamring
poster i systemet,

1064
00:46:00,030 --> 00:46:02,030
alt ender opp med å gå til en node.

1065
00:46:02,030 --> 00:46:03,160
>> Det er ikke bra.

1066
00:46:03,160 --> 00:46:04,820
Det er en antipattern.

1067
00:46:04,820 --> 00:46:08,760
I MongoDB de har dette problemet
hvis du ikke bruker en firkanttasten.

1068
00:46:08,760 --> 00:46:11,325
MongoDB gir deg muligheten
av hashing nøkkelverdien.

1069
00:46:11,325 --> 00:46:13,950
Du bør alltid gjøre det, hvis
du bruker et økes hash

1070
00:46:13,950 --> 00:46:17,380
nøkkelen i MongoDB, eller vil du være
spikre hver skrive til en node,

1071
00:46:17,380 --> 00:46:21,290
og du vil være begrensende
din skrive gjennomstrømming dårlig.

1072
00:46:21,290 --> 00:46:24,896
>> PUBLIKUM: Er det A9 169 i desimal?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Ja, det er
et sted rundt der.

1074
00:46:28,450 --> 00:46:29,950
A9, vet jeg ikke.

1075
00:46:29,950 --> 00:46:32,200
Du må få min binære
til desimal kalkulator.

1076
00:46:32,200 --> 00:46:34,237
Hjernen min virker ikke sånn.

1077
00:46:34,237 --> 00:46:36,320
PUBLIKUM: Bare en rask en
av Mongo kommentarer.

1078
00:46:36,320 --> 00:46:39,530
Så er objektet ID som kommer
opprinnelig med Mongo gjøre det?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Betyr det gjøre det?

1081
00:46:41,470 --> 00:46:42,970
Hvis du spesifiserer det.

1082
00:46:42,970 --> 00:46:45,030
Med MongoDB, har du muligheten.

1083
00:46:45,030 --> 00:46:48,930
Du kan specify-- hvert dokument i
MongoDB må ha en understrek ID.

1084
00:46:48,930 --> 00:46:50,300
Det er den unike verdien.

1085
00:46:50,300 --> 00:46:55,240
>> I MongoDB kan du angi
om til hasj det eller ikke.

1086
00:46:55,240 --> 00:46:56,490
De bare gir deg muligheten.

1087
00:46:56,490 --> 00:46:58,198
Hvis du vet at det er
tilfeldig, ikke noe problem.

1088
00:46:58,198 --> 00:46:59,640
Du trenger ikke å gjøre det.

1089
00:46:59,640 --> 00:47:04,260
Hvis du vet at det ikke er tilfeldig at
det økes, så gjør hash.

1090
00:47:04,260 --> 00:47:06,880
>> Nå er ting om
hashing, når du hasj

1091
00:47:06,880 --> 00:47:08,800
en value-- og denne er
hvorfor hash tastene er alltid

1092
00:47:08,800 --> 00:47:13,740
unike spørringer, fordi jeg har endret
verdien, nå kan jeg ikke gjøre en rekke spørsmål.

1093
00:47:13,740 --> 00:47:15,640
Jeg kan ikke si dette er
mellom dette eller hint,

1094
00:47:15,640 --> 00:47:20,800
fordi hash-verdi er ikke til
å være tilsvarende den faktiske verdien.

1095
00:47:20,800 --> 00:47:24,570
Så når du hasj som
nøkkel, er det likestilling bare.

1096
00:47:24,570 --> 00:47:28,700
Det er derfor i DynamoDB firkanttasten
spørringer er alltid likestilling bare.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Så nå i en rekke key--
når jeg legger til at utvalget nøkkel,

1099
00:47:34,700 --> 00:47:38,180
disse range viktige poster alle kommer inn og
de blir lagret på samme partisjon.

1100
00:47:38,180 --> 00:47:42,430
Så de er veldig raskt, enkelt
hentet fordi dette er den hash,

1101
00:47:42,430 --> 00:47:43,220
dette er rekkevidden.

1102
00:47:43,220 --> 00:47:44,928
Og du ser alt
med den samme hash

1103
00:47:44,928 --> 00:47:48,550
blir lagret på samme partisjon plass.

1104
00:47:48,550 --> 00:47:53,889
Du kan bruke dette området for å bidra til
isere dine data nær sin forelder.

1105
00:47:53,889 --> 00:47:55,180
Så hva er det jeg egentlig gjør her?

1106
00:47:55,180 --> 00:47:57,320
Dette er en en til mange forhold.

1107
00:47:57,320 --> 00:48:01,490
Forholdet mellom en firkanttasten
og utvalget nøkkelen er en til mange.

1108
00:48:01,490 --> 00:48:03,490
Jeg kan ha flere hash nøkler.

1109
00:48:03,490 --> 00:48:07,610
Jeg kan bare ha flere utvalg
tastene innenfor hver firkanttasten.

1110
00:48:07,610 --> 00:48:11,910
>> Hash definerer forelder,
utvalget definerer barn.

1111
00:48:11,910 --> 00:48:15,240
Så du kan se det er analog her
mellom det relasjonelle konstruksjonen

1112
00:48:15,240 --> 00:48:18,840
og de samme typene
konstruerer i NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Folk snakker om
NoSQL som ikke-relasjons.

1114
00:48:20,760 --> 00:48:22,200
Det er ikke ikke-relasjons.

1115
00:48:22,200 --> 00:48:24,680
Data har alltid relasjoner.

1116
00:48:24,680 --> 00:48:28,172
Disse relasjonene bare
er modellert annerledes.

1117
00:48:28,172 --> 00:48:29,880
La oss snakke litt
litt om holdbarhet.

1118
00:48:29,880 --> 00:48:34,860
Når du skriver til DynamoDB, skriver
alltid er tre-veis replikert.

1119
00:48:34,860 --> 00:48:37,550
Noe som betyr at vi har tre AZ-tallet.

1120
00:48:37,550 --> 00:48:39,160
AZ-er Tilgjengelighet soner.

1121
00:48:39,160 --> 00:48:43,430
Du kan tenke på en tilgjengelighet
Sonen som et datasenter

1122
00:48:43,430 --> 00:48:45,447
eller en samling av datasentre.

1123
00:48:45,447 --> 00:48:47,780
Disse tingene er geografisk
isolert fra hverandre

1124
00:48:47,780 --> 00:48:51,610
på tvers av ulike forkastningssoner, på tvers
annet kraftnett og elveslette.

1125
00:48:51,610 --> 00:48:54,510
En svikt i en AZ er ikke
kommer til å ta ned en annen.

1126
00:48:54,510 --> 00:48:56,890
De er også knyttet
sammen med mørk fiber.

1127
00:48:56,890 --> 00:49:01,240
Den støtter én sub 1
millisekund latency mellom AZS.

1128
00:49:01,240 --> 00:49:05,390
Så sanntidsdata kjøringer
stand i multi AZS.

1129
00:49:05,390 --> 00:49:09,990
>> Og ofte flere AZ distribusjoner
møte de høye krav til tilgjengelighet

1130
00:49:09,990 --> 00:49:12,930
av de fleste bedriftsorganisasjoner.

1131
00:49:12,930 --> 00:49:16,139
Så DynamoDB er spredt
over tre AZS som standard.

1132
00:49:16,139 --> 00:49:19,430
Vi skal bare kunnskap skrive
når to av de tre nodene komme tilbake

1133
00:49:19,430 --> 00:49:21,470
og si: Ja, jeg fikk den.

1134
00:49:21,470 --> 00:49:22,050
Hvorfor det?

1135
00:49:22,050 --> 00:49:25,950
Fordi på lesesiden vi er bare
kommer til å gi deg dataene tilbake når

1136
00:49:25,950 --> 00:49:27,570
vi får det fra to noder.

1137
00:49:27,570 --> 00:49:30,490
>> Hvis jeg reproduserende tvers
tre, og jeg leser fra to,

1138
00:49:30,490 --> 00:49:32,840
Jeg er alltid garantert
å ha minst ett

1139
00:49:32,840 --> 00:49:35,720
av dem som leser til å være
mest oppdaterte versjonen av data.

1140
00:49:35,720 --> 00:49:38,340
Det er det som gjør DynamoDB konsekvent.

1141
00:49:38,340 --> 00:49:42,450
Nå kan du velge å slå
de som konsekvent leser av.

1142
00:49:42,450 --> 00:49:45,070
I så fall kommer jeg til å si,
Jeg skal bare lese fra én node.

1143
00:49:45,070 --> 00:49:47,430
Og jeg kan ikke garantere det kommer
å være de mest aktuelle data.

1144
00:49:47,430 --> 00:49:49,450
>> Så hvis en skrive kommer inn,
det ikke har replikert ennå,

1145
00:49:49,450 --> 00:49:50,360
du kommer til å få den kopien.

1146
00:49:50,360 --> 00:49:52,220
Det er en slutt konsekvent lese.

1147
00:49:52,220 --> 00:49:54,640
Og hva som er er halvparten av prisen.

1148
00:49:54,640 --> 00:49:56,140
Så dette er noe å tenke på.

1149
00:49:56,140 --> 00:50:00,160
Når du leser ut DynamoDB, og
du setter opp din lesekapasitet

1150
00:50:00,160 --> 00:50:04,430
enheter, hvis du velger til slutt
konsekvent leser, det er mye billigere,

1151
00:50:04,430 --> 00:50:06,010
det er omtrent halvparten av kostnadene.

1152
00:50:06,010 --> 00:50:09,342
>> Og så det sparer du penger.

1153
00:50:09,342 --> 00:50:10,300
Men det er ditt valg.

1154
00:50:10,300 --> 00:50:12,925
Hvis du vil ha en konsekvent lese- eller
en slutt konsekvent lese.

1155
00:50:12,925 --> 00:50:15,720
Det er noe som du kan velge.

1156
00:50:15,720 --> 00:50:17,659
>> La oss snakke om indekser.

1157
00:50:17,659 --> 00:50:19,450
Så vi nevnte at
toppnivå aggregering.

1158
00:50:19,450 --> 00:50:23,720
Vi har fått hasj nøkler, og
vi har fått range keys.

1159
00:50:23,720 --> 00:50:24,320
Det er fint.

1160
00:50:24,320 --> 00:50:26,950
Og det er på den primære tabellen, jeg
fikk en firkanttasten, fikk jeg en rekke nøkkel.

1161
00:50:26,950 --> 00:50:27,783
>> Hva betyr det?

1162
00:50:27,783 --> 00:50:30,410
Jeg har fått en attributt som jeg
kan kjøre rike spørringer mot.

1163
00:50:30,410 --> 00:50:31,800
Det er utvalget nøkkelen.

1164
00:50:31,800 --> 00:50:35,530
De andre attributter på at item--
Jeg kan filtrere på disse attributtene.

1165
00:50:35,530 --> 00:50:40,050
Men jeg kan ikke gjøre ting som det
begynner med, eller er større enn.

1166
00:50:40,050 --> 00:50:40,820
>> Hvordan gjør jeg det?

1167
00:50:40,820 --> 00:50:42,860
Jeg oppretter en indeks.

1168
00:50:42,860 --> 00:50:45,340
Det finnes to typer av
indekser i DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
En indeks er virkelig
et annet syn på bordet.

1170
00:50:49,002 --> 00:50:50,490
Og den lokale videregående indeksen.

1171
00:50:50,490 --> 00:50:51,781
>> Det første vi skal snakke om.

1172
00:50:51,781 --> 00:50:57,740
Så lokale second er coexisted
på samme partisjon som dataene.

1173
00:50:57,740 --> 00:51:00,240
Og som sådan, de er på
den samme fysiske noden.

1174
00:51:00,240 --> 00:51:01,780
De er det vi kaller konsekvent.

1175
00:51:01,780 --> 00:51:04,599
Betydning, vil de erkjenne
skrive sammen med bordet.

1176
00:51:04,599 --> 00:51:06,890
Når skrive kommer inn,
vi skal skrive gjennom indeksen.

1177
00:51:06,890 --> 00:51:09,306
Vi skal skrive opp til bordet,
og da vil vi erkjenne.

1178
00:51:09,306 --> 00:51:10,490
Så det er konsekvent.

1179
00:51:10,490 --> 00:51:13,174
Når skrive har vært
erkjent fra bordet,

1180
00:51:13,174 --> 00:51:15,090
det er garantert at
lokal videregående index

1181
00:51:15,090 --> 00:51:18,380
vil ha samme syn på data.

1182
00:51:18,380 --> 00:51:22,390
Men hva de lar deg gjøre er
definere alternative range keys.

1183
00:51:22,390 --> 00:51:25,260
>> Nødt til å bruke samme hash
tast som den primære tabellen,

1184
00:51:25,260 --> 00:51:29,050
fordi de er samlokalisert på
samme partisjon, og de er konsekvente.

1185
00:51:29,050 --> 00:51:33,110
Men jeg kan lage en indeks
med ulike range keys.

1186
00:51:33,110 --> 00:51:41,590
Så for eksempel, hvis jeg hadde en produsent
som hadde en rå deler bord kommer inn.

1187
00:51:41,590 --> 00:51:44,590
Og rå deler kommer inn, og
de er samlet ved montering.

1188
00:51:44,590 --> 00:51:46,840
Og kanskje det er en tilbakekalling.

1189
00:51:46,840 --> 00:51:50,240
>> Del som ble gjort av dette
Produsenten etter denne datoen,

1190
00:51:50,240 --> 00:51:52,840
Jeg trenger å trekke fra min linje.

1191
00:51:52,840 --> 00:51:55,950
Jeg kan spinne en indeks
som ville være ute,

1192
00:51:55,950 --> 00:52:00,760
aggregering på datoen for
produksjon av den aktuelle delen.

1193
00:52:00,760 --> 00:52:03,930
Så hvis min topp nivå bord var
allerede hashet av produsenten,

1194
00:52:03,930 --> 00:52:07,655
kanskje det ble arrangert på en del ID, jeg
kan opprette en indeks av det bordet

1195
00:52:07,655 --> 00:52:11,140
som hashet av produsenten og
varierte på produksjonsdato.

1196
00:52:11,140 --> 00:52:14,490
Og på den måten jeg kunne si, noe som
ble produsert mellom disse datoene,

1197
00:52:14,490 --> 00:52:16,804
Jeg må trekke fra linjen.

1198
00:52:16,804 --> 00:52:18,220
Så det er en lokal videregående indeks.

1199
00:52:18,220 --> 00:52:22,280
>> Dette har effekten av
begrense firkanttasten plass.

1200
00:52:22,280 --> 00:52:24,360
Fordi de co-eksisterte
på samme lagerknuten,

1201
00:52:24,360 --> 00:52:26,860
de begrense firkanttasten
plass til 10 gigabyte.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, under
tabeller, vil partisjonere

1203
00:52:28,950 --> 00:52:31,380
bordet hver 10 gigabyte.

1204
00:52:31,380 --> 00:52:34,760
Når du putter 10 gigabyte data i, vi
gå [PHH], og vi legge til en annen node.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Vi vil ikke dele LSI
tvers av flere partisjoner.

1207
00:52:42,070 --> 00:52:43,200
Vi skal dele bordet.

1208
00:52:43,200 --> 00:52:44,679
Men vi vil ikke dele LSI.

1209
00:52:44,679 --> 00:52:46,470
Så det er noe
viktig å forstå

1210
00:52:46,470 --> 00:52:50,070
er hvis du gjør veldig,
veldig, veldig store samlinger,

1211
00:52:50,070 --> 00:52:53,860
så du kommer til å være begrenset
10 gigabyte på din LSIS.

1212
00:52:53,860 --> 00:52:56,640
>> Hvis det er tilfelle, kan vi
bruke globale second.

1213
00:52:56,640 --> 00:52:58,630
Global second er
virkelig en annen tabell.

1214
00:52:58,630 --> 00:53:01,720
De finnes helt av å
siden av din primære tabellen.

1215
00:53:01,720 --> 00:53:04,680
Og de tillater meg å finne en
helt annen struktur.

1216
00:53:04,680 --> 00:53:08,010
Så tenk på det som data blir satt inn
i to forskjellige tabeller, strukturert

1217
00:53:08,010 --> 00:53:09,220
på to forskjellige måter.

1218
00:53:09,220 --> 00:53:11,360
>> Jeg kan definere en helt
annerledes firkanttasten.

1219
00:53:11,360 --> 00:53:13,490
Jeg kan definere en helt
annet utvalg nøkkelen.

1220
00:53:13,490 --> 00:53:15,941
Og jeg kan kjøre dette
helt uavhengig av hverandre.

1221
00:53:15,941 --> 00:53:18,190
Som et spørsmål om faktum, har jeg
klargjort min lesekapasitet

1222
00:53:18,190 --> 00:53:21,090
og skrive kapasitet for min
globale sekundære indekser

1223
00:53:21,090 --> 00:53:24,240
helt uavhengig
av mitt primære tabellen.

1224
00:53:24,240 --> 00:53:26,640
Hvis jeg definerer som indeks, sier jeg
det hvor mye lese og skrive

1225
00:53:26,640 --> 00:53:28,610
kapasitet det kommer til å bruke.

1226
00:53:28,610 --> 00:53:31,490
>> Og som er atskilt
fra mitt primære tabellen.

1227
00:53:31,490 --> 00:53:35,240
Nå begge indeksene tillate oss å
ikke bare definere hasj og range keys,

1228
00:53:35,240 --> 00:53:38,610
men de tillater oss å
projisere ekstra verdier.

1229
00:53:38,610 --> 00:53:44,950
Så hvis jeg ønsker å lese av indeksen,
og jeg ønsker å få noen sett med data,

1230
00:53:44,950 --> 00:53:48,327
Jeg trenger ikke å gå tilbake til hoved
bordet for å få de ekstra attributtene.

1231
00:53:48,327 --> 00:53:50,660
Jeg kan projisere dem ekstra
attributter i tabellen

1232
00:53:50,660 --> 00:53:53,440
å støtte tilgangsmønster.

1233
00:53:53,440 --> 00:53:57,700
Jeg vet at vi sannsynligvis får inn noen
virkelig, really-- komme inn ugresset

1234
00:53:57,700 --> 00:53:58,910
her på noen av disse tingene.

1235
00:53:58,910 --> 00:54:02,725
Nå fikk jeg til å drive ut av dette.

1236
00:54:02,725 --> 00:54:07,320
>> PUBLIKUM: [uhørbart]
--table nøkkelen mente var en hash?

1237
00:54:07,320 --> 00:54:08,840
Den opprinnelige hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-lamellene?

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
Tabellen nøkkelen i utgangspunktet
peker tilbake til elementet.

1242
00:54:15,260 --> 00:54:19,280
Så en indeks er en peker tilbake til
de opprinnelige elementene på bordet.

1243
00:54:19,280 --> 00:54:22,910
Nå kan du velge å bygge en
indeks som bare har nøkkelen bordet,

1244
00:54:22,910 --> 00:54:24,840
og ingen andre egenskaper.

1245
00:54:24,840 --> 00:54:26,570
Og hvorfor kan jeg gjøre det?

1246
00:54:26,570 --> 00:54:28,570
Vel, kanskje jeg har veldig store elementer.

1247
00:54:28,570 --> 00:54:31,660
>> Jeg egentlig bare trenger å vite which--
min tilgang mønster kanskje si,

1248
00:54:31,660 --> 00:54:33,760
hvilke elementer som inneholder denne eiendommen?

1249
00:54:33,760 --> 00:54:35,780
Trenger ikke å returnere varen.

1250
00:54:35,780 --> 00:54:37,800
Jeg trenger bare å vite
hvilke elementer som inneholder det.

1251
00:54:37,800 --> 00:54:40,700
Så du kan bygge indekser
som bare har nøkkelen bordet.

1252
00:54:40,700 --> 00:54:43,360
>> Men det er først og fremst hva
en indeks i databasen er for.

1253
00:54:43,360 --> 00:54:46,280
Det er for å være i stand til raskt
identifisere hvilke poster,

1254
00:54:46,280 --> 00:54:49,470
hvilke rader, hvilke
postene i tabellen har

1255
00:54:49,470 --> 00:54:51,080
egenskapene som jeg søker etter.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIs, så hvordan fungerer de?

1258
00:54:54,860 --> 00:54:58,340
GSIs utgangspunktet er asynkron.

1259
00:54:58,340 --> 00:55:02,570
Oppdateringen kommer inn i tabellen,
Tabellen blir deretter asynkront oppdateres

1260
00:55:02,570 --> 00:55:03,720
alle dine GSIs.

1261
00:55:03,720 --> 00:55:06,680
Dette er grunnen er GSIs
slutt konsekvent.

1262
00:55:06,680 --> 00:55:09,440
>> Det er viktig å merke seg at
når du bygger GSIs,

1263
00:55:09,440 --> 00:55:13,110
og du forstår du oppretter
en annen dimensjon av aggregation--

1264
00:55:13,110 --> 00:55:16,594
Nå la oss si et godt eksempel
her er en produsent.

1265
00:55:16,594 --> 00:55:19,260
Jeg tror jeg kunne ha snakket om
en medisinsk produsent enhet.

1266
00:55:19,260 --> 00:55:23,870
Produsenter av medisinsk utstyr
Ofte har serialiserte deler.

1267
00:55:23,870 --> 00:55:28,070
De delene som går inn
en hofteoperasjon alle

1268
00:55:28,070 --> 00:55:30,200
har en liten serienummer på dem.

1269
00:55:30,200 --> 00:55:33,584
Og de kunne ha millioner og
millioner og milliarder av deler

1270
00:55:33,584 --> 00:55:35,000
i alle enheter som de leverer.

1271
00:55:35,000 --> 00:55:37,440
Vel, de trenger å aggregere henhold
forskjellige dimensjoner, alle deler

1272
00:55:37,440 --> 00:55:39,520
i en sammenstilling, hele
deler som er gjort

1273
00:55:39,520 --> 00:55:41,670
på en viss linje, alt
delene som kom

1274
00:55:41,670 --> 00:55:44,620
i fra en bestemt produsent
på en bestemt dato.

1275
00:55:44,620 --> 00:55:47,940
Og disse samlinger noen ganger
komme opp i milliardklassen.

1276
00:55:47,940 --> 00:55:50,550
>> Så jeg jobber med noen av
disse gutta som lider

1277
00:55:50,550 --> 00:55:53,156
fordi de skaper
disse enorm samlinger

1278
00:55:53,156 --> 00:55:54,280
i sine sekundære indekser.

1279
00:55:54,280 --> 00:55:57,070
De kan ha en rå deler
tabell som kommer som hasj bare.

1280
00:55:57,070 --> 00:55:59,090
Hver del har et unikt serienummer.

1281
00:55:59,090 --> 00:56:00,975
Jeg bruker serienummeret som hasj.

1282
00:56:00,975 --> 00:56:01,600
Det er vakkert.

1283
00:56:01,600 --> 00:56:04,160
Min rå datatabellen er spredt
hele nøkkelen plass.

1284
00:56:04,160 --> 00:56:05,930
Min [? skrive ?]
[? inntak?] er kjempebra.

1285
00:56:05,930 --> 00:56:07,876
Jeg tar mye data.

1286
00:56:07,876 --> 00:56:09,500
Så hva de gjør er de oppretter en GSI.

1287
00:56:09,500 --> 00:56:12,666
Og jeg sier, vet du hva, jeg trenger å se
alle delene for denne produsenten.

1288
00:56:12,666 --> 00:56:15,060
Vel, plutselig er jeg
ta en milliard rader,

1289
00:56:15,060 --> 00:56:17,550
og stappe dem inn
en node, fordi når

1290
00:56:17,550 --> 00:56:21,170
Jeg aggregere som
Produsenten ID som hasj,

1291
00:56:21,170 --> 00:56:25,410
og en del tall som utvalget,
da alle plutselig er jeg

1292
00:56:25,410 --> 00:56:30,530
sette en milliard deler inn i hva
denne produsenten har levert meg.

1293
00:56:30,530 --> 00:56:34,447
>> Det kan føre til mye
press på GSI,

1294
00:56:34,447 --> 00:56:36,030
igjen, fordi jeg hamrer én node.

1295
00:56:36,030 --> 00:56:38,350
Jeg setter alle disse
setter inn en node.

1296
00:56:38,350 --> 00:56:40,940
Og det er en skikkelig problematisk bruk tilfelle.

1297
00:56:40,940 --> 00:56:43,479
Nå fikk jeg en god design
mønster for hvordan du unngår det.

1298
00:56:43,479 --> 00:56:45,770
Og det er et av problemene
at jeg alltid jobbe med.

1299
00:56:45,770 --> 00:56:49,590
Men hva skjer, er det GSI kanskje
ikke har nok skrivekapasitet

1300
00:56:49,590 --> 00:56:52,330
å være i stand til å skyve alle
rader i en enkelt node.

1301
00:56:52,330 --> 00:56:55,390
Og hva skjer da er det
primære, klienten bordet,

1302
00:56:55,390 --> 00:57:00,180
den primære tabellen skal strupes
fordi GSI ikke kan holde tritt.

1303
00:57:00,180 --> 00:57:02,980
Så min innsats rente vil
faller på den primære tabell

1304
00:57:02,980 --> 00:57:06,230
som min GSI forsøker å holde tritt.

1305
00:57:06,230 --> 00:57:08,850
>> All right, så GSI-tallet, LSI-tallet,
som en bør jeg bruke?

1306
00:57:08,850 --> 00:57:12,290
LSI-er konsekvent.

1307
00:57:12,290 --> 00:57:13,750
GSI-er etter hvert konsekvent.

1308
00:57:13,750 --> 00:57:17,490
Hvis det er OK, anbefaler jeg å bruke en
GSI, de er mye mer fleksibel.

1309
00:57:17,490 --> 00:57:20,270
LSI-er kan modelleres som en GSI.

1310
00:57:20,270 --> 00:57:27,040
Og hvis datastørrelsen per hash nøklene i
samlingen din overstiger 10 gigabyte,

1311
00:57:27,040 --> 00:57:31,050
så du kommer til å ønske å bruke det
GSI fordi det er bare en hard grense.

1312
00:57:31,050 --> 00:57:32,035
>> All right, så skalering.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Gjennomstrømning i Dynamo DB, du
kan bestemmelsen [uhørbart]

1315
00:57:37,460 --> 00:57:38,680
gjennomstrømning i en tabell.

1316
00:57:38,680 --> 00:57:42,740
Vi har kunder som har
klargjort 60 billion--

1317
00:57:42,740 --> 00:57:45,970
gjør 60 milliarder forespørsler, regelmessig
kjører på over en million forespørsler

1318
00:57:45,970 --> 00:57:47,790
per sekund på våre bord.

1319
00:57:47,790 --> 00:57:50,360
Det er egentlig ingen
teoretisk grense for hvor mye

1320
00:57:50,360 --> 00:57:53,730
og hvor fort tabellen
kan kjøre i Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Det er noen myk
begrensninger på kontoen din

1322
00:57:55,920 --> 00:57:58,170
at vi satt der så
at du ikke gå gale.

1323
00:57:58,170 --> 00:58:00,070
Hvis du ønsker mer enn
at det ikke er et problem.

1324
00:58:00,070 --> 00:58:00,820
Du kommer fortelle oss.

1325
00:58:00,820 --> 00:58:02,810
Vi vil slå opp urskiven.

1326
00:58:02,810 --> 00:58:08,210
>> Hver konto er begrenset til et visst nivå
i hver service, like utenfor balltre

1327
00:58:08,210 --> 00:58:11,920
slik at folk ikke gå gale
komme seg inn i trøbbel.

1328
00:58:11,920 --> 00:58:12,840
Ingen grense i størrelse.

1329
00:58:12,840 --> 00:58:14,940
Du kan sette et tall
av elementer på et bord.

1330
00:58:14,940 --> 00:58:17,620
Størrelsen på en vare er
begrenset til 400 kilobyte hver,

1331
00:58:17,620 --> 00:58:20,050
som ville være elementet ikke attributtene.

1332
00:58:20,050 --> 00:58:24,200
Så summen av alle attributter
er begrenset til 400 kilobyte.

1333
00:58:24,200 --> 00:58:27,300
Og så igjen, har vi
det lille LSI saken

1334
00:58:27,300 --> 00:58:30,405
med 10 gigabyte grense per hasj.

1335
00:58:30,405 --> 00:58:33,280
PUBLIKUM: Lite antall, jeg mangler
hva du forteller meg, som er--

1336
00:58:33,280 --> 00:58:36,830
PUBLIKUM: Oh, 400 kilobyte
er maksimumsstørrelsen per element.

1337
00:58:36,830 --> 00:58:39,570
Så et objekt har alle attributtene.

1338
00:58:39,570 --> 00:58:43,950
Så 400 k er den totale størrelse
av dette elementet, 400 kilobyte.

1339
00:58:43,950 --> 00:58:46,170
Så av alle de egenskaper
kombineres, alle data

1340
00:58:46,170 --> 00:58:49,140
det er i alle disse attributtene,
rullet opp i en total størrelse,

1341
00:58:49,140 --> 00:58:51,140
dag i dag elementet grensen er 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Så skalering igjen, oppnådde
gjennom partisjonering.

1344
00:58:57,046 --> 00:58:58,920
Gjennomstrømning er klargjort
ved bordet nivå.

1345
00:58:58,920 --> 00:59:00,160
Og det er egentlig to knotter.

1346
00:59:00,160 --> 00:59:02,400
Vi har lest kapasitet
og skrive kapasitet.

1347
00:59:02,400 --> 00:59:05,530
>> Så disse er justert
uavhengig av hverandre.

1348
00:59:05,530 --> 00:59:08,640
RCU er tiltaket strengt konsekvent leser.

1349
00:59:08,640 --> 00:59:13,005
OK, så hvis du sier jeg vil ha 1000
RCU er de som er strengt konsekvent,

1350
00:59:13,005 --> 00:59:14,130
de er konsistente leser.

1351
00:59:14,130 --> 00:59:17,130
Hvis du sier jeg vil ha
eventuell konsekvent leser,

1352
00:59:17,130 --> 00:59:19,402
du kan bestemmelsen 1000
RCU er, du kommer

1353
00:59:19,402 --> 00:59:21,840
for å få 2000 til slutt
konsekvent leser.

1354
00:59:21,840 --> 00:59:25,940
Og halvparten av prisen for disse
til slutt bestå i leser.

1355
00:59:25,940 --> 00:59:28,520
>> Igjen, justert
uavhengig av hverandre.

1356
00:59:28,520 --> 00:59:32,900
Og de har throughput--
Hvis du bruker 100% av RCU,

1357
00:59:32,900 --> 00:59:35,960
du kommer ikke til å påvirke
tilgjengeligheten av dine rettigheter.

1358
00:59:35,960 --> 00:59:40,161
Så de er helt
uavhengig av hverandre.

1359
00:59:40,161 --> 00:59:43,160
All right, så en av de tingene som
Jeg nevnte kort ble strupe.

1360
00:59:43,160 --> 00:59:44,320
Struping er dårlig.

1361
00:59:44,320 --> 00:59:47,311
Struping indikerer dårlig ingen SQL.

1362
00:59:47,311 --> 00:59:50,310
Det er ting vi kan gjøre for å hjelpe
du lindre struping at du

1363
00:59:50,310 --> 00:59:51,040
opplever.

1364
00:59:51,040 --> 00:59:53,240
Men den beste løsningen
til dette er la oss ta

1365
00:59:53,240 --> 00:59:58,000
en se på hva du gjør, fordi
det er en anti-mønster i spill her.

1366
00:59:58,000 --> 01:00:02,140
>> Disse tingene, ting som ikke-uniform
arbeidsbelastning, hurtigtaster, varme partisjoner.

1367
01:00:02,140 --> 01:00:06,210
Jeg treffer en bestemt nøkkel plass
veldig vanskelig for noen spesiell grunn.

1368
01:00:06,210 --> 01:00:07,080
Hvorfor gjør jeg dette?

1369
01:00:07,080 --> 01:00:08,710
La oss finne det ut.

1370
01:00:08,710 --> 01:00:10,427
Jeg blande min varme data med kalde data.

1371
01:00:10,427 --> 01:00:12,510
Jeg la mine tabeller få
stor, men det er egentlig

1372
01:00:12,510 --> 01:00:15,970
bare noen delsett av data
det er veldig interessant for meg.

1373
01:00:15,970 --> 01:00:20,290
Så for loggdata, for eksempel en masse
kunder, får de logger data hver dag.

1374
01:00:20,290 --> 01:00:22,490
De fikk en enorm mengde av loggdata.

1375
01:00:22,490 --> 01:00:25,940
>> Hvis du bare dumping alt som log
data i ett stort bord, over tid

1376
01:00:25,940 --> 01:00:28,070
at tabellen kommer til å få massiv.

1377
01:00:28,070 --> 01:00:30,950
Men jeg er egentlig bare interessert i
siste 24 timene, de siste sju dagene,

1378
01:00:30,950 --> 01:00:31,659
de siste 30 dagene.

1379
01:00:31,659 --> 01:00:34,074
Uansett tidsvindu
at jeg er interessert i å se

1380
01:00:34,074 --> 01:00:37,010
for hendelsen som plager meg, eller
tilfelle det er interessant for meg,

1381
01:00:37,010 --> 01:00:39,540
det er det eneste vinduet tiden at jeg trenger.

1382
01:00:39,540 --> 01:00:42,470
Så hvorfor er jeg sette 10 år
verdt av loggdata i tabellen?

1383
01:00:42,470 --> 01:00:45,030
Hva som forårsaker er
bordet fragmentet.

1384
01:00:45,030 --> 01:00:45,880
>> Det blir stort.

1385
01:00:45,880 --> 01:00:48,340
Det begynner å spre ut
over tusenvis av noder.

1386
01:00:48,340 --> 01:00:51,380
Og siden din kapasitet
er så lav, du er

1387
01:00:51,380 --> 01:00:54,090
faktisk rangere begrensende på hver
en av de individuelle noder.

1388
01:00:54,090 --> 01:00:57,120
Så la oss begynne å se på hvordan
gjør vi rulle tabellen over.

1389
01:00:57,120 --> 01:01:01,502
Hvordan skal vi håndtere disse dataene litt
bedre å unngå disse problemene.

1390
01:01:01,502 --> 01:01:02,710
Og hva betyr det se ut?

1391
01:01:02,710 --> 01:01:04,370
Dette er hva som ser ut som.

1392
01:01:04,370 --> 01:01:06,790
Dette er hva dårlig NoSQL ser ut.

1393
01:01:06,790 --> 01:01:07,830
>> Jeg fikk en hurtigtast her.

1394
01:01:07,830 --> 01:01:10,246
Hvis du ser på siden her,
disse er alle mine partisjoner.

1395
01:01:10,246 --> 01:01:12,630
Jeg fikk 16 partisjoner opp her
på denne databasen.

1396
01:01:12,630 --> 01:01:13,630
Vi gjør dette hele tiden.

1397
01:01:13,630 --> 01:01:15,046
Jeg kjører denne for kunder hele tiden.

1398
01:01:15,046 --> 01:01:16,550
Det kalles kartet varmen.

1399
01:01:16,550 --> 01:01:20,590
Varmekartet forteller meg hvor du er
tilgang til nøkkel plass.

1400
01:01:20,590 --> 01:01:23,700
Og hva dette forteller meg er
at det er en bestemt hash

1401
01:01:23,700 --> 01:01:26,330
at denne fyren liker en
forferdelig mye, fordi han er

1402
01:01:26,330 --> 01:01:28,250
treffer det veldig, veldig vanskelig.

1403
01:01:28,250 --> 01:01:29,260
>> Så den blå er fint.

1404
01:01:29,260 --> 01:01:29,900
Vi liker blått.

1405
01:01:29,900 --> 01:01:30,720
Vi liker ikke rødt.

1406
01:01:30,720 --> 01:01:33,120
Rødts der trykket
kommer opp til 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, nå er du kommer til å bli redusert.

1408
01:01:35,560 --> 01:01:39,030
Så når du ser noen røde linjer som
dette-- og det er ikke bare Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
hver NoSQL database har dette problemet.

1410
01:01:41,630 --> 01:01:44,640
Det er anti-mønstre som kan
drive disse forhold.

1411
01:01:44,640 --> 01:01:49,070
Det jeg gjør er at jeg jobber med kunder
for å lindre disse tilstander.

1412
01:01:49,070 --> 01:01:51,840
>> Og hva betyr det se ut?

1413
01:01:51,840 --> 01:01:54,260
Og dette er å få mest mulig
ut av Dynamo DB gjennomstrømning,

1414
01:01:54,260 --> 01:01:56,176
men det begynner virkelig å
mest mulig ut av NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Dette er ikke begrenset til Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Dette er definitely-- jeg
pleide å jobbe på Mongo.

1417
01:02:02,050 --> 01:02:04,090
Jeg er kjent med mange NoSQL plattformer.

1418
01:02:04,090 --> 01:02:06,830
Hver og en har disse typene
av hurtigtast problemer.

1419
01:02:06,830 --> 01:02:10,320
For å få mest mulig ut av enhver NoSQL
database, spesielt Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
du ønsker å opprette tabellene
hvor firkanttasten element har

1421
01:02:13,320 --> 01:02:18,590
et stort antall forskjellige verdier,
en høy grad av kardinalitet.

1422
01:02:18,590 --> 01:02:22,530
Fordi det betyr at jeg skriver
til mange forskjellige skuffer.

1423
01:02:22,530 --> 01:02:24,870
>> Jo flere bøtter jeg er
skriving til, jo mer sannsynlig

1424
01:02:24,870 --> 01:02:29,100
Jeg er for å spre at skrive belastning eller
lese laste ut over flere noder,

1425
01:02:29,100 --> 01:02:33,560
jo mer sannsynlig er jeg til å ha en
høy gjennomstrømning på bordet.

1426
01:02:33,560 --> 01:02:37,440
Og da vil jeg verdiene å være
ba nokså jevnt over tid

1427
01:02:37,440 --> 01:02:39,430
og jevnt så tilfeldig som mulig.

1428
01:02:39,430 --> 01:02:42,410
Vel, det er ganske interessant,
fordi jeg kan egentlig ikke

1429
01:02:42,410 --> 01:02:43,960
kontroll når brukerne kommer.

1430
01:02:43,960 --> 01:02:47,645
Så nok til å si, hvis vi spre
ting ut over nøkkelen plass,

1431
01:02:47,645 --> 01:02:49,270
vi vil trolig være i bedre form.

1432
01:02:49,270 --> 01:02:51,522
>> Det er en viss
tid levering

1433
01:02:51,522 --> 01:02:53,230
at du ikke kommer
å være i stand til kontroll.

1434
01:02:53,230 --> 01:02:55,438
Men de er egentlig
to dimensjoner som vi har,

1435
01:02:55,438 --> 01:02:58,800
plass, tilgang jevnt
spredt, tid, forespørsler

1436
01:02:58,800 --> 01:03:01,040
ankommer jevnt fordelt i tid.

1437
01:03:01,040 --> 01:03:03,110
Og hvis de to
vilkår blir oppfylt,

1438
01:03:03,110 --> 01:03:05,610
så det er hva det er
kommer til å se ut.

1439
01:03:05,610 --> 01:03:07,890
Dette er mye hyggeligere.

1440
01:03:07,890 --> 01:03:08,890
Vi er veldig fornøyd her.

1441
01:03:08,890 --> 01:03:10,432
Vi har en meget jevn tilgang mønster.

1442
01:03:10,432 --> 01:03:13,098
Ja, kanskje du får en
lite press nå og da,

1443
01:03:13,098 --> 01:03:14,830
men ingenting egentlig altfor omfattende.

1444
01:03:14,830 --> 01:03:17,660
Så det er utrolig hvor mange ganger,
når jeg jobber med kunder,

1445
01:03:17,660 --> 01:03:20,670
som først graf med den store røde
bar og alt det stygge gule det er

1446
01:03:20,670 --> 01:03:23,147
over alt, vi
få gjort med øvelsen

1447
01:03:23,147 --> 01:03:24,980
etter et par måneder
av re-arkitektur,

1448
01:03:24,980 --> 01:03:28,050
de kjører nøyaktig samme
arbeidsmengde på nøyaktig samme belastning.

1449
01:03:28,050 --> 01:03:30,140
Og dette er hva det ser ut nå.

1450
01:03:30,140 --> 01:03:36,600
Så hva du får med NoSQL er en
data skjema som er helt

1451
01:03:36,600 --> 01:03:38,510
bundet til aksessmønster.

1452
01:03:38,510 --> 01:03:42,170
>> Og du kan optimalisere at data skjema
å støtte at tilgangen mønster.

1453
01:03:42,170 --> 01:03:45,490
Hvis du ikke gjør det, så du kommer
å se disse typer problemer

1454
01:03:45,490 --> 01:03:46,710
med disse hurtigtastene.

1455
01:03:46,710 --> 01:03:50,518
>> PUBLIKUM: Vel, uunngåelig noen steder
kommer til å bli varmere enn andre.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Alltid.

1457
01:03:51,450 --> 01:03:51,960
Alltid.

1458
01:03:51,960 --> 01:03:54,620
Ja, jeg mener det er alltid
a-- og igjen, det er

1459
01:03:54,620 --> 01:03:56,980
enkelte design patterns vi får gjennom
som vil snakke om hvordan du avtale

1460
01:03:56,980 --> 01:03:58,480
med disse super store samlinger.

1461
01:03:58,480 --> 01:04:01,260
Jeg mener, jeg fikk til å ha dem,
hvordan skal vi takle dem?

1462
01:04:01,260 --> 01:04:03,760
Jeg fikk en ganske god bruk saken
at vi skal snakke om for det.

1463
01:04:03,760 --> 01:04:05,940
>> Greit, så la oss snakke
om noen kunder nå.

1464
01:04:05,940 --> 01:04:06,950
Disse gutta er AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Jeg vet ikke om du er
kjent med AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Du sannsynligvis se dem
mye på nettleseren.

1467
01:04:10,781 --> 01:04:14,230
De er annonse re-targeting, de er
den største annonse re-targeting virksomhet

1468
01:04:14,230 --> 01:04:14,940
der ute.

1469
01:04:14,940 --> 01:04:17,792
De normalt jevnlig påkjørt
60 milliarder transaksjoner per dag.

1470
01:04:17,792 --> 01:04:20,000
De gjør over en million
transaksjoner per sekund.

1471
01:04:20,000 --> 01:04:22,660
De har fått en ganske enkel tabell
struktur, den travleste tabellen.

1472
01:04:22,660 --> 01:04:26,450
Det er i utgangspunktet bare en
firkanttasten er cookie,

1473
01:04:26,450 --> 01:04:29,010
området er den demografiske
kategori, og deretter

1474
01:04:29,010 --> 01:04:31,220
den tredje attributten er poengsummen.

1475
01:04:31,220 --> 01:04:33,720
>> Så vi alle informasjonskapsler i
vår nettleser fra disse gutta.

1476
01:04:33,720 --> 01:04:35,900
Og når du går til en
deltakende kjøpmann,

1477
01:04:35,900 --> 01:04:39,390
de i utgangspunktet scorer du på tvers
ulike demografiske kategorier.

1478
01:04:39,390 --> 01:04:42,070
Når du går til et nettsted og
du sier jeg ønsker å se dette ad--

1479
01:04:42,070 --> 01:04:44,920
eller i utgangspunktet du ikke sier at--
men når du går til nettsiden

1480
01:04:44,920 --> 01:04:47,550
de sier at du ønsker å se denne annonsen.

1481
01:04:47,550 --> 01:04:49,370
Og de går får den annonsen fra AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll ser du opp på bordet.

1483
01:04:51,130 --> 01:04:52,115
De finner din cookie.

1484
01:04:52,115 --> 01:04:53,990
Annonsørene forteller
dem, jeg vil ha noen

1485
01:04:53,990 --> 01:04:58,632
som er middelaldrende,
40-år gammel mann, i sport.

1486
01:04:58,632 --> 01:05:01,590
Og de scorer du i de demografiske
og de bestemmer hvorvidt

1487
01:05:01,590 --> 01:05:02,740
det er en god annonse for deg.

1488
01:05:02,740 --> 01:05:10,330
>> Nå har de en SLA med
deres reklame leverandører

1489
01:05:10,330 --> 01:05:14,510
å gi sub-10 millisekund
respons på hver enkelt forespørsel.

1490
01:05:14,510 --> 01:05:16,090
Så de bruker Dynamo DB for dette.

1491
01:05:16,090 --> 01:05:18,131
De treffer oss en
million forespørsler per sekund.

1492
01:05:18,131 --> 01:05:21,120
De er i stand til å gjøre alle sine
oppslag, triage alle disse dataene,

1493
01:05:21,120 --> 01:05:26,130
og få den add link tilbake til at
annonsør på under 10 millisekunder.

1494
01:05:26,130 --> 01:05:29,800
Det er egentlig ganske fenomenalt
implementering som de har.

1495
01:05:29,800 --> 01:05:36,210
>> Disse gutta actually--
er disse gutta.

1496
01:05:36,210 --> 01:05:38,010
Jeg er ikke sikker på om det er disse gutta.

1497
01:05:38,010 --> 01:05:40,127
Kanskje disse gutta.

1498
01:05:40,127 --> 01:05:42,210
Utgangspunktet fortalte us-- nei, jeg
tror ikke det var dem.

1499
01:05:42,210 --> 01:05:43,000
Jeg tror det var noen andre.

1500
01:05:43,000 --> 01:05:44,750
Jeg jobbet med en
kunde som fortalte meg

1501
01:05:44,750 --> 01:05:47,040
at nå som de har
gått til Dynamo DB, de er

1502
01:05:47,040 --> 01:05:50,330
bruker mer penger på snacks for
deres utvikling team hver måned

1503
01:05:50,330 --> 01:05:52,886
enn de bruker på deres database.

1504
01:05:52,886 --> 01:05:54,760
Så det vil gi deg en
Ideen om kostnadsbesparelser

1505
01:05:54,760 --> 01:05:57,889
at du kan få i Dynamo DB er stort.

1506
01:05:57,889 --> 01:05:59,430
Greit, dropcam et annet selskap.

1507
01:05:59,430 --> 01:06:02,138
Disse fyren er slags of-- hvis du tror
av internett av ting, dropcam

1508
01:06:02,138 --> 01:06:05,150
er i utgangspunktet internet security video.

1509
01:06:05,150 --> 01:06:06,660
Du setter kameraet der ute.

1510
01:06:06,660 --> 01:06:08,180
Kameraet har en bevegelsesdetektor.

1511
01:06:08,180 --> 01:06:10,290
Noen kommer sammen,
utløser en cue point.

1512
01:06:10,290 --> 01:06:13,540
Kameraet begynner å ta en stund til
det trenger ikke oppdage noen bevegelse lenger.

1513
01:06:13,540 --> 01:06:15,310
Setter at videoen opp på internett.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam var et selskap som er
utgangspunktet byttet til Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
fordi de var opplever
enorme voksesmerter.

1516
01:06:22,200 --> 01:06:25,820
Og hva de fortalte oss,
plutselig petabyte med data.

1517
01:06:25,820 --> 01:06:28,070
De hadde ingen anelse om deres tjeneste
ville være så vellykket.

1518
01:06:28,070 --> 01:06:32,310
Mer inngående video enn YouTube
er hva disse gutta får.

1519
01:06:32,310 --> 01:06:36,780
De bruker DynamoDB å spore alle
metadata på alle sine video viktige punkter.

1520
01:06:36,780 --> 01:06:40,282
>> Så de har S3 bøtter de presse
alle de binære gjenstander inn.

1521
01:06:40,282 --> 01:06:41,990
Og da de har
Dynamo DB poster som

1522
01:06:41,990 --> 01:06:44,070
peke folk til disse S3 tre stedene.

1523
01:06:44,070 --> 01:06:47,070
Når de trenger å se på en video,
de ser opp posten i Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
De klikker på linken.

1525
01:06:47,903 --> 01:06:49,770
De trekker ned video fra S3.

1526
01:06:49,770 --> 01:06:51,590
Så det er litt av hva dette ser ut som.

1527
01:06:51,590 --> 01:06:53,580
Og dette er rett fra deres team.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB reduserer deres
leveringstid for video hendelser

1529
01:06:56,010 --> 01:06:57,590
fra fem til ti sekunder.

1530
01:06:57,590 --> 01:07:00,470
I deres gamle relasjons butikken,
de pleide å ha til å gå og kjøre

1531
01:07:00,470 --> 01:07:03,780
flere komplekse spørringer til figuren
ut hvilke videoer for å trekke ned,

1532
01:07:03,780 --> 01:07:06,690
til mindre enn 50 millisekunder.

1533
01:07:06,690 --> 01:07:08,990
Så det er utrolig, utrolig
hvor mye ytelse

1534
01:07:08,990 --> 01:07:12,990
du kan få når du optimalisere og
du tune den underliggende database

1535
01:07:12,990 --> 01:07:15,110
å støtte tilgangsmønster.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, disse gutta, hva er det,
Fruit Ninja jeg antar er deres greie.

1537
01:07:20,500 --> 01:07:22,590
At alle kjører på Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
Og disse gutta, de er en stor
utvikling team, stor utvikling

1539
01:07:26,810 --> 01:07:27,670
butikk.

1540
01:07:27,670 --> 01:07:29,364
>> Ikke en god ops team.

1541
01:07:29,364 --> 01:07:31,280
De hadde ikke mye
av driftsressurser.

1542
01:07:31,280 --> 01:07:33,940
De kjempet for å prøve å holde
sin søknad infrastruktur opp

1543
01:07:33,940 --> 01:07:34,290
og kjører.

1544
01:07:34,290 --> 01:07:35,000
De kom til oss.

1545
01:07:35,000 --> 01:07:36,251
De så på at Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
De sa, det er for oss.

1547
01:07:37,291 --> 01:07:39,470
De bygget sin helhet
applikasjonsrammeverk på den.

1548
01:07:39,470 --> 01:07:43,640
Noen virkelig fine kommentarer her
fra teamet på deres evne

1549
01:07:43,640 --> 01:07:46,800
å nå fokusere på å bygge
spillet og ikke

1550
01:07:46,800 --> 01:07:49,010
å opprettholde
infrastruktur, som

1551
01:07:49,010 --> 01:07:51,910
var blitt en enorm mengde
av overhead for sitt lag.

1552
01:07:51,910 --> 01:07:56,170
Så dette er noe at-- den
nytte som du får fra Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> All right, komme inn
datamodellering her.

1554
01:08:00,930 --> 01:08:03,440
Og vi snakket litt om
dette til en, en til mange,

1555
01:08:03,440 --> 01:08:05,060
og mange til mange type relasjoner.

1556
01:08:05,060 --> 01:08:07,630
Og hvordan opprett du de i Dynamo.

1557
01:08:07,630 --> 01:08:10,500
I Dynamo DB bruker vi
indekser, generelt sett,

1558
01:08:10,500 --> 01:08:12,910
å rotere dataene fra
en smak til den andre.

1559
01:08:12,910 --> 01:08:15,210
Hash nøkler, range nøkler og indekser.

1560
01:08:15,210 --> 01:08:18,540
>> I denne spesielle
eksempel, som de fleste stater

1561
01:08:18,540 --> 01:08:23,802
har en lisensiering krav om at
bare ett førerkort per person.

1562
01:08:23,802 --> 01:08:26,510
Du kan ikke gå å få to fører
lisenser i delstaten Boston.

1563
01:08:26,510 --> 01:08:27,500
Jeg kan ikke gjøre det i Texas.

1564
01:08:27,500 --> 01:08:28,708
Det er på en måte sånn det er.

1565
01:08:28,708 --> 01:08:32,779
Og så på DMV, har vi oppslag, vi
ønsker å slå opp førerkort

1566
01:08:32,779 --> 01:08:35,180
av personnummer.

1567
01:08:35,180 --> 01:08:39,990
Jeg ønsker å slå opp brukerdetaljer
av førerkort nummer.

1568
01:08:39,990 --> 01:08:43,620
>> Så vi kan ha en brukers tabell som
har en firkanttasten på serienummer,

1569
01:08:43,620 --> 01:08:47,830
eller personnummer, og
forskjellige attributter definert på elementet.

1570
01:08:47,830 --> 01:08:49,859
Nå på det bordet jeg
kunne definere en GSI som

1571
01:08:49,859 --> 01:08:53,370
knipser at rundt som sier at jeg vil ha
et firkanttasten på lisensen og deretter

1572
01:08:53,370 --> 01:08:54,252
alle de andre elementene.

1573
01:08:54,252 --> 01:08:57,210
Nå hvis jeg ønsker å spørre og finne
lisensnummer for enhver Social

1574
01:08:57,210 --> 01:08:59,609
Security-nummer, kan jeg
spørhovedtabellen.

1575
01:08:59,609 --> 01:09:02,130
>> Hvis jeg ønsker å spørre, og jeg ønsker
for å få trygd

1576
01:09:02,130 --> 01:09:05,735
nummer eller andre attributter ved en
lisensnummer, kan jeg spørre GSI.

1577
01:09:05,735 --> 01:09:08,689
Denne modellen er at ett
til en forhold.

1578
01:09:08,689 --> 01:09:12,460
Bare en svært enkel GSI,
snu disse tingene rundt.

1579
01:09:12,460 --> 01:09:13,979
Nå, snakke om en til mange.

1580
01:09:13,979 --> 01:09:16,450
En til mange er i utgangspunktet
din hash utvalg nøkkelen.

1581
01:09:16,450 --> 01:09:20,510
Hvor vi får mye med dette
use case er overvåkingsdata.

1582
01:09:20,510 --> 01:09:23,880
Monitor data kommer i vanlig
intervall, som internett av ting.

1583
01:09:23,880 --> 01:09:26,890
Vi får alltid alle disse
poster som kommer inn hele tiden.

1584
01:09:26,890 --> 01:09:31,420
>> Og jeg ønsker å finne alle målinger
mellom en bestemt tidsperiode.

1585
01:09:31,420 --> 01:09:34,220
Det er en veldig vanlig spørring i
overvåking infrastruktur.

1586
01:09:34,220 --> 01:09:38,430
Måten gå om det er å finne en
enkel tabell struktur, ett bord.

1587
01:09:38,430 --> 01:09:42,250
Jeg har en utstyrsmålingene bord
med en firkanttasten på enheten ID.

1588
01:09:42,250 --> 01:09:47,340
Og jeg har en rekkevidde tast på
tidsstempel, eller i dette tilfellet, det episke.

1589
01:09:47,340 --> 01:09:50,350
Og det gjør meg utføre komplekse
spørringer mot dette området nøkkelen

1590
01:09:50,350 --> 01:09:54,950
og returnere disse postene som
står i forhold til resultatet

1591
01:09:54,950 --> 01:09:56,310
satt at jeg leter etter.

1592
01:09:56,310 --> 01:09:58,360
Og det bygger på at man
til mange relasjon

1593
01:09:58,360 --> 01:10:02,340
inn i det primære tabellen ved hjelp av
firkanttasten, rekkevidde nøkkelen struktur.

1594
01:10:02,340 --> 01:10:04,600
>> Så det er slags inne
i tabellen i Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Når jeg definerer en hash
og rekkevidde t bordet, jeg er

1596
01:10:07,290 --> 01:10:09,240
definerer et en til mange forhold.

1597
01:10:09,240 --> 01:10:12,770
Det er en foreldre-barn-forhold.

1598
01:10:12,770 --> 01:10:14,620
>> La oss snakke om mange
til mange relasjoner.

1599
01:10:14,620 --> 01:10:19,170
Og for dette spesielle eksempelet,
igjen, kommer vi til å bruke GSI-tallet.

1600
01:10:19,170 --> 01:10:23,500
Og la oss snakke om gaming
scenario hvor jeg har en gitt bruker.

1601
01:10:23,500 --> 01:10:26,500
Jeg ønsker å finne ut alle spillene som
han er registrert for eller spille inn.

1602
01:10:26,500 --> 01:10:29,600
Og for et gitt spill, I
ønsker å finne alle brukerne.

1603
01:10:29,600 --> 01:10:31,010
Så hvordan gjør jeg det?

1604
01:10:31,010 --> 01:10:34,330
Min bruker spill bord, jeg kommer
å ha en firkanttasten for bruker-ID

1605
01:10:34,330 --> 01:10:35,810
og en rekke nøkkel av spillet.

1606
01:10:35,810 --> 01:10:37,810
>> Slik at en bruker kan ha flere spill.

1607
01:10:37,810 --> 01:10:41,380
Det er en en til mange relasjon mellom
brukeren og de kampene han spiller.

1608
01:10:41,380 --> 01:10:43,410
Og deretter på GSI,
Jeg vil snu det rundt.

1609
01:10:43,410 --> 01:10:46,679
Jeg skal hash på spillet og
Jeg spenner på brukeren.

1610
01:10:46,679 --> 01:10:48,970
Så hvis jeg ønsker å få alle
Spillet brukerens spille i,

1611
01:10:48,970 --> 01:10:49,950
Jeg skal spørre hovedtabellen.

1612
01:10:49,950 --> 01:10:52,699
Hvis jeg ønsker å få alle brukere
som spiller et bestemt spill,

1613
01:10:52,699 --> 01:10:53,887
Jeg søke i GSI.

1614
01:10:53,887 --> 01:10:54,970
Så du se hvordan vi gjør dette?

1615
01:10:54,970 --> 01:10:58,369
Du bygger disse GSI er å støtte
bruk tilfellet programmet, tilgangs

1616
01:10:58,369 --> 01:10:59,410
mønster, søknaden.

1617
01:10:59,410 --> 01:11:01,440
>> Hvis jeg trenger å spørre om
denne dimensjonen, la

1618
01:11:01,440 --> 01:11:03,500
meg å opprette en indeks på denne dimensjonen.

1619
01:11:03,500 --> 01:11:05,850
Hvis jeg ikke gjør det, jeg bryr meg ikke.

1620
01:11:05,850 --> 01:11:09,060
Og avhengig av brukstilfellet, I
kan trenge indeksen eller jeg kanskje ikke.

1621
01:11:09,060 --> 01:11:12,390
Hvis det er en enkel en til mange,
den primære tabellen er fine.

1622
01:11:12,390 --> 01:11:15,860
Hvis jeg trenger å gjøre disse mange til
mange er, eller jeg trenger å gjøre en til seg,

1623
01:11:15,860 --> 01:11:18,390
så kanskje jeg trenger
til andre indeksen.

1624
01:11:18,390 --> 01:11:20,840
Så det kommer an på
det jeg prøver å gjøre

1625
01:11:20,840 --> 01:11:24,550
og hva jeg prøver å få dyktig.

1626
01:11:24,550 --> 01:11:28,000
>> Sannsynligvis jeg ikke kommer til å bruke for
mye tid på å snakke om dokumenter.

1627
01:11:28,000 --> 01:11:31,460
Dette blir litt, sannsynligvis,
dypere enn vi trenger å gå inn.

1628
01:11:31,460 --> 01:11:33,710
La oss snakke litt
om rike spør uttrykk.

1629
01:11:33,710 --> 01:11:37,831
Så i Dynamo DB har vi
evnen til å skape

1630
01:11:37,831 --> 01:11:39,330
det vi kaller projeksjon uttrykk.

1631
01:11:39,330 --> 01:11:42,660
Projeksjon uttrykk er rett og slett
plukke felt eller verdiene

1632
01:11:42,660 --> 01:11:44,290
som du vil vise.

1633
01:11:44,290 --> 01:11:46,000
OK, så jeg gjør et valg.

1634
01:11:46,000 --> 01:11:48,010
Jeg gjør en spørring mot Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
Og jeg sier, vet du hva, showet
me bare de fem stjerners anmeldelser

1636
01:11:51,730 --> 01:11:54,544
for dette spesielle produkt.

1637
01:11:54,544 --> 01:11:55,710
Så det er alt jeg ønsker å se.

1638
01:11:55,710 --> 01:11:57,320
Jeg ønsker ikke å se hele
andre attributter for rad,

1639
01:11:57,320 --> 01:11:58,319
Jeg vil bare se dette.

1640
01:11:58,319 --> 01:12:01,209
Det er akkurat som i SQL når du
si velger stjerne eller fra bordet,

1641
01:12:01,209 --> 01:12:02,000
du får alt.

1642
01:12:02,000 --> 01:12:05,450
Når jeg sier velger navn fra
bordet, jeg får bare ett attributt.

1643
01:12:05,450 --> 01:12:09,070
Det er samme type ting i
Dynamo DB eller annen NoSQL-databaser.

1644
01:12:09,070 --> 01:12:14,510
Filteruttrykk tillate meg å
utgangspunktet kutte resultatet satt ned.

1645
01:12:14,510 --> 01:12:15,540
Så jeg gjør et søk.

1646
01:12:15,540 --> 01:12:17,260
Spørring kan komme tilbake med 500 elementer.

1647
01:12:17,260 --> 01:12:20,255
Men jeg vil bare de elementene som
har en egenskap som sier dette.

1648
01:12:20,255 --> 01:12:23,380
OK, så la oss filtrere ut de elementene
som ikke samsvarer med det aktuelle søket.

1649
01:12:23,380 --> 01:12:25,540
Så vi har filteruttrykk.

1650
01:12:25,540 --> 01:12:28,310
>> Filteruttrykk kan
kjøres på en hvilken som helst attributt.

1651
01:12:28,310 --> 01:12:30,260
De er ikke som range spørringer.

1652
01:12:30,260 --> 01:12:32,690
Heve spørringer er mer selektive.

1653
01:12:32,690 --> 01:12:36,470
Filtrer spørsmål krever meg å gå
få hele resultatet satt og så

1654
01:12:36,470 --> 01:12:39,170
skjære ut dataene jeg ikke vil ha.

1655
01:12:39,170 --> 01:12:40,660
Hvorfor er det viktig?

1656
01:12:40,660 --> 01:12:42,770
Fordi jeg leste det hele tatt.

1657
01:12:42,770 --> 01:12:46,597
I en spørring, kommer jeg til å lese og
det kommer til å bli en gigantisk om data.

1658
01:12:46,597 --> 01:12:48,430
Og så kommer jeg til å
skjære ut det jeg trenger.

1659
01:12:48,430 --> 01:12:52,080
Og hvis jeg bare carving ut en
par rader, så det er OK.

1660
01:12:52,080 --> 01:12:53,620
Det er ikke så ineffektiv.

1661
01:12:53,620 --> 01:12:57,800
>> Men hvis jeg leser en hel haug av
data, bare for å skjære ut ett element,

1662
01:12:57,800 --> 01:13:01,490
så jeg kommer til å bli bedre
av ved hjelp av en rekke spørsmål,

1663
01:13:01,490 --> 01:13:03,030
fordi det er mye mer selektiv.

1664
01:13:03,030 --> 01:13:06,330
Det kommer til å spare meg mye
penger, fordi jeg betale for at lese.

1665
01:13:06,330 --> 01:13:10,430
Der resultatene som kommer tilbake
krysse at ledningen kan være mindre,

1666
01:13:10,430 --> 01:13:11,890
men jeg betaler for å lese.

1667
01:13:11,890 --> 01:13:14,340
Så forstå hvordan
du får dataene.

1668
01:13:14,340 --> 01:13:16,420
Det er veldig viktig i Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Betingelsesuttrykk, dette er hva
du kan kalle optimistisk låsing.

1670
01:13:19,710 --> 01:13:28,470
Oppdater IF eksisterer, eller hvis denne verdien
tilsvarer det jeg angir.

1671
01:13:28,470 --> 01:13:31,494
Og hvis jeg har en tidsangivelse på en
posten, jeg kan lese dataene.

1672
01:13:31,494 --> 01:13:32,535
Jeg kan endre disse dataene.

1673
01:13:32,535 --> 01:13:35,030
Jeg kan gå skrive at
data tilbake til databasen.

1674
01:13:35,030 --> 01:13:38,100
Hvis noen har endret posten,
tidsstempelet kan ha endret seg.

1675
01:13:38,100 --> 01:13:40,370
Og på den måten min betinget
Oppdateringen kan si oppdatering

1676
01:13:40,370 --> 01:13:42,340
hvis tidsstempel er lik denne.

1677
01:13:42,340 --> 01:13:46,290
Eller oppdateringen vil mislykkes fordi noen
oppdatert posten i mellomtiden.

1678
01:13:46,290 --> 01:13:48,290
>> Det er hva vi kaller optimistisk låsing.

1679
01:13:48,290 --> 01:13:50,670
Det betyr at noen
kan komme inn og endre det,

1680
01:13:50,670 --> 01:13:53,100
og jeg kommer til å oppdage det
når jeg går tilbake til å skrive.

1681
01:13:53,100 --> 01:13:56,106
Og så kan jeg faktisk lese at
data og si, oh, han endret dette.

1682
01:13:56,106 --> 01:13:57,230
Jeg trenger å ta hensyn til det.

1683
01:13:57,230 --> 01:14:00,490
Og jeg kan endre data i min
spille inn og bruke en annen oppdatering.

1684
01:14:00,490 --> 01:14:04,330
Så du kan fange de inkrementelle
oppdateringer som oppstår mellom tiden

1685
01:14:04,330 --> 01:14:08,740
at du leser data og
gang du kan skrive data.

1686
01:14:08,740 --> 01:14:11,520
>> PUBLIKUM: Og filteret
uttrykket egentlig betyr ikke

1687
01:14:11,520 --> 01:14:13,020
i antall eller not--

1688
01:14:13,020 --> 01:14:14,316
>> [Interposing VOICES]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: Jeg vil ikke
få for mye inn i dette.

1690
01:14:16,232 --> 01:14:17,700
Dette er et reservert nøkkelord.

1691
01:14:17,700 --> 01:14:20,130
Pundet syn er en reservert
søkeord i Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Hver database har sin egen reservert
navn for samlinger du ikke kan bruke.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, hvis du angir
et pund foran denne,

1694
01:14:27,240 --> 01:14:29,310
du kan definere disse navnene opp ovenfor.

1695
01:14:29,310 --> 01:14:31,840
Dette er verdien en referert.

1696
01:14:31,840 --> 01:14:34,880
Det er nok ikke den beste syntaks til
har oppe for denne diskusjonen,

1697
01:14:34,880 --> 01:14:38,090
fordi det kommer inn noen real--
Jeg ville ha snakket mer

1698
01:14:38,090 --> 01:14:41,360
om det på et dypere nivå.

1699
01:14:41,360 --> 01:14:46,130
>> Men nok til å si, dette kunne
være spørring skanner der de views--

1700
01:14:46,130 --> 01:14:50,190
heller pund utsikt er større enn 10.

1701
01:14:50,190 --> 01:14:54,660
Det er en numerisk verdi, ja.

1702
01:14:54,660 --> 01:14:57,322
Hvis du vil, kan vi snakke om
at etter diskusjonen.

1703
01:14:57,322 --> 01:15:00,030
Greit, så vi får inn
noen scenarier i beste praksis

1704
01:15:00,030 --> 01:15:02,000
hvor vi kommer til å snakke
om noen apps her.

1705
01:15:02,000 --> 01:15:03,810
Hva er de bruksmåter for Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Hva er design
mønstre i Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> Og det første vi kommer til å
snakk om er internett av ting.

1708
01:15:09,110 --> 01:15:15,010
Så vi får mye of-- antar jeg,
det som er it mer enn 50%

1709
01:15:15,010 --> 01:15:19,370
av trafikken på internett i disse dager
faktisk er generert av maskiner,

1710
01:15:19,370 --> 01:15:21,930
automatiserte prosesser, ikke av mennesker.

1711
01:15:21,930 --> 01:15:25,140
Jeg mener denne tingen denne tingen som
du bære rundt i lommen,

1712
01:15:25,140 --> 01:15:28,840
hvor mye data som at ting er
faktisk sender rundt uten deg

1713
01:15:28,840 --> 01:15:30,550
vet det er helt utrolig.

1714
01:15:30,550 --> 01:15:34,970
Din plassering, informasjon
om hvor fort du skal.

1715
01:15:34,970 --> 01:15:38,400
Hvordan tror du Google Maps fungerer
når de forteller deg hva trafikken er.

1716
01:15:38,400 --> 01:15:41,275
Det er fordi det er millioner og
millioner av mennesker kjører rundt

1717
01:15:41,275 --> 01:15:44,667
med telefoner som sender
data over stedet hele tiden.

1718
01:15:44,667 --> 01:15:46,500
Så en av de tingene
om denne typen data

1719
01:15:46,500 --> 01:15:50,980
som kommer inn, overvåkingsdata, logg
data, tidsseriedata, er det

1720
01:15:50,980 --> 01:15:53,540
vanligvis bare interessant
for en liten bit av gangen.

1721
01:15:53,540 --> 01:15:55,580
Etter den tid, er det
ikke så interessant.

1722
01:15:55,580 --> 01:15:58,390
Så vi snakket om, ikke la
disse tabellene vokse uten grenser.

1723
01:15:58,390 --> 01:16:03,410
Ideen her er at jeg kanskje har fått 24
timer igjen av hendelser i min varme tabellen.

1724
01:16:03,410 --> 01:16:06,160
Og det hot tabellen kommer til å være
klargjort på en svært høy rente,

1725
01:16:06,160 --> 01:16:07,950
fordi det tar mye data.

1726
01:16:07,950 --> 01:16:10,920
Det tar mye av data
og jeg leser det mye.

1727
01:16:10,920 --> 01:16:14,560
Jeg har fått mange operasjon
spørringer som kjører mot data.

1728
01:16:14,560 --> 01:16:18,120
>> Etter 24 timer, hei, du
Vet du hva, jeg bryr meg ikke.

1729
01:16:18,120 --> 01:16:21,150
Så kanskje hver midnatt jeg roll
mitt bord over til en ny tabell

1730
01:16:21,150 --> 01:16:22,430
og jeg deprovision denne tabellen.

1731
01:16:22,430 --> 01:16:26,440
Og jeg skal ta RCU og
WCU er nede fordi 24 timer senere

1732
01:16:26,440 --> 01:16:28,630
Jeg kjører ikke så mange
spørringer mot at data.

1733
01:16:28,630 --> 01:16:30,200
Så jeg kommer til å spare penger.

1734
01:16:30,200 --> 01:16:32,940
Og kanskje 30 dager senere jeg ikke
engang trenger å bry seg om det hele.

1735
01:16:32,940 --> 01:16:35,020
Jeg kunne ta WCU s
helt ned til en,

1736
01:16:35,020 --> 01:16:36,990
fordi du vet hva, er det
aldri kommer til å bli skrevet til.

1737
01:16:36,990 --> 01:16:38,300
Dataene er 30 dager gamle.

1738
01:16:38,300 --> 01:16:40,000
Det forandrer aldri.

1739
01:16:40,000 --> 01:16:44,200
>> Og det er nesten aldri kommer til å få lese,
så la oss bare ta det RCU ned til 10.

1740
01:16:44,200 --> 01:16:49,372
Og jeg sparer massevis av penger på denne
data, og bare betale for mine varme data.

1741
01:16:49,372 --> 01:16:52,330
Så det er det viktigste å se
på når du ser på en tidsserie

1742
01:16:52,330 --> 01:16:54,716
data som kommer inn i volum.

1743
01:16:54,716 --> 01:16:55,590
Dette er strategier.

1744
01:16:55,590 --> 01:16:58,010
Nå kunne jeg bare la det
alle gå til samme bord

1745
01:16:58,010 --> 01:16:59,461
og bare la det bordet vokse.

1746
01:16:59,461 --> 01:17:01,460
Etter hvert kommer jeg til å
se ytelsesproblemer.

1747
01:17:01,460 --> 01:17:04,060
Jeg er nødt til å begynne å arkivere
noen av disse data av bordet,

1748
01:17:04,060 --> 01:17:04,720
hva ikke.

1749
01:17:04,720 --> 01:17:07,010
>> La oss mye bedre
designe din søknad

1750
01:17:07,010 --> 01:17:08,900
slik at du kan operere på denne måten rett.

1751
01:17:08,900 --> 01:17:11,460
Så det er bare automatisk
i applikasjonskoden.

1752
01:17:11,460 --> 01:17:13,580
Ved midnatt hver kveld
den ruller tabellen.

1753
01:17:13,580 --> 01:17:17,170
Kanskje det jeg trenger er en glid
vinduet i 24 timer med data.

1754
01:17:17,170 --> 01:17:20,277
Så på en jevnlig basis er jeg
kalle data av bordet.

1755
01:17:20,277 --> 01:17:22,360
Jeg trimming det med en
Cron jobb og jeg setter det

1756
01:17:22,360 --> 01:17:24,160
på disse andre tabeller,
det du trenger.

1757
01:17:24,160 --> 01:17:25,940
Så hvis en roll fungerer, det er flott.

1758
01:17:25,940 --> 01:17:27,080
Hvis ikke, trimme den.

1759
01:17:27,080 --> 01:17:29,640
Men la oss holde det varmt data
vekk fra kalde data.

1760
01:17:29,640 --> 01:17:32,535
Det vil spare deg for mye penger og
gjøre tabellene mer utøvende.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Så neste ting vi skal snakke
om er produktkatalogen.

1763
01:17:38,210 --> 01:17:42,000
Produktkatalog er
ganske vanlig brukstilfelle.

1764
01:17:42,000 --> 01:17:46,600
Dette er faktisk en veldig vanlig mønster
at vi vil se i en rekke ting.

1765
01:17:46,600 --> 01:17:48,870
Du vet, Twitter for
eksempel en varm tweet.

1766
01:17:48,870 --> 01:17:51,280
Alle som kommer og
gripe tak som tweet.

1767
01:17:51,280 --> 01:17:52,680
Produktkatalog, fikk jeg et salg.

1768
01:17:52,680 --> 01:17:54,120
Jeg fikk en varm salg.

1769
01:17:54,120 --> 01:17:57,277
Jeg fikk 70.000 henvendelser per
andre kommer etter et produkt

1770
01:17:57,277 --> 01:17:58,860
beskrivelse av min produktkatalog.

1771
01:17:58,860 --> 01:18:02,384
Vi ser dette i person
drift ganske mye.

1772
01:18:02,384 --> 01:18:03,550
Så hvordan håndtere vi med det?

1773
01:18:03,550 --> 01:18:04,924
Det er ingen måte å håndtere det.

1774
01:18:04,924 --> 01:18:07,110
Alle mine brukere ønsker å se
samme stykke data.

1775
01:18:07,110 --> 01:18:09,410
De kommer inn, samtidig.

1776
01:18:09,410 --> 01:18:11,920
Og de er alle gjør forespørsler
for samme stykke data.

1777
01:18:11,920 --> 01:18:16,240
Dette gir meg som hurtigtast, som store røde
stripe på min diagram som vi ikke liker.

1778
01:18:16,240 --> 01:18:17,720
Og det er det som ser ut som.

1779
01:18:17,720 --> 01:18:22,290
Så over nøkkelen min plass jeg får
hamret i salg elementer.

1780
01:18:22,290 --> 01:18:24,070
Jeg får ikke noe annet sted.

1781
01:18:24,070 --> 01:18:26,050
>> Hvordan lindre jeg dette problemet?

1782
01:18:26,050 --> 01:18:28,410
Vel, vi lindre dette med cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, sette deg i utgangspunktet en in-memory
skillevegg foran databasen.

1784
01:18:33,630 --> 01:18:37,260
Vi har klart
[Uhørbart] cache, hvordan du

1785
01:18:37,260 --> 01:18:40,260
kan sette opp din egen cache, [uhørbart]
cache [? d,?] hva du vil.

1786
01:18:40,260 --> 01:18:42,220
Sette det opp foran databasen.

1787
01:18:42,220 --> 01:18:47,250
Og på den måten du kan lagre disse dataene
fra disse hurtigtastene opp i at cache

1788
01:18:47,250 --> 01:18:49,390
plass og lese gjennom cache.

1789
01:18:49,390 --> 01:18:51,962
>> Og da de fleste av din leser
begynne å se slik ut.

1790
01:18:51,962 --> 01:18:54,920
Jeg fikk alle disse cache treffer deg her
og jeg fikk ingenting skjer her nede

1791
01:18:54,920 --> 01:18:59,330
fordi database sitter bak
cache og leser aldri komme gjennom.

1792
01:18:59,330 --> 01:19:02,520
Hvis jeg endrer dataene i
database, må jeg oppdatere cache.

1793
01:19:02,520 --> 01:19:04,360
Vi kan bruke noe
som damper å gjøre det.

1794
01:19:04,360 --> 01:19:07,360
Og jeg skal forklare hvordan det fungerer.

1795
01:19:07,360 --> 01:19:09,060
Greit, meldinger.

1796
01:19:09,060 --> 01:19:11,180
E-post, vi alle bruker e-post.

1797
01:19:11,180 --> 01:19:12,540
>> Dette er et ganske godt eksempel.

1798
01:19:12,540 --> 01:19:14,950
Vi har fått en slags meldinger tabellen.

1799
01:19:14,950 --> 01:19:17,040
Og vi fikk innboks og utboks.

1800
01:19:17,040 --> 01:19:19,760
Dette er hva SQL ville
se ut til å bygge på at innboksen.

1801
01:19:19,760 --> 01:19:23,350
Vi slags bruker samme type
av strategi å bruke GSI-tallet, GSI s

1802
01:19:23,350 --> 01:19:25,320
for min innboks og min utboks.

1803
01:19:25,320 --> 01:19:27,600
Så jeg fikk rå meldinger kommer
inn i min meldinger tabellen.

1804
01:19:27,600 --> 01:19:30,194
Og den første tilnærming til dette
kan være, sier, OK, ikke noe problem.

1805
01:19:30,194 --> 01:19:31,110
Jeg har fått rå meldinger.

1806
01:19:31,110 --> 01:19:33,710
Meldinger som kommer [uhørbart],
Meldingen ID, det er flott.

1807
01:19:33,710 --> 01:19:35,070
Det er min unike hash.

1808
01:19:35,070 --> 01:19:38,280
Jeg kommer til å lage to GSI er, en
for min innboks, en for min utboks.

1809
01:19:38,280 --> 01:19:40,530
Og det første jeg skal gjøre
er jeg skal si min firkanttasten er

1810
01:19:40,530 --> 01:19:43,310
kommer til å være mottaker og
Jeg kommer til å ordne på dato.

1811
01:19:43,310 --> 01:19:44,220
Dette er fantastisk.

1812
01:19:44,220 --> 01:19:45,890
Jeg fikk min fin utsikt her.

1813
01:19:45,890 --> 01:19:47,780
Men det er et lite problem her.

1814
01:19:47,780 --> 01:19:50,891
Og du kjører inn i dette i
relasjonsdatabaser også.

1815
01:19:50,891 --> 01:19:52,390
De kalte vertikalt partisjonering.

1816
01:19:52,390 --> 01:19:55,840
Du ønsker å holde store data
bort fra lite data.

1817
01:19:55,840 --> 01:20:00,470
>> Og grunnen er fordi jeg må
gå lese elementer for å få attributtene.

1818
01:20:00,470 --> 01:20:05,570
Og hvis mine organer er alle på her,
deretter lese bare noen få elementer

1819
01:20:05,570 --> 01:20:08,560
hvis kroppen min lengde er
gjennomsnitt 256 kilobyte hver,

1820
01:20:08,560 --> 01:20:10,991
regnestykket blir ganske stygg.

1821
01:20:10,991 --> 01:20:12,490
Så sier jeg ønsker å lese David innboks.

1822
01:20:12,490 --> 01:20:14,520
David innboks har 50 elementer.

1823
01:20:14,520 --> 01:20:17,880
Gjennomsnittlig og størrelsen er 256 kilobyte.

1824
01:20:17,880 --> 01:20:21,730
Her er min bytteforhold
for RCU s er fire kilobyte.

1825
01:20:21,730 --> 01:20:24,450
>> OK, la oss gå med
slutt konsekvent leser.

1826
01:20:24,450 --> 01:20:28,640
Jeg er fortsatt spiser 1600 RCU s
bare for å lese David innboks.

1827
01:20:28,640 --> 01:20:29,950
Au.

1828
01:20:29,950 --> 01:20:31,980
OK, nå la oss tenke
om hvordan programmet fungerer.

1829
01:20:31,980 --> 01:20:35,340
Hvis jeg er i en e-post-appen og
Jeg ser på min innboks,

1830
01:20:35,340 --> 01:20:39,680
og jeg ser på kroppen av hver melding,
Nei, jeg ser på oppsummeringene.

1831
01:20:39,680 --> 01:20:41,850
Jeg ser på bare overskriftene.

1832
01:20:41,850 --> 01:20:46,310
Så la oss bygge en tabell struktur
som ser mer ut som.

1833
01:20:46,310 --> 01:20:49,470
>> Så her er det informasjon
at min arbeidsflyt trenger.

1834
01:20:49,470 --> 01:20:50,890
Det er i min innboks GSI.

1835
01:20:50,890 --> 01:20:53,800
Det er den dato, avsender,
emnet, og deretter

1836
01:20:53,800 --> 01:20:56,790
meldingen ID, som peker
tilbake til meldinger bordet

1837
01:20:56,790 --> 01:20:57,850
hvor jeg kan få kroppen.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Vel, disse vil være rekord IDer.

1840
01:21:04,420 --> 01:21:09,850
De vil peke tilbake til
element IDer på Dynamo DB tabellen.

1841
01:21:09,850 --> 01:21:12,220
Hver indeks alltid creates--
alltid har elementet

1842
01:21:12,220 --> 01:21:15,750
ID som en del of-- at
kommer med indeksen.

1843
01:21:15,750 --> 01:21:17,414
>> Greit.

1844
01:21:17,414 --> 01:21:19,080
PUBLIKUM: Det forteller den hvor den er lagret?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Ja, det forteller
exactly-- det er akkurat det det gjør.

1846
01:21:21,420 --> 01:21:22,644
Det står her er min re posten.

1847
01:21:22,644 --> 01:21:24,310
Og det vil peke det tilbake til min re posten.

1848
01:21:24,310 --> 01:21:26,460
Nettopp.

1849
01:21:26,460 --> 01:21:29,490
OK, så nå innboksen min er
faktisk er mye mindre.

1850
01:21:29,490 --> 01:21:32,210
Og dette støtter faktisk
arbeidsflyten av en e-post-appen.

1851
01:21:32,210 --> 01:21:34,230
Så innboksen min, jeg klikker.

1852
01:21:34,230 --> 01:21:38,160
Jeg går sammen og jeg klikker på meldingen,
det er da jeg må gå får kroppen,

1853
01:21:38,160 --> 01:21:40,180
fordi jeg kommer til å
gå til et annet syn.

1854
01:21:40,180 --> 01:21:43,870
Så hvis du tenker på MVC type
rammeverk, modell view controller.

1855
01:21:43,870 --> 01:21:46,120
>> Modellen inneholder
data at utsikten behov

1856
01:21:46,120 --> 01:21:48,130
og styreenheten kommuniserer med.

1857
01:21:48,130 --> 01:21:51,670
Når jeg endre ramme, når
Jeg endre perspektivet,

1858
01:21:51,670 --> 01:21:55,080
det er greit å gå tilbake til
server og fylle den på modellen,

1859
01:21:55,080 --> 01:21:56,860
fordi det er hva brukeren forventer.

1860
01:21:56,860 --> 01:22:00,530
Når de endrer utsikt, det er da
vi kan gå tilbake til databasen.

1861
01:22:00,530 --> 01:22:02,480
Så e-post, klikk.

1862
01:22:02,480 --> 01:22:03,710
Jeg ser for kroppen.

1863
01:22:03,710 --> 01:22:04,330
Rundtur.

1864
01:22:04,330 --> 01:22:05,680
Gå få kroppen.

1865
01:22:05,680 --> 01:22:06,950
>> Jeg leser mye mindre data.

1866
01:22:06,950 --> 01:22:09,960
Jeg bare leser de organer som
David trenger når han trenger dem.

1867
01:22:09,960 --> 01:22:14,230
Og jeg er ikke brenne i 1600
RCU oss bare for å vise sin innboks.

1868
01:22:14,230 --> 01:22:17,670
Så nå at-- dette er veien
som LSI eller GSI-- Jeg beklager,

1869
01:22:17,670 --> 01:22:19,900
GSI, ville fungere.

1870
01:22:19,900 --> 01:22:25,450
Vi har fått vår hash på mottakeren.

1871
01:22:25,450 --> 01:22:27,030
Vi har utvalget tasten på dato.

1872
01:22:27,030 --> 01:22:31,380
Og vi har fått de forventede attributter
at vi bare trenger å støtte synet.

1873
01:22:31,380 --> 01:22:34,300
>> Vi roter det til utboksen.

1874
01:22:34,300 --> 01:22:35,770
Hash på avsenderen.

1875
01:22:35,770 --> 01:22:39,612
Og i hovedsak, har vi
veldig fin, ren utsikt.

1876
01:22:39,612 --> 01:22:41,570
Og det er basically-- vi
har denne fine meldinger

1877
01:22:41,570 --> 01:22:45,870
tabell som blir spredt pent fordi
det er hash bare, hashet melding ID.

1878
01:22:45,870 --> 01:22:51,750
Og vi har to indekser som
roterer ut av tabellen.

1879
01:22:51,750 --> 01:22:57,411
All right, så Ideen her er ikke
holde de store data og denne lille data

1880
01:22:57,411 --> 01:22:57,910
i lag.

1881
01:22:57,910 --> 01:23:00,700
Partition vertikalt,
partisjonere disse tabellene.

1882
01:23:00,700 --> 01:23:03,150
Ikke lese data du ikke må.

1883
01:23:03,150 --> 01:23:04,850
Greit, gaming.

1884
01:23:04,850 --> 01:23:06,990
Vi liker alle spillene.

1885
01:23:06,990 --> 01:23:10,902
Minst Jeg liker spill da.

1886
01:23:10,902 --> 01:23:12,735
Så noen av de tingene
at vi forholde seg til når

1887
01:23:12,735 --> 01:23:14,193
vi tenker om spill, ikke sant?

1888
01:23:14,193 --> 01:23:16,999
Gaming i disse dager, spesielt mobil
gaming, handler om tenkning.

1889
01:23:16,999 --> 01:23:19,540
Og jeg kommer til å rotere her
litt bort fra DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Jeg kommer til å få inn
noen av diskusjonen

1891
01:23:21,373 --> 01:23:24,240
rundt noen av
andre AWS teknologier.

1892
01:23:24,240 --> 01:23:28,930
>> Men ideen om gaming er å tenke
om i form av APIer, APIer som er,

1893
01:23:28,930 --> 01:23:31,730
generelt sett, HTTP og JSON.

1894
01:23:31,730 --> 01:23:34,550
Det er hvordan mobile spill slags
samhandle med sine tilbake ender.

1895
01:23:34,550 --> 01:23:35,850
De gjør JSON innlegg.

1896
01:23:35,850 --> 01:23:40,660
De får data, og det er alt,
generelt sett, i fin JSON APIer.

1897
01:23:40,660 --> 01:23:44,950
>> Ting som får venner, få
de leaderboard, utveksle data,

1898
01:23:44,950 --> 01:23:47,699
brukergenerert innhold,
skyve tilbake til systemet,

1899
01:23:47,699 --> 01:23:49,740
disse er typer ting
at vi kommer til å gjøre.

1900
01:23:49,740 --> 01:23:52,542
Binary aktivum data, disse dataene
ikke kan sitte i databasen.

1901
01:23:52,542 --> 01:23:54,250
Dette kan sitte i en
objekt butikken, ikke sant?

1902
01:23:54,250 --> 01:23:56,541
Men databasen skal
ender opp med å fortelle systemet,

1903
01:23:56,541 --> 01:23:59,140
forteller programmet
hvor du skal gå få det.

1904
01:23:59,140 --> 01:24:03,550
Og uunngåelig, multiplayer
servere, back end infrastruktur,

1905
01:24:03,550 --> 01:24:06,180
og konstruert for høy
tilgjengelighet og skalerbarhet.

1906
01:24:06,180 --> 01:24:09,400
Så dette er ting som vi alle ønsker
i gaming infrastruktur i dag.

1907
01:24:09,400 --> 01:24:12,160
>> Så la oss ta en titt på
hva som ser ut som.

1908
01:24:12,160 --> 01:24:16,070
Fikk en kjerne bakenden,
veldig grei.

1909
01:24:16,070 --> 01:24:19,880
Vi har et system her med
flere tilgjengelighet soner.

1910
01:24:19,880 --> 01:24:23,780
Vi snakket om AZS som being-- tror
av dem som egne datasentre.

1911
01:24:23,780 --> 01:24:26,040
Mer enn en datasenter
per AZ, men det er OK,

1912
01:24:26,040 --> 01:24:28,831
bare tenke på dem som separate data
sentre som er geografisk

1913
01:24:28,831 --> 01:24:30,090
og feil isolert.

1914
01:24:30,090 --> 01:24:32,172
>> Vi kommer til å ha en
par EC2 instanser.

1915
01:24:32,172 --> 01:24:33,880
Vi kommer til å ha
noen back end server.

1916
01:24:33,880 --> 01:24:35,800
Kanskje hvis du er en arv
arkitektur, er vi

1917
01:24:35,800 --> 01:24:38,920
bruker det vi kaller RDS,
relasjonsdatabasetjenester.

1918
01:24:38,920 --> 01:24:42,040
Kan være MSSQL, MySQL,
eller noe sånt.

1919
01:24:42,040 --> 01:24:47,080
Dette er måten en masse søknader
er utformet i dag.

1920
01:24:47,080 --> 01:24:49,594
>> Vel vi kanskje vil gå med
dette er når vi skalere ut.

1921
01:24:49,594 --> 01:24:51,510
Vi vil gå foran og sette
S3 bøtte der oppe.

1922
01:24:51,510 --> 01:24:54,200
Og at S3 bøtte, i stedet for å tjene
opp disse objektene fra vår servers--

1923
01:24:54,200 --> 01:24:55,220
vi kunne gjøre det.

1924
01:24:55,220 --> 01:24:57,210
Du setter all din binære
objekter på dine servere

1925
01:24:57,210 --> 01:24:59,751
og du kan bruke de som server
instanser for å tjene disse dataene opp.

1926
01:24:59,751 --> 01:25:01,860
Men det er ganske dyrt.

1927
01:25:01,860 --> 01:25:05,107
>> Bedre måte å gjøre er å gå foran og
sette disse objektene i en S3 bøtte.

1928
01:25:05,107 --> 01:25:06,315
S3 er et objekt repositories.

1929
01:25:06,315 --> 01:25:10,860
Det er bygget spesielt for
tjene opp slike ting.

1930
01:25:10,860 --> 01:25:13,690
Og la disse klientene be
direkte fra disse objekt bøtter,

1931
01:25:13,690 --> 01:25:15,390
avlaste serverne.

1932
01:25:15,390 --> 01:25:17,020
Så vi begynner å skalere ut her.

1933
01:25:17,020 --> 01:25:19,140
>> Nå fikk vi brukere over hele verden.

1934
01:25:19,140 --> 01:25:19,730
Jeg fikk brukere.

1935
01:25:19,730 --> 01:25:23,380
Jeg må ha innhold lokalt
ligger i nærheten av disse brukerne, ikke sant?

1936
01:25:23,380 --> 01:25:26,200
Jeg har opprettet en S3 bøtte
som min kilde depotet.

1937
01:25:26,200 --> 01:25:29,370
Og jeg skal fram at med
den CloudFront distribusjon.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront er en CD og en
Content Delivery Network.

1939
01:25:31,720 --> 01:25:35,750
I utgangspunktet tar det data som du angir
og bufrer det over hele internett

1940
01:25:35,750 --> 01:25:39,230
slik at brukerne overalt kan ha
en meget rask respons når

1941
01:25:39,230 --> 01:25:40,960
de ber om disse stedene.

1942
01:25:40,960 --> 01:25:41,960
>> Så du får en idé.

1943
01:25:41,960 --> 01:25:48,230
Dere slags utnytte alle
aspekter av AWS her for å få dette gjort.

1944
01:25:48,230 --> 01:25:50,790
Og til slutt, vi kaster
i en auto-skalering gruppe.

1945
01:25:50,790 --> 01:25:52,737
Så våre AC2 tilfeller
av våre spillservere,

1946
01:25:52,737 --> 01:25:54,820
som de begynner å bli travlere
og travlere og travlere,

1947
01:25:54,820 --> 01:25:57,236
de vil bare spinne en annen
eksempel spinne et annet eksempel,

1948
01:25:57,236 --> 01:25:58,210
spinne et annet eksempel.

1949
01:25:58,210 --> 01:26:02,090
Så teknologien AWS har, det
lar deg spesifisere parametere

1950
01:26:02,090 --> 01:26:04,650
rundt der serverne vil vokse.

1951
01:26:04,650 --> 01:26:08,110
Så du kan ha n antall servere
det ut til enhver tid.

1952
01:26:08,110 --> 01:26:11,870
Og hvis lasten går bort, vil de
krympe, vil antallet krympe.

1953
01:26:11,870 --> 01:26:15,250
Og hvis lasten kommer tilbake,
det vil vokse ut igjen, elastisk.

1954
01:26:15,250 --> 01:26:17,050
>> Så dette ser flott ut.

1955
01:26:17,050 --> 01:26:19,800
Vi har fått mange EC2 instanser.

1956
01:26:19,800 --> 01:26:21,671
Vi kan sette cache i
foran databasene,

1957
01:26:21,671 --> 01:26:23,045
prøve og akselerere databasene.

1958
01:26:23,045 --> 01:26:25,030
Den neste trykkpunkt
typisk folk ser

1959
01:26:25,030 --> 01:26:28,850
er de skalere et spill ved hjelp av en
relasjonsdatabasesystem.

1960
01:26:28,850 --> 01:26:30,790
Jeez, databasen
Forestillingen er forferdelig.

1961
01:26:30,790 --> 01:26:31,932
Hvordan forbedrer vi det?

1962
01:26:31,932 --> 01:26:33,640
La oss prøve å sette
cache foran det.

1963
01:26:33,640 --> 01:26:36,780
>> Vel, cache fungerer ikke
så stor i spill, ikke sant?

1964
01:26:36,780 --> 01:26:39,330
For spill, skriving er smertefullt.

1965
01:26:39,330 --> 01:26:40,930
Spill er veldig skrive tung.

1966
01:26:40,930 --> 01:26:43,610
Cache fungerer ikke når du er
skrive tung fordi du har alltid

1967
01:26:43,610 --> 01:26:44,610
fikk å oppdatere cache.

1968
01:26:44,610 --> 01:26:47,780
Du oppdaterer cache, det er
irrelevant å bli caching.

1969
01:26:47,780 --> 01:26:49,780
Det er faktisk bare ekstra arbeid.

1970
01:26:49,780 --> 01:26:51,970
>> Så hvor går vi her?

1971
01:26:51,970 --> 01:26:54,400
Du har en stor flaskehals
der nede i databasen.

1972
01:26:54,400 --> 01:26:57,661
Og stedet å gå
åpenbart er partisjonering.

1973
01:26:57,661 --> 01:26:59,410
Partisjonering er ikke
lett å gjøre når du er

1974
01:26:59,410 --> 01:27:01,900
arbeider med relasjonsdatabaser.

1975
01:27:01,900 --> 01:27:05,080
Med relasjonsdatabaser, er du
ansvarlig for å administrere, effektivt,

1976
01:27:05,080 --> 01:27:06,210
nøkkelen plass.

1977
01:27:06,210 --> 01:27:10,527
Du sier brukerne mellom A og M
gå her, mellom N og Z gå dit.

1978
01:27:10,527 --> 01:27:12,360
Og du bytter
på tvers av søknaden.

1979
01:27:12,360 --> 01:27:15,000
Så du arbeider med
denne partisjonen datakilde.

1980
01:27:15,000 --> 01:27:18,670
Du har transaksjons begrensninger
som ikke spenner partisjoner.

1981
01:27:18,670 --> 01:27:20,560
Du har alle typer
messi at du er

1982
01:27:20,560 --> 01:27:23,040
arbeider med der nede prøver
å forholde seg til skalering ut

1983
01:27:23,040 --> 01:27:25,120
og å bygge en større infrastruktur.

1984
01:27:25,120 --> 01:27:27,284
Det er bare ikke morsomt.

1985
01:27:27,284 --> 01:27:30,930
>> PUBLIKUM: Så sier du at
økende kildepunkter raskere

1986
01:27:30,930 --> 01:27:31,430
prosessen?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Økende?

1988
01:27:32,513 --> 01:27:33,520
PUBLIKUM: Source poeng.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Source poeng?

1990
01:27:34,410 --> 01:27:37,500
PUBLIKUM: Fra informasjonen,
hvor informasjonen kommer fra?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: No.

1992
01:27:38,250 --> 01:27:41,820
Det jeg sier er å øke
antall partisjoner i datalageret

1993
01:27:41,820 --> 01:27:44,060
forbedrer gjennomstrømming.

1994
01:27:44,060 --> 01:27:48,300
Så hva er det som skjer her er brukere
kommer inn i EC2 eksempel her oppe,

1995
01:27:48,300 --> 01:27:50,780
vel, hvis jeg trenger en bruker
det er A til M, vil jeg gå her.

1996
01:27:50,780 --> 01:27:53,560
Fra N til p, vil jeg gå her.

1997
01:27:53,560 --> 01:27:55,060
Fra P til Z, vil jeg gå her.

1998
01:27:55,060 --> 01:27:57,120
>> PUBLIKUM: OK, de så de er
alle lagret i forskjellige noder?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Ja.

2000
01:27:57,911 --> 01:28:00,210
Tenk på disse som
forskjellige siloer av data.

2001
01:28:00,210 --> 01:28:01,660
Så du trenger å gjøre dette.

2002
01:28:01,660 --> 01:28:02,910
Hvis du prøver å gjøre
dette, hvis du prøver

2003
01:28:02,910 --> 01:28:05,730
å skalere på en relasjons plattform,
dette er hva du gjør.

2004
01:28:05,730 --> 01:28:08,100
Du tar data og
du klipper den ned.

2005
01:28:08,100 --> 01:28:10,975
Og du partisjonere den på tvers
flere forekomster av databasen.

2006
01:28:10,975 --> 01:28:13,580
Og du administrerer alt
på applikasjons tier.

2007
01:28:13,580 --> 01:28:14,729
Det er ikke morsomt.

2008
01:28:14,729 --> 01:28:15,770
Så hva gjør vi ønsker å gå?

2009
01:28:15,770 --> 01:28:20,240
Vi ønsker å gå DynamoDB, fullstendig styrt,
NoSQL datalageret, bestemmelse gjennomstrømming.

2010
01:28:20,240 --> 01:28:22,680
Vi bruker sekundære indekser.

2011
01:28:22,680 --> 01:28:26,154
Det er i utgangspunktet HTTP API og
omfatter dokumentstøtte.

2012
01:28:26,154 --> 01:28:28,570
Så du trenger ikke å bekymre deg
om noe av det partisjonering.

2013
01:28:28,570 --> 01:28:30,740
Vi gjør alt for deg.

2014
01:28:30,740 --> 01:28:33,260
Så nå, i stedet, du
bare skrive til bordet.

2015
01:28:33,260 --> 01:28:36,490
Hvis tabellen må være partisjonert,
som skjer bak kulissene.

2016
01:28:36,490 --> 01:28:40,642
Du er helt isolert
fra det som en utvikler.

2017
01:28:40,642 --> 01:28:42,350
Så la oss snakke om
noen av de bruksmåter

2018
01:28:42,350 --> 01:28:47,564
at vi kjører inn i gaming, felles
gaming scenarier, leaderboard.

2019
01:28:47,564 --> 01:28:49,980
Så du har brukere som kommer inn,
de BoardNames at de er

2020
01:28:49,980 --> 01:28:52,930
på, resultatet for denne brukeren.

2021
01:28:52,930 --> 01:28:57,700
Vi kan hashing på BrukerID,
og da har vi hold til spillet.

2022
01:28:57,700 --> 01:28:59,960
Så hver brukeren ønsker å se
hele spillet han har spilt

2023
01:28:59,960 --> 01:29:01,770
og alle hans bestenotering
over hele spillet.

2024
01:29:01,770 --> 01:29:04,000
Så det er hans personlige leaderboard.

2025
01:29:04,000 --> 01:29:10,010
>> Nå ønsker jeg å gå i, og jeg ønsker å get--
så jeg får disse personlige topplister.

2026
01:29:10,010 --> 01:29:12,827
Det jeg ønsker å gjøre er å gå får
toppscore på tvers av alle brukere.

2027
01:29:12,827 --> 01:29:13,660
Så hvordan gjør jeg det?

2028
01:29:13,660 --> 01:29:18,070
Da min rekord er hashet på
den UserID, varierte på spillet,

2029
01:29:18,070 --> 01:29:20,740
vel jeg kommer til å gå videre
og restrukturere, skape en GSI,

2030
01:29:20,740 --> 01:29:22,370
og jeg kommer til å restrukturere disse dataene.

2031
01:29:22,370 --> 01:29:27,310
>> Nå skal jeg til hasj på
BoardName, som er spillet.

2032
01:29:27,310 --> 01:29:29,800
Og jeg kommer til å variere på topp score.

2033
01:29:29,800 --> 01:29:31,540
Og nå har jeg laget forskjellige skuffer.

2034
01:29:31,540 --> 01:29:34,790
Jeg bruker den samme tabellen,
den samme varen data.

2035
01:29:34,790 --> 01:29:39,870
Men jeg lage en bøtte som gir
meg en samling av topp score av spillet.

2036
01:29:39,870 --> 01:29:43,180
>> Og jeg kan spørre denne tabellen
å få den informasjonen.

2037
01:29:43,180 --> 01:29:50,890
Så jeg har satt dette søket mønster opp til
være støttet av en sekundær indeks.

2038
01:29:50,890 --> 01:29:54,556
Nå kan de bli sortert etter BoardName
og sortert etter TopScore, avhengig av.

2039
01:29:54,556 --> 01:29:57,180
Så du kan se, er disse typene
av bruk tilfeller du får i gaming.

2040
01:29:57,180 --> 01:30:02,190
En annen god bruk tilfelle vi får i gaming
er utmerkelser og som har vunnet priser.

2041
01:30:02,190 --> 01:30:05,340
Og dette er en stor use case
der vi kaller sparsom indekser.

2042
01:30:05,340 --> 01:30:07,340
Sparsom indekser er
evne til å generere

2043
01:30:07,340 --> 01:30:10,850
en indeks som ikke nødvendigvis
inneholder hver enkelt element på bordet.

2044
01:30:10,850 --> 01:30:11,470
Og hvorfor ikke?

2045
01:30:11,470 --> 01:30:14,540
Fordi attributt som er å være
indeksert ikke finnes på hvert element.

2046
01:30:14,540 --> 01:30:16,460
>> Så i denne spesielle
bruke saken, jeg sa:

2047
01:30:16,460 --> 01:30:19,240
vet du hva, jeg kommer til å
opprette et attributt kalt Award.

2048
01:30:19,240 --> 01:30:22,970
Og jeg kommer til å gi hver bruker
som har en pris som attributt.

2049
01:30:22,970 --> 01:30:25,950
Brukere som ikke har tildelingene er
ikke kommer til å ha som attributt.

2050
01:30:25,950 --> 01:30:27,800
Så når jeg oppretter
indeksen, de eneste brukerne

2051
01:30:27,800 --> 01:30:28,960
som kommer til å vise
opp i indeksen er

2052
01:30:28,960 --> 01:30:31,050
de som faktisk har vunnet priser.

2053
01:30:31,050 --> 01:30:34,440
Så det er en fin måte å kunne
å opprette filtrerte indekser som

2054
01:30:34,440 --> 01:30:40,580
er veldig, veldig selektiv som ikke gjør det
har å indeksere hele tabellen.

2055
01:30:40,580 --> 01:30:43,050
>> Så vi får lite tid her.

2056
01:30:43,050 --> 01:30:49,190
Jeg kommer til å gå videre og hoppe
ut og hoppe over dette scenariet.

2057
01:30:49,190 --> 01:30:52,625
Snakke litt om--

2058
01:30:52,625 --> 01:30:54,460
>> PUBLIKUM: Kan jeg stille et raskt spørsmål?

2059
01:30:54,460 --> 01:30:56,722
En er skrive tung?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Hva er?

2061
01:30:57,680 --> 01:30:58,596
PUBLIKUM: Skriv tung.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Skriv tung.

2063
01:31:01,270 --> 01:31:03,460
La meg se.

2064
01:31:03,460 --> 01:31:06,220
>> PUBLIKUM: Eller er det ikke
noe du kan bare

2065
01:31:06,220 --> 01:31:08,809
stemme til i løpet av sekunder?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Vi går
gjennom stemmegivning scenario.

2067
01:31:10,850 --> 01:31:11,670
Det er ikke så ille.

2068
01:31:11,670 --> 01:31:14,580
Har dere har noen få minutter?

2069
01:31:14,580 --> 01:31:15,860
OK.

2070
01:31:15,860 --> 01:31:17,890
>> Så vi skal snakke om stemmegivning.

2071
01:31:17,890 --> 01:31:20,250
Så sanntid stemmegivning, har vi
krav til stemmegivning.

2072
01:31:20,250 --> 01:31:25,250
Kravene er at vi tillater
hver person til å stemme bare én gang.

2073
01:31:25,250 --> 01:31:28,060
Vi ønsker ingen å være i stand
å endre sin stemme.

2074
01:31:28,060 --> 01:31:31,045
Vi ønsker sanntid aggregering
og analyser for demografi

2075
01:31:31,045 --> 01:31:34,210
at vi kommer til å være
viser til brukere på nettstedet.

2076
01:31:34,210 --> 01:31:35,200
>> Tenk på dette scenariet.

2077
01:31:35,200 --> 01:31:37,550
Vi jobber mye med virkeligheten
TV-programmer der de er

2078
01:31:37,550 --> 01:31:38,960
gjør disse eksakte type ting.

2079
01:31:38,960 --> 01:31:41,584
Så du kan tenke på det scenariet
vi har millioner på millioner

2080
01:31:41,584 --> 01:31:43,959
tenåringsjenter der
med sine mobiltelefoner

2081
01:31:43,959 --> 01:31:46,250
og stemmegivning, og stemmegivning, og
stemme for hvem de er

2082
01:31:46,250 --> 01:31:48,610
synes å være den mest populære.

2083
01:31:48,610 --> 01:31:50,830
Så dette er noen av de
kravene vi går tom.

2084
01:31:50,830 --> 01:31:52,990
>> Og så den første ta
i å løse dette problemet

2085
01:31:52,990 --> 01:31:55,090
ville være å bygge en
veldig enkelt program.

2086
01:31:55,090 --> 01:31:56,490
Så jeg har fått dette programmet.

2087
01:31:56,490 --> 01:31:57,950
Jeg har noen velgere der ute.

2088
01:31:57,950 --> 01:31:59,980
De kommer i, de treffer stemme app.

2089
01:31:59,980 --> 01:32:03,440
Jeg har fått noen rå stemmer bord
Jeg vil bare dumpe disse stemmer inn.

2090
01:32:03,440 --> 01:32:05,780
Jeg vil ha noen samlet
stemmer tabell som

2091
01:32:05,780 --> 01:32:09,490
vil gjøre mine analyser og demografi,
og vi vil sette alt dette inn der.

2092
01:32:09,490 --> 01:32:11,420
>> Og dette er flott.

2093
01:32:11,420 --> 01:32:12,332
Livet er godt.

2094
01:32:12,332 --> 01:32:15,040
Livet er bra før vi finner ut at
det er alltid bare én eller to

2095
01:32:15,040 --> 01:32:16,879
folk som er populære i et valg.

2096
01:32:16,879 --> 01:32:19,420
Det finnes bare én eller to ting
at folk virkelig bryr seg om.

2097
01:32:19,420 --> 01:32:22,340
Og hvis du stemme på
skala, plutselig er jeg

2098
01:32:22,340 --> 01:32:26,360
kommer til å bli hamret i helvete ut av
to kandidater, en eller to kandidater.

2099
01:32:26,360 --> 01:32:29,390
Et svært begrenset antall elementer
folk synes å være populære.

2100
01:32:29,390 --> 01:32:31,710
>> Dette er ikke en god design mønster.

2101
01:32:31,710 --> 01:32:33,549
Dette er faktisk en
veldig dårlig design mønster

2102
01:32:33,549 --> 01:32:36,340
fordi det skaper akkurat det vi
snakket om som var hurtigtaster.

2103
01:32:36,340 --> 01:32:38,960
Hurtigtaster er noe vi ikke liker.

2104
01:32:38,960 --> 01:32:40,470
>> Så hvordan løser vi det?

2105
01:32:40,470 --> 01:32:47,640
Og virkelig, er måten å fikse dette
ved å ta disse kandidat bøtter

2106
01:32:47,640 --> 01:32:51,490
og for hver kandidat vi har,
vi kommer til å legge en tilfeldig verdi,

2107
01:32:51,490 --> 01:32:54,192
noe som vi vet, tilfeldig
verdi mellom en og 100,

2108
01:32:54,192 --> 01:32:56,620
mellom 100 og 1000,
eller mellom en og tusen,

2109
01:32:56,620 --> 01:32:59,940
men mange tilfeldige verdier du vil
føye på enden av at kandidaten.

2110
01:32:59,940 --> 01:33:01,330
>> Og hva har jeg egentlig gjort da?

2111
01:33:01,330 --> 01:33:05,830
Hvis jeg bruker kandidaten ID som
bøtte til å samle stemmer,

2112
01:33:05,830 --> 01:33:08,780
hvis jeg har lagt til en tilfeldig
nummer til slutten av det,

2113
01:33:08,780 --> 01:33:12,000
Jeg har laget nå 10 bøtter, en
hundre bøtter, tusen bøtter

2114
01:33:12,000 --> 01:33:14,160
at jeg samle stemmer over.

2115
01:33:14,160 --> 01:33:18,030
>> Så jeg har millioner, og millioner,
og millioner av plater som kommer inn

2116
01:33:18,030 --> 01:33:22,050
for disse kandidatene, er jeg nå spre
de stemmer over Kandidat a_1

2117
01:33:22,050 --> 01:33:24,630
gjennom Kandidat A_100, fordi
hver gang en stemme kommer inn,

2118
01:33:24,630 --> 01:33:26,530
Jeg genererer en tilfeldig
en verdi mellom 100 og.

2119
01:33:26,530 --> 01:33:29,446
Jeg vinne den på slutten av
Kandidaten vedkommendes stemme for.

2120
01:33:29,446 --> 01:33:31,120
Jeg dumping den inn som bøtte.

2121
01:33:31,120 --> 01:33:33,910
>> Nå på baksiden, jeg vet
at jeg fikk hundre bøtter.

2122
01:33:33,910 --> 01:33:36,350
Så når jeg ønsker å gå videre
og samle stemmene,

2123
01:33:36,350 --> 01:33:38,244
Jeg leste fra alle de bøtter.

2124
01:33:38,244 --> 01:33:39,160
Så jeg gå videre og legge til.

2125
01:33:39,160 --> 01:33:42,410
Og så jeg den scatter samle
der jeg går ut og si hei,

2126
01:33:42,410 --> 01:33:45,399
vet du hva, dette kandidatens nøkkel
mellomrom er over hundre bøtter.

2127
01:33:45,399 --> 01:33:47,940
Jeg kommer til å samle all
Stemmer fra disse hundre bøtter.

2128
01:33:47,940 --> 01:33:49,981
Jeg kommer til å aggregere
dem, og jeg kommer til å si,

2129
01:33:49,981 --> 01:33:53,830
Kandidat A har nå
stemmetall telling av x.

2130
01:33:53,830 --> 01:33:55,690
>> Nå er både skrive
spørring og lese søket

2131
01:33:55,690 --> 01:33:58,160
er pent fordelt
fordi jeg skriver på tvers

2132
01:33:58,160 --> 01:34:00,320
og jeg leser over hundrevis av nøkler.

2133
01:34:00,320 --> 01:34:03,500
Jeg skriver ikke og
lesing over en nøkkel nå.

2134
01:34:03,500 --> 01:34:04,950
Så det er et flott mønster.

2135
01:34:04,950 --> 01:34:08,090
>> Dette er faktisk trolig en
av de viktigste utformingen

2136
01:34:08,090 --> 01:34:10,420
mønstre for skalaen i NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Du vil se denne typen
design mønster i hver smak.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, det gjør det ikke
Uansett, vi alle har til å gjøre dette.

2139
01:34:19,100 --> 01:34:21,840
Fordi når du arbeider
med de store samlinger,

2140
01:34:21,840 --> 01:34:26,650
du må finne ut en måte å
spre dem ut over bøtter.

2141
01:34:26,650 --> 01:34:29,512
Så dette er måten du gjør det.

2142
01:34:29,512 --> 01:34:31,220
Greit, så hva
du gjør akkurat nå

2143
01:34:31,220 --> 01:34:35,252
er du handel av lese-
Kostnaden for skrive skalerbarhet.

2144
01:34:35,252 --> 01:34:37,085
Kostnaden for min lese er
litt mer komplisert

2145
01:34:37,085 --> 01:34:40,220
og jeg må gå lese fra en
hundre bøtter i stedet for én.

2146
01:34:40,220 --> 01:34:41,310
Men jeg er i stand til å skrive.

2147
01:34:41,310 --> 01:34:44,860
Og min gjennomstrømning, min skrive
gjennomstrømning er utrolig.

2148
01:34:44,860 --> 01:34:49,450
Så det er vanligvis en verdifull
teknikk for skalering DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
eller noen NoSQL database for den saks skyld.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Så vi fant ut hvordan å skalere den.

2152
01:34:55,240 --> 01:34:56,930
Og vi skjønte hvordan
eliminere våre hurtigtaster.

2153
01:34:56,930 --> 01:34:57,820
Og dette er fantastisk.

2154
01:34:57,820 --> 01:34:58,960
Og vi fikk denne fine system.

2155
01:34:58,960 --> 01:35:02,043
Og det har gitt oss veldig riktig å stemme
fordi vi har rekord stemme de-lettlurt.

2156
01:35:02,043 --> 01:35:03,130
Det er bygget inn DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Vi snakket om betingede rettigheter.

2158
01:35:05,380 --> 01:35:08,170
>> Når en velger kommer inn, setter
en innsats på bordet,

2159
01:35:08,170 --> 01:35:11,220
de setter inn med sine velgere ID,
hvis de prøver å sette inn en annen stemme,

2160
01:35:11,220 --> 01:35:13,320
Jeg gjør en betinget skrive.

2161
01:35:13,320 --> 01:35:16,960
Si bare skrive dette
dersom dette ikke eksisterer.

2162
01:35:16,960 --> 01:35:19,270
Så så snart jeg ser at
at stemmen er rammet bordet,

2163
01:35:19,270 --> 01:35:20,460
ingen andre kommer til å bli
stand til å sette sin stemme.

2164
01:35:20,460 --> 01:35:21,634
Og det er fantastisk.

2165
01:35:21,634 --> 01:35:23,550
Og vi økes
våre kandidat tellere.

2166
01:35:23,550 --> 01:35:25,466
Og vi gjør vårt
demografi og alt det der.

2167
01:35:25,466 --> 01:35:29,110
Men hva skjer hvis min
søknaden faller over?

2168
01:35:29,110 --> 01:35:31,350
Nå plutselig stemmer
er kommer inn, og jeg

2169
01:35:31,350 --> 01:35:34,840
vet ikke om de er å få behandlet
i mine analyser og demografi

2170
01:35:34,840 --> 01:35:36,040
lenger.

2171
01:35:36,040 --> 01:35:38,462
Og når programmet
kommer opp igjen, hvordan

2172
01:35:38,462 --> 01:35:41,420
faen vet jeg hva stemmer har
blitt behandlet og hvor skal jeg begynne?

2173
01:35:41,420 --> 01:35:44,530
>> Så dette er et reelt problem når du
begynner å se på denne typen scenario.

2174
01:35:44,530 --> 01:35:45,571
Og hvordan løser vi det?

2175
01:35:45,571 --> 01:35:48,070
Vi løser det med hva vi
kalle DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Strømmer er en tid bestilt og
partisjonert endringslogg for hver tilgang

2177
01:35:53,470 --> 01:35:55,700
til bordet, hvert skrive
adgang til bordet.

2178
01:35:55,700 --> 01:35:58,810
Eventuelle data som er skrevet til
Tabellen viser opp på strømmen.

2179
01:35:58,810 --> 01:36:01,815
>> Det er i utgangspunktet en 24 timers kø.

2180
01:36:01,815 --> 01:36:03,690
Elementer treffer bekken,
de lever i 24 timer.

2181
01:36:03,690 --> 01:36:05,990
De kan leses flere ganger.

2182
01:36:05,990 --> 01:36:09,400
Garantert å bli levert
bare en gang til strømmen,

2183
01:36:09,400 --> 01:36:11,180
kan leses n antall ganger.

2184
01:36:11,180 --> 01:36:14,910
Så uansett hvor mange prosesser du vil
konsumere disse dataene, kan du fordøye det.

2185
01:36:14,910 --> 01:36:16,350
Den vil vises hver oppdatering.

2186
01:36:16,350 --> 01:36:18,455
Hver write vil bare
vises en gang på strømmen.

2187
01:36:18,455 --> 01:36:20,621
Så du trenger ikke å bekymre deg
om å behandle den to ganger

2188
01:36:20,621 --> 01:36:22,500
fra den samme prosessen.

2189
01:36:22,500 --> 01:36:25,350
>> Det er strengt bestilles per element.

2190
01:36:25,350 --> 01:36:28,180
Når vi sier tid
bestilt og partisjonert,

2191
01:36:28,180 --> 01:36:30,680
du vil se per partisjon på strømmen.

2192
01:36:30,680 --> 01:36:33,169
Du vil se elementer, oppdateringer i orden.

2193
01:36:33,169 --> 01:36:35,210
Vi er ikke garanterer
på strømmen som du er

2194
01:36:35,210 --> 01:36:40,240
kommer til å få hver transaksjon
i størrelsesorden på tvers av elementene.

2195
01:36:40,240 --> 01:36:42,440
>> Så bekker er idempotent.

2196
01:36:42,440 --> 01:36:44,037
Må vi alle vet hva idempotent betyr?

2197
01:36:44,037 --> 01:36:46,620
Idempotent betyr at du kan gjøre det
over, og igjen, og igjen.

2198
01:36:46,620 --> 01:36:48,200
Resultatet kommer til å bli det samme.

2199
01:36:48,200 --> 01:36:49,991
>> Strømmer er idempotent,
men de må være

2200
01:36:49,991 --> 01:36:54,860
Spilte fra startpunktet,
uansett hvor du velger, til slutten,

2201
01:36:54,860 --> 01:36:57,950
eller de vil ikke medføre
i de samme verdier.

2202
01:36:57,950 --> 01:36:59,727
>> Samme med MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB har en konstruksjon
de kaller oplog.

2204
01:37:01,560 --> 01:37:04,140
Det er nøyaktig samme konstruksjon.

2205
01:37:04,140 --> 01:37:06,500
Mange NoSQL-databaser
har denne konstruksjonen.

2206
01:37:06,500 --> 01:37:08,790
De bruker den til å gjøre ting
som replikering, som

2207
01:37:08,790 --> 01:37:10,475
er akkurat hva vi gjør med bekker.

2208
01:37:10,475 --> 01:37:12,350
PUBLIKUM: Kanskje en
kjetterske spørsmålet, men du

2209
01:37:12,350 --> 01:37:13,975
snakke om apps gjør ned en så videre.

2210
01:37:13,975 --> 01:37:16,089
Er bekker garantert å
aldri muligens gå ned?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Yeah, bekker
er garantert å aldri gå ned.

2212
01:37:18,630 --> 01:37:21,040
Vi forvalter infrastrukturen
bak. bekker automatisk

2213
01:37:21,040 --> 01:37:22,498
distribuere i sin autoskalering gruppe.

2214
01:37:22,498 --> 01:37:25,910
Vi vil gå gjennom en liten
litt om hva som skjer.

2215
01:37:25,910 --> 01:37:30,060
>> Jeg skal ikke si at de ikke er
garantert å aldri gå ned.

2216
01:37:30,060 --> 01:37:33,110
Elementene er garantert
skal vises i bekken.

2217
01:37:33,110 --> 01:37:36,740
Og strømmen vil være tilgjengelig.

2218
01:37:36,740 --> 01:37:40,580
Så hva går ned eller kommer tilbake
opp, skjer det under.

2219
01:37:40,580 --> 01:37:43,844
Det covers-- det er OK.

2220
01:37:43,844 --> 01:37:46,260
All right, slik at du får forskjellige
view typer av skjermen.

2221
01:37:46,260 --> 01:37:51,040
Typene view som er viktige for en
programmerer vanligvis er, hva var det?

2222
01:37:51,040 --> 01:37:52,370
Jeg får det gamle synet.

2223
01:37:52,370 --> 01:37:55,630
Når en oppdatering treffer bordet, det vil
skyve det gamle synet til strømmen

2224
01:37:55,630 --> 01:38:02,070
slik at data kan arkivere eller endring
kontroll, endring identifikasjon, endring

2225
01:38:02,070 --> 01:38:03,600
ledelse.

2226
01:38:03,600 --> 01:38:07,160
>> Det nye bildet, hva det er nå etter
oppdateringen, det er en annen type visning

2227
01:38:07,160 --> 01:38:07,660
du kan få.

2228
01:38:07,660 --> 01:38:09,660
Du kan få både den gamle og nye bilder.

2229
01:38:09,660 --> 01:38:10,660
Kanskje jeg vil ha dem begge.

2230
01:38:10,660 --> 01:38:11,790
Jeg ønsker å se hva det var.

2231
01:38:11,790 --> 01:38:13,290
Jeg ønsker å se hva det endret til.

2232
01:38:13,290 --> 01:38:15,340
>> Jeg har en compliance typen
prosess som kjører.

2233
01:38:15,340 --> 01:38:17,430
Det er behov for å kontrollere at
når disse ting endrer seg,

2234
01:38:17,430 --> 01:38:21,840
at de er innenfor visse grenser
eller innenfor visse rammer.

2235
01:38:21,840 --> 01:38:23,840
>> Og så kanskje jeg bare
trenger å vite hva som er endret.

2236
01:38:23,840 --> 01:38:26,240
Jeg bryr meg ikke hva elementet endret.

2237
01:38:26,240 --> 01:38:28,580
Jeg trenger ikke å trenge å vite
hvilke attributter endret.

2238
01:38:28,580 --> 01:38:30,882
Jeg trenger bare å vite at
elementene blir berørt.

2239
01:38:30,882 --> 01:38:33,340
Så er det disse typer visninger
at du får av strøm

2240
01:38:33,340 --> 01:38:35,960
og du kan samhandle med.

2241
01:38:35,960 --> 01:38:37,840
>> Søknaden som
forbruker strøm,

2242
01:38:37,840 --> 01:38:39,298
dette er slags måten dette fungerer.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB kunde om å
presse data til tabellene.

2244
01:38:42,570 --> 01:38:44,750
Strømmer distribuere på det vi kaller skår.

2245
01:38:44,750 --> 01:38:47,380
Shards er skalert
uavhengig av bordet.

2246
01:38:47,380 --> 01:38:50,660
De trenger ikke stille opp helt
til partisjonene av tabellen.

2247
01:38:50,660 --> 01:38:52,540
Og grunnen er
fordi de stiller seg opp

2248
01:38:52,540 --> 01:38:55,430
til kapasiteten, den nåværende
kapasitet av tabellen.

2249
01:38:55,430 --> 01:38:57,600
>> De distribuerer i deres
egen auto skalering gruppe,

2250
01:38:57,600 --> 01:39:00,800
og de begynner å spinne ut avhengig
på hvor mange skrivinger kommer inn,

2251
01:39:00,800 --> 01:39:03,090
hvor mange reads-- egentlig er det skriver.

2252
01:39:03,090 --> 01:39:05,820
Det er ingen reads-- men hvordan
mange skriver kommer inn.

2253
01:39:05,820 --> 01:39:08,200
>> Og deretter på ryggen
slutt, har vi det vi

2254
01:39:08,200 --> 01:39:11,390
kalle en KCL, eller Kinesis klientbiblioteket.

2255
01:39:11,390 --> 01:39:19,190
Kinesis er en strøm av data
produksjonsteknologi fra Amazon.

2256
01:39:19,190 --> 01:39:22,040
Og bekker er bygget på det.

2257
01:39:22,040 --> 01:39:25,670
>> Så du bruker en KCL aktivert
program for å lese bekken.

2258
01:39:25,670 --> 01:39:28,752
Kinesis Client Library faktisk
forvalter arbeiderne for deg.

2259
01:39:28,752 --> 01:39:30,460
Og det gjør også noen
interessante ting.

2260
01:39:30,460 --> 01:39:35,630
Det vil skape noen tabeller opp
i DynamoDB tabell

2261
01:39:35,630 --> 01:39:38,410
å spore hvilke elementer
har blitt behandlet.

2262
01:39:38,410 --> 01:39:41,190
Så denne måten hvis den faller tilbake, hvis
den faller over og kommer og får

2263
01:39:41,190 --> 01:39:45,570
sto opp igjen, kan det avgjøre hvor
var det i behandlingen av strømmen.

2264
01:39:45,570 --> 01:39:48,360
>> Det er veldig viktig når
du snakker om replikering.

2265
01:39:48,360 --> 01:39:50,350
Jeg trenger å vite hva
data ble blitt behandlet

2266
01:39:50,350 --> 01:39:52,810
og hvilke data som ennå ikke er behandlet.

2267
01:39:52,810 --> 01:39:57,380
Så KCL bibliotek for bekker vil
gi deg mye av den funksjonaliteten.

2268
01:39:57,380 --> 01:39:58,990
Det tar vare på all rengjøring.

2269
01:39:58,990 --> 01:40:01,140
Det står opp en arbeidstaker for hver fragmentet.

2270
01:40:01,140 --> 01:40:04,620
Det skaper en administrativ bord
for hver Shard, for hver arbeidstaker.

2271
01:40:04,620 --> 01:40:07,560
Og som de arbeidere brann,
de opprettholder disse tabellene

2272
01:40:07,560 --> 01:40:10,510
slik at du vet denne posten
ble lest og behandlet.

2273
01:40:10,510 --> 01:40:13,850
Og så på den måten hvis prosessen
dør og kommer tilbake på nettet,

2274
01:40:13,850 --> 01:40:17,940
det kan fortsette akkurat der den tok av.

2275
01:40:17,940 --> 01:40:20,850
>> Så vi bruker denne for
cross-regionen replikering.

2276
01:40:20,850 --> 01:40:24,680
Mange kunder har behov for å
flytte data eller deler av sine datatabeller

2277
01:40:24,680 --> 01:40:25,920
rundt til forskjellige regioner.

2278
01:40:25,920 --> 01:40:29,230
Det er ni regioner
hele verden.

2279
01:40:29,230 --> 01:40:32,100
Så det kan være en need-- jeg
kan ha brukere i Asia, brukere

2280
01:40:32,100 --> 01:40:34,150
i østkysten av USA.

2281
01:40:34,150 --> 01:40:38,980
De har forskjellige data som
må være lokalt fordelt.

2282
01:40:38,980 --> 01:40:42,510
Og kanskje en bruker flyr fra
Asia over til USA,

2283
01:40:42,510 --> 01:40:45,020
og jeg ønsker å replikere
hans data med ham.

2284
01:40:45,020 --> 01:40:49,340
Så når han får ut av flyet, har han
en god opplevelse ved å bruke sin mobil app.

2285
01:40:49,340 --> 01:40:52,360
>> Du kan bruke cross-regionen
replikering biblioteket for å gjøre dette.

2286
01:40:52,360 --> 01:40:55,730
I utgangspunktet har vi
gitt to teknologiene.

2287
01:40:55,730 --> 01:40:59,400
One er en konsoll applikasjon du kan
stå opp på egen hånd EC2 eksempel.

2288
01:40:59,400 --> 01:41:01,240
Det kjører ren replikering.

2289
01:41:01,240 --> 01:41:02,720
Og da vi ga deg biblioteket.

2290
01:41:02,720 --> 01:41:06,070
Biblioteket kan du bruke til å bygge
din egen søknad hvis du

2291
01:41:06,070 --> 01:41:10,740
ønsker å gjøre gale ting med at data--
filter, replikere bare en del av den,

2292
01:41:10,740 --> 01:41:14,120
rotere data, flytte den til en
annen tabell, så videre og så videre.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Så det er litt av hva som ser ut som.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams kan være
behandlet av det vi kaller Lambda.

2296
01:41:23,690 --> 01:41:27,394
Vi nevnte litt om hendelsen
drevne program arkitekturer.

2297
01:41:27,394 --> 01:41:28,810
Lambda er en viktig del av det.

2298
01:41:28,810 --> 01:41:32,840
Lambda er kode som fyrer on demand
som respons på en bestemt hendelse.

2299
01:41:32,840 --> 01:41:36,020
En av disse arrangementer kan være en
posten vises på strømmen.

2300
01:41:36,020 --> 01:41:39,100
Hvis en post vises på stream,
vi kaller dette Java funksjonen.

2301
01:41:39,100 --> 01:41:44,980
Vel, dette er Javascript, og Lambda
støtter Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
og vil snart støtte
andre språk også.

2303
01:41:47,820 --> 01:41:50,940
Og nok til å si, det er ren kode.

2304
01:41:50,940 --> 01:41:53,610
Skriv i Java, definerer du en klasse.

2305
01:41:53,610 --> 01:41:55,690
Du skyver JAR opp i Lambda.

2306
01:41:55,690 --> 01:42:00,200
Og så kan du spesifisere hvilken klasse
å ringe som svar på hvilken hendelse.

2307
01:42:00,200 --> 01:42:04,770
Og så Lambda infrastruktur
bak som vil kjøre denne koden.

2308
01:42:04,770 --> 01:42:06,730
>> Den koden kan behandle
poster utenfor stream.

2309
01:42:06,730 --> 01:42:08,230
Det kan gjøre noe den ønsker med den.

2310
01:42:08,230 --> 01:42:11,650
I dette eksempelet, er alt vi
egentlig gjør er å logge attributtene.

2311
01:42:11,650 --> 01:42:13,480
Men dette er bare koden.

2312
01:42:13,480 --> 01:42:15,260
Koden kan gjøre noe, ikke sant?

2313
01:42:15,260 --> 01:42:16,600
>> Så du kan rotere disse dataene.

2314
01:42:16,600 --> 01:42:18,160
Du kan lage et derivat visning.

2315
01:42:18,160 --> 01:42:21,160
Hvis det er en dokumentstruktur,
du kan flate strukturen.

2316
01:42:21,160 --> 01:42:24,300
Du kan lage alternative indekser.

2317
01:42:24,300 --> 01:42:27,100
Alle slags ting du kan
gjøre med DynamoDB Streams.

2318
01:42:27,100 --> 01:42:28,780
>> Og egentlig, det er hva det ser ut.

2319
01:42:28,780 --> 01:42:29,940
Så du får disse oppdateringene kommer inn.

2320
01:42:29,940 --> 01:42:31,190
De kommer av strengen.

2321
01:42:31,190 --> 01:42:32,720
De er lest av Lambda-funksjonen.

2322
01:42:32,720 --> 01:42:37,480
De rotere data og
skyve den opp i avledede tabeller,

2323
01:42:37,480 --> 01:42:42,200
varsle eksterne systemer for endring,
og skyve data inn ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Vi snakket om hvordan å sette cache
foran database for at omsetningen

2325
01:42:45,900 --> 01:42:46,450
scenario.

2326
01:42:46,450 --> 01:42:50,049
Vel hva skjer hvis jeg
oppdatere varebeskrivelsen?

2327
01:42:50,049 --> 01:42:52,340
Vel, hvis jeg hadde en Lambda
funksjon som kjører på det bordet,

2328
01:42:52,340 --> 01:42:55,490
hvis jeg oppdaterer varebeskrivelsen, det vil
plukke opp posten av bekken,

2329
01:42:55,490 --> 01:42:58,711
og det vil oppdatere ElastiCache
eksempel med de nye dataene.

2330
01:42:58,711 --> 01:43:00,460
Så det er mye
hva vi gjør med Lambda.

2331
01:43:00,460 --> 01:43:02,619
Det er lim koden, kontakter.

2332
01:43:02,619 --> 01:43:04,410
Og det gir faktisk
muligheten til å starte

2333
01:43:04,410 --> 01:43:07,930
og til å kjøre svært komplekse applikasjoner
uten en dedikert server

2334
01:43:07,930 --> 01:43:10,371
infrastruktur, som er virkelig kult.

2335
01:43:10,371 --> 01:43:13,100
>> Så la oss gå tilbake til vår
sanntid stemmegivning arkitektur.

2336
01:43:13,100 --> 01:43:17,984
Dette er nytt og forbedret med vår
bekker og KCL aktivert program.

2337
01:43:17,984 --> 01:43:20,150
Samme som før, kan vi
håndtere eventuelle omfanget av valget.

2338
01:43:20,150 --> 01:43:21,100
Vi liker dette.

2339
01:43:21,100 --> 01:43:24,770
Vi gjør ut scatter samler
tvers av flere bøtter.

2340
01:43:24,770 --> 01:43:26,780
Vi har fått optimistisk låsing skjer.

2341
01:43:26,780 --> 01:43:30,192
Vi kan holde våre velgere
fra å endre sine stemmer.

2342
01:43:30,192 --> 01:43:31,400
De kan bare stemme én gang.

2343
01:43:31,400 --> 01:43:32,880
Dette er fantastisk.

2344
01:43:32,880 --> 01:43:35,895
Real-time feiltoleranse,
skalerbar aggregering nå.

2345
01:43:35,895 --> 01:43:38,270
Hvis ting faller over, det
vet hvor du skal starte seg selv

2346
01:43:38,270 --> 01:43:41,300
når det kommer opp igjen fordi
vi bruker den KCL app.

2347
01:43:41,300 --> 01:43:45,700
Og da kan vi også bruke det
KCL program for å presse data ut

2348
01:43:45,700 --> 01:43:48,820
til rødforskyvning for andre
app analytics, eller bruk

2349
01:43:48,820 --> 01:43:51,990
Den elastiske MapReduce å kjøre
real-time streaming samlinger off

2350
01:43:51,990 --> 01:43:53,180
av dataene.

2351
01:43:53,180 --> 01:43:55,480
>> Så dette er ting vi
har ikke snakket om mye.

2352
01:43:55,480 --> 01:43:57,375
Men de er ekstra
teknologier som kommer

2353
01:43:57,375 --> 01:44:00,310
å bære når du leter
på disse typer scenarier.

2354
01:44:00,310 --> 01:44:03,160
>> Greit, så det er omtrent
analytics med DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
Du kan samle de-lure
data, gjøre alle typer

2356
01:44:05,340 --> 01:44:09,490
av fine ting, samle data i
minne, lage disse avledede tabeller.

2357
01:44:09,490 --> 01:44:13,110
Det er en enorm use case
at mange kunder

2358
01:44:13,110 --> 01:44:16,950
er involvert med, tar nestet
egenskapene til disse JSON-dokumenter

2359
01:44:16,950 --> 01:44:18,946
og opprette flere indekser.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Vi er på slutten.

2362
01:44:23,150 --> 01:44:26,689
Takk for at du bærer med meg.

2363
01:44:26,689 --> 01:44:28,480
Så la oss snakke om
referansearkitektur.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB sitter i midten av så
mye av AWS infrastruktur.

2365
01:44:33,440 --> 01:44:37,090
I utgangspunktet kan du koble den
opp til noe du ønsker.

2366
01:44:37,090 --> 01:44:45,600
Applikasjoner bygget med Dynamo inkluderer
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
skyve data ut i Elastic
MapReduce, import eksport fra DynamoDB

2368
01:44:49,890 --> 01:44:52,370
i S3, alle typer arbeidsflyter.

2369
01:44:52,370 --> 01:44:54,120
Men sannsynligvis den beste
ting å snakke om,

2370
01:44:54,120 --> 01:44:56,119
og dette er hva som er virkelig
interessant er når vi

2371
01:44:56,119 --> 01:44:58,350
snakke om hendelsesdrevne applikasjoner.

2372
01:44:58,350 --> 01:45:00,300
>> Dette er et eksempel på
et internt prosjekt

2373
01:45:00,300 --> 01:45:04,850
at vi har der vi er faktisk
publisering for å samle resultatene fra undersøkelsen.

2374
01:45:04,850 --> 01:45:07,700
Så i en e-post link som
vi sender ut, det vil

2375
01:45:07,700 --> 01:45:11,350
være litt link som sier klikk
her for å svare på undersøkelsen.

2376
01:45:11,350 --> 01:45:14,070
Og når en person klikk
som link, hva skjer

2377
01:45:14,070 --> 01:45:18,020
er de trekke ned en sikker
HTML undersøkelse form fra S3.

2378
01:45:18,020 --> 01:45:18,980
Det er ingen server.

2379
01:45:18,980 --> 01:45:20,600
Dette er bare en S3 objekt.

2380
01:45:20,600 --> 01:45:22,770
>> At formen kommer opp,
laster opp i nettleseren.

2381
01:45:22,770 --> 01:45:24,240
Det har ryggrad.

2382
01:45:24,240 --> 01:45:30,160
Det har komplekse Javascript
at den kjører.

2383
01:45:30,160 --> 01:45:33,557
Så det er veldig rik søknad
kjører i klientens nettleser.

2384
01:45:33,557 --> 01:45:36,390
De vet ikke at de ikke er
samspill med en back end server.

2385
01:45:36,390 --> 01:45:38,220
På dette punktet, er det alt nettleser.

2386
01:45:38,220 --> 01:45:41,780
>> De publiserer resultatene til hva
vi kaller Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway er rett og slett en web-API
at du kan definere og koble opp

2388
01:45:46,270 --> 01:45:47,760
til hva du vil.

2389
01:45:47,760 --> 01:45:50,990
I dette tilfellet er vi
koblet til en Lambda funksjon.

2390
01:45:50,990 --> 01:45:54,797
>> Så min POST drift er
skjer uten server.

2391
01:45:54,797 --> 01:45:56,380
Utgangspunktet at API Gateway sitter der.

2392
01:45:56,380 --> 01:45:58,770
Det koster meg ingenting før folk
begynne å legge til det, ikke sant?

2393
01:45:58,770 --> 01:46:00,269
Lambda-funksjonen bare sitter der.

2394
01:46:00,269 --> 01:46:03,760
Og det koster meg ingenting før
folk begynner å treffe den.

2395
01:46:03,760 --> 01:46:07,270
Så du kan se, som volumet
øker, er at når anklagene kommer.

2396
01:46:07,270 --> 01:46:09,390
Jeg er ikke kjører en server 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Så jeg trekker form
ned fra bøtta,

2398
01:46:12,310 --> 01:46:15,719
og jeg legger gjennom API
Inngangsport til Lambda funksjonen.

2399
01:46:15,719 --> 01:46:17,510
Og så Lambda
Funksjonen sier, du vet

2400
01:46:17,510 --> 01:46:20,600
hva har jeg fått noen PIIs, noen
personlig identifiserbar informasjon

2401
01:46:20,600 --> 01:46:21,480
i disse svarene.

2402
01:46:21,480 --> 01:46:23,020
Jeg fikk kommentarer fra brukere.

2403
01:46:23,020 --> 01:46:24,230
Jeg har fått e-postadresser.

2404
01:46:24,230 --> 01:46:26,190
Jeg har fått brukernavn.

2405
01:46:26,190 --> 01:46:27,810
>> La meg dele dette av.

2406
01:46:27,810 --> 01:46:30,280
Jeg kommer til å generere noen
metadata av denne posten.

2407
01:46:30,280 --> 01:46:32,850
Og jeg kommer til å skyve
metadata inn DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Og jeg kunne kryptere all data
og skyv den inn DynamoDB hvis jeg vil.

2409
01:46:36,059 --> 01:46:38,600
Men det er lettere for meg, i dette
bruke saken for å gå videre en si,

2410
01:46:38,600 --> 01:46:42,800
Jeg kommer til å presse rådata
inn i en kryptert S3 bøtte.

2411
01:46:42,800 --> 01:46:47,240
Så jeg bruke bygget i S3 server side
kryptering og Amazons Key Management

2412
01:46:47,240 --> 01:46:51,600
Tjenesten, slik at jeg har en nøkkel som
kan rotere på en vanlig intervall,

2413
01:46:51,600 --> 01:46:55,010
og jeg kan beskytte at PII data
som en del av hele denne arbeidsflyten.

2414
01:46:55,010 --> 01:46:55,870
>> Så hva har jeg gjort?

2415
01:46:55,870 --> 01:47:00,397
Jeg har nettopp utplassert en hel
program, og jeg har ingen server.

2416
01:47:00,397 --> 01:47:02,980
Så er hva hendelse drevet søknad
arkitektur gjør for deg.

2417
01:47:02,980 --> 01:47:05,730
>> Nå hvis du tenker på
bruk case for dette--

2418
01:47:05,730 --> 01:47:08,730
vi har andre kunder jeg snakker
til om denne eksakte arkitektur som

2419
01:47:08,730 --> 01:47:14,560
kjøre fenomenalt store kampanjer, som
ser på dette og går, oh my.

2420
01:47:14,560 --> 01:47:17,840
Fordi nå, kan de
utgangspunktet skyve den ut der,

2421
01:47:17,840 --> 01:47:21,900
la den kampanjen bare sitte
der til det lanseres, og ikke

2422
01:47:21,900 --> 01:47:24,400
trenger å bekymre deg en fig om
hva slags infrastruktur

2423
01:47:24,400 --> 01:47:26,120
kommer til å være der for å støtte den.

2424
01:47:26,120 --> 01:47:28,600
Og så så snart
at kampanjen er gjort,

2425
01:47:28,600 --> 01:47:31,520
det er som infrastruktur
bare umiddelbart går unna

2426
01:47:31,520 --> 01:47:33,680
fordi det egentlig
er ingen infrastruktur.

2427
01:47:33,680 --> 01:47:35,660
Det er bare kode som sitter på Lambda.

2428
01:47:35,660 --> 01:47:38,560
Det er bare data som sitter i DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Det er en fantastisk måte
å bygge applikasjoner.

2430
01:47:41,340 --> 01:47:43,970
>> PUBLIKUM: Så er det mer
flyktig enn det ville være

2431
01:47:43,970 --> 01:47:45,740
hvis den ble lagret på en faktisk server?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Absolutt.

2433
01:47:46,823 --> 01:47:49,190
Fordi at tjenerforekomsten
måtte være en 7/24.

2434
01:47:49,190 --> 01:47:51,954
Det må være tilgjengelig for
noen til å svare på.

2435
01:47:51,954 --> 01:47:52,620
Vel gjett hva?

2436
01:47:52,620 --> 01:47:55,410
S3 er tilgjengelig 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 svarer alltid.

2438
01:47:57,100 --> 01:47:59,320
Og S3 er veldig, veldig bra
på servering opp gjenstander.

2439
01:47:59,320 --> 01:48:02,590
Disse objektene kan være HTML-filer, eller
Javascript-filer, eller hva du vil.

2440
01:48:02,590 --> 01:48:07,430
Du kan kjøre svært rike webapplikasjoner
ut av S3 bøtter, og mennesker gjør.

2441
01:48:07,430 --> 01:48:10,160
>> Og så det er tanken her
er å komme bort fra veien

2442
01:48:10,160 --> 01:48:11,270
vi pleide å tenke på det.

2443
01:48:11,270 --> 01:48:14,270
Vi pleide å tenke i
form av servere og verter.

2444
01:48:14,270 --> 01:48:16,580
Det handler ikke om det lenger.

2445
01:48:16,580 --> 01:48:19,310
Det handler om infrastruktur som kode.

2446
01:48:19,310 --> 01:48:22,470
Distribuere koden til nettskyen og
la skyen kjøre den for deg.

2447
01:48:22,470 --> 01:48:24,980
Og det er det AWS prøver å gjøre.

2448
01:48:24,980 --> 01:48:29,690
>> PUBLIKUM: Så din gull boksen i midten
av API Gateway er ikke server-aktig,

2449
01:48:29,690 --> 01:48:30,576
men i stedet er just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Du kan tenke
av det som server fasaden.

2451
01:48:32,850 --> 01:48:38,040
Alt er det er det vil ta en HTTP
be om og kartlegge den til en annen prosess.

2452
01:48:38,040 --> 01:48:39,192
Det er alt den gjør.

2453
01:48:39,192 --> 01:48:41,525
Og i dette tilfellet, vi kartlegge
den til en Lambda funksjon.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Greit, så det er alt jeg fikk.

2456
01:48:45,410 --> 01:48:46,190
Tusen takk.

2457
01:48:46,190 --> 01:48:46,800
Jeg setter pris på det.

2458
01:48:46,800 --> 01:48:48,100
Jeg vet at vi vil ha en litt over tid.

2459
01:48:48,100 --> 01:48:49,980
Og forhåpentligvis fikk dere
en liten bit av informasjon

2460
01:48:49,980 --> 01:48:51,410
at du kan ta bort i dag.

2461
01:48:51,410 --> 01:48:53,520
Og jeg beklager hvis jeg gikk
over noen av hodene,

2462
01:48:53,520 --> 01:48:56,697
men det er en god rekke
fundamental grunnleggende kunnskap

2463
01:48:56,697 --> 01:48:58,280
som jeg tror er svært verdifull for deg.

2464
01:48:58,280 --> 01:48:59,825
Så takk for å ha meg.

2465
01:48:59,825 --> 01:49:00,325
[BIFALL]

2466
01:49:00,325 --> 01:49:02,619
PUBLIKUM: [uhørbart]
er når du sa

2467
01:49:02,619 --> 01:49:05,160
du måtte gå gjennom ting
fra begynnelsen til slutten

2468
01:49:05,160 --> 01:49:07,619
å få de riktige verdiene
eller de samme verdier,

2469
01:49:07,619 --> 01:49:09,410
hvordan ville verdiene
endres hvis [uhørbart].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Hvordan ville de verdiene endres?

2472
01:49:11,800 --> 01:49:15,180
Vel, fordi hvis jeg ikke kjøre
den helt til slutten,

2473
01:49:15,180 --> 01:49:19,770
så jeg vet ikke hvilke endringer
ble gjort i den siste mil.

2474
01:49:19,770 --> 01:49:22,144
Det kommer ikke til å være det
samme data som det jeg så.

2475
01:49:22,144 --> 01:49:24,560
PUBLIKUM: Å, så du bare
har ikke fått hele innspill.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Høyre.

2477
01:49:24,770 --> 01:49:26,895
Du må gå fra begynnelse
til slutt, og da er det

2478
01:49:26,895 --> 01:49:29,280
kommer til å være en konsistent tilstand.

2479
01:49:29,280 --> 01:49:31,520
Kjølig.

2480
01:49:31,520 --> 01:49:35,907
>> PUBLIKUM: Så du viste oss DynamoDB
kan gjøre dokumentet eller nøkkelverdien.

2481
01:49:35,907 --> 01:49:38,740
Og vi har brukt mye tid på
sentral verdi med hasj og veier

2482
01:49:38,740 --> 01:49:40,005
å snu det rundt.

2483
01:49:40,005 --> 01:49:43,255
Når du har sett på disse tabellene, er at
later dokumentet tilnærming?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: Jeg ville ikke
si forlate den bak.

2485
01:49:44,600 --> 01:49:45,855
>> PUBLIKUM: De ble skilt fra the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Med dokumentet
tilnærming, dokumenttype i DynamoDB

2487
01:49:49,140 --> 01:49:50,880
er bare å tenke på som en annen egenskap.

2488
01:49:50,880 --> 01:49:53,560
Det er en egenskap som inneholder
en hierarkisk datastruktur.

2489
01:49:53,560 --> 01:49:56,980
Og så i spørringene,
du kan bruke egenskapene

2490
01:49:56,980 --> 01:49:59,480
av disse objektene ved hjelp av Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Så jeg kan filtrere på en nestet
eiendommen av JSON dokumentet.

2492
01:50:03,562 --> 01:50:05,520
PUBLIKUM: Så hver gang jeg
gjøre et dokument tilnærming,

2493
01:50:05,520 --> 01:50:07,906
Jeg kan liksom komme frem til tabular--

2494
01:50:07,906 --> 01:50:08,780
PUBLIKUM: Absolutt.

2495
01:50:08,780 --> 01:50:09,800
Målgruppe: --indexes og
ting du bare snakket om.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Ja,
indekser og alt det der,

2497
01:50:11,280 --> 01:50:13,363
når du ønsker å indeksere
egenskapene til JSON,

2498
01:50:13,363 --> 01:50:18,230
den måten at vi må gjøre det på er hvis
du setter inn en JSON objekt eller et dokument

2499
01:50:18,230 --> 01:50:20,780
til Dynamo, vil du bruke bekker.

2500
01:50:20,780 --> 01:50:22,400
Strømmer ville lese innspill.

2501
01:50:22,400 --> 01:50:24,340
Du vil få det JSON
objekt og du vil si OK,

2502
01:50:24,340 --> 01:50:26,030
hva er den egenskapen jeg vil indeksere?

2503
01:50:26,030 --> 01:50:28,717
>> Du oppretter et derivat bord.

2504
01:50:28,717 --> 01:50:30,300
Nå det er slik det fungerer akkurat nå.

2505
01:50:30,300 --> 01:50:32,650
Vi vil ikke tillate deg å indeksere
direkte disse egenskapene.

2506
01:50:32,650 --> 01:50:33,520
>> PUBLIKUM: Tabularizing dokumentene.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Nøyaktig, flatere
det, tabularizing det, akkurat.

2508
01:50:36,230 --> 01:50:37,415
Det er hva du gjør med den.

2509
01:50:37,415 --> 01:50:37,860
>> PUBLIKUM: Takk.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Jepp,
absolutt, takk.

2511
01:50:39,609 --> 01:50:42,240
PUBLIKUM: Så det er på en måte
Mongo møter Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Ja,
det er mye sånn.

2513
01:50:43,990 --> 01:50:45,940
Det er en god beskrivelse for det.

2514
01:50:45,940 --> 01:50:47,490
Kjølig.

2515
01:50:47,490 --> 01:50:49,102