1
00:00:00,000 --> 00:00:04,969
>> [Přehrávání hudby]

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: Dobře.

3
00:00:06,010 --> 00:00:06,600
Ahoj všichni.

4
00:00:06,600 --> 00:00:07,670
Jmenuji se Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Jsem senior ředitel
Řešení architekt společnosti AWS.

6
00:00:10,330 --> 00:00:14,070
Zaměřuji se na NoSQL a
Technologie DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Jsem tu dnes mluvit
jste trochu o nich.

8
00:00:16,930 --> 00:00:18,970
>> Moje pozadí je
především v datové vrstvy.

9
00:00:18,970 --> 00:00:21,390
Strávil jsem půlku rozvoj
kariéra psaní databázi,

10
00:00:21,390 --> 00:00:25,930
přístup k datům, řešení
pro různé aplikace.

11
00:00:25,930 --> 00:00:30,000
Byl jsem v oblasti virtualizace Cloud
asi 20 let.

12
00:00:30,000 --> 00:00:33,460
Takže před tím, než Cloud Cloud,
jsme byli zvyklí říkat utility computing.

13
00:00:33,460 --> 00:00:37,170
A nápad byl, je to jako
PG & E, budete platit za to, co používáte.

14
00:00:37,170 --> 00:00:38,800
Dnes ji nazýváme mrak.

15
00:00:38,800 --> 00:00:41,239
>> Ale v průběhu let jsem pracoval
pro pár firem

16
00:00:41,239 --> 00:00:42,530
jste pravděpodobně nikdy neslyšeli.

17
00:00:42,530 --> 00:00:47,470
Ale já jsem sestavil seznam technických
úspěchy, myslím, že bych.

18
00:00:47,470 --> 00:00:51,620
Mám osm patentů v Cloud systémy
virtualizace, mikroprocesor design,

19
00:00:51,620 --> 00:00:54,440
komplexní zpracování událostí,
a jiných oblastech.

20
00:00:54,440 --> 00:00:58,290
>> Takže v těchto dnech, jsem se zaměřují především na NoSQL
technologie a příští generace

21
00:00:58,290 --> 00:00:59,450
databáze.

22
00:00:59,450 --> 00:01:03,370
A to je to obecně, co budu
tu být s tebou mluvit dnes o.

23
00:01:03,370 --> 00:01:06,030
Takže to, co můžete očekávat
z tohoto zasedání,

24
00:01:06,030 --> 00:01:08,254
půjdeme přes krátké
Historie zpracování dat.

25
00:01:08,254 --> 00:01:10,420
Je vždy užitečné
pochopit, odkud jsme přišli

26
00:01:10,420 --> 00:01:12,400
a důvod, proč jsme tam, kde jsme.

27
00:01:12,400 --> 00:01:15,600
A budeme mluvit trochu
bit o technologii NoSQL

28
00:01:15,600 --> 00:01:17,500
od základní hlediska.

29
00:01:17,500 --> 00:01:19,870
>> Dostaneme se do některé z
vnitřní vybavení DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB je AWS to není chuť.

31
00:01:24,350 --> 00:01:27,340
Je plně organizovaná a
Hostované řešení NoSQL.

32
00:01:27,340 --> 00:01:32,420
A budeme mluvit trochu o stůl
struktura, API, datové typy, indexy,

33
00:01:32,420 --> 00:01:35,177
a některé z niternosti
tohoto DynamoDB technologie.

34
00:01:35,177 --> 00:01:37,760
Dostaneme se do některé z designu
vzory a osvědčených postupů.

35
00:01:37,760 --> 00:01:39,968
Budeme mluvit o tom, jak
použití této technologie pro některé

36
00:01:39,968 --> 00:01:41,430
dnešních aplikací.

37
00:01:41,430 --> 00:01:44,820
A pak budeme mluvit trochu
o vývoji či vzniku

38
00:01:44,820 --> 00:01:48,980
nového paradigmatu programování
tzv aplikace událostmi řízené

39
00:01:48,980 --> 00:01:51,580
a jak DynamoDB hraje v, že stejně.

40
00:01:51,580 --> 00:01:54,690
A my vám necháme trochu
referenční architektury diskuse

41
00:01:54,690 --> 00:01:59,540
takže můžeme hovořit o některých
způsoby, jak můžete použít DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Takže nejprve off-- je to otázka
Slyšel jsem, že hodně, je to, co je databáze.

43
00:02:04,116 --> 00:02:06,240
Mnoho lidí si myslí, že
víte, co je databáze.

44
00:02:06,240 --> 00:02:08,360
Pokud jste Google, uvidíte to.

45
00:02:08,360 --> 00:02:11,675
Je to strukturovaný soubor údajů konalo
v počítači, zejména ten, který

46
00:02:11,675 --> 00:02:13,600
je k dispozici ve různými způsoby.

47
00:02:13,600 --> 00:02:16,992
Myslím, že je to dobrý
Definice moderní databáze.

48
00:02:16,992 --> 00:02:19,450
Ale nelíbí se mi to, protože
to znamená několik věcí.

49
00:02:19,450 --> 00:02:20,935
To znamená strukturu.

50
00:02:20,935 --> 00:02:23,120
A to znamená, že je to v počítači.

51
00:02:23,120 --> 00:02:25,750
A databáze ne
vždy existovat na počítačích.

52
00:02:25,750 --> 00:02:28,020
Databáze vlastně existoval v mnoha ohledech.

53
00:02:28,020 --> 00:02:32,000
>> Takže lepší definice
Databáze je něco takového.

54
00:02:32,000 --> 00:02:34,786
Databáze je organizovaná
mechanismus pro ukládání, správu,

55
00:02:34,786 --> 00:02:35,910
a získávání informací.

56
00:02:35,910 --> 00:02:36,868
To je od About.com.

57
00:02:36,868 --> 00:02:42,080
Tak jsem to rád, protože je to opravdu mluví
o databázi, že je úložiště,

58
00:02:42,080 --> 00:02:44,800
studnicí
informace, ne nutně

59
00:02:44,800 --> 00:02:46,780
něco, co sedí na počítači.

60
00:02:46,780 --> 00:02:49,290
A celé historii, my
ne vždy měli počítačů.

61
00:02:49,290 --> 00:02:52,110
>> A teď, když jsem se zeptat průměr
developer dnes to, co je

62
00:02:52,110 --> 00:02:54,770
databázi, že je odpověď jsem si.

63
00:02:54,770 --> 00:02:56,070
Někde jsem si držet věci.

64
00:02:56,070 --> 00:02:56,670
Právo?

65
00:02:56,670 --> 00:02:58,725
A je to pravda.

66
00:02:58,725 --> 00:02:59,600
Ale je to nešťastné.

67
00:02:59,600 --> 00:03:02,700
Vzhledem k tomu, databáze je opravdu
základem moderní aplikace.

68
00:03:02,700 --> 00:03:04,810
To je základ
z každé aplikace.

69
00:03:04,810 --> 00:03:07,240
A jak si vybudovat, že
databáze, jak strukturovat

70
00:03:07,240 --> 00:03:11,750
že data se bude diktovat, jak, že
Aplikace vystupuje jako měřítka.

71
00:03:11,750 --> 00:03:14,640
>> Takže mnoho mé práce dnes
se zabývá, co

72
00:03:14,640 --> 00:03:17,180
se stane, když vývojáři
tento přístup

73
00:03:17,180 --> 00:03:19,510
a řešit následky
aplikace, která

74
00:03:19,510 --> 00:03:24,966
Nyní je škálování nad rámec původní
záměr a utrpení ze špatného návrhu.

75
00:03:24,966 --> 00:03:26,840
Takže doufejme, že když vás
odejít dnes, budete

76
00:03:26,840 --> 00:03:29,010
mají několik nástrojů v
tvůj pás, který tě držet

77
00:03:29,010 --> 00:03:32,566
od dělat ty stejné chyby.

78
00:03:32,566 --> 00:03:33,066
Dobře.

79
00:03:33,066 --> 00:03:36,360
Tak pojďme mluvit o trochou
časová osa databázových technologií.

80
00:03:36,360 --> 00:03:38,830
Myslím, že jsem četl
článek Není to tak dávno

81
00:03:38,830 --> 00:03:43,020
a řekl něco na lines--
je to velmi poetické prohlášení.

82
00:03:43,020 --> 00:03:46,590
To řekl, že historie
dat zpracování je

83
00:03:46,590 --> 00:03:49,350
plná vysokých vodoznaků
hojnosti dat.

84
00:03:49,350 --> 00:03:49,920
DOBŘE.

85
00:03:49,920 --> 00:03:52,532
A teď, myslím, že je docela pravda.

86
00:03:52,532 --> 00:03:54,990
Ale já jsem vlastně podívat, je, jak
historie byla skutečně naplněna

87
00:03:54,990 --> 00:03:56,820
s vysokým vodoznakem tlaku dat.

88
00:03:56,820 --> 00:04:00,040
Vzhledem k tomu, rychlost přenosu dat z
Požití nikdy klesá.

89
00:04:00,040 --> 00:04:01,360
Je to jen jde nahoru.

90
00:04:01,360 --> 00:04:03,670
>> A inovace nastane, když
vidíme tlak dat, což

91
00:04:03,670 --> 00:04:07,825
je množství dat, které je
nyní v přichází do systému.

92
00:04:07,825 --> 00:04:12,027
A to nelze zpracovat
účinně buď v čase, nebo z hlediska nákladů.

93
00:04:12,027 --> 00:04:14,110
A to je, když začneme
se podívat na tlaku dat.

94
00:04:14,110 --> 00:04:15,920
>> Takže když jsme se podívat na
první databází, toto

95
00:04:15,920 --> 00:04:17,180
je ten, který byl mezi naše uši.

96
00:04:17,180 --> 00:04:18,310
Jsme všichni s tím narodil.

97
00:04:18,310 --> 00:04:19,194
Je to pěkná databáze.

98
00:04:19,194 --> 00:04:21,110
To má vysokou dostupnost.

99
00:04:21,110 --> 00:04:21,959
Je to vždy.

100
00:04:21,959 --> 00:04:23,930
Vždy se můžete dostat.

101
00:04:23,930 --> 00:04:24,890
>> Ale je to pro jednoho uživatele.

102
00:04:24,890 --> 00:04:26,348
Nelze sdílet své myšlenky s vámi.

103
00:04:26,348 --> 00:04:28,370
Nemůžete dostat své myšlenky
když je chcete mít.

104
00:04:28,370 --> 00:04:30,320
A jejich abilitiy není tak dobrá.

105
00:04:30,320 --> 00:04:32,510
Zapomínáme věci.

106
00:04:32,510 --> 00:04:36,540
Tu a tam, jeden z nás listy
a přesune na jiný existenci

107
00:04:36,540 --> 00:04:39,110
a ztratíme všechno
která byla v této databázi.

108
00:04:39,110 --> 00:04:40,640
Takže to není tak dobré.

109
00:04:40,640 --> 00:04:43,189
>> A to fungovalo dobře v průběhu času
když jsme byli zpět v den

110
00:04:43,189 --> 00:04:46,230
když všechno, co jsme opravdu potřebovali vědět, je,
kde budeme pokračovat zítra

111
00:04:46,230 --> 00:04:49,630
nebo tam, kde jsme se shromáždit nejlepší jídlo.

112
00:04:49,630 --> 00:04:52,820
Ale když jsme začali pěstovat jako
civilizace a vláda začala

113
00:04:52,820 --> 00:04:55,152
vstoupit do bytí, a
podniky začaly vyvíjet,

114
00:04:55,152 --> 00:04:57,360
jsme začali si uvědomíme,
Potřebujeme trochu víc, než to, co

115
00:04:57,360 --> 00:04:58,210
jsme mohli dát do naší hlavě.

116
00:04:58,210 --> 00:04:58,870
Dobře?

117
00:04:58,870 --> 00:05:00,410
>> Potřebovali jsme systémy záznamu.

118
00:05:00,410 --> 00:05:02,220
Potřebovali jsme místa, aby ukládání dat schopné.

119
00:05:02,220 --> 00:05:05,450
Tak jsme začali psát dokumenty,
vytváření knihoven a archivů.

120
00:05:05,450 --> 00:05:08,000
Začali jsme vyvíjet
Systém Ledger účetnictví.

121
00:05:08,000 --> 00:05:12,200
A že systém počítání saldokontní
běžel svět pro mnoho století,

122
00:05:12,200 --> 00:05:15,580
A možná i tisíciletí as
jsme trochu rostla k věci

123
00:05:15,580 --> 00:05:18,420
pokud tento náklad údaje předčil
schopnost těchto systémů

124
00:05:18,420 --> 00:05:19,870
aby bylo možné jej obsahovat.

125
00:05:19,870 --> 00:05:22,070
>> A to se skutečně stalo v 1880s.

126
00:05:22,070 --> 00:05:22,570
Právo?

127
00:05:22,570 --> 00:05:24,390
V 1880 amerického sčítání lidu.

128
00:05:24,390 --> 00:05:26,976
To je opravdu, kde soustružení
bod moderní zpracování dat.

129
00:05:26,976 --> 00:05:28,850
To je bod, ve
což je množství dat

130
00:05:28,850 --> 00:05:32,060
který byl shromážděné
Vláda USA se dostal do bodu,

131
00:05:32,060 --> 00:05:34,005
kde to trvalo osm let zpracovat.

132
00:05:34,005 --> 00:05:36,350
>> Teď, osm years-- as
víte, sčítání lidu

133
00:05:36,350 --> 00:05:39,180
jezdí každých 10 years--, takže je to
docela zřejmé, že když jsme

134
00:05:39,180 --> 00:05:41,419
dostal 1890 sčítání lidu,
Množství dat, které

135
00:05:41,419 --> 00:05:43,210
šel být zpracovány
vládou byl

136
00:05:43,210 --> 00:05:46,335
bude překračují 10 let to tak
by se do zahájila nové sčítání lidu.

137
00:05:46,335 --> 00:05:47,250
To byl problém.

138
00:05:47,250 --> 00:05:49,000
>> Takže chlápek jménem Herman
Hollerith přišel

139
00:05:49,000 --> 00:05:52,640
a on vynalezl přístroj nahraje punč
karty, punč čtečka karet, děrný štítek

140
00:05:52,640 --> 00:05:58,420
tabulátor, a kolace
mechanismy pro tuto technologii.

141
00:05:58,420 --> 00:06:01,860
A že společnost, která se tvořil u
čas, spolu s několika ostatními,

142
00:06:01,860 --> 00:06:05,450
ve skutečnosti se stal jedním z pilíři
malá firma známe dnes vyzvala IBM.

143
00:06:05,450 --> 00:06:08,417
>> Takže IBM původně byl v
obchodní databáze.

144
00:06:08,417 --> 00:06:09,750
A to je opravdu to, co udělali.

145
00:06:09,750 --> 00:06:11,110
Udělali zpracování dat.

146
00:06:11,110 --> 00:06:15,400
>> Jak tak šíření punč
karty, geniální mechanismy

147
00:06:15,400 --> 00:06:18,560
že budou moci využít, že
Technologie na hlasování setříděné sady výsledků.

148
00:06:18,560 --> 00:06:20,726
Můžete vidět v tomto snímku
K dispozici máme little--

149
00:06:20,726 --> 00:06:23,970
je to trochu small-- ale můžete vidět
velmi důmyslný mechanický mechanismus

150
00:06:23,970 --> 00:06:26,970
kde máme punč balíček karet.

151
00:06:26,970 --> 00:06:28,720
A brát něčí
trochu šroubovák

152
00:06:28,720 --> 00:06:31,400
a lepení prostřednictvím
sloty a zvednutím nahoru

153
00:06:31,400 --> 00:06:34,820
se dostat, že zápas, který
seřazené výsledky set.

154
00:06:34,820 --> 00:06:36,270
>> Toto je agregace.

155
00:06:36,270 --> 00:06:38,690
Děláme to po celou dobu
dnes v počítači,

156
00:06:38,690 --> 00:06:40,100
kde to děláte v databázi.

157
00:06:40,100 --> 00:06:41,620
Použili jsme to udělat ručně, je to tak?

158
00:06:41,620 --> 00:06:42,994
Lidé dát tyto věci dohromady.

159
00:06:42,994 --> 00:06:45,440
A bylo to šíření
těchto děrných štítků

160
00:06:45,440 --> 00:06:50,070
do toho, co jsme nazvali datových bubnů
a datové kotouče, papírové pásky.

161
00:06:50,070 --> 00:06:55,980
>> Zpracování dat průmysl vzal
poučení z klavírů hráče.

162
00:06:55,980 --> 00:06:57,855
Piana zpátky
na přelomu století

163
00:06:57,855 --> 00:07:02,100
používali papírové kotouče s drážkami
na to říct, které klíče hrát.

164
00:07:02,100 --> 00:07:05,380
Tak, že technologie byla upravena
nakonec pro ukládání digitálních dat,

165
00:07:05,380 --> 00:07:08,070
protože oni mohli dát, že data
na těchto papírovou pásku rolích.

166
00:07:08,070 --> 00:07:10,870
>> Nyní, jako výsledek, údaje
byl actually-- jak

167
00:07:10,870 --> 00:07:14,960
máte přístup tato data byla přímo
v závislosti na tom, jak jste je uložili.

168
00:07:14,960 --> 00:07:17,825
Takže když jsem dal data na pásku,
Měl jsem lineárně přístup k datům.

169
00:07:17,825 --> 00:07:20,475
Musel jsem se vrátit celou
Páska přístup ke všem datům.

170
00:07:20,475 --> 00:07:22,600
Mám-li vložit data do punč
karty, mohl jsem to přístup

171
00:07:22,600 --> 00:07:26,270
v trochu více náhodný
móda, možná ne tak rychle.

172
00:07:26,270 --> 00:07:30,770
>> Ale tam bylo omezení v tom, jak
přístup k datům na základě toho, jak byl uložen.

173
00:07:30,770 --> 00:07:32,890
A tak to byl problém,
jít do 50. let.

174
00:07:32,890 --> 00:07:37,890
Opět platí, že můžeme začít vidět, že jako my
vyvíjet nové technologie pro zpracování

175
00:07:37,890 --> 00:07:41,670
data, vpravo, otevírá
dveře pro nová řešení,

176
00:07:41,670 --> 00:07:45,852
pro nové programy, nové
Žádosti o těchto dat.

177
00:07:45,852 --> 00:07:47,810
A opravdu, správa věcí veřejných
mohl být důvodem

178
00:07:47,810 --> 00:07:49,435
Proto jsme vyvinuli některé z těchto systémů.

179
00:07:49,435 --> 00:07:52,290
Ale firma se rychle stal se
Řidič za evoluci

180
00:07:52,290 --> 00:07:54,720
moderní databáze a
moderní systém souborů.

181
00:07:54,720 --> 00:07:56,870
>> Takže další věc, která se
přišel byl v 50. letech

182
00:07:56,870 --> 00:08:00,780
byl systém souborů a
Vývoj náhodného skladování přístupu.

183
00:08:00,780 --> 00:08:02,050
To byla krásná.

184
00:08:02,050 --> 00:08:06,230
Nyní jsou všechny náhlé, můžeme dát naše
soubory kdekoli na těchto pevných discích

185
00:08:06,230 --> 00:08:09,760
a můžeme přístup k těmto datům náhodně.

186
00:08:09,760 --> 00:08:11,950
Můžeme analyzovat, že
Informace ze souborů.

187
00:08:11,950 --> 00:08:14,920
A jsme vyřešili všech světových
problémy s zpracování dat.

188
00:08:14,920 --> 00:08:17,550
>> A to trvalo asi 20 nebo
30 let až do evoluce

189
00:08:17,550 --> 00:08:22,100
relační databáze, která
je, když se svět rozhodli jsme se teď

190
00:08:22,100 --> 00:08:27,940
musí mít úložiště, které překazí
rozléhat dat napříč souboru

191
00:08:27,940 --> 00:08:29,540
systémy, které jsme vytvořili. Právo?

192
00:08:29,540 --> 00:08:34,270
Příliš mnoho dat distribuovaných v příliš mnoho
místa, de-duplikace dat,

193
00:08:34,270 --> 00:08:37,120
a náklady na skladování byl obrovský.

194
00:08:37,120 --> 00:08:43,760
>> V 70. letech, nejdražší zdroj
že počítač měl byl skladování.

195
00:08:43,760 --> 00:08:46,200
Procesor byl
vnímána jako fixní náklady.

196
00:08:46,200 --> 00:08:49,030
Když jsem se koupit box,
CPU dělá nějakou práci.

197
00:08:49,030 --> 00:08:51,960
Bude to být předení, zda
je to vlastně pracuje, nebo ne.

198
00:08:51,960 --> 00:08:53,350
To je opravdu fixních nákladů.

199
00:08:53,350 --> 00:08:56,030
>> Ale to, co mě stálo jako
podnikání je skladování.

200
00:08:56,030 --> 00:09:00,020
Mám-li koupit více disků další
měsíc, to je skutečné náklady, které jsem zaplatit.

201
00:09:00,020 --> 00:09:01,620
A že skladování je drahé.

202
00:09:01,620 --> 00:09:05,020
>> Nyní jsme rychle dopředu 40 roků
a máme jiný problém.

203
00:09:05,020 --> 00:09:10,020
Compute je nyní
nejdražší zdroj.

204
00:09:10,020 --> 00:09:11,470
Úložiště je levné.

205
00:09:11,470 --> 00:09:14,570
Myslím, že jsme může jít kamkoliv na
cloud a můžeme najít levné skladování.

206
00:09:14,570 --> 00:09:17,190
Ale to, co nemohu najít je levná výpočetní.

207
00:09:17,190 --> 00:09:20,700
>> Takže evoluce dnešní
Technologie, databázové technologie,

208
00:09:20,700 --> 00:09:23,050
je opravdu zaměřeny na
distribuované databáze

209
00:09:23,050 --> 00:09:26,960
že netrpí
stejný typ stupnice

210
00:09:26,960 --> 00:09:29,240
omezení relačních databází.

211
00:09:29,240 --> 00:09:32,080
Budeme mluvit trochu o
co to vlastně znamená.

212
00:09:32,080 --> 00:09:34,760
>> Ale jeden z důvodů, proč a
Řidič za tohle-- my

213
00:09:34,760 --> 00:09:38,290
mluvil o tlaku dat.

214
00:09:38,290 --> 00:09:41,920
Tlak dat je něco,
že podporuje inovaci.

215
00:09:41,920 --> 00:09:44,610
A když se podíváte na více než
posledních pět let,

216
00:09:44,610 --> 00:09:48,180
toto je tabulka k čemu se údaje
zatížení v rámci obecného podniku

217
00:09:48,180 --> 00:09:49,640
vypadá v posledních pěti letech.

218
00:09:49,640 --> 00:09:52,570
>> A obecné pravidlo
Tyto days-- pokud jdete Google--

219
00:09:52,570 --> 00:09:55,290
90% z údajů, které
ukládáme dnes, a to bylo

220
00:09:55,290 --> 00:09:57,330
vytvořených v posledních dvou letech.

221
00:09:57,330 --> 00:09:57,911
DOBŘE.

222
00:09:57,911 --> 00:09:59,410
Nyní, se nejedná o trend, který je nový.

223
00:09:59,410 --> 00:10:01,230
To je trend, který byl
chodit na 100 let.

224
00:10:01,230 --> 00:10:03,438
Od té doby, Herman Hollerith
vyvinul děrný štítek,

225
00:10:03,438 --> 00:10:08,040
jsme byli budování datových úložišť
a shromažďování údajů na fenomenální sazby.

226
00:10:08,040 --> 00:10:10,570
>> Takže v průběhu posledních 100 let,
jsme viděli tento trend.

227
00:10:10,570 --> 00:10:11,940
To nebude měnit.

228
00:10:11,940 --> 00:10:14,789
Do budoucna budeme vidět
to, ne-li zrychlené trend.

229
00:10:14,789 --> 00:10:16,330
A můžete vidět, jak to vypadá.

230
00:10:16,330 --> 00:10:23,510
>> Pokud se firma v roce 2010 měl jeden
terabyte dat v rámci řízení,

231
00:10:23,510 --> 00:10:27,080
Dnes to znamená, že jsou
správu 6,5 petabajtů dat.

232
00:10:27,080 --> 00:10:30,380
To je 6500 krát více dat.

233
00:10:30,380 --> 00:10:31,200
A vím, že tohle.

234
00:10:31,200 --> 00:10:33,292
Každý den jsem se pracovat s těmito podniky.

235
00:10:33,292 --> 00:10:35,000
Před pěti lety jsem
by se mluvit na společnosti

236
00:10:35,000 --> 00:10:38,260
kdo by se mnou mluvit o tom, co bolesti
to je řídit terabajtů dat.

237
00:10:38,260 --> 00:10:39,700
A oni by se mluvit
se mnou o tom, jak vidíme

238
00:10:39,700 --> 00:10:41,825
že je to pravděpodobně bude
být petabyte nebo dva

239
00:10:41,825 --> 00:10:43,030
během několika let.

240
00:10:43,030 --> 00:10:45,170
>> Tyto stejné společnosti
Dnes mám schůzku s,

241
00:10:45,170 --> 00:10:48,100
a oni se mnou mluvit o
Problémem jsou zde mají řídící

242
00:10:48,100 --> 00:10:51,440
desítky, 20 petabajtů dat.

243
00:10:51,440 --> 00:10:53,590
Takže Exploze
Data v průmyslu

244
00:10:53,590 --> 00:10:56,670
pohání obrovský
Potřebujete pro lepší řešení.

245
00:10:56,670 --> 00:11:00,980
A relační databáze je
prostě žít až do poptávky.

246
00:11:00,980 --> 00:11:03,490
>> A tak je tu lineární
korelace mezi tlakem dat

247
00:11:03,490 --> 00:11:05,210
a technické inovace.

248
00:11:05,210 --> 00:11:07,780
Historie nám ukázala,
to, že v průběhu doby,

249
00:11:07,780 --> 00:11:11,090
vždy, když se objem dat
které musí být zpracovány

250
00:11:11,090 --> 00:11:15,490
přesahuje kapacitu systému
zpracovat ji v rozumném čase

251
00:11:15,490 --> 00:11:18,870
nebo za rozumnou cenu,
pak nové technologie

252
00:11:18,870 --> 00:11:21,080
jsou vynalezeny na řešení těchto problémů.

253
00:11:21,080 --> 00:11:24,090
Tyto nové technologie,
naopak, otevřete dvířka

254
00:11:24,090 --> 00:11:27,840
na jinou sadu problémů, které
sbírá i další data.

255
00:11:27,840 --> 00:11:29,520
>> Nyní, nebudeme to zastavit.

256
00:11:29,520 --> 00:11:30,020
Právo?

257
00:11:30,020 --> 00:11:31,228
Nebudeme to zastavit.

258
00:11:31,228 --> 00:11:31,830
Proč?

259
00:11:31,830 --> 00:11:35,520
Vzhledem k tomu, nemůžete vědět všechno
tam je znát ve vesmíru.

260
00:11:35,520 --> 00:11:40,510
A tak dlouho, jak jsme byli naživu,
v celé historii člověka,

261
00:11:40,510 --> 00:11:43,440
jsme vždy řízený vědět víc.

262
00:11:43,440 --> 00:11:49,840
>> Takže to vypadá, že každý palec se pohybujeme
po cestě vědeckého objevu,

263
00:11:49,840 --> 00:11:54,620
jsme se množí množství dat
že musíme zpracovat exponenciálně

264
00:11:54,620 --> 00:11:59,920
jak odhalit víc a víc a víc
o vnitřním fungování života,

265
00:11:59,920 --> 00:12:04,530
o tom, jak vesmír funguje, o
řídil vědecký objev,

266
00:12:04,530 --> 00:12:06,440
a vynález, který
děláme dnes.

267
00:12:06,440 --> 00:12:09,570
Objem dat jen
neustále zvyšuje.

268
00:12:09,570 --> 00:12:12,120
Takže je schopen vypořádat se s
Tento problém je obrovský.

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

270
00:12:14,790 --> 00:12:17,410
>> Takže jedna z věcí
se podíváme, jak, proč NoSQL?

271
00:12:17,410 --> 00:12:19,200
Jak NoSQL tento problém vyřešit?

272
00:12:19,200 --> 00:12:24,980
No, relační databáze,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL--, že je opravdu konstrukt
relační database-- tyto věci jsou

274
00:12:28,600 --> 00:12:30,770
optimalizovaný pro skladování.

275
00:12:30,770 --> 00:12:33,180
>> Zpátky v 70. letech, se znovu,
disk je drahé.

276
00:12:33,180 --> 00:12:36,990
Dotační Výkon skladování
V podniku je nikdy nekončící.

277
00:12:36,990 --> 00:12:37,490
Já vím.

278
00:12:37,490 --> 00:12:38,020
Žil jsem to.

279
00:12:38,020 --> 00:12:41,250
Napsal jsem ovladače úložiště pro
enterprised SuperServer firmy

280
00:12:41,250 --> 00:12:42,470
zpátky v 90. letech.

281
00:12:42,470 --> 00:12:45,920
A faktem je stáčení další
diskové pole bylo jen něco,

282
00:12:45,920 --> 00:12:47,600
každý den v podniku stalo.

283
00:12:47,600 --> 00:12:49,030
A to nikdy nepřestalo.

284
00:12:49,030 --> 00:12:52,690
Vyšší hustota skladování, poptávka
pro vysokou hustotou skladování,

285
00:12:52,690 --> 00:12:56,340
a pro efektivnější ukládání
devices-- to nikdy nepřestalo.

286
00:12:56,340 --> 00:13:00,160
>> A NoSQL je špičkovou technologií
proto, že normalizuje data.

287
00:13:00,160 --> 00:13:02,210
Je to de-kopíruje data.

288
00:13:02,210 --> 00:13:07,180
Klade data ve struktuře, která
je agnostik na každý vzorek přístup.

289
00:13:07,180 --> 00:13:11,600
Více aplikací, které může zasáhnout
SQL databáze, spouštět dotazy ad hoc,

290
00:13:11,600 --> 00:13:15,950
a získat data ve tvaru, který se
je třeba zpracovat pro své pracovní zátěže.

291
00:13:15,950 --> 00:13:17,570
To zní fantasticky.

292
00:13:17,570 --> 00:13:21,350
Ale faktem je, s jakýmkoliv
systém, pokud je to agnostik ke všemu,

293
00:13:21,350 --> 00:13:23,500
je optimalizován pro nic za nic.

294
00:13:23,500 --> 00:13:24,050
DOBŘE?

295
00:13:24,050 --> 00:13:26,386
>> A to je to, co jsme si s
relační databáze.

296
00:13:26,386 --> 00:13:27,510
Je optimalizovaný pro skladování.

297
00:13:27,510 --> 00:13:28,280
To je normalizovaná.

298
00:13:28,280 --> 00:13:29,370
Je to relační.

299
00:13:29,370 --> 00:13:31,660
Podporuje dotazy ad hoc.

300
00:13:31,660 --> 00:13:34,000
A to je a to váhy svisle.

301
00:13:34,000 --> 00:13:39,030
>> Pokud je potřeba získat větší SQL databázi
nebo silnější SQL databáze,

302
00:13:39,030 --> 00:13:41,090
Jdu si koupit větší kus železa.

303
00:13:41,090 --> 00:13:41,600
DOBŘE?

304
00:13:41,600 --> 00:13:44,940
Pracoval jsem s mnoha zákazníků
které byly prostřednictvím významné modernizace

305
00:13:44,940 --> 00:13:48,340
pouze v jejich SQL infrastruktury
zjistit, o šest měsíců později,

306
00:13:48,340 --> 00:13:49,750
oni bít do zdi znovu.

307
00:13:49,750 --> 00:13:55,457
A odpověď z Oracle nebo MSSQL
nebo někdo jiný, je dostat větší krabici.

308
00:13:55,457 --> 00:13:58,540
Tak dříve nebo později, nemůžete koupit
větší box, a to je skutečný problém.

309
00:13:58,540 --> 00:14:00,080
Musíme skutečně něco změnit.

310
00:14:00,080 --> 00:14:01,080
Takže tam, kde to funguje?

311
00:14:01,080 --> 00:14:06,560
Funguje to dobře pro offline
analytika, OLAP typu zatížení.

312
00:14:06,560 --> 00:14:08,670
A to je opravdu, kde SQL patří.

313
00:14:08,670 --> 00:14:12,540
Nyní, to je dnes používán v mnoha online
transakční zpracování typu

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

315
00:14:13,330 --> 00:14:16,460
A funguje to v pohodě na
určitá úroveň využití,

