1
00:00:00,000 --> 00:00:04,969
>> [MUZIKO Ludante]

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

3
00:00:06,010 --> 00:00:06,600
Saluton, ĉiuj.

4
00:00:06,600 --> 00:00:07,670
Mia nomo estas Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Mi estas altranga rektoro
solvoj arkitekto ĉe AWS.

6
00:00:10,330 --> 00:00:14,070
Mi enfokusigi NoSQL kaj
DynamoDB teknologioj.

7
00:00:14,070 --> 00:00:16,930
Mi estas ĉi tie hodiaŭ por paroli al
vi iomete pri tiuj.

8
00:00:16,930 --> 00:00:18,970
>> Mia fono estas
unuavice en datumoj tavolo.

9
00:00:18,970 --> 00:00:21,390
Mi pasigis duonon mia disvolviĝo
kariero skribanta datumbazo,

10
00:00:21,390 --> 00:00:25,930
datumoj aliro, solvoj
por diversaj aplikoj.

11
00:00:25,930 --> 00:00:30,000
Mi estis en Cloud virtualización
por proksimume 20 jaroj.

12
00:00:30,000 --> 00:00:33,460
Do antaŭ la Nubo estis la Nubo,
ni nomis ŝin utileco komputado.

13
00:00:33,460 --> 00:00:37,170
Kaj la ideo, estas kiel
PG & E, vi pagos por kio vi uzas.

14
00:00:37,170 --> 00:00:38,800
Hodiaŭ ni nomas ĝin la nubo.

15
00:00:38,800 --> 00:00:41,239
>> Sed tra la jaroj, mi laboris
por paro de firmaoj

16
00:00:41,239 --> 00:00:42,530
vi probable neniam aŭdis.

17
00:00:42,530 --> 00:00:47,470
Sed Mi kompilis liston de teknika
plenumoj, mi supozas ke vi volas diri.

18
00:00:47,470 --> 00:00:51,620
Mi havas ok patentojn en Cloud sistemoj
virtualización, mikroprocesoro dezajno,

19
00:00:51,620 --> 00:00:54,440
kompleksa okazaĵo prilaborado,
kaj aliaj areoj ankaŭ.

20
00:00:54,440 --> 00:00:58,290
>> Do tiuj tagoj, Mi enfokusigi plejparte sur NoSQL
teknologioj kaj la sekva generacio

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

22
00:00:59,450 --> 00:01:03,370
Kaj tio estas ĝenerale kion mi tuj
esti tie parolante al vi hodiaŭ pri.

23
00:01:03,370 --> 00:01:06,030
Do kion vi povas atendi
de tiu kunsido,

24
00:01:06,030 --> 00:01:08,254
ni iros tra mallonga
historio de datumtraktado.

25
00:01:08,254 --> 00:01:10,420
Ĉiam helpema por
kompreni de kie ni venis

26
00:01:10,420 --> 00:01:12,400
kaj kial ni estas, kie ni estas.

27
00:01:12,400 --> 00:01:15,600
Kaj ni parolos iom
bita pri NoSQL teknologio

28
00:01:15,600 --> 00:01:17,500
de fundamenta starpunkto.

29
00:01:17,500 --> 00:01:19,870
>> Ni akiros en kelkaj
la DynamoDB internals.

30
00:01:19,870 --> 00:01:24,350
DynamoDB estas AWS estas neniu gusto.

31
00:01:24,350 --> 00:01:27,340
Ĝi estas plene sukcesis kaj
gastigita NoSQL solvo.

32
00:01:27,340 --> 00:01:32,420
Kaj ni parolos iomete pri tablo
strukturo, APIs, datumtipoj, indeksoj,

33
00:01:32,420 --> 00:01:35,177
kaj iu el la internals
de tiu DynamoDB teknologio.

34
00:01:35,177 --> 00:01:37,760
Ni enir iuj de la dezajno
ŝablonoj kaj bonaj praktikoj.

35
00:01:37,760 --> 00:01:39,968
Ni parolos pri kiel vi
uzi tiun teknologion por kelkaj

36
00:01:39,968 --> 00:01:41,430
de hodiaŭa aplikoj.

37
00:01:41,430 --> 00:01:44,820
Kaj tiam ni parolos iomete
pri la evoluado aŭ la apero

38
00:01:44,820 --> 00:01:48,980
de nova paradigmo en programado
nomita okazaĵo tirataj aplikoj

39
00:01:48,980 --> 00:01:51,580
kaj kiel DynamoDB ludas en tiu tiel.

40
00:01:51,580 --> 00:01:54,690
Kaj ni lasos vin iomete de
referenco arkitekturo diskuto

41
00:01:54,690 --> 00:01:59,540
tiel ni povos paroli pri kelkaj el
la manieroj vi povas uzi DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Do unue off-- tiu estas demando
Mi aŭdas multon estas, kio estas datumbazo.

43
00:02:04,116 --> 00:02:06,240
Multaj homoj kredas, ke ili
scias kion datumbazo estas.

44
00:02:06,240 --> 00:02:08,360
Se vi Google, vi vidos tion.

45
00:02:08,360 --> 00:02:11,675
Ĝi estas strukturita aro de datumoj tenis
en komputilo, speciale unu kiu

46
00:02:11,675 --> 00:02:13,600
estas alirebla en diversaj manieroj.

47
00:02:13,600 --> 00:02:16,992
Mi supozas ke estas bona
difino de moderna datumbazo.

48
00:02:16,992 --> 00:02:19,450
Sed mi ne ŝatas ŝin, ĉar
ĝi implicas kelkajn aferojn.

49
00:02:19,450 --> 00:02:20,935
Ĝi implicas strukturo.

50
00:02:20,935 --> 00:02:23,120
Kaj ĝi implicas ke ĝi estas en komputilo.

51
00:02:23,120 --> 00:02:25,750
Kaj datumbazoj ne
Ĉiam ekzistas sur komputiloj.

52
00:02:25,750 --> 00:02:28,020
Datumbazoj reale ekzistis en multaj manieroj.

53
00:02:28,020 --> 00:02:32,000
>> Do pli bona difino de
datumbazo estas io tiamaniere.

54
00:02:32,000 --> 00:02:34,786
Al datumbazo estas organizita
mekanismo por stoki, administri,

55
00:02:34,786 --> 00:02:35,910
kaj prenado informojn.

56
00:02:35,910 --> 00:02:36,868
Tiu estas de About.com.

57
00:02:36,868 --> 00:02:42,080
Do mi ŝatas tiun ĉar ĝi vere prelegoj
pri datumbazo estanta dosieraro,

58
00:02:42,080 --> 00:02:44,800
deponejo de
informoj, ne nepre

59
00:02:44,800 --> 00:02:46,780
io kiu sidas sur komputilo.

60
00:02:46,780 --> 00:02:49,290
Kaj dum historio, ni
ne ĉiam havis komputilojn.

61
00:02:49,290 --> 00:02:52,110
>> Nun, se mi petos la mezumo
desarrollador hodiaŭ kio estas

62
00:02:52,110 --> 00:02:54,770
datumbazo, jen la respondo mi akiras.

63
00:02:54,770 --> 00:02:56,070
Ie mi povas meti aĵojn.

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

65
00:02:56,670 --> 00:02:58,725
Kaj estas vera.

66
00:02:58,725 --> 00:02:59,600
Sed estas malfeliĉa.

67
00:02:59,600 --> 00:03:02,700
Ĉar la datumbazo estas vere
la fondo de la moderna app.

68
00:03:02,700 --> 00:03:04,810
Estas la fundamento
de ĉiu apliko.

69
00:03:04,810 --> 00:03:07,240
Kaj kiel vi konstruu ke
datenbazo, kiom vi strukturi

70
00:03:07,240 --> 00:03:11,750
ke datumoj tuj diktas ke
apliko rezultas kiel vi grimpi.

71
00:03:11,750 --> 00:03:14,640
>> Do multe da mia laboro hodiaŭ
pritraktas kio

72
00:03:14,640 --> 00:03:17,180
okazas kiam programistoj
prenu ĉi alproksimiĝo

73
00:03:17,180 --> 00:03:19,510
kaj traktanta la sekvo
de apliko kiu

74
00:03:19,510 --> 00:03:24,966
nun grimpante preter la originala
intenco kaj suferado de malbona dezajno.

75
00:03:24,966 --> 00:03:26,840
Do espereble kiam vi
marŝi for hodiaŭ, vi

76
00:03:26,840 --> 00:03:29,010
havas paron de iloj en
via zono kiu tenos vin

77
00:03:29,010 --> 00:03:32,566
el farante tiujn samajn erarojn.

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

79
00:03:33,066 --> 00:03:36,360
Do ni parolu pri iomete da
la timeline de datumbazo teknologio.

80
00:03:36,360 --> 00:03:38,830
Mi kredas ke mi legis
artikolo ne ke antaŭlonge

81
00:03:38,830 --> 00:03:43,020
kaj ĝi diris iun ĉi lines--
ĝi estas tre poezia komunikaĵo.

82
00:03:43,020 --> 00:03:46,590
Ĝi diris la historio
de datumtraktado estas

83
00:03:46,590 --> 00:03:49,350
plena de alta filigranoj
de datumoj abundo.

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

85
00:03:49,920 --> 00:03:52,532
Nun, mi supozas ke estas speco de vera.

86
00:03:52,532 --> 00:03:54,990
Sed mi vere rigardi kiel
la historio estas vere plenigis

87
00:03:54,990 --> 00:03:56,820
kun alta filigrano de datumoj premo.

88
00:03:56,820 --> 00:04:00,040
Ĉar la datumoj imposto de
ingestión neniam iras malsupren.

89
00:04:00,040 --> 00:04:01,360
Ĝi nur iras supren.

90
00:04:01,360 --> 00:04:03,670
>> Kaj novigado okazas kiam
ni vidas datumoj premo, kio

91
00:04:03,670 --> 00:04:07,825
estas la kvanto de datumoj kiuj estas
nun en venanta en la sistemo.

92
00:04:07,825 --> 00:04:12,027
Kaj ĝi ne povas procesi
kompetente ĉu en tempo aŭ en kosto.

93
00:04:12,027 --> 00:04:14,110
Kaj tio estas kiam ni komencas
rigardi datumoj premo.

94
00:04:14,110 --> 00:04:15,920
>> Do kiam ni rigardas la
unua datumbazon, ĉi

95
00:04:15,920 --> 00:04:17,180
Estas kiu estis inter niaj oreloj.

96
00:04:17,180 --> 00:04:18,310
Ni ĉiuj naskiĝis kun ĝi.

97
00:04:18,310 --> 00:04:19,194
Ĝi estas bela datumbazo.

98
00:04:19,194 --> 00:04:21,110
Ĝi havas altan haveblecon.

99
00:04:21,110 --> 00:04:21,959
Ĝi estas ĉiam sur.

100
00:04:21,959 --> 00:04:23,930
Vi povas ĉiam atingi ĝin.

101
00:04:23,930 --> 00:04:24,890
>> Sed estas sola uzanto.

102
00:04:24,890 --> 00:04:26,348
Mi ne povas dividi miajn pensojn kun vi.

103
00:04:26,348 --> 00:04:28,370
Vi ne povas akiri mian pensoj
kiam vi volas ilin.

104
00:04:28,370 --> 00:04:30,320
Iliaj abilitiy estas ne tiel bona.

105
00:04:30,320 --> 00:04:32,510
Ni forgesas aĵojn.

106
00:04:32,510 --> 00:04:36,540
Ĉiu nun kaj tiam, unu el ni folioj
kaj pluiras al alia ekzisto

107
00:04:36,540 --> 00:04:39,110
kaj ni perdas ĉiun
kiu estis en tiu datumbazo.

108
00:04:39,110 --> 00:04:40,640
Do tio ne estas ĉiu tiu bono.

109
00:04:40,640 --> 00:04:43,189
>> Kaj ĉi funkciis bone super tempo
kiam ni estis reen en la tago

110
00:04:43,189 --> 00:04:46,230
kiam ĉiuj ni vere bezonis scii estas
kie ni tuj iru morgaŭ

111
00:04:46,230 --> 00:04:49,630
aŭ kie ni kolektos la plej bonan manĝon.

112
00:04:49,630 --> 00:04:52,820
Sed kiel ni komencis kreski kiel
civilizacio kaj registaro komenciĝis

113
00:04:52,820 --> 00:04:55,152
veni en estaĵo, kaj
komercoj komencis evolui,

114
00:04:55,152 --> 00:04:57,360
ni komencis rimarki nin
bezonas iom pli ol kio

115
00:04:57,360 --> 00:04:58,210
Ni povus meti en nia kapo.

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

117
00:04:58,870 --> 00:05:00,410
>> Ni bezonis sistemoj de rekordo.

118
00:05:00,410 --> 00:05:02,220
Ni bezonis lokojn por povi stoki datumojn.

119
00:05:02,220 --> 00:05:05,450
Do ni komencis verki dokumentojn,
kreanta bibliotekoj kaj arkivoj.

120
00:05:05,450 --> 00:05:08,000
Ni komencis evoluiganta
sistemo libro librotenisto librotenado.

121
00:05:08,000 --> 00:05:12,200
Kaj ke sistemo de Ledger kalkula
kuris la mondo dum multaj jarcentoj,

122
00:05:12,200 --> 00:05:15,580
kaj eble eĉ jarmiloj kiel
ni ia kreskis al la punkto

123
00:05:15,580 --> 00:05:18,420
kie tiu datumo ŝarĝo superis
la kapablo de tiuj sistemoj

124
00:05:18,420 --> 00:05:19,870
povi enhavi ĝin.

125
00:05:19,870 --> 00:05:22,070
>> Kaj tio fakte okazis en la 1880s.

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

127
00:05:22,570 --> 00:05:24,390
En la 1880 Censo.

128
00:05:24,390 --> 00:05:26,976
Tiu estas vere kie la turniĝo
atentigi moderna datumtraktado.

129
00:05:26,976 --> 00:05:28,850
Tio estas la punkto je
kiu la kvanto de datumoj

130
00:05:28,850 --> 00:05:32,060
kiu estis kolektita de la
Usona registaro alvenis al la punkto

131
00:05:32,060 --> 00:05:34,005
kie prenis ok jaroj procesi.

132
00:05:34,005 --> 00:05:36,350
>> Nun, ok years-- kiel
vi scias, la censo

133
00:05:36,350 --> 00:05:39,180
kuroj ĉiun 10 years-- tiel ĝi estas
sufiĉe preterlasas ke de tempo ni

134
00:05:39,180 --> 00:05:41,419
ekhavis la 1890 kontado,
la kvanton de datumoj kiuj

135
00:05:41,419 --> 00:05:43,210
tuj estos procesitaj
per registaro estis

136
00:05:43,210 --> 00:05:46,335
tuj superos la 10 jaroj kiujn ĝi
prenus al ĵetis la nova censo.

137
00:05:46,335 --> 00:05:47,250
Tiu estis problemo.

138
00:05:47,250 --> 00:05:49,000
>> Do ulo nomis Herman
Hollerith venis kune

139
00:05:49,000 --> 00:05:52,640
kaj li inventis unuo rekordo stampilon
kartoj, stampilon karto leganto, stampilon karto

140
00:05:52,640 --> 00:05:58,420
tabulador kaj la colación de
la mekanismoj por ĉi tiu teknologio.

141
00:05:58,420 --> 00:06:01,860
Kaj ke firmao kiu formis en la
tempo, kune kun paro de aliaj,

142
00:06:01,860 --> 00:06:05,450
fakte iĝis unu el la kolonoj de
Malgranda entrepreno ni scias hodiaŭ nomita IBM.

143
00:06:05,450 --> 00:06:08,417
>> Do IBM origine estis en
datumbazaj negoco.

144
00:06:08,417 --> 00:06:09,750
Kaj tio estas vere kion ili faris.

145
00:06:09,750 --> 00:06:11,110
Ili faris datumtraktado.

146
00:06:11,110 --> 00:06:15,400
>> Kiel do la proliferación de punĉo
kartoj, sprita meĥanismoj

147
00:06:15,400 --> 00:06:18,560
de povi utiligi ke
teknologio por razu ordo rezulto aroj.

148
00:06:18,560 --> 00:06:20,726
Vi povas vidi en ĉi tiu bildo
tie ni havas little--

149
00:06:20,726 --> 00:06:23,970
ĝi estas iom small-- sed vi povas vidi
tre sprita mekanika mekanismo

150
00:06:23,970 --> 00:06:26,970
kie ni havas stampilon karto ferdeko.

151
00:06:26,970 --> 00:06:28,720
Kaj ies preno
iom destornillador

152
00:06:28,720 --> 00:06:31,400
kaj batante per la
fendoj kaj levante ĝin

153
00:06:31,400 --> 00:06:34,820
bonstata turniro, kiu
ordo rezultoj starigis.

154
00:06:34,820 --> 00:06:36,270
>> Tiu estas agregaĵo.

155
00:06:36,270 --> 00:06:38,690
Ni faru tion tutan tempon
hodiaŭ en la komputilo,

156
00:06:38,690 --> 00:06:40,100
kie vi faras ĝin en la datumbazo.

157
00:06:40,100 --> 00:06:41,620
Ni kutimis fari ĝin manualmente, dekstra?

158
00:06:41,620 --> 00:06:42,994
Homoj metis tion kune.

159
00:06:42,994 --> 00:06:45,440
Kaj estis la proliferado
de tiuj kartoj boritaj

160
00:06:45,440 --> 00:06:50,070
en kion ni vokis datumoj tamburojn
kaj datumo bobenoj, papero bendo.

161
00:06:50,070 --> 00:06:55,980
>> La datumtraktado industrio prenis
lecionon de la ludanto pianoj.

162
00:06:55,980 --> 00:06:57,855
Ludanto pianoj reen ĉe
la jarcentŝanĝo

163
00:06:57,855 --> 00:07:02,100
kutimis uzi paperon bobenoj kun fendoj
sur sciigi kio klavoj ludi.

164
00:07:02,100 --> 00:07:05,380
Por ke teknologio estis adaptita
eventuale enteni ciferecaj datumoj,

165
00:07:05,380 --> 00:07:08,070
ĉar ili povus enkalkulu datumoj
sur tiuj papero bendo bobenoj.

166
00:07:08,070 --> 00:07:10,870
>> Nun, kiel rezulto, datumoj
estis actually-- kiom

167
00:07:10,870 --> 00:07:14,960
vi aliri ĉi datumoj estis rekte
dependa sur kiel vi stokas ĝin.

168
00:07:14,960 --> 00:07:17,825
Do se mi metas la datumojn sur bendo,
Mi devis aliri la datumojn lineare.

169
00:07:17,825 --> 00:07:20,475
Mi devas ruli la tuta
bendo aliri ĉiujn datumojn.

170
00:07:20,475 --> 00:07:22,600
Se mi metas la datumojn en stampilon
kartojn, mi povis aliri ĝin

171
00:07:22,600 --> 00:07:26,270
en iom pli hazarda
modo, eble ne tiel rapide.

172
00:07:26,270 --> 00:07:30,770
>> Sed estis limigoj en kiel ni
aliro al datumoj bazita sur kiel estis stokita.

173
00:07:30,770 --> 00:07:32,890
Kaj tiel tio estis problemo
iro en la '50s.

174
00:07:32,890 --> 00:07:37,890
Denove, ni povas komenci al vidi ke ni
disvolvi novajn teknologiojn procesi

175
00:07:37,890 --> 00:07:41,670
la datumoj, dekstra, tio malfermas
la pordo por novaj solvoj,

176
00:07:41,670 --> 00:07:45,852
por novaj programoj, nova
aplikoj por kiuj datumoj.

177
00:07:45,852 --> 00:07:47,810
Kaj vere, gobernanza
eble estis la kialo

178
00:07:47,810 --> 00:07:49,435
kial ni disvolvis kelkajn el tiuj sistemoj.

179
00:07:49,435 --> 00:07:52,290
Sed negocon rapide iĝis
la ŝoforo malantaŭ la evoluado

180
00:07:52,290 --> 00:07:54,720
de la moderna datumbazo kaj
la moderna sistemo de arkivoj.

181
00:07:54,720 --> 00:07:56,870
>> Do la sekvanta afero ke
venis estis en la 50'oj

182
00:07:56,870 --> 00:08:00,780
estis la dosiersistemo kaj la
disvolviĝo de aliro aleatorio stokado.

183
00:08:00,780 --> 00:08:02,050
Tio estis bela.

184
00:08:02,050 --> 00:08:06,230
Nun, ĉiuj de subita, ni povas meti niajn
fajlilo ie sur tiuj malmolaj diskoj

185
00:08:06,230 --> 00:08:09,760
kaj ni povas aliri ĉi datumoj hazarde.

186
00:08:09,760 --> 00:08:11,950
Ni povas analizi ke
informo el dosierojn.

187
00:08:11,950 --> 00:08:14,920
Kaj ni solvis ĉiujn mondo
problemoj kun datumtraktado.

188
00:08:14,920 --> 00:08:17,550
>> Kaj kiu daŭris ĉirkaŭ 20 aŭ
30 jarojn ĝis la evoluado

189
00:08:17,550 --> 00:08:22,100
de la rilata datumbazo, kiu
Estas kiam la mondo decidis nin nun

190
00:08:22,100 --> 00:08:27,940
bezonas havi dosieraro kiu malvenko
la aglomeración de datumoj trans la dosiero

191
00:08:27,940 --> 00:08:29,540
sistemoj kiuj ni konstruis. Dekstra?

192
00:08:29,540 --> 00:08:34,270
Tro multe datumoj distribuita en tro multaj
lokoj, la de-duobligo de datumoj,

193
00:08:34,270 --> 00:08:37,120
kaj la koston de stokado estis enorma.

194
00:08:37,120 --> 00:08:43,760
>> En la 70'oj, la plej multekosta rimedo
ke komputilo havis estis la stokado.

195
00:08:43,760 --> 00:08:46,200
La procesoro estis
rigardita kiel fiksa kosto.

196
00:08:46,200 --> 00:08:49,030
Kiam mi aĉetas la skatolo,
la CPU faras iun laboron.

197
00:08:49,030 --> 00:08:51,960
Ĝi tuj estos turnadanta ĉu
ĝi estas vere laboranta aŭ ne.

198
00:08:51,960 --> 00:08:53,350
Tio estas vere enprofundigita kosto.

199
00:08:53,350 --> 00:08:56,030
>> Sed kion kostis min kiel
negoco estas stokado.

200
00:08:56,030 --> 00:09:00,020
Se mi devos aĉeti pli diskoj apud
monato, tio estas vera kosto kiu mi pagis.

201
00:09:00,020 --> 00:09:01,620
Kaj ke stokado estas multekosta.

202
00:09:01,620 --> 00:09:05,020
>> Nun ni rapide antaŭen 40 jaroj
kaj ni havas alian problemon.

203
00:09:05,020 --> 00:09:10,020
La komputi estas nun la
plej altekosta rimedo.

204
00:09:10,020 --> 00:09:11,470
La stokado estas malmultekosta.

205
00:09:11,470 --> 00:09:14,570
Mi volas diri, ni povas iri ie ajn sur la
nubo kaj ni povos trovi malmultekostan stokado.

206
00:09:14,570 --> 00:09:17,190
Sed kion mi povas ne trovi estas malmultekosta komputi.

207
00:09:17,190 --> 00:09:20,700
>> Do la evoluo de la hodiaŭa
teknologio, de datumbazo teknologio,

208
00:09:20,700 --> 00:09:23,050
Estas vere koncentrita ĉirkaŭ
distribuita datumbazoj

209
00:09:23,050 --> 00:09:26,960
ke ne suferas de
la sama tipo de skalo

210
00:09:26,960 --> 00:09:29,240
limigoj de interrilataj datumaroj.

211
00:09:29,240 --> 00:09:32,080
Ni parolos iomete pri
kion tio vere signifas.

212
00:09:32,080 --> 00:09:34,760
>> Sed unu el la kialoj kaj
la ŝoforo malantaŭ this-- ni

213
00:09:34,760 --> 00:09:38,290
parolis pri la datumoj premo.

214
00:09:38,290 --> 00:09:41,920
Datumoj premo estas io
kiu pelas la novigon.

215
00:09:41,920 --> 00:09:44,610
Kaj se vi rigardas super
la lastaj kvin jaroj,

216
00:09:44,610 --> 00:09:48,180
tiu estas abako de kio la datumoj
ŝarĝo trans la ĝenerala entrepreno

217
00:09:48,180 --> 00:09:49,640
aspektas kiel en la lastaj kvin jaroj.

218
00:09:49,640 --> 00:09:52,570
>> Kaj la ĝenerala regulo de dikfingro
tiuj days-- se vi iros Google--

219
00:09:52,570 --> 00:09:55,290
estas 90% de la datumoj kiuj
ni stoki hodiaŭ, kaj ĝi estis

220
00:09:55,290 --> 00:09:57,330
generita ene de la lastaj du jaroj.

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

222
00:09:57,911 --> 00:09:59,410
Nun, ĉi tio ne estas tendenco kiu novas.

223
00:09:59,410 --> 00:10:01,230
Tio estas tendenco kiu estas estita
eliros por 100 jaroj.

224
00:10:01,230 --> 00:10:03,438
Ekde Herman Hollerith
evoluigis la stampilon karto,

225
00:10:03,438 --> 00:10:08,040
ni estis konstruado datumoj deponejoj
kaj kolektanta datumon ĉe fenomena impostoj.

226
00:10:08,040 --> 00:10:10,570
>> Do dum la lastaj 100 jaroj,
ni vidis ĉi tiun tendencon.

227
00:10:10,570 --> 00:10:11,940
Tio ne tuj ŝanĝos.

228
00:10:11,940 --> 00:10:14,789
Irante antaŭen, ni tuj vidos
tiu, se ne akcelita tendenco.

229
00:10:14,789 --> 00:10:16,330
Kaj vi povas vidi kion tio aspektas.

230
00:10:16,330 --> 00:10:23,510
>> Se negoco en 2010 havis unu
terabajto de datumoj sub direktado,

231
00:10:23,510 --> 00:10:27,080
hodiaŭ tiu signifas ke ili estas
administri 6.5 petabytes de datumoj.

232
00:10:27,080 --> 00:10:30,380
Tio 6.500 fojoj pli datumoj.

233
00:10:30,380 --> 00:10:31,200
Kaj mi scias tion.

234
00:10:31,200 --> 00:10:33,292
Mi laboras kun tiuj komercoj ĉiutage.

235
00:10:33,292 --> 00:10:35,000
Antaŭ kvin jaroj, mi
parolus al entreprenoj

236
00:10:35,000 --> 00:10:38,260
kiu parolus al mi pri kia doloro
ĝi estas gestionar terabajtoj de datumoj.

237
00:10:38,260 --> 00:10:39,700
Kaj ili parolus
al mi pri kiamaniere ni vidas

238
00:10:39,700 --> 00:10:41,825
ke tiu estas probable tuj
esti petabyte aŭ du

239
00:10:41,825 --> 00:10:43,030
ene de paro de jaroj.

240
00:10:43,030 --> 00:10:45,170
>> Tiuj samaj entreprenoj
hodiaŭ mi renkontis kun,

241
00:10:45,170 --> 00:10:48,100
kaj ili parolas al mi pri la
problemo estas ne havi perantino

242
00:10:48,100 --> 00:10:51,440
dekoj, 20 petabytes de datumoj.

243
00:10:51,440 --> 00:10:53,590
Do la eksplodo de la
datumoj en la industrio

244
00:10:53,590 --> 00:10:56,670
forpelas la enorma
bezonas por bona solvoj.

245
00:10:56,670 --> 00:11:00,980
Kaj la rilata datumbazo estas
nur ne vivas ĝis la peto.

246
00:11:00,980 --> 00:11:03,490
>> Kaj do tie estas lineara
korelacion inter datumoj premo

247
00:11:03,490 --> 00:11:05,210
kaj teknika novigo.

248
00:11:05,210 --> 00:11:07,780
Historio montris al ni
tiu, kiu super tempo,

249
00:11:07,780 --> 00:11:11,090
kiam la volumo de datumoj
kiu devas esti procesitaj

250
00:11:11,090 --> 00:11:15,490
superas la kapaciton de la sistemo
procesi ĝin en akceptebla tempo

251
00:11:15,490 --> 00:11:18,870
aŭ ĉe akceptebla kosto,
tiam novaj teknologioj

252
00:11:18,870 --> 00:11:21,080
estas elpensita por solvi tiujn problemojn.

253
00:11:21,080 --> 00:11:24,090
Tiuj novaj teknologioj,
siavice, malfermu la pordon

254
00:11:24,090 --> 00:11:27,840
al alia aro de problemoj, kiujn
kolektas eĉ pli datumoj.

255
00:11:27,840 --> 00:11:29,520
>> Nun, ni ne tuj halti ĉi.

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

257
00:11:30,020 --> 00:11:31,228
Ni ne tuj halti ĉi.

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

259
00:11:31,830 --> 00:11:35,520
Ĉar vi ne povas scii ĉion
oni devas scii en la universo.

260
00:11:35,520 --> 00:11:40,510
Kaj kiel longe kiel ni vivus,
tra la homa historio,

261
00:11:40,510 --> 00:11:43,440
ni ĉiam pelataj scii pli.

262
00:11:43,440 --> 00:11:49,840
>> Do ŝajnas kiel ĉiu colo ni movas
malsupren la vojo de scienca malkovro,

263
00:11:49,840 --> 00:11:54,620
ni multiplikante la kvanto de datumoj
ke ni devas prilabori eksponente

264
00:11:54,620 --> 00:11:59,920
kiel ni malkovros pli kaj pli kaj pli
pri la interna funkciado de vivo,

265
00:11:59,920 --> 00:12:04,530
pri kiel la universo funkcias, pri
manipulante la scienca malkovro,

266
00:12:04,530 --> 00:12:06,440
kaj la inventado kiu
ni faras hodiaŭ.

267
00:12:06,440 --> 00:12:09,570
La volumo de datumoj nur
senĉese pliigas.

268
00:12:09,570 --> 00:12:12,120
Do povante trakti
tiu problemo estas enorma.

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

270
00:12:14,790 --> 00:12:17,410
>> Do unu el la aĵoj
ni rigardas kiel kial NoSQL?

271
00:12:17,410 --> 00:12:19,200
Kiel NoSQL solvi tiun problemon?

272
00:12:19,200 --> 00:12:24,980
Nu, rilata datumbazoj,
Strukturita Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- ke estas vere konstrukcio de la
interrilata database-- tiuj aferoj estas

274
00:12:28,600 --> 00:12:30,770
optimumigita por stokado.

275
00:12:30,770 --> 00:12:33,180
>> Reen en la 70'oj, denove,
disko estas multekosta.

276
00:12:33,180 --> 00:12:36,990
La provizoj ekzerco de stokado
en la entrepreno estas senfina.

277
00:12:36,990 --> 00:12:37,490
Mi scias.

278
00:12:37,490 --> 00:12:38,020
Mi vivis ĝin.

279
00:12:38,020 --> 00:12:41,250
Mi skribis stokado ŝoforoj por
enterprised superserver entrepreno

280
00:12:41,250 --> 00:12:42,470
reen en la '90aj jaroj.

281
00:12:42,470 --> 00:12:45,920
Kaj la malsupra linio estas trasercxante alian
stokado tabelo estis nur iu kiu

282
00:12:45,920 --> 00:12:47,600
okazis ĉiutage en la entrepreno.

283
00:12:47,600 --> 00:12:49,030
Kaj neniam haltis.

284
00:12:49,030 --> 00:12:52,690
Granda denseco de stokado, peto
por alta denseca stokado,

285
00:12:52,690 --> 00:12:56,340
kaj por pli efika stokado
devices-- ĝi neniam ĉesis.

286
00:12:56,340 --> 00:13:00,160
>> Kaj NoSQL estas granda teknologio
ĉar ĝi normaligas la datumoj.

287
00:13:00,160 --> 00:13:02,210
Ĝi de-duobligas la datumoj.

288
00:13:02,210 --> 00:13:07,180
Ĝi metas la datumoj en strukturo kiu
estas agnostikulo al ĉiu aliro ŝablono.

289
00:13:07,180 --> 00:13:11,600
Multoblaj aplikoj povas kolizii ke
SQL datumbazo, kuras ad hoc pridemandojn,

290
00:13:11,600 --> 00:13:15,950
kaj akiri datumojn en la formo ke ili
devas prilabori por sia laborŝarĝoj.

291
00:13:15,950 --> 00:13:17,570
Tio sonas fantazia.

292
00:13:17,570 --> 00:13:21,350
Sed la malsupra linio estas kun ajna
sistemo, se ĝi estas agnostikulo al ĉio,

293
00:13:21,350 --> 00:13:23,500
ĝi estas optimumigita por nenio.

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

295
00:13:24,050 --> 00:13:26,386
>> Kaj tio estas kion ni ricevas per
la rilata datumbazo.

296
00:13:26,386 --> 00:13:27,510
Ĝi estas optimumigita por stokado.

297
00:13:27,510 --> 00:13:28,280
Ĝi estas ununormigita.

298
00:13:28,280 --> 00:13:29,370
Ĝi estas rilata.

299
00:13:29,370 --> 00:13:31,660
Ĝi apogas la ad hoc demandoj.

300
00:13:31,660 --> 00:13:34,000
Kaj ĝi kaj ĝi grimpas vertikale.

301
00:13:34,000 --> 00:13:39,030
>> Se mi devas akiri pli grandan SQL datumbazo
aŭ pli potenca SQL datumbazo,

302
00:13:39,030 --> 00:13:41,090
Mi iros aĉeti pli grandan pecon de fero.

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

304
00:13:41,600 --> 00:13:44,940
Mi laboris kun multaj klientoj
ke estis tra gravaj ĝisdatigaĵoj

305
00:13:44,940 --> 00:13:48,340
en ilia SQLa infrastrukturo nur
por ekscii ses monatojn poste,

306
00:13:48,340 --> 00:13:49,750
ili estas frapanta la muron denove.

307
00:13:49,750 --> 00:13:55,457
Kaj la respondo de Oracle aŭ MSSQL
aŭ iu alia estas akiri pli grandan skatolon.

308
00:13:55,457 --> 00:13:58,540
Nu malpli frue, vi ne povas aĉeti
grandan skatolon, kaj tio estas vera problemo.

309
00:13:58,540 --> 00:14:00,080
Ni devas vere ŝanĝi tion.

310
00:14:00,080 --> 00:14:01,080
Do kie tio funkcias?

311
00:14:01,080 --> 00:14:06,560
Ĝi laboras bone por eksterreta
analytics, OLAP-tipo laborŝarĝoj.

312
00:14:06,560 --> 00:14:08,670
Kaj tio estas vere kie SQLa apartenas.

