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

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

3
00:00:06,010 --> 00:00:06,600
Buna tuturor.

4
00:00:06,600 --> 00:00:07,670
Numele meu este Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Sunt un senior principal
soluții arhitect la AWS.

6
00:00:10,330 --> 00:00:14,070
Ma concentrez pe NoSQL și
Tehnologii DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Sunt astăzi aici pentru a vorbi cu
ai un pic despre ele.

8
00:00:16,930 --> 00:00:18,970
>> Background-ul meu este
în primul rând în strat de date.

9
00:00:18,970 --> 00:00:21,390
Mi-am petrecut jumătate dezvoltarea mea
cariera scris de baze de date,

10
00:00:21,390 --> 00:00:25,930
de acces la date, soluții
pentru diverse aplicații.

11
00:00:25,930 --> 00:00:30,000
Am fost în virtualizare Cloud
timp de aproximativ 20 ani.

12
00:00:30,000 --> 00:00:33,460
Deci, înainte de Cloud a fost nor,
am folosit pentru a apela utilitate de calcul.

13
00:00:33,460 --> 00:00:37,170
Și ideea a fost, e ca si cum
PG & E, veți plăti pentru ceea ce folosiți.

14
00:00:37,170 --> 00:00:38,800
Astăzi numim nor.

15
00:00:38,800 --> 00:00:41,239
>> Dar de-a lungul anilor, am lucrat
pentru un cuplu de companii

16
00:00:41,239 --> 00:00:42,530
nu ati auzit niciodata, probabil, de.

17
00:00:42,530 --> 00:00:47,470
Dar am compilat o listă de tehnică
realizări, cred că aș spune.

18
00:00:47,470 --> 00:00:51,620
Am opt patente în sistemele de Cloud
virtualizare, design microprocesor,

19
00:00:51,620 --> 00:00:54,440
prelucrare eveniment complex,
și în alte domenii, de asemenea.

20
00:00:54,440 --> 00:00:58,290
>> Deci în aceste zile, mă concentrez mai mult pe NoSQL
tehnologii și generația următoare

21
00:00:58,290 --> 00:00:59,450
Bază de date.

22
00:00:59,450 --> 00:01:03,370
Și asta e ceea ce, în general, am de gând
să fie aici să vorbesc cu tine astăzi despre.

23
00:01:03,370 --> 00:01:06,030
Deci, ce vă puteți aștepta
din această sesiune,

24
00:01:06,030 --> 00:01:08,254
vom trece printr-o scurtă
Istoria de prelucrare a datelor.

25
00:01:08,254 --> 00:01:10,420
Este întotdeauna util să
înțelege de unde am venit

26
00:01:10,420 --> 00:01:12,400
și de ce suntem unde suntem.

27
00:01:12,400 --> 00:01:15,600
Și vom vorbi un pic
bit despre tehnologie NoSQL

28
00:01:15,600 --> 00:01:17,500
din punct de vedere fundamental.

29
00:01:17,500 --> 00:01:19,870
>> Vom intra în unele dintre
cele interne ale DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB este AWS nr gust.

31
00:01:24,350 --> 00:01:27,340
Este un complet gestionate și
găzduit soluție NoSQL.

32
00:01:27,340 --> 00:01:32,420
Și vom vorbi un pic despre masă
structura, API-uri, tipuri de date, indici,

33
00:01:32,420 --> 00:01:35,177
și unele dintre componentele interne
a acestei tehnologii DynamoDB.

34
00:01:35,177 --> 00:01:37,760
Vom lua în unele dintre design
modele și cele mai bune practici.

35
00:01:37,760 --> 00:01:39,968
Vom vorbi despre modul în care
utiliza această tehnologie pentru a putea

36
00:01:39,968 --> 00:01:41,430
de aplicații de astăzi.

37
00:01:41,430 --> 00:01:44,820
Și apoi vom vorbi un pic
despre evoluția sau apariția

38
00:01:44,820 --> 00:01:48,980
de o nouă paradigmă de programare
numite aplicații determinate de un eveniment

39
00:01:48,980 --> 00:01:51,580
și cum DynamoDB joacă în la fel de bine.

40
00:01:51,580 --> 00:01:54,690
Și vă vom lăsa un pic de
o discuție arhitectura de referință

41
00:01:54,690 --> 00:01:59,540
astfel încât să putem vorbi despre o parte din
modalități în care puteți utiliza DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Deci, în primul rând off-- aceasta este o întrebare
Am auzit o mulțime este, ceea ce este o bază de date.

43
00:02:04,116 --> 00:02:06,240
O mulțime de oameni cred că
știu ce o bază de date este.

44
00:02:06,240 --> 00:02:08,360
Dacă vă Google, veți vedea asta.

45
00:02:08,360 --> 00:02:11,675
Este un un set structurat de date a avut loc
într-un calculator, mai ales unul care

46
00:02:11,675 --> 00:02:13,600
este accesibil în diverse moduri.

47
00:02:13,600 --> 00:02:16,992
Cred că e un bun
Definiția unei baze de date moderne.

48
00:02:16,992 --> 00:02:19,450
Dar eu nu-mi place, pentru că
implică o serie de lucruri.

49
00:02:19,450 --> 00:02:20,935
Aceasta implică structura.

50
00:02:20,935 --> 00:02:23,120
Și se presupune că este pe un computer.

51
00:02:23,120 --> 00:02:25,750
Si baze de date nu a
exista întotdeauna pe computere.

52
00:02:25,750 --> 00:02:28,020
Baze de date a existat de fapt, în mai multe moduri.

53
00:02:28,020 --> 00:02:32,000
>> Deci, o mai bună definire a unui
bază de date este ceva de genul asta.

54
00:02:32,000 --> 00:02:34,786
O bază de date este o organizat
mecanism pentru stocarea, gestionarea,

55
00:02:34,786 --> 00:02:35,910
și regăsirea informațiilor.

56
00:02:35,910 --> 00:02:36,868
Acest lucru este de la About.com.

57
00:02:36,868 --> 00:02:42,080
Așa că am dori acest lucru, deoarece într-adevăr discuții
despre o bază de date a fi un depozit,

58
00:02:42,080 --> 00:02:44,800
un depozit de
informații, nu neapărat

59
00:02:44,800 --> 00:02:46,780
ceva care sta pe un calculator.

60
00:02:46,780 --> 00:02:49,290
Și de-a lungul istoriei, am
nu au avut întotdeauna calculatoare.

61
00:02:49,290 --> 00:02:52,110
>> Acum, dacă te întreb media
dezvoltator astăzi ceea ce este

62
00:02:52,110 --> 00:02:54,770
o bază de date, care este răspunsul primesc.

63
00:02:54,770 --> 00:02:56,070
Undeva pot lipi lucruri.

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

65
00:02:56,670 --> 00:02:58,725
Și e adevărat.

66
00:02:58,725 --> 00:02:59,600
Dar e regretabil.

67
00:02:59,600 --> 00:03:02,700
Deoarece baza de date este într-adevăr
temelia a aplicației moderne.

68
00:03:02,700 --> 00:03:04,810
Este fundația
de fiecare aplicație.

69
00:03:04,810 --> 00:03:07,240
Și cum vă construi că
baze de date, cum structura

70
00:03:07,240 --> 00:03:11,750
că datele se va dicta cum sa
aplicație funcționează în timp ce scara.

71
00:03:11,750 --> 00:03:14,640
>> Deci, o mulțime de munca mea de azi
se ocupă cu ceea ce

72
00:03:14,640 --> 00:03:17,180
se întâmplă atunci când dezvoltatorii
să ia această abordare

73
00:03:17,180 --> 00:03:19,510
și care se ocupă cu urma
de o aplicație care

74
00:03:19,510 --> 00:03:24,966
este acum scalarea dincolo de original
intenție și suferința de la proiectare rău.

75
00:03:24,966 --> 00:03:26,840
Deci sperăm că, atunci când
de mers pe jos de astăzi, veți

76
00:03:26,840 --> 00:03:29,010
au o serie de instrumente în
centura care va vă păstrați

77
00:03:29,010 --> 00:03:32,566
de la a face aceleași greșeli aceste.

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

79
00:03:33,066 --> 00:03:36,360
Deci, hai sa vorbim despre un pic de
calendarul de tehnologie de baze de date.

80
00:03:36,360 --> 00:03:38,830
Cred că am citit-o
Articolul nu mult timp în urmă

81
00:03:38,830 --> 00:03:43,020
și a spus ceva pe lines--
este o declarație foarte poetic.

82
00:03:43,020 --> 00:03:46,590
Acesta a spus istoricul
de prelucrare a datelor este

83
00:03:46,590 --> 00:03:49,350
plin de filigrane mari
de abundenta de date.

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

85
00:03:49,920 --> 00:03:52,532
Acum, cred că e un fel de adevărat.

86
00:03:52,532 --> 00:03:54,990
Dar mă uit de fapt este la fel de la
istoria este, de fapt umplut

87
00:03:54,990 --> 00:03:56,820
cu filigran mare de presiune date.

88
00:03:56,820 --> 00:04:00,040
Deoarece rata de date a
ingestie nu se duce în jos.

89
00:04:00,040 --> 00:04:01,360
Merge doar până.

90
00:04:01,360 --> 00:04:03,670
>> Și inovarea apare atunci când
vom vedea de presiune date, care

91
00:04:03,670 --> 00:04:07,825
este cantitatea de date care este
acum în vine în sistem.

92
00:04:07,825 --> 00:04:12,027
Și nu poate fi procesată
eficient, fie în timp, fie în costul.

93
00:04:12,027 --> 00:04:14,110
Și atunci vom începe
să se uite la o presiune de date.

94
00:04:14,110 --> 00:04:15,920
>> Deci, atunci când ne uităm la
în primul rând baza de date, aceasta

95
00:04:15,920 --> 00:04:17,180
este cel care a fost între urechile noastre.

96
00:04:17,180 --> 00:04:18,310
Toate ne-am născut cu ea.

97
00:04:18,310 --> 00:04:19,194
E o bază de date de frumos.

98
00:04:19,194 --> 00:04:21,110
Ea are o disponibilitate ridicată.

99
00:04:21,110 --> 00:04:21,959
E mereu pe.

100
00:04:21,959 --> 00:04:23,930
Puteți să-l obține întotdeauna.

101
00:04:23,930 --> 00:04:24,890
>> Dar e un singur utilizator.

102
00:04:24,890 --> 00:04:26,348
Eu nu pot partaja gândurile mele cu tine.

103
00:04:26,348 --> 00:04:28,370
Nu se poate obține gândurile mele
atunci când le doriți.

104
00:04:28,370 --> 00:04:30,320
Și abilitiy lor nu este atât de bun.

105
00:04:30,320 --> 00:04:32,510
Am uitat lucrurile.

106
00:04:32,510 --> 00:04:36,540
Fiecare acum și apoi, unul dintre noi frunze
și se mută la un alt existență

107
00:04:36,540 --> 00:04:39,110
și ne-am pierde tot
care a fost în această bază de date.

108
00:04:39,110 --> 00:04:40,640
Deci asta nu e tot atât de bun.

109
00:04:40,640 --> 00:04:43,189
>> Și aceasta a lucrat mai bine de timp
când eram pe vremuri

110
00:04:43,189 --> 00:04:46,230
când tot ce ne într-adevăr nevoie să știu este
unde mergem pentru a merge pe mâine

111
00:04:46,230 --> 00:04:49,630
sau în cazul în care ne-am adunat cele mai bune alimente.

112
00:04:49,630 --> 00:04:52,820
Dar, așa cum am început să crească ca o
civilizație și de guvern a început

113
00:04:52,820 --> 00:04:55,152
să vină în ființă, și
întreprinderile au început să evolueze,

114
00:04:55,152 --> 00:04:57,360
am început să ne dăm seama
nevoie de un pic mai mult decât ceea ce

115
00:04:57,360 --> 00:04:58,210
am putea pune în capul nostru.

116
00:04:58,210 --> 00:04:58,870
In regula?

117
00:04:58,870 --> 00:05:00,410
>> Aveam nevoie de sisteme de înregistrare.

118
00:05:00,410 --> 00:05:02,220
Aveam nevoie de locuri pentru a fi capabili a stoca date.

119
00:05:02,220 --> 00:05:05,450
Așa că am început documente scris,
crearea de biblioteci și arhive.

120
00:05:05,450 --> 00:05:08,000
Am început dezvoltarea unui
sistem de contabilitate a registru.

121
00:05:08,000 --> 00:05:12,200
Și că sistemul de numărare Ledger
a fugit în lume pentru multe secole,

122
00:05:12,200 --> 00:05:15,580
și poate chiar milenii ca
am un fel de crescut până la punctul

123
00:05:15,580 --> 00:05:18,420
în cazul în care că sarcina datele depasit
capacitatea acestor sisteme

124
00:05:18,420 --> 00:05:19,870
să fie capabil să-l conțină.

125
00:05:19,870 --> 00:05:22,070
>> Și acest lucru sa întâmplat de fapt în anii 1880.

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

127
00:05:22,570 --> 00:05:24,390
În 1880 Statele Unite recensământul.

128
00:05:24,390 --> 00:05:26,976
Aceasta este de fapt în cazul în care întoarcerea
punctul de prelucrare a datelor moderne.

129
00:05:26,976 --> 00:05:28,850
Acesta este punctul în
care cantitatea de date

130
00:05:28,850 --> 00:05:32,060
care a fost colectate de către
Guvernul Statelor Unite a ajuns la punctul

131
00:05:32,060 --> 00:05:34,005
în cazul în care a fost nevoie de opt ani pentru a procesa.

132
00:05:34,005 --> 00:05:36,350
>> Acum, opt ani-- fi
știți, recensământul

133
00:05:36,350 --> 00:05:39,180
ruleaza la fiecare 10 ani-- asa ca e
destul de evident că, prin timp am

134
00:05:39,180 --> 00:05:41,419
Trebuie recensământul din 1890,
cantitatea de date pe care

135
00:05:41,419 --> 00:05:43,210
a fost de gând să fie prelucrate
de guvern a fost

136
00:05:43,210 --> 00:05:46,335
O să depășească 10 ani că
ar lua pentru a lansat noul recensământ.

137
00:05:46,335 --> 00:05:47,250
Aceasta a fost o problemă.

138
00:05:47,250 --> 00:05:49,000
>> Deci, un tip pe nume Herman
Hollerith venit

139
00:05:49,000 --> 00:05:52,640
și a inventat înregistra pumn unitate
cărți, cititor de carduri pumn, pumn carte

140
00:05:52,640 --> 00:05:58,420
tabulator, și colaționarea de
mecanismele pentru această tehnologie.

141
00:05:58,420 --> 00:06:01,860
Și această societate că format la
timp, împreună cu o pereche de alții,

142
00:06:01,860 --> 00:06:05,450
de fapt, a devenit unul dintre pilonii unei
companie mică știm astăzi numit IBM.

143
00:06:05,450 --> 00:06:08,417
>> Deci, IBM a fost inițial în
de afaceri de baze de date.

144
00:06:08,417 --> 00:06:09,750
Și asta e într-adevăr ceea ce au făcut.

145
00:06:09,750 --> 00:06:11,110
Ei au făcut de prelucrare a datelor.

146
00:06:11,110 --> 00:06:15,400
>> Ca astfel proliferarea pumn
cărți, o mecanisme ingenioase

147
00:06:15,400 --> 00:06:18,560
de a fi în măsură să impulsioneze că
Tehnologia la vot seturi de rezultate sortate.

148
00:06:18,560 --> 00:06:20,726
Puteți vedea în această imagine
acolo avem o little--

149
00:06:20,726 --> 00:06:23,970
e un pic small-- dar puteți vedea
un mecanism mecanic foarte ingenios

150
00:06:23,970 --> 00:06:26,970
în cazul în care avem o punte carte pumn.

151
00:06:26,970 --> 00:06:28,720
Și asumarea cuiva
un pic de șurubelniță

152
00:06:28,720 --> 00:06:31,400
și lipirea prin
sloturi și ridicându-l

153
00:06:31,400 --> 00:06:34,820
pentru a obține acel meci, că
Rezultate sortate set.

154
00:06:34,820 --> 00:06:36,270
>> Aceasta este o agregare.

155
00:06:36,270 --> 00:06:38,690
Facem acest lucru tot timpul
astăzi în calculator,

156
00:06:38,690 --> 00:06:40,100
în cazul în care o faci în baza de date.

157
00:06:40,100 --> 00:06:41,620
Am folosit pentru a face acest lucru manual, nu?

158
00:06:41,620 --> 00:06:42,994
Oamenii pun aceste lucruri împreună.

159
00:06:42,994 --> 00:06:45,440
Și a fost proliferarea
din aceste cartele perforate

160
00:06:45,440 --> 00:06:50,070
în ceea ce am numit tobe de date
și role de date, bandă de hârtie.

161
00:06:50,070 --> 00:06:55,980
>> Industria de prelucrare a datelor a avut
o lecție de la piane jucător.

162
00:06:55,980 --> 00:06:57,855
Jucător Piane înapoi la
rândul său, a secolului

163
00:06:57,855 --> 00:07:02,100
folosit pentru a utiliza role de hârtie cu fante
pe ea spune care tastele pentru a juca.

164
00:07:02,100 --> 00:07:05,380
Astfel încât tehnologia a fost adaptat
în cele din urmă pentru a stoca date digitale,

165
00:07:05,380 --> 00:07:08,070
deoarece acestea ar putea pune faptul că datele
pe aceste role bandă de hârtie.

166
00:07:08,070 --> 00:07:10,870
>> Acum, ca urmare, datele
a fost actually-- cum

167
00:07:10,870 --> 00:07:14,960
accesați aceste date a fost direct
depinde de modul în care l-ați stocat.

168
00:07:14,960 --> 00:07:17,825
Deci, dacă am pus datele de pe o bandă,
Am avut acces la datele liniar.

169
00:07:17,825 --> 00:07:20,475
A trebuit să se rostogolească întreg
bandă pentru a accesa toate datele.

170
00:07:20,475 --> 00:07:22,600
Dacă am pus datele din pumn
cărți, am putea accesa

171
00:07:22,600 --> 00:07:26,270
într-un pic mai mult la întâmplare
moda, poate nu la fel de repede.

172
00:07:26,270 --> 00:07:30,770
>> Dar au existat limitări în modul în care
accesul la date pe baza modului fost depozitat.

173
00:07:30,770 --> 00:07:32,890
Și așa mai departe acest lucru a fost o problemă
a intra în anii '50.

174
00:07:32,890 --> 00:07:37,890
Din nou, putem începe să vedem că așa cum am
dezvoltarea de noi tehnologii pentru a procesa

175
00:07:37,890 --> 00:07:41,670
datele, dreapta, se deschide
usa pentru noi soluții,

176
00:07:41,670 --> 00:07:45,852
pentru noi programe, noi
aplicatii pentru că datele.

177
00:07:45,852 --> 00:07:47,810
Și într-adevăr, de guvernare
poate să fi fost motivul

178
00:07:47,810 --> 00:07:49,435
de ce am dezvoltat unele dintre aceste sisteme.

179
00:07:49,435 --> 00:07:52,290
Dar de afaceri a devenit rapid
șoferul din spatele evolutia

180
00:07:52,290 --> 00:07:54,720
a bazei de date moderne și
sistemul de fișiere modern.

181
00:07:54,720 --> 00:07:56,870
>> Deci urmatorul lucru pe care
a venit a fost în anii '50

182
00:07:56,870 --> 00:08:00,780
a fost sistemul de fișiere și
dezvoltarea de stocare cu acces aleator.

183
00:08:00,780 --> 00:08:02,050
Acest lucru a fost frumos.

184
00:08:02,050 --> 00:08:06,230
Acum, toate de brusc, putem pune noastre
fișiere de oriunde de pe aceste hard disk-uri

185
00:08:06,230 --> 00:08:09,760
si putem accesa aceste date în mod aleatoriu.

186
00:08:09,760 --> 00:08:11,950
Putem analiza care
Informatiile din fișiere.

187
00:08:11,950 --> 00:08:14,920
Si am rezolvat tot în lume anilor
probleme cu prelucrarea datelor.

188
00:08:14,920 --> 00:08:17,550
>> Și care a durat aproximativ 20 sau
30 ani până când degajarea

189
00:08:17,550 --> 00:08:22,100
a bazei de date relaționale, care
este atunci când lumea ne-am decis acum

190
00:08:22,100 --> 00:08:27,940
trebuie să aibă un depozit care învinge
expansiunii datelor peste fișierul

191
00:08:27,940 --> 00:08:29,540
sisteme care ne-am construit. Dreapta?

192
00:08:29,540 --> 00:08:34,270
Prea multe date distribuite în prea multe
locuri, de-duplicarea de date,

193
00:08:34,270 --> 00:08:37,120
și costul de depozitare a fost enormă.

194
00:08:37,120 --> 00:08:43,760
>> În anii '70, resursa cea mai scumpe
că un calculator avut a fost de stocare.

195
00:08:43,760 --> 00:08:46,200
Procesorul a fost
privit ca un cost fix.

196
00:08:46,200 --> 00:08:49,030
Când m-am cumpăra pe centru,
CPU nu ceva de lucru.

197
00:08:49,030 --> 00:08:51,960
O să fie filare dacă
este de fapt de lucru sau nu.

198
00:08:51,960 --> 00:08:53,350
Asta e într-adevăr un cost scufundat.

199
00:08:53,350 --> 00:08:56,030
>> Dar ceea ce ma costat ca
de afaceri este de stocare.

200
00:08:56,030 --> 00:09:00,020
Dacă am să cumpere mai multe discuri următor
lună, asta e un cost real care platesc.

201
00:09:00,020 --> 00:09:01,620
Și că de depozitare este scump.

202
00:09:01,620 --> 00:09:05,020
>> Acum ne rapid înainte 40 ani
și avem o altă problemă.

203
00:09:05,020 --> 00:09:10,020
Mașinei elec este acum
resursa cel mai scump.

204
00:09:10,020 --> 00:09:11,470
Stocarea este ieftin.

205
00:09:11,470 --> 00:09:14,570
Vreau să spun, putem merge oriunde pe
nor și putem găsi de stocare ieftine.

206
00:09:14,570 --> 00:09:17,190
Dar ceea ce eu nu pot găsi este de calcul ieftine.

207
00:09:17,190 --> 00:09:20,700
>> Deci evoluția de astăzi
tehnologie, de tehnologie de baze de date,

208
00:09:20,700 --> 00:09:23,050
este cu adevărat concentrat în jurul
baze de date distribuite

209
00:09:23,050 --> 00:09:26,960
care nu suferă de
același tip de scară

210
00:09:26,960 --> 00:09:29,240
limitări ale bazelor de date relaționale.

211
00:09:29,240 --> 00:09:32,080
Vom vorbi un pic despre
ce înseamnă că, de fapt.

212
00:09:32,080 --> 00:09:34,760
>> Dar unul dintre motivele și
șoferul din spatele astea-- noi

213
00:09:34,760 --> 00:09:38,290
a vorbit despre presiunea de date.

214
00:09:38,290 --> 00:09:41,920
Presiune de date este ceva
care conduce inovarea.

215
00:09:41,920 --> 00:09:44,610
Și dacă te uiți la peste
în ultimii cinci ani,

216
00:09:44,610 --> 00:09:48,180
aceasta este o diagramă a ceea ce a datelor
încărcare în întreaga întreprindere generală

217
00:09:48,180 --> 00:09:49,640
arata ca in ultimii cinci ani.

218
00:09:49,640 --> 00:09:52,570
>> Și regula generală de degetul mare
aceste days-- dacă te duci Google--

219
00:09:52,570 --> 00:09:55,290
este de 90% din datele pe care
stocăm astăzi, și a fost

220
00:09:55,290 --> 00:09:57,330
generat în ultimii doi ani.

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

222
00:09:57,911 --> 00:09:59,410
Acum, acest lucru nu este o tendință care este nou.

223
00:09:59,410 --> 00:10:01,230
Aceasta este o tendință care a fost
ieși de 100 de ani.

224
00:10:01,230 --> 00:10:03,438
Inca de la Herman Hollerith
a dezvoltat cardul pumn,

225
00:10:03,438 --> 00:10:08,040
am fost construirea arhive de date
și colectarea de date la viteze fenomenal.

226
00:10:08,040 --> 00:10:10,570
>> Deci, în ultimii 100 de ani,
am văzut această tendință.

227
00:10:10,570 --> 00:10:11,940
Asta nu se va schimba.

228
00:10:11,940 --> 00:10:14,789
Mergând mai departe, vom vedea
acest lucru, în cazul în care nu o tendință accelerată.

229
00:10:14,789 --> 00:10:16,330
Și puteți vedea cum arată.

230
00:10:16,330 --> 00:10:23,510
>> Dacă o afacere in 2010 a avut o
terabyte de date în gestiune,

231
00:10:23,510 --> 00:10:27,080
astăzi că înseamnă că sunt
gestionarea 6,5 ​​petabytes de date.

232
00:10:27,080 --> 00:10:30,380
Asta e 6500 ori mai multe date.

233
00:10:30,380 --> 00:10:31,200
Și știu acest lucru.

234
00:10:31,200 --> 00:10:33,292
Lucrez cu aceste întreprinderi în fiecare zi.

235
00:10:33,292 --> 00:10:35,000
Acum cinci ani, am
ar vorbi cu companii

236
00:10:35,000 --> 00:10:38,260
care ar vorbi cu mine despre ceea ce o durere
este de a gestiona terabytes de date.

237
00:10:38,260 --> 00:10:39,700
Și le-ar vorbi
cu mine despre cum vom vedea

238
00:10:39,700 --> 00:10:41,825
că acest lucru este, probabil, va
să fie un petabyte sau două

239
00:10:41,825 --> 00:10:43,030
într-un cuplu de ani.

240
00:10:43,030 --> 00:10:45,170
>> Aceleași companii
azi Mă întâlnesc cu,

241
00:10:45,170 --> 00:10:48,100
și vorbesc cu mine despre
problemă sunt acolo au de gestionare

242
00:10:48,100 --> 00:10:51,440
zeci, 20 petabytes de date.

243
00:10:51,440 --> 00:10:53,590
Deci explozia
Date din industria

244
00:10:53,590 --> 00:10:56,670
este de conducere enorme
nevoie de soluții mai bune.

245
00:10:56,670 --> 00:11:00,980
Și baza de date relațională este
doar nu de viață de până la cererea.

246
00:11:00,980 --> 00:11:03,490
>> Și deci nu este un liniar
corelație între presiunea de date

247
00:11:03,490 --> 00:11:05,210
și inovație tehnică.

248
00:11:05,210 --> 00:11:07,780
Istoria ne-a arătat
aceasta, că în timp,

249
00:11:07,780 --> 00:11:11,090
ori de câte ori volumul de date
care trebuie să fie procesate

250
00:11:11,090 --> 00:11:15,490
depășește capacitatea sistemului
să-l proceseze într-un timp rezonabil

251
00:11:15,490 --> 00:11:18,870
sau la un cost rezonabil,
apoi noi tehnologii

252
00:11:18,870 --> 00:11:21,080
sunt inventate pentru a rezolva aceste probleme.

253
00:11:21,080 --> 00:11:24,090
Aceste noi tehnologii,
la rândul său, deschide ușa

254
00:11:24,090 --> 00:11:27,840
la un alt set de probleme, care
este colectarea de mai multe date.

255
00:11:27,840 --> 00:11:29,520
>> Acum, nu vom opri acest lucru.

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

257
00:11:30,020 --> 00:11:31,228
Nu vom opri acest lucru.

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

259
00:11:31,830 --> 00:11:35,520
Pentru că nu poate ști totul
ce trebuie să știi în univers.

260
00:11:35,520 --> 00:11:40,510
Și atâta timp cât am fost în viață,
de-a lungul istoriei omului,

261
00:11:40,510 --> 00:11:43,440
am condus mereu să știu mai multe.

262
00:11:43,440 --> 00:11:49,840
>> Deci, se pare ca fiecare inch ne mutam
pe calea de descoperire stiintifica,

263
00:11:49,840 --> 00:11:54,620
suntem înmulțirea valorii de date
că avem nevoie pentru a procesa exponențial

264
00:11:54,620 --> 00:11:59,920
cum am descoperi mai mult și mai mult și mai mult
despre mecanismele interioare ale vieții,

265
00:11:59,920 --> 00:12:04,530
despre modul în care funcționează universul, despre
de conducere descoperire stiintifica,

266
00:12:04,530 --> 00:12:06,440
și invenția care
facem astăzi.

267
00:12:06,440 --> 00:12:09,570
Volumul de date doar
crește continuu.

268
00:12:09,570 --> 00:12:12,120
Deci, fiind capabil să se ocupe de
această problemă este enorm.

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

270
00:12:14,790 --> 00:12:17,410
>> Deci, unul din lucrurile
ne uităm ca de ce NoSQL?

271
00:12:17,410 --> 00:12:19,200
Cum NoSQL rezolva aceasta problema?

272
00:12:19,200 --> 00:12:24,980
Ei bine, baze de date relaționale,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- că e într-adevăr o de construct a
relațional database-- aceste lucruri sunt

274
00:12:28,600 --> 00:12:30,770
optimizat pentru depozitare.

275
00:12:30,770 --> 00:12:33,180
>> Înapoi în anii '70, din nou,
disc este scump.

276
00:12:33,180 --> 00:12:36,990
Exercitarea de provizionare de stocare
în întreprindere este nu se mai termină.

277
00:12:36,990 --> 00:12:37,490
Eu stiu.

278
00:12:37,490 --> 00:12:38,020
Am trăit.

279
00:12:38,020 --> 00:12:41,250
I-am scris drivere de stocare pentru o
companie SuperServer enterprised

280
00:12:41,250 --> 00:12:42,470
înapoi în anii '90.

281
00:12:42,470 --> 00:12:45,920
Și linia de jos este o altă rafturi
matrice de stocare a fost doar ceva ce

282
00:12:45,920 --> 00:12:47,600
sa întâmplat în fiecare zi în întreprindere.

283
00:12:47,600 --> 00:12:49,030
Și nu sa oprit.

284
00:12:49,030 --> 00:12:52,690
De stocare mai mare densitate, cererea
pentru stocarea de înaltă densitate,

285
00:12:52,690 --> 00:12:56,340
și pentru depozitare mai eficientă
devices-- acestuia nu a oprit.

286
00:12:56,340 --> 00:13:00,160
>> Și NoSQL este o tehnologie de mare
deoarece normalizeaza datele.

287
00:13:00,160 --> 00:13:02,210
Acesta de-duplicarea datelor.

288
00:13:02,210 --> 00:13:07,180
Se pune datele într-o structură care
este agnostic pentru orice model de acces.

289
00:13:07,180 --> 00:13:11,600
Aplicații multiple pot lovi că
Baze de date SQL, executați interogări ad-hoc,

290
00:13:11,600 --> 00:13:15,950
și a obține date în forma pe care le
Trebuie să proceseze pentru sarcini de lucru lor.

291
00:13:15,950 --> 00:13:17,570
Sună fantastic.

292
00:13:17,570 --> 00:13:21,350
Dar linia de jos este cu orice
sistem, în cazul în care este agnostic la orice,

293
00:13:21,350 --> 00:13:23,500
este optimizat pentru nimic.

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

295
00:13:24,050 --> 00:13:26,386
>> Și asta e ceea ce vom ajunge cu
baza de date relațională.

296
00:13:26,386 --> 00:13:27,510
Este optimizat pentru depozitare.

297
00:13:27,510 --> 00:13:28,280
E normalizat.

298
00:13:28,280 --> 00:13:29,370
E relațională.

299
00:13:29,370 --> 00:13:31,660
Acesta susține interogările ad-hoc.

300
00:13:31,660 --> 00:13:34,000
Și ea și cântare vertical.

301
00:13:34,000 --> 00:13:39,030
>> Dacă am nevoie pentru a obține o bază de date SQL mai mare
sau o bază de date SQL mai puternic,

302
00:13:39,030 --> 00:13:41,090
Mă duc cumpăra o bucată mai mare de fier.

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

304
00:13:41,600 --> 00:13:44,940
Am lucrat cu o mulțime de clienți
care au trecut prin upgrade-uri majore

305
00:13:44,940 --> 00:13:48,340
în infrastructura SQL numai
pentru a afla sase luni mai tarziu,

306
00:13:48,340 --> 00:13:49,750
ei lovind din nou de perete.

307
00:13:49,750 --> 00:13:55,457
Iar răspunsul de la Oracle sau MSSQL
sau oricine altcineva este de a lua o cutie mai mare.

308
00:13:55,457 --> 00:13:58,540
Ei bine, mai devreme sau mai târziu, nu poti cumpara un
cutie mai mare, și asta e problema reala.

309
00:13:58,540 --> 00:14:00,080
Avem nevoie de a schimba de fapt lucrurile.

310
00:14:00,080 --> 00:14:01,080
Deci, unde face acest lucru?

