1
00:00:00,000 --> 00:00:04,969
>> [Zenelejátszási]

2
00:00:04,969 --> 00:00:06,010
Rick Houlihan: Rendben.

3
00:00:06,010 --> 00:00:06,600
Hello mindenki.

4
00:00:06,600 --> 00:00:07,670
A nevem Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Én egy magas rangú vezető
megoldások építész AWS.

6
00:00:10,330 --> 00:00:14,070
Én elsősorban NoSQL és
DynamoDB technológiák.

7
00:00:14,070 --> 00:00:16,930
Én vagyok ma itt, hogy beszéljek
Ön egy kicsit azokról.

8
00:00:16,930 --> 00:00:18,970
>> Saját háttér
Elsősorban adatok rétegen.

9
00:00:18,970 --> 00:00:21,390
Én töltött fél fejlődésemet
pályafutását írásban adatbázis,

10
00:00:21,390 --> 00:00:25,930
az adatokhoz való hozzáférést, megoldások
különböző alkalmazások számára.

11
00:00:25,930 --> 00:00:30,000
Voltam Cloud virtualizáció
körülbelül 20 év.

12
00:00:30,000 --> 00:00:33,460
Szóval mielőtt a felhő a felhő,
szoktuk nevezni használati számítástechnika.

13
00:00:33,460 --> 00:00:37,170
És az ötlet az volt, hogy olyan, mint
PG & E, akkor fizet, amit használ.

14
00:00:37,170 --> 00:00:38,800
Ma hívjuk a felhő.

15
00:00:38,800 --> 00:00:41,239
>> De az évek során, akivel valaha dolgoztam
Egy pár cég

16
00:00:41,239 --> 00:00:42,530
akkor már valószínűleg soha nem hallott.

17
00:00:42,530 --> 00:00:47,470
De én már összeállított egy listát a technikai
teljesítmények, azt hiszem, hogy ezt mondod.

18
00:00:47,470 --> 00:00:51,620
Van nyolc szabadalom Cloud rendszerek
virtualizáció, mikroprocesszor tervezés,

19
00:00:51,620 --> 00:00:54,440
komplex események feldolgozása
és más területeken is.

20
00:00:54,440 --> 00:00:58,290
>> Így ezekben a napokban, azt leginkább az NoSQL
technológiák és a következő generáció

21
00:00:58,290 --> 00:00:59,450
adatbázis.

22
00:00:59,450 --> 00:01:03,370
És ez általában mit fogok
hogy itt beszélgetni veled ma.

23
00:01:03,370 --> 00:01:06,030
Szóval mire számíthatsz
ebből a munkamenet,

24
00:01:06,030 --> 00:01:08,254
megyünk keresztül, egy rövid
történelem adatfeldolgozás.

25
00:01:08,254 --> 00:01:10,420
Ez mindig hasznos,
megérteni, hogy honnan jöttünk

26
00:01:10,420 --> 00:01:12,400
és miért vagyunk, ahol vagyunk.

27
00:01:12,400 --> 00:01:15,600
És fogunk beszélni egy kicsit
kicsit NoSQL technológia

28
00:01:15,600 --> 00:01:17,500
egy alapvető szempontból.

29
00:01:17,500 --> 00:01:19,870
>> Mi lesz bejutni néhány
A DynamoDB belső.

30
00:01:19,870 --> 00:01:24,350
DynamoDB az AWS által nem ízét.

31
00:01:24,350 --> 00:01:27,340
Ez egy teljes körű irányítását és
házigazdája NoSQL megoldás.

32
00:01:27,340 --> 00:01:32,420
És fogunk beszélni egy kicsit a táblázatban
struktúra, API-k, adattípusok, indexek,

33
00:01:32,420 --> 00:01:35,177
és néhány, a belső
Az, hogy DynamoDB technológia.

34
00:01:35,177 --> 00:01:37,760
Majd szerzünk be néhány, a tervezési
minták és a legjobb gyakorlatok.

35
00:01:37,760 --> 00:01:39,968
Megbeszéljük, hogyan
használja ezt a technológiát valamilyen

36
00:01:39,968 --> 00:01:41,430
mai alkalmazások.

37
00:01:41,430 --> 00:01:44,820
És aztán majd beszélünk egy kicsit
alakulásáról vagy a megjelenése

38
00:01:44,820 --> 00:01:48,980
Egy új paradigma programozási
úgynevezett eseményvezérelt alkalmazások

39
00:01:48,980 --> 00:01:51,580
és hogyan DynamoDB játszik, hogy is.

40
00:01:51,580 --> 00:01:54,690
És elmegyünk egy kicsit
A referencia architektúra vita

41
00:01:54,690 --> 00:01:59,540
így tudjuk beszélni néhány
A használati módja DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Tehát először off-- ez a kérdés
Hallom, egy csomó van, mi egy adatbázisban.

43
00:02:04,116 --> 00:02:06,240
Sokan azt hiszik,
tudom, mi az adatbázis.

44
00:02:06,240 --> 00:02:08,360
Ha a Google, látni fogod ezt.

45
00:02:08,360 --> 00:02:11,675
Ez egy olyan strukturált adathalmazt tartott
egy számítógépet, különösen az egyik, hogy

46
00:02:11,675 --> 00:02:13,600
hozzáférhető különböző módokon.

47
00:02:13,600 --> 00:02:16,992
Azt hiszem, ez egy jó
meghatározása a modern adatbázis.

48
00:02:16,992 --> 00:02:19,450
De én nem szeretem, mert
ez azt jelenti, egy-két dolgot.

49
00:02:19,450 --> 00:02:20,935
Ez azt jelenti, szerkezete.

50
00:02:20,935 --> 00:02:23,120
És ez azt jelenti, hogy ez a számítógép.

51
00:02:23,120 --> 00:02:25,750
És adatbázisok nem
Mindig létezik a számítógépek.

52
00:02:25,750 --> 00:02:28,020
Adatbázisok valóban létezett sok.

53
00:02:28,020 --> 00:02:32,000
>> Szóval jobb meghatározása
adatbázis valami ilyesmi.

54
00:02:32,000 --> 00:02:34,786
Egy adatbázis szervezett
mechanizmus tárolására, kezelésére,

55
00:02:34,786 --> 00:02:35,910
és információt kérhet.

56
00:02:35,910 --> 00:02:36,868
Ez származó About.com.

57
00:02:36,868 --> 00:02:42,080
Szóval azért szeretem, mert tényleg beszél
egy adatbázist, hogy egy adattár,

58
00:02:42,080 --> 00:02:44,800
tárháza
információ, nem feltétlenül

59
00:02:44,800 --> 00:02:46,780
valamit, hogy leül a számítógép.

60
00:02:46,780 --> 00:02:49,290
A történelem azt
Nem mindig volt számítógépek.

61
00:02:49,290 --> 00:02:52,110
>> Most, ha megkérdezem az átlagos
fejlesztő ma mi

62
00:02:52,110 --> 00:02:54,770
egy adatbázis, amely a válasz kapok.

63
00:02:54,770 --> 00:02:56,070
Valahol tudok ragaszkodni dolgokat.

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

65
00:02:56,670 --> 00:02:58,725
És ez igaz.

66
00:02:58,725 --> 00:02:59,600
De ez sajnálatos.

67
00:02:59,600 --> 00:03:02,700
Mivel az adatbázist a valóban
Az alapítvány a modern app.

68
00:03:02,700 --> 00:03:04,810
Ez az alapítvány
Minden alkalmazás.

69
00:03:04,810 --> 00:03:07,240
És hogy hogyan kell kialakítani
adatbázis, hogyan strukturálják

70
00:03:07,240 --> 00:03:11,750
hogy az adatok fog diktálni, hogyan, hogy
alkalmazás elvégzi ahogy skála.

71
00:03:11,750 --> 00:03:14,640
>> Szóval sok a munkám ma
foglalkozik, hogy mit

72
00:03:14,640 --> 00:03:17,180
történik, ha a fejlesztők
ezt a megközelítést

73
00:03:17,180 --> 00:03:19,510
és következményeinek kezelésében
Az olyan alkalmazás, amely

74
00:03:19,510 --> 00:03:24,966
most méretezés túl az eredeti
szándék és a szenvedés a rossz tervezés.

75
00:03:24,966 --> 00:03:26,840
Így remélhetőleg, ha
elsétálni ma, akkor

76
00:03:26,840 --> 00:03:29,010
Van egy pár eszközök
a biztonsági öv, hogy akkor tartsa meg

77
00:03:29,010 --> 00:03:32,566
attól, hogy azok ugyanazokat a hibákat.

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

79
00:03:33,066 --> 00:03:36,360
Szóval beszéljünk egy kicsit a
Az idővonal adatbázis-technológia.

80
00:03:36,360 --> 00:03:38,830
Azt hiszem, olvastam egy
Cikk nem is olyan régen

81
00:03:38,830 --> 00:03:43,020
és mondott valamit a lines--
ez egy nagyon költői nyilatkozatot.

82
00:03:43,020 --> 00:03:46,590
Azt mondta, a történelem
Az adatfeldolgozás

83
00:03:46,590 --> 00:03:49,350
tele nagy vízjelek
Az adatok sokasága.

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

85
00:03:49,920 --> 00:03:52,532
Most, azt hiszem, ez a fajta igaz.

86
00:03:52,532 --> 00:03:54,990
De én tényleg nézd meg az AS
A történelem valójában tele

87
00:03:54,990 --> 00:03:56,820
Magas vízjel az adatok nyomást.

88
00:03:56,820 --> 00:04:00,040
Mivel az adatok sebessége
lenyelés soha nem megy le.

89
00:04:00,040 --> 00:04:01,360
Csak megy fel.

90
00:04:01,360 --> 00:04:03,670
>> És az innováció akkor jelentkezik, ha
látjuk adatok nyomás, amely

91
00:04:03,670 --> 00:04:07,825
az adatok mennyisége, amely
most jön be a rendszerbe.

92
00:04:07,825 --> 00:04:12,027
És ez nem lehet feldolgozni
hatékonyan időben vagy a költség.

93
00:04:12,027 --> 00:04:14,110
És ez az, amikor elkezdjük
nézni adatok nyomás.

94
00:04:14,110 --> 00:04:15,920
>> Tehát, ha megnézzük a
első adatbázis, ennek

95
00:04:15,920 --> 00:04:17,180
az egyik, hogy között volt a fülünkben.

96
00:04:17,180 --> 00:04:18,310
Mindannyian született.

97
00:04:18,310 --> 00:04:19,194
Ez egy szép adatbázisban.

98
00:04:19,194 --> 00:04:21,110
Ez egy magas rendelkezésre állás.

99
00:04:21,110 --> 00:04:21,959
Ez mindig az.

100
00:04:21,959 --> 00:04:23,930
Mindig kapni.

101
00:04:23,930 --> 00:04:24,890
>> De ez egyetlen felhasználó.

102
00:04:24,890 --> 00:04:26,348
Nem tudok megosztani a gondolataimat veled.

103
00:04:26,348 --> 00:04:28,370
Ha nem kap a gondolataim
ha meg akarjuk őket.

104
00:04:28,370 --> 00:04:30,320
És azok abilitiy nem olyan jó.

105
00:04:30,320 --> 00:04:32,510
Mi elfelejt dolgokat.

106
00:04:32,510 --> 00:04:36,540
Hébe-hóba, egyikünk levelek
és mozog, hogy egy másik létezéséről

107
00:04:36,540 --> 00:04:39,110
és mi mindent elveszít
ez volt az adatbázisba.

108
00:04:39,110 --> 00:04:40,640
Szóval ez nem annyira jó.

109
00:04:40,640 --> 00:04:43,189
>> És ez jól működött az idő múlásával
amikor mi voltunk vissza a nap

110
00:04:43,189 --> 00:04:46,230
amikor minden, amit igazán szükség, hogy tudjuk,
hová megyünk menni holnap

111
00:04:46,230 --> 00:04:49,630
vagy ha gyűjtünk a legjobb étel.

112
00:04:49,630 --> 00:04:52,820
De ahogy növekedni kezdett, mint egy
civilizáció és a kormány megkezdte

113
00:04:52,820 --> 00:04:55,152
hogy jöjjön létre, és
vállalkozások fejlesztésébe kezdett,

114
00:04:55,152 --> 00:04:57,360
kezdtünk rájönni, mi
Szükségem van egy kicsit több, mint mi

115
00:04:57,360 --> 00:04:58,210
tudnánk tenni a fejünkben.

116
00:04:58,210 --> 00:04:58,870
Minden rendben?

117
00:04:58,870 --> 00:05:00,410
>> Mi szükséges rendszerek rekordot.

118
00:05:00,410 --> 00:05:02,220
Mi szükség van helyeket, hogy képes az adatok tárolására.

119
00:05:02,220 --> 00:05:05,450
Így kezdődött az írás dokumentumok,
létrehozása könyvtárak és levéltárak.

120
00:05:05,450 --> 00:05:08,000
Elkezdtük fejlesztése
rendszer a főkönyvi könyvelés.

121
00:05:08,000 --> 00:05:12,200
És ez a rendszer a főkönyvi számolás
futott a világ évszázadokon,

122
00:05:12,200 --> 00:05:15,580
és talán még évezredek
Azt a fajta nőtt arra a pontra

123
00:05:15,580 --> 00:05:18,420
ahol az adatok terhelés meghaladta
a képesség, e rendszerek

124
00:05:18,420 --> 00:05:19,870
hogy képes legyen tartalmaznak azt.

125
00:05:19,870 --> 00:05:22,070
>> És ez is történt valójában az 1880-as években.

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

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

128
00:05:24,390 --> 00:05:26,976
Ez valóban, ahol a fordulópont
pont korszerű adatkezelés.

129
00:05:26,976 --> 00:05:28,850
Ez az a pont,
amely az adatok mennyisége

130
00:05:28,850 --> 00:05:32,060
amit szedett be a
Egyesült Államok kormánya van arra a pontra

131
00:05:32,060 --> 00:05:34,005
ahol nyolc évig tartott feldolgozni.

132
00:05:34,005 --> 00:05:36,350
>> Most, nyolc years-- mint
Tudod, a népszámlálás

133
00:05:36,350 --> 00:05:39,180
fut minden 10 years-- így
Elég nyilvánvaló, hogy az idő is

134
00:05:39,180 --> 00:05:41,419
Megvan a 1890-es népszámlálás,
az adatok mennyiségét

135
00:05:41,419 --> 00:05:43,210
volt, lesz feldolgozni
a kormány

136
00:05:43,210 --> 00:05:46,335
fog haladhatja meg a 10 évet, hogy
lenne szükség, hogy elindította az új népszámlálás.

137
00:05:46,335 --> 00:05:47,250
Ez volt a probléma.

138
00:05:47,250 --> 00:05:49,000
>> Tehát egy srác nevű Herman
Hollerith jött

139
00:05:49,000 --> 00:05:52,640
és ő találta egység rekordot ütést
kártyák, lyukkártya olvasó, lyukkártya

140
00:05:52,640 --> 00:05:58,420
tabulátorral, és az egybevetés
a mechanizmusok ezt a technológiát.

141
00:05:58,420 --> 00:06:01,860
És ez a társaság, hogy alakult a
időt, valamint egy pár mások,

142
00:06:01,860 --> 00:06:05,450
valóban lett az egyik pillére a
kis cég ma már tudjuk, az úgynevezett IBM.

143
00:06:05,450 --> 00:06:08,417
>> Így aztán az IBM eredetileg volt
Az adatbázis üzlet.

144
00:06:08,417 --> 00:06:09,750
És ez igazán, amit csináltak.

145
00:06:09,750 --> 00:06:11,110
Tették adatfeldolgozás.

146
00:06:11,110 --> 00:06:15,400
>> Mint oly elterjedése ütést
kártyák, egy ötletes mechanizmusok

147
00:06:15,400 --> 00:06:18,560
hogy képes felerősítse, hogy
technológia lehívni sorba rendezett eredmény határozza meg.

148
00:06:18,560 --> 00:06:20,726
Láthatjuk a kép
ott van egy little--

149
00:06:20,726 --> 00:06:23,970
ez egy kicsit small-- de láthatjuk
Nagyon ötletes mechanikus mechanizmus

150
00:06:23,970 --> 00:06:26,970
ahol van egy lyukkártya fedélzeten.

151
00:06:26,970 --> 00:06:28,720
És valaki vesz
Egy kis csavarhúzó

152
00:06:28,720 --> 00:06:31,400
és kitart a
nyílások és felemelése a

153
00:06:31,400 --> 00:06:34,820
kap, hogy meccs, hogy
válogatni eredmény eléréséhez.

154
00:06:34,820 --> 00:06:36,270
>> Ez egy aggregációt.

155
00:06:36,270 --> 00:06:38,690
Tesszük ezt minden alkalommal
ma a számítógépet,

156
00:06:38,690 --> 00:06:40,100
ahol csinálni az adatbázisban.

157
00:06:40,100 --> 00:06:41,620
Szoktuk csinálni kézzel, ugye?

158
00:06:41,620 --> 00:06:42,994
Az emberek álljanak össze.

159
00:06:42,994 --> 00:06:45,440
És ez volt a proliferáció
Ezen lyukkártya

160
00:06:45,440 --> 00:06:50,070
abba, hogy mi hívtuk adatok dobok
és az adatok orsók, papírszalag.

161
00:06:50,070 --> 00:06:55,980
>> Az adatok feldolgozása ipar vette
a tanulságot a játékos zongorák.

162
00:06:55,980 --> 00:06:57,855
Játékos zongorák vissza
A századfordulón

163
00:06:57,855 --> 00:07:02,100
használt papírt használ tárcsa slot
A megmondani, hogy melyik kulcsot kell játszani.

164
00:07:02,100 --> 00:07:05,380
Annak érdekében, hogy a technológia adaptáltuk
végül digitális adatok tárolására,

165
00:07:05,380 --> 00:07:08,070
mert sodorhatják az adatokat
adnunk az olyan papírszalag tárcsákat.

166
00:07:08,070 --> 00:07:10,870
>> Most, ennek eredményeként, az adatok
volt actually-- hogyan

167
00:07:10,870 --> 00:07:14,960
hozzáférést ezen adatokat közvetlenül
függ, hogy hogyan tárolják azt.

168
00:07:14,960 --> 00:07:17,825
Tehát ha tettem az adatokat a kazettára,
Volt hozzáférni az adatokhoz lineárisan.

169
00:07:17,825 --> 00:07:20,475
Meg kellett dobni az egész
szalagot, hogy minden adatot.

170
00:07:20,475 --> 00:07:22,600
Ha tettem az adatokat ütést
kártyák, tudtam hozzáférni

171
00:07:22,600 --> 00:07:26,270
egy kicsit több véletlenszerű
divat, talán nem olyan gyorsan.

172
00:07:26,270 --> 00:07:30,770
>> De voltak korlátai, hogyan
adatokhoz való hozzáférés alapján hogyan tárolták.

173
00:07:30,770 --> 00:07:32,890
És így ez volt a probléma
bemegy a '50 -es években.

174
00:07:32,890 --> 00:07:37,890
Ismét kezdhetjük látni, hogy ahogy
új technológiák kifejlesztésére feldolgozni

175
00:07:37,890 --> 00:07:41,670
Az adatok, jobb, mert nyit
Az ajtó az új megoldások,

176
00:07:41,670 --> 00:07:45,852
Az új programok, új
alkalmazások az adatokat.

177
00:07:45,852 --> 00:07:47,810
És valóban, a kormányzás
Lehet, hogy az ok

178
00:07:47,810 --> 00:07:49,435
Ezért fejlesztettük ki néhány ilyen rendszerek.

179
00:07:49,435 --> 00:07:52,290
De az üzleti gyorsan vált
a vezető evolúciója mögött

180
00:07:52,290 --> 00:07:54,720
A modern adatbázis és
a modern fájlrendszer.

181
00:07:54,720 --> 00:07:56,870
>> Így a következő dolog,
feljött volt, a 50-es évek

182
00:07:56,870 --> 00:08:00,780
volt a fájlrendszer és a
fejlesztését véletlen hozzáférésű tároló.

183
00:08:00,780 --> 00:08:02,050
Ez szép volt.

184
00:08:02,050 --> 00:08:06,230
Most, minden hirtelen, tudjuk be a
fájlokat bárhol a következő merevlemezek

185
00:08:06,230 --> 00:08:09,760
és mi lehet hozzáférni az adatokhoz véletlenszerűen.

186
00:08:09,760 --> 00:08:11,950
Mi lehet elemezni, hogy
információkat ki fájlokat.

187
00:08:11,950 --> 00:08:14,920
És megoldottuk a világ összes
problémák adatfeldolgozás.

188
00:08:14,920 --> 00:08:17,550
>> És ez tartott kb 20 vagy
30 év, amíg a fejlődése

189
00:08:17,550 --> 00:08:22,100
A relációs adatbázis, amely
az, amikor a világ úgy döntött, most

190
00:08:22,100 --> 00:08:27,940
szükség van egy tároló, amely legyőzi
A terjeszkedés az adatok az egész fájl

191
00:08:27,940 --> 00:08:29,540
rendszereket, amit felépítettünk. Jobbra?

192
00:08:29,540 --> 00:08:34,270
Túl sok adatot forgalmazott túl sok
helyen, a duplikáció-adatok,

193
00:08:34,270 --> 00:08:37,120
és a tárolási költségeket, óriási volt.

194
00:08:37,120 --> 00:08:43,760
>> A '70 -es években, a legdrágább erőforrás
hogy a számítógép volt a gép tárolására.

195
00:08:43,760 --> 00:08:46,200
A processzor volt
tekinteni, mint egy fix költség.

196
00:08:46,200 --> 00:08:49,030
Ha veszek a dobozt,
A CPU munkát végez.

197
00:08:49,030 --> 00:08:51,960
Ez lesz forog-e
ez valóban működik-e vagy sem.

198
00:08:51,960 --> 00:08:53,350
Ez tényleg egy elsüllyedt költség.

199
00:08:53,350 --> 00:08:56,030
>> De milyen áron nekem, mint egy
üzlet tároló.

200
00:08:56,030 --> 00:09:00,020
Ha meg kell vásárolni több lemezt következő
hónapban, ez egy valós költségeit, hogy én fizetni.

201
00:09:00,020 --> 00:09:01,620
És, hogy a tárolás drága.

202
00:09:01,620 --> 00:09:05,020
>> Most gyors előre 40 éves
és van egy másik probléma.

203
00:09:05,020 --> 00:09:10,020
A számítási most a
legdrágább erőforrás.

204
00:09:10,020 --> 00:09:11,470
A tárolási olcsó.

205
00:09:11,470 --> 00:09:14,570
Úgy értem, mehetünk bárhová a
felhő, és mi lehet találni olcsó tárolása.

206
00:09:14,570 --> 00:09:17,190
De mi nem találok olcsó számítási.

207
00:09:17,190 --> 00:09:20,700
>> Tehát az evolúció mai
technológiát, az adatbázis-technológia,

208
00:09:20,700 --> 00:09:23,050
valóban köré
elosztott adatbázisok

209
00:09:23,050 --> 00:09:26,960
amelyek nem szenvednek
az azonos típusú skála

210
00:09:26,960 --> 00:09:29,240
korlátai relációs adatbázisok.

211
00:09:29,240 --> 00:09:32,080
Beszélni fogunk egy kicsit
hogy ez mit is jelent valójában.

212
00:09:32,080 --> 00:09:34,760
>> De az egyik oka, és
a vezető mögött this-- vagyunk

213
00:09:34,760 --> 00:09:38,290
beszélt az adatok nyomást.

214
00:09:38,290 --> 00:09:41,920
Az adatok nyomás valamit
ami hajtja az innovációt.

215
00:09:41,920 --> 00:09:44,610
És ha megnézi felett
Az elmúlt öt évben,

216
00:09:44,610 --> 00:09:48,180
ez egy táblázatot, amit az adatok
terhelést a az általános vállalati

217
00:09:48,180 --> 00:09:49,640
úgy néz ki, mint az elmúlt öt évben.

218
00:09:49,640 --> 00:09:52,570
>> És az általános ökölszabály
Ezek days-- ha megy Google--

219
00:09:52,570 --> 00:09:55,290
90% -a az adatok, hogy a
tárolunk ma, és ez volt

220
00:09:55,290 --> 00:09:57,330
generált az elmúlt két évben.

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

222
00:09:57,911 --> 00:09:59,410
Nos, ez nem egy trend, ami új.

223
00:09:59,410 --> 00:10:01,230
Ez a tendencia, hogy a már
kiment 100 éve.

224
00:10:01,230 --> 00:10:03,438
Amióta Herman Hollerith
kifejlesztette a lyukkártya,

225
00:10:03,438 --> 00:10:08,040
mi már az épület adattárak
és adatgyűjtés fenomenális árak.

226
00:10:08,040 --> 00:10:10,570
>> Így az elmúlt 100 évben,
Láttuk ezt a trendet.

227
00:10:10,570 --> 00:10:11,940
Ez nem fog megváltozni.

228
00:10:11,940 --> 00:10:14,789
Továbblépve fogunk látni
ez, ha nem gyorsított tendenciát.

229
00:10:14,789 --> 00:10:16,330
És tudod mit, hogy néz ki.

230
00:10:16,330 --> 00:10:23,510
>> Ha egy vállalkozás 2010-ben volt egy
terabyte adatot kezel,

231
00:10:23,510 --> 00:10:27,080
ma azt jelenti, hogy ők
irányító 6,5 petabájt adat.

232
00:10:27,080 --> 00:10:30,380
Ez 6500-szer több adatot.

233
00:10:30,380 --> 00:10:31,200
És tudom, hogy ez.

234
00:10:31,200 --> 00:10:33,292
Dolgozom ezek a vállalkozások minden nap.

235
00:10:33,292 --> 00:10:35,000
Öt évvel ezelőtt,
hogy szóba cégek

236
00:10:35,000 --> 00:10:38,260
aki velem beszélni, mi a fájdalom
ez kezelni terabájt adat.

237
00:10:38,260 --> 00:10:39,700
És ők beszélnek
nekem arról, hogyan látjuk

238
00:10:39,700 --> 00:10:41,825
hogy ez valószínűleg fog
hogy egy petabyte vagy két

239
00:10:41,825 --> 00:10:43,030
egy pár évig.

240
00:10:43,030 --> 00:10:45,170
>> Ugyanezek a cégek
ma találkozom azzal,

241
00:10:45,170 --> 00:10:48,100
és ők beszélnek, hogy nekem a
probléma van ott, amelynek kezelése

242
00:10:48,100 --> 00:10:51,440
tíz, 20 petabájt adat.

243
00:10:51,440 --> 00:10:53,590
Így a robbanás a
adatok az iparban

244
00:10:53,590 --> 00:10:56,670
hajtja a hatalmas
szükség van jobb megoldás.

245
00:10:56,670 --> 00:11:00,980
És a relációs adatbázis
Csak nem éri el a kereslet.

246
00:11:00,980 --> 00:11:03,490
>> És így van egy lineáris
korreláció adatok nyomás

247
00:11:03,490 --> 00:11:05,210
és a technikai innováció.

248
00:11:05,210 --> 00:11:07,780
A történelem megmutatta nekünk
ez, hogy az idő múlásával,

249
00:11:07,780 --> 00:11:11,090
valahányszor az adatmennyiség
hogy kell feldolgozni

250
00:11:11,090 --> 00:11:15,490
meghaladja a kapacitás a rendszer
feldolgozni azt ésszerű időn

251
00:11:15,490 --> 00:11:18,870
vagy elfogadható áron,
Ezután az új technológiák

252
00:11:18,870 --> 00:11:21,080
kitalált megoldani ezeket a problémákat.

253
00:11:21,080 --> 00:11:24,090
Ezeket az új technológiák,
viszont nyissa ki az ajtót

254
00:11:24,090 --> 00:11:27,840
a másik meg a problémákat, amelyek
összegyűjtése még több adatot.

255
00:11:27,840 --> 00:11:29,520
>> Most, hogy nem fogunk megállítani ezt.

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

257
00:11:30,020 --> 00:11:31,228
Mi nem fogja megállítani ezt.

258
00:11:31,228 --> 00:11:31,830
Miért?

259
00:11:31,830 --> 00:11:35,520
Mert nem lehet tudni, hogy mindent
van tudni az univerzumban.

260
00:11:35,520 --> 00:11:40,510
És amíg mi már él,
az egész ember története,

261
00:11:40,510 --> 00:11:43,440
mi mindig is hajtott, hogy többet.

262
00:11:43,440 --> 00:11:49,840
>> Tehát úgy tűnik, mintha minden négyzetcentiméterét haladunk
le az utat a tudományos felfedezés,

263
00:11:49,840 --> 00:11:54,620
mi megszorozzuk az adatmennyiség
hogy meg kell feldolgozni exponenciálisan

264
00:11:54,620 --> 00:11:59,920
ahogy feltárni egyre több és több
a belső élet működését,

265
00:11:59,920 --> 00:12:04,530
arról, hogyan működik a világegyetem, mintegy
vezetői a tudományos felfedezés,

266
00:12:04,530 --> 00:12:06,440
és a találmány szerinti, hogy a
csinálunk ma.

267
00:12:06,440 --> 00:12:09,570
Az adatmennyiség csak
folyamatosan növekszik.

268
00:12:09,570 --> 00:12:12,120
Tehát, hogy képes kezelni
ez a probléma hatalmas.

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

270
00:12:14,790 --> 00:12:17,410
>> Tehát az egyik dolog
nézzük, hogy miért NoSQL?

271
00:12:17,410 --> 00:12:19,200
Hogyan NoSQL megoldani ezt a problémát?

272
00:12:19,200 --> 00:12:24,980
Nos, a relációs adatbázisok,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL--, hogy tényleg egy konstrukciót a
relációs database-- ezek a dolgok

274
00:12:28,600 --> 00:12:30,770
optimalizált tároló.

275
00:12:30,770 --> 00:12:33,180
>> Vissza a 70-es években, ismét,
lemez drága.

276
00:12:33,180 --> 00:12:36,990
A céltartalék gyakorlása tároló
A vállalkozás soha véget nem érő.

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

278
00:12:37,490 --> 00:12:38,020
Éltem meg.

279
00:12:38,020 --> 00:12:41,250
Írtam tároló illesztőprogramok egy
enterprised szuperszervert cég

280
00:12:41,250 --> 00:12:42,470
vissza a '90 -es években.

281
00:12:42,470 --> 00:12:45,920
És a lényeg, állványok másik
tártömböt csak valami,

282
00:12:45,920 --> 00:12:47,600
történt minden nap a vállalkozás.

283
00:12:47,600 --> 00:12:49,030
És soha nem szűnt meg.

284
00:12:49,030 --> 00:12:52,690
Nagyobb sűrűségű tároló, a kereslet
A nagy sűrűségű tároló,

285
00:12:52,690 --> 00:12:56,340
és a hatékonyabb tárolás
devices-- ez soha nem szűnt meg.

286
00:12:56,340 --> 00:13:00,160
>> És NoSQL egy nagyszerű technológia
mert normalizálja az adatokat.

287
00:13:00,160 --> 00:13:02,210
Ez de-megkétszerezi az adatokat.

288
00:13:02,210 --> 00:13:07,180
Ez hozza az adatokat egy olyan szerkezetbe
az agnosztikus minden hozzáférési mintát.

289
00:13:07,180 --> 00:13:11,600
Több alkalmazás is sújtotta, hogy
SQL adatbázis, fuss eseti lekérdezések

290
00:13:11,600 --> 00:13:15,950
adatokat kaphat az alakja, hogy
kell feldolgozni a terhelést.

291
00:13:15,950 --> 00:13:17,570
Ez úgy hangzik, fantasztikus.

292
00:13:17,570 --> 00:13:21,350
De a lényeg az, bármilyen
rendszer, ha ez agnosztikus, hogy mindent,

293
00:13:21,350 --> 00:13:23,500
van optimalizálva semmit.

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

295
00:13:24,050 --> 00:13:26,386
>> És ez az, amit kapunk a
A relációs adatbázis.

296
00:13:26,386 --> 00:13:27,510
Ez optimalizált tároló.

297
00:13:27,510 --> 00:13:28,280
Ez normalizálódik.

298
00:13:28,280 --> 00:13:29,370
Ez relációs.

299
00:13:29,370 --> 00:13:31,660
Támogatja az ad hoc lekérdezéseket.

300
00:13:31,660 --> 00:13:34,000
És ez és ez mérlegek függőlegesen.

301
00:13:34,000 --> 00:13:39,030
>> Ha kell, hogy egy nagyobb SQL adatbázis
vagy egy erősebb SQL adatbázis,

302
00:13:39,030 --> 00:13:41,090
Én veszünk egy nagyobb darab vas.

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

304
00:13:41,600 --> 00:13:44,940
Dolgoztam már sok ügyfél
hogy már át jelentős fejlesztése

305
00:13:44,940 --> 00:13:48,340
a saját SQL csak infrastruktúra
hogy megtudja, hat hónappal később,

306
00:13:48,340 --> 00:13:49,750
ők üti a falat újra.

307
00:13:49,750 --> 00:13:55,457
És a válasz az Oracle vagy MSSQL
vagy bárki más is kap egy nagyobb dobozt.

308
00:13:55,457 --> 00:13:58,540
Hát előbb vagy utóbb, ha nem lehet megvenni egy
nagyobb dobozt, és ez valós probléma.

309
00:13:58,540 --> 00:14:00,080
Meg kell, hogy valóban változtatni a dolgokat.

310
00:14:00,080 --> 00:14:01,080
Szóval, ha ez a munka?

311
00:14:01,080 --> 00:14:06,560
Jól működik az offline
analitika, OLAP-típusú terhelés.

312
00:14:06,560 --> 00:14:08,670
És ez igazán, amikor az SQL tartozik.

313
00:14:08,670 --> 00:14:12,540
Most, ezt használják ma sok online
tranzakciófeldolgozás típusú

314
00:14:12,540 --> 00:14:13,330
alkalmazásokat.

