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

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: Në rregull.

3
00:00:06,010 --> 00:00:06,600
Çkemi të gjithë.

4
00:00:06,600 --> 00:00:07,670
Emri im është Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Unë jam një drejtor i lartë
Zgjidhjet arkitekt në AWS.

6
00:00:10,330 --> 00:00:14,070
Unë të përqëndrohet në NoSQL dhe
Teknologjive DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Jam këtu sot për të folur për
ju pak për ata.

8
00:00:16,930 --> 00:00:18,970
>> Prejardhja ime është
kryesisht në shtresën e të dhënave.

9
00:00:18,970 --> 00:00:21,390
Kam kaluar gjysmën zhvillimin tim
Karriera e shkruar bazës së të dhënave,

10
00:00:21,390 --> 00:00:25,930
qasje të dhënat, zgjidhje
për aplikacione të ndryshme.

11
00:00:25,930 --> 00:00:30,000
Unë kam qenë në Cloud Virtualization
për rreth 20 vjet.

12
00:00:30,000 --> 00:00:33,460
Pra, para se Cloud ishte Cloud,
kemi përdorur për të thirrur atë të shërbimeve informatikë.

13
00:00:33,460 --> 00:00:37,170
Dhe ideja ishte, është si
PG & E, ju paguani për atë që ju përdorni.

14
00:00:37,170 --> 00:00:38,800
Sot ne e quajmë atë cloud.

15
00:00:38,800 --> 00:00:41,239
>> Por me kalimin e viteve, unë kam punuar
për një çift të kompanive

16
00:00:41,239 --> 00:00:42,530
ju ndoshta keni dëgjuar kurrë të.

17
00:00:42,530 --> 00:00:47,470
Por unë kam përpiluar një listë të teknik
arritjet, I guess ju do të thonë.

18
00:00:47,470 --> 00:00:51,620
Unë kam tetë patentave në sistemin Cloud
Virtualization, dizajn mikroprocesor,

19
00:00:51,620 --> 00:00:54,440
përpunimi kompleks ngjarje,
dhe fusha të tjera si edhe.

20
00:00:54,440 --> 00:00:58,290
>> Pra, këto ditë, unë të përqëndrohet kryesisht në NoSQL
teknologjive dhe gjenerata e ardhshme

21
00:00:58,290 --> 00:00:59,450
bazës së të dhënave.

22
00:00:59,450 --> 00:01:03,370
Dhe kjo është në përgjithësi ajo që unë jam duke shkuar
të jem këtu duke folur për ju sot rreth.

23
00:01:03,370 --> 00:01:06,030
Pra, çfarë ju mund të presin
nga kjo seancë,

24
00:01:06,030 --> 00:01:08,254
ne do të kalojnë nëpër një të shkurtër
Historia e përpunimit të të dhënave.

25
00:01:08,254 --> 00:01:10,420
Është gjithmonë e dobishme për
kuptuar se ku kemi ardhur nga

26
00:01:10,420 --> 00:01:12,400
dhe pse ne jemi këtu ku jemi.

27
00:01:12,400 --> 00:01:15,600
Dhe ne do të flasim pak
bit rreth teknologjisë NoSQL

28
00:01:15,600 --> 00:01:17,500
nga pikëpamja themelore.

29
00:01:17,500 --> 00:01:19,870
>> Ne do të merrni në disa prej
internals DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB është AWS nr shije.

31
00:01:24,350 --> 00:01:27,340
Kjo është një menaxhuar plotësisht dhe
priti zgjidhje NoSQL.

32
00:01:27,340 --> 00:01:32,420
Dhe ne do të flasim pak për tryezë
Struktura, TV, tipet e te dhenave, indekseve,

33
00:01:32,420 --> 00:01:35,177
dhe disa internals
e këtë teknologji DynamoDB.

34
00:01:35,177 --> 00:01:37,760
Ne do të merrni në disa nga dizajnit
modelet dhe praktikat më të mira.

35
00:01:37,760 --> 00:01:39,968
Ne do të flasim si ju
përdorin këtë teknologji për disa

36
00:01:39,968 --> 00:01:41,430
e aplikacioneve sotme.

37
00:01:41,430 --> 00:01:44,820
Dhe pastaj ne do të flasim pak
për evoluimin ose shfaqjen

38
00:01:44,820 --> 00:01:48,980
i një paradigmë të re në programimin
quajtur aplikacionet ngjarje të shtyrë

39
00:01:48,980 --> 00:01:51,580
dhe si luan DynamoDB në se si.

40
00:01:51,580 --> 00:01:54,690
Dhe ne do të ju lënë një grimë të vogël e
një diskutim arkitekturë referencë

41
00:01:54,690 --> 00:01:59,540
kështu që ne mund të flasim për disa nga
mënyrat që ju mund të përdorni DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Pra, së pari off-- kjo është një pyetje
Kam dëgjuar shumë është, çfarë është një bazë të dhënash.

43
00:02:04,116 --> 00:02:06,240
Shumë njerëz mendojnë se ata
e di se çfarë është një bazë të dhënash.

44
00:02:06,240 --> 00:02:08,360
Nëse ju Google, ju do të shihni këtë.

45
00:02:08,360 --> 00:02:11,675
Kjo është një një grup të strukturuar e të dhënave të mbajtur
në një kompjuter, veçanërisht një që

46
00:02:11,675 --> 00:02:13,600
është në dispozicion në mënyra të ndryshme.

47
00:02:13,600 --> 00:02:16,992
Unë mendoj se është një e mirë
Përkufizimi i një bazë të dhënash moderne.

48
00:02:16,992 --> 00:02:19,450
Por unë nuk e pëlqen atë, sepse
kjo nënkupton disa gjëra.

49
00:02:19,450 --> 00:02:20,935
Kjo nënkupton strukturën.

50
00:02:20,935 --> 00:02:23,120
Dhe kjo nënkupton se ajo është në një kompjuter.

51
00:02:23,120 --> 00:02:25,750
Dhe bazat e të dhënave nuk e bëri
gjithmonë ekzistojnë në kompjuter.

52
00:02:25,750 --> 00:02:28,020
Bazat e të dhënave në fakt ka ekzistuar në shumë mënyra.

53
00:02:28,020 --> 00:02:32,000
>> Pra, një përkufizim më i mirë i një
bazës së të dhënave është diçka si kjo.

54
00:02:32,000 --> 00:02:34,786
Një databazë është një i organizuar
mekanizëm për ruajtjen, menaxhimin,

55
00:02:34,786 --> 00:02:35,910
dhe retrieving informacion.

56
00:02:35,910 --> 00:02:36,868
Kjo është nga About.com.

57
00:02:36,868 --> 00:02:42,080
Kështu që unë doja këtë, sepse me të vërtetë bisedimet
në lidhje me një bazë të dhënash të qenë një depo,

58
00:02:42,080 --> 00:02:44,800
një depo e
informacion, jo domosdoshmërisht

59
00:02:44,800 --> 00:02:46,780
diçka që ulet në një kompjuter.

60
00:02:46,780 --> 00:02:49,290
Dhe gjatë gjithë historisë, ne
nuk kanë pasur gjithmonë kompjutera.

61
00:02:49,290 --> 00:02:52,110
>> Tani, në qoftë se unë kërkoj mesatare
zhvilluesi sot çfarë është

62
00:02:52,110 --> 00:02:54,770
një bazë të dhënash, kjo është përgjigja unë shkoj.

63
00:02:54,770 --> 00:02:56,070
Diku unë mund të rrinë gjëra.

64
00:02:56,070 --> 00:02:56,670
E drejtë?

65
00:02:56,670 --> 00:02:58,725
Dhe kjo është e vërtetë.

66
00:02:58,725 --> 00:02:59,600
Por kjo është për të ardhur keq.

67
00:02:59,600 --> 00:03:02,700
Sepse baza e të dhënave është me të vërtetë
themeli i app moderne.

68
00:03:02,700 --> 00:03:04,810
Është themeli
e çdo kërkesë.

69
00:03:04,810 --> 00:03:07,240
Dhe si ju të ndërtuar atë
bazës së të dhënave, si ju strukturojnë

70
00:03:07,240 --> 00:03:11,750
që të dhënat do të diktojë se si
Aplikimi kryen si ju shkallë.

71
00:03:11,750 --> 00:03:14,640
>> Pra, një shumë e punës time sot
merret me atë

72
00:03:14,640 --> 00:03:17,180
ndodh kur zhvilluesit
marrë këtë qasje

73
00:03:17,180 --> 00:03:19,510
dhe që kanë të bëjnë me pasojat
e një kërkesë që

74
00:03:19,510 --> 00:03:24,966
tani është shkallë përtej origjinale
Qëllimi dhe vuajtje nga dizajni i keq.

75
00:03:24,966 --> 00:03:26,840
Kështu që shpresojmë se, kur ju
ecin tutje sot, ju do të

76
00:03:26,840 --> 00:03:29,010
kanë një çift të mjeteve në
rrip tuaj që do të ju mbajë

77
00:03:29,010 --> 00:03:32,566
nga bërja ato gabime të njëjta.

78
00:03:32,566 --> 00:03:33,066
Në rregull.

79
00:03:33,066 --> 00:03:36,360
Pra, le të flasim për një grimë të vogël të
afati kohor i teknologjisë bazës së të dhënave.

80
00:03:36,360 --> 00:03:38,830
Unë mendoj se kam lexuar një
artikull jo se shumë kohë më parë

81
00:03:38,830 --> 00:03:43,020
dhe ai tha diçka në lines--
kjo është një deklaratë shumë e poetik.

82
00:03:43,020 --> 00:03:46,590
Ai tha se historia
e të dhënave të përpunimit është

83
00:03:46,590 --> 00:03:49,350
plot filigranë të lartë
e të dhënave bollëk.

84
00:03:49,350 --> 00:03:49,920
NE RREGULL.

85
00:03:49,920 --> 00:03:52,532
Tani, unë mendoj se është lloj i vërtetë.

86
00:03:52,532 --> 00:03:54,990
Por, unë në fakt shohim është si
historia është e mbushur në fakt

87
00:03:54,990 --> 00:03:56,820
me ujëra të lartë të presionit të dhënave.

88
00:03:56,820 --> 00:04:00,040
Për shkak se shkalla e të dhënave të
gëlltitje kurrë nuk shkon poshtë.

89
00:04:00,040 --> 00:04:01,360
Ajo vetëm shkon deri.

90
00:04:01,360 --> 00:04:03,670
>> Dhe risi ndodh kur
ne shohim presionin e të dhënave, e cila

91
00:04:03,670 --> 00:04:07,825
është sasia e dhëna që është
tani në vijnë në sistem.

92
00:04:07,825 --> 00:04:12,027
Dhe kjo nuk mund të jenë të përpunuara
efikase ose në kohë ose në kosto.

93
00:04:12,027 --> 00:04:14,110
Dhe kjo është kur ne fillojmë
për të parë presionin e të dhënave.

94
00:04:14,110 --> 00:04:15,920
>> Pra, kur ne shikojmë në
Baza e të dhënave të parë, kjo

95
00:04:15,920 --> 00:04:17,180
është ai që ishte në mes veshët tona.

96
00:04:17,180 --> 00:04:18,310
Ne jemi të gjithë të lindur me të.

97
00:04:18,310 --> 00:04:19,194
Kjo është një bazë të dhënash e bukur.

98
00:04:19,194 --> 00:04:21,110
Ajo ka një disponueshmërinë e lartë.

99
00:04:21,110 --> 00:04:21,959
Është gjithmonë në.

100
00:04:21,959 --> 00:04:23,930
Ju gjithmonë mund të merrni atë.

101
00:04:23,930 --> 00:04:24,890
>> Por kjo është përdorues të vetëm.

102
00:04:24,890 --> 00:04:26,348
Unë nuk mund të ndajnë mendimet e mia me ju.

103
00:04:26,348 --> 00:04:28,370
Ju nuk mund të merrni mendimet e mia
kur ju doni ta.

104
00:04:28,370 --> 00:04:30,320
Dhe abilitiy i tyre nuk është aq i mirë.

105
00:04:30,320 --> 00:04:32,510
Ne harrojmë gjërat.

106
00:04:32,510 --> 00:04:36,540
Çdo tani dhe pastaj, njëri prej nesh lë
dhe shkon në një tjetër ekzistencë

107
00:04:36,540 --> 00:04:39,110
dhe kemi humbur çdo gjë
që ishte në atë bazë të dhënash.

108
00:04:39,110 --> 00:04:40,640
Pra, kjo nuk është e gjitha se e mirë.

109
00:04:40,640 --> 00:04:43,189
>> Dhe kjo ka funksionuar mirë me kalimin e kohës
kur ishim mbrapa në ditë

110
00:04:43,189 --> 00:04:46,230
kur të gjithë ne me të vërtetë e nevojshme për të dini është
ku do të shkojmë për të shkuar në nesër

111
00:04:46,230 --> 00:04:49,630
ose ku mblidhen ushqimin më të mirë.

112
00:04:49,630 --> 00:04:52,820
Por si kemi filluar të rritet si një
Qytetërimi dhe qeveria ka filluar

113
00:04:52,820 --> 00:04:55,152
për të ardhur në ekzistencë, dhe
Bizneset filluan të zhvillohet,

114
00:04:55,152 --> 00:04:57,360
kemi filluar për të realizuar ne
nevojë për pak më shumë se çfarë

115
00:04:57,360 --> 00:04:58,210
ne mund të vënë në kokën tonë.

116
00:04:58,210 --> 00:04:58,870
Në rregull?

117
00:04:58,870 --> 00:05:00,410
>> Ne kishim nevojë për sistemet e rekord.

118
00:05:00,410 --> 00:05:02,220
Ne kishim nevojë për vende të jetë në gjendje të dhënave dyqan.

119
00:05:02,220 --> 00:05:05,450
Pra, kemi filluar dokumente me shkrim,
krijuar bibliotekat dhe arkivat.

120
00:05:05,450 --> 00:05:08,000
Ne kemi filluar zhvillimin e një
sistemi i kontabilitetit një libër i llogarive.

121
00:05:08,000 --> 00:05:12,200
Dhe se sistemi i librit numërimit
vrapoi botën për shumë shekuj,

122
00:05:12,200 --> 00:05:15,580
dhe ndoshta edhe mijëvjeçarë si
ne lloj i rrit deri në pikën

123
00:05:15,580 --> 00:05:18,420
ku se ngarkesa të dhënat tejkaluar
aftësia e atyre sistemeve

124
00:05:18,420 --> 00:05:19,870
të jetë në gjendje për të kontrolluar atë.

125
00:05:19,870 --> 00:05:22,070
>> Dhe kjo në fakt ndodhi në 1880.

126
00:05:22,070 --> 00:05:22,570
E drejtë?

127
00:05:22,570 --> 00:05:24,390
Në SHBA Census 1880.

128
00:05:24,390 --> 00:05:26,976
Kjo është me të vërtetë ku kthese
pikë përpunimin e të dhënave moderne.

129
00:05:26,976 --> 00:05:28,850
Kjo është pika në
që shuma e të dhënave

130
00:05:28,850 --> 00:05:32,060
që ishte duke u mbledhur nga
Qeveria e SHBA mori në pikën

131
00:05:32,060 --> 00:05:34,005
ku ai mori tetë vjet për të procesit.

132
00:05:34,005 --> 00:05:36,350
>> Tani, tetë years-- si
ju e dini, regjistrimin

133
00:05:36,350 --> 00:05:39,180
shkon çdo 10 years-- kështu kjo është
shumë e qartë se nga koha ne

134
00:05:39,180 --> 00:05:41,419
mori e regjistrimit 1890,
shuma e dhëna që

135
00:05:41,419 --> 00:05:43,210
do të jenë të përpunuara
nga qeveria ishte

136
00:05:43,210 --> 00:05:46,335
do të tejkalojnë 10 vjet që ajo
do të marrë për të nisur regjistrimin e ri.

137
00:05:46,335 --> 00:05:47,250
Ky ishte një problem.

138
00:05:47,250 --> 00:05:49,000
>> Pra, një djalë i quajtur Herman
Hollerith erdhi së bashku

139
00:05:49,000 --> 00:05:52,640
dhe ai shpiku njësi rekord grusht
kartat, kartë shënoj lexues, kartë shënoj

140
00:05:52,640 --> 00:05:58,420
që hedh në tabelë, dhe krahasimin e
mekanizmat për këtë teknologji.

141
00:05:58,420 --> 00:06:01,860
Dhe se kompania që ai formuar në
kohë, së bashku me disa të tjerë,

142
00:06:01,860 --> 00:06:05,450
në fakt u bë një nga shtyllat e një
kompani e vogël ne e dimë sot quhet IBM.

143
00:06:05,450 --> 00:06:08,417
>> Pra, IBM fillimisht ishte në
biznesi bazës së të dhënave.

144
00:06:08,417 --> 00:06:09,750
Dhe kjo është me të vërtetë atë që ata vepruan.

145
00:06:09,750 --> 00:06:11,110
Ata e bënë përpunimin e të dhënave.

146
00:06:11,110 --> 00:06:15,400
>> Si kështu përhapjen e shënoj
Kartat, një mekanizmat zgjuar

147
00:06:15,400 --> 00:06:18,560
të qenë në gjendje të levave që
teknologji të sondazhit grupe renditura rezultat.

148
00:06:18,560 --> 00:06:20,726
Ju mund të shihni në këtë foto
nuk kemi një little--

149
00:06:20,726 --> 00:06:23,970
kjo është pak small--, por ju mund të shihni
një mekanizëm shumë i zgjuar mekanike

150
00:06:23,970 --> 00:06:26,970
ku ne kemi një kuvertë kartë shënoj.

151
00:06:26,970 --> 00:06:28,720
Dhe marrja e dikujt
një kaçavidë e vogël

152
00:06:28,720 --> 00:06:31,400
dhe fërkimit përmes
lojëra elektronike dhe heqjen atë

153
00:06:31,400 --> 00:06:34,820
për të marrë atë ndeshje, që
Rezultatet e renditura vendosur.

154
00:06:34,820 --> 00:06:36,270
>> Kjo është një grumbullimi.

155
00:06:36,270 --> 00:06:38,690
Ne e bëjmë këtë gjatë gjithë kohës
sot në kompjuter,

156
00:06:38,690 --> 00:06:40,100
ku ju bëni atë në bazën e të dhënave.

157
00:06:40,100 --> 00:06:41,620
Ne kemi përdorur për të bërë atë me dorë, e drejtë?

158
00:06:41,620 --> 00:06:42,994
Njerëzit vënë këto gjëra së bashku.

159
00:06:42,994 --> 00:06:45,440
Dhe kjo ishte përhapja
nga këto karta shënoj

160
00:06:45,440 --> 00:06:50,070
në atë që quhet bateri të dhënave
dhe lëkundet dhënave, kasetë letër.

161
00:06:50,070 --> 00:06:55,980
>> Industria e përpunimit të të dhënave mori
një mësim nga pianos lojtar.

162
00:06:55,980 --> 00:06:57,855
Player pianos mbrapa në
radha e shekullit

163
00:06:57,855 --> 00:07:02,100
përdorur për të përdorur lëkundet letër me lojëra elektronike
për të treguar atë që çelësat për të luajtur.

164
00:07:02,100 --> 00:07:05,380
Kështu që teknologjia ishte përshtatur
përfundimisht për të ruajtur të dhënat digjitale,

165
00:07:05,380 --> 00:07:08,070
për shkak se ata mund të vënë ato të dhëna
mbi këto makinë kasetë letër.

166
00:07:08,070 --> 00:07:10,870
>> Tani, si rezultat i kësaj, të dhënat e
u actually-- si

167
00:07:10,870 --> 00:07:14,960
ju hyni në këto të dhëna ishte drejtpërdrejt
varet nga ajo se ju ruajtur atë.

168
00:07:14,960 --> 00:07:17,825
Pra, nëse unë vendos të dhënat në një kasetë,
Unë kisha hyrë në të dhënat linear.

169
00:07:17,825 --> 00:07:20,475
Unë kisha për të rrokulliset të gjithë
kasetë për të hyrë në të gjitha të dhënat.

170
00:07:20,475 --> 00:07:22,600
Në qoftë se kam vënë të dhënat në grusht
Kartat, unë mund të hyni në atë

171
00:07:22,600 --> 00:07:26,270
në pak më shumë të rastit
modës, ndoshta jo aq shpejt.

172
00:07:26,270 --> 00:07:30,770
>> Por ka pasur kufizime në mënyrën se si ne
qasje në të dhënat në bazë të se si është ruajtur.

173
00:07:30,770 --> 00:07:32,890
Dhe kështu që ky ishte një problem
shkon në '50.

174
00:07:32,890 --> 00:07:37,890
Përsëri, ne mund të fillojmë të shohim se si ne
zhvillimin e teknologjive të reja të procesit

175
00:07:37,890 --> 00:07:41,670
të dhënat, e drejtë, ajo hap
dera për zgjidhje të reja,

176
00:07:41,670 --> 00:07:45,852
për programet e reja, të reja
aplikimet për këto të dhëna.

177
00:07:45,852 --> 00:07:47,810
Dhe me të vërtetë, qeverisja
mund të ketë qenë arsyeja

178
00:07:47,810 --> 00:07:49,435
pse ne kemi zhvilluar disa nga këto sisteme.

179
00:07:49,435 --> 00:07:52,290
Por biznesi shpejt u bë
shoferi prapa evolucionit

180
00:07:52,290 --> 00:07:54,720
bazës së të dhënave modern dhe
sistemi modern skedar.

181
00:07:54,720 --> 00:07:56,870
>> Pra, gjëja tjetër që
doli ishte në '50

182
00:07:56,870 --> 00:08:00,780
ishte sistemi skedar dhe
zhvillimi i magazinimit Random Access.

183
00:08:00,780 --> 00:08:02,050
Kjo ishte e bukur.

184
00:08:02,050 --> 00:08:06,230
Tani, të gjithë e papritur, ne mund të vënë tonë
fotografi kudo në këto hard drives

185
00:08:06,230 --> 00:08:09,760
dhe ne mund të hyni në këto të dhëna rastësisht.

186
00:08:09,760 --> 00:08:11,950
Ne mund të kuptoj se
informacion nga e dosjeve.

187
00:08:11,950 --> 00:08:14,920
Dhe ne zgjidhur të gjithë në botë
problemet me përpunimin e të dhënave.

188
00:08:14,920 --> 00:08:17,550
>> Dhe kjo zgjati rreth 20 ose
30 vjet deri në evolucionin

189
00:08:17,550 --> 00:08:22,100
bazës së të dhënave relacionale, e cila
është kur bota ka vendosur ne tani

190
00:08:22,100 --> 00:08:27,940
duhet të ketë një depo që mposht
plandosem e të dhënave në të gjithë file

191
00:08:27,940 --> 00:08:29,540
sisteme që ne kemi ndërtuar. E drejtë?

192
00:08:29,540 --> 00:08:34,270
Të dhënave shumë të shpërndara në shumë shumë
vende, de-dyfishimin e të dhënave,

193
00:08:34,270 --> 00:08:37,120
dhe kostoja e magazinimit ishte shumë i madh.

194
00:08:37,120 --> 00:08:43,760
>> Në vitet '70, burimi më i shtrenjtë
se një kompjuter ka qenë e magazinimit.

195
00:08:43,760 --> 00:08:46,200
Procesor ishte
shihet si një kosto fikse.

196
00:08:46,200 --> 00:08:49,030
Kur unë blej kuti,
CPU bën disa punë.

197
00:08:49,030 --> 00:08:51,960
Ajo do të jetë tjerrje nëse
kjo është në fakt duke punuar apo jo.

198
00:08:51,960 --> 00:08:53,350
Kjo është me të vërtetë një kosto zhytur.

199
00:08:53,350 --> 00:08:56,030
>> Por çfarë kosto mua si një
biznesit është ruajtje.

200
00:08:56,030 --> 00:09:00,020
Nëse unë kam për të blerë më shumë disqe të ardhshëm
muaj, kjo është një e vërtetë që unë kosto të paguajnë.

201
00:09:00,020 --> 00:09:01,620
Dhe kjo magazinimit është e shtrenjtë.

202
00:09:01,620 --> 00:09:05,020
>> Tani ne shpejt përpara 40 vjet
dhe ne kemi një problem tjetër.

203
00:09:05,020 --> 00:09:10,020
Të llogaritin tani është
Burimi më i shtrenjtë.

204
00:09:10,020 --> 00:09:11,470
Magazinimit është i lirë.

205
00:09:11,470 --> 00:09:14,570
Unë do të thotë, ne mund të shkojnë kudo në
cloud dhe ne mund të gjeni magazinimit të lirë.

206
00:09:14,570 --> 00:09:17,190
Por ajo që unë nuk mund të gjeni është llogaritje lirë.

207
00:09:17,190 --> 00:09:20,700
>> Pra, evoluimin e sotme
teknologji, i teknologjisë së bazës së të dhënave,

208
00:09:20,700 --> 00:09:23,050
është e përqendruar me të vërtetë rreth
Bazat e të dhënave të shpërndara

209
00:09:23,050 --> 00:09:26,960
që nuk vuajnë nga
të njëjtin lloj të shkallës

210
00:09:26,960 --> 00:09:29,240
kufizimet e bazave të të dhënave relacionale.

211
00:09:29,240 --> 00:09:32,080
Ne do të flasim pak për
çka do të thotë që në fakt.

212
00:09:32,080 --> 00:09:34,760
>> Por një nga arsyet dhe
shoferi pas this-- ne

213
00:09:34,760 --> 00:09:38,290
foli për presionin e të dhënave.

214
00:09:38,290 --> 00:09:41,920
Presioni dhënave është diçka
që drejton risi.

215
00:09:41,920 --> 00:09:44,610
Dhe në qoftë se ju shikoni në mbi
pesë vitet e fundit,

216
00:09:44,610 --> 00:09:48,180
kjo është një tabelë e asaj të dhënave
ngarkesës nëpër ndërmarrje e përgjithshme

217
00:09:48,180 --> 00:09:49,640
duket si në pesë vitet e fundit.

218
00:09:49,640 --> 00:09:52,570
>> Dhe rregulli i përgjithshëm i gishtit
këto days-- qoftë se ju shkoni Google--

219
00:09:52,570 --> 00:09:55,290
është 90% e të dhënave që
ne dyqan sot, dhe kjo ishte

220
00:09:55,290 --> 00:09:57,330
gjeneruara brenda dy viteve të fundit.

221
00:09:57,330 --> 00:09:57,911
NE RREGULL.

222
00:09:57,911 --> 00:09:59,410
Tani, kjo nuk është një prirje që është e re.

223
00:09:59,410 --> 00:10:01,230
Kjo është një prirje që ka qenë
shkojnë jashtë për 100 vjet.

224
00:10:01,230 --> 00:10:03,438
Që nga Herman Hollerith
zhvilluar kartë shënoj,

225
00:10:03,438 --> 00:10:08,040
ne kemi qenë ndërtuar depo të dhënave
dhe mbledhjes së të dhënave me ritme fenomenale.

226
00:10:08,040 --> 00:10:10,570
>> Pra, gjatë 100 viteve të fundit,
ne kemi parë këtë trend.

227
00:10:10,570 --> 00:10:11,940
Kjo nuk do të ndryshojë.

228
00:10:11,940 --> 00:10:14,789
Duke shkuar përpara, ne jemi duke shkuar për të parë
kjo, nëse nuk është një prirje të përshpejtuar.

229
00:10:14,789 --> 00:10:16,330
Dhe ju mund të shihni se si duket kjo.

230
00:10:16,330 --> 00:10:23,510
>> Nëse një biznes në vitin 2010 ka pasur një të tillë
Terabyte e të dhënave nën menaxhim,

231
00:10:23,510 --> 00:10:27,080
sot kjo do të thotë se ata janë
menaxhimin 6.5 petabytes të të dhënave.

232
00:10:27,080 --> 00:10:30,380
Kjo është 6.500 herë më shumë të dhënave.

233
00:10:30,380 --> 00:10:31,200
Dhe unë e di këtë.

234
00:10:31,200 --> 00:10:33,292
Unë punoj me këto biznese çdo ditë.

235
00:10:33,292 --> 00:10:35,000
Pesë vjet më parë, unë
do të flasim për kompanitë

236
00:10:35,000 --> 00:10:38,260
të cilët do të bisedoni me mua në lidhje me atë që një dhimbje
kjo është për të menaxhuar terabajt të dhëna.

237
00:10:38,260 --> 00:10:39,700
Dhe ata do të flasin
për mua për mënyrën se si ne e shohim

238
00:10:39,700 --> 00:10:41,825
se kjo është ndoshta do
të jetë një Petabyte ose dy

239
00:10:41,825 --> 00:10:43,030
brenda nja dy vjet.

240
00:10:43,030 --> 00:10:45,170
>> Këto kompani të njëjta
sot unë jam takuar me,

241
00:10:45,170 --> 00:10:48,100
dhe ata janë duke folur për mua në lidhje me
Problemi janë atje të pasur menaxhimin

242
00:10:48,100 --> 00:10:51,440
dhjetëra, 20 petabajtë e të dhënave.

243
00:10:51,440 --> 00:10:53,590
Pra, shpërthimin e
të dhënat në industrinë e

244
00:10:53,590 --> 00:10:56,670
është leja e madhe
nevojë për zgjidhje më të mira.

245
00:10:56,670 --> 00:11:00,980
Dhe baza e të dhënave relacionale është
jo vetëm të jetojnë deri në kërkesën.

246
00:11:00,980 --> 00:11:03,490
>> Dhe kështu që nuk ka një linear
korrelacion në mes të presionit të dhënave

247
00:11:03,490 --> 00:11:05,210
dhe risi teknike.

248
00:11:05,210 --> 00:11:07,780
Historia na ka treguar
ky, që me kalimin e kohës,

249
00:11:07,780 --> 00:11:11,090
kur vëllimi i të dhënave
që duhet të jenë të përpunuara

250
00:11:11,090 --> 00:11:15,490
e tejkalon kapacitetin e sistemit
të përpunojë atë në një kohë të arsyeshme

251
00:11:15,490 --> 00:11:18,870
ose me një kosto të arsyeshme,
teknologjitë e pastaj reja

252
00:11:18,870 --> 00:11:21,080
janë shpikur për të zgjidhur këto probleme.

253
00:11:21,080 --> 00:11:24,090
Këto teknologjive të reja,
nga ana tjetër, të hapur derën

254
00:11:24,090 --> 00:11:27,840
për një tjetër grup të problemeve, të cilat
është mbledhur edhe më shumë të dhëna.

255
00:11:27,840 --> 00:11:29,520
>> Tani, ne nuk jemi duke shkuar për të ndaluar këtë.

256
00:11:29,520 --> 00:11:30,020
E drejtë?

257
00:11:30,020 --> 00:11:31,228
Ne nuk jemi duke shkuar për të ndaluar këtë.

258
00:11:31,228 --> 00:11:31,830
Përse?

259
00:11:31,830 --> 00:11:35,520
Sepse ju nuk mund të di çdo gjë
ka të dini në univers.

260
00:11:35,520 --> 00:11:40,510
Dhe për aq kohë sa ne kemi qenë gjallë,
gjatë gjithë historisë së njeriut,

261
00:11:40,510 --> 00:11:43,440
ne kemi shtyrë gjithmonë të dini më shumë.

262
00:11:43,440 --> 00:11:49,840
>> Pra, duket si çdo pëllëmbë të lëvizur
poshtë në rrugën e zbulimit shkencor,

263
00:11:49,840 --> 00:11:54,620
ne jemi shumëzuar sasinë e të dhënave
se ne kemi nevojë të procesit në mënyrë eksponenciale

264
00:11:54,620 --> 00:11:59,920
si ne zbulojë gjithnjë e më shumë e më shumë
për punët e brendshme të jetës,

265
00:11:59,920 --> 00:12:04,530
për mënyrën se si funksionon universi, në lidhje me
ngarje zbulimin shkencor,

266
00:12:04,530 --> 00:12:06,440
dhe shpikje që
ne jemi duke bërë sot.

267
00:12:06,440 --> 00:12:09,570
Vëllimi i të dhënave të vetëm
vazhdimisht rritet.

268
00:12:09,570 --> 00:12:12,120
Pra, duke qenë në gjendje të merren me
ky problem është i madh.

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

270
00:12:14,790 --> 00:12:17,410
>> Pra, një nga gjërat
ne shikojmë si pse NoSQL?

271
00:12:17,410 --> 00:12:19,200
Si funksionon NoSQL zgjidhur këtë problem?

272
00:12:19,200 --> 00:12:24,980
E pra, databaza relacionale,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- kjo është me të vërtetë një konstrukt i
relacionale database-- këto gjëra janë

274
00:12:28,600 --> 00:12:30,770
optimizuar për ruajtje.

275
00:12:30,770 --> 00:12:33,180
>> Kthehu në vitet '70, përsëri,
disk është e shtrenjtë.

276
00:12:33,180 --> 00:12:36,990
Ushtrimi sigurimin e ruajtjes
në ndërmarrje është i pafund.

277
00:12:36,990 --> 00:12:37,490
E di.

278
00:12:37,490 --> 00:12:38,020
Kam jetuar atë.

279
00:12:38,020 --> 00:12:41,250
Kam shkruar Shoferët e magazinimit për një
Kompania enterprised Superserveri

280
00:12:41,250 --> 00:12:42,470
prapa në vitet '90.

281
00:12:42,470 --> 00:12:45,920
Dhe në fund është tortues tjetër
Grup magazinimit ishte vetëm diçka që

282
00:12:45,920 --> 00:12:47,600
ndodhi çdo ditë në ndërmarrje.

283
00:12:47,600 --> 00:12:49,030
Dhe ajo kurrë nuk ndalet.

284
00:12:49,030 --> 00:12:52,690
Magazinimit të Lartë dendësia, kërkesa
për ruajtjen densitet të lartë,

285
00:12:52,690 --> 00:12:56,340
dhe për ruajtjen më efikas
devices-- ajo kurrë nuk ndalet.

286
00:12:56,340 --> 00:13:00,160
>> Dhe NoSQL është një teknologji e madhe
sepse ajo normalizes të dhënat.

287
00:13:00,160 --> 00:13:02,210
Ajo de-dyfishon të dhënat.

288
00:13:02,210 --> 00:13:07,180
Ajo vë të dhënat në një strukturë që
është agnostik për çdo model të qasjes.

289
00:13:07,180 --> 00:13:11,600
Aplikacionet e shumta mund të goditur atë
SQL databazë, të drejtuar pyetje ad hoc,

290
00:13:11,600 --> 00:13:15,950
dhe për të marrë të dhënat në formën që ata
nevojë për të procesit për Ngarkesat e punës tyre.

291
00:13:15,950 --> 00:13:17,570
Kjo tingëllon fantastike.

292
00:13:17,570 --> 00:13:21,350
Por në fund është me ndonjë
sistem, në qoftë se është agnostik për çdo gjë,

293
00:13:21,350 --> 00:13:23,500
ajo është e optimizuar për asgjë.

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

295
00:13:24,050 --> 00:13:26,386
>> Dhe kjo është ajo që ne të merrni me
baza e të dhënave relacionale.

296
00:13:26,386 --> 00:13:27,510
Është e optimizuar për ruajtje.

297
00:13:27,510 --> 00:13:28,280
Është normalizuar.

298
00:13:28,280 --> 00:13:29,370
Është relacionale.

299
00:13:29,370 --> 00:13:31,660
Ajo mbështet pyetje ad hoc.

300
00:13:31,660 --> 00:13:34,000
Dhe kjo dhe kjo peshore vertikalisht.

301
00:13:34,000 --> 00:13:39,030
>> Nëse unë duhet të merrni një bazë të dhënash të madhe SQL
ose një bazë të dhënash më të fuqishëm SQL,

302
00:13:39,030 --> 00:13:41,090
Unë shkoj të blej një copë të madhe të hekurit.

303
00:13:41,090 --> 00:13:41,600
NE RREGULL?

304
00:13:41,600 --> 00:13:44,940
Unë kam punuar me një shumë të konsumatorëve
që kanë qenë përmes përmirësimeve të mëdha

305
00:13:44,940 --> 00:13:48,340
në infrastrukturën e tyre SQL vetëm
për të gjetur se gjashtë muaj më vonë,

306
00:13:48,340 --> 00:13:49,750
ata janë goditur murin përsëri.

307
00:13:49,750 --> 00:13:55,457
Dhe përgjigja nga Oracle apo MSSQL
ose dikush tjetër është për të marrë një kuti të madhe.

308
00:13:55,457 --> 00:13:58,540
E pra shpejt ose më vonë, ju nuk mund të blejnë një
më e madhe kuti, dhe ky është problemi i vërtetë.

309
00:13:58,540 --> 00:14:00,080
Ne kemi nevojë që në fakt ndryshojnë gjërat.

310
00:14:00,080 --> 00:14:01,080
Pra, ku e bën këtë punë?

311
00:14:01,080 --> 00:14:06,560
Ajo punon mirë për offline
analytics, Ngarkesat e punës OLAP tipit.

