1
00:00:00,000 --> 00:00:04,969
>> [Muziek]

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: Oké.

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

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

5
00:00:07,670 --> 00:00:10,330
Ik ben een senior principal
oplossingen architect bij AWS.

6
00:00:10,330 --> 00:00:14,070
Ik mij richten op NoSQL en
DynamoDB technologieën.

7
00:00:14,070 --> 00:00:16,930
Ik ben hier vandaag om te praten
je een beetje over die.

8
00:00:16,930 --> 00:00:18,970
>> Mijn achtergrond is
vooral in datalaag.

9
00:00:18,970 --> 00:00:21,390
Ik heb de helft van mijn ontwikkeling
carrière schrijven databank

10
00:00:21,390 --> 00:00:25,930
toegang tot de gegevens, oplossingen
voor diverse toepassingen.

11
00:00:25,930 --> 00:00:30,000
Ik heb in Cloud virtualisatie geweest
ongeveer 20 jaar.

12
00:00:30,000 --> 00:00:33,460
Dus voordat de Cloud was de Cloud,
We noemden het utility computing.

13
00:00:33,460 --> 00:00:37,170
En het idee was, het is net als
PG & E, je betaalt voor wat je gebruikt.

14
00:00:37,170 --> 00:00:38,800
Vandaag noemen we het de cloud.

15
00:00:38,800 --> 00:00:41,239
>> Maar in de loop der jaren heb ik gewerkt
voor een paar bedrijven

16
00:00:41,239 --> 00:00:42,530
heb je waarschijnlijk nog nooit van gehoord.

17
00:00:42,530 --> 00:00:47,470
Maar ik heb een lijst van technische samengesteld
prestaties, ik denk dat je zou zeggen.

18
00:00:47,470 --> 00:00:51,620
Ik heb acht octrooien in Cloud systemen
virtualisatie, microprocessor ontwerp,

19
00:00:51,620 --> 00:00:54,440
complex event processing,
en andere gebieden.

20
00:00:54,440 --> 00:00:58,290
>> Dus deze dagen, richt ik me vooral op NoSQL
technologieën en de volgende generatie

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

22
00:00:59,450 --> 00:01:03,370
En dat is over het algemeen wat ik ga
om hier te zijn met je te praten vandaag over.

23
00:01:03,370 --> 00:01:06,030
Dus wat u kunt verwachten
van deze sessie,

24
00:01:06,030 --> 00:01:08,254
we gaan door middel van een kort
geschiedenis van gegevensverwerking.

25
00:01:08,254 --> 00:01:10,420
Het is altijd nuttig om
begrijpen waar we vandaan komen

26
00:01:10,420 --> 00:01:12,400
en waarom we zijn waar we zijn.

27
00:01:12,400 --> 00:01:15,600
En we zullen een beetje praten
beetje over NoSQL-technologie

28
00:01:15,600 --> 00:01:17,500
vanuit fundamenteel oogpunt.

29
00:01:17,500 --> 00:01:19,870
>> We krijgen in een aantal van
de DynamoDB binnenwerk.

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

31
00:01:24,350 --> 00:01:27,340
Het is een volledig beheerde en
gehoste NoSQL oplossing.

32
00:01:27,340 --> 00:01:32,420
En we zullen een klein beetje over tafel praten
structuur, API's, data types, indexen,

33
00:01:32,420 --> 00:01:35,177
en sommige internals
DynamoDB van die technologie.

34
00:01:35,177 --> 00:01:37,760
We krijgen in een aantal van het ontwerp
patronen en best practices.

35
00:01:37,760 --> 00:01:39,968
We zullen praten over hoe je
Gebruik van deze technologie voor sommige

36
00:01:39,968 --> 00:01:41,430
toepassingen van vandaag.

37
00:01:41,430 --> 00:01:44,820
En dan zullen we een beetje praten
over de evolutie en de opkomst

38
00:01:44,820 --> 00:01:48,980
van een nieuw paradigma in de programmering
zogenaamde event-driven applicaties

39
00:01:48,980 --> 00:01:51,580
en hoe DynamoDB speelt dat ook.

40
00:01:51,580 --> 00:01:54,690
En wij sturen u een klein beetje
een referentie-architectuur discussie

41
00:01:54,690 --> 00:01:59,540
zodat we kunnen praten over een aantal van
de manieren waarop je kunt DynamoDB gebruiken.

42
00:01:59,540 --> 00:02:04,116
>> Dus eerst off-- dit is een vraag
Ik hoor veel is, wat is een database.

43
00:02:04,116 --> 00:02:06,240
Veel mensen denken dat ze
weet wat een database is.

44
00:02:06,240 --> 00:02:08,360
Als u Google, zult u dit zien.

45
00:02:08,360 --> 00:02:11,675
Het is een gestructureerd geheel van gegevens waarover
in een computer, vooral een die

46
00:02:11,675 --> 00:02:13,600
is bereikbaar op verschillende manieren.

47
00:02:13,600 --> 00:02:16,992
Ik veronderstel dat is een goede
definitie van moderne database.

48
00:02:16,992 --> 00:02:19,450
Maar ik vind het niet leuk, omdat
het impliceert een paar dingen.

49
00:02:19,450 --> 00:02:20,935
Het impliceert structuur.

50
00:02:20,935 --> 00:02:23,120
En het betekent dat het op een computer.

51
00:02:23,120 --> 00:02:25,750
En databases niet
Er bestaan ​​altijd op computers.

52
00:02:25,750 --> 00:02:28,020
Databases daadwerkelijk op vele manieren bestaan.

53
00:02:28,020 --> 00:02:32,000
>> Dus een betere definitie van een
database is zoiets als dit.

54
00:02:32,000 --> 00:02:34,786
Een database is een georganiseerde
mechanisme voor het opslaan, beheren,

55
00:02:34,786 --> 00:02:35,910
en ophalen van informatie.

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

57
00:02:36,868 --> 00:02:42,080
Dus ik vind dit omdat het echt gesprekken
over een database die een repository,

58
00:02:42,080 --> 00:02:44,800
een opslagplaats van
informatie niet noodzakelijkerwijs

59
00:02:44,800 --> 00:02:46,780
iets dat zit op een computer.

60
00:02:46,780 --> 00:02:49,290
En door de geschiedenis heen, we
niet altijd computers.

61
00:02:49,290 --> 00:02:52,110
>> Nu, als ik vraag de gemiddelde
ontwikkelaar vandaag wat is

62
00:02:52,110 --> 00:02:54,770
een database, dat is het antwoord dat ik krijg.

63
00:02:54,770 --> 00:02:56,070
Ergens kan ik dingen vasthouden.

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

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

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

67
00:02:59,600 --> 00:03:02,700
Omdat de database werkelijk
het fundament van de moderne app.

68
00:03:02,700 --> 00:03:04,810
Het is de stichting
van elke toepassing.

69
00:03:04,810 --> 00:03:07,240
En hoe je dat bouwen
databank, hoe je de structuur

70
00:03:07,240 --> 00:03:11,750
die gegevens gaat dicteren hoe dat
applicatie presteert zoals u schalen.

71
00:03:11,750 --> 00:03:14,640
>> Dus veel van mijn werk vandaag
houdt zich bezig met wat

72
00:03:14,640 --> 00:03:17,180
gebeurt wanneer ontwikkelaars
nemen deze aanpak

73
00:03:17,180 --> 00:03:19,510
en het omgaan met de nasleep
van een toepassing die

74
00:03:19,510 --> 00:03:24,966
nu schalen dan de oorspronkelijke
intentie en het lijden van slecht ontwerp.

75
00:03:24,966 --> 00:03:26,840
Dus hopelijk wanneer je
lopen vandaag weg, zult u

76
00:03:26,840 --> 00:03:29,010
hebben een paar van de gereedschappen in
je riem die je houden

77
00:03:29,010 --> 00:03:32,566
van het maken van die dezelfde fouten.

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

79
00:03:33,066 --> 00:03:36,360
Dus laten we praten over een beetje
de tijdlijn van databasetechnologie.

80
00:03:36,360 --> 00:03:38,830
Ik denk dat ik las een
artikel niet zo lang geleden

81
00:03:38,830 --> 00:03:43,020
en het zei iets over de lines--
het is een zeer poëtisch statement.

82
00:03:43,020 --> 00:03:46,590
Het zei de geschiedenis
van de gegevensverwerking is

83
00:03:46,590 --> 00:03:49,350
vol van hoge watermerken
data overvloed.

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

85
00:03:49,920 --> 00:03:52,532
Nu, ik denk dat dat soort waar.

86
00:03:52,532 --> 00:03:54,990
Maar ik eigenlijk kijken is als
de geschiedenis is eigenlijk gevuld

87
00:03:54,990 --> 00:03:56,820
met een high watermark van data druk.

88
00:03:56,820 --> 00:04:00,040
Omdat de datasnelheid van
inname gaat nooit naar beneden.

89
00:04:00,040 --> 00:04:01,360
Alleen gaat omhoog.

90
00:04:01,360 --> 00:04:03,670
>> En innovatie ontstaat wanneer
zien we data druk, die

91
00:04:03,670 --> 00:04:07,825
is de hoeveelheid gegevens die
Nu in die in het systeem.

92
00:04:07,825 --> 00:04:12,027
En het kan niet worden verwerkt
efficiënt in tijd of in de kosten.

93
00:04:12,027 --> 00:04:14,110
En dat is wanneer we beginnen
om te kijken naar de gegevens druk.

94
00:04:14,110 --> 00:04:15,920
>> Dus als we kijken naar de
eerste gegevensbank, dit

95
00:04:15,920 --> 00:04:17,180
is degene die was tussen onze oren.

96
00:04:17,180 --> 00:04:18,310
We zijn allemaal geboren.

97
00:04:18,310 --> 00:04:19,194
Het is een mooie database.

98
00:04:19,194 --> 00:04:21,110
Het heeft een hoge beschikbaarheid.

99
00:04:21,110 --> 00:04:21,959
Het is altijd aan.

100
00:04:21,959 --> 00:04:23,930
U kunt altijd krijgen.

101
00:04:23,930 --> 00:04:24,890
>> Maar het is één gebruiker.

102
00:04:24,890 --> 00:04:26,348
Ik kan niet delen mijn gedachten met u.

103
00:04:26,348 --> 00:04:28,370
Je kunt niet mijn gedachten te krijgen
als je wilt dat ze.

104
00:04:28,370 --> 00:04:30,320
En hun abilitiy is niet zo goed.

105
00:04:30,320 --> 00:04:32,510
We vergeten dingen.

106
00:04:32,510 --> 00:04:36,540
Zo nu en dan, een van ons bladeren
en verhuist naar een ander bestaan

107
00:04:36,540 --> 00:04:39,110
en we alles kwijt
die in de databank.

108
00:04:39,110 --> 00:04:40,640
Dus dat is niet zo goed.

109
00:04:40,640 --> 00:04:43,189
>> En dat werkte goed in de tijd
toen we terug in de dag

110
00:04:43,189 --> 00:04:46,230
wanneer alles wat we echt nodig om te weten is
waar gaan we heen te gaan op morgen

111
00:04:46,230 --> 00:04:49,630
of waar we verzamelen van de beste voedsel.

112
00:04:49,630 --> 00:04:52,820
Maar zoals we begonnen te groeien als een
beschaving en de overheid begonnen

113
00:04:52,820 --> 00:04:55,152
tot stand te komen, en
bedrijven begonnen te evolueren,

114
00:04:55,152 --> 00:04:57,360
we begonnen te beseffen dat we
hebben een beetje meer dan

115
00:04:57,360 --> 00:04:58,210
konden we in ons hoofd zetten.

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

117
00:04:58,870 --> 00:05:00,410
>> We hadden behoefte aan systemen van het record.

118
00:05:00,410 --> 00:05:02,220
We moesten plaatsen om te kunnen slaan gegevens.

119
00:05:02,220 --> 00:05:05,450
Dus we begonnen met het schrijven van documenten,
het creëren van bibliotheken en archieven.

120
00:05:05,450 --> 00:05:08,000
We zijn begonnen met het ontwikkelen van een
systeem een ​​grootboek boekhouding.

121
00:05:08,000 --> 00:05:12,200
En dat het systeem van grootboek tellen
liep de hele wereld voor vele eeuwen,

122
00:05:12,200 --> 00:05:15,580
en misschien zelfs millennia als
we soort groeide uit tot het punt

123
00:05:15,580 --> 00:05:18,420
wanneer die gegevens belasting overtroffen
het vermogen van deze systemen

124
00:05:18,420 --> 00:05:19,870
in staat om het te bevatten.

125
00:05:19,870 --> 00:05:22,070
>> En dit werkelijk is gebeurd in de jaren 1880.

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

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

128
00:05:24,390 --> 00:05:26,976
Dit is echt wanneer het draaien
wijzen moderne gegevensverwerking.

129
00:05:26,976 --> 00:05:28,850
Dit is het punt
waarbij de hoeveelheid data

130
00:05:28,850 --> 00:05:32,060
dat werd verzameld door de
Amerikaanse regering kwam tot het punt

131
00:05:32,060 --> 00:05:34,005
wanneer duurde acht jaar te verwerken.

132
00:05:34,005 --> 00:05:36,350
>> Nu, acht years-- als
je weet wel, de volkstelling

133
00:05:36,350 --> 00:05:39,180
rijdt elke 10 years-- dus het is
vrij duidelijk dat we door de tijd

134
00:05:39,180 --> 00:05:41,419
kreeg de volkstelling van 1890,
de hoeveelheid gegevens die

135
00:05:41,419 --> 00:05:43,210
zou worden verwerkt
door de overheid was

136
00:05:43,210 --> 00:05:46,335
naar de 10 jaar overschrijdt dat
zou nemen om lanceerde de nieuwe telling.

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

138
00:05:47,250 --> 00:05:49,000
>> Dus een man genaamd Herman
Hollerith kwam langs

139
00:05:49,000 --> 00:05:52,640
en hij bedacht eenheid plaat punch
kaarten, punch kaartlezer, ponskaart

140
00:05:52,640 --> 00:05:58,420
tabulator, en de verzameling van
de mechanismen voor deze technologie.

141
00:05:58,420 --> 00:06:01,860
En dat bedrijf dat hij in de gevormde
tijd, samen met een aantal anderen,

142
00:06:01,860 --> 00:06:05,450
eigenlijk werd een van de pijlers van een
klein bedrijf dat we vandaag kennen genaamd IBM.

143
00:06:05,450 --> 00:06:08,417
>> Dus IBM oorspronkelijk was
de database business.

144
00:06:08,417 --> 00:06:09,750
En dat is echt wat ze deden.

145
00:06:09,750 --> 00:06:11,110
Zij deden gegevensverwerking.

146
00:06:11,110 --> 00:06:15,400
>> Zoals zo de proliferatie van punch
kaarten, een ingenieus mechanisme

147
00:06:15,400 --> 00:06:18,560
van de mogelijkheid om gebruik te maken dat
technologie om gesorteerde resultaat sets pollen.

148
00:06:18,560 --> 00:06:20,726
U kunt zien op deze foto
daar hebben we een little--

149
00:06:20,726 --> 00:06:23,970
het is een beetje small-- maar je kunt zien
een zeer ingenieus mechanisch mechanisme

150
00:06:23,970 --> 00:06:26,970
waar we een ponskaart dek.

151
00:06:26,970 --> 00:06:28,720
En het nemen van iemands
een kleine schroevendraaier

152
00:06:28,720 --> 00:06:31,400
en steken door de
slots en tillen

153
00:06:31,400 --> 00:06:34,820
om die wedstrijd te krijgen, dat
gesorteerd resultatenset.

154
00:06:34,820 --> 00:06:36,270
>> Dit is een aggregatie.

155
00:06:36,270 --> 00:06:38,690
We doen dit de hele tijd
vandaag in de computer,

156
00:06:38,690 --> 00:06:40,100
waar je het doen in de database.

157
00:06:40,100 --> 00:06:41,620
We gebruikt om handmatig te doen, toch?

158
00:06:41,620 --> 00:06:42,994
Mensen zetten deze dingen samen.

159
00:06:42,994 --> 00:06:45,440
En het was de proliferatie
van deze ponskaarten

160
00:06:45,440 --> 00:06:50,070
in wat we genaamd data drums
en data-rollen, papier tape.

161
00:06:50,070 --> 00:06:55,980
>> De gegevens verwerkende industrie nam
een les van de speler piano's.

162
00:06:55,980 --> 00:06:57,855
Pianola's terug op
het begin van de eeuw

163
00:06:57,855 --> 00:07:02,100
gebruikt voor papierrollen met slots
op om het te vertellen welke toetsen om te spelen.

164
00:07:02,100 --> 00:07:05,380
Zodat technologie aangepast
uiteindelijk digitale gegevens,

165
00:07:05,380 --> 00:07:08,070
omdat ze die gegevens kon zetten
op die papieren band rollen.

166
00:07:08,070 --> 00:07:10,870
>> Nu, als gevolg, data
werd actually-- hoe

167
00:07:10,870 --> 00:07:14,960
u toegang tot deze gegevens was direct
afhankelijk van hoe je het opgeslagen.

168
00:07:14,960 --> 00:07:17,825
Dus als ik de gegevens op een tape,
Ik had toegang tot de gegevens lineair.

169
00:07:17,825 --> 00:07:20,475
Ik moest de hele rollen
tape om alle data.

170
00:07:20,475 --> 00:07:22,600
Als ik de gegevens in punch
kaarten, kon ik het toegang

171
00:07:22,600 --> 00:07:26,270
in iets meer willekeurige
mode, misschien niet zo snel.

172
00:07:26,270 --> 00:07:30,770
>> Maar er waren beperkingen in de manier waarop we
toegang tot gegevens op basis van hoe werd opgeslagen.

173
00:07:30,770 --> 00:07:32,890
En dus was dit een probleem
gaan in de jaren '50.

174
00:07:32,890 --> 00:07:37,890
Nogmaals, kunnen we beginnen te zien dat als we
nieuwe technologieën te verwerken ontwikkelen

175
00:07:37,890 --> 00:07:41,670
de gegevens, rechts, het opent
de deur naar nieuwe oplossingen,

176
00:07:41,670 --> 00:07:45,852
voor nieuwe programma's, nieuwe
aanvragen voor die gegevens.

177
00:07:45,852 --> 00:07:47,810
En echt, het bestuur
kan de reden geweest

178
00:07:47,810 --> 00:07:49,435
Daarom ontwikkelden we een aantal van deze systemen.

179
00:07:49,435 --> 00:07:52,290
Maar de zaken snel werd
de bestuurder achter de evolutie

180
00:07:52,290 --> 00:07:54,720
van de moderne database
het moderne bestandssysteem.

181
00:07:54,720 --> 00:07:56,870
>> Dus de volgende ding dat
kwam was in de jaren '50

182
00:07:56,870 --> 00:08:00,780
was het bestandssysteem en de
ontwikkeling van random access opslag.

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

184
00:08:02,050 --> 00:08:06,230
Nu, alle van een plotselinge, kunnen we onze
bestanden overal op deze harde schijven

185
00:08:06,230 --> 00:08:09,760
en we kunnen deze gegevens willekeurig toegang.

186
00:08:09,760 --> 00:08:11,950
We kunnen ontleden dat
informatie uit bestanden.

187
00:08:11,950 --> 00:08:14,920
En we opgelost hele wereld
problemen gegevensverwerking.

188
00:08:14,920 --> 00:08:17,550
>> En dat duurde ongeveer 20 of
30 jaar tot de evolutie

189
00:08:17,550 --> 00:08:22,100
van de relationele database, die
wanneer de wereld besloten we nu

190
00:08:22,100 --> 00:08:27,940
moet een repository die nederlagen hebben
de wildgroei van de gegevens over het bestand

191
00:08:27,940 --> 00:08:29,540
systemen die we hebben opgebouwd. Rechts?

192
00:08:29,540 --> 00:08:34,270
Te veel gegevens verdeeld in te veel
plaatsen, de de-duplicatie van data,

193
00:08:34,270 --> 00:08:37,120
en opslagkosten was enorm.

194
00:08:37,120 --> 00:08:43,760
>> In de jaren '70, de duurste bron
een computer had was de opslag.

195
00:08:43,760 --> 00:08:46,200
De processor was
gezien vaste kosten.

196
00:08:46,200 --> 00:08:49,030
Toen ik koop de doos,
de CPU doet wat werk.

197
00:08:49,030 --> 00:08:51,960
Het gaat om spinnen of
het is eigenlijk werkt of niet.

198
00:08:51,960 --> 00:08:53,350
Dat is echt een verzonken kosten.

199
00:08:53,350 --> 00:08:56,030
>> Maar wat kostte me als een
business is opslag.

200
00:08:56,030 --> 00:09:00,020
Als ik meer schijven kopen volgende
maand, dat is een echte prijs die ik betaal.

201
00:09:00,020 --> 00:09:01,620
En dat de opslag is duur.

202
00:09:01,620 --> 00:09:05,020
>> Nu zijn we snel vooruit 40 jaar
en we hebben een ander probleem.

203
00:09:05,020 --> 00:09:10,020
Het berekenen is nu de
duurste bron.

204
00:09:10,020 --> 00:09:11,470
De opslag is goedkoop.

205
00:09:11,470 --> 00:09:14,570
Ik bedoel, we kunnen overal op de
cloud en kunnen we goedkope opslag te vinden.

206
00:09:14,570 --> 00:09:17,190
Maar wat ik niet kan vinden is goedkoop berekenen.

207
00:09:17,190 --> 00:09:20,700
>> Dus de evolutie van de huidige
technologie, database technologie,

208
00:09:20,700 --> 00:09:23,050
is echt rond gericht
gedistribueerde databases

209
00:09:23,050 --> 00:09:26,960
die niet lijden
hetzelfde type schaal

210
00:09:26,960 --> 00:09:29,240
beperkingen van relationele databases.

211
00:09:29,240 --> 00:09:32,080
We zullen een klein beetje over praten
wat dat eigenlijk betekent.

212
00:09:32,080 --> 00:09:34,760
>> Maar een van de redenen en
de bestuurder achter dit-- we

213
00:09:34,760 --> 00:09:38,290
sprak over de gegevens druk.

214
00:09:38,290 --> 00:09:41,920
Gegevens druk iets
dat drijft innovatie.

215
00:09:41,920 --> 00:09:44,610
En als je kijkt naar boven
de laatste vijf jaar,

216
00:09:44,610 --> 00:09:48,180
Dit is een grafiek van wat de data
belasting over de algemene enterprise

217
00:09:48,180 --> 00:09:49,640
ziet er in de afgelopen vijf jaar.

218
00:09:49,640 --> 00:09:52,570
>> En de algemene vuistregel
deze dagen-- als je Google--

219
00:09:52,570 --> 00:09:55,290
is 90% van de gegevens
we nu opslaan en het

220
00:09:55,290 --> 00:09:57,330
gegenereerd in de afgelopen twee jaar.

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

222
00:09:57,911 --> 00:09:59,410
Nu, dit is niet een trend die is nieuw.

223
00:09:59,410 --> 00:10:01,230
Dit is een trend die is geweest
gaan voor 100 jaar.

224
00:10:01,230 --> 00:10:03,438
Sinds Herman Hollerith
ontwikkelde de ponskaart,

225
00:10:03,438 --> 00:10:08,040
we hebben het bouwen van data repositories
en het verzamelen van gegevens op fenomenale tarieven.

226
00:10:08,040 --> 00:10:10,570
>> Dus in de afgelopen 100 jaar,
we hebben deze trend gezien.

227
00:10:10,570 --> 00:10:11,940
Dat gaat niet veranderen.

228
00:10:11,940 --> 00:10:14,789
Going forward, we gaan om te zien
Dit, zo niet een versnelde trend.

229
00:10:14,789 --> 00:10:16,330
En je kunt zien hoe dat eruit ziet.

230
00:10:16,330 --> 00:10:23,510
>> Als een bedrijf in 2010 had een
terabyte aan gegevens onder beheer,

231
00:10:23,510 --> 00:10:27,080
vandaag aan dat betekent dat ze
managing 6,5 petabyte aan data.

232
00:10:27,080 --> 00:10:30,380
Dat is 6.500 keer meer gegevens.

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

234
00:10:31,200 --> 00:10:33,292
Ik werk met deze bedrijven elke dag.

235
00:10:33,292 --> 00:10:35,000
Vijf jaar geleden heb ik
aan bedrijven zouden praten

236
00:10:35,000 --> 00:10:38,260
die mij zou praten over wat een pijn
het is om terabytes aan gegevens te beheren.

237
00:10:38,260 --> 00:10:39,700
En zij zouden praten
om me over hoe we zien

238
00:10:39,700 --> 00:10:41,825
dat dit gaat waarschijnlijk
een petabyte of twee

239
00:10:41,825 --> 00:10:43,030
binnen een paar jaar.

240
00:10:43,030 --> 00:10:45,170
>> Deze zelfde bedrijven
vandaag ben ik een ontmoeting met,

241
00:10:45,170 --> 00:10:48,100
en ze praten met mij over de
probleem zijn er met het beheer

242
00:10:48,100 --> 00:10:51,440
tientallen, 20 petabyte aan data.

243
00:10:51,440 --> 00:10:53,590
Dus de explosie van de
data in de industrie

244
00:10:53,590 --> 00:10:56,670
drijft de enorme
behoefte aan betere oplossingen.

245
00:10:56,670 --> 00:11:00,980
En de relationele database is
gewoon niet naleven van de vraag.

246
00:11:00,980 --> 00:11:03,490
>> En dus is er een lineaire
correlatie tussen de gegevens druk

247
00:11:03,490 --> 00:11:05,210
en technische innovatie.

248
00:11:05,210 --> 00:11:07,780
De geschiedenis heeft ons geleerd
dit, dat de tijd,

249
00:11:07,780 --> 00:11:11,090
wanneer de hoeveelheid gegevens
dat moet worden verwerkt

250
00:11:11,090 --> 00:11:15,490
groter is dan de capaciteit van het systeem
om het te verwerken in een redelijke tijd

251
00:11:15,490 --> 00:11:18,870
of tegen redelijke kosten,
dan nieuwe technologieën

252
00:11:18,870 --> 00:11:21,080
uitgevonden om deze problemen op te lossen.

253
00:11:21,080 --> 00:11:24,090
Deze nieuwe technologieën,
op zijn beurt, de deur open

254
00:11:24,090 --> 00:11:27,840
naar een andere set van problemen, die
is het verzamelen van nog meer gegevens.

255
00:11:27,840 --> 00:11:29,520
>> Nu, we zijn niet van plan om dit te stoppen.

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

257
00:11:30,020 --> 00:11:31,228
We zijn niet van plan om dit te stoppen.

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

259
00:11:31,830 --> 00:11:35,520
Want je kunt niet alles weten
er is om te weten in het universum.

260
00:11:35,520 --> 00:11:40,510
En zolang we in leven geweest,
de hele geschiedenis van de mens,

261
00:11:40,510 --> 00:11:43,440
we hebben altijd gedreven om meer te weten.

262
00:11:43,440 --> 00:11:49,840
>> Dus het lijkt alsof elke inch we verhuizen
het pad van de wetenschappelijke ontdekking,

263
00:11:49,840 --> 00:11:54,620
wij zijn de hoeveelheid data te vermenigvuldigen
die we nodig hebben om exponentieel te verwerken

264
00:11:54,620 --> 00:11:59,920
we ontdekken steeds meer
over de interne werking van het leven,

265
00:11:59,920 --> 00:12:04,530
over hoe het universum werkt, over
besturen van de wetenschappelijke ontdekking,

266
00:12:04,530 --> 00:12:06,440
en de uitvinding die
die we vandaag doen.

267
00:12:06,440 --> 00:12:09,570
Het volume van de gegevens alleen
voortdurend toeneemt.

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

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

270
00:12:14,790 --> 00:12:17,410
>> Dus een van de dingen
we kijken als waarom NoSQL?

271
00:12:17,410 --> 00:12:19,200
Hoe werkt NoSQL dit probleem oplossen?

272
00:12:19,200 --> 00:12:24,980
Nou, relationele databases,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- dat is echt een constructie van het
relationele database-- deze dingen zijn

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

275
00:12:30,770 --> 00:12:33,180
>> Terug in de jaren '70, opnieuw,
disk is duur.

276
00:12:33,180 --> 00:12:36,990
De provisioning uitoefening van opslag
in de onderneming is nooit eindigende.

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

278
00:12:37,490 --> 00:12:38,020
Ik leefde het.

279
00:12:38,020 --> 00:12:41,250
Ik schreef opslag drivers voor een
enterprised superserver bedrijf

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

281
00:12:42,470 --> 00:12:45,920
En de bottom line is racking andere
storage array was gewoon iets dat

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

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

284
00:12:49,030 --> 00:12:52,690
Opslag hogere dichtheid vraag
voor hoge opslagdichtheid,

285
00:12:52,690 --> 00:12:56,340
en meer efficiënte opslag
devices-- het is nooit gestopt.

286
00:12:56,340 --> 00:13:00,160
>> En NoSQL is een geweldige technologie
omdat normaliseert de gegevens.

287
00:13:00,160 --> 00:13:02,210
Het de-dupliceert de gegevens.

288
00:13:02,210 --> 00:13:07,180
Het zet de gegevens in een structuur die
is agnostisch om elke toegang patroon.

289
00:13:07,180 --> 00:13:11,600
Meerdere applicaties kan raken dat
SQL-database, voert ad hoc queries,

290
00:13:11,600 --> 00:13:15,950
en krijgen de gegevens in de vorm die zij
moeten werkwijze voor de werklast.

291
00:13:15,950 --> 00:13:17,570
Dat klinkt fantastisch.

292
00:13:17,570 --> 00:13:21,350
Maar de bottom line is met enige
systeem, als het agnostisch om alles,

293
00:13:21,350 --> 00:13:23,500
het is geoptimaliseerd voor niets.

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

295
00:13:24,050 --> 00:13:26,386
>> En dat is wat we krijgen met
de relationele database.

296
00:13:26,386 --> 00:13:27,510
Het is geoptimaliseerd voor opslag.

297
00:13:27,510 --> 00:13:28,280
Het is genormaliseerd.

298
00:13:28,280 --> 00:13:29,370
Het is relationele.

299
00:13:29,370 --> 00:13:31,660
Het ondersteunt de ad hoc queries.

300
00:13:31,660 --> 00:13:34,000
En het en het schalen verticaal.

301
00:13:34,000 --> 00:13:39,030
>> Als ik moet een grotere SQL-database te krijgen
of een krachtigere SQL-database,

302
00:13:39,030 --> 00:13:41,090
Ik ga kopen een groter stuk ijzer.

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

304
00:13:41,600 --> 00:13:44,940
Ik heb gewerkt met veel klanten
dat door middel van belangrijke upgrades zijn geweest

305
00:13:44,940 --> 00:13:48,340
in de SQL alleen infrastructuur
om uit te vinden zes maanden later,

306
00:13:48,340 --> 00:13:49,750
ze zijn weer het raken van de muur.

307
00:13:49,750 --> 00:13:55,457
En het antwoord van Oracle of MSSQL
of iemand anders is krijgen een grotere doos.

308
00:13:55,457 --> 00:13:58,540
Nou vroeg of laat, kun je niet kopen van een
grote doos, en dat is echt een probleem.

309
00:13:58,540 --> 00:14:00,080
We moeten echt dingen te veranderen.

310
00:14:00,080 --> 00:14:01,080
Dus waar komt dit?

311
00:14:01,080 --> 00:14:06,560
Het werkt goed voor offline
analytics, OLAP-type workloads.

312
00:14:06,560 --> 00:14:08,670
En dat is echt waar de SQL behoort.

313
00:14:08,670 --> 00:14:12,540
Nu, het is vandaag de dag gebruikt in vele online
transactionele verwerking-type

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

315
00:14:13,330 --> 00:14:16,460
En het werkt prima op
zekere mate van gebruik,

316
00:14:16,460 --> 00:14:18,670
maar het gewoon niet schaal
de manier waarop NoSQL doet.

317
00:14:18,670 --> 00:14:20,660
En we zullen een beetje praten
beetje over waarom dat zo is.

318
00:14:20,660 --> 00:14:23,590
>> Nu NoSQL, anderzijds,
is meer geoptimaliseerd voor compute.

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

320
00:14:24,540 --> 00:14:26,830
Het is niet agnostisch te
de toegang patroon.