315
00:14:13,330 --> 00:14:16,460
És azért jól működik a
Néhány kihasználtsági szintje,

316
00:14:16,460 --> 00:14:18,670
de ez csak nem skála
a módon, hogy NoSQL nem.

317
00:14:18,670 --> 00:14:20,660
És fogunk beszélni egy kicsit
kicsit, hogy ez miért.

318
00:14:20,660 --> 00:14:23,590
>> Most, NoSQL, másrészt,
jobban optimalizált számítási.

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

320
00:14:24,540 --> 00:14:26,830
Nem agnosztikus, hogy
A hozzáférési mintát.

321
00:14:26,830 --> 00:14:31,620
Hívjuk de normalizált
struktúra, vagy egy hierarchikus struktúrát.

322
00:14:31,620 --> 00:14:35,000
Az adatokat egy relációs adatbázis
egymáshoz több táblából

323
00:14:35,000 --> 00:14:36,850
termelni véli, hogy szükség van.

324
00:14:36,850 --> 00:14:40,090
Az adatokat egy NoSQL adatbázisban
van tárolva egy dokumentumot, hogy

325
00:14:40,090 --> 00:14:42,100
tartalmazza a hierarchikus felépítés.

326
00:14:42,100 --> 00:14:45,670
Minden adat, ami általában
összefogtak, hogy készítsen ezt a nézetet

327
00:14:45,670 --> 00:14:47,160
tárolt egyetlen dokumentumban.

328
00:14:47,160 --> 00:14:50,990
És fogunk beszélni egy kicsit
hogyan működik egy-két listákon.

329
00:14:50,990 --> 00:14:55,320
>> De az ötlet az, hogy tárolja
Az adatok, mivel ezek példányai kilátást.

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

331
00:14:56,410 --> 00:14:58,610
Léptékezni vízszintesen.

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

333
00:14:59,556 --> 00:15:02,100
Ha kell növelni a
mérete a NoSQL klaszter,

334
00:15:02,100 --> 00:15:03,700
Nem kell, hogy egy nagyobb dobozt.

335
00:15:03,700 --> 00:15:05,200
Kapok egy dobozt.

336
00:15:05,200 --> 00:15:07,700
És én klaszter ezeket együtt,
és tudom, hogy Szilánk adatokat.

337
00:15:07,700 --> 00:15:10,780
Majd beszéljünk egy kicsit
mi sharding van, hogy

338
00:15:10,780 --> 00:15:14,270
képes bővíteni, hogy az adatbázisban
több fizikai eszközök

339
00:15:14,270 --> 00:15:18,370
és távolítsa el az akadályt, hogy
megköveteli, hogy skála függőlegesen.

340
00:15:18,370 --> 00:15:22,080
>> Szóval ez tényleg beépített online
tranzakció-feldolgozás és a skála.

341
00:15:22,080 --> 00:15:25,480
Van egy nagy különbség
Itt közötti jelentési, ugye?

342
00:15:25,480 --> 00:15:27,810
Jelentést, nem tudom, a
kérdéseket fogok feltenni.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- ha valaki a
én marketing osztály

345
00:15:30,570 --> 00:15:34,520
akar csak-- hány ügyfelem
ezt különösen jellemző, akik

346
00:15:34,520 --> 00:15:37,850
vásárolt ezen a day-- nem tudom
mit kérdezni fognak kérni.

347
00:15:37,850 --> 00:15:39,160
Szóval kell lennie agnosztikus.

348
00:15:39,160 --> 00:15:41,810
>> Most, egy on-line
tranzakciós alkalmazás,

349
00:15:41,810 --> 00:15:43,820
Tudom, milyen kérdéseket, amit kérek.

350
00:15:43,820 --> 00:15:46,581
Én építettem a kérelem
Egy nagyon speciális munkafolyamat.

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

352
00:15:47,080 --> 00:15:50,540
Szóval ha optimalizálja az adatok
tárolni, hogy támogassa, hogy a munkafolyamat,

353
00:15:50,540 --> 00:15:52,020
ez lesz gyorsabb.

354
00:15:52,020 --> 00:15:55,190
És ezért NoSQL lehet
Tényleg gyorsabb eljuttatása

355
00:15:55,190 --> 00:15:57,710
Az olyan típusú szolgáltatások.

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

357
00:15:58,210 --> 00:16:00,501
>> Így fogunk bejutni
Egy kis elmélet itt.

358
00:16:00,501 --> 00:16:03,330
És néhányan közületek, a szemed
visszagörgetheti egy kicsit.

359
00:16:03,330 --> 00:16:06,936
De megpróbálom tartani
olyan magas szintű, amennyire csak tudok.

360
00:16:06,936 --> 00:16:08,880
Tehát ha a projekt
menedzsment, van

361
00:16:08,880 --> 00:16:12,280
A konstrukció az úgynevezett
háromszög korlátok.

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

363
00:16:12,936 --> 00:16:16,060
A háromszög a korlátozásoknak diktálja
hogy nem lehet mindent minden alkalommal.

364
00:16:16,060 --> 00:16:17,750
Nem lehet a pite és enni is.

365
00:16:17,750 --> 00:16:22,310
Így a projekt menedzsment, hogy háromszög
korlátok akkor lehet, hogy az olcsó,

366
00:16:22,310 --> 00:16:24,710
akkor lehet, hogy gyors,
vagy lehet, hogy jó.

367
00:16:24,710 --> 00:16:25,716
Válassz kettőt.

368
00:16:25,716 --> 00:16:27,090
Mert nem lehet csak ezt a hármat.

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

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

371
00:16:27,820 --> 00:16:28,920
>> Szóval hallani erről sokat.

372
00:16:28,920 --> 00:16:31,253
Ez egy hármas korlát,
háromszög hármas korlát,

373
00:16:31,253 --> 00:16:34,420
vagy a vas háromszög oftentimes--
amikor beszélsz projektmenedzserek,

374
00:16:34,420 --> 00:16:35,420
fognak beszélni erről.

375
00:16:35,420 --> 00:16:37,640
Most, adatbázisok
saját vas háromszög.

376
00:16:37,640 --> 00:16:40,350
És a vas háromszög adatok
hívjuk KAP tétel.

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

378
00:16:41,580 --> 00:16:43,770
>> KAP-tétel diktál
hogyan működnek adatbázisok

379
00:16:43,770 --> 00:16:45,627
egy igen konkrét feltétel.

380
00:16:45,627 --> 00:16:47,460
És fogunk beszélni,
mi ez a feltétel.

381
00:16:47,460 --> 00:16:52,221
De a három pontot a háromszög,
hogy úgy mondjam, a C, a következetesség.

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

383
00:16:52,720 --> 00:16:56,760
Tehát a KAP, a következetesség azt jelenti, hogy minden
ügyfelek, akik hozzáférhet az adatbázishoz

384
00:16:56,760 --> 00:16:59,084
mindig van egy nagyon
konzisztens képet adatokat.

385
00:16:59,084 --> 00:17:00,750
Senki sem fog látni két különböző dolog.

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

387
00:17:01,480 --> 00:17:04,020
Ha látom az adatbázis,
Látok ugyanazt a nézetet

388
00:17:04,020 --> 00:17:06,130
mint a társam, aki látja
ugyanabból az adatbázisból.

389
00:17:06,130 --> 00:17:07,470
Ez a következetesség.

390
00:17:07,470 --> 00:17:12,099
>> Szabad azt jelenti, hogy ha a
adatbázis az interneten, ha el lehet érni,

391
00:17:12,099 --> 00:17:14,760
hogy minden kliens program mindig
képes írni és olvasni.

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

393
00:17:15,260 --> 00:17:17,010
Így minden ügyfél, hogy
Elolvashatja az adatbázisban

394
00:17:17,010 --> 00:17:18,955
Mindig tudja olvasni
adatok és írni az adatokat.

395
00:17:18,955 --> 00:17:21,819
És ha ez a helyzet,
ez egy álló rendszer.

396
00:17:21,819 --> 00:17:24,230
>> És a harmadik pont az, amit
hívjuk partíció tolerancia.

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

398
00:17:24,730 --> 00:17:28,160
Partíció tolerancia úton
hogy a rendszer jól működik

399
00:17:28,160 --> 00:17:32,000
annak ellenére, hogy a fizikai hálózat
válaszfalak a csomópontok között.

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

401
00:17:32,760 --> 00:17:36,270
Tehát a fürt csomópontjai nem
beszélnek egymással, mi történik?

402
00:17:36,270 --> 00:17:36,880
Minden rendben.

403
00:17:36,880 --> 00:17:39,545
>> Tehát a relációs adatbázisok choose--
akkor vedd két ilyen.

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

405
00:17:40,045 --> 00:17:43,680
Tehát a relációs adatbázisok választani
hogy következetes és elérhető.

406
00:17:43,680 --> 00:17:47,510
Ha a partíció között történik
A DataNodes az adattárban,

407
00:17:47,510 --> 00:17:48,831
Az adatbázis összeomlik.

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

409
00:17:49,330 --> 00:17:50,900
Csak megy le.

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

411
00:17:51,450 --> 00:17:54,230
>> És ez miért van
a nő a nagyobb dobozok.

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

413
00:17:54,730 --> 00:17:58,021
Mert van no-- általában, a klaszter
adatbázis, ott nem nagyon sokan

414
00:17:58,021 --> 00:17:59,590
hogy működnek így.

415
00:17:59,590 --> 00:18:03,019
De a legtöbb adatbázisok skála
függőlegesen egyetlen dobozban.

416
00:18:03,019 --> 00:18:05,060
Mert kell lennie
következetes és rendelkezésre.

417
00:18:05,060 --> 00:18:10,320
Ha egy partíció voltak kell beadni,
akkor kellett volna, hogy a választás.

418
00:18:10,320 --> 00:18:13,720
Van, hogy egy választás között
következetes és elérhető.

419
00:18:13,720 --> 00:18:16,080
>> És ez az, amit NoSQL adatbázisokhoz.

420
00:18:16,080 --> 00:18:16,580
Minden rendben.

421
00:18:16,580 --> 00:18:20,950
Tehát egy NoSQL adatbázist, akkor
Két fajta.

422
00:18:20,950 --> 00:18:22,990
Mi have-- jól,
Jön a sok íz,

423
00:18:22,990 --> 00:18:26,140
de ez benne van a két alapvető
jellemzõk mi

424
00:18:26,140 --> 00:18:30,050
mondanánk CP adatbázisban, vagy
következetes és partíció tolerancia

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

426
00:18:31,040 --> 00:18:34,930
Ezek a srácok, hogy a választás, hogy amikor
a csomópontok veszít érintkezik egymással,

427
00:18:34,930 --> 00:18:37,091
nem megyünk, hogy
embereket, hogy írjanak többé.

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

429
00:18:37,590 --> 00:18:41,855
>> Amíg ez a partíció eltávolítása,
írási hozzáférés le van tiltva.

430
00:18:41,855 --> 00:18:43,230
Ez azt jelenti, hogy nem áll rendelkezésre.

431
00:18:43,230 --> 00:18:44,510
Ők következetes.

432
00:18:44,510 --> 00:18:46,554
Amikor azt látjuk, hogy
partíció adja magát,

433
00:18:46,554 --> 00:18:48,470
most következetes,
mert nem megyünk

434
00:18:48,470 --> 00:18:51,517
hogy lehetővé tegye a változás két
oldalán a partíció függetlenül

435
00:18:51,517 --> 00:18:52,100
egymást.

436
00:18:52,100 --> 00:18:54,130
Mi kell
helyreállítani kommunikációs

437
00:18:54,130 --> 00:18:56,930
mielőtt bármilyen frissítés
az adatok megengedett.

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

439
00:18:58,120 --> 00:19:02,650
>> A következő íz lenne egy AP rendszer,
vagy egy szabad és megosztjuk

440
00:19:02,650 --> 00:19:03,640
tolerancia rendszer.

441
00:19:03,640 --> 00:19:05,320
Ezek a srácok nem érdekel.

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

443
00:19:06,020 --> 00:19:08,960
Bármilyen csomópont, amely kap egy
levelet, akkor vedd el.

444
00:19:08,960 --> 00:19:11,480
Úgyhogy lemásolják az adataimat
több csomópontot.

445
00:19:11,480 --> 00:19:14,730
Ezek a csomópontok kap az ügyfél, ügyfél jön
A mondja, én fogom írni néhány adatot.

446
00:19:14,730 --> 00:19:16,300
Node mondja, semmi gond.

447
00:19:16,300 --> 00:19:18,580
A csomópont mellé kap
írási ugyanazon a rekordot,

448
00:19:18,580 --> 00:19:20,405
ő fog mondani semmi gond.

449
00:19:20,405 --> 00:19:23,030
Valahol vissza a háttérben,
hogy az adatok fog szaporodni.

450
00:19:23,030 --> 00:19:27,360
És akkor valaki majd észre,
Ajjaj, akkor a rendszer észre, uh-oh,

451
00:19:27,360 --> 00:19:28,870
van már egy frissítést a két fél.

452
00:19:28,870 --> 00:19:30,370
Mit csináljunk?

453
00:19:30,370 --> 00:19:33,210
És mit csinálnak majd a
csinálnak valamit, ami

454
00:19:33,210 --> 00:19:36,080
lehetővé teszi számukra, hogy megoldja az adatok állapotban.

455
00:19:36,080 --> 00:19:39,000
És fogunk beszélni,
hogy a következő táblázatot.

456
00:19:39,000 --> 00:19:40,000
>> Dolog, hogy pont itt.

457
00:19:40,000 --> 00:19:42,374
És én nem fogok túl
sokkal ebbe, mert ez a

458
00:19:42,374 --> 00:19:43,510
bejut mély adatokat elmélet.

459
00:19:43,510 --> 00:19:46,670
De van olyan ügyleti
keretet, amely

460
00:19:46,670 --> 00:19:50,680
fut egy relációs rendszer
lehetővé teszi számomra, hogy biztonságosan, hogy frissítések

461
00:19:50,680 --> 00:19:53,760
hogy több szervezet az adatbázisban.

462
00:19:53,760 --> 00:19:58,320
És ezek a frissítések fog bekövetkezni
egyszerre, vagy egyáltalán nem.

463
00:19:58,320 --> 00:20:00,500
És ezt nevezik ACID tranzakciók.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID ad nekünk atomicitás, következetesség,
szigetelés, és a tartósság.

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

467
00:20:07,070 --> 00:20:13,550
Ez azt jelenti, atomi, tranzakciók, mind
frissítéseim sem történik meg, vagy nem.

468
00:20:13,550 --> 00:20:16,570
Összhang azt jelenti, hogy
Az adatbázis mindig

469
00:20:16,570 --> 00:20:19,780
hozni egy egységes
állapotban egy frissítés után.

470
00:20:19,780 --> 00:20:23,900
Soha nem fogom elhagyni az adatbázist egy
Rossz állapotban alkalmazása után egy frissítést.

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

472
00:20:24,400 --> 00:20:26,720
>> Szóval ez egy kicsit más
mint KAP összhang.

473
00:20:26,720 --> 00:20:29,760
KAP konzisztencia azt jelenti az én
ügyfelek mindig látni az adatokat.

474
00:20:29,760 --> 00:20:34,450
ACID a következetesség azt jelenti, hogy ha
a tranzakció megtörtént, az adatok jó.

475
00:20:34,450 --> 00:20:35,709
Saját kapcsolatok mind jó.

476
00:20:35,709 --> 00:20:38,750
Nem fogom törölni a szülő sorban
és hagyjuk egy csomó árva gyermekek

477
00:20:38,750 --> 00:20:40,970
Néhány másik asztalnál.

478
00:20:40,970 --> 00:20:44,320
Ez nem történhet meg, ha én vagyok következetes
savas tranzakciót.

479
00:20:44,320 --> 00:20:49,120
>> Isolation jelenti, hogy az ügyletek
mindig előfordulnak egyiket a másik után.

480
00:20:49,120 --> 00:20:51,920
A végeredmény az adatok
ugyanaz lesz állapotban

481
00:20:51,920 --> 00:20:54,770
mintha ezen ügyletek
ben kibocsátott egyidejűleg

482
00:20:54,770 --> 00:20:57,340
kivégezték sorozatban.

483
00:20:57,340 --> 00:21:00,030
Szóval ez konkurencia
kontroll az adatbázisban.

484
00:21:00,030 --> 00:21:04,130
Tehát alapvetően, nem tudom megnövelni a
ugyanazt az értéket kétszer két művelet.

485
00:21:04,130 --> 00:21:08,580
>> De ha azt mondom adjunk hozzá 1 erre az értékre,
és két ügylet jönnek

486
00:21:08,580 --> 00:21:10,665
és megpróbálja csinálni, az egyik az,
lesz, hogy oda először

487
00:21:10,665 --> 00:21:12,540
és a többi ember
fog odaérni után.

488
00:21:12,540 --> 00:21:15,210
Így a végén, tettem hozzá kettő.

489
00:21:15,210 --> 00:21:16,170
Látod, mire gondolok?

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

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

492
00:21:19,220 --> 00:21:21,250
>> Tartóssága nagyon egyszerű.

493
00:21:21,250 --> 00:21:23,460
Amikor az ügylet
Elismert, hogy

494
00:21:23,460 --> 00:21:26,100
ott lesz még
ha a rendszer összeomlik.

495
00:21:26,100 --> 00:21:29,230
Ha ez a rendszer visszanyeri, hogy
ügylet, amely elkövetése

496
00:21:29,230 --> 00:21:30,480
valóban ott lesz.

497
00:21:30,480 --> 00:21:33,130
Szóval ez a garanciák
Az ACID tranzakciók.

498
00:21:33,130 --> 00:21:35,470
Ezek elég szép garanciák
hogy egy adatbázis,

499
00:21:35,470 --> 00:21:36,870
de ennek ez a költség.

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

501
00:21:37,640 --> 00:21:40,520
>> Mivel a probléma
ezzel a keret

502
00:21:40,520 --> 00:21:44,540
ha van egy partíció az adatokban
set, azt kell dönteni.

503
00:21:44,540 --> 00:21:48,000
Megyek is, hogy
frissítéseket az egyik oldalon vagy a másik.

504
00:21:48,000 --> 00:21:50,310
És ha ez megtörténik,
Ezután már nem vagyok megy

505
00:21:50,310 --> 00:21:52,630
hogy képes fenntartani
ezeket a jellemzőket.

506
00:21:52,630 --> 00:21:53,960
Ők nem lesz egyenletes.

507
00:21:53,960 --> 00:21:55,841
Ezek nem izolálható.

508
00:21:55,841 --> 00:21:58,090
Ez az, ahol lerobban
A relációs adatbázisok.

509
00:21:58,090 --> 00:22:01,360
Ez az oka relációs
adatbázisok skála függőlegesen.

510
00:22:01,360 --> 00:22:05,530
>> Másrészt, van
az úgynevezett alap technológia.

511
00:22:05,530 --> 00:22:07,291
És ezek a NoSQL adatbázisok.

512
00:22:07,291 --> 00:22:07,790
Minden rendben.

513
00:22:07,790 --> 00:22:10,180
Szóval mi van a CP, AP adatbázisok.

514
00:22:10,180 --> 00:22:14,720
És ezek, amit úgy hívnak alapvetően
álló, puha állapotban, végül

515
00:22:14,720 --> 00:22:15,740
következetes.

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

517
00:22:16,420 --> 00:22:19,690
>> Alapvetően elérhető, mert
ők partíció toleráns.

518
00:22:19,690 --> 00:22:21,470
Ők mindig
ott, akkor is, ha van

519
00:22:21,470 --> 00:22:23,053
hálózati partíciót a csomópontok között.

520
00:22:23,053 --> 00:22:25,900
Ha tudok beszélni, hogy egy csomópont, én vagyok
lesz képes olvasni az adatokat.

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

522
00:22:26,460 --> 00:22:30,810
Lehet, hogy nem mindig képes írni
adatokat, ha én vagyok a következetes platform.

523
00:22:30,810 --> 00:22:32,130
De képes lesz olvasni az adatokat.

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

525
00:22:34,960 --> 00:22:38,010
>> A puha állapot mutatja,
hogy amikor olvastam, hogy az adatok,

526
00:22:38,010 --> 00:22:40,790
lehet, hogy nem ugyanaz, mint a többi csomópont.

527
00:22:40,790 --> 00:22:43,390
Ha a jobb adta ki a csomóponton
valahol máshol a klaszter

528
00:22:43,390 --> 00:22:46,650
és ez nem replikálta az egész
klaszter mégis, amikor azt olvastam, hogy az adatok,

529
00:22:46,650 --> 00:22:48,680
hogy az állami esetleg nem következetes.

530
00:22:48,680 --> 00:22:51,650
Azonban, ez lesz
végül következetes,

531
00:22:51,650 --> 00:22:53,870
ami azt jelenti, hogy amikor egy írási
történik a rendszerben,

532
00:22:53,870 --> 00:22:56,480
akkor megismételni az egész csomópontot.

533
00:22:56,480 --> 00:22:59,095
És végül, hogy az állami
majd hozni annak érdekében,

534
00:22:59,095 --> 00:23:00,890
és ez lesz konzisztens állapotban.

535
00:23:00,890 --> 00:23:05,000
>> Most, a KAP-tétel valóban
játszik csak egy feltétellel.

536
00:23:05,000 --> 00:23:08,700
Ez a feltétel az, amikor ez megtörténik.

537
00:23:08,700 --> 00:23:13,710
Mert ha ez működik
normál módban, nincs partíció,

538
00:23:13,710 --> 00:23:16,370
mindent következetes és elérhető.

539
00:23:16,370 --> 00:23:19,990
Ön csak aggódni KAP
amikor már a partíciót.

540
00:23:19,990 --> 00:23:21,260
Tehát azok ritkák.

541
00:23:21,260 --> 00:23:25,360
De a rendszer hogyan reagál, amikor azok
merülnek diktálja, hogy milyen típusú rendszer

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

543
00:23:26,750 --> 00:23:31,110
>> Szóval vessünk egy pillantást, amit
úgy néz ki, mint az AP rendszerek.

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

545
00:23:32,621 --> 00:23:34,830
AP rendszerek jön két ízeket.

546
00:23:34,830 --> 00:23:38,514
Jönnek az íz, ami a
master master, 100%, mindig elérhető.

547
00:23:38,514 --> 00:23:40,430
És jönnek az
Más ízt, amely azt mondja,

548
00:23:40,430 --> 00:23:43,330
Tudod mit, fogok aggódni
erről a particionálás dolog

549
00:23:43,330 --> 00:23:44,724
ha a tényleges partíció fordul elő.

550
00:23:44,724 --> 00:23:47,890
Ellenkező esetben nem lesz elsődleges
csomópontok, ki fogja venni a jogokat.

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

552
00:23:48,500 --> 00:23:50,040
>> Tehát, ha valami ilyesmi Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra lenne mestere
mester, hadd írjam minden csomópont.

554
00:23:54,440 --> 00:23:55,540
Tehát mi történik?

555
00:23:55,540 --> 00:23:58,270
Szóval van egy tárgy a
adatbázis, hogy létezik a két csomópont.

556
00:23:58,270 --> 00:24:01,705
Nevezzük azt a tárgyat S.
Tehát van állapotban S.

557
00:24:01,705 --> 00:24:04,312
Van néhány művelet
S hogy folyamatban vannak.

558
00:24:04,312 --> 00:24:06,270
Cassandra lehetővé teszi számomra, hogy
írjon több csomópont.

559
00:24:06,270 --> 00:24:08,550
Tehát mondjuk azt, hogy egy
írni, s két csomópontra.

560
00:24:08,550 --> 00:24:12,274
Nos, mi végül az történik,
hívjuk, hogy a particionálás esetén.

561
00:24:12,274 --> 00:24:14,190
Ott nem lehet
fizikai hálózat partíció.

562
00:24:14,190 --> 00:24:15,950
De mivel a tervezés
A rendszer, ez

563
00:24:15,950 --> 00:24:18,449
ténylegesen particionálás amint
kapok egy írás a két csomópont.

564
00:24:18,449 --> 00:24:20,830
Ez nem kényszerít
írok egy csomóponton keresztül.

565
00:24:20,830 --> 00:24:22,340
Írok két csomópontot.

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

567
00:24:23,330 --> 00:24:25,740
>> Mostanra van két állam.

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

569
00:24:26,360 --> 00:24:28,110
Mi fog történni
előbb vagy utóbb,

570
00:24:28,110 --> 00:24:29,960
ott lesz a replikációs eseményt.

571
00:24:29,960 --> 00:24:33,300
Ott lesz, amit mi
úgynevezett partíció helyreállító, amely

572
00:24:33,300 --> 00:24:35,200
az, ahol ez a két
államok jönnek újra együtt

573
00:24:35,200 --> 00:24:37,310
és ott lesz egy algoritmus
fut az adatbázison belül történik,

574
00:24:37,310 --> 00:24:38,540
eldönti, hogy mi a teendő.

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

576
00:24:39,110 --> 00:24:43,057
Alapértelmezésben Utolsó frissítés
nyerte a legtöbb AP rendszerek.

577
00:24:43,057 --> 00:24:44,890
Szóval ott általában egy
alapértelmezett algoritmus, milyen

578
00:24:44,890 --> 00:24:47,400
Hogy hívják a visszahívás
funkciót, ami

579
00:24:47,400 --> 00:24:51,000
fogják hívni, ha ez a feltétel
érzékeli, hogy végre némi logika

580
00:24:51,000 --> 00:24:52,900
megoldani, hogy a konfliktus.

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

582
00:24:53,850 --> 00:24:58,770
Az alapértelmezett visszahívási és alapértelmezett
rezolverkábel a legtöbb AP adatbázisok

583
00:24:58,770 --> 00:25:01,130
van, tudod mit, időbélyeg nyer.

584
00:25:01,130 --> 00:25:02,380
Ez volt az utolsó frissítés.

585
00:25:02,380 --> 00:25:04,320
Azt fogom tenni, hogy frissítés van.

586
00:25:04,320 --> 00:25:08,440
Lehet kiírása ezt a lemezt, hogy én
dömpingelt ki egy helyreállítási napló

587
00:25:08,440 --> 00:25:11,670
úgy, hogy a felhasználó látogasson vissza később
és azt mondják, hé, volt egy ütközés.

588
00:25:11,670 --> 00:25:12,320
Ami történt?

589
00:25:12,320 --> 00:25:16,370
És akkor valóban kiírása egy rekordot
minden ütközések és a visszavonás

590
00:25:16,370 --> 00:25:17,550
és meglátjuk, mi történik.

591
00:25:17,550 --> 00:25:21,580
>> Most, mint felhasználó, akkor is
közé logika, hogy visszahívás.

592
00:25:21,580 --> 00:25:24,290
Szóval lehet változtatni
visszahívási műveletet.

593
00:25:24,290 --> 00:25:26,730
Azt lehet mondani, hé, szeretnék
orvoslására az adatokat.

594
00:25:26,730 --> 00:25:28,880
És azt akarom, hogy megpróbálja
egyesíti a két nyilvántartás.

595
00:25:28,880 --> 00:25:30,050
De ez rajtad áll.

596
00:25:30,050 --> 00:25:32,880
Az adatbázis nem tudja, hogyan kell
Ehhez alapértelmezés szerint. A legtöbb időt,

597
00:25:32,880 --> 00:25:34,850
Az egyetlen dolog, az adatbázis
Tudja, hogyan kell tennie, hogy azt mondják,

598
00:25:34,850 --> 00:25:36,100
ez volt az utolsó rekordot.

599
00:25:36,100 --> 00:25:39,183
Ez az egyik, hogy az fog nyerni,
és ez az érték fogom tenni.

600
00:25:39,183 --> 00:25:41,490
Egyszer, hogy partíció helyreállító
és replikáció,

601
00:25:41,490 --> 00:25:43,930
mi államunk, amely
most S elsődleges, amely

602
00:25:43,930 --> 00:25:46,890
Az egyesítés állam mindazon tárgyakat.

603
00:25:46,890 --> 00:25:49,700
Tehát AP rendszerek ezt.

604
00:25:49,700 --> 00:25:51,615
CP rendszerek nem kell
aggódni emiatt.

605
00:25:51,615 --> 00:25:54,490
Mert amint egy partíció jön
játékba, csak hagyja abba

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

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

608
00:25:56,180 --> 00:25:58,670
Szóval ez nagyon könnyű
foglalkozik következetes

609
00:25:58,670 --> 00:26:01,330
ha nem fogadja el a frissítéseket.

610
00:26:01,330 --> 00:26:04,620
Ez a CP rendszerek teszik.

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

612
00:26:05,120 --> 00:26:07,590
>> Szóval beszéljünk egy kicsit
kicsit a hozzáférési mintákat.

613
00:26:07,590 --> 00:26:11,580
Amikor arról beszélünk, NoSQL, ez
Minden a hozzáférést mintát.

614
00:26:11,580 --> 00:26:13,550
Most, az SQL eseti lekérdezések.

615
00:26:13,550 --> 00:26:14,481
Ez relációs boltban.

616
00:26:14,481 --> 00:26:16,480
Nem kell aggódnia
a hozzáférés mintát.

617
00:26:16,480 --> 00:26:17,688
Írok egy nagyon összetett kérdés.

618
00:26:17,688 --> 00:26:19,250
Magától és megkapja az adatokat.

619
00:26:19,250 --> 00:26:21,210
Ez az, amit ez úgy néz ki
mint, normalizálás.

620
00:26:21,210 --> 00:26:24,890
>> Tehát ebben a különleges szerkezetet,
keresünk egy katalógus.

621
00:26:24,890 --> 00:26:26,640
Van különböző típusú termékek.

622
00:26:26,640 --> 00:26:27,217
Van könyveket.

623
00:26:27,217 --> 00:26:27,800
Van egy albumot.

624
00:26:27,800 --> 00:26:30,090
Van videók.

625
00:26:30,090 --> 00:26:33,370
A kapcsolat a termékek
és ezek bármelyike ​​könyvek, albumok,

626
00:26:33,370 --> 00:26:34,860
és videók táblák 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Van egy termék azonosító,
és hogy az ID felel

629
00:26:38,860 --> 00:26:41,080
egy könyv, egy album, vagy egy videót.

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

631
00:26:41,580 --> 00:26:44,350
Ez egy 1: 1 kapcsolat
szerte e táblázatokat.

632
00:26:44,350 --> 00:26:46,970
>> Most, books-- minden tőlük
Van root tulajdonságokkal.

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

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

635
00:26:48,230 --> 00:26:52,130
Egy-egy kapcsolat, azt, hogy minden
Az adatok azt kell leírni, hogy a könyv.

636
00:26:52,130 --> 00:26:54,770
Albums-- két album zeneszámokat.

637
00:26:54,770 --> 00:26:56,470
Ez az, amit mi hívja az egyik, hogy sok.

638
00:26:56,470 --> 00:26:58,905
Minden album volna sok pálya.

639
00:26:58,905 --> 00:27:00,780
Így minden pályán
Az album tudtam volna

640
00:27:00,780 --> 00:27:02,570
egy másik rekord ebben gyermek asztal.

641
00:27:02,570 --> 00:27:04,680
Szóval létre egy rekordot
az én album táblázatban.

642
00:27:04,680 --> 00:27:06,700
Én létre több rekord
A pályák asztalra.

643
00:27:06,700 --> 00:27:08,850
Egy-sok kapcsolat.

644
00:27:08,850 --> 00:27:11,220
>> Ez a kapcsolat az, ami
hívjuk a sok-sok.

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

646
00:27:11,750 --> 00:27:17,000
Látod, hogy a szereplők lehetnek
sok film, sok videót.

647
00:27:17,000 --> 00:27:21,450
Szóval amit csinálunk, az tesszük ezt a leképezés
táblázat között azok, amelyek csak

648
00:27:21,450 --> 00:27:24,040
térképek a színész azonosítóját a videó azonosítóját.

649
00:27:24,040 --> 00:27:28,464
Most is létrehozhat egy lekérdezést az illesztéseknél
videók segítségével színész videót szereplők,

650
00:27:28,464 --> 00:27:31,130
és ez ad nekem egy szép listát
összes film és a valamennyi szereplő

651
00:27:31,130 --> 00:27:32,420
akik abban a filmben.

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

653
00:27:33,290 --> 00:27:33,880
Tehát itt vagyunk.

654
00:27:33,880 --> 00:27:38,040
Egy-egy a felső szintű
kapcsolat; egy-sok,

655
00:27:38,040 --> 00:27:40,240
album számai; Sok-sok.

656
00:27:40,240 --> 00:27:44,990
Ez a három felső szintű
kapcsolatok bármilyen adatbázisban.

657
00:27:44,990 --> 00:27:48,050
Ha tudod, hogyan kell e
kapcsolatok működnek együtt,

658
00:27:48,050 --> 00:27:51,490
akkor tudjuk, hogy sok
mintegy adatbázis már.

659
00:27:51,490 --> 00:27:55,660
Tehát NoSQL egy kicsit másképpen dolgozik.

660
00:27:55,660 --> 00:27:58,930
Gondoljunk csak a második, amit
Úgy néz ki, hogy akkor kap az én termékek.

661
00:27:58,930 --> 00:28:01,096
>> Egy relációs boltban,
szeretnénk, hogy az én termékek

662
00:28:01,096 --> 00:28:02,970
egy listát az összes termékeim.

663
00:28:02,970 --> 00:28:04,910
Ez sok olyan lekérdezés.

664
00:28:04,910 --> 00:28:07,030
Kaptam egy lekérdezést az összes könyvemet.

665
00:28:07,030 --> 00:28:08,470
Kaptam egy lekérdezést az albumomat.

666
00:28:08,470 --> 00:28:09,970
És kaptam egy lekérdezést az én videók.

667
00:28:09,970 --> 00:28:11,719
És kaptam, hogy azt
valamennyit egy listát

668
00:28:11,719 --> 00:28:15,250
és tálaljuk vissza az
alkalmazás, ami azt kérő.