312
00:14:06,560 --> 00:14:08,670
Dhe kjo është me të vërtetë ku SQL takon.

313
00:14:08,670 --> 00:14:12,540
Tani, ajo është përdorur sot në shumë Online
transaksional përpunimit të tipit

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

315
00:14:13,330 --> 00:14:16,460
Dhe ajo punon vetëm gjobë në
një nivel të shfrytëzimit,

316
00:14:16,460 --> 00:14:18,670
por ai thjesht nuk shkallë
mënyra se si NoSQL bën.

317
00:14:18,670 --> 00:14:20,660
Dhe ne do të flasim pak
bit se pse kjo është.

318
00:14:20,660 --> 00:14:23,590
>> Tani, NoSQL, nga ana tjetër,
është më shumë e optimizuar për llogaritjen.

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

320
00:14:24,540 --> 00:14:26,830
Kjo nuk është agnostik për
model qasje.

321
00:14:26,830 --> 00:14:31,620
Është ajo që ne e quajmë de-normalizuar
struktura ose një strukturë hierarkike.

322
00:14:31,620 --> 00:14:35,000
Të dhënat në një bazë të dhënash relacionale është
bashkuar nga tavolina të shumta

323
00:14:35,000 --> 00:14:36,850
për të prodhuar pamje që ju duhet.

324
00:14:36,850 --> 00:14:40,090
Të dhënat në bazën e të dhënave NoSQL
është ruajtur në një dokument që

325
00:14:40,090 --> 00:14:42,100
përmban strukturën hierarkike.

326
00:14:42,100 --> 00:14:45,670
Të gjitha të dhënave që normalisht do të jetë
u bashkuan së bashku për të prodhuar këtë pikëpamje

327
00:14:45,670 --> 00:14:47,160
është ruajtur në një dokument të vetëm.

328
00:14:47,160 --> 00:14:50,990
Dhe ne do të flasim pak për
si që punon në një çift të Listat.

329
00:14:50,990 --> 00:14:55,320
>> Por ideja këtu është se ju dyqan
të dhënat tuaja si këto pikëpamje instantiated.

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

331
00:14:56,410 --> 00:14:58,610
Ju shkallë horizontalisht.

332
00:14:58,610 --> 00:14:59,556
E drejtë?

333
00:14:59,556 --> 00:15:02,100
Nëse kam nevojë për të rritur
Madhësia e NoSQL grup tim,

334
00:15:02,100 --> 00:15:03,700
Unë nuk kam nevojë për të marrë një kuti të madhe.

335
00:15:03,700 --> 00:15:05,200
Kam marrë një tjetër kuti.

336
00:15:05,200 --> 00:15:07,700
Dhe unë grumbull ato së bashku,
dhe unë mund të copë e thyer ato të dhëna.

337
00:15:07,700 --> 00:15:10,780
Ne do të flasim pak për
çfarë sharding është, që të jetë

338
00:15:10,780 --> 00:15:14,270
në gjendje për të shkallë që bazën e të dhënave
gjithë pajisjeve të shumta fizike

339
00:15:14,270 --> 00:15:18,370
dhe për të hequr pengesën që
kërkon që më në shkallë vertikalisht.

340
00:15:18,370 --> 00:15:22,080
>> Pra, është e ndërtuar me të vërtetë për internet
përpunimi transaksion dhe shkallë.

341
00:15:22,080 --> 00:15:25,480
Ka një dallim i madh
këtu në mes të raportimit, e drejtë?

342
00:15:25,480 --> 00:15:27,810
Raportimi, unë nuk e di
Pyetje Unë jam duke shkuar për të pyetur.

343
00:15:27,810 --> 00:15:28,310
E drejtë?

344
00:15:28,310 --> 00:15:30,570
Reporting-- nëse dikush nga
departamenti im i marketingut

345
00:15:30,570 --> 00:15:34,520
dëshiron të just-- Sa nga klientët e mi
kanë këtë karakteristikë të veçantë që

346
00:15:34,520 --> 00:15:37,850
blerë në këtë day-- unë nuk e di
çfarë pyetje ata do të pyes.

347
00:15:37,850 --> 00:15:39,160
Kështu që unë duhet të jenë agnostik.

348
00:15:39,160 --> 00:15:41,810
>> Tani, në një Online
Aplikimi transaksional,

349
00:15:41,810 --> 00:15:43,820
Unë e di se çfarë pyetje unë jam duke kërkuar.

350
00:15:43,820 --> 00:15:46,581
I ndërtuar aplikimin për
një workflow shumë specifik.

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

352
00:15:47,080 --> 00:15:50,540
Pra, nëse unë zgjedh të dhënave
dyqan për të mbështetur këtë punës,

353
00:15:50,540 --> 00:15:52,020
ajo do të jetë më i shpejtë.

354
00:15:52,020 --> 00:15:55,190
Dhe kjo është arsyeja pse NoSQL mund
me të vërtetë të përshpejtojë shpërndarjen

355
00:15:55,190 --> 00:15:57,710
e këtyre llojeve të shërbimeve.

356
00:15:57,710 --> 00:15:58,210
Në rregull.

357
00:15:58,210 --> 00:16:00,501
>> Pra, ne jemi duke shkuar për të marrë në
pak e teorisë këtu.

358
00:16:00,501 --> 00:16:03,330
Dhe disa prej jush, sytë tuaj
mund të rrokulliset përsëri pak.

359
00:16:03,330 --> 00:16:06,936
Por unë do të përpiqemi për ta mbajtur atë
nivel të lartë si unë mund.

360
00:16:06,936 --> 00:16:08,880
Pra, nëse ju jeni në projekt
menaxhimit, ka

361
00:16:08,880 --> 00:16:12,280
një konstrukt quajtur
trekëndësh i kufizimeve.

362
00:16:12,280 --> 00:16:12,936
NE RREGULL.

363
00:16:12,936 --> 00:16:16,060
Trekëndëshi i kufizon diktatit
ju nuk mund të keni gjithçka gjatë gjithë kohës.

364
00:16:16,060 --> 00:16:17,750
Nuk mund të ketë byrek tuaj dhe të hani atë shumë.

365
00:16:17,750 --> 00:16:22,310
Pra, në menaxhimin e projekteve, që trekëndësh
Kufizimet është që ju mund të keni atë të lirë,

366
00:16:22,310 --> 00:16:24,710
ju mund të keni atë të shpejtë,
ose ju mund të keni atë mirë.

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

368
00:16:25,716 --> 00:16:27,090
Sepse ju nuk mund të ketë të gjitha tre.

369
00:16:27,090 --> 00:16:27,460
E drejtë?

370
00:16:27,460 --> 00:16:27,820
NE RREGULL.

371
00:16:27,820 --> 00:16:28,920
>> Pra, keni dëgjuar për këtë shumë.

372
00:16:28,920 --> 00:16:31,253
Është një detyrim trefishtë,
trekëndësh i kufizimit të trefishtë,

373
00:16:31,253 --> 00:16:34,420
ose trekëndësh hekuri është oftentimes--
kur ju bisedoni me menaxherët e projektit,

374
00:16:34,420 --> 00:16:35,420
ata do të flasin për këtë.

375
00:16:35,420 --> 00:16:37,640
Tani, Bazat e të dhënave kanë
vetë trekëndësh tyre hekuri.

376
00:16:37,640 --> 00:16:40,350
Dhe trekëndësh hekurt e të dhënave
është ajo që ne e quajmë CAP teorema.

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

378
00:16:41,580 --> 00:16:43,770
>> CAP dikton teorema
si bazave të të dhënave të veprojë

379
00:16:43,770 --> 00:16:45,627
nën një gjendje shumë të veçantë.

380
00:16:45,627 --> 00:16:47,460
Dhe ne do të flasim për
se çfarë gjendje është.

381
00:16:47,460 --> 00:16:52,221
Por tre pikat e trekëndëshit,
kështu që të flasin, janë C, qëndrueshmëri.

382
00:16:52,221 --> 00:16:52,720
NE RREGULL?

383
00:16:52,720 --> 00:16:56,760
Pra në CAP, qëndrueshmëri do të thotë se të gjithë
Klientët të cilët mund të hyni bazën e të dhënave

384
00:16:56,760 --> 00:16:59,084
gjithmonë do të ketë një shumë të
pamje konsistente e të dhënave.

385
00:16:59,084 --> 00:17:00,750
Gonna të askujt të shihni dy gjëra të ndryshme.

386
00:17:00,750 --> 00:17:01,480
NE RREGULL?

387
00:17:01,480 --> 00:17:04,020
Nëse unë shoh bazën e të dhënave,
Unë jam duke parë të njëjtin mendim

388
00:17:04,020 --> 00:17:06,130
si partnerin tim që sheh
e njëjta bazës së të dhënave.

389
00:17:06,130 --> 00:17:07,470
Kjo është e qëndrueshmëri.

390
00:17:07,470 --> 00:17:12,099
>> Disponueshmëria do të thotë se në qoftë se
bazës së të dhënave në internet, në qoftë se ajo mund të arrihet,

391
00:17:12,099 --> 00:17:14,760
që të gjithë klientët do të gjithmonë
të jenë në gjendje të lexojnë dhe shkruajnë.

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

393
00:17:15,260 --> 00:17:17,010
Pra, çdo klient që
mund të lexoni bazën e të dhënave

394
00:17:17,010 --> 00:17:18,955
do të jetë gjithmonë në gjendje lexuar
të dhënave dhe shkruar të dhëna.

395
00:17:18,955 --> 00:17:21,819
Dhe në qoftë se është e rastit,
është një sistem në dispozicion.

396
00:17:21,819 --> 00:17:24,230
>> Dhe pika e tretë është se çfarë
ne e quajmë tolerancë ndarje.

397
00:17:24,230 --> 00:17:24,730
NE RREGULL?

398
00:17:24,730 --> 00:17:28,160
Mjetet tolerancës Ndarja
se sistemi punon mirë

399
00:17:28,160 --> 00:17:32,000
pavarësisht rrjetit fizik
ndarëse midis nyjet.

400
00:17:32,000 --> 00:17:32,760
NE RREGULL?

401
00:17:32,760 --> 00:17:36,270
Pra, nyjet në grup nuk mund
bisedoni me njëri-tjetrin, çfarë ndodh?

402
00:17:36,270 --> 00:17:36,880
Në rregull.

403
00:17:36,880 --> 00:17:39,545
>> Bazave të të dhënave relacionale Pra choose--
ju mund të vini dy nga këto.

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

405
00:17:40,045 --> 00:17:43,680
Bazave të të dhënave relacionale Pra zgjidhni
të jenë në përputhje dhe në dispozicion.

406
00:17:43,680 --> 00:17:47,510
Nëse ndarja ndodh në mes
të DataNodes në dyqan e të dhënave,

407
00:17:47,510 --> 00:17:48,831
baza e të dhënave crashes.

408
00:17:48,831 --> 00:17:49,330
E drejtë?

409
00:17:49,330 --> 00:17:50,900
Ajo thjesht shkon poshtë.

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

411
00:17:51,450 --> 00:17:54,230
>> Dhe kjo është arsyeja pse ata kanë
të rritet me kuti të mëdha.

412
00:17:54,230 --> 00:17:54,730
E drejtë?

413
00:17:54,730 --> 00:17:58,021
Sepse nuk ka no-- zakonisht, një grup
bazës së të dhënave, nuk është shumë e shumë prej tyre

414
00:17:58,021 --> 00:17:59,590
që veprojnë në këtë mënyrë.

415
00:17:59,590 --> 00:18:03,019
Por shumica e bazave të të dhënave në shkallë
vertikalisht në një kuti vetme.

416
00:18:03,019 --> 00:18:05,060
Sepse ata duhet të jenë të
në përputhje dhe në dispozicion.

417
00:18:05,060 --> 00:18:10,320
Në qoftë se një ndarje duhej të injektuar,
atëherë ju do të keni për të bërë një zgjedhje.

418
00:18:10,320 --> 00:18:13,720
Ju duhet të bëni një zgjedhje në mes të
qenë në përputhje dhe në dispozicion.

419
00:18:13,720 --> 00:18:16,080
>> Dhe kjo është ajo që bëjnë bazat e të dhënave NoSQL.

420
00:18:16,080 --> 00:18:16,580
Në rregull.

421
00:18:16,580 --> 00:18:20,950
Pra, një bazë të dhënash NoSQL, atë
vjen në dy flavors.

422
00:18:20,950 --> 00:18:22,990
Ne have-- mirë, atë
vjen në shumë lloje,

423
00:18:22,990 --> 00:18:26,140
por ajo vjen me dy themelore
characteristics-- çfarë

424
00:18:26,140 --> 00:18:30,050
ne do të thërrasë bazë të dhënash CP, apo një
tolerancë të qëndrueshme dhe ndarje

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

426
00:18:31,040 --> 00:18:34,930
Këta njerëz të bëjë zgjedhjen që kur
nyjet humb kontakt me njëri-tjetrin,

427
00:18:34,930 --> 00:18:37,091
ne nuk jemi duke shkuar për të lejuar
njerëzit për të shkruar ndonjë më shumë.

428
00:18:37,091 --> 00:18:37,590
NE RREGULL?

429
00:18:37,590 --> 00:18:41,855
>> Deri në se ndarja është hequr,
Qasje shkruaj është bllokuar.

430
00:18:41,855 --> 00:18:43,230
Kjo do të thotë se ata nuk janë në dispozicion.

431
00:18:43,230 --> 00:18:44,510
Ata janë në përputhje.

432
00:18:44,510 --> 00:18:46,554
Kur ne shohim se
ndarje injektuar veten,

433
00:18:46,554 --> 00:18:48,470
ne tani janë në përputhje,
sepse ne nuk jemi duke shkuar

434
00:18:48,470 --> 00:18:51,517
për të lejuar ndryshimin e të dhënave në dy
anët e ndarjes në mënyrë të pavarur

435
00:18:51,517 --> 00:18:52,100
nga njëra-tjetra.

436
00:18:52,100 --> 00:18:54,130
Ne do të duhet të
rivendosur komunikimin

437
00:18:54,130 --> 00:18:56,930
para çdo update
të dhënave është e lejuar.

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

439
00:18:58,120 --> 00:19:02,650
>> Shije i ardhshëm do të jetë një sistem AP,
ose një në dispozicion dhe e ndarë

440
00:19:02,650 --> 00:19:03,640
sistem toleranca.

441
00:19:03,640 --> 00:19:05,320
Këta njerëz nuk e kujdesit.

442
00:19:05,320 --> 00:19:06,020
E drejtë?

443
00:19:06,020 --> 00:19:08,960
Çdo nyje që merr një
shkruaj, ne do të marrë atë.

444
00:19:08,960 --> 00:19:11,480
Kështu që unë jam përsëritur të dhënat e mia
nëpër nyje të shumta.

445
00:19:11,480 --> 00:19:14,730
Këto nyje të merrni një klient, klient vjen
në, thotë, unë jam duke shkuar për të shkruar disa të dhëna.

446
00:19:14,730 --> 00:19:16,300
Nyja thotë, nuk ka problem.

447
00:19:16,300 --> 00:19:18,580
Nyja pranë tij merr
një Shkruani në të njëjtën rekord,

448
00:19:18,580 --> 00:19:20,405
ai do të thotë nuk ka problem.

449
00:19:20,405 --> 00:19:23,030
Diku prapa në anën e pasme,
që të dhënat do të replikuar.

450
00:19:23,030 --> 00:19:27,360
Dhe pastaj dikush do të realizojë,
uh-oh, sistem ata do të kuptojnë, uh-oh,

451
00:19:27,360 --> 00:19:28,870
ka pasur një update për të dy palëve.

452
00:19:28,870 --> 00:19:30,370
Çfarë bëjmë ne?

453
00:19:30,370 --> 00:19:33,210
Dhe çfarë bëjnë ata atëherë është
ata bëjnë diçka që

454
00:19:33,210 --> 00:19:36,080
u lejon atyre për të zgjidhur atë shtet të dhënave.

455
00:19:36,080 --> 00:19:39,000
Dhe ne do të flasim për
që në tabelë ardhshëm.

456
00:19:39,000 --> 00:19:40,000
>> Gjë për të nxjerr në pah këtu.

457
00:19:40,000 --> 00:19:42,374
Dhe unë nuk jam duke shkuar për të marrë shumë
shumë në këtë, sepse ky

458
00:19:42,374 --> 00:19:43,510
merr në teorinë e të dhënave të thellë.

459
00:19:43,510 --> 00:19:46,670
Por ka një transaksional
kornizë që

460
00:19:46,670 --> 00:19:50,680
shkon në një sistem relacionale që
lejon mua për të në mënyrë të sigurtë të rejat

461
00:19:50,680 --> 00:19:53,760
të subjekteve të shumta në bazën e të dhënave.

462
00:19:53,760 --> 00:19:58,320
Dhe ato më të reja do të ndodhë
të gjitha në të njëjtën kohë ose aspak.

463
00:19:58,320 --> 00:20:00,500
Dhe kjo quhet transaksioneve acid.

464
00:20:00,500 --> 00:20:01,000
NE RREGULL?

465
00:20:01,000 --> 00:20:06,570
>> ACID na jep atomicity, qëndrueshmëri,
izolimi, dhe qëndrueshmëri.

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

467
00:20:07,070 --> 00:20:13,550
Kjo do të thotë atomike, transaksionet, të gjithë
Përditësimet e mia ose të ndodhë, ose ata nuk e bëjnë.

468
00:20:13,550 --> 00:20:16,570
Konsistenca do të thotë se
baza e të dhënave do të gjithmonë

469
00:20:16,570 --> 00:20:19,780
të sillen në një të qëndrueshme
shteti pas një update.

470
00:20:19,780 --> 00:20:23,900
Unë kurrë nuk do të largohet bazën e të dhënave në një
gjendja e keqe pas aplikimit një update.

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

472
00:20:24,400 --> 00:20:26,720
>> Pra, kjo është pak më ndryshe
se konsistencës CAP.

473
00:20:26,720 --> 00:20:29,760
Qëndrueshmëri CAP do të thotë të gjithë e mia
Klientët mund gjithmonë të shohin të dhënat.

474
00:20:29,760 --> 00:20:34,450
Konsistencë ACID do të thotë se kur
një transaksion është bërë, të dhënat e të mirë.

475
00:20:34,450 --> 00:20:35,709
Marrëdhëniet e mia janë të gjithë të mirë.

476
00:20:35,709 --> 00:20:38,750
Unë nuk jam duke shkuar për të fshirë një rresht prind
dhe të lënë një bandë e fëmijëve jetimë

477
00:20:38,750 --> 00:20:40,970
në ndonjë tryezë tjetër.

478
00:20:40,970 --> 00:20:44,320
Kjo nuk mund të ndodhë në qoftë se unë jam në përputhje
në një transaksion acid.

479
00:20:44,320 --> 00:20:49,120
>> Izolimi do të thotë se transaksionet
gjithmonë do të ndodhë njëri pas tjetrit.

480
00:20:49,120 --> 00:20:51,920
Rezultati përfundimtar i të dhënave
do të jetë e njëjtë shteti

481
00:20:51,920 --> 00:20:54,770
sikur ato transaksione
që janë lëshuar njëkohësisht

482
00:20:54,770 --> 00:20:57,340
u ekzekutuan në seri.

483
00:20:57,340 --> 00:21:00,030
Pra, kjo është concurrency
kontrolli në bazën e të dhënave.

484
00:21:00,030 --> 00:21:04,130
Pra, në thelb, unë nuk mund të rrisim
njëjtën vlerë dy herë me dy operacione.

485
00:21:04,130 --> 00:21:08,580
>> Por në qoftë se unë them shtoni 1 për këtë vlerë,
dhe dy transaksione të vijë në

486
00:21:08,580 --> 00:21:10,665
dhe të përpiqet të bëjë atë, një është
do të merrni atje në fillim

487
00:21:10,665 --> 00:21:12,540
dhe tjetra e
do të merrni atje pas.

488
00:21:12,540 --> 00:21:15,210
Pra, në fund, kam shtuar dy.

489
00:21:15,210 --> 00:21:16,170
Ju shihni se çfarë dua të them?

490
00:21:16,170 --> 00:21:16,670
NE RREGULL.

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

492
00:21:19,220 --> 00:21:21,250
>> Qëndrueshmëri është shumë i thjeshtë.

493
00:21:21,250 --> 00:21:23,460
Kur transaksioni
është pranuar, është

494
00:21:23,460 --> 00:21:26,100
do të jetë aty edhe
nëse sistemi crashes.

495
00:21:26,100 --> 00:21:29,230
Kur se sistemi rimëkëmbet, që
transaksion që është kryer

496
00:21:29,230 --> 00:21:30,480
është në të vërtetë do të jetë atje.

497
00:21:30,480 --> 00:21:33,130
Pra, kjo është garanton
e transaksioneve acid.

498
00:21:33,130 --> 00:21:35,470
Ata janë garanci pretty nice
që të ketë në një bazë të dhënash,

499
00:21:35,470 --> 00:21:36,870
por ata vijnë në atë kosto.

500
00:21:36,870 --> 00:21:37,640
E drejtë?

501
00:21:37,640 --> 00:21:40,520
>> Për shkak të problemit
me këtë kornizë është

502
00:21:40,520 --> 00:21:44,540
nëse ka një ndarje në të dhënat
vendosur, unë kam për të marrë një vendim.

503
00:21:44,540 --> 00:21:48,000
Unë do të ketë për të lejuar
Përditësimet në njërën anë apo tjetrën.

504
00:21:48,000 --> 00:21:50,310
Dhe nëse kjo ndodh,
atëherë unë nuk jam duke shkuar

505
00:21:50,310 --> 00:21:52,630
të jetë në gjendje për të ruajtur
këto karakteristika.

506
00:21:52,630 --> 00:21:53,960
Ata nuk do të jenë në përputhje.

507
00:21:53,960 --> 00:21:55,841
Ata nuk do të jenë të izoluara.

508
00:21:55,841 --> 00:21:58,090
Kjo është ajo ku ajo prishet
për bazat e të dhënave relacionale.

509
00:21:58,090 --> 00:22:01,360
Kjo është arsyeja relacionale
Bazat e të dhënave shkallë vertikalisht.

510
00:22:01,360 --> 00:22:05,530
>> Në anën tjetër, ne kemi
atë që quhet teknologji BASE.

511
00:22:05,530 --> 00:22:07,291
Dhe këto janë Bazat e të dhënave tuaja NoSQL.

512
00:22:07,291 --> 00:22:07,790
Në rregull.

513
00:22:07,790 --> 00:22:10,180
Pra, ne kemi CP tonë, bazave të AP.

514
00:22:10,180 --> 00:22:14,720
Dhe këto janë ato që ju e quani në thelb
në dispozicion, shteti të butë, përfundimisht

515
00:22:14,720 --> 00:22:15,740
në përputhje.

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

517
00:22:16,420 --> 00:22:19,690
>> Në thelb në dispozicion, sepse
ata janë ndarja tolerant.

518
00:22:19,690 --> 00:22:21,470
Ata gjithmonë do të jetë
atje, edhe në qoftë se ka

519
00:22:21,470 --> 00:22:23,053
një ndarje rrjet në mes të nyjeve.

520
00:22:23,053 --> 00:22:25,900
Në qoftë se unë mund të flas me një nyje, unë jam
do të jetë në gjendje për të lexuar të dhënat.

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

522
00:22:26,460 --> 00:22:30,810
Unë nuk mund të jetë gjithmonë në gjendje për të shkruar
të dhëna në qoftë se unë jam një platformë të qëndrueshme.

523
00:22:30,810 --> 00:22:32,130
Por unë do të jetë në gjendje për të lexuar të dhënat.

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

525
00:22:34,960 --> 00:22:38,010
>> Shteti butë tregon
që kur kam lexuar se të dhënat,

526
00:22:38,010 --> 00:22:40,790
kjo mund të mos jetë e njëjtë si nyjet e tjera.

527
00:22:40,790 --> 00:22:43,390
Në qoftë se një e drejtë është lëshuar në një nyje
diku tjetër në grup

528
00:22:43,390 --> 00:22:46,650
dhe kjo nuk ka përsëriten Përtej
Grumbulli por kur lexova se të dhënat,

529
00:22:46,650 --> 00:22:48,680
se shteti mund të mos jenë në përputhje.

530
00:22:48,680 --> 00:22:51,650
Megjithatë, ajo do të jetë
përfundimisht në përputhje,

531
00:22:51,650 --> 00:22:53,870
do të thotë se kur një shkruaj
është bërë për të sistemit,

532
00:22:53,870 --> 00:22:56,480
ajo do të përsëris të gjithë nyjet.

533
00:22:56,480 --> 00:22:59,095
Dhe përfundimisht, ai shtet
do të sillet në mënyrë,

534
00:22:59,095 --> 00:23:00,890
dhe kjo do të jetë një shtet i qëndrueshëm.

535
00:23:00,890 --> 00:23:05,000
>> Tani, CAP teorema vërtetë
luan vetëm në një kusht.

536
00:23:05,000 --> 00:23:08,700
Se gjendja është kur kjo ndodh.

537
00:23:08,700 --> 00:23:13,710
Sepse sa herë që e veprojnë në
Mënyra normale, nuk ka ndarje,

538
00:23:13,710 --> 00:23:16,370
çdo gjë është në përputhje dhe në dispozicion.

539
00:23:16,370 --> 00:23:19,990
Ju shqetësohen vetëm për CAP
kur ne kemi këtë ndarje.

540
00:23:19,990 --> 00:23:21,260
Kështu që ata janë të rralla.

541
00:23:21,260 --> 00:23:25,360
Por se si sistemi reagon kur ata
ndodhë diktojnë se çfarë lloji i sistemit

542
00:23:25,360 --> 00:23:26,750
ne jemi që kanë të bëjnë me të.

543
00:23:26,750 --> 00:23:31,110
>> Pra, le të marrin një vështrim në atë që
që duket si për sistemet AP.

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

545
00:23:32,621 --> 00:23:34,830
Sistemet AP vijnë në dy flavors.

546
00:23:34,830 --> 00:23:38,514
Ata vijnë në shije që është një
mjeshtër mjeshtër, 100%, gjithmonë në dispozicion.

547
00:23:38,514 --> 00:23:40,430
Dhe ata vijnë në
shije të tjera, që thotë:

548
00:23:40,430 --> 00:23:43,330
ju e dini se çfarë, unë jam duke shkuar për t'u shqetësuar
në lidhje me këtë gjë ndarjes

549
00:23:43,330 --> 00:23:44,724
kur një ndarje aktuale ndodh.

550
00:23:44,724 --> 00:23:47,890
Përndryshe, nuk do të jetë primar
nyjet që do të marrë të drejtat.

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

552
00:23:48,500 --> 00:23:50,040
>> Pra, nëse ne diçka si Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra do të jetë një mjeshtër
mjeshtër, le të më shkruajë për çdo nyje.

554
00:23:54,440 --> 00:23:55,540
Pra, çfarë ndodh?

555
00:23:55,540 --> 00:23:58,270
Kështu që unë kam një objekt në
bazës së të dhënave që ekziston në dy nyjeve.

556
00:23:58,270 --> 00:24:01,705
Le të thërrasë atë objekt S.
Pra, ne kemi shtetin për S.

557
00:24:01,705 --> 00:24:04,312
Ne kemi disa operacione
në S që janë në vazhdim.

558
00:24:04,312 --> 00:24:06,270
Cassandra lejon mua që të
shkruani në nyje të shumta.

559
00:24:06,270 --> 00:24:08,550
Pra, le të thonë se unë të marrë një
shkruaj për s për të dy nyjeve.

560
00:24:08,550 --> 00:24:12,274
E pra, ajo që përfundon deri ndodh është
ne e quajmë atë një ngjarje të ndarjes.

561
00:24:12,274 --> 00:24:14,190
Nuk mund të jetë një
ndarje fizike të rrjetit.

562
00:24:14,190 --> 00:24:15,950
Por për shkak të dizajnit
e sistemit, është e

563
00:24:15,950 --> 00:24:18,449
në fakt ndarjes sa më shpejt
si unë të marrë një të shkruaj mbi dy nyjeve.

564
00:24:18,449 --> 00:24:20,830
Kjo nuk është e detyruar mua për të
shkruaj gjatë gjithë një nyje.

565
00:24:20,830 --> 00:24:22,340
Unë jam me shkrim në dy nyje.

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

567
00:24:23,330 --> 00:24:25,740
>> Deri tani unë kam dy shtete.

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

569
00:24:26,360 --> 00:24:28,110
Çfarë do të ndodhë
është herët a vonë,

570
00:24:28,110 --> 00:24:29,960
atje do të jetë një ngjarje e përsëritje.

571
00:24:29,960 --> 00:24:33,300
Nuk do të jetë ajo që ne
quhet një shërim ndarje, e cila

572
00:24:33,300 --> 00:24:35,200
është vendi ku këto dy
shtetet të vijnë përsëri së bashku

573
00:24:35,200 --> 00:24:37,310
dhe atje do të jetë një algoritmi
që shkon brenda bazën e të dhënave,

574
00:24:37,310 --> 00:24:38,540
vendos se çfarë të bëjmë.

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

576
00:24:39,110 --> 00:24:43,057
By default, përditësimi i fundit
fiton në shumicën e sistemeve AP.

577
00:24:43,057 --> 00:24:44,890
Pra, ka zakonisht një
parazgjedhur algorithm, çfarë

578
00:24:44,890 --> 00:24:47,400
ata e quajnë një callback
funksion, diçka që

579
00:24:47,400 --> 00:24:51,000
do të quhet kur ky kusht
është zbuluar për të ekzekutuar disa logjikën

580
00:24:51,000 --> 00:24:52,900
për të zgjidhur këtë konflikt.

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

582
00:24:53,850 --> 00:24:58,770
Callback parazgjedhur dhe parazgjedhur
zgjidhës në shumicën e bazave të të dhënave AP

583
00:24:58,770 --> 00:25:01,130
është, guess what, timestamp fiton.

584
00:25:01,130 --> 00:25:02,380
Kjo ishte përditësimi i fundit.

585
00:25:02,380 --> 00:25:04,320
Unë jam duke shkuar për të vënë atë përditësim në atje.

586
00:25:04,320 --> 00:25:08,440
Unë mund të hale këtë rekord që unë
hedhur jashtë në një regjistër të rimëkëmbjes

587
00:25:08,440 --> 00:25:11,670
në mënyrë që përdoruesi mund të kthehen më vonë
dhe thonë, hej, ka pasur një përplasje.

588
00:25:11,670 --> 00:25:12,320
Cfare ndodhi?

589
00:25:12,320 --> 00:25:16,370
Dhe ju në fakt mund të hale një rekord të
të gjitha goditjet dhe rollbacks

590
00:25:16,370 --> 00:25:17,550
dhe shikoni se çfarë ndodh.

591
00:25:17,550 --> 00:25:21,580
>> Tani, si një përdorues, ju gjithashtu mund të
përfshijnë logjikën në atë callback.

592
00:25:21,580 --> 00:25:24,290
Kështu që ju mund të ndryshojë atë
operacion callback.

593
00:25:24,290 --> 00:25:26,730
Ju mund të thoni, hej, unë dua
për të ndrequr këto të dhëna.

594
00:25:26,730 --> 00:25:28,880
Dhe unë dua të provoni dhe
bashkojë këto dy shënime.

595
00:25:28,880 --> 00:25:30,050
Por kjo është deri te ju.

596
00:25:30,050 --> 00:25:32,880
Baza e të dhënave nuk e di se si për të
bëjnë që nga default. Shumica e kohës,

597
00:25:32,880 --> 00:25:34,850
e vetmja gjë që baza e të dhënave
e di se si të bëni është të themi,

598
00:25:34,850 --> 00:25:36,100
ky ishte rekord fundit.

599
00:25:36,100 --> 00:25:39,183
Kjo është ajo që do të fitojë,
dhe kjo është vlera që unë jam duke shkuar për të vënë.

600
00:25:39,183 --> 00:25:41,490
Pasi atij shërim ndarje
dhe përsëritje ndodh,

601
00:25:41,490 --> 00:25:43,930
ne kemi shtetin tonë, i cili
tani është S kryesor, i cili është

602
00:25:43,930 --> 00:25:46,890
gjendja bashkojë të gjitha ato objekte.

603
00:25:46,890 --> 00:25:49,700
Pra sistemet AP të ketë këtë.

604
00:25:49,700 --> 00:25:51,615
Sistemet CP nuk kanë nevojë
për t'u shqetësuar për këtë.

605
00:25:51,615 --> 00:25:54,490
Sepse sa më shpejt që vjen një ndarje
në lojë, ata vetëm të ndaluar marrjen

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

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

608
00:25:56,180 --> 00:25:58,670
Pra, kjo është shumë e lehtë për të
merren me të qenit në përputhje

609
00:25:58,670 --> 00:26:01,330
kur ju nuk e pranoni ndonjë më të reja.

610
00:26:01,330 --> 00:26:04,620
Kjo është me sistemet CP bëjë.

611
00:26:04,620 --> 00:26:05,120
Në rregull.

612
00:26:05,120 --> 00:26:07,590
>> Pra, le të flasim pak
bit për modelet e aksesit.

613
00:26:07,590 --> 00:26:11,580
Kur ne flasim për NoSQL, është
të gjitha në lidhje me modelin e qasjes.

614
00:26:11,580 --> 00:26:13,550
Tani, SQL është ad hoc, pyetje.

615
00:26:13,550 --> 00:26:14,481
Është dyqan relacionale.

616
00:26:14,481 --> 00:26:16,480
Ne nuk duhet të shqetësohen
në lidhje me modelin e qasjes.

617
00:26:16,480 --> 00:26:17,688
Unë shkruaj një pyetje shumë komplekse.

618
00:26:17,688 --> 00:26:19,250
Ajo shkon dhe merr të dhënat.

619
00:26:19,250 --> 00:26:21,210
Kjo është ajo që kjo duket
si, normalizimi.

620
00:26:21,210 --> 00:26:24,890
>> Pra, në këtë strukturë të veçantë,
ne jemi duke kërkuar në një katalog produkteve.

621
00:26:24,890 --> 00:26:26,640
Unë kam lloje të ndryshme të produkteve.

622
00:26:26,640 --> 00:26:27,217
Kam libra.

623
00:26:27,217 --> 00:26:27,800
Unë kam albume.

624
00:26:27,800 --> 00:26:30,090
Kam video.

625
00:26:30,090 --> 00:26:33,370
Marrëdhënia në mes të produkteve
dhe çdo një nga këto libra, albume,

626
00:26:33,370 --> 00:26:34,860
dhe video tavolina është 1: 1.

627
00:26:34,860 --> 00:26:35,800
Në rregull?

628
00:26:35,800 --> 00:26:38,860
Unë kam marrë një ID të produktit,
dhe që i përgjigjet ID

629
00:26:38,860 --> 00:26:41,080
në një libër, një album, ose një video.

630
00:26:41,080 --> 00:26:41,580
NE RREGULL?

631
00:26:41,580 --> 00:26:44,350
Kjo është një 1: 1 marrëdhënie
nëpër ato tavolina.

632
00:26:44,350 --> 00:26:46,970
>> Tani, të gjithë ata books--
kanë është prona rrënjë.

633
00:26:46,970 --> 00:26:47,550
Nuk ka problem.

634
00:26:47,550 --> 00:26:48,230
Kjo është e madhe.

635
00:26:48,230 --> 00:26:52,130
Një-për-një marrëdhënie, Unë të marrë të gjitha
të dhënat Unë kam nevojë për të përshkruar atë libër.

636
00:26:52,130 --> 00:26:54,770
Albume Albums-- kanë gjurmët.

637
00:26:54,770 --> 00:26:56,470
Kjo është ajo që ne e quajmë njëri shumë.

638
00:26:56,470 --> 00:26:58,905
Çdo album do të ketë shumë këngë.

639
00:26:58,905 --> 00:27:00,780
Pra, për çdo udhë në
album, unë mund të ketë

640
00:27:00,780 --> 00:27:02,570
një tjetër rekord në këtë tabelë fëmijëve.

641
00:27:02,570 --> 00:27:04,680
Kështu që unë krijoj një rekord
në tryezën albumet e mia.

642
00:27:04,680 --> 00:27:06,700
I krijuar regjistrime të shumëfishta
në tabelën gjurmët.

643
00:27:06,700 --> 00:27:08,850
Marrëdhënie një-me-shumë.

644
00:27:08,850 --> 00:27:11,220
>> Kjo marrëdhënie është çfarë
ne e quajmë shumë-me-shumë.

645
00:27:11,220 --> 00:27:11,750
NE RREGULL?

646
00:27:11,750 --> 00:27:17,000
Ju shihni se aktorët mund të jetë
në shumë filma, shume video.

647
00:27:17,000 --> 00:27:21,450
Pra, ajo që ne bëjmë është ne kemi vënë këtë hartë
tavolinë mes atyre, që ai vetëm

648
00:27:21,450 --> 00:27:24,040
harta ID aktorit në ID videove.

