1
00:00:00,000 --> 00:00:04,969
>> [RIPRODUZIONE DI BRANI MUSICALI]

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

3
00:00:06,010 --> 00:00:06,600
Salve a tutti.

4
00:00:06,600 --> 00:00:07,670
Il mio nome è Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Io sono un anziano preside
Le soluzioni architetto AWS.

6
00:00:10,330 --> 00:00:14,070
Mi concentro su NoSQL e
Tecnologie DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Sono qui oggi per parlare
un po 'di quelle.

8
00:00:16,930 --> 00:00:18,970
>> Il mio background è
principalmente nello strato di dati.

9
00:00:18,970 --> 00:00:21,390
Ho passato metà della mia sviluppo
carriera scrivendo dati,

10
00:00:21,390 --> 00:00:25,930
accesso ai dati, soluzioni
per varie applicazioni.

11
00:00:25,930 --> 00:00:30,000
Sono stato nella virtualizzazione Nube
per circa 20 anni.

12
00:00:30,000 --> 00:00:33,460
Quindi, prima che il Cloud era il Cloud,
abbiamo usato per chiamare l'utility computing.

13
00:00:33,460 --> 00:00:37,170
E l'idea è stata, è come
PG & E, si paga per ciò che si utilizza.

14
00:00:37,170 --> 00:00:38,800
Oggi la chiamiamo la nuvola.

15
00:00:38,800 --> 00:00:41,239
>> Ma nel corso degli anni, ho lavorato
per un paio di aziende

16
00:00:41,239 --> 00:00:42,530
probabilmente non avete mai sentito parlare.

17
00:00:42,530 --> 00:00:47,470
Ma ho compilato una lista di tecnica
realizzazioni, credo che ci si dice.

18
00:00:47,470 --> 00:00:51,620
Ho otto brevetti in sistemi cloud
virtualizzazione, progettazione di microprocessori,

19
00:00:51,620 --> 00:00:54,440
elaborazione di eventi complessi,
e altre aree.

20
00:00:54,440 --> 00:00:58,290
>> Così in questi giorni, mi concentro soprattutto su NoSQL
tecnologie e la prossima generazione

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

22
00:00:59,450 --> 00:01:03,370
E questo è in genere quello che ho intenzione
di essere qui a parlare con voi oggi circa.

23
00:01:03,370 --> 00:01:06,030
Allora, cosa ci si può aspettare
da questa sessione,

24
00:01:06,030 --> 00:01:08,254
andremo attraverso una breve
Storia di elaborazione dei dati.

25
00:01:08,254 --> 00:01:10,420
E 'sempre utile
capire da dove veniamo

26
00:01:10,420 --> 00:01:12,400
e perché siamo dove siamo.

27
00:01:12,400 --> 00:01:15,600
E parleremo un po '
po 'di tecnologia NoSQL

28
00:01:15,600 --> 00:01:17,500
dal punto di vista fondamentale.

29
00:01:17,500 --> 00:01:19,870
>> Ci metteremo in alcuni dei
l'interno DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB c'è sapore di AWS.

31
00:01:24,350 --> 00:01:27,340
E 'completamente gestito e
soluzione NoSQL hosted.

32
00:01:27,340 --> 00:01:32,420
E parleremo un po 'di tavola
struttura, API, tipi di dati, indici,

33
00:01:32,420 --> 00:01:35,177
e alcune funzioni interne
di tale tecnologia DynamoDB.

34
00:01:35,177 --> 00:01:37,760
Arriveremo in alcuni dei design
modelli e best practice.

35
00:01:37,760 --> 00:01:39,968
Parleremo di come si
utilizzare questa tecnologia per qualche

36
00:01:39,968 --> 00:01:41,430
di applicazioni di oggi.

37
00:01:41,430 --> 00:01:44,820
E poi parleremo un po '
circa l'evoluzione o la comparsa

38
00:01:44,820 --> 00:01:48,980
di un nuovo paradigma di programmazione
chiamati applicazioni event-driven

39
00:01:48,980 --> 00:01:51,580
e come DynamoDB suona in quello.

40
00:01:51,580 --> 00:01:54,690
E vi lasciamo un po 'di
una architettura di riferimento discussione

41
00:01:54,690 --> 00:01:59,540
così possiamo parlare di alcuni dei
i modi è possibile utilizzare DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Quindi, prima off-- questa è una domanda
Ho sentito un sacco è, che cosa è un database.

43
00:02:04,116 --> 00:02:06,240
Un sacco di gente pensa che
sanno cosa sia un database.

44
00:02:06,240 --> 00:02:08,360
Se Google, vedrai questo.

45
00:02:08,360 --> 00:02:11,675
Si tratta di un un insieme strutturato di dati trattati
in un computer, in particolare uno che

46
00:02:11,675 --> 00:02:13,600
è accessibile in vari modi.

47
00:02:13,600 --> 00:02:16,992
Suppongo che sia una buona
definizione di un moderno database.

48
00:02:16,992 --> 00:02:19,450
Ma non mi piace, perché
implica un paio di cose.

49
00:02:19,450 --> 00:02:20,935
Implica struttura.

50
00:02:20,935 --> 00:02:23,120
E ciò implica che è su un computer.

51
00:02:23,120 --> 00:02:25,750
E i database non hanno
esistono sempre sui computer.

52
00:02:25,750 --> 00:02:28,020
Basi di dati realmente esistito in molti modi.

53
00:02:28,020 --> 00:02:32,000
>> Quindi una migliore definizione di un
database è qualcosa di simile.

54
00:02:32,000 --> 00:02:34,786
Un database è un organizzato
meccanismo di archiviazione, la gestione,

55
00:02:34,786 --> 00:02:35,910
e il recupero di informazioni.

56
00:02:35,910 --> 00:02:36,868
Questo è da About.com.

57
00:02:36,868 --> 00:02:42,080
Così mi piace questo perché in realtà i colloqui
su un database di essere un repository,

58
00:02:42,080 --> 00:02:44,800
un repository di
informazioni, non necessariamente

59
00:02:44,800 --> 00:02:46,780
qualcosa che si trova su un computer.

60
00:02:46,780 --> 00:02:49,290
E nel corso della storia, abbiamo
non hanno sempre avuto i computer.

61
00:02:49,290 --> 00:02:52,110
>> Ora, se io chiedo la media
sviluppatore oggi ciò che è

62
00:02:52,110 --> 00:02:54,770
un database, che è la risposta che ottengo.

63
00:02:54,770 --> 00:02:56,070
Da qualche parte posso attaccare roba.

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

65
00:02:56,670 --> 00:02:58,725
Ed è vero.

66
00:02:58,725 --> 00:02:59,600
Ma è un peccato.

67
00:02:59,600 --> 00:03:02,700
Poiché il database è davvero
la fondazione delle app moderno.

68
00:03:02,700 --> 00:03:04,810
E 'il fondamento
di ogni applicazione.

69
00:03:04,810 --> 00:03:07,240
E come si costruisce che
banca dati, come si struttura

70
00:03:07,240 --> 00:03:11,750
che i dati sta per dettare come questo
applicazione esegue come si scala.

71
00:03:11,750 --> 00:03:14,640
>> Così un sacco del mio lavoro oggi
si occupa di ciò che

72
00:03:14,640 --> 00:03:17,180
accade quando gli sviluppatori
adottare questo approccio

73
00:03:17,180 --> 00:03:19,510
e la gestione delle conseguenze
di un'applicazione

74
00:03:19,510 --> 00:03:24,966
è ora scalare oltre l'originale
intento e la sofferenza dalla cattiva progettazione.

75
00:03:24,966 --> 00:03:26,840
Così si spera quando si
a piedi oggi, ti

76
00:03:26,840 --> 00:03:29,010
un paio di strumenti in
la cintura che ti terrà

77
00:03:29,010 --> 00:03:32,566
dal fare quegli stessi errori.

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

79
00:03:33,066 --> 00:03:36,360
Quindi parliamo di un po 'di
la timeline di tecnologia di database.

80
00:03:36,360 --> 00:03:38,830
Penso che ho letto un
articolo non molto tempo fa

81
00:03:38,830 --> 00:03:43,020
e ha detto qualcosa sul lines--
si tratta di una dichiarazione molto poetico.

82
00:03:43,020 --> 00:03:46,590
Ha detto che la storia
del trattamento dei dati è

83
00:03:46,590 --> 00:03:49,350
pieno di alte filigrane
di abbondanza di dati.

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

85
00:03:49,920 --> 00:03:52,532
Ora, credo che una specie di vero.

86
00:03:52,532 --> 00:03:54,990
Ma io in realtà guardare è come
la storia è in realtà piena

87
00:03:54,990 --> 00:03:56,820
con high watermark di pressione dati.

88
00:03:56,820 --> 00:04:00,040
Perché la velocità di trasmissione dati di
ingestione non va giù.

89
00:04:00,040 --> 00:04:01,360
Si arriva solo fino.

90
00:04:01,360 --> 00:04:03,670
>> E l'innovazione si verifica quando
vediamo pressione dati, che

91
00:04:03,670 --> 00:04:07,825
è la quantità di dati che è
Ora venendo al sistema.

92
00:04:07,825 --> 00:04:12,027
E non può essere elaborato
efficiente nel tempo o di costo.

93
00:04:12,027 --> 00:04:14,110
Ed è allora che cominciamo
guardare pressione dati.

94
00:04:14,110 --> 00:04:15,920
>> Così, quando guardiamo il
primo database, questo

95
00:04:15,920 --> 00:04:17,180
è quello che è stato tra le nostre orecchie.

96
00:04:17,180 --> 00:04:18,310
Siamo tutti nati con esso.

97
00:04:18,310 --> 00:04:19,194
E 'un bel database.

98
00:04:19,194 --> 00:04:21,110
Ha una elevata disponibilità.

99
00:04:21,110 --> 00:04:21,959
E 'sempre su.

100
00:04:21,959 --> 00:04:23,930
È sempre possibile ottenerlo.

101
00:04:23,930 --> 00:04:24,890
>> Ma è solo utente.

102
00:04:24,890 --> 00:04:26,348
Non posso condividere i miei pensieri con voi.

103
00:04:26,348 --> 00:04:28,370
Non è possibile ottenere i miei pensieri
quando vuoi.

104
00:04:28,370 --> 00:04:30,320
E la loro abilitiy non è così buono.

105
00:04:30,320 --> 00:04:32,510
Ci dimentichiamo le cose.

106
00:04:32,510 --> 00:04:36,540
Ogni tanto, uno di noi foglie
e si sposta verso un'altra esistenza

107
00:04:36,540 --> 00:04:39,110
e perdiamo tutto
che era in quel database.

108
00:04:39,110 --> 00:04:40,640
In modo che non è affatto buono.

109
00:04:40,640 --> 00:04:43,189
>> E questo ha funzionato bene nel corso del tempo
quando siamo tornati nel corso della giornata

110
00:04:43,189 --> 00:04:46,230
quando tutti abbiamo veramente bisogno di sapere è
dove stiamo andando ad andare domani

111
00:04:46,230 --> 00:04:49,630
o dove ci riuniamo il cibo migliore.

112
00:04:49,630 --> 00:04:52,820
Ma, come abbiamo cominciato a crescere come
la civiltà e il governo ha iniziato

113
00:04:52,820 --> 00:04:55,152
a venire in essere, e
le aziende hanno cominciato a evolversi,

114
00:04:55,152 --> 00:04:57,360
abbiamo iniziato a capire che
necessario un po 'più di quello

115
00:04:57,360 --> 00:04:58,210
abbiamo potuto mettere nella nostra testa.

116
00:04:58,210 --> 00:04:58,870
Tutto ok?

117
00:04:58,870 --> 00:05:00,410
>> Avevamo bisogno di sistemi di registrazione.

118
00:05:00,410 --> 00:05:02,220
Avevamo bisogno di essere posti in grado memorizzare i dati.

119
00:05:02,220 --> 00:05:05,450
Così abbiamo iniziato la scrittura di documenti,
la creazione di biblioteche e archivi.

120
00:05:05,450 --> 00:05:08,000
Abbiamo iniziato lo sviluppo di un
sistema una contabilità libro mastro.

121
00:05:08,000 --> 00:05:12,200
E quel sistema di conteggio contabilità
correva il mondo per molti secoli,

122
00:05:12,200 --> 00:05:15,580
e forse anche millenni come
abbiamo tipo cresciuti al punto

123
00:05:15,580 --> 00:05:18,420
dove il carico di dati ha superato
la capacità di tali sistemi

124
00:05:18,420 --> 00:05:19,870
essere in grado di contenere.

125
00:05:19,870 --> 00:05:22,070
>> E questo è realmente accaduto nel 1880.

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

127
00:05:22,570 --> 00:05:24,390
Nel Censimenti 1880.

128
00:05:24,390 --> 00:05:26,976
Questo è davvero in cui la svolta
puntare trattamento moderno.

129
00:05:26,976 --> 00:05:28,850
Questo è il punto in
che la quantità di dati

130
00:05:28,850 --> 00:05:32,060
che veniva riscossa dalle
Governo degli Stati Uniti ha ottenuto al punto

131
00:05:32,060 --> 00:05:34,005
dove ci sono voluti otto anni per elaborare.

132
00:05:34,005 --> 00:05:36,350
>> Ora, otto anni-- come
si sa, il censimento

133
00:05:36,350 --> 00:05:39,180
corse ogni 10 anni-- quindi è
abbastanza evidente che da tempo siamo

134
00:05:39,180 --> 00:05:41,419
ottenuto il censimento 1890,
la quantità di dati che

135
00:05:41,419 --> 00:05:43,210
stava per essere elaborati
da parte del governo è stato

136
00:05:43,210 --> 00:05:46,335
andando a superare i 10 anni che
avrebbe portato al lancio del nuovo censimento.

137
00:05:46,335 --> 00:05:47,250
Questo è stato un problema.

138
00:05:47,250 --> 00:05:49,000
>> Così un ragazzo di nome Herman
Hollerith è arrivato

139
00:05:49,000 --> 00:05:52,640
e ha inventato unità disco pugno
carte, lettore di schede perforate, schede perforate

140
00:05:52,640 --> 00:05:58,420
tabulatore, e le regole di confronto
i meccanismi di questa tecnologia.

141
00:05:58,420 --> 00:06:01,860
E quella società che ha formato alla
tempo, insieme con un paio di altri,

142
00:06:01,860 --> 00:06:05,450
in realtà è diventato uno dei pilastri di una
piccola azienda che conosciamo oggi chiamato IBM.

143
00:06:05,450 --> 00:06:08,417
>> Così IBM originariamente era in
il database aziendale.

144
00:06:08,417 --> 00:06:09,750
E questo è davvero quello che hanno fatto.

145
00:06:09,750 --> 00:06:11,110
Hanno fatto l'elaborazione dei dati.

146
00:06:11,110 --> 00:06:15,400
>> Come così la proliferazione di punch
carte, un ingegnoso meccanismi

147
00:06:15,400 --> 00:06:18,560
di essere in grado di sfruttare tale
la tecnologia per il polling set di risultati ordinati.

148
00:06:18,560 --> 00:06:20,726
Si può vedere in questa foto
ci abbiamo un little--

149
00:06:20,726 --> 00:06:23,970
è un po 'small-- ma si può vedere
un meccanismo meccanico molto ingegnoso

150
00:06:23,970 --> 00:06:26,970
dove abbiamo un mazzo di carte pugno.

151
00:06:26,970 --> 00:06:28,720
E presa di qualcuno
un piccolo cacciavite

152
00:06:28,720 --> 00:06:31,400
e attaccare attraverso il
slot e sollevandola

153
00:06:31,400 --> 00:06:34,820
per ottenere quella partita, che
impostati risultati ordinati.

154
00:06:34,820 --> 00:06:36,270
>> Questo è un aggregato.

155
00:06:36,270 --> 00:06:38,690
Facciamo questo per tutto il tempo
oggi nel computer,

156
00:06:38,690 --> 00:06:40,100
dove lo si fa nel database.

157
00:06:40,100 --> 00:06:41,620
Abbiamo usato per farlo manualmente, giusto?

158
00:06:41,620 --> 00:06:42,994
Persone mettere insieme queste cose.

159
00:06:42,994 --> 00:06:45,440
E fu la proliferazione
di queste schede perforate

160
00:06:45,440 --> 00:06:50,070
in quello che abbiamo chiamato tamburi dati
e bobine di dati, nastro di carta.

161
00:06:50,070 --> 00:06:55,980
>> L'industria di trasformazione dei dati ha preso
una lezione dai pianole.

162
00:06:55,980 --> 00:06:57,855
Giocatore pianoforti indietro
la fine del secolo

163
00:06:57,855 --> 00:07:02,100
utilizzato per utilizzare bobine di carta con slot
a dire che i tasti da suonare.

164
00:07:02,100 --> 00:07:05,380
In modo che la tecnologia è stata adattata
eventualmente per memorizzare dati digitali,

165
00:07:05,380 --> 00:07:08,070
perché potrebbero mettere tali dati
su quelle bobine di nastro di carta.

166
00:07:08,070 --> 00:07:10,870
>> Ora, come risultato, i dati
è stato come actually--

167
00:07:10,870 --> 00:07:14,960
Accedendo a questo dati sono stati direttamente
dipende da come l'avete memorizzato.

168
00:07:14,960 --> 00:07:17,825
Quindi, se ho messo i dati su un nastro,
Ho avuto accedere ai dati in modo lineare.

169
00:07:17,825 --> 00:07:20,475
Ho avuto a rotolare tutto
nastro per accedere a tutti i dati.

170
00:07:20,475 --> 00:07:22,600
Se metto i dati in pugno
carte, ho potuto accedervi

171
00:07:22,600 --> 00:07:26,270
in poco più casuale
moda, forse non così velocemente.

172
00:07:26,270 --> 00:07:30,770
>> Ma c'erano limiti nel modo in cui
l'accesso ai dati in base a come è stato immagazzinato.

173
00:07:30,770 --> 00:07:32,890
E quindi questo è stato un problema
entrare nei anni '50.

174
00:07:32,890 --> 00:07:37,890
Ancora una volta, possiamo iniziare a vedere che come noi
sviluppare nuove tecnologie per elaborare

175
00:07:37,890 --> 00:07:41,670
i dati, a destra, si apre
la porta a nuove soluzioni,

176
00:07:41,670 --> 00:07:45,852
per i nuovi programmi, nuovi
domande di tali dati.

177
00:07:45,852 --> 00:07:47,810
E davvero, la governance
potrebbe essere stato il motivo

178
00:07:47,810 --> 00:07:49,435
perché abbiamo sviluppato alcuni di questi sistemi.

179
00:07:49,435 --> 00:07:52,290
Ma gli affari è diventato rapidamente
il driver dietro l'evoluzione

180
00:07:52,290 --> 00:07:54,720
del database e moderna
il file system moderno.

181
00:07:54,720 --> 00:07:56,870
>> Così la prossima cosa che
si avvicinò era negli anni '50

182
00:07:56,870 --> 00:08:00,780
è il file system e la
sviluppo di memoria ad accesso casuale.

183
00:08:00,780 --> 00:08:02,050
Questo è stato bello.

184
00:08:02,050 --> 00:08:06,230
Ora, all'improvviso, possiamo mettere la nostra
file ovunque su questi hard disk

185
00:08:06,230 --> 00:08:09,760
e siamo in grado di accedere a questi dati in modo casuale.

186
00:08:09,760 --> 00:08:11,950
Possiamo analizzare che
informazioni dai file.

187
00:08:11,950 --> 00:08:14,920
E abbiamo risolto tutto il mondo
problemi con l'elaborazione dei dati.

188
00:08:14,920 --> 00:08:17,550
>> E che è durato circa 20 o
30 anni fino alla evoluzione

189
00:08:17,550 --> 00:08:22,100
del database relazionale, che
è quando il mondo ha deciso che ora

190
00:08:22,100 --> 00:08:27,940
bisogno di avere un repository che sconfigge
la distesa di dati attraverso file

191
00:08:27,940 --> 00:08:29,540
sistemi che abbiamo costruito. Destra?

192
00:08:29,540 --> 00:08:34,270
Troppi dati distribuiti in troppi
luoghi, la de-duplicazione dei dati,

193
00:08:34,270 --> 00:08:37,120
e il costo dello storage è stato enorme.

194
00:08:37,120 --> 00:08:43,760
>> Negli anni '70, la risorsa più costoso
che un computer aveva era lo stoccaggio.

195
00:08:43,760 --> 00:08:46,200
Il processore era
visto come un costo fisso.

196
00:08:46,200 --> 00:08:49,030
Quando compro la scatola,
la CPU fa un certo lavoro.

197
00:08:49,030 --> 00:08:51,960
E sta per essere filatura se
in realtà è lavoro oppure no.

198
00:08:51,960 --> 00:08:53,350
Questo è davvero un costo sommerso.

199
00:08:53,350 --> 00:08:56,030
>> Ma quello che mi è costato un
affari è di stoccaggio.

200
00:08:56,030 --> 00:09:00,020
Se devo comprare più dischi prossimo
mese, questo è un vero e proprio costo che pago.

201
00:09:00,020 --> 00:09:01,620
E che lo stoccaggio è costoso.

202
00:09:01,620 --> 00:09:05,020
>> Ora siamo veloci in avanti 40 anni
e abbiamo un problema diverso.

203
00:09:05,020 --> 00:09:10,020
Il calcolo è ora il
risorsa più costoso.

204
00:09:10,020 --> 00:09:11,470
Il deposito è a buon mercato.

205
00:09:11,470 --> 00:09:14,570
Voglio dire, si può andare in qualsiasi punto della
Cloud e possiamo trovare di stoccaggio a basso costo.

206
00:09:14,570 --> 00:09:17,190
Ma quello che non riesco a trovare è calcolo economico.

207
00:09:17,190 --> 00:09:20,700
>> Così l'evoluzione di oggi
La tecnologia, di tecnologia di database,

208
00:09:20,700 --> 00:09:23,050
è molto concentrato intorno
database distribuiti

209
00:09:23,050 --> 00:09:26,960
che non soffrono di
lo stesso tipo di scala

210
00:09:26,960 --> 00:09:29,240
limitazioni di database relazionali.

211
00:09:29,240 --> 00:09:32,080
Parleremo un po 'di
che cosa significa realmente.

212
00:09:32,080 --> 00:09:34,760
>> Ma uno dei motivi e
il driver dietro questo-- noi

213
00:09:34,760 --> 00:09:38,290
ha parlato della pressione dei dati.

214
00:09:38,290 --> 00:09:41,920
Pressione dati è qualcosa
che spinge l'innovazione.

215
00:09:41,920 --> 00:09:44,610
E se si guarda al di sopra
negli ultimi cinque anni,

216
00:09:44,610 --> 00:09:48,180
questo è un grafico di quello dei dati
carico in tutta l'azienda in generale

217
00:09:48,180 --> 00:09:49,640
sembra che negli ultimi cinque anni.

218
00:09:49,640 --> 00:09:52,570
>> E la regola generale
questi days-- se si va Google--

219
00:09:52,570 --> 00:09:55,290
è il 90% dei dati che
memorizziamo oggi, ed era

220
00:09:55,290 --> 00:09:57,330
generato nel corso degli ultimi due anni.

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

222
00:09:57,911 --> 00:09:59,410
Ora, questa non è una tendenza che è nuovo.

223
00:09:59,410 --> 00:10:01,230
Questa è una tendenza che è stato
uscire per 100 anni.

224
00:10:01,230 --> 00:10:03,438
Da quando Herman Hollerith
sviluppato la scheda perforata,

225
00:10:03,438 --> 00:10:08,040
abbiamo costruito repository di dati
e la raccolta di dati a velocità fenomenali.

226
00:10:08,040 --> 00:10:10,570
>> Così nel corso degli ultimi 100 anni,
abbiamo visto questa tendenza.

227
00:10:10,570 --> 00:10:11,940
Questo non cambierà.

228
00:10:11,940 --> 00:10:14,789
Andando avanti, stiamo andando a vedere
questo, se non una tendenza accelerata.

229
00:10:14,789 --> 00:10:16,330
E si può vedere ciò che sembra.

230
00:10:16,330 --> 00:10:23,510
>> Se un'impresa nel 2010 ha avuto un
terabyte di dati in gestione,

231
00:10:23,510 --> 00:10:27,080
oggi che significa che sono
gestione di 6,5 petabyte di dati.

232
00:10:27,080 --> 00:10:30,380
Questo è 6.500 volte più dati.

233
00:10:30,380 --> 00:10:31,200
E so che questo.

234
00:10:31,200 --> 00:10:33,292
Io lavoro con queste aziende ogni giorno.

235
00:10:33,292 --> 00:10:35,000
Cinque anni fa, ho
sarebbe parlare con le aziende

236
00:10:35,000 --> 00:10:38,260
che avrebbe parlare con me di quello che un dolore
che è quello di gestire terabyte di dati.

237
00:10:38,260 --> 00:10:39,700
E avrebbero parlato
a me su come vediamo

238
00:10:39,700 --> 00:10:41,825
che questa è destinata probabilmente
essere una o due petabyte

239
00:10:41,825 --> 00:10:43,030
entro un paio di anni.

240
00:10:43,030 --> 00:10:45,170
>> Queste stesse aziende
oggi ho un incontro con,

241
00:10:45,170 --> 00:10:48,100
e stanno parlando con me circa il
problema stanno avendo lì la gestione

242
00:10:48,100 --> 00:10:51,440
decine, 20 petabyte di dati.

243
00:10:51,440 --> 00:10:53,590
Così l'esplosione del
Dati del settore

244
00:10:53,590 --> 00:10:56,670
sta guidando l'enorme
necessità di soluzioni migliori.

245
00:10:56,670 --> 00:11:00,980
E il database relazionale è
semplicemente non vivere fino alla domanda.

246
00:11:00,980 --> 00:11:03,490
>> E quindi c'è una lineari
la correlazione tra la pressione dei dati

247
00:11:03,490 --> 00:11:05,210
e innovazione tecnica.

248
00:11:05,210 --> 00:11:07,780
La storia ci ha mostrato
questo, che nel tempo,

249
00:11:07,780 --> 00:11:11,090
ogni volta che il volume dei dati
che deve essere processato

250
00:11:11,090 --> 00:11:15,490
supera la capacità del sistema
di elaborare in un tempo ragionevole

251
00:11:15,490 --> 00:11:18,870
o ad un costo ragionevole,
poi le nuove tecnologie

252
00:11:18,870 --> 00:11:21,080
sono inventato per risolvere questi problemi.

253
00:11:21,080 --> 00:11:24,090
Queste nuove tecnologie,
a sua volta, aprire la porta

254
00:11:24,090 --> 00:11:27,840
a un'altra serie di problemi, che
sta raccogliendo ancora più dati.

255
00:11:27,840 --> 00:11:29,520
>> Ora, non stiamo andando a fermare tutto questo.

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

257
00:11:30,020 --> 00:11:31,228
Non stiamo andando a fermare tutto questo.

258
00:11:31,228 --> 00:11:31,830
Come mai?

259
00:11:31,830 --> 00:11:35,520
Poiché non è possibile sapere tutto
c'è da sapere nell'universo.

260
00:11:35,520 --> 00:11:40,510
E finché siamo stati vivi,
in tutta la storia dell'uomo,

261
00:11:40,510 --> 00:11:43,440
abbiamo sempre spinto a saperne di più.

262
00:11:43,440 --> 00:11:49,840
>> Così sembra che ogni pollice ci muoviamo
lungo il sentiero della scoperta scientifica,

263
00:11:49,840 --> 00:11:54,620
stiamo moltiplicando la quantità di dati
che abbiamo bisogno di elaborare in modo esponenziale

264
00:11:54,620 --> 00:11:59,920
come scopriamo sempre più
sul funzionamento interno della vita,

265
00:11:59,920 --> 00:12:04,530
su come funziona l'universo, su
guidare la scoperta scientifica,

266
00:12:04,530 --> 00:12:06,440
e l'invenzione che
stiamo facendo oggi.

267
00:12:06,440 --> 00:12:09,570
Il volume di dati appena
aumenta continuamente.

268
00:12:09,570 --> 00:12:12,120
Quindi essere in grado di affrontare
questo problema è enorme.

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

270
00:12:14,790 --> 00:12:17,410
>> Così una delle cose
guardiamo come NoSQL perché?

271
00:12:17,410 --> 00:12:19,200
In che modo NoSQL risolvere questo problema?

272
00:12:19,200 --> 00:12:24,980
Beh, database relazionali,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- che è davvero un costrutto della
relazionale database-- queste cose sono

274
00:12:28,600 --> 00:12:30,770
ottimizzato per la conservazione.

275
00:12:30,770 --> 00:12:33,180
>> Già negli anni '70, ancora una volta,
disco è costoso.

276
00:12:33,180 --> 00:12:36,990
L'esercizio provisioning dello storage
in azienda è senza fine.

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

278
00:12:37,490 --> 00:12:38,020
Ho vissuto.

279
00:12:38,020 --> 00:12:41,250
Ho scritto driver di archiviazione per un
società superserver Enterprised

280
00:12:41,250 --> 00:12:42,470
indietro negli anni '90.

281
00:12:42,470 --> 00:12:45,920
E la linea di fondo è un'altra svinatura
array di storage era solo qualcosa che

282
00:12:45,920 --> 00:12:47,600
accaduto ogni giorno in azienda.

283
00:12:47,600 --> 00:12:49,030
E non si è mai fermato.

284
00:12:49,030 --> 00:12:52,690
Archiviazione maggiore densità, la domanda
per lo stoccaggio ad alta densità,

285
00:12:52,690 --> 00:12:56,340
e per lo storage più efficiente
devices-- non è mai fermato.

286
00:12:56,340 --> 00:13:00,160
>> E NoSQL è una grande tecnologia
perché normalizza i dati.

287
00:13:00,160 --> 00:13:02,210
Si de-duplica dei dati.

288
00:13:02,210 --> 00:13:07,180
Si mette i dati in una struttura che
è agnostico per ogni tipo di accesso.

289
00:13:07,180 --> 00:13:11,600
Più applicazioni che possono colpire
Database SQL, eseguire query ad hoc,

290
00:13:11,600 --> 00:13:15,950
e ottenere i dati nella forma che
necessario elaborare per i loro carichi di lavoro.

291
00:13:15,950 --> 00:13:17,570
Che suona fantastico.

292
00:13:17,570 --> 00:13:21,350
Ma la linea di fondo è con qualsiasi
sistema, se è agnostica a tutto,

293
00:13:21,350 --> 00:13:23,500
è ottimizzato per nulla.

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

295
00:13:24,050 --> 00:13:26,386
>> Ed è quello che si ottiene con
il database relazionale.

296
00:13:26,386 --> 00:13:27,510
È ottimizzato per la conservazione.

297
00:13:27,510 --> 00:13:28,280
È normalizzato.

298
00:13:28,280 --> 00:13:29,370
E 'relazionale.

299
00:13:29,370 --> 00:13:31,660
Supporta le query ad hoc.

300
00:13:31,660 --> 00:13:34,000
Ed esso e scale in verticale.

301
00:13:34,000 --> 00:13:39,030
>> Se ho bisogno di ottenere un database SQL più grande
o un database SQL più potente,

302
00:13:39,030 --> 00:13:41,090
Vado comprare un pezzo più grande di ferro.

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

304
00:13:41,600 --> 00:13:44,940
Ho lavorato con un sacco di clienti
che sono state con importanti aggiornamenti

305
00:13:44,940 --> 00:13:48,340
nella loro infrastruttura di SQL solo
per scoprire sei mesi più tardi,

306
00:13:48,340 --> 00:13:49,750
che stanno colpendo il muro di nuovo.

307
00:13:49,750 --> 00:13:55,457
E la risposta da Oracle o MSSQL
o chiunque altro è ottenere una scatola più grande.

308
00:13:55,457 --> 00:13:58,540
Beh, prima o poi, non si può comprare un
scatola più grande, e questo è vero problema.

309
00:13:58,540 --> 00:14:00,080
Abbiamo bisogno di cambiare realmente le cose.

310
00:14:00,080 --> 00:14:01,080
Allora, dove funziona?

311
00:14:01,080 --> 00:14:06,560
Funziona bene per linea
analisi OLAP, tipo i carichi di lavoro.

312
00:14:06,560 --> 00:14:08,670
E questo è davvero dove SQL appartiene.

313
00:14:08,670 --> 00:14:12,540
Ora, è oggi utilizzato in molti on-line
transazionale lavorazione di tipo

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