321
00:14:26,830 --> 00:14:31,620
Is wat wij noemen de-genormaliseerde
structuur of een hiërarchische structuur.

322
00:14:31,620 --> 00:14:35,000
De gegevens in een relationele database
samengevoegd uit meerdere tabellen

323
00:14:35,000 --> 00:14:36,850
de opvatting dat je nodig hebt produceren.

324
00:14:36,850 --> 00:14:40,090
De gegevens in een databank NoSQL
wordt opgeslagen in een document

325
00:14:40,090 --> 00:14:42,100
bevat de hiërarchische structuur.

326
00:14:42,100 --> 00:14:45,670
Alle gegevens die normaal zouden zijn
samengevoegd dat standpunt te produceren

327
00:14:45,670 --> 00:14:47,160
wordt opgeslagen in een enkel document.

328
00:14:47,160 --> 00:14:50,990
En we zullen een klein beetje over praten
hoe dat werkt in een paar grafieken.

329
00:14:50,990 --> 00:14:55,320
>> Maar het idee is hier dat u opslaat
uw gegevens zoals deze geïnstantieerd uitzicht.

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

331
00:14:56,410 --> 00:14:58,610
Je schaal horizontaal.

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

333
00:14:59,556 --> 00:15:02,100
Als ik moet het verhogen
grootte van mijn NoSQL cluster,

334
00:15:02,100 --> 00:15:03,700
Ik heb geen behoefte om een ​​grotere doos te krijgen.

335
00:15:03,700 --> 00:15:05,200
Ik krijg een andere doos.

336
00:15:05,200 --> 00:15:07,700
En ik cluster die samen,
en ik kan die gegevens shard.

337
00:15:07,700 --> 00:15:10,780
We zullen een beetje over praten
Wat sharding is, worden

338
00:15:10,780 --> 00:15:14,270
staat op schaal die database
over meerdere fysieke apparaten

339
00:15:14,270 --> 00:15:18,370
en verwijder de barrière die
vraagt ​​me om verticaal te schalen.

340
00:15:18,370 --> 00:15:22,080
>> Dus het is echt gebouwd voor online
transactieverwerking en schaal.

341
00:15:22,080 --> 00:15:25,480
Er is een groot verschil
hier tussen rapportage, toch?

342
00:15:25,480 --> 00:15:27,810
Rapporteren, weet ik niet de
vragen Ik ga om te vragen.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- als iemand uit
mijn marketing afdeling

345
00:15:30,570 --> 00:15:34,520
wil hoe veel van mijn klanten gewoon--
hebben deze bijzondere eigenschap die

346
00:15:34,520 --> 00:15:37,850
gekocht op dit dag-- Ik weet het niet
wat een query ze gaan vragen.

347
00:15:37,850 --> 00:15:39,160
Dus ik moet agnostisch te zijn.

348
00:15:39,160 --> 00:15:41,810
>> Nu, in een online
transactionele applicatie

349
00:15:41,810 --> 00:15:43,820
Ik weet welke vragen ik vraag.

350
00:15:43,820 --> 00:15:46,581
Ik de aanvraag voor gebouwd
een zeer specifieke workflow.

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

352
00:15:47,080 --> 00:15:50,540
Dus als ik het optimaliseren van de data
opslaan die workflow ondersteunen

353
00:15:50,540 --> 00:15:52,020
het gaat sneller.

354
00:15:52,020 --> 00:15:55,190
En dat is waarom NoSQL kan
echt versnellen van de levering

355
00:15:55,190 --> 00:15:57,710
van die typen diensten.

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

357
00:15:58,210 --> 00:16:00,501
>> Dus we gaan krijgen in
een stukje theorie hier.

358
00:16:00,501 --> 00:16:03,330
En sommigen van u, uw ogen
zou terugdraaien een beetje.

359
00:16:03,330 --> 00:16:06,936
Maar ik zal proberen om het te houden
zo hoog als ik kan.

360
00:16:06,936 --> 00:16:08,880
Dus als je in het project
management, er is

361
00:16:08,880 --> 00:16:12,280
een construct genaamd
driehoek van beperkingen.

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

363
00:16:12,936 --> 00:16:16,060
De driehoek van bedwingt dictaten
je kunt niet alles hebben de hele tijd.

364
00:16:16,060 --> 00:16:17,750
Kan niet over uw taart en eet het ook.

365
00:16:17,750 --> 00:16:22,310
Dus in projectmanagement, dat driehoek
beperkingen is dat je kunt het goedkoop hebben,

366
00:16:22,310 --> 00:16:24,710
je kunt het snel moet,
of u kunt het goed.

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

368
00:16:25,716 --> 00:16:27,090
Want je kunt niet alle drie.

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

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

371
00:16:27,820 --> 00:16:28,920
>> Dus je hoort over dit veel.

372
00:16:28,920 --> 00:16:31,253
Het is een drievoudige beperking,
driehoek van drievoudige beperking,

373
00:16:31,253 --> 00:16:34,420
of ijzeren driehoek oftentimes--
als je praat met projectmanagers,

374
00:16:34,420 --> 00:16:35,420
ze over praten.

375
00:16:35,420 --> 00:16:37,640
Nu, databases
hun eigen ijzeren driehoek.

376
00:16:37,640 --> 00:16:40,350
En het ijzeren driehoek data
is wat wij GLB stelling noemen.

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

378
00:16:41,580 --> 00:16:43,770
>> CAP stelling dicteert
hoe databases werken

379
00:16:43,770 --> 00:16:45,627
onder een specifieke omstandigheid.

380
00:16:45,627 --> 00:16:47,460
En we praten over
wat die voorwaarde is.

381
00:16:47,460 --> 00:16:52,221
Maar de drie punten van de driehoek,
zogezegd, zijn C, consistentie.

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

383
00:16:52,720 --> 00:16:56,760
Dus in het GLB, consistentie betekent dat alle
klanten die toegang tot de database

384
00:16:56,760 --> 00:16:59,084
zal altijd een zeer
consistente weergave van gegevens.

385
00:16:59,084 --> 00:17:00,750
Niemand gaat zien twee verschillende dingen.

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

387
00:17:01,480 --> 00:17:04,020
Als ik zie de database,
Ik zie dezelfde mening

388
00:17:04,020 --> 00:17:06,130
als mijn partner die ziet
dezelfde database.

389
00:17:06,130 --> 00:17:07,470
Dat is consistentie.

390
00:17:07,470 --> 00:17:12,099
>> Beschikbaarheid betekent dat als de
databank online, als het kan worden bereikt,

391
00:17:12,099 --> 00:17:14,760
dat alle klanten zullen altijd
kunnen lezen en schrijven.

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

393
00:17:15,260 --> 00:17:17,010
Zodat iedere klant dat
kan de database lezen

394
00:17:17,010 --> 00:17:18,955
zal altijd in staat te lezen
data en schrijven van gegevens.

395
00:17:18,955 --> 00:17:21,819
En als dat het geval is,
het is een beschikbaar systeem.

396
00:17:21,819 --> 00:17:24,230
>> En het derde punt is wat
wij noemen partitie tolerantie.

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

398
00:17:24,730 --> 00:17:28,160
Partitie tolerantie middelen
dat het systeem goed werkt

399
00:17:28,160 --> 00:17:32,000
ondanks fysieke netwerk
wanden tussen de knooppunten.

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

401
00:17:32,760 --> 00:17:36,270
Dus knooppunten in het cluster kan niet
praten met elkaar, wat gebeurt er?

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

403
00:17:36,880 --> 00:17:39,545
>> Dus relationele databases choose--
kunt u twee van deze te halen.

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

405
00:17:40,045 --> 00:17:43,680
Dus relationele databases kiezen
consistent te zijn en beschikbaar zijn.

406
00:17:43,680 --> 00:17:47,510
Als de partitie gebeurt tussen
de DataNodes in de gegevens op te slaan,

407
00:17:47,510 --> 00:17:48,831
de database crasht.

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

409
00:17:49,330 --> 00:17:50,900
Het gaat gewoon naar beneden.

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

411
00:17:51,450 --> 00:17:54,230
>> En dit is waarom ze hebben
om te groeien met grotere dozen.

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

413
00:17:54,730 --> 00:17:58,021
Omdat er no-- meestal een cluster
databank, is er niet heel veel van hen

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

415
00:17:59,590 --> 00:18:03,019
Maar de meeste databases schalen
verticaal in een doos.

416
00:18:03,019 --> 00:18:05,060
Omdat ze moeten worden
consistente en beschikbaar.

417
00:18:05,060 --> 00:18:10,320
Als een partitie zou worden geïnjecteerd
dan zou je een keuze te maken.

418
00:18:10,320 --> 00:18:13,720
Je moet een keuze te maken tussen de
consequent en beschikbaar.

419
00:18:13,720 --> 00:18:16,080
>> En dat is wat NoSQL-databases doen.

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

421
00:18:16,580 --> 00:18:20,950
Dus een NoSQL database is
komt in twee smaken.

422
00:18:20,950 --> 00:18:22,990
We have-- goed, het
komt in vele smaken,

423
00:18:22,990 --> 00:18:26,140
maar het komt met twee fundamentele
characteristics-- wat

424
00:18:26,140 --> 00:18:30,050
we zouden CP-database, of een bel
consistente en partitie tolerantie

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

426
00:18:31,040 --> 00:18:34,930
Deze jongens maken de keuze die bij
de knooppunten verliest contact met elkaar,

427
00:18:34,930 --> 00:18:37,091
we gaan niet toestaan
mensen om nog meer te schrijven.

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

429
00:18:37,590 --> 00:18:41,855
>> Tot die partitie is verwijderd,
schrijftoegang geblokkeerd.

430
00:18:41,855 --> 00:18:43,230
Dat betekent dat ze niet beschikbaar.

431
00:18:43,230 --> 00:18:44,510
Ze zijn consistent.

432
00:18:44,510 --> 00:18:46,554
Wanneer we zien dat
partitie injecteren zelf,

433
00:18:46,554 --> 00:18:48,470
we zijn nu consistent,
want we gaan niet

434
00:18:48,470 --> 00:18:51,517
om de gegevens te wijzigen op twee toestaan
zijden van de scheidingswand zelfstandig

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

436
00:18:52,100 --> 00:18:54,130
We moeten
herstellen communicatie

437
00:18:54,130 --> 00:18:56,930
voordat een update
de gegevens is toegestaan.

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

439
00:18:58,120 --> 00:19:02,650
>> Aan de smaak zou AP systeem,
of een beschikbare en verdeeld

440
00:19:02,650 --> 00:19:03,640
tolerance systeem.

441
00:19:03,640 --> 00:19:05,320
Deze jongens niet schelen.

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

443
00:19:06,020 --> 00:19:08,960
Elk knooppunt dat een krijgt
schrijven, we nemen het.

444
00:19:08,960 --> 00:19:11,480
Dus ik ben het repliceren van mijn gegevens
over meerdere nodes.

445
00:19:11,480 --> 00:19:14,730
Deze knooppunten krijgt een klant, klant komt
in, zegt, ga ik een aantal gegevens te schrijven.

446
00:19:14,730 --> 00:19:16,300
Knooppunt zegt, geen probleem.

447
00:19:16,300 --> 00:19:18,580
Het knooppunt naast hem krijgt
een waardevermindering op dezelfde record,

448
00:19:18,580 --> 00:19:20,405
hij zal geen probleem te zeggen.

449
00:19:20,405 --> 00:19:23,030
Ergens terug op het einde terug,
die gegevens gaat repliceren.

450
00:19:23,030 --> 00:19:27,360
En dan iemand gaan realiseren,
uh-oh, ze systeem zal realiseren, uh-oh,

451
00:19:27,360 --> 00:19:28,870
er is al een update naar twee kanten.

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

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

454
00:19:33,210 --> 00:19:36,080
kunnen ze de gegevens staat lossen.

455
00:19:36,080 --> 00:19:39,000
En we praten over
die in de volgende tabel.

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

457
00:19:40,000 --> 00:19:42,374
En ik ben niet van plan te krijgen
veel in deze, omdat deze

458
00:19:42,374 --> 00:19:43,510
krijgt in diepe data theorie.

459
00:19:43,510 --> 00:19:46,670
Maar er is een transactionele
raamwerk dat

460
00:19:46,670 --> 00:19:50,680
uitgevoerd in een relationeel systeem
kan ik veilig te actualiseren

461
00:19:50,680 --> 00:19:53,760
meerdere entiteiten in de database.

462
00:19:53,760 --> 00:19:58,320
En die updates zal optreden
ineens of helemaal niet.

463
00:19:58,320 --> 00:20:00,500
En dit heet ACID transacties.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID geeft ons atomiciteit, consistentie,
isolatie en duurzaamheid.

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

467
00:20:07,070 --> 00:20:13,550
Dat betekent dat atomaire, transacties, alle
mijn updates ofwel gebeuren of ze dat niet doen.

468
00:20:13,550 --> 00:20:16,570
Consistentie betekent dat
de database zal altijd

469
00:20:16,570 --> 00:20:19,780
in een consistent worden gebracht
staat na een update.

470
00:20:19,780 --> 00:20:23,900
Ik zal nooit de database in een verlaten
slechte staat na het aanbrengen van een update.

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

472
00:20:24,400 --> 00:20:26,720
>> Dus het is een beetje anders
dan CAP consistentie.

473
00:20:26,720 --> 00:20:29,760
CAP consistentie betekent dat al mijn
klanten kunnen altijd zien de gegevens.

474
00:20:29,760 --> 00:20:34,450
ACID samenhang betekent dat wanneer
een transactie heeft gedaan, de gegevens van goed.

475
00:20:34,450 --> 00:20:35,709
Mijn relaties zijn allemaal goed.

476
00:20:35,709 --> 00:20:38,750
Ik ben niet van plan om een ​​ouder rij verwijderen
en laat een stel weeskinderen

477
00:20:38,750 --> 00:20:40,970
in een andere tabel.

478
00:20:40,970 --> 00:20:44,320
Het kan niet gebeuren als ik consequent
in zuur transactie.

479
00:20:44,320 --> 00:20:49,120
>> Isolatiemiddelen die transacties
geschiedt altijd na elkaar.

480
00:20:49,120 --> 00:20:51,920
Het eindresultaat van de data
zal dezelfde toestand

481
00:20:51,920 --> 00:20:54,770
alsof die transacties
die werden gelijktijdig uitgegeven

482
00:20:54,770 --> 00:20:57,340
werden serieel uitgevoerd.

483
00:20:57,340 --> 00:21:00,030
Dus het is concurrency
controle in de database.

484
00:21:00,030 --> 00:21:04,130
Dus eigenlijk, ik kan niet verhogen van de
dezelfde waarde tweemaal met twee operaties.

485
00:21:04,130 --> 00:21:08,580
>> Maar als ik zeg voeg 1 om deze waarde,
en twee transacties komen

486
00:21:08,580 --> 00:21:10,665
en proberen om het te doen, één is
gaan om daar eerst

487
00:21:10,665 --> 00:21:12,540
en de andere is
gaan om daar na te krijgen.

488
00:21:12,540 --> 00:21:15,210
Dus in het einde, voegde ik twee.

489
00:21:15,210 --> 00:21:16,170
Zie je wat ik bedoel?

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

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

492
00:21:19,220 --> 00:21:21,250
>> Duurzaamheid is vrij eenvoudig.

493
00:21:21,250 --> 00:21:23,460
Wanneer de transactie
wordt erkend, is het

494
00:21:23,460 --> 00:21:26,100
gaat er zelfs
als het systeem crasht.

495
00:21:26,100 --> 00:21:29,230
Toen dat systeem herstelt, dat
transactie die werd gepleegd

496
00:21:29,230 --> 00:21:30,480
er werkelijk gaande is om daar te zijn.

497
00:21:30,480 --> 00:21:33,130
Dus dat is de garanties
van ACID transacties.

498
00:21:33,130 --> 00:21:35,470
Die zijn vrij aardig garanties
om een ​​databank

499
00:21:35,470 --> 00:21:36,870
maar ze komen op die kosten.

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

501
00:21:37,640 --> 00:21:40,520
>> Omdat het probleem
met dit kader is

502
00:21:40,520 --> 00:21:44,540
Als er een wand in de data
set, ik moet een beslissing nemen.

503
00:21:44,540 --> 00:21:48,000
Ik ga moeten toestaan
updates aan één of de ander.

504
00:21:48,000 --> 00:21:50,310
En als dat gebeurt,
dan ben ik niet meer gaan

505
00:21:50,310 --> 00:21:52,630
te kunnen handhaven
deze kenmerken.

506
00:21:52,630 --> 00:21:53,960
Ze zullen niet in overeenstemming zijn.

507
00:21:53,960 --> 00:21:55,841
Ze zullen niet worden geïsoleerd.

508
00:21:55,841 --> 00:21:58,090
Dit is waar het afbreekt
voor relationele databases.

509
00:21:58,090 --> 00:22:01,360
Dit is de reden relationele
databases schalen verticaal.

510
00:22:01,360 --> 00:22:05,530
>> Aan de andere kant zijn
wat heet BASE technologie.

511
00:22:05,530 --> 00:22:07,291
En dit zijn uw NoSQL-databases.

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

513
00:22:07,790 --> 00:22:10,180
Dus hebben we onze CP, AP databases.

514
00:22:10,180 --> 00:22:14,720
En deze zijn wat je eigenlijk noemen
beschikbaar, zacht staat, uiteindelijk

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

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

517
00:22:16,420 --> 00:22:19,690
>> In principe mogelijk, omdat
ze partitie tolerant.

518
00:22:19,690 --> 00:22:21,470
Ze zullen altijd
daar, zelfs als er

519
00:22:21,470 --> 00:22:23,053
een netwerk afscheiding tussen de knooppunten.

520
00:22:23,053 --> 00:22:25,900
Als ik naar een knooppunt kan praten, ik ben
zal in staat zijn om gegevens te lezen.

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

522
00:22:26,460 --> 00:22:30,810
Ik misschien niet altijd in staat zijn om te schrijven
data als ik een consistent platform.

523
00:22:30,810 --> 00:22:32,130
Maar ik zal in staat zijn om gegevens te lezen.

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

525
00:22:34,960 --> 00:22:38,010
>> De zachte toestand geeft
dat toen ik las dat de gegevens,

526
00:22:38,010 --> 00:22:40,790
het misschien niet hetzelfde als andere knooppunten zijn.

527
00:22:40,790 --> 00:22:43,390
Indien een recht op een knooppunt werd uitgegeven
ergens anders in het cluster

528
00:22:43,390 --> 00:22:46,650
en het is niet gerepliceerd over de
cluster nog toen ik las dat de gegevens,

529
00:22:46,650 --> 00:22:48,680
die staat misschien niet consistent.

530
00:22:48,680 --> 00:22:51,650
Toch zal het
uiteindelijk consistente,

531
00:22:51,650 --> 00:22:53,870
betekent dat wanneer een schrijf
wordt aan het systeem,

532
00:22:53,870 --> 00:22:56,480
het zal repliceren over de knooppunten.

533
00:22:56,480 --> 00:22:59,095
En uiteindelijk, die staat
in orde zal worden gebracht,

534
00:22:59,095 --> 00:23:00,890
en zal een consistente toestand.

535
00:23:00,890 --> 00:23:05,000
>> Nu, CAP stelling echt
speelt slechts in één voorwaarde.

536
00:23:05,000 --> 00:23:08,700
Deze voorwaarde is wanneer dit gebeurt.

537
00:23:08,700 --> 00:23:13,710
Want als het is actief in
de normale modus, er is geen partitie,

538
00:23:13,710 --> 00:23:16,370
alles is consequent en beschikbaar.

539
00:23:16,370 --> 00:23:19,990
Je je zorgen alleen over het GLB
als we die partitie.

540
00:23:19,990 --> 00:23:21,260
Dus die zijn zeldzaam.

541
00:23:21,260 --> 00:23:25,360
Maar hoe het systeem reageert wanneer die
optreden dicteren wat voor soort systeem

542
00:23:25,360 --> 00:23:26,750
we te maken hebben met.

543
00:23:26,750 --> 00:23:31,110
>> Dus laten we eens kijken naar wat
dat lijkt voor AP-systemen.

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

545
00:23:32,621 --> 00:23:34,830
AP systemen komen in twee smaken.

546
00:23:34,830 --> 00:23:38,514
Ze komen in de smaak, dat is een
Meester, 100%, altijd beschikbaar.

547
00:23:38,514 --> 00:23:40,430
En ze komen in de
andere smaak, die zegt:

548
00:23:40,430 --> 00:23:43,330
weet je wat, ik ga zorgen te maken
over dit partitioneren ding

549
00:23:43,330 --> 00:23:44,724
wanneer een feitelijke verdeling optreedt.

550
00:23:44,724 --> 00:23:47,890
Anders, er zal primair worden
knooppunten wie gaat om de rechten te nemen.

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

552
00:23:48,500 --> 00:23:50,040
>> Dus als we iets als Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra zou een meester te zijn
meester, laat het me te schrijven aan een knooppunt.

554
00:23:54,440 --> 00:23:55,540
Dus wat gebeurt er?

555
00:23:55,540 --> 00:23:58,270
Dus ik heb een object in de
database die bestaat op twee knooppunten.

556
00:23:58,270 --> 00:24:01,705
Laten we noemen dat object S.
Dus we hebben staat voor S.

557
00:24:01,705 --> 00:24:04,312
We hebben een aantal activiteiten
op S die zijn gaande.

558
00:24:04,312 --> 00:24:06,270
Cassandra kan ik
schrijven op meerdere knooppunten.

559
00:24:06,270 --> 00:24:08,550
Dus laten we zeggen dat ik een
te schrijven voor en twee knooppunten.

560
00:24:08,550 --> 00:24:12,274
Nou, wat uiteindelijk gebeurt is
wij noemen dat een opdeling evenement.

561
00:24:12,274 --> 00:24:14,190
Er kan niet worden een
fysieke netwerk partitie.

562
00:24:14,190 --> 00:24:15,950
Maar vanwege het ontwerp
van het systeem, is het

563
00:24:15,950 --> 00:24:18,449
eigenlijk partitioneren zodra
als ik een schrijven op twee knooppunten.

564
00:24:18,449 --> 00:24:20,830
Het is me niet dwingen
schrijf alles via één knooppunt.

565
00:24:20,830 --> 00:24:22,340
Ik schrijf over twee knooppunten.

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

567
00:24:23,330 --> 00:24:25,740
>> Dus nu heb ik twee staten.

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

569
00:24:26,360 --> 00:24:28,110
Wat gaat er gebeuren
is vroeg of laat,

570
00:24:28,110 --> 00:24:29,960
er zal een replicatie evenement.

571
00:24:29,960 --> 00:24:33,300
Er gaat worden wat we
riep een partitie herstel, die

572
00:24:33,300 --> 00:24:35,200
is waar deze twee
staten bij elkaar komen terug

573
00:24:35,200 --> 00:24:37,310
en er zal een algoritme
die draait binnen de database

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

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

576
00:24:39,110 --> 00:24:43,057
Standaard laatste aanpassing
wint meeste AP systemen.

577
00:24:43,057 --> 00:24:44,890
Dus er is meestal een
standaard algoritme, wat

578
00:24:44,890 --> 00:24:47,400
ze noemen een callback
functie, iets wat

579
00:24:47,400 --> 00:24:51,000
zal worden genoemd wanneer deze aandoening
wordt gedetecteerd wat logica uit te voeren

580
00:24:51,000 --> 00:24:52,900
om dat conflict op te lossen.

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

582
00:24:53,850 --> 00:24:58,770
De standaard callback en standaard
resolver meeste AP databases

583
00:24:58,770 --> 00:25:01,130
is, wat denk je, timestamp wint.

584
00:25:01,130 --> 00:25:02,380
Dit was de laatste update.

585
00:25:02,380 --> 00:25:04,320
Ik ga die update daar zetten.

586
00:25:04,320 --> 00:25:08,440
Ik kan dit record dumpen dat ik
gedumpt af in een recovery log

587
00:25:08,440 --> 00:25:11,670
zodat de gebruiker later terug kan komen
en zeggen: hey, was er een botsing.

588
00:25:11,670 --> 00:25:12,320
Wat er is gebeurd?

589
00:25:12,320 --> 00:25:16,370
En je kunt eigenlijk dumpen een record van
alle botsingen en rollbacks

590
00:25:16,370 --> 00:25:17,550
en zie wat er gebeurt.

591
00:25:17,550 --> 00:25:21,580
>> Nu, als een gebruiker, kunt u ook
omvatten logica in die callback.

592
00:25:21,580 --> 00:25:24,290
Dus je kan dat veranderen
callback operatie.

593
00:25:24,290 --> 00:25:26,730
Je kunt zeggen, hey, ik wil
om deze gegevens te saneren.

594
00:25:26,730 --> 00:25:28,880
En ik wil proberen en
samenvoegen van deze twee records.

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

596
00:25:30,050 --> 00:25:32,880
De database weet niet hoe
dat doen door standaard. De meeste van de tijd,

597
00:25:32,880 --> 00:25:34,850
de enige database
weet hoe dat te doen is te zeggen,

598
00:25:34,850 --> 00:25:36,100
Dit was de laatste record.

599
00:25:36,100 --> 00:25:39,183
Dat is degene die gaat winnen,
en dat is de waarde Ik ga zetten.

600
00:25:39,183 --> 00:25:41,490
Zodra dat partitie herstel
en replicatie optreedt,

601
00:25:41,490 --> 00:25:43,930
we hebben onze staat, die
is nu S eerste, dat is

602
00:25:43,930 --> 00:25:46,890
het samenvoegen toestand van al die objecten.

603
00:25:46,890 --> 00:25:49,700
Dus AP systemen hebben dit.

604
00:25:49,700 --> 00:25:51,615
CP-systemen niet nodig
zorgen te maken over dit.

605
00:25:51,615 --> 00:25:54,490
Want zodra een partitie komt
in het spel, maar ze stoppen met het innemen

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

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

608
00:25:56,180 --> 00:25:58,670
Dus dat is heel gemakkelijk te
behandelen consequent

609
00:25:58,670 --> 00:26:01,330
wanneer u geen updates te accepteren.

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

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

612
00:26:05,120 --> 00:26:07,590
>> Dus laten we een beetje praten
beetje over toegang patronen.

613
00:26:07,590 --> 00:26:11,580
Als we praten over NoSQL, het is
alles over de toegang patroon.

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

615
00:26:13,550 --> 00:26:14,481
Het is relationele winkel.

616
00:26:14,481 --> 00:26:16,480
We hebben geen zorgen te maken
over de toegang patroon.

617
00:26:16,480 --> 00:26:17,688
Ik schrijf een zeer complexe vraag.

618
00:26:17,688 --> 00:26:19,250
Het gaat en de gegevens krijgt.

619
00:26:19,250 --> 00:26:21,210
Dat is wat het lijkt
zoals, normalisatie.

620
00:26:21,210 --> 00:26:24,890
>> Dus in dit bijzondere structuur,
we kijken naar een producten catalogus.

621
00:26:24,890 --> 00:26:26,640
Ik heb verschillende soorten producten.

622
00:26:26,640 --> 00:26:27,217
Ik heb boeken.

623
00:26:27,217 --> 00:26:27,800
Ik heb albums.

624
00:26:27,800 --> 00:26:30,090
Ik heb video's.

625
00:26:30,090 --> 00:26:33,370
De relatie tussen producten
en elk van deze boeken, albums,

626
00:26:33,370 --> 00:26:34,860
en video tabellen 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Ik heb een product-ID,
en dat ID overeenkomt

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

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

631
00:26:41,580 --> 00:26:44,350
Dat is een 1: 1 relatie
over die tabellen.

632
00:26:44,350 --> 00:26:46,970
>> Nu, alles wat ze books--
hebben root eigenschappen.

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

634
00:26:47,550 --> 00:26:48,230
Dat is fantastisch.

635
00:26:48,230 --> 00:26:52,130
Eén-op-één relatie, krijg ik alle
de gegevens die ik nodig heb om dat boek te beschrijven.

636
00:26:52,130 --> 00:26:54,770
Albums-- albums hebben tracks.

637
00:26:54,770 --> 00:26:56,470
Dit is wat we een te veel bellen.

638
00:26:56,470 --> 00:26:58,905
Elk album zou kunnen hebben veel tracks.

639
00:26:58,905 --> 00:27:00,780
Dus voor elke track op
het album, kon ik heb

640
00:27:00,780 --> 00:27:02,570
een record in dit kind tabel.

641
00:27:02,570 --> 00:27:04,680
Dus ik maak één record
in mijn albums tafel.

642
00:27:04,680 --> 00:27:06,700
Ik meerdere records
in de tabel tracks.

643
00:27:06,700 --> 00:27:08,850
Een-op-veel-relatie.

644
00:27:08,850 --> 00:27:11,220
>> Deze relatie is waar
noemen we many-to-many.

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

646
00:27:11,750 --> 00:27:17,000
Je ziet dat de acteurs zou kunnen zijn
in vele films, veel video's.

647
00:27:17,000 --> 00:27:21,450
Dus wat we doen is zetten we deze mapping
tussen die, waardoor het net

648
00:27:21,450 --> 00:27:24,040
brengt de acteur ID om de video-ID.

649
00:27:24,040 --> 00:27:28,464
Nu kan ik een query de naden te creëren
video's via acteur video naar acteurs,

650
00:27:28,464 --> 00:27:31,130
en het geeft me een mooie lijst
alle films en alle actoren

651
00:27:31,130 --> 00:27:32,420
die in die film waren.

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

653
00:27:33,290 --> 00:27:33,880
Dus hier gaan we.

654
00:27:33,880 --> 00:27:38,040
Eén-op-één is de top-level
relatie; één-op-veel,

655
00:27:38,040 --> 00:27:40,240
albums te sporen; many-to-many.

656
00:27:40,240 --> 00:27:44,990
Dat zijn de drie top-level
relaties in een database.

657
00:27:44,990 --> 00:27:48,050
Als je weet hoe die
relaties werken samen,

658
00:27:48,050 --> 00:27:51,490
dan weet je een heleboel
over de database al.

659
00:27:51,490 --> 00:27:55,660
Dus NoSQL werkt een beetje anders.

660
00:27:55,660 --> 00:27:58,930
Laten we nadenken over voor een tweede wat het
looks willen gaan krijgen al mijn producten.

661
00:27:58,930 --> 00:28:01,096
>> In een relationele winkel I
wil al mijn producten te krijgen

662
00:28:01,096 --> 00:28:02,970
op een lijst van al mijn producten.

663
00:28:02,970 --> 00:28:04,910
Dat is een hoop vragen.

664
00:28:04,910 --> 00:28:07,030
Ik heb een vraag voor al mijn boeken.

665
00:28:07,030 --> 00:28:08,470
Ik heb een vraag van mijn albums.

666
00:28:08,470 --> 00:28:09,970
En ik heb een vraag voor al mijn video's.

667
00:28:09,970 --> 00:28:11,719
En ik heb om het te zetten
allemaal samen in een lijst

668
00:28:11,719 --> 00:28:15,250
en serveer het terug naar de
applicatie dat is het verzoek.

669
00:28:15,250 --> 00:28:18,000
>> Om mijn boeken te krijgen, ik meedoen
Producten en boeken.

670
00:28:18,000 --> 00:28:21,680
Mijn albums krijgen, kreeg ik om toe te treden
Producten, Albums en Tracks.

671
00:28:21,680 --> 00:28:25,330
En tot mijn video's te krijgen, heb ik
om producten aan te sluiten voor video,

672
00:28:25,330 --> 00:28:28,890
toetreden tot Actor's,
en brengen de acteurs.

673
00:28:28,890 --> 00:28:31,020
Dus dat is drie queries.

674
00:28:31,020 --> 00:28:34,560
Zeer complexe queries op
assembleren een resultaat set.

675
00:28:34,560 --> 00:28:36,540
>> Dat is niet optimaal.

676
00:28:36,540 --> 00:28:39,200
Dit is waarom wanneer we praten
over een gegevensstructuur die

677
00:28:39,200 --> 00:28:42,900
gebouwd agnostische om toegang te
pattern-- goed, dat is geweldig.

678
00:28:42,900 --> 00:28:45,730
En je kunt zien dit is echt
mooi hoe we de gegevens hebben georganiseerd.

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

680
00:28:46,550 --> 00:28:49,750
Ik heb maar één record voor een acteur.

681
00:28:49,750 --> 00:28:50,440
>> Dat is cool.