649
00:27:24,040 --> 00:27:28,464
Tani unë mund të krijojë një query bashkohet
video përmes aktorit video për aktorët,

650
00:27:28,464 --> 00:27:31,130
dhe kjo më jep një listë e bukur e
të gjitha filmat dhe të gjithë aktorët

651
00:27:31,130 --> 00:27:32,420
që ishin në atë film.

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

653
00:27:33,290 --> 00:27:33,880
Pra, këtu ne do të shkojmë.

654
00:27:33,880 --> 00:27:38,040
Një-për-një është e nivelit të lartë
marrëdhënie; një-për-shumë,

655
00:27:38,040 --> 00:27:40,240
Albumet më gjurmët; shumë-me-shumë.

656
00:27:40,240 --> 00:27:44,990
Ata janë tre të nivelit të lartë
marrëdhëniet në çdo bazë të dhënash.

657
00:27:44,990 --> 00:27:48,050
Nëse ju e dini se si ata
marrëdhëniet punojnë së bashku,

658
00:27:48,050 --> 00:27:51,490
atëherë ju e dini shumë
në lidhje me bazën e të dhënave tashmë.

659
00:27:51,490 --> 00:27:55,660
Pra NoSQL punon pak ndryshe.

660
00:27:55,660 --> 00:27:58,930
Le të mendojmë për një të dytë për atë që
Duket si për të shkuar të marrë të gjitha produktet e mia.

661
00:27:58,930 --> 00:28:01,096
>> Në një dyqan relacionale, unë
doni të merrni të gjitha produktet e mia

662
00:28:01,096 --> 00:28:02,970
në një listë të të gjitha produktet e mia.

663
00:28:02,970 --> 00:28:04,910
Kjo është një shumë e pyetje.

664
00:28:04,910 --> 00:28:07,030
Unë kam një pyetje për të gjithë librat e mi.

665
00:28:07,030 --> 00:28:08,470
Unë kam një pyetje nga albumet e mia.

666
00:28:08,470 --> 00:28:09,970
Dhe unë kam një pyetje për të gjithë videot e mia.

667
00:28:09,970 --> 00:28:11,719
Dhe kam marrë për ta vënë atë
të gjithë së bashku në një listë

668
00:28:11,719 --> 00:28:15,250
dhe për të shërbyer atë deri në të
kërkesë që e kërkon atë.

669
00:28:15,250 --> 00:28:18,000
>> Për të marrë librat e mi, unë bashkohem
Produktet dhe libra.

670
00:28:18,000 --> 00:28:21,680
Për të marrë albumet e mia, kam marrë për t'u bashkuar
Produkte, Albume, dhe gjurmët.

671
00:28:21,680 --> 00:28:25,330
Dhe për të marrë videot e mia, unë kam
për t'u bashkuar Produkte të Videos,

672
00:28:25,330 --> 00:28:28,890
bashkohen përmes aktor Videos,
dhe për të sjellë në Aktorët.

673
00:28:28,890 --> 00:28:31,020
Pra, kjo është tre pyetje.

674
00:28:31,020 --> 00:28:34,560
Pyetje shumë komplekse për të
mblidhen një grup rezultat.

675
00:28:34,560 --> 00:28:36,540
>> Kjo është më pak se optimale.

676
00:28:36,540 --> 00:28:39,200
Kjo është arsyeja pse kur flasim
në lidhje me një strukturë të dhënave që është

677
00:28:39,200 --> 00:28:42,900
ndërtuar që të jetë agnostik për qasje
pattern-- mirë që është e madhe.

678
00:28:42,900 --> 00:28:45,730
Dhe ju mund të shihni këtë është me të vërtetë
mirë se si ne kemi organizuar e të dhënave.

679
00:28:45,730 --> 00:28:46,550
Dhe ju e dini se çfarë?

680
00:28:46,550 --> 00:28:49,750
Kam vetëm një rekord për një aktor.

681
00:28:49,750 --> 00:28:50,440
>> Kjo është e ftohtë.

682
00:28:50,440 --> 00:28:53,750
Unë e kam deduplicated gjithë aktorët e mia,
dhe unë mbajtur shoqatat e mia

683
00:28:53,750 --> 00:28:55,200
në këtë tabelë hartës.

684
00:28:55,200 --> 00:29:00,620
Megjithatë, duke marrë të dhënat e
jashtë bëhet i shtrenjtë.

685
00:29:00,620 --> 00:29:04,500
Unë jam i dërguar CPU në të gjithë sistemin e
bashkimin e këtyre strukturave të dhënave së bashku

686
00:29:04,500 --> 00:29:05,950
të jetë në gjendje për të tërhequr këto të dhëna mbrapa.

687
00:29:05,950 --> 00:29:07,310
>> Pra, si mund unë të marrë rreth se?

688
00:29:07,310 --> 00:29:11,200
Në NoSQL është në lidhje
grumbullimi, jo normalizimi.

689
00:29:11,200 --> 00:29:13,534
Pra, ne duam të themi se duam të
mbështesin modelin qasje.

690
00:29:13,534 --> 00:29:15,283
Nëse modelin e qasjes
të aplikimeve,

691
00:29:15,283 --> 00:29:16,770
Unë kam nevojë për të marrë të gjitha produktet e mia.

692
00:29:16,770 --> 00:29:19,027
Le të vënë të gjitha produktet në një tryezë.

693
00:29:19,027 --> 00:29:22,110
Nëse unë vënë të gjitha produktet në një tryezë,
Unë vetëm mund të zgjidhni të gjitha produktet

694
00:29:22,110 --> 00:29:23,850
nga ajo tryezë dhe unë të marrë të gjitha.

695
00:29:23,850 --> 00:29:25,240
Pra si mund ta bëni këtë?

696
00:29:25,240 --> 00:29:28,124
Edhe në NoSQL nuk ka asnjë
Struktura në tryezë.

697
00:29:28,124 --> 00:29:30,540
Ne do të flasim pak për
se si kjo punon në Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Por ju nuk keni të njëjtin
atributet dhe të njëjtat pronat

699
00:29:33,570 --> 00:29:37,751
në çdo rresht të vetëm, në çdo të vetme
pika, si ju bëni në një tryezë SQL.

700
00:29:37,751 --> 00:29:39,750
Dhe çfarë kjo lejon mua
të bëni është një shumë gjëra

701
00:29:39,750 --> 00:29:41,124
dhe jepni një shumë fleksibilitet.

702
00:29:41,124 --> 00:29:45,360
Në këtë rast të veçantë, unë
kanë dokumentet e mia të produktit.

703
00:29:45,360 --> 00:29:49,090
Dhe në këtë të veçantë
shembull, çdo gjë

704
00:29:49,090 --> 00:29:51,930
është një dokument në tabelën e produkteve.

705
00:29:51,930 --> 00:29:56,510
Dhe produkt për një libër të fuqisë
kanë një ID tip që përcakton një libër.

706
00:29:56,510 --> 00:29:59,180
Dhe aplikimi
do të kaloni në këtë ID.

707
00:29:59,180 --> 00:30:02,570
>> Në grupin e aplikimit, unë jam duke shkuar
për të thënë oh, çfarë lloji rekord është kjo?

708
00:30:02,570 --> 00:30:04,100
Oh, kjo është një rekord libër.

709
00:30:04,100 --> 00:30:05,990
Librin kanë këto prona.

710
00:30:05,990 --> 00:30:08,100
Më lejoni të krijoni një objekt libër.

711
00:30:08,100 --> 00:30:11,289
Kështu që unë jam duke shkuar për të mbushur
objekt libër me këtë artikull.

712
00:30:11,289 --> 00:30:13,080
Pika tjetër vjen dhe
thotë, çfarë është kjo artikull?

713
00:30:13,080 --> 00:30:14,560
E pra ky artikull është një album.

714
00:30:14,560 --> 00:30:17,340
Oh, kam marrë një të tërë të ndryshme
përpunimit rutinë për atë,

715
00:30:17,340 --> 00:30:18,487
sepse kjo është një album.

716
00:30:18,487 --> 00:30:19,320
Ju shihni se çfarë dua të them?

717
00:30:19,320 --> 00:30:21,950
>> Pra, kërkesa tier-- unë
thjesht zgjidhni të gjitha këto shënime.

718
00:30:21,950 --> 00:30:23,200
Ata të gjithë të fillojnë të vijnë në.

719
00:30:23,200 --> 00:30:24,680
Ato mund të jenë të gjitha llojet e ndryshme.

720
00:30:24,680 --> 00:30:27,590
Dhe kjo është logjika e aplikimit
që kalon nëpër ato lloje

721
00:30:27,590 --> 00:30:29,530
dhe vendos se si të përpunojë ato.

722
00:30:29,530 --> 00:30:33,640
>> Përsëri, kështu që ne jemi optimizimin e
skema për modelin qasje.

723
00:30:33,640 --> 00:30:36,390
Ne jemi duke bërë atë me
kolaps ato tavolina.

724
00:30:36,390 --> 00:30:39,670
Ne jemi në thelb duke marrë
këto struktura normalizuar,

725
00:30:39,670 --> 00:30:42,000
dhe ne jemi duke ndërtuar
struktura hierarkike.

726
00:30:42,000 --> 00:30:45,130
Brenda secilit prej këtyre të dhënave
Unë jam duke shkuar për të parë pronat e array.

727
00:30:45,130 --> 00:30:49,400
>> Brenda këtij dokumenti për albume,
Unë jam duke parë vargjeve të pista.

728
00:30:49,400 --> 00:30:53,900
Këto këngë tani become-- është
Në thelb kjo tabelë fëmijë që

729
00:30:53,900 --> 00:30:56,520
ekziston e drejtë këtu në këtë strukturë.

730
00:30:56,520 --> 00:30:57,975
Kështu që ju mund ta bëni këtë në DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Ju mund ta bëni këtë në MongoDB.

732
00:30:59,810 --> 00:31:01,437
Ju mund ta bëni këtë në çdo bazë të dhënash NoSQL.

733
00:31:01,437 --> 00:31:03,520
Krijo këto lloje të
strukturat e të dhënave hierarkike

734
00:31:03,520 --> 00:31:07,120
që ju lejon të rifitoj të dhënave
shumë shpejt, sepse tani unë

735
00:31:07,120 --> 00:31:08,537
nuk duhet të jenë në përputhje.

736
00:31:08,537 --> 00:31:11,620
Kur kam futur një rresht në gjurmët
tavolinë, ose një rresht në tabelën e albume,

737
00:31:11,620 --> 00:31:13,110
Unë duhet të jenë në përputhje me këtë skemë.

738
00:31:13,110 --> 00:31:18,060
Unë duhet të ketë atribut ose
Prona që është përcaktuar në këtë tryezë.

739
00:31:18,060 --> 00:31:20,480
Çdo njëri prej tyre,
kur kam futur atë rresht.

740
00:31:20,480 --> 00:31:21,910
Kjo nuk është rasti në NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Unë mund të ketë krejtësisht të ndryshme
Pronat në çdo dokument

742
00:31:24,440 --> 00:31:26,100
që kam futur në koleksion.

743
00:31:26,100 --> 00:31:30,480
Mekanizëm aq shumë i fuqishëm.

744
00:31:30,480 --> 00:31:32,852
Dhe kjo është me të vërtetë si ju
zgjedh sistemin.

745
00:31:32,852 --> 00:31:35,310
Sepse tani këtë pyetje, në vend
i bashkuar të gjitha këto tabelat

746
00:31:35,310 --> 00:31:39,160
dhe ekzekutimin e një një duzinë e gjysmë pyetje
për të tërhequr mbrapsht të dhënat kam nevojë,

747
00:31:39,160 --> 00:31:40,890
Unë jam ekzekutimin e një pyetje.

748
00:31:40,890 --> 00:31:43,010
Dhe unë jam iterating
të gjithë rezultatet e përcaktuara.

749
00:31:43,010 --> 00:31:46,512
kjo ju jep një ide
e fuqisë së NoSQL.

750
00:31:46,512 --> 00:31:49,470
Unë jam duke shkuar për të shkuar lloj anash këtu
dhe flasim pak për këtë.

751
00:31:49,470 --> 00:31:53,240
Kjo është më shumë lloj i
marketingu apo technology--

752
00:31:53,240 --> 00:31:55,660
marketingu i teknologjisë
lloji i diskutimit.

753
00:31:55,660 --> 00:31:58,672
Por është e rëndësishme për të kuptuar
sepse nëse ne shikojmë në krye

754
00:31:58,672 --> 00:32:00,380
këtu në këtë tabelë,
ajo që ne jemi duke kërkuar në

755
00:32:00,380 --> 00:32:04,030
është ajo që ne e quajmë
teknologji hype kurbë.

756
00:32:04,030 --> 00:32:06,121
Dhe çfarë kjo do të thotë është
gjëra të reja vjen në lojë.

757
00:32:06,121 --> 00:32:07,120
Njerëzit mendojnë se është e madhe.

758
00:32:07,120 --> 00:32:09,200
Unë e kam zgjidhur të gjitha problemet e mia.

759
00:32:09,200 --> 00:32:11,630
>> Kjo mund të jetë fundi
të gjithë, të jenë të gjitha për çdo gjë.

760
00:32:11,630 --> 00:32:12,790
Dhe ata të fillojnë duke e përdorur atë.

761
00:32:12,790 --> 00:32:14,720
Dhe ata thonë, kjo stuff nuk funksionon.

762
00:32:14,720 --> 00:32:17,600
Kjo nuk është e drejtë.

763
00:32:17,600 --> 00:32:19,105
Stuff vjetër ishte më i mirë.

764
00:32:19,105 --> 00:32:21,230
Dhe ata të shkojnë përsëri për të bërë të
gjëra mënyra se si ata ishin.

765
00:32:21,230 --> 00:32:22,730
Dhe pastaj në fund
ata të shkojnë, ju e dini se çfarë?

766
00:32:22,730 --> 00:32:24,040
Kjo stuff nuk është aq e keqe.

767
00:32:24,040 --> 00:32:26,192
Oh, kjo është se si funksionon.

768
00:32:26,192 --> 00:32:28,900
Dhe një herë ata të kuptoj se si ajo
Punimet, ata fillojnë të shkojnë më mirë.

769
00:32:28,900 --> 00:32:32,050
>> Dhe gjëja qesharake në lidhje me të
është, ai lloj i linjave deri në çfarë

770
00:32:32,050 --> 00:32:34,300
ne e quajmë Curve Teknologji birësimin.

771
00:32:34,300 --> 00:32:36,910
Pra, çfarë ndodh është që ne kemi
disa shkaktojë teknologji lloj.

772
00:32:36,910 --> 00:32:39,100
Në rastin e bazave të të dhënave,
kjo është presion dhënave.

773
00:32:39,100 --> 00:32:42,200
Ne biseduam në lidhje me pikat e larta të ujit
e presionit të dhënave gjatë gjithë kohës.

774
00:32:42,200 --> 00:32:46,310
Kur se presioni dhënat e godet një të caktuar
pikë, kjo është shkas teknologji.

775
00:32:46,310 --> 00:32:47,830
>> Është duke u shumë të shtrenjta.

776
00:32:47,830 --> 00:32:49,790
Ajo merr shumë kohë për të përpunuar të dhënat.

777
00:32:49,790 --> 00:32:50,890
Ne kemi nevojë për diçka më të mirë.

778
00:32:50,890 --> 00:32:52,890
Ju merrni risimtarët
atje endet,

779
00:32:52,890 --> 00:32:55,050
duke u përpjekur për të gjetur se çfarë është zgjidhja.

780
00:32:55,050 --> 00:32:56,050
Çfarë është ideja e re?

781
00:32:56,050 --> 00:32:58,170
>> Çfarë është më e mirë
mënyrë për të bërë këtë gjë?

782
00:32:58,170 --> 00:32:59,530
Ata vijnë me diçka.

783
00:32:59,530 --> 00:33:03,140
Dhe njerëzit me dhimbje e vërtetë,
djemtë në buzë gjakderdhje,

784
00:33:03,140 --> 00:33:06,390
ata do të hidhen mbi të gjitha,
sepse ata kanë nevojë për një përgjigje.

785
00:33:06,390 --> 00:33:09,690
Tani ajo që në mënyrë të pashmangshme happens-- dhe
kjo po ndodh tani në NoSQL.

786
00:33:09,690 --> 00:33:11,090
Unë shoh atë gjatë gjithë kohës.

787
00:33:11,090 --> 00:33:13,610
>> Çfarë ndodh në mënyrë të pashmangshme është
njerëzit fillojnë duke përdorur mjet të ri

788
00:33:13,610 --> 00:33:15,490
në të njëjtën mënyrë ata kanë përdorur mjet vjetër.

789
00:33:15,490 --> 00:33:17,854
Dhe ata e gjejnë atë jashtë
nuk punon aq mirë.

790
00:33:17,854 --> 00:33:20,020
Unë nuk mund të mbani mend kush isha
duke folur për të më parë sot.

791
00:33:20,020 --> 00:33:22,080
Por kjo është si, kur
Jackhammer u shpik,

792
00:33:22,080 --> 00:33:24,621
njerëzit nuk e lëkundur atë mbi
kreu i tyre për të goditur konkrete.

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

794
00:33:27,360 --> 00:33:30,610
>> Por kjo është ajo që është
ndodh me NoSQL sot.

795
00:33:30,610 --> 00:33:33,900
Në qoftë se ju ecni në të shumicën e dyqaneve,
ata janë duke u përpjekur të jenë dyqane NoSQL.

796
00:33:33,900 --> 00:33:36,510
Çfarë ata po bëjnë është
ata janë duke përdorur NoSQL,

797
00:33:36,510 --> 00:33:39,900
dhe ata janë të ngarkimit atë
plot me skemen relacionale.

798
00:33:39,900 --> 00:33:41,630
Sepse kjo është se si
ata të hartuar bazat e të dhënave.

799
00:33:41,630 --> 00:33:44,046
Dhe ata jeni të pyesin, pse është
ajo nuk kryen shumë mirë?

800
00:33:44,046 --> 00:33:45,230
Boy, kjo gjë stinks.

801
00:33:45,230 --> 00:33:49,900
Unë kisha për të ruajtur të gjithë e mia
bashkohet in-- është si, jo, jo.

802
00:33:49,900 --> 00:33:50,800
Ruajtja e bashkohet?

803
00:33:50,800 --> 00:33:52,430
Pse jeni bashkuar të dhënat?

804
00:33:52,430 --> 00:33:54,350
Ju nuk mund të bashkohet me të dhënat në NoSQL.

805
00:33:54,350 --> 00:33:55,850
Ju agregate atë.

806
00:33:55,850 --> 00:34:00,690
>> Pra, nëse ju doni të shmangur këtë, të mësojnë
si mjet punon para se të vërtetë

807
00:34:00,690 --> 00:34:02,010
filloni duke e përdorur atë.

808
00:34:02,010 --> 00:34:04,860
Nuk do të përpiqet dhe të përdorin mjete të reja
njëjtën mënyrë keni përdorur mjetet e vjetra.

809
00:34:04,860 --> 00:34:06,500
Ju jeni do të ketë një përvojë të keqe.

810
00:34:06,500 --> 00:34:08,848
Dhe çdo herë të vetme
kjo është ajo që kjo është rreth.

811
00:34:08,848 --> 00:34:11,389
Kur ne fillojmë të ardhur deri këtu,
kjo është për shkak se njerëzit me motive nga

812
00:34:11,389 --> 00:34:13,449
se si të përdorin mjetet.

813
00:34:13,449 --> 00:34:16,250
>> Ata e bënë të njëjtën gjë kur
databaza relacionale ishin shpikur,

814
00:34:16,250 --> 00:34:17,969
dhe ata ishin zëvendësuar file sistemeve.

815
00:34:17,969 --> 00:34:20,420
Ata u përpoqën të ndërtojnë file sistemeve
me bazat e të dhënave relacionale

816
00:34:20,420 --> 00:34:22,159
sepse kjo është ajo që njerëzit e kuptuan.

817
00:34:22,159 --> 00:34:23,049
Ajo nuk ka punë.

818
00:34:23,049 --> 00:34:26,090
Pra, të kuptuarit e praktikave më të mira
e teknologjisë ju jeni duke punuar me

819
00:34:26,090 --> 00:34:26,730
është i madh.

820
00:34:26,730 --> 00:34:29,870
Shume e rendesishme.

821
00:34:29,870 --> 00:34:32,440
>> Pra, ne jemi duke shkuar për të marrë në DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB është AWS-së
plotësisht të menaxhuar platformë NoSQL.

823
00:34:36,480 --> 00:34:37,719
Çfarë do të plotësisht të menaxhuar të thotë?

824
00:34:37,719 --> 00:34:40,010
Kjo do të thotë që ju nuk keni nevojë për të
me të vërtetë të shqetësuar për ndonjë gjë.

825
00:34:40,010 --> 00:34:42,060
>> Ju vijnë në, ju thoni
SHBA, kam nevojë për një tryezë.

826
00:34:42,060 --> 00:34:43,409
Ajo ka nevojë për këtë kapacitet shumë.

827
00:34:43,409 --> 00:34:47,300
Ju goditi butonin, dhe sigurimi ne
gjithë infrastrukturën e prapa skenës.

828
00:34:47,300 --> 00:34:48,310
Tani që është shumë e madhe.

829
00:34:48,310 --> 00:34:51,310
>> Sepse kur ju flisni
në lidhje me shkallë një bazë të dhënash,

830
00:34:51,310 --> 00:34:53,917
Dhënave NoSQL grupimeve në
shkallë, petabajtë drejtimin,

831
00:34:53,917 --> 00:34:55,750
drejtimin e miliona
transaksionet për sekondë,

832
00:34:55,750 --> 00:34:58,180
këto gjëra nuk janë grupe të vogla.

833
00:34:58,180 --> 00:35:00,830
Ne jemi duke folur me mijëra raste.

834
00:35:00,830 --> 00:35:04,480
Menaxhimi mijëra raste,
edhe raste virtuale,

835
00:35:04,480 --> 00:35:06,350
është një dhimbje e vërtetë në prapanicë.

836
00:35:06,350 --> 00:35:09,110
Unë do të thotë, mendoj për çdo kohë një
Sistemi operativ patch vjen nga

837
00:35:09,110 --> 00:35:11,552
ose një version i ri i bazën e të dhënave.

838
00:35:11,552 --> 00:35:13,260
Cfare do te thote ajo
për ju operative?

839
00:35:13,260 --> 00:35:16,330
Kjo do të thotë ju mori 1.200
serverat që duhet të përditësohen.

840
00:35:16,330 --> 00:35:18,960
Tani edhe me automatizimin,
që mund të marrë një kohë të gjatë.

841
00:35:18,960 --> 00:35:21,480
Kjo mund të shkaktojë shumë
dhimbje koke operacionale,

842
00:35:21,480 --> 00:35:23,090
sepse unë mund të ketë shërbime poshtë.

843
00:35:23,090 --> 00:35:26,070
>> Siç kam rinovuar këto baza të dhënash, unë
mund të bëjë vendosjen e trupave Blue Green

844
00:35:26,070 --> 00:35:29,420
ku kam vendosur dhe për të përmirësuar gjysmë tim
nyjet, dhe pastaj të përmirësuar gjysmën tjetër.

845
00:35:29,420 --> 00:35:30,490
Marrë ato poshtë.

846
00:35:30,490 --> 00:35:33,410
Pra, menaxhimin e infrastrukturës
shkallë është jashtëzakonisht e dhimbshme.

847
00:35:33,410 --> 00:35:36,210
Dhe AWS marrë atë dhimbje nga ajo.

848
00:35:36,210 --> 00:35:39,210
Dhe bazave të të dhënave NoSQL mund
të jetë jashtëzakonisht e dhimbshme

849
00:35:39,210 --> 00:35:41,780
për shkak të mënyrë ata shkallë.

850
00:35:41,780 --> 00:35:42,926
>> Scale horizontalisht.

851
00:35:42,926 --> 00:35:45,550
Nëse ju doni të merrni një NoSQL madhe
bazës së të dhënave, ju blini më shumë nyje.

852
00:35:45,550 --> 00:35:48,660
Çdo nyje keni blerë është
një tjetër dhimbje koke operacional.

853
00:35:48,660 --> 00:35:50,830
Pra, le dikush tjetër të bëjë atë për ju.

854
00:35:50,830 --> 00:35:52,000
AWS mund ta bëjë këtë.

855
00:35:52,000 --> 00:35:54,587
>> Ne mbështesim vlerat dokument kyçe.

856
00:35:54,587 --> 00:35:56,670
Tani ne nuk ka shkuar shumë
në në tabelë tjetër.

857
00:35:56,670 --> 00:35:58,750
Ka shumë të ndryshme
shijet e NoSQL.

858
00:35:58,750 --> 00:36:02,670
Ata janë të gjitha llojet e gjetjes
munged së bashku në këtë pikë.

859
00:36:02,670 --> 00:36:06,260
Ju mund të shikoni në DynamoDB dhe të thonë po,
ne jemi si një dokument dhe një vlerë kyçe

860
00:36:06,260 --> 00:36:08,412
ruajtur këtë pikë.

861
00:36:08,412 --> 00:36:10,620
Dhe ju mund të argumentojnë tiparet
e njëri mbi tjetrin.

862
00:36:10,620 --> 00:36:13,950
Për mua, një shumë kjo është me të vërtetë gjashtë
e një gjysmë duzinë të tjera.

863
00:36:13,950 --> 00:36:18,710
Secili prej këtyre teknologjive eshte nje
teknologji gjobë dhe një zgjidhje gjobë.

864
00:36:18,710 --> 00:36:23,390
Unë nuk do të thonë se është më e mirë apo MongoDB
më keq se shtrat, pastaj Cassandra,

865
00:36:23,390 --> 00:36:25,994
pastaj Dynamo, ose anasjelltas.

866
00:36:25,994 --> 00:36:27,285
Unë do të thotë, këto janë vetëm options.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Është i shpejtë dhe kjo është
konsistente në çdo shkallë.

869
00:36:32,700 --> 00:36:36,210
Pra, kjo është një nga më të madh
shpërblimet që ju të merrni me AWS.

870
00:36:36,210 --> 00:36:40,850
Me DynamoDB është aftësia
për të marrë një shifër të ulët të vetme

871
00:36:40,850 --> 00:36:44,040
latente milisekonda në çdo shkallë.

872
00:36:44,040 --> 00:36:45,720
Ky ishte një gol Dizajni i sistemit.

873
00:36:45,720 --> 00:36:49,130
Dhe ne kemi klientët që janë duke bërë
miliona transaksione për sekondë.

874
00:36:49,130 --> 00:36:52,670
>> Tani unë do të shkoj nëpër disa nga ato
përdorin raste në disa minuta këtu.

875
00:36:52,670 --> 00:36:55,660
Control-- Integruar qasje
ne kemi atë që ne e quajmë

876
00:36:55,660 --> 00:36:57,920
Identiteti Menaxhimi Access, ose IAM.

877
00:36:57,920 --> 00:37:01,980
Ajo përshkon çdo sistem,
çdo shërbim që ofron AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB nuk është përjashtim.

879
00:37:03,630 --> 00:37:06,020
Ju mund të kontrollojë aksesin
në tabelat DynamoDB.

880
00:37:06,020 --> 00:37:09,960
Nëpër të gjitha AWS tuaj llogaritë nga
definimin e roleve qasje dhe lejet

881
00:37:09,960 --> 00:37:12,140
në infrastrukturën IAM.

882
00:37:12,140 --> 00:37:16,630
>> Dhe kjo është një komponent kyç dhe integral në
ajo që ne e quajmë ngjarje Programim shtyrë.

883
00:37:16,630 --> 00:37:19,056
Tani kjo është një paradigmë e re.

884
00:37:19,056 --> 00:37:22,080
>> Audienca: Si është Shkalla juaj e vërtetë
pozitive kundrejt negative të rreme

885
00:37:22,080 --> 00:37:24,052
në sistemin tuaj të kontrollit të qasjes?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: pozitive True
kundrejt negative të rreme?

887
00:37:26,260 --> 00:37:28,785
Audienca: Kthimi çfarë
ju duhet të kthehen?

888
00:37:28,785 --> 00:37:33,720
Në krahasim me një herë në një kohë të
nuk e kthen, kur ajo duhet të provoj?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: Unë nuk mund t'ju them se.

891
00:37:38,050 --> 00:37:40,140
Nëse ka ndonjë dështimet
çfarëdo qoftë në këtë,

892
00:37:40,140 --> 00:37:42,726
Unë nuk jam personi për të kërkuar
kjo pyetje të veçantë.

893
00:37:42,726 --> 00:37:43,850
Por kjo është një pyetje e mirë.

894
00:37:43,850 --> 00:37:45,905
Unë do të jetë kurioz të di
se veten time, në të vërtetë.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Dhe kështu pastaj përsëri, paradigmë e re
është ngjarja shtyrë programimit.

897
00:37:51,320 --> 00:37:55,160
Kjo është ideja që ju mund të
vendosur aplikacionet komplekse që

898
00:37:55,160 --> 00:37:59,720
mund të veprojë një shkallë shumë të lartë, shumë
pa asnjë infrastrukturë whatsoever.

899
00:37:59,720 --> 00:38:02,120
Pa asnjë fikse
Infrastruktura whatsoever.

900
00:38:02,120 --> 00:38:04,720
Dhe ne do të flasim pak
për çka do të thotë si ne

901
00:38:04,720 --> 00:38:06,550
të marrë në për nja dy Listat.

902
00:38:06,550 --> 00:38:08,716
>> Gjëja e parë që ne do të bëjmë
është që ne do të flasim për tavolina.

903
00:38:08,716 --> 00:38:10,857
Llojet e të dhënave API për Dynamo.

904
00:38:10,857 --> 00:38:13,190
Dhe gjëja e parë që ju do të
vini re kur ju shikoni në këtë,

905
00:38:13,190 --> 00:38:17,930
në qoftë se ju jeni të njohur me çdo bazë të dhënash,
Bazat e të dhënave duhet të vërtetë dy lloj TV

906
00:38:17,930 --> 00:38:18,430
Unë do të thërrasë atë.

907
00:38:18,430 --> 00:38:21,570
Ose dy grupe të API.

908
00:38:21,570 --> 00:38:23,840
Njëri nga ata do të jetë
API administrative.

909
00:38:23,840 --> 00:38:26,710
>> Gjërat ata të kujdeset për
funksionet e bazën e të dhënave.

910
00:38:26,710 --> 00:38:31,340
Configuring motor magazinimit,
ngritjen dhe duke shtuar tavolina.

911
00:38:31,340 --> 00:38:35,180
krijimit të bazës së të dhënave
katalogë dhe raste.

912
00:38:35,180 --> 00:38:40,450
Këto things-- në DynamoDB, ju
kanë, listat shumë të shkurtër të shkurtër.

913
00:38:40,450 --> 00:38:43,120
>> Pra, në bazat e të dhënave të tjera,
ju mund të shihni dhjetra

914
00:38:43,120 --> 00:38:45,680
i urdhëron, e administrative
komandat, për të konfiguruar

915
00:38:45,680 --> 00:38:47,290
këto opsione shtesë.

916
00:38:47,290 --> 00:38:51,234
Në DynamoDB ju nuk keni nevojë ata, sepse
ju nuk e konfiguroni sistemin, ne bëjmë.

917
00:38:51,234 --> 00:38:54,150
Pra, e vetmja gjë që ju duhet të bëni është të
më tregoni se çfarë tavolinë madhësia nuk kam nevojë.

918
00:38:54,150 --> 00:38:55,660
Pra, ju merrni një shumë të
grup i kufizuar i komandave.

919
00:38:55,660 --> 00:38:58,618
>> Ju merrni një Krijo Tabela Update, Tabela,
Fshij Tabela, dhe Përshkruani Tabela.

920
00:38:58,618 --> 00:39:01,150
Ata janë të vetmet gjëra
ju keni nevojë për DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Ju nuk keni nevojë për një ruajtje
konfigurimit motor.

922
00:39:03,294 --> 00:39:04,960
Unë nuk duhet të shqetësohen për përsëritje.

923
00:39:04,960 --> 00:39:06,490
Unë nuk duhet të shqetësohen për sharding.

924
00:39:06,490 --> 00:39:07,800
>> Unë nuk kam nevojë për t'u shqetësuar
në lidhje me ndonjë të këtij stuff.

925
00:39:07,800 --> 00:39:08,740
Ne bëjmë të gjitha për ju.

926
00:39:08,740 --> 00:39:11,867
Pra, kjo është një sasi të madhe të sipërm
që është ngritur vetëm jashtë pjatë tuaj.

927
00:39:11,867 --> 00:39:13,200
Pastaj kemi operatorët Crud.

928
00:39:13,200 --> 00:39:17,740
Crud është diçka që ne
të telefononi në bazën e të dhënave që është

929
00:39:17,740 --> 00:39:19,860
Krijo, update, Delete operatorët.

930
00:39:19,860 --> 00:39:24,180
Këto janë të zakonshme tuaj
operacionet e bazës së të dhënave.

931
00:39:24,180 --> 00:39:31,299
Gjëra të tilla si pika të shitur, të marrë pika, përditësim
artikuj, fshirë objekte, grumbull query, scan.

932
00:39:31,299 --> 00:39:32,840
Nëse ju doni të scan të gjithë tabelën.

933
00:39:32,840 --> 00:39:34,220
Tërhiqe gjithçka jashtë tryezë.

934
00:39:34,220 --> 00:39:37,130
Një nga gjërat e bukur për DynamoDB
është ajo lejon skanim paralele.

935
00:39:37,130 --> 00:39:40,602
Kështu që ju mund të vërtetë të më lejoni të dinë se sa
temat ju doni të drejtuar në atë scan.

936
00:39:40,602 --> 00:39:41,810
Dhe ne mund të kandidojë ato temat.

937
00:39:41,810 --> 00:39:43,985
Ne mund të tjerr se të skanoni deri
nëpër temat e shumta

938
00:39:43,985 --> 00:39:49,060
kështu që ju mund të skanoni të gjithë tabelën
hapësirë ​​shumë, shumë shpejt në DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> API tjetër që kemi është
ajo që ne e quajmë Streams API ynë.

940
00:39:51,490 --> 00:39:52,940
Ne nuk do të flasim shumë
shumë për këtë tani.

941
00:39:52,940 --> 00:39:55,189
Unë kam marrë disa përmbajtje më vonë
në në kuvertë në lidhje me këtë.

942
00:39:55,189 --> 00:39:59,910
Por Streams është me të vërtetë një running--
të mendojnë për atë si koha e urdhëroi

943
00:39:59,910 --> 00:40:01,274
dhe log ndryshim ndarje.

944
00:40:01,274 --> 00:40:03,940
Çdo gjë që po ndodh në
tabela tregon deri në lumë.

945
00:40:03,940 --> 00:40:05,940
>> Çdo shkruani në tryezë
tregon deri në lumë.

946
00:40:05,940 --> 00:40:08,370
Ju mund të lexoni këtë lumë, dhe
ju mund të bëni gjëra me të.

947
00:40:08,370 --> 00:40:10,150
Ne do të flasim për atë që
llojet e gjërave që ju

948
00:40:10,150 --> 00:40:13,680
të bëjë me gjëra të tilla si përsëritje,
krijuar indekseve dytësore.

949
00:40:13,680 --> 00:40:17,620
Të gjitha llojet e vërtetë cool
gjëra që ju mund të bëni me atë.

950
00:40:17,620 --> 00:40:19,150
>> Llojet e të dhënave.

951
00:40:19,150 --> 00:40:23,320
Në DynamoDB, ne mbështesim si çelës
Vlera e dhe të dhënat dokument lloje.

952
00:40:23,320 --> 00:40:26,350
Në anën e majtë të ekranit
këtu, ne kemi marrë lloje tona themelore.

953
00:40:26,350 --> 00:40:27,230
Llojet kryesore vlerë.

954
00:40:27,230 --> 00:40:30,040
Këto janë vargjet,
numra, dhe binareve.

955
00:40:30,040 --> 00:40:31,640
>> Pra, vetëm tre lloje themelore.

956
00:40:31,640 --> 00:40:33,700
Dhe pastaj ju mund të ketë grupe të atyre.

957
00:40:33,700 --> 00:40:37,650
Një nga gjërat e bukur rreth NoSQL është
ju mund të përmbajë vargjeve si pronat.

958
00:40:37,650 --> 00:40:42,050
Dhe me DynamoDB ju mund të përmbajë vargjeve
e llojeve themelore, si një pronë rrënjë.

959
00:40:42,050 --> 00:40:43,885
>> Dhe pastaj nuk ka llojet dokument.

960
00:40:43,885 --> 00:40:45,510
Sa njerëz janë të njohur me JSON?

961
00:40:45,510 --> 00:40:47,130
Ju djema njohur me JSON kaq shumë?

962
00:40:47,130 --> 00:40:49,380
Kjo është në thelb JavaScript,
Objekt, simbol.

963
00:40:49,380 --> 00:40:52,510
Kjo ju lejon për të në thelb
të përcaktojë një strukturë hierarkike.