311
00:14:01,080 --> 00:14:06,560
Aceasta funcționează bine pentru off-
Analytics, sarcini de lucru de tip OLAP.

312
00:14:06,560 --> 00:14:08,670
Și asta e într-adevăr în cazul în care face parte SQL.

313
00:14:08,670 --> 00:14:12,540
Acum, acesta este folosit astăzi în multe on-line
tranzacțională-tip de prelucrare

314
00:14:12,540 --> 00:14:13,330
aplicații.

315
00:14:13,330 --> 00:14:16,460
Și funcționează foarte bine la
un anumit nivel de utilizare,

316
00:14:16,460 --> 00:14:18,670
dar pur si simplu nu scară
modul în care NoSQL face.

317
00:14:18,670 --> 00:14:20,660
Și vom vorbi un pic
bit de ce, care este.

318
00:14:20,660 --> 00:14:23,590
>> Acum, NoSQL, pe de altă parte,
este mai optimizat pentru calcul.

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

320
00:14:24,540 --> 00:14:26,830
Nu este agnostic a
modelul de acces.

321
00:14:26,830 --> 00:14:31,620
Este ceea ce noi numim de-normalizat
structură sau o structură ierarhică.

322
00:14:31,620 --> 00:14:35,000
Datele într-o bază de date relațională este
s-au alăturat împreună de la mai multe tabele

323
00:14:35,000 --> 00:14:36,850
pentru a produce de părere că aveți nevoie.

324
00:14:36,850 --> 00:14:40,090
Datele din baza de date NoSQL o
este stocată într-un document care

325
00:14:40,090 --> 00:14:42,100
conține structura ierarhică.

326
00:14:42,100 --> 00:14:45,670
Toate datele care ar fi în mod normal,
s-au alăturat împreună pentru a produce acest punct de vedere

327
00:14:45,670 --> 00:14:47,160
este stocată într-un singur document.

328
00:14:47,160 --> 00:14:50,990
Și vom vorbi un pic despre
cum funcționează într-o pereche de diagrame.

329
00:14:50,990 --> 00:14:55,320
>> Dar ideea de aici este să păstrați
datele ca aceste puncte de vedere. instanțiate

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

331
00:14:56,410 --> 00:14:58,610
Tu scară orizontală.

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

333
00:14:59,556 --> 00:15:02,100
Dacă am nevoie pentru a crește
mărimea clusterului meu NoSQL,

334
00:15:02,100 --> 00:15:03,700
Nu am nevoie pentru a obține o cutie mai mare.

335
00:15:03,700 --> 00:15:05,200
I a lua o altă cutie.

336
00:15:05,200 --> 00:15:07,700
Și am grupează cele împreună,
și pot ciob că datele.

337
00:15:07,700 --> 00:15:10,780
Vom vorbi un pic despre
ceea ce sharding este, să fie

338
00:15:10,780 --> 00:15:14,270
posibilitatea de a scară care baza de date
pe mai multe dispozitive fizice

339
00:15:14,270 --> 00:15:18,370
și scoateți bariera care
mi cere să scară verticală.

340
00:15:18,370 --> 00:15:22,080
>> Deci, este într-adevăr construit pentru on-line
procesarea tranzacțiilor și la scară.

341
00:15:22,080 --> 00:15:25,480
Există o distincție mare
aici între raportare, nu?

342
00:15:25,480 --> 00:15:27,810
Raportarea, eu nu știu
întrebări Mă duc să întreb.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- dacă cineva de la
departamentul meu de marketing

345
00:15:30,570 --> 00:15:34,520
vrea sa doar-- câți dintre clienții mei
au această caracteristică special, care

346
00:15:34,520 --> 00:15:37,850
cumpărate pe acest ziua-- Nu știu
ce interogare au de gând să ceară.

347
00:15:37,850 --> 00:15:39,160
Așa că am nevoie pentru a fi agnostic.

348
00:15:39,160 --> 00:15:41,810
>> Acum, într-o on-line
aplicație tranzacțională,

349
00:15:41,810 --> 00:15:43,820
Știu ce întrebări îți cer.

350
00:15:43,820 --> 00:15:46,581
Am construit cererea de
un flux de lucru foarte specific.

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

352
00:15:47,080 --> 00:15:50,540
Deci, dacă am optimiza datele
stoca pentru a sprijini care flux de lucru,

353
00:15:50,540 --> 00:15:52,020
o să fie mai rapid.

354
00:15:52,020 --> 00:15:55,190
Și de aceea poate NoSQL
accelera într-adevăr de livrare

355
00:15:55,190 --> 00:15:57,710
acestor tipuri de servicii.

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

357
00:15:58,210 --> 00:16:00,501
>> Deci vom intra în
un pic de teorie aici.

358
00:16:00,501 --> 00:16:03,330
Iar unii dintre voi, ochii
s-ar putea derula înapoi un pic.

359
00:16:03,330 --> 00:16:06,936
Dar voi încerca să-l păstrați
nivel la fel de mare ca pot.

360
00:16:06,936 --> 00:16:08,880
Deci, dacă sunteți în proiect
management, există

361
00:16:08,880 --> 00:16:12,280
un construct numită
triunghi de constrângeri.

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

363
00:16:12,936 --> 00:16:16,060
Triunghiul constrângerilor dictează
nu poti avea totul tot timpul.

364
00:16:16,060 --> 00:16:17,750
Nu poate avea plăcintă dvs. și mănâncă prea.

365
00:16:17,750 --> 00:16:22,310
Deci, în managementul de proiect, care triunghi
constrângeri este puteți să-l ieftin,

366
00:16:22,310 --> 00:16:24,710
puteți să-l repede,
sau puteți să-l bine.

367
00:16:24,710 --> 00:16:25,716
Alege două.

368
00:16:25,716 --> 00:16:27,090
Pentru că nu poți avea pe toate trei.

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

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

371
00:16:27,820 --> 00:16:28,920
>> Deci ai auzit despre asta foarte mult.

372
00:16:28,920 --> 00:16:31,253
Este o constrângere triplu,
triunghi de triple constrângere,

373
00:16:31,253 --> 00:16:34,420
sau triunghi de fier este oftentimes--
cand vorbesti cu managerii de proiect,

374
00:16:34,420 --> 00:16:35,420
vor vorbi despre asta.

375
00:16:35,420 --> 00:16:37,640
Acum, baze de date au
propria lor triunghi de fier.

376
00:16:37,640 --> 00:16:40,350
Și triunghiul de fier de date
este ceea ce noi numim teorema CAP.

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

378
00:16:41,580 --> 00:16:43,770
>> PAC dictează teorema
cum baze de date funcționează

379
00:16:43,770 --> 00:16:45,627
sub o stare foarte specific.

380
00:16:45,627 --> 00:16:47,460
Și vom vorbi despre
ceea ce este această condiție.

381
00:16:47,460 --> 00:16:52,221
Dar cele trei puncte ale triunghiului,
ca să spunem așa, sunt C, consistență.

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

383
00:16:52,720 --> 00:16:56,760
Deci, în CAP, consistență înseamnă că toate
clienții care pot accesa baza de date

384
00:16:56,760 --> 00:16:59,084
va avea întotdeauna o foarte
vedere consistent de date.

385
00:16:59,084 --> 00:17:00,750
Nimeni nu vedem două lucruri diferite.

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

387
00:17:01,480 --> 00:17:04,020
Dacă văd în baza de date,
Văd același punct de vedere

388
00:17:04,020 --> 00:17:06,130
ca partenerul meu care vede
aceeași bază de date.

389
00:17:06,130 --> 00:17:07,470
Asta e consistenta.

390
00:17:07,470 --> 00:17:12,099
>> Disponibilitatea înseamnă că, dacă
bază de date online, în cazul în care se poate ajunge,

391
00:17:12,099 --> 00:17:14,760
că toți clienții va fi întotdeauna
să poată citi și scrie.

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

393
00:17:15,260 --> 00:17:17,010
Deci fiecare client care
poate citi baza de date

394
00:17:17,010 --> 00:17:18,955
va fi întotdeauna citit putea
Date de date și să scrie.

395
00:17:18,955 --> 00:17:21,819
Și dacă acesta este cazul,
este un sistem disponibil.

396
00:17:21,819 --> 00:17:24,230
>> Și al treilea punct este ceea ce
numim toleranta partiție.

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

398
00:17:24,730 --> 00:17:28,160
Mijloace de toleranță partiție
că sistemul funcționează bine

399
00:17:28,160 --> 00:17:32,000
în ciuda rețea fizică
partiții între nodurile.

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

401
00:17:32,760 --> 00:17:36,270
Deci, noduri din cluster nu poate
vorbi unul cu celălalt, ceea ce se întâmplă?

402
00:17:36,270 --> 00:17:36,880
In regula.

403
00:17:36,880 --> 00:17:39,545
>> Baze de date relaționale, astfel choose--
puteți alege două dintre acestea.

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

405
00:17:40,045 --> 00:17:43,680
Baze de date relaționale, astfel alege
să fie coerente și disponibile.

406
00:17:43,680 --> 00:17:47,510
Dacă partiția se întâmplă între
de DataNodes din depozitul de date,

407
00:17:47,510 --> 00:17:48,831
baza de date se blochează.

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

409
00:17:49,330 --> 00:17:50,900
Pur și simplu se duce în jos.

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

411
00:17:51,450 --> 00:17:54,230
>> Și acest lucru este motivul pentru care au
să crească cu cutii mai mari.

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

413
00:17:54,730 --> 00:17:58,021
Pentru că nu e no-- de obicei, un grup
baze de date, nu este foarte mulți dintre ei

414
00:17:58,021 --> 00:17:59,590
care funcționează în acest fel.

415
00:17:59,590 --> 00:18:03,019
Dar cele mai multe baze de date scară
vertical într-o singură cutie.

416
00:18:03,019 --> 00:18:05,060
Deoarece au nevoie să fie
consecvent și disponibil.

417
00:18:05,060 --> 00:18:10,320
Dacă o partiție ar fi injectat,
atunci va trebui să facă o alegere.

418
00:18:10,320 --> 00:18:13,720
Trebuie să facă o alegere între
fiind consecvent și disponibil.

419
00:18:13,720 --> 00:18:16,080
>> Și asta e ceea ce fac baze de date NoSQL.

420
00:18:16,080 --> 00:18:16,580
In regula.

421
00:18:16,580 --> 00:18:20,950
Deci, o bază de date NoSQL ea,
vine în două arome.

422
00:18:20,950 --> 00:18:22,990
Noi have-- Ei bine,
vine în mai multe arome,

423
00:18:22,990 --> 00:18:26,140
dar vine cu două de bază
characteristics-- ce

424
00:18:26,140 --> 00:18:30,050
am numi de baze de date CP, sau un
toleranță coerente și partiție

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

426
00:18:31,040 --> 00:18:34,930
Tipii ăștia a face alegerea că, atunci când
nodurile pierd contactul cu celălalt,

427
00:18:34,930 --> 00:18:37,091
nu vom permite
oamenii să scrie orice mai mult.

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

429
00:18:37,590 --> 00:18:41,855
>> Până la acea partiție este eliminat,
acces de scriere este blocat.

430
00:18:41,855 --> 00:18:43,230
Asta înseamnă că nu sunt disponibile.

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

432
00:18:44,510 --> 00:18:46,554
Când vom vedea că
partiție sine injecta,

433
00:18:46,554 --> 00:18:48,470
suntem acum coerente,
pentru că nu mergem

434
00:18:48,470 --> 00:18:51,517
pentru a permite schimbarea datelor de pe două
laturi ale partiției independent

435
00:18:51,517 --> 00:18:52,100
unul de celălalt.

436
00:18:52,100 --> 00:18:54,130
Va trebui să
restabili comunicare

437
00:18:54,130 --> 00:18:56,930
înainte de orice actualizare a
datele sunt permise.

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

439
00:18:58,120 --> 00:19:02,650
>> Aroma următor ar fi un sistem de AP,
sau un libere și porționat

440
00:19:02,650 --> 00:19:03,640
Sistemul de toleranță.

441
00:19:03,640 --> 00:19:05,320
Tipii ăștia nu-mi pasă.

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

443
00:19:06,020 --> 00:19:08,960
Orice nod care devine o
scrie, vom lua.

444
00:19:08,960 --> 00:19:11,480
Deci, eu sunt replicarea datelor meu
pe mai multe noduri.

445
00:19:11,480 --> 00:19:14,730
Aceste noduri obține un client, client vine
în, spune, am de gând să scrie unele date.

446
00:19:14,730 --> 00:19:16,300
Nod spune, nici o problema.

447
00:19:16,300 --> 00:19:18,580
Nodul de lângă el devine
o scriere pe aceeași înregistrare,

448
00:19:18,580 --> 00:19:20,405
el va spune nici o problema.

449
00:19:20,405 --> 00:19:23,030
Undeva înapoi pe partea din spate,
că datele va replica.

450
00:19:23,030 --> 00:19:27,360
Și apoi cineva va realiza,
uh-oh, sistemul își vor da seama, uh-oh,

451
00:19:27,360 --> 00:19:28,870
acolo a fost o actualizare a două părți.

452
00:19:28,870 --> 00:19:30,370
Ce facem?

453
00:19:30,370 --> 00:19:33,210
Și ceea ce fac ei, atunci este
fac ceva care

454
00:19:33,210 --> 00:19:36,080
le permite să rezolve această stare de date.

455
00:19:36,080 --> 00:19:39,000
Și vom vorbi despre
că în graficul următor.

456
00:19:39,000 --> 00:19:40,000
>> Lucru să sublinieze aici.

457
00:19:40,000 --> 00:19:42,374
Iar eu nu am de gând pentru a obține prea
mult în acest lucru, deoarece aceasta

458
00:19:42,374 --> 00:19:43,510
ajunge în teorie de date adânc.

459
00:19:43,510 --> 00:19:46,670
Dar există o tranzacțional
cadru care

460
00:19:46,670 --> 00:19:50,680
ruleaza într-un sistem relațional care
mi permite să facă în condiții de siguranță actualizări

461
00:19:50,680 --> 00:19:53,760
la mai multe entități în baza de date.

462
00:19:53,760 --> 00:19:58,320
Și aceste actualizări vor avea loc
dintr-o dată sau nu la toate.

463
00:19:58,320 --> 00:20:00,500
Și aceasta se numește tranzacții ACID.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID ne dă atomicitatea, consistență,
izolare, și durabilitate.

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

467
00:20:07,070 --> 00:20:13,550
Asta înseamnă că atomice, tranzacții, toate
actualizările mele fie întâmpla sau nu.

468
00:20:13,550 --> 00:20:16,570
Coerența înseamnă că
baza de date va fi întotdeauna

469
00:20:16,570 --> 00:20:19,780
fi aduse într-o consistentă
de stat după o actualizare.

470
00:20:19,780 --> 00:20:23,900
Eu nu va lăsa baza de date într-un
stare de rău după aplicarea o actualizare.

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

472
00:20:24,400 --> 00:20:26,720
>> Deci, este un pic diferit
decât PAC consistenta.

473
00:20:26,720 --> 00:20:29,760
CAP consistență înseamnă toate meu
clienții pot vedea întotdeauna datele.

474
00:20:29,760 --> 00:20:34,450
Consistență ACID înseamnă că, atunci când
o tranzacție a făcut, de date e bine.

475
00:20:34,450 --> 00:20:35,709
Relațiile mele sunt toate bune.

476
00:20:35,709 --> 00:20:38,750
Eu nu am de gând să ștergeți un rând părinte
și se lasă o grămadă de copii orfani

477
00:20:38,750 --> 00:20:40,970
într-o altă tabelă.

478
00:20:40,970 --> 00:20:44,320
Nu se poate întâmpla dacă eu sunt în concordanță
într-o tranzacție de acid.

479
00:20:44,320 --> 00:20:49,120
>> Izolarea înseamnă că tranzacțiile
va avea loc întotdeauna una după alta.

480
00:20:49,120 --> 00:20:51,920
Rezultatul final al datelor
va fi aceeași stare

481
00:20:51,920 --> 00:20:54,770
ca în cazul în aceste tranzacții
care au fost emise simultan

482
00:20:54,770 --> 00:20:57,340
au fost executați în serie.

483
00:20:57,340 --> 00:21:00,030
Deci e concurenta
de control în baza de date.

484
00:21:00,030 --> 00:21:04,130
Deci, practic, nu pot incrementa
aceeași valoare de două ori cu două operațiuni.

485
00:21:04,130 --> 00:21:08,580
>> Dar dacă spun adăuga 1 la această valoare,
și două tranzacții vin în

486
00:21:08,580 --> 00:21:10,665
și să încerce să o facă, un e
O să ajung acolo primul

487
00:21:10,665 --> 00:21:12,540
și celuilalt
O să ajung acolo după.

488
00:21:12,540 --> 00:21:15,210
Deci, în cele din urmă, am adăugat două.

489
00:21:15,210 --> 00:21:16,170
Vezi ce vreau să spun?

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

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

492
00:21:19,220 --> 00:21:21,250
>> Durabilitatea este destul de simplă.

493
00:21:21,250 --> 00:21:23,460
Atunci când tranzacția
este recunoscut, este

494
00:21:23,460 --> 00:21:26,100
O să fie acolo, chiar
în cazul în care sistemul se blochează.

495
00:21:26,100 --> 00:21:29,230
Când acest sistem recupereaza, care
tranzacție care a fost săvârșită

496
00:21:29,230 --> 00:21:30,480
este, de fapt va fi acolo.

497
00:21:30,480 --> 00:21:33,130
Așa că e garanțiile
tranzacțiilor ACID.

498
00:21:33,130 --> 00:21:35,470
Acestea sunt garanții destul de frumos
pentru a avea o bază de date,

499
00:21:35,470 --> 00:21:36,870
dar au venit la acest cost.

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

501
00:21:37,640 --> 00:21:40,520
>> Deoarece problema
cu acest cadru este

502
00:21:40,520 --> 00:21:44,540
dacă există o partiție în datele
set, trebuie să ia o decizie.

503
00:21:44,540 --> 00:21:48,000
Am de gând să trebuie să permită
actualizări pe o parte sau alta.

504
00:21:48,000 --> 00:21:50,310
Și dacă acest lucru se întâmplă,
atunci nu mai merg sunt

505
00:21:50,310 --> 00:21:52,630
să fie capabil să mențină
aceste caracteristici.

506
00:21:52,630 --> 00:21:53,960
Ei nu vor fi în concordanță.

507
00:21:53,960 --> 00:21:55,841
Ele nu vor fi izolate.

508
00:21:55,841 --> 00:21:58,090
Acest lucru este în cazul în care se strică
pentru baze de date relaționale.

509
00:21:58,090 --> 00:22:01,360
Aceasta este relațional motiv
baze de date scară verticală.

510
00:22:01,360 --> 00:22:05,530
>> Pe de altă parte, avem
ceea ce se numește tehnologie de bază.

511
00:22:05,530 --> 00:22:07,291
Și acestea sunt NoSQL bazele de date.

512
00:22:07,291 --> 00:22:07,790
In regula.

513
00:22:07,790 --> 00:22:10,180
Deci avem CP nostru, baze de date AP.

514
00:22:10,180 --> 00:22:14,720
Și acestea sunt ceea ce voi numiți practic
disponibil de stat, moale, în cele din urmă

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

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

517
00:22:16,420 --> 00:22:19,690
>> Practic disponibile, deoarece
sunt partiție tolerant.

518
00:22:19,690 --> 00:22:21,470
Ei vor fi întotdeauna
acolo, chiar dacă nu există

519
00:22:21,470 --> 00:22:23,053
o partiție de rețea între noduri.

520
00:22:23,053 --> 00:22:25,900
Dacă aș putea vorbi cu un nod, sunt
va fi capabil să citească date.

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

522
00:22:26,460 --> 00:22:30,810
S-ar putea să nu fie întotdeauna în măsură să scrie
date în cazul în care sunt o platformă consistentă.

523
00:22:30,810 --> 00:22:32,130
Dar voi fi capabil să citească date.

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

525
00:22:34,960 --> 00:22:38,010
>> Starea moale indică
că, atunci când am citit că datele,

526
00:22:38,010 --> 00:22:40,790
s-ar putea să nu fie la fel ca alte noduri.

527
00:22:40,790 --> 00:22:43,390
În cazul în care un drept a fost emis pe un nod
în altă parte în cluster

528
00:22:43,390 --> 00:22:46,650
și nu a replicat pe întreg teritoriul UE
grup dar atunci când am citit că datele,

529
00:22:46,650 --> 00:22:48,680
acest stat ar putea să nu fie în concordanță.

530
00:22:48,680 --> 00:22:51,650
Cu toate acestea, ea va fi
în cele din urmă consistent,

531
00:22:51,650 --> 00:22:53,870
ceea ce înseamnă că, atunci când o scriere
se face în sistem,

532
00:22:53,870 --> 00:22:56,480
acesta va reproduce peste nodurile.

533
00:22:56,480 --> 00:22:59,095
Și în cele din urmă, această stare
vor fi aduse în ordine,

534
00:22:59,095 --> 00:23:00,890
și va fi o stare consistentă.

535
00:23:00,890 --> 00:23:05,000
>> Acum, într-adevăr teorema CAP
joaca doar într-un singur condiție.

536
00:23:05,000 --> 00:23:08,700
Această condiție este atunci când se întâmplă acest lucru.

537
00:23:08,700 --> 00:23:13,710
Pentru că ori de câte ori este operează în
modul normal, nu exista nici o partiție,

538
00:23:13,710 --> 00:23:16,370
Totul e consistentă și disponibile.

539
00:23:16,370 --> 00:23:19,990
Îți faci griji cu privire la PAC numai
atunci când avem acea partiție.

540
00:23:19,990 --> 00:23:21,260
Deci, acestea sunt rare.

541
00:23:21,260 --> 00:23:25,360
Dar modul în care sistemul reacționează atunci când cei
apar dicta ce tip de sistem

542
00:23:25,360 --> 00:23:26,750
avem de-a face cu.

543
00:23:26,750 --> 00:23:31,110
>> Deci, haideți să aruncăm o privire la ceea ce
care arata ca pentru sistemele de AP.

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

545
00:23:32,621 --> 00:23:34,830
Sisteme de AP vin in doua arome.

546
00:23:34,830 --> 00:23:38,514
Ei vin în aroma, care este o
maestru maestru, 100%, întotdeauna disponibile.

547
00:23:38,514 --> 00:23:40,430
Și au venit în
alte aroma, care spune,

548
00:23:40,430 --> 00:23:43,330
Știi ce, am de gând să vă faceți griji
despre acest lucru de partiționare

549
00:23:43,330 --> 00:23:44,724
atunci când are loc o partiție actuale.

550
00:23:44,724 --> 00:23:47,890
În caz contrar, acolo va fi primar
noduri care va lua drepturile.

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

552
00:23:48,500 --> 00:23:50,040
>> Deci, dacă am ceva de genul Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra ar fi un maestru
master, permiteți-mi scrie la e orice nod.

554
00:23:54,440 --> 00:23:55,540
Deci, ce se întâmplă?

555
00:23:55,540 --> 00:23:58,270
Așa că am un obiect în
baze de date care există pe două noduri.

556
00:23:58,270 --> 00:24:01,705
Să numim acest obiect S.
Deci avem de stat pentru S.

557
00:24:01,705 --> 00:24:04,312
Avem unele operațiuni
pe S, care sunt în curs de desfășurare.

558
00:24:04,312 --> 00:24:06,270
Cassandra mi permite să
scrie la mai multe noduri.

559
00:24:06,270 --> 00:24:08,550
Deci, să spunem că am o
scrie pentru de a două noduri.

560
00:24:08,550 --> 00:24:12,274
Ei bine, ce se termină întâmplă este
numim că un eveniment de partiționare.

561
00:24:12,274 --> 00:24:14,190
Nu poate fi un
partiție de rețea fizică.

562
00:24:14,190 --> 00:24:15,950
Dar, din cauza de proiectare
a sistemului, este

563
00:24:15,950 --> 00:24:18,449
de fapt, de partiționare cât mai curând
așa cum am lua o scrie pe două noduri.

564
00:24:18,449 --> 00:24:20,830
Nu mă forțează să
scrie toate printr-un singur nod.

565
00:24:20,830 --> 00:24:22,340
Scriu pe două noduri.

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

567
00:24:23,330 --> 00:24:25,740
>> Deci, acum am două state.

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

569
00:24:26,360 --> 00:24:28,110
Ce se va întâmpla
este devreme sau mai târziu,

570
00:24:28,110 --> 00:24:29,960
acolo va fi un eveniment de replicare.

571
00:24:29,960 --> 00:24:33,300
Acolo va fi ceea ce ne-am
numit de recuperare partiție, care

572
00:24:33,300 --> 00:24:35,200
este în cazul în care aceste două
Statele întoarce împreună

573
00:24:35,200 --> 00:24:37,310
și acolo va fi un algoritm
care ruleaza in interiorul bazei de date,

574
00:24:37,310 --> 00:24:38,540
decide ce să facă.

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

576
00:24:39,110 --> 00:24:43,057
În mod implicit, Ultima modificare
câștigă în cele mai multe sisteme AP.

577
00:24:43,057 --> 00:24:44,890
Deci, există de obicei, un
algoritm implicit, ceea ce

578
00:24:44,890 --> 00:24:47,400
ei numesc un apel invers
funcție, ceva care

579
00:24:47,400 --> 00:24:51,000
va fi numit atunci când această condiție
este detectată pentru a executa unele logica

580
00:24:51,000 --> 00:24:52,900
pentru a rezolva acest conflict.

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

582
00:24:53,850 --> 00:24:58,770
Callback implicit și implicit
resolver în cele mai multe baze de date AP

583
00:24:58,770 --> 00:25:01,130
este, ghici ce, timestamp castiga.

584
00:25:01,130 --> 00:25:02,380
Aceasta a fost ultima actualizare.

585
00:25:02,380 --> 00:25:04,320
Am de gând să pun că actualizarea acolo.

586
00:25:04,320 --> 00:25:08,440
S-ar putea benă acest record pe care am
fac obiectul unui dumping de pe într-un jurnal de recuperare

587
00:25:08,440 --> 00:25:11,670
astfel încât utilizatorul poate întoarce mai târziu
și spune, hei, nu a fost o coliziune.

588
00:25:11,670 --> 00:25:12,320
Ce s-a întâmplat?

589
00:25:12,320 --> 00:25:16,370
Și vă puteți arunca de fapt o înregistrare de
toate coliziunile și rollbacks

590
00:25:16,370 --> 00:25:17,550
și să vedem ce se întâmplă.

591
00:25:17,550 --> 00:25:21,580
>> Acum, ca utilizator, puteți, de asemenea
includ logica în care de apel invers.

592
00:25:21,580 --> 00:25:24,290
Astfel încât să puteți schimba asta
operațiune de apel invers.

593
00:25:24,290 --> 00:25:26,730
Puteți spune, hei, vreau
pentru remedierea acestei date.

594
00:25:26,730 --> 00:25:28,880
Și vreau să încerc și
fuziona cele două înregistrări.

595
00:25:28,880 --> 00:25:30,050
Dar asta depinde de tine.

596
00:25:30,050 --> 00:25:32,880
Baza de date nu știe cum să
face acest lucru în mod implicit. Cele mai multe ori,

597
00:25:32,880 --> 00:25:34,850
singurul lucru baza de date
știe cum să facă este spus,

598
00:25:34,850 --> 00:25:36,100
acesta a fost ultima înregistrare.

599
00:25:36,100 --> 00:25:39,183
Asta e cea care va câștiga,
și asta e valoarea am de gând să pun.

600
00:25:39,183 --> 00:25:41,490
Odată ce partiție de recuperare
și replicarea apare,

601
00:25:41,490 --> 00:25:43,930
avem statul nostru, care
este acum S prim, care este

602
00:25:43,930 --> 00:25:46,890
starea îmbinare de toate aceste obiecte.

603
00:25:46,890 --> 00:25:49,700
Deci, sisteme de AP au acest.

604
00:25:49,700 --> 00:25:51,615
Sisteme de CP nu au nevoie de
să vă faceți griji despre acest lucru.

605
00:25:51,615 --> 00:25:54,490
Pentru că, de îndată ce vine o partiție
în joc, doar ei nu mai luați

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

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

608
00:25:56,180 --> 00:25:58,670
Așa că e foarte ușor să
a face cu a fi în concordanță

609
00:25:58,670 --> 00:26:01,330
atunci când nu accepta nici actualizări.

610
00:26:01,330 --> 00:26:04,620
Asta e cu sistemele CP face.

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

612
00:26:05,120 --> 00:26:07,590
>> Deci, hai sa vorbim un pic
bit despre modelele de acces.

613
00:26:07,590 --> 00:26:11,580
Când vorbim despre NoSQL, e
Totul despre modelul de acces.

614
00:26:11,580 --> 00:26:13,550
Acum, SQL este ad-hoc, interogări.

615
00:26:13,550 --> 00:26:14,481
Este magazin relațională.

616
00:26:14,481 --> 00:26:16,480
Noi nu trebuie să vă faceți griji
despre modelul de acces.

617
00:26:16,480 --> 00:26:17,688
Scriu o interogare foarte complex.

618
00:26:17,688 --> 00:26:19,250
Se merge și devine datele.

619
00:26:19,250 --> 00:26:21,210
Asta e ceea ce pare acest
cum ar fi, de normalizare.

620
00:26:21,210 --> 00:26:24,890
>> Deci, în această structură special,
ne uitam la un catalog de produse.

621
00:26:24,890 --> 00:26:26,640
Am diferite tipuri de produse.

622
00:26:26,640 --> 00:26:27,217
Am cărți.

623
00:26:27,217 --> 00:26:27,800
Am albume.

624
00:26:27,800 --> 00:26:30,090
Am videoclipuri.

625
00:26:30,090 --> 00:26:33,370
Relația dintre produse
și oricare dintre aceste cărți, albume,

626
00:26:33,370 --> 00:26:34,860
și video mese este de 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Am un ID de produs,
și care corespunde ID

629
00:26:38,860 --> 00:26:41,080
la o carte, un album sau un videoclip.

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

631
00:26:41,580 --> 00:26:44,350
Asta-i un 1: 1 relație
peste aceste tabele.

632
00:26:44,350 --> 00:26:46,970
>> Acum, tot ce books--
au proprietăți este rădăcină.

633
00:26:46,970 --> 00:26:47,550
Nici o problema.

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

635
00:26:48,230 --> 00:26:52,130
One-la-unu relație, mă tot
datele trebuie să descrie acea carte.

636
00:26:52,130 --> 00:26:54,770
Albumele Albums-- au piese.

637
00:26:54,770 --> 00:26:56,470
Aceasta este ceea ce noi numim o la mai multe.

638
00:26:56,470 --> 00:26:58,905
Fiecare album poate avea mai multe piese.

639
00:26:58,905 --> 00:27:00,780
Deci, pentru fiecare piesa de pe
albumul, am putea avea

640
00:27:00,780 --> 00:27:02,570
un alt record în acest tabel copil.

641
00:27:02,570 --> 00:27:04,680
Așa că am crea o înregistrare
în masa mea albume.

642
00:27:04,680 --> 00:27:06,700
Am crea mai multe înregistrări
în tabelul piste.

643
00:27:06,700 --> 00:27:08,850
One-la-mai mulți relație.

644
00:27:08,850 --> 00:27:11,220
>> Această relație este ceea ce
numim mulți-la-mai-mulți.

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

646
00:27:11,750 --> 00:27:17,000
Vezi că actorii ar putea fi
în multe filme, multe videoclipuri.

647
00:27:17,000 --> 00:27:21,450
Deci, ceea ce facem este să punem această cartografiere
tabel între cei, care doar

648
00:27:21,450 --> 00:27:24,040
Hărți ID actor la ID-ul video.

649
00:27:24,040 --> 00:27:28,464
Acum pot crea o interogare îmbinările
video prin video de actor la actori,

650
00:27:28,464 --> 00:27:31,130
și dă-mi o listă frumos de
toate filmele și toți actorii

651
00:27:31,130 --> 00:27:32,420
care au fost în acel film.

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

653
00:27:33,290 --> 00:27:33,880
Deci, aici vom merge.

654
00:27:33,880 --> 00:27:38,040
One-to-one este de nivel superior
relaţie; unu-la-mulți,

655
00:27:38,040 --> 00:27:40,240
Albumele de piste; multe-la-mai mulți.

656
00:27:40,240 --> 00:27:44,990
Acestea sunt de trei nivel superior
relații în orice bază de date.

657
00:27:44,990 --> 00:27:48,050
Dacă știți cum cei
relatii lucreze împreună,

658
00:27:48,050 --> 00:27:51,490
atunci știi o mulțime
despre deja de baze de date.

659
00:27:51,490 --> 00:27:55,660
Deci, NoSQL funcționează un pic diferit.

660
00:27:55,660 --> 00:27:58,930
Să ne gândim pentru un al doilea ceea ce
Se pare că pentru a merge obține toate produsele mele.