682
00:28:50,440 --> 00:28:53,750
Ik heb al mijn acteurs gededupliceerd,
en ik onderhouden mijn verenigingen

683
00:28:53,750 --> 00:28:55,200
in dit toewijzingstabel.

684
00:28:55,200 --> 00:29:00,620
Echter, om de gegevens
out wordt duurder.

685
00:29:00,620 --> 00:29:04,500
Ik ben het verzenden van de CPU over het hele systeem
toetreding tot deze gegevens structuren samen

686
00:29:04,500 --> 00:29:05,950
kunnen de gegevens terug te trekken.

687
00:29:05,950 --> 00:29:07,310
>> Dus hoe krijg ik rond dat?

688
00:29:07,310 --> 00:29:11,200
In NoSQL het gaat over
aggregatie, niet normalisering.

689
00:29:11,200 --> 00:29:13,534
Dus we willen zeggen dat we willen
ondersteuning van de toegang patroon.

690
00:29:13,534 --> 00:29:15,283
Als de toegang patroon
de toepassingen,

691
00:29:15,283 --> 00:29:16,770
Ik moet al mijn producten te krijgen.

692
00:29:16,770 --> 00:29:19,027
Laten we alle producten in één tabel.

693
00:29:19,027 --> 00:29:22,110
Als ik alle producten in een tabel,
Ik kan gewoon selecteren alle producten

694
00:29:22,110 --> 00:29:23,850
van die tafel en ik krijg het allemaal.

695
00:29:23,850 --> 00:29:25,240
Goed hoe doe ik dat?

696
00:29:25,240 --> 00:29:28,124
Welnu, in NoSQL er geen
structuur tafel.

697
00:29:28,124 --> 00:29:30,540
We zullen een klein beetje over praten
hoe dit werkt in Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Maar je hoeft niet dezelfde zijn
eigenschappen en dezelfde eigenschappen

699
00:29:33,570 --> 00:29:37,751
in elke rij, in elk
voorwerp, zoals je in een SQL-tabel.

700
00:29:37,751 --> 00:29:39,750
En wat dit kan ik
te doen is een heleboel dingen

701
00:29:39,750 --> 00:29:41,124
en geef me een veel flexibiliteit.

702
00:29:41,124 --> 00:29:45,360
In dit specifieke geval, I
heb mijn product documenten.

703
00:29:45,360 --> 00:29:49,090
En in dit
Bijvoorbeeld, alles

704
00:29:49,090 --> 00:29:51,930
een document in de tabel producten.

705
00:29:51,930 --> 00:29:56,510
En het product voor een boek zou kunnen
hebben een soort ID die een boek aangeeft.

706
00:29:56,510 --> 00:29:59,180
En de toepassing
zou overstappen op dat ID.

707
00:29:59,180 --> 00:30:02,570
>> Bij de toepassing tier, ga ik
te zeggen oh, wat opname type is dit?

708
00:30:02,570 --> 00:30:04,100
Oh, het is een boek record.

709
00:30:04,100 --> 00:30:05,990
Boek records deze eigenschappen.

710
00:30:05,990 --> 00:30:08,100
Laat me een boek-object te maken.

711
00:30:08,100 --> 00:30:11,289
Dus ik ga naar het vullen
boek object met dit punt.

712
00:30:11,289 --> 00:30:13,080
Volgend item komt en
zegt, wat is dit artikel?

713
00:30:13,080 --> 00:30:14,560
Vormt van dit artikel is een album.

714
00:30:14,560 --> 00:30:17,340
Oh, ik heb een heel ander
verwerkingsroutine daarvoor,

715
00:30:17,340 --> 00:30:18,487
want het is een album.

716
00:30:18,487 --> 00:30:19,320
Zie je wat ik bedoel?

717
00:30:19,320 --> 00:30:21,950
>> Zodat de toepassing tier-- I
Selecteer gewoon al deze records.

718
00:30:21,950 --> 00:30:23,200
Ze beginnen allemaal komen.

719
00:30:23,200 --> 00:30:24,680
Ze kunnen alle verschillende soorten.

720
00:30:24,680 --> 00:30:27,590
En het is de logica van de toepassing
dat schakelt over die soorten

721
00:30:27,590 --> 00:30:29,530
en besluit hoe ze te verwerken.

722
00:30:29,530 --> 00:30:33,640
>> Weer, dus we het optimaliseren van de
schema voor de toegang patroon.

723
00:30:33,640 --> 00:30:36,390
We doen het door
instortende die tabellen.

724
00:30:36,390 --> 00:30:39,670
We zijn in principe nemen
Deze genormaliseerde structuren

725
00:30:39,670 --> 00:30:42,000
en we bouwen
hiërarchische structuren.

726
00:30:42,000 --> 00:30:45,130
Binnen elk van deze records
Ik ga reeks eigenschappen te zien.

727
00:30:45,130 --> 00:30:49,400
>> Binnen dit document voor Albums,
Ik zie arrays van tracks.

728
00:30:49,400 --> 00:30:53,900
Die tracks nu become-- het is
In principe is dit kind tafel

729
00:30:53,900 --> 00:30:56,520
Er bestaat hier in deze structuur.

730
00:30:56,520 --> 00:30:57,975
Dus u kunt dit doen in DynamoDB.

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

732
00:30:59,810 --> 00:31:01,437
U kunt dit doen in een NoSQL-database.

733
00:31:01,437 --> 00:31:03,520
Maak deze soorten
hiërarchische datastructuren

734
00:31:03,520 --> 00:31:07,120
dat u gegevens mogelijk te maken op te halen
zeer snel omdat ik nu

735
00:31:07,120 --> 00:31:08,537
niet hoeven te voldoen.

736
00:31:08,537 --> 00:31:11,620
Wanneer ik een rij in de Tracks
tafel, of een rij in de tabel Albums,

737
00:31:11,620 --> 00:31:13,110
Ik heb om te voldoen aan dat schema.

738
00:31:13,110 --> 00:31:18,060
Ik moet het attribuut of het hebben
eigenschap die is gedefinieerd op die tafel.

739
00:31:18,060 --> 00:31:20,480
Ieder van hen,
toen ik steek die rij.

740
00:31:20,480 --> 00:31:21,910
Dat is niet het geval in NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Ik kan totaal verschillend zijn
woningen in elk document

742
00:31:24,440 --> 00:31:26,100
dat ik invoegen in de collectie.

743
00:31:26,100 --> 00:31:30,480
Dus zeer krachtig mechanisme.

744
00:31:30,480 --> 00:31:32,852
En het is echt hoe je
optimaliseren van het systeem.

745
00:31:32,852 --> 00:31:35,310
Want nu die vraag, in plaats
van toetreding al deze tabellen

746
00:31:35,310 --> 00:31:39,160
en uitvoeren van een half dozijn queries
terug te trekken van de gegevens die ik nodig,

747
00:31:39,160 --> 00:31:40,890
Ik ben het uitvoeren van een zoekopdracht.

748
00:31:40,890 --> 00:31:43,010
En ik ben itereren
over de resultatenset.

749
00:31:43,010 --> 00:31:46,512
het geeft je een idee
van de kracht van NoSQL.

750
00:31:46,512 --> 00:31:49,470
Ik ga soort zijwaarts gaan hier
en een beetje praten over dit.

751
00:31:49,470 --> 00:31:53,240
Dit is de soort
marketing of technology--

752
00:31:53,240 --> 00:31:55,660
op de markt brengen van de technologie
soort discussie.

753
00:31:55,660 --> 00:31:58,672
Maar het is belangrijk om te begrijpen
want als we kijken naar de top

754
00:31:58,672 --> 00:32:00,380
hier bij deze grafiek,
wat we op zoek naar

755
00:32:00,380 --> 00:32:04,030
is wat wij noemen de
technologie hype curve.

756
00:32:04,030 --> 00:32:06,121
En wat dit betekent is
nieuwe dingen in het spel komt.

757
00:32:06,121 --> 00:32:07,120
Mensen denken dat het geweldig.

758
00:32:07,120 --> 00:32:09,200
Ik heb al mijn problemen opgelost.

759
00:32:09,200 --> 00:32:11,630
>> Dit kan het einde
alle, zijn allemaal van alles.

760
00:32:11,630 --> 00:32:12,790
En ze gaan gebruiken.

761
00:32:12,790 --> 00:32:14,720
En zij zeggen, dit spul werkt niet.

762
00:32:14,720 --> 00:32:17,600
Dit is niet goed.

763
00:32:17,600 --> 00:32:19,105
De oude spul was beter.

764
00:32:19,105 --> 00:32:21,230
En ze gaan terug naar het doen
dingen zoals ze waren.

765
00:32:21,230 --> 00:32:22,730
En dan uiteindelijk
ze gaan, weet je wat?

766
00:32:22,730 --> 00:32:24,040
Dit spul is niet zo slecht.

767
00:32:24,040 --> 00:32:26,192
Oh, dat is hoe het werkt.

768
00:32:26,192 --> 00:32:28,900
En zodra ze erachter te komen hoe het
werken, beginnen ze steeds beter.

769
00:32:28,900 --> 00:32:32,050
>> En het grappige ding over het
is het soort leidingen tot wat

770
00:32:32,050 --> 00:32:34,300
wij noemen het Technology Adoption Curve.

771
00:32:34,300 --> 00:32:36,910
Dus wat er gebeurt is dat we hebben
een soort technologie trekker.

772
00:32:36,910 --> 00:32:39,100
Bij databases,
het data druk.

773
00:32:39,100 --> 00:32:42,200
We spraken over het hoge water punten
van data druk door de tijd heen.

774
00:32:42,200 --> 00:32:46,310
Wanneer die gegevens druk raakt een bepaald
punt, dat is een technologie trekker.

775
00:32:46,310 --> 00:32:47,830
>> Het wordt te duur.

776
00:32:47,830 --> 00:32:49,790
Het duurt te lang om de gegevens te verwerken.

777
00:32:49,790 --> 00:32:50,890
We moeten iets beters.

778
00:32:50,890 --> 00:32:52,890
Je krijgt de vernieuwers
die er rond te rennen,

779
00:32:52,890 --> 00:32:55,050
proberen uit te vinden wat is de oplossing.

780
00:32:55,050 --> 00:32:56,050
Wat is het nieuwe idee?

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

782
00:32:58,170 --> 00:32:59,530
En ze komen met iets.

783
00:32:59,530 --> 00:33:03,140
En de mensen met de echte pijn,
de jongens op de bleeding edge,

784
00:33:03,140 --> 00:33:06,390
ze allemaal te springen over,
omdat ze moeten een antwoord.

785
00:33:06,390 --> 00:33:09,690
Nu, wat onvermijdelijk happens-- en
is er nu gebeurt in NoSQL.

786
00:33:09,690 --> 00:33:11,090
Ik zie het de hele tijd.

787
00:33:11,090 --> 00:33:13,610
>> Wat onvermijdelijk gebeurt is
mensen beginnen met behulp van de nieuwe tool

788
00:33:13,610 --> 00:33:15,490
Op dezelfde manier gebruikten ze de oude tool.

789
00:33:15,490 --> 00:33:17,854
En ze ontdekken dat het
niet zo goed.

790
00:33:17,854 --> 00:33:20,020
Ik weet niet meer wie ik was
praat eerder vandaag.

791
00:33:20,020 --> 00:33:22,080
Maar het is net als de
drilboor werd uitgevonden,

792
00:33:22,080 --> 00:33:24,621
mensen niet swing het over
hun hoofd naar de betonnen smash.

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

794
00:33:27,360 --> 00:33:30,610
>> Maar dat is wat
gebeurt met NoSQL vandaag.

795
00:33:30,610 --> 00:33:33,900
Als je loopt in de meeste winkels,
ze proberen te zijn NoSQL winkels.

796
00:33:33,900 --> 00:33:36,510
Wat ze doen is
ze gebruiken NoSQL,

797
00:33:36,510 --> 00:33:39,900
en ze zijn het laden
vol relationele schema.

798
00:33:39,900 --> 00:33:41,630
Want dat is hoe
zij ontwerpen databases.

799
00:33:41,630 --> 00:33:44,046
En ze vraagt ​​je af, waarom is
het niet uitvoeren van zeer goed?

800
00:33:44,046 --> 00:33:45,230
Jongen, dit ding stinkt.

801
00:33:45,230 --> 00:33:49,900
Ik moest al mijn behouden
toetreedt in-- het is als, nee, nee.

802
00:33:49,900 --> 00:33:50,800
Onderhouden toetreedt?

803
00:33:50,800 --> 00:33:52,430
Waarom doe je mee data?

804
00:33:52,430 --> 00:33:54,350
Je hoeft geen gegevens mee NoSQL.

805
00:33:54,350 --> 00:33:55,850
U aggregeren het.

806
00:33:55,850 --> 00:34:00,690
>> Dus als je wilt om dit te voorkomen, te leren
hoe de tool werkt voordat je daadwerkelijk

807
00:34:00,690 --> 00:34:02,010
gaan gebruiken.

808
00:34:02,010 --> 00:34:04,860
Probeer niet en gebruik maken van de nieuwe instrumenten van de
dezelfde manier gebruikt de oude gereedschappen.

809
00:34:04,860 --> 00:34:06,500
Je gaat naar een slechte ervaring hebben.

810
00:34:06,500 --> 00:34:08,848
En elke keer
dat is waar het om gaat.

811
00:34:08,848 --> 00:34:11,389
Wanneer we beginnen komen hier,
het is omdat de mensen bedacht

812
00:34:11,389 --> 00:34:13,449
hoe u de tools te gebruiken.

813
00:34:13,449 --> 00:34:16,250
>> Ze deed hetzelfde bij
relationele databases werden uitgevonden,

814
00:34:16,250 --> 00:34:17,969
en zij werden vervangen bestandssystemen.

815
00:34:17,969 --> 00:34:20,420
Ze probeerden file systemen te bouwen
met relationele databases

816
00:34:20,420 --> 00:34:22,159
want dat is wat de mensen begrepen.

817
00:34:22,159 --> 00:34:23,049
Het werkte niet.

818
00:34:23,049 --> 00:34:26,090
Dus het begrijpen van de 'best practices'
van de technologie die u werkt met

819
00:34:26,090 --> 00:34:26,730
is enorm.

820
00:34:26,730 --> 00:34:29,870
Erg belangrijk.

821
00:34:29,870 --> 00:34:32,440
>> Dus we gaan krijgen in DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB is AWS
volledig beheerde NoSQL platform.

823
00:34:36,480 --> 00:34:37,719
Wat betekent volledig beheerde betekenen?

824
00:34:37,719 --> 00:34:40,010
Het betekent dat je niet hoeft te
echt zorgen te maken over iets.

825
00:34:40,010 --> 00:34:42,060
>> Kom je in, je vertellen
ons, ik heb een tafel.

826
00:34:42,060 --> 00:34:43,409
Het moet dit veel capaciteit.

827
00:34:43,409 --> 00:34:47,300
U druk op de knop, en wij verstrekken
alle infrastructuur achter de schermen.

828
00:34:47,300 --> 00:34:48,310
Nu dat is enorm.

829
00:34:48,310 --> 00:34:51,310
>> Want als je praat
schaalvergroting een databank

830
00:34:51,310 --> 00:34:53,917
NoSQL data clusters op
schaal, lopen petabytes,

831
00:34:53,917 --> 00:34:55,750
loopt miljoenen
transacties per seconde,

832
00:34:55,750 --> 00:34:58,180
deze dingen zijn geen kleine clusters.

833
00:34:58,180 --> 00:35:00,830
We praten duizenden gevallen.

834
00:35:00,830 --> 00:35:04,480
Het beheren van duizenden gevallen
zelfs virtuele instances,

835
00:35:04,480 --> 00:35:06,350
is een echte pijn in de kont.

836
00:35:06,350 --> 00:35:09,110
Ik bedoel, denk elke keer een
besturingssysteem patch uitkomt

837
00:35:09,110 --> 00:35:11,552
of een nieuwe versie van de database.

838
00:35:11,552 --> 00:35:13,260
Wat betekent dat
om u operationeel?

839
00:35:13,260 --> 00:35:16,330
Dat betekent dat je hebt 1200
servers die moeten worden bijgewerkt.

840
00:35:16,330 --> 00:35:18,960
Nu zelfs met automatisering,
dat kan een lange tijd in beslag nemen.

841
00:35:18,960 --> 00:35:21,480
Dat kan veel veroorzaken
operationele hoofdpijn,

842
00:35:21,480 --> 00:35:23,090
omdat ik misschien diensten naar beneden.

843
00:35:23,090 --> 00:35:26,070
>> Zoals ik updaten deze databases, I
misschien blauwgroene implementaties doen

844
00:35:26,070 --> 00:35:29,420
waar ik implementeren en upgraden de helft van mijn
knooppunten, en vervolgens een upgrade van de andere helft.

845
00:35:29,420 --> 00:35:30,490
Neem die naar beneden.

846
00:35:30,490 --> 00:35:33,410
Zodat het beheer van de infrastructuur
schaal is enorm pijnlijk.

847
00:35:33,410 --> 00:35:36,210
En AWS nemen die pijn uit.

848
00:35:36,210 --> 00:35:39,210
En NoSQL-databases kan
zijn buitengewoon pijnlijk

849
00:35:39,210 --> 00:35:41,780
vanwege de manier waarop ze schaal.

850
00:35:41,780 --> 00:35:42,926
>> Schalen horizontaal.

851
00:35:42,926 --> 00:35:45,550
Als u wilt een grotere NoSQL krijgen
databank, je koopt meer knooppunten.

852
00:35:45,550 --> 00:35:48,660
Elk knooppunt u koopt is
andere operationele hoofdpijn.

853
00:35:48,660 --> 00:35:50,830
Dus laat iemand anders dat voor je doen.

854
00:35:50,830 --> 00:35:52,000
AWS kan dat doen.

855
00:35:52,000 --> 00:35:54,587
>> Wij ondersteunen document kernwaarden.

856
00:35:54,587 --> 00:35:56,670
Nu hebben we niet te veel gaan
in op de andere kaart.

857
00:35:56,670 --> 00:35:58,750
Er is een heleboel verschillende
smaken van NoSQL.

858
00:35:58,750 --> 00:36:02,670
Ze zijn allemaal soort van krijgen
samen onder handen genomen op dit punt.

859
00:36:02,670 --> 00:36:06,260
U kunt kijken naar DynamoDB en zeggen: ja,
we allebei een document en een belangrijke waarde

860
00:36:06,260 --> 00:36:08,412
bewaar dit punt.

861
00:36:08,412 --> 00:36:10,620
En u kunt de functies argumenteren
van een over de ander.

862
00:36:10,620 --> 00:36:13,950
Voor mij, veel van dit is echt zes
van een half dozijn andere.

863
00:36:13,950 --> 00:36:18,710
Elk van deze technologieën is een
fijne techniek en een prima oplossing.

864
00:36:18,710 --> 00:36:23,390
Ik zou niet zeggen MongoDB beter of
erger dan Couch, dan Cassandra,

865
00:36:23,390 --> 00:36:25,994
dan Dynamo, of vice versa.

866
00:36:25,994 --> 00:36:27,285
Ik bedoel, dit zijn slechts opties.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Het is snel en het is
consistente op elke schaal.

869
00:36:32,700 --> 00:36:36,210
Dus dit is een van de grootste
bonussen je krijgt met AWS.

870
00:36:36,210 --> 00:36:40,850
Met DynamoDB is het vermogen
een low single digit krijgen

871
00:36:40,850 --> 00:36:44,040
milliseconde latentie op elke schaal.

872
00:36:44,040 --> 00:36:45,720
Dat was een ontwerp doel van het systeem.

873
00:36:45,720 --> 00:36:49,130
En we hebben klanten die aan het doen zijn
miljoenen transacties per seconde.

874
00:36:49,130 --> 00:36:52,670
>> Nu zal ik gaan door middel van een aantal van deze
use cases in een paar minuten hier.

875
00:36:52,670 --> 00:36:55,660
Geïntegreerde toegang control--
we hebben wat we noemen

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, of IAM.

877
00:36:57,920 --> 00:37:01,980
Het doordringt elk systeem,
elke dienst die AWS biedt.

878
00:37:01,980 --> 00:37:03,630
DynamoDB is geen uitzondering.

879
00:37:03,630 --> 00:37:06,020
U kunt toegang te controleren
de DynamoDB tabellen.

880
00:37:06,020 --> 00:37:09,960
Voor al uw AWS-accounts door
definiëren van toegang en machtigingen

881
00:37:09,960 --> 00:37:12,140
in de IAM infrastructuur.

882
00:37:12,140 --> 00:37:16,630
>> En het is een belangrijk en integraal onderdeel van
wat wij noemen Event Driven Programming.

883
00:37:16,630 --> 00:37:19,056
Nu is dit een nieuw paradigma.

884
00:37:19,056 --> 00:37:22,080
>> Publiek: Hoe is uw snelheid van de ware
positieven versus valse negatieven

885
00:37:22,080 --> 00:37:24,052
op uw toegangscontrole systeem?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: True positieven
versus valse negatieven?

887
00:37:26,260 --> 00:37:28,785
PUBLIEK: Terugkerende wat
je moet terug worden?

888
00:37:28,785 --> 00:37:33,720
In tegenstelling tot een keer in een tijdje
niet terug te keren wanneer het moet valideren?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: Ik kan je niet vertellen dat.

891
00:37:38,050 --> 00:37:40,140
Als er geen storingen
ook op dat,

892
00:37:40,140 --> 00:37:42,726
Ik ben niet de persoon te vragen
die specifieke vraag.

893
00:37:42,726 --> 00:37:43,850
Maar dat is een goede vraag.

894
00:37:43,850 --> 00:37:45,905
Ik zou nieuwsgierig zijn om te weten
dat zelf, eigenlijk.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> En dus nogmaals, nieuw paradigma
is event-driven programmeren.

897
00:37:51,320 --> 00:37:55,160
Dit is het idee dat je kunt
implementeren van complexe applicaties die

898
00:37:55,160 --> 00:37:59,720
kan een zeer, zeer grote schaal opereren
zonder enige infrastructuur dan ook.

899
00:37:59,720 --> 00:38:02,120
Zonder vaste
infrastructuur dan ook.

900
00:38:02,120 --> 00:38:04,720
En we zullen een beetje praten
over wat dat betekent als we

901
00:38:04,720 --> 00:38:06,550
krijgen op de komende paar grafieken.

902
00:38:06,550 --> 00:38:08,716
>> Het eerste wat we doen
is dat we praten over tafels.

903
00:38:08,716 --> 00:38:10,857
Typen API-gegevens voor Dynamo.

904
00:38:10,857 --> 00:38:13,190
En het eerste wat je zult
opvalt als je kijkt naar dit,

905
00:38:13,190 --> 00:38:17,930
als je bekend bent met een database,
databases hebben eigenlijk twee soorten API's

906
00:38:17,930 --> 00:38:18,430
Ik zou het noemen.

907
00:38:18,430 --> 00:38:21,570
Of twee van API.

908
00:38:21,570 --> 00:38:23,840
Een van die zou
administratieve API.

909
00:38:23,840 --> 00:38:26,710
>> De dingen die ze verzorgen
de functies van de database.

910
00:38:26,710 --> 00:38:31,340
De opslag motor configureren,
opzetten en het toevoegen van tabellen.

911
00:38:31,340 --> 00:38:35,180
het creëren van de database
catalogi en gevallen.

912
00:38:35,180 --> 00:38:40,450
Deze things-- in DynamoDB, u
hebben zeer korte, korte lijsten.

913
00:38:40,450 --> 00:38:43,120
>> Dus met andere databases,
je zou tientallen zien

914
00:38:43,120 --> 00:38:45,680
van commando's, van de administratieve
commando's voor het configureren

915
00:38:45,680 --> 00:38:47,290
deze extra opties.

916
00:38:47,290 --> 00:38:51,234
In DynamoDB je niet nodig, omdat die
u niet het systeem te configureren, we doen.

917
00:38:51,234 --> 00:38:54,150
Dus het enige wat je hoeft te doen is
vertel me welke maat tafel heb ik nodig.

918
00:38:54,150 --> 00:38:55,660
Zodat u een zeer krijgen
beperkte set van commando's.

919
00:38:55,660 --> 00:38:58,618
>> Je krijgt een Creëer Table Update, Tafel,
Tabel verwijderen, en Beschrijf tabel.

920
00:38:58,618 --> 00:39:01,150
Dat zijn de enige dingen
je nodig hebt voor DynamoDB.

921
00:39:01,150 --> 00:39:03,294
U hoeft niet een opslag nodig
engine configuratie.

922
00:39:03,294 --> 00:39:04,960
Ik heb geen zorgen te maken over replicatie.

923
00:39:04,960 --> 00:39:06,490
Ik heb geen zorgen te maken over sharding.

924
00:39:06,490 --> 00:39:07,800
>> Ik heb geen zorgen te maken
over een van deze spullen.

925
00:39:07,800 --> 00:39:08,740
We doen het allemaal voor u.

926
00:39:08,740 --> 00:39:11,867
Dus dat is een enorme hoeveelheid overhead
die net is getild je bord.

927
00:39:11,867 --> 00:39:13,200
Dan hebben we de CRUD operators.

928
00:39:13,200 --> 00:39:17,740
CRUD is iets wat we
noemen in de database dat is

929
00:39:17,740 --> 00:39:19,860
Create, Update, Delete operators.

930
00:39:19,860 --> 00:39:24,180
Dit zijn uw gezond
databank operaties.

931
00:39:24,180 --> 00:39:31,299
Dingen zoals put punt, item te krijgen, bijwerken
items, items te verwijderen, batch query, scannen.

932
00:39:31,299 --> 00:39:32,840
Als u de hele tabel te scannen.

933
00:39:32,840 --> 00:39:34,220
Trek alles uit de tabel.

934
00:39:34,220 --> 00:39:37,130
Een van de leuke dingen over DynamoDB
is het mogelijk parallelle scanning.

935
00:39:37,130 --> 00:39:40,602
Dus je kunt eigenlijk laat me weten hoeveel
discussies die u wilt uitvoeren op die scan.

936
00:39:40,602 --> 00:39:41,810
En we kunnen draaien die draden.

937
00:39:41,810 --> 00:39:43,985
We kunnen draaien dat scannen up
over meerdere threads

938
00:39:43,985 --> 00:39:49,060
dus je kunt de hele tabel te scannen
ruimte zeer, zeer snel in DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> De andere API die we hebben is
wat wij noemen ons Streams API.

940
00:39:51,490 --> 00:39:52,940
We gaan niet om te praten
veel over dit recht nu.

941
00:39:52,940 --> 00:39:55,189
Ik heb wat inhoud later kreeg
op het dek over.

942
00:39:55,189 --> 00:39:59,910
Maar Streams is echt een running--
denk aan het als de tijd besteld

943
00:39:59,910 --> 00:40:01,274
en partitie change log.

944
00:40:01,274 --> 00:40:03,940
Alles wat er gebeurt op
de tabel toont op de stream.

945
00:40:03,940 --> 00:40:05,940
>> Elke brief aan de tafel
verschijnt op de stroom.

946
00:40:05,940 --> 00:40:08,370
Je kunt die stroom lezen en
Je kunt dingen doen.

947
00:40:08,370 --> 00:40:10,150
We zullen praten over wat
soorten dingen die je

948
00:40:10,150 --> 00:40:13,680
maken met de dingen zoals replicatie,
het creëren van secundaire indexen.

949
00:40:13,680 --> 00:40:17,620
Alle soorten van echt cool
dingen die je kunt doen met die.

950
00:40:17,620 --> 00:40:19,150
>> Types data.

951
00:40:19,150 --> 00:40:23,320
In DynamoDB, beide belangrijke steunen wij
waarde en het document data types.

952
00:40:23,320 --> 00:40:26,350
Aan de linkerkant van het scherm
hier, we hebben onze basistypen.

953
00:40:26,350 --> 00:40:27,230
Key value types.

954
00:40:27,230 --> 00:40:30,040
Dit zijn snaren,
getallen en binaries.

955
00:40:30,040 --> 00:40:31,640
>> Dus gewoon drie basistypen.

956
00:40:31,640 --> 00:40:33,700
En dan kunt u sets van die te hebben.

957
00:40:33,700 --> 00:40:37,650
Een van de leuke dingen over NoSQL is
U kunt arrays als eigenschappen bevatten.

958
00:40:37,650 --> 00:40:42,050
En met DynamoDB u kunt arrays bevatten
van basistypen als een wortel woning.

959
00:40:42,050 --> 00:40:43,885
>> En dan is er het type document.

960
00:40:43,885 --> 00:40:45,510
Hoeveel mensen zijn bekend met JSON?

961
00:40:45,510 --> 00:40:47,130
Jullie vertrouwd met JSON zo veel?

962
00:40:47,130 --> 00:40:49,380
Het is eigenlijk JavaScript,
Object, Notation.

963
00:40:49,380 --> 00:40:52,510
Hiermee kunt u in principe
definieert een hiërarchische structuur.

964
00:40:52,510 --> 00:40:58,107
>> U kunt een JSON-document op te slaan
DynamoDB het gebruik van gemeenschappelijke componenten

965
00:40:58,107 --> 00:41:00,940
of bouwstenen die beschikbaar zijn
In de meeste programmeertalen.

966
00:41:00,940 --> 00:41:03,602
Dus als je Java, je bent
kijken naar kaarten en lijsten.

967
00:41:03,602 --> 00:41:05,060
Ik kan objecten maken dat gebied kaart.

968
00:41:05,060 --> 00:41:08,030
Een kaart als kernwaarden
opgeslagen als eigenschappen.

969
00:41:08,030 --> 00:41:10,890
En het zou een lijst hebben van
waarden binnen die eigenschappen.

970
00:41:10,890 --> 00:41:13,490
U kunt dit complex te bewaren
hiërarchische structuur

971
00:41:13,490 --> 00:41:16,320
als een enkel attribuut
van een DynamoDB punt.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Zo tafels in DynamoDB, net als de meeste
NoSQL databases, tabellen items.

974
00:41:24,460 --> 00:41:26,469
In MongoDB je zou
noemen deze documenten.

975
00:41:26,469 --> 00:41:27,760
En het zou de bank uitvalsbasis.

976
00:41:27,760 --> 00:41:28,900
Ook een document database.

977
00:41:28,900 --> 00:41:29,941
Je noemt deze documenten.

978
00:41:29,941 --> 00:41:32,930
Documenten of items hebben attributen.

979
00:41:32,930 --> 00:41:35,850
Attributen kunnen bestaan ​​of
bestaan ​​niet op het item.

980
00:41:35,850 --> 00:41:38,520
In DynamoDB, is er
één verplichte attribuut.

981
00:41:38,520 --> 00:41:43,880
Net als in een relationele database,
heb je een primaire sleutel op de tafel.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB heeft wat wij een hekje noemen.

983
00:41:46,010 --> 00:41:48,280
Hash sleutel moet uniek zijn.

984
00:41:48,280 --> 00:41:52,580
Dus toen ik een hash tabel te definiëren,
eigenlijk wat ik zeg

985
00:41:52,580 --> 00:41:54,110
is elke punt zal een hash sleutel.

986
00:41:54,110 --> 00:41:58,520
En elke hash sleutel moet uniek zijn.

987
00:41:58,520 --> 00:42:01,200
>> Elk item wordt gedefinieerd
door die unieke hekje.

988
00:42:01,200 --> 00:42:02,940
En er kan slechts één.

989
00:42:02,940 --> 00:42:05,820
Dit is OK, maar vaak
wat mensen nodig hebben

990
00:42:05,820 --> 00:42:08,170
is dat ze willen is dit hash
toets om een ​​beetje meer te doen

991
00:42:08,170 --> 00:42:11,010
dan alleen een unieke identificatie zijn.

992
00:42:11,010 --> 00:42:15,240
Vaak willen we dat hekje-toets gebruiken
als het hoogste niveau aggregatie emmer.

993
00:42:15,240 --> 00:42:19,160
En de manier waarop we dat doen is door
het toevoegen van wat we een reeks belangrijke noemen.

994
00:42:19,160 --> 00:42:22,460
>> Dus als het is slechts een hash
tabel, moet dit uniek zijn.

995
00:42:22,460 --> 00:42:27,040
Als het een hash en het bereik tafel, de
combinatie van de hash en gamma

996
00:42:27,040 --> 00:42:28,640
moet uniek zijn.

997
00:42:28,640 --> 00:42:30,110
Dus na te denken over het op deze manier.