964
00:40:52,510 --> 00:40:58,107
>> Ju mund të ruajë një dokument JSON në
DynamoDB duke përdorur komponente të përbashkëta

965
00:40:58,107 --> 00:41:00,940
ose blloqe ndërtimi që janë në dispozicion
në gjuhë programuese.

966
00:41:00,940 --> 00:41:03,602
Pra, nëse ju keni Java, ju jeni
duke kërkuar në hartat dhe listat.

967
00:41:03,602 --> 00:41:05,060
Unë mund të krijojë objekte që hartë zonë.

968
00:41:05,060 --> 00:41:08,030
Një hartë si vlera kryesore
ruhet si pronat.

969
00:41:08,030 --> 00:41:10,890
Dhe kjo mund të ketë listat e
Vlerat brenda ato prona.

970
00:41:10,890 --> 00:41:13,490
Ju mund të ruajë këtë kompleks
Struktura hierarkike

971
00:41:13,490 --> 00:41:16,320
si një atribut të vetme
e një artikull DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Pra, tavolina në DynamoDB, si shumica
Bazat e të dhënave NoSQL, tavolina keni artikuj.

974
00:41:24,460 --> 00:41:26,469
Në MongoDB ju do
quajmë këto dokumente.

975
00:41:26,469 --> 00:41:27,760
Dhe kjo do të jetë bazë shtrat.

976
00:41:27,760 --> 00:41:28,900
Gjithashtu një bazë të dhënash dokument.

977
00:41:28,900 --> 00:41:29,941
Ju e quani këto dokumente.

978
00:41:29,941 --> 00:41:32,930
Dokumente ose sende të ketë atributet.

979
00:41:32,930 --> 00:41:35,850
Atributet mund të ekzistojnë ose
nuk ekzistojnë në pika.

980
00:41:35,850 --> 00:41:38,520
Në DynamoDB, nuk ka
një atribut i detyrueshëm.

981
00:41:38,520 --> 00:41:43,880
Ashtu si në një bazë të dhënash relacionale,
ju keni një kyç primar në tryezë.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB ka atë që ne e quajmë një çelës hash.

983
00:41:46,010 --> 00:41:48,280
Kyç Hash duhet të jetë unike.

984
00:41:48,280 --> 00:41:52,580
Kështu që, kur unë të përcaktojë një tabelë hash,
në thelb ajo që unë jam duke thënë

985
00:41:52,580 --> 00:41:54,110
është çdo send do të ketë një çelës hash.

986
00:41:54,110 --> 00:41:58,520
Dhe çdo kyç hash duhet të jetë unike.

987
00:41:58,520 --> 00:42:01,200
>> Çdo artikull është përcaktuar
deri në atë çelës unik hash.

988
00:42:01,200 --> 00:42:02,940
Dhe nuk mund të jetë vetëm një.

989
00:42:02,940 --> 00:42:05,820
Kjo është në rregull, por shpesh
çfarë njerëzit kanë nevojë

990
00:42:05,820 --> 00:42:08,170
është se ata duan është kjo hash
Çelësi për të bërë një pak më shumë

991
00:42:08,170 --> 00:42:11,010
se vetëm të jetë një identifikues unik.

992
00:42:11,010 --> 00:42:15,240
Shpesh ne duam të përdorin këtë çelës hash
si të lartë kovë nivel grumbullimi.

993
00:42:15,240 --> 00:42:19,160
Dhe mënyra e bëjmë këtë është duke
duke shtuar se ajo që ne e quajmë një çelës varg.

994
00:42:19,160 --> 00:42:22,460
>> Pra, nëse kjo është vetëm një hash
tavolinë, kjo duhet të jetë unike.

995
00:42:22,460 --> 00:42:27,040
Në qoftë se kjo është një hash dhe varg tryezën, me
Kombinimi i hash dhe varg

996
00:42:27,040 --> 00:42:28,640
duhet të jetë unike.

997
00:42:28,640 --> 00:42:30,110
Pra, mendoj se në këtë mënyrë.

998
00:42:30,110 --> 00:42:32,140
Nëse unë kam një forum.

999
00:42:32,140 --> 00:42:39,010
Dhe forma e ka tema, ajo ka
postimet, dhe ajo ka përgjigje.

1000
00:42:39,010 --> 00:42:42,630
>> Kështu që unë mund të ketë një hash
kryesor, i cili është ID topic.

1001
00:42:42,630 --> 00:42:46,650
Dhe unë mund të ketë një çelës varg,
që është ID përgjigje.

1002
00:42:46,650 --> 00:42:49,650
Në këtë mënyrë në qoftë se unë dua të merrni të gjitha
Përgjigjet për temë të caktuar,

1003
00:42:49,650 --> 00:42:52,370
Unë vetëm mund të query hash.

1004
00:42:52,370 --> 00:42:55,190
Unë vetëm mund të them më jepni të gjitha
sendet që kanë këtë hash.

1005
00:42:55,190 --> 00:43:01,910
Dhe unë jam duke shkuar për të marrë çdo pyetje
ose postoni për këtë temë të veçantë.

1006
00:43:01,910 --> 00:43:03,910
Këto aggregations nivelit të lartë
janë shumë të rëndësishme.

1007
00:43:03,910 --> 00:43:07,370
Ata mbështesin qasje primare
model i aplikimit.

1008
00:43:07,370 --> 00:43:09,420
Në përgjithësi, kjo
është ajo që ne duam të bëjmë.

1009
00:43:09,420 --> 00:43:11,780
Ne duam që table--
si ju ngarkesës në tryezë,

1010
00:43:11,780 --> 00:43:16,640
ne duam për të strukturuar e të dhënave
brenda tavolinë në një mënyrë të tillë

1011
00:43:16,640 --> 00:43:20,140
se aplikimi mund shumë
shpejt të marrim këto rezultate.

1012
00:43:20,140 --> 00:43:24,510
Dhe shpesh mënyra për të bërë këtë është
për të ruajtur këto bashkimet si ne

1013
00:43:24,510 --> 00:43:25,650
futur të dhënat.

1014
00:43:25,650 --> 00:43:31,110
Në thelb, ne jemi përhapjen e të dhënave
në kovë ndritshme si ajo vjen në.

1015
00:43:31,110 --> 00:43:35,210
>> Çelësat varg të lejojë hash me--
Çelësat duhet të ketë barazi.

1016
00:43:35,210 --> 00:43:39,490
Kur unë të query një hash, unë duhet të them
më jepni një hash që është e barabartë kjo.

1017
00:43:39,490 --> 00:43:41,950
Kur unë të query një varg, unë
mund të them më jepni një gamë të

1018
00:43:41,950 --> 00:43:47,040
se është duke përdorur çdo lloj
Operatori i pasur se ne e mbështesim.

1019
00:43:47,040 --> 00:43:49,200
Më jep të gjitha sendet për një hash.

1020
00:43:49,200 --> 00:43:52,520
A është i barabartë, më e madhe se,
më pak se, e bën atë të filluar me të,

1021
00:43:52,520 --> 00:43:54,145
a ekziston në mes të këtyre dy vlerave?

1022
00:43:54,145 --> 00:43:56,811
Pra, këto lloje të pyetjeve varg
se ne jemi gjithmonë të interesuar në.

1023
00:43:56,811 --> 00:43:59,650
Tani një gjë në lidhje me të dhëna, kur
ju shikoni në qasjen e të dhënave, kur

1024
00:43:59,650 --> 00:44:02,360
ju qasje në të dhënat, është e
gjithmonë rreth një grumbullimi.

1025
00:44:02,360 --> 00:44:05,770
Është gjithmonë lidhje me të dhënat
që janë të lidhura me këtë.

1026
00:44:05,770 --> 00:44:10,390
Më jep gjithçka këtu that's-- gjithë
transaksionet në këtë karte krediti

1027
00:44:10,390 --> 00:44:12,500
për muajin e kaluar.

1028
00:44:12,500 --> 00:44:13,960
Kjo është një grumbullimi.

1029
00:44:13,960 --> 00:44:17,490
>> Pothuajse çdo gjë që ju bëni në
bazës së të dhënave është një lloj i grumbullimit.

1030
00:44:17,490 --> 00:44:21,530
Pra, duke qenë në gjendje të jetë në gjendje për të përcaktuar
këto kova dhe ju jap këto gamë

1031
00:44:21,530 --> 00:44:24,950
atributet të jetë në gjendje për të query mbi,
këto pyetje pasur mbështetjen e shumë,

1032
00:44:24,950 --> 00:44:27,165
shumë, shumë modele qasje aplikimit.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Pra, tjetër gjë çelësi hash
nuk është ajo na jep një mekanizëm

1035
00:44:35,000 --> 00:44:37,740
të jetë në gjendje për të përhapur të dhëna rreth.

1036
00:44:37,740 --> 00:44:40,390
Bazat e të dhënave NoSQL të punojnë më mirë
kur të dhënave është në mënyrë të barabartë

1037
00:44:40,390 --> 00:44:41,740
të shpërndara në të gjithë grup.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Sa njerëz janë të njohur
me hashing algoritme?

1040
00:44:47,050 --> 00:44:49,860
Kur them hash dhe një hashing--
sepse një algoritmi hashing

1041
00:44:49,860 --> 00:44:54,140
është një mënyrë për të qenë në gjendje të gjenerojnë
një vlerë të rastit nga ndonjë vlerë të caktuar.

1042
00:44:54,140 --> 00:44:59,300
Pra, në këtë rast të veçantë,
hash algorithm kemi drejtuar është ND 5 i bazuar.

1043
00:44:59,300 --> 00:45:04,765
>> Dhe në qoftë se unë kam një ID, dhe kjo
është çelësi im hash, unë kam 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Kur kam drejtuar hash algorithm,
ajo do të kthehen dhe do të thonë:

1045
00:45:07,390 --> 00:45:10,800
edhe 1 barabartë 7B, 2
është e barabartë me 48, 3 e barabartë me CD.

1046
00:45:10,800 --> 00:45:13,092
Ata janë përhapur në të gjithë hapësirën kryesore.

1047
00:45:13,092 --> 00:45:14,050
Dhe pse do të bëni këtë?

1048
00:45:14,050 --> 00:45:17,120
Sepse kjo e bën të sigurt që unë mund të
vënë të dhënat në të gjithë nyje të shumta.

1049
00:45:17,120 --> 00:45:19,574
>> Në qoftë se unë jam duke bërë këtë
incrementally, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Dhe unë kam një gamë hash që
shkon në këtë rast të veçantë,

1051
00:45:21,990 --> 00:45:24,785
një hapësirë ​​të vogël hash,
ajo shkon nga 00 deri FF,

1052
00:45:24,785 --> 00:45:27,951
atëherë të dhënat do të vijë në
dhe ata do të shkojnë 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
Cfare ndodh?

1055
00:45:31,800 --> 00:45:34,860
Çdo insert është duke shkuar në të njëjtën nyje.

1056
00:45:34,860 --> 00:45:36,070
Ju shihni se çfarë dua të them?

1057
00:45:36,070 --> 00:45:40,910
>> Sepse kur kam ndarë hapësirë,
dhe unë u përhap në të gjithë këtyre të dhënave,

1058
00:45:40,910 --> 00:45:45,950
dhe unë ndarje, unë jam duke shkuar për të thënë
ndarje 1 ka hapësirë ​​kyç 0 në 54.

1059
00:45:45,950 --> 00:45:47,720
Ndarja 2 është 55 deri 89.

1060
00:45:47,720 --> 00:45:49,780
Ndarja 3 është AA për FF.

1061
00:45:49,780 --> 00:45:53,740
Pra, nëse unë jam duke përdorur linear bën rritjen
ID, ju mund të shihni se çfarë po ndodh.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, të gjithë mënyrë deri ne 54.

1063
00:45:57,410 --> 00:46:00,030
Pra, si unë jam me çekan
të dhënat në sistem,

1064
00:46:00,030 --> 00:46:02,030
gjithçka përfundon duke shkuar për një nyje.

1065
00:46:02,030 --> 00:46:03,160
>> Kjo nuk është e mirë.

1066
00:46:03,160 --> 00:46:04,820
Kjo është një antipattern.

1067
00:46:04,820 --> 00:46:08,760
Në MongoDB ata kanë këtë problem
në qoftë se ju nuk e përdorni një çelës hash.

1068
00:46:08,760 --> 00:46:11,325
MongoDB ju jep mundësi
i hashing vlerën kyç.

1069
00:46:11,325 --> 00:46:13,950
Ju gjithmonë duhet të bëni që, në qoftë se
ju jeni duke përdorur një hash bën rritjen

1070
00:46:13,950 --> 00:46:17,380
kyç në MongoDB, ose ju do të jetë
ngulje çdo shkruani në një nyje,

1071
00:46:17,380 --> 00:46:21,290
dhe ju do të jetë i kufizuar
Shkruaj xhiros tuaj keq.

1072
00:46:21,290 --> 00:46:24,896
>> Audienca: A është kjo A9 169 në decimal?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Po, kjo është
diku rreth atje.

1074
00:46:28,450 --> 00:46:29,950
A9, unë nuk e di.

1075
00:46:29,950 --> 00:46:32,200
Ju do të keni për të marrë binar mia
në kalkulator dhjetore.

1076
00:46:32,200 --> 00:46:34,237
Truri im nuk punon si kjo.

1077
00:46:34,237 --> 00:46:36,320
Audienca: Vetëm një njeri i shpejtë
e Mongo komentet tuaja.

1078
00:46:36,320 --> 00:46:39,530
Pra, është ID objekt që vjen
vetvetiu me Mongo bëjë këtë?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: A do të bëjë këtë?

1081
00:46:41,470 --> 00:46:42,970
Nëse ju specifikoni atë.

1082
00:46:42,970 --> 00:46:45,030
Me MongoDB, ju keni mundësi.

1083
00:46:45,030 --> 00:46:48,930
Ju mund të specify-- çdo dokument në
MongoDB duhet të ketë një ID nënvizë.

1084
00:46:48,930 --> 00:46:50,300
Kjo është vlera unike.

1085
00:46:50,300 --> 00:46:55,240
>> Në MongoDB ju mund të specifikoni
nëse do të hash atë apo jo.

1086
00:46:55,240 --> 00:46:56,490
Ata vetëm të ju jap mundësi.

1087
00:46:56,490 --> 00:46:58,198
Nëse ju e dini se kjo është
rastit, nuk ka problem.

1088
00:46:58,198 --> 00:46:59,640
Ju nuk keni nevojë për të bërë këtë.

1089
00:46:59,640 --> 00:47:04,260
Nëse ju e dini se kjo nuk është e rastit, që
ajo bën rritjen, pastaj të bëjë hash.

1090
00:47:04,260 --> 00:47:06,880
>> Tani gjë rreth
hashing, sapo ju të hash

1091
00:47:06,880 --> 00:47:08,800
një value-- dhe kjo është
pse çelësat hash janë gjithmonë

1092
00:47:08,800 --> 00:47:13,740
pyetje unike, sepse unë kam ndryshuar
vlera, tani unë nuk mund të bëj një pyetje varg.

1093
00:47:13,740 --> 00:47:15,640
Unë nuk mund të them është kjo
në mes këtë apo atë,

1094
00:47:15,640 --> 00:47:20,800
sepse vlera hash nuk është duke shkuar
të jenë të barabartë me vlerën aktuale.

1095
00:47:20,800 --> 00:47:24,570
Pra, kur ju të hash se
kyç, kjo është vetëm barazia.

1096
00:47:24,570 --> 00:47:28,700
Kjo është arsyeja pse në DynamoDB hash kyçe
pyetje janë gjithmonë barazia vetëm.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Deri tani në një gamë të key--
kur unë shtoj se varg kyç,

1099
00:47:34,700 --> 00:47:38,180
këto të dhënat kryesore varg të gjithë të vijnë në dhe
ata marrin ruajtur në të njëjtën ndarje.

1100
00:47:38,180 --> 00:47:42,430
Pra, ata janë shumë të shpejt, lehtë
marrë sepse kjo është hash,

1101
00:47:42,430 --> 00:47:43,220
kjo është varg.

1102
00:47:43,220 --> 00:47:44,928
Dhe ju shihni gjithçka
me të njëjtin hash

1103
00:47:44,928 --> 00:47:48,550
merr ruajtur në të njëjtën hapësirë ​​ndarje.

1104
00:47:48,550 --> 00:47:53,889
Ju mund të përdorni atë varg kyç për të ndihmuar
gjetur të dhënat tuaja të afërt me prindërit e saj.

1105
00:47:53,889 --> 00:47:55,180
Pra, çfarë jam unë me të vërtetë duke bërë këtu?

1106
00:47:55,180 --> 00:47:57,320
Kjo është një e për marrëdhënie shumë.

1107
00:47:57,320 --> 00:48:01,490
Marrëdhënia ndërmjet një çelës hash
dhe çelësi varg është një shumë për të.

1108
00:48:01,490 --> 00:48:03,490
Unë mund të ketë çelësat shumta hash.

1109
00:48:03,490 --> 00:48:07,610
Unë mund të ketë vetëm gamë të shumta
çelësat brenda çdo çelës hash.

1110
00:48:07,610 --> 00:48:11,910
>> Hash përcakton prind,
varg definon fëmijët.

1111
00:48:11,910 --> 00:48:15,240
Kështu që ju mund të shihni se ka analog këtu
midis ndërtimin relacionale

1112
00:48:15,240 --> 00:48:18,840
dhe njëjtat lloje të
ndërton në NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Njerëzit flasin për
NoSQL si nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Kjo nuk është nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Të dhënat gjithmonë ka marrëdhënie.

1116
00:48:24,680 --> 00:48:28,172
Këto marrëdhënie vetëm
janë modeluar ndryshe.

1117
00:48:28,172 --> 00:48:29,880
Le të flasim pak
bit për qëndrueshmëri.

1118
00:48:29,880 --> 00:48:34,860
Kur ju shkruani për të DynamoDB, shkruan
janë gjithmonë tre-palësh përsëriten.

1119
00:48:34,860 --> 00:48:37,550
Që do të thotë se ne kemi tre AZ-së.

1120
00:48:37,550 --> 00:48:39,160
AZ-së janë Zonat Disponueshmëria.

1121
00:48:39,160 --> 00:48:43,430
Ju mund të mendoj për një Disponueshmëria
Zona si një qendër të dhënave

1122
00:48:43,430 --> 00:48:45,447
ose një koleksion i qendrave të të dhënave.

1123
00:48:45,447 --> 00:48:47,780
Këto gjëra janë gjeografikisht
izoluar nga njëri-tjetri

1124
00:48:47,780 --> 00:48:51,610
nëpër zona të ndryshme faj, të gjithë
rrjetet e energjisë dhe floodplains ndryshme.

1125
00:48:51,610 --> 00:48:54,510
Një dështim në një AZ nuk është
do të marrë poshtë një tjetër.

1126
00:48:54,510 --> 00:48:56,890
Ato janë të lidhura edhe
së bashku me fibër të errët.

1127
00:48:56,890 --> 00:49:01,240
Ajo mbështet një nën 1
latente milisekonda mes të AZS.

1128
00:49:01,240 --> 00:49:05,390
Kështu që të dhënat në kohë reale replications
aftë në AZS multi.

1129
00:49:05,390 --> 00:49:09,990
>> Dhe shumë herë multi dislokimet AZ
përmbushur kërkesat e Lartë Disponueshmëria

1130
00:49:09,990 --> 00:49:12,930
e organizatave më të madhe të ndërmarrjeve.

1131
00:49:12,930 --> 00:49:16,139
Pra, DynamoDB është e përhapur
nëpër tri AZS by default.

1132
00:49:16,139 --> 00:49:19,430
Ne jemi vetëm duke shkuar për të njohurive shkruaj
kur dy prej këtyre tre nyje kthehen

1133
00:49:19,430 --> 00:49:21,470
dhe thonë: Po, kam marrë atë.

1134
00:49:21,470 --> 00:49:22,050
Pse eshte ajo?

1135
00:49:22,050 --> 00:49:25,950
Sepse në anën read ne jemi vetëm
do të ju japin të dhënat e mbrapa kur

1136
00:49:25,950 --> 00:49:27,570
ne të merrni atë nga dy nyjeve.

1137
00:49:27,570 --> 00:49:30,490
>> Në qoftë se unë jam duke përsëritur të gjithë
tre, dhe unë jam duke lexuar nga dy,

1138
00:49:30,490 --> 00:49:32,840
Unë jam gjithmonë i garantuar
të ketë së paku një

1139
00:49:32,840 --> 00:49:35,720
e atyre që lexon të jetë
Kopja më aktuale e të dhënave.

1140
00:49:35,720 --> 00:49:38,340
Kjo është ajo që e bën DynamoDB qëndrueshme.

1141
00:49:38,340 --> 00:49:42,450
Tani ju mund të zgjidhni për të kthyer
ato në përputhje lexon off.

1142
00:49:42,450 --> 00:49:45,070
Në të cilin rast unë jam duke shkuar për të thënë,
Unë do të lexoni vetëm nga një nyje.

1143
00:49:45,070 --> 00:49:47,430
Dhe unë nuk mund të garantojë se do
të jenë të dhënat më aktuale.

1144
00:49:47,430 --> 00:49:49,450
>> Pra, nëse një shkruani po vjen në,
ajo nuk ka përsëriten ende,

1145
00:49:49,450 --> 00:49:50,360
ju jeni do të merrni atë kopje.

1146
00:49:50,360 --> 00:49:52,220
Kjo është një lexuar përfundimisht në përputhje.

1147
00:49:52,220 --> 00:49:54,640
Dhe çfarë është kjo është gjysma e kostos.

1148
00:49:54,640 --> 00:49:56,140
Pra, kjo është diçka për të menduar.

1149
00:49:56,140 --> 00:50:00,160
Kur ju jeni duke lexuar jashtë DynamoDB, dhe
ju jeni ngritjen e kapaciteteve të lexuar

1150
00:50:00,160 --> 00:50:04,430
Njësitë, në qoftë se ju zgjidhni përfundimisht
në përputhje lexon, kjo është një shumë më të lirë,

1151
00:50:04,430 --> 00:50:06,010
është rreth gjysma e kostos.

1152
00:50:06,010 --> 00:50:09,342
>> Dhe kështu që ajo ju kursen para.

1153
00:50:09,342 --> 00:50:10,300
Por kjo është zgjedhja juaj.

1154
00:50:10,300 --> 00:50:12,925
Nëse doni një lexuar qëndrueshme ose
një lexuar përfundimisht në përputhje.

1155
00:50:12,925 --> 00:50:15,720
Kjo është diçka që ju mund të zgjidhni.

1156
00:50:15,720 --> 00:50:17,659
>> Le të flasim për indekseve.

1157
00:50:17,659 --> 00:50:19,450
Pra, kemi përmendur se
grumbullimi nivelit të lartë.

1158
00:50:19,450 --> 00:50:23,720
Ne kemi marrë çelësat hash, dhe
ne kemi marrë çelësat varg.

1159
00:50:23,720 --> 00:50:24,320
Kjo është e bukur.

1160
00:50:24,320 --> 00:50:26,950
Dhe kjo është në tryezë primar, unë
mori një kyç hash, kam marrë një kyç varg.

1161
00:50:26,950 --> 00:50:27,783
>> Cfare do te thote ajo?

1162
00:50:27,783 --> 00:50:30,410
Unë kam marrë një atribut që unë
mund të kandidojë pyetje pasur kundër.

1163
00:50:30,410 --> 00:50:31,800
Është çelësi varg.

1164
00:50:31,800 --> 00:50:35,530
Atributet e tjera në atë item--
Unë mund të filtruar në ato atribute.

1165
00:50:35,530 --> 00:50:40,050
Por unë nuk mund të bëjë gjëra të tilla si, atë
fillon me, ose është më i madh se.

1166
00:50:40,050 --> 00:50:40,820
>> Si ta bëj këtë?

1167
00:50:40,820 --> 00:50:42,860
Kam krijuar një indeks.

1168
00:50:42,860 --> 00:50:45,340
Ka dy lloje të
Indekset në DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Një indeks është me të vërtetë
një tjetër pamje e tabelës.

1170
00:50:49,002 --> 00:50:50,490
Dhe indeksi i mesëm lokale.

1171
00:50:50,490 --> 00:50:51,781
>> I pari ne do të flasim për.

1172
00:50:51,781 --> 00:50:57,740
Pra dytësore e lokale janë të bashkëjetuar
në të njëjtën ndarje si të dhënave.

1173
00:50:57,740 --> 00:51:00,240
Dhe si të tilla, ato janë në
e njëjta nyje fizike.

1174
00:51:00,240 --> 00:51:01,780
Ata janë ato që ne e quajmë në përputhje.

1175
00:51:01,780 --> 00:51:04,599
Kuptimi, ata do të pranojnë
shkruaj së bashku me tryezë.

1176
00:51:04,599 --> 00:51:06,890
Kur shkruani vjen në,
ne do të shkruaj me anë të indeksit.

1177
00:51:06,890 --> 00:51:09,306
Ne do të shkruaj deri në tryezë,
dhe pastaj ne do të pranojmë.

1178
00:51:09,306 --> 00:51:10,490
Pra, kjo është në përputhje.

1179
00:51:10,490 --> 00:51:13,174
Pasi shkruaj ka qenë
pranuar nga tabela,

1180
00:51:13,174 --> 00:51:15,090
është e garantuar që
Indeksi i mesëm lokale

1181
00:51:15,090 --> 00:51:18,380
do të kenë të njëjtin vizion të të dhënave.

1182
00:51:18,380 --> 00:51:22,390
Por ajo që ata ju lejojnë të bëni është
përcaktojë çelësat varg alternative.

1183
00:51:22,390 --> 00:51:25,260
>> Duhet të përdorin të njëjtin hash
kyç si tryezë primar,

1184
00:51:25,260 --> 00:51:29,050
për shkak se ata janë të bashkë-të vendosura në
njëjta ndarje, dhe ata janë të qëndrueshme.

1185
00:51:29,050 --> 00:51:33,110
Por unë mund të krijojë një indeks
me çelësat e ndryshme varg.

1186
00:51:33,110 --> 00:51:41,590
Kështu për shembull, në qoftë se kam pasur një prodhues
që kishte një pjesë tavolinë papërpunuara vijnë.

1187
00:51:41,590 --> 00:51:44,590
Dhe pjesë e papërpunuara të vijnë në, dhe
ata janë të grumbulluara nga kuvendi.

1188
00:51:44,590 --> 00:51:46,840
Dhe ndoshta ka një kujtojnë.

1189
00:51:46,840 --> 00:51:50,240
>> Çdo pjesë që është bërë nga kjo
prodhues pas kësaj date,

1190
00:51:50,240 --> 00:51:52,840
Unë kam nevojë për të tërhequr nga linjë tim.

1191
00:51:52,840 --> 00:51:55,950
Unë mund të tjerr një indeks
që do të jetë në kërkim,

1192
00:51:55,950 --> 00:52:00,760
përmbledhë në datën e
prodhimin e asaj pjese të veçantë.

1193
00:52:00,760 --> 00:52:03,930
Pra, nëse tryezën time të nivelit të lartë ishte
tashmë sheshuar nga prodhuesi,

1194
00:52:03,930 --> 00:52:07,655
ndoshta ajo ishte e rregulluar në pjesë ID, unë
mund të krijojë një indeks off atë tavolinë

1195
00:52:07,655 --> 00:52:11,140
si sheshuar nga prodhuesi dhe
shkonin në datën e prodhimit.

1196
00:52:11,140 --> 00:52:14,490
Dhe në këtë mënyrë unë mund të them, çdo gjë që
ishte prodhuar në mes të këtyre datave,

1197
00:52:14,490 --> 00:52:16,804
Unë kam nevojë për të tërhequr nga vija.

1198
00:52:16,804 --> 00:52:18,220
Pra, kjo është një indeks mesme lokale.

1199
00:52:18,220 --> 00:52:22,280
>> Këto kanë efektin e
kufizimin hash hapësirën tuaj kryesor.

1200
00:52:22,280 --> 00:52:24,360
Për shkak se ata bashkë-ekzistuar
në të njëjtën nyjen e magazinimit,

1201
00:52:24,360 --> 00:52:26,860
ata kufizojnë çelësin hash
hapësirë ​​në 10 gigabajt.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, nën
tavolina, do ndarje

1203
00:52:28,950 --> 00:52:31,380
tavolina juaj çdo 10 gigabajt.

1204
00:52:31,380 --> 00:52:34,760
Kur ju vënë 10 koncerte e të dhënave në, ne
shkoni [PHH], dhe ne të shtoni një tjetër nyje.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Ne nuk do të ndahet me LSI
nëpër ndarëse të shumta.

1207
00:52:42,070 --> 00:52:43,200
Ne do të ndahet në tryezë.

1208
00:52:43,200 --> 00:52:44,679
Por ne nuk do të ndahet LSI.

1209
00:52:44,679 --> 00:52:46,470
Pra, kjo është diçka
e rëndësishme për të kuptuar

1210
00:52:46,470 --> 00:52:50,070
është në qoftë se ju jeni duke bërë shumë,
shumë, grumbullimit shumë të mëdha,

1211
00:52:50,070 --> 00:52:53,860
atëherë ju jeni do të jetë i kufizuar
10 gigabajt në LSIs tuaj.

1212
00:52:53,860 --> 00:52:56,640
>> Në qoftë se është rasti, ne mund
përdorni secondaries globale.

1213
00:52:56,640 --> 00:52:58,630
Dytësore e globale janë
me të vërtetë një tjetër tryezë.

1214
00:52:58,630 --> 00:53:01,720
Ato ekzistojnë plotësisht jashtë për
anën e tryezën tuaj primar.

1215
00:53:01,720 --> 00:53:04,680
Dhe ata më lejoni të gjetur një
Struktura krejtësisht të ndryshme.

1216
00:53:04,680 --> 00:53:08,010
Pra, mendoni për atë si të dhënave është duke u futur
në dy tavolina të ndryshme, të strukturuara

1217
00:53:08,010 --> 00:53:09,220
në dy mënyra të ndryshme.

1218
00:53:09,220 --> 00:53:11,360
>> Unë mund të përcaktojë një krejtësisht të
Çelësi i ndryshëm hash.

1219
00:53:11,360 --> 00:53:13,490
Unë mund të përcaktojë një krejtësisht të
Çelësi varg të ndryshme.

1220
00:53:13,490 --> 00:53:15,941
Dhe unë mund të kandidojë këtë
plotësisht të pavarur.

1221
00:53:15,941 --> 00:53:18,190
Si një çështje të vërtetë, unë kam
parashikuar kapacitetin tim lexuar

1222
00:53:18,190 --> 00:53:21,090
dhe shkruaj e kapaciteteve për tim
indekseve global të mesëm

1223
00:53:21,090 --> 00:53:24,240
plotësisht në mënyrë të pavarur
e tryezën time primar.

1224
00:53:24,240 --> 00:53:26,640
Nëse unë të përcaktojë se indeksi, unë them
ajo se sa lexojnë dhe shkruajnë

1225
00:53:26,640 --> 00:53:28,610
Kapaciteti ajo do të jetë duke përdorur.

1226
00:53:28,610 --> 00:53:31,490
>> Dhe kjo është e ndarë
nga tryezën time primar.

1227
00:53:31,490 --> 00:53:35,240
Tani të dy indekseve të na lejojë të
jo vetëm të përcaktojë hash dhe varg çelësat,

1228
00:53:35,240 --> 00:53:38,610
por ata na lejojnë të
projektojnë vlera shtesë.

1229
00:53:38,610 --> 00:53:44,950
Pra, nëse unë dua të lexoj nga indeksi,
dhe unë dua të të marrë disa grup të dhënash,

1230
00:53:44,950 --> 00:53:48,327
Unë nuk kam nevojë për të shkuar përsëri në kryesore
tryezë të marrë atributet shtesë.

1231
00:53:48,327 --> 00:53:50,660
Unë mund të projektit ato shtesë
atributet në tryezë

1232
00:53:50,660 --> 00:53:53,440
për të mbështetur modelin qasje.

1233
00:53:53,440 --> 00:53:57,700
Unë e di se ne jemi ndoshta duke marrë në disa
me të vërtetë, really-- hyrë në barërat e këqija

1234
00:53:57,700 --> 00:53:58,910
këtu në disa të kësaj stuff.

1235
00:53:58,910 --> 00:54:02,725
Tani unë kam për të domethënie nga kjo.

1236
00:54:02,725 --> 00:54:07,320
>> Audienca: [padëgjueshme]
Çelësi --table do të thoshte ishte një hash?

1237
00:54:07,320 --> 00:54:08,840
Hash origjinal?

1238
00:54:08,840 --> 00:54:09,340
Multi-slats?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Po.

1240
00:54:10,200 --> 00:54:11,070
Po.

1241
00:54:11,070 --> 00:54:15,260
Tabela Çelësi thelb
vë përsëri në artikull.

1242
00:54:15,260 --> 00:54:19,280
Pra, një indeks është një tregues prapa në
sendet origjinale në tryezë.

1243
00:54:19,280 --> 00:54:22,910
Tani ju mund të zgjidhni për të ndërtuar një
Indeksi që ka vetëm tryezë kyç,

1244
00:54:22,910 --> 00:54:24,840
dhe ka prona të tjera.

1245
00:54:24,840 --> 00:54:26,570
Dhe pse mund ta bëj këtë?

1246
00:54:26,570 --> 00:54:28,570
Epo, ndoshta unë kam objekte shumë të mëdha.

1247
00:54:28,570 --> 00:54:31,660
>> Unë me të vërtetë vetëm duhet të dini which--
model im qasje mund të thonë,

1248
00:54:31,660 --> 00:54:33,760
sende të cilat përmbajnë këtë pronë?

1249
00:54:33,760 --> 00:54:35,780
Mos duhet të kthehen pika.

1250
00:54:35,780 --> 00:54:37,800
Unë vetëm duhet të dini
sende të cilat përmbajnë atë.

1251
00:54:37,800 --> 00:54:40,700
Kështu që ju mund të ndërtojë indekseve
se vetëm kanë tryezë çelësin.

1252
00:54:40,700 --> 00:54:43,360
>> Por kjo është kryesisht ajo që
një indeks në bazën e të dhënave është për.

1253
00:54:43,360 --> 00:54:46,280
Është për të qenë në gjendje të shpejt
të identifikuar të cilat të dhënat,

1254
00:54:46,280 --> 00:54:49,470
të cilat rreshtave, të cilat
artikuj në tryezë kanë

1255
00:54:49,470 --> 00:54:51,080
pronat që unë jam në kërkim për.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIs, kështu që si mund ata punojnë?

1258
00:54:54,860 --> 00:54:58,340
GSIs thelb janë asinkron.

1259
00:54:58,340 --> 00:55:02,570
Përditësimi vjen në tryezë,
Tabela është pastaj përditësuar asynchronously

1260
00:55:02,570 --> 00:55:03,720
të gjithë GSIs tuaj.

1261
00:55:03,720 --> 00:55:06,680
Kjo është arsyeja pse GSIs janë
përfundimisht në përputhje.

1262
00:55:06,680 --> 00:55:09,440
>> Është e rëndësishme të theksohet se
kur ju jeni ndërtimin GSIs,

1263
00:55:09,440 --> 00:55:13,110
dhe ju e kuptoni se ju jeni duke krijuar
një tjetër dimension i aggregation--

1264
00:55:13,110 --> 00:55:16,594
tani le të thonë se një shembull të mirë
këtu është një prodhues.

1265
00:55:16,594 --> 00:55:19,260
Unë mendoj se unë mund të ketë biseduar rreth
një prodhues mjekësore pajisje.

1266
00:55:19,260 --> 00:55:23,870
Prodhuesit pajisje mjekësore
shpesh kanë pjesë serialized.

1267
00:55:23,870 --> 00:55:28,070
Pjesët që shkojnë në
një zëvendësim hip gjithë

1268
00:55:28,070 --> 00:55:30,200
të ketë një numër serik të vogël mbi to.

1269
00:55:30,200 --> 00:55:33,584
Dhe ata mund të kenë miliona dhe
miliona dhe miliarda pjesëve

1270
00:55:33,584 --> 00:55:35,000
në të gjitha pajisjet që ato anije.

1271
00:55:35,000 --> 00:55:37,440
E pra, ata duhet të mbledhë nën
dimensione të ndryshme, të gjitha pjesët

1272
00:55:37,440 --> 00:55:39,520
në një asamble, të gjithë
Pjesët që janë bërë

1273
00:55:39,520 --> 00:55:41,670
në një linjë të caktuar, të gjithë
pjesët që kanë ardhur

1274
00:55:41,670 --> 00:55:44,620
në nga një prodhues të caktuar
në një datë të caktuar.

1275
00:55:44,620 --> 00:55:47,940
Dhe këto aggregations ndonjëherë
merrni deri në miliarda.

1276
00:55:47,940 --> 00:55:50,550
>> Kështu që unë punoj me disa prej
këta njerëz të cilët janë duke vuajtur

1277
00:55:50,550 --> 00:55:53,156
sepse ata janë krijuar
këto aggregations ginormous