313
00:14:08,670 --> 00:14:12,540
Nun, ĝi estas uzata hodiaŭ en multaj rete
transaccionales prilaborado-tipo

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

315
00:14:13,330 --> 00:14:16,460
Kaj ĝi funkcias nur fajna ĉe
iu nivelo de utiligo,

316
00:14:16,460 --> 00:14:18,670
sed simple ne skali
la vojo ke NoSQL faras.

317
00:14:18,670 --> 00:14:20,660
Kaj ni parolos iom
bita pri kial tio estas.

318
00:14:20,660 --> 00:14:23,590
>> Nun, NoSQL, aliflanke,
estas pli optimizado por komputi.

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

320
00:14:24,540 --> 00:14:26,830
Ne estas agnostikulo al
la aliro ŝablono.

321
00:14:26,830 --> 00:14:31,620
Estas kion ni nomas de-ununormigita
strukturo aŭ hierarkia strukturo.

322
00:14:31,620 --> 00:14:35,000
La datumoj en rilata datumbazo estas
kunvenis de multoblaj tabloj

323
00:14:35,000 --> 00:14:36,850
produkti la vido ke vi bezonas.

324
00:14:36,850 --> 00:14:40,090
La datumoj en NoSQL datumbazo
estas stokita en dokumento kiu

325
00:14:40,090 --> 00:14:42,100
enhavas la hierarkia strukturo.

326
00:14:42,100 --> 00:14:45,670
Ĉiuj de la datumoj kiuj normale estus
kunvenis por produkti tiun vidpunkton

327
00:14:45,670 --> 00:14:47,160
estas stokita en ununura dokumento.

328
00:14:47,160 --> 00:14:50,990
Kaj ni parolos iomete pri
kiel tio funkcias en kelkaj mapoj.

329
00:14:50,990 --> 00:14:55,320
>> Sed la ideo estas, ke vi stoki
viajn datumojn kiel tiuj instantiated vidpunktojn.

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

331
00:14:56,410 --> 00:14:58,610
Vi grimpi horizontale.

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

333
00:14:59,556 --> 00:15:02,100
Se mi bezonas pliigi la
grandecon de mia NoSQL stelamaso

334
00:15:02,100 --> 00:15:03,700
Mi ne bezonas akiri pli grandan skatolon.

335
00:15:03,700 --> 00:15:05,200
Mi alvenas alia skatolo.

336
00:15:05,200 --> 00:15:07,700
Kaj mi kolekti tiujn kune,
kaj mi povas Shard ke datumoj.

337
00:15:07,700 --> 00:15:10,780
Ni parolos iom pri
kio sharding estas, esti

338
00:15:10,780 --> 00:15:14,270
povis grimpi ke datenbazo
trans multoblaj fizikaj aparatoj

339
00:15:14,270 --> 00:15:18,370
kaj forigi la baron kiu
postulas min grimpi vertikale.

340
00:15:18,370 --> 00:15:22,080
>> Do ĝi estas vere konstruita por retaj
transakcia prilaborado kaj skalo.

341
00:15:22,080 --> 00:15:25,480
Estas granda distingo
tie inter raportado, dekstra?

342
00:15:25,480 --> 00:15:27,810
Raportado, mi ne scias la
demandoj mi tuj demandas.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- se iu el
miaj marketing fako

345
00:15:30,570 --> 00:15:34,520
volas just-- kiom da de miaj klientoj
havi ĉi apartan karakterizaĵon kiu

346
00:15:34,520 --> 00:15:37,850
aĉetita sur ĉi day-- Mi ne scias
kio konsulti ili tuj demandas.

347
00:15:37,850 --> 00:15:39,160
Do mi devas esti agnostikulo.

348
00:15:39,160 --> 00:15:41,810
>> Nun, en rete
transaccionales apliko,

349
00:15:41,810 --> 00:15:43,820
Mi scias kion demandoj mi demandas.

350
00:15:43,820 --> 00:15:46,581
Mi konstruis la apliko por
tre specifa laborfluo.

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

352
00:15:47,080 --> 00:15:50,540
Do se mi optimizar la datumoj
stoki apogi ke laborfluo,

353
00:15:50,540 --> 00:15:52,020
ĝi tuj estos pli rapida.

354
00:15:52,020 --> 00:15:55,190
Kaj jen kial NoSQL povas
vere akceli la transdono

355
00:15:55,190 --> 00:15:57,710
de tiuj tipoj de servoj.

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

357
00:15:58,210 --> 00:16:00,501
>> Do ni tuj eniri
iomete de teorio tie.

358
00:16:00,501 --> 00:16:03,330
Kaj iu el vi, viaj okuloj
povus ruliĝi reen iomete.

359
00:16:03,330 --> 00:16:06,936
Sed mi provos konservi ĝin
tiel alta nivelo kiel mi povas.

360
00:16:06,936 --> 00:16:08,880
Do se vi estas en projekto
demarŝo, estas

361
00:16:08,880 --> 00:16:12,280
al konstrukcio nomis la
triangulo de devigoj.

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

363
00:16:12,936 --> 00:16:16,060
La triangulo de premas diktaĵoj
vi ne povas havi ĉion ĉiuj la tempo.

364
00:16:16,060 --> 00:16:17,750
Ne havas vian kukaĵon kaj manĝi ĝin ankaŭ.

365
00:16:17,750 --> 00:16:22,310
Do en projekto demarŝo, ke triangulo
devigoj estas vi povas havi ĝin malmultekosta,

366
00:16:22,310 --> 00:16:24,710
Vi povas havi ĝin rapida,
aŭ vi povas havi ĝin bona.

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

368
00:16:25,716 --> 00:16:27,090
Ĉar vi ne povas havi ĉiujn tri.

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

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

371
00:16:27,820 --> 00:16:28,920
>> Do vi aŭdas pri tio tre.

372
00:16:28,920 --> 00:16:31,253
Ĝi estas triobla devige,
triangulo de triobla devige,

373
00:16:31,253 --> 00:16:34,420
aŭ la fera triangulo estas oftentimes--
kiam vi parolos projekti perantoj,

374
00:16:34,420 --> 00:16:35,420
ili parolos pri tio.

375
00:16:35,420 --> 00:16:37,640
Nun, datumbazoj havas
ilia propra fera triangulo.

376
00:16:37,640 --> 00:16:40,350
Kaj la fero Triangulo de datumoj
estas kion ni nomas CAP teoremo.

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

378
00:16:41,580 --> 00:16:43,770
>> CAP teoremo diktaĵoj
kiom datumbazoj funkcii

379
00:16:43,770 --> 00:16:45,627
sub tre specifaj kondiĉoj.

380
00:16:45,627 --> 00:16:47,460
Kaj ni parolos pri
kion tio kondiĉo estas.

381
00:16:47,460 --> 00:16:52,221
Sed la tri punktoj de la triangulo,
tiel diri, estas C, consistencia.

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

383
00:16:52,720 --> 00:16:56,760
Do en Cap, konsistenco signifas ke ĉiuj
klientoj kiuj povas aliri la datumbazon

384
00:16:56,760 --> 00:16:59,084
havos ĉiam tre
konsekvenca vido de datumoj.

385
00:16:59,084 --> 00:17:00,750
Nenies gonna vidi du malsamajn aferojn.

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

387
00:17:01,480 --> 00:17:04,020
Se mi vidas la datumbazo,
Mi vidas la saman vidon

388
00:17:04,020 --> 00:17:06,130
kiel mia partnero, kiu vidas
la sama datumbazo.

389
00:17:06,130 --> 00:17:07,470
Tio consistencia.

390
00:17:07,470 --> 00:17:12,099
>> Havebleco signifas ke se la
datumbazo rete, se ĝi povas esti atingita,

391
00:17:12,099 --> 00:17:14,760
ke ĉiuj klientoj ĉiam
povi legi kaj skribi.

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

393
00:17:15,260 --> 00:17:17,010
Do ĉiu kliento kiu
povas legi la datumbazo

394
00:17:17,010 --> 00:17:18,955
ĉiam povos legado
datumoj kaj skribi datumojn.

395
00:17:18,955 --> 00:17:21,819
Kaj se tio estas la kazo,
ĝi estas havebla sistemo.

396
00:17:21,819 --> 00:17:24,230
>> Kaj la tria punkto estas kio
ni nomas dispartigo toleremo.

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

398
00:17:24,730 --> 00:17:28,160
Dispartigo toleremo rimedoj
ke la sistemo bone funkcias

399
00:17:28,160 --> 00:17:32,000
malgraŭ fizika reto
dispartigas inter la nodoj.

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

401
00:17:32,760 --> 00:17:36,270
Do nodoj en la areto ne povas
konversaciadis, kio okazas?

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

403
00:17:36,880 --> 00:17:39,545
>> Do interrilataj datumbazoj choose--
vi povas elekti du el tiuj.

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

405
00:17:40,045 --> 00:17:43,680
Do interrilataj datumbazoj elekti
esti konsekvenca kaj havebla.

406
00:17:43,680 --> 00:17:47,510
Se la subdisko okazas inter
la DataNodes en la magazeno de datumoj,

407
00:17:47,510 --> 00:17:48,831
datumbazaj kraŝas.

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

409
00:17:49,330 --> 00:17:50,900
Ĝi simple iras malsupren.

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

411
00:17:51,450 --> 00:17:54,230
>> Kaj tio estas kial ili havas
kreski kun pli grandaj skatoloj.

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

413
00:17:54,730 --> 00:17:58,021
Ĉar estas no-- kutime, grapolo
datumbazo, ne estas tre multaj el ili

414
00:17:58,021 --> 00:17:59,590
kiuj operacias tiel.

415
00:17:59,590 --> 00:18:03,019
Sed plej datumbazoj skali
vertikale ene ununura skatolo.

416
00:18:03,019 --> 00:18:05,060
Ĉar ili bezonas esti
konsekvenca kaj havebla.

417
00:18:05,060 --> 00:18:10,320
Se subdisko estis esti injektita,
tiam vi devus fari elekton.

418
00:18:10,320 --> 00:18:13,720
Vi devos fari elekton inter
esti konsekvenca kaj havebla.

419
00:18:13,720 --> 00:18:16,080
>> Kaj tion NoSQL datumbazoj fari.

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

421
00:18:16,580 --> 00:18:20,950
Do NoSQL datumbazo, ĝi
venas en du gustoj.

422
00:18:20,950 --> 00:18:22,990
Ni have-- nu,
venas en multaj gustoj,

423
00:18:22,990 --> 00:18:26,140
sed ĝi venas kun du bazaj
characteristics-- kio

424
00:18:26,140 --> 00:18:30,050
nomus CP datumbazo, aŭ
konsekvenca kaj dispartigo toleremo

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

426
00:18:31,040 --> 00:18:34,930
Tiuj uloj faras la elekton ke kiam
la nodoj perdi kontakton kun unu la alian,

427
00:18:34,930 --> 00:18:37,091
ni ne tuj permesos al
personoj skribi plu.

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

429
00:18:37,590 --> 00:18:41,855
>> Ĝis tiu dispartigo estas forigita,
registran rajton estas blokita.

430
00:18:41,855 --> 00:18:43,230
Tio signifas ke ili estas ne havebla.

431
00:18:43,230 --> 00:18:44,510
Ili estas konsekvenca.

432
00:18:44,510 --> 00:18:46,554
Kiam ni vidas ke
dispartigo injekti sin,

433
00:18:46,554 --> 00:18:48,470
ni estas nun kohera,
ĉar ni ne tuj

434
00:18:48,470 --> 00:18:51,517
permesi la datumoj ŝanĝo sur du
flankoj de la vando sendepende

435
00:18:51,517 --> 00:18:52,100
de ĉiu alia.

436
00:18:52,100 --> 00:18:54,130
Ni devos
restarigi komunikado

437
00:18:54,130 --> 00:18:56,930
antaŭ ajna ĝisdatigo
la datumoj estas permesita.

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

439
00:18:58,120 --> 00:19:02,650
>> La sekva gusto estus AP sistemo,
aŭ disponeblaj kaj dispartigis

440
00:19:02,650 --> 00:19:03,640
toleremo sistemo.

441
00:19:03,640 --> 00:19:05,320
Tiuj uloj ne zorgas.

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

443
00:19:06,020 --> 00:19:08,960
Ajna nodo kiu ricevas
skribi, ni prenos ĝin.

444
00:19:08,960 --> 00:19:11,480
Do mi repliki miaj datumoj
trans multoblaj nodoj.

445
00:19:11,480 --> 00:19:14,730
Tiuj nodoj akiri kliento, kliento venas
en, diras, mi tuj skribos iuj datumoj.

446
00:19:14,730 --> 00:19:16,300
Nodo diras, neniu problemo.

447
00:19:16,300 --> 00:19:18,580
La nodo apud li ricevas
skribo sur la sama disko,

448
00:19:18,580 --> 00:19:20,405
li tuj diros neniu problemo.

449
00:19:20,405 --> 00:19:23,030
Ie reen sur la dorso fino,
ke datumoj tuj repliki.

450
00:19:23,030 --> 00:19:27,360
Kaj tiam iu tuj rimarkas,
uh-oh, ili sistemon konstatos, uh-oh,

451
00:19:27,360 --> 00:19:28,870
tie jam ĝisdatigon al du flankoj.

452
00:19:28,870 --> 00:19:30,370
Kion ni faru?

453
00:19:30,370 --> 00:19:33,210
Kaj kion ili faros estas
ili faras ion, kio

454
00:19:33,210 --> 00:19:36,080
permesas al ili decidu, ke datumoj stato.

455
00:19:36,080 --> 00:19:39,000
Kaj ni parolos pri
ke en la sekva diagramo.

456
00:19:39,000 --> 00:19:40,000
>> Aĵo atentigi ĉi tie.

457
00:19:40,000 --> 00:19:42,374
Kaj mi ne ricevos tro
multe en tiun, ĉar tiu

458
00:19:42,374 --> 00:19:43,510
ekhavas profundan datumoj teorio.

459
00:19:43,510 --> 00:19:46,670
Sed estas transaccional
kadro kiu

460
00:19:46,670 --> 00:19:50,680
kuroj en interrilata sistemo kiu
permesas min sekure fari ĝisdatigojn

461
00:19:50,680 --> 00:19:53,760
al multoblaj unuoj en la datumbazo.

462
00:19:53,760 --> 00:19:58,320
Kaj tiuj ĝisdatigoj okazos
ĉiuj samtempe aŭ ne.

463
00:19:58,320 --> 00:20:00,500
Kaj tio nomiĝas ACID transakcioj.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID donas nin atomicidad, consistencia,
izolado, kaj fortikeco.

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

467
00:20:07,070 --> 00:20:13,550
Tio signifas atoma, transakcioj, ĉiuj
miaj ĝisdatigoj aŭ okazi aŭ ne.

468
00:20:13,550 --> 00:20:16,570
Konsistenco signifas ke
la datumaron ĉiam

469
00:20:16,570 --> 00:20:19,780
enkondukota en konsekvenca
stato post ĝisdatigo.

470
00:20:19,780 --> 00:20:23,900
Mi ne foriros de la datumbazo per
malbona stato post apliki ĝisdatigon.

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

472
00:20:24,400 --> 00:20:26,720
>> Do ĝi estas iom malsama
ol CAP consistencia.

473
00:20:26,720 --> 00:20:29,760
CAP konsistenco signifas mia tuta
klientoj ĉiam povas vidi la datumojn.

474
00:20:29,760 --> 00:20:34,450
ACID konsistenco signifas ke kiam
transakcio estas farita, datumoj estas bonaj.

475
00:20:34,450 --> 00:20:35,709
Miaj interrilatoj estas tute bona.

476
00:20:35,709 --> 00:20:38,750
Mi ne tuj forviŝi gepatro vico
kaj lasos faskon de orfo infanoj

477
00:20:38,750 --> 00:20:40,970
en iu alia tablo.

478
00:20:40,970 --> 00:20:44,320
Ĝi ne povas okazi se mi estas konsekvenca
en acida transakcio.

479
00:20:44,320 --> 00:20:49,120
>> Izolado signifas ke transakcioj
ĉiam okazas unu post la alia.

480
00:20:49,120 --> 00:20:51,920
La fina rezulto de la datumoj
estos la sama stato

481
00:20:51,920 --> 00:20:54,770
kvazaŭ tiuj transakcioj
kiuj emisiis samtempe

482
00:20:54,770 --> 00:20:57,340
estis ekzekutitaj serially.

483
00:20:57,340 --> 00:21:00,030
Do estas samtempeco
kontrolo en la datumbazo.

484
00:21:00,030 --> 00:21:04,130
Do resume, mi ne povas pliigo la
sama valoro dufoje kun du operacioj.

485
00:21:04,130 --> 00:21:08,580
>> Sed se mi diras aldoni 1 al tiu valoro,
kaj du transakcioj enveni

486
00:21:08,580 --> 00:21:10,665
kaj provu fari ĝin, oni estas
tuj akiri tie unue

487
00:21:10,665 --> 00:21:12,540
kaj la aliaj onian
tuj ricevas tie post.

488
00:21:12,540 --> 00:21:15,210
Do en la fino, mi aldonis du.

489
00:21:15,210 --> 00:21:16,170
Vi vidas kion mi volas diri?

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

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

492
00:21:19,220 --> 00:21:21,250
>> Fortikeco estas bela simpla.

493
00:21:21,250 --> 00:21:23,460
Kiam la transakcio
estas agnoskita, ĝi estas

494
00:21:23,460 --> 00:21:26,100
tuj estos tie eĉ
se la sistemo kraŝas.

495
00:21:26,100 --> 00:21:29,230
Kiam tiu sistemo rekuperas, ke
transakcio kiu estis farita

496
00:21:29,230 --> 00:21:30,480
fakte tuj estos tie.

497
00:21:30,480 --> 00:21:33,130
Do jen la garantiojn
de ACID transakcioj.

498
00:21:33,130 --> 00:21:35,470
Tiuj estas sufiĉe bela garantiojn
havi sur datumbazo,

499
00:21:35,470 --> 00:21:36,870
sed ili venas en tiu kosto.

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

501
00:21:37,640 --> 00:21:40,520
>> Ĉar la problemo
kun tiu kadro estas

502
00:21:40,520 --> 00:21:44,540
se estas subdisko en la datumoj
aro, mi devas fari decidon.

503
00:21:44,540 --> 00:21:48,000
Mi tuj devas permesi
ĝisdatigoj sur unu flanko aŭ la alia.

504
00:21:48,000 --> 00:21:50,310
Kaj se tio okazas,
tiam mi ne plu iras

505
00:21:50,310 --> 00:21:52,630
povi subteni
tiuj karakterizaĵoj.

506
00:21:52,630 --> 00:21:53,960
Ili ne estos kohera.

507
00:21:53,960 --> 00:21:55,841
Ili ne estos izolita.

508
00:21:55,841 --> 00:21:58,090
Jen kie rompiĝas
por rilata datumbazoj.

509
00:21:58,090 --> 00:22:01,360
Tiu estas la kialo interrilata
datumbazoj grimpi vertikale.

510
00:22:01,360 --> 00:22:05,530
>> Aliflanke, ni havas
kio nomiĝas BAZO teknologio.

511
00:22:05,530 --> 00:22:07,291
Jen estas via NoSQL Databases.

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

513
00:22:07,790 --> 00:22:10,180
Do ni havas nian CP, AP datumbazoj.

514
00:22:10,180 --> 00:22:14,720
Kaj jen estas, kion vi nomas esence
disponebla, mola stato, eventuale

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

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

517
00:22:16,420 --> 00:22:19,690
>> Esence disponebla, ĉar
ili estas subdisko tolerema.

518
00:22:19,690 --> 00:22:21,470
Ili ĉiam estos
tie, eĉ se estas

519
00:22:21,470 --> 00:22:23,053
reto subdisko inter la nodoj.

520
00:22:23,053 --> 00:22:25,900
Se mi povas paroli al nodo, mi estas
tuj povos legi datumoj.

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

522
00:22:26,460 --> 00:22:30,810
Mi eble ne ĉiam povos skribi
datumo se mi estas konsekvenca platformo.

523
00:22:30,810 --> 00:22:32,130
Sed mi povos legi datumoj.

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

525
00:22:34,960 --> 00:22:38,010
>> La mola stato indikas
ke kiam mi legis ke datumoj,

526
00:22:38,010 --> 00:22:40,790
ĝi povus ne esti la sama kiel aliaj nodoj.

527
00:22:40,790 --> 00:22:43,390
Se dekstra estis emisiita sur nodo
aliloken en la areto

528
00:22:43,390 --> 00:22:46,650
kaj ne reproduktita trans la
grapolo tamen kiam mi legas ke datumoj,

529
00:22:46,650 --> 00:22:48,680
tiu stato ne povus esti konsekvenca.

530
00:22:48,680 --> 00:22:51,650
Tamen, estos
eventuale kohera,

531
00:22:51,650 --> 00:22:53,870
signifante ke kiam registran
estas farita al la sistemo,

532
00:22:53,870 --> 00:22:56,480
ĝi repliki trans la nodoj.

533
00:22:56,480 --> 00:22:59,095
Kaj fine, tiu stato
estos alportita en ordo,

534
00:22:59,095 --> 00:23:00,890
kaj ĝi estos kohera stato.

535
00:23:00,890 --> 00:23:05,000
>> Nun, cap teoremo vere
ludas nur en unu kondiĉo.

536
00:23:05,000 --> 00:23:08,700
Ke kondiĉo estas kiam tiu okazas.

537
00:23:08,700 --> 00:23:13,710
Ĉar kiam ajn ĝi estas operaciis en
normala reĝimo, ne dispartigo,

538
00:23:13,710 --> 00:23:16,370
ĉio estas konsekvenca kaj havebla.

539
00:23:16,370 --> 00:23:19,990
Vi nur maltrankviligi CAP
kiam ni havas tiun dispartigo.

540
00:23:19,990 --> 00:23:21,260
Do tiuj estas maloftaj.

541
00:23:21,260 --> 00:23:25,360
Sed kiel la sistemo reagas kiam tiuj
okazas dikti kion tipo de sistemo

542
00:23:25,360 --> 00:23:26,750
ni pritraktas.

543
00:23:26,750 --> 00:23:31,110
>> Do ni rigardu kio
kiu similas por AP sistemoj.

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

545
00:23:32,621 --> 00:23:34,830
AP sistemoj venas en du gustoj.

546
00:23:34,830 --> 00:23:38,514
Ili venas en la gusto kiu estas
mastro mastro, 100%, ĉiam disponebla.

547
00:23:38,514 --> 00:23:40,430
Kaj ili venis en la
alia gusto, kiu diras:

548
00:23:40,430 --> 00:23:43,330
vi scias kion, mi tuj zorgi
pri tiu dispartiganta afero

549
00:23:43,330 --> 00:23:44,724
kiam reala subdisko okazas.

550
00:23:44,724 --> 00:23:47,890
Alie, ekzistas okazas esti primara
nodoj kiuj tuj prenos la rajtoj.

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

552
00:23:48,500 --> 00:23:50,040
>> Do se ni ion kiel Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra estus majstra
sinjoro: Ni min skribi al ajna nodo.

554
00:23:54,440 --> 00:23:55,540
Do kio okazas?

555
00:23:55,540 --> 00:23:58,270
Do mi havas celon en la
datumbazo kiu ekzistas sur du nodoj.

556
00:23:58,270 --> 00:24:01,705
Ni nomas ke objekto S.
Do ni havas ŝtaton por S.

557
00:24:01,705 --> 00:24:04,312
Ni havas iuj operacioj
sur S kiu estas daŭranta.

558
00:24:04,312 --> 00:24:06,270
Cassandra min permesas
skribi al multoblaj nodoj.

559
00:24:06,270 --> 00:24:08,550
Do diru min akiras
skribi por s al du nodoj.

560
00:24:08,550 --> 00:24:12,274
Nu, kio finas pasante estas
ni nomas tion a dispartiganta okazaĵo.

561
00:24:12,274 --> 00:24:14,190
Tie eble ne estas
fizika reto dispartigo.

562
00:24:14,190 --> 00:24:15,950
Sed pro la dezajno
de la sistemo, ĝi estas

563
00:24:15,950 --> 00:24:18,449
fakte dispartiganta tuj
kiel mi ricevas registran sur du nodoj.

564
00:24:18,449 --> 00:24:20,830
Tio ne devigante min
skribu ĉiuj tra unu nodo.

565
00:24:20,830 --> 00:24:22,340
Mi skribas sur du nodoj.

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

567
00:24:23,330 --> 00:24:25,740
>> Do nun mi havas du statojn.

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

569
00:24:26,360 --> 00:24:28,110
Kio okazos
estas pli aŭ malpli frue,

570
00:24:28,110 --> 00:24:29,960
Tie tuj estos replicación okazaĵo.

571
00:24:29,960 --> 00:24:33,300
Tie tuj estos kio ni
nomata subdisko reakiro, kiu

572
00:24:33,300 --> 00:24:35,200
estas kie ĉi tiuj du
ŝtatoj revenu kune

573
00:24:35,200 --> 00:24:37,310
kaj tie tuj estos algoritmo
kiu kuras ene la datumbazo,

574
00:24:37,310 --> 00:24:38,540
decidas kion fari.

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

576
00:24:39,110 --> 00:24:43,057
Defaŭlte, la lasta ĝisdatigo
venkas en plej AP sistemoj.

577
00:24:43,057 --> 00:24:44,890
Do ekzistas kutime
defaŭlta algoritmo, kio

578
00:24:44,890 --> 00:24:47,400
ili nomas callback
funkcio, iu kiu

579
00:24:47,400 --> 00:24:51,000
estos nomita kiam kondicxo
estas detektita ekzekuti iuj logiko

580
00:24:51,000 --> 00:24:52,900
solvi tiu konflikto.

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

582
00:24:53,850 --> 00:24:58,770
La defaŭlta callback kaj defaŭlte
Resolver en plej AP datumbazoj

583
00:24:58,770 --> 00:25:01,130
estas, divenu kion, timestamp gajnas.

584
00:25:01,130 --> 00:25:02,380
Tio estis la lasta ĝisdatigo.

585
00:25:02,380 --> 00:25:04,320
Mi tuj metis tiun ĝisdatigon en tie.

586
00:25:04,320 --> 00:25:08,440
Mi povas forĵeti tiun rekordon kiu mi
faligis for en reakiro log

587
00:25:08,440 --> 00:25:11,670
tiel ke la uzanto povas reveni poste
kaj diri, hej, ekzistis kolizio.

588
00:25:11,670 --> 00:25:12,320
Kio okazis?

589
00:25:12,320 --> 00:25:16,370
Kaj vi povas reale dump priskribu
ĉiuj kolizioj kaj la rollbacks

590
00:25:16,370 --> 00:25:17,550
kaj vidu kio okazas.

591
00:25:17,550 --> 00:25:21,580
>> Nun, kiel uzanto, vi povas ankaŭ
inkluzivas logiko en tiun callback.

592
00:25:21,580 --> 00:25:24,290
Do vi povas ŝanĝi tion
callback operacio.

593
00:25:24,290 --> 00:25:26,730
Vi povas diri, hej, mi volas
al remediate tiu datumo.

594
00:25:26,730 --> 00:25:28,880
Kaj mi volas provi kaj
kunfandi tiujn du registroj.

595
00:25:28,880 --> 00:25:30,050
Sed tio estas ĝis vi.

596
00:25:30,050 --> 00:25:32,880
La datumbazo ne scipovas
fari tion defaŭlte. Plej la tempo,

597
00:25:32,880 --> 00:25:34,850
La nura afero la datumbazo
scias fari estas diri,

598
00:25:34,850 --> 00:25:36,100
ĉi tiu estis la lasta rekordo.

599
00:25:36,100 --> 00:25:39,183
Tio estas la unu kiu estas iranta gajni,
kaj tio estas la valoro mi tuj metis.

600
00:25:39,183 --> 00:25:41,490
Unufoje ke dispartigo reakiro
kaj replicación okazas,

601
00:25:41,490 --> 00:25:43,930
ni havos niajn stato, kiun
nun S primo, kiu estas

602
00:25:43,930 --> 00:25:46,890
la merge stato de ĉiuj tiuj objektoj.

603
00:25:46,890 --> 00:25:49,700
Do AP sistemoj havas tiun.

604
00:25:49,700 --> 00:25:51,615
CP sistemoj ne bezonas
zorgi pri tio.

605
00:25:51,615 --> 00:25:54,490
Ĉar kiam subdisko venas
en ludon, ili nur ĉesas preni

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

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

608
00:25:56,180 --> 00:25:58,670
Do jen tre facila
trakti esti konsekvenca

609
00:25:58,670 --> 00:26:01,330
kiam vi ne akceptas ajnan ĝisdatigojn.

610
00:26:01,330 --> 00:26:04,620
Jen kun CP sistemoj fari.

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

612
00:26:05,120 --> 00:26:07,590
>> Do ni parolu iom
bita pri aliro ŝablonoj.

613
00:26:07,590 --> 00:26:11,580
Kiam ni parolas pri NoSQL, estas
ĉion pri la aliro ŝablono.

614
00:26:11,580 --> 00:26:13,550
Nun, SQL estas ad hoc, mendoj.

615
00:26:13,550 --> 00:26:14,481
Ĝi estas rilata vendejo.

616
00:26:14,481 --> 00:26:16,480
Ni ne devas maltrankviligi
pri la aliro ŝablono.

617
00:26:16,480 --> 00:26:17,688
Mi skribas tre kompleksa demando.

618
00:26:17,688 --> 00:26:19,250
Ĝi iras kaj alprenas la datumoj.

619
00:26:19,250 --> 00:26:21,210
Tion ĉi aspektas
kiel, normaligo.

620
00:26:21,210 --> 00:26:24,890
>> Do en tiu speciala strukturo,
ni rigardas produktoj katalogo.

621
00:26:24,890 --> 00:26:26,640
Mi havas malsamajn tipojn de produktoj.

622
00:26:26,640 --> 00:26:27,217
Mi havas librojn.

623
00:26:27,217 --> 00:26:27,800
Mi havas albumoj.

624
00:26:27,800 --> 00:26:30,090
Mi havas filmetoj.

625
00:26:30,090 --> 00:26:33,370
La interrilato inter produktoj
kaj iu el tiuj libroj, diskoj,

626
00:26:33,370 --> 00:26:34,860
kaj filmetoj tabloj estas 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Mi havas produkton ID,
kaj ke ID respondas

629
00:26:38,860 --> 00:26:41,080
al libro, albumo, aŭ video.

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

631
00:26:41,580 --> 00:26:44,350
Tio estas 1: 1 rilato
trans tiuj tabloj.

632
00:26:44,350 --> 00:26:46,970
>> Nun, books-- ĉiuj ili
havas estas radiko propraĵoj.

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

634
00:26:47,550 --> 00:26:48,230
Tio estas granda.

635
00:26:48,230 --> 00:26:52,130
Unu-al-unu rilato, mi akiras ĉiuj
la datumo mi bezonas priskribi tiun libron.

636
00:26:52,130 --> 00:26:54,770
Albums-- albumoj havas trakojn.

637
00:26:54,770 --> 00:26:56,470
Jen kion ni nomas unu al multaj.

638
00:26:56,470 --> 00:26:58,905
Ĉiu albumo povus esti multaj trakoj.

639
00:26:58,905 --> 00:27:00,780
Do por ĉiu trako sur
la albumo, mi povus havi

640
00:27:00,780 --> 00:27:02,570
alia rekordo en tiu infano tablo.

641
00:27:02,570 --> 00:27:04,680
Do mi kreas unu rekordo
en mia albumoj tablo.

642
00:27:04,680 --> 00:27:06,700
Mi kreas multoblajn rekordojn
en la aŭtoveturejoj tablo.

643
00:27:06,700 --> 00:27:08,850
Unu-al-multaj rilato.

644
00:27:08,850 --> 00:27:11,220
>> Tiu rilato estas kio
ni nomas multaj-al-multaj.

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

646
00:27:11,750 --> 00:27:17,000
Komprenu ke aktoroj povus esti
en multaj filmoj, multaj videoj.

647
00:27:17,000 --> 00:27:21,450
Do kion ni faras estas ni metu ĉi surĵeto
tablo inter tiuj, kiuj nur

648
00:27:21,450 --> 00:27:24,040
mapoj la aktoro ID al la video ID.

649
00:27:24,040 --> 00:27:28,464
Nun mi povas krei query la krampoj
videos tra aktoro video por aktoroj,

650
00:27:28,464 --> 00:27:31,130
kaj donu al mi belan Listo
ĉiuj filmoj kaj ĉiuj aktoroj

651
00:27:31,130 --> 00:27:32,420
kiuj estis en tiu filmo.

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

653
00:27:33,290 --> 00:27:33,880
Do jen ni iras.

654
00:27:33,880 --> 00:27:38,040
Unu-al-unu estas la pintnivela
interrilato; unu-al-multaj,

655
00:27:38,040 --> 00:27:40,240
albumojn al trakojn; multaj-al-multaj.

656
00:27:40,240 --> 00:27:44,990
Tiuj estas la tri pintnivela
interrilatoj en ajna datumbazo.

657
00:27:44,990 --> 00:27:48,050
Se vi scias kiel tiuj
interrilatoj labori kune,

658
00:27:48,050 --> 00:27:51,490
tiam vi scios multon
pri datumbazo jam.

659
00:27:51,490 --> 00:27:55,660
Do NoSQL laboras iom alimaniere.

660
00:27:55,660 --> 00:27:58,930
Ni pensu pri dum sekundo kio
rigardojn ŝatas iri akiri ĉiujn miajn produktojn.

661
00:27:58,930 --> 00:28:01,096
>> En rilata vendejo, mi
volas akiri ĉiujn miajn produktojn

662
00:28:01,096 --> 00:28:02,970
sur listo de ĉiuj miaj produktoj.

663
00:28:02,970 --> 00:28:04,910
Tio estas multe de demandoj.

664
00:28:04,910 --> 00:28:07,030
Mi akiris query por ĉiuj miaj libroj.

665
00:28:07,030 --> 00:28:08,470
Mi akiris query el miaj albumoj.

666
00:28:08,470 --> 00:28:09,970
Kaj mi ricevis query por ĉiuj miaj filmetoj.

667
00:28:09,970 --> 00:28:11,719
Kaj mi alvenis al meti ŝin
ĉiuj kune en lerta

668
00:28:11,719 --> 00:28:15,250
kaj servi lin reen ĝis la
apliko kiu estas petanta ĝin.

669
00:28:15,250 --> 00:28:18,000
>> Akiri miajn librojn, mi aliĝi
Produktoj kaj Libroj.

670
00:28:18,000 --> 00:28:21,680
Akiri miajn albumojn, mi alvenis al kunigi
Produktoj, Albumoj kaj Trakoj.