661
00:27:58,930 --> 00:28:01,096
>> Într-un magazin relațională, am
doriți să obțineți toate produsele mele

662
00:28:01,096 --> 00:28:02,970
pe o listă cu toate produsele mele.

663
00:28:02,970 --> 00:28:04,910
Asta-i o mulțime de întrebări.

664
00:28:04,910 --> 00:28:07,030
Am o interogare pentru toate cărțile mele.

665
00:28:07,030 --> 00:28:08,470
Am o interogare de la albumele mele.

666
00:28:08,470 --> 00:28:09,970
Și am o interogare pentru toate videoclipurile mele.

667
00:28:09,970 --> 00:28:11,719
Și am ajuns să-l pună
toate împreună într-o listă

668
00:28:11,719 --> 00:28:15,250
și-l servi înapoi la
aplicație Asta e solicitant.

669
00:28:15,250 --> 00:28:18,000
>> Pentru a obține cărțile mele, mă alătur
Produse și cărți.

670
00:28:18,000 --> 00:28:21,680
Pentru a obține albumele mele, am ajuns să se alăture
Produse, Albume, Melodii și.

671
00:28:21,680 --> 00:28:25,330
Și pentru a obține videoclipurile mele, am
să se alăture Produse la Videoclipuri,

672
00:28:25,330 --> 00:28:28,890
se alăture prin actor Videoclipuri,
și să aducă în actori.

673
00:28:28,890 --> 00:28:31,020
Așa că e trei interogări.

674
00:28:31,020 --> 00:28:34,560
Interogări foarte complexe la
asambla un set de rezultate.

675
00:28:34,560 --> 00:28:36,540
>> Asta e mai puțin optimă.

676
00:28:36,540 --> 00:28:39,200
Acesta este motivul pentru atunci când vorbim
despre o structură de date care este

677
00:28:39,200 --> 00:28:42,900
construite pentru a fi agnostic la accesul
pattern-- Și e minunat.

678
00:28:42,900 --> 00:28:45,730
Și puteți vedea acest lucru este într-adevăr
frumos cum am organizat datele.

679
00:28:45,730 --> 00:28:46,550
Și știi ce?

680
00:28:46,550 --> 00:28:49,750
Am doar o singură înregistrare pentru un actor.

681
00:28:49,750 --> 00:28:50,440
>> Asta e tare.

682
00:28:50,440 --> 00:28:53,750
Am deduplicated toți actorii mei,
și am menținut asociații mei

683
00:28:53,750 --> 00:28:55,200
în acest tabel de mapare.

684
00:28:55,200 --> 00:29:00,620
Cu toate acestea, obtinerea de date
out devine scump.

685
00:29:00,620 --> 00:29:04,500
Eu trimit CPU peste tot sistemul
aderarea la aceste structuri de date împreună

686
00:29:04,500 --> 00:29:05,950
pentru a fi capabil de a trage înapoi de date.

687
00:29:05,950 --> 00:29:07,310
>> Deci, cum pot obține în jurul valorii de asta?

688
00:29:07,310 --> 00:29:11,200
În NoSQL este vorba despre
agregare, nu de normalizare.

689
00:29:11,200 --> 00:29:13,534
Deci, vrem să spunem că doriți să
sprijini modelul de accesare.

690
00:29:13,534 --> 00:29:15,283
În cazul în care modelul de acces
cererilor,

691
00:29:15,283 --> 00:29:16,770
Am nevoie pentru a obține toate produsele mele.

692
00:29:16,770 --> 00:29:19,027
Să punem toate produsele într-un tabel.

693
00:29:19,027 --> 00:29:22,110
Dacă am pune toate produsele într-un tabel,
Pot selecta doar toate produsele

694
00:29:22,110 --> 00:29:23,850
de la acea masă și am lua toate.

695
00:29:23,850 --> 00:29:25,240
Ei bine, cum fac asta?

696
00:29:25,240 --> 00:29:28,124
Ei bine, în NoSQL nu există
Structura tabelului.

697
00:29:28,124 --> 00:29:30,540
Vom vorbi un pic despre
cum functioneaza la Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Dar nu ai la fel
atributele și aceleași proprietăți

699
00:29:33,570 --> 00:29:37,751
în fiecare rând singur, în fiecare
element, cum faci într-un tabel SQL.

700
00:29:37,751 --> 00:29:39,750
Și ce îmi permite acest
pentru a face o mulțime de lucruri

701
00:29:39,750 --> 00:29:41,124
si da-mi o mulțime de flexibilitate.

702
00:29:41,124 --> 00:29:45,360
În acest caz particular, am
au documentele mele de produse.

703
00:29:45,360 --> 00:29:49,090
Și în acest special
exemplu, totul

704
00:29:49,090 --> 00:29:51,930
este un document în tabelul Produse.

705
00:29:51,930 --> 00:29:56,510
Și produsul pentru o carte ar putea
au un ID de tip care specifică o carte.

706
00:29:56,510 --> 00:29:59,180
Și cererea
ar orienta pe acel ID.

707
00:29:59,180 --> 00:30:02,570
>> La nivel de aplicare, am de gând
să spun oh, ce tip de înregistrare este asta?

708
00:30:02,570 --> 00:30:04,100
Oh, e un record carte.

709
00:30:04,100 --> 00:30:05,990
Înregistrări de carte au aceste proprietăți.

710
00:30:05,990 --> 00:30:08,100
Lasă-mă să creeze un obiect carte.

711
00:30:08,100 --> 00:30:11,289
Deci, am de gând să umple
obiect carte cu acest articol.

712
00:30:11,289 --> 00:30:13,080
Articolul următor vine și
spune, ce e acest articol?

713
00:30:13,080 --> 00:30:14,560
Ei bine, acest articol este un album.

714
00:30:14,560 --> 00:30:17,340
Oh, am o cu totul diferit
rutina de prelucrare pentru că,

715
00:30:17,340 --> 00:30:18,487
pentru ca este un album.

716
00:30:18,487 --> 00:30:19,320
Vezi ce vreau să spun?

717
00:30:19,320 --> 00:30:21,950
>> Astfel încât cererea tier-- I
doar selecta toate aceste înregistrări.

718
00:30:21,950 --> 00:30:23,200
Acestea toate incepe sa vina.

719
00:30:23,200 --> 00:30:24,680
Ele ar putea fi toate tipurile diferite.

720
00:30:24,680 --> 00:30:27,590
Și e logica aplicației
care trece peste aceste tipuri de

721
00:30:27,590 --> 00:30:29,530
și decide cum să le proceseze.

722
00:30:29,530 --> 00:30:33,640
>> Din nou, așa că optimizarea
schema pentru modelul de acces.

723
00:30:33,640 --> 00:30:36,390
O facem prin
colaps aceste tabele.

724
00:30:36,390 --> 00:30:39,670
Suntem practic luați
aceste structuri normalizate,

725
00:30:39,670 --> 00:30:42,000
si ne construim
structuri ierarhice.

726
00:30:42,000 --> 00:30:45,130
În interiorul fiecare dintre aceste înregistrări
Mă duc să văd proprietăți matrice.

727
00:30:45,130 --> 00:30:49,400
>> În interiorul acestui document pentru Albume,
Văd rețele de piste.

728
00:30:49,400 --> 00:30:53,900
Aceste piese become-- acum e
practic acest tabel copil care

729
00:30:53,900 --> 00:30:56,520
există chiar aici, în această structură.

730
00:30:56,520 --> 00:30:57,975
Astfel încât să puteți face acest lucru în DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Puteți face acest lucru în MongoDB.

732
00:30:59,810 --> 00:31:01,437
Puteți face acest lucru în orice bază de date NoSQL.

733
00:31:01,437 --> 00:31:03,520
Crea aceste tipuri de
structuri de date ierarhice

734
00:31:03,520 --> 00:31:07,120
care vă permit să preluați date
foarte repede pentru că acum

735
00:31:07,120 --> 00:31:08,537
nu trebuie să se conformeze.

736
00:31:08,537 --> 00:31:11,620
Când inserați un rând în Tracks
masă, sau un rând în tabelul Albume,

737
00:31:11,620 --> 00:31:13,110
Trebuie să se conformeze că schema.

738
00:31:13,110 --> 00:31:18,060
Trebuie să aibă atributul sau
proprietate care este definit pe masă.

739
00:31:18,060 --> 00:31:20,480
Fiecare dintre ei,
atunci când am insera acel rând.

740
00:31:20,480 --> 00:31:21,910
Asta nu e cazul în NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Pot avea cu totul alt
proprietăți în fiecare document de

742
00:31:24,440 --> 00:31:26,100
că am insera în colecție.

743
00:31:26,100 --> 00:31:30,480
Mecanism atât de foarte puternic.

744
00:31:30,480 --> 00:31:32,852
Și este într-adevăr modul în care
optimizarea sistemului.

745
00:31:32,852 --> 00:31:35,310
Pentru că acum că interogare, în loc să
de a se alătura toate aceste tabele

746
00:31:35,310 --> 00:31:39,160
și executarea de o jumătate de duzină interogări
pentru a trage înapoi datele am nevoie,

747
00:31:39,160 --> 00:31:40,890
Sunt de executare o interogare.

748
00:31:40,890 --> 00:31:43,010
Și mă iterarea
peste rezultatele stabilite.

749
00:31:43,010 --> 00:31:46,512
îți dă o idee
a puterii de NoSQL.

750
00:31:46,512 --> 00:31:49,470
Am de gând să fel de a merge lateral aici
și vorbesc un pic despre asta.

751
00:31:49,470 --> 00:31:53,240
Acest lucru este mai mult un fel de
de marketing sau technology--

752
00:31:53,240 --> 00:31:55,660
comercializarea de tehnologie
tip de discuție.

753
00:31:55,660 --> 00:31:58,672
Dar este important să înțelegem
pentru că dacă ne uităm la partea de sus

754
00:31:58,672 --> 00:32:00,380
aici, la această diagramă,
ceea ce ne uităm la

755
00:32:00,380 --> 00:32:04,030
este ceea ce noi numim
Tehnologia curba hype.

756
00:32:04,030 --> 00:32:06,121
Și ce înseamnă acest lucru este
chestii noi intră în joc.

757
00:32:06,121 --> 00:32:07,120
Oamenii cred că e minunat.

758
00:32:07,120 --> 00:32:09,200
Am rezolvat toate problemele mele.

759
00:32:09,200 --> 00:32:11,630
>> Acest lucru ar putea fi sfârșitul
toate, să fie toate la tot.

760
00:32:11,630 --> 00:32:12,790
Și ei începe să utilizați-l.

761
00:32:12,790 --> 00:32:14,720
Și spun ei, chestia asta nu funcționează.

762
00:32:14,720 --> 00:32:17,600
Acest lucru nu este corect.

763
00:32:17,600 --> 00:32:19,105
Lucruri vechi a fost mai bine.

764
00:32:19,105 --> 00:32:21,230
Și se întorc de a face
lucrurile așa cum erau.

765
00:32:21,230 --> 00:32:22,730
Și apoi în cele din urmă
ei merg, știi ce?

766
00:32:22,730 --> 00:32:24,040
Chestia asta nu este atât de rău.

767
00:32:24,040 --> 00:32:26,192
Oh, asta e cum funcționează.

768
00:32:26,192 --> 00:32:28,900
Și odată ce își vor da seama cum
lucrări, ei încep tot mai bine.

769
00:32:28,900 --> 00:32:32,050
>> Și lucrul amuzant despre ea
este, un fel de linii de până la ceea ce

770
00:32:32,050 --> 00:32:34,300
numim Curve Technology Adoptare.

771
00:32:34,300 --> 00:32:36,910
Deci, ceea ce se întâmplă e că avem
unele de declanșare tehnologie fel.

772
00:32:36,910 --> 00:32:39,100
În cazul bazelor de date,
e presiune date.

773
00:32:39,100 --> 00:32:42,200
Am vorbit despre punctele ridicate de apă
de presiune date de-a lungul timpului.

774
00:32:42,200 --> 00:32:46,310
În momentul în care presiunea de date lovește un anumit
punct, care este un declanșator tehnologie.

775
00:32:46,310 --> 00:32:47,830
>> E prea scump.

776
00:32:47,830 --> 00:32:49,790
Este nevoie de prea mult timp pentru a procesa datele.

777
00:32:49,790 --> 00:32:50,890
Avem nevoie de ceva mai bun.

778
00:32:50,890 --> 00:32:52,890
Ai inovatorii
acolo rulează în jurul,

779
00:32:52,890 --> 00:32:55,050
încercarea de a afla care este solutia.

780
00:32:55,050 --> 00:32:56,050
Care este noua idee?

781
00:32:56,050 --> 00:32:58,170
>> Care este cel mai bun următoare
mod de a face asta?

782
00:32:58,170 --> 00:32:59,530
Și au venit cu ceva.

783
00:32:59,530 --> 00:33:03,140
Și persoanele cu durere reală,
baietii de la marginea sângerare,

784
00:33:03,140 --> 00:33:06,390
vor sări peste tot ea,
pentru că au nevoie de un răspuns.

785
00:33:06,390 --> 00:33:09,690
Acum, ceea ce în mod inevitabil și happens--
se întâmplă acum în NoSQL.

786
00:33:09,690 --> 00:33:11,090
O văd tot timpul.

787
00:33:11,090 --> 00:33:13,610
>> Ce se întâmplă în mod inevitabil este
oameni începe să utilizați noul instrument

788
00:33:13,610 --> 00:33:15,490
în același mod au folosit instrumentul vechi.

789
00:33:15,490 --> 00:33:17,854
Și au aflat că
nu funcționează atât de bine.

790
00:33:17,854 --> 00:33:20,020
Nu-mi amintesc cine eram
vorbesc cu mai devreme.

791
00:33:20,020 --> 00:33:22,080
Dar e ca si cum, atunci când
jackhammer a fost inventat,

792
00:33:22,080 --> 00:33:24,621
oamenii nu l-leagăn peste
capul lor pentru a sparge betonul.

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

794
00:33:27,360 --> 00:33:30,610
>> Dar asta este ceea ce este
întâmplă cu NoSQL astăzi.

795
00:33:30,610 --> 00:33:33,900
Dacă te plimbi în cele mai multe magazine de,
ei încearcă să fie magazine NoSQL.

796
00:33:33,900 --> 00:33:36,510
Ceea ce fac este
ei folosesc NoSQL,

797
00:33:36,510 --> 00:33:39,900
și ei l de încărcare
plin de schemă relațională.

798
00:33:39,900 --> 00:33:41,630
Pentru că așa
ei de design baze de date.

799
00:33:41,630 --> 00:33:44,046
Și ei te intrebi, de ce este
nu desfășoară foarte bine?

800
00:33:44,046 --> 00:33:45,230
Băiat, acest lucru pute.

801
00:33:45,230 --> 00:33:49,900
A trebuit să-mi mențin toate
se alătură in-- e ca, nu, nu.

802
00:33:49,900 --> 00:33:50,800
Menținerea se alătură?

803
00:33:50,800 --> 00:33:52,430
De ce aderarea la date?

804
00:33:52,430 --> 00:33:54,350
Tu nu se alăture de date în NoSQL.

805
00:33:54,350 --> 00:33:55,850
Ai agregate.

806
00:33:55,850 --> 00:34:00,690
>> Deci, dacă doriți, pentru a evita acest lucru, să învețe
cum funcționează instrumentul înainte de fapt

807
00:34:00,690 --> 00:34:02,010
a începe să utilizați-l.

808
00:34:02,010 --> 00:34:04,860
Nu încercați și de a folosi instrumente noi
același mod în care a folosit vechile instrumente.

809
00:34:04,860 --> 00:34:06,500
Vei avea o experiență neplăcută.

810
00:34:06,500 --> 00:34:08,848
Și de fiecare dată
asta e ceea ce e vorba.

811
00:34:08,848 --> 00:34:11,389
Când ne-am începe vine aici,
e pentru că oamenii dat seama

812
00:34:11,389 --> 00:34:13,449
modul de utilizare a instrumentelor.

813
00:34:13,449 --> 00:34:16,250
>> Ei au făcut același lucru atunci când
baze de date relaționale au fost inventate,

814
00:34:16,250 --> 00:34:17,969
și au fost înlocuirea sistemelor de fișiere.

815
00:34:17,969 --> 00:34:20,420
Au încercat să construiască sisteme de fișiere
cu baze de date relaționale

816
00:34:20,420 --> 00:34:22,159
pentru că asta e ceea ce a înțeles oamenii.

817
00:34:22,159 --> 00:34:23,049
Ea nu a funcționat.

818
00:34:23,049 --> 00:34:26,090
Deci, înțelegerea celor mai bune practici
tehnologiei lucrați cu

819
00:34:26,090 --> 00:34:26,730
este imens.

820
00:34:26,730 --> 00:34:29,870
Foarte important.

821
00:34:29,870 --> 00:34:32,440
>> Deci vom intra în DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB este de AWS
-a reușit pe deplin platforma NoSQL.

823
00:34:36,480 --> 00:34:37,719
Ce a reușit pe deplin-înseamnă?

824
00:34:37,719 --> 00:34:40,010
Aceasta înseamnă că nu trebuie să
într-adevăr vă faceți griji despre nimic.

825
00:34:40,010 --> 00:34:42,060
>> Ai venit în, să-ți spun
ne, am nevoie de o masa.

826
00:34:42,060 --> 00:34:43,409
Este nevoie de această capacitate de mult.

827
00:34:43,409 --> 00:34:47,300
Te-a lovit butonul, și furnizarea noi
toată infrastructura din spatele scenei.

828
00:34:47,300 --> 00:34:48,310
Acum, că este enorm.

829
00:34:48,310 --> 00:34:51,310
>> Pentru că atunci când vorbești
despre scalarea o bază de date,

830
00:34:51,310 --> 00:34:53,917
Clustere de date NoSQL la
scară, petabytes de funcționare,

831
00:34:53,917 --> 00:34:55,750
funcționare milioane de
tranzacții pe secundă,

832
00:34:55,750 --> 00:34:58,180
aceste lucruri nu sunt grupuri mici.

833
00:34:58,180 --> 00:35:00,830
Vorbim de mii de cazuri.

834
00:35:00,830 --> 00:35:04,480
Gestionarea mii de cazuri,
chiar cazuri virtuale,

835
00:35:04,480 --> 00:35:06,350
este o adevarata durere în fund.

836
00:35:06,350 --> 00:35:09,110
Adică, cred că despre fiecare dată când un
sistem de patch-uri de operare iese

837
00:35:09,110 --> 00:35:11,552
sau o nouă versiune a bazei de date.

838
00:35:11,552 --> 00:35:13,260
Ce inseamna
pentru tine operațional?

839
00:35:13,260 --> 00:35:16,330
Asta înseamnă că ai 1200
servere care trebuie să fie actualizate.

840
00:35:16,330 --> 00:35:18,960
Acum, chiar și cu automatizare,
care poate lua o lungă perioadă de timp.

841
00:35:18,960 --> 00:35:21,480
Care poate provoca o mulțime de
dureri de cap operaționale,

842
00:35:21,480 --> 00:35:23,090
pentru că s-ar putea avea servicii în jos.

843
00:35:23,090 --> 00:35:26,070
>> Așa cum am actualiza aceste baze de date, am
s-ar putea face implementări albastru verde

844
00:35:26,070 --> 00:35:29,420
în cazul în care am implementat și upgrade jumătate meu
noduri, și apoi upgrade la cealaltă jumătate.

845
00:35:29,420 --> 00:35:30,490
Ia cele jos.

846
00:35:30,490 --> 00:35:33,410
Deci gestionează infrastructura
scară este extrem de dureros.

847
00:35:33,410 --> 00:35:36,210
Și AWS ia durerea din ea.

848
00:35:36,210 --> 00:35:39,210
Si baze de date NoSQL poate
extraordinar de dureros să fie

849
00:35:39,210 --> 00:35:41,780
din cauza modului în care scara.

850
00:35:41,780 --> 00:35:42,926
>> Scale orizontal.

851
00:35:42,926 --> 00:35:45,550
Dacă doriți să obțineți un NoSQL mai mare
de baze de date, de a cumpăra mai multe noduri.

852
00:35:45,550 --> 00:35:48,660
Fiecare nod cumperi este
un alt dureri de cap operaționale.

853
00:35:48,660 --> 00:35:50,830
Așa că haideți să altcineva face asta pentru tine.

854
00:35:50,830 --> 00:35:52,000
AWS poate face asta.

855
00:35:52,000 --> 00:35:54,587
>> Noi sprijinim valorile cheie de documente.

856
00:35:54,587 --> 00:35:56,670
Acum, noi nu a mers prea mult
în pe harta altei.

857
00:35:56,670 --> 00:35:58,750
Există o mulțime de diferite
arome de NoSQL.

858
00:35:58,750 --> 00:36:02,670
Sunt tot felul de a obține
munged împreună în acest moment.

859
00:36:02,670 --> 00:36:06,260
Poti sa te uiti la DynamoDB și spune da,
suntem amândoi un document și o valoare cheie

860
00:36:06,260 --> 00:36:08,412
stoca acest punct.

861
00:36:08,412 --> 00:36:10,620
Și tu poți argumenta caracteristicile
din unul peste celălalt.

862
00:36:10,620 --> 00:36:13,950
Pentru mine, o mulțime de acest lucru este într-adevăr șase
de o jumătate de duzină de celălalt.

863
00:36:13,950 --> 00:36:18,710
Fiecare dintre aceste tehnologii este un
Tehnologia FINE și o soluție amendă.

864
00:36:18,710 --> 00:36:23,390
Nu aș putea spune MongoDB este mai bine sau
mai rău decât Couch, atunci Cassandra,

865
00:36:23,390 --> 00:36:25,994
apoi Dynamo, sau invers.

866
00:36:25,994 --> 00:36:27,285
Adică, acestea sunt doar opțiuni.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> E rapid și e
consistent la orice scară.

869
00:36:32,700 --> 00:36:36,210
Deci, aceasta este una dintre cele mai mari
bonusuri te cu AWS.

870
00:36:36,210 --> 00:36:40,850
Cu DynamoDB este abilitatea
pentru a obține o singură cifră scăzută

871
00:36:40,850 --> 00:36:44,040
latență milisecunde la orice scară.

872
00:36:44,040 --> 00:36:45,720
Acesta a fost un obiectiv de proiectare a sistemului.

873
00:36:45,720 --> 00:36:49,130
Și avem clienti care fac
milioane de tranzacții pe secundă.

874
00:36:49,130 --> 00:36:52,670
>> Acum mă duc prin unele dintre cele
utiliza cazuri în câteva minute aici.

875
00:36:52,670 --> 00:36:55,660
Control-- acces integrat
avem ceea ce noi numim

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, sau IAM.

877
00:36:57,920 --> 00:37:01,980
Acesta pătrunde fiecare sistem,
fiecare serviciu care ofera AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB nu este o excepție.

879
00:37:03,630 --> 00:37:06,020
Puteți controla accesul
la tabelele DynamoDB.

880
00:37:06,020 --> 00:37:09,960
Peste toate AWS dumneavoastră conturile de
definirea rolurilor de acces și permisiuni

881
00:37:09,960 --> 00:37:12,140
în infrastructura IAM.

882
00:37:12,140 --> 00:37:16,630
>> Și este o componenta cheie și integrală în
ceea ce noi numim Event Driven programare.

883
00:37:16,630 --> 00:37:19,056
Acum, acest lucru este o nouă paradigmă.

884
00:37:19,056 --> 00:37:22,080
>> Audiența: Cum e rata de adevărat
pozitive față de rezultatele negative false

885
00:37:22,080 --> 00:37:24,052
pe sistemul dvs. de control al accesului?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: Adevărații pozitive
versus negative false?

887
00:37:26,260 --> 00:37:28,785
Audiența: Returnarea ce
ar trebui să fie întoarce?

888
00:37:28,785 --> 00:37:33,720
Spre deosebire de o dată într-un timp
nu se întoarce atunci când ar trebui să valideze?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: nu am putut să spun că.

891
00:37:38,050 --> 00:37:40,140
Dacă există defecțiuni
bazate pe faptul că,

892
00:37:40,140 --> 00:37:42,726
Eu nu sunt persoana de a cere
această întrebare special.

893
00:37:42,726 --> 00:37:43,850
Dar asta este o întrebare bună.

894
00:37:43,850 --> 00:37:45,905
Aș fi curios să știu
că eu, de fapt.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Și astfel apoi, din nou, nouă paradigmă
este de programare condus eveniment.

897
00:37:51,320 --> 00:37:55,160
Aceasta este ideea pe care le puteți
implementa aplicatii complexe care

898
00:37:55,160 --> 00:37:59,720
poate opera o foarte, foarte mare la scară
fără nici un fel de infrastructură.

899
00:37:59,720 --> 00:38:02,120
Fără nici o fix
Infrastructura fel.

900
00:38:02,120 --> 00:38:04,720
Și vom vorbi un pic
despre ceea ce înseamnă că pe măsură ce

901
00:38:04,720 --> 00:38:06,550
ajunge la următoarele două diagrame.

902
00:38:06,550 --> 00:38:08,716
>> Primul lucru pe care vom face
este vom vorbi despre mese.

903
00:38:08,716 --> 00:38:10,857
Tipuri de date API pentru Dinamo.

904
00:38:10,857 --> 00:38:13,190
Și primul lucru pe care veți
observă atunci când te uiți la asta,

905
00:38:13,190 --> 00:38:17,930
Dacă sunteți familiarizat cu orice bază de date,
baze de date într-adevăr două tipuri de API-uri

906
00:38:17,930 --> 00:38:18,430
Aș numi.

907
00:38:18,430 --> 00:38:21,570
Sau două seturi de API.

908
00:38:21,570 --> 00:38:23,840
Unul dintre acestea ar fi
API administrativă.

909
00:38:23,840 --> 00:38:26,710
>> Lucrurile pe care le avea grijă de
funcțiile bazei de date.

910
00:38:26,710 --> 00:38:31,340
Configurarea motorului de stocare,
înființarea și adăugarea mese.

911
00:38:31,340 --> 00:38:35,180
crearea de baze de date
cataloage și cazuri.

912
00:38:35,180 --> 00:38:40,450
Acestea lucruri-- în DynamoDB, tu
au liste foarte scurte, scurte.

913
00:38:40,450 --> 00:38:43,120
>> Deci, în alte baze de date,
s-ar putea vedea zeci

914
00:38:43,120 --> 00:38:45,680
de comenzi, de administrative
comenzi, pentru configurarea

915
00:38:45,680 --> 00:38:47,290
aceste opțiuni suplimentare.

916
00:38:47,290 --> 00:38:51,234
În DynamoDB nu aveți nevoie de cele din cauza
nu configurați sistemul, facem.

917
00:38:51,234 --> 00:38:54,150
Deci, singurul lucru ce trebuie sa faci este
spune-mi ce tabel dimensiune am nevoie.

918
00:38:54,150 --> 00:38:55,660
Astfel încât să obțineți o foarte
set limitat de comenzi.

919
00:38:55,660 --> 00:38:58,618
>> Ai un Creează masă actualizare, de masă,
Șterge de masă, și să descrie tabelul.

920
00:38:58,618 --> 00:39:01,150
Acestea sunt singurele lucruri
aveți nevoie pentru DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Nu aveți nevoie de un depozitare
configurație motor.

922
00:39:03,294 --> 00:39:04,960
Nu am nevoie să vă faceți griji cu privire la replicarea.

923
00:39:04,960 --> 00:39:06,490
Nu am nevoie să vă faceți griji cu privire la sharding.

924
00:39:06,490 --> 00:39:07,800
>> Nu am nevoie să vă faceți griji
cu privire la orice din astea.

925
00:39:07,800 --> 00:39:08,740
Noi face totul pentru tine.

926
00:39:08,740 --> 00:39:11,867
Deci asta este o mare cantitate de deasupra capului
asta e doar decolat farfurie.

927
00:39:11,867 --> 00:39:13,200
Apoi avem operatorii CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD este ceva ce noi
apel în baza de date care este

929
00:39:17,740 --> 00:39:19,860
Crea, actualiza, Ștergere operatori.

930
00:39:19,860 --> 00:39:24,180
Acestea sunt comune dvs.
operațiunile de bază de date.

931
00:39:24,180 --> 00:39:31,299
Lucruri ca element pune, pentru a primi obiect, actualizare
articole, șterge elemente, interogare lot, scanare.

932
00:39:31,299 --> 00:39:32,840
Dacă doriți să scanați întregul tabel.

933
00:39:32,840 --> 00:39:34,220
Trageți totul pe masă.

934
00:39:34,220 --> 00:39:37,130
Unul dintre lucrurile frumoase despre DynamoDB
este permite scanarea în paralel.

935
00:39:37,130 --> 00:39:40,602
Astfel încât să puteți de fapt, să-mi spuneți cât de multe
fire vrei să ruleze pe acea scanare.

936
00:39:40,602 --> 00:39:41,810
Și putem rula aceste fire.

937
00:39:41,810 --> 00:39:43,985
Putem roti care scana până
peste mai multe fire

938
00:39:43,985 --> 00:39:49,060
astfel încât să puteți scana întregul tabel
spațiu foarte, foarte repede în DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Celălalt API avem este
ceea ce noi numim Streams API-ul nostru.

940
00:39:51,490 --> 00:39:52,940
Noi nu o să vorbesc prea
mult despre asta acum.

941
00:39:52,940 --> 00:39:55,189
Am o parte a conținutului mai târziu
pe de punte despre acest lucru.

942
00:39:55,189 --> 00:39:59,910
Dar este într-adevăr un Streams running--
cred ca e timpul ordonat

943
00:39:59,910 --> 00:40:01,274
și schimbare partiție jurnal.

944
00:40:01,274 --> 00:40:03,940
Tot ce se întâmplă pe
tabelul apare pe fluxul.

945
00:40:03,940 --> 00:40:05,940
>> Fiecare scrie la masa
apare pe fluxul.

946
00:40:05,940 --> 00:40:08,370
Puteți citi acel flux și
poti sa faci lucruri cu ea.

947
00:40:08,370 --> 00:40:10,150
Vom vorbi despre ceea ce
tipuri de lucruri pe care le

948
00:40:10,150 --> 00:40:13,680
a face cu lucruri, cum ar fi replicare,
crearea indici secundari.

949
00:40:13,680 --> 00:40:17,620
Toate tipurile de foarte cool
lucruri pe care le pot face cu asta.

950
00:40:17,620 --> 00:40:19,150
>> Tipuri de date.

951
00:40:19,150 --> 00:40:23,320
În DynamoDB, susținem atât cheie
valoare și de date de documente tipuri.

952
00:40:23,320 --> 00:40:26,350
Pe partea stângă a ecranului
aici, avem tipuri de noastre de bază.

953
00:40:26,350 --> 00:40:27,230
Tipuri de valoare cheie.

954
00:40:27,230 --> 00:40:30,040
Acestea sunt siruri de caractere,
numere, și binare.

955
00:40:30,040 --> 00:40:31,640
>> Deci, doar trei tipuri de bază.

956
00:40:31,640 --> 00:40:33,700
Și apoi puteți avea seturi de cele.

957
00:40:33,700 --> 00:40:37,650
Unul dintre lucrurile frumoase despre NoSQL este
vă pot conține tablouri ca proprietăți.

958
00:40:37,650 --> 00:40:42,050
Și cu DynamoDB puteti conține tablouri
de tipuri de bază ca o proprietate rădăcină.

959
00:40:42,050 --> 00:40:43,885
>> Și apoi există tipurile de documente.

960
00:40:43,885 --> 00:40:45,510
Cât de mulți oameni sunt familiarizati cu JSON?

961
00:40:45,510 --> 00:40:47,130
Voi familiarizat cu JSON atât de mult?

962
00:40:47,130 --> 00:40:49,380
Este practic JavaScript,
Obiect, Notation.

963
00:40:49,380 --> 00:40:52,510
Acesta vă permite să practic
definesc o structură ierarhică.

964
00:40:52,510 --> 00:40:58,107
>> Puteți stoca un document JSON pe
DynamoDB folosind componente comune

965
00:40:58,107 --> 00:41:00,940
sau blocuri care sunt disponibile
în cele mai multe limbaje de programare.

966
00:41:00,940 --> 00:41:03,602
Deci, dacă aveți Java, ești
uita la hărți și liste.

967
00:41:03,602 --> 00:41:05,060
Pot crea obiecte zona harta.

968
00:41:05,060 --> 00:41:08,030
O hartă ca valori cheie
stocate ca proprietăți.

969
00:41:08,030 --> 00:41:10,890
Și ar putea avea liste de
valori în acele proprietăți.

970
00:41:10,890 --> 00:41:13,490
Puteți stoca acest complex
structură ierarhică

971
00:41:13,490 --> 00:41:16,320
ca un singur atribut
de un element DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Deci, tabele în DynamoDB, la fel ca majoritatea
Baze de date NoSQL, tabele au produs.