1278
00:55:53,156 --> 00:55:54,280
në indekset e tyre të mesme.

1279
00:55:54,280 --> 00:55:57,070
Ata mund të kenë një pjesë të papërpunuara
tabela që vjen vetëm si hash.

1280
00:55:57,070 --> 00:55:59,090
Çdo pjesë ka një numër serik unik.

1281
00:55:59,090 --> 00:56:00,975
I use numrin serik si hash.

1282
00:56:00,975 --> 00:56:01,600
Eshte e bukur.

1283
00:56:01,600 --> 00:56:04,160
Tryezën time papërpunuara të dhënave është e përhapur
gjitha në të gjithë hapësirën kryesore.

1284
00:56:04,160 --> 00:56:05,930
[E mia? shkruaj?]
[? gëlltitje?] është awesome.

1285
00:56:05,930 --> 00:56:07,876
Kam marrë një shumë të të dhënave.

1286
00:56:07,876 --> 00:56:09,500
Atëherë çfarë ata bëjnë është se ata të krijojnë një GSI.

1287
00:56:09,500 --> 00:56:12,666
Dhe unë them, ju e dini se çfarë, unë duhet të shoh
të gjitha pjesët për këtë prodhuesi.

1288
00:56:12,666 --> 00:56:15,060
E pra, të gjithë një e papritur unë jam
Duke marrë një miliard rreshtave,

1289
00:56:15,060 --> 00:56:17,550
dhe sende tyre mbi
një nyje, sepse kur

1290
00:56:17,550 --> 00:56:21,170
Unë agregate si
ID prodhues si hash,

1291
00:56:21,170 --> 00:56:25,410
dhe numri pjesë si varg,
pastaj të gjithë e papritur unë jam

1292
00:56:25,410 --> 00:56:30,530
vënë një miliard pjesë në çfarë
ky prodhues ka më shpëtoi.

1293
00:56:30,530 --> 00:56:34,447
>> Kjo mund të shkaktojë shumë
e presionit mbi GSI,

1294
00:56:34,447 --> 00:56:36,030
përsëri, sepse unë jam goditje me çekan një nyje.

1295
00:56:36,030 --> 00:56:38,350
Unë jam vënë të gjitha këto
fut në një nyje.

1296
00:56:38,350 --> 00:56:40,940
Dhe kjo është një rast i vërtetë problematik përdorimi.

1297
00:56:40,940 --> 00:56:43,479
Tani, unë kam një dizajn të mirë
model për mënyrën se si ju shmangur atë.

1298
00:56:43,479 --> 00:56:45,770
Dhe kjo është një nga problemet
që unë gjithmonë punojnë me.

1299
00:56:45,770 --> 00:56:49,590
Por çfarë ndodh, është GSI mund të
nuk kanë kapacitet të mjaftueshëm shkruar

1300
00:56:49,590 --> 00:56:52,330
të jetë në gjendje për të nxitur të gjithë ata
rreshtave në një nyje të vetme.

1301
00:56:52,330 --> 00:56:55,390
Dhe çfarë ndodh atëherë është
primar, tabela klienti,

1302
00:56:55,390 --> 00:57:00,180
tabela primar do të jetë mbytur
sepse GSI nuk mund të mbaj lart.

1303
00:57:00,180 --> 00:57:02,980
Pra, insert kursi im do të
bien në tryezë primar

1304
00:57:02,980 --> 00:57:06,230
si GSI im përpiqet për të mbajtur lart.

1305
00:57:06,230 --> 00:57:08,850
>> Të gjithë të drejtë, kështu GSI-së, LSI-së,
të cilat duhet të përdor?

1306
00:57:08,850 --> 00:57:12,290
LSI-së janë në përputhje.

1307
00:57:12,290 --> 00:57:13,750
GSI-së janë përfundimisht të qëndrueshme.

1308
00:57:13,750 --> 00:57:17,490
Në qoftë se kjo është në rregull, unë rekomandoj duke përdorur një
GSI, ata janë shumë më elastike.

1309
00:57:17,490 --> 00:57:20,270
LSI-së mund të jetë modeluar si një GSI.

1310
00:57:20,270 --> 00:57:27,040
Dhe në qoftë se madhësia e të dhënave për çelësat hash në
koleksionin tuaj kalon 10 gigabajt,

1311
00:57:27,040 --> 00:57:31,050
atëherë ju jeni do të dëshironi të përdorni atë
GSI sepse kjo është vetëm një kufi i vështirë.

1312
00:57:31,050 --> 00:57:32,035
>> Të gjithë të drejtë, kështu shkallë.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Xhiroja në Dinamo DB, ju
dispozitë mund të [padëgjueshme]

1315
00:57:37,460 --> 00:57:38,680
xhiros në një tryezë.

1316
00:57:38,680 --> 00:57:42,740
Ne kemi klientët që kanë
provizionuar 60 billion--

1317
00:57:42,740 --> 00:57:45,970
janë duke bërë 60 miliardë kërkesa, rregullisht
drejtimin në mbi një milion kërkesa

1318
00:57:45,970 --> 00:57:47,790
për sekondë në tryezat tona.

1319
00:57:47,790 --> 00:57:50,360
Ka të vërtetë nuk
Kufiri teorik për sa

1320
00:57:50,360 --> 00:57:53,730
dhe sa shpejt tabela
mund të kandidojë në Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Ka disa të buta
kufizime në llogarinë tuaj

1322
00:57:55,920 --> 00:57:58,170
që ne kemi vënë në atje kështu
që ju nuk shkoni çmendur.

1323
00:57:58,170 --> 00:58:00,070
Në qoftë se ju doni më shumë se
se, nuk është një problem.

1324
00:58:00,070 --> 00:58:00,820
Ju vijnë na tregoni.

1325
00:58:00,820 --> 00:58:02,810
Ne do të kthehet deri dial.

1326
00:58:02,810 --> 00:58:08,210
>> Çdo llogari është e kufizuar në një nivel
në çdo shërbim, vetëm të fjalës

1327
00:58:08,210 --> 00:58:11,920
kështu që njerëzit nuk shkojnë çmendur
merrni veten në telashe.

1328
00:58:11,920 --> 00:58:12,840
Nuk ka limit në madhësi.

1329
00:58:12,840 --> 00:58:14,940
Ju mund të vënë ndonjë numër
e artikujve në një tryezë.

1330
00:58:14,940 --> 00:58:17,620
Madhësia e një elementi është
kufizuar në 400 kilobytes secili,

1331
00:58:17,620 --> 00:58:20,050
që do të jetë jo pika atributet.

1332
00:58:20,050 --> 00:58:24,200
Pra, shuma e të gjitha atributeve
është e kufizuar në 400 kilobytes.

1333
00:58:24,200 --> 00:58:27,300
Dhe pastaj përsëri, ne kemi
se pak çështje LSI

1334
00:58:27,300 --> 00:58:30,405
me limitin 10 Gigabyte per hash.

1335
00:58:30,405 --> 00:58:33,280
Audienca: Numri i vogël, unë jam i humbur
atë që ju po më thoni mua, që is--

1336
00:58:33,280 --> 00:58:36,830
Audienca: Oh, 400 kilobyte
është madhësia maksimale për artikull.

1337
00:58:36,830 --> 00:58:39,570
Pra, një artikull i ka të gjitha atributet.

1338
00:58:39,570 --> 00:58:43,950
Pra, 400 k është madhësia e përgjithshme
e atij sendit, 400 kilobytes.

1339
00:58:43,950 --> 00:58:46,170
Pra, të gjitha atributet
kombinuara, të gjitha të dhënat

1340
00:58:46,170 --> 00:58:49,140
kjo është në të gjitha ato atributet,
mbështjellë deri në një madhësi të plotë,

1341
00:58:49,140 --> 00:58:51,140
aktualisht sot kufiri artikull është 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Pra shkallë përsëri, ka arritur
përmes ndarjes.

1344
00:58:57,046 --> 00:58:58,920
Xhiroja është parashikuar
në nivel tabela.

1345
00:58:58,920 --> 00:59:00,160
Dhe nuk ka të vërtetë dy pullat.

1346
00:59:00,160 --> 00:59:02,400
Ne kemi lexuar kapacitet
dhe shkruaj kapacitetit.

1347
00:59:02,400 --> 00:59:05,530
>> Pra, këto janë të rregulluara
në mënyrë të pavarur nga njëra-tjetra.

1348
00:59:05,530 --> 00:59:08,640
Masa RCU-së në mënyrë rigoroze në përputhje lexon.

1349
00:59:08,640 --> 00:59:13,005
OK, kështu që nëse ju jeni duke thënë se unë dua 1000
RCU-së ata janë rreptësisht të qëndrueshme,

1350
00:59:13,005 --> 00:59:14,130
ato janë në përputhje lexon.

1351
00:59:14,130 --> 00:59:17,130
Në qoftë se ju thonë se unë dua
eventuale në përputhje lexon,

1352
00:59:17,130 --> 00:59:19,402
ju mund të dispozitë 1000
RCU-së, ju do të jeni

1353
00:59:19,402 --> 00:59:21,840
për të marrë 2,000 përfundimisht
në përputhje lexon.

1354
00:59:21,840 --> 00:59:25,940
Dhe gjysma e çmimit për ata
përfundimisht konsistojnë në lexon.

1355
00:59:25,940 --> 00:59:28,520
>> Përsëri, rregulluar
në mënyrë të pavarur nga njëra-tjetra.

1356
00:59:28,520 --> 00:59:32,900
Dhe ata kanë throughput--
Nëse ju konsumoni 100% të RCU tuaj,

1357
00:59:32,900 --> 00:59:35,960
ju nuk do të ndikojë në
Disponueshmëria e të drejtat tuaja.

1358
00:59:35,960 --> 00:59:40,161
Pra, ata janë krejtësisht
të pavarur nga njëri-tjetri.

1359
00:59:40,161 --> 00:59:43,160
Të gjithë të drejtë, kështu që një nga gjërat që
Përmenda shkurtimisht u throttling.

1360
00:59:43,160 --> 00:59:44,320
Throttling është e keqe.

1361
00:59:44,320 --> 00:59:47,311
Throttling tregon keq nuk SQL.

1362
00:59:47,311 --> 00:59:50,310
Ka gjëra që mund të bëjmë për të ndihmuar
ju lehtësuar throttling që ju

1363
00:59:50,310 --> 00:59:51,040
janë duke përjetuar.

1364
00:59:51,040 --> 00:59:53,240
Por zgjidhja më e mirë
për të kjo është le të marrin

1365
00:59:53,240 --> 00:59:58,000
një vështrim në atë që ju jeni duke bërë, sepse
ka një anti-model në lojë këtu.

1366
00:59:58,000 --> 01:00:02,140
>> Këto gjëra, gjëra të tilla si jo-uniforme
Ngarkesat e punës, çelësat e nxehtë, ndarëse nxehtë.

1367
01:00:02,140 --> 01:00:06,210
Unë jam goditur një hapësirë ​​të veçantë kyç
shumë e vështirë për disa arsye të veçantë.

1368
01:00:06,210 --> 01:00:07,080
Pse jam duke e bërë këtë?

1369
01:00:07,080 --> 01:00:08,710
Le të kuptoj se nga.

1370
01:00:08,710 --> 01:00:10,427
Unë jam përzierjen dhënat e mia të nxehta me të dhënat e të ftohtë.

1371
01:00:10,427 --> 01:00:12,510
Unë jam duke i lënë tavolina e mia të marrë
i madh, por nuk ka të vërtetë

1372
01:00:12,510 --> 01:00:15,970
vetëm disa mesin e të dhënave
kjo është me të vërtetë interesante për mua.

1373
01:00:15,970 --> 01:00:20,290
Pra, për të dhënat log, për shembull, një shumë e
konsumatorët, ata marrin log dhënat e çdo ditë.

1374
01:00:20,290 --> 01:00:22,490
Ata morën një sasi të madhe të të dhënave log.

1375
01:00:22,490 --> 01:00:25,940
>> Nëse jeni vetëm hedhja gjithë atë log
të dhëna në një tavolinë të madhe, me kalimin e kohës

1376
01:00:25,940 --> 01:00:28,070
kjo tryezë do të merrni masiv.

1377
01:00:28,070 --> 01:00:30,950
Por unë jam me të vërtetë i interesuar vetëm në
24 orët e fundit, shtatë ditëve të fundit,

1378
01:00:30,950 --> 01:00:31,659
30 ditët e fundit.

1379
01:00:31,659 --> 01:00:34,074
Çfarëdo dritarja e kohës
se unë jam i interesuar në kërkim

1380
01:00:34,074 --> 01:00:37,010
për ngjarjen që pengon mua, ose
Ngjarja që është interesante për mua,

1381
01:00:37,010 --> 01:00:39,540
kjo është e vetmja kohë dritare që kam nevojë.

1382
01:00:39,540 --> 01:00:42,470
Pra, pse jam unë duke vënë 10 vjet
vlerë e të dhënave log në tryezë?

1383
01:00:42,470 --> 01:00:45,030
Çfarë është që shkakton
tabela fragmenti.

1384
01:00:45,030 --> 01:00:45,880
>> Ajo merr e madhe.

1385
01:00:45,880 --> 01:00:48,340
Ajo fillon përhapur nga
nëpër mijëra nyjave.

1386
01:00:48,340 --> 01:00:51,380
Dhe që kapacitetin tuaj
është aq i ulët, ju jeni

1387
01:00:51,380 --> 01:00:54,090
në fakt Vlerësoni kufizuar në çdo
një nga ato nyje individuale.

1388
01:00:54,090 --> 01:00:57,120
Pra, le të fillojmë të shikojmë se si
nuk kemi rrokulliset atë tryezë gjatë.

1389
01:00:57,120 --> 01:01:01,502
Si nuk kemi menaxhuar që të dhënat pak
më mirë për të shmangur këto probleme.

1390
01:01:01,502 --> 01:01:02,710
Dhe çfarë bën që të duken si?

1391
01:01:02,710 --> 01:01:04,370
Kjo është ajo që duket si.

1392
01:01:04,370 --> 01:01:06,790
Kjo është ajo që NoSQL e keqe duket si.

1393
01:01:06,790 --> 01:01:07,830
>> Unë kam një çelës të nxehtë këtu.

1394
01:01:07,830 --> 01:01:10,246
Nëse ju shikoni në anën e këtu,
këto janë të gjitha ndarëse e mia.

1395
01:01:10,246 --> 01:01:12,630
I kam 16 ndarëse këtu
mbi këtë bazë të dhënash të veçantë.

1396
01:01:12,630 --> 01:01:13,630
Ne e bëjmë këtë gjatë gjithë kohës.

1397
01:01:13,630 --> 01:01:15,046
I drejtuar këtë për konsumatorët gjatë gjithë kohës.

1398
01:01:15,046 --> 01:01:16,550
Ajo që quhet hartë ngrohjes.

1399
01:01:16,550 --> 01:01:20,590
Harta ngrohjes tregon mua se si ju jeni
hyrë në hapësirën tuaj kryesor.

1400
01:01:20,590 --> 01:01:23,700
Dhe çfarë kjo është thënë mua është
se ka një hash veçantë

1401
01:01:23,700 --> 01:01:26,330
se ky djalë i pëlqen një
shumë e tmerrshme, sepse ai është

1402
01:01:26,330 --> 01:01:28,250
goditur atë me të vërtetë, të vërtetë e vështirë.

1403
01:01:28,250 --> 01:01:29,260
>> Pra blu është e bukur.

1404
01:01:29,260 --> 01:01:29,900
Ne si blu.

1405
01:01:29,900 --> 01:01:30,720
Ne nuk e pëlqen e kuqe.

1406
01:01:30,720 --> 01:01:33,120
Red ku presioni
merr deri në 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, tani ju do të jeni të mbytur.

1408
01:01:35,560 --> 01:01:39,030
Pra, sa herë që ju shihni ndonjë vijat e kuqe si
this-- dhe kjo nuk është vetëm Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
çdo bazës së të dhënave NoSQL e ka këtë problem.

1410
01:01:41,630 --> 01:01:44,640
Nuk janë anti-modele që mund të
përzënë këto lloje të kushteve.

1411
01:01:44,640 --> 01:01:49,070
Çfarë të bëj është që unë të punojë me klientët
për të lehtësuar këto kushte.

1412
01:01:49,070 --> 01:01:51,840
>> Dhe çfarë bën që të duken si?

1413
01:01:51,840 --> 01:01:54,260
Dhe kjo po bëhet më e
nga Dynamo DB xhiros,

1414
01:01:54,260 --> 01:01:56,176
por kjo është me të vërtetë duke u
maksimumin e NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Kjo nuk është e kufizuar për Dinamo.

1416
01:01:58,740 --> 01:02:02,050
Kjo është që unë definitely--
përdoret për të punuar në Mongo.

1417
01:02:02,050 --> 01:02:04,090
Unë jam njohur me shumë platforma NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Çdo njëri ka këto lloje
e problemeve të nxehtë kryesore.

1419
01:02:06,830 --> 01:02:10,320
Për të marrë maksimumin e çdo NoSQL
bazës së të dhënave, në veçanti Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
ju doni të krijoni tabela
ku elementi kyç hash ka

1421
01:02:13,320 --> 01:02:18,590
një numër i madh i vlerave të dallueshme,
një shkallë të lartë të cardinality.

1422
01:02:18,590 --> 01:02:22,530
Sepse kjo do të thotë që unë jam shkrim
në shumë kova të ndryshme.

1423
01:02:22,530 --> 01:02:24,870
>> Sa më shumë kova Jam
shkrim, më shumë të ngjarë

1424
01:02:24,870 --> 01:02:29,100
Unë jam për të përhapur atë peshë shkruani ose
lexuar ngarkesës në të gjithë nyje të shumta,

1425
01:02:29,100 --> 01:02:33,560
më shumë të ngjarë unë jam që të ketë një
xhiros të lartë në tryezë.

1426
01:02:33,560 --> 01:02:37,440
Dhe atëherë unë dua vlerat të jenë
ka kërkuar në mënyrë të drejtë në mënyrë të barabartë me kalimin e kohës

1427
01:02:37,440 --> 01:02:39,430
dhe të njëtrajtshme si rastësisht të jetë e mundur.

1428
01:02:39,430 --> 01:02:42,410
E pra, kjo është lloj i interesante,
sepse unë nuk mund të vërtetë

1429
01:02:42,410 --> 01:02:43,960
kontrollit kur përdoruesit do të vijnë.

1430
01:02:43,960 --> 01:02:47,645
Pra, mjaftonte për të thënë, në qoftë se ne të përhapet
gjëra në të gjithë hapësirën kyçe,

1431
01:02:47,645 --> 01:02:49,270
ne ndoshta do të jetë në formë të mirë.

1432
01:02:49,270 --> 01:02:51,522
>> Ka një farë
Shuma e ofrimit me kohë

1433
01:02:51,522 --> 01:02:53,230
se ju nuk jeni duke shkuar
të kontrollit gjendje.

1434
01:02:53,230 --> 01:02:55,438
Por, ata janë me të vërtetë
dy dimensione që ne kemi,

1435
01:02:55,438 --> 01:02:58,800
hapësirë, qasje në mënyrë të barabartë
përhapur, kohë, kërkesa

1436
01:02:58,800 --> 01:03:01,040
Duke arritur Spaced në mënyrë të barabartë në kohë.

1437
01:03:01,040 --> 01:03:03,110
Dhe në qoftë se ata të dy
Kushtet janë duke u përmbushur,

1438
01:03:03,110 --> 01:03:05,610
atëherë kjo është ajo që është
do të duken si.

1439
01:03:05,610 --> 01:03:07,890
Kjo është shumë nicer.

1440
01:03:07,890 --> 01:03:08,890
Ne jemi shumë të lumtur këtu.

1441
01:03:08,890 --> 01:03:10,432
Ne kemi marrë një model shumë edhe qasje.

1442
01:03:10,432 --> 01:03:13,098
Po, ndoshta ju jeni duke marrë një
pak presion çdo tani dhe pastaj,

1443
01:03:13,098 --> 01:03:14,830
por asgjë të vërtetë shumë të gjerë.

1444
01:03:14,830 --> 01:03:17,660
Pra, është e mahnitshme sa herë,
kur kam punuar me klientët,

1445
01:03:17,660 --> 01:03:20,670
që grafiku i parë me të kuqe e madhe
bar dhe të gjitha që është e shëmtuar verdhë

1446
01:03:20,670 --> 01:03:23,147
të gjithë vendin, ne
merrni bërë me ushtrimin

1447
01:03:23,147 --> 01:03:24,980
pas disa muaj
e ri-arkitekturës,

1448
01:03:24,980 --> 01:03:28,050
ata janë duke e njëjtë e saktë
Ngarkesa e punës në të njëjtën ngarkesë e saktë.

1449
01:03:28,050 --> 01:03:30,140
Dhe kjo është ajo që është në kërkim si tani.

1450
01:03:30,140 --> 01:03:36,600
Pra, ajo që ju merrni me NoSQL është një
skemë të dhëna që është absolutisht

1451
01:03:36,600 --> 01:03:38,510
lidhur me modelin e qasjes.

1452
01:03:38,510 --> 01:03:42,170
>> Dhe ju mund të zgjedh që të dhënat skemë
për të mbështetur këtë model qasje.

1453
01:03:42,170 --> 01:03:45,490
Nëse ju nuk bëni, atëherë ju do të jeni
për të parë ato lloje të problemeve

1454
01:03:45,490 --> 01:03:46,710
me ato çelësat e nxehtë.

1455
01:03:46,710 --> 01:03:50,518
>> Audienca: E pra, në mënyrë të pashmangshme disa vende
do të jetë hotter se të tjerët.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Gjithmonë.

1457
01:03:51,450 --> 01:03:51,960
Gjithmonë.

1458
01:03:51,960 --> 01:03:54,620
Po, Unë do të thotë ka gjithmonë
a-- dhe përsëri, nuk ka

1459
01:03:54,620 --> 01:03:56,980
disa modelet e projektimit ne do të merrni me anë të
që do të flasim rreth asaj se si të merren

1460
01:03:56,980 --> 01:03:58,480
me këto agregime super të mëdha.

1461
01:03:58,480 --> 01:04:01,260
Unë do të thotë, kam marrë që të ketë ato,
si mund të merremi me to?

1462
01:04:01,260 --> 01:04:03,760
Unë kam një rast mjaft të mirë përdorimi
që ne do të flasim për për atë.

1463
01:04:03,760 --> 01:04:05,940
>> Të gjithë të drejtë, kështu që le të flasim
rreth disa konsumatorë tani.

1464
01:04:05,940 --> 01:04:06,950
Këta njerëz janë AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Unë nuk e di nëse ju jeni
njohur me AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Ju ndoshta shihni ato
shumë në shfletuesin.

1467
01:04:10,781 --> 01:04:14,230
Ata janë ad ri-shënjestrimi, ata janë
më e madhe ad ri-i synimeve të dhënësit të biznesit

1468
01:04:14,230 --> 01:04:14,940
atje jashte.

1469
01:04:14,940 --> 01:04:17,792
Ata zakonisht rregullisht drejtuar mbi
60 miliard transaksione në ditë.

1470
01:04:17,792 --> 01:04:20,000
Ata po bëjnë më shumë se një milion
Transaksionet për sekondë.

1471
01:04:20,000 --> 01:04:22,660
Ata kanë marrë një tabelë shumë e thjeshtë
Struktura, tabela ngarkuar.

1472
01:04:22,660 --> 01:04:26,450
Kjo është në thelb vetëm një
kyç Hash është cookie,

1473
01:04:26,450 --> 01:04:29,010
varg është demografike
kategori, dhe pastaj

1474
01:04:29,010 --> 01:04:31,220
atributi i tretë është rezultati.

1475
01:04:31,220 --> 01:04:33,720
>> Pra, ne të gjithë kemi cookies në
shfletuesi ynë nga këta njerëz.

1476
01:04:33,720 --> 01:04:35,900
Dhe kur ju shkoni në një
tregtar pjesëmarrëse,

1477
01:04:35,900 --> 01:04:39,390
ata në thelb të shënuar të gjithë
kategoritë e ndryshme demografike.

1478
01:04:39,390 --> 01:04:42,070
Kur ju shkoni në një faqe interneti dhe
ju thonë se unë dua të shoh këtë ad--

1479
01:04:42,070 --> 01:04:44,920
apo në thelb ju nuk e thoni that--
por kur ju shkoni në faqen e internetit

1480
01:04:44,920 --> 01:04:47,550
ata thonë se ju doni të shihni këtë shpallje.

1481
01:04:47,550 --> 01:04:49,370
Dhe ata të shkojnë merrni atë shpallje nga AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll ju duket deri në tryezën e tyre.

1483
01:04:51,130 --> 01:04:52,115
Ata gjejnë cookie tuaj.

1484
01:04:52,115 --> 01:04:53,990
Reklamuesit duke u thënë
ata, unë dua dikë

1485
01:04:53,990 --> 01:04:58,632
i cili është i moshës së mesme,
Burrë 40-vjeçar, në sport.

1486
01:04:58,632 --> 01:05:01,590
Dhe ata të ju të shënuar në ato demografike
dhe ata të vendosin nëse janë apo jo

1487
01:05:01,590 --> 01:05:02,740
kjo është një reklamë e mirë për ju.

1488
01:05:02,740 --> 01:05:10,330
>> Tani ata kanë një SLA me
ofruesit e tyre reklamat

1489
01:05:10,330 --> 01:05:14,510
për të siguruar nën-10 Millisekonda
Përgjigja në çdo kërkesë të vetme.

1490
01:05:14,510 --> 01:05:16,090
Pra, ata janë duke përdorur Dynamo DB për këtë.

1491
01:05:16,090 --> 01:05:18,131
Ata po na goditur një
milionë kërkesa për sekondë.

1492
01:05:18,131 --> 01:05:21,120
Ata janë në gjendje të bëjë të gjitha e tyre
lookups, përzgjedhje të gjithë që të dhënat,

1493
01:05:21,120 --> 01:05:26,130
dhe për të marrë atë lidhje shtoni mbrapa në atë
reklamues në nën 10 milisekonda.

1494
01:05:26,130 --> 01:05:29,800
Është me të vërtetë mjaft fenomenal
Zbatimi se ata kanë.

1495
01:05:29,800 --> 01:05:36,210
>> Këta actually--
janë këto guys.

1496
01:05:36,210 --> 01:05:38,010
Unë nuk jam i sigurt nëse kjo është këta njerëz.

1497
01:05:38,010 --> 01:05:40,127
Mund të jetë këta njerëz.

1498
01:05:40,127 --> 01:05:42,210
Në thelb tha us-- jo, unë
nuk mendoj se ishte e tyre.

1499
01:05:42,210 --> 01:05:43,000
Mendoj se ishte dikush tjetër.

1500
01:05:43,000 --> 01:05:44,750
Unë kam qenë duke punuar me një
konsumatorëve që më tha

1501
01:05:44,750 --> 01:05:47,040
se tani që ata kanë
shkuar në Dinamo DB, ata janë

1502
01:05:47,040 --> 01:05:50,330
shpenzojnë më shumë para për snacks për
ekipi i tyre të zhvillimit çdo muaj

1503
01:05:50,330 --> 01:05:52,886
se ata shpenzojnë në database e tyre.

1504
01:05:52,886 --> 01:05:54,760
Pra, kjo do të ju jap një
Ideja e kursimet e kostos

1505
01:05:54,760 --> 01:05:57,889
që ju mund të merrni në Dinamo DB është i madh.

1506
01:05:57,889 --> 01:05:59,430
Të gjithë të drejtë, Dropcam është një tjetër kompani.

1507
01:05:59,430 --> 01:06:02,138
Këto djalë është lloj of-- në qoftë se ju mendoni se
e internetit të gjërave, Dropcam

1508
01:06:02,138 --> 01:06:05,150
është në thelb në internet video të sigurisë.

1509
01:06:05,150 --> 01:06:06,660
Ju vënë aparatin tuaj atje.

1510
01:06:06,660 --> 01:06:08,180
Kamera ka një detektor lëvizje.

1511
01:06:08,180 --> 01:06:10,290
Dikush vjen së bashku,
shkakton një pikë sugjerim.

1512
01:06:10,290 --> 01:06:13,540
Kamera fillon regjistrimi për një kohë deri
ajo nuk ka zbuluar ndonjë lëvizje më.

1513
01:06:13,540 --> 01:06:15,310
Vë se video deri në internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam ishte një kompani që është e
në thelb kaloi në Dinamo DB

1515
01:06:19,800 --> 01:06:22,200
sepse ata ishin duke përjetuar
mëdha dhimbjet në rritje.

1516
01:06:22,200 --> 01:06:25,820
Dhe çfarë na thanë,
papritmas petabajtë e të dhënave.

1517
01:06:25,820 --> 01:06:28,070
Ata nuk kishte asnjë ide shërbimin e tyre
do të jetë aq i suksesshëm.

1518
01:06:28,070 --> 01:06:32,310
Video Më shumë se përbrenda YouTube
është ajo që këta njerëz janë duke marrë.

1519
01:06:32,310 --> 01:06:36,780
Ata përdorin DynamoDB për të gjetur të gjitha
metadata në të gjitha pikat e tyre video-kyçe.

1520
01:06:36,780 --> 01:06:40,282
>> Pra, ata kanë kova S3 ata të shtyjë
Të gjitha Artefaktet binar në.

1521
01:06:40,282 --> 01:06:41,990
Dhe pastaj ata kanë
Të dhënat dinamo DB se

1522
01:06:41,990 --> 01:06:44,070
pikë njerëzit me ato S3 tre objekte.

1523
01:06:44,070 --> 01:06:47,070
Kur ata duhet të shikoni në një video,
ata shikojnë deri rekord në Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Ata klikoni lidhjen.

1525
01:06:47,903 --> 01:06:49,770
Ata shemb video nga S3.

1526
01:06:49,770 --> 01:06:51,590
Pra, kjo është lloj i asaj që kjo duket si.

1527
01:06:51,590 --> 01:06:53,580
Dhe kjo është e drejtë nga ekipi i tyre.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB redukton tyre
kohën e dorëzimit për ngjarjet video të

1529
01:06:56,010 --> 01:06:57,590
nga pesë deri në 10 sekonda.

1530
01:06:57,590 --> 01:07:00,470
Në dyqan e tyre të vjetër relacionale,
ata kanë përdorur për të shkuar dhe të ekzekutojë

1531
01:07:00,470 --> 01:07:03,780
pyetje të shumta komplekse të kuptoj
se cilat video për të tërhequr poshtë,

1532
01:07:03,780 --> 01:07:06,690
në më pak se 50 milisekonda.

1533
01:07:06,690 --> 01:07:08,990
Pra, kjo është e mahnitshme, e mahnitshme
sa performanca

1534
01:07:08,990 --> 01:07:12,990
ju mund të merrni kur ju zgjedh dhe
sintonizoheni baza e të dhënave themelor

1535
01:07:12,990 --> 01:07:15,110
për të mbështetur modelin qasje.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, këta njerëz, çfarë është ajo,
Fruit Ninja I guess është gjë e tyre.

1537
01:07:20,500 --> 01:07:22,590
Se të gjitha shkon në Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
Dhe këta njerëz, ata janë një e madhe
Ekipi i zhvillimit, zhvillimi i madh

1539
01:07:26,810 --> 01:07:27,670
dyqan.

1540
01:07:27,670 --> 01:07:29,364
>> Nuk është një ekip i mirë OPS.

1541
01:07:29,364 --> 01:07:31,280
Ata nuk kanë shumë
e burimeve operative.

1542
01:07:31,280 --> 01:07:33,940
Ata ishin duke luftuar duke u përpjekur për të mbajtur
infrastruktura e tyre e aplikimit deri

1543
01:07:33,940 --> 01:07:34,290
dhe drejtimin.

1544
01:07:34,290 --> 01:07:35,000
Ata erdhën tek ne.

1545
01:07:35,000 --> 01:07:36,251
Ata dukeshin në atë Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Ata thanë, kjo është për ne.

1547
01:07:37,291 --> 01:07:39,470
Ata ndërtuan gjithë e tyre
Korniza aplikimi mbi të.

1548
01:07:39,470 --> 01:07:43,640
Disa komente me të vërtetë e bukur këtu
nga ekipi në aftësinë e tyre

1549
01:07:43,640 --> 01:07:46,800
tani fokusohet në ndërtimin e
loja dhe jo

1550
01:07:46,800 --> 01:07:49,010
duke pasur për të ruajtur
infrastrukturës, e cila

1551
01:07:49,010 --> 01:07:51,910
ishte duke u bërë një sasi e madhe
i sipërm për ekipin e tyre.

1552
01:07:51,910 --> 01:07:56,170
Pra, kjo është diçka that--
dobi që ju të merrni nga Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Të gjithë të drejtë, duke marrë në
modelimit të dhëna këtu.

1554
01:08:00,930 --> 01:08:03,440
Dhe kemi biseduar pak për
ky një me një, një për të shumë,

1555
01:08:03,440 --> 01:08:05,060
dhe shumë shumë marrëdhëniet tipit.

1556
01:08:05,060 --> 01:08:07,630
Dhe si mund të mbajë ato në Dinamo.

1557
01:08:07,630 --> 01:08:10,500
Në Dinamo DB ne përdorim
indekseve, në përgjithësi,

1558
01:08:10,500 --> 01:08:12,910
të rrotullohen të dhënat nga
një aromë në tjetrën.

1559
01:08:12,910 --> 01:08:15,210
Çelësat hash, çelësat varg, dhe indekseve.

1560
01:08:15,210 --> 01:08:18,540
>> Në këtë të veçantë
shembull, si shumicën e shteteve

1561
01:08:18,540 --> 01:08:23,802
të ketë një kërkesë të licencimit që
vetëm patentë e një shoferi për person.

1562
01:08:23,802 --> 01:08:26,510
Ju nuk mund të shkojnë për të marrë dy shoferit
licencat në shtetin e Bostonit.

1563
01:08:26,510 --> 01:08:27,500
Unë nuk mund ta bëjë këtë në Teksas.

1564
01:08:27,500 --> 01:08:28,708
Kjo është lloj i mënyrës se si është.

1565
01:08:28,708 --> 01:08:32,779
Dhe kështu në DMV, kemi Lookups, ne
doni të shikoni patentë shoferin

1566
01:08:32,779 --> 01:08:35,180
nga numri i sigurimit social.

1567
01:08:35,180 --> 01:08:39,990
Unë dua të shikoni detajet e përdoruesit
nga numri i licencës e shoferit.

1568
01:08:39,990 --> 01:08:43,620
>> Pra, ne mund të kemi tabelën e përdoruesit që
ka një kyç hash në numrin serial,

1569
01:08:43,620 --> 01:08:47,830
ose numrin e sigurimit social, dhe
atributet e ndryshme të përcaktuara në pika.

1570
01:08:47,830 --> 01:08:49,859
Tani në atë tryezë I
mund të përcaktojë një GSI që

1571
01:08:49,859 --> 01:08:53,370
flips se rreth që thotë se unë dua
një kyç hash në licencë dhe pastaj

1572
01:08:53,370 --> 01:08:54,252
të gjitha sendet e tjera.

1573
01:08:54,252 --> 01:08:57,210
Tani në qoftë se unë dua të pyetjes dhe për të gjetur
numrin e licencës për çdo Sociale dhënë

1574
01:08:57,210 --> 01:08:59,609
Numrin e sigurimit, unë mund të
query tryezë kryesore.

1575
01:08:59,609 --> 01:09:02,130
>> Nëse unë dua të query dhe unë dua
për të marrë sigurimet shoqërore

1576
01:09:02,130 --> 01:09:05,735
Numri i apo atributet e tjera nga një
numrin e licencës, unë mund të query GSI.

1577
01:09:05,735 --> 01:09:08,689
Se modeli është se një
në një marrëdhënie.

1578
01:09:08,689 --> 01:09:12,460
Vetëm një GSI shumë të thjeshtë,
rrokullisje ato gjëra përreth.

1579
01:09:12,460 --> 01:09:13,979
Tani, të flasim për një të shumë.

1580
01:09:13,979 --> 01:09:16,450
Një për shumë është në thelb
juaj kyç varg hash.

1581
01:09:16,450 --> 01:09:20,510
Ku kemi marrë një shumë me këtë
Përdorimi rast të dhëna të monitoruar.

1582
01:09:20,510 --> 01:09:23,880
Monitor dhëna vjen në të rregullt
interval, si Internet të gjërave.

1583
01:09:23,880 --> 01:09:26,890
Ne gjithmonë merrni të gjitha këto
Të dhënat që vijnë në gjithë kohës.

1584
01:09:26,890 --> 01:09:31,420
>> Dhe unë dua të gjeni të gjitha leximet
në mes të një periudhe të caktuar kohore.

1585
01:09:31,420 --> 01:09:34,220
Kjo është një pyetje shumë e zakonshme në
Infrastruktura e monitorimit.

1586
01:09:34,220 --> 01:09:38,430
Mënyra lëvizje në lidhje me atë është për të gjetur një
strukturë e thjeshtë tryezë, një tryezë.