315
00:14:13,330 --> 00:14:16,460
E funziona bene in
un certo livello di utilizzazione,

316
00:14:16,460 --> 00:14:18,670
ma semplicemente non scala
il modo in cui lo fa NoSQL.

317
00:14:18,670 --> 00:14:20,660
E parleremo un po '
po 'su perché.

318
00:14:20,660 --> 00:14:23,590
>> Ora, NoSQL, d'altra parte,
è più ottimizzato per calcolo.

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

320
00:14:24,540 --> 00:14:26,830
Non è agnostica di
il modello di accesso.

321
00:14:26,830 --> 00:14:31,620
È ciò che chiamiamo de-normalizzata
struttura o una struttura gerarchica.

322
00:14:31,620 --> 00:14:35,000
I dati in un database relazionale è
uniti da più tabelle

323
00:14:35,000 --> 00:14:36,850
per produrre l'opinione che si ha bisogno.

324
00:14:36,850 --> 00:14:40,090
I dati in un database NoSQL
è memorizzato in un documento che

325
00:14:40,090 --> 00:14:42,100
contiene la struttura gerarchica.

326
00:14:42,100 --> 00:14:45,670
Tutti i dati che normalmente sarebbe
uniti per produrre quella vista

327
00:14:45,670 --> 00:14:47,160
è memorizzato in un unico documento.

328
00:14:47,160 --> 00:14:50,990
E parleremo un po 'di
come funziona in un paio di grafici.

329
00:14:50,990 --> 00:14:55,320
>> Ma l'idea è che si memorizza
i tuoi dati come questi punti di vista istanziato.

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

331
00:14:56,410 --> 00:14:58,610
Si scala orizzontalmente.

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

333
00:14:59,556 --> 00:15:02,100
Se ho bisogno di aumentare la
dimensioni del mio gruppo NoSQL,

334
00:15:02,100 --> 00:15:03,700
Non ho bisogno di ottenere una scatola più grande.

335
00:15:03,700 --> 00:15:05,200
Ho un'altra scatola.

336
00:15:05,200 --> 00:15:07,700
E io CLUSTER quelli insieme,
e posso coccio tali dati.

337
00:15:07,700 --> 00:15:10,780
Parleremo un po '
cosa sharding è, di essere

338
00:15:10,780 --> 00:15:14,270
in grado di scalare quel database
su più dispositivi fisici

339
00:15:14,270 --> 00:15:18,370
e rimuovere la barriera che
mi impone di scalare verticalmente.

340
00:15:18,370 --> 00:15:22,080
>> Quindi è davvero costruito per linea
elaborazione delle transazioni e la scala.

341
00:15:22,080 --> 00:15:25,480
C'è una grande differenza
qui tra reporting, giusto?

342
00:15:25,480 --> 00:15:27,810
Segnalazione, non so il
domande ho intenzione di chiedere.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- se qualcuno da
il mio ufficio marketing

345
00:15:30,570 --> 00:15:34,520
vuole solo-- come molti dei miei clienti
avere questa caratteristica particolare che

346
00:15:34,520 --> 00:15:37,850
comprato su questo giorno-- non so
cosa interrogare hanno intenzione di chiedere.

347
00:15:37,850 --> 00:15:39,160
Così ho bisogno di essere agnostico.

348
00:15:39,160 --> 00:15:41,810
>> Ora, in una linea
un'applicazione transazionale,

349
00:15:41,810 --> 00:15:43,820
So quello che sto chiedendo domande.

350
00:15:43,820 --> 00:15:46,581
Ho costruito la domanda di
un flusso di lavoro molto specifico.

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

352
00:15:47,080 --> 00:15:50,540
Quindi, se ho ottimizzare i dati
memorizzare per sostenere che il flusso di lavoro,

353
00:15:50,540 --> 00:15:52,020
che sta per essere più veloce.

354
00:15:52,020 --> 00:15:55,190
Ed è per questo che può NoSQL
davvero accelerare la consegna

355
00:15:55,190 --> 00:15:57,710
di quei tipi di servizi.

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

357
00:15:58,210 --> 00:16:00,501
>> Quindi stiamo per entrare in
un po 'di teoria qui.

358
00:16:00,501 --> 00:16:03,330
E alcuni di voi, i vostri occhi
potrebbe ripristinare un po '.

359
00:16:03,330 --> 00:16:06,936
Ma cercherò di tenerlo
come di alto livello possibile.

360
00:16:06,936 --> 00:16:08,880
Quindi, se siete in progetto
gestione, c'e '

361
00:16:08,880 --> 00:16:12,280
un costrutto chiamato
triangolo di vincoli.

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

363
00:16:12,936 --> 00:16:16,060
Il triangolo di vincoli dettati
non si può avere tutto ogni volta.

364
00:16:16,060 --> 00:16:17,750
Non può avere la vostra torta e la moglie ubriaca.

365
00:16:17,750 --> 00:16:22,310
Quindi, nella gestione dei progetti, quel triangolo
vincoli è che si può avere a buon mercato,

366
00:16:22,310 --> 00:16:24,710
si può avere fretta,
o si può avere una buona.

367
00:16:24,710 --> 00:16:25,716
Prendine due.

368
00:16:25,716 --> 00:16:27,090
Poiché non è possibile avere tutti e tre.

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

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

371
00:16:27,820 --> 00:16:28,920
>> Così avete sentito parlare di questo un sacco.

372
00:16:28,920 --> 00:16:31,253
Si tratta di un vincolo tripla,
triangolo triplo vincolo,

373
00:16:31,253 --> 00:16:34,420
o il triangolo di ferro è oftentimes--
quando si parla di project manager,

374
00:16:34,420 --> 00:16:35,420
faranno parlare di questo.

375
00:16:35,420 --> 00:16:37,640
Ora, database hanno
proprio triangolo di ferro.

376
00:16:37,640 --> 00:16:40,350
E il triangolo di ferro dei dati
è quello che chiamiamo teorema cap.

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

378
00:16:41,580 --> 00:16:43,770
>> PAC dettami teorema
come funzionano i database

379
00:16:43,770 --> 00:16:45,627
sotto una condizione molto specifica.

380
00:16:45,627 --> 00:16:47,460
E parleremo
ciò che tale condizione sia.

381
00:16:47,460 --> 00:16:52,221
Ma i tre vertici del triangolo,
per così dire, sono C, consistenza.

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

383
00:16:52,720 --> 00:16:56,760
Così in CAP, consistenza significa che tutti
i clienti che possono accedere alla banca dati

384
00:16:56,760 --> 00:16:59,084
avrà sempre molto
visione coerente dei dati.

385
00:16:59,084 --> 00:17:00,750
Andando di nessuno vedere due cose diverse.

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

387
00:17:01,480 --> 00:17:04,020
Se vedo il database,
Vedo la stessa vista

388
00:17:04,020 --> 00:17:06,130
come il mio compagno che vede
lo stesso database.

389
00:17:06,130 --> 00:17:07,470
Questa è la coerenza.

390
00:17:07,470 --> 00:17:12,099
>> Disponibilità significa che se la
database online, se può essere raggiunto,

391
00:17:12,099 --> 00:17:14,760
che tutti i clienti sarà sempre
essere in grado di leggere e scrivere.

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

393
00:17:15,260 --> 00:17:17,010
Così ogni client che
in grado di leggere il database

394
00:17:17,010 --> 00:17:18,955
sarà sempre in grado di lettura
dati dati e scrivere.

395
00:17:18,955 --> 00:17:21,819
E se questo è il caso,
si tratta di un sistema disponibile.

396
00:17:21,819 --> 00:17:24,230
>> E il terzo punto è quello che
chiamiamo tolleranza partizione.

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

398
00:17:24,730 --> 00:17:28,160
Mezzi di tolleranza Partition
che il sistema funziona bene

399
00:17:28,160 --> 00:17:32,000
nonostante rete fisica
pareti divisorie tra i nodi.

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

401
00:17:32,760 --> 00:17:36,270
Quindi i nodi del cluster non può
parlano tra loro, che cosa succede?

402
00:17:36,270 --> 00:17:36,880
Tutto ok.

403
00:17:36,880 --> 00:17:39,545
>> I database relazionali così prego--
è possibile scegliere due di questi.

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

405
00:17:40,045 --> 00:17:43,680
I database relazionali così scegliere
essere coerenti e disponibile.

406
00:17:43,680 --> 00:17:47,510
Se la partizione avviene tra
le DataNodes nell'archivio dati,

407
00:17:47,510 --> 00:17:48,831
il database si blocca.

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

409
00:17:49,330 --> 00:17:50,900
Semplicemente va giù.

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

411
00:17:51,450 --> 00:17:54,230
>> E questo è il motivo per cui hanno
di crescere con le scatole più grandi.

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

413
00:17:54,730 --> 00:17:58,021
Perché c'è no-- solito, un cluster
database, non c'è molto molti di loro

414
00:17:58,021 --> 00:17:59,590
che operano in questo modo.

415
00:17:59,590 --> 00:18:03,019
Ma la maggior parte dei database scala
verticalmente all'interno di un unico contenitore.

416
00:18:03,019 --> 00:18:05,060
Perché hanno bisogno di essere
coerente e disponibili.

417
00:18:05,060 --> 00:18:10,320
Se una partizione venisse iniettata,
allora si dovrà fare una scelta.

418
00:18:10,320 --> 00:18:13,720
Devi fare una scelta tra
essere coerente e disponibile.

419
00:18:13,720 --> 00:18:16,080
>> Ed è quello che i database NoSQL fanno.

420
00:18:16,080 --> 00:18:16,580
Tutto ok.

421
00:18:16,580 --> 00:18:20,950
Quindi un database NoSQL, esso
è disponibile in due versioni.

422
00:18:20,950 --> 00:18:22,990
Noi have-- bene,
è disponibile in molti sapori,

423
00:18:22,990 --> 00:18:26,140
ma si tratta di due di base
characteristics-- cosa

424
00:18:26,140 --> 00:18:30,050
noi chiameremmo dati del CP, o un
tolleranza costante e la partizione

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

426
00:18:31,040 --> 00:18:34,930
Questi ragazzi fanno la scelta che quando
i nodi perdono il contatto con l'altro,

427
00:18:34,930 --> 00:18:37,091
non stiamo andando per consentire
persone a scrivere più.

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

429
00:18:37,590 --> 00:18:41,855
>> Fino a quel divisorio viene rimosso,
l'accesso in scrittura è bloccato.

430
00:18:41,855 --> 00:18:43,230
Ciò significa che non sono disponibili.

431
00:18:43,230 --> 00:18:44,510
Sono coerente.

432
00:18:44,510 --> 00:18:46,554
Quando vediamo che
partizione iniettare se stesso,

433
00:18:46,554 --> 00:18:48,470
siamo ora coerente,
perché non stiamo andando

434
00:18:48,470 --> 00:18:51,517
per consentire la variazione dei dati su due
lati della partizione indipendente

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

436
00:18:52,100 --> 00:18:54,130
Dovremo
ristabilire la comunicazione

437
00:18:54,130 --> 00:18:56,930
prima di qualsiasi aggiornamento
il dato è permesso.

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

439
00:18:58,120 --> 00:19:02,650
>> Il sapore successivo sarebbe un sistema AP,
o partizionato un disponibile e

440
00:19:02,650 --> 00:19:03,640
sistema di tolleranza.

441
00:19:03,640 --> 00:19:05,320
Questi ragazzi non si preoccupano.

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

443
00:19:06,020 --> 00:19:08,960
Qualsiasi nodo che ottiene un
scriviamo, noi lo prenderemo.

444
00:19:08,960 --> 00:19:11,480
Così sto replica dei miei dati
in più nodi.

445
00:19:11,480 --> 00:19:14,730
Questi nodi ottengono un cliente, cliente viene
in, dice, ho intenzione di scrivere alcuni dati.

446
00:19:14,730 --> 00:19:16,300
Nodo dice, nessun problema.

447
00:19:16,300 --> 00:19:18,580
Il nodo accanto a lui si
una scrittura sullo stesso disco,

448
00:19:18,580 --> 00:19:20,405
ha intenzione di dire di no problema.

449
00:19:20,405 --> 00:19:23,030
Da qualche parte indietro sul back-end,
che i dati sta per replicare.

450
00:19:23,030 --> 00:19:27,360
E poi qualcuno sta per realizzare,
uh-oh, sistema realizzerà, uh-oh,

451
00:19:27,360 --> 00:19:28,870
c'è stato un aggiornamento di due parti.

452
00:19:28,870 --> 00:19:30,370
Cosa facciamo?

453
00:19:30,370 --> 00:19:33,210
E quello che fanno, allora è
fanno qualcosa che

454
00:19:33,210 --> 00:19:36,080
permette loro di risolvere tale stato i dati.

455
00:19:36,080 --> 00:19:39,000
E parleremo
che nella tabella seguente.

456
00:19:39,000 --> 00:19:40,000
>> Cosa da sottolineare qui.

457
00:19:40,000 --> 00:19:42,374
E io non ho intenzione di arrivare troppo
molto in questo, perché questo

458
00:19:42,374 --> 00:19:43,510
riceve in teoria i dati in profondità.

459
00:19:43,510 --> 00:19:46,670
Ma c'è un transazionale
quadro che

460
00:19:46,670 --> 00:19:50,680
viene eseguito in un sistema relazionale che
mi permette di fare in modo sicuro gli aggiornamenti

461
00:19:50,680 --> 00:19:53,760
di più entità nel database.

462
00:19:53,760 --> 00:19:58,320
E si verificheranno tali aggiornamenti
tutto in una volta o per niente.

463
00:19:58,320 --> 00:20:00,500
E questo si chiama transazioni ACID.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID ci dà atomicità, consistenza,
isolamento e durata.

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

467
00:20:07,070 --> 00:20:13,550
Ciò significa atomici, le transazioni, tutto
i miei aggiornamenti o avvengono o non lo fanno.

468
00:20:13,550 --> 00:20:16,570
Coerenza significa che
la banca dati sarà sempre

469
00:20:16,570 --> 00:20:19,780
essere portato in un consistente
stato dopo un aggiornamento.

470
00:20:19,780 --> 00:20:23,900
Non potrò mai lasciare il database in uno
cattivo stato dopo l'applicazione di un aggiornamento.

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

472
00:20:24,400 --> 00:20:26,720
>> Quindi è un po 'diverso
di consistenza PAC.

473
00:20:26,720 --> 00:20:29,760
Coerenza PAC significa tutto il mio
i clienti possono sempre vedere i dati.

474
00:20:29,760 --> 00:20:34,450
Consistenza ACIDO significa che quando
una transazione è fatto, i dati di buono.

475
00:20:34,450 --> 00:20:35,709
I miei rapporti sono tutti buoni.

476
00:20:35,709 --> 00:20:38,750
Io non ho intenzione di eliminare una riga padre
e lasciare un po 'di bambini orfani

477
00:20:38,750 --> 00:20:40,970
in qualche altra tabella.

478
00:20:40,970 --> 00:20:44,320
Non può succedere se sono coerente
in una transazione acida.

479
00:20:44,320 --> 00:20:49,120
>> Isolamento significa che le operazioni
avverrà sempre uno dopo l'altro.

480
00:20:49,120 --> 00:20:51,920
Il risultato finale dei dati
sarà lo stesso stato

481
00:20:51,920 --> 00:20:54,770
come se tali operazioni
che sono stati emessi contemporaneamente

482
00:20:54,770 --> 00:20:57,340
sono stati eseguiti in serie.

483
00:20:57,340 --> 00:21:00,030
Quindi è concorrenza
controllo nel database.

484
00:21:00,030 --> 00:21:04,130
Quindi, fondamentalmente, non riesco a incrementare il
stesso valore due volte con due operazioni.

485
00:21:04,130 --> 00:21:08,580
>> Ma se dico aggiungere 1 a questo valore,
e due operazioni sono disponibili in

486
00:21:08,580 --> 00:21:10,665
e cercare di farlo, si è
intenzione di arrivare prima

487
00:21:10,665 --> 00:21:12,540
e l'altro di un
intenzione di arrivare dopo.

488
00:21:12,540 --> 00:21:15,210
Così, alla fine, ho aggiunto due.

489
00:21:15,210 --> 00:21:16,170
Vedete cosa voglio dire?

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
>> La durabilità è abbastanza semplice.

493
00:21:21,250 --> 00:21:23,460
Quando la transazione
è riconosciuta, e '

494
00:21:23,460 --> 00:21:26,100
sta per essere lì anche
se il sistema va in crash.

495
00:21:26,100 --> 00:21:29,230
Quando questo sistema recupera, che
operazione che è stato commesso

496
00:21:29,230 --> 00:21:30,480
è in realtà sta per essere lì.

497
00:21:30,480 --> 00:21:33,130
Ecco, questo è le garanzie
di transazioni ACID.

498
00:21:33,130 --> 00:21:35,470
Quelli sono molto carino garanzie
disporre su un database,

499
00:21:35,470 --> 00:21:36,870
ma vengono a quel costo.

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

501
00:21:37,640 --> 00:21:40,520
>> Perché il problema
con questo quadro è

502
00:21:40,520 --> 00:21:44,540
se c'è una partizione nei dati
insieme, devo prendere una decisione.

503
00:21:44,540 --> 00:21:48,000
Sto andando ad avere per consentire
aggiornamenti su un lato o l'altro.

504
00:21:48,000 --> 00:21:50,310
E se questo accade,
allora non ho più intenzione sono

505
00:21:50,310 --> 00:21:52,630
per poter mantenere
tali caratteristiche.

506
00:21:52,630 --> 00:21:53,960
Non saranno coerenti.

507
00:21:53,960 --> 00:21:55,841
Non saranno isolati.

508
00:21:55,841 --> 00:21:58,090
Questo è dove si rompe
per i database relazionali.

509
00:21:58,090 --> 00:22:01,360
Questa è la ragione relazionale
database scala verticalmente.

510
00:22:01,360 --> 00:22:05,530
>> D'altra parte, abbiamo
quello che chiama tecnologia di base.

511
00:22:05,530 --> 00:22:07,291
E questi sono i database NoSQL.

512
00:22:07,291 --> 00:22:07,790
Tutto ok.

513
00:22:07,790 --> 00:22:10,180
Così abbiamo la nostra CP, i database AP.

514
00:22:10,180 --> 00:22:14,720
E questi sono ciò che si chiama fondamentalmente
disponibile, soft stato, alla fine

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

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

517
00:22:16,420 --> 00:22:19,690
>> Fondamentalmente disponibile, perché
sono tolleranti partizione.

518
00:22:19,690 --> 00:22:21,470
Saranno sempre
lì, anche se non c'è

519
00:22:21,470 --> 00:22:23,053
una partizione di rete tra i nodi.

520
00:22:23,053 --> 00:22:25,900
Se posso parlare con un nodo, sono
sarà in grado di leggere i dati.

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

522
00:22:26,460 --> 00:22:30,810
Potrei non essere sempre in grado di scrivere
dati se io sono una piattaforma coerente.

523
00:22:30,810 --> 00:22:32,130
Ma sarò in grado di leggere i dati.

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

525
00:22:34,960 --> 00:22:38,010
>> Lo stato morbido indica
che quando ho letto che i dati,

526
00:22:38,010 --> 00:22:40,790
potrebbe non essere la stessa di altri nodi.

527
00:22:40,790 --> 00:22:43,390
Se un diritto è stato rilasciato su un nodo
da qualche altra parte nel cluster

528
00:22:43,390 --> 00:22:46,650
e non è stato replicato in tutto il
grappolo ma quando ho letto che i dati,

529
00:22:46,650 --> 00:22:48,680
questo stato potrebbe non essere coerente.

530
00:22:48,680 --> 00:22:51,650
Tuttavia, sarà
finalmente coerente,

531
00:22:51,650 --> 00:22:53,870
il che significa che quando una scrittura
è fatto per il sistema,

532
00:22:53,870 --> 00:22:56,480
si replicherà attraverso i nodi.

533
00:22:56,480 --> 00:22:59,095
E alla fine, quello stato
sarà portato in ordine,

534
00:22:59,095 --> 00:23:00,890
e sarà uno stato coerente.

535
00:23:00,890 --> 00:23:05,000
>> Ora, CAP teorema davvero
gioca in una sola condizione.

536
00:23:05,000 --> 00:23:08,700
Tale condizione è quando questo accade.

537
00:23:08,700 --> 00:23:13,710
Perché ogni volta che è operante in
modalità normale, non c'è nessuna partizione,

538
00:23:13,710 --> 00:23:16,370
tutto è coerente e disponibile.

539
00:23:16,370 --> 00:23:19,990
Ti preoccupi solo di PAC
quando abbiamo quella partizione.

540
00:23:19,990 --> 00:23:21,260
Quindi questi sono rari.

541
00:23:21,260 --> 00:23:25,360
Ma come il sistema reagisce quando quelli
si verificano dettare quale tipo di sistema

542
00:23:25,360 --> 00:23:26,750
abbiamo a che fare.

543
00:23:26,750 --> 00:23:31,110
>> Quindi, diamo un'occhiata a ciò che
che assomiglia per i sistemi di AP.

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

545
00:23:32,621 --> 00:23:34,830
Sistemi di AP sono di due tipi.

546
00:23:34,830 --> 00:23:38,514
Vengono nel sapore che è un
Master, 100%, sempre a disposizione.

547
00:23:38,514 --> 00:23:40,430
E vengono in
altro sapore, che dice:

548
00:23:40,430 --> 00:23:43,330
sai cosa, ho intenzione di preoccuparsi
di questa cosa partizionamento

549
00:23:43,330 --> 00:23:44,724
quando si verifica una partizione reale.

550
00:23:44,724 --> 00:23:47,890
In caso contrario, ci sara 'primario
nodi che sta andando a prendere i diritti.

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

552
00:23:48,500 --> 00:23:50,040
>> Quindi, se qualcosa di simile a Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra sarebbe un maestro
padrone, andiamo a scrivere ad ogni nodo.

554
00:23:54,440 --> 00:23:55,540
Allora, cosa succede?

555
00:23:55,540 --> 00:23:58,270
Così ho un oggetto nella
database esistente su due nodi.

556
00:23:58,270 --> 00:24:01,705
Chiamiamolo quell'oggetto S.
Così abbiamo statale per S.

557
00:24:01,705 --> 00:24:04,312
Abbiamo alcune operazioni
su S che sono in corso.

558
00:24:04,312 --> 00:24:06,270
Cassandra mi permette di
scrivere a più nodi.

559
00:24:06,270 --> 00:24:08,550
Quindi diciamo che ho un
scrivere per s a due nodi.

560
00:24:08,550 --> 00:24:12,274
Ebbene, ciò che finisce accadendo è
noi chiamiamo che un evento di partizionamento.

561
00:24:12,274 --> 00:24:14,190
Non ci può essere un
partizione rete fisica.

562
00:24:14,190 --> 00:24:15,950
Ma a causa del disegno
del sistema, è

563
00:24:15,950 --> 00:24:18,449
in realtà il più presto partizionamento
come ottengo una scrittura su due nodi.

564
00:24:18,449 --> 00:24:20,830
Non mi sta costringendo a
scrivere tutto attraverso un nodo.

565
00:24:20,830 --> 00:24:22,340
Sto scrivendo su due nodi.

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

567
00:24:23,330 --> 00:24:25,740
>> Così ora ho due stati.

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

569
00:24:26,360 --> 00:24:28,110
Cosa succederà
è prima o poi,

570
00:24:28,110 --> 00:24:29,960
ci sara 'un evento di replica.

571
00:24:29,960 --> 00:24:33,300
Ci sara 'quello che abbiamo
chiamato un recupero del divisorio, che

572
00:24:33,300 --> 00:24:35,200
è dove questi due
Stati tornano insieme

573
00:24:35,200 --> 00:24:37,310
e ci sara 'un algoritmo
che corre all'interno del database,

574
00:24:37,310 --> 00:24:38,540
decide cosa fare.

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

576
00:24:39,110 --> 00:24:43,057
Per impostazione predefinita, ultimo aggiornamento
vince nella maggior parte dei sistemi di AP.

577
00:24:43,057 --> 00:24:44,890
Così di solito c'è un
algoritmo predefinito, cosa

578
00:24:44,890 --> 00:24:47,400
che chiamano un callback
funzione, cosa che

579
00:24:47,400 --> 00:24:51,000
sarà chiamato quando questa condizione
viene rilevato ad eseguire qualche logica

580
00:24:51,000 --> 00:24:52,900
per risolvere quel conflitto.

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

582
00:24:53,850 --> 00:24:58,770
Il callback di default e di default
resolver nella maggior parte dei database AP

583
00:24:58,770 --> 00:25:01,130
è, indovinate un po ', timestamp vince.

584
00:25:01,130 --> 00:25:02,380
Questo era l'ultimo aggiornamento.

585
00:25:02,380 --> 00:25:04,320
Ho intenzione di mettere che si aggiornano in là.

586
00:25:04,320 --> 00:25:08,440
Posso scaricare questo disco che ho
dumping fuori in un registro per il recupero

587
00:25:08,440 --> 00:25:11,670
in modo che l'utente possa tornare più tardi
e dire: ehi, c'è stata una collisione.

588
00:25:11,670 --> 00:25:12,320
Quello che è successo?

589
00:25:12,320 --> 00:25:16,370
E si può effettivamente scaricare un record di
tutte le collisioni e le rollback

590
00:25:16,370 --> 00:25:17,550
e vedere cosa succede.

591
00:25:17,550 --> 00:25:21,580
>> Ora, come utente, è anche possibile
includere logica in quella richiamata.

592
00:25:21,580 --> 00:25:24,290
Così si può cambiare la situazione
operazione di richiamata.

593
00:25:24,290 --> 00:25:26,730
Si può dire, ehi, voglio
per rimediare questi dati.

594
00:25:26,730 --> 00:25:28,880
E voglio cercare di
unire i due record.

595
00:25:28,880 --> 00:25:30,050
Ma questo sta a voi.

596
00:25:30,050 --> 00:25:32,880
Il database non sa come
farlo per impostazione predefinita. La maggior parte del tempo,

597
00:25:32,880 --> 00:25:34,850
l'unica cosa database
sa come fare è dire,

598
00:25:34,850 --> 00:25:36,100
questo era l'ultimo record.

599
00:25:36,100 --> 00:25:39,183
Questo è quello che sta andando a vincere,
e questo è il valore che ho intenzione di mettere.

600
00:25:39,183 --> 00:25:41,490
Una volta che il recupero delle partizioni
e la replica si verifica,

601
00:25:41,490 --> 00:25:43,930
abbiamo il nostro Stato, che
è ora S primo, che è

602
00:25:43,930 --> 00:25:46,890
lo stato di unione di tutti quegli oggetti.

603
00:25:46,890 --> 00:25:49,700
Così i sistemi di AP hanno questo.

604
00:25:49,700 --> 00:25:51,615
Sistemi CP non necessitano
preoccuparsi di questo.

605
00:25:51,615 --> 00:25:54,490
Perché appena arriva una partizione
in gioco, hanno semplicemente smettere di prendere

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

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

608
00:25:56,180 --> 00:25:58,670
Ecco, questo è molto facile
fare con l'essere coerente

609
00:25:58,670 --> 00:26:01,330
quando non si accetta eventuali aggiornamenti.

610
00:26:01,330 --> 00:26:04,620
Questo è con i sistemi CP fanno.

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

612
00:26:05,120 --> 00:26:07,590
>> Così parliamo un po '
po 'di modelli di accesso.

613
00:26:07,590 --> 00:26:11,580
Quando si parla di NoSQL, è
tutto sul modello di accesso.

614
00:26:11,580 --> 00:26:13,550
Ora, SQL è ad hoc, le query.

615
00:26:13,550 --> 00:26:14,481
E 'archivio relazionale.

616
00:26:14,481 --> 00:26:16,480
Noi non dobbiamo preoccuparci
circa il modello di accesso.

617
00:26:16,480 --> 00:26:17,688
Scrivo una domanda molto complessa.

618
00:26:17,688 --> 00:26:19,250
Va e riceve i dati.

619
00:26:19,250 --> 00:26:21,210
Questo è ciò che questo sembra
come, la normalizzazione.

620
00:26:21,210 --> 00:26:24,890
>> Quindi, in questa particolare struttura,
stiamo guardando un catalogo prodotti.

621
00:26:24,890 --> 00:26:26,640
Ho diversi tipi di prodotti.

622
00:26:26,640 --> 00:26:27,217
Ho libri.

623
00:26:27,217 --> 00:26:27,800
Ho album.

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

625
00:26:30,090 --> 00:26:33,370
Il rapporto tra i prodotti
e uno di questi libri, album,

626
00:26:33,370 --> 00:26:34,860
e video tavoli è di 1: 1.

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

628
00:26:35,800 --> 00:26:38,860
Ho un ID del prodotto,
e che corrisponde ID

629
00:26:38,860 --> 00:26:41,080
di un libro, un album o un video.

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

631
00:26:41,580 --> 00:26:44,350
Questa è una relazione 1: 1
attraverso tali tabelle.

632
00:26:44,350 --> 00:26:46,970
>> Ora, tutto quello che books--
avere è proprietà di root.

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

634
00:26:47,550 --> 00:26:48,230
È fantastico.

635
00:26:48,230 --> 00:26:52,130
Uno-a-uno, ho tutti
i dati che ho bisogno di descrivere quel libro.

636
00:26:52,130 --> 00:26:54,770
Album Albums-- hanno tracce.

637
00:26:54,770 --> 00:26:56,470
Questo è ciò che noi chiamiamo uno a molti.

638
00:26:56,470 --> 00:26:58,905
Ogni album può avere molte tracce.

639
00:26:58,905 --> 00:27:00,780
Così, per ogni traccia su
l'album, ho potuto avere

640
00:27:00,780 --> 00:27:02,570
un altro record in questa tabella figlio.

641
00:27:02,570 --> 00:27:04,680
Così ho creato un record
nel mio tavolo album.

642
00:27:04,680 --> 00:27:06,700
Creo più record
nella tabella tracce.

643
00:27:06,700 --> 00:27:08,850
Uno-a-molti.

644
00:27:08,850 --> 00:27:11,220
>> Questa relazione è quello
chiamiamo molti-a-molti.

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

646
00:27:11,750 --> 00:27:17,000
Si vede che gli attori potrebbero essere
in molti film, molti video.

647
00:27:17,000 --> 00:27:21,450
Quindi quello che facciamo è che abbiamo messo questa mappatura
tavolo tra coloro, i quali solo

648
00:27:21,450 --> 00:27:24,040
mappe l'ID attore all'ID video.

649
00:27:24,040 --> 00:27:28,464
Ora posso creare una query join
video attraverso attore video da attori,

650
00:27:28,464 --> 00:27:31,130
e mi dà una bella lista di
tutti i film e tutti gli attori

651
00:27:31,130 --> 00:27:32,420
che erano in quel film.

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

653
00:27:33,290 --> 00:27:33,880
Quindi qui si va.

654
00:27:33,880 --> 00:27:38,040
One-to-one è il primo livello
relazione; uno-a-molti,

655
00:27:38,040 --> 00:27:40,240
album alle tracce; molti-a-molti.

656
00:27:40,240 --> 00:27:44,990
Questi sono i tre livelli top
relazioni in qualsiasi database.

657
00:27:44,990 --> 00:27:48,050
Se sai come quelli
rapporti di lavoro insieme,

658
00:27:48,050 --> 00:27:51,490
poi si sa un sacco
su base di dati già.

659
00:27:51,490 --> 00:27:55,660
Così NoSQL funziona un po 'diverso.

660
00:27:55,660 --> 00:27:58,930
Pensiamo per un attimo quello che
sembra che per andare a prendere tutti i miei prodotti.

661
00:27:58,930 --> 00:28:01,096
>> In un negozio relazionale, io
vuole ottenere tutti i miei prodotti

662
00:28:01,096 --> 00:28:02,970
su un elenco di tutti i miei prodotti.

663
00:28:02,970 --> 00:28:04,910
Questo è un sacco di domande.

664
00:28:04,910 --> 00:28:07,030
Ho una domanda per tutti i miei libri.

665
00:28:07,030 --> 00:28:08,470
Ho una domanda da miei album.

666
00:28:08,470 --> 00:28:09,970
E io ho una domanda per tutti i miei video.

667
00:28:09,970 --> 00:28:11,719
E ho avuto modo di mettere
tutti insieme in una lista

668
00:28:11,719 --> 00:28:15,250
e servire indietro fino al
applicazione che è lo richiedono.