669
00:28:15,250 --> 00:28:18,000
>> Ahhoz, hogy a könyveim, csatlakozom
Termékek és könyvek.

670
00:28:18,000 --> 00:28:21,680
Ahhoz, hogy az albumokon kaptam, hogy csatlakozzon
Termékek, albumok és számok.

671
00:28:21,680 --> 00:28:25,330
És hogy megkapjam a videókat, van
hogy csatlakozzon termékek a videók,

672
00:28:25,330 --> 00:28:28,890
csatlakozzon a színész videók,
és hogy a színészek.

673
00:28:28,890 --> 00:28:31,020
Szóval ez a három lekérdezéseket.

674
00:28:31,020 --> 00:28:34,560
Nagyon összetett lekérdezések
össze egy eredmény meg.

675
00:28:34,560 --> 00:28:36,540
>> Ez kevesebb, mint az optimális.

676
00:28:36,540 --> 00:28:39,200
Ez az oka annak, amikor beszélünk
körülbelül egy adatstruktúrát, ami

677
00:28:39,200 --> 00:28:42,900
építették, hogy agnosztikus, hogy a hozzáférési
pattern-- is ez nagyszerű.

678
00:28:42,900 --> 00:28:45,730
És láthatjuk ezt a valóban
Jó, hogyan szervezte az adatokat.

679
00:28:45,730 --> 00:28:46,550
És tudod mit?

680
00:28:46,550 --> 00:28:49,750
Nekem csak egy rekord egy színész számára.

681
00:28:49,750 --> 00:28:50,440
>> Ez király.

682
00:28:50,440 --> 00:28:53,750
Már duplikációmentesített az én szereplők,
és én tartjuk az én egyesületek

683
00:28:53,750 --> 00:28:55,200
ebben a leképezési tábla.

684
00:28:55,200 --> 00:29:00,620
Azonban a szerzés adatok
ki lesz drága.

685
00:29:00,620 --> 00:29:04,500
Küldök a CPU az egész rendszer
ezeket összekötő adatszerkezetek össze

686
00:29:04,500 --> 00:29:05,950
hogy képes húzni, hogy az adatok vissza.

687
00:29:05,950 --> 00:29:07,310
>> Szóval hogyan lehet megkerülni, hogy?

688
00:29:07,310 --> 00:29:11,200
Ebben NoSQL ez körülbelül
összesítés nem normalizálása.

689
00:29:11,200 --> 00:29:13,534
Szóval azt akarom mondani akarunk
támogatja a hozzáférési mintát.

690
00:29:13,534 --> 00:29:15,283
Ha a hozzáférési minta
Az alkalmazások,

691
00:29:15,283 --> 00:29:16,770
Azt kell, hogy az én termékek.

692
00:29:16,770 --> 00:29:19,027
Tegyük az összes termék egy táblázatban.

693
00:29:19,027 --> 00:29:22,110
Ha tettem a termék egy asztal,
Én is csak válassza ki az összes termék

694
00:29:22,110 --> 00:29:23,850
ettől az asztalra, és azt, hogy mindent.

695
00:29:23,850 --> 00:29:25,240
Nos, hogyan tudom ezt?

696
00:29:25,240 --> 00:29:28,124
Nos NoSQL nincs
szerkezete az asztalra.

697
00:29:28,124 --> 00:29:30,540
Beszélni fogunk egy kicsit
hogyan is működik ez a Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
De nem ugyanaz
tulajdonságok és az azonos tulajdonságokkal

699
00:29:33,570 --> 00:29:37,751
minden egyes sorban, minden egyes
elemet, mint te SQL táblában.

700
00:29:37,751 --> 00:29:39,750
És mi ez lehetővé teszi számomra
tennie, hogy egy csomó dolgot

701
00:29:39,750 --> 00:29:41,124
és adj egy nagy rugalmasságot.

702
00:29:41,124 --> 00:29:45,360
Ebben a konkrét esetben, I
van a termék dokumentumokat.

703
00:29:45,360 --> 00:29:49,090
És ebben a konkrét
Például, mindent

704
00:29:49,090 --> 00:29:51,930
egy olyan dokumentum, a termékek asztalra.

705
00:29:51,930 --> 00:29:56,510
És a terméket a könyv talán
Van egy ID típusú, amely meghatározza egy könyvet.

706
00:29:56,510 --> 00:29:59,180
És az alkalmazás
váltana az ID.

707
00:29:59,180 --> 00:30:02,570
>> A ás alkalmazások, megyek
mondani ó, milyen rekordot típusú ez?

708
00:30:02,570 --> 00:30:04,100
Ó, ez egy könyvet rekordot.

709
00:30:04,100 --> 00:30:05,990
Nyilvántartást kell ezeket a tulajdonságokat.

710
00:30:05,990 --> 00:30:08,100
Hadd hozzon létre egy könyvet objektumot.

711
00:30:08,100 --> 00:30:11,289
Így fogok, hogy kitöltse a
könyv célja ezzel az elemmel.

712
00:30:11,289 --> 00:30:13,080
Következő termék jön és
mondja, mi ez a tétel?

713
00:30:13,080 --> 00:30:14,560
Hát ez a tétel egy albumot.

714
00:30:14,560 --> 00:30:17,340
Ó, kaptam egy teljesen más
feldolgozó rutin, hogy

715
00:30:17,340 --> 00:30:18,487
mert ez az album.

716
00:30:18,487 --> 00:30:19,320
Látod, mire gondolok?

717
00:30:19,320 --> 00:30:21,950
>> Így az alkalmazás tier-- I
csak válassza ki ezeket a feljegyzéseket.

718
00:30:21,950 --> 00:30:23,200
Mindannyian kezdeni jön.

719
00:30:23,200 --> 00:30:24,680
Ők lehetnek a különféle típusú.

720
00:30:24,680 --> 00:30:27,590
És ez az alkalmazás logikáját
hogy kapcsol át az ilyen típusú

721
00:30:27,590 --> 00:30:29,530
és úgy dönt, hogy miként kell feldolgozni őket.

722
00:30:29,530 --> 00:30:33,640
>> Ismét, szóval optimalizálása
sémája a hozzáférési mintát.

723
00:30:33,640 --> 00:30:36,390
Megcsináljuk azt
összeomló ezeket a táblázatokat.

724
00:30:36,390 --> 00:30:39,670
Mi alapvetően figyelembe
ezek normalizált szerkezetek,

725
00:30:39,670 --> 00:30:42,000
és mi építünk
hierarchikus felépítés.

726
00:30:42,000 --> 00:30:45,130
Belül minden egyes ilyen bejegyzések
Megyek látni tömb tulajdonságait.

727
00:30:45,130 --> 00:30:49,400
>> Belül ezt a dokumentumot albumok,
Látok tömbök pályák.

728
00:30:49,400 --> 00:30:53,900
Azok a dalok most become-- ez
Alapvetően ez a gyermek asztal, hogy

729
00:30:53,900 --> 00:30:56,520
létezik itt, ebben a struktúrában.

730
00:30:56,520 --> 00:30:57,975
Tehát akkor ezt a DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Megteheti ezt a MongoDB.

732
00:30:59,810 --> 00:31:01,437
Ezt megteheti bármely NoSQL adatbázisban.

733
00:31:01,437 --> 00:31:03,520
Hozzon létre ilyen típusú
hierarchikus adatszerkezetek

734
00:31:03,520 --> 00:31:07,120
amelyek lehetővé teszik adatok lekérése
Nagyon gyorsan, mert most

735
00:31:07,120 --> 00:31:08,537
Nem kell felelniük.

736
00:31:08,537 --> 00:31:11,620
Amikor egy sort akarunk beszúrni a számok
asztal, vagy egy sort a albumai asztal,

737
00:31:11,620 --> 00:31:13,110
Meg kell felelnie, hogy a séma.

738
00:31:13,110 --> 00:31:18,060
Van, hogy a tulajdonság vagy az
ingatlanokra, amelyek meghatározott annál az asztalnál.

739
00:31:18,060 --> 00:31:20,480
Mindegyiküket,
behelyezésekor azt a sort.

740
00:31:20,480 --> 00:31:21,910
Nem ez a helyzet NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Én is teljesen más
ingatlan minden dokumentumban

742
00:31:24,440 --> 00:31:26,100
hogy helyezze be a gyűjtemény.

743
00:31:26,100 --> 00:31:30,480
Tehát nagyon erős mechanizmust.

744
00:31:30,480 --> 00:31:32,852
És tényleg, hogyan
optimalizálja a rendszer.

745
00:31:32,852 --> 00:31:35,310
Mert most ez a lekérdezés helyett
csatlakozás mindezek asztalok

746
00:31:35,310 --> 00:31:39,160
és a végrehajtó fél tucat lekérdezések
hogy húzza vissza az adatokat szükségem,

747
00:31:39,160 --> 00:31:40,890
Én végrehajtó egy lekérdezést.

748
00:31:40,890 --> 00:31:43,010
És én ismételve
szerte az eredmények beállítva.

749
00:31:43,010 --> 00:31:46,512
ez ad ön egy eszme
A hatalom a NoSQL.

750
00:31:46,512 --> 00:31:49,470
Megyek a fajta megy itt oldalt
és beszélni egy kicsit erről.

751
00:31:49,470 --> 00:31:53,240
Ez több fajta a
marketing vagy technology--

752
00:31:53,240 --> 00:31:55,660
a technológia értékesítésére
típusú vita.

753
00:31:55,660 --> 00:31:58,672
De fontos, hogy megértsük
mert ha megnézzük a felső

754
00:31:58,672 --> 00:32:00,380
itt ezt a táblázatot,
mit keresünk

755
00:32:00,380 --> 00:32:04,030
hívjuk a
technológia hype görbe.

756
00:32:04,030 --> 00:32:06,121
És ez mit jelent,
új cucc jön szóba.

757
00:32:06,121 --> 00:32:07,120
Az emberek azt hiszik, hogy ez jó.

758
00:32:07,120 --> 00:32:09,200
Én már megoldódott minden gondom.

759
00:32:09,200 --> 00:32:11,630
>> Ez lehet a végén
Minden, lehet, hogy mindenki mindent.

760
00:32:11,630 --> 00:32:12,790
És már használhatja is.

761
00:32:12,790 --> 00:32:14,720
És azt mondják, ez a cucc nem működik.

762
00:32:14,720 --> 00:32:17,600
Ez nem igaz.

763
00:32:17,600 --> 00:32:19,105
A régi cucc jobb volt.

764
00:32:19,105 --> 00:32:21,230
És mennek vissza csinál
dolgokat, ahogy voltak.

765
00:32:21,230 --> 00:32:22,730
És akkor végül
mennek, tudod mit?

766
00:32:22,730 --> 00:32:24,040
Ez a cucc nem is olyan rossz.

767
00:32:24,040 --> 00:32:26,192
Ó, ez hogyan működik.

768
00:32:26,192 --> 00:32:28,900
És ha egyszer kitalálni, hogyan
munkák, elkezdenek egyre jobb.

769
00:32:28,900 --> 00:32:32,050
>> És a vicces róla
van, ez a fajta vonalak fel, hogy milyen

770
00:32:32,050 --> 00:32:34,300
hívjuk a technológia elfogadás Curve.

771
00:32:34,300 --> 00:32:36,910
Tehát mi történik, mi
valamiféle technológia ravaszt.

772
00:32:36,910 --> 00:32:39,100
Abban az esetben, adatbázisok,
ez az adatok nyomást.

773
00:32:39,100 --> 00:32:42,200
Beszéltünk a magas vízállás pont
Az adatok nyomás az idők során.

774
00:32:42,200 --> 00:32:46,310
Ha az adatok nyomás elér egy bizonyos
pont, ez egy technológia ravaszt.

775
00:32:46,310 --> 00:32:47,830
>> Egyre túl drága.

776
00:32:47,830 --> 00:32:49,790
Túl sokáig tart az adatok feldolgozására.

777
00:32:49,790 --> 00:32:50,890
Szükségünk van valami jobb.

778
00:32:50,890 --> 00:32:52,890
Kapsz az újítók
ott rohangál,

779
00:32:52,890 --> 00:32:55,050
próbálják kideríteni, mi a megoldás.

780
00:32:55,050 --> 00:32:56,050
Milyen az új ötlet?

781
00:32:56,050 --> 00:32:58,170
>> Mi a második legjobb
módja annak, hogy ezt a dolgot?

782
00:32:58,170 --> 00:32:59,530
És jön valami.

783
00:32:59,530 --> 00:33:03,140
És az emberek az igazi fájdalom,
A srácok a vadi

784
00:33:03,140 --> 00:33:06,390
fognak ugrani rajta,
mert szükség van egy választ.

785
00:33:06,390 --> 00:33:09,690
Most mi elkerülhetetlenül happens-- és
ez történik most NoSQL.

786
00:33:09,690 --> 00:33:11,090
Látom, hogy egész idő alatt.

787
00:33:11,090 --> 00:33:13,610
>> Mi óhatatlanul előfordul az,
az emberek kezdenek új eszközt használva

788
00:33:13,610 --> 00:33:15,490
ugyanúgy használták a régi szerszámot.

789
00:33:15,490 --> 00:33:17,854
És rájönnek, hogy
nem működik olyan jól.

790
00:33:17,854 --> 00:33:20,020
Nem emlékszem, ki vagyok
beszélget korábbi ma.

791
00:33:20,020 --> 00:33:22,080
De ez olyan, mint amikor a
légkalapács találták,

792
00:33:22,080 --> 00:33:24,621
az emberek nem swing át
fejüket törni a betont.

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

794
00:33:27,360 --> 00:33:30,610
>> De ez az, amit az
történik NoSQL ma.

795
00:33:30,610 --> 00:33:33,900
Ha belépsz a legtöbb üzlet,
akarják, hogy NoSQL üzletek.

796
00:33:33,900 --> 00:33:36,510
Mit csinálnak az
ők a NoSQL,

797
00:33:36,510 --> 00:33:39,900
és ők betöltés
tele relációs séma.

798
00:33:39,900 --> 00:33:41,630
Mert így
általuk tervezett adatbázisokat.

799
00:33:41,630 --> 00:33:44,046
És ők vajon miért van
Nem megy túl jól?

800
00:33:44,046 --> 00:33:45,230
Fiú, ez a dolog bűzlik.

801
00:33:45,230 --> 00:33:49,900
Volt, hogy fenntartsák az én
csatlakozik in-- ez olyan, mint, nem, nem.

802
00:33:49,900 --> 00:33:50,800
Fenntartani csatlakozik?

803
00:33:50,800 --> 00:33:52,430
Miért csatlakozott adatokat?

804
00:33:52,430 --> 00:33:54,350
Nem csatlakozik az adatokat NoSQL.

805
00:33:54,350 --> 00:33:55,850
Ön összesítik azt.

806
00:33:55,850 --> 00:34:00,690
>> Tehát, ha szeretné elkerülni ezt, tanulni
hogy a szerszám működik, mielőtt ténylegesen

807
00:34:00,690 --> 00:34:02,010
elindíthatjuk.

808
00:34:02,010 --> 00:34:04,860
Ne próbálja használni az új eszközöket a
ugyanúgy használják a régi eszközöket.

809
00:34:04,860 --> 00:34:06,500
Fogsz egy rossz tapasztalat.

810
00:34:06,500 --> 00:34:08,848
És minden egyes alkalommal
ez az, amit ez az egész.

811
00:34:08,848 --> 00:34:11,389
Amikor elkezdünk jön ide,
azért, mert az emberek rájöttek

812
00:34:11,389 --> 00:34:13,449
hogyan kell használni az eszközöket.

813
00:34:13,449 --> 00:34:16,250
>> Ők is ugyanezt tették, amikor
relációs adatbázisok találták,

814
00:34:16,250 --> 00:34:17,969
és ők váltották fájlrendszereket.

815
00:34:17,969 --> 00:34:20,420
Igyekeztek építeni fájlrendszerek
A relációs adatbázisok

816
00:34:20,420 --> 00:34:22,159
mert ez az, amit az emberek megértették.

817
00:34:22,159 --> 00:34:23,049
Ez nem jött be.

818
00:34:23,049 --> 00:34:26,090
Így értelmezte a legjobb gyakorlatok
A technológia dolgoztok

819
00:34:26,090 --> 00:34:26,730
hatalmas.

820
00:34:26,730 --> 00:34:29,870
Nagyon fontos.

821
00:34:29,870 --> 00:34:32,440
>> Így fogunk bejutni DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB az AWS által
teljes mértékben irányított NoSQL platform.

823
00:34:36,480 --> 00:34:37,719
Mit jelent mértékben irányított jelent?

824
00:34:37,719 --> 00:34:40,010
Ez azt jelenti, hogy nem kell
igazán aggódni semmit.

825
00:34:40,010 --> 00:34:42,060
>> Bejössz, mondd
velünk, szükségem van egy asztal.

826
00:34:42,060 --> 00:34:43,409
Szüksége van ez a sok kapacitást.

827
00:34:43,409 --> 00:34:47,300
Bejön a gombot, és a rendelkezés
az infrastruktúrát a kulisszák mögé.

828
00:34:47,300 --> 00:34:48,310
Most, hogy óriási.

829
00:34:48,310 --> 00:34:51,310
>> Mert ha beszélni
mintegy méretezés adatbázis,

830
00:34:51,310 --> 00:34:53,917
NoSQL adatok klaszterek
skála, futás petabájt,

831
00:34:53,917 --> 00:34:55,750
futás millió
tranzakció másodpercenként,

832
00:34:55,750 --> 00:34:58,180
ezek a dolgok nem kisebb csoportokban.

833
00:34:58,180 --> 00:35:00,830
Beszélünk ezer esetben.

834
00:35:00,830 --> 00:35:04,480
Ügyvezető ezer esetben
akár virtuális esetekben,

835
00:35:04,480 --> 00:35:06,350
egy igazi fájdalom a seggét.

836
00:35:06,350 --> 00:35:09,110
Úgy értem, gondolni minden alkalommal, amikor egy
operációs rendszer patch jön ki

837
00:35:09,110 --> 00:35:11,552
vagy egy új változata az adatbázis.

838
00:35:11,552 --> 00:35:13,260
Az mit jelent
Önnek működésében?

839
00:35:13,260 --> 00:35:16,330
Ez azt jelenti, megvan 1200
kiszolgálók frissíteni kell.

840
00:35:16,330 --> 00:35:18,960
Most még automatizálás,
amely hosszú időt vesz igénybe.

841
00:35:18,960 --> 00:35:21,480
Hogy okozhat egy csomó
működési fejfájás,

842
00:35:21,480 --> 00:35:23,090
mert talán van szolgáltatásokat le.

843
00:35:23,090 --> 00:35:26,070
>> Amint azt frissíteni ezeket az adatbázisokat, én
Lehet csinálni, kék, zöld telepítések

844
00:35:26,070 --> 00:35:29,420
ahol telepíteni és frissíteni felét én
csomópontok, majd frissíteni a másik felét.

845
00:35:29,420 --> 00:35:30,490
Hogy ezeket le.

846
00:35:30,490 --> 00:35:33,410
Tehát infrastruktúrájának kezelése
skála rendkívül fájdalmas.

847
00:35:33,410 --> 00:35:36,210
És AWS veszi, hogy a fájdalom belőle.

848
00:35:36,210 --> 00:35:39,210
És NoSQL adatbázisok,
pedig rendkívül fájdalmas

849
00:35:39,210 --> 00:35:41,780
miatt, ahogy skála.

850
00:35:41,780 --> 00:35:42,926
>> Scale vízszintesen.

851
00:35:42,926 --> 00:35:45,550
Ha azt szeretnénk, hogy egy nagyobb NoSQL
adatbázis, veszel több csomópontban.

852
00:35:45,550 --> 00:35:48,660
Minden csomópont amit vásárolni
Egy másik működési fejfájás.

853
00:35:48,660 --> 00:35:50,830
Szóval valaki erre az Ön számára.

854
00:35:50,830 --> 00:35:52,000
AWS képes erre.

855
00:35:52,000 --> 00:35:54,587
>> Támogatjuk a dokumentum kulcsok értékeit.

856
00:35:54,587 --> 00:35:56,670
Most nem mentünk túl sokat
be, a másik chart.

857
00:35:56,670 --> 00:35:58,750
Van egy csomó más
ízek NoSQL.

858
00:35:58,750 --> 00:36:02,670
Mind a fajta egyre
munged együtt ezen a ponton.

859
00:36:02,670 --> 00:36:06,260
Akkor nézd meg DynamoDB és igent mond,
mindketten egy dokumentumot, és a legfontosabb érték

860
00:36:06,260 --> 00:36:08,412
tárolni ebben a kérdésben.

861
00:36:08,412 --> 00:36:10,620
És lehet azzal érvelni a funkciók
az egyik a másik felett.

862
00:36:10,620 --> 00:36:13,950
Számomra sok ez valóban hat
Egy fél tucat más.

863
00:36:13,950 --> 00:36:18,710
Minden ilyen technológiák egy
finom technológia és finom megoldást.

864
00:36:18,710 --> 00:36:23,390
Nem mondanám, MongoDB jobb vagy
rosszabb, mint Couch, akkor Cassandra,

865
00:36:23,390 --> 00:36:25,994
majd Dynamo, vagy fordítva.

866
00:36:25,994 --> 00:36:27,285
Úgy értem, ezek csak lehetőségek.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Ez gyors és ez
következetes bármilyen szinten.

869
00:36:32,700 --> 00:36:36,210
Tehát ez az egyik legnagyobb
bónuszokat kapsz AWS.

870
00:36:36,210 --> 00:36:40,850
A DynamoDB az a képesség,
hogy egy alacsony egy számjegyű

871
00:36:40,850 --> 00:36:44,040
milliszekundumos késleltetést bármilyen szinten.

872
00:36:44,040 --> 00:36:45,720
Ez volt a tervezés célja a rendszer.

873
00:36:45,720 --> 00:36:49,130
És mi van az ügyfelek, hogy csinálnak
Több millió tranzakció másodpercenként.

874
00:36:49,130 --> 00:36:52,670
>> Most átnézzük néhány ilyen
Használja esetben néhány perc múlva itt.

875
00:36:52,670 --> 00:36:55,660
Integrált hozzáférést control--
mi hívjuk

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, vagy IAM.

877
00:36:57,920 --> 00:37:01,980
Ez áthatja minden rendszer,
Minden szolgáltatás, amely AWS kínál.

878
00:37:01,980 --> 00:37:03,630
DynamoDB sem kivétel.

879
00:37:03,630 --> 00:37:06,020
Akkor hozzáférés szabályozására
A DynamoDB táblákat.

880
00:37:06,020 --> 00:37:09,960
Szerte az összes AWS számlái
meghatározó hozzáférési szerepkörök és engedélyek

881
00:37:09,960 --> 00:37:12,140
az IAM infrastruktúra.

882
00:37:12,140 --> 00:37:16,630
>> És ez egy alapvető és kulcsfontosságú eleme
hívjuk eseményvezérelt programozás.

883
00:37:16,630 --> 00:37:19,056
Most ez egy új paradigma.

884
00:37:19,056 --> 00:37:22,080
>> Közönség: Hogy van a ráta igaz
pozitív versus hamis negatív

885
00:37:22,080 --> 00:37:24,052
a beléptető rendszer?

886
00:37:24,052 --> 00:37:26,260
Rick Houlihan: valódi pozitív
versus hamis negatív?

887
00:37:26,260 --> 00:37:28,785
Közönség: Visszatérő mit
akkor visszatér?

888
00:37:28,785 --> 00:37:33,720
Szemben a hóba, hogy
nem tér vissza, ha kell érvényesíteni?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> Rick Houlihan: nem tudtam megmondani.

891
00:37:38,050 --> 00:37:40,140
Ha van olyan hibák
semmiképpen, hogy

892
00:37:40,140 --> 00:37:42,726
Nem vagyok az a személy megkérdezni
hogy az adott kérdést.

893
00:37:42,726 --> 00:37:43,850
De ez egy jó kérdés.

894
00:37:43,850 --> 00:37:45,905
Lennék kíváncsi
hogy magam, tényleg.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> És így aztán megint, új paradigma
eseményvezérelt programozás.

897
00:37:51,320 --> 00:37:55,160
Ez a gondolat, hogy tudsz
telepíteni komplex alkalmazások

898
00:37:55,160 --> 00:37:59,720
működhet egy nagyon, nagyon magas szintű
infrastruktúrákkal nem egyáltalán.

899
00:37:59,720 --> 00:38:02,120
Nélkül rögzített
infrastruktúra nélkül.

900
00:38:02,120 --> 00:38:04,720
És akkor beszéljünk egy kicsit
arról, hogy mit jelent, mint mi

901
00:38:04,720 --> 00:38:06,550
kap, hogy a következő néhány listákon.

902
00:38:06,550 --> 00:38:08,716
>> Az első dolog, amit megteszek
ez fogunk beszélni, asztalok.

903
00:38:08,716 --> 00:38:10,857
API adattípusok Dynamo.

904
00:38:10,857 --> 00:38:13,190
És az első dolog, akkor
észrevenni, ha megnézi ezt,

905
00:38:13,190 --> 00:38:17,930
Ha még nem ismeri, minden adatbázis,
adatbázisok valóban két fajta API-k

906
00:38:17,930 --> 00:38:18,430
Hívnám meg.

907
00:38:18,430 --> 00:38:21,570
Vagy két API.

908
00:38:21,570 --> 00:38:23,840
Az egyik ilyen lenne
igazgatási API.

909
00:38:23,840 --> 00:38:26,710
>> A dolog úgy vigyázni
a funkciók a adatbázisban.

910
00:38:26,710 --> 00:38:31,340
Konfigurálása tároló motor,
felállítása és hozzá táblákat.

911
00:38:31,340 --> 00:38:35,180
adatbázis létrehozása
katalógusok és példányok.

912
00:38:35,180 --> 00:38:40,450
Ezek things-- a DynamoDB, akkor
nagyon rövid, rövid listák.

913
00:38:40,450 --> 00:38:43,120
>> Tehát más adatbázisok,
lehet, hogy több tucat

914
00:38:43,120 --> 00:38:45,680
A parancsok, az adminisztratív
parancsokat, konfigurálásához

915
00:38:45,680 --> 00:38:47,290
A további lehetőségek.

916
00:38:47,290 --> 00:38:51,234
Ebben DynamoDB akkor nem kell azokat, mert
nem konfigurálja a rendszert, amit csinálunk.

917
00:38:51,234 --> 00:38:54,150
Tehát az egyetlen dolog, amit tennie kell, hogy
mondd meg, mit méretű tábla van szükségem.

918
00:38:54,150 --> 00:38:55,660
Így kapsz egy nagyon
korlátozott parancsokat.

919
00:38:55,660 --> 00:38:58,618
>> Kapsz egy új táblázat létrehozásához Update, táblázat,
Táblázat törlése, és írja táblázat.

920
00:38:58,618 --> 00:39:01,150
Ezek azok a dolgok, csak
szükség van DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Nem kell a tárolási
motorkonfiguráció.

922
00:39:03,294 --> 00:39:04,960
Nem kell aggódni a replikáció.

923
00:39:04,960 --> 00:39:06,490
Nem kell aggódni sharding.

924
00:39:06,490 --> 00:39:07,800
>> Nem kell aggódni
bármilyen ez a cucc.

925
00:39:07,800 --> 00:39:08,740
Tesszük mindezt az Ön számára.

926
00:39:08,740 --> 00:39:11,867
Szóval ez egy hatalmas többlet
ez csak emelte ki a lemezt.

927
00:39:11,867 --> 00:39:13,200
Aztán ott van a szifilisz szereplők.

928
00:39:13,200 --> 00:39:17,740
Szifilisz valami, amit mi
hívja az adatbázisban, ez

929
00:39:17,740 --> 00:39:19,860
Create, Update, Delete szereplők.

930
00:39:19,860 --> 00:39:24,180
Ezek a közös
adatbázis-műveletek.

931
00:39:24,180 --> 00:39:31,299
Dolgok, mint eladási tétel, hogy a tétel, frissítés
tételek, törölje elemek, kötegelt lekérdezést, szkennelni.

932
00:39:31,299 --> 00:39:32,840
Ha azt szeretnénk, hogy átvizsgálja a teljes táblázatot.

933
00:39:32,840 --> 00:39:34,220
Húzza le mindent az asztalra.

934
00:39:34,220 --> 00:39:37,130
Az egyik szép dolog DynamoDB
ez lehetővé teszi a párhuzamos szkennelés.

935
00:39:37,130 --> 00:39:40,602
Így tulajdonképpen hadd tudja, hogy hány
szálak szeretne futni, hogy a vizsgálat.

936
00:39:40,602 --> 00:39:41,810
És tudjuk futtatni azokat a szálakat.

937
00:39:41,810 --> 00:39:43,985
Mi lehet pörögni, hogy átvizsgálja fel
több téma

938
00:39:43,985 --> 00:39:49,060
így végig a teljes táblázatot
hely nagyon, nagyon gyorsan DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> A másik API amink van
Így hívjuk a Streams API.

940
00:39:51,490 --> 00:39:52,940
Nem fogunk beszélni is
sokat erről most.

941
00:39:52,940 --> 00:39:55,189
Van néhány tartalmi később
A fedélzeti erről.

942
00:39:55,189 --> 00:39:59,910
De Streams valóban running--
úgy mondanám, hogy az idő megrendelt

943
00:39:59,910 --> 00:40:01,274
és partíció változtatási napló.

944
00:40:01,274 --> 00:40:03,940
Minden, ami történik a
A táblázat azt mutatja, akár a patak.

945
00:40:03,940 --> 00:40:05,940
>> Minden levelet az asztalra
felbukkan a patak.

946
00:40:05,940 --> 00:40:08,370
Elolvashatja az a folyam, és
meg tudod csinálni a dolgokat vele.

947
00:40:08,370 --> 00:40:10,150
Megbeszéljük, mit
típusú dolgokat

948
00:40:10,150 --> 00:40:13,680
köze a dolgokat, mint a replikáció,
megteremtése másodlagos indexek.

949
00:40:13,680 --> 00:40:17,620
Mindenféle nagyon klassz
dolog, amit tehetünk vele.

950
00:40:17,620 --> 00:40:19,150
>> Adattípusok.

951
00:40:19,150 --> 00:40:23,320
Ebben DynamoDB, támogatjuk mindkét kulcsfontosságú
érték és a dokumentum adattípusok.

952
00:40:23,320 --> 00:40:26,350
A bal oldalon a képernyő
Itt megvan a alaptípusa.

953
00:40:26,350 --> 00:40:27,230
Kulcs érték típusok.

954
00:40:27,230 --> 00:40:30,040
Ezek húrok,
szám, és a futtatható fájlok.

955
00:40:30,040 --> 00:40:31,640
>> Tehát csak három alaptípusa.

956
00:40:31,640 --> 00:40:33,700
És akkor lehet készletek e.

957
00:40:33,700 --> 00:40:37,650
Az egyik jó dolog a NoSQL van
akkor tartalmazhat tömböket tulajdonságait.

958
00:40:37,650 --> 00:40:42,050
És DynamoDB akkor tartalmazhat tömbök
Az alaptípus, mint egy gyökér ingatlan.

959
00:40:42,050 --> 00:40:43,885
>> És akkor ott van a dokumentum típusokat.

960
00:40:43,885 --> 00:40:45,510
Hány ember ismeri a JSON?

961
00:40:45,510 --> 00:40:47,130
Srácok ismeri JSON annyira?

962
00:40:47,130 --> 00:40:49,380
Ez alapvetően a JavaScript,
Objektum, jelölés.

963
00:40:49,380 --> 00:40:52,510
Ez lehetővé teszi, hogy alapvetően
meghatározzák hierarchikus struktúrába.

964
00:40:52,510 --> 00:40:58,107
>> Tárolhat JSON dokumentum
DynamoDB közös összetevők használata

965
00:40:58,107 --> 00:41:00,940
vagy építőelemek, amelyek rendelkezésre állnak
A legtöbb programozási nyelv.

966
00:41:00,940 --> 00:41:03,602
Tehát ha van a Java, akkor
nézi térképek és jegyzékek.

967
00:41:03,602 --> 00:41:05,060
Én is készített objektumok a területen térképet.

968
00:41:05,060 --> 00:41:08,030
A térképen kulcsértékekkel
tárolni tulajdonságait.

969
00:41:08,030 --> 00:41:10,890
És talán van listái
belüli értékek ezeket a tulajdonságokat.

970
00:41:10,890 --> 00:41:13,490
Akkor tárolja a komplex
hierarchikus felépítés

971
00:41:13,490 --> 00:41:16,320
mint egyetlen tulajdonság
Egy DynamoDB elemet.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Tehát táblázatok DynamoDB, mint a legtöbb
NoSQL adatbázisok, táblázatok tételek.

974
00:41:24,460 --> 00:41:26,469
Ebben MongoDB szeretnéd
hívja ezeket a dokumentumokat.

975
00:41:26,469 --> 00:41:27,760
És ez lenne a kanapén bázist.

976
00:41:27,760 --> 00:41:28,900
Szintén egy dokumentumot adatbázisban.

977
00:41:28,900 --> 00:41:29,941
Ezt nevezed te ezeket a dokumentumokat.

978
00:41:29,941 --> 00:41:32,930
Dokumentumokat vagy attribútumokat.

979
00:41:32,930 --> 00:41:35,850
Az attribútumok léteznek, vagy
Nem létezik a tételt.

980
00:41:35,850 --> 00:41:38,520
Ebben DynamoDB, van
egy kötelező attribútum.

981
00:41:38,520 --> 00:41:43,880
Pont, mint a relációs adatbázisok,
van egy elsődleges kulcsot az asztalon.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB van mit nevezünk kettőskereszt.

983
00:41:46,010 --> 00:41:48,280
Hash kulcsnak egyedinek kell lennie.

984
00:41:48,280 --> 00:41:52,580
Szóval amikor meghatározza a hash tábla,
Alapvetően, amit mondok

985
00:41:52,580 --> 00:41:54,110
van minden elem lesz a kettőskereszt gombot.