974
00:41:24,460 --> 00:41:26,469
În MongoDB v-ar
numesc aceste documente.

975
00:41:26,469 --> 00:41:27,760
Și ar fi baza canapea.

976
00:41:27,760 --> 00:41:28,900
De asemenea, o bază de date de documente.

977
00:41:28,900 --> 00:41:29,941
Te sun aceste documente.

978
00:41:29,941 --> 00:41:32,930
Documentele sau elementele au atribute.

979
00:41:32,930 --> 00:41:35,850
Atribute pot exista sau
nu exista pe elementul.

980
00:41:35,850 --> 00:41:38,520
În DynamoDB, există
un atribut obligatoriu.

981
00:41:38,520 --> 00:41:43,880
La fel ca într-o bază de date relațională,
aveți o cheie primară pe masă.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB are ceea ce noi numim o cheie hash.

983
00:41:46,010 --> 00:41:48,280
Tasta Diez trebuie să fie unic.

984
00:41:48,280 --> 00:41:52,580
Așa că atunci când am defini un tabel hash,
Practic ceea ce vreau să spun

985
00:41:52,580 --> 00:41:54,110
este fiecare element va avea o cheie hash.

986
00:41:54,110 --> 00:41:58,520
Și fiecare tasta Diez trebuie să fie unic.

987
00:41:58,520 --> 00:42:01,200
>> Fiecare element este definit
de care cheie unică hash.

988
00:42:01,200 --> 00:42:02,940
Și nu poate fi decât unul.

989
00:42:02,940 --> 00:42:05,820
Acest lucru este OK, dar de multe ori
ceea ce oamenii au nevoie

990
00:42:05,820 --> 00:42:08,170
este ce doresc este acest hash
cheie pentru a face un pic mai mult

991
00:42:08,170 --> 00:42:11,010
decât să fie doar un identificator unic.

992
00:42:11,010 --> 00:42:15,240
Deseori am doriți să utilizați cheia hash
ca partea de sus cupei nivel de agregare.

993
00:42:15,240 --> 00:42:19,160
Și modul în care face acest lucru este de
adăugând ceea ce noi numim o cheie gama.

994
00:42:19,160 --> 00:42:22,460
>> Deci, dacă e doar un hash
tabel, aceasta trebuie să fie unic.

995
00:42:22,460 --> 00:42:27,040
Daca este un tabel hash și interval,
combinație de hash și gama

996
00:42:27,040 --> 00:42:28,640
trebuie să fie unic.

997
00:42:28,640 --> 00:42:30,110
Deci, cred că despre el în acest fel.

998
00:42:30,110 --> 00:42:32,140
Dacă am un forum.

999
00:42:32,140 --> 00:42:39,010
Și forma are subiecte, nu are
posturi, și are răspunsuri.

1000
00:42:39,010 --> 00:42:42,630
>> Așa că am putea avea un hash
cheie, care este ID-ul subiect.

1001
00:42:42,630 --> 00:42:46,650
Și ar putea să am o cheie interval,
care este ID răspuns.

1002
00:42:46,650 --> 00:42:49,650
În acest fel, dacă vreau pentru a obține toate
Răspunsurile pentru anumit subiect,

1003
00:42:49,650 --> 00:42:52,370
Eu poate interoga doar hash.

1004
00:42:52,370 --> 00:42:55,190
Pot spune doar da-mi tot
elementele care au acest hash.

1005
00:42:55,190 --> 00:43:01,910
Și am de gând pentru a obține fiecare întrebare
sau posta pentru acest subiect particular.

1006
00:43:01,910 --> 00:43:03,910
Aceste agregate la nivel de top
sunt foarte importante.

1007
00:43:03,910 --> 00:43:07,370
Acestea susțin accesul primar
model al cererii.

1008
00:43:07,370 --> 00:43:09,420
În general vorbind, acest
este ceea ce vrem să facem.

1009
00:43:09,420 --> 00:43:11,780
Dorim ca table--
în timp ce încărcați masa,

1010
00:43:11,780 --> 00:43:16,640
vrem să structureze datele
La masa în așa fel

1011
00:43:16,640 --> 00:43:20,140
că cererea poate foarte
prelua rapid aceste rezultate.

1012
00:43:20,140 --> 00:43:24,510
Și deseori modul de a face acest lucru este
pentru a menține aceste agregări Așa cum am

1013
00:43:24,510 --> 00:43:25,650
introduce datele.

1014
00:43:25,650 --> 00:43:31,110
Practic, suntem răspândirea datelor
în găleată luminos ca vine in.

1015
00:43:31,110 --> 00:43:35,210
>> Tastele Gama permite hash mine--
Tastele trebuie să fie egalitate.

1016
00:43:35,210 --> 00:43:39,490
Când m-am interoga un hash, trebuie să spun
da-mi un hash care este egal cu acest lucru.

1017
00:43:39,490 --> 00:43:41,950
Când m-am interoga o gamă, am
pot spune da-mi o gama

1018
00:43:41,950 --> 00:43:47,040
care utilizează orice tip de
Operatorul bogat pe care le susține.

1019
00:43:47,040 --> 00:43:49,200
Dă-mi toate elementele pentru un hash.

1020
00:43:49,200 --> 00:43:52,520
Este egal, mai mare decât,
mai puțin, nu-l începe cu,

1021
00:43:52,520 --> 00:43:54,145
nu mai există între aceste două valori?

1022
00:43:54,145 --> 00:43:56,811
Deci, aceste tipuri de interogări gama
că suntem mereu interesati de.

1023
00:43:56,811 --> 00:43:59,650
Acum un lucru despre datele, atunci când
te uiți la accesarea datelor, atunci când

1024
00:43:59,650 --> 00:44:02,360
ai acces la date, e
mereu despre o agregare.

1025
00:44:02,360 --> 00:44:05,770
E mereu despre înregistrările
care sunt legate de această.

1026
00:44:05,770 --> 00:44:10,390
Dă-mi tot ce aici that's-- toate
tranzacțiile de pe acest card de credit

1027
00:44:10,390 --> 00:44:12,500
pentru ultima lună.

1028
00:44:12,500 --> 00:44:13,960
Asta e un agregare.

1029
00:44:13,960 --> 00:44:17,490
>> Aproape tot ceea ce face în
bază de date este un fel de agregare.

1030
00:44:17,490 --> 00:44:21,530
Deci fiind capabil să fie în măsură să definească
aceste găleți și vă va oferi aceste gama

1031
00:44:21,530 --> 00:44:24,950
atribute pentru a putea interoga pe,
aceste interogări bogate sprijini mulți,

1032
00:44:24,950 --> 00:44:27,165
multe, multe modele de acces cerere.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Deci celălalt lucru pe tasta Diez
Are este ne dă un mecanism

1035
00:44:35,000 --> 00:44:37,740
să fie capabil să se răspândească datele jurul.

1036
00:44:37,740 --> 00:44:40,390
Baze de date NoSQL funcționează cel mai bine
când datele sunt uniform

1037
00:44:40,390 --> 00:44:41,740
distribuite pe cluster.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Cât de mulți oameni sunt familiarizati
cu hashing algoritmi?

1040
00:44:47,050 --> 00:44:49,860
Când spun hash și o hashing--
pentru că un algoritm de hashing

1041
00:44:49,860 --> 00:44:54,140
este un mod de a fi în măsură să genereze
o valoare aleatoare de la orice valoare dată.

1042
00:44:54,140 --> 00:44:59,300
Deci, în acest caz particular,
algoritmul hash vom rula este ND 5 pe baza.

1043
00:44:59,300 --> 00:45:04,765
>> Și dacă am un ID, iar acest lucru
este cheia hash, am 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Când m-am rula algoritmul hash,
este de gând să se întoarcă și să spună,

1045
00:45:07,390 --> 00:45:10,800
bine 1 este egal cu 7B, 2
este egal cu 48, 3 este egal cu CD.

1046
00:45:10,800 --> 00:45:13,092
Sunt răspândit peste tot în spațiul cheie.

1047
00:45:13,092 --> 00:45:14,050
Și de ce faci asta?

1048
00:45:14,050 --> 00:45:17,120
Pentru că face sigur că pot
pune înregistrările pe mai multe noduri.

1049
00:45:17,120 --> 00:45:19,574
>> Dacă fac asta
incremental, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Și am o gamă hash care
execută în acest caz particular,

1051
00:45:21,990 --> 00:45:24,785
un spațiu hash mic,
ruleaza de la 00 la FF,

1052
00:45:24,785 --> 00:45:27,951
apoi înregistrările sunt de gând să vină în
și ei vor să meargă 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
Ce se întâmplă?

1055
00:45:31,800 --> 00:45:34,860
Fiecare inserție va același nod.

1056
00:45:34,860 --> 00:45:36,070
Vezi ce vreau să spun?

1057
00:45:36,070 --> 00:45:40,910
>> Pentru că atunci când am împărțit spațiul,
și am răspândit aceste înregistrări peste,

1058
00:45:40,910 --> 00:45:45,950
și partiție I, am de gând să spun
partiție 1 are spațiu cheie 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partition 2 este 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partition 3 este AA de FF.

1061
00:45:49,780 --> 00:45:53,740
Deci, dacă eu sunt, folosind liniar incrementarea
ID-uri, puteți vedea ce se întâmplă.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, toate drumul până la 54.

1063
00:45:57,410 --> 00:46:00,030
Deci, ca eu sunt percuție
înregistrări în sistem,

1064
00:46:00,030 --> 00:46:02,030
totul sfârșește merge la un nod.

1065
00:46:02,030 --> 00:46:03,160
>> Asta nu este bine.

1066
00:46:03,160 --> 00:46:04,820
Asta e un antipattern.

1067
00:46:04,820 --> 00:46:08,760
În MongoDB au această problemă
dacă nu utilizați o cheie hash.

1068
00:46:08,760 --> 00:46:11,325
MongoDB vă oferă opțiunea de
de hashing valoarea cheii.

1069
00:46:11,325 --> 00:46:13,950
Tu ar trebui să facă întotdeauna că, în cazul în care
utilizați un hash incrementare

1070
00:46:13,950 --> 00:46:17,380
cheie în MongoDB, sau veți fi
cuie fiecare scriere la un nod,

1071
00:46:17,380 --> 00:46:21,290
și veți fi limitarea
tranzitată dumneavoastră scrie prost.

1072
00:46:21,290 --> 00:46:24,896
>> Audiența: Este A9 169 în zecimal?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Da, e
undeva în jurul valorii de acolo.

1074
00:46:28,450 --> 00:46:29,950
A9, nu știu.

1075
00:46:29,950 --> 00:46:32,200
Ar trebui să se binar meu
la calculator zecimal.

1076
00:46:32,200 --> 00:46:34,237
Creierul meu nu funcționează așa.

1077
00:46:34,237 --> 00:46:36,320
Audiența: Doar una rapidă
de comentariile tale Mongo.

1078
00:46:36,320 --> 00:46:39,530
Deci este ID-ul de obiect care vine
nativ cu Mongo face asta?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Are face asta?

1081
00:46:41,470 --> 00:46:42,970
Dacă îl specificați.

1082
00:46:42,970 --> 00:46:45,030
Cu MongoDB, aveți opțiunea.

1083
00:46:45,030 --> 00:46:48,930
Puteți specify-- fiecare document
MongoDB trebuie să aibă un ID de subliniere.

1084
00:46:48,930 --> 00:46:50,300
Asta e valoarea unică.

1085
00:46:50,300 --> 00:46:55,240
>> În MongoDB puteți specifica
dacă să-l hash sau nu.

1086
00:46:55,240 --> 00:46:56,490
Ei doar vă oferă opțiunea.

1087
00:46:56,490 --> 00:46:58,198
Dacă știți că este
aleatoare, nici o problema.

1088
00:46:58,198 --> 00:46:59,640
Nu aveți nevoie să faci asta.

1089
00:46:59,640 --> 00:47:04,260
Dacă știți că nu este întâmplătoare, care
este incrementarea, apoi face hash.

1090
00:47:04,260 --> 00:47:06,880
>> Acum, lucru despre
hashing, odată ce hash

1091
00:47:06,880 --> 00:47:08,800
un value-- și aceasta este
de ce chei hash sunt întotdeauna

1092
00:47:08,800 --> 00:47:13,740
interogări unice, pentru că m-am schimbat
valoarea, acum eu nu pot face o interogare domeniu.

1093
00:47:13,740 --> 00:47:15,640
Nu pot să spun este aceasta
între acest lucru sau că,

1094
00:47:15,640 --> 00:47:20,800
deoarece valoarea hash nu se va
să fie echivalentă cu valoarea reală.

1095
00:47:20,800 --> 00:47:24,570
Deci, atunci când hash care
cheie, e doar egalitatea.

1096
00:47:24,570 --> 00:47:28,700
De aceea, în tasta Diez DynamoDB
interogări sunt întotdeauna doar egalitatea.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Deci, acum într-o gamă key--
când am adăuga că cheia interval,

1099
00:47:34,700 --> 00:47:38,180
aceste înregistrări cheie cu rază venit tot în și
contră, se depozitează pe aceeași partiție.

1100
00:47:38,180 --> 00:47:42,430
Astfel încât acestea sunt foarte repede, usor
recuperat deoarece aceasta este hash,

1101
00:47:42,430 --> 00:47:43,220
aceasta este gama.

1102
00:47:43,220 --> 00:47:44,928
Și veți vedea totul
cu același hash

1103
00:47:44,928 --> 00:47:48,550
se stocate pe același spațiu partiție.

1104
00:47:48,550 --> 00:47:53,889
Puteți folosi cheia pentru a ajuta la gama
localiza datele aproape de mamă.

1105
00:47:53,889 --> 00:47:55,180
Deci, ce caut eu de fapt aici?

1106
00:47:55,180 --> 00:47:57,320
Acesta este unul de foarte multe relații.

1107
00:47:57,320 --> 00:48:01,490
Relația dintre o cheie hash
iar cheia gama este unul de multe.

1108
00:48:01,490 --> 00:48:03,490
Pot avea mai multe chei hash.

1109
00:48:03,490 --> 00:48:07,610
Eu pot avea doar gama multiple
Taste în fiecare tasta Diez.

1110
00:48:07,610 --> 00:48:11,910
>> Hash definește părinte,
intervalul definește copiilor.

1111
00:48:11,910 --> 00:48:15,240
Deci, puteți vedea acolo este analog aici
între constructul relațional

1112
00:48:15,240 --> 00:48:18,840
și aceleași tipuri de
construiește în NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Oamenii vorbesc despre
NoSQL ca nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Nu e nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Date are întotdeauna relații.

1116
00:48:24,680 --> 00:48:28,172
Aceste relații doar
sunt modelate diferit.

1117
00:48:28,172 --> 00:48:29,880
Hai sa vorbim un pic
bit despre durabilitate.

1118
00:48:29,880 --> 00:48:34,860
Când scrie DynamoDB, scrie
sunt întotdeauna trei căi replicat.

1119
00:48:34,860 --> 00:48:37,550
Ceea ce înseamnă că avem trei de AZ.

1120
00:48:37,550 --> 00:48:39,160
Lui AZ sunt zone de disponibilitate.

1121
00:48:39,160 --> 00:48:43,430
Vă puteți gândi la o disponibilitate
Zone ca un centru de date

1122
00:48:43,430 --> 00:48:45,447
sau o colectie de centre de date.

1123
00:48:45,447 --> 00:48:47,780
Aceste lucruri sunt punct de vedere geografic
izolate una de alta

1124
00:48:47,780 --> 00:48:51,610
în diferite zone de avarie, peste
diferite rețele electrice și zonele inundabile.

1125
00:48:51,610 --> 00:48:54,510
Un eșec într-o AZ nu este
va lua în jos un alt.

1126
00:48:54,510 --> 00:48:56,890
Ele sunt, de asemenea, legate
împreună cu fibra de întuneric.

1127
00:48:56,890 --> 00:49:01,240
Aceasta susține o sub 1
latență milisecunda între AZS.

1128
00:49:01,240 --> 00:49:05,390
Deci repetiții date în timp real
capabil în AZS multe.

1129
00:49:05,390 --> 00:49:09,990
>> Și implementări de multe ori mai multe AZ
să îndeplinească cerințele ridicate de disponibilitate

1130
00:49:09,990 --> 00:49:12,930
de cele mai multe organizatii Intreprindere.

1131
00:49:12,930 --> 00:49:16,139
Deci DynamoDB se răspândește
pe trei AZS implicit.

1132
00:49:16,139 --> 00:49:19,430
Vom doar la cunoștințe de scriere
atunci când două dintre aceste trei noduri întoarce

1133
00:49:19,430 --> 00:49:21,470
și spune, Da, am înțeles.

1134
00:49:21,470 --> 00:49:22,050
De ce este asta?

1135
00:49:22,050 --> 00:49:25,950
Deoarece pe partea citire suntem numai
gând să vă dau datele înapoi, atunci când

1136
00:49:25,950 --> 00:49:27,570
am lua de la două noduri.

1137
00:49:27,570 --> 00:49:30,490
>> Dacă am replicarea peste
trei, și am citit de la doi,

1138
00:49:30,490 --> 00:49:32,840
Sunt mereu garantat
să aibă cel puțin unul

1139
00:49:32,840 --> 00:49:35,720
din cei citește să fie
cele mai multe copie curentă a datelor.

1140
00:49:35,720 --> 00:49:38,340
Asta e ceea ce face DynamoDB consistent.

1141
00:49:38,340 --> 00:49:42,450
Acum puteți alege să activați
cei consistent citește off.

1142
00:49:42,450 --> 00:49:45,070
În cazul în care pe care am de gând să spun,
Voi citi doar la un nod.

1143
00:49:45,070 --> 00:49:47,430
Și nu pot garanta că va
să fie date mai recente.

1144
00:49:47,430 --> 00:49:49,450
>> Deci, dacă o scriere vine în,
acesta nu a replicat încă,

1145
00:49:49,450 --> 00:49:50,360
ai de gând pentru a obține că copie.

1146
00:49:50,360 --> 00:49:52,220
Asta e un citire în cele din urmă consistentă.

1147
00:49:52,220 --> 00:49:54,640
Și ce este este jumătate din costul.

1148
00:49:54,640 --> 00:49:56,140
Deci acest lucru este ceva să mă gândesc.

1149
00:49:56,140 --> 00:50:00,160
Când sunteți citire DynamoDB, și
te configurarea capacitatea de citire

1150
00:50:00,160 --> 00:50:04,430
de unități, dacă alegeți în cele din urmă
consistent citește, este mult mai ieftin,

1151
00:50:04,430 --> 00:50:06,010
este vorba despre jumătate din costul.

1152
00:50:06,010 --> 00:50:09,342
>> Și așa vă economisește bani.

1153
00:50:09,342 --> 00:50:10,300
Dar asta e alegerea ta.

1154
00:50:10,300 --> 00:50:12,925
Dacă doriți o citire consistent sau
o citire în cele din urmă consistentă.

1155
00:50:12,925 --> 00:50:15,720
Asta e ceva pe care le puteți alege.

1156
00:50:15,720 --> 00:50:17,659
>> Să vorbim despre indici.

1157
00:50:17,659 --> 00:50:19,450
Așa că am menționat că
agregare de nivel superior.

1158
00:50:19,450 --> 00:50:23,720
Avem chei hash, și
avem chei gama.

1159
00:50:23,720 --> 00:50:24,320
Este frumos.

1160
00:50:24,320 --> 00:50:26,950
Și asta e pe masă primar, am
Trebuie o cheie hash, am primit o cheie gama.

1161
00:50:26,950 --> 00:50:27,783
>> Ce inseamna?

1162
00:50:27,783 --> 00:50:30,410
Am un atribut pe care am
poate rula interogări bogate împotriva.

1163
00:50:30,410 --> 00:50:31,800
Este cheia gama.

1164
00:50:31,800 --> 00:50:35,530
Celelalte atribute pe care item--
Pot filtra pe acele atribute.

1165
00:50:35,530 --> 00:50:40,050
Dar eu nu pot face lucruri cum ar fi, ea
începe cu, sau este mai mare decât.

1166
00:50:40,050 --> 00:50:40,820
>> Cum să fac asta?

1167
00:50:40,820 --> 00:50:42,860
Am crea un index.

1168
00:50:42,860 --> 00:50:45,340
Există două tipuri de
indici în DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Un index este într-adevăr
o altă vedere a mesei.

1170
00:50:49,002 --> 00:50:50,490
Și indicele secundar locală.

1171
00:50:50,490 --> 00:50:51,781
>> Primul vom vorbi despre.

1172
00:50:51,781 --> 00:50:57,740
Secundare Deci locale sunt coexistat
pe aceeași partiție de date.

1173
00:50:57,740 --> 00:51:00,240
Și ca atare, ele sunt pe
același nod fizic.

1174
00:51:00,240 --> 00:51:01,780
Ele sunt ceea ce noi numim consistent.

1175
00:51:01,780 --> 00:51:04,599
Înțeles, ei vor recunoaște
write împreună cu tabelul.

1176
00:51:04,599 --> 00:51:06,890
În cazul în care scrie vine,
vom scrie prin indicele.

1177
00:51:06,890 --> 00:51:09,306
Vom scrie până la masa,
și atunci vom recunoaște.

1178
00:51:09,306 --> 00:51:10,490
Deci asta e consistent.

1179
00:51:10,490 --> 00:51:13,174
Odată ce a fost write
a recunoscut de la masă,

1180
00:51:13,174 --> 00:51:15,090
este garantat că
index secundar locală

1181
00:51:15,090 --> 00:51:18,380
va avea aceeași viziune de date.

1182
00:51:18,380 --> 00:51:22,390
Dar ceea ce vă permite să faceți este să
defini cheile gama alternative.

1183
00:51:22,390 --> 00:51:25,260
>> Trebuie să utilizeze același hash
cheie ca masa principala,

1184
00:51:25,260 --> 00:51:29,050
deoarece acestea sunt co-situat pe
aceeași partiție, și sunt coerente.

1185
00:51:29,050 --> 00:51:33,110
Dar pot crea un index
cu diferite chei gama.

1186
00:51:33,110 --> 00:51:41,590
Deci, de exemplu, în cazul în care am avut un producător
care a avut o masă piese crud vine.

1187
00:51:41,590 --> 00:51:44,590
Și piese de prime provin din, și
acestea sunt agregate de asamblare.

1188
00:51:44,590 --> 00:51:46,840
Și poate e un rechemare.

1189
00:51:46,840 --> 00:51:50,240
>> Orice parte care a fost făcută de către aceasta
Producator după această dată,

1190
00:51:50,240 --> 00:51:52,840
Am nevoie pentru a trage de la linia mea.

1191
00:51:52,840 --> 00:51:55,950
Pot roti un index
care ar fi în căutarea,

1192
00:51:55,950 --> 00:52:00,760
agregarea la data de
Fabricarea de partea particular.

1193
00:52:00,760 --> 00:52:03,930
Deci, dacă masa mea nivel de top a fost
deja distribuit de către producătorul,

1194
00:52:03,930 --> 00:52:07,655
Poate a fost amenajat pe partea de identitate, am
poate crea un index la tabel

1195
00:52:07,655 --> 00:52:11,140
cum distribuit de către producător și
a variat de la data fabricației.

1196
00:52:11,140 --> 00:52:14,490
Și așa am putea spune, ceva care
a fost fabricat intre aceste date,

1197
00:52:14,490 --> 00:52:16,804
Am nevoie pentru a trage de la linia.

1198
00:52:16,804 --> 00:52:18,220
Așa că e un index secundar local.

1199
00:52:18,220 --> 00:52:22,280
>> Acestea au ca efect
limitarea spațiu hash cheie.

1200
00:52:22,280 --> 00:52:24,360
Pentru că ei co-existat
pe același nod de depozitare,

1201
00:52:24,360 --> 00:52:26,860
limitează tasta Diez
spațiu pentru a 10 gigabytes.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, sub
tabele, va partiție

1203
00:52:28,950 --> 00:52:31,380
masa ta la fiecare 10 GB.

1204
00:52:31,380 --> 00:52:34,760
Când ai pus 10 de concerte de date în, am
du-te [PHH], și vom adăuga un alt nod.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Nu vom împărți LSI
peste partiții multiple.

1207
00:52:42,070 --> 00:52:43,200
Vom împărți masa.

1208
00:52:43,200 --> 00:52:44,679
Dar nu vom împărți LSI.

1209
00:52:44,679 --> 00:52:46,470
Deci asta e ceva
important să se înțeleagă

1210
00:52:46,470 --> 00:52:50,070
este dacă faci foarte,
foarte, foarte mari aglomerări,

1211
00:52:50,070 --> 00:52:53,860
atunci ai de gând să fie limitată
la 10 gigabytes pe chipuri LSI ta.

1212
00:52:53,860 --> 00:52:56,640
>> Dacă e cazul, putem
utilizați secundare la nivel mondial.

1213
00:52:56,640 --> 00:52:58,630
Secundare globale sunt
într-adevăr un alt tabel.

1214
00:52:58,630 --> 00:53:01,720
Ele există complet de pe la
partea de masa dumneavoastră primar.

1215
00:53:01,720 --> 00:53:04,680
Și-au permiteți-mi să găsească un
complet diferit structura.

1216
00:53:04,680 --> 00:53:08,010
Deci, cred că de ea ca este introdus date
în două tabele diferite, structurate

1217
00:53:08,010 --> 00:53:09,220
în două moduri diferite.

1218
00:53:09,220 --> 00:53:11,360
>> Pot defini o cu totul
diferit tasta Diez.

1219
00:53:11,360 --> 00:53:13,490
Pot defini o cu totul
cheie gamă diferită.

1220
00:53:13,490 --> 00:53:15,941
Și eu pot rula acest
complet independent.

1221
00:53:15,941 --> 00:53:18,190
Ca o chestiune de fapt, m-am
prevazut calitatea mea de citire

1222
00:53:18,190 --> 00:53:21,090
și scrie capacitate pentru meu
indici secundari globale

1223
00:53:21,090 --> 00:53:24,240
complet independent
de masa mea primară.

1224
00:53:24,240 --> 00:53:26,640
Dacă aș defini ca index, spun
ea cât de mult a scrie și a citi

1225
00:53:26,640 --> 00:53:28,610
Capacitate se va folosi.

1226
00:53:28,610 --> 00:53:31,490
>> Și care este separată
de la masa mea primară.

1227
00:53:31,490 --> 00:53:35,240
Acum atât indicilor ne permite să
defini nu numai chei hash și o gamă,

1228
00:53:35,240 --> 00:53:38,610
dar ne permit să
proiecta valorile suplimentare.

1229
00:53:38,610 --> 00:53:44,950
Deci, dacă vreau să citesc de pe index,
și vreau să obține unele set de date,

1230
00:53:44,950 --> 00:53:48,327
Nu am nevoie să mă întorc la principalele
tabel pentru a obține atribute suplimentare.

1231
00:53:48,327 --> 00:53:50,660
Pot proiect cele suplimentare
atribute în tabelul

1232
00:53:50,660 --> 00:53:53,440
pentru a sprijini modelul de accesare.

1233
00:53:53,440 --> 00:53:57,700
Știu că suntem probabil asistent, în unele
într-adevăr, really-- intra buruienile

1234
00:53:57,700 --> 00:53:58,910
aici, pe unele dintre aceste lucruri.

1235
00:53:58,910 --> 00:54:02,725
Acum am ajuns la deriva din aceasta.

1236
00:54:02,725 --> 00:54:07,320
>> Audiența: [inaudibil]
cheie --table însemnat a fost un hash?

1237
00:54:07,320 --> 00:54:08,840
Hash originală?

1238
00:54:08,840 --> 00:54:09,340
Multi-lamele?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Da.

1240
00:54:10,200 --> 00:54:11,070
Da.

1241
00:54:11,070 --> 00:54:15,260
Cheia de masă practic
punctele înapoi la elementul.

1242
00:54:15,260 --> 00:54:19,280
Deci un index este un pointer înapoi la
articolele originale de pe masă.

1243
00:54:19,280 --> 00:54:22,910
Acum puteți alege pentru a construi o
index care are doar cheia de masă,

1244
00:54:22,910 --> 00:54:24,840
și nici alte proprietăți.

1245
00:54:24,840 --> 00:54:26,570
Și de ce s-ar putea să fac asta?

1246
00:54:26,570 --> 00:54:28,570
Ei bine, poate am un produs foarte mari.

1247
00:54:28,570 --> 00:54:31,660
>> Am într-adevăr nevoie doar să știu which--
modelul meu de acces s-ar putea spune,

1248
00:54:31,660 --> 00:54:33,760
care conțin elemente această proprietate?

1249
00:54:33,760 --> 00:54:35,780
Nu au nevoie să se întoarcă elementul.

1250
00:54:35,780 --> 00:54:37,800
Vreau doar să știu
care elemente se conțin.

1251
00:54:37,800 --> 00:54:40,700
Astfel încât să puteți construi indici
care au doar cheia de masă.

1252
00:54:40,700 --> 00:54:43,360
>> Dar asta e în primul rând ceea ce
un index in baza de date este pentru.

1253
00:54:43,360 --> 00:54:46,280
Este pentru a fi în măsură să rapid
să identifice care înregistrează,

1254
00:54:46,280 --> 00:54:49,470
care rânduri, care
elemente din tabelul au

1255
00:54:49,470 --> 00:54:51,080
proprietățile pe care am căutați.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, așa cum funcționează?

1258
00:54:54,860 --> 00:54:58,340
GSIS practic sunt asincrone.

1259
00:54:58,340 --> 00:55:02,570
Actualizarea vine în tabel,
tabel este apoi actualizată asincron

1260
00:55:02,570 --> 00:55:03,720
toate GSIS dumneavoastră.

1261
00:55:03,720 --> 00:55:06,680
Acesta este motivul pentru GSIS sunt
în cele din urmă consistent.

1262
00:55:06,680 --> 00:55:09,440
>> Este important să rețineți că
atunci când sunteți construirea GSIS,

1263
00:55:09,440 --> 00:55:13,110
și ați înțeles ce crearea
o altă dimensiune a aggregation--

1264
00:55:13,110 --> 00:55:16,594
acum sa spunem un exemplu bun
aici este un producător.

1265
00:55:16,594 --> 00:55:19,260
Cred că s-ar fi vorbit despre
un producător de dispozitiv medical.

1266
00:55:19,260 --> 00:55:23,870
Producatorii de dispozitive medicale
au deseori părți serializate.

1267
00:55:23,870 --> 00:55:28,070
Piesele care merg în
o înlocuire a șoldului toate

1268
00:55:28,070 --> 00:55:30,200
au un pic de număr de serie pe ele.

1269
00:55:30,200 --> 00:55:33,584
Și ar putea avea milioane de oameni și
milioane și miliarde de piese

1270
00:55:33,584 --> 00:55:35,000
în toate dispozitivele pe care le transferă.

1271
00:55:35,000 --> 00:55:37,440
Ei bine, ei au nevoie pentru a agrega în
diferite dimensiuni, toate părțile

1272
00:55:37,440 --> 00:55:39,520
într-un ansamblu, toate
Piese care au fost făcute

1273
00:55:39,520 --> 00:55:41,670
pe o anumită linie, toate
piesele care au venit

1274
00:55:41,670 --> 00:55:44,620
de un anumit producător
la o anumită dată.

1275
00:55:44,620 --> 00:55:47,940
Și aceste agregări uneori
obține până în miliarde.

1276
00:55:47,940 --> 00:55:50,550
>> Așa că am de lucru cu unele dintre
tipii ăștia care suferă

1277
00:55:50,550 --> 00:55:53,156
pentru că sunt crearea
aceste agregate ginormous

1278
00:55:53,156 --> 00:55:54,280
în indexurile lor secundare.

1279
00:55:54,280 --> 00:55:57,070
Ei ar putea avea un piese brute
tabel care vine ca doar hash.

1280
00:55:57,070 --> 00:55:59,090
Fiecare parte are un număr de serie unic.

1281
00:55:59,090 --> 00:56:00,975
Eu folosesc numărul de serie ca hash.

1282
00:56:00,975 --> 00:56:01,600
E frumos.

1283
00:56:01,600 --> 00:56:04,160
Masa mea de date brute se răspândește
peste tot în spațiul cheie.

1284
00:56:04,160 --> 00:56:05,930
Mele [? a scrie ?]
[? ingestie?] este minunat.

1285
00:56:05,930 --> 00:56:07,876
Iau o mulțime de date.

1286
00:56:07,876 --> 00:56:09,500
Atunci ceea ce fac ei este că a crea un GSI.

1287
00:56:09,500 --> 00:56:12,666
Și să spun, știi ce, am nevoie pentru a vedea
toate piesele pentru acest producător.

1288
00:56:12,666 --> 00:56:15,060
Ei bine, dintr-o dată că sunt
luând un miliard de rânduri,