671
00:28:21,680 --> 00:28:25,330
Kaj akiro miaj filmetoj, mi havas
aliĝi Produktoj al Videoj,

672
00:28:25,330 --> 00:28:28,890
aliĝi tra Aktoro Videoj,
kaj enportu la Aktoroj.

673
00:28:28,890 --> 00:28:31,020
Do jen tri demandoj.

674
00:28:31,020 --> 00:28:34,560
Tre kompleksa pridemandojn
kunvenigi unu rezulto aro.

675
00:28:34,560 --> 00:28:36,540
>> Tio estas malpli ol optimuma.

676
00:28:36,540 --> 00:28:39,200
Jen kial kiam ni parolas
pri datumstrukturo tio

677
00:28:39,200 --> 00:28:42,900
konstruita esti agnostikulo al la aliro
pattern-- bone ke estas granda.

678
00:28:42,900 --> 00:28:45,730
Kaj vi povas vidi ĉi estas vere
bela kiom ni organizas la datumojn.

679
00:28:45,730 --> 00:28:46,550
Kaj vi scias kion?

680
00:28:46,550 --> 00:28:49,750
Mi nur havas unu rekordo por aktoro.

681
00:28:49,750 --> 00:28:50,440
>> Tio estas mojosa.

682
00:28:50,440 --> 00:28:53,750
Mi deduplicated ĉiuj miaj aktoroj,
kaj mi subtenis mian asocioj

683
00:28:53,750 --> 00:28:55,200
en tiu mapado tablo.

684
00:28:55,200 --> 00:29:00,620
Tamen, Akiranta la datumoj
eksteren iĝas multekosta.

685
00:29:00,620 --> 00:29:04,500
Mi sendas la CPU tuta sistemo
aliĝanta tiuj datumstrukturoj kune

686
00:29:04,500 --> 00:29:05,950
povi tiri ke datumoj dorso.

687
00:29:05,950 --> 00:29:07,310
>> Do kiel mi elturniĝi?

688
00:29:07,310 --> 00:29:11,200
En NoSQL temas pri
agregación, ne normaligo.

689
00:29:11,200 --> 00:29:13,534
Do ni volas diri ni volas
apogi la aliro ŝablono.

690
00:29:13,534 --> 00:29:15,283
Se la aliro mastron
al la aplikoj,

691
00:29:15,283 --> 00:29:16,770
Mi bezonos akiri ĉiujn miajn produktojn.

692
00:29:16,770 --> 00:29:19,027
Ni metu ĉiujn produktojn en la sama tablo.

693
00:29:19,027 --> 00:29:22,110
Se mi metis ĉiujn produktojn en la sama tablo,
Mi povas nur elekti ĉiuj produktoj

694
00:29:22,110 --> 00:29:23,850
de tiu tablo kaj mi akiras ĉion.

695
00:29:23,850 --> 00:29:25,240
Nu kiel mi faru tion?

696
00:29:25,240 --> 00:29:28,124
Nu en NoSQL estas nenia
strukturon al la tablo.

697
00:29:28,124 --> 00:29:30,540
Ni parolos iomete pri
kiel tio funkcias en Dinamo DB.

698
00:29:30,540 --> 00:29:33,570
Sed vi ne havas la saman
atributoj kaj la samaj propraĵoj

699
00:29:33,570 --> 00:29:37,751
en ĉiu unuopa vico, en ĉiu unuopa
ero, kiel vi faras en SQL tablo.

700
00:29:37,751 --> 00:29:39,750
Kaj kion tio permesas min
fari estas multaj aferoj

701
00:29:39,750 --> 00:29:41,124
kaj donu al mi multan flekseblecon.

702
00:29:41,124 --> 00:29:45,360
En ĉi tiu aparta kazo, mi
havas mian produkton dokumentoj.

703
00:29:45,360 --> 00:29:49,090
Kaj en ĉi tiu aparta
Ekzemple, ĉiu

704
00:29:49,090 --> 00:29:51,930
estas dokumento en la Produktoj tablo.

705
00:29:51,930 --> 00:29:56,510
Kaj la produkto por libro eble
havi tipon ID kiu specifas libron.

706
00:29:56,510 --> 00:29:59,180
Kaj la aplikaĵo
estus enŝaltu ke ID.

707
00:29:59,180 --> 00:30:02,570
>> Ĉe la apliko tier, mi tuj
diri ho, kia rekordo tipo estas tio?

708
00:30:02,570 --> 00:30:04,100
Ho, ĝi estas libro rekordo.

709
00:30:04,100 --> 00:30:05,990
Libro rekordoj havas tiujn trajtojn.

710
00:30:05,990 --> 00:30:08,100
Lasu min krei libron objekto.

711
00:30:08,100 --> 00:30:11,289
Do mi tuj plenigos la
libro objekton kun tiu ero.

712
00:30:11,289 --> 00:30:13,080
Sekva ero venas kaj
diras, kio estas tio eron?

713
00:30:13,080 --> 00:30:14,560
Nu ĉi artikolo estas albumo.

714
00:30:14,560 --> 00:30:17,340
Ho, mi ricevis tutajn malsamajn
prilaborado rutinon por ke,

715
00:30:17,340 --> 00:30:18,487
ĉar ĝi estas albumo.

716
00:30:18,487 --> 00:30:19,320
Vi vidas kion mi volas diri?

717
00:30:19,320 --> 00:30:21,950
>> Do la apliko tier-- mi
simple elektu cxiujn tiujn rekordojn.

718
00:30:21,950 --> 00:30:23,200
Ili ĉiuj komenci venon.

719
00:30:23,200 --> 00:30:24,680
Ili povus esti ĉiuj malsamaj tipoj.

720
00:30:24,680 --> 00:30:27,590
Kaj ĝi estas la apliko de logiko
ke ŝanĝas trans tiuj tipoj

721
00:30:27,590 --> 00:30:29,530
kaj decidas kiel prilabori ilin.

722
00:30:29,530 --> 00:30:33,640
>> Denove, tiel ni optimizando la
skemo por la aliro ŝablono.

723
00:30:33,640 --> 00:30:36,390
Ni faras tion per
kolapsado tiuj tabloj.

724
00:30:36,390 --> 00:30:39,670
Ni esence prenante
tiuj ununormigita strukturoj,

725
00:30:39,670 --> 00:30:42,000
kaj ni konstruas
hierarkia strukturo.

726
00:30:42,000 --> 00:30:45,130
Ene de ĉiu el ĉi tiuj rekordoj
Mi tuj vidu tabelo propraĵoj.

727
00:30:45,130 --> 00:30:49,400
>> Ene de tiu dokumento por Albumoj,
Mi vidas arrays de aŭtoveturejoj.

728
00:30:49,400 --> 00:30:53,900
Tiuj temoj nun become-- estas
esence tiu infano tablo ke

729
00:30:53,900 --> 00:30:56,520
ekzistas ĉi tie en ĉi tiu strukturo.

730
00:30:56,520 --> 00:30:57,975
Do vi povas fari tion en DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Vi povas fari tion en MongoDB.

732
00:30:59,810 --> 00:31:01,437
Vi povas fari tion en ajna NoSQL datumbazo.

733
00:31:01,437 --> 00:31:03,520
Krei tiuj tipoj de
hierarkia datumstrukturoj

734
00:31:03,520 --> 00:31:07,120
kiuj permesas al vi elsxuti datumoj
tre rapide ĉar nun mi

735
00:31:07,120 --> 00:31:08,537
ne devas konformiĝi.

736
00:31:08,537 --> 00:31:11,620
Kiam mi enmeti vico en la Trakoj
tablo, aŭ vico en la Albumoj tablo

737
00:31:11,620 --> 00:31:13,110
Mi devas konformiĝi al tiu skemo.

738
00:31:13,110 --> 00:31:18,060
Mi devas havi la atributon aŭ la
proprieto kiu estas difinita sur tiu tablo.

739
00:31:18,060 --> 00:31:20,480
Cxiu de ili,
kiam mi enmeti tiu vico.

740
00:31:20,480 --> 00:31:21,910
Tio ne estas la kazo en NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Mi povas havi plene malsama
propraĵoj en ĉiu dokumenton

742
00:31:24,440 --> 00:31:26,100
ke mi enmeti en la kolekto.

743
00:31:26,100 --> 00:31:30,480
Do tre potenca mekanismo.

744
00:31:30,480 --> 00:31:32,852
Kaj estas vere kiel vi
optimizar la sistemo.

745
00:31:32,852 --> 00:31:35,310
Ĉar nun ke query, anstataŭ
de aliĝado ĉiuj tiuj tabloj

746
00:31:35,310 --> 00:31:39,160
kaj ekzekutante duono dekduo demandoj
tiri reen la datumojn mi bezonas,

747
00:31:39,160 --> 00:31:40,890
Mi efektiviganta unu mendo.

748
00:31:40,890 --> 00:31:43,010
Kaj mi ripetanta
trans la rezultoj starigis.

749
00:31:43,010 --> 00:31:46,512
ĝi donas al vi ideon
de la potenco de NoSQL.

750
00:31:46,512 --> 00:31:49,470
Mi tuj speco de iri flanken tie
kaj paroli iomete pri tio.

751
00:31:49,470 --> 00:31:53,240
Ĉi tio estas pli afabla el la
marketing aŭ technology--

752
00:31:53,240 --> 00:31:55,660
la merkatiko de teknologio
tipo de diskuto.

753
00:31:55,660 --> 00:31:58,672
Sed estas grave kompreni
ĉar se ni rigardas la pinto

754
00:31:58,672 --> 00:32:00,380
tie ĉe tiu diagramo,
kion ni rigardis

755
00:32:00,380 --> 00:32:04,030
estas kion ni nomas la
teknologio tamburego kurbo.

756
00:32:04,030 --> 00:32:06,121
Kaj kion tio signifas estas
novaj aĵoj venas en ludon.

757
00:32:06,121 --> 00:32:07,120
Homoj kredas ke estas granda.

758
00:32:07,120 --> 00:32:09,200
Mi jam solvis ĉiujn miajn problemojn.

759
00:32:09,200 --> 00:32:11,630
>> Tio povus esti la fino
ĉiuj, estu ĉiuj al ĉio.

760
00:32:11,630 --> 00:32:12,790
Kaj ili ekuzi ĝin.

761
00:32:12,790 --> 00:32:14,720
Kaj ili diras, ĉi stuff ne funkcias.

762
00:32:14,720 --> 00:32:17,600
Tio ne pravas.

763
00:32:17,600 --> 00:32:19,105
La ruzaĵojn estis bona.

764
00:32:19,105 --> 00:32:21,230
Kaj superas al faras
aferojn la vojo ili estis.

765
00:32:21,230 --> 00:32:22,730
Kaj tiam poste
ili iras, vi scias kion?

766
00:32:22,730 --> 00:32:24,040
Ĉi tiujn aferojn estas ne tiom malbona.

767
00:32:24,040 --> 00:32:26,192
Ho, jen kiel ĝi funkcias.

768
00:32:26,192 --> 00:32:28,900
Kaj unufoje ili elkompreni kiel
verkoj, ili komencas akiranta pli bonan.

769
00:32:28,900 --> 00:32:32,050
>> Kaj la amuza afero pri ĝi
estas, speco de regiono al kio

770
00:32:32,050 --> 00:32:34,300
ni nomas la Teknologio Adopto Kurbo.

771
00:32:34,300 --> 00:32:36,910
Do kio okazas estas ni havas
ia teknologio ellasilon.

772
00:32:36,910 --> 00:32:39,100
En la kazo de datumbazoj,
ĝi estas datumoj premo.

773
00:32:39,100 --> 00:32:42,200
Ni parolis pri la alta akvo punktoj
de datumoj premo tra tempo.

774
00:32:42,200 --> 00:32:46,310
Kiam ke datumoj premo trafas certaj
punkto, tio estas teknologio ellasilon.

775
00:32:46,310 --> 00:32:47,830
>> Ĝi Fariĝas tro multekostaj.

776
00:32:47,830 --> 00:32:49,790
Ĝi prenas tro longa por procesi la datumojn.

777
00:32:49,790 --> 00:32:50,890
Ni bezonas ion pli bonan.

778
00:32:50,890 --> 00:32:52,890
Vi ricevas la pioniraj
tie ekstere kurante ĉirkaŭe,

779
00:32:52,890 --> 00:32:55,050
provante elŝeligi kio estas la solvo.

780
00:32:55,050 --> 00:32:56,050
Kio estas nova ideo?

781
00:32:56,050 --> 00:32:58,170
>> Kio estas la sekva plej bona
maniero agi tiel?

782
00:32:58,170 --> 00:32:59,530
Kaj ili venas supre kun io.

783
00:32:59,530 --> 00:33:03,140
Kaj la popolo kun la reala doloro,
la infanoj de la sanganta rando,

784
00:33:03,140 --> 00:33:06,390
ili devos salti ĉiuj super ĝi,
ĉar ili bezonas respondon.

785
00:33:06,390 --> 00:33:09,690
Nun kio neeviteble happens-- kaj
ĝi okazas nun en NoSQL.

786
00:33:09,690 --> 00:33:11,090
Mi vidas la tutan tempon.

787
00:33:11,090 --> 00:33:13,610
>> Kio neeviteble okazas estas
personoj ekuzi la nova ilo

788
00:33:13,610 --> 00:33:15,490
sammaniere oni uzis la malnovan ilon.

789
00:33:15,490 --> 00:33:17,854
Kaj ili trovis inter ĝi
ne funkcias tiel bone.

790
00:33:17,854 --> 00:33:20,020
Mi ne memoras kiu mi estis
parolante al antaŭe hodiaŭ.

791
00:33:20,020 --> 00:33:22,080
Sed estas kiel, kiam la
Jackhammer estis inventita,

792
00:33:22,080 --> 00:33:24,621
personoj ne svingi ĝin super
ilia kapo frakasi la betono.

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

794
00:33:27,360 --> 00:33:30,610
>> Sed tio kio estas
okazanta kun NoSQL hodiaŭ.

795
00:33:30,610 --> 00:33:33,900
Se vi iras por plej butikoj,
ili klopodas esti NoSQL butikoj.

796
00:33:33,900 --> 00:33:36,510
Kion ili faras estas
ili estas uzanta NoSQL,

797
00:33:36,510 --> 00:33:39,900
kaj ili estas tio ŝargado
plena de interrilata schema.

798
00:33:39,900 --> 00:33:41,630
Ĉar tio estas kiel
ili desegni datumbazoj.

799
00:33:41,630 --> 00:33:44,046
Kaj ili scivolas, kial estas
ĝi ne elfaranta tre bone?

800
00:33:44,046 --> 00:33:45,230
Knabo, tiu afero fetoras.

801
00:33:45,230 --> 00:33:49,900
Mi devis subteni ĉiujn miajn
kunigas in-- estas kvazaŭ, ne, ne.

802
00:33:49,900 --> 00:33:50,800
Subteni kunigas?

803
00:33:50,800 --> 00:33:52,430
Kial vi aliĝado datumoj?

804
00:33:52,430 --> 00:33:54,350
Vi ne aliĝi datumoj en NoSQL.

805
00:33:54,350 --> 00:33:55,850
Vi aldonas ĝin.

806
00:33:55,850 --> 00:34:00,690
>> Do se vi volas eviti tion, lerni
kiom la ilo laboras antaŭ vi reale

807
00:34:00,690 --> 00:34:02,010
ekuzi ĝin.

808
00:34:02,010 --> 00:34:04,860
Ne provu kaj uzi la novajn ilojn la
sama maniero vi uzis la malnovajn ilojn.

809
00:34:04,860 --> 00:34:06,500
Vi tuj havas malbonan sperton.

810
00:34:06,500 --> 00:34:08,848
Kaj ĉiu ununura tempo
Tion ĉi estas proksimume.

811
00:34:08,848 --> 00:34:11,389
Kiam ni komencas venanta supre ĉi tie,
ĝi estas ĉar homoj eltrovis

812
00:34:11,389 --> 00:34:13,449
kiel uzi la ilojn.

813
00:34:13,449 --> 00:34:16,250
>> Ili faris la saman aĵon kiam
interrilata datumbazoj estis inventita,

814
00:34:16,250 --> 00:34:17,969
kaj ili anstataŭante dosiersistemojn.

815
00:34:17,969 --> 00:34:20,420
Ili provis konstrui dosiersistemojn
kun rilata datumbazoj

816
00:34:20,420 --> 00:34:22,159
ĉar tio estas kion homoj komprenas.

817
00:34:22,159 --> 00:34:23,049
Ĝi ne funkciis.

818
00:34:23,049 --> 00:34:26,090
Do komprenanta la bonaj praktikoj
de la teknologio vi laboras kun

819
00:34:26,090 --> 00:34:26,730
estas grandega.

820
00:34:26,730 --> 00:34:29,870
Tre grava.

821
00:34:29,870 --> 00:34:32,440
>> Do ni tuj eniri DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB estas AWS La
plene sukcesis NoSQL platformo.

823
00:34:36,480 --> 00:34:37,719
Kion plene sukcesis signifas?

824
00:34:37,719 --> 00:34:40,010
Ĝi signifas ke vi ne bezonas
vere maltrankvili pri io ajn.

825
00:34:40,010 --> 00:34:42,060
>> Vi eniras, vi diru
ni, mi bezonas tablon.

826
00:34:42,060 --> 00:34:43,409
Ĝi bezonas multe ĉi kapablo.

827
00:34:43,409 --> 00:34:47,300
Vi trafis la butonon, kaj ni provizo
tuta infrastrukturo malantaŭ la sceno.

828
00:34:47,300 --> 00:34:48,310
Nun ke estas enorma.

829
00:34:48,310 --> 00:34:51,310
>> Ĉar kiam vi parolas
pri krustanta datumbazon,

830
00:34:51,310 --> 00:34:53,917
NoSQL datumoj aretoj ĉe
skalo, kurado petabytes,

831
00:34:53,917 --> 00:34:55,750
kurante milionojn da
transakcioj je sekundo,

832
00:34:55,750 --> 00:34:58,180
tiuj aferoj ne estas malgrandaj amasoj.

833
00:34:58,180 --> 00:35:00,830
Ni parolas miloj da petskriboj.

834
00:35:00,830 --> 00:35:04,480
Administranta miloj da kazoj,
eĉ virtuala petskribojn,

835
00:35:04,480 --> 00:35:06,350
estas reela doloro en la pugo.

836
00:35:06,350 --> 00:35:09,110
Mi volas diri, pensi pri ĉiufoje oni
operaciumo diakilo eliras

837
00:35:09,110 --> 00:35:11,552
aŭ nova versio de la datumbazo.

838
00:35:11,552 --> 00:35:13,260
Kion tio signifas
al vi funkcie?

839
00:35:13,260 --> 00:35:16,330
Tio signifas ke vi akiris 1,200
serviloj kiuj bezonas esti ĝisdatigita.

840
00:35:16,330 --> 00:35:18,960
Nun eĉ kun aŭtomatigo,
kiu povas preni longan tempon.

841
00:35:18,960 --> 00:35:21,480
Tio povas kaŭzi multajn
operacia kapdoloroj,

842
00:35:21,480 --> 00:35:23,090
ĉar mi havu servoj suben.

843
00:35:23,090 --> 00:35:26,070
>> Kiel mi ĝisdatigos tiuj datumbazoj, mi
plenumadu blua verda deplojoj

844
00:35:26,070 --> 00:35:29,420
Kie mi deploji kaj altgradigi duono mia
nodoj, kaj tiam ĝisdatigi la alian duonon.

845
00:35:29,420 --> 00:35:30,490
Prenu tiujn malsupren.

846
00:35:30,490 --> 00:35:33,410
Do administranta la infrastrukturon
skalo estas ege doloraj.

847
00:35:33,410 --> 00:35:36,210
Kaj AWS preni tiun doloron el ĝi.

848
00:35:36,210 --> 00:35:39,210
Kaj NoSQL datumbazoj povas
eksterordinare dolora

849
00:35:39,210 --> 00:35:41,780
pro la maniero ili grimpi.

850
00:35:41,780 --> 00:35:42,926
>> Grimpi horizontale.

851
00:35:42,926 --> 00:35:45,550
Se vi deziras akiri pli grandan NoSQL
datenbazo, vi aĉetas pli nodoj.

852
00:35:45,550 --> 00:35:48,660
Ĉiu nodo vi aĉetas estas
alia operacia kapdoloron.

853
00:35:48,660 --> 00:35:50,830
Do iu alia faros tion por vi.

854
00:35:50,830 --> 00:35:52,000
AWS povas fari tion.

855
00:35:52,000 --> 00:35:54,587
>> Ni apogas dokumenton ŝlosilo valoroj.

856
00:35:54,587 --> 00:35:56,670
Nun ni ne iru tro multe
en aliflanke diagramo.

857
00:35:56,670 --> 00:35:58,750
Ekzistas multe da malsamaj
gustoj de NoSQL.

858
00:35:58,750 --> 00:36:02,670
Ili estas ĉiaj atingi
munged kune ĉe tiu punkto.

859
00:36:02,670 --> 00:36:06,260
Vi povas rigardi DynamoDB kaj diri jes,
ni ambaŭ dokumenton kaj ŝlosila valoro

860
00:36:06,260 --> 00:36:08,412
stoki tiu punkto.

861
00:36:08,412 --> 00:36:10,620
Kaj vi povas argumenti la trajtoj
de unu super la alia.

862
00:36:10,620 --> 00:36:13,950
Al mi, multe da tio vere ses
de unu duono dekduo de la alia.

863
00:36:13,950 --> 00:36:18,710
Ĉiu el tiuj teknologioj estas
delikatan teknologion kaj monpuno solvo.

864
00:36:18,710 --> 00:36:23,390
Mi ne dirus MongoDB estas bona aŭ
malbona ol Couch, tiam Cassandra,

865
00:36:23,390 --> 00:36:25,994
tiam Dinamo, aŭ inverse.

866
00:36:25,994 --> 00:36:27,285
Mi volas diri, jen nur ebloj.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Ĝi estas rapida kaj ĝi estas
konsekvenca en ajna skalo.

869
00:36:32,700 --> 00:36:36,210
Do ĉi tiu estas unu el la plej grandaj
gratifikoj vi akiras kun AWS.

870
00:36:36,210 --> 00:36:40,850
Kun DynamoDB estas la kapablo
akiri malaltan sola cifero

871
00:36:40,850 --> 00:36:44,040
milisegundo latencia en ajna skalo.

872
00:36:44,040 --> 00:36:45,720
Ke estis dezajno celo de la sistemo.

873
00:36:45,720 --> 00:36:49,130
Kaj ni havas klientoj kiuj faras
milionoj da transakcioj je sekundo.

874
00:36:49,130 --> 00:36:52,670
>> Nun mi iros tra kelkaj el tiuj
Uzkazoj post kelkaj minutoj tie.

875
00:36:52,670 --> 00:36:55,660
Integrita aliro control--
ni havas, kion ni nomas

876
00:36:55,660 --> 00:36:57,920
Identeco Aliro Management, aŭ IAM.

877
00:36:57,920 --> 00:37:01,980
Ĝi trapenetras ĉiun sistemon,
ĉiu servo kiu proponas AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB estas neniu escepto.

879
00:37:03,630 --> 00:37:06,020
Vi povas kontroli la aliron
al la DynamoDB tabloj.

880
00:37:06,020 --> 00:37:09,960
Tra ĉiuj viaj kontoj AWS per
difinanta aliro rolojn kaj permesoj

881
00:37:09,960 --> 00:37:12,140
en la IAM infrastrukturo.

882
00:37:12,140 --> 00:37:16,630
>> Kaj ĝi estas kerna kaj integra komponanto en
kion ni nomas Event Driven Programado.

883
00:37:16,630 --> 00:37:19,056
Nun tiu estas nova paradigmo.

884
00:37:19,056 --> 00:37:22,080
>> Publiko: Kiel fartas via imposto de veraj
pozitivaj kontre falsaj negativoj

885
00:37:22,080 --> 00:37:24,052
sur via aliro kontrolo sistemo?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: Vera pozitivaĵoj
kontre falsaj negativaj?

887
00:37:26,260 --> 00:37:28,785
Publiko: Revenante kio
vi devas reveni?

888
00:37:28,785 --> 00:37:33,720
Kontraste al tempaltempe ĝi
ne redonas kiam devus validigi?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: Mi ne povus diri al vi ke.

891
00:37:38,050 --> 00:37:40,140
Se estas neniu fiaskoj
whatsoever sur tio,

892
00:37:40,140 --> 00:37:42,726
Mi ne estas la persono por demandi
tiu aparta demando.

893
00:37:42,726 --> 00:37:43,850
Sed tio estas bona demando.

894
00:37:43,850 --> 00:37:45,905
Mi estus scivola scii
ke mi mem, reale.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Kaj tiel do denove, nova paradigmo
estas okazaĵo movita programado.

897
00:37:51,320 --> 00:37:55,160
Tio estas la ideo ke vi povas
deploji kompleksaj aplikoj kiuj

898
00:37:55,160 --> 00:37:59,720
povas funkcii tre, tre alta skalo
sen infrastrukturo whatsoever.

899
00:37:59,720 --> 00:38:02,120
Sen ajna fiksa
infrastrukturo whatsoever.

900
00:38:02,120 --> 00:38:04,720
Kaj ni parolos iomete
pri kio tio signifas, kiel ni

901
00:38:04,720 --> 00:38:06,550
eniri la sekva paro de mapoj.

902
00:38:06,550 --> 00:38:08,716
>> La unua afero ni faros
Estas ni parolos pri tabloj.

903
00:38:08,716 --> 00:38:10,857
API datumtipoj por Dinamo.

904
00:38:10,857 --> 00:38:13,190
Kaj la unua afero vi instruos vin
rimarkos kiam vi rigardas tiun,

905
00:38:13,190 --> 00:38:17,930
se vi estas familiara kun ajna datumbazo,
datumbazoj havas vere du speco de APIs

906
00:38:17,930 --> 00:38:18,430
Mi nomus ĝin.

907
00:38:18,430 --> 00:38:21,570
Aŭ du aroj de API.

908
00:38:21,570 --> 00:38:23,840
Unu el tiuj estus
administra API.

909
00:38:23,840 --> 00:38:26,710
>> La aferoj ili prizorgi
la funkcioj de la datumbazo.

910
00:38:26,710 --> 00:38:31,340
Agordi la stokado motoron,
alĝustigo kaj aldonante tabloj.

911
00:38:31,340 --> 00:38:35,180
kreo de datumbazo
katalogoj kaj petskriboj.

912
00:38:35,180 --> 00:38:40,450
Tiuj things-- en DynamoDB, vi
havas tre mallongajn, triopoj.

913
00:38:40,450 --> 00:38:43,120
>> Do en aliaj datumbazoj,
vi eble vidos dekojn

914
00:38:43,120 --> 00:38:45,680
de komandas, de administra
komandojn, por agordi

915
00:38:45,680 --> 00:38:47,290
tiuj pliaj ebloj.

916
00:38:47,290 --> 00:38:51,234
En DynamoDB vi ne bezonas tiujn ĉar
vi ne agordi la sistemon, ni faros.

917
00:38:51,234 --> 00:38:54,150
Do la nura afero vi devas fari estas
diru al mi kio grandeco tablo mi bezonas.

918
00:38:54,150 --> 00:38:55,660
Do vi ricevas tre
limigita aro da ordonoj.

919
00:38:55,660 --> 00:38:58,618
>> Vi ricevas Krei Tablo Ĝisdatigo, Tablo,
Forigi Tablo kaj priskribu Tablo.

920
00:38:58,618 --> 00:39:01,150
Tiuj estas la nuraj aĵoj
vi bezonas por DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Vi ne bezonas stokadon
motoro konfiguro.

922
00:39:03,294 --> 00:39:04,960
Mi ne bezonas zorgi pri replicación.

923
00:39:04,960 --> 00:39:06,490
Mi ne bezonas zorgi pri sharding.

924
00:39:06,490 --> 00:39:07,800
>> Mi ne bezonas zorgi
pri iu ajn el ĉi aĵoj.

925
00:39:07,800 --> 00:39:08,740
Ni faros ĉion por vi.

926
00:39:08,740 --> 00:39:11,867
Do tio estas grandega kvanto de superkape
Tio simple levis vian teleron.

927
00:39:11,867 --> 00:39:13,200
Sekvas la stranga materio operatoroj.

928
00:39:13,200 --> 00:39:17,740
Stranga materio estas io kion ni
voki en datumbazo tio

929
00:39:17,740 --> 00:39:19,860
Krei, Ĝisdatigo, Delete operatoroj.

930
00:39:19,860 --> 00:39:24,180
Tiuj estas viaj komunaj
operacion.

931
00:39:24,180 --> 00:39:31,299
Aĵoj kiel metita ero, akiri eron, ĝisdatigo
erojn, forigi elementojn, batch query, skani.

932
00:39:31,299 --> 00:39:32,840
Se vi volas skani la tuta tablo.

933
00:39:32,840 --> 00:39:34,220
Tiri ĉiu de la tablo.

934
00:39:34,220 --> 00:39:37,130
Unu de la belaj aferoj pri DynamoDB
estas ĝi permesas paralela escanear.

935
00:39:37,130 --> 00:39:40,602
Do vi efektive povas sciigi min kiom da
fadenoj vi volas kuri en tiu skanado.

936
00:39:40,602 --> 00:39:41,810
Kaj ni povas kuri tiuj fadenoj.

937
00:39:41,810 --> 00:39:43,985
Ni povas ŝpini ke scan supren
trans multoblaj fadenoj

938
00:39:43,985 --> 00:39:49,060
tiel vi povas skani la tuta tablo
spaco tre, tre rapide en DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> La aliaj API ni havas estas
kion ni nomas nia Rojoj API.

940
00:39:51,490 --> 00:39:52,940
Ni ne tuj paroli tro
multe pri ĉi tiu momento.

941
00:39:52,940 --> 00:39:55,189
Mi havas iun enhavon poste
sur la ferdeko pri tio.

942
00:39:55,189 --> 00:39:59,910
Sed Rojoj estas vere running--
rigardante ĝin kiel la tempo ordigitaj

943
00:39:59,910 --> 00:40:01,274
kaj dispartigo ŝanĝo log.

944
00:40:01,274 --> 00:40:03,940
Ĉio okazas sur
la tablo aperas sur la rivereto.

945
00:40:03,940 --> 00:40:05,940
>> Ĉiu skribu al la tablo
Aperas sur la rivereto.

946
00:40:05,940 --> 00:40:08,370
Vi povas legi tiun rivereton, kaj
vi povas fari aferojn kun ĝi.

947
00:40:08,370 --> 00:40:10,150
Ni parolos pri kia
tipoj de aferoj vi

948
00:40:10,150 --> 00:40:13,680
fari kun la aĵoj kiel replicación,
kreanta malĉefa indeksoj.

949
00:40:13,680 --> 00:40:17,620
Ĉiaj vere malvarmeta
aĵoj vi povas fari kun tio.

950
00:40:17,620 --> 00:40:19,150
>> Datumtipoj.

951
00:40:19,150 --> 00:40:23,320
En DynamoDB ni subtenas ambaŭ ŝlosilo
valoro kaj dokumenti datumtipoj.

952
00:40:23,320 --> 00:40:26,350
Sur la maldekstra flanko de la ekrano
tie, ni havas niajn bazajn tipojn.

953
00:40:26,350 --> 00:40:27,230
Ŝlosilo valoro tipoj.

954
00:40:27,230 --> 00:40:30,040
Tiuj estas ŝnuroj,
nombroj, kaj binaroj.

955
00:40:30,040 --> 00:40:31,640
>> Do nur tri bazaj tipoj.

956
00:40:31,640 --> 00:40:33,700
Kaj tiam vi povas havi arojn de tiuj.

957
00:40:33,700 --> 00:40:37,650
Unu de la belaj aferoj pri NoSQL estas
vi povas enhavi arrays kiel propraĵoj.

958
00:40:37,650 --> 00:40:42,050
Kaj kun DynamoDB povas enhavi tabeloj
de bazaj tipoj kiel radiko proprieto.

959
00:40:42,050 --> 00:40:43,885
>> Kaj tiam ekzistas la dokumenton tipoj.

960
00:40:43,885 --> 00:40:45,510
Kiom da homoj estas familiara kun JSON?

961
00:40:45,510 --> 00:40:47,130
Vi uloj familiara kun JSON tiel?

962
00:40:47,130 --> 00:40:49,380
Ĝi estas esence Ĝavoskripto,
Objekto, Skribmaniero.

963
00:40:49,380 --> 00:40:52,510
Ĝi permesas esence
difini hierarkia strukturo.

964
00:40:52,510 --> 00:40:58,107
>> Vi povas stoki JSON dokumenton sur
DynamoDB uzante komunaj komponantoj

965
00:40:58,107 --> 00:41:00,940
aŭ konstruelementoj kiuj haveblas
en plej programlingvoj.

966
00:41:00,940 --> 00:41:03,602
Do se vi havas Java, vi estas
rigardante mapoj kaj lertaj.

967
00:41:03,602 --> 00:41:05,060
Mi povas krei objektojn kiuj areon mapo.

968
00:41:05,060 --> 00:41:08,030
A mapo kiel kernaj valoroj
stokitaj kiel propraĵoj.

969
00:41:08,030 --> 00:41:10,890
Kaj ĝi povus havi listoj de
valoroj ene de tiuj posedaĵoj.

970
00:41:10,890 --> 00:41:13,490
Vi povas stoki ĉi komplekso
hierarkia strukturo

971
00:41:13,490 --> 00:41:16,320
kiel ununura atributo
de DynamoDB eron.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Do tabloj en DynamoDB, kiel plej
NoSQL datumbazoj, tabloj havas erojn.

974
00:41:24,460 --> 00:41:26,469
En MongoDB vi farus
nomas tiujn dokumentojn.

975
00:41:26,469 --> 00:41:27,760
Kaj estus la kanapo bazo.

976
00:41:27,760 --> 00:41:28,900
Ankaŭ dokumenton datumbazo.

977
00:41:28,900 --> 00:41:29,941
Vi nomas tiujn dokumentojn.

978
00:41:29,941 --> 00:41:32,930
Dokumentoj aŭ erojn havas atributojn.

979
00:41:32,930 --> 00:41:35,850
Atributoj povas ekzisti aŭ
ne ekzistas sur la eron.

980
00:41:35,850 --> 00:41:38,520
En DynamoDB, ekzistas
unu deviga atributo.

981
00:41:38,520 --> 00:41:43,880
Nur ŝatas en rilata datumbazo,
vi havas primara ŝlosilo sur la tablo.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB havas, kion ni nomas hash ŝlosilo.

983
00:41:46,010 --> 00:41:48,280
Hash ŝlosilo devas esti unika.