998
00:42:30,110 --> 00:42:32,140
Als ik een forum.

999
00:42:32,140 --> 00:42:39,010
En het formulier heeft onderwerpen, het heeft
posten, en het heeft reacties.

1000
00:42:39,010 --> 00:42:42,630
>> Dus ik zou een hash
key, die het onderwerp ID.

1001
00:42:42,630 --> 00:42:46,650
En ik zou een reeks sleutel,
die de reactie ID.

1002
00:42:46,650 --> 00:42:49,650
Op die manier als ik wil al het krijgen
antwoorden voor bepaald onderwerp,

1003
00:42:49,650 --> 00:42:52,370
Ik kan query de hash.

1004
00:42:52,370 --> 00:42:55,190
Ik kan alleen maar zeggen geef me alle
punten die deze hash.

1005
00:42:55,190 --> 00:43:01,910
En ik ga elke vraag te krijgen
of post voor dat specifieke onderwerp.

1006
00:43:01,910 --> 00:43:03,910
Deze top level samenvoegingen
zijn zeer belangrijk.

1007
00:43:03,910 --> 00:43:07,370
Zij ondersteunen de primaire toegang
patroon van de applicatie.

1008
00:43:07,370 --> 00:43:09,420
In het algemeen, dit
is wat we willen doen.

1009
00:43:09,420 --> 00:43:11,780
We willen dat table--
als je de tafel te laden,

1010
00:43:11,780 --> 00:43:16,640
we willen de datastructuur
binnen de tafel zodanig

1011
00:43:16,640 --> 00:43:20,140
dat de aanvraag kan zeer
snel die resultaten te halen.

1012
00:43:20,140 --> 00:43:24,510
En vaak de manier om dat te doen is
deze combinaties als we behouden

1013
00:43:24,510 --> 00:43:25,650
Steek de gegevens.

1014
00:43:25,650 --> 00:43:31,110
Kortom, we de gegevens verspreiden
in de lichte emmer als het komt in.

1015
00:43:31,110 --> 00:43:35,210
>> Range toetsen kunt mij-- hash
sleutels moet gelijkheid zijn.

1016
00:43:35,210 --> 00:43:39,490
Als ik een query een hash, moet ik zeggen
geef me een hash dat dit evenaart.

1017
00:43:39,490 --> 00:43:41,950
Als ik een query een bereik, ik
kan zeggen geef me een scala

1018
00:43:41,950 --> 00:43:47,040
dat is het gebruik van elke vorm van
rijke operator die we ondersteunen.

1019
00:43:47,040 --> 00:43:49,200
Geef me alle items voor een hash.

1020
00:43:49,200 --> 00:43:52,520
Is het gelijk, groter dan,
dan, begint het met,

1021
00:43:52,520 --> 00:43:54,145
het bestaat tussen deze twee waarden?

1022
00:43:54,145 --> 00:43:56,811
Dus dit soort range queries
dat we altijd geïnteresseerd in.

1023
00:43:56,811 --> 00:43:59,650
Nu is een ding over data, wanneer
je kijkt naar de toegang tot gegevens, wanneer

1024
00:43:59,650 --> 00:44:02,360
u toegang tot de gegevens, het is
altijd om een ​​aggregatie.

1025
00:44:02,360 --> 00:44:05,770
Het gaat altijd over de verslagen
die gerelateerd zijn aan deze.

1026
00:44:05,770 --> 00:44:10,390
Geef mij alles hier that's-- alle
de transacties op deze creditcard

1027
00:44:10,390 --> 00:44:12,500
voor de laatste maand.

1028
00:44:12,500 --> 00:44:13,960
Dat is een samenvoeging.

1029
00:44:13,960 --> 00:44:17,490
>> Bijna alles wat je doet in de
database is een soort van aggregatie.

1030
00:44:17,490 --> 00:44:21,530
Dus de mogelijkheid om te kunnen definiëren
Deze emmers en geven u deze range

1031
00:44:21,530 --> 00:44:24,950
attributen kunnen bevragen,
die rijke queries ondersteunen vele,

1032
00:44:24,950 --> 00:44:27,165
vele, vele toegang applicatie patronen.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Dus de andere wat de hekje-toets
doet is het geeft ons een mechanisme

1035
00:44:35,000 --> 00:44:37,740
kunnen de gegevens rond te spreiden.

1036
00:44:37,740 --> 00:44:40,390
NoSQL-databases werken het beste
wanneer de data gelijkmatig

1037
00:44:40,390 --> 00:44:41,740
verdeeld over de cluster.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Hoeveel mensen zijn bekend
met hashing algoritmen?

1040
00:44:47,050 --> 00:44:49,860
Toen ik hasj en een hashing-- zeggen
omdat een hashing-algoritme

1041
00:44:49,860 --> 00:44:54,140
is een manier te kunnen genereren
een willekeurige waarde van een gegeven waarde.

1042
00:44:54,140 --> 00:44:59,300
Dus in dit geval, de
hash-algoritme we lopen is ND 5 gebaseerd.

1043
00:44:59,300 --> 00:45:04,765
>> En als ik een ID, en dit
is mijn hash sleutel, ik heb 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Wanneer ik de hash-algoritme,
het gaat om terug te komen en te zeggen:

1045
00:45:07,390 --> 00:45:10,800
en 1 gelijk 7B, 2
gelijk aan 48, 3 gelijk CD.

1046
00:45:10,800 --> 00:45:13,092
Ze zijn verspreid over de belangrijkste ruimte.

1047
00:45:13,092 --> 00:45:14,050
En waarom doe je dit?

1048
00:45:14,050 --> 00:45:17,120
Want dat zorgt ervoor dat ik kan
zet de verslagen over meerdere nodes.

1049
00:45:17,120 --> 00:45:19,574
>> Als ik dit doe
stapsgewijs, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
En ik heb een hash bereik dat
runs in dit geval

1051
00:45:21,990 --> 00:45:24,785
een kleine hash ruimte,
loopt van 00 tot FF,

1052
00:45:24,785 --> 00:45:27,951
dan is de administratie gaan om binnen te komen
en ze gaan naar 1, 2, 3, 4, 5,

1053
00:45:27,951 --> 00:45:30,390
6, 7, 8, 9, 10, 11, 12.

1054
00:45:30,390 --> 00:45:31,800
Wat gebeurt?

1055
00:45:31,800 --> 00:45:34,860
Elk inzetstuk naar hetzelfde knooppunt.

1056
00:45:34,860 --> 00:45:36,070
Zie je wat ik bedoel?

1057
00:45:36,070 --> 00:45:40,910
>> Want als ik deelden de ruimte,
en ik verspreid deze records over,

1058
00:45:40,910 --> 00:45:45,950
en ik partitie, ik ga zeggen
partitie 1 heeft sleutel ruimte 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partitie 2 is 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partitie 3 is AA FF.

1061
00:45:49,780 --> 00:45:53,740
Dus als ik ben met behulp van lineair verhogen
Id's, kunt u zien wat er gebeurt.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, helemaal tot aan 54.

1063
00:45:57,410 --> 00:46:00,030
Dus als ik het hameren
gegevens in het systeem,

1064
00:46:00,030 --> 00:46:02,030
alles eindigt gaat naar een knooppunt.

1065
00:46:02,030 --> 00:46:03,160
>> Dat is niet goed.

1066
00:46:03,160 --> 00:46:04,820
Dat is een antipattern.

1067
00:46:04,820 --> 00:46:08,760
In MongoDB hebben ze dit probleem
als je niet beschikt over een hekje te gebruiken.

1068
00:46:08,760 --> 00:46:11,325
MongoDB geeft u de mogelijkheid
hashing van de belangrijkste waarde.

1069
00:46:11,325 --> 00:46:13,950
Je moet altijd dat doen, als
je bent met behulp van een hash verhogen

1070
00:46:13,950 --> 00:46:17,380
sleutel in MongoDB, of je zult
spijkeren elke schrijven naar een knooppunt,

1071
00:46:17,380 --> 00:46:21,290
en je zal beperken
je schrijft throughput slecht.

1072
00:46:21,290 --> 00:46:24,896
>> PUBLIEK: Is dat A9 169 in decimale?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Ja, het is
ergens rond daar.

1074
00:46:28,450 --> 00:46:29,950
A9, ik weet het niet.

1075
00:46:29,950 --> 00:46:32,200
Je zou hebben om mijn binaire krijgen
decimale rekenmachine.

1076
00:46:32,200 --> 00:46:34,237
Mijn brein werkt niet zo.

1077
00:46:34,237 --> 00:46:36,320
PUBLIEK: Even snel een
van uw Mongo opmerkingen.

1078
00:46:36,320 --> 00:46:39,530
Dus is het object ID die geleverd
native met Mongo dat doen?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Is het dat?

1081
00:46:41,470 --> 00:46:42,970
Als je het opgeeft.

1082
00:46:42,970 --> 00:46:45,030
Met MongoDB, heb je de optie.

1083
00:46:45,030 --> 00:46:48,930
U kunt elk document in specify--
MongoDB moet een underscore ID hebben.

1084
00:46:48,930 --> 00:46:50,300
Dat is de unieke waarde.

1085
00:46:50,300 --> 00:46:55,240
>> In MongoDB u kunt opgeven
of om het te hash of niet.

1086
00:46:55,240 --> 00:46:56,490
Ze geven je gewoon de optie.

1087
00:46:56,490 --> 00:46:58,198
Als je weet dat het
willekeurig, geen probleem.

1088
00:46:58,198 --> 00:46:59,640
U hoeft niet om dat te doen.

1089
00:46:59,640 --> 00:47:04,260
Als je weet dat het niet willekeurig, dat
het is het verhogen, doe dan de hash.

1090
00:47:04,260 --> 00:47:06,880
>> Nu is het ding over
hashing, als je eenmaal hash

1091
00:47:06,880 --> 00:47:08,800
een value-- en dit is
waarom hash toetsen zijn altijd

1092
00:47:08,800 --> 00:47:13,740
unieke vragen, want ik ben veranderd
de waarde, nu kan ik niet een reeks vragen doen.

1093
00:47:13,740 --> 00:47:15,640
Ik kan niet zeggen is dit
tussen dit of dat,

1094
00:47:15,640 --> 00:47:20,800
omdat de hash-waarde is niet van plan
gelijk aan de werkelijke waarde.

1095
00:47:20,800 --> 00:47:24,570
Dus als je hash dat
sleutel, het is slechts gelijkheid.

1096
00:47:24,570 --> 00:47:28,700
Dit is de reden waarom in DynamoDB hekje
queries zijn altijd alleen gelijkheid.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Dus nu in een reeks key--
toen ik toevoegen dat bereik sleutel,

1099
00:47:34,700 --> 00:47:38,180
die reeks belangrijke records allemaal komen en
ze worden opgeslagen op dezelfde partitie.

1100
00:47:38,180 --> 00:47:42,430
Dus ze zijn erg snel, eenvoudig
teruggehaald, want dit is de hash,

1101
00:47:42,430 --> 00:47:43,220
Dit is het bereik.

1102
00:47:43,220 --> 00:47:44,928
En je alles zien
met dezelfde hash

1103
00:47:44,928 --> 00:47:48,550
wordt opgeslagen op dezelfde partitie ruimte.

1104
00:47:48,550 --> 00:47:53,889
Je kunt dat bereik toets gebruiken om te helpen
de locatie van uw gegevens in de buurt van haar moedermaatschappij.

1105
00:47:53,889 --> 00:47:55,180
Dus wat doe ik hier eigenlijk doen?

1106
00:47:55,180 --> 00:47:57,320
Dit is een één tot vele relatie.

1107
00:47:57,320 --> 00:48:01,490
De relatie tussen een hekje
en het bereik sleutel is een te veel.

1108
00:48:01,490 --> 00:48:03,490
Ik kan meerdere hash sleutels.

1109
00:48:03,490 --> 00:48:07,610
Ik kan alleen maar meerdere range
sleutels in ieder hekje.

1110
00:48:07,610 --> 00:48:11,910
>> De hash bepaalt de ouder,
het bereik definieert de kinderen.

1111
00:48:11,910 --> 00:48:15,240
Zodat u kunt zien is er analoge hier
tussen de relationele construct

1112
00:48:15,240 --> 00:48:18,840
en dezelfde soort
construeert in NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Mensen praten over
NoSQL als niet-relationele.

1114
00:48:20,760 --> 00:48:22,200
Het is niet niet-relationele.

1115
00:48:22,200 --> 00:48:24,680
Data altijd relaties.

1116
00:48:24,680 --> 00:48:28,172
Die relaties gewoon
worden anders gemodelleerd.

1117
00:48:28,172 --> 00:48:29,880
Laten we praten een beetje
beetje over duurzaamheid.

1118
00:48:29,880 --> 00:48:34,860
Wanneer je schrijven op DynamoDB, schrijft
zijn altijd drie-weg gerepliceerd.

1119
00:48:34,860 --> 00:48:37,550
Wat betekent dat we hebben drie van AZ.

1120
00:48:37,550 --> 00:48:39,160
AZ zijn beschikbaarheid Zones.

1121
00:48:39,160 --> 00:48:43,430
U kunt denken aan een Beschikbaarheid
Zone als een data center

1122
00:48:43,430 --> 00:48:45,447
of een verzameling van datacenters.

1123
00:48:45,447 --> 00:48:47,780
Deze dingen zijn geografisch
geïsoleerd van elkaar

1124
00:48:47,780 --> 00:48:51,610
over verschillende breukzones, over
verschillende elektriciteitsnetten en de uiterwaarden.

1125
00:48:51,610 --> 00:48:54,510
Een storing in een AZ niet
gaan te nemen van de andere.

1126
00:48:54,510 --> 00:48:56,890
Zij zijn ook gekoppeld
samen met dark fiber.

1127
00:48:56,890 --> 00:49:01,240
Het ondersteunt een sub 1
milliseconde latentie tussen AZS.

1128
00:49:01,240 --> 00:49:05,390
Dus real time data replicatie
staat in multi AZS.

1129
00:49:05,390 --> 00:49:09,990
>> En vaak met meerdere AZ implementaties
voldoen aan de hoge beschikbaarheidseisen

1130
00:49:09,990 --> 00:49:12,930
van de meeste enterprise organisaties.

1131
00:49:12,930 --> 00:49:16,139
Dus DynamoDB gespreid
over drie AZS standaard.

1132
00:49:16,139 --> 00:49:19,430
We zijn alleen maar om de kennis van de write
wanneer twee van de drie knooppunten terugkomen

1133
00:49:19,430 --> 00:49:21,470
en zeggen: Ja, ik heb het.

1134
00:49:21,470 --> 00:49:22,050
Waarom is het zo?

1135
00:49:22,050 --> 00:49:25,950
Want op de lees kant zijn we alleen
ga je de gegevens terug te geven wanneer

1136
00:49:25,950 --> 00:49:27,570
we krijgen van twee knooppunten.

1137
00:49:27,570 --> 00:49:30,490
>> Als ik repliceren over
drie, en ik ben het lezen van de twee,

1138
00:49:30,490 --> 00:49:32,840
Ik ben altijd gegarandeerd
ten minste één over

1139
00:49:32,840 --> 00:49:35,720
van die leest het zijn
meest recente kopie van de gegevens.

1140
00:49:35,720 --> 00:49:38,340
Dat maakt DynamoDB consistent.

1141
00:49:38,340 --> 00:49:42,450
Nu kunt u kiezen om te draaien
die consistente leest uit.

1142
00:49:42,450 --> 00:49:45,070
In dat geval ga ik om te zeggen,
Ik zal alleen lezen van het ene knooppunt.

1143
00:49:45,070 --> 00:49:47,430
En ik kan niet garanderen dat het gaat
om de meest actuele gegevens.

1144
00:49:47,430 --> 00:49:49,450
>> Dus als een waardevermindering komt in,
het is nog niet gerepliceerd,

1145
00:49:49,450 --> 00:49:50,360
je gaat om die kopie te krijgen.

1146
00:49:50,360 --> 00:49:52,220
Dat is een uiteindelijk consistente lezen.

1147
00:49:52,220 --> 00:49:54,640
En wat dat is de helft van de kosten.

1148
00:49:54,640 --> 00:49:56,140
Dus dit is iets om na te denken over.

1149
00:49:56,140 --> 00:50:00,160
Wanneer je uitlezen DynamoDB en
je het opzetten van uw lees- capaciteit

1150
00:50:00,160 --> 00:50:04,430
units, als je uiteindelijk kiezen
consistente leest, het is een stuk goedkoper,

1151
00:50:04,430 --> 00:50:06,010
het is ongeveer de helft van de kosten.

1152
00:50:06,010 --> 00:50:09,342
>> En zo bespaart u geld.

1153
00:50:09,342 --> 00:50:10,300
Maar dat is uw keuze.

1154
00:50:10,300 --> 00:50:12,925
Als u een consistente lezen of
een uiteindelijk consistente lezen.

1155
00:50:12,925 --> 00:50:15,720
Dat is iets dat je kunt kiezen.

1156
00:50:15,720 --> 00:50:17,659
>> Laten we praten over indexen.

1157
00:50:17,659 --> 00:50:19,450
Dus hebben we dat genoemd
topniveau aggregatie.

1158
00:50:19,450 --> 00:50:23,720
We hebben hash toetsen, en
we hebben range toetsen.

1159
00:50:23,720 --> 00:50:24,320
Dat is leuk.

1160
00:50:24,320 --> 00:50:26,950
En dat is op de primaire tabel, I
heb er een hekje, ik heb er een reeks sleutel.

1161
00:50:26,950 --> 00:50:27,783
>> Wat betekent dat?

1162
00:50:27,783 --> 00:50:30,410
Ik heb één attribuut kreeg dat ik
kan rijk queries tegen draaien.

1163
00:50:30,410 --> 00:50:31,800
Het is het bereik toets.

1164
00:50:31,800 --> 00:50:35,530
De andere attributen die item--
Ik kan filteren op deze attributen.

1165
00:50:35,530 --> 00:50:40,050
Maar ik kan geen dingen doen, zoals het
begint met of groter dan.

1166
00:50:40,050 --> 00:50:40,820
>> Hoe doe ik dat?

1167
00:50:40,820 --> 00:50:42,860
Ik maak een index.

1168
00:50:42,860 --> 00:50:45,340
Er zijn twee types
indexen in DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Een index is echt
een andere kijk op de tafel.

1170
00:50:49,002 --> 00:50:50,490
En de lokale secundaire index.

1171
00:50:50,490 --> 00:50:51,781
>> De eerste die we praten over.

1172
00:50:51,781 --> 00:50:57,740
Dus lokale secundaire worden naast elkaar
op dezelfde partitie als data.

1173
00:50:57,740 --> 00:51:00,240
En als zodanig zijn zij op
dezelfde fysieke node.

1174
00:51:00,240 --> 00:51:01,780
Ze zijn wat we consequent noemen.

1175
00:51:01,780 --> 00:51:04,599
Betekenis, zullen ze erkennen
het schrijven met de tafel.

1176
00:51:04,599 --> 00:51:06,890
Wanneer het schrijven komt,
zullen we schrijven via de index.

1177
00:51:06,890 --> 00:51:09,306
We zullen naar de tafel te schrijven,
en dan zullen we erkennen.

1178
00:51:09,306 --> 00:51:10,490
Dus dat is consistent.

1179
00:51:10,490 --> 00:51:13,174
Nadat het schrijven is
erkend van de tafel,

1180
00:51:13,174 --> 00:51:15,090
het is gegarandeerd dat de
lokale secundaire index

1181
00:51:15,090 --> 00:51:18,380
zal dezelfde visie van gegevens.

1182
00:51:18,380 --> 00:51:22,390
Maar wat ze laten je doet is
definiëren alternatieve bereik toetsen.

1183
00:51:22,390 --> 00:51:25,260
>> Aan dezelfde hash gebruiken
key als de primaire tabel,

1184
00:51:25,260 --> 00:51:29,050
omdat ze samen op het
dezelfde partitie, en ze zijn consistent.

1185
00:51:29,050 --> 00:51:33,110
Maar ik kan een index te maken
met verschillende bereik toetsen.

1186
00:51:33,110 --> 00:51:41,590
Dus bijvoorbeeld, als ik had een fabrikant
dat had een ruwe delen tafel komen.

1187
00:51:41,590 --> 00:51:44,590
En ruwe onderdelen komen, en
ze zijn samengevoegd door de montage.

1188
00:51:44,590 --> 00:51:46,840
En misschien is er een recall.

1189
00:51:46,840 --> 00:51:50,240
>> Elk deel dat werd gemaakt door dit
fabrikant na deze datum,

1190
00:51:50,240 --> 00:51:52,840
Ik moet te trekken van mijn lijn.

1191
00:51:52,840 --> 00:51:55,950
Ik kan een index draaien
dat zou kijken,

1192
00:51:55,950 --> 00:52:00,760
aggregeren op de datum van
vervaardiging van dat deel.

1193
00:52:00,760 --> 00:52:03,930
Dus als mijn top level tafel was
al gehashed door de fabrikant,

1194
00:52:03,930 --> 00:52:07,655
misschien was aangebracht op een deel ID, I
kan een index uit die tabel te maken

1195
00:52:07,655 --> 00:52:11,140
zoals hash per fabrikant en
varieerden op datum van productie.

1196
00:52:11,140 --> 00:52:14,490
En op die manier dat ik kon zeggen, iets dat
werd geproduceerd tussen deze data,

1197
00:52:14,490 --> 00:52:16,804
Ik moet te trekken van de lijn.

1198
00:52:16,804 --> 00:52:18,220
Dus dat is een lokale secundaire index.

1199
00:52:18,220 --> 00:52:22,280
>> Deze hebben het effect van de
het beperken van uw hekje ruimte.

1200
00:52:22,280 --> 00:52:24,360
Omdat ze co-bestonden
op dezelfde opslagknooppunt,

1201
00:52:24,360 --> 00:52:26,860
ze beperken de hekje-toets
ruimte 10 gigabytes.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, onder de
tabellen, zal verdelen

1203
00:52:28,950 --> 00:52:31,380
uw tafel elke 10 gigabyte.

1204
00:52:31,380 --> 00:52:34,760
Wanneer je 10 optredens van de gegevens in, we
ga [PHH], en we voegen een ander knooppunt.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> We zullen niet gesplitst de LSI
meerdere partities.

1207
00:52:42,070 --> 00:52:43,200
We zullen de tabel splitsen.

1208
00:52:43,200 --> 00:52:44,679
Maar we zullen niet splitsing van de LSI.

1209
00:52:44,679 --> 00:52:46,470
Dus dat is iets
belangrijk te begrijpen

1210
00:52:46,470 --> 00:52:50,070
is als je zeer doet,
zeer, zeer grote samenvoegingen,

1211
00:52:50,070 --> 00:52:53,860
dan zul je worden beperkt
tot 10 gigabytes op LSIs.

1212
00:52:53,860 --> 00:52:56,640
>> Als dat het geval is, kunnen we
Gebruik wereldwijde secondaries.

1213
00:52:56,640 --> 00:52:58,630
Global secondaries zijn
echt een andere tafel.

1214
00:52:58,630 --> 00:53:01,720
Ze bestaan ​​volledig uit te
de zijkant van de primaire tabel.

1215
00:53:01,720 --> 00:53:04,680
En ze laten me om een ​​vondst
volledig andere structuur.

1216
00:53:04,680 --> 00:53:08,010
Dus denk aan het als gegevens worden ingebracht
in twee verschillende tabellen, gestructureerde

1217
00:53:08,010 --> 00:53:09,220
op twee verschillende manieren.

1218
00:53:09,220 --> 00:53:11,360
>> Ik kan een heel definiëren
verschillende hekje.

1219
00:53:11,360 --> 00:53:13,490
Ik kan een heel definiëren
ander bereik toets.

1220
00:53:13,490 --> 00:53:15,941
En ik kan dit uitvoeren
volledig zelfstandig.

1221
00:53:15,941 --> 00:53:18,190
Als een zaak van de feiten, ik heb
bevoorraad mijn read capaciteit

1222
00:53:18,190 --> 00:53:21,090
Schrijf capaciteit voor mijn
globale secundaire indexen

1223
00:53:21,090 --> 00:53:24,240
volledig onafhankelijk
mijn primaire tabel.

1224
00:53:24,240 --> 00:53:26,640
Als ik te definiëren die index, ik vertel
Het hoeveel lezen en schrijven

1225
00:53:26,640 --> 00:53:28,610
capaciteit het gaat gebruiken.

1226
00:53:28,610 --> 00:53:31,490
>> En dat is gescheiden
van mijn primaire tabel.

1227
00:53:31,490 --> 00:53:35,240
Nu beide indexen ons toelaten om
niet alleen definiëren hash en het bereik toetsen,

1228
00:53:35,240 --> 00:53:38,610
maar wij laten
projecteren extra waarden.

1229
00:53:38,610 --> 00:53:44,950
Dus als ik wil lezen uit de index,
en ik wil een aantal set van gegevens te krijgen,

1230
00:53:44,950 --> 00:53:48,327
Ik heb geen behoefte om terug te gaan naar de belangrijkste
tabel om de extra attributen te krijgen.

1231
00:53:48,327 --> 00:53:50,660
Ik kan die extra projecteren
attributen in de tabel

1232
00:53:50,660 --> 00:53:53,440
ter ondersteuning van de toegang patroon.

1233
00:53:53,440 --> 00:53:57,700
Ik weet dat we waarschijnlijk krijgen in sommige
echt, really-- krijgen in het onkruid

1234
00:53:57,700 --> 00:53:58,910
hier op een aantal van dit spul.

1235
00:53:58,910 --> 00:54:02,725
Nu kreeg ik te drijven uit deze.

1236
00:54:02,725 --> 00:54:07,320
>> PUBLIEK: [onverstaanbaar]
--table sleutel betekende een hash?

1237
00:54:07,320 --> 00:54:08,840
De oorspronkelijke hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-lamellen?

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
De tabel sleutel in principe
wijst terug naar het item.

1242
00:54:15,260 --> 00:54:19,280
Dus een index is een pointer terug naar
de oorspronkelijke items op de tafel.

1243
00:54:19,280 --> 00:54:22,910
Nu kunt u kiezen voor een te bouwen
index die alleen de tabel sleutel,

1244
00:54:22,910 --> 00:54:24,840
en geen andere eigenschappen.

1245
00:54:24,840 --> 00:54:26,570
En waarom zou ik dat doen?

1246
00:54:26,570 --> 00:54:28,570
Nou ja, misschien heb ik zeer grote items.

1247
00:54:28,570 --> 00:54:31,660
>> Ik eigenlijk alleen moet weten which--
mijn toegang patroon zou kunnen zeggen,

1248
00:54:31,660 --> 00:54:33,760
welke items deze eigenschap bevatten?

1249
00:54:33,760 --> 00:54:35,780
Niet nodig om het item terug te keren.

1250
00:54:35,780 --> 00:54:37,800
Ik moet alleen weten
welke items indammen.

1251
00:54:37,800 --> 00:54:40,700
Dus je kunt indexen bouwen
dat alleen de tabel sleutel.

1252
00:54:40,700 --> 00:54:43,360
>> Maar dat is vooral wat
een index in de database is.

1253
00:54:43,360 --> 00:54:46,280
Het is voor snel kunnen
identificeren welke registreert,

1254
00:54:46,280 --> 00:54:49,470
welke rijen, waarbij
items in de tafel

1255
00:54:49,470 --> 00:54:51,080
de eigenschappen die ik zoek.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, dus hoe werken ze?

1258
00:54:54,860 --> 00:54:58,340
GSIS principe zijn asynchroon.

1259
00:54:58,340 --> 00:55:02,570
De update komt in de tabel,
tabel wordt vervolgens asynchroon bijgewerkt

1260
00:55:02,570 --> 00:55:03,720
al uw GSIS.

1261
00:55:03,720 --> 00:55:06,680
Dit is de reden waarom GSIS zijn
uiteindelijk consistent.

1262
00:55:06,680 --> 00:55:09,440
>> Het is belangrijk op te merken dat
als je het bouwen GSIS,

1263
00:55:09,440 --> 00:55:13,110
en je begrijpt u maakt
een andere dimensie van aggregation--

1264
00:55:13,110 --> 00:55:16,594
Nu laten we zeggen een goed voorbeeld
Hier is een fabrikant.

1265
00:55:16,594 --> 00:55:19,260
Ik denk dat ik heb gesproken over
een medisch fabrikant van het apparaat.

1266
00:55:19,260 --> 00:55:23,870
Fabrikanten van medische hulpmiddelen
vaak hebben series onderdelen.

1267
00:55:23,870 --> 00:55:28,070
De onderdelen die verder gaan in
een heupprothese alle

1268
00:55:28,070 --> 00:55:30,200
een beetje serienummer erop.

1269
00:55:30,200 --> 00:55:33,584
En zij konden miljoenen hebben en
miljoenen en miljarden onderdelen

1270
00:55:33,584 --> 00:55:35,000
in alle apparaten die ze verzenden.

1271
00:55:35,000 --> 00:55:37,440
Nou, ze moeten onder aggregeren
verschillende dimensies, alle onderdelen

1272
00:55:37,440 --> 00:55:39,520
in een samenstel, alle
onderdelen die gemaakt

1273
00:55:39,520 --> 00:55:41,670
op een bepaalde lijn, alle
de onderdelen die kwam

1274
00:55:41,670 --> 00:55:44,620
vanaf een bepaalde fabrikant
op een bepaalde datum.

1275
00:55:44,620 --> 00:55:47,940
En deze combinaties soms
opstaan ​​in de miljarden.

1276
00:55:47,940 --> 00:55:50,550
>> Dus ik werk met een aantal van
deze jongens die lijden

1277
00:55:50,550 --> 00:55:53,156
omdat ze creëren
deze ginormous aggregaties

1278
00:55:53,156 --> 00:55:54,280
in hun secundaire indexen.

1279
00:55:54,280 --> 00:55:57,070
Ze misschien een ruwe onderdelen hebben
tabel die wordt geleverd zoals alleen hash.

1280
00:55:57,070 --> 00:55:59,090
Elk deel heeft een uniek serienummer.

1281
00:55:59,090 --> 00:56:00,975
Ik gebruik het serienummer als de hash.

1282
00:56:00,975 --> 00:56:01,600
Het is prachtig.

1283
00:56:01,600 --> 00:56:04,160
Mijn ruwe data tabel is verspreid
Alles over de belangrijkste ruimte.

1284
00:56:04,160 --> 00:56:05,930
Mijn [? schrijven ?]
[? inslikken?] is geweldig.

1285
00:56:05,930 --> 00:56:07,876
Ik neem veel gegevens.

1286
00:56:07,876 --> 00:56:09,500
Dan wat ze doen is ze een GSI.

1287
00:56:09,500 --> 00:56:12,666
En ik zeg, weet je wat, ik moet zien
alle onderdelen voor deze fabrikant.

1288
00:56:12,666 --> 00:56:15,060
Nou ja, ineens ben ik
het nemen van een miljard rijen,

1289
00:56:15,060 --> 00:56:17,550
en vul ze op
één knooppunt, want als

1290
00:56:17,550 --> 00:56:21,170
Ik aggregeren als
fabrikant ID als de hash,

1291
00:56:21,170 --> 00:56:25,410
en een deel nummer als het bereik,
dan plots ik

1292
00:56:25,410 --> 00:56:30,530
zetten een miljard delen in wat
Deze fabrikant heeft mij verlost.

1293
00:56:30,530 --> 00:56:34,447
>> Dat kan veel veroorzaken
druk op de GSI,

1294
00:56:34,447 --> 00:56:36,030
weer, want ik hameren één knooppunt.

1295
00:56:36,030 --> 00:56:38,350
Ik zet al deze
voegt in één knooppunt.

1296
00:56:38,350 --> 00:56:40,940
En dat is een echte problematisch use case.

1297
00:56:40,940 --> 00:56:43,479
Nu, ik heb een goed ontwerp
patroon voor hoe vermijd je dat.

1298
00:56:43,479 --> 00:56:45,770
En dat is een van de problemen
dat ik werk altijd met.

1299
00:56:45,770 --> 00:56:49,590
Maar wat gebeurt, is de GSI misschien
genoeg schrijven capaciteit hebben

1300
00:56:49,590 --> 00:56:52,330
kunnen duwen alle
rijen in een enkel knooppunt.

1301
00:56:52,330 --> 00:56:55,390
En wat gebeurt er dan is het
primair, de klant tafel,