669
00:28:15,250 --> 00:28:18,000
>> Per ottenere i miei libri, mi unisco
Prodotti e Libri.

670
00:28:18,000 --> 00:28:21,680
Per ottenere i miei album, ho avuto modo di unirsi
Prodotti, Album e tracce.

671
00:28:21,680 --> 00:28:25,330
E per ottenere il mio video, ho
di aderire a prodotti video,

672
00:28:25,330 --> 00:28:28,890
unirsi attraverso Attore Video,
e portare gli attori.

673
00:28:28,890 --> 00:28:31,020
Ecco, questo è tre domande.

674
00:28:31,020 --> 00:28:34,560
Query molto complesso
montare un set di risultati.

675
00:28:34,560 --> 00:28:36,540
>> Questo è meno che ottimale.

676
00:28:36,540 --> 00:28:39,200
Ecco perché quando si parla
di una struttura di dati che è

677
00:28:39,200 --> 00:28:42,900
costruita per essere agnostici all'accesso
pattern-- bene che è grande.

678
00:28:42,900 --> 00:28:45,730
E si può vedere questo è davvero
bello come abbiamo organizzato i dati.

679
00:28:45,730 --> 00:28:46,550
E sai una cosa?

680
00:28:46,550 --> 00:28:49,750
Ho solo un record per un attore.

681
00:28:49,750 --> 00:28:50,440
>> Questo è figo.

682
00:28:50,440 --> 00:28:53,750
Ho deduplicato tutti i miei attori,
e ho mantenuto le mie associazioni

683
00:28:53,750 --> 00:28:55,200
in questa tabella di mappatura.

684
00:28:55,200 --> 00:29:00,620
Tuttavia, ottenere i dati
fuori diventa costoso.

685
00:29:00,620 --> 00:29:04,500
Sto inviando la CPU in tutto il sistema
unendo queste strutture dati insieme

686
00:29:04,500 --> 00:29:05,950
per essere in grado di tirare indietro che dati.

687
00:29:05,950 --> 00:29:07,310
>> Allora, come faccio ad andare in giro così?

688
00:29:07,310 --> 00:29:11,200
In NoSQL si tratta di
aggregazione, non la normalizzazione.

689
00:29:11,200 --> 00:29:13,534
Quindi, vogliamo dire che vogliamo
supportare il modello di accesso.

690
00:29:13,534 --> 00:29:15,283
Se il modello di accesso
alle applicazioni,

691
00:29:15,283 --> 00:29:16,770
Ho bisogno di ottenere tutti i miei prodotti.

692
00:29:16,770 --> 00:29:19,027
Mettiamo tutti i prodotti di una tabella.

693
00:29:19,027 --> 00:29:22,110
Se metto tutti i prodotti di una tabella,
Posso solo selezionare tutti i prodotti

694
00:29:22,110 --> 00:29:23,850
da quel tavolo e ho capito tutto.

695
00:29:23,850 --> 00:29:25,240
Bene come posso fare?

696
00:29:25,240 --> 00:29:28,124
Bene in NoSQL non c'è
struttura alla tabella.

697
00:29:28,124 --> 00:29:30,540
Parleremo un po 'di
come funziona in Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Ma non si ha la stessa
attributi e le stesse proprietà

699
00:29:33,570 --> 00:29:37,751
in ogni singola riga, in ogni singolo
voce, come si fa in una tabella SQL.

700
00:29:37,751 --> 00:29:39,750
E ciò che questo mi permette
di fare è un sacco di cose

701
00:29:39,750 --> 00:29:41,124
e mi danno un sacco di flessibilità.

702
00:29:41,124 --> 00:29:45,360
In questo caso particolare,
i miei documenti di prodotto.

703
00:29:45,360 --> 00:29:49,090
E in questa particolare
esempio, tutto

704
00:29:49,090 --> 00:29:51,930
è un documento nella tabella Products.

705
00:29:51,930 --> 00:29:56,510
E il prodotto per un libro potrebbe
disporre di un ID tipo che specifica un libro.

706
00:29:56,510 --> 00:29:59,180
E l'applicazione
sarebbe attivare tale ID.

707
00:29:59,180 --> 00:30:02,570
>> Al livello applicazione, io vado
a dire oh, che tipo di record è questo?

708
00:30:02,570 --> 00:30:04,100
Oh, è un record di libro.

709
00:30:04,100 --> 00:30:05,990
Prenota record hanno queste proprietà.

710
00:30:05,990 --> 00:30:08,100
Mi permetta di creare un oggetto libro.

711
00:30:08,100 --> 00:30:11,289
Quindi ho intenzione di riempire il
oggetto libro con questo oggetto.

712
00:30:11,289 --> 00:30:13,080
Prodotto successivo arriva e
dice, che cosa è questo articolo?

713
00:30:13,080 --> 00:30:14,560
Beh, questa voce è un album.

714
00:30:14,560 --> 00:30:17,340
Oh, ho ottenuto un intero diverso
routine di trattamento per questo,

715
00:30:17,340 --> 00:30:18,487
perché è un album.

716
00:30:18,487 --> 00:30:19,320
Vedete cosa voglio dire?

717
00:30:19,320 --> 00:30:21,950
>> Così l'applicazione tier-- I
basta selezionare tutti questi record.

718
00:30:21,950 --> 00:30:23,200
Tutti cominciano ad arrivare.

719
00:30:23,200 --> 00:30:24,680
Essi potrebbero essere tutti i tipi diversi.

720
00:30:24,680 --> 00:30:27,590
Ed è la logica dell'applicazione
che gli interruttori attraverso questi tipi

721
00:30:27,590 --> 00:30:29,530
e decide come elaborare loro.

722
00:30:29,530 --> 00:30:33,640
>> Ancora una volta, quindi stiamo ottimizzando il
schema per il modello di accesso.

723
00:30:33,640 --> 00:30:36,390
Lo stiamo facendo da
collasso tali tabelle.

724
00:30:36,390 --> 00:30:39,670
Stiamo fondamentalmente prendendo
queste strutture normalizzati,

725
00:30:39,670 --> 00:30:42,000
e stiamo costruendo
strutture gerarchiche.

726
00:30:42,000 --> 00:30:45,130
All'interno di ciascuno di questi record
Io vado a vedere le proprietà di matrice.

727
00:30:45,130 --> 00:30:49,400
>> All'interno di questo documento per gli album,
Sto vedendo array di tracce.

728
00:30:49,400 --> 00:30:53,900
Queste tracce ora become-- è
fondamentalmente questa tabella figlio che

729
00:30:53,900 --> 00:30:56,520
esiste proprio qui in questa struttura.

730
00:30:56,520 --> 00:30:57,975
Così si può fare questo in DynamoDB.

731
00:30:57,975 --> 00:30:59,810
È possibile farlo in MongoDB.

732
00:30:59,810 --> 00:31:01,437
È possibile farlo in qualsiasi database NoSQL.

733
00:31:01,437 --> 00:31:03,520
Creare questi tipi di
strutture di dati gerarchiche

734
00:31:03,520 --> 00:31:07,120
che consentono di recuperare i dati
molto in fretta perché ora

735
00:31:07,120 --> 00:31:08,537
non devono conformarsi.

736
00:31:08,537 --> 00:31:11,620
Quando inserisco una riga in the Tracks
tavolo, o una riga nella tabella Album,

737
00:31:11,620 --> 00:31:13,110
Devo conformarsi a tale schema.

738
00:31:13,110 --> 00:31:18,060
Devo avere l'attributo o il
proprietà definita su quella tabella.

739
00:31:18,060 --> 00:31:20,480
Ognuno di essi,
quando inserisco quella riga.

740
00:31:20,480 --> 00:31:21,910
Questo non è il caso di NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Posso avere completamente diverso
immobili a ogni documento

742
00:31:24,440 --> 00:31:26,100
che inserisco nella collezione.

743
00:31:26,100 --> 00:31:30,480
Meccanismo in modo molto potente.

744
00:31:30,480 --> 00:31:32,852
Ed è davvero come si
ottimizzare il sistema.

745
00:31:32,852 --> 00:31:35,310
Perché ora quella query, invece
di unire tutte queste tabelle

746
00:31:35,310 --> 00:31:39,160
e l'esecuzione di una mezza dozzina di domande
per tirare indietro i dati che ho bisogno,

747
00:31:39,160 --> 00:31:40,890
Sto eseguendo una query.

748
00:31:40,890 --> 00:31:43,010
E sto iterazione
attraverso i risultati prefissati.

749
00:31:43,010 --> 00:31:46,512
ti dà un'idea
del potere di NoSQL.

750
00:31:46,512 --> 00:31:49,470
Ho intenzione di andare tipo di traverso qui
e parlare un po 'di questo.

751
00:31:49,470 --> 00:31:53,240
Questo è più del tipo
di marketing o tecnologici, quali

752
00:31:53,240 --> 00:31:55,660
la commercializzazione della tecnologia
tipo di discussione.

753
00:31:55,660 --> 00:31:58,672
Ma è importante capire
perché se guardiamo in alto

754
00:31:58,672 --> 00:32:00,380
qui in questo grafico,
quello che stiamo guardando

755
00:32:00,380 --> 00:32:04,030
è ciò che chiamiamo il
La tecnologia curva di hype.

756
00:32:04,030 --> 00:32:06,121
E ciò significa
novità entra in gioco.

757
00:32:06,121 --> 00:32:07,120
La gente pensa che sia grande.

758
00:32:07,120 --> 00:32:09,200
Ho risolto tutti i miei problemi.

759
00:32:09,200 --> 00:32:11,630
>> Questa potrebbe essere la fine
tutto, essere tutto a tutto.

760
00:32:11,630 --> 00:32:12,790
E iniziano ad usarlo.

761
00:32:12,790 --> 00:32:14,720
E dicono, questa roba non funziona.

762
00:32:14,720 --> 00:32:17,600
Non è giusto.

763
00:32:17,600 --> 00:32:19,105
La roba vecchia era meglio.

764
00:32:19,105 --> 00:32:21,230
E tornano a fare
le cose come erano.

765
00:32:21,230 --> 00:32:22,730
E poi alla fine
vanno, sai una cosa?

766
00:32:22,730 --> 00:32:24,040
Questa roba non è così male.

767
00:32:24,040 --> 00:32:26,192
Oh, è così che funziona.

768
00:32:26,192 --> 00:32:28,900
E una volta che capire come
opere, iniziano sempre meglio.

769
00:32:28,900 --> 00:32:32,050
>> E la cosa divertente su di esso
è, che tipo di linee fino a che

770
00:32:32,050 --> 00:32:34,300
che noi chiamiamo la curva Technology Adoption.

771
00:32:34,300 --> 00:32:36,910
Quindi, quello che succede è che abbiamo
alcuni trigger tecnologia sorta.

772
00:32:36,910 --> 00:32:39,100
Nel caso di banche dati,
è la pressione dei dati.

773
00:32:39,100 --> 00:32:42,200
Abbiamo parlato dei punti d'acqua alti
della pressione dei dati nel tempo.

774
00:32:42,200 --> 00:32:46,310
Quando la pressione che i dati colpisce un certo
punto, che è un trigger di tecnologia.

775
00:32:46,310 --> 00:32:47,830
>> Sta diventando troppo costoso.

776
00:32:47,830 --> 00:32:49,790
Ci vuole troppo tempo per elaborare i dati.

777
00:32:49,790 --> 00:32:50,890
Abbiamo bisogno di qualcosa di meglio.

778
00:32:50,890 --> 00:32:52,890
È possibile ottenere gli innovatori
là fuori in giro,

779
00:32:52,890 --> 00:32:55,050
cercando di scoprire qual è la soluzione.

780
00:32:55,050 --> 00:32:56,050
Qual è la nuova idea?

781
00:32:56,050 --> 00:32:58,170
>> Qual è il prossimo migliore
modo di fare questa cosa?

782
00:32:58,170 --> 00:32:59,530
E sono venuti fuori con qualcosa.

783
00:32:59,530 --> 00:33:03,140
E la gente con il vero dolore,
i ragazzi al bordo sanguinamento,

784
00:33:03,140 --> 00:33:06,390
faranno saltare tutto su di esso,
perché hanno bisogno di una risposta.

785
00:33:06,390 --> 00:33:09,690
Ora che cosa inevitabilmente happens-- e
sta accadendo in questo momento nel NoSQL.

786
00:33:09,690 --> 00:33:11,090
Lo vedo tutto il tempo.

787
00:33:11,090 --> 00:33:13,610
>> Quello che succede è inevitabilmente
persone iniziare a utilizzare il nuovo strumento

788
00:33:13,610 --> 00:33:15,490
allo stesso modo in cui ha utilizzato il vecchio strumento.

789
00:33:15,490 --> 00:33:17,854
E scoprono che
non funziona così bene.

790
00:33:17,854 --> 00:33:20,020
Non riesco a ricordare chi ero
parlando prima di oggi.

791
00:33:20,020 --> 00:33:22,080
Ma è come, quando la
martello pneumatico è stato inventato,

792
00:33:22,080 --> 00:33:24,621
la gente non ha oscillare sopra
la loro testa per distruggere il calcestruzzo.

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

794
00:33:27,360 --> 00:33:30,610
>> Ma questo è ciò che è
accadendo con NoSQL oggi.

795
00:33:30,610 --> 00:33:33,900
Se si cammina per maggior parte dei negozi,
stanno cercando di essere negozi NoSQL.

796
00:33:33,900 --> 00:33:36,510
Quello che stanno facendo è
stanno usando NoSQL,

797
00:33:36,510 --> 00:33:39,900
e stanno caricarlo
pieno di schema relazionale.

798
00:33:39,900 --> 00:33:41,630
Perché è così che
progettano database.

799
00:33:41,630 --> 00:33:44,046
E stanno chiedendo, perché è
non eseguire molto bene?

800
00:33:44,046 --> 00:33:45,230
Ragazzi, questa cosa puzza.

801
00:33:45,230 --> 00:33:49,900
Dovevo mantenere tutto il mio
unisce dentro-- è come, no, no.

802
00:33:49,900 --> 00:33:50,800
Mantenere unisce?

803
00:33:50,800 --> 00:33:52,430
Perché si stanno unendo i dati?

804
00:33:52,430 --> 00:33:54,350
Non si uniscono i dati in NoSQL.

805
00:33:54,350 --> 00:33:55,850
Si aggregare esso.

806
00:33:55,850 --> 00:34:00,690
>> Quindi, se si vuole evitare questo, imparare
come funziona lo strumento prima che realmente

807
00:34:00,690 --> 00:34:02,010
iniziare ad usarlo.

808
00:34:02,010 --> 00:34:04,860
Non cercare di utilizzare i nuovi strumenti del
Allo stesso modo si è utilizzato i vecchi strumenti.

809
00:34:04,860 --> 00:34:06,500
Stai andando ad avere una brutta esperienza.

810
00:34:06,500 --> 00:34:08,848
E ogni volta
questo è ciò che si tratta.

811
00:34:08,848 --> 00:34:11,389
Quando cominciamo a venire qui,
è perché la gente capito

812
00:34:11,389 --> 00:34:13,449
come utilizzare gli strumenti.

813
00:34:13,449 --> 00:34:16,250
>> Hanno fatto la stessa cosa quando
database relazionali sono stati inventati,

814
00:34:16,250 --> 00:34:17,969
e stavano sostituendo i file system.

815
00:34:17,969 --> 00:34:20,420
Hanno cercato di costruire sistemi di file
con i database relazionali

816
00:34:20,420 --> 00:34:22,159
perché è quello che la gente capisse.

817
00:34:22,159 --> 00:34:23,049
Non ha funzionato.

818
00:34:23,049 --> 00:34:26,090
Così la comprensione delle buone pratiche
della tecnologia si sta lavorando

819
00:34:26,090 --> 00:34:26,730
è enorme.

820
00:34:26,730 --> 00:34:29,870
Molto importante.

821
00:34:29,870 --> 00:34:32,440
>> Quindi stiamo per entrare in DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB è AWS di
completamente gestiti piattaforma NoSQL.

823
00:34:36,480 --> 00:34:37,719
Che cosa significa completamente gestiti significa?

824
00:34:37,719 --> 00:34:40,010
Significa che non è necessario
davvero preoccuparsi di nulla.

825
00:34:40,010 --> 00:34:42,060
>> Vieni a, si dice
noi, ho bisogno di un tavolo.

826
00:34:42,060 --> 00:34:43,409
Ha bisogno di questa capacità molto.

827
00:34:43,409 --> 00:34:47,300
Si preme il pulsante, e la fornitura noi
tutte le infrastrutture dietro la scena.

828
00:34:47,300 --> 00:34:48,310
Ora che è enorme.

829
00:34:48,310 --> 00:34:51,310
>> Perché quando si parla
su scala di un database,

830
00:34:51,310 --> 00:34:53,917
Cluster di dati NoSQL a
scala, petabyte in esecuzione,

831
00:34:53,917 --> 00:34:55,750
esecuzione di milioni di
transazioni al secondo,

832
00:34:55,750 --> 00:34:58,180
queste cose non sono piccoli grappoli.

833
00:34:58,180 --> 00:35:00,830
Stiamo parlando di migliaia di casi.

834
00:35:00,830 --> 00:35:04,480
Gestione delle migliaia di casi,
anche istanze virtuali,

835
00:35:04,480 --> 00:35:06,350
è un vero e proprio dolore nel culo.

836
00:35:06,350 --> 00:35:09,110
Voglio dire, penso ogni volta che un
patch del sistema operativo esce

837
00:35:09,110 --> 00:35:11,552
o una nuova versione del database.

838
00:35:11,552 --> 00:35:13,260
Cosa significa
a voi operativamente?

839
00:35:13,260 --> 00:35:16,330
Ciò significa che hai 1.200
i server che hanno bisogno di essere aggiornati.

840
00:35:16,330 --> 00:35:18,960
Ora anche con l'automazione,
che può richiedere molto tempo.

841
00:35:18,960 --> 00:35:21,480
Questo può causare un sacco di
emicranie operative,

842
00:35:21,480 --> 00:35:23,090
perché potrei avere servizi verso il basso.

843
00:35:23,090 --> 00:35:26,070
>> Come aggiorno questi database, io
potrebbe fare implementazioni verde blu

844
00:35:26,070 --> 00:35:29,420
dove ho implementano e aggiornano metà del mio
nodi, e quindi aggiornare l'altra metà.

845
00:35:29,420 --> 00:35:30,490
Prendete quelli giù.

846
00:35:30,490 --> 00:35:33,410
Così gestione dell'infrastruttura
scala è enormemente doloroso.

847
00:35:33,410 --> 00:35:36,210
E AWS prendere quel dolore fuori di esso.

848
00:35:36,210 --> 00:35:39,210
E i database NoSQL può
essere straordinariamente doloroso

849
00:35:39,210 --> 00:35:41,780
a causa del loro modo di scala.

850
00:35:41,780 --> 00:35:42,926
>> Scala orizzontale.

851
00:35:42,926 --> 00:35:45,550
Se si vuole ottenere un maggiore NoSQL
banca dati, comprate più nodi.

852
00:35:45,550 --> 00:35:48,660
Ogni nodo si acquista è
altro mal di testa operativa.

853
00:35:48,660 --> 00:35:50,830
Quindi cerchiamo qualcun altro farlo per voi.

854
00:35:50,830 --> 00:35:52,000
AWS può farlo.

855
00:35:52,000 --> 00:35:54,587
>> Sosteniamo valori chiave del documento.

856
00:35:54,587 --> 00:35:56,670
Ora non siamo andati troppo
in dall'altro tabella.

857
00:35:56,670 --> 00:35:58,750
C'è un sacco di diverso
sapori di NoSQL.

858
00:35:58,750 --> 00:36:02,670
Sono tutti i tipi di ottenere
munged insieme a questo punto.

859
00:36:02,670 --> 00:36:06,260
Potete guardare DynamoDB e dire di sì,
siamo entrambi un documento e un valore chiave

860
00:36:06,260 --> 00:36:08,412
memorizzare questo punto.

861
00:36:08,412 --> 00:36:10,620
E si può discutere le caratteristiche
di uno sopra l'altro.

862
00:36:10,620 --> 00:36:13,950
Per me, un sacco di questo è davvero sei
di una mezza dozzina dell'altro.

863
00:36:13,950 --> 00:36:18,710
Ognuna di queste tecnologie è un
La tecnologia raffinata e una buona soluzione.

864
00:36:18,710 --> 00:36:23,390
Non direi che MongoDB è migliore o
peggio di Couch, poi Cassandra,

865
00:36:23,390 --> 00:36:25,994
poi Dynamo, o viceversa.

866
00:36:25,994 --> 00:36:27,285
Voglio dire, questi sono solo opzioni.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> E 'veloce ed è
coerente a qualsiasi scala.

869
00:36:32,700 --> 00:36:36,210
Quindi questo è uno dei più grandi
bonus si ottiene con AWS.

870
00:36:36,210 --> 00:36:40,850
Con DynamoDB è la capacità
per ottenere un basso sola cifra

871
00:36:40,850 --> 00:36:44,040
latenza millisecondo in qualsiasi scala.

872
00:36:44,040 --> 00:36:45,720
E 'stato un obiettivo di progettazione del sistema.

873
00:36:45,720 --> 00:36:49,130
E abbiamo clienti che stanno facendo
milioni di transazioni al secondo.

874
00:36:49,130 --> 00:36:52,670
>> Ora andrò attraverso alcune di quelle
casi d'uso in pochi minuti qui.

875
00:36:52,670 --> 00:36:55,660
Accesso control-- integrato
abbiamo quello che chiamiamo

876
00:36:55,660 --> 00:36:57,920
Identity Access Management, o IAM.

877
00:36:57,920 --> 00:37:01,980
Essa permea ogni sistema,
ogni servizio che AWS offre.

878
00:37:01,980 --> 00:37:03,630
DynamoDB non fa eccezione.

879
00:37:03,630 --> 00:37:06,020
È possibile controllare l'accesso
ai tavoli DynamoDB.

880
00:37:06,020 --> 00:37:09,960
Attraverso tutti i tuoi account di AWS per
definizione dei ruoli di accesso e autorizzazioni

881
00:37:09,960 --> 00:37:12,140
nelle infrastrutture IAM.

882
00:37:12,140 --> 00:37:16,630
>> Ed è un componente chiave e integrale in
ciò che noi chiamiamo Event Driven Programming.

883
00:37:16,630 --> 00:37:19,056
Ora, questo è un nuovo paradigma.

884
00:37:19,056 --> 00:37:22,080
>> PUBBLICO: Come è il tuo tasso di vero
positivi contro falsi negativi

885
00:37:22,080 --> 00:37:24,052
sul vostro sistema di controllo accessi?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: veri positivi
contro falsi negativi?

887
00:37:26,260 --> 00:37:28,785
PUBBLICO: Tornando cosa
si dovrebbe essere di ritorno?

888
00:37:28,785 --> 00:37:33,720
A differenza di una volta in un mentre
non restituisce quando dovrebbe convalidare?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: non ho potuto dirvi che.

891
00:37:38,050 --> 00:37:40,140
Se c'è eventuali guasti
di sorta su questo,

892
00:37:40,140 --> 00:37:42,726
Io non sono la persona a chiedere
quella particolare domanda.

893
00:37:42,726 --> 00:37:43,850
Ma questa è una buona domanda.

894
00:37:43,850 --> 00:37:45,905
Sarei curioso di sapere
che io, in realtà.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> E così poi di nuovo, nuovo paradigma
è la programmazione event driven.

897
00:37:51,320 --> 00:37:55,160
Questa è l'idea che si può
distribuire applicazioni complesse che

898
00:37:55,160 --> 00:37:59,720
può funzionare molto, molto elevata scala
senza alcuna infrastruttura di sorta.

899
00:37:59,720 --> 00:38:02,120
Senza alcun fissa
infrastrutture di sorta.

900
00:38:02,120 --> 00:38:04,720
E parleremo un po '
su cosa significa come noi

901
00:38:04,720 --> 00:38:06,550
andare avanti per il prossimo paio di grafici.

902
00:38:06,550 --> 00:38:08,716
>> La prima cosa che faremo
è parleremo di tabelle.

903
00:38:08,716 --> 00:38:10,857
I tipi di dati API per Dynamo.

904
00:38:10,857 --> 00:38:13,190
E la prima cosa che si
notare quando si guarda a questo,

905
00:38:13,190 --> 00:38:17,930
se si ha familiarità con qualsiasi database,
database hanno davvero due tipi di API

906
00:38:17,930 --> 00:38:18,430
Lo definirei.

907
00:38:18,430 --> 00:38:21,570
O due serie di API.

908
00:38:21,570 --> 00:38:23,840
Uno di questi sarebbe
API amministrativo.

909
00:38:23,840 --> 00:38:26,710
>> Le cose che si prendono cura di
le funzioni del database.

910
00:38:26,710 --> 00:38:31,340
Configurazione del motore di archiviazione,
la creazione e l'aggiunta di tabelle.

911
00:38:31,340 --> 00:38:35,180
la creazione del database
cataloghi e le istanze.

912
00:38:35,180 --> 00:38:40,450
Questi things-- in DynamoDB, è
sono molto brevi, liste brevi.

913
00:38:40,450 --> 00:38:43,120
>> Quindi, in altre banche dati,
si potrebbe vedere decine

914
00:38:43,120 --> 00:38:45,680
di comandi, di tipo amministrativo
comandi, per la configurazione

915
00:38:45,680 --> 00:38:47,290
queste opzioni aggiuntive.

916
00:38:47,290 --> 00:38:51,234
In DynamoDB non hai bisogno di quelli, perché
non si configura il sistema, che facciamo.

917
00:38:51,234 --> 00:38:54,150
Quindi l'unica cosa che devi fare è
mi dice che formato tabella ho bisogno.

918
00:38:54,150 --> 00:38:55,660
Così si ottiene un
insieme limitato di comandi.

919
00:38:55,660 --> 00:38:58,618
>> Si ottiene un CREATE TABLE aggiornamento, Tavolo,
Elimina tabella, e Descrivere Tabella.

920
00:38:58,618 --> 00:39:01,150
Queste sono le uniche cose
il necessario per DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Non hai bisogno di una memoria
configurazione del motore.

922
00:39:03,294 --> 00:39:04,960
Non ho bisogno di preoccuparsi di replica.

923
00:39:04,960 --> 00:39:06,490
Non ho bisogno di preoccuparsi di sharding.

924
00:39:06,490 --> 00:39:07,800
>> Non ho bisogno di preoccuparsi
di tutto questo roba.

925
00:39:07,800 --> 00:39:08,740
Facciamo tutto per voi.

926
00:39:08,740 --> 00:39:11,867
Ecco, questo è un enorme quantità di overhead
che è appena alzato dal tuo piatto.

927
00:39:11,867 --> 00:39:13,200
Poi abbiamo gli operatori CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD è qualcosa quello che abbiamo
chiamare database che è

929
00:39:17,740 --> 00:39:19,860
Creare, Update, Delete operatori.

930
00:39:19,860 --> 00:39:24,180
Questi sono i vostri comuni
operazioni di database.

931
00:39:24,180 --> 00:39:31,299
Cose come mettere voce, diventano voce, aggiornamento
articoli, eliminare elementi, interrogare batch, scansione.

932
00:39:31,299 --> 00:39:32,840
Se si desidera acquisire l'intera tabella.

933
00:39:32,840 --> 00:39:34,220
Tirare tutto fuori dal tavolo.

934
00:39:34,220 --> 00:39:37,130
Una delle cose belle di DynamoDB
è che permette la scansione parallela.

935
00:39:37,130 --> 00:39:40,602
Così si può effettivamente farmi sapere quanti
le discussioni che si desidera eseguire su quella scansione.

936
00:39:40,602 --> 00:39:41,810
E possiamo eseguire quei fili.

937
00:39:41,810 --> 00:39:43,985
Possiamo girare che la scansione su
attraverso più thread

938
00:39:43,985 --> 00:39:49,060
in modo da poter acquisire l'intera tabella
spazio molto, molto rapidamente in DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> L'altra API che abbiamo è
quello che noi chiamiamo il nostro Stream API.

940
00:39:51,490 --> 00:39:52,940
Non stiamo andando a parlare troppo
molto di questo adesso.

941
00:39:52,940 --> 00:39:55,189
Ho alcuni contenuti più tardi
su nel mazzo su questo.

942
00:39:55,189 --> 00:39:59,910
Ma Streams è davvero un running--
pensare ad esso come il tempo ordinato

943
00:39:59,910 --> 00:40:01,274
e change log partizione.

944
00:40:01,274 --> 00:40:03,940
Tutto ciò che sta accadendo sul
la tabella mostra sul torrente.

945
00:40:03,940 --> 00:40:05,940
>> Ogni scrittura sul tavolo
si presenta sul torrente.

946
00:40:05,940 --> 00:40:08,370
Si può leggere quel flusso, e
si possono fare le cose con esso.

947
00:40:08,370 --> 00:40:10,150
Parleremo di ciò che
tipi di cose che si

948
00:40:10,150 --> 00:40:13,680
che fare con le cose come replica,
creazione di indici secondari.

949
00:40:13,680 --> 00:40:17,620
Tutti i tipi di davvero cool
cose che si possono fare con questo.

950
00:40:17,620 --> 00:40:19,150
>> Tipi di dati.

951
00:40:19,150 --> 00:40:23,320
In DynamoDB, sosteniamo entrambi chiave
valore e dati documento tipi.

952
00:40:23,320 --> 00:40:26,350
Sul lato sinistro dello schermo
qui, abbiamo i nostri tipi di base.

953
00:40:26,350 --> 00:40:27,230
Tipi di valore chiave.

954
00:40:27,230 --> 00:40:30,040
Si tratta di stringhe,
numeri e binari.

955
00:40:30,040 --> 00:40:31,640
>> Così solo tre tipi fondamentali.

956
00:40:31,640 --> 00:40:33,700
E allora si può avere insiemi di quelli.

957
00:40:33,700 --> 00:40:37,650
Una delle cose belle di NoSQL è
è possibile contenere le matrici come proprietà.

958
00:40:37,650 --> 00:40:42,050
E con DynamoDB è possibile contenere le matrici
di tipi di base come una proprietà di root.

959
00:40:42,050 --> 00:40:43,885
>> E poi ci sono i tipi di documento.

960
00:40:43,885 --> 00:40:45,510
Quante persone hanno familiarità con JSON?

961
00:40:45,510 --> 00:40:47,130
Voi ragazzi che hanno familiarità con JSON così tanto?

962
00:40:47,130 --> 00:40:49,380
Si tratta fondamentalmente di JavaScript,
Oggetto, Notation.

963
00:40:49,380 --> 00:40:52,510
Esso consente di fondamentalmente
definire una struttura gerarchica.

964
00:40:52,510 --> 00:40:58,107
>> È possibile memorizzare un documento JSON su
DynamoDB utilizzando componenti comuni

965
00:40:58,107 --> 00:41:00,940
o la costruzione di blocchi che sono disponibili
nella maggior parte dei linguaggi di programmazione.

966
00:41:00,940 --> 00:41:03,602
Quindi, se avete Java, sei
guardando le mappe ed elenchi.

967
00:41:03,602 --> 00:41:05,060
Posso creare oggetti che mappa.

968
00:41:05,060 --> 00:41:08,030
Una mappa come valori chiave
memorizzato come proprietà.

969
00:41:08,030 --> 00:41:10,890
E potrebbe avere liste di
valori all'interno di tali proprietà.

970
00:41:10,890 --> 00:41:13,490
È possibile memorizzare questo complesso
struttura gerarchica

971
00:41:13,490 --> 00:41:16,320
come un singolo attributo
di un elemento DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Così tavoli in DynamoDB, come la maggior parte
Database NoSQL, tabelle hanno elementi.

974
00:41:24,460 --> 00:41:26,469
In MongoDB si farebbe
chiamare questi documenti.

975
00:41:26,469 --> 00:41:27,760
E sarebbe la base divano.

976
00:41:27,760 --> 00:41:28,900
Anche un database di documenti.

977
00:41:28,900 --> 00:41:29,941
Si chiama questi documenti.

978
00:41:29,941 --> 00:41:32,930
Documenti o oggetti hanno attributi.

979
00:41:32,930 --> 00:41:35,850
Possono esistere attributi o
non esiste per l'oggetto.

980
00:41:35,850 --> 00:41:38,520
In DynamoDB, c'è
un attributo obbligatorio.

981
00:41:38,520 --> 00:41:43,880
Proprio come in un database relazionale,
si dispone di una chiave primaria nella tabella.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB ha ciò che noi chiamiamo una chiave hash.