984
00:41:48,280 --> 00:41:52,580
Do kiam mi difini hash tablo,
esence kion mi diras

985
00:41:52,580 --> 00:41:54,110
estas cxiu menuero devos hash ŝlosilo.

986
00:41:54,110 --> 00:41:58,520
CXia hash ŝlosilo devas esti unika.

987
00:41:58,520 --> 00:42:01,200
>> Ĉiu ero estas difinita
per tiu sola hash ŝlosilo.

988
00:42:01,200 --> 00:42:02,940
Kaj tie povas esti nur unu.

989
00:42:02,940 --> 00:42:05,820
Tio estas okej, sed ofte
kion homoj bezonas

990
00:42:05,820 --> 00:42:08,170
Estas ili volas estas tiu hash
ŝlosilo por fari iomete pli

991
00:42:08,170 --> 00:42:11,010
ol nur esti unika identigilo.

992
00:42:11,010 --> 00:42:15,240
Ofte ni volas uzi tiun hash ŝlosilo
kiel la pinta nivelo agregación sitelo.

993
00:42:15,240 --> 00:42:19,160
Kaj la vojo ni fari tion estas per
aldonante kion ni nomas vicon ŝlosilo.

994
00:42:19,160 --> 00:42:22,460
>> Do se ĝi estas hash nur
tablo, tiu devas esti unika.

995
00:42:22,460 --> 00:42:27,040
Se ĝi estas hash kaj gamo tablo, la
kombino de la hash kaj la gamo

996
00:42:27,040 --> 00:42:28,640
devas esti unika.

997
00:42:28,640 --> 00:42:30,110
Do pensu pri tio ĉi vojo.

998
00:42:30,110 --> 00:42:32,140
Se mi havas forumon.

999
00:42:32,140 --> 00:42:39,010
Kaj la formo havas temojn, ĝi havas
afiŝoj, kaj ĝi havas respondojn.

1000
00:42:39,010 --> 00:42:42,630
>> Do mi havu hash
ŝlosilo, kiu estas la temo ID.

1001
00:42:42,630 --> 00:42:46,650
Kaj mi povus havi gamon ŝlosilo,
kiu estas la respondo ID.

1002
00:42:46,650 --> 00:42:49,650
KE vojo se mi volas ricevi ĉiujn
respondojn por aparta temo,

1003
00:42:49,650 --> 00:42:52,370
Mi povas nur konsulti la hash.

1004
00:42:52,370 --> 00:42:55,190
Mi povas nur diri al mi ĉion
la erojn, kiuj havas tiun hash.

1005
00:42:55,190 --> 00:43:01,910
Kaj mi tuj instigi cxiun demandon
aŭ afiŝi por tiu aparta temo.

1006
00:43:01,910 --> 00:43:03,910
Tiuj supro nivelo agregaciones
estas tre gravaj.

1007
00:43:03,910 --> 00:43:07,370
Ili apogas la primara aliro
desegnon de la apliko.

1008
00:43:07,370 --> 00:43:09,420
Ĝenerale parolante, tiu
kion ni volas fari.

1009
00:43:09,420 --> 00:43:11,780
Ni volas ke table--
kiel vi ŝarĝi la tablo,

1010
00:43:11,780 --> 00:43:16,640
ni volas strukturi la datumoj
ene la tablo tiel

1011
00:43:16,640 --> 00:43:20,140
ke la apliko povas tre
rapide elsxuti tiujn rezultojn.

1012
00:43:20,140 --> 00:43:24,510
Kaj ofte la maniero fari tion estas
subteni tiujn agregaciones kiel ni

1013
00:43:24,510 --> 00:43:25,650
enmeti la datumojn.

1014
00:43:25,650 --> 00:43:31,110
Esence, ni diskonigi la datumoj
en la helan sitelo kiel ĝi envenas.

1015
00:43:31,110 --> 00:43:35,210
>> Gamo klavoj permesas kunulinon hash
klavoj devas esti egaleco.

1016
00:43:35,210 --> 00:43:39,490
Kiam mi konsulti hash, mi devas diri
donu al mi hash kiu egalas ĉi.

1017
00:43:39,490 --> 00:43:41,950
Kiam mi konsulti gamo, Mi
povas diri al mi vicon

1018
00:43:41,950 --> 00:43:47,040
kiu uzas ian
riĉa operatoro kiun ni apogas.

1019
00:43:47,040 --> 00:43:49,200
Donu ĉiujn erojn por hash.

1020
00:43:49,200 --> 00:43:52,520
Ĉu egala, pli granda ol,
malpli ol, faras ĝi komenci,

1021
00:43:52,520 --> 00:43:54,145
Ĉu ĝi ekzistas inter tiuj du valoroj?

1022
00:43:54,145 --> 00:43:56,811
Tiuj tipoj de gamo demandoj
ke ni estas ĉiam interesita en.

1023
00:43:56,811 --> 00:43:59,650
Nun unu afero pri datumoj, kiam
vi rigardas aliranta datumon, kiam

1024
00:43:59,650 --> 00:44:02,360
vi aliri la datumojn, ĝi estas
ĉiam pri kungregigxinte.

1025
00:44:02,360 --> 00:44:05,770
Ĉiam pri la rekordojn
ke estas rilatigitaj kun ĉi tiu.

1026
00:44:05,770 --> 00:44:10,390
Donu al mi ĉion tie that's-- ĉiuj
la transakcioj sur ĉi kreditkarto

1027
00:44:10,390 --> 00:44:12,500
por la lasta monato.

1028
00:44:12,500 --> 00:44:13,960
Tio kungregigxinte.

1029
00:44:13,960 --> 00:44:17,490
>> Preskaŭ ĉio vi faras en la
datumbazo estas ia agregaĵo.

1030
00:44:17,490 --> 00:44:21,530
Do povante povi difini
tiuj rubujoj kaj doni al vi tiujn gamo

1031
00:44:21,530 --> 00:44:24,950
ecoj por povi konsulti sur,
tiuj riĉaj demandoj subteni multajn,

1032
00:44:24,950 --> 00:44:27,165
multaj, multaj apliko aliro ŝablonoj.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Do la alia afero la hash ŝlosilo
faras estas ĝi donas al ni meĥanismo

1035
00:44:35,000 --> 00:44:37,740
por povi disvastigi la datumoj ĉirkaŭ.

1036
00:44:37,740 --> 00:44:40,390
NoSQL datumbazoj funkcias plej
kiam la datumoj estas egale

1037
00:44:40,390 --> 00:44:41,740
distribuis trans la areto.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Kiom da homoj estas familiara
kun hashing algoritmoj?

1040
00:44:47,050 --> 00:44:49,860
Kiam mi diras hash kaj hashing--
ĉar Regionoj algoritmo

1041
00:44:49,860 --> 00:44:54,140
Estas maniero de povi generi
hazarda valoro de iu antaŭfiksita valoro.

1042
00:44:54,140 --> 00:44:59,300
Do en ĉi tiu aparta kazo, la
hash algoritmo ni kuras estas ND 5 bazita.

1043
00:44:59,300 --> 00:45:04,765
>> Kaj se mi havas ID kaj ĉi
Estas mia hash ŝlosilon, mi havas 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Kiam mi kuras la hash algoritmo,
ĝi tuj revenos kaj diros:

1045
00:45:07,390 --> 00:45:10,800
bone 1 egalas 7B, 2
egalas 48, 3 egalas KD.

1046
00:45:10,800 --> 00:45:13,092
Ili disvastiĝis tra la tuta ŝlosilo spaco.

1047
00:45:13,092 --> 00:45:14,050
Kaj kial vi faru tion?

1048
00:45:14,050 --> 00:45:17,120
Ĉar kiu certigas ke mi povas
metis la rekordojn trans multoblaj nodoj.

1049
00:45:17,120 --> 00:45:19,574
>> Se mi faras tiun
incrementally, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Kaj mi havas hash gamo kiu
kuroj en ĉi tiu aparta kazo,

1051
00:45:21,990 --> 00:45:24,785
malgranda krada spaco,
ĝi kuras de 00 al FF,

1052
00:45:24,785 --> 00:45:27,951
tiam la rekordojn tuj enveni
kaj ili tuj iru 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
Kio okazas?

1055
00:45:31,800 --> 00:45:34,860
Ĉiu insert tuj la sama nodo.

1056
00:45:34,860 --> 00:45:36,070
Vi vidas kion mi volas diri?

1057
00:45:36,070 --> 00:45:40,910
>> Ĉar kiam mi disiĝis la spaco,
kaj Mi etendis tiujn rekordojn trans,

1058
00:45:40,910 --> 00:45:45,950
kaj mi vandon, mi tuj diros
dispartigo 1 havas ŝlosilon spaco 0 al 54.

1059
00:45:45,950 --> 00:45:47,720
Dispartigo 2 estas 55 al 89.

1060
00:45:47,720 --> 00:45:49,780
Dispartigo 3 estas AA al ff.

1061
00:45:49,780 --> 00:45:53,740
Do se mi uzas lineare pliigante
IDs, vi povas vidi kio okazas.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, ĉiuj vojo ĝis 54.

1063
00:45:57,410 --> 00:46:00,030
Do kiel mi martelante la
rekordojn en la sistemo,

1064
00:46:00,030 --> 00:46:02,030
ĉiu finas tuj unu nodo.

1065
00:46:02,030 --> 00:46:03,160
>> Tio ne bona.

1066
00:46:03,160 --> 00:46:04,820
Tio estas antipattern.

1067
00:46:04,820 --> 00:46:08,760
En MongoDB ili havas tiun problemon
se vi ne uzas hash ŝlosilo.

1068
00:46:08,760 --> 00:46:11,325
MongoDB donas al vi la eblon
de hashing la ŝlosilo valoro.

1069
00:46:11,325 --> 00:46:13,950
Vi devas ĉiam fari tion, se
vi uzas pliigante hash

1070
00:46:13,950 --> 00:46:17,380
ŝlosilo en MongoDB, aŭ vi estos
najlante ĉiu skribu al unu nodon,

1071
00:46:17,380 --> 00:46:21,290
kaj vi estos limitante
via skribi traigivo malbone.

1072
00:46:21,290 --> 00:46:24,896
>> Spektantaro: Ĉu Al9 169 en dekuma?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Jes, ĝi estas
ie ĉirkaŭe.

1074
00:46:28,450 --> 00:46:29,950
Al9, mi ne scias.

1075
00:46:29,950 --> 00:46:32,200
Vi devus ricevi mia duuma
al dekuma kalkulilo.

1076
00:46:32,200 --> 00:46:34,237
Mia cerbo ne funkcias tiel.

1077
00:46:34,237 --> 00:46:36,320
Spektantaro: Nur rapida unu
de via Mongo komentoj.

1078
00:46:36,320 --> 00:46:39,530
Tia estas la objekto ID kiu venas
denaske kun Mongo fari tion?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Ĉu ĝi farus tion?

1081
00:46:41,470 --> 00:46:42,970
Se vi specifas ĝin.

1082
00:46:42,970 --> 00:46:45,030
Kun MongoDB, vi havas la eblon.

1083
00:46:45,030 --> 00:46:48,930
Vi povas specify-- ĉiu dokumento en
MongoDB devas havi substreko ID.

1084
00:46:48,930 --> 00:46:50,300
Tio estas la unika valoro.

1085
00:46:50,300 --> 00:46:55,240
>> En MongoDB vi povas entajpi
ĉu hash aŭ ne.

1086
00:46:55,240 --> 00:46:56,490
Ili simple donis al vi la eblon.

1087
00:46:56,490 --> 00:46:58,198
Se vi scias ke ĝi estas
hazarda, neniu problemo.

1088
00:46:58,198 --> 00:46:59,640
Vi ne bezonas fari tion.

1089
00:46:59,640 --> 00:47:04,260
Se vi scias, ke ĝi ne estas hazardo, ke
ĝi estas pliigante, tiam faru la hash.

1090
00:47:04,260 --> 00:47:06,880
>> Nun la afero pri
hashing, iam vi hash

1091
00:47:06,880 --> 00:47:08,800
a value-- kaj tiu estas
kial hash ŝlosiloj estas ĉiam

1092
00:47:08,800 --> 00:47:13,740
solaj demandoj, ĉar mi ŝanĝis
la valoro, nun mi ne povas fari vicon mendo.

1093
00:47:13,740 --> 00:47:15,640
Mi ne povas diri estas ĉi
inter tio aux,

1094
00:47:15,640 --> 00:47:20,800
ĉar la hash valoro ne tuj
esti ekvivalenta al la reala valoro.

1095
00:47:20,800 --> 00:47:24,570
Do kiam vi hash ke
ŝlosilo, ĝi estas egaleco nur.

1096
00:47:24,570 --> 00:47:28,700
Jen kial en DynamoDB hash ŝlosilo
demandoj estas ĉiam egaleco nur.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Do nun en gamo key--
kiam mi aldonas ke gamo ŝlosilo,

1099
00:47:34,700 --> 00:47:38,180
tiuj gamo klavo rekordojn ĉiuj enveni kaj
ili akiras entenita sur la sama dispartigo.

1100
00:47:38,180 --> 00:47:42,430
Do, ili estas tre rapide, facile
retrieved ĉar tiu estas la hash,

1101
00:47:42,430 --> 00:47:43,220
tio estas la gamo.

1102
00:47:43,220 --> 00:47:44,928
Kaj vi vidas ĉion
kun la sama hash

1103
00:47:44,928 --> 00:47:48,550
gets stokitaj en la sama subdisko spaco.

1104
00:47:48,550 --> 00:47:53,889
Vi povas uzi tiun gamon ŝlosilo por helpi
lokalizi viajn datumojn proksime al lia patro.

1105
00:47:53,889 --> 00:47:55,180
Do kion mi vere faras ĉi tie?

1106
00:47:55,180 --> 00:47:57,320
Jen unu al multaj rilato.

1107
00:47:57,320 --> 00:48:01,490
La interrilato inter hash ŝlosilo
kaj la gamo-klavo unu al multaj.

1108
00:48:01,490 --> 00:48:03,490
Mi povas havi multoblajn hash klavoj.

1109
00:48:03,490 --> 00:48:07,610
Mi povas nur havi multoblajn gamo
ŝlosilojn ene ĉiu krada ŝlosilo.

1110
00:48:07,610 --> 00:48:11,910
>> La hash difinas la gepatro,
la gamo difinas la infanoj.

1111
00:48:11,910 --> 00:48:15,240
Do vi povas vidi ke estas analoga tie
inter la rilata konstrukcio

1112
00:48:15,240 --> 00:48:18,840
kaj la samajn tipojn de
konstruas en NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Homoj parolas pri
NoSQL kiel nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Ne nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Datumoj ĉiam havas interrilatojn.

1116
00:48:24,680 --> 00:48:28,172
Tiuj rilatoj ĵus
modelan malsame.

1117
00:48:28,172 --> 00:48:29,880
Ni parolu iomete
bita pri fortikeco.

1118
00:48:29,880 --> 00:48:34,860
Kiam vi skribas al DynamoDB, skribas
ĉiam triopa multobliĝas.

1119
00:48:34,860 --> 00:48:37,550
Signifanta ke ni havas tri AZ a.

1120
00:48:37,550 --> 00:48:39,160
AZ informojn estas Havebleco Zonoj.

1121
00:48:39,160 --> 00:48:43,430
Vi povas pensi pri Havebleco
Zono kiel datumoj centro

1122
00:48:43,430 --> 00:48:45,447
aŭ kolekton de datumoj centroj.

1123
00:48:45,447 --> 00:48:47,780
Tiuj aferoj estas geografie
izolitaj unuj de aliaj

1124
00:48:47,780 --> 00:48:51,610
trans malsamaj kulpo zonoj, trans
malsamaj potenco kradoj kaj inundebenaĵoj.

1125
00:48:51,610 --> 00:48:54,510
Misfunkciado en unu AZ ne
tuj prenonta alian.

1126
00:48:54,510 --> 00:48:56,890
Ili estas ankaŭ ligita
kune kun malhela fibro.

1127
00:48:56,890 --> 00:49:01,240
Ĝi apogas unu sub- 1
milisegundo latencia inter AZS.

1128
00:49:01,240 --> 00:49:05,390
Do reala tempo datumoj replications
hábil en mult AZS.

1129
00:49:05,390 --> 00:49:09,990
>> Kaj ofte multi AZ deplojoj
renkonti la alta disponibilidad postuloj

1130
00:49:09,990 --> 00:49:12,930
de plej dungistaj organizoj.

1131
00:49:12,930 --> 00:49:16,139
Do DynamoDB sternigxos
trans tri AZS defaŭlte.

1132
00:49:16,139 --> 00:49:19,430
Ni nur tuj scio la registran
kiam du el tiuj tri nodoj revenos

1133
00:49:19,430 --> 00:49:21,470
kaj diru: Jes, mi havas ĝin.

1134
00:49:21,470 --> 00:49:22,050
Kial estas tio?

1135
00:49:22,050 --> 00:49:25,950
Ĉar sur la legado flanko ni estas nur
tuj donos al vi la datumojn reen kiam

1136
00:49:25,950 --> 00:49:27,570
ni akiru ĝin el du nodoj.

1137
00:49:27,570 --> 00:49:30,490
>> Se mi repliki trans
tri, kaj mi legas el du,

1138
00:49:30,490 --> 00:49:32,840
Mi ĉiam garantiita
havi almenaŭ unu

1139
00:49:32,840 --> 00:49:35,720
de tiuj legas esti la
plej aktualan kopion de datumoj.

1140
00:49:35,720 --> 00:49:38,340
Tion faras DynamoDB konsekvenca.

1141
00:49:38,340 --> 00:49:42,450
Nun vi povas elekti turni
tiuj konsekvenca legas for.

1142
00:49:42,450 --> 00:49:45,070
Tiuokaze mi tuj diru,
Mi nur legis de unu nodo.

1143
00:49:45,070 --> 00:49:47,430
Kaj mi ne povas garantii ĝi tuj
esti la plej aktualaj datumoj.

1144
00:49:47,430 --> 00:49:49,450
>> Do se skribi estas eniranta,
ĝi ne multoblighas tamen,

1145
00:49:49,450 --> 00:49:50,360
vi tuj akiri tiun kopion.

1146
00:49:50,360 --> 00:49:52,220
Tio estas eventuale konsekvenca legita.

1147
00:49:52,220 --> 00:49:54,640
Kaj kion tio estas estas duono la kosto.

1148
00:49:54,640 --> 00:49:56,140
Do tiu estas multon pripensindan.

1149
00:49:56,140 --> 00:50:00,160
Kiam vi legas el DynamoDB, kaj
vi starigi vian legita kapablo

1150
00:50:00,160 --> 00:50:04,430
ekzemplerojn, se vi elektas finfine
konsekvenca legas, ĝi estas multe pli malmultekosta,

1151
00:50:04,430 --> 00:50:06,010
ĝi estas proksimume duono de la kosto.

1152
00:50:06,010 --> 00:50:09,342
>> Kaj tiel ĝi savas vin monon.

1153
00:50:09,342 --> 00:50:10,300
Sed tio estas via elekto.

1154
00:50:10,300 --> 00:50:12,925
Se vi volas konsekvencan legado aŭ
oni eventuale konsekvenca legita.

1155
00:50:12,925 --> 00:50:15,720
Tio estas io kion vi povas elekti.

1156
00:50:15,720 --> 00:50:17,659
>> Ni parolu pri indeksojn.

1157
00:50:17,659 --> 00:50:19,450
Do ni menciis ke
pinta nivelo agregaĵo.

1158
00:50:19,450 --> 00:50:23,720
Ni havas hash klavoj, kaj
ni havas gamon klavoj.

1159
00:50:23,720 --> 00:50:24,320
Tio bonas.

1160
00:50:24,320 --> 00:50:26,950
Kaj tio estas la ĉefa tablo, mi
akiris unu hash ŝlosilon, mi akiris unu gamo ŝlosilo.

1161
00:50:26,950 --> 00:50:27,783
>> Kion tio signifas?

1162
00:50:27,783 --> 00:50:30,410
Mi havas unu atributo kiu mi
povas kuri riĉa sercxoj kontraŭ.

1163
00:50:30,410 --> 00:50:31,800
Ĝi estas la intervalo ŝlosilo.

1164
00:50:31,800 --> 00:50:35,530
La aliaj atributoj sur tiu item--
Mi povas filtri tiujn atributojn.

1165
00:50:35,530 --> 00:50:40,050
Sed mi ne povas fari tion kiel, ĝi
komencas kun, aŭ superas.

1166
00:50:40,050 --> 00:50:40,820
>> Kiel mi faru tion?

1167
00:50:40,820 --> 00:50:42,860
Mi kreos indekson.

1168
00:50:42,860 --> 00:50:45,340
Ekzistas du tipoj de
indeksoj en DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Indico estas vere
alia vido de la tablo.

1170
00:50:49,002 --> 00:50:50,490
Kaj la loka sekundara indekso.

1171
00:50:50,490 --> 00:50:51,781
>> La unua unu ni parolos pri.

1172
00:50:51,781 --> 00:50:57,740
Do loka duarangaj estas kunvivis
sur la sama dispartigo kiel la datumoj.

1173
00:50:57,740 --> 00:51:00,240
Kaj kiel tia, ili estas sur
la sama fizika nodo.

1174
00:51:00,240 --> 00:51:01,780
Ili estas kion ni nomas konsekvenca.

1175
00:51:01,780 --> 00:51:04,599
Signifo, ili konfesos
la registran kune kun la tablo.

1176
00:51:04,599 --> 00:51:06,890
Kiam la registran envenas,
ni skribas per la indekso.

1177
00:51:06,890 --> 00:51:09,306
Ni skribu al la tablo,
kaj tiam ni agnoskos.

1178
00:51:09,306 --> 00:51:10,490
Do jen konsekvencaj.

1179
00:51:10,490 --> 00:51:13,174
Iam la registran estis
agnoskita de la tablo,

1180
00:51:13,174 --> 00:51:15,090
ĝi estas garantiita ke la
loka sekundara indekso

1181
00:51:15,090 --> 00:51:18,380
havos la saman vizion de datumoj.

1182
00:51:18,380 --> 00:51:22,390
Sed kion ili permesas fari estas
difini alternativan gamo klavoj.

1183
00:51:22,390 --> 00:51:25,260
>> Devas uzi la saman kradon
ŝlosilo kiel la primara tablo

1184
00:51:25,260 --> 00:51:29,050
ĉar ili ko-lokalizitaj sur la
sama vando, kaj ili estas konsekvenca.

1185
00:51:29,050 --> 00:51:33,110
Sed mi povas krei indekson
kun malsamaj gamo klavoj.

1186
00:51:33,110 --> 00:51:41,590
Do ekzemple, se mi havus fabrikanto
kiu havis krudan partoj tablo venon.

1187
00:51:41,590 --> 00:51:44,590
Kaj krudaj partoj enveni, kaj
ili estas agregita per asembleo.

1188
00:51:44,590 --> 00:51:46,840
Kaj eble tie estas revokon.

1189
00:51:46,840 --> 00:51:50,240
>> Ajna parto kiu estis farita de tiu
Fabrikejo de post tiu dato,

1190
00:51:50,240 --> 00:51:52,840
Mi bezonas tiri de mia linio.

1191
00:51:52,840 --> 00:51:55,950
Mi povas ŝpini indekso
ke serĉus,

1192
00:51:55,950 --> 00:52:00,760
agregi sur la dato de
fabrikado de tiu aparta parto.

1193
00:52:00,760 --> 00:52:03,930
Do se mia pinta nivelo tablo estis
Jam hashed por fabrikanto,

1194
00:52:03,930 --> 00:52:07,655
Eble estis aranĝita sur parto ID, mi
povas krei indekson off ke tablo

1195
00:52:07,655 --> 00:52:11,140
kiel hashed por fabrikanto kaj
gamis sur dato de fabrikado.

1196
00:52:11,140 --> 00:52:14,490
Kaj aliflanken mi povus diri, ke io
estis fabrikitaj inter tiuj datoj,

1197
00:52:14,490 --> 00:52:16,804
Mi bezonas tiri el la linio.

1198
00:52:16,804 --> 00:52:18,220
Do jen loka sekundara indekso.

1199
00:52:18,220 --> 00:52:22,280
>> Tiuj havas la efekton de
limigi viajn hash ŝlosilo spaco.

1200
00:52:22,280 --> 00:52:24,360
Ĉar ili kunekzistis
sur la sama stokado nodo,

1201
00:52:24,360 --> 00:52:26,860
Ili limigi la hash ŝlosilo
spaco por 10 gigabajtoj.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, sub la
tabloj, estos dispartigo

1203
00:52:28,950 --> 00:52:31,380
via tablo ĉiu 10 gigabajtoj.

1204
00:52:31,380 --> 00:52:34,760
Kiam vi metos 10 koncertoj de datumoj en ni
iri [PHH], kaj ni aldonas alia nodo.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Ni ne fendi la LSI
trans multaj vandoj.

1207
00:52:42,070 --> 00:52:43,200
Ni disiĝis la tablo.

1208
00:52:43,200 --> 00:52:44,679
Sed ni ne fendi la LSI.

1209
00:52:44,679 --> 00:52:46,470
Do jen io
Gravas kompreni

1210
00:52:46,470 --> 00:52:50,070
estas se vi faras tre,
tre, tre grandaj aldonitaj,

1211
00:52:50,070 --> 00:52:53,860
tiam vi tuj estos limigita
10 gigabajtoj sur via LSIs.

1212
00:52:53,860 --> 00:52:56,640
>> Se tio estas la kazo, ni povas
uzi tutmonda duarangaj.

1213
00:52:56,640 --> 00:52:58,630
Tutmondaj duarangaj estas
vere alia tablo.

1214
00:52:58,630 --> 00:53:01,720
Ekzistas tute ekstere al
flanke de via primara tablo.

1215
00:53:01,720 --> 00:53:04,680
Kaj ili permesos min trovi
tute malsama strukturo.

1216
00:53:04,680 --> 00:53:08,010
Do pensu pri ĝi kiel datumo estas estanta insertita
en du malsamaj tabloj, strukturita

1217
00:53:08,010 --> 00:53:09,220
en du malsamaj manieroj.

1218
00:53:09,220 --> 00:53:11,360
>> Mi povas difini tutece
malsama hash ŝlosilo.

1219
00:53:11,360 --> 00:53:13,490
Mi povas difini tutece
malsamaj gamo ŝlosilo.

1220
00:53:13,490 --> 00:53:15,941
Kaj mi povas kuri ĉi
tute sendepende.

1221
00:53:15,941 --> 00:53:18,190
Kiel Efektive, mi havas
provizis mia legado kapablo

1222
00:53:18,190 --> 00:53:21,090
kaj skribu kapablo por mia
tutmonda malĉefa indeksoj

1223
00:53:21,090 --> 00:53:24,240
tute sendepende
de mia primara tablo.

1224
00:53:24,240 --> 00:53:26,640
Se mi difinus ke indekso, mi diras
ĝi kiom legi kaj skribi

1225
00:53:26,640 --> 00:53:28,610
kapacito ĝi tuj uzos.

1226
00:53:28,610 --> 00:53:31,490
>> Kaj ke estas aparta
de mia primara tablo.

1227
00:53:31,490 --> 00:53:35,240
Nun ambaŭ de la indeksoj permesas nin
ne nur difini hash kaj gamo ŝlosilojn,

1228
00:53:35,240 --> 00:53:38,610
sed ili permesos nin
projekti aldonaj valoroj.

1229
00:53:38,610 --> 00:53:44,950
Do se mi volas legi for la indekso,
kaj mi volas ricevi iun aron de datumoj,

1230
00:53:44,950 --> 00:53:48,327
Mi ne bezonas reiri al la ĉefa
tablo akiri la aldonan atributoj.

1231
00:53:48,327 --> 00:53:50,660
Mi povas projekti tiuj aldonaj
atribuas al la tablo

1232
00:53:50,660 --> 00:53:53,440
por apogi la aliro ŝablono.

1233
00:53:53,440 --> 00:53:57,700
Mi scias ni probable akiranta en kelkaj
vere, really-- akiranta en la trudherboj

1234
00:53:57,700 --> 00:53:58,910
tie sur kelkaj de ĉi aĵoj.

1235
00:53:58,910 --> 00:54:02,725
Nun mi atingis drivus el tiu.

1236
00:54:02,725 --> 00:54:07,320
>> Spektantaro: [inaudible]
--table ŝlosilo signifis estis hash?

1237
00:54:07,320 --> 00:54:08,840
La originala hash?

1238
00:54:08,840 --> 00:54:09,340
Mult-latoj?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Jes.

1240
00:54:10,200 --> 00:54:11,070
Jes.

1241
00:54:11,070 --> 00:54:15,260
La tablo ŝlosilo esence
markas reen al la artikolo.

1242
00:54:15,260 --> 00:54:19,280
Do indekso estas puntero al
la originalo erojn sur la tablon.

1243
00:54:19,280 --> 00:54:22,910
Nun vi povas elekti konstrui
indekso kiu nur havas la tablo ŝlosilo,

1244
00:54:22,910 --> 00:54:24,840
kaj neniu aliaj propraĵoj.

1245
00:54:24,840 --> 00:54:26,570
Kaj kial povus mi fari tion?

1246
00:54:26,570 --> 00:54:28,570
Nu, eble mi havas tre grandajn erojn.

1247
00:54:28,570 --> 00:54:31,660
>> Mi vere nur bezonas scii which--
mia aliro padrono povus diri,

1248
00:54:31,660 --> 00:54:33,760
kiu erojn enhavas tiun proprieton?

1249
00:54:33,760 --> 00:54:35,780
Ne bezonas resendi la eron.

1250
00:54:35,780 --> 00:54:37,800
Mi nur bezonas scii
kiu erojn enhavi ĝin.

1251
00:54:37,800 --> 00:54:40,700
Do vi povas konstrui indeksojn
ke nur havos la tablo ŝlosilo.

1252
00:54:40,700 --> 00:54:43,360
>> Sed tio estas unuavice kio
indekso en datumbazo estas por.

1253
00:54:43,360 --> 00:54:46,280
Ĝi estas por povi rapide
identigi kiu registras,

1254
00:54:46,280 --> 00:54:49,470
kiuj vicoj, kiuj
erojn en la tablo havas

1255
00:54:49,470 --> 00:54:51,080
la propraĵoj kiujn mi sercxas.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIs, do kiel ili laboras?

1258
00:54:54,860 --> 00:54:58,340
GSIs esence estas nesinkrona.

1259
00:54:58,340 --> 00:55:02,570
La ĝisdatigo venas en la tablon,
tablo estas poste nesamtempe ĝisdatigita

1260
00:55:02,570 --> 00:55:03,720
ĉiuj viajn GSIs.

1261
00:55:03,720 --> 00:55:06,680
Jen kial GSIs estas
eventuale konsekvenca.

1262
00:55:06,680 --> 00:55:09,440
>> Estas grave noti, ke
kiam vi konstruado GSIs,

1263
00:55:09,440 --> 00:55:13,110
kaj komprenu vi kreas
alia dimensio de aggregation--

1264
00:55:13,110 --> 00:55:16,594
nun diru bona ekzemplo
tie estas fabrikanto.

1265
00:55:16,594 --> 00:55:19,260
Mi kredas ke mi povus esti parolita pri
medicina aparato fabrikanto.

1266
00:55:19,260 --> 00:55:23,870
Medicina aparato fabrikantoj
ofte havas serializada partoj.

1267
00:55:23,870 --> 00:55:28,070
La partoj kiuj iras en
kokso anstataŭas ĉiuj

1268
00:55:28,070 --> 00:55:30,200
havi iom serian numeron sur ilin.

1269
00:55:30,200 --> 00:55:33,584
Ili povus havi milionojn kaj
milionoj kaj miliardoj da partoj

1270
00:55:33,584 --> 00:55:35,000
en ĉiuj mekanismoj kiuj ili sxipo.

1271
00:55:35,000 --> 00:55:37,440
Nu, ili bezonas por aldoni sub
malsamaj dimensioj, ĉiuj partoj

1272
00:55:37,440 --> 00:55:39,520
en asembleo, ĉiuj
partoj, faritajn

1273
00:55:39,520 --> 00:55:41,670
je certa linio, ĉiuj
la partoj kiuj venis

1274
00:55:41,670 --> 00:55:44,620
en el certa Fabrikejo
je certa dato.

1275
00:55:44,620 --> 00:55:47,940
Kaj tiuj aldonitaj kelkfoje
leviĝi en la miliardoj.

1276
00:55:47,940 --> 00:55:50,550
>> Do mi laboras kun kelkaj el
tiuj uloj, kiuj suferas

1277
00:55:50,550 --> 00:55:53,156
ĉar ili kreas
tiuj ginormous agregaciones

1278
00:55:53,156 --> 00:55:54,280
en siaj duarangaj indeksoj.

1279
00:55:54,280 --> 00:55:57,070
Ili povus havi krudan partoj
tablo, kiu venas kiel hash nur.

1280
00:55:57,070 --> 00:55:59,090
Ĉiu parto havas unikan serian numeron.

1281
00:55:59,090 --> 00:56:00,975
Mi uzas la seria numero kiel la hash.

1282
00:56:00,975 --> 00:56:01,600
Ĝi estas bela.

1283
00:56:01,600 --> 00:56:04,160
Mia krudaj datumoj tablo sternigxos
ĉiuj trans la ŝlosilo spaco.

1284
00:56:04,160 --> 00:56:05,930
Mia [? skribi?]
[? ingestión?] estas timinda.

1285
00:56:05,930 --> 00:56:07,876
Mi prenas multajn datumojn.

1286
00:56:07,876 --> 00:56:09,500
Tiam kion ili faras estas ili krei GSI.

1287
00:56:09,500 --> 00:56:12,666
Kaj mi diras, vi scias kion mi bezonas vidi
ĉiuj partoj por ĉi tiu fabrikanto.

1288
00:56:12,666 --> 00:56:15,060
Nu, subite mi
prenante miliardo vicoj,

1289
00:56:15,060 --> 00:56:17,550
kaj plenigos ilin sur
unu nodon, ĉar kiam

1290
00:56:17,550 --> 00:56:21,170
Mi aldonas kiel la
Fabrikejo de ID kiel la hash,

1291
00:56:21,170 --> 00:56:25,410
kaj parto nombro kiel la gamo,
tiam ĉiuj el la subita mi estas

1292
00:56:25,410 --> 00:56:30,530
metante miliardo partoj en kio
tiu fabrikanto savis min.

1293
00:56:30,530 --> 00:56:34,447
>> Tio povas kaŭzi multajn
de premo sur la GSI,

1294
00:56:34,447 --> 00:56:36,030
denove, ĉar mi martelante unu nodo.