1302
00:56:55,390 --> 00:57:00,180
de primaire tabel wordt gesmoord
omdat de GSI niet kan bijbenen.

1303
00:57:00,180 --> 00:57:02,980
Dus mijn insert tarief
vallen op de primaire tabel

1304
00:57:02,980 --> 00:57:06,230
zoals mijn GSI probeert te houden.

1305
00:57:06,230 --> 00:57:08,850
>> Oké, dus GSI's, LSI's,
welke moet ik gebruiken?

1306
00:57:08,850 --> 00:57:12,290
LSI's consistent.

1307
00:57:12,290 --> 00:57:13,750
GSI's zijn uiteindelijk consistent.

1308
00:57:13,750 --> 00:57:17,490
Als dat is OK, adviseer ik met behulp van een
GSI, ze zijn veel flexibeler.

1309
00:57:17,490 --> 00:57:20,270
LSI kan worden gemodelleerd als een GSI.

1310
00:57:20,270 --> 00:57:27,040
En als de gegevens grootte per hash sleutels in
uw collectie meer dan 10 gigabyte,

1311
00:57:27,040 --> 00:57:31,050
dan zul je wilt gebruiken
GSI want het is gewoon een harde limiet.

1312
00:57:31,050 --> 00:57:32,035
>> Oké, dus schaalvergroting.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
De overslag in Dynamo DB, u
Can bepaling [onverstaanbaar]

1315
00:57:37,460 --> 00:57:38,680
doorvoer naar een tafel.

1316
00:57:38,680 --> 00:57:42,740
We hebben klanten die hebben
bevoorraad 60 billion--

1317
00:57:42,740 --> 00:57:45,970
doen 60 miljard verzoeken, regelmatig
draait op meer dan een miljoen aanvragen

1318
00:57:45,970 --> 00:57:47,790
per seconde op onze tafels.

1319
00:57:47,790 --> 00:57:50,360
Er is echt geen
theoretische limiet aan hoeveel

1320
00:57:50,360 --> 00:57:53,730
en hoe snel de tafel
kan in Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Er zijn een aantal zacht
limieten op uw account

1322
00:57:55,920 --> 00:57:58,170
dat zetten we daar in zo
dat je niet gek.

1323
00:57:58,170 --> 00:58:00,070
Als u meer dan wilt
dat geen probleem.

1324
00:58:00,070 --> 00:58:00,820
Je komt ons vertellen.

1325
00:58:00,820 --> 00:58:02,810
We zetten de wijzerplaat.

1326
00:58:02,810 --> 00:58:08,210
>> Elk account is beperkt tot een bepaald niveau
in elke dienst, net buiten de vleermuis

1327
00:58:08,210 --> 00:58:11,920
zodat de mensen niet gek
krijgen zich in de problemen.

1328
00:58:11,920 --> 00:58:12,840
Geen limiet in grootte.

1329
00:58:12,840 --> 00:58:14,940
U kunt elk nummer zetten
items op een tafel.

1330
00:58:14,940 --> 00:58:17,620
De grootte van een artikel
beperkt tot 400 kilobytes per,

1331
00:58:17,620 --> 00:58:20,050
dat zou zijn artikel niet de attributen.

1332
00:58:20,050 --> 00:58:24,200
Zodat de som van alle attributen
is beperkt tot 400 kilobytes.

1333
00:58:24,200 --> 00:58:27,300
En nogmaals, we hebben
dat kleine LSI kwestie

1334
00:58:27,300 --> 00:58:30,405
met de 10 gigabyte limiet per hash.

1335
00:58:30,405 --> 00:58:33,280
Doelgroep: Kleine nummer, ik ben ontbrekende
wat je me vertelt, dat is--

1336
00:58:33,280 --> 00:58:36,830
PUBLIEK: Oh, 400 kilobyte
is de maximale grootte per stuk.

1337
00:58:36,830 --> 00:58:39,570
Dus een item heeft alle attributen.

1338
00:58:39,570 --> 00:58:43,950
Dus 400 k is de totale omvang
van dat punt, 400 kilobytes.

1339
00:58:43,950 --> 00:58:46,170
Dus alle attributen
gecombineerd, alle data

1340
00:58:46,170 --> 00:58:49,140
dat is in al die attributen,
opgerold tot een totale grootte,

1341
00:58:49,140 --> 00:58:51,140
momenteel vandaag het item limiet is 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Dus nogmaals schalen, bereikt
door middel van partitionering.

1344
00:58:57,046 --> 00:58:58,920
Doorvoer wordt bevoorraad
aan tafel niveau.

1345
00:58:58,920 --> 00:59:00,160
En er is echt twee knoppen.

1346
00:59:00,160 --> 00:59:02,400
We hebben gelezen capaciteit
en schrijf capaciteit.

1347
00:59:02,400 --> 00:59:05,530
>> Dus deze worden aangepast
onafhankelijk van elkaar.

1348
00:59:05,530 --> 00:59:08,640
RCU's maatregel strikt consistente leest.

1349
00:59:08,640 --> 00:59:13,005
OK, dus als je zegt ik wil 1000
RCU's die strikt consistent,

1350
00:59:13,005 --> 00:59:14,130
die consistent leest.

1351
00:59:14,130 --> 00:59:17,130
Als je zegt ik wil
uiteindelijke consistente leest,

1352
00:59:17,130 --> 00:59:19,402
kunt u bepaling 1000
RCU's, je gaat

1353
00:59:19,402 --> 00:59:21,840
om uiteindelijk 2000
consistente leest.

1354
00:59:21,840 --> 00:59:25,940
En de helft van de prijs voor die
uiteindelijk bestaan ​​uit leest.

1355
00:59:25,940 --> 00:59:28,520
>> Nogmaals, gecorrigeerd
onafhankelijk van elkaar.

1356
00:59:28,520 --> 00:59:32,900
En ze hebben de throughput--
Als u verbruikt 100% van uw afstandsbediening,

1357
00:59:32,900 --> 00:59:35,960
je bent niet van plan om de impact
beschikbaarheid van uw rechten.

1358
00:59:35,960 --> 00:59:40,161
Dus ze zijn volledig
onafhankelijk van elkaar.

1359
00:59:40,161 --> 00:59:43,160
Oké, dus een van de dingen die
Ik noemde het kort werd smoren.

1360
00:59:43,160 --> 00:59:44,320
Throttling is slecht.

1361
00:59:44,320 --> 00:59:47,311
Smoren geeft slechte geen SQL.

1362
00:59:47,311 --> 00:59:50,310
Er zijn dingen die we kunnen doen om te helpen
je smoren verlichten dat u

1363
00:59:50,310 --> 00:59:51,040
ervaren.

1364
00:59:51,040 --> 00:59:53,240
Maar de beste oplossing
deze is laten we

1365
00:59:53,240 --> 00:59:58,000
Een blik op wat je doet, want
is er een anti-patroon in het spel hier.

1366
00:59:58,000 --> 01:00:02,140
>> Deze dingen, dingen als niet-uniforme
workloads, sneltoetsen, hot partities.

1367
01:00:02,140 --> 01:00:06,210
Ik ben het raken van een bepaalde toets ruimte
erg moeilijk voor een bepaalde reden.

1368
01:00:06,210 --> 01:00:07,080
Waarom doe ik dit?

1369
01:00:07,080 --> 01:00:08,710
Laten we dat uit.

1370
01:00:08,710 --> 01:00:10,427
Ik ben het mengen van mijn hete data met koud data.

1371
01:00:10,427 --> 01:00:12,510
Ik laat mijn tafels
enorm, maar er is echt

1372
01:00:12,510 --> 01:00:15,970
slechts enkele deelverzameling van de gegevens
dat is echt interessant voor mij.

1373
01:00:15,970 --> 01:00:20,290
Dus voor logboekgegevens bijvoorbeeld veel
klanten, krijgen ze loggegevens elke dag.

1374
01:00:20,290 --> 01:00:22,490
Ze hebben een enorme hoeveelheid loggegevens.

1375
01:00:22,490 --> 01:00:25,940
>> Als je gewoon dumpen alles wat log
gegevens in één grote tafel, na verloop van tijd

1376
01:00:25,940 --> 01:00:28,070
die tafel gaat massaal te krijgen.

1377
01:00:28,070 --> 01:00:30,950
Maar ik ben echt alleen in geinteresseerd
laatste 24 uur, de laatste zeven dagen,

1378
01:00:30,950 --> 01:00:31,659
de laatste 30 dagen.

1379
01:00:31,659 --> 01:00:34,074
Ongeacht het venster van de tijd
dat ik ben geïnteresseerd in het zoeken

1380
01:00:34,074 --> 01:00:37,010
voor het geval dat me stoort, of
Indien dat is interessant voor mij,

1381
01:00:37,010 --> 01:00:39,540
dat is het enige raam keer dat ik nodig heb.

1382
01:00:39,540 --> 01:00:42,470
Dus waarom ben ik het zetten 10 jaar
ter waarde van log gegevens in de tabel?

1383
01:00:42,470 --> 01:00:45,030
Wat dat veroorzaakt is
de tafel het fragment.

1384
01:00:45,030 --> 01:00:45,880
>> Het wordt enorm.

1385
01:00:45,880 --> 01:00:48,340
Het begint uitspreiden
over duizenden nodes.

1386
01:00:48,340 --> 01:00:51,380
En omdat uw vermogen
is zo laag, je bent

1387
01:00:51,380 --> 01:00:54,090
eigenlijk snelheidsbeperkende op elke
zo'n afzonderlijke knooppunten.

1388
01:00:54,090 --> 01:00:57,120
Dus laten we gaan kijken naar hoe
doen we roll die tafel over.

1389
01:00:57,120 --> 01:01:01,502
Hoe gaan we om die gegevens een beetje
beter om deze problemen te voorkomen.

1390
01:01:01,502 --> 01:01:02,710
En hoe ziet dat eruit?

1391
01:01:02,710 --> 01:01:04,370
Dit is wat die lijkt.

1392
01:01:04,370 --> 01:01:06,790
Dit is wat slecht NoSQL eruit ziet.

1393
01:01:06,790 --> 01:01:07,830
>> Ik heb hier een sneltoets.

1394
01:01:07,830 --> 01:01:10,246
Als je kijkt op de zijkant hier,
het zijn allemaal mijn partities.

1395
01:01:10,246 --> 01:01:12,630
Ik heb 16 partities hier
deze bepaalde database.

1396
01:01:12,630 --> 01:01:13,630
We doen dit de hele tijd.

1397
01:01:13,630 --> 01:01:15,046
Ik dit lopen voor klanten alle tijden.

1398
01:01:15,046 --> 01:01:16,550
Het heet de hitte kaart.

1399
01:01:16,550 --> 01:01:20,590
Hitte kaart vertelt me ​​hoe je bent
toegang tot uw sleutel ruimte.

1400
01:01:20,590 --> 01:01:23,700
En wat dit vertelt mij
dat er een bepaalde hash

1401
01:01:23,700 --> 01:01:26,330
dat deze man houdt van een
verschrikkelijk veel, want hij is

1402
01:01:26,330 --> 01:01:28,250
raken het echt, echt moeilijk.

1403
01:01:28,250 --> 01:01:29,260
>> Dus de blauwe is leuk.

1404
01:01:29,260 --> 01:01:29,900
We willen blauw.

1405
01:01:29,900 --> 01:01:30,720
We houden niet van rood.

1406
01:01:30,720 --> 01:01:33,120
Rood, waar de druk
krijgt tot 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, nu je gaat worden gesmoord.

1408
01:01:35,560 --> 01:01:39,030
Dus wanneer je zie geen rode lijnen als
dit-- en het is niet alleen Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
elke NoSQL-database heeft dit probleem.

1410
01:01:41,630 --> 01:01:44,640
Er zijn anti-patronen die kunnen
rijden dit soort aandoeningen.

1411
01:01:44,640 --> 01:01:49,070
Wat ik doe is dat ik samen met klanten
deze omstandigheden te.

1412
01:01:49,070 --> 01:01:51,840
>> En hoe ziet dat eruit?

1413
01:01:51,840 --> 01:01:54,260
En dit is het krijgen van de meest
van Dynamo DB throughput,

1414
01:01:54,260 --> 01:01:56,176
maar het is echt het krijgen
het meeste uit NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Dit is niet beperkt tot Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Dit is definitely-- I
gebruikt om te werken bij Mongo.

1417
01:02:02,050 --> 01:02:04,090
Ik ben bekend met vele NoSQL platforms.

1418
01:02:04,090 --> 01:02:06,830
Iedereen heeft deze typen
van sneltoets problemen.

1419
01:02:06,830 --> 01:02:10,320
Om het meeste te halen uit elke NoSQL
databank, in het bijzonder Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
u wilt de tabellen te maken
waar de hash sleutel element

1421
01:02:13,320 --> 01:02:18,590
een groot aantal verschillende waarden,
een hoge mate van belangrijkheid.

1422
01:02:18,590 --> 01:02:22,530
Want dat betekent dat ik aan het schrijven ben
om veel verschillende emmers.

1423
01:02:22,530 --> 01:02:24,870
>> Hoe meer emmers ik ben
schrijf, hoe waarschijnlijker

1424
01:02:24,870 --> 01:02:29,100
Ik ben dat schrijven belasting verspreiden of
lees laden uit over meerdere nodes,

1425
01:02:29,100 --> 01:02:33,560
hoe meer kans dat ik een hebben
hoge doorvoer op de tafel.

1426
01:02:33,560 --> 01:02:37,440
En dan wil ik de waarden te zijn
gevraagde redelijk gelijkmatig over de tijd

1427
01:02:37,440 --> 01:02:39,430
en uniform willekeurig mogelijk.

1428
01:02:39,430 --> 01:02:42,410
Nou, dat is een soort van interessante,
want ik kan niet echt

1429
01:02:42,410 --> 01:02:43,960
controle bij de gebruiker komen.

1430
01:02:43,960 --> 01:02:47,645
Zo volstaat te zeggen, als we spreiden
dingen uit over de belangrijkste ruimte,

1431
01:02:47,645 --> 01:02:49,270
we zullen waarschijnlijk beter in vorm.

1432
01:02:49,270 --> 01:02:51,522
>> Er is een zekere
hoeveelheid tijd levering

1433
01:02:51,522 --> 01:02:53,230
dat je niet gaat
te kunnen controle.

1434
01:02:53,230 --> 01:02:55,438
Maar die zijn echt de
twee dimensies die we hebben,

1435
01:02:55,438 --> 01:02:58,800
ruimte, toegang gelijkmatig
spread, tijd, verzoeken

1436
01:02:58,800 --> 01:03:01,040
Invaren gelijkmatig verdeeld in de tijd.

1437
01:03:01,040 --> 01:03:03,110
Als deze twee
voorwaarden wordt voldaan,

1438
01:03:03,110 --> 01:03:05,610
dan is dat wat het is
gaan uitzien.

1439
01:03:05,610 --> 01:03:07,890
Dit is veel mooier.

1440
01:03:07,890 --> 01:03:08,890
We zijn hier erg blij.

1441
01:03:08,890 --> 01:03:10,432
We hebben een zeer zelfs de toegang patroon.

1442
01:03:10,432 --> 01:03:13,098
Ja, misschien heb je krijgt een
weinig druk zo nu en dan,

1443
01:03:13,098 --> 01:03:14,830
maar niets echt te uitgebreid.

1444
01:03:14,830 --> 01:03:17,660
Dus het is verbazingwekkend hoe vaak,
toen ik werken met klanten,

1445
01:03:17,660 --> 01:03:20,670
die eerste grafiek met de grote rode
bar en al die lelijke gele het

1446
01:03:20,670 --> 01:03:23,147
all over the place, we
gedaan te krijgen met de uitoefening

1447
01:03:23,147 --> 01:03:24,980
na een paar maanden
van re-architectuur,

1448
01:03:24,980 --> 01:03:28,050
ze draaien exact dezelfde
werklast op exact dezelfde belasting.

1449
01:03:28,050 --> 01:03:30,140
En dit is wat het is op zoek als nu.

1450
01:03:30,140 --> 01:03:36,600
Dus wat je krijgt met NoSQL is een
data schema dat is absoluut

1451
01:03:36,600 --> 01:03:38,510
gebonden aan de toegang patroon.

1452
01:03:38,510 --> 01:03:42,170
>> En je kunt die gegevens schema te optimaliseren
te steunen die toegang patroon.

1453
01:03:42,170 --> 01:03:45,490
Als je dat niet doet, dan zul je
om die soorten problemen te zien

1454
01:03:45,490 --> 01:03:46,710
met die sneltoetsen.

1455
01:03:46,710 --> 01:03:50,518
>> PUBLIEK: Nou, onvermijdelijk sommige plaatsen
gaan warmer dan anderen.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Altijd.

1457
01:03:51,450 --> 01:03:51,960
Altijd.

1458
01:03:51,960 --> 01:03:54,620
Ja, ik bedoel er is altijd
a-- en nogmaals, er is

1459
01:03:54,620 --> 01:03:56,980
sommige design patterns we door te komen
die zal spreken over hoe je omgaat

1460
01:03:56,980 --> 01:03:58,480
met deze super grote aggregaten.

1461
01:03:58,480 --> 01:04:01,260
Ik bedoel, ik heb om ze te hebben,
hoe gaan we ermee om?

1462
01:04:01,260 --> 01:04:03,760
Ik had een vrij goede use case
dat we over praten voor.

1463
01:04:03,760 --> 01:04:05,940
>> Oké, dus laten we praten
over sommige klanten nu.

1464
01:04:05,940 --> 01:04:06,950
Deze jongens zijn AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Ik weet niet of je bent
vertrouwd met AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Je ziet ze waarschijnlijk
veel van de browser.

1467
01:04:10,781 --> 01:04:14,230
Ze zijn ad re-targeting, ze zijn
de grootste ad re-targeting bedrijf

1468
01:04:14,230 --> 01:04:14,940
buiten.

1469
01:04:14,940 --> 01:04:17,792
Ze normaal gesproken regelmatig overreden
60 miljard transacties per dag.

1470
01:04:17,792 --> 01:04:20,000
Ze doen meer dan een miljoen
transacties per seconde.

1471
01:04:20,000 --> 01:04:22,660
Ze hebben een vrij eenvoudige tafel kreeg
structuur, de drukste tafel.

1472
01:04:22,660 --> 01:04:26,450
Het is eigenlijk gewoon een
hash sleutel is het koekje,

1473
01:04:26,450 --> 01:04:29,010
het bereik is van de demografische
categorie, en dan

1474
01:04:29,010 --> 01:04:31,220
de derde kenmerk is de score.

1475
01:04:31,220 --> 01:04:33,720
>> Dus we hebben allemaal cookies in
onze browser van deze jongens.

1476
01:04:33,720 --> 01:04:35,900
En als je naar een
deelnemende handelaar,

1477
01:04:35,900 --> 01:04:39,390
ze eigenlijk scoren je tegenkomt
verschillende demografische categorieën.

1478
01:04:39,390 --> 01:04:42,070
Als je naar een website en
je zegt ik wil dit ad-- zien

1479
01:04:42,070 --> 01:04:44,920
of eigenlijk hoef je niet zeggen dat--
maar als je naar de website

1480
01:04:44,920 --> 01:04:47,550
ze zeggen dat je wilt deze advertentie.

1481
01:04:47,550 --> 01:04:49,370
En ze gaan krijgen die advertentie van AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll kijkt u op hun tafel.

1483
01:04:51,130 --> 01:04:52,115
Ze vinden uw cookie.

1484
01:04:52,115 --> 01:04:53,990
De adverteerders vertellen
hen, ik wil iemand

1485
01:04:53,990 --> 01:04:58,632
wie is van middelbare leeftijd,
40-jarige man, in de sport.

1486
01:04:58,632 --> 01:05:01,590
En zij scoren u in die demografische
en ze beslissen of

1487
01:05:01,590 --> 01:05:02,740
dat is een goede advertentie voor jou.

1488
01:05:02,740 --> 01:05:10,330
>> Nu hebben ze een SLA met
hun reclame aanbieders

1489
01:05:10,330 --> 01:05:14,510
sub-10 milliseconde bieden
respons op elke aanvraag.

1490
01:05:14,510 --> 01:05:16,090
Dus ze gebruiken Dynamo DB voor.

1491
01:05:16,090 --> 01:05:18,131
Ze ons een raken
miljoen aanvragen per seconde.

1492
01:05:18,131 --> 01:05:21,120
Ze zijn in staat om alles te doen van hun
lookups, triage al die gegevens,

1493
01:05:21,120 --> 01:05:26,130
en krijgen dat add link terug naar die
adverteerder in minder dan 10 milliseconden.

1494
01:05:26,130 --> 01:05:29,800
Het is echt mooi fenomenaal
implementatie die ze hebben.

1495
01:05:29,800 --> 01:05:36,210
>> Deze jongens actually--
dit zijn de jongens.

1496
01:05:36,210 --> 01:05:38,010
Ik ben niet zeker of het deze jongens.

1497
01:05:38,010 --> 01:05:40,127
Misschien deze jongens.

1498
01:05:40,127 --> 01:05:42,210
Eigenlijk vertelde ons-- nee, ik
denk niet dat het hen was.

1499
01:05:42,210 --> 01:05:43,000
Ik denk dat het iemand anders was.

1500
01:05:43,000 --> 01:05:44,750
Ik werkte met een
de klant die me vertelde

1501
01:05:44,750 --> 01:05:47,040
dat nu dat ze hebben
gegaan naar Dynamo DB, ze zijn

1502
01:05:47,040 --> 01:05:50,330
besteden meer geld aan snacks voor
hun development team elke maand

1503
01:05:50,330 --> 01:05:52,886
dan ze uitgeven aan hun database.

1504
01:05:52,886 --> 01:05:54,760
Dus het zal je een geven
idee van de kostenbesparingen

1505
01:05:54,760 --> 01:05:57,889
die je kunt krijgen in Dynamo DB is enorm.

1506
01:05:57,889 --> 01:05:59,430
Oké, dropcam is een ander bedrijf.

1507
01:05:59,430 --> 01:06:02,138
Deze man is een soort van-- als je denkt
van het internet van de dingen, dropcam

1508
01:06:02,138 --> 01:06:05,150
is eigenlijk internet security video.

1509
01:06:05,150 --> 01:06:06,660
Je zet je camera die er zijn.

1510
01:06:06,660 --> 01:06:08,180
Camera heeft een bewegingsdetector.

1511
01:06:08,180 --> 01:06:10,290
Iemand komt langs,
triggers een cue punt.

1512
01:06:10,290 --> 01:06:13,540
Camera start de opname voor een tijdje tot
het geen beweging meer detecteren.

1513
01:06:13,540 --> 01:06:15,310
Zet die video op het internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam was een bedrijf dat is
eigenlijk overgestapt naar Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
omdat ze werden ervaren
enorme groeipijnen.

1516
01:06:22,200 --> 01:06:25,820
En wat ze ons vertelde,
plotseling petabyte aan data.

1517
01:06:25,820 --> 01:06:28,070
Ze hadden er geen idee van hun dienst
zou zo succesvol.

1518
01:06:28,070 --> 01:06:32,310
Meer inkomende video dan YouTube
is wat deze jongens krijgen.

1519
01:06:32,310 --> 01:06:36,780
Zij maken gebruik van DynamoDB te sporen alle
metadata van al hun video belangrijke punten.

1520
01:06:36,780 --> 01:06:40,282
>> Dus ze hebben S3 emmers ze duwen
alle binaire artefacten in.

1521
01:06:40,282 --> 01:06:41,990
En dan hebben ze
Dynamo DB records

1522
01:06:41,990 --> 01:06:44,070
wijzen mensen die S3 drie objecten.

1523
01:06:44,070 --> 01:06:47,070
Wanneer ze moeten kijken naar een video,
ze zoeken het record in Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Ze klikt u op de link.

1525
01:06:47,903 --> 01:06:49,770
Ze trekken naar beneden de video van S3.

1526
01:06:49,770 --> 01:06:51,590
Dus dat is een soort van hoe dit eruit ziet.

1527
01:06:51,590 --> 01:06:53,580
En dit is rechtstreeks van hun team.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB vermindert hun
levertijd voor video-events

1529
01:06:56,010 --> 01:06:57,590
van vijf tot 10 seconden.

1530
01:06:57,590 --> 01:07:00,470
In hun oude relationele winkel,
ze gebruikt te hebben om te gaan en uit te voeren

1531
01:07:00,470 --> 01:07:03,780
meervoudige complexe queries figuur
welke video's neer te halen,

1532
01:07:03,780 --> 01:07:06,690
tot minder dan 50 milliseconden.

1533
01:07:06,690 --> 01:07:08,990
Dus het is geweldig, verbazingwekkend
hoeveel prestaties

1534
01:07:08,990 --> 01:07:12,990
je kunt krijgen als je optimaliseren en
u afstemt de onderliggende databank

1535
01:07:12,990 --> 01:07:15,110
ter ondersteuning van de toegang patroon.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, deze jongens, wat is het,
Fruit Ninja Ik denk dat is hun ding.

1537
01:07:20,500 --> 01:07:22,590
Dat alle draait op Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
En deze jongens, ze zijn een geweldige
development team, grote ontwikkeling

1539
01:07:26,810 --> 01:07:27,670
winkel.

1540
01:07:27,670 --> 01:07:29,364
>> Niet een goede ops team.

1541
01:07:29,364 --> 01:07:31,280
Ze hadden niet veel
van de operatie middelen.

1542
01:07:31,280 --> 01:07:33,940
Ze vochten proberen te houden
hun applicatie-infrastructuur up

1543
01:07:33,940 --> 01:07:34,290
and running.

1544
01:07:34,290 --> 01:07:35,000
Ze kwamen naar ons.

1545
01:07:35,000 --> 01:07:36,251
Ze keken op dat Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Ze zeiden, dat is voor ons.

1547
01:07:37,291 --> 01:07:39,470
Ze bouwden hun hele
applicatie framework op.

1548
01:07:39,470 --> 01:07:43,640
Hier een aantal hele leuke reacties
van het team op hun vermogen

1549
01:07:43,640 --> 01:07:46,800
nu richten op de bouw
het spel en niet

1550
01:07:46,800 --> 01:07:49,010
dat u het handhaven
infrastructuur, die

1551
01:07:49,010 --> 01:07:51,910
was steeds een enorme hoeveelheid
overhead voor hun team.

1552
01:07:51,910 --> 01:07:56,170
Dus dit is iets dat-- de
voordeel dat je krijgt van Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Oké, het krijgen in
datamodellering hier.

1554
01:08:00,930 --> 01:08:03,440
En we praatten een beetje over
Deze 1 tot 1, 1 tot vele,

1555
01:08:03,440 --> 01:08:05,060
en veel te veel soort relaties.

1556
01:08:05,060 --> 01:08:07,630
En hoe ga je te houden die in Dynamo.

1557
01:08:07,630 --> 01:08:10,500
In Dynamo DB gebruiken we
indexen algemeen

1558
01:08:10,500 --> 01:08:12,910
de gegevens van roteren
één smaak naar de andere.

1559
01:08:12,910 --> 01:08:15,210
Hash toetsen, bereik sleutels en indexen.

1560
01:08:15,210 --> 01:08:18,540
>> In dit specifieke
Bijvoorbeeld, de meeste staten

1561
01:08:18,540 --> 01:08:23,802
hebben een vergunningplicht die
slechts rijbewijs één bestuurder per persoon.

1562
01:08:23,802 --> 01:08:26,510
Je kunt niet naar twee bestuurder te krijgen
licenties in de staat van Boston.

1563
01:08:26,510 --> 01:08:27,500
Ik kan het niet doen in Texas.

1564
01:08:27,500 --> 01:08:28,708
Dat is een soort van de manier waarop het is.

1565
01:08:28,708 --> 01:08:32,779
En zo bij de DMV, hebben we lookups, we
wilt opzoeken het rijbewijs

1566
01:08:32,779 --> 01:08:35,180
door het aantal sociale zekerheid.

1567
01:08:35,180 --> 01:08:39,990
Ik wil opzoeken van de gebruikersgegevens
het rijbewijs nummer.

1568
01:08:39,990 --> 01:08:43,620
>> Dus kunnen we tafel van een gebruiker hebben die
heeft een hash-toets op het serienummer,

1569
01:08:43,620 --> 01:08:47,830
of het sofi-nummer, en
verschillende attributen gedefinieerd op het punt.

1570
01:08:47,830 --> 01:08:49,859
Nu op die tafel I
een GSI kon bepalen dat

1571
01:08:49,859 --> 01:08:53,370
flips dat rond die zegt: ik wil
een hash-toets op de vergunning en vervolgens

1572
01:08:53,370 --> 01:08:54,252
alle andere items.

1573
01:08:54,252 --> 01:08:57,210
Nu als ik wil op te vragen en vind de
licentienummer voor een bepaalde sociale

1574
01:08:57,210 --> 01:08:59,609
-Nummer, ik kan
query de hoofdtabel.

1575
01:08:59,609 --> 01:09:02,130
>> Als ik wil vragen en ik wil
aan de sociale zekerheid te krijgen

1576
01:09:02,130 --> 01:09:05,735
nummer of andere kenmerken van een
licentienummer, kan ik query de GSI.

1577
01:09:05,735 --> 01:09:08,689
Dat model is dat men
op een relatie.

1578
01:09:08,689 --> 01:09:12,460
Slechts een zeer eenvoudige GSI,
flip die dingen rond.

1579
01:09:12,460 --> 01:09:13,979
Nu, praten over een te veel.

1580
01:09:13,979 --> 01:09:16,450
Een tot vele fundamenteel
je hash range sleutel.

1581
01:09:16,450 --> 01:09:20,510
Waar we veel met dit
use case is de monitor gegevens.

1582
01:09:20,510 --> 01:09:23,880
Monitor gegevens komen in de reguliere
interval, zoals internet van de dingen.

1583
01:09:23,880 --> 01:09:26,890
We hebben altijd al deze
platen komen hele tijd.

1584
01:09:26,890 --> 01:09:31,420
>> En ik wil alle metingen vinden
tussen een bepaalde tijdsperiode.

1585
01:09:31,420 --> 01:09:34,220
Het is een veel voorkomende vraag in
bewaking infrastructuur.

1586
01:09:34,220 --> 01:09:38,430
De manier te gaan over dat is een vondst
eenvoudige tabel structuur, één tafel.

1587
01:09:38,430 --> 01:09:42,250
Ik heb een tafel metingen apparaat kreeg
met een hekje toets op het apparaat-ID.

1588
01:09:42,250 --> 01:09:47,340
En ik hebben een bereik toets op het
tijdstempel, of in dit geval, de epische.

1589
01:09:47,340 --> 01:09:50,350
En dat maakt me complexe voeren
queries tegen dat bereik sleutel

1590
01:09:50,350 --> 01:09:54,950
en terug te keren records die
zijn ten opzichte van het resultaat

1591
01:09:54,950 --> 01:09:56,310
set die ik zoek.

1592
01:09:56,310 --> 01:09:58,360
En het bouwt dat één
te veel relatie

1593
01:09:58,360 --> 01:10:02,340
in de primaire tabel met de
hash key, range sleutel structuur.

1594
01:10:02,340 --> 01:10:04,600
>> Dus dat is een soort van ingebouwde
in de tabel in Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Toen ik een hash te definiëren
en het bereik t tafel, ik ben

1596
01:10:07,290 --> 01:10:09,240
definieert één tot vele relatie.

1597
01:10:09,240 --> 01:10:12,770
Het is een ouder-kind relatie.

1598
01:10:12,770 --> 01:10:14,620
>> Laten we praten over de vele
te veel relaties.

1599
01:10:14,620 --> 01:10:19,170
En dit specifieke voorbeeld,
nogmaals, we gaan GSI's gebruiken.

1600
01:10:19,170 --> 01:10:23,500
En laten we praten over gaming
scenario waar ik een bepaalde gebruiker.

1601
01:10:23,500 --> 01:10:26,500
Ik wil weten alle games die
hij is ingeschreven voor of spelen in.

1602
01:10:26,500 --> 01:10:29,600
En voor een bepaald spel, I
willen alle gebruikers te vinden.

1603
01:10:29,600 --> 01:10:31,010
Dus hoe kan ik dat doen?

1604
01:10:31,010 --> 01:10:34,330
Mijn gebruiker spelletjes tafel, ik ga
een hash sleutel van gebruikers-ID hebben

1605
01:10:34,330 --> 01:10:35,810
en een reeks sleutel van het spel.