316
00:14:16,460 --> 00:14:18,670
ale to prostě není měřítko
tak, že NoSQL dělá.

317
00:14:18,670 --> 00:14:20,660
A budeme mluvit trochu
bit o tom, proč to je.

318
00:14:20,660 --> 00:14:23,590
>> Nyní, NoSQL, na druhé straně,
je více optimalizován pro výpočetně.

319
00:14:23,590 --> 00:14:24,540
DOBŘE?

320
00:14:24,540 --> 00:14:26,830
Není k agnostik
přístup vzor.

321
00:14:26,830 --> 00:14:31,620
Je to, co nazýváme de-normalizoval
struktura nebo hierarchická struktura.

322
00:14:31,620 --> 00:14:35,000
Data v relační databázi
spojeny dohromady z více tabulek

323
00:14:35,000 --> 00:14:36,850
produkovat názor, že potřebujete.

324
00:14:36,850 --> 00:14:40,090
Data v databázi NoSQL
je uložen v dokumentu, který

325
00:14:40,090 --> 00:14:42,100
obsahuje hierarchickou strukturu.

326
00:14:42,100 --> 00:14:45,670
Veškerá data, která by normálně
spojily produkovat tento názor

327
00:14:45,670 --> 00:14:47,160
je uložen v jediném dokumentu.

328
00:14:47,160 --> 00:14:50,990
A budeme mluvit trochu o
jak to funguje v několika grafů.

329
00:14:50,990 --> 00:14:55,320
>> Ale myšlenka je, že budete ukládat
Vaše data jsou tyto konkretizovaná výhledem.

330
00:14:55,320 --> 00:14:56,410
DOBŘE?

331
00:14:56,410 --> 00:14:58,610
Ty vodorovně škálovat.

332
00:14:58,610 --> 00:14:59,556
Právo?

333
00:14:59,556 --> 00:15:02,100
Pokud je potřeba zvýšit
velikost mého clusteru NoSQL,

334
00:15:02,100 --> 00:15:03,700
Nepotřebuji, aby si větší krabici.

335
00:15:03,700 --> 00:15:05,200
Mám další krabici.

336
00:15:05,200 --> 00:15:07,700
A já clusteru ty dohromady,
a já si střep, že data.

337
00:15:07,700 --> 00:15:10,780
Promluvíme si něco o
co sharding je, že

338
00:15:10,780 --> 00:15:14,270
schopny škálovat této databáze
přes více fyzických zařízení

339
00:15:14,270 --> 00:15:18,370
a odstranit bariéru, která
vyžaduje, abych měřítku svisle.

340
00:15:18,370 --> 00:15:22,080
>> Takže je to opravdu postavené pro on-line
zpracování transakcí a měřítko.

341
00:15:22,080 --> 00:15:25,480
Je tu velký rozdíl
tady mezi hlášení, že jo?

342
00:15:25,480 --> 00:15:27,810
Reporting, já neznáte
Otázky Jdu se zeptat.

343
00:15:27,810 --> 00:15:28,310
Právo?

344
00:15:28,310 --> 00:15:30,570
Reporting-- pokud někdo z
můj marketingové oddělení

345
00:15:30,570 --> 00:15:34,520
chce jen--, kolik z mých zákazníků
mít tuto zvláštní vlastnost, která

346
00:15:34,520 --> 00:15:37,850
koupil na této day-- nevím
co dotaz jdou zeptat.

347
00:15:37,850 --> 00:15:39,160
Tak jsem třeba být agnostik.

348
00:15:39,160 --> 00:15:41,810
>> Nyní, v on-line
transakční aplikace,

349
00:15:41,810 --> 00:15:43,820
Vím, jaké otázky se ptám.

350
00:15:43,820 --> 00:15:46,581
Postavil jsem žádost o
velmi specifický workflow.

351
00:15:46,581 --> 00:15:47,080
DOBŘE?

352
00:15:47,080 --> 00:15:50,540
Takže když jsem optimalizovat údaje
ukládat na podporu tohoto pracovního postupu,

353
00:15:50,540 --> 00:15:52,020
že to bude rychlejší.

354
00:15:52,020 --> 00:15:55,190
A to je důvod, proč může NoSQL
Opravdu urychlit dodávku

355
00:15:55,190 --> 00:15:57,710
z těchto typů služeb.

356
00:15:57,710 --> 00:15:58,210
Dobře.

357
00:15:58,210 --> 00:16:00,501
>> Takže jsme se dostat do
trochu teorie zde.

358
00:16:00,501 --> 00:16:03,330
A někteří z vás, vaše oči
může vrátit zpět trochu.

359
00:16:03,330 --> 00:16:06,936
Ale budu se snažit, aby to
jak vysoké úrovni jako já.

360
00:16:06,936 --> 00:16:08,880
Takže pokud jste v projektu
management, je tu

361
00:16:08,880 --> 00:16:12,280
konstrukt nazvaný
trojúhelník omezení.

362
00:16:12,280 --> 00:16:12,936
DOBŘE.

363
00:16:12,936 --> 00:16:16,060
Trojúhelník omezuje diktátu
nemůžete mít všechno čas.

364
00:16:16,060 --> 00:16:17,750
Nemůžete mít svůj koláč a jíst to příliš.

365
00:16:17,750 --> 00:16:22,310
Takže v oblasti projektového řízení, že trojúhelník
omezení je můžete mít levné,

366
00:16:22,310 --> 00:16:24,710
můžete mít to rychle,
nebo můžete mít to dobré.

367
00:16:24,710 --> 00:16:25,716
Vyberte si dva.

368
00:16:25,716 --> 00:16:27,090
Vzhledem k tomu, nemůžete mít všechny tři.

369
00:16:27,090 --> 00:16:27,460
Právo?

370
00:16:27,460 --> 00:16:27,820
DOBŘE.

371
00:16:27,820 --> 00:16:28,920
>> Takže jste slyšel o tom hodně.

372
00:16:28,920 --> 00:16:31,253
Je to trojitý omezení,
trojúhelník trojité omezení,

373
00:16:31,253 --> 00:16:34,420
nebo železo trojúhelník je oftentimes--
Když mluvíte s projektovým manažerům,

374
00:16:34,420 --> 00:16:35,420
oni Promluvíme si o tom.

375
00:16:35,420 --> 00:16:37,640
Nyní, databáze mají
jejich vlastní železo trojúhelník.

376
00:16:37,640 --> 00:16:40,350
A železo trojúhelník údajů
je to, co nazýváme věta CAP.

377
00:16:40,350 --> 00:16:41,580
DOBŘE?

378
00:16:41,580 --> 00:16:43,770
>> CAP teorém diktuje
jak fungují databáze

379
00:16:43,770 --> 00:16:45,627
za velmi specifických podmínek.

380
00:16:45,627 --> 00:16:47,460
A budeme mluvit o tom,
co je tato podmínka.

381
00:16:47,460 --> 00:16:52,221
Ale tři body trojúhelníku,
tak říkajíc, jsou C, konzistence.

382
00:16:52,221 --> 00:16:52,720
DOBŘE?

383
00:16:52,720 --> 00:16:56,760
Takže v CAP, konzistence znamená, že všechny
Klienti, kteří mají přístup k databázi

384
00:16:56,760 --> 00:16:59,084
bude mít vždy velmi
konzistentní pohled na data.

385
00:16:59,084 --> 00:17:00,750
Nikdo se bude vidět dvě různé věci.

386
00:17:00,750 --> 00:17:01,480
DOBŘE?

387
00:17:01,480 --> 00:17:04,020
Když vidím databázi,
Vidím stejný pohled

388
00:17:04,020 --> 00:17:06,130
jako můj partner, který vidí
stejné databáze.

389
00:17:06,130 --> 00:17:07,470
To je konzistence.

390
00:17:07,470 --> 00:17:12,099
>> Dostupnost znamená, že v případě, že
databáze on-line, v případě, že může být dosaženo,

391
00:17:12,099 --> 00:17:14,760
že všichni klienti budou vždy
být schopen číst a psát.

392
00:17:14,760 --> 00:17:15,260
DOBŘE?

393
00:17:15,260 --> 00:17:17,010
Takže každý klient, který
můžete přečíst databáze

394
00:17:17,010 --> 00:17:18,955
budou vždy schopni čtení
Údaje údaje a psát.

395
00:17:18,955 --> 00:17:21,819
A pokud je tomu tak,
je to k dispozici systém.

396
00:17:21,819 --> 00:17:24,230
>> A třetí bod je to, co
nazýváme tolerance oddílu.

397
00:17:24,230 --> 00:17:24,730
DOBŘE?

398
00:17:24,730 --> 00:17:28,160
Tolerance Partition prostředky
že systém funguje dobře

399
00:17:28,160 --> 00:17:32,000
i přes fyzické sítě
příčky mezi uzly.

400
00:17:32,000 --> 00:17:32,760
DOBŘE?

401
00:17:32,760 --> 00:17:36,270
Takže uzly v clusteru nemůže
mluvit k sobě navzájem, co se stane?

402
00:17:36,270 --> 00:17:36,880
Dobře.

403
00:17:36,880 --> 00:17:39,545
>> Takže relační databáze vyberte--
si můžete vybrat dva z nich.

404
00:17:39,545 --> 00:17:40,045
DOBŘE.

405
00:17:40,045 --> 00:17:43,680
Takže relační databáze vyberte
být konzistentní a jsou k dispozici.

406
00:17:43,680 --> 00:17:47,510
Pokud oddíl se děje mezi
že DataNodes v úložišti dat,

407
00:17:47,510 --> 00:17:48,831
databáze havaruje.

408
00:17:48,831 --> 00:17:49,330
Právo?

409
00:17:49,330 --> 00:17:50,900
Je to jen jde dolů.

410
00:17:50,900 --> 00:17:51,450
DOBŘE.

411
00:17:51,450 --> 00:17:54,230
>> A to je důvod, proč mají
růst s většími boxy.

412
00:17:54,230 --> 00:17:54,730
Právo?

413
00:17:54,730 --> 00:17:58,021
Protože tam je no-- obvykle, cluster
Databáze, že to není moc mnoho z nich

414
00:17:58,021 --> 00:17:59,590
že fungují tímto způsobem.

415
00:17:59,590 --> 00:18:03,019
Ale většina databází měřítko
ve svislém směru v rámci jediného pole.

416
00:18:03,019 --> 00:18:05,060
Vzhledem k tomu, že musí být
konzistentní a jsou k dispozici.

417
00:18:05,060 --> 00:18:10,320
Pokud oddíl měl být aplikován,
pak budete muset učinit volbu.

418
00:18:10,320 --> 00:18:13,720
Musíte si vybrat mezi
je v souladu a jsou k dispozici.

419
00:18:13,720 --> 00:18:16,080
>> A to je to, co databáze NoSQL dělat.

420
00:18:16,080 --> 00:18:16,580
Dobře.

421
00:18:16,580 --> 00:18:20,950
Takže databáze NoSQL to,
přichází ve dvou příchutích.

422
00:18:20,950 --> 00:18:22,990
My have-- dobře, to
přichází v mnoha příchutích,

423
00:18:22,990 --> 00:18:26,140
ale přichází se dvěma základními
characteristics-- co

424
00:18:26,140 --> 00:18:30,050
bychom nazvali CP databáze, nebo
konzistentní a oddíl tolerance

425
00:18:30,050 --> 00:18:31,040
systém.

426
00:18:31,040 --> 00:18:34,930
Tihle chlapi zda se rozhodne, že když
uzly ztrátě kontaktu spolu navzájem,

427
00:18:34,930 --> 00:18:37,091
nebudeme dovolit
lidé psát víc.

428
00:18:37,091 --> 00:18:37,590
DOBŘE?

429
00:18:37,590 --> 00:18:41,855
>> Do té doby bude oddíl odstraněn,
Přístup pro zápis je blokován.

430
00:18:41,855 --> 00:18:43,230
To znamená, že to není k dispozici.

431
00:18:43,230 --> 00:18:44,510
Jsou konzistentní.

432
00:18:44,510 --> 00:18:46,554
Když vidíme, že
partition injekci sám,

433
00:18:46,554 --> 00:18:48,470
jsme nyní konzistentní,
protože my nejdeme

434
00:18:48,470 --> 00:18:51,517
aby změnu dat na dva
strany přepážky samostatně

435
00:18:51,517 --> 00:18:52,100
na sobě.

436
00:18:52,100 --> 00:18:54,130
Budeme se muset
obnovit komunikaci

437
00:18:54,130 --> 00:18:56,930
před jakýmkoli aktualizaci
data je povoleno.

438
00:18:56,930 --> 00:18:58,120
DOBŘE?

439
00:18:58,120 --> 00:19:02,650
>> Další varianta by byl systém AP,
nebo k dispozici a rozdělí

440
00:19:02,650 --> 00:19:03,640
tolerance systém.

441
00:19:03,640 --> 00:19:05,320
Tihle kluci to jedno.

442
00:19:05,320 --> 00:19:06,020
Právo?

443
00:19:06,020 --> 00:19:08,960
Jakýkoliv uzel, který dostane
psát, budeme si to.

444
00:19:08,960 --> 00:19:11,480
Takže jsem svou replikaci dat
přes více uzlů.

445
00:19:11,480 --> 00:19:14,730
Tyto uzly se klient, klient přijde
V říká, budu zapisovat některé údaje.

446
00:19:14,730 --> 00:19:16,300
Node říká, žádný problém.

447
00:19:16,300 --> 00:19:18,580
Uzel Vedle něj dostane
Zápis na stejném záznamu,

448
00:19:18,580 --> 00:19:20,405
že to bude říkat žádný problém.

449
00:19:20,405 --> 00:19:23,030
Někde zpátky na konci zadní,
že data to bude replikovat.

450
00:19:23,030 --> 00:19:27,360
A pak někdo to bude realizovat,
uh-oh, ale systém bude realizovat, uh-oh,

451
00:19:27,360 --> 00:19:28,870
Stala se aktualizace dvou stran.

452
00:19:28,870 --> 00:19:30,370
Co děláme?

453
00:19:30,370 --> 00:19:33,210
A to, co dělají, je pak
dělají něco, co

454
00:19:33,210 --> 00:19:36,080
jim umožňuje řešit tento stav dat.

455
00:19:36,080 --> 00:19:39,000
A budeme mluvit o tom,
že v následujícím grafu.

456
00:19:39,000 --> 00:19:40,000
>> Thing poukázat zde.

457
00:19:40,000 --> 00:19:42,374
A já nebudu mít moc
mnohem do toho, protože to

458
00:19:42,374 --> 00:19:43,510
dostane do hluboké teorie dat.

459
00:19:43,510 --> 00:19:46,670
Ale je tu transakční
rámec, který

460
00:19:46,670 --> 00:19:50,680
probíhá v relační systému, který
mi umožňuje bezpečně provádět aktualizace

461
00:19:50,680 --> 00:19:53,760
na více subjektů v databázi.

462
00:19:53,760 --> 00:19:58,320
A tyto aktualizace budou vyskytovat
najednou, nebo vůbec ne.

463
00:19:58,320 --> 00:20:00,500
A to se nazývá ACID transakce.

464
00:20:00,500 --> 00:20:01,000
DOBŘE?

465
00:20:01,000 --> 00:20:06,570
>> ACID nám dává atomicity, konzistence,
izolace, a trvanlivost.

466
00:20:06,570 --> 00:20:07,070
DOBŘE?

467
00:20:07,070 --> 00:20:13,550
To znamená, že atomové, transakce, vše
moje aktualizace buď stát, nebo ne.

468
00:20:13,550 --> 00:20:16,570
Konzistence znamená, že
Databáze bude vždy

469
00:20:16,570 --> 00:20:19,780
být uvedena do konzistentní
stav po aktualizaci.

470
00:20:19,780 --> 00:20:23,900
Já se nikdy opustit databáze v
po použití aktualizace špatný stav.

471
00:20:23,900 --> 00:20:24,400
DOBŘE?

472
00:20:24,400 --> 00:20:26,720
>> Takže je to trochu jinak
než konzistence CAP.

473
00:20:26,720 --> 00:20:29,760
Konzistence CAP znamená, že všechny moje
klienti mohou vždy zobrazit data.

474
00:20:29,760 --> 00:20:34,450
ACID konzistence znamená, že když
transakce se stalo, údaje je dobré.

475
00:20:34,450 --> 00:20:35,709
Mé vztahy jsou dobré.

476
00:20:35,709 --> 00:20:38,750
Nebudu odstranit nadřazený řádek
a zanechat spoustu osiřelých dětí

477
00:20:38,750 --> 00:20:40,970
v jiné tabulce.

478
00:20:40,970 --> 00:20:44,320
To se nemůže stát, jestli jsem v souladu
v kyselém transakce.

479
00:20:44,320 --> 00:20:49,120
>> Izolace znamená, že transakce
dojde vždy po sobě.

480
00:20:49,120 --> 00:20:51,920
Konečný výsledek dat
bude stejný stav

481
00:20:51,920 --> 00:20:54,770
jako kdyby tyto transakce
které byly vydány souběžně

482
00:20:54,770 --> 00:20:57,340
byli popraveni sériově.

483
00:20:57,340 --> 00:21:00,030
Takže je to souběžnost
kontrola v databázi.

484
00:21:00,030 --> 00:21:04,130
Takže v podstatě, nemohu zvýšit
Stejná hodnota dvakrát se dvěma operacemi.

485
00:21:04,130 --> 00:21:08,580
>> Ale když řeknu přidat 1 k této hodnotě,
a dvě transakce přijít

486
00:21:08,580 --> 00:21:10,665
a pokusit se udělat to, něčí
tam dostane jako první

487
00:21:10,665 --> 00:21:12,540
a druhý je
bude se tam dostat po.

488
00:21:12,540 --> 00:21:15,210
Takže nakonec, jsem přidal dva.

489
00:21:15,210 --> 00:21:16,170
Víš, co tím myslím?

490
00:21:16,170 --> 00:21:16,670
DOBŘE.

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

492
00:21:19,220 --> 00:21:21,250
>> Trvanlivost je velice jednoduché.

493
00:21:21,250 --> 00:21:23,460
Když je transakce
Uznává se, že je to

494
00:21:23,460 --> 00:21:26,100
Bude tam i
v případě, že systém se zhroutí.

495
00:21:26,100 --> 00:21:29,230
Když se tento systém využívá, že
Transakce, která byla spáchána

496
00:21:29,230 --> 00:21:30,480
je ve skutečnosti tam bude.

497
00:21:30,480 --> 00:21:33,130
Tak to je záruky
kyseliny transakcí.

498
00:21:33,130 --> 00:21:35,470
To jsou docela pěkné záruky
mít na databázi,

499
00:21:35,470 --> 00:21:36,870
ale přijdou na těchto nákladů.

500
00:21:36,870 --> 00:21:37,640
Právo?

501
00:21:37,640 --> 00:21:40,520
>> Vzhledem k tomu, problém
s tento rámec

502
00:21:40,520 --> 00:21:44,540
v případě, že je oddíl v datech
set, musím učinit rozhodnutí.

503
00:21:44,540 --> 00:21:48,000
Budu muset umožnit
Aktualizace na jedné nebo druhé straně.

504
00:21:48,000 --> 00:21:50,310
A pokud se tak stane,
pak jsem už jít

505
00:21:50,310 --> 00:21:52,630
aby bylo možné zachovat
tyto vlastnosti.

506
00:21:52,630 --> 00:21:53,960
Nebudou konzistentní.

507
00:21:53,960 --> 00:21:55,841
Nebudou být izolovány.

508
00:21:55,841 --> 00:21:58,090
To je místo, kde se rozkládá
pro relační databáze.

509
00:21:58,090 --> 00:22:01,360
To je důvod, relační
databází měřítko vertikálně.

510
00:22:01,360 --> 00:22:05,530
>> Na druhé straně, máme
co se nazývá BASE technologie.

511
00:22:05,530 --> 00:22:07,291
A to jsou vaše NoSQL databáze.

512
00:22:07,291 --> 00:22:07,790
Dobře.

513
00:22:07,790 --> 00:22:10,180
Takže máme CP, databáze AP.

514
00:22:10,180 --> 00:22:14,720
A to jsou v podstatě to, co říkáte
k dispozici, měkký stav, případně

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

516
00:22:15,740 --> 00:22:16,420
DOBŘE?

517
00:22:16,420 --> 00:22:19,690
>> V podstatě k dispozici, protože
jsou to oddíl tolerantní.

518
00:22:19,690 --> 00:22:21,470
Budou vždy
tam, a to i v případě, že je

519
00:22:21,470 --> 00:22:23,053
dělicí síť mezi uzly.

520
00:22:23,053 --> 00:22:25,900
Mohu-li mluvit k uzlu, já jsem
bude schopen číst data.

521
00:22:25,900 --> 00:22:26,460
DOBŘE?

522
00:22:26,460 --> 00:22:30,810
I nemusí být vždy schopen napsat
Údaje, jestli jsem konzistentní platformu.

523
00:22:30,810 --> 00:22:32,130
Ale budu moci číst data.

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

525
00:22:34,960 --> 00:22:38,010
>> Měkká stav označuje
že když jsem si přečetl, že data,

526
00:22:38,010 --> 00:22:40,790
to nemusí být stejné jako ostatních uzlů.

527
00:22:40,790 --> 00:22:43,390
Jestliže právo bylo vydáno v uzlu
někde jinde v clusteru

528
00:22:43,390 --> 00:22:46,650
a nebyla replikována napříč
klastr ale když jsem četl, že údaje,

529
00:22:46,650 --> 00:22:48,680
že stát nemusí být konzistentní.

530
00:22:48,680 --> 00:22:51,650
Nicméně, to bude
nakonec konzistentní,

531
00:22:51,650 --> 00:22:53,870
což znamená, že když je pro zápis
se provádí v systému,

532
00:22:53,870 --> 00:22:56,480
se bude replikovat přes uzly.

533
00:22:56,480 --> 00:22:59,095
A nakonec, že ​​státní
budou uvedena do pořádku,

534
00:22:59,095 --> 00:23:00,890
a to bude konzistentním stavu.

535
00:23:00,890 --> 00:23:05,000
>> Nyní, teorém CAP opravdu
hraje jen v jednom stavu.

536
00:23:05,000 --> 00:23:08,700
Tato podmínka je, když se to stane.

537
00:23:08,700 --> 00:23:13,710
Vzhledem k tomu, kdykoli je to pracovat v
normální režim, neexistuje žádný oddíl,

538
00:23:13,710 --> 00:23:16,370
všechno je konzistentní a jsou k dispozici.

539
00:23:16,370 --> 00:23:19,990
Stačí pouze starat o SZP
když máme tento oddíl.

540
00:23:19,990 --> 00:23:21,260
Takže ty jsou vzácné.

541
00:23:21,260 --> 00:23:25,360
Ale jak systém reaguje, když ti,
dochází diktovat, jaký typ systému

542
00:23:25,360 --> 00:23:26,750
máme co do činění s.

543
00:23:26,750 --> 00:23:31,110
>> Takže pojďme se podívat na to, co
že vypadá jako na AP systémy.

544
00:23:31,110 --> 00:23:32,621
DOBŘE?

545
00:23:32,621 --> 00:23:34,830
Systémy AP přicházejí ve dvou příchutích.

546
00:23:34,830 --> 00:23:38,514
Přicházejí v chuti, která je
master master, 100%, vždy k dispozici.

547
00:23:38,514 --> 00:23:40,430
A přicházejí v
jiná varianta, která říká,

548
00:23:40,430 --> 00:23:43,330
Víš co, já budu dělat starosti
o Toto rozdělení věci

549
00:23:43,330 --> 00:23:44,724
v případě, že skutečná partition dojde.

550
00:23:44,724 --> 00:23:47,890
Jinak to bude primární
uzly, kdo bude mít práva.

551
00:23:47,890 --> 00:23:48,500
DOBŘE?

552
00:23:48,500 --> 00:23:50,040
>> Pokud tedy něco jako Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra by být mistr
master, dovolte mi, abych to zapsat do kteréhokoliv uzlu.

554
00:23:54,440 --> 00:23:55,540
Takže co se stane?

555
00:23:55,540 --> 00:23:58,270
Takže mám objekt v
databáze, která existuje na dvou uzlů.

556
00:23:58,270 --> 00:24:01,705
Říkejme tento objekt S.
Takže máme stát pro S.

557
00:24:01,705 --> 00:24:04,312
Máme některé operace
na S, které probíhají.

558
00:24:04,312 --> 00:24:06,270
Cassandra mi dovoluje
pište na více uzlů.

559
00:24:06,270 --> 00:24:08,550
Takže řekněme, že jsem se dostat
psát pro s dvěma uzly.

560
00:24:08,550 --> 00:24:12,274
No, co skončí děje, je
říkáme, že rozdělovacím události.

561
00:24:12,274 --> 00:24:14,190
Tam nemusí být
oddíl fyzická síť.

562
00:24:14,190 --> 00:24:15,950
Avšak z důvodu konstrukce
systému, to je

563
00:24:15,950 --> 00:24:18,449
ve skutečnosti rozdělení jakmile
jak jsem si psát na dvou uzlů.

564
00:24:18,449 --> 00:24:20,830
Není to mě nutí
napsat celý jeden uzel.

565
00:24:20,830 --> 00:24:22,340
Píšu na dvou uzlů.

566
00:24:22,340 --> 00:24:23,330
DOBŘE?

567
00:24:23,330 --> 00:24:25,740
>> Takže teď mám dva stavy.

568
00:24:25,740 --> 00:24:26,360
DOBŘE?

569
00:24:26,360 --> 00:24:28,110
Co se bude dít
je dříve nebo později,

570
00:24:28,110 --> 00:24:29,960
tam to bude událost replikace.

571
00:24:29,960 --> 00:24:33,300
Tam to bude to, co jsme
volal zotavení oddíl, který

572
00:24:33,300 --> 00:24:35,200
je místo, kde tyto dva
státy vrátit spolu

573
00:24:35,200 --> 00:24:37,310
a tam to bude algoritmus
který běží uvnitř databáze,

574
00:24:37,310 --> 00:24:38,540
se rozhodne, co má dělat.

575
00:24:38,540 --> 00:24:39,110
DOBŘE?

576
00:24:39,110 --> 00:24:43,057
Ve výchozím nastavení, poslední aktualizace
vítězí ve většině systémů AP.

577
00:24:43,057 --> 00:24:44,890
Takže tam je obvykle
výchozí algoritmus, co

578
00:24:44,890 --> 00:24:47,400
říkají zpětné volání
funkce, něco,

579
00:24:47,400 --> 00:24:51,000
bude volána, když tato podmínka
je detekován provádět nějakou logiku

580
00:24:51,000 --> 00:24:52,900
k vyřešení tohoto konfliktu.

581
00:24:52,900 --> 00:24:53,850
DOBŘE?

582
00:24:53,850 --> 00:24:58,770
Výchozí zpětné volání a výchozí
resolver ve většině AP databázích

583
00:24:58,770 --> 00:25:01,130
je, víš co, timestamp vyhrává.

584
00:25:01,130 --> 00:25:02,380
To byla poslední aktualizace.

585
00:25:02,380 --> 00:25:04,320
Chystám se dát tuto aktualizaci tam.

586
00:25:04,320 --> 00:25:08,440
Možná jsem výpis tento záznam, který jsem
dumpingové off do protokolu obnovy

587
00:25:08,440 --> 00:25:11,670
takže uživatel může přijít později
a říct, hej, došlo ke kolizi.

588
00:25:11,670 --> 00:25:12,320
Co se stalo?

589
00:25:12,320 --> 00:25:16,370
A můžete skutečně výpis záznam
všechny kolize a vrácení provedených změn

590
00:25:16,370 --> 00:25:17,550
a uvidíme, co se stane.

591
00:25:17,550 --> 00:25:21,580
>> Nyní, jako uživatel, můžete také
obsahovat logiku do tohoto zpětného volání.

592
00:25:21,580 --> 00:25:24,290
Takže si můžete změnit
zpětné volání operace.

593
00:25:24,290 --> 00:25:26,730
Můžete říct, hej, já chci
k nápravě tohoto data.

594
00:25:26,730 --> 00:25:28,880
A já chci, aby se pokusila
sloučit tyto dva záznamy.

595
00:25:28,880 --> 00:25:30,050
Ale to je jen na vás.

596
00:25:30,050 --> 00:25:32,880
Databáze neví, jak se
tomu, že ve výchozím nastavení. Nejvíce času,

597
00:25:32,880 --> 00:25:34,850
jediné, co je databáze
Ví, jak udělat, je říci,

598
00:25:34,850 --> 00:25:36,100
tenhle byl poslední záznam.

599
00:25:36,100 --> 00:25:39,183
To je ten, který vyhraje,
a to je hodnota jdu dát.

600
00:25:39,183 --> 00:25:41,490
Jakmile to oddíl zotavení
a dojde k replikaci,

601
00:25:41,490 --> 00:25:43,930
máme stát, který
Nyní je S prvočíslo, což je

602
00:25:43,930 --> 00:25:46,890
sloučení stav všech těchto objektů.

603
00:25:46,890 --> 00:25:49,700
Takže systémy AP tohle.

604
00:25:49,700 --> 00:25:51,615
CP systémy nepotřebují
se starat o to.

605
00:25:51,615 --> 00:25:54,490
Vzhledem k tomu, jakmile oddíl přichází
do hry, prostě přestat užívat

606
00:25:54,490 --> 00:25:55,530
píše.

607
00:25:55,530 --> 00:25:56,180
DOBŘE?

608
00:25:56,180 --> 00:25:58,670
Takže je to velmi snadné
vypořádat s tím, že v souladu

609
00:25:58,670 --> 00:26:01,330
pokud nechcete přijímat žádné aktualizace.

610
00:26:01,330 --> 00:26:04,620
To je s CP systémy dělají.

611
00:26:04,620 --> 00:26:05,120
Dobře.

612
00:26:05,120 --> 00:26:07,590
>> Takže pojďme mluvit trochu
něco o přístupových vzory.

613
00:26:07,590 --> 00:26:11,580
Když mluvíme o NoSQL, je to
vše o vzorek přístup.

614
00:26:11,580 --> 00:26:13,550
Nyní, SQL je ad hoc dotazy.

615
00:26:13,550 --> 00:26:14,481
Je to relační obchod.

616
00:26:14,481 --> 00:26:16,480
Nemusíme se bát
o vzorek přístup.

617
00:26:16,480 --> 00:26:17,688
Píšu velmi složitý dotaz.

618
00:26:17,688 --> 00:26:19,250
Jde to a získává data.

619
00:26:19,250 --> 00:26:21,210
To je to, co to vypadá
jako, normalizace.

620
00:26:21,210 --> 00:26:24,890
>> Takže v tomto konkrétní strukturu,
díváme na katalog produktů.

621
00:26:24,890 --> 00:26:26,640
Mám různé druhy výrobků.

622
00:26:26,640 --> 00:26:27,217
Mám knihy.

623
00:26:27,217 --> 00:26:27,800
Mám alba.

624
00:26:27,800 --> 00:26:30,090
Mám videa.

625
00:26:30,090 --> 00:26:33,370
Vztah mezi výrobky
a některý z těchto knih, alb,

626
00:26:33,370 --> 00:26:34,860
a videa tabulek je 1: 1.

627
00:26:34,860 --> 00:26:35,800
Dobře?

628
00:26:35,800 --> 00:26:38,860
Mám ID produktu,
a že ID odpovídá

629
00:26:38,860 --> 00:26:41,080
na knihu, album, nebo video.

630
00:26:41,080 --> 00:26:41,580
DOBŘE?

631
00:26:41,580 --> 00:26:44,350
To je vztah 1: 1
po těchto tabulkách.

632
00:26:44,350 --> 00:26:46,970
>> Teď, books-- všechno, co
mají vlastnosti je root.

633
00:26:46,970 --> 00:26:47,550
Žádný problém.

634
00:26:47,550 --> 00:26:48,230
To je skvělé.

635
00:26:48,230 --> 00:26:52,130
One-to-one vztah, jsem si všechny
údaje musím popsat tu knihu.

636
00:26:52,130 --> 00:26:54,770
Albums-- alba mají stopy.

637
00:26:54,770 --> 00:26:56,470
To je to, co nazýváme jeden k mnoho.

638
00:26:56,470 --> 00:26:58,905
Každé album může mít mnoho stop.

639
00:26:58,905 --> 00:27:00,780
Takže pro každé dráze na
album, mohl bych mít

640
00:27:00,780 --> 00:27:02,570
další rekord v tomto podřízené tabulce.

641
00:27:02,570 --> 00:27:04,680
Tak jsem vytvořit jeden záznam
v mém alba tabulce.