1587
01:09:38,430 --> 01:09:42,250
Unë kam marrë një tavolinë matjeve pajisje
me një kyç hash në ID pajisjes.

1588
01:09:42,250 --> 01:09:47,340
Dhe unë kam një çelës varg në
timestamp, apo në këtë rast, epike.

1589
01:09:47,340 --> 01:09:50,350
Dhe që lejon mua të ekzekutuar kompleks
pyetje kundër kësaj varg kyç

1590
01:09:50,350 --> 01:09:54,950
dhe kthehen ato shënime që
janë relative të rezultatit

1591
01:09:54,950 --> 01:09:56,310
vendosur që unë jam duke kërkuar për.

1592
01:09:56,310 --> 01:09:58,360
Dhe ajo ndërton se një
në marrëdhënie shumë

1593
01:09:58,360 --> 01:10:02,340
në tryezë primar duke përdorur
kyç hash, struktura kryesore varg.

1594
01:10:02,340 --> 01:10:04,600
>> Kështu që është ndërtuar lloj i
në tryezë në Dinamo DB.

1595
01:10:04,600 --> 01:10:07,290
Kur unë të përcaktuar një hash
dhe tabela varg t, unë jam

1596
01:10:07,290 --> 01:10:09,240
përcaktimin e një një për marrëdhënie shumë.

1597
01:10:09,240 --> 01:10:12,770
Kjo është një marrëdhënie prind-fëmijë.

1598
01:10:12,770 --> 01:10:14,620
>> Le të flasim për shumë
për shumë marrëdhënie.

1599
01:10:14,620 --> 01:10:19,170
Dhe për këtë shembull të veçantë,
përsëri, ne jemi duke shkuar për të përdorur GSI-së.

1600
01:10:19,170 --> 01:10:23,500
Dhe le të flasim rreth lojrave
skenar ku unë kam një përdorues të caktuar.

1601
01:10:23,500 --> 01:10:26,500
Unë dua të gjeni të gjitha lojrat që
ai është i regjistruar për ose duke luajtur në.

1602
01:10:26,500 --> 01:10:29,600
Dhe për një lojë të caktuar, unë
doni të gjeni të gjithë përdoruesit.

1603
01:10:29,600 --> 01:10:31,010
Pra, si mund ta bëni këtë?

1604
01:10:31,010 --> 01:10:34,330
My tavolinë Games User, unë jam duke shkuar
të ketë një çelës hash prej përdoruesit ID

1605
01:10:34,330 --> 01:10:35,810
dhe një varg kyç të lojës.

1606
01:10:35,810 --> 01:10:37,810
>> Kështu që një përdorues mund të ketë lojëra të shumta.

1607
01:10:37,810 --> 01:10:41,380
Kjo është një njeri për marrëdhënie ndërmjet shumë
përdoruesi dhe lojërat që ai luan.

1608
01:10:41,380 --> 01:10:43,410
Dhe pastaj në GSI,
Unë do të rrokullisje se rreth.

1609
01:10:43,410 --> 01:10:46,679
Unë do të hash në lojë dhe
Unë do të shkojnë në të përdoruesit.

1610
01:10:46,679 --> 01:10:48,970
Pra, nëse unë dua të të marrë të gjitha
lojë përdoruesi është duke luajtur në,

1611
01:10:48,970 --> 01:10:49,950
Unë do të query tryezë kryesore.

1612
01:10:49,950 --> 01:10:52,699
Nëse unë dua të të marrë të gjithë përdoruesit
se janë duke luajtur një lojë të veçantë,

1613
01:10:52,699 --> 01:10:53,887
Unë query GSI.

1614
01:10:53,887 --> 01:10:54,970
Kështu që ju shihni se si ta bëjmë këtë?

1615
01:10:54,970 --> 01:10:58,369
Ju ndërtuar këto GSI-së për të mbështetur
rast përdorimi, aplikimi, qasja

1616
01:10:58,369 --> 01:10:59,410
model, aplikimi.

1617
01:10:59,410 --> 01:11:01,440
>> Nëse unë duhet të query në
ky dimension, le të

1618
01:11:01,440 --> 01:11:03,500
Më të krijuar një indeks në atë dimension.

1619
01:11:03,500 --> 01:11:05,850
Nëse unë nuk bëj, unë nuk e kujdesit.

1620
01:11:05,850 --> 01:11:09,060
Dhe sipas rastit të përdorimit, unë
mund të kenë nevojë indeksi ose unë nuk mund të.

1621
01:11:09,060 --> 01:11:12,390
Në qoftë se kjo është një e thjeshtë për shumë njerëz,
tabela kryesor është e mirë.

1622
01:11:12,390 --> 01:11:15,860
Nëse unë duhet të bëni këto shumë të
shumë së, ose unë duhet të bëjë një për ato,

1623
01:11:15,860 --> 01:11:18,390
atëherë ndoshta unë kam nevojë
të dytë indeksi.

1624
01:11:18,390 --> 01:11:20,840
Pra, të gjitha varet nga
ajo që unë jam duke u përpjekur për të bërë

1625
01:11:20,840 --> 01:11:24,550
dhe atë që unë jam duke u përpjekur për të marrë kryer.

1626
01:11:24,550 --> 01:11:28,000
>> Ndoshta unë nuk jam duke shkuar për të shpenzuar shumë
shumë kohë duke folur për dokumente.

1627
01:11:28,000 --> 01:11:31,460
Kjo merr pak, ndoshta,
thellë se ne kemi nevojë për të shkuar në.

1628
01:11:31,460 --> 01:11:33,710
Le të flasim pak
shprehje për të pasur query.

1629
01:11:33,710 --> 01:11:37,831
Pra, në Dinamo DB ne kemi
aftësia për të krijuar

1630
01:11:37,831 --> 01:11:39,330
ajo që ne e quajmë shprehje projektimit.

1631
01:11:39,330 --> 01:11:42,660
Shprehjet Projektim janë thjesht
picking fushat ose vlerat

1632
01:11:42,660 --> 01:11:44,290
që ju doni të shfaqur.

1633
01:11:44,290 --> 01:11:46,000
OK, kështu që unë të bëjë një përzgjedhje.

1634
01:11:46,000 --> 01:11:48,010
Unë bëj një pyetje kundër Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
Dhe unë them, ju e dini se çfarë, shfaqje
Me vetëm pesë komente të yll

1636
01:11:51,730 --> 01:11:54,544
për këtë produkt të veçantë.

1637
01:11:54,544 --> 01:11:55,710
Pra, kjo është e gjitha unë dua të shoh.

1638
01:11:55,710 --> 01:11:57,320
Unë nuk dua të shoh të gjitha
atributet e tjera të radhës,

1639
01:11:57,320 --> 01:11:58,319
Unë vetëm dua të shoh këtë.

1640
01:11:58,319 --> 01:12:01,209
Është vetëm si në SQL, kur ju
thonë zgjidhni yll ose nga tabela,

1641
01:12:01,209 --> 01:12:02,000
ju merrni gjithçka.

1642
01:12:02,000 --> 01:12:05,450
Kur them zgjidhni emrin nga
tavolinë, unë vetëm të marrë një atribut.

1643
01:12:05,450 --> 01:12:09,070
Është e njëjta lloj gjë në
Dynamo DB ose një tjetër bazat e të dhënave NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Filtro shprehjet më lejoni të
në thelb të shkurtojë rezultatin vendosur poshtë.

1645
01:12:14,510 --> 01:12:15,540
Kështu që unë bëj një pyetje.

1646
01:12:15,540 --> 01:12:17,260
Query mund të vijë përsëri me 500 artikuj.

1647
01:12:17,260 --> 01:12:20,255
Por, unë dua vetëm artikujt që
kanë një atribut që thotë kjo.

1648
01:12:20,255 --> 01:12:23,380
OK, kështu që le të filtruar nga ato artikuj
që nuk përputhen me këtë pyetje të veçantë.

1649
01:12:23,380 --> 01:12:25,540
Pra, ne kemi shprehje filtër.

1650
01:12:25,540 --> 01:12:28,310
>> Filter shprehje mund
të kandidojë në çdo atribut.

1651
01:12:28,310 --> 01:12:30,260
Ata nuk janë si pyetje varg.

1652
01:12:30,260 --> 01:12:32,690
Ngrenë pyetje janë më selektive.

1653
01:12:32,690 --> 01:12:36,470
Filtro pyetje kërkon mua për të shkuar
merrni rezultatet gjithë të vendosur dhe më pas

1654
01:12:36,470 --> 01:12:39,170
ndërtoj të dhënat Unë nuk dua.

1655
01:12:39,170 --> 01:12:40,660
Pse është kjo e rëndësishme?

1656
01:12:40,660 --> 01:12:42,770
Sepse kam lexuar të gjitha.

1657
01:12:42,770 --> 01:12:46,597
Në një pyetje, unë jam duke shkuar për të lexuar dhe
ajo do të jetë një gjigant për të dhënat.

1658
01:12:46,597 --> 01:12:48,430
Dhe atëherë unë jam duke shkuar për
ndërtoj atë që kam nevojë.

1659
01:12:48,430 --> 01:12:52,080
Dhe në qoftë se unë jam vetëm gdhendje një
çift ​​i rreshtave, atëherë kjo është në rregull.

1660
01:12:52,080 --> 01:12:53,620
Kjo nuk është aq i paefektshëm.

1661
01:12:53,620 --> 01:12:57,800
>> Por në qoftë se unë jam duke lexuar një grumbull të tërë të
të dhëna, vetëm të ndërtoj një artikull,

1662
01:12:57,800 --> 01:13:01,490
atëherë unë jam do të jetë më mirë
duke përdorur një pyetje varg,

1663
01:13:01,490 --> 01:13:03,030
sepse kjo është shumë më selektive.

1664
01:13:03,030 --> 01:13:06,330
Ajo do të shpëtojë më shumë
para, sepse unë të paguajnë për atë lexuar.

1665
01:13:06,330 --> 01:13:10,430
Ku rezultatet që vjen prapa
kalojnë atë tela mund të jenë më të vogla,

1666
01:13:10,430 --> 01:13:11,890
por unë jam duke paguar për të lexuar.

1667
01:13:11,890 --> 01:13:14,340
Pra, të kuptojnë se si
ju jeni marrë të dhënat.

1668
01:13:14,340 --> 01:13:16,420
Kjo është shumë e rëndësishme në Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Shprehjet e kushtëzuara, kjo është ajo që
ju mund të telefononi mbyllje optimiste.

1670
01:13:19,710 --> 01:13:28,470
Update nëse ekziston, ose në qoftë se kjo vlerë
është e barabartë me atë që unë të specifikojë.

1671
01:13:28,470 --> 01:13:31,494
Dhe në qoftë se unë kam një vulë kohë në një
rekord, unë mund të lexoni të dhënat.

1672
01:13:31,494 --> 01:13:32,535
Unë mund të ndryshojë këto të dhëna.

1673
01:13:32,535 --> 01:13:35,030
Unë mund të shkoj shkruaj se
të dhënat përsëri në bazën e të dhënave.

1674
01:13:35,030 --> 01:13:38,100
Në qoftë se dikush ka ndryshuar rekord,
timestamp mund të ketë ndryshuar.

1675
01:13:38,100 --> 01:13:40,370
Dhe në këtë mënyrë i kushtëzuar im
Përditësimi mund të them përditësim

1676
01:13:40,370 --> 01:13:42,340
nëse timestamp barabartë kjo.

1677
01:13:42,340 --> 01:13:46,290
Ose update do të dështojë për shkak dikë
updated rekordin në ndërkohë.

1678
01:13:46,290 --> 01:13:48,290
>> Kjo është ajo që ne e quajmë mbyllje optimiste.

1679
01:13:48,290 --> 01:13:50,670
Kjo do të thotë se dikush
mund të vijnë në dhe për të ndryshuar atë,

1680
01:13:50,670 --> 01:13:53,100
dhe unë jam duke shkuar për të zbuluar atë
kur të shkoj përsëri për të shkruar.

1681
01:13:53,100 --> 01:13:56,106
Dhe pastaj unë në fakt mund të lexoni se
të dhënave dhe të thonë, oh, ai e ndryshoi këtë.

1682
01:13:56,106 --> 01:13:57,230
Unë kam nevojë për të llogari për atë.

1683
01:13:57,230 --> 01:14:00,490
Dhe unë mund të ndryshojë të dhënat në tim
rekord dhe aplikoni një përditësim.

1684
01:14:00,490 --> 01:14:04,330
Kështu që ju mund të kapur ata në rritje
përditësime që ndodhin në mes të kohës

1685
01:14:04,330 --> 01:14:08,740
që ju lexoni të dhënat dhe
herë ju mund të shkruani të dhënat.

1686
01:14:08,740 --> 01:14:11,520
>> Audienca: Dhe filtër
shprehje në fakt nuk do të thotë

1687
01:14:11,520 --> 01:14:13,020
në numrin ose not--

1688
01:14:13,020 --> 01:14:14,316
>> [Ndërhynte ZËRA]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: Unë nuk do të
marrë shumë në këtë.

1690
01:14:16,232 --> 01:14:17,700
Kjo është një fjalen e rezervuar.

1691
01:14:17,700 --> 01:14:20,130
Pamje Pound është një rezervuar
fjalen në Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Çdo bazës së të dhënave ka vet e rezervuara
emra për koleksionet ju nuk mund të përdorni.

1693
01:14:24,500 --> 01:14:27,240
Dinamo DB, nëse ju specifikoni
një kile në frontin e kësaj,

1694
01:14:27,240 --> 01:14:29,310
ju mund të përcaktojë ato emra lart.

1695
01:14:29,310 --> 01:14:31,840
Kjo është një vlerë të cekura.

1696
01:14:31,840 --> 01:14:34,880
Kjo ndoshta nuk është sintaksa e mirë për të
kanë atje për këtë diskutim,

1697
01:14:34,880 --> 01:14:38,090
për shkak se ajo merr në disa real--
Unë do të kishte qenë duke folur më shumë

1698
01:14:38,090 --> 01:14:41,360
në lidhje me atë në një nivel më të thellë.

1699
01:14:41,360 --> 01:14:46,130
>> Por mjafton të them, kjo mund të
jetë query scan ku ata views--

1700
01:14:46,130 --> 01:14:50,190
as paund views është më i madh se 10.

1701
01:14:50,190 --> 01:14:54,660
Kjo është një vlerë numerike, po.

1702
01:14:54,660 --> 01:14:57,322
Nëse dëshironi, mund të flasim për
se pas diskutimit.

1703
01:14:57,322 --> 01:15:00,030
Të gjithë të drejtë, kështu që ne jemi duke marrë në
disa skenarë në praktikat më të mira

1704
01:15:00,030 --> 01:15:02,000
ku ne jemi duke shkuar për të folur
për disa aplikacione këtu.

1705
01:15:02,000 --> 01:15:03,810
Cilat janë rastet e përdorimit për Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Cilat janë të projektimit
modelet në Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> Dhe i pari që ne jemi duke shkuar për
flasim për është e internetit të gjërave.

1708
01:15:09,110 --> 01:15:15,010
Pra, ne të merrni një shumë of-- unë mendoj,
ajo që është it-- më shumë se 50%

1709
01:15:15,010 --> 01:15:19,370
e trafikut në internet këto ditë
është e gjeneruar të vërtetë nga makinat,

1710
01:15:19,370 --> 01:15:21,930
proceset e automatizuar, jo nga njerëzit.

1711
01:15:21,930 --> 01:15:25,140
Unë do të thotë këtë gjë kjo që
keni kryer rreth në xhepin tuaj,

1712
01:15:25,140 --> 01:15:28,840
se si të dhënat shumë sa që kjo gjë është
në fakt duke dërguar rreth pa ty

1713
01:15:28,840 --> 01:15:30,550
duke e ditur se është absolutisht e mrekullueshme.

1714
01:15:30,550 --> 01:15:34,970
Vendndodhjen tuaj, informacioni
rreth asaj se si shpejt ju jeni duke shkuar.

1715
01:15:34,970 --> 01:15:38,400
Si mendoni Google Maps vepra
kur ata të ju tregojnë se çfarë trafiku është.

1716
01:15:38,400 --> 01:15:41,275
Kjo është për shkak se ka me miliona dhe
miliona njerëz të makinës rreth

1717
01:15:41,275 --> 01:15:44,667
me telefona që janë dërguar
të dhëna në të gjithë vendin gjatë gjithë kohës.

1718
01:15:44,667 --> 01:15:46,500
Pra, një nga gjërat
në lidhje me këtë lloj të të dhënave

1719
01:15:46,500 --> 01:15:50,980
që vjen në, të dhënat Monitor, log
të dhënave, të dhënat e kohë seri, është ajo e

1720
01:15:50,980 --> 01:15:53,540
zakonisht vetëm interesante
për pak kohë.

1721
01:15:53,540 --> 01:15:55,580
Pas asaj kohe, është e
jo aq interesante.

1722
01:15:55,580 --> 01:15:58,390
Pra, kemi biseduar rreth, nuk e le
këto tavolina të rriten pa të mëdhenj.

1723
01:15:58,390 --> 01:16:03,410
Ideja këtu është se ndoshta unë kam marrë 24
orë vlerë e ngjarjeve në tryezën time të nxehtë.

1724
01:16:03,410 --> 01:16:06,160
Dhe kjo tryezë e nxehtë do të jetë
parashikuar në një shkallë shumë të lartë,

1725
01:16:06,160 --> 01:16:07,950
për shkak se ajo është duke marrë një shumë të të dhënave.

1726
01:16:07,950 --> 01:16:10,920
Ajo është duke marrë një shumë të të dhënave
në dhe unë jam duke lexuar atë shumë.

1727
01:16:10,920 --> 01:16:14,560
Unë kam marrë një shumë të operimit
pyetje running kundër atij të dhëna.

1728
01:16:14,560 --> 01:16:18,120
>> Pas 24 orësh, hej, ju
e di se çfarë, unë nuk e kujdesit.

1729
01:16:18,120 --> 01:16:21,150
Kështu që ndoshta çdo mesnatë unë roll
tryezën time mbi një tavolinë të re

1730
01:16:21,150 --> 01:16:22,430
dhe unë deprovision këtë tabelë.

1731
01:16:22,430 --> 01:16:26,440
Dhe unë do të marrë RCU-së dhe
Poshtë NJKL sepse 24 orë më vonë

1732
01:16:26,440 --> 01:16:28,630
Unë nuk jam kandidon si shumë
pyetje kundër kësaj të dhënave.

1733
01:16:28,630 --> 01:16:30,200
Kështu që unë jam duke shkuar për të kursyer para.

1734
01:16:30,200 --> 01:16:32,940
Dhe ndoshta 30 ditë më vonë, unë nuk e bëj
edhe duhet të kujdesen për të gjitha.

1735
01:16:32,940 --> 01:16:35,020
Unë mund të marrë NJKL-së
të gjithë rrugën poshtë për një,

1736
01:16:35,020 --> 01:16:36,990
sepse ju e dini se çfarë, është
kurrë nuk do të merrni me shkrim.

1737
01:16:36,990 --> 01:16:38,300
Të dhënat është 30 ditë të vjetra.

1738
01:16:38,300 --> 01:16:40,000
Ajo nuk ndryshon kurrë.

1739
01:16:40,000 --> 01:16:44,200
>> Dhe kjo është pothuajse kurrë nuk do të merrni të lexuar,
kështu që le të marrë vetëm atë RCU deri në 10.

1740
01:16:44,200 --> 01:16:49,372
Dhe unë jam duke kursyer një ton të parave për këtë
të dhënave, dhe vetëm duke paguar për të dhënat e mia të nxehtë.

1741
01:16:49,372 --> 01:16:52,330
Pra, kjo është gjë e rëndësishme për të parë
në kur ju shikoni në një seri kohore

1742
01:16:52,330 --> 01:16:54,716
të dhënat që vijnë në në vëllim.

1743
01:16:54,716 --> 01:16:55,590
Këto janë strategji.

1744
01:16:55,590 --> 01:16:58,010
Tani, unë mund vetëm le atë
të gjithë shkojnë në të njëjtën tryezë

1745
01:16:58,010 --> 01:16:59,461
dhe vetëm le atë tryezë të rriten.

1746
01:16:59,461 --> 01:17:01,460
Përfundimisht, unë jam duke shkuar për
shih çështjet e performancës.

1747
01:17:01,460 --> 01:17:04,060
Unë do të duhet të fillojë për të arkivit
disa prej se të dhënat off tryezë,

1748
01:17:04,060 --> 01:17:04,720
çfarë jo.

1749
01:17:04,720 --> 01:17:07,010
>> Le të shumë më mirë
hartuar aplikimin tuaj

1750
01:17:07,010 --> 01:17:08,900
kështu që ju mund të veprojë në këtë mënyrë të drejtë.

1751
01:17:08,900 --> 01:17:11,460
Pra, kjo është vetëm automatike
në kodin e aplikimit.

1752
01:17:11,460 --> 01:17:13,580
Në mesnatë çdo natë
ajo e rrotullon tryezë.

1753
01:17:13,580 --> 01:17:17,170
Ndoshta atë që kam nevojë është një rrëshqitje
Dritarja e 24 orëve të dhënave.

1754
01:17:17,170 --> 01:17:20,277
Pastaj mbi një bazë të rregullt unë jam
duke e quajtur të dhënat off tryezë.

1755
01:17:20,277 --> 01:17:22,360
Unë jam zvogëlimin atë me një
Punë cron dhe unë jam vënë atë

1756
01:17:22,360 --> 01:17:24,160
në këto tabela të tjera,
çdo gjë që ju nevojitet.

1757
01:17:24,160 --> 01:17:25,940
Pra, nëse një rollover punon, kjo është e madhe.

1758
01:17:25,940 --> 01:17:27,080
Nëse jo, të shkurtojë atë.

1759
01:17:27,080 --> 01:17:29,640
Por le të mbajtur ato të dhëna të nxehtë
larg nga të dhënat tuaja të ftohtë.

1760
01:17:29,640 --> 01:17:32,535
Kjo do të ju kursejnë një shumë të holla dhe
bëjnë tavolinat tuaja më shumë probleme.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Pra, gjëja tjetër ne do të flasim
lidhje është katalog produkt.

1763
01:17:38,210 --> 01:17:42,000
Katalogu i produkteve është
Rasti shumë e zakonshme përdorimi.

1764
01:17:42,000 --> 01:17:46,600
Kjo është në fakt një model shumë i zakonshëm
se ne do të shohim në një shumëllojshmëri të gjëra.

1765
01:17:46,600 --> 01:17:48,870
Ju e dini, Twitter për
shembull, një cicërimë të nxehtë.

1766
01:17:48,870 --> 01:17:51,280
Çdo njeri vjen dhe
grabbing atë cicërimë.

1767
01:17:51,280 --> 01:17:52,680
Katalogu i produkteve, kam marrë një shitje.

1768
01:17:52,680 --> 01:17:54,120
Kam marrë një shitje të nxehtë.

1769
01:17:54,120 --> 01:17:57,277
I kam 70,000 kërkesa për
ardhjen e dytë për një produkt

1770
01:17:57,277 --> 01:17:58,860
përshkrim nga katalogu ime produktit.

1771
01:17:58,860 --> 01:18:02,384
Ne e shohim këtë në pakicë
operacion mjaft pak.

1772
01:18:02,384 --> 01:18:03,550
Pra, si mund të merremi me atë?

1773
01:18:03,550 --> 01:18:04,924
Nuk ka asnjë mënyrë për t'u marrë me atë.

1774
01:18:04,924 --> 01:18:07,110
Të gjithë përdoruesit e mia duan të shohin
e njëjta pjesë e të dhënave.

1775
01:18:07,110 --> 01:18:09,410
Ata po vijnë në, njëkohësisht.

1776
01:18:09,410 --> 01:18:11,920
Dhe ata janë të gjithë duke bërë kërkesa
për të njëjtën pjesë të të dhënave.

1777
01:18:11,920 --> 01:18:16,240
Kjo i jep mua se çelësi i nxehtë, ajo e kuqe e madhe
shirit në kartelën time se ne nuk na pëlqen.

1778
01:18:16,240 --> 01:18:17,720
Dhe kjo është ajo që duket si.

1779
01:18:17,720 --> 01:18:22,290
Pra, të gjithë hapësirën time kyçe unë jam marrë
hartuar në pikat e shitjes.

1780
01:18:22,290 --> 01:18:24,070
Unë jam marrë asgjë kudo tjetër.

1781
01:18:24,070 --> 01:18:26,050
>> Si mund ta lehtësuar këtë problem?

1782
01:18:26,050 --> 01:18:28,410
E pra, ne të lehtësuar këtë me cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, ju vënë në thelb një në kujtesën
ndarje në frontin bazën e të dhënave.

1784
01:18:33,630 --> 01:18:37,260
Ne kemi arritur
[Padëgjueshme] cache, si ju

1785
01:18:37,260 --> 01:18:40,260
mund të ngritur vetë cache tuaj, [e padëgjueshme]
cache [? d,?] çdo gjë që ju dëshironi.

1786
01:18:40,260 --> 01:18:42,220
Vënë atë në frontin e bazën e të dhënave.

1787
01:18:42,220 --> 01:18:47,250
Dhe në këtë mënyrë ju mund të ruajë ato të dhëna
nga ato çelësat e nxehtë deri në atë cache

1788
01:18:47,250 --> 01:18:49,390
hapësirë ​​dhe lexuar nëpër cache.

1789
01:18:49,390 --> 01:18:51,962
>> Dhe pastaj shumica e lexon tuaj
fillojmë të shikojmë si kjo.

1790
01:18:51,962 --> 01:18:54,920
I kam të gjitha këto cache godet këtu
dhe kam marrë asgjë ndodh këtu poshtë

1791
01:18:54,920 --> 01:18:59,330
sepse baza e të dhënave është e ulur prapa
cache dhe nuk lexon vijnë përmes.

1792
01:18:59,330 --> 01:19:02,520
Nëse unë të ndryshojë të dhënat në
bazës së të dhënave, unë kam për të rinovuar cache.

1793
01:19:02,520 --> 01:19:04,360
Ne mund të përdorim diçka
si avuj për të bërë këtë.

1794
01:19:04,360 --> 01:19:07,360
Dhe unë do të shpjegojë se si punon kjo.

1795
01:19:07,360 --> 01:19:09,060
Të gjithë të drejtë, mesazheve.

1796
01:19:09,060 --> 01:19:11,180
Email, ne të gjithë e përdorin e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> Ky është një shembull mjaft të mirë.

1798
01:19:12,540 --> 01:19:14,950
Ne kemi marrë disa lloj të mesazheve tabelës.

1799
01:19:14,950 --> 01:19:17,040
Dhe kemi marrë postë dhe Dalje.

1800
01:19:17,040 --> 01:19:19,760
Kjo është ajo që do SQL
duken si për të ndërtuar atë në postë.

1801
01:19:19,760 --> 01:19:23,350
Ne lloj i përdorin të njëjtin lloj
i strategjisë për të përdorur GSI-së, GSI-së

1802
01:19:23,350 --> 01:19:25,320
për kutinë time dhe Dalje tim.

1803
01:19:25,320 --> 01:19:27,600
Kështu që unë kam mesazhe të para që vijnë
në mesazhe tryezën time.

1804
01:19:27,600 --> 01:19:30,194
Dhe qasja e parë për këtë
mund të jetë, të themi, OK, nuk ka problem.

1805
01:19:30,194 --> 01:19:31,110
Unë kam marrë mesazhe të papërpunuara.

1806
01:19:31,110 --> 01:19:33,710
Mesazhet që vijnë [e padëgjueshme],
Mesazhi ID, kjo është e madhe.

1807
01:19:33,710 --> 01:19:35,070
Kjo është hash ime unik.

1808
01:19:35,070 --> 01:19:38,280
Unë jam duke shkuar për të krijuar dy GSI-së, një
për kutinë time, një për Dalje tim.

1809
01:19:38,280 --> 01:19:40,530
Dhe gjëja e parë që unë do të bëj
po unë do të them kyç im hash është

1810
01:19:40,530 --> 01:19:43,310
do të jetë marrësi dhe
Unë jam duke shkuar për të rregulluar në datën.

1811
01:19:43,310 --> 01:19:44,220
Kjo është fantastike.

1812
01:19:44,220 --> 01:19:45,890
Unë kam mendimin tim të bukur këtu.

1813
01:19:45,890 --> 01:19:47,780
Por ka një problem të vogël këtu.

1814
01:19:47,780 --> 01:19:50,891
Dhe ju drejtuar në këtë në
databaza relacionale si.

1815
01:19:50,891 --> 01:19:52,390
Ata i bënë thirrje ndarjen vertikalisht.

1816
01:19:52,390 --> 01:19:55,840
Ju dëshironi të mbani të dhënat tuaja të madhe
larg nga të dhënat tuaja të vogla.

1817
01:19:55,840 --> 01:20:00,470
>> Dhe arsyeja pse është për shkak se unë Gotta
shkoni lexoni artikujt për të marrë atributet.

1818
01:20:00,470 --> 01:20:05,570
Dhe në qoftë se organet e mi janë të gjithë këtu,
pastaj duke lexuar vetëm disa artikuj

1819
01:20:05,570 --> 01:20:08,560
nëse gjatësia trupi im është
mesatarisht 256 kilobytes secila,

1820
01:20:08,560 --> 01:20:10,991
matematikë merr goxha e shëmtuar.

1821
01:20:10,991 --> 01:20:12,490
Pra, thonë se unë dua të lexoj postë Davidit.

1822
01:20:12,490 --> 01:20:14,520
Inbox Davidit ka 50 objekte.

1823
01:20:14,520 --> 01:20:17,880
Mesatarja e madhësisë është 256 kilobytes.

1824
01:20:17,880 --> 01:20:21,730
Këtu është raporti im konvertimit
për RCU-së është katër kilobytes.

1825
01:20:21,730 --> 01:20:24,450
>> OK, le të shkojë me
përfundimisht në përputhje lexon.

1826
01:20:24,450 --> 01:20:28,640
Unë jam ende duke ngrënë 1600 RCU-së
vetëm për të lexuar postë Davidit.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
OK, tani le të mendojmë
për mënyrën se si funksionon aplikacioni.

1829
01:20:31,980 --> 01:20:35,340
Në qoftë se unë jam në një app email dhe
Unë jam duke kërkuar në kutinë time,

1830
01:20:35,340 --> 01:20:39,680
dhe unë shoh në trupin e çdo mesazhi,
jo, unë jam duke kërkuar në përmbledhjet.

1831
01:20:39,680 --> 01:20:41,850
Unë jam duke kërkuar në vetëm headers.

1832
01:20:41,850 --> 01:20:46,310
Pra, le të ndërtojmë një strukturë tryezë
që duket më shumë si kjo.

1833
01:20:46,310 --> 01:20:49,470
>> Kështu që këtu është informacioni
që ka nevojë për workflow im.

1834
01:20:49,470 --> 01:20:50,890
Është në kutinë time GSI.

1835
01:20:50,890 --> 01:20:53,800
Kjo është data, dërguesi,
subjekt, dhe pastaj

1836
01:20:53,800 --> 01:20:56,790
ID mesazhi, i cili tregon
përsëri në mesazhet tryezë

1837
01:20:56,790 --> 01:20:57,850
ku unë mund të merrni trupin.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
E pra, këto do të jenë ID rekord.

1840
01:21:04,420 --> 01:21:09,850
Ata do të pikë prapa në
ID pika në tryezë Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Çdo indeksi gjithmonë creates--
gjithmonë ka pika

1842
01:21:12,220 --> 01:21:15,750
ID si pjesë of-- se
vjen me indeksin.

1843
01:21:15,750 --> 01:21:17,414
>> Në rregull.

1844
01:21:17,414 --> 01:21:19,080
Audienca: Ajo tregon se ku është e ruajtur?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Po, ai tregon
exactly-- kjo është pikërisht ajo që e bën.

1846
01:21:21,420 --> 01:21:22,644
Ajo thotë se këtu është rekord RE.

1847
01:21:22,644 --> 01:21:24,310
Dhe kjo do të pikë atë përsëri në rekordin tim të ri.

1848
01:21:24,310 --> 01:21:26,460
Pikërisht.

1849
01:21:26,460 --> 01:21:29,490
OK, kështu që tani inbox im është
në fakt shumë më të vogla.

1850
01:21:29,490 --> 01:21:32,210
Dhe kjo në fakt mbështet
workflow i një app email.

1851
01:21:32,210 --> 01:21:34,230
Pra kutinë time, unë klikoni.

1852
01:21:34,230 --> 01:21:38,160
I shkojnë së bashku dhe unë klikoni mbi mesazhin,
kjo është kur kam nevojë për të shkuar të marrë trupin,

1853
01:21:38,160 --> 01:21:40,180
sepse unë jam duke shkuar për
shkoni në një pikëpamje të ndryshme.

1854
01:21:40,180 --> 01:21:43,870
Pra, nëse ju mendoni për llojin e MVC
kornizë, Model Shiko kontrollues.

1855
01:21:43,870 --> 01:21:46,120
>> Modeli përmban
të dhënat që nevojat view

1856
01:21:46,120 --> 01:21:48,130
dhe kontrolluesi ndërvepron me.

1857
01:21:48,130 --> 01:21:51,670
Kur unë të ndryshojë kornizë, kur
Unë të ndryshojë perspektivën,

1858
01:21:51,670 --> 01:21:55,080
është në rregull për të shkuar përsëri në
server dhe ripopulluar modelin,

1859
01:21:55,080 --> 01:21:56,860
sepse kjo është ajo që pret përdoruesi.

1860
01:21:56,860 --> 01:22:00,530
Kur ata të ndryshojnë pikëpamje, kjo është kur
ne mund të shkoni përsëri në bazën e të dhënave.

1861
01:22:00,530 --> 01:22:02,480
Pra email, klikoni.

1862
01:22:02,480 --> 01:22:03,710
Unë jam duke kërkuar për trupin.

1863
01:22:03,710 --> 01:22:04,330
Udhëtim.

1864
01:22:04,330 --> 01:22:05,680
Shkoni merrni trupin.

1865
01:22:05,680 --> 01:22:06,950
>> Kam lexuar shumë më pak të dhëna.

1866
01:22:06,950 --> 01:22:09,960
Unë jam vetëm duke lexuar organet që
David ka nevojë, kur ai ka nevojë për ta.

1867
01:22:09,960 --> 01:22:14,230
Dhe unë nuk jam djeg në 1600
RCU të vetëm për të treguar postë tij.

1868
01:22:14,230 --> 01:22:17,670
Deri tani that-- kjo është mënyra
se LSI apo GSI-- unë jam i keq,

1869
01:22:17,670 --> 01:22:19,900
GSI, do të punojnë jashtë.

1870
01:22:19,900 --> 01:22:25,450
Ne kemi marrë hashin tonë në marrësit.

1871
01:22:25,450 --> 01:22:27,030
Ne kemi marrë çelësin varg në datën.

1872
01:22:27,030 --> 01:22:31,380
Dhe ne kemi marrë atributet projektuara
se ne kemi nevojë vetëm për të mbështetur pikëpamjen.

1873
01:22:31,380 --> 01:22:34,300
>> Ne rrotullohen se për Dalje.

1874
01:22:34,300 --> 01:22:35,770
Hash në dërguesit.

1875
01:22:35,770 --> 01:22:39,612
Dhe në thelb, ne kemi
, pamje shumë e bukur të pastër.

1876
01:22:39,612 --> 01:22:41,570
Dhe kjo është që ne basically--
kemi këtë porosi bukur

1877
01:22:41,570 --> 01:22:45,870
tabela që është duke u përhapur bukur sepse
kjo është vetëm hash, sheshuar mesazh ID.

1878
01:22:45,870 --> 01:22:51,750
Dhe ne kemi dy indekseve që
janë të rradhës off e atë tryezë.

1879
01:22:51,750 --> 01:22:57,411
Të gjithë të drejtë, kështu që ideja këtu është të mos
ruajnë të dhënat mëdha dhe këto të dhëna të vogël

1880
01:22:57,411 --> 01:22:57,910
së bashku.

1881
01:22:57,910 --> 01:23:00,700
Ndarje vertikalisht,
ndarjen ato tavolina.

1882
01:23:00,700 --> 01:23:03,150
A nuk e lexoni të dhënat që ju nuk keni për të.

1883
01:23:03,150 --> 01:23:04,850
Të gjithë të drejtë, lojrave.

1884
01:23:04,850 --> 01:23:06,990
Ne të gjithë si lojra.

1885
01:23:06,990 --> 01:23:10,902
Së paku unë pëlqen lojra atëherë.

1886
01:23:10,902 --> 01:23:12,735
Pra, disa nga gjërat
që të merremi me të, kur

1887
01:23:12,735 --> 01:23:14,193
ne jemi duke menduar për të lojrave, e drejtë?

1888
01:23:14,193 --> 01:23:16,999
Lojrave këtyre ditëve, veçanërisht celular
lojrave, është mbi të gjitha të menduarit.