1295
00:56:36,030 --> 00:56:38,350
Mi estas metanta ĉiuj tiuj
enmetas en unu nodo.

1296
00:56:38,350 --> 00:56:40,940
Kaj tio estas vera problema uzo kazo.

1297
00:56:40,940 --> 00:56:43,479
Nun, mi havas bonan dezajnon
mastron por kiom vi evitas tion.

1298
00:56:43,479 --> 00:56:45,770
Kaj tio estas unu el la problemoj
ke mi ĉiam laboros kun.

1299
00:56:45,770 --> 00:56:49,590
Sed kio okazas, estas la GSI povus
ne havas sufiĉan kapablon registran

1300
00:56:49,590 --> 00:56:52,330
povi puŝi ĉiuj tiuj
vicoj en ununuran nodon.

1301
00:56:52,330 --> 00:56:55,390
Kaj kio okazas tiam estas la
primaria, la kliento tablo

1302
00:56:55,390 --> 00:57:00,180
la primara tablo estos throttled
ĉar la GSI ne povas teni supre.

1303
00:57:00,180 --> 00:57:02,980
Do mia insert imposto
fali sur la primara tablo

1304
00:57:02,980 --> 00:57:06,230
kiel mia GSI provas teni supre.

1305
00:57:06,230 --> 00:57:08,850
>> Bone, do GSI a, LSI-a,
kiu mi uzu?

1306
00:57:08,850 --> 00:57:12,290
LSI informojn estas konsekvenca.

1307
00:57:12,290 --> 00:57:13,750
GSI informojn estas eventuale konsekvenca.

1308
00:57:13,750 --> 00:57:17,490
Se tio estas bone, mi rekomendus uzi
GSI, ili estas multe pli fleksebla.

1309
00:57:17,490 --> 00:57:20,270
LSI-a povas esti modelita kiel GSI.

1310
00:57:20,270 --> 00:57:27,040
Kaj se la datumoj grandeco po hash klavoj en
via kolekto superas 10 gigabajtoj,

1311
00:57:27,040 --> 00:57:31,050
tiam vi tuj volas uzi tiun
GSI ĉar ĝi estas nur malfacila limo.

1312
00:57:31,050 --> 00:57:32,035
>> Bone, do grimpita.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Traigivo en Dinamo DB, vi
ladskatolon provizo [inaudible]

1315
00:57:37,460 --> 00:57:38,680
Throughput al tablo.

1316
00:57:38,680 --> 00:57:42,740
Ni havas klientojn kiuj havas
provizis 60 billion--

1317
00:57:42,740 --> 00:57:45,970
faras 60 miliardoj petoj, regule
kurante al super miliono petoj

1318
00:57:45,970 --> 00:57:47,790
sekunde sur niaj tabloj.

1319
00:57:47,790 --> 00:57:50,360
Tie estas vere neniu
teoria limo por kiom

1320
00:57:50,360 --> 00:57:53,730
kaj kiom rapide la tablo
povas kuri en Dinamo DB.

1321
00:57:53,730 --> 00:57:55,920
Estas iuj molaj
limoj en via konto

1322
00:57:55,920 --> 00:57:58,170
ke ni metu tien por
ke vi ne freneziĝos.

1323
00:57:58,170 --> 00:58:00,070
Se vi volas pli ol
ke, ne estas problemo.

1324
00:58:00,070 --> 00:58:00,820
Vi venas informi nin.

1325
00:58:00,820 --> 00:58:02,810
Ni turnas supren la ciferplaton.

1326
00:58:02,810 --> 00:58:08,210
>> Ĉiu konto estas limigita al iu nivelo
en ĉiu servo, nur la batilon

1327
00:58:08,210 --> 00:58:11,920
do la homoj ne freneziĝos
akiri sin en problemo.

1328
00:58:11,920 --> 00:58:12,840
Neniu limo en grandeco.

1329
00:58:12,840 --> 00:58:14,940
Vi povas meti ajna nombro
da eroj sur tablo.

1330
00:58:14,940 --> 00:58:17,620
La grandeco de ero estas
limigita al 400 kilobajtoj ĉiu,

1331
00:58:17,620 --> 00:58:20,050
ke estus elemento ne la atributoj.

1332
00:58:20,050 --> 00:58:24,200
Do la sumo de ĉiuj atributoj
estas limigita al 400 kilobajtoj.

1333
00:58:24,200 --> 00:58:27,300
Kaj cetere, ni havas
ke iom LSI temo

1334
00:58:27,300 --> 00:58:30,405
kun la 10 gigabajto limo po hash.

1335
00:58:30,405 --> 00:58:33,280
Publiko: Malgrandaj numeron, mi mankas
kion vi estas diranta al mi, ke is--

1336
00:58:33,280 --> 00:58:36,830
Publiko: Oh, 400 kilobajto
Estas la maksimuma grandeco por ero.

1337
00:58:36,830 --> 00:58:39,570
Do ero havas ĉiujn atributojn.

1338
00:58:39,570 --> 00:58:43,950
Do 400 k estas la totala grandeco
de tiu ero, 400 kilobajtoj.

1339
00:58:43,950 --> 00:58:46,170
Do de ĉiuj atributoj
kombinita, ĉiuj datumoj

1340
00:58:46,170 --> 00:58:49,140
jen en ĉiujn tiujn atributojn,
envolvita en tuta grandeco,

1341
00:58:49,140 --> 00:58:51,140
aktuale hodiaŭ la eron limo estas 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Do grimpante denove, atingita
tra dispartiganta.

1344
00:58:57,046 --> 00:58:58,920
Traigivo estas provizis
ĉe la tablo nivelo.

1345
00:58:58,920 --> 00:59:00,160
Kaj estas vere du kapetoj.

1346
00:59:00,160 --> 00:59:02,400
Ni legis kapablo
kaj skribu kapablo.

1347
00:59:02,400 --> 00:59:05,530
>> Do tiuj estas ĝustigitaj
sendepende.

1348
00:59:05,530 --> 00:59:08,640
RCU la mezuron strikte konsekvenca legas.

1349
00:59:08,640 --> 00:59:13,005
Bone, do se vi diras mi volas 1,000
RCU La tiuj estas strikte kohera,

1350
00:59:13,005 --> 00:59:14,130
tiuj estas konsekvenca legas.

1351
00:59:14,130 --> 00:59:17,130
Se vi diras ke mi volas
eventuala konsekvenca legas,

1352
00:59:17,130 --> 00:59:19,402
vi povas provizo 1,000
RCU a, vi tuj

1353
00:59:19,402 --> 00:59:21,840
akiri 2.000 eventuale
konsekvenca legas.

1354
00:59:21,840 --> 00:59:25,940
Kaj duono de la prezo por tiuj
eventuale konsisti en legas.

1355
00:59:25,940 --> 00:59:28,520
>> Denove, alĝustiĝi
sendepende.

1356
00:59:28,520 --> 00:59:32,900
Kaj ili havas la throughput--
Se vi konsumas 100% de via RCU,

1357
00:59:32,900 --> 00:59:35,960
vi ne tuj efikon la
havebleco de viaj rajtoj.

1358
00:59:35,960 --> 00:59:40,161
Do, ili estas tute
sendependa de unu la alian.

1359
00:59:40,161 --> 00:59:43,160
Bone, do unu el la aĵoj kiuj
Mi menciis brevemente estis sxancelan.

1360
00:59:43,160 --> 00:59:44,320
Sxancelan estas malbona.

1361
00:59:44,320 --> 00:59:47,311
Sxancelan indikas malbonan neniu SQL.

1362
00:59:47,311 --> 00:59:50,310
Ekzistas aferoj ni povas fari helpi
vi malpezigi la sxancelan ke vi

1363
00:59:50,310 --> 00:59:51,040
spertas.

1364
00:59:51,040 --> 00:59:53,240
Sed la plej bona solvo
al tio ni prenu

1365
00:59:53,240 --> 00:59:58,000
Rigardu, kion vi faras, ĉar
Tie estas anti-ŝablono en teatraĵo tie.

1366
00:59:58,000 --> 01:00:02,140
>> Tion, aĵoj kiel ne-uniforma
laborŝarĝoj, varmaj klavoj, varma vandoj.

1367
01:00:02,140 --> 01:00:06,210
Mi batas apartan klavon spaco
tre malfacile por iu aparta kialo.

1368
01:00:06,210 --> 01:00:07,080
Kial mi faras tion?

1369
01:00:07,080 --> 01:00:08,710
Ni kalkuli ke ekstere.

1370
01:00:08,710 --> 01:00:10,427
Mi miksante mia varma datumojn malvarma datumoj.

1371
01:00:10,427 --> 01:00:12,510
Mi liberigas miajn tabloj akiri
grandegaj, sed estas vere

1372
01:00:12,510 --> 01:00:15,970
nur iu subaro de la datumoj
tio estas vere interesa por mi.

1373
01:00:15,970 --> 01:00:20,290
Do por log datumoj, ekzemple, multajn
klientoj, Ili akiras log datumoj ĉiutage.

1374
01:00:20,290 --> 01:00:22,490
Ili akiris grandegan kvanton de log datumoj.

1375
01:00:22,490 --> 01:00:25,940
>> Se vi ĝuste dumpingo ĉiuj ke log
datumojn en unu granda tablo, super tempo

1376
01:00:25,940 --> 01:00:28,070
ke tablo tuj akiri amasajn.

1377
01:00:28,070 --> 01:00:30,950
Sed mi vere nur interesiĝis
lastaj 24 horoj, la lastaj sep tagoj,

1378
01:00:30,950 --> 01:00:31,659
la lastaj 30 tagoj.

1379
01:00:31,659 --> 01:00:34,074
Whatever la fenestro de tempo
ke mi estas interesita en rigardanta

1380
01:00:34,074 --> 01:00:37,010
por la okazaĵo kiu min tedas, aŭ
la okazaĵo kiu estas interesa por mi,

1381
01:00:37,010 --> 01:00:39,540
tio estas la sola fenestro tempo ke mi bezonas.

1382
01:00:39,540 --> 01:00:42,470
Do kial mi metante 10 jaroj
valoras de log datumoj en la tabelo?

1383
01:00:42,470 --> 01:00:45,030
Kio kiu kaŭzas estas
la tablo la fragmento.

1384
01:00:45,030 --> 01:00:45,880
>> Ĝi ricevas grandegan.

1385
01:00:45,880 --> 01:00:48,340
Ĝi komencas disvastiĝas
trans miloj da nodoj.

1386
01:00:48,340 --> 01:00:51,380
Kaj ĉar via kapablo
estas tiel malalta, ke vi estas

1387
01:00:51,380 --> 01:00:54,090
reale taksas limiganta sur ĉiu
unu el tiuj individuaj nodoj.

1388
01:00:54,090 --> 01:00:57,120
Do ni komencu rigardi kiel
do ni ruliĝi ke tablo super.

1389
01:00:57,120 --> 01:01:01,502
Kiel ni sukcesos ke datumoj iom
pli bone eviti tiujn problemojn.

1390
01:01:01,502 --> 01:01:02,710
Kaj kion tio aspektas?

1391
01:01:02,710 --> 01:01:04,370
Jen kion tio aspektas.

1392
01:01:04,370 --> 01:01:06,790
Jen kion malbonan NoSQL aspektas.

1393
01:01:06,790 --> 01:01:07,830
>> Mi ricevis varman klavon tie.

1394
01:01:07,830 --> 01:01:10,246
Se vi rigardos la flanko ĉi tie,
tiuj estas mia tuta vandoj.

1395
01:01:10,246 --> 01:01:12,630
Mi alvenis 16 vandoj tien
sur tiu aparta datumbazo.

1396
01:01:12,630 --> 01:01:13,630
Ni faru tion tutan tempon.

1397
01:01:13,630 --> 01:01:15,046
Mi kuras ĉi por klientoj ĉiuj tempoj.

1398
01:01:15,046 --> 01:01:16,550
Ĝi nomiĝas la varmego mapo.

1399
01:01:16,550 --> 01:01:20,590
Varmo mapo diras mi kiel vi estas
aliranta via ŝlosilo spaco.

1400
01:01:20,590 --> 01:01:23,700
Kaj kion tio estas diranta min estas
ke estas unu aparta hash

1401
01:01:23,700 --> 01:01:26,330
ke tiu ulo ŝatas an
amasego, ĉar li estas

1402
01:01:26,330 --> 01:01:28,250
batante ĝin vere, vere malmola.

1403
01:01:28,250 --> 01:01:29,260
>> Do la blua estas bela.

1404
01:01:29,260 --> 01:01:29,900
Ni ŝatas blua.

1405
01:01:29,900 --> 01:01:30,720
Ni ne ŝatas ruĝa.

1406
01:01:30,720 --> 01:01:33,120
Ruĝa estas kie la premo
ricevas ĝis 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, nun vi tuj estos limigita.

1408
01:01:35,560 --> 01:01:39,030
Do kiam ajn vi vidas ian ruĝaj linioj kiel
this-- kaj ĝi estas ne nur Dinamo DB--

1409
01:01:39,030 --> 01:01:41,630
ĉiun NoSQL datumbazo havas tiun problemon.

1410
01:01:41,630 --> 01:01:44,640
Ekzistas kontraŭ-padronoj kiuj povas
forpelos tiujn tipojn de kondiĉoj.

1411
01:01:44,640 --> 01:01:49,070
Kion mi faros estas mi laboras kun klientoj
mildigi tiujn kondiĉojn.

1412
01:01:49,070 --> 01:01:51,840
>> Kaj kion tio aspektas?

1413
01:01:51,840 --> 01:01:54,260
Kaj tiu estas akiranta la plej
el Dinamo DB traigivo,

1414
01:01:54,260 --> 01:01:56,176
Sed estas vere atingi
la plej ekstere de NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Tiu ne estas restriktita al Dinamo.

1416
01:01:58,740 --> 01:02:02,050
Jen definitely-- mi
kutimis labori ĉe Mongo.

1417
01:02:02,050 --> 01:02:04,090
Mi estas konata kun multaj NoSQL platformoj.

1418
01:02:04,090 --> 01:02:06,830
Ĉiu unu havas tiujn tipojn
de varma klavo problemojn.

1419
01:02:06,830 --> 01:02:10,320
Por ricevi la plej el ajna NoSQL
datenbazo, specife Dinamo DB,

1420
01:02:10,320 --> 01:02:13,320
vi volas krei la tabloj
kie la hash ŝlosila elemento havas

1421
01:02:13,320 --> 01:02:18,590
granda nombro da apartaj valoroj,
altgradan kardinalo.

1422
01:02:18,590 --> 01:02:22,530
Ĉar tiu signifas Mi estas skribanta
al multaj malsamaj siteloj.

1423
01:02:22,530 --> 01:02:24,870
>> La pli siteloj mi
skribi al, la pli verŝajna

1424
01:02:24,870 --> 01:02:29,100
Mi estas disvastigi, kiuj skribas ŝarĝo aŭ
legi ŝargi trans multoblaj nodoj,

1425
01:02:29,100 --> 01:02:33,560
La pli probable mi estas havi
alta traigivo sur la tablo.

1426
01:02:33,560 --> 01:02:37,440
Kaj tiam mi volas ke la valoroj por esti
petis sufiĉe egale super tempo

1427
01:02:37,440 --> 01:02:39,430
kaj unuforme kiel hazarde kiel ebla.

1428
01:02:39,430 --> 01:02:42,410
Nu, jen speco de interesaj,
ĉar mi ne povas vere

1429
01:02:42,410 --> 01:02:43,960
kontrolo kiam la uzantoj venas.

1430
01:02:43,960 --> 01:02:47,645
Do sufiĉas nomi, se ni disvastigus
aferojn ekstere trans la ŝlosilo spaco,

1431
01:02:47,645 --> 01:02:49,270
ni probable esti en pli bona formo.

1432
01:02:49,270 --> 01:02:51,522
>> Ekzistas certa
kvanto de tempo transdono

1433
01:02:51,522 --> 01:02:53,230
ke vi ne tuj
povi kontrolon.

1434
01:02:53,230 --> 01:02:55,438
Sed tiuj estas vere la
du dimensioj ke ni havas,

1435
01:02:55,438 --> 01:02:58,800
spaco, aliro egale
disvastiĝo, tempo, petoj

1436
01:02:58,800 --> 01:03:01,040
alveni egale interspacigitaj en la tempo.

1437
01:03:01,040 --> 01:03:03,110
Kaj se tiuj du
kondiĉoj estas estanta renkontita,

1438
01:03:03,110 --> 01:03:05,610
tiam tio estas kio ĝi estas
tuj aspekti.

1439
01:03:05,610 --> 01:03:07,890
Tiu estas multe pli bela.

1440
01:03:07,890 --> 01:03:08,890
Ni estas vere feliĉa tie.

1441
01:03:08,890 --> 01:03:10,432
Ni havas tre eĉ aliro ŝablono.

1442
01:03:10,432 --> 01:03:13,098
Jes, eble vi fariĝas
iom premo ĉiu nun kaj tiam,

1443
01:03:13,098 --> 01:03:14,830
sed nenio vere tro vasta.

1444
01:03:14,830 --> 01:03:17,660
Do estas nekredebla kiel multaj tempoj,
kiam mi laboras kun klientoj,

1445
01:03:17,660 --> 01:03:20,670
ke unua grafeo kun la granda ruĝa
bari kaj cxio malbela flava estas

1446
01:03:20,670 --> 01:03:23,147
ĉie, ni
get farita per la ekzerco

1447
01:03:23,147 --> 01:03:24,980
post paro de monatoj
de re-arkitekturo,

1448
01:03:24,980 --> 01:03:28,050
ili estas kurante la ĝusta sama
laborŝarĝo ĉe la ĝusta sama ŝarĝo.

1449
01:03:28,050 --> 01:03:30,140
Kaj tiu estas kio ĝi estas rigardanta kiel nun.

1450
01:03:30,140 --> 01:03:36,600
Do kion vi ricevas kun NoSQL estas
datumoj skemo kiu estas absolute

1451
01:03:36,600 --> 01:03:38,510
ligitaj al la aliro ŝablono.

1452
01:03:38,510 --> 01:03:42,170
>> Kaj vi povas optimizar ke datumoj schema
subteni ke aliro ŝablono.

1453
01:03:42,170 --> 01:03:45,490
Se ne, tiam vi tuj
vidi tiujn tipojn de problemoj

1454
01:03:45,490 --> 01:03:46,710
kun tiuj varmaj klavoj.

1455
01:03:46,710 --> 01:03:50,518
>> Publiko: Nu, neeviteble iuj lokoj
tuj estos pli varmega ol aliaj.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Ĉiam.

1457
01:03:51,450 --> 01:03:51,960
Ĉiam.

1458
01:03:51,960 --> 01:03:54,620
Jes, mi signifas ĉiam
a-- kaj denove, ekzistas

1459
01:03:54,620 --> 01:03:56,980
iuj dezajno ŝablonoj ni akiros tra
kiu parolas pri kiel vi trakti

1460
01:03:56,980 --> 01:03:58,480
kun tiuj super grandaj aldonitaj.

1461
01:03:58,480 --> 01:04:01,260
Mi volas diri, mi alvenis al havi ilin,
kiel ni traktu ilin?

1462
01:04:01,260 --> 01:04:03,760
Mi akiris sufiĉe bonan uzon kazo
ke ni parolos pri tion.

1463
01:04:03,760 --> 01:04:05,940
>> Bone, do ni parolu
pri iuj klientoj nun.

1464
01:04:05,940 --> 01:04:06,950
Tiuj infanoj estas AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Mi ne scias ĉu vi estas
konanta AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Vi probable vidos ilin
tre sur la retumilo.

1467
01:04:10,781 --> 01:04:14,230
Ili estas ad re-celado, ili estas
la plej granda ad re-celado negoco

1468
01:04:14,230 --> 01:04:14,940
tie.

1469
01:04:14,940 --> 01:04:17,792
Ili kutime regule alveturi
60 miliardoj transakcioj je tago.

1470
01:04:17,792 --> 01:04:20,000
Ili faras super miliono
transakcioj je sekundo.

1471
01:04:20,000 --> 01:04:22,660
Ili havas belan simpla tablo
strukturo, la plej okupataj tablo.

1472
01:04:22,660 --> 01:04:26,450
Ĝi estas esence nur
hash ŝlosilo estas la kuketon,

1473
01:04:26,450 --> 01:04:29,010
la gamo estas la demografia
kategorio, kaj poste

1474
01:04:29,010 --> 01:04:31,220
la tria atributo estas la poentaro.

1475
01:04:31,220 --> 01:04:33,720
>> Do ni ĉiuj kuketojn en
nia retumilo el tiuj infanoj.

1476
01:04:33,720 --> 01:04:35,900
Kaj kiam vi iros al
partoprenantaj komercisto,

1477
01:04:35,900 --> 01:04:39,390
Ili esence trafi vin trans
diversaj demografiaj kategorioj.

1478
01:04:39,390 --> 01:04:42,070
Kiam vi iras al retejo kaj
via parolo mi volas vidi ĉi ad--

1479
01:04:42,070 --> 01:04:44,920
aŭ esence vi ne diras that--
sed kiam vi iras al la paĝaro

1480
01:04:44,920 --> 01:04:47,550
ili diras vi volas vidi ĉi tiun anoncon.

1481
01:04:47,550 --> 01:04:49,370
Kaj ili iris akiri ke ad el AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll aspektas vin sur ilian tablon.

1483
01:04:51,130 --> 01:04:52,115
Ili trovas vian kuketon.

1484
01:04:52,115 --> 01:04:53,990
La reklamantoj rakontanta
ilin, mi volas iun

1485
01:04:53,990 --> 01:04:58,632
Kiu estas mezaĝa,
40-jaro-malnova viro, en sportoj.

1486
01:04:58,632 --> 01:05:01,590
Kaj ili trafi vin en tiuj demografio
kaj ili decidos ĉu aŭ ne

1487
01:05:01,590 --> 01:05:02,740
tio estas bona reklamo por vi.

1488
01:05:02,740 --> 01:05:10,330
>> Nun ili havas SLA kun
ilia publikeco provizantoj

1489
01:05:10,330 --> 01:05:14,510
provizi sub- 10 milisegundo
respondo sur ĉiu ununura peto.

1490
01:05:14,510 --> 01:05:16,090
Do ili estas uzanta Dinamo DB ĉi.

1491
01:05:16,090 --> 01:05:18,131
Ili batas al ni
milionoj petoj por dua.

1492
01:05:18,131 --> 01:05:21,120
Ili estas kapablaj fari cxiujn siajn
serĉoj, postenoj de klasifiko ĉiuj kiuj datumojn,

1493
01:05:21,120 --> 01:05:26,130
kaj kunprenu tiun aldonu ligon reen al tiu
Advertiser en sub 10 milisekundoj.

1494
01:05:26,130 --> 01:05:29,800
Estas vere bela fenomena
efektivigo, kiun ili havas.

1495
01:05:29,800 --> 01:05:36,210
>> Tiuj uloj actually--
Estas tiuj la uloj.

1496
01:05:36,210 --> 01:05:38,010
Mi ne certas se ĝi estas tiuj uloj.

1497
01:05:38,010 --> 01:05:40,127
Povus esti tiuj uloj.

1498
01:05:40,127 --> 01:05:42,210
Esence rakontis us-- ne, mi
ne kredu, ke estis ili.

1499
01:05:42,210 --> 01:05:43,000
Mi kredas ke estis iu alia.

1500
01:05:43,000 --> 01:05:44,750
Mi laboris kun
kliento kiu rakontis min

1501
01:05:44,750 --> 01:05:47,040
ke nun ke ili jam
iris al Dinamo DB, ili estas

1502
01:05:47,040 --> 01:05:50,330
elspezi pli mono en manĝetoj por
ilia evoluo teamo ĉiumonate

1503
01:05:50,330 --> 01:05:52,886
ol ili elspezas en lia datumbazo.

1504
01:05:52,886 --> 01:05:54,760
Do ĝi donos al vi
ideon de la kosto ŝparadoj

1505
01:05:54,760 --> 01:05:57,889
ke vi povas akiri en Dinamo DB estas grandega.

1506
01:05:57,889 --> 01:05:59,430
Bone, dropcam estas alia kompanio.

1507
01:05:59,430 --> 01:06:02,138
Tiuj ulo estas afabla of-- se vi opinias
de interreto de aferoj, dropcam

1508
01:06:02,138 --> 01:06:05,150
estas esence interreto sekureco video.

1509
01:06:05,150 --> 01:06:06,660
Vi metu vian fotilon tie.

1510
01:06:06,660 --> 01:06:08,180
Fotilo havas moviĝo detektilo.

1511
01:06:08,180 --> 01:06:10,290
Iu venas kune,
deĉenigas cue punkto.

1512
01:06:10,290 --> 01:06:13,540
Fotilo startas registrado por tempeto ĝis
ĝi ne detektas ajnan movadon anymore.

1513
01:06:13,540 --> 01:06:15,310
Metas ke video sur la interreto.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam estis entrepreno kiu estas
esence ŝanĝis al Dinamo DB

1515
01:06:19,800 --> 01:06:22,200
ĉar ili spertas
enorma kreskanta dolorojn.

1516
01:06:22,200 --> 01:06:25,820
Kaj kion ili diris al ni,
subite petabytes de datumoj.

1517
01:06:25,820 --> 01:06:28,070
Ili tute ne sciis ilian servon
estus tiel sukcesa.

1518
01:06:28,070 --> 01:06:32,310
Pli inbound vídeo ol YouTube
estas kio tiuj infanoj plialtigas.

1519
01:06:32,310 --> 01:06:36,780
Ili uzas DynamoDB spuri ĉiujn
metadatenojn en ĉiuj liaj video ŝlosilaj punktoj.

1520
01:06:36,780 --> 01:06:40,282
>> Do ili havas S3 siteloj ili puŝi
ĉiuj binarajn artefaktojn en.

1521
01:06:40,282 --> 01:06:41,990
Kaj tiam ili havas
Dinamo DB rekordojn ke

1522
01:06:41,990 --> 01:06:44,070
atentigi homojn al tiuj S3 tri celojn.

1523
01:06:44,070 --> 01:06:47,070
Kiam ili bezonas rigardi video,
Ili fikse rigardis la rekordon en Dinamo DB.

1524
01:06:47,070 --> 01:06:47,903
Ili klaku la ligilon.

1525
01:06:47,903 --> 01:06:49,770
Ili disbatos la video de S3.

1526
01:06:49,770 --> 01:06:51,590
Do jen speco de kion ĉi aspektas.

1527
01:06:51,590 --> 01:06:53,580
Kaj tio estas rekte el ilia teamo.

1528
01:06:53,580 --> 01:06:56,010
>> Dinamo DB reduktas sian
transdono tempo por video okazaĵoj

1529
01:06:56,010 --> 01:06:57,590
de kvin al 10 sekundoj.

1530
01:06:57,590 --> 01:07:00,470
En sia malnova interrilata vendejo,
kutimis devi iri kaj ekzekuti

1531
01:07:00,470 --> 01:07:03,780
multoblaj kompleksaj pridemandojn figuro
el kiuj videos disfrapos,

1532
01:07:03,780 --> 01:07:06,690
ĝis malpli ol 50 milisekundoj.

1533
01:07:06,690 --> 01:07:08,990
Do estas mirinda, Miranta
kiom agado

1534
01:07:08,990 --> 01:07:12,990
vi povas akiri kiam vin optimizar kaj
vi agordi la subkuŝantaj datumbazo

1535
01:07:12,990 --> 01:07:15,110
por apogi la aliro ŝablono.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, tiuj uloj, kio estas ĝi,
Frukto Ninja mi supozas estas ilia afero.

1537
01:07:20,500 --> 01:07:22,590
Ke ĉiuj kuras sur Dinamo DB.

1538
01:07:22,590 --> 01:07:26,810
Kaj tiuj uloj, ili estas granda
evoluigteamo, granda disvolviĝo

1539
01:07:26,810 --> 01:07:27,670
butiko.

1540
01:07:27,670 --> 01:07:29,364
>> Ne bona ops teamo.

1541
01:07:29,364 --> 01:07:31,280
Ili ne havis multe
de operacio rimedoj.

1542
01:07:31,280 --> 01:07:33,940
Ili baraktis provas konservi
ilia apliko infrastrukturo supren

1543
01:07:33,940 --> 01:07:34,290
kaj kurante.

1544
01:07:34,290 --> 01:07:35,000
Ili venis al ni.

1545
01:07:35,000 --> 01:07:36,251
Ili rigardis ke Dinamo DB.

1546
01:07:36,251 --> 01:07:37,291
Ili diris, tio estas por ni.

1547
01:07:37,291 --> 01:07:39,470
Ili konstruis siajn tutajn
apliko kadro sur ĝi.

1548
01:07:39,470 --> 01:07:43,640
Kelkaj vere bela komentoj tie
de la teamo sur ilia kapablo

1549
01:07:43,640 --> 01:07:46,800
nun enfokusigi konstruaĵo
la ludo kaj ne

1550
01:07:46,800 --> 01:07:49,010
devi subteni la
infrastrukturo, kiu

1551
01:07:49,010 --> 01:07:51,910
iĝis enorma kvanto
de superkape por ilia teamo.

1552
01:07:51,910 --> 01:07:56,170
Do ĉi tio estas iu that-- la
profitigi kiujn vi ricevas el Dinamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Bone, reenirinte
modelo de datumoj ĉi tie.

1554
01:08:00,930 --> 01:08:03,440
Kaj ni parolis iom pri
ĉi tiu al oni, oni al multaj,

1555
01:08:03,440 --> 01:08:05,060
kaj multaj multaj tipo interrilatoj.

1556
01:08:05,060 --> 01:08:07,630
Kaj kiel vi subteni tiujn en Dinamo.

1557
01:08:07,630 --> 01:08:10,500
En Dinamo DB ni uzas
indeksoj, ĝenerale parolante,

1558
01:08:10,500 --> 01:08:12,910
rotacii la datenoj de
unu guston al la aliaj.

1559
01:08:12,910 --> 01:08:15,210
Hash klavoj, gamo klavoj kaj indeksoj.

1560
01:08:15,210 --> 01:08:18,540
>> En ĉi tiu aparta
Ekzemple, kiel la plej multaj ŝtatoj

1561
01:08:18,540 --> 01:08:23,802
havi permesila postulo ke
nur unu kondukpermesilon por persono.

1562
01:08:23,802 --> 01:08:26,510
Vi povas iri por akiri du ŝoforo
licencojn en la stato de Boston.

1563
01:08:26,510 --> 01:08:27,500
Mi ne povas fari ĝin en Teksaso.

1564
01:08:27,500 --> 01:08:28,708
Tio estas speco de la vojo ĝi estas.

1565
01:08:28,708 --> 01:08:32,779
Kaj tial ĉe la DMV, ni havas serĉoj, ni
deziras rigardi supre la kondukpermesilon

1566
01:08:32,779 --> 01:08:35,180
per la socia sekureco nombro.

1567
01:08:35,180 --> 01:08:39,990
Mi volas rigardi la uzanto detaloj
per la kondukpermesilon nombro.

1568
01:08:39,990 --> 01:08:43,620
>> Do ni povus havi uzanto tablo, kiu
havas hash ŝlosilo sur la seria numero,

1569
01:08:43,620 --> 01:08:47,830
aŭ la socia sekureco nombro, kaj
diversaj atributoj difinita sur la eron.

1570
01:08:47,830 --> 01:08:49,859
Nun sur tiu tablo mi
povus difini GSI ke

1571
01:08:49,859 --> 01:08:53,370
flips ke ĉirkaŭ kiu diras mi volas
hash ŝlosilo sur la licenco kaj tiam

1572
01:08:53,370 --> 01:08:54,252
ĉiuj aliaj eroj.

1573
01:08:54,252 --> 01:08:57,210
Sed se mi volas demandi kaj trovi la
licenco nombro por iu antaŭfiksita Socia

1574
01:08:57,210 --> 01:08:59,609
Sekureco nombro, mi povas
konsulti la ĉefa tablo.

1575
01:08:59,609 --> 01:09:02,130
>> Se mi volas konsulti kaj mi volas
akiri la socian sekurecon

1576
01:09:02,130 --> 01:09:05,735
numeron aŭ aliaj atributoj de
licenco numeron, mi povas konsulti la GSI.

1577
01:09:05,735 --> 01:09:08,689
Tiu modelo estas tiu
al unu interrilato.

1578
01:09:08,689 --> 01:09:12,460
Nur tre simpla GSI,
flip tiuj aĵoj ĉirkaŭ.

1579
01:09:12,460 --> 01:09:13,979
Nun, parolu pri unu al multaj.

1580
01:09:13,979 --> 01:09:16,450
Unu por multaj estas esence
via hash gamo ŝlosilo.

1581
01:09:16,450 --> 01:09:20,510
Kie ni ricevas multe kun ĉi
uzokazo estas monitoro datumoj.

1582
01:09:20,510 --> 01:09:23,880
Monitoro datumoj venas en regula
intervalo, kiel interreto de aferoj.

1583
01:09:23,880 --> 01:09:26,890
Ni ĉiam akiri ĉiujn tiujn
rekordojn venon tutan tempon.

1584
01:09:26,890 --> 01:09:31,420
>> Kaj mi volas trovi ĉiujn legaĵoj
inter specifa tempoperiodo.

1585
01:09:31,420 --> 01:09:34,220
Ĝi estas tre komuna en query
monitorado infrastrukturo.

1586
01:09:34,220 --> 01:09:38,430
La vojo iras pri kiuj estas trovi
simpla tablo strukturo, unu tablon.

1587
01:09:38,430 --> 01:09:42,250
Mi havas aparaton mezuradojn tablo
kun hash ŝlosilo sur la aparato ID.

1588
01:09:42,250 --> 01:09:47,340
Kaj mi havas gamon ŝlosilon sur la
tempstampo aŭ en ĉi tiu kazo, la epopeo.

1589
01:09:47,340 --> 01:09:50,350
Kaj kiu min permesas ekzekuti kompleksajn
sercxoj kontraŭ tiu gamo ŝlosilo

1590
01:09:50,350 --> 01:09:54,950
kaj redoni tiuj rekordoj ke
estas relativa al la rezulto

1591
01:09:54,950 --> 01:09:56,310
fiksita ke mi serĉas.

1592
01:09:56,310 --> 01:09:58,360
Kaj verko ke unu
al multaj interrilato

1593
01:09:58,360 --> 01:10:02,340
en la primara tablo uzante la
hash ŝlosilo, gamo ŝlosilo strukturo.

1594
01:10:02,340 --> 01:10:04,600
>> Do jen speco de konstruita
en la tablon en Dinamo DB.

1595
01:10:04,600 --> 01:10:07,290
Kiam mi difini hash
kaj gamo t tablon, mi

1596
01:10:07,290 --> 01:10:09,240
difinanta unu al multaj rilato.