642
00:27:04,680 --> 00:27:06,700
Vytvořit více záznamů
v tabulce stop.

643
00:27:06,700 --> 00:27:08,850
One-to-many vztah.

644
00:27:08,850 --> 00:27:11,220
>> Tento vztah je to, co
nazýváme many-to-many.

645
00:27:11,220 --> 00:27:11,750
DOBŘE?

646
00:27:11,750 --> 00:27:17,000
Vidíte, že herci by mohla být
v mnoha filmech, mnoho videí.

647
00:27:17,000 --> 00:27:21,450
Takže to, co děláme, je, že jsme dát toto mapování
tabulku mezi těmi, které se právě

648
00:27:21,450 --> 00:27:24,040
mapuje herce ID do ID videa.

649
00:27:24,040 --> 00:27:28,464
Nyní mohu vytvořit dotaz spoje
videa přes herec videa do herců,

650
00:27:28,464 --> 00:27:31,130
a to mi dává pěkný seznam
všechny filmy a všichni herci

651
00:27:31,130 --> 00:27:32,420
kteří byli v tom filmu.

652
00:27:32,420 --> 00:27:33,290
>> DOBŘE.

653
00:27:33,290 --> 00:27:33,880
Tak jdeme na to.

654
00:27:33,880 --> 00:27:38,040
One-to-one je nejvyšší úrovně
vztah; one-to-many,

655
00:27:38,040 --> 00:27:40,240
alba skladeb; many-to-many.

656
00:27:40,240 --> 00:27:44,990
To jsou tři nejvyšší úrovně
vztahy v žádné databázi.

657
00:27:44,990 --> 00:27:48,050
Pokud víte, jak ti,
vztahy pracovat společně,

658
00:27:48,050 --> 00:27:51,490
pak víte hodně
o již databáze.

659
00:27:51,490 --> 00:27:55,660
Takže NoSQL trochu funguje jinak.

660
00:27:55,660 --> 00:27:58,930
Pojďme se zamyslet nad za druhé to, co to
Vypadá to, jít pro všechny své produkty.

661
00:27:58,930 --> 00:28:01,096
>> V relační obchodě, já
se chtějí dostat všechny své produkty

662
00:28:01,096 --> 00:28:02,970
na seznamu všech mých výrobků.

663
00:28:02,970 --> 00:28:04,910
To je hodně dotazů.

664
00:28:04,910 --> 00:28:07,030
Mám dotaz pro všechny moje knihy.

665
00:28:07,030 --> 00:28:08,470
Mám dotaz od svých alb.

666
00:28:08,470 --> 00:28:09,970
A já mám dotaz pro všechny mých videí.

667
00:28:09,970 --> 00:28:11,719
A já musím dát
vše dohromady v seznamu

668
00:28:11,719 --> 00:28:15,250
a slouží to zpět až do výše
aplikace, která je o to požádá.

669
00:28:15,250 --> 00:28:18,000
>> Chcete-li získat své knihy, jsem se připojit
Produkty a knihy.

670
00:28:18,000 --> 00:28:21,680
Chcete-li získat moje alba, jsem se připojit
Produkty, alba a skladby.

671
00:28:21,680 --> 00:28:25,330
A aby se moje videa, mám
připojit produktů na videa,

672
00:28:25,330 --> 00:28:28,890
připojit přes herců videa,
a přinést herců.

673
00:28:28,890 --> 00:28:31,020
Tak to je tři dotazy.

674
00:28:31,020 --> 00:28:34,560
Velmi složité dotazy na
shromáždit jednu sadu výsledků.

675
00:28:34,560 --> 00:28:36,540
>> To je méně než optimální.

676
00:28:36,540 --> 00:28:39,200
To je důvod, proč, když mluvíme
o datové struktury, která je

677
00:28:39,200 --> 00:28:42,900
postavena tak, aby agnostik s přístupem
pattern-- dobře, že je to skvělé.

678
00:28:42,900 --> 00:28:45,730
A vidíte, je to opravdu
pěkné, jak jsme organizovali data.

679
00:28:45,730 --> 00:28:46,550
A víte co?

680
00:28:46,550 --> 00:28:49,750
Mám jen jeden záznam pro herce.

681
00:28:49,750 --> 00:28:50,440
>> To je v pohodě.

682
00:28:50,440 --> 00:28:53,750
Já jsem deduplikovány všechny své herce,
a já udržovány své sdružení

683
00:28:53,750 --> 00:28:55,200
V této tabulce mapování.

684
00:28:55,200 --> 00:29:00,620
Nicméně, jak se data
out se stává dražší.

685
00:29:00,620 --> 00:29:04,500
Posílám CPU celého systému
spojující tyto datové struktury spolu

686
00:29:04,500 --> 00:29:05,950
aby bylo možné vytáhnout, že data zpět.

687
00:29:05,950 --> 00:29:07,310
>> Tak jak to mám dostat kolem, že?

688
00:29:07,310 --> 00:29:11,200
V NoSQL je to o
agregace, ne normalizace.

689
00:29:11,200 --> 00:29:13,534
Takže chceme říci chceme
podporovat přístup vzor.

690
00:29:13,534 --> 00:29:15,283
Pokud vzorek přístup
k aplikacím,

691
00:29:15,283 --> 00:29:16,770
Musím se dostat všechny své výrobky.

692
00:29:16,770 --> 00:29:19,027
Pojďme dát všechny produkty v jedné tabulce.

693
00:29:19,027 --> 00:29:22,110
Když jsem dal všechny produkty v jedné tabulce,
Já si jen vybrat všechny produkty

694
00:29:22,110 --> 00:29:23,850
Z této tabulky, a já si to všechno.

695
00:29:23,850 --> 00:29:25,240
Tak jak to mám udělat, že?

696
00:29:25,240 --> 00:29:28,124
No v NoSQL není
struktura ke stolu.

697
00:29:28,124 --> 00:29:30,540
Budeme mluvit trochu o
Jak to funguje Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Ale nemusíte mít stejný
atributy a stejné vlastnosti

699
00:29:33,570 --> 00:29:37,751
v každé řadě, v každém jednotlivém
položky, jako vy v tabulce SQL.

700
00:29:37,751 --> 00:29:39,750
A co mi to dovoluje
udělat, je spousta věcí

701
00:29:39,750 --> 00:29:41,124
a dal mi velkou flexibilitu.

702
00:29:41,124 --> 00:29:45,360
V tomto konkrétním případě, I
mají svůj produkt doklady.

703
00:29:45,360 --> 00:29:49,090
A v tomto konkrétním
příklad, všechno

704
00:29:49,090 --> 00:29:51,930
je dokument, v tabulce Výrobky.

705
00:29:51,930 --> 00:29:56,510
A produkt pro knihu by mohl
mají ID typu, který určuje knihu.

706
00:29:56,510 --> 00:29:59,180
A aplikace
by se mělo přepnout na tomto ID.

707
00:29:59,180 --> 00:30:02,570
>> V aplikační vrstvě, jdu
říkat ach, jaký typ záznamu je to?

708
00:30:02,570 --> 00:30:04,100
Oh, to je kniha rekord.

709
00:30:04,100 --> 00:30:05,990
Book záznamy mají tyto vlastnosti.

710
00:30:05,990 --> 00:30:08,100
Dovolte mi, abych vytvořit knihu objekt.

711
00:30:08,100 --> 00:30:11,289
Takže já jdu pro naplnění
kniha objekt s touto položkou.

712
00:30:11,289 --> 00:30:13,080
Další položka přijde a
říká, co je tato položka?

713
00:30:13,080 --> 00:30:14,560
No tato položka je album.

714
00:30:14,560 --> 00:30:17,340
Oh, mám úplně jiná
rutina pro zpracování, které,

715
00:30:17,340 --> 00:30:18,487
protože je to album.

716
00:30:18,487 --> 00:30:19,320
Víš, co tím myslím?

717
00:30:19,320 --> 00:30:21,950
>> Takže aplikace tier-- I
stačí vybrat všechny tyto záznamy.

718
00:30:21,950 --> 00:30:23,200
Všichni začnou přicházet dovnitř.

719
00:30:23,200 --> 00:30:24,680
Mohly by být veškeré typy.

720
00:30:24,680 --> 00:30:27,590
A je to logika aplikace
který přepíná napříč těchto typů

721
00:30:27,590 --> 00:30:29,530
a rozhodne, jak je zpracovat.

722
00:30:29,530 --> 00:30:33,640
>> Opět, takže jsme optimalizaci
schéma vzorek přístup.

723
00:30:33,640 --> 00:30:36,390
Děláme to tím,
hroutí ty tabulky.

724
00:30:36,390 --> 00:30:39,670
Jsme v podstatě převzetí
Tyto normalizované struktury,

725
00:30:39,670 --> 00:30:42,000
a stavíme
hierarchické struktury.

726
00:30:42,000 --> 00:30:45,130
Uvnitř každé z těchto záznamů
Jdu vidět vlastnosti pole.

727
00:30:45,130 --> 00:30:49,400
>> Uvnitř tohoto dokumentu pro alba,
Vidím matice stop.

728
00:30:49,400 --> 00:30:53,900
Tyto stopy teď become-- je to
v podstatě toto dítě tabulka

729
00:30:53,900 --> 00:30:56,520
existuje přímo zde v této struktuře.

730
00:30:56,520 --> 00:30:57,975
Takže můžete to provést v DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Můžete to udělat v MongoDB.

732
00:30:59,810 --> 00:31:01,437
Můžete to udělat v jakékoliv databázi NoSQL.

733
00:31:01,437 --> 00:31:03,520
Vytvořte tyto typy
hierarchické datové struktury

734
00:31:03,520 --> 00:31:07,120
které umožňují načtení dat
velmi rychle, protože teď

735
00:31:07,120 --> 00:31:08,537
Nemusíte odpovídat.

736
00:31:08,537 --> 00:31:11,620
Když jsem se vložit řádek do kolejích
stůl, nebo o řádek do tabulky Alba

737
00:31:11,620 --> 00:31:13,110
Musím odpovídat tomuto schématu.

738
00:31:13,110 --> 00:31:18,060
Musím mít atribut nebo
majetek, který je definován na této tabulce.

739
00:31:18,060 --> 00:31:20,480
Každý z nich,
když jsem vložte tento řádek.

740
00:31:20,480 --> 00:31:21,910
To není případ v NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Můžu mít zcela odlišné
vlastnosti v každém dokumentu

742
00:31:24,440 --> 00:31:26,100
že jsem se vložit do sbírky.

743
00:31:26,100 --> 00:31:30,480
Takže velmi silný mechanismus.

744
00:31:30,480 --> 00:31:32,852
A je to opravdu, jak vás
optimalizaci systému.

745
00:31:32,852 --> 00:31:35,310
Vzhledem k tomu, teď, že dotaz, namísto
spojování všechny tyto tabulky

746
00:31:35,310 --> 00:31:39,160
a provádění půl tuctu dotazy
vytáhnout zpět data, co potřebuji,

747
00:31:39,160 --> 00:31:40,890
Jsem vykonávající jeden dotaz.

748
00:31:40,890 --> 00:31:43,010
A já jsem iterace
přes výsledky uvedené.

749
00:31:43,010 --> 00:31:46,512
to vám dává představu
o síle NoSQL.

750
00:31:46,512 --> 00:31:49,470
Chystám se jít trochu bokem zde
a mluvit trochu o tom.

751
00:31:49,470 --> 00:31:53,240
To je více druhů
marketing nebo technology--

752
00:31:53,240 --> 00:31:55,660
marketing technologie
typ diskuse.

753
00:31:55,660 --> 00:31:58,672
Ale je důležité pochopit,
protože když se podíváme na vrcholu

754
00:31:58,672 --> 00:32:00,380
zde na tento graf,
co se díváme

755
00:32:00,380 --> 00:32:04,030
je to, co nazýváme
Technologie humbuk křivka.

756
00:32:04,030 --> 00:32:06,121
A co to znamená,
nové věci přichází do hry.

757
00:32:06,121 --> 00:32:07,120
Lidé si myslí, že je to skvělé.

758
00:32:07,120 --> 00:32:09,200
Já jsem vyřešil všechny mé problémy.

759
00:32:09,200 --> 00:32:11,630
>> To by mohlo být konec
všichni, být vše, na všechno.

760
00:32:11,630 --> 00:32:12,790
A začnou používat.

761
00:32:12,790 --> 00:32:14,720
A oni říkají, tohle nefunguje.

762
00:32:14,720 --> 00:32:17,600
To není správné.

763
00:32:17,600 --> 00:32:19,105
Staré věci byly lepší.

764
00:32:19,105 --> 00:32:21,230
A oni se vrátit k dělání
věci tak, jak byly.

765
00:32:21,230 --> 00:32:22,730
A pak nakonec
jdou, víš co?

766
00:32:22,730 --> 00:32:24,040
Tohle není tak špatné.

767
00:32:24,040 --> 00:32:26,192
Ach, to je, jak to funguje.

768
00:32:26,192 --> 00:32:28,900
A jakmile se zjistit, jak to
práce, začnou stále lepší.

769
00:32:28,900 --> 00:32:32,050
>> A legrační věc, o tom
Je to trochu linek až na to, co

770
00:32:32,050 --> 00:32:34,300
nazýváme Technology osvojení dítěte křivky.

771
00:32:34,300 --> 00:32:36,910
Takže co se stane, je, že jsme se
nějaká technologie spoušť.

772
00:32:36,910 --> 00:32:39,100
V případě databází,
to je tlak dat.

773
00:32:39,100 --> 00:32:42,200
Mluvili jsme o vysokých vodních bodů
tlaku dat po celou dobu.

774
00:32:42,200 --> 00:32:46,310
Když tato data tlak zasáhne určité
bod, to je technologie spoušť.

775
00:32:46,310 --> 00:32:47,830
>> Začíná to příliš drahé.

776
00:32:47,830 --> 00:32:49,790
To trvá příliš dlouho, aby zpracování dat.

777
00:32:49,790 --> 00:32:50,890
Potřebujeme něco lepšího.

778
00:32:50,890 --> 00:32:52,890
Získáte inovátorů
tam venku pobíhají,

779
00:32:52,890 --> 00:32:55,050
snaží zjistit, jaké je řešení.

780
00:32:55,050 --> 00:32:56,050
Co je to nová myšlenka?

781
00:32:56,050 --> 00:32:58,170
>> Jaký je další nejlepší
způsob, jak tuto věc?

782
00:32:58,170 --> 00:32:59,530
A oni přijdou s něčím.

783
00:32:59,530 --> 00:33:03,140
A lidé s skutečnou bolest,
kluci na drsně,

784
00:33:03,140 --> 00:33:06,390
budou skákat přes to všechno,
protože potřebují odpověď.

785
00:33:06,390 --> 00:33:09,690
A teď, co nevyhnutelně happens-- a
to se právě teď děje v NoSQL.

786
00:33:09,690 --> 00:33:11,090
Vidím to po celou dobu.

787
00:33:11,090 --> 00:33:13,610
>> Co se nevyhnutelně stane, je
lidé začnou používat nový nástroj

788
00:33:13,610 --> 00:33:15,490
stejný způsob, jakým používá staré nástroje.

789
00:33:15,490 --> 00:33:17,854
A oni zjistili to
nefunguje tak dobře.

790
00:33:17,854 --> 00:33:20,020
Nemohu si vzpomenout, kdo jsem
mluvit dneska.

791
00:33:20,020 --> 00:33:22,080
Ale je to jako, když se
sbíječka byl vynalezen,

792
00:33:22,080 --> 00:33:24,621
lidé neměli houpačka ji
jejich hlava rozbít beton.

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

794
00:33:27,360 --> 00:33:30,610
>> Ale to je to, co je
děje NoSQL dnes.

795
00:33:30,610 --> 00:33:33,900
Půjdete-li ve většině obchodů,
se snaží být NoSQL obchodů.

796
00:33:33,900 --> 00:33:36,510
To, co děláte, je
Používají NoSQL,

797
00:33:36,510 --> 00:33:39,900
a oni ho načítání
plná relačního schématu.

798
00:33:39,900 --> 00:33:41,630
Vzhledem k tomu, že to, jak
navrhují databází.

799
00:33:41,630 --> 00:33:44,046
A oni jsou zvědaví, proč je
to nefunguje dobře?

800
00:33:44,046 --> 00:33:45,230
Páni, tahle věc smrdí.

801
00:33:45,230 --> 00:33:49,900
Musel jsem se udržet všechny mé
připojí in-- je to jako, ne, ne.

802
00:33:49,900 --> 00:33:50,800
Udržovat se připojí?

803
00:33:50,800 --> 00:33:52,430
Proč se připojí data?

804
00:33:52,430 --> 00:33:54,350
Nemusíte připojit data v NoSQL.

805
00:33:54,350 --> 00:33:55,850
Agregovat to.

806
00:33:55,850 --> 00:34:00,690
>> Takže pokud chcete, aby se tomu zabránilo, učit se
jak nástroj funguje před vámi vlastně

807
00:34:00,690 --> 00:34:02,010
začít používat.

808
00:34:02,010 --> 00:34:04,860
Nesnažte se používat nové nástroje pro
Stejným způsobem jste použili staré nástroje.

809
00:34:04,860 --> 00:34:06,500
Budeš mít špatnou zkušenost.

810
00:34:06,500 --> 00:34:08,848
A pokaždé
to je to, o co jde.

811
00:34:08,848 --> 00:34:11,389
Když jsme se začnou přicházet sem,
je to proto, že lidé zjistili,

812
00:34:11,389 --> 00:34:13,449
jak používat nástroje.

813
00:34:13,449 --> 00:34:16,250
>> Udělali stejnou věc, když
relační databáze byly vynalezeny,

814
00:34:16,250 --> 00:34:17,969
a oni byli nahrazení souborové systémy.

815
00:34:17,969 --> 00:34:20,420
Snažili se vybudovat souborové systémy
s relačních databází

816
00:34:20,420 --> 00:34:22,159
protože to je to, co lidé pochopili.

817
00:34:22,159 --> 00:34:23,049
Nefungovalo to.

818
00:34:23,049 --> 00:34:26,090
Takže pochopení osvědčených postupů
technologie pracujete s

819
00:34:26,090 --> 00:34:26,730
je obrovský.

820
00:34:26,730 --> 00:34:29,870
Velmi důležité.

821
00:34:29,870 --> 00:34:32,440
>> Takže jsme se dostat do DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB je AWS je
Plně řízené NoSQL platformy.

823
00:34:36,480 --> 00:34:37,719
Co znamená plně řízené znamená?

824
00:34:37,719 --> 00:34:40,010
To znamená, že nemusíte
opravdu o nic starat.

825
00:34:40,010 --> 00:34:42,060
>> Můžete přijít, řeknete
us, potřebuji tabulku.

826
00:34:42,060 --> 00:34:43,409
Je třeba tolik kapacity.

827
00:34:43,409 --> 00:34:47,300
Stisknete tlačítko, a my ustanovení
veškerá infrastruktura za scény.

828
00:34:47,300 --> 00:34:48,310
Teď, když je obrovský.

829
00:34:48,310 --> 00:34:51,310
>> Vzhledem k tomu, když mluvíte
škálování o databáze,

830
00:34:51,310 --> 00:34:53,917
NoSQL datové klastry na
stupnice, provozní petabajtů,

831
00:34:53,917 --> 00:34:55,750
běží miliony
transakcí za sekundu,

832
00:34:55,750 --> 00:34:58,180
tyto věci nejsou malé shluky.

833
00:34:58,180 --> 00:35:00,830
Mluvíme tisíce instancí.

834
00:35:00,830 --> 00:35:04,480
Správa tisíce případů,
dokonce i virtuální instance,

835
00:35:04,480 --> 00:35:06,350
je skutečnou bolest v zadku.

836
00:35:06,350 --> 00:35:09,110
Mám na mysli, přemýšlet o tom, pokaždé, když
Systém náplast provozní vyjde

837
00:35:09,110 --> 00:35:11,552
nebo novou verzi databáze.

838
00:35:11,552 --> 00:35:13,260
Co to znamená
vám provozně?

839
00:35:13,260 --> 00:35:16,330
To znamená, že máš 1200
servery, které je třeba aktualizovat.

840
00:35:16,330 --> 00:35:18,960
Nyní ještě s automatizací,
který může trvat dlouhou dobu.

841
00:35:18,960 --> 00:35:21,480
To může způsobit hodně
provozní bolesti hlavy,

842
00:35:21,480 --> 00:35:23,090
proto, že jsem mohl mít služby dolů.

843
00:35:23,090 --> 00:35:26,070
>> Když jsem aktualizovat tyto databáze, já
mohli dělat modrá zelená nasazení

844
00:35:26,070 --> 00:35:29,420
kde jsem nasadit a upgrade polovina mé
uzly, a potom inovovat druhou polovinu.

845
00:35:29,420 --> 00:35:30,490
Vezměte ty dole.

846
00:35:30,490 --> 00:35:33,410
Takže řízení infrastruktury
Měřítko je nesmírně bolestivé.

847
00:35:33,410 --> 00:35:36,210
A AWS přijmout, že bolest z ní.

848
00:35:36,210 --> 00:35:39,210
A databáze NoSQL může
být mimořádně bolestivá

849
00:35:39,210 --> 00:35:41,780
vzhledem ke způsobu jejich měřítko.

850
00:35:41,780 --> 00:35:42,926
>> Měřítko vodorovně.

851
00:35:42,926 --> 00:35:45,550
Chcete-li mít větší NoSQL
databáze, kupujete více uzlů.

852
00:35:45,550 --> 00:35:48,660
Každý uzel si koupíte, je
další operační bolest hlavy.

853
00:35:48,660 --> 00:35:50,830
Tak ať někdo jiný udělá za vás.

854
00:35:50,830 --> 00:35:52,000
AWS může udělat.

855
00:35:52,000 --> 00:35:54,587
>> Podporujeme hodnoty klíčového dokumentu.

856
00:35:54,587 --> 00:35:56,670
Teď jsme nešli moc
do na straně grafu.

857
00:35:56,670 --> 00:35:58,750
Je tu mnoho různých
chutí NoSQL.

858
00:35:58,750 --> 00:36:02,670
Jsou to všechny druhy získávání
munged společně v tomto bodě.

859
00:36:02,670 --> 00:36:06,260
Můžete se podívat na DynamoDB a říct ano,
oba jsme dokument a klíčovou hodnotou

860
00:36:06,260 --> 00:36:08,412
uložit tento bod.

861
00:36:08,412 --> 00:36:10,620
A můžete argumentovat funkce
jednoho nad druhým.

862
00:36:10,620 --> 00:36:13,950
Pro mě, hodně je to opravdu six
jedné půl tuctu druhého.

863
00:36:13,950 --> 00:36:18,710
Každý z těchto technologií je
jemné technologie a kvalitní řešení.

864
00:36:18,710 --> 00:36:23,390
Neřekl bych, že je lepší nebo MongoDB
horší než Couch, pak Cassandra,

865
00:36:23,390 --> 00:36:25,994
pak Dynamo, nebo naopak.

866
00:36:25,994 --> 00:36:27,285
Chci říct, že to jsou jen možnosti.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Je to rychlé a je to
konzistentní v jakémkoli měřítku.

869
00:36:32,700 --> 00:36:36,210
Takže to je jedna z největších
bonusy získáte s AWS.

870
00:36:36,210 --> 00:36:40,850
S DynamoDB je schopnost
získat nízké jednu číslici

871
00:36:40,850 --> 00:36:44,040
milisekunda zpoždění v jakémkoli měřítku.

872
00:36:44,040 --> 00:36:45,720
To byl cíl designu systému.

873
00:36:45,720 --> 00:36:49,130
A máme zákazníky, které dělají
miliony transakcí za sekundu.

874
00:36:49,130 --> 00:36:52,670
>> Teď budu jít přes některé z těch,
případů použití za několik minut zde.

875
00:36:52,670 --> 00:36:55,660
Integrovaný přístup control--
máme to, co nazýváme

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, nebo IAM.

877
00:36:57,920 --> 00:37:01,980
To prostupuje všechny systémy,
každá služba, která nabízí AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB není výjimkou.

879
00:37:03,630 --> 00:37:06,020
Můžete řídit přístup
k DynamoDB tabulek.

880
00:37:06,020 --> 00:37:09,960
Přes všechny vaše AWS účtů
definování přístupových rolí a oprávnění

881
00:37:09,960 --> 00:37:12,140
v IAM infrastruktury.

882
00:37:12,140 --> 00:37:16,630
>> A to je klíč a nedílnou složkou
to, co nazýváme událostmi řízené programování.

883
00:37:16,630 --> 00:37:19,056
Nyní se jedná o nové paradigma.

884
00:37:19,056 --> 00:37:22,080
>> Diváků: Jak je na tom vaše rychlost true
pozitiva oproti falešně negativních

885
00:37:22,080 --> 00:37:24,052
ve vašem systému řízení přístupu?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: Pravda pozitivy
proti falešně negativní?

887
00:37:26,260 --> 00:37:28,785
Publikum: Vrácení co
měli byste se vrací?

888
00:37:28,785 --> 00:37:33,720
Na rozdíl od jednou za čas to
nevrací, kdy by měl ověřit?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: Nemohla jsem ti to říct.

891
00:37:38,050 --> 00:37:40,140
Pokud existuje nějaké poruchy
vůbec na to,

892
00:37:40,140 --> 00:37:42,726
Nejsem člověk se zeptat
že zvláštní otázka.

893
00:37:42,726 --> 00:37:43,850
Ale to je dobrá otázka.

894
00:37:43,850 --> 00:37:45,905
Byl bych zvědavý
že sám, ve skutečnosti.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> A tak opět, nové paradigma
je událostmi řízené programování.

897
00:37:51,320 --> 00:37:55,160
To je myšlenka, že můžete
nasadit komplexní aplikace, které

898
00:37:55,160 --> 00:37:59,720
může pracovat velmi, velmi vysoká měřítka
bez jakékoliv infrastruktury vůbec.

899
00:37:59,720 --> 00:38:02,120
Bez stanovených
infrastrukturu vůbec.

900
00:38:02,120 --> 00:38:04,720
A budeme mluvit trochu
o tom, co to znamená, že jako my

901
00:38:04,720 --> 00:38:06,550
dostat se na další pár grafů.

902
00:38:06,550 --> 00:38:08,716
>> První věc, kterou uděláme
je budeme mluvit o tabulkách.

903
00:38:08,716 --> 00:38:10,857
Datové typy API pro Dynamo.

904
00:38:10,857 --> 00:38:13,190
A první věc, kterou budete
Všimněte si, když se podíváte na to,

905
00:38:13,190 --> 00:38:17,930
pokud jste obeznámeni s libovolnou databází,
databáze mají opravdu dva druhy API

906
00:38:17,930 --> 00:38:18,430
Já bych to říkat.

907
00:38:18,430 --> 00:38:21,570
Nebo dvě sady API.

908
00:38:21,570 --> 00:38:23,840
Jednou z nich by byl
administrativní API.

909
00:38:23,840 --> 00:38:26,710
>> Věci, které se starají o
Funkce databáze.

910
00:38:26,710 --> 00:38:31,340
Konfigurace engine pro ukládání,
zřizování a přidávání tabulek.

911
00:38:31,340 --> 00:38:35,180
vytvoření databáze
katalogy a instance.

912
00:38:35,180 --> 00:38:40,450
Ty things-- v DynamoDB, budete
mají velmi krátký, krátký seznamy.

913
00:38:40,450 --> 00:38:43,120
>> Takže v jiných databázích,
můžete vidět desítky

914
00:38:43,120 --> 00:38:45,680
příkazů, správních
příkazy, pro konfiguraci

915
00:38:45,680 --> 00:38:47,290
tyto další možnosti.

916
00:38:47,290 --> 00:38:51,234
V DynamoDB nepotřebujete, protože ti,
nenakonfigurujete systém, co děláme.

917
00:38:51,234 --> 00:38:54,150
Takže jediná věc, kterou musíte udělat, je
řekni mi, co velikost tabulky potřebuji.

918
00:38:54,150 --> 00:38:55,660
Tak dostanete velmi
omezený soubor příkazů.

919
00:38:55,660 --> 00:38:58,618
>> Získáte CREATE TABLE aktualizace, tabulka,
Odstranit tabulku a označení stolních.

920
00:38:58,618 --> 00:39:01,150
To jsou jediné věci,
co potřebujete pro DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Nemusíte úložiště
konfigurace motoru.

922
00:39:03,294 --> 00:39:04,960
Nepotřebuju se starat o replikaci.

923
00:39:04,960 --> 00:39:06,490
Nepotřebuju se starat o sharding.

924
00:39:06,490 --> 00:39:07,800
>> Nepotřebuji se obávat
o některý z těchto věcí.

925
00:39:07,800 --> 00:39:08,740
Děláme to vše za vás.

926
00:39:08,740 --> 00:39:11,867
Tak to je obrovské množství režie
to je jen zvedne talíř.

927
00:39:11,867 --> 00:39:13,200
Pak máme operátory CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD je něco, co jsme
volat v databázi, která je

929
00:39:17,740 --> 00:39:19,860
Vytvořit, aktualizovat, mazat operátorů.

930
00:39:19,860 --> 00:39:24,180
To jsou vaše běžné
databázové operace.

931
00:39:24,180 --> 00:39:31,299
Věci jako put položku, dostat položku, aktualizace
položky, mazat položky, šarže dotaz, skenovat.

932
00:39:31,299 --> 00:39:32,840
Chcete-li skenovat celou tabulku.

933
00:39:32,840 --> 00:39:34,220
Vytáhněte všechno ze stolu.

934
00:39:34,220 --> 00:39:37,130
Jedna z pěkné věci o DynamoDB
Je to umožňuje paralelní skenování.

935
00:39:37,130 --> 00:39:40,602
Takže můžete ve skutečnosti, dejte mi vědět, kolik
nitě chcete spustit na tom skenu.

936
00:39:40,602 --> 00:39:41,810
A můžeme spustit tyto závity.

937
00:39:41,810 --> 00:39:43,985
Můžeme točit, že skenovat nahoru
napříč více vláken

938
00:39:43,985 --> 00:39:49,060
takže můžete skenovat celou tabulku
space velmi, velmi rychle DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Další API máme, je
to, co nazýváme Streams API.

940
00:39:51,490 --> 00:39:52,940
Nebudeme mluvit příliš
hodně o tom právě teď.

941
00:39:52,940 --> 00:39:55,189
Mám nějaký obsah později
Na v balíčku o tom.

942
00:39:55,189 --> 00:39:59,910
Ale proudy je opravdu running--
myslet na to, jak čas objednat

943
00:39:59,910 --> 00:40:01,274
a změna oddíl log.

944
00:40:01,274 --> 00:40:03,940
Všechno, co se děje na
V tabulce se objeví na proudu.

945
00:40:03,940 --> 00:40:05,940
>> Každý zapsat do tabulky
se objeví na proudu.

946
00:40:05,940 --> 00:40:08,370
Můžete si přečíst tento proud, a
můžete dělat, co s ním.

947
00:40:08,370 --> 00:40:10,150
Promluvíme si o tom, co
typy věcí,

948
00:40:10,150 --> 00:40:13,680
činění s věcmi, jako jsou replikace,
vznikají sekundární indexy.

949
00:40:13,680 --> 00:40:17,620
Všechny druhy opravdu cool
věci, které můžete udělat s tím.

950
00:40:17,620 --> 00:40:19,150
>> Datové typy.

951
00:40:19,150 --> 00:40:23,320
V DynamoDB, podporujeme i klíč
hodnota a datové typy dokumentů.

952
00:40:23,320 --> 00:40:26,350
Na levé straně obrazovky
tady, máme naše základní typy.

953
00:40:26,350 --> 00:40:27,230
Typy hodnoty klíče.

954
00:40:27,230 --> 00:40:30,040
Jsou to řetězce,
čísla a binární soubory.

955
00:40:30,040 --> 00:40:31,640
>> Takže jen tři základní typy.

956
00:40:31,640 --> 00:40:33,700
A pak můžete mít sady ty.

957
00:40:33,700 --> 00:40:37,650
Jedna z pěkné věci o NoSQL je
můžete obsahovat pole jako vlastnosti.

958
00:40:37,650 --> 00:40:42,050
A s DynamoDB můžete obsahovat pole
základních typů jako kořenová vlastnost.

959
00:40:42,050 --> 00:40:43,885
>> A pak je tu typy dokumentů.

960
00:40:43,885 --> 00:40:45,510
Kolik lidí jsou obeznámeni s JSON?

961
00:40:45,510 --> 00:40:47,130
Vy obeznámení s JSON tolik?