983
00:41:46,010 --> 00:41:48,280
Tasto cancelletto deve essere univoco.

984
00:41:48,280 --> 00:41:52,580
Così, quando ho definire una tabella hash,
fondamentalmente quello che sto dicendo

985
00:41:52,580 --> 00:41:54,110
è ogni articolo avrà un tasto cancelletto.

986
00:41:54,110 --> 00:41:58,520
E ogni tasto cancelletto deve essere univoco.

987
00:41:58,520 --> 00:42:01,200
>> Ogni articolo è definito
da quella chiave hash univoco.

988
00:42:01,200 --> 00:42:02,940
E non ci può essere una sola.

989
00:42:02,940 --> 00:42:05,820
Questo va bene, ma spesso
quello che la gente ha bisogno

990
00:42:05,820 --> 00:42:08,170
è che vogliono è questo hash
la chiave per fare un po 'di più

991
00:42:08,170 --> 00:42:11,010
di essere solo un identificativo univoco.

992
00:42:11,010 --> 00:42:15,240
Spesso vogliamo usare quel tasto cancelletto
come il top secchio di aggregazione di livello.

993
00:42:15,240 --> 00:42:19,160
E il nostro modo di fare che è di
l'aggiunta di ciò che noi chiamiamo una chiave gamma.

994
00:42:19,160 --> 00:42:22,460
>> Quindi, se è solo un hash
tavolo, questo deve essere univoco.

995
00:42:22,460 --> 00:42:27,040
Se si tratta di una tabella di hash e la gamma, la
combinazione di hash e la gamma

996
00:42:27,040 --> 00:42:28,640
deve essere unico.

997
00:42:28,640 --> 00:42:30,110
Quindi, pensare in questo modo.

998
00:42:30,110 --> 00:42:32,140
Se ho un forum.

999
00:42:32,140 --> 00:42:39,010
E la forma ha argomenti, non ha
posts, e ha le risposte.

1000
00:42:39,010 --> 00:42:42,630
>> Così potrei avere un hash
chiave, che è l'ID argomento.

1001
00:42:42,630 --> 00:42:46,650
E potrei avere una chiave gamma,
che è l'ID risposta.

1002
00:42:46,650 --> 00:42:49,650
In questo modo se voglio ottenere tutte le
risposte per argomento specifico,

1003
00:42:49,650 --> 00:42:52,370
Posso solo interrogare l'hash.

1004
00:42:52,370 --> 00:42:55,190
Posso solo dire che mi danno tutto
gli elementi che hanno questo hash.

1005
00:42:55,190 --> 00:43:01,910
E ho intenzione di ottenere ogni domanda
o inviare per quel particolare argomento.

1006
00:43:01,910 --> 00:43:03,910
Queste aggregazioni di alto livello
sono molto importanti.

1007
00:43:03,910 --> 00:43:07,370
Sostengono l'accesso primario
modello dell'applicazione.

1008
00:43:07,370 --> 00:43:09,420
In generale, questo
è quello che vogliamo fare.

1009
00:43:09,420 --> 00:43:11,780
Vogliamo che table--
come si carica il tavolo,

1010
00:43:11,780 --> 00:43:16,640
vogliamo strutturare i dati
all'interno della tabella in modo tale

1011
00:43:16,640 --> 00:43:20,140
che l'applicazione può molto
recuperare rapidamente i risultati.

1012
00:43:20,140 --> 00:43:24,510
E spesso il modo per farlo è
di mantenere queste aggregazioni come noi

1013
00:43:24,510 --> 00:43:25,650
inserire i dati.

1014
00:43:25,650 --> 00:43:31,110
In sostanza, stiamo diffondendo i dati
nel secchio luminoso mentre entra.

1015
00:43:31,110 --> 00:43:35,210
>> Chiavi Gamma consentono hash me--
chiavi devono essere l'uguaglianza.

1016
00:43:35,210 --> 00:43:39,490
Quando mi interrogo un hash, devo dire
dammi un hash che è uguale a questo.

1017
00:43:39,490 --> 00:43:41,950
Quando mi interrogo un intervallo, io
può dire dammi una gamma

1018
00:43:41,950 --> 00:43:47,040
cioè usando qualsiasi tipo di
ricco operatore che sosteniamo.

1019
00:43:47,040 --> 00:43:49,200
Datemi tutti gli elementi per un hash.

1020
00:43:49,200 --> 00:43:52,520
E 'uguale, superiore,
meno, vuol cominciare,

1021
00:43:52,520 --> 00:43:54,145
e non esiste tra questi due valori?

1022
00:43:54,145 --> 00:43:56,811
Quindi questi tipi di query gamma
che siamo sempre interessati a.

1023
00:43:56,811 --> 00:43:59,650
Ora, una cosa su dati, quando
guardate l'accesso ai dati, quando

1024
00:43:59,650 --> 00:44:02,360
si accede ai dati, è
sempre di una aggregazione.

1025
00:44:02,360 --> 00:44:05,770
E 'sempre sui record
che sono legati a questo.

1026
00:44:05,770 --> 00:44:10,390
Dammi tutto qui that's-- tutto
le operazioni su questa carta di credito

1027
00:44:10,390 --> 00:44:12,500
per l'ultimo mese.

1028
00:44:12,500 --> 00:44:13,960
Questo è un aggregazione.

1029
00:44:13,960 --> 00:44:17,490
>> Quasi tutto quello che fai nella
database è una sorta di aggregazione.

1030
00:44:17,490 --> 00:44:21,530
Così poter essere in grado di definire
questi secchi e darvi questi vanno

1031
00:44:21,530 --> 00:44:24,950
attributi poter interrogare,
quelle ricche query sostengono molti,

1032
00:44:24,950 --> 00:44:27,165
molti, molti modelli di accesso alle applicazioni.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Così l'altra cosa il tasto cancelletto
non fa altro che ci dà un meccanismo

1035
00:44:35,000 --> 00:44:37,740
essere in grado di diffondere i dati intorno.

1036
00:44:37,740 --> 00:44:40,390
I database NoSQL funzionano meglio
quando i dati sono uniformemente

1037
00:44:40,390 --> 00:44:41,740
distribuiti in tutto il cluster.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Quante persone sono familiari
con algoritmi di hashing?

1040
00:44:47,050 --> 00:44:49,860
Quando dico hash e un hashing--
perché un algoritmo di hashing

1041
00:44:49,860 --> 00:44:54,140
è un modo di essere in grado di generare
un valore casuale da ogni valore dato.

1042
00:44:54,140 --> 00:44:59,300
Quindi, in questo caso particolare, la
algoritmo di hash che si corre è ND 5 basato.

1043
00:44:59,300 --> 00:45:04,765
>> E se ho un ID, e questo
è il mio tasto cancelletto, ho 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Quando faccio funzionare l'algoritmo di hash,
che sta per tornare indietro e dire,

1045
00:45:07,390 --> 00:45:10,800
bene 1 uguale 7B, 2
è uguale a 48, 3 è uguale a CD.

1046
00:45:10,800 --> 00:45:13,092
Sono diffusi in tutto lo spazio chiave.

1047
00:45:13,092 --> 00:45:14,050
E perché lo fai?

1048
00:45:14,050 --> 00:45:17,120
Perché questo fa in modo che posso
mettere i record su più nodi.

1049
00:45:17,120 --> 00:45:19,574
>> Se io sto facendo questo
incrementale, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
E ho una gamma hash che
viene eseguito in questo caso particolare,

1051
00:45:21,990 --> 00:45:24,785
un piccolo spazio di hash,
corre da 00 a FF,

1052
00:45:24,785 --> 00:45:27,951
poi i record stanno per entrare in
e che stanno andando ad andare 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
Che succede?

1055
00:45:31,800 --> 00:45:34,860
Ogni inserto sta allo stesso nodo.

1056
00:45:34,860 --> 00:45:36,070
Vedete cosa voglio dire?

1057
00:45:36,070 --> 00:45:40,910
>> Perché quando ho diviso lo spazio,
io stesi questi record in tutto,

1058
00:45:40,910 --> 00:45:45,950
e la partizione io, che sto per dire
partizione 1, dispone di spazi chiave 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partizione 2 è 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partizione 3 è AA a FF.

1061
00:45:49,780 --> 00:45:53,740
Quindi se sto utilizzando in modo lineare l'incremento
ID, si può vedere cosa sta succedendo.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, tutto fino a 54.

1063
00:45:57,410 --> 00:46:00,030
Così come io sto martellando l'
record nel sistema,

1064
00:46:00,030 --> 00:46:02,030
tutto finisce per andare a un nodo.

1065
00:46:02,030 --> 00:46:03,160
>> Questo non va bene.

1066
00:46:03,160 --> 00:46:04,820
Questo è un antipattern.

1067
00:46:04,820 --> 00:46:08,760
In MongoDB hanno questo problema
se non si utilizza una chiave hash.

1068
00:46:08,760 --> 00:46:11,325
MongoDB ti dà la possibilità
di hashing del valore della chiave.

1069
00:46:11,325 --> 00:46:13,950
Si dovrebbe sempre farlo, se
stai usando un hash di incremento

1070
00:46:13,950 --> 00:46:17,380
chiave in MongoDB, o sarai
inchiodare ogni scrittura per un nodo,

1071
00:46:17,380 --> 00:46:21,290
e sarete limitando
il vostro rendimento scrivere male.

1072
00:46:21,290 --> 00:46:24,896
>> PUBBLICO: È che A9 169 in decimale?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Sì, è
da qualche parte lì intorno.

1074
00:46:28,450 --> 00:46:29,950
A9, non lo so.

1075
00:46:29,950 --> 00:46:32,200
Dovreste ottenere il mio binario
di calcolatrice decimale.

1076
00:46:32,200 --> 00:46:34,237
Il mio cervello non funziona così.

1077
00:46:34,237 --> 00:46:36,320
PUBBLICO: Solo un rapido uno
dei vostri commenti Mongo.

1078
00:46:36,320 --> 00:46:39,530
Così è l'ID oggetto che viene
nativamente con Mongo farlo?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Ha fatto?

1081
00:46:41,470 --> 00:46:42,970
Se si specifica che.

1082
00:46:42,970 --> 00:46:45,030
Con MongoDB, si ha la possibilità.

1083
00:46:45,030 --> 00:46:48,930
È possibile specify-- ogni documento
MongoDB deve avere un ID di sottolineatura.

1084
00:46:48,930 --> 00:46:50,300
Questo è il valore unico.

1085
00:46:50,300 --> 00:46:55,240
>> In MongoDB è possibile specificare
se hash o meno.

1086
00:46:55,240 --> 00:46:56,490
Hanno appena ti danno la possibilità.

1087
00:46:56,490 --> 00:46:58,198
Se si sa che si tratta di
casuale, nessun problema.

1088
00:46:58,198 --> 00:46:59,640
Non c'è bisogno di farlo.

1089
00:46:59,640 --> 00:47:04,260
Se si sa che non è casuale, che
è incrementato, quindi effettuare l'hash.

1090
00:47:04,260 --> 00:47:06,880
>> Ora la cosa su
hashing, una volta che si hash

1091
00:47:06,880 --> 00:47:08,800
un value-- e questo è
Perché chiavi hash sono sempre

1092
00:47:08,800 --> 00:47:13,740
query uniche, perché ho cambiato
il valore, ora non posso fare una query gamma.

1093
00:47:13,740 --> 00:47:15,640
Non posso dire che è questo
tra questo o quello,

1094
00:47:15,640 --> 00:47:20,800
perché il valore di hash non sta andando
per essere equivalente al valore reale.

1095
00:47:20,800 --> 00:47:24,570
Quindi, quando si hash
chiave, è solo l'uguaglianza.

1096
00:47:24,570 --> 00:47:28,700
È per questo che in chiave hash DynamoDB
query sono sempre solo uguaglianza.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Così ora in una gamma key--
quando aggiungo che chiave gamma,

1099
00:47:34,700 --> 00:47:38,180
i record chiave gamma provengono tutti in e
essi vengono memorizzati sulla stessa partizione.

1100
00:47:38,180 --> 00:47:42,430
Quindi sono molto rapidamente, facilmente
recuperate perché questa è l'hash,

1101
00:47:42,430 --> 00:47:43,220
questa è la gamma.

1102
00:47:43,220 --> 00:47:44,928
E si vede tutto
con lo stesso hash

1103
00:47:44,928 --> 00:47:48,550
viene memorizzato sullo stesso spazio partizione.

1104
00:47:48,550 --> 00:47:53,889
È possibile utilizzare la chiave per aiutare gamma
individuare i dati vicino al suo genitore.

1105
00:47:53,889 --> 00:47:55,180
Così che cosa sto veramente facendo qui?

1106
00:47:55,180 --> 00:47:57,320
Questo è un uno a molti.

1107
00:47:57,320 --> 00:48:01,490
La relazione tra una chiave hash
e la chiave di gamma è uno a molti.

1108
00:48:01,490 --> 00:48:03,490
Posso avere più chiavi di hash.

1109
00:48:03,490 --> 00:48:07,610
Posso avere solo gamma multipla
chiavi all'interno di ogni tasto cancelletto.

1110
00:48:07,610 --> 00:48:11,910
>> L'hash definisce il genitore,
la gamma definisce i bambini.

1111
00:48:11,910 --> 00:48:15,240
Così si può vedere c'è analogico qui
tra il costrutto relazionale

1112
00:48:15,240 --> 00:48:18,840
e gli stessi tipi di
costruisce in NoSQL.

1113
00:48:18,840 --> 00:48:20,760
La gente parla di
NoSQL come non relazionali.

1114
00:48:20,760 --> 00:48:22,200
Non è non relazionali.

1115
00:48:22,200 --> 00:48:24,680
Data ha sempre rapporti.

1116
00:48:24,680 --> 00:48:28,172
Quei rapporti solo
sono modellati in modo diverso.

1117
00:48:28,172 --> 00:48:29,880
Parliamo un po '
po 'di durata.

1118
00:48:29,880 --> 00:48:34,860
Quando si scrive di DynamoDB, scrive
sono sempre a tre vie replicato.

1119
00:48:34,860 --> 00:48:37,550
Il che significa che abbiamo tre AZ.

1120
00:48:37,550 --> 00:48:39,160
AZ sono Zone Disponibilità.

1121
00:48:39,160 --> 00:48:43,430
Si può pensare a un Disponibilità
Zone come un data center

1122
00:48:43,430 --> 00:48:45,447
o un insieme di data center.

1123
00:48:45,447 --> 00:48:47,780
Queste cose sono geograficamente
isolati l'uno dall'altro

1124
00:48:47,780 --> 00:48:51,610
tra le diverse zone di faglia, attraverso
diverse reti elettriche e delle pianure alluvionali.

1125
00:48:51,610 --> 00:48:54,510
Un guasto in uno AZ non è
andando a prendere giù un altro.

1126
00:48:54,510 --> 00:48:56,890
Essi sono anche legate
insieme con fibra spenta.

1127
00:48:56,890 --> 00:49:01,240
Supporta un sub 1
latenza millisecondo tra AZS.

1128
00:49:01,240 --> 00:49:05,390
Così repliche dei dati in tempo reale
capace in AZS multiple.

1129
00:49:05,390 --> 00:49:09,990
>> E implementazioni spesso multi-AZ
soddisfare i requisiti di disponibilità elevata

1130
00:49:09,990 --> 00:49:12,930
della maggior parte delle organizzazioni aziendali.

1131
00:49:12,930 --> 00:49:16,139
Così DynamoDB si sviluppa
in tre AZS per impostazione predefinita.

1132
00:49:16,139 --> 00:49:19,430
Stiamo solo andando alla conoscenza della scrittura
quando due di questi tre nodi tornare

1133
00:49:19,430 --> 00:49:21,470
e dico, Sì, ho capito.

1134
00:49:21,470 --> 00:49:22,050
Perché?

1135
00:49:22,050 --> 00:49:25,950
Perché sul lato lettura siamo solo
andando a dare i dati indietro quando

1136
00:49:25,950 --> 00:49:27,570
abbiamo capito da due nodi.

1137
00:49:27,570 --> 00:49:30,490
>> Se sto replicare attraverso
tre, e sto leggendo da due,

1138
00:49:30,490 --> 00:49:32,840
Sono sempre garantito
avere almeno un

1139
00:49:32,840 --> 00:49:35,720
Di quelli legge per la
la maggior copia corrente di dati.

1140
00:49:35,720 --> 00:49:38,340
Questo è ciò che rende DynamoDB coerente.

1141
00:49:38,340 --> 00:49:42,450
Ora è possibile scegliere di girare
quelli coerenti letture fuori.

1142
00:49:42,450 --> 00:49:45,070
Nel qual caso ho intenzione di dire,
Leggo da un solo nodo.

1143
00:49:45,070 --> 00:49:47,430
E io non posso garantire che sta andando
essere i dati più recenti.

1144
00:49:47,430 --> 00:49:49,450
>> Quindi, se la scrittura è in arrivo,
essa non ha ancora replicato,

1145
00:49:49,450 --> 00:49:50,360
si sta andando ad ottenere quella copia.

1146
00:49:50,360 --> 00:49:52,220
Questa è una lettura finalmente coerente.

1147
00:49:52,220 --> 00:49:54,640
E di cosa si tratta è la metà del costo.

1148
00:49:54,640 --> 00:49:56,140
Quindi questo è qualcosa a cui pensare.

1149
00:49:56,140 --> 00:50:00,160
Quando stai leggendo fuori DynamoDB, e
stai impostando la vostra capacità di lettura

1150
00:50:00,160 --> 00:50:04,430
unità, se si sceglie alla fine
coerente legge, è molto più economico,

1151
00:50:04,430 --> 00:50:06,010
è circa la metà del costo.

1152
00:50:06,010 --> 00:50:09,342
>> E così di risparmiare denaro.

1153
00:50:09,342 --> 00:50:10,300
Ma questa è la vostra scelta.

1154
00:50:10,300 --> 00:50:12,925
Se si desidera una lettura coerente o
una lettura finalmente coerente.

1155
00:50:12,925 --> 00:50:15,720
Questo è qualcosa che si può scegliere.

1156
00:50:15,720 --> 00:50:17,659
>> Parliamo di indici.

1157
00:50:17,659 --> 00:50:19,450
Così abbiamo detto che
l'aggregazione di alto livello.

1158
00:50:19,450 --> 00:50:23,720
Abbiamo chiavi hash, e
abbiamo chiavi gamma.

1159
00:50:23,720 --> 00:50:24,320
Bello.

1160
00:50:24,320 --> 00:50:26,950
E questo è sul tavolo primario, io
ottenuto una chiave hash, ho ottenuto una chiave gamma.

1161
00:50:26,950 --> 00:50:27,783
>> Cosa significa?

1162
00:50:27,783 --> 00:50:30,410
Ho un attributo che io
possono eseguire query ricchi contro.

1163
00:50:30,410 --> 00:50:31,800
E 'la chiave di gamma.

1164
00:50:31,800 --> 00:50:35,530
Gli altri attributi su quel item--
Posso filtrare quegli attributi.

1165
00:50:35,530 --> 00:50:40,050
Ma non posso fare cose simili,
inizia con, o è superiore.

1166
00:50:40,050 --> 00:50:40,820
>> Come lo faccio?

1167
00:50:40,820 --> 00:50:42,860
Creo un indice.

1168
00:50:42,860 --> 00:50:45,340
Ci sono due tipi di
indici in DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Un indice è davvero
un'altra vista del tavolo.

1170
00:50:49,002 --> 00:50:50,490
E l'indice secondario locale.

1171
00:50:50,490 --> 00:50:51,781
>> La prima ne parleremo.

1172
00:50:51,781 --> 00:50:57,740
Così secondari locali sono coesistevano
sulla stessa partizione come i dati.

1173
00:50:57,740 --> 00:51:00,240
E come tali, sono
lo stesso nodo fisico.

1174
00:51:00,240 --> 00:51:01,780
Sono ciò che noi chiamiamo coerente.

1175
00:51:01,780 --> 00:51:04,599
Significato, essi riconosceranno
la scrittura insieme al tavolo.

1176
00:51:04,599 --> 00:51:06,890
Quando la scrittura entra,
scriveremo attraverso l'indice.

1177
00:51:06,890 --> 00:51:09,306
Scriveremo al tavolo,
e poi ci riconoscere.

1178
00:51:09,306 --> 00:51:10,490
Ecco, questo è coerente.

1179
00:51:10,490 --> 00:51:13,174
Una volta che la scrittura è stata
riconosciuto dalla tabella,

1180
00:51:13,174 --> 00:51:15,090
è garantito che il
indice secondario locali

1181
00:51:15,090 --> 00:51:18,380
avrà la stessa visione dei dati.

1182
00:51:18,380 --> 00:51:22,390
Ma quello che ti permettono di fare è
definire le chiavi alternative gamma.

1183
00:51:22,390 --> 00:51:25,260
>> È necessario utilizzare lo stesso hash
chiave come tabella primaria,

1184
00:51:25,260 --> 00:51:29,050
perché sono co-situato sulla
stessa partizione, e sono coerenti.

1185
00:51:29,050 --> 00:51:33,110
Ma posso creare un indice
con chiavi diverse gamma.

1186
00:51:33,110 --> 00:51:41,590
Così, per esempio, se avessi un produttore
che aveva un tavolo le parti prima proveniente in.

1187
00:51:41,590 --> 00:51:44,590
E pezzi grezzi entrano, e
stanno aggregati per il montaggio.

1188
00:51:44,590 --> 00:51:46,840
E forse c'è un richiamo.

1189
00:51:46,840 --> 00:51:50,240
>> Qualsiasi parte che è stato fatto da questo
produttore dopo tale data,

1190
00:51:50,240 --> 00:51:52,840
Ho bisogno di tirare da mia linea.

1191
00:51:52,840 --> 00:51:55,950
Posso girare un indice
che sarebbe in cerca,

1192
00:51:55,950 --> 00:52:00,760
aggregando alla data di
fabbricazione di quella parte particolare.

1193
00:52:00,760 --> 00:52:03,930
Quindi, se il mio tavolo livello superiore era
già hashed dal costruttore,

1194
00:52:03,930 --> 00:52:07,655
forse era organizzato su ID parte, io
in grado di creare un indice fuori quel tavolo

1195
00:52:07,655 --> 00:52:11,140
come hash dal costruttore e
a distanza alla data di costruzione.

1196
00:52:11,140 --> 00:52:14,490
E in questo modo potrei dire, tutto ciò che
è stato prodotto tra queste date,

1197
00:52:14,490 --> 00:52:16,804
Ho bisogno di tirare dalla linea.

1198
00:52:16,804 --> 00:52:18,220
Quindi questo è un indice secondario locale.

1199
00:52:18,220 --> 00:52:22,280
>> Questi hanno l'effetto di
limitando l'hash spazio chiave.

1200
00:52:22,280 --> 00:52:24,360
Perché loro co-esistiti
sullo stesso nodo di archiviazione,

1201
00:52:24,360 --> 00:52:26,860
limitano il tasto cancelletto
spazio a 10 gigabyte.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, sotto la
tavoli, si ripartisce

1203
00:52:28,950 --> 00:52:31,380
il vostro tavolo ogni 10 gigabyte.

1204
00:52:31,380 --> 00:52:34,760
Quando si mettono 10 giga di dati in, abbiamo
andare [PHH], e aggiungiamo un altro nodo.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Noi non dividere il LSI
attraverso più partizioni.

1207
00:52:42,070 --> 00:52:43,200
Ci divideremo il tavolo.

1208
00:52:43,200 --> 00:52:44,679
Ma noi non dividere il LSI.

1209
00:52:44,679 --> 00:52:46,470
Ecco, questo è qualcosa
importante capire

1210
00:52:46,470 --> 00:52:50,070
è se si sta facendo molto,
molto, molto grandi aggregazioni,

1211
00:52:50,070 --> 00:52:53,860
allora si sta andando ad essere limitato
a 10 gigabyte sul LSI.

1212
00:52:53,860 --> 00:52:56,640
>> Se questo è il caso, si può
utilizzare secondari globali.

1213
00:52:56,640 --> 00:52:58,630
Secondari globali sono
davvero un altro tavolo.

1214
00:52:58,630 --> 00:53:01,720
Esistono completamente fuori a
il lato della tabella primaria.

1215
00:53:01,720 --> 00:53:04,680
E loro mi permettono di trovare un
struttura completamente diversa.

1216
00:53:04,680 --> 00:53:08,010
Così pensare ad esso come viene inserito dati
in due diverse tabelle, strutturato

1217
00:53:08,010 --> 00:53:09,220
in due modi diversi.

1218
00:53:09,220 --> 00:53:11,360
>> Posso definire totalmente
diverso tasto cancelletto.

1219
00:53:11,360 --> 00:53:13,490
Posso definire totalmente
chiave diversa gamma.

1220
00:53:13,490 --> 00:53:15,941
E posso correre questo
completamente indipendente.

1221
00:53:15,941 --> 00:53:18,190
È un dato di fatto, ho
provisioning la mia capacità di lettura

1222
00:53:18,190 --> 00:53:21,090
e scrivere la mia capacità di
indici secondari globali

1223
00:53:21,090 --> 00:53:24,240
completamente indipendente
della mia tabella primaria.

1224
00:53:24,240 --> 00:53:26,640
Se io definisco tale indice, dico
esso quanto leggere e scrivere

1225
00:53:26,640 --> 00:53:28,610
capacità che sta per essere utilizzato.

1226
00:53:28,610 --> 00:53:31,490
>> E questo è separata
dalla mia tabella primaria.

1227
00:53:31,490 --> 00:53:35,240
Ora sia degli indici ci permettono di
definire non solo le chiavi di hash e gamma,

1228
00:53:35,240 --> 00:53:38,610
ma ci hanno permettono di
proiettare valori aggiuntivi.

1229
00:53:38,610 --> 00:53:44,950
Quindi, se voglio leggere l'indice,
e voglio ottenere un insieme di dati,

1230
00:53:44,950 --> 00:53:48,327
Non ho bisogno di tornare alla principale
tavolo per ottenere gli attributi aggiuntivi.

1231
00:53:48,327 --> 00:53:50,660
Posso proiettare quelli supplementari
attributi nella tabella

1232
00:53:50,660 --> 00:53:53,440
per supportare il tipo di accesso.

1233
00:53:53,440 --> 00:53:57,700
So che probabilmente stiamo ottenendo in qualche
davvero, really-- entrare le erbacce

1234
00:53:57,700 --> 00:53:58,910
qui su alcune di queste cose.

1235
00:53:58,910 --> 00:54:02,725
Ora ho avuto modo di andare alla deriva da questo.

1236
00:54:02,725 --> 00:54:07,320
>> PUBBLICO: [incomprensibile]
chiave --table dire era un hash?

1237
00:54:07,320 --> 00:54:08,840
L'hash originale?

1238
00:54:08,840 --> 00:54:09,340
Multi-stecche?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Sì.

1240
00:54:10,200 --> 00:54:11,070
Sì.

1241
00:54:11,070 --> 00:54:15,260
La chiave della tabella in fondo
punti di nuovo alla voce.

1242
00:54:15,260 --> 00:54:19,280
Così un indice è un indicatore di nuovo a
gli elementi originali sul tavolo.

1243
00:54:19,280 --> 00:54:22,910
Ora si può scegliere di costruire un
indice che ha solo la chiave della tabella,

1244
00:54:22,910 --> 00:54:24,840
e non altre proprietà.

1245
00:54:24,840 --> 00:54:26,570
E perché potrei farlo?

1246
00:54:26,570 --> 00:54:28,570
Beh, forse ho molto oggetti di grandi dimensioni.

1247
00:54:28,570 --> 00:54:31,660
>> Ho davvero bisogno solo di sapere which--
il mio modello di accesso potrebbe dire,

1248
00:54:31,660 --> 00:54:33,760
quali elementi contengono questa struttura?

1249
00:54:33,760 --> 00:54:35,780
Non c'è bisogno di restituire l'articolo.

1250
00:54:35,780 --> 00:54:37,800
Ho solo bisogno di sapere
quali elementi contengono.

1251
00:54:37,800 --> 00:54:40,700
Così si può costruire indici
che hanno solo la chiave della tabella.

1252
00:54:40,700 --> 00:54:43,360
>> Ma questo è in primo luogo ciò
un indice nel database è per.

1253
00:54:43,360 --> 00:54:46,280
E 'per poter rapidamente
identificare che registra,

1254
00:54:46,280 --> 00:54:49,470
le righe, che
elementi nella tabella hanno

1255
00:54:49,470 --> 00:54:51,080
le proprietà che sto cercando.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSI, così come funzionano?

1258
00:54:54,860 --> 00:54:58,340
GSI fondamentalmente sono asincroni.

1259
00:54:58,340 --> 00:55:02,570
L'aggiornamento viene in tabella,
tabella viene aggiornata in modo asincrono

1260
00:55:02,570 --> 00:55:03,720
tutti i tuoi GSI.

1261
00:55:03,720 --> 00:55:06,680
Questo è il motivo per cui sono GSI
infine coerente.

1262
00:55:06,680 --> 00:55:09,440
>> È importante notare che
quando si sta costruendo GSI,

1263
00:55:09,440 --> 00:55:13,110
e si capisce che si sta creando
un'altra dimensione di aggregation--

1264
00:55:13,110 --> 00:55:16,594
Ora diciamo che il buon esempio
qui è un produttore.

1265
00:55:16,594 --> 00:55:19,260
Penso che avrei potuto parlato
un produttore di dispositivi medici.

1266
00:55:19,260 --> 00:55:23,870
Produttori di dispositivi medici
hanno spesso parti serializzati.

1267
00:55:23,870 --> 00:55:28,070
Le parti che entrano in
una protesi all'anca tutto

1268
00:55:28,070 --> 00:55:30,200
avere un po 'di numero di serie su di loro.

1269
00:55:30,200 --> 00:55:33,584
E potrebbero avere milioni e
milioni e miliardi di pezzi

1270
00:55:33,584 --> 00:55:35,000
in tutti i dispositivi che spediscono.

1271
00:55:35,000 --> 00:55:37,440
Beh, hanno bisogno di aggregare sotto
diverse dimensioni, tutte le parti

1272
00:55:37,440 --> 00:55:39,520
in un assieme, tutti i
parti che sono state fatte

1273
00:55:39,520 --> 00:55:41,670
su una determinata linea, tutte
le parti in dotazione

1274
00:55:41,670 --> 00:55:44,620
in di un determinato produttore
in una certa data.

1275
00:55:44,620 --> 00:55:47,940
E queste aggregazioni volte
alzarsi in miliardi.

1276
00:55:47,940 --> 00:55:50,550
>> Così io lavoro con alcuni dei
questi ragazzi che soffrono

1277
00:55:50,550 --> 00:55:53,156
perché sono la creazione di
queste aggregazioni ginormous

1278
00:55:53,156 --> 00:55:54,280
nei loro indici secondari.

1279
00:55:54,280 --> 00:55:57,070
Potrebbero avere un pezzi grezzi
tavolo che si presenta come unico hash.

1280
00:55:57,070 --> 00:55:59,090
Ogni parte ha un numero di serie unico.

1281
00:55:59,090 --> 00:56:00,975
Io uso il numero di serie come l'hash.

1282
00:56:00,975 --> 00:56:01,600
È bellissimo.

1283
00:56:01,600 --> 00:56:04,160
Il mio tavolo dati grezzi si sviluppa
in tutto lo spazio chiave.

1284
00:56:04,160 --> 00:56:05,930
Il mio [? scrivere ?]
[? ingestione?] è impressionante.

1285
00:56:05,930 --> 00:56:07,876
Prendo un sacco di dati.

1286
00:56:07,876 --> 00:56:09,500
Poi quello che fanno è creano un GSI.

1287
00:56:09,500 --> 00:56:12,666
E io dico, sai cosa, ho bisogno di vedere
tutte le parti per questo produttore.

1288
00:56:12,666 --> 00:56:15,060
Beh, tutto ad un tratto sono
prendere un miliardo di righe,

1289
00:56:15,060 --> 00:56:17,550
e li roba su
un nodo, perché quando

1290
00:56:17,550 --> 00:56:21,170
Ho aggregato il
ID produttore come l'hash,

1291
00:56:21,170 --> 00:56:25,410
e il numero di parte come la gamma,
poi all'improvviso sono

1292
00:56:25,410 --> 00:56:30,530
mettendo un miliardo di parti in quello che
questo produttore mi ha consegnato.