1597
01:10:09,240 --> 01:10:12,770
Ĝi estas gepatro-infano rilato.

1598
01:10:12,770 --> 01:10:14,620
>> Ni parolu pri multaj
multaj rilatoj.

1599
01:10:14,620 --> 01:10:19,170
Kaj por ĉi tiu aparta ekzemplo,
denove, ni tuj uzos la GSI.

1600
01:10:19,170 --> 01:10:23,500
Kaj ni parolu pri ludoj
scenaro kie mi havas donita uzanto.

1601
01:10:23,500 --> 01:10:26,500
Mi volas eltrovi ĉiujn ludojn kiuj
li registris por aŭ ludante en.

1602
01:10:26,500 --> 01:10:29,600
Kaj por antaŭfiksita ludo, mi
volas trovi ĉiujn uzantojn.

1603
01:10:29,600 --> 01:10:31,010
Do kiel mi faru tion?

1604
01:10:31,010 --> 01:10:34,330
Mia uzanto ludoj tablo, mi tuj
havi hash ŝlosilon de uzanto ID

1605
01:10:34,330 --> 01:10:35,810
kaj gamo ŝlosilo de la ludo.

1606
01:10:35,810 --> 01:10:37,810
>> Do uzanto povas havi multoblajn ludojn.

1607
01:10:37,810 --> 01:10:41,380
Estas unu al multaj rilato inter
la uzanto kaj la ludoj li ludas.

1608
01:10:41,380 --> 01:10:43,410
Kaj poste sur la GSI,
Mi flip ke ĉirkaŭ.

1609
01:10:43,410 --> 01:10:46,679
Mi hash sur la ludo kaj
Mi oscili sur la uzanto.

1610
01:10:46,679 --> 01:10:48,970
Do se mi volas ricevi ĉiujn
ludo la uzanto ludi en,

1611
01:10:48,970 --> 01:10:49,950
Mi konsulti la ĉefa tablo.

1612
01:10:49,950 --> 01:10:52,699
Se mi volas ricevi ĉiujn uzantojn
ke ludas apartan ludo,

1613
01:10:52,699 --> 01:10:53,887
Mi konsulti la GSI.

1614
01:10:53,887 --> 01:10:54,970
Do vi vidas, kiel ni faru tion?

1615
01:10:54,970 --> 01:10:58,369
Vi konstruas tiujn GSI la subteni la
uzo kazo, la apliko, la aliro

1616
01:10:58,369 --> 01:10:59,410
mastro, la apliko.

1617
01:10:59,410 --> 01:11:01,440
>> Se mi bezonas konsulti sur
tiu dimensio, lasu

1618
01:11:01,440 --> 01:11:03,500
mi krei indekson en tiu dimensio.

1619
01:11:03,500 --> 01:11:05,850
Se ne, mi ne zorgas.

1620
01:11:05,850 --> 01:11:09,060
Kaj laŭ la uzo kazo, mi
eble bezonas la indekso aŭ mi ne.

1621
01:11:09,060 --> 01:11:12,390
Se ĝi estas simpla por multaj;
la ĉefa tablo estas fajna.

1622
01:11:12,390 --> 01:11:15,860
Se mi bezonas fari multaj al tiuj
multaj informoj, aŭ mi bezonas fari unu al ones,

1623
01:11:15,860 --> 01:11:18,390
tiam eble mi bezonas
al dua la indekso.

1624
01:11:18,390 --> 01:11:20,840
Do ĉiu dependas
kion mi klopodas fari

1625
01:11:20,840 --> 01:11:24,550
kaj kion mi provas akiri plenumita.

1626
01:11:24,550 --> 01:11:28,000
>> Probable mi ne tuj elspezi tro
da tempo parolante pri dokumentoj.

1627
01:11:28,000 --> 01:11:31,460
Ĉi ricevas iomete, probable,
profunda ol ni bezonas iri en.

1628
01:11:31,460 --> 01:11:33,710
Ni parolu iomete
pri riĉaj query esprimo.

1629
01:11:33,710 --> 01:11:37,831
Do en Dinamo DB ni havas
la eblecon krei

1630
01:11:37,831 --> 01:11:39,330
kion ni nomas projekcio esprimoj.

1631
01:11:39,330 --> 01:11:42,660
Projekcio esprimoj estas simple
pluki la kampoj aŭ la valoroj

1632
01:11:42,660 --> 01:11:44,290
ke vi volas montri.

1633
01:11:44,290 --> 01:11:46,000
Bone, do mi fari elekton.

1634
01:11:46,000 --> 01:11:48,010
Mi kreskigos query kontraŭ Dinamo DB.

1635
01:11:48,010 --> 01:11:51,730
Kaj mi diras, vi scias kio, spektaklo
min nur la kvin stelo recenzoj

1636
01:11:51,730 --> 01:11:54,544
por ĉi tiu aparta produkto.

1637
01:11:54,544 --> 01:11:55,710
Do jen ĉio mi volas vidi.

1638
01:11:55,710 --> 01:11:57,320
Mi ne volas vidi ĉiujn
aliaj atributoj de la vico,

1639
01:11:57,320 --> 01:11:58,319
Mi nur volas vidi tion.

1640
01:11:58,319 --> 01:12:01,209
Estas ĝuste kiel en SQLa kiam vi
diru unuaranga stelo aŭ de tablo,

1641
01:12:01,209 --> 01:12:02,000
vi ricevas ĉion.

1642
01:12:02,000 --> 01:12:05,450
Kiam mi diras unuaranga nomon de
tablo, mi nur akiri unu atributo.

1643
01:12:05,450 --> 01:12:09,070
Ĝi estas la sama speco de aĵo en
Dinamo DB aŭ alia NoSQL datumbazoj.

1644
01:12:09,070 --> 01:12:14,510
Filtrilo esprimoj permesos min
esence tranĉis la rezulto metita malsupren.

1645
01:12:14,510 --> 01:12:15,540
Do mi faru konsulto.

1646
01:12:15,540 --> 01:12:17,260
Query revenu kun 500 eroj.

1647
01:12:17,260 --> 01:12:20,255
Sed mi nur volas la erojn kiuj
havas atributon kiu diras tion.

1648
01:12:20,255 --> 01:12:23,380
Okej, do ni elfiltri tiujn erojn
kiuj ne kongruas tiu aparta demando.

1649
01:12:23,380 --> 01:12:25,540
Do ni havas filtrilon esprimoj.

1650
01:12:25,540 --> 01:12:28,310
>> Filtrilo esprimoj povas
kuri sur iu atributo.

1651
01:12:28,310 --> 01:12:30,260
Ili ne estas kiel gamo mendoj.

1652
01:12:30,260 --> 01:12:32,690
Raise demandoj estas pli selektema.

1653
01:12:32,690 --> 01:12:36,470
Filtrilo demandoj postulas min iri
akiri la tutan rezultoj starigis kaj tiam

1654
01:12:36,470 --> 01:12:39,170
skulpti el la datumoj ne volas.

1655
01:12:39,170 --> 01:12:40,660
Kial estas tio gravas?

1656
01:12:40,660 --> 01:12:42,770
Ĉar mi legis ĉion.

1657
01:12:42,770 --> 01:12:46,597
En konsulto, mi tuj legi kaj
ĝi tuj estos gigante pri datenoj.

1658
01:12:46,597 --> 01:12:48,430
Kaj tiam mi tuj
skulpti el kio mi bezonas.

1659
01:12:48,430 --> 01:12:52,080
Kaj se mi nur cxizi eksteren
kelkaj vicoj, tiam tio estas bone.

1660
01:12:52,080 --> 01:12:53,620
Ĝi ne estas tiom malefikaj.

1661
01:12:53,620 --> 01:12:57,800
>> Sed se mi legas tutan amason de
datumo, nur por skulpti el unu ero,

1662
01:12:57,800 --> 01:13:01,490
tiam mi tuj estos pli bona
off uzante gamon query,

1663
01:13:01,490 --> 01:13:03,030
ĉar ĝi estas multe pli elektemaj.

1664
01:13:03,030 --> 01:13:06,330
Ĝi tuj savi min multan
monon, ĉar mi pagas por tiu legado.

1665
01:13:06,330 --> 01:13:10,430
Kie la rezultoj kiuj venas reen
transiri tiun drato povus esti pli malgranda,

1666
01:13:10,430 --> 01:13:11,890
sed mi pagas pro la legado.

1667
01:13:11,890 --> 01:13:14,340
Do komprenu kiom
vi fariĝas la datumoj.

1668
01:13:14,340 --> 01:13:16,420
Tio estas tre grava en Dinamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Kondiĉa esprimoj, tiu estas kio
vi eble nomu optimisma ŝlosado.

1670
01:13:19,710 --> 01:13:28,470
Ĝisdatigu se ekzistas, aŭ se tiu valoro
estas ekvivalenta al kio mi specifas.

1671
01:13:28,470 --> 01:13:31,494
Kaj se mi havas tempon poŝtmarko iun
rekordo, mi povus legi la datumojn.

1672
01:13:31,494 --> 01:13:32,535
Mi povus ŝanĝi tion datumoj.

1673
01:13:32,535 --> 01:13:35,030
Mi povus iri registran ke
datumojn reen al la datumbazo.

1674
01:13:35,030 --> 01:13:38,100
Se iu ŝanĝis la rekordo,
la tempstampo eble ŝanĝiĝis.

1675
01:13:38,100 --> 01:13:40,370
Kaj aliflanken mian kondiĉa
ĝisdatigo povus diri ĝisdatigo

1676
01:13:40,370 --> 01:13:42,340
se la tempstampo egalas ĉi.

1677
01:13:42,340 --> 01:13:46,290
Aŭ la ĝisdatigo malsukcesos ĉar iu
ĝisdatigis la rekordon dume.

1678
01:13:46,290 --> 01:13:48,290
>> Tion ni nomas optimisma ŝlosado.

1679
01:13:48,290 --> 01:13:50,670
Ĝi signifas ke iu
povas enveni kaj ŝanĝi ĝin,

1680
01:13:50,670 --> 01:13:53,100
kaj mi tuj detekti ŝin
kiam mi reiras al skribi.

1681
01:13:53,100 --> 01:13:56,106
Kaj tiam mi povas vere legi ke
datumoj kaj diru, ho, li ŝanĝis tion.

1682
01:13:56,106 --> 01:13:57,230
Mi bezonas klarigi ke.

1683
01:13:57,230 --> 01:14:00,490
Kaj mi povas ŝanĝi la datumojn en mia
registri kaj apliki alian ĝisdatigon.

1684
01:14:00,490 --> 01:14:04,330
Do vi povas kapti tiujn dumtajpa
ĝisdatigoj kiuj okazas inter la tempo

1685
01:14:04,330 --> 01:14:08,740
ke vi legas la datumojn kaj la
tempo vi povus skribi la datumojn.

1686
01:14:08,740 --> 01:14:11,520
>> Publiko: Kaj la filtrilo
esprimo fakte signifas ne

1687
01:14:11,520 --> 01:14:13,020
en la nombro aŭ not--

1688
01:14:13,020 --> 01:14:14,316
>> [Intermetante VOĈOJ]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: Mi ne volas
ricevas tro multe en tiu.

1690
01:14:16,232 --> 01:14:17,700
Tio Estas rezervita ŝlosilvorto.

1691
01:14:17,700 --> 01:14:20,130
La funto vido estas rezervita
ŝlosilvorto en Dinamo DB.

1692
01:14:20,130 --> 01:14:24,500
Ĉiu datumbazo havas propran rezervita
nomoj por kolektoj vi ne povas uzi.

1693
01:14:24,500 --> 01:14:27,240
Dinamo DB, se vi specifas
funton antaŭ tiu,

1694
01:14:27,240 --> 01:14:29,310
vi povas difini tiujn nomojn super.

1695
01:14:29,310 --> 01:14:31,840
Jen referencita valoro.

1696
01:14:31,840 --> 01:14:34,880
Ĝi estas probable ne la plej bona sintakso por
havas tie supre por ĉi tiu diskuto,

1697
01:14:34,880 --> 01:14:38,090
ĉar ĝi metas en iu real--
Mi estus estinta parolante pli

1698
01:14:38,090 --> 01:14:41,360
pri kiuj ĉe pli profunda nivelo.

1699
01:14:41,360 --> 01:14:46,130
>> Sed sufiĉas diri, tiu povis
esti query skani kie views--

1700
01:14:46,130 --> 01:14:50,190
nek funto opinioj estas pli granda ol 10.

1701
01:14:50,190 --> 01:14:54,660
Ĝi estas nombra valoro, jes.

1702
01:14:54,660 --> 01:14:57,322
Se vi volas, ni povas paroli pri
ke post la diskuto.

1703
01:14:57,322 --> 01:15:00,030
Bone, do ni ricevas en
iuj scenejoj en bonaj praktikoj

1704
01:15:00,030 --> 01:15:02,000
kie ni tuj paroli
pri iuj apps tie.

1705
01:15:02,000 --> 01:15:03,810
Kio estas la uzo kazoj por Dinamo DB.

1706
01:15:03,810 --> 01:15:06,120
Kio estas la dezajno
ŝablonoj en Dinamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> Kaj la unua unu ni tuj
diskuto pri tio estas la interreto de aferoj.

1708
01:15:09,110 --> 01:15:15,010
Do ni ricevas amason of-- mi supozas,
kio estas it-- pli ol 50%

1709
01:15:15,010 --> 01:15:19,370
de trafiko sur la interreto ĉi tiuj tagoj
fakte generita per maŝinoj,

1710
01:15:19,370 --> 01:15:21,930
aŭtomatigita procezoj, ne de homoj.

1711
01:15:21,930 --> 01:15:25,140
Mi volas diri tion ĉi afero
vi portas ĉirkaŭ via poŝo,

1712
01:15:25,140 --> 01:15:28,840
kiom datumo ke tio afero estas
fakte sendado ĉirkaŭ sen vi

1713
01:15:28,840 --> 01:15:30,550
scii ĝin estas absolute mirinda.

1714
01:15:30,550 --> 01:15:34,970
Via situo, informoj
pri kiom rapide vi iras.

1715
01:15:34,970 --> 01:15:38,400
Kiel vi pensas Google Maps verkoj
kiam oni diras al vi kion la trafiko estas.

1716
01:15:38,400 --> 01:15:41,275
Estas ĉar ekzistas milionoj kaj
milionoj da homoj veturanta ĉirkaŭ

1717
01:15:41,275 --> 01:15:44,667
kun telefonoj kiuj sendas
datumoj ĉie loko tutan tempon.

1718
01:15:44,667 --> 01:15:46,500
Do unu el la aĵoj
pri tiu tipo de datumoj

1719
01:15:46,500 --> 01:15:50,980
kiu venas en, monitoro datumoj, log
datumoj, tempo serio datumojn, estas ĝi

1720
01:15:50,980 --> 01:15:53,540
kutime nur interesa
por iomete da tempo.

1721
01:15:53,540 --> 01:15:55,580
Post tiu tempo, ĝi estas
ne tiel interesa.

1722
01:15:55,580 --> 01:15:58,390
Do ni raportis, ne lasu
tiujn tablojn kreski sen limoj.

1723
01:15:58,390 --> 01:16:03,410
La ideo ĉi tie estas ke eble mi havas 24
horoj valoras de eventoj en mia varma tablo.

1724
01:16:03,410 --> 01:16:06,160
Kaj ke varma tablo tuj estos
provizis al tre alta rapideco,

1725
01:16:06,160 --> 01:16:07,950
ĉar ĝi estas prenante multajn datumojn.

1726
01:16:07,950 --> 01:16:10,920
Ĝi prenas multajn datumojn
en kaj mi legas ĝin multe.

1727
01:16:10,920 --> 01:16:14,560
Mi havas multajn operacio
sercxoj kurante kontraŭ tiu datumo.

1728
01:16:14,560 --> 01:16:18,120
>> Post 24 horoj, hej, vi
scias kion, mi ne zorgas.

1729
01:16:18,120 --> 01:16:21,150
Do eble ĉiu noktomezo mi rulo
Mia tablo super al nova tablo

1730
01:16:21,150 --> 01:16:22,430
kaj mi deprovision ĉi tablo.

1731
01:16:22,430 --> 01:16:26,440
Kaj Mi prenos la RCU aj kaj
WCU la malsupren ĉar 24 horojn poste

1732
01:16:26,440 --> 01:16:28,630
Mi ne kuras tiom da
sercxoj kontraŭ tiu datumo.

1733
01:16:28,630 --> 01:16:30,200
Do mi iros por savi monon.

1734
01:16:30,200 --> 01:16:32,940
Kaj eble 30 tagoj mi ne
eĉ bezonas zorgi pri ĉio.

1735
01:16:32,940 --> 01:16:35,020
Mi povus porti la WCU La
tuta vojo malsupren al unu,

1736
01:16:35,020 --> 01:16:36,990
ĉar vi scias kion, ĝi estas
neniam tuj get skribita al.

1737
01:16:36,990 --> 01:16:38,300
La datumoj estas 30 tagojn malnova.

1738
01:16:38,300 --> 01:16:40,000
Ĝi neniam ŝanĝas.

1739
01:16:40,000 --> 01:16:44,200
>> Kaj ĝi estas preskaŭ neniam ricevos legi,
do ni nur prenu ke RCU malsupren al 10.

1740
01:16:44,200 --> 01:16:49,372
Kaj Mi ŝparas barelon da mono sur tiu
datumoj, kaj nur pagi por mia varma datumoj.

1741
01:16:49,372 --> 01:16:52,330
Do jen la grava afero rigardi
ĉe kiam vi rigardas tempo serio

1742
01:16:52,330 --> 01:16:54,716
datumoj eniranta en volumo.

1743
01:16:54,716 --> 01:16:55,590
Tiuj estas strategioj.

1744
01:16:55,590 --> 01:16:58,010
Nun, mi povis nur lasi ĝin
ĉiuj iras al la sama tablo

1745
01:16:58,010 --> 01:16:59,461
kaj simple lasu ke tablo kreski.

1746
01:16:59,461 --> 01:17:01,460
Eventuale, mi tuj
vidu agado temoj.

1747
01:17:01,460 --> 01:17:04,060
Mi tuj devas komenci al arĥivo
iuj de kiuj datiĝas de la tablo,

1748
01:17:04,060 --> 01:17:04,720
kio ne.

1749
01:17:04,720 --> 01:17:07,010
>> Ni multe pli bone
desegni vian kandidatiĝon

1750
01:17:07,010 --> 01:17:08,900
por ke vi povas funkcii tiel dekstra.

1751
01:17:08,900 --> 01:17:11,460
Do estas nur aŭtomata
en la apliko kodo.

1752
01:17:11,460 --> 01:17:13,580
Noktomeze ĉiunokte
ĝi ruliĝas la tablo.

1753
01:17:13,580 --> 01:17:17,170
Eble kion mi bezonas estas glitante
fenestro de 24 horoj de datumoj.

1754
01:17:17,170 --> 01:17:20,277
Tiam sur regula bazo mi
nomante datumojn de la tablo.

1755
01:17:20,277 --> 01:17:22,360
Mi borderas ĝin per
Cron laborposteno kaj mi metas ĝin

1756
01:17:22,360 --> 01:17:24,160
sur tiuj aliaj tabloj,
kiom vi bezonas.

1757
01:17:24,160 --> 01:17:25,940
Do se seguidilla funkcias, tio estas granda.

1758
01:17:25,940 --> 01:17:27,080
Se ne, eltondi ĝin.

1759
01:17:27,080 --> 01:17:29,640
Sed ni tenas tiun varman datumoj
for de via malvarma datumoj.

1760
01:17:29,640 --> 01:17:32,535
Ĝi ŝparos vin multa mono kaj
Fari vian tabloj pli elfaranta.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Do la sekvanta afero ni parolos
pri estas produkto katalogo.

1763
01:17:38,210 --> 01:17:42,000
Produkto katalogo estas
bela komuna uzo kazo.

1764
01:17:42,000 --> 01:17:46,600
Tiu estas fakte tre komuna padrono
ke ni vidos en vario de aferoj.

1765
01:17:46,600 --> 01:17:48,870
Vi scias, Twitter por
Ekzemple, varma tweet.

1766
01:17:48,870 --> 01:17:51,280
Ĉiuj venas kaj
grabbing tiu tweet.

1767
01:17:51,280 --> 01:17:52,680
Produkto katalogo, Mi akiris vendon.

1768
01:17:52,680 --> 01:17:54,120
Mi ricevis varman vendo.

1769
01:17:54,120 --> 01:17:57,277
Mi ricevis 70.000 petoj por
dua alveno por produkto

1770
01:17:57,277 --> 01:17:58,860
priskribo de mia produkto katalogo.

1771
01:17:58,860 --> 01:18:02,384
Ni vidas tion en la detalisto
operacion sufiĉe iomete.

1772
01:18:02,384 --> 01:18:03,550
Do kiel ni trakti tion?

1773
01:18:03,550 --> 01:18:04,924
Ne estas maniero pritrakti tion.

1774
01:18:04,924 --> 01:18:07,110
Ĉiuj miaj uzantoj volas vidi
la sama peco de datumo.

1775
01:18:07,110 --> 01:18:09,410
Ili venas en, samtempe.

1776
01:18:09,410 --> 01:18:11,920
Kaj ili ĉiuj farante petoj
por la sama peco de datumo.

1777
01:18:11,920 --> 01:18:16,240
Tio donas min ke varma klavo, ke granda ruĝa
kontuzon sur mia mapo kiu ni ne ŝatas.

1778
01:18:16,240 --> 01:18:17,720
Kaj tio estas kion tio aspektas.

1779
01:18:17,720 --> 01:18:22,290
Do trans mian ŝlosilon spaco mi ricevas
martelita en la vendo erojn.

1780
01:18:22,290 --> 01:18:24,070
Mi ricevas nenion aliloke.

1781
01:18:24,070 --> 01:18:26,050
>> Kiel mi malpezigi tiun problemon?

1782
01:18:26,050 --> 01:18:28,410
Nu, ni malpezigi tiun kun caché.

1783
01:18:28,410 --> 01:18:33,630
Kaŝmemoro, vi metas esence en-memoro
dispartigo antaŭ la datumbazo.

1784
01:18:33,630 --> 01:18:37,260
Ni sukcesis
[Inaudible] kaŝmemoro, kiom vi

1785
01:18:37,260 --> 01:18:40,260
povas agordi vian propran kaŝmemoro, [inaudible]
kaŝmemoro [? d,?] kiom vi volas.

1786
01:18:40,260 --> 01:18:42,220
Metu ke ĝis antaŭ la datumbazo.

1787
01:18:42,220 --> 01:18:47,250
Kaj Tiel vi povos stoki ke datumoj
el tiuj varmaj klavoj en tiu kaŝmemoro

1788
01:18:47,250 --> 01:18:49,390
spaco kaj tralegu la kaŝmemoro.

1789
01:18:49,390 --> 01:18:51,962
>> Kaj tiam plimultaj viaj legas
komenci rigardante kiel ĉi.

1790
01:18:51,962 --> 01:18:54,920
I got ĉiuj tiuj kaŝmemoron trafas tien
kaj mi ja nenion okazas cxi tie

1791
01:18:54,920 --> 01:18:59,330
ĉar datumbazo sidas malantaŭ la
kaŝmemoro kaj legas neniam veni tra.

1792
01:18:59,330 --> 01:19:02,520
Se mi ŝanĝas la datumojn en la
datenbazo, mi devas ĝisdatigi la kaŝmemoro.

1793
01:19:02,520 --> 01:19:04,360
Ni povas uzi iun
kiel steams fari tion.

1794
01:19:04,360 --> 01:19:07,360
Kaj mi klarigos, kiel tio funkcias.

1795
01:19:07,360 --> 01:19:09,060
Bone, mesaĝado.

1796
01:19:09,060 --> 01:19:11,180
Retpoŝto, ni ĉiuj uzas retpoŝto.

1797
01:19:11,180 --> 01:19:12,540
>> Jen sufiĉe bona ekzemplo.

1798
01:19:12,540 --> 01:19:14,950
Ni havas ian mesaĝojn tablo.

1799
01:19:14,950 --> 01:19:17,040
Kaj ni akiris enirkesto kaj sendotaj.

1800
01:19:17,040 --> 01:19:19,760
Jen kion la SQL volus
aspekti konstrui ke enirkesto.

1801
01:19:19,760 --> 01:19:23,350
Ni ia uzas samspecan
de strategio uzi GSI a, GSI La

1802
01:19:23,350 --> 01:19:25,320
por mia enirkesto kaj mia sendotaj.

1803
01:19:25,320 --> 01:19:27,600
Do mi akiris krudan reagoj
en miajn mesaĝojn tablo.

1804
01:19:27,600 --> 01:19:30,194
Kaj la unua alproksimiĝo al tiu
povus esti, diri, OK, neniu problemo.

1805
01:19:30,194 --> 01:19:31,110
Mi havas krudan mesaĝojn.

1806
01:19:31,110 --> 01:19:33,710
Mesaĝoj venanta [inaudible],
mesaĝo ID, jen granda.

1807
01:19:33,710 --> 01:19:35,070
Tio estas mia unika hash.

1808
01:19:35,070 --> 01:19:38,280
Mi tuj kreos du GSI-a, unu
por mia inbox, unu por mia sendotaj.

1809
01:19:38,280 --> 01:19:40,530
Kaj la unua afero Mi faros
estas mi diros mian hash ŝlosilo

1810
01:19:40,530 --> 01:19:43,310
tuj estos la ricevonto kaj
Mi tuj aranĝi sur la dato.

1811
01:19:43,310 --> 01:19:44,220
Tio estas mirinda.

1812
01:19:44,220 --> 01:19:45,890
Mi akiris mian belan vidon tie.

1813
01:19:45,890 --> 01:19:47,780
Sed estas iom afero tie.

1814
01:19:47,780 --> 01:19:50,891
Kaj vi kuros en ĉi en
interrilata datumbazoj tiel.

1815
01:19:50,891 --> 01:19:52,390
Ili vokis vertikale dispartiganta.

1816
01:19:52,390 --> 01:19:55,840
Vi volas gardi viajn grandaj datumoj
for de via malgranda datumo.

1817
01:19:55,840 --> 01:20:00,470
>> Kaj la kialo kial estas ĉar mi gotta
iri legi la erojn akiri la atributojn.

1818
01:20:00,470 --> 01:20:05,570
Kaj se mia korpoj estas ĉiuj en ĉi tie,
tiam legas nur kelkaj erojn

1819
01:20:05,570 --> 01:20:08,560
se mia korpo longo estas
averaĝanta 256 kilobajtoj ĉiu,

1820
01:20:08,560 --> 01:20:10,991
la math ricevas belajn malbela.

1821
01:20:10,991 --> 01:20:12,490
Do diras mi volas legi David enirkesto.

1822
01:20:12,490 --> 01:20:14,520
David enirkesto havas 50 erojn.

1823
01:20:14,520 --> 01:20:17,880
La mezumo kaj grandeco estas 256 kilobajtoj.

1824
01:20:17,880 --> 01:20:21,730
Jen mia konvertiĝo rilatumo
por RCU La estas kvar kilobajtoj.

1825
01:20:21,730 --> 01:20:24,450
>> OK, ni iru kun
eventuale konsekvenca legas.

1826
01:20:24,450 --> 01:20:28,640
Mi ankoraŭ manĝas 1600 RCU La
nur legi David enirkesto.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
OK, nun ni pensas
pri kiel la app laboroj.

1829
01:20:31,980 --> 01:20:35,340
Se mi estas en retpoŝto app kaj
Mi rigardas mian leterkeston,

1830
01:20:35,340 --> 01:20:39,680
kaj mi rigardas la korpon de ĉiu mesaĝo,
ne, mi rigardas la resumoj.

1831
01:20:39,680 --> 01:20:41,850
Mi rigardis nur la titolaj.

1832
01:20:41,850 --> 01:20:46,310
Do ni konstruu tablo strukturo
kiu aspektas pli kiel tiu.

1833
01:20:46,310 --> 01:20:49,470
>> Do jen la informo
ke mia laborfluo bezonas.

1834
01:20:49,470 --> 01:20:50,890
Ĝi estas en mia enirkesto GSI.

1835
01:20:50,890 --> 01:20:53,800
Ĝi estas la dato, la sendinto,
la temo, kaj poste

1836
01:20:53,800 --> 01:20:56,790
la mesaĝo ID, kiuj punktoj
reen al la mesaĝoj tablo

1837
01:20:56,790 --> 01:20:57,850
kie mi povas ricevi la korpon.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Nu, tiuj estus rekordo IDs.

1840
01:21:04,420 --> 01:21:09,850
Ili notus reen al la
listero IDs sur la Dinamo DB tablo.

1841
01:21:09,850 --> 01:21:12,220
Ĉiu indekso ĉiam creates--
ĉiam havas la eron

1842
01:21:12,220 --> 01:21:15,750
ID kadre of-- ke
venas kun la indico.

1843
01:21:15,750 --> 01:21:17,414
>> Bone.

1844
01:21:17,414 --> 01:21:19,080
Spektantaro: Ĝi rakontas ĝin kie ĝi estas stokita?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Jes, ĝi diras
exactly-- jen ĝuste kion ĝi faras.

1846
01:21:21,420 --> 01:21:22,644
Ĝi diras jen mia re rekordo.

1847
01:21:22,644 --> 01:21:24,310
Kaj ĝi malebligos montri ĝin al mia re rekordo.

1848
01:21:24,310 --> 01:21:26,460
Ekzakte.

1849
01:21:26,460 --> 01:21:29,490
Bone, do nun mia inbox estas
fakte multe pli malgranda.

1850
01:21:29,490 --> 01:21:32,210
Kaj tio vere subtenas
la laborfluo de email app.

1851
01:21:32,210 --> 01:21:34,230
Do mia inbox, mi klakas.

1852
01:21:34,230 --> 01:21:38,160
Mi iros kune kaj mi alklakas la mesaĝo,
tio estas kiam mi devas iri ricevi la korpon,

1853
01:21:38,160 --> 01:21:40,180
ĉar mi tuj
iri al malsama vido.

1854
01:21:40,180 --> 01:21:43,870
Do se vi opinias pri MVC tipo de
kadro, modelo view adaptilo.

1855
01:21:43,870 --> 01:21:46,120
>> La modelo enhavas la
datumo kiu la vido bezonoj

1856
01:21:46,120 --> 01:21:48,130
kaj la regilo interagas kun.

1857
01:21:48,130 --> 01:21:51,670
Kiam mi ŝanĝas la kadro, kiam
Mi ŝanĝas la perspektivon,

1858
01:21:51,670 --> 01:21:55,080
ĝi estas BONE reiri al la
servilo kaj repoblar la modelon,

1859
01:21:55,080 --> 01:21:56,860
ĉar tio estas kion la uzanto atendas.

1860
01:21:56,860 --> 01:22:00,530
Kiam ili ŝanĝas opiniojn, tio estas kiam
ni povas reiri al la datumbazo.

1861
01:22:00,530 --> 01:22:02,480
Do retpoŝton, klaki.

1862
01:22:02,480 --> 01:22:03,710
Mi serĉas la korpo.

1863
01:22:03,710 --> 01:22:04,330
Ronda vojaĝo.

1864
01:22:04,330 --> 01:22:05,680
Iri preni la korpon.

1865
01:22:05,680 --> 01:22:06,950
>> Mi legis multe malpli datumojn.

1866
01:22:06,950 --> 01:22:09,960
Mi nur legis la korpoj kiuj
David bezonas kiam li bezonas ilin.

1867
01:22:09,960 --> 01:22:14,230
Kaj mi ne brulos en 1600
RCU simple montri sian leterkeston.

1868
01:22:14,230 --> 01:22:17,670
Do nun that-- tiamaniere
ke LSI aŭ GSI-- Mi bedaŭras,

1869
01:22:17,670 --> 01:22:19,900
GSI, laborus el.

1870
01:22:19,900 --> 01:22:25,450
Ni havas niajn hash sur la ricevanto.

1871
01:22:25,450 --> 01:22:27,030
Ni havas la gamo ŝlosilo sur la dato.

1872
01:22:27,030 --> 01:22:31,380
Kaj ni havas la projektita atributoj
ke ni bezonas nur por apogi la vidon.

1873
01:22:31,380 --> 01:22:34,300
>> Ni rotacias ke por la sendotaj.

1874
01:22:34,300 --> 01:22:35,770
Hash pri sendinto.

1875
01:22:35,770 --> 01:22:39,612
Kaj en esenco, ni havas
la tre bona, pura rigardo.

1876
01:22:39,612 --> 01:22:41,570
Kaj estas basically-- ni
havas tiun belan mesaĝojn

1877
01:22:41,570 --> 01:22:45,870
tablo ke tio esti disvastigi bele ĉar
ĝi estas hash nur, hashed mesaĝon ID.

1878
01:22:45,870 --> 01:22:51,750
Kaj ni havas du indeksoj ke
estas turnanta for de tiu tablo.

1879
01:22:51,750 --> 01:22:57,411
Bone, do ideo tie estas ne
teni la granda datumo kaj tiu malgranda datumo

1880
01:22:57,411 --> 01:22:57,910
kune.

1881
01:22:57,910 --> 01:23:00,700
Partition vertikale,
dispartigi tiuj tabloj.

1882
01:23:00,700 --> 01:23:03,150
Ne legu datumojn vi ne devas.

1883
01:23:03,150 --> 01:23:04,850
Bone, videoludado.

1884
01:23:04,850 --> 01:23:06,990
Ni ĉiuj ŝatas ludojn.

1885
01:23:06,990 --> 01:23:10,902
Almenaŭ mi ŝatas ludojn tiam.

1886
01:23:10,902 --> 01:23:12,735
Do iuj de la aĵoj
ke ni trakti kiam

1887
01:23:12,735 --> 01:23:14,193
ni pensas videoludado, dekstra?

1888
01:23:14,193 --> 01:23:16,999
Gaming tiujn tagojn, speciale moveblaj
videoludado, estas ĉiuj pri pensado.

1889
01:23:16,999 --> 01:23:19,540
Kaj mi tuj turni tie
iomete for de DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Mi tuj alportos en
iuj de la diskuto

1891
01:23:21,373 --> 01:23:24,240
chirkau la
aliaj AWS teknologioj.

1892
01:23:24,240 --> 01:23:28,930
>> Sed la ideo pri videoludado estas pensi
proksimume en terminoj de APIs, API kiu estas,

1893
01:23:28,930 --> 01:23:31,730
Ĝenerale parolante, HTTP kaj JSON.

1894
01:23:31,730 --> 01:23:34,550
Ĝi estas kiel moveblaj ludoj ia
interagi kun siaj reen randoj.