962
00:40:47,130 --> 00:40:49,380
Je to v podstatě JavaScript,
Object, notace.

963
00:40:49,380 --> 00:40:52,510
To vám umožní v podstatě
definují hierarchickou strukturu.

964
00:40:52,510 --> 00:40:58,107
>> Můžete uložit dokument o JSON
DynamoDB použití běžných komponent

965
00:40:58,107 --> 00:41:00,940
nebo stavební bloky, které jsou k dispozici
ve většině programovacích jazycích.

966
00:41:00,940 --> 00:41:03,602
Takže pokud máte Javu, budete
při pohledu na mapách a seznamy.

967
00:41:03,602 --> 00:41:05,060
Mohu vytvořit objekty, které Mapa oblasti.

968
00:41:05,060 --> 00:41:08,030
Mapa jako klíčové hodnoty
uložena jako vlastnosti.

969
00:41:08,030 --> 00:41:10,890
A to by mohlo mít seznamy
hodnot v rámci těchto vlastností.

970
00:41:10,890 --> 00:41:13,490
Můžete ukládat tento komplex
hierarchická struktura

971
00:41:13,490 --> 00:41:16,320
jako jediný atribut
z položky DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Takže tabulek v DynamoDB, stejně jako většina
Databáze NoSQL, tabulky mají položky.

974
00:41:24,460 --> 00:41:26,469
V MongoDB byste
volání těchto dokumentů.

975
00:41:26,469 --> 00:41:27,760
A to by byl gauč základna.

976
00:41:27,760 --> 00:41:28,900
Také dokument databáze.

977
00:41:28,900 --> 00:41:29,941
Zavoláte těchto dokumentů.

978
00:41:29,941 --> 00:41:32,930
Dokumenty nebo položky mají atributy.

979
00:41:32,930 --> 00:41:35,850
Atributy mohou existovat nebo
neexistuje na položku.

980
00:41:35,850 --> 00:41:38,520
V DynamoDB, je tu
jedním povinný atribut.

981
00:41:38,520 --> 00:41:43,880
Stejně jako v relační databázi,
máte primární klíč na stole.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB má to, co nazýváme hash klíč.

983
00:41:46,010 --> 00:41:48,280
Hash klíč musí být jedinečný.

984
00:41:48,280 --> 00:41:52,580
Takže když jsem definovat hash tabulky,
v podstatě to, co říkám

985
00:41:52,580 --> 00:41:54,110
je každá položka bude mít hash klíč.

986
00:41:54,110 --> 00:41:58,520
A každý křížkem musí být jedinečný.

987
00:41:58,520 --> 00:42:01,200
>> Každá položka je definována
touto unikátní křížek.

988
00:42:01,200 --> 00:42:02,940
A tam může být jen jeden.

989
00:42:02,940 --> 00:42:05,820
To je v pořádku, ale častokrát
to, co lidé potřebují

990
00:42:05,820 --> 00:42:08,170
je chtějí, je to hash
Klíčem k tomu trochu více

991
00:42:08,170 --> 00:42:11,010
než být jen jedinečný identifikátor.

992
00:42:11,010 --> 00:42:15,240
Často chceme použít tento hash klíč
jako nejvyšší úrovně agregace kbelíku.

993
00:42:15,240 --> 00:42:19,160
A způsob, jak to udělat, je tím,
přidávání říkáme rozsah klíč.

994
00:42:19,160 --> 00:42:22,460
>> Takže pokud je to jen hash
stůl, musí to být jedinečná.

995
00:42:22,460 --> 00:42:27,040
Pokud se jedná o hash a rozsah tabulky se
kombinace hash a rozsah

996
00:42:27,040 --> 00:42:28,640
musí být jedinečný.

997
00:42:28,640 --> 00:42:30,110
Takže myslíte, že o tom tímto způsobem.

998
00:42:30,110 --> 00:42:32,140
Mám-li fórum.

999
00:42:32,140 --> 00:42:39,010
A forma má témat, má
sloupky, a to má odpovědi.

1000
00:42:39,010 --> 00:42:42,630
>> Takže jsem mohl mít hash
klíč, což je téma ID.

1001
00:42:42,630 --> 00:42:46,650
A já mohla mít rozsah klíč,
což je ID odpověď.

1002
00:42:46,650 --> 00:42:49,650
Tak, když chci, aby si všechny
odpovědi na určité téma,

1003
00:42:49,650 --> 00:42:52,370
Mohu jen dotaz hash.

1004
00:42:52,370 --> 00:42:55,190
Mohu jen říct, dej mi všechny
položky, které mají tuto hash.

1005
00:42:55,190 --> 00:43:01,910
A budu se dostat na každou otázku
nebo poštou na tuto konkrétní téma.

1006
00:43:01,910 --> 00:43:03,910
Tyto špičkové úrovně agregace
jsou velmi důležité.

1007
00:43:03,910 --> 00:43:07,370
Podporují primární přístup
vzor žádosti.

1008
00:43:07,370 --> 00:43:09,420
Obecně řečeno, toto
je to, co chceme dělat.

1009
00:43:09,420 --> 00:43:11,780
Chceme, aby table--
jak si nahrát tabulku,

1010
00:43:11,780 --> 00:43:16,640
chceme strukturovat data
v tabulce tak,

1011
00:43:16,640 --> 00:43:20,140
že aplikace může velmi
rychle získat tyto výsledky.

1012
00:43:20,140 --> 00:43:24,510
A často způsob, jak to udělat, je
udržovat tyto agregací jako my

1013
00:43:24,510 --> 00:43:25,650
vložit data.

1014
00:43:25,650 --> 00:43:31,110
V podstatě jsme šíření dat
do jasného kbelíku, jak to přichází v.

1015
00:43:31,110 --> 00:43:35,210
>> Rozsah tlačítka umožňují me-- hash
Klávesy mají být rovnost.

1016
00:43:35,210 --> 00:43:39,490
Když jsem dotazu hash, musím říci,
dej mi hash, která se rovná toto.

1017
00:43:39,490 --> 00:43:41,950
Když jsem dotaz rozsah, já
Dá se říci, dej mi rozsah

1018
00:43:41,950 --> 00:43:47,040
že je použití jakékoli
bohatý subjekt, který podporujeme.

1019
00:43:47,040 --> 00:43:49,200
Dej mi všechny položky pro hash.

1020
00:43:49,200 --> 00:43:52,520
Je to stejné, větší než,
méně než, to začíná,

1021
00:43:52,520 --> 00:43:54,145
to existují mezi těmito dvěma hodnotami?

1022
00:43:54,145 --> 00:43:56,811
Takže tyto typy rozsahu dotazů
že máme vždy zajímá.

1023
00:43:56,811 --> 00:43:59,650
A teď jedna věc, o datech, kdy
se podíváte na přístup k datům, kdy

1024
00:43:59,650 --> 00:44:02,360
máte přístup k datům, je to
Vždycky jde o agregaci.

1025
00:44:02,360 --> 00:44:05,770
Je to vždycky o záznamech
které se vztahují k této.

1026
00:44:05,770 --> 00:44:10,390
Dejte mi tady všechno that's-- všechny
transakce na této kreditní karty

1027
00:44:10,390 --> 00:44:12,500
za poslední měsíc.

1028
00:44:12,500 --> 00:44:13,960
To je agregace.

1029
00:44:13,960 --> 00:44:17,490
>> Téměř všechno, co děláte v
Databáze je nějaký druh agregace.

1030
00:44:17,490 --> 00:44:21,530
Tak budou moci být schopni definovat
Tyto kbelíky a dá vám tyto rozsah

1031
00:44:21,530 --> 00:44:24,950
atributy, aby bylo možné na dotaz na,
ty bohaté dotazů podporuje mnoho,

1032
00:44:24,950 --> 00:44:27,165
mnoho, mnoho přístup k aplikacím vzory.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Takže další věc, s křížkem
dělá je, že nám dává mechanismus

1035
00:44:35,000 --> 00:44:37,740
aby bylo možné rozšířit data kolem.

1036
00:44:37,740 --> 00:44:40,390
Databáze NoSQL fungují nejlépe
když jsou data rovnoměrně

1037
00:44:40,390 --> 00:44:41,740
distribuována po clusteru.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Kolik lidí zná
s algoritmy hash?

1040
00:44:47,050 --> 00:44:49,860
Když řeknu, že hash a hashing--
protože je algoritmus hash

1041
00:44:49,860 --> 00:44:54,140
je způsob, jak být schopen generovat
náhodná hodnota z jakékoliv dané hodnoty.

1042
00:44:54,140 --> 00:44:59,300
Takže v tomto konkrétním případě
hashovací algoritmus provozujeme je ND 5 na základě.

1043
00:44:59,300 --> 00:45:04,765
>> A pokud mám ID, a to
je můj křížkem, mám 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Když spustím hash algoritmu,
to bude, aby se vrátil a řekl,

1045
00:45:07,390 --> 00:45:10,800
dobře 1 rovná 7B, 2
se rovná 48, 3 se rovná CD.

1046
00:45:10,800 --> 00:45:13,092
Jsou rozšířily do celého klíče prostoru.

1047
00:45:13,092 --> 00:45:14,050
A proč to děláte?

1048
00:45:14,050 --> 00:45:17,120
Vzhledem k tomu, že zajistí, že mohu
dal záznamy přes více uzlů.

1049
00:45:17,120 --> 00:45:19,574
>> Pokud bych to dělám
postupně, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
A mám hash rozsah, který
probíhá v tomto konkrétním případě,

1051
00:45:21,990 --> 00:45:24,785
malý hash prostor,
běží od 00 do FF,

1052
00:45:24,785 --> 00:45:27,951
pak záznamy se chystáte přijít
a oni se chystáte jít 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
Co se děje?

1055
00:45:31,800 --> 00:45:34,860
Každá vložka bude stejném uzlu.

1056
00:45:34,860 --> 00:45:36,070
Víš, co tím myslím?

1057
00:45:36,070 --> 00:45:40,910
>> Protože když jsem se rozdělit prostor,
a já se šíří přes tyto záznamy,

1058
00:45:40,910 --> 00:45:45,950
a oddíl já, já jsem chtěl říct,
oddíl 1 má klíčový prostor, 0 až 54.

1059
00:45:45,950 --> 00:45:47,720
Oddíl 2 je 55 až 89.

1060
00:45:47,720 --> 00:45:49,780
Oddíl 3 AA až FF.

1061
00:45:49,780 --> 00:45:53,740
Takže když jsem pomocí lineárně zvyšování
ID, můžete vidět, co se děje.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, vše až po 54.

1063
00:45:57,410 --> 00:46:00,030
Takže jak jsem zatloukat
záznamy do systému,

1064
00:46:00,030 --> 00:46:02,030
všechno skončí jít do jednoho uzlu.

1065
00:46:02,030 --> 00:46:03,160
>> To není dobré.

1066
00:46:03,160 --> 00:46:04,820
To je antipattern.

1067
00:46:04,820 --> 00:46:08,760
V MongoDB mají tento problém
pokud nechcete použít hash klíč.

1068
00:46:08,760 --> 00:46:11,325
MongoDB vám dává možnost
z hash hodnotu klíče.

1069
00:46:11,325 --> 00:46:13,950
Vždy byste měli udělat, pokud
vy používáte incrementing hash

1070
00:46:13,950 --> 00:46:17,380
Zadejte MongoDB, nebo budete
přibil každý zápis do jednoho uzlu,

1071
00:46:17,380 --> 00:46:21,290
a budete omezující
Váš zápis propustnost špatně.

1072
00:46:21,290 --> 00:46:24,896
>> Diváků: Je to A9 169 v desítkové soustavě?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Jo, to je
někde kolem tam.

1074
00:46:28,450 --> 00:46:29,950
A9, já nevím.

1075
00:46:29,950 --> 00:46:32,200
Musel byste, aby mi binární
na desetinné kalkulačka.

1076
00:46:32,200 --> 00:46:34,237
Můj mozek nefunguje takhle.

1077
00:46:34,237 --> 00:46:36,320
Diváků: Jen rychlý jedním
Vaše připomínky Mongo.

1078
00:46:36,320 --> 00:46:39,530
Tak je objekt, ID, který je dodáván
nativně s Mongo dělat, že?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Má to udělat?

1081
00:46:41,470 --> 00:46:42,970
Pokud jej specifikovat.

1082
00:46:42,970 --> 00:46:45,030
S MongoDB, máte možnost.

1083
00:46:45,030 --> 00:46:48,930
Můžete specify-- každý dokument v
MongoDB musí mít podtržítko ID.

1084
00:46:48,930 --> 00:46:50,300
To je unikátní hodnota.

1085
00:46:50,300 --> 00:46:55,240
>> V MongoDB můžete zadat
zda hash, nebo ne.

1086
00:46:55,240 --> 00:46:56,490
Prostě vám možnost.

1087
00:46:56,490 --> 00:46:58,198
Pokud víte, že je to
náhodný, žádný problém.

1088
00:46:58,198 --> 00:46:59,640
Nemusíte to dělat.

1089
00:46:59,640 --> 00:47:04,260
Pokud víte, že to není náhodné, že
to postupně, pak to hash.

1090
00:47:04,260 --> 00:47:06,880
>> Nyní věc, o
zatřiďování, jakmile se hash

1091
00:47:06,880 --> 00:47:08,800
value-- a to je
Proč hash klíče jsou vždy

1092
00:47:08,800 --> 00:47:13,740
unikátních dotazů, protože jsem se změnil
je hodnota, teď nemůžu udělat dotaz rozsahu.

1093
00:47:13,740 --> 00:47:15,640
Nemůžu říct, že je to
mezi to či ono,

1094
00:47:15,640 --> 00:47:20,800
protože hodnota hash nebude
se rovná skutečné hodnoty.

1095
00:47:20,800 --> 00:47:24,570
Takže když hash, že
klíč, je to jen rovnost.

1096
00:47:24,570 --> 00:47:28,700
To je důvod, proč v DynamoDB křížek
dotazy jsou vždy jen rovnost.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Takže teď v rozmezí key--
když jsem se dodat, že rozsah klíč,

1099
00:47:34,700 --> 00:47:38,180
tyto záznamy důležité spektrum všichni přijít a
oni se ukládají na stejný oddíl.

1100
00:47:38,180 --> 00:47:42,430
Tak oni jsou velmi rychle, snadno
načíst, protože to je hash,

1101
00:47:42,430 --> 00:47:43,220
to je řada.

1102
00:47:43,220 --> 00:47:44,928
A vidíte všechno
se stejnou hash

1103
00:47:44,928 --> 00:47:48,550
je uložena na stejném oddílu prostoru.

1104
00:47:48,550 --> 00:47:53,889
Můžete použít tento rozsah klíč pomoci
lokalizovat data v blízkosti jeho rodiče.

1105
00:47:53,889 --> 00:47:55,180
Tak co mám vlastně tady děláš?

1106
00:47:55,180 --> 00:47:57,320
To je jedním mnoha vztahu.

1107
00:47:57,320 --> 00:48:01,490
Vztah mezi křížek
a rozsah klíč je, kdo mnoho.

1108
00:48:01,490 --> 00:48:03,490
Mohu mít více hash klíčů.

1109
00:48:03,490 --> 00:48:07,610
Mohu mít jen více rozsah
klíče v každé křížek.

1110
00:48:07,610 --> 00:48:11,910
>> Hash definuje rodiče,
rozsah definuje děti.

1111
00:48:11,910 --> 00:48:15,240
Takže můžete vidět, že je analogový zde
mezi relační konstruktu

1112
00:48:15,240 --> 00:48:18,840
a stejné typy
konstrukty v NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Lidé mluví o
NoSQL jako Nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Není to Nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Údaje má vždy vztahy.

1116
00:48:24,680 --> 00:48:28,172
Tyto vztahy jen
jsou modelovány jinak.

1117
00:48:28,172 --> 00:48:29,880
Pojďme mluvit trochu
něco o trvanlivost.

1118
00:48:29,880 --> 00:48:34,860
Při psaní se DynamoDB, píše
jsou vždy třícestný replikovány.

1119
00:48:34,860 --> 00:48:37,550
To znamená, že máme tři AZ je.

1120
00:48:37,550 --> 00:48:39,160
AZ to jsou volné zóny.

1121
00:48:39,160 --> 00:48:43,430
Můžete myslet na dostupnost
Zone jako datové centrum

1122
00:48:43,430 --> 00:48:45,447
nebo soubor datových center.

1123
00:48:45,447 --> 00:48:47,780
Tyto věci jsou geograficky
izolovány od sebe navzájem

1124
00:48:47,780 --> 00:48:51,610
napříč různými zlomové, napříč
odlišný rozvodné sítě a zátopových oblastí.

1125
00:48:51,610 --> 00:48:54,510
Selhání v jedné AZ není
bude trvat dolů další.

1126
00:48:54,510 --> 00:48:56,890
Oni jsou také spojeny
spolu s tmavým vláknem.

1127
00:48:56,890 --> 00:49:01,240
To podporuje jeden sub 1
milisekunda zpoždění mezi AZS.

1128
00:49:01,240 --> 00:49:05,390
Takže data replikace v reálném čase
schopné v bytových AZS.

1129
00:49:05,390 --> 00:49:09,990
>> A často multi nasazení AZ
splňovaly požadavky na vysokou dostupnost

1130
00:49:09,990 --> 00:49:12,930
většiny podnikových organizací.

1131
00:49:12,930 --> 00:49:16,139
Takže DynamoDB se šíří
ve třech AZS ve výchozím nastavení.

1132
00:49:16,139 --> 00:49:19,430
Budeme jen k poznání Write
když se dva z těchto tří uzlů vrátí

1133
00:49:19,430 --> 00:49:21,470
a říkají, Jo, mám to.

1134
00:49:21,470 --> 00:49:22,050
Proč tomu tak je?

1135
00:49:22,050 --> 00:49:25,950
Vzhledem k tomu, na čtení stranu jsme jen
dám vám data zpět, pokud

1136
00:49:25,950 --> 00:49:27,570
jsme ho dostat ze dvou uzlů.

1137
00:49:27,570 --> 00:49:30,490
>> Pokud jsem replikace napříč
tři, a čtu ze dvou,

1138
00:49:30,490 --> 00:49:32,840
Já jsem vždy zaručena
mít alespoň jeden

1139
00:49:32,840 --> 00:49:35,720
z nich čte, že je
Nejaktuálnější kopie dat.

1140
00:49:35,720 --> 00:49:38,340
To je to, co dělá DynamoDB konzistentní.

1141
00:49:38,340 --> 00:49:42,450
Nyní si můžete vybrat otočit
ty konzistentní čte off.

1142
00:49:42,450 --> 00:49:45,070
V tom případě budu říkat,
Budu číst pouze z jednoho uzlu.

1143
00:49:45,070 --> 00:49:47,430
A nemůžu zaručit, že to bude
být nejvíce aktuální data.

1144
00:49:47,430 --> 00:49:49,450
>> Takže pokud write přichází,
to nebyla replikována dosud,

1145
00:49:49,450 --> 00:49:50,360
budete se dostat, že kopie.

1146
00:49:50,360 --> 00:49:52,220
To je nakonec konzistentní čtení.

1147
00:49:52,220 --> 00:49:54,640
A co to je, je polovinu nákladů.

1148
00:49:54,640 --> 00:49:56,140
Takže to je o čem přemýšlet.

1149
00:49:56,140 --> 00:50:00,160
Když čtete ven DynamoDB, a
jste nastavování čtení kapacity

1150
00:50:00,160 --> 00:50:04,430
jednotek, pokud se rozhodnete nakonec
konzistentní čte, je to mnohem levnější,

1151
00:50:04,430 --> 00:50:06,010
je to o polovinu nákladů.

1152
00:50:06,010 --> 00:50:09,342
>> A tak se ušetří peníze.

1153
00:50:09,342 --> 00:50:10,300
Ale to je vaše volba.

1154
00:50:10,300 --> 00:50:12,925
Pokud chcete, konzistentní čtení nebo
nakonec konzistentní čtení.

1155
00:50:12,925 --> 00:50:15,720
To je něco, co si můžete vybrat.

1156
00:50:15,720 --> 00:50:17,659
>> Pojďme se bavit o indexech.

1157
00:50:17,659 --> 00:50:19,450
Tak jsme se zmínili, že
nejvyšší úrovně agregace.

1158
00:50:19,450 --> 00:50:23,720
Máme hash klíče, a
máme rozsah klíče.

1159
00:50:23,720 --> 00:50:24,320
To je milé.

1160
00:50:24,320 --> 00:50:26,950
A to je na primární tabulky, já
má jedno křížkem, mám jeden rozsah klíč.

1161
00:50:26,950 --> 00:50:27,783
>> Co to znamená?

1162
00:50:27,783 --> 00:50:30,410
Mám jeden atribut, že jsem
může běžet bohaté dotazy proti.

1163
00:50:30,410 --> 00:50:31,800
Je to rozsah klíč.

1164
00:50:31,800 --> 00:50:35,530
Ostatní atributy na té item--
Mohu filtrovat na těch atributech.

1165
00:50:35,530 --> 00:50:40,050
Ale nemůžu dělat věci jako, to
začíná, nebo je větší než.

1166
00:50:40,050 --> 00:50:40,820
>> Jak to dělám?

1167
00:50:40,820 --> 00:50:42,860
I vytvořit index.

1168
00:50:42,860 --> 00:50:45,340
Jsou dva typy
indexy v DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Index je opravdu
Jiný pohled na tabulky.

1170
00:50:49,002 --> 00:50:50,490
A místní sekundární index.

1171
00:50:50,490 --> 00:50:51,781
>> První z nich budeme mluvit.

1172
00:50:51,781 --> 00:50:57,740
Takže místní pobočníci se koexistovaly
na stejném oddílu jako data.

1173
00:50:57,740 --> 00:51:00,240
A jako takové, jsou na
stejné fyzikální uzel.

1174
00:51:00,240 --> 00:51:01,780
Oni jsou to, co nazýváme konzistentní.

1175
00:51:01,780 --> 00:51:04,599
Význam, budou uznávat
zápisu spolu s tabulkou.

1176
00:51:04,599 --> 00:51:06,890
Při zápisu přijde,
budeme psát přes index.

1177
00:51:06,890 --> 00:51:09,306
Budeme psát až ke stolu,
a pak budeme potvrdit.

1178
00:51:09,306 --> 00:51:10,490
Tak to je konzistentní.

1179
00:51:10,490 --> 00:51:13,174
Jakmile je zápis byl
uznala od stolu,

1180
00:51:13,174 --> 00:51:15,090
je zaručeno, že
místní sekundární index

1181
00:51:15,090 --> 00:51:18,380
bude mít stejnou vizi dat.

1182
00:51:18,380 --> 00:51:22,390
Ale to, co vám umožní udělat, je
definovat alternativní klíče rozsah.

1183
00:51:22,390 --> 00:51:25,260
>> Musí používat stejný hash
key jako primární tabulce,

1184
00:51:25,260 --> 00:51:29,050
proto, že jsou umístěny na stejném místě na
stejný oddíl, a jsou konzistentní.

1185
00:51:29,050 --> 00:51:33,110
Ale můžu vytvořit index
s různými klíči dosahu.

1186
00:51:33,110 --> 00:51:41,590
Tak například, pokud jsem měl výrobce
že měl části tabulky syrové přicházet.

1187
00:51:41,590 --> 00:51:44,590
A RAW díly dodáváme v a
oni jsou agregované sestavou.

1188
00:51:44,590 --> 00:51:46,840
A možná je tu odvolání.

1189
00:51:46,840 --> 00:51:50,240
>> Každá část, která byla vyrobena tímto
Výrobce po tomto datu,

1190
00:51:50,240 --> 00:51:52,840
Musím vytáhnout z mého linky.

1191
00:51:52,840 --> 00:51:55,950
Dokážu točit index
že bude hledat,

1192
00:51:55,950 --> 00:52:00,760
agregaci dnem
Výroba této konkrétní části.

1193
00:52:00,760 --> 00:52:03,930
Takže pokud můj stůl nejvyšší úroveň byla
již zatříděna podle výrobce,

1194
00:52:03,930 --> 00:52:07,655
Možná to bylo uspořádáno na částečný ID, já
Můžete vytvořit index off této tabulce

1195
00:52:07,655 --> 00:52:11,140
jak hash výrobce a
pohybovala na data výroby.

1196
00:52:11,140 --> 00:52:14,490
A takhle bych mohl říci, že cokoli
byl vyroben mezi těmito daty,

1197
00:52:14,490 --> 00:52:16,804
Musím vytáhnout z linky.

1198
00:52:16,804 --> 00:52:18,220
Tak to je místní sekundární index.

1199
00:52:18,220 --> 00:52:22,280
>> Ty mají za následek
omezit svou klíčovou prostor hash.

1200
00:52:22,280 --> 00:52:24,360
Vzhledem k tomu, že koexistovaly
na stejné úložné uzlu,

1201
00:52:24,360 --> 00:52:26,860
omezují s křížkem
prostor na 10 GB.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, pod
stoly, se rozdělí

1203
00:52:28,950 --> 00:52:31,380
Váš stůl každých 10 gigabajtů.

1204
00:52:31,380 --> 00:52:34,760
Když dáte 10 koncerty dat v, my
go [PhH], a my jsme přidat další uzel.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Nebudeme rozdělit LSI
přes více oddílů.

1207
00:52:42,070 --> 00:52:43,200
Budeme rozdělit tabulku.

1208
00:52:43,200 --> 00:52:44,679
Ale nebudeme rozdělit LSI.

1209
00:52:44,679 --> 00:52:46,470
Tak to je něco,
důležité pochopit

1210
00:52:46,470 --> 00:52:50,070
je, pokud děláte hodně,
velmi, velmi velké shluky,

1211
00:52:50,070 --> 00:52:53,860
pak jste bude omezen
10 GB na vašem LSIS.

1212
00:52:53,860 --> 00:52:56,640
>> Pokud tomu tak je, můžeme
použít globální Sekundární.

1213
00:52:56,640 --> 00:52:58,630
Globální secondaries jsou
Opravdu jiné tabulky.

1214
00:52:58,630 --> 00:53:01,720
Existují úplně pryč
strana primární tabulky.

1215
00:53:01,720 --> 00:53:04,680
A dovolte mi, abych najít
zcela odlišná struktura.

1216
00:53:04,680 --> 00:53:08,010
Takže myslíte, že na to, jak se vkládá údaje
do dvou různých tabulek, strukturované

1217
00:53:08,010 --> 00:53:09,220
dvěma různými způsoby.

1218
00:53:09,220 --> 00:53:11,360
>> Mohu definovat zcela
jiný křížkem.

1219
00:53:11,360 --> 00:53:13,490
Mohu definovat zcela
jiný klíč rozsah.

1220
00:53:13,490 --> 00:53:15,941
A můžu běžet to
zcela nezávisle na sobě.

1221
00:53:15,941 --> 00:53:18,190
Jako ve skutečnosti, jsem
dotován mé čtení kapacity

1222
00:53:18,190 --> 00:53:21,090
a psát kapacity pro mou
globální sekundární indexy

1223
00:53:21,090 --> 00:53:24,240
zcela nezávisle
můj primární tabulky.

1224
00:53:24,240 --> 00:53:26,640
Kdybych stanoví tento index, řeknu
to, jak moc číst a psát

1225
00:53:26,640 --> 00:53:28,610
Kapacita to bude používat.

1226
00:53:28,610 --> 00:53:31,490
>> A to je samostatná
z mého primární tabulky.

1227
00:53:31,490 --> 00:53:35,240
Nyní oba indexy nám umožňují
nejen definovat hash a rozsah kláves,

1228
00:53:35,240 --> 00:53:38,610
ale oni nám umožňují
promítat další hodnoty.

1229
00:53:38,610 --> 00:53:44,950
Takže pokud chci odečtěte index,
a chci získat nějaké sadu dat,

1230
00:53:44,950 --> 00:53:48,327
Nepotřebuji se vrátit do hlavního
Tabulka získat další atributy.

1231
00:53:48,327 --> 00:53:50,660
I může promítat ty další
atributů do tabulky

1232
00:53:50,660 --> 00:53:53,440
podporovat přístup vzor.

1233
00:53:53,440 --> 00:53:57,700
Vím, že jsme asi dostat do některých
Opravdu, really-- dostat do plevel

1234
00:53:57,700 --> 00:53:58,910
tady na některé z těchto věcí.

1235
00:53:58,910 --> 00:54:02,725
Teď mám se nechat unášet z toho.

1236
00:54:02,725 --> 00:54:07,320
>> Diváků: [Neslyšitelné]
--table klíč znamenalo, hash?

1237
00:54:07,320 --> 00:54:08,840
Původní hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-lamely?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Ano.

1240
00:54:10,200 --> 00:54:11,070
Ano.

1241
00:54:11,070 --> 00:54:15,260
Tabulka klíč v podstatě
poukazuje zpět do položky.

1242
00:54:15,260 --> 00:54:19,280
Tak že index je ukazatel zpět do
původní položky na stole.

1243
00:54:19,280 --> 00:54:22,910
Nyní si můžete vybrat vybudovat
index, který má pouze tabulku klíč,

1244
00:54:22,910 --> 00:54:24,840
a žádné jiné vlastnosti.

1245
00:54:24,840 --> 00:54:26,570
A proč bych to dělal?

1246
00:54:26,570 --> 00:54:28,570
No, možná mám velmi velké položky.

1247
00:54:28,570 --> 00:54:31,660
>> Opravdu jen potřebuji vědět which--
můj přístup vzor by se říci,

1248
00:54:31,660 --> 00:54:33,760
položky, které obsahují tuto nemovitost?

1249
00:54:33,760 --> 00:54:35,780
Nepotřebujete vrátit položku.

1250
00:54:35,780 --> 00:54:37,800
Prostě potřebuju vědět,
položky, které obsahují to.

1251
00:54:37,800 --> 00:54:40,700
Takže si můžete vytvořit indexy
které mají pouze tabulku klíč.

1252
00:54:40,700 --> 00:54:43,360
>> Ale to je v první řadě to, co
index v databázi je pro.

1253
00:54:43,360 --> 00:54:46,280
Je to, že jsou schopny rychle
určit, které zaznamenává,

1254
00:54:46,280 --> 00:54:49,470
které řádky, které
položky v tabulce mají

1255
00:54:49,470 --> 00:54:51,080
vlastnosti, které jsem hledali.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, tak jak fungují?

1258
00:54:54,860 --> 00:54:58,340
GSIS v podstatě jsou asynchronní.

1259
00:54:58,340 --> 00:55:02,570
Aktualizace přichází do tabulky,
Tabulka je pak asynchronně aktualizován

1260
00:55:02,570 --> 00:55:03,720
všechny vaše GSIS.

1261
00:55:03,720 --> 00:55:06,680
To je důvod, proč jsou GSIS
nakonec konzistentní.

1262
00:55:06,680 --> 00:55:09,440
>> Je důležité poznamenat, že
když stavíte GSIS,

1263
00:55:09,440 --> 00:55:13,110
a pochopíte, budete vytvářet
další rozměr aggregation--

1264
00:55:13,110 --> 00:55:16,594
Nyní řekněme, že dobrý příklad
Zde je výrobce.

1265
00:55:16,594 --> 00:55:19,260
Myslím, že bych mohl mít mluvil o
lékařské výrobce zařízení.

1266
00:55:19,260 --> 00:55:23,870
Výrobci Lékařské zařízení
častokrát mají Serializovaná části.

1267
00:55:23,870 --> 00:55:28,070
Části, které jdou do
náhradní hip vše

1268
00:55:28,070 --> 00:55:30,200
mít trochu sériové číslo na ně.

1269
00:55:30,200 --> 00:55:33,584
A oni mohli mít miliony a
milióny a miliardy dílů

1270
00:55:33,584 --> 00:55:35,000
ve všech zařízeních, která se loď.

1271
00:55:35,000 --> 00:55:37,440
No, oni potřebují k agregaci v rámci
různé rozměry, všechny díly

1272
00:55:37,440 --> 00:55:39,520
v sestavě, veškeré
díly, které byly provedeny

1273
00:55:39,520 --> 00:55:41,670
na určité linie, vše
části, které přišly

1274
00:55:41,670 --> 00:55:44,620
v od určitého výrobce
k určitému datu.

1275
00:55:44,620 --> 00:55:47,940
A tyto shluky někdy
dostat až do miliard.

1276
00:55:47,940 --> 00:55:50,550
>> Tak jsem se pracovat s některými z
tito lidé, kteří trpí

1277
00:55:50,550 --> 00:55:53,156
protože jsou vytváření
Tyto GINORMOUS agregace