1889
01:23:16,999 --> 01:23:19,540
Dhe unë jam duke shkuar për të rrotullohen këtu një
pak larg nga DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Unë jam duke shkuar për të sjellë në
disa diskutime

1891
01:23:21,373 --> 01:23:24,240
rreth disa nga
teknologjive të tjera AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Por ideja rreth lojrave është që të mendoj
për në drejtim të TV, TV që janë,

1893
01:23:28,930 --> 01:23:31,730
në përgjithësi, HTTP dhe JSON.

1894
01:23:31,730 --> 01:23:34,550
Është mënyra se si lojrave celular lloj i
ndërveprojnë me skajet e tyre prapa.

1895
01:23:34,550 --> 01:23:35,850
Ata e bëjnë JSON postimi.

1896
01:23:35,850 --> 01:23:40,660
Ata të marrë të dhëna, dhe kjo është e gjitha,
në përgjithësi, në TV bukur JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Gjëra të tilla si të merrni miqtë, të merrni
të dhënat Fituesit, këmbimit,

1898
01:23:44,950 --> 01:23:47,699
user generated përmbajtje,
zbyth deri në sistem,

1899
01:23:47,699 --> 01:23:49,740
këto janë llojet e gjërave
se ne jemi duke shkuar për të bërë.

1900
01:23:49,740 --> 01:23:52,542
Dhënat binare pasuri, këto të dhëna
nuk mund të ulen në bazën e të dhënave.

1901
01:23:52,542 --> 01:23:54,250
Kjo mund të ulen në një
dyqan objekt, e drejtë?

1902
01:23:54,250 --> 01:23:56,541
Por baza e të dhënave do të
përfundojnë duke u thënë të sistemit,

1903
01:23:56,541 --> 01:23:59,140
thënë aplikacionin
ku të shkoni të merrni atë.

1904
01:23:59,140 --> 01:24:03,550
Dhe në mënyrë të pashmangshme, multiplayer
serverat, infrastruktura fund mbrapa,

1905
01:24:03,550 --> 01:24:06,180
dhe i projektuar për të lartë
Disponueshmëria dhe scalability.

1906
01:24:06,180 --> 01:24:09,400
Pra, këto janë gjëra që ne të gjithë duam
në infrastrukturën e lojrave sot.

1907
01:24:09,400 --> 01:24:12,160
>> Pra, le të marrin një vështrim në
ajo që duket si.

1908
01:24:12,160 --> 01:24:16,070
Got një fund core mbrapa,
shumë të thjeshtë.

1909
01:24:16,070 --> 01:24:19,880
Kemi një sistem me këtu
Zonat e shumta disponueshmërisë.

1910
01:24:19,880 --> 01:24:23,780
Kemi biseduar për AZS si being-- mendoj
prej tyre si qendra të veçanta të të dhënave.

1911
01:24:23,780 --> 01:24:26,040
Qendra e më shumë se një e të dhënave
për AZ, por kjo është në rregull,

1912
01:24:26,040 --> 01:24:28,831
thjesht mendoj se prej tyre si të dhëna të veçanta
Qendrat që janë gjeografikisht

1913
01:24:28,831 --> 01:24:30,090
dhe faji izoluar.

1914
01:24:30,090 --> 01:24:32,172
>> Ne do të kemi një
raste çift EC2.

1915
01:24:32,172 --> 01:24:33,880
Ne do të kemi
disa server fund mbrapa.

1916
01:24:33,880 --> 01:24:35,800
Ndoshta, nëse ju jeni një trashëgimi
Arkitektura, ne jemi

1917
01:24:35,800 --> 01:24:38,920
duke përdorur atë që ne e quajmë RDS,
Shërbimet e bazës së të dhënave relacionale.

1918
01:24:38,920 --> 01:24:42,040
Mund të jetë MSSQL, MySQL,
ose diçka të tillë.

1919
01:24:42,040 --> 01:24:47,080
Kjo është mënyra aplikacione shumë
janë projektuar sot.

1920
01:24:47,080 --> 01:24:49,594
>> Edhe ne mund të dëshironi të shkoni me
kjo është kur ne shkallë jashtë.

1921
01:24:49,594 --> 01:24:51,510
Ne do të shkojnë përpara dhe të vënë
kovë S3 deri atje.

1922
01:24:51,510 --> 01:24:54,200
Dhe kjo kovë S3, në vend të shërbyer
deri ato objekte nga servers-- tonë

1923
01:24:54,200 --> 01:24:55,220
ne mund të bëjmë atë.

1924
01:24:55,220 --> 01:24:57,210
Ju vënë të gjitha binare tuaj
objektet në serverat tuaj

1925
01:24:57,210 --> 01:24:59,751
dhe ju mund të përdorni ato server
raste për të shërbyer që të dhënat up.

1926
01:24:59,751 --> 01:25:01,860
Por kjo është goxha i shtrenjtë.

1927
01:25:01,860 --> 01:25:05,107
>> Mënyra më e mirë për të bëni është të shkoni përpara dhe
vënë ato objekte në një kovë S3.

1928
01:25:05,107 --> 01:25:06,315
S3 është një objekt magazinat.

1929
01:25:06,315 --> 01:25:10,860
Është e ndërtuar posaçërisht për
duke shërbyer deri këto lloje të gjërave.

1930
01:25:10,860 --> 01:25:13,690
Dhe le ata klientë të kërkojë
direkt nga ato kova objekt,

1931
01:25:13,690 --> 01:25:15,390
shkarkoj servers.

1932
01:25:15,390 --> 01:25:17,020
Pra, ne jemi duke filluar të shkallës këtu.

1933
01:25:17,020 --> 01:25:19,140
>> Tani kemi marrë përdoruesit në të gjithë botën.

1934
01:25:19,140 --> 01:25:19,730
I kam përdoruesit.

1935
01:25:19,730 --> 01:25:23,380
Unë duhet të ketë përmbajtje në nivel lokal
vendosur në afërsi të këtyre përdoruesve, e drejtë?

1936
01:25:23,380 --> 01:25:26,200
Unë kam krijuar një kovë S3
si depo e mia burim.

1937
01:25:26,200 --> 01:25:29,370
Dhe unë do para se me
shpërndarja CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront është një CD dhe a
Rrjeti ofrimit përmbajtje.

1939
01:25:31,720 --> 01:25:35,750
Në thelb ajo merr të dhënat që ju të specifikojë
dhe arka të gjitha në lidhje me internet

1940
01:25:35,750 --> 01:25:39,230
kështu që përdoruesit mund të ketë kudo
një përgjigje shumë të shpejtë, kur

1941
01:25:39,230 --> 01:25:40,960
ata kërkojnë ato objekte.

1942
01:25:40,960 --> 01:25:41,960
>> Pra, ju merrni një ide.

1943
01:25:41,960 --> 01:25:48,230
Ju jeni lloj i leveraging gjitha
aspekte të AWS këtu për të marrë këtë bërë.

1944
01:25:48,230 --> 01:25:50,790
Dhe në fund, hedhim
në një grup shkallë auto.

1945
01:25:50,790 --> 01:25:52,737
Pra instancat tona AC2
nga serverat tanë lojës,

1946
01:25:52,737 --> 01:25:54,820
si ata të fillojnë për të marrë zënë
dhe zënë dhe të zhurmshme,

1947
01:25:54,820 --> 01:25:57,236
ata do të tjerr vetëm një tjetër
shembull, tjerr një rast tjetër,

1948
01:25:57,236 --> 01:25:58,210
tjerr një tjetër shembull.

1949
01:25:58,210 --> 01:26:02,090
Pra, teknologji AWS ka, ai
ju lejon të specifikoni parametrat

1950
01:26:02,090 --> 01:26:04,650
rreth të cilit serverat tuaj do të rritet.

1951
01:26:04,650 --> 01:26:08,110
Kështu që ju mund të keni numrin n të serverëve
atje në çdo kohë të dhënë.

1952
01:26:08,110 --> 01:26:11,870
Dhe në qoftë se ngarkesa juaj shkon larg, ata do të
tkurret, numri do të tkurret.

1953
01:26:11,870 --> 01:26:15,250
Dhe në qoftë se ngarkesa vjen mbrapa,
ajo do të rritet përsëri jashtë, elastike.

1954
01:26:15,250 --> 01:26:17,050
>> Pra, kjo duket e madhe.

1955
01:26:17,050 --> 01:26:19,800
Ne kemi marrë një shumë raste EC2.

1956
01:26:19,800 --> 01:26:21,671
Ne mund të vënë në cache
front i bazave të të dhënave,

1957
01:26:21,671 --> 01:26:23,045
provoni dhe përshpejtimin bazat e të dhënave.

1958
01:26:23,045 --> 01:26:25,030
Pika tjetër presion
zakonisht njerëzit të shohin

1959
01:26:25,030 --> 01:26:28,850
është se ata shkallë një lojë duke përdorur një
sistem i bazës së të dhënave relacionale.

1960
01:26:28,850 --> 01:26:30,790
Jeez, baza e të dhënave
Performanca është e tmerrshme.

1961
01:26:30,790 --> 01:26:31,932
Si nuk kemi të përmirësuar atë?

1962
01:26:31,932 --> 01:26:33,640
Le të provoni duke
cache para se.

1963
01:26:33,640 --> 01:26:36,780
>> E pra, cache nuk funksionon
aq e madhe në lojëra, e drejtë?

1964
01:26:36,780 --> 01:26:39,330
Për lojëra, të shkruarit është e dhimbshme.

1965
01:26:39,330 --> 01:26:40,930
Lojërat janë shumë të shkruajnë e rëndë.

1966
01:26:40,930 --> 01:26:43,610
Cache nuk punon kur ju jeni
shkruaj rëndë për shkak se ju keni gjithmonë

1967
01:26:43,610 --> 01:26:44,610
mori për të rinovuar cache.

1968
01:26:44,610 --> 01:26:47,780
Ju update cache, kjo është
parëndësishme të caching.

1969
01:26:47,780 --> 01:26:49,780
Kjo është në fakt vetëm punë shtesë.

1970
01:26:49,780 --> 01:26:51,970
>> Pra, ku të shkojmë këtu?

1971
01:26:51,970 --> 01:26:54,400
Ju keni marrë një ngushtim i madh
atje poshtë në bazën e të dhënave.

1972
01:26:54,400 --> 01:26:57,661
Dhe vendi për të shkuar
padyshim është ndarjes.

1973
01:26:57,661 --> 01:26:59,410
Ndarje nuk është e
lehtë për të bërë, kur ju jeni

1974
01:26:59,410 --> 01:27:01,900
që kanë të bëjnë me bazat e të dhënave relacionale.

1975
01:27:01,900 --> 01:27:05,080
Me bazat e të dhënave relacionale, ju jeni
përgjegjës për menaxhimin, në mënyrë efektive,

1976
01:27:05,080 --> 01:27:06,210
hapësirë ​​kyç.

1977
01:27:06,210 --> 01:27:10,527
Ju jeni duke thënë përdoruesit ndërmjet A dhe M
shkoni këtu, në mes N dhe Z shkojnë atje.

1978
01:27:10,527 --> 01:27:12,360
Dhe ju jeni kalimi
të gjithë aplikimit.

1979
01:27:12,360 --> 01:27:15,000
Kështu që ju jeni që kanë të bëjnë me
ky burimi i të dhënave ndarje.

1980
01:27:15,000 --> 01:27:18,670
Ju keni kufizime transaksioneve
që nuk shtrihen ndarëse.

1981
01:27:18,670 --> 01:27:20,560
Ju keni marrë të gjitha llojet e
Çrregullimi që ju jeni

1982
01:27:20,560 --> 01:27:23,040
që kanë të bëjnë me atje poshtë duke u përpjekur
për t'u marrë me shkallë jashtë

1983
01:27:23,040 --> 01:27:25,120
dhe ndërtimin e një infrastrukture më të madhe.

1984
01:27:25,120 --> 01:27:27,284
Është vetëm më zbavitëse.

1985
01:27:27,284 --> 01:27:30,930
>> Audienca: Pra, jeni duke thënë se
rritja pikë burim përshpejton

1986
01:27:30,930 --> 01:27:31,430
procesi?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Rritja?

1988
01:27:32,513 --> 01:27:33,520
Pikat Burimi: audiencë.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: pikë Burimi?

1990
01:27:34,410 --> 01:27:37,500
Audienca: Nga informacioni,
ku informacioni vjen nga?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: Jo.

1992
01:27:38,250 --> 01:27:41,820
Ajo që unë jam duke thënë se është në rritje
Numri i ndarëse në dyqan e të dhënave

1993
01:27:41,820 --> 01:27:44,060
përmirëson xhiros.

1994
01:27:44,060 --> 01:27:48,300
Pra, çfarë po ndodh këtu është përdorues
që vijnë në radhë të EC2 deri këtu,

1995
01:27:48,300 --> 01:27:50,780
mirë, në qoftë se kam nevojë për një përdorues
Kjo është një për M, unë do të shkoj këtu.

1996
01:27:50,780 --> 01:27:53,560
Nga N të p, unë do të shkoj këtu.

1997
01:27:53,560 --> 01:27:55,060
Nga P në Z, unë do të shkoj këtu.

1998
01:27:55,060 --> 01:27:57,120
>> Audienca: OK, kështu që ata janë ato
ruajtur të gjitha në nyjet e ndryshme?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Po.

2000
01:27:57,911 --> 01:28:00,210
Mendoni e tyre si
kapanoneve të ndryshme të të dhënave.

2001
01:28:00,210 --> 01:28:01,660
Pra, ju jeni ka për të bërë këtë.

2002
01:28:01,660 --> 01:28:02,910
Nëse ju jeni duke u përpjekur për të bërë
kjo, në qoftë se ju jeni duke u përpjekur

2003
01:28:02,910 --> 01:28:05,730
në shkallë në një platformë relacionale,
kjo është ajo që ju jeni duke bërë.

2004
01:28:05,730 --> 01:28:08,100
Ju jeni duke marrë të dhënat dhe
ju jeni prerja atë poshtë.

2005
01:28:08,100 --> 01:28:10,975
Dhe ju jeni ndarjes atë në të gjithë
raste të shumta të të dhënave.

2006
01:28:10,975 --> 01:28:13,580
Dhe ju jeni menaxhimin e të gjitha që
në grupin e aplikimit.

2007
01:28:13,580 --> 01:28:14,729
Kjo është më zbavitëse.

2008
01:28:14,729 --> 01:28:15,770
Pra, çfarë duam të shkojmë?

2009
01:28:15,770 --> 01:28:20,240
Ne duan të shkojnë DynamoDB, menaxhuar plotësisht,
NoSQL ruajtur të dhënat, xhiros dispozitë.

2010
01:28:20,240 --> 01:28:22,680
Ne përdorim indekseve mesme.

2011
01:28:22,680 --> 01:28:26,154
Kjo është në thelb HTTP API dhe
përfshin mbështetje dokument.

2012
01:28:26,154 --> 01:28:28,570
Pra, ju nuk keni për t'u shqetësuar
në lidhje me ndonjë prej kësaj ndarje.

2013
01:28:28,570 --> 01:28:30,740
Ne bëjmë të gjitha për ju.

2014
01:28:30,740 --> 01:28:33,260
Deri tani, në vend të kësaj, ju
vetëm shkruani në tryezë.

2015
01:28:33,260 --> 01:28:36,490
Nëse tryezë duhet të jetë e ndarë,
që ndodh në prapaskenë.

2016
01:28:36,490 --> 01:28:40,642
Ju jeni krejtësisht e izoluar
nga se si një zhvillues.

2017
01:28:40,642 --> 01:28:42,350
Pra, le të flasim për
disa raste përdorim

2018
01:28:42,350 --> 01:28:47,564
që ne të drejtuar në në lojrave, të përbashkët
Skenarët lojrave, drejtues.

2019
01:28:47,564 --> 01:28:49,980
Pra, ju keni marrë përdoruesit që vijnë në,
të BoardNames se ata janë

2020
01:28:49,980 --> 01:28:52,930
në, rezultatet për këtë përdorues.

2021
01:28:52,930 --> 01:28:57,700
Ne mund të hashing në userid,
dhe pastaj ne kemi gamë të në lojë.

2022
01:28:57,700 --> 01:28:59,960
Kështu që çdo përdorues dëshiron të shohë
të gjitha të lojës ai ka luajtur

2023
01:28:59,960 --> 01:29:01,770
dhe tërë rezultati i tij të lartë
nëpër të gjitha lojë të.

2024
01:29:01,770 --> 01:29:04,000
Pra, kjo është Fituesit tij personal.

2025
01:29:04,000 --> 01:29:10,010
>> Tani unë dua të shkoj në dhe unë dua të get--
kështu që unë të marrë këto leaderboards personale.

2026
01:29:10,010 --> 01:29:12,827
Ajo që unë dua të bëni është të shkoni të merrni
rezultati më i lartë në të gjithë përdoruesit.

2027
01:29:12,827 --> 01:29:13,660
Pra, si mund ta bëni këtë?

2028
01:29:13,660 --> 01:29:18,070
Kur im është sheshuar në
userid, shkonin në lojë,

2029
01:29:18,070 --> 01:29:20,740
edhe unë jam duke shkuar për të shkuar përpara
dhe ristrukturimin, të krijojë një GSI,

2030
01:29:20,740 --> 01:29:22,370
dhe unë jam duke shkuar për të ristrukturuar këto të dhëna.

2031
01:29:22,370 --> 01:29:27,310
>> Tani unë jam duke shkuar për të hash mbi
BoardName, që është loja.

2032
01:29:27,310 --> 01:29:29,800
Dhe unë jam duke shkuar për të shkojnë në rezultat të lartë.

2033
01:29:29,800 --> 01:29:31,540
Dhe tani unë kam krijuar kova të ndryshme.

2034
01:29:31,540 --> 01:29:34,790
Unë jam duke përdorur të njëjtën tryezë,
të njëjtat të dhëna artikull.

2035
01:29:34,790 --> 01:29:39,870
Por unë jam duke krijuar një kovë që i jep
mua një grumbull rezultat të lartë nga loja.

2036
01:29:39,870 --> 01:29:43,180
>> Dhe unë mund të query atë tryezë
për të marrë këtë informacion.

2037
01:29:43,180 --> 01:29:50,890
Pra, unë kam vendosur se model query deri në
të mbështetet nga një indeks të mesme.

2038
01:29:50,890 --> 01:29:54,556
Tani ata mund të ndahen nga BoardName
dhe të renditura nga TopScore, në varësi.

2039
01:29:54,556 --> 01:29:57,180
Kështu që ju mund të shihni, këto janë lloje
të përdorin rasteve ju merrni në lojrave.

2040
01:29:57,180 --> 01:30:02,190
Një rast tjetër i mirë përdorim ne të merrni në lojrave
është çmime dhe që ka fituar çmime.

2041
01:30:02,190 --> 01:30:05,340
Dhe ky është një rast i madh përdorim
ku ne e quajmë indekseve rrallë.

2042
01:30:05,340 --> 01:30:07,340
Indekset rrallë janë
Aftësia për të gjeneruar

2043
01:30:07,340 --> 01:30:10,850
një indeks që nuk do të
përmbajnë çdo send të vetëm në tryezë.

2044
01:30:10,850 --> 01:30:11,470
Dhe pse jo?

2045
01:30:11,470 --> 01:30:14,540
Sepse atribut që është duke u
e indeksuar nuk ekziston në çdo send.

2046
01:30:14,540 --> 01:30:16,460
>> Pra, në këtë të veçantë
përdorni rast, unë jam duke thënë:

2047
01:30:16,460 --> 01:30:19,240
ju e dini se çfarë, unë jam duke shkuar për
të krijojë një atribut të quajtur Award.

2048
01:30:19,240 --> 01:30:22,970
Dhe unë jam duke shkuar për të dhënë çdo përdorues
se ka një çmim që ia veshin.

2049
01:30:22,970 --> 01:30:25,950
Përdoruesit që nuk kanë çmime janë
nuk do të ketë këtë atribut.

2050
01:30:25,950 --> 01:30:27,800
Kështu që, kur unë të krijuar
indeksi, vetëm përdoruesit

2051
01:30:27,800 --> 01:30:28,960
që janë duke shkuar për të treguar
deri në indeks janë

2052
01:30:28,960 --> 01:30:31,050
ato që në fakt kanë fituar çmime.

2053
01:30:31,050 --> 01:30:34,440
Pra, kjo është një mënyrë e madhe të jetë në gjendje
për të krijuar indekseve filtruar se

2054
01:30:34,440 --> 01:30:40,580
janë shumë, shumë selektive që nuk bëjnë
duhet të indeksit të gjithë tabelën.

2055
01:30:40,580 --> 01:30:43,050
>> Pra, ne jemi duke marrë ulët në kohë këtu.

2056
01:30:43,050 --> 01:30:49,190
Unë jam duke shkuar për të shkuar përpara dhe kaloni
jashtë dhe kaloni këtë skenar.

2057
01:30:49,190 --> 01:30:52,625
Flasim pak? Për

2058
01:30:52,625 --> 01:30:54,460
>> Audienca: A mund të bëj një pyetje të shpejtë?

2059
01:30:54,460 --> 01:30:56,722
Njëra është të shkruani rëndë?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Çfarë është?

2061
01:30:57,680 --> 01:30:58,596
Audienca: Shkruani rëndë.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Shkruaj rëndë.

2063
01:31:01,270 --> 01:31:03,460
Me lejo te shikoj.

2064
01:31:03,460 --> 01:31:06,220
>> Audienca: Apo është se nuk
diçka që ju mund të vetëm

2065
01:31:06,220 --> 01:31:08,809
zë për të në një kohë të shkurtër?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Ne do të shkojmë
nëpërmjet skenarit votimit.

2067
01:31:10,850 --> 01:31:11,670
Kjo nuk është edhe aq keq.

2068
01:31:11,670 --> 01:31:14,580
A ju djema keni disa minuta?

2069
01:31:14,580 --> 01:31:15,860
NE RREGULL.

2070
01:31:15,860 --> 01:31:17,890
>> Pra, ne do të flasim për votim.

2071
01:31:17,890 --> 01:31:20,250
Pra, votimi në kohë reale, ne kemi
Kërkesat për votim.

2072
01:31:20,250 --> 01:31:25,250
Kërkesat janë që ne të lejojë
çdo person të votojë vetëm një herë.

2073
01:31:25,250 --> 01:31:28,060
Ne duam që askush të jenë në gjendje
për të ndryshuar votën e tyre.

2074
01:31:28,060 --> 01:31:31,045
Ne duam kohë reale agregimin
dhe analitikë për demografinë

2075
01:31:31,045 --> 01:31:34,210
se ne do të jetë
duke treguar për përdoruesit në këtë faqe interneti.

2076
01:31:34,210 --> 01:31:35,200
>> Mendoni për këtë skenar.

2077
01:31:35,200 --> 01:31:37,550
Ne punojmë shumë realitetit
TV tregon ku ata janë

2078
01:31:37,550 --> 01:31:38,960
duke bërë këto lloj saktë të gjërave.

2079
01:31:38,960 --> 01:31:41,584
Kështu që ju mund të mendoni për skenar,
ne kemi miliona dhe miliona

2080
01:31:41,584 --> 01:31:43,959
vajzat e adoleshente atje
me telefonat e tyre celularë

2081
01:31:43,959 --> 01:31:46,250
dhe votimi dhe votimi, dhe
votimi për këdo që ata janë

2082
01:31:46,250 --> 01:31:48,610
gjetur të jetë më popullore.

2083
01:31:48,610 --> 01:31:50,830
Pra, këto janë disa nga
Kërkesat kemi drejtuar jashtë.

2084
01:31:50,830 --> 01:31:52,990
>> Dhe kështu i pari marrë
në zgjidhjen e këtij problemi

2085
01:31:52,990 --> 01:31:55,090
do të jetë për të ndërtuar një
kërkesë shumë të thjeshtë.

2086
01:31:55,090 --> 01:31:56,490
Kështu që unë kam marrë këtë app.

2087
01:31:56,490 --> 01:31:57,950
Unë kam disa votues atje.

2088
01:31:57,950 --> 01:31:59,980
Ata vijnë në, ata e goditi app votimit.

2089
01:31:59,980 --> 01:32:03,440
Unë kam marrë disa vota të papërpunuara tryezë
Unë do të hale vetëm ato vota në.

2090
01:32:03,440 --> 01:32:05,780
Unë do të keni disa agregat
vota tabelë që

2091
01:32:05,780 --> 01:32:09,490
do të bëjë analytics mia dhe demografike,
dhe ne do të vënë të gjithë këtë në atje.

2092
01:32:09,490 --> 01:32:11,420
>> Dhe kjo është e madhe.

2093
01:32:11,420 --> 01:32:12,332
Jeta eshte e mire.

2094
01:32:12,332 --> 01:32:15,040
Jeta është e mirë deri sa të gjejmë se
ka gjithmonë vetëm një ose dy

2095
01:32:15,040 --> 01:32:16,879
njerëzit që janë të njohura në zgjedhje.

2096
01:32:16,879 --> 01:32:19,420
Ka vetëm një ose dy gjëra
që njerëzit të vërtetë kujdeset për.

2097
01:32:19,420 --> 01:32:22,340
Dhe nëse ju jeni votimit në
shkallë, të gjithë një e papritur unë jam

2098
01:32:22,340 --> 01:32:26,360
do të jetë e përgatitur ferr nga
Dy kandidatë, një ose dy kandidatë.

2099
01:32:26,360 --> 01:32:29,390
Një numër shumë i kufizuar i artikujve
njerëzit të gjejnë të jenë të njohura.

2100
01:32:29,390 --> 01:32:31,710
>> Kjo nuk është një model i mirë dizajn.

2101
01:32:31,710 --> 01:32:33,549
Kjo është në fakt një
model shumë të keqe të projektimit

2102
01:32:33,549 --> 01:32:36,340
sepse ajo krijon pikërisht ajo që ne
foli për të cilin ishte çelësat e nxehtë.

2103
01:32:36,340 --> 01:32:38,960
Hot çelësat janë diçka që ne nuk i pëlqen.

2104
01:32:38,960 --> 01:32:40,470
>> Deri sa nuk kemi të rregullojmë se?

2105
01:32:40,470 --> 01:32:47,640
Dhe me të vërtetë, mënyra për të rregulluar këtë është
duke marrë ato kova kandidate

2106
01:32:47,640 --> 01:32:51,490
dhe për secilin kandidat që kemi,
ne jemi duke shkuar për append një vlerë të rastit,

2107
01:32:51,490 --> 01:32:54,192
diçka që ne e dimë, të rastit
Vlera ndërmjet një dhe 100,

2108
01:32:54,192 --> 01:32:56,620
midis 100 dhe 1,000,
ose ndërmjet një dhe 1.000,

2109
01:32:56,620 --> 01:32:59,940
megjithatë shumë vlerat e rastit qe doni te
append në fund të atij kandidati.

2110
01:32:59,940 --> 01:33:01,330
>> Dhe çfarë kam bërë me të vërtetë atëherë?

2111
01:33:01,330 --> 01:33:05,830
Nëse unë jam duke përdorur ID kandidat si
kovë të votave agregate,

2112
01:33:05,830 --> 01:33:08,780
në qoftë se unë kam shtuar një të rastit
numër në fund të se

2113
01:33:08,780 --> 01:33:12,000
Unë kam krijuar tani 10 kova, një
njëqind kova, një mijë kova

2114
01:33:12,000 --> 01:33:14,160
se unë jam përmbledhë vota në të gjithë.

2115
01:33:14,160 --> 01:33:18,030
>> Pra, unë kam miliona, dhe miliona,
dhe miliona e të dhënave që vijnë në

2116
01:33:18,030 --> 01:33:22,050
për këta kandidatë, unë tani jam duke përhapur
këto vota në të gjithë a_1 kandidatit

2117
01:33:22,050 --> 01:33:24,630
përmes A_100 kandidat, sepse
çdo herë që një votë vjen në,

2118
01:33:24,630 --> 01:33:26,530
Unë jam duke gjeneruar një të rastit
Vlera në mes një dhe 100.

2119
01:33:26,530 --> 01:33:29,446
Unë jam tacking atë mbi fund të
Kandidati që personi të votojnë për.

2120
01:33:29,446 --> 01:33:31,120
Unë jam hedhja atë në atë kovë.

2121
01:33:31,120 --> 01:33:33,910
>> Tani në pasme, unë e di
që kam marrë njëqind kova.

2122
01:33:33,910 --> 01:33:36,350
Pra, kur unë dua të shkoj përpara
dhe mbledhë votat,

2123
01:33:36,350 --> 01:33:38,244
Kam lexuar nga të gjitha ato kova.

2124
01:33:38,244 --> 01:33:39,160
Kështu që unë shkoj përpara dhe të shtoni.

2125
01:33:39,160 --> 01:33:42,410
Dhe atëherë unë do të shpërndaj mblidhen
ku të shkoj jashtë dhe të thotë hej,

2126
01:33:42,410 --> 01:33:45,399
ju e dini se çfarë, çelësi këtij kandidatit
hapësira është mbi njëqind kova.

2127
01:33:45,399 --> 01:33:47,940
Unë jam duke shkuar për të mbledhur të gjitha
vota nga ato njëqind kova.

2128
01:33:47,940 --> 01:33:49,981
Unë jam duke shkuar për të agreguar
ata dhe unë jam duke shkuar për të thënë,

2129
01:33:49,981 --> 01:33:53,830
Kandidati A tani ka
Numri total vota e x.

2130
01:33:53,830 --> 01:33:55,690
>> Tani të dy shkruaj
query dhe lexoni query

2131
01:33:55,690 --> 01:33:58,160
janë të shpërndara bukur
sepse unë jam shkrim të gjithë

2132
01:33:58,160 --> 01:34:00,320
dhe unë jam duke lexuar nëpër qindra çelësat.

2133
01:34:00,320 --> 01:34:03,500
Unë nuk jam shkrim dhe
duke lexuar nëpër një kyç tani.

2134
01:34:03,500 --> 01:34:04,950
Kështu që është një model i madh.

2135
01:34:04,950 --> 01:34:08,090
>> Kjo është në fakt ndoshta një
e dizajnit më të rëndësishme

2136
01:34:08,090 --> 01:34:10,420
internetit për shkallë në NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Ju do të shihni këtë lloj të
model të projektimit në çdo shije.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, kjo nuk ka
çështje, ne të gjithë duhet të bëjmë këtë.

2139
01:34:19,100 --> 01:34:21,840
Sepse kur ju jeni që kanë të bëjnë
me ato aggregations të mëdha,

2140
01:34:21,840 --> 01:34:26,650
ju duhet të gjej një mënyrë për të
përhapjen tyre në të gjithë kova.

2141
01:34:26,650 --> 01:34:29,512
Pra, kjo është mënyra që ju bëni atë.

2142
01:34:29,512 --> 01:34:31,220
Të gjithë të drejtë, kështu që çfarë
ju jeni duke bërë tani

2143
01:34:31,220 --> 01:34:35,252
është që ju jeni tregtare off lexoni
Kostoja për shkruani scalability.

2144
01:34:35,252 --> 01:34:37,085
Kostoja e lexoni tim është
një kompleks pak më shumë

2145
01:34:37,085 --> 01:34:40,220
dhe unë duhet të shkoj të lexuar nga një
njëqind kova në vend të një.

2146
01:34:40,220 --> 01:34:41,310
Por unë jam në gjendje për të shkruar.

2147
01:34:41,310 --> 01:34:44,860
Dhe xhiros im, shkruaj im
xhiros është e pabesueshme.

2148
01:34:44,860 --> 01:34:49,450
Pra, kjo është zakonisht një të vlefshme
Teknika për shkallë DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
ose ndonjë bazës së të dhënave NoSQL për këtë çështje.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Kështu që ne artistikisht se si të shkallës atë.

2152
01:34:55,240 --> 01:34:56,930
Dhe ne artistikisht se si për të
eliminuar çelësat e nxehtë tona.

2153
01:34:56,930 --> 01:34:57,820
Dhe kjo është fantastike.

2154
01:34:57,820 --> 01:34:58,960
Dhe kemi marrë këtë sistem të bukur.

2155
01:34:58,960 --> 01:35:02,043
Dhe kjo na ka dhënë votimin shumë korrekte
sepse ne kemi votës rekord de-dede.

2156
01:35:02,043 --> 01:35:03,130
Është e ndërtuar në DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Kemi biseduar për të drejtat e kushtëzuara.

2158
01:35:05,380 --> 01:35:08,170
>> Kur vjen një zgjedhës në, vë
një insert në tryezë,

2159
01:35:08,170 --> 01:35:11,220
ata futur me ID e votuesve,
në qoftë se ata përpiqen për të futur një tjetër votë,

2160
01:35:11,220 --> 01:35:13,320
Unë bëj një shkruaj kushtëzuar.

2161
01:35:13,320 --> 01:35:16,960
Thuaj vetëm shkruaj këtë
në qoftë se kjo nuk ekziston.

2162
01:35:16,960 --> 01:35:19,270
Pra, sa më shpejt që unë shoh se
se vota e goditi tryezë,

2163
01:35:19,270 --> 01:35:20,460
askush tjetër do të jetë
gjendje për të vënë votën e tyre në.

2164
01:35:20,460 --> 01:35:21,634
Dhe kjo është fantastike.

2165
01:35:21,634 --> 01:35:23,550
Dhe ne jemi bën rritjen
sportelet tona kandidat.

2166
01:35:23,550 --> 01:35:25,466
Dhe ne jemi duke bërë tonë
demografike dhe të gjitha këto.

2167
01:35:25,466 --> 01:35:29,110
Por çfarë ndodh nëse tim
Aplikimi bie mbi?

2168
01:35:29,110 --> 01:35:31,350
Tani të gjithë një e papritur vota
janë të vijnë në, dhe unë

2169
01:35:31,350 --> 01:35:34,840
nuk e di nëse ata janë duke u përpunuar
në analytics mia dhe demografisë

2170
01:35:34,840 --> 01:35:36,040
më.

2171
01:35:36,040 --> 01:35:38,462
Dhe kur kërkesa
vjen back up, si

2172
01:35:38,462 --> 01:35:41,420
dreqin e di se çka kanë vota
janë përpunuar dhe ku mund të fillojë?

2173
01:35:41,420 --> 01:35:44,530
>> Pra, ky është një problem i vërtetë kur ju
filloni të shikoni në këtë lloj skenari.

2174
01:35:44,530 --> 01:35:45,571
Dhe si e zgjidhim atë?

2175
01:35:45,571 --> 01:35:48,070
Ne të zgjidhur atë me atë që ne
quajmë DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Streams është një kohë urdhërohet dhe
log ndarë ndryshimi i çdo qasjes

2177
01:35:53,470 --> 01:35:55,700
në tryezë, çdo shkruani
Qasje në tryezë.

2178
01:35:55,700 --> 01:35:58,810
Çdo të dhënave që është shkruar me
Tabela tregon deri në lumë.

2179
01:35:58,810 --> 01:36:01,815
>> Kjo është në thelb një radhë 24 orë.

2180
01:36:01,815 --> 01:36:03,690
Artikuj goditi lumë,
ata jetojnë për 24 orë.

2181
01:36:03,690 --> 01:36:05,990
Ato mund të lexohet disa herë.

2182
01:36:05,990 --> 01:36:09,400
Garantuar që do të dërgohen
vetëm një herë në lumë,

2183
01:36:09,400 --> 01:36:11,180
mund të lexohet disa n herë.

2184
01:36:11,180 --> 01:36:14,910
Pra, megjithatë shumë procese qe doni te
konsumojnë se të dhënat, ju mund të konsumojnë atë.

2185
01:36:14,910 --> 01:36:16,350
Ajo do të shfaqet çdo përditësim.

2186
01:36:16,350 --> 01:36:18,455
Çdo shkruaj vetëm do
shfaqet një herë në lumë.

2187
01:36:18,455 --> 01:36:20,621
Pra, ju nuk keni për t'u shqetësuar
në lidhje me përpunimin e tij dy herë

2188
01:36:20,621 --> 01:36:22,500
nga e njëjta proces.

2189
01:36:22,500 --> 01:36:25,350
>> Është urdhëroi rreptësisht për artikull.

2190
01:36:25,350 --> 01:36:28,180
Kur themi kohë
urdhëroi dhe e ndarë,

2191
01:36:28,180 --> 01:36:30,680
ju do të shihni në ndarje në lumë.

2192
01:36:30,680 --> 01:36:33,169
Ju do të shihni artikujt, përditësimet në rregull.

2193
01:36:33,169 --> 01:36:35,210
Ne nuk jemi të garantuar
në lumë që ju jeni

2194
01:36:35,210 --> 01:36:40,240
do të merrni çdo transaksion
në mënyrë që të gjithë artikujve.

2195
01:36:40,240 --> 01:36:42,440
>> Pra streams janë idempotent.

2196
01:36:42,440 --> 01:36:44,037
A ne të gjithë e dimë se çfarë do të thotë idempotent?

2197
01:36:44,037 --> 01:36:46,620
Idempotent do të thotë që ju mund të bëni atë
mbi dhe mbi dhe mbi përsëri.