1895
01:23:34,550 --> 01:23:35,850
Ili faras JSON afisxo.

1896
01:23:35,850 --> 01:23:40,660
Ili ricevas datumojn, kaj ĝi estas ĉio,
Ĝenerale parolante, en bela JSON APIs.

1897
01:23:40,660 --> 01:23:44,950
>> Aĵoj kiel akiri amikoj, akiru
la leaderboard, interŝanĝi datumojn,

1898
01:23:44,950 --> 01:23:47,699
uzanto generita enhavo,
puŝi reen ĝis la sistemo,

1899
01:23:47,699 --> 01:23:49,740
tiuj estas specoj de aferoj
ke ni tuj faros.

1900
01:23:49,740 --> 01:23:52,542
Duuma valoraĵo datumoj, ĉi datumoj
eble ne sidas en la datumbazo.

1901
01:23:52,542 --> 01:23:54,250
Tio povas sidi en
objekto vendejo, dekstra?

1902
01:23:54,250 --> 01:23:56,541
Sed la datumbazo tuj
finas dirante la sistemo,

1903
01:23:56,541 --> 01:23:59,140
rakontanta la aplikaĵo
kien iri akiri ĝin.

1904
01:23:59,140 --> 01:24:03,550
Kaj neeviteble, multijugador
serviloj, dorso fino infrastrukturo,

1905
01:24:03,550 --> 01:24:06,180
kaj desegnita por alta
disponeblo kaj escalabilidad.

1906
01:24:06,180 --> 01:24:09,400
Tiuj estas aferoj kiujn ni ĉiuj deziras
en la videoludado infrastrukturo hodiaŭ.

1907
01:24:09,400 --> 01:24:12,160
>> Do ni rigardu
kion tio aspektas.

1908
01:24:12,160 --> 01:24:16,070
Got kernan malantauxo,
tre simpla.

1909
01:24:16,070 --> 01:24:19,880
Ni havas sistemon ĉi tie kun
multoblaj disponeblo zonoj.

1910
01:24:19,880 --> 01:24:23,780
Ni parolis pri AZS kiel being-- opinias
de ili kiel apartaj datumoj centroj.

1911
01:24:23,780 --> 01:24:26,040
Pli ol unu datumejo
po AZ, sed tio estas bone,

1912
01:24:26,040 --> 01:24:28,831
nur pensas pri ili kiel apartaj datumoj
centroj kiuj estas geografie

1913
01:24:28,831 --> 01:24:30,090
kaj kulpo izolita.

1914
01:24:30,090 --> 01:24:32,172
>> Ni tuj havi
paro EC2 petskriboj.

1915
01:24:32,172 --> 01:24:33,880
Ni tuj devas
iuj malantauxo servilo.

1916
01:24:33,880 --> 01:24:35,800
Eble se vi estas legaco
arkitekturo, ni estas

1917
01:24:35,800 --> 01:24:38,920
uzante kion ni nomas RDS,
rilata datumbazo servoj.

1918
01:24:38,920 --> 01:24:42,040
Povus esti MSSQL, MySQL,
aŭ io simila.

1919
01:24:42,040 --> 01:24:47,080
Tiu estas maniero multe aplikoj
estas desegnitaj hodiaŭ.

1920
01:24:47,080 --> 01:24:49,594
>> Nu ni eble volas iri kun
tio estas kiam ni grimpi eksteren.

1921
01:24:49,594 --> 01:24:51,510
Ni iru antaŭen kaj metis
la S3 sitelo tie supre.

1922
01:24:51,510 --> 01:24:54,200
Kaj ke S3 sitelo anstataŭ servanta
tiujn celojn de nia servers--

1923
01:24:54,200 --> 01:24:55,220
ni povus fari tion.

1924
01:24:55,220 --> 01:24:57,210
Vi metis ĉiujn viajn duuma
objektojn sur via serviloj

1925
01:24:57,210 --> 01:24:59,751
kaj vi povas uzi tiujn servilo
petskribojn por servi tiun datumojn supren.

1926
01:24:59,751 --> 01:25:01,860
Sed tio estas sufiĉe multekosta.

1927
01:25:01,860 --> 01:25:05,107
>> Pli bona maniero por fari estas iri antaŭen kaj
metis tiujn objektojn en S3 sitelo.

1928
01:25:05,107 --> 01:25:06,315
S3 estas objekto repositorios.

1929
01:25:06,315 --> 01:25:10,860
Ĝi estas konstruita specife por
utilante tiujn tipojn de aferoj.

1930
01:25:10,860 --> 01:25:13,690
Kaj forkuru Viaj klientoj peti
rekte de tiuj objekto siteloj,

1931
01:25:13,690 --> 01:25:15,390
offload la serviloj.

1932
01:25:15,390 --> 01:25:17,020
Do ni komencas grimpi tie.

1933
01:25:17,020 --> 01:25:19,140
>> Nun ni alvenis uzantoj ĉiuj super la mondo.

1934
01:25:19,140 --> 01:25:19,730
Mi alvenis uzantoj.

1935
01:25:19,730 --> 01:25:23,380
Mi bezonas havi enhavon loke
situas proksime al ĉi tiuj uzantoj, dekstra?

1936
01:25:23,380 --> 01:25:26,200
Mi kreis S3 sitelo
kiel mia fonto dosierujo.

1937
01:25:26,200 --> 01:25:29,370
Kaj mi frente kiu kun
la CloudFront dissendo.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront estas KD kaj
enhavo transdono reto.

1939
01:25:31,720 --> 01:25:35,750
Esence ĝi prenas datumoj kiuj vi specifas
kaj cachés ŝin ĉiuj super la interreto

1940
01:25:35,750 --> 01:25:39,230
tiel uzantoj ĉie povas havi
tre rapida respondo kiam

1941
01:25:39,230 --> 01:25:40,960
ili petas tiujn celojn.

1942
01:25:40,960 --> 01:25:41,960
>> Do vi fari ideon.

1943
01:25:41,960 --> 01:25:48,230
Vi estas speco de ekspluatanta ĉiuj
aspektoj de AWS tie akiri tiun faris.

1944
01:25:48,230 --> 01:25:50,790
Kaj fine, ni ĵetu
en aŭtomatan grimpita grupo.

1945
01:25:50,790 --> 01:25:52,737
Do nia AC2 petskribojn
de nia ludo serviloj,

1946
01:25:52,737 --> 01:25:54,820
kiel ili komencas akiri pli okupata
kaj pli okupataj kaj pli okupata,

1947
01:25:54,820 --> 01:25:57,236
Ili simple ŝpini alian
Ekzemple, ŝpini alia petskribo,

1948
01:25:57,236 --> 01:25:58,210
ŝpini alia petskribo.

1949
01:25:58,210 --> 01:26:02,090
Do la teknologio AWS havas, ĝi
permesas specifi parametrojn

1950
01:26:02,090 --> 01:26:04,650
ĉirkaŭ kiu via serviloj kreskos.

1951
01:26:04,650 --> 01:26:08,110
Do vi povas havi n nombro de serviloj
tie ekstere ĉe ajna donita tempon.

1952
01:26:08,110 --> 01:26:11,870
Kaj se via ŝarĝo foriras, ili timige
ŝrumpi, la nombro estos ŝrumpi.

1953
01:26:11,870 --> 01:26:15,250
Kaj se la ŝarĝo revenas,
gxi devos kreski reen eksteren, elaste.

1954
01:26:15,250 --> 01:26:17,050
>> Do tiu aspektas granda.

1955
01:26:17,050 --> 01:26:19,800
Ni havas multajn EC2 petskriboj.

1956
01:26:19,800 --> 01:26:21,671
Ni povas meti en kaŝmemoron
antaŭ la datumbazoj,

1957
01:26:21,671 --> 01:26:23,045
klopodi akceli la datumbazoj.

1958
01:26:23,045 --> 01:26:25,030
La sekva punkto de premo
tipe personoj vidos

1959
01:26:25,030 --> 01:26:28,850
Estas ili grimpi ludo uzanta
interrilata datumbaza sistemo.

1960
01:26:28,850 --> 01:26:30,790
Jeez, la datumbazo
agado estas terura.

1961
01:26:30,790 --> 01:26:31,932
Kiel ni plibonigi tiun?

1962
01:26:31,932 --> 01:26:33,640
Ni provu meti
kaŝmemoro antaŭ tiu.

1963
01:26:33,640 --> 01:26:36,780
>> Nu, cache ne funkcias
tiel granda en ludoj, bone?

1964
01:26:36,780 --> 01:26:39,330
Por ludoj, skribo estas dolora.

1965
01:26:39,330 --> 01:26:40,930
Ludoj estas tre skribi peza.

1966
01:26:40,930 --> 01:26:43,610
Cache ne funkcias kiam vi estas
skribi pezaj ĉar vi ĉiam

1967
01:26:43,610 --> 01:26:44,610
akiris ĝisdatigi la kaŝmemoro.

1968
01:26:44,610 --> 01:26:47,780
Vi aktualigi la kaŝmemoron, estas
senrilataj esti caching.

1969
01:26:47,780 --> 01:26:49,780
Ĝi estas fakte ĵus ekstra laboro.

1970
01:26:49,780 --> 01:26:51,970
>> Do kie ni iras tien?

1971
01:26:51,970 --> 01:26:54,400
Vi havas grandan botelkolo
tie malsupre en la datumbazo.

1972
01:26:54,400 --> 01:26:57,661
Kaj la loko iri
evidente estas dispartiganta.

1973
01:26:57,661 --> 01:26:59,410
Dispartiganta ne
facile fari kiam vi estas

1974
01:26:59,410 --> 01:27:01,900
kontraktanta kun rilata datumbazoj.

1975
01:27:01,900 --> 01:27:05,080
Kun interrilata datumbazoj, vi estas
respondeca por administrado, efike,

1976
01:27:05,080 --> 01:27:06,210
la ŝlosilo spaco.

1977
01:27:06,210 --> 01:27:10,527
Vi diras ke uzantoj inter A kaj M
iri tien, inter N kaj Z iri tien.

1978
01:27:10,527 --> 01:27:12,360
Kaj vi ŝaltanta
trans la apliko.

1979
01:27:12,360 --> 01:27:15,000
Do vi pritraktas
tiu dispartigo datumfonto.

1980
01:27:15,000 --> 01:27:18,670
Vi havas transaccionales devigoj
kiuj ne ampleksas vandoj.

1981
01:27:18,670 --> 01:27:20,560
Vi havas ĉiajn
messiness ke vi estas

1982
01:27:20,560 --> 01:27:23,040
kontraktanta kun malsupre provas
trakti grimpante eksteren

1983
01:27:23,040 --> 01:27:25,120
kaj konstruante pli grandan infrastrukturon.

1984
01:27:25,120 --> 01:27:27,284
Estas nur neniu amuzo.

1985
01:27:27,284 --> 01:27:30,930
>> Publiko: Do ​​vi diras, ke
kreskanta fonto punktoj akcelas

1986
01:27:30,930 --> 01:27:31,430
la procezo?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Kreskanta?

1988
01:27:32,513 --> 01:27:33,520
Publiko: Fonto punktoj.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Fonto punktoj?

1990
01:27:34,410 --> 01:27:37,500
Publiko: El la informon,
kie la informo estas venanta de?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: No.

1992
01:27:38,250 --> 01:27:41,820
Kion mi diras estas pliigante la
numeron de vandoj en la magazeno de datumoj

1993
01:27:41,820 --> 01:27:44,060
plibonigas traigivo.

1994
01:27:44,060 --> 01:27:48,300
Do kio okazas ĉi tie estas uzantoj
venanta en la EC2 ekzemple tien,

1995
01:27:48,300 --> 01:27:50,780
bone, se mi bezonas uzanto
jen A al M, mi iros tien.

1996
01:27:50,780 --> 01:27:53,560
El N al p, mi iros tien.

1997
01:27:53,560 --> 01:27:55,060
De P al Z, mi iros tien.

1998
01:27:55,060 --> 01:27:57,120
>> Publiko: OK, tiuj tiel tiuj estas
ĉiuj stokitaj en malsamaj nodoj?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Jes.

2000
01:27:57,911 --> 01:28:00,210
Konsideru tiajxojn
malsamaj siloj de datumoj.

2001
01:28:00,210 --> 01:28:01,660
Do vi devi fari tion.

2002
01:28:01,660 --> 01:28:02,910
Se vi provas fari
tiu, se vi provas

2003
01:28:02,910 --> 01:28:05,730
grimpi sur rilata platformo,
jen kion vi faras.

2004
01:28:05,730 --> 01:28:08,100
Vi prenas datumojn kaj
vi tranĉante ĝin malsupren.

2005
01:28:08,100 --> 01:28:10,975
Kaj vi dispartiganta ĝin trans
multnombraj petskriboj de la datumbazo.

2006
01:28:10,975 --> 01:28:13,580
Kaj vi administri ĉiuj kiuj
ĉe la apliko parto.

2007
01:28:13,580 --> 01:28:14,729
Ĝi estas neniu amuzo.

2008
01:28:14,729 --> 01:28:15,770
Do kion ni volas iri?

2009
01:28:15,770 --> 01:28:20,240
Ni volas iri DynamoDB, plene sukcesis,
NoSQL datumoj vendejo, provizo traigivo.

2010
01:28:20,240 --> 01:28:22,680
Ni uzas malĉefa indeksoj.

2011
01:28:22,680 --> 01:28:26,154
Ĝi estas esence HTTP API kaj
inkluzivas dokumenton subteno.

2012
01:28:26,154 --> 01:28:28,570
Do vi ne devas maltrankvili
pri ajna el kiuj dispartiganta.

2013
01:28:28,570 --> 01:28:30,740
Ni faros ĉion por vi.

2014
01:28:30,740 --> 01:28:33,260
Do nun, anstataŭ, vi
simple skribu al la tablo.

2015
01:28:33,260 --> 01:28:36,490
Se la tablo devas esti dispartigita,
kio okazas malantaŭ la scenoj.

2016
01:28:36,490 --> 01:28:40,642
Vi tute izolita
de tiu kiel desarrollador.

2017
01:28:40,642 --> 01:28:42,350
Do ni parolu pri
iuj de la uzo kazoj

2018
01:28:42,350 --> 01:28:47,564
ke ni trafos en videoludado, komuna
videoludado scenaroj, leaderboard.

2019
01:28:47,564 --> 01:28:49,980
Do vi hvas uzantoj enirantan
la BoardNames ke ili estas

2020
01:28:49,980 --> 01:28:52,930
sur la partituroj por tiu uzanto.

2021
01:28:52,930 --> 01:28:57,700
Ni povus hashing sur la komputila uzantnomo,
kaj tiam ni havas gamon sur la ludo.

2022
01:28:57,700 --> 01:28:59,960
Do ĉiu uzanto volas vidi
la tuta ludo estas ludis li

2023
01:28:59,960 --> 01:29:01,770
kaj lia tuta supro partituro
trans tuta ludo.

2024
01:29:01,770 --> 01:29:04,000
Do jen lia persona leaderboard.

2025
01:29:04,000 --> 01:29:10,010
>> Nun mi volas iri en kaj mi volas get--
do mi ricevas tiujn personajn leaderboards.

2026
01:29:10,010 --> 01:29:12,827
Kion mi volas fari estas iri preni
la supro partituro tra ĉiuj uzantoj.

2027
01:29:12,827 --> 01:29:13,660
Do kiel mi faru tion?

2028
01:29:13,660 --> 01:29:18,070
Kiam mia konanto estas hashed sur
la komputila uzantnomo, intervalis sur la ludo,

2029
01:29:18,070 --> 01:29:20,740
bone mi tuj iros antaŭen
kaj restrukturi, krei GSI,

2030
01:29:20,740 --> 01:29:22,370
kaj mi tuj restrukturi ke datumoj.

2031
01:29:22,370 --> 01:29:27,310
>> Nun mi tuj hash sur la
BoardName, kiu estas la ludo.

2032
01:29:27,310 --> 01:29:29,800
Kaj mi tuj oscili sur la supro partituro.

2033
01:29:29,800 --> 01:29:31,540
Kaj nun mi kreis malsamajn siteloj.

2034
01:29:31,540 --> 01:29:34,790
Mi uzas la saman tablon,
la sama elemento datumoj.

2035
01:29:34,790 --> 01:29:39,870
Sed mi kreante sitelo kiu donas
mi agregación de supro partituro por ludo.

2036
01:29:39,870 --> 01:29:43,180
>> Kaj mi povas konsulti ke tablo
ricevi tiun informon.

2037
01:29:43,180 --> 01:29:50,890
Do, mi metis ke query desegnon ĝis
esti apogita per sekundara indekso.

2038
01:29:50,890 --> 01:29:54,556
Nun ili povas ordo laŭ BoardName
kaj ordo laŭ TopScore, depende.

2039
01:29:54,556 --> 01:29:57,180
Do vi povas vidi, ĉi tiuj estas tipoj
de uzkazoj vi ricevas en videoludado.

2040
01:29:57,180 --> 01:30:02,190
Alia bona uzo kazo ni preni en videoludado
estas premioj kaj kiuj estas gajnis la premiojn.

2041
01:30:02,190 --> 01:30:05,340
Kaj tiu estas granda uzo kazo
kie ni nomas maldensa indeksoj.

2042
01:30:05,340 --> 01:30:07,340
Maldensa indeksoj estas la
kapablecon produkti

2043
01:30:07,340 --> 01:30:10,850
indico kiu ne nepre
enhavi ĉiun objekton sur la tablo.

2044
01:30:10,850 --> 01:30:11,470
Kaj kial ne?

2045
01:30:11,470 --> 01:30:14,540
Pro la atributo kiu estas estanta
indeksita ne ekzistas sur ĉiu ero.

2046
01:30:14,540 --> 01:30:16,460
>> Do en ĉi tiu aparta
uzi kazo, mi diras,

2047
01:30:16,460 --> 01:30:19,240
Vi scias kion, Mi tuj
krei atributo nomata Award.

2048
01:30:19,240 --> 01:30:22,970
Kaj mi tuj doni ĉiun uzanton
kiu havas premion kiuj atribuas.

2049
01:30:22,970 --> 01:30:25,950
Uzantoj kiuj ne havas premiojn estas
ne tuj havas tiun atributon.

2050
01:30:25,950 --> 01:30:27,800
Do kiam mi krei la
indekso, la nuraj uzantoj

2051
01:30:27,800 --> 01:30:28,960
kiuj tuj montros
supren en la indekso estas

2052
01:30:28,960 --> 01:30:31,050
tiuj kiuj vere gajnis premiojn.

2053
01:30:31,050 --> 01:30:34,440
Do tio estas granda vojo esti kapabla
krei filtrita indeksoj ke

2054
01:30:34,440 --> 01:30:40,580
Estas tre, tre selectiva kiu ne
devas indeksi la tuta tablo.

2055
01:30:40,580 --> 01:30:43,050
>> Do ni estas duumaj malalta ĝustatempe tie.

2056
01:30:43,050 --> 01:30:49,190
Mi tuj iros antaŭen kaj salti
eksteren kaj transsaltu tiun scenaron.

2057
01:30:49,190 --> 01:30:52,625
Paroli iomete about--

2058
01:30:52,625 --> 01:30:54,460
>> Publiko: Povas min demandas rapidan demandon?

2059
01:30:54,460 --> 01:30:56,722
Unu estas skribi peza?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Kio estas?

2061
01:30:57,680 --> 01:30:58,596
Publiko: Skribu peza.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Skribu peza.

2063
01:31:01,270 --> 01:31:03,460
Mi vidu.

2064
01:31:03,460 --> 01:31:06,220
>> Publiko: Aŭ estas kiu ne
io vi povas simple

2065
01:31:06,220 --> 01:31:08,809
voĉon al en demando de duaj?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Ni iru
tra la balotado scenaro.

2067
01:31:10,850 --> 01:31:11,670
Ĝi ne estas tiel malbona.

2068
01:31:11,670 --> 01:31:14,580
Ĉu vi infanoj havas kelkajn minutojn?

2069
01:31:14,580 --> 01:31:15,860
BONE.

2070
01:31:15,860 --> 01:31:17,890
>> Do ni parolos pri balotado.

2071
01:31:17,890 --> 01:31:20,250
Do reala tempo balotado, ni havas
postulojn por balotado.

2072
01:31:20,250 --> 01:31:25,250
Postuloj estas ke ni permesos
ĉiu persono voĉdoni nur unufoje.

2073
01:31:25,250 --> 01:31:28,060
Ni volas neniu povi
ŝanĝi sian voĉdonon.

2074
01:31:28,060 --> 01:31:31,045
Ni volas realtempan agregación
kaj analytics por demografio

2075
01:31:31,045 --> 01:31:34,210
ke ni tuj estos
montrante al uzantoj en la retejo.

2076
01:31:34,210 --> 01:31:35,200
>> Pensu pri tiu scenaro.

2077
01:31:35,200 --> 01:31:37,550
Ni laboras multajn realo
TV montras kie ili estas

2078
01:31:37,550 --> 01:31:38,960
fari tiujn ĝusta tipo de aĵoj.

2079
01:31:38,960 --> 01:31:41,584
Do vi povas pensi pri la scenaro,
ni havas milionojn kaj milionoj

2080
01:31:41,584 --> 01:31:43,959
de adoleskaj knabinoj tie
kun liaj poŝtelefonoj

2081
01:31:43,959 --> 01:31:46,250
kaj voĉdonas kaj voĉdonado, kaj
voĉdoni por ĉiuj kiu estas

2082
01:31:46,250 --> 01:31:48,610
trovas esti la plej populara.

2083
01:31:48,610 --> 01:31:50,830
Tiuj estas iuj de la
postulojn ni elĉerpas.

2084
01:31:50,830 --> 01:31:52,990
>> Kaj tiel la unua preni
solvi tiun problemon

2085
01:31:52,990 --> 01:31:55,090
estus konstrui
tre simpla apliko.

2086
01:31:55,090 --> 01:31:56,490
Do mi havas ĉi tiu app.

2087
01:31:56,490 --> 01:31:57,950
Mi havas kelkajn balotantojn tie.

2088
01:31:57,950 --> 01:31:59,980
Ili envenis, ili batis la balotado app.

2089
01:31:59,980 --> 01:32:03,440
Mi havas iom da krudaj voĉoj tablo
Mi nur renversi tiujn voĉdonojn en.

2090
01:32:03,440 --> 01:32:05,780
Mi havas iom aldonita
voĉdonoj tablo ke

2091
01:32:05,780 --> 01:32:09,490
faros mian Analytics kaj demografion,
kaj ni metos ĉiuj ĉi tien.

2092
01:32:09,490 --> 01:32:11,420
>> Kaj tiu estas granda.

2093
01:32:11,420 --> 01:32:12,332
Vivo estas bona.

2094
01:32:12,332 --> 01:32:15,040
Vivo bona ĝis ni trovos ke
ĉiam nur unu aŭ du

2095
01:32:15,040 --> 01:32:16,879
popolo, kiu estas populara en elekto.

2096
01:32:16,879 --> 01:32:19,420
Ekzistas nur unu aŭ du aferojn
ke homoj vere zorgas pri.

2097
01:32:19,420 --> 01:32:22,340
Kaj se vi voĉdoni ĉe
skalo, subite mi

2098
01:32:22,340 --> 01:32:26,360
tuj estos martelante la infero el
du kandidatoj, unu aux du kandidatoj.

2099
01:32:26,360 --> 01:32:29,390
Tre limigita nombro da eroj
personoj trovas esti populara.

2100
01:32:29,390 --> 01:32:31,710
>> Tiu ne estas bona dezajno ŝablono.

2101
01:32:31,710 --> 01:32:33,549
Tiu estas fakte
tre maltaŭga modelo

2102
01:32:33,549 --> 01:32:36,340
ĉar ĝi kreas precize kion ni
parolis pri kio estis varma klavoj.

2103
01:32:36,340 --> 01:32:38,960
Varmaj ŝlosiloj estas io ni ne ŝatas.

2104
01:32:38,960 --> 01:32:40,470
>> Nu do kiel ni ripari tiun?

2105
01:32:40,470 --> 01:32:47,640
Kaj vere, la maniero por korekti tiun estas
per prenante tiujn kandidato siteloj

2106
01:32:47,640 --> 01:32:51,490
kaj por ĉiu kandidato ni havas,
ni tuj append hazarda valoro,

2107
01:32:51,490 --> 01:32:54,192
iu kiun ni scias, hazarda
valoro inter unu kaj 100,

2108
01:32:54,192 --> 01:32:56,620
inter 100 kaj 1,000,
aŭ inter unu kaj 1.000,

2109
01:32:56,620 --> 01:32:59,940
tamen multaj hazarda valoroj vi volas
append sur la fino de tiu kandidato.

2110
01:32:59,940 --> 01:33:01,330
>> Kaj kion mi vere faris tiam?

2111
01:33:01,330 --> 01:33:05,830
Se mi uzas la kandidato ID kiel
la sitelon al entuta voĉdonoj,

2112
01:33:05,830 --> 01:33:08,780
se mi aldonis hazarda
numeron al la fino de tiu,

2113
01:33:08,780 --> 01:33:12,000
Mi kreis nun 10 siteloj, a
cent sitelojn, mil siteloj

2114
01:33:12,000 --> 01:33:14,160
ke mi agregi voĉdonoj laŭlarĝe.

2115
01:33:14,160 --> 01:33:18,030
>> Do mi havas milionojn kaj milionoj,
kaj milionoj de registroj venon

2116
01:33:18,030 --> 01:33:22,050
por tiuj kandidatoj, mi elĵetas
tiuj voĉdonoj trans Kandidato a_1

2117
01:33:22,050 --> 01:33:24,630
tra Kandidato A_100, ĉar
ĉiufoje voĉdono envenas,

2118
01:33:24,630 --> 01:33:26,530
Mi generante hazarda
valoro inter unu kaj 100.

2119
01:33:26,530 --> 01:33:29,446
Mi tacking ĝin sur la fino de la
kandidato tiu persono voĉdonis por.

2120
01:33:29,446 --> 01:33:31,120
Mi dumpingo gxin en tiun rubujon.

2121
01:33:31,120 --> 01:33:33,910
>> Nun malantauxe, mi scias
ke mi havas cent sitelojn.

2122
01:33:33,910 --> 01:33:36,350
Do kiam mi deziras antaŭeniri
kaj aldonita la voĉdonoj,

2123
01:33:36,350 --> 01:33:38,244
Mi legis el ĉiuj tiuj siteloj.

2124
01:33:38,244 --> 01:33:39,160
Do mi iru antaŭen kaj aldoni.

2125
01:33:39,160 --> 01:33:42,410
Kaj tiam mi la disjxetu kolektu
kie mi eliras kaj diru hey,

2126
01:33:42,410 --> 01:33:45,399
Vi scias kio, tiu kandidato ŝlosilo
spacoj estas super cent sitelojn.

2127
01:33:45,399 --> 01:33:47,940
Mi tuj kunvenigu cxiujn
voĉdonu el tiuj cent sitelojn.

2128
01:33:47,940 --> 01:33:49,981
Mi tuj aldonas
ili kaj mi tuj diros,

2129
01:33:49,981 --> 01:33:53,830
Kandidato A nun havas
totala voĉdono grafo de x.

2130
01:33:53,830 --> 01:33:55,690
>> Nun ambaŭ la registran
query kaj la legado query

2131
01:33:55,690 --> 01:33:58,160
estas bele distribuita
ĉar mi skribas trans

2132
01:33:58,160 --> 01:34:00,320
kaj mi legas trans centoj de klavoj.

2133
01:34:00,320 --> 01:34:03,500
Mi ne skribas kaj
legante trans unu klavo nun.

2134
01:34:03,500 --> 01:34:04,950
Do jen granda ŝablono.

2135
01:34:04,950 --> 01:34:08,090
>> Tiu estas fakte probable unu
de la plej grava dezajno

2136
01:34:08,090 --> 01:34:10,420
ŝablonoj por skalo en NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Vi vidos ĉi tipo de
dezajno ŝablono en ĉiu gusto.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, ĝi ne
afero, ni ĉiuj devas fari tion.

2139
01:34:19,100 --> 01:34:21,840
Ĉar kiam vi pritraktas
kun tiuj grandegaj agregaciones,

2140
01:34:21,840 --> 01:34:26,650
vi devas diveni manieron
disvastigi ilin trans siteloj.

2141
01:34:26,650 --> 01:34:29,512
Do jen kiel vi faros tion.

2142
01:34:29,512 --> 01:34:31,220
Bone, do kion
vi faras nun

2143
01:34:31,220 --> 01:34:35,252
Estas vi komercanta ekstere legado
kosto por registran escalabilidad.

2144
01:34:35,252 --> 01:34:37,085
La kosto de mia legado estas
iom pli kompleksa

2145
01:34:37,085 --> 01:34:40,220
kaj mi devas iri legita de
cent sitelojn anstataŭ unu.

2146
01:34:40,220 --> 01:34:41,310
Sed mi povas skribi.

2147
01:34:41,310 --> 01:34:44,860
Kaj mia traigivo, mia registran
traigivo estas nekredebla.

2148
01:34:44,860 --> 01:34:49,450
Do estas kutime valora
tekniko por krustanta DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
aŭ ajna NoSQL datumbazo tiurilate.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Do ni eltrovis kiel grimpi gxin.

2152
01:34:55,240 --> 01:34:56,930
Kaj ni kalkulis kiel
forigi nia varma klavoj.

2153
01:34:56,930 --> 01:34:57,820
Kaj tiu estas fantazia.

2154
01:34:57,820 --> 01:34:58,960
Kaj ni akiris ĉi belan sistemon.

2155
01:34:58,960 --> 01:35:02,043
Kaj ĝin donis al ni tre ĝentila balotado
ĉar ni havas rekordon voĉdono de-dupe.

2156
01:35:02,043 --> 01:35:03,130
Ĝi estas konstruita en DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Ni parolis pri kondicionalo rajtoj.

2158
01:35:05,380 --> 01:35:08,170
>> Kiam balotanto envenas, metas
insert sur la tablo,

2159
01:35:08,170 --> 01:35:11,220
ili enmeti kun siaj votante ID,
se ili provas enmeti alian voĉdonon,

2160
01:35:11,220 --> 01:35:13,320
Mi do kondiĉa registran.

2161
01:35:13,320 --> 01:35:16,960
Diru nur skribi ĉi
se tiu ne ekzistas.

2162
01:35:16,960 --> 01:35:19,270
Tuj, kiam mi vidas ke
ke voĉdono la trafis la tablon,

2163
01:35:19,270 --> 01:35:20,460
neniu alia tuj estos
kapabla meti lian voĉdonon en.

2164
01:35:20,460 --> 01:35:21,634
Kaj tio estas mirinda.

2165
01:35:21,634 --> 01:35:23,550
Kaj ni pliigante
nia kandidato nombriloj.

2166
01:35:23,550 --> 01:35:25,466
Kaj ni faras nia
demografio kaj cxio.

2167
01:35:25,466 --> 01:35:29,110
Sed kio okazas se mia
apliko falas super?

2168
01:35:29,110 --> 01:35:31,350
Nun subite voĉdonoj
estas enirantan kaj mi

2169
01:35:31,350 --> 01:35:34,840
ne scias se ili estas duumaj procesis
en mia analytics kaj demografio

2170
01:35:34,840 --> 01:35:36,040
anymore.

2171
01:35:36,040 --> 01:35:38,462
Kaj kiam la apliko
venas reen supren, kiom

2172
01:35:38,462 --> 01:35:41,420
diable mi scias kion voĉdonoj havas
estis traktitaj kaj kie mi komencu?

2173
01:35:41,420 --> 01:35:44,530
>> Do tio estas vera problemo kiam vin
komenci rigardi ĉi tipo de scenaro.

2174
01:35:44,530 --> 01:35:45,571
Kaj kiel ni solvi tiun?

2175
01:35:45,571 --> 01:35:48,070
Ni solvos ĝin kun kion ni
voki DynamoDB Rojoj.

2176
01:35:48,070 --> 01:35:53,470
Rojoj estas tempo ordigis kaj
dispartigita ŝanĝo Protokolo de ĉiu aliro

2177
01:35:53,470 --> 01:35:55,700
al la tablo, ĉiu skribos
aliro al la tablo.

2178
01:35:55,700 --> 01:35:58,810
Ajna datumoj kiu estas skribita al la
tablo montras supren en la rivereto.

2179
01:35:58,810 --> 01:36:01,815
>> Ĝi estas resume 24 horo atendovico.

2180
01:36:01,815 --> 01:36:03,690
Eroj batis la rivereto,
ili povas vivi 24 horoj.

2181
01:36:03,690 --> 01:36:05,990
Ili povas legi plurfoje.

2182
01:36:05,990 --> 01:36:09,400
Garantiita esti liverita
nur unufoje al la rivereto,

2183
01:36:09,400 --> 01:36:11,180
povis legi n plurfoje.

2184
01:36:11,180 --> 01:36:14,910
Do tamen multaj procezoj vi volas
konsumi ke datumoj, vi povas konsumi ĝin.

2185
01:36:14,910 --> 01:36:16,350
Ĝi aperos ĉiun ĝisdatigon.

2186
01:36:16,350 --> 01:36:18,455
Ĉiu registran volas nur
aperas unufoje sur la rivereto.

2187
01:36:18,455 --> 01:36:20,621
Do vi ne devas maltrankvili
pri procesante ŝin dufoje

2188
01:36:20,621 --> 01:36:22,500
de la sama procezo.

2189
01:36:22,500 --> 01:36:25,350
>> Ĝi estas strikte ordigita por ero.

2190
01:36:25,350 --> 01:36:28,180
Kiam ni diras tempo
ordigita kaj dispartigita,

2191
01:36:28,180 --> 01:36:30,680
vi vidos po dispartigo sur la rivereto.

2192
01:36:30,680 --> 01:36:33,169
Vi vidos erojn, ĝisdatigoj en ordo.

2193
01:36:33,169 --> 01:36:35,210
Ni ne garantias
sur la rivereto ke vi estas

2194
01:36:35,210 --> 01:36:40,240
ricevos ĉiu transakcio
en la ordo trans erojn.

2195
01:36:40,240 --> 01:36:42,440
>> Do rojoj estas kvadrategala.

2196
01:36:42,440 --> 01:36:44,037
Ĉu ni ĉiuj scias kion kvadrategala signifas?

2197
01:36:44,037 --> 01:36:46,620
Kvadrategala signifas vin povas fari ĝin
super kaj super kaj super denove.

2198
01:36:46,620 --> 01:36:48,200
La rezulto estas tuj estos la sama.

2199
01:36:48,200 --> 01:36:49,991
>> Rojoj estas kvadrategala,
sed ili devas esti

2200
01:36:49,991 --> 01:36:54,860
luditaj de la deirpunkto,
Wherever vi elektas, al la fino,