1293
00:56:30,530 --> 00:56:34,447
>> Questo può causare un sacco
di pressione sul GSI,

1294
00:56:34,447 --> 00:56:36,030
ancora una volta, perché sto martellando un nodo.

1295
00:56:36,030 --> 00:56:38,350
Sto mettendo tutto questo
inserisce in un nodo.

1296
00:56:38,350 --> 00:56:40,940
E questo è un vero e proprio caso d'uso problematico.

1297
00:56:40,940 --> 00:56:43,479
Ora, ho ottenuto un buon progetto
modello per come si evita che.

1298
00:56:43,479 --> 00:56:45,770
E questo è uno dei problemi
che ho sempre lavorato con.

1299
00:56:45,770 --> 00:56:49,590
Ma ciò che accade, è il GSI può
Non avere una capacità di scrittura abbastanza

1300
00:56:49,590 --> 00:56:52,330
essere in grado di spingere tutti coloro
righe in un unico nodo.

1301
00:56:52,330 --> 00:56:55,390
E cosa succede allora è il
primaria, la tabella client,

1302
00:56:55,390 --> 00:57:00,180
la tabella primaria verrà strozzata
perché il GSI non può tenere il passo.

1303
00:57:00,180 --> 00:57:02,980
Quindi il mio tasso di inserimento sarà
cadere sul tavolo primario

1304
00:57:02,980 --> 00:57:06,230
come il mio GSI cerca di tenere il passo.

1305
00:57:06,230 --> 00:57:08,850
>> Va bene, così GSI di LSI di,
quale dovrei usare?

1306
00:57:08,850 --> 00:57:12,290
LSI di sono coerenti.

1307
00:57:12,290 --> 00:57:13,750
GSI di sono finalmente coerenti.

1308
00:57:13,750 --> 00:57:17,490
Se va bene, mi consiglia di utilizzare un
GSI, loro sono molto più flessibile.

1309
00:57:17,490 --> 00:57:20,270
LSI di può essere modellato come un GSI.

1310
00:57:20,270 --> 00:57:27,040
E se la dimensione dei dati per chiavi hash in
la vostra collezione supera i 10 gigabyte,

1311
00:57:27,040 --> 00:57:31,050
allora si sta andando a voler utilizzare tale
GSI perché è solo un limite rigido.

1312
00:57:31,050 --> 00:57:32,035
>> Va bene, così ridimensionamento.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Throughput in Dynamo DB, è
disposizione può [incomprensibile]

1315
00:57:37,460 --> 00:57:38,680
throughput di un tavolo.

1316
00:57:38,680 --> 00:57:42,740
Abbiamo clienti che hanno
provisioning 60 billion--

1317
00:57:42,740 --> 00:57:45,970
stanno facendo 60 miliardi di richieste, regolarmente
in esecuzione a oltre un milione di richieste

1318
00:57:45,970 --> 00:57:47,790
al secondo sulle nostre tavole.

1319
00:57:47,790 --> 00:57:50,360
Non c'è davvero nessun
limite teorico a quanto

1320
00:57:50,360 --> 00:57:53,730
e quanto velocemente il tavolo
può essere eseguito in Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Ci sono alcuni morbido
limiti sul tuo conto

1322
00:57:55,920 --> 00:57:58,170
che abbiamo messo in là così
che non si va pazzo.

1323
00:57:58,170 --> 00:58:00,070
Se si desidera più di
che, non è un problema.

1324
00:58:00,070 --> 00:58:00,820
Vieni dirci.

1325
00:58:00,820 --> 00:58:02,810
Faremo girare il quadrante.

1326
00:58:02,810 --> 00:58:08,210
>> Ogni account è limitato a un certo livello
in ogni servizio, appena fuori del blocco

1327
00:58:08,210 --> 00:58:11,920
così la gente non impazzire
si sono nei guai.

1328
00:58:11,920 --> 00:58:12,840
Nessun limite di dimensione.

1329
00:58:12,840 --> 00:58:14,940
È possibile inserire un qualsiasi numero
di oggetti su un tavolo.

1330
00:58:14,940 --> 00:58:17,620
Le dimensioni di un oggetto è
limitato a 400 kilobyte,

1331
00:58:17,620 --> 00:58:20,050
che non sarebbero oggetto gli attributi.

1332
00:58:20,050 --> 00:58:24,200
Quindi la somma di tutti gli attributi
è limitata a 400 kilobyte.

1333
00:58:24,200 --> 00:58:27,300
E poi di nuovo, abbiamo
quel piccolo problema LSI

1334
00:58:27,300 --> 00:58:30,405
con il limite di 10 gigabyte per hash.

1335
00:58:30,405 --> 00:58:33,280
PUBBLICO: Piccolo numero, mi manca
quello che mi stai dicendo, che è--

1336
00:58:33,280 --> 00:58:36,830
PUBBLICO: Oh, 400 kilobyte
è la dimensione massima per ogni articolo.

1337
00:58:36,830 --> 00:58:39,570
Quindi un elemento ha tutti gli attributi.

1338
00:58:39,570 --> 00:58:43,950
Così 400 k è la dimensione totale
di tale voce, 400 kilobyte.

1339
00:58:43,950 --> 00:58:46,170
Così, tutti gli attributi
combinati, tutti i dati

1340
00:58:46,170 --> 00:58:49,140
che è in tutti questi attributi,
arrotolato in una dimensione totale,

1341
00:58:49,140 --> 00:58:51,140
Attualmente il limite di elementi oggi è di 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Quindi il ridimensionamento di nuovo, raggiunto
attraverso il partizionamento.

1344
00:58:57,046 --> 00:58:58,920
Throughput provisioning
a livello di tabella.

1345
00:58:58,920 --> 00:59:00,160
E ci sono davvero due manopole.

1346
00:59:00,160 --> 00:59:02,400
Abbiamo letto di capacità
e scrivere la capacità.

1347
00:59:02,400 --> 00:59:05,530
>> Quindi questi sono regolati
indipendentemente l'uno dall'altro.

1348
00:59:05,530 --> 00:59:08,640
Misura di telecomando rigorosamente coerente legge.

1349
00:59:08,640 --> 00:59:13,005
OK, quindi se stai dicendo che voglio 1000
Telecomando di quelli sono strettamente coerenti,

1350
00:59:13,005 --> 00:59:14,130
queste sono letture coerenti.

1351
00:59:14,130 --> 00:59:17,130
Se dici che voglio
eventuale coerente legge,

1352
00:59:17,130 --> 00:59:19,402
è possibile disposizione 1.000
RCU di, si sta andando

1353
00:59:19,402 --> 00:59:21,840
per ottenere 2.000 alla fine
coerente legge.

1354
00:59:21,840 --> 00:59:25,940
E la metà del prezzo per chi
infine consisterà nella legge.

1355
00:59:25,940 --> 00:59:28,520
>> Ancora una volta, rettificato
indipendentemente l'uno dall'altro.

1356
00:59:28,520 --> 00:59:32,900
E hanno la throughput--
Se si consumano 100% del tuo telecomando,

1357
00:59:32,900 --> 00:59:35,960
non avete intenzione di influenzare il
disponibilità dei vostri diritti.

1358
00:59:35,960 --> 00:59:40,161
Quindi sono completamente
indipendenti l'uno dall'altro.

1359
00:59:40,161 --> 00:59:43,160
Va bene, quindi una delle cose che
Ho accennato brevemente è stato di limitazione.

1360
00:59:43,160 --> 00:59:44,320
Throttling è male.

1361
00:59:44,320 --> 00:59:47,311
Throttling indica male no SQL.

1362
00:59:47,311 --> 00:59:50,310
Ci sono cose che possiamo fare per aiutare
ad alleviare la limitazione che si

1363
00:59:50,310 --> 00:59:51,040
stanno vivendo.

1364
00:59:51,040 --> 00:59:53,240
Ma la soluzione migliore
per questo è diamo

1365
00:59:53,240 --> 00:59:58,000
uno sguardo a quello che stai facendo, perché
c'è un anti-modello in gioco qui.

1366
00:59:58,000 --> 01:00:02,140
>> Queste cose, cose come non uniforme
i carichi di lavoro, tasti di scelta rapida, divisori calde.

1367
01:00:02,140 --> 01:00:06,210
Mi colpisce un particolare spazio chiave
molto difficile per qualche ragione particolare.

1368
01:00:06,210 --> 01:00:07,080
Perché sto facendo questo?

1369
01:00:07,080 --> 01:00:08,710
Cerchiamo di capirlo.

1370
01:00:08,710 --> 01:00:10,427
Sto mescolare i miei dati a caldo con i dati freddi.

1371
01:00:10,427 --> 01:00:12,510
Sto lasciando mie tabelle ottenere
enorme, ma non c'è davvero

1372
01:00:12,510 --> 01:00:15,970
solo un sottoinsieme dei dati
che è davvero interessante per me.

1373
01:00:15,970 --> 01:00:20,290
Così, per dati di log, per esempio, molti
clienti, che ricevono i dati di log ogni giorno.

1374
01:00:20,290 --> 01:00:22,490
Hanno ottenuto una quantità enorme di dati di log.

1375
01:00:22,490 --> 01:00:25,940
>> Se sei solo il dumping tutto quel registro
i dati in un unico grande tavolo, nel corso del tempo

1376
01:00:25,940 --> 01:00:28,070
quel tavolo sta per ottenere massiccia.

1377
01:00:28,070 --> 01:00:30,950
Ma sono davvero interessati solo a
ultime 24 ore, gli ultimi sette giorni,

1378
01:00:30,950 --> 01:00:31,659
negli ultimi 30 giorni.

1379
01:00:31,659 --> 01:00:34,074
Qualunque sia la finestra di tempo
che io sono interessato a guardare

1380
01:00:34,074 --> 01:00:37,010
per l'evento che mi preoccupa, o
l'evento che è interessante per me,

1381
01:00:37,010 --> 01:00:39,540
questa è l'unica volta che ho bisogno della finestra.

1382
01:00:39,540 --> 01:00:42,470
Allora perché sto mettendo 10 anni
vale la pena di dati di registro nella tabella?

1383
01:00:42,470 --> 01:00:45,030
Che cosa è che causa
il tavolo il frammento.

1384
01:00:45,030 --> 01:00:45,880
>> Diventa enorme.

1385
01:00:45,880 --> 01:00:48,340
Si comincia diffondendo
attraverso migliaia di nodi.

1386
01:00:48,340 --> 01:00:51,380
E dal momento che la capacità
è così basso, sei

1387
01:00:51,380 --> 01:00:54,090
in realtà rate limiting su ogni
uno di quei singoli nodi.

1388
01:00:54,090 --> 01:00:57,120
Quindi cominciamo a guardare come
facciamo rotolare quel tavolo.

1389
01:00:57,120 --> 01:01:01,502
Come gestire i dati che un po '
meglio evitare questi problemi.

1390
01:01:01,502 --> 01:01:02,710
E questo cosa assomigliano?

1391
01:01:02,710 --> 01:01:04,370
Questo è ciò che sembra.

1392
01:01:04,370 --> 01:01:06,790
Questo è ciò che male NoSQL assomiglia.

1393
01:01:06,790 --> 01:01:07,830
>> Ho qui un tasto di scelta rapida.

1394
01:01:07,830 --> 01:01:10,246
Se si guarda dal lato qui,
queste sono tutte le mie partizioni.

1395
01:01:10,246 --> 01:01:12,630
Ho 16 partizioni qui
su questo particolare database.

1396
01:01:12,630 --> 01:01:13,630
Facciamo questo per tutto il tempo.

1397
01:01:13,630 --> 01:01:15,046
Corro questo per i clienti di tutto il tempo.

1398
01:01:15,046 --> 01:01:16,550
Si chiama la mappa di calore.

1399
01:01:16,550 --> 01:01:20,590
Mappa di calore mi dice come sei
accedere al proprio spazio delle chiavi.

1400
01:01:20,590 --> 01:01:23,700
E ciò che questo mi sta dicendo è
che ci sia un particolare hash

1401
01:01:23,700 --> 01:01:26,330
che questo ragazzo piace un
lotto terribile, perché è

1402
01:01:26,330 --> 01:01:28,250
colpisce davvero, davvero difficile.

1403
01:01:28,250 --> 01:01:29,260
>> Così il blu è bello.

1404
01:01:29,260 --> 01:01:29,900
Ci piace blu.

1405
01:01:29,900 --> 01:01:30,720
Non ci piace rosso.

1406
01:01:30,720 --> 01:01:33,120
Red dove la pressione
si alza a 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, ora si sta andando ad essere strozzato.

1408
01:01:35,560 --> 01:01:39,030
Quindi, ogni volta che vedete tutte le linee rosse come
questo-- e non è solo Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
tutti i database NoSQL ha questo problema.

1410
01:01:41,630 --> 01:01:44,640
Ci sono anti-pattern che possono
guidare questi tipi di condizioni.

1411
01:01:44,640 --> 01:01:49,070
Quello che faccio è che lavoro con i clienti
per alleviare queste condizioni.

1412
01:01:49,070 --> 01:01:51,840
>> E questo cosa assomigliano?

1413
01:01:51,840 --> 01:01:54,260
E questo è sempre il più
di rendimento Dynamo DB,

1414
01:01:54,260 --> 01:01:56,176
ma è davvero sempre
il massimo da NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Questo non è limitata a dinamo.

1416
01:01:58,740 --> 01:02:02,050
Questo è io definitely--
abituato a lavorare a Mongo.

1417
01:02:02,050 --> 01:02:04,090
Ho familiarità con molte piattaforme NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Ognuno ha questi tipi
di problemi di tasti di scelta rapida.

1419
01:02:06,830 --> 01:02:10,320
Per ottenere il massimo da qualsiasi NoSQL
base di dati, in particolare Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
si desidera creare le tabelle
dove l'elemento chiave hash ha

1421
01:02:13,320 --> 01:02:18,590
un gran numero di valori distinti,
un alto grado di cardinalità.

1422
01:02:18,590 --> 01:02:22,530
Perché significa che sto scrivendo
a un sacco di differenti secchi.

1423
01:02:22,530 --> 01:02:24,870
>> I più secchi Sono
la scrittura, più è probabile

1424
01:02:24,870 --> 01:02:29,100
Sono a diffondere quel carico scrittura o
Leggere caricare fuori attraverso più nodi,

1425
01:02:29,100 --> 01:02:33,560
più è probabile che io sono di avere una
throughput elevato sul tavolo.

1426
01:02:33,560 --> 01:02:37,440
E poi voglio i valori siano
richiesto abbastanza uniforme nel tempo

1427
01:02:37,440 --> 01:02:39,430
e più uniforme possibile in modo casuale.

1428
01:02:39,430 --> 01:02:42,410
Beh, questo è abbastanza interessante,
perché non posso davvero

1429
01:02:42,410 --> 01:02:43,960
controllo quando gli utenti arrivano.

1430
01:02:43,960 --> 01:02:47,645
Quindi, basti dire, se abbiamo diffuso
cose fuori tutto lo spazio delle chiavi,

1431
01:02:47,645 --> 01:02:49,270
Probabilmente ci andremo più in forma.

1432
01:02:49,270 --> 01:02:51,522
>> C'è una certa
quantità di tempo di consegna

1433
01:02:51,522 --> 01:02:53,230
che non si sta andando
per essere in grado di controllo.

1434
01:02:53,230 --> 01:02:55,438
Ma questi sono davvero il
due dimensioni che abbiamo,

1435
01:02:55,438 --> 01:02:58,800
spazio, l'accesso in modo uniforme
spread, il tempo, le richieste

1436
01:02:58,800 --> 01:03:01,040
di arrivare distribuiti uniformemente nel tempo.

1437
01:03:01,040 --> 01:03:03,110
E se quei due
condizioni sono soddisfatte,

1438
01:03:03,110 --> 01:03:05,610
allora questo è quello che è
andare a guardare come.

1439
01:03:05,610 --> 01:03:07,890
Questo è molto più bello.

1440
01:03:07,890 --> 01:03:08,890
Siamo davvero felici qui.

1441
01:03:08,890 --> 01:03:10,432
Abbiamo un modello di accesso molto anche.

1442
01:03:10,432 --> 01:03:13,098
Sì, forse stai ricevendo un
poca pressione ogni tanto,

1443
01:03:13,098 --> 01:03:14,830
ma niente di veramente troppo estesa.

1444
01:03:14,830 --> 01:03:17,660
Quindi è sorprendente quante volte,
quando lavoro con i clienti,

1445
01:03:17,660 --> 01:03:20,670
quel primo grafico con il grande rosso
bar e tutto ciò che esso è brutto giallo

1446
01:03:20,670 --> 01:03:23,147
tutto il posto, abbiamo
ottenere fatto con l'esercizio

1447
01:03:23,147 --> 01:03:24,980
dopo un paio di mesi
di ri-architettura,

1448
01:03:24,980 --> 01:03:28,050
sono in esecuzione la stessa identica
carico di lavoro presso lo stesso esatto carico.

1449
01:03:28,050 --> 01:03:30,140
E questo è ciò che sta cercando come ora.

1450
01:03:30,140 --> 01:03:36,600
Quindi, quello che si ottiene con NoSQL è un
schema di dati che è assolutamente

1451
01:03:36,600 --> 01:03:38,510
legata al tipo di accesso.

1452
01:03:38,510 --> 01:03:42,170
>> Ed è possibile ottimizzare tale schema dati
per supportare quel modello di accesso.

1453
01:03:42,170 --> 01:03:45,490
Se non lo fai, allora si sta andando
vedere quei tipi di problemi

1454
01:03:45,490 --> 01:03:46,710
con questi tasti di scelta rapida.

1455
01:03:46,710 --> 01:03:50,518
>> PUBBLICO: Bene, inevitabilmente alcuni posti
stanno per essere più caldo rispetto ad altri.

1456
01:03:50,518 --> 01:03:51,450
>> RICK Houlihan: Sempre.

1457
01:03:51,450 --> 01:03:51,960
Sempre.

1458
01:03:51,960 --> 01:03:54,620
Sì, voglio dire c'è sempre
a-- e ancora una volta, non c'è

1459
01:03:54,620 --> 01:03:56,980
alcuni modelli di progettazione ce la caveremo
che parlerà di come si affronta

1460
01:03:56,980 --> 01:03:58,480
con questi super-grandi aggregazioni.

1461
01:03:58,480 --> 01:04:01,260
Voglio dire, ho avuto modo di avere loro,
come possiamo trattare con loro?

1462
01:04:01,260 --> 01:04:03,760
Ho ottenuto un buon caso d'uso
che parleremo per questo.

1463
01:04:03,760 --> 01:04:05,940
>> Va bene, quindi cerchiamo di parlare
circa alcuni clienti ora.

1464
01:04:05,940 --> 01:04:06,950
Questi ragazzi sono AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Non so se siete
familiarità con AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Probabilmente li vede
molto sul browser.

1467
01:04:10,781 --> 01:04:14,230
Sono annunci re-targeting, sono
il più grande business degli annunci riorientamento

1468
01:04:14,230 --> 01:04:14,940
là fuori.

1469
01:04:14,940 --> 01:04:17,792
Normalmente passano regolarmente su
60 miliardi di transazioni al giorno.

1470
01:04:17,792 --> 01:04:20,000
Stanno facendo più di un milione
transazioni al secondo.

1471
01:04:20,000 --> 01:04:22,660
Hanno una bella semplice tavolo
la struttura, la tabella più trafficato.

1472
01:04:22,660 --> 01:04:26,450
E 'fondamentalmente solo una
chiave hash è il cookie,

1473
01:04:26,450 --> 01:04:29,010
la gamma è il demografica
categoria, e poi

1474
01:04:29,010 --> 01:04:31,220
il terzo attributo è il punteggio.

1475
01:04:31,220 --> 01:04:33,720
>> Quindi tutti noi abbiamo i biscotti in
il nostro browser da questi ragazzi.

1476
01:04:33,720 --> 01:04:35,900
E quando si va a una
merchant partecipanti,

1477
01:04:35,900 --> 01:04:39,390
essi fondamentalmente punteggio attraverso
diverse categorie demografiche.

1478
01:04:39,390 --> 01:04:42,070
Quando vai a un sito web e
dici che voglio vedere questo ad--

1479
01:04:42,070 --> 01:04:44,920
o in fondo non si dice che--
ma quando si va al sito web

1480
01:04:44,920 --> 01:04:47,550
dicono che si vuole vedere questo annuncio.

1481
01:04:47,550 --> 01:04:49,370
E vanno ottenere tale annuncio da AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll si guarda in alto sul loro tavolo.

1483
01:04:51,130 --> 01:04:52,115
Trovano il cookie.

1484
01:04:52,115 --> 01:04:53,990
Gli inserzionisti che raccontano
li, voglio qualcuno

1485
01:04:53,990 --> 01:04:58,632
chi è di mezza età,
40-year-old man, in sport.

1486
01:04:58,632 --> 01:05:01,590
E ti segnano in quei dati demografici
e decidono se

1487
01:05:01,590 --> 01:05:02,740
questo è un buon annuncio per voi.

1488
01:05:02,740 --> 01:05:10,330
>> Ora hanno un SLA con
i loro fornitori di pubblicità

1489
01:05:10,330 --> 01:05:14,510
per fornire sub-10 millisecondi
risposta su ogni singola richiesta.

1490
01:05:14,510 --> 01:05:16,090
Così stanno usando Dynamo DB per questo.

1491
01:05:16,090 --> 01:05:18,131
Ci stanno colpendo un
milioni di richieste al secondo.

1492
01:05:18,131 --> 01:05:21,120
Sono in grado di fare tutto il loro
ricerche, triage tutti i dati,

1493
01:05:21,120 --> 01:05:26,130
e ottenere che puntano aggiungere di nuovo a quel
l'inserzionista in meno di 10 millisecondi.

1494
01:05:26,130 --> 01:05:29,800
E 'davvero davvero fenomenale
attuazione che hanno.

1495
01:05:29,800 --> 01:05:36,210
>> Questi ragazzi actually--
sono questi i ragazzi.

1496
01:05:36,210 --> 01:05:38,010
Io non sono sicuro se è questi ragazzi.

1497
01:05:38,010 --> 01:05:40,127
Potrebbe essere questi ragazzi.

1498
01:05:40,127 --> 01:05:42,210
Fondamentalmente noi-- detto no,
non credo che loro era.

1499
01:05:42,210 --> 01:05:43,000
Penso che sia stato qualcun altro.

1500
01:05:43,000 --> 01:05:44,750
Stavo lavorando con un
cliente che mi ha detto

1501
01:05:44,750 --> 01:05:47,040
che ora che hanno
andato a Dynamo DB, sono

1502
01:05:47,040 --> 01:05:50,330
spendere più soldi per spuntini per
il loro team di sviluppo di ogni mese

1503
01:05:50,330 --> 01:05:52,886
quello che spendono in loro database.

1504
01:05:52,886 --> 01:05:54,760
Quindi ti do un
idea dei risparmi sui costi

1505
01:05:54,760 --> 01:05:57,889
che si può ottenere in Dynamo DB è enorme.

1506
01:05:57,889 --> 01:05:59,430
Va bene, dropcam è un'altra società.

1507
01:05:59,430 --> 01:06:02,138
Questi tipo una specie di-- se si pensa
di internet delle cose, dropcam

1508
01:06:02,138 --> 01:06:05,150
è fondamentalmente video di sicurezza Internet.

1509
01:06:05,150 --> 01:06:06,660
Hai messo la macchina fotografica là fuori.

1510
01:06:06,660 --> 01:06:08,180
Fotocamera dispone di un sensore di movimento.

1511
01:06:08,180 --> 01:06:10,290
Qualcuno arriva,
innesca un cue point.

1512
01:06:10,290 --> 01:06:13,540
Camera avvia la registrazione per un po 'fino a
non rileva più alcun movimento.

1513
01:06:13,540 --> 01:06:15,310
Mette quel video su internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam era una società che è
fondamentalmente passati a Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
perché erano vivendo
enormi dolori della crescita.

1516
01:06:22,200 --> 01:06:25,820
E quello che ci hanno detto,
petabyte improvvisamente di dati.

1517
01:06:25,820 --> 01:06:28,070
Non avevano idea loro servizio
sarebbe così tanto successo.

1518
01:06:28,070 --> 01:06:32,310
Altri video in entrata di YouTube
è ciò che questi ragazzi stanno ottenendo.

1519
01:06:32,310 --> 01:06:36,780
Usano DynamoDB seguire tutto il
metadati su tutti i loro punti chiave video.

1520
01:06:36,780 --> 01:06:40,282
>> Così hanno secchi S3 Spingono
tutti gli artefatti binari in.

1521
01:06:40,282 --> 01:06:41,990
E poi hanno
Record Dynamo DB

1522
01:06:41,990 --> 01:06:44,070
indicare le persone a quegli S3 tre oggetti.

1523
01:06:44,070 --> 01:06:47,070
Quando hanno bisogno di guardare un video,
guardano il record di Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Fatto clic sul collegamento.

1525
01:06:47,903 --> 01:06:49,770
Essi tirare giù il video da S3.

1526
01:06:49,770 --> 01:06:51,590
Ecco, questo è ciò che questo tipo di assomiglia.

1527
01:06:51,590 --> 01:06:53,580
E questo è direttamente dal loro squadra.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB riduce la loro
termine di consegna per eventi video

1529
01:06:56,010 --> 01:06:57,590
da cinque a 10 secondi.

1530
01:06:57,590 --> 01:07:00,470
Nel loro negozio relazionale vecchio,
hanno usato per andare ed eseguire

1531
01:07:00,470 --> 01:07:03,780
più query complesse a figura
quale video per tirare giù,

1532
01:07:03,780 --> 01:07:06,690
a meno di 50 millisecondi.

1533
01:07:06,690 --> 01:07:08,990
Quindi è incredibile, incredibile
quanto le prestazioni

1534
01:07:08,990 --> 01:07:12,990
si può ottenere quando si ottimizza e
si sintonizza il database sottostante

1535
01:07:12,990 --> 01:07:15,110
per supportare il tipo di accesso.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, questi ragazzi, di cosa si tratta,
Fruit Ninja Credo che è la loro cosa.

1537
01:07:20,500 --> 01:07:22,590
Che tutte le corse su Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
E questi ragazzi, sono una grande
team di sviluppo, grande sviluppo

1539
01:07:26,810 --> 01:07:27,670
negozio.

1540
01:07:27,670 --> 01:07:29,364
>> Non è una buona squadra ops.

1541
01:07:29,364 --> 01:07:31,280
Non avevano un sacco
delle risorse di funzionamento.

1542
01:07:31,280 --> 01:07:33,940
Loro stavano lottando cercando di mantenere
la loro infrastruttura applicativa su

1543
01:07:33,940 --> 01:07:34,290
e funzionante.

1544
01:07:34,290 --> 01:07:35,000
Sono venuti da noi.

1545
01:07:35,000 --> 01:07:36,251
Hanno guardato che la DB Dynamo.

1546
01:07:36,251 --> 01:07:37,291
Hanno detto, questo è per noi.

1547
01:07:37,291 --> 01:07:39,470
Hanno costruito la loro intera
framework applicazione su di esso.

1548
01:07:39,470 --> 01:07:43,640
Alcuni commenti veramente bello qui
dal team sulla loro capacità

1549
01:07:43,640 --> 01:07:46,800
per ora concentrarsi sulla costruzione
il gioco e non

1550
01:07:46,800 --> 01:07:49,010
dover mantenere la
infrastrutture, che

1551
01:07:49,010 --> 01:07:51,910
stava diventando una quantità enorme
di overhead per la loro squadra.

1552
01:07:51,910 --> 01:07:56,170
Quindi questo è qualcosa che-- la
beneficio che si ottiene da Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Va bene, entrare in
modellazione dei dati qui.

1554
01:08:00,930 --> 01:08:03,440
E abbiamo parlato un po '
questo per uno, uno a molti,

1555
01:08:03,440 --> 01:08:05,060
e molti a molti rapporti di tipo.

1556
01:08:05,060 --> 01:08:07,630
E come si fa a mantenere quelli in Dynamo.

1557
01:08:07,630 --> 01:08:10,500
In Dynamo DB usiamo
indici, in generale,

1558
01:08:10,500 --> 01:08:12,910
per ruotare i dati da
un sapore all'altro.

1559
01:08:12,910 --> 01:08:15,210
Chiavi hash, chiavi gamma e indici.

1560
01:08:15,210 --> 01:08:18,540
>> In questo particolare
ad esempio, come la maggior parte degli stati

1561
01:08:18,540 --> 01:08:23,802
hanno un obbligo di licenza che
solo una licenza di pilota di a persona.

1562
01:08:23,802 --> 01:08:26,510
Non si può andare a prendere due guidatore
licenze nello stato di Boston.

1563
01:08:26,510 --> 01:08:27,500
Io non posso farlo in Texas.

1564
01:08:27,500 --> 01:08:28,708
Questo è il tipo di così com'è.

1565
01:08:28,708 --> 01:08:32,779
E così al DMV, abbiamo le ricerche, abbiamo
voler cercare la patente di guida

1566
01:08:32,779 --> 01:08:35,180
per il numero di previdenza sociale.

1567
01:08:35,180 --> 01:08:39,990
Voglio guardare i dati utente
dal numero della patente di guida.

1568
01:08:39,990 --> 01:08:43,620
>> Così potremmo avere tavolo di un utente che
ha una chiave hash sul numero di serie,

1569
01:08:43,620 --> 01:08:47,830
o il numero di previdenza sociale, e
vari attributi definiti sulla voce.

1570
01:08:47,830 --> 01:08:49,859
Ora su quel tavolo io
potrebbe definire un GSI che

1571
01:08:49,859 --> 01:08:53,370
flip che in giro che dice che voglio
una chiave hash sulla licenza e poi

1572
01:08:53,370 --> 01:08:54,252
tutte le altre voci.

1573
01:08:54,252 --> 01:08:57,210
Ora, se voglio interrogare e trovare il
numero di licenza per un dato sociale

1574
01:08:57,210 --> 01:08:59,609
Numero di sicurezza, non posso
interrogare la tabella principale.

1575
01:08:59,609 --> 01:09:02,130
>> Se voglio interrogare e voglio
per ottenere la sicurezza sociale

1576
01:09:02,130 --> 01:09:05,735
numero o altri attributi di un
numero di licenza, posso interrogare il GSI.

1577
01:09:05,735 --> 01:09:08,689
Questo modello è che uno
una relazione.

1578
01:09:08,689 --> 01:09:12,460
Basta un semplice GSI,
capovolgere le cose intorno.

1579
01:09:12,460 --> 01:09:13,979
Ora, parlare di uno a molti.

1580
01:09:13,979 --> 01:09:16,450
Uno a molti è fondamentalmente
la chiave gamma hash.

1581
01:09:16,450 --> 01:09:20,510
Dove abbiamo un sacco con questo
caso d'uso è dati di monitoraggio.

1582
01:09:20,510 --> 01:09:23,880
Dati Monitor è disponibile in regolare
intervallo, come internet delle cose.

1583
01:09:23,880 --> 01:09:26,890
Siamo sempre tutti questi
record proveniente in tutto il tempo.

1584
01:09:26,890 --> 01:09:31,420
>> E voglio trovare tutte le letture
tra un determinato periodo di tempo.

1585
01:09:31,420 --> 01:09:34,220
E 'una domanda molto comune in
infrastruttura di monitoraggio.

1586
01:09:34,220 --> 01:09:38,430
Il modo in cui andare a tale proposito è quello di trovare una
semplice struttura della tabella, una tabella.

1587
01:09:38,430 --> 01:09:42,250
Ho una tabella di misure dell'apparecchiatura
con una chiave hash l'ID del dispositivo.

1588
01:09:42,250 --> 01:09:47,340
E ho una chiave gamma sul
timestamp, o in questo caso, l'epopea.

1589
01:09:47,340 --> 01:09:50,350
E che mi permette eseguire complesse
query che chiave gamma

1590
01:09:50,350 --> 01:09:54,950
e restituire quei record che
sono relative al risultato

1591
01:09:54,950 --> 01:09:56,310
set che sto cercando.

1592
01:09:56,310 --> 01:09:58,360
E costruisce che uno
ai molti rapporto

1593
01:09:58,360 --> 01:10:02,340
nella tabella principale utilizzando la
tasto cancelletto, gamma struttura chiave.

1594
01:10:02,340 --> 01:10:04,600
>> Ecco, questo è tipo di costruito
nella tabella di Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Quando mi definisco un hash
e tavolo gamma t, io sono