1606
01:10:35,810 --> 01:10:37,810
>> Zo kan een gebruiker meerdere games.

1607
01:10:37,810 --> 01:10:41,380
Het is een te veel relatie tussen
de gebruiker en de games die hij speelt.

1608
01:10:41,380 --> 01:10:43,410
En vervolgens op de GSI,
Ik zal dat ongeveer spiegelen.

1609
01:10:43,410 --> 01:10:46,679
Ik op het spel zullen hash en
Ik zal variëren van de gebruiker.

1610
01:10:46,679 --> 01:10:48,970
Dus als ik wil alle krijgen
de gebruiker het spel spelen in,

1611
01:10:48,970 --> 01:10:49,950
Ik zal de hoofdtabel te vragen.

1612
01:10:49,950 --> 01:10:52,699
Als ik wil alle gebruikers krijgen
die het spelen van een bepaald spel,

1613
01:10:52,699 --> 01:10:53,887
Ik vraag de GSI.

1614
01:10:53,887 --> 01:10:54,970
Zo zie je hoe we dit doen?

1615
01:10:54,970 --> 01:10:58,369
Je bouwt deze GSI aan de ondersteuning
use case, de toepassing, de toegang

1616
01:10:58,369 --> 01:10:59,410
patroon, de toepassing.

1617
01:10:59,410 --> 01:11:01,440
>> Als ik nodig om te vragen op
deze dimensie, laat

1618
01:11:01,440 --> 01:11:03,500
me een index op die dimensie.

1619
01:11:03,500 --> 01:11:05,850
Als ik dat niet doen, kan me niet schelen.

1620
01:11:05,850 --> 01:11:09,060
En afhankelijk van het gebruik case, I
kan de index nodig hebben of ik misschien niet.

1621
01:11:09,060 --> 01:11:12,390
Als het simpel voor velen,
de primaire tabel is prima.

1622
01:11:12,390 --> 01:11:15,860
Als ik moet deze veel te doen om
veel van, of ik moet een tot degenen doen,

1623
01:11:15,860 --> 01:11:18,390
dan misschien ik moet
naar de tweede de index.

1624
01:11:18,390 --> 01:11:20,840
Dus het hangt allemaal af van
wat ik probeer te doen

1625
01:11:20,840 --> 01:11:24,550
en wat ik probeer te krijgen volbracht.

1626
01:11:24,550 --> 01:11:28,000
>> Waarschijnlijk ben ik niet van plan om te besteden
veel tijd aan het praten over de documenten.

1627
01:11:28,000 --> 01:11:31,460
Dit krijgt een beetje, waarschijnlijk,
dieper dan we nodig hebben in te gaan.

1628
01:11:31,460 --> 01:11:33,710
Laten we praten een beetje
over de rijke query-expressie.

1629
01:11:33,710 --> 01:11:37,831
Dus in Dynamo DB hebben we
de mogelijkheid te creëren

1630
01:11:37,831 --> 01:11:39,330
wat wij noemen projectie uitdrukkingen.

1631
01:11:39,330 --> 01:11:42,660
Projectie uitdrukkingen zijn gewoon
plukken van de velden of de waarden

1632
01:11:42,660 --> 01:11:44,290
die u wilt weergeven.

1633
01:11:44,290 --> 01:11:46,000
OK, dus ik maak een selectie.

1634
01:11:46,000 --> 01:11:48,010
Ik maak een query tegen Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
En ik zeg, weet je wat, laten zien
ik alleen de vijf sterren beoordelingen

1636
01:11:51,730 --> 01:11:54,544
voor dit specifieke product.

1637
01:11:54,544 --> 01:11:55,710
Dus dat is alles wat ik wil zien.

1638
01:11:55,710 --> 01:11:57,320
Ik wil niet alle zien
andere kenmerken van de rij,

1639
01:11:57,320 --> 01:11:58,319
Ik wil alleen maar om dit te zien.

1640
01:11:58,319 --> 01:12:01,209
Het is net als wanneer je in SQL
zeggen select ster of van tafel,

1641
01:12:01,209 --> 01:12:02,000
je krijgt alles.

1642
01:12:02,000 --> 01:12:05,450
Als ik zeg select naam uit
tafel, krijg ik slechts één attribuut.

1643
01:12:05,450 --> 01:12:09,070
Het is hetzelfde soort dingen in
Dynamo DB of een andere NoSQL-databases.

1644
01:12:09,070 --> 01:12:14,510
Filter uitdrukkingen laat mij
eigenlijk snijd de vastgelegd resultaat.

1645
01:12:14,510 --> 01:12:15,540
Dus ik maak een query.

1646
01:12:15,540 --> 01:12:17,260
Query kan terugkomen met 500 punten.

1647
01:12:17,260 --> 01:12:20,255
Maar ik wil alleen de items die
een eigenschap die dit zegt.

1648
01:12:20,255 --> 01:12:23,380
OK, dus laten filteren die items
die niet overeenkomt met die bepaalde query.

1649
01:12:23,380 --> 01:12:25,540
Dus hebben we filter uitdrukkingen.

1650
01:12:25,540 --> 01:12:28,310
>> Filter uitdrukkingen kan
worden op elke attribuut.

1651
01:12:28,310 --> 01:12:30,260
Ze zijn niet zoals range queries.

1652
01:12:30,260 --> 01:12:32,690
Raise vragen zijn meer selectief.

1653
01:12:32,690 --> 01:12:36,470
Queries filter nodig mij om te gaan
krijgen de volledige resultaten te stellen en vervolgens

1654
01:12:36,470 --> 01:12:39,170
carve out de gegevens die ik niet wil.

1655
01:12:39,170 --> 01:12:40,660
Waarom is dat belangrijk?

1656
01:12:40,660 --> 01:12:42,770
Want ik lees het allemaal.

1657
01:12:42,770 --> 01:12:46,597
In een query, ik ga lezen en
het gaat om een ​​gigantische over gegevens.

1658
01:12:46,597 --> 01:12:48,430
En dan ga ik
carve out wat ik nodig heb.

1659
01:12:48,430 --> 01:12:52,080
En als ik ben alleen uithakken van een
paar rijen, dan is dat OK.

1660
01:12:52,080 --> 01:12:53,620
Het is niet zo inefficiënt.

1661
01:12:53,620 --> 01:12:57,800
>> Maar als ik het lezen van een hele stapel
data, maar om uit te spitten een item,

1662
01:12:57,800 --> 01:13:01,490
dan ga ik beter
uit met een reeks vragen,

1663
01:13:01,490 --> 01:13:03,030
want het is veel selectiever.

1664
01:13:03,030 --> 01:13:06,330
Het gaat me een hoop
geld, want ik betaal voor die lezen.

1665
01:13:06,330 --> 01:13:10,430
Wanneer de resultaten die terugkomt
kruisen die draad kleiner zou kunnen zijn,

1666
01:13:10,430 --> 01:13:11,890
maar ik ben te betalen voor de gelezen.

1667
01:13:11,890 --> 01:13:14,340
Dus begrijpen hoe
je krijgt de gegevens.

1668
01:13:14,340 --> 01:13:16,420
Dat is heel belangrijk in Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Voorwaardelijke uitdrukkingen, dit is wat
je zou optimistische vergrendeling noemen.

1670
01:13:19,710 --> 01:13:28,470
Update als deze bestaat, of als deze waarde
is gelijk aan wat ik opgeven.

1671
01:13:28,470 --> 01:13:31,494
En als ik een tijd stempel op een
record, zou ik de gegevens te lezen.

1672
01:13:31,494 --> 01:13:32,535
Ik zou die gegevens veranderen.

1673
01:13:32,535 --> 01:13:35,030
Ik zou kunnen gaan schrijven dat
data terug naar de database.

1674
01:13:35,030 --> 01:13:38,100
Als iemand heeft veranderd het record,
de tijdstempel zou hebben veranderd.

1675
01:13:38,100 --> 01:13:40,370
En op die manier mijn voorwaardelijke
-update-update kon zeggen

1676
01:13:40,370 --> 01:13:42,340
Als de tijdstempel gelijk aan deze.

1677
01:13:42,340 --> 01:13:46,290
Of de update zal mislukken omdat iemand
bijgewerkt het record in de tussentijd.

1678
01:13:46,290 --> 01:13:48,290
>> Dat is wat we optimistische vergrendeling noemen.

1679
01:13:48,290 --> 01:13:50,670
Dit betekent dat iemand
kunnen komen en het veranderen,

1680
01:13:50,670 --> 01:13:53,100
en ik ga om het te ontdekken
toen ik terug te gaan om te schrijven.

1681
01:13:53,100 --> 01:13:56,106
En dan kan ik eigenlijk lezen dat
data en zeggen: oh, dit veranderde hij.

1682
01:13:56,106 --> 01:13:57,230
Ik moet verklaren dat.

1683
01:13:57,230 --> 01:14:00,490
En ik kan de gegevens in te wijzigen mijn
opnemen en een andere update.

1684
01:14:00,490 --> 01:14:04,330
Dus je kunt deze incrementele vangen
updates die zich voordoen tussen het tijdstip

1685
01:14:04,330 --> 01:14:08,740
dat u de data en het lezen
keer dat u misschien de gegevens te schrijven.

1686
01:14:08,740 --> 01:14:11,520
>> Publiek: En de filter
uitdrukking betekent eigenlijk niet

1687
01:14:11,520 --> 01:14:13,020
van het aantal of niet--

1688
01:14:13,020 --> 01:14:14,316
>> [Onderbreekt hem VOICES]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: Ik zal niet
krijgen te veel in deze.

1690
01:14:16,232 --> 01:14:17,700
Dit is een gereserveerde trefwoord.

1691
01:14:17,700 --> 01:14:20,130
Het pond view is een gereserveerde
zoekwoord in Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Elke databank heeft zijn eigen gereserveerde
namen voor verzamelingen je niet kunt gebruiken.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, als u opgeeft
een pond tegenover dit,

1694
01:14:27,240 --> 01:14:29,310
kunt u die namen hierboven definiëren maximaal.

1695
01:14:29,310 --> 01:14:31,840
Dit is een referentie waarde.

1696
01:14:31,840 --> 01:14:34,880
Het is waarschijnlijk niet de beste syntaxis
hebben er voor deze discussie,

1697
01:14:34,880 --> 01:14:38,090
want het wordt in sommige real--
Ik heb gesproken meer

1698
01:14:38,090 --> 01:14:41,360
daarover op een dieper niveau.

1699
01:14:41,360 --> 01:14:46,130
>> Maar volstaat te zeggen, deze kan
zijn vraag scan waar ze views--

1700
01:14:46,130 --> 01:14:50,190
noch uitzicht pond groter is dan 10.

1701
01:14:50,190 --> 01:14:54,660
Het is een numerieke waarde, ja.

1702
01:14:54,660 --> 01:14:57,322
Als u wilt, kunnen we praten over
dat na de discussie.

1703
01:14:57,322 --> 01:15:00,030
Oké, dus we krijgen in
sommige scenario's in de beste praktijken

1704
01:15:00,030 --> 01:15:02,000
waar we heen gaan praten
over een aantal apps hier.

1705
01:15:02,000 --> 01:15:03,810
Wat zijn de use cases voor Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Wat zijn het ontwerp
patronen in Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> En de eerste die we gaan
praten over het internet van de dingen.

1708
01:15:09,110 --> 01:15:15,010
Zo krijgen we een veel van-- denk ik,
wat het-- meer dan 50%

1709
01:15:15,010 --> 01:15:19,370
van het verkeer op het internet deze dagen
eigenlijk gegenereerd door machines,

1710
01:15:19,370 --> 01:15:21,930
geautomatiseerde processen, niet door de mens.

1711
01:15:21,930 --> 01:15:25,140
Ik bedoel, dit ding dit ding dat
u rond in uw zak,

1712
01:15:25,140 --> 01:15:28,840
hoeveel gegevens dat dat ding is
eigenlijk het verzenden van rond zonder jou

1713
01:15:28,840 --> 01:15:30,550
wetende dat het is absoluut geweldig.

1714
01:15:30,550 --> 01:15:34,970
Uw locatie, informatie
over hoe snel je gaat.

1715
01:15:34,970 --> 01:15:38,400
Hoe denk je dat Google Maps werken
als ze je vertellen wat het verkeer is.

1716
01:15:38,400 --> 01:15:41,275
Het is omdat er miljoenen en
miljoenen mensen rondrijden

1717
01:15:41,275 --> 01:15:44,667
met telefoons die sturen
gegevens over de hele tijd plaats.

1718
01:15:44,667 --> 01:15:46,500
Dus een van de dingen
dit soort gegevens

1719
01:15:46,500 --> 01:15:50,980
die wordt geleverd in, monitoren gegevens, log
gegevens, tijdreeksen, is het

1720
01:15:50,980 --> 01:15:53,540
meestal alleen interessant
voor een beetje tijd.

1721
01:15:53,540 --> 01:15:55,580
Na die tijd, het is
niet zo interessant.

1722
01:15:55,580 --> 01:15:58,390
Dus spraken we over, laat
die tabellen groeien zonder grenzen.

1723
01:15:58,390 --> 01:16:03,410
Het idee hier is dat misschien heb ik 24
uur aan de gebeurtenissen in mijn hete tafel.

1724
01:16:03,410 --> 01:16:06,160
En dat heet tafel gaat worden
bevoorraad op een zeer hoog tempo,

1725
01:16:06,160 --> 01:16:07,950
omdat het nemen van een veel gegevens.

1726
01:16:07,950 --> 01:16:10,920
Het nemen van een veel gegevens
in en ik lees het een stuk.

1727
01:16:10,920 --> 01:16:14,560
Ik heb veel van de operatie kreeg
query's tegen deze data.

1728
01:16:14,560 --> 01:16:18,120
>> Na 24 uur, hey, je
Weet je wat, kan me niet schelen.

1729
01:16:18,120 --> 01:16:21,150
Dus misschien elke middernacht Ik roll
mijn tafel over naar een nieuwe tabel

1730
01:16:21,150 --> 01:16:22,430
en ik deprovision deze tabel.

1731
01:16:22,430 --> 01:16:26,440
En ik neem de afstandsbediening en
WCU's neer, omdat 24 uur later

1732
01:16:26,440 --> 01:16:28,630
Ik ben niet actief als veel
query's die gegevens.

1733
01:16:28,630 --> 01:16:30,200
Dus ik ga om geld te besparen.

1734
01:16:30,200 --> 01:16:32,940
En misschien 30 dagen later heb ik niet
zelfs zorgen te maken over dit alles.

1735
01:16:32,940 --> 01:16:35,020
Ik kon nemen van de WCU's
helemaal naar beneden naar een,

1736
01:16:35,020 --> 01:16:36,990
omdat je weet wat het is
nooit gaat krijgen geschreven.

1737
01:16:36,990 --> 01:16:38,300
De gegevens zijn 30 dagen oud.

1738
01:16:38,300 --> 01:16:40,000
Het verandert nooit.

1739
01:16:40,000 --> 01:16:44,200
>> En het is bijna nooit gaat krijgen lezen,
dus laten we gewoon dat RCU tot 10.

1740
01:16:44,200 --> 01:16:49,372
En ik ben aan het sparen een hoop geld op deze
data, en alleen betalen voor mijn hete data.

1741
01:16:49,372 --> 01:16:52,330
Dus dat is het belangrijkste om te kijken
op als je kijkt naar een tijdreeks

1742
01:16:52,330 --> 01:16:54,716
binnenkomende data volume.

1743
01:16:54,716 --> 01:16:55,590
Deze strategieën zijn.

1744
01:16:55,590 --> 01:16:58,010
Nu, ik kon gewoon laten
gaan allemaal naar dezelfde tafel

1745
01:16:58,010 --> 01:16:59,461
en laat die tafel groeien.

1746
01:16:59,461 --> 01:17:01,460
Uiteindelijk ga ik
Zie problemen met de prestaties.

1747
01:17:01,460 --> 01:17:04,060
Ik ga moeten beginnen te archiveren
sommige van die gegevens van de tafel,

1748
01:17:04,060 --> 01:17:04,720
wat niet.

1749
01:17:04,720 --> 01:17:07,010
>> Laten we veel beter
ontwerp uw aanvraag

1750
01:17:07,010 --> 01:17:08,900
zodat u kunt op deze manier recht te bedienen.

1751
01:17:08,900 --> 01:17:11,460
Dus het is gewoon automatisch
in de applicatie code.

1752
01:17:11,460 --> 01:17:13,580
Om middernacht elke nacht
rolt de tafel.

1753
01:17:13,580 --> 01:17:17,170
Misschien wat ik nodig heb is een glijdende
raam van 24 uur aan gegevens.

1754
01:17:17,170 --> 01:17:20,277
Vervolgens regelmatig ik
roepen gegevens van de tafel.

1755
01:17:20,277 --> 01:17:22,360
Ik ben het trimmen met een
Cron job en ik zetten het

1756
01:17:22,360 --> 01:17:24,160
naar deze andere tafels,
wat je nodig hebt.

1757
01:17:24,160 --> 01:17:25,940
Dus als een rollover werkt, dat is geweldig.

1758
01:17:25,940 --> 01:17:27,080
Zo niet, trim het.

1759
01:17:27,080 --> 01:17:29,640
Maar laten we dat heet data
weg van uw koude gegevens.

1760
01:17:29,640 --> 01:17:32,535
Het zal bespaart u een hoop geld en
maak uw tafels meer uitvoeren.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Dus het volgende wat we praten
over is productcatalogus.

1763
01:17:38,210 --> 01:17:42,000
Productcatalogus is
vrij gebruikelijk use case.

1764
01:17:42,000 --> 01:17:46,600
Dit is eigenlijk een veel voorkomende patroon
dat we zullen zien in een verscheidenheid van dingen.

1765
01:17:46,600 --> 01:17:48,870
Je weet wel, Twitter voor
Bijvoorbeeld, een hot tweet.

1766
01:17:48,870 --> 01:17:51,280
Iedereen komt en
grijpen die tweet.

1767
01:17:51,280 --> 01:17:52,680
Productcatalogus, kreeg ik een verkoop.

1768
01:17:52,680 --> 01:17:54,120
Ik heb een hete verkoop.

1769
01:17:54,120 --> 01:17:57,277
Ik kreeg 70.000 aanvragen per
wederkomst voor een product

1770
01:17:57,277 --> 01:17:58,860
beschrijving van mijn product catalogus.

1771
01:17:58,860 --> 01:18:02,384
We zien dit op de retail
operatie nogal wat.

1772
01:18:02,384 --> 01:18:03,550
Dus hoe kunnen we gaan met dat?

1773
01:18:03,550 --> 01:18:04,924
Er is geen manier om te gaan met dat.

1774
01:18:04,924 --> 01:18:07,110
Al mijn gebruikers willen zien
hetzelfde stuk van de gegevens.

1775
01:18:07,110 --> 01:18:09,410
Ze komen binnen, gelijktijdig.

1776
01:18:09,410 --> 01:18:11,920
En ze zijn allemaal het maken van verzoeken
voor hetzelfde stuk van de gegevens.

1777
01:18:11,920 --> 01:18:16,240
Dit geeft mij dat sneltoets, die grote rode
streep op mijn kaart die we niet willen.

1778
01:18:16,240 --> 01:18:17,720
En dat is wat die lijkt.

1779
01:18:17,720 --> 01:18:22,290
Dus over mijn sleutel ruimte Ik krijg
gehamerd op de verkoop items.

1780
01:18:22,290 --> 01:18:24,070
Ik krijg niets ergens anders.

1781
01:18:24,070 --> 01:18:26,050
>> Hoe kan ik dit probleem te verlichten?

1782
01:18:26,050 --> 01:18:28,410
Nou, we deze te verlichten met cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, in principe een zet je in-memory
verdeling voor de database.

1784
01:18:33,630 --> 01:18:37,260
We zijn erin geslaagd
[Onhoorbaar] cache, hoe je

1785
01:18:37,260 --> 01:18:40,260
kunt uw eigen cache, [onverstaanbaar]
cache [? d,?] wat je wilt.

1786
01:18:40,260 --> 01:18:42,220
Zet dat aan de voorkant van de gegevensbank.

1787
01:18:42,220 --> 01:18:47,250
En op die manier kunt u die gegevens op te slaan
van die sneltoetsen in die cache

1788
01:18:47,250 --> 01:18:49,390
ruimte en lezen via de cache.

1789
01:18:49,390 --> 01:18:51,962
>> En dan de meeste van uw leest
gaan kijken als deze.

1790
01:18:51,962 --> 01:18:54,920
Ik heb al deze cache raakt hier
en ik heb niets aan de hand hier beneden

1791
01:18:54,920 --> 01:18:59,330
omdat de database zit achter de
cache en het leest nooit door.

1792
01:18:59,330 --> 01:19:02,520
Als ik de gegevens in het veranderen
databank, moet ik de cache bij te werken.

1793
01:19:02,520 --> 01:19:04,360
We kunnen iets te gebruiken
zoals stoomt om dat te doen.

1794
01:19:04,360 --> 01:19:07,360
En ik zal uitleggen hoe dat werkt.

1795
01:19:07,360 --> 01:19:09,060
Oké, messaging.

1796
01:19:09,060 --> 01:19:11,180
E-mail, we allemaal gebruik van e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> Dit is een vrij goed voorbeeld.

1798
01:19:12,540 --> 01:19:14,950
We hebben een soort van berichten tafel.

1799
01:19:14,950 --> 01:19:17,040
En we kregen inbox en outbox.

1800
01:19:17,040 --> 01:19:19,760
Dit is wat de SQL zou
kijk graag dat inbox te bouwen.

1801
01:19:19,760 --> 01:19:23,350
We soort gebruiken dezelfde soort
van de strategie om de GSI's, gebruik maken van GSI's

1802
01:19:23,350 --> 01:19:25,320
voor mijn inbox en mijn outbox.

1803
01:19:25,320 --> 01:19:27,600
Dus ik heb ruwe berichten komen
in mijn boodschappen tafel.

1804
01:19:27,600 --> 01:19:30,194
De eerste benadering van dit
zou kunnen zijn, zeggen: OK, geen probleem.

1805
01:19:30,194 --> 01:19:31,110
Ik heb rauwe berichten gekregen.

1806
01:19:31,110 --> 01:19:33,710
Berichten komen [onhoorbaar]
bericht ID, dat is geweldig.

1807
01:19:33,710 --> 01:19:35,070
Dat is mijn unieke hash.

1808
01:19:35,070 --> 01:19:38,280
Ik ga maken twee GSI's, een
voor mijn inbox, één voor mijn outbox.

1809
01:19:38,280 --> 01:19:40,530
En het eerste wat ik doe
is Ik zal zeggen dat mijn hekje is

1810
01:19:40,530 --> 01:19:43,310
naar de ontvanger en
Ik ga om te regelen op de dag.

1811
01:19:43,310 --> 01:19:44,220
Dit is fantastisch.

1812
01:19:44,220 --> 01:19:45,890
Ik heb mijn mooi uitzicht hier.

1813
01:19:45,890 --> 01:19:47,780
Maar er is hier een klein probleem.

1814
01:19:47,780 --> 01:19:50,891
En je in deze in
relationele databases ook.

1815
01:19:50,891 --> 01:19:52,390
Ze noemden verticaal partitionering.

1816
01:19:52,390 --> 01:19:55,840
U wilt uw big data te houden
weg van uw weinig gegevens.

1817
01:19:55,840 --> 01:20:00,470
>> En de reden waarom is omdat ik moet
lees dan de items om de kenmerken te krijgen.

1818
01:20:00,470 --> 01:20:05,570
En als mijn lichaam zijn allemaal hier,
dan is het lezen van een paar artikelen

1819
01:20:05,570 --> 01:20:08,560
als mijn lichaam lengte is
gemiddeld 256 kilobytes per,

1820
01:20:08,560 --> 01:20:10,991
de wiskunde wordt behoorlijk lelijk.

1821
01:20:10,991 --> 01:20:12,490
Zo zeg ik wil Davids inbox lezen.

1822
01:20:12,490 --> 01:20:14,520
David's inbox heeft 50 items.

1823
01:20:14,520 --> 01:20:17,880
De gemiddelde en de grootte is 256 kilobytes.

1824
01:20:17,880 --> 01:20:21,730
Hier is mijn conversie ratio
voor RCU is vier kilobytes.

1825
01:20:21,730 --> 01:20:24,450
>> Oké, laten we gaan met
uiteindelijk consistente leest.

1826
01:20:24,450 --> 01:20:28,640
Ik ben nog steeds het eten van 1600 RCU's
alleen maar om David's inbox lezen.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
OK, laten we nu denken
over hoe de app werkt.

1829
01:20:31,980 --> 01:20:35,340
Als ik in een e-mail app en
Ik kijk naar mijn inbox,

1830
01:20:35,340 --> 01:20:39,680
en ik kijk naar het lichaam van elk bericht,
nee, ik ben op zoek naar de samenvattingen.

1831
01:20:39,680 --> 01:20:41,850
Ik ben op zoek naar alleen de headers.

1832
01:20:41,850 --> 01:20:46,310
Dus laten we bouwen aan een tafel structuur
dat lijkt meer op dat.

1833
01:20:46,310 --> 01:20:49,470
>> Dus hier is de informatie
dat mijn workflow nodig.

1834
01:20:49,470 --> 01:20:50,890
Het is in mijn inbox GSI.

1835
01:20:50,890 --> 01:20:53,800
Het is de datum, de afzender,
het onderwerp, en dan

1836
01:20:53,800 --> 01:20:56,790
de boodschap ID, die wijst
terug naar de tafel berichten

1837
01:20:56,790 --> 01:20:57,850
waar ik kan het lichaam te krijgen.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Nou, dit zou opnemen ID's.

1840
01:21:04,420 --> 01:21:09,850
Ze wijst naar de
Item-id's op het Dynamo DB tafel.

1841
01:21:09,850 --> 01:21:12,220
Elke index altijd creates--
altijd het artikel

1842
01:21:12,220 --> 01:21:15,750
ID als onderdeel van-- dat
wordt geleverd met de index.

1843
01:21:15,750 --> 01:21:17,414
>> Prima.

1844
01:21:17,414 --> 01:21:19,080
Publiek: Het vertelt het waar het is opgeslagen?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Ja, het vertelt
exactly-- dat is precies wat het doet.

1846
01:21:21,420 --> 01:21:22,644
Het zegt hier is mijn re record.

1847
01:21:22,644 --> 01:21:24,310
En het zal het punt terug naar mijn re record.

1848
01:21:24,310 --> 01:21:26,460
Precies.

1849
01:21:26,460 --> 01:21:29,490
OK, dus nu mijn inbox is
eigenlijk veel kleiner.

1850
01:21:29,490 --> 01:21:32,210
En dit ook daadwerkelijk ondersteunt
de workflow van een e-app.

1851
01:21:32,210 --> 01:21:34,230
Dus mijn inbox, ik klik.

1852
01:21:34,230 --> 01:21:38,160
Ik ga mee en ik klik op het bericht,
dat is wanneer ik moet gaan krijgen van het lichaam,

1853
01:21:38,160 --> 01:21:40,180
want ik ga
ga dan naar een andere mening toegedaan.

1854
01:21:40,180 --> 01:21:43,870
Dus als je nadenkt over MVC type
kader, model view controller.

1855
01:21:43,870 --> 01:21:46,120
>> Het model bevat de
gegevens die de behoeften view

1856
01:21:46,120 --> 01:21:48,130
en de controller samenwerkt met.

1857
01:21:48,130 --> 01:21:51,670
Toen ik het frame veranderen, wanneer
Ik verander het perspectief,

1858
01:21:51,670 --> 01:21:55,080
het is OK om terug te gaan naar de
server en herbevolken van het model,

1859
01:21:55,080 --> 01:21:56,860
want dat is wat de gebruiker verwacht.

1860
01:21:56,860 --> 01:22:00,530
Wanneer ze veranderen uitzicht, dat is wanneer
we terug naar de database te kunnen gaan.

1861
01:22:00,530 --> 01:22:02,480
Dus e-mail, klikt u op.

1862
01:22:02,480 --> 01:22:03,710
Ik ben op zoek naar het lichaam.

1863
01:22:03,710 --> 01:22:04,330
Rondvaart.

1864
01:22:04,330 --> 01:22:05,680
Haal het lichaam.

1865
01:22:05,680 --> 01:22:06,950
>> Ik lees veel minder gegevens.

1866
01:22:06,950 --> 01:22:09,960
Ik ben alleen het lezen van de instanties die
David heeft toen hij ze nodig heeft.

1867
01:22:09,960 --> 01:22:14,230
En ik ben niet branden in 1600
RCU's alleen maar om zijn inbox zien.

1868
01:22:14,230 --> 01:22:17,670
Dus nu dat-- dit is de manier
dat LSI of GSI-- Het spijt me,

1869
01:22:17,670 --> 01:22:19,900
GSI, zou werken.

1870
01:22:19,900 --> 01:22:25,450
We hebben onze hash op de ontvanger.

1871
01:22:25,450 --> 01:22:27,030
We hebben het bereik toets op de datum.

1872
01:22:27,030 --> 01:22:31,380
En we hebben de verwachte attributen gekregen
dat we alleen om de weergave te ondersteunen.

1873
01:22:31,380 --> 01:22:34,300
>> We draaien dat de outbox.

1874
01:22:34,300 --> 01:22:35,770
Hash op afzender.

1875
01:22:35,770 --> 01:22:39,612
En in wezen we
de zeer mooi, schoon uitzicht.

1876
01:22:39,612 --> 01:22:41,570
En het is basically-- we
hebben deze mooie berichten

1877
01:22:41,570 --> 01:22:45,870
tabel die wordt mooi omdat er verspreid
het is alleen hash, hash bericht ID.

1878
01:22:45,870 --> 01:22:51,750
En we hebben twee indexen die
roteren off van die tabel.

1879
01:22:51,750 --> 01:22:57,411
Oké, dus idee hier is dat niet
houd de big data en dit kleine data

1880
01:22:57,411 --> 01:22:57,910
samen.

1881
01:22:57,910 --> 01:23:00,700
Partitie verticaal
partitie die tabellen.

1882
01:23:00,700 --> 01:23:03,150
Geen gegevens niet lezen je niet hoeft te doen.

1883
01:23:03,150 --> 01:23:04,850
Oké, gaming.

1884
01:23:04,850 --> 01:23:06,990
We allemaal graag spelen.

1885
01:23:06,990 --> 01:23:10,902
Tenminste ik graag spelen toen.

1886
01:23:10,902 --> 01:23:12,735
Dus sommige van de dingen
dat we omgaan met wanneer

1887
01:23:12,735 --> 01:23:14,193
we denken over gaming, toch?

1888
01:23:14,193 --> 01:23:16,999
Gaming deze dagen, met name mobiele
gaming, is alles over denken.

1889
01:23:16,999 --> 01:23:19,540
En ik ga hier een roteren
beetje uit de buurt van DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Ik ga in te brengen
enkele discussie

1891
01:23:21,373 --> 01:23:24,240
rond sommige
AWS andere technologieën.

1892
01:23:24,240 --> 01:23:28,930
>> Maar het idee over gaming is om na te denken
over in termen van API's, API's die zijn,

1893
01:23:28,930 --> 01:23:31,730
in het algemeen, HTTP en JSON.

1894
01:23:31,730 --> 01:23:34,550
Het is hoe mobiele games soort
interactie met hun achtereinden.

1895
01:23:34,550 --> 01:23:35,850
Ze doen JSON posting.

1896
01:23:35,850 --> 01:23:40,660
Ze krijgen van gegevens, en het is allemaal,
in het algemeen, in een mooie JSON API's.

1897
01:23:40,660 --> 01:23:44,950
>> Dingen zoals krijgen vrienden, krijgen
het leaderboard, uitwisseling van gegevens,

1898
01:23:44,950 --> 01:23:47,699
door gebruikers gegenereerde inhoud,
terugzet naar het systeem,

1899
01:23:47,699 --> 01:23:49,740
deze zijn soort dingen
dat we gaan doen.

1900
01:23:49,740 --> 01:23:52,542
Binaire troef data, deze data
misschien niet zitten in de database.

1901
01:23:52,542 --> 01:23:54,250
Dit kan in een zitten
object op te slaan, toch?

1902
01:23:54,250 --> 01:23:56,541
Maar de database gaat
uiteindelijk vertellen het systeem,

1903
01:23:56,541 --> 01:23:59,140
het vertellen van de applicatie
waar te gaan krijgen.