1289
00:56:15,060 --> 00:56:17,550
și le-a chestii pe
un nod, pentru că atunci când

1290
00:56:17,550 --> 00:56:21,170
Am agregate ca
ID-ul producător ca hash,

1291
00:56:21,170 --> 00:56:25,410
și numărul de o parte ca gama,
apoi dintr-o dată că sunt

1292
00:56:25,410 --> 00:56:30,530
punând un miliard de piese în ceea ce
acest producător mi-a dat.

1293
00:56:30,530 --> 00:56:34,447
>> Care poate provoca o mulțime
de presiune asupra GSI,

1294
00:56:34,447 --> 00:56:36,030
din nou, pentru că eu sunt percuție un nod.

1295
00:56:36,030 --> 00:56:38,350
Pun toate acestea
introduce într-un singur nod.

1296
00:56:38,350 --> 00:56:40,940
Și că este un adevărat caz de utilizare problematic.

1297
00:56:40,940 --> 00:56:43,479
Acum, am un design bun
model pentru modul în care evita ca.

1298
00:56:43,479 --> 00:56:45,770
Și asta e una din problemele
că întotdeauna lucrez cu.

1299
00:56:45,770 --> 00:56:49,590
Dar ce se întâmplă, este GSI ar putea
să nu aibă capacitatea de a scrie suficientă

1300
00:56:49,590 --> 00:56:52,330
să fie capabil să împingă pe toți cei
rânduri într-un singur nod.

1301
00:56:52,330 --> 00:56:55,390
Și ce se întâmplă atunci este
primar, tabelul client,

1302
00:56:55,390 --> 00:57:00,180
tabelul primar va fi sugrumat
pentru că GSI nu poate ține pasul.

1303
00:57:00,180 --> 00:57:02,980
Deci, rata mea de inserție va
cad pe masă primar

1304
00:57:02,980 --> 00:57:06,230
ca GSI mea încearcă să țină pasul.

1305
00:57:06,230 --> 00:57:08,850
>> Bine, deci a GSI, lui LSI,
care unul ar trebui sa folosesc?

1306
00:57:08,850 --> 00:57:12,290
Lui LSI sunt coerente.

1307
00:57:12,290 --> 00:57:13,750
Lui GSI sunt în cele din urmă coerente.

1308
00:57:13,750 --> 00:57:17,490
Dacă e OK, am recomandăm să utilizați un
GSI, sunt mult mai flexibile.

1309
00:57:17,490 --> 00:57:20,270
Lui LSI poate fi modelat ca un GSI.

1310
00:57:20,270 --> 00:57:27,040
Și dacă dimensiunea datelor pe chei hash în
Colecția depășește 10 gigaocteți,

1311
00:57:27,040 --> 00:57:31,050
atunci ai de gând să doriți să utilizați că
GSI pentru ca este doar o limită de greu.

1312
00:57:31,050 --> 00:57:32,035
>> Bine, așa scalare.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Tranzitată în Dynamo DB, tu
dispoziție poate [Inaudibil]

1315
00:57:37,460 --> 00:57:38,680
throughput la o masă.

1316
00:57:38,680 --> 00:57:42,740
Avem clienti care au
prevazute 60 billion--

1317
00:57:42,740 --> 00:57:45,970
fac 60 de miliarde de cereri, în mod regulat
rulează la peste un milion de cereri

1318
00:57:45,970 --> 00:57:47,790
pe secundă la mesele noastre.

1319
00:57:47,790 --> 00:57:50,360
Nu e într-adevăr nici
limită teoretică la cât de mult

1320
00:57:50,360 --> 00:57:53,730
și cât de repede la masa
poate rula in Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Există unele moi
limite în contul dvs.

1322
00:57:55,920 --> 00:57:58,170
că am pus acolo, astfel
care nu te duci nebun.

1323
00:57:58,170 --> 00:58:00,070
Dacă doriți mai mult
că, nu o problemă.

1324
00:58:00,070 --> 00:58:00,820
Ai venit să ne spuneți.

1325
00:58:00,820 --> 00:58:02,810
Vom întoarce cadran.

1326
00:58:02,810 --> 00:58:08,210
>> Fiecare cont este limitată la un anumit nivel
în fiecare serviciu, chiar de la început

1327
00:58:08,210 --> 00:58:11,920
astfel încât oamenii nu merg nebun
se ajunge în necazuri.

1328
00:58:11,920 --> 00:58:12,840
Nici o limită în mărime.

1329
00:58:12,840 --> 00:58:14,940
Puteți pune orice număr
de elemente de pe o masă.

1330
00:58:14,940 --> 00:58:17,620
Dimensiunea unui element este
limitate la 400 kilobiți fiecare,

1331
00:58:17,620 --> 00:58:20,050
care ar fi nu element atributele.

1332
00:58:20,050 --> 00:58:24,200
Deci suma tuturor atributelor
se limitează la 400 kilobytes.

1333
00:58:24,200 --> 00:58:27,300
Și apoi din nou, ne-am
că puțin problemă LSI

1334
00:58:27,300 --> 00:58:30,405
cu limita de 10 gigabyte pe hash.

1335
00:58:30,405 --> 00:58:33,280
Audiența: numărul mic, mi-e dor
ceea ce-mi spui, că este--

1336
00:58:33,280 --> 00:58:36,830
Audiența: Oh, 400 kilobyte
este dimensiunea maximă pentru fiecare element.

1337
00:58:36,830 --> 00:58:39,570
Deci, un element are toate atributele.

1338
00:58:39,570 --> 00:58:43,950
Deci 400 k este mărimea totală
de acel element, 400 kilobytes.

1339
00:58:43,950 --> 00:58:46,170
Deci din toate atributele
combinate, toate datele

1340
00:58:46,170 --> 00:58:49,140
care este în toate aceste atribute,
rulată într-o dimensiune totală,

1341
00:58:49,140 --> 00:58:51,140
în prezent astăzi limita produs este de 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Deci scalarea din nou, realizat
prin partiționare.

1344
00:58:57,046 --> 00:58:58,920
De transfer este prevazuta
la nivelul masă.

1345
00:58:58,920 --> 00:59:00,160
Și există într-adevăr două butoane.

1346
00:59:00,160 --> 00:59:02,400
Am citit capacitate
și scrie capacitate.

1347
00:59:02,400 --> 00:59:05,530
>> Deci, acestea sunt ajustate
independent unul de celălalt.

1348
00:59:05,530 --> 00:59:08,640
Măsură RCU lui strict citește consistent.

1349
00:59:08,640 --> 00:59:13,005
OK, deci, dacă vrei să spui vreau 1000
Lui RCU acestea sunt strict coerente,

1350
00:59:13,005 --> 00:59:14,130
acestea sunt coerente citește.

1351
00:59:14,130 --> 00:59:17,130
Dacă spui vreau
eventual consistent citește,

1352
00:59:17,130 --> 00:59:19,402
puteți dispoziție 1.000
Lui RCU, te duci

1353
00:59:19,402 --> 00:59:21,840
pentru a obține în cele din urmă 2.000
consistent citește.

1354
00:59:21,840 --> 00:59:25,940
Și la jumătate de preț pentru cei
în cele din urmă constau citește.

1355
00:59:25,940 --> 00:59:28,520
>> Din nou, ajustat
independent unul de celălalt.

1356
00:59:28,520 --> 00:59:32,900
Și ei au throughput--
Dacă ați consuma 100% din RCU dumneavoastră,

1357
00:59:32,900 --> 00:59:35,960
nu vei a impactului
Disponibilitatea drepturile.

1358
00:59:35,960 --> 00:59:40,161
Astfel încât acestea sunt complet
independente una de cealaltă.

1359
00:59:40,161 --> 00:59:43,160
Bine, deci unul din lucrurile pe care
Am menționat pe scurt a fost throttling.

1360
00:59:43,160 --> 00:59:44,320
Laminare este rău.

1361
00:59:44,320 --> 00:59:47,311
Restricție indică rău nu SQL.

1362
00:59:47,311 --> 00:59:50,310
Există lucruri pe care le putem face pentru a ajuta la
ai atenua throttling care

1363
00:59:50,310 --> 00:59:51,040
se confruntă.

1364
00:59:51,040 --> 00:59:53,240
Dar cea mai bună soluție
la acest lucru este să luăm

1365
00:59:53,240 --> 00:59:58,000
o privire la ceea ce faci, pentru că
există un anti-model în joc aici.

1366
00:59:58,000 --> 01:00:02,140
>> Aceste lucruri, lucruri cum ar fi non-uniform
volumul de lucru, taste, paravane încinse.

1367
01:00:02,140 --> 01:00:06,210
Am lovit un anumit spațiu cheie
foarte greu pentru un motiv special.

1368
01:00:06,210 --> 01:00:07,080
De ce fac asta?

1369
01:00:07,080 --> 01:00:08,710
Să dai seama.

1370
01:00:08,710 --> 01:00:10,427
Sunt de amestecare datele mele calde cu datele reci.

1371
01:00:10,427 --> 01:00:12,510
Mă lăsa tabele mele Ia
uriaș, dar există într-adevăr

1372
01:00:12,510 --> 01:00:15,970
doar unele subset al datelor
care este foarte interesant pentru mine.

1373
01:00:15,970 --> 01:00:20,290
Deci, pentru a datelor jurnal, de exemplu, o mulțime de
clienții, ei a lua jurnal de date în fiecare zi.

1374
01:00:20,290 --> 01:00:22,490
Au o mare cantitate de date jurnal.

1375
01:00:22,490 --> 01:00:25,940
>> Dacă sunteți doar dumping toate jurnal
date într-un singur tabel mare, în timp

1376
01:00:25,940 --> 01:00:28,070
acest tabel va obține masive.

1377
01:00:28,070 --> 01:00:30,950
Dar eu sunt foarte interesat doar de
ultimele 24 de ore, ultimele șapte zile,

1378
01:00:30,950 --> 01:00:31,659
ultimele 30 de zile.

1379
01:00:31,659 --> 01:00:34,074
Oricare ar fi fereastra de timp
că eu sunt interesat de căutarea

1380
01:00:34,074 --> 01:00:37,010
pentru cazul în care mă deranjează, sau
cazul în care este interesant pentru mine,

1381
01:00:37,010 --> 01:00:39,540
că este fereastra singura dată când am nevoie.

1382
01:00:39,540 --> 01:00:42,470
Deci, de ce sunt eu de 10 de ani a pune
în valoare de date jurnal din tabel?

1383
01:00:42,470 --> 01:00:45,030
Ce cauzeaza este că
tabelul fragmentul.

1384
01:00:45,030 --> 01:00:45,880
>> Ea devine imens.

1385
01:00:45,880 --> 01:00:48,340
Se începe întindere
peste mii de noduri.

1386
01:00:48,340 --> 01:00:51,380
Si din moment ce capacitatea de
este atât de scăzut, esti

1387
01:00:51,380 --> 01:00:54,090
rata de fapt, limitarea pe fiecare
unul dintre aceste noduri individuale.

1388
01:00:54,090 --> 01:00:57,120
Așa că haideți să începem uita la cum
avem rola acea masă de peste.

1389
01:00:57,120 --> 01:01:01,502
Cum reușim un pic ca datele
mai bine pentru a evita aceste probleme.

1390
01:01:01,502 --> 01:01:02,710
Și ce care arata ca?

1391
01:01:02,710 --> 01:01:04,370
Aceasta este ceea ce pare ca la fel ca.

1392
01:01:04,370 --> 01:01:06,790
Aceasta este ceea ce pare rău NoSQL ca.

1393
01:01:06,790 --> 01:01:07,830
>> Am o cheie fierbinte aici.

1394
01:01:07,830 --> 01:01:10,246
Dacă te uiți în partea de aici,
acestea sunt toate partițiile mele.

1395
01:01:10,246 --> 01:01:12,630
M-am 16 partiții aici
pe această bază de date special.

1396
01:01:12,630 --> 01:01:13,630
Facem acest lucru tot timpul.

1397
01:01:13,630 --> 01:01:15,046
Eu conduc acest lucru pentru clienții toate timpurile.

1398
01:01:15,046 --> 01:01:16,550
Se numește harta de căldură.

1399
01:01:16,550 --> 01:01:20,590
Harta de căldură mi-a spus cum te
accesarea spațiu cheie.

1400
01:01:20,590 --> 01:01:23,700
Și ce-mi spune acest lucru este este
că există un anumit hash

1401
01:01:23,700 --> 01:01:26,330
că tipul ăsta îi place un
foarte mult, pentru că el este

1402
01:01:26,330 --> 01:01:28,250
lovind într-adevăr, foarte greu.

1403
01:01:28,250 --> 01:01:29,260
>> Deci albastru este frumos.

1404
01:01:29,260 --> 01:01:29,900
Ne place albastru.

1405
01:01:29,900 --> 01:01:30,720
Noi nu le place roșu.

1406
01:01:30,720 --> 01:01:33,120
Roșu, unde presiunea
ajunge până la 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, acum vei fi sugrumat.

1408
01:01:35,560 --> 01:01:39,030
Deci de fiecare dată când vedeți linii roșii, cum ar fi
astea-- și nu e doar Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
fiecare bază de date NoSQL are această problemă.

1410
01:01:41,630 --> 01:01:44,640
Există anti-modele care pot
conduce aceste tipuri de condiții.

1411
01:01:44,640 --> 01:01:49,070
Ceea ce fac este lucrez cu clienții
pentru a atenua aceste condiții.

1412
01:01:49,070 --> 01:01:51,840
>> Și ce care arata ca?

1413
01:01:51,840 --> 01:01:54,260
Și acest lucru este obtinerea cele mai multe
din transfer Dynamo DB,

1414
01:01:54,260 --> 01:01:56,176
dar este foarte asistent
mai mult de NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Acest lucru nu se limitează la Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Acest lucru este I definitely--
a lucrat la Mongo.

1417
01:02:02,050 --> 01:02:04,090
Sunt familiarizat cu mai multe platforme NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Fiecare are aceste tipuri
de probleme fierbinți cheie.

1419
01:02:06,830 --> 01:02:10,320
Pentru a obține cele mai multe din orice NoSQL
baze de date, în special Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
doriți să creați tabelele
în cazul în care elementul cheie hash are

1421
01:02:13,320 --> 01:02:18,590
un număr mare de valori distincte,
un grad ridicat de cardinalitatea.

1422
01:02:18,590 --> 01:02:22,530
Pentru că înseamnă că scriu
la o mulțime de diferite cupe.

1423
01:02:22,530 --> 01:02:24,870
>> Mai multe găleți Sunt
scris, cu atât mai probabil

1424
01:02:24,870 --> 01:02:29,100
Sunt de a răspândi ca sarcină de scriere sau
citeste load out pe mai multe noduri,

1425
01:02:29,100 --> 01:02:33,560
cu atât mai probabil sunt de a avea o
capacitate mare de pe masă.

1426
01:02:33,560 --> 01:02:37,440
Și apoi vreau valorile să fie
solicitat destul de uniform în timp

1427
01:02:37,440 --> 01:02:39,430
și mai uniform aleator posibil.

1428
01:02:39,430 --> 01:02:42,410
Ei bine, asta e un fel de interesant,
pentru că nu poate într-adevăr

1429
01:02:42,410 --> 01:02:43,960
control, atunci când utilizatorii vin.

1430
01:02:43,960 --> 01:02:47,645
Deci, suficient să spun, dacă am răspândit
lucrurile din spațiul cheie,

1431
01:02:47,645 --> 01:02:49,270
vom fi, probabil, într-o formă mai bună.

1432
01:02:49,270 --> 01:02:51,522
>> Există un anumit
cantitate de timp de livrare

1433
01:02:51,522 --> 01:02:53,230
că nu te duci
să fie de control putea.

1434
01:02:53,230 --> 01:02:55,438
Dar acestea sunt într-adevăr
două dimensiuni pe care le avem,

1435
01:02:55,438 --> 01:02:58,800
spațiu, acces egal
răspândit, timp, cererile

1436
01:02:58,800 --> 01:03:01,040
sosesc distanțate uniform în timp.

1437
01:03:01,040 --> 01:03:03,110
Și dacă cei doi
condiții sunt îndeplinite,

1438
01:03:03,110 --> 01:03:05,610
atunci asta e ceea ce e
O să arate.

1439
01:03:05,610 --> 01:03:07,890
Acest lucru este mult mai frumos.

1440
01:03:07,890 --> 01:03:08,890
Suntem foarte fericit aici.

1441
01:03:08,890 --> 01:03:10,432
Avem un model de acces foarte chiar.

1442
01:03:10,432 --> 01:03:13,098
Da, poate vei primi un
pic de presiune fiecare acum și apoi,

1443
01:03:13,098 --> 01:03:14,830
dar nimic nu într-adevăr prea extinse.

1444
01:03:14,830 --> 01:03:17,660
Deci, este uimitor cât de multe ori,
când lucrez cu clienți,

1445
01:03:17,660 --> 01:03:20,670
că primul grafic cu roșu mare
bar și tot ce urât e galben

1446
01:03:20,670 --> 01:03:23,147
peste tot, am
se face cu exercitarea

1447
01:03:23,147 --> 01:03:24,980
după câteva luni
de re-arhitectura,

1448
01:03:24,980 --> 01:03:28,050
ei rulează exact același lucru
volumul de muncă la aceeași sarcină exact.

1449
01:03:28,050 --> 01:03:30,140
Și aceasta este ceea ce se arata ca acum.

1450
01:03:30,140 --> 01:03:36,600
Deci, ceea ce veți obține cu NoSQL este un
schema de date, care este absolut

1451
01:03:36,600 --> 01:03:38,510
legat de modelul de accesare.

1452
01:03:38,510 --> 01:03:42,170
>> Și puteți optimiza că schema de date
pentru a sprijini acel model de acces.

1453
01:03:42,170 --> 01:03:45,490
Dacă nu, atunci te duci
pentru a vedea aceste tipuri de probleme

1454
01:03:45,490 --> 01:03:46,710
cu aceste taste.

1455
01:03:46,710 --> 01:03:50,518
>> Audiența: Ei bine, inevitabil unele locuri
vor fi mai fierbinte decât altele.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Întotdeauna.

1457
01:03:51,450 --> 01:03:51,960
Mereu.

1458
01:03:51,960 --> 01:03:54,620
Da, vreau să spun că întotdeauna
un-- și, din nou, nu e

1459
01:03:54,620 --> 01:03:56,980
unele modele de design vom trece prin
care va vorbi despre modul în care te descurci

1460
01:03:56,980 --> 01:03:58,480
cu aceste agregări super-mari.

1461
01:03:58,480 --> 01:04:01,260
Adică, am să le aibă,
cum avem de a face cu ei?

1462
01:04:01,260 --> 01:04:03,760
Am un caz de utilizare destul de bine
că vom vorbi despre asta.

1463
01:04:03,760 --> 01:04:05,940
>> Bine, așa că hai să vorbim
despre unii clienți acum.

1464
01:04:05,940 --> 01:04:06,950
Tipii ăștia sunt AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Nu știu dacă ești
familiar cu AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Tu, probabil, le vezi
mult pe browser-ul.

1467
01:04:10,781 --> 01:04:14,230
Sunt ad re-direcționarea, sunt
cea mai mare afacere ad re-orientare

1468
01:04:14,230 --> 01:04:14,940
acolo.

1469
01:04:14,940 --> 01:04:17,792
În mod normal, ei rula în mod regulat peste
60 miliarde de tranzactii pe zi.

1470
01:04:17,792 --> 01:04:20,000
Ei fac de peste un milion
tranzacții pe secundă.

1471
01:04:20,000 --> 01:04:22,660
Au o masă destul de simplu
structură, cele mai aglomerate masa.

1472
01:04:22,660 --> 01:04:26,450
Este practic doar un
cheie hash este cookie,

1473
01:04:26,450 --> 01:04:29,010
gama este demografice
categorie, și apoi

1474
01:04:29,010 --> 01:04:31,220
al treilea atribut este scorul.

1475
01:04:31,220 --> 01:04:33,720
>> Deci, noi toți avem cookie-urile în
Browser-ul nostru de la tipii ăștia.

1476
01:04:33,720 --> 01:04:35,900
Și când te duci la un
comerciant participante,

1477
01:04:35,900 --> 01:04:39,390
ei practic tine scorul peste
diferite categorii demografice.

1478
01:04:39,390 --> 01:04:42,070
Când te duci la un site web și
ai spus Vreau să văd acest ad--

1479
01:04:42,070 --> 01:04:44,920
sau practic nu spui that--
dar atunci când te duci la site-ul web

1480
01:04:44,920 --> 01:04:47,550
ei spun doriți să vedeți acest anunț.

1481
01:04:47,550 --> 01:04:49,370
Și ei du-te că anunțul de AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll te uită pe masa lor.

1483
01:04:51,130 --> 01:04:52,115
Ei au găsit cookie-ul.

1484
01:04:52,115 --> 01:04:53,990
Agenții de publicitate spun
le, vreau pe cineva

1485
01:04:53,990 --> 01:04:58,632
care e de varsta mijlocie,
Bărbat de 40 de ani, în sport.

1486
01:04:58,632 --> 01:05:01,590
Și te-au înscrie în acele demografice
și ei să decidă dacă este sau nu

1487
01:05:01,590 --> 01:05:02,740
asta e un anunț bun pentru tine.

1488
01:05:02,740 --> 01:05:10,330
>> Acum, ei au un SLA cu
furnizorii de publicitate

1489
01:05:10,330 --> 01:05:14,510
pentru a oferi sub-10 milisecunde
răspuns la fiecare cerere.

1490
01:05:14,510 --> 01:05:16,090
Deci ei folosesc Dinamo DB pentru acest lucru.

1491
01:05:16,090 --> 01:05:18,131
Ne-o lovind
milioane de cereri pe secundă.

1492
01:05:18,131 --> 01:05:21,120
Sunt în stare să facă toate lor
căutări, triaj toate aceste date,

1493
01:05:21,120 --> 01:05:26,130
și obține Adauga link-ul înapoi la faptul că
publicitate în conformitate cu 10 milisecunde.

1494
01:05:26,130 --> 01:05:29,800
E într-adevăr destul fenomenal
de punere în aplicare pe care le au.

1495
01:05:29,800 --> 01:05:36,210
>> Tipii ăștia actually--
sunt acestea băieții.

1496
01:05:36,210 --> 01:05:38,010
Nu sunt sigur dacă e tipii ăștia.

1497
01:05:38,010 --> 01:05:40,127
S-ar putea să fie tipii ăștia.

1498
01:05:40,127 --> 01:05:42,210
Practic us-- spus nu,
Nu cred că le era.

1499
01:05:42,210 --> 01:05:43,000
Cred că a fost altcineva.

1500
01:05:43,000 --> 01:05:44,750
Am fost de lucru cu un
client care mi-a spus

1501
01:05:44,750 --> 01:05:47,040
că acum că le-am
plecat la Dinamo DB, sunt

1502
01:05:47,040 --> 01:05:50,330
cheltui mai mulți bani pe snacks-uri pentru
echipa lor de dezvoltare în fiecare lună

1503
01:05:50,330 --> 01:05:52,886
decât cheltui pe baza lor de date.

1504
01:05:52,886 --> 01:05:54,760
Deci, să-ți dau o
idee economiile de costuri

1505
01:05:54,760 --> 01:05:57,889
pe care le puteți obține de la Dynamo DB este imens.

1506
01:05:57,889 --> 01:05:59,430
Bine, dropcam e altă companie.

1507
01:05:59,430 --> 01:06:02,138
Aceste tip cam de--, dacă credeți
de internet de lucruri, dropcam

1508
01:06:02,138 --> 01:06:05,150
este, în principiu Internet Video de securitate.

1509
01:06:05,150 --> 01:06:06,660
Ai pus aparatul de fotografiat acolo.

1510
01:06:06,660 --> 01:06:08,180
Camera are un senzor de mișcare.

1511
01:06:08,180 --> 01:06:10,290
Cineva vine,
declanșează un punct de tac.

1512
01:06:10,290 --> 01:06:13,540
Camera începe înregistrarea pentru un timp până
aceasta nu mai detecta orice mișcare.

1513
01:06:13,540 --> 01:06:15,310
Pune că videoclipul pe internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam fost o companie care este
practic a trecut la Dinamo DB

1515
01:06:19,800 --> 01:06:22,200
deoarece acestea au fost confrunta cu
dureri de crestere enorme.

1516
01:06:22,200 --> 01:06:25,820
Și ce ne-au spus,
brusc petabytes de date.

1517
01:06:25,820 --> 01:06:28,070
Ei au avut nici o idee serviciul lor
ar fi atât de succes.

1518
01:06:28,070 --> 01:06:32,310
Mai mult de pe YouTube videoclipuri de intrare
este ceea ce tipii ăștia sunt de asistent.

1519
01:06:32,310 --> 01:06:36,780
Ei folosesc DynamoDB pentru a urmări toate
metadate cu privire la toate punctele lor cheie video.

1520
01:06:36,780 --> 01:06:40,282
>> Deci, ei au S3 găleți ei împinge
toate artefactele binare în.

1521
01:06:40,282 --> 01:06:41,990
Și apoi le-au
Înregistrările dinam DB care

1522
01:06:41,990 --> 01:06:44,070
punctul de oameni la aceste S3 trei obiecte.

1523
01:06:44,070 --> 01:06:47,070
Atunci când au nevoie să se uite la un film,
se uita în sus înregistrarea în Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Ei faceți clic pe link.

1525
01:06:47,903 --> 01:06:49,770
Ei trage în jos video de la S3.

1526
01:06:49,770 --> 01:06:51,590
Deci, asta e un fel de ceea ce arata ca aceasta.

1527
01:06:51,590 --> 01:06:53,580
Și acest lucru este direct de la echipa lor.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB reduce lor
Termenul de livrare pentru evenimente video,

1529
01:06:56,010 --> 01:06:57,590
de la cinci la 10 secunde.

1530
01:06:57,590 --> 01:07:00,470
In magazinul lor vechi relațional,
au folosit pentru a trebuie să meargă și să execute

1531
01:07:00,470 --> 01:07:03,780
mai multe interogări complexe pentru a descoperi
din care videoclipuri a trage în jos,

1532
01:07:03,780 --> 01:07:06,690
la mai puțin de 50 milisecunde.

1533
01:07:06,690 --> 01:07:08,990
Deci e uimitor, uimitor
cât de mult de performanță

1534
01:07:08,990 --> 01:07:12,990
puteți obține atunci când vă optimizați și
vă ton de date care stau la baza

1535
01:07:12,990 --> 01:07:15,110
pentru a sprijini modelul de accesare.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, tipii ăștia, ce este,
Fruit Ninja Cred este un lucru lor.

1537
01:07:20,500 --> 01:07:22,590
Că toate ruleaza pe Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
Și tipii ăștia, ele sunt o mare
echipa de dezvoltare, mare dezvoltare

1539
01:07:26,810 --> 01:07:27,670
magazin.

1540
01:07:27,670 --> 01:07:29,364
>> Nu este o echipă bună op.

1541
01:07:29,364 --> 01:07:31,280
Ei nu au avut o mulțime
resurselor de operare.

1542
01:07:31,280 --> 01:07:33,940
Ei au fost lupta încearcă să mențină
infrastructura aplicare până

1543
01:07:33,940 --> 01:07:34,290
și să fie difuzate.

1544
01:07:34,290 --> 01:07:35,000
Ei au venit la noi.

1545
01:07:35,000 --> 01:07:36,251
Ei se uita la acel Dinamo DB.

1546
01:07:36,251 --> 01:07:37,291
Ei au spus, asta e pentru noi.

1547
01:07:37,291 --> 01:07:39,470
Au construit întregul lor
cadru de aplicare pe ea.

1548
01:07:39,470 --> 01:07:43,640
Unele comentarii foarte frumos aici
de la echipa de pe capacitatea lor

1549
01:07:43,640 --> 01:07:46,800
să se concentreze acum pe construirea
jocul și nu

1550
01:07:46,800 --> 01:07:49,010
având Pentru a menține
infrastructură, care

1551
01:07:49,010 --> 01:07:51,910
a devenit o cantitate enormă
de deasupra pentru echipa lor.

1552
01:07:51,910 --> 01:07:56,170
Deci acest lucru este ceva that--
beneficiul pe care le primesc de la Dinamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Bine, intrând în
modelarea datelor aici.

1554
01:08:00,930 --> 01:08:03,440
Și am vorbit un pic despre
aceasta la unu, unu la multe,

1555
01:08:03,440 --> 01:08:05,060
și mulți să multe relatii de tip.

1556
01:08:05,060 --> 01:08:07,630
Și cum a face tu menține cele din Dynamo.

1557
01:08:07,630 --> 01:08:10,500
În Dynamo DB folosim
indici, în general vorbind,

1558
01:08:10,500 --> 01:08:12,910
pentru a roti datele din
unul aromă la alta.

1559
01:08:12,910 --> 01:08:15,210
Chei hash, chei gama, și indexurile.

1560
01:08:15,210 --> 01:08:18,540
>> În acest special
exemplu, ca cele mai multe state

1561
01:08:18,540 --> 01:08:23,802
au o cerință de acordare a licențelor care
doar permis o conducere per persoană.

1562
01:08:23,802 --> 01:08:26,510
Nu puteți merge pentru a obține șofer două lui
licențe în stare de Boston.

1563
01:08:26,510 --> 01:08:27,500
Nu pot face acest lucru în Texas.

1564
01:08:27,500 --> 01:08:28,708
Asta e un fel de modul în care aceasta este.

1565
01:08:28,708 --> 01:08:32,779
Și astfel, la DMV, avem căutări, am
doriți să căutați permisul de conducere

1566
01:08:32,779 --> 01:08:35,180
de numărul de securitate socială.

1567
01:08:35,180 --> 01:08:39,990
Vreau să te uiți în sus detaliile de utilizator
în funcție de numărul permisul de conducere.

1568
01:08:39,990 --> 01:08:43,620
>> Deci, am putea avea masa de un utilizator care
are o cheie hash cu privire la numărul de serie,

1569
01:08:43,620 --> 01:08:47,830
sau numărul de securitate socială, și
diverse atribute definite pe element.

1570
01:08:47,830 --> 01:08:49,859
Acum, pe masa am
ar putea defini un GSI care

1571
01:08:49,859 --> 01:08:53,370
flips că în jurul valorii de care spune vreau
o cheie hash pe licență și apoi

1572
01:08:53,370 --> 01:08:54,252
toate celelalte elemente.

1573
01:08:54,252 --> 01:08:57,210
Acum, dacă vreau să interogare și de a găsi
Numărul de licență pentru un anumit Social

1574
01:08:57,210 --> 01:08:59,609
Numărul de securitate, nu pot
interogare tabelul principal.

1575
01:08:59,609 --> 01:09:02,130
>> Dacă vreau să interogare și vreau
pentru a obține de securitate socială

1576
01:09:02,130 --> 01:09:05,735
numărul sau alte atribute de către un
Numărul de licență, pot interoga GSI.

1577
01:09:05,735 --> 01:09:08,689
Acest model este faptul că unul
la unul relație.

1578
01:09:08,689 --> 01:09:12,460
Doar un foarte simplu GSI,
răsturna aceste lucruri în jurul valorii de.

1579
01:09:12,460 --> 01:09:13,979
Acum, vorbesc despre o la mai multe.

1580
01:09:13,979 --> 01:09:16,450
Unul pentru mulți este, în principiu
cheia gama hash.

1581
01:09:16,450 --> 01:09:20,510
În cazul în care vom obține o mulțime cu acest
caz de utilizare este de date de monitorizare.

1582
01:09:20,510 --> 01:09:23,880
Date monitor vine în mod regulat
interval, cum ar fi internet de lucruri.

1583
01:09:23,880 --> 01:09:26,890
Noi întotdeauna obține toate acestea
înregistrările venind tot timpul.

1584
01:09:26,890 --> 01:09:31,420
>> Și vreau să găsească toate citirile
între o anumită perioadă de timp.

1585
01:09:31,420 --> 01:09:34,220
Este o interogare foarte frecvente în
infrastructură de monitorizare.

1586
01:09:34,220 --> 01:09:38,430
Modul merge despre care este de a găsi o
structură de tabel simplu, un tabel.

1587
01:09:38,430 --> 01:09:42,250
Am un tabel măsurători dispozitiv
cu o cheie hash pe ID-ul dispozitivului.

1588
01:09:42,250 --> 01:09:47,340
Și am o cheie gamă privire la
timestamp, sau în acest caz, epic.

1589
01:09:47,340 --> 01:09:50,350
Și care-mi permite să execute complex
interogări împotriva cheia gamă

1590
01:09:50,350 --> 01:09:54,950
și să se întoarcă acele înregistrări care
sunt raportate la rezultatul

1591
01:09:54,950 --> 01:09:56,310
set care caut.

1592
01:09:56,310 --> 01:09:58,360
Și se construiește care o
de foarte multe relații

1593
01:09:58,360 --> 01:10:02,340
în tabelul primar folosind
tasta Diez, structura cheie gama.