1596
01:10:07,290 --> 01:10:09,240
definire un uno a molti.

1597
01:10:09,240 --> 01:10:12,770
Si tratta di una relazione padre-figlio.

1598
01:10:12,770 --> 01:10:14,620
>> Parliamo di molti
per molte relazioni.

1599
01:10:14,620 --> 01:10:19,170
E per questo particolare esempio,
ancora una volta, stiamo andando a utilizzare GSI di.

1600
01:10:19,170 --> 01:10:23,500
E parliamo di gioco
scenario in cui ho un determinato utente.

1601
01:10:23,500 --> 01:10:26,500
Voglio trovare tutti i giochi che
ha registrato per o giocare in.

1602
01:10:26,500 --> 01:10:29,600
E per un determinato gioco,
vuole trovare tutti gli utenti.

1603
01:10:29,600 --> 01:10:31,010
Allora, come faccio a farlo?

1604
01:10:31,010 --> 01:10:34,330
Il mio tavolo giochi degli utenti, vado
per avere una chiave hash di ID utente

1605
01:10:34,330 --> 01:10:35,810
e una chiave gamma del gioco.

1606
01:10:35,810 --> 01:10:37,810
>> Così un utente può avere più giochi.

1607
01:10:37,810 --> 01:10:41,380
E 'un uno a molti tra
l'utente e le partite che interpreta.

1608
01:10:41,380 --> 01:10:43,410
E poi il GSI,
Io capovolgere che circa.

1609
01:10:43,410 --> 01:10:46,679
Io hash sul gioco e
Io gamma per l'utente.

1610
01:10:46,679 --> 01:10:48,970
Quindi, se voglio ottenere tutte le
gioco l'utente di giocare in,

1611
01:10:48,970 --> 01:10:49,950
Mi interrogo la tabella principale.

1612
01:10:49,950 --> 01:10:52,699
Se voglio ottenere tutti gli utenti
che stanno giocando un gioco particolare,

1613
01:10:52,699 --> 01:10:53,887
Interrogo il GSI.

1614
01:10:53,887 --> 01:10:54,970
Quindi, vedete come lo facciamo?

1615
01:10:54,970 --> 01:10:58,369
Si crea di questi GSI a sostegno della
uso caso, l'applicazione, l'accesso

1616
01:10:58,369 --> 01:10:59,410
modello, l'applicazione.

1617
01:10:59,410 --> 01:11:01,440
>> Se ho bisogno di interrogare su
questa dimensione, lascia

1618
01:11:01,440 --> 01:11:03,500
me crea un indice su quella dimensione.

1619
01:11:03,500 --> 01:11:05,850
Se non lo faccio, non mi interessa.

1620
01:11:05,850 --> 01:11:09,060
E a seconda del caso d'uso, I
potrebbe essere necessario l'indice o non potrebbe.

1621
01:11:09,060 --> 01:11:12,390
Se si tratta di un semplice uno a molti,
tabella primaria va bene.

1622
01:11:12,390 --> 01:11:15,860
Se ho bisogno di fare questi molti a
molti di, o ho bisogno di fare un a quelli,

1623
01:11:15,860 --> 01:11:18,390
allora forse ho bisogno
al secondo l'indice.

1624
01:11:18,390 --> 01:11:20,840
Quindi tutto dipende da
quello che sto cercando di fare

1625
01:11:20,840 --> 01:11:24,550
e quello che sto cercando di ottenere compiuta.

1626
01:11:24,550 --> 01:11:28,000
>> Probabilmente io non ho intenzione di spendere troppo
molto tempo a parlare di documenti.

1627
01:11:28,000 --> 01:11:31,460
Questo diventa un po ', probabilmente,
più profondo di quanto abbiamo bisogno di andare in.

1628
01:11:31,460 --> 01:11:33,710
Parliamo un po '
espressione di query su ricchi.

1629
01:11:33,710 --> 01:11:37,831
Quindi, in Dynamo DB abbiamo
la capacità di creare

1630
01:11:37,831 --> 01:11:39,330
ciò che noi chiamiamo le espressioni di proiezione.

1631
01:11:39,330 --> 01:11:42,660
Espressioni di proiezione sono semplicemente
scegliere i campi oi valori

1632
01:11:42,660 --> 01:11:44,290
che si desidera visualizzare.

1633
01:11:44,290 --> 01:11:46,000
OK, allora faccio una selezione.

1634
01:11:46,000 --> 01:11:48,010
Faccio una query contro la Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
E io dico, sai cosa, spettacolo
me solo le recensioni a cinque stelle

1636
01:11:51,730 --> 01:11:54,544
per questo particolare prodotto.

1637
01:11:54,544 --> 01:11:55,710
Ecco, questo è tutto quello che voglio vedere.

1638
01:11:55,710 --> 01:11:57,320
Non voglio vedere tutto il
altri attributi della fila,

1639
01:11:57,320 --> 01:11:58,319
Voglio solo vedere questo.

1640
01:11:58,319 --> 01:12:01,209
È proprio come in SQL quando si
dire selezionare stella o da tavolo,

1641
01:12:01,209 --> 01:12:02,000
si ottiene tutto.

1642
01:12:02,000 --> 01:12:05,450
Quando dico selezionare il nome da
tavolo, io ho soltanto un attributo.

1643
01:12:05,450 --> 01:12:09,070
E 'lo stesso tipo di cosa in
Dynamo DB o un altro database NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Filtrare espressioni mi permettono di
fondamentalmente tagliare il set di risultati verso il basso.

1645
01:12:14,510 --> 01:12:15,540
Così faccio una query.

1646
01:12:15,540 --> 01:12:17,260
Query può tornare con 500 articoli.

1647
01:12:17,260 --> 01:12:20,255
Ma io voglio solo gli elementi che
avere un attributo che dice questo.

1648
01:12:20,255 --> 01:12:23,380
OK, quindi cerchiamo di filtrare le voci
che non corrispondono quella query particolare.

1649
01:12:23,380 --> 01:12:25,540
Così abbiamo espressioni di filtro.

1650
01:12:25,540 --> 01:12:28,310
>> Filtro espressioni possono
essere eseguito su qualsiasi attributo.

1651
01:12:28,310 --> 01:12:30,260
Non sono come le query gamma.

1652
01:12:30,260 --> 01:12:32,690
Alzare query sono più selettivi.

1653
01:12:32,690 --> 01:12:36,470
Query di filtro mi impongono di andare
vengono impostati l'intero risultato e poi

1654
01:12:36,470 --> 01:12:39,170
ritagliarsi i dati che non voglio.

1655
01:12:39,170 --> 01:12:40,660
Perché è così importante?

1656
01:12:40,660 --> 01:12:42,770
Perché ho letto tutto.

1657
01:12:42,770 --> 01:12:46,597
In una query, ho intenzione di leggere e
sta andando essere un gigante sui dati.

1658
01:12:46,597 --> 01:12:48,430
E poi ho intenzione di
ritagliarmi cosa ho bisogno.

1659
01:12:48,430 --> 01:12:52,080
E se sto solo ritagliarsi un
paio di righe, quindi va bene così.

1660
01:12:52,080 --> 01:12:53,620
Non è così inefficiente.

1661
01:12:53,620 --> 01:12:57,800
>> Ma se io sto leggendo un mucchio di
i dati, solo per ritagliarsi una voce,

1662
01:12:57,800 --> 01:13:01,490
poi ho intenzione di essere meglio
fuori utilizzando una query gamma,

1663
01:13:01,490 --> 01:13:03,030
perché è molto più selettivo.

1664
01:13:03,030 --> 01:13:06,330
Sta andando a me risparmiare un sacco di
soldi, perché devo pagare per quella lettura.

1665
01:13:06,330 --> 01:13:10,430
Se i risultati che ritorna
attraversare quel filo potrebbe essere più piccolo,

1666
01:13:10,430 --> 01:13:11,890
ma sto pagando per la lettura.

1667
01:13:11,890 --> 01:13:14,340
Quindi, capire come
che stai ricevendo i dati.

1668
01:13:14,340 --> 01:13:16,420
Questo è molto importante in Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Espressioni condizionali, questo è ciò che
si potrebbe chiamare lock ottimistico.

1670
01:13:19,710 --> 01:13:28,470
Aggiornamento SE ESISTE, o se questo valore
è equivalente a quello che ho specificato.

1671
01:13:28,470 --> 01:13:31,494
E se ho un timbro di tempo su un
disco, potrei leggere i dati.

1672
01:13:31,494 --> 01:13:32,535
Potrei cambiare la situazione dei dati.

1673
01:13:32,535 --> 01:13:35,030
Potrei andare scrivere che
indietro i dati nel database.

1674
01:13:35,030 --> 01:13:38,100
Se qualcuno ha modificato il record,
il timestamp potrebbe avere cambiato.

1675
01:13:38,100 --> 01:13:40,370
E in questo modo il mio condizionale
aggiornamento potrebbe dire aggiornamento

1676
01:13:40,370 --> 01:13:42,340
se il timestamp è uguale a questo.

1677
01:13:42,340 --> 01:13:46,290
O l'aggiornamento non riuscirà perché qualcuno
aggiornato il record nel frattempo.

1678
01:13:46,290 --> 01:13:48,290
>> Questo è ciò che noi chiamiamo il blocco ottimistico.

1679
01:13:48,290 --> 01:13:50,670
Vuol dire che qualcuno
può entrare e cambiare,

1680
01:13:50,670 --> 01:13:53,100
e ho intenzione di rilevarla
quando torno a scrivere.

1681
01:13:53,100 --> 01:13:56,106
E poi posso effettivamente letto che
dati e dire: oh, ha cambiato questo.

1682
01:13:56,106 --> 01:13:57,230
Ho bisogno di tenere conto di questo.

1683
01:13:57,230 --> 01:14:00,490
E posso modificare i dati della mia
registrare e applicare un altro aggiornamento.

1684
01:14:00,490 --> 01:14:04,330
Così si può prendere quelli incrementali
aggiornamenti che si verificano tra il momento

1685
01:14:04,330 --> 01:14:08,740
di leggere i dati e la
ora è possibile scrivere i dati.

1686
01:14:08,740 --> 01:14:11,520
>> AUDIENCE: E il filtro
espressione in realtà non significa

1687
01:14:11,520 --> 01:14:13,020
nel numero o not--

1688
01:14:13,020 --> 01:14:14,316
>> [VOICES interponendo]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: non lo farò
ottenere troppo in questo.

1690
01:14:16,232 --> 01:14:17,700
Questa è una parola chiave riservata.

1691
01:14:17,700 --> 01:14:20,130
La vista è una libbra riservata
parola chiave in Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Ogni database ha il suo riservata
nome della raccolta non possono essere utilizzate.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, se si specifica
una libbra di fronte a questo,

1694
01:14:27,240 --> 01:14:29,310
è possibile definire i nomi sopra.

1695
01:14:29,310 --> 01:14:31,840
Questo è un valore di riferimento.

1696
01:14:31,840 --> 01:14:34,880
Non è probabilmente il miglior sintassi per
avere lassù per questa discussione,

1697
01:14:34,880 --> 01:14:38,090
perché ottiene in alcuni real--
Avrei parlato di più

1698
01:14:38,090 --> 01:14:41,360
riguardo ad un livello più profondo.

1699
01:14:41,360 --> 01:14:46,130
>> Ma basti dire, questo potrebbe
essere richiesta la scansione in cui views--

1700
01:14:46,130 --> 01:14:50,190
né viste libbra è maggiore di 10.

1701
01:14:50,190 --> 01:14:54,660
Si tratta di un valore numerico, sì.

1702
01:14:54,660 --> 01:14:57,322
Se si vuole, si può parlare di
che dopo la discussione.

1703
01:14:57,322 --> 01:15:00,030
Va bene, quindi stiamo entrando
alcuni scenari in best practice

1704
01:15:00,030 --> 01:15:02,000
dove stiamo andando a parlare
su alcune applicazioni qui.

1705
01:15:02,000 --> 01:15:03,810
Quali sono i casi di utilizzo per la Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Quali sono il disegno
modelli in Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> E il primo che andremo a
parlare è l'internet delle cose.

1708
01:15:09,110 --> 01:15:15,010
Quindi abbiamo un sacco di-- credo,
ciò è it-- più del 50%

1709
01:15:15,010 --> 01:15:19,370
del traffico su internet in questi giorni
è in realtà generato dalle macchine,

1710
01:15:19,370 --> 01:15:21,930
processi automatizzati, non da esseri umani.

1711
01:15:21,930 --> 01:15:25,140
Voglio dire, questa cosa questa cosa che
portare in giro in tasca,

1712
01:15:25,140 --> 01:15:28,840
quantità di dati che che cosa è
in realtà l'invio in giro senza di te

1713
01:15:28,840 --> 01:15:30,550
sapendo che è assolutamente incredibile.

1714
01:15:30,550 --> 01:15:34,970
La posizione, le informazioni
su quanto velocemente si sta andando.

1715
01:15:34,970 --> 01:15:38,400
Come pensi che Google Maps funziona
quando vi dicono che cosa il traffico è.

1716
01:15:38,400 --> 01:15:41,275
È perché ci sono milioni e
milioni di persone guidando

1717
01:15:41,275 --> 01:15:44,667
con i telefoni che inviano
Dati di tutto luogo per tutto il tempo.

1718
01:15:44,667 --> 01:15:46,500
Così una delle cose
su questo tipo di dati

1719
01:15:46,500 --> 01:15:50,980
che viene in, dati di monitoraggio, il log-
dati, dati di serie temporali, è il suo

1720
01:15:50,980 --> 01:15:53,540
di solito solo interessante
per un po 'di tempo.

1721
01:15:53,540 --> 01:15:55,580
Dopo questo tempo, è
non così interessante.

1722
01:15:55,580 --> 01:15:58,390
Così abbiamo parlato, non lasciare
tali tabelle crescere senza limiti.

1723
01:15:58,390 --> 01:16:03,410
L'idea è che forse ho 24
ora vale la pena di eventi della mia tavola calda.

1724
01:16:03,410 --> 01:16:06,160
E quella tavola calda sta per essere
provisioning a un tasso molto alto,

1725
01:16:06,160 --> 01:16:07,950
perché sta prendendo un sacco di dati.

1726
01:16:07,950 --> 01:16:10,920
Sta prendendo un sacco di dati
in e sto leggendo molto.

1727
01:16:10,920 --> 01:16:14,560
Ho un sacco di operazione
query in esecuzione contro tali dati.

1728
01:16:14,560 --> 01:16:18,120
>> Dopo 24 ore, hey,
so cosa, non mi interessa.

1729
01:16:18,120 --> 01:16:21,150
Così forse io ogni rotolo di mezzanotte
mio tavolo a un nuovo tavolo

1730
01:16:21,150 --> 01:16:22,430
e io deprovisioning questa tabella.

1731
01:16:22,430 --> 01:16:26,440
E mi prendo il telecomando e
Giù di WCU perché 24 ore dopo

1732
01:16:26,440 --> 01:16:28,630
Io non sto correndo come molti
query che i dati.

1733
01:16:28,630 --> 01:16:30,200
Quindi ho intenzione di risparmiare denaro.

1734
01:16:30,200 --> 01:16:32,940
E forse i 30 giorni più tardi non lo faccio
nemmeno bisogno di preoccuparsi di tutto.

1735
01:16:32,940 --> 01:16:35,020
Potrei prendere il WCU del
tutta la strada fino a uno,

1736
01:16:35,020 --> 01:16:36,990
perché si sa che cosa, e '
mai andando ottenere scritto.

1737
01:16:36,990 --> 01:16:38,300
Il dato è di 30 giorni.

1738
01:16:38,300 --> 01:16:40,000
Non cambia mai.

1739
01:16:40,000 --> 01:16:44,200
>> Ed è quasi mai andando ottenere leggere,
quindi cerchiamo di prendere solo quello telecomando fino a 10.

1740
01:16:44,200 --> 01:16:49,372
E sto risparmiando un sacco di soldi per questo
i dati, e pagare solo per i miei dati a caldo.

1741
01:16:49,372 --> 01:16:52,330
Ecco, questo è la cosa importante da guardare
a quando si guarda a una serie storica

1742
01:16:52,330 --> 01:16:54,716
dati che arriva in volume.

1743
01:16:54,716 --> 01:16:55,590
Si tratta di strategie.

1744
01:16:55,590 --> 01:16:58,010
Ora, ho potuto solo lasciarlo
vanno tutti allo stesso tavolo

1745
01:16:58,010 --> 01:16:59,461
e lasciare quel tavolo crescere.

1746
01:16:59,461 --> 01:17:01,460
Alla fine, ho intenzione di
vedi problemi di prestazioni.

1747
01:17:01,460 --> 01:17:04,060
Ho intenzione di dover ricominciare da archiviare
alcuni di tali dati dal tavolo,

1748
01:17:04,060 --> 01:17:04,720
cosa no.

1749
01:17:04,720 --> 01:17:07,010
>> Facciamo molto meglio
progettare l'applicazione

1750
01:17:07,010 --> 01:17:08,900
in modo da poter operare in questo modo giusto.

1751
01:17:08,900 --> 01:17:11,460
Quindi è solo automatica
nel codice dell'applicazione.

1752
01:17:11,460 --> 01:17:13,580
A mezzanotte ogni notte
rotola tabella.

1753
01:17:13,580 --> 01:17:17,170
Forse quello che mi serve è un scorrevole
finestra di 24 ore di dati.

1754
01:17:17,170 --> 01:17:20,277
Poi su base regolare sono
chiamando i dati fuori dal tavolo.

1755
01:17:20,277 --> 01:17:22,360
Sto taglio con un
Cron lavoro e sto mettendo

1756
01:17:22,360 --> 01:17:24,160
su queste altre tabelle,
qualunque cosa ti serva.

1757
01:17:24,160 --> 01:17:25,940
Quindi, se un rollover funziona, che è grande.

1758
01:17:25,940 --> 01:17:27,080
In caso contrario, finiture.

1759
01:17:27,080 --> 01:17:29,640
Ma teniamo che i dati a caldo
via dai vostri dati freddi.

1760
01:17:29,640 --> 01:17:32,535
Esso ti risparmiare un sacco di soldi e
rendere le tabelle più performante.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Così la prossima cosa ne parleremo
circa è catalogo prodotti.

1763
01:17:38,210 --> 01:17:42,000
Catalogo prodotti è
caso d'uso piuttosto comune.

1764
01:17:42,000 --> 01:17:46,600
Questo è in realtà un modello molto comune
che vedremo in una varietà di cose.

1765
01:17:46,600 --> 01:17:48,870
Sai, per Twitter
ad esempio, un tweet caldo.

1766
01:17:48,870 --> 01:17:51,280
Ognuno sta arrivando e
afferrando quel tweet.

1767
01:17:51,280 --> 01:17:52,680
Catalogo prodotti, ho ottenuto una vendita.

1768
01:17:52,680 --> 01:17:54,120
Ho ottenuto una vendita calda.

1769
01:17:54,120 --> 01:17:57,277
Ho ottenuto 70.000 richieste al
seconda venuta di un prodotto

1770
01:17:57,277 --> 01:17:58,860
descrizione dal mio catalogo prodotti.

1771
01:17:58,860 --> 01:18:02,384
Lo vediamo in dettaglio
operazione un po '.

1772
01:18:02,384 --> 01:18:03,550
Quindi, come abbiamo a che fare con questo?

1773
01:18:03,550 --> 01:18:04,924
Non c'è modo di fare con questo.

1774
01:18:04,924 --> 01:18:07,110
Tutti i miei utenti vogliono vedere
lo stesso pezzo di dati.

1775
01:18:07,110 --> 01:18:09,410
Stanno stanno arrivando, contemporaneamente.

1776
01:18:09,410 --> 01:18:11,920
E stanno tutti facendo richieste
per la stessa porzione di dati.

1777
01:18:11,920 --> 01:18:16,240
Questo mi dà quella chiave caldo, quel grande rosso
striscia sul mio grafico che non ci piace.

1778
01:18:16,240 --> 01:18:17,720
Ed è quello che sembra.

1779
01:18:17,720 --> 01:18:22,290
Così attraverso il mio spazio chiave Ricevo
martellato nelle voci di vendita.

1780
01:18:22,290 --> 01:18:24,070
Sto ottenendo nulla altrove.

1781
01:18:24,070 --> 01:18:26,050
>> Come posso alleviare questo problema?

1782
01:18:26,050 --> 01:18:28,410
Beh, alleviamo questo con cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, si mette in pratica un in-memory
partizione di fronte al database.

1784
01:18:33,630 --> 01:18:37,260
Siamo riusciti
[Incomprensibile] cache, come si

1785
01:18:37,260 --> 01:18:40,260
può impostare la propria cache, [incomprensibile]
cache [? d,?] quello che volete.

1786
01:18:40,260 --> 01:18:42,220
Mettere che di fronte database.

1787
01:18:42,220 --> 01:18:47,250
E in questo modo è possibile memorizzare i dati
da quei tasti di scelta rapida in quel nascondiglio

1788
01:18:47,250 --> 01:18:49,390
spazio e leggere attraverso la cache.

1789
01:18:49,390 --> 01:18:51,962
>> E poi la maggior parte del vostro letture
iniziare a guardare come questo.

1790
01:18:51,962 --> 01:18:54,920
Mi sono tutti questi nascondiglio urta qui
e mi sono nulla succede qui

1791
01:18:54,920 --> 01:18:59,330
perché database è seduto dietro la
cache e la letture mai venire attraverso.

1792
01:18:59,330 --> 01:19:02,520
Se cambio i dati del
base di dati, devo aggiornare la cache.

1793
01:19:02,520 --> 01:19:04,360
Possiamo usare qualcosa
come vapori di farlo.

1794
01:19:04,360 --> 01:19:07,360
E ti spiego come funziona.

1795
01:19:07,360 --> 01:19:09,060
D'accordo, la messaggistica.

1796
01:19:09,060 --> 01:19:11,180
E-mail, che noi tutti usiamo e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> Questo è un buon esempio.

1798
01:19:12,540 --> 01:19:14,950
Abbiamo una sorta di tabella dei messaggi.

1799
01:19:14,950 --> 01:19:17,040
E abbiamo ottenuto posta in arrivo e in uscita.

1800
01:19:17,040 --> 01:19:19,760
Questo è ciò che il SQL sarebbe
guarda come per costruire quella casella di posta.

1801
01:19:19,760 --> 01:19:23,350
Noi tipo di utilizzo dello stesso tipo
di strategia da utilizzare GSI di, GSI di

1802
01:19:23,350 --> 01:19:25,320
per la mia casella di posta e la mia posta in uscita.

1803
01:19:25,320 --> 01:19:27,600
Così ho preso i messaggi provenienti prime
nella mia tabella dei messaggi.

1804
01:19:27,600 --> 01:19:30,194
E il primo approccio a questo
potrebbe essere, diciamo, OK, nessun problema.

1805
01:19:30,194 --> 01:19:31,110
Ho messaggi prime.

1806
01:19:31,110 --> 01:19:33,710
Messaggi provenienti [incomprensibile],
messaggio di ID, che è grande.

1807
01:19:33,710 --> 01:19:35,070
Questo è il mio hash univoco.

1808
01:19:35,070 --> 01:19:38,280
Ho intenzione di creare due GSI di, uno
per la mia casella di posta, uno per il mio in uscita.

1809
01:19:38,280 --> 01:19:40,530
E la prima cosa che farò
è Dirò la mia chiave hash è

1810
01:19:40,530 --> 01:19:43,310
sarà il destinatario e
Ho intenzione di organizzare il giorno.

1811
01:19:43,310 --> 01:19:44,220
È fantastico.

1812
01:19:44,220 --> 01:19:45,890
Ho ottenuto il mio bella vista qui.

1813
01:19:45,890 --> 01:19:47,780
Ma c'è un piccolo problema qui.

1814
01:19:47,780 --> 01:19:50,891
E si esegue in questo
database relazionali come bene.

1815
01:19:50,891 --> 01:19:52,390
Hanno chiamato partizionamento verticale.

1816
01:19:52,390 --> 01:19:55,840
Si desidera mantenere i vostri dati grande
via dai vostri dati piccoli.

1817
01:19:55,840 --> 01:20:00,470
>> E il motivo è perché io devo
andare a leggere gli elementi per ottenere gli attributi.

1818
01:20:00,470 --> 01:20:05,570
E se i miei corpi sono tutti qui,
poi leggendo pochi elementi

1819
01:20:05,570 --> 01:20:08,560
se il mio corpo è la lunghezza
una media di 256 kilobyte ciascuno,

1820
01:20:08,560 --> 01:20:10,991
la matematica diventa piuttosto brutto.

1821
01:20:10,991 --> 01:20:12,490
Quindi dire che voglio leggere posta in arrivo di David.

1822
01:20:12,490 --> 01:20:14,520
Posta in arrivo di David ha 50 elementi.

1823
01:20:14,520 --> 01:20:17,880
La media e la dimensione è di 256 kilobyte.

1824
01:20:17,880 --> 01:20:21,730
Ecco il mio rapporto di conversione
per RCU di è quattro kilobyte.

1825
01:20:21,730 --> 01:20:24,450
>> Ok, andiamo con
infine coerente legge.

1826
01:20:24,450 --> 01:20:28,640
Sto ancora mangiando 1.600 telecomando di
solo per leggere posta in arrivo di David.

1827
01:20:28,640 --> 01:20:29,950
Ahia.

1828
01:20:29,950 --> 01:20:31,980
OK, ora pensiamo
su come funziona l'applicazione.

1829
01:20:31,980 --> 01:20:35,340
Se mi trovo in una e-mail app e
Sto guardando la mia casella di posta,

1830
01:20:35,340 --> 01:20:39,680
e guardo il corpo di ogni messaggio,
no, sto guardando i sommari.

1831
01:20:39,680 --> 01:20:41,850
Sto guardando solo le intestazioni.

1832
01:20:41,850 --> 01:20:46,310
Quindi cerchiamo di costruire una struttura di tabella
che sembra più simile a quella.

1833
01:20:46,310 --> 01:20:49,470
>> Quindi, ecco le informazioni
che il mio flusso di lavoro ha bisogno.

1834
01:20:49,470 --> 01:20:50,890
E 'nella mia casella di posta GSI.

1835
01:20:50,890 --> 01:20:53,800
E 'la data, il mittente,
il soggetto, e quindi

1836
01:20:53,800 --> 01:20:56,790
l'ID del messaggio, che punta
torna alla tabella dei messaggi

1837
01:20:56,790 --> 01:20:57,850
dove posso trovare il corpo.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Ebbene, questi sarebbero gli ID record.

1840
01:21:04,420 --> 01:21:09,850
Avrebbero puntare di nuovo al
ID elemento sul tavolo Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Ogni indice creates-- sempre
ha sempre la voce

1842
01:21:12,220 --> 01:21:15,750
ID come parte di-- che
viene fornito con l'indice.

1843
01:21:15,750 --> 01:21:17,414
>> Tutto ok.

1844
01:21:17,414 --> 01:21:19,080
PUBBLICO: Si dice che dove è conservato?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Sì, racconta
exactly-- questo è esattamente quello che fa.

1846
01:21:21,420 --> 01:21:22,644
Qui dice il mio record di re.

1847
01:21:22,644 --> 01:21:24,310
E sarà puntare di nuovo al mio record re.

1848
01:21:24,310 --> 01:21:26,460
Di preciso.

1849
01:21:26,460 --> 01:21:29,490
OK, ora la mia casella di posta è
in realtà molto più piccolo.

1850
01:21:29,490 --> 01:21:32,210
E questo in realtà sostiene
il flusso di lavoro di una e-mail app.

1851
01:21:32,210 --> 01:21:34,230
Così la mia casella di posta, clicco.

1852
01:21:34,230 --> 01:21:38,160
Vado avanti e faccio clic sul messaggio,
in quel momento che ho bisogno di andare a prendere il corpo,

1853
01:21:38,160 --> 01:21:40,180
perché ho intenzione di
andare a una visione diversa.

1854
01:21:40,180 --> 01:21:43,870
Quindi, se si pensa di tipo MVC
quadro, controllore vista del modello.

1855
01:21:43,870 --> 01:21:46,120
>> Il modello contiene la
i dati che i bisogni vista

1856
01:21:46,120 --> 01:21:48,130
e il controllore interagisce.

1857
01:21:48,130 --> 01:21:51,670
Quando cambio il telaio, quando
A cambiare il punto di vista,

1858
01:21:51,670 --> 01:21:55,080
va bene per tornare al
server e ripopolare il modello,

1859
01:21:55,080 --> 01:21:56,860
perché è quello che l'utente si aspetta.

1860
01:21:56,860 --> 01:22:00,530
Quando cambiano di vista, in quel momento
possiamo tornare al database.

1861
01:22:00,530 --> 01:22:02,480
Quindi e-mail, fare clic su.

1862
01:22:02,480 --> 01:22:03,710
Sto cercando il corpo.

1863
01:22:03,710 --> 01:22:04,330
Andata e ritorno.

1864
01:22:04,330 --> 01:22:05,680
Vai a prendere il corpo.

1865
01:22:05,680 --> 01:22:06,950
>> Leggo molto meno dati.

1866
01:22:06,950 --> 01:22:09,960
Sono solo leggendo i corpi che
David ha bisogno quando ne ha bisogno.

1867
01:22:09,960 --> 01:22:14,230
E non sto brucio nel 1600
RCU di solo per mostrare la sua casella di posta.

1868
01:22:14,230 --> 01:22:17,670
Così ora che-- questo è il modo
che LSI o GSI-- mi dispiace,

1869
01:22:17,670 --> 01:22:19,900
GSI, avrebbe funzionato.

1870
01:22:19,900 --> 01:22:25,450
Abbiamo il nostro hash al beneficiario.

1871
01:22:25,450 --> 01:22:27,030
Abbiamo il tasto della gamma della data.

1872
01:22:27,030 --> 01:22:31,380
E abbiamo gli attributi previsti
che abbiamo bisogno solo di sostegno della tesi.

1873
01:22:31,380 --> 01:22:34,300
>> Ruotiamo che per la posta in uscita.

1874
01:22:34,300 --> 01:22:35,770
Hash al mittente.

1875
01:22:35,770 --> 01:22:39,612
E in sostanza, abbiamo
molto bella, vista pulita.

1876
01:22:39,612 --> 01:22:41,570
Ed è che basically--
avere questo bel messaggio

1877
01:22:41,570 --> 01:22:45,870
tabella che viene diffuso bene perché
è solo hash, ID messaggio hash.

1878
01:22:45,870 --> 01:22:51,750
E abbiamo due indici
sono a rotazione fuori di quel tavolo.

1879
01:22:51,750 --> 01:22:57,411
Va bene, quindi idea qui è fare non
tenere i grandi dati e questo piccolo dati

1880
01:22:57,411 --> 01:22:57,910
insieme.

1881
01:22:57,910 --> 01:23:00,700
Partition verticalmente,
partizionare tali tabelle.

1882
01:23:00,700 --> 01:23:03,150
Non leggere dati che non è necessario.

1883
01:23:03,150 --> 01:23:04,850
Va bene, il gioco.

1884
01:23:04,850 --> 01:23:06,990
A tutti noi piace giochi.

1885
01:23:06,990 --> 01:23:10,902
Almeno Mi piacciono i giochi allora.

1886
01:23:10,902 --> 01:23:12,735
Così alcune delle cose
che abbiamo a che fare con quando

1887
01:23:12,735 --> 01:23:14,193
stiamo pensando di gioco, giusto?

1888
01:23:14,193 --> 01:23:16,999
Gaming questi giorni, soprattutto mobili
di gioco, è tutto di pensare.

1889
01:23:16,999 --> 01:23:19,540
E ho intenzione di girare qui un
po 'lontano dalla DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Ho intenzione di portare a
alcune delle discussioni

1891
01:23:21,373 --> 01:23:24,240
intorno alcuni dei
altre tecnologie AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Ma l'idea di gioco è quella di pensare
circa in termini di API, le API che sono,

1893
01:23:28,930 --> 01:23:31,730
in generale, HTTP e JSON.

1894
01:23:31,730 --> 01:23:34,550
E 'come i giochi mobili tipo di
interagire con i loro back end.

1895
01:23:34,550 --> 01:23:35,850
Fanno JSON distacco.

1896
01:23:35,850 --> 01:23:40,660
Ottengono i dati, ed è tutto,
in generale, in bei API JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Cose come ottenere amici, ottengono
i dati leaderboard, scambio,