986
00:41:54,110 --> 00:41:58,520
És minden kettőskereszt gombot egyedinek kell lennie.

987
00:41:58,520 --> 00:42:01,200
>> Minden elem határozza
az, hogy egyedi kettőskereszt gombot.

988
00:42:01,200 --> 00:42:02,940
És ott csak az egyik.

989
00:42:02,940 --> 00:42:05,820
Ez rendben van, de sokszor
amit az embereknek szükségük

990
00:42:05,820 --> 00:42:08,170
van, amit akarnak ezen a hash
gombot, lépjen egy kicsit

991
00:42:08,170 --> 00:42:11,010
mint egy egyedi azonosítót.

992
00:42:11,010 --> 00:42:15,240
Gyakran szeretnénk használni, hogy a kettőskereszt gombot
mint a felső szintű összesítés vödör.

993
00:42:15,240 --> 00:42:19,160
És ahogy mi tesszük, hogy a
hozzátéve, hogy mit nevezünk tartományban gombot.

994
00:42:19,160 --> 00:42:22,460
>> Tehát ha ez egy hash csak
asztal, ez egyedinek kell lennie.

995
00:42:22,460 --> 00:42:27,040
Ha ez egy hash és a tartomány asztalra, a
kombinációja a hash és a tartomány

996
00:42:27,040 --> 00:42:28,640
egyedinek kell lennie.

997
00:42:28,640 --> 00:42:30,110
Tehát gondolj, hogy ez így.

998
00:42:30,110 --> 00:42:32,140
Ha van egy fórum.

999
00:42:32,140 --> 00:42:39,010
És a forma téma, azt
hozzászólás, és azt válaszokat.

1000
00:42:39,010 --> 00:42:42,630
>> Szóval lehet, hogy egy hash
gombot, ami a téma azonosítója.

1001
00:42:42,630 --> 00:42:46,650
És talán van egy sor kulcsfontosságú,
amely a válasz azonosítója.

1002
00:42:46,650 --> 00:42:49,650
Így ha azt akarom, hogy minden a
válaszokat adott témában,

1003
00:42:49,650 --> 00:42:52,370
Én is csak lekérdezni a hash.

1004
00:42:52,370 --> 00:42:55,190
Én csak azt mondom, hogy nekem minden
Az elemek, amelyek ezt a hash.

1005
00:42:55,190 --> 00:43:01,910
És fogok kapni minden kérdést
vagy postai úton az adott témában.

1006
00:43:01,910 --> 00:43:03,910
Ezek a felső szintű összeállítások
nagyon fontosak.

1007
00:43:03,910 --> 00:43:07,370
Támogatják az elsődleges hozzáférési
minta a kérelmet.

1008
00:43:07,370 --> 00:43:09,420
Általánosságban elmondható, hogy ez az
az, amit akarok.

1009
00:43:09,420 --> 00:43:11,780
Szeretnénk, hogy table--
ahogy betölteni az asztalra,

1010
00:43:11,780 --> 00:43:16,640
azt szeretné felépíteni az adatokat
belül a táblázat olyan módon

1011
00:43:16,640 --> 00:43:20,140
hogy az alkalmazás nagyon
gyorsan letölteni az eredményeket.

1012
00:43:20,140 --> 00:43:24,510
És sokszor a módja, hogy a
fenntartani ezeket a csoportosulásai, mint mi

1013
00:43:24,510 --> 00:43:25,650
amibe az adatok.

1014
00:43:25,650 --> 00:43:31,110
Alapvetően mi terjed az adatokat
a fényes vödör, mert jön.

1015
00:43:31,110 --> 00:43:35,210
>> Választék gombok lehetővé teszik me-- hash
A kulcsok a egyenlőséget.

1016
00:43:35,210 --> 00:43:39,490
Amikor lekérdezés egy hash, azt kell mondanom,
adj egy hash, hogy egyenlő ennek.

1017
00:43:39,490 --> 00:43:41,950
Amikor lekérdezni egy sor, én
lehet mondani, hogy nekem egy tartományban

1018
00:43:41,950 --> 00:43:47,040
használó bármilyen
Gazdag üzemeltető, hogy támogatjuk.

1019
00:43:47,040 --> 00:43:49,200
Add nekem az összes elemet egy hash.

1020
00:43:49,200 --> 00:43:52,520
Vajon egyenlő, nagyobb,
kevesebb, mint, nem is kezdődik,

1021
00:43:52,520 --> 00:43:54,145
Létezik a két érték között?

1022
00:43:54,145 --> 00:43:56,811
Tehát az ilyen típusú tartomány lekérdezések
hogy mi mindig érdekelt.

1023
00:43:56,811 --> 00:43:59,650
Most egy dolog adatok, ha
megnézi adatokhoz való hozzáférés, ha

1024
00:43:59,650 --> 00:44:02,360
hozzáférést az adatokhoz, ez
Mindig csak egy összesítés.

1025
00:44:02,360 --> 00:44:05,770
Ez mindig a rekordok
hogy kapcsolódik ehhez.

1026
00:44:05,770 --> 00:44:10,390
Adj nekem mindent itt that's-- összes
A tranzakciók ezt a hitelkártya

1027
00:44:10,390 --> 00:44:12,500
az elmúlt hónapban.

1028
00:44:12,500 --> 00:44:13,960
Ez egy összesítés.

1029
00:44:13,960 --> 00:44:17,490
>> Szinte mindent csinálsz a
adatbázis valamilyen összesítés.

1030
00:44:17,490 --> 00:44:21,530
Tehát, hogy képes, hogy képes legyen meghatározni
Ezek vödrök és adja meg ezeket a tartományban

1031
00:44:21,530 --> 00:44:24,950
tulajdonítja, hogy képes lekérdezni a,
azok gazdag lekérdezések támogatására számos,

1032
00:44:24,950 --> 00:44:27,165
Sok-sok alkalmazás elérhető mintákat.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Tehát a másik dolog a kettőskereszt gombot
nem az, ez ad nekünk egy mechanizmust

1035
00:44:35,000 --> 00:44:37,740
hogy képes terjedni az adatok körül.

1036
00:44:37,740 --> 00:44:40,390
NoSQL adatbázisok működnek a legjobban
amikor az adatok egyenletesen

1037
00:44:40,390 --> 00:44:41,740
elosztva a klaszter.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Hány ember ismeri
a hash algoritmusok?

1040
00:44:47,050 --> 00:44:49,860
Amikor azt mondom, hash és hashing--
mert egy algoritmus

1041
00:44:49,860 --> 00:44:54,140
egy módja, hogy képes generálni
egy véletlen értéket adott értéket.

1042
00:44:54,140 --> 00:44:59,300
Tehát ebben az esetben a
hash algoritmus futunk az ND 5 alapú.

1043
00:44:59,300 --> 00:45:04,765
>> És ha van egy azonosító, és ez a
az én kettőskereszt gombot, van 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Amikor futtatom a hash algoritmust,
ez megy, hogy jöjjön vissza, és azt mondják,

1045
00:45:07,390 --> 00:45:10,800
valamint 1értéke 7B, 2
egyenlő 48, 3 egyenlő CD-t.

1046
00:45:10,800 --> 00:45:13,092
Ők elterjedt az egész kulcsfontosságú helyet.

1047
00:45:13,092 --> 00:45:14,050
És miért csinálod ezt?

1048
00:45:14,050 --> 00:45:17,120
Mert ami biztos, hogy tudok
tedd a feljegyzések több csomópontot.

1049
00:45:17,120 --> 00:45:19,574
>> Ha én csinálom ezt
inkrementálisan, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
És van egy hash-tartományban,
fut ebben a konkrét esetben,

1051
00:45:21,990 --> 00:45:24,785
egy kis hash helyet,
fut 00-tól FF,

1052
00:45:24,785 --> 00:45:27,951
akkor a rekordok fognak jönni
és ők fognak menni 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
Mi történik?

1055
00:45:31,800 --> 00:45:34,860
Minden betét lesz ugyanazon a csomóponton.

1056
00:45:34,860 --> 00:45:36,070
Látod, mire gondolok?

1057
00:45:36,070 --> 00:45:40,910
>> Mert amikor szét a térben,
és én terjedt ezeket a feljegyzéseket az egész,

1058
00:45:40,910 --> 00:45:45,950
és én partíció, fogok mondani
1. partíció van kulcsa tér 0-54.

1059
00:45:45,950 --> 00:45:47,720
2. partíciót 55-89.

1060
00:45:47,720 --> 00:45:49,780
3. Partíció AA a FF.

1061
00:45:49,780 --> 00:45:53,740
Tehát, ha én vagyok a lineárisan növekvõ
Azonosítók, akkor láthatjuk, hogy mi történik.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, minden módon akár 54.

1063
00:45:57,410 --> 00:46:00,030
Szóval, mint én vagyok kalapálni a
feljegyzések a rendszerbe,

1064
00:46:00,030 --> 00:46:02,030
minden ott kötött ki fog egy csomópont.

1065
00:46:02,030 --> 00:46:03,160
>> Ez nem jó.

1066
00:46:03,160 --> 00:46:04,820
Ez egy antipattern.

1067
00:46:04,820 --> 00:46:08,760
Ebben MongoDB van ez a probléma
Ha nem használja a kettőskereszt gombot.

1068
00:46:08,760 --> 00:46:11,325
MongoDB megadja a lehetőséget,
A hashing a legfontosabb érték.

1069
00:46:11,325 --> 00:46:13,950
Mindig meg kell csinálni, ha
Ön használ egy megnő hash

1070
00:46:13,950 --> 00:46:17,380
kulcs MongoDB, vagy ha lesz
szegező minden egyes írási hogy egy csomópont,

1071
00:46:17,380 --> 00:46:21,290
és akkor korlátozása
Ön írási teljesítményt rosszul.

1072
00:46:21,290 --> 00:46:24,896
>> Közönség: Ez A9 169 decimális?

1073
00:46:24,896 --> 00:46:28,450
>> Rick Houlihan: Igen, ez
Valahol ott.

1074
00:46:28,450 --> 00:46:29,950
A9, nem tudom.

1075
00:46:29,950 --> 00:46:32,200
Te volna, hogy megkapjam a bináris
a tizedes számológépet.

1076
00:46:32,200 --> 00:46:34,237
Az agyam nem így működik.

1077
00:46:34,237 --> 00:46:36,320
Közönség: Csak egy gyorsat
a Mongo hozzászólás.

1078
00:46:36,320 --> 00:46:39,530
Tehát az a tárgy, azonosító, jön
natív Mongo csinálni?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
Rick Houlihan: Ez azt csinálni?

1081
00:46:41,470 --> 00:46:42,970
Ha megadja azt.

1082
00:46:42,970 --> 00:46:45,030
A MongoDB, akkor lehetőség van.

1083
00:46:45,030 --> 00:46:48,930
Akkor specify-- minden dokumentum
MongoDB rendelkeznie kell egy aláhúzás ID.

1084
00:46:48,930 --> 00:46:50,300
Ez az egyedülálló értéket.

1085
00:46:50,300 --> 00:46:55,240
>> Ebben MongoDB megadhatja
hogy a hash-e vagy sem.

1086
00:46:55,240 --> 00:46:56,490
Ők csak megadja a lehetőséget.

1087
00:46:56,490 --> 00:46:58,198
Ha tudod, hogy ez az
véletlenszerű, nem probléma.

1088
00:46:58,198 --> 00:46:59,640
Nem kell ezt tenni.

1089
00:46:59,640 --> 00:47:04,260
Ha tudja, hogy ez nem véletlen, hogy a
ez megnő, majd tegye a hash.

1090
00:47:04,260 --> 00:47:06,880
>> Most a dolog
hashing, ha egyszer hash

1091
00:47:06,880 --> 00:47:08,800
egy value-- és ez
Ezért hash kulcsok mindig

1092
00:47:08,800 --> 00:47:13,740
egyedi lekérdezések, mert én változtam
az érték, most nem tudok csinálni egy sor kérdés.

1093
00:47:13,740 --> 00:47:15,640
Nem tudom megmondani, ez
között ezt vagy azt,

1094
00:47:15,640 --> 00:47:20,800
mert a hash érték nem megy
egyenértékűnek a tényleges érték.

1095
00:47:20,800 --> 00:47:24,570
Tehát, ha hash
gombot, ez az egyenlőség csak.

1096
00:47:24,570 --> 00:47:28,700
Ez az oka annak, DynamoDB kettőskereszt
lekérdezések mindig egyenlőség csak.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Tehát most egy sor key--
ha hozzáteszem, hogy a tartomány kulcs,

1099
00:47:34,700 --> 00:47:38,180
azok körét kulcs bejegyzések mindnyájan és
kapnak tárolt ugyanazon a partíción.

1100
00:47:38,180 --> 00:47:42,430
Így nagyon gyorsan, egyszerűen
visszakeresni, mert ez a hash,

1101
00:47:42,430 --> 00:47:43,220
ez az a tartomány.

1102
00:47:43,220 --> 00:47:44,928
És látod mindent
azonos hash-

1103
00:47:44,928 --> 00:47:48,550
kap tárolt ugyanazon a partíción helyet.

1104
00:47:48,550 --> 00:47:53,889
Használhatja, hogy a tartomány legfontosabb, hogy segítsen
keresse meg a közeli adatok a szülő.

1105
00:47:53,889 --> 00:47:55,180
Tehát mi vagyok én valójában mit keresel itt?

1106
00:47:55,180 --> 00:47:57,320
Ez egy sok kapcsolat.

1107
00:47:57,320 --> 00:48:01,490
A kapcsolat a kettőskereszt
és a tartomány legfontosabb az egyik, hogy sok.

1108
00:48:01,490 --> 00:48:03,490
Azt lehet több hash kulcsot.

1109
00:48:03,490 --> 00:48:07,610
Csak azt tudom, hogy több tartomány
kulcsokat minden kettőskereszt gombot.

1110
00:48:07,610 --> 00:48:11,910
>> A hash határozza meg a szülő,
A tartomány határozza meg a gyerekek.

1111
00:48:11,910 --> 00:48:15,240
Tehát láthatjuk, van analóg ide
között relációs konstrukció

1112
00:48:15,240 --> 00:48:18,840
és az azonos típusú
konstrukcióból NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Az emberek beszélnek
NoSQL a relációs.

1114
00:48:20,760 --> 00:48:22,200
Ez nem relációs.

1115
00:48:22,200 --> 00:48:24,680
Az adatok mindig kapcsolatokat.

1116
00:48:24,680 --> 00:48:28,172
Ezeket a kapcsolatokat csak
modellezzük másképp.

1117
00:48:28,172 --> 00:48:29,880
Beszéljünk egy kicsit
kicsit a tartósság.

1118
00:48:29,880 --> 00:48:34,860
Amikor írsz, hogy DynamoDB, írja
mindig három-utas terjeszteni.

1119
00:48:34,860 --> 00:48:37,550
Azt jelenti, hogy van három az AZ.

1120
00:48:37,550 --> 00:48:39,160
Az AZ a Szabad zóna.

1121
00:48:39,160 --> 00:48:43,430
Akkor gondolom az Elérhetőség
Zóna, mint egy adatközpont

1122
00:48:43,430 --> 00:48:45,447
vagy egy gyűjtemény a adatközpontok.

1123
00:48:45,447 --> 00:48:47,780
Ezek a dolgok földrajzilag
egymástól elszigetelt

1124
00:48:47,780 --> 00:48:51,610
különböző törészónákban, az egész
más elektromos hálózatok és az árterek.

1125
00:48:51,610 --> 00:48:54,510
A kudarc egyik AZ nem
megy, hogy vegye le a másik.

1126
00:48:54,510 --> 00:48:56,890
Ők is kapcsolódik
valamint a sötét szálakat.

1127
00:48:56,890 --> 00:49:01,240
Támogat egy al 1
milliszekundumos késleltetést között Azs.

1128
00:49:01,240 --> 00:49:05,390
Így a valós idejű adatok ismétlésben
Képesek a multi Azs.

1129
00:49:05,390 --> 00:49:09,990
>> És sokszor a multi AZ telepítések
megfelelnek a magas rendelkezésre állási követelmények

1130
00:49:09,990 --> 00:49:12,930
A legtöbb vállalati szervezetek.

1131
00:49:12,930 --> 00:49:16,139
Tehát DynamoDB terjed
egész három AZS alapértelmezés szerint.

1132
00:49:16,139 --> 00:49:19,430
Mi csak akkor fog a tudás az írási
amikor két említett három csomópont jön vissza

1133
00:49:19,430 --> 00:49:21,470
és azt mondják, igen, megvan.

1134
00:49:21,470 --> 00:49:22,050
Miert van az?

1135
00:49:22,050 --> 00:49:25,950
Mivel az író oldalán mi csak
fog adni az adatokat vissza, amikor

1136
00:49:25,950 --> 00:49:27,570
megkapjuk azt a két csomópont.

1137
00:49:27,570 --> 00:49:30,490
>> Ha én lemásolják az egész
három, és olvasok két,

1138
00:49:30,490 --> 00:49:32,840
Én mindig garantált
hogy legalább egy

1139
00:49:32,840 --> 00:49:35,720
e beolvassa, hogy a
legfrissebb adatok másolatát.

1140
00:49:35,720 --> 00:49:38,340
Ez teszi DynamoDB következetes.

1141
00:49:38,340 --> 00:49:42,450
Most lehet választani, hogy kapcsolja
azok következetes leolvassa.

1142
00:49:42,450 --> 00:49:45,070
Ebben az esetben fogom mondani,
Én csak olvasni egy csomópont.

1143
00:49:45,070 --> 00:49:47,430
És nem tudom garantálni, hogy fog
hogy a leginkább aktuális adatok.

1144
00:49:47,430 --> 00:49:49,450
>> Tehát, ha az írási jön be,
ez nem replikálta még,

1145
00:49:49,450 --> 00:49:50,360
fogsz kapni a másolatot.

1146
00:49:50,360 --> 00:49:52,220
Ez egy végül következetes olvasni.

1147
00:49:52,220 --> 00:49:54,640
És mi ez a feléért.

1148
00:49:54,640 --> 00:49:56,140
Szóval ez valami gondolkodni.

1149
00:49:56,140 --> 00:50:00,160
Amikor olvasod ki DynamoDB, és
te felállítása az olvasás képességét

1150
00:50:00,160 --> 00:50:04,430
egységek, ha úgy dönt, végül
következetes szól, hogy ez egy sokkal olcsóbb,

1151
00:50:04,430 --> 00:50:06,010
ez körülbelül feléért.

1152
00:50:06,010 --> 00:50:09,342
>> És ez így pénzt takarít meg.

1153
00:50:09,342 --> 00:50:10,300
De ez a választás.

1154
00:50:10,300 --> 00:50:12,925
Ha szeretne egy állandó olvasási vagy
Egy végül következetes olvasni.

1155
00:50:12,925 --> 00:50:15,720
Ez olyasmi, hogy lehet választani.

1156
00:50:15,720 --> 00:50:17,659
>> Beszéljünk indexek.

1157
00:50:17,659 --> 00:50:19,450
Így már említettük, hogy
felső szintű összesítés.

1158
00:50:19,450 --> 00:50:23,720
Megvan hash kulcsok, és
megvan tartományban kulcsokat.

1159
00:50:23,720 --> 00:50:24,320
Ez szép.

1160
00:50:24,320 --> 00:50:26,950
És ez az elsődleges tábla, I
Van egy kettőskereszt gombot, kaptam egy tartományban gombot.

1161
00:50:26,950 --> 00:50:27,783
>> Az mit jelent?

1162
00:50:27,783 --> 00:50:30,410
Nekem is van egy tulajdonság, amit
futhat gazdag lekérdezéseket.

1163
00:50:30,410 --> 00:50:31,800
Ez a tartomány gombot.

1164
00:50:31,800 --> 00:50:35,530
A másik attribútumokat, hogy item--
Azt lehet szűrni azokat a tulajdonságokat.

1165
00:50:35,530 --> 00:50:40,050
De nem tudok olyan dolgokat, mint ez
kezdődik, vagy nagyobb, mint.

1166
00:50:40,050 --> 00:50:40,820
>> Hogyan tudom ezt megtenni?

1167
00:50:40,820 --> 00:50:42,860
Én létrehoz egy indexet.

1168
00:50:42,860 --> 00:50:45,340
Van kétféle
indexek DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Az index valóban
Egy másik nézet az asztalra.

1170
00:50:49,002 --> 00:50:50,490
És a helyi másodlagos index.

1171
00:50:50,490 --> 00:50:51,781
>> Az első fogunk beszélni.

1172
00:50:51,781 --> 00:50:57,740
Tehát a helyi secondaries vannak együtt éltek
ugyanazon a partíción, mint az adatok.

1173
00:50:57,740 --> 00:51:00,240
És mint ilyen, ezek a
az azonos fizikai csomóponton.

1174
00:51:00,240 --> 00:51:01,780
Ők mit nevezünk következetes.

1175
00:51:01,780 --> 00:51:04,599
Jelentése, akkor elismerik
Az írási együtt az asztalra.

1176
00:51:04,599 --> 00:51:06,890
Ha az írási érkezik,
azt írjuk át az index.

1177
00:51:06,890 --> 00:51:09,306
Majd írjuk fel az asztalra,
és akkor majd elismerni.

1178
00:51:09,306 --> 00:51:10,490
Szóval ez következetes.

1179
00:51:10,490 --> 00:51:13,174
Miután az írás volt
elismerte az asztaltól,

1180
00:51:13,174 --> 00:51:15,090
akkor garantált, hogy a
helyi másodlagos index

1181
00:51:15,090 --> 00:51:18,380
ugyanaz lesz a jövőkép adatok.

1182
00:51:18,380 --> 00:51:22,390
De mit tesznek lehetővé, amit csinál,
meghatározzák alternatív tartományban kulcsokat.

1183
00:51:22,390 --> 00:51:25,260
>> Van, hogy ugyanazzal a hash
gombot, mint az elsődleges tábla,

1184
00:51:25,260 --> 00:51:29,050
mert együtt elhelyezkedik
ugyanazon a partíción, és ők következetes.

1185
00:51:29,050 --> 00:51:33,110
De azt is létrehoz egy indexet
különböző tartományban kulcsokat.

1186
00:51:33,110 --> 00:51:41,590
Így például, ha lenne egy gyártó
hogy volt egy nyers résztáblázatig jön.

1187
00:51:41,590 --> 00:51:44,590
És nyers részek jönnek, és
ők összesítve szerelvény.

1188
00:51:44,590 --> 00:51:46,840
És talán van egy visszahívás.

1189
00:51:46,840 --> 00:51:50,240
>> Bármilyen része volt, hogy az ebből az
gyártó ezen időpontot követően,

1190
00:51:50,240 --> 00:51:52,840
Meg kell húzni a sort.

1191
00:51:52,840 --> 00:51:55,950
Tudok pörögni index
hogy fognak nézni,

1192
00:51:55,950 --> 00:52:00,760
összesítése napján
gyártását az adott részt.

1193
00:52:00,760 --> 00:52:03,930
Tehát, ha én legfelső szinten asztal
Már hashed gyártó,

1194
00:52:03,930 --> 00:52:07,655
Talán ez volt elhelyezve része azonosító, én
létrehozhat egy index le az asztalhoz

1195
00:52:07,655 --> 00:52:11,140
a kivonatolt gyártó és
mozgott a gyártás időpontját.

1196
00:52:11,140 --> 00:52:14,490
És így azt is mondhatnám, hogy semmit
gyártották különböző időpontok között,

1197
00:52:14,490 --> 00:52:16,804
Meg kell húzni a vonalat.

1198
00:52:16,804 --> 00:52:18,220
Szóval ez egy helyi másodlagos index.

1199
00:52:18,220 --> 00:52:22,280
>> Ezek a hatása,
korlátozza a kettőskereszt gombot helyet.

1200
00:52:22,280 --> 00:52:24,360
Mert együtt létezett
ugyanazon a tárolási csomópont,

1201
00:52:24,360 --> 00:52:26,860
korlátozzák a kettőskereszt gombot
tér 10 gigabájt.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB alatt
asztalok, szétoszlik

1203
00:52:28,950 --> 00:52:31,380
A táblázat minden 10 gigabájt.

1204
00:52:31,380 --> 00:52:34,760
Amikor fel 10 giga adatok azt
go [PHH], és mi adjuk hozzá egy másik csomópont.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Mi nem osztott az LSI
A több partíció.

1207
00:52:42,070 --> 00:52:43,200
Majd szét a táblázatot.

1208
00:52:43,200 --> 00:52:44,679
De nem fogjuk megosztani az LSI.

1209
00:52:44,679 --> 00:52:46,470
Szóval ez valami
Fontos, hogy megértsük

1210
00:52:46,470 --> 00:52:50,070
van, ha csinálsz nagyon,
Nagyon, nagyon nagy összeállítások,

1211
00:52:50,070 --> 00:52:53,860
akkor fogsz korlátozni
10 gigabájt a LSI-k váltották.

1212
00:52:53,860 --> 00:52:56,640
>> Ha ez a helyzet, amit lehet
használja a globális secondaries.

1213
00:52:56,640 --> 00:52:58,630
Globális állórészek
Tényleg egy másik asztalhoz.

1214
00:52:58,630 --> 00:53:01,720
Léteznek teljesen kikapcsol, hogy
oldalán az elsődleges tábla.

1215
00:53:01,720 --> 00:53:04,680
És engedjék meg, hogy talál egy
merőben eltérő szerkezetű.

1216
00:53:04,680 --> 00:53:08,010
Így gondolok rá, mint adat kerül beillesztésre
két különböző táblák, strukturált

1217
00:53:08,010 --> 00:53:09,220
két különböző módon.

1218
00:53:09,220 --> 00:53:11,360
>> Azt is meghatározhatja teljesen
különböző kettőskereszt gombot.

1219
00:53:11,360 --> 00:53:13,490
Azt is meghatározhatja teljesen
különböző tartományban gombot.

1220
00:53:13,490 --> 00:53:15,941
És tudom futtatni ezt
Teljesen függetlenül.

1221
00:53:15,941 --> 00:53:18,190
Ami azt illeti, én már
tartalékolni az én olvasási képességét

1222
00:53:18,190 --> 00:53:21,090
és írd kapacitás én
globális másodlagos indexek

1223
00:53:21,090 --> 00:53:24,240
Teljesen függetlenül
az én elsődleges tábla.

1224
00:53:24,240 --> 00:53:26,640
Ha én határozzák meg, hogy az indexek, elmondom
ez mennyit írni és olvasni

1225
00:53:26,640 --> 00:53:28,610
kapacitása ez lesz használva.

1226
00:53:28,610 --> 00:53:31,490
>> És ez külön
az én elsődleges tábla.

1227
00:53:31,490 --> 00:53:35,240
Most mind a mutatók lehetővé teszik számunkra, hogy
Nem csak azokat hash és a tartomány kulcsok,

1228
00:53:35,240 --> 00:53:38,610
de engedje meg, hogy
projekt további értékeket.

1229
00:53:38,610 --> 00:53:44,950
Tehát, ha azt akarom, hogy olvassa el az index,
és azt akarom, hogy egy kis adathalmazt,

1230
00:53:44,950 --> 00:53:48,327
Nem kell, hogy menjen vissza a fő
táblázatban, hogy a kiegészítő attribútumokat.

1231
00:53:48,327 --> 00:53:50,660
Azt lehet vetíteni azokat a kiegészítő
attribútumok be a táblázatba

1232
00:53:50,660 --> 00:53:53,440
hogy támogassa a hozzáférési minta.

1233
00:53:53,440 --> 00:53:57,700
Tudom, hogy valószínűleg bekerülni valamilyen
Tényleg, really-- bekerülni a gyomok

1234
00:53:57,700 --> 00:53:58,910
itt néhány dolgot.

1235
00:53:58,910 --> 00:54:02,725
Most kaptam sodródni ki ebből.

1236
00:54:02,725 --> 00:54:07,320
>> Közönség: [hallható]
--table kulcsot jelent egy hash?

1237
00:54:07,320 --> 00:54:08,840
Az eredeti hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-léc?

1239
00:54:09,340 --> 00:54:10,200
>> Rick Houlihan: Igen.

1240
00:54:10,200 --> 00:54:11,070
Igen.

1241
00:54:11,070 --> 00:54:15,260
A tábla kulcs alapvetően
rámutat vissza az elemet.

1242
00:54:15,260 --> 00:54:19,280
Tehát egy index mutató vissza
az eredeti példány az asztalra.

1243
00:54:19,280 --> 00:54:22,910
Most lehet választani, hogy építsenek egy
index, amely csak a tábla kulcs,

1244
00:54:22,910 --> 00:54:24,840
és nincs más tulajdonságokkal.

1245
00:54:24,840 --> 00:54:26,570
És miért lehet ilyet?

1246
00:54:26,570 --> 00:54:28,570
Nos, lehet, hogy van nagyon nagy tételek.

1247
00:54:28,570 --> 00:54:31,660
>> Én tényleg csak akkor kell tudni which--
én hozzáférést mintát lehet mondani,

1248
00:54:31,660 --> 00:54:33,760
mely tételeket tartalmazza ezt az ingatlant?

1249
00:54:33,760 --> 00:54:35,780
Nem kell, hogy térjen vissza az elemet.

1250
00:54:35,780 --> 00:54:37,800
Én csak meg kell tudni
mely tételeket tartalmazza azt.

1251
00:54:37,800 --> 00:54:40,700
Szóval lehet építeni indexek
hogy csak a tábla kulcs.

1252
00:54:40,700 --> 00:54:43,360
>> De ez elsősorban mi
Az index adatbázis számára.

1253
00:54:43,360 --> 00:54:46,280
Ez az, hogy képes gyorsan
azonosítani, amely rögzíti,

1254
00:54:46,280 --> 00:54:49,470
mely sorok, amelyek
tételek a táblázatban

1255
00:54:49,470 --> 00:54:51,080
A tulajdonságokat keresem.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, hogy hogyan működnek?

1258
00:54:54,860 --> 00:54:58,340
GSIS alapvetően aszinkron.

1259
00:54:58,340 --> 00:55:02,570
A frissítés érkezik az asztalra,
asztal ezután aszinkron frissítve

1260
00:55:02,570 --> 00:55:03,720
az összes GSIS.

1261
00:55:03,720 --> 00:55:06,680
Ez az, amiért GSIS vannak
végül következetes.

1262
00:55:06,680 --> 00:55:09,440
>> Fontos megjegyezni, hogy a
ha építesz GSIS,

1263
00:55:09,440 --> 00:55:13,110
és megérted te létre
egy másik dimenziója aggregation--

1264
00:55:13,110 --> 00:55:16,594
Most mondjuk egy jó példa
Itt a gyártó.

1265
00:55:16,594 --> 00:55:19,260
Azt hiszem, már beszéltem
orvosi eszköz gyártója.

1266
00:55:19,260 --> 00:55:23,870
Az orvostechnikai eszközök gyártói
sokszor van folytatásos részek.

1267
00:55:23,870 --> 00:55:28,070
A részek, hogy bemegy
csípőprotézis összes

1268
00:55:28,070 --> 00:55:30,200
Van egy kis sorozatszámot rájuk.

1269
00:55:30,200 --> 00:55:33,584
És akár több millió is, és
millió vagy milliárd alkatrészek

1270
00:55:33,584 --> 00:55:35,000
minden eszközt, hogy az általuk szállított.

1271
00:55:35,000 --> 00:55:37,440
Nos, meg kell összesíteni alatt
különféle méretek, az összes alkatrész

1272
00:55:37,440 --> 00:55:39,520
Egy összeállítás, minden
részek készültek

1273
00:55:39,520 --> 00:55:41,670
egy bizonyos vonal, minden
Az alkatrészeket kapott

1274
00:55:41,670 --> 00:55:44,620
magának egy bizonyos gyártó
Egy bizonyos időpontban.

1275
00:55:44,620 --> 00:55:47,940
És ezek csoportosulásai néha
kelj fel a milliárdokat.

1276
00:55:47,940 --> 00:55:50,550
>> Szóval dolgozni néhány
ezek a srácok, akik szenvednek

1277
00:55:50,550 --> 00:55:53,156
mert ők létrehozása
Ezek ginormous csoportosulásai

1278
00:55:53,156 --> 00:55:54,280
A másodlagos indexek.

1279
00:55:54,280 --> 00:55:57,070
Lehet, hogy egy nyers részek
táblázatot, hogy jön a hash csak.

1280
00:55:57,070 --> 00:55:59,090
Minden rész egy egyedi sorszámot.

1281
00:55:59,090 --> 00:56:00,975
Én a sorszámot a hash.

1282
00:56:00,975 --> 00:56:01,600
Ez gyönyörű.

1283
00:56:01,600 --> 00:56:04,160
Saját nyers adatok táblázatban terjed
szerte a legfontosabb helyet.

1284
00:56:04,160 --> 00:56:05,930
Az én [? ír ?]
[? lenyelés?] félelmetes.

1285
00:56:05,930 --> 00:56:07,876
Veszek egy csomó adat.

1286
00:56:07,876 --> 00:56:09,500
Akkor mit csinálnak ők hozzon létre egy GSI.

1287
00:56:09,500 --> 00:56:12,666
És én azt mondom, tudod mit, azt kell látni
minden alkatrész Ennek a gyártónak.

1288
00:56:12,666 --> 00:56:15,060
Nos, hirtelen vagyok
vesz egy milliárd sorok,

1289
00:56:15,060 --> 00:56:17,550
és cucc őket rá
egy csomópontot, mert amikor

1290
00:56:17,550 --> 00:56:21,170
Én összesítik a
gyártó azonosítót, mint a hash,

1291
00:56:21,170 --> 00:56:25,410
és cikkszám, mint a tartomány,
akkor minden hirtelen vagyok

1292
00:56:25,410 --> 00:56:30,530
amivel egy milliárd rész azzá
ez a gyártó megszabadított engem.

1293
00:56:30,530 --> 00:56:34,447
>> Ez is okozhat sok
A nyomás a GSI,