1904
01:23:59,140 --> 01:24:03,550
En onvermijdelijk, multiplayer
servers, back-end infrastructuur,

1905
01:24:03,550 --> 01:24:06,180
en ontworpen voor hoge
beschikbaarheid en schaalbaarheid.

1906
01:24:06,180 --> 01:24:09,400
Dus dit zijn dingen die we allemaal willen
in de gaming-infrastructuur vandaag.

1907
01:24:09,400 --> 01:24:12,160
>> Dus laten we een kijkje nemen op
hoe dat eruit ziet.

1908
01:24:12,160 --> 01:24:16,070
Kreeg een kern back-end,
zeer eenvoudig.

1909
01:24:16,070 --> 01:24:19,880
We hebben een systeem heb hier met
meerdere beschikbaarheid zones.

1910
01:24:19,880 --> 01:24:23,780
We spraken over AZS als being-- denken
van hen als aparte datacenters.

1911
01:24:23,780 --> 01:24:26,040
Meer dan een datacenter
per AZ, maar dat is OK,

1912
01:24:26,040 --> 01:24:28,831
denk maar aan hen als afzonderlijke gegevens
centra die geografisch

1913
01:24:28,831 --> 01:24:30,090
en storingen geïsoleerd.

1914
01:24:30,090 --> 01:24:32,172
>> We gaan naar een hebben
paar EC2 gevallen.

1915
01:24:32,172 --> 01:24:33,880
We gaan te hebben
sommige back-end server.

1916
01:24:33,880 --> 01:24:35,800
Misschien als je een erfenis
architectuur, we zijn

1917
01:24:35,800 --> 01:24:38,920
met behulp van wat we RDS noemen,
relationele database services.

1918
01:24:38,920 --> 01:24:42,040
Zou kunnen zijn MSSQL, MySQL,
of zoiets.

1919
01:24:42,040 --> 01:24:47,080
Dit is zo veel toepassingen
zijn ontworpen vandaag.

1920
01:24:47,080 --> 01:24:49,594
>> Goed we zouden willen gaan met
dit is wanneer we schaal uit.

1921
01:24:49,594 --> 01:24:51,510
We zullen verder gaan en zet
de S3 emmer daar.

1922
01:24:51,510 --> 01:24:54,200
En dat S3 emmer, in plaats van het dienen
up die objecten uit onze servers--

1923
01:24:54,200 --> 01:24:55,220
we dat konden doen.

1924
01:24:55,220 --> 01:24:57,210
Je al je binaire
objecten op uw servers

1925
01:24:57,210 --> 01:24:59,751
en u kunt deze server gebruiken
instanties die gegevens up dienen.

1926
01:24:59,751 --> 01:25:01,860
Maar dat is vrij duur.

1927
01:25:01,860 --> 01:25:05,107
>> Betere manier om te doen is ga je gang en
zet de objecten in een S3 emmer.

1928
01:25:05,107 --> 01:25:06,315
S3 is een object repositories.

1929
01:25:06,315 --> 01:25:10,860
Het is speciaal gebouwd voor
waar je van dit soort dingen.

1930
01:25:10,860 --> 01:25:13,690
En laat die cliënten te vragen
rechtstreeks vanuit die voorwerp emmers,

1931
01:25:13,690 --> 01:25:15,390
offload de servers.

1932
01:25:15,390 --> 01:25:17,020
Dus we beginnen hier te schalen.

1933
01:25:17,020 --> 01:25:19,140
>> Nu kregen we gebruikers over de hele wereld.

1934
01:25:19,140 --> 01:25:19,730
Ik heb gebruikers.

1935
01:25:19,730 --> 01:25:23,380
Ik moet de inhoud lokaal hebben
dicht bij deze gebruikers, toch?

1936
01:25:23,380 --> 01:25:26,200
Ik heb een S3 emmer gemaakt
zoals mijn bron repository.

1937
01:25:26,200 --> 01:25:29,370
En ik zal dat met de voorzijde
de CloudFront distributie.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront is een cd en een
content delivery network.

1939
01:25:31,720 --> 01:25:35,750
In principe de gegevens die u opgeeft neemt
en slaat het allemaal via internet

1940
01:25:35,750 --> 01:25:39,230
zodat gebruikers overal kunnen hebben
een zeer snelle reactie bij

1941
01:25:39,230 --> 01:25:40,960
zij verzoeken die objecten.

1942
01:25:40,960 --> 01:25:41,960
>> Zo krijg je een idee.

1943
01:25:41,960 --> 01:25:48,230
Je soort hefboomwerking alle
aspecten van AWS hier om dit gedaan.

1944
01:25:48,230 --> 01:25:50,790
En uiteindelijk, we gooien
in een automatische schaling groep.

1945
01:25:50,790 --> 01:25:52,737
Dus onze AC2 gevallen
van onze game servers,

1946
01:25:52,737 --> 01:25:54,820
als ze beginnen te krijgen drukker
en drukker en drukker,

1947
01:25:54,820 --> 01:25:57,236
zullen ze gewoon een andere spin-
Zo draaien een ander voorbeeld,

1948
01:25:57,236 --> 01:25:58,210
draaien een ander voorbeeld.

1949
01:25:58,210 --> 01:26:02,090
Dus de techniek AWS heeft het
kunt u de parameters opgeven

1950
01:26:02,090 --> 01:26:04,650
waarrond uw servers zal groeien.

1951
01:26:04,650 --> 01:26:08,110
Dus je kunt n aantal servers
er op een bepaald moment.

1952
01:26:08,110 --> 01:26:11,870
En als uw lading weg gaat, zullen ze
krimpt, zal het aantal krimpen.

1953
01:26:11,870 --> 01:26:15,250
Als de belasting terugkomt,
het zal weer groeien, elastisch.

1954
01:26:15,250 --> 01:26:17,050
>> Dus dit ziet er geweldig uit.

1955
01:26:17,050 --> 01:26:19,800
We hebben veel van EC2 gevallen.

1956
01:26:19,800 --> 01:26:21,671
We kunnen cache zetten in
voorzijde van de databases,

1957
01:26:21,671 --> 01:26:23,045
proberen en versnellen van de databases.

1958
01:26:23,045 --> 01:26:25,030
De volgende drukpunt
meestal mensen zien

1959
01:26:25,030 --> 01:26:28,850
is deze schaal een spel met behulp van een
relationeel databanksysteem.

1960
01:26:28,850 --> 01:26:30,790
Jeez, de database
prestaties is verschrikkelijk.

1961
01:26:30,790 --> 01:26:31,932
Hoe kunnen we dat verbeteren?

1962
01:26:31,932 --> 01:26:33,640
Laten we eens proberen
cache in de voorkant van dat.

1963
01:26:33,640 --> 01:26:36,780
>> Nou, cache werkt niet
zo groot in games, toch?

1964
01:26:36,780 --> 01:26:39,330
Voor games, schrijven is pijnlijk.

1965
01:26:39,330 --> 01:26:40,930
Games zijn zeer zwaar te schrijven.

1966
01:26:40,930 --> 01:26:43,610
Cache werkt niet als je
schrijf zwaar want je hebt altijd

1967
01:26:43,610 --> 01:26:44,610
kreeg om de cache te werken.

1968
01:26:44,610 --> 01:26:47,780
U het actualiseren van de cache, het is
irrelevant te cachen.

1969
01:26:47,780 --> 01:26:49,780
Het is eigenlijk gewoon extra werk.

1970
01:26:49,780 --> 01:26:51,970
>> Dus waar we hier gaan?

1971
01:26:51,970 --> 01:26:54,400
Je hebt een grote bottleneck gekregen
beneden in de database.

1972
01:26:54,400 --> 01:26:57,661
En de plek om te gaan
uiteraard is partitioneren.

1973
01:26:57,661 --> 01:26:59,410
Partitioneren is niet
makkelijk te doen als je

1974
01:26:59,410 --> 01:27:01,900
omgaan met relationele databases.

1975
01:27:01,900 --> 01:27:05,080
Met relationele databases, je bent
verantwoordelijk voor het beheer, effectief

1976
01:27:05,080 --> 01:27:06,210
de sleutel ruimte.

1977
01:27:06,210 --> 01:27:10,527
Je zegt dat gebruikers tussen A en M
ga hier, tussen N en Z gaan daar.

1978
01:27:10,527 --> 01:27:12,360
En je overschakelen
over de toepassing.

1979
01:27:12,360 --> 01:27:15,000
Dus je mee bezig bent
deze partitie gegevensbron.

1980
01:27:15,000 --> 01:27:18,670
Je hebt transactionele beperkingen
die geen partities overspannen.

1981
01:27:18,670 --> 01:27:20,560
Je hebt allerlei gekregen
messiness dat je

1982
01:27:20,560 --> 01:27:23,040
omgaan met daar beneden proberen
om te gaan met scaling out

1983
01:27:23,040 --> 01:27:25,120
en opbouwen van een grotere infrastructuur.

1984
01:27:25,120 --> 01:27:27,284
Het is gewoon niet leuk.

1985
01:27:27,284 --> 01:27:30,930
>> Publiek: Dus zeg je dat
toenemende bron punten versnelt

1986
01:27:30,930 --> 01:27:31,430
het proces?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Verhoging?

1988
01:27:32,513 --> 01:27:33,520
PUBLIEK: Source punten.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Source punten?

1990
01:27:34,410 --> 01:27:37,500
Publiek: Uit de informatie,
waar de informatie vandaan komt?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: No.

1992
01:27:38,250 --> 01:27:41,820
Wat ik wil zeggen is het verhogen van de
aantal partities in de gegevens op te slaan

1993
01:27:41,820 --> 01:27:44,060
verbetert de doorvoer.

1994
01:27:44,060 --> 01:27:48,300
Dus wat hier gebeurt is gebruikers
komen in de EC2 bijvoorbeeld hier,

1995
01:27:48,300 --> 01:27:50,780
goed, als ik een gebruikersnaam
Dat is een aan M, zal ik hier te gaan.

1996
01:27:50,780 --> 01:27:53,560
Van N naar p, zal ik hier te gaan.

1997
01:27:53,560 --> 01:27:55,060
Van P tot Z, zal ik hier te gaan.

1998
01:27:55,060 --> 01:27:57,120
>> Publiek: OK, degenen dus die zijn
allemaal opgeslagen in verschillende knooppunten?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Ja.

2000
01:27:57,911 --> 01:28:00,210
Denk aan deze als
verschillende silo's van gegevens.

2001
01:28:00,210 --> 01:28:01,660
Dus je hoeft te doen.

2002
01:28:01,660 --> 01:28:02,910
Als je probeert te doen
dit, als je probeert

2003
01:28:02,910 --> 01:28:05,730
op schaal op een relationeel platform,
dit is wat je doet.

2004
01:28:05,730 --> 01:28:08,100
Je neemt data en
je bent te snijden naar beneden.

2005
01:28:08,100 --> 01:28:10,975
En je bent te partitioneren over
meerdere exemplaren van de database.

2006
01:28:10,975 --> 01:28:13,580
En u bent het beheren van al die
bij de toepassing tier.

2007
01:28:13,580 --> 01:28:14,729
Het is niet leuk.

2008
01:28:14,729 --> 01:28:15,770
Dus wat willen we gaan?

2009
01:28:15,770 --> 01:28:20,240
We willen gaan DynamoDB, volledig beheerde,
NoSQL gegevens op te slaan, bepaling doorvoer.

2010
01:28:20,240 --> 01:28:22,680
We maken gebruik van secundaire indexen.

2011
01:28:22,680 --> 01:28:26,154
Het is eigenlijk HTTP API en
omvat document ondersteuning.

2012
01:28:26,154 --> 01:28:28,570
U hoeft dus geen zorgen te maken
over een van die verdeling.

2013
01:28:28,570 --> 01:28:30,740
We doen het allemaal voor u.

2014
01:28:30,740 --> 01:28:33,260
Dus nu, in plaats daarvan kun
gewoon schrijven naar de tafel.

2015
01:28:33,260 --> 01:28:36,490
Wanneer de tafel moet worden verdeeld,
dat gebeurt achter de schermen.

2016
01:28:36,490 --> 01:28:40,642
Je bent volledig geïsoleerd
uit die als ontwikkelaar.

2017
01:28:40,642 --> 01:28:42,350
Dus laten we praten over
enkele use cases

2018
01:28:42,350 --> 01:28:47,564
dat we tegenkomen in gaming, gemeenschappelijke
gaming scenario's leaderboard.

2019
01:28:47,564 --> 01:28:49,980
Dus je hebt gebruikers komen,
de BoardNames dat ze

2020
01:28:49,980 --> 01:28:52,930
op de scores voor deze gebruiker.

2021
01:28:52,930 --> 01:28:57,700
We misschien hashing op het gebruikers-ID,
en dan hebben we range op het spel.

2022
01:28:57,700 --> 01:28:59,960
Zodat iedere gebruiker wil zien
al het spel dat hij gespeeld

2023
01:28:59,960 --> 01:29:01,770
en al zijn hoogste score
in alle het spel.

2024
01:29:01,770 --> 01:29:04,000
Dus dat is zijn persoonlijke leaderboard.

2025
01:29:04,000 --> 01:29:10,010
>> Nu wil ik gaan en ik wil get--
dus ik krijg deze persoonlijke leaderboards.

2026
01:29:10,010 --> 01:29:12,827
Wat ik wil doen is gaan halen
de hoogste score in alle gebruikers.

2027
01:29:12,827 --> 01:29:13,660
Dus hoe kan ik dat doen?

2028
01:29:13,660 --> 01:29:18,070
Toen mijn record is gehashed op
de gebruikers-ID, varieerden van het spel,

2029
01:29:18,070 --> 01:29:20,740
nou ik ga om verder te gaan
en te herstructureren, het creëren van een GSI,

2030
01:29:20,740 --> 01:29:22,370
en ik ga om die gegevens te herstructureren.

2031
01:29:22,370 --> 01:29:27,310
>> Nu ga ik hash op de
BoardName, wat het spel.

2032
01:29:27,310 --> 01:29:29,800
En ik ga liggen op de hoogste score.

2033
01:29:29,800 --> 01:29:31,540
En nu heb ik verschillende emmers gemaakt.

2034
01:29:31,540 --> 01:29:34,790
Ik gebruik dezelfde tafel,
dezelfde artikelgegevens.

2035
01:29:34,790 --> 01:29:39,870
Maar ik ben het creëren van een emmer dat geeft
me een samenvoeging van de top scoren spel.

2036
01:29:39,870 --> 01:29:43,180
>> En ik kan die tafel opvragen
om die informatie te krijgen.

2037
01:29:43,180 --> 01:29:50,890
Dus ik heb ingesteld die vraag patroon tot
worden ondersteund door een secundaire index.

2038
01:29:50,890 --> 01:29:54,556
Nu kunnen ze worden gesorteerd per BoardName
en gesorteerd topscore afhankelijk.

2039
01:29:54,556 --> 01:29:57,180
Zodat u kunt zien, zijn dit soort
van use cases je in gaming.

2040
01:29:57,180 --> 01:30:02,190
Een ander goed gebruik voor het geval we krijgen in gaming
is awards en wie won de awards.

2041
01:30:02,190 --> 01:30:05,340
En dit is een geweldige use case
waar we noemen schaars indexen.

2042
01:30:05,340 --> 01:30:07,340
Schaars indexen zijn de
mogelijkheid bieden tot het

2043
01:30:07,340 --> 01:30:10,850
een index die niet noodzakelijkerwijs
bevatten elk punt op de tafel.

2044
01:30:10,850 --> 01:30:11,470
En waarom niet?

2045
01:30:11,470 --> 01:30:14,540
Omdat het attribuut dat wordt
geïndexeerde bestaat niet op elk punt.

2046
01:30:14,540 --> 01:30:16,460
>> Dus in dit specifieke
use case, ik zeg,

2047
01:30:16,460 --> 01:30:19,240
weet je wat, ik ga
maak een attribuut genaamd Award.

2048
01:30:19,240 --> 01:30:22,970
En ik ga elke gebruiker te geven
dat heeft een onderscheiding die toeschrijven.

2049
01:30:22,970 --> 01:30:25,950
Gebruikers die niet over awards zijn
niet van plan om dat attribuut.

2050
01:30:25,950 --> 01:30:27,800
Dus wanneer ik de
index, de enige gebruikers

2051
01:30:27,800 --> 01:30:28,960
die gaan tonen
in de index zijn

2052
01:30:28,960 --> 01:30:31,050
degenen die daadwerkelijk awards hebben gewonnen.

2053
01:30:31,050 --> 01:30:34,440
Dus dat is een geweldige manier om te kunnen
gefilterd indexen te creëren dat

2054
01:30:34,440 --> 01:30:40,580
zijn zeer, zeer selectief die dat niet doen
moet index de hele tabel.

2055
01:30:40,580 --> 01:30:43,050
>> Dus we weinig tijd om hier.

2056
01:30:43,050 --> 01:30:49,190
Ik ga om te gaan en sla
uit en sla dit scenario.

2057
01:30:49,190 --> 01:30:52,625
Praat een beetje about--

2058
01:30:52,625 --> 01:30:54,460
>> PUBLIEK: Kan ik een snelle vraag stellen?

2059
01:30:54,460 --> 01:30:56,722
Een daarvan is te schrijven zwaar?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Wat is?

2061
01:30:57,680 --> 01:30:58,596
Publiek: Schrijf zwaar.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Schrijf zwaar.

2063
01:31:01,270 --> 01:31:03,460
Even kijken.

2064
01:31:03,460 --> 01:31:06,220
>> Publiek: Of is dat niet
iets wat je kunt gewoon

2065
01:31:06,220 --> 01:31:08,809
stem binnen enkele seconden?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: We gaan
door middel van de stemming scenario.

2067
01:31:10,850 --> 01:31:11,670
Het is niet zo erg.

2068
01:31:11,670 --> 01:31:14,580
Hebben jullie een paar minuten?

2069
01:31:14,580 --> 01:31:15,860
OK.

2070
01:31:15,860 --> 01:31:17,890
>> Dus we praten over de stemming.

2071
01:31:17,890 --> 01:31:20,250
Zo echt tijd stemmen, hebben we
vereisten voor de stemming.

2072
01:31:20,250 --> 01:31:25,250
Vereisten zijn dat we toestaan
elke persoon slechts één keer stemmen.

2073
01:31:25,250 --> 01:31:28,060
We willen niemand in staat zijn
om hun stem te veranderen.

2074
01:31:28,060 --> 01:31:31,045
We willen real-time aggregatie
en analytics voor demografie

2075
01:31:31,045 --> 01:31:34,210
dat we gaan worden
tonen aan gebruikers op de site.

2076
01:31:34,210 --> 01:31:35,200
>> Denk aan dit scenario.

2077
01:31:35,200 --> 01:31:37,550
We werken veel van de werkelijkheid
Tv-programma's waar ze

2078
01:31:37,550 --> 01:31:38,960
het doen van deze exacte aard van de dingen.

2079
01:31:38,960 --> 01:31:41,584
Zo kunt u denken aan het scenario,
We hebben miljoenen en miljoenen

2080
01:31:41,584 --> 01:31:43,959
tienermeisjes er
met hun mobiele telefoons

2081
01:31:43,959 --> 01:31:46,250
en stemmen, en stemmen, en
stemmen voor wie ze ook zijn

2082
01:31:46,250 --> 01:31:48,610
vinden van de meest populair.

2083
01:31:48,610 --> 01:31:50,830
Dit zijn dus enkele
eisen we opraken.

2084
01:31:50,830 --> 01:31:52,990
>> En dus is de eerste te nemen
in oplossen van dit probleem

2085
01:31:52,990 --> 01:31:55,090
zou een te bouwen
zeer eenvoudige toepassing.

2086
01:31:55,090 --> 01:31:56,490
Dus ik heb deze app.

2087
01:31:56,490 --> 01:31:57,950
Ik heb een aantal kiezers die er zijn.

2088
01:31:57,950 --> 01:31:59,980
Ze komen, ze sloeg de stemming app.

2089
01:31:59,980 --> 01:32:03,440
Ik heb wat rauwe stemmen tafel kreeg
Ik zal gewoon dumpen die stemmen in.

2090
01:32:03,440 --> 01:32:05,780
Ik zal wat totaal hebben
stemmen tafel

2091
01:32:05,780 --> 01:32:09,490
zal mijn analytics en demografie doen,
en we zullen dit er allemaal in te zetten.

2092
01:32:09,490 --> 01:32:11,420
>> En dit is geweldig.

2093
01:32:11,420 --> 01:32:12,332
Het leven is goed.

2094
01:32:12,332 --> 01:32:15,040
Het leven is goed, totdat we erachter komen dat
er is altijd slechts één of twee

2095
01:32:15,040 --> 01:32:16,879
mensen die populair zijn bij een verkiezing.

2096
01:32:16,879 --> 01:32:19,420
Er is slechts één of twee dingen
dat mensen echt zorgen over.

2097
01:32:19,420 --> 01:32:22,340
En als je in de stemming
schaal, ineens ben ik

2098
01:32:22,340 --> 01:32:26,360
gaat worden hameren de hel uit
twee kandidaten, één of twee kandidaten.

2099
01:32:26,360 --> 01:32:29,390
Een zeer beperkt aantal artikelen
mensen vinden populair.

2100
01:32:29,390 --> 01:32:31,710
>> Dit is niet een goed ontwerp patroon.

2101
01:32:31,710 --> 01:32:33,549
Dit is eigenlijk een
zeer slecht ontwerp patroon

2102
01:32:33,549 --> 01:32:36,340
omdat daarmee precies wat we
sprak over die sneltoetsen was.

2103
01:32:36,340 --> 01:32:38,960
Sneltoetsen zijn iets wat we niet willen.

2104
01:32:38,960 --> 01:32:40,470
>> Dus hoe kunnen we dat oplossen?

2105
01:32:40,470 --> 01:32:47,640
En echt, de manier om dit op te lossen is
door het nemen van de kandidaat-emmers

2106
01:32:47,640 --> 01:32:51,490
en voor elke kandidaat wij,
we gaan naar een willekeurige waarde toevoegen,

2107
01:32:51,490 --> 01:32:54,192
iets dat we kennen, willekeurige
waarde tussen één en 100,

2108
01:32:54,192 --> 01:32:56,620
tussen 100 en 1000,
of één tot 1000,

2109
01:32:56,620 --> 01:32:59,940
echter veel willekeurige waarden die u wilt
voeg op het einde van die kandidaat.

2110
01:32:59,940 --> 01:33:01,330
>> En wat heb ik dan gedaan?

2111
01:33:01,330 --> 01:33:05,830
Als ik met de kandidaat-ID als
de emmer te aggregeren stemmen,

2112
01:33:05,830 --> 01:33:08,780
als ik heb toegevoegd een willekeurige
nummer aan het einde van die,

2113
01:33:08,780 --> 01:33:12,000
Ik heb gemaakt nu 10 emmers, een
honderd emmers, duizend emmers

2114
01:33:12,000 --> 01:33:14,160
dat ik het aggregeren van stemmen over.

2115
01:33:14,160 --> 01:33:18,030
>> Dus ik heb miljoenen en miljoenen,
en miljoenen records komen

2116
01:33:18,030 --> 01:33:22,050
voor deze kandidaten, ik ben nu verspreiden
die stemmen over de kandidaat A_1

2117
01:33:22,050 --> 01:33:24,630
door middel van Kandidaat A_100, omdat
elke keer een stemming komt,

2118
01:33:24,630 --> 01:33:26,530
Ik ben het genereren van een willekeurige
waarde tussen één en 100.

2119
01:33:26,530 --> 01:33:29,446
Ik tacking het op het einde van de
kandidaat die persoon te stemmen voor.

2120
01:33:29,446 --> 01:33:31,120
Ik dumpen het in die emmer.

2121
01:33:31,120 --> 01:33:33,910
>> Nu aan de achterzijde, ik weet
dat ik honderd emmers.

2122
01:33:33,910 --> 01:33:36,350
Dus als ik wil gaan
en aggregeren van de stemmen,

2123
01:33:36,350 --> 01:33:38,244
Ik lees van al die emmers.

2124
01:33:38,244 --> 01:33:39,160
Dus ik ga je gang en voeg.

2125
01:33:39,160 --> 01:33:42,410
En dan heb ik het scatter verzamelen
waar ik naar buiten en zeggen hey,

2126
01:33:42,410 --> 01:33:45,399
weet je wat, deze kandidaat sleutel
ruimten is meer dan honderd emmers.

2127
01:33:45,399 --> 01:33:47,940
Ik ga om te verzamelen alle
stemt van die honderd emmers.

2128
01:33:47,940 --> 01:33:49,981
Ik ga om te aggregeren
hen en ik ga zeggen,

2129
01:33:49,981 --> 01:33:53,830
Een kandidaat heeft nu
totale stem meetellen van x.

2130
01:33:53,830 --> 01:33:55,690
>> Nu zowel de schrijf
query en de lees vraag

2131
01:33:55,690 --> 01:33:58,160
zijn mooi verdeeld
want ik ben over het schrijven

2132
01:33:58,160 --> 01:34:00,320
en ik lees over honderden sleutels.

2133
01:34:00,320 --> 01:34:03,500
Ik ben niet schrijven en
lezen over een sleutel nu.

2134
01:34:03,500 --> 01:34:04,950
Dus dat is een groot patroon.

2135
01:34:04,950 --> 01:34:08,090
>> Dit is in feite waarschijnlijk een
van de belangrijkste ontwerp

2136
01:34:08,090 --> 01:34:10,420
patronen voor schaal in NoSQL.

2137
01:34:10,420 --> 01:34:14,470
U vindt deze soort te zien
ontwerp patroon in elke smaak.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, doet het niet
materie, we hebben allemaal om dit te doen.

2139
01:34:19,100 --> 01:34:21,840
Want als je te maken hebt
met die enorme samenvoegingen,

2140
01:34:21,840 --> 01:34:26,650
moet je een manier om
spreid ze uit over emmers.

2141
01:34:26,650 --> 01:34:29,512
Dus dit is de manier waarop je dat doet.

2142
01:34:29,512 --> 01:34:31,220
Oké, dus wat
je nu aan het doen bent

2143
01:34:31,220 --> 01:34:35,252
wordt je de handel af te lezen
kosten voor schrijven schaalbaarheid.

2144
01:34:35,252 --> 01:34:37,085
De kosten van mijn lezen is
wat complexer

2145
01:34:37,085 --> 01:34:40,220
en ik moet gaan lezen uit een
Honderd emmers in plaats van één.

2146
01:34:40,220 --> 01:34:41,310
Maar ik ben in staat om te schrijven.

2147
01:34:41,310 --> 01:34:44,860
En mijn throughput, mijn schrijven
throughput is ongelooflijk.

2148
01:34:44,860 --> 01:34:49,450
Dus het is meestal een waardevolle
techniek voor het schalen DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
of een NoSQL-database voor die kwestie.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Dus we dachten hoe het te schalen.

2152
01:34:55,240 --> 01:34:56,930
En we dachten hoe
elimineren onze sneltoetsen.

2153
01:34:56,930 --> 01:34:57,820
En dit is fantastisch.

2154
01:34:57,820 --> 01:34:58,960
En we hebben dit mooie systeem.

2155
01:34:58,960 --> 01:35:02,043
En het is ons gegeven zeer correct stemming
want we hebben opname stem de-dupe.

2156
01:35:02,043 --> 01:35:03,130
Het is gebouwd in DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
We spraken over voorwaardelijke rechten.

2158
01:35:05,380 --> 01:35:08,170
>> Wanneer een kiezer binnenkomt, zet
een insert op de tafel,

2159
01:35:08,170 --> 01:35:11,220
ze te voegen met hun kiezers ID,
als ze proberen naar een andere stem in te voegen,

2160
01:35:11,220 --> 01:35:13,320
Ik doe een voorwaardelijke schrijven.

2161
01:35:13,320 --> 01:35:16,960
Alleen maar zeggen dit schrijf
als dit niet bestaat.

2162
01:35:16,960 --> 01:35:19,270
Dus zodra ik zie dat
dat de stemming spatte uiteen op de tafel,

2163
01:35:19,270 --> 01:35:20,460
niemand anders gaat worden
in staat zijn om hun stem uit te brengen.

2164
01:35:20,460 --> 01:35:21,634
En dat is fantastisch.

2165
01:35:21,634 --> 01:35:23,550
En we zijn het verhogen
onze kandidaat tellers.

2166
01:35:23,550 --> 01:35:25,466
En we doen ons
demografie en dat alles.

2167
01:35:25,466 --> 01:35:29,110
Maar wat gebeurt er als mijn
toepassing valt over?

2168
01:35:29,110 --> 01:35:31,350
Nu ineens stemmen
zijn komst, en ik

2169
01:35:31,350 --> 01:35:34,840
weet niet of ze krijgen verwerkt
in mijn analytics en demografie

2170
01:35:34,840 --> 01:35:36,040
meer.

2171
01:35:36,040 --> 01:35:38,462
En wanneer de toepassing
komt een back-up, hoe

2172
01:35:38,462 --> 01:35:41,420
de hel weet ik wat stemmen hebben
verwerkt en waar moet ik beginnen?

2173
01:35:41,420 --> 01:35:44,530
>> Dus dit is echt een probleem als je
beginnen te kijken naar dit soort scenario.

2174
01:35:44,530 --> 01:35:45,571
En hoe kunnen we dat oplossen?

2175
01:35:45,571 --> 01:35:48,070
We lossen het met wat we
noemen DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Streams is een tijd besteld en
gepartitioneerd change log van elke toegang

2177
01:35:53,470 --> 01:35:55,700
naar de tafel, elke schrijven
toegang tot de tafel.

2178
01:35:55,700 --> 01:35:58,810
Alle gegevens die is geschreven aan de
tabel laat zien op de stream.

2179
01:35:58,810 --> 01:36:01,815
>> Het is eigenlijk een 24 uurs wachtrij.

2180
01:36:01,815 --> 01:36:03,690
Items raakte de beek,
ze leven voor 24 uur.

2181
01:36:03,690 --> 01:36:05,990
Ze kunnen meerdere keren worden gelezen.

2182
01:36:05,990 --> 01:36:09,400
Gegarandeerd te leveren
slechts één keer naar de beek,

2183
01:36:09,400 --> 01:36:11,180
kon n aantal keer worden gelezen.

2184
01:36:11,180 --> 01:36:14,910
Dus hoe veel processen u wilt
verbruiken die gegevens, kunt u deze verbruikt.

2185
01:36:14,910 --> 01:36:16,350
Het zal elke update verschijnen.

2186
01:36:16,350 --> 01:36:18,455
Elke write zal alleen
verschijnen eenmaal op de stream.

2187
01:36:18,455 --> 01:36:20,621
U hoeft dus geen zorgen te maken
over verwerken tweemaal

2188
01:36:20,621 --> 01:36:22,500
van hetzelfde proces.

2189
01:36:22,500 --> 01:36:25,350
>> Het is strikt besteld per stuk.

2190
01:36:25,350 --> 01:36:28,180
Wanneer we de tijd te zeggen
besteld en verdeeld,

2191
01:36:28,180 --> 01:36:30,680
zie je per partitie op de stream.

2192
01:36:30,680 --> 01:36:33,169
Je krijgt punten, updates te zien in orde.

2193
01:36:33,169 --> 01:36:35,210
We zijn niet garanderen
Op de stroom die je

2194
01:36:35,210 --> 01:36:40,240
gaan om elke transactie te krijgen
in de volgorde waarin over items.

2195
01:36:40,240 --> 01:36:42,440
>> Dus streams zijn idempotent.

2196
01:36:42,440 --> 01:36:44,037
Weten we weten allemaal wat idempotent betekent?

2197
01:36:44,037 --> 01:36:46,620
Idempotent betekent dat u kunt doen
over, en over, en weer.

2198
01:36:46,620 --> 01:36:48,200
Het resultaat zal hetzelfde zijn.

2199
01:36:48,200 --> 01:36:49,991
>> Streams zijn idempotent,
maar ze moeten

2200
01:36:49,991 --> 01:36:54,860
afgespeeld vanaf het beginpunt,
waar je maar wilt, tot het einde,

2201
01:36:54,860 --> 01:36:57,950
of ze zullen niet resulteren
in dezelfde waarden.

2202
01:36:57,950 --> 01:36:59,727
>> Hetzelfde met MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB een construct
zij noemen de oplog.