1278
00:55:53,156 --> 00:55:54,280
v jejich sekundárních indexů.

1279
00:55:54,280 --> 00:55:57,070
Mohou mít syrové díly
stůl, který je dodáván pouze jako hash.

1280
00:55:57,070 --> 00:55:59,090
Každá část má unikátní sériové číslo.

1281
00:55:59,090 --> 00:56:00,975
Já používám sériové číslo jako hash.

1282
00:56:00,975 --> 00:56:01,600
To je krásné.

1283
00:56:01,600 --> 00:56:04,160
Můj surová data tabulky se rozprostírá
po celé klíče prostoru.

1284
00:56:04,160 --> 00:56:05,930
Můj [? napsat ?]
[? Požití?] je úžasné.

1285
00:56:05,930 --> 00:56:07,876
Beru velké množství dat.

1286
00:56:07,876 --> 00:56:09,500
Pak to, co dělají, je, že vytvoří GSI.

1287
00:56:09,500 --> 00:56:12,666
A já říkám, víš co, musím vidět
Všechny díly pro tohoto výrobce.

1288
00:56:12,666 --> 00:56:15,060
No, najednou jsem si
přičemž miliardy řádků,

1289
00:56:15,060 --> 00:56:17,550
a tak je na
jeden uzel, protože když

1290
00:56:17,550 --> 00:56:21,170
I agregovat jako
Výrobce ID jako hash,

1291
00:56:21,170 --> 00:56:25,410
a číslo dílu jako oblast,
pak všichni najednou, že jsem

1292
00:56:25,410 --> 00:56:30,530
uvedení miliardy díly do čeho
Tento výrobce mě doručena.

1293
00:56:30,530 --> 00:56:34,447
>> To může způsobit hodně
tlaku na GSI,

1294
00:56:34,447 --> 00:56:36,030
znovu, protože jsem příklepem jeden uzel.

1295
00:56:36,030 --> 00:56:38,350
Dávám všechny tyto
vloží do jednoho uzlu.

1296
00:56:38,350 --> 00:56:40,940
A to je skutečný problematický případ použití.

1297
00:56:40,940 --> 00:56:43,479
Teď jsem dostal dobrý design
vzor pro to, jak se vyhnout to.

1298
00:56:43,479 --> 00:56:45,770
A to je jeden z problémů
že jsem vždycky pracovat.

1299
00:56:45,770 --> 00:56:49,590
Ale co se stane, je GSI může
Není dostatek zápisu kapacity

1300
00:56:49,590 --> 00:56:52,330
aby bylo možné posunout všechny ty
řádků do jednoho uzlu.

1301
00:56:52,330 --> 00:56:55,390
A co se stane, pak je
primární, klient tabulka,

1302
00:56:55,390 --> 00:57:00,180
primární tabulce bude škrtil
protože GSI nemůže držet krok.

1303
00:57:00,180 --> 00:57:02,980
Takže můj vložka sazba
spadnout na primární tabulky

1304
00:57:02,980 --> 00:57:06,230
jako můj GSI snaží držet krok.

1305
00:57:06,230 --> 00:57:08,850
>> Dobře, takže GSI je, LSI je,
který z nich bych měl použít?

1306
00:57:08,850 --> 00:57:12,290
LSI je být konzistentní.

1307
00:57:12,290 --> 00:57:13,750
GSI to jsou nakonec konzistentní.

1308
00:57:13,750 --> 00:57:17,490
Pokud to je v pořádku, doporučuji pomocí
GSI, jsou mnohem flexibilnější.

1309
00:57:17,490 --> 00:57:20,270
LSI může být modelována jako GSI.

1310
00:57:20,270 --> 00:57:27,040
A v případě, že velikost dat na hash klíčů
vaše sbírka překročí 10 gigabajtů,

1311
00:57:27,040 --> 00:57:31,050
pak budete chtít použít, že
GSI, protože je to jen pevný limit.

1312
00:57:31,050 --> 00:57:32,035
>> Dobře, takže škálování.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Výkon v Dynamo DB, vy
ustanovení může [neslyšitelných]

1315
00:57:37,460 --> 00:57:38,680
propustnost do tabulky.

1316
00:57:38,680 --> 00:57:42,740
Máme zákazníky, kteří mají
dotován 60 billion--

1317
00:57:42,740 --> 00:57:45,970
dělají 60 miliard žádostí, pravidelně
běží na více než milion žádostí

1318
00:57:45,970 --> 00:57:47,790
za sekundu na našich stolech.

1319
00:57:47,790 --> 00:57:50,360
To fakt není
teoretický limit, kolik

1320
00:57:50,360 --> 00:57:53,730
a jak rychle se tabulka
lze spustit v Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Tam jsou některé měkké
limity na vašem účtu

1322
00:57:55,920 --> 00:57:58,170
že jsme dali tam tak
že nemusíte zbláznit.

1323
00:57:58,170 --> 00:58:00,070
Chcete-li více než
že, není problém.

1324
00:58:00,070 --> 00:58:00,820
Přišel jsi řekněte nám.

1325
00:58:00,820 --> 00:58:02,810
Budeme zase až voličem.

1326
00:58:02,810 --> 00:58:08,210
>> Každý účet je omezena na určité úrovni
v každé službě, jen kousek od netopýra

1327
00:58:08,210 --> 00:58:11,920
takže lidé nemají zbláznit
dostat se do potíží.

1328
00:58:11,920 --> 00:58:12,840
Žádný limit velikosti.

1329
00:58:12,840 --> 00:58:14,940
Můžete dát libovolný počet
položek na stole.

1330
00:58:14,940 --> 00:58:17,620
Velikost položky je
omezena na 400 kB každý,

1331
00:58:17,620 --> 00:58:20,050
které by byly položka se atributy.

1332
00:58:20,050 --> 00:58:24,200
Takže součet všech atributů
je omezena na 400 kB.

1333
00:58:24,200 --> 00:58:27,300
A pak znovu, máme
ten malý LSI otázka

1334
00:58:27,300 --> 00:58:30,405
s 10 GB limitu na hash.

1335
00:58:30,405 --> 00:58:33,280
Publikum: malý počet, mi chybí
to, co mi říkáte, že je--

1336
00:58:33,280 --> 00:58:36,830
Publikum: Oh, 400kb
je maximální velikost za položku.

1337
00:58:36,830 --> 00:58:39,570
Takže položka má všechny atributy.

1338
00:58:39,570 --> 00:58:43,950
Takže 400 k je celková velikost
této položky, 400 kilobajtů.

1339
00:58:43,950 --> 00:58:46,170
Takže ze všech atributů
kombinované, všechny údaje

1340
00:58:46,170 --> 00:58:49,140
to je ve všech těch atributech,
srolované do celkové velikosti,

1341
00:58:49,140 --> 00:58:51,140
V současné době dnes limit položka 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Takže znovu měřítka, dosáhl
přes rozdělení.

1344
00:58:57,046 --> 00:58:58,920
Propustnost je dotován
na úrovni tabulky.

1345
00:58:58,920 --> 00:59:00,160
A je to opravdu dva knoflíky.

1346
00:59:00,160 --> 00:59:02,400
Četli jsme kapacitu
a psát kapacity.

1347
00:59:02,400 --> 00:59:05,530
>> To jsou tedy upraveny
nezávisle na sobě.

1348
00:59:05,530 --> 00:59:08,640
RCU měřítkem přísně v souladu čte.

1349
00:59:08,640 --> 00:59:13,005
OK, takže pokud jste říkal chci 1000
RCU to ty jsou přísně konzistentní,

1350
00:59:13,005 --> 00:59:14,130
ty jsou v souladu čte.

1351
00:59:14,130 --> 00:59:17,130
Když řeknete, chci
Eventuální konzistentní čte,

1352
00:59:17,130 --> 00:59:19,402
můžete ustanovení 1000
RCU je, budete

1353
00:59:19,402 --> 00:59:21,840
dostat 2.000 nakonec
konzistentní čte.

1354
00:59:21,840 --> 00:59:25,940
A poloviční cenu pro ty,
nakonec spočívá v čte.

1355
00:59:25,940 --> 00:59:28,520
>> Opět platí, upraveno
nezávisle na sobě.

1356
00:59:28,520 --> 00:59:32,900
A oni mají throughput--
Pokud budete konzumovat 100% své dálkovém ovladači,

1357
00:59:32,900 --> 00:59:35,960
vy nebudete mít dopad na
dostupnost vašich práv.

1358
00:59:35,960 --> 00:59:40,161
Takže jsou zcela
nezávisle na sobě.

1359
00:59:40,161 --> 00:59:43,160
Dobře, takže jedna z věcí, které
Zmínil jsem se krátce byl škrcení.

1360
00:59:43,160 --> 00:59:44,320
Škrcení je špatné.

1361
00:59:44,320 --> 00:59:47,311
Škrcení označuje špatný žádné SQL.

1362
00:59:47,311 --> 00:59:50,310
Tam jsou věci, které můžeme udělat, aby pomohla
jste zmírnit škrcení, které vás

1363
00:59:50,310 --> 00:59:51,040
zažívají.

1364
00:59:51,040 --> 00:59:53,240
Ale nejlepším řešením
je to, pojďme

1365
00:59:53,240 --> 00:59:58,000
Podívejte se na to, co děláte, protože
tam je anti-vzor ve hře zde.

1366
00:59:58,000 --> 01:00:02,140
>> Tyto věci, věci, jako je non-uniformě
zátěže, horké klávesy, horké příčky.

1367
01:00:02,140 --> 01:00:06,210
Jsem bít konkrétní klíčový prostor
velmi těžké pro nějakého konkrétního důvodu.

1368
01:00:06,210 --> 01:00:07,080
Proč to dělám?

1369
01:00:07,080 --> 01:00:08,710
Pojďme zjistit, že ven.

1370
01:00:08,710 --> 01:00:10,427
Já jsem míchání mé horké data s daty za studena.

1371
01:00:10,427 --> 01:00:12,510
Nechávám mé tabulky dostat
obrovský, ale je to opravdu

1372
01:00:12,510 --> 01:00:15,970
pouze některé podmnožinu dat
to je opravdu pro mě zajímavé.

1373
01:00:15,970 --> 01:00:20,290
Takže pro dat protokolu, například, hodně
Zákazníci, dostanou data protokolu každý den.

1374
01:00:20,290 --> 01:00:22,490
Mají obrovské množství dat protokolu.

1375
01:00:22,490 --> 01:00:25,940
>> Pokud jste právě dumping všechny, kteří se přihlašují
Data do jednoho velkého stolu, v průběhu času

1376
01:00:25,940 --> 01:00:28,070
že tabulka se dostane masivní.

1377
01:00:28,070 --> 01:00:30,950
Ale já jsem opravdu zajímá jen
posledních 24 hodin, posledních sedm dní,

1378
01:00:30,950 --> 01:00:31,659
během posledních 30 dnů.

1379
01:00:31,659 --> 01:00:34,074
Bez ohledu na časové okno
že mám zájem při hledání

1380
01:00:34,074 --> 01:00:37,010
Pro případ, že mi vadí, nebo
událost, která je pro mě zajímavé,

1381
01:00:37,010 --> 01:00:39,540
to je jediná doba, okno, které potřebuji.

1382
01:00:39,540 --> 01:00:42,470
Tak proč jsem dávat 10 let
v hodnotě dat protokolu v tabulce?

1383
01:00:42,470 --> 01:00:45,030
To, co způsobuje, že je
tabulka fragment.

1384
01:00:45,030 --> 01:00:45,880
>> To dostane obrovský.

1385
01:00:45,880 --> 01:00:48,340
To začne se šířit ven
přes tisíců uzlů.

1386
01:00:48,340 --> 01:00:51,380
A od té doby své funkci
je tak nízká, že jste

1387
01:00:51,380 --> 01:00:54,090
ve skutečnosti omezení rychlosti na každém
jeden z těchto jednotlivých uzlů.

1388
01:00:54,090 --> 01:00:57,120
Takže pojďme začít hledat na to, jak
máme vrátit tuto tabulku přes.

1389
01:00:57,120 --> 01:01:01,502
Jak se nám podaří, aby údaje o něco
lepší se vyhnout těmto problémům.

1390
01:01:01,502 --> 01:01:02,710
A co to vypadá?

1391
01:01:02,710 --> 01:01:04,370
To je, co to vypadá.

1392
01:01:04,370 --> 01:01:06,790
To je to, co špatné, NoSQL vypadá.

1393
01:01:06,790 --> 01:01:07,830
>> Mám horkou klávesu zde.

1394
01:01:07,830 --> 01:01:10,246
Podíváte-li se na straně tady,
to všechno jsou moje oddíly.

1395
01:01:10,246 --> 01:01:12,630
Dostal jsem 16 oddílů sem
na tento konkrétní databáze.

1396
01:01:12,630 --> 01:01:13,630
Děláme to po celou dobu.

1397
01:01:13,630 --> 01:01:15,046
Běžím to pro zákazníky všech dob.

1398
01:01:15,046 --> 01:01:16,550
Jmenuje se teplo mapa.

1399
01:01:16,550 --> 01:01:20,590
Teplo mapu mi říká, jak jste
přístupu k klíč prostor.

1400
01:01:20,590 --> 01:01:23,700
A co to mi říká, je
že tam je jeden konkrétní hash

1401
01:01:23,700 --> 01:01:26,330
že tento člověk má rád
strašně moc, protože je

1402
01:01:26,330 --> 01:01:28,250
bít to opravdu, opravdu těžké.

1403
01:01:28,250 --> 01:01:29,260
>> Takže modrá je hezká.

1404
01:01:29,260 --> 01:01:29,900
Máme rádi modrou.

1405
01:01:29,900 --> 01:01:30,720
Nemáme rádi červené.

1406
01:01:30,720 --> 01:01:33,120
Red, kde je tlak
dostane až do výše 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, teď jsi bude škrtil.

1408
01:01:35,560 --> 01:01:39,030
Takže kdykoli budete vidět žádné červené čáry, jako je
tohle--, a není to jen Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
každá databáze NoSQL má tento problém.

1410
01:01:41,630 --> 01:01:44,640
Tam jsou anti-vzory, které mohou
řídit tyto typy podmínek.

1411
01:01:44,640 --> 01:01:49,070
Co mám dělat, je, že jsem pracovat se zákazníky
pro zmírnění těchto podmínek.

1412
01:01:49,070 --> 01:01:51,840
>> A co to vypadá?

1413
01:01:51,840 --> 01:01:54,260
A to už je co nejvíce
z Dynamo DB propustnosti,

1414
01:01:54,260 --> 01:01:56,176
ale je to opravdu dostat
nejvíce z NoSQL.

1415
01:01:56,176 --> 01:01:58,740
To se neomezuje pouze na Dynamo.

1416
01:01:58,740 --> 01:02:02,050
To je definitely-- I
pracoval v Mongo.

1417
01:02:02,050 --> 01:02:04,090
Jsem obeznámen s mnoha NoSQL platformách.

1418
01:02:04,090 --> 01:02:06,830
Každý, kdo má tyto typy
horké klíčových problémů.

1419
01:02:06,830 --> 01:02:10,320
Chcete-li získat co nejvíce z jakéhokoli NoSQL
databáze, konkrétně Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
Chcete-li vytvořit tabulky
kde hash klíčovým prvkem má

1421
01:02:13,320 --> 01:02:18,590
velké množství odlišných hodnot,
vysoký stupeň mohutnost.

1422
01:02:18,590 --> 01:02:22,530
Protože to znamená, že píšu
na mnoha různých kbelíky.

1423
01:02:22,530 --> 01:02:24,870
>> Čím více jsem kbelíky
písemně, tím větší je pravděpodobnost

1424
01:02:24,870 --> 01:02:29,100
Jsem šířit tuto zátěž zápisu nebo
číst zatížení se přes více uzlů,

1425
01:02:29,100 --> 01:02:33,560
tím je pravděpodobnější, jsem mít
vysoký výkon na stole.

1426
01:02:33,560 --> 01:02:37,440
A pak chci hodnoty, aby
požádala docela rovnoměrně v průběhu času

1427
01:02:37,440 --> 01:02:39,430
a jednotně náhodně jak je to možné.

1428
01:02:39,430 --> 01:02:42,410
No, to je docela zajímavé,
protože nemůžu

1429
01:02:42,410 --> 01:02:43,960
Ovládání když uživatelé přijdou.

1430
01:02:43,960 --> 01:02:47,645
Takže stačí říct, pokud budeme šířit
věci se přes klíče prostoru,

1431
01:02:47,645 --> 01:02:49,270
budeme pravděpodobně v lepší formě.

1432
01:02:49,270 --> 01:02:51,522
>> Je tu určitá
Množství okamžiku dodání

1433
01:02:51,522 --> 01:02:53,230
že nejdeš
Aby bylo možné kontrolu.

1434
01:02:53,230 --> 01:02:55,438
Ale to jsou opravdu
dva rozměry, které máme,

1435
01:02:55,438 --> 01:02:58,800
prostor, přístup rovnoměrně
šíření, čas, žádosti

1436
01:02:58,800 --> 01:03:01,040
kteří přijíždějí rovnoměrně rozloženy v čase.

1437
01:03:01,040 --> 01:03:03,110
A pokud ti dva
jsou splněny podmínky,

1438
01:03:03,110 --> 01:03:05,610
pak je to to, co to je
vypadat.

1439
01:03:05,610 --> 01:03:07,890
To je mnohem hezčí.

1440
01:03:07,890 --> 01:03:08,890
Jsme tady opravdu šťastný.

1441
01:03:08,890 --> 01:03:10,432
Máme velmi rovný přístup vzor.

1442
01:03:10,432 --> 01:03:13,098
Jo, možná jste stále
malý tlak tu a tam,

1443
01:03:13,098 --> 01:03:14,830
ale nic opravdu příliš rozsáhlé.

1444
01:03:14,830 --> 01:03:17,660
Takže je to úžasné, kolikrát,
když jsem se pracovat se zákazníky,

1445
01:03:17,660 --> 01:03:20,670
že jako první graf s velkým červeným
bar a vše, co ošklivé žluté je to

1446
01:03:20,670 --> 01:03:23,147
všude, jsme
si udělal s výkonem

1447
01:03:23,147 --> 01:03:24,980
po několika měsících
zpětného architektury,

1448
01:03:24,980 --> 01:03:28,050
Utíkají přesně stejné
pracovní zátěž na přesně stejnou zátěží.

1449
01:03:28,050 --> 01:03:30,140
A to je to, co vypadá to jako teď.

1450
01:03:30,140 --> 01:03:36,600
Takže to, co dostanete s NoSQL je
Data schématu, který je naprosto

1451
01:03:36,600 --> 01:03:38,510
vázána na vzorek přístup.

1452
01:03:38,510 --> 01:03:42,170
>> A můžete optimalizovat, že data schéma
na podporu tohoto přístupu vzor.

1453
01:03:42,170 --> 01:03:45,490
Pokud ne, pak budete
vidět ty druhy problémů

1454
01:03:45,490 --> 01:03:46,710
s těmito horkých kláves.

1455
01:03:46,710 --> 01:03:50,518
>> Diváků: No, nevyhnutelně některá místa
se bude teplejší než ostatní.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Vždy.

1457
01:03:51,450 --> 01:03:51,960
Vždy.

1458
01:03:51,960 --> 01:03:54,620
Jo, myslím, že je vždy
je-- a znovu, je tu

1459
01:03:54,620 --> 01:03:56,980
některé návrhové vzory se dostaneme přes
který bude mluvit o tom, jak se vypořádat

1460
01:03:56,980 --> 01:03:58,480
s těmito extra velkými agregace.

1461
01:03:58,480 --> 01:04:01,260
Myslím, že musím mít je,
jak jsme se s nimi vypořádat?

1462
01:04:01,260 --> 01:04:03,760
Mám docela dobrý případ použití
že budeme hovořit o za to.

1463
01:04:03,760 --> 01:04:05,940
>> V pořádku, takže pojďme mluvit
asi někteří nyní zákazníci.

1464
01:04:05,940 --> 01:04:06,950
Tihle chlapi jsou AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Já nevím, jestli jste
obeznámeni s AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Pravděpodobně jste vidět
hodně na prohlížeči.

1467
01:04:10,781 --> 01:04:14,230
Jsou ad re-targeting, jsou
největší obchodní ad re-cílení

1468
01:04:14,230 --> 01:04:14,940
tam venku.

1469
01:04:14,940 --> 01:04:17,792
Obvykle pravidelně přejet
60 miliard transakcí za den.

1470
01:04:17,792 --> 01:04:20,000
Dělají přes milion
transakcí za sekundu.

1471
01:04:20,000 --> 01:04:22,660
Mají tam docela jednoduchou tabulku
struktura, nejrušnější tabulky.

1472
01:04:22,660 --> 01:04:26,450
Je to v podstatě jen
křížkem je cookie,

1473
01:04:26,450 --> 01:04:29,010
rozsah je demografický
kategorie, a poté

1474
01:04:29,010 --> 01:04:31,220
Třetí atribut je skóre.

1475
01:04:31,220 --> 01:04:33,720
>> Takže máme všichni cookies
náš prohlížeč od těchto kluků.

1476
01:04:33,720 --> 01:04:35,900
A když jdete na
účast obchodníka,

1477
01:04:35,900 --> 01:04:39,390
Oni v podstatě skóre vás napříč
různé demografické kategorie.

1478
01:04:39,390 --> 01:04:42,070
Když jdete na webové stránky a
Říkáte, že chcete vidět tuto ad--

1479
01:04:42,070 --> 01:04:44,920
nebo v podstatě nemusíte říkat that--
ale když jdete na webových stránkách

1480
01:04:44,920 --> 01:04:47,550
říkají, že chcete vidět tuto reklamu.

1481
01:04:47,550 --> 01:04:49,370
A oni jdou dostat, že reklama AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll vás podívá se na jejich stolu.

1483
01:04:51,130 --> 01:04:52,115
Zjistí, že je váš cookie.

1484
01:04:52,115 --> 01:04:53,990
Inzerenti vyprávění
jim, chci někoho

1485
01:04:53,990 --> 01:04:58,632
kdo je ve středním věku,
40-letý muž, do sportu.

1486
01:04:58,632 --> 01:05:01,590
A oni skóre vás v těch demografii
a oni se rozhodnou, zda

1487
01:05:01,590 --> 01:05:02,740
že je to dobrý reklama pro vás.

1488
01:05:02,740 --> 01:05:10,330
>> Nyní mají SLA s
jejich poskytovatelů reklamní

1489
01:05:10,330 --> 01:05:14,510
poskytovat sub-10 milisekund
Odezva na jednotlivých vyžádání.

1490
01:05:14,510 --> 01:05:16,090
Takže oni používáte Dynamo DB pro toto.

1491
01:05:16,090 --> 01:05:18,131
Oni nás bít
milion požadavků za sekundu.

1492
01:05:18,131 --> 01:05:21,120
Jsou schopni dělat všechny své
číselníků, třídění všechno údaje,

1493
01:05:21,120 --> 01:05:26,130
a dostat, že doplněk odkaz zpět na který
inzerenta za méně než 10 milisekund.

1494
01:05:26,130 --> 01:05:29,800
Je to opravdu docela fenomenální
implementace, která mají.

1495
01:05:29,800 --> 01:05:36,210
>> Tihle kluci actually--
jsou ti chlapi.

1496
01:05:36,210 --> 01:05:38,010
Nejsem si jistý, jestli je to ty chlapy.

1497
01:05:38,010 --> 01:05:40,127
Může být tyto lidi.

1498
01:05:40,127 --> 01:05:42,210
V podstatě řekl us-- ne, já
si nemyslím, že to byli oni.

1499
01:05:42,210 --> 01:05:43,000
Myslím, že to byl někdo jiný.

1500
01:05:43,000 --> 01:05:44,750
Pracoval jsem s
zákazník, který mi řekl,

1501
01:05:44,750 --> 01:05:47,040
že teď, když jsem
šel do Dynamo DB, jsou

1502
01:05:47,040 --> 01:05:50,330
utrácet více peněz na občerstvení pro
jejich vývojový tým každý měsíc

1503
01:05:50,330 --> 01:05:52,886
než utratí za své databáze.

1504
01:05:52,886 --> 01:05:54,760
Tak to ti dám
Myšlenka úspor nákladů

1505
01:05:54,760 --> 01:05:57,889
že se můžete dostat do Dynamo DB je obrovský.

1506
01:05:57,889 --> 01:05:59,430
Dobře, dropcam je jiná společnost.

1507
01:05:59,430 --> 01:06:02,138
Tyto chlap druh of-- pokud si myslíte,
internetového věcí, dropcam

1508
01:06:02,138 --> 01:06:05,150
je v podstatě Internet Security videa.

1509
01:06:05,150 --> 01:06:06,660
Dáte svůj fotoaparát venku.

1510
01:06:06,660 --> 01:06:08,180
Kamera má detektor pohybu.

1511
01:06:08,180 --> 01:06:10,290
Někdo přijde,
spouští startovací bod.

1512
01:06:10,290 --> 01:06:13,540
Fotoaparát začne nahrávat na chvíli až do
nezjistí žádný pohyb ještě.

1513
01:06:13,540 --> 01:06:15,310
Klade, že videa se na internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam byla společnost, která je
v podstatě přešel na Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
protože oni prožívali
obrovské rostoucí bolesti.

1516
01:06:22,200 --> 01:06:25,820
A to, co nám řekli,
Najednou petabajtů dat.

1517
01:06:25,820 --> 01:06:28,070
Netušili, své služby
by byl tak úspěšný.

1518
01:06:28,070 --> 01:06:32,310
Více než YouTube video příchozí
je to, co tito lidé dostávají.

1519
01:06:32,310 --> 01:06:36,780
Oni používají DynamoDB sledovat všechny
metadata na všech svých videa klíčových bodech.

1520
01:06:36,780 --> 01:06:40,282
>> Takže oni mají S3 kbelíky, které posouvají
Všechny binární artefakty do.

1521
01:06:40,282 --> 01:06:41,990
A pak, že mají
Dynamo DB záznamy, které

1522
01:06:41,990 --> 01:06:44,070
poukazují na ty lidi, S3, tři objekty.

1523
01:06:44,070 --> 01:06:47,070
Když se třeba podívat se na video,
oni vyhledat záznam v Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Oni klikněte na odkaz.

1525
01:06:47,903 --> 01:06:49,770
Oni strhnout na video z S3.

1526
01:06:49,770 --> 01:06:51,590
Takže to je to trochu, jak to vypadá.

1527
01:06:51,590 --> 01:06:53,580
A to je přímo z jejich týmu.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB snižuje jejich
dodací lhůta pro video události

1529
01:06:56,010 --> 01:06:57,590
od pěti do 10 sekund.

1530
01:06:57,590 --> 01:07:00,470
Ve svém starém relační obchodě,
oni používali muset jít a vykonat

1531
01:07:00,470 --> 01:07:03,780
více složité dotazy k obrázku
out, která videa strhnout,

1532
01:07:03,780 --> 01:07:06,690
do méně než 50 milisekund.

1533
01:07:06,690 --> 01:07:08,990
Takže je to úžasné, úžasné,
jak moc výkon

1534
01:07:08,990 --> 01:07:12,990
můžete získat, když optimalizovat a
ladíte podkladové databáze

1535
01:07:12,990 --> 01:07:15,110
podporovat přístup vzor.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, tihle kluci, co to je,
Fruit Ninja Myslím, že je jejich věc.

1537
01:07:20,500 --> 01:07:22,590
Že všechny běží na Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
A tito lidé, oni jsou skvělý
Vývojový tým, velký rozvoj

1539
01:07:26,810 --> 01:07:27,670
nakupovat.

1540
01:07:27,670 --> 01:07:29,364
>> To není dobrý ops tým.

1541
01:07:29,364 --> 01:07:31,280
Neměli mnoho
provozních prostředků.

1542
01:07:31,280 --> 01:07:33,940
Oni byli snaží se snaží udržet
jejich aplikační infrastruktury up

1543
01:07:33,940 --> 01:07:34,290
a běží.

1544
01:07:34,290 --> 01:07:35,000
Přišli k nám.

1545
01:07:35,000 --> 01:07:36,251
Dívali se na tomto Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Říkali, že je to pro nás.

1547
01:07:37,291 --> 01:07:39,470
Oni stavěli jejich celek
aplikační framework na to.

1548
01:07:39,470 --> 01:07:43,640
Některé opravdu pěkné komentáře zde
z týmu na jejich schopnosti

1549
01:07:43,640 --> 01:07:46,800
se nyní zaměřují na budování
hra a ne

1550
01:07:46,800 --> 01:07:49,010
nutnosti udržení
infrastruktura, která

1551
01:07:49,010 --> 01:07:51,910
stal se obrovské množství
režie pro jejich tým.

1552
01:07:51,910 --> 01:07:56,170
Takže to je něco, co that--
užitek, že dostanete od Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Dobře, jak se dostat do
modelování dat zde.

1554
01:08:00,930 --> 01:08:03,440
A mluvili jsme trochu o
to jedna ku jedné, kdo mnoho,

1555
01:08:03,440 --> 01:08:05,060
a mnoho mnoho vztahů typu.

1556
01:08:05,060 --> 01:08:07,630
A jak si udržet ty v Dynamu.

1557
01:08:07,630 --> 01:08:10,500
V Dynamo DB používáme
indexy, obecně řečeno,

1558
01:08:10,500 --> 01:08:12,910
k otáčení data z
jednu příchuť do druhé.

1559
01:08:12,910 --> 01:08:15,210
Hash klíče, rozsah klíče a indexy.

1560
01:08:15,210 --> 01:08:18,540
>> V tomto konkrétním
Například, jak je většině států

1561
01:08:18,540 --> 01:08:23,802
mají požadavek licenci, která
pouze jeden řidičský průkaz na osobu.

1562
01:08:23,802 --> 01:08:26,510
Nemůžete jít do dostat řidiče dvou je
licencí ve státě Bostonu.

1563
01:08:26,510 --> 01:08:27,500
Nemohu to udělat v Texasu.

1564
01:08:27,500 --> 01:08:28,708
Je to něco, jak to je.

1565
01:08:28,708 --> 01:08:32,779
A tak na DMV, máme vyhledávání, my
Chcete se podívat na řidiče licenci

1566
01:08:32,779 --> 01:08:35,180
počtem sociálního zabezpečení.

1567
01:08:35,180 --> 01:08:39,990
Chci se podívat do podrobnosti uživatele
licenční číslo řidiče.

1568
01:08:39,990 --> 01:08:43,620
>> Takže bychom mohli mít tabulku uživatele, že
Má hash klíč na sériové číslo,

1569
01:08:43,620 --> 01:08:47,830
nebo číslo sociálního zabezpečení, a
různé atributy definovány na položku.

1570
01:08:47,830 --> 01:08:49,859
Nyní na této tabulce I
by mohlo definovat, který GSI

1571
01:08:49,859 --> 01:08:53,370
vyletí, že kolem toho říká, že chci,
hash klíč na licenci a pak

1572
01:08:53,370 --> 01:08:54,252
všechny ostatní položky.

1573
01:08:54,252 --> 01:08:57,210
A teď, když chci, aby dotaz a najít
licenční číslo pro danou sociální

1574
01:08:57,210 --> 01:08:59,609
Bezpečnostní číslo, mohu
dotaz na hlavní tabulky.

1575
01:08:59,609 --> 01:09:02,130
>> Pokud chci, aby dotaz a já chci
dostat sociálního zabezpečení

1576
01:09:02,130 --> 01:09:05,735
číslo nebo jiné atributy tavnou
licenční číslo, mohu dotaz GSI.

1577
01:09:05,735 --> 01:09:08,689
Tento model je, že jeden
do jednoho vztahu.

1578
01:09:08,689 --> 01:09:12,460
Jen velmi jednoduchý GSI,
otočit ty věci kolem sebe.

1579
01:09:12,460 --> 01:09:13,979
Nyní, mluvit o tom, kdo mnoho.

1580
01:09:13,979 --> 01:09:16,450
Jedním z mnoha je v zásadě
Váš hash rozsah klíč.

1581
01:09:16,450 --> 01:09:20,510
Tam, kde jsme si hodně s tímto
use case jsou data monitoru.

1582
01:09:20,510 --> 01:09:23,880
Data Monitor je dodáván v pravidelné
interval, jako je internet věcí.

1583
01:09:23,880 --> 01:09:26,890
Vždycky jsme si všechny tyto
Záznamy přichází po celou dobu.

1584
01:09:26,890 --> 01:09:31,420
>> A já chci najít všechny údaje
mezi konkrétní časové období.

1585
01:09:31,420 --> 01:09:34,220
Je to velmi časté dotazu
monitoring infrastruktury.