2198
01:36:46,620 --> 01:36:48,200
Rezultati do të jetë e njëjtë.

2199
01:36:48,200 --> 01:36:49,991
>> Streams janë idempotent,
por ata duhet të jenë të

2200
01:36:49,991 --> 01:36:54,860
luajtur nga pika e fillimit,
kudo që ju zgjidhni, deri në fund,

2201
01:36:54,860 --> 01:36:57,950
ose ata nuk do të rezultojë
në të njëjtat vlera.

2202
01:36:57,950 --> 01:36:59,727
>> E njëjta gjë me MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB ka një konstrukt
ata e quajnë oplog.

2204
01:37:01,560 --> 01:37:04,140
Është e njëjta konstrukt saktë.

2205
01:37:04,140 --> 01:37:06,500
Shumë Bazat e të dhënave NoSQL
kanë këtë konstrukt.

2206
01:37:06,500 --> 01:37:08,790
Ata e përdorin atë për të bërë gjëra të
si përsëritje, e cila

2207
01:37:08,790 --> 01:37:10,475
është pikërisht ajo që ne bëjmë me lumenj.

2208
01:37:10,475 --> 01:37:12,350
Audienca: Ndoshta një
pyetje heretike, por ju

2209
01:37:12,350 --> 01:37:13,975
flasim për Apps bërë poshtë një kështu me radhë.

2210
01:37:13,975 --> 01:37:16,089
Janë streams garantuara për
kurrë ndoshta të shkojnë poshtë?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Po, përrenjve
janë të garantuara për të nuk shkojnë poshtë.

2212
01:37:18,630 --> 01:37:21,040
Ne menaxhuar infrastrukturën
prapa. streams automatikisht

2213
01:37:21,040 --> 01:37:22,498
vendoset në grupin e tyre shkallë auto.

2214
01:37:22,498 --> 01:37:25,910
Ne do të kalojnë nëpër pak
bit për atë që ndodh.

2215
01:37:25,910 --> 01:37:30,060
>> Unë nuk duhet të thonë se ata nuk janë të
të garantuara për të nuk shkojnë poshtë.

2216
01:37:30,060 --> 01:37:33,110
Elementet janë të garantuara
për të dalë në lumë.

2217
01:37:33,110 --> 01:37:36,740
Dhe lumë do të jetë i mundshëm.

2218
01:37:36,740 --> 01:37:40,580
Pra, çfarë shkon poshtë ose kthehet
up, kjo ndodh nën.

2219
01:37:40,580 --> 01:37:43,844
Është covers-- është në rregull.

2220
01:37:43,844 --> 01:37:46,260
Të gjithë të drejtë, kështu që ju të merrni të ndryshme
Llojet pamje jashtë ekranit.

2221
01:37:46,260 --> 01:37:51,040
Llojet pikëpamje që janë të rëndësishme për një
programues zakonisht janë, çfarë ishte ajo?

2222
01:37:51,040 --> 01:37:52,370
Unë të marrë pamje të vjetër.

2223
01:37:52,370 --> 01:37:55,630
Kur një përditësim hits tryezë, ajo do të
shtytje pikëpamjen e vjetër në lumë

2224
01:37:55,630 --> 01:38:02,070
kështu që të dhënat mund të arkivit, ose ndryshim
kontrollit, identifikimi ndryshim, ndryshim

2225
01:38:02,070 --> 01:38:03,600
menaxhimit.

2226
01:38:03,600 --> 01:38:07,160
>> Imazhi i ri, ajo që tani është pas
update, kjo është një tjetër lloj i mendimit

2227
01:38:07,160 --> 01:38:07,660
ju mund të merrni.

2228
01:38:07,660 --> 01:38:09,660
Ju mund të merrni të dy imazhe të vjetra dhe të reja.

2229
01:38:09,660 --> 01:38:10,660
Ndoshta unë dua ata të dy.

2230
01:38:10,660 --> 01:38:11,790
Unë dua të shoh se çfarë ishte.

2231
01:38:11,790 --> 01:38:13,290
Unë dua të shoh se çfarë ndryshoi në.

2232
01:38:13,290 --> 01:38:15,340
>> Unë kam një lloj të pajtueshmërisë
e procesit që shkon.

2233
01:38:15,340 --> 01:38:17,430
Ajo ka nevojë për të verifikuar se
kur këto gjëra ndryshojnë,

2234
01:38:17,430 --> 01:38:21,840
se ata janë brenda kufijve të caktuar
ose brenda parametrave të caktuara.

2235
01:38:21,840 --> 01:38:23,840
>> Dhe pastaj ndoshta unë vetëm
duhet të dinë se çfarë ka ndryshuar.

2236
01:38:23,840 --> 01:38:26,240
Unë nuk bëj kujdes atë artikull ndryshuar.

2237
01:38:26,240 --> 01:38:28,580
Unë nuk kam nevojë për të duhet të dini
çfarë atributet ndryshuar.

2238
01:38:28,580 --> 01:38:30,882
Unë vetëm duhet të dini se
sendet janë duke u prekur.

2239
01:38:30,882 --> 01:38:33,340
Pra, këto janë llojet e pikëpamjeve
që ju të merrni jashtë lumë

2240
01:38:33,340 --> 01:38:35,960
dhe ju mund të ndërveprojnë me të.

2241
01:38:35,960 --> 01:38:37,840
>> Aplikacioni që
konsumon lumë,

2242
01:38:37,840 --> 01:38:39,298
kjo është lloj i mënyrës kjo funksionon.

2243
01:38:39,298 --> 01:38:42,570
Klienti DynamoDB kërkojë për
shtytje të dhëna në tabelat.

2244
01:38:42,570 --> 01:38:44,750
Streams vendosur në atë që ne e quajmë shards.

2245
01:38:44,750 --> 01:38:47,380
Shards janë shkallëzuar
në mënyrë të pavarur të tabelës.

2246
01:38:47,380 --> 01:38:50,660
Ata nuk të vijë deri plotësisht
në ndarëse e tryezën tuaj.

2247
01:38:50,660 --> 01:38:52,540
Dhe arsyeja pse është e
sepse ata vargoj

2248
01:38:52,540 --> 01:38:55,430
të kapacitetit, aktuale
Kapaciteti i tabelës.

2249
01:38:55,430 --> 01:38:57,600
>> Ata vendosë në e tyre
vet grupi madhesise auto,

2250
01:38:57,600 --> 01:39:00,800
dhe ata fillojnë të tjerr jashtë në varësi
për sa shkruan po vijnë në,

2251
01:39:00,800 --> 01:39:03,090
Sa reads-- me të vërtetë është e shkruan.

2252
01:39:03,090 --> 01:39:05,820
Nuk ka reads-- por si
shumë shkruan po vijnë në.

2253
01:39:05,820 --> 01:39:08,200
>> Dhe pastaj në anën e pasme
fund, ne kemi atë që ne

2254
01:39:08,200 --> 01:39:11,390
thërrasë një KCL, ose kinesis Klienti Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis është një lumë të dhënave
Teknologjia e përpunimit nga Amazon.

2256
01:39:19,190 --> 01:39:22,040
Dhe lumenj është e ndërtuar mbi atë.

2257
01:39:22,040 --> 01:39:25,670
>> Kështu që ju përdorni një KCL aktivizuar
Aplikimi për të lexuar derdhet.

2258
01:39:25,670 --> 01:39:28,752
Klienti Biblioteka kinesis fakt
menaxhon punëtorët për ju.

2259
01:39:28,752 --> 01:39:30,460
Dhe ai gjithashtu ka disa
gjëra interesante.

2260
01:39:30,460 --> 01:39:35,630
Kjo do të krijojë disa tabela lart
në tablespace tuaj DynamoDB

2261
01:39:35,630 --> 01:39:38,410
për të gjetur sende të cilat
janë përpunuar.

2262
01:39:38,410 --> 01:39:41,190
Pra, në këtë mënyrë, nëse ajo bie përsëri, në qoftë se
ajo bie mbi dhe vjen dhe merr

2263
01:39:41,190 --> 01:39:45,570
u back up, ajo mund të përcaktojë se ku
ishte ajo në përpunimin lumë.

2264
01:39:45,570 --> 01:39:48,360
>> Kjo është shumë e rëndësishme kur
ju jeni duke folur për përsëritje.

2265
01:39:48,360 --> 01:39:50,350
Unë duhet të dini se çfarë
dhënave u janë përpunuar

2266
01:39:50,350 --> 01:39:52,810
dhe çfarë të dhëna ende të përpunohen.

2267
01:39:52,810 --> 01:39:57,380
Pra, biblioteka KCL për rrjedhat do të
t'ju japë një shumë të këtij funksionalitetit.

2268
01:39:57,380 --> 01:39:58,990
Ai kujdeset për të gjithë shtëpisë së.

2269
01:39:58,990 --> 01:40:01,140
Ajo qëndron një punëtor për çdo copë e thyer.

2270
01:40:01,140 --> 01:40:04,620
Ajo krijon një tryezë administrative
për çdo copë e thyer, për çdo punëtor.

2271
01:40:04,620 --> 01:40:07,560
Dhe si ata punëtorë zjarr,
ata mbajnë ato tavolina

2272
01:40:07,560 --> 01:40:10,510
kështu që ju e dini këtë rekord
u lexuar dhe përpunuar.

2273
01:40:10,510 --> 01:40:13,850
Dhe pastaj në këtë mënyrë nëse procesi
vdes dhe kthehet në internet,

2274
01:40:13,850 --> 01:40:17,940
ajo mund të rifillojë të drejtë ku ajo mori hov.

2275
01:40:17,940 --> 01:40:20,850
>> Pra, ne i përdorim këtë për
përsëritje ndër-rajon.

2276
01:40:20,850 --> 01:40:24,680
Një shumë e konsumatorëve kanë nevojën për
të lëvizin të dhënat apo pjesë të tabelave të të dhënave të tyre

2277
01:40:24,680 --> 01:40:25,920
rreth në rajone të ndryshme.

2278
01:40:25,920 --> 01:40:29,230
Ka nëntë rajone
e gjithë bota.

2279
01:40:29,230 --> 01:40:32,100
Pra, nuk mund të jetë një unë need--
mund të ketë përdorues në Azi, përdoruesit

2280
01:40:32,100 --> 01:40:34,150
në Bregdetin Lindor të Shteteve të Bashkuara.

2281
01:40:34,150 --> 01:40:38,980
Ata kanë të dhëna të ndryshme që
duhet të shpërndahen në nivel lokal.

2282
01:40:38,980 --> 01:40:42,510
Dhe ndoshta një përdorues fluturon nga
Azi gjatë në Shtetet e Bashkuara,

2283
01:40:42,510 --> 01:40:45,020
dhe unë dua të përsëris
të dhënat e tij.

2284
01:40:45,020 --> 01:40:49,340
Pra, kur ai merr nga avioni, ai ka
një përvojë e mirë duke përdorur aplikacionin e tij celular.

2285
01:40:49,340 --> 01:40:52,360
>> Ju mund të përdorni ndër-rajonin
Biblioteka përsëritje për të bërë këtë.

2286
01:40:52,360 --> 01:40:55,730
Në thelb ne kemi
dhënë dy teknologjive.

2287
01:40:55,730 --> 01:40:59,400
Një është një aplikim i konsol ju mund të
të qëndrojë deri në vetë shembull tuaj EC2.

2288
01:40:59,400 --> 01:41:01,240
Ajo shkon përsëritje të pastër.

2289
01:41:01,240 --> 01:41:02,720
Dhe pastaj ne ju dha bibliotekën.

2290
01:41:02,720 --> 01:41:06,070
Biblioteka ju mund të përdorni për të ndërtuar
aplikimi juaj nëse ju

2291
01:41:06,070 --> 01:41:10,740
duan të bëjnë gjëra të çmendur me që data--
filtër, përsëris vetëm një pjesë të saj,

2292
01:41:10,740 --> 01:41:14,120
rrotullohen dhënat, lëvizin atë në një
tavolinë të ndryshme, kështu me radhë e kështu me radhë.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Pra, kjo është lloj i asaj që duket si.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams mund të jetë
përpunuara nga ajo që ne e quajmë lambda.

2296
01:41:23,690 --> 01:41:27,394
Ne kemi përmendur pak për ngjarjen
shtyrë arkitektura e aplikimit.

2297
01:41:27,394 --> 01:41:28,810
Lambda është një komponent kyç i kësaj.

2298
01:41:28,810 --> 01:41:32,840
Lambda është kodi që zjarret në kërkesën
në përgjigje të një ngjarjeje të veçantë.

2299
01:41:32,840 --> 01:41:36,020
Një nga këto ngjarje mund të jetë një
rekord shfaqeshin në lumë.

2300
01:41:36,020 --> 01:41:39,100
Nëse një rekord shfaqet në lumë,
ne do të thërrasë këtë funksion Java.

2301
01:41:39,100 --> 01:41:44,980
E pra, kjo është e JavaScript, dhe Lambda
mbështet Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
dhe do të mbështesë së shpejti
gjuhët e tjera si edhe.

2303
01:41:47,820 --> 01:41:50,940
Dhe mjaftonte për të thënë, kjo është kodi i pastër.

2304
01:41:50,940 --> 01:41:53,610
shkruaj Në Java, ju përcaktoni një klasë.

2305
01:41:53,610 --> 01:41:55,690
Ju shtyjnë jar lart në lambda.

2306
01:41:55,690 --> 01:42:00,200
Dhe pastaj ju specifikoni cilat klasë
për të thirrur në përgjigje të cilën ngjarje.

2307
01:42:00,200 --> 01:42:04,770
Dhe pastaj infrastruktura Lambda
pas se do të kandidojë atë kod.

2308
01:42:04,770 --> 01:42:06,730
>> Se kodi mund të procesit
të dhënat off lumë.

2309
01:42:06,730 --> 01:42:08,230
Ajo mund të bëjë asgjë ajo dëshiron me të.

2310
01:42:08,230 --> 01:42:11,650
Në këtë shembull të veçantë, të gjithë ne jemi
të vërtetë duke bërë është prerjet atributet.

2311
01:42:11,650 --> 01:42:13,480
Por kjo është vetëm kod.

2312
01:42:13,480 --> 01:42:15,260
Kodi mund të bëjë asgjë, e drejtë?

2313
01:42:15,260 --> 01:42:16,600
>> Kështu që ju mund të rrotullohen ato të dhëna.

2314
01:42:16,600 --> 01:42:18,160
Ju mund të krijoni një pamje derivat.

2315
01:42:18,160 --> 01:42:21,160
Në qoftë se kjo është një strukturë dokument,
ju mund të shkatërroj strukturën.

2316
01:42:21,160 --> 01:42:24,300
Ju mund të krijoni indekseve alternative.

2317
01:42:24,300 --> 01:42:27,100
Të gjitha llojet e gjërave që ju mund
bëjnë me rrjedhat DynamoDB.

2318
01:42:27,100 --> 01:42:28,780
>> Dhe me të vërtetë, kjo është ajo që duket si.

2319
01:42:28,780 --> 01:42:29,940
Pra, ju merrni ato më të reja që vijnë në.

2320
01:42:29,940 --> 01:42:31,190
Ata po vijnë jashtë string.

2321
01:42:31,190 --> 01:42:32,720
Ata janë lexuar nga funksioni lambda.

2322
01:42:32,720 --> 01:42:37,480
Ata po rradhës të dhënat dhe
shtyjnë atë deri në tabelat derivative,

2323
01:42:37,480 --> 01:42:42,200
njoftuar sistemeve të jashtëm të ndryshimit,
dhe shtyn të dhënat në ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Ne biseduam rreth asaj se si për të vënë në cache
në frontin e bazën e të dhënave për atë shitje

2325
01:42:45,900 --> 01:42:46,450
skenar.

2326
01:42:46,450 --> 01:42:50,049
E pra çfarë ndodh në qoftë se unë
update përshkrimin artikull?

2327
01:42:50,049 --> 01:42:52,340
E pra, në qoftë se kam pasur një Lambda
Funksioni kandidon në këtë tryezë,

2328
01:42:52,340 --> 01:42:55,490
në qoftë se unë të rinovuar përshkrimin pika, ajo do të
marr rekordin off lumë,

2329
01:42:55,490 --> 01:42:58,711
dhe ajo do update ElastiCache
shembull me të dhënat e reja.

2330
01:42:58,711 --> 01:43:00,460
Pra, kjo është një shumë e
Çfarë bëjmë ne me lambda.

2331
01:43:00,460 --> 01:43:02,619
Kjo është kodi zam, lidhje.

2332
01:43:02,619 --> 01:43:04,410
Dhe kjo në fakt i jep
aftësia për të nisur

2333
01:43:04,410 --> 01:43:07,930
dhe për të drejtuar kërkesat shumë komplekse
pa një server të dedikuar

2334
01:43:07,930 --> 01:43:10,371
infrastruktura, e cila është me të vërtetë cool.

2335
01:43:10,371 --> 01:43:13,100
>> Pra, le të kthehemi në tonë
kohë reale arkitekturës votimit.

2336
01:43:13,100 --> 01:43:17,984
Kjo është e re dhe e përmirësuar me tonë
lumenj dhe KCL aktivizuar aplikacionin.

2337
01:43:17,984 --> 01:43:20,150
Njësoj si më parë, ne mund të
të trajtojë çdo shkallën e zgjedhjeve.

2338
01:43:20,150 --> 01:43:21,100
Ne si kjo.

2339
01:43:21,100 --> 01:43:24,770
Ne jemi duke bërë jashtë grumbullon shpërndaj
nëpër kova të shumta.

2340
01:43:24,770 --> 01:43:26,780
Ne kemi marrë mbyllje optimist në vazhdim e sipër.

2341
01:43:26,780 --> 01:43:30,192
Ne mund të mbajë votuesit tanë
nga ndryshimi votat e tyre.

2342
01:43:30,192 --> 01:43:31,400
Ata mund të votojnë vetëm vetëm një herë.

2343
01:43:31,400 --> 01:43:32,880
Kjo është fantastike.

2344
01:43:32,880 --> 01:43:35,895
Toleranca faji në kohë reale,
grumbullimi shkallëzuar tani.

2345
01:43:35,895 --> 01:43:38,270
Kjo gjë bie mbi, atë
e di se ku për të rifilluar veten

2346
01:43:38,270 --> 01:43:41,300
kur ajo vjen përsëri për shkak
ne jemi duke përdorur app OAK.

2347
01:43:41,300 --> 01:43:45,700
Dhe pastaj ne gjithashtu mund të përdorin atë
Aplikimi KCL për të nxitur e të dhënave nga

2348
01:43:45,700 --> 01:43:48,820
për RedShift për tjetrin
analytics app, ose të përdorë

2349
01:43:48,820 --> 01:43:51,990
të MapReduce elastik për të drejtuar
në kohë reale streaming aggregations off

2350
01:43:51,990 --> 01:43:53,180
e këto të dhëna.

2351
01:43:53,180 --> 01:43:55,480
>> Pra, këto janë gjëra që ne
nuk kanë folur për shumë.

2352
01:43:55,480 --> 01:43:57,375
Por ata janë shtesë
teknologjitë që vijnë

2353
01:43:57,375 --> 01:44:00,310
të mbajnë kur ju jeni në kërkim
në këto lloje të skenarëve.

2354
01:44:00,310 --> 01:44:03,160
>> Të gjithë të drejtë, kështu që kjo është në lidhje
analytics me DynamoDB streams.

2355
01:44:03,160 --> 01:44:05,340
Ju mund të mbledhë de-dede
të dhënat, të bëjë të gjitha llojet

2356
01:44:05,340 --> 01:44:09,490
e gjëra të këndshme, të dhëna të përgjithshme në
kujtesës, të krijojë këto tavolina të rrjedhura.

2357
01:44:09,490 --> 01:44:13,110
Ky është një rast i madh përdorim
se një shumë e konsumatorëve

2358
01:44:13,110 --> 01:44:16,950
janë të përfshirë me të, duke marrë mbivendosur
Pronat e këtyre dokumenteve JSON

2359
01:44:16,950 --> 01:44:18,946
dhe krijimin e indekseve të tjera.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Ne jemi në fund.

2362
01:44:23,150 --> 01:44:26,689
Faleminderit për duke pasur me mua.

2363
01:44:26,689 --> 01:44:28,480
Pra, le të flasim për
Arkitektura referencë.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB ulet në mes të kaq
shumë e infrastrukturës AWS.

2365
01:44:33,440 --> 01:44:37,090
Në thelb ju mund të lidh atë
deri në çdo gjë që ju dëshironi.

2366
01:44:37,090 --> 01:44:45,600
Aplikime ndërtuar duke përdorur Dynamo përfshijnë
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
shtytje të dhënave jashtë në Elastike
MapReduce, eksport-import nga DynamoDB

2368
01:44:49,890 --> 01:44:52,370
në S3, të gjitha llojet e menu.

2369
01:44:52,370 --> 01:44:54,120
Por ndoshta më e mira
gjë për të folur në lidhje me,

2370
01:44:54,120 --> 01:44:56,119
dhe kjo është ajo që është me të vërtetë
interesante është kur ne

2371
01:44:56,119 --> 01:44:58,350
flasim për ngjarje të shtyrë aplikacioneve.

2372
01:44:58,350 --> 01:45:00,300
>> Ky është një shembull i
një projekti të brendshëm

2373
01:45:00,300 --> 01:45:04,850
që kemi se ku ne jemi në fakt
botuese të mbledhur rezultatet e anketës.

2374
01:45:04,850 --> 01:45:07,700
Pra, në një lidhje email që
kemi dërguar jashtë, nuk do të

2375
01:45:07,700 --> 01:45:11,350
të jetë një klik pak lidhje thënë
këtu për t'iu përgjigjur anketës.

2376
01:45:11,350 --> 01:45:14,070
Dhe kur një person klikime
që lidhen, çfarë ndodh

2377
01:45:14,070 --> 01:45:18,020
është se ata shemb një të sigurt
Forma HTML studim nga S3.

2378
01:45:18,020 --> 01:45:18,980
Nuk ka server.

2379
01:45:18,980 --> 01:45:20,600
Kjo është vetëm një objekt S3.

2380
01:45:20,600 --> 01:45:22,770
>> Kjo formë vjen deri,
ngarkesa deri në shfletuesin.

2381
01:45:22,770 --> 01:45:24,240
Atë e mori shtyllë.

2382
01:45:24,240 --> 01:45:30,160
Atë e mori kompleks JavaScript
se është e running.

2383
01:45:30,160 --> 01:45:33,557
Pra, kjo është kërkesë shumë e pasur
drejtimin në shfletuesin e klientit.

2384
01:45:33,557 --> 01:45:36,390
Ata nuk e dinë se ata nuk janë
bashkëveprojmë me një server mbrapa fund.

2385
01:45:36,390 --> 01:45:38,220
Në këtë pikë, kjo është e gjitha shfletues.

2386
01:45:38,220 --> 01:45:41,780
>> Ata publikojnë rezultatet në çfarë
ne e quajmë Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway është thjesht një web API
që ju mund të përcaktojë dhe të lidh

2388
01:45:46,270 --> 01:45:47,760
për çdo gjë që ju dëshironi.

2389
01:45:47,760 --> 01:45:50,990
Në këtë rast të veçantë, ne jemi
përkulur deri në një funksion lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Pra, operacion ime POST është
ndodh me asnjë server.

2391
01:45:54,797 --> 01:45:56,380
Në thelb kjo API Gateway ulet atje.

2392
01:45:56,380 --> 01:45:58,770
Ajo kushton më asgjë derisa njerëzit
fillojnë postimi atë, e drejtë?

2393
01:45:58,770 --> 01:46:00,269
Funksioni Lambda vetëm ulet atje.

2394
01:46:00,269 --> 01:46:03,760
Dhe kjo më kushton asgjë deri
njerëzit fillojnë të goditur atë.

2395
01:46:03,760 --> 01:46:07,270
Kështu që ju mund të shihni, si vëllimit
rritet, kjo është kur akuzat vijnë.

2396
01:46:07,270 --> 01:46:09,390
Unë nuk jam drejtimin e një server 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Kështu që unë tërheq formularin
poshtë nga kovë,

2398
01:46:12,310 --> 01:46:15,719
dhe unë postoni përmes API
Portë në funksion lambda.

2399
01:46:15,719 --> 01:46:17,510
Dhe pastaj Lambda
funksion thotë, ju e dini

2400
01:46:17,510 --> 01:46:20,600
çfarë, unë kam marrë disa PIIs, disa
personalisht të identifikueshme

2401
01:46:20,600 --> 01:46:21,480
në këto përgjigje.

2402
01:46:21,480 --> 01:46:23,020
Kam marrë komente që vijnë nga përdoruesit.

2403
01:46:23,020 --> 01:46:24,230
Unë kam marrë adresat e-mail.

2404
01:46:24,230 --> 01:46:26,190
Unë kam marrë përdoruesve.

2405
01:46:26,190 --> 01:46:27,810
>> Më lejoni të ndarë këtë off.

2406
01:46:27,810 --> 01:46:30,280
Unë jam duke shkuar për të gjeneruar disa
metadata off këtë rekord.

2407
01:46:30,280 --> 01:46:32,850
Dhe unë jam duke shkuar për të shtyjë
metadata në DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Dhe unë mund të encrypt të gjitha të dhënat
dhe të shtyjë atë në DynamoDB qoftë se unë dua.

2409
01:46:36,059 --> 01:46:38,600
Por është më e lehtë për mua, në këtë
përdorin çështjen, për të shkuar përpara një rol,

2410
01:46:38,600 --> 01:46:42,800
Unë jam duke shkuar për të nxitur të dhënat e papërpunuara
në një kovë të koduar S3.

2411
01:46:42,800 --> 01:46:47,240
Kështu që unë përdorin ndërtuar në S3 anën e serverit
encryption dhe Menaxhimi Key Amazon

2412
01:46:47,240 --> 01:46:51,600
Shërbim kështu që unë kam një çelës që
mund të rrotullohen në një interval të rregullt,

2413
01:46:51,600 --> 01:46:55,010
dhe unë mund të mbrojë se të dhënat PII
si pjesë e tërë këtij punës.

2414
01:46:55,010 --> 01:46:55,870
>> Pra, çfarë kam bërë?

2415
01:46:55,870 --> 01:47:00,397
Unë kam vendosur vetëm një e tërë
aplikimit, dhe unë nuk kam asnjë server.

2416
01:47:00,397 --> 01:47:02,980
Pra, është ajo ngjarje të shtyrë zbatimin
Arkitektura bën për ju.

2417
01:47:02,980 --> 01:47:05,730
>> Tani në qoftë se ju mendoni rreth
rasti përdorimi për this--

2418
01:47:05,730 --> 01:47:08,730
ne kemi klientët e tjerë unë jam duke folur
në lidhje me këtë arkitekturë saktë që

2419
01:47:08,730 --> 01:47:14,560
drejtuar fushata phenomenally të mëdha, të cilët
janë duke kërkuar në këtë dhe duke shkuar, oh my.

2420
01:47:14,560 --> 01:47:17,840
Sepse tani, ata mund
në thelb të shtyjë atë atje,

2421
01:47:17,840 --> 01:47:21,900
le se fushatë të rrimë
aty deri sa nis, dhe jo

2422
01:47:21,900 --> 01:47:24,400
duhet të shqetësohen një fik për
çfarë lloj i infrastrukturës

2423
01:47:24,400 --> 01:47:26,120
do të jetë atje për të mbështetur atë.

2424
01:47:26,120 --> 01:47:28,600
Dhe pastaj sa më shpejt
se fushata është bërë,

2425
01:47:28,600 --> 01:47:31,520
kjo është si të infrastrukturës
vetëm menjëherë shkon larg

2426
01:47:31,520 --> 01:47:33,680
sepse ka të vërtetë
ka infrastrukturë.

2427
01:47:33,680 --> 01:47:35,660
Është kodi vetëm që ulet në lambda.

2428
01:47:35,660 --> 01:47:38,560
Është dhënat vetëm që ulet në DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Kjo është një mënyrë e mrekullueshme
për të ndërtuar aplikime.

2430
01:47:41,340 --> 01:47:43,970
>> Audienca: Pra, është ajo më shumë
jetëshkurtër se ajo do të jetë

2431
01:47:43,970 --> 01:47:45,740
në qoftë se ajo është ruajtur në një server të vërtetë?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Absolutisht.

2433
01:47:46,823 --> 01:47:49,190
Sepse këtë server shembull
do të duhet të jetë një 7/24.

2434
01:47:49,190 --> 01:47:51,954
Ajo duhet të jetë në dispozicion për
dikush për t'iu përgjigjur.

2435
01:47:51,954 --> 01:47:52,620
Well guess what?

2436
01:47:52,620 --> 01:47:55,410
S3 është në dispozicion 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 gjithmonë përgjigjet.

2438
01:47:57,100 --> 01:47:59,320
Dhe S3 është shumë, shumë i mirë
që shërbejnë up objekte.

2439
01:47:59,320 --> 01:48:02,590
Ato objekte mund të jetë fotografi HTML, ose
Fotografi JavaScript, ose çdo gjë që ju dëshironi.

2440
01:48:02,590 --> 01:48:07,430
Ju mund të drejtuar kërkesat shumë të pasur web
nga kovat S3, dhe njerëzit bëjnë.

2441
01:48:07,430 --> 01:48:10,160
>> Dhe kështu kjo është ideja këtu
është për të marrë larg nga rruga

2442
01:48:10,160 --> 01:48:11,270
kemi përdorur për të mendoj për atë.

2443
01:48:11,270 --> 01:48:14,270
Ne të gjithë e përdorur për të mendoj në
Kushtet e servers dhe pret.

2444
01:48:14,270 --> 01:48:16,580
Kjo nuk është për atë më.

2445
01:48:16,580 --> 01:48:19,310
Është në lidhje me infrastrukturën si kod.

2446
01:48:19,310 --> 01:48:22,470
Vendosë kodin në cloud dhe
le të reja të kandidojë atë për ju.

2447
01:48:22,470 --> 01:48:24,980
Dhe kjo është ajo që AWS është duke u përpjekur për të bërë.

2448
01:48:24,980 --> 01:48:29,690
>> Audienca: Pra kutinë tuaj të artë në mes
i API Gateway nuk është server-si,

2449
01:48:29,690 --> 01:48:30,576
por në vend të kësaj është just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Ju mund të mendoni
atë si server fasadë.

2451
01:48:32,850 --> 01:48:38,040
Të gjitha ajo është është ajo do të marrë një HTTP
kërkojnë dhe hartë atë në një tjetër proces.

2452
01:48:38,040 --> 01:48:39,192
Kjo është e gjitha ajo ka.

2453
01:48:39,192 --> 01:48:41,525
Dhe në këtë rast, ne jemi hartes
ajo në një funksion lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Të gjithë të drejtë, kështu që kjo është e gjitha që kam marrë.

2456
01:48:45,410 --> 01:48:46,190
Faleminderit shumë.

2457
01:48:46,190 --> 01:48:46,800
E vleresoj.

2458
01:48:46,800 --> 01:48:48,100
Unë e di se ne duam pak me kalimin e kohës.

2459
01:48:48,100 --> 01:48:49,980
Dhe shpresojmë se ju djema mori
pak e informacionit

2460
01:48:49,980 --> 01:48:51,410
që ju mund të marr me vete sot.

2461
01:48:51,410 --> 01:48:53,520
Dhe unë kërkoj falje në qoftë se unë shkova
mbi disa nga kokat tuaja,

2462
01:48:53,520 --> 01:48:56,697
por ka një shumë të mirë të
Njohuri themelore themelore

2463
01:48:56,697 --> 01:48:58,280
që unë mendoj se është shumë e vlefshme për ju.

2464
01:48:58,280 --> 01:48:59,825
Pra, ju falënderoj për të pasur mua.

2465
01:48:59,825 --> 01:49:00,325
[Duartrokitje]

2466
01:49:00,325 --> 01:49:02,619
Audienca: [padëgjueshme]
është kur ju ishin duke thënë

2467
01:49:02,619 --> 01:49:05,160
keni pasur për të shkuar nëpërmjet gjë
që nga fillimi deri në fund

2468
01:49:05,160 --> 01:49:07,619
për të marrë vlerat e duhura
ose të njëjtat vlera,

2469
01:49:07,619 --> 01:49:09,410
si do vlerat
të ndryshojë në qoftë se [e padëgjueshme].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Si do të ndryshojë vlerat?

2472
01:49:11,800 --> 01:49:15,180
E pra, sepse në qoftë se unë nuk e drejtuar
kjo të gjithë rrugën deri në fund,

2473
01:49:15,180 --> 01:49:19,770
atëherë unë nuk e di se çfarë ndryshon
janë bërë në milje e fundit.

2474
01:49:19,770 --> 01:49:22,144
Kjo nuk do të jetë
të dhënat e njëjtë me atë që pashë.

2475
01:49:22,144 --> 01:49:24,560
Audienca: Oh, kështu që ju vetëm
nuk kanë marrë të gjithë input.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: E drejta.

2477
01:49:24,770 --> 01:49:26,895
Ju keni për të shkuar nga fillimi
deri në fund, dhe pastaj është

2478
01:49:26,895 --> 01:49:29,280
do të jetë një shtet i qëndrueshëm.

2479
01:49:29,280 --> 01:49:31,520
Ftohtë.

2480
01:49:31,520 --> 01:49:35,907
>> Audienca: Pra, ju na tregoi DynamoDB
mund të bëjë dokument apo vlerën kyç.

2481
01:49:35,907 --> 01:49:38,740
Dhe kemi shpenzuar shumë kohë në
Vlera e kyç me një hash dhe mënyrat

2482
01:49:38,740 --> 01:49:40,005
për të rrokullisje atë rreth.

2483
01:49:40,005 --> 01:49:43,255
Kur keni shikuar në ato tavolina, është se
duke lënë prapa qasjen e dokumenteve?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: Unë nuk do të
thonë se e lënë atë prapa.

2485
01:49:44,600 --> 01:49:45,855
>> Audienca: Ata ishin ndarë nga the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Me dokumentin
qasja, lloji dokumenti në DynamoDB

2487
01:49:49,140 --> 01:49:50,880
është vetëm e mendojmë si një atribut.

2488
01:49:50,880 --> 01:49:53,560
Kjo është një atribut që përmban
një strukturë hierarkike të dhënave.

2489
01:49:53,560 --> 01:49:56,980
Dhe pastaj në pyetje,
ju mund të përdorni pronat

2490
01:49:56,980 --> 01:49:59,480
e këtyre objekteve duke përdorur simbol Object.

2491
01:49:59,480 --> 01:50:03,562
Kështu që unë mund të filtruar në një mbivendosur
pronë e dokumentit JSON.

2492
01:50:03,562 --> 01:50:05,520
Audienca: Pra, çdo herë që unë
të bëjë një qasje dokument,

2493
01:50:05,520 --> 01:50:07,906
Unë mund të lloj të arrijnë në tabular--

2494
01:50:07,906 --> 01:50:08,780
Audienca: Absolutisht.

2495
01:50:08,780 --> 01:50:09,800
Audienca: --indexes dhe
gjëra që ju vetëm biseduar rreth.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Po, The
indekseve dhe të gjitha që,

2497
01:50:11,280 --> 01:50:13,363
kur ju doni të indeksit të
Pronat e JSON,

2498
01:50:13,363 --> 01:50:18,230
mënyrë që ne do të duhet për të bërë këtë është në qoftë se
ju futur një objekt JSON apo një dokument

2499
01:50:18,230 --> 01:50:20,780
në Dynamo, që ju do të përdorni streams.

2500
01:50:20,780 --> 01:50:22,400
Streams do të lexoni dhëna.

2501
01:50:22,400 --> 01:50:24,340
Ju do të merrni se JSON
kundërshtojnë dhe ju do të them OK,

2502
01:50:24,340 --> 01:50:26,030
çfarë është pronë që unë dua të indeksit?

2503
01:50:26,030 --> 01:50:28,717
>> Ju krijoni një tabelë derivat.

2504
01:50:28,717 --> 01:50:30,300
Tani që është mënyra ajo punon tani.

2505
01:50:30,300 --> 01:50:32,650
Ne nuk do të ju lejojnë për të indeksit
direkt ato prona.

2506
01:50:32,650 --> 01:50:33,520
>> Audienca: Tabularizing dokumentet tuaja.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Pikërisht, rrafshim
ajo, tabularizing atë, pikërisht.

2508
01:50:36,230 --> 01:50:37,415
Kjo është ajo që ju bëni me të.

2509
01:50:37,415 --> 01:50:37,860
>> Audienca: Ju faleminderit.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Po,
absolutisht, faleminderit.

2511
01:50:39,609 --> 01:50:42,240
Audienca: Pra, kjo është lloj i
Mongo takohet classifers Redis.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Po,
kjo është një shumë si kjo.

2513
01:50:43,990 --> 01:50:45,940
Kjo është një përshkrim i mirë për të.

2514
01:50:45,940 --> 01:50:47,490
Ftohtë.

2515
01:50:47,490 --> 01:50:49,102