1294
00:56:34,447 --> 00:56:36,030
újra, mert én kalapálni egy csomópont.

1295
00:56:36,030 --> 00:56:38,350
Leteszem mindezeket
illesztett egy csomópont.

1296
00:56:38,350 --> 00:56:40,940
És ez egy igazi problémás használat esetén.

1297
00:56:40,940 --> 00:56:43,479
Most kaptam egy jó design
minta, hogyan lehet elkerülni, hogy.

1298
00:56:43,479 --> 00:56:45,770
És ez az egyik probléma
hogy én mindig működnek.

1299
00:56:45,770 --> 00:56:49,590
De mi történik, az a GSI lehet
nincs elég kapacitás írási

1300
00:56:49,590 --> 00:56:52,330
hogy képes legyen nyomja mindazoknak
sorok egyetlen csomópontot.

1301
00:56:52,330 --> 00:56:55,390
És mi történik akkor a
elsődleges, az ügyfél asztal,

1302
00:56:55,390 --> 00:57:00,180
Az elsődleges tábla lesz fojtva
mert a GSI nem tud lépést tartani.

1303
00:57:00,180 --> 00:57:02,980
Szóval a betét ráta, akkor
esik az elsődleges tábla

1304
00:57:02,980 --> 00:57:06,230
mint az én GSI próbál lépést tartani.

1305
00:57:06,230 --> 00:57:08,850
>> Rendben, GSI, LSI-k,
melyiket érdemes használni?

1306
00:57:08,850 --> 00:57:12,290
LSI-k következetes.

1307
00:57:12,290 --> 00:57:13,750
GSI-k végül következetes.

1308
00:57:13,750 --> 00:57:17,490
Ha ez rendben van, még mindig ajánlott a
GSI, ők sokkal rugalmasabb.

1309
00:57:17,490 --> 00:57:20,270
LSI által lehet modellezni, mint egy GSI.

1310
00:57:20,270 --> 00:57:27,040
És ha az adatok mérete per hash kulcsot
a gyűjtemény meghaladja a 10 gigabájtot,

1311
00:57:27,040 --> 00:57:31,050
akkor fogsz szeretné használni, hogy
GSI, mert ez csak egy kemény korlátot.

1312
00:57:31,050 --> 00:57:32,035
>> Rendben, skálázás.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Átmenő Dynamo DB, akkor
Can rendelkezés [hallhatatlan]

1315
00:57:37,460 --> 00:57:38,680
átmenő egy asztalhoz.

1316
00:57:38,680 --> 00:57:42,740
Jelenleg az ügyfelek, hogy van
tartalékolni 60 billion--

1317
00:57:42,740 --> 00:57:45,970
csinálnak 60 milliárd kéréseket, rendszeresen
futó több mint egy millió kérések

1318
00:57:45,970 --> 00:57:47,790
másodpercenként az asztalunkra.

1319
00:57:47,790 --> 00:57:50,360
Már tényleg nincs
elméleti határ, hogy mennyi

1320
00:57:50,360 --> 00:57:53,730
és milyen gyorsan az asztalra
futtatható Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Vannak olyan puha
korlátokat fiókját

1322
00:57:55,920 --> 00:57:58,170
hogy mi tesz oda, így
hogy nem megbolondul.

1323
00:57:58,170 --> 00:58:00,070
Ha többet szeretne, mint
hogy, nem probléma.

1324
00:58:00,070 --> 00:58:00,820
Gyere mondani.

1325
00:58:00,820 --> 00:58:02,810
Majd kapcsolja ki a tárcsát.

1326
00:58:02,810 --> 00:58:08,210
>> Minden fiók korlátozódik valamilyen szinten
Minden szolgáltatás, csak kapásból

1327
00:58:08,210 --> 00:58:11,920
így az emberek nem mennek őrült
magukat bajba.

1328
00:58:11,920 --> 00:58:12,840
Nincs határ méretű.

1329
00:58:12,840 --> 00:58:14,940
Tudod, hogy bármennyi
A tételek egy asztalon.

1330
00:58:14,940 --> 00:58:17,620
A méret egy tétel
korlátozva 400 kilobájt minden,

1331
00:58:17,620 --> 00:58:20,050
hogy lenne tétel nem az attribútumokat.

1332
00:58:20,050 --> 00:58:24,200
Tehát az összeg az összes attribútumok
korlátozódik 400 kilobájt.

1333
00:58:24,200 --> 00:58:27,300
És akkor megint, van
hogy a kis LSI kérdés

1334
00:58:27,300 --> 00:58:30,405
A 10 GB-os korlát hash.

1335
00:58:30,405 --> 00:58:33,280
Közönség: Kis számú, vagyok, hiányzik
mit mondasz nekem, hogy is--

1336
00:58:33,280 --> 00:58:36,830
Közönség: Ó, 400 kilobájt
a legnagyobb méret db áron.

1337
00:58:36,830 --> 00:58:39,570
Tehát egy elem minden jó tulajdonsága.

1338
00:58:39,570 --> 00:58:43,950
Tehát 400 k a teljes mérete
ezen tárgy, 400 kilobájt.

1339
00:58:43,950 --> 00:58:46,170
Tehát az összes attribútum
egyesítjük, az összes adatot

1340
00:58:46,170 --> 00:58:49,140
ez mindazon tulajdonságokat,
tekerni a teljes mérete,

1341
00:58:49,140 --> 00:58:51,140
Jelenleg ma az elem határ 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Tehát méretezés ismét elért
a particionálás.

1344
00:58:57,046 --> 00:58:58,920
Áteresztőképesség tartalékolni
a tábla szinten.

1345
00:58:58,920 --> 00:59:00,160
És ott tényleg két gomb.

1346
00:59:00,160 --> 00:59:02,400
Azt olvastam kapacitás
írni és kapacitás.

1347
00:59:02,400 --> 00:59:05,530
>> Szóval ezek vannak beállítva
egymástól függetlenül.

1348
00:59:05,530 --> 00:59:08,640
Távirányító intézkedése szigorúan következetes szól.

1349
00:59:08,640 --> 00:59:13,005
OK, így ha azt mondod akarok 1000
Távirányító által azok szigorúan következetes,

1350
00:59:13,005 --> 00:59:14,130
azok konzisztensek szól.

1351
00:59:14,130 --> 00:59:17,130
Ha azt mondod akarok
esetleges következetes olvasás,

1352
00:59:17,130 --> 00:59:19,402
akkor a rendelkezés 1000
Távirányító által, fogsz

1353
00:59:19,402 --> 00:59:21,840
hogy 2000-utóbb
következetes szól.

1354
00:59:21,840 --> 00:59:25,940
És fél áron azoknak,
végül áll szól.

1355
00:59:25,940 --> 00:59:28,520
>> Ismét igazított
egymástól függetlenül.

1356
00:59:28,520 --> 00:59:32,900
És van a throughput--
Ha fogyaszt 100% -a távirányító,

1357
00:59:32,900 --> 00:59:35,960
nem fogod befolyásolja a
elérhetőségét a jogait.

1358
00:59:35,960 --> 00:59:40,161
Szóval ezek teljesen
egymástól független.

1359
00:59:40,161 --> 00:59:43,160
Rendben, tehát az egyik dolog, hogy
Említettem röviden volt fojtás.

1360
00:59:43,160 --> 00:59:44,320
Fojtás rossz.

1361
00:59:44,320 --> 00:59:47,311
Fojtás jelzi rossz nincs SQL.

1362
00:59:47,311 --> 00:59:50,310
Vannak dolgok, amit tehetünk, hogy segítsen
enyhíteni a fojtás, hogy

1363
00:59:50,310 --> 00:59:51,040
tapasztal.

1364
00:59:51,040 --> 00:59:53,240
De a legjobb megoldás
hogy ez vessünk

1365
00:59:53,240 --> 00:59:58,000
Nézd meg, mit csinálsz, mert
van egy anti-minta játékban van.

1366
00:59:58,000 --> 01:00:02,140
>> Ezek a dolgok, dolgok, mint a nem egyenletes
munkaterhelés, gyorsbillentyűk, forró partíciókat.

1367
01:00:02,140 --> 01:00:06,210
Én üti egy adott kulcs teret
Nagyon nehéz néhány különös oka.

1368
01:00:06,210 --> 01:00:07,080
Miért csinálom ezt?

1369
01:00:07,080 --> 01:00:08,710
Nézzük kitalálni.

1370
01:00:08,710 --> 01:00:10,427
Én vagyok keverést én forró adatokat hideg adatokat.

1371
01:00:10,427 --> 01:00:12,510
Hagylak én asztalok kap
Hatalmas, de tényleg

1372
01:00:12,510 --> 01:00:15,970
csak néhány részhalmaza az adatok
ez igazán érdekes számomra.

1373
01:00:15,970 --> 01:00:20,290
Tehát napló adatok, például a sok
ügyfelek kapnak jelentkezzen adat minden nap.

1374
01:00:20,290 --> 01:00:22,490
Kaptak egy hatalmas log adatok.

1375
01:00:22,490 --> 01:00:25,940
>> Ha most dömping minden napló
adatot egy nagy asztal, idővel

1376
01:00:25,940 --> 01:00:28,070
E táblázat fog kapni hatalmas.

1377
01:00:28,070 --> 01:00:30,950
De én tényleg csak az érdekli,
elmúlt 24 órában, az utolsó hét nap,

1378
01:00:30,950 --> 01:00:31,659
Az elmúlt 30 napban.

1379
01:00:31,659 --> 01:00:34,074
Bármi legyen is az idő-ablak
hogy Érdekelne keres

1380
01:00:34,074 --> 01:00:37,010
Az esetben, ha zavar engem, vagy
Amennyiben érdekes számomra,

1381
01:00:37,010 --> 01:00:39,540
ez az egyetlen ablak alkalom, hogy szükségem van.

1382
01:00:39,540 --> 01:00:42,470
Miért is vagyok üzembe 10 éves
Érdemes log adatok a táblázatban?

1383
01:00:42,470 --> 01:00:45,030
Mi okozza a
A táblázatban a fragmentumot.

1384
01:00:45,030 --> 01:00:45,880
>> Egyre hatalmas.

1385
01:00:45,880 --> 01:00:48,340
Ez kezd el terjedni ki
szerte több ezer csomópont.

1386
01:00:48,340 --> 01:00:51,380
És mivel a kapacitás
olyan alacsony, te

1387
01:00:51,380 --> 01:00:54,090
ténylegesen sebesség korlátozás minden
az egyik ilyen egyes csomópontok.

1388
01:00:54,090 --> 01:00:57,120
Szóval kezdjük nézi, hogyan
nem dobunk a táblázat fölött.

1389
01:00:57,120 --> 01:01:01,502
Hogyan kezeljük az adatokat egy kicsit
jobb elkerülni ezeket a problémákat.

1390
01:01:01,502 --> 01:01:02,710
És ez mit néz ki?

1391
01:01:02,710 --> 01:01:04,370
Ez az, amit úgy néz ki, mint a.

1392
01:01:04,370 --> 01:01:06,790
Ez az, amit a rossz NoSQL néz ki.

1393
01:01:06,790 --> 01:01:07,830
>> Kaptam egy forró kulcs itt.

1394
01:01:07,830 --> 01:01:10,246
Ha megnézed az oldalán van,
ezek mind az én partíciókat.

1395
01:01:10,246 --> 01:01:12,630
Kaptam 16 partíciók ide
ezen a bizonyos adatbázisban.

1396
01:01:12,630 --> 01:01:13,630
Tesszük ezt minden alkalommal.

1397
01:01:13,630 --> 01:01:15,046
Én vezetem ezt az ügyfelek minden alkalommal.

1398
01:01:15,046 --> 01:01:16,550
Ezt hívják a hőtérkép.

1399
01:01:16,550 --> 01:01:20,590
Hőtérkép azt mondja nekem, hogy hogyan te
hozzáférését a kulcsfontosságú helyet.

1400
01:01:20,590 --> 01:01:23,700
És mi ez mesélsz
hogy van egy bizonyos hash

1401
01:01:23,700 --> 01:01:26,330
hogy ez a pasi szeret egy
borzasztó sok, mert ő

1402
01:01:26,330 --> 01:01:28,250
üti meg nagyon, nagyon nehéz.

1403
01:01:28,250 --> 01:01:29,260
>> Így a kék szép.

1404
01:01:29,260 --> 01:01:29,900
Szeretjük kék.

1405
01:01:29,900 --> 01:01:30,720
Mi nem tetszik a piros.

1406
01:01:30,720 --> 01:01:33,120
Red, ahol a nyomás
feláll, hogy 100% -os.

1407
01:01:33,120 --> 01:01:35,560
100%, most fogsz prioritású.

1408
01:01:35,560 --> 01:01:39,030
Szóval, ha lát piros vonalak, mint
this-- és ez nem csak Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
Minden NoSQL adatbázis küzd ezzel a problémával.

1410
01:01:41,630 --> 01:01:44,640
Vannak anti-minták, amelyek
vezetni az ilyen típusú feltételek.

1411
01:01:44,640 --> 01:01:49,070
Amit én csinálok, akikkel dolgozom ügyfelekkel
enyhíteni ezeket a feltételeket.

1412
01:01:49,070 --> 01:01:51,840
>> És ez mit néz ki?

1413
01:01:51,840 --> 01:01:54,260
És ez kezd a legtöbb
ki Dynamo DB áteresztőképességű,

1414
01:01:54,260 --> 01:01:56,176
de ez tényleg kezd
A legtöbbet hozza ki a NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Ez nem korlátozódik a Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Ez definitely-- I
Régebben a Mongo.

1417
01:02:02,050 --> 01:02:04,090
Tisztában vagyok a sok NoSQL platformokon.

1418
01:02:04,090 --> 01:02:06,830
Mindenkinek ilyen típusú
A gyorsgomb problémákat.

1419
01:02:06,830 --> 01:02:10,320
Ahhoz, hogy a legtöbbet hozza ki minden NoSQL
adatbázis, konkrétan Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
szeretne létrehozni a táblák
ahol a kettőskereszt gombot elem

1421
01:02:13,320 --> 01:02:18,590
nagy számú különböző értékek,
a magas fokú számosságú.

1422
01:02:18,590 --> 01:02:22,530
Mert ez azt jelenti, írok
hogy sok különböző vödrök.

1423
01:02:22,530 --> 01:02:24,870
>> Minél több vödör vagyok
írásban, annál valószínűbb,

1424
01:02:24,870 --> 01:02:29,100
Én vagyok az terjedt el, hogy írási terhelés vagy
load ki szerte több csomópont,

1425
01:02:29,100 --> 01:02:33,560
annál valószínűbb vagyok, hogy egy
nagy áteresztőképességű az asztalra.

1426
01:02:33,560 --> 01:02:37,440
És akkor azt szeretné, hogy az értékek, hogy
kért meglehetősen egyenletesen idő

1427
01:02:37,440 --> 01:02:39,430
és egyenletesen véletlenszerűen, mint lehetséges.

1428
01:02:39,430 --> 01:02:42,410
Nos, ez elég érdekes,
mert nem tudok igazán

1429
01:02:42,410 --> 01:02:43,960
vezérlés, a felhasználók jönnek.

1430
01:02:43,960 --> 01:02:47,645
Szóval elég mondani, ha kenjük
dolgokat szerte a legfontosabb helyet,

1431
01:02:47,645 --> 01:02:49,270
akkor valószínűleg jobb formában.

1432
01:02:49,270 --> 01:02:51,522
>> Van egy bizonyos
időt szállítás

1433
01:02:51,522 --> 01:02:53,230
hogy nem mész
hogy képes ellenőrzés.

1434
01:02:53,230 --> 01:02:55,438
De ezek tényleg a
két dimenzióban, hogy van,

1435
01:02:55,438 --> 01:02:58,800
hely, hozzáférés egyenletesen
terjedése, az idő, kérések

1436
01:02:58,800 --> 01:03:01,040
érkező, egyenletesen elosztva az időben.

1437
01:03:01,040 --> 01:03:03,110
És ha ezt a két
feltételek teljesülnek,

1438
01:03:03,110 --> 01:03:05,610
akkor ez az, amit ez
fog kinézni.

1439
01:03:05,610 --> 01:03:07,890
Ez sokkal szebb.

1440
01:03:07,890 --> 01:03:08,890
Vagyunk igazán boldog itt.

1441
01:03:08,890 --> 01:03:10,432
Van egy nagyon kiegyenlített hozzáféréssel mintát.

1442
01:03:10,432 --> 01:03:13,098
Igen, talán kapsz egy
kis nyomás hébe-hóba,

1443
01:03:13,098 --> 01:03:14,830
de semmi igazán túlságosan kiterjedt.

1444
01:03:14,830 --> 01:03:17,660
Szóval ez elképesztő, hogy sokszor,
amikor dolgozom ügyfelekkel,

1445
01:03:17,660 --> 01:03:20,670
hogy első grafikon a nagy piros
bár és minden, ami csúnya sárga ez

1446
01:03:20,670 --> 01:03:23,147
az egész hely, amit
jusson ennek gyakorlása

1447
01:03:23,147 --> 01:03:24,980
után egy pár hónap
A re-architektúra,

1448
01:03:24,980 --> 01:03:28,050
ők futó pontosan ugyanolyan
munkateher pontosan ugyanazt a terhelést.

1449
01:03:28,050 --> 01:03:30,140
És ez az, amit keres, mint most.

1450
01:03:30,140 --> 01:03:36,600
Szóval mit kap a NoSQL egy
adatok séma, amely teljesen

1451
01:03:36,600 --> 01:03:38,510
kötődik a hozzáférést mintát.

1452
01:03:38,510 --> 01:03:42,170
>> És ha lehet optimalizálni az adatokat séma
támogatni, hogy a hozzáférés mintát.

1453
01:03:42,170 --> 01:03:45,490
Ha nem, akkor fogsz
hogy az ilyen típusú problémák

1454
01:03:45,490 --> 01:03:46,710
azokkal gyorsbillentyűk.

1455
01:03:46,710 --> 01:03:50,518
>> Közönség: Nos, óhatatlanul néhány helyen
lesznek melegebb, mint mások.

1456
01:03:50,518 --> 01:03:51,450
>> Rick Houlihan: Mindig.

1457
01:03:51,450 --> 01:03:51,960
Mindig.

1458
01:03:51,960 --> 01:03:54,620
Igen, úgy értem mindig van
egy-- és újra, van

1459
01:03:54,620 --> 01:03:56,980
Néhány tervezési minták fogjuk átvészelni
hogy fog beszélni, hogy hogyan kezeled

1460
01:03:56,980 --> 01:03:58,480
ezekkel a szuper nagy összeállítások.

1461
01:03:58,480 --> 01:04:01,260
Úgy értem, kaptam őket,
hogyan kezeljük őket?

1462
01:04:01,260 --> 01:04:03,760
Kaptam egy nagyon jó hasznát esetén
hogy fogunk beszélni, hogy.

1463
01:04:03,760 --> 01:04:05,940
>> Rendben, akkor beszéljünk
néhány ügyfelek most.

1464
01:04:05,940 --> 01:04:06,950
Ezek a srácok AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Nem tudom, ha
ismerik AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Valószínűleg látni őket
Sok a böngészőben.

1467
01:04:10,781 --> 01:04:14,230
Ők ad újracélzás, ők
A legnagyobb hirdetési újracélzás üzleti

1468
01:04:14,230 --> 01:04:14,940
kint.

1469
01:04:14,940 --> 01:04:17,792
Ezek általában rendszeresen elgázolta
60 milliárd tranzakció naponta.

1470
01:04:17,792 --> 01:04:20,000
Csinálnak több mint egy millió
tranzakció másodpercenként.

1471
01:04:20,000 --> 01:04:22,660
Már van egy elég egyszerű táblázatot
szerkezete, a legforgalmasabb asztalra.

1472
01:04:22,660 --> 01:04:26,450
Ez alapvetően csak egy
hash kulcs a sütit,

1473
01:04:26,450 --> 01:04:29,010
a tartomány a demográfiai
kategóriát, majd

1474
01:04:29,010 --> 01:04:31,220
A harmadik tulajdonság az állás.

1475
01:04:31,220 --> 01:04:33,720
>> Tehát mi minden van a cookie-k
böngészőnk a srácoktól.

1476
01:04:33,720 --> 01:04:35,900
És ha elmész egy
résztvevő kereskedő,

1477
01:04:35,900 --> 01:04:39,390
Alapvetően gólt akkor az egész
különböző demográfiai kategóriák.

1478
01:04:39,390 --> 01:04:42,070
Amikor elmész egy honlapot, és
mondasz Látni akarom ezt a ad--

1479
01:04:42,070 --> 01:04:44,920
vagy alapvetően nem mondod, hogy--
de ha megy a honlap

1480
01:04:44,920 --> 01:04:47,550
Azt mondják szeretné látni ezt a hirdetést.

1481
01:04:47,550 --> 01:04:49,370
És mennek kap, hogy hirdetése AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll néz téged az asztalukon.

1483
01:04:51,130 --> 01:04:52,115
Megtalálják a cookie.

1484
01:04:52,115 --> 01:04:53,990
A hirdetők mondja
őket, azt akarom, hogy valaki

1485
01:04:53,990 --> 01:04:58,632
aki középkorú,
40 éves férfi, a sport.

1486
01:04:58,632 --> 01:05:01,590
És gólt akkor azokban a demográfiai
és ők döntenek arról,

1487
01:05:01,590 --> 01:05:02,740
ez egy jó reklám az Ön számára.

1488
01:05:02,740 --> 01:05:10,330
>> Most, hogy van egy SLA a
a hirdetési szolgáltatók

1489
01:05:10,330 --> 01:05:14,510
hogy al-10 milliszekundumos
válasz minden egyes kérelmet.

1490
01:05:14,510 --> 01:05:16,090
Tehát ők a Dynamo DB erre.

1491
01:05:16,090 --> 01:05:18,131
Ők elér minket egy
millió kérelmek másodpercenként.

1492
01:05:18,131 --> 01:05:21,120
Ők tudják, hogy nem minden
kereséseket, osztályozás minden adatot,

1493
01:05:21,120 --> 01:05:26,130
és kap, hogy add linket vissza, hogy
hirdetőnek alatt 10 ms.

1494
01:05:26,130 --> 01:05:29,800
Ez tényleg nagyon fenomenális
végrehajtása, hogy van.

1495
01:05:29,800 --> 01:05:36,210
>> Ezek a srácok actually--
ezek a srácok.

1496
01:05:36,210 --> 01:05:38,010
Nem vagyok biztos benne, hogy ezek a srácok.

1497
01:05:38,010 --> 01:05:40,127
Lehet, hogy ezek a srácok.

1498
01:05:40,127 --> 01:05:42,210
Alapvetően azt mondta us-- nem,
Nem hiszem, hogy ők voltak.

1499
01:05:42,210 --> 01:05:43,000
Azt hiszem, valaki más volt.

1500
01:05:43,000 --> 01:05:44,750
Én dolgoztam egy
ügyfél, hogy azt mondta,

1501
01:05:44,750 --> 01:05:47,040
hogy most, hogy már
elment a Dynamo DB, ők

1502
01:05:47,040 --> 01:05:50,330
több pénzt költünk snack
a fejlesztő csapat minden hónapban

1503
01:05:50,330 --> 01:05:52,886
mint amennyit költeni az adatbázisba.

1504
01:05:52,886 --> 01:05:54,760
Tehát kapsz egy
elképzelést, hogy a költségmegtakarítás

1505
01:05:54,760 --> 01:05:57,889
hogy lehet kapni a Dynamo DB hatalmas.

1506
01:05:57,889 --> 01:05:59,430
Rendben, dropcam egy másik cég.

1507
01:05:59,430 --> 01:06:02,138
Ezek a srác kedves of-- ha úgy gondolja,
A tárgyak internete, dropcam

1508
01:06:02,138 --> 01:06:05,150
alapvetően internetes biztonsági videó.

1509
01:06:05,150 --> 01:06:06,660
Ön tesz a kamerát odakint.

1510
01:06:06,660 --> 01:06:08,180
Fényképezőgép egy mozgásérzékelő.

1511
01:06:08,180 --> 01:06:10,290
Valaki jön,
elindít egy cue pont.

1512
01:06:10,290 --> 01:06:13,540
Rögzítés indítása egy darabig, amíg
nem talál semmilyen mozgást többé.

1513
01:06:13,540 --> 01:06:15,310
Helyezi, hogy a videó fel az interneten.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam volt olyan cég, amely
Alapvetően váltott Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
mert volt tapasztalható
Hatalmas növekedési fájdalom.

1516
01:06:22,200 --> 01:06:25,820
És mi azt mondták,
Hirtelen petabájt adat.

1517
01:06:25,820 --> 01:06:28,070
Fogalmuk sem volt, a szolgáltatás
ilyen sikeres lesz.

1518
01:06:28,070 --> 01:06:32,310
Több bejövő videó, mint a YouTube
az, amit ezek a srácok egyre.

1519
01:06:32,310 --> 01:06:36,780
Az általuk használt DynamoDB követni az összes
metaadatokat minden videó kulcsfontosságú pontokat.

1520
01:06:36,780 --> 01:06:40,282
>> Tehát ezek S3 kanalak kinyomják
minden bináris melléktermékeit.

1521
01:06:40,282 --> 01:06:41,990
És akkor már
Dynamo DB rekordok

1522
01:06:41,990 --> 01:06:44,070
pont az emberek azokra S3 három tárgyat.

1523
01:06:44,070 --> 01:06:47,070
Amikor meg kell nézni egy videót,
ezek a rekordot megkeresni a Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Ezek a linkre kattintva.

1525
01:06:47,903 --> 01:06:49,770
Úgy húzza le a videót S3.

1526
01:06:49,770 --> 01:06:51,590
Szóval ez a fajta, amit ez úgy néz ki, mint.

1527
01:06:51,590 --> 01:06:53,580
És ez egyenesen a csapat.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB csökkenti
szállítási idő a video események

1529
01:06:56,010 --> 01:06:57,590
öt és 10 másodperc.

1530
01:06:57,590 --> 01:07:00,470
Hogy idős relációs boltban,
szoktak menni, és végre

1531
01:07:00,470 --> 01:07:03,780
többszörösen összetett lekérdezések figura
hogy mely videókat, hogy húzza le,

1532
01:07:03,780 --> 01:07:06,690
kevesebb, mint 50 milliszekundum.

1533
01:07:06,690 --> 01:07:08,990
Tehát ez hihetetlen, elképesztő
mennyit teljesítményű

1534
01:07:08,990 --> 01:07:12,990
akkor kap, amikor optimalizálják és
hangol a mögöttes adatbázis

1535
01:07:12,990 --> 01:07:15,110
hogy támogassa a hozzáférési minta.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, ezek a srácok, mi ez,
Fruit Ninja Azt hiszem, ez a dolog.

1537
01:07:20,500 --> 01:07:22,590
Hogy minden fut Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
És ezek a srácok, hogy van egy nagy
fejlesztőcsapat, nagy fejlődés

1539
01:07:26,810 --> 01:07:27,670
üzlet.

1540
01:07:27,670 --> 01:07:29,364
>> Nem jó ops csapat.

1541
01:07:29,364 --> 01:07:31,280
Nem volt sok
működési forrásokat.

1542
01:07:31,280 --> 01:07:33,940
Ők küzdenek próbálják tartani
alkalmazásuk infrastruktúrájukat

1543
01:07:33,940 --> 01:07:34,290
és fut.

1544
01:07:34,290 --> 01:07:35,000
Jöttek hozzánk.

1545
01:07:35,000 --> 01:07:36,251
Úgy nézett, hogy Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Azt mondták, hogy ez a számunkra.

1547
01:07:37,291 --> 01:07:39,470
Ők építették az egész
alkalmazás-keretrendszer rajta.

1548
01:07:39,470 --> 01:07:43,640
Néhány igazán szép hozzászólás itt
a csapat, hogy képesek

1549
01:07:43,640 --> 01:07:46,800
hogy ezentúl az épületben
a játék, és nem

1550
01:07:46,800 --> 01:07:49,010
amelynek fenntartása
infrastruktúra, amely

1551
01:07:49,010 --> 01:07:51,910
vált a hatalmas mennyiségű
A rezsi a csapatnak.

1552
01:07:51,910 --> 01:07:56,170
Szóval ez az, amit a hogy--
hasznot, amit kap Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Rendben, bekerülni
adatmodellezés itt.

1554
01:08:00,930 --> 01:08:03,440
És beszélgettünk egy kicsit a
ez a 1-1, az egyik, hogy sok,

1555
01:08:03,440 --> 01:08:05,060
és sok sok típusú kapcsolatokat.

1556
01:08:05,060 --> 01:08:07,630
És hogyan kezelni ezeket a Dynamo.

1557
01:08:07,630 --> 01:08:10,500
Ebben Dynamo DB használjuk
indexek, általánosságban elmondható,

1558
01:08:10,500 --> 01:08:12,910
forgatni az adatokat
egy ízt a többi.

1559
01:08:12,910 --> 01:08:15,210
Hash kulcsok, kulcsok körét, és az indexek.

1560
01:08:15,210 --> 01:08:18,540
>> Ebben a konkrét
Például a legtöbb állam

1561
01:08:18,540 --> 01:08:23,802
Van egy engedélyezési kötelezettség, hogy
csak egy jogosítványt fejenként.

1562
01:08:23,802 --> 01:08:26,510
Nem mehetsz, hogy két vezető
engedélyeket az állam Boston.

1563
01:08:26,510 --> 01:08:27,500
Nem tehetem meg Texasban.

1564
01:08:27,500 --> 01:08:28,708
Ez a fajta, ahogy van.

1565
01:08:28,708 --> 01:08:32,779
És így a DMV, van kereséseket, mi
szeretnéd nézni a jogosítvány

1566
01:08:32,779 --> 01:08:35,180
a társadalombiztosítási szám.

1567
01:08:35,180 --> 01:08:39,990
Azt akarom, hogy néz ki a felhasználói adatokat
A vezetői engedély száma.

1568
01:08:39,990 --> 01:08:43,620
>> Tehát lehet, hogy egy felhasználó tábla
van egy kettőskereszt gombot a sorozatszám,

1569
01:08:43,620 --> 01:08:47,830
vagy a társadalombiztosítási szám, és
különféle attribútumok határozzák meg a tételt.

1570
01:08:47,830 --> 01:08:49,859
Most az asztalon I
lehetne meghatározni a GSI, hogy

1571
01:08:49,859 --> 01:08:53,370
kibukik, hogy körül, hogy azt mondja, szeretnék
kettőskereszt a licencet, majd

1572
01:08:53,370 --> 01:08:54,252
minden más elem.

1573
01:08:54,252 --> 01:08:57,210
Most, ha akarok kérdezni, és megtalálja a
engedély száma bármely adott Szociális

1574
01:08:57,210 --> 01:08:59,609
Biztonsági száma, tudok
lekérdezni a főtábla.

1575
01:08:59,609 --> 01:09:02,130
>> Ha azt szeretnénk, hogy a lekérdezés, és azt akarom,
hogy a társadalombiztosítási

1576
01:09:02,130 --> 01:09:05,735
szám vagy más attribútumok által
engedély száma, tudom kérdezni a GSI.

1577
01:09:05,735 --> 01:09:08,689
Ez a modell, hogy az egyik
hogy egy kapcsolat.

1578
01:09:08,689 --> 01:09:12,460
Csak egy nagyon egyszerű GSI,
fordítsa ezeket a dolgokat.

1579
01:09:12,460 --> 01:09:13,979
Most beszéljünk egy a sok.

1580
01:09:13,979 --> 01:09:16,450
Az egyik, hogy sok alapvetően
A hash tartományban gombot.

1581
01:09:16,450 --> 01:09:20,510
Ahol kap egy csomó ezzel
felhasználása esetén a monitor adatai.

1582
01:09:20,510 --> 01:09:23,880
Monitor adatai jön a rendszeres
intervallum, mint a tárgyak internete.

1583
01:09:23,880 --> 01:09:26,890
Mi mindig az összes ilyen
megjelenésekkel minden alkalommal.

1584
01:09:26,890 --> 01:09:31,420
>> És azt akarom, hogy megtalálja az összes mért
között egy adott időszakban.

1585
01:09:31,420 --> 01:09:34,220
Ez egy nagyon gyakori lekérdezés
monitoring infrastruktúra.

1586
01:09:34,220 --> 01:09:38,430
Az út megy róla, hogy megtaláljuk a
egyszerű tábla szerkezete, egy asztalnál.

1587
01:09:38,430 --> 01:09:42,250
Van egy eszköz mérési asztal
A kettőskereszt gombot a készüléken ID.

1588
01:09:42,250 --> 01:09:47,340
És van egy sor kulcsfontosságú a
időbélyeg, vagy ebben az esetben, az epikus.

1589
01:09:47,340 --> 01:09:50,350
És ez lehetővé teszi számomra, végre komplex
lekérdezéseket, hogy a tartomány kulcs

1590
01:09:50,350 --> 01:09:54,950
és vissza azokat a rekordokat, hogy
relatív az eredmény

1591
01:09:54,950 --> 01:09:56,310
beállítani, hogy keresem.

1592
01:09:56,310 --> 01:09:58,360
És épít, hogy az egyik
sok kapcsolat

1593
01:09:58,360 --> 01:10:02,340
a primer táblázat felhasználásával
kettőskereszt gombot, tartomány kulcs szerkezete.

1594
01:10:02,340 --> 01:10:04,600
>> Szóval ez a fajta beépített
Írja be a táblázatba a Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Amikor meg egy hash
és a tartomány t tábla vagyok

1596
01:10:07,290 --> 01:10:09,240
meghatározó egy a sok kapcsolatot.

1597
01:10:09,240 --> 01:10:12,770
Ez a szülő-gyermek kapcsolat.

1598
01:10:12,770 --> 01:10:14,620
>> Beszéljünk sok
hogy sok kapcsolatot.

1599
01:10:14,620 --> 01:10:19,170
És ezen a konkrét példában,
megint megyünk használni GSI.