1586
01:09:34,220 --> 01:09:38,430
Způsob, jakým jít o to je najít
jednoduchá struktura tabulky, jedna tabulka.

1587
01:09:38,430 --> 01:09:42,250
Mám tabulku měr zařízení
s křížkem na ID zařízení.

1588
01:09:42,250 --> 01:09:47,340
A mám rozsah klíč na straně
timestamp, nebo v tomto případě, epos.

1589
01:09:47,340 --> 01:09:50,350
A to mi umožňuje provádět složité
dotazy vůči které sahají klíče

1590
01:09:50,350 --> 01:09:54,950
a vrátit ty záznamy, které
jsou vztaženy k výsledku

1591
01:09:54,950 --> 01:09:56,310
nastavit, že jsem hledal.

1592
01:09:56,310 --> 01:09:58,360
A to, že jeden buduje
mnoha vztah

1593
01:09:58,360 --> 01:10:02,340
do primární tabulky pomocí
křížkem, rozsah klíčová struktura.

1594
01:10:02,340 --> 01:10:04,600
>> Takže to trochu postavený
do tabulky v Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Když jsem se definovat hash
a rozsah t stůl, já jsem

1596
01:10:07,290 --> 01:10:09,240
definování jednoho k mnoha vztah.

1597
01:10:09,240 --> 01:10:12,770
Je to vztah rodič-dítě.

1598
01:10:12,770 --> 01:10:14,620
>> Pojďme se bavit o mnoho
mnoha vztahů.

1599
01:10:14,620 --> 01:10:19,170
A pro tento konkrétní příklad,
znovu, budeme používat GSI je.

1600
01:10:19,170 --> 01:10:23,500
A pojďme mluvit o hraní
scénář, kde mám daného uživatele.

1601
01:10:23,500 --> 01:10:26,500
Chci zjistit všechny hry, které
on je zapsána pro nebo hraní v.

1602
01:10:26,500 --> 01:10:29,600
A pro danou hru, já
Chcete najít všechny uživatele.

1603
01:10:29,600 --> 01:10:31,010
Tak jak to mám udělat?

1604
01:10:31,010 --> 01:10:34,330
Můj uživatelský hry stůl, jdu
mít hash klíč ID uživatele

1605
01:10:34,330 --> 01:10:35,810
a rozsah klíč hry.

1606
01:10:35,810 --> 01:10:37,810
>> Uživatel tedy může mít více her.

1607
01:10:37,810 --> 01:10:41,380
Je to, kdo mnoha vztah mezi
Uživatel a hry hraje.

1608
01:10:41,380 --> 01:10:43,410
A pak na GSI,
Budu překlopit, že kolem.

1609
01:10:43,410 --> 01:10:46,679
Budu hash na hru a
Budu se pohybují na uživatele.

1610
01:10:46,679 --> 01:10:48,970
Takže pokud chci, aby si všechny
Hra uživatele hraje v,

1611
01:10:48,970 --> 01:10:49,950
Budu dotaz hlavní tabulky.

1612
01:10:49,950 --> 01:10:52,699
Pokud chci, aby si všechny uživatele
které hrají určitou hru,

1613
01:10:52,699 --> 01:10:53,887
Já dotaz GSI.

1614
01:10:53,887 --> 01:10:54,970
Tak vidíte, jak to uděláme?

1615
01:10:54,970 --> 01:10:58,369
Stavíte na podporu těchto GSI je
případ použití, aplikace, přístup

1616
01:10:58,369 --> 01:10:59,410
vzor, ​​žádost.

1617
01:10:59,410 --> 01:11:01,440
>> Pokud je potřeba, aby na dotaz
tato dimenze, nechť

1618
01:11:01,440 --> 01:11:03,500
me vytvořit index na této dimenzi.

1619
01:11:03,500 --> 01:11:05,850
Pokud nemám, je mi to jedno.

1620
01:11:05,850 --> 01:11:09,060
A v závislosti na use case, já
může potřebovat indexu, nebo já taky ne.

1621
01:11:09,060 --> 01:11:12,390
Pokud je to jednoduchý pro mnohé,
primární tabulky je v pořádku.

1622
01:11:12,390 --> 01:11:15,860
Pokud je potřeba, aby se tyto mnoho
Mnoho je, nebo musím udělat jeden až ty,

1623
01:11:15,860 --> 01:11:18,390
pak možná Já potřebuji
na druhé místo index.

1624
01:11:18,390 --> 01:11:20,840
Takže to vše závisí na tom,
co se snažím dělat

1625
01:11:20,840 --> 01:11:24,550
a to, co se snažím dostat dokonalý.

1626
01:11:24,550 --> 01:11:28,000
>> Asi nebudu trávit moc
mnoho času mluví o dokumentech.

1627
01:11:28,000 --> 01:11:31,460
To dostane trochu, pravděpodobně,
hlouběji, než musíme jít do.

1628
01:11:31,460 --> 01:11:33,710
Mluvme trochu
o bohatý výraz dotazu.

1629
01:11:33,710 --> 01:11:37,831
Takže Dynamo DB máme
schopnost vytvořit

1630
01:11:37,831 --> 01:11:39,330
to, čemu říkáme projekce výrazy.

1631
01:11:39,330 --> 01:11:42,660
Projekční výrazy jsou jednoduše
vybírání pole nebo hodnot

1632
01:11:42,660 --> 01:11:44,290
které chcete zobrazit.

1633
01:11:44,290 --> 01:11:46,000
OK, tak jsem udělat výběr.

1634
01:11:46,000 --> 01:11:48,010
Dělám dotazu proti Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
A já říkám, víš co, show
jen mi pět hvězd recenze

1636
01:11:51,730 --> 01:11:54,544
pro tento konkrétní výrobek.

1637
01:11:54,544 --> 01:11:55,710
Tak to je vše, co chci vidět.

1638
01:11:55,710 --> 01:11:57,320
Nechci vidět všechny
další atributy řádku,

1639
01:11:57,320 --> 01:11:58,319
Jen chci vidět.

1640
01:11:58,319 --> 01:12:01,209
Je to jako v SQL, když jste
říkají, vyberte hvězdy nebo z tabulky,

1641
01:12:01,209 --> 01:12:02,000
dostanete vše.

1642
01:12:02,000 --> 01:12:05,450
Když říkám, vyberte jméno ze
stůl, jen jsem si jeden atribut.

1643
01:12:05,450 --> 01:12:09,070
Je to stejný druh věci v
Dynamo DB nebo jiný databází NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Filtr výrazy mi dovolte, abych se
v podstatě snížit sadu výsledků dolů.

1645
01:12:14,510 --> 01:12:15,540
Tak jsem se, aby se dotaz.

1646
01:12:15,540 --> 01:12:17,260
Dotaz může vrátit s 500 položkami.

1647
01:12:17,260 --> 01:12:20,255
Ale já jsem jen chtějí, aby položky, které
mají atribut, který říká, že tento.

1648
01:12:20,255 --> 01:12:23,380
OK, takže pojďme odfiltrovat ty položky,
které se neshodují, že konkrétní dotaz.

1649
01:12:23,380 --> 01:12:25,540
Takže máme výrazy filtru.

1650
01:12:25,540 --> 01:12:28,310
>> Filtr výrazy mohou
lze spustit na každém atributu.

1651
01:12:28,310 --> 01:12:30,260
Jsou to nebude líbit rozsah dotazy.

1652
01:12:30,260 --> 01:12:32,690
Vyvolávají otázky jsou více selektivní.

1653
01:12:32,690 --> 01:12:36,470
Filtr dotazy vyžadují, abych šel
Získejte Kompletní výsledky nastavit a poté

1654
01:12:36,470 --> 01:12:39,170
vybojovat data nechci.

1655
01:12:39,170 --> 01:12:40,660
Proč je to důležité?

1656
01:12:40,660 --> 01:12:42,770
Vzhledem k tomu, Četl jsem to všechno.

1657
01:12:42,770 --> 01:12:46,597
V dotazu, budu číst a
že to bude obrovský o datech.

1658
01:12:46,597 --> 01:12:48,430
A pak budu
vybojovat co potřebuji.

1659
01:12:48,430 --> 01:12:52,080
A když já jsem jen vybojovat
pár řádků, pak je to v pořádku.

1660
01:12:52,080 --> 01:12:53,620
Není to tak neefektivní.

1661
01:12:53,620 --> 01:12:57,800
>> Ale když jsem četl celou hromadu
Údaje, jen aby vybojovat jednu položku,

1662
01:12:57,800 --> 01:13:01,490
Pak jsem se chystám být lepší
vypnout pomocí dotazu rozsah,

1663
01:13:01,490 --> 01:13:03,030
protože je to mnohem vybíravější.

1664
01:13:03,030 --> 01:13:06,330
Bude to mi ušetřit spoustu
peníze, protože jsem za to zaplatit čtení.

1665
01:13:06,330 --> 01:13:10,430
V případě, že výsledky, které přichází zpět
kříž, že drát může být nižší,

1666
01:13:10,430 --> 01:13:11,890
ale já jsem platit za čtení.

1667
01:13:11,890 --> 01:13:14,340
Tak pochopit, jak
jste dostat data.

1668
01:13:14,340 --> 01:13:16,420
To je velmi důležité v Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Podmíněné výrazy, to je to, co
by se dalo nazvat optimistické zamykání.

1670
01:13:19,710 --> 01:13:28,470
Aktualizaci, pokud existuje, nebo pokud je tato hodnota
je ekvivalentní tomu, co jsem specifikovat.

1671
01:13:28,470 --> 01:13:31,494
A když mám časové razítko na
rekord, mohl bych číst data.

1672
01:13:31,494 --> 01:13:32,535
I se může změnit, že data.

1673
01:13:32,535 --> 01:13:35,030
Mohl bych jít psát, že
data zpět do databáze.

1674
01:13:35,030 --> 01:13:38,100
Pokud někdo změnil záznam,
časové razítko mohly změnit.

1675
01:13:38,100 --> 01:13:40,370
A takhle můj podmíněné
Aktualizace by se říci aktualizace

1676
01:13:40,370 --> 01:13:42,340
v případě, že se rovná této časové razítko.

1677
01:13:42,340 --> 01:13:46,290
Nebo aktualizace nezdaří, protože někdo
aktualizováno záznam v mezidobí.

1678
01:13:46,290 --> 01:13:48,290
>> To je to, co nazýváme optimistické zamykání.

1679
01:13:48,290 --> 01:13:50,670
To znamená, že někdo
může přijít a změnit to,

1680
01:13:50,670 --> 01:13:53,100
a budu detekovat
když jsem se vrátit do psát.

1681
01:13:53,100 --> 01:13:56,106
A pak jsem si skutečně četl, že
dat a říkají, ach, on změnil to.

1682
01:13:56,106 --> 01:13:57,230
Potřebuji účet za to.

1683
01:13:57,230 --> 01:14:00,490
A mohu změnit údaje v mém
nahrát a aplikovat další aktualizaci.

1684
01:14:00,490 --> 01:14:04,330
Takže si můžete chytit ty přírůstkové
Aktualizace, které se vyskytují v době mezi

1685
01:14:04,330 --> 01:14:08,740
že budete číst data a
Čas můžete zapsat data.

1686
01:14:08,740 --> 01:14:11,520
>> Diváků: A filtr
Výraz vlastně znamená ne

1687
01:14:11,520 --> 01:14:13,020
v počtu nebo ne--

1688
01:14:13,020 --> 01:14:14,316
>> [Vložením hlasy]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: Nebudu
příliš mnoho na to.

1690
01:14:16,232 --> 01:14:17,700
To je rezervované klíčové slovo.

1691
01:14:17,700 --> 01:14:20,130
Pohled libra je vyhrazeno
klíčové slovo v Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Každá databáze má své vlastní vyhrazené
Jména pro vymáhání pohledávek nelze použít.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, pokud zadáte
libru před touto,

1694
01:14:27,240 --> 01:14:29,310
můžete definovat tyto názvy nahoře.

1695
01:14:29,310 --> 01:14:31,840
Toto je odkazováno hodnota.

1696
01:14:31,840 --> 01:14:34,880
Je to asi není nejlepší syntaxi
mají tam pro tuto diskusi,

1697
01:14:34,880 --> 01:14:38,090
proto, že se dostane do některých real--
Byl bych mluvil více

1698
01:14:38,090 --> 01:14:41,360
o, že na hlubší úrovni.

1699
01:14:41,360 --> 01:14:46,130
>> Ale stačí říct, mohlo by to
být dotaz skenovat, kde views--

1700
01:14:46,130 --> 01:14:50,190
ani názory libra je větší než 10.

1701
01:14:50,190 --> 01:14:54,660
Je to číselná hodnota, ano.

1702
01:14:54,660 --> 01:14:57,322
Chcete-li, můžeme hovořit o
že po diskusi.

1703
01:14:57,322 --> 01:15:00,030
Dobře, takže se dostáváme do
některé scénáře v osvědčených postupech

1704
01:15:00,030 --> 01:15:02,000
kam jdeme mluvit
o některých aplikací zde.

1705
01:15:02,000 --> 01:15:03,810
Jaké jsou případy použití pro Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Jaké jsou konstrukce
vzory v Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> A první, kdo budeme
mluvit o je internet věcí.

1708
01:15:09,110 --> 01:15:15,010
Tak jsme si hodně of-- myslím,
co je to-- více než 50%

1709
01:15:15,010 --> 01:15:19,370
provozu na internetu v těchto dnech
je skutečně vyrobené pomocí strojů,

1710
01:15:19,370 --> 01:15:21,930
automatizované procesy, které nejsou lidmi.

1711
01:15:21,930 --> 01:15:25,140
Mám na mysli tuto věc tuto věc, která se
budete nosit v kapse,

1712
01:15:25,140 --> 01:15:28,840
kolik dat, která je ta věc
vlastně posílá kolem bez tebe

1713
01:15:28,840 --> 01:15:30,550
s vědomím, že je naprosto úžasné.

1714
01:15:30,550 --> 01:15:34,970
Vaše poloha, informace
o tom, jak rychle se budete.

1715
01:15:34,970 --> 01:15:38,400
Jak myslíš, že Google Maps díla
když ti, co je provoz.

1716
01:15:38,400 --> 01:15:41,275
Je to proto, že tam jsou miliony a
miliony lidí jezdí po

1717
01:15:41,275 --> 01:15:44,667
s telefony, které jsou odesílání
Údaje celé místo po celou dobu.

1718
01:15:44,667 --> 01:15:46,500
Takže jedna z věcí
o údaje tohoto druhu

1719
01:15:46,500 --> 01:15:50,980
že přijde, údaje přístroje, přihlaste
údaje, časové řady, je, že je

1720
01:15:50,980 --> 01:15:53,540
obvykle jen zajímavý
na trochu času.

1721
01:15:53,540 --> 01:15:55,580
Po uplynutí této doby, to je
není tak zajímavé.

1722
01:15:55,580 --> 01:15:58,390
Tak jsme mluvili o, nenechte
tyto tabulky růst bez hranic.

1723
01:15:58,390 --> 01:16:03,410
Myšlenka je, že možná mám 24
hodiny v hodnotě událostí v mé horké tabulce.

1724
01:16:03,410 --> 01:16:06,160
A to horký tabulka bude
opravná položka ve velmi vysoké rychlosti,

1725
01:16:06,160 --> 01:16:07,950
protože to trvá hodně dat.

1726
01:16:07,950 --> 01:16:10,920
Trvá to velké množství dat
a já jsem to četl hodně.

1727
01:16:10,920 --> 01:16:14,560
Mám spoustu provozu
Dotazy spuštěné vůči této dat.

1728
01:16:14,560 --> 01:16:18,120
>> Po 24 hodinách, hej, ty
Víš co, je mi to jedno.

1729
01:16:18,120 --> 01:16:21,150
Takže možná každý I role půlnoci
můj stůl se k nové tabulky

1730
01:16:21,150 --> 01:16:22,430
a já deprovision tuto tabulku.

1731
01:16:22,430 --> 01:16:26,440
A já si vezmu RCU je a
WCU je dolů, protože o 24 hodin později

1732
01:16:26,440 --> 01:16:28,630
Nejsem běží tolik
dotazy vůči těmto údajům.

1733
01:16:28,630 --> 01:16:30,200
Takže budu spořit.

1734
01:16:30,200 --> 01:16:32,940
A možná 30 dní později, vůbec se mi nelíbí
ani potřeba se starat o to všechno.

1735
01:16:32,940 --> 01:16:35,020
Mohl bych vzít WCU je
celou cestu dolů na jeden,

1736
01:16:35,020 --> 01:16:36,990
proto, že víte, co je to
nikdy dostat zapisovat.

1737
01:16:36,990 --> 01:16:38,300
Data jsou 30 dní stará.

1738
01:16:38,300 --> 01:16:40,000
To se nikdy nezmění.

1739
01:16:40,000 --> 01:16:44,200
>> A to téměř nikdy dostane číst,
tak ať to prostě přijmout, že RCU až 10.

1740
01:16:44,200 --> 01:16:49,372
A Šetřím tuny peněz na to
Data, a to pouze platit za mé horké dat.

1741
01:16:49,372 --> 01:16:52,330
Tak to je důležité se podívat
u, když se podíváte na časové řady

1742
01:16:52,330 --> 01:16:54,716
Data přicházet v objemu.

1743
01:16:54,716 --> 01:16:55,590
Jsou to strategie.

1744
01:16:55,590 --> 01:16:58,010
Teď jsem mohl jen nechat to
všichni do jednoho stolu

1745
01:16:58,010 --> 01:16:59,461
a nechat že tabulka růst.

1746
01:16:59,461 --> 01:17:01,460
Nakonec budu
viz problémy s výkonem.

1747
01:17:01,460 --> 01:17:04,060
Budu muset začít do archivu
některé z těchto dat mimo stůl,

1748
01:17:04,060 --> 01:17:04,720
co ne.

1749
01:17:04,720 --> 01:17:07,010
>> Pojďme mnohem lépe
navrhněte aplikaci

1750
01:17:07,010 --> 01:17:08,900
takže můžete ovládat tímto způsobem pravdu.

1751
01:17:08,900 --> 01:17:11,460
Takže je to jen automatické
v kódu aplikace.

1752
01:17:11,460 --> 01:17:13,580
O půlnoci každý večer
to valí tabulku.

1753
01:17:13,580 --> 01:17:17,170
Možná, že to, co potřebujete, je posuvná
Okno 24 hodin dat.

1754
01:17:17,170 --> 01:17:20,277
Pak se pravidelně, že jsem
volat data z tabulky.

1755
01:17:20,277 --> 01:17:22,360
Jsem ořezávání to s
Cronu a já jsem ho uvedení

1756
01:17:22,360 --> 01:17:24,160
na těchto jiných tabulek,
co budete potřebovat.

1757
01:17:24,160 --> 01:17:25,940
Takže pokud převrácení funguje, to je skvělé.

1758
01:17:25,940 --> 01:17:27,080
Pokud ne, trim to.

1759
01:17:27,080 --> 01:17:29,640
Ale pojďme si tu horký údaje
od svých chladných dat.

1760
01:17:29,640 --> 01:17:32,535
To vám ušetří spoustu peněz a
Udělej si svůj tabulek více vede.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Takže další věc, kterou budeme mluvit
o tom, je katalog výrobků.

1763
01:17:38,210 --> 01:17:42,000
Katalog je
docela obyčejný případ použití.

1764
01:17:42,000 --> 01:17:46,600
To je vlastně velmi časté vzor
že uvidíme v řadě věcí.

1765
01:17:46,600 --> 01:17:48,870
Víte, pro Twitter
Příkladem, horký tweet.

1766
01:17:48,870 --> 01:17:51,280
Každý, kdo přijde a
popadl ten tweet.

1767
01:17:51,280 --> 01:17:52,680
Katalog, mám prodeje.

1768
01:17:52,680 --> 01:17:54,120
Dostal jsem horký prodeje.

1769
01:17:54,120 --> 01:17:57,277
Mám 70.000 žádostí za
druhý příchod pro výrobek

1770
01:17:57,277 --> 01:17:58,860
popis z mého katalogu výrobků.

1771
01:17:58,860 --> 01:18:02,384
Vidíme to na maloobchodním
Provoz docela dost.

1772
01:18:02,384 --> 01:18:03,550
Tak jak jsme se s tím vypořádat?

1773
01:18:03,550 --> 01:18:04,924
Neexistuje žádný způsob, jak se s tím vypořádat.

1774
01:18:04,924 --> 01:18:07,110
Všichni moji uživatelé chtějí vidět
stejný údaj.

1775
01:18:07,110 --> 01:18:09,410
Oni přicházejí, souběžně.

1776
01:18:09,410 --> 01:18:11,920
A oni jsou všichni dělat žádosti
za stejný kus dat.

1777
01:18:11,920 --> 01:18:16,240
To mi dává, že horké klávesy, že velké červené
pruh na mém grafu, které se nám nelíbí.

1778
01:18:16,240 --> 01:18:17,720
A to je to, co to vypadá.

1779
01:18:17,720 --> 01:18:22,290
Takže přes můj klíčový prostor Dostávám
kladivem v prodeji položky.

1780
01:18:22,290 --> 01:18:24,070
Začínám nic nikde jinde.

1781
01:18:24,070 --> 01:18:26,050
>> Jak mám tento problém zmírnit?

1782
01:18:26,050 --> 01:18:28,410
No, my zmírnit to s cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, dáte v podstatě v paměti
partition v přední části databáze.

1784
01:18:33,630 --> 01:18:37,260
Podařilo se
[Neslyšitelný] cache, jak vás

1785
01:18:37,260 --> 01:18:40,260
Můžete nastavit vlastní cache, [neslyšitelných]
mezipaměť [? d,?], co chcete.

1786
01:18:40,260 --> 01:18:42,220
Dát, že se před databáze.

1787
01:18:42,220 --> 01:18:47,250
A to způsob, jak můžete ukládat, že data
z těchto horkých kláves až v této paměti cache

1788
01:18:47,250 --> 01:18:49,390
prostor a přečtěte si cache.

1789
01:18:49,390 --> 01:18:51,962
>> A pak s největší vašich čte
začít hledat takhle.

1790
01:18:51,962 --> 01:18:54,920
Dostal jsem všechny tyto keše sem
a já nemám nic v cestě sem

1791
01:18:54,920 --> 01:18:59,330
protože databáze je usednutí za
mezipaměti a čte se nikdy projít.

1792
01:18:59,330 --> 01:19:02,520
Když změním údaje do systému
databáze, musím aktualizovat mezipaměť.

1793
01:19:02,520 --> 01:19:04,360
Můžeme použít něco
jako par to udělat.

1794
01:19:04,360 --> 01:19:07,360
A já vám vysvětlím, jak to funguje.

1795
01:19:07,360 --> 01:19:09,060
Dobře, zasílání zpráv.

1796
01:19:09,060 --> 01:19:11,180
E-mail, my všichni používat e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> To je docela dobrý příklad.

1798
01:19:12,540 --> 01:19:14,950
Máme nějaký zpráv tabulky.

1799
01:19:14,950 --> 01:19:17,040
A my jsme dostali složky Doručená pošta a Pošta k odeslání.

1800
01:19:17,040 --> 01:19:19,760
To je to, co by SQL
vypadat jako na stavět, že e-mailové schránky.

1801
01:19:19,760 --> 01:19:23,350
Jsme trochu používají stejný druh
strategie použít GSI, GSI je

1802
01:19:23,350 --> 01:19:25,320
pro mé e-mailové schránky a můj Pošta k odeslání.

1803
01:19:25,320 --> 01:19:27,600
Tak jsem se dostal syrové zprávy přicházející
do mé zprávy tabulky.

1804
01:19:27,600 --> 01:19:30,194
A první přístup k této
by mohlo být, řekněme, v pořádku, žádný problém.

1805
01:19:30,194 --> 01:19:31,110
Mám syrové zprávy.

1806
01:19:31,110 --> 01:19:33,710
Zprávy přicházející [neslyšitelných],
ID zprávy, to je skvělé.

1807
01:19:33,710 --> 01:19:35,070
To je můj unikátní hash.

1808
01:19:35,070 --> 01:19:38,280
Chystám se vytvořit dvěma GSI je, jeden
pro mé e-mailové schránky, jeden pro mou Pošta k odeslání.

1809
01:19:38,280 --> 01:19:40,530
A první věc, kterou udělám
je Řeknu můj hash klíč

1810
01:19:40,530 --> 01:19:43,310
Bude příjemce a
Jdu zařídit dnem.

1811
01:19:43,310 --> 01:19:44,220
To je fantastické.

1812
01:19:44,220 --> 01:19:45,890
Já tady mám pěkný výhled.

1813
01:19:45,890 --> 01:19:47,780
Ale je to trochu problém zde.

1814
01:19:47,780 --> 01:19:50,891
A se dostanete do toho
relační databáze stejně.

1815
01:19:50,891 --> 01:19:52,390
Říkali vertikálně dělení.

1816
01:19:52,390 --> 01:19:55,840
Chcete, aby se vaše zpracování velkých objemů dat
od svých malých dat.

1817
01:19:55,840 --> 01:20:00,470
>> A důvod, proč je, protože musím
go číst položky, které chcete získat atributy.

1818
01:20:00,470 --> 01:20:05,570
A pokud moje těla jsou všichni tady,
pak čte jen několik položek

1819
01:20:05,570 --> 01:20:08,560
když moje tělo je délka
v průměru 256 kilobajtů každý,

1820
01:20:08,560 --> 01:20:10,991
matematický dostane docela ošklivý.

1821
01:20:10,991 --> 01:20:12,490
Takže říct, že chcete přečíst Davidův e-mailové schránky.

1822
01:20:12,490 --> 01:20:14,520
Davidova Doručená pošta má 50 položek.

1823
01:20:14,520 --> 01:20:17,880
Průměrná a velikost je 256 kB.

1824
01:20:17,880 --> 01:20:21,730
Tady je můj konverzní poměr
pro RCU je je čtyři kilobajtů.

1825
01:20:21,730 --> 01:20:24,450
>> OK, pojďme se
nakonec konzistentní čte.

1826
01:20:24,450 --> 01:20:28,640
Jsem stále jíst 1600 RCU je
jen ke čtení Davidův e-mailové schránky.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
OK, teď pojďme přemýšlet
o tom, jak aplikace funguje.

1829
01:20:31,980 --> 01:20:35,340
Pokud jsem v e-mailové aplikaci a
Dívám se na mé e-mailové schránky,

1830
01:20:35,340 --> 01:20:39,680
a já se na tělo každé zprávy,
Ne, já jsem při pohledu na shrnutí.

1831
01:20:39,680 --> 01:20:41,850
Dívám se na pouze hlavičky.

1832
01:20:41,850 --> 01:20:46,310
Takže pojďme postavit strukturu tabulky
že vypadá takhle.

1833
01:20:46,310 --> 01:20:49,470
>> Tak tady je informace
že moje workflow potřebuje.

1834
01:20:49,470 --> 01:20:50,890
Je to v mé e-mailové schránky GSI.

1835
01:20:50,890 --> 01:20:53,800
Je to datum, odesílatel,
předmět, a poté

1836
01:20:53,800 --> 01:20:56,790
ID zprávy, které body
zpět ke stolu zpráv

1837
01:20:56,790 --> 01:20:57,850
kde bych mohl dostat tělo.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
No, to by bylo rekordní ID.

1840
01:21:04,420 --> 01:21:09,850
Oni by ukazovat zpět do
položka ID na stole Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Každý index vždy creates--
má vždy položku

1842
01:21:12,220 --> 01:21:15,750
ID jako součást of-- že
přichází s indexem.

1843
01:21:15,750 --> 01:21:17,414
>> Dobře.

1844
01:21:17,414 --> 01:21:19,080
Diváků: Je to o tom, kde je uložen?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Ano, je to říká
exactly--, že je to přesně to, co dělá.

1846
01:21:21,420 --> 01:21:22,644
To říká, že tady je moje re rekord.

1847
01:21:22,644 --> 01:21:24,310
A to bude ukazovat ji zpátky do svého opětovného záznamu.

1848
01:21:24,310 --> 01:21:26,460
Přesně.

1849
01:21:26,460 --> 01:21:29,490
OK, tak teď moje schránka
ve skutečnosti mnohem menší.

1850
01:21:29,490 --> 01:21:32,210
A to vlastně podporuje
pracovního postupu z e-mailové aplikace.

1851
01:21:32,210 --> 01:21:34,230
Takže mé e-mailové schránky, jsem klepněte na tlačítko.

1852
01:21:34,230 --> 01:21:38,160
Jdu dál a já klikněte na zprávu,
to je, když musím jít pro tělo,

1853
01:21:38,160 --> 01:21:40,180
protože budu
přejít do jiného pohledu.

1854
01:21:40,180 --> 01:21:43,870
Takže pokud si myslíte, že o typu MVC města
rámec, pohled modelu regulátoru.

1855
01:21:43,870 --> 01:21:46,120
>> Tento model obsahuje
údaje, které potřebuje pohled

1856
01:21:46,120 --> 01:21:48,130
a regulátor interaguje s.

1857
01:21:48,130 --> 01:21:51,670
Když jsem se změnit rám, kdy
I změnit perspektivu,

1858
01:21:51,670 --> 01:21:55,080
to je v pořádku se vrátit do
Server a repopulate modelu,

1859
01:21:55,080 --> 01:21:56,860
protože to je to, co uživatel očekává.

1860
01:21:56,860 --> 01:22:00,530
Když se změní zobrazení, to je, když
můžeme jít zpět do databáze.

1861
01:22:00,530 --> 01:22:02,480
Tak e-mail, klepněte na tlačítko.

1862
01:22:02,480 --> 01:22:03,710
Hledám pro tělo.

1863
01:22:03,710 --> 01:22:04,330
Okružní výlet.

1864
01:22:04,330 --> 01:22:05,680
Jdi tělo.

1865
01:22:05,680 --> 01:22:06,950
>> Četl jsem hodně méně dat.

1866
01:22:06,950 --> 01:22:09,960
Já jsem jen čtení orgánů, které
David potřebuje, když je potřebuje.

1867
01:22:09,960 --> 01:22:14,230
A já nejsem hořet v roce 1600
RCU prostě ukázat své e-mailové schránky.

1868
01:22:14,230 --> 01:22:17,670
Takže teď that-- je to způsob,
že LSI nebo GSI-- Je mi to líto,

1869
01:22:17,670 --> 01:22:19,900
GSI, bude fungovat.

1870
01:22:19,900 --> 01:22:25,450
Máme naši hash na příjemce.

1871
01:22:25,450 --> 01:22:27,030
Máme rozsah klíč na datu.

1872
01:22:27,030 --> 01:22:31,380
A máme plánované atributy
že musíme jen podporují názor.

1873
01:22:31,380 --> 01:22:34,300
>> Otočíme, že pro odchozích zpráv.

1874
01:22:34,300 --> 01:22:35,770
Hash odesílatele.

1875
01:22:35,770 --> 01:22:39,612
A v podstatě, máme
velmi pěkný, čistý výhled.

1876
01:22:39,612 --> 01:22:41,570
A je to basically-- jsme
už tuhle příjemnou zprávy

1877
01:22:41,570 --> 01:22:45,870
tabulka, která se šíří hezky, protože
je to jen hash, hash ID zprávy.

1878
01:22:45,870 --> 01:22:51,750
A máme dva indexy, které
se otáčejí z této tabulky.

1879
01:22:51,750 --> 01:22:57,411
Dobře, takže myšlenka tady je ne
uchovávat velké data a tento malý údaje

1880
01:22:57,411 --> 01:22:57,910
spolu.

1881
01:22:57,910 --> 01:23:00,700
Rozdělit svisle,
rozdělit ty tabulky.

1882
01:23:00,700 --> 01:23:03,150
Nečtěte data, nemusíte.

1883
01:23:03,150 --> 01:23:04,850
Dobře, herní.

1884
01:23:04,850 --> 01:23:06,990
Všichni jsme rádi hry.

1885
01:23:06,990 --> 01:23:10,902
Alespoň se mi líbí hry poté.

1886
01:23:10,902 --> 01:23:12,735
Takže některé z věcí,
že se zabýváme, když

1887
01:23:12,735 --> 01:23:14,193
přemýšlíme o hraní, ne?

1888
01:23:14,193 --> 01:23:16,999
Herní těchto dnech, a to zejména mobilní
hraní her, je o myšlení.

1889
01:23:16,999 --> 01:23:19,540
A budu otáčet tady
trochu daleko od DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Jdu, aby v
některé z diskuse

1891
01:23:21,373 --> 01:23:24,240
kolem některých z
jiné technologie AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Ale myšlenka o hraní je myslet
o co se týče API, API, které jsou,

1893
01:23:28,930 --> 01:23:31,730
Obecně řečeno, HTTP a JSON.

1894
01:23:31,730 --> 01:23:34,550
Je to, jak mobilní hry druh
komunikovat s jejich zadními konci.

1895
01:23:34,550 --> 01:23:35,850
Oni dělají JSON vysílání.

1896
01:23:35,850 --> 01:23:40,660
Dostanou dat, a to je všechno,
Obecně řečeno, v pěkném JSON API.

1897
01:23:40,660 --> 01:23:44,950
>> Věci jako získat přátele, získat
leaderboard, vyměňovat data,

1898
01:23:44,950 --> 01:23:47,699
uživateli generovaný obsah,
tlačit zpět do systému,

1899
01:23:47,699 --> 01:23:49,740
se jedná o typy věcí
že budeme dělat.

1900
01:23:49,740 --> 01:23:52,542
Binární data aktiv, tato data
nemusí sedět v databázi.

1901
01:23:52,542 --> 01:23:54,250
To by mohlo sedět ve
objekt obchod, ne?

1902
01:23:54,250 --> 01:23:56,541
Ale databáze bude
skončit říká systému,

1903
01:23:56,541 --> 01:23:59,140
říká aplikace
kam jít si to.

1904
01:23:59,140 --> 01:24:03,550
A nevyhnutelně, multiplayer
servery, back end infrastruktury,

1905
01:24:03,550 --> 01:24:06,180
a určené pro vysoce
dostupnost a škálovatelnost.

1906
01:24:06,180 --> 01:24:09,400
To jsou věci, které chceme všichni
v herním infrastruktury dnes.

1907
01:24:09,400 --> 01:24:12,160
>> Takže pojďme se podívat na
jak to vypadá.

1908
01:24:12,160 --> 01:24:16,070
Mám základní zadní konec,
velmi jednoduché.

1909
01:24:16,070 --> 01:24:19,880
Máme systém, zde se
vícenásobné dostupnost zón.

1910
01:24:19,880 --> 01:24:23,780
Mluvili jsme o AZS as being-- myslíte
z nich jako samostatné datových center.

1911
01:24:23,780 --> 01:24:26,040
Více než jedna datová centra
per AZ, ale to je v pořádku,

1912
01:24:26,040 --> 01:24:28,831
jen myslet na nich jako samostatný dat
střediska, která jsou geograficky

1913
01:24:28,831 --> 01:24:30,090
a porucha izolované.

1914
01:24:30,090 --> 01:24:32,172
>> Budeme mít
instance pár EC2.

1915
01:24:32,172 --> 01:24:33,880
Budeme mít
někteří back end serveru.

1916
01:24:33,880 --> 01:24:35,800
Možná, pokud jste starší
architektura, my jsme

1917
01:24:35,800 --> 01:24:38,920
s použitím co nazýváme RDS,
relační databáze služby.

1918
01:24:38,920 --> 01:24:42,040
Mohl by to být MSSQL, MySQL,
nebo něco takového.

1919
01:24:42,040 --> 01:24:47,080
To je způsob, jak hodně aplikací
jsou navrženy tak dnes.

1920
01:24:47,080 --> 01:24:49,594
>> Tak bychom mohli chtít jít s
to je, když jsme škálování.

1921
01:24:49,594 --> 01:24:51,510
Budeme pokračovat a dát
vědro S3 tam nahoře.

1922
01:24:51,510 --> 01:24:54,200
A to S3 lopaty, namísto porce
up těchto objektů z naší servers--

1923
01:24:54,200 --> 01:24:55,220
jsme mohli udělat.

1924
01:24:55,220 --> 01:24:57,210
Dáte všechny vaše binární
objekty na vašich serverech

1925
01:24:57,210 --> 01:24:59,751
a můžete použít ty serveru
instance sloužit, že data nahoru.

1926
01:24:59,751 --> 01:25:01,860
Ale to je dost drahé.

1927
01:25:01,860 --> 01:25:05,107
>> Lepší způsob, jak udělat, je jít dopředu a
dát tyto objekty v S3 kbelíku.

1928
01:25:05,107 --> 01:25:06,315
S3 je objekt úložiště.

1929
01:25:06,315 --> 01:25:10,860
Je postaven speciálně pro
servírují tyto typy věcí.

1930
01:25:10,860 --> 01:25:13,690
A ať tito klienti vyžádat
přímo z těchto objektů věder,

1931
01:25:13,690 --> 01:25:15,390
složit servery.

1932
01:25:15,390 --> 01:25:17,020
Takže začínáme měřítko tady.

1933
01:25:17,020 --> 01:25:19,140
>> Teď jsme se dostali uživatelů po celém světě.

1934
01:25:19,140 --> 01:25:19,730
Mám uživatelů.

1935
01:25:19,730 --> 01:25:23,380
Musím mít obsah lokálně
se nachází v blízkosti těchto uživatelů, ne?

1936
01:25:23,380 --> 01:25:26,200
Vytvořil jsem S3 kbelík
jako můj zdrojový úložiště.

1937
01:25:26,200 --> 01:25:29,370
A já budu vpředu, že s
distribuce CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront je CD a
content delivery network.

1939
01:25:31,720 --> 01:25:35,750
V podstatě to znamená data, která jste určili
a ukládá to všechno přes internet

1940
01:25:35,750 --> 01:25:39,230
takže uživatelé mohou mít všude
velmi rychlá odezva při

1941
01:25:39,230 --> 01:25:40,960
žádají o tyto objekty.

1942
01:25:40,960 --> 01:25:41,960
>> Tak dostanete nápad.

1943
01:25:41,960 --> 01:25:48,230
Jste typ pákového efektu všechny
aspekty AWS sem si to udělat.

1944
01:25:48,230 --> 01:25:50,790
A nakonec, vyhodíme
ve skupině auto škálování.

1945
01:25:50,790 --> 01:25:52,737
Takže naše případy AC2
našich herních serverů,

1946
01:25:52,737 --> 01:25:54,820
jak začnou dostat rušnější
a nabitější a rušnější,

1947
01:25:54,820 --> 01:25:57,236
oni si jen točit další
instance, točit další instanci,

1948
01:25:57,236 --> 01:25:58,210
točit další instanci.

1949
01:25:58,210 --> 01:26:02,090
Takže technologie AWS má, ho
umožňuje zadat parametry

1950
01:26:02,090 --> 01:26:04,650
kolem které vaše servery budou růst.

1951
01:26:04,650 --> 01:26:08,110
Takže můžete mít n počet serverů
tam u nějakého daného času.

1952
01:26:08,110 --> 01:26:11,870
A pokud váš náklad zmizí, oni budou
zmenšovat, číslo se bude zmenšovat.

1953
01:26:11,870 --> 01:26:15,250
A v případě, že zatížení vrátí,
to bude pěstovat zpět, pružně.

1954
01:26:15,250 --> 01:26:17,050
>> Tak to vypadá skvěle.

1955
01:26:17,050 --> 01:26:19,800
Máme spoustu instancí EC2.

1956
01:26:19,800 --> 01:26:21,671
Můžeme dát cache
front z databází,

1957
01:26:21,671 --> 01:26:23,045
pokusit se urychlit databází.

1958
01:26:23,045 --> 01:26:25,030
Příští tlakový bod
typicky lidé vidí

1959
01:26:25,030 --> 01:26:28,850
je, že měřítko hru pomocí
relační databázový systém.

1960
01:26:28,850 --> 01:26:30,790
Ježíši, databáze
výkon je hrozné.

1961
01:26:30,790 --> 01:26:31,932
Jak se můžeme zlepšit, že?

1962
01:26:31,932 --> 01:26:33,640
Zkusme uvedení
vyrovnávací paměti před, že.

1963
01:26:33,640 --> 01:26:36,780
>> No, mezipaměti nefunguje
tak skvělé hry, ne?

1964
01:26:36,780 --> 01:26:39,330
U her, psaní je bolestivé.

1965
01:26:39,330 --> 01:26:40,930
Hry jsou velmi těžké psát.

1966
01:26:40,930 --> 01:26:43,610
Cache nefunguje, když jste
napsat těžké, protože jste vždy

1967
01:26:43,610 --> 01:26:44,610
dostal k aktualizaci mezipaměti.

1968
01:26:44,610 --> 01:26:47,780
Aktualizovat vyrovnávací paměti, je to
irelevantní, které mají být mezipaměti.

1969
01:26:47,780 --> 01:26:49,780
Je to vlastně jen práce navíc.

1970
01:26:49,780 --> 01:26:51,970
>> Takže, kde jsme jít sem?

1971
01:26:51,970 --> 01:26:54,400
Máš velkou zúžení
tam dole v databázi.

1972
01:26:54,400 --> 01:26:57,661
A místo, kam jít
samozřejmě je rozdělení.

1973
01:26:57,661 --> 01:26:59,410
Rozdělení disku není
snadné dělat, když jste

1974
01:26:59,410 --> 01:27:01,900
jednání s relační databáze.

1975
01:27:01,900 --> 01:27:05,080
U relačních databází, že jste
Zodpovídají za řízení, efektivně,

1976
01:27:05,080 --> 01:27:06,210
klíč prostor.

1977
01:27:06,210 --> 01:27:10,527
Říkáte, že uživatelů mezi A a M
jít sem, mezi N a Z jít tam.

1978
01:27:10,527 --> 01:27:12,360
A vy spínání
po aplikaci.

1979
01:27:12,360 --> 01:27:15,000
Takže máte co do činění s
tento oddíl zdroj dat.

1980
01:27:15,000 --> 01:27:18,670
Máte transakční omezení
které nemají span oddíly.

1981
01:27:18,670 --> 01:27:20,560
Máte všechny druhy
nepořádek, že jste

1982
01:27:20,560 --> 01:27:23,040
zabývající se tam snaží
vypořádat se s škálování out

1983
01:27:23,040 --> 01:27:25,120
a budování větší infrastruktury.

1984
01:27:25,120 --> 01:27:27,284
Je to jen žádná legrace.

1985
01:27:27,284 --> 01:27:30,930
>> Diváků: Takže říkáte, že
rostoucím zdrojem body urychluje

1986
01:27:30,930 --> 01:27:31,430
proces?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Zvýšení?

1988
01:27:32,513 --> 01:27:33,520
Diváků: Zdroj bodů.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Zdroj body?

1990
01:27:34,410 --> 01:27:37,500
Diváků: Z informací,
kde se informace přichází?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: Ne.

1992
01:27:38,250 --> 01:27:41,820
To, co říkám, je zvyšování
počet oddílů v úložišti dat

1993
01:27:41,820 --> 01:27:44,060
zvyšuje výkon.

1994
01:27:44,060 --> 01:27:48,300
Takže to, co se tady děje, je uživatelé
přicházející do instance EC2 tady,

1995
01:27:48,300 --> 01:27:50,780
dobře, když potřebuji uživatele
To je na M, půjdu sem.

1996
01:27:50,780 --> 01:27:53,560
Od N k p, půjdu sem.

1997
01:27:53,560 --> 01:27:55,060
Od P do Z, půjdu sem.

1998
01:27:55,060 --> 01:27:57,120
>> Publikum: OK, ty, tak to jsou
všechny uložené v různých uzlech?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Ano.

2000
01:27:57,911 --> 01:28:00,210
Myslete na to, jak
různé sila dat.

2001
01:28:00,210 --> 01:28:01,660
Takže máte na to udělat.

2002
01:28:01,660 --> 01:28:02,910
Pokud se snažíte udělat,
to, pokud se snažíte

2003
01:28:02,910 --> 01:28:05,730
měřítku na relační platformě,
To je to, co děláte.

2004
01:28:05,730 --> 01:28:08,100
Berete dat a
jste řezání dolů.

2005
01:28:08,100 --> 01:28:10,975
A vy oddílů to přes
více instancí databáze.

2006
01:28:10,975 --> 01:28:13,580
A vy řízení vše, co
v aplikační vrstvě.

2007
01:28:13,580 --> 01:28:14,729
Není to žádná legrace.

2008
01:28:14,729 --> 01:28:15,770
Takže to, co chceme jít?

2009
01:28:15,770 --> 01:28:20,240
Chceme jít DynamoDB, plně spravované,
NoSQL úložiště dat, poskytování propustnost.

2010
01:28:20,240 --> 01:28:22,680
Využíváme sekundární indexy.

2011
01:28:22,680 --> 01:28:26,154
Je to v podstatě HTTP API a
zahrnuje podporu dokumentu.

2012
01:28:26,154 --> 01:28:28,570
Takže nemusíte mít strach
přibližně kterákoli hodnota z tohoto dělení.

2013
01:28:28,570 --> 01:28:30,740
Děláme to vše za vás.

2014
01:28:30,740 --> 01:28:33,260
Takže teď, místo toho, budete
stačí napsat do tabulky.

2015
01:28:33,260 --> 01:28:36,490
Pokud je třeba tabulku být rozdělen,
že se děje v zákulisí.

2016
01:28:36,490 --> 01:28:40,642
Vy jste kompletně izolované
z toho jako vývojář.

2017
01:28:40,642 --> 01:28:42,350
Tak pojďme mluvit o
některé z případů použití

2018
01:28:42,350 --> 01:28:47,564
že narazíme na v hraní, obyčejný
herní scénáře, žebříčku.

2019
01:28:47,564 --> 01:28:49,980
Takže jste dostali uživatelé přichází,
se BoardNames, že jsou

2020
01:28:49,980 --> 01:28:52,930
na, skóre pro tohoto uživatele.

2021
01:28:52,930 --> 01:28:57,700
Můžeme být hashování na UserID,
a pak máme řadu na hru.

2022
01:28:57,700 --> 01:28:59,960
Takže každý uživatel chce vidět
všechno hra on hrál

2023
01:28:59,960 --> 01:29:01,770
a všechny jeho nejvyšší skóre
napříč všemi hře.

2024
01:29:01,770 --> 01:29:04,000
Tak to je jeho osobní žebříčku.

2025
01:29:04,000 --> 01:29:10,010
>> Teď chci jít a já chci, aby get--
tak jsem si tyto osobní žebříčků.

2026
01:29:10,010 --> 01:29:12,827
To, co chci udělat, je jít dostat
nejvyšší skóre napříč všemi uživateli.

2027
01:29:12,827 --> 01:29:13,660
Tak jak to mám udělat?

2028
01:29:13,660 --> 01:29:18,070
Když je můj rekord zatříděna na
ID uživatele, se pohybovala na hru,

2029
01:29:18,070 --> 01:29:20,740
dobře Chystám se pokračovat
a restrukturalizovat, vytvořit GSI,

2030
01:29:20,740 --> 01:29:22,370
a budu o restrukturalizaci, že data.

2031
01:29:22,370 --> 01:29:27,310
>> Teď budu k transformaci na
BoardName, což je hra.

2032
01:29:27,310 --> 01:29:29,800
A budu pohybovat na nejvyšší skóre.

2033
01:29:29,800 --> 01:29:31,540
A teď jsem vytvořil různé kbelíky.

2034
01:29:31,540 --> 01:29:34,790
Já jsem za použití stejné tabulky,
stejná data položky.

2035
01:29:34,790 --> 01:29:39,870
Ale já jsem vytvořit kbelík, který dává
me agregací nejvyšší skóre zvěří.

2036
01:29:39,870 --> 01:29:43,180
>> A mohu dotaz, který tabulku
tuto informaci získat.

2037
01:29:43,180 --> 01:29:50,890
Tak jsem nastavit, aby dotazu vzor až do
být podpořeno sekundární indexu.

2038
01:29:50,890 --> 01:29:54,556
Nyní mohou být řazeny podle BoardName
a řazeny podle TopScore, v závislosti na.

2039
01:29:54,556 --> 01:29:57,180
Takže můžete vidět, jsou to typy
z případů použití se dostanete do hry.

2040
01:29:57,180 --> 01:30:02,190
Další dobrá use case jsme se dostat do hry
je ocenění a kdo vyhrál ocenění.

2041
01:30:02,190 --> 01:30:05,340
A je to skvělý případ použití
kde říkáme řídké indexy.

2042
01:30:05,340 --> 01:30:07,340
Řídké indexy jsou
schopnost vytvářet

2043
01:30:07,340 --> 01:30:10,850
index, který není nezbytně
obsahovat každou položku na stole.

2044
01:30:10,850 --> 01:30:11,470
A proč ne?

2045
01:30:11,470 --> 01:30:14,540
Vzhledem k tomu, že to je atribut
indexovaný neexistuje na každém kusu.

2046
01:30:14,540 --> 01:30:16,460
>> Takže v tomto konkrétním
případ použití, říkám,

2047
01:30:16,460 --> 01:30:19,240
víte co, budu
vytvořit atribut nazvaný Award.

2048
01:30:19,240 --> 01:30:22,970
A já dám každému uživateli
že má cenu, která atribut.

2049
01:30:22,970 --> 01:30:25,950
Uživatelé, kteří nemají ocenění jsou
nebude mít tento atribut.

2050
01:30:25,950 --> 01:30:27,800
Takže když jsem se vytvořit
index, pouze uživatelé

2051
01:30:27,800 --> 01:30:28,960
že ukážeme
up v indexu jsou

2052
01:30:28,960 --> 01:30:31,050
ty, které skutečně získaly ocenění.

2053
01:30:31,050 --> 01:30:34,440
Takže je to skvělý způsob, jak být schopni
vytvořit filtrované indexy

2054
01:30:34,440 --> 01:30:40,580
jsou velmi, velmi selektivní, že ne
mají indexovat celou tabulku.

2055
01:30:40,580 --> 01:30:43,050
>> Takže my jsme stále málo času.

2056
01:30:43,050 --> 01:30:49,190
Chystám se jít dopředu a přeskočte
out a přeskočit tento scénář.

2057
01:30:49,190 --> 01:30:52,625
Promluvte si trochu about--

2058
01:30:52,625 --> 01:30:54,460
>> Diváků: Mohu se zeptat na rychlý dotaz?

2059
01:30:54,460 --> 01:30:56,722
Jedním z nich je psát těžké?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Co je to?

2061
01:30:57,680 --> 01:30:58,596
Diváků: Napište těžký.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Napište těžký.

2063
01:31:01,270 --> 01:31:03,460
Podívám se.

2064
01:31:03,460 --> 01:31:06,220
>> Diváků: Nebo je, že ne
něco, co můžete jen

2065
01:31:06,220 --> 01:31:08,809
hlas během několika vteřin?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Jdeme
prostřednictvím hlasování scénáře.

2067
01:31:10,850 --> 01:31:11,670
Není to tak špatné.

2068
01:31:11,670 --> 01:31:14,580
Myslíte si, kluci mají pár minut?

2069
01:31:14,580 --> 01:31:15,860
DOBŘE.

2070
01:31:15,860 --> 01:31:17,890
>> Takže budeme hovořit o hlasování.

2071
01:31:17,890 --> 01:31:20,250
Takže v reálném čase hlasování, máme
požadavky pro hlasování.

2072
01:31:20,250 --> 01:31:25,250
Požadavky jsou, že umožníme
každá osoba, která má hlasovat pouze jednou.

2073
01:31:25,250 --> 01:31:28,060
Chceme nikdo být schopni
změnit svůj hlas.

2074
01:31:28,060 --> 01:31:31,045
Chceme, aby v reálném čase agregace
a analytika pro demografie

2075
01:31:31,045 --> 01:31:34,210
že budeme mít
ukazuje uživatelům na webu.

2076
01:31:34,210 --> 01:31:35,200
>> Myslete na tento scénář.

2077
01:31:35,200 --> 01:31:37,550
Pracujeme hodně reality
TV ukazuje, kde jsou

2078
01:31:37,550 --> 01:31:38,960
dělá tyto přesný typ věcí.

2079
01:31:38,960 --> 01:31:41,584
Takže si můžete myslet na scénář,
máme miliony a miliony

2080
01:31:41,584 --> 01:31:43,959
tam of dospívající dívky
s jejich mobilní telefony

2081
01:31:43,959 --> 01:31:46,250
a hlasování a hlasování, a
hlasovat pro toho, kdo jsou

2082
01:31:46,250 --> 01:31:48,610
si, že je nejoblíbenější.

2083
01:31:48,610 --> 01:31:50,830
Tak to jsou některé z
Požadavky nám dojde.

2084
01:31:50,830 --> 01:31:52,990
>> A tak se jako první přijmout
při řešení tohoto problému

2085
01:31:52,990 --> 01:31:55,090
by bylo vybudovat
Velmi jednoduchá aplikace.

2086
01:31:55,090 --> 01:31:56,490
Tak jsem dostal tuto aplikaci.

2087
01:31:56,490 --> 01:31:57,950
Mám nějaké voliče venku.

2088
01:31:57,950 --> 01:31:59,980
Přicházejí v, narazí na hlasovací aplikace.

2089
01:31:59,980 --> 01:32:03,440
Mám nějaké syrové hlasů tabulku
Já si jen výpis těchto hlasů do.

2090
01:32:03,440 --> 01:32:05,780
Budu mít nějaké agregát
hlasů tabulka, která

2091
01:32:05,780 --> 01:32:09,490
bude dělat Analytics a demografie,
a dáme to všechno tam.

2092
01:32:09,490 --> 01:32:11,420
>> A to je skvělé.

2093
01:32:11,420 --> 01:32:12,332
Život je krásný.

2094
01:32:12,332 --> 01:32:15,040
Život je dobrý, dokud nezjistíme, že
je tu vždy jen jedna nebo dvě

2095
01:32:15,040 --> 01:32:16,879
lidé, kteří jsou populární ve volbách.

2096
01:32:16,879 --> 01:32:19,420
Je tu jen jedna nebo dvě věci
že lidé opravdu záleží.

2097
01:32:19,420 --> 01:32:22,340
A pokud jste na hlasování
měřítko, najednou jsem si

2098
01:32:22,340 --> 01:32:26,360
bude zatloukat sakra z
dva kandidáti, jeden nebo dva zájemci.

2099
01:32:26,360 --> 01:32:29,390
Velmi omezený počet kusů
lidé najdou být populární.

2100
01:32:29,390 --> 01:32:31,710
>> To není dobrý design vzor.

2101
01:32:31,710 --> 01:32:33,549
To je vlastně
velmi špatné návrhový vzor

2102
01:32:33,549 --> 01:32:36,340
protože vytváří přesně to, co jsme
Mluvil o tom, které bylo kláves.

2103
01:32:36,340 --> 01:32:38,960
Horké klávesy jsou něco, co se nám nelíbí.

2104
01:32:38,960 --> 01:32:40,470
>> Tak jak to napravit?

2105
01:32:40,470 --> 01:32:47,640
A opravdu, jak to opravit, je
tím, že se ty kandidátské kbelíky

2106
01:32:47,640 --> 01:32:51,490
a pro každého kandidáta máme,
budeme připojit náhodnou hodnotu,

2107
01:32:51,490 --> 01:32:54,192
něco, co víme, náhodné
hodnota mezi jedním a 100,

2108
01:32:54,192 --> 01:32:56,620
mezi 100 a 1000,
nebo mezi jednou a 1000,

2109
01:32:56,620 --> 01:32:59,940
nicméně mnoho náhodné hodnoty, které chcete
připojit na konec tohoto kandidáta.

2110
01:32:59,940 --> 01:33:01,330
>> A co jsem vlastně udělal potom?

2111
01:33:01,330 --> 01:33:05,830
Pokud jsem pomocí číslo kandidáta jako
bačkory agregovat hlasování,

2112
01:33:05,830 --> 01:33:08,780
jestli jsem přidal náhodný
Číslo na konec, který,

2113
01:33:08,780 --> 01:33:12,000
Vytvořil jsem teď 10 kbelíky, je
Sto tisíc kbelíky, kbelíky

2114
01:33:12,000 --> 01:33:14,160
že jsem agregaci hlasů napříč.

2115
01:33:14,160 --> 01:33:18,030
>> Takže mám miliony a miliony,
a miliony záznamů přichází

2116
01:33:18,030 --> 01:33:22,050
pro tyto kandidáty, jsem nyní šíří
tyto hlasy napříč Candidate a_1

2117
01:33:22,050 --> 01:33:24,630
přes kandidáta A_100, protože
pokaždé, když hlas přijde,

2118
01:33:24,630 --> 01:33:26,530
Jsem generování náhodných
Hodnota mezi jedním a 100.

2119
01:33:26,530 --> 01:33:29,446
Jsem připínání ho na konci
Kandidát, že osoba je hlasovat pro.

2120
01:33:29,446 --> 01:33:31,120
Já dumping to do té kbelíku.

2121
01:33:31,120 --> 01:33:33,910
>> Nyní na zadní straně, já vím,
že jsem sto kbelíky.

2122
01:33:33,910 --> 01:33:36,350
Takže když chci jít dopředu
a agregovat hlasy,

2123
01:33:36,350 --> 01:33:38,244
Četl jsem ze všech těch kbelíků.

2124
01:33:38,244 --> 01:33:39,160
Tak jsem se do toho pusťte a přidat.

2125
01:33:39,160 --> 01:33:42,410
A pak jsem si bodový shromáždit
kde jsem jít ven a říct hej,

2126
01:33:42,410 --> 01:33:45,399
víte co, klíč tohoto uchazeče
prostory je více než sto lopaty.

2127
01:33:45,399 --> 01:33:47,940
Chystám se shromáždit všechny
hlasy od těch sto věder.

2128
01:33:47,940 --> 01:33:49,981
Jdu k agregaci
jim a budu říkat,

2129
01:33:49,981 --> 01:33:53,830
Kandidáta má nyní
Celkový počet hlasování o x.

2130
01:33:53,830 --> 01:33:55,690
>> Nyní oba zápisu
dotaz a dotaz čtení

2131
01:33:55,690 --> 01:33:58,160
jsou pěkně distribuovány
protože píšu napříč

2132
01:33:58,160 --> 01:34:00,320
a já jsem četl přes stovky klíčů.

2133
01:34:00,320 --> 01:34:03,500
Nejsem psaní a
čtení přes jeden klíč nyní.

2134
01:34:03,500 --> 01:34:04,950
Takže je to skvělý vzor.

2135
01:34:04,950 --> 01:34:08,090
>> Toto je ve skutečnosti pravděpodobně jedním
z nejdůležitějších designu

2136
01:34:08,090 --> 01:34:10,420
vzory pro měřítko v NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Uvidíte tento typ
návrhový vzor v každém chuť.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, to není
ohledu na to, my všichni musíme to udělat.

2139
01:34:19,100 --> 01:34:21,840
Protože když máte co do činění
s těch obrovských agregace,

2140
01:34:21,840 --> 01:34:26,650
budete muset vymyslet způsob, jak na
šíří ven přes kbelíky.

2141
01:34:26,650 --> 01:34:29,512
Takže tohle je způsob, jak to udělat.

2142
01:34:29,512 --> 01:34:31,220
Dobře, tak co
děláte právě teď

2143
01:34:31,220 --> 01:34:35,252
Je jste obchodování off čtení
náklady na zápis škálovatelnost.

2144
01:34:35,252 --> 01:34:37,085
Náklady na mé čtení je
trochu složitější

2145
01:34:37,085 --> 01:34:40,220
a já musím jít číst ze
Sto kbelíky namísto jednoho.

2146
01:34:40,220 --> 01:34:41,310
Ale jsem schopen napsat.

2147
01:34:41,310 --> 01:34:44,860
A má propustnost, můj zápis
propustnost je neuvěřitelné.

2148
01:34:44,860 --> 01:34:49,450
Takže je to většinou cenný
technika pro škálování DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
nebo jakékoliv databáze NoSQL na to přijde.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Tak jsme se na to, jak jej škálovat.

2152
01:34:55,240 --> 01:34:56,930
A jsme přišli, jak se
eliminovat naše horkých kláves.

2153
01:34:56,930 --> 01:34:57,820
A to je fantastické.

2154
01:34:57,820 --> 01:34:58,960
A my jsme dostali tento pěkný systém.

2155
01:34:58,960 --> 01:35:02,043
A to nám velmi správné hlasování
protože máme záznam, hlasováno de-Dupe.

2156
01:35:02,043 --> 01:35:03,130
Je postaven do DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Mluvili jsme o podmíněných práv.

2158
01:35:05,380 --> 01:35:08,170
>> Pokud volič přijde, dá
vložku na stole,

2159
01:35:08,170 --> 01:35:11,220
oni vložka s jejich voličské ID,
pokud se pokusíte vložit jiný hlas,

2160
01:35:11,220 --> 01:35:13,320
Já podmíněné zápis.

2161
01:35:13,320 --> 01:35:16,960
Řekněme, že jen napsat to
pokud tato neexistuje.

2162
01:35:16,960 --> 01:35:19,270
Takže jakmile jsem vidět, že
že hlasování hit stůl,

2163
01:35:19,270 --> 01:35:20,460
nikdo jiný to bude
schopen dát svůj hlas v.

2164
01:35:20,460 --> 01:35:21,634
A to je fantastické.

2165
01:35:21,634 --> 01:35:23,550
A my zvyšování
Naši pulty kandidátských.

2166
01:35:23,550 --> 01:35:25,466
A děláme dotazy
demografie a tak.

2167
01:35:25,466 --> 01:35:29,110
Ale co se stane, když je moje
Aplikace padá přes?

2168
01:35:29,110 --> 01:35:31,350
A teď najednou hlasů
jsou přichází, a já

2169
01:35:31,350 --> 01:35:34,840
Nevím, jestli jsou stále zpracovávány
do mé analýzy a demografie

2170
01:35:34,840 --> 01:35:36,040
už ne.

2171
01:35:36,040 --> 01:35:38,462
A když aplikace
přijde zpět, jak

2172
01:35:38,462 --> 01:35:41,420
sakra vím, co máte hlasů
byla zpracována a kde mám začít?

2173
01:35:41,420 --> 01:35:44,530
>> Tak to je skutečný problém, když vás
začít se dívat na tento typ scénáře.

2174
01:35:44,530 --> 01:35:45,571
A jak to řešíme, že?

2175
01:35:45,571 --> 01:35:48,070
Řešíme to s tím, co
volejte DynamoDB proudů.

2176
01:35:48,070 --> 01:35:53,470
Potoky je čas objednat a
rozdělí změna protokol o každém přístupu

2177
01:35:53,470 --> 01:35:55,700
ke stolu, každý napsat
přístup ke stolu.

2178
01:35:55,700 --> 01:35:58,810
Všechna data, která to napsáno na
Tabulka se objeví na proudu.

2179
01:35:58,810 --> 01:36:01,815
>> Je to v podstatě 24 hodin fronta.

2180
01:36:01,815 --> 01:36:03,690
Položky zasáhl proud,
žijí po dobu 24 hodin.

2181
01:36:03,690 --> 01:36:05,990
Mohou být číst vícekrát.

2182
01:36:05,990 --> 01:36:09,400
Garantovaná které mají být dodány
pouze jednou do proudu,

2183
01:36:09,400 --> 01:36:11,180
by bylo možné číst n počet opakování.

2184
01:36:11,180 --> 01:36:14,910
Takže nicméně mnoho procesy, které chcete
konzumovat, že data, můžete konzumovat.

2185
01:36:14,910 --> 01:36:16,350
To se zobrazí při každém aktualizaci.

2186
01:36:16,350 --> 01:36:18,455
Každý zápis bude jen
se objeví jednou na potoku.

2187
01:36:18,455 --> 01:36:20,621
Takže nemusíte mít strach
asi dvojnásobek jejich zpracování

2188
01:36:20,621 --> 01:36:22,500
ze stejného procesu.

2189
01:36:22,500 --> 01:36:25,350
>> Je to přísně nařídil za položku.

2190
01:36:25,350 --> 01:36:28,180
Když říkáme čas
objednal a rozdělí,

2191
01:36:28,180 --> 01:36:30,680
uvidíte za přepážkou na potoku.

2192
01:36:30,680 --> 01:36:33,169
Uvidíte položky, aktualizace v pořádku.

2193
01:36:33,169 --> 01:36:35,210
Nejsme zaručující
streamu, že jste

2194
01:36:35,210 --> 01:36:40,240
dostane každou transakci
v pořadí přes položek.

2195
01:36:40,240 --> 01:36:42,440
>> Takže proudy jsou idempotentních.

2196
01:36:42,440 --> 01:36:44,037
Máme všichni víme, co idempotentních znamená?

2197
01:36:44,037 --> 01:36:46,620
Idempotentních znamená, že můžete to udělat
přes, a znovu, a znovu.

2198
01:36:46,620 --> 01:36:48,200
Výsledek to bude stejná.