2201
01:36:54,860 --> 01:36:57,950
aŭ ili ne rezulti
en la samaj valoroj.

2202
01:36:57,950 --> 01:36:59,727
>> Sama afero kun MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB havas konstrukcio
ili nomas la oplog.

2204
01:37:01,560 --> 01:37:04,140
Estas la ĝusta sama konstrukcio.

2205
01:37:04,140 --> 01:37:06,500
Multaj NoSQL datumbazoj
havas ĉi konstrukcio.

2206
01:37:06,500 --> 01:37:08,790
Ili uzas ĝin por fari aferojn
kiel replicación, kiu

2207
01:37:08,790 --> 01:37:10,475
Estas ĝuste kion ni faras kun riveretoj.

2208
01:37:10,475 --> 01:37:12,350
Publiko: Eble
hereza demando, sed vi

2209
01:37:12,350 --> 01:37:13,975
paroli pri apps fari malsupren tiel antaŭen.

2210
01:37:13,975 --> 01:37:16,089
Ĉu riveretoj garantiita
neniam eble iros malsupren?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Yeah, riveretoj
estas guaranteed neniam penetras.

2212
01:37:18,630 --> 01:37:21,040
Ni manipuli la infrastrukturo
malantaŭe. riveretoj aŭtomate

2213
01:37:21,040 --> 01:37:22,498
deploji en ilia auto grimpita grupo.

2214
01:37:22,498 --> 01:37:25,910
Ni iros tra iom
bita pri kio okazas.

2215
01:37:25,910 --> 01:37:30,060
>> Mi ne devus diri ili estas ne
guaranteed neniam penetras.

2216
01:37:30,060 --> 01:37:33,110
La elementoj estas garantiita
aperi en la rivereto.

2217
01:37:33,110 --> 01:37:36,740
Kaj la rivereto estos alirebla.

2218
01:37:36,740 --> 01:37:40,580
Do kio iras malsupren aŭ revenas
supren, ke okazas sube.

2219
01:37:40,580 --> 01:37:43,844
Ĝi covers-- ĝi estas okej.

2220
01:37:43,844 --> 01:37:46,260
Bone, do vi ricevas malsaman
vido tipoj de sur la ekrano.

2221
01:37:46,260 --> 01:37:51,040
La vido tipoj kiuj estas gravaj al
programisto tipe estas, kio ĝi estis?

2222
01:37:51,040 --> 01:37:52,370
Mi alvenas la malnova vido.

2223
01:37:52,370 --> 01:37:55,630
Kiam ĝisdatigo frapas la tablon, ĝi devos
puŝi la malnova vido al la rivereto

2224
01:37:55,630 --> 01:38:02,070
tiom datumoj povas enarkivigi, aŭ ŝanĝo
kontrolo, ŝanĝo identigo, ŝanĝo

2225
01:38:02,070 --> 01:38:03,600
demarŝo.

2226
01:38:03,600 --> 01:38:07,160
>> La nova bildo, kio estas nun post
la ĝisdatigo, tio estas alia tipo de vido

2227
01:38:07,160 --> 01:38:07,660
vi povas akiri.

2228
01:38:07,660 --> 01:38:09,660
Vi povas akiri ambaŭ la malnovaj kaj novaj bildoj.

2229
01:38:09,660 --> 01:38:10,660
Eble mi volas ilin ambaŭ.

2230
01:38:10,660 --> 01:38:11,790
Mi volas vidi, kio estis.

2231
01:38:11,790 --> 01:38:13,290
Mi volas vidi kio ŝanĝis.

2232
01:38:13,290 --> 01:38:15,340
>> Mi havas observon tipo
de procezo kiu kuras.

2233
01:38:15,340 --> 01:38:17,430
Ĝi bezonas por kontroli ke
kiam tio ŝanĝi,

2234
01:38:17,430 --> 01:38:21,840
ke ili estas ene de certaj limoj
aŭ ene de certaj parametroj.

2235
01:38:21,840 --> 01:38:23,840
>> Kaj tiam eble mi nur
bezonas scii kion ŝanĝis.

2236
01:38:23,840 --> 01:38:26,240
Ne gravas kion item ŝanĝis.

2237
01:38:26,240 --> 01:38:28,580
Mi ne bezonas bezonas scii
kio ecoj ŝanĝiĝis.

2238
01:38:28,580 --> 01:38:30,882
Mi nur bezonas scii ke
La aĵoj estas estanta tuŝita.

2239
01:38:30,882 --> 01:38:33,340
Tiuj estas la tipoj de opinioj
ke vi akiri de la rivereto

2240
01:38:33,340 --> 01:38:35,960
kaj vi povas interagi kun.

2241
01:38:35,960 --> 01:38:37,840
>> La apliko kiu
konsumas la rivereto,

2242
01:38:37,840 --> 01:38:39,298
tio estas speco de vojo tio funkcias.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB kliento demandas al
puŝi datumojn al la tabloj.

2244
01:38:42,570 --> 01:38:44,750
Riveretoj deploji sur kion ni nomas breĉetoj.

2245
01:38:44,750 --> 01:38:47,380
Breĉetoj estas skalita
sendepende de la tablo.

2246
01:38:47,380 --> 01:38:50,660
Ili ne laŭliniigi tute
al la vandoj de via tablo.

2247
01:38:50,660 --> 01:38:52,540
Kaj la kialo kial estas
ĉar ili laŭliniigi

2248
01:38:52,540 --> 01:38:55,430
al la kapablo, la nuna
kapablo de la tablo.

2249
01:38:55,430 --> 01:38:57,600
>> Ili deploji en ilia
propra auto grimpita grupo,

2250
01:38:57,600 --> 01:39:00,800
kaj ili komencas ŝpini el dependanta
sur kiom multaj skribas venintoj,

2251
01:39:00,800 --> 01:39:03,090
kiom reads-- vere estas skribas.

2252
01:39:03,090 --> 01:39:05,820
Mankas reads-- sed kiom
multaj skribas estas eniranta.

2253
01:39:05,820 --> 01:39:08,200
>> Kaj tiam sur la dorso
Fine, ni havas kion ni

2254
01:39:08,200 --> 01:39:11,390
voki KCL, aŭ Kinesis Kliento Biblioteko.

2255
01:39:11,390 --> 01:39:19,190
Kinesis estas rivereto datumoj
prilaborado teknologio de Amazon.

2256
01:39:19,190 --> 01:39:22,040
Kaj riveretoj estas konstruita sur tio.

2257
01:39:22,040 --> 01:39:25,670
>> Do vi uzas KCL enŝaltita
apliko por legi la rivereton.

2258
01:39:25,670 --> 01:39:28,752
La Kinesis Kliento Biblioteko reale
administras la laboristoj por vi.

2259
01:39:28,752 --> 01:39:30,460
Kaj ĝi ankaŭ faras iuj
interesajn aferojn.

2260
01:39:30,460 --> 01:39:35,630
Ĝi kreos iuj tabloj supren
en via DynamoDB tablespace

2261
01:39:35,630 --> 01:39:38,410
spuri kiujn erojn
estis traktitaj.

2262
01:39:38,410 --> 01:39:41,190
Do tiu vojo se ĝi falas reen, se
ĝi falas super kaj venas kaj ricevas

2263
01:39:41,190 --> 01:39:45,570
staris reen supren, ĝi povas determini kie
cxu en procesante la rivereto.

2264
01:39:45,570 --> 01:39:48,360
>> Tio estas tre grava kiam
vi parolas replicación.

2265
01:39:48,360 --> 01:39:50,350
Mi bezonas scii kion
datumoj procesis

2266
01:39:50,350 --> 01:39:52,810
kaj kio datumoj havas ankoraŭ esti procesitaj.

2267
01:39:52,810 --> 01:39:57,380
Do la KCL biblioteko por riveroj
doni al vi multe de tiu funcionalidad.

2268
01:39:57,380 --> 01:39:58,990
Atentas tutan mastrumadon.

2269
01:39:58,990 --> 01:40:01,140
Ĝi ekstaras laboriston por ĉiu Shard.

2270
01:40:01,140 --> 01:40:04,620
Ĝi kreas administra tablo
por ĉiu Shard, por ĉiu laboristo.

2271
01:40:04,620 --> 01:40:07,560
Kaj tiuj laboristoj fajro,
subtenas tiujn tablojn

2272
01:40:07,560 --> 01:40:10,510
do vi scias ĉi rekordo
estis legita kaj procesis.

2273
01:40:10,510 --> 01:40:13,850
Kaj tiam tiu modo se la procezo
mortas kaj revenas enretan,

2274
01:40:13,850 --> 01:40:17,940
ĝi povas rekomenci ĝuste kie ekis.

2275
01:40:17,940 --> 01:40:20,850
>> Do ni uzu tiun por
kruco-regiono replicación.

2276
01:40:20,850 --> 01:40:24,680
Multaj klientoj havas la bezonon
movi datumon aŭ partoj de liaj datumoj tabloj

2277
01:40:24,680 --> 01:40:25,920
ĉirkaŭe al malsamaj regionoj.

2278
01:40:25,920 --> 01:40:29,230
Estas naŭ regionoj
ĉie en la mondo.

2279
01:40:29,230 --> 01:40:32,100
Do eble estas need-- mi
havu uzantoj en Azio, uzantoj

2280
01:40:32,100 --> 01:40:34,150
en la Orienta marbordo de Usono.

2281
01:40:34,150 --> 01:40:38,980
Ili havas malsamajn datumojn kiuj
bezonoj esti loke distribuita.

2282
01:40:38,980 --> 01:40:42,510
Kaj eble uzanto flugas el
Azio inte al Usono,

2283
01:40:42,510 --> 01:40:45,020
kaj mi volas repliki
lia datumoj kun li.

2284
01:40:45,020 --> 01:40:49,340
Do kiam li ricevas for la aviadilon, li havas
bona sperto uzante lia telefono app.

2285
01:40:49,340 --> 01:40:52,360
>> Vi povas uzi la kruco-regiono
replicación biblioteko fari tion.

2286
01:40:52,360 --> 01:40:55,730
Esence ni havas
havigis du teknologioj.

2287
01:40:55,730 --> 01:40:59,400
Unu estas konzolo apliko vi povas
ekstari sur via propra EC2 okazo.

2288
01:40:59,400 --> 01:41:01,240
Ĝi kuras pura replicación.

2289
01:41:01,240 --> 01:41:02,720
Kaj tiam ni donis al vi la biblioteko.

2290
01:41:02,720 --> 01:41:06,070
La biblioteko povas uzi konstrui
via propra apliko se vi

2291
01:41:06,070 --> 01:41:10,740
volas fari freneza aĵojn kun kiuj data--
filtrilo, repliki nur parto de ĝi,

2292
01:41:10,740 --> 01:41:14,120
turni la datumoj, kopii ĝin en
malsamaj tablo, tiel plu kaj tiel antaŭen.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Do jen speco de kion tio aspektas.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Riveretoj povas esti
pretigita de kion ni nomas Lambda.

2296
01:41:23,690 --> 01:41:27,394
Ni menciis iomete pri okazaĵo
veturita apliko arkitekturoj.

2297
01:41:27,394 --> 01:41:28,810
Lambda estas ŝlosila komponanto de tiu.

2298
01:41:28,810 --> 01:41:32,840
Lambda estas kodo kiu maldungas laŭpete
en respondo al aparta okazaĵo.

2299
01:41:32,840 --> 01:41:36,020
Unu el tiuj eventoj eblis
rekordo aperante sur la rivereto.

2300
01:41:36,020 --> 01:41:39,100
Se rekordon aperas sur la rivereton,
ni nomas ĉi Java funkcio.

2301
01:41:39,100 --> 01:41:44,980
Nu, tio estas JavaScript, kaj Lambda
Elportas Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
kaj baldaŭ apogi
aliajn lingvojn ankaŭ.

2303
01:41:47,820 --> 01:41:50,940
Kaj sufiĉas nomi, estas pura kodo.

2304
01:41:50,940 --> 01:41:53,610
skribi En Java, vi difinas klason.

2305
01:41:53,610 --> 01:41:55,690
Vi puŝi la JAR supren en Lambda.

2306
01:41:55,690 --> 01:42:00,200
Kaj tiam oni indikas kiun klaso
voki en respondo al kiu okazaĵo.

2307
01:42:00,200 --> 01:42:04,770
Kaj tiam la Lambda infrastrukturo
malantaŭ kiu kuros tiu kodo.

2308
01:42:04,770 --> 01:42:06,730
>> Ke kodo povas procesi
rekordojn super la rivereto.

2309
01:42:06,730 --> 01:42:08,230
Ĝi povas fari ion ajn kun ĝi.

2310
01:42:08,230 --> 01:42:11,650
En ĉi tiu aparta ekzemplo, ĉiuj ni estas
vere faras estas elsaluti la atributoj.

2311
01:42:11,650 --> 01:42:13,480
Sed tio estas nur kodo.

2312
01:42:13,480 --> 01:42:15,260
Kodo povas fari ion, ĉu ne?

2313
01:42:15,260 --> 01:42:16,600
>> Do vi povas rotacii ke datumoj.

2314
01:42:16,600 --> 01:42:18,160
Vi povas krei devenaĵojn vido.

2315
01:42:18,160 --> 01:42:21,160
Se ĝi estas dokumenta strukturo,
vi povas platigi la strukturo.

2316
01:42:21,160 --> 01:42:24,300
Vi povas krei alternajn indeksoj.

2317
01:42:24,300 --> 01:42:27,100
Ĉiuj specoj de aferoj vi povas
fari kun la DynamoDB Rojoj.

2318
01:42:27,100 --> 01:42:28,780
>> Kaj vere, tion ke aspektas.

2319
01:42:28,780 --> 01:42:29,940
Do vi ricevas tiujn ĝisdatigojn venon.

2320
01:42:29,940 --> 01:42:31,190
Ili venas for la ĉenon.

2321
01:42:31,190 --> 01:42:32,720
Ili legita de la Lambda funkcio.

2322
01:42:32,720 --> 01:42:37,480
Ili turnanta la datumojn kaj
puŝante ĝin supren en derivaĵa tabloj,

2323
01:42:37,480 --> 01:42:42,200
sciigante eksteraj sistemoj de ŝanĝo,
kaj puŝas datumojn en ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Ni parolis pri kiel meti la kaŝmemoron
antaŭ la datumbazo por vendoj

2325
01:42:45,900 --> 01:42:46,450
scenaro.

2326
01:42:46,450 --> 01:42:50,049
Nu kio okazas, se mi
ĝisdatigi la eron priskribo?

2327
01:42:50,049 --> 01:42:52,340
Nu, se mi havus Lambda
funkcio kurante sur tiu tablo,

2328
01:42:52,340 --> 01:42:55,490
se mi ĝisdatigos la eron priskribo, ĝi devos
repreni la rekordon de la rivereto,

2329
01:42:55,490 --> 01:42:58,711
kaj gxi devos ĝisdatigi la ElastiCache
Ekzemple kun la novaj datumoj.

2330
01:42:58,711 --> 01:43:00,460
Do jen multa
kion ni faras kun Lambda.

2331
01:43:00,460 --> 01:43:02,619
Estas gluo kodo, konektiloj.

2332
01:43:02,619 --> 01:43:04,410
Kaj ĝi efektive donas
la kapablo lanĉi

2333
01:43:04,410 --> 01:43:07,930
kaj kuri tre kompleksaj aplikoj
sen diligenta servilo

2334
01:43:07,930 --> 01:43:10,371
infrastrukturo, kio estas vere malvarmeta.

2335
01:43:10,371 --> 01:43:13,100
>> Do ni revenu al nia
realtempan balotado arkitekturo.

2336
01:43:13,100 --> 01:43:17,984
Tiu estas nova kaj plibonigita kun nia
riveretoj kaj KCL ebligis apliko.

2337
01:43:17,984 --> 01:43:20,150
Sama kiel antaŭe, ni povas
manipuli ajna skalo de elekto.

2338
01:43:20,150 --> 01:43:21,100
Ni ŝatas ĉi.

2339
01:43:21,100 --> 01:43:24,770
Ni faras el disjxetu reprenas
trans multaj siteloj.

2340
01:43:24,770 --> 01:43:26,780
Ni havas optimisma ŝlosado okazas.

2341
01:43:26,780 --> 01:43:30,192
Ni povas teni niajn balotantoj
de ŝanĝanta iliajn voĉdonojn.

2342
01:43:30,192 --> 01:43:31,400
Ili povas nur voĉdoni nur unufoje.

2343
01:43:31,400 --> 01:43:32,880
Tio estas mirinda.

2344
01:43:32,880 --> 01:43:35,895
Realtempaj kulpo toleremo,
skalebla agregación nun.

2345
01:43:35,895 --> 01:43:38,270
Se la afero falas super, ĝi
scias kie rekomenci mem

2346
01:43:38,270 --> 01:43:41,300
kiam venas reen supren ĉar
ni uzas la KCL app.

2347
01:43:41,300 --> 01:43:45,700
Kaj tiam ni povas ankaŭ uzi tiu
KCL apliko puŝi datumojn ekstere

2348
01:43:45,700 --> 01:43:48,820
al ruĝenŝoviĝo por aliaj
app analytics, aŭ uzo

2349
01:43:48,820 --> 01:43:51,990
la Elasta MapReduce kuri
realtempan streaming agregaciones off

2350
01:43:51,990 --> 01:43:53,180
de tiu datumo.

2351
01:43:53,180 --> 01:43:55,480
>> Tiuj estas aferoj ni
ne parolis pri multo.

2352
01:43:55,480 --> 01:43:57,375
Sed ili estas aldona
teknologioj kiuj venis

2353
01:43:57,375 --> 01:44:00,310
toleri kiam vi serĉas
ĉe tiuj tipoj de scenejoj.

2354
01:44:00,310 --> 01:44:03,160
>> Bone, do jen pri
analytics kun DynamoDB Rojoj.

2355
01:44:03,160 --> 01:44:05,340
Vi povas kolekti de-dupe
datumoj, fari ĉiajn

2356
01:44:05,340 --> 01:44:09,490
bongustajxoj stuff, entutaj datumoj en
memoro, krei tiujn derivaĵo tabloj.

2357
01:44:09,490 --> 01:44:13,110
Tio estas grandega uzo kazo
ke multajn klientojn

2358
01:44:13,110 --> 01:44:16,950
estas implikitaj kun, prenante la nestitaj
propraĵoj de tiuj JSON dokumentoj

2359
01:44:16,950 --> 01:44:18,946
kaj kreante aldonan indeksoj.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Ni estas je la fino.

2362
01:44:23,150 --> 01:44:26,689
Dankon por portanta kun mi.

2363
01:44:26,689 --> 01:44:28,480
Do ni parolu pri
referenco arkitekturo.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB sidas en la mezo de tiel
multe de la AWS infrastrukturo.

2365
01:44:33,440 --> 01:44:37,090
Esence vi povas enganchar ĝi
ĝis ajn vi volas.

2366
01:44:37,090 --> 01:44:45,600
Aplikoj konstruita uzante Dinamo inkluzivi
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
puŝi la datumoj eksteren en Elasta
MapReduce, importado eksportado de DynamoDB

2368
01:44:49,890 --> 01:44:52,370
en S3, ĉiajn fluoj de laboro.

2369
01:44:52,370 --> 01:44:54,120
Sed probable la plej bona
afero paroli,

2370
01:44:54,120 --> 01:44:56,119
kaj tiu estas kio estas vere
interesa estas kiam ni

2371
01:44:56,119 --> 01:44:58,350
paroli pri okazaĵo movita aplikoj.

2372
01:44:58,350 --> 01:45:00,300
>> Tiu estas ekzemplo de
interna projekto

2373
01:45:00,300 --> 01:45:04,850
ke ni havas kie ni reale
eldonado kolekti enketo rezultoj.

2374
01:45:04,850 --> 01:45:07,700
Do en retpoŝto ligilon
ni sendu, tie denove

2375
01:45:07,700 --> 01:45:11,350
esti iom ligilon dirante klako
tie respondi al la enketo.

2376
01:45:11,350 --> 01:45:14,070
Kaj kiam persono klakoj
ligantaj, kio okazas

2377
01:45:14,070 --> 01:45:18,020
Estas ili disbatos sekuran
HTML enketo formo de S3.

2378
01:45:18,020 --> 01:45:18,980
Mankas servilo.

2379
01:45:18,980 --> 01:45:20,600
Tiu estas nur S3 objekto.

2380
01:45:20,600 --> 01:45:22,770
>> Tiu formo venas supren,
ŝarĝas supren en la retumilo.

2381
01:45:22,770 --> 01:45:24,240
Oni alvenis Backbone.

2382
01:45:24,240 --> 01:45:30,160
Oni alvenis kompleksa Ĝavoskripto
ke ĝi estas kurante.

2383
01:45:30,160 --> 01:45:33,557
Do estas tre riĉa apliko
kurante en la kliento retumilo.

2384
01:45:33,557 --> 01:45:36,390
Ili ne scias ke ili ne estas
interagante kun malantaŭa fino servilo.

2385
01:45:36,390 --> 01:45:38,220
Ĉe tiu punkto, ĉio retumilo.

2386
01:45:38,220 --> 01:45:41,780
>> Ili publikigas la rezultojn al kio
ni nomas la Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway estas simple TTT API
ke vi povas difini kaj conectarse

2388
01:45:46,270 --> 01:45:47,760
al kiom vi volas.

2389
01:45:47,760 --> 01:45:50,990
En ĉi tiu aparta kazo, ni estas
hokita supren al Lambda funkcio.

2390
01:45:50,990 --> 01:45:54,797
>> Do mia POST operacio estas
okazanta sen servilo.

2391
01:45:54,797 --> 01:45:56,380
Esence tiu API Gateway sidas tie.

2392
01:45:56,380 --> 01:45:58,770
Ĝi kostas al mi nenion, ĝis homoj
komenci eldoni ĝin, ĉu ne?

2393
01:45:58,770 --> 01:46:00,269
La Lambda funkcio nur sidas tie.

2394
01:46:00,269 --> 01:46:03,760
Kaj ĝi kostas min nenio ĝis
personoj komencos bati lin.

2395
01:46:03,760 --> 01:46:07,270
Do vi povas vidi, kiel la volumeno
kreskoj, tio estas kiam la ŝargoj venis.

2396
01:46:07,270 --> 01:46:09,390
Mi ne kurante servilon 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Do mi tiras la formo
malsuprenvenas de la sitelo,

2398
01:46:12,310 --> 01:46:15,719
kaj mi afiŝas per la API
Enirejo en la Lambda funkcio.

2399
01:46:15,719 --> 01:46:17,510
Kaj tiam la Lambda
funkcio diras, vi scias

2400
01:46:17,510 --> 01:46:20,600
kion mi havas kelkajn PIIs, iuj
propre perceptebla informo

2401
01:46:20,600 --> 01:46:21,480
en tiuj respondoj.

2402
01:46:21,480 --> 01:46:23,020
Mi ricevis komentojn devenante uzantoj.

2403
01:46:23,020 --> 01:46:24,230
Mi havas retadresoj.

2404
01:46:24,230 --> 01:46:26,190
Mi havas salutnomoj.

2405
01:46:26,190 --> 01:46:27,810
>> Lasu min fendi ĉi ekstere.

2406
01:46:27,810 --> 01:46:30,280
Mi tuj generos iun
metadatuma sur tiu rekordo.

2407
01:46:30,280 --> 01:46:32,850
Kaj mi tuj puŝi la
metadatumon en DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Kaj mi povus ĉifri ĉiujn datumojn
kaj puŝi ĝin en DynamoDB se mi volas.

2409
01:46:36,059 --> 01:46:38,600
Sed estas pli facile por mi, en ĉi
uzi kazo, por antaŭeniri al ni diru,

2410
01:46:38,600 --> 01:46:42,800
Mi tuj puŝas la krudaj datumoj
en ĉifrita S3 sitelo.

2411
01:46:42,800 --> 01:46:47,240
Do mi uzas konstruita en S3 servilo flanko
ĉifrado kaj Amazon Ŝlosilo Management

2412
01:46:47,240 --> 01:46:51,600
Servo por ke mi havas klavon, kiu
povas turni sur regula intervalo,

2413
01:46:51,600 --> 01:46:55,010
kaj mi povas protekti ke PII datumoj
kiel parto de tiu aro laborfluo.

2414
01:46:55,010 --> 01:46:55,870
>> Do kion mi faris?

2415
01:46:55,870 --> 01:47:00,397
Mi ĵus deplojiĝis tuto
apliko, kaj mi ne havas servilon.

2416
01:47:00,397 --> 01:47:02,980
Do kion okazaĵo movita apliko
arkitekturo faras por vi.

2417
01:47:02,980 --> 01:47:05,730
>> Nun, se vi pensas pri
la uzo kazo por this--

2418
01:47:05,730 --> 01:47:08,730
ni havos aliajn klientojn mi parolas
proksimume precize tiu arkitekturo kiu

2419
01:47:08,730 --> 01:47:14,560
kuri fenomene granda kampanjoj, kiuj
rigardas tion kaj irantaj, oh mia.

2420
01:47:14,560 --> 01:47:17,840
Ĉar nun, ili povas
esence puŝi ĝin tie,

2421
01:47:17,840 --> 01:47:21,900
lasu ke kampanjo nur sidi
tie ĝis ĝi ĵetas, kaj ne

2422
01:47:21,900 --> 01:47:24,400
devas zorgi figon pri
kia infrastrukturo

2423
01:47:24,400 --> 01:47:26,120
tuj estos tie por apogi ŝin.

2424
01:47:26,120 --> 01:47:28,600
Kaj tiam tuj kiam
tiu kampanjo estas farita,

2425
01:47:28,600 --> 01:47:31,520
ĝi estas kiel la infrastrukturo
nur tuj foriras

2426
01:47:31,520 --> 01:47:33,680
ĉar tie vere
neniu infrastrukturo.

2427
01:47:33,680 --> 01:47:35,660
Estas nur kodo kiu subigas Lambda.

2428
01:47:35,660 --> 01:47:38,560
Estas nur datumoj kiuj sidas en DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Ĝi estas mirinda vojo
konstrui aplikojn.

2430
01:47:41,340 --> 01:47:43,970
>> Publiko: Do ​​ĝi estas pli
efemeran ol ĝi estus

2431
01:47:43,970 --> 01:47:45,740
se ĝi estis stokita sur reala servilo?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Absolute.

2433
01:47:46,823 --> 01:47:49,190
Pro tiu servilo ekzemple
devus esti 7/24.

2434
01:47:49,190 --> 01:47:51,954
Ĝi devas esti havebla por
iu respondi al.

2435
01:47:51,954 --> 01:47:52,620
Nu divenu kion?

2436
01:47:52,620 --> 01:47:55,410
S3 estas disponebla 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 ĉiam respondas.

2438
01:47:57,100 --> 01:47:59,320
Kaj S3 estas tre, tre bona
ĉe servanta celojn.

2439
01:47:59,320 --> 01:48:02,590
Tiuj objektoj povas esti HTML- dosieroj, aŭ
JavaScript dosierojn, aŭ kion ajn vi volas.

2440
01:48:02,590 --> 01:48:07,430
Vi povas kuri tre riĉa aplikoj retejo
el S3 siteloj, kaj homoj faras.

2441
01:48:07,430 --> 01:48:10,160
>> Kaj do jen la ideo tie
estas foriri de la vojo

2442
01:48:10,160 --> 01:48:11,270
ni kutimis pensi pri ĝi.

2443
01:48:11,270 --> 01:48:14,270
Ni ĉiuj uzis pensi en
Kondiĉoj de serviloj kaj gastigantoj.

2444
01:48:14,270 --> 01:48:16,580
Ĝi ne estas pri tio plu.

2445
01:48:16,580 --> 01:48:19,310
Temas pri infrastrukturo kiel kodo.

2446
01:48:19,310 --> 01:48:22,470
Deploji la kodo al la nubo kaj
lasu la nubo ruli ĝin por vi.

2447
01:48:22,470 --> 01:48:24,980
Kaj tion AWS provas fari.

2448
01:48:24,980 --> 01:48:29,690
>> Publiko: Do ​​via oro skatolo en la mezo
de la API Gateway ne servilo-simila,

2449
01:48:29,690 --> 01:48:30,576
sed anstataŭe estas just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Vi povas pensi
de ĝi kiel servilo fasado.

2451
01:48:32,850 --> 01:48:38,040
Ĉiuj estas estas ĝi prenos HTTP
peti kaj mapi ĝin al alia procezo.

2452
01:48:38,040 --> 01:48:39,192
Tio estas ĉio faras.

2453
01:48:39,192 --> 01:48:41,525
Kaj en ĉi tiu kazo, ni surĵeto
ĝin al Lambda funkcio.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Bone, do jen ĉio mi ricevis.

2456
01:48:45,410 --> 01:48:46,190
Dankegon.

2457
01:48:46,190 --> 01:48:46,800
Mi dankos.

2458
01:48:46,800 --> 01:48:48,100
Mi scias ni volas iomete super tempo.

2459
01:48:48,100 --> 01:48:49,980
Kaj espereble vi uloj atingis
iomete da informo

2460
01:48:49,980 --> 01:48:51,410
ke vi povas forpreni hodiaŭ.

2461
01:48:51,410 --> 01:48:53,520
Mi pardonpetas se mi irus
super iu el viaj kapoj,

2462
01:48:53,520 --> 01:48:56,697
sed tie estas bona multajn
fundamentaj fundamenta scio

2463
01:48:56,697 --> 01:48:58,280
ke mi pensas estas tre valoraj por vi.

2464
01:48:58,280 --> 01:48:59,825
Do dankon por havi min.

2465
01:48:59,825 --> 01:49:00,325
[Aplaŭdo]

2466
01:49:00,325 --> 01:49:02,619
Spektantaro: [inaudible]
Estas kiam vi diras

2467
01:49:02,619 --> 01:49:05,160
vi devis iri tra la afero
de la komenco ĝis la fino

2468
01:49:05,160 --> 01:49:07,619
akiri la rajton valoroj
aŭ la samajn valorojn,

2469
01:49:07,619 --> 01:49:09,410
Kiel volus la valoroj
ŝanĝi se [inaudible].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Ho, kvadrategala?

2471
01:49:10,480 --> 01:49:11,800
Kiel volus la valoroj ŝanĝas?

2472
01:49:11,800 --> 01:49:15,180
Nu, ĉar se mi ne kuris
ĝi la tutan vojon al la fino,

2473
01:49:15,180 --> 01:49:19,770
tiam mi ne scias kion ŝanĝas
estis faritaj en la lasta mejlo.

2474
01:49:19,770 --> 01:49:22,144
Oni ne tuj estos la
samajn datumojn kiel kion mi vidis.

2475
01:49:22,144 --> 01:49:24,560
Publiko: Ho, do vi simple
ne alvenis la tuta enigo.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Dekstra.

2477
01:49:24,770 --> 01:49:26,895
Vi devos iri de komenco
al fino, kaj tiam estas

2478
01:49:26,895 --> 01:49:29,280
tuj esti kohera stato.

2479
01:49:29,280 --> 01:49:31,520
Malvarmeta.

2480
01:49:31,520 --> 01:49:35,907
>> Publiko: Do ​​vi montris nin DynamoDB
povas fari dokumento aŭ la klavo valoro.

2481
01:49:35,907 --> 01:49:38,740
Kaj ni pasigis multan tempon en la
ŝlosilo valoro kun hash kaj la manieroj

2482
01:49:38,740 --> 01:49:40,005
klaki ĝin ĉirkaŭ.

2483
01:49:40,005 --> 01:49:43,255
Kiam vi rigardis tiujn tablojn: estas ke
lasante malantaŭ la dokumenton alproksimiĝo?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: mi ne
diru lasante malantaŭe.

2485
01:49:44,600 --> 01:49:45,855
>> Publiko: Ili estis apartigitaj de the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Kun la dokumenton
alproksimiĝo, la dokumento tipo en DynamoDB

2487
01:49:49,140 --> 01:49:50,880
estas nur pensi kiel alia atributo.

2488
01:49:50,880 --> 01:49:53,560
Ĝi estas atributo kiu enhavas
hierarkia datumstrukturo.

2489
01:49:53,560 --> 01:49:56,980
Kaj poste en la demandoj,
vi povas uzi la propraĵoj

2490
01:49:56,980 --> 01:49:59,480
de tiuj objektoj uzante Objekto Skribmaniero.

2491
01:49:59,480 --> 01:50:03,562
Do mi povas filtri iun nestitaj
proprieto de la JSON dokumenton.

2492
01:50:03,562 --> 01:50:05,520
Publiko: Do ​​iam mi
fari dokumenton alproksimiĝo,

2493
01:50:05,520 --> 01:50:07,906
Mi povas ordigi de alveni al la tabular--

2494
01:50:07,906 --> 01:50:08,780
Publiko: Absolute.

2495
01:50:08,780 --> 01:50:09,800
Publiko: --indexes kaj
aferoj vi simple parolis.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Yeah, la
indeksoj kaj ĉiu tio,

2497
01:50:11,280 --> 01:50:13,363
kiam vi volas indekso la
propraĵoj de la JSON,

2498
01:50:13,363 --> 01:50:18,230
la vojo, ke ni devus fari tion estas se
enigata JSON objekto aŭ dokumenton

2499
01:50:18,230 --> 01:50:20,780
en Dinamo, vi uzus torentojn.

2500
01:50:20,780 --> 01:50:22,400
Riveretoj legus la enigo.

2501
01:50:22,400 --> 01:50:24,340
Vi akirus ke JSON
kontesti kaj vi dirus OK,

2502
01:50:24,340 --> 01:50:26,030
kio estas la propraĵo Mi volas indekso?

2503
01:50:26,030 --> 01:50:28,717
>> Vi kreas devenaĵon tablo.

2504
01:50:28,717 --> 01:50:30,300
Nun tio estas tiel funkcias nun.

2505
01:50:30,300 --> 01:50:32,650
Ni ne permesas indekso
rekte tiuj propraĵoj.

2506
01:50:32,650 --> 01:50:33,520
>> Publiko: Tabularizing viaj dokumentoj.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Precize, ebenigo
ĝin tabularizing Precize.

2508
01:50:36,230 --> 01:50:37,415
Tion vi faras per ĝi.

2509
01:50:37,415 --> 01:50:37,860
>> Publiko: Dankon.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Yep,
absolute, dankon.

2511
01:50:39,609 --> 01:50:42,240
Publiko: Do ​​ĝi estas speco de
Mongo renkontas Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Yeah,
ĝi estas multe simila.

2513
01:50:43,990 --> 01:50:45,940
Tio estas bona priskribo por ĝi.

2514
01:50:45,940 --> 01:50:47,490
Malvarmeta.

2515
01:50:47,490 --> 01:50:49,102