1600
01:10:19,170 --> 01:10:23,500
És beszéljünk játék
forgatókönyv, ahol van egy adott felhasználó.

1601
01:10:23,500 --> 01:10:26,500
Azt akarom, hogy megtudja, az összes játékot,
ő regisztrált vagy játszanak.

1602
01:10:26,500 --> 01:10:29,600
És az adott játék, én
szeretné megtalálni minden felhasználó számára.

1603
01:10:29,600 --> 01:10:31,010
Szóval hogyan tudom megtenni?

1604
01:10:31,010 --> 01:10:34,330
Saját felhasználói játékok asztalra, megyek
hogy egy kettőskereszt gombot a felhasználói azonosítót

1605
01:10:34,330 --> 01:10:35,810
és egy sor kulcsfontosságú a játék.

1606
01:10:35,810 --> 01:10:37,810
>> Tehát egy felhasználó több játékot.

1607
01:10:37,810 --> 01:10:41,380
Ez egy egy a sok közötti kapcsolat
a felhasználó és a játékok játszik.

1608
01:10:41,380 --> 01:10:43,410
És akkor a GSI,
Majd fordítsa, hogy bárhol.

1609
01:10:43,410 --> 01:10:46,679
Majd Hash a játékot, és
Majd terjedhet a felhasználó.

1610
01:10:46,679 --> 01:10:48,970
Tehát, ha azt akarom, hogy minden a
játék a felhasználó játszik,

1611
01:10:48,970 --> 01:10:49,950
Majd kérdezni a főtábla.

1612
01:10:49,950 --> 01:10:52,699
Ha azt akarom, hogy minden felhasználó számára
hogy játszanak egy adott játékban,

1613
01:10:52,699 --> 01:10:53,887
Azt kérdezni a GSI.

1614
01:10:53,887 --> 01:10:54,970
Így látod, hogyan tudjuk ezt megtenni?

1615
01:10:54,970 --> 01:10:58,369
Ön építeni ezeket a GSI, hogy támogassa a
felhasználása az esetben a kérelmet, a hozzáférési

1616
01:10:58,369 --> 01:10:59,410
minta, az alkalmazás.

1617
01:10:59,410 --> 01:11:01,440
>> Ha kell kérdezni a
Ebben a dimenzióban, hadd

1618
01:11:01,440 --> 01:11:03,500
nekem, és indexelheted ezt a dimenziót.

1619
01:11:03,500 --> 01:11:05,850
Ha nem teszem, nem érdekel.

1620
01:11:05,850 --> 01:11:09,060
És a felhasználástól függően az esetben azt
szükség lehet az index, vagy talán nem.

1621
01:11:09,060 --> 01:11:12,390
Ha ez egy egyszerű egy a sok,
Az elsődleges tábla rendben van.

1622
01:11:12,390 --> 01:11:15,860
Ha kell tennem ennyi az
Sok-k, vagy ki kell tegye, hogy azok,

1623
01:11:15,860 --> 01:11:18,390
akkor talán nem kell
a második az index.

1624
01:11:18,390 --> 01:11:20,840
Tehát minden attól függ,
mit akarok csinálni

1625
01:11:20,840 --> 01:11:24,550
és amit én próbálok rutinos.

1626
01:11:24,550 --> 01:11:28,000
>> Valószínűleg nem fogom költeni túl
sok időt beszélünk dokumentumokat.

1627
01:11:28,000 --> 01:11:31,460
Ez lesz egy kicsit, talán,
mélyebb, mint azt kell menni.

1628
01:11:31,460 --> 01:11:33,710
Beszéljünk egy kicsit
a gazdag keresett kifejezést.

1629
01:11:33,710 --> 01:11:37,831
Tehát a Dynamo DB van
a képesség, hogy hozzon létre

1630
01:11:37,831 --> 01:11:39,330
hívjuk vetítés kifejezéseket.

1631
01:11:39,330 --> 01:11:42,660
Vetítési kifejezések egyszerűen
felvette a mezei és az értékeket

1632
01:11:42,660 --> 01:11:44,290
hogy a megjeleníteni kívánt.

1633
01:11:44,290 --> 01:11:46,000
OK, szóval hogy egy választás.

1634
01:11:46,000 --> 01:11:48,010
Azt, hogy egy lekérdezést Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
És én azt mondom, tudod mit, show
nekem csak az öt csillagos értékelés alapján

1636
01:11:51,730 --> 01:11:54,544
e konkrét termék.

1637
01:11:54,544 --> 01:11:55,710
Szóval ez minden, amit látni akarnak.

1638
01:11:55,710 --> 01:11:57,320
Nem akarom látni az összes
más attribútumait a sor,

1639
01:11:57,320 --> 01:11:58,319
Én csak azt szeretném látni ezt.

1640
01:11:58,319 --> 01:12:01,209
Olyan ez, mint az SQL, ha
azt mondják, válassza a csillag vagy táblázatból,

1641
01:12:01,209 --> 01:12:02,000
kapsz mindent.

1642
01:12:02,000 --> 01:12:05,450
Amikor azt mondom, válasszuk a nevét
asztal, én csak kap egy attribútum.

1643
01:12:05,450 --> 01:12:09,070
Ez ugyanaz a fajta dolog
Dynamo DB vagy más NoSQL adatbázisok.

1644
01:12:09,070 --> 01:12:14,510
Szűrőkifejezések engedje meg, hogy
Alapvetően vágni az eredmény meg lefelé.

1645
01:12:14,510 --> 01:12:15,540
Szóval, hogy egy lekérdezés.

1646
01:12:15,540 --> 01:12:17,260
Kérdés kiújulhat 500 példány.

1647
01:12:17,260 --> 01:12:20,255
De én csak azt akarom, hogy a tételek
más tulajdonsága van, hogy ezt mondja.

1648
01:12:20,255 --> 01:12:23,380
OK, úgyhogy kiszűrni azokat a témákat,
amelyek nem felelnek meg az adott lekérdezés.

1649
01:12:23,380 --> 01:12:25,540
Tehát van szűrőkifejezések.

1650
01:12:25,540 --> 01:12:28,310
>> Szűrés kifejezéseket
futtatható bármely attribútum.

1651
01:12:28,310 --> 01:12:30,260
Ők nem szeretik tartományban lekérdezéseket.

1652
01:12:30,260 --> 01:12:32,690
Kérdések merülnek fel szelektívebb.

1653
01:12:32,690 --> 01:12:36,470
Szűrés lekérdezések igényel, hogy menjek
hogy a teljes eredmény eléréséhez, majd

1654
01:12:36,470 --> 01:12:39,170
faragni az adatok nem akarom.

1655
01:12:39,170 --> 01:12:40,660
Miért fontos ez?

1656
01:12:40,660 --> 01:12:42,770
Mert olvastam az egészet.

1657
01:12:42,770 --> 01:12:46,597
Egy lekérdezés, fogok olvasni és
ez lesz egy óriási mintegy adatokat.

1658
01:12:46,597 --> 01:12:48,430
És akkor fogok
faragni, amire szükségem van.

1659
01:12:48,430 --> 01:12:52,080
És ha én csak elhagyásával, a
pár sort, akkor ez rendben van.

1660
01:12:52,080 --> 01:12:53,620
Ez nem olyan hatékony.

1661
01:12:53,620 --> 01:12:57,800
>> De ha olvasok egy egész halom
adatokat, csak faragni egy tétel,

1662
01:12:57,800 --> 01:13:01,490
akkor én leszek a jobb
off-ban, több lekérdezést,

1663
01:13:01,490 --> 01:13:03,030
mert az sokkal szelektívebb.

1664
01:13:03,030 --> 01:13:06,330
Meg fog menteni nekem egy csomó
pénzt, mert azt fizetni, hogy olvasni.

1665
01:13:06,330 --> 01:13:10,430
Amennyiben az eredmények, hogy jön vissza
határon, hogy a huzal kisebb lehet,

1666
01:13:10,430 --> 01:13:11,890
de én fizetem az olvasási.

1667
01:13:11,890 --> 01:13:14,340
Szóval értem, hogy
kapsz az adatokat.

1668
01:13:14,340 --> 01:13:16,420
Ez nagyon fontos a Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Feltételes kifejezések, ez az, amit
nevezhetünk optimista zár.

1670
01:13:19,710 --> 01:13:28,470
Frissítés ha létezik, vagy ha ez az érték
megegyezik azzal, amit az általam megadott.

1671
01:13:28,470 --> 01:13:31,494
És ha van egy időbélyeg egy
rekord, talán olvassa az adatokat.

1672
01:13:31,494 --> 01:13:32,535
Lehet változtatni az adatokat.

1673
01:13:32,535 --> 01:13:35,030
Elmehetnék írási hogy
adatok vissza az adatbázisba.

1674
01:13:35,030 --> 01:13:38,100
Ha valaki megváltoztatta a rekordot,
Az időbélyeg megváltozhatott.

1675
01:13:38,100 --> 01:13:40,370
És így én feltételes
frissítés mondhatnánk frissítés

1676
01:13:40,370 --> 01:13:42,340
ha a timestamp értéke ennek.

1677
01:13:42,340 --> 01:13:46,290
Vagy a frissítés sikertelen lesz, mert valaki
frissítette a rekord időközben.

1678
01:13:46,290 --> 01:13:48,290
>> Ez az, amit nevezünk optimista zárolást.

1679
01:13:48,290 --> 01:13:50,670
Ez azt jelenti, hogy valaki
jöhet, és változtassa meg,

1680
01:13:50,670 --> 01:13:53,100
és fogok észlelni azt
mikor megy vissza kell írni.

1681
01:13:53,100 --> 01:13:56,106
És akkor én is olvasni, hogy
adatokat, és azt mondják, ó, megváltoztatta ezt.

1682
01:13:56,106 --> 01:13:57,230
Meg kell elszámolnia, hogy.

1683
01:13:57,230 --> 01:14:00,490
És tudom változtatni az adatokat én
rögzíteni és alkalmazni egy frissítést.

1684
01:14:00,490 --> 01:14:04,330
Szóval lehet elkapni azokat a járulékos
frissítések között bekövetkezett ideje

1685
01:14:04,330 --> 01:14:08,740
hogy olvassa el az adatokat és a
alkalommal lehet írni az adatokat.

1686
01:14:08,740 --> 01:14:11,520
>> Közönség: És a szűrőt
véleménynyilvánítás valójában azt jelenti, nem

1687
01:14:11,520 --> 01:14:13,020
A szám vagy nem--

1688
01:14:13,020 --> 01:14:14,316
>> [Közbeiktatásával VOICES]

1689
01:14:14,316 --> 01:14:16,232
Rick Houlihan: nem fogok
túl sok ebbe.

1690
01:14:16,232 --> 01:14:17,700
Ez egy tartalék kulcsszó.

1691
01:14:17,700 --> 01:14:20,130
A font nézet egy fenntartva
kulcsszó Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Minden adatbázis saját fenntartva
nevek gyűjtemények nem tudod használni.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, ha megadja
egy font előtt ez,

1694
01:14:27,240 --> 01:14:29,310
megadhatjuk azokat a neveket fölé.

1695
01:14:29,310 --> 01:14:31,840
Ez egy hivatkozott érték.

1696
01:14:31,840 --> 01:14:34,880
Ez valószínűleg nem a legjobb szintaxis
odafenn erre a vitára,

1697
01:14:34,880 --> 01:14:38,090
mert ez lesz a néhány real--
Azt már beszélt több

1698
01:14:38,090 --> 01:14:41,360
erről egy mélyebb szinten.

1699
01:14:41,360 --> 01:14:46,130
>> De elég mondani, ez lehet
legyen lekérdezés beolvasni, ahol views--

1700
01:14:46,130 --> 01:14:50,190
sem font nézetek nagyobb, mint 10.

1701
01:14:50,190 --> 01:14:54,660
Ez egy numerikus érték, igen.

1702
01:14:54,660 --> 01:14:57,322
Ha azt szeretnénk, beszélhetünk
hogy miután a vitát.

1703
01:14:57,322 --> 01:15:00,030
Rendben, szóval bekerülni
Egyes esetekben a legjobb gyakorlatok

1704
01:15:00,030 --> 01:15:02,000
hová megyünk beszélni
néhány apps itt.

1705
01:15:02,000 --> 01:15:03,810
Melyek a használati esetek Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Melyek a tervezési
minták Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> És az első megyünk
beszélni a tárgyak internete.

1708
01:15:09,110 --> 01:15:15,010
Így kapunk egy csomó of-- azt hiszem,
mi it-- több mint 50%

1709
01:15:15,010 --> 01:15:19,370
A forgalom az interneten ezekben a napokban
ténylegesen által generált gépek,

1710
01:15:19,370 --> 01:15:21,930
automatizált folyamatok, és nem az emberek.

1711
01:15:21,930 --> 01:15:25,140
Úgy értem ezt a dolgot, ez a dolog, hogy
Ön viselheti a zsebedben,

1712
01:15:25,140 --> 01:15:28,840
hogy mennyi adat, hogy ez a dolog
tényleges elküldése körül nélküled

1713
01:15:28,840 --> 01:15:30,550
tudom, hogy ez teljesen elképesztő.

1714
01:15:30,550 --> 01:15:34,970
Az Ön helye, információk
milyen gyorsan mész.

1715
01:15:34,970 --> 01:15:38,400
Mit gondolsz, a Google Maps munkák
ha azt mondják nektek, amit a forgalom.

1716
01:15:38,400 --> 01:15:41,275
Ez azért van, mert több millió és
emberek milliói vezetői körül

1717
01:15:41,275 --> 01:15:44,667
A telefonok küld
adatok az egész hely minden alkalommal.

1718
01:15:44,667 --> 01:15:46,500
Tehát az egyik dolog
erről a típusú adatok

1719
01:15:46,500 --> 01:15:50,980
hogy jön, monitor adatai, jelentkezzen
adatok, idősorok, van ez

1720
01:15:50,980 --> 01:15:53,540
Általában csak érdekes
Egy kis idő.

1721
01:15:53,540 --> 01:15:55,580
Ekkortól ez
nem annyira érdekes.

1722
01:15:55,580 --> 01:15:58,390
Szóval beszélgettünk, ne hagyd,
E táblázatokban korlátok nélkül bõvíthetõ.

1723
01:15:58,390 --> 01:16:03,410
Az elképzelés az, hogy talán kaptam 24
órányi események a meleg asztalra.

1724
01:16:03,410 --> 01:16:06,160
És, hogy a forró asztal lesz
tartalékolni egy nagyon magas arány,

1725
01:16:06,160 --> 01:16:07,950
mert túl sok időt vesz egy csomó adat.

1726
01:16:07,950 --> 01:16:10,920
Ez eltart egy csomó adat
és olvasok sokat.

1727
01:16:10,920 --> 01:16:14,560
Van egy csomó működése
lekérdezések futás ellen, hogy az adatokat.

1728
01:16:14,560 --> 01:16:18,120
>> 24 óra után, hé, te
Tudod mit, nem érdekel.

1729
01:16:18,120 --> 01:16:21,150
Így talán minden éjfél tekercs
én asztalomnál át egy új táblát

1730
01:16:21,150 --> 01:16:22,430
és én deprovision ebben a táblázatban.

1731
01:16:22,430 --> 01:16:26,440
És én viszem a távirányító és a
WCU lent, mert 24 órával később

1732
01:16:26,440 --> 01:16:28,630
Nem futok annyi
lekérdezéseket, hogy az adatok.

1733
01:16:28,630 --> 01:16:30,200
Így fogok pénzt takarít meg.

1734
01:16:30,200 --> 01:16:32,940
És talán 30 nap múlva én nem
is kell törődni az egészet.

1735
01:16:32,940 --> 01:16:35,020
Tudtam venni a WCU a
egészen egy,

1736
01:16:35,020 --> 01:16:36,990
mert tudod mit, ez
nem is fog írni.

1737
01:16:36,990 --> 01:16:38,300
Az adatok 30 napos.

1738
01:16:38,300 --> 01:16:40,000
Ez sosem változik.

1739
01:16:40,000 --> 01:16:44,200
>> És ez szinte nem is fog olvasni,
úgyhogy csak hogy ezt a távirányító és 10.

1740
01:16:44,200 --> 01:16:49,372
És én megtakarítás egy csomó pénzt erre
adatokat, és csak fizet a meleg adatok.

1741
01:16:49,372 --> 01:16:52,330
Szóval ez a lényeg, hogy nézd
A ha megnézed egy idősor

1742
01:16:52,330 --> 01:16:54,716
érkező adatok volumene.

1743
01:16:54,716 --> 01:16:55,590
Ezek stratégiák.

1744
01:16:55,590 --> 01:16:58,010
Most tudtam csak hagyjuk, hogy
minden megy ugyanannál az asztalnál

1745
01:16:58,010 --> 01:16:59,461
és csak hagyja, hogy a tábla nőnek.

1746
01:16:59,461 --> 01:17:01,460
Végül, megyek
lásd teljesítménnyel kapcsolatos problémák.

1747
01:17:01,460 --> 01:17:04,060
Megyek kell kezdeni archiválásához
bizonyos, hogy az adatok le az asztalra,

1748
01:17:04,060 --> 01:17:04,720
miegymás.

1749
01:17:04,720 --> 01:17:07,010
>> Nézzük sokkal jobb
úgy az alkalmazást

1750
01:17:07,010 --> 01:17:08,900
így működik ez a módja a jobb.

1751
01:17:08,900 --> 01:17:11,460
Tehát csak az automatikus
az alkalmazás kódját.

1752
01:17:11,460 --> 01:17:13,580
Éjfélkor minden este
nem gördül az asztalra.

1753
01:17:13,580 --> 01:17:17,170
Talán amire szükségem van egy csúszó
ablak 24 órányi adat.

1754
01:17:17,170 --> 01:17:20,277
Ezután rendszeresen vagyok
Adatok felhívása le az asztalra.

1755
01:17:20,277 --> 01:17:22,360
Én levágva egy
Cron job és leteszem azt

1756
01:17:22,360 --> 01:17:24,160
ra ezek más asztalok,
amire szükségetek van.

1757
01:17:24,160 --> 01:17:25,940
Tehát, ha egy borulás működik, ez nagyszerű.

1758
01:17:25,940 --> 01:17:27,080
Ha nem, akkor vágja.

1759
01:17:27,080 --> 01:17:29,640
De maradjunk a forró adatok
távol a hideg adatokat.

1760
01:17:29,640 --> 01:17:32,535
Ez fog menteni egy csomó pénzt, és
hogy az asztalok szempontból hatékonyabb.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Így a következő dolog, fogunk beszélni
arról van szó, termék katalógus.

1763
01:17:38,210 --> 01:17:42,000
Termék katalógus
elég gyakori használatra esetében.

1764
01:17:42,000 --> 01:17:46,600
Ez valójában egy nagyon gyakori motívum
hogy majd meglátjuk a különböző dolgokat.

1765
01:17:46,600 --> 01:17:48,870
Tudja, Twitter
Például, egy forró csipog.

1766
01:17:48,870 --> 01:17:51,280
Mindenki jön és
megragadta, hogy csipog.

1767
01:17:51,280 --> 01:17:52,680
Árukatalógus, kaptam egy eladó.

1768
01:17:52,680 --> 01:17:54,120
Kaptam egy forró eladó.

1769
01:17:54,120 --> 01:17:57,277
Kaptam 70.000 kérelmek száma
második eljövetele egy termék

1770
01:17:57,277 --> 01:17:58,860
leírás az én termékkatalógusban.

1771
01:17:58,860 --> 01:18:02,384
Ezt látjuk a kiskereskedelmi
művelet egy kicsit.

1772
01:18:02,384 --> 01:18:03,550
Szóval hogyan foglalkozzunk vele?

1773
01:18:03,550 --> 01:18:04,924
Kizárt, hogy foglalkozzanak ezzel.

1774
01:18:04,924 --> 01:18:07,110
Minden az én felhasználókat szeretné látni
ugyanazt az adatot.

1775
01:18:07,110 --> 01:18:09,410
Ők jönnek, egyidejűleg.

1776
01:18:09,410 --> 01:18:11,920
És mind kérelmek benyújtása
az azonos adatot.

1777
01:18:11,920 --> 01:18:16,240
Ez ad nekem, hogy a forró kulcsot, hogy nagy piros
csík én chart, hogy mi nem tetszik.

1778
01:18:16,240 --> 01:18:17,720
És ez az, ami úgy néz ki, mint.

1779
01:18:17,720 --> 01:18:22,290
Szóval az egész az én kulcsfontosságú helyet kapok
kalapált az értékesítés tételeket.

1780
01:18:22,290 --> 01:18:24,070
Kezdek semmi sehol máshol.

1781
01:18:24,070 --> 01:18:26,050
>> Hogyan enyhíthetik ezt a problémát?

1782
01:18:26,050 --> 01:18:28,410
Nos, enyhítse ezt a gyorsítótárat.

1783
01:18:28,410 --> 01:18:33,630
Cache, akkor tegye alapvetően egy memóriában
partíció előtt a adatbázisban.

1784
01:18:33,630 --> 01:18:37,260
Sikerült
[Hallhatatlan] cache, hogyan

1785
01:18:37,260 --> 01:18:40,260
beállíthatja a saját cache, [hallhatatlan]
cache [? d,?], amit akarsz.

1786
01:18:40,260 --> 01:18:42,220
Tedd, hogy fel előtte az adatbázist.

1787
01:18:42,220 --> 01:18:47,250
És így tudod tárolni az adatokat
azoktól gyorsbillentyűk fel, hogy cache

1788
01:18:47,250 --> 01:18:49,390
térben és olvassa el a gyorsítótárat.

1789
01:18:49,390 --> 01:18:51,962
>> És akkor a legtöbb a elolvassa
kezdeni, mint ez.

1790
01:18:51,962 --> 01:18:54,920
Kaptam mindezek cache eltalálja itt
és engem semmi sem történt itt lent

1791
01:18:54,920 --> 01:18:59,330
mivel az adat- mögött ül a
A gyorsítótár és a olvasás soha nem jön át.

1792
01:18:59,330 --> 01:19:02,520
Ha tudom megváltoztatni az adatokat a
adatbázis, azt kell frissíteni a cache.

1793
01:19:02,520 --> 01:19:04,360
Tudjuk használni valamit
mint gőzök erre.

1794
01:19:04,360 --> 01:19:07,360
És leírom, hogy hogyan működik.

1795
01:19:07,360 --> 01:19:09,060
Rendben, üzenetküldés.

1796
01:19:09,060 --> 01:19:11,180
E-mail, mindannyian használjuk az e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> Ez egy nagyon jó példa.

1798
01:19:12,540 --> 01:19:14,950
Van valamiféle üzenetet asztalra.

1799
01:19:14,950 --> 01:19:17,040
És mi van Bejövõ és kimenõ.

1800
01:19:17,040 --> 01:19:19,760
Ez az, amit az SQL lenne
néznek ki, mint építeni, hogy postaládájába.

1801
01:19:19,760 --> 01:19:23,350
Azt a fajta használja ugyanazt a fajta
A stratégia az GSI, GSI

1802
01:19:23,350 --> 01:19:25,320
az én postaládájába, és én kimenő üzenetek.

1803
01:19:25,320 --> 01:19:27,600
Szóval kaptam nyers érkező üzenetek
az én üzenetek asztalra.

1804
01:19:27,600 --> 01:19:30,194
És az első megközelítése ennek
Lehet, azt mondják, OK, semmi gond.

1805
01:19:30,194 --> 01:19:31,110
Megvan a nyers üzeneteket.

1806
01:19:31,110 --> 01:19:33,710
Üzenetek jön [hallható],
Üzenet azonosító, ez nagyszerű.

1807
01:19:33,710 --> 01:19:35,070
Ez az én egyedi hash.

1808
01:19:35,070 --> 01:19:38,280
Megyek, hogy két GSI, egy
az én postaládájába, egy az én kimenő üzenetek.

1809
01:19:38,280 --> 01:19:40,530
És az első dolog, amit megteszek
A mondok én hash kulcs

1810
01:19:40,530 --> 01:19:43,310
lesz a címzett és
Megyek, hogy gondoskodjon a napon.

1811
01:19:43,310 --> 01:19:44,220
Ez fantasztikus.

1812
01:19:44,220 --> 01:19:45,890
Kaptam szép kilátás van.

1813
01:19:45,890 --> 01:19:47,780
De van egy kis kérdés.

1814
01:19:47,780 --> 01:19:50,891
És befut ezt
relációs adatbázisok is.

1815
01:19:50,891 --> 01:19:52,390
Ők az úgynevezett függőleges particionálás.

1816
01:19:52,390 --> 01:19:55,840
Meg akarja tartani a nagy adatok
távol a kevés adat.

1817
01:19:55,840 --> 01:20:00,470
>> És az az oka, mert azt kell
menj olvassa el a tételeket, hogy az attribútumokat.

1818
01:20:00,470 --> 01:20:05,570
És ha én szervek mind itt,
Ezután olvasás csak néhány elem

1819
01:20:05,570 --> 01:20:08,560
ha a testem hossza
átlagosan 256 kilobyte minden,

1820
01:20:08,560 --> 01:20:10,991
A matek lesz elég csúnya.

1821
01:20:10,991 --> 01:20:12,490
Tehát mondani akarok olvasni David postaládájába.

1822
01:20:12,490 --> 01:20:14,520
Dávid postaládájába 50 példány.

1823
01:20:14,520 --> 01:20:17,880
Az átlagos és a mérete 256 kilobájt.

1824
01:20:17,880 --> 01:20:21,730
Itt a konverziós arány
A távirányító a négy kilobájt.

1825
01:20:21,730 --> 01:20:24,450
>> OK, menjünk együtt
végül következetes szól.

1826
01:20:24,450 --> 01:20:28,640
Én még mindig eszik 1600 távirányító által
csak olvasni David postaládájába.

1827
01:20:28,640 --> 01:20:29,950
Jaj.

1828
01:20:29,950 --> 01:20:31,980
OK, most gondolkodjunk
arról, hogy a app működik.

1829
01:20:31,980 --> 01:20:35,340
Ha én vagyok egy e-mailt app, és
Nézem én postaládájába,

1830
01:20:35,340 --> 01:20:39,680
és nézem a test minden üzenetet,
Nem, nézem az összefoglalókat.

1831
01:20:39,680 --> 01:20:41,850
Én néztem csak a fejlécek.

1832
01:20:41,850 --> 01:20:46,310
Így építsük fel a táblázat szerkezete
úgy néz ki, mint ezt.

1833
01:20:46,310 --> 01:20:49,470
>> Tehát itt van az információ
hogy a munkafolyamat szüksége.

1834
01:20:49,470 --> 01:20:50,890
Ez az én postaládájába GSI.

1835
01:20:50,890 --> 01:20:53,800
Ez a dátum, feladó,
a téma, majd

1836
01:20:53,800 --> 01:20:56,790
Az üzenet azonosítója, amely rámutat,
vissza az üzeneteket asztal

1837
01:20:56,790 --> 01:20:57,850
hol lehet kapni a szervezetben.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Nos, ezek lennének rekord azonosítók.

1840
01:21:04,420 --> 01:21:09,850
Ők pont vissza a
elem adatait a Dynamo DB asztalra.

1841
01:21:09,850 --> 01:21:12,220
Minden index mindig creates--
Mindig az elemet

1842
01:21:12,220 --> 01:21:15,750
ID részeként of--, hogy
jön az index.

1843
01:21:15,750 --> 01:21:17,414
>> Minden rendben.

1844
01:21:17,414 --> 01:21:19,080
Közönség: Azt mondja, hogy hol tárolja az?

1845
01:21:19,080 --> 01:21:21,420
Rick Houlihan: Igen, azt mondja
exactly-- hogy pontosan mit csinál.

1846
01:21:21,420 --> 01:21:22,644
Azt mondja, itt az én újra rekordot.

1847
01:21:22,644 --> 01:21:24,310
És ez lesz a pont vissza az én újra rekordot.

1848
01:21:24,310 --> 01:21:26,460
Pontosan.

1849
01:21:26,460 --> 01:21:29,490
OK, így most én postaládájába is
valójában sokkal kisebb.

1850
01:21:29,490 --> 01:21:32,210
És ez valóban támogatja
A munkafolyamat egy e-mail alkalmazás.

1851
01:21:32,210 --> 01:21:34,230
Szóval én postaládájába, rákattintok.

1852
01:21:34,230 --> 01:21:38,160
Megyek végig, és rákattintok az üzenet,
ez az, amikor el kell mennem, hogy a test,

1853
01:21:38,160 --> 01:21:40,180
mert megyek
megy egy másik nézet.

1854
01:21:40,180 --> 01:21:43,870
Tehát, ha jól meggondoljuk MVC típusú
keretet, MVC.

1855
01:21:43,870 --> 01:21:46,120
>> A modell tartalmazza a
adatok, hogy a néző igényeinek

1856
01:21:46,120 --> 01:21:48,130
és a vezérlő kölcsönhatásba lép.

1857
01:21:48,130 --> 01:21:51,670
Ha tudom megváltoztatni a keret, ha
Én a változás szempontjából,

1858
01:21:51,670 --> 01:21:55,080
nem baj, hogy menjen vissza a
szerver és újra benépesíteni a modell,

1859
01:21:55,080 --> 01:21:56,860
mert ez az, amit a felhasználó számít.

1860
01:21:56,860 --> 01:22:00,530
Amikor változás nézetek, ez az, amikor
mehetünk vissza az adatbázisba.

1861
01:22:00,530 --> 01:22:02,480
Így az e-mail, kattintson.

1862
01:22:02,480 --> 01:22:03,710
Keresem a szervezetben.

1863
01:22:03,710 --> 01:22:04,330
Körutazás.

1864
01:22:04,330 --> 01:22:05,680
Menj a szervezetben.

1865
01:22:05,680 --> 01:22:06,950
>> Sokat olvasok kevesebb adatot.

1866
01:22:06,950 --> 01:22:09,960
Én csak olvassa a szervek
David szüksége, amikor szüksége van rájuk.

1867
01:22:09,960 --> 01:22:14,230
És én nem égnek 1600-ban
Távirányító, csak hogy megmutassa a postaládájába.

1868
01:22:14,230 --> 01:22:17,670
Tehát most hogy-- ez az út
hogy LSI vagy GSI-- Sajnálom,

1869
01:22:17,670 --> 01:22:19,900
GSI, hogy dolgozzanak ki.

1870
01:22:19,900 --> 01:22:25,450
Megvan a hash a kedvezményezettet.

1871
01:22:25,450 --> 01:22:27,030
Megvan a tartományban gombot napján.

1872
01:22:27,030 --> 01:22:31,380
És megvan a vetített attribútumok
hogy csak fel kell alátámasztják azt a nézetet.

1873
01:22:31,380 --> 01:22:34,300
>> Mi forgatni, hogy a kimenő üzenetek.

1874
01:22:34,300 --> 01:22:35,770
Hash feladónak.

1875
01:22:35,770 --> 01:22:39,612
És lényegében már
A nagyon szép, tiszta kilátás.

1876
01:22:39,612 --> 01:22:41,570
És ez basically-- vagyunk
Van ez a szép üzeneteket

1877
01:22:41,570 --> 01:22:45,870
táblázatot, amit most elterjedt szépen, mert
ez hash csak, hashelt üzenet azonosítója.

1878
01:22:45,870 --> 01:22:51,750
És van két indexek
forognak ki a táblázat.

1879
01:22:51,750 --> 01:22:57,411
Rendben, tehát ötlet itt nem
tartani a nagy adatok és ez a kis adatok

1880
01:22:57,411 --> 01:22:57,910
együtt.

1881
01:22:57,910 --> 01:23:00,700
Partíció függőlegesen,
partíció azokat a táblákat.

1882
01:23:00,700 --> 01:23:03,150
Ne olvass adatokat nem kell.

1883
01:23:03,150 --> 01:23:04,850
Rendben, játék.

1884
01:23:04,850 --> 01:23:06,990
Mindannyian szeretnénk játékok.

1885
01:23:06,990 --> 01:23:10,902
Legalább Szeretem a játékokat majd.

1886
01:23:10,902 --> 01:23:12,735
Így néhány dolog
hogy kezelni, ha

1887
01:23:12,735 --> 01:23:14,193
arra gondoltunk, hogy játék, igaz?

1888
01:23:14,193 --> 01:23:16,999
Játék ezekben a napokban, különösen a mobil
játék, szól gondolkodás.

1889
01:23:16,999 --> 01:23:19,540
És fogok forgatni itt
kicsit távol DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Megyek, hogy a
néhány beszélgetés

1891
01:23:21,373 --> 01:23:24,240
körül néhány, a
Más AWS technológiák.

1892
01:23:24,240 --> 01:23:28,930
>> De az ötlet a játék, hogy úgy gondolja,
mintegy szempontjából API, API-k, amelyek,

1893
01:23:28,930 --> 01:23:31,730
általánosságban elmondható, hogy a HTTP és JSON.

1894
01:23:31,730 --> 01:23:34,550
Ez hogyan mobil játékok fajta
kölcsönhatásba a hátsó végét.

1895
01:23:34,550 --> 01:23:35,850
Ők JSON kiküldetés.

1896
01:23:35,850 --> 01:23:40,660
Kapnak adatok, és ez mind,
általánosságban elmondható, hogy a szép JSON API-k.

1897
01:23:40,660 --> 01:23:44,950
>> Dolgok, mint hogy barátok, hogy
A ranglistán, adatokat cseréljen,

1898
01:23:44,950 --> 01:23:47,699
felhasználó által generált tartalom,
tolja vissza a rendszerbe,

1899
01:23:47,699 --> 01:23:49,740
Ezek típusú dolgokat
hogy fogunk csinálni.

1900
01:23:49,740 --> 01:23:52,542
Bináris eszköz adatok, az adatok
Lehet, hogy nem ülnek az adatbázisban.

1901
01:23:52,542 --> 01:23:54,250
Ez lehet ülni egy
objektum tárolja, ugye?