1594
01:10:02,340 --> 01:10:04,600
>> Deci, asta e un fel de construit
în tabelul de la Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Când m-am defini un hash
și o gamă T masă, eu sunt

1596
01:10:07,290 --> 01:10:09,240
definirea unei una la mai multe relații.

1597
01:10:09,240 --> 01:10:12,770
Este o relație părinte-copil.

1598
01:10:12,770 --> 01:10:14,620
>> Hai sa vorbim despre multe
la multe relatii.

1599
01:10:14,620 --> 01:10:19,170
Și pentru acest exemplu particular,
din nou, vom pentru a utiliza lui GSI.

1600
01:10:19,170 --> 01:10:23,500
Și să vorbim despre jocuri de noroc
scenariu în cazul în care am avea o anumită utilizator.

1601
01:10:23,500 --> 01:10:26,500
Vreau să aflu toate jocurile care
el a înregistrat pentru sau juca în.

1602
01:10:26,500 --> 01:10:29,600
Și pentru un anumit joc, am
doriți să găsiți toți utilizatorii.

1603
01:10:29,600 --> 01:10:31,010
Deci, cum fac asta?

1604
01:10:31,010 --> 01:10:34,330
My masă jocuri de utilizator, am de gând
pentru a avea o cheie hash de ID utilizator

1605
01:10:34,330 --> 01:10:35,810
și o cheie gamă de joc.

1606
01:10:35,810 --> 01:10:37,810
>> Deci, un utilizator poate avea mai multe jocuri.

1607
01:10:37,810 --> 01:10:41,380
Este unul la multe relație între
utilizator și jocurile el joacă.

1608
01:10:41,380 --> 01:10:43,410
Și apoi pe GSI,
Voi întoarceți că în jurul valorii.

1609
01:10:43,410 --> 01:10:46,679
Voi hash pe joc și
Voi gama asupra utilizatorului.

1610
01:10:46,679 --> 01:10:48,970
Deci, dacă vreau pentru a obține toate
joc utilizatorului joacă în,

1611
01:10:48,970 --> 01:10:49,950
Voi interogare tabelul principal.

1612
01:10:49,950 --> 01:10:52,699
Dacă vreau să obțineți tuturor utilizatorilor
care joacă un anumit joc,

1613
01:10:52,699 --> 01:10:53,887
Am interogare GSI.

1614
01:10:53,887 --> 01:10:54,970
Deci, vedeți cum facem acest lucru?

1615
01:10:54,970 --> 01:10:58,369
Vă construi aceste GSI a sprijini
caz de utilizare, cererea, accesul

1616
01:10:58,369 --> 01:10:59,410
model, aplicația.

1617
01:10:59,410 --> 01:11:01,440
>> Dacă am nevoie pentru a interoga pe
această dimensiune, să

1618
01:11:01,440 --> 01:11:03,500
mi crea un index pe acea dimensiune.

1619
01:11:03,500 --> 01:11:05,850
Dacă nu o fac, nu-mi pasă.

1620
01:11:05,850 --> 01:11:09,060
Și în funcție de caz de utilizare, am
ar putea avea nevoie indexul sau nu s-ar putea.

1621
01:11:09,060 --> 01:11:12,390
Dacă e unul simplu pentru multi,
tabelul primar este bine.

1622
01:11:12,390 --> 01:11:15,860
Dacă am nevoie pentru a face aceste mulți să
multe lui sau am nevoie pentru a face o la cele,

1623
01:11:15,860 --> 01:11:18,390
atunci poate am nevoie
a doua index.

1624
01:11:18,390 --> 01:11:20,840
Deci, totul depinde de
ceea ce am încercat să fac

1625
01:11:20,840 --> 01:11:24,550
și ceea ce am încercarea de a obține realizat.

1626
01:11:24,550 --> 01:11:28,000
>> Probabil ca nu am de gând să-și petreacă prea
mult vorbesc despre documentele timp.

1627
01:11:28,000 --> 01:11:31,460
Acest lucru devine un pic, probabil,
mai profund decât avem nevoie pentru a merge în.

1628
01:11:31,460 --> 01:11:33,710
Hai sa vorbim un pic
expresie de interogare despre bogat.

1629
01:11:33,710 --> 01:11:37,831
Deci, în Dynamo DB avem
abilitatea de a crea

1630
01:11:37,831 --> 01:11:39,330
ceea ce noi numim expresii de proiecție.

1631
01:11:39,330 --> 01:11:42,660
Expresii de proiecție sunt pur și simplu
cules câmpurile sau valorile

1632
01:11:42,660 --> 01:11:44,290
pe care doriți să o afișați.

1633
01:11:44,290 --> 01:11:46,000
OK, asa ca am face o selecție.

1634
01:11:46,000 --> 01:11:48,010
Eu fac o interogare împotriva Dinamo DB.

1635
01:11:48,010 --> 01:11:51,730
Și să spun, știi ce, spectacol
mi numai cinci stele comentarii

1636
01:11:51,730 --> 01:11:54,544
pentru acest produs special.

1637
01:11:54,544 --> 01:11:55,710
Deci, asta e tot ce vreau să văd.

1638
01:11:55,710 --> 01:11:57,320
Nu vreau să Vezi toate
alte atribute ale rândul,

1639
01:11:57,320 --> 01:11:58,319
Vreau doar să văd asta.

1640
01:11:58,319 --> 01:12:01,209
E la fel ca în SQL, atunci când
spune selectați stele sau de la masă,

1641
01:12:01,209 --> 01:12:02,000
ai totul.

1642
01:12:02,000 --> 01:12:05,450
Când spun selectați numele din
masă, am doar un singur atribut.

1643
01:12:05,450 --> 01:12:09,070
Este același tip de lucru în
Dynamo DB sau alte baze de date NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Expresii de filtrare mă lasă să
tăiat practic rezultatul stabilit.

1645
01:12:14,510 --> 01:12:15,540
Așa că am face o interogare.

1646
01:12:15,540 --> 01:12:17,260
Interogare poate reveni cu 500 de articole.

1647
01:12:17,260 --> 01:12:20,255
Dar vreau doar elementele pe care
au un atribut care spune acest lucru.

1648
01:12:20,255 --> 01:12:23,380
OK, deci haideți să filtreze aceste elemente
care nu se potrivesc că interogarea special.

1649
01:12:23,380 --> 01:12:25,540
Deci avem expresii de filtrare.

1650
01:12:25,540 --> 01:12:28,310
>> Expresii filtru poate
fi rulat pe orice atribut.

1651
01:12:28,310 --> 01:12:30,260
Ei nu sunt ca interogări gama.

1652
01:12:30,260 --> 01:12:32,690
Ridicați interogări sunt mai selective.

1653
01:12:32,690 --> 01:12:36,470
Interogări de filtrare mi cere să merg
obține întreaga rezultatele stabilite și apoi

1654
01:12:36,470 --> 01:12:39,170
sculpta datele nu vreau.

1655
01:12:39,170 --> 01:12:40,660
De ce este așa de important?

1656
01:12:40,660 --> 01:12:42,770
Pentru că l-am citit toate.

1657
01:12:42,770 --> 01:12:46,597
Într-o interogare, am de gând să citească și să
se va fi un gigant cu privire la date.

1658
01:12:46,597 --> 01:12:48,430
Și apoi am de gând să
sculpta ceea ce am nevoie.

1659
01:12:48,430 --> 01:12:52,080
Și dacă am doar sculptură o
câteva rânduri, atunci e OK.

1660
01:12:52,080 --> 01:12:53,620
Nu este atât de ineficient.

1661
01:12:53,620 --> 01:12:57,800
>> Dar dacă am citit o grămadă de
date, doar pentru a sculpta un articol,

1662
01:12:57,800 --> 01:13:01,490
apoi m-am de gând să fie mai bine
folosind o interogare domeniu,

1663
01:13:01,490 --> 01:13:03,030
pentru că este mult mai selectiv.

1664
01:13:03,030 --> 01:13:06,330
O să-mi salva o mulțime de
bani, pentru că am plăti pentru asta citire.

1665
01:13:06,330 --> 01:13:10,430
În cazul în care rezultatele pe care se întoarce
cruce ca sârmă ar putea fi mai mici,

1666
01:13:10,430 --> 01:13:11,890
dar eu sunt de plata pentru citit.

1667
01:13:11,890 --> 01:13:14,340
Deci, înțeleg cum
vei primi datele.

1668
01:13:14,340 --> 01:13:16,420
Asta e foarte important în Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Expresiilor condiționale, aceasta este ceea ce
ai putea numi blocare optimistă.

1670
01:13:19,710 --> 01:13:28,470
Actualizare dacă există, sau în cazul în care această valoare
este echivalent cu ceea ce am specifica.

1671
01:13:28,470 --> 01:13:31,494
Și dacă am o ștampilă de timp pe un
înregistrare, s-ar putea citi datele.

1672
01:13:31,494 --> 01:13:32,535
S-ar putea schimba aceste date.

1673
01:13:32,535 --> 01:13:35,030
S-ar putea merge scrie că
date înapoi la baza de date.

1674
01:13:35,030 --> 01:13:38,100
Dacă cineva a schimbat înregistrarea,
amprenta de timp s-ar putea s-au schimbat.

1675
01:13:38,100 --> 01:13:40,370
Și în acest fel condiționată meu
update putea spune actualizare

1676
01:13:40,370 --> 01:13:42,340
în cazul în care amprenta de timp este egal cu acest lucru.

1677
01:13:42,340 --> 01:13:46,290
Sau actualizarea va eșua, deoarece cineva
actualizat înregistrarea între timp.

1678
01:13:46,290 --> 01:13:48,290
>> Asta e ceea ce noi numim de blocare optimistă.

1679
01:13:48,290 --> 01:13:50,670
Aceasta înseamnă că cineva
poate veni în si schimba-l,

1680
01:13:50,670 --> 01:13:53,100
și am de gând să-l detecta
atunci când mă întorc la a scrie.

1681
01:13:53,100 --> 01:13:56,106
Și apoi eu pot citi de fapt, că
date și spune, oh, a schimbat acest lucru.

1682
01:13:56,106 --> 01:13:57,230
Am nevoie de a ține cont de acest lucru.

1683
01:13:57,230 --> 01:14:00,490
Și eu pot schimba datele din mea
înregistra și se aplică un alt update.

1684
01:14:00,490 --> 01:14:04,330
Astfel încât să puteți prinde cele incrementale
actualizări care apar între timp

1685
01:14:04,330 --> 01:14:08,740
că ai citit datele și
timp s-ar putea scrie datele.

1686
01:14:08,740 --> 01:14:11,520
>> Audiența: și filtrul
exprimare nu înseamnă de fapt

1687
01:14:11,520 --> 01:14:13,020
în numărul sau not--

1688
01:14:13,020 --> 01:14:14,316
>> [Interpunerea VOCI]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: nu voi
a lua prea mult în asta.

1690
01:14:16,232 --> 01:14:17,700
Acesta este un cuvânt cheie rezervate.

1691
01:14:17,700 --> 01:14:20,130
Punctul de vedere este o lira rezervat
cuvinte cheie în Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Fiecare baza de date are propriul rezervate
nume pentru colecții nu se poate folosi.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, dacă specificați
o lira în fața acestui fapt,

1694
01:14:27,240 --> 01:14:29,310
puteți defini aceste nume deasupra.

1695
01:14:29,310 --> 01:14:31,840
Aceasta este o valoare de referință.

1696
01:14:31,840 --> 01:14:34,880
Probabil nu este cel mai bun pentru a sintaxa
au acolo pentru această discuție,

1697
01:14:34,880 --> 01:14:38,090
pentru că acesta devine în unele real--
Mi-ar fi vorbit mai mult

1698
01:14:38,090 --> 01:14:41,360
despre care, la un nivel mai profund.

1699
01:14:41,360 --> 01:14:46,130
>> Dar suficient să spun, acest lucru ar putea
fi interogare scanare în cazul în care views--

1700
01:14:46,130 --> 01:14:50,190
nici vizionări lira este mai mare de 10.

1701
01:14:50,190 --> 01:14:54,660
Este o valoare numerică, da.

1702
01:14:54,660 --> 01:14:57,322
Dacă doriți, putem vorbi despre
că, după discuția.

1703
01:14:57,322 --> 01:15:00,030
În regulă, așa că vei primi în
unele scenarii din cele mai bune practici

1704
01:15:00,030 --> 01:15:02,000
în cazul în care vom vorbi
despre unele aplicații aici.

1705
01:15:02,000 --> 01:15:03,810
Care sunt cazurile de utilizare pentru Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Care sunt proiectarea
modele în Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> Și primul vom
vorbesc despre este internetul obiectelor.

1708
01:15:09,110 --> 01:15:15,010
Așa că am obține o mulțime de-- cred,
ceea ce este it-- peste 50%

1709
01:15:15,010 --> 01:15:19,370
de trafic pe internet aceste zile
este, de fapt generată de mașini,

1710
01:15:19,370 --> 01:15:21,930
procese automatizate, nu de oameni.

1711
01:15:21,930 --> 01:15:25,140
Adică acest lucru acest lucru
purtați în jurul valorii în buzunar,

1712
01:15:25,140 --> 01:15:28,840
cât de mult date care acel lucru este
de fapt, trimiterea în jurul fără tine

1713
01:15:28,840 --> 01:15:30,550
știind că este absolut uimitor.

1714
01:15:30,550 --> 01:15:34,970
Locația dvs., informatii
despre cât de repede te duci.

1715
01:15:34,970 --> 01:15:38,400
Cum crezi că funcționează Google Maps
când vă spun ceea ce este traficul.

1716
01:15:38,400 --> 01:15:41,275
Este pentru că există milioane de oameni și
milioane de oameni în jurul valorii de conducere

1717
01:15:41,275 --> 01:15:44,667
cu telefoanele care trimit
date peste tot loc tot timpul.

1718
01:15:44,667 --> 01:15:46,500
Deci, unul din lucrurile
despre acest tip de date

1719
01:15:46,500 --> 01:15:50,980
care vine în, date de monitorizare, log
date, datele seriilor de timp, este e

1720
01:15:50,980 --> 01:15:53,540
de obicei, doar interesant
pentru un pic de timp.

1721
01:15:53,540 --> 01:15:55,580
După acest timp, e
nu atât de interesant.

1722
01:15:55,580 --> 01:15:58,390
Așa că am vorbit despre, nu lasa
aceste tabele creste fara limite.

1723
01:15:58,390 --> 01:16:03,410
Ideea este ca poate am 24
ore în valoare de evenimente din masa mea fierbinte.

1724
01:16:03,410 --> 01:16:06,160
Și acest tabel fierbinte va fi
prevăzut, la o rată foarte mare,

1725
01:16:06,160 --> 01:16:07,950
pentru că este a lua o mulțime de date.

1726
01:16:07,950 --> 01:16:10,920
Este de a lua o mulțime de date
și am citit foarte mult.

1727
01:16:10,920 --> 01:16:14,560
Am o mulțime de funcționare
interogări care rulează împotriva date.

1728
01:16:14,560 --> 01:16:18,120
>> După 24 de ore, hei, tu
Știi ce, nu-mi pasă.

1729
01:16:18,120 --> 01:16:21,150
Poate fiecare mă rostogolesc la miezul nopții
masa mea pe la o masă nouă

1730
01:16:21,150 --> 01:16:22,430
și am deprovision acest tabel.

1731
01:16:22,430 --> 01:16:26,440
Și voi lua telecomandă și
Jos pentru scaune cu rotile, deoarece 24 de ore mai târziu

1732
01:16:26,440 --> 01:16:28,630
Nu fug cât mai multe
interogări împotriva că datele.

1733
01:16:28,630 --> 01:16:30,200
Deci, am de gând pentru a economisi bani.

1734
01:16:30,200 --> 01:16:32,940
Și poate de 30 de zile mai târziu, eu nu
chiar trebuie să aibă grijă de toate.

1735
01:16:32,940 --> 01:16:35,020
Aș putea lua anii scaune cu rotile
tot drumul până la un,

1736
01:16:35,020 --> 01:16:36,990
pentru că știi ce, e
nu mergi la a lua scris.

1737
01:16:36,990 --> 01:16:38,300
Datele sunt vechi de 30 de zile.

1738
01:16:38,300 --> 01:16:40,000
Acesta nu se schimbă niciodată.

1739
01:16:40,000 --> 01:16:44,200
>> Și se aproape niciodată mergi la a lua citi,
Să ia doar că RCU până la 10.

1740
01:16:44,200 --> 01:16:49,372
Iar eu de economisire o grămadă de bani pe acest
date, și numai plata pentru datele mele fierbinte.

1741
01:16:49,372 --> 01:16:52,330
Deci, asta e cel mai important lucru pentru a căuta
la atunci când te uiți la o serie cronologică

1742
01:16:52,330 --> 01:16:54,716
date venind în volum.

1743
01:16:54,716 --> 01:16:55,590
Acestea sunt strategii.

1744
01:16:55,590 --> 01:16:58,010
Acum, aș putea să-l pur și simplu
toate merg la aceeași masă

1745
01:16:58,010 --> 01:16:59,461
și doar lăsa să se tabel să crească.

1746
01:16:59,461 --> 01:17:01,460
În cele din urmă, am de gând să
vezi probleme de performanță.

1747
01:17:01,460 --> 01:17:04,060
Am de gând să trebuie să înceapă să arhiva
unele dintre aceste date de pe masă,

1748
01:17:04,060 --> 01:17:04,720
fleacuri.

1749
01:17:04,720 --> 01:17:07,010
>> Să mult mai bine
proiecta cererea dumneavoastră

1750
01:17:07,010 --> 01:17:08,900
astfel încât să poată funcționa în acest fel drept.

1751
01:17:08,900 --> 01:17:11,460
Deci e doar automat
în codul de aplicare.

1752
01:17:11,460 --> 01:17:13,580
La miezul nopții în fiecare noapte
se rostogolește masa.

1753
01:17:13,580 --> 01:17:17,170
Poate ceea ce am nevoie este o alunecare
fereastră de 24 de ore de date.

1754
01:17:17,170 --> 01:17:20,277
Apoi, în mod regulat sunt
de asteptare de date de pe masă.

1755
01:17:20,277 --> 01:17:22,360
Am o tundere cu un
Cron de locuri de muncă și eu sunt o pune

1756
01:17:22,360 --> 01:17:24,160
pe aceste alte tabele,
orice ai nevoie.

1757
01:17:24,160 --> 01:17:25,940
Deci, dacă un rollover funcționează, e minunat.

1758
01:17:25,940 --> 01:17:27,080
Dacă nu, o tăiați.

1759
01:17:27,080 --> 01:17:29,640
Dar să păstrați datele fierbinte
departe de datele reci.

1760
01:17:29,640 --> 01:17:32,535
Acesta va salva o mulțime de bani și
face mesele mai performant.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Deci următorul lucru vom vorbi
despre este catalogul de produse.

1763
01:17:38,210 --> 01:17:42,000
Catalog produse este
caz de utilizare destul de comun.

1764
01:17:42,000 --> 01:17:46,600
Aceasta este de fapt un model foarte frecvente
că vom vedea într-o varietate de lucruri.

1765
01:17:46,600 --> 01:17:48,870
Știi, Twitter pentru
exemplu, un tweet fierbinte.

1766
01:17:48,870 --> 01:17:51,280
Toată lumea vine și
hapsân că tweet.

1767
01:17:51,280 --> 01:17:52,680
Catalog produse, am o vânzare.

1768
01:17:52,680 --> 01:17:54,120
Am o vânzare fierbinte.

1769
01:17:54,120 --> 01:17:57,277
Am 70.000 de cereri pe
doua venire pentru un produs

1770
01:17:57,277 --> 01:17:58,860
Descrierea din catalog mea de produse.

1771
01:17:58,860 --> 01:18:02,384
Vedem acest lucru în retail
operație destul de un pic.

1772
01:18:02,384 --> 01:18:03,550
Deci, cum avem de a face cu asta?

1773
01:18:03,550 --> 01:18:04,924
Nu există nici o modalitate de a face cu asta.

1774
01:18:04,924 --> 01:18:07,110
Toți utilizatorii mei doresc să vadă
aceeași bucată de date.

1775
01:18:07,110 --> 01:18:09,410
Ei vin în, concomitent.

1776
01:18:09,410 --> 01:18:11,920
Și acestea sunt de luare toate cererile
pentru aceeași bucată de date.

1777
01:18:11,920 --> 01:18:16,240
Acest lucru îmi dă cheia cald, că roșu mare
dungă pe graficul meu pe care nu le place.

1778
01:18:16,240 --> 01:18:17,720
Și asta e ceea ce pare ca la fel ca.

1779
01:18:17,720 --> 01:18:22,290
Deci, peste spatiul meu cheie Primesc
ciocanul în elementele de vânzare.

1780
01:18:22,290 --> 01:18:24,070
Primesc nimic în altă parte.

1781
01:18:24,070 --> 01:18:26,050
>> Cum pot atenua această problemă?

1782
01:18:26,050 --> 01:18:28,410
Ei bine, am atenua acest lucru cu cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, ai pus practic un in-memory
partiție în fața bazei de date.

1784
01:18:33,630 --> 01:18:37,260
Am reușit
[Auzite] cache, ce

1785
01:18:37,260 --> 01:18:40,260
poate configura propriul cache, [neauzit]
cache [? d,?] ce vrei.

1786
01:18:40,260 --> 01:18:42,220
Pune în fața bazei de date.

1787
01:18:42,220 --> 01:18:47,250
Și în acest fel se pot stoca aceste date
din aceste taste în care cache

1788
01:18:47,250 --> 01:18:49,390
spațiu și citit prin cache-ul.

1789
01:18:49,390 --> 01:18:51,962
>> Și apoi de cele mai multe dvs. citește
începe aratand ca aceasta.

1790
01:18:51,962 --> 01:18:54,920
M-am toate aceste cache hit-uri aici
și m-am nimic întâmplă aici

1791
01:18:54,920 --> 01:18:59,330
deoarece baza de date este ședinței în spatele
cache și nu citește vin prin.

1792
01:18:59,330 --> 01:19:02,520
Dacă aș schimba datele din
baze de date, trebuie să actualizați cache-ul.

1793
01:19:02,520 --> 01:19:04,360
Putem folosi ceva
ca aburi pentru a face asta.

1794
01:19:04,360 --> 01:19:07,360
Și voi explica cum funcționează.

1795
01:19:07,360 --> 01:19:09,060
Bine, mesaje.

1796
01:19:09,060 --> 01:19:11,180
E-mail, vom folosi toate e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> Acesta este un exemplu destul de bun.

1798
01:19:12,540 --> 01:19:14,950
Avem un fel de masă mesaje.

1799
01:19:14,950 --> 01:19:17,040
Și ne-am Inbox și Outbox.

1800
01:19:17,040 --> 01:19:19,760
Aceasta este ceea ce ar fi SQL
arata ca pentru a construi acea inbox.

1801
01:19:19,760 --> 01:19:23,350
Noi tip de utilizare de același tip
strategiei de a utiliza lui GSI, a GSI

1802
01:19:23,350 --> 01:19:25,320
pentru cutia mea poștală și Outbox mea.

1803
01:19:25,320 --> 01:19:27,600
Așa că am primit mesajele prime provenind
în masa mea mesaje.

1804
01:19:27,600 --> 01:19:30,194
Și prima abordare a acestei
ar putea fi, spune, OK, nici o problema.

1805
01:19:30,194 --> 01:19:31,110
Am primit mesajele prime.

1806
01:19:31,110 --> 01:19:33,710
Mesaje provenind [Inaudibil],
mesaj ID, e minunat.

1807
01:19:33,710 --> 01:19:35,070
Asta e hash meu unic.

1808
01:19:35,070 --> 01:19:38,280
Am de gând să creeze două de GSI, o
pentru cutia mea poștală, una pentru Outbox mea.

1809
01:19:38,280 --> 01:19:40,530
Și primul lucru pe care voi face
este Voi spune cheia mea hash este

1810
01:19:40,530 --> 01:19:43,310
O să fie beneficiarul și
Am de gând pentru a aranja la data.

1811
01:19:43,310 --> 01:19:44,220
Acest lucru este fantastic.

1812
01:19:44,220 --> 01:19:45,890
Am punctul meu de vedere frumoasă aici.

1813
01:19:45,890 --> 01:19:47,780
Dar nu e un pic problemă aici.

1814
01:19:47,780 --> 01:19:50,891
Și aveți o acest lucru în
baze de date relationale, de asemenea.

1815
01:19:50,891 --> 01:19:52,390
Ei au numit partiționare verticală.

1816
01:19:52,390 --> 01:19:55,840
Doriți să vă păstrați datele dvs. de mare
departe de datele micile tale.

1817
01:19:55,840 --> 01:20:00,470
>> Și motivul pentru care se datorează faptului că trebuie să-
du-te citește elementele pentru a obține atributele.

1818
01:20:00,470 --> 01:20:05,570
Și dacă organismele mele sunt toate pe aici,
apoi citit doar câteva articole

1819
01:20:05,570 --> 01:20:08,560
dacă lungimea corpului meu este
o medie de 256 kiloocteți fiecare,

1820
01:20:08,560 --> 01:20:10,991
matematica devine destul de urât.

1821
01:20:10,991 --> 01:20:12,490
Deci, spun vreau să citesc inbox lui David.

1822
01:20:12,490 --> 01:20:14,520
Inbox lui David are 50 de elemente.

1823
01:20:14,520 --> 01:20:17,880
Media și dimensiunea este de 256 kilobytes.

1824
01:20:17,880 --> 01:20:21,730
Iată raportul meu de conversie
pentru a RCU este de patru kilobytes.

1825
01:20:21,730 --> 01:20:24,450
>> OK, să mergem cu
în cele din urmă consistent citește.

1826
01:20:24,450 --> 01:20:28,640
Sunt încă mănâncă 1600 RCU lui
doar pentru a citi inbox lui David.

1827
01:20:28,640 --> 01:20:29,950
Vai.

1828
01:20:29,950 --> 01:20:31,980
OK, acum sa ne gandim
despre modul în care funcționează aplicația.

1829
01:20:31,980 --> 01:20:35,340
Dacă sunt într-o aplicație de e-mail și
Mă uit la cutia mea poștală,

1830
01:20:35,340 --> 01:20:39,680
și mă uit la corpul de fiecare mesaj,
Nu, mă uit la rezumatele.

1831
01:20:39,680 --> 01:20:41,850
Mă uit la numai anteturile.

1832
01:20:41,850 --> 01:20:46,310
Deci, haideți să construim o structură de tabel
care arata mai mult ca asta.

1833
01:20:46,310 --> 01:20:49,470
>> Deci, aici e informația
care flux de lucru meu are nevoie de.

1834
01:20:49,470 --> 01:20:50,890
E în cutia mea poștală GSI.

1835
01:20:50,890 --> 01:20:53,800
Este data, expeditorul,
subiectul, iar apoi

1836
01:20:53,800 --> 01:20:56,790
ID-ul mesajului, ceea ce indică
înapoi la masa de mesaje

1837
01:20:56,790 --> 01:20:57,850
în cazul în care pot obține corpul.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Ei bine, acestea ar fi ID-uri de înregistrare.

1840
01:21:04,420 --> 01:21:09,850
Ei ar dori înapoi la
ID-uri articol de pe masa de Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Fiecare index creates-- întotdeauna
are întotdeauna elementul

1842
01:21:12,220 --> 01:21:15,750
ID ca parte de-- care
vine cu indicele.

1843
01:21:15,750 --> 01:21:17,414
>> In regula.

1844
01:21:17,414 --> 01:21:19,080
Audiența: îl spune în cazul în care este stocat?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Da, se spune
exactly-- exact ceea ce face.

1846
01:21:21,420 --> 01:21:22,644
Se spune aici e recordul meu re.

1847
01:21:22,644 --> 01:21:24,310
Și-l voi laturi Inapoi la dosarul meu re.

1848
01:21:24,310 --> 01:21:26,460
Exact.

1849
01:21:26,460 --> 01:21:29,490
OK, asa ca acum inbox mea este
de fapt mult mai mic.

1850
01:21:29,490 --> 01:21:32,210
Și acest fapt susține
fluxul de lucru de o aplicație de e-mail.

1851
01:21:32,210 --> 01:21:34,230
Deci cutia mea poștală, am faceți clic.

1852
01:21:34,230 --> 01:21:38,160
Mă duc de-a lungul și dau click pe mesaj,
că, atunci când am nevoie pentru a du-te corpul,

1853
01:21:38,160 --> 01:21:40,180
pentru că am de gând să
du-te la un punct de vedere diferit.

1854
01:21:40,180 --> 01:21:43,870
Deci, dacă te gândești tip MVC de
cadru, vedere modelul controler.

1855
01:21:43,870 --> 01:21:46,120
>> Modelul conține
date care vezi nevoile

1856
01:21:46,120 --> 01:21:48,130
și controlerul interacționează cu.

1857
01:21:48,130 --> 01:21:51,670
Când m-am schimba cadrul, atunci când
Am schimba perspectiva,

1858
01:21:51,670 --> 01:21:55,080
este OK pentru a reveni la
Server și repopula model,

1859
01:21:55,080 --> 01:21:56,860
pentru că asta e ceea ce așteaptă utilizatorul.

1860
01:21:56,860 --> 01:22:00,530
Când se schimbă puncte de vedere, atunci
ne putem întoarce la baza de date.

1861
01:22:00,530 --> 01:22:02,480
Deci e-mail, faceți clic pe.

1862
01:22:02,480 --> 01:22:03,710
Caut pentru organism.

1863
01:22:03,710 --> 01:22:04,330
Dus-întors.

1864
01:22:04,330 --> 01:22:05,680
Du-te corpul.

1865
01:22:05,680 --> 01:22:06,950
>> Am citit o mulțime mai puține date.

1866
01:22:06,950 --> 01:22:09,960
Eu doar citesc organismele care
David are nevoie de când are nevoie de ele.

1867
01:22:09,960 --> 01:22:14,230
Și nu mă ard în 1600
De RCU doar pentru a arăta inbox lui.

1868
01:22:14,230 --> 01:22:17,670
Deci, acum that-- aceasta este calea
că LSI sau GSI-- Îmi pare rău,

1869
01:22:17,670 --> 01:22:19,900
GSI, ar lucra.

1870
01:22:19,900 --> 01:22:25,450
Avem hash nostru beneficiarului.

1871
01:22:25,450 --> 01:22:27,030
Avem cheia gama la data.

1872
01:22:27,030 --> 01:22:31,380
Și avem atributele proiectate
că avem nevoie doar de a sprijini punctul de vedere.

1873
01:22:31,380 --> 01:22:34,300
>> Am roti că pentru outbox.

1874
01:22:34,300 --> 01:22:35,770
Hash pe expeditor.

1875
01:22:35,770 --> 01:22:39,612
Și în esență, avem
foarte frumos de vedere, curat.

1876
01:22:39,612 --> 01:22:41,570
Și este ne basically--
Au acest mesaje frumoase

1877
01:22:41,570 --> 01:22:45,870
Tabelul care fiind răspândit frumos deoarece
e hash numai, ID mesaj distribuit.

1878
01:22:45,870 --> 01:22:51,750
Și avem doi indici care
se rotesc pe a tabelului.

1879
01:22:51,750 --> 01:22:57,411
Bine, asa ca idee aici este nu
păstra datele mari si asta mic

1880
01:22:57,411 --> 01:22:57,910
împreună.

1881
01:22:57,910 --> 01:23:00,700
Partiție pe verticală,
partiție aceste tabele.

1882
01:23:00,700 --> 01:23:03,150
Nu citesc date nu trebuie să.

1883
01:23:03,150 --> 01:23:04,850
Bine, jocuri.

1884
01:23:04,850 --> 01:23:06,990
Tuturor ne place jocurile.

1885
01:23:06,990 --> 01:23:10,902
Cel puțin eu plac jocurile atunci.

1886
01:23:10,902 --> 01:23:12,735
Deci, unele dintre lucrurile
că avem de a face cu, atunci când

1887
01:23:12,735 --> 01:23:14,193
ne gândim despre jocuri de noroc, nu?

1888
01:23:14,193 --> 01:23:16,999
Jocuri in aceste zile, mai ales mobil
jocuri de noroc, este vorba de gândire.

1889
01:23:16,999 --> 01:23:19,540
Și am de gând să se rotească aici
pic departe de DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Am de gând să aducă în
o parte din discuția

1891
01:23:21,373 --> 01:23:24,240
în jurul unele dintre
alte tehnologii AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Dar ideea despre jocuri de noroc este de a gândi
despre în termeni de API-uri, API-uri, care sunt,

1893
01:23:28,930 --> 01:23:31,730
în general vorbind, HTTP și JSON.

1894
01:23:31,730 --> 01:23:34,550
Este modul în care jocurile mobile fel de
interacționa cu capetele lor înapoi.

1895
01:23:34,550 --> 01:23:35,850
Ei fac JSON postare.