1898
01:23:44,950 --> 01:23:47,699
contenuto generato dall'utente,
spingere indietro fino al sistema,

1899
01:23:47,699 --> 01:23:49,740
questi sono i tipi di cose
che andremo a fare.

1900
01:23:49,740 --> 01:23:52,542
Dati risorsa binari, questi dati
potrebbe non sedersi nel database.

1901
01:23:52,542 --> 01:23:54,250
Questo potrebbe sedersi in un
archivio degli oggetti, giusto?

1902
01:23:54,250 --> 01:23:56,541
Ma il database sta per
finiscono per raccontare il sistema,

1903
01:23:56,541 --> 01:23:59,140
raccontando l'applicazione
dove andarlo a prendere.

1904
01:23:59,140 --> 01:24:03,550
E, inevitabilmente, il multiplayer
server, infrastruttura di back-end,

1905
01:24:03,550 --> 01:24:06,180
e progettata per elevate
disponibilità e scalabilità.

1906
01:24:06,180 --> 01:24:09,400
Quindi, queste sono cose che tutti noi vogliamo
nelle infrastrutture di gioco di oggi.

1907
01:24:09,400 --> 01:24:12,160
>> Quindi, diamo uno sguardo a
quello che sembra.

1908
01:24:12,160 --> 01:24:16,070
Hai un back-end di base,
molto semplice.

1909
01:24:16,070 --> 01:24:19,880
Abbiamo un sistema di qui con
più zone disponibilità.

1910
01:24:19,880 --> 01:24:23,780
Abbiamo parlato di come AZS being-- pensare
a loro come data center separati.

1911
01:24:23,780 --> 01:24:26,040
Più di un centro dati
per AZ, ma va bene così,

1912
01:24:26,040 --> 01:24:28,831
basti pensare a loro come dati separata
Centri che sono geograficamente

1913
01:24:28,831 --> 01:24:30,090
e colpa isolato.

1914
01:24:30,090 --> 01:24:32,172
>> Stiamo per avere un
istanze EC2 coppia.

1915
01:24:32,172 --> 01:24:33,880
Stiamo per avere
qualche server back-end.

1916
01:24:33,880 --> 01:24:35,800
Forse, se sei un lascito
architettura, siamo

1917
01:24:35,800 --> 01:24:38,920
utilizzando ciò che noi chiamiamo RDS,
servizi di database relazionali.

1918
01:24:38,920 --> 01:24:42,040
Potrebbe essere MSSQL, MySQL,
o qualcosa di simile.

1919
01:24:42,040 --> 01:24:47,080
Si tratta di un sacco di applicazioni way
sono oggi progettato.

1920
01:24:47,080 --> 01:24:49,594
>> Beh si potrebbe desiderare di andare con
questo è quando si scala fuori.

1921
01:24:49,594 --> 01:24:51,510
Andremo avanti e mettere
il secchio S3 lassù.

1922
01:24:51,510 --> 01:24:54,200
E quel secchio S3, invece di servire
up quegli oggetti del nostro servers--

1923
01:24:54,200 --> 01:24:55,220
potremmo farlo.

1924
01:24:55,220 --> 01:24:57,210
Hai messo tutto il tuo binario
oggetti nei server

1925
01:24:57,210 --> 01:24:59,751
ed è possibile utilizzare quelli di server
le istanze per servire i dati su.

1926
01:24:59,751 --> 01:25:01,860
Ma questo è piuttosto costoso.

1927
01:25:01,860 --> 01:25:05,107
>> Modo migliore da fare è andare avanti e
mettere quegli oggetti in un secchio di S3.

1928
01:25:05,107 --> 01:25:06,315
S3 è oggetto un repository.

1929
01:25:06,315 --> 01:25:10,860
E 'costruito appositamente per
servendo questi tipi di cose.

1930
01:25:10,860 --> 01:25:13,690
E lasciare che i clienti richiedono
direttamente da quelli secchi oggetto,

1931
01:25:13,690 --> 01:25:15,390
offload dei server.

1932
01:25:15,390 --> 01:25:17,020
Quindi stiamo iniziando a scalare qui.

1933
01:25:17,020 --> 01:25:19,140
>> Ora abbiamo ottenuto utenti di tutto il mondo.

1934
01:25:19,140 --> 01:25:19,730
Ho utenti.

1935
01:25:19,730 --> 01:25:23,380
Ho bisogno di avere contenuti a livello locale
situato vicino a questi utenti, giusto?

1936
01:25:23,380 --> 01:25:26,200
Ho creato un secchio S3
come il mio repository di origine.

1937
01:25:26,200 --> 01:25:29,370
E sarò anteriore che con
la distribuzione CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront è un CD e un
Content Delivery Network.

1939
01:25:31,720 --> 01:25:35,750
Fondamentalmente prende i dati che si specifica
e memorizza nella cache il tutto su internet

1940
01:25:35,750 --> 01:25:39,230
così gli utenti in tutto il mondo possono avere
una risposta molto veloce quando

1941
01:25:39,230 --> 01:25:40,960
chiedono tali oggetti.

1942
01:25:40,960 --> 01:25:41,960
>> Così si ottiene un idea.

1943
01:25:41,960 --> 01:25:48,230
Stai tipo di sfruttare tutte le
aspetti di AWS qui per ottenere questo fatto.

1944
01:25:48,230 --> 01:25:50,790
E alla fine, gettiamo
in un gruppo di ridimensionamento automatico.

1945
01:25:50,790 --> 01:25:52,737
Così i nostri casi AC2
dei nostri server di gioco,

1946
01:25:52,737 --> 01:25:54,820
in cui iniziano a essere più affollato
e più affollate e frequentate,

1947
01:25:54,820 --> 01:25:57,236
faranno solo girare un altro
esempio, girare un altro caso,

1948
01:25:57,236 --> 01:25:58,210
girare un'altra istanza.

1949
01:25:58,210 --> 01:26:02,090
Così la tecnologia AWS ha,
consente di specificare i parametri

1950
01:26:02,090 --> 01:26:04,650
attorno al quale i server cresceranno.

1951
01:26:04,650 --> 01:26:08,110
Così si può avere n numero di server
là fuori in un dato momento.

1952
01:26:08,110 --> 01:26:11,870
E se il vostro carico se ne va, faranno
restringersi, il numero si ridurrà.

1953
01:26:11,870 --> 01:26:15,250
E se il carico torna,
esso crescerà di nuovo fuori, elasticamente.

1954
01:26:15,250 --> 01:26:17,050
>> Quindi questo sembra grande.

1955
01:26:17,050 --> 01:26:19,800
Abbiamo un sacco di istanze EC2.

1956
01:26:19,800 --> 01:26:21,671
Possiamo mettere cache
fronte dei database,

1957
01:26:21,671 --> 01:26:23,045
cercare di accelerare i database.

1958
01:26:23,045 --> 01:26:25,030
Il punto di pressione prossimo
in genere la gente vede

1959
01:26:25,030 --> 01:26:28,850
sono loro scalare un gioco con un
sistema di database relazionale.

1960
01:26:28,850 --> 01:26:30,790
Cribbio, il database
prestazioni è terribile.

1961
01:26:30,790 --> 01:26:31,932
Come possiamo migliorare questo?

1962
01:26:31,932 --> 01:26:33,640
Proviamo mettendo
la cache di fronte a quella.

1963
01:26:33,640 --> 01:26:36,780
>> Beh, la cache non funziona
così grande nei giochi, giusto?

1964
01:26:36,780 --> 01:26:39,330
Per i giochi, la scrittura è doloroso.

1965
01:26:39,330 --> 01:26:40,930
I giochi sono molto scrivono pesante.

1966
01:26:40,930 --> 01:26:43,610
Cache non funziona quando si è
scrivere pesante perché hai sempre

1967
01:26:43,610 --> 01:26:44,610
avuto modo di aggiornare la cache.

1968
01:26:44,610 --> 01:26:47,780
Si aggiorna la cache, è
irrilevante da caching.

1969
01:26:47,780 --> 01:26:49,780
In realtà è solo un lavoro extra.

1970
01:26:49,780 --> 01:26:51,970
>> Allora dove andiamo qui?

1971
01:26:51,970 --> 01:26:54,400
Hai un grande collo di bottiglia
laggiù nel database.

1972
01:26:54,400 --> 01:26:57,661
E il posto dove andare
ovviamente è partizionamento.

1973
01:26:57,661 --> 01:26:59,410
Partizionamento non è
facile da fare quando si è

1974
01:26:59,410 --> 01:27:01,900
che fare con i database relazionali.

1975
01:27:01,900 --> 01:27:05,080
Con i database relazionali, sei
responsabile della gestione, in modo efficace,

1976
01:27:05,080 --> 01:27:06,210
lo spazio delle chiavi.

1977
01:27:06,210 --> 01:27:10,527
Stai dicendo che gli utenti tra A e M
andate qui, tra N e Z ci vanno.

1978
01:27:10,527 --> 01:27:12,360
E stai passando
attraverso l'applicazione.

1979
01:27:12,360 --> 01:27:15,000
Quindi hai a che fare con
questa fonte di dati partizione.

1980
01:27:15,000 --> 01:27:18,670
Si hanno vincoli transazionali
che non si estendono le partizioni.

1981
01:27:18,670 --> 01:27:20,560
Hai tutti i tipi di
disordine che sei

1982
01:27:20,560 --> 01:27:23,040
trattare con laggiù provare
a che fare con la scalabilità orizzontale

1983
01:27:23,040 --> 01:27:25,120
e la costruzione di una infrastruttura più grande.

1984
01:27:25,120 --> 01:27:27,284
E 'solo non è divertente.

1985
01:27:27,284 --> 01:27:30,930
>> PUBBLICO: Quindi stai dicendo che
aumentando punti sorgente accelera

1986
01:27:30,930 --> 01:27:31,430
il processo?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Aumento?

1988
01:27:32,513 --> 01:27:33,520
Punti Fonte: UDIENZA.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: punti di origine?

1990
01:27:34,410 --> 01:27:37,500
AUDIENCE: Dalle informazioni,
dove l'informazione proviene da?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: No.

1992
01:27:38,250 --> 01:27:41,820
Quello che sto dicendo è l'aumento della
numero di partizioni in archivio dati

1993
01:27:41,820 --> 01:27:44,060
migliora il throughput.

1994
01:27:44,060 --> 01:27:48,300
Così che cosa sta accadendo qui è utenti
entrando nella istanza EC2 qui,

1995
01:27:48,300 --> 01:27:50,780
bene, se ho bisogno di un utente
che è da A a M, vado qui.

1996
01:27:50,780 --> 01:27:53,560
Da N a p, vado qui.

1997
01:27:53,560 --> 01:27:55,060
Da P alla Z, vado qui.

1998
01:27:55,060 --> 01:27:57,120
>> PUBBLICO: OK, quelli così quelle sono
tutti memorizzati in diversi nodi?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Sì.

2000
01:27:57,911 --> 01:28:00,210
Pensate a questi come
diversi silos di dati.

2001
01:28:00,210 --> 01:28:01,660
Quindi stai dover fare questo.

2002
01:28:01,660 --> 01:28:02,910
Se stai cercando di fare
questo, se si sta cercando

2003
01:28:02,910 --> 01:28:05,730
in scala su una piattaforma relazionale,
questo è quello che stai facendo.

2004
01:28:05,730 --> 01:28:08,100
Stai prendendo i dati e
si sta tagliando verso il basso.

2005
01:28:08,100 --> 01:28:10,975
E stai partizionamento trasversalmente
più istanze di database.

2006
01:28:10,975 --> 01:28:13,580
E si sta gestendo tutto ciò che
al livello applicazione.

2007
01:28:13,580 --> 01:28:14,729
Non è divertente.

2008
01:28:14,729 --> 01:28:15,770
Così che cosa vogliamo andare?

2009
01:28:15,770 --> 01:28:20,240
Vogliamo andare DynamoDB, completamente gestito,
Archivio dati NoSQL, il throughput disposizione.

2010
01:28:20,240 --> 01:28:22,680
Usiamo indici secondari.

2011
01:28:22,680 --> 01:28:26,154
Si tratta fondamentalmente di HTTP API e
include il supporto dei documenti.

2012
01:28:26,154 --> 01:28:28,570
Quindi non ci si deve preoccupare
nulla di tutto ciò partizionamento.

2013
01:28:28,570 --> 01:28:30,740
Facciamo tutto per voi.

2014
01:28:30,740 --> 01:28:33,260
Così ora, invece,
basta scrivere al tavolo.

2015
01:28:33,260 --> 01:28:36,490
Se la tabella deve essere partizionato,
che accade dietro le quinte.

2016
01:28:36,490 --> 01:28:40,642
Sei completamente isolato
da che come sviluppatore.

2017
01:28:40,642 --> 01:28:42,350
Quindi parliamo di
alcuni casi di utilizzo

2018
01:28:42,350 --> 01:28:47,564
che ci imbattiamo in nel gioco, comuni
scenari di gioco, classifica.

2019
01:28:47,564 --> 01:28:49,980
Così hai gli utenti in arrivo,
le BoardNames che stanno

2020
01:28:49,980 --> 01:28:52,930
su, i punteggi per questo utente.

2021
01:28:52,930 --> 01:28:57,700
Potremmo essere hashing sul UserID,
e poi abbiamo gamma sul gioco.

2022
01:28:57,700 --> 01:28:59,960
Così ogni utente vuole vedere
tutto il gioco che ha giocato

2023
01:28:59,960 --> 01:29:01,770
e tutto il suo punteggio più alto
attraverso tutto il gioco.

2024
01:29:01,770 --> 01:29:04,000
Ecco, questo è il suo classifica personale.

2025
01:29:04,000 --> 01:29:10,010
>> Ora voglio andare e voglio get--
in modo da ottenere queste classifiche personali.

2026
01:29:10,010 --> 01:29:12,827
Quello che voglio fare è andare a prendere
il punteggio più alto tra tutti gli utenti.

2027
01:29:12,827 --> 01:29:13,660
Allora, come faccio a farlo?

2028
01:29:13,660 --> 01:29:18,070
Quando il mio disco viene assegnata su
la UserID, spaziava sul gioco,

2029
01:29:18,070 --> 01:29:20,740
bene ho intenzione di andare avanti
e ristrutturare, creare un GSI,

2030
01:29:20,740 --> 01:29:22,370
e ho intenzione di ristrutturare tali dati.

2031
01:29:22,370 --> 01:29:27,310
>> Ora ho intenzione di hash sul
BoardName, che è il gioco.

2032
01:29:27,310 --> 01:29:29,800
E ho intenzione di spaziare sul punteggio superiore.

2033
01:29:29,800 --> 01:29:31,540
E ora ho creato diversi secchi.

2034
01:29:31,540 --> 01:29:34,790
Sto utilizzando la stessa tabella,
gli stessi dati voce.

2035
01:29:34,790 --> 01:29:39,870
Ma Sto creando un secchio che dà
mi un'aggregazione di punteggio più alto da gioco.

2036
01:29:39,870 --> 01:29:43,180
>> E posso interrogare quel tavolo
per ottenere tali informazioni.

2037
01:29:43,180 --> 01:29:50,890
Quindi ho messo quel modello di query fino a
essere sostenuta da un indice secondario.

2038
01:29:50,890 --> 01:29:54,556
Ora possono essere ordinati per BoardName
e ordinati per Topscore, seconda.

2039
01:29:54,556 --> 01:29:57,180
Così si può vedere, questi sono i tipi
di casi d'uso che si ottiene nel gioco.

2040
01:29:57,180 --> 01:30:02,190
Un altro buon caso di utilizzo entriamo in gioco
è premi e che ha vinto i premi.

2041
01:30:02,190 --> 01:30:05,340
E questo è un grande caso d'uso
dove noi chiamiamo indici sparse.

2042
01:30:05,340 --> 01:30:07,340
Sparse indici sono il
capacità di generare

2043
01:30:07,340 --> 01:30:10,850
un indice che non lo fa necessariamente
contenere ogni singolo elemento sul tavolo.

2044
01:30:10,850 --> 01:30:11,470
E perchè no?

2045
01:30:11,470 --> 01:30:14,540
Perché l'attributo che viene
indicizzato non esiste su ogni articolo.

2046
01:30:14,540 --> 01:30:16,460
>> Quindi, in questa particolare
uso caso, sto dicendo,

2047
01:30:16,460 --> 01:30:19,240
sai cosa, ho intenzione di
creare un attributo denominato Award.

2048
01:30:19,240 --> 01:30:22,970
E ho intenzione di dare ad ogni utente
che ha un premio che attributo.

2049
01:30:22,970 --> 01:30:25,950
Gli utenti che non dispongono di premi sono
non andando ad avere tale attributo.

2050
01:30:25,950 --> 01:30:27,800
Così, quando creo il
indice, gli unici utenti

2051
01:30:27,800 --> 01:30:28,960
che stanno per mostrare
nell'indice sono

2052
01:30:28,960 --> 01:30:31,050
quelli che effettivamente hanno vinto premi.

2053
01:30:31,050 --> 01:30:34,440
Ecco, questo è un ottimo modo per essere in grado
per creare indici filtrati che

2054
01:30:34,440 --> 01:30:40,580
sono molto, molto selettivo che non lo fanno
avere per indicizzare l'intera tabella.

2055
01:30:40,580 --> 01:30:43,050
>> Così siamo sempre a corto di tempo qui.

2056
01:30:43,050 --> 01:30:49,190
Ho intenzione di andare avanti e saltare
fuori e saltare questo scenario.

2057
01:30:49,190 --> 01:30:52,625
Parlare un po 'about--

2058
01:30:52,625 --> 01:30:54,460
>> PUBBLICO: Posso fare una domanda veloce?

2059
01:30:54,460 --> 01:30:56,722
Uno è scrivere pesante?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Che cosa è?

2061
01:30:57,680 --> 01:30:58,596
PUBBLICO: Scrivi pesante.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Scrivere pesante.

2063
01:31:01,270 --> 01:31:03,460
Fammi vedere.

2064
01:31:03,460 --> 01:31:06,220
>> PUBBLICO: O è che non
qualcosa che si può solo

2065
01:31:06,220 --> 01:31:08,809
voce in pochi secondi?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Andiamo
attraverso lo scenario di voto.

2067
01:31:10,850 --> 01:31:11,670
Non è così male.

2068
01:31:11,670 --> 01:31:14,580
Fate voi ragazzi avete qualche minuto?

2069
01:31:14,580 --> 01:31:15,860
OK.

2070
01:31:15,860 --> 01:31:17,890
>> Quindi parleremo di voto.

2071
01:31:17,890 --> 01:31:20,250
Così il voto in tempo reale, abbiamo
requisiti per il voto.

2072
01:31:20,250 --> 01:31:25,250
I requisiti sono che ci permettono
ogni persona di votare una sola volta.

2073
01:31:25,250 --> 01:31:28,060
Vogliamo che nessuno sia in grado
a cambiare il loro voto.

2074
01:31:28,060 --> 01:31:31,045
Vogliamo aggregazione in tempo reale
e analisi di dati demografici

2075
01:31:31,045 --> 01:31:34,210
che stiamo andando a essere
dimostrando di utenti sul sito.

2076
01:31:34,210 --> 01:31:35,200
>> Pensate a questo scenario.

2077
01:31:35,200 --> 01:31:37,550
Lavoriamo molto della realtà
TV mostra dove sono

2078
01:31:37,550 --> 01:31:38,960
facendo queste esatto tipo di cose.

2079
01:31:38,960 --> 01:31:41,584
Così si può pensare di scenario,
abbiamo milioni e milioni

2080
01:31:41,584 --> 01:31:43,959
ragazze di adolescenti là
con i loro telefoni cellulari

2081
01:31:43,959 --> 01:31:46,250
e il voto, e il voto, e
votare per chiunque essi siano

2082
01:31:46,250 --> 01:31:48,610
trova ad essere il più popolare.

2083
01:31:48,610 --> 01:31:50,830
Quindi questi sono alcuni dei
richieste di prenotazione esauriscono.

2084
01:31:50,830 --> 01:31:52,990
>> E così la prima prendere
per risolvere il problema

2085
01:31:52,990 --> 01:31:55,090
sarebbe di costruire un
molto semplice applicazione.

2086
01:31:55,090 --> 01:31:56,490
Così ho questa applicazione.

2087
01:31:56,490 --> 01:31:57,950
Ho alcuni elettori là fuori.

2088
01:31:57,950 --> 01:31:59,980
Vengono in, hanno colpito l'applicazione di voto.

2089
01:31:59,980 --> 01:32:03,440
Ho un po 'grezzo voti tavolo
Mi limiterò a discarica quei voti in.

2090
01:32:03,440 --> 01:32:05,780
Avrò qualche aggregato
voti tabella che

2091
01:32:05,780 --> 01:32:09,490
faranno i miei analisi e la demografia,
e metteremo tutto in là.

2092
01:32:09,490 --> 01:32:11,420
>> E questo è grande.

2093
01:32:11,420 --> 01:32:12,332
La vita è bella.

2094
01:32:12,332 --> 01:32:15,040
La vita è buona fino a quando abbiamo scoperto che
c'è sempre solo uno o due

2095
01:32:15,040 --> 01:32:16,879
persone che sono popolari in un'elezione.

2096
01:32:16,879 --> 01:32:19,420
Ci sono solo una o due cose
che le persone veramente a cuore.

2097
01:32:19,420 --> 01:32:22,340
E se si sta votando a
scala, tutto ad un tratto sono

2098
01:32:22,340 --> 01:32:26,360
andando a martellare l'inferno fuori di
due candidati, uno o due candidati.

2099
01:32:26,360 --> 01:32:29,390
Un numero molto limitato di articoli
persone trovano ad essere popolare.

2100
01:32:29,390 --> 01:32:31,710
>> Questo non è un buon modello di progettazione.

2101
01:32:31,710 --> 01:32:33,549
Questo è in realtà un
pessimo design pattern

2102
01:32:33,549 --> 01:32:36,340
perché crea esattamente ciò che
parlato che era tasti di scelta rapida.

2103
01:32:36,340 --> 01:32:38,960
Tasti di scelta rapida sono qualcosa che non ci piace.

2104
01:32:38,960 --> 01:32:40,470
>> Quindi, come possiamo risolvere questo?

2105
01:32:40,470 --> 01:32:47,640
E davvero, il modo per risolvere questo problema è
prendendo quelli secchi candidati

2106
01:32:47,640 --> 01:32:51,490
e per ogni candidato che abbiamo,
stiamo andando a aggiungere un valore casuale,

2107
01:32:51,490 --> 01:32:54,192
qualcosa che sappiamo, casuale
valore compreso tra uno e 100,

2108
01:32:54,192 --> 01:32:56,620
tra 100 e 1.000,
o tra uno e 1.000,

2109
01:32:56,620 --> 01:32:59,940
tuttavia molti valori casuali si desidera
aggiungere sulla fine di quel candidato.

2110
01:32:59,940 --> 01:33:01,330
>> E quello che ho fatto veramente, allora?

2111
01:33:01,330 --> 01:33:05,830
Se sto utilizzando l'ID candidato come
il secchio per voti aggregati,

2112
01:33:05,830 --> 01:33:08,780
se ho aggiunto un caso
numero alla fine di questo,

2113
01:33:08,780 --> 01:33:12,000
Ho creato la società 10 secchi, un
cento, mille secchi secchi

2114
01:33:12,000 --> 01:33:14,160
che sto aggregare voti in tutto.

2115
01:33:14,160 --> 01:33:18,030
>> Così ho milioni e milioni,
e milioni di record in arrivo

2116
01:33:18,030 --> 01:33:22,050
per questi candidati, ora sto diffondendo
quei voti in tutta A_1 Candidate

2117
01:33:22,050 --> 01:33:24,630
attraverso A_100 Candidato, perché
ogni volta che un voto entra,

2118
01:33:24,630 --> 01:33:26,530
Sto generando un casuale
valore compreso tra uno e 100.

2119
01:33:26,530 --> 01:33:29,446
Sto virata che sull'estremità del
il candidato che la persona di votare per.

2120
01:33:29,446 --> 01:33:31,120
Sto dumping in quel secchio.

2121
01:33:31,120 --> 01:33:33,910
>> Ora sul retro, lo so
che ho avuto un centinaio di secchi.

2122
01:33:33,910 --> 01:33:36,350
Così, quando ho voglia di andare avanti
e aggregare i voti,

2123
01:33:36,350 --> 01:33:38,244
Ho letto da tutti quelli secchi.

2124
01:33:38,244 --> 01:33:39,160
Così vado avanti e aggiungi.

2125
01:33:39,160 --> 01:33:42,410
E poi io la dispersione raccogliere
dove vado fuori e dire hey,

2126
01:33:42,410 --> 01:33:45,399
si sa che cosa, la chiave di questo candidato
spazi è oltre un centinaio di secchi.

2127
01:33:45,399 --> 01:33:47,940
Ho intenzione di raccogliere tutte le
voti da quei cento secchi.

2128
01:33:47,940 --> 01:33:49,981
Ho intenzione di aggregare
li e ho intenzione di dire,

2129
01:33:49,981 --> 01:33:53,830
Il candidato A ha ora
conteggio totale voto di x.

2130
01:33:53,830 --> 01:33:55,690
>> Ora sia la scrittura
query e la query di lettura

2131
01:33:55,690 --> 01:33:58,160
sono ben distribuite
perché sto scrivendo tutto

2132
01:33:58,160 --> 01:34:00,320
e sto leggendo su centinaia di chiavi.

2133
01:34:00,320 --> 01:34:03,500
Non sto scrivendo e
la lettura attraverso una chiave ora.

2134
01:34:03,500 --> 01:34:04,950
Ecco, questo è un grande modello.

2135
01:34:04,950 --> 01:34:08,090
>> Questo è in realtà probabilmente uno
del design più importante

2136
01:34:08,090 --> 01:34:10,420
modelli per scala NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Vedrete questo tipo di
modello di progettazione in ogni sapore.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, non è così
materia, tutti noi dobbiamo fare questo.

2139
01:34:19,100 --> 01:34:21,840
Perché quando hai a che fare
con quelle enormi aggregazioni,

2140
01:34:21,840 --> 01:34:26,650
si deve trovare un modo per
diffonderli fuori attraverso secchi.

2141
01:34:26,650 --> 01:34:29,512
Quindi questo è il modo di fare questo.

2142
01:34:29,512 --> 01:34:31,220
Va bene, e allora
si sta facendo in questo momento

2143
01:34:31,220 --> 01:34:35,252
è entrato in negoziazione fuori di lettura
costo per la scalabilità in scrittura.

2144
01:34:35,252 --> 01:34:37,085
Il costo della mia lettura è
un po 'più complesso

2145
01:34:37,085 --> 01:34:40,220
e devo andare leggere da un
cento secchi invece di uno.

2146
01:34:40,220 --> 01:34:41,310
Ma io sono in grado di scrivere.

2147
01:34:41,310 --> 01:34:44,860
E il mio rendimento, la mia scrittura
il throughput è incredibile.

2148
01:34:44,860 --> 01:34:49,450
Quindi è di solito una preziosa
tecnica per il ridimensionamento DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
o qualsiasi database NoSQL per quella materia.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Così abbiamo capito come la dimensioni.

2152
01:34:55,240 --> 01:34:56,930
E abbiamo capito come
eliminare i nostri tasti di scelta rapida.

2153
01:34:56,930 --> 01:34:57,820
E questo è fantastico.

2154
01:34:57,820 --> 01:34:58,960
E abbiamo ottenuto questo bel sistema.

2155
01:34:58,960 --> 01:35:02,043
E ci ha dato molto corretto voto
perché abbiamo record di voto de-babbeo.

2156
01:35:02,043 --> 01:35:03,130
E 'costruito in DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Abbiamo parlato di diritti condizionati.

2158
01:35:05,380 --> 01:35:08,170
>> Quando un elettore entra, mette
un inserimento nella tabella,

2159
01:35:08,170 --> 01:35:11,220
inseriscono con la loro ID elettore,
se si cerca di inserire un altro voto,

2160
01:35:11,220 --> 01:35:13,320
Faccio una scrittura condizionale.

2161
01:35:13,320 --> 01:35:16,960
Solo dire scrivere questo
se questo non esiste.

2162
01:35:16,960 --> 01:35:19,270
Così, non appena vedo che
che il voto di colpire il tavolo,

2163
01:35:19,270 --> 01:35:20,460
nessun altro sta per essere
in grado di mettere il loro voto in.

2164
01:35:20,460 --> 01:35:21,634
E questo è fantastico.

2165
01:35:21,634 --> 01:35:23,550
E stiamo incrementando
nostri sportelli candidati.

2166
01:35:23,550 --> 01:35:25,466
E stiamo facendo del nostro
demografia e tutto il resto.

2167
01:35:25,466 --> 01:35:29,110
Ma cosa succede se il mio
applicazione cade?

2168
01:35:29,110 --> 01:35:31,350
Ora, tutto ad un tratto voti
sono in arrivo, e io

2169
01:35:31,350 --> 01:35:34,840
Non so se stanno ottenendo trattati
nelle mie analisi e dati demografici

2170
01:35:34,840 --> 01:35:36,040
più.

2171
01:35:36,040 --> 01:35:38,462
E quando l'applicazione
torna su, come

2172
01:35:38,462 --> 01:35:41,420
diavolo faccio a sapere cosa hanno voti
stato elaborato e da dove si comincia?

2173
01:35:41,420 --> 01:35:44,530
>> Quindi questo è un vero problema quando si
iniziare a guardare questo tipo di scenario.

2174
01:35:44,530 --> 01:35:45,571
E come si fa a risolvere questo?

2175
01:35:45,571 --> 01:35:48,070
Risolviamo con quello che abbiamo
chiamare DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Streams è un tempo ordinato e
partizionato change log di ogni accesso

2177
01:35:53,470 --> 01:35:55,700
al tavolo, ogni scrittura
accesso alla tabella.

2178
01:35:55,700 --> 01:35:58,810
Tutti i dati che è scritto al
tabella mostra sul torrente.

2179
01:35:58,810 --> 01:36:01,815
>> Si tratta fondamentalmente di una coda di 24 ore.

2180
01:36:01,815 --> 01:36:03,690
Elementi colpito il torrente,
vivono per 24 ore.

2181
01:36:03,690 --> 01:36:05,990
Essi possono essere letti più volte.

2182
01:36:05,990 --> 01:36:09,400
Garantito da consegnare
solo una volta al torrente,

2183
01:36:09,400 --> 01:36:11,180
potrebbe essere letto n volte.

2184
01:36:11,180 --> 01:36:14,910
Così tuttavia molti processi che si desidera
consumare tali dati, si può consumare.

2185
01:36:14,910 --> 01:36:16,350
Apparirà ogni aggiornamento.

2186
01:36:16,350 --> 01:36:18,455
Ogni scrittura sarà solo
comparire una sola volta sul torrente.

2187
01:36:18,455 --> 01:36:20,621
Quindi non ci si deve preoccupare
circa il trattamento due volte

2188
01:36:20,621 --> 01:36:22,500
dallo stesso processo.

2189
01:36:22,500 --> 01:36:25,350
>> E 'severamente ordinato per articolo.

2190
01:36:25,350 --> 01:36:28,180
Quando diciamo tempo
ordinato e diviso,

2191
01:36:28,180 --> 01:36:30,680
vedrete per partizione sul torrente.

2192
01:36:30,680 --> 01:36:33,169
Vedrete articoli, aggiornamenti in ordine.

2193
01:36:33,169 --> 01:36:35,210
Noi non siamo garanti
sul flusso che sei

2194
01:36:35,210 --> 01:36:40,240
intenzione di ottenere ogni transazione
nell'ordine di tutti gli elementi.

2195
01:36:40,240 --> 01:36:42,440
>> Così flussi sono idempotente.

2196
01:36:42,440 --> 01:36:44,037
Dobbiamo tutti cosa idempotente significa?

2197
01:36:44,037 --> 01:36:46,620
Idempotent significa che si può fare
oltre, e oltre, e più volte.

2198
01:36:46,620 --> 01:36:48,200
Il risultato sarà lo stesso.

2199
01:36:48,200 --> 01:36:49,991
>> Flussi sono idempotente,
ma devono essere

2200
01:36:49,991 --> 01:36:54,860
giocato dal punto di partenza,
ovunque si desideri, fino alla fine,

2201
01:36:54,860 --> 01:36:57,950
o non comporteranno
negli stessi valori.

2202
01:36:57,950 --> 01:36:59,727
>> Stessa cosa con MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB è un costrutto
che chiamano la oplog.