1902
01:23:54,250 --> 01:23:56,541
De az adatbázis fog
a végén azt mondja a rendszer,

1903
01:23:56,541 --> 01:23:59,140
mondja a kérelem
hová menjen érte.

1904
01:23:59,140 --> 01:24:03,550
És elkerülhetetlenül, multiplayer
szerverek, hát vége infrastruktúra,

1905
01:24:03,550 --> 01:24:06,180
és célja a magas
rendelkezésre állás és a skálázhatóság.

1906
01:24:06,180 --> 01:24:09,400
Tehát ezek azok a dolgok, hogy mindannyian szeretnénk
a szerencsejáték-infrastruktúra ma.

1907
01:24:09,400 --> 01:24:12,160
>> Szóval vessünk egy pillantást
mi az hogy néz ki.

1908
01:24:12,160 --> 01:24:16,070
Van egy alapvető hátsó,
nagyon egyszerű.

1909
01:24:16,070 --> 01:24:19,880
Van egy rendszer itt
Több rendelkezésre álló zónára.

1910
01:24:19,880 --> 01:24:23,780
Beszéltünk Azs mint being-- hiszem
ezek külön adatközpontok.

1911
01:24:23,780 --> 01:24:26,040
Több, mint egy adatközpont
per AZ, de ez rendben van,

1912
01:24:26,040 --> 01:24:28,831
gondoljunk csak azokat külön adatok
központok, amelyek földrajzilag

1913
01:24:28,831 --> 01:24:30,090
és a hiba elszigetelt.

1914
01:24:30,090 --> 01:24:32,172
>> Fogunk egy
Pár EC2 esetekben.

1915
01:24:32,172 --> 01:24:33,880
Fogunk van
Néhány hátsó kiszolgáló.

1916
01:24:33,880 --> 01:24:35,800
Talán ha egy örökölt
építészet vagyunk

1917
01:24:35,800 --> 01:24:38,920
segítségével hívjuk RDS,
relációs adatbázis-szolgáltatások.

1918
01:24:38,920 --> 01:24:42,040
Lehet, MSSQL, MySQL,
vagy valami ilyesmi.

1919
01:24:42,040 --> 01:24:47,080
Ez így egy csomó alkalmazások
úgy tervezték, ma.

1920
01:24:47,080 --> 01:24:49,594
>> Hát talán akar menni
Ez az, amikor bővíthetők.

1921
01:24:49,594 --> 01:24:51,510
Majd megy előre, és tedd
Az S3 vödör ott.

1922
01:24:51,510 --> 01:24:54,200
És hogy az S3 bucket szolgálata helyett
azokat a tárgyakat mi servers--

1923
01:24:54,200 --> 01:24:55,220
tudnánk csinálni.

1924
01:24:55,220 --> 01:24:57,210
Akkor tedd az összes bináris
tárgyakat a szerverek

1925
01:24:57,210 --> 01:24:59,751
és tudod használni ezeket kiszolgáló
esetekben szolgálja, hogy az adatok felfelé.

1926
01:24:59,751 --> 01:25:01,860
De ez elég drága.

1927
01:25:01,860 --> 01:25:05,107
>> Jobb így, hogy, menj előre, és
tedd azokat a tárgyakat egy S3 vödör.

1928
01:25:05,107 --> 01:25:06,315
S3 egy adattáraknál.

1929
01:25:06,315 --> 01:25:10,860
Az épített kifejezetten
szolgálja ki az ilyen típusú dolgokat.

1930
01:25:10,860 --> 01:25:13,690
És hagyd, hogy azok az ügyfelek kérhetik
a közvetlenül ezen objektum vödrök,

1931
01:25:13,690 --> 01:25:15,390
tehermentesíti a szervereket.

1932
01:25:15,390 --> 01:25:17,020
Szóval kezdjük a skála idekint.

1933
01:25:17,020 --> 01:25:19,140
>> Most kaptuk a felhasználók a világ minden tájáról.

1934
01:25:19,140 --> 01:25:19,730
Megvan a felhasználók.

1935
01:25:19,730 --> 01:25:23,380
Azt kell, hogy tartalmi helyben
közel helyezkedik el ezeket a felhasználókat, ugye?

1936
01:25:23,380 --> 01:25:26,200
Létrehoztam egy S3 vödör
mint az én repository.

1937
01:25:26,200 --> 01:25:29,370
És én elöl, hogy a
A CloudFront forgalmazás.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront egy CD-t és egy
tartalomszolgáltató hálózat.

1939
01:25:31,720 --> 01:25:35,750
Alapvetően tart adatokat Ön által megadott
és a tartalmát tárolja az egész internet

1940
01:25:35,750 --> 01:25:39,230
így a felhasználók bárhol lehet
egy nagyon gyors választ, amikor

1941
01:25:39,230 --> 01:25:40,960
kérik azokat az objektumokat.

1942
01:25:40,960 --> 01:25:41,960
>> Így kap egy ötlet.

1943
01:25:41,960 --> 01:25:48,230
Te milyen kihasználva minden
szempontjai AWS ide hogy ez megtörtént.

1944
01:25:48,230 --> 01:25:50,790
És végül, dobjuk
egy automatikus méretezés csoport.

1945
01:25:50,790 --> 01:25:52,737
Szóval mi AC2 példányok
játékunk szerverek,

1946
01:25:52,737 --> 01:25:54,820
mivel kezdenek elfoglaltabb
és elfoglaltabb és elfoglaltabb,

1947
01:25:54,820 --> 01:25:57,236
ők csak forgasd a másik
Például, forgasd másik esetben,

1948
01:25:57,236 --> 01:25:58,210
pörögni egy másik példánya.

1949
01:25:58,210 --> 01:26:02,090
Tehát a technológia AWS, hogy
lehetővé teszi azoknak a paramétereknek

1950
01:26:02,090 --> 01:26:04,650
amely körül a szervereket fog nőni.

1951
01:26:04,650 --> 01:26:08,110
Szóval lehet, hogy van n szerverek száma
ott bármely adott időpontban.

1952
01:26:08,110 --> 01:26:11,870
És ha a terhelés elmúlik, akkor majd
zsugorodik, a szám csökkenni fog.

1953
01:26:11,870 --> 01:26:15,250
És ha a terhelés jön vissza,
ez akkor nőnek vissza, rugalmasan.

1954
01:26:15,250 --> 01:26:17,050
>> Tehát ez jól néz ki.

1955
01:26:17,050 --> 01:26:19,800
Van egy csomó EC2 esetekben.

1956
01:26:19,800 --> 01:26:21,671
Mi lehet tenni cache
előtt az adatbázisokat,

1957
01:26:21,671 --> 01:26:23,045
próbálja gyorsítani az adatbázisokat.

1958
01:26:23,045 --> 01:26:25,030
A következő nyomáspont
általában az emberek látják

1959
01:26:25,030 --> 01:26:28,850
Ők azok skála egy játék segítségével
relációs adatbázis-rendszer.

1960
01:26:28,850 --> 01:26:30,790
Jesszus, az adatbázis
teljesítmény borzalmas.

1961
01:26:30,790 --> 01:26:31,932
Hogyan javítja ezt?

1962
01:26:31,932 --> 01:26:33,640
Próbáljuk üzembe
cache előtt, hogy.

1963
01:26:33,640 --> 01:26:36,780
>> Nos, cache nem működik
olyan nagy a játék, igaz?

1964
01:26:36,780 --> 01:26:39,330
A játékok, az írás fájdalmas.

1965
01:26:39,330 --> 01:26:40,930
A játékok nagyon nehéz írni.

1966
01:26:40,930 --> 01:26:43,610
Cache nem működik, ha éppen
levelet nehéz, mert te mindig

1967
01:26:43,610 --> 01:26:44,610
Meg kell frissíteni a cache.

1968
01:26:44,610 --> 01:26:47,780
Frissíti a cache, ez
lényegtelen, hogy cache-t.

1969
01:26:47,780 --> 01:26:49,780
Ez valójában csak plusz munkát.

1970
01:26:49,780 --> 01:26:51,970
>> Szóval, ha mi megy itt?

1971
01:26:51,970 --> 01:26:54,400
Van egy nagy szűk
ott az adatbázisban.

1972
01:26:54,400 --> 01:26:57,661
És az a hely, hogy menjen
Nyilvánvalóan a particionálás.

1973
01:26:57,661 --> 01:26:59,410
Particionálás nem
könnyű csinálni, ha éppen

1974
01:26:59,410 --> 01:27:01,900
foglalkozó relációs adatbázisok.

1975
01:27:01,900 --> 01:27:05,080
A relációs adatbázisok, te
irányításáért felelős, hatékony,

1976
01:27:05,080 --> 01:27:06,210
a legfontosabb helyet.

1977
01:27:06,210 --> 01:27:10,527
Azt mondod, hogy a felhasználók az A és M
megy itt, az N és Z odamenni.

1978
01:27:10,527 --> 01:27:12,360
És te váltás
az egész alkalmazást.

1979
01:27:12,360 --> 01:27:15,000
Szóval van dolgunk,
ez a partíció adatforrás.

1980
01:27:15,000 --> 01:27:18,670
Van tranzakciós megszorítások
amelyek nem befogják partíciókat.

1981
01:27:18,670 --> 01:27:20,560
Van mindenféle
messiness, hogy te

1982
01:27:20,560 --> 01:27:23,040
foglalkozó ott próbál
foglalkozni méretezés el

1983
01:27:23,040 --> 01:27:25,120
és az épület egy nagyobb infrastruktúra.

1984
01:27:25,120 --> 01:27:27,284
Ez csak nem szórakoztató.

1985
01:27:27,284 --> 01:27:30,930
>> Közönség: Szóval azt mondod, hogy
növekvő forrása pont felgyorsítja

1986
01:27:30,930 --> 01:27:31,430
a folyamat?

1987
01:27:31,430 --> 01:27:32,513
Rick Houlihan: növekvő?

1988
01:27:32,513 --> 01:27:33,520
Közönség: Forrás pont.

1989
01:27:33,520 --> 01:27:34,410
Rick Houlihan: Forrás pont?

1990
01:27:34,410 --> 01:27:37,500
Közönség: A rendelkezésre álló információk,
amennyiben az információ érkezik?

1991
01:27:37,500 --> 01:27:38,250
Rick Houlihan: Nem

1992
01:27:38,250 --> 01:27:41,820
Mit mondok növelése
számú partíciót az adattárban

1993
01:27:41,820 --> 01:27:44,060
javítja a teljesítményt.

1994
01:27:44,060 --> 01:27:48,300
Szóval, mi történik itt felhasználók
jön be a EC2 például itt,

1995
01:27:48,300 --> 01:27:50,780
Nos, ha szükségem van egy felhasználói
Ez egy M, megyek itt.

1996
01:27:50,780 --> 01:27:53,560
N p, megyek itt.

1997
01:27:53,560 --> 01:27:55,060
P Z-ig, megyek itt.

1998
01:27:55,060 --> 01:27:57,120
>> Közönség: OK, ezeket így azok
Az összes tárolt különböző csomópontok?

1999
01:27:57,120 --> 01:27:57,911
>> Rick Houlihan: Igen.

2000
01:27:57,911 --> 01:28:00,210
Gondolj ezeket
különböző silók adatok.

2001
01:28:00,210 --> 01:28:01,660
Szóval ha ezt kellene csinálnia.

2002
01:28:01,660 --> 01:28:02,910
Ha akarsz csinálni
ez, ha akarsz

2003
01:28:02,910 --> 01:28:05,730
méretarányos egy relációs platformon,
ez az, amit csinálsz.

2004
01:28:05,730 --> 01:28:08,100
Te véve adatok és
akkor csökkennek le.

2005
01:28:08,100 --> 01:28:10,975
És te particionálás ez az egész
több példányát adatbázisban.

2006
01:28:10,975 --> 01:28:13,580
És te irányítasz mindent,
A ás alkalmazások.

2007
01:28:13,580 --> 01:28:14,729
Ez nem vicces.

2008
01:28:14,729 --> 01:28:15,770
Szóval mit is akar menni?

2009
01:28:15,770 --> 01:28:20,240
Azt akarom, hogy DynamoDB, teljes körű irányítását,
NoSQL adattároló rendelkezni forgalom.

2010
01:28:20,240 --> 01:28:22,680
Az általunk használt másodlagos indexek.

2011
01:28:22,680 --> 01:28:26,154
Ez alapvetően HTTP API és
tartalmazza a dokumentum támogatása.

2012
01:28:26,154 --> 01:28:28,570
Szóval nem kell aggódni
mintegy bármely hogy a particionálás.

2013
01:28:28,570 --> 01:28:30,740
Tesszük mindezt az Ön számára.

2014
01:28:30,740 --> 01:28:33,260
Tehát most, ahelyett, akkor
csak írni, hogy az asztalra.

2015
01:28:33,260 --> 01:28:36,490
Ha a táblázatot kell megosztjuk,
ez történik a színfalak mögött.

2016
01:28:36,490 --> 01:28:40,642
Te teljesen szigetelt
re, hogy a fejlesztő.

2017
01:28:40,642 --> 01:28:42,350
Szóval beszéljünk
néhány, a használati esetek

2018
01:28:42,350 --> 01:28:47,564
hogy befut a játék, közös
szerencsejáték-forgatókönyvek, ranglistán.

2019
01:28:47,564 --> 01:28:49,980
Szóval megvan a felhasználók érkezik,
A BoardNames, hogy ők

2020
01:28:49,980 --> 01:28:52,930
a, a pontszámok a felhasználó számára.

2021
01:28:52,930 --> 01:28:57,700
Mi lehet tördeljük a felhasználói azonosító,
és akkor mi van tartományban a játékot.

2022
01:28:57,700 --> 01:28:59,960
Így minden felhasználó akar látni
Minden játék ő játszott

2023
01:28:59,960 --> 01:29:01,770
és minden rekordot állított fel
az összes játék.

2024
01:29:01,770 --> 01:29:04,000
Szóval ez az ő személyes ranglistán.

2025
01:29:04,000 --> 01:29:10,010
>> Most azt akarom, hogy menjen be, és azt akarom, hogy get--
ezért kapok e személyes ranglista.

2026
01:29:10,010 --> 01:29:12,827
Amit én akarok, akkor kap
A legtöbb pontot az összes felhasználó számára.

2027
01:29:12,827 --> 01:29:13,660
Szóval hogyan tudom megtenni?

2028
01:29:13,660 --> 01:29:18,070
Amikor a rekord hashelt a
a felhasználói azonosító, mozgott a játékot,

2029
01:29:18,070 --> 01:29:20,740
jól fogok menni előre
és átszervezése, hozzon létre egy GSI,

2030
01:29:20,740 --> 01:29:22,370
és megyek átalakítására, hogy az adatokat.

2031
01:29:22,370 --> 01:29:27,310
>> Most megyek Hash a
BoardName, amely a játék.

2032
01:29:27,310 --> 01:29:29,800
És fogok terjedhet a legtöbb pontot.

2033
01:29:29,800 --> 01:29:31,540
És most létrehozott különböző vödrök.

2034
01:29:31,540 --> 01:29:34,790
Én a ugyanannál az asztalnál,
ugyanazt a tételt adatokat.

2035
01:29:34,790 --> 01:29:39,870
De hozok létre egy vödör, hogy ad
nekem egy összesítése rekordot állított fel a játékot.

2036
01:29:39,870 --> 01:29:43,180
>> És azt tudja kérdezni, hogy asztalon
hogy ezt az információt.

2037
01:29:43,180 --> 01:29:50,890
Így állítottam, hogy keresett mintát akár
alá kell támasztani egy másodlagos index.

2038
01:29:50,890 --> 01:29:54,556
Most már lehet válogatni a BoardName
és sorolva TopScore függően.

2039
01:29:54,556 --> 01:29:57,180
Így láthatja, ezek típusai
A használati esetek kapsz a játék.

2040
01:29:57,180 --> 01:30:02,190
Egy másik jó hasznát esetben felvesszük a szerencsejáték-
a díjak és aki megnyerte a díjat.

2041
01:30:02,190 --> 01:30:05,340
És ez egy nagy használati eset
ahol hívjuk ritka indexek.

2042
01:30:05,340 --> 01:30:07,340
Ritka indexek a
képes generálni

2043
01:30:07,340 --> 01:30:10,850
az index, hogy nem feltétlenül
tartalmaznak minden egyes tételt az asztalra.

2044
01:30:10,850 --> 01:30:11,470
És miért nem?

2045
01:30:11,470 --> 01:30:14,540
Mivel a tulajdonság, amit most
indexelt nem létezik minden elemet.

2046
01:30:14,540 --> 01:30:16,460
>> Tehát ebben a konkrét
használni az esetben, azt mondom,

2047
01:30:16,460 --> 01:30:19,240
Tudod mit, megyek
hozzon létre egy attribútum nevű díját.

2048
01:30:19,240 --> 01:30:22,970
És fogok adni minden felhasználónak
hogy van egy díjat, amely tulajdonítani.

2049
01:30:22,970 --> 01:30:25,950
Azok a felhasználók, nem kell a díjak
nem megy, hogy a tulajdonsággal.

2050
01:30:25,950 --> 01:30:27,800
Tehát, ha tudok létrehozni a
index, az egyetlen felhasználók

2051
01:30:27,800 --> 01:30:28,960
hogy fognak mutatni
akár az index

2052
01:30:28,960 --> 01:30:31,050
az is, hogy ténylegesen díjat nyert.

2053
01:30:31,050 --> 01:30:34,440
Szóval ez egy nagyszerű lehetőség, hogy képes
hogy hozzon létre szűrt indexek

2054
01:30:34,440 --> 01:30:40,580
Nagyon, nagyon szelektív, amelyek nem
van az index a teljes táblázatot.

2055
01:30:40,580 --> 01:30:43,050
>> Szóval kezd megtelni időben itt.

2056
01:30:43,050 --> 01:30:49,190
Megyek előre, és hagyja menni
ki, és hagyja ki ezt a forgatókönyvet.

2057
01:30:49,190 --> 01:30:52,625
Beszéljünk egy kicsit about--

2058
01:30:52,625 --> 01:30:54,460
>> Közönség: Megkérdezhetem egy gyors kérdés?

2059
01:30:54,460 --> 01:30:56,722
Az egyik levelet nehéz?

2060
01:30:56,722 --> 01:30:57,680
Rick Houlihan: Mi?

2061
01:30:57,680 --> 01:30:58,596
Közönség: Írj nehéz.

2062
01:30:58,596 --> 01:31:01,270
Rick Houlihan: Írj nehéz.

2063
01:31:01,270 --> 01:31:03,460
Hadd lássam.

2064
01:31:03,460 --> 01:31:06,220
>> Közönség: Vagy az, hogy nem
valami, amit csak

2065
01:31:06,220 --> 01:31:08,809
hangját a másodpercek kérdése?

2066
01:31:08,809 --> 01:31:10,850
Rick Houlihan: Megyünk
a szavazási forgatókönyv.

2067
01:31:10,850 --> 01:31:11,670
Ez nem olyan rossz.

2068
01:31:11,670 --> 01:31:14,580
Srácok, van egy pár percig?

2069
01:31:14,580 --> 01:31:15,860
OKÉ.

2070
01:31:15,860 --> 01:31:17,890
>> Így fogunk beszélni szavazást.

2071
01:31:17,890 --> 01:31:20,250
Így valós időben szavazás, van
való választásra.

2072
01:31:20,250 --> 01:31:25,250
Követelmény az, hogy megengedjük
Minden személy csak egyszer szavazhat.

2073
01:31:25,250 --> 01:31:28,060
Szeretnénk senki, hogy képes
hogy változtassák meg a szavazást.

2074
01:31:28,060 --> 01:31:31,045
Szeretnénk valós idejű összesítés
és elemzése demográfiai

2075
01:31:31,045 --> 01:31:34,210
hogy mi lesz
mutatja, hogy a felhasználók az oldalon.

2076
01:31:34,210 --> 01:31:35,200
>> Gondolj ez a forgatókönyv.

2077
01:31:35,200 --> 01:31:37,550
Mi sokat dolgoznak a valóság
TV-műsorok, ahol ők

2078
01:31:37,550 --> 01:31:38,960
csinálnak ezek pontos típusa a dolgokat.

2079
01:31:38,960 --> 01:31:41,584
Így gondolja a forgatókönyv,
van milliónyi

2080
01:31:41,584 --> 01:31:43,959
A tizenéves lányok ott
a mobiltelefonok

2081
01:31:43,959 --> 01:31:46,250
és szavazó, valamint a szavazás, és
szavazok bárkik legyenek is

2082
01:31:46,250 --> 01:31:48,610
találni, hogy a legnépszerűbb.

2083
01:31:48,610 --> 01:31:50,830
Tehát ezek közül néhány a
követelmények elfogy.

2084
01:31:50,830 --> 01:31:52,990
>> És így az első vegye
e probléma megoldásában

2085
01:31:52,990 --> 01:31:55,090
az lenne, hogy építsenek egy
Nagyon egyszerű alkalmazás.

2086
01:31:55,090 --> 01:31:56,490
Így kaptam ezt a kb.

2087
01:31:56,490 --> 01:31:57,950
Van néhány szavazók odakint.

2088
01:31:57,950 --> 01:31:59,980
Jönnek, hogy megüt a szavazati app.

2089
01:31:59,980 --> 01:32:03,440
Van néhány nyers szavazat asztal
Én csak kiírása ezen szavazatok be.

2090
01:32:03,440 --> 01:32:05,780
Szólok néhány összesített
szavazatok tábla

2091
01:32:05,780 --> 01:32:09,490
minden tőlem analitika és a demográfia,
és mi mindezt ott.

2092
01:32:09,490 --> 01:32:11,420
>> És ez jó.

2093
01:32:11,420 --> 01:32:12,332
Az élet jó.

2094
01:32:12,332 --> 01:32:15,040
Az élet jó, amíg nem találunk arra, hogy
mindig van csak egy vagy két

2095
01:32:15,040 --> 01:32:16,879
az emberek, amelyek népszerűek a választások.

2096
01:32:16,879 --> 01:32:19,420
Már csak egy-két dolgot
hogy az emberek tényleg érdekel.

2097
01:32:19,420 --> 01:32:22,340
És ha szavazó
skála, hirtelen vagyok

2098
01:32:22,340 --> 01:32:26,360
lesz kalapált a fenébe
két jelölt, egy vagy két jelölt.

2099
01:32:26,360 --> 01:32:29,390
Egy nagyon kevés példány
ember számára, hogy népszerű.

2100
01:32:29,390 --> 01:32:31,710
>> Ez nem egy jó tervezési minta.

2101
01:32:31,710 --> 01:32:33,549
Ez valójában egy
Nagyon rossz tervezési minta

2102
01:32:33,549 --> 01:32:36,340
mert létrehoz pontosan mi
beszélt ami gyorsbillentyűk.

2103
01:32:36,340 --> 01:32:38,960
Gyorsbillentyűk valamit mi nem tetszik.

2104
01:32:38,960 --> 01:32:40,470
>> Szóval hogyan lehet megjavítani ezt?

2105
01:32:40,470 --> 01:32:47,640
És valóban, a módja annak, hogy erősít ez
azáltal, hogy azokban a tagjelölt kanalak

2106
01:32:47,640 --> 01:32:51,490
és minden jelölt van,
fogunk hozzáfűzni egy véletlen értéket,

2107
01:32:51,490 --> 01:32:54,192
valamit, hogy tudjuk, véletlenszerű
közötti érték egy és 100,

2108
01:32:54,192 --> 01:32:56,620
100 és 1000,
közötti, vagy egy és 1,000,

2109
01:32:56,620 --> 01:32:59,940
Azonban sok véletlenszerű értékeket szeretne
fűzze rá a végén, hogy a jelölt.

2110
01:32:59,940 --> 01:33:01,330
>> És mit értem igazán történt akkor?

2111
01:33:01,330 --> 01:33:05,830
Ha én vagyok a jelölt azonosítót
A vödröt összesített szavazatok,

2112
01:33:05,830 --> 01:33:08,780
Ha Adtam egy véletlenszerű
szám, hogy a végén, hogy

2113
01:33:08,780 --> 01:33:12,000
Már létrehozott most 10 kanalak, egy
Száz vödrök, ezer vödrök

2114
01:33:12,000 --> 01:33:14,160
hogy én vagyok a szavazatok összegyűjtésére szerte.

2115
01:33:14,160 --> 01:33:18,030
>> Szóval van több millió, és milliók,
és több millió lemez jön

2116
01:33:18,030 --> 01:33:22,050
ezeket a jelölteket, most terjed
ezen szavazatok szerte vont a_1

2117
01:33:22,050 --> 01:33:24,630
a tagjelölt A_100, mert
Minden alkalommal, amikor egy szavazást érkezik,

2118
01:33:24,630 --> 01:33:26,530
Én generál egy véletlen
közötti érték egy és 100.

2119
01:33:26,530 --> 01:33:29,446
Én tacking rá a végén a
jelöltet az adott személy szavazok.

2120
01:33:29,446 --> 01:33:31,120
Én dömping be, hogy vödörbe.

2121
01:33:31,120 --> 01:33:33,910
>> Most a hátoldalon, tudom
hogy kaptam száz vödör.

2122
01:33:33,910 --> 01:33:36,350
Tehát, ha azt akarom, hogy menjen előre
és összesítik a szavazatok,

2123
01:33:36,350 --> 01:33:38,244
Olvastam az összes többi vödrök.

2124
01:33:38,244 --> 01:33:39,160
Szóval megy előre, és adjunk hozzá.

2125
01:33:39,160 --> 01:33:42,410
És akkor én a szórás gyűjteni
hová megyek, és azt mondják hé,

2126
01:33:42,410 --> 01:33:45,399
tudod mit, ez a jelölt gombot
terek több mint száz vödör.

2127
01:33:45,399 --> 01:33:47,940
Megyek összegyűjteni a
szavazat azoktól száz vödör.

2128
01:33:47,940 --> 01:33:49,981
Megyek összesíteni
őket, és meg fogom mondani,

2129
01:33:49,981 --> 01:33:53,830
Tagjelölt Egy most
Összesen szavazatszámlálás x.

2130
01:33:53,830 --> 01:33:55,690
>> Most mind a write
lekérdezés és az olvasási lekérdezés

2131
01:33:55,690 --> 01:33:58,160
szépen elosztva
mert én írom át

2132
01:33:58,160 --> 01:34:00,320
és olvasom több száz kulcsokat.

2133
01:34:00,320 --> 01:34:03,500
Én nem írom és
olvasás-szerte az egyik legfontosabb most.

2134
01:34:03,500 --> 01:34:04,950
Szóval ez egy jó minta.

2135
01:34:04,950 --> 01:34:08,090
>> Ez tulajdonképpen talán az egyik
A legfontosabb tervezési

2136
01:34:08,090 --> 01:34:10,420
minták skála NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Látni fogja az ilyen típusú
tervezési minta minden ízét.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, ez nem
számít, mi minden kell ezt csinálni.

2139
01:34:19,100 --> 01:34:21,840
Mert ha éppen foglalkoznak
azokkal a hatalmas csoportosulásai,

2140
01:34:21,840 --> 01:34:26,650
meg kell találnunk a módját, hogy
osszuk ki az egész vödör.

2141
01:34:26,650 --> 01:34:29,512
Tehát ez az az út, ezt teszed.

2142
01:34:29,512 --> 01:34:31,220
Rendben, akkor mi
csinálsz most

2143
01:34:31,220 --> 01:34:35,252
A te kereskedés off Olvasás
költség írási skálázhatóság.

2144
01:34:35,252 --> 01:34:37,085
Az ára én beolvasás
egy kicsit bonyolultabb,

2145
01:34:37,085 --> 01:34:40,220
és mennem kell olvasni egy
Száz vödrök helyett.

2146
01:34:40,220 --> 01:34:41,310
De nem vagyok képes írni.

2147
01:34:41,310 --> 01:34:44,860
És én áteresztőképességű, én write
áteresztőképességű hihetetlen.

2148
01:34:44,860 --> 01:34:49,450
Szóval ez általában egy értékes
technika méretezés DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
vagy bármilyen NoSQL adatbázist, hogy az ügyben.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Szóval kitaláltam, hogyan lehet skálázni.

2152
01:34:55,240 --> 01:34:56,930
És rájöttünk, hogyan kell
megszüntesse a gyorsbillentyűk.

2153
01:34:56,930 --> 01:34:57,820
És ez fantasztikus.

2154
01:34:57,820 --> 01:34:58,960
És mi van ez a szép rendszer.

2155
01:34:58,960 --> 01:35:02,043
És ez adott nekünk nagyon helyes szavazati
mert van eredménye szavazás de-dupe.

2156
01:35:02,043 --> 01:35:03,130
Építettük DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Beszéltünk a feltételes jogokat.

2158
01:35:05,380 --> 01:35:08,170
>> Ha a választópolgár jön, hozza
betét az asztalra,

2159
01:35:08,170 --> 01:35:11,220
úgy helyezze azok a szavazók ID,
ha megpróbál beilleszteni egy szavazást,

2160
01:35:11,220 --> 01:35:13,320
Én egy feltételes írni.

2161
01:35:13,320 --> 01:35:16,960
Mondja el, csak írni ezt
Ha ez nem létezik.

2162
01:35:16,960 --> 01:35:19,270
Tehát amint látom, hogy
a szavazást a verik az asztalt,

2163
01:35:19,270 --> 01:35:20,460
senki más lesz
tudja tenni a szavazást.

2164
01:35:20,460 --> 01:35:21,634
És ez fantasztikus.

2165
01:35:21,634 --> 01:35:23,550
És mi megnő
a tagjelölt számlálók.

2166
01:35:23,550 --> 01:35:25,466
És csinálunk mi
demográfiai és ennyi.

2167
01:35:25,466 --> 01:35:29,110
De mi történik, ha a
alkalmazás elesik?

2168
01:35:29,110 --> 01:35:31,350
Most hirtelen szavazat
jönnek, és én

2169
01:35:31,350 --> 01:35:34,840
nem tudom, ha ők egyre feldolgozása
az én elemző és demográfia

2170
01:35:34,840 --> 01:35:36,040
többé.

2171
01:35:36,040 --> 01:35:38,462
És ha az alkalmazás
jön vissza, hogyan

2172
01:35:38,462 --> 01:35:41,420
A fenébe tudom, hogy milyen szavazattal rendelkezik
feldolgozott és hol is kezdjem?

2173
01:35:41,420 --> 01:35:44,530
>> Tehát ez egy valós probléma, ha
elkezdi nézni az ilyen típusú forgatókönyv.

2174
01:35:44,530 --> 01:35:45,571
És hogyan oldja meg ezt?

2175
01:35:45,571 --> 01:35:48,070
Megoldjuk azt, amit mi
hívja DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Patakok egy időben rendezett és
megosztjuk változás napló minden hozzáférést

2177
01:35:53,470 --> 01:35:55,700
A táblázat minden levelet
hozzáférést a táblázatban.

2178
01:35:55,700 --> 01:35:58,810
Minden olyan adatot, hogy van írva, hogy a
táblázat mutatja fel a patak.

2179
01:35:58,810 --> 01:36:01,815
>> Ez alapvetően egy 24 órás sorban.

2180
01:36:01,815 --> 01:36:03,690
Tételek sújtotta a patak,
élnek 24 órán át.

2181
01:36:03,690 --> 01:36:05,990
Ők lehet olvasni többször.

2182
01:36:05,990 --> 01:36:09,400
Garantált kell szállítani
csak egyszer a patakhoz,

2183
01:36:09,400 --> 01:36:11,180
lehet olvasni N számú alkalommal.

2184
01:36:11,180 --> 01:36:14,910
Így azonban sok kívánt folyamatokat
fogyasztanak, hogy az adatok, akkor is fogyaszthatunk.

2185
01:36:14,910 --> 01:36:16,350
Úgy jelenik meg minden frissítés.

2186
01:36:16,350 --> 01:36:18,455
Minden írási csak akkor
jelennek meg egyszer a patak.

2187
01:36:18,455 --> 01:36:20,621
Szóval nem kell aggódni
mintegy feldolgozás kétszer

2188
01:36:20,621 --> 01:36:22,500
ugyanabból a folyamatot.

2189
01:36:22,500 --> 01:36:25,350
>> Ez szigorúan elrendelte db áron.

2190
01:36:25,350 --> 01:36:28,180
Amikor azt mondjuk, ideje
megrendelt és megosztjuk,

2191
01:36:28,180 --> 01:36:30,680
látni fogod per partíciót a patak.

2192
01:36:30,680 --> 01:36:33,169
Látni fogja tételek, frissítések érdekében.

2193
01:36:33,169 --> 01:36:35,210
Mi nem garantálja
a patak, hogy te

2194
01:36:35,210 --> 01:36:40,240
lesz, hogy minden tranzakció
A sorrendben az egész terméket.

2195
01:36:40,240 --> 01:36:42,440
>> Tehát patakok idempotens.

2196
01:36:42,440 --> 01:36:44,037
Ne mindannyian tudjuk, mi idempotens jelent?

2197
01:36:44,037 --> 01:36:46,620
Idempotens azt jelenti, hogy meg tudod csinálni
újra és újra, és újra.

2198
01:36:46,620 --> 01:36:48,200
Az eredmény lesz ugyanaz.

2199
01:36:48,200 --> 01:36:49,991
>> Patakok idempotens,
de meg kell lennie

2200
01:36:49,991 --> 01:36:54,860
játszott a kiindulási pont,
bárhol is, hogy a végén,

2201
01:36:54,860 --> 01:36:57,950
vagy amelyek nem eredményeznek
az azonos értékeket.

2202
01:36:57,950 --> 01:36:59,727
>> Ugyanezt MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB egy konstrukciót
hívják az oplog.

2204
01:37:01,560 --> 01:37:04,140
Ez pontosan ugyanaz a konstrukció.

2205
01:37:04,140 --> 01:37:06,500
Sok NoSQL adatbázisok
Van ez a konstrukció.