1896
01:23:35,850 --> 01:23:40,660
Ei primesc date, și totul,
în general vorbind, în API-uri JSON frumoase.

1897
01:23:40,660 --> 01:23:44,950
>> Lucruri cum ar fi a lua prietenii, pentru a primi
datele clasament, de schimb,

1898
01:23:44,950 --> 01:23:47,699
utilizator conținutul generat,
împinge înapoi până la sistem,

1899
01:23:47,699 --> 01:23:49,740
acestea sunt tipuri de lucruri
că vom face.

1900
01:23:49,740 --> 01:23:52,542
Date activ binare, aceste date
ar putea să nu stea în baza de date.

1901
01:23:52,542 --> 01:23:54,250
Acest lucru ar putea sta într-o
magazin obiect, nu?

1902
01:23:54,250 --> 01:23:56,541
Dar baza de date este de gând să
încheia spune sistemului,

1903
01:23:56,541 --> 01:23:59,140
spune cererea
în cazul în care pentru a merge să-l.

1904
01:23:59,140 --> 01:24:03,550
Și în mod inevitabil, multiplayer
servere, infrastructura end spate,

1905
01:24:03,550 --> 01:24:06,180
și concepute pentru înaltă
disponibilitate și scalabilitate.

1906
01:24:06,180 --> 01:24:09,400
Deci, acestea sunt lucruri pe care noi toți doresc
în infrastructura de jocuri de astăzi.

1907
01:24:09,400 --> 01:24:12,160
>> Deci, haideți să aruncăm o privire la
ceea ce arata ca asta.

1908
01:24:12,160 --> 01:24:16,070
A primit un miez back end,
foarte simplu.

1909
01:24:16,070 --> 01:24:19,880
Avem un sistem de aici cu
mai multe zone de disponibilitate.

1910
01:24:19,880 --> 01:24:23,780
Am vorbit despre AZS ca being-- cred
dintre ele ca centre de date separate.

1911
01:24:23,780 --> 01:24:26,040
Centru de date mai mult de un
pe AZ, dar asta e OK,

1912
01:24:26,040 --> 01:24:28,831
gandeste-te de ele ca date separată
centre care sunt punct de vedere geografic

1913
01:24:28,831 --> 01:24:30,090
și vina izolat.

1914
01:24:30,090 --> 01:24:32,172
>> Vom avea o
cazuri cuplu EC2.

1915
01:24:32,172 --> 01:24:33,880
Vom avea
un server back end.

1916
01:24:33,880 --> 01:24:35,800
Poate daca esti o moștenire
arhitectura, suntem

1917
01:24:35,800 --> 01:24:38,920
folosind ceea ce numim RDS,
Servicii de baze de date relaționale.

1918
01:24:38,920 --> 01:24:42,040
Ar putea fi MSSQL, MySQL,
sau asa ceva.

1919
01:24:42,040 --> 01:24:47,080
Aceasta este modul în care o mulțime aplicații
sunt proiectate astăzi.

1920
01:24:47,080 --> 01:24:49,594
>> Ei bine, am putea vrei să mergi cu
acest lucru este atunci când ne scară afară.

1921
01:24:49,594 --> 01:24:51,510
Vom merge mai departe și a pus
găleată S3 acolo.

1922
01:24:51,510 --> 01:24:54,200
Și că găleată S3, în loc de servire
acele obiecte din servers-- nostru

1923
01:24:54,200 --> 01:24:55,220
am putea face asta.

1924
01:24:55,220 --> 01:24:57,210
Ai pus toate binar dvs.
obiecte de pe serverele dvs.

1925
01:24:57,210 --> 01:24:59,751
și puteți folosi cele de server
instanțe pentru a servi ca date de până.

1926
01:24:59,751 --> 01:25:01,860
Dar asta e destul de scump.

1927
01:25:01,860 --> 01:25:05,107
>> Modalitate mai bună de a face este merge mai departe și
pune aceste obiecte într-o găleată S3.

1928
01:25:05,107 --> 01:25:06,315
S3 este un arhive obiect.

1929
01:25:06,315 --> 01:25:10,860
Este construit special pentru
servind la aceste tipuri de lucruri.

1930
01:25:10,860 --> 01:25:13,690
Și să solicite acei clienți
direct de la aceste cupe obiect,

1931
01:25:13,690 --> 01:25:15,390
scape serverele.

1932
01:25:15,390 --> 01:25:17,020
Deci suntem incepand de la scară aici.

1933
01:25:17,020 --> 01:25:19,140
>> Acum avem de utilizatori din întreaga lume.

1934
01:25:19,140 --> 01:25:19,730
Am utilizatori.

1935
01:25:19,730 --> 01:25:23,380
Am nevoie pentru a avea conținut local
situat în apropiere de acești utilizatori, nu?

1936
01:25:23,380 --> 01:25:26,200
Am creat o găleată S3
ca depozit sursa mea.

1937
01:25:26,200 --> 01:25:29,370
Și voi față care cu
distribuția CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront este un CD și un
Content Delivery Network.

1939
01:25:31,720 --> 01:25:35,750
Practic este nevoie de date pe care le specificați
și tot cache pe internet

1940
01:25:35,750 --> 01:25:39,230
astfel încât utilizatorii de pretutindeni pot avea
un răspuns foarte rapid, atunci când

1941
01:25:39,230 --> 01:25:40,960
ei solicită aceste obiecte.

1942
01:25:40,960 --> 01:25:41,960
>> Astfel încât să obțineți o idee.

1943
01:25:41,960 --> 01:25:48,230
Ești un fel de pârghie tot
aspecte ale AWS aici pentru a obține făcut acest lucru.

1944
01:25:48,230 --> 01:25:50,790
Și, eventual,, ne arunca
într-un grup de scalare automată.

1945
01:25:50,790 --> 01:25:52,737
Deci cazuri noastre AC2
de serverele noastre de joc,

1946
01:25:52,737 --> 01:25:54,820
deoarece acestea încep să se ocupată
și mai plină și mai ocupat,

1947
01:25:54,820 --> 01:25:57,236
vor invarti doar un alt
exemplu, de spin-un alt exemplu,

1948
01:25:57,236 --> 01:25:58,210
rotească un alt exemplu.

1949
01:25:58,210 --> 01:26:02,090
Deci tehnologia AWS are, ea
permite să specificați parametrii

1950
01:26:02,090 --> 01:26:04,650
în jurul căreia serverele va crește.

1951
01:26:04,650 --> 01:26:08,110
Astfel încât să puteți avea număr n de servere
acolo la un moment dat.

1952
01:26:08,110 --> 01:26:11,870
Și dacă sarcina dumneavoastră dispare, ei vor
psihiatru, numărul se va micsora.

1953
01:26:11,870 --> 01:26:15,250
Și dacă sarcina se întoarce,
o să crească înapoi, elastic.

1954
01:26:15,250 --> 01:26:17,050
>> Deci, aceasta arata grozav.

1955
01:26:17,050 --> 01:26:19,800
Avem o mulțime de cazuri EC2.

1956
01:26:19,800 --> 01:26:21,671
Putem pune în cache
fata a bazelor de date,

1957
01:26:21,671 --> 01:26:23,045
încercați și să accelereze bazele de date.

1958
01:26:23,045 --> 01:26:25,030
Următorul punct de presiune
de obicei oamenii se vedea

1959
01:26:25,030 --> 01:26:28,850
este un joc de ei scară folosind un
sistem baze de date relaționale.

1960
01:26:28,850 --> 01:26:30,790
Doamne, baza de date
performanța este teribil.

1961
01:26:30,790 --> 01:26:31,932
Cum putem îmbunătăți asta?

1962
01:26:31,932 --> 01:26:33,640
Să încercăm punerea
cache în fața asta.

1963
01:26:33,640 --> 01:26:36,780
>> Ei bine, cache nu funcționează
atât de mare în jocuri, nu?

1964
01:26:36,780 --> 01:26:39,330
Pentru jocuri, scrisul este dureros.

1965
01:26:39,330 --> 01:26:40,930
Jocurile sunt foarte grele scrie.

1966
01:26:40,930 --> 01:26:43,610
Cache nu funcționează atunci când sunteți
scrie greu pentru că ai întotdeauna

1967
01:26:43,610 --> 01:26:44,610
Trebuie să actualizați cache-ul.

1968
01:26:44,610 --> 01:26:47,780
Vă actualizați cache-ul, e
irelevante să fie cache.

1969
01:26:47,780 --> 01:26:49,780
Este de fapt doar o muncă suplimentară.

1970
01:26:49,780 --> 01:26:51,970
>> Deci, unde mergem de aici?

1971
01:26:51,970 --> 01:26:54,400
Ai un blocaj mare
acolo în baza de date.

1972
01:26:54,400 --> 01:26:57,661
Și locul pentru a merge
evident, este de partiționare.

1973
01:26:57,661 --> 01:26:59,410
Partiționarea nu este
ușor să faci când ești

1974
01:26:59,410 --> 01:27:01,900
care se ocupă cu baze de date relaționale.

1975
01:27:01,900 --> 01:27:05,080
Cu baze de date relaționale, ești
responsabilă pentru gestionarea, în mod eficient,

1976
01:27:05,080 --> 01:27:06,210
spațiul cheie.

1977
01:27:06,210 --> 01:27:10,527
Ești utilizatorii între A și M spune
du-te aici, între N și Z acolo.

1978
01:27:10,527 --> 01:27:12,360
Și tu de comutare
peste aplicația.

1979
01:27:12,360 --> 01:27:15,000
Deci ai de a face cu
această sursă de date partiție.

1980
01:27:15,000 --> 01:27:18,670
Aveți constrângeri tranzacționale
care nu acopera partiții.

1981
01:27:18,670 --> 01:27:20,560
Ai tot felul de
messiness că ești

1982
01:27:20,560 --> 01:27:23,040
care se ocupă cu acolo încercând
să se ocupe de scalare din

1983
01:27:23,040 --> 01:27:25,120
și construirea unei infrastructuri mai mare.

1984
01:27:25,120 --> 01:27:27,284
E doar nici un haz.

1985
01:27:27,284 --> 01:27:30,930
>> Audiența: Deci vrei să spui că
creșterea puncte sursa accelerează

1986
01:27:30,930 --> 01:27:31,430
procesul?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Creșterea?

1988
01:27:32,513 --> 01:27:33,520
Puncte Sursa: audienta.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: puncte Sursa?

1990
01:27:34,410 --> 01:27:37,500
Audiența: Din informațiile,
în cazul în care informația vine de la?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: Nu.

1992
01:27:38,250 --> 01:27:41,820
Ce vreau să spun este creșterea
Numărul de partiții în depozitul de date

1993
01:27:41,820 --> 01:27:44,060
îmbunătățește tranzitată.

1994
01:27:44,060 --> 01:27:48,300
Deci, ce se întâmplă aici este utilizatori
vin în instanță EC2 aici,

1995
01:27:48,300 --> 01:27:50,780
Ei bine, dacă am nevoie de un utilizator
care este de la A la M, voi merge aici.

1996
01:27:50,780 --> 01:27:53,560
De la N la p, voi merge aici.

1997
01:27:53,560 --> 01:27:55,060
De la P la A la Z, mă duc aici.

1998
01:27:55,060 --> 01:27:57,120
>> Audiența: OK, cei atât de acestea sunt
toate stocate in diferite noduri?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Da.

2000
01:27:57,911 --> 01:28:00,210
Gândiți-vă la cum ar fi
diferite silozuri de date.

2001
01:28:00,210 --> 01:28:01,660
Deci a fi nevoie să facă acest lucru.

2002
01:28:01,660 --> 01:28:02,910
Dacă sunteți încercarea de a face
acest lucru, dacă sunteți încercarea de

2003
01:28:02,910 --> 01:28:05,730
la scară pe o platformă relațională,
acest lucru este ceea ce faci.

2004
01:28:05,730 --> 01:28:08,100
Iei date și
te-l taie.

2005
01:28:08,100 --> 01:28:10,975
Și tu o partiționare peste
mai multe instanțe ale bazei de date.

2006
01:28:10,975 --> 01:28:13,580
Și ești de gestionare toate
la nivel de aplicare.

2007
01:28:13,580 --> 01:28:14,729
Nu e amuzant.

2008
01:28:14,729 --> 01:28:15,770
Deci, ceea ce vrem să mergem?

2009
01:28:15,770 --> 01:28:20,240
Vrem să mergem DynamoDB, complet gestionate,
Magazin de date NoSQL, transfer dispoziție.

2010
01:28:20,240 --> 01:28:22,680
Noi folosim indici secundari.

2011
01:28:22,680 --> 01:28:26,154
Este practic HTTP API și
include suport de documente.

2012
01:28:26,154 --> 01:28:28,570
Deci nu trebuie să vă faceți griji
cu privire la orice de care partiționare.

2013
01:28:28,570 --> 01:28:30,740
Noi face totul pentru tine.

2014
01:28:30,740 --> 01:28:33,260
Deci, acum, în schimb, tu
doar scrie la masa.

2015
01:28:33,260 --> 01:28:36,490
Dacă tabela trebuie să fie partiționat,
ce se întâmplă în spatele scenei.

2016
01:28:36,490 --> 01:28:40,642
Ești complet izolate
din care ca un dezvoltator.

2017
01:28:40,642 --> 01:28:42,350
Deci, haideți să vorbim despre
unele cazuri de utilizare

2018
01:28:42,350 --> 01:28:47,564
că vom rula în în jocuri de noroc, comun
scenarii de jocuri, clasament.

2019
01:28:47,564 --> 01:28:49,980
Deci ai de utilizatori vine,
de BoardNames că sunt

2020
01:28:49,980 --> 01:28:52,930
pe, scorurile pentru acest utilizator.

2021
01:28:52,930 --> 01:28:57,700
S-ar putea să fie hashing pe UserID,
și apoi ne-am gamă pe joc.

2022
01:28:57,700 --> 01:28:59,960
Astfel încât fiecare utilizator vrea să vadă
tot jocul el a jucat

2023
01:28:59,960 --> 01:29:01,770
și toată scorul său top
în toate joc.

2024
01:29:01,770 --> 01:29:04,000
Deci, asta e clasament personal.

2025
01:29:04,000 --> 01:29:10,010
>> Acum vreau să merg și eu vreau să get--
așa că am obține aceste clasamente personale.

2026
01:29:10,010 --> 01:29:12,827
Ceea ce vreau să faceți este să mergeți obține
Scorul de sus a lungul tuturor utilizatorilor.

2027
01:29:12,827 --> 01:29:13,660
Deci, cum fac asta?

2028
01:29:13,660 --> 01:29:18,070
Când recordul meu este distribuit pe
UserID, variat pe joc,

2029
01:29:18,070 --> 01:29:20,740
bine am de gând să merg mai departe
și restructurarea, a crea un GSI,

2030
01:29:20,740 --> 01:29:22,370
și am de gând să restructureze aceste date.

2031
01:29:22,370 --> 01:29:27,310
>> Acum am de gând să hash cu privire la
BoardName, care este jocul.

2032
01:29:27,310 --> 01:29:29,800
Și am de gând să gama pe punctajul sus.

2033
01:29:29,800 --> 01:29:31,540
Și acum am creat diferite cupe.

2034
01:29:31,540 --> 01:29:34,790
Sunt folosind aceeași masă,
aceleași date element.

2035
01:29:34,790 --> 01:29:39,870
Dar eu sunt crearea unui găleată care oferă
mi o agregare de scor de top de joc.

2036
01:29:39,870 --> 01:29:43,180
>> Și pot interogare acea masă
pentru a obține aceste informații.

2037
01:29:43,180 --> 01:29:50,890
Deci am stabilit că modelul de interogare până la
fi susținută de un indice secundar.

2038
01:29:50,890 --> 01:29:54,556
Acum, ei pot fi sortate dupa BoardName
și clasificate în funcție de TopScore, în funcție de.

2039
01:29:54,556 --> 01:29:57,180
Deci, puteți vedea, acestea sunt tipurile
de utilizare cazuri pe care le obține în jocuri de noroc.

2040
01:29:57,180 --> 01:30:02,190
Un alt caz bună utilizare ajungem la jocuri de noroc
este premii și care a câștigat premii.

2041
01:30:02,190 --> 01:30:05,340
Și acesta este un caz de utilizare mare
în cazul în care o numim indici rare.

2042
01:30:05,340 --> 01:30:07,340
Indici rare sunt
capacitatea de a genera

2043
01:30:07,340 --> 01:30:10,850
un indice care nu neapărat
conțin fiecare element unic pe masă.

2044
01:30:10,850 --> 01:30:11,470
De ce nu?

2045
01:30:11,470 --> 01:30:14,540
Deoarece atributul care fiind
indexate nu exista pe fiecare element.

2046
01:30:14,540 --> 01:30:16,460
>> Deci, în acest special
utiliza caz, vreau să spun,

2047
01:30:16,460 --> 01:30:19,240
Știi ce, am de gând să
a crea un atribut numit Award.

2048
01:30:19,240 --> 01:30:22,970
Și am de gând să dea fiecare utilizator
care are un premiu care atribut.

2049
01:30:22,970 --> 01:30:25,950
Utilizatorii care nu au premii sunt
nu va avea acel atribut.

2050
01:30:25,950 --> 01:30:27,800
Așa că atunci când am crea
index, numai utilizatorii

2051
01:30:27,800 --> 01:30:28,960
care sunt de gând să arate
în indexul sunt

2052
01:30:28,960 --> 01:30:31,050
cei care de fapt au câștigat premii.

2053
01:30:31,050 --> 01:30:34,440
Deci asta e un mod minunat de a putea
pentru a crea indici filtrate că

2054
01:30:34,440 --> 01:30:40,580
sunt foarte, foarte selectiv, care nu
trebuie să indice întreaga masă.

2055
01:30:40,580 --> 01:30:43,050
>> Deci ne apropiem scăzut la timp aici.

2056
01:30:43,050 --> 01:30:49,190
Am de gând să merg mai departe și sări
afară și sări peste acest scenariu.

2057
01:30:49,190 --> 01:30:52,625
Vorbeste un pic about--

2058
01:30:52,625 --> 01:30:54,460
>> Audiența: Pot să pun o întrebare rapidă?

2059
01:30:54,460 --> 01:30:56,722
Una este a scrie greu?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Ce este?

2061
01:30:57,680 --> 01:30:58,596
Audiența: Scrieți grele.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Scrie grele.

2063
01:31:01,270 --> 01:31:03,460
Staţi să văd.

2064
01:31:03,460 --> 01:31:06,220
>> Audiența: Sau este că nu
ceva ce se poate doar

2065
01:31:06,220 --> 01:31:08,809
voce la o chestiune de secunde?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Mergem
prin scenariul de vot.

2067
01:31:10,850 --> 01:31:11,670
Nu e așa de rău.

2068
01:31:11,670 --> 01:31:14,580
Ai voi avea câteva minute?

2069
01:31:14,580 --> 01:31:15,860
BINE.

2070
01:31:15,860 --> 01:31:17,890
>> Deci, vom vorbi despre vot.

2071
01:31:17,890 --> 01:31:20,250
Deci, în timp real de vot, avem
Cerințe pentru vot.

2072
01:31:20,250 --> 01:31:25,250
Cerințe sunt că vom permite
fiecare persoană să voteze o singură dată.

2073
01:31:25,250 --> 01:31:28,060
Vrem nimeni să fie în măsură
pentru a schimba votul lor.

2074
01:31:28,060 --> 01:31:31,045
Ne dorim în timp real agregare
si analitica pentru demografice

2075
01:31:31,045 --> 01:31:34,210
că vom fi
arătând utilizatorilor pe site-ul.

2076
01:31:34,210 --> 01:31:35,200
>> Gândește-te la acest scenariu.

2077
01:31:35,200 --> 01:31:37,550
Noi lucram o mulțime de realitate
TV arată unde sunt

2078
01:31:37,550 --> 01:31:38,960
a face aceste tipul exact de lucruri.

2079
01:31:38,960 --> 01:31:41,584
Astfel încât să puteți gândi la scenariu,
avem milioane și milioane

2080
01:31:41,584 --> 01:31:43,959
fete de adolescente acolo
cu telefoanele lor mobile

2081
01:31:43,959 --> 01:31:46,250
și votarea, precum și de vot, precum și
vot pentru oricine ar fi

2082
01:31:46,250 --> 01:31:48,610
se pare a fi cel mai popular.

2083
01:31:48,610 --> 01:31:50,830
Deci, acestea sunt unele dintre cele
Cerințe am alerga afară.

2084
01:31:50,830 --> 01:31:52,990
>> Și astfel primul să ia
în rezolvarea acestei probleme

2085
01:31:52,990 --> 01:31:55,090
ar fi de a construi o
aplicație foarte simplu.

2086
01:31:55,090 --> 01:31:56,490
Așa că am această aplicație.

2087
01:31:56,490 --> 01:31:57,950
Am niște alegători acolo.

2088
01:31:57,950 --> 01:31:59,980
Ei vin în, au lovit aplicația de vot.

2089
01:31:59,980 --> 01:32:03,440
Am niște voturi de masă brută
Voi arunca doar acele voturi în.

2090
01:32:03,440 --> 01:32:05,780
Voi avea unele agregat
voturi tabel care

2091
01:32:05,780 --> 01:32:09,490
va face Analitica si demografice mele,
și vom pune toate acestea în acolo.

2092
01:32:09,490 --> 01:32:11,420
>> Și acest lucru este mare.

2093
01:32:11,420 --> 01:32:12,332
Viata e buna.

2094
01:32:12,332 --> 01:32:15,040
Viața e bine până când vom afla că
există întotdeauna doar una sau două

2095
01:32:15,040 --> 01:32:16,879
oameni care sunt populare în alegeri.

2096
01:32:16,879 --> 01:32:19,420
Nu e doar unul sau două lucruri
că oamenii cu adevărat pasă.

2097
01:32:19,420 --> 01:32:22,340
Și dacă sunteți de vot la
scară, dintr-o dată că sunt

2098
01:32:22,340 --> 01:32:26,360
va fi percuție dracu de
doi candidați, unul sau doi candidați.

2099
01:32:26,360 --> 01:32:29,390
Un număr foarte limitat de produse
oamenii găsesc a fi popular.

2100
01:32:29,390 --> 01:32:31,710
>> Acesta nu este un model de design bun.

2101
01:32:31,710 --> 01:32:33,549
Aceasta este de fapt o
model de design foarte rău

2102
01:32:33,549 --> 01:32:36,340
deoarece creează exact ceea ce ne-am
a vorbit despre ceea ce a fost taste.

2103
01:32:36,340 --> 01:32:38,960
Taste sunt ceva ce nu-mi place.

2104
01:32:38,960 --> 01:32:40,470
>> Deci, cum putem repara asta?

2105
01:32:40,470 --> 01:32:47,640
Și într-adevăr, modul de a rezolva această este
prin luarea aceste cupe candidate

2106
01:32:47,640 --> 01:32:51,490
și pentru fiecare candidat, avem,
vom adăuga o valoare aleatoare,

2107
01:32:51,490 --> 01:32:54,192
ceva ce știm, aleatoare
valoare între unul și 100,

2108
01:32:54,192 --> 01:32:56,620
între 100 și 1000,
sau între unul și 1000,

2109
01:32:56,620 --> 01:32:59,940
Cu toate acestea multe valori aleatoare pe care doriți să
adăugați pe sfârșitul acestei candidat.

2110
01:32:59,940 --> 01:33:01,330
>> Și ceea ce am cu adevărat făcut atunci?

2111
01:33:01,330 --> 01:33:05,830
Dacă eu sunt, folosind ID-ul candidat ca
galeata voturilor agregate,

2112
01:33:05,830 --> 01:33:08,780
dacă am adăugat o întâmplare
număr la sfârșitul anului că,

2113
01:33:08,780 --> 01:33:12,000
Am creat acum 10 de cupe, o
sute de cupe, o mie de galeti

2114
01:33:12,000 --> 01:33:14,160
că eu sunt cumularea de voturi peste.

2115
01:33:14,160 --> 01:33:18,030
>> Așa că au milioane, și milioane de oameni,
și milioane de înregistrări vine

2116
01:33:18,030 --> 01:33:22,050
pentru acești candidați, eu sunt acum de raspandire
aceste voturi din candidate A_1

2117
01:33:22,050 --> 01:33:24,630
prin candidate A_100, deoarece
de fiecare dată când un vot vine,

2118
01:33:24,630 --> 01:33:26,530
Am generând o întâmplare
valoare între unul și 100.

2119
01:33:26,530 --> 01:33:29,446
Am o capsare pe la sfârșitul
candidat care persoane cu drept de vot pentru.

2120
01:33:29,446 --> 01:33:31,120
Am o dumping în acea găleată.

2121
01:33:31,120 --> 01:33:33,910
>> Acum, pe partea din spate, știu
că am primit o sută de găleți.

2122
01:33:33,910 --> 01:33:36,350
Așa că, atunci când vreau să merg mai departe
și agregate din voturi,

2123
01:33:36,350 --> 01:33:38,244
Am citit de la toate aceste găleți.

2124
01:33:38,244 --> 01:33:39,160
Așa că am merge mai departe și se adaugă.

2125
01:33:39,160 --> 01:33:42,410
Și apoi eu difuzată aduna
în cazul în care mă duc afară și spun hei,

2126
01:33:42,410 --> 01:33:45,399
Știi ce, cheia acest candidat
spații este peste o sută de găleți.

2127
01:33:45,399 --> 01:33:47,940
Am de gând să aduna toate
voturi din aceste sute de găleți.

2128
01:33:47,940 --> 01:33:49,981
Am de gând pentru a agrega
ei și am de gând să spun,

2129
01:33:49,981 --> 01:33:53,830
Candidat A are acum
totală numărarea voturilor a X.

2130
01:33:53,830 --> 01:33:55,690
>> Acum atât de scriere
interogare și interogarea de citire

2131
01:33:55,690 --> 01:33:58,160
sunt frumos distribuite
pentru că eu scriu peste

2132
01:33:58,160 --> 01:34:00,320
și am citit peste sute de chei.

2133
01:34:00,320 --> 01:34:03,500
Nu scriu și
lectură peste o cheie acum.

2134
01:34:03,500 --> 01:34:04,950
Deci asta e un model de mare.

2135
01:34:04,950 --> 01:34:08,090
>> Aceasta este, de fapt, probabil, unul
dintre cele mai importante proiectare

2136
01:34:08,090 --> 01:34:10,420
modelelor de scară în NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Veți vedea acest tip de
model de design în fiecare aroma.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, aceasta nu
Indiferent, noi toți trebuie să facem acest lucru.

2139
01:34:19,100 --> 01:34:21,840
Pentru că atunci când ai de a face
cu aceste aglomerări mari,

2140
01:34:21,840 --> 01:34:26,650
va trebui să dau seama o modalitate de a
răspândit le peste găleți.

2141
01:34:26,650 --> 01:34:29,512
Astfel încât acesta este modul în care face acest lucru.

2142
01:34:29,512 --> 01:34:31,220
Bine, deci ce
ce faci chiar acum

2143
01:34:31,220 --> 01:34:35,252
este te de tranzacționare de pe citire
Costul pentru scalabilitate scriere.

2144
01:34:35,252 --> 01:34:37,085
Costul de citire meu este
un pic mai complex

2145
01:34:37,085 --> 01:34:40,220
și trebuie să mă duc citit dintr-o
sute de găleți în loc de unul.

2146
01:34:40,220 --> 01:34:41,310
Dar eu sunt în măsură să scrie.

2147
01:34:41,310 --> 01:34:44,860
Și de transfer mea, scrie mea
tranzitează este incredibil.

2148
01:34:44,860 --> 01:34:49,450
Deci, este, de obicei, un valoros
Tehnica pentru scalarea DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
sau orice bază de date NoSQL pentru care contează.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Deci, ne-am dat seama cum să-l scară.

2152
01:34:55,240 --> 01:34:56,930
Și ne-am gândit cum să
elimina cheile noastre fierbinte.

2153
01:34:56,930 --> 01:34:57,820
Și acest lucru este fantastic.

2154
01:34:57,820 --> 01:34:58,960
Și avem acest sistem frumos.

2155
01:34:58,960 --> 01:35:02,043
Și este ne-a dat vot foarte corect
pentru că avem de-record de vot dupe.

2156
01:35:02,043 --> 01:35:03,130
Este construit în DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Am vorbit despre drepturile condiționate.

2158
01:35:05,380 --> 01:35:08,170
>> Când un alegător vine, pune
o inserție pe masă,

2159
01:35:08,170 --> 01:35:11,220
ei introduce cu ID-ul lor la vot,
în cazul în care încercați să introduceți un alt vot,

2160
01:35:11,220 --> 01:35:13,320
Fac o scrie condiționată.

2161
01:35:13,320 --> 01:35:16,960
Spune doar scrie acest
Dacă acest lucru nu există.

2162
01:35:16,960 --> 01:35:19,270
Deci, de îndată ce văd că
că votul a lovit masa,

2163
01:35:19,270 --> 01:35:20,460
nimeni altcineva va fi
capabil de a pune votul în.

2164
01:35:20,460 --> 01:35:21,634
Și asta e fantastic.

2165
01:35:21,634 --> 01:35:23,550
Si suntem incrementarea
contoare noastre candidate.

2166
01:35:23,550 --> 01:35:25,466
Și facem nostru
demografice și tot ce.

2167
01:35:25,466 --> 01:35:29,110
Dar ce se întâmplă dacă meu
cerere cade?

2168
01:35:29,110 --> 01:35:31,350
Acum, toate dintr-o brusc voturi
provin din, și eu

2169
01:35:31,350 --> 01:35:34,840
Nu știu dacă acestea sunt obtinerea prelucrate
în analiză și demografice mele

2170
01:35:34,840 --> 01:35:36,040
mai.

2171
01:35:36,040 --> 01:35:38,462
Și atunci când cererea
vine înapoi, cum

2172
01:35:38,462 --> 01:35:41,420
dracu 'știu ce au de voturi
fost prelucrate și în cazul în care să încep?

2173
01:35:41,420 --> 01:35:44,530
>> Deci, aceasta este o problemă reală, atunci când
începe să se uite la acest tip de scenariu.

2174
01:35:44,530 --> 01:35:45,571
Și cum vom rezolva asta?

2175
01:35:45,571 --> 01:35:48,070
Am rezolvat cu ceea ce am
apel DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Fluxuri este un timp și ordonat
jurnal schimbare a separat de fiecare acces

2177
01:35:53,470 --> 01:35:55,700
la masa, fiecare scrie
accesul la masa.

2178
01:35:55,700 --> 01:35:58,810
Orice date care este scris la
Tabelul apare pe fluxul.

2179
01:35:58,810 --> 01:36:01,815
>> Este de fapt o coadă 24 de ore.

2180
01:36:01,815 --> 01:36:03,690
Articole lovit fluxul,
ei trăiesc pentru 24 de ore.

2181
01:36:03,690 --> 01:36:05,990
Ele pot fi citite de mai multe ori.

2182
01:36:05,990 --> 01:36:09,400
Garantat pentru a fi livrate
o singură dată la fluxul,

2183
01:36:09,400 --> 01:36:11,180
ar putea fi citit n numărul de ori.

2184
01:36:11,180 --> 01:36:14,910
Deci, cu toate acestea de multe procese pe care doriți să
consuma aceste date, puteți consuma.

2185
01:36:14,910 --> 01:36:16,350
Acesta va apărea în fiecare actualizare.

2186
01:36:16,350 --> 01:36:18,455
Fiecare scrie va numai
apar o dată pe fluxul de.

2187
01:36:18,455 --> 01:36:20,621
Deci nu trebuie să vă faceți griji
despre procesarea de două ori

2188
01:36:20,621 --> 01:36:22,500
din același proces.

2189
01:36:22,500 --> 01:36:25,350
>> Este strict ordonat pe articol.

2190
01:36:25,350 --> 01:36:28,180
Când spunem timp
ordonat și împărțit,

2191
01:36:28,180 --> 01:36:30,680
veți vedea pe partiția pe fluxul.

2192
01:36:30,680 --> 01:36:33,169
Veți vedea un produs, actualizări în ordine.

2193
01:36:33,169 --> 01:36:35,210
Noi nu sunt garantarea
pe fluxul pe care esti

2194
01:36:35,210 --> 01:36:40,240
mergi la a lua fiecare tranzacție
în ordinea în întreaga obiecte.

2195
01:36:40,240 --> 01:36:42,440
>> Deci, fluxuri sunt idempotent.

2196
01:36:42,440 --> 01:36:44,037
Nu știm cu toții ce înseamnă idempotent?

2197
01:36:44,037 --> 01:36:46,620
Idempotent înseamnă că puteți face acest lucru
peste și peste și peste din nou.

2198
01:36:46,620 --> 01:36:48,200
Rezultatul va fi la fel.

2199
01:36:48,200 --> 01:36:49,991
>> Fluxuri sunt idempotent,
dar acestea trebuie să fie

2200
01:36:49,991 --> 01:36:54,860
jucat la punctul de pornire,
ori de câte ori doriți, până la sfârșit,

2201
01:36:54,860 --> 01:36:57,950
sau ei nu vor avea ca rezultat
în aceleași valori.

2202
01:36:57,950 --> 01:36:59,727
>> Acelasi lucru cu MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB are un construct
ei numesc oplog.

2204
01:37:01,560 --> 01:37:04,140
Este același construct exact.

2205
01:37:04,140 --> 01:37:06,500
Baze de date NoSQL multe
au acest construct.

2206
01:37:06,500 --> 01:37:08,790
Ei l utilizați pentru a face lucruri
ca de replicare, care

2207
01:37:08,790 --> 01:37:10,475
este exact ceea ce facem cu fluxuri.

2208
01:37:10,475 --> 01:37:12,350
Audiența: Poate un
întrebare eretic, dar

2209
01:37:12,350 --> 01:37:13,975
vorbesc despre Apps face pe un asa mai departe.

2210
01:37:13,975 --> 01:37:16,089
Sunt fluxuri garantat
nu merge, eventual, în jos?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Da, fluxuri
sunt garantate pentru a nu merge în jos.

2212
01:37:18,630 --> 01:37:21,040
Noi gestionăm infrastructura
din spatele. fluxuri automat

2213
01:37:21,040 --> 01:37:22,498
desfășoare în grupul lor de scalare Auto.

2214
01:37:22,498 --> 01:37:25,910
Vom merge printr-un pic
bit despre ceea ce se întâmplă.

2215
01:37:25,910 --> 01:37:30,060
>> Nu ar trebui să spun că nu sunt
garantat de a nu merge în jos.

2216
01:37:30,060 --> 01:37:33,110
Elementele sunt garantate
să apară în fluxul.

2217
01:37:33,110 --> 01:37:36,740
Și fluxul va fi accesibil.

2218
01:37:36,740 --> 01:37:40,580
Deci, ceea ce duce în jos sau se întoarce
up, ce se întâmplă dedesubt.

2219
01:37:40,580 --> 01:37:43,844
Este covers-- e OK.

2220
01:37:43,844 --> 01:37:46,260
În regulă, astfel încât să obțineți diferite
Tipuri de vedere în afara ecranului.

2221
01:37:46,260 --> 01:37:51,040
Tipurile de părere că sunt importante pentru o
programator de obicei sunt, ceea ce a fost?

2222
01:37:51,040 --> 01:37:52,370
I a lua punctul de vedere vechi.

2223
01:37:52,370 --> 01:37:55,630
Atunci când o actualizare lovește masa, va
împinge vederea vechi pentru fluxul

2224
01:37:55,630 --> 01:38:02,070
astfel de date pot arhiva, sau schimbare
controlul, identificarea schimbare, schimbare

2225
01:38:02,070 --> 01:38:03,600
management.

2226
01:38:03,600 --> 01:38:07,160
>> Noua imagine, ceea ce este acum, după
actualizarea, asta e un alt tip de vedere

2227
01:38:07,160 --> 01:38:07,660
poți obține.

2228
01:38:07,660 --> 01:38:09,660
Puteți obține atât imagini vechi și noi.

2229
01:38:09,660 --> 01:38:10,660
Poate că amândoi doresc.

2230
01:38:10,660 --> 01:38:11,790
Vreau să văd ce era.

2231
01:38:11,790 --> 01:38:13,290
Vreau să văd ce sa schimbat la.

2232
01:38:13,290 --> 01:38:15,340
>> Am un tip de conformitate
de proces care ruleaza.

2233
01:38:15,340 --> 01:38:17,430
Acesta trebuie să verifice că
atunci când aceste lucruri se schimbă,

2234
01:38:17,430 --> 01:38:21,840
că sunt în anumite limite
sau în anumiți parametri.

2235
01:38:21,840 --> 01:38:23,840
>> Și apoi doar poate că
Trebuie să știu ce sa schimbat.

2236
01:38:23,840 --> 01:38:26,240
Nu-mi pasă ce articol sa schimbat.

2237
01:38:26,240 --> 01:38:28,580
Nu am nevoie sa trebuie să știe
ce atribute schimbat.

2238
01:38:28,580 --> 01:38:30,882
Vreau doar să știu că
produsele sunt atinse.

2239
01:38:30,882 --> 01:38:33,340
Deci, acestea sunt tipurile de vizualizări
pe care le obține de pe fluxul

2240
01:38:33,340 --> 01:38:35,960
și puteți interacționa cu.

2241
01:38:35,960 --> 01:38:37,840
>> Cererea că
consumă fluxul,

2242
01:38:37,840 --> 01:38:39,298
Aceasta este un fel de modul în care aceasta funcționează.

2243
01:38:39,298 --> 01:38:42,570
Client DynamoDB cere să
împinge date pentru tabele.

2244
01:38:42,570 --> 01:38:44,750
Fluxuri implementa pe ceea ce noi numim cioburi.

2245
01:38:44,750 --> 01:38:47,380
Cioburi sunt scalate
independent de masă.

2246
01:38:47,380 --> 01:38:50,660
Ei nu sunt aliniate complet
la partițiile de masa ta.

2247
01:38:50,660 --> 01:38:52,540
Și motivul pentru care este
pentru că linia de sus

2248
01:38:52,540 --> 01:38:55,430
la capacitatea, curentul
Capacitatea de tabel.

2249
01:38:55,430 --> 01:38:57,600
>> Ei implementa în lor
propriul grup scalare Auto,

2250
01:38:57,600 --> 01:39:00,800
și încep să se rotească în funcție
cu privire la modul de multe scrieri vin în,

2251
01:39:00,800 --> 01:39:03,090
cât de multe reads-- într-adevăr e scrie.

2252
01:39:03,090 --> 01:39:05,820
Nu e nici o reads-- dar cum
multe scrieri vin în.

2253
01:39:05,820 --> 01:39:08,200
>> Și apoi pe spate
scop, avem ceea ce ne

2254
01:39:08,200 --> 01:39:11,390
apela un KCL sau Kinesis Client Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis este o date flux
tehnologia de procesare de la Amazon.

2256
01:39:19,190 --> 01:39:22,040
Și fluxuri este construit pe asta.

2257
01:39:22,040 --> 01:39:25,670
>> Astfel încât să utilizați o KCL activat
aplicații să citească fluxul.

2258
01:39:25,670 --> 01:39:28,752
Kinesis Client Biblioteca de fapt
gestionează muncitorii pentru tine.

2259
01:39:28,752 --> 01:39:30,460
Și-l face, de asemenea, unele
lucruri interesante.

2260
01:39:30,460 --> 01:39:35,630
Se va crea unele tabele până
în tablespace dumneavoastră DynamoDB

2261
01:39:35,630 --> 01:39:38,410
pentru a urmări care un produs
au fost procesate.

2262
01:39:38,410 --> 01:39:41,190
Deci, în acest fel, dacă se cade înapoi, în cazul în care
cade peste și vine și devine

2263
01:39:41,190 --> 01:39:45,570
stătea înapoi, se poate determina în cazul în care
era în procesarea fluxul.

2264
01:39:45,570 --> 01:39:48,360
>> Asta e foarte important atunci când
vorbești despre replicarea.

2265
01:39:48,360 --> 01:39:50,350
Trebuie să știu ce
datele au fost procesate

2266
01:39:50,350 --> 01:39:52,810
și ce date a fost încă să fie prelucrate.

2267
01:39:52,810 --> 01:39:57,380
Deci biblioteca KCL pentru fluxurile va
vă dau o mulțime de funcționalități care.

2268
01:39:57,380 --> 01:39:58,990
Este nevoie de grijă de toate menaj.

2269
01:39:58,990 --> 01:40:01,140
Acesta se ridică un lucrător pentru fiecare ciob.

2270
01:40:01,140 --> 01:40:04,620
Se creează un tabel administrativ
pentru fiecare ciob, pentru fiecare lucrător.

2271
01:40:04,620 --> 01:40:07,560
Și, după cum cei lucrători foc,
mențin aceste tabele

2272
01:40:07,560 --> 01:40:10,510
astfel încât să știi această înregistrare
a fost citit și prelucrate.

2273
01:40:10,510 --> 01:40:13,850
Și apoi în acest fel, dacă procesul de
moare și vine din nou online,

2274
01:40:13,850 --> 01:40:17,940
se poate relua chiar în cazul în care acesta a plecat.

2275
01:40:17,940 --> 01:40:20,850
>> Deci, vom folosi acest lucru pentru
eco-regiune replicare.

2276
01:40:20,850 --> 01:40:24,680
O mulțime de clienți au nevoie de a
muta de date sau părți de tabele de date

2277
01:40:24,680 --> 01:40:25,920
în jurul valorii de la diferite regiuni.

2278
01:40:25,920 --> 01:40:29,230
Există nouă regiuni
in toata lumea.

2279
01:40:29,230 --> 01:40:32,100
Deci, ar putea fi o am need--
ar putea avea utilizatorii în Asia, utilizatorii

2280
01:40:32,100 --> 01:40:34,150
în Coasta de Est a Statelor Unite.

2281
01:40:34,150 --> 01:40:38,980
Ei au date diferite care
trebuie să fie distribuite la nivel local.

2282
01:40:38,980 --> 01:40:42,510
Și poate un utilizator zboară de la
Asia pe la Statele Unite ale Americii,

2283
01:40:42,510 --> 01:40:45,020
și vreau să reproducă
datele sale cu el.

2284
01:40:45,020 --> 01:40:49,340
Deci, atunci când el devine din avion, el are
o experiență bună, folosind aplicația său mobil.

2285
01:40:49,340 --> 01:40:52,360
>> Puteți utiliza eco-regiunea
Biblioteca de replicare pentru a face acest lucru.

2286
01:40:52,360 --> 01:40:55,730
Practic ne-am
prevăzute două tehnologii.

2287
01:40:55,730 --> 01:40:59,400
Unul o aplicație consolă puteți
se ridice în picioare pe cont propriu instanță EC2.

2288
01:40:59,400 --> 01:41:01,240
Se ruleaza replicare pur.

2289
01:41:01,240 --> 01:41:02,720
Și apoi v-am oferit biblioteca.

2290
01:41:02,720 --> 01:41:06,070
Biblioteca puteți utiliza pentru a construi
propria aplicație dacă

2291
01:41:06,070 --> 01:41:10,740
vrei sa faci lucruri nebunești cu care data--
filtru, reproduce doar o parte din ea,

2292
01:41:10,740 --> 01:41:14,120
roti de date, mutați-l într-un
tabel diferit, așa mai departe și așa mai departe.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Deci, asta e un fel de ceea ce arata ca la fel ca.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams poate fi
prelucrate de ceea ce noi numim Lambda.

2296
01:41:23,690 --> 01:41:27,394
Am menționat un pic despre eveniment
arhitecturi de aplicare condus.

2297
01:41:27,394 --> 01:41:28,810
Lambda este o componentă cheie a acestei.

2298
01:41:28,810 --> 01:41:32,840
Lambda este cod care trage la cerere
ca răspuns la un anumit eveniment.

2299
01:41:32,840 --> 01:41:36,020
Unul dintre aceste evenimente ar putea fi un
înregistrare care apare pe fluxul.

2300
01:41:36,020 --> 01:41:39,100
Dacă apare o înregistrare pe fluxul,
vom numi acest funcție Java.

2301
01:41:39,100 --> 01:41:44,980
Ei bine, acest lucru este JavaScript, și Lambda
sprijină Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
și va sprijini în curând
alte limbi, de asemenea.

2303
01:41:47,820 --> 01:41:50,940
Și suficient să spun, că e cod pur.

2304
01:41:50,940 --> 01:41:53,610
scrie în Java, definiți o clasă.

2305
01:41:53,610 --> 01:41:55,690
Tu împingeți JAR sus în Lambda.

2306
01:41:55,690 --> 01:42:00,200
Și apoi să specificați care clasa
pentru a apela, ca răspuns la care eveniment.

2307
01:42:00,200 --> 01:42:04,770
Și apoi infrastructurii Lambda
în spatele că va rula acel cod.

2308
01:42:04,770 --> 01:42:06,730
>> Acest cod poate procesa
înregistrările de pe fluxul.

2309
01:42:06,730 --> 01:42:08,230
Se poate face orice vrea cu el.

2310
01:42:08,230 --> 01:42:11,650
În acest exemplu particular, toate suntem
într-adevăr a face este de logare atributele.

2311
01:42:11,650 --> 01:42:13,480
Dar aceasta este doar cod.

2312
01:42:13,480 --> 01:42:15,260
Cod pot face nimic, nu?

2313
01:42:15,260 --> 01:42:16,600
>> Astfel încât să puteți roti că datele.

2314
01:42:16,600 --> 01:42:18,160
Puteți crea o imagine derivat.

2315
01:42:18,160 --> 01:42:21,160
Daca este o structură de document,
puteți aplatiza structura.

2316
01:42:21,160 --> 01:42:24,300
Puteți crea indici alternative.

2317
01:42:24,300 --> 01:42:27,100
Tot felul de lucruri pe care le puteți
face cu Izvoare DynamoDB.

2318
01:42:27,100 --> 01:42:28,780
>> Și într-adevăr, asta e ceea ce pare ca la fel ca.

2319
01:42:28,780 --> 01:42:29,940
Astfel încât să obțineți cele actualizări vine.

2320
01:42:29,940 --> 01:42:31,190
Vin de pe șirul.

2321
01:42:31,190 --> 01:42:32,720
Sunt citit de funcția Lambda.

2322
01:42:32,720 --> 01:42:37,480
Ei rotirea datelor și
împingându-l în tabele derivate,

2323
01:42:37,480 --> 01:42:42,200
notificarea sisteme externe de schimbare,
și împingând de date în ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Am vorbit despre cum să pună cache
în fața bazei de date pentru că vânzările

2325
01:42:45,900 --> 01:42:46,450
scenariu.

2326
01:42:46,450 --> 01:42:50,049
Ei bine, ce se întâmplă dacă am
actualiza descrierea articolului?

2327
01:42:50,049 --> 01:42:52,340
Ei bine, dacă am avut o Lambda
Funcția rulează pe masa,

2328
01:42:52,340 --> 01:42:55,490
dacă am actualiza descrierea element, acesta va
ridica înregistrarea de pe fluxul,

2329
01:42:55,490 --> 01:42:58,711
și-l vom actualiza ElastiCache
exemplu cu noile date.

2330
01:42:58,711 --> 01:43:00,460
Așa că o mulțime de
ceea ce facem cu Lambda.

2331
01:43:00,460 --> 01:43:02,619
E cod lipici, conectori.

2332
01:43:02,619 --> 01:43:04,410
Și oferă de fapt
abilitatea de a lansa

2333
01:43:04,410 --> 01:43:07,930
și de a rula aplicații foarte complexe
fără un server dedicat

2334
01:43:07,930 --> 01:43:10,371
infrastructurii, care este foarte misto.

2335
01:43:10,371 --> 01:43:13,100
>> Deci, să ne întoarcem la nostru
în timp real arhitectura vot.

2336
01:43:13,100 --> 01:43:17,984
Acest lucru este nou si imbunatatit cu nostru
cursuri de apă și KCL activat aplicație.

2337
01:43:17,984 --> 01:43:20,150
Fel ca înainte, putem
se ocupe de orice scară de la alegeri.

2338
01:43:20,150 --> 01:43:21,100
Ne place asta.

2339
01:43:21,100 --> 01:43:24,770
Facem din adună scatter
pe mai multe găleți.

2340
01:43:24,770 --> 01:43:26,780
Avem de blocare optimistă întâmplă.

2341
01:43:26,780 --> 01:43:30,192
Putem păstra alegătorii noștri
la schimbarea voturile lor.

2342
01:43:30,192 --> 01:43:31,400
Ei pot vota doar o singură dată.

2343
01:43:31,400 --> 01:43:32,880
Acest lucru este fantastic.

2344
01:43:32,880 --> 01:43:35,895
În timp real toleranței la erori,
agregare scalabil acum.

2345
01:43:35,895 --> 01:43:38,270
În cazul în care lucrul cade, aceasta
știe unde să se reporni

2346
01:43:38,270 --> 01:43:41,300
atunci când vine vorba înapoi, deoarece
suntem folosind aplicația KCL.

2347
01:43:41,300 --> 01:43:45,700
Și apoi putem folosi, de asemenea, că
Cerere KCL pentru a împinge afară de date

2348
01:43:45,700 --> 01:43:48,820
a Redshift pentru alte
Analytics app, sau utilizare

2349
01:43:48,820 --> 01:43:51,990
de MapReduce elastice pentru a rula
în timp real de streaming de pe agregate

2350
01:43:51,990 --> 01:43:53,180
de faptul că datele.

2351
01:43:53,180 --> 01:43:55,480
>> Deci, acestea sunt lucruri pe care le
nu s-au vorbit despre mult.

2352
01:43:55,480 --> 01:43:57,375
Dar sunt suplimentare
tehnologii care vin

2353
01:43:57,375 --> 01:44:00,310
să suporte atunci când sunteți în căutarea
La aceste tipuri de scenarii.

2354
01:44:00,310 --> 01:44:03,160
>> Bine, pentru ca este vorba despre
analytics cu DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
Puteți colecta de-dupe
date, face tot felul

2356
01:44:05,340 --> 01:44:09,490
de lucruri frumos, date agregate în
memorie, crea aceste tabele derivate.

2357
01:44:09,490 --> 01:44:13,110
Asta e un caz de utilizare imens
că o mulțime de clienți

2358
01:44:13,110 --> 01:44:16,950
sunt implicate cu, luând imbricate
proprietăți ale acestor documente JSON

2359
01:44:16,950 --> 01:44:18,946
și crearea de indici suplimentare.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Suntem la sfârșitul anului.

2362
01:44:23,150 --> 01:44:26,689
Vă mulțumim pentru poartă cu mine.

2363
01:44:26,689 --> 01:44:28,480
Deci, haideți să vorbim despre
arhitectura de referință.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB stă în mijlocul atât de
mare parte din infrastructura AWS.

2365
01:44:33,440 --> 01:44:37,090
Practic puteti cârlig
până la tot ce vrei.

2366
01:44:37,090 --> 01:44:45,600
Aplicații construit folosind Dynamo includ
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
împinge datele în afară Elastic
MapReduce, import export din DynamoDB

2368
01:44:49,890 --> 01:44:52,370
în S3, tot felul de fluxuri de lucru.

2369
01:44:52,370 --> 01:44:54,120
Dar, probabil, cel mai bun
lucru pentru a vorbi despre,

2370
01:44:54,120 --> 01:44:56,119
și acest lucru este într-adevăr ceea ce este
interesant este atunci când ne

2371
01:44:56,119 --> 01:44:58,350
vorbesc despre aplicații bazate pe eveniment.

2372
01:44:58,350 --> 01:45:00,300
>> Acesta este un exemplu de
un proiect intern

2373
01:45:00,300 --> 01:45:04,850
pe care o avem atunci când suntem de fapt
publicare pentru a aduna rezultatele sondajului.

2374
01:45:04,850 --> 01:45:07,700
Deci, într-un link de e-mail care
am trimite, acolo va

2375
01:45:07,700 --> 01:45:11,350
fi un pic click link spunând
aici pentru a răspunde la sondaj.

2376
01:45:11,350 --> 01:45:14,070
Și atunci când o persoană clicuri
care se leagă, ceea ce se întâmplă

2377
01:45:14,070 --> 01:45:18,020
este că trage în jos o sigură
Formular de sondaj HTML de la S3.

2378
01:45:18,020 --> 01:45:18,980
Nu e nici un server.

2379
01:45:18,980 --> 01:45:20,600
Acesta este doar un obiect S3.

2380
01:45:20,600 --> 01:45:22,770
>> Această formă vine,
încarcă în browser-ul.

2381
01:45:22,770 --> 01:45:24,240
Are Backbone.

2382
01:45:24,240 --> 01:45:30,160
Are complex JavaScript
că este pornit.

2383
01:45:30,160 --> 01:45:33,557
Deci, este foarte bogat aplicație
rulează în browser-ul clientului.

2384
01:45:33,557 --> 01:45:36,390
Ei nu știu că nu sunt
interacționând cu un server back end.

2385
01:45:36,390 --> 01:45:38,220
În acest moment, totul browser.

2386
01:45:38,220 --> 01:45:41,780
>> Ei publica rezultatele la ceea ce
numim Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway este pur și simplu un API web
pe care le puteți defini și cârlig până

2388
01:45:46,270 --> 01:45:47,760
pentru ce vrei tu.

2389
01:45:47,760 --> 01:45:50,990
În acest caz particular, suntem
conectat la o funcție Lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Deci operațiune meu post este
întâmplă cu nici un server.

2391
01:45:54,797 --> 01:45:56,380
Practic că API Gateway sta acolo.

2392
01:45:56,380 --> 01:45:58,770
Ea mă costă nimic până când oamenii
începe să postați la ea, nu?

2393
01:45:58,770 --> 01:46:00,269
Funcția Lambda doar sta acolo.

2394
01:46:00,269 --> 01:46:03,760
Și mă costă nimic până
oamenii încep să-l lovi.

2395
01:46:03,760 --> 01:46:07,270
Deci, puteți vedea, ca volumul
crește, atunci vin taxele.

2396
01:46:07,270 --> 01:46:09,390
Nu am rulează un server 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Așa că am trage formularul
jos din găleată,

2398
01:46:12,310 --> 01:46:15,719
și am posta, prin API
Gateway în funcția Lambda.

2399
01:46:15,719 --> 01:46:17,510
Și apoi Lambda
Funcția spune, știi

2400
01:46:17,510 --> 01:46:20,600
ceea ce, am niște PIIs, unele
informații de identificare personală

2401
01:46:20,600 --> 01:46:21,480
în aceste raspunsuri.

2402
01:46:21,480 --> 01:46:23,020
Am comentariile provenind din utilizatori.

2403
01:46:23,020 --> 01:46:24,230
Am adrese de email.

2404
01:46:24,230 --> 01:46:26,190
Am nume de utilizator.

2405
01:46:26,190 --> 01:46:27,810
>> Lasă-mă să împartă acest off.

2406
01:46:27,810 --> 01:46:30,280
Am de gând să genereze unele
metadate de pe acest record.

2407
01:46:30,280 --> 01:46:32,850
Și am de gând pentru a împinge
metadate în DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Și am putut cripta toate datele
și-l împinge în DynamoDB dacă vreau.

2409
01:46:36,059 --> 01:46:38,600
Dar este mai ușor pentru mine, în acest
utiliza caz, pentru a merge mai departe un cuvânt de spus,

2410
01:46:38,600 --> 01:46:42,800
Am de gând să împingă datele brute
într-o găleată S3 criptat.

2411
01:46:42,800 --> 01:46:47,240
Asa ca am folosi construit în partea de server S3
criptare și Key Management Amazon

2412
01:46:47,240 --> 01:46:51,600
Serviciu, astfel că am o cheie care
se poate roti pe un interval regulat,

2413
01:46:51,600 --> 01:46:55,010
și pot proteja că datele PII
ca parte a fluxului de lucru întregi acest.

2414
01:46:55,010 --> 01:46:55,870
>> Deci, ce am făcut?

2415
01:46:55,870 --> 01:47:00,397
Tocmai am desfășurat o întreagă
cerere, și nu am nici un server.

2416
01:47:00,397 --> 01:47:02,980
Deci, este ceea ce evenimente de aplicație condus
Arhitectura nu pentru tine.

2417
01:47:02,980 --> 01:47:05,730
>> Acum, dacă te gândești la
în cazul utilizării pentru astea--

2418
01:47:05,730 --> 01:47:08,730
avem alți clienți să vorbesc
la aproximativ această arhitectură exacta care

2419
01:47:08,730 --> 01:47:14,560
campanii fenomenal mari, care
se uita la acest lucru și merge, oh meu.

2420
01:47:14,560 --> 01:47:17,840
Pentru că acum, ei pot
Practic împinge acolo,

2421
01:47:17,840 --> 01:47:21,900
lăsa să se campanie sta
acolo până când se lansează, și nu

2422
01:47:21,900 --> 01:47:24,400
trebuie să vă faceți o smochin despre
Ce fel de infrastructură

2423
01:47:24,400 --> 01:47:26,120
va fi acolo să o susțină.

2424
01:47:26,120 --> 01:47:28,600
Și apoi, de îndată ce
campania se face,

2425
01:47:28,600 --> 01:47:31,520
e ca si cum infrastructura
doar imediat dispare

2426
01:47:31,520 --> 01:47:33,680
într-adevăr, deoarece nu
nu este infrastructură.

2427
01:47:33,680 --> 01:47:35,660
E cod doar că stă pe Lambda.

2428
01:47:35,660 --> 01:47:38,560
E doar datele care stă în DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Acesta este un mod uimitor
pentru a construi aplicații.

2430
01:47:41,340 --> 01:47:43,970
>> Audiența: Deci este mai mult
efemer decât ar fi

2431
01:47:43,970 --> 01:47:45,740
în cazul în care a fost stocat pe un server real?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Absolut.

2433
01:47:46,823 --> 01:47:49,190
Pentru că serverul exemplu
ar trebui să fie un 7/24.

2434
01:47:49,190 --> 01:47:51,954
Trebuie să fie disponibile pentru
cineva pentru a răspunde la.

2435
01:47:51,954 --> 01:47:52,620
Ei bine, ghici ce?

2436
01:47:52,620 --> 01:47:55,410
S3 este disponibil 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 răspunde întotdeauna.

2438
01:47:57,100 --> 01:47:59,320
Și S3 este foarte, foarte bun
la servire obiecte.

2439
01:47:59,320 --> 01:48:02,590
Aceste obiecte pot fi fișiere HTML, sau
Fișiere JavaScript, sau ce vrei tu.

2440
01:48:02,590 --> 01:48:07,430
Puteți rula aplicații web foarte bogate
din S3 găleți, și oamenii.

2441
01:48:07,430 --> 01:48:10,160
>> Și așa că e ideea aici
este de a obtine departe de drum

2442
01:48:10,160 --> 01:48:11,270
am folosit să mă gândesc.

2443
01:48:11,270 --> 01:48:14,270
Cu toții să ne gândim la folosit
termeni de servere și gazde.

2444
01:48:14,270 --> 01:48:16,580
Nu e vorba de asta mai.

2445
01:48:16,580 --> 01:48:19,310
Este vorba despre infrastructură drept cod.

2446
01:48:19,310 --> 01:48:22,470
Implementați codul de nor și
lasa norul rula pentru tine.

2447
01:48:22,470 --> 01:48:24,980
Și asta e ceea ce AWS încearcă să facă.

2448
01:48:24,980 --> 01:48:29,690
>> Audiența: Deci, cutia de aur în mijloc
de API Gateway nu este-server cum ar fi,

2449
01:48:29,690 --> 01:48:30,576
ci este doar--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Puteți să vă gândiți
va ca fațadă de server.

2451
01:48:32,850 --> 01:48:38,040
Tot ce este este că va lua o HTTP
solicite și harta-l la un alt proces.

2452
01:48:38,040 --> 01:48:39,192
Asta e tot ce face.

2453
01:48:39,192 --> 01:48:41,525
Și în acest caz, ne cartografiere
l la o funcție Lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Bine, asta-i tot ce am.

2456
01:48:45,410 --> 01:48:46,190
Mulțumesc foarte mult.

2457
01:48:46,190 --> 01:48:46,800
Apreciez asta.

2458
01:48:46,800 --> 01:48:48,100
Știu că ne dorim un pic în timp.

2459
01:48:48,100 --> 01:48:49,980
Și, sperăm, voi primit
un pic de informații

2460
01:48:49,980 --> 01:48:51,410
pe care le poate lua astăzi.

2461
01:48:51,410 --> 01:48:53,520
Și îmi cer scuze dacă m-am dus
peste unele dintre capetele voastre,

2462
01:48:53,520 --> 01:48:56,697
dar există o mulțime de bun
cunoștințe fundamentale fundamentale

2463
01:48:56,697 --> 01:48:58,280
care cred că este foarte valoros pentru tine.

2464
01:48:58,280 --> 01:48:59,825
Deci, vă mulțumesc pentru că m-.

2465
01:48:59,825 --> 01:49:00,325
[APLAUZE]

2466
01:49:00,325 --> 01:49:02,619
Audiența: [inaudibil]
este atunci când spuneai

2467
01:49:02,619 --> 01:49:05,160
trebuia să treacă prin lucru
de la început până la sfârșit

2468
01:49:05,160 --> 01:49:07,619
pentru a obține valorile corecte
sau aceleași valori,

2469
01:49:07,619 --> 01:49:09,410
cum ar fi valorile
schimba dacă [neauzit].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Cum s-ar schimba valorile?

2472
01:49:11,800 --> 01:49:15,180
Ei bine, pentru că dacă nu am alerga
tot drumul până la sfârșit,

2473
01:49:15,180 --> 01:49:19,770
atunci nu știu ce schimbări
au fost făcute în ultima milă.

2474
01:49:19,770 --> 01:49:22,144
Nu va să fie
aceleași date ca ceea ce am vazut.

2475
01:49:22,144 --> 01:49:24,560
Audiența: Oh, astfel încât să doar
nu au ajuns întreaga intrare.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: dreapta.

2477
01:49:24,770 --> 01:49:26,895
Trebuie să mergi la început
la final, iar apoi este

2478
01:49:26,895 --> 01:49:29,280
Va fi o stare consistentă.

2479
01:49:29,280 --> 01:49:31,520
Misto.

2480
01:49:31,520 --> 01:49:35,907
>> Audiența: Deci ne-a arătat DynamoDB
poate face document sau valoarea cheii.

2481
01:49:35,907 --> 01:49:38,740
Și am petrecut o mulțime de timp pe
valoare-cheie cu un hash și modalitățile

2482
01:49:38,740 --> 01:49:40,005
a flip în jurul.

2483
01:49:40,005 --> 01:49:43,255
Când te-ai uitat la aceste tabele, este că
lăsând în urmă abordarea de documente?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: I nu ar fi
lăsându-l în urmă spun.

2485
01:49:44,600 --> 01:49:45,855
>> Audiența: Ei s-au separat de the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Cu documentul
abordare, tipul documentului în DynamoDB

2487
01:49:49,140 --> 01:49:50,880
este doar cred că de ca un alt atribut.

2488
01:49:50,880 --> 01:49:53,560
Este un atribut care conține
o structură de date ierarhică.

2489
01:49:53,560 --> 01:49:56,980
Și apoi în interogări,
puteți utiliza proprietățile

2490
01:49:56,980 --> 01:49:59,480
dintre aceste obiecte folosind Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Deci, eu pot filtra pe un imbricate
proprietate a documentului JSON.

2492
01:50:03,562 --> 01:50:05,520
Audiența: Deci, orice moment am
face o abordare de document,

2493
01:50:05,520 --> 01:50:07,906
Pot fel ajunge la tabular--

2494
01:50:07,906 --> 01:50:08,780
Audiența: Absolut.

2495
01:50:08,780 --> 01:50:09,800
Audiența: --indexes și
lucruri pe care tocmai ați vorbit.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: da,
indici și tot ce,

2497
01:50:11,280 --> 01:50:13,363
atunci când doriți să indexeze
proprietăți ale JSON,

2498
01:50:13,363 --> 01:50:18,230
modul în care vom avea de a face asta este dacă
introduceți un obiect JSON sau un document

2499
01:50:18,230 --> 01:50:20,780
în Dynamo, ar trebui să utilizați fluxuri.

2500
01:50:20,780 --> 01:50:22,400
Fluxuri ar citi de intrare.

2501
01:50:22,400 --> 01:50:24,340
Te-ai obține că JSON
opoziție și ai spune OK,

2502
01:50:24,340 --> 01:50:26,030
ceea ce este proprietatea vreau să indice?

2503
01:50:26,030 --> 01:50:28,717
>> Puteți crea un tabel derivat.

2504
01:50:28,717 --> 01:50:30,300
Acum, că e modul în care funcționează acum.

2505
01:50:30,300 --> 01:50:32,650
Noi nu vă permit să indice
direct acele proprietăți.

2506
01:50:32,650 --> 01:50:33,520
>> Audiența: Tabularizing documente.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Exact, aplatizare
ea, tabularizing, exact.

2508
01:50:36,230 --> 01:50:37,415
Asta e ceea ce faci cu ea.

2509
01:50:37,415 --> 01:50:37,860
>> Audiența: Mulțumesc.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Da,
absolut, vă mulțumesc.

2511
01:50:39,609 --> 01:50:42,240
Audiența: Deci e un fel de
Mongo întâlnește classifers Redis.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Da,
e mult de genul asta.

2513
01:50:43,990 --> 01:50:45,940
Asta-i o descriere bună pentru el.

2514
01:50:45,940 --> 01:50:47,490
Misto.

2515
01:50:47,490 --> 01:50:49,102