2204
01:37:01,560 --> 01:37:04,140
E 'esattamente lo stesso costrutto.

2205
01:37:04,140 --> 01:37:06,500
Molti database NoSQL
avere questo costrutto.

2206
01:37:06,500 --> 01:37:08,790
Lo usano per fare le cose
come la replica, che

2207
01:37:08,790 --> 01:37:10,475
è esattamente quello che facciamo con i flussi.

2208
01:37:10,475 --> 01:37:12,350
PUBBLICO: Forse un
domanda eretica, ma voi

2209
01:37:12,350 --> 01:37:13,975
parlare di applicazioni facendo giù un così via.

2210
01:37:13,975 --> 01:37:16,089
Sono flussi garantiti
mai possibilmente andare giù?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Sì, i flussi
sono garantiti per non andare giù.

2212
01:37:18,630 --> 01:37:21,040
Gestiamo l'infrastruttura
alle spalle. ruscelli automaticamente

2213
01:37:21,040 --> 01:37:22,498
implementare nel loro gruppo ridimensionamento automatico.

2214
01:37:22,498 --> 01:37:25,910
Andremo attraverso un po '
po 'di quello che accade.

2215
01:37:25,910 --> 01:37:30,060
>> Non dovrei dire che non sono
garantito per non andare giù.

2216
01:37:30,060 --> 01:37:33,110
Gli elementi sono garantiti
ad apparire nel flusso.

2217
01:37:33,110 --> 01:37:36,740
E il flusso sarà accessibile.

2218
01:37:36,740 --> 01:37:40,580
Così che cosa va giù o ritorna
up, ciò accade sotto.

2219
01:37:40,580 --> 01:37:43,844
E covers-- è OK.

2220
01:37:43,844 --> 01:37:46,260
D'accordo, in modo da ottenere diversi
Tipi fuori dallo schermo.

2221
01:37:46,260 --> 01:37:51,040
I tipi di vista che sono importanti per un
programmatore in genere sono, che cosa era?

2222
01:37:51,040 --> 01:37:52,370
Ho la vecchia visione.

2223
01:37:52,370 --> 01:37:55,630
Quando un aggiornamento colpisce il tavolo, che sarà
spingere il vecchio vista del flusso

2224
01:37:55,630 --> 01:38:02,070
quindi i dati possono archiviare, o il cambiamento
il controllo, l'identificazione cambiamento, cambiamento

2225
01:38:02,070 --> 01:38:03,600
gestione.

2226
01:38:03,600 --> 01:38:07,160
>> La nuova immagine, quello che è ora, dopo
l'aggiornamento, questo è un altro tipo di vista

2227
01:38:07,160 --> 01:38:07,660
Puoi prendere.

2228
01:38:07,660 --> 01:38:09,660
È possibile ottenere sia le vecchie e nuove immagini.

2229
01:38:09,660 --> 01:38:10,660
Forse tutti e due che voglio.

2230
01:38:10,660 --> 01:38:11,790
Voglio vedere cosa fosse.

2231
01:38:11,790 --> 01:38:13,290
Voglio vedere che cosa è cambiato a.

2232
01:38:13,290 --> 01:38:15,340
>> Ho un tipo di conformità
di processo che corre.

2233
01:38:15,340 --> 01:38:17,430
Ha bisogno di verificare che
quando queste cose cambiano,

2234
01:38:17,430 --> 01:38:21,840
che sono entro certi limiti
o entro certi parametri.

2235
01:38:21,840 --> 01:38:23,840
>> E poi forse solo
bisogno di sapere cosa è cambiato.

2236
01:38:23,840 --> 01:38:26,240
Non mi interessa quello che è cambiato voce.

2237
01:38:26,240 --> 01:38:28,580
Non ho bisogno di bisogno di sapere
quali attributi cambiato.

2238
01:38:28,580 --> 01:38:30,882
Ho solo bisogno di sapere che
i prodotti sono toccati.

2239
01:38:30,882 --> 01:38:33,340
Quindi questi sono i tipi di viste
che si scende dal torrente

2240
01:38:33,340 --> 01:38:35,960
e si può interagire.

2241
01:38:35,960 --> 01:38:37,840
>> L'applicazione che
consuma il torrente,

2242
01:38:37,840 --> 01:38:39,298
questo è una specie di modo in cui funziona.

2243
01:38:39,298 --> 01:38:42,570
Cliente DynamoDB chiede di
spingere i dati nelle tabelle.

2244
01:38:42,570 --> 01:38:44,750
Flussi distribuire su ciò che chiamiamo cocci.

2245
01:38:44,750 --> 01:38:47,380
Frammenti vengono scalate
indipendentemente dalla tabella.

2246
01:38:47,380 --> 01:38:50,660
Essi non sono allineate completamente
per le partizioni del vostro tavolo.

2247
01:38:50,660 --> 01:38:52,540
E la ragione per cui è
perché si allineano

2248
01:38:52,540 --> 01:38:55,430
alla capacità, la corrente
capacità del tavolo.

2249
01:38:55,430 --> 01:38:57,600
>> Essi implementare nella loro
proprio gruppo ridimensionamento automatico,

2250
01:38:57,600 --> 01:39:00,800
e cominciano a girare fuori a seconda
da quante scritture sono in arrivo,

2251
01:39:00,800 --> 01:39:03,090
quanti reads-- realtà è scritto.

2252
01:39:03,090 --> 01:39:05,820
Non c'è reads-- ma come
diverse scritture sono in arrivo.

2253
01:39:05,820 --> 01:39:08,200
>> E poi sul retro
fine, abbiamo quello che

2254
01:39:08,200 --> 01:39:11,390
chiamare un KCL o Kinesis Client Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis è un flusso di dati
tecnologia di elaborazione da Amazon.

2256
01:39:19,190 --> 01:39:22,040
E torrenti è costruito su questo.

2257
01:39:22,040 --> 01:39:25,670
>> Quindi si utilizza un KCL abilitato
un'applicazione di leggere il flusso.

2258
01:39:25,670 --> 01:39:28,752
La Biblioteca Kinesis Cliente realtà
gestisce gli operai per voi.

2259
01:39:28,752 --> 01:39:30,460
E lo fa anche un po '
cose interessanti.

2260
01:39:30,460 --> 01:39:35,630
Si creerà alcune tabelle su
nel tablespace DynamoDB

2261
01:39:35,630 --> 01:39:38,410
per tracciare quali articoli
sono stati elaborati.

2262
01:39:38,410 --> 01:39:41,190
Quindi, in questo modo se cade indietro, se
essa cade e viene e ottiene

2263
01:39:41,190 --> 01:39:45,570
sorgeva il backup, è possibile determinare dove
era nella elaborazione del flusso.

2264
01:39:45,570 --> 01:39:48,360
>> Questo è molto importante quando si
stai parlando di replica.

2265
01:39:48,360 --> 01:39:50,350
Ho bisogno di sapere che cosa
dati sono stati elaborati stati

2266
01:39:50,350 --> 01:39:52,810
e quali dati sono ancora da elaborare.

2267
01:39:52,810 --> 01:39:57,380
Così la libreria KCL per i flussi saranno
vi darà un sacco di tale funzionalità.

2268
01:39:57,380 --> 01:39:58,990
Si prende cura di tutto il servizio di pulizia.

2269
01:39:58,990 --> 01:40:01,140
Si alza un lavoratore per ogni frammento.

2270
01:40:01,140 --> 01:40:04,620
Si crea una tabella amministrativo
per ogni frammento, per ogni lavoratore.

2271
01:40:04,620 --> 01:40:07,560
E come quelli dei lavoratori del fuoco,
mantengono tali tabelle

2272
01:40:07,560 --> 01:40:10,510
in modo da sapere questo record
è stato letto e trasformati.

2273
01:40:10,510 --> 01:40:13,850
E poi in questo modo se il processo
muore e torna in linea,

2274
01:40:13,850 --> 01:40:17,940
può riprendere a destra dove è decollato.

2275
01:40:17,940 --> 01:40:20,850
>> Quindi usiamo questo per
replica tra regione.

2276
01:40:20,850 --> 01:40:24,680
Molti clienti hanno la necessità di
spostare i dati o le parti di loro tabelle di dati

2277
01:40:24,680 --> 01:40:25,920
intorno alle diverse regioni.

2278
01:40:25,920 --> 01:40:29,230
Ci sono nove regioni
in tutto il mondo.

2279
01:40:29,230 --> 01:40:32,100
Quindi ci potrebbe essere un io need--
potrebbero avere gli utenti in Asia, gli utenti

2280
01:40:32,100 --> 01:40:34,150
nella costa orientale degli Stati Uniti.

2281
01:40:34,150 --> 01:40:38,980
Essi hanno dati diversi che
deve essere distribuito a livello locale.

2282
01:40:38,980 --> 01:40:42,510
E forse un utente vola da
Asia verso gli Stati Uniti,

2283
01:40:42,510 --> 01:40:45,020
e voglio replicare
i suoi dati con lui.

2284
01:40:45,020 --> 01:40:49,340
Così, quando si scende dall'aereo, ha
una buona esperienza con la sua app mobile.

2285
01:40:49,340 --> 01:40:52,360
>> È possibile utilizzare la cross-regione
biblioteca replica per fare questo.

2286
01:40:52,360 --> 01:40:55,730
Fondamentalmente abbiamo
fornito due tecnologie.

2287
01:40:55,730 --> 01:40:59,400
Uno è un'applicazione console è possibile
stare in piedi da soli istanza EC2.

2288
01:40:59,400 --> 01:41:01,240
Funziona replica puro.

2289
01:41:01,240 --> 01:41:02,720
E allora vi abbiamo dato la biblioteca.

2290
01:41:02,720 --> 01:41:06,070
La biblioteca è possibile utilizzare per costruire
la propria applicazione se si

2291
01:41:06,070 --> 01:41:10,740
voglia di fare cose folli con quella data--
filtro, replicare solo una parte di essa,

2292
01:41:10,740 --> 01:41:14,120
ruotare i dati, spostare in un
tabella diversa, così via e così via.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Ecco, questo è una specie di ciò che sembra.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams può essere
elaborati da ciò che noi chiamiamo Lambda.

2296
01:41:23,690 --> 01:41:27,394
Abbiamo detto un po 'di evento
architetture applicative guidato.

2297
01:41:27,394 --> 01:41:28,810
Lambda è un componente chiave di questo.

2298
01:41:28,810 --> 01:41:32,840
Lambda è il codice che spara su richiesta
in risposta a un evento particolare.

2299
01:41:32,840 --> 01:41:36,020
Uno di questi eventi può essere
disco che appare sul torrente.

2300
01:41:36,020 --> 01:41:39,100
Se un record appare sul torrente,
chiameremo questa funzione Java.

2301
01:41:39,100 --> 01:41:44,980
Bene, questo è JavaScript e Lambda
supporta Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
e presto sostenere
altre lingue.

2303
01:41:47,820 --> 01:41:50,940
E basti dire, è codice puro.

2304
01:41:50,940 --> 01:41:53,610
scrittura In Java, si definisce una classe.

2305
01:41:53,610 --> 01:41:55,690
Si preme il JAR su in Lambda.

2306
01:41:55,690 --> 01:42:00,200
E poi si specifica quale classe
chiamare in risposta al quale evento.

2307
01:42:00,200 --> 01:42:04,770
E poi l'infrastruttura Lambda
dietro che verrà eseguito il codice.

2308
01:42:04,770 --> 01:42:06,730
>> Quel codice in grado di elaborare
record fuori dal torrente.

2309
01:42:06,730 --> 01:42:08,230
Si può fare qualsiasi cosa che vuole con esso.

2310
01:42:08,230 --> 01:42:11,650
In questo particolare esempio, tutti siamo
realmente facendo sta registrando gli attributi.

2311
01:42:11,650 --> 01:42:13,480
Ma questo è solo codice.

2312
01:42:13,480 --> 01:42:15,260
Il codice può fare qualsiasi cosa, giusto?

2313
01:42:15,260 --> 01:42:16,600
>> Così è possibile ruotare i dati.

2314
01:42:16,600 --> 01:42:18,160
È possibile creare una vista derivata.

2315
01:42:18,160 --> 01:42:21,160
Se si tratta di una struttura del documento,
si può appiattire la struttura.

2316
01:42:21,160 --> 01:42:24,300
È possibile creare indici alternativi.

2317
01:42:24,300 --> 01:42:27,100
Tutti i tipi di cose che si possono
che fare con i flussi DynamoDB.

2318
01:42:27,100 --> 01:42:28,780
>> E davvero, questo è quello che sembra.

2319
01:42:28,780 --> 01:42:29,940
Così si ottiene tali aggiornamenti in arrivo.

2320
01:42:29,940 --> 01:42:31,190
Stanno venendo fuori la corda.

2321
01:42:31,190 --> 01:42:32,720
Sono letti dalla funzione Lambda.

2322
01:42:32,720 --> 01:42:37,480
Stanno rotazione i dati e
spingendola verso l'alto nelle tabelle derivate,

2323
01:42:37,480 --> 01:42:42,200
notificando sistemi esterni di cambiamento,
e spingendo i dati in ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Abbiamo parlato di come mettere la cache
davanti al database per le vendite

2325
01:42:45,900 --> 01:42:46,450
scenario.

2326
01:42:46,450 --> 01:42:50,049
Beh, che cosa succede se
aggiornare la descrizione articolo?

2327
01:42:50,049 --> 01:42:52,340
Beh, se avessi un Lambda
la funzione in esecuzione su quel tavolo,

2328
01:42:52,340 --> 01:42:55,490
se aggiorno la descrizione dell'oggetto, sarà
prendere il record fuori dal torrente,

2329
01:42:55,490 --> 01:42:58,711
e sarà aggiornare il ElastiCache
esempio con i nuovi dati.

2330
01:42:58,711 --> 01:43:00,460
Ecco, questo è un sacco di
ciò che facciamo con Lambda.

2331
01:43:00,460 --> 01:43:02,619
E 'il codice colla, connettori.

2332
01:43:02,619 --> 01:43:04,410
E dà realmente
la capacità di lanciare

2333
01:43:04,410 --> 01:43:07,930
e per eseguire applicazioni molto complesse
senza un server dedicato

2334
01:43:07,930 --> 01:43:10,371
infrastrutture, che è davvero cool.

2335
01:43:10,371 --> 01:43:13,100
>> Quindi torniamo al nostro
in tempo reale architettura votazioni.

2336
01:43:13,100 --> 01:43:17,984
Questo è nuovo e migliorato con la nostra
ruscelli e LKC abilitata applicazione.

2337
01:43:17,984 --> 01:43:20,150
Stessa di prima, possiamo
gestire qualsiasi scala di elezione.

2338
01:43:20,150 --> 01:43:21,100
Ci piace questo.

2339
01:43:21,100 --> 01:43:24,770
Stiamo facendo fuori raccoglie scatter
in più secchi.

2340
01:43:24,770 --> 01:43:26,780
Abbiamo blocco ottimistico in corso.

2341
01:43:26,780 --> 01:43:30,192
Siamo in grado di mantenere i nostri elettori
di cambiare i loro voti.

2342
01:43:30,192 --> 01:43:31,400
Possono votare solo una volta sola.

2343
01:43:31,400 --> 01:43:32,880
È fantastico.

2344
01:43:32,880 --> 01:43:35,895
Tolleranza ai guasti in tempo reale,
aggregazione scalabile ora.

2345
01:43:35,895 --> 01:43:38,270
Se la cosa cade, esso
sa dove per riavviare stesso

2346
01:43:38,270 --> 01:43:41,300
quando si tratta di eseguire il backup perché
stiamo utilizzando l'applicazione KCL.

2347
01:43:41,300 --> 01:43:45,700
E poi possiamo anche usare quella
Applicazione KCL per spingere i dati fuori

2348
01:43:45,700 --> 01:43:48,820
a redshift per altri
analisi delle applicazioni, o l'uso

2349
01:43:48,820 --> 01:43:51,990
le MapReduce elastici a correre
streaming in tempo reale aggregazioni off

2350
01:43:51,990 --> 01:43:53,180
di tali dati.

2351
01:43:53,180 --> 01:43:55,480
>> Quindi, queste sono le cose che noi
Non hanno parlato molto.

2352
01:43:55,480 --> 01:43:57,375
Ma sono aggiuntivo
tecnologie che vengono

2353
01:43:57,375 --> 01:44:00,310
a sopportare quando stai cercando
questi tipi di scenari.

2354
01:44:00,310 --> 01:44:03,160
>> Va bene, in modo che su di
analisi con DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
È possibile raccogliere de-babbeo
i dati, fare tutti i tipi

2356
01:44:05,340 --> 01:44:09,490
di roba bella, dati aggregati in
la memoria, creare tali tabelle derivati.

2357
01:44:09,490 --> 01:44:13,110
Questo è un enorme caso d'uso
che un sacco di clienti

2358
01:44:13,110 --> 01:44:16,950
sono coinvolti con, prendendo la nidificato
proprietà di tali documenti JSON

2359
01:44:16,950 --> 01:44:18,946
e la creazione di indici aggiuntivi.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Siamo alla fine.

2362
01:44:23,150 --> 01:44:26,689
Grazie per cuscinetto con me.

2363
01:44:26,689 --> 01:44:28,480
Quindi parliamo di
architettura di riferimento.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB si trova nel mezzo di così
gran parte dell'infrastruttura AWS.

2365
01:44:33,440 --> 01:44:37,090
Fondamentalmente si può collegarlo
fino a tutto quello che vuoi.

2366
01:44:37,090 --> 01:44:45,600
Le applicazioni create utilizzando Dynamo includono
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
spingere i dati fuori in elastico
MapReduce, import export da DynamoDB

2368
01:44:49,890 --> 01:44:52,370
in S3, tutti i tipi di flussi di lavoro.

2369
01:44:52,370 --> 01:44:54,120
Ma probabilmente il migliore
cosa di cui parlare,

2370
01:44:54,120 --> 01:44:56,119
e questo è ciò che è realmente
interessante è quando noi

2371
01:44:56,119 --> 01:44:58,350
parlare di applicazioni event-driven.

2372
01:44:58,350 --> 01:45:00,300
>> Questo è un esempio di
un progetto interno

2373
01:45:00,300 --> 01:45:04,850
che abbiamo dove siamo realmente
pubblicazione per raccogliere i risultati dell'indagine.

2374
01:45:04,850 --> 01:45:07,700
Quindi, in un collegamento e-mail che
inviamo fuori, ci sarò

2375
01:45:07,700 --> 01:45:11,350
essere un po 'click collegamento dicendo
qui a rispondere al sondaggio.

2376
01:45:11,350 --> 01:45:14,070
E quando una persona fa clic
quel collegamento, ciò che accade

2377
01:45:14,070 --> 01:45:18,020
è tirano giù un sicuro
Modulo di indagine HTML da S3.

2378
01:45:18,020 --> 01:45:18,980
Non c'è alcun server.

2379
01:45:18,980 --> 01:45:20,600
Questo è solo un oggetto S3.

2380
01:45:20,600 --> 01:45:22,770
>> Quella forma viene in su,
carica nel browser.

2381
01:45:22,770 --> 01:45:24,240
E 'ottenuto Backbone.

2382
01:45:24,240 --> 01:45:30,160
E 'ottenuto complesso JavaScript
che è in esecuzione.

2383
01:45:30,160 --> 01:45:33,557
Quindi è molto ricco applicazione
in esecuzione nel browser del client.

2384
01:45:33,557 --> 01:45:36,390
Non sanno che non sono
interagire con un server back-end.

2385
01:45:36,390 --> 01:45:38,220
A questo punto, è tutto browser.

2386
01:45:38,220 --> 01:45:41,780
>> Pubblicano i risultati a ciò che
che noi chiamiamo l'Amazzonia gateway API.

2387
01:45:41,780 --> 01:45:46,270
Gateway API è semplicemente una API web
che è possibile definire e collegare

2388
01:45:46,270 --> 01:45:47,760
o qualsiasi altra cosa.

2389
01:45:47,760 --> 01:45:50,990
In questo caso particolare, siamo
collegato ad una funzione Lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Così la mia operazione POST
accadendo con nessun server.

2391
01:45:54,797 --> 01:45:56,380
Fondamentalmente che gateway API sta lì.

2392
01:45:56,380 --> 01:45:58,770
Mi costa nulla finché la gente
iniziare a postare ad esso, giusto?

2393
01:45:58,770 --> 01:46:00,269
La funzione Lambda appena ci si siede.

2394
01:46:00,269 --> 01:46:03,760
E mi costa nulla fino
la gente inizia colpirlo.

2395
01:46:03,760 --> 01:46:07,270
Così si può vedere, come il volume
aumenta, in quel momento che le accuse arrivano.

2396
01:46:07,270 --> 01:46:09,390
Non sto in esecuzione un server 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Così ho tirare il modulo
giù dal secchio,

2398
01:46:12,310 --> 01:46:15,719
e vi posto attraverso l'API
Gateway nella funzione Lambda.

2399
01:46:15,719 --> 01:46:17,510
E poi il Lambda
Funzione dice, sai

2400
01:46:17,510 --> 01:46:20,600
ciò, ho alcuni PII, alcuni
informazioni di identificazione personale

2401
01:46:20,600 --> 01:46:21,480
in queste risposte.

2402
01:46:21,480 --> 01:46:23,020
Ho avuto i commenti provenienti da utenti.

2403
01:46:23,020 --> 01:46:24,230
Ho indirizzi e-mail.

2404
01:46:24,230 --> 01:46:26,190
Ho i nomi utente.

2405
01:46:26,190 --> 01:46:27,810
>> Permettetemi di dividere questa via.

2406
01:46:27,810 --> 01:46:30,280
Ho intenzione di generare un certo
metadati fuori questo disco.

2407
01:46:30,280 --> 01:46:32,850
E ho intenzione di spingere la
metadati in DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
E potrei crittografare tutti i dati
e spingerlo in DynamoDB se voglio.

2409
01:46:36,059 --> 01:46:38,600
Ma è più facile per me, in questo
utilizzare caso, di andare avanti un esempio,

2410
01:46:38,600 --> 01:46:42,800
Ho intenzione di spingere i dati grezzi
in un secchio S3 crittografato.

2411
01:46:42,800 --> 01:46:47,240
Così ho utilizzare costruito in lato server S3
crittografia e gestione delle chiavi di Amazon

2412
01:46:47,240 --> 01:46:51,600
Servizio in modo da avere una chiave che
può ruotare a intervalli regolari,

2413
01:46:51,600 --> 01:46:55,010
e posso proteggere i dati PII
come parte di tutto questo flusso di lavoro.

2414
01:46:55,010 --> 01:46:55,870
>> Allora, cosa ho fatto?

2415
01:46:55,870 --> 01:47:00,397
Ho appena implementato un intero
applicazione, e non ho alcun server.

2416
01:47:00,397 --> 01:47:02,980
Quindi, è ciò che l'applicazione event driven
architettura fa per voi.

2417
01:47:02,980 --> 01:47:05,730
>> Ora, se ci pensate
il caso d'uso per questo--

2418
01:47:05,730 --> 01:47:08,730
abbiamo altri clienti di cui sto parlando
per questo esatto architettura che

2419
01:47:08,730 --> 01:47:14,560
eseguire fenomenale grandi campagne, che
stanno guardando questo e andare, oh mio.

2420
01:47:14,560 --> 01:47:17,840
Perché ora, possono
fondamentalmente spingerlo fuori là,

2421
01:47:17,840 --> 01:47:21,900
lasciare che la campagna solo sedersi
lì fino a quando non lancia, e non

2422
01:47:21,900 --> 01:47:24,400
devono preoccuparsi un fico su
che tipo di infrastruttura

2423
01:47:24,400 --> 01:47:26,120
sta per essere lì per sostenerlo.

2424
01:47:26,120 --> 01:47:28,600
E poi, non appena
che la campagna è fatto,

2425
01:47:28,600 --> 01:47:31,520
è come l'infrastruttura
va solo subito via

2426
01:47:31,520 --> 01:47:33,680
perché non c'è davvero
è alcuna infrastruttura.

2427
01:47:33,680 --> 01:47:35,660
E 'solo il codice che si trova sulla Lambda.

2428
01:47:35,660 --> 01:47:38,560
E 'solo i dati che si trova in DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Si tratta di un fantastico modo
per creare applicazioni.

2430
01:47:41,340 --> 01:47:43,970
>> PUBBLICO: Quindi è più
effimero quanto lo sarebbe

2431
01:47:43,970 --> 01:47:45,740
se è stato memorizzato in un server vero e proprio?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Assolutamente.

2433
01:47:46,823 --> 01:47:49,190
Poiché tale istanza del server
avrebbe dovuto essere un 7/24.

2434
01:47:49,190 --> 01:47:51,954
Deve essere disponibile per
qualcuno per rispondere a.

2435
01:47:51,954 --> 01:47:52,620
Beh indovinate un po?

2436
01:47:52,620 --> 01:47:55,410
S3 è disponibile 24/7.

2437
01:47:55,410 --> 01:47:57,100
S3 risponde sempre.

2438
01:47:57,100 --> 01:47:59,320
E S3 è molto, molto buono
a servire gli oggetti.

2439
01:47:59,320 --> 01:48:02,590
Gli oggetti possono essere file HTML, o
File JavaScript, o quello che volete.

2440
01:48:02,590 --> 01:48:07,430
È possibile eseguire le applicazioni web molto ricchi
fuori secchi S3, e la gente fa.

2441
01:48:07,430 --> 01:48:10,160
>> E così questa è l'idea qui
è quello di allontanarsi dalla strada

2442
01:48:10,160 --> 01:48:11,270
eravamo abituati a pensarci.

2443
01:48:11,270 --> 01:48:14,270
Siamo tutti abituati a pensare in
termini di server e host.

2444
01:48:14,270 --> 01:48:16,580
Non si tratta di più così.

2445
01:48:16,580 --> 01:48:19,310
Si tratta di infrastrutture come codice.

2446
01:48:19,310 --> 01:48:22,470
Distribuire il codice per la nube e
lasciare che la nube funzionare per voi.

2447
01:48:22,470 --> 01:48:24,980
Ed è quello che AWS sta cercando di fare.

2448
01:48:24,980 --> 01:48:29,690
>> PUBBLICO: Così il vostro contenitore di oro nel mezzo
del gateway API non è il server-like,

2449
01:48:29,690 --> 01:48:30,576
ma invece è solo--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Si può pensare
di come facciata del server.

2451
01:48:32,850 --> 01:48:38,040
Tutto ciò che è è ci vorrà un HTTP
richiesta e la mappa di un altro processo.

2452
01:48:38,040 --> 01:48:39,192
Questo è tutto ciò che fa.

2453
01:48:39,192 --> 01:48:41,525
E in questo caso, stiamo mappando
ad una funzione Lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Va bene, allora questo è tutto quello che ho.

2456
01:48:45,410 --> 01:48:46,190
Grazie mille.

2457
01:48:46,190 --> 01:48:46,800
Lo apprezzo.

2458
01:48:46,800 --> 01:48:48,100
So che ci vuole un po 'nel corso del tempo.

2459
01:48:48,100 --> 01:48:49,980
E si spera voi ragazzi avete
un po 'di informazioni

2460
01:48:49,980 --> 01:48:51,410
che si può prendere via oggi.

2461
01:48:51,410 --> 01:48:53,520
E mi scuso se sono andato
su alcune delle vostre teste,

2462
01:48:53,520 --> 01:48:56,697
ma c'è un sacco di buona
conoscenze fondamentali fondazionale

2463
01:48:56,697 --> 01:48:58,280
che secondo me è molto importante per voi.

2464
01:48:58,280 --> 01:48:59,825
Quindi grazie per avermi.

2465
01:48:59,825 --> 01:49:00,325
[APPLAUSI]

2466
01:49:00,325 --> 01:49:02,619
PUBBLICO: [incomprensibile]
è quando dicevi

2467
01:49:02,619 --> 01:49:05,160
si doveva passare attraverso la cosa
dall'inizio alla fine

2468
01:49:05,160 --> 01:49:07,619
per ottenere i valori giusti
o gli stessi valori,

2469
01:49:07,619 --> 01:49:09,410
come sarebbe i valori
cambiare se [incomprensibile].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, idempotente?

2471
01:49:10,480 --> 01:49:11,800
Come potrebbero i valori cambiare?

2472
01:49:11,800 --> 01:49:15,180
Beh, perché se io non corro
tutto fino alla fine,

2473
01:49:15,180 --> 01:49:19,770
poi non so cosa cambia
sono stati effettuati nell'ultimo miglio.

2474
01:49:19,770 --> 01:49:22,144
Non sarà il
stessi dati come quello che ho visto.

2475
01:49:22,144 --> 01:49:24,560
PUBBLICO: Oh, quindi basta
non hanno ottenuto l'intero input.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Giusto.

2477
01:49:24,770 --> 01:49:26,895
Dovete andare dall'inizio
alla fine, e quindi è

2478
01:49:26,895 --> 01:49:29,280
sta per essere uno stato coerente.

2479
01:49:29,280 --> 01:49:31,520
Raffreddare.

2480
01:49:31,520 --> 01:49:35,907
>> PUBBLICO: Così ci ha mostrato DynamoDB
può fare documento o il valore della chiave.

2481
01:49:35,907 --> 01:49:38,740
E abbiamo passato un sacco di tempo sul
valore di chiave con un hash e modi

2482
01:49:38,740 --> 01:49:40,005
per capovolgere in giro.

2483
01:49:40,005 --> 01:49:43,255
Quando hai guardato quei tavoli, è che
lasciandosi alle spalle l'approccio del documento?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: non vorrei
dire lasciando alle spalle.

2485
01:49:44,600 --> 01:49:45,855
>> PUBBLICO: Sono stati separati da the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Con il documento
approccio, il tipo di documento in DynamoDB

2487
01:49:49,140 --> 01:49:50,880
è solo pensare come un altro attributo.

2488
01:49:50,880 --> 01:49:53,560
Si tratta di un attributo che contiene
una struttura di dati gerarchica.

2489
01:49:53,560 --> 01:49:56,980
E poi nelle query,
è possibile utilizzare le proprietà

2490
01:49:56,980 --> 01:49:59,480
di quegli oggetti utilizzando Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Così posso filtrare su un nidificato
di proprietà del documento JSON.

2492
01:50:03,562 --> 01:50:05,520
PUBBLICO: Così ogni volta che mi
fare un approccio del documento,

2493
01:50:05,520 --> 01:50:07,906
Posso sorta di arrivare al tabular--

2494
01:50:07,906 --> 01:50:08,780
PUBBLICO: Assolutamente.

2495
01:50:08,780 --> 01:50:09,800
Pubblico: --indexes e
cose che proprio parlato.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Sì, il
indici e tutto ciò che,

2497
01:50:11,280 --> 01:50:13,363
quando si vuole indicizzare il
proprietà del JSON,

2498
01:50:13,363 --> 01:50:18,230
il modo in cui avremmo dovuto farlo è se
si inserisce un oggetto JSON o di un documento

2499
01:50:18,230 --> 01:50:20,780
in Dynamo, è necessario utilizzare i flussi.

2500
01:50:20,780 --> 01:50:22,400
Flussi leggevano l'ingresso.

2501
01:50:22,400 --> 01:50:24,340
Si otterrebbe che JSON
Oggetto e avresti detto OK,

2502
01:50:24,340 --> 01:50:26,030
qual è la proprietà che voglio index?

2503
01:50:26,030 --> 01:50:28,717
>> È possibile creare una tabella derivata.

2504
01:50:28,717 --> 01:50:30,300
Ora che è il modo in cui funziona adesso.

2505
01:50:30,300 --> 01:50:32,650
Noi non vi consentono di indicizzare
direttamente tali proprietà.

2506
01:50:32,650 --> 01:50:33,520
>> PUBBLICO: Tabularizing vostri documenti.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: Esattamente, appiattimento
esso, tabularizing, esattamente.

2508
01:50:36,230 --> 01:50:37,415
Questo è quello che si fa con esso.

2509
01:50:37,415 --> 01:50:37,860
>> PUBBLICO: Grazie.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Sì,
assolutamente, grazie.

2511
01:50:39,609 --> 01:50:42,240
PUBBLICO: Quindi è una specie di
Mongo incontra classifers Redis.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Sì,
è molto simile.

2513
01:50:43,990 --> 01:50:45,940
Questa è una buona descrizione per questo.

2514
01:50:45,940 --> 01:50:47,490
Raffreddare.

2515
01:50:47,490 --> 01:50:49,102