2204
01:37:01,560 --> 01:37:04,140
Het is precies hetzelfde construct.

2205
01:37:04,140 --> 01:37:06,500
Veel NoSQL-databases
hebben dit construct.

2206
01:37:06,500 --> 01:37:08,790
Ze gebruiken het om dingen te doen
zoals replicatie, die

2207
01:37:08,790 --> 01:37:10,475
is precies wat we doen met beekjes.

2208
01:37:10,475 --> 01:37:12,350
PUBLIEK: Misschien een
ketterse vraag, maar u

2209
01:37:12,350 --> 01:37:13,975
praten over apps doet hij een enzovoort.

2210
01:37:13,975 --> 01:37:16,089
Worden streams gegarandeerd
nooit mogelijk naar beneden gaan?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Ja, stromen
zijn gegarandeerd nooit naar beneden gaan.

2212
01:37:18,630 --> 01:37:21,040
Wij beheren de infrastructuur
achter. stromen automatisch

2213
01:37:21,040 --> 01:37:22,498
implementeren in hun auto scaling-groep.

2214
01:37:22,498 --> 01:37:25,910
We gaan door middel van een klein
beetje over wat er gebeurt.

2215
01:37:25,910 --> 01:37:30,060
>> Ik zou niet zeggen dat ze niet
gegarandeerd nooit naar beneden gaan.

2216
01:37:30,060 --> 01:37:33,110
De elementen worden gegarandeerd
te verschijnen in de beek.

2217
01:37:33,110 --> 01:37:36,740
En de stroom zal toegankelijk zijn.

2218
01:37:36,740 --> 01:37:40,580
Dus wat naar beneden gaat of komt terug
up, dat gebeurt eronder.

2219
01:37:40,580 --> 01:37:43,844
Het Covers het is OK.

2220
01:37:43,844 --> 01:37:46,260
Oké, dus je anders krijgt
types weergave van het scherm af.

2221
01:37:46,260 --> 01:37:51,040
De types dat een belangrijk zijn
programmeur meestal zijn, wat was het?

2222
01:37:51,040 --> 01:37:52,370
Ik krijg het oude uitzicht.

2223
01:37:52,370 --> 01:37:55,630
Wanneer er een update raakt de tafel, het zal
duwen de oude het oog op de stroom

2224
01:37:55,630 --> 01:38:02,070
zodat gegevens kunnen archiveren, of wijzigen
controle, identificatie change, change

2225
01:38:02,070 --> 01:38:03,600
beheer.

2226
01:38:03,600 --> 01:38:07,160
>> Het nieuwe beeld, wat het nu is na
de update, dat is een ander type weergave

2227
01:38:07,160 --> 01:38:07,660
je kan krijgen.

2228
01:38:07,660 --> 01:38:09,660
U kunt zowel de oude en nieuwe beelden.

2229
01:38:09,660 --> 01:38:10,660
Misschien wil ik ze allebei.

2230
01:38:10,660 --> 01:38:11,790
Ik wil zien wat het was.

2231
01:38:11,790 --> 01:38:13,290
Ik wil zien wat er veranderd is.

2232
01:38:13,290 --> 01:38:15,340
>> Ik heb een soort naleving
van het proces dat loopt.

2233
01:38:15,340 --> 01:38:17,430
Het moet om te controleren of
wanneer deze dingen te veranderen,

2234
01:38:17,430 --> 01:38:21,840
dat ze binnen bepaalde grenzen
of binnen bepaalde parameters.

2235
01:38:21,840 --> 01:38:23,840
>> En dan alleen ik misschien
moet weten wat er veranderd is.

2236
01:38:23,840 --> 01:38:26,240
Kan me niet schelen wat punt gewijzigd.

2237
01:38:26,240 --> 01:38:28,580
Ik heb geen behoefte om te weten
Wat veranderde attributen.

2238
01:38:28,580 --> 01:38:30,882
Ik moet gewoon weten dat
de producten worden aangeraakt.

2239
01:38:30,882 --> 01:38:33,340
Dus dit zijn de soorten bekeken
dat je uit de stroom

2240
01:38:33,340 --> 01:38:35,960
en je kunt communiceren met.

2241
01:38:35,960 --> 01:38:37,840
>> De toepassing die
verbruikt de stroom,

2242
01:38:37,840 --> 01:38:39,298
Dit is een soort van de manier waarop dit werkt.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB klant vragen om
druk data naar de tafels.

2244
01:38:42,570 --> 01:38:44,750
Streams zetten op wat we scherven noemen.

2245
01:38:44,750 --> 01:38:47,380
Scherven worden geschaald
onafhankelijk van de tabel.

2246
01:38:47,380 --> 01:38:50,660
Ze niet helemaal line-up
om de partities van uw tafel.

2247
01:38:50,660 --> 01:38:52,540
De reden waarom
omdat ze rechtgetrokken

2248
01:38:52,540 --> 01:38:55,430
de capaciteit, de huidige
capaciteit van de tafel.

2249
01:38:55,430 --> 01:38:57,600
>> Zij zetten in hun
eigen auto-scaling-groep,

2250
01:38:57,600 --> 01:39:00,800
en ze beginnen uit te spinnen, afhankelijk
hoeveel schrijft binnenkomen,

2251
01:39:00,800 --> 01:39:03,090
hoeveel reads-- echt het schrijft.

2252
01:39:03,090 --> 01:39:05,820
Er is geen reads-- maar hoe
veel schrijft binnenkomen.

2253
01:39:05,820 --> 01:39:08,200
>> En dan op de rug
Uiteindelijk hebben we wat we

2254
01:39:08,200 --> 01:39:11,390
bel een KCL of Kinesis Client Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis is een stroom data
processing technologie van Amazon.

2256
01:39:19,190 --> 01:39:22,040
En beken is gebouwd op dat.

2257
01:39:22,040 --> 01:39:25,670
>> Zodat je gebruik maken van een KCL enabled
toepassing om de stroom te lezen.

2258
01:39:25,670 --> 01:39:28,752
Kinesis Client Library eigenlijk
beheert de werknemers voor u.

2259
01:39:28,752 --> 01:39:30,460
En het heeft ook een aantal
Interessante dingen.

2260
01:39:30,460 --> 01:39:35,630
Het zal sommige tabellen te maken up
in uw DynamoDB tablespace

2261
01:39:35,630 --> 01:39:38,410
waarin items bijhouden
zijn verwerkt.

2262
01:39:38,410 --> 01:39:41,190
Dus op deze manier als het valt terug, als
het valt over en komt en krijgt

2263
01:39:41,190 --> 01:39:45,570
stond back-up, kan het bepalen waar
was het verwerken van de stroom.

2264
01:39:45,570 --> 01:39:48,360
>> Dat is heel belangrijk wanneer
je praat over replicatie.

2265
01:39:48,360 --> 01:39:50,350
Ik moet weten wat
gegevens werden verwerkt

2266
01:39:50,350 --> 01:39:52,810
en welke gegevens nog worden verwerkt.

2267
01:39:52,810 --> 01:39:57,380
Dus de KCL bibliotheek voor streams zal
geven je een heleboel van die functionaliteit.

2268
01:39:57,380 --> 01:39:58,990
Het zorgt ervoor dat al het huishouden.

2269
01:39:58,990 --> 01:40:01,140
Het staat op een werknemer voor elke scherf.

2270
01:40:01,140 --> 01:40:04,620
Het creëert een administratieve tafel
voor elke scherf, voor iedere werknemer.

2271
01:40:04,620 --> 01:40:07,560
En als die werknemers brand,
ze te behouden die tabellen

2272
01:40:07,560 --> 01:40:10,510
zodat u weet dat dit record
werd gelezen en verwerkt.

2273
01:40:10,510 --> 01:40:13,850
En dan op die manier als het proces
sterft en komt weer online,

2274
01:40:13,850 --> 01:40:17,940
het kan hervatten op de plaats waar het nam af.

2275
01:40:17,940 --> 01:40:20,850
>> Dus we dit gebruiken voor
cross-regio replicatie.

2276
01:40:20,850 --> 01:40:24,680
Veel klanten de noodzaak
gegevens of delen van hun gegevens verhuizen tafels

2277
01:40:24,680 --> 01:40:25,920
rond naar verschillende regio's.

2278
01:40:25,920 --> 01:40:29,230
Er zijn negen regio
over de hele wereld.

2279
01:40:29,230 --> 01:40:32,100
Dus er een need-- ik misschien
kunnen gebruikers in Azië, gebruikers

2280
01:40:32,100 --> 01:40:34,150
in de oostkust van de Verenigde Staten.

2281
01:40:34,150 --> 01:40:38,980
Ze hebben verschillende gegevens die
moet lokaal worden verspreid.

2282
01:40:38,980 --> 01:40:42,510
En misschien een gebruiker vliegt van
Azië naar de Verenigde Staten,

2283
01:40:42,510 --> 01:40:45,020
en ik wil repliceren
zijn gegevens met hem.

2284
01:40:45,020 --> 01:40:49,340
Dus als hij uit het vliegtuig, heeft hij
een goede ervaring met zijn mobiele app.

2285
01:40:49,340 --> 01:40:52,360
>> U kunt de cross-regio gebruiken
replicatie bibliotheek om dit te doen.

2286
01:40:52,360 --> 01:40:55,730
Eigenlijk we
mits twee technologieën.

2287
01:40:55,730 --> 01:40:59,400
Eén is een console applicatie die u kunt
staan ​​op uw eigen EC2 bijvoorbeeld.

2288
01:40:59,400 --> 01:41:01,240
Het loopt pure replicatie.

2289
01:41:01,240 --> 01:41:02,720
En toen gaven we u de bibliotheek.

2290
01:41:02,720 --> 01:41:06,070
De bibliotheek die u kunt gebruiken om te bouwen
uw eigen applicatie als u

2291
01:41:06,070 --> 01:41:10,740
willen gekke dingen doen met die data--
filter, repliceren slechts een deel ervan,

2292
01:41:10,740 --> 01:41:14,120
draai de gegevens verplaatsen naar een
andere tabel, enzovoort, enzovoort.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Dus dat is een soort van hoe dat eruit ziet.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams kan worden
verwerkt door wat wij noemen Lambda.

2296
01:41:23,690 --> 01:41:27,394
We hebben het een beetje over evenement
gedreven applicatie architecturen.

2297
01:41:27,394 --> 01:41:28,810
Lambda is een belangrijk onderdeel van.

2298
01:41:28,810 --> 01:41:32,840
Lambda is code die branden op aanvraag
in reactie op een bepaalde gebeurtenis.

2299
01:41:32,840 --> 01:41:36,020
Een van die gebeurtenissen zou een
opnemen die op de stream.

2300
01:41:36,020 --> 01:41:39,100
Als een record wordt weergegeven op de stroom,
we zullen deze Java-functie aan te roepen.

2301
01:41:39,100 --> 01:41:44,980
Nou, dit is JavaScript en Lambda
ondersteunt Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
en zal binnenkort te ondersteunen
andere talen.

2303
01:41:47,820 --> 01:41:50,940
En het volstaat te zeggen, het is pure code.

2304
01:41:50,940 --> 01:41:53,610
schrijven in Java, een klasse te definiëren.

2305
01:41:53,610 --> 01:41:55,690
Je duwt de JAR omhoog in Lambda.

2306
01:41:55,690 --> 01:42:00,200
En dan aangeven welke klasse je
te roepen in respons op welk geval.

2307
01:42:00,200 --> 01:42:04,770
En dan de Lambda-infrastructuur
achter die zal dat code uit te voeren.

2308
01:42:04,770 --> 01:42:06,730
>> Die code kan verwerken
registers van de beek.

2309
01:42:06,730 --> 01:42:08,230
Het kan om het even wat hij wil mee doen.

2310
01:42:08,230 --> 01:42:11,650
In dit specifieke voorbeeld, alles wat we zijn
eigenlijk doet is het loggen van de attributen.

2311
01:42:11,650 --> 01:42:13,480
Maar dit is gewoon code.

2312
01:42:13,480 --> 01:42:15,260
Code kan niets doen, toch?

2313
01:42:15,260 --> 01:42:16,600
>> Dus je kunt die gegevens draaien.

2314
01:42:16,600 --> 01:42:18,160
U kunt een afgeleide weergave maken.

2315
01:42:18,160 --> 01:42:21,160
Als het een document structuur,
U kunt de structuur plat.

2316
01:42:21,160 --> 01:42:24,300
U kunt alternatieve indexen creëren.

2317
01:42:24,300 --> 01:42:27,100
Allerlei dingen die je kunt
maken met de DynamoDB Streams.

2318
01:42:27,100 --> 01:42:28,780
>> En echt, dat is wat die lijkt.

2319
01:42:28,780 --> 01:42:29,940
Zo krijg je de updates komen.

2320
01:42:29,940 --> 01:42:31,190
Ze komen uit de string.

2321
01:42:31,190 --> 01:42:32,720
Ze worden gelezen door de Lambda functie.

2322
01:42:32,720 --> 01:42:37,480
Ze draaien van de gegevens en
duwen in afgeleide tabellen,

2323
01:42:37,480 --> 01:42:42,200
kennisgeving externe systemen van verandering,
en duwen gegevens in ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> We spraken over hoe de cache te zetten
voor de database die de verkoop

2325
01:42:45,900 --> 01:42:46,450
scenario.

2326
01:42:46,450 --> 01:42:50,049
Tja, wat gebeurt er als ik
actualiseren het item beschrijving?

2327
01:42:50,049 --> 01:42:52,340
Nou, als ik had een Lambda
functie die op die tafel,

2328
01:42:52,340 --> 01:42:55,490
als ik het updaten van het item beschrijving, het zal
pick-up het record van de stroom,

2329
01:42:55,490 --> 01:42:58,711
en het zal de ElastiCache actualiseren
Bijvoorbeeld met de nieuwe gegevens.

2330
01:42:58,711 --> 01:43:00,460
Dus dat is een heleboel
wat we doen met Lambda.

2331
01:43:00,460 --> 01:43:02,619
Het is glue code, connectoren.

2332
01:43:02,619 --> 01:43:04,410
En het eigenlijk geeft
het vermogen om te starten

2333
01:43:04,410 --> 01:43:07,930
en zeer complexe applicaties
zonder een dedicated server

2334
01:43:07,930 --> 01:43:10,371
infrastructuur, die is echt cool.

2335
01:43:10,371 --> 01:43:13,100
>> Dus laten we gaan terug naar onze
real-time de stemming architectuur.

2336
01:43:13,100 --> 01:43:17,984
Dit is nieuw en verbeterd onze
beken en KCL enabled applicatie.

2337
01:43:17,984 --> 01:43:20,150
Hetzelfde als voorheen, we kunnen
handvat elke schaal van de verkiezingen.

2338
01:43:20,150 --> 01:43:21,100
We dit leuk.

2339
01:43:21,100 --> 01:43:24,770
We doen uit scatter verzamelt
over meerdere emmers.

2340
01:43:24,770 --> 01:43:26,780
We hebben optimistische vergrendeling gaande.

2341
01:43:26,780 --> 01:43:30,192
We kunnen onze kiezers houden
van het veranderen van hun stemmen.

2342
01:43:30,192 --> 01:43:31,400
Ze kunnen alleen maar één keer stemmen.

2343
01:43:31,400 --> 01:43:32,880
Dit is fantastisch.

2344
01:43:32,880 --> 01:43:35,895
Real-time fouttolerantie,
schaalbare aggregatie nu.

2345
01:43:35,895 --> 01:43:38,270
Als het ding omvalt, is het
weet waar om zichzelf opnieuw op te starten

2346
01:43:38,270 --> 01:43:41,300
als het gaat terug omdat
we gebruiken de KCL app.

2347
01:43:41,300 --> 01:43:45,700
En dan kunnen we ook gebruik maken van dat
KCL verzoek om gegevens uit te duwen

2348
01:43:45,700 --> 01:43:48,820
om Redshift voor andere
app analytics, of het gebruik

2349
01:43:48,820 --> 01:43:51,990
de Elastic MapReduce te lopen
real-time streaming aggregaties off

2350
01:43:51,990 --> 01:43:53,180
van die data.

2351
01:43:53,180 --> 01:43:55,480
>> Dus dit zijn dingen die we
hebben niet gesproken over veel.

2352
01:43:55,480 --> 01:43:57,375
Maar ze zijn extra
technologieën die komen

2353
01:43:57,375 --> 01:44:00,310
te dragen als je op zoek bent
deze soort scenario.

2354
01:44:00,310 --> 01:44:03,160
>> Oké, dus dat is over
analytics met DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
U kunt de-dupe te verzamelen
data, doen allerlei

2356
01:44:05,340 --> 01:44:09,490
van mooie spullen, geaggregeerde gegevens in
geheugen, maken deze afgeleide tabellen.

2357
01:44:09,490 --> 01:44:13,110
Dat is een enorme use case
dat veel klanten

2358
01:44:13,110 --> 01:44:16,950
betrokken zijn bij, waarbij de geneste
eigenschappen van de JSON-documenten

2359
01:44:16,950 --> 01:44:18,946
en het creëren van extra indexen.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> We zijn aan het einde.

2362
01:44:23,150 --> 01:44:26,689
Dank u voor het dragen met mij.

2363
01:44:26,689 --> 01:44:28,480
Dus laten we praten over
referentie-architectuur.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB zit in het midden van zo
veel van de AWS infrastructuur.

2365
01:44:33,440 --> 01:44:37,090
In principe kunt u deze aansluiten
tot alles wat je wilt.

2366
01:44:37,090 --> 01:44:45,600
Applicaties gebouwd met behulp van Dynamo omvatten
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
duw de gegevens uit in Elastic
MapReduce, import export van DynamoDB

2368
01:44:49,890 --> 01:44:52,370
in S3, allerlei workflows.

2369
01:44:52,370 --> 01:44:54,120
Maar waarschijnlijk de beste
ding om te praten over,

2370
01:44:54,120 --> 01:44:56,119
en dit is wat echt
interessant is wanneer we

2371
01:44:56,119 --> 01:44:58,350
praten over event-driven applicaties.

2372
01:44:58,350 --> 01:45:00,300
>> Dit is een voorbeeld van
een intern project

2373
01:45:00,300 --> 01:45:04,850
dat we hebben waar we zijn eigenlijk
publiceren om onderzoeksresultaten te verzamelen.

2374
01:45:04,850 --> 01:45:07,700
Dus in een e-mail link die
we sturen, zal er

2375
01:45:07,700 --> 01:45:11,350
een beetje koppeling zeggen klik
Hier te reageren op het onderzoek.

2376
01:45:11,350 --> 01:45:14,070
En wanneer een persoon klikken
die verwijzen, wat er gebeurt

2377
01:45:14,070 --> 01:45:18,020
is ze pull-down een beveiligde
HTML enquêteformulier van S3.

2378
01:45:18,020 --> 01:45:18,980
Er is geen server.

2379
01:45:18,980 --> 01:45:20,600
Dit is slechts een S3 object.

2380
01:45:20,600 --> 01:45:22,770
>> Dit formulier komt,
laadt in de browser.

2381
01:45:22,770 --> 01:45:24,240
Het heeft Backbone.

2382
01:45:24,240 --> 01:45:30,160
Het heeft complexe JavaScript
dat het draait.

2383
01:45:30,160 --> 01:45:33,557
Dus het is zeer rijk applicatie
die in de browser van de klant.

2384
01:45:33,557 --> 01:45:36,390
Ze weten niet dat ze niet
interactie met een back-end server.

2385
01:45:36,390 --> 01:45:38,220
Op dit punt, het is allemaal browser.

2386
01:45:38,220 --> 01:45:41,780
>> Zij publiceren de resultaten van wat
we de Amazone API Gateway noemen.

2387
01:45:41,780 --> 01:45:46,270
API Gateway is gewoon een web API
die u kunt definiëren en haak

2388
01:45:46,270 --> 01:45:47,760
in wat u wilt.

2389
01:45:47,760 --> 01:45:50,990
In dit specifieke geval, we zijn
aangesloten op een Lambda functie.

2390
01:45:50,990 --> 01:45:54,797
>> Dus mijn POST-bewerking is
gebeurt zonder server.

2391
01:45:54,797 --> 01:45:56,380
In feite dat API Gateway zit daar.

2392
01:45:56,380 --> 01:45:58,770
Het kost me niets totdat de mensen
begin met het publiceren om het, toch?

2393
01:45:58,770 --> 01:46:00,269
De Lambda functie zit daar gewoon.

2394
01:46:00,269 --> 01:46:03,760
En het kost me niets, totdat
mensen beginnen te raken.

2395
01:46:03,760 --> 01:46:07,270
Zodat u kunt zien, omdat het volume
toeneemt, dat is wanneer de kosten komen.

2396
01:46:07,270 --> 01:46:09,390
Ik ben niet het draaien van een server 24/7.

2397
01:46:09,390 --> 01:46:12,310
>> Dus ik trek de vorm
naar beneden uit de emmer,

2398
01:46:12,310 --> 01:46:15,719
en ik post via de API
Toegangspoort tot de Lambda functie.

2399
01:46:15,719 --> 01:46:17,510
En dan de Lambda
functie zegt, weet je

2400
01:46:17,510 --> 01:46:20,600
wat, heb ik een aantal PIIS kreeg, wat
persoonlijk identificeerbare informatie

2401
01:46:20,600 --> 01:46:21,480
in deze reacties.

2402
01:46:21,480 --> 01:46:23,020
Ik kreeg reacties uit gebruikers.

2403
01:46:23,020 --> 01:46:24,230
Ik heb e-mailadressen.

2404
01:46:24,230 --> 01:46:26,190
Ik heb gebruikersnamen.

2405
01:46:26,190 --> 01:46:27,810
>> Laat me dit af te splitsen.

2406
01:46:27,810 --> 01:46:30,280
Ik ga wat te genereren
metadata uit dit record.

2407
01:46:30,280 --> 01:46:32,850
En ik ga het duwen
metadata in DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
En ik kon alle data te versleutelen
en duw hem in DynamoDB als ik wil.

2409
01:46:36,059 --> 01:46:38,600
Maar het is makkelijker voor mij, in dit
use case, om verder te gaan van een woord,

2410
01:46:38,600 --> 01:46:42,800
Ik ga naar de ruwe data te duwen
in een versleutelde S3 emmer.

2411
01:46:42,800 --> 01:46:47,240
Dus ik gebruik gebouwd in S3 server side
encryptie en Key Management Amazon's

2412
01:46:47,240 --> 01:46:51,600
Service dus dat ik een sleutel die
kan roteren op regelmatige interval,

2413
01:46:51,600 --> 01:46:55,010
en ik kan dat PII gegevens te beschermen
als onderdeel van dit hele workflow.

2414
01:46:55,010 --> 01:46:55,870
>> Dus wat heb ik gedaan?

2415
01:46:55,870 --> 01:47:00,397
Ik heb net ingezet geheel
toepassing, en ik heb geen server.

2416
01:47:00,397 --> 01:47:02,980
Dus is wat event driven applicatie
architectuur voor je doet.

2417
01:47:02,980 --> 01:47:05,730
>> Nu, als u denkt over
de use case voor dit--

2418
01:47:05,730 --> 01:47:08,730
we hebben andere klanten Ik heb het
om over exacte architectuur die

2419
01:47:08,730 --> 01:47:14,560
gerund fenomenaal grote campagnes, die
zijn op zoek naar deze en gaan, oh my.

2420
01:47:14,560 --> 01:47:17,840
Omdat nu, kunnen zij
Duw het in principe die er zijn,

2421
01:47:17,840 --> 01:47:21,900
laat die campagne gewoon zitten
daar tot lanceert, en niet

2422
01:47:21,900 --> 01:47:24,400
moet je een figuur maken over
wat voor infrastructuur

2423
01:47:24,400 --> 01:47:26,120
gaat om daar te zijn om het te ondersteunen.

2424
01:47:26,120 --> 01:47:28,600
En dan zo snel
die campagne wordt gedaan,

2425
01:47:28,600 --> 01:47:31,520
het is als de infrastructuur
gewoon direct gaat weg

2426
01:47:31,520 --> 01:47:33,680
want er echt
is geen infrastructuur.

2427
01:47:33,680 --> 01:47:35,660
Het is enkel code die zit op Lambda.

2428
01:47:35,660 --> 01:47:38,560
Het is gewoon de gegevens die zit in DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Het is een geweldige manier
om applicaties te bouwen.

2430
01:47:41,340 --> 01:47:43,970
>> Publiek: Dus is het meer
efemere dan het zou zijn

2431
01:47:43,970 --> 01:47:45,740
als het werd opgeslagen op een echte server?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Absoluut.

2433
01:47:46,823 --> 01:47:49,190
Want dat serverinstantie
zou een 7/24 zijn.

2434
01:47:49,190 --> 01:47:51,954
Het moet beschikbaar zijn
somebody reageren.

2435
01:47:51,954 --> 01:47:52,620
Nou wat denk je?

2436
01:47:52,620 --> 01:47:55,410
S3 is beschikbaar 24/7.

2437
01:47:55,410 --> 01:47:57,100
S3 reageert altijd.

2438
01:47:57,100 --> 01:47:59,320
En S3 is zeer, zeer goed
op waar je van objecten.

2439
01:47:59,320 --> 01:48:02,590
Deze objecten kunnen HTML bestanden, of
JavaScript-bestanden, of wat je wilt.

2440
01:48:02,590 --> 01:48:07,430
U kunt zeer rijke webapplicaties draaien
uit S3 emmers, en de mensen doen.

2441
01:48:07,430 --> 01:48:10,160
>> En dus dat is het idee hier
is om uit de buurt van de weg te krijgen

2442
01:48:10,160 --> 01:48:11,270
we gebruikt om te denken over.

2443
01:48:11,270 --> 01:48:14,270
We hebben allemaal gebruikt om te denken in
het gebied van servers en hosts.

2444
01:48:14,270 --> 01:48:16,580
Het gaat niet om dat niet meer.

2445
01:48:16,580 --> 01:48:19,310
Het gaat over de infrastructuur als code.

2446
01:48:19,310 --> 01:48:22,470
Implementeren van de code naar de cloud en
laat de cloud draaien voor u.

2447
01:48:22,470 --> 01:48:24,980
En dat is wat AWS probeert te doen.

2448
01:48:24,980 --> 01:48:29,690
>> Publiek: Dus je gouden kist in het midden
van de API Gateway is niet server-achtige,

2449
01:48:29,690 --> 01:48:30,576
maar in plaats daarvan is gewoon--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: U kunt denken
het als server gevel.

2451
01:48:32,850 --> 01:48:38,040
Al is het is het zal een HTTP nemen
aanvragen en toewijzen aan een ander proces.

2452
01:48:38,040 --> 01:48:39,192
Dat is alles wat het doet.

2453
01:48:39,192 --> 01:48:41,525
En in dit geval, we in kaart brengen
aan een Lambda functie.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Oké, dus dat is alles wat ik heb.

2456
01:48:45,410 --> 01:48:46,190
Veel dank.

2457
01:48:46,190 --> 01:48:46,800
Ik waardeer dat.

2458
01:48:46,800 --> 01:48:48,100
Ik weet dat we een beetje in de tijd.

2459
01:48:48,100 --> 01:48:49,980
En hopelijk hebben jullie
een beetje van informatie

2460
01:48:49,980 --> 01:48:51,410
dat u vandaag weg kan nemen.

2461
01:48:51,410 --> 01:48:53,520
En ik verontschuldig me als ik ging
over een aantal van uw hoofd,

2462
01:48:53,520 --> 01:48:56,697
maar er is een goede hoop
fundamentele fundamentele kennis

2463
01:48:56,697 --> 01:48:58,280
dat ik denk dat is zeer waardevol voor je.

2464
01:48:58,280 --> 01:48:59,825
Ik dank u voor het hebben van mij.

2465
01:48:59,825 --> 01:49:00,325
[APPLAUS]

2466
01:49:00,325 --> 01:49:02,619
PUBLIEK: [onverstaanbaar]
is wanneer je zegt

2467
01:49:02,619 --> 01:49:05,160
je moest gaan door het ding
vanaf het begin tot het einde

2468
01:49:05,160 --> 01:49:07,619
om de juiste waarden te krijgen
of dezelfde waarden,

2469
01:49:07,619 --> 01:49:09,410
hoe zou de waarden
veranderen als [onverstaanbaar].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Hoe zou de waarden veranderen?

2472
01:49:11,800 --> 01:49:15,180
Nou, want als ik niet lopen
het helemaal tot het einde,

2473
01:49:15,180 --> 01:49:19,770
dan weet ik niet welke veranderingen
werden gemaakt in de laatste mijl.

2474
01:49:19,770 --> 01:49:22,144
Het gaat niet om het te
dezelfde gegevens als wat ik zag.

2475
01:49:22,144 --> 01:49:24,560
PUBLIEK: Oh, dus je gewoon
hebben niet de gehele ingang gekregen.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Recht.

2477
01:49:24,770 --> 01:49:26,895
Je moet gaan van het begin
tot het einde, en dan is het

2478
01:49:26,895 --> 01:49:29,280
gaan naar een consistente staat.

2479
01:49:29,280 --> 01:49:31,520
Koel.

2480
01:49:31,520 --> 01:49:35,907
>> Publiek: Dus u ons toonde DynamoDB
kan document of de sleutel waarde te doen.

2481
01:49:35,907 --> 01:49:38,740
En we brachten veel tijd op de
sleutelwaarde met een hash en wegen

2482
01:49:38,740 --> 01:49:40,005
om het te spiegelen rond.

2483
01:49:40,005 --> 01:49:43,255
Als je keek naar die tabellen, is dat
achterlating van het document aanpak?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: Ik zou het niet
zeggen dat het verlaten van het achter.

2485
01:49:44,600 --> 01:49:45,855
>> Publiek: Ze werden gescheiden van the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Met het document
aanpak, het type document in DynamoDB

2487
01:49:49,140 --> 01:49:50,880
is denk maar aan als een ander attribuut.

2488
01:49:50,880 --> 01:49:53,560
Het is een eigenschap die bevat
een hiërarchische gegevensstructuur.

2489
01:49:53,560 --> 01:49:56,980
En vervolgens in de query,
U kunt de eigenschappen gebruiken

2490
01:49:56,980 --> 01:49:59,480
van die objecten met behulp van Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Dus ik kan filteren op een geneste
eigendom van de JSON-document.

2492
01:50:03,562 --> 01:50:05,520
Publiek: Dus elke keer als ik
doe een document aanpak,

2493
01:50:05,520 --> 01:50:07,906
Ik kan soort van komen op de tabular--

2494
01:50:07,906 --> 01:50:08,780
Publiek: Absoluut.

2495
01:50:08,780 --> 01:50:09,800
PUBLIEK: --indexes en
dingen die je net over sprak.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Ja, de
indexen en dat alles,

2497
01:50:11,280 --> 01:50:13,363
wanneer u wilt de index van de
eigenschappen van de JSON,

2498
01:50:13,363 --> 01:50:18,230
de manier waarop we zouden moeten doen is als
u een JSON object of een document in te voegen

2499
01:50:18,230 --> 01:50:20,780
in Dynamo, zou je streams gebruiken.

2500
01:50:20,780 --> 01:50:22,400
Streams zou de input te lezen.

2501
01:50:22,400 --> 01:50:24,340
Je zou krijgen dat JSON
object en je zou zeggen: OK,

2502
01:50:24,340 --> 01:50:26,030
wat is het pand wil ik index?

2503
01:50:26,030 --> 01:50:28,717
>> U maakt een afgeleide tabel.

2504
01:50:28,717 --> 01:50:30,300
Nu dat is de manier waarop het nu werkt.

2505
01:50:30,300 --> 01:50:32,650
Wij niet toestaan ​​te indexeren
direct die eigenschappen.

2506
01:50:32,650 --> 01:50:33,520
>> PUBLIEK: Tabularizing uw documenten.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Precies, afvlakking
het, tabularizing het, precies.

2508
01:50:36,230 --> 01:50:37,415
Dat is wat je ermee doet.

2509
01:50:37,415 --> 01:50:37,860
>> Publiek: Dank je wel.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Yep,
absoluut, dank je.

2511
01:50:39,609 --> 01:50:42,240
Publiek: Dus het is een soort van
Mongo voldoet Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Ja,
het is een stuk als dat.

2513
01:50:43,990 --> 01:50:45,940
Dat is een goede beschrijving voor.

2514
01:50:45,940 --> 01:50:47,490
Koel.

2515
01:50:47,490 --> 01:50:49,102