2206
01:37:06,500 --> 01:37:08,790
Ők használják a dolgokat
mint a replikáció, amely

2207
01:37:08,790 --> 01:37:10,475
Pontosan mit teszünk patakok.

2208
01:37:10,475 --> 01:37:12,350
Közönség: Talán egy
eretnek kérdést, de

2209
01:37:12,350 --> 01:37:13,975
beszélni alkalmazások csinálsz egy így tovább.

2210
01:37:13,975 --> 01:37:16,089
Vannak patakok garantáltan
Soha esetleg megy le?

2211
01:37:16,089 --> 01:37:18,630
Rick Houlihan: Igen, patakok
garantáltan soha nem megy le.

2212
01:37:18,630 --> 01:37:21,040
Sikerül az infrastruktúra
mögött. patakok automatikusan

2213
01:37:21,040 --> 01:37:22,498
telepíteni az automatikus méretezés csoport.

2214
01:37:22,498 --> 01:37:25,910
Elmegyünk egy kicsit
kicsit arról, hogy mi történik.

2215
01:37:25,910 --> 01:37:30,060
>> Nem kellett mondanom, hogy nem
Garantált, hogy menjen le.

2216
01:37:30,060 --> 01:37:33,110
Az elemek garantáltan
megjelenni a patak.

2217
01:37:33,110 --> 01:37:36,740
És a közvetítés lesz elérhető.

2218
01:37:36,740 --> 01:37:40,580
Tehát mi megy le, vagy jön vissza
fel, ami történik alatta.

2219
01:37:40,580 --> 01:37:43,844
Ez covers-- minden rendben.

2220
01:37:43,844 --> 01:37:46,260
Rendben, így kap a különböző
ábrázolási mód ki a képernyőn.

2221
01:37:46,260 --> 01:37:51,040
A kilátás típusok, amelyek fontosak a
programozó jellemzően, mi volt ez?

2222
01:37:51,040 --> 01:37:52,370
Azt, hogy a régi nézetet.

2223
01:37:52,370 --> 01:37:55,630
Amikor frissítést üt az asztalra, akkor az
tolja a régi nézetet, hogy a patak

2224
01:37:55,630 --> 01:38:02,070
így az adatok archiválására, illetve a változás
kontroll, a változás azonosítása, a változás

2225
01:38:02,070 --> 01:38:03,600
menedzsment.

2226
01:38:03,600 --> 01:38:07,160
>> Az új kép, mint amilyen most, miután
A frissítés, ez egy újabb fajta nézet

2227
01:38:07,160 --> 01:38:07,660
lehet kapni.

2228
01:38:07,660 --> 01:38:09,660
Lehet kapni a régi és az új képeket.

2229
01:38:09,660 --> 01:38:10,660
Talán azt akarom mind a kettőt.

2230
01:38:10,660 --> 01:38:11,790
Azt akarom, hogy lássák, mi az.

2231
01:38:11,790 --> 01:38:13,290
Azt akarom, hogy megnézze, mi változott.

2232
01:38:13,290 --> 01:38:15,340
>> Nekem van egy megfelelési típus
A folyamat fut.

2233
01:38:15,340 --> 01:38:17,430
Azt kell, hogy ellenőrizze, hogy
ha ezek a dolgok megváltoznak,

2234
01:38:17,430 --> 01:38:21,840
hogy ők bizonyos határokon belül
vagy bizonyos paramétereken belül.

2235
01:38:21,840 --> 01:38:23,840
>> És akkor talán csak
kell, hogy mi változott.

2236
01:38:23,840 --> 01:38:26,240
Nem érdekel, hogy melyik elem változott.

2237
01:38:26,240 --> 01:38:28,580
Nem kell tudnod kell
milyen képességei változtak.

2238
01:38:28,580 --> 01:38:30,882
Én csak meg kell tudni, hogy
A tételek kerülnek megérintette.

2239
01:38:30,882 --> 01:38:33,340
Tehát ezek a különböző nézetek
hogy szálljon le a patak

2240
01:38:33,340 --> 01:38:35,960
és kölcsönhatásba léphet.

2241
01:38:35,960 --> 01:38:37,840
>> Az alkalmazás
fogyasztja az áramot,

2242
01:38:37,840 --> 01:38:39,298
Ez a fajta az, ahogy ez működik.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB ügyfél kérheti,
nyomja adatok az asztalokhoz.

2244
01:38:42,570 --> 01:38:44,750
Patakok telepíteni, hogy mit nevezünk szilánkok.

2245
01:38:44,750 --> 01:38:47,380
Szilánkok méretezése
függetlenül az asztalra.

2246
01:38:47,380 --> 01:38:50,660
Ők nem sorakoznak teljesen
A válaszfalak a táblázat.

2247
01:38:50,660 --> 01:38:52,540
És az az oka,
mert sorakoznak

2248
01:38:52,540 --> 01:38:55,430
a kapacitás, a jelenlegi
kapacitása a táblázatban.

2249
01:38:55,430 --> 01:38:57,600
>> Ők telepíteni a saját
saját auto méretezés csoport,

2250
01:38:57,600 --> 01:39:00,800
és elkezdenek elhúz függően
hány írások jönnek,

2251
01:39:00,800 --> 01:39:03,090
Hány reads-- igazán ez írja.

2252
01:39:03,090 --> 01:39:05,820
Nincs reads-- de hogyan
Sok írások jönnek.

2253
01:39:05,820 --> 01:39:08,200
>> És akkor a hátsó
végén, van, amit mi

2254
01:39:08,200 --> 01:39:11,390
hívja a kálium-klorid, vagy Kinesis Client Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis egy adatfolyamok
feldolgozási technológia Amazon.

2256
01:39:19,190 --> 01:39:22,040
És patakok épül, hogy.

2257
01:39:22,040 --> 01:39:25,670
>> Szóval használja a KCL engedélyezve
alkalmazás olvasni a patak.

2258
01:39:25,670 --> 01:39:28,752
A Kinesis Client Library ténylegesen
kezeli a munkavállalók az Ön számára.

2259
01:39:28,752 --> 01:39:30,460
És ez is, nem valami
érdekes dolgok.

2260
01:39:30,460 --> 01:39:35,630
Ez létre fog hozni néhány táblázatban fel
a DynamoDB tablespace

2261
01:39:35,630 --> 01:39:38,410
követni, hogy mely elemek
feldolgozásra kerültek.

2262
01:39:38,410 --> 01:39:41,190
Szóval így ha esik vissza, ha
esik át, és jön, és lesz

2263
01:39:41,190 --> 01:39:45,570
állt vissza, meg tudja határozni, ahol
volt feldolgozásában a patak.

2264
01:39:45,570 --> 01:39:48,360
>> Ez nagyon fontos, ha
te beszélsz replikáció.

2265
01:39:48,360 --> 01:39:50,350
Tudnom kell, hogy mi
adatok feldolgozása megtörtént

2266
01:39:50,350 --> 01:39:52,810
és milyen adatokat még ki kell dolgozni.

2267
01:39:52,810 --> 01:39:57,380
Tehát a KCL könyvtár patakok
kapsz egy csomó ezt a funkciót.

2268
01:39:57,380 --> 01:39:58,990
Ez gondoskodik az összes háztartás.

2269
01:39:58,990 --> 01:40:01,140
Állítsa fel a munkavállalót minden darabnak.

2270
01:40:01,140 --> 01:40:04,620
Ez létrehoz egy adminisztratív asztal
Minden darabnak, a minden munkavállalót.

2271
01:40:04,620 --> 01:40:07,560
És mivel ezek a munkavállalók tűz,
fenntartják azokat a táblákat

2272
01:40:07,560 --> 01:40:10,510
így tudja ezt a rekordot
felolvasták és feldolgozni.

2273
01:40:10,510 --> 01:40:13,850
És akkor így, ha a folyamat
meghal, és újra online,

2274
01:40:13,850 --> 01:40:17,940
akkor folytathatja ott, ahol levette.

2275
01:40:17,940 --> 01:40:20,850
>> Így használjuk ezt
határokon régió replikáció.

2276
01:40:20,850 --> 01:40:24,680
Sok ügyfél van szükség
mentsük el az adatokat, vagy egyes részein adattáblák

2277
01:40:24,680 --> 01:40:25,920
körül, hogy különböző régiókban.

2278
01:40:25,920 --> 01:40:29,230
Kilenc régió
a világon mindenhol.

2279
01:40:29,230 --> 01:40:32,100
Tehát ott lehet a need-- I
Lehet, hogy a felhasználók Ázsiában, a felhasználók

2280
01:40:32,100 --> 01:40:34,150
A keleti parton az Egyesült Államokban.

2281
01:40:34,150 --> 01:40:38,980
Ők különböző adatok
kell helyben osztják.

2282
01:40:38,980 --> 01:40:42,510
És talán egy felhasználó indít járatot
Ázsia át az Egyesült Államokban,

2283
01:40:42,510 --> 01:40:45,020
és szeretném megismételni
adatainak vele.

2284
01:40:45,020 --> 01:40:49,340
Tehát amikor leszáll a gép, ő
Jó tapasztalat segítségével a mobil app.

2285
01:40:49,340 --> 01:40:52,360
>> Használhatja a határon régióban
replikáció könyvtár erre.

2286
01:40:52,360 --> 01:40:55,730
Alapvetően van
amennyiben két technológia.

2287
01:40:55,730 --> 01:40:59,400
Az egyik egy konzolos alkalmazás segítségével
felállni a saját EC2 fokon.

2288
01:40:59,400 --> 01:41:01,240
Ez fut a tiszta replikáció.

2289
01:41:01,240 --> 01:41:02,720
És akkor mi adta meg a könyvtárban.

2290
01:41:02,720 --> 01:41:06,070
A könyvtár használhatja építeni
Saját alkalmazásában, ha

2291
01:41:06,070 --> 01:41:10,740
akarok őrült dolgokat, hogy data--
szűrő, lemásolni csak részét,

2292
01:41:10,740 --> 01:41:14,120
forgatni az adatokat, hogy helyezze át a
különböző asztal, így tovább és így tovább.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Szóval ez a fajta, amit úgy néz ki, mint a.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams lehet
dolgozza fel, amit úgy hívunk Lambda.

2296
01:41:23,690 --> 01:41:27,394
Említettük egy kicsit esemény
vezérelt alkalmazás architektúrák.

2297
01:41:27,394 --> 01:41:28,810
Lambda kulcsfontosságú eleme, hogy.

2298
01:41:28,810 --> 01:41:32,840
A lambda-kód, amely a tüzek igény
válaszul egy adott eseményt.

2299
01:41:32,840 --> 01:41:36,020
Az egyik ilyen események lehet egy
rekord jelenik meg a patak.

2300
01:41:36,020 --> 01:41:39,100
Ha egy rekord jelenik meg a patak,
fogjuk hívni ezt a Java funkciót.

2301
01:41:39,100 --> 01:41:44,980
Nos, ez a JavaScriptet, és a Lambda
támogatja node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
és hamarosan támogatni
más nyelveken is.

2303
01:41:47,820 --> 01:41:50,940
És elég mondani, ez tiszta kódot.

2304
01:41:50,940 --> 01:41:53,610
levelet a Java, akkor meg egy osztályt.

2305
01:41:53,610 --> 01:41:55,690
Lenyomja a JAR fel Lambda.

2306
01:41:55,690 --> 01:42:00,200
És akkor adja meg, hogy melyik osztályba
hívni amelyekre válaszul esemény.

2307
01:42:00,200 --> 01:42:04,770
És akkor a Lambda infrastruktúra
mögött, hogy futni fog a kódot.

2308
01:42:04,770 --> 01:42:06,730
>> Ez a kód képes feldolgozni
nyilvántartások le a patak.

2309
01:42:06,730 --> 01:42:08,230
Meg lehet csinálni amit akar vele.

2310
01:42:08,230 --> 01:42:11,650
Ebben a konkrét példában az összes vagyunk
igazán tesz bejelentkezik az attribútumokat.

2311
01:42:11,650 --> 01:42:13,480
De ez csak kódot.

2312
01:42:13,480 --> 01:42:15,260
Kód tehetünk semmit, ugye?

2313
01:42:15,260 --> 01:42:16,600
>> Szóval lehet forgatni, hogy az adatok.

2314
01:42:16,600 --> 01:42:18,160
Tudod teremt egy származékos kilátás.

2315
01:42:18,160 --> 01:42:21,160
Ha ez egy dokumentum szerkezetét,
akkor simítsa a szerkezet.

2316
01:42:21,160 --> 01:42:24,300
Tudod teremt alternatív indexek.

2317
01:42:24,300 --> 01:42:27,100
Mindenféle dolgot lehet
köze a DynamoDB Streams.

2318
01:42:27,100 --> 01:42:28,780
>> És valóban, ez az, amit úgy néz ki, mint.

2319
01:42:28,780 --> 01:42:29,940
Így kap, ezeket a frissítéseket jön.

2320
01:42:29,940 --> 01:42:31,190
Jönnek ki a húr.

2321
01:42:31,190 --> 01:42:32,720
Ők olvasható a Lambda funkció.

2322
01:42:32,720 --> 01:42:37,480
Ők forgó adatok és
nyomja fel a származékos asztalok,

2323
01:42:37,480 --> 01:42:42,200
bejelentő külső rendszerek változás,
és nyomja adatok ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Beszéltünk arról, hogyan tegye a cache
előtte az adatbázist, hogy az értékesítés

2325
01:42:45,900 --> 01:42:46,450
forgatókönyv.

2326
01:42:46,450 --> 01:42:50,049
Nos, mi történik, ha
frissíti a tétel leírását?

2327
01:42:50,049 --> 01:42:52,340
Nos, ha volt egy Lambda
funkció fut az asztalon,

2328
01:42:52,340 --> 01:42:55,490
ha frissítem a tétel leírását, akkor az
vegye fel a rekordot le a patak,

2329
01:42:55,490 --> 01:42:58,711
és akkor frissíti a ElastiCache
Például az új adatokkal.

2330
01:42:58,711 --> 01:43:00,460
Szóval ez a sok
mit tegyünk Lambda.

2331
01:43:00,460 --> 01:43:02,619
Ez a ragasztó kódot, csatlakozók.

2332
01:43:02,619 --> 01:43:04,410
És ez valóban ad
a képesség, hogy indítson

2333
01:43:04,410 --> 01:43:07,930
és futni nagyon összetett alkalmazások
anélkül egy dedikált szerver

2334
01:43:07,930 --> 01:43:10,371
infrastruktúrát, ami nagyon klassz.

2335
01:43:10,371 --> 01:43:13,100
>> Szóval menjünk vissza a
valós idejű szavazási építészet.

2336
01:43:13,100 --> 01:43:17,984
Ez az új és továbbfejlesztett változata a
patakok és KCL kompatibilis alkalmazás.

2337
01:43:17,984 --> 01:43:20,150
Ugyanaz, mint korábban, nem tudjuk
kezelni bármilyen skálán választásokon.

2338
01:43:20,150 --> 01:43:21,100
Szeretjük ezt.

2339
01:43:21,100 --> 01:43:24,770
Csinálunk szórás gyűjt
több vödör.

2340
01:43:24,770 --> 01:43:26,780
Megvan optimista zárolás folyik.

2341
01:43:26,780 --> 01:43:30,192
Tudjuk tartani a választók
megváltoztassák a szavazatokat.

2342
01:43:30,192 --> 01:43:31,400
Ők csak csak egyszer szavazhat.

2343
01:43:31,400 --> 01:43:32,880
Ez fantasztikus.

2344
01:43:32,880 --> 01:43:35,895
Valós idejű hibatűrés,
skálázható összesítés most.

2345
01:43:35,895 --> 01:43:38,270
Ha a dolog eldől, hogy
tudja, hogy hol újraindítja magát

2346
01:43:38,270 --> 01:43:41,300
amikor jön vissza, mert
mi használ a KCL app.

2347
01:43:41,300 --> 01:43:45,700
És akkor mi is használjuk, hogy
KCL kérelmet, hogy álljon ki az adatok

2348
01:43:45,700 --> 01:43:48,820
a vöröseltolódás más
app analitika, vagy használatra

2349
01:43:48,820 --> 01:43:51,990
A rugalmas MapReduce futtatásához
valós idejű streaming összeállítások le

2350
01:43:51,990 --> 01:43:53,180
Az, hogy az adatok.

2351
01:43:53,180 --> 01:43:55,480
>> Tehát ezek a dolgok is
nem beszéltünk sokat.

2352
01:43:55,480 --> 01:43:57,375
De ők további
technológiák jönnek

2353
01:43:57,375 --> 01:44:00,310
viseli, ha keres
A ilyen típusú forgatókönyvek.

2354
01:44:00,310 --> 01:44:03,160
>> Rendben, ez körülbelül
Analytics DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
Tudod gyűjteni de-dupe
adatok, nem mindenféle

2356
01:44:05,340 --> 01:44:09,490
A szép dolgokat, az adatok összesítése
memória, hozzon létre származékos táblákat.

2357
01:44:09,490 --> 01:44:13,110
Ez egy hatalmas felhasználása esetén
hogy egy csomó ügyfelek

2358
01:44:13,110 --> 01:44:16,950
részt vesznek a, figyelembe véve a beágyazott
ezek jellemzőit JSON dokumentumok

2359
01:44:16,950 --> 01:44:18,946
biztosítása és kiegészítő indexek.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Mi vagyunk a végén.

2362
01:44:23,150 --> 01:44:26,689
Köszönjük viselő velem.

2363
01:44:26,689 --> 01:44:28,480
Szóval beszéljünk
referencia architektúra.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB ül a közepén, így
sok a AWS infrastruktúra.

2365
01:44:33,440 --> 01:44:37,090
Alapvetően akkor akassza
akár bármit, amit akarsz.

2366
01:44:37,090 --> 01:44:45,600
Alkalmazások felhasználásával épült Dynamo közé
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
tolja az adatokat ki Elastic
MapReduce, import-export re DynamoDB

2368
01:44:49,890 --> 01:44:52,370
S3, mindenféle munkafolyamatokat.

2369
01:44:52,370 --> 01:44:54,120
De talán a legjobb
dolog beszélni,

2370
01:44:54,120 --> 01:44:56,119
és ez az, ami igazán
érdekes, amikor

2371
01:44:56,119 --> 01:44:58,350
beszélni eseményvezérelt alkalmazások.

2372
01:44:58,350 --> 01:45:00,300
>> Ez egy példa az
egy belső projekt

2373
01:45:00,300 --> 01:45:04,850
hogy van, ahol mi vagyunk valójában
kiadói összegyűjteni felmérés eredményeit.

2374
01:45:04,850 --> 01:45:07,700
Tehát egy e-mailt link,
küldünk ki, hogy lesz-

2375
01:45:07,700 --> 01:45:11,350
egy kicsit linket mondván kattintással
Itt válaszolni a felmérés.

2376
01:45:11,350 --> 01:45:14,070
És ha valaki kattintással
lapra, mi történik

2377
01:45:14,070 --> 01:45:18,020
Ők azok, húzza le a biztonságos
HTML felmérés formájában S3.

2378
01:45:18,020 --> 01:45:18,980
Nincs szerver.

2379
01:45:18,980 --> 01:45:20,600
Ez csak egy S3 objektumot.

2380
01:45:20,600 --> 01:45:22,770
>> Ez a forma jön létre,
betölti fel a böngészőben.

2381
01:45:22,770 --> 01:45:24,240
Van rajta Gerinchálózat.

2382
01:45:24,240 --> 01:45:30,160
Van rajta komplex JavaScript
hogy ez fut.

2383
01:45:30,160 --> 01:45:33,557
Így nagyon gazdag alkalmazás
fut a kliens böngésző.

2384
01:45:33,557 --> 01:45:36,390
Nem tudják, hogy ők nem
kölcsönhatásban áll a hátsó kiszolgáló.

2385
01:45:36,390 --> 01:45:38,220
Ezen a ponton, az egész böngészőt.

2386
01:45:38,220 --> 01:45:41,780
>> Ők hozzák nyilvánosságra az eredményeket, hogy milyen
hívjuk az Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway egyszerűen egy webes API
amit meg lehet adni, és ismerkedj meg

2388
01:45:46,270 --> 01:45:47,760
hogy amit akarsz.

2389
01:45:47,760 --> 01:45:50,990
Ebben a konkrét esetben mi vagyunk
akasztott fel a Lambda funkciót.

2390
01:45:50,990 --> 01:45:54,797
>> Szóval a POST művelet
történik szerver nélkül.

2391
01:45:54,797 --> 01:45:56,380
Alapvetően, hogy az API Gateway ül ott.

2392
01:45:56,380 --> 01:45:58,770
Kerül nekem semmit, amíg az emberek
íráshoz hozzá, ugye?

2393
01:45:58,770 --> 01:46:00,269
A Lambda funkció csak ül ott.

2394
01:46:00,269 --> 01:46:03,760
És kerül nekem semmit, amíg
az emberek kezdenek üti meg.

2395
01:46:03,760 --> 01:46:07,270
Tehát láthatjuk, ahogy a hangerőt
nő, ez az, amikor a díjak jönnek.

2396
01:46:07,270 --> 01:46:09,390
Nem futok szerveren 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Szóval húzza formájában
le ki a vödröt,

2398
01:46:12,310 --> 01:46:15,719
és azt tegye az API-
Kapuja a Lambda funkció.

2399
01:46:15,719 --> 01:46:17,510
És akkor a Lambda
funkciót mondja, tudja

2400
01:46:17,510 --> 01:46:20,600
mit, van pár PIIs, néhány
személyazonosításra alkalmas adatokat

2401
01:46:20,600 --> 01:46:21,480
Ezekben válaszok.

2402
01:46:21,480 --> 01:46:23,020
Kaptam hozzászólás érkező felhasználók.

2403
01:46:23,020 --> 01:46:24,230
Van e-mail címeket.

2404
01:46:24,230 --> 01:46:26,190
Megvan a felhasználóneveket.

2405
01:46:26,190 --> 01:46:27,810
>> Hadd osztott ezt le.

2406
01:46:27,810 --> 01:46:30,280
Megyek generálni
metaadat ki ezt a rekordot.

2407
01:46:30,280 --> 01:46:32,850
És megyek, hogy álljon a
metaadatok DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
És tudtam titkosítja az összes adatot
és tolja DynamoDB, ha akarom.

2409
01:46:36,059 --> 01:46:38,600
De ez könnyebb számomra, ebben a
használni az esetben, hogy menjen előre az mondjuk,

2410
01:46:38,600 --> 01:46:42,800
Megyek, hogy álljon a nyers adatok
egy titkosított S3 vödör.

2411
01:46:42,800 --> 01:46:47,240
Ezért használom épült S3 szerver oldalon
titkosítás és az Amazon Key Management

2412
01:46:47,240 --> 01:46:51,600
Szerviz, hogy van egy kulcs,
lehet forgatni a rendszeres időközönként,

2413
01:46:51,600 --> 01:46:55,010
és tudom védeni, hogy PII adatok
Ennek részeként az egész munkafolyamatot.

2414
01:46:55,010 --> 01:46:55,870
>> Szóval mit tettem?

2415
01:46:55,870 --> 01:47:00,397
Épp most telepített egy egész
alkalmazást, és nekem nincs szerver.

2416
01:47:00,397 --> 01:47:02,980
Tehát az, amit eseményvezérelt alkalmazás
építészet nem az Ön számára.

2417
01:47:02,980 --> 01:47:05,730
>> Most, ha jól meggondoljuk
A felhasználási módja this--

2418
01:47:05,730 --> 01:47:08,730
mi más ügyfelek beszélek
hogy erről az architektúrát, akik

2419
01:47:08,730 --> 01:47:14,560
fuss hihetetlenül nagy kampányok, akik
nézi ezt, és megy, ó.

2420
01:47:14,560 --> 01:47:17,840
Mert most, tudnak
Alapvetően tolja odakinn,

2421
01:47:17,840 --> 01:47:21,900
hagyja, hogy a kampány csak ül
ott, amíg elindul, és nem

2422
01:47:21,900 --> 01:47:24,400
nem kell aggódnia a füge mintegy
milyen infrastrukturális

2423
01:47:24,400 --> 01:47:26,120
lesz ott, hogy támogassa azt.

2424
01:47:26,120 --> 01:47:28,600
Aztán, amint
a kampány véget ért,

2425
01:47:28,600 --> 01:47:31,520
ez olyan, mint az infrastruktúra
Csak azonnal elmúlik

2426
01:47:31,520 --> 01:47:33,680
mert tényleg
nincs infrastruktúra.

2427
01:47:33,680 --> 01:47:35,660
Ez csak kódját, hogy ül a Lambda.

2428
01:47:35,660 --> 01:47:38,560
Ez csak az adatok, hogy ül DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Ez egy csodálatos módja
alkalmazásokat építhetnek.

2430
01:47:41,340 --> 01:47:43,970
>> Közönség: Szóval ez több
efemer, mint lenne

2431
01:47:43,970 --> 01:47:45,740
ha azt tárolt tényleges szerver?

2432
01:47:45,740 --> 01:47:46,823
>> Rick Houlihan: Abszolút.

2433
01:47:46,823 --> 01:47:49,190
Mert, hogy kiszolgálópéldányt
kellene lennie egy 7/24.

2434
01:47:49,190 --> 01:47:51,954
Meg kell rendelkezésre állnia
valaki válaszolni.

2435
01:47:51,954 --> 01:47:52,620
Hát tudod mit?

2436
01:47:52,620 --> 01:47:55,410
S3 elérhető 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 mindig reagál.

2438
01:47:57,100 --> 01:47:59,320
És S3 nagyon, nagyon jó
szolgálata fel tárgyakat.

2439
01:47:59,320 --> 01:48:02,590
Azok a tárgyak lehetnek HTML fájlokat, vagy
JavaScript fájlokat, vagy amit akarsz.

2440
01:48:02,590 --> 01:48:07,430
Akkor fuss nagyon gazdag internetes alkalmazások
az S3 vödrök, és az emberek.

2441
01:48:07,430 --> 01:48:10,160
>> És ez az a gondolat itt
van, hogy távol az út

2442
01:48:10,160 --> 01:48:11,270
szoktuk gondolni.

2443
01:48:11,270 --> 01:48:14,270
Mindannyian használt gondolkodni
szempontjából szerverek és a házigazdák.

2444
01:48:14,270 --> 01:48:16,580
Ez nem arról szól, hogy többé.

2445
01:48:16,580 --> 01:48:19,310
Arról van szó, infrastruktúra kódot.

2446
01:48:19,310 --> 01:48:22,470
Telepítse a kódot a felhő, és
hagyja, hogy a felhő el fogja indítani.

2447
01:48:22,470 --> 01:48:24,980
És ez az, amit AWS akar csinálni.

2448
01:48:24,980 --> 01:48:29,690
>> Közönség: Szóval az arany doboz közepén
Az API Gateway nem szerver-szerű,

2449
01:48:29,690 --> 01:48:30,576
hanem az, csak--

2450
01:48:30,576 --> 01:48:32,850
>> Rick Houlihan: Ön szerint
rá, mint szerver homlokzat.

2451
01:48:32,850 --> 01:48:38,040
Minden ez is el fog tartani egy HTTP
kérni, és leképezni a másik folyamat.

2452
01:48:38,040 --> 01:48:39,192
Ez minden, hogy nem.

2453
01:48:39,192 --> 01:48:41,525
És ebben az esetben, mi feltérképezése
azt egy Lambda funkció.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Rendben, ez minden, amit kaptam.

2456
01:48:45,410 --> 01:48:46,190
Nagyon szépen köszönöm.

2457
01:48:46,190 --> 01:48:46,800
Nagyra értékelem.

2458
01:48:46,800 --> 01:48:48,100
Tudom, hogy szeretnénk egy kicsit az idő múlásával.

2459
01:48:48,100 --> 01:48:49,980
És remélhetőleg srácok
Egy kis információ

2460
01:48:49,980 --> 01:48:51,410
hogy lehet elvenni ma.

2461
01:48:51,410 --> 01:48:53,520
És elnézést kérek, ha elmentem
át néhány fejeteket,

2462
01:48:53,520 --> 01:48:56,697
de van egy jó csomó
alapvető megalapozó ismeretek

2463
01:48:56,697 --> 01:48:58,280
azt gondolom, hogy nagyon értékes az Ön számára.

2464
01:48:58,280 --> 01:48:59,825
Szóval köszönöm, hogy rám.

2465
01:48:59,825 --> 01:49:00,325
[TAPS]

2466
01:49:00,325 --> 01:49:02,619
Közönség: [hallható]
az, amikor azt mondták,

2467
01:49:02,619 --> 01:49:05,160
meg kellett, hogy menjen át a dolog
elejétől végéig

2468
01:49:05,160 --> 01:49:07,619
hogy a megfelelő értékek
vagy ugyanazokat az értékeket,

2469
01:49:07,619 --> 01:49:09,410
milyen lenne az értékeket
változik meg, ha [hallhatatlan].

2470
01:49:09,410 --> 01:49:10,480
>> Rick Houlihan: Ó, idempotens?

2471
01:49:10,480 --> 01:49:11,800
Hogyan értékeit változtatni?

2472
01:49:11,800 --> 01:49:15,180
Nos, azért, mert ha nem futottam
ez egészen a végéig,

2473
01:49:15,180 --> 01:49:19,770
akkor nem tudom, mi változik
került sor az utolsó mérföld.

2474
01:49:19,770 --> 01:49:22,144
Ez nem lesz a
adatokkal, amit láttam.

2475
01:49:22,144 --> 01:49:24,560
Közönség: Ó, így csak
Még nem ütött a teljes bemenet.

2476
01:49:24,560 --> 01:49:24,770
Rick Houlihan: Így van.

2477
01:49:24,770 --> 01:49:26,895
El kell menni az elejétől
végét, és akkor ez

2478
01:49:26,895 --> 01:49:29,280
lesz konzisztens állapotban.

2479
01:49:29,280 --> 01:49:31,520
Hűvös.

2480
01:49:31,520 --> 01:49:35,907
>> Közönség: Szóval megmutatta DynamoDB
tehetünk a dokumentum vagy a kulcs értékét.

2481
01:49:35,907 --> 01:49:38,740
És mi töltött sok időt a
kulcs értéke egy hash, és milyen módon

2482
01:49:38,740 --> 01:49:40,005
flip azt körül.

2483
01:49:40,005 --> 01:49:43,255
Amikor megnézte azokat a táblákat, hogy
maga mögött hagyva a dokumentumot megközelítés?

2484
01:49:43,255 --> 01:49:44,600
>> Rick Houlihan: Én nem tenném
mondjuk hagyva maga mögött.

2485
01:49:44,600 --> 01:49:45,855
>> Közönség: Ők elváltak the--

2486
01:49:45,855 --> 01:49:49,140
>> Rick Houlihan: a dokumentumot
megközelítést, a dokumentumtípus DynamoDB

2487
01:49:49,140 --> 01:49:50,880
csak gondoljunk, mint egy másik attribútum.

2488
01:49:50,880 --> 01:49:53,560
Ez egy olyan tulajdonság, amely tartalmazza
hierarchikus adatszerkezet.

2489
01:49:53,560 --> 01:49:56,980
És akkor a lekérdezések,
akkor a tulajdonságok

2490
01:49:56,980 --> 01:49:59,480
ezen objektumok Object jelölés.

2491
01:49:59,480 --> 01:50:03,562
Szóval lehet szűrni a beágyazott
ingatlan a JSON dokumentum.

2492
01:50:03,562 --> 01:50:05,520
Közönség: Tehát minden alkalommal, amikor
nem egy dokumentumot megközelítést,

2493
01:50:05,520 --> 01:50:07,906
Én is egyfajta megérkezik a tabular--

2494
01:50:07,906 --> 01:50:08,780
Közönség: Abszolút.

2495
01:50:08,780 --> 01:50:09,800
Közönség: --indexes és
dolog, amit csak beszélgettünk.

2496
01:50:09,800 --> 01:50:11,280
Rick Houlihan: Igen, a
indexek, meg minden,

2497
01:50:11,280 --> 01:50:13,363
ha azt szeretné, hogy az index
tulajdonságait a JSON,

2498
01:50:13,363 --> 01:50:18,230
az is, hogy mi volna a teendő, hogy az, ha
beszúr egy JSON vagy dokumentumot

2499
01:50:18,230 --> 01:50:20,780
a Dynamo, akkor használja patakok.

2500
01:50:20,780 --> 01:50:22,400
Patakok volna olvasni a bemenet.

2501
01:50:22,400 --> 01:50:24,340
Azt kap, hogy JSON
objektumot, és azt mondanám, OK,

2502
01:50:24,340 --> 01:50:26,030
mi az ingatlan akarok index?

2503
01:50:26,030 --> 01:50:28,717
>> Létrehoz egy származékos asztalra.

2504
01:50:28,717 --> 01:50:30,300
Most, hogy ez így működik most.

2505
01:50:30,300 --> 01:50:32,650
Mi nem teszi lehetővé, hogy index
közvetlenül azokat a tulajdonságokat.

2506
01:50:32,650 --> 01:50:33,520
>> Közönség: Tabularizing a dokumentumokat.

2507
01:50:33,520 --> 01:50:36,230
>> Rick Houlihan: Pontosan, simító
ez, tabularizing meg, pontosan.

2508
01:50:36,230 --> 01:50:37,415
Ez az, amit teszel vele.

2509
01:50:37,415 --> 01:50:37,860
>> Közönség: Köszönöm.

2510
01:50:37,860 --> 01:50:39,609
>> Rick Houlihan: Igen,
abszolút, köszönöm.

2511
01:50:39,609 --> 01:50:42,240
Közönség: Szóval ez a fajta
Mongo találkozik Redis osztályozók.

2512
01:50:42,240 --> 01:50:43,990
>> Rick Houlihan: Igen,
ez egy csomó ilyen.

2513
01:50:43,990 --> 01:50:45,940
Ez egy jó leírást érte.

2514
01:50:45,940 --> 01:50:47,490
Hűvös.

2515
01:50:47,490 --> 01:50:49,102