2199
01:36:48,200 --> 01:36:49,991
>> Proudy jsou idempotentních,
ale musí být

2200
01:36:49,991 --> 01:36:54,860
hrál od výchozího bodu,
tam, kde si vyberete, až do konce,

2201
01:36:54,860 --> 01:36:57,950
nebo nebudou mít za následek
ve stejných hodnotách.

2202
01:36:57,950 --> 01:36:59,727
>> Totéž se MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB má konstrukt
oni volají oplog.

2204
01:37:01,560 --> 01:37:04,140
Je to přesně stejné konstrukce.

2205
01:37:04,140 --> 01:37:06,500
Mnoho databází NoSQL
mají tento konstrukt.

2206
01:37:06,500 --> 01:37:08,790
Používají ji dělat věci
jako replikace, který

2207
01:37:08,790 --> 01:37:10,475
je přesně to, co děláme s proudy.

2208
01:37:10,475 --> 01:37:12,350
Publikum: Možná
kacířský otázka, ale vy

2209
01:37:12,350 --> 01:37:13,975
mluvit o tom apps dolů po tak dále.

2210
01:37:13,975 --> 01:37:16,089
Jsou proudy zaručeně
Nikdy možná jít dolů?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Jo, potoky
je zaručeno, že se nikdy jít dolů.

2212
01:37:18,630 --> 01:37:21,040
Řídíme infrastrukturu
za. proudy automaticky

2213
01:37:21,040 --> 01:37:22,498
rozmístit své auto škálování skupiny.

2214
01:37:22,498 --> 01:37:25,910
Projdeme trochu
něco o tom, co se stane.

2215
01:37:25,910 --> 01:37:30,060
>> Neměl bych říct, že to není
zaručeno, že se nikdy jít dolů.

2216
01:37:30,060 --> 01:37:33,110
Prvky jsou zaručeny
se objeví v proudu.

2217
01:37:33,110 --> 01:37:36,740
A proud bude přístupná.

2218
01:37:36,740 --> 01:37:40,580
Takže to, co jde dolů nebo se vrátí zpět
up, že se děje pod ním.

2219
01:37:40,580 --> 01:37:43,844
Je covers--, že je to v pořádku.

2220
01:37:43,844 --> 01:37:46,260
Dobře, takže máte jiný
Typy zobrazení mimo obrazovku.

2221
01:37:46,260 --> 01:37:51,040
Typy zobrazení, které jsou důležité pro
programátor jsou obvykle, co to bylo?

2222
01:37:51,040 --> 01:37:52,370
Mám starý názor.

2223
01:37:52,370 --> 01:37:55,630
Pokud aktualizace dopadne na stůl, bude to
vytlačte starý pohled do proudu

2224
01:37:55,630 --> 01:38:02,070
takže data mohou archivovat, nebo změna
kontrola, identifikace změn, změna

2225
01:38:02,070 --> 01:38:03,600
řízení.

2226
01:38:03,600 --> 01:38:07,160
>> Nový snímek, co to je nyní, po
aktualizace, to je jiný druh pohledu

2227
01:38:07,160 --> 01:38:07,660
můžeš dostat.

2228
01:38:07,660 --> 01:38:09,660
Můžete získat staré i nové obrazy.

2229
01:38:09,660 --> 01:38:10,660
Možná, že chci oba.

2230
01:38:10,660 --> 01:38:11,790
Chci vidět, co to bylo.

2231
01:38:11,790 --> 01:38:13,290
Chci vidět, co to se změnilo na.

2232
01:38:13,290 --> 01:38:15,340
>> Mám typ shody
procesu, který běží.

2233
01:38:15,340 --> 01:38:17,430
Je třeba ověřit, zda
pokud se změní tyto věci,

2234
01:38:17,430 --> 01:38:21,840
že jsou v určitých mezích
nebo v rámci určitých parametrů.

2235
01:38:21,840 --> 01:38:23,840
>> A pak možná jsem jen
Potřebuji vědět, co se změnilo.

2236
01:38:23,840 --> 01:38:26,240
Nezajímá mě, co změně položky.

2237
01:38:26,240 --> 01:38:28,580
Nepotřebuji, aby potřebujete vědět
jaké atributy změnil.

2238
01:38:28,580 --> 01:38:30,882
Jenom potřebuju vědět, že
položky jsou dotkl.

2239
01:38:30,882 --> 01:38:33,340
To jsou tedy způsoby zobrazování
že se dostanete z proudu

2240
01:38:33,340 --> 01:38:35,960
a můžete komunikovat s.

2241
01:38:35,960 --> 01:38:37,840
>> Aplikace, která
spotřebovává proud,

2242
01:38:37,840 --> 01:38:39,298
to je tak trochu, jak to funguje.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB klient požádat, aby
tlačit dat do tabulek.

2244
01:38:42,570 --> 01:38:44,750
Proudy nasadit na to, co říkáme střepy.

2245
01:38:44,750 --> 01:38:47,380
Střepy jsou odstupňovány
nezávisle na tabulky.

2246
01:38:47,380 --> 01:38:50,660
Nemají zarovnány úplně
se rozdělí váš stůl.

2247
01:38:50,660 --> 01:38:52,540
A důvod, proč je
protože line up

2248
01:38:52,540 --> 01:38:55,430
kapacitě, aktuální
Kapacita tabulky.

2249
01:38:55,430 --> 01:38:57,600
>> Jejich nasazení v jejich
vlastní auto škálování skupina,

2250
01:38:57,600 --> 01:39:00,800
a začnou vymykat závislosti
na tom, kolik zápisy přicházejí,

2251
01:39:00,800 --> 01:39:03,090
kolik reads-- ve skutečnosti je to píše.

2252
01:39:03,090 --> 01:39:05,820
Není reads-- ale jak
Mnoho zápisy přicházejí.

2253
01:39:05,820 --> 01:39:08,200
>> A pak na zádech
konec, máme to, co máme

2254
01:39:08,200 --> 01:39:11,390
volat KCI, nebo Kinesis klientskou knihovnu.

2255
01:39:11,390 --> 01:39:19,190
Kinesis je proud dat
technologie zpracování od Amazonu.

2256
01:39:19,190 --> 01:39:22,040
A potoků je postavena na tom.

2257
01:39:22,040 --> 01:39:25,670
>> Takže jste použít KCL povolen
Aplikace pro čtení proudu.

2258
01:39:25,670 --> 01:39:28,752
Kinesis Klient knihovna vlastně
spravuje dělníky pro vás.

2259
01:39:28,752 --> 01:39:30,460
A to také dělá některé
zajímavé věci.

2260
01:39:30,460 --> 01:39:35,630
To bude vytvářet nějaké tabulky up
v DynamoDB tabulkovém

2261
01:39:35,630 --> 01:39:38,410
sledovat, které položky
byly zpracovány.

2262
01:39:38,410 --> 01:39:41,190
Takže tímto způsobem, pokud to padá zpět, pokud
spadne a přijde a dostane

2263
01:39:41,190 --> 01:39:45,570
postavil zpět nahoru, to může zjistit, kde
to bylo při zpracování proudu.

2264
01:39:45,570 --> 01:39:48,360
>> To je velmi důležité, když
mluvíte o replikaci.

2265
01:39:48,360 --> 01:39:50,350
Musím vědět, co
Data byla zpracována

2266
01:39:50,350 --> 01:39:52,810
a jaké údaje musí být teprve zpracovány.

2267
01:39:52,810 --> 01:39:57,380
Takže knihovna KCL pro proudů bude
vám hodně této funkci.

2268
01:39:57,380 --> 01:39:58,990
To se stará o veškerou domácnost.

2269
01:39:58,990 --> 01:40:01,140
To se postaví pracovníka pro každý střep.

2270
01:40:01,140 --> 01:40:04,620
To vytvoří administrativní tabulku
za každý střep, pro každého pracovníka.

2271
01:40:04,620 --> 01:40:07,560
A jak tito pracovníci oheň,
udržují ty tabulky

2272
01:40:07,560 --> 01:40:10,510
takže víte, tento záznam
byla přečtena a zpracována.

2273
01:40:10,510 --> 01:40:13,850
A pak, že způsob, jak v případě, že proces
zemře a přejde do režimu online,

2274
01:40:13,850 --> 01:40:17,940
to může pokračovat přesně tam, kde je to vzlétlo.

2275
01:40:17,940 --> 01:40:20,850
>> Tak jsme se použít pro
cross-region replikace.

2276
01:40:20,850 --> 01:40:24,680
Mnoho zákazníků má potřebu
přesunout data nebo části jejich datových tabulek

2277
01:40:24,680 --> 01:40:25,920
kolem různých oblastech.

2278
01:40:25,920 --> 01:40:29,230
Existuje devět regionů
kolem celého světa.

2279
01:40:29,230 --> 01:40:32,100
Tak by mohlo dojít k need-- I
může mít uživatele v Asii, uživatelé

2280
01:40:32,100 --> 01:40:34,150
ve východním pobřeží Spojených států.

2281
01:40:34,150 --> 01:40:38,980
Mají různé údaje, které
musí být na místě rozdělení.

2282
01:40:38,980 --> 01:40:42,510
A možná, že uživatel létá od
Asie přes do Spojených států,

2283
01:40:42,510 --> 01:40:45,020
a chci, aby replikovat
jeho data s ním.

2284
01:40:45,020 --> 01:40:49,340
Takže když se dostane z letadla, má
dobrá zkušenost pomocí svého mobilního aplikace.

2285
01:40:49,340 --> 01:40:52,360
>> Můžete použít cross-region
Knihovna replikace to udělat.

2286
01:40:52,360 --> 01:40:55,730
V podstatě máme
poskytla dvě technologie.

2287
01:40:55,730 --> 01:40:59,400
Jeden je aplikace konzoly můžete
postavit na své vlastní EC2 instance.

2288
01:40:59,400 --> 01:41:01,240
To běží čisté replikace.

2289
01:41:01,240 --> 01:41:02,720
A pak jsme vám dali do knihovny.

2290
01:41:02,720 --> 01:41:06,070
Knihovna můžete použít k vybudování
vlastní aplikace, pokud vás

2291
01:41:06,070 --> 01:41:10,740
chtějí dělat šílené věci, s tím data--
filtr, kopírovat jen část z toho,

2292
01:41:10,740 --> 01:41:14,120
otáčet dat, přesuňte jej na A
jiné tabulky, a tak dále a tak dále.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Takže to je to trochu jak to vypadá.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams může být
zpracovány co nazýváme Lambda.

2296
01:41:23,690 --> 01:41:27,394
Zmínili jsme se trochu o události
aplikačních architektury.

2297
01:41:27,394 --> 01:41:28,810
Lambda je klíčovým prvkem, který.

2298
01:41:28,810 --> 01:41:32,840
Lambda je kód, který vystřelí na požádání
v reakci na konkrétní události.

2299
01:41:32,840 --> 01:41:36,020
Jedním z těchto případů by mohl být
záznam se objeví na potoku.

2300
01:41:36,020 --> 01:41:39,100
Pokud se na potoce se objeví záznam,
zavoláme tuto funkci Java.

2301
01:41:39,100 --> 01:41:44,980
No, to je JavaScript, a Lambda
podporuje Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
a brzy podpoří
další jazyky stejně.

2303
01:41:47,820 --> 01:41:50,940
A stačí říct, že je to čistý kód.

2304
01:41:50,940 --> 01:41:53,610
napsat V Javě, definujete třídu.

2305
01:41:53,610 --> 01:41:55,690
Můžete tlačit JAR nahoru do lambda.

2306
01:41:55,690 --> 01:42:00,200
A pak se určit, která třída
volat v reakci na kterém událost.

2307
01:42:00,200 --> 01:42:04,770
A pak infrastruktura Lambda
za tím poběží ten kód.

2308
01:42:04,770 --> 01:42:06,730
>> Tento kód dokáže zpracovat
Záznamy mimo potoku.

2309
01:42:06,730 --> 01:42:08,230
To může dělat cokoliv, chce s ním.

2310
01:42:08,230 --> 01:42:11,650
V tomto konkrétním příkladu, všichni jsme
opravdu dělají, je protokolování atributy.

2311
01:42:11,650 --> 01:42:13,480
Ale to je jen kód.

2312
01:42:13,480 --> 01:42:15,260
Kód může dělat cokoliv, že jo?

2313
01:42:15,260 --> 01:42:16,600
>> Takže můžete otáčet, že data.

2314
01:42:16,600 --> 01:42:18,160
Můžete vytvářet odvozená pohled.

2315
01:42:18,160 --> 01:42:21,160
Pokud je to struktura dokumentů,
můžete vyrovnat strukturu.

2316
01:42:21,160 --> 01:42:24,300
Můžete si vytvořit alternativní indexy.

2317
01:42:24,300 --> 01:42:27,100
Všechny druhy věcí, které můžete
činění s DynamoDB proudy.

2318
01:42:27,100 --> 01:42:28,780
>> A opravdu, to je to, co to vypadá.

2319
01:42:28,780 --> 01:42:29,940
Takže jste si tyto aktualizace přicházet.

2320
01:42:29,940 --> 01:42:31,190
Jdou mimo řetězec.

2321
01:42:31,190 --> 01:42:32,720
Jsou číst pomocí funkce Lambda.

2322
01:42:32,720 --> 01:42:37,480
Jsou otáčení údaje a
tlačí to v tabulkách finančních derivátů,

2323
01:42:37,480 --> 01:42:42,200
oznamování externích systémů změny,
a tlačí data do ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Mluvili jsme o tom, jak dát cache
v přední části databáze pro tento prodeje

2325
01:42:45,900 --> 01:42:46,450
scénář.

2326
01:42:46,450 --> 01:42:50,049
No, co se stane, když jsem
aktualizuje popis položky?

2327
01:42:50,049 --> 01:42:52,340
No, kdybych měl Lambda
Funkce běží na této tabulce,

2328
01:42:52,340 --> 01:42:55,490
když jsem aktualizovat popis položky, bude to
vyzvednout záznam z potoka,

2329
01:42:55,490 --> 01:42:58,711
a to bude aktualizovat ElastiCache
instance s novými daty.

2330
01:42:58,711 --> 01:43:00,460
Tak to je hodně
Co děláme s Lambda.

2331
01:43:00,460 --> 01:43:02,619
Je to lepidlo kód, konektory.

2332
01:43:02,619 --> 01:43:04,410
A to vlastně dává
schopnost zahájit

2333
01:43:04,410 --> 01:43:07,930
a provozovat velmi složitých aplikací
bez dedikovaný server

2334
01:43:07,930 --> 01:43:10,371
infrastruktura, která je opravdu cool.

2335
01:43:10,371 --> 01:43:13,100
>> Takže pojďme zpět k našim
real-time hlasování architektury.

2336
01:43:13,100 --> 01:43:17,984
To je nová a lepší s našimi
potoků a KCL povoleno žádost.

2337
01:43:17,984 --> 01:43:20,150
Stejně jako předtím, můžeme
zvládnout jakoukoliv měřítko voleb.

2338
01:43:20,150 --> 01:43:21,100
My takhle.

2339
01:43:21,100 --> 01:43:24,770
Děláme z bodový shromažďuje
přes více kbelíků.

2340
01:43:24,770 --> 01:43:26,780
Máme optimističtější zamykání děje.

2341
01:43:26,780 --> 01:43:30,192
Můžeme udržet naše voliče
měnit jejich hlasy.

2342
01:43:30,192 --> 01:43:31,400
Mohou hlasovat pouze jednou.

2343
01:43:31,400 --> 01:43:32,880
To je fantastické.

2344
01:43:32,880 --> 01:43:35,895
Real-time odolnost proti chybám,
Nyní škálovatelné agregace.

2345
01:43:35,895 --> 01:43:38,270
V případě, že věc spadne, ji
ví, kde o restartování samotného

2346
01:43:38,270 --> 01:43:41,300
když se vrátí, protože
jsme pomocí aplikace KCL.

2347
01:43:41,300 --> 01:43:45,700
A pak můžeme použít také, že
KCL aplikace, aby se zasadila dat ven

2348
01:43:45,700 --> 01:43:48,820
k redshift pro jiné
analytika app, nebo použití

2349
01:43:48,820 --> 01:43:51,990
Elastické MapReduce spustit
real-time streaming agregací off

2350
01:43:51,990 --> 01:43:53,180
těchto údajů.

2351
01:43:53,180 --> 01:43:55,480
>> To jsou věci, které bychom
Nemluvil o moc.

2352
01:43:55,480 --> 01:43:57,375
Ale jsou další
technologie, které přicházejí

2353
01:43:57,375 --> 01:44:00,310
nést, když hledáte
na těchto typech scénářů.

2354
01:44:00,310 --> 01:44:03,160
>> Dobře, takže to je asi
analytics s DynamoDB proudů.

2355
01:44:03,160 --> 01:44:05,340
Můžete vybírat de-Dupe
Údaje, dělat všechny druhy

2356
01:44:05,340 --> 01:44:09,490
pěkná věcí, souhrnné údaje v
paměť, vytvoření těchto tabulkách finančních derivátů.

2357
01:44:09,490 --> 01:44:13,110
To je obrovský případ použití
že spousta zákazníků

2358
01:44:13,110 --> 01:44:16,950
se zabývají, přičemž vnořená
Vlastnosti těchto dokumentů JSON

2359
01:44:16,950 --> 01:44:18,946
a vytvoření dalších indexů.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Jsme na konci.

2362
01:44:23,150 --> 01:44:26,689
Děkujeme vám za ložiska se mnou.

2363
01:44:26,689 --> 01:44:28,480
Tak pojďme mluvit o
referenční architektura.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB sedí ve středu tak,
velkou část infrastruktury AWS.

2365
01:44:33,440 --> 01:44:37,090
V podstatě můžete připojit jej
až na cokoli chcete.

2366
01:44:37,090 --> 01:44:45,600
Aplikací pomocí Dynamo zahrnují
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
tlačit data ven do Elastic
MapReduce, export import z DynamoDB

2368
01:44:49,890 --> 01:44:52,370
do S3, všechny druhy pracovních postupů.

2369
01:44:52,370 --> 01:44:54,120
Ale pravděpodobně nejlepší
věc mluvit,

2370
01:44:54,120 --> 01:44:56,119
a to je to, co je opravdu
Zajímavé je, když jsme

2371
01:44:56,119 --> 01:44:58,350
mluvit o události řízené aplikace.

2372
01:44:58,350 --> 01:45:00,300
>> Toto je příklad
interní projekt

2373
01:45:00,300 --> 01:45:04,850
že máme kde jsme vlastně
publikování shromažďovat výsledky průzkumu.

2374
01:45:04,850 --> 01:45:07,700
Takže v e-mailu odkaz, který
vyšleme, tam bude

2375
01:45:07,700 --> 01:45:11,350
být trochu odkaz rčení click
zde v reakci na zjišťování.

2376
01:45:11,350 --> 01:45:14,070
A když se člověk kliknutí
odkazující, co se stane,

2377
01:45:14,070 --> 01:45:18,020
je, že se strhnout bezpečné
Formulář průzkumu HTML z S3.

2378
01:45:18,020 --> 01:45:18,980
Neexistuje žádný server.

2379
01:45:18,980 --> 01:45:20,600
To je jen objekt S3.

2380
01:45:20,600 --> 01:45:22,770
>> Tato forma přijde,
načte do prohlížeče.

2381
01:45:22,770 --> 01:45:24,240
Má to páteř.

2382
01:45:24,240 --> 01:45:30,160
Má to složitý JavaScript
že je to běh.

2383
01:45:30,160 --> 01:45:33,557
Takže je to velmi bohatá aplikace
běží v prohlížeči klienta.

2384
01:45:33,557 --> 01:45:36,390
Oni nevědí, že oni nejsou
interakci s back end.

2385
01:45:36,390 --> 01:45:38,220
V tomto bodě, je to všechno prohlížeč.

2386
01:45:38,220 --> 01:45:41,780
>> Oni zveřejňovat výsledky na to, co
nazýváme Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway je prostě web API
že můžete definovat a připojit

2388
01:45:46,270 --> 01:45:47,760
na co chcete.

2389
01:45:47,760 --> 01:45:50,990
V tomto konkrétním případě, my jsme
zahnutý do funkce Lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Takže moje POST operace
děje žádný server.

2391
01:45:54,797 --> 01:45:56,380
V podstatě, že API brány sedí tam.

2392
01:45:56,380 --> 01:45:58,770
To mi nic nestojí, dokud lidí
start vysílání na to, že jo?

2393
01:45:58,770 --> 01:46:00,269
Funkce Lambda tam prostě sedí.

2394
01:46:00,269 --> 01:46:03,760
A mě to nic nestojí, dokud
lidé začnou bít ji.

2395
01:46:03,760 --> 01:46:07,270
Takže můžete vidět, jak objem
se zvyšuje, to je, když se obvinění přijít.

2396
01:46:07,270 --> 01:46:09,390
Nejsem spuštěn server 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Tak jsem vytáhnout formulář
dolů z nádoby,

2398
01:46:12,310 --> 01:46:15,719
a já jsem psát prostřednictvím rozhraní API
Brána do funkce Lambda.

2399
01:46:15,719 --> 01:46:17,510
A pak Lambda
funkce říká, víte,

2400
01:46:17,510 --> 01:46:20,600
to, co jsem dostal nějaké PIIS, někteří
osobní údaje

2401
01:46:20,600 --> 01:46:21,480
V těchto odpovědí.

2402
01:46:21,480 --> 01:46:23,020
Dostal jsem komentáře přicházející z uživatelů.

2403
01:46:23,020 --> 01:46:24,230
Mám e-mailové adresy.

2404
01:46:24,230 --> 01:46:26,190
Mám uživatelská jména.

2405
01:46:26,190 --> 01:46:27,810
>> Dovolte mi, abych rozdělil to pryč.

2406
01:46:27,810 --> 01:46:30,280
Budu vytvářet nějaké
metadata z tohoto záznamu.

2407
01:46:30,280 --> 01:46:32,850
A budu tlačit
metadata do DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
A mohl bych šifrovat všechny údaje
a zatlačte ji do DynamoDB když budu chtít.

2409
01:46:36,059 --> 01:46:38,600
Ale je to pro mě jednodušší, v tomto
případ použití, pokračovat o slovo,

2410
01:46:38,600 --> 01:46:42,800
Budu tlačit raw dat
do šifrované S3 lopaty.

2411
01:46:42,800 --> 01:46:47,240
Tak jsem použít postaven v S3 straně serveru
šifrování a správy klíčů Amazon

2412
01:46:47,240 --> 01:46:51,600
Služba tak, že mám klíč, který
se může otáčet v pravidelných intervalech,

2413
01:46:51,600 --> 01:46:55,010
a já mohu ochránit, že PII dat
jako součást celého tohoto pracovního postupu.

2414
01:46:55,010 --> 01:46:55,870
>> Tak co jsem to udělal?

2415
01:46:55,870 --> 01:47:00,397
Právě jsem nasazen celek
aplikace, a já nemám server.

2416
01:47:00,397 --> 01:47:02,980
Tak je to, co událost řízený aplikaci
architektura udělá za vás.

2417
01:47:02,980 --> 01:47:05,730
>> Nyní, pokud si myslíte, že o
v případě použití pro tohle--

2418
01:47:05,730 --> 01:47:08,730
Máme jiné zákazníky, já mluvím
se o tomto přesném architektuře, kteří

2419
01:47:08,730 --> 01:47:14,560
spustit neobyčejně velké kampaně, kteří
jsou při pohledu na to a jít, oh my.

2420
01:47:14,560 --> 01:47:17,840
Protože teď, mohou
v podstatě tlačit to tam,

2421
01:47:17,840 --> 01:47:21,900
dovolte, že kampaň jen sedět
tam, dokud se na trh, a nikoli

2422
01:47:21,900 --> 01:47:24,400
muset starat o obr o
jaký druh infrastruktury

2423
01:47:24,400 --> 01:47:26,120
bude tam na její podporu.

2424
01:47:26,120 --> 01:47:28,600
A pak, jakmile
že kampaň je hotovo,

2425
01:47:28,600 --> 01:47:31,520
je to jako na infrastrukturu
Jen okamžitě zmizí

2426
01:47:31,520 --> 01:47:33,680
protože tam opravdu
žádná infrastruktura.

2427
01:47:33,680 --> 01:47:35,660
Je to jen kód, který sedí na Lambda.

2428
01:47:35,660 --> 01:47:38,560
Je to jen data, která sedí v DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Je to úžasný způsob,
při tvorbě aplikací.

2430
01:47:41,340 --> 01:47:43,970
>> Diváků: Tak to je více
pomíjivý, než by bylo

2431
01:47:43,970 --> 01:47:45,740
pokud to bylo uloženo na skutečné serveru?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Rozhodně.

2433
01:47:46,823 --> 01:47:49,190
Vzhledem k tomu, že instance serveru
by měla být 7 dvacet čtyřitin.

2434
01:47:49,190 --> 01:47:51,954
To má být k dispozici pro
někdo reagovat.

2435
01:47:51,954 --> 01:47:52,620
Tak víš co?

2436
01:47:52,620 --> 01:47:55,410
S3 je k dispozici 7 dvacet čtyřitiny.

2437
01:47:55,410 --> 01:47:57,100
S3 vždy odpoví.

2438
01:47:57,100 --> 01:47:59,320
A S3 je velmi, velmi dobrá
při servírují objekty.

2439
01:47:59,320 --> 01:48:02,590
Tyto objekty mohou být HTML soubory, nebo
JavaScript soubory, nebo cokoliv chcete.

2440
01:48:02,590 --> 01:48:07,430
Můžete spustit velmi bohatých webových aplikací
z S3 kbelíky, a lidé dělají.

2441
01:48:07,430 --> 01:48:10,160
>> A tak to je myšlenka tady
je dostat se pryč od cesty

2442
01:48:10,160 --> 01:48:11,270
jsme se o tom přemýšlet.

2443
01:48:11,270 --> 01:48:14,270
Všichni jsme si myslela, že v
Podmínky serverů a hostitelů.

2444
01:48:14,270 --> 01:48:16,580
Není to o tom ještě.

2445
01:48:16,580 --> 01:48:19,310
Je to o infrastruktury jako kód.

2446
01:48:19,310 --> 01:48:22,470
Nasadit kód do cloudu a
nechte oblak spusťte jej za vás.

2447
01:48:22,470 --> 01:48:24,980
A to je to, co AWS se snaží dělat.

2448
01:48:24,980 --> 01:48:29,690
>> Diváků: Takže vaše zlaté pole ve středu
API brány není serverem-like,

2449
01:48:29,690 --> 01:48:30,576
ale místo toho je jen--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Můžete si myslet
o tom jako fasáda serveru.

2451
01:48:32,850 --> 01:48:38,040
Vše, co to je, je to bude trvat HTTP
požadovat a mapovat na jiný proces.

2452
01:48:38,040 --> 01:48:39,192
To je vše, co dělá.

2453
01:48:39,192 --> 01:48:41,525
A v tomto případě, my mapování
to na funkci Lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Dobře, takže to je vše, co mám.

2456
01:48:45,410 --> 01:48:46,190
Děkuji mnohokrát.

2457
01:48:46,190 --> 01:48:46,800
Vážím si toho.

2458
01:48:46,800 --> 01:48:48,100
Vím, že chceme trochu v čase.

2459
01:48:48,100 --> 01:48:49,980
A doufejme, že vy jste dostal
trochu informací

2460
01:48:49,980 --> 01:48:51,410
které si můžete odnést i dnes.

2461
01:48:51,410 --> 01:48:53,520
A omlouvám se, pokud jsem šel
přes některé z vašich hlav,

2462
01:48:53,520 --> 01:48:56,697
ale je tu velká spousta
základní znalosti foundational

2463
01:48:56,697 --> 01:48:58,280
si myslím, že je velmi cenné pro vás.

2464
01:48:58,280 --> 01:48:59,825
Takže děkuji za to, že mě.

2465
01:48:59,825 --> 01:49:00,325
[POTLESK]

2466
01:49:00,325 --> 01:49:02,619
Diváků: [Neslyšitelné]
je, když jste říkal

2467
01:49:02,619 --> 01:49:05,160
museli jste projít věc
od začátku až do konce

2468
01:49:05,160 --> 01:49:07,619
získat správné hodnoty
nebo stejné hodnoty,

2469
01:49:07,619 --> 01:49:09,410
jak by se hodnoty
pokud [neslyšitelný] změnit.

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, idempotentních?

2471
01:49:10,480 --> 01:49:11,800
Jak by se hodnoty změní?

2472
01:49:11,800 --> 01:49:15,180
No, protože kdybych nebyl spuštěn
to celou cestu až do konce,

2473
01:49:15,180 --> 01:49:19,770
pak nevím, jaké změny
byly provedeny v poslední míli.

2474
01:49:19,770 --> 01:49:22,144
Nebude to být
stejné údaje jako to, co jsem viděl.

2475
01:49:22,144 --> 01:49:24,560
Publikum: Oh, takže stačí
nedostal celý vstup.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Správně.

2477
01:49:24,770 --> 01:49:26,895
Musíte jít od začátku
až do konce, a pak je to

2478
01:49:26,895 --> 01:49:29,280
Bude konzistentního stavu.

2479
01:49:29,280 --> 01:49:31,520
Bezva.

2480
01:49:31,520 --> 01:49:35,907
>> Diváků: Takže jste nám ukázal DynamoDB
může dělat dokument nebo hodnotu klíče.

2481
01:49:35,907 --> 01:49:38,740
A my jsme strávili hodně času na
Hodnota klíče s hash a způsoby

2482
01:49:38,740 --> 01:49:40,005
hodit kolem.

2483
01:49:40,005 --> 01:49:43,255
Když se podíval na těchto tabulek, je to, že
odcházející za přístupu dokumentu?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: Já bych ne
říkají, opouštět to za sebou.

2485
01:49:44,600 --> 01:49:45,855
>> Diváků: Oni byli odděleni od the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: S dokumentem
přístup, typ dokument DynamoDB

2487
01:49:49,140 --> 01:49:50,880
Je jen myslet jako další atribut.

2488
01:49:50,880 --> 01:49:53,560
Je to vlastnost, která obsahuje
hierarchická struktura dat.

2489
01:49:53,560 --> 01:49:56,980
A pak se v dotazech,
můžete použít vlastnosti

2490
01:49:56,980 --> 01:49:59,480
z těchto objektů pomocí Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Tak jsem můžete filtrovat na vnořené
vlastnost dokumentu JSON.

2492
01:50:03,562 --> 01:50:05,520
Diváků: Takže kdykoliv jsem se
udělat přístup dokumentu,

2493
01:50:05,520 --> 01:50:07,906
Mohu nějak dorazit na tabular--

2494
01:50:07,906 --> 01:50:08,780
Diváků: Rozhodně.

2495
01:50:08,780 --> 01:50:09,800
Publikum: --indexes a
věci, které právě mluvili.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Jo, ten
indexy a všechno,

2497
01:50:11,280 --> 01:50:13,363
když chcete indexu
vlastnosti JSON,

2498
01:50:13,363 --> 01:50:18,230
tak, že budeme muset udělat, je, pokud
vložíte objekt JSON nebo dokumentu

2499
01:50:18,230 --> 01:50:20,780
do Dynamu, měli byste použít proudy.

2500
01:50:20,780 --> 01:50:22,400
Proudy by číst vstup.

2501
01:50:22,400 --> 01:50:24,340
Vy byste dostat, že JSON
objekt a vy byste řekl OK,

2502
01:50:24,340 --> 01:50:26,030
co je to vlastnost chci index?

2503
01:50:26,030 --> 01:50:28,717
>> Můžete vytvářet odvozená tabulky.

2504
01:50:28,717 --> 01:50:30,300
Teď, když je to tak, jak to funguje právě teď.

2505
01:50:30,300 --> 01:50:32,650
Nechceme, aby vás na indexu
přímo tyto vlastnosti.

2506
01:50:32,650 --> 01:50:33,520
>> Diváků: Tabularizing dokumentů.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Přesně tak, zploštění
to, tabularizing to přesně.

2508
01:50:36,230 --> 01:50:37,415
To je to, co s tím dělat.

2509
01:50:37,415 --> 01:50:37,860
>> Diváků: Děkuji.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Jo,
absolutně, děkuji.

2511
01:50:39,609 --> 01:50:42,240
Diváků: Takže je to trochu
Mongo setkává REDIS classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Jo,
to je hodně jako to.

2513
01:50:43,990 --> 01:50:45,940
To je dobrý popis pro něj.

2514
01:50:45,940 --> 01:50:47,490
Bezva.

2515
01:50:47,490 --> 01:50:49,102