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

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

3
00:00:06,010 --> 00:00:06,600
Hei kaikki.

4
00:00:06,600 --> 00:00:07,670
Nimeni on Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Olen vanhempi pääasiallinen
ratkaisut arkkitehti AWS.

6
00:00:10,330 --> 00:00:14,070
I keskittyä NoSQL ja
DynamoDB tekniikoita.

7
00:00:14,070 --> 00:00:16,930
Olen täällä tänään puhua
olet hieman näistä.

8
00:00:16,930 --> 00:00:18,970
>> Oma taustani on
ensisijaisesti tiedot kerros.

9
00:00:18,970 --> 00:00:21,390
Vietin puoli minun kehitys
ura kirjallisesti tietokanta,

10
00:00:21,390 --> 00:00:25,930
tietojen saatavuutta, ratkaisut
erilaisiin sovelluksiin.

11
00:00:25,930 --> 00:00:30,000
Olen ollut Cloud virtualisointi
noin 20 vuotta.

12
00:00:30,000 --> 00:00:33,460
Joten ennen Cloud oli Cloud,
käytimme kutsua Utility Computing.

13
00:00:33,460 --> 00:00:37,170
Ja ajatus oli, se on kuin
PG & E, maksat siitä mitä käytät.

14
00:00:37,170 --> 00:00:38,800
Tänään me kutsumme sitä pilvi.

15
00:00:38,800 --> 00:00:41,239
>> Mutta vuosien mittaan, olen työskennellyt
pari yritykset

16
00:00:41,239 --> 00:00:42,530
olet todennäköisesti koskaan kuullut.

17
00:00:42,530 --> 00:00:47,470
Mutta olen koonnut luettelon teknisen
saavutuksia, kai haluat sanoa.

18
00:00:47,470 --> 00:00:51,620
Minulla on kahdeksan patentteja Cloud järjestelmät
virtualisointi, mikroprosessori suunnittelu,

19
00:00:51,620 --> 00:00:54,440
monimutkainen tapahtuma käsittely,
ja muilla aloilla.

20
00:00:54,440 --> 00:00:58,290
>> Niin näinä päivinä, keskityn lähinnä NoSQL
teknologioita ja seuraavan sukupolven

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

22
00:00:59,450 --> 00:01:03,370
Ja se on yleensä mitä aion
olla täällä puhumassa teille tänään.

23
00:01:03,370 --> 00:01:06,030
Mitä voit odottaa
Tämän istunnon,

24
00:01:06,030 --> 00:01:08,254
käymme läpi lyhyt
historia tietojenkäsittelyä.

25
00:01:08,254 --> 00:01:10,420
On aina hyödyllistä
ymmärtää mistä tulimme

26
00:01:10,420 --> 00:01:12,400
ja miksi olemme missä olemme.

27
00:01:12,400 --> 00:01:15,600
Ja me puhumme hieman
vähän siitä NoSQL tekniikka

28
00:01:15,600 --> 00:01:17,500
alkaen perustavanlaatuinen näkökulmasta.

29
00:01:17,500 --> 00:01:19,870
>> Saamme joihinkin
DynamoDB sisäosat.

30
00:01:19,870 --> 00:01:24,350
DynamoDB on AWS: n ei maku.

31
00:01:24,350 --> 00:01:27,340
Se on täysin onnistunut ja
isännöi NoSQL ratkaisu.

32
00:01:27,340 --> 00:01:32,420
Ja me puhumme hieman siitä taulukko
rakenne, API, tietotyypit, hakemistot,

33
00:01:32,420 --> 00:01:35,177
ja jotkut sisäosat
Tämän DynamoDB tekniikkaa.

34
00:01:35,177 --> 00:01:37,760
Pääsemme joitakin suunnittelu
malleja ja parhaita käytäntöjä.

35
00:01:37,760 --> 00:01:39,968
Puhutaan miten
käyttää tätä tekniikkaa joidenkin

36
00:01:39,968 --> 00:01:41,430
nykypäivän sovelluksia.

37
00:01:41,430 --> 00:01:44,820
Ja sitten me jutellaan vähän
noin evoluutio tai syntymistä

38
00:01:44,820 --> 00:01:48,980
uuden paradigman ohjelmoinnin
nimeltään tapahtumapohjainen sovelluksia

39
00:01:48,980 --> 00:01:51,580
ja miten DynamoDB soittaa että samoin.

40
00:01:51,580 --> 00:01:54,690
Ja me jättää sinut hieman
viittaus arkkitehtuuri keskustelu

41
00:01:54,690 --> 00:01:59,540
jotta voimme puhua joistakin
miten voit käyttää DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Joten ensimmäinen off-- tämä on kysymys
Kuulen paljon on, mitä tietokanta.

43
00:02:04,116 --> 00:02:06,240
Monet ihmiset ajattelevat, että he
tietävät, mitä tietokannassa on.

44
00:02:06,240 --> 00:02:08,360
Jos Google, näet tämän.

45
00:02:08,360 --> 00:02:11,675
Se on jäsennelty joukko tietoja hallussa
tietokoneessa, varsinkin sellainen, joka

46
00:02:11,675 --> 00:02:13,600
on saatavilla eri tavoin.

47
00:02:13,600 --> 00:02:16,992
Oletan, että on hyvä
määritelmä modernin tietokannan.

48
00:02:16,992 --> 00:02:19,450
Mutta en pidä siitä, koska
se merkitsee pari asiaa.

49
00:02:19,450 --> 00:02:20,935
Se merkitsee rakenne.

50
00:02:20,935 --> 00:02:23,120
Ja se merkitsee, että se on tietokoneessa.

51
00:02:23,120 --> 00:02:25,750
Ja tietokannat eivät
aina olemassa tietokoneissa.

52
00:02:25,750 --> 00:02:28,020
Tietokannat todella olemassa monin tavoin.

53
00:02:28,020 --> 00:02:32,000
>> Joten parempi määrittely
tietokanta on jotain tällaista.

54
00:02:32,000 --> 00:02:34,786
Tietokanta on organisoitu
mekanismi tallentamiseen, hallintaan,

55
00:02:34,786 --> 00:02:35,910
ja tiedonhaku.

56
00:02:35,910 --> 00:02:36,868
Tämä on peräisin About.com.

57
00:02:36,868 --> 00:02:42,080
Joten Pidän tästä, koska se todella puhuu
noin tietokanta on arkiston,

58
00:02:42,080 --> 00:02:44,800
arkisto
tietoja, ei välttämättä

59
00:02:44,800 --> 00:02:46,780
jotain, joka istuu tietokoneella.

60
00:02:46,780 --> 00:02:49,290
Ja läpi historian, me
ei ole aina ollut tietokoneita.

61
00:02:49,290 --> 00:02:52,110
>> Nyt, jos kysyn keskimäärin
kehittäjä tänään mitä

62
00:02:52,110 --> 00:02:54,770
tietokanta, joka on vastaus saan.

63
00:02:54,770 --> 00:02:56,070
Jossain Voin kiinni kamaa.

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

65
00:02:56,670 --> 00:02:58,725
Ja se on totta.

66
00:02:58,725 --> 00:02:59,600
Mutta se on valitettavaa.

67
00:02:59,600 --> 00:03:02,700
Koska tietokanta on todella
perusta nykyaikaisen sovelluksen.

68
00:03:02,700 --> 00:03:04,810
Se on perusta
jokaisen hakemuksen.

69
00:03:04,810 --> 00:03:07,240
Ja miten rakentaa, että
tietokanta, miten rakenne

70
00:03:07,240 --> 00:03:11,750
että tiedot on menossa sanella miten että
sovellus toimii kuten mittakaavassa.

71
00:03:11,750 --> 00:03:14,640
>> Niin paljon työni tänään
käsittelee mitä

72
00:03:14,640 --> 00:03:17,180
tapahtuu, kun kehittäjät
tätä lähestymistapaa

73
00:03:17,180 --> 00:03:19,510
ja käsittelevät jälkimainingeissa
hakemuksen, joka

74
00:03:19,510 --> 00:03:24,966
on nyt skaalaus yli alkuperäisen
tahallisuus ja kärsii huonosta suunnittelusta.

75
00:03:24,966 --> 00:03:26,840
Joten toivottavasti kun
kävelymatkan päässä tänään, luultavasti

76
00:03:26,840 --> 00:03:29,010
on pari työkaluja
vyöhön että pitää sinut

77
00:03:29,010 --> 00:03:32,566
tekemästä niitä samoja virheitä.

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

79
00:03:33,066 --> 00:03:36,360
Joten Puhutaanpa hieman
aikajana tietokantateknologia.

80
00:03:36,360 --> 00:03:38,830
Taisin lukea
artikkeli ei niin kauan sitten

81
00:03:38,830 --> 00:03:43,020
ja se sanoi jotain lines--
se on hyvin runollinen lausunto.

82
00:03:43,020 --> 00:03:46,590
Se sanoi historia
Tietojen käsittely on

83
00:03:46,590 --> 00:03:49,350
täynnä korkea vesileimat
Tietojen runsaus.

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

85
00:03:49,920 --> 00:03:52,532
Nyt, oletan, että on tavallaan totta.

86
00:03:52,532 --> 00:03:54,990
Mutta olen itse tarkastella on kuin
historia on todella täynnä

87
00:03:54,990 --> 00:03:56,820
korkea vesileima tietojen paine.

88
00:03:56,820 --> 00:04:00,040
Koska datanopeus
nauttiminen ei koskaan mene alas.

89
00:04:00,040 --> 00:04:01,360
Se vain menee ylös.

90
00:04:01,360 --> 00:04:03,670
>> Ja innovaatio tapahtuu, kun
näemme tiedot paine, joka

91
00:04:03,670 --> 00:04:07,825
on datan määrä, joka on
nyt tulossa järjestelmään.

92
00:04:07,825 --> 00:04:12,027
Ja se ei voi käsitellä
tehokkaasti joko eri aikaan tai eri kustannuksia.

93
00:04:12,027 --> 00:04:14,110
Ja silloin alamme
tarkastella tietoja paineessa.

94
00:04:14,110 --> 00:04:15,920
>> Joten kun katsomme
ensimmäinen tietokanta, tämä

95
00:04:15,920 --> 00:04:17,180
on yksi, joka oli välillä korvat.

96
00:04:17,180 --> 00:04:18,310
Olemme kaikki syntyneet kanssa.

97
00:04:18,310 --> 00:04:19,194
Se on kiva tietokanta.

98
00:04:19,194 --> 00:04:21,110
Se on korkean käytettävyyden.

99
00:04:21,110 --> 00:04:21,959
Se on aina päällä.

100
00:04:21,959 --> 00:04:23,930
Voit aina saada sitä.

101
00:04:23,930 --> 00:04:24,890
>> Mutta se on yksi käyttäjä.

102
00:04:24,890 --> 00:04:26,348
En voi jakaa ajatuksiani kanssanne.

103
00:04:26,348 --> 00:04:28,370
Et voi saada ajatukseni
kun haluat niitä.

104
00:04:28,370 --> 00:04:30,320
Ja heidän abilitiy ei ole niin hyvä.

105
00:04:30,320 --> 00:04:32,510
Me unohtaa asioita.

106
00:04:32,510 --> 00:04:36,540
Aina silloin tällöin, yksi meistä lehdet
ja siirtyy toiseen olemassaoloon

107
00:04:36,540 --> 00:04:39,110
ja menetämme kaiken
joka oli, että tietokantaan.

108
00:04:39,110 --> 00:04:40,640
Niin, että ei ole kaikki, että hyvä.

109
00:04:40,640 --> 00:04:43,189
>> Ja tämä toimi hyvin ajan
kun olimme takaisin seuraavana päivänä

110
00:04:43,189 --> 00:04:46,230
kun kaikki me todella tarvitaan tietää
Mihin olemme menossa huomenna

111
00:04:46,230 --> 00:04:49,630
tai jos keräämme parasta ruokaa.

112
00:04:49,630 --> 00:04:52,820
Mutta kun aloimme kasvaa
sivistyksen ja hallitus käynnisti

113
00:04:52,820 --> 00:04:55,152
että otetaan käyttöön, ja
yritykset alkoivat kehittyä,

114
00:04:55,152 --> 00:04:57,360
aloimme ymmärtää me
tarvitsevat hieman enemmän kuin mitä

115
00:04:57,360 --> 00:04:58,210
voisimme laittaa meidän pään.

116
00:04:58,210 --> 00:04:58,870
Selvä?

117
00:04:58,870 --> 00:05:00,410
>> Tarvitsimme järjestelmien ennätys.

118
00:05:00,410 --> 00:05:02,220
Tarvitsimme paikkoja voi tallentaa tietoja.

119
00:05:02,220 --> 00:05:05,450
Aloimme kirjallisesti asiakirjat,
luodaan kirjastojen ja arkistojen.

120
00:05:05,450 --> 00:05:08,000
Aloitimme kehittää
järjestelmä Ledger kirjanpito.

121
00:05:08,000 --> 00:05:12,200
Ja että järjestelmä Ledger laskenta
juoksi maailman vuosisatojen ajan,

122
00:05:12,200 --> 00:05:15,580
ja ehkä jopa vuosituhansia kuin
me tavallaan kasvoi pisteeseen

123
00:05:15,580 --> 00:05:18,420
jos tietojen kuormitus ylitti
kyky näiden järjestelmien

124
00:05:18,420 --> 00:05:19,870
pystyä sisältää sitä.

125
00:05:19,870 --> 00:05:22,070
>> Ja tämä todella tapahtui 1880-luvulla.

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

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

128
00:05:24,390 --> 00:05:26,976
Tämä on todella, jossa käännön
kohta moderni tietojenkäsittely.

129
00:05:26,976 --> 00:05:28,850
Tämä on piste
jossa datan määrä

130
00:05:28,850 --> 00:05:32,060
että keräsi
Yhdysvaltain hallitus tulleet pisteeseen

131
00:05:32,060 --> 00:05:34,005
jossa se kesti kahdeksan vuotta käsitellä.

132
00:05:34,005 --> 00:05:36,350
>> Nyt, kahdeksan years-- kuten
tiedät, väestönlaskenta

133
00:05:36,350 --> 00:05:39,180
kulkee joka 10 years-- joten se on
melko selvää, että aika

134
00:05:39,180 --> 00:05:41,419
sai 1890 väestönlaskenta,
datan määrä, joka

135
00:05:41,419 --> 00:05:43,210
piti käsitellä
valtion oli

136
00:05:43,210 --> 00:05:46,335
tulee ylittämään 10 vuotta, että se
kestäisi käynnisti uuden väestönlaskennan.

137
00:05:46,335 --> 00:05:47,250
Tämä oli ongelma.

138
00:05:47,250 --> 00:05:49,000
>> Joten kaveri nimeltä Herman
Hollerith tulivat

139
00:05:49,000 --> 00:05:52,640
ja hän keksi yksikkö ennätys booli
kortit, booli kortinlukija, reikäkorttikoneilla

140
00:05:52,640 --> 00:05:58,420
tabulaattoria, ja kokoamista
mekanismeja tätä tekniikkaa.

141
00:05:58,420 --> 00:06:01,860
Ja että yhtiö hän muodostettu
aika, sekä pari muuta,

142
00:06:01,860 --> 00:06:05,450
itse asiassa tuli yksi peruspilareista
pieni yritys tunnemme tänään nimeltään IBM.

143
00:06:05,450 --> 00:06:08,417
>> Joten IBM alunperin oli
tietokanta liiketoimintaa.

144
00:06:08,417 --> 00:06:09,750
Ja se on todella mitä he tekivät.

145
00:06:09,750 --> 00:06:11,110
He tekivät tietojenkäsittely.

146
00:06:11,110 --> 00:06:15,400
>> Kuten niin leviämisen booli
kortteja, nerokas mekanismeja

147
00:06:15,400 --> 00:06:18,560
että voimme hyödyntää että
teknologia kyselyn lajiteltua tulosjoukkoja.

148
00:06:18,560 --> 00:06:20,726
Voit nähdä tässä kuvassa
siellä meillä little--

149
00:06:20,726 --> 00:06:23,970
se on hieman small-- mutta voit nähdä
erittäin nerokas mekaaninen mekanismi

150
00:06:23,970 --> 00:06:26,970
jossa meillä on booli kortin pakalla.

151
00:06:26,970 --> 00:06:28,720
Ja joku vie
pieni ruuvimeisseli

152
00:06:28,720 --> 00:06:31,400
ja kiinni kautta
lähtö ja nostamalla sitä ylös

153
00:06:31,400 --> 00:06:34,820
saada, että ottelu, että
lajiteltu tulokset asetettu.

154
00:06:34,820 --> 00:06:36,270
>> Tämä on yhdistäminen.

155
00:06:36,270 --> 00:06:38,690
Teemme tämän kaiken aikaa
tänään tietokone,

156
00:06:38,690 --> 00:06:40,100
jossa teet sen tietokantaan.

157
00:06:40,100 --> 00:06:41,620
Käytimme tehdä sen manuaalisesti, eikö?

158
00:06:41,620 --> 00:06:42,994
Ihmiset laittaa nämä asiat yhteen.

159
00:06:42,994 --> 00:06:45,440
Ja se oli leviämisen
Näiden reikäkortteja

160
00:06:45,440 --> 00:06:50,070
mitä me kutsutaan tietojen rummut
ja tiedot kelat, paperi nauha.

161
00:06:50,070 --> 00:06:55,980
>> Tietojenkäsittely teollisuus otti
opetus soittimesta pianot.

162
00:06:55,980 --> 00:06:57,855
Pelaajan pianos takaisin
vuosisadan vaihteessa

163
00:06:57,855 --> 00:07:02,100
tapana käyttää paperirullien kanssa lähtö
on kertoa se mitä näppäimiä pelata.

164
00:07:02,100 --> 00:07:05,380
Jotta teknologia mukautettiin
lopulta tallentaa digitaalista tietoa,

165
00:07:05,380 --> 00:07:08,070
koska ne voisi laittaa, että tiedot
asemia paperi nauha rullia.

166
00:07:08,070 --> 00:07:10,870
>> Nyt, sen seurauksena, tiedot
oli actually-- miten

167
00:07:10,870 --> 00:07:14,960
käytät näitä tietoja oli suoraan
riippuu siitä, kuinka se on tallennettu.

168
00:07:14,960 --> 00:07:17,825
Joten jos laitan tietoja nauhalle,
Minulla oli käyttää tietoja lineaarisesti.

169
00:07:17,825 --> 00:07:20,475
Minulla oli roll koko
nauha käyttää kaikkia tietoja.

170
00:07:20,475 --> 00:07:22,600
Jos laitan tiedot booli
kortteja, voisin käyttää sitä

171
00:07:22,600 --> 00:07:26,270
hieman enemmän satunnaisia
muoti, ehkä ei niin nopeasti.

172
00:07:26,270 --> 00:07:30,770
>> Mutta on rajoituksia siinä, miten
pääsy tietoihin perustuvat kuinka säilytettiin.

173
00:07:30,770 --> 00:07:32,890
Ja niin tämä oli ongelma
menee 50-luvulla.

174
00:07:32,890 --> 00:07:37,890
Jälleen voimme alkaa nähdä, että me
kehittää uutta teknologiaa käsitellä

175
00:07:37,890 --> 00:07:41,670
tiedot, oikea, se avautuu
ovi uusia ratkaisuja,

176
00:07:41,670 --> 00:07:45,852
uusien ohjelmien, uusi
Hakemukset että tiedot.

177
00:07:45,852 --> 00:07:47,810
Ja todella, hallintotapa
saattanut olla syy

178
00:07:47,810 --> 00:07:49,435
miksi olemme kehittäneet joitakin näistä järjestelmistä.

179
00:07:49,435 --> 00:07:52,290
Mutta liike tuli nopeasti
kuljettaja takana evoluutio

180
00:07:52,290 --> 00:07:54,720
modernin tietokannan ja
moderni tiedostojärjestelmä.

181
00:07:54,720 --> 00:07:56,870
>> Joten seuraava asia, että
tuli oli 50-luvulla

182
00:07:56,870 --> 00:08:00,780
oli tiedostojärjestelmä ja
kehittäminen random access varastoinnin.

183
00:08:00,780 --> 00:08:02,050
Tämä oli kaunis.

184
00:08:02,050 --> 00:08:06,230
Nyt kaikki äkillinen, voimme ottaa
tiedostoja tahansa näistä kiintolevyt

185
00:08:06,230 --> 00:08:09,760
ja voimme käyttää näitä tietoja satunnaisesti.

186
00:08:09,760 --> 00:08:11,950
Voimme jäsentää että
tietoa ulos tiedostoja.

187
00:08:11,950 --> 00:08:14,920
Ja me ratkaista kaikki maailman
ongelmia tietojenkäsittely.

188
00:08:14,920 --> 00:08:17,550
>> Ja joka kesti noin 20 tai
30 vuotta kunnes kehitys

189
00:08:17,550 --> 00:08:22,100
on relaatiotietokannan, joka
on kun maailma päätti nyt

190
00:08:22,100 --> 00:08:27,940
täytyy olla arkisto tyhjäksi
hajautumista dataa tiedosto

191
00:08:27,940 --> 00:08:29,540
järjestelmät että olemme rakentaneet. Oikea?

192
00:08:29,540 --> 00:08:34,270
Liian paljon tietoa jaetaan liikaa
paikkoja, de-päällekkäisyyksiä tietojen,

193
00:08:34,270 --> 00:08:37,120
ja kustannukset varastointi oli valtava.

194
00:08:37,120 --> 00:08:43,760
>> 70-luvulla, kallein resurssi
että tietokone oli ollut varastointi.

195
00:08:43,760 --> 00:08:46,200
Prosessori oli
pitää kiinteät kustannukset.

196
00:08:46,200 --> 00:08:49,030
Kun ostan laatikko,
CPU tekee jonkin verran työtä.

197
00:08:49,030 --> 00:08:51,960
Se tulee pyöriä onko
Se on itse asiassa toimii tai ei.

198
00:08:51,960 --> 00:08:53,350
Se on todella uponneita kustannuksia.

199
00:08:53,350 --> 00:08:56,030
>> Mutta mitä maksaa minulle
liiketoiminta on varastointi.

200
00:08:56,030 --> 00:09:00,020
Jos minun täytyy ostaa enemmän levyjä seuraavaksi
kuukaudessa, se on todellisia kustannuksia että voin maksaa.

201
00:09:00,020 --> 00:09:01,620
Ja että varastointi on kallista.

202
00:09:01,620 --> 00:09:05,020
>> Nyt nopeasti eteenpäin 40 vuotta
ja meillä on erilainen ongelma.

203
00:09:05,020 --> 00:09:10,020
Laske on nyt
kallein voimavara.

204
00:09:10,020 --> 00:09:11,470
Varastointi on halpaa.

205
00:09:11,470 --> 00:09:14,570
Tarkoitan, voimme mennä minne tahansa
pilvi ja voimme löytää halpoja varastointi.

206
00:09:14,570 --> 00:09:17,190
Mutta mitä en löydä on halpa laskea.

207
00:09:17,190 --> 00:09:20,700
>> Joten kehitys nykypäivän
teknologia, tietokanta teknologia,

208
00:09:20,700 --> 00:09:23,050
on todella keskittynyt noin
hajautettujen tietokantojen

209
00:09:23,050 --> 00:09:26,960
että eivät kärsi
samantyyppistä mittakaavassa

210
00:09:26,960 --> 00:09:29,240
rajoitukset relaatiotietokantojen.

211
00:09:29,240 --> 00:09:32,080
Puhutaan hieman siitä
mitä se todella tarkoittaa.

212
00:09:32,080 --> 00:09:34,760
>> Mutta yksi syy ja
kuljettaja takana this-- me

213
00:09:34,760 --> 00:09:38,290
puhui tiedot paine.

214
00:09:38,290 --> 00:09:41,920
Tiedot paine on jotain
että innovaatioiden lähde.

215
00:09:41,920 --> 00:09:44,610
Ja jos tarkastellaan yli
viimeisten viiden vuoden aikana,

216
00:09:44,610 --> 00:09:48,180
tämä on kaavio, mitä tietoja
kuormitus koko yrityksen yleisiin

217
00:09:48,180 --> 00:09:49,640
näyttää viimeisten viiden vuoden aikana.

218
00:09:49,640 --> 00:09:52,570
>> Ja Nyrkkisääntönä
nämä days-- jos menet Google--

219
00:09:52,570 --> 00:09:55,290
on 90%: n tietoja, jotka
Tallennamme tänään, ja se oli

220
00:09:55,290 --> 00:09:57,330
joka syntyy kahden viime vuoden aikana.

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

222
00:09:57,911 --> 00:09:59,410
Nyt, tämä ei ole trendi, joka on uusi.

223
00:09:59,410 --> 00:10:01,230
Tämä on suuntaus, joka on ollut
menee ulos 100 vuotta.

224
00:10:01,230 --> 00:10:03,438
Siitä lähtien Herman Hollerith
kehitti reikäkorttikoneilla,

225
00:10:03,438 --> 00:10:08,040
olemme rakentaneet tietovarastot
ja keräämällä tietoja ilmiömäinen hinnat.

226
00:10:08,040 --> 00:10:10,570
>> Joten viime 100 vuotta,
olemme nähneet tämän suuntauksen.

227
00:10:10,570 --> 00:10:11,940
Se ei aio muuttaa.

228
00:10:11,940 --> 00:10:14,789
Jatkossa aiomme nähdä
Tässä, jos ei kiihtynyt suuntaus.

229
00:10:14,789 --> 00:10:16,330
Ja näet mitä se näyttää.

230
00:10:16,330 --> 00:10:23,510
>> Jos yritys vuonna 2010 oli yksi
teratavun tietojen hallinnoitavien,

231
00:10:23,510 --> 00:10:27,080
tänään, että tarkoittaa, että ne ovat
toimitusjohtaja 6.5 petatavua dataa.

232
00:10:27,080 --> 00:10:30,380
Se on 6500 kertaa enemmän tietoa.

233
00:10:30,380 --> 00:10:31,200
Ja tiedän tämän.

234
00:10:31,200 --> 00:10:33,292
Työskentelen näitä yrityksiä päivittäin.

235
00:10:33,292 --> 00:10:35,000
Viisi vuotta sitten, olen
puhuisit yritykset

236
00:10:35,000 --> 00:10:38,260
jotka puhua minulle mitä kipu
se on hallita teratavua dataa.

237
00:10:38,260 --> 00:10:39,700
Ja he puhuvat
minulle miten näemme

238
00:10:39,700 --> 00:10:41,825
että tämä on todennäköisesti aio
olla petatavun tai kaksi

239
00:10:41,825 --> 00:10:43,030
sisällä pari vuotta.

240
00:10:43,030 --> 00:10:45,170
>> Nämä samat yritykset
Tänään olen tapaaminen,

241
00:10:45,170 --> 00:10:48,100
ja he puhuvat minulle
ongelma on siellä ottaa hallintaan

242
00:10:48,100 --> 00:10:51,440
kymmeniä, 20 petatavua dataa.

243
00:10:51,440 --> 00:10:53,590
Niin räjähdys
tiedot alan

244
00:10:53,590 --> 00:10:56,670
ajaa valtava
tarvitset parempia ratkaisuja.

245
00:10:56,670 --> 00:11:00,980
Ja relaatiotietokannan on
vain ole elää jopa kysyntää.

246
00:11:00,980 --> 00:11:03,490
>> Ja niin siellä on lineaarinen
korrelaatio tiedot paineen

247
00:11:03,490 --> 00:11:05,210
ja teknisiä innovaatioita.

248
00:11:05,210 --> 00:11:07,780
Historia on osoittanut
tämä, että ajan mittaan,

249
00:11:07,780 --> 00:11:11,090
kun tietomäärä
joka on käsitelty

250
00:11:11,090 --> 00:11:15,490
ylittää järjestelmän kapasiteetin
käsitellä sitä kohtuullisessa ajassa

251
00:11:15,490 --> 00:11:18,870
tai kohtuullisin kustannuksin,
sitten uudet teknologiat

252
00:11:18,870 --> 00:11:21,080
ovat keksineet ratkaista nämä ongelmat.

253
00:11:21,080 --> 00:11:24,090
Näiden tekniikoiden,
puolestaan ​​avaa oven

254
00:11:24,090 --> 00:11:27,840
toiseen joukko ongelmia, jotka
kerää vieläkin tietoja.

255
00:11:27,840 --> 00:11:29,520
>> Nyt emme aio lopettaa tähän.

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

257
00:11:30,020 --> 00:11:31,228
Emme aio lopettaa tähän.

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

259
00:11:31,830 --> 00:11:35,520
Koska et voi tietää kaikkea
on tietää maailmankaikkeudessa.

260
00:11:35,520 --> 00:11:40,510
Ja niin kauan kuin olemme olleet elossa,
Kautta historian mies,

261
00:11:40,510 --> 00:11:43,440
olemme aina ajanut tietää enemmän.

262
00:11:43,440 --> 00:11:49,840
>> Joten se tuntuu jokaisen sentin siirrymme
tiellä tieteellisen löydön,

263
00:11:49,840 --> 00:11:54,620
Olemme kertomalla datan määrä
että meidän täytyy käsitellä eksponentiaalisesti

264
00:11:54,620 --> 00:11:59,920
kuten me paljastaa enemmän ja enemmän ja enemmän
sen sisäisestä toiminnasta elämän,

265
00:11:59,920 --> 00:12:04,530
siitä, miten maailmankaikkeus toimii, noin
ajo tieteellinen löytö,

266
00:12:04,530 --> 00:12:06,440
ja keksintö, joka
teemme tänään.

267
00:12:06,440 --> 00:12:09,570
Tietomäärä vain
jatkuvasti lisää.

268
00:12:09,570 --> 00:12:12,120
Niin että voimme käsitellä
tämä ongelma on valtava.

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

270
00:12:14,790 --> 00:12:17,410
>> Niin yksi niistä asioista
katsomme kuten miksi NoSQL?

271
00:12:17,410 --> 00:12:19,200
Miten NoSQL ratkaista tämän ongelman?

272
00:12:19,200 --> 00:12:24,980
No, relaatiotietokantojen,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- se on todella konstruktin
ihmissuhteisiin database-- nämä asiat ovat

274
00:12:28,600 --> 00:12:30,770
optimoitu varastointi.

275
00:12:30,770 --> 00:12:33,180
>> Takaisin 70-luvulla, uudelleen,
levy on kallista.

276
00:12:33,180 --> 00:12:36,990
Provisioinnin harjoittaminen varastointi
yrityksessä on loputon.

277
00:12:36,990 --> 00:12:37,490
Tiedän.

278
00:12:37,490 --> 00:12:38,020
Olen elänyt sen.

279
00:12:38,020 --> 00:12:41,250
Kirjoitin varastointi ajurit
enterprised superserver yritys

280
00:12:41,250 --> 00:12:42,470
takaisin 90-luvulla.

281
00:12:42,470 --> 00:12:45,920
Ja tärkeintä on raastava toinen
tallennusjärjestelmä oli vain jotain, joka

282
00:12:45,920 --> 00:12:47,600
tapahtui päivittäin yrityksessä.

283
00:12:47,600 --> 00:12:49,030
Ja se koskaan lopettanut.

284
00:12:49,030 --> 00:12:52,690
Suurempi tiheys varastointi, kysyntä
korkean tiheyden varastointiin,

285
00:12:52,690 --> 00:12:56,340
ja tehokkaamman varastoinnin
devices-- se ei ole koskaan lopettanut.

286
00:12:56,340 --> 00:13:00,160
>> Ja NoSQL on hyvä tekniikka
koska se normalisoi data.

287
00:13:00,160 --> 00:13:02,210
Se de-monistaa tiedot.

288
00:13:02,210 --> 00:13:07,180
Siinä tiedot rakenne, joka
on agnostikko jokaiseen käyttötapa.

289
00:13:07,180 --> 00:13:11,600
Useita sovelluksia voi lyödä, että
SQL-tietokannan, suorita ad hoc kyselyjä,

290
00:13:11,600 --> 00:13:15,950
ja saada tietoja muotoon, että ne
tarvitsevat prosessin niiden työmääriä.

291
00:13:15,950 --> 00:13:17,570
Kuulostaa fantastinen.

292
00:13:17,570 --> 00:13:21,350
Mutta tärkeintä on kanssa tahansa
järjestelmä, jos se on agnostikko kaiken,

293
00:13:21,350 --> 00:13:23,500
se on optimoitu mitään.

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

295
00:13:24,050 --> 00:13:26,386
>> Ja sitähän saamme kanssa
relaatiotietokannan.

296
00:13:26,386 --> 00:13:27,510
Se on optimoitu varastointi.

297
00:13:27,510 --> 00:13:28,280
Se on normalisoitu.

298
00:13:28,280 --> 00:13:29,370
Se on suhteissaan.

299
00:13:29,370 --> 00:13:31,660
Se tukee ad hoc kyselyt.

300
00:13:31,660 --> 00:13:34,000
Ja se ja se skaalaa pystysuunnassa.

301
00:13:34,000 --> 00:13:39,030
>> Jos minun täytyy saada isompi SQL-tietokannan
tai tehokkaampi SQL-tietokannan,

302
00:13:39,030 --> 00:13:41,090
Menen ostaa isompi pala rautaa.

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

304
00:13:41,600 --> 00:13:44,940
Olen työskennellyt paljon asiakkaita
jotka ovat käyneet läpi merkittäviä parannuksia

305
00:13:44,940 --> 00:13:48,340
niiden SQL infrastruktuurissa
selvittää kuusi kuukautta myöhemmin,

306
00:13:48,340 --> 00:13:49,750
he lyömällä seinään uudelleen.

307
00:13:49,750 --> 00:13:55,457
Ja vastaus Oracle tai MSSQL
tai joku muu on saada isompi laatikko.

308
00:13:55,457 --> 00:13:58,540
No ennemmin tai myöhemmin, et voi ostaa
isompi laatikko, ja se on todellinen ongelma.

309
00:13:58,540 --> 00:14:00,080
Meidän on todella muuttaa asioita.

310
00:14:00,080 --> 00:14:01,080
Joten jos tämä toimii?

311
00:14:01,080 --> 00:14:06,560
Se toimii hyvin offline
analytiikan, OLAP-tyypin työtaakka.

312
00:14:06,560 --> 00:14:08,670
Ja se on todella jossa SQL kuuluu.

313
00:14:08,670 --> 00:14:12,540
Nyt sitä käytetään nykyään monissa verkossa
Kaupallisen Processing-tyyppinen

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

315
00:14:13,330 --> 00:14:16,460
Ja se toimii vain sakko
jonkin verran käyttöaste,

316
00:14:16,460 --> 00:14:18,670
mutta se vain ei mittakaavassa
siten, että NoSQL ei.

317
00:14:18,670 --> 00:14:20,660
Ja me puhumme hieman
vähän siitä, miksi näin on.

318
00:14:20,660 --> 00:14:23,590
>> Nyt, NoSQL, toisaalta,
on enemmän optimoitu laskentatehoa.

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

320
00:14:24,540 --> 00:14:26,830
Se ei ole agnostikko
käyttötapa.

321
00:14:26,830 --> 00:14:31,620
Me kutsumme de-normalisoitu
rakenne tai hierarkkisen.

322
00:14:31,620 --> 00:14:35,000
Tiedot relaatiotietokantaan on
liittyneet yhteen useista taulukoista

323
00:14:35,000 --> 00:14:36,850
tuottaa, että tarvitset.

324
00:14:36,850 --> 00:14:40,090
Tiedot NoSQL tietokantaan
tallennetaan asiakirjan

325
00:14:40,090 --> 00:14:42,100
sisältää hierarkkinen rakenne.

326
00:14:42,100 --> 00:14:45,670
Kaikki tiedot, jotka yleensä
liittyneet yhteen tuottamaan että näkymä

327
00:14:45,670 --> 00:14:47,160
tallennetaan yhteen asiakirjaan.

328
00:14:47,160 --> 00:14:50,990
Ja me puhumme hieman siitä
miten se toimii pari kaavioita.

329
00:14:50,990 --> 00:14:55,320
>> Mutta ajatus tässä on, että säilytät
tietosi kuin nämä instantiated näkemyksiä.

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

331
00:14:56,410 --> 00:14:58,610
Skaalaat vaakatasossa.

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

333
00:14:59,556 --> 00:15:02,100
Jos minun täytyy lisätä
koko minun NoSQL klusterin,

334
00:15:02,100 --> 00:15:03,700
En tarvitse saada isompi laatikko.

335
00:15:03,700 --> 00:15:05,200
Saan toiseen ruutuun.

336
00:15:05,200 --> 00:15:07,700
Ja minä klusterin ne yhteen,
ja voin Shard että tiedot.

337
00:15:07,700 --> 00:15:10,780
Puhumme vähän siitä
mitä sharding on, olla

338
00:15:10,780 --> 00:15:14,270
voivat lisätä tietokantaan
useiden fyysiset laitteet

339
00:15:14,270 --> 00:15:18,370
ja poistaa este, joka
vaatii minua mittakaavassa pystysuunnassa.

340
00:15:18,370 --> 00:15:22,080
>> Joten se on todella rakennettu verkossa
tapahtumien käsittelyn ja mittakaavassa.

341
00:15:22,080 --> 00:15:25,480
Siinä on suuri ero
täällä välillä raportointi, eikö?

342
00:15:25,480 --> 00:15:27,810
Raportointi, en tiedä
kysymyksiä Aion kysyä.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- jos joku
minun markkinointiosasto

345
00:15:30,570 --> 00:15:34,520
haluaa just-- kuinka monet minun asiakkaat
on tämä erityispiirre, joka

346
00:15:34,520 --> 00:15:37,850
ostivat tämän day-- En tiedä
mitä kyselyn he aikovat kysyä.

347
00:15:37,850 --> 00:15:39,160
Joten minun täytyy olla agnostikko.

348
00:15:39,160 --> 00:15:41,810
>> Nyt online-
kaupallisen sovelluksen,

349
00:15:41,810 --> 00:15:43,820
Tiedän mitä kysymyksiä pyydän.

350
00:15:43,820 --> 00:15:46,581
Rakensin hakemuksen
hyvin erityinen työnkulkua.

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

352
00:15:47,080 --> 00:15:50,540
Joten jos voin optimoida tiedot
tallentaa tukea että työnkulun,

353
00:15:50,540 --> 00:15:52,020
se tulee olemaan nopeampi.

354
00:15:52,020 --> 00:15:55,190
Ja siksi NoSQL voi
todella nopeuttamaan

355
00:15:55,190 --> 00:15:57,710
Näiden tyyppisiä palveluja.

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

357
00:15:58,210 --> 00:16:00,501
>> Joten aiomme päästä
hieman teoriaa täällä.

358
00:16:00,501 --> 00:16:03,330
Ja jotkut teistä, silmäsi
voi perua hieman.

359
00:16:03,330 --> 00:16:06,936
Mutta yritän pitää sen
korkean tason kuin pystyn.

360
00:16:06,936 --> 00:16:08,880
Joten jos olet hankkeessa
hallinta, siellä

361
00:16:08,880 --> 00:16:12,280
rakenteelle
kolmio rajoitteet.

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

363
00:16:12,936 --> 00:16:16,060
Kolmio rajoitteiden sanelee
et voi olla kaikkea kaiken aikaa.

364
00:16:16,060 --> 00:16:17,750
Ei voi olla sinun kakku ja syödä sitä.

365
00:16:17,750 --> 00:16:22,310
Joten projektinhallintaan, että kolmio
rajoitteet on voit olla se halpa,

366
00:16:22,310 --> 00:16:24,710
voit olla se nopeasti,
tai voit olla se hyvä.

367
00:16:24,710 --> 00:16:25,716
Valitse kaksi.

368
00:16:25,716 --> 00:16:27,090
Koska et voi olla kaikki kolme.

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

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

371
00:16:27,820 --> 00:16:28,920
>> Joten kuulet tästä paljon.

372
00:16:28,920 --> 00:16:31,253
Se on kolminkertainen rajoitus,
kolmio kolminkertainen rajoitus,

373
00:16:31,253 --> 00:16:34,420
tai rauta kolmio on oftentimes--
kun puhut projektipäälliköille,

374
00:16:34,420 --> 00:16:35,420
he puhua tästä.

375
00:16:35,420 --> 00:16:37,640
Nyt tietokantojen
oma rauta kolmio.

376
00:16:37,640 --> 00:16:40,350
Ja rauta kolmio tietojen
me kutsumme YMP lause.

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

378
00:16:41,580 --> 00:16:43,770
>> YMP lause sanelee
miten tietokannat toimivat

379
00:16:43,770 --> 00:16:45,627
alle hyvin erityinen ehto.

380
00:16:45,627 --> 00:16:47,460
Ja me puhumme
mitä tämä edellytys.

381
00:16:47,460 --> 00:16:52,221
Mutta kolme pistettä kolmio,
niin sanoakseni, ovat C, johdonmukaisuus.

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

383
00:16:52,720 --> 00:16:56,760
Joten maatalouspolitiikan johdonmukaisuus tarkoittaa sitä, että kaikki
asiakkaita, jotka voivat käyttää tietokantaa

384
00:16:56,760 --> 00:16:59,084
on aina hyvin
johdonmukainen näkemys tietojen.

385
00:16:59,084 --> 00:17:00,750
Kukaan ei nähdä kaksi eri asiaa.

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

387
00:17:01,480 --> 00:17:04,020
Jos näen tietokanta,
Näen samaa mieltä

388
00:17:04,020 --> 00:17:06,130
minun kumppani, joka näkee
samaan tietokantaan.

389
00:17:06,130 --> 00:17:07,470
Se on johdonmukaisuus.

390
00:17:07,470 --> 00:17:12,099
>> Saatavuus tarkoittaa, että jos
tietokanta verkossa, jos se pääsee,

391
00:17:12,099 --> 00:17:14,760
että kaikki asiakkaat aina
osaa lukea ja kirjoittaa.

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

393
00:17:15,260 --> 00:17:17,010
Joten jokainen asiakas, joka
voi lukea tietokanta

394
00:17:17,010 --> 00:17:18,955
aina voi lukea
tiedot ja kirjoittaa tietoa.

395
00:17:18,955 --> 00:17:21,819
Ja jos näin on,
se saatavilla järjestelmä.

396
00:17:21,819 --> 00:17:24,230
>> Ja kolmas kohta on mitä
kutsumme osio suvaitsevaisuutta.

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

398
00:17:24,730 --> 00:17:28,160
Partition toleranssi välineet
että järjestelmä toimii hyvin

399
00:17:28,160 --> 00:17:32,000
vaikka fyysinen verkko
väliseinät solmujen välillä.

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

401
00:17:32,760 --> 00:17:36,270
Joten solmut klusterin voi
puhua toisilleen, mitä tapahtuu?

402
00:17:36,270 --> 00:17:36,880
Selvä.

403
00:17:36,880 --> 00:17:39,545
>> Joten relaatiotietokantojen choose--
voit valita kaksi näistä.

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

405
00:17:40,045 --> 00:17:43,680
Joten relaatiotietokantojen valita
oltava johdonmukaisia ​​ja käytettävissä.

406
00:17:43,680 --> 00:17:47,510
Jos osio välillä tapahtuu
DataNodes vuonna tietovaraston,

407
00:17:47,510 --> 00:17:48,831
tietokanta kaatuu.

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

409
00:17:49,330 --> 00:17:50,900
Se vain menee alas.

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

411
00:17:51,450 --> 00:17:54,230
>> Ja siksi ne ovat
kasvaa isompi laatikot.

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

413
00:17:54,730 --> 00:17:58,021
Koska siellä on no-- yleensä, klusteri
tietokanta, siellä ei ole kovin monet niistä

414
00:17:58,021 --> 00:17:59,590
jotka toimivat tällä tavoin.

415
00:17:59,590 --> 00:18:03,019
Mutta useimmat tietokannat mittakaavassa
pystysuunnassa yksi laatikko.

416
00:18:03,019 --> 00:18:05,060
Koska niiden on oltava
johdonmukainen ja käytettävissä.

417
00:18:05,060 --> 00:18:10,320
Jos osio oli tarkoitus injektoida,
niin sinun täytyy tehdä valinta.

418
00:18:10,320 --> 00:18:13,720
Sinun täytyy tehdä valita
johdonmukainen ja käytettävissä.

419
00:18:13,720 --> 00:18:16,080
>> Ja sitähän NoSQL tietokantoihin.

420
00:18:16,080 --> 00:18:16,580
Selvä.

421
00:18:16,580 --> 00:18:20,950
Joten NoSQL tietokanta, se
Makuja on kaksi.

422
00:18:20,950 --> 00:18:22,990
Me have-- hyvin, se
tulee monissa makuja,

423
00:18:22,990 --> 00:18:26,140
mutta se on kaksi perus
characteristics-- mitä

424
00:18:26,140 --> 00:18:30,050
kutsuisimme CP tietokanta, tai
johdonmukainen ja osio suvaitsevaisuutta

425
00:18:30,050 --> 00:18:31,040
järjestelmä.

426
00:18:31,040 --> 00:18:34,930
Nämä kaverit tehdä valinta, että kun
solmut menettävät yhteyden toisiinsa,

427
00:18:34,930 --> 00:18:37,091
emme aio sallia
ihmisiä kirjoittamaan enempää.

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

429
00:18:37,590 --> 00:18:41,855
>> Kunnes kyseinen osio on poistettu,
kirjoitusoikeudet on estetty.

430
00:18:41,855 --> 00:18:43,230
Tämä tarkoittaa, että he eivät ole käytettävissä.

431
00:18:43,230 --> 00:18:44,510
He johdonmukainen.

432
00:18:44,510 --> 00:18:46,554
Kun näemme, että
osion pistää itse,

433
00:18:46,554 --> 00:18:48,470
olemme nyt johdonmukaisia,
koska emme aio

434
00:18:48,470 --> 00:18:51,517
jotta tietojen muutos kahden
puolin osion itsenäisesti

435
00:18:51,517 --> 00:18:52,100
toisistaan.

436
00:18:52,100 --> 00:18:54,130
Meidän on
Muodosta yhteys uudelleen

437
00:18:54,130 --> 00:18:56,930
ennen päivitys
data on sallittu.

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

439
00:18:58,120 --> 00:19:02,650
>> Seuraava maku olisi AP järjestelmä,
tai saatavilla ja osioitu

440
00:19:02,650 --> 00:19:03,640
toleranssi järjestelmän.

441
00:19:03,640 --> 00:19:05,320
Nämä kaverit eivät välitä.

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

443
00:19:06,020 --> 00:19:08,960
Mikä tahansa solmu, joka saa
kirjoittaa, otamme sen.

444
00:19:08,960 --> 00:19:11,480
Joten olen jäljittelevän tietoni
useiden solmut.

445
00:19:11,480 --> 00:19:14,730
Nämä solmut saada asiakas, asiakas tulee
vuonna, sanoo, aion kirjoittaa joitakin tietoja.

446
00:19:14,730 --> 00:19:16,300
Solmu sanoo, ei ole ongelma.

447
00:19:16,300 --> 00:19:18,580
Solmu vieressä häntä saa
Kirjoita samalla ennätys,

448
00:19:18,580 --> 00:19:20,405
hän aikoo sanoa mitään ongelmaa.

449
00:19:20,405 --> 00:19:23,030
Jossain takaisin loppupäätä,
että tiedot tulee jäljitellä.

450
00:19:23,030 --> 00:19:27,360
Ja sitten joku tulee ymmärtää,
uh-oh, he järjestelmä ymmärtävät, uh-oh,

451
00:19:27,360 --> 00:19:28,870
että on ollut päivityksen kaksi puolta.

452
00:19:28,870 --> 00:19:30,370
Mitä me teemme?

453
00:19:30,370 --> 00:19:33,210
Ja mitä he tekevät niin on
he tekevät jotain, joka

454
00:19:33,210 --> 00:19:36,080
avulla ne voivat ratkaista, että tiedot valtio.

455
00:19:36,080 --> 00:19:39,000
Ja me puhumme
että seuraavassa kaaviossa.

456
00:19:39,000 --> 00:19:40,000
>> Asia huomauttaa täällä.

457
00:19:40,000 --> 00:19:42,374
Ja en aio saada liian
paljon tähän, koska tämä

458
00:19:42,374 --> 00:19:43,510
joutuu syvään tiedot teoria.

459
00:19:43,510 --> 00:19:46,670
Mutta on kaupallisen
puitteet,

460
00:19:46,670 --> 00:19:50,680
kulkee ihmissuhteisiin, joka
antaa minulle mahdollisuuden turvallisesti tehdä päivityksiä

461
00:19:50,680 --> 00:19:53,760
useita yhteisöjä tietokantaan.

462
00:19:53,760 --> 00:19:58,320
Ja päivitykset tapahtuu
kaikki kerralla tai ei ollenkaan.

463
00:19:58,320 --> 00:20:00,500
Ja tätä kutsutaan ACID liiketoimia.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID antaa meille atomisuuden, johdonmukaisuus,
eristäminen, ja kestävyys.

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

467
00:20:07,070 --> 00:20:13,550
Tämä tarkoittaa atomi, liiketoimia, kaikki
minun päivitykset joko tapahtuu tai sitten eivät.

468
00:20:13,550 --> 00:20:16,570
Johdonmukaisuus tarkoittaa sitä, että
tietokanta aina

469
00:20:16,570 --> 00:20:19,780
tuoda johdonmukainen
tilaan, kun päivityksen.

470
00:20:19,780 --> 00:20:23,900
Minä en koskaan jätä tietokanta
huonossa kunnossa levittämisen jälkeen päivityksen.

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

472
00:20:24,400 --> 00:20:26,720
>> Joten se on hieman erilainen
kuin YMP johdonmukaisuus.

473
00:20:26,720 --> 00:20:29,760
YMP johdonmukaisuus kaikkia minun
asiakkaat voivat aina nähdä tiedot.

474
00:20:29,760 --> 00:20:34,450
ACID johdonmukaisuus tarkoittaa sitä, että kun
liiketoimi on tehty, tiedot on hyvä.

475
00:20:34,450 --> 00:20:35,709
Oma suhteet ovat kaikki hyviä.

476
00:20:35,709 --> 00:20:38,750
En aio poistaa vanhemman rivi
ja jättää nippu orpo lasten

477
00:20:38,750 --> 00:20:40,970
muulla taulukossa.

478
00:20:40,970 --> 00:20:44,320
Se ei voi tapahtua, jos olen johdonmukaisesti
happamassa liiketoimi.

479
00:20:44,320 --> 00:20:49,120
>> Eristäminen tarkoittaa, että liiketoimet
esiintyy aina yksi toisensa jälkeen.

480
00:20:49,120 --> 00:20:51,920
Lopputulos tietojen
on samassa tilassa

481
00:20:51,920 --> 00:20:54,770
ikään kuin nämä liiketoimet
että annettiin samanaikaisesti

482
00:20:54,770 --> 00:20:57,340
teloitettiin sarjaan.

483
00:20:57,340 --> 00:21:00,030
Joten se samanaikaisuuden
ohjaus tietokantaan.

484
00:21:00,030 --> 00:21:04,130
Joten periaatteessa, en voi kasvattaa
sama arvo kahdesti kaksi leikkausta.

485
00:21:04,130 --> 00:21:08,580
>> Mutta jos sanon lisää 1 tätä arvoa,
ja kaksi kauppaa tulevat

486
00:21:08,580 --> 00:21:10,665
ja yritän tehdä sen, yksi on
menossa sinne ensin

487
00:21:10,665 --> 00:21:12,540
ja toinen on
menossa sinne jälkeen.

488
00:21:12,540 --> 00:21:15,210
Joten lopulta, lisäsin kaksi.

489
00:21:15,210 --> 00:21:16,170
Näetkö mitä tarkoitan?

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

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

492
00:21:19,220 --> 00:21:21,250
>> Kestävyys on melko yksinkertainen.

493
00:21:21,250 --> 00:21:23,460
Kun kauppa
kuitataan, se on

494
00:21:23,460 --> 00:21:26,100
olemaan siellä jopa
jos järjestelmä kaatuu.

495
00:21:26,100 --> 00:21:29,230
Kun että järjestelmä ottaa talteen, että
tapahtuma, joka on tehty

496
00:21:29,230 --> 00:21:30,480
on todella olemaan siellä.

497
00:21:30,480 --> 00:21:33,130
Niin, että takaukset
Acid liiketoimia.

498
00:21:33,130 --> 00:21:35,470
Ne ovat ihan kivoja takuut
on tietokantaan,

499
00:21:35,470 --> 00:21:36,870
mutta ne tulevat nämä kustannukset.

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

501
00:21:37,640 --> 00:21:40,520
>> Koska ongelma
näiden puitteiden on

502
00:21:40,520 --> 00:21:44,540
jos on osion tiedot
setti, minun täytyy tehdä päätös.

503
00:21:44,540 --> 00:21:48,000
Aion on sallittava
päivitykset toisella puolella tai toisella.

504
00:21:48,000 --> 00:21:50,310
Ja jos näin tapahtuu,
sitten En ole enää menossa

505
00:21:50,310 --> 00:21:52,630
pystyä säilyttämään
nämä ominaisuudet.

506
00:21:52,630 --> 00:21:53,960
Ne eivät ole johdonmukaisia.

507
00:21:53,960 --> 00:21:55,841
Niitä ei eristetty.

508
00:21:55,841 --> 00:21:58,090
Tämä on, jos se hajoaa
varten relaatiotietokantojen.

509
00:21:58,090 --> 00:22:01,360
Tämä on syy relaatio
tietokantoja mittakaavassa pystysuunnassa.

510
00:22:01,360 --> 00:22:05,530
>> Toisaalta, meillä on
mitä kutsutaan BASE tekniikkaa.

511
00:22:05,530 --> 00:22:07,291
Ja nämä ovat NoSQL Tietokannat.

512
00:22:07,291 --> 00:22:07,790
Selvä.

513
00:22:07,790 --> 00:22:10,180
Joten meillä on CP, AP tietokantoja.

514
00:22:10,180 --> 00:22:14,720
Ja nämä ovat mitä te kutsutte pohjimmiltaan
käytettävissä, pehmeä valtio, lopulta

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

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

517
00:22:16,420 --> 00:22:19,690
>> Periaatteessa käytettävissä, koska
he osio suvaitsevainen.

518
00:22:19,690 --> 00:22:21,470
Ne ovat aina
siellä, vaikka siellä

519
00:22:21,470 --> 00:22:23,053
verkon osion solmujen välillä.

520
00:22:23,053 --> 00:22:25,900
Jos voin puhua solmuun, olen
tulee pystyä lukemaan dataa.

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

522
00:22:26,460 --> 00:22:30,810
En ehkä ole aina osaa kirjoittaa
tiedot, jos olen johdonmukaisesti alusta.

523
00:22:30,810 --> 00:22:32,130
Mutta minä voi lukea tietoja.

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

525
00:22:34,960 --> 00:22:38,010
>> Pehmeä tila ilmaisee
että kun luin, että tiedot,

526
00:22:38,010 --> 00:22:40,790
se ei ehkä ole sama kuin muut solmut.

527
00:22:40,790 --> 00:22:43,390
Jos oikeus annettiin solmu
jossain muualla klusterin

528
00:22:43,390 --> 00:22:46,650
ja se ei ole mallia koko
klusterin mutta kun luin, että tiedot,

529
00:22:46,650 --> 00:22:48,680
että valtio ei ehkä ole johdonmukaisia.

530
00:22:48,680 --> 00:22:51,650
Kuitenkin, se on
lopulta johdonmukainen,

531
00:22:51,650 --> 00:22:53,870
mikä tarkoittaa, että kun kirjoittaa
on tehty järjestelmään,

532
00:22:53,870 --> 00:22:56,480
se monistuu poikki solmujen.

533
00:22:56,480 --> 00:22:59,095
Ja lopulta, että valtio
saatetaan kuntoon,

534
00:22:59,095 --> 00:23:00,890
ja se on johdonmukainen valtio.

535
00:23:00,890 --> 00:23:05,000
>> Nyt CAP lause todella
pelaa vain yksi ehto.

536
00:23:05,000 --> 00:23:08,700
Tämä edellytys on, kun tämä tapahtuu.

537
00:23:08,700 --> 00:23:13,710
Koska aina se toimii
normaalitilassa, ei ole osio,

538
00:23:13,710 --> 00:23:16,370
kaikki on johdonmukainen ja käytettävissä.

539
00:23:16,370 --> 00:23:19,990
Olet vain huolissasi YMP
kun meillä on osion.

540
00:23:19,990 --> 00:23:21,260
Joten ne ovat harvinaisia.

541
00:23:21,260 --> 00:23:25,360
Mutta miten järjestelmä reagoi, kun ne
esiintyy sanella minkälainen järjestelmä

542
00:23:25,360 --> 00:23:26,750
olemme tekemisissä.

543
00:23:26,750 --> 00:23:31,110
>> Joten katsomaan mitä
joka näyttää AP järjestelmiä.

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

545
00:23:32,621 --> 00:23:34,830
AP järjestelmät tulevat kaksi makua.

546
00:23:34,830 --> 00:23:38,514
Ne tulevat maku, joka on
Master Master, 100%, aina käytettävissä.

547
00:23:38,514 --> 00:23:40,430
Ja he tulevat
muut maku, jossa sanotaan,

548
00:23:40,430 --> 00:23:43,330
Tiedätkö mitä, aion huolehtia
tästä osiointi asia

549
00:23:43,330 --> 00:23:44,724
kun todellinen osio tapahtuu.

550
00:23:44,724 --> 00:23:47,890
Muuten, siellä tulee olemaan ensisijainen
solmut kuka ottaa oikeuksia.

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

552
00:23:48,500 --> 00:23:50,040
>> Joten jos me jotain Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra olisi mestari
mestari, nyt minua kirjoittamaan mitään solmuun.

554
00:23:54,440 --> 00:23:55,540
Mitä tapahtuu?

555
00:23:55,540 --> 00:23:58,270
Joten minulla on esineen
tietokanta, joka on olemassa kaksi solmua.

556
00:23:58,270 --> 00:24:01,705
Kutsukaamme että esine S.
Joten meillä on valtio S.

557
00:24:01,705 --> 00:24:04,312
Meillä on joitakin toimintoja
S, jotka ovat käynnissä.

558
00:24:04,312 --> 00:24:06,270
Cassandra antaa minulle
kirjoittaa useita solmuja.

559
00:24:06,270 --> 00:24:08,550
Joten sanokaamme saan
kirjoittaa s kaksi solmua.

560
00:24:08,550 --> 00:24:12,274
No, mitä päätyy tapahtuu on
kutsumme että osioinnin tapahtuma.

561
00:24:12,274 --> 00:24:14,190
Siellä ei voi olla
fyysinen verkko osio.

562
00:24:14,190 --> 00:24:15,950
Mutta koska muotoilu
järjestelmän, se on

563
00:24:15,950 --> 00:24:18,449
todella osiointi heti
kun saan kirjoittaa kaksi solmua.

564
00:24:18,449 --> 00:24:20,830
Se ei pakottaa minut
kirjoittaa kaikki läpi yksi solmu.

565
00:24:20,830 --> 00:24:22,340
Olen kirjallisesti kaksi solmua.

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

567
00:24:23,330 --> 00:24:25,740
>> Joten nyt minulla on kaksi valtiota.

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

569
00:24:26,360 --> 00:24:28,110
Mitä tulee tapahtumaan
on ennemmin tai myöhemmin,

570
00:24:28,110 --> 00:24:29,960
siellä tulee olemaan replikointi tapahtuma.

571
00:24:29,960 --> 00:24:33,300
Siellä tulee olemaan mitä me
kutsutaan osio hyödyntämistä, joka

572
00:24:33,300 --> 00:24:35,200
on, jos nämä kaksi
valtiot palata yhteen

573
00:24:35,200 --> 00:24:37,310
ja siellä tulee olemaan algoritmi
joka kulkee sisällä tietokanta,

574
00:24:37,310 --> 00:24:38,540
päättää mitä tehdä.

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

576
00:24:39,110 --> 00:24:43,057
Oletuksena, Viimeksi päivitetty
voittaa useimmissa AP järjestelmissä.

577
00:24:43,057 --> 00:24:44,890
Joten siellä on yleensä
Oletuksena algoritmi, mitä

578
00:24:44,890 --> 00:24:47,400
he kutsuvat soittopyynnön
toiminto, mikä

579
00:24:47,400 --> 00:24:51,000
soitetaan, kun tämä ehto
havaitaan suorittaa jotain logiikkaa

580
00:24:51,000 --> 00:24:52,900
ratkaisemiseksi että konflikti.

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

582
00:24:53,850 --> 00:24:58,770
Oletuksena soittopyynnön ja oletuksena
resolverin useimmissa AP tietokannoissa

583
00:24:58,770 --> 00:25:01,130
on, arvaa mitä, aikaleima voittaa.

584
00:25:01,130 --> 00:25:02,380
Tämä oli viimeinen päivitys.

585
00:25:02,380 --> 00:25:04,320
Aion laittaa että päivitys siellä.

586
00:25:04,320 --> 00:25:08,440
Saatan dump tämä ennätys että minä
polkumyynnillä pois osaksi elpyminen loki

587
00:25:08,440 --> 00:25:11,670
niin että käyttäjä voi palata myöhemmin
ja sanoa, hei, oli törmäys.

588
00:25:11,670 --> 00:25:12,320
Mitä tapahtui?

589
00:25:12,320 --> 00:25:16,370
Ja voit itse dumpata kirjaa
kaikki törmäykset ja rollbacks

590
00:25:16,370 --> 00:25:17,550
ja katso mitä tapahtuu.

591
00:25:17,550 --> 00:25:21,580
>> Nyt, kun käyttäjä, voit myös
sisältävät logiikan tuohon soittopyynnön.

592
00:25:21,580 --> 00:25:24,290
Joten voit muuttaa että
soittopyynnön toiminta.

593
00:25:24,290 --> 00:25:26,730
Voit sanoa, hei, haluan
kunnostamiseksi näitä tietoja.

594
00:25:26,730 --> 00:25:28,880
Ja haluan kokeilla ja
yhdistää nämä kaksi kirjaa.

595
00:25:28,880 --> 00:25:30,050
Mutta se on sinun.

596
00:25:30,050 --> 00:25:32,880
Tietokanta ei osaa
tehdä oletuksena. Useimmat aika,

597
00:25:32,880 --> 00:25:34,850
ainoa asia tietokanta
osaa tehdä on sanoa,

598
00:25:34,850 --> 00:25:36,100
tämä oli viimeinen ennätys.

599
00:25:36,100 --> 00:25:39,183
Se on se, joka tulee voittaa,
ja se on arvo aion laittaa.

600
00:25:39,183 --> 00:25:41,490
Kun että osio hyödyntämistä
ja replikointi tapahtuu,

601
00:25:41,490 --> 00:25:43,930
meillä on valtio, joka
on nyt n tärkein, mikä on

602
00:25:43,930 --> 00:25:46,890
yhdistämisen tilan kaikki nämä esineet.

603
00:25:46,890 --> 00:25:49,700
Joten AP järjestelmissä on tämä.

604
00:25:49,700 --> 00:25:51,615
CP järjestelmät eivät tarvitse
huolestua.

605
00:25:51,615 --> 00:25:54,490
Sillä heti osio tulee
peliin, he vain lopeta

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

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

608
00:25:56,180 --> 00:25:58,670
Niin, että on erittäin helppo
käsitellä johdonmukainen

609
00:25:58,670 --> 00:26:01,330
kun et hyväksy mitään päivityksiä.

610
00:26:01,330 --> 00:26:04,620
Se CP järjestelmien tehdä.

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

612
00:26:05,120 --> 00:26:07,590
>> Joten puhua vähän
vähän siitä pääsy kuvioita.

613
00:26:07,590 --> 00:26:11,580
Kun puhumme NoSQL, se on
All About käyttötapa.

614
00:26:11,580 --> 00:26:13,550
Nyt SQL on tilapäinen, kyselyt.

615
00:26:13,550 --> 00:26:14,481
Se on relaatio myymälä.

616
00:26:14,481 --> 00:26:16,480
Meillä ei tarvitse huolehtia
noin käyttötapa.

617
00:26:16,480 --> 00:26:17,688
Kirjoitan hyvin monimutkainen kyselyn.

618
00:26:17,688 --> 00:26:19,250
Se menee ja saa tiedot.

619
00:26:19,250 --> 00:26:21,210
Sitähän tämä näyttää
kuten, normalisointi.

620
00:26:21,210 --> 00:26:24,890
>> Joten tässä erityinen rakenne,
me tarkastelemme tuotteita luettelo.

621
00:26:24,890 --> 00:26:26,640
Minulla on erilaisia ​​tuotteita.

622
00:26:26,640 --> 00:26:27,217
Minulla on kirjoja.

623
00:26:27,217 --> 00:26:27,800
Minulla albumeita.

624
00:26:27,800 --> 00:26:30,090
Minulla on videoita.

625
00:26:30,090 --> 00:26:33,370
Suhde tuotteet
ja jokin näistä kirjoista, albumit,

626
00:26:33,370 --> 00:26:34,860
ja videot taulukot on 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Minulla tuotteen tunnus,
ja että tunnus vastaa

629
00:26:38,860 --> 00:26:41,080
kirjaan, albumin, tai videon.

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

631
00:26:41,580 --> 00:26:44,350
Se on 1: 1 suhde
yli kyseiset taulukot.

632
00:26:44,350 --> 00:26:46,970
>> Nyt books-- kaikki ne
on on juuri ominaisuuksia.

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

634
00:26:47,550 --> 00:26:48,230
Sepä hienoa.

635
00:26:48,230 --> 00:26:52,130
Yksi-yhteen suhde, saan kaikki
tiedot Minun täytyy kuvata että kirja.

636
00:26:52,130 --> 00:26:54,770
Albums-- albumeilla on kappaleita.

637
00:26:54,770 --> 00:26:56,470
Tämä on mitä me kutsumme yhdeltä monelle.

638
00:26:56,470 --> 00:26:58,905
Jokainen albumi voi olla monia kappaleita.

639
00:26:58,905 --> 00:27:00,780
Joten jokaisen kappaleen
albumi, voisin olla

640
00:27:00,780 --> 00:27:02,570
toinen ennätys tämän lapsen taulukossa.

641
00:27:02,570 --> 00:27:04,680
Joten luon yksi ennätys
minun albumia taulukossa.

642
00:27:04,680 --> 00:27:06,700
Luon useita tietueita
vuonna kappaleita taulukossa.

643
00:27:06,700 --> 00:27:08,850
Yksi-moneen.

644
00:27:08,850 --> 00:27:11,220
>> Tämä suhde on mitä
kutsumme monia-moneen.

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

646
00:27:11,750 --> 00:27:17,000
Huomaatte, että toimijat voisivat olla
monissa elokuvissa, monet videoita.

647
00:27:17,000 --> 00:27:21,450
Joten mitä teemme on laitamme tämä kartoitus
sekä kyseisiä, jotka se vain

648
00:27:21,450 --> 00:27:24,040
kartat näyttelijä ID videon tunnus.

649
00:27:24,040 --> 00:27:28,464
Nyt voin luoda kyselyn liittyy
videoita kautta näyttelijä videon toimijoille,

650
00:27:28,464 --> 00:27:31,130
ja se antaa minulle mukava luettelo
kaikki elokuvat ja kaikki toimijat

651
00:27:31,130 --> 00:27:32,420
jotka olivat siinä elokuvassa.

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

653
00:27:33,290 --> 00:27:33,880
Joten tässä sitä mennään.

654
00:27:33,880 --> 00:27:38,040
Yksi-yhteen on huipputason
suhde; yksi-moneen,

655
00:27:38,040 --> 00:27:40,240
albumit kappaleita; monet-moneen.

656
00:27:40,240 --> 00:27:44,990
Ne ovat kolme huipputason
suhteet tahansa tietokantaan.

657
00:27:44,990 --> 00:27:48,050
Jos tiedät, miten nämä
suhteet toimivat yhdessä,

658
00:27:48,050 --> 00:27:51,490
niin tiedät paljon
noin tietokanta jo.

659
00:27:51,490 --> 00:27:55,660
Joten NoSQL toimii hieman eri tavalla.

660
00:27:55,660 --> 00:27:58,930
Ajatellaanpa toista mitä se
Näyttää mennä saada kaikki minun tuotteet.

661
00:27:58,930 --> 00:28:01,096
>> Vuonna relational myymälä, I
haluavat saada kaikki minun tuotteet

662
00:28:01,096 --> 00:28:02,970
on luettelo kaikista minun tuotteita.

663
00:28:02,970 --> 00:28:04,910
Se on paljon kyselyitä.

664
00:28:04,910 --> 00:28:07,030
Sain kyselyn kaikille minun kirjoja.

665
00:28:07,030 --> 00:28:08,470
Sain kyselyn minun albumia.

666
00:28:08,470 --> 00:28:09,970
Ja sain kyselyn kaikki minun videoita.

667
00:28:09,970 --> 00:28:11,719
Ja sain laittaa sen
kaikki yhdessä luettelossa

668
00:28:11,719 --> 00:28:15,250
ja palvella sitä takaisin jopa
sovellus, joka on sitä pyytäville.

669
00:28:15,250 --> 00:28:18,000
>> Saan kirjoja, liityn
Tuotteet ja kirjat.

670
00:28:18,000 --> 00:28:21,680
Saan albumit, sain liittyä
Tuotteet, Albumit, ja jälkien.

671
00:28:21,680 --> 00:28:25,330
Ja saan videoita, minulla on
liittyä Tuotteet videot,

672
00:28:25,330 --> 00:28:28,890
liittyä kautta Näyttelijä Videot,
ja tuo Näyttelijät.

673
00:28:28,890 --> 00:28:31,020
Niin, että kolme kyselyitä.

674
00:28:31,020 --> 00:28:34,560
Hyvin monimutkainen kyselyitä
koota yksi tulosjoukko.

675
00:28:34,560 --> 00:28:36,540
>> Se on vähemmän kuin optimaalinen.

676
00:28:36,540 --> 00:28:39,200
Siksi kun puhumme
noin tietorakenne, joka on

677
00:28:39,200 --> 00:28:42,900
rakennettu mahdollisimman agnostikko pääsy
pattern-- hyvin, että on hienoa.

678
00:28:42,900 --> 00:28:45,730
Ja voit nähdä tämä on todella
mukava miten olemme järjestetty tiedot.

679
00:28:45,730 --> 00:28:46,550
Ja tiedätkö mitä?

680
00:28:46,550 --> 00:28:49,750
Minulla on vain yksi ennätys näyttelijä.

681
00:28:49,750 --> 00:28:50,440
>> Hyvä juttu.

682
00:28:50,440 --> 00:28:53,750
Olen deduplicated kaikki minun toimijoita,
ja minä säilyttäneet yhdistykset

683
00:28:53,750 --> 00:28:55,200
tässä mappaustaulukon.

684
00:28:55,200 --> 00:29:00,620
Kuitenkin saada tiedot
ulos tulee kalliiksi.

685
00:29:00,620 --> 00:29:04,500
Lähetän CPU koko järjestelmän
liittymällä nämä tietorakenteita yhdessä

686
00:29:04,500 --> 00:29:05,950
pystyä vetämään että tiedot takaisin.

687
00:29:05,950 --> 00:29:07,310
>> Joten miten saan noin, että?

688
00:29:07,310 --> 00:29:11,200
Vuonna NoSQL se on noin
yhdistäminen, ei normalisointi.

689
00:29:11,200 --> 00:29:13,534
Joten haluamme sanoa haluamme
tukea käyttötapa.

690
00:29:13,534 --> 00:29:15,283
Jos käyttötapa
sovelluksiin,

691
00:29:15,283 --> 00:29:16,770
Minun täytyy saada kaikki minun tuotteet.

692
00:29:16,770 --> 00:29:19,027
Laitetaan kaikki tuotteet yhdessä taulukossa.

693
00:29:19,027 --> 00:29:22,110
Jos laitan kaikki tuotteita yhteen taulukossa,
Voin vain valita kaikki tuotteet

694
00:29:22,110 --> 00:29:23,850
tästä taulukosta ja saan kaiken.

695
00:29:23,850 --> 00:29:25,240
No miten voin tehdä sen?

696
00:29:25,240 --> 00:29:28,124
No NoSQL ei ole
rakenne pöytään.

697
00:29:28,124 --> 00:29:30,540
Puhutaan hieman siitä
miten tämä toimii Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Mutta sinulla ei ole sama
ominaisuudet ja samat ominaisuudet

699
00:29:33,570 --> 00:29:37,751
jokaisessa rivissä, jokaisessa
erä, kuten te tehdä SQL taulukossa.

700
00:29:37,751 --> 00:29:39,750
Ja mitä tämä antaa minulle
tehdä, on paljon asioita

701
00:29:39,750 --> 00:29:41,124
ja antaa minulle paljon joustavuutta.

702
00:29:41,124 --> 00:29:45,360
Tässä nimenomaisessa tapauksessa, I
minun tuote asiakirjoja.

703
00:29:45,360 --> 00:29:49,090
Ja tässä nimenomaisessa
Esimerkiksi kaikki

704
00:29:49,090 --> 00:29:51,930
on asiakirja Tuotteet taulukossa.

705
00:29:51,930 --> 00:29:56,510
Ja tuote kirja pitää
on tyyppi tunnus, joka määrittelee kirja.

706
00:29:56,510 --> 00:29:59,180
Ja hakemus
siirtyvänsä tästä tunnus.

707
00:29:59,180 --> 00:30:02,570
>> Sovellustasolla tason, aion
sanoa oh, mikä tyyppi on tämä?

708
00:30:02,570 --> 00:30:04,100
Voi, se on kirja ennätys.

709
00:30:04,100 --> 00:30:05,990
Kirja Records on nämä ominaisuudet.

710
00:30:05,990 --> 00:30:08,100
Saanen luoda kirjan objekti.

711
00:30:08,100 --> 00:30:11,289
Joten aion täyttää
kirja esine tämän kohteen.

712
00:30:11,289 --> 00:30:13,080
Esityslistalla tulee ja
sanoo, mitä tämän kohteen?

713
00:30:13,080 --> 00:30:14,560
No tämä tuote on albumi.

714
00:30:14,560 --> 00:30:17,340
Voi, sain kokonaan eri
käsittely rutiini, että

715
00:30:17,340 --> 00:30:18,487
koska se albumi.

716
00:30:18,487 --> 00:30:19,320
Näetkö mitä tarkoitan?

717
00:30:19,320 --> 00:30:21,950
>> Joten hakemus tier-- I
valitse vain kaikki nämä tiedot.

718
00:30:21,950 --> 00:30:23,200
Ne kaikki alkavat tulossa.

719
00:30:23,200 --> 00:30:24,680
Ne voisivat olla kaikki erilaisia.

720
00:30:24,680 --> 00:30:27,590
Ja se on sovelluksen logiikka
että kytkimet yli nämä tyypit

721
00:30:27,590 --> 00:30:29,530
ja päättää miten käsitellä niitä.

722
00:30:29,530 --> 00:30:33,640
>> Taas, joten olemme optimoimalla
skeema käyttötapa.

723
00:30:33,640 --> 00:30:36,390
Teemme sen
romahtamassa kyseiset taulukot.

724
00:30:36,390 --> 00:30:39,670
Olemme periaatteessa ottaen
nämä normalisoitu rakenteet,

725
00:30:39,670 --> 00:30:42,000
ja me rakennamme
hierarkkiset rakenteet.

726
00:30:42,000 --> 00:30:45,130
Sisällä jokainen näistä kirjaa
Aion nähdä array ominaisuuksia.

727
00:30:45,130 --> 00:30:49,400
>> Inside tämä asiakirja Albumit,
Näen ryhmät kappaleita.

728
00:30:49,400 --> 00:30:53,900
Ne kappaleet nyt become-- se
pohjimmiltaan tämä lapsi taulukko että

729
00:30:53,900 --> 00:30:56,520
olemassa täällä tässä rakenteessa.

730
00:30:56,520 --> 00:30:57,975
Voit siis tehdä tämän DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Voit tehdä tämän MongoDB.

732
00:30:59,810 --> 00:31:01,437
Voit tehdä tämän missä tahansa NoSQL tietokantaan.

733
00:31:01,437 --> 00:31:03,520
Luo nämä tyypit
hierarkkinen tietorakenteita

734
00:31:03,520 --> 00:31:07,120
joiden avulla voit hakea tietoja
hyvin nopeasti, koska nyt olen

735
00:31:07,120 --> 00:31:08,537
ei tarvitse noudattaa.

736
00:31:08,537 --> 00:31:11,620
Kun asetan rivin osaksi Kappaleet
pöytä tai rivi osaksi Albumit pöytä,

737
00:31:11,620 --> 00:31:13,110
Minun on noudatettava, että kaava.

738
00:31:13,110 --> 00:31:18,060
Minun on ominaisuus tai
omaisuus, joka on määritelty kyseisen taulukon.

739
00:31:18,060 --> 00:31:20,480
Jokainen heistä,
kun asetan että rivin.

740
00:31:20,480 --> 00:31:21,910
Se ei tapahtunut NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Voin olla täysin erilainen
ominaisuudet jokaisessa asiakirjassa

742
00:31:24,440 --> 00:31:26,100
että asetan osaksi kokoelma.

743
00:31:26,100 --> 00:31:30,480
Joten erittäin voimakas mekanismi.

744
00:31:30,480 --> 00:31:32,852
Ja se on todella miten
optimoida järjestelmän.

745
00:31:32,852 --> 00:31:35,310
Koska nyt että kysely, sen sijaan
liittyä kaikki nämä taulukot

746
00:31:35,310 --> 00:31:39,160
ja täytäntöönpanosta puoli tusinaa kyselyt
vetäytyä tiedot minä tarvitsen,

747
00:31:39,160 --> 00:31:40,890
Olen täytäntöönpanosta yksi kysely.

748
00:31:40,890 --> 00:31:43,010
Ja olen iteroimalla
poikki tulokset asetettu.

749
00:31:43,010 --> 00:31:46,512
se antaa käsityksen
voiman NoSQL.

750
00:31:46,512 --> 00:31:49,470
Aion eräänlainen mennä sivuttain täällä
ja puhua hieman tästä.

751
00:31:49,470 --> 00:31:53,240
Tämä on enemmän sellaista
markkinointi tai technology--

752
00:31:53,240 --> 00:31:55,660
markkinointi tekniikka
tyyppinen keskustelu.

753
00:31:55,660 --> 00:31:58,672
Mutta on tärkeää ymmärtää
koska jos katsomme alkuun

754
00:31:58,672 --> 00:32:00,380
täällä tällä kaavio,
mitä me tarkastelemme

755
00:32:00,380 --> 00:32:04,030
kutsumme
teknologia hype käyrä.

756
00:32:04,030 --> 00:32:06,121
Ja mitä tämä tarkoittaa
uusia juttuja tulee pelata.

757
00:32:06,121 --> 00:32:07,120
Ihmiset ajattelevat, se on hienoa.

758
00:32:07,120 --> 00:32:09,200
Olen ratkaista kaikki minun ongelmia.

759
00:32:09,200 --> 00:32:11,630
>> Tämä voisi olla lopussa
kaikki, on kaikki kaikkeen.

760
00:32:11,630 --> 00:32:12,790
Ja he alkavat käyttää sitä.

761
00:32:12,790 --> 00:32:14,720
Ja he sanovat, tätä tavaraa ei toimi.

762
00:32:14,720 --> 00:32:17,600
Tämä ei ole oikein.

763
00:32:17,600 --> 00:32:19,105
Vanhoja juttuja oli parempi.

764
00:32:19,105 --> 00:32:21,230
Ja he menevät takaisin tekemään
asiat niin kuin ne olivat.

765
00:32:21,230 --> 00:32:22,730
Ja sitten lopulta
ne menevät, tiedätkö mitä?

766
00:32:22,730 --> 00:32:24,040
Tämä tavaraa ei ole niin paha.

767
00:32:24,040 --> 00:32:26,192
Voi, että se toimii.

768
00:32:26,192 --> 00:32:28,900
Ja kun he selvittää, miten se
teoksia, ne alkavat paranemassa.

769
00:32:28,900 --> 00:32:32,050
>> Ja hauska juttu siitä
on, se tavallaan linjassa mitä

770
00:32:32,050 --> 00:32:34,300
kutsumme teknologian käyttöönotto Curve.

771
00:32:34,300 --> 00:32:36,910
Mitä tapahtuu on meillä
jonkinlainen teknologia laukaista.

772
00:32:36,910 --> 00:32:39,100
Kun on kyse tietokannoista,
se on tietoja paine.

773
00:32:39,100 --> 00:32:42,200
Puhuimme korkea vesipisteitä
Tietojen paine koko ajan.

774
00:32:42,200 --> 00:32:46,310
Kun tietojen paine osuu tietty
kohta, joka on teknologia laukaista.

775
00:32:46,310 --> 00:32:47,830
>> Se on tulossa liian kallis.

776
00:32:47,830 --> 00:32:49,790
Se kestää liian kauan käsitellä tietoja.

777
00:32:49,790 --> 00:32:50,890
Tarvitsemme jotain parempaa.

778
00:32:50,890 --> 00:32:52,890
Saat innovaattorit
siellä juoksee ympäriinsä,

779
00:32:52,890 --> 00:32:55,050
yrittää selvittää, mitä ratkaisu.

780
00:32:55,050 --> 00:32:56,050
Mitä uusi idea?

781
00:32:56,050 --> 00:32:58,170
>> Mikä on seuraava paras
tapa tehdä tämä asia?

782
00:32:58,170 --> 00:32:59,530
Ja he keksivät jotain.

783
00:32:59,530 --> 00:33:03,140
Ja ihmiset todellista tuskaa,
pojat verenvuoto reuna,

784
00:33:03,140 --> 00:33:06,390
he hypätä kaikki yli sen,
koska he tarvitsevat vastauksen.

785
00:33:06,390 --> 00:33:09,690
Nyt mitä väistämättä happens-- ja
se tapahtuu juuri nyt NoSQL.

786
00:33:09,690 --> 00:33:11,090
Näen sitä koko ajan.

787
00:33:11,090 --> 00:33:13,610
>> Mitä väistämättä tapahtuu on
ihmiset alkavat käyttää uutta työkalua

788
00:33:13,610 --> 00:33:15,490
samalla tavalla kuin käytetään vanha työkalu.

789
00:33:15,490 --> 00:33:17,854
Ja he selville sitä
ei toimi niin hyvin.

790
00:33:17,854 --> 00:33:20,020
En muista kuka olin
puhuu aiemmin tänään.

791
00:33:20,020 --> 00:33:22,080
Mutta se on kuin, kun
jackhammer keksittiin,

792
00:33:22,080 --> 00:33:24,621
ihmiset eivät käännä se
päätään murskata betoni.

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

794
00:33:27,360 --> 00:33:30,610
>> Mutta se on mitä
tapahtuu NoSQL tänään.

795
00:33:30,610 --> 00:33:33,900
Jos kävelet sisään useimmat kaupat,
he yrittävät olla NoSQL kauppoja.

796
00:33:33,900 --> 00:33:36,510
Mitä he tekevät on
he käyttävät NoSQL,

797
00:33:36,510 --> 00:33:39,900
ja he sen lataamista
täynnä relaatio kaava.

798
00:33:39,900 --> 00:33:41,630
Koska näin
ne suunnittelevat tietokantoja.

799
00:33:41,630 --> 00:33:44,046
Ja he ihmettelevät, miksi on
se ei toimi kovin hyvin?

800
00:33:44,046 --> 00:33:45,230
Poika, tämä asia haisee.

801
00:33:45,230 --> 00:33:49,900
Jouduin pitämään kaikki minun
liittyy in-- se on kuin, ei, ei.

802
00:33:49,900 --> 00:33:50,800
Ylläpitää liittyy?

803
00:33:50,800 --> 00:33:52,430
Miksi liittyä tietoja?

804
00:33:52,430 --> 00:33:54,350
Sinun ei liity tietoja NoSQL.

805
00:33:54,350 --> 00:33:55,850
Voit yhdistää sen.

806
00:33:55,850 --> 00:34:00,690
>> Joten jos haluat välttää tämän, oppia
miten työkalu toimii ennen kuin itse

807
00:34:00,690 --> 00:34:02,010
alkaa käyttää sitä.

808
00:34:02,010 --> 00:34:04,860
Älä yritä käyttää uusia välineitä
Samoin käytit vanhoja työkaluja.

809
00:34:04,860 --> 00:34:06,500
Olet menossa on huonoja kokemuksia.

810
00:34:06,500 --> 00:34:08,848
Ja joka ikinen kerta
sitähän tämä on noin.

811
00:34:08,848 --> 00:34:11,389
Kun me alkaa tulla tänne,
se johtuu siitä, ihmiset tajunnut

812
00:34:11,389 --> 00:34:13,449
miten käyttää työkaluja.

813
00:34:13,449 --> 00:34:16,250
>> He tekivät saman asian, kun
relaatiotietokantojen keksittiin,

814
00:34:16,250 --> 00:34:17,969
ja ne korvaavat tiedostojärjestelmää.

815
00:34:17,969 --> 00:34:20,420
He yrittivät rakentaa tiedostojärjestelmien
relaatiotietokantojen

816
00:34:20,420 --> 00:34:22,159
koska se mitä ihmiset ymmärtää.

817
00:34:22,159 --> 00:34:23,049
Se ei toiminut.

818
00:34:23,049 --> 00:34:26,090
Niin ymmärtää parhaita käytäntöjä
teknologian olet työskennellyt

819
00:34:26,090 --> 00:34:26,730
on valtava.

820
00:34:26,730 --> 00:34:29,870
Erittäin tärkeä.

821
00:34:29,870 --> 00:34:32,440
>> Joten aiomme päästä DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB on AWS: n
täysin onnistuneet NoSQL alustalla.

823
00:34:36,480 --> 00:34:37,719
Mitä täysin onnistuneet tarkoittaa?

824
00:34:37,719 --> 00:34:40,010
Se tarkoittaa sinun ei tarvitse
todella huolehtia mistään.

825
00:34:40,010 --> 00:34:42,060
>> Tulet, kerrot
meille, Tarvitsen pöytä.

826
00:34:42,060 --> 00:34:43,409
Se tarvitsee näin paljon kapasiteettia.

827
00:34:43,409 --> 00:34:47,300
Osut painiketta, ja me säännös
kaikki infrastruktuuri takana kohtauksen.

828
00:34:47,300 --> 00:34:48,310
Nyt on valtava.

829
00:34:48,310 --> 00:34:51,310
>> Koska kun puhut
noin skaalaus tietokanta,

830
00:34:51,310 --> 00:34:53,917
NoSQL tiedot klustereita
mittakaavassa, käynnissä petatavuun,

831
00:34:53,917 --> 00:34:55,750
käynnissä miljoonia
tapahtumaa sekunnissa,

832
00:34:55,750 --> 00:34:58,180
nämä asiat eivät ole pieniä klustereita.

833
00:34:58,180 --> 00:35:00,830
Puhumme tuhansia tapauksia.

834
00:35:00,830 --> 00:35:04,480
Toimitusjohtaja tuhansia tapauksia,
jopa virtuaalinen tapauksissa

835
00:35:04,480 --> 00:35:06,350
on todellinen kipu Butt.

836
00:35:06,350 --> 00:35:09,110
Tarkoitan, ajattele aina
käyttöjärjestelmä laastari tulee ulos

837
00:35:09,110 --> 00:35:11,552
tai uuden version tietokannan.

838
00:35:11,552 --> 00:35:13,260
Mitä se tarkoittaa
sinulle toiminnallisesti?

839
00:35:13,260 --> 00:35:16,330
Tämä tarkoittaa sait 1200
palvelimet, jotka on päivitettävä.

840
00:35:16,330 --> 00:35:18,960
Nyt jopa automaation,
joka voi kestää kauan.

841
00:35:18,960 --> 00:35:21,480
Tämä voi aiheuttaa paljon
operatiivinen päänsärkyä,

842
00:35:21,480 --> 00:35:23,090
koska olisin palvelut alas.

843
00:35:23,090 --> 00:35:26,070
>> Kuten olen päivittää nämä tietokannat, I
voisi tehdä sininen vihreä käyttöönottoja

844
00:35:26,070 --> 00:35:29,420
jossa olen käyttöön ja päivittää puoli minun
solmuja, ja päivittää sitten toinen puoli.

845
00:35:29,420 --> 00:35:30,490
Ottaa ne alas.

846
00:35:30,490 --> 00:35:33,410
Joten hallinnoi infrastruktuuria
asteikko on erittäin kivulias.

847
00:35:33,410 --> 00:35:36,210
Ja AWS ottaa että kipu irti.

848
00:35:36,210 --> 00:35:39,210
Ja NoSQL tietokantoja voi
olla erittäin kivulias

849
00:35:39,210 --> 00:35:41,780
sillä tavalla he mittakaavassa.

850
00:35:41,780 --> 00:35:42,926
>> Mittakaavassa vaakasuunnassa.

851
00:35:42,926 --> 00:35:45,550
Jos haluat saada isompi NoSQL
tietokanta, ostat enemmän solmuja.

852
00:35:45,550 --> 00:35:48,660
Jokainen solmu ostat on
toinen operatiivinen päänsärky.

853
00:35:48,660 --> 00:35:50,830
Joten anna jonkun muun tehdä sen puolestasi.

854
00:35:50,830 --> 00:35:52,000
AWS voi tehdä.

855
00:35:52,000 --> 00:35:54,587
>> Tuemme asiakirja keskeisistä arvoista.

856
00:35:54,587 --> 00:35:56,670
Nyt ei mene liikaa
osaksi toisaalta kaavion.

857
00:35:56,670 --> 00:35:58,750
Siellä on paljon erilaisia
makuja NoSQL.

858
00:35:58,750 --> 00:36:02,670
Ne ovat kaikki tavallaan saada
munged yhdessä tässä vaiheessa.

859
00:36:02,670 --> 00:36:06,260
Voit tarkastella DynamoDB ja sanoa kyllä,
olemme molemmat asiakirja ja keskeinen arvo

860
00:36:06,260 --> 00:36:08,412
Säilytä tässä vaiheessa.

861
00:36:08,412 --> 00:36:10,620
Ja voit väittää ominaisuudet
ja yksi yli muiden.

862
00:36:10,620 --> 00:36:13,950
Minulle paljon tämä on todella kuusi
Yhden puoli tusinaa muita.

863
00:36:13,950 --> 00:36:18,710
Jokainen näistä teknologioista on
hieno tekniikka ja hieno ratkaisu.

864
00:36:18,710 --> 00:36:23,390
En sanoisi MongoDB on parempi tai
huonompi kuin Couch, sitten Cassandra,

865
00:36:23,390 --> 00:36:25,994
sitten Dynamo, tai päinvastoin.

866
00:36:25,994 --> 00:36:27,285
Tarkoitan, nämä ovat vain vaihtoehtoja.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Se on nopea ja se on
johdonmukainen missä tahansa mittakaavassa.

869
00:36:32,700 --> 00:36:36,210
Joten tämä on yksi suurimmista
bonuksia saat kanssa AWS.

870
00:36:36,210 --> 00:36:40,850
Kanssa DynamoDB on kyky
saada alhainen yhden numeron

871
00:36:40,850 --> 00:36:44,040
millisekunnin viive milloin tahansa mittakaavassa.

872
00:36:44,040 --> 00:36:45,720
Se oli suunnittelu tavoite järjestelmän.

873
00:36:45,720 --> 00:36:49,130
Ja meillä on asiakkaita, jotka tekevät
miljoonia tapahtumia sekunnissa.

874
00:36:49,130 --> 00:36:52,670
>> Nyt menen läpi joitakin näistä
käyttää tapauksissa muutaman minuutin täällä.

875
00:36:52,670 --> 00:36:55,660
Integroitu pääsy control--
meillä on mitä me kutsumme

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, tai IAM.

877
00:36:57,920 --> 00:37:01,980
Se leviää kaikissa järjestelmissä,
jokainen palvelu, joka AWS tarjoaa.

878
00:37:01,980 --> 00:37:03,630
DynamoDB ei ole poikkeus.

879
00:37:03,630 --> 00:37:06,020
Voit valvoa pääsyä
ja DynamoDB taulukoita.

880
00:37:06,020 --> 00:37:09,960
Across kaikki AWS-tilejä
määritellään pääsy roolit ja käyttöoikeudet

881
00:37:09,960 --> 00:37:12,140
IAM infrastruktuuriin.

882
00:37:12,140 --> 00:37:16,630
>> Ja se on keskeinen ja kiinteä osa
mitä me kutsumme Tapahtuma Driven Ohjelmointi.

883
00:37:16,630 --> 00:37:19,056
Nyt tämä on uusi paradigma.

884
00:37:19,056 --> 00:37:22,080
>> Yleisö: Miten korko totta
positiivisia verrattuna vääriä negatiivisia

885
00:37:22,080 --> 00:37:24,052
teidän kulunvalvontajärjestelmä?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: True positiivisia
vs. vääriä negatiivisia?

887
00:37:26,260 --> 00:37:28,785
Yleisö: Palatakseni mitä
sinun pitäisi palaamassa?

888
00:37:28,785 --> 00:37:33,720
Toisin kuin kerran, kun se
ei palaa, kun sen pitäisi vahvistaa?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: En voinut kertoa.

891
00:37:38,050 --> 00:37:40,140
Onko siellä mitään epäonnistumisia
millään tavoin, että

892
00:37:40,140 --> 00:37:42,726
En ole henkilö kysyä
että erityisesti kysymys.

893
00:37:42,726 --> 00:37:43,850
Mutta se on hyvä kysymys.

894
00:37:43,850 --> 00:37:45,905
Olisin utelias tietämään
että itse, todella.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Ja niin sitten taas, uusi paradigma
on tapahtuma ajetaan ohjelmointi.

897
00:37:51,320 --> 00:37:55,160
Tämä on ajatus, että voit
käyttöön monimutkaisia ​​sovelluksia

898
00:37:55,160 --> 00:37:59,720
voi toimia hyvin, hyvin suuri mittakaava
ilman infrastruktuuria lainkaan.

899
00:37:59,720 --> 00:38:02,120
Ilman kiinteää
infrastruktuuri mitään.

900
00:38:02,120 --> 00:38:04,720
Ja me puhua hieman
mitä se tarkoittaa kun me

901
00:38:04,720 --> 00:38:06,550
päästä seuraavalle pari kaavioita.

902
00:38:06,550 --> 00:38:08,716
>> Ensimmäinen asia teemme
on me puhumme taulukoita.

903
00:38:08,716 --> 00:38:10,857
API tietotyyppejä Dynamo.

904
00:38:10,857 --> 00:38:13,190
Ja ensimmäinen asia, sinun
huomaat kun katsot tätä,

905
00:38:13,190 --> 00:38:17,930
jos olet perehtynyt tahansa tietokannan,
tietokannat ovat todella kaksi sellainen API

906
00:38:17,930 --> 00:38:18,430
Olin kutsua sitä.

907
00:38:18,430 --> 00:38:21,570
Tai kaksi sarjaa API.

908
00:38:21,570 --> 00:38:23,840
Yksi näistä olisi
hallinnollisia API.

909
00:38:23,840 --> 00:38:26,710
>> Mitä he huolehtivat
toiminnot tietokantaan.

910
00:38:26,710 --> 00:38:31,340
Määrittäminen säilömoduuli,
perustamalla ja lisäämällä pöytiä.

911
00:38:31,340 --> 00:38:35,180
luoda tietokanta
luetteloita ja tapauksia.

912
00:38:35,180 --> 00:38:40,450
Nämä things-- vuonna DynamoDB, sinua
on hyvin lyhyt, lyhyt luettelot.

913
00:38:40,450 --> 00:38:43,120
>> Eli toisin tietokantoihin,
saatat nähdä kymmeniä

914
00:38:43,120 --> 00:38:45,680
komentoja, hallinnollisten
komentoja, konfigurointiin

915
00:38:45,680 --> 00:38:47,290
näitä asetuksia.

916
00:38:47,290 --> 00:38:51,234
Vuonna DynamoDB et tarvitse niitä, koska
et määritä järjestelmän, teemme.

917
00:38:51,234 --> 00:38:54,150
Joten ainoa asia mitä sinun tarvitsee tehdä, on
kerro minulle, mitä koko taulukko tarvitsen.

918
00:38:54,150 --> 00:38:55,660
Niin saat hyvin
rajoitettu sarja komentoja.

919
00:38:55,660 --> 00:38:58,618
>> Saat Luo Pöytä Update, taulukko,
Poista taulukko, ja Kuvaile taulukossa.

920
00:38:58,618 --> 00:39:01,150
Ne ovat ainoat asiat
tarvitset DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Sinun ei tarvitse varastointi
moottorissa.

922
00:39:03,294 --> 00:39:04,960
En tarvitse murehtia replikointi.

923
00:39:04,960 --> 00:39:06,490
En tarvitse murehtia sharding.

924
00:39:06,490 --> 00:39:07,800
>> Minun ei tarvitse huolehtia
mitään tätä kamaa.

925
00:39:07,800 --> 00:39:08,740
Teemme kaiken puolestasi.

926
00:39:08,740 --> 00:39:11,867
Niin, että valtava määrä yläpuolella
Se on vain nostaa pois lautasella.

927
00:39:11,867 --> 00:39:13,200
Sitten meillä on lika toimijoille.

928
00:39:13,200 --> 00:39:17,740
Lika on jotain mitä me
soittaa tietokanta, jota on

929
00:39:17,740 --> 00:39:19,860
Luo, päivittää, poistaa toimijoille.

930
00:39:19,860 --> 00:39:24,180
Nämä ovat yhteisiä
tietokannan toiminnan.

931
00:39:24,180 --> 00:39:31,299
Asiat kuten laittaa kohteen, saada kohta, päivitys
kohteita, poistaa kohteita, erä kyselyn, skannata.

932
00:39:31,299 --> 00:39:32,840
Jos haluat skannata koko taulukon.

933
00:39:32,840 --> 00:39:34,220
Vedä kaikki pöydältä.

934
00:39:34,220 --> 00:39:37,130
Yksi mukavia asioita DynamoDB
on se mahdollistaa rinnakkainen skannauksen.

935
00:39:37,130 --> 00:39:40,602
Joten voit itse haluaisin tietää, kuinka monta
viestiketjut haluat ajaa että skannata.

936
00:39:40,602 --> 00:39:41,810
Ja voimme käyttää niitä kierteet.

937
00:39:41,810 --> 00:39:43,985
Voimme spin että skannata ylös
poikki useita säikeitä

938
00:39:43,985 --> 00:39:49,060
joten voit tarkistaa koko taulukon
tila hyvin, hyvin nopeasti DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Muut API meillä on
mitä me kutsumme Streams API.

940
00:39:51,490 --> 00:39:52,940
Emme aio puhua liian
paljon tästä juuri nyt.

941
00:39:52,940 --> 00:39:55,189
Minulla jotain sisältöä myöhemmin
päälle kannella tästä.

942
00:39:55,189 --> 00:39:59,910
Mutta Streams on todella running--
ajattele sitä aika määräsi

943
00:39:59,910 --> 00:40:01,274
ja osio muutos loki.

944
00:40:01,274 --> 00:40:03,940
Kaiken, mitä tapahtuu
taulukossa esitetään ylös virta.

945
00:40:03,940 --> 00:40:05,940
>> Jokainen kirjoittaa pöytään
näkyy stream.

946
00:40:05,940 --> 00:40:08,370
Voit lukea, että virta, ja
voit tehdä asioita sen kanssa.

947
00:40:08,370 --> 00:40:10,150
Puhutaan mitä
tyyppisiä asioita

948
00:40:10,150 --> 00:40:13,680
tehdä asioita, kuten replikointi,
perustamalla toissijaisia ​​indeksejä.

949
00:40:13,680 --> 00:40:17,620
Kaikenlaiset todella cool
asioita voit tehdä sen kanssa.

950
00:40:17,620 --> 00:40:19,150
>> Tietotyyppejä.

951
00:40:19,150 --> 00:40:23,320
Vuonna DynamoDB tuemme molemmat keskeisiä
arvo ja asiakirja tietotyyppejä.

952
00:40:23,320 --> 00:40:26,350
Vasemmalla laidassa
täällä, meillä meidän perustyyppiä.

953
00:40:26,350 --> 00:40:27,230
Avain arvotyypeillä.

954
00:40:27,230 --> 00:40:30,040
Nämä ovat jouset,
numeroita, ja binäärit.

955
00:40:30,040 --> 00:40:31,640
>> Joten vain kolme perustyyppiä.

956
00:40:31,640 --> 00:40:33,700
Ja sitten voit olla sarjaa näiden.

957
00:40:33,700 --> 00:40:37,650
Yksi mukavia asioita NoSQL on
voit olla taulukoita kuin ominaisuuksia.

958
00:40:37,650 --> 00:40:42,050
Ja DynamoDB voit olla taulukoita
perus tyyppejä kuin viitteenä omaisuutta.

959
00:40:42,050 --> 00:40:43,885
>> Ja sitten on asiakirjatyyppejä.

960
00:40:43,885 --> 00:40:45,510
Kuinka monet ihmiset tuntevat JSON?

961
00:40:45,510 --> 00:40:47,130
Te perehtynyt JSON niin paljon?

962
00:40:47,130 --> 00:40:49,380
Se on pohjimmiltaan JavaScript,
Esine, merkintätapa.

963
00:40:49,380 --> 00:40:52,510
Sen avulla voit pohjimmiltaan
määritellä hierarkkinen rakenne.

964
00:40:52,510 --> 00:40:58,107
>> Voit tallentaa JSON asiakirjan
DynamoDB käyttämällä yhteisiä komponentteja

965
00:40:58,107 --> 00:41:00,940
tai rakennuspalikoita, jotka ovat käytettävissä
Useimmissa ohjelmointikielissä.

966
00:41:00,940 --> 00:41:03,602
Joten jos sinulla on Java, olet
katsot karttoja ja luetteloita.

967
00:41:03,602 --> 00:41:05,060
Voin luoda objekteja alueen kartta.

968
00:41:05,060 --> 00:41:08,030
Kartta keskeisinä arvot
tallennetaan ominaisuudet.

969
00:41:08,030 --> 00:41:10,890
Ja se voisi olla luettelot
arvoja nämä ominaisuudet.

970
00:41:10,890 --> 00:41:13,490
Voit tallentaa tämän monimutkaisen
hierarkkinen rakenne

971
00:41:13,490 --> 00:41:16,320
yhtenä ominaisuus
of DynamoDB kohteen.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Joten taulukoita DynamoDB, kuten useimmat
NoSQL tietokannat, taulukot ovat kohteita.

974
00:41:24,460 --> 00:41:26,469
Vuonna MongoDB olisit
kutsuvat näitä asiakirjoja.

975
00:41:26,469 --> 00:41:27,760
Ja se olisi sohvalla pohja.

976
00:41:27,760 --> 00:41:28,900
Myös asiakirja tietokanta.

977
00:41:28,900 --> 00:41:29,941
Soitat nämä asiakirjat.

978
00:41:29,941 --> 00:41:32,930
Asiakirjoja tai kohteita on määritteitä.

979
00:41:32,930 --> 00:41:35,850
Määritteitä voi olla olemassa tai
ei löydy kohteen.

980
00:41:35,850 --> 00:41:38,520
Vuonna DynamoDB, siellä
yksi pakollisena ominaisuutena.

981
00:41:38,520 --> 00:41:43,880
Aivan kuten relaatiotietokanta,
käytössä on ensisijainen avain pöydälle.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB on mitä me kutsumme ruutu.

983
00:41:46,010 --> 00:41:48,280
Ruutunäppäintä on oltava yksilöllinen.

984
00:41:48,280 --> 00:41:52,580
Kun siis määritellä tiiviste,
periaatteessa mitä sanon

985
00:41:52,580 --> 00:41:54,110
on jokainen erä on ruutu.

986
00:41:54,110 --> 00:41:58,520
Ja jokainen ruutu on oltava yksilöllisiä.

987
00:41:58,520 --> 00:42:01,200
>> Jokainen erä määritellään
tämän ainutlaatuisen ruutu.

988
00:42:01,200 --> 00:42:02,940
Ja voi olla vain yksi.

989
00:42:02,940 --> 00:42:05,820
Tämä on OK, mutta Usein
mitä ihmiset tarvitsevat

990
00:42:05,820 --> 00:42:08,170
he haluavat tämä hash
avain tehdä vähän enemmän

991
00:42:08,170 --> 00:42:11,010
kuin vain olla yksilöllinen tunniste.

992
00:42:11,010 --> 00:42:15,240
Usein haluamme käyttää että ruutunäppäintä
kuten huipputason yhdistäminen ämpäri.

993
00:42:15,240 --> 00:42:19,160
Ja tapamme tehdä se on
lisäämällä mitä me kutsumme erilaisia ​​avain.

994
00:42:19,160 --> 00:42:22,460
>> Joten jos se on hash vain
pöytä, tämä on oltava yksilöllinen.

995
00:42:22,460 --> 00:42:27,040
Jos se on hash ja alue pöytä,
yhdistelmä hash ja alue

996
00:42:27,040 --> 00:42:28,640
on oltava yksilöllinen.

997
00:42:28,640 --> 00:42:30,110
Joten ajattele sitä tällä tavalla.

998
00:42:30,110 --> 00:42:32,140
Jos minulla on foorumi.

999
00:42:32,140 --> 00:42:39,010
Ja muoto on aiheita, se on
virkaa, ja se on vastauksia.

1000
00:42:39,010 --> 00:42:42,630
>> Joten olisin hash
avain, joka on aihe tunnus.

1001
00:42:42,630 --> 00:42:46,650
Ja voisin olla erilaisia ​​avain,
joka on vastaus tunnus.

1002
00:42:46,650 --> 00:42:49,650
Näin jos haluan saada kaikki
vastauksia tiettyyn aiheeseen,

1003
00:42:49,650 --> 00:42:52,370
Voin vain kyselyn hash.

1004
00:42:52,370 --> 00:42:55,190
Voin vain sanoa antaa minulle kaikki
kohteita, jotka ovat tämän hash.

1005
00:42:55,190 --> 00:43:01,910
Ja aion saada jokaiseen kysymykseen
tai lähettää kyseisen aiheen.

1006
00:43:01,910 --> 00:43:03,910
Nämä huipputason aggregoinneista
ovat erittäin tärkeitä.

1007
00:43:03,910 --> 00:43:07,370
Ne tukevat ensisijainen yhteys
kuvio hakemuksen.

1008
00:43:07,370 --> 00:43:09,420
Yleisesti ottaen tämä
on mitä haluamme tehdä.

1009
00:43:09,420 --> 00:43:11,780
Haluamme, että table--
kun lataat taulukon,

1010
00:43:11,780 --> 00:43:16,640
haluamme jäsentää tiedot
taulukon sisällä siten, että

1011
00:43:16,640 --> 00:43:20,140
että sovellus voi hyvin
nopeasti hakea nämä tulokset.

1012
00:43:20,140 --> 00:43:24,510
Ja Usein tapa tehdä se on
säilyttää nämä kasaumien kuin me

1013
00:43:24,510 --> 00:43:25,650
aseta tiedot.

1014
00:43:25,650 --> 00:43:31,110
Periaatteessa olemme levittää tiedot
osaksi kirkas ämpäri kuin se tulee.

1015
00:43:31,110 --> 00:43:35,210
>> Range avaimet sallia me-- hash
avaimet on oltava tasa-arvo.

1016
00:43:35,210 --> 00:43:39,490
Kun minä kyselyn hash, minun on sanottava
anna minulle hash, joka vastaa tätä.

1017
00:43:39,490 --> 00:43:41,950
Kun minä kyselyn alue, I
voi sanoa antaa minulle alue

1018
00:43:41,950 --> 00:43:47,040
että käyttää mitä tahansa
rikas operaattori että tuemme.

1019
00:43:47,040 --> 00:43:49,200
Anna minulle kaikki kohteet hash.

1020
00:43:49,200 --> 00:43:52,520
Onko se yhtä suuri, suurempi kuin,
alle, se alkaa,

1021
00:43:52,520 --> 00:43:54,145
se välillä näiden kahden arvon?

1022
00:43:54,145 --> 00:43:56,811
Joten tämäntyyppisiä valikoima kyselyitä
että olemme aina kiinnostuneita.

1023
00:43:56,811 --> 00:43:59,650
Nyt yksi asia tietoja, kun
katsot päästä tiedot, kun

1024
00:43:59,650 --> 00:44:02,360
voit käyttää tietoja, se
aina noin yhdistäminen.

1025
00:44:02,360 --> 00:44:05,770
Kyse on aina kirjaa
jotka liittyvät tähän.

1026
00:44:05,770 --> 00:44:10,390
Anna minulle kaikki täällä that's-- kaikki
liiketoimet tämän luottokortilla

1027
00:44:10,390 --> 00:44:12,500
viimeiseltä kuukaudelta.

1028
00:44:12,500 --> 00:44:13,960
Se yhdistäminen.

1029
00:44:13,960 --> 00:44:17,490
>> Lähes kaikki mitä tehdä
tietokanta on jonkinlainen aggregaatiota.

1030
00:44:17,490 --> 00:44:21,530
Niin se voi pystyä määrittelemään
nämä kauhat ja antaa sinulle nämä alue

1031
00:44:21,530 --> 00:44:24,950
määritteet pystyä hakua,
ne rikas kyselyt tukea monia,

1032
00:44:24,950 --> 00:44:27,165
monet, monet sovellus pääsy malleja.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Joten toinen asia ruutunäppäintä
ei se antaa meille mekanismi

1035
00:44:35,000 --> 00:44:37,740
pystyä laajentamaan data ympärillä.

1036
00:44:37,740 --> 00:44:40,390
NoSQL tietokannat toimivat parhaiten
kun data on tasaisesti

1037
00:44:40,390 --> 00:44:41,740
jakautunut klusterin.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Kuinka monet ihmiset tuntevat
kanssa hajautusta algoritmit?

1040
00:44:47,050 --> 00:44:49,860
Kun sanon hash ja hashing--
koska hajautinalgoritmi

1041
00:44:49,860 --> 00:44:54,140
on tapa olla kykenevä generoimaan
satunnainen arvo tahansa arvosta.

1042
00:44:54,140 --> 00:44:59,300
Joten tässä tapauksessa,
hash-algoritmia otamme on ND 5 perustuva.

1043
00:44:59,300 --> 00:45:04,765
>> Ja jos minulla on tunnus, ja tämä
on minun ruutunäppäintä, minulla on 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Kun olen suorittanut hash-algoritmia,
se tulee tulla takaisin ja sanoa,

1045
00:45:07,390 --> 00:45:10,800
hyvin 1 vastaa 7B, 2
vastaa 48, 3 vastaa CD.

1046
00:45:10,800 --> 00:45:13,092
He levisi avainavaruus.

1047
00:45:13,092 --> 00:45:14,050
Ja miksi teet tämän?

1048
00:45:14,050 --> 00:45:17,120
Koska se varmistaa, että voin
laittaa kirjaa useiden solmut.

1049
00:45:17,120 --> 00:45:19,574
>> Jos Teen tämän
vähitellen, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Ja minulla on hash alue, joka
käy tässä tapauksessa,

1051
00:45:21,990 --> 00:45:24,785
pieni hash tilaan,
se kulkee 00-FF

1052
00:45:24,785 --> 00:45:27,951
sitten Records aikovat tulla
ja he aikovat mennä 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
Mitä tapahtuu?

1055
00:45:31,800 --> 00:45:34,860
Joka insertti on menossa samaan solmuun.

1056
00:45:34,860 --> 00:45:36,070
Näetkö mitä tarkoitan?

1057
00:45:36,070 --> 00:45:40,910
>> Koska kun minä jakaa tilaa,
Ja minä levitin nämä tiedot kaikkialla,

1058
00:45:40,910 --> 00:45:45,950
ja minä osio, aion sanoa
osio 1 on avain tilaa 0-54.

1059
00:45:45,950 --> 00:45:47,720
Osio 2 on 55-89.

1060
00:45:47,720 --> 00:45:49,780
Osio 3 on AA-FF.

1061
00:45:49,780 --> 00:45:53,740
Joten jos käytän lineaarisesti monesko
Tunnukset, näet mitä tapahtuu.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, kaikki tavalla jopa 54.

1063
00:45:57,410 --> 00:46:00,030
Niin olen mäiske
Records järjestelmään,

1064
00:46:00,030 --> 00:46:02,030
kaikki päätyy menossa yksi solmu.

1065
00:46:02,030 --> 00:46:03,160
>> Tuo ei ole hyvä.

1066
00:46:03,160 --> 00:46:04,820
Se antipattern.

1067
00:46:04,820 --> 00:46:08,760
Vuonna MongoDB heillä on tämä ongelma
jos et käytä ruutu.

1068
00:46:08,760 --> 00:46:11,325
MongoDB antaa sinulle mahdollisuuden
ja hajautusta avainarvon.

1069
00:46:11,325 --> 00:46:13,950
Sinun tulisi aina tehdä, jos
käytät monesko hash

1070
00:46:13,950 --> 00:46:17,380
Näppäile MongoDB, tai voit olla
naulaamalla jokainen kirjoittaa yhteen solmuun,

1071
00:46:17,380 --> 00:46:21,290
ja sinun on rajoittaa
sinun kirjoittaa läpijuoksu huonosti.

1072
00:46:21,290 --> 00:46:24,896
>> Yleisö: Onko se A9 169 desimaalin?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Joo, se on
jonnekin noin siellä.

1074
00:46:28,450 --> 00:46:29,950
A9, en tiedä.

1075
00:46:29,950 --> 00:46:32,200
Sinun täytyy saada minun binary
desimaaliluvuiksi laskin.

1076
00:46:32,200 --> 00:46:34,237
Aivoni ei toimi niin.

1077
00:46:34,237 --> 00:46:36,320
Yleisö: Vain näkäräinen
teidän Mongo kommentteja.

1078
00:46:36,320 --> 00:46:39,530
Joten on esine tunnus, joka tulee
natiivisti kanssa Mongo tehdä?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Onko se tehdä niin?

1081
00:46:41,470 --> 00:46:42,970
Jos määrittää sen.

1082
00:46:42,970 --> 00:46:45,030
Kanssa MongoDB, sinulla on mahdollisuus.

1083
00:46:45,030 --> 00:46:48,930
Voit specify-- jokaisen asiakirjan
MongoDB on oltava alaviiva tunnus.

1084
00:46:48,930 --> 00:46:50,300
Se ainutlaatuista arvoa.

1085
00:46:50,300 --> 00:46:55,240
>> Vuonna MongoDB voit määrittää
onko hash sitä tai ei.

1086
00:46:55,240 --> 00:46:56,490
He vain antaa sinulle mahdollisuuden.

1087
00:46:56,490 --> 00:46:58,198
Jos tiedät, että se on
satunnainen, ei ole ongelma.

1088
00:46:58,198 --> 00:46:59,640
Sinun ei tarvitse tehdä sitä.

1089
00:46:59,640 --> 00:47:04,260
Jos tiedät, että se ei ole satunnainen, että
se on lisäävä, tee hash.

1090
00:47:04,260 --> 00:47:06,880
>> Nyt asia
hajautusta, kun hash

1091
00:47:06,880 --> 00:47:08,800
value-- ja tämä on
miksi hash avaimet ovat aina

1092
00:47:08,800 --> 00:47:13,740
ainutlaatuinen kyselyitä, koska olen muuttanut
arvo, nyt en voi tehdä erilaisia ​​kyselyn.

1093
00:47:13,740 --> 00:47:15,640
En voi sanoa on tämä
välillä tämän tai tuon,

1094
00:47:15,640 --> 00:47:20,800
koska haja-arvo ei ole menossa
olla samantasoinen kuin todellinen arvo.

1095
00:47:20,800 --> 00:47:24,570
Joten kun hash että
avain, se on tasa vain.

1096
00:47:24,570 --> 00:47:28,700
Tämä on miksi DynamoDB ruutunäppäintä
kyselyt ovat aina tasa vain.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Joten nyt alueella key--
kun lisään, että alue avain,

1099
00:47:34,700 --> 00:47:38,180
ne alue avain tallentaa kaikki tulevat ja
ne saa varastoida samaan osioon.

1100
00:47:38,180 --> 00:47:42,430
Joten he ovat hyvin nopeasti, helposti
haetaan koska tämä on hash,

1101
00:47:42,430 --> 00:47:43,220
tämä on alue.

1102
00:47:43,220 --> 00:47:44,928
Ja näet kaiken
samalla hash

1103
00:47:44,928 --> 00:47:48,550
saa säilyttää samaan osioon tilaan.

1104
00:47:48,550 --> 00:47:53,889
Voit käyttää tätä alue avain auttaa
etsi tietosi lähellä sen emoyhtiön.

1105
00:47:53,889 --> 00:47:55,180
Mitä minä todella tekee täällä?

1106
00:47:55,180 --> 00:47:57,320
Tämä on yksi moneen.

1107
00:47:57,320 --> 00:48:01,490
Suhdetta ruutunäppäintä
ja alue avain on yksi monista.

1108
00:48:01,490 --> 00:48:03,490
Voin olla useita hash avaimet.

1109
00:48:03,490 --> 00:48:07,610
Voin vain olla useita erilaisia
avaimet jokaisessa ruutu.

1110
00:48:07,610 --> 00:48:11,910
>> Hash määrittelee vanhempi,
alue määrittää lapset.

1111
00:48:11,910 --> 00:48:15,240
Voit siis nähdä siellä analoginen täällä
välillä relaatio konstrukti

1112
00:48:15,240 --> 00:48:18,840
ja saman tyyppisiä
rakentaa ja NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Ihmiset puhuvat
NoSQL kuten nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Se ei ole nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Tiedot on aina suhteita.

1116
00:48:24,680 --> 00:48:28,172
Nämä suhteet vain
mallinnetaan eri tavalla.

1117
00:48:28,172 --> 00:48:29,880
Puhutaanpa hieman
vähän siitä kestävyys.

1118
00:48:29,880 --> 00:48:34,860
Kun kirjoitat DynamoDB, kirjoittaa
ovat aina kolmen tavalla jäljitellä.

1119
00:48:34,860 --> 00:48:37,550
Eli meillä on kolme AZ: n.

1120
00:48:37,550 --> 00:48:39,160
AZ: n ovat Saatavuus Zones.

1121
00:48:39,160 --> 00:48:43,430
Voit ajatella Saatavuus
Zone datakeskuksen

1122
00:48:43,430 --> 00:48:45,447
tai kokoelma datakeskusten.

1123
00:48:45,447 --> 00:48:47,780
Nämä asiat ovat maantieteellisesti
eristetty toisistaan

1124
00:48:47,780 --> 00:48:51,610
eri vika alueilla, yli
eri sähköverkkoihin ja tulva.

1125
00:48:51,610 --> 00:48:54,510
Vika yhdessä AZ ei ole
vie alas toiselle.

1126
00:48:54,510 --> 00:48:56,890
Ne ovat myös sidoksissa
yhdessä pimeä kuitu.

1127
00:48:56,890 --> 00:49:01,240
Se tukee yhtä osa 1
millisekunnin viive välillä AZS.

1128
00:49:01,240 --> 00:49:05,390
Joten reaaliaikaista tietoa aliotosten
kykenee monen AZS.

1129
00:49:05,390 --> 00:49:09,990
>> Ja Usein multi AZ käyttöönottoja
täyttää korkean käytettävyyden vaatimukset

1130
00:49:09,990 --> 00:49:12,930
Useimpien yritysten organisaatioissa.

1131
00:49:12,930 --> 00:49:16,139
Joten DynamoDB on levinnyt
yli kolme AZS oletuksena.

1132
00:49:16,139 --> 00:49:19,430
Olemme vain menossa tietoa kirjoittaa
kun kaksi näistä kolmesta solmuja palata

1133
00:49:19,430 --> 00:49:21,470
ja sanoa, Joo, sain sen.

1134
00:49:21,470 --> 00:49:22,050
Miksi näin?

1135
00:49:22,050 --> 00:49:25,950
Koska lukupuolella olemme vain
annan teille tiedot takaisin, kun

1136
00:49:25,950 --> 00:49:27,570
saamme sen kaksi solmua.

1137
00:49:27,570 --> 00:49:30,490
>> Jos olen jäljittelevän poikki
kolme, ja luen kahdesta,

1138
00:49:30,490 --> 00:49:32,840
Olen aina taattu
on ainakin yksi

1139
00:49:32,840 --> 00:49:35,720
Näiden lukee olla
uusimmat kopiota.

1140
00:49:35,720 --> 00:49:38,340
Se tekee DynamoDB johdonmukainen.

1141
00:49:38,340 --> 00:49:42,450
Nyt voit kääntyä
ne johdonmukaisesti lukee pois.

1142
00:49:42,450 --> 00:49:45,070
Jolloin aion sanoa,
Minä vain lukea yksi solmu.

1143
00:49:45,070 --> 00:49:47,430
Ja en voi taata se tulee
olla uusimmat tiedot.

1144
00:49:47,430 --> 00:49:49,450
>> Joten jos kirjoitus on tulossa,
se ei ole toistettu vielä,

1145
00:49:49,450 --> 00:49:50,360
aiot saada tämä jäljennös.

1146
00:49:50,360 --> 00:49:52,220
Se lopulta johdonmukainen lukea.

1147
00:49:52,220 --> 00:49:54,640
Ja mitä se on on puolet kustannuksista.

1148
00:49:54,640 --> 00:49:56,140
Joten tämä on jotain ajateltavaa.

1149
00:49:56,140 --> 00:50:00,160
Kun luet ulos DynamoDB, ja
olet perustaa oman lukea kapasiteetti

1150
00:50:00,160 --> 00:50:04,430
yksiköt, jos valitset lopulta
johdonmukainen lukee, se on paljon halvempaa,

1151
00:50:04,430 --> 00:50:06,010
se on noin puolet kustannuksista.

1152
00:50:06,010 --> 00:50:09,342
>> Ja niin se säästää rahaa.

1153
00:50:09,342 --> 00:50:10,300
Mutta se on sinun valintasi.

1154
00:50:10,300 --> 00:50:12,925
Jos haluat johdonmukainen luku- tai
lopulta johdonmukainen lukea.

1155
00:50:12,925 --> 00:50:15,720
Se on jotain, että voit valita.

1156
00:50:15,720 --> 00:50:17,659
>> Puhutaanpa indeksit.

1157
00:50:17,659 --> 00:50:19,450
Niin me mainita, että
huipputason yhdistäminen.

1158
00:50:19,450 --> 00:50:23,720
Meillä hash avaimet, ja
meillä valikoima avaimet.

1159
00:50:23,720 --> 00:50:24,320
Sepä kiva.

1160
00:50:24,320 --> 00:50:26,950
Ja se on ensisijaisen taulukon, I
sai yhden ruutunäppäintä, sain yksi alue avain.

1161
00:50:26,950 --> 00:50:27,783
>> Mitä se tarkoittaa?

1162
00:50:27,783 --> 00:50:30,410
Minulla on yksi ominaisuus, että olen
voi ajaa rikas kyselyitä.

1163
00:50:30,410 --> 00:50:31,800
Se on alue avain.

1164
00:50:31,800 --> 00:50:35,530
Muita ominaisuuksia, että item--
Voin suodattaa nämä määritteet.

1165
00:50:35,530 --> 00:50:40,050
Mutta en voi tehdä asioita, kuten se
alkaa, tai on suurempi kuin.

1166
00:50:40,050 --> 00:50:40,820
>> Miten teen sen?

1167
00:50:40,820 --> 00:50:42,860
Luon indeksin.

1168
00:50:42,860 --> 00:50:45,340
On kahdenlaisia
indeksit DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Indeksi on todella
Toinen näkymä pöydän.

1170
00:50:49,002 --> 00:50:50,490
Ja paikallinen toissijainen indeksi.

1171
00:50:50,490 --> 00:50:51,781
>> Ensimmäinen me puhumme.

1172
00:50:51,781 --> 00:50:57,740
Joten paikalliset kyynärsulat ovat rinnakkain
samaan osioon kuin tiedot.

1173
00:50:57,740 --> 00:51:00,240
Ja sellaisenaan, ne ovat
samaan fyysiseen solmuun.

1174
00:51:00,240 --> 00:51:01,780
Ne ovat mitä me kutsumme johdonmukainen.

1175
00:51:01,780 --> 00:51:04,599
Merkitys, ne tunnustavat
Kirjoita yhdessä pöytä.

1176
00:51:04,599 --> 00:51:06,890
Kun kirjoittaa tulee,
me kirjoittaa hakemiston läpi.

1177
00:51:06,890 --> 00:51:09,306
Me kirjoittaa ylös pöytään,
ja sitten me tunnustaa.

1178
00:51:09,306 --> 00:51:10,490
Niinpä se on johdonmukainen.

1179
00:51:10,490 --> 00:51:13,174
Kun kirjoitus on ollut
myönsi taulukosta,

1180
00:51:13,174 --> 00:51:15,090
se on varmaa, että
paikallinen toissijainen indeksi

1181
00:51:15,090 --> 00:51:18,380
on sama näkemys tietojen.

1182
00:51:18,380 --> 00:51:22,390
Mutta mitä niiden avulla voit tehdä on
määritellä vaihtoehtoinen valikoima avaimet.

1183
00:51:22,390 --> 00:51:25,260
>> Täytyy käyttää samaa hash
avain ensisijaisena pöytä,

1184
00:51:25,260 --> 00:51:29,050
koska ne ovat yhteistyössä sijaitsevat
samaan osioon, ja ne ovat johdonmukaisia.

1185
00:51:29,050 --> 00:51:33,110
Mutta voin luoda indeksi
eri valikoima avaimet.

1186
00:51:33,110 --> 00:51:41,590
Niinpä esimerkiksi, jos olisin valmistaja
että oli raaka osia taulukko tulossa.

1187
00:51:41,590 --> 00:51:44,590
Ja raaka osat tulevat, ja
he yhdisteltynä kokoonpano.

1188
00:51:44,590 --> 00:51:46,840
Ja ehkä siellä muistaa.

1189
00:51:46,840 --> 00:51:50,240
>> Mitään osaa, joka tehtiin tämän
valmistaja tämän päivämäärän jälkeen,

1190
00:51:50,240 --> 00:51:52,840
Minun täytyy vetää minun linjan.

1191
00:51:52,840 --> 00:51:55,950
Voin spin indeksi
että etsisivät,

1192
00:51:55,950 --> 00:52:00,760
kokoamiseen mennessä
valmistusta kyseisen osan.

1193
00:52:00,760 --> 00:52:03,930
Joten jos ylätason taulukko oli
jo hashed valmistaja,

1194
00:52:03,930 --> 00:52:07,655
ehkä se järjestettiin osa ID, I
voi luoda indeksin pois, että taulukon

1195
00:52:07,655 --> 00:52:11,140
kuten hajakoodataan valmistajan ja
vaihteli päivämäärään valmistuksen.

1196
00:52:11,140 --> 00:52:14,490
Ja näin voisin sanoa, mitään,
on valmistettu näiden päivämäärien,

1197
00:52:14,490 --> 00:52:16,804
Minun täytyy vetää linjan.

1198
00:52:16,804 --> 00:52:18,220
Niin, että paikallinen toissijainen indeksi.

1199
00:52:18,220 --> 00:52:22,280
>> Näiden vaikutuksesta
rajoittamalla ruutu tilaa.

1200
00:52:22,280 --> 00:52:24,360
Koska he yhteistyötä olemassa
samalla varastointi solmu,

1201
00:52:24,360 --> 00:52:26,860
ne rajoittavat ruutunäppäintä
tilaa 10 gigatavua.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, alle
pöydät, tulee osio

1203
00:52:28,950 --> 00:52:31,380
pöytääsi joka 10 gigatavua.

1204
00:52:31,380 --> 00:52:34,760
Kun laitat 10 keikoilla tietojen, me
mennä [PHH], ja lisäämme uuden solmun.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Emme jakaa LSI
useiden osioita.

1207
00:52:42,070 --> 00:52:43,200
Me jakaa taulukossa.

1208
00:52:43,200 --> 00:52:44,679
Mutta emme jakaa LSI.

1209
00:52:44,679 --> 00:52:46,470
Niin, että jotain
tärkeää ymmärtää

1210
00:52:46,470 --> 00:52:50,070
on jos teet hyvin,
erittäin, erittäin suuri koosteita,

1211
00:52:50,070 --> 00:52:53,860
sitten aiot rajoitettava
10 gigatavua teidän LSI: t.

1212
00:52:53,860 --> 00:52:56,640
>> Jos näin on, voimme
käyttää maailmanlaajuisia secondaries.

1213
00:52:56,640 --> 00:52:58,630
Global kyynärsulat ovat
todella toinen pöytä.

1214
00:52:58,630 --> 00:53:01,720
Ne ovat olemassa kokonaan pois
puoli ensisijainen pöydän.

1215
00:53:01,720 --> 00:53:04,680
Ja ne mahdollistavat minua löytämään
täysin erilainen rakenne.

1216
00:53:04,680 --> 00:53:08,010
Joten ajattele sitä dataa lisätään
kahteen eri taulukoita, jäsennelty

1217
00:53:08,010 --> 00:53:09,220
kahdella eri tavalla.

1218
00:53:09,220 --> 00:53:11,360
>> Voin määritellä täysin
eri ruutu.

1219
00:53:11,360 --> 00:53:13,490
Voin määritellä täysin
eri alue avain.

1220
00:53:13,490 --> 00:53:15,941
Ja voin ajaa tätä
täysin itsenäisesti.

1221
00:53:15,941 --> 00:53:18,190
Koska itse asiassa, olen
palveluntarjoajan minun lukea kapasiteetti

1222
00:53:18,190 --> 00:53:21,090
ja kirjoittaa kapasiteetti minun
maailmanlaajuinen toissijainen indeksit

1223
00:53:21,090 --> 00:53:24,240
täysin itsenäisesti
minun ensisijainen pöytä.

1224
00:53:24,240 --> 00:53:26,640
Jos minä määritellä, että indeksi, kerron
se kuinka paljon lukea ja kirjoittaa

1225
00:53:26,640 --> 00:53:28,610
kapasiteetti se aio käyttää.

1226
00:53:28,610 --> 00:53:31,490
>> Ja joka on erillinen
minun ensisijainen taulukosta.

1227
00:53:31,490 --> 00:53:35,240
Nyt molemmat indeksit avulla voimme
ei vain määritellä hash ja alue avaimet,

1228
00:53:35,240 --> 00:53:38,610
mutta ne auttavat meitä
hankkeen lisäarvon.

1229
00:53:38,610 --> 00:53:44,950
Joten jos haluan lukea pois indeksi,
ja haluan saada joitakin joukko tietoja,

1230
00:53:44,950 --> 00:53:48,327
Minun ei tarvitse mennä takaisin päävalikkoon
taulukko saada lisämääreitä.

1231
00:53:48,327 --> 00:53:50,660
En voi heijastaa näitä ylimääräisiä
ominaisuuksia taulukkoon

1232
00:53:50,660 --> 00:53:53,440
tukea käyttötapa.

1233
00:53:53,440 --> 00:53:57,700
Tiedän olemme luultavasti joutumassa joitakin
todella, really-- päästä rikkaruohot

1234
00:53:57,700 --> 00:53:58,910
täällä joitakin tätä kamaa.

1235
00:53:58,910 --> 00:54:02,725
Nyt sain ajelehtia pois tästä.

1236
00:54:02,725 --> 00:54:07,320
>> Yleisö: [äänetön]
--table avain tarkoitti oli hash?

1237
00:54:07,320 --> 00:54:08,840
Kuvan alkuperäinen hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-säleet?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Kyllä.

1240
00:54:10,200 --> 00:54:11,070
Kyllä.

1241
00:54:11,070 --> 00:54:15,260
Selitykset pohjimmiltaan
viittaa takaisin kohde.

1242
00:54:15,260 --> 00:54:19,280
Joten indeksi on osoitin takaisin
alkuperäiset pöydälle.

1243
00:54:19,280 --> 00:54:22,910
Nyt voit rakentaa
indeksi on vain pöytä avain,

1244
00:54:22,910 --> 00:54:24,840
ja muita ominaisuuksia.

1245
00:54:24,840 --> 00:54:26,570
Ja miksi voisin tehdä?

1246
00:54:26,570 --> 00:54:28,570
No, ehkä minulla on hyvin suuria kohteita.

1247
00:54:28,570 --> 00:54:31,660
>> Olen todella tarvitsee vain tietää which--
minun käyttötapa voisi sanoa,

1248
00:54:31,660 --> 00:54:33,760
mitkä kohteet sisältävät tätä omaisuutta?

1249
00:54:33,760 --> 00:54:35,780
Ei tarvitse palauttaa tuotteen.

1250
00:54:35,780 --> 00:54:37,800
Minun täytyy vain tietää
mitkä kohteet sisältävät sitä.

1251
00:54:37,800 --> 00:54:40,700
Joten voit rakentaa indeksejä
että vain pöydän avain.

1252
00:54:40,700 --> 00:54:43,360
>> Mutta se lähinnä sitä, mitä
indeksi tietokannassa on.

1253
00:54:43,360 --> 00:54:46,280
Se, että pystyy nopeasti
mitkä kirjaa,

1254
00:54:46,280 --> 00:54:49,470
rivejä, joka
kohteita taulukossa on

1255
00:54:49,470 --> 00:54:51,080
ominaisuudet, Etsin.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, joten miten ne toimivat?

1258
00:54:54,860 --> 00:54:58,340
GSIS pohjimmiltaan ovat asynkroninen.

1259
00:54:58,340 --> 00:55:02,570
Päivitys tulee taulukko,
taulukko on sitten asynkronisesti päivitetään

1260
00:55:02,570 --> 00:55:03,720
kaikki GSIS.

1261
00:55:03,720 --> 00:55:06,680
Siksi GSIS ovat
lopulta johdonmukainen.

1262
00:55:06,680 --> 00:55:09,440
>> On tärkeää huomata, että
kun olet rakentamassa GSIS,

1263
00:55:09,440 --> 00:55:13,110
ja ymmärrät luot
toinen ulottuvuus aggregation--

1264
00:55:13,110 --> 00:55:16,594
Nyt sanokaamme hyvä esimerkki
tässä valmistaja.

1265
00:55:16,594 --> 00:55:19,260
Uskoisin puhunut
lääketieteellisen laitteen valmistaja.

1266
00:55:19,260 --> 00:55:23,870
Lääketieteellisen laitteen valmistajat
Usein on sarjoitettu osia.

1267
00:55:23,870 --> 00:55:28,070
Osat, jotka menevät
lonkan kaikki

1268
00:55:28,070 --> 00:55:30,200
on vähän sarjanumero niitä.

1269
00:55:30,200 --> 00:55:33,584
Ja ne voivat olla miljoonia ja
miljoonia ja miljardeja osat

1270
00:55:33,584 --> 00:55:35,000
kaikissa laitteissa että ne aluksen.

1271
00:55:35,000 --> 00:55:37,440
No, ne täytyy yhdistää alle
eri mitat, kaikki osat

1272
00:55:37,440 --> 00:55:39,520
seurakunnassa, kaikki
osat, jotka tehtiin

1273
00:55:39,520 --> 00:55:41,670
tietyllä rataosuudella, kaikki
osat, jotka tulivat

1274
00:55:41,670 --> 00:55:44,620
sisään tietty valmistaja
tiettynä päivänä.

1275
00:55:44,620 --> 00:55:47,940
Ja nämä aggregoinneista joskus
päästä ylös miljardeja.

1276
00:55:47,940 --> 00:55:50,550
>> Joten Työskentelen joidenkin
nämä kaverit jotka kärsivät

1277
00:55:50,550 --> 00:55:53,156
koska he luoda
nämä Valtavan aggregoinneista

1278
00:55:53,156 --> 00:55:54,280
niiden toissijainen indeksit.

1279
00:55:54,280 --> 00:55:57,070
He saattavat olla raaka osia
taulukko, joka tulee hash vain.

1280
00:55:57,070 --> 00:55:59,090
Jokaisella osalla on yksilöllinen sarjanumero.

1281
00:55:59,090 --> 00:56:00,975
Käytän järjestysnumero kuin hash.

1282
00:56:00,975 --> 00:56:01,600
Se on kaunis.

1283
00:56:01,600 --> 00:56:04,160
Oma raaka tietojen taulukossa on levinnyt
kaikkialla avainavaruus.

1284
00:56:04,160 --> 00:56:05,930
Minun [? kirjoittaa ?]
[? nieleminen?] on mahtava.

1285
00:56:05,930 --> 00:56:07,876
Otan paljon tietoa.

1286
00:56:07,876 --> 00:56:09,500
Sitten mitä he tekevät on ne luovat GSI.

1287
00:56:09,500 --> 00:56:12,666
Ja minä sanon, tiedät mitä, minun täytyy nähdä
kaikki osat tämän valmistajan.

1288
00:56:12,666 --> 00:56:15,060
No, yhtäkkiä olen
ottaen miljardia rivejä,

1289
00:56:15,060 --> 00:56:17,550
ja kamaa ne päälle
yksi solmu, sillä kun

1290
00:56:17,550 --> 00:56:21,170
Olen aggregoitua
valmistaja tunnus kuten hash,

1291
00:56:21,170 --> 00:56:25,410
ja osa numero alue,
sitten yhtäkkiä olen

1292
00:56:25,410 --> 00:56:30,530
laskemisesta miljardia osat, mitä
tämä valmistaja on antanut minulle.

1293
00:56:30,530 --> 00:56:34,447
>> Tämä voi aiheuttaa paljon
paineita GSI,

1294
00:56:34,447 --> 00:56:36,030
jälleen, koska olen mäiske yksi solmu.

1295
00:56:36,030 --> 00:56:38,350
Laitan kaikki nämä
insertoituu yksi solmu.

1296
00:56:38,350 --> 00:56:40,940
Ja se on todellinen ongelmakäyttö tapauksessa.

1297
00:56:40,940 --> 00:56:43,479
Nyt sain hyvä suunnittelu
malli miten voit välttää sen.

1298
00:56:43,479 --> 00:56:45,770
Ja se on yksi ongelmista
että olen aina työskennellä.

1299
00:56:45,770 --> 00:56:49,590
Mutta mitä tapahtuu, on GSI saattaa
ei ole tarpeeksi kirjoittaa kapasiteetti

1300
00:56:49,590 --> 00:56:52,330
pystyä työntää kaikki
rivejä yhden solmun.

1301
00:56:52,330 --> 00:56:55,390
Ja mitä sitten tapahtuu on
ensisijainen, asiakas pöytä,

1302
00:56:55,390 --> 00:57:00,180
ensisijainen taulukko on kuristettu
koska GSI ei voi pysyä.

1303
00:57:00,180 --> 00:57:02,980
Joten insertti korko
pudota ensisijainen taulukko

1304
00:57:02,980 --> 00:57:06,230
minun GSI yrittää pysyä.

1305
00:57:06,230 --> 00:57:08,850
>> Selvä, joten GSI: n, LSI: n,
joista yksi minun pitäisi käyttää?

1306
00:57:08,850 --> 00:57:12,290
LSI: n ovat johdonmukaisia.

1307
00:57:12,290 --> 00:57:13,750
GSI: n on lopulta johdonmukaisia.

1308
00:57:13,750 --> 00:57:17,490
Jos se on OK, suosittelen
GSI, ne ovat paljon joustavampia.

1309
00:57:17,490 --> 00:57:20,270
LSI: n voidaan mallintaa GSI.

1310
00:57:20,270 --> 00:57:27,040
Ja jos tiedot koko kohti hash avaimet
kokoelma on yli 10 gigatavua,

1311
00:57:27,040 --> 00:57:31,050
sitten olet menossa haluavat käyttää tätä
GSI koska se on vain kova raja.

1312
00:57:31,050 --> 00:57:32,035
>> Selvä, joten skaalaus.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Jaeltavan Dynamo DB, voit
CAN säännös [äänetön]

1315
00:57:37,460 --> 00:57:38,680
läpäisyä pöytään.

1316
00:57:38,680 --> 00:57:42,740
Meillä on asiakkaita, jotka ovat
palveluntarjoajan 60 billion--

1317
00:57:42,740 --> 00:57:45,970
tekevät 60000000000 pyyntöjä, säännöllisesti
käynnissä yli miljoona pyyntöjä

1318
00:57:45,970 --> 00:57:47,790
sekunnissa meidän taulukoita.

1319
00:57:47,790 --> 00:57:50,360
Siellä oikeastaan ​​mitään
teoreettinen raja, kuinka paljon

1320
00:57:50,360 --> 00:57:53,730
ja kuinka nopeasti taulukon
voi ajaa Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
On joitakin pehmeitä
rajoituksia tilisi

1322
00:57:55,920 --> 00:57:58,170
että panemme siellä niin
että et mene hullu.

1323
00:57:58,170 --> 00:58:00,070
Jos haluat enemmän kuin
että ei ole ongelma.

1324
00:58:00,070 --> 00:58:00,820
Tulet kertoa meille.

1325
00:58:00,820 --> 00:58:02,810
Me nosta säädintä.

1326
00:58:02,810 --> 00:58:08,210
>> Jokainen tili on rajoitettu jollain tasolla
jokaisessa palvelussa, aivan lepakko

1327
00:58:08,210 --> 00:58:11,920
joten ihmiset eivät mene hullu
saada itsensä vaikeuksiin.

1328
00:58:11,920 --> 00:58:12,840
No limit kooltaan.

1329
00:58:12,840 --> 00:58:14,940
Voit laittaa minkä tahansa määrän
kohteita pöydälle.

1330
00:58:14,940 --> 00:58:17,620
Koko erä on
rajoitettu 400 kilotavua kullekin,

1331
00:58:17,620 --> 00:58:20,050
että olisi kohta ei määritteitä.

1332
00:58:20,050 --> 00:58:24,200
Joten summa kaikki määritteet
rajoittuu 400 kilotavua.

1333
00:58:24,200 --> 00:58:27,300
Ja sitten taas, meillä on
että vähän LSI kysymys

1334
00:58:27,300 --> 00:58:30,405
kanssa 10 gigatavun rajaa kohti hash.

1335
00:58:30,405 --> 00:58:33,280
Yleisö: Pieni numero, olen puuttuu
mitä sanot, että is--

1336
00:58:33,280 --> 00:58:36,830
Yleisö: Voi, 400 kilotavun
on maksimikoko per tuote.

1337
00:58:36,830 --> 00:58:39,570
Joten tuotteella on kaikki ominaisuudet.

1338
00:58:39,570 --> 00:58:43,950
Joten 400 k on yhteensä koko
tai esineen, 400 kilotavua.

1339
00:58:43,950 --> 00:58:46,170
Joten kaikki ominaisuudet
Yhdistetyt, kaikki tiedot

1340
00:58:46,170 --> 00:58:49,140
siinä kaikki nämä määritteet,
rullattu ylös koko yhteensä,

1341
00:58:49,140 --> 00:58:51,140
tällä hetkellä tänään erä raja on 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Joten skaalaus taas, saavutetaan
väliseinien.

1344
00:58:57,046 --> 00:58:58,920
Läpäisykyky palveluntarjoajan
pöydässä tasolla.

1345
00:58:58,920 --> 00:59:00,160
Ja siellä on todella kaksi nuppia.

1346
00:59:00,160 --> 00:59:02,400
Olemme lukenut kapasiteetti
ja kirjoittaa kapasiteetti.

1347
00:59:02,400 --> 00:59:05,530
>> Joten nämä oikaistaan
toisistaan ​​riippumatta.

1348
00:59:05,530 --> 00:59:08,640
RCU: n toimenpide tiukasti johdonmukainen lukee.

1349
00:59:08,640 --> 00:59:13,005
OK, joten jos sanot haluan 1000
RCU: n ne ovat tiukasti yhdenmukaisia,

1350
00:59:13,005 --> 00:59:14,130
ne ovat johdonmukaisia ​​lukee.

1351
00:59:14,130 --> 00:59:17,130
Jos sanot haluan
lopulta johdonmukainen lukee,

1352
00:59:17,130 --> 00:59:19,402
voit säännös 1000
RCU: n, olet menossa

1353
00:59:19,402 --> 00:59:21,840
saada 2000 lopulta
johdonmukainen lukee.

1354
00:59:21,840 --> 00:59:25,940
Ja puoli hinta niille
lopulta koostuvat lukee.

1355
00:59:25,940 --> 00:59:28,520
>> Jälleen oikaistu
toisistaan ​​riippumatta.

1356
00:59:28,520 --> 00:59:32,900
Ja he ovat throughput--
Jos kuluttaa 100% lisää RCU,

1357
00:59:32,900 --> 00:59:35,960
et aio vaikuttaa
saatavuus oikeuksistasi.

1358
00:59:35,960 --> 00:59:40,161
Joten ne ovat täysin
toisistaan ​​riippumattomia.

1359
00:59:40,161 --> 00:59:43,160
Selvä, joten yksi niistä asioista, jotka
Mainitsin lyhyesti oli kuristamalla.

1360
00:59:43,160 --> 00:59:44,320
Kuristus on huono.

1361
00:59:44,320 --> 00:59:47,311
Kuristus osoittaa huono ei SQL.

1362
00:59:47,311 --> 00:59:50,310
On asioita, joita voimme tehdä auttaaksemme
voit lievittää kuristus että te

1363
00:59:50,310 --> 00:59:51,040
kokevat.

1364
00:59:51,040 --> 00:59:53,240
Mutta paras ratkaisu
Tähän on ottakaamme

1365
00:59:53,240 --> 00:59:58,000
katso mitä olet tekemässä, koska
siellä anti-malli pelata täällä.

1366
00:59:58,000 --> 01:00:02,140
>> Nämä asiat, asioita, kuten epätasainen
työmäärät, pikanäppäimet, kuuma osioita.

1367
01:00:02,140 --> 01:00:06,210
Olen lyömällä erityinen avainavaruus
hyvin vaikeaa joillekin erityinen syy.

1368
01:00:06,210 --> 01:00:07,080
Miksi teen tämän?

1369
01:00:07,080 --> 01:00:08,710
Katsotaanpa sen selville.

1370
01:00:08,710 --> 01:00:10,427
Olen sekoittamalla hot tiedot kylmällä tiedot.

1371
01:00:10,427 --> 01:00:12,510
Olen annan taulukot saada
valtava, mutta siellä oikeastaan

1372
01:00:12,510 --> 01:00:15,970
vain osa osajoukko tietojen
se on todella mielenkiintoista minulle.

1373
01:00:15,970 --> 01:00:20,290
Joten lokitietoja, esimerkiksi paljon
asiakkaita, he saavat lokitiedot joka päivä.

1374
01:00:20,290 --> 01:00:22,490
He saivat valtavasti lokitietoja.

1375
01:00:22,490 --> 01:00:25,940
>> Jos olet juuri polkumyyntiä kaikki, lokin
tiedot yhdeksi iso pöytä, ajan

1376
01:00:25,940 --> 01:00:28,070
että pöytä menee saada massiivinen.

1377
01:00:28,070 --> 01:00:30,950
Mutta olen todella kiinnostunut vain
viimeisten 24 tunnin, viimeisten seitsemän päivän aikana,

1378
01:00:30,950 --> 01:00:31,659
viimeisten 30 päivän aikana.

1379
01:00:31,659 --> 01:00:34,074
Riippumatta ikkuna aikaa
että olen kiinnostunut näköinen

1380
01:00:34,074 --> 01:00:37,010
tapahtumaa, joka häiritsee minua, tai
Jos mielenkiintoista minulle,

1381
01:00:37,010 --> 01:00:39,540
se on ainoa ikkuna kerta, tarvitsen.

1382
01:00:39,540 --> 01:00:42,470
Joten miksi olen laskemisesta 10 vuotta
arvoinen lokitietoja taulukossa?

1383
01:00:42,470 --> 01:00:45,030
Mikä joka aiheuttaa on
taulukko fragmentti.

1384
01:00:45,030 --> 01:00:45,880
>> Se saa valtava.

1385
01:00:45,880 --> 01:00:48,340
Se alkaa ripustus
tuhansien solmujen.

1386
01:00:48,340 --> 01:00:51,380
Ja koska teidän kapasiteetti
on niin pieni, olet

1387
01:00:51,380 --> 01:00:54,090
todella nopeutta rajoittava kullakin
yksi niistä yksittäisten solmujen.

1388
01:00:54,090 --> 01:00:57,120
Joten aloitetaan tarkastelemalla, miten
Emme Roll että pöytä yli.

1389
01:00:57,120 --> 01:01:01,502
Miten onnistumme että tiedot hieman
parempi välttää näitä ongelmia.

1390
01:01:01,502 --> 01:01:02,710
Ja mitä se näyttää?

1391
01:01:02,710 --> 01:01:04,370
Tämä on mitä se näyttää.

1392
01:01:04,370 --> 01:01:06,790
Tämä on mitä huono NoSQL näyttää.

1393
01:01:06,790 --> 01:01:07,830
>> Sain kuuma tässä avainasemassa.

1394
01:01:07,830 --> 01:01:10,246
Jos katsot puolella täällä,
nämä ovat kaikki minun osioita.

1395
01:01:10,246 --> 01:01:12,630
Sain 16 osiot täällä
tästä nimenomaisesta tietokantaan.

1396
01:01:12,630 --> 01:01:13,630
Teemme tämän kaiken aikaa.

1397
01:01:13,630 --> 01:01:15,046
Juoksen tämä asiakkaille kaiken aikaa.

1398
01:01:15,046 --> 01:01:16,550
Sitä kutsutaan lämmön kartalla.

1399
01:01:16,550 --> 01:01:20,590
Lämpö kartta kertoo minulle miten olet
pääsemästä käsiksi avainta.

1400
01:01:20,590 --> 01:01:23,700
Ja mitä tämä kertoo minulle on
että on olemassa yksi erityisesti hash

1401
01:01:23,700 --> 01:01:26,330
että tämä kaveri tykkää
todella paljon, koska hän on

1402
01:01:26,330 --> 01:01:28,250
lyömällä sitä todella, todella kovaa.

1403
01:01:28,250 --> 01:01:29,260
>> Joten sininen on mukavaa.

1404
01:01:29,260 --> 01:01:29,900
Haluamme sininen.

1405
01:01:29,900 --> 01:01:30,720
Emme pidä punainen.

1406
01:01:30,720 --> 01:01:33,120
Redin jossa paine
nousee 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, nyt aiot olla kuristettu.

1408
01:01:35,560 --> 01:01:39,030
Joten kun näet kaikki punaiset linjat kuten
this-- ja se ei ole vain Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
jokainen NoSQL tietokanta on tämä ongelma.

1410
01:01:41,630 --> 01:01:44,640
On anti-malleja, jotka voivat
ajaa tällaisia ​​ehtoja.

1411
01:01:44,640 --> 01:01:49,070
Mitä teen, on työtä asiakkaiden kanssa
lieventämään näitä ehtoja.

1412
01:01:49,070 --> 01:01:51,840
>> Ja mitä se näyttää?

1413
01:01:51,840 --> 01:01:54,260
Ja tämä on saada eniten
ulos Dynamo DB läpijuoksu,

1414
01:01:54,260 --> 01:01:56,176
mutta se on todella tulossa
irti NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Tämä ei rajoitu Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Tämä on definitely-- I
työskenteli ravintolaan Mongo.

1417
01:02:02,050 --> 01:02:04,090
Olen perehtynyt monet NoSQL alustoilla.

1418
01:02:04,090 --> 01:02:06,830
Jokainen on tämäntyyppisiä
pikanäppäinjoukkoja ongelmia.

1419
01:02:06,830 --> 01:02:10,320
Saadaksesi kaiken irti mitään NoSQL
tietokanta, erityisesti Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
haluat luoda taulukoita
jossa hash avaintekijä on

1421
01:02:13,320 --> 01:02:18,590
suuri määrä eri arvoja,
korkea mahtavuus.

1422
01:02:18,590 --> 01:02:22,530
Koska se tarkoittaa Kirjoitan
on paljon erilaisia ​​kauhoja.

1423
01:02:22,530 --> 01:02:24,870
>> Enemmän kauhat olen
kirjallisesti, sitä todennäköisemmin

1424
01:02:24,870 --> 01:02:29,100
Olen levittää että kirjoittaa kuorma tai
lukea ladata pois useiden solmut,

1425
01:02:29,100 --> 01:02:33,560
todennäköisemmin olen olla
suurikapasiteettisten pöydälle.

1426
01:02:33,560 --> 01:02:37,440
Ja sitten haluan arvot
pyysi melko tasaisesti ajan mittaan

1427
01:02:37,440 --> 01:02:39,430
ja yhdenmukaisesti satunnaisesti kuin mahdollista.

1428
01:02:39,430 --> 01:02:42,410
No, se on aika mielenkiintoista,
koska en voi oikeastaan

1429
01:02:42,410 --> 01:02:43,960
ohjaus kun käyttäjät tulevat.

1430
01:02:43,960 --> 01:02:47,645
Joten riittää sanoa, jos me levittää
asioita poikki avainavaruus,

1431
01:02:47,645 --> 01:02:49,270
me todennäköisesti paremmassa kunnossa.

1432
01:02:49,270 --> 01:02:51,522
>> On tietty
määrä aikaisesti

1433
01:02:51,522 --> 01:02:53,230
että et tule
pystyä valvontaa.

1434
01:02:53,230 --> 01:02:55,438
Mutta ne ovat todella
kaksi ulottuvuutta, että meillä on,

1435
01:02:55,438 --> 01:02:58,800
, pääsy tasaisesti
leviäminen, aika, pyynnöt

1436
01:02:58,800 --> 01:03:01,040
saapuvia tasaisin välein ajoissa.

1437
01:03:01,040 --> 01:03:03,110
Ja jos nämä kaksi
edellytykset täyttyvät,

1438
01:03:03,110 --> 01:03:05,610
niin se mitä se on
tulee näyttämään.

1439
01:03:05,610 --> 01:03:07,890
Tämä on paljon mukavampi.

1440
01:03:07,890 --> 01:03:08,890
Olemme todella onnellinen täällä.

1441
01:03:08,890 --> 01:03:10,432
Meillä on hyvin tasainen käyttötapa.

1442
01:03:10,432 --> 01:03:13,098
Joo, ehkä saat
pieni paine aina silloin tällöin,

1443
01:03:13,098 --> 01:03:14,830
mutta mitään todella liian laaja.

1444
01:03:14,830 --> 01:03:17,660
Joten se on hämmästyttävää, kuinka monta kertaa,
Kun työskentelen asiakkaiden kanssa,

1445
01:03:17,660 --> 01:03:20,670
että ensin kuvaajan iso punainen
baari ja kaikki että ruma keltainen se on

1446
01:03:20,670 --> 01:03:23,147
koko paikka, me
saada tehdä harjoitus

1447
01:03:23,147 --> 01:03:24,980
jälkeen pari kuukautta
uudelleen arkkitehtuuri,

1448
01:03:24,980 --> 01:03:28,050
he käynnissä täsmälleen sama
kuormitusta täsmälleen sama kuorma.

1449
01:03:28,050 --> 01:03:30,140
Ja tämä on mitä se etsii kuin nyt.

1450
01:03:30,140 --> 01:03:36,600
Joten mitä saat NoSQL on
tiedot skeema, joka on ehdottoman

1451
01:03:36,600 --> 01:03:38,510
sidottu käyttötapa.

1452
01:03:38,510 --> 01:03:42,170
>> Ja voit optimoida että tiedot skeema
tukea että käyttötapa.

1453
01:03:42,170 --> 01:03:45,490
Jos et, niin olet menossa
nähdä näiden tyyppisiä ongelmia

1454
01:03:45,490 --> 01:03:46,710
näiden pikanäppäimet.

1455
01:03:46,710 --> 01:03:50,518
>> Yleisö: No, väistämättä paikoin
tulevat olemaan kuumempi kuin toiset.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Aina.

1457
01:03:51,450 --> 01:03:51,960
Aina.

1458
01:03:51,960 --> 01:03:54,620
Joo, tarkoitan on aina
a-- ja uudelleen, siellä on

1459
01:03:54,620 --> 01:03:56,980
jotkut suunnittelumalleja me selviydymme
että puhumme miten käsitellä

1460
01:03:56,980 --> 01:03:58,480
Näiden kookas koosteita.

1461
01:03:58,480 --> 01:04:01,260
Tarkoitan, sain ne,
miten me käsittelemme niitä?

1462
01:04:01,260 --> 01:04:03,760
Sain aika hyvä käyttötapaus
että me puhumme siitä.

1463
01:04:03,760 --> 01:04:05,940
>> Selvä, joten puhutaanpa
noin jotkut asiakkaat nyt.

1464
01:04:05,940 --> 01:04:06,950
Nämä kaverit ovat AdRoll.

1465
01:04:06,950 --> 01:04:08,990
En tiedä, jos olet
perehtynyt AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Olet luultavasti nähdä ne
paljon selaimen.

1467
01:04:10,781 --> 01:04:14,230
He ad uudelleen kohdentamista, he
suurin mainos uudelleen kohdistaminen liiketoiminnan

1468
01:04:14,230 --> 01:04:14,940
siellä.

1469
01:04:14,940 --> 01:04:17,792
Ne yleensä säännöllisesti ajaa yli
60000000000 liiketoimet päivässä.

1470
01:04:17,792 --> 01:04:20,000
He tekevät yli miljoona
tapahtumaa sekunnissa.

1471
01:04:20,000 --> 01:04:22,660
Heillä melko yksinkertainen pöytä
rakenne, vilkkain pöytä.

1472
01:04:22,660 --> 01:04:26,450
Se on pohjimmiltaan vain
ruutunäppäintä on evästeen,

1473
01:04:26,450 --> 01:04:29,010
alue on väestörakenteen
luokka, ja sitten

1474
01:04:29,010 --> 01:04:31,220
kolmas ominaisuus on pisteet.

1475
01:04:31,220 --> 01:04:33,720
>> Joten meillä kaikilla on evästeet
meidän selaimen nämä kaverit.

1476
01:04:33,720 --> 01:04:35,900
Ja kun menet
osallistuvien kauppias,

1477
01:04:35,900 --> 01:04:39,390
he pohjimmiltaan pisteet halki
eri väestöryhmää.

1478
01:04:39,390 --> 01:04:42,070
Kun menet verkkosivuilla ja
sanot Haluan nähdä tämän ad--

1479
01:04:42,070 --> 01:04:44,920
tai pohjimmiltaan et sano that--
mutta kun menet verkkosivuilla

1480
01:04:44,920 --> 01:04:47,550
he sanovat haluat nähdä tämän mainoksen.

1481
01:04:47,550 --> 01:04:49,370
Ja he menevät saada että mainos AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll näyttää sinut heidän pöytä.

1483
01:04:51,130 --> 01:04:52,115
Heidän mielestään evästeiden.

1484
01:04:52,115 --> 01:04:53,990
Mainostajat kertoo
heille, haluan jonkun

1485
01:04:53,990 --> 01:04:58,632
kuka keski-ikäinen,
40-vuotias mies, urheilullinen.

1486
01:04:58,632 --> 01:05:01,590
Ja ne pisteet sinua niissä väestötiedot
ja ne päättää

1487
01:05:01,590 --> 01:05:02,740
se on hyvä mainos sinulle.

1488
01:05:02,740 --> 01:05:10,330
>> Nyt heillä SLA kanssa
mainontaansa tarjoajat

1489
01:05:10,330 --> 01:05:14,510
tarjota osa-10 millisekunnin
vastaus jokaisesta pyynnöstä.

1490
01:05:14,510 --> 01:05:16,090
Joten he käyttävät Dynamo DB tähän.

1491
01:05:16,090 --> 01:05:18,131
He lyövät meitä
miljoonaa pyyntöä sekunnissa.

1492
01:05:18,131 --> 01:05:21,120
He pystyvät tekemään kaikki
hakuja, triage kaikki tiedot,

1493
01:05:21,120 --> 01:05:26,130
ja saada jotka lisäävät linkin takaisin, että
mainostajan alle 10 millisekuntia.

1494
01:05:26,130 --> 01:05:29,800
Se on oikeastaan ​​aika ilmiömäistä
täytäntöönpano, että heillä on.

1495
01:05:29,800 --> 01:05:36,210
>> Nämä kaverit actually--
nämä kaverit.

1496
01:05:36,210 --> 01:05:38,010
En ole varma, onko se nämä kaverit.

1497
01:05:38,010 --> 01:05:40,127
Ehkä nämä kaverit.

1498
01:05:40,127 --> 01:05:42,210
Periaatteessa kertoi us-- ei, en
usko, että se oli heille.

1499
01:05:42,210 --> 01:05:43,000
Mielestäni se oli joku muu.

1500
01:05:43,000 --> 01:05:44,750
Olin työskennellyt
Asiakkaalle, joka kertoi

1501
01:05:44,750 --> 01:05:47,040
että nyt, että he ovat
mennyt Dynamo DB, he

1502
01:05:47,040 --> 01:05:50,330
menoja enemmän rahaa välipaloja
niiden kehitystiimi joka kuukausi

1503
01:05:50,330 --> 01:05:52,886
kuin he käyttävät niiden tietokannassa.

1504
01:05:52,886 --> 01:05:54,760
Joten se antaa sinulle
Ajatus kustannussäästöjä

1505
01:05:54,760 --> 01:05:57,889
että voit saada Dynamo DB on valtava.

1506
01:05:57,889 --> 01:05:59,430
Okei, dropcam on toinen yritys.

1507
01:05:59,430 --> 01:06:02,138
Nämä kaveri on tavallaan of-- jos luulet
Internet asioita, dropcam

1508
01:06:02,138 --> 01:06:05,150
on pohjimmiltaan internet security video.

1509
01:06:05,150 --> 01:06:06,660
Voit laittaa kameran siellä.

1510
01:06:06,660 --> 01:06:08,180
Kamerassa on liiketunnistin.

1511
01:06:08,180 --> 01:06:10,290
Joku tulee pitkin,
laukaisee cue kohta.

1512
01:06:10,290 --> 01:06:13,540
Kamera alkaa tallentaa jonkin aikaa asti
se ei havaitse liikettä enää.

1513
01:06:13,540 --> 01:06:15,310
Laittaa että video jopa internetissä.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam oli yritys, joka on
pohjimmiltaan vaihtoi Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
koska he kokivat
valtavia kasvukipuja.

1516
01:06:22,200 --> 01:06:25,820
Ja mitä he kertoivat meille,
yhtäkkiä petatavua dataa.

1517
01:06:25,820 --> 01:06:28,070
Heillä ei ollut aavistustakaan niiden palvelu
olisi niin menestyksekäs.

1518
01:06:28,070 --> 01:06:32,310
Enemmän ulkomailta video kuin YouTube
on mitä nämä kaverit saavat.

1519
01:06:32,310 --> 01:06:36,780
He käyttävät DynamoDB seurata kaikkia
metatiedot kaikista videon avainkohdat.

1520
01:06:36,780 --> 01:06:40,282
>> Joten heillä on S3 kauhat ne työntää
kaikki binary esineitä osaksi.

1521
01:06:40,282 --> 01:06:41,990
Ja sitten he ovat
Dynamo DB Records että

1522
01:06:41,990 --> 01:06:44,070
kohta ihmiset kuin S3 kolme esinettä.

1523
01:06:44,070 --> 01:06:47,070
Kun he täytyy tarkastella videon,
he etsiä ennätys Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
He klikkaa linkkiä.

1525
01:06:47,903 --> 01:06:49,770
Ne vetää alas videon S3.

1526
01:06:49,770 --> 01:06:51,590
Niin, että on eräänlainen mitä tämä näyttää.

1527
01:06:51,590 --> 01:06:53,580
Ja tämä on suoraan niiden joukkue.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB vähentää niiden
toimitusaika video tapahtumia

1529
01:06:56,010 --> 01:06:57,590
viidestä 10 sekuntia.

1530
01:06:57,590 --> 01:07:00,470
Heidän vanha ihmissuhteisiin myymälä,
ne käytetään täytyy mennä ja toteuttaa

1531
01:07:00,470 --> 01:07:03,780
useita monimutkaisia ​​kyselyitä kuvan
mitkä videot kaatamaan,

1532
01:07:03,780 --> 01:07:06,690
vähemmän kuin 50 millisekuntia.

1533
01:07:06,690 --> 01:07:08,990
Joten se on hämmästyttävää, hämmästyttävä
kuinka paljon suorituskyky

1534
01:07:08,990 --> 01:07:12,990
saat kun optimoida ja
virität taustalla tietokanta

1535
01:07:12,990 --> 01:07:15,110
tukea käyttötapa.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, nämä kaverit, mitä on se,
Fruit Ninja kai on heidän asia.

1537
01:07:20,500 --> 01:07:22,590
Että kaikki Toimii Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
Ja nämä kaverit, he ovat suuri
kehitystiimi, suurta kehitystä

1539
01:07:26,810 --> 01:07:27,670
myymälä.

1540
01:07:27,670 --> 01:07:29,364
>> Ei hyvä ops joukkue.

1541
01:07:29,364 --> 01:07:31,280
Heillä ei ollut paljon
toiminnan resursseja.

1542
01:07:31,280 --> 01:07:33,940
Ne kamppailevat yrittää pitää
niiden soveltaminen infrastruktuurin ylös

1543
01:07:33,940 --> 01:07:34,290
ja käynnissä.

1544
01:07:34,290 --> 01:07:35,000
He tulivat meille.

1545
01:07:35,000 --> 01:07:36,251
He katsoivat, että Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
He sanoivat, että on meille.

1547
01:07:37,291 --> 01:07:39,470
He rakensivat koko
sovellus puitteet sitä.

1548
01:07:39,470 --> 01:07:43,640
Joitakin todella mukavia kommentteja
tiimiltä niiden kyvystä

1549
01:07:43,640 --> 01:07:46,800
nyt keskittyä rakentamaan
peli ja ei

1550
01:07:46,800 --> 01:07:49,010
ottaa säilyttää
infrastruktuuri, joka

1551
01:07:49,010 --> 01:07:51,910
oli tulossa valtava määrä
yläpuolella niiden joukkue.

1552
01:07:51,910 --> 01:07:56,170
Joten tämä on jotain that--
hyötyä, että saat Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Selvä, päästä
tietomallinnus täällä.

1554
01:08:00,930 --> 01:08:03,440
Ja puhuimme vähän
tämä yhtä, yksi monista,

1555
01:08:03,440 --> 01:08:05,060
ja monia monia tyyppi suhteita.

1556
01:08:05,060 --> 01:08:07,630
Ja miten säilyttää ne, Dynamo.

1557
01:08:07,630 --> 01:08:10,500
Vuonna Dynamo DB käytämme
indeksit, yleisesti ottaen,

1558
01:08:10,500 --> 01:08:12,910
kiertää tietoja
yksi maku toiseen.

1559
01:08:12,910 --> 01:08:15,210
Hash avaimet, alue avaimet ja indeksit.

1560
01:08:15,210 --> 01:08:18,540
>> Tässä nimenomaisessa
Esimerkiksi useimmat valtiot

1561
01:08:18,540 --> 01:08:23,802
on luvanvaraista, että
vain yksi ajokortti per henkilö.

1562
01:08:23,802 --> 01:08:26,510
Et voi mennä saada kaksi kuljettajan
lisenssit osavaltiossa Boston.

1563
01:08:26,510 --> 01:08:27,500
En voi tehdä sitä Texasissa.

1564
01:08:27,500 --> 01:08:28,708
Sellainen tapa se on.

1565
01:08:28,708 --> 01:08:32,779
Ja niin on DMV, olemme hakuja, me
haluavat etsiä ajokortti

1566
01:08:32,779 --> 01:08:35,180
jonka sosiaaliturvatunnus.

1567
01:08:35,180 --> 01:08:39,990
Haluan etsiä käyttäjän tiedot
kuljettajan ajokortin numero.

1568
01:08:39,990 --> 01:08:43,620
>> Joten saatamme olla käyttäjän taulukko,
on hash näppäintä sarjanumero,

1569
01:08:43,620 --> 01:08:47,830
tai sosiaaliturvatunnus, ja
eri ominaisuuksia määritellään kohteen.

1570
01:08:47,830 --> 01:08:49,859
Nyt että taulukko I
voitaisiin määritellä GSI joka

1571
01:08:49,859 --> 01:08:53,370
kääntää että noin joka sanoo haluan
ruutunäppäintä lisenssiin ja sitten

1572
01:08:53,370 --> 01:08:54,252
kaikki muut.

1573
01:08:54,252 --> 01:08:57,210
Nyt jos haluan kyselyn ja löytää
lisenssin numero tahansa sosiaalikomitean

1574
01:08:57,210 --> 01:08:59,609
Henkilötunnus, voin
kyselyn päätaulukko.

1575
01:08:59,609 --> 01:09:02,130
>> Jos haluan kyselyn ja haluan
saada sosiaaliturva

1576
01:09:02,130 --> 01:09:05,735
numero tai muu määritteitä
lisenssin numero, voin kyselyn GSI.

1577
01:09:05,735 --> 01:09:08,689
Tämä malli on, että yksi
yhden suhde.

1578
01:09:08,689 --> 01:09:12,460
Vain hyvin yksinkertainen GSI,
flip niitä asioita ympärillä.

1579
01:09:12,460 --> 01:09:13,979
Nyt puhutaan yhdeltä monelle.

1580
01:09:13,979 --> 01:09:16,450
Yksi monista on pohjimmiltaan
sinun hash alue avain.

1581
01:09:16,450 --> 01:09:20,510
Jos saamme paljon tämän
käyttötapaus on seurata tietoja.

1582
01:09:20,510 --> 01:09:23,880
Monitor tiedot tulee säännöllisesti
väli, kuten internet-asioita.

1583
01:09:23,880 --> 01:09:26,890
Olemme aina kaikki nämä
Records tulossa koko ajan.

1584
01:09:26,890 --> 01:09:31,420
>> Ja haluan löytää kaikki lukemat
välillä tietyn ajan kuluessa.

1585
01:09:31,420 --> 01:09:34,220
Se on hyvin yleinen kyselyn
seurannan infrastruktuuri.

1586
01:09:34,220 --> 01:09:38,430
Tapa edetä, joka on löytää
yksinkertainen taulukon rakenne, yksi pöytä.

1587
01:09:38,430 --> 01:09:42,250
Minulla laitemittausta taulukko
jossa ruutunäppäintä laitteen tunnus.

1588
01:09:42,250 --> 01:09:47,340
Ja minulla on valikoima näppäintä
aikaleiman, tai tässä tapauksessa, eeppinen.

1589
01:09:47,340 --> 01:09:50,350
Ja joka antaa minulle suorittaa monimutkaisia
kyselyitä, että alue avain

1590
01:09:50,350 --> 01:09:54,950
ja palauttaa nämä tiedot, jotka
ovat suhteessa tulosta

1591
01:09:54,950 --> 01:09:56,310
asettaa, että etsin.

1592
01:09:56,310 --> 01:09:58,360
Ja se rakentaa että yksi
moniin suhde

1593
01:09:58,360 --> 01:10:02,340
ensisijaiseen taulukkoon käyttäen
ruutunäppäintä, alue näppäinrakenne.

1594
01:10:02,340 --> 01:10:04,600
>> Joten on tavallaan rakennettu
osaksi taulukko Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Kun määritän hash
ja valikoima t pöytä, olen

1596
01:10:07,290 --> 01:10:09,240
määritellään yksi moneen.

1597
01:10:09,240 --> 01:10:12,770
Se on vanhempi-lapsi-suhde.

1598
01:10:12,770 --> 01:10:14,620
>> Puhutaanpa monista
ja monissa suhteissa.

1599
01:10:14,620 --> 01:10:19,170
Ja tätä erityistä esimerkiksi,
uudelleen, aiomme käyttää GSI: n.

1600
01:10:19,170 --> 01:10:23,500
Ja puhutaanpa pelaamista
skenaario, jossa minulla on tietty käyttäjä.

1601
01:10:23,500 --> 01:10:26,500
Haluan selvittää kaikki pelit, jotka
hän rekisteröity tai pelaavat.

1602
01:10:26,500 --> 01:10:29,600
Ja tietyn peli, I
haluavat löytää kaikille käyttäjille.

1603
01:10:29,600 --> 01:10:31,010
Joten miten voin tehdä sen?

1604
01:10:31,010 --> 01:10:34,330
Oma käyttäjä Pelipöytä, aion
on ruutunäppäintä käyttäjän tunnus

1605
01:10:34,330 --> 01:10:35,810
ja valikoima keskeinen pelin.

1606
01:10:35,810 --> 01:10:37,810
>> Joten käyttäjä voi olla useita pelejä.

1607
01:10:37,810 --> 01:10:41,380
Se on yksi monista suhdetta
käyttäjä ja pelejä hän pelaa.

1608
01:10:41,380 --> 01:10:43,410
Ja sitten GSI,
Minä kääntää että noin.

1609
01:10:43,410 --> 01:10:46,679
Minä Hash peli ja
Minä vaihtelevat käyttäjän.

1610
01:10:46,679 --> 01:10:48,970
Joten jos haluan saada kaikki
pelin käyttäjän pelaavat,

1611
01:10:48,970 --> 01:10:49,950
Minä kyselyn päätaulukko.

1612
01:10:49,950 --> 01:10:52,699
Jos haluan saada kaikki käyttäjät
että pelaavat tietyn pelin,

1613
01:10:52,699 --> 01:10:53,887
Olen kyselyn GSI.

1614
01:10:53,887 --> 01:10:54,970
Niin näet, miten teemme tämän?

1615
01:10:54,970 --> 01:10:58,369
Voit rakentaa nämä GSI: n tukea
use case, sovellus, pääsy

1616
01:10:58,369 --> 01:10:59,410
kuvio, sovellus.

1617
01:10:59,410 --> 01:11:01,440
>> Jos minun täytyy hakua
tämä ulottuvuus, anna

1618
01:11:01,440 --> 01:11:03,500
haluan luoda indeksin että ulottuvuus.

1619
01:11:03,500 --> 01:11:05,850
Jos en, en välitä.

1620
01:11:05,850 --> 01:11:09,060
Ja käytöstä riippuen tapauksessa I
ehkä indeksi tai etten tekisi.

1621
01:11:09,060 --> 01:11:12,390
Jos se on yksinkertainen yksi monista,
ensisijainen pöytä on hieno.

1622
01:11:12,390 --> 01:11:15,860
Jos minun täytyy tehdä nämä monet
monet n, tai minun täytyy tehdä yksi niistä,

1623
01:11:15,860 --> 01:11:18,390
niin ehkä en tarvitse
toiseen indeksiin.

1624
01:11:18,390 --> 01:11:20,840
Joten kaikki riippuu
mitä yritän tehdä

1625
01:11:20,840 --> 01:11:24,550
ja mitä yritän saada päätökseen.

1626
01:11:24,550 --> 01:11:28,000
>> Todennäköisesti En aio viettää liian
paljon aikaa puhumalla asiakirjoja.

1627
01:11:28,000 --> 01:11:31,460
Tämä saa vähän, luultavasti,
syvemmälle kuin meidän mennä.

1628
01:11:31,460 --> 01:11:33,710
Puhutaanpa hieman
noin rikas kysely ilme.

1629
01:11:33,710 --> 01:11:37,831
Joten Dynamo DB meillä
kyky luoda

1630
01:11:37,831 --> 01:11:39,330
mitä me kutsumme projektio ilmaisuja.

1631
01:11:39,330 --> 01:11:42,660
Projektio ilmaukset ovat yksinkertaisesti
poiminta kenttiä tai arvot

1632
01:11:42,660 --> 01:11:44,290
että haluat näyttää.

1633
01:11:44,290 --> 01:11:46,000
OK, joten en tee valinta.

1634
01:11:46,000 --> 01:11:48,010
Teen kyselyn vastaan ​​Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
Ja minä sanon, tiedät mitä, näyttää
minulle vain viiden tähden arvosteluja

1636
01:11:51,730 --> 01:11:54,544
kyseisen tuotteen.

1637
01:11:54,544 --> 01:11:55,710
Niin, että kaikki mitä haluan nähdä.

1638
01:11:55,710 --> 01:11:57,320
En halua nähdä kaikki
muita ominaisuuksia rivin,

1639
01:11:57,320 --> 01:11:58,319
Haluan vain nähdä tämän.

1640
01:11:58,319 --> 01:12:01,209
Se on aivan kuten SQL kun
sanoa Valitse tähti tai taulukosta,

1641
01:12:01,209 --> 01:12:02,000
saat kaiken.

1642
01:12:02,000 --> 01:12:05,450
Kun sanon valitse nimi
pöytä, minulla on vain yksi ominaisuus.

1643
01:12:05,450 --> 01:12:09,070
Se on samanlaista asia
Dynamo DB tai toisen NoSQL tietokantoja.

1644
01:12:09,070 --> 01:12:14,510
Suodatin ilmaisuja saanen
pohjimmiltaan leikata tulos vahvistetaan.

1645
01:12:14,510 --> 01:12:15,540
Joten teen kyselyn.

1646
01:12:15,540 --> 01:12:17,260
Kyselyn voi tulla takaisin 500 kohdetta.

1647
01:12:17,260 --> 01:12:20,255
Mutta Haluan vain kohteita, jotka
on ominaisuus, joka kertoo tämän.

1648
01:12:20,255 --> 01:12:23,380
OK, joten katsotaanpa suodattaa pois ne asiat
jotka eivät vastaa kyseisen kyselyn.

1649
01:12:23,380 --> 01:12:25,540
Joten meillä on suodatin ilmaisuja.

1650
01:12:25,540 --> 01:12:28,310
>> Suodatin ilmaisut voivat
käyttää kaikilla määrite.

1651
01:12:28,310 --> 01:12:30,260
He eivät pidä valikoima kyselyitä.

1652
01:12:30,260 --> 01:12:32,690
Nosta kyselyt ovat valikoivia.

1653
01:12:32,690 --> 01:12:36,470
Suodatin kyselyt vaativat minua menemään
saada koko tulokset asetettu ja sitten

1654
01:12:36,470 --> 01:12:39,170
raivata tietoja en halua.

1655
01:12:39,170 --> 01:12:40,660
Miksi se on tärkeää?

1656
01:12:40,660 --> 01:12:42,770
Koska olen lukenut kaiken.

1657
01:12:42,770 --> 01:12:46,597
Kyselyssä, aion lukea ja
se tulee olemaan jättiläinen noin tietoja.

1658
01:12:46,597 --> 01:12:48,430
Ja sitten aion
raivata mitä tarvitsen.

1659
01:12:48,430 --> 01:12:52,080
Ja jos olen vain erotetaan
pari riviä, niin se on OK.

1660
01:12:52,080 --> 01:12:53,620
Se ei ole niin tehoton.

1661
01:12:53,620 --> 01:12:57,800
>> Mutta jos luen koko kasa
tiedot, vain raivata yhden kohteen,

1662
01:12:57,800 --> 01:13:01,490
sitten aion olla parempi
pois käyttämällä erilaisia ​​kyselyn,

1663
01:13:01,490 --> 01:13:03,030
koska se on paljon enemmän valikoiva.

1664
01:13:03,030 --> 01:13:06,330
Se tulee säästää minulta paljon
rahaa, koska maksan että lukea.

1665
01:13:06,330 --> 01:13:10,430
Jos tulokset tulee takaisin
cross että lanka saattaa olla pienempi,

1666
01:13:10,430 --> 01:13:11,890
mutta olen maksaa lukea.

1667
01:13:11,890 --> 01:13:14,340
Joten ymmärtää, miten
saat tiedot.

1668
01:13:14,340 --> 01:13:16,420
Se on erittäin tärkeää Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Ehdollinen ilmaisuja, tämä on mitä
voisi kutsua optimistinen lukitus.

1670
01:13:19,710 --> 01:13:28,470
Päivitys JOS olemassa, tai jos tämä arvo
vastaa mitä voin määritellä.

1671
01:13:28,470 --> 01:13:31,494
Ja vaikka minulla olisi aikaa leima
ennätys, voisin lukea tietoja.

1672
01:13:31,494 --> 01:13:32,535
Voisin muuttaa että tiedot.

1673
01:13:32,535 --> 01:13:35,030
Voisin mennä kirjoittaa, että
tiedot takaisin tietokantaan.

1674
01:13:35,030 --> 01:13:38,100
Jos joku on muuttanut ennätys,
aikaleima saattanut muuttua.

1675
01:13:38,100 --> 01:13:40,370
Ja sillä tavalla minun ehdollinen
päivitys voisi sanoa päivitys

1676
01:13:40,370 --> 01:13:42,340
jos aikaleima vastaa tämän.

1677
01:13:42,340 --> 01:13:46,290
Tai päivitys epäonnistuu, koska joku
päivitetty ennätys tällä välin.

1678
01:13:46,290 --> 01:13:48,290
>> Sitähän me kutsumme optimistinen lukitus.

1679
01:13:48,290 --> 01:13:50,670
Se tarkoittaa, että joku
voi tulla ja muuttaa sitä,

1680
01:13:50,670 --> 01:13:53,100
ja aion havaita se
kun menen takaisin kirjoittaa.

1681
01:13:53,100 --> 01:13:56,106
Ja sitten en voi itse lukea, että
tiedot ja sanoa, oi, hän muutti tätä.

1682
01:13:56,106 --> 01:13:57,230
Minun täytyy selittää, että.

1683
01:13:57,230 --> 01:14:00,490
Ja voin vaihtaa tietoja minun
tallentaa ja soveltaa toisen päivityksen.

1684
01:14:00,490 --> 01:14:04,330
Voit siis kiinni ne vähitellen
päivityksiä, jotka tapahtuvat välillä aika

1685
01:14:04,330 --> 01:14:08,740
että luet tiedot ja
aika saatat kirjoittaa tiedot.

1686
01:14:08,740 --> 01:14:11,520
>> Yleisö: Ja suodatin
ilmaus oikeastaan ​​tarkoittaa ei

1687
01:14:11,520 --> 01:14:13,020
määrän tai not--

1688
01:14:13,020 --> 01:14:14,316
>> [Väliin ÄÄNTÄ]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: en tahdo
saada liikaa tähän.

1690
01:14:16,232 --> 01:14:17,700
Tämä on varattu avainsana.

1691
01:14:17,700 --> 01:14:20,130
Punta näkymä on varattu
hakusana Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Jokainen tietokanta on oma varattu
nimiä kokoelmia ei voi käyttää.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, jos valitset
punta edessä tämän,

1694
01:14:27,240 --> 01:14:29,310
voit määritellä ne nimiä yläpuolelle.

1695
01:14:29,310 --> 01:14:31,840
Tämä on viitattu arvo.

1696
01:14:31,840 --> 01:14:34,880
Se on luultavasti ole paras syntaksin
on siellä tästä keskustelusta,

1697
01:14:34,880 --> 01:14:38,090
koska se joutuu joitakin real--
Olisin puhunut lisää

1698
01:14:38,090 --> 01:14:41,360
siitä syvemmällä tasolla.

1699
01:14:41,360 --> 01:14:46,130
>> Mutta riittää sanoa, tämä voisi
olla kysely skannata jossa he views--

1700
01:14:46,130 --> 01:14:50,190
eikä punta näkymät on suurempi kuin 10.

1701
01:14:50,190 --> 01:14:54,660
Se on numeerinen arvo, kyllä.

1702
01:14:54,660 --> 01:14:57,322
Jos haluat, voimme puhua
että kun keskustelun.

1703
01:14:57,322 --> 01:15:00,030
Selvä, joten olemme joutumassa
joitakin skenaarioita parhaita käytäntöjä

1704
01:15:00,030 --> 01:15:02,000
minne olemme menossa puhua
joitakin apps täällä.

1705
01:15:02,000 --> 01:15:03,810
Mitkä ovat käytön tapauksissa Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Mitä suunnittelu
malleja Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> Ja ensimmäinen aiomme
puhua on internet asioita.

1708
01:15:09,110 --> 01:15:15,010
Joten saamme paljon of-- luulisin,
mikä on it-- yli 50%

1709
01:15:15,010 --> 01:15:19,370
Liikenteen Internetissä näinä päivinä
on todella syntyy koneiden,

1710
01:15:19,370 --> 01:15:21,930
automatisoidut prosessit, ei ihmisten.

1711
01:15:21,930 --> 01:15:25,140
Tarkoitan tämä asia tämä asia
teillä noin taskussa,

1712
01:15:25,140 --> 01:15:28,840
miten paljon tietoa, että asia on
todella lähettävät noin ilman sinua

1713
01:15:28,840 --> 01:15:30,550
tietäen se on aivan uskomatonta.

1714
01:15:30,550 --> 01:15:34,970
Sijaintisi, tiedot
kuinka nopeasti olet menossa.

1715
01:15:34,970 --> 01:15:38,400
Miten luulet Google Maps teoksia
kun he kertovat, mitä liikenne on.

1716
01:15:38,400 --> 01:15:41,275
Se johtuu siitä, on miljoonia ja
miljoonat ihmiset ajelemassa

1717
01:15:41,275 --> 01:15:44,667
puhelimilla, jotka lähettävät
tiedot koko paikka koko ajan.

1718
01:15:44,667 --> 01:15:46,500
Niin yksi niistä asioista
noin tämäntyyppisiä tietoja

1719
01:15:46,500 --> 01:15:50,980
joka tulee, seurata tietojen log
tiedot, aikasarjatiedot, on se

1720
01:15:50,980 --> 01:15:53,540
yleensä vain mielenkiintoinen
sillä vähän aikaa.

1721
01:15:53,540 --> 01:15:55,580
Tuon ajan jälkeen, se on
ei niin kiinnostavaa.

1722
01:15:55,580 --> 01:15:58,390
Joten puhuimme, älä anna
Mainituissa taulukoissa kasvaa ilman rajoja.

1723
01:15:58,390 --> 01:16:03,410
Ideana on, että ehkä minulla 24
tunnin edestä tapahtumien hot taulukossa.

1724
01:16:03,410 --> 01:16:06,160
Ja että kuuma taulukko tulee olemaan
palveluntarjoajan on erittäin korkea,

1725
01:16:06,160 --> 01:16:07,950
koska se vie paljon tietoa.

1726
01:16:07,950 --> 01:16:10,920
Se vie paljon tietoa
ja luen sitä paljon.

1727
01:16:10,920 --> 01:16:14,560
Minulla on paljon toimintaa
kyselyitä käynnissä vastaan, että tiedot.

1728
01:16:14,560 --> 01:16:18,120
>> 24 tunnin kuluttua, hei, te
tiedä mitä, en välitä.

1729
01:16:18,120 --> 01:16:21,150
Joten ehkä jokainen keskiyöllä roll
minun pöytä yli uuteen pöytään

1730
01:16:21,150 --> 01:16:22,430
ja minä deprovision tässä taulukossa.

1731
01:16:22,430 --> 01:16:26,440
Ja otan RCU: n ja
WCU n alas, koska 24 tuntia myöhemmin

1732
01:16:26,440 --> 01:16:28,630
Minulla ei ole niin paljon
kyselyitä, että tiedot.

1733
01:16:28,630 --> 01:16:30,200
Joten aion säästää rahaa.

1734
01:16:30,200 --> 01:16:32,940
Ja ehkä 30 päivää myöhemmin en
tarvitse edes välitä siitä kaiken.

1735
01:16:32,940 --> 01:16:35,020
Voisin ottaa WCU n
kaikki alas yksi,

1736
01:16:35,020 --> 01:16:36,990
koska tiedät mitä, se on
koskaan saada kirjoitetaan.

1737
01:16:36,990 --> 01:16:38,300
Tiedot on 30 päivää vanha.

1738
01:16:38,300 --> 01:16:40,000
Se ei koskaan muutu.

1739
01:16:40,000 --> 01:16:44,200
>> Ja se on melkein koskaan saada lukea,
joten haluan vain ottaa että RCU alas 10.

1740
01:16:44,200 --> 01:16:49,372
Ja olen säästää tonni rahaa tähän
tiedot, ja vain maksaa hot tiedot.

1741
01:16:49,372 --> 01:16:52,330
Niin, että tärkeä asia tarkastella
klo kun tarkastellaan aikasarjan

1742
01:16:52,330 --> 01:16:54,716
tulevia tietoja volyymin.

1743
01:16:54,716 --> 01:16:55,590
Nämä ovat strategioita.

1744
01:16:55,590 --> 01:16:58,010
Nyt voisin vain antaa sen
kaikki mene samaan pöytään

1745
01:16:58,010 --> 01:16:59,461
ja vain antaa kyseisen taulukon kasvaa.

1746
01:16:59,461 --> 01:17:01,460
Lopulta, aion
katso suorituskykyyn liittyviä ongelmia.

1747
01:17:01,460 --> 01:17:04,060
Aion on aloitettava arkistoon
jotkut tietojen pöydältä,

1748
01:17:04,060 --> 01:17:04,720
mitä ei.

1749
01:17:04,720 --> 01:17:07,010
>> Katsotaanpa paljon parempi
suunnitella sovellus

1750
01:17:07,010 --> 01:17:08,900
jotta voit käyttää tällä tavalla oikea.

1751
01:17:08,900 --> 01:17:11,460
Joten se on vain automaattinen
hakemuksessa koodi.

1752
01:17:11,460 --> 01:17:13,580
Keskiyöllä joka yö
se vierii taulukon.

1753
01:17:13,580 --> 01:17:17,170
Ehkä mitä tarvitsen on liukuva
ikkuna 24 tunnin tiedot.

1754
01:17:17,170 --> 01:17:20,277
Sitten säännöllisesti olen
jossa tiedot pöydältä.

1755
01:17:20,277 --> 01:17:22,360
Olen leikkaus sen
Ajastettu tehtävä ja Laitan sen

1756
01:17:22,360 --> 01:17:24,160
kiinni näistä muissa taulukoissa,
mitä tarvitset.

1757
01:17:24,160 --> 01:17:25,940
Joten jos kaatuessa toimii, se on hienoa.

1758
01:17:25,940 --> 01:17:27,080
Jos ei, leikkaa se.

1759
01:17:27,080 --> 01:17:29,640
Mutta katsotaanpa pitää että kuuma tiedot
pois kylmä tiedot.

1760
01:17:29,640 --> 01:17:32,535
Se tulee säästää paljon rahaa ja
tehdä taulukoita enemmän suorittamista.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Joten seuraava asia niin jutellaan
Tietoja on tuote luettelo.

1763
01:17:38,210 --> 01:17:42,000
Tavaroiden luettelo on
melko yleinen käyttötapaus.

1764
01:17:42,000 --> 01:17:46,600
Tämä on itse asiassa hyvin yleinen malli
että näemme eri asioita.

1765
01:17:46,600 --> 01:17:48,870
Tiedäthän, Twitter
Esimerkiksi kuuma visertää.

1766
01:17:48,870 --> 01:17:51,280
Jokaisella on tulossa ja
tarttumalla että titityy.

1767
01:17:51,280 --> 01:17:52,680
Tavaroiden luettelo, sain myyntiin.

1768
01:17:52,680 --> 01:17:54,120
Sain kuuma myynti.

1769
01:17:54,120 --> 01:17:57,277
Sain 70000 pyyntöjä kohden
toinen tulossa tuote

1770
01:17:57,277 --> 01:17:58,860
kuvaus ulos my tuoteluettelo.

1771
01:17:58,860 --> 01:18:02,384
Näemme tämän vähittäiskaupan
toiminta melko vähän.

1772
01:18:02,384 --> 01:18:03,550
Miten siis käsitellä että?

1773
01:18:03,550 --> 01:18:04,924
Ei ole mitään keinoa käsitellä että.

1774
01:18:04,924 --> 01:18:07,110
Kaikki minun käyttäjät haluavat nähdä
samoja tietoja.

1775
01:18:07,110 --> 01:18:09,410
He ovat tulossa, samanaikaisesti.

1776
01:18:09,410 --> 01:18:11,920
Ja he kaikki tehdä pyyntöjä
että samoja tietoja.

1777
01:18:11,920 --> 01:18:16,240
Tämä antaa minulle että pikanäppäintä, että iso punainen
raita minun kaavio että emme pidä.

1778
01:18:16,240 --> 01:18:17,720
Ja niinhän se näyttää.

1779
01:18:17,720 --> 01:18:22,290
Joten koko minun avainta Saan
kädenvääntöä myyntiin kohteita.

1780
01:18:22,290 --> 01:18:24,070
Saan mitään missään muualla.

1781
01:18:24,070 --> 01:18:26,050
>> Miten tämän ongelman lieventämiseksi?

1782
01:18:26,050 --> 01:18:28,410
No, me lievittää tätä välimuisti.

1783
01:18:28,410 --> 01:18:33,630
Cache, laitat pohjimmiltaan in-muisti
osio edessä tietokantaan.

1784
01:18:33,630 --> 01:18:37,260
Olemme onnistuneet
[Äänetön] välimuisti, miten

1785
01:18:37,260 --> 01:18:40,260
voi perustaa oman välimuistin, [kuulumaton]
välimuisti [? d,?] mitä haluat.

1786
01:18:40,260 --> 01:18:42,220
Laita että jopa edessä tietokantaan.

1787
01:18:42,220 --> 01:18:47,250
Ja näin voit tallentaa että tiedot
Näistä pikanäppäimet tuohon välimuisti

1788
01:18:47,250 --> 01:18:49,390
tilaa ja lukea läpi välimuisti.

1789
01:18:49,390 --> 01:18:51,962
>> Ja sitten irti lukee
alkaa etsiä näin.

1790
01:18:51,962 --> 01:18:54,920
Sain kaikki nämä välimuisti osuu täällä
ja sain mitään täällä tapahtuu

1791
01:18:54,920 --> 01:18:59,330
koska tietokanta istuu takana
välimuisti ja lukee koskaan tule läpi.

1792
01:18:59,330 --> 01:19:02,520
Jos muutan tietoja
tietokanta, minun täytyy päivittää välimuistia.

1793
01:19:02,520 --> 01:19:04,360
Voimme käyttää jotain
kuten höyryää tehdä niin.

1794
01:19:04,360 --> 01:19:07,360
Ja Selitän miten se toimii.

1795
01:19:07,360 --> 01:19:09,060
Hyvä, messaging.

1796
01:19:09,060 --> 01:19:11,180
Sähköposti, me kaikki käytämme sähköpostia.

1797
01:19:11,180 --> 01:19:12,540
>> Tämä on aika hyvä esimerkki.

1798
01:19:12,540 --> 01:19:14,950
Meillä jonkinlaisen viestejä pöytä.

1799
01:19:14,950 --> 01:19:17,040
Ja saimme Saapuneet ja Lähtevät.

1800
01:19:17,040 --> 01:19:19,760
Tämä on mitä SQL olisi
näyttävät rakentaa että postilaatikkoon.

1801
01:19:19,760 --> 01:19:23,350
Olemme tavallaan käyttävät samanlaista
Strategian käyttää GSI: n, GSI: n

1802
01:19:23,350 --> 01:19:25,320
minun Saapuneet ja minun Lähtevät.

1803
01:19:25,320 --> 01:19:27,600
Joten sain raaka tulevat viestit
minun viestejä pöytä.

1804
01:19:27,600 --> 01:19:30,194
Ja ensimmäinen lähestymistapa tähän
voisi olla, sanoa, OK, ei ole ongelma.

1805
01:19:30,194 --> 01:19:31,110
Minulla raaka viestejä.

1806
01:19:31,110 --> 01:19:33,710
Tulevat viestit [kuulumaton],
Viestin tunnus, se on hienoa.

1807
01:19:33,710 --> 01:19:35,070
Se on minun ainutlaatuinen hash.

1808
01:19:35,070 --> 01:19:38,280
Aion luoda kaksi GSI: n, yksi
minun postilaatikkoon, yksi minun Lähtevät.

1809
01:19:38,280 --> 01:19:40,530
Ja ensimmäinen asia teen
on Sanon minun ruutunäppäintä on

1810
01:19:40,530 --> 01:19:43,310
olemaan vastaanottaja ja
Aion järjestää mennessä.

1811
01:19:43,310 --> 01:19:44,220
Tämä on fantastinen.

1812
01:19:44,220 --> 01:19:45,890
Sain mukava katsella täällä.

1813
01:19:45,890 --> 01:19:47,780
Mutta on vähän kysymys.

1814
01:19:47,780 --> 01:19:50,891
Ja olet joutunut tämän
relaatiotietokantojen samoin.

1815
01:19:50,891 --> 01:19:52,390
He kutsuivat pystysuoraan osioinnin.

1816
01:19:52,390 --> 01:19:55,840
Haluat pitää big data
pois vähän tietoa.

1817
01:19:55,840 --> 01:20:00,470
>> Ja syy miksi koska minun täytyy
mennä lukemaan kohteita saada määritteitä.

1818
01:20:00,470 --> 01:20:05,570
Ja jos elimet ovat kaikki täällä,
sitten lukee vain muutamia kohteita

1819
01:20:05,570 --> 01:20:08,560
jos ruumiin pituus on
keskimäärin 256 kilotavua kullekin,

1820
01:20:08,560 --> 01:20:10,991
matematiikka saa melko ruma.

1821
01:20:10,991 --> 01:20:12,490
Sano Haluan lukea Daavidin postilaatikkoon.

1822
01:20:12,490 --> 01:20:14,520
David sähköpostilaatikkoon on 50 kohdetta.

1823
01:20:14,520 --> 01:20:17,880
Keskimääräinen ja koko on 256 kilotavua.

1824
01:20:17,880 --> 01:20:21,730
Tässä on minun tulosmuuntokertoimeen
sillä RCU: n on neljä kilotavua.

1825
01:20:21,730 --> 01:20:24,450
>> OK, mennään kanssa
lopulta johdonmukainen lukee.

1826
01:20:24,450 --> 01:20:28,640
Olen edelleen syö 1600 RCU: n
vain lukea Daavidin postilaatikkoon.

1827
01:20:28,640 --> 01:20:29,950
Auts.

1828
01:20:29,950 --> 01:20:31,980
OK, nyt mietitäänpä
miten sovellus toimii.

1829
01:20:31,980 --> 01:20:35,340
Jos olen sähköpostia sovelluksen ja
Etsin minun postilaatikkoon,

1830
01:20:35,340 --> 01:20:39,680
ja katson ruumista jokaisen viestin,
Ei, Etsin yhteenvedot.

1831
01:20:39,680 --> 01:20:41,850
Etsin vain otsikot.

1832
01:20:41,850 --> 01:20:46,310
Joten rakentaa taulukon rakenne
joka näyttää enemmän kuin että.

1833
01:20:46,310 --> 01:20:49,470
>> Joten tässä tiedot
että minun työnkulun tarpeisiin.

1834
01:20:49,470 --> 01:20:50,890
Se on minun postilaatikkoon GSI.

1835
01:20:50,890 --> 01:20:53,800
Se päivämäärä, lähettäjä,
aihe, ja sitten

1836
01:20:53,800 --> 01:20:56,790
viestin tunnus, joka osoittaa
takaisin viestien taulukkoon

1837
01:20:56,790 --> 01:20:57,850
mistä saan kehon.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
No, nämä olisivat ennätys tunnukset.

1840
01:21:04,420 --> 01:21:09,850
He kohta takaisin
Tuote tunnukset Dynamo DB taulukossa.

1841
01:21:09,850 --> 01:21:12,220
Jokainen indeksi aina creates--
aina on kohde

1842
01:21:12,220 --> 01:21:15,750
ID osana of-- että
mukana indeksi.

1843
01:21:15,750 --> 01:21:17,414
>> Selvä.

1844
01:21:17,414 --> 01:21:19,080
Yleisö: Se kertoo se, jos se on tallennettu?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Kyllä, se kertoo
exactly-- se on juuri sitä mitä se tekee.

1846
01:21:21,420 --> 01:21:22,644
Se sanoo tässä on minun uudelleen ennätys.

1847
01:21:22,644 --> 01:21:24,310
Ja se tulee kohta takaisin minun uudelleen ennätys.

1848
01:21:24,310 --> 01:21:26,460
Täsmälleen.

1849
01:21:26,460 --> 01:21:29,490
OK, joten nyt minun postilaatikkoon on
todella paljon pienempi.

1850
01:21:29,490 --> 01:21:32,210
Ja tämä todella tukee
työnkulun sähköpostia sovelluksen.

1851
01:21:32,210 --> 01:21:34,230
Joten minun postilaatikkoon, painan.

1852
01:21:34,230 --> 01:21:38,160
Menen pitkin ja klikkaan viestin,
silloin minun täytyy mennä saada kehon,

1853
01:21:38,160 --> 01:21:40,180
koska aion
mennä eri mieltä.

1854
01:21:40,180 --> 01:21:43,870
Joten jos ajattelee MVC tyyppi
puitteet, malli näkymä-ohjain.

1855
01:21:43,870 --> 01:21:46,120
>> Malli sisältää
tiedot että näkymä tarpeet

1856
01:21:46,120 --> 01:21:48,130
ja ohjaimen vuorovaikutuksessa.

1857
01:21:48,130 --> 01:21:51,670
Kun minä muuttaa kehyksen, kun
Muutan näkökulmasta,

1858
01:21:51,670 --> 01:21:55,080
se on OK palata
palvelin ja asuttaa malli,

1859
01:21:55,080 --> 01:21:56,860
koska sitähän käyttäjä odottaa.

1860
01:21:56,860 --> 01:22:00,530
Kun he vaihtavat näkemyksiä, silloin
voimme mennä takaisin tietokantaan.

1861
01:22:00,530 --> 01:22:02,480
Joten sähköpostia, valitse.

1862
01:22:02,480 --> 01:22:03,710
Etsin elin.

1863
01:22:03,710 --> 01:22:04,330
Meno-paluu matka.

1864
01:22:04,330 --> 01:22:05,680
Mennä saada kehon.

1865
01:22:05,680 --> 01:22:06,950
>> Luen paljon vähemmän tietoja.

1866
01:22:06,950 --> 01:22:09,960
Olen vain käsittelyssä elinten
David tarvitsee, kun hän tarvitsee niitä.

1867
01:22:09,960 --> 01:22:14,230
Enkä polttaa 1600
RCU: n vain osoittaa hänen postilaatikkoon.

1868
01:22:14,230 --> 01:22:17,670
Joten nyt that-- tämä on tapa
että LSI tai GSI-- Olen pahoillani,

1869
01:22:17,670 --> 01:22:19,900
GSI, järjestyisi.

1870
01:22:19,900 --> 01:22:25,450
Meillä meidän hash vastaanottajan.

1871
01:22:25,450 --> 01:22:27,030
Meillä alue näppäintä mennessä.

1872
01:22:27,030 --> 01:22:31,380
Ja meillä ennustetaan määritteet
että meidän täytyy vain tukevan näkemystä.

1873
01:22:31,380 --> 01:22:34,300
>> Me kiertää että Lähtevät.

1874
01:22:34,300 --> 01:22:35,770
Hash lähettäjä.

1875
01:22:35,770 --> 01:22:39,612
Ja pohjimmiltaan olemme
erittäin mukava, puhdas katsella.

1876
01:22:39,612 --> 01:22:41,570
Ja se on basically-- me
on tämä mukava viestejä

1877
01:22:41,570 --> 01:22:45,870
taulukko, joka on on levinnyt mukavasti, sillä
se on hash vain, hajauttamat viestin tunnus.

1878
01:22:45,870 --> 01:22:51,750
Ja meillä on kaksi indeksit
pyörivät pois kyseisen taulukon.

1879
01:22:51,750 --> 01:22:57,411
Selvä, joten ajatus tässä ei
pitää big data ja tämän pienen tiedot

1880
01:22:57,411 --> 01:22:57,910
yhdessä.

1881
01:22:57,910 --> 01:23:00,700
Partition pystysuoraan,
osio kyseiset taulukot.

1882
01:23:00,700 --> 01:23:03,150
Älä lue tietoja sinun ei tarvitse.

1883
01:23:03,150 --> 01:23:04,850
Hyvä, pelaamista.

1884
01:23:04,850 --> 01:23:06,990
Me kaikki haluamme pelejä.

1885
01:23:06,990 --> 01:23:10,902
Ainakin Pidän pelejä sitten.

1886
01:23:10,902 --> 01:23:12,735
Joten joitakin asioita
että me käsitellä, kun

1887
01:23:12,735 --> 01:23:14,193
ajattelemme pelaamista, eikö?

1888
01:23:14,193 --> 01:23:16,999
Pelaamista näinä päivinä, erityisesti mobiili
pelaamista, on kyse ajattelua.

1889
01:23:16,999 --> 01:23:19,540
Ja aion kiertää täällä
vähän etäämmälle DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Aion tuoda
jotkut keskustelua

1891
01:23:21,373 --> 01:23:24,240
noin joitakin
muut AWS teknologioita.

1892
01:23:24,240 --> 01:23:28,930
>> Mutta ajatus siitä pelaaminen on ajatella
noin kannalta API, API, jotka ovat,

1893
01:23:28,930 --> 01:23:31,730
yleisesti ottaen, HTTP ja JSON.

1894
01:23:31,730 --> 01:23:34,550
Se miten mobiilipelejä sellainen
vuorovaikutuksessa niiden takaisin päät.

1895
01:23:34,550 --> 01:23:35,850
He tekevät JSON lähettämistä.

1896
01:23:35,850 --> 01:23:40,660
He saavat tietoa, ja se on kaikki,
yleisesti ottaen, Nizzassa JSON API.

1897
01:23:40,660 --> 01:23:44,950
>> Asiat kuten saada ystäviä, saada
leaderboard, vaihtaa tietoja,

1898
01:23:44,950 --> 01:23:47,699
käyttäjien luoman sisällön,
työntää takaisin ylös järjestelmään,

1899
01:23:47,699 --> 01:23:49,740
nämä ovat tyyppisiä asioita
että aiomme tehdä.

1900
01:23:49,740 --> 01:23:52,542
Binary omaisuuden tiedot, nämä tiedot
ei ehkä istua tietokantaan.

1901
01:23:52,542 --> 01:23:54,250
Tämä voi istua
esine myymälä, eikö?

1902
01:23:54,250 --> 01:23:56,541
Mutta tietokanta on menossa
päätyvät kertoo järjestelmän,

1903
01:23:56,541 --> 01:23:59,140
kertoo hakemus
minne mennä saada se.

1904
01:23:59,140 --> 01:24:03,550
Ja väistämättä, moninpeli
palvelimet, loppupäätä infrastruktuuri,

1905
01:24:03,550 --> 01:24:06,180
ja suunniteltu korkean
saatavuus ja skaalautuvuutta.

1906
01:24:06,180 --> 01:24:09,400
Joten nämä ovat asioita, joita me kaikki haluamme
vuonna pelaamista infrastruktuuriin tänään.

1907
01:24:09,400 --> 01:24:12,160
>> Joten katsomaan
mitä se näyttää.

1908
01:24:12,160 --> 01:24:16,070
Sai ydin loppupäätä,
hyvin yksinkertainen.

1909
01:24:16,070 --> 01:24:19,880
Meillä järjestelmä täällä
useita saatavuus alueilla.

1910
01:24:19,880 --> 01:24:23,780
Puhuimme AZS kuin being-- ajatella
niistä erillisinä datakeskusten.

1911
01:24:23,780 --> 01:24:26,040
Enemmän kuin yksi datakeskuksen
per AZ, mutta se on OK,

1912
01:24:26,040 --> 01:24:28,831
ajatelkaa niitä erilliset tiedot
keskuksia, jotka ovat maantieteellisesti

1913
01:24:28,831 --> 01:24:30,090
ja vika eristetty.

1914
01:24:30,090 --> 01:24:32,172
>> Aiomme olla
pari EC2 tapauksissa.

1915
01:24:32,172 --> 01:24:33,880
Aiomme olla
jotkut loppupäätä palvelimelle.

1916
01:24:33,880 --> 01:24:35,800
Ehkä jos olet perintö
arkkitehtuuri, olemme

1917
01:24:35,800 --> 01:24:38,920
käyttäen mitä kutsumme RDS,
relaatiotietokanta palvelut.

1918
01:24:38,920 --> 01:24:42,040
Voisi olla MSSQL, MySQL,
Tai jotain sellaista.

1919
01:24:42,040 --> 01:24:47,080
Tämä on tapa paljon hakemuksia
suunnitellaan tänään.

1920
01:24:47,080 --> 01:24:49,594
>> No me ehkä halua mennä kanssa
tämä on, kun me mittakaavassa ulos.

1921
01:24:49,594 --> 01:24:51,510
Menemme eteenpäin ja laittaa
S3 ämpäri siellä.

1922
01:24:51,510 --> 01:24:54,200
Ja että S3 ämpäri, palvelemisen sijasta
nuo esineitä meidän servers--

1923
01:24:54,200 --> 01:24:55,220
voisimme tehdä sen.

1924
01:24:55,220 --> 01:24:57,210
Voit laittaa kaikki binary
esineitä palvelimia

1925
01:24:57,210 --> 01:24:59,751
ja voit käyttää niitä palvelimen
tapauksissa palvelemaan että tiedot ylös.

1926
01:24:59,751 --> 01:25:01,860
Mutta se on melko kallista.

1927
01:25:01,860 --> 01:25:05,107
>> Parempi tapa tehdä on mennä eteenpäin ja
laittaa ne esineitä S3 ämpäri.

1928
01:25:05,107 --> 01:25:06,315
S3 on esine arkistot.

1929
01:25:06,315 --> 01:25:10,860
Se on rakennettu erityisesti
palvelevat tämäntyyppisiä asioita.

1930
01:25:10,860 --> 01:25:13,690
Ja nuo asiakkaat pyytävät
suoraan näiden esine kauhat,

1931
01:25:13,690 --> 01:25:15,390
purkamaan palvelimet.

1932
01:25:15,390 --> 01:25:17,020
Joten olemme alkaneet mittakaavassa täällä.

1933
01:25:17,020 --> 01:25:19,140
>> Nyt saimme käyttäjät ympäri maailmaa.

1934
01:25:19,140 --> 01:25:19,730
Sain käyttäjille.

1935
01:25:19,730 --> 01:25:23,380
Minun täytyy olla sisältöä paikallisesti
lähellä näille käyttäjille, eikö?

1936
01:25:23,380 --> 01:25:26,200
Olen luonut S3 ämpäri
OMA LÄHDE arkistoon.

1937
01:25:26,200 --> 01:25:29,370
Ja minä edessä että
CloudFront jakelu.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront on CD ja
sisältöä jakeluverkoston.

1939
01:25:31,720 --> 01:25:35,750
Periaatteessa se vie tietoja, jotka olet määrittänyt
ja välimuistit se kaikki Internetissä

1940
01:25:35,750 --> 01:25:39,230
joten käyttäjät kaikkialla voivat olla
erittäin nopea vastaus, kun

1941
01:25:39,230 --> 01:25:40,960
he pyytävät nämä esineet.

1942
01:25:40,960 --> 01:25:41,960
>> Joten saat käsityksen.

1943
01:25:41,960 --> 01:25:48,230
Olet tavallaan hyödyntämällä kaikki
näkökohtia AWS täällä saada tämä tehtävä.

1944
01:25:48,230 --> 01:25:50,790
Ja lopulta, heitämme
auto-skaalaus ryhmä.

1945
01:25:50,790 --> 01:25:52,737
Joten meidän AC2 tapauksissa
meidän peli palvelimia,

1946
01:25:52,737 --> 01:25:54,820
kun ne alkavat saada kiireisempiä
ja vilkkaampi ja vilkkaampi,

1947
01:25:54,820 --> 01:25:57,236
he vain spin toinen
Esimerkiksi spin toisessa tapauksessa,

1948
01:25:57,236 --> 01:25:58,210
spin toisessa tapauksessa.

1949
01:25:58,210 --> 01:26:02,090
Joten tekniikka AWS on, se
avulla voit määrittää parametrit

1950
01:26:02,090 --> 01:26:04,650
joiden ympärille palvelimet kasvaa.

1951
01:26:04,650 --> 01:26:08,110
Joten voit olla n palvelimien määrä
siellä kulloinkin.

1952
01:26:08,110 --> 01:26:11,870
Ja jos kuorma menee pois, he
kutistua, numero kutistuu.

1953
01:26:11,870 --> 01:26:15,250
Ja jos kuormitus tulee takaisin,
se tulee kasvamaan takaisin ulos, elastisesti.

1954
01:26:15,250 --> 01:26:17,050
>> Joten tämä näyttää hyvältä.

1955
01:26:17,050 --> 01:26:19,800
Meillä on paljon EC2 tapauksissa.

1956
01:26:19,800 --> 01:26:21,671
Voimme laittaa välimuisti
edessä tietokantojen,

1957
01:26:21,671 --> 01:26:23,045
yrittää nopeuttaa tietokantoja.

1958
01:26:23,045 --> 01:26:25,030
Seuraava paine kohta
tyypillisesti ihmiset näkevät

1959
01:26:25,030 --> 01:26:28,850
on ne mittakaavassa peli käyttäen
relaatiotietokantajärjestelmään.

1960
01:26:28,850 --> 01:26:30,790
Jeez, tietokanta
suorituskyky on kauheaa.

1961
01:26:30,790 --> 01:26:31,932
Miten voimme parantaa sitä?

1962
01:26:31,932 --> 01:26:33,640
Yritetään laittaa
välimuisti edessä että.

1963
01:26:33,640 --> 01:26:36,780
>> No, välimuisti ei toimi
niin suuri peleissä, eikö?

1964
01:26:36,780 --> 01:26:39,330
Pelejä, kirjoittaminen on tuskallista.

1965
01:26:39,330 --> 01:26:40,930
Pelit ovat hyvin kirjoittaa raskas.

1966
01:26:40,930 --> 01:26:43,610
Välimuisti ei toimi, kun olet
kirjoittaa raskas koska olet aina

1967
01:26:43,610 --> 01:26:44,610
sai päivittää välimuistia.

1968
01:26:44,610 --> 01:26:47,780
Päivität välimuistin, se on
merkityksetön on välimuistiin.

1969
01:26:47,780 --> 01:26:49,780
Se on oikeastaan ​​vain lisätyötä.

1970
01:26:49,780 --> 01:26:51,970
>> Joten missä mennään täällä?

1971
01:26:51,970 --> 01:26:54,400
Sinulla iso pullonkaula
siellä tietokantaan.

1972
01:26:54,400 --> 01:26:57,661
Ja paikka mennä
ilmeisesti on osiointi.

1973
01:26:57,661 --> 01:26:59,410
Osiointi ei ole
helppo tehdä, kun olet

1974
01:26:59,410 --> 01:27:01,900
tekemisissä relaatiotietokantojen.

1975
01:27:01,900 --> 01:27:05,080
Relaatiotietokantojen, olet
vastuussa, tehokkaasti,

1976
01:27:05,080 --> 01:27:06,210
avainavaruus.

1977
01:27:06,210 --> 01:27:10,527
Sanot käyttäjien välillä ja M
täältä, välillä N ja Z sinne.

1978
01:27:10,527 --> 01:27:12,360
Ja olet kytkentä
koko hakemuksen.

1979
01:27:12,360 --> 01:27:15,000
Joten olet tekemisissä
Tämän osion tietolähde.

1980
01:27:15,000 --> 01:27:18,670
Sinulla on kaupallisen rajoitukset
jotka eivät kata osioita.

1981
01:27:18,670 --> 01:27:20,560
Sinulla kaikenlaisia
messiness että olet

1982
01:27:20,560 --> 01:27:23,040
käsitellään siellä yrittää
käsitellä skaalaus ulos

1983
01:27:23,040 --> 01:27:25,120
ja rakentaa suuremman infrastruktuuri.

1984
01:27:25,120 --> 01:27:27,284
Se on vain ole hauskaa.

1985
01:27:27,284 --> 01:27:30,930
>> Yleisö: Joten sinä tarkoitat, että
kasvava lähde pistettä nopeuttaa

1986
01:27:30,930 --> 01:27:31,430
prosessi?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: lisääminen?

1988
01:27:32,513 --> 01:27:33,520
Yleisö: Source pistettä.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Lähde pistettä?

1990
01:27:34,410 --> 01:27:37,500
Yleisö: Vuodesta tiedot,
jos tieto on peräisin?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: Ei.

1992
01:27:38,250 --> 01:27:41,820
Sanon lisääntyy
määrä osiot tietovaraston

1993
01:27:41,820 --> 01:27:44,060
parantaa suorituskykyä.

1994
01:27:44,060 --> 01:27:48,300
Joten mitä tapahtuu tässä käyttäjät
tulossa EC2 Esimerkiksi täällä,

1995
01:27:48,300 --> 01:27:50,780
hyvin, jos tarvitsen käyttäjä
joka on M, menen tänne.

1996
01:27:50,780 --> 01:27:53,560
N p, menen tänne.

1997
01:27:53,560 --> 01:27:55,060
P-Z, menen tänne.

1998
01:27:55,060 --> 01:27:57,120
>> Yleisö: OK, nämä niin ne ovat
kaikki tallennetut eri solmuissa?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Kyllä.

2000
01:27:57,911 --> 01:28:00,210
Ajattele näitä
eri siilot tietojen.

2001
01:28:00,210 --> 01:28:01,660
Joten sinulla on tehdä tämän.

2002
01:28:01,660 --> 01:28:02,910
Jos yrität tehdä
tämä, jos yrität

2003
01:28:02,910 --> 01:28:05,730
mittakaavassa on ihmissuhteisiin alustalla,
tämä on mitä olet tekemässä.

2004
01:28:05,730 --> 01:28:08,100
Otatte tiedot ja
olet leikkaamalla se alas.

2005
01:28:08,100 --> 01:28:10,975
Ja olet osiointi se poikki
useita esiintymiä tietokannasta.

2006
01:28:10,975 --> 01:28:13,580
Ja sinä hallitset kaikki,
klo sovellus tason.

2007
01:28:13,580 --> 01:28:14,729
Se ei ole hauskaa.

2008
01:28:14,729 --> 01:28:15,770
Mitä me haluamme mennä?

2009
01:28:15,770 --> 01:28:20,240
Haluamme mennä DynamoDB, täysin onnistunut,
NoSQL tietovaraston, säännös läpijuoksu.

2010
01:28:20,240 --> 01:28:22,680
Käytämme toissijainen indeksejä.

2011
01:28:22,680 --> 01:28:26,154
Se on pohjimmiltaan HTTP API ja
dokumenttien tuki.

2012
01:28:26,154 --> 01:28:28,570
Joten sinun ei tarvitse huolehtia
tuosta mitään eristämiseen.

2013
01:28:28,570 --> 01:28:30,740
Teemme kaiken puolestasi.

2014
01:28:30,740 --> 01:28:33,260
Joten nyt, sen sijaan, te
vain kirjoittaa pöytään.

2015
01:28:33,260 --> 01:28:36,490
Jos taulukko on osioitu,
että tapahtuu kulissien takana.

2016
01:28:36,490 --> 01:28:40,642
Olet täysin eristetty
kyseisestä kehittäjänä.

2017
01:28:40,642 --> 01:28:42,350
Joten puhua
joitakin käyttötapauksia

2018
01:28:42,350 --> 01:28:47,564
että me törmätä pelaamista, yhteinen
pelaamista skenaarioita, leaderboard.

2019
01:28:47,564 --> 01:28:49,980
Joten sinulla käyttäjiä tulossa,
BoardNames että he

2020
01:28:49,980 --> 01:28:52,930
on, tulokset tälle käyttäjälle.

2021
01:28:52,930 --> 01:28:57,700
Saatamme hajautusta päälle Käyttäjätunnus,
ja sitten meillä on valikoima peliin.

2022
01:28:57,700 --> 01:28:59,960
Joten jokainen käyttäjä haluaa nähdä
kaikki pelissä hän on pelannut

2023
01:28:59,960 --> 01:29:01,770
ja kaikki hänen huippupisteet
kaikissa peli.

2024
01:29:01,770 --> 01:29:04,000
Niin, että hänen henkilökohtainen leaderboard.

2025
01:29:04,000 --> 01:29:10,010
>> Nyt haluan mennä ja haluan get--
joten saan nämä henkilökohtaista pistetaulukot.

2026
01:29:10,010 --> 01:29:12,827
Mitä haluan tehdä on mennä saada
huippupisteet kaikkien käyttäjien.

2027
01:29:12,827 --> 01:29:13,660
Joten miten voin tehdä sen?

2028
01:29:13,660 --> 01:29:18,070
Kun minun ennätys on hajauttaa päälle
Käyttäjätunnus, vaihteli pelin,

2029
01:29:18,070 --> 01:29:20,740
hyvin aion mennä eteenpäin
ja uudelleen, luoda GSI,

2030
01:29:20,740 --> 01:29:22,370
ja aion uudelleen, että tiedot.

2031
01:29:22,370 --> 01:29:27,310
>> Nyt aion Hash
BoardName, joka on peli.

2032
01:29:27,310 --> 01:29:29,800
Ja aion Range huippupisteet.

2033
01:29:29,800 --> 01:29:31,540
Ja nyt olen luonut eri kauhat.

2034
01:29:31,540 --> 01:29:34,790
Käytän samassa pöydässä,
saman kohteen tiedot.

2035
01:29:34,790 --> 01:29:39,870
Mutta Olen luomassa ämpäri, joka antaa
minulle yhdistäminen alkuun pisteet peli.

2036
01:29:39,870 --> 01:29:43,180
>> Ja voin kyselyn että taulukon
saada nämä tiedot.

2037
01:29:43,180 --> 01:29:50,890
Joten olen asettanut että hakukaavan jopa
tuettava toissijainen indeksi.

2038
01:29:50,890 --> 01:29:54,556
Nyt he voivat järjestellä BoardName
ja lajiteltu Topscore riippuen.

2039
01:29:54,556 --> 01:29:57,180
Voit siis nähdä, nämä ovat tyypit
käyttötapauksia saat pelaamista.

2040
01:29:57,180 --> 01:30:02,190
Toinen hyvä käyttää tapauksessa saamme pelaamista
on palkintoja ja kuka voitti palkintoja.

2041
01:30:02,190 --> 01:30:05,340
Ja tämä on paljon hyötyä asiassa
jossa kutsumme harvaa indeksit.

2042
01:30:05,340 --> 01:30:07,340
Harva indeksit ovat
kyky tuottaa

2043
01:30:07,340 --> 01:30:10,850
indeksi, joka ei välttämättä
sisältävät jokainen erä pöydälle.

2044
01:30:10,850 --> 01:30:11,470
Ja miksi ei?

2045
01:30:11,470 --> 01:30:14,540
Koska ominaisuus, joka on on
indeksoitu ei löydy jokaisen kohteen.

2046
01:30:14,540 --> 01:30:16,460
>> Joten tässä nimenomaisessa
Käytä asia, sanon,

2047
01:30:16,460 --> 01:30:19,240
Tiedätkö mitä, aion
luoda määritteen nimeltä palkinnon.

2048
01:30:19,240 --> 01:30:22,970
Ja minä aion antaa jokaiselle käyttäjälle
että on palkinto, joka määrite.

2049
01:30:22,970 --> 01:30:25,950
Käyttäjät, joilla ei ole palkinnot ovat
aio olla, että ominaisuus.

2050
01:30:25,950 --> 01:30:27,800
Joten kun luon
indeksi, vain käyttäjät

2051
01:30:27,800 --> 01:30:28,960
jotka ovat menossa näyttämään
ylös indeksissä ovat

2052
01:30:28,960 --> 01:30:31,050
ne, jotka todella ovat voittaneet palkintoja.

2053
01:30:31,050 --> 01:30:34,440
Niin se on hyvä tapa pystyä
luoda suodatettu indeksit

2054
01:30:34,440 --> 01:30:40,580
ovat hyvin, hyvin valikoiva jotka eivät
on indeksoida koko pöydän.

2055
01:30:40,580 --> 01:30:43,050
>> Joten emme vähissä aikaa täällä.

2056
01:30:43,050 --> 01:30:49,190
Aion mennä eteenpäin ja ohita
ulos ja ohita tämä skenaario.

2057
01:30:49,190 --> 01:30:52,625
Puhua hieman about--

2058
01:30:52,625 --> 01:30:54,460
>> Yleisö: Voinko kysyä nopea kysymys?

2059
01:30:54,460 --> 01:30:56,722
Yksi on kirjoittaa raskas?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Mikä on?

2061
01:30:57,680 --> 01:30:58,596
Yleisö: Kirjoita raskas.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Kirjoita raskas.

2063
01:31:01,270 --> 01:31:03,460
Anna minun nähdä.

2064
01:31:03,460 --> 01:31:06,220
>> Yleisö: Vai että ei
jotain voit vain

2065
01:31:06,220 --> 01:31:08,809
ääni muutamassa sekunnissa?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Menemme
kautta äänestäminen skenaario.

2067
01:31:10,850 --> 01:31:11,670
Se ei ole niin paha.

2068
01:31:11,670 --> 01:31:14,580
Onko teillä muutaman minuutin?

2069
01:31:14,580 --> 01:31:15,860
OK.

2070
01:31:15,860 --> 01:31:17,890
>> Joten me puhumme äänestykseen.

2071
01:31:17,890 --> 01:31:20,250
Joten reaaliaikainen äänestyksen, meillä on
vaatimukset äänestää.

2072
01:31:20,250 --> 01:31:25,250
Vaatimukset ovat, että annamme
jokainen äänestää vain kerran.

2073
01:31:25,250 --> 01:31:28,060
Haluamme kukaan pystyä
muuttaa äänestää.

2074
01:31:28,060 --> 01:31:31,045
Haluamme reaaliaikainen yhdistäminen
ja Analytics väestötiedot

2075
01:31:31,045 --> 01:31:34,210
että aiomme olla
näytetään käyttäjille sivuston.

2076
01:31:34,210 --> 01:31:35,200
>> Ajattele tätä skenaariota.

2077
01:31:35,200 --> 01:31:37,550
Teemme paljon todellisuutta
TV-ohjelmia, jos ne ovat

2078
01:31:37,550 --> 01:31:38,960
teet näitä tarkka tyyppi asioita.

2079
01:31:38,960 --> 01:31:41,584
Joten voit ajatella skenaario,
meillä on miljoonia ja miljoonia

2080
01:31:41,584 --> 01:31:43,959
teinityttöjen siellä
niiden matkapuhelimet

2081
01:31:43,959 --> 01:31:46,250
ja äänestäminen ja äänestäminen, ja
Äänestän keitä he ovat

2082
01:31:46,250 --> 01:31:48,610
löytää olla suosituin.

2083
01:31:48,610 --> 01:31:50,830
Joten nämä ovat joitakin
vaatimusten me loppuu.

2084
01:31:50,830 --> 01:31:52,990
>> Ja niin ensin ottaa
ratkaisemaan tämän ongelman

2085
01:31:52,990 --> 01:31:55,090
olisi rakentaa
hyvin yksinkertainen sovellus.

2086
01:31:55,090 --> 01:31:56,490
Joten minulla on tämä app.

2087
01:31:56,490 --> 01:31:57,950
Minulla on joitakin äänestäjiä siellä.

2088
01:31:57,950 --> 01:31:59,980
Ne tulevat, ne osuvat äänestys sovelluksen.

2089
01:31:59,980 --> 01:32:03,440
Minulla joidenkin raaka ääntä taulukko
Otan vain dump nämä äänet osaksi.

2090
01:32:03,440 --> 01:32:05,780
Otan joitakin yhteenlaskettu
ääntä taulukko että

2091
01:32:05,780 --> 01:32:09,490
teen analytiikan ja väestötiedot,
ja me laitamme kaikki tämä siellä.

2092
01:32:09,490 --> 01:32:11,420
>> Ja tämä on suuri.

2093
01:32:11,420 --> 01:32:12,332
Elämä on hyvää.

2094
01:32:12,332 --> 01:32:15,040
Elämän hyvä kunnes saamme selville, että
siellä on aina vain yksi tai kaksi

2095
01:32:15,040 --> 01:32:16,879
ihmiset, jotka ovat suosittuja vaaleissa.

2096
01:32:16,879 --> 01:32:19,420
On vain yksi tai kaksi asiaa
että ihmiset oikeasti välitä.

2097
01:32:19,420 --> 01:32:22,340
Ja jos olet äänestyksestä
mittakaavassa, yhtäkkiä olen

2098
01:32:22,340 --> 01:32:26,360
aiotaan mäiske helvettiin
kaksi ehdokasta, yksi tai kaksi ehdokasta.

2099
01:32:26,360 --> 01:32:29,390
Hyvin rajoitettu määrä kohdetta
ihmiset löytävät olla suosittu.

2100
01:32:29,390 --> 01:32:31,710
>> Tämä ei ole hyvä suunnittelu malli.

2101
01:32:31,710 --> 01:32:33,549
Tämä on oikeastaan
erittäin huono suunnittelu malli

2102
01:32:33,549 --> 01:32:36,340
koska se luo mitä me
puhui joka oli pikanäppäimiä.

2103
01:32:36,340 --> 01:32:38,960
Pikanäppäimet ovat jotain, josta emme pidä.

2104
01:32:38,960 --> 01:32:40,470
>> Miten siis korjata sen?

2105
01:32:40,470 --> 01:32:47,640
Ja todella, tapa korjata tämä on
ottamalla ne ehdokas kauhat

2106
01:32:47,640 --> 01:32:51,490
ja jokaisen ehdokkaan meillä on,
aiomme liittää satunnainen arvo,

2107
01:32:51,490 --> 01:32:54,192
jotain, että me tiedämme, satunnainen
arvo välillä yksi ja 100,

2108
01:32:54,192 --> 01:32:56,620
välillä 100 ja 1000,
tai yhdestä 1000,

2109
01:32:56,620 --> 01:32:59,940
kuitenkin monet satunnainen arvoja haluat
liittää päälle päätteeksi, että ehdokas.

2110
01:32:59,940 --> 01:33:01,330
>> Ja mitä olen todella tehnyt niin?

2111
01:33:01,330 --> 01:33:05,830
Jos käytän ehdokastunnuksesi kuin
ämpäri yhteenlaskettu ääntä,

2112
01:33:05,830 --> 01:33:08,780
jos Olen lisännyt satunnainen
numero loppuun, että

2113
01:33:08,780 --> 01:33:12,000
Olen luonut nyt 10 kauhat,
sata kauhat, tuhat kauhat

2114
01:33:12,000 --> 01:33:14,160
että olen kokoamiseen ääntä poikki.

2115
01:33:14,160 --> 01:33:18,030
>> Olen siis miljoonia, ja miljoonat,
ja miljoonia levyjä tulossa

2116
01:33:18,030 --> 01:33:22,050
Näiden ehdokkaiden, olen nyt leviämässä
nämä äänet yli Candidate A_1

2117
01:33:22,050 --> 01:33:24,630
kautta Ehdokas A_100, koska
joka kerta ääni tulee,

2118
01:33:24,630 --> 01:33:26,530
Olen satunnaisjonon
arvo välillä yksi ja 100.

2119
01:33:26,530 --> 01:33:29,446
Olen tacking se kiinni loppuun
ehdokkaan kyseisen henkilön äänestää.

2120
01:33:29,446 --> 01:33:31,120
Olen polkumyyntiä sen, että ämpäri.

2121
01:33:31,120 --> 01:33:33,910
>> Nyt takana, tiedän
että sain sata kauhat.

2122
01:33:33,910 --> 01:33:36,350
Joten kun haluan mennä eteenpäin
ja yhdistää ääntä,

2123
01:33:36,350 --> 01:33:38,244
Olen lukenut kaikilta niiltä kauhat.

2124
01:33:38,244 --> 01:33:39,160
Joten menin eteenpäin ja lisätä.

2125
01:33:39,160 --> 01:33:42,410
Ja sitten en hajottaa kerätä
missä menen ulos ja sanoa hei,

2126
01:33:42,410 --> 01:33:45,399
Tiedätkö mitä, tämä ehdokkaan avain
tilat on yli sata kauhat.

2127
01:33:45,399 --> 01:33:47,940
Aion koota kaikki
ääntä kuin sata kauhat.

2128
01:33:47,940 --> 01:33:49,981
Aion yhdistää
niitä ja aion sanoa,

2129
01:33:49,981 --> 01:33:53,830
Ehdokas on nyt
yhteensä ääntenlaskun x.

2130
01:33:53,830 --> 01:33:55,690
>> Nyt molemmat Kirjoita
kysely ja luetun kysely

2131
01:33:55,690 --> 01:33:58,160
ovat kauniisti jaettu
koska Kirjoitan koko

2132
01:33:58,160 --> 01:34:00,320
ja luen sadoissa avaimia.

2133
01:34:00,320 --> 01:34:03,500
En ole kirjallisesti ja
käymällä läpi yksi keskeinen nyt.

2134
01:34:03,500 --> 01:34:04,950
Niin se on hyvä malli.

2135
01:34:04,950 --> 01:34:08,090
>> Tämä on itse asiassa todennäköisesti yksi
tärkeimmistä suunnittelu

2136
01:34:08,090 --> 01:34:10,420
kaavoja mittakaavassa NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Näet tämän tyyppisen
suunnittelumalli jokaisessa maku.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, se ei
asia, me kaikki täytyy tehdä tämä.

2139
01:34:19,100 --> 01:34:21,840
Koska kun olet tekemisissä
näitä valtavia koosteita,

2140
01:34:21,840 --> 01:34:26,650
sinun täytyy keksiä tapa
levittää niitä ulos koko kauhat.

2141
01:34:26,650 --> 01:34:29,512
Joten tämä on niin teet sen.

2142
01:34:29,512 --> 01:34:31,220
Selvä, niin mitä
teet juuri nyt

2143
01:34:31,220 --> 01:34:35,252
on olet kaupankäynnin pois Lue
kustannuksia kirjoittaa skaalautuvuutta.

2144
01:34:35,252 --> 01:34:37,085
Kustannukset minun lukea on
hieman monimutkaisempi

2145
01:34:37,085 --> 01:34:40,220
ja minun täytyy mennä lukea
sata kauhat yhden sijasta.

2146
01:34:40,220 --> 01:34:41,310
Mutta olen voinut kirjoittaa.

2147
01:34:41,310 --> 01:34:44,860
Ja minun suoritusteho, minun kirjoittaa
läpijuoksu on uskomaton.

2148
01:34:44,860 --> 01:34:49,450
Niin se on yleensä arvokas
tekniikka skaalaus DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
tai NoSQL tietokanta, että asiassa.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Joten me tajunnut, miten mittakaavassa se.

2152
01:34:55,240 --> 01:34:56,930
Ja me tajunnut, miten
eliminoida pikanäppäimet.

2153
01:34:56,930 --> 01:34:57,820
Ja tämä on fantastinen.

2154
01:34:57,820 --> 01:34:58,960
Ja saimme tämän mukava järjestelmä.

2155
01:34:58,960 --> 01:35:02,043
Ja se on antanut meille aivan oikea äänestäminen
koska meillä on ennätys äänestys de-huiputtaa.

2156
01:35:02,043 --> 01:35:03,130
Se on rakennettu DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Puhuimme ehdollinen oikeuksista.

2158
01:35:05,380 --> 01:35:08,170
>> Kun äänestäjä tulee, puts
Aseta pöydälle,

2159
01:35:08,170 --> 01:35:11,220
he lisätä niiden äänestäjien tunnus,
jos he yrittävät lisätä uutta äänestystä,

2160
01:35:11,220 --> 01:35:13,320
En ehdollinen kirjoittaa.

2161
01:35:13,320 --> 01:35:16,960
Sano vain kirjoittaa tämä
jos tämä ei ole olemassa.

2162
01:35:16,960 --> 01:35:19,270
Niin heti kun näen, että
että äänestys on osuma pöytä,

2163
01:35:19,270 --> 01:35:20,460
kukaan muu tulee olemaan
voi laittaa äänioikeuttaan.

2164
01:35:20,460 --> 01:35:21,634
Ja se on fantastinen.

2165
01:35:21,634 --> 01:35:23,550
Ja me monesko
meidän ehdokas laskurit.

2166
01:35:23,550 --> 01:35:25,466
Ja me teemme
väestötiedot ja kaikki.

2167
01:35:25,466 --> 01:35:29,110
Mutta mitä tapahtuu, jos
sovellus kaatuu?

2168
01:35:29,110 --> 01:35:31,350
Nyt yhtäkkiä ääniä
ovat tulossa, ja minä

2169
01:35:31,350 --> 01:35:34,840
tiedä jos he saavat jalostettu
minun analytiikan ja väestötiedot

2170
01:35:34,840 --> 01:35:36,040
enää.

2171
01:35:36,040 --> 01:35:38,462
Ja kun sovellus
tulee takaisin ylös, miten

2172
01:35:38,462 --> 01:35:41,420
helvetti tiedän mitä ääntä on
käsitelty ja missä voin aloittaa?

2173
01:35:41,420 --> 01:35:44,530
>> Joten tämä on todellinen ongelma, kun
alkaa tarkastella kuvaillut tapaukset.

2174
01:35:44,530 --> 01:35:45,571
Ja miten me ratkaista sen?

2175
01:35:45,571 --> 01:35:48,070
Ratkaisemme sen mitä me
soittaa DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Streams on aika tilata ja
osioitu muutos loki jokaisen pääsy

2177
01:35:53,470 --> 01:35:55,700
pöytään, joka kirjoittaa
pääsy taulukkoon.

2178
01:35:55,700 --> 01:35:58,810
Tietoja, jotka on kirjoitettu
taulukossa esitetään ylös virta.

2179
01:35:58,810 --> 01:36:01,815
>> Se on pohjimmiltaan 24 tunnin jono.

2180
01:36:01,815 --> 01:36:03,690
Kohdetta osuma virta,
he elävät 24 tuntia.

2181
01:36:03,690 --> 01:36:05,990
Ne voidaan lukea useita kertoja.

2182
01:36:05,990 --> 01:36:09,400
Taattu toimitetaan
vain kerran virta,

2183
01:36:09,400 --> 01:36:11,180
voidaan lukea n määrän kertoja.

2184
01:36:11,180 --> 01:36:14,910
Niin kuitenkin monet prosessit haluat
kuluttaa että tiedot, voit kuluttaa sitä.

2185
01:36:14,910 --> 01:36:16,350
Se näkyy jokaisen päivityksen.

2186
01:36:16,350 --> 01:36:18,455
Jokainen kirjoittamasi vain
näkyvät kerran virta.

2187
01:36:18,455 --> 01:36:20,621
Joten sinun ei tarvitse huolehtia
noin sen käsittelyn kahdesti

2188
01:36:20,621 --> 01:36:22,500
samasta prosessi.

2189
01:36:22,500 --> 01:36:25,350
>> Se on ehdottomasti tilata per tuote.

2190
01:36:25,350 --> 01:36:28,180
Kun sanomme aika
tilasi ja osioitu,

2191
01:36:28,180 --> 01:36:30,680
näet kohden osio virta.

2192
01:36:30,680 --> 01:36:33,169
Näet kohdat, päivitykset järjestyksessä.

2193
01:36:33,169 --> 01:36:35,210
Emme takaa
stream että olet

2194
01:36:35,210 --> 01:36:40,240
menossa jokainen tapahtuma
järjestyksessä poikki kohteita.

2195
01:36:40,240 --> 01:36:42,440
>> Joten purot ovat idempotentti.

2196
01:36:42,440 --> 01:36:44,037
Älä me kaikki tiedämme, mitä idempotentti tarkoittaa?

2197
01:36:44,037 --> 01:36:46,620
Idempotentti tarkoittaa, että voit tehdä sen
yli, ja yli, ja uudestaan.

2198
01:36:46,620 --> 01:36:48,200
Tulos tulee olemaan sama.

2199
01:36:48,200 --> 01:36:49,991
>> Purot ovat idempotentti,
mutta niiden on oltava

2200
01:36:49,991 --> 01:36:54,860
Päivämäärä lähtöpisteestä,
minne haluat, loppuun,

2201
01:36:54,860 --> 01:36:57,950
tai ne eivät aiheuta
samassa arvot.

2202
01:36:57,950 --> 01:36:59,727
>> Sama juttu MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB on konstrukti
he kutsuvat oplog.

2204
01:37:01,560 --> 01:37:04,140
Se on täsmälleen sama konstruktin.

2205
01:37:04,140 --> 01:37:06,500
Monet NoSQL tietokannat
on tämä rakenne.

2206
01:37:06,500 --> 01:37:08,790
He käyttävät sitä tehdä asioita
kuten replikointi, joka

2207
01:37:08,790 --> 01:37:10,475
Juuri teemme puroihin.

2208
01:37:10,475 --> 01:37:12,350
Yleisö: Ehkä
harhaoppisia kysymys, mutta te

2209
01:37:12,350 --> 01:37:13,975
puhua sovellukset tekevät alas niin edelleen.

2210
01:37:13,975 --> 01:37:16,089
Ovat purot taatusti
koskaan mahdollisesti mennä alas?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Joo, purot
ovat taatusti koskaan mennä alas.

2212
01:37:18,630 --> 01:37:21,040
Onnistumme infrastruktuuri
takana. virrat automaattisesti

2213
01:37:21,040 --> 01:37:22,498
käyttöön niiden automaattinen skaalaus ryhmä.

2214
01:37:22,498 --> 01:37:25,910
Menemme läpi hieman
vähän siitä, mitä tapahtuu.

2215
01:37:25,910 --> 01:37:30,060
>> Minun ei pitäisi sanoa ne eivät ole
taatusti koskaan mennä alas.

2216
01:37:30,060 --> 01:37:33,110
Elementit taataan
näkyvän virta.

2217
01:37:33,110 --> 01:37:36,740
Ja virta tulee saataville.

2218
01:37:36,740 --> 01:37:40,580
Joten mikä menee alas tai tulee takaisin
ylös, että tapahtuu alla.

2219
01:37:40,580 --> 01:37:43,844
Se covers-- se on OK.

2220
01:37:43,844 --> 01:37:46,260
Selvä, niin saat eri
näkymä tyypit pois ruudulta.

2221
01:37:46,260 --> 01:37:51,040
Näkymä tyypit, jotka ovat tärkeitä
ohjelmoija tyypillisesti ovat, mitä se oli?

2222
01:37:51,040 --> 01:37:52,370
Saan vanhan mieltä.

2223
01:37:52,370 --> 01:37:55,630
Kun päivitys osuu pöytään, se tulee
työnnä vanha näkymä stream

2224
01:37:55,630 --> 01:38:02,070
joten tiedot voidaan arkistoida, tai muutos
ohjaus, muutos tunnistaminen, muutos

2225
01:38:02,070 --> 01:38:03,600
hallinta.

2226
01:38:03,600 --> 01:38:07,160
>> Uusi kuva, mitä se on nyt jälkeen
päivitys, se on toinen tyyppi näkymä

2227
01:38:07,160 --> 01:38:07,660
voit saada.

2228
01:38:07,660 --> 01:38:09,660
Voit saada sekä vanhan ja uusia kuvia.

2229
01:38:09,660 --> 01:38:10,660
Ehkä haluan heidät molemmat.

2230
01:38:10,660 --> 01:38:11,790
Haluan nähdä, mitä se oli.

2231
01:38:11,790 --> 01:38:13,290
Haluan nähdä, mitä se muuttui.

2232
01:38:13,290 --> 01:38:15,340
>> Minulla noudattamista tyyppi
prosessin, joka toimii.

2233
01:38:15,340 --> 01:38:17,430
Sen on varmistaa, että
kun nämä asiat muuttuvat,

2234
01:38:17,430 --> 01:38:21,840
että he tietyissä rajoissa
tai tiettyjen parametrien.

2235
01:38:21,840 --> 01:38:23,840
>> Ja sitten ehkä minä vain
täytyy tietää, mitä muuttunut.

2236
01:38:23,840 --> 01:38:26,240
En välitä, mitä kohde muuttunut.

2237
01:38:26,240 --> 01:38:28,580
En tarvitse tarvitse tietää
mitä ominaisuuksia muuttuneen.

2238
01:38:28,580 --> 01:38:30,882
Haluan vain tietää, että
kohteet kosketetaan.

2239
01:38:30,882 --> 01:38:33,340
Joten nämä ovat eri näkemyksiä
että saat pois virta

2240
01:38:33,340 --> 01:38:35,960
ja voit olla vuorovaikutuksessa.

2241
01:38:35,960 --> 01:38:37,840
>> Sovellus
kuluttaa virta,

2242
01:38:37,840 --> 01:38:39,298
tämä on sellainen tapa, jolla tämä toimii.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB asiakas pyytää
työntää dataa taulukoihin.

2244
01:38:42,570 --> 01:38:44,750
Streams käyttöön mitä kutsumme sirpaleiksi.

2245
01:38:44,750 --> 01:38:47,380
Sirpaleiksi skaalataan
riippumatta taulukon.

2246
01:38:47,380 --> 01:38:50,660
Ne eivät ole kohdallaan täysin
seinäjakoon oman pöydän.

2247
01:38:50,660 --> 01:38:52,540
Ja syy miksi
koska ne riviin

2248
01:38:52,540 --> 01:38:55,430
kapasiteetin, nykyinen
kapasiteetti taulukon.

2249
01:38:55,430 --> 01:38:57,600
>> Ne käyttöön niiden
oma auto skaalaus ryhmä,

2250
01:38:57,600 --> 01:39:00,800
ja he alkavat venyttää riippuen
kuinka monta kirjoituksia on tulossa,

2251
01:39:00,800 --> 01:39:03,090
kuinka monta reads-- todella se kirjoittaa.

2252
01:39:03,090 --> 01:39:05,820
Ei ole reads-- mutta miten
monet kirjoituksia ovat tulossa.

2253
01:39:05,820 --> 01:39:08,200
>> Ja sitten takaisin
Lopulta meillä on mitä me

2254
01:39:08,200 --> 01:39:11,390
soittaa KCL, tai Kinesis Client Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis on virta tiedot
teknologiaan Amazon.

2256
01:39:19,190 --> 01:39:22,040
Ja purot on rakennettu, että.

2257
01:39:22,040 --> 01:39:25,670
>> Joten käytät KCL käytössä
sovelluksen lukea stream.

2258
01:39:25,670 --> 01:39:28,752
Kinesis Client Library todella
hallinnoi työntekijöiden sinulle.

2259
01:39:28,752 --> 01:39:30,460
Ja se tekee myös joitakin
mielenkiintoisia asioita.

2260
01:39:30,460 --> 01:39:35,630
Se luo joitakin taulukoita ylös
teidän DynamoDB tablespace

2261
01:39:35,630 --> 01:39:38,410
seurata, mitkä kohteet
on käsitelty.

2262
01:39:38,410 --> 01:39:41,190
Joten tällä tavalla, jos se putoaa takaisin, jos
se kaatuu ja tulee ja saa

2263
01:39:41,190 --> 01:39:45,570
nousi takaisin ylös, se voi määrittää, missä
oli se käsittelystä virta.

2264
01:39:45,570 --> 01:39:48,360
>> Se on erittäin tärkeää, kun
puhut replikointi.

2265
01:39:48,360 --> 01:39:50,350
Minun täytyy tietää, mitä
Aineisto on käsitelty

2266
01:39:50,350 --> 01:39:52,810
ja mitä tietoja on vielä käsiteltävä.

2267
01:39:52,810 --> 01:39:57,380
Joten KCL kirjasto virtojen
antaa sinulle paljon, että toiminnallisuus.

2268
01:39:57,380 --> 01:39:58,990
Se huolehtii kaikista taloudenhoito.

2269
01:39:58,990 --> 01:40:01,140
Se kestää työntekijä jokaiselle Shard.

2270
01:40:01,140 --> 01:40:04,620
Se luo hallinnollinen taulukko
jokaista sirpale, jokaiselle työntekijälle.

2271
01:40:04,620 --> 01:40:07,560
Ja kun näiden työntekijöiden tulipalo,
ne säilyttää nämä taulukot

2272
01:40:07,560 --> 01:40:10,510
niin tiedät tämä ennätys
luettiin ja käsitelty.

2273
01:40:10,510 --> 01:40:13,850
Ja sitten, että tavalla, jos prosessi
kuolee ja tulee takaisin verkossa,

2274
01:40:13,850 --> 01:40:17,940
se voi jatkaa siellä missä se lähti.

2275
01:40:17,940 --> 01:40:20,850
>> Joten käytämme tätä varten
rajat alue replikointi.

2276
01:40:20,850 --> 01:40:24,680
Paljon asiakkaita on tarve
siirtää tietoja tai osissa taulukot

2277
01:40:24,680 --> 01:40:25,920
ympäri eri alueille.

2278
01:40:25,920 --> 01:40:29,230
On yhdeksän aluetta
ympäri maailmaa.

2279
01:40:29,230 --> 01:40:32,100
Joten saattaa olla need-- I
voisi olla käyttäjien Aasiassa, käyttäjät

2280
01:40:32,100 --> 01:40:34,150
itärannikolla Yhdysvalloissa.

2281
01:40:34,150 --> 01:40:38,980
Niillä on eri tietoja,
on paikallisesti hajautettu.

2282
01:40:38,980 --> 01:40:42,510
Ja ehkä käyttäjän lentää
Aasia yli Yhdysvaltoihin,

2283
01:40:42,510 --> 01:40:45,020
ja haluan jäljitellä
hänen tietoja hänen kanssaan.

2284
01:40:45,020 --> 01:40:49,340
Joten kun hän saa ulos lentokoneesta, hänellä on
hyvä kokemus käyttää hänen mobiilisovelluksen.

2285
01:40:49,340 --> 01:40:52,360
>> Voit käyttää rajat alue
replikointi kirjasto tehdä tämän.

2286
01:40:52,360 --> 01:40:55,730
Periaatteessa meillä on
jos kaksi teknologiaa.

2287
01:40:55,730 --> 01:40:59,400
Yksi on konsoli sovellus voit
seisomaan oman EC2 oikeusasteessa.

2288
01:40:59,400 --> 01:41:01,240
Se toimii puhdas replikointi.

2289
01:41:01,240 --> 01:41:02,720
Ja sitten me annoimme teille kirjasto.

2290
01:41:02,720 --> 01:41:06,070
Kirjasto voit rakentaa
oman sovelluksen, jos

2291
01:41:06,070 --> 01:41:10,740
haluavat tehdä hulluja asioita, että data--
suodatin, jäljitellä vain osa sitä,

2292
01:41:10,740 --> 01:41:14,120
kiertää tietoja, siirtää sen
eri taulukossa, niin edelleen ja niin edelleen.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Niin, että sellainen mitä se näyttää.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams voi olla
käsitellään mitä kutsumme Lambda.

2296
01:41:23,690 --> 01:41:27,394
Mainitsimme hieman siitä tapahtumasta
ajettu sovellus arkkitehtuurit.

2297
01:41:27,394 --> 01:41:28,810
Lambda on keskeinen osa tätä.

2298
01:41:28,810 --> 01:41:32,840
Lambda on koodi, että tulipalot kysyntään
vastauksena tietyn tapahtuman.

2299
01:41:32,840 --> 01:41:36,020
Yksi näistä tapahtumista voisi olla
ennätys näkymisen virta.

2300
01:41:36,020 --> 01:41:39,100
Jos ennätys tulee virta,
me kutsumme tätä Java toiminto.

2301
01:41:39,100 --> 01:41:44,980
No, tämä on Javascript ja Lambda
tukee Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
ja pian tukea
muilla kielillä.

2303
01:41:47,820 --> 01:41:50,940
Ja riittää sanoa, se on puhdasta koodia.

2304
01:41:50,940 --> 01:41:53,610
kirjoittaa Javassa voit määrittää luokan.

2305
01:41:53,610 --> 01:41:55,690
Painat JAR ylös Lambda.

2306
01:41:55,690 --> 01:42:00,200
Ja sitten voit määrittää, mihin luokkaan
soittaa vastauksena missä tapauksessa.

2307
01:42:00,200 --> 01:42:04,770
Ja sitten Lambda infrastruktuuri
takana joka jatkuu että koodia.

2308
01:42:04,770 --> 01:42:06,730
>> Tämä koodi voi käsitellä
Records pois virta.

2309
01:42:06,730 --> 01:42:08,230
Se voi tehdä mitään, se haluaa sen kanssa.

2310
01:42:08,230 --> 01:42:11,650
Tässä nimenomaisessa esimerkissä, kaikki olemme
todella tekee kirjautuu ominaisuuksia.

2311
01:42:11,650 --> 01:42:13,480
Mutta tämä on vain koodi.

2312
01:42:13,480 --> 01:42:15,260
Koodi voi tehdä mitään, eikö?

2313
01:42:15,260 --> 01:42:16,600
>> Joten voit kääntää, että tiedot.

2314
01:42:16,600 --> 01:42:18,160
Voit luoda johdannainen näkymä.

2315
01:42:18,160 --> 01:42:21,160
Jos se on asiakirja rakenne,
voit litistää rakenne.

2316
01:42:21,160 --> 01:42:24,300
Voit luoda vaihtoehtoisia indeksejä.

2317
01:42:24,300 --> 01:42:27,100
Kaikenlaista voit
tehdä DynamoDB Streams.

2318
01:42:27,100 --> 01:42:28,780
>> Ja todella, että mitä se näyttää.

2319
01:42:28,780 --> 01:42:29,940
Joten saat päivitykset tulossa.

2320
01:42:29,940 --> 01:42:31,190
He tulevat pois merkkijono.

2321
01:42:31,190 --> 01:42:32,720
He lukea Lambda-toiminto.

2322
01:42:32,720 --> 01:42:37,480
He pyörivät tiedot ja
työntämällä sitä ylös johdannainen taulukoita,

2323
01:42:37,480 --> 01:42:42,200
Ilmoituksen ulkoisten järjestelmien muutoksen,
ja työntää dataa ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Puhuimme siitä, miten laittaa välimuisti
edessä tietokannan että myynti

2325
01:42:45,900 --> 01:42:46,450
skenaario.

2326
01:42:46,450 --> 01:42:50,049
No mitä tapahtuu, jos
päivittää kohteen kuvaus?

2327
01:42:50,049 --> 01:42:52,340
No, jos olisin Lambda
toiminto käynnissä että pöytä,

2328
01:42:52,340 --> 01:42:55,490
jos päivitän kohteen kuvaus, se tulee
poimia ennätys pois virta,

2329
01:42:55,490 --> 01:42:58,711
ja se tulee päivittää ElastiCache
Esimerkiksi uusilla tiedoilla.

2330
01:42:58,711 --> 01:43:00,460
Niin, että on paljon
mitä teemme Lambda.

2331
01:43:00,460 --> 01:43:02,619
Se on liima koodi, liittimet.

2332
01:43:02,619 --> 01:43:04,410
Ja se itse asiassa antaa
kyky käynnistää

2333
01:43:04,410 --> 01:43:07,930
ja ajaa erittäin monimutkaisia ​​sovelluksia
ilman oma palvelin

2334
01:43:07,930 --> 01:43:10,371
infrastruktuuri, joka on todella siistiä.

2335
01:43:10,371 --> 01:43:13,100
>> Joten mennään takaisin meidän
reaaliaikainen äänestyksen arkkitehtuuri.

2336
01:43:13,100 --> 01:43:17,984
Tämä on uusi ja parannettu kanssa
purojen ja KCL käytössä sovellus.

2337
01:43:17,984 --> 01:43:20,150
Sama kuin ennen, voimme
käsitellä mitä tahansa asteikolla vaaleissa.

2338
01:43:20,150 --> 01:43:21,100
Haluamme tätä.

2339
01:43:21,100 --> 01:43:24,770
Teemme ulos hajottaa kerää
useiden kauhat.

2340
01:43:24,770 --> 01:43:26,780
Meillä optimistinen lukitus tapahtuu.

2341
01:43:26,780 --> 01:43:30,192
Voimme pitää äänestäjät
muuttamasta niiden ääntä.

2342
01:43:30,192 --> 01:43:31,400
He voivat vain äänestää vain kerran.

2343
01:43:31,400 --> 01:43:32,880
Tämä on fantastinen.

2344
01:43:32,880 --> 01:43:35,895
Reaaliaikainen vikasietoisuus,
skaalautuva yhdistäminen nyt.

2345
01:43:35,895 --> 01:43:38,270
Jos asia kaatuu, se
tietää mistä käynnistää itsensä

2346
01:43:38,270 --> 01:43:41,300
kun se tulee takaisin ylös, koska
käytämme KCL sovelluksen.

2347
01:43:41,300 --> 01:43:45,700
Ja voimme myös käyttää sitä
KCL sovellus työntää dataa ulos

2348
01:43:45,700 --> 01:43:48,820
että punasiirtymä muita
app analytics, tai käyttö

2349
01:43:48,820 --> 01:43:51,990
Elastinen MapReduce ajaa
reaaliaikainen streaming aggregoinneista pois

2350
01:43:51,990 --> 01:43:53,180
näistä tiedoista.

2351
01:43:53,180 --> 01:43:55,480
>> Nämä ovat siis asioita
ole puhuneet paljon.

2352
01:43:55,480 --> 01:43:57,375
Mutta ne ovat täydentäviä
teknologioita, jotka tulevat

2353
01:43:57,375 --> 01:44:00,310
kantamaan kun etsit
klo tämäntyyppisiä skenaarioita.

2354
01:44:00,310 --> 01:44:03,160
>> Selvä, niin se on noin
Analyticsin ja DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
Voit kerätä de-huiputtaa
tietoja, tehdä kaikenlaisia

2356
01:44:05,340 --> 01:44:09,490
on kivaa, yhteenlaskettu tiedot
muisti, luoda nämä johdannainen taulukoita.

2357
01:44:09,490 --> 01:44:13,110
Se on valtava käyttötapaus
että paljon asiakkaita

2358
01:44:13,110 --> 01:44:16,950
ovat mukana, kun sisäkkäisiä
ominaisuudet, jotka JSON asiakirjojen

2359
01:44:16,950 --> 01:44:18,946
ja luoda uusia hakemistoja.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Olemme lopussa.

2362
01:44:23,150 --> 01:44:26,689
Kiitos laakerin kanssani.

2363
01:44:26,689 --> 01:44:28,480
Joten puhua
viittaus arkkitehtuuri.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB istuu keskellä niin
paljon AWS infrastruktuurin.

2365
01:44:33,440 --> 01:44:37,090
Periaatteessa voit liittää sen
jopa mitä haluat.

2366
01:44:37,090 --> 01:44:45,600
Sovellusten rakennettu Dynamo kuuluvat
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
työntää tiedot ulos Elastinen
MapReduce, tuonti vienti DynamoDB

2368
01:44:49,890 --> 01:44:52,370
osaksi S3, kaikenlaisia ​​työnkulkuja.

2369
01:44:52,370 --> 01:44:54,120
Mutta luultavasti paras
asia puhua,

2370
01:44:54,120 --> 01:44:56,119
ja tämä on mitä todella
kiinnostavaa on, kun me

2371
01:44:56,119 --> 01:44:58,350
puhua tapahtuma perustuvia sovelluksia.

2372
01:44:58,350 --> 01:45:00,300
>> Tämä on esimerkki
sisäinen projekti

2373
01:45:00,300 --> 01:45:04,850
että meillä on missä olemme todella
julkaisu kerätä kyselyn tuloksiin.

2374
01:45:04,850 --> 01:45:07,700
Joten sähköpostilinkkiä, että
lähetämme, siellä tulee

2375
01:45:07,700 --> 01:45:11,350
olla hieman linkki sanonta klikkauksella
täällä vastaamaan kyselyyn.

2376
01:45:11,350 --> 01:45:14,070
Ja kun henkilö napsauttaa
että linkki, mitä tapahtuu

2377
01:45:14,070 --> 01:45:18,020
on ne vetää alas turvallinen
HTML kyselykaavake S3.

2378
01:45:18,020 --> 01:45:18,980
Ei ole palvelinta.

2379
01:45:18,980 --> 01:45:20,600
Tämä on vain S3 objekti.

2380
01:45:20,600 --> 01:45:22,770
>> Tämä lomake tulee esiin,
lataa ylös selaimessa.

2381
01:45:22,770 --> 01:45:24,240
Se sai selkäranka.

2382
01:45:24,240 --> 01:45:30,160
Se sai monimutkainen JavaScript
että se on käynnissä.

2383
01:45:30,160 --> 01:45:33,557
Joten se on hyvin rikas sovellus
käynnissä asiakkaan selaimen.

2384
01:45:33,557 --> 01:45:36,390
He eivät tiedä, että he eivät
vuorovaikutuksessa takaisin end-palvelin.

2385
01:45:36,390 --> 01:45:38,220
Tässä vaiheessa, se on kaikki selaimen.

2386
01:45:38,220 --> 01:45:41,780
>> Ne julkaisevat tulokset mitä
kutsumme Amazonin API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway on yksinkertaisesti web API
että voit määrittää ja kytkeä

2388
01:45:46,270 --> 01:45:47,760
ja mitä haluat.

2389
01:45:47,760 --> 01:45:50,990
Tässä nimenomaisessa tapauksessa olemme
koukussa jopa Lambda toiminto.

2390
01:45:50,990 --> 01:45:54,797
>> Joten POST toiminta on
tapahtuu ilman palvelinta.

2391
01:45:54,797 --> 01:45:56,380
Pohjimmiltaan että API Gateway istuu siellä.

2392
01:45:56,380 --> 01:45:58,770
Se maksaa minulle mitään ennen ihmiset
alkaa julkaista sitä, eikö?

2393
01:45:58,770 --> 01:46:00,269
Lambda-toiminto vain istuu.

2394
01:46:00,269 --> 01:46:03,760
Ja se maksaa minulle mitään ennen
ihmiset alkavat lyömällä sitä.

2395
01:46:03,760 --> 01:46:07,270
Voit siis nähdä, koska äänenvoimakkuus
kasvaa, silloin maksut tulevat.

2396
01:46:07,270 --> 01:46:09,390
Minulla ei ole palvelinta 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Joten vedän muodossa
alas ämpäri,

2398
01:46:12,310 --> 01:46:15,719
ja olen lähettänyt API: n kautta
Portti Lambda-toiminto.

2399
01:46:15,719 --> 01:46:17,510
Ja sitten Lambda
toiminto sanoo, tiedät

2400
01:46:17,510 --> 01:46:20,600
mitä, minulla joitakin PIIs, jotkut
henkilökohtaisia ​​tietoja

2401
01:46:20,600 --> 01:46:21,480
näissä vastauksissa.

2402
01:46:21,480 --> 01:46:23,020
Sain kommentit tulevat käyttäjät.

2403
01:46:23,020 --> 01:46:24,230
Minulla sähköpostiosoitteita.

2404
01:46:24,230 --> 01:46:26,190
Minulla käyttäjätunnukset.

2405
01:46:26,190 --> 01:46:27,810
>> Saanen jakaa tämän pois.

2406
01:46:27,810 --> 01:46:30,280
Aion tuottaa noin
metatiedot pois tämä ennätys.

2407
01:46:30,280 --> 01:46:32,850
Ja aion työntää
metadatan DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Ja voisin salata kaikki tiedot
ja työnnä se DynamoDB jos haluan.

2409
01:46:36,059 --> 01:46:38,600
Mutta se on helpompaa minulle, tässä
Käytä asia, mennä eteenpäin sanoa,

2410
01:46:38,600 --> 01:46:42,800
Aion työntää raakadatan
osaksi salattu S3 ämpäri.

2411
01:46:42,800 --> 01:46:47,240
Joten käytän rakennettu S3 palvelimen puolella
salaus ja Amazonin Key Management

2412
01:46:47,240 --> 01:46:51,600
Palvelua niin, että minulla on avain,
voi pyöriä säännöllisin väliajoin,

2413
01:46:51,600 --> 01:46:55,010
ja voin suojata että PII tiedot
Osana tätä koko työnkulun.

2414
01:46:55,010 --> 01:46:55,870
>> Joten mitä minä olen tehnyt?

2415
01:46:55,870 --> 01:47:00,397
Olen juuri käyttöön koko
sovellus, ja minulla ei ole palvelinta.

2416
01:47:00,397 --> 01:47:02,980
Joten on mitä ylläpitäjä hakemus
arkkitehtuuri tekee sinulle.

2417
01:47:02,980 --> 01:47:05,730
>> Nyt jos ajattelee
käytön tapauksessa this--

2418
01:47:05,730 --> 01:47:08,730
meillä on muita asiakkaita puhun
noin juuri tämän arkkitehtuurin, joka

2419
01:47:08,730 --> 01:47:14,560
ajaa ilmiömäisen suuri kampanjoita, jotka
etsivät tätä ja menee, oh my.

2420
01:47:14,560 --> 01:47:17,840
Koska nyt, he voivat
pohjimmiltaan työnnä se siellä,

2421
01:47:17,840 --> 01:47:21,900
anna että kampanja vain istua
siellä kunnes se käynnistyy, eikä

2422
01:47:21,900 --> 01:47:24,400
tarvitse huolehtia viikuna noin
minkälainen infrastruktuuri

2423
01:47:24,400 --> 01:47:26,120
tulee olemaan siellä tukea sitä.

2424
01:47:26,120 --> 01:47:28,600
Ja sitten heti
että kampanja on tehty,

2425
01:47:28,600 --> 01:47:31,520
se on kuin infrastruktuuri
vain välittömästi menee pois

2426
01:47:31,520 --> 01:47:33,680
koska siellä todella
ole infrastruktuuria.

2427
01:47:33,680 --> 01:47:35,660
Se on vain koodi, joka istuu Lambda.

2428
01:47:35,660 --> 01:47:38,560
Se on vain tietoja, joka istuu DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Se on hämmästyttävä tapa
rakentaa sovelluksia.

2430
01:47:41,340 --> 01:47:43,970
>> Yleisö: Onko siis enemmän
hetkellistä kuin se olisi

2431
01:47:43,970 --> 01:47:45,740
jos se on tallennettu todellinen palvelin?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Ehdottomasti.

2433
01:47:46,823 --> 01:47:49,190
Koska että Server-esiintymä
pitäisi olla 7/24.

2434
01:47:49,190 --> 01:47:51,954
Sen täytyy olla käytettävissä
joku vastata.

2435
01:47:51,954 --> 01:47:52,620
No arvaa mitä?

2436
01:47:52,620 --> 01:47:55,410
S3 on käytettävissä 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 aina vastaa.

2438
01:47:57,100 --> 01:47:59,320
Ja S3 on erittäin, erittäin hyvä
klo palvelevat esineitä.

2439
01:47:59,320 --> 01:48:02,590
Nämä esineet voivat olla HTML-tiedostoja, tai
JavaScript-tiedostot, tai mitä haluat.

2440
01:48:02,590 --> 01:48:07,430
Voit ajaa hyvin rikas web-sovellusten
ulos S3 kauhat, ja ihmiset tekevät.

2441
01:48:07,430 --> 01:48:10,160
>> Ja niin se on ajatus täällä
on päästä pois tieltä

2442
01:48:10,160 --> 01:48:11,270
meillä oli tapana ajatella sitä.

2443
01:48:11,270 --> 01:48:14,270
Me kaikki tapana ajatella vuonna
ehdot palvelimia ja isäntien.

2444
01:48:14,270 --> 01:48:16,580
Kyse ei ole siitä enää.

2445
01:48:16,580 --> 01:48:19,310
Kyse infrastruktuuria koodi.

2446
01:48:19,310 --> 01:48:22,470
Käyttöön koodin pilvi ja
anna pilvi ajaa sen sinulle.

2447
01:48:22,470 --> 01:48:24,980
Ja se mitä AWS yrittää tehdä.

2448
01:48:24,980 --> 01:48:29,690
>> Yleisö: Joten kulta laatikko keskellä
API Gateway ei ole palvelin kaltainen,

2449
01:48:29,690 --> 01:48:30,576
mutta sen sijaan on just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Voit ajatella
IT palvelinten julkisivu.

2451
01:48:32,850 --> 01:48:38,040
Kaikki se on se otan HTTP
pyytää ja kartta sen toiseen prosessiin.

2452
01:48:38,040 --> 01:48:39,192
Siinä kaikki se tekee.

2453
01:48:39,192 --> 01:48:41,525
Ja tässä tapauksessa, olemme kartoitus
se Lambda toiminnon.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Hyvä, että on kaikki mitä minulla.

2456
01:48:45,410 --> 01:48:46,190
Kiitos paljon.

2457
01:48:46,190 --> 01:48:46,800
Minä arvostan sitä.

2458
01:48:46,800 --> 01:48:48,100
Tiedän haluamme hieman ajan mittaan.

2459
01:48:48,100 --> 01:48:49,980
Ja toivottavasti te saanut
hieman tietoa

2460
01:48:49,980 --> 01:48:51,410
että voit ottaa pois tänään.

2461
01:48:51,410 --> 01:48:53,520
Ja pyydän anteeksi, jos menin
yli joitakin päänne,

2462
01:48:53,520 --> 01:48:56,697
mutta siellä on hyvä paljon
perusoikeuksien perustava tieto

2463
01:48:56,697 --> 01:48:58,280
mielestäni on erittäin arvokas sinulle.

2464
01:48:58,280 --> 01:48:59,825
Joten kiitos siitä minulle.

2465
01:48:59,825 --> 01:49:00,325
[SUOSIONOSOITUKSET]

2466
01:49:00,325 --> 01:49:02,619
Yleisö: [äänetön]
on kun sanoitte

2467
01:49:02,619 --> 01:49:05,160
sinun piti mennä läpi asia
alusta loppuun

2468
01:49:05,160 --> 01:49:07,619
saada oikeita arvoja
tai samat arvot,

2469
01:49:07,619 --> 01:49:09,410
miten olisi arvot
muuttua, jos [kuultavissa].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Ai, idempotentti?

2471
01:49:10,480 --> 01:49:11,800
Miten arvot muuttuvat?

2472
01:49:11,800 --> 01:49:15,180
No, koska jos en suorita
se aina loppuun,

2473
01:49:15,180 --> 01:49:19,770
sitten en tiedä, mitä muutoksia
tehtiin viimeisen mailin.

2474
01:49:19,770 --> 01:49:22,144
Se ei tule olemaan
samat tiedot kuin mitä olen nähnyt.

2475
01:49:22,144 --> 01:49:24,560
Yleisö: Voi, niin sinä vain
ole saanut koko panos.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Oikea.

2477
01:49:24,770 --> 01:49:26,895
Sinun täytyy mennä alusta
loppuun, ja sitten se on

2478
01:49:26,895 --> 01:49:29,280
olemaan johdonmukainen valtio.

2479
01:49:29,280 --> 01:49:31,520
Viileä.

2480
01:49:31,520 --> 01:49:35,907
>> Yleisö: Joten näytti meille DynamoDB
voi tehdä asiakirjan tai keskeinen arvo.

2481
01:49:35,907 --> 01:49:38,740
Ja vietimme paljon aikaa
avain arvo hash ja tapoja

2482
01:49:38,740 --> 01:49:40,005
käännä se ympäri.

2483
01:49:40,005 --> 01:49:43,255
Kun katsoin noita pöytiä, että
jättäen jälkeensä asiakirjan lähestymistapa?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: en halua
sanoa jättää taakse.

2485
01:49:44,600 --> 01:49:45,855
>> Yleisö: He erotettiin the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Kun asiakirja
lähestymistapa, asiakirja kirjoita DynamoDB

2487
01:49:49,140 --> 01:49:50,880
on ajatelkaa kuin toinen määrite.

2488
01:49:50,880 --> 01:49:53,560
Se on ominaisuus, joka sisältää
hierarkkinen tietorakenne.

2489
01:49:53,560 --> 01:49:56,980
Ja sitten kyselyt,
voit käyttää ominaisuuksia

2490
01:49:56,980 --> 01:49:59,480
Näiden esineiden Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Voin siis suodattaa sisäkkäisiä
omaisuutta JSON asiakirjan.

2492
01:50:03,562 --> 01:50:05,520
Yleisö: Joten tahansa I
do asiakirja lähestymistapa,

2493
01:50:05,520 --> 01:50:07,906
Voin tavallaan saapua tabular--

2494
01:50:07,906 --> 01:50:08,780
Yleisö: Ehdottomasti.

2495
01:50:08,780 --> 01:50:09,800
Yleisö: --indexes ja
asiat juuri puhui.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Joo,
indeksit ja kaikki,

2497
01:50:11,280 --> 01:50:13,363
kun haluat indeksoida
ominaisuudet JSON,

2498
01:50:13,363 --> 01:50:18,230
siten, että meillä olisi tehdä se on jos
lisäät JSON esine tai asiakirja

2499
01:50:18,230 --> 01:50:20,780
osaksi Dynamo, voit käyttää puroihin.

2500
01:50:20,780 --> 01:50:22,400
Virrat lukisi panos.

2501
01:50:22,400 --> 01:50:24,340
Voit saada että JSON
objekti ja sanoisit OK,

2502
01:50:24,340 --> 01:50:26,030
mitä omaisuus haluan indeksi?

2503
01:50:26,030 --> 01:50:28,717
>> Luot johdannainen pöytä.

2504
01:50:28,717 --> 01:50:30,300
Nyt se on, miten se toimii nyt.

2505
01:50:30,300 --> 01:50:32,650
Emme salli indeksoida
suoraan nämä ominaisuudet.

2506
01:50:32,650 --> 01:50:33,520
>> Yleisö: Tabularizing dokumentteja.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Aivan, madaltuminen
se, tabularizing se, tarkalleen.

2508
01:50:36,230 --> 01:50:37,415
Se mitä sinä tekisit.

2509
01:50:37,415 --> 01:50:37,860
>> Yleisö: Kiitos.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Jep,
ehdottomasti, kiitos.

2511
01:50:39,609 --> 01:50:42,240
Yleisö: Joten se on eräänlainen
Mongo täyttää Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Joo,
se on paljon sellaista.

2513
01:50:43,990 --> 01:50:45,940
Se on hyvä kuvaus siitä.

2514
01:50:45,940 --> 01:50:47,490
Viileä.

2515
01:50:47,490 --> 01:50:49,102