1
00:00:00,000 --> 00:00:04,969
>> [Música tocando]

2
00:00:04,969 --> 00:00:06,010
RICK HOULIHAN: Tudo bem.

3
00:00:06,010 --> 00:00:06,600
Oi pessoal.

4
00:00:06,600 --> 00:00:07,670
Meu nome é Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Eu sou um diretor sênior
arquiteto de soluções da AWS.

6
00:00:10,330 --> 00:00:14,070
Concentro-me em NoSQL e
Tecnologias DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Estou aqui hoje para falar com
você um pouco sobre aqueles.

8
00:00:16,930 --> 00:00:18,970
>> Minha formação é
principalmente na camada de dados.

9
00:00:18,970 --> 00:00:21,390
Passei metade da minha desenvolvimento
escrita da carreira de banco de dados,

10
00:00:21,390 --> 00:00:25,930
acesso a dados, soluções
para várias aplicações.

11
00:00:25,930 --> 00:00:30,000
Eu estive em virtualização em nuvem
por cerca de 20 anos.

12
00:00:30,000 --> 00:00:33,460
Então, antes que a nuvem se a nuvem,
costumávamos chamá-lo de utility computing.

13
00:00:33,460 --> 00:00:37,170
E a ideia foi, é como
PG & E, você paga pelo que usa.

14
00:00:37,170 --> 00:00:38,800
Hoje nós o chamamos de nuvem.

15
00:00:38,800 --> 00:00:41,239
>> Mas ao longo dos anos, eu tenho trabalhado
para um par de empresas

16
00:00:41,239 --> 00:00:42,530
você provavelmente nunca ouviu falar.

17
00:00:42,530 --> 00:00:47,470
Mas eu compilei uma lista de técnico
realizações, eu acho que você diria.

18
00:00:47,470 --> 00:00:51,620
Eu tenho oito patentes em sistemas em nuvem
virtualização, design de microprocessadores,

19
00:00:51,620 --> 00:00:54,440
processamento de eventos complexos,
e outras áreas.

20
00:00:54,440 --> 00:00:58,290
>> Então, esses dias, vou me concentrar principalmente sobre NoSQL
tecnologias e da próxima geração

21
00:00:58,290 --> 00:00:59,450
banco de dados.

22
00:00:59,450 --> 00:01:03,370
E isso é geralmente o que eu vou
estar aqui falando com você hoje sobre.

23
00:01:03,370 --> 00:01:06,030
Então, o que você pode esperar
a partir desta sessão,

24
00:01:06,030 --> 00:01:08,254
nós vamos passar por um breve
história de processamento de dados.

25
00:01:08,254 --> 00:01:10,420
É sempre útil
compreender de onde viemos

26
00:01:10,420 --> 00:01:12,400
e por isso que estamos onde estamos.

27
00:01:12,400 --> 00:01:15,600
E vamos falar um pouco
pouco sobre tecnologia NoSQL

28
00:01:15,600 --> 00:01:17,500
a partir de um ponto de vista fundamental.

29
00:01:17,500 --> 00:01:19,870
>> Nós vamos entrar em algumas das
os internos DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB é da AWS não sabor.

31
00:01:24,350 --> 00:01:27,340
É um totalmente gerenciado e
solução NoSQL hospedado.

32
00:01:27,340 --> 00:01:32,420
E nós vamos falar um pouco sobre a tabela
estrutura, APIs, tipos de dados, índices,

33
00:01:32,420 --> 00:01:35,177
e algumas das partes internas
de que a tecnologia DynamoDB.

34
00:01:35,177 --> 00:01:37,760
Nós vamos entrar em algum do design
padrões e melhores práticas.

35
00:01:37,760 --> 00:01:39,968
Nós vamos falar sobre como você
utilizar esta tecnologia para alguns

36
00:01:39,968 --> 00:01:41,430
as aplicações de hoje.

37
00:01:41,430 --> 00:01:44,820
E então nós vamos falar um pouco
sobre a evolução ou a emergência

38
00:01:44,820 --> 00:01:48,980
de um novo paradigma na programação
chamados aplicativos orientados a eventos

39
00:01:48,980 --> 00:01:51,580
e como DynamoDB desempenha em que, como bem.

40
00:01:51,580 --> 00:01:54,690
E nós vamos deixar você um pouco de
uma arquitetura de referência discussão

41
00:01:54,690 --> 00:01:59,540
assim que nós podemos falar sobre algumas das
as maneiras que você pode usar DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Então, primeiro off-- esta é uma questão
Eu ouço muito é, o que é um banco de dados.

43
00:02:04,116 --> 00:02:06,240
Muita gente acha que eles
sabe o que é um banco de dados.

44
00:02:06,240 --> 00:02:08,360
Se você Google, você vai ver isso.

45
00:02:08,360 --> 00:02:11,675
É uma de um conjunto estruturado de dados realizada
em um computador, especialmente um que

46
00:02:11,675 --> 00:02:13,600
é acessível de várias maneiras.

47
00:02:13,600 --> 00:02:16,992
Acho que é uma boa
definição de um banco de dados moderno.

48
00:02:16,992 --> 00:02:19,450
Mas eu não gosto, porque
ela implica um par de coisas.

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

50
00:02:20,935 --> 00:02:23,120
E isso implica que é em um computador.

51
00:02:23,120 --> 00:02:25,750
E bases de dados não
sempre existir em computadores.

52
00:02:25,750 --> 00:02:28,020
Bases de dados, na verdade existia em muitas maneiras.

53
00:02:28,020 --> 00:02:32,000
>> Assim, uma melhor definição de um
banco de dados é algo como isto.

54
00:02:32,000 --> 00:02:34,786
Um banco de dados é uma organizada
mecanismo para armazenamento, gerenciamento,

55
00:02:34,786 --> 00:02:35,910
e recuperação de informações.

56
00:02:35,910 --> 00:02:36,868
Isto é de About.com.

57
00:02:36,868 --> 00:02:42,080
Então, eu gosto disso porque ele realmente fala
sobre uma base de dados de ser um repositório,

58
00:02:42,080 --> 00:02:44,800
um repositório de
informações, não necessariamente

59
00:02:44,800 --> 00:02:46,780
algo que se sente em um computador.

60
00:02:46,780 --> 00:02:49,290
E ao longo da história, nós
nem sempre tiveram computadores.

61
00:02:49,290 --> 00:02:52,110
>> Agora, se eu perguntar a média
desenvolvedor de hoje o que é

62
00:02:52,110 --> 00:02:54,770
um banco de dados, essa é a resposta que recebo.

63
00:02:54,770 --> 00:02:56,070
Em algum lugar que eu possa manter o material.

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

65
00:02:56,670 --> 00:02:58,725
E é verdade.

66
00:02:58,725 --> 00:02:59,600
Mas é lamentável.

67
00:02:59,600 --> 00:03:02,700
Porque o banco de dados é realmente
a fundação do app moderno.

68
00:03:02,700 --> 00:03:04,810
É a fundação
de cada aplicação.

69
00:03:04,810 --> 00:03:07,240
E como você construir esse
banco de dados, como você estrutura

70
00:03:07,240 --> 00:03:11,750
que dados vai ditar como que
aplicação executa como você escala.

71
00:03:11,750 --> 00:03:14,640
>> Assim, muito do meu trabalho hoje
é lidar com o que

72
00:03:14,640 --> 00:03:17,180
acontece quando os desenvolvedores
adotar essa abordagem

73
00:03:17,180 --> 00:03:19,510
e lidando com as conseqüências
de um aplicativo que

74
00:03:19,510 --> 00:03:24,966
agora está ampliando para além do original
intenção e sofrimento de mau design.

75
00:03:24,966 --> 00:03:26,840
Portanto, esperamos que quando você
ir embora hoje, você vai

76
00:03:26,840 --> 00:03:29,010
tem um par de ferramentas em
seu cinto que vai mantê-lo

77
00:03:29,010 --> 00:03:32,566
de fazer os mesmos erros.

78
00:03:32,566 --> 00:03:33,066
Tudo certo.

79
00:03:33,066 --> 00:03:36,360
Então vamos falar sobre um pouco de
a linha do tempo da tecnologia de banco de dados.

80
00:03:36,360 --> 00:03:38,830
Acho que eu li um
artigo não muito tempo atrás

81
00:03:38,830 --> 00:03:43,020
e ele disse algo sobre o lines--
é uma afirmação muito poético.

82
00:03:43,020 --> 00:03:46,590
Ele disse que a história
de processamento de dados é

83
00:03:46,590 --> 00:03:49,350
cheio de altos marcas d'água
abundância de dados.

84
00:03:49,350 --> 00:03:49,920
ESTÁ BEM.

85
00:03:49,920 --> 00:03:52,532
Agora, eu acho que é o tipo de verdade.

86
00:03:52,532 --> 00:03:54,990
Mas eu realmente olhar é como
a história é realmente cheio

87
00:03:54,990 --> 00:03:56,820
com marca de água de alta pressão de dados.

88
00:03:56,820 --> 00:04:00,040
Uma vez que a taxa de dados
Ingestão Nunca vai para baixo.

89
00:04:00,040 --> 00:04:01,360
Ele só vai para cima.

90
00:04:01,360 --> 00:04:03,670
>> E a inovação ocorre quando
vemos pressão de dados, que

91
00:04:03,670 --> 00:04:07,825
representa a quantidade de dados que é
Agora, no que entra no sistema.

92
00:04:07,825 --> 00:04:12,027
E não pode ser processado
eficientemente, quer no tempo ou em custo.

93
00:04:12,027 --> 00:04:14,110
E foi aí que começamos
a olhar para a pressão de dados.

94
00:04:14,110 --> 00:04:15,920
>> Assim, quando olhamos para o
primeira base de dados, esta

95
00:04:15,920 --> 00:04:17,180
é a única que estava entre os nossos ouvidos.

96
00:04:17,180 --> 00:04:18,310
Todos nós nascemos com ele.

97
00:04:18,310 --> 00:04:19,194
É um banco de dados bom.

98
00:04:19,194 --> 00:04:21,110
Ele tem uma alta disponibilidade.

99
00:04:21,110 --> 00:04:21,959
É sempre ligado.

100
00:04:21,959 --> 00:04:23,930
Você sempre pode obtê-lo.

101
00:04:23,930 --> 00:04:24,890
>> Mas é único usuário.

102
00:04:24,890 --> 00:04:26,348
Eu não posso compartilhar meus pensamentos com você.

103
00:04:26,348 --> 00:04:28,370
Você não pode obter os meus pensamentos
quando você quer que eles.

104
00:04:28,370 --> 00:04:30,320
E a sua abilitiy não é tão bom.

105
00:04:30,320 --> 00:04:32,510
Esquecemo-nos de coisas.

106
00:04:32,510 --> 00:04:36,540
De vez em quando, um de nós folhas
e se move para outra existência

107
00:04:36,540 --> 00:04:39,110
e perdemos tudo
que estava no banco de dados.

108
00:04:39,110 --> 00:04:40,640
Então isso não é tudo o que é bom.

109
00:04:40,640 --> 00:04:43,189
>> E isso funcionou bem ao longo do tempo
quando estávamos de volta ao dia

110
00:04:43,189 --> 00:04:46,230
quando tudo o que realmente precisava saber é
onde estamos indo para ir amanhã

111
00:04:46,230 --> 00:04:49,630
ou onde nos reunimos a melhor comida.

112
00:04:49,630 --> 00:04:52,820
Mas quando começamos a crescer como
civilização e governo começou

113
00:04:52,820 --> 00:04:55,152
para vir a ser, e
as empresas começaram a evoluir,

114
00:04:55,152 --> 00:04:57,360
nós começamos a perceber que
precisamos de um pouco mais do que o

115
00:04:57,360 --> 00:04:58,210
poderíamos colocar na nossa cabeça.

116
00:04:58,210 --> 00:04:58,870
Tudo certo?

117
00:04:58,870 --> 00:05:00,410
>> Precisávamos de sistemas de registro.

118
00:05:00,410 --> 00:05:02,220
Precisávamos de lugares para ser armazenar dados capazes.

119
00:05:02,220 --> 00:05:05,450
Então começamos a escrever documentos,
a criação de bibliotecas e arquivos.

120
00:05:05,450 --> 00:05:08,000
Começamos a desenvolver um
sistema de contabilidade Ledger.

121
00:05:08,000 --> 00:05:12,200
E que o sistema de contagem de contabilidade
correu o mundo por muitos séculos,

122
00:05:12,200 --> 00:05:15,580
e talvez até mesmo milênios, como
nós meio que cresceu a tal ponto

123
00:05:15,580 --> 00:05:18,420
onde essa carga de dados superou
a capacidade desses sistemas

124
00:05:18,420 --> 00:05:19,870
para ser capaz de conter.

125
00:05:19,870 --> 00:05:22,070
>> E isso realmente aconteceu na década de 1880.

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

127
00:05:22,570 --> 00:05:24,390
No Censo de 1880 dos EUA.

128
00:05:24,390 --> 00:05:26,976
Isto é realmente onde a viragem
apontar processamento de dados moderno.

129
00:05:26,976 --> 00:05:28,850
Este é o ponto em
que a quantidade de dados

130
00:05:28,850 --> 00:05:32,060
que estava sendo recolhidas pela
Governo dos Estados Unidos chegou a um ponto

131
00:05:32,060 --> 00:05:34,005
onde ele levou oito anos para ser processado.

132
00:05:34,005 --> 00:05:36,350
>> Agora, oito anos-- como
você sabe, o censo

133
00:05:36,350 --> 00:05:39,180
sai a cada 10 anos-- por isso é
bastante óbvio que pelo tempo que

134
00:05:39,180 --> 00:05:41,419
obteve o censo de 1890,
a quantidade de dados que

135
00:05:41,419 --> 00:05:43,210
ia ser processado
pelo governo foi

136
00:05:43,210 --> 00:05:46,335
vai exceder os 10 anos que
seria necessário para lançar o novo censo.

137
00:05:46,335 --> 00:05:47,250
Este foi um problema.

138
00:05:47,250 --> 00:05:49,000
>> Então, um cara chamado Herman
Hollerith veio junto

139
00:05:49,000 --> 00:05:52,640
e ele inventou registro soco unidade
cartões, leitor de cartões perfurados, cartões perfurados

140
00:05:52,640 --> 00:05:58,420
tabulator, eo agrupamento de
os mecanismos para essa tecnologia.

141
00:05:58,420 --> 00:06:01,860
E que a empresa que ele formou no
tempo, juntamente com um par de outros,

142
00:06:01,860 --> 00:06:05,450
na verdade, tornou-se um dos pilares de uma
pequena empresa que conhecemos hoje chamada IBM.

143
00:06:05,450 --> 00:06:08,417
>> Então IBM originalmente estava em
base de dados da empresa.

144
00:06:08,417 --> 00:06:09,750
E isso é realmente o que eles fizeram.

145
00:06:09,750 --> 00:06:11,110
Eles fizeram processamento de dados.

146
00:06:11,110 --> 00:06:15,400
>> Como assim a proliferação de perfurador
cartões, um engenhoso mecanismos

147
00:06:15,400 --> 00:06:18,560
de ser capaz de alavancar esse
tecnologia para votação conjuntos de resultados classificados.

148
00:06:18,560 --> 00:06:20,726
Você pode ver nesta foto
aí temos um little--

149
00:06:20,726 --> 00:06:23,970
é um pouco small-- mas você pode ver
um mecanismo mecânico muito engenhoso

150
00:06:23,970 --> 00:06:26,970
onde temos uma plataforma de cartões perfurados.

151
00:06:26,970 --> 00:06:28,720
E tomada de alguém
um pouco de chave de fenda

152
00:06:28,720 --> 00:06:31,400
e furando através do
slots e levantando-

153
00:06:31,400 --> 00:06:34,820
para obter esse jogo, que
resultados classificados definido.

154
00:06:34,820 --> 00:06:36,270
>> Esta é uma agregação.

155
00:06:36,270 --> 00:06:38,690
Fazemos isso o tempo todo
hoje no computador,

156
00:06:38,690 --> 00:06:40,100
onde você fazê-lo no banco de dados.

157
00:06:40,100 --> 00:06:41,620
Nós costumávamos fazê-lo manualmente, certo?

158
00:06:41,620 --> 00:06:42,994
Pessoas colocar essas coisas em conjunto.

159
00:06:42,994 --> 00:06:45,440
E foi a proliferação
destes cartões perfurados

160
00:06:45,440 --> 00:06:50,070
para o que chamamos de tambores de dados
e bobinas de dados, fita de papel.

161
00:06:50,070 --> 00:06:55,980
>> A indústria de processamento de dados levou
uma lição com os pianos de jogador.

162
00:06:55,980 --> 00:06:57,855
Jogador pianos de volta ao
a virada do século

163
00:06:57,855 --> 00:07:02,100
costumava usar bobinas de papel com slots
para dizer-lhe que as chaves para jogar.

164
00:07:02,100 --> 00:07:05,380
Assim que a tecnologia foi adaptada
eventualmente, para armazenar dados digitais,

165
00:07:05,380 --> 00:07:08,070
porque eles poderiam colocar esses dados
para aqueles rolos de fita de papel.

166
00:07:08,070 --> 00:07:10,870
>> Agora, como um resultado, os dados
foi actually-- como

167
00:07:10,870 --> 00:07:14,960
você acessar esses dados foi diretamente
dependente da forma como ele está armazenado.

168
00:07:14,960 --> 00:07:17,825
Então, se eu colocar os dados em uma fita,
Eu tive acessar os dados de forma linear.

169
00:07:17,825 --> 00:07:20,475
Eu tive que rolar a todo
fita para acessar todos os dados.

170
00:07:20,475 --> 00:07:22,600
Se eu colocar os dados no soco
cartões, eu poderia acessá-lo

171
00:07:22,600 --> 00:07:26,270
em um pouco mais aleatória
forma, talvez não tão rapidamente.

172
00:07:26,270 --> 00:07:30,770
>> Mas havia limitações em como nós
acesso a dados com base em como foi armazenado.

173
00:07:30,770 --> 00:07:32,890
E por isso foi um problema
vai para os anos 50.

174
00:07:32,890 --> 00:07:37,890
Mais uma vez, podemos começar a ver que, como nós
desenvolver novas tecnologias para processar

175
00:07:37,890 --> 00:07:41,670
os dados, certo, ela abre
a porta para novas soluções,

176
00:07:41,670 --> 00:07:45,852
para novos programas, novo
aplicações para esses dados.

177
00:07:45,852 --> 00:07:47,810
E realmente, governança
pode ter sido a razão

178
00:07:47,810 --> 00:07:49,435
por isso que desenvolvemos alguns desses sistemas.

179
00:07:49,435 --> 00:07:52,290
Mas o negócio tornou-se rapidamente
o motorista por trás da evolução

180
00:07:52,290 --> 00:07:54,720
da base de dados moderno e
o sistema de arquivos moderno.

181
00:07:54,720 --> 00:07:56,870
>> Portanto, a próxima coisa que
surgiu foi na década de 50

182
00:07:56,870 --> 00:08:00,780
foi o sistema de arquivos eo
desenvolvimento de armazenamento de acesso aleatório.

183
00:08:00,780 --> 00:08:02,050
Esta foi a bela.

184
00:08:02,050 --> 00:08:06,230
Agora, de repente, podemos colocar o nosso
arquivos em qualquer lugar nesses discos rígidos

185
00:08:06,230 --> 00:08:09,760
e nós podemos acessar esses dados de forma aleatória.

186
00:08:09,760 --> 00:08:11,950
Podemos analisar que
informações de arquivos.

187
00:08:11,950 --> 00:08:14,920
E nós resolvemos todo o mundo
problemas com processamento de dados.

188
00:08:14,920 --> 00:08:17,550
>> E que durou cerca de 20 ou
30 anos até a evolução

189
00:08:17,550 --> 00:08:22,100
do banco de dados relacional, que
é quando o mundo decidiu que agora

190
00:08:22,100 --> 00:08:27,940
precisa ter um repositório que derrota
a expansão dos dados através do arquivo

191
00:08:27,940 --> 00:08:29,540
sistemas que nós construímos. Certo?

192
00:08:29,540 --> 00:08:34,270
Muitos dados distribuídos em muitos
lugares, a de-duplicação de dados,

193
00:08:34,270 --> 00:08:37,120
e o custo de armazenamento era enorme.

194
00:08:37,120 --> 00:08:43,760
>> Nos anos 70, o recurso mais caro
que um computador tinha era o de armazenamento.

195
00:08:43,760 --> 00:08:46,200
O processador foi
visto como um custo fixo.

196
00:08:46,200 --> 00:08:49,030
Quando eu comprar a caixa,
a CPU faz algum trabalho.

197
00:08:49,030 --> 00:08:51,960
Vai ser giro se
ele é realmente funcionando ou não.

198
00:08:51,960 --> 00:08:53,350
Isso é realmente um custo afundado.

199
00:08:53,350 --> 00:08:56,030
>> Mas o que me custou como um
negócio é o armazenamento.

200
00:08:56,030 --> 00:09:00,020
Se eu tenho que comprar mais discos próximo
mês, isso é um custo real que eu pagar.

201
00:09:00,020 --> 00:09:01,620
E que o armazenamento é caro.

202
00:09:01,620 --> 00:09:05,020
>> Agora nós avanço rápido 40 anos
e nós temos um problema diferente.

203
00:09:05,020 --> 00:09:10,020
A computação é agora o
recurso mais caro.

204
00:09:10,020 --> 00:09:11,470
O armazenamento é barato.

205
00:09:11,470 --> 00:09:14,570
Quero dizer, nós podemos ir a qualquer lugar no
nuvem e podemos encontrar armazenamento barato.

206
00:09:14,570 --> 00:09:17,190
Mas o que eu não consigo encontrar é computação barato.

207
00:09:17,190 --> 00:09:20,700
>> Assim, a evolução de hoje
tecnologia, da tecnologia de banco de dados,

208
00:09:20,700 --> 00:09:23,050
está realmente focado em torno de
bancos de dados distribuídos

209
00:09:23,050 --> 00:09:26,960
que não sofrem
o mesmo tipo de escala

210
00:09:26,960 --> 00:09:29,240
limitações dos bancos de dados relacionais.

211
00:09:29,240 --> 00:09:32,080
Vamos falar um pouco sobre
o que isso realmente significa.

212
00:09:32,080 --> 00:09:34,760
>> Mas uma das razões e
o motorista atrás de nós isto--

213
00:09:34,760 --> 00:09:38,290
falou sobre a pressão de dados.

214
00:09:38,290 --> 00:09:41,920
Pressão de dados é algo
que impulsiona a inovação.

215
00:09:41,920 --> 00:09:44,610
E se você olhar para cima
Nos últimos cinco anos,

216
00:09:44,610 --> 00:09:48,180
este é um gráfico de que os dados
carga toda a empresa geral

217
00:09:48,180 --> 00:09:49,640
Parece que, nos últimos cinco anos.

218
00:09:49,640 --> 00:09:52,570
>> E a regra geral do polegar
estes dias-- se você vai Google--

219
00:09:52,570 --> 00:09:55,290
é de 90% do que os dados
nós armazenamos hoje, e foi

220
00:09:55,290 --> 00:09:57,330
gerado dentro dos últimos dois anos.

221
00:09:57,330 --> 00:09:57,911
ESTÁ BEM.

222
00:09:57,911 --> 00:09:59,410
Agora, isso não é uma tendência que há de novo.

223
00:09:59,410 --> 00:10:01,230
Esta é uma tendência que tem sido
saindo por 100 anos.

224
00:10:01,230 --> 00:10:03,438
Desde Herman Hollerith
desenvolveu o cartão de perfurador,

225
00:10:03,438 --> 00:10:08,040
temos vindo a construir repositórios de dados
e coleta de dados em taxas fenomenais.

226
00:10:08,040 --> 00:10:10,570
>> Assim, ao longo dos últimos 100 anos,
nós vimos essa tendência.

227
00:10:10,570 --> 00:10:11,940
Isso não vai mudar.

228
00:10:11,940 --> 00:10:14,789
Daqui para frente, vamos ver
este, se não uma tendência acelerada.

229
00:10:14,789 --> 00:10:16,330
E você pode ver o que parece.

230
00:10:16,330 --> 00:10:23,510
>> Se uma empresa, em 2010, teve um
terabyte de dados sob gestão,

231
00:10:23,510 --> 00:10:27,080
hoje que significa que eles são
gestão de 6,5 petabytes de dados.

232
00:10:27,080 --> 00:10:30,380
Isso é 6.500 vezes mais dados.

233
00:10:30,380 --> 00:10:31,200
E eu sei que isso.

234
00:10:31,200 --> 00:10:33,292
Eu trabalho com essas empresas todos os dias.

235
00:10:33,292 --> 00:10:35,000
Cinco anos atrás, eu
falaria com empresas

236
00:10:35,000 --> 00:10:38,260
quem iria falar comigo sobre o que é uma dor
é para gerir terabytes de dados.

237
00:10:38,260 --> 00:10:39,700
E eles falariam
para mim sobre como podemos ver

238
00:10:39,700 --> 00:10:41,825
que este é provavelmente vai
ser um ou dois petabyte

239
00:10:41,825 --> 00:10:43,030
dentro de um par de anos.

240
00:10:43,030 --> 00:10:45,170
>> Estas mesmas empresas
hoje vou me encontrar com,

241
00:10:45,170 --> 00:10:48,100
e eles estão falando comigo sobre o
problema está lá ter gestão

242
00:10:48,100 --> 00:10:51,440
dezenas, 20 petabytes de dados.

243
00:10:51,440 --> 00:10:53,590
Assim, a explosão da
dados na indústria

244
00:10:53,590 --> 00:10:56,670
está dirigindo a enorme
precisa de melhores soluções.

245
00:10:56,670 --> 00:11:00,980
E o banco de dados relacional é
apenas não viver de acordo com a demanda.

246
00:11:00,980 --> 00:11:03,490
>> E por isso há uma linear
correlação entre a pressão de dados

247
00:11:03,490 --> 00:11:05,210
e inovação técnica.

248
00:11:05,210 --> 00:11:07,780
A história tem nos mostrado
este, que ao longo do tempo,

249
00:11:07,780 --> 00:11:11,090
sempre que o volume de dados
que tem de ser processado

250
00:11:11,090 --> 00:11:15,490
excede a capacidade do sistema
para processá-lo em um tempo razoável

251
00:11:15,490 --> 00:11:18,870
ou a um custo razoável,
em seguida, as novas tecnologias

252
00:11:18,870 --> 00:11:21,080
são inventadas para resolver esses problemas.

253
00:11:21,080 --> 00:11:24,090
Essas novas tecnologias,
por sua vez, abre a porta

254
00:11:24,090 --> 00:11:27,840
para um outro conjunto de problemas, o que
está reunindo ainda mais dados.

255
00:11:27,840 --> 00:11:29,520
>> Agora, nós não vamos parar com isso.

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

257
00:11:30,020 --> 00:11:31,228
Nós não vamos parar com isso.

258
00:11:31,228 --> 00:11:31,830
Por quê?

259
00:11:31,830 --> 00:11:35,520
Porque você não pode saber tudo
que há para saber no universo.

260
00:11:35,520 --> 00:11:40,510
E enquanto nós estivemos vivos,
ao longo da história do homem,

261
00:11:40,510 --> 00:11:43,440
temos sempre conduzido para saber mais.

262
00:11:43,440 --> 00:11:49,840
>> Então, parece que cada polegada nos movemos
no caminho da descoberta científica,

263
00:11:49,840 --> 00:11:54,620
estamos a multiplicação da quantidade de dados
que precisamos para processar exponencialmente

264
00:11:54,620 --> 00:11:59,920
como descobrimos mais e mais e mais
sobre o funcionamento interno da vida,

265
00:11:59,920 --> 00:12:04,530
sobre como o universo funciona, sobre
dirigir a descoberta científica,

266
00:12:04,530 --> 00:12:06,440
e que a invenção
nós estamos fazendo hoje.

267
00:12:06,440 --> 00:12:09,570
O volume de dados apenas
aumenta continuamente.

268
00:12:09,570 --> 00:12:12,120
Assim, ser capaz de lidar com
este problema é enorme.

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

270
00:12:14,790 --> 00:12:17,410
>> Então, uma das coisas
olharmos como por NoSQL?

271
00:12:17,410 --> 00:12:19,200
Como é que NoSQL resolver este problema?

272
00:12:19,200 --> 00:12:24,980
Bem, bancos de dados relacionais,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- que é realmente uma construção do
relacional database-- essas coisas são

274
00:12:28,600 --> 00:12:30,770
optimizada para o armazenamento.

275
00:12:30,770 --> 00:12:33,180
>> Voltar na década de 70, mais uma vez,
disco é caro.

276
00:12:33,180 --> 00:12:36,990
O exercício de provisionamento de armazenamento
na empresa é interminável.

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

278
00:12:37,490 --> 00:12:38,020
Eu vivi isso.

279
00:12:38,020 --> 00:12:41,250
Eu escrevi drivers de armazenamento para um
empresa superserver enterprised

280
00:12:41,250 --> 00:12:42,470
de volta nos anos 90.

281
00:12:42,470 --> 00:12:45,920
E a linha de fundo é outra trasfega
matriz de armazenamento foi apenas algo que

282
00:12:45,920 --> 00:12:47,600
Aconteceu a cada dia na empresa.

283
00:12:47,600 --> 00:12:49,030
E não parou mais.

284
00:12:49,030 --> 00:12:52,690
Maior densidade de armazenamento, a demanda
para armazenamento de alta densidade,

285
00:12:52,690 --> 00:12:56,340
e para um armazenamento mais eficiente
devices-- ele nunca parou.

286
00:12:56,340 --> 00:13:00,160
>> E NoSQL é uma grande tecnologia
uma vez que normaliza os dados.

287
00:13:00,160 --> 00:13:02,210
É de-duplica os dados.

288
00:13:02,210 --> 00:13:07,180
Isto coloca os dados numa estrutura que
é agnóstica para cada padrão de acesso.

289
00:13:07,180 --> 00:13:11,600
Vários aplicativos podem bater esse
Banco de dados SQL, executar consultas ad hoc,

290
00:13:11,600 --> 00:13:15,950
e obter dados na forma que eles
precisa processo para a sua carga de trabalho.

291
00:13:15,950 --> 00:13:17,570
Isso soa fantástico.

292
00:13:17,570 --> 00:13:21,350
Mas a linha inferior é com qualquer
sistema, se é agnóstico a tudo,

293
00:13:21,350 --> 00:13:23,500
ele é otimizado para nada.

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

295
00:13:24,050 --> 00:13:26,386
>> E é isso que nós começamos com
o banco de dados relacional.

296
00:13:26,386 --> 00:13:27,510
Ele é otimizado para armazenamento.

297
00:13:27,510 --> 00:13:28,280
É normalizada.

298
00:13:28,280 --> 00:13:29,370
É relacional.

299
00:13:29,370 --> 00:13:31,660
Ele suporta as consultas ad hoc.

300
00:13:31,660 --> 00:13:34,000
E ele e ele escalas verticalmente.

301
00:13:34,000 --> 00:13:39,030
>> Se eu preciso para obter um banco de dados SQL maior
ou um banco de dados SQL mais poderoso,

302
00:13:39,030 --> 00:13:41,090
Eu vou comprar um pedaço maior de ferro.

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

304
00:13:41,600 --> 00:13:44,940
Eu trabalhei com um monte de clientes
que já passou por grandes atualizações

305
00:13:44,940 --> 00:13:48,340
em sua infra-estrutura SQL única
para descobrir seis meses depois,

306
00:13:48,340 --> 00:13:49,750
eles estão acertando a parede novamente.

307
00:13:49,750 --> 00:13:55,457
E a resposta da Oracle ou MSSQL
ou qualquer outra pessoa é obter uma caixa maior.

308
00:13:55,457 --> 00:13:58,540
Bem, mais cedo ou mais tarde, você não pode comprar um
maior caixa, e isso é problema real.

309
00:13:58,540 --> 00:14:00,080
Precisamos realmente mudar as coisas.

310
00:14:00,080 --> 00:14:01,080
Então, onde é que isto funciona?

311
00:14:01,080 --> 00:14:06,560
Ele funciona bem para off-line
analytics, do tipo OLAP cargas de trabalho.

312
00:14:06,560 --> 00:14:08,670
E isso é realmente onde o SQL pertence.

313
00:14:08,670 --> 00:14:12,540
Agora, ele é usado hoje em muitos on-line
transacional-tipo de processamento

314
00:14:12,540 --> 00:14:13,330
aplicações.

315
00:14:13,330 --> 00:14:16,460
E ele funciona muito bem no
algum nível de utilização,

316
00:14:16,460 --> 00:14:18,670
mas ele simplesmente não escala
a maneira que NoSQL faz.

317
00:14:18,670 --> 00:14:20,660
E vamos falar um pouco
pouco sobre por que isso acontece.

318
00:14:20,660 --> 00:14:23,590
>> Agora, noSQL, por outro lado,
é mais otimizado para computação.

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

320
00:14:24,540 --> 00:14:26,830
Não é agnóstico
o padrão de acesso.

321
00:14:26,830 --> 00:14:31,620
É o que chamamos de-normalizado
estrutura ou uma estrutura hierárquica.

322
00:14:31,620 --> 00:14:35,000
Os dados em um banco de dados relacional é
Juntaram-se a partir de várias tabelas

323
00:14:35,000 --> 00:14:36,850
para produzir a visão de que você precisa.

324
00:14:36,850 --> 00:14:40,090
Os dados no banco de dados NoSQL um
é armazenado em um documento que

325
00:14:40,090 --> 00:14:42,100
contém a estrutura hierárquica.

326
00:14:42,100 --> 00:14:45,670
Todos os dados que, normalmente, seria
uniram-se para produzir esse ponto de vista

327
00:14:45,670 --> 00:14:47,160
é armazenado em um único documento.

328
00:14:47,160 --> 00:14:50,990
E vamos falar um pouco sobre
como isso funciona em um par de cartas.

329
00:14:50,990 --> 00:14:55,320
>> Mas a idéia aqui é que você armazene
seus dados como esses pontos de vista instanciado.

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

331
00:14:56,410 --> 00:14:58,610
Você escala horizontal.

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

333
00:14:59,556 --> 00:15:02,100
Se eu precisar de aumentar o
tamanho do meu agrupamento NoSQL,

334
00:15:02,100 --> 00:15:03,700
Eu não preciso de obter uma caixa maior.

335
00:15:03,700 --> 00:15:05,200
Recebo outra caixa.

336
00:15:05,200 --> 00:15:07,700
E eu agrupar esses juntos,
e eu posso caco que os dados.

337
00:15:07,700 --> 00:15:10,780
Vamos falar um pouco sobre
sharding que é, para ser

338
00:15:10,780 --> 00:15:14,270
capaz de escalar esse banco de dados
em vários dispositivos físicos

339
00:15:14,270 --> 00:15:18,370
e remover a barreira que
me obriga a escalar verticalmente.

340
00:15:18,370 --> 00:15:22,080
>> Então, é realmente construído para on-line
processamento de transações e escala.

341
00:15:22,080 --> 00:15:25,480
Há uma grande distinção
aqui entre os relatórios, certo?

342
00:15:25,480 --> 00:15:27,810
Relatórios, eu não sei o
perguntas que eu vou pedir.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- se alguém do
meu departamento de marketing

345
00:15:30,570 --> 00:15:34,520
quer só-- como muitos dos meus clientes
têm essa característica em particular que

346
00:15:34,520 --> 00:15:37,850
comprei nesta dia-- Não sei
que consultar eles vão perguntar.

347
00:15:37,850 --> 00:15:39,160
Então eu preciso ser agnóstico.

348
00:15:39,160 --> 00:15:41,810
>> Agora, numa linha
aplicativo transacional,

349
00:15:41,810 --> 00:15:43,820
Eu sei que perguntas que eu estou pedindo.

350
00:15:43,820 --> 00:15:46,581
Eu construí o pedido de
um fluxo de trabalho muito específico.

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

352
00:15:47,080 --> 00:15:50,540
Então, se eu otimizar a dados
armazenar a apoiar esse fluxo de trabalho,

353
00:15:50,540 --> 00:15:52,020
ele vai ser mais rápido.

354
00:15:52,020 --> 00:15:55,190
E é por isso que pode NoSQL
realmente acelerar a entrega

355
00:15:55,190 --> 00:15:57,710
um destes tipos de serviços.

356
00:15:57,710 --> 00:15:58,210
Tudo certo.

357
00:15:58,210 --> 00:16:00,501
>> Então, nós estamos indo para entrar em
um pouco de teoria aqui.

358
00:16:00,501 --> 00:16:03,330
E alguns de vocês, seus olhos
pode reverter um pouco.

359
00:16:03,330 --> 00:16:06,936
Mas eu vou tentar mantê-lo
tão alto nível que eu puder.

360
00:16:06,936 --> 00:16:08,880
Então, se você está no projeto
gestão, há

361
00:16:08,880 --> 00:16:12,280
uma construção chamada
triângulo de restrições.

362
00:16:12,280 --> 00:16:12,936
ESTÁ BEM.

363
00:16:12,936 --> 00:16:16,060
O triângulo de constrangimentos ditados
você não pode ter tudo o tempo todo.

364
00:16:16,060 --> 00:16:17,750
Não pode ter seu bolo e comê-lo.

365
00:16:17,750 --> 00:16:22,310
Assim, em gerenciamento de projetos, que triângulo
limitações é que você pode tê-lo barato,

366
00:16:22,310 --> 00:16:24,710
você pode tê-lo rápido,
ou você pode tê-lo bom.

367
00:16:24,710 --> 00:16:25,716
Escolha dois.

368
00:16:25,716 --> 00:16:27,090
Porque você não pode ter todos os três.

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

370
00:16:27,460 --> 00:16:27,820
ESTÁ BEM.

371
00:16:27,820 --> 00:16:28,920
>> Então você ouve muito sobre isso.

372
00:16:28,920 --> 00:16:31,253
É uma restrição tripla,
triângulo de restrição tripla,

373
00:16:31,253 --> 00:16:34,420
ou o triângulo de ferro é oftentimes--
quando você fala aos gerentes de projeto,

374
00:16:34,420 --> 00:16:35,420
eles vão falar sobre isso.

375
00:16:35,420 --> 00:16:37,640
Agora, bancos de dados têm
seu próprio triângulo de ferro.

376
00:16:37,640 --> 00:16:40,350
E o triângulo de ferro de dados
é o que chamamos de teorema de CAP.

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

378
00:16:41,580 --> 00:16:43,770
>> PAC ditames teorema
como bancos de dados operar

379
00:16:43,770 --> 00:16:45,627
sob uma condição muito específica.

380
00:16:45,627 --> 00:16:47,460
E nós vamos falar sobre
o que é essa condição.

381
00:16:47,460 --> 00:16:52,221
Mas os três vértices do triângulo,
por assim dizer, são C, consistência.

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

383
00:16:52,720 --> 00:16:56,760
Assim, no PAC, a consistência significa que todos
clientes que podem acessar o banco de dados

384
00:16:56,760 --> 00:16:59,084
terá sempre um muito
visão consistente dos dados.

385
00:16:59,084 --> 00:17:00,750
Ninguém vai ver duas coisas diferentes.

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

387
00:17:01,480 --> 00:17:04,020
Se eu ver o banco de dados,
Estou vendo a mesma visão

388
00:17:04,020 --> 00:17:06,130
como meu parceiro que vê
a mesma base de dados.

389
00:17:06,130 --> 00:17:07,470
Essa é a consistência.

390
00:17:07,470 --> 00:17:12,099
>> Disponibilidade significa que, se o
banco de dados on-line, se puder ser alcançado,

391
00:17:12,099 --> 00:17:14,760
que todos os clientes serão sempre
ser capaz de ler e escrever.

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

393
00:17:15,260 --> 00:17:17,010
Assim, cada cliente que
pode ler o banco de dados

394
00:17:17,010 --> 00:17:18,955
será sempre capaz de leitura
dados de dados e escrever.

395
00:17:18,955 --> 00:17:21,819
E se esse for o caso,
É um sistema disponível.

396
00:17:21,819 --> 00:17:24,230
>> E o terceiro ponto é o que
que chamamos de tolerância partição.

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

398
00:17:24,730 --> 00:17:28,160
Meios de tolerância partição
que o sistema funciona bem

399
00:17:28,160 --> 00:17:32,000
apesar de rede física
divisórias entre os nós.

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

401
00:17:32,760 --> 00:17:36,270
Então nós do cluster não pode
falar uns com os outros, o que acontece?

402
00:17:36,270 --> 00:17:36,880
Tudo certo.

403
00:17:36,880 --> 00:17:39,545
>> Bancos de dados relacionais Então choose--
você pode escolher dois destes.

404
00:17:39,545 --> 00:17:40,045
ESTÁ BEM.

405
00:17:40,045 --> 00:17:43,680
Bancos de dados relacionais Então escolha
para ser consistente e disponível.

406
00:17:43,680 --> 00:17:47,510
Se a partição acontece entre
os DataNodes no armazenamento de dados,

407
00:17:47,510 --> 00:17:48,831
o banco de dados falha.

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

409
00:17:49,330 --> 00:17:50,900
Ele só vai para baixo.

410
00:17:50,900 --> 00:17:51,450
ESTÁ BEM.

411
00:17:51,450 --> 00:17:54,230
>> E é por isso que eles têm
a crescer com as caixas maiores.

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

413
00:17:54,730 --> 00:17:58,021
Porque não há Não-- geralmente, um cluster
banco de dados, não há muito muitos deles

414
00:17:58,021 --> 00:17:59,590
que operam dessa forma.

415
00:17:59,590 --> 00:18:03,019
Mas a maioria dos bancos de dados de escala
verticalmente dentro de uma única caixa.

416
00:18:03,019 --> 00:18:05,060
Porque eles precisam ser
consistente e disponível.

417
00:18:05,060 --> 00:18:10,320
Se uma partição foram a ser injectado,
então você teria que fazer uma escolha.

418
00:18:10,320 --> 00:18:13,720
Você tem que fazer uma escolha entre
sendo consistente e disponível.

419
00:18:13,720 --> 00:18:16,080
>> E é isso que bancos de dados NoSQL fazer.

420
00:18:16,080 --> 00:18:16,580
Tudo certo.

421
00:18:16,580 --> 00:18:20,950
Assim, uma base de dados noSQL, ele
vem em dois sabores.

422
00:18:20,950 --> 00:18:22,990
Nós have-- bem,
vem em muitos sabores,

423
00:18:22,990 --> 00:18:26,140
mas ele vem com dois básico
characteristics-- o que

424
00:18:26,140 --> 00:18:30,050
nós chamaríamos de banco de dados CP, ou um
tolerância e consistente partição

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

426
00:18:31,040 --> 00:18:34,930
Esses caras a fazer a escolha que, quando
os nós perder o contacto uns com os outros,

427
00:18:34,930 --> 00:18:37,091
nós não vamos permitir
as pessoas a escrever mais.

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

429
00:18:37,590 --> 00:18:41,855
>> Até que essa partição é removida,
acesso de gravação é bloqueada.

430
00:18:41,855 --> 00:18:43,230
Isso significa que eles não estão disponíveis.

431
00:18:43,230 --> 00:18:44,510
Eles são consistentes.

432
00:18:44,510 --> 00:18:46,554
Quando vemos que
partição injectar-se,

433
00:18:46,554 --> 00:18:48,470
estamos agora consistente,
porque nós não vamos

434
00:18:48,470 --> 00:18:51,517
para permitir a mudança de dados em dois
os lados da partição independentemente

435
00:18:51,517 --> 00:18:52,100
de cada um.

436
00:18:52,100 --> 00:18:54,130
Nós teremos que
restabelecer a comunicação

437
00:18:54,130 --> 00:18:56,930
antes de qualquer atualização
os dados são permitidos.

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

439
00:18:58,120 --> 00:19:02,650
>> O próximo sabor seria um sistema AP,
ou um disponível e repartiu

440
00:19:02,650 --> 00:19:03,640
sistema de tolerância.

441
00:19:03,640 --> 00:19:05,320
Esses caras não se importam.

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

443
00:19:06,020 --> 00:19:08,960
Qualquer nó que recebe uma
escrever, nós vamos tomá-lo.

444
00:19:08,960 --> 00:19:11,480
Então, eu estou replicar meus dados
em vários nós.

445
00:19:11,480 --> 00:19:14,730
Esses nós obter um cliente, o cliente vem
em, diz, eu vou escrever alguns dados.

446
00:19:14,730 --> 00:19:16,300
Nó diz, não há problema.

447
00:19:16,300 --> 00:19:18,580
O nó ao lado dele fica
uma gravação no mesmo registro,

448
00:19:18,580 --> 00:19:20,405
ele vai dizer não problema.

449
00:19:20,405 --> 00:19:23,030
Em algum lugar de volta no back-end,
que os dados vai replicar.

450
00:19:23,030 --> 00:19:27,360
E então alguém vai perceber,
uh-oh, eles vão perceber sistema, uh-oh,

451
00:19:27,360 --> 00:19:28,870
houve uma atualização para os dois lados.

452
00:19:28,870 --> 00:19:30,370
O que nós fazemos?

453
00:19:30,370 --> 00:19:33,210
E o que eles fazem é, então,
eles fazem algo que

454
00:19:33,210 --> 00:19:36,080
lhes permite resolver esse estado de dados.

455
00:19:36,080 --> 00:19:39,000
E nós vamos falar sobre
que, no quadro seguinte.

456
00:19:39,000 --> 00:19:40,000
>> Coisa a salientar aqui.

457
00:19:40,000 --> 00:19:42,374
E eu não vou ficar muito
muito a este, porque esta

458
00:19:42,374 --> 00:19:43,510
entra em teoria dados de profundidade.

459
00:19:43,510 --> 00:19:46,670
Mas há um transacional
quadro que

460
00:19:46,670 --> 00:19:50,680
é executado em um sistema relacional que
permite que eu faça com segurança atualizações

461
00:19:50,680 --> 00:19:53,760
para várias entidades no banco de dados.

462
00:19:53,760 --> 00:19:58,320
E essas atualizações devem ocorrer
todo de uma só vez ou de modo nenhum.

463
00:19:58,320 --> 00:20:00,500
E isso é chamado de transações ACID.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID nos dá atomicidade, consistência,
isolamento, e durabilidade.

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

467
00:20:07,070 --> 00:20:13,550
Isso significa que, transações atômicas, tudo
minhas atualizações tanto acontecer ou não fazem.

468
00:20:13,550 --> 00:20:16,570
Consistência significa que
o banco de dados será sempre

469
00:20:16,570 --> 00:20:19,780
ser levado a um consistente
estado após uma atualização.

470
00:20:19,780 --> 00:20:23,900
Eu nunca vou deixar o banco de dados em um
mau estado depois de aplicar uma atualização.

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

472
00:20:24,400 --> 00:20:26,720
>> Portanto, é um pouco diferente
de consistência PAC.

473
00:20:26,720 --> 00:20:29,760
Consistência PAC significa toda minha
os clientes podem sempre ver os dados.

474
00:20:29,760 --> 00:20:34,450
Consistência ÁCIDO significa que quando
uma transação é feito, dados de boa.

475
00:20:34,450 --> 00:20:35,709
Meus relacionamentos são tudo de bom.

476
00:20:35,709 --> 00:20:38,750
Eu não estou indo para apagar uma linha pai
e deixar um monte de crianças órfãs

477
00:20:38,750 --> 00:20:40,970
em alguma outra tabela.

478
00:20:40,970 --> 00:20:44,320
Isso não pode acontecer se eu estiver consistente
em uma transação de ácido.

479
00:20:44,320 --> 00:20:49,120
>> Isolamento significa que as transações
sempre ocorrer uma depois da outra.

480
00:20:49,120 --> 00:20:51,920
O resultado final dos dados
será o mesmo estado

481
00:20:51,920 --> 00:20:54,770
como se essas operações
que foram emitidos simultaneamente

482
00:20:54,770 --> 00:20:57,340
foram executados em série.

483
00:20:57,340 --> 00:21:00,030
Portanto, é a simultaneidade
controlo na base de dados.

484
00:21:00,030 --> 00:21:04,130
Então, basicamente, eu não posso incrementar o
mesmo valor duas vezes com duas operações.

485
00:21:04,130 --> 00:21:08,580
>> Mas se eu disser adicionar 1 a este valor,
e duas operações vêm em

486
00:21:08,580 --> 00:21:10,665
e tentar fazê-lo, é uma
vai chegar lá primeiro

487
00:21:10,665 --> 00:21:12,540
e do outro um
vai chegar lá depois.

488
00:21:12,540 --> 00:21:15,210
Então, no final, eu adicionei dois.

489
00:21:15,210 --> 00:21:16,170
Você vê o que eu quero dizer?

490
00:21:16,170 --> 00:21:16,670
ESTÁ BEM.

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

492
00:21:19,220 --> 00:21:21,250
>> A durabilidade é bastante simples.

493
00:21:21,250 --> 00:21:23,460
Quando a transação
é reconhecido, é

494
00:21:23,460 --> 00:21:26,100
vai estar lá mesmo
se o sistema falhar.

495
00:21:26,100 --> 00:21:29,230
Quando esse sistema recupera, isto
transação que foi cometida

496
00:21:29,230 --> 00:21:30,480
está realmente indo para estar lá.

497
00:21:30,480 --> 00:21:33,130
Então, isso é as garantias
de transações ACID.

498
00:21:33,130 --> 00:21:35,470
Essas são garantias bastante agradáveis
para ter em um banco de dados,

499
00:21:35,470 --> 00:21:36,870
mas eles vêm para esse custo.

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

501
00:21:37,640 --> 00:21:40,520
>> Porque o problema
com este quadro é

502
00:21:40,520 --> 00:21:44,540
Se houver uma partição na dados
set, eu tenho que tomar uma decisão.

503
00:21:44,540 --> 00:21:48,000
Eu vou ter para permitir que
atualizações de um lado ou do outro.

504
00:21:48,000 --> 00:21:50,310
E se isso acontecer,
então eu já não estou indo

505
00:21:50,310 --> 00:21:52,630
para ser capaz de manter
essas características.

506
00:21:52,630 --> 00:21:53,960
Eles não vão ser consistente.

507
00:21:53,960 --> 00:21:55,841
Eles não vão ser isolado.

508
00:21:55,841 --> 00:21:58,090
Este é o lugar onde se decompõe
para bancos de dados relacionais.

509
00:21:58,090 --> 00:22:01,360
Esta é a razão relacional
bancos de dados de escala vertical.

510
00:22:01,360 --> 00:22:05,530
>> Por outro lado, temos
o que é chamado de tecnologia BASE.

511
00:22:05,530 --> 00:22:07,291
E estes são os seus bancos de dados NoSQL.

512
00:22:07,291 --> 00:22:07,790
Tudo certo.

513
00:22:07,790 --> 00:22:10,180
Portanto, temos nossa CP, bancos de dados de AP.

514
00:22:10,180 --> 00:22:14,720
E estes são, basicamente, o que você chama
disponível, estado macio, eventualmente,

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

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

517
00:22:16,420 --> 00:22:19,690
>> Basicamente disponível, porque
eles são partição tolerante.

518
00:22:19,690 --> 00:22:21,470
Eles serão sempre
lá, mesmo se não houver

519
00:22:21,470 --> 00:22:23,053
uma divisória entre os nós da rede.

520
00:22:23,053 --> 00:22:25,900
Se eu posso falar com um nó, eu sou
vai ser capaz de ler dados.

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

522
00:22:26,460 --> 00:22:30,810
Eu posso não ser sempre capaz de escrever
dados se eu sou uma plataforma consistente.

523
00:22:30,810 --> 00:22:32,130
Mas eu vou ser capaz de ler os dados.

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

525
00:22:34,960 --> 00:22:38,010
>> O estado indica macio
que quando eu ler esses dados,

526
00:22:38,010 --> 00:22:40,790
ele pode não ser o mesmo que os outros nós.

527
00:22:40,790 --> 00:22:43,390
Se um direito foi emitido em um nó
em outro lugar no cluster

528
00:22:43,390 --> 00:22:46,650
e não foi replicado em toda a
aglomerado ainda quando li que os dados,

529
00:22:46,650 --> 00:22:48,680
que o estado pode não ser consistente.

530
00:22:48,680 --> 00:22:51,650
No entanto, será
eventualmente, consistente,

531
00:22:51,650 --> 00:22:53,870
o que significa que quando uma gravação
é feito para o sistema,

532
00:22:53,870 --> 00:22:56,480
ele vai replicar em todos os nós.

533
00:22:56,480 --> 00:22:59,095
E, eventualmente, esse estado
será posto em ordem,

534
00:22:59,095 --> 00:23:00,890
e será um estado consistente.

535
00:23:00,890 --> 00:23:05,000
>> Agora, o teorema PAC realmente
joga apenas em uma condição.

536
00:23:05,000 --> 00:23:08,700
Essa condição é quando isso acontece.

537
00:23:08,700 --> 00:23:13,710
Porque sempre que ele está operando em
modo normal, não há nenhuma partição,

538
00:23:13,710 --> 00:23:16,370
tudo é consistente e disponível.

539
00:23:16,370 --> 00:23:19,990
Você só se preocupar com CAP
quando temos essa partição.

540
00:23:19,990 --> 00:23:21,260
Portanto, estas são raras.

541
00:23:21,260 --> 00:23:25,360
Mas como o sistema reage quando os
ocorrem ditar que tipo de sistema

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

543
00:23:26,750 --> 00:23:31,110
>> Então, vamos dar uma olhada no que
que parece para os sistemas AP.

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

545
00:23:32,621 --> 00:23:34,830
Sistemas AP vêm em dois sabores.

546
00:23:34,830 --> 00:23:38,514
Eles vêm em o sabor que é um
mestre mestre, 100%, sempre disponível.

547
00:23:38,514 --> 00:23:40,430
E eles vêm na
outro sabor, que diz:

548
00:23:40,430 --> 00:23:43,330
você sabe o quê, eu vou me preocupar
sobre essa coisa de particionamento

549
00:23:43,330 --> 00:23:44,724
quando ocorre uma partição real.

550
00:23:44,724 --> 00:23:47,890
Caso contrário, não vai ser primária
nós que vai levar os direitos.

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

552
00:23:48,500 --> 00:23:50,040
>> Então, se nós algo como Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra seria um mestre
mestre, vamos escrever-me a qualquer nó.

554
00:23:54,440 --> 00:23:55,540
Então o que acontece?

555
00:23:55,540 --> 00:23:58,270
Então, eu tenho um objeto no
banco de dados que existe em dois nós.

556
00:23:58,270 --> 00:24:01,705
Vamos chamar esse objeto S.
Portanto, temos estado para S.

557
00:24:01,705 --> 00:24:04,312
Temos algumas operações
S em que estão em curso.

558
00:24:04,312 --> 00:24:06,270
Cassandra me permite
escrever para vários nós.

559
00:24:06,270 --> 00:24:08,550
Então, digamos que eu recebo uma
escrever para s para dois nós.

560
00:24:08,550 --> 00:24:12,274
Bem, o que acaba acontecendo é
chamamos isso de um evento de particionamento.

561
00:24:12,274 --> 00:24:14,190
Não pode ser um
partição de rede física.

562
00:24:14,190 --> 00:24:15,950
Mas por causa do projeto
do sistema, que é

563
00:24:15,950 --> 00:24:18,449
particionamento realmente logo
que eu conseguir uma gravação em dois nós.

564
00:24:18,449 --> 00:24:20,830
Não está me forçando a
escrever tudo através de um nó.

565
00:24:20,830 --> 00:24:22,340
Eu estou escrevendo sobre dois nós.

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

567
00:24:23,330 --> 00:24:25,740
>> Então agora eu tenho dois estados.

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

569
00:24:26,360 --> 00:24:28,110
O que vai acontecer
é, mais cedo ou mais tarde,

570
00:24:28,110 --> 00:24:29,960
lá vai ser um evento de replicação.

571
00:24:29,960 --> 00:24:33,300
Não vai ser o que nós
chamado de recuperação de partição, que

572
00:24:33,300 --> 00:24:35,200
é o lugar onde estes dois
estados voltar juntos

573
00:24:35,200 --> 00:24:37,310
e lá vai ser um algoritmo
que é executado dentro do banco de dados,

574
00:24:37,310 --> 00:24:38,540
decide o que fazer.

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

576
00:24:39,110 --> 00:24:43,057
Por padrão, última atualização
vence na maioria dos sistemas de AP.

577
00:24:43,057 --> 00:24:44,890
Portanto, há geralmente um
algoritmo padrão, o que

578
00:24:44,890 --> 00:24:47,400
eles chamam de um callback
função, algo que

579
00:24:47,400 --> 00:24:51,000
será chamado quando esta condição
seja detectado para executar alguma lógica

580
00:24:51,000 --> 00:24:52,900
para resolver esse conflito.

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

582
00:24:53,850 --> 00:24:58,770
O retorno de chamada padrão e padrão
resolver na maioria dos bancos de dados AP

583
00:24:58,770 --> 00:25:01,130
é, adivinhem, timestamp ganha.

584
00:25:01,130 --> 00:25:02,380
Esta foi a última atualização.

585
00:25:02,380 --> 00:25:04,320
Eu vou colocar essa atualização lá.

586
00:25:04,320 --> 00:25:08,440
Eu posso despejar este registro que eu
despejado fora em um log de recuperação

587
00:25:08,440 --> 00:25:11,670
de modo que o usuário pode voltar mais tarde
e dizer, hey, houve uma colisão.

588
00:25:11,670 --> 00:25:12,320
O que aconteceu?

589
00:25:12,320 --> 00:25:16,370
E você pode realmente despejar um registro de
todas as colisões e as reversões

590
00:25:16,370 --> 00:25:17,550
e ver o que acontece.

591
00:25:17,550 --> 00:25:21,580
>> Agora, como um usuário, você também pode
incluir lógica em que callback.

592
00:25:21,580 --> 00:25:24,290
Assim, você pode mudar isso
operação de retorno de chamada.

593
00:25:24,290 --> 00:25:26,730
Você pode dizer, hey, eu quero
para remediar esses dados.

594
00:25:26,730 --> 00:25:28,880
E eu quero tentar e
mesclar esses dois registros.

595
00:25:28,880 --> 00:25:30,050
Mas isso é até você.

596
00:25:30,050 --> 00:25:32,880
O banco de dados não sabe como
fazer isso por padrão. A maior parte do tempo,

597
00:25:32,880 --> 00:25:34,850
a única coisa que o banco de dados
sabe fazer é dizer,

598
00:25:34,850 --> 00:25:36,100
este foi o último registro.

599
00:25:36,100 --> 00:25:39,183
Isso é o que vai ganhar,
e esse é o valor que eu vou colocar.

600
00:25:39,183 --> 00:25:41,490
Uma vez que a recuperação partição
e replicação ocorre,

601
00:25:41,490 --> 00:25:43,930
temos o nosso estado, que
agora é S principal, que é

602
00:25:43,930 --> 00:25:46,890
o estado de mesclagem de todos esses objetos.

603
00:25:46,890 --> 00:25:49,700
Assim, os sistemas AP ter isso.

604
00:25:49,700 --> 00:25:51,615
Sistemas CP não precisa
se preocupar com isso.

605
00:25:51,615 --> 00:25:54,490
Porque assim como uma partição vem
em jogo, eles simplesmente parar de tomar

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

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

608
00:25:56,180 --> 00:25:58,670
Então, isso é muito fácil
lidar com ser consistente

609
00:25:58,670 --> 00:26:01,330
quando você não aceitar quaisquer atualizações.

610
00:26:01,330 --> 00:26:04,620
Isso é com os sistemas CP fazer.

611
00:26:04,620 --> 00:26:05,120
Tudo certo.

612
00:26:05,120 --> 00:26:07,590
>> Então vamos falar um pouco
pouco sobre padrões de acesso.

613
00:26:07,590 --> 00:26:11,580
Quando falamos de NoSQL, é
tudo sobre o padrão de acesso.

614
00:26:11,580 --> 00:26:13,550
Agora, o SQL é ad hoc, as consultas.

615
00:26:13,550 --> 00:26:14,481
É armazenamento relacional.

616
00:26:14,481 --> 00:26:16,480
Nós não temos que preocupar-se
sobre o padrão de acesso.

617
00:26:16,480 --> 00:26:17,688
Eu escrever uma consulta muito complexa.

618
00:26:17,688 --> 00:26:19,250
Ele vai e pega os dados.

619
00:26:19,250 --> 00:26:21,210
Isso é o que isso parece
como, normalização.

620
00:26:21,210 --> 00:26:24,890
>> Portanto, neste estrutura particular,
nós estamos olhando para um catálogo de produtos.

621
00:26:24,890 --> 00:26:26,640
I têm diferentes tipos de produtos.

622
00:26:26,640 --> 00:26:27,217
Tenho livros.

623
00:26:27,217 --> 00:26:27,800
Eu tenho álbuns.

624
00:26:27,800 --> 00:26:30,090
Eu tenho vídeos.

625
00:26:30,090 --> 00:26:33,370
A relação entre os produtos
e qualquer um desses livros, álbuns,

626
00:26:33,370 --> 00:26:34,860
e vídeos tabelas é 1: 1.

627
00:26:34,860 --> 00:26:35,800
Tudo certo?

628
00:26:35,800 --> 00:26:38,860
Eu tenho um ID do produto,
e que corresponde ID

629
00:26:38,860 --> 00:26:41,080
para um livro, um álbum ou um vídeo.

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

631
00:26:41,580 --> 00:26:44,350
Isso é uma relação 1: 1
através dessas tabelas.

632
00:26:44,350 --> 00:26:46,970
>> Agora, todos eles books--
tem é propriedades da raiz.

633
00:26:46,970 --> 00:26:47,550
Sem problemas.

634
00:26:47,550 --> 00:26:48,230
Isso é ótimo.

635
00:26:48,230 --> 00:26:52,130
One-to-one relacionamento, eu recebo tudo
os dados que eu preciso para descrever esse livro.

636
00:26:52,130 --> 00:26:54,770
Álbuns Albums-- têm faixas.

637
00:26:54,770 --> 00:26:56,470
Isto é o que chamamos de um para muitos.

638
00:26:56,470 --> 00:26:58,905
Cada álbum pode ter muitas faixas.

639
00:26:58,905 --> 00:27:00,780
Assim, para cada faixa
o álbum, eu poderia ter

640
00:27:00,780 --> 00:27:02,570
outro recorde nesta tabela filho.

641
00:27:02,570 --> 00:27:04,680
Então eu criar um registro
na minha tabela de álbuns.

642
00:27:04,680 --> 00:27:06,700
Eu criar vários registros
na tabela de faixas.

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

644
00:27:08,850 --> 00:27:11,220
>> Esta relação é o que
que chamamos de muitos-para-muitos.

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

646
00:27:11,750 --> 00:27:17,000
Você vê que os atores poderiam ser
em muitos filmes, muitos vídeos.

647
00:27:17,000 --> 00:27:21,450
Então, o que fazemos é colocar esse mapeamento
mesa entre aqueles, que ele só

648
00:27:21,450 --> 00:27:24,040
mapeia o ID ator para o ID de vídeo.

649
00:27:24,040 --> 00:27:28,464
Agora eu posso criar uma consulta da junta
vídeos através de vídeo ator para atores,

650
00:27:28,464 --> 00:27:31,130
e isso me dá uma boa lista de
todos os filmes e todos os atores

651
00:27:31,130 --> 00:27:32,420
que eram naquele filme.

652
00:27:32,420 --> 00:27:33,290
>> ESTÁ BEM.

653
00:27:33,290 --> 00:27:33,880
Então, vamos lá.

654
00:27:33,880 --> 00:27:38,040
One-to-one é a de nível superior
relação; um-para-muitos,

655
00:27:38,040 --> 00:27:40,240
álbuns de trilhas; muitos-para-muitos.

656
00:27:40,240 --> 00:27:44,990
Esses são os três de nível superior
relacionamentos em qualquer banco de dados.

657
00:27:44,990 --> 00:27:48,050
Se você sabe como aqueles
relações de trabalho em conjunto,

658
00:27:48,050 --> 00:27:51,490
então você sabe muito
sobre banco de dados já.

659
00:27:51,490 --> 00:27:55,660
Então NoSQL funciona um pouco diferente.

660
00:27:55,660 --> 00:27:58,930
Vamos pensar por um segundo o que
olhares gosta de ir obter todos os meus produtos.

661
00:27:58,930 --> 00:28:01,096
>> Em uma loja relacional, I
quer obter todos os meus produtos

662
00:28:01,096 --> 00:28:02,970
em uma lista de todos os meus produtos.

663
00:28:02,970 --> 00:28:04,910
Isso é um monte de consultas.

664
00:28:04,910 --> 00:28:07,030
Eu tenho uma consulta para todos os meus livros.

665
00:28:07,030 --> 00:28:08,470
Eu tenho uma consulta dos meus álbuns.

666
00:28:08,470 --> 00:28:09,970
E eu tenho uma consulta para todos os meus vídeos.

667
00:28:09,970 --> 00:28:11,719
E eu tenho que colocá-lo
todos juntos em uma lista

668
00:28:11,719 --> 00:28:15,250
e servi-lo de volta até o
aplicativo que está solicitando isso.

669
00:28:15,250 --> 00:28:18,000
>> Para obter os meus livros, eu juntar-
Produtos e Livros.

670
00:28:18,000 --> 00:28:21,680
Para obter os meus álbuns, eu comecei a juntar-se
Produtos, Álbuns, e faixas.

671
00:28:21,680 --> 00:28:25,330
E para obter meus vídeos, eu tenho
para juntar-se os produtos a vídeos,

672
00:28:25,330 --> 00:28:28,890
juntar-se através Ator vídeos,
e trazer os atores.

673
00:28:28,890 --> 00:28:31,020
Então, isso é três consultas.

674
00:28:31,020 --> 00:28:34,560
Consultas muito complexas para
montar um conjunto de resultados.

675
00:28:34,560 --> 00:28:36,540
>> Isso é menos do que ideal.

676
00:28:36,540 --> 00:28:39,200
É por isso que quando falamos
sobre uma estrutura de dados que é

677
00:28:39,200 --> 00:28:42,900
construído para ser agnóstico ao acesso
pattern-- bem, isso é ótimo.

678
00:28:42,900 --> 00:28:45,730
E você pode ver isso é realmente
agradável como nós organizamos os dados.

679
00:28:45,730 --> 00:28:46,550
E você sabe o que?

680
00:28:46,550 --> 00:28:49,750
Eu só tenho um recorde para um ator.

681
00:28:49,750 --> 00:28:50,440
>> Isso é legal.

682
00:28:50,440 --> 00:28:53,750
Eu deduplicados todos os meus atores,
e eu mantive minhas associações

683
00:28:53,750 --> 00:28:55,200
nesta tabela de mapeamento.

684
00:28:55,200 --> 00:29:00,620
No entanto, obter os dados
fora torna-se caro.

685
00:29:00,620 --> 00:29:04,500
Estou enviando a CPU em todo o sistema
juntando essas estruturas de dados em conjunto

686
00:29:04,500 --> 00:29:05,950
para ser capaz de puxar os dados de volta.

687
00:29:05,950 --> 00:29:07,310
>> Então, como posso contornar isso?

688
00:29:07,310 --> 00:29:11,200
Em NoSQL é sobre
agregação, não normalização.

689
00:29:11,200 --> 00:29:13,534
Por isso, queremos dizer que nós queremos
apoiar o padrão de acesso.

690
00:29:13,534 --> 00:29:15,283
Se o padrão de acesso
para as aplicações,

691
00:29:15,283 --> 00:29:16,770
Eu preciso para obter todos os meus produtos.

692
00:29:16,770 --> 00:29:19,027
Vamos colocar todos os produtos em uma tabela.

693
00:29:19,027 --> 00:29:22,110
Se eu colocar todos os produtos em uma tabela,
Eu só posso selecionar todos os produtos

694
00:29:22,110 --> 00:29:23,850
a partir dessa mesa e eu entendi tudo.

695
00:29:23,850 --> 00:29:25,240
Bem, como eu faço isso?

696
00:29:25,240 --> 00:29:28,124
Bem em NoSQL não há nenhuma
estrutura para a mesa.

697
00:29:28,124 --> 00:29:30,540
Vamos falar um pouco sobre
como isso funciona na Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Mas você não tem o mesmo
atributos e as mesmas propriedades

699
00:29:33,570 --> 00:29:37,751
em cada linha única, em cada
item, como você faz em uma tabela SQL.

700
00:29:37,751 --> 00:29:39,750
E o que isso me permite
para fazer um monte de coisas

701
00:29:39,750 --> 00:29:41,124
e me dar um monte de flexibilidade.

702
00:29:41,124 --> 00:29:45,360
Neste caso particular, eu
tenho meus documentos do produto.

703
00:29:45,360 --> 00:29:49,090
E nesse particular
exemplo, tudo

704
00:29:49,090 --> 00:29:51,930
é um documento na tabela Produtos.

705
00:29:51,930 --> 00:29:56,510
E o produto de um livro pode
ter um ID de tipo que especifica um livro.

706
00:29:56,510 --> 00:29:59,180
E a aplicação
mudariam em que ID.

707
00:29:59,180 --> 00:30:02,570
>> Na camada de aplicativo, eu vou
para dizer oh, que tipo de registro é isso?

708
00:30:02,570 --> 00:30:04,100
Oh, é um registro livro.

709
00:30:04,100 --> 00:30:05,990
Registros do livro têm essas propriedades.

710
00:30:05,990 --> 00:30:08,100
Deixe-me criar um objeto livro.

711
00:30:08,100 --> 00:30:11,289
Então, eu estou indo para preencher o
livro objeto com este item.

712
00:30:11,289 --> 00:30:13,080
Próximo item vem e
diz, o que é este item?

713
00:30:13,080 --> 00:30:14,560
Bem, este item é um álbum.

714
00:30:14,560 --> 00:30:17,340
Oh, eu tenho um diferente inteiro
rotina de processamento para que,

715
00:30:17,340 --> 00:30:18,487
porque é um álbum.

716
00:30:18,487 --> 00:30:19,320
Você vê o que eu quero dizer?

717
00:30:19,320 --> 00:30:21,950
>> Assim, a aplicação tier-- I
basta selecionar todos esses registros.

718
00:30:21,950 --> 00:30:23,200
Todos eles começam a vir.

719
00:30:23,200 --> 00:30:24,680
Eles podem ser de todos os tipos diferentes.

720
00:30:24,680 --> 00:30:27,590
E é a lógica do aplicativo
que alterna entre os tipos

721
00:30:27,590 --> 00:30:29,530
e decide como processá-los.

722
00:30:29,530 --> 00:30:33,640
>> Mais uma vez, por isso estamos otimizando o
esquema para o padrão de acesso.

723
00:30:33,640 --> 00:30:36,390
Estamos fazendo isso por
colapso dessas tabelas.

724
00:30:36,390 --> 00:30:39,670
Estamos basicamente tomando
estas estruturas normalizados,

725
00:30:39,670 --> 00:30:42,000
e nós estamos construindo
estruturas hierárquicas.

726
00:30:42,000 --> 00:30:45,130
Dentro de cada um destes registos
Eu estou indo para ver propriedades de matriz.

727
00:30:45,130 --> 00:30:49,400
>> Dentro deste documento para Álbuns,
Eu estou vendo matrizes de faixas.

728
00:30:49,400 --> 00:30:53,900
Essas faixas agora é become--
basicamente esta tabela filho que

729
00:30:53,900 --> 00:30:56,520
existe aqui nesta estrutura.

730
00:30:56,520 --> 00:30:57,975
Assim, você pode fazer isso no DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Você pode fazer isso no MongoDB.

732
00:30:59,810 --> 00:31:01,437
Você pode fazer isso em qualquer banco de dados NoSQL.

733
00:31:01,437 --> 00:31:03,520
Criar estes tipos de
estruturas de dados hierárquicos

734
00:31:03,520 --> 00:31:07,120
que permitem que você recuperar dados
muito rapidamente, porque agora eu

735
00:31:07,120 --> 00:31:08,537
não tem que se conformar.

736
00:31:08,537 --> 00:31:11,620
Quando eu inserir uma linha para as Faixas
mesa, ou uma linha na tabela de álbuns,

737
00:31:11,620 --> 00:31:13,110
Eu tenho que estar em conformidade com esse esquema.

738
00:31:13,110 --> 00:31:18,060
Eu tenho que ter o atributo ou a
propriedade que é definida nessa tabela.

739
00:31:18,060 --> 00:31:20,480
Cada um deles,
quando eu inserir essa linha.

740
00:31:20,480 --> 00:31:21,910
Isso não é o caso em NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Eu posso ter totalmente diferente
propriedades em cada documento

742
00:31:24,440 --> 00:31:26,100
que eu inserir na coleção.

743
00:31:26,100 --> 00:31:30,480
Então mecanismo muito poderoso.

744
00:31:30,480 --> 00:31:32,852
E é realmente como você
optimizar o sistema.

745
00:31:32,852 --> 00:31:35,310
Porque agora que consulta, em vez
de juntar todas essas tabelas

746
00:31:35,310 --> 00:31:39,160
e execução de uma meia dúzia de consultas
para puxar a dados que eu preciso,

747
00:31:39,160 --> 00:31:40,890
Estou executando uma consulta.

748
00:31:40,890 --> 00:31:43,010
E eu estou a iteração
em todo o conjunto de resultados.

749
00:31:43,010 --> 00:31:46,512
dá-lhe uma ideia
do poder de NoSQL.

750
00:31:46,512 --> 00:31:49,470
Eu estou indo para ir para o lado tipo de aqui
e falar um pouco sobre isso.

751
00:31:49,470 --> 00:31:53,240
Isto é mais do tipo
comercialização ou technology--

752
00:31:53,240 --> 00:31:55,660
a comercialização de tecnologia
tipo de discussão.

753
00:31:55,660 --> 00:31:58,672
Mas é importante entender
porque, se olharmos para o topo

754
00:31:58,672 --> 00:32:00,380
aqui nesta carta,
o que nós estamos olhando para

755
00:32:00,380 --> 00:32:04,030
é o que chamamos de
curva campanha publicitária tecnologia.

756
00:32:04,030 --> 00:32:06,121
E o que isto significa é
material novo entra em jogo.

757
00:32:06,121 --> 00:32:07,120
As pessoas pensam que é ótimo.

758
00:32:07,120 --> 00:32:09,200
Eu já resolveu todos os meus problemas.

759
00:32:09,200 --> 00:32:11,630
>> Esta poderia ser a extremidade
tudo, ser tudo de tudo.

760
00:32:11,630 --> 00:32:12,790
E eles começam a usá-lo.

761
00:32:12,790 --> 00:32:14,720
E eles dizem, essa coisa não funciona.

762
00:32:14,720 --> 00:32:17,600
Isto não está certo.

763
00:32:17,600 --> 00:32:19,105
O material antigo era melhor.

764
00:32:19,105 --> 00:32:21,230
E eles vão voltar a fazer
as coisas do jeito que estavam.

765
00:32:21,230 --> 00:32:22,730
E depois, eventualmente,
eles vão, você sabe o quê?

766
00:32:22,730 --> 00:32:24,040
Este material não é tão ruim.

767
00:32:24,040 --> 00:32:26,192
Oh, é assim que funciona.

768
00:32:26,192 --> 00:32:28,900
E uma vez que descobrir como ele
obras, eles começam a ficar melhor.

769
00:32:28,900 --> 00:32:32,050
>> E o engraçado sobre isso
é, que tipo de linhas até que

770
00:32:32,050 --> 00:32:34,300
chamamos a Curva de Adoção de Tecnologia.

771
00:32:34,300 --> 00:32:36,910
Então o que acontece é que temos
algum tipo de gatilho tecnologia.

772
00:32:36,910 --> 00:32:39,100
No caso das bases de dados,
é a pressão de dados.

773
00:32:39,100 --> 00:32:42,200
Nós conversamos sobre os pontos de água altos
dados de pressão ao longo do tempo.

774
00:32:42,200 --> 00:32:46,310
Quando esta pressão atinge um certo dados
ponto, isso é um gatilho tecnologia.

775
00:32:46,310 --> 00:32:47,830
>> Está ficando muito caro.

776
00:32:47,830 --> 00:32:49,790
Leva muito tempo para processar os dados.

777
00:32:49,790 --> 00:32:50,890
Precisamos de algo melhor.

778
00:32:50,890 --> 00:32:52,890
Você obtém os inovadores
lá fora, correndo por aí,

779
00:32:52,890 --> 00:32:55,050
tentando descobrir qual é a solução.

780
00:32:55,050 --> 00:32:56,050
Qual é a nova idéia?

781
00:32:56,050 --> 00:32:58,170
>> Qual é a melhor próxima
maneira de fazer isso?

782
00:32:58,170 --> 00:32:59,530
E eles vêm para cima com alguma coisa.

783
00:32:59,530 --> 00:33:03,140
E as pessoas com a dor real,
os indivíduos na borda do sangramento,

784
00:33:03,140 --> 00:33:06,390
eles vão saltar tudo sobre ele,
porque eles precisam de uma resposta.

785
00:33:06,390 --> 00:33:09,690
Agora, o que inevitavelmente happens-- e
isso está acontecendo agora em NoSQL.

786
00:33:09,690 --> 00:33:11,090
Eu vejo isso o tempo todo.

787
00:33:11,090 --> 00:33:13,610
>> O que acontece é inevitavelmente
pessoas começam a usar a nova ferramenta

788
00:33:13,610 --> 00:33:15,490
da mesma forma que usou a ferramenta de idade.

789
00:33:15,490 --> 00:33:17,854
E eles descobrir que
não funciona tão bem.

790
00:33:17,854 --> 00:33:20,020
Não consigo me lembrar quem eu era
falando mais cedo hoje.

791
00:33:20,020 --> 00:33:22,080
Mas é como, quando o
britadeira foi inventado,

792
00:33:22,080 --> 00:33:24,621
as pessoas não balançá-lo sobre
sua cabeça para quebrar o concreto.

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

794
00:33:27,360 --> 00:33:30,610
>> Mas isso é o que é
acontecendo com NoSQL hoje.

795
00:33:30,610 --> 00:33:33,900
Se você caminhada para a maioria das lojas,
eles estão tentando ser lojas NoSQL.

796
00:33:33,900 --> 00:33:36,510
O que eles estão fazendo é
eles estão usando NoSQL,

797
00:33:36,510 --> 00:33:39,900
e eles estão carregando-
cheio de esquema relacional.

798
00:33:39,900 --> 00:33:41,630
Porque é assim que
eles projetam bancos de dados.

799
00:33:41,630 --> 00:33:44,046
E eles estão se perguntando, por que é
não realizar muito bem?

800
00:33:44,046 --> 00:33:45,230
Rapaz, essa coisa fede.

801
00:33:45,230 --> 00:33:49,900
Eu tive que manter toda a minha
junta-se em-- como é, não, não.

802
00:33:49,900 --> 00:33:50,800
Manter junta?

803
00:33:50,800 --> 00:33:52,430
Por que você está juntando dados?

804
00:33:52,430 --> 00:33:54,350
Você não se juntar dados NoSQL.

805
00:33:54,350 --> 00:33:55,850
Você agregar-lo.

806
00:33:55,850 --> 00:34:00,690
>> Então, se você quiser evitar isso, aprender
como a ferramenta funciona antes que você realmente

807
00:34:00,690 --> 00:34:02,010
começar a usá-lo.

808
00:34:02,010 --> 00:34:04,860
Não tente usar as novas ferramentas do
mesma maneira que você usou as ferramentas antigas.

809
00:34:04,860 --> 00:34:06,500
Você vai ter uma experiência ruim.

810
00:34:06,500 --> 00:34:08,848
E cada vez
isso é o que se trata.

811
00:34:08,848 --> 00:34:11,389
Quando começam a vir até aqui,
é porque as pessoas descobriram

812
00:34:11,389 --> 00:34:13,449
como usar as ferramentas.

813
00:34:13,449 --> 00:34:16,250
>> Eles fizeram a mesma coisa quando
bancos de dados relacionais foram inventados,

814
00:34:16,250 --> 00:34:17,969
e eles estavam substituindo os sistemas de arquivos.

815
00:34:17,969 --> 00:34:20,420
Eles tentaram construir sistemas de arquivos
com bancos de dados relacionais

816
00:34:20,420 --> 00:34:22,159
porque é isso que as pessoas entendessem.

817
00:34:22,159 --> 00:34:23,049
Não funcionou.

818
00:34:23,049 --> 00:34:26,090
Assim, a compreensão das melhores práticas
da tecnologia você está trabalhando com

819
00:34:26,090 --> 00:34:26,730
é enorme.

820
00:34:26,730 --> 00:34:29,870
Muito importante.

821
00:34:29,870 --> 00:34:32,440
>> Então, nós estamos indo para entrar em DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB é AWS de
totalmente de gestão plataforma NoSQL.

823
00:34:36,480 --> 00:34:37,719
O que totalmente de gestão significa?

824
00:34:37,719 --> 00:34:40,010
Isso significa que você não precisa
realmente se preocupar com nada.

825
00:34:40,010 --> 00:34:42,060
>> Você entra, você diz
nós, eu preciso de uma mesa.

826
00:34:42,060 --> 00:34:43,409
Ele precisa de tanta capacidade.

827
00:34:43,409 --> 00:34:47,300
Você pressiona o botão, e provisão nós
toda infra-estrutura por trás da cena.

828
00:34:47,300 --> 00:34:48,310
Agora que é enorme.

829
00:34:48,310 --> 00:34:51,310
>> Porque quando você fala
sobre o dimensionamento de um banco de dados,

830
00:34:51,310 --> 00:34:53,917
Clusters de dados NoSQL na
escala, petabytes de funcionamento,

831
00:34:53,917 --> 00:34:55,750
executando milhões de
transações por segundo,

832
00:34:55,750 --> 00:34:58,180
estas coisas não são pequenos clusters.

833
00:34:58,180 --> 00:35:00,830
Estamos falando de milhares de casos.

834
00:35:00,830 --> 00:35:04,480
Gerenciamento de milhares de instâncias,
até mesmo instâncias virtuais,

835
00:35:04,480 --> 00:35:06,350
é uma verdadeira dor na bunda.

836
00:35:06,350 --> 00:35:09,110
Quer dizer, pensar em cada vez que um
patch de sistema operacional sai

837
00:35:09,110 --> 00:35:11,552
ou uma nova versão do banco de dados.

838
00:35:11,552 --> 00:35:13,260
O que isso significa
operacionalmente a você?

839
00:35:13,260 --> 00:35:16,330
Isso significa que você tem 1200
servidores que precisam ser atualizados.

840
00:35:16,330 --> 00:35:18,960
Agora, até mesmo com a automação,
que pode levar um longo tempo.

841
00:35:18,960 --> 00:35:21,480
Isso pode causar uma série de
dores de cabeça operacionais,

842
00:35:21,480 --> 00:35:23,090
porque eu poderia ter serviços para baixo.

843
00:35:23,090 --> 00:35:26,070
>> Como eu atualizar essas bases de dados, I
pode fazer implantações verde azul

844
00:35:26,070 --> 00:35:29,420
onde eu implantar e atualizar a metade da minha
nós, e depois atualizar a outra metade.

845
00:35:29,420 --> 00:35:30,490
Tome aqueles para baixo.

846
00:35:30,490 --> 00:35:33,410
Portanto, o gerenciamento da infra-estrutura
escala é extremamente doloroso.

847
00:35:33,410 --> 00:35:36,210
E AWS assumir que a dor de fora.

848
00:35:36,210 --> 00:35:39,210
E bancos de dados NoSQL pode
ser extraordinariamente dolorosa

849
00:35:39,210 --> 00:35:41,780
por causa da maneira que escala.

850
00:35:41,780 --> 00:35:42,926
>> Dimensionar horizontalmente.

851
00:35:42,926 --> 00:35:45,550
Se você quiser obter um maior NoSQL
banco de dados, você compra mais nós.

852
00:35:45,550 --> 00:35:48,660
Cada nó que você compra é
outra cabeça operacional.

853
00:35:48,660 --> 00:35:50,830
Então deixe outra pessoa fazer isso por você.

854
00:35:50,830 --> 00:35:52,000
AWS pode fazer isso.

855
00:35:52,000 --> 00:35:54,587
>> Apoiamos os valores-chave do documento.

856
00:35:54,587 --> 00:35:56,670
Agora nós não ir muito
Por outro em gráfico.

857
00:35:56,670 --> 00:35:58,750
Há um monte de diferente
sabores de NoSQL.

858
00:35:58,750 --> 00:36:02,670
Eles são todos os tipos de conseguir
munged juntos neste momento.

859
00:36:02,670 --> 00:36:06,260
Você pode olhar para DynamoDB e dizer que sim,
nós dois somos um documento e um valor de chave

860
00:36:06,260 --> 00:36:08,412
armazenar este ponto.

861
00:36:08,412 --> 00:36:10,620
E você pode discutir as características
de um sobre o outro.

862
00:36:10,620 --> 00:36:13,950
Para mim, um monte de presente é realmente seis
de uma meia dúzia de outro.

863
00:36:13,950 --> 00:36:18,710
Cada uma dessas tecnologias é um
tecnologia de multa e uma solução bem.

864
00:36:18,710 --> 00:36:23,390
Eu não diria que é melhor ou MongoDB
pior do que Couch, em seguida, Cassandra,

865
00:36:23,390 --> 00:36:25,994
então Dynamo, ou vice-versa.

866
00:36:25,994 --> 00:36:27,285
Quero dizer, estes são apenas opções.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> É rápido e é
consistente em qualquer escala.

869
00:36:32,700 --> 00:36:36,210
Portanto, este é um dos maiores
bônus que você começa com a AWS.

870
00:36:36,210 --> 00:36:40,850
Com DynamoDB é a capacidade
para obter um baixo único dígito

871
00:36:40,850 --> 00:36:44,040
latência milissegundo em qualquer escala.

872
00:36:44,040 --> 00:36:45,720
Essa era uma meta de projeto do sistema.

873
00:36:45,720 --> 00:36:49,130
E temos clientes que estão fazendo
milhões de operações por segundo.

874
00:36:49,130 --> 00:36:52,670
>> Agora eu vou passar por algumas das pessoas
usar casos em poucos minutos aqui.

875
00:36:52,670 --> 00:36:55,660
Control-- acesso integrado
nós temos o que chamamos

876
00:36:55,660 --> 00:36:57,920
Gerenciamento de Acesso identidade ou IAM.

877
00:36:57,920 --> 00:37:01,980
Ela permeia todos os sistemas,
todos os serviços que a AWS oferece.

878
00:37:01,980 --> 00:37:03,630
DynamoDB não é excepção.

879
00:37:03,630 --> 00:37:06,020
Você pode controlar o acesso
para as tabelas DynamoDB.

880
00:37:06,020 --> 00:37:09,960
Em todas as suas contas pela AWS
definição de funções de acesso e permissões

881
00:37:09,960 --> 00:37:12,140
na infra-estrutura de IAM.

882
00:37:12,140 --> 00:37:16,630
>> E é um componente fundamental e integral em
o que chamamos de eventos programação orientada.

883
00:37:16,630 --> 00:37:19,056
Agora, este é um novo paradigma.

884
00:37:19,056 --> 00:37:22,080
>> AUDIÊNCIA: Como é a sua taxa de verdadeira
positivos contra falsos negativos

885
00:37:22,080 --> 00:37:24,052
em seu sistema de controle de acesso?

886
00:37:24,052 --> 00:37:26,260
RICK HOULIHAN: Verdadeiros positivos
contra falsos negativos?

887
00:37:26,260 --> 00:37:28,785
AUDIÊNCIA: Devolver o que
você deve estar retornando?

888
00:37:28,785 --> 00:37:33,720
Ao contrário de vez em quando ele
não retorna quando ele deve validar?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK HOULIHAN: Eu não poderia te dizer isso.

891
00:37:38,050 --> 00:37:40,140
Se houver quaisquer falhas
seja qual for, que,

892
00:37:40,140 --> 00:37:42,726
Eu não sou a pessoa para perguntar
essa questão particular.

893
00:37:42,726 --> 00:37:43,850
Mas isso é uma boa pergunta.

894
00:37:43,850 --> 00:37:45,905
Eu seria curioso para saber
que eu, na verdade.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> E assim, novamente, novo paradigma
é dirigida evento programação.

897
00:37:51,320 --> 00:37:55,160
Esta é a idéia de que você pode
implantar aplicativos complexos que

898
00:37:55,160 --> 00:37:59,720
pode operar um muito, muito alta escala
sem qualquer infra-estrutura qualquer.

899
00:37:59,720 --> 00:38:02,120
Sem qualquer fixo
infra-estrutura qualquer.

900
00:38:02,120 --> 00:38:04,720
E nós vamos falar um pouco
sobre o que isso significa que nós

901
00:38:04,720 --> 00:38:06,550
obter para o próximo par de cartas.

902
00:38:06,550 --> 00:38:08,716
>> A primeira coisa que vamos fazer
é falaremos sobre mesas.

903
00:38:08,716 --> 00:38:10,857
Tipos de dados API para Dynamo.

904
00:38:10,857 --> 00:38:13,190
E a primeira coisa que você vai
notar quando você olha para isso,

905
00:38:13,190 --> 00:38:17,930
se você estiver familiarizado com qualquer banco de dados,
bancos de dados têm realmente dois tipos de APIs

906
00:38:17,930 --> 00:38:18,430
Eu diria que é.

907
00:38:18,430 --> 00:38:21,570
Ou dois conjuntos de API.

908
00:38:21,570 --> 00:38:23,840
Uma delas seria
API administrativa.

909
00:38:23,840 --> 00:38:26,710
>> As coisas que eles cuidam de
as funções da base de dados.

910
00:38:26,710 --> 00:38:31,340
Configurando o mecanismo de armazenamento,
a criação e inclusão de tabelas.

911
00:38:31,340 --> 00:38:35,180
criação de banco de dados
catálogos e instâncias.

912
00:38:35,180 --> 00:38:40,450
Estes coisas- em DynamoDB, você
têm listas muito curto, curto.

913
00:38:40,450 --> 00:38:43,120
>> Portanto, em outras bases de dados,
você pode ver dezenas

914
00:38:43,120 --> 00:38:45,680
de comandos, de administrativa
comandos, para a configuração

915
00:38:45,680 --> 00:38:47,290
estas opções adicionais.

916
00:38:47,290 --> 00:38:51,234
Em DynamoDB você não precisa aqueles porque
você não configurar o sistema, o que fazemos.

917
00:38:51,234 --> 00:38:54,150
Então a única coisa que você precisa fazer é
me diga o que mesa tamanho eu preciso.

918
00:38:54,150 --> 00:38:55,660
Então você começa um muito
conjunto limitado de comandos.

919
00:38:55,660 --> 00:38:58,618
>> Você começa uma Create Table Update, Mesa,
Excluir Mesa, e descrever Table.

920
00:38:58,618 --> 00:39:01,150
Essas são as únicas coisas
você precisa para DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Você não precisa de um armazenamento
configuração do motor.

922
00:39:03,294 --> 00:39:04,960
Eu não precisa se preocupar com a replicação.

923
00:39:04,960 --> 00:39:06,490
Eu não precisa se preocupar com sharding.

924
00:39:06,490 --> 00:39:07,800
>> Eu não precisa se preocupar
sobre algum deste material.

925
00:39:07,800 --> 00:39:08,740
Fazemos tudo para você.

926
00:39:08,740 --> 00:39:11,867
Então, isso é uma enorme quantidade de sobrecarga
isso é só decolou seu prato.

927
00:39:11,867 --> 00:39:13,200
Então nós temos os operadores CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD é algo que temos
chamar banco de dados que é

929
00:39:17,740 --> 00:39:19,860
Criar, atualizar, excluir operadores.

930
00:39:19,860 --> 00:39:24,180
Estes são os seus comum
operações de banco de dados.

931
00:39:24,180 --> 00:39:31,299
Coisas como item de venda, obter item, atualização
itens, apagar objetos, consulta de lote, digitalizar.

932
00:39:31,299 --> 00:39:32,840
Se você quiser verificar a tabela inteira.

933
00:39:32,840 --> 00:39:34,220
Puxe tudo fora da mesa.

934
00:39:34,220 --> 00:39:37,130
Uma das coisas agradáveis ​​sobre DynamoDB
é que permite a digitalização paralela.

935
00:39:37,130 --> 00:39:40,602
Então você pode realmente deixe-me saber quantas
tópicos que você deseja executar em que digitalização.

936
00:39:40,602 --> 00:39:41,810
E nós podemos executar esses tópicos.

937
00:39:41,810 --> 00:39:43,985
Nós podemos girar que digitalizar até
através de múltiplas threads

938
00:39:43,985 --> 00:39:49,060
assim você pode verificar a tabela inteira
espaço muito, muito rapidamente no DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> A outra API que temos é
o que chamamos de nossa API Streams.

940
00:39:51,490 --> 00:39:52,940
Nós não vamos falar muito
muito sobre isso agora.

941
00:39:52,940 --> 00:39:55,189
Eu tenho algum conteúdo mais tarde
em no baralho sobre isso.

942
00:39:55,189 --> 00:39:59,910
Mas Streams é realmente um running--
pense nisso como o tempo encomendado

943
00:39:59,910 --> 00:40:01,274
e log de alterações partição.

944
00:40:01,274 --> 00:40:03,940
Tudo o que está acontecendo no
a tabela mostra-se no fluxo.

945
00:40:03,940 --> 00:40:05,940
>> Cada escrever para a mesa
mostra-se no fluxo.

946
00:40:05,940 --> 00:40:08,370
Você pode ler esse fluxo, e
você pode fazer coisas com ele.

947
00:40:08,370 --> 00:40:10,150
Vamos falar sobre o que
tipos de coisas que você

948
00:40:10,150 --> 00:40:13,680
fazer com as coisas como replicação,
a criação de índices secundários.

949
00:40:13,680 --> 00:40:17,620
Todos os tipos de muito legal
coisas que você pode fazer com isso.

950
00:40:17,620 --> 00:40:19,150
>> Os tipos de dados.

951
00:40:19,150 --> 00:40:23,320
Em DynamoDB, apoiamos tanto chave
valor e de dados documento tipos.

952
00:40:23,320 --> 00:40:26,350
No lado esquerdo do ecrã
aqui, nós temos os nossos tipos básicos.

953
00:40:26,350 --> 00:40:27,230
Tipos de valor-chave.

954
00:40:27,230 --> 00:40:30,040
Estes são cordas,
números e binários.

955
00:40:30,040 --> 00:40:31,640
>> Então, apenas três tipos básicos.

956
00:40:31,640 --> 00:40:33,700
E então você pode ter conjuntos de aqueles.

957
00:40:33,700 --> 00:40:37,650
Uma das coisas agradáveis ​​sobre NoSQL é
você pode conter matrizes como propriedades.

958
00:40:37,650 --> 00:40:42,050
E com DynamoDB pode conter matrizes
de tipos básicos como uma propriedade raiz.

959
00:40:42,050 --> 00:40:43,885
>> E depois há os tipos de documentos.

960
00:40:43,885 --> 00:40:45,510
Quantas pessoas estão familiarizadas com JSON?

961
00:40:45,510 --> 00:40:47,130
Vocês familiarizadas com JSON tanto?

962
00:40:47,130 --> 00:40:49,380
É basicamente JavaScript,
Object, Notation.

963
00:40:49,380 --> 00:40:52,510
Ele permite que você, basicamente,
definir uma estrutura hierárquica.

964
00:40:52,510 --> 00:40:58,107
>> Você pode armazenar um documento JSON em
DynamoDB usando componentes comuns

965
00:40:58,107 --> 00:41:00,940
ou blocos de construção que estão disponíveis
na maioria das linguagens de programação.

966
00:41:00,940 --> 00:41:03,602
Então, se você tem o Java, você está
olhando os mapas e listas.

967
00:41:03,602 --> 00:41:05,060
Eu posso criar objetos que área do mapa.

968
00:41:05,060 --> 00:41:08,030
Um mapa como valores-chave
armazenado como propriedades.

969
00:41:08,030 --> 00:41:10,890
E pode ter listas de
valores dentro dessas propriedades.

970
00:41:10,890 --> 00:41:13,490
Você pode armazenar este complexo
estrutura hierárquica

971
00:41:13,490 --> 00:41:16,320
como um único atributo
de um item de DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Então tabelas no DynamoDB, como a maioria
Bancos de dados NoSQL, as tabelas têm itens.

974
00:41:24,460 --> 00:41:26,469
Em MongoDB você faria
chamar esses documentos.

975
00:41:26,469 --> 00:41:27,760
E seria a base sofá.

976
00:41:27,760 --> 00:41:28,900
Além disso uma base de dados de documento.

977
00:41:28,900 --> 00:41:29,941
Você chama esses documentos.

978
00:41:29,941 --> 00:41:32,930
Documentos ou itens têm atributos.

979
00:41:32,930 --> 00:41:35,850
Pode existir atributos ou
não existe no produto.

980
00:41:35,850 --> 00:41:38,520
Em DynamoDB, há
um atributo obrigatório.

981
00:41:38,520 --> 00:41:43,880
Assim como em um banco de dados relacional,
você tem uma chave primária na tabela.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB tem o que chamamos de uma chave de hash.

983
00:41:46,010 --> 00:41:48,280
Chave de hash deve ser exclusivo.

984
00:41:48,280 --> 00:41:52,580
Então, quando eu definir uma tabela hash,
basicamente o que eu estou dizendo

985
00:41:52,580 --> 00:41:54,110
é cada item terá uma chave de hash.

986
00:41:54,110 --> 00:41:58,520
E cada chave de hash deve ser exclusivo.

987
00:41:58,520 --> 00:42:01,200
>> Cada item é definido
por essa chave da mistura original.

988
00:42:01,200 --> 00:42:02,940
E só pode haver um.

989
00:42:02,940 --> 00:42:05,820
Este é OK, mas muitas vezes
que as pessoas precisam

990
00:42:05,820 --> 00:42:08,170
é que eles querem é esse hash
chave para fazer um pouco mais

991
00:42:08,170 --> 00:42:11,010
que apenas ser um identificador único.

992
00:42:11,010 --> 00:42:15,240
Muitas vezes nós queremos usar essa chave de hash
como o topo balde agregação nível.

993
00:42:15,240 --> 00:42:19,160
E a maneira de fazermos isso é por
acrescentando o que chamamos de uma chave intervalo.

994
00:42:19,160 --> 00:42:22,460
>> Então, se é apenas um hash
mesa, esta deve ser exclusivo.

995
00:42:22,460 --> 00:42:27,040
Se é uma tabela hash e gama, o
combinação do hash eo intervalo

996
00:42:27,040 --> 00:42:28,640
deve ser exclusivo.

997
00:42:28,640 --> 00:42:30,110
Então, pense nisso desta maneira.

998
00:42:30,110 --> 00:42:32,140
Se eu tiver um fórum.

999
00:42:32,140 --> 00:42:39,010
E a forma tem tópicos, tem
lança, e tem respostas.

1000
00:42:39,010 --> 00:42:42,630
>> Então, eu poderia ter um hash
chave, que é a identificação de tópico.

1001
00:42:42,630 --> 00:42:46,650
E eu poderia ter uma chave de gama,
que representa a identificação da resposta.

1002
00:42:46,650 --> 00:42:49,650
Dessa forma, se eu quiser obter todas as
respostas para determinado tópico,

1003
00:42:49,650 --> 00:42:52,370
Eu só posso consultar o hash.

1004
00:42:52,370 --> 00:42:55,190
Posso apenas dizer que me dar tudo
os itens que têm esse hash.

1005
00:42:55,190 --> 00:43:01,910
E eu estou indo para obter todas as perguntas
ou postar para esse tópico particular.

1006
00:43:01,910 --> 00:43:03,910
Essas agregações de nível superior
são muito importantes.

1007
00:43:03,910 --> 00:43:07,370
Eles suportam o acesso primário
padrão do aplicativo.

1008
00:43:07,370 --> 00:43:09,420
De um modo geral, esta
é o que nós queremos fazer.

1009
00:43:09,420 --> 00:43:11,780
Queremos que mesa--
como você carregar a tabela,

1010
00:43:11,780 --> 00:43:16,640
queremos estruturar a dados
dentro da tabela de tal maneira

1011
00:43:16,640 --> 00:43:20,140
que a aplicação pode muito
recuperar rapidamente esses resultados.

1012
00:43:20,140 --> 00:43:24,510
E muitas vezes a maneira de fazer isso é
para manter estas agregações como nós

1013
00:43:24,510 --> 00:43:25,650
inserir os dados.

1014
00:43:25,650 --> 00:43:31,110
Basicamente, nós estamos espalhando os dados
no balde brilhante como ele vem em.

1015
00:43:31,110 --> 00:43:35,210
>> Intervalo de chaves de hash permitir me--
chaves tem que ser igualdade.

1016
00:43:35,210 --> 00:43:39,490
Quando eu consultar um hash, eu tenho que dizer
dê-me um hash que é igual a este.

1017
00:43:39,490 --> 00:43:41,950
Quando eu consultar um intervalo, eu
pode dizer-me dar um intervalo

1018
00:43:41,950 --> 00:43:47,040
que está usando qualquer tipo de
operador rico que apoiamos.

1019
00:43:47,040 --> 00:43:49,200
Dê-me todos os itens para um hash.

1020
00:43:49,200 --> 00:43:52,520
É igual, maior que,
menos do que, não é começar,

1021
00:43:52,520 --> 00:43:54,145
ela existe entre estes dois valores?

1022
00:43:54,145 --> 00:43:56,811
Então, esses tipos de consultas de intervalo
que estamos sempre interessados ​​em.

1023
00:43:56,811 --> 00:43:59,650
Agora uma coisa sobre os dados, quando
você olhar para o acesso a dados, quando

1024
00:43:59,650 --> 00:44:02,360
você acessar os dados, é
sempre sobre uma agregação.

1025
00:44:02,360 --> 00:44:05,770
É sempre sobre os registros
que estão relacionadas com este.

1026
00:44:05,770 --> 00:44:10,390
Dá-me tudo aqui that's-- tudo
as transações de cartão de crédito nesta

1027
00:44:10,390 --> 00:44:12,500
para o último mês.

1028
00:44:12,500 --> 00:44:13,960
Isso é uma agregação.

1029
00:44:13,960 --> 00:44:17,490
>> Quase tudo que você faz no
banco de dados é um tipo de agregação.

1030
00:44:17,490 --> 00:44:21,530
Assim, ser capaz de ser capaz de definir
estes baldes e dar-lhe estes variam

1031
00:44:21,530 --> 00:44:24,950
atributos de ser capaz de consulta em,
essas consultas ricos apoiar muitos,

1032
00:44:24,950 --> 00:44:27,165
muitos, muitos padrões de acesso do aplicativo.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Então a outra coisa a chave de hash
faz é que nos dá um mecanismo

1035
00:44:35,000 --> 00:44:37,740
para ser capaz de difundir os dados de volta.

1036
00:44:37,740 --> 00:44:40,390
Bancos de dados NoSQL funcionar melhor
quando os dados são uniformemente

1037
00:44:40,390 --> 00:44:41,740
distribuídos em todo o cluster.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Quantas pessoas estão familiarizados
com algoritmos de hash?

1040
00:44:47,050 --> 00:44:49,860
Quando eu digo de hash e um hashing--
porque um algoritmo de hashing

1041
00:44:49,860 --> 00:44:54,140
é um modo de ser capaz de gerar
um valor aleatório de qualquer valor dado.

1042
00:44:54,140 --> 00:44:59,300
Portanto, neste caso particular, o
algoritmo de hash que corremos é ND 5 com base.

1043
00:44:59,300 --> 00:45:04,765
>> E se eu tiver um ID, e este
é a minha chave de hash, eu tenho 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Quando eu executar o algoritmo de hash,
ele vai voltar e dizer,

1045
00:45:07,390 --> 00:45:10,800
poço 1 é igual a 7B, 2
é igual a 48, é igual a 3 CD.

1046
00:45:10,800 --> 00:45:13,092
Eles estão espalhados por todo o espaço da chave.

1047
00:45:13,092 --> 00:45:14,050
E por que você faz isso?

1048
00:45:14,050 --> 00:45:17,120
Porque isso garante que eu posso
colocar os registros em vários nós.

1049
00:45:17,120 --> 00:45:19,574
>> Se eu estou fazendo isso
incrementalmente, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
E eu tenho uma gama de hash que
runs, neste caso específico,

1051
00:45:21,990 --> 00:45:24,785
um pequeno espaço de hash,
que vai de 00 a FF,

1052
00:45:24,785 --> 00:45:27,951
em seguida, os registros vão vir em
e eles estão indo para ir 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
O que acontece?

1055
00:45:31,800 --> 00:45:34,860
Cada inserção é indo para o mesmo nó.

1056
00:45:34,860 --> 00:45:36,070
Você vê o que eu quero dizer?

1057
00:45:36,070 --> 00:45:40,910
>> Porque quando eu dividir o espaço,
e eu espalhar esses registros transversalmente,

1058
00:45:40,910 --> 00:45:45,950
e partição eu, eu vou dizer
partição 1 tem espaço chave 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partição 2 é 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partição 3 é AA a FF.

1061
00:45:49,780 --> 00:45:53,740
Então, se eu estou usando linearmente incrementando
IDs, você pode ver o que está acontecendo.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, todos forma-se a 54.

1063
00:45:57,410 --> 00:46:00,030
Então, como eu estou martelando a
registros no sistema,

1064
00:46:00,030 --> 00:46:02,030
tudo acaba indo para um nó.

1065
00:46:02,030 --> 00:46:03,160
>> Isso não é bom.

1066
00:46:03,160 --> 00:46:04,820
Essa é uma antipattern.

1067
00:46:04,820 --> 00:46:08,760
Em MongoDB eles têm esse problema
se você não usar uma chave de hash.

1068
00:46:08,760 --> 00:46:11,325
MongoDB lhe dá a opção
de hash o valor da chave.

1069
00:46:11,325 --> 00:46:13,950
Você deve sempre fazer isso, se
você está usando um hash incrementando

1070
00:46:13,950 --> 00:46:17,380
chave no MongoDB, ou você vai ser
cravando cada gravação para um nó,

1071
00:46:17,380 --> 00:46:21,290
e você vai ser um fator limitante
o seu rendimento escrever mal.

1072
00:46:21,290 --> 00:46:24,896
>> AUDIÊNCIA: É que A9 169 em decimal?

1073
00:46:24,896 --> 00:46:28,450
>> RICK HOULIHAN: Sim, é
algo em torno de lá.

1074
00:46:28,450 --> 00:46:29,950
A9, eu não sei.

1075
00:46:29,950 --> 00:46:32,200
Você teria que pegar minha binário
a calculadora decimal.

1076
00:46:32,200 --> 00:46:34,237
Meu cérebro não funciona assim.

1077
00:46:34,237 --> 00:46:36,320
AUDIÊNCIA: Apenas um rápido
Seus comentários Mongo.

1078
00:46:36,320 --> 00:46:39,530
Assim é a identificação do objeto que vem
nativamente com Mongo fazer isso?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK HOULIHAN: Será que ela faria isso?

1081
00:46:41,470 --> 00:46:42,970
Se você especificá-lo.

1082
00:46:42,970 --> 00:46:45,030
Com MongoDB, você tem a opção.

1083
00:46:45,030 --> 00:46:48,930
Você pode specify-- cada documento
MongoDB tem que ter um ID sublinhado.

1084
00:46:48,930 --> 00:46:50,300
Esse é o valor único.

1085
00:46:50,300 --> 00:46:55,240
>> Em MongoDB você pode especificar
se a hash-lo ou não.

1086
00:46:55,240 --> 00:46:56,490
Eles apenas dar-lhe a opção.

1087
00:46:56,490 --> 00:46:58,198
Se você sabe que é
aleatória, não há problema.

1088
00:46:58,198 --> 00:46:59,640
Você não precisa fazer isso.

1089
00:46:59,640 --> 00:47:04,260
Se você sabe que não é aleatório, que
ele está incrementando, em seguida, fazer o hash.

1090
00:47:04,260 --> 00:47:06,880
>> Agora, a coisa sobre
hashing, uma vez que o hash

1091
00:47:06,880 --> 00:47:08,800
um value-- e esta é
por que chaves de hash são sempre

1092
00:47:08,800 --> 00:47:13,740
consultas únicas, porque eu mudei
o valor, agora eu não posso fazer uma consulta intervalo.

1093
00:47:13,740 --> 00:47:15,640
Eu não posso dizer é isto
entre isso ou aquilo,

1094
00:47:15,640 --> 00:47:20,800
porque o valor de hash não vai
como sendo equivalente ao valor real.

1095
00:47:20,800 --> 00:47:24,570
Então, quando você hash que
chave, é apenas a igualdade.

1096
00:47:24,570 --> 00:47:28,700
É por isso que na chave de hash DynamoDB
consultas são sempre apenas a igualdade.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Então, agora em uma escala key--
quando eu adicionar essa chave gama,

1099
00:47:34,700 --> 00:47:38,180
esses registros principais alcance todos entrar e
eles ficam armazenados na mesma partição.

1100
00:47:38,180 --> 00:47:42,430
Então, eles estão muito rapidamente, facilmente
recuperado porque este é o hash,

1101
00:47:42,430 --> 00:47:43,220
esta é a gama.

1102
00:47:43,220 --> 00:47:44,928
E você vê tudo
com o mesmo hash

1103
00:47:44,928 --> 00:47:48,550
fica armazenado no mesmo espaço de partição.

1104
00:47:48,550 --> 00:47:53,889
Você pode usar essa chave para ajudar a gama
localizar seus dados perto de seu pai.

1105
00:47:53,889 --> 00:47:55,180
Então, o que eu realmente estou fazendo aqui?

1106
00:47:55,180 --> 00:47:57,320
Esta é uma relação um para muitos.

1107
00:47:57,320 --> 00:48:01,490
A relação entre uma chave de hash
ea tecla de intervalo é de um para muitos.

1108
00:48:01,490 --> 00:48:03,490
Eu posso ter várias chaves de hash.

1109
00:48:03,490 --> 00:48:07,610
Eu só pode ter intervalo múltiplo
chaves dentro de cada chave de hash.

1110
00:48:07,610 --> 00:48:11,910
>> O hash define o pai,
o intervalo define as crianças.

1111
00:48:11,910 --> 00:48:15,240
Assim você pode ver que há analógica aqui
entre o construto relacional

1112
00:48:15,240 --> 00:48:18,840
e os mesmos tipos de
constrói em NoSQL.

1113
00:48:18,840 --> 00:48:20,760
As pessoas falam sobre
NoSQL como não-relacional.

1114
00:48:20,760 --> 00:48:22,200
Não é nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Dados sempre tem relações.

1116
00:48:24,680 --> 00:48:28,172
Essas relações apenas
são modeladas de modo diferente.

1117
00:48:28,172 --> 00:48:29,880
Vamos falar um pouco
pouco sobre durabilidade.

1118
00:48:29,880 --> 00:48:34,860
Quando você escreve para DynamoDB, escreve
são sempre três vias replicado.

1119
00:48:34,860 --> 00:48:37,550
O que significa que temos três AZ de.

1120
00:48:37,550 --> 00:48:39,160
AZ são de Zonas de disponibilidade.

1121
00:48:39,160 --> 00:48:43,430
Você pode pensar em um Disponibilidade
Zona como um centro de dados

1122
00:48:43,430 --> 00:48:45,447
ou um conjunto de centros de dados.

1123
00:48:45,447 --> 00:48:47,780
Essas coisas são geograficamente
isolados uns dos outros

1124
00:48:47,780 --> 00:48:51,610
em diferentes zonas de falhas, através
diferentes redes de energia e planícies aluviais.

1125
00:48:51,610 --> 00:48:54,510
Uma falha em um AZ não é
indo para derrubar o outro.

1126
00:48:54,510 --> 00:48:56,890
Eles também estão ligados
juntamente com a fibra escura.

1127
00:48:56,890 --> 00:49:01,240
Ele suporta uma sub 1
latência milissegundo entre AZs.

1128
00:49:01,240 --> 00:49:05,390
Assim repetições de dados em tempo real
capaz em multi AZs.

1129
00:49:05,390 --> 00:49:09,990
>> E implementações muitas vezes multi-AZ
atender aos requisitos de alta disponibilidade

1130
00:49:09,990 --> 00:49:12,930
da maioria das organizações empresariais.

1131
00:49:12,930 --> 00:49:16,139
Então DynamoDB está espalhada
em três AZs por padrão.

1132
00:49:16,139 --> 00:49:19,430
Nós estamos indo apenas para o conhecimento da escrita
quando dois desses três nós voltar

1133
00:49:19,430 --> 00:49:21,470
e dizer: Sim, eu tenho.

1134
00:49:21,470 --> 00:49:22,050
Por que é que?

1135
00:49:22,050 --> 00:49:25,950
Porque no lado da leitura estamos apenas
vai dar-lhe os dados de volta quando

1136
00:49:25,950 --> 00:49:27,570
nós obtê-lo de dois nós.

1137
00:49:27,570 --> 00:49:30,490
>> Se eu estou replicar em toda
três, e eu estou lendo a partir de dois,

1138
00:49:30,490 --> 00:49:32,840
Eu estou sempre garantida
ter pelo menos um

1139
00:49:32,840 --> 00:49:35,720
daqueles lê-se o
mais de cópia atual dos dados.

1140
00:49:35,720 --> 00:49:38,340
É isso que faz DynamoDB consistente.

1141
00:49:38,340 --> 00:49:42,450
Agora você pode optar por ativar
as leituras consistentes fora.

1142
00:49:42,450 --> 00:49:45,070
Caso em que eu vou dizer,
Eu só vou ler de um nó.

1143
00:49:45,070 --> 00:49:47,430
E eu não posso garantir que vai
a ser os dados mais atuais.

1144
00:49:47,430 --> 00:49:49,450
>> Assim, se uma gravação está chegando,
que ainda não foi duplicado,

1145
00:49:49,450 --> 00:49:50,360
você está indo para obter essa cópia.

1146
00:49:50,360 --> 00:49:52,220
Essa é uma leitura eventualmente consistente.

1147
00:49:52,220 --> 00:49:54,640
E o que é que é metade do custo.

1148
00:49:54,640 --> 00:49:56,140
Então, isso é algo para se pensar.

1149
00:49:56,140 --> 00:50:00,160
Quando você está lendo fora DynamoDB, e
você estiver configurando sua capacidade de leitura

1150
00:50:00,160 --> 00:50:04,430
unidades, se você escolher, eventualmente,
leituras consistentes, é muito mais barato,

1151
00:50:04,430 --> 00:50:06,010
é cerca de metade do custo.

1152
00:50:06,010 --> 00:50:09,342
>> E assim você economiza dinheiro.

1153
00:50:09,342 --> 00:50:10,300
Mas essa é a sua escolha.

1154
00:50:10,300 --> 00:50:12,925
Se você quiser uma leitura consistente ou
uma leitura eventualmente consistente.

1155
00:50:12,925 --> 00:50:15,720
Isso é algo que você pode escolher.

1156
00:50:15,720 --> 00:50:17,659
>> Vamos falar sobre índices.

1157
00:50:17,659 --> 00:50:19,450
Então, nós mencionamos que
agregação de nível superior.

1158
00:50:19,450 --> 00:50:23,720
Temos chaves de hash, e
temos chaves alcance.

1159
00:50:23,720 --> 00:50:24,320
Isso é bom.

1160
00:50:24,320 --> 00:50:26,950
E isso é sobre a mesa principal, I
tem uma chave de hash, eu tenho uma chave intervalo.

1161
00:50:26,950 --> 00:50:27,783
>> O que isso significa?

1162
00:50:27,783 --> 00:50:30,410
Eu tenho um atributo que eu
pode executar consultas contra ricos.

1163
00:50:30,410 --> 00:50:31,800
É a chave intervalo.

1164
00:50:31,800 --> 00:50:35,530
Os outros atributos em que item--
Eu posso filtrar esses atributos.

1165
00:50:35,530 --> 00:50:40,050
Mas eu não posso fazer coisas como, ele
inicia-se com, ou é maior do que.

1166
00:50:40,050 --> 00:50:40,820
>> Como eu faço isso?

1167
00:50:40,820 --> 00:50:42,860
Eu criar um índice.

1168
00:50:42,860 --> 00:50:45,340
Há dois tipos de
índices em DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Um índice é realmente
outra visão da tabela.

1170
00:50:49,002 --> 00:50:50,490
E o índice secundário local.

1171
00:50:50,490 --> 00:50:51,781
>> O primeiro vamos falar sobre.

1172
00:50:51,781 --> 00:50:57,740
Então secundários locais são coexistiram
na mesma partição como os dados.

1173
00:50:57,740 --> 00:51:00,240
E como tal, eles são sobre
o mesmo nó físico.

1174
00:51:00,240 --> 00:51:01,780
Eles são o que chamamos consistente.

1175
00:51:01,780 --> 00:51:04,599
Significado, eles vão reconhecer
a gravação, juntamente com a mesa.

1176
00:51:04,599 --> 00:51:06,890
Quando a gravação entra,
vamos escrever através do índice.

1177
00:51:06,890 --> 00:51:09,306
Vamos escrever-se para a mesa,
e depois vamos reconhecer.

1178
00:51:09,306 --> 00:51:10,490
Então, isso é consistente.

1179
00:51:10,490 --> 00:51:13,174
Uma vez que a escrita foi
reconhecido a partir da tabela,

1180
00:51:13,174 --> 00:51:15,090
é garantido que o
Índice secundária local

1181
00:51:15,090 --> 00:51:18,380
terá a mesma visão dos dados.

1182
00:51:18,380 --> 00:51:22,390
Mas o que eles permitem que você faz é
definir chaves Faixa suplentes.

1183
00:51:22,390 --> 00:51:25,260
>> Tem que usar o mesmo hash
chave como a tabela primária,

1184
00:51:25,260 --> 00:51:29,050
porque eles são co-localizado na
mesma partição, e eles são consistentes.

1185
00:51:29,050 --> 00:51:33,110
Mas eu posso criar um índice
com diferentes chaves de alcance.

1186
00:51:33,110 --> 00:51:41,590
Assim, por exemplo, se eu tivesse um fabricante
que tinha uma tabela de peças em bruto chegando.

1187
00:51:41,590 --> 00:51:44,590
E peças brutas entrar, e
eles estão agregados por montagem.

1188
00:51:44,590 --> 00:51:46,840
E talvez haja um recall.

1189
00:51:46,840 --> 00:51:50,240
>> Qualquer parte que foi feito por este
fabricante após esta data,

1190
00:51:50,240 --> 00:51:52,840
Eu preciso puxar da minha linha.

1191
00:51:52,840 --> 00:51:55,950
Eu posso girar um índice
que estaria olhando,

1192
00:51:55,950 --> 00:52:00,760
agregação na data de
Fabricação de que parte particular.

1193
00:52:00,760 --> 00:52:03,930
Então, se minha mesa nível superior era
já hash pelo fabricante,

1194
00:52:03,930 --> 00:52:07,655
talvez ele foi organizado em parte ID, I
pode criar um índice que a tabela off

1195
00:52:07,655 --> 00:52:11,140
como hash pelo fabricante e
variaram em data de fabricação.

1196
00:52:11,140 --> 00:52:14,490
E de que maneira eu poderia dizer, qualquer coisa que
foi fabricado entre essas datas,

1197
00:52:14,490 --> 00:52:16,804
Eu preciso puxar a partir da linha.

1198
00:52:16,804 --> 00:52:18,220
Então, isso é um índice secundário local.

1199
00:52:18,220 --> 00:52:22,280
>> Estes têm o efeito de
limitar o seu espaço de chave hash.

1200
00:52:22,280 --> 00:52:24,360
Porque eles coexistiram
no mesmo nó de armazenamento,

1201
00:52:24,360 --> 00:52:26,860
eles limitam a chave de hash
espaço de 10 gigabytes.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, sob a
tabelas, particionará

1203
00:52:28,950 --> 00:52:31,380
sua mesa a cada 10 gigabytes.

1204
00:52:31,380 --> 00:52:34,760
Quando você colocar 10 GB de dados, nós
ir [PHH], e nós adicionamos outro nó.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Nós não vamos dividir o LSI
através de múltiplas partições.

1207
00:52:42,070 --> 00:52:43,200
Vamos dividir a tabela.

1208
00:52:43,200 --> 00:52:44,679
Mas não vamos dividir o LSI.

1209
00:52:44,679 --> 00:52:46,470
Então, isso é algo
importante compreender

1210
00:52:46,470 --> 00:52:50,070
é se você está fazendo muito,
muito, muito grandes agregações,

1211
00:52:50,070 --> 00:52:53,860
então você vai ser limitado
10 gigabytes em seu LSIs.

1212
00:52:53,860 --> 00:52:56,640
>> Se for esse o caso, nós podemos
usar secundários globais.

1213
00:52:56,640 --> 00:52:58,630
Secundários globais são
realmente outra mesa.

1214
00:52:58,630 --> 00:53:01,720
Eles existem completamente fora de
o lado de sua tabela primária.

1215
00:53:01,720 --> 00:53:04,680
E eles me permita encontrar uma
estrutura completamente diferente.

1216
00:53:04,680 --> 00:53:08,010
Então, pense nisso como os dados estão sendo inseridas
em duas tabelas diferentes, estruturado

1217
00:53:08,010 --> 00:53:09,220
de duas maneiras diferentes.

1218
00:53:09,220 --> 00:53:11,360
>> Posso definir um totalmente
diferente chave de hash.

1219
00:53:11,360 --> 00:53:13,490
Posso definir um totalmente
diferente chave de gama.

1220
00:53:13,490 --> 00:53:15,941
E eu posso executar este
de forma totalmente independente.

1221
00:53:15,941 --> 00:53:18,190
Por uma questão de fato, eu tenho
provisionados minha capacidade de leitura

1222
00:53:18,190 --> 00:53:21,090
e capacidade para escrever meu
índices secundários globais

1223
00:53:21,090 --> 00:53:24,240
de forma totalmente independente
da minha tabela primária.

1224
00:53:24,240 --> 00:53:26,640
Se eu definir esse índice, digo-
ele o quanto ler e escrever

1225
00:53:26,640 --> 00:53:28,610
capacidade que ela vai estar usando.

1226
00:53:28,610 --> 00:53:31,490
>> E que é separado
da minha mesa principal.

1227
00:53:31,490 --> 00:53:35,240
Agora, tanto dos índices nos permitir
não só definem chaves de hash e alcance,

1228
00:53:35,240 --> 00:53:38,610
mas eles nos permitem
projetar valores adicionais.

1229
00:53:38,610 --> 00:53:44,950
Então, se eu quero ler fora do índice,
e eu quero obter um conjunto de dados,

1230
00:53:44,950 --> 00:53:48,327
Eu não preciso de voltar para o principal
mesa para obter os atributos adicionais.

1231
00:53:48,327 --> 00:53:50,660
Eu posso projetar os adicional
atributos na tabela

1232
00:53:50,660 --> 00:53:53,440
para suportar o padrão de acesso.

1233
00:53:53,440 --> 00:53:57,700
Eu sei que provavelmente está se metendo alguns
realmente, realmente-- metendo as ervas daninhas

1234
00:53:57,700 --> 00:53:58,910
aqui em algumas dessas coisas.

1235
00:53:58,910 --> 00:54:02,725
Agora eu tenho a deriva fora deste.

1236
00:54:02,725 --> 00:54:07,320
>> AUDIÊNCIA: [inaudível]
chave --table quis dizer foi um hash?

1237
00:54:07,320 --> 00:54:08,840
O hash original?

1238
00:54:08,840 --> 00:54:09,340
Multi-slats?

1239
00:54:09,340 --> 00:54:10,200
>> RICK HOULIHAN: Sim.

1240
00:54:10,200 --> 00:54:11,070
Sim.

1241
00:54:11,070 --> 00:54:15,260
A chave tabela, basicamente,
aponta para o item.

1242
00:54:15,260 --> 00:54:19,280
Assim, um índice é um ponteiro de volta para
os itens originais na mesa.

1243
00:54:19,280 --> 00:54:22,910
Agora você pode optar por construir um
índice que só tem a chave da tabela,

1244
00:54:22,910 --> 00:54:24,840
e há outras propriedades.

1245
00:54:24,840 --> 00:54:26,570
E por que eu poderia fazer isso?

1246
00:54:26,570 --> 00:54:28,570
Bem, talvez eu tenha muito grandes itens.

1247
00:54:28,570 --> 00:54:31,660
>> Eu realmente só precisa saber which--
meu padrão de acesso pode dizer,

1248
00:54:31,660 --> 00:54:33,760
os itens que contêm essa propriedade?

1249
00:54:33,760 --> 00:54:35,780
Não precisa devolver o item.

1250
00:54:35,780 --> 00:54:37,800
Eu só preciso saber
os itens que contê-lo.

1251
00:54:37,800 --> 00:54:40,700
Assim, você pode criar índices
que só tem a chave da tabela.

1252
00:54:40,700 --> 00:54:43,360
>> Mas isso é principalmente o que
um índice no banco de dados é para.

1253
00:54:43,360 --> 00:54:46,280
É para ser capaz de rapidamente
identificar quais registros,

1254
00:54:46,280 --> 00:54:49,470
quais linhas, que
itens na tabela tem

1255
00:54:49,470 --> 00:54:51,080
as propriedades que eu estou procurando.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, então como eles funcionam?

1258
00:54:54,860 --> 00:54:58,340
GSIS basicamente são assíncronas.

1259
00:54:58,340 --> 00:55:02,570
A atualização vem para a mesa,
tabela é atualizada em seguida, de forma assíncrona

1260
00:55:02,570 --> 00:55:03,720
todo o seu GSIS.

1261
00:55:03,720 --> 00:55:06,680
É por isso que são GSIS
eventualmente, consistente.

1262
00:55:06,680 --> 00:55:09,440
>> É importante notar que,
quando você está construindo GSIS,

1263
00:55:09,440 --> 00:55:13,110
e você entender que você está criando
outra dimensão da aggregation--

1264
00:55:13,110 --> 00:55:16,594
Agora, vamos dizer que um bom exemplo
aqui é um fabricante.

1265
00:55:16,594 --> 00:55:19,260
Eu acho que eu poderia ter falado sobre
um fabricante de dispositivos médicos.

1266
00:55:19,260 --> 00:55:23,870
Fabricantes de dispositivos médicos
muitas vezes têm partes serializados.

1267
00:55:23,870 --> 00:55:28,070
As peças que entram em
uma substituição da anca tudo

1268
00:55:28,070 --> 00:55:30,200
ter um pouco de número de série neles.

1269
00:55:30,200 --> 00:55:33,584
E eles poderiam ter milhões e
milhões e bilhões de peças

1270
00:55:33,584 --> 00:55:35,000
em todos os dispositivos que elas trazem.

1271
00:55:35,000 --> 00:55:37,440
Bem, eles precisam agregar sob
diferentes dimensões, todas as peças

1272
00:55:37,440 --> 00:55:39,520
em uma montagem, todo o
partes que foram feitas

1273
00:55:39,520 --> 00:55:41,670
em uma determinada linha, todos
as peças que vieram

1274
00:55:41,670 --> 00:55:44,620
a partir de um determinado fabricante
em uma determinada data.

1275
00:55:44,620 --> 00:55:47,940
E, por vezes, estas agregações
levantar-se em casa dos bilhões.

1276
00:55:47,940 --> 00:55:50,550
>> Então, eu trabalho com alguns dos
esses caras que estão sofrendo

1277
00:55:50,550 --> 00:55:53,156
porque eles estão criando
estas agregações ginormous

1278
00:55:53,156 --> 00:55:54,280
em seus índices secundários.

1279
00:55:54,280 --> 00:55:57,070
Eles podem ter uma peças de matérias-
tabela que vem como única de hash.

1280
00:55:57,070 --> 00:55:59,090
Cada parte tem um número de série único.

1281
00:55:59,090 --> 00:56:00,975
Eu uso o número de série como o hash.

1282
00:56:00,975 --> 00:56:01,600
É lindo.

1283
00:56:01,600 --> 00:56:04,160
Minha tabela de dados brutos é espalhada
em todo o espaço da chave.

1284
00:56:04,160 --> 00:56:05,930
Minhas [? Escreva ?]
[? ingestão?] é incrível.

1285
00:56:05,930 --> 00:56:07,876
Eu tomo um monte de dados.

1286
00:56:07,876 --> 00:56:09,500
Então o que eles fazem é criar um GSI.

1287
00:56:09,500 --> 00:56:12,666
E eu digo, você sabe o quê, eu preciso ver
todas as partes para este fabricante.

1288
00:56:12,666 --> 00:56:15,060
Bem, de repente eu sou
tendo um bilhão de linhas,

1289
00:56:15,060 --> 00:56:17,550
e enchê-los para
um nó, porque quando

1290
00:56:17,550 --> 00:56:21,170
I agregar como o
ID fabricante como o hash,

1291
00:56:21,170 --> 00:56:25,410
e número da peça como o intervalo,
em seguida, de repente eu sou

1292
00:56:25,410 --> 00:56:30,530
colocar um bilhão de partes em que
este fabricante tem me entregue.

1293
00:56:30,530 --> 00:56:34,447
>> Isso pode causar uma série
de pressão sobre o GSI,

1294
00:56:34,447 --> 00:56:36,030
novamente, porque estou martelando um nó.

1295
00:56:36,030 --> 00:56:38,350
Estou colocando todos estes
insere um nó.

1296
00:56:38,350 --> 00:56:40,940
E isso é um caso de uso problemático real.

1297
00:56:40,940 --> 00:56:43,479
Agora, eu tenho um bom design
padrão de como você evitar isso.

1298
00:56:43,479 --> 00:56:45,770
E isso é um dos problemas
que eu sempre trabalhar.

1299
00:56:45,770 --> 00:56:49,590
Mas o que acontece, é a GSI pode
não tem capacidade de gravação suficiente

1300
00:56:49,590 --> 00:56:52,330
para ser capaz de empurrar todos aqueles
linhas em um único nó.

1301
00:56:52,330 --> 00:56:55,390
E o que acontece em seguida é a
primário, a tabela de cliente,

1302
00:56:55,390 --> 00:57:00,180
tabela primária será estrangulada
porque o GSI não pode manter-se.

1303
00:57:00,180 --> 00:57:02,980
Assim, a minha taxa de inserção vai
cair sobre a mesa principal

1304
00:57:02,980 --> 00:57:06,230
como meu GSI tenta manter-se.

1305
00:57:06,230 --> 00:57:08,850
>> Tudo bem, então GSI de, LSI de,
qual deles devo usar?

1306
00:57:08,850 --> 00:57:12,290
LSI de são consistentes.

1307
00:57:12,290 --> 00:57:13,750
GSI de, eventualmente, são consistentes.

1308
00:57:13,750 --> 00:57:17,490
Se isso é OK, eu recomendo usar um
GSI, eles são muito mais flexíveis.

1309
00:57:17,490 --> 00:57:20,270
LSI de pode ser modelado como um GSI.

1310
00:57:20,270 --> 00:57:27,040
E se o tamanho dos dados por chaves hash em
sua coleção seja superior a 10 gigabytes,

1311
00:57:27,040 --> 00:57:31,050
então você vai querer usar isso
GSI porque é apenas um limite rígido.

1312
00:57:31,050 --> 00:57:32,035
>> Tudo bem, então escala.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Rendimento no Dynamo DB, você
prestação lata [inaudível]

1315
00:57:37,460 --> 00:57:38,680
throughput para uma mesa.

1316
00:57:38,680 --> 00:57:42,740
Temos clientes que têm
provisionado 60 billion--

1317
00:57:42,740 --> 00:57:45,970
está fazendo 60 bilhões de pedidos, regularmente
rodando a mais de um milhão pedidos

1318
00:57:45,970 --> 00:57:47,790
por segundo em nossas mesas.

1319
00:57:47,790 --> 00:57:50,360
Não há realmente nenhuma
limite teórico de quanto

1320
00:57:50,360 --> 00:57:53,730
e quão rápido a mesa
pode ser executado no Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Há alguns suave
limites na sua conta

1322
00:57:55,920 --> 00:57:58,170
que nós colocamos lá, então
que você não enlouquecer.

1323
00:57:58,170 --> 00:58:00,070
Se você quer mais do que
que, não um problema.

1324
00:58:00,070 --> 00:58:00,820
Você vem dizer-nos.

1325
00:58:00,820 --> 00:58:02,810
Vamos transformar-se no mostrador.

1326
00:58:02,810 --> 00:58:08,210
>> Cada conta é limitado a um certo nível
em todos os serviços, apenas fora do bastão

1327
00:58:08,210 --> 00:58:11,920
para que as pessoas não enlouquecer
se metem em problemas.

1328
00:58:11,920 --> 00:58:12,840
Não há limite de tamanho.

1329
00:58:12,840 --> 00:58:14,940
Você pode colocar qualquer número
de itens em uma tabela.

1330
00:58:14,940 --> 00:58:17,620
O tamanho de um item é
limitada a 400 quilobytes cada,

1331
00:58:17,620 --> 00:58:20,050
que seria item não os atributos.

1332
00:58:20,050 --> 00:58:24,200
Assim, a soma de todos os atributos
está limitado a 400 kilobytes.

1333
00:58:24,200 --> 00:58:27,300
E então, novamente, temos
esse pequeno problema LSI

1334
00:58:27,300 --> 00:58:30,405
com o limite de 10 gigabyte por hash.

1335
00:58:30,405 --> 00:58:33,280
AUDIÊNCIA: número pequeno, eu estou faltando
o que você está me dizendo, que é--

1336
00:58:33,280 --> 00:58:36,830
AUDIÊNCIA: Oh, 400 kilobytes
é o tamanho máximo por item.

1337
00:58:36,830 --> 00:58:39,570
Assim, um item tem todos os atributos.

1338
00:58:39,570 --> 00:58:43,950
Então, 400 K é o tamanho total
desse item, 400 kilobytes.

1339
00:58:43,950 --> 00:58:46,170
Assim, de todos os atributos
combinados, todos os dados

1340
00:58:46,170 --> 00:58:49,140
que está em todos esses atributos,
enrolado em um tamanho total,

1341
00:58:49,140 --> 00:58:51,140
Atualmente o limite de itens hoje é de 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Assim dimensionamento novamente, conseguida
através de particionamento.

1344
00:58:57,046 --> 00:58:58,920
O throughput é provisionado
no nível da tabela.

1345
00:58:58,920 --> 00:59:00,160
E não há realmente dois botões.

1346
00:59:00,160 --> 00:59:02,400
Temos capacidade de leitura
e escrever capacidade.

1347
00:59:02,400 --> 00:59:05,530
>> Então, essas são ajustados
independentemente um do outro.

1348
00:59:05,530 --> 00:59:08,640
Medida do estritamente RCU leituras consistentes.

1349
00:59:08,640 --> 00:59:13,005
OK, então se você está dizendo que eu quero 1000
RCU de esses são estritamente consistente,

1350
00:59:13,005 --> 00:59:14,130
estas são as leituras consistentes.

1351
00:59:14,130 --> 00:59:17,130
Se você disser que eu quero
eventual leituras consistentes,

1352
00:59:17,130 --> 00:59:19,402
você pode provisionar 1000
RCU do, você vai

1353
00:59:19,402 --> 00:59:21,840
para obter, eventualmente, 2000
leituras consistentes.

1354
00:59:21,840 --> 00:59:25,940
E metade do preço para aqueles
eventualmente, consistem em lê.

1355
00:59:25,940 --> 00:59:28,520
>> Mais uma vez, ajustada
independentemente um do outro.

1356
00:59:28,520 --> 00:59:32,900
E eles têm o throughput--
Se você consumir 100% do seu RCU,

1357
00:59:32,900 --> 00:59:35,960
você não vai ter impacto no
disponibilidade de seus direitos.

1358
00:59:35,960 --> 00:59:40,161
Então, eles estão completamente
independentes uns dos outros.

1359
00:59:40,161 --> 00:59:43,160
Tudo bem, então uma das coisas que
Mencionei brevemente foi estrangulamento.

1360
00:59:43,160 --> 00:59:44,320
Estrangulamento é ruim.

1361
00:59:44,320 --> 00:59:47,311
Estrangulamento indica mau não SQL.

1362
00:59:47,311 --> 00:59:50,310
Há coisas que podemos fazer para ajudá-
você aliviar o estrangulamento que você

1363
00:59:50,310 --> 00:59:51,040
está enfrentando.

1364
00:59:51,040 --> 00:59:53,240
Mas a melhor solução
para isso é, vamos dar

1365
00:59:53,240 --> 00:59:58,000
um olhar para o que você está fazendo, porque
há um anti-padrão em jogo aqui.

1366
00:59:58,000 --> 01:00:02,140
>> Essas coisas, coisas como não-uniforme
cargas de trabalho, teclas de atalho, divisórias quentes.

1367
01:00:02,140 --> 01:00:06,210
Eu estou batendo um espaço de chave em particular
muito difícil por algum motivo particular.

1368
01:00:06,210 --> 01:00:07,080
Por que estou fazendo isso?

1369
01:00:07,080 --> 01:00:08,710
Vamos descobrir isso.

1370
01:00:08,710 --> 01:00:10,427
Eu estou misturando meus dados quentes com dados frios.

1371
01:00:10,427 --> 01:00:12,510
Eu estou deixando minhas tabelas chegar
enorme, mas não há realmente

1372
01:00:12,510 --> 01:00:15,970
apenas algumas subconjunto dos dados
que é realmente interessante para mim.

1373
01:00:15,970 --> 01:00:20,290
Assim, para os dados de log, por exemplo, uma grande quantidade de
clientes, que recebem os dados de registro a cada dia.

1374
01:00:20,290 --> 01:00:22,490
Eles têm uma enorme quantidade de dados de registro.

1375
01:00:22,490 --> 01:00:25,940
>> Se você está apenas despejar tudo o que log
dados em uma grande mesa, ao longo do tempo

1376
01:00:25,940 --> 01:00:28,070
que a tabela vai ficar enorme.

1377
01:00:28,070 --> 01:00:30,950
Mas eu estou realmente interessado apenas em
últimas 24 horas, nos últimos sete dias,

1378
01:00:30,950 --> 01:00:31,659
nos últimos 30 dias.

1379
01:00:31,659 --> 01:00:34,074
Seja qual for a janela de tempo
que eu estou interessado em olhar

1380
01:00:34,074 --> 01:00:37,010
para o evento que me incomoda, ou
o evento que é interessante para mim,

1381
01:00:37,010 --> 01:00:39,540
essa é a única vez que a janela que eu preciso.

1382
01:00:39,540 --> 01:00:42,470
Então por que estou colocando 10 anos
vale de dados de registro na tabela?

1383
01:00:42,470 --> 01:00:45,030
O que faz com que é
a tabela de fragmento.

1384
01:00:45,030 --> 01:00:45,880
>> Ele fica enorme.

1385
01:00:45,880 --> 01:00:48,340
Ele começa a se espalhar para fora
através de milhares de nós.

1386
01:00:48,340 --> 01:00:51,380
E uma vez que a sua capacidade
é tão baixo, você é

1387
01:00:51,380 --> 01:00:54,090
na verdade, em cada taxa de limitar
um desses nodos individuais.

1388
01:00:54,090 --> 01:00:57,120
Então, vamos começar olhando como
nós rolar aquela mesa.

1389
01:00:57,120 --> 01:01:01,502
Como podemos gerenciar esses dados um pouco
melhor evitar estes problemas.

1390
01:01:01,502 --> 01:01:02,710
E o que isso parece?

1391
01:01:02,710 --> 01:01:04,370
Isto é o que parece.

1392
01:01:04,370 --> 01:01:06,790
Isto é o que mau NoSQL parece.

1393
01:01:06,790 --> 01:01:07,830
>> Eu tenho uma tecla de atalho aqui.

1394
01:01:07,830 --> 01:01:10,246
Se você olhar para o lado aqui,
estas são todas as minhas partições.

1395
01:01:10,246 --> 01:01:12,630
Eu tenho 16 partições-se aqui
nesse banco de dados particular.

1396
01:01:12,630 --> 01:01:13,630
Fazemos isso o tempo todo.

1397
01:01:13,630 --> 01:01:15,046
Eu corro isto para clientes todos os tempos.

1398
01:01:15,046 --> 01:01:16,550
É o chamado mapa de calor.

1399
01:01:16,550 --> 01:01:20,590
Mapa de calor me diz como você é
acessando seu espaço chave.

1400
01:01:20,590 --> 01:01:23,700
E o que isso está me dizendo é
que há um hash de especial

1401
01:01:23,700 --> 01:01:26,330
que esse cara gosta de uma
lote terrível, porque ele é

1402
01:01:26,330 --> 01:01:28,250
batê-lo muito, muito difícil.

1403
01:01:28,250 --> 01:01:29,260
>> Assim, o azul é bom.

1404
01:01:29,260 --> 01:01:29,900
Nós gostamos azul.

1405
01:01:29,900 --> 01:01:30,720
Nós não gostamos de vermelho.

1406
01:01:30,720 --> 01:01:33,120
Onde a pressão da Red
levanta-se a 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, agora você vai ser estrangulado.

1408
01:01:35,560 --> 01:01:39,030
Assim, sempre que você ver todas as linhas vermelhas, como
isto-- e não é apenas Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
cada banco de dados NoSQL tem este problema.

1410
01:01:41,630 --> 01:01:44,640
Há anti-padrões que podem
conduzir estes tipos de condições.

1411
01:01:44,640 --> 01:01:49,070
O que eu faço é trabalhar com os clientes
para aliviar essas condições.

1412
01:01:49,070 --> 01:01:51,840
>> E o que isso parece?

1413
01:01:51,840 --> 01:01:54,260
E isso está ficando mais
Fora do Dynamo DB rendimento,

1414
01:01:54,260 --> 01:01:56,176
mas é realmente ficando
o máximo de NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Este não é restrita a dínamo.

1416
01:01:58,740 --> 01:02:02,050
Este é definitely-- I
costumava trabalhar no Mongo.

1417
01:02:02,050 --> 01:02:04,090
Eu estou familiarizado com muitas plataformas NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Cada um tem esses tipos
de problemas de teclas de atalho.

1419
01:02:06,830 --> 01:02:10,320
Para tirar o máximo proveito de qualquer NoSQL
banco de dados, especificamente Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
você deseja criar as tabelas
onde o elemento chave de hash tem

1421
01:02:13,320 --> 01:02:18,590
um grande número de valores distintos,
um elevado grau de cardinalidade.

1422
01:02:18,590 --> 01:02:22,530
Porque isso significa que eu estou escrevendo
para os lotes de diferentes baldes.

1423
01:02:22,530 --> 01:02:24,870
>> Os mais baldes que eu sou
escrever para, o mais provável

1424
01:02:24,870 --> 01:02:29,100
Eu sou a espalhar a carga de gravação ou
leia carregar para fora através de vários nós,

1425
01:02:29,100 --> 01:02:33,560
o mais provável que eu estou a ter um
alto rendimento sobre a mesa.

1426
01:02:33,560 --> 01:02:37,440
E então eu quero que os valores a serem
solicitadas de forma bastante equilibrada ao longo do tempo

1427
01:02:37,440 --> 01:02:39,430
e uniforme quanto possível de forma aleatória.

1428
01:02:39,430 --> 01:02:42,410
Bem, isso é bem interessante,
porque eu não posso realmente

1429
01:02:42,410 --> 01:02:43,960
controle quando os usuários vêm.

1430
01:02:43,960 --> 01:02:47,645
Então, basta dizer que, se espalhar
coisas para fora em todo o espaço da chave,

1431
01:02:47,645 --> 01:02:49,270
provavelmente vamos estar em melhor forma.

1432
01:02:49,270 --> 01:02:51,522
>> Há um certo
quantidade de tempo de entrega

1433
01:02:51,522 --> 01:02:53,230
que você não vai
para ser capaz de controle.

1434
01:02:53,230 --> 01:02:55,438
Mas esses são realmente o
duas dimensões que temos,

1435
01:02:55,438 --> 01:02:58,800
espaço, o acesso uniformemente
propagação, tempo, pedidos

1436
01:02:58,800 --> 01:03:01,040
que chegam uniformemente espaçados no tempo.

1437
01:03:01,040 --> 01:03:03,110
E se aqueles dois
condições estão a ser cumpridas,

1438
01:03:03,110 --> 01:03:05,610
em seguida, que é o que é
vai parecer.

1439
01:03:05,610 --> 01:03:07,890
Este é muito mais agradável.

1440
01:03:07,890 --> 01:03:08,890
Estamos muito felizes aqui.

1441
01:03:08,890 --> 01:03:10,432
Temos um padrão de acesso muito mesmo.

1442
01:03:10,432 --> 01:03:13,098
Sim, talvez você está recebendo um
pouca pressão de vez em quando,

1443
01:03:13,098 --> 01:03:14,830
mas nada realmente muito extensa.

1444
01:03:14,830 --> 01:03:17,660
Por isso, é incrível como muitas vezes,
quando eu trabalho com os clientes,

1445
01:03:17,660 --> 01:03:20,670
que primeiro gráfico com o vermelho grande
bar e tudo o que feio amarelo é

1446
01:03:20,670 --> 01:03:23,147
em todo o lugar, nós
ter feito com o exercício

1447
01:03:23,147 --> 01:03:24,980
depois de um par de meses
de re-arquitetura,

1448
01:03:24,980 --> 01:03:28,050
eles estão executando exatamente o mesmo
carga de trabalho com a mesma carga exata.

1449
01:03:28,050 --> 01:03:30,140
E isso é o que está parecendo agora.

1450
01:03:30,140 --> 01:03:36,600
Então, o que você ganha com NoSQL é um
esquema de dados que é absolutamente

1451
01:03:36,600 --> 01:03:38,510
amarrado ao padrão de acesso.

1452
01:03:38,510 --> 01:03:42,170
>> E você pode otimizar o esquema de dados
para suportar esse padrão de acesso.

1453
01:03:42,170 --> 01:03:45,490
Se você não fizer isso, então você está indo
para ver esses tipos de problemas

1454
01:03:45,490 --> 01:03:46,710
com essas teclas de atalho.

1455
01:03:46,710 --> 01:03:50,518
>> AUDIÊNCIA: Bem, inevitavelmente, alguns lugares
vai ser mais quente do que outros.

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
Sim, quero dizer, há sempre
um-- e, novamente, há

1459
01:03:54,620 --> 01:03:56,980
alguns padrões de design nós vamos passar por
que vai falar sobre como você lida

1460
01:03:56,980 --> 01:03:58,480
com estas super-grandes agregações.

1461
01:03:58,480 --> 01:04:01,260
Quer dizer, eu tenho que tê-los,
como vamos lidar com eles?

1462
01:04:01,260 --> 01:04:03,760
I got um bom caso de uso
que nós vamos falar sobre por que.

1463
01:04:03,760 --> 01:04:05,940
>> Tudo bem, então vamos falar
sobre alguns clientes agora.

1464
01:04:05,940 --> 01:04:06,950
Esses caras são AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Eu não sei se você é
familiarizados com AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Você provavelmente vê-los
muito no browser.

1467
01:04:10,781 --> 01:04:14,230
Eles são re-segmentação de anúncios, eles são
o maior negócio ad re-segmentação

1468
01:04:14,230 --> 01:04:14,940
lá fora.

1469
01:04:14,940 --> 01:04:17,792
Eles normalmente executado regularmente durante
60 bilhões de transações por dia.

1470
01:04:17,792 --> 01:04:20,000
Eles estão fazendo mais de um milhão
transações por segundo.

1471
01:04:20,000 --> 01:04:22,660
Eles tem uma tabela muito simples
estrutura, a tabela mais movimentado.

1472
01:04:22,660 --> 01:04:26,450
É basicamente apenas um
chave hash é o cookie,

1473
01:04:26,450 --> 01:04:29,010
o intervalo é o grupo demográfico
categoria, e em seguida,

1474
01:04:29,010 --> 01:04:31,220
o terceiro atributo é a pontuação.

1475
01:04:31,220 --> 01:04:33,720
>> Portanto, todos nós temos biscoitos em
nosso navegador a partir desses eles.

1476
01:04:33,720 --> 01:04:35,900
E quando você vai a um
comerciante participante,

1477
01:04:35,900 --> 01:04:39,390
eles basicamente marcar você em frente
várias categorias demográficas.

1478
01:04:39,390 --> 01:04:42,070
Quando você vai para um site e
você diz que eu quero ver isso AD--

1479
01:04:42,070 --> 01:04:44,920
ou, basicamente, você não diz que--
mas quando você vai para o site

1480
01:04:44,920 --> 01:04:47,550
eles dizem que você quer ver este anúncio.

1481
01:04:47,550 --> 01:04:49,370
E eles vão obter esse anúncio de AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll te olha de cima em sua mesa.

1483
01:04:51,130 --> 01:04:52,115
Eles encontrar o seu cookie.

1484
01:04:52,115 --> 01:04:53,990
Os anunciantes dizem
eles, eu quero alguém

1485
01:04:53,990 --> 01:04:58,632
que é de meia-idade,
Homem de 40 anos de idade, em esportes.

1486
01:04:58,632 --> 01:05:01,590
E eles marcarem você nesses dados demográficos
e eles decidir se quer ou não

1487
01:05:01,590 --> 01:05:02,740
isso é um bom anúncio para você.

1488
01:05:02,740 --> 01:05:10,330
>> Agora eles têm um SLA com
seus provedores de publicidade

1489
01:05:10,330 --> 01:05:14,510
para proporcionar sub-10 milissegundo
resposta a cada requisição.

1490
01:05:14,510 --> 01:05:16,090
Então, eles estão usando Dynamo DB para isso.

1491
01:05:16,090 --> 01:05:18,131
Eles estão nos a bater
milhão de pedidos por segundo.

1492
01:05:18,131 --> 01:05:21,120
Eles são capazes de fazer toda a sua
pesquisas, triagem todos os dados,

1493
01:05:21,120 --> 01:05:26,130
e obter esse link adicionar de volta para que
anunciante em menos de 10 milissegundos.

1494
01:05:26,130 --> 01:05:29,800
É realmente fenomenal
aplicação que eles têm.

1495
01:05:29,800 --> 01:05:36,210
>> Esses caras actually--
são estes os caras.

1496
01:05:36,210 --> 01:05:38,010
Eu não tenho certeza se é esses caras.

1497
01:05:38,010 --> 01:05:40,127
Pode ser esses caras.

1498
01:05:40,127 --> 01:05:42,210
Basicamente disse US-- não, eu
não acho que foram eles.

1499
01:05:42,210 --> 01:05:43,000
Acho que foi outra pessoa.

1500
01:05:43,000 --> 01:05:44,750
Eu estava trabalhando com um
cliente que me disse

1501
01:05:44,750 --> 01:05:47,040
que, agora que eles têm
ido para Dynamo DB, eles são

1502
01:05:47,040 --> 01:05:50,330
gastar mais dinheiro em lanches para
sua equipe de desenvolvimento a cada mês

1503
01:05:50,330 --> 01:05:52,886
do que gastam em seu banco de dados.

1504
01:05:52,886 --> 01:05:54,760
Por isso, vamos dar-lhe um
idéia da redução de custos

1505
01:05:54,760 --> 01:05:57,889
que você pode obter no Dynamo DB é enorme.

1506
01:05:57,889 --> 01:05:59,430
Tudo bem, Dropcam é outra empresa.

1507
01:05:59,430 --> 01:06:02,138
Estes cara é tipo de-- se você pensa
de internet das coisas, Dropcam

1508
01:06:02,138 --> 01:06:05,150
é basicamente vídeo de segurança internet.

1509
01:06:05,150 --> 01:06:06,660
Você coloca sua câmera para fora lá.

1510
01:06:06,660 --> 01:06:08,180
Câmara tem um detector de movimento.

1511
01:06:08,180 --> 01:06:10,290
Alguém vem junto,
desencadeia um ponto de sinalização.

1512
01:06:10,290 --> 01:06:13,540
Câmara começa a gravar por um tempo até
ele não detecta qualquer movimento mais.

1513
01:06:13,540 --> 01:06:15,310
Coloca-se que o vídeo na internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam era uma empresa que é
basicamente ligado ao Dínamo DB

1515
01:06:19,800 --> 01:06:22,200
porque eles estavam experimentando
enormes dores de crescimento.

1516
01:06:22,200 --> 01:06:25,820
E o que eles nos disseram,
de repente petabytes de dados.

1517
01:06:25,820 --> 01:06:28,070
Eles não tinham idéia seu serviço
seria tão bem sucedido.

1518
01:06:28,070 --> 01:06:32,310
Mais do que de entrada de vídeo YouTube
é o que esses caras estão ficando.

1519
01:06:32,310 --> 01:06:36,780
Eles usam DynamoDB para acompanhar todo o
metadados em todos os seus pontos-chave de vídeo.

1520
01:06:36,780 --> 01:06:40,282
>> Então eles têm baldes S3 eles empurram
todos os artefatos binários em.

1521
01:06:40,282 --> 01:06:41,990
E então eles têm
Registros Dynamo DB que

1522
01:06:41,990 --> 01:06:44,070
apontar as pessoas para essas S3 três objetos.

1523
01:06:44,070 --> 01:06:47,070
Quando eles precisam de olhar para um vídeo,
eles olham-se o registro no Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Eles clicam no link.

1525
01:06:47,903 --> 01:06:49,770
Eles puxar para baixo o vídeo do S3.

1526
01:06:49,770 --> 01:06:51,590
Então, isso é o tipo do que isto parece.

1527
01:06:51,590 --> 01:06:53,580
E isto é em linha reta de sua equipe.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB reduz a sua
tempo de entrega para eventos de vídeo

1529
01:06:56,010 --> 01:06:57,590
de cinco a 10 segundos.

1530
01:06:57,590 --> 01:07:00,470
Em sua loja relacional de idade,
eles costumavam ter que ir e executar

1531
01:07:00,470 --> 01:07:03,780
várias consultas complexas a figura
quais vídeos para puxar para baixo,

1532
01:07:03,780 --> 01:07:06,690
para menos de 50 milissegundos.

1533
01:07:06,690 --> 01:07:08,990
Por isso é incrível, incrível
o quanto de desempenho

1534
01:07:08,990 --> 01:07:12,990
você pode começar quando você otimizar e
você sintonizar o banco de dados subjacente

1535
01:07:12,990 --> 01:07:15,110
para suportar o padrão de acesso.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, esses caras, o que é,
Fruit Ninja eu acho que é a sua coisa.

1537
01:07:20,500 --> 01:07:22,590
Que todas as corridas em Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
E esses caras, eles são uma ótima
equipe de desenvolvimento, grande desenvolvimento

1539
01:07:26,810 --> 01:07:27,670
loja.

1540
01:07:27,670 --> 01:07:29,364
>> Não é uma boa equipe de operações.

1541
01:07:29,364 --> 01:07:31,280
Eles não têm muito
de recursos de operação.

1542
01:07:31,280 --> 01:07:33,940
Eles estavam lutando tentando manter
sua infra-estrutura de aplicação up

1543
01:07:33,940 --> 01:07:34,290
e em execução.

1544
01:07:34,290 --> 01:07:35,000
Eles vieram até nós.

1545
01:07:35,000 --> 01:07:36,251
Eles olharam para que Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Eles disseram, isso é para nós.

1547
01:07:37,291 --> 01:07:39,470
Eles construíram seu todo
estrutura de aplicativos nele.

1548
01:07:39,470 --> 01:07:43,640
Alguns muito bons comentários aqui
da equipe em sua capacidade

1549
01:07:43,640 --> 01:07:46,800
agora se concentrar no edifício
o jogo e não

1550
01:07:46,800 --> 01:07:49,010
ter de manter o
infra-estrutura, o que

1551
01:07:49,010 --> 01:07:51,910
estava se tornando uma enorme quantidade
de sobrecarga para sua equipe.

1552
01:07:51,910 --> 01:07:56,170
Então, isso é algo que-- o
benefício que você começa a partir Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Tudo bem, metendo
modelagem de dados aqui.

1554
01:08:00,930 --> 01:08:03,440
E nós conversamos um pouco sobre
este 1-1, um para muitos,

1555
01:08:03,440 --> 01:08:05,060
e muitos para muitos relacionamentos de tipo.

1556
01:08:05,060 --> 01:08:07,630
E como você manter aqueles na Dynamo.

1557
01:08:07,630 --> 01:08:10,500
Em Dynamo DB usamos
índices, de um modo geral,

1558
01:08:10,500 --> 01:08:12,910
para rodar os dados a partir de
um sabor para o outro.

1559
01:08:12,910 --> 01:08:15,210
Chaves de hash, chaves de gama, e índices.

1560
01:08:15,210 --> 01:08:18,540
>> Nesse particular
exemplo, como a maioria dos estados

1561
01:08:18,540 --> 01:08:23,802
tem uma exigência de licenciamento que
apenas a licença de motorista de um por pessoa.

1562
01:08:23,802 --> 01:08:26,510
Você não pode ir para obter duas motorista
licenças no estado de Boston.

1563
01:08:26,510 --> 01:08:27,500
Eu não posso fazê-lo no Texas.

1564
01:08:27,500 --> 01:08:28,708
Esse é um tipo da maneira que é.

1565
01:08:28,708 --> 01:08:32,779
E assim no DMV, temos pesquisas, nós
quero olhar para cima a carteira de motorista

1566
01:08:32,779 --> 01:08:35,180
pelo número de segurança social.

1567
01:08:35,180 --> 01:08:39,990
Eu quero olhar-se os detalhes do usuário
pelo número da carteira de motorista.

1568
01:08:39,990 --> 01:08:43,620
>> Assim, poderíamos ter uma mesa do usuário que
tem uma chave de hash no número de série,

1569
01:08:43,620 --> 01:08:47,830
ou o número de segurança social, e
vários atributos definido no item.

1570
01:08:47,830 --> 01:08:49,859
Agora, naquela mesa I
poderia definir um GSI que

1571
01:08:49,859 --> 01:08:53,370
flips que cerca que diz que eu quero
uma chave de hash na licença e, em seguida,

1572
01:08:53,370 --> 01:08:54,252
todos os outros itens.

1573
01:08:54,252 --> 01:08:57,210
Agora, se eu deseja consultar e encontrar o
número de licença para qualquer Sociais

1574
01:08:57,210 --> 01:08:59,609
Número de segurança, eu posso
consultar a tabela principal.

1575
01:08:59,609 --> 01:09:02,130
>> Se eu quiser consultar e eu quero
para obter a segurança social

1576
01:09:02,130 --> 01:09:05,735
número ou outros atributos por um
número da licença, posso consultar o GSI.

1577
01:09:05,735 --> 01:09:08,689
Esse modelo é que um
a uma relação.

1578
01:09:08,689 --> 01:09:12,460
Apenas uma forma muito simples GSI,
virar as coisas ao redor.

1579
01:09:12,460 --> 01:09:13,979
Agora, falar sobre um para muitos.

1580
01:09:13,979 --> 01:09:16,450
Um para muitos é, basicamente,
sua chave gama hash.

1581
01:09:16,450 --> 01:09:20,510
Onde temos um monte com este
caso de uso é dados do monitor.

1582
01:09:20,510 --> 01:09:23,880
Monitor de dados vem em comum
intervalo, como internet das coisas.

1583
01:09:23,880 --> 01:09:26,890
Nós sempre obter todos estes
registos vindo em todo o tempo.

1584
01:09:26,890 --> 01:09:31,420
>> E eu quero encontrar todas as leituras
entre um determinado período de tempo.

1585
01:09:31,420 --> 01:09:34,220
É uma consulta muito comum em
infra-estrutura de monitoramento.

1586
01:09:34,220 --> 01:09:38,430
A maneira de ir sobre isso é encontrar um
estrutura de tabela simples, uma mesa.

1587
01:09:38,430 --> 01:09:42,250
Eu tenho uma tabela de medições do dispositivo
com uma chave de hash sobre a identificação do dispositivo.

1588
01:09:42,250 --> 01:09:47,340
E eu tenho uma chave intervalo na
timestamp, ou neste caso, o épico.

1589
01:09:47,340 --> 01:09:50,350
E isso permite-me executar complexo
consultas em que a chave gama

1590
01:09:50,350 --> 01:09:54,950
e retornar os registros que
são em relação ao resultado

1591
01:09:54,950 --> 01:09:56,310
definir que eu estou procurando.

1592
01:09:56,310 --> 01:09:58,360
E ele constrói que um
para muitos relação

1593
01:09:58,360 --> 01:10:02,340
na tabela usando o primário
chave de hash, estrutura de chave intervalo.

1594
01:10:02,340 --> 01:10:04,600
>> Então, esse é o tipo de construção
na tabela da Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Quando eu definir um hash
e mesa de gama t, eu sou

1596
01:10:07,290 --> 01:10:09,240
a definição de uma relação um para muitos.

1597
01:10:09,240 --> 01:10:12,770
É uma relação pai-filho.

1598
01:10:12,770 --> 01:10:14,620
>> Vamos falar sobre muitos
para muitos relacionamentos.

1599
01:10:14,620 --> 01:10:19,170
E para este exemplo particular,
novamente, nós vamos usar GSI de.

1600
01:10:19,170 --> 01:10:23,500
E vamos falar sobre o jogo
cenário onde eu tenho um determinado usuário.

1601
01:10:23,500 --> 01:10:26,500
Eu quero descobrir todos os jogos que
ele está registrado para ou jogar em.

1602
01:10:26,500 --> 01:10:29,600
E para um determinado jogo, eu
quer encontrar todos os utilizadores.

1603
01:10:29,600 --> 01:10:31,010
Então, como posso fazer isso?

1604
01:10:31,010 --> 01:10:34,330
Minha tabela de jogos do usuário, eu vou
para ter uma chave de hash de ID do usuário

1605
01:10:34,330 --> 01:10:35,810
e uma chave intervalo do jogo.

1606
01:10:35,810 --> 01:10:37,810
>> Assim, um usuário pode ter vários jogos.

1607
01:10:37,810 --> 01:10:41,380
É uma relação um para muitos entre
o usuário e os jogos que ele joga.

1608
01:10:41,380 --> 01:10:43,410
E em seguida, no GSI,
Eu vou virar essa volta.

1609
01:10:43,410 --> 01:10:46,679
Vou botar no jogo e
Vou variar sobre o usuário.

1610
01:10:46,679 --> 01:10:48,970
Então, se eu quiser obter todas as
jogo o usuário de jogar em,

1611
01:10:48,970 --> 01:10:49,950
Vou consultar a tabela principal.

1612
01:10:49,950 --> 01:10:52,699
Se eu quiser obter todos os usuários
que estão jogando um jogo particular,

1613
01:10:52,699 --> 01:10:53,887
Eu consultar o GSI.

1614
01:10:53,887 --> 01:10:54,970
Assim você ver como vamos fazer isso?

1615
01:10:54,970 --> 01:10:58,369
Você constrói a apoiar estes do GSI o
caso de uso, o aplicativo, o acesso

1616
01:10:58,369 --> 01:10:59,410
teste padrão, o aplicativo.

1617
01:10:59,410 --> 01:11:01,440
>> Se eu precisar consultar on
esta dimensão, deixe-

1618
01:11:01,440 --> 01:11:03,500
me criar um índice em que dimensão.

1619
01:11:03,500 --> 01:11:05,850
Se eu não fizer isso, eu não me importo.

1620
01:11:05,850 --> 01:11:09,060
E, dependendo do caso de uso, I
pode precisar o índice ou eu não poderia.

1621
01:11:09,060 --> 01:11:12,390
Se é um simples um para muitos,
da tabela primária é bom.

1622
01:11:12,390 --> 01:11:15,860
Se eu preciso fazer estes muitos a
muitos de, ou eu preciso fazer um para queridos,

1623
01:11:15,860 --> 01:11:18,390
então talvez eu preciso
a segunda no índice.

1624
01:11:18,390 --> 01:11:20,840
Então, tudo depende
o que eu estou tentando fazer

1625
01:11:20,840 --> 01:11:24,550
eo que eu estou tentando obter realizado.

1626
01:11:24,550 --> 01:11:28,000
>> Provavelmente eu não vou gastar muito
muito tempo falando sobre documentos.

1627
01:11:28,000 --> 01:11:31,460
Isto torna-se um pouco, provavelmente,
mais profundo do que precisamos para entrar.

1628
01:11:31,460 --> 01:11:33,710
Vamos falar um pouco
expressão de consulta sobre a rica.

1629
01:11:33,710 --> 01:11:37,831
Assim, no Dynamo DB temos
a capacidade de criar

1630
01:11:37,831 --> 01:11:39,330
o que chamamos de expressões de projeção.

1631
01:11:39,330 --> 01:11:42,660
Projeção expressões são simplesmente
escolher os campos ou os valores

1632
01:11:42,660 --> 01:11:44,290
que você deseja exibir.

1633
01:11:44,290 --> 01:11:46,000
OK, então eu fazer uma seleção.

1634
01:11:46,000 --> 01:11:48,010
Eu faço uma consulta contra Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
E eu digo, você sabe o que, mostra
me apenas os cinco estrelas comentários

1636
01:11:51,730 --> 01:11:54,544
para este produto particular.

1637
01:11:54,544 --> 01:11:55,710
Então, isso é tudo que eu quero ver.

1638
01:11:55,710 --> 01:11:57,320
Eu não quero ver todas as
outros atributos da linha,

1639
01:11:57,320 --> 01:11:58,319
Eu só quero ver isso.

1640
01:11:58,319 --> 01:12:01,209
É como quando você em SQL
dizer selecione estrela ou de mesa,

1641
01:12:01,209 --> 01:12:02,000
você começa tudo.

1642
01:12:02,000 --> 01:12:05,450
Quando eu digo selecione o nome de
mesa, eu só obter um atributo.

1643
01:12:05,450 --> 01:12:09,070
É o mesmo tipo de coisa em
Dynamo DB ou mais bancos de dados NoSQL.

1644
01:12:09,070 --> 01:12:14,510
As expressões de filtro permita-me
basicamente cortar o conjunto de resultados para baixo.

1645
01:12:14,510 --> 01:12:15,540
Então eu faço uma consulta.

1646
01:12:15,540 --> 01:12:17,260
Consulta pode voltar com 500 itens.

1647
01:12:17,260 --> 01:12:20,255
Mas eu só quero os itens que
tem um atributo que diz isso.

1648
01:12:20,255 --> 01:12:23,380
OK, então vamos filtrar esses itens
que não correspondem a essa consulta particular.

1649
01:12:23,380 --> 01:12:25,540
Então nós temos expressões de filtro.

1650
01:12:25,540 --> 01:12:28,310
>> As expressões de filtro pode
ser executado em qualquer atributo.

1651
01:12:28,310 --> 01:12:30,260
Eles não são como consultas por abrangência.

1652
01:12:30,260 --> 01:12:32,690
Levantar questões são mais seletivos.

1653
01:12:32,690 --> 01:12:36,470
Consultas de filtro de me obrigar a ir
se os resultados inteiros definir e, em seguida

1654
01:12:36,470 --> 01:12:39,170
esculpir os dados que eu não quero.

1655
01:12:39,170 --> 01:12:40,660
Por que isso é importante?

1656
01:12:40,660 --> 01:12:42,770
Porque eu li tudo.

1657
01:12:42,770 --> 01:12:46,597
Em uma consulta, eu vou ler e
ele vai ser um gigante sobre os dados.

1658
01:12:46,597 --> 01:12:48,430
E então eu vou
esculpir o que eu preciso.

1659
01:12:48,430 --> 01:12:52,080
E se eu só estou conquistando um
par de linhas, então isso é OK.

1660
01:12:52,080 --> 01:12:53,620
Não é tão ineficiente.

1661
01:12:53,620 --> 01:12:57,800
>> Mas se eu estou lendo uma pilha de
dados, só para esculpir um item,

1662
01:12:57,800 --> 01:13:01,490
então eu vou ser melhor
fora de usar uma consulta de gama,

1663
01:13:01,490 --> 01:13:03,030
porque é muito mais seletivo.

1664
01:13:03,030 --> 01:13:06,330
Ele vai me salvar um monte de
dinheiro, porque eu pagar por essa leitura.

1665
01:13:06,330 --> 01:13:10,430
Sempre que os resultados que vem de volta
cruzar essa fio pode ser menor,

1666
01:13:10,430 --> 01:13:11,890
mas eu estou pagando para a leitura.

1667
01:13:11,890 --> 01:13:14,340
Assim, entender como
você está recebendo os dados.

1668
01:13:14,340 --> 01:13:16,420
Isso é muito importante na Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> As expressões condicionais, isto é o que
você poderia chamar de bloqueio otimista.

1670
01:13:19,710 --> 01:13:28,470
Atualização se existe, ou se esse valor
é equivalente ao que eu especificar.

1671
01:13:28,470 --> 01:13:31,494
E se eu tiver um carimbo de tempo em um
registro, eu poderia ler os dados.

1672
01:13:31,494 --> 01:13:32,535
Eu poderia mudar esses dados.

1673
01:13:32,535 --> 01:13:35,030
Eu poderia ir gravação que
dados de volta para o banco de dados.

1674
01:13:35,030 --> 01:13:38,100
Se alguém mudou o registro,
o timestamp poderia ter mudado.

1675
01:13:38,100 --> 01:13:40,370
E de que maneira a minha condicional
atualização poderia dizer actualização

1676
01:13:40,370 --> 01:13:42,340
Se a data e hora é igual a este.

1677
01:13:42,340 --> 01:13:46,290
Ou a atualização falhará porque alguém
atualizou o registro no mesmo período.

1678
01:13:46,290 --> 01:13:48,290
>> Isso é o que chamamos de bloqueio otimista.

1679
01:13:48,290 --> 01:13:50,670
Isso significa que alguém
pode entrar e mudá-lo,

1680
01:13:50,670 --> 01:13:53,100
e eu estou indo para detectá-lo
quando eu voltar a escrever.

1681
01:13:53,100 --> 01:13:56,106
E então eu posso realmente ler que
dados e dizer, oh, ele mudou isso.

1682
01:13:56,106 --> 01:13:57,230
Eu preciso explicar isso.

1683
01:13:57,230 --> 01:14:00,490
E eu posso mudar os dados na minha
gravar e aplicar outra atualização.

1684
01:14:00,490 --> 01:14:04,330
Então você pode pegar aqueles incrementais
atualizações que ocorrem entre o momento

1685
01:14:04,330 --> 01:14:08,740
que você lê os dados ea
tempo você pode gravar os dados.

1686
01:14:08,740 --> 01:14:11,520
>> AUDIÊNCIA: E o filtro
expressão, na verdade, não significa

1687
01:14:11,520 --> 01:14:13,020
no número ou não--

1688
01:14:13,020 --> 01:14:14,316
>> [Interpondo VOZES]

1689
01:14:14,316 --> 01:14:16,232
RICK HOULIHAN: Eu não vou
obter muito para isso.

1690
01:14:16,232 --> 01:14:17,700
Esta é uma palavra-chave reservada.

1691
01:14:17,700 --> 01:14:20,130
A vista é uma libra reservados
palavra-chave no Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Cada banco de dados tem sua própria reservados
nomes para as coleções que você não pode usar.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, se você especificar
uma libra na frente desta,

1694
01:14:27,240 --> 01:14:29,310
você pode definir os nomes acima.

1695
01:14:29,310 --> 01:14:31,840
Este é um valor de referência.

1696
01:14:31,840 --> 01:14:34,880
Provavelmente não é o melhor para sintaxe
tem lá em cima para esta discussão,

1697
01:14:34,880 --> 01:14:38,090
porque ele recebe em alguns real--
Eu teria falado mais

1698
01:14:38,090 --> 01:14:41,360
sobre isso em um nível mais profundo.

1699
01:14:41,360 --> 01:14:46,130
>> Mas basta dizer, isso poderia
ser consulta digitalizar onde views--

1700
01:14:46,130 --> 01:14:50,190
nem libra vista é superior a 10.

1701
01:14:50,190 --> 01:14:54,660
É um valor numérico, sim.

1702
01:14:54,660 --> 01:14:57,322
Se você quiser, podemos falar sobre
que, após a discussão.

1703
01:14:57,322 --> 01:15:00,030
Tudo bem, então estamos entrando em
alguns cenários em melhores práticas

1704
01:15:00,030 --> 01:15:02,000
onde nós estamos indo falar
sobre alguns aplicativos aqui.

1705
01:15:02,000 --> 01:15:03,810
Quais são os casos de uso para Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
O que são o design
padrões em Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> E o primeiro que vamos
falar é a internet das coisas.

1708
01:15:09,110 --> 01:15:15,010
Então nós temos um monte de-- eu acho,
o que é mais do que ele-- 50%

1709
01:15:15,010 --> 01:15:19,370
de tráfego na internet nos dias de hoje
é na verdade gerado por máquinas,

1710
01:15:19,370 --> 01:15:21,930
processos automatizados, não por seres humanos.

1711
01:15:21,930 --> 01:15:25,140
Quero dizer esta coisa essa coisa que
você carrega no seu bolso,

1712
01:15:25,140 --> 01:15:28,840
quantos dados que essa coisa é
realmente enviando ao redor sem você

1713
01:15:28,840 --> 01:15:30,550
sabendo que é absolutamente incrível.

1714
01:15:30,550 --> 01:15:34,970
Sua localização, informações
sobre o quão rápido você está indo.

1715
01:15:34,970 --> 01:15:38,400
Como você acha que o Google Maps funciona
quando lhe dizem que o tráfego é.

1716
01:15:38,400 --> 01:15:41,275
É porque existem milhões e
milhões de pessoas em torno de condução

1717
01:15:41,275 --> 01:15:44,667
com os telefones que estão enviando
dados em todo lugar o tempo todo.

1718
01:15:44,667 --> 01:15:46,500
Então, uma das coisas
sobre este tipo de dados

1719
01:15:46,500 --> 01:15:50,980
que vem em, dados do monitor, ingresse
dados, dados de séries temporais, é que é

1720
01:15:50,980 --> 01:15:53,540
geralmente só é interessante
para um pouco de tempo.

1721
01:15:53,540 --> 01:15:55,580
Após esse tempo, é
não é tão interessante.

1722
01:15:55,580 --> 01:15:58,390
Então nós conversamos sobre, não deixe
essas tabelas crescer sem limites.

1723
01:15:58,390 --> 01:16:03,410
A idéia aqui é que talvez eu tenha 24
horas no valor de acontecimentos na minha mesa quente.

1724
01:16:03,410 --> 01:16:06,160
E que mesa quente vai ser
provisionados em uma taxa muito alta,

1725
01:16:06,160 --> 01:16:07,950
porque ele está tomando um monte de dados.

1726
01:16:07,950 --> 01:16:10,920
Está levando um monte de dados
e eu estou lendo muito.

1727
01:16:10,920 --> 01:16:14,560
Eu tenho um monte de operação
consultas que executam em relação a esses dados.

1728
01:16:14,560 --> 01:16:18,120
>> Após 24 horas, hey, você
sabe, eu não me importo.

1729
01:16:18,120 --> 01:16:21,150
Então, talvez eu rolo cada meia-noite
sobre minha mesa para uma nova tabela

1730
01:16:21,150 --> 01:16:22,430
e eu desprovisione esta tabela.

1731
01:16:22,430 --> 01:16:26,440
E eu vou levar da RCU e
Para baixo do WCU porque 24 horas depois

1732
01:16:26,440 --> 01:16:28,630
Eu não estou correndo como muitos
consultas em que os dados.

1733
01:16:28,630 --> 01:16:30,200
Então, eu estou indo para poupar dinheiro.

1734
01:16:30,200 --> 01:16:32,940
E talvez 30 dias mais tarde, eu não
ainda precisa se preocupar com tudo.

1735
01:16:32,940 --> 01:16:35,020
Eu poderia assumir a WCU de
todo o caminho para um,

1736
01:16:35,020 --> 01:16:36,990
porque você sabe o que, é
Nunca vai ficar gravado.

1737
01:16:36,990 --> 01:16:38,300
Os dados são de 30 dias de idade.

1738
01:16:38,300 --> 01:16:40,000
Ele nunca muda.

1739
01:16:40,000 --> 01:16:44,200
>> E é quase nunca vai conseguir ler,
então vamos ter que RCU para 10.

1740
01:16:44,200 --> 01:16:49,372
E eu estou economizando uma tonelada de dinheiro com isso
dados, e só pagando por meus dados quentes.

1741
01:16:49,372 --> 01:16:52,330
Então essa é a coisa importante é olhar
em quando você olha para uma série temporal

1742
01:16:52,330 --> 01:16:54,716
dados entrando em volume.

1743
01:16:54,716 --> 01:16:55,590
Estas são estratégias.

1744
01:16:55,590 --> 01:16:58,010
Agora, eu poderia simplesmente deixá-lo
vão todos para a mesma tabela

1745
01:16:58,010 --> 01:16:59,461
e deixe que a tabela crescer.

1746
01:16:59,461 --> 01:17:01,460
Eventualmente, eu vou
ver problemas de desempenho.

1747
01:17:01,460 --> 01:17:04,060
Eu vou ter que começar a arquivar
alguns desses dados para fora da mesa,

1748
01:17:04,060 --> 01:17:04,720
que não.

1749
01:17:04,720 --> 01:17:07,010
>> Vamos muito melhor
projetar seu aplicativo

1750
01:17:07,010 --> 01:17:08,900
para que você possa operar este caminho certo.

1751
01:17:08,900 --> 01:17:11,460
Então é só automática
no código do aplicativo.

1752
01:17:11,460 --> 01:17:13,580
À meia-noite todas as noites
rola a tabela.

1753
01:17:13,580 --> 01:17:17,170
Talvez o que eu preciso é de um deslizamento
janela de 24 horas de dados.

1754
01:17:17,170 --> 01:17:20,277
Em seguida, em uma base regular que eu sou
chamando de dados fora da mesa.

1755
01:17:20,277 --> 01:17:22,360
Eu estou cortando-o com uma
Cron trabalho e eu estou colocando-

1756
01:17:22,360 --> 01:17:24,160
para estes quadros,
o que você precisar.

1757
01:17:24,160 --> 01:17:25,940
Portanto, se um rollover trabalha, isso é ótimo.

1758
01:17:25,940 --> 01:17:27,080
Se não, cortá-la.

1759
01:17:27,080 --> 01:17:29,640
Mas vamos manter os dados quente
longe de seus dados frios.

1760
01:17:29,640 --> 01:17:32,535
Ele vai te salvar um monte de dinheiro e
fazer suas tabelas mais desempenho.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Portanto, a próxima coisa que vou falar
é cerca de catálogo de produtos.

1763
01:17:38,210 --> 01:17:42,000
Catálogo dos produtos é
caso de uso bastante comum.

1764
01:17:42,000 --> 01:17:46,600
Este é realmente um padrão muito comum
que vamos ver em uma variedade de coisas.

1765
01:17:46,600 --> 01:17:48,870
Você sabe, para Twitter
exemplo, um tweet quente.

1766
01:17:48,870 --> 01:17:51,280
Todo mundo está vindo e
agarrando que tweet.

1767
01:17:51,280 --> 01:17:52,680
Catálogo dos produtos, eu tenho uma venda.

1768
01:17:52,680 --> 01:17:54,120
Eu tenho uma venda quente.

1769
01:17:54,120 --> 01:17:57,277
Eu tenho 70.000 pedidos por
segunda vinda de um produto

1770
01:17:57,277 --> 01:17:58,860
descrição do meu catálogo de produtos.

1771
01:17:58,860 --> 01:18:02,384
Vemos isso no varejo
operação um pouco.

1772
01:18:02,384 --> 01:18:03,550
Então, como vamos lidar com isso?

1773
01:18:03,550 --> 01:18:04,924
Não há nenhuma maneira de lidar com isso.

1774
01:18:04,924 --> 01:18:07,110
Todos os meus usuários querem ver
o mesmo pedaço de dados.

1775
01:18:07,110 --> 01:18:09,410
Eles estão estão chegando, simultaneamente.

1776
01:18:09,410 --> 01:18:11,920
E eles estão todos fazendo pedidos
para o mesmo pedaço de dados.

1777
01:18:11,920 --> 01:18:16,240
Isso me dá a chave quente, que grande e vermelho
listra no meu gráfico que nós não gostamos.

1778
01:18:16,240 --> 01:18:17,720
E isso é o que parece.

1779
01:18:17,720 --> 01:18:22,290
Assim, em toda a minha tecla espaço que estou recebendo
martelado nos itens de venda.

1780
01:18:22,290 --> 01:18:24,070
Estou recebendo nada em qualquer outro lugar.

1781
01:18:24,070 --> 01:18:26,050
>> Como faço para aliviar este problema?

1782
01:18:26,050 --> 01:18:28,410
Bem, nós aliviar esta com cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, você coloca basicamente um in-memory
partição na frente da base de dados.

1784
01:18:33,630 --> 01:18:37,260
Conseguimos
[Inaudível] cache, como você

1785
01:18:37,260 --> 01:18:40,260
pode configurar o seu próprio cache, [inaudível]
cache de [? d,?] o que quiser.

1786
01:18:40,260 --> 01:18:42,220
Ponha isso na frente do banco de dados.

1787
01:18:42,220 --> 01:18:47,250
E de que maneira você pode armazenar esses dados
a partir dessas teclas de atalho para cima em que o cache

1788
01:18:47,250 --> 01:18:49,390
espaço e ler o cache.

1789
01:18:49,390 --> 01:18:51,962
>> E então a maioria de suas leituras
começar a olhar como este.

1790
01:18:51,962 --> 01:18:54,920
Eu tenho todos estes cache de bate-se aqui
e eu não tenho nada acontecendo aqui

1791
01:18:54,920 --> 01:18:59,330
porque banco de dados está sentado atrás do
cache e não a lê passar.

1792
01:18:59,330 --> 01:19:02,520
Se eu mudar os dados na
banco de dados, eu tenho que atualizar o cache.

1793
01:19:02,520 --> 01:19:04,360
Podemos usar algo
como vapores de fazer isso.

1794
01:19:04,360 --> 01:19:07,360
E eu vou explicar como isso funciona.

1795
01:19:07,360 --> 01:19:09,060
Tudo bem, messaging.

1796
01:19:09,060 --> 01:19:11,180
E-mail, todos nós usamos e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> Este é um bom exemplo.

1798
01:19:12,540 --> 01:19:14,950
Temos algum tipo de tabela de mensagens.

1799
01:19:14,950 --> 01:19:17,040
E nós temos caixa de entrada e caixa de saída.

1800
01:19:17,040 --> 01:19:19,760
Isto é o que o faria SQL
Look Like a construir essa caixa de entrada.

1801
01:19:19,760 --> 01:19:23,350
Nós tipo de usar o mesmo tipo
da estratégia de usar GSI de, GSI de

1802
01:19:23,350 --> 01:19:25,320
para minha caixa de entrada e minha caixa de saída.

1803
01:19:25,320 --> 01:19:27,600
Então, eu tenho mensagens de matérias-vindo
em minha tabela de mensagens.

1804
01:19:27,600 --> 01:19:30,194
E a primeira abordagem a este
pode ser, digamos, OK, não há problema.

1805
01:19:30,194 --> 01:19:31,110
Eu tenho mensagens matérias.

1806
01:19:31,110 --> 01:19:33,710
Mensagens provenientes [inaudível],
mensagem de ID, isso é ótimo.

1807
01:19:33,710 --> 01:19:35,070
Esse é o meu hash exclusivo.

1808
01:19:35,070 --> 01:19:38,280
Eu vou criar dois GSI de, um
para minha caixa de entrada, uma para minha caixa de saída.

1809
01:19:38,280 --> 01:19:40,530
E a primeira coisa que vou fazer
é que eu vou dizer a minha chave de hash é

1810
01:19:40,530 --> 01:19:43,310
vai ser o destinatário e
Vou organizar na data.

1811
01:19:43,310 --> 01:19:44,220
Isso é fantástico.

1812
01:19:44,220 --> 01:19:45,890
Eu tenho a minha bela vista aqui.

1813
01:19:45,890 --> 01:19:47,780
Mas há um pequeno problema aqui.

1814
01:19:47,780 --> 01:19:50,891
E você tiver isso em
bases de dados relacionais bem.

1815
01:19:50,891 --> 01:19:52,390
Eles chamado de particionamento vertical.

1816
01:19:52,390 --> 01:19:55,840
Você deseja manter seus dados grande
longe de seus dados pequenos.

1817
01:19:55,840 --> 01:20:00,470
>> E a razão por que é porque eu tenho que
vá ler os itens de obter os atributos.

1818
01:20:00,470 --> 01:20:05,570
E se meus corpos estão todos aqui,
depois de ler apenas alguns itens

1819
01:20:05,570 --> 01:20:08,560
se o meu comprimento do corpo é
média 256 quilobytes cada,

1820
01:20:08,560 --> 01:20:10,991
a matemática fica muito feio.

1821
01:20:10,991 --> 01:20:12,490
Então, digamos que eu quero ler caixa de entrada de David.

1822
01:20:12,490 --> 01:20:14,520
Caixa de entrada de David tem 50 itens.

1823
01:20:14,520 --> 01:20:17,880
A média eo tamanho é de 256 kilobytes.

1824
01:20:17,880 --> 01:20:21,730
Aqui está a minha taxa de conversão
para RCU é de quatro kilobytes.

1825
01:20:21,730 --> 01:20:24,450
>> OK, vamos com
leituras eventualmente consistentes.

1826
01:20:24,450 --> 01:20:28,640
Eu ainda estou comendo 1600 RCU do
só para ler caixa de entrada de David.

1827
01:20:28,640 --> 01:20:29,950
Ouch.

1828
01:20:29,950 --> 01:20:31,980
OK, agora vamos pensar
sobre como o aplicativo funciona.

1829
01:20:31,980 --> 01:20:35,340
Se eu estou em um aplicativo de e-mail e
Eu estou olhando para minha caixa de entrada,

1830
01:20:35,340 --> 01:20:39,680
e eu olhar para o corpo de cada mensagem,
não, eu estou olhando para os resumos.

1831
01:20:39,680 --> 01:20:41,850
Eu estou olhando apenas os cabeçalhos.

1832
01:20:41,850 --> 01:20:46,310
Então, vamos construir uma estrutura de tabela
que se parece mais com isso.

1833
01:20:46,310 --> 01:20:49,470
>> Então aqui está a informação
que o meu fluxo de trabalho precisa.

1834
01:20:49,470 --> 01:20:50,890
Está na minha caixa de entrada GSI.

1835
01:20:50,890 --> 01:20:53,800
É a data, o remetente,
o assunto e, em seguida,

1836
01:20:53,800 --> 01:20:56,790
a identificação da mensagem, que aponta
de volta para a tabela de mensagens

1837
01:20:56,790 --> 01:20:57,850
onde posso obter o corpo.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Bem, estes seriam IDs de registro.

1840
01:21:04,420 --> 01:21:09,850
Eles iriam apontar de volta para o
IDs de item na tabela de Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Cada índice sempre creates--
sempre tem o item

1842
01:21:12,220 --> 01:21:15,750
ID como parte de-- que
vem com o índice.

1843
01:21:15,750 --> 01:21:17,414
>> Tudo certo.

1844
01:21:17,414 --> 01:21:19,080
AUDIÊNCIA: Diz-lo onde ele é armazenado?

1845
01:21:19,080 --> 01:21:21,420
RICK HOULIHAN: Sim, diz-
exactly-- isso é exatamente o que ele faz.

1846
01:21:21,420 --> 01:21:22,644
Diz aqui é o meu recorde re.

1847
01:21:22,644 --> 01:21:24,310
E vai apontá-lo de volta para o meu recorde re.

1848
01:21:24,310 --> 01:21:26,460
Exatamente.

1849
01:21:26,460 --> 01:21:29,490
OK, então agora é minha caixa de entrada
na verdade, muito menor.

1850
01:21:29,490 --> 01:21:32,210
E isso realmente suporta
o fluxo de trabalho de um aplicativo de e-mail.

1851
01:21:32,210 --> 01:21:34,230
Assim, a minha caixa de entrada, eu clicar.

1852
01:21:34,230 --> 01:21:38,160
Eu ir junto e eu clicar sobre a mensagem,
que é quando eu preciso ir buscar o corpo,

1853
01:21:38,160 --> 01:21:40,180
porque eu vou
ir para uma visão diferente.

1854
01:21:40,180 --> 01:21:43,870
Então, se você pensar sobre o tipo de MVC
quadro, controlador de vista do modelo.

1855
01:21:43,870 --> 01:21:46,120
>> O modelo contém a
dados que a visão necessidades

1856
01:21:46,120 --> 01:21:48,130
e o controlador interage com.

1857
01:21:48,130 --> 01:21:51,670
Quando eu mudar o quadro, quando
Eu mudar a perspectiva,

1858
01:21:51,670 --> 01:21:55,080
que é OK para voltar ao
servidor e repovoar o modelo,

1859
01:21:55,080 --> 01:21:56,860
porque é o que o usuário espera.

1860
01:21:56,860 --> 01:22:00,530
Quando mudar de vista, que é quando
nós podemos ir de volta para o banco de dados.

1861
01:22:00,530 --> 01:22:02,480
Então e-mail, clique em.

1862
01:22:02,480 --> 01:22:03,710
Eu estou olhando para o corpo.

1863
01:22:03,710 --> 01:22:04,330
Ida e volta.

1864
01:22:04,330 --> 01:22:05,680
Vá buscar o corpo.

1865
01:22:05,680 --> 01:22:06,950
>> Eu leio muito menos dados.

1866
01:22:06,950 --> 01:22:09,960
Eu só estou lendo os corpos que
David precisa de quando ele precisa deles.

1867
01:22:09,960 --> 01:22:14,230
E eu não estou queimar em 1600
RCU é só para mostrar a sua caixa de entrada.

1868
01:22:14,230 --> 01:22:17,670
Então agora isso-- este é o caminho
que LSI ou GSI-- Sinto muito,

1869
01:22:17,670 --> 01:22:19,900
GSI, daria certo.

1870
01:22:19,900 --> 01:22:25,450
Nós temos nossa haxixe no destinatário.

1871
01:22:25,450 --> 01:22:27,030
Nós temos a chave gama na data.

1872
01:22:27,030 --> 01:22:31,380
E nós temos os atributos projectados
que precisamos apenas para apoiar a visão.

1873
01:22:31,380 --> 01:22:34,300
>> Nós girar para que a caixa de saída.

1874
01:22:34,300 --> 01:22:35,770
Hash no remetente.

1875
01:22:35,770 --> 01:22:39,612
E, em essência, temos
a, vista limpo muito agradável.

1876
01:22:39,612 --> 01:22:41,570
E é que basically--
tem este agradável mensagens

1877
01:22:41,570 --> 01:22:45,870
tabela que está sendo espalhado bem porque
é hash somente, hash ID mensagem.

1878
01:22:45,870 --> 01:22:51,750
E nós temos dois índices que
estão girando fora do referido quadro.

1879
01:22:51,750 --> 01:22:57,411
Tudo bem, então idéia aqui não é fazer
manter os grandes dados e este pequeno dados

1880
01:22:57,411 --> 01:22:57,910
junto.

1881
01:22:57,910 --> 01:23:00,700
Particionar verticalmente,
particionar essas tabelas.

1882
01:23:00,700 --> 01:23:03,150
Não leia dados que você não tem que.

1883
01:23:03,150 --> 01:23:04,850
Tudo bem, jogo.

1884
01:23:04,850 --> 01:23:06,990
Nós todos gostamos de jogos.

1885
01:23:06,990 --> 01:23:10,902
Pelo menos eu gosto de jogos depois.

1886
01:23:10,902 --> 01:23:12,735
Assim, algumas das coisas
que lidar com quando

1887
01:23:12,735 --> 01:23:14,193
nós estamos pensando sobre o jogo, certo?

1888
01:23:14,193 --> 01:23:16,999
Jogos nestes dias, especialmente móvel
jogo, é tudo sobre o pensamento.

1889
01:23:16,999 --> 01:23:19,540
E eu estou indo para rodar aqui um
pouco longe DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Vou trazer
a discussão de alguns

1891
01:23:21,373 --> 01:23:24,240
em torno de alguns dos
outras tecnologias da AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Mas a idéia sobre o jogo é pensar
sobre em termos de APIs, APIs que são,

1893
01:23:28,930 --> 01:23:31,730
de um modo geral, HTTP e JSON.

1894
01:23:31,730 --> 01:23:34,550
É como jogos para celular tipo de
interagir com suas extremidades traseiras.

1895
01:23:34,550 --> 01:23:35,850
Eles fazem JSON postagem.

1896
01:23:35,850 --> 01:23:40,660
Eles ficam de dados, e é tudo,
de um modo geral, em Nice APIs JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Coisas como fazer amigos, obter
os dados leaderboard, câmbio,

1898
01:23:44,950 --> 01:23:47,699
conteúdo gerado por usuários,
empurre de volta para o sistema,

1899
01:23:47,699 --> 01:23:49,740
estes são os tipos de coisas
que nós vamos fazer.

1900
01:23:49,740 --> 01:23:52,542
Dados de ativos binário, estes dados
pode não se sentar no banco de dados.

1901
01:23:52,542 --> 01:23:54,250
Isso pode sentar-se em um
armazenamento de objeto, certo?

1902
01:23:54,250 --> 01:23:56,541
Mas o banco de dados vai
acabam dizendo ao sistema,

1903
01:23:56,541 --> 01:23:59,140
contando a aplicação
onde ir buscá-la.

1904
01:23:59,140 --> 01:24:03,550
E, inevitavelmente, para múltiplos jogadores
servidores, infra-estrutura de back-end,

1905
01:24:03,550 --> 01:24:06,180
e projetado para alta
disponibilidade e escalabilidade.

1906
01:24:06,180 --> 01:24:09,400
Então, essas são as coisas que todos nós queremos
na infra-estrutura do jogo hoje.

1907
01:24:09,400 --> 01:24:12,160
>> Então, vamos dar uma olhada
o que parece.

1908
01:24:12,160 --> 01:24:16,070
Obteve um back-end núcleo,
muito simples.

1909
01:24:16,070 --> 01:24:19,880
Nós temos um sistema aqui com
múltiplas zonas de disponibilidade.

1910
01:24:19,880 --> 01:24:23,780
Nós conversamos sobre como AZs being-- pensar
deles como centros de dados separados.

1911
01:24:23,780 --> 01:24:26,040
Mais de um centro de dados
por AZ, mas isso é OK,

1912
01:24:26,040 --> 01:24:28,831
basta pensar-los como dados separado
centros que estão geograficamente

1913
01:24:28,831 --> 01:24:30,090
e falha isolada.

1914
01:24:30,090 --> 01:24:32,172
>> Nós vamos ter um
instâncias EC2 casal.

1915
01:24:32,172 --> 01:24:33,880
Nós vamos ter
algum servidor back-end.

1916
01:24:33,880 --> 01:24:35,800
Talvez se você é um legado
arquitetura, estamos

1917
01:24:35,800 --> 01:24:38,920
usando o que chamamos de RDS,
serviços de banco de dados relacional.

1918
01:24:38,920 --> 01:24:42,040
Poderia ser MSSQL, MySQL,
ou algo assim.

1919
01:24:42,040 --> 01:24:47,080
Esta é a maneira como um aplicações de lote
são projetados hoje.

1920
01:24:47,080 --> 01:24:49,594
>> Bem, nós pode querer ir com
isto é, quando nós escalar.

1921
01:24:49,594 --> 01:24:51,510
Vamos ir em frente e colocar
o balde S3 lá em cima.

1922
01:24:51,510 --> 01:24:54,200
E isso balde S3, em vez de servir
se esses objetos do nosso servers--

1923
01:24:54,200 --> 01:24:55,220
nós poderíamos fazer isso.

1924
01:24:55,220 --> 01:24:57,210
Você colocar todo o seu binário
objetos em seus servidores

1925
01:24:57,210 --> 01:24:59,751
e você pode usar aqueles servidor
instâncias de servir-se de que os dados.

1926
01:24:59,751 --> 01:25:01,860
Mas isso é muito caro.

1927
01:25:01,860 --> 01:25:05,107
>> Melhor maneira de fazer é ir em frente e
colocar os objetos em um balde S3.

1928
01:25:05,107 --> 01:25:06,315
S3 é um repositórios de objetos.

1929
01:25:06,315 --> 01:25:10,860
Ele é construído especificamente para
servindo-se esses tipos de coisas.

1930
01:25:10,860 --> 01:25:13,690
E deixe que os clientes solicitam
diretamente desses baldes de objetos,

1931
01:25:13,690 --> 01:25:15,390
descarregar os servidores.

1932
01:25:15,390 --> 01:25:17,020
Então, nós estamos começando a escalar aqui.

1933
01:25:17,020 --> 01:25:19,140
>> Agora temos usuários em todo o mundo.

1934
01:25:19,140 --> 01:25:19,730
Eu tenho usuários.

1935
01:25:19,730 --> 01:25:23,380
Eu preciso ter conteúdo localmente
localizado próximo a esses usuários, certo?

1936
01:25:23,380 --> 01:25:26,200
Eu criei um balde S3
como meu repositório de origem.

1937
01:25:26,200 --> 01:25:29,370
E eu vou frente que, com
a distribuição CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront é um CD e um
rede de distribuição de conteúdo.

1939
01:25:31,720 --> 01:25:35,750
Basicamente é preciso de dados que você especificar
e armazena em cache-lo por toda a internet

1940
01:25:35,750 --> 01:25:39,230
assim os usuários em todos os lugares podem ter
uma resposta muito rápida quando

1941
01:25:39,230 --> 01:25:40,960
eles solicitam esses objetos.

1942
01:25:40,960 --> 01:25:41,960
>> Então, você ter uma idéia.

1943
01:25:41,960 --> 01:25:48,230
Você está meio que aproveitando toda a
aspectos da AWS aqui para obter este feito.

1944
01:25:48,230 --> 01:25:50,790
E, eventualmente, jogamos
em um grupo de auto escala.

1945
01:25:50,790 --> 01:25:52,737
Assim, nossos casos AC2
de nossos servidores de jogo,

1946
01:25:52,737 --> 01:25:54,820
como eles começam a ficar mais agitado
e cada vez mais ocupados,

1947
01:25:54,820 --> 01:25:57,236
eles só vai girar outra
exemplo, girar outra instância,

1948
01:25:57,236 --> 01:25:58,210
girar outra instância.

1949
01:25:58,210 --> 01:26:02,090
Assim, a tecnologia AWS tem, ele
permite que você especifique os parâmetros

1950
01:26:02,090 --> 01:26:04,650
em torno do qual seus servidores vai crescer.

1951
01:26:04,650 --> 01:26:08,110
Então você pode ter n número de servidores
lá fora, em um dado momento.

1952
01:26:08,110 --> 01:26:11,870
E se a sua carga vai embora, eles vão
encolher, o número irá diminuir.

1953
01:26:11,870 --> 01:26:15,250
E se a carga de volta,
ele vai crescer de volta para fora, elasticamente.

1954
01:26:15,250 --> 01:26:17,050
>> Então, isso parece ótimo.

1955
01:26:17,050 --> 01:26:19,800
Nós temos um monte de instâncias de EC2.

1956
01:26:19,800 --> 01:26:21,671
Podemos colocar cache
frente dos bancos de dados,

1957
01:26:21,671 --> 01:26:23,045
tentar acelerar os bancos de dados.

1958
01:26:23,045 --> 01:26:25,030
O próximo ponto de pressão
normalmente as pessoas vêem

1959
01:26:25,030 --> 01:26:28,850
é que eles escalar um jogo usando um
sistema de banco de dados relacional.

1960
01:26:28,850 --> 01:26:30,790
Eita, o banco de dados
desempenho é terrível.

1961
01:26:30,790 --> 01:26:31,932
Como podemos melhorar isso?

1962
01:26:31,932 --> 01:26:33,640
Vamos tentar colocar
cache na frente daquele.

1963
01:26:33,640 --> 01:26:36,780
>> Bem, o cache não funciona
tão grande nos jogos, certo?

1964
01:26:36,780 --> 01:26:39,330
Para os jogos, a escrita é doloroso.

1965
01:26:39,330 --> 01:26:40,930
Os jogos são muito pesados ​​escrever.

1966
01:26:40,930 --> 01:26:43,610
Cache não funciona quando você está
escrever pesado, porque você sempre

1967
01:26:43,610 --> 01:26:44,610
tem que atualizar o cache.

1968
01:26:44,610 --> 01:26:47,780
Você atualizar o cache, é
irrelevantes para ser cache.

1969
01:26:47,780 --> 01:26:49,780
Na verdade, é apenas um trabalho extra.

1970
01:26:49,780 --> 01:26:51,970
>> Então, para onde vamos daqui?

1971
01:26:51,970 --> 01:26:54,400
Você tem um grande gargalo
lá em baixo no banco de dados.

1972
01:26:54,400 --> 01:26:57,661
E o lugar para ir
obviamente, é o particionamento.

1973
01:26:57,661 --> 01:26:59,410
Particionamento não é
fácil de fazer quando você está

1974
01:26:59,410 --> 01:27:01,900
lidar com bancos de dados relacionais.

1975
01:27:01,900 --> 01:27:05,080
Com bancos de dados relacionais, você é
responsável pela gestão, de forma eficaz,

1976
01:27:05,080 --> 01:27:06,210
o espaço chave.

1977
01:27:06,210 --> 01:27:10,527
Você está dizendo usuários entre A e M
aqui, entre N e Z ir para lá.

1978
01:27:10,527 --> 01:27:12,360
E você está comutação
em toda a aplicação.

1979
01:27:12,360 --> 01:27:15,000
Então, você está lidando com
esta fonte de dados partição.

1980
01:27:15,000 --> 01:27:18,670
Você tem restrições transacionais
que não ocupam partições.

1981
01:27:18,670 --> 01:27:20,560
Você tem todos os tipos de
messiness que você é

1982
01:27:20,560 --> 01:27:23,040
lidar com lá tentando
para lidar com dimensionando

1983
01:27:23,040 --> 01:27:25,120
e construção de uma infra-estrutura maior.

1984
01:27:25,120 --> 01:27:27,284
É só não é divertido.

1985
01:27:27,284 --> 01:27:30,930
>> AUDIÊNCIA: Então você está dizendo que
o aumento dos pontos de origem acelera

1986
01:27:30,930 --> 01:27:31,430
o processo?

1987
01:27:31,430 --> 01:27:32,513
RICK HOULIHAN: Aumentando?

1988
01:27:32,513 --> 01:27:33,520
Pontos Fonte: platéia.

1989
01:27:33,520 --> 01:27:34,410
RICK HOULIHAN: pontos Fonte?

1990
01:27:34,410 --> 01:27:37,500
AUDIÊNCIA: A partir das informações,
onde a informação está vindo?

1991
01:27:37,500 --> 01:27:38,250
RICK HOULIHAN: Não.

1992
01:27:38,250 --> 01:27:41,820
O que estou dizendo é o aumento da
número de partições no armazenamento de dados

1993
01:27:41,820 --> 01:27:44,060
melhora a taxa de transferência.

1994
01:27:44,060 --> 01:27:48,300
Então, o que está acontecendo aqui é usuários
entrando na instância EC2 aqui em cima,

1995
01:27:48,300 --> 01:27:50,780
bem, se eu precisar de um usuário
isso é A a M, eu vou aqui.

1996
01:27:50,780 --> 01:27:53,560
De N a p, eu vou aqui.

1997
01:27:53,560 --> 01:27:55,060
De P a Z, eu vou aqui.

1998
01:27:55,060 --> 01:27:57,120
>> AUDIÊNCIA: OK, então essas são aqueles
todos armazenados em diferentes nós?

1999
01:27:57,120 --> 01:27:57,911
>> RICK HOULIHAN: Sim.

2000
01:27:57,911 --> 01:28:00,210
Pense nisso como
diferentes silos de dados.

2001
01:28:00,210 --> 01:28:01,660
Então, você está tendo que fazer isso.

2002
01:28:01,660 --> 01:28:02,910
Se você está tentando fazer
isso, se você está tentando

2003
01:28:02,910 --> 01:28:05,730
a escala em uma plataforma relacional,
isto é o que você está fazendo.

2004
01:28:05,730 --> 01:28:08,100
Você está levando de dados e
você está cortando-o para baixo.

2005
01:28:08,100 --> 01:28:10,975
E você está dividindo-o em toda a
várias instâncias do banco de dados.

2006
01:28:10,975 --> 01:28:13,580
E você está administrando tudo o que
na camada de aplicativo.

2007
01:28:13,580 --> 01:28:14,729
Não é divertido.

2008
01:28:14,729 --> 01:28:15,770
Então, o que nós queremos ir?

2009
01:28:15,770 --> 01:28:20,240
Queremos ir DynamoDB, totalmente gerenciado,
Armazenamento de dados NoSQL, prestação de transferência.

2010
01:28:20,240 --> 01:28:22,680
Nós usamos índices secundários.

2011
01:28:22,680 --> 01:28:26,154
É basicamente HTTP API e
inclui suporte documento.

2012
01:28:26,154 --> 01:28:28,570
Então você não precisa se preocupar
sobre qualquer um que o particionamento.

2013
01:28:28,570 --> 01:28:30,740
Fazemos tudo para você.

2014
01:28:30,740 --> 01:28:33,260
Então, agora, em vez disso, você
basta escrever para a mesa.

2015
01:28:33,260 --> 01:28:36,490
Se a tabela precisa ser particionado,
que acontece nos bastidores.

2016
01:28:36,490 --> 01:28:40,642
Você está completamente isolado
do que como um desenvolvedor.

2017
01:28:40,642 --> 01:28:42,350
Então vamos falar sobre
alguns dos casos de uso

2018
01:28:42,350 --> 01:28:47,564
que nos deparamos no jogo, comum
cenários de jogos, tabela de classificação.

2019
01:28:47,564 --> 01:28:49,980
Então você tem os usuários entrando,
os BoardNames que eles são

2020
01:28:49,980 --> 01:28:52,930
em, a pontuação para este usuário.

2021
01:28:52,930 --> 01:28:57,700
Podemos estar hash na UserID,
e então nós temos variedade no jogo.

2022
01:28:57,700 --> 01:28:59,960
Assim, cada usuário quer ver
todo o jogo que ele jogou

2023
01:28:59,960 --> 01:29:01,770
e toda a sua pontuação máxima
em todos o jogo.

2024
01:29:01,770 --> 01:29:04,000
Então, esse é o seu ranking pessoal.

2025
01:29:04,000 --> 01:29:10,010
>> Agora eu quero ir e eu quero get--
por isso fico com esses leaderboards pessoais.

2026
01:29:10,010 --> 01:29:12,827
O que eu quero fazer é ir buscar
a pontuação máxima para todos os usuários.

2027
01:29:12,827 --> 01:29:13,660
Então, como posso fazer isso?

2028
01:29:13,660 --> 01:29:18,070
Quando o meu recorde é hash em
o UserID, variou no jogo,

2029
01:29:18,070 --> 01:29:20,740
bem, eu estou indo para ir em frente
e reestruturar, criar um GSI,

2030
01:29:20,740 --> 01:29:22,370
e eu estou indo para reestruturar esses dados.

2031
01:29:22,370 --> 01:29:27,310
>> Agora vou para hash no
BoardName, que é o jogo.

2032
01:29:27,310 --> 01:29:29,800
E eu estou indo para variar na pontuação máxima.

2033
01:29:29,800 --> 01:29:31,540
E agora eu criei diferentes baldes.

2034
01:29:31,540 --> 01:29:34,790
Eu estou usando a mesma tabela,
os mesmos dados do item.

2035
01:29:34,790 --> 01:29:39,870
Mas eu estou criando um balde que dá
me uma agregação de pontuação máxima por jogo.

2036
01:29:39,870 --> 01:29:43,180
>> E eu posso consultar essa tabela
para obter essa informação.

2037
01:29:43,180 --> 01:29:50,890
Então eu definir esse padrão de consulta até
ser suportada por um índice secundário.

2038
01:29:50,890 --> 01:29:54,556
Agora, eles podem ser classificados por BoardName
e classificados por topscore, dependendo.

2039
01:29:54,556 --> 01:29:57,180
Assim você pode ver, estes são tipos
de casos de uso que você começa no jogo.

2040
01:29:57,180 --> 01:30:02,190
Outro caso bom uso chegarmos em jogos
é prêmios e quem ganhou os prêmios.

2041
01:30:02,190 --> 01:30:05,340
E este é um grande caso de uso
onde chamamos índices esparsos.

2042
01:30:05,340 --> 01:30:07,340
Índices esparsos são o
capacidade de gerar

2043
01:30:07,340 --> 01:30:10,850
um índice que não faz necessariamente
conter todos os único item sobre a mesa.

2044
01:30:10,850 --> 01:30:11,470
E por que não?

2045
01:30:11,470 --> 01:30:14,540
Como o atributo que está sendo
não indexado não existir em cada item.

2046
01:30:14,540 --> 01:30:16,460
>> Portanto, neste particular,
usar caso, eu estou dizendo,

2047
01:30:16,460 --> 01:30:19,240
você sabe o quê, eu vou
criar um atributo chamado Award.

2048
01:30:19,240 --> 01:30:22,970
E eu vou dar a todo usuário
que tem um prêmio que atribuem.

2049
01:30:22,970 --> 01:30:25,950
Usuários que não têm prêmios são
não vai ter esse atributo.

2050
01:30:25,950 --> 01:30:27,800
Então, quando eu criar o
índice, os únicos usuários

2051
01:30:27,800 --> 01:30:28,960
que vão mostrar
no índice são

2052
01:30:28,960 --> 01:30:31,050
aqueles que realmente ganharam prêmios.

2053
01:30:31,050 --> 01:30:34,440
Então essa é uma ótima maneira de ser capaz
para criar índices filtrados que

2054
01:30:34,440 --> 01:30:40,580
são muito, muito seletiva que não fazer
tem que indexar a tabela inteira.

2055
01:30:40,580 --> 01:30:43,050
>> Então, nós estamos ficando com pouco tempo aqui.

2056
01:30:43,050 --> 01:30:49,190
Eu estou indo para ir em frente e pular
fora e ignorar este cenário.

2057
01:30:49,190 --> 01:30:52,625
Fale um pouco about--

2058
01:30:52,625 --> 01:30:54,460
>> AUDIÊNCIA: Posso fazer uma pergunta rápida?

2059
01:30:54,460 --> 01:30:56,722
Um deles é escrever pesado?

2060
01:30:56,722 --> 01:30:57,680
RICK HOULIHAN: O que é?

2061
01:30:57,680 --> 01:30:58,596
AUDIÊNCIA: Escrever pesado.

2062
01:30:58,596 --> 01:31:01,270
RICK HOULIHAN: Escrever pesado.

2063
01:31:01,270 --> 01:31:03,460
Deixe-me ver.

2064
01:31:03,460 --> 01:31:06,220
>> AUDIÊNCIA: Ou que não é
algo que você pode apenas

2065
01:31:06,220 --> 01:31:08,809
voz para em questão de segundos?

2066
01:31:08,809 --> 01:31:10,850
RICK HOULIHAN: Vamos
através do cenário de votação.

2067
01:31:10,850 --> 01:31:11,670
Não é tão ruim.

2068
01:31:11,670 --> 01:31:14,580
Vocês têm alguns minutos?

2069
01:31:14,580 --> 01:31:15,860
ESTÁ BEM.

2070
01:31:15,860 --> 01:31:17,890
>> Então, vamos falar sobre a votação.

2071
01:31:17,890 --> 01:31:20,250
Assim, a votação em tempo real, temos
requisitos para votar.

2072
01:31:20,250 --> 01:31:25,250
Os requisitos são que nós permitimos
cada pessoa para votar apenas uma vez.

2073
01:31:25,250 --> 01:31:28,060
Queremos que ninguém seja capaz
para mudar seu voto.

2074
01:31:28,060 --> 01:31:31,045
Queremos agregação em tempo real
e análise de dados demográficos

2075
01:31:31,045 --> 01:31:34,210
que vamos ser
mostrando aos usuários do site.

2076
01:31:34,210 --> 01:31:35,200
>> Pense neste cenário.

2077
01:31:35,200 --> 01:31:37,550
Trabalhamos muito da realidade
TV mostra onde eles estão

2078
01:31:37,550 --> 01:31:38,960
fazendo estes tipo exato de coisas.

2079
01:31:38,960 --> 01:31:41,584
Então você pode pensar no cenário,
nós temos milhões e milhões

2080
01:31:41,584 --> 01:31:43,959
meninas de adolescentes lá
com seus telefones celulares

2081
01:31:43,959 --> 01:31:46,250
e votação, e votação, e
votar em quem eles são

2082
01:31:46,250 --> 01:31:48,610
encontrar para ser o mais popular.

2083
01:31:48,610 --> 01:31:50,830
Então, essas são algumas das
requisitos corremos para fora.

2084
01:31:50,830 --> 01:31:52,990
>> E assim o primeiro tomar
na resolução deste problema

2085
01:31:52,990 --> 01:31:55,090
seria construir um
aplicação muito simples.

2086
01:31:55,090 --> 01:31:56,490
Então eu tenho esse app.

2087
01:31:56,490 --> 01:31:57,950
Eu tenho alguns eleitores lá fora.

2088
01:31:57,950 --> 01:31:59,980
Eles chegam, eles bateram o aplicativo de votação.

2089
01:31:59,980 --> 01:32:03,440
Eu tenho um pouco de votos tabela raw
Eu só vou despejar esses votos em.

2090
01:32:03,440 --> 01:32:05,780
Eu vou ter algum agregado
votos tabela que

2091
01:32:05,780 --> 01:32:09,490
farei o meu analytics e demografia,
e vamos colocar tudo isso lá dentro.

2092
01:32:09,490 --> 01:32:11,420
>> E isso é ótimo.

2093
01:32:11,420 --> 01:32:12,332
A vida é boa.

2094
01:32:12,332 --> 01:32:15,040
A vida é boa até descobrirmos o que
há sempre apenas um ou dois

2095
01:32:15,040 --> 01:32:16,879
pessoas que são populares em uma eleição.

2096
01:32:16,879 --> 01:32:19,420
Há apenas uma ou duas coisas
que as pessoas realmente se preocupam.

2097
01:32:19,420 --> 01:32:22,340
E se você está votando em
escala, de repente eu sou

2098
01:32:22,340 --> 01:32:26,360
vai ser martelando o inferno fora de
dois candidatos, um ou dois candidatos.

2099
01:32:26,360 --> 01:32:29,390
Um número muito limitado de itens
pessoas acham que ser popular.

2100
01:32:29,390 --> 01:32:31,710
>> Este não é um bom padrão de design.

2101
01:32:31,710 --> 01:32:33,549
Esta é realmente uma
padrão de design muito ruim

2102
01:32:33,549 --> 01:32:36,340
porque cria exatamente o que nós
falou sobre o que era teclas de atalho.

2103
01:32:36,340 --> 01:32:38,960
Teclas de atalho são algo de que não gostamos.

2104
01:32:38,960 --> 01:32:40,470
>> Então, como vamos consertar isso?

2105
01:32:40,470 --> 01:32:47,640
E realmente, a maneira de corrigir isso é
tomando aqueles baldes candidatos

2106
01:32:47,640 --> 01:32:51,490
e para cada candidato que temos,
vamos acrescentar um valor aleatório,

2107
01:32:51,490 --> 01:32:54,192
algo que sabemos, aleatório
um valor entre 100 e,

2108
01:32:54,192 --> 01:32:56,620
entre 100 e 1000,
ou entre um e 1000,

2109
01:32:56,620 --> 01:32:59,940
porém muitos valores aleatórios que você quer
anexar para o final desse candidato.

2110
01:32:59,940 --> 01:33:01,330
>> E o que eu realmente feito, então?

2111
01:33:01,330 --> 01:33:05,830
Se eu estou usando o ID como candidato
o balde para agregar votos,

2112
01:33:05,830 --> 01:33:08,780
se eu adicionei um aleatório
número para o fim de que,

2113
01:33:08,780 --> 01:33:12,000
Eu criei agora 10 baldes, um
centenas de baldes, mil baldes

2114
01:33:12,000 --> 01:33:14,160
que eu estou agregando votos de diâmetro.

2115
01:33:14,160 --> 01:33:18,030
>> Então, eu tenho milhões e milhões,
e milhões de registros vindo

2116
01:33:18,030 --> 01:33:22,050
Para estes candidatos, agora estou espalhando
os votos em todo A_1 Candidate

2117
01:33:22,050 --> 01:33:24,630
através A_100 Candidato, porque
cada vez que um voto vem,

2118
01:33:24,630 --> 01:33:26,530
Eu estou gerando uma aleatório
valor entre um e 100.

2119
01:33:26,530 --> 01:33:29,446
Eu estou aderência que na extremidade do
candidato que pessoa de votar.

2120
01:33:29,446 --> 01:33:31,120
Eu estou jogando-o em que balde.

2121
01:33:31,120 --> 01:33:33,910
>> Agora na parte de trás, eu sei
que eu tenho mais de cem baldes.

2122
01:33:33,910 --> 01:33:36,350
Então, quando eu quiser ir em frente
e agregar os votos,

2123
01:33:36,350 --> 01:33:38,244
Eu li a partir de todos esses baldes.

2124
01:33:38,244 --> 01:33:39,160
Então eu ir em frente e adicionar.

2125
01:33:39,160 --> 01:33:42,410
E então eu a dispersão reunir
onde eu sair e dizer hey,

2126
01:33:42,410 --> 01:33:45,399
Você sabe o que, esta chave do candidato
espaços é mais de cem baldes.

2127
01:33:45,399 --> 01:33:47,940
Vou reunir todas as
votos dos cem baldes.

2128
01:33:47,940 --> 01:33:49,981
Eu estou indo para agregar
-los e eu vou dizer,

2129
01:33:49,981 --> 01:33:53,830
Um candidato tem agora
contagem total de votos de x.

2130
01:33:53,830 --> 01:33:55,690
>> Agora, tanto o write
consulta ea consulta de leitura

2131
01:33:55,690 --> 01:33:58,160
são bem distribuídos
porque eu estou escrevendo em frente

2132
01:33:58,160 --> 01:34:00,320
e eu estou lendo em centenas de chaves.

2133
01:34:00,320 --> 01:34:03,500
Eu não estou escrevendo e
leitura através de uma chave agora.

2134
01:34:03,500 --> 01:34:04,950
Então, isso é um grande teste padrão.

2135
01:34:04,950 --> 01:34:08,090
>> Este é provavelmente um realmente
do projeto o mais importante

2136
01:34:08,090 --> 01:34:10,420
padrões para a escala em NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Você vai ver este tipo de
padrão de design em cada sabor.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, isso não acontece
importa, todos nós temos que fazer isso.

2139
01:34:19,100 --> 01:34:21,840
Porque quando você está lidando
com aqueles enormes agregações,

2140
01:34:21,840 --> 01:34:26,650
você tem que descobrir uma maneira de
espalhá-los para fora através de baldes.

2141
01:34:26,650 --> 01:34:29,512
Portanto, esta é a maneira de fazer isso.

2142
01:34:29,512 --> 01:34:31,220
Tudo bem, então o que
você está fazendo agora

2143
01:34:31,220 --> 01:34:35,252
é que você está trocando de leitura
custo para gravação escalabilidade.

2144
01:34:35,252 --> 01:34:37,085
O custo de minha leitura é
um pouco mais complexo

2145
01:34:37,085 --> 01:34:40,220
e eu tenho que ir ler a partir de um
centenas de baldes em vez de um.

2146
01:34:40,220 --> 01:34:41,310
Mas eu sou capaz de escrever.

2147
01:34:41,310 --> 01:34:44,860
E o meu rendimento, minha escrita
throughput é incrível.

2148
01:34:44,860 --> 01:34:49,450
Portanto, é geralmente um valioso
técnica para escalar DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
ou qualquer banco de dados NoSQL para esse assunto.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Então, nós descobrimos como escalá-lo.

2152
01:34:55,240 --> 01:34:56,930
E nós figuramos como
eliminar nossas teclas de atalho.

2153
01:34:56,930 --> 01:34:57,820
E isso é fantástico.

2154
01:34:57,820 --> 01:34:58,960
E nós temos este sistema agradável.

2155
01:34:58,960 --> 01:35:02,043
E isso nos deu muito correto votação
porque temos registro voto de-dupe.

2156
01:35:02,043 --> 01:35:03,130
Ele é construído em DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Falamos sobre direitos condicionais.

2158
01:35:05,380 --> 01:35:08,170
>> Quando um eleitor entra, puts
uma inserção na tabela,

2159
01:35:08,170 --> 01:35:11,220
eles inserir com a sua identificação do eleitor,
se tentarem inserir outra votação,

2160
01:35:11,220 --> 01:35:13,320
Eu faço uma gravação condicional.

2161
01:35:13,320 --> 01:35:16,960
Digam apenas escrever este
se este não existe.

2162
01:35:16,960 --> 01:35:19,270
Assim, logo que eu vejo que
que a votação de bater na mesa,

2163
01:35:19,270 --> 01:35:20,460
ninguém mais vai ser
capaz de colocar o seu voto no.

2164
01:35:20,460 --> 01:35:21,634
E isso é fantástico.

2165
01:35:21,634 --> 01:35:23,550
E nós estamos incrementando
nossos contadores de candidatos.

2166
01:35:23,550 --> 01:35:25,466
E nós estamos fazendo nosso
demografia e tudo isso.

2167
01:35:25,466 --> 01:35:29,110
Mas o que acontece se o meu
aplicação cai?

2168
01:35:29,110 --> 01:35:31,350
Agora, de repente votos
estão chegando, e eu

2169
01:35:31,350 --> 01:35:34,840
Não sei se eles estão sendo processados
em minhas análises e demografia

2170
01:35:34,840 --> 01:35:36,040
anymore.

2171
01:35:36,040 --> 01:35:38,462
E quando a aplicação
volta para cima, como

2172
01:35:38,462 --> 01:35:41,420
diabos eu sei o que tenho de votos
foi processado e por onde eu começo?

2173
01:35:41,420 --> 01:35:44,530
>> Portanto, este é um problema real quando você
começar a olhar para esse tipo de cenário.

2174
01:35:44,530 --> 01:35:45,571
E como é que vamos resolver isso?

2175
01:35:45,571 --> 01:35:48,070
Nós resolvê-lo com o que nós
chamar DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Streams é um tempo de pedidos e
log de alterações particionado de cada acesso

2177
01:35:53,470 --> 01:35:55,700
para a mesa, cada gravação
acesso à tabela.

2178
01:35:55,700 --> 01:35:58,810
Quaisquer dados que está escrito à
tabela mostra-se no fluxo.

2179
01:35:58,810 --> 01:36:01,815
>> É basicamente uma fila de 24 horas.

2180
01:36:01,815 --> 01:36:03,690
Itens bater o córrego,
eles vivem por 24 horas.

2181
01:36:03,690 --> 01:36:05,990
Eles podem ser lidas múltiplas vezes.

2182
01:36:05,990 --> 01:36:09,400
Garantido para ser entregue
apenas uma vez para o fluxo,

2183
01:36:09,400 --> 01:36:11,180
pode ser lido n número de vezes.

2184
01:36:11,180 --> 01:36:14,910
Então porém muitos processos você deseja
consumir esses dados, você pode consumi-lo.

2185
01:36:14,910 --> 01:36:16,350
Ele aparecerá a cada atualização.

2186
01:36:16,350 --> 01:36:18,455
Cada gravação será apenas
aparecer uma vez no fluxo.

2187
01:36:18,455 --> 01:36:20,621
Então você não precisa se preocupar
sobre o processamento de duas vezes

2188
01:36:20,621 --> 01:36:22,500
a partir do mesmo processo.

2189
01:36:22,500 --> 01:36:25,350
>> É estritamente ordenada por item.

2190
01:36:25,350 --> 01:36:28,180
Quando dizemos tempo
ordenada e particionado,

2191
01:36:28,180 --> 01:36:30,680
você vai ver por partição no fluxo.

2192
01:36:30,680 --> 01:36:33,169
Você vai ver os itens, atualizações em ordem.

2193
01:36:33,169 --> 01:36:35,210
Nós não estamos garantindo
sobre o fluxo que você é

2194
01:36:35,210 --> 01:36:40,240
indo para obter todas as transações
na ordem em todo itens.

2195
01:36:40,240 --> 01:36:42,440
>> Então córregos são idempotent.

2196
01:36:42,440 --> 01:36:44,037
Será que todos nós sabemos o que significa idempotent?

2197
01:36:44,037 --> 01:36:46,620
Idempotente significa que você pode fazê-lo
mais, e mais, e outra vez.

2198
01:36:46,620 --> 01:36:48,200
O resultado vai ser o mesmo.

2199
01:36:48,200 --> 01:36:49,991
>> Streams são idempotent,
mas eles têm que ser

2200
01:36:49,991 --> 01:36:54,860
reproduzidos a partir do ponto de partida,
onde quer que você escolher, até o fim,

2201
01:36:54,860 --> 01:36:57,950
ou eles não vão resultar
nos mesmos valores.

2202
01:36:57,950 --> 01:36:59,727
>> A mesma coisa com MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB tem uma construção
eles chamam a oplog.

2204
01:37:01,560 --> 01:37:04,140
É a mesma construção exata.

2205
01:37:04,140 --> 01:37:06,500
Muitos bancos de dados NoSQL
tem esta construção.

2206
01:37:06,500 --> 01:37:08,790
Eles usá-lo para fazer coisas
como replicação, que

2207
01:37:08,790 --> 01:37:10,475
é exatamente o que fazemos com os córregos.

2208
01:37:10,475 --> 01:37:12,350
AUDIÊNCIA: Talvez um
pergunta herética, mas você

2209
01:37:12,350 --> 01:37:13,975
falar sobre aplicativos fazendo derrubou um assim por diante.

2210
01:37:13,975 --> 01:37:16,089
São fluxos garantido para
Nunca possivelmente ir para baixo?

2211
01:37:16,089 --> 01:37:18,630
RICK HOULIHAN: Sim, córregos
são garantidos para nunca mais ir para baixo.

2212
01:37:18,630 --> 01:37:21,040
Nós administramos a infra-estrutura
atrás. córregos automaticamente

2213
01:37:21,040 --> 01:37:22,498
implantar em seu grupo Auto Scaling.

2214
01:37:22,498 --> 01:37:25,910
Nós vamos passar por um pouco
pouco sobre o que acontece.

2215
01:37:25,910 --> 01:37:30,060
>> Eu não deveria dizer que eles não são
garantido que nunca ir para baixo.

2216
01:37:30,060 --> 01:37:33,110
Os elementos são garantidos
para aparecer no córrego.

2217
01:37:33,110 --> 01:37:36,740
E o fluxo será acessível.

2218
01:37:36,740 --> 01:37:40,580
Então, o que vai para baixo ou volta
up, que acontece por baixo.

2219
01:37:40,580 --> 01:37:43,844
Ele covers-- é OK.

2220
01:37:43,844 --> 01:37:46,260
Tudo bem, então você começa diferente
tipos de vista fora da tela.

2221
01:37:46,260 --> 01:37:51,040
Os tipos de vista que são importantes para a
programador normalmente é, o que era?

2222
01:37:51,040 --> 01:37:52,370
Recebo a antiga visão.

2223
01:37:52,370 --> 01:37:55,630
Quando uma atualização atinge a mesa, ele vai
empurrar o velho vista para o fluxo

2224
01:37:55,630 --> 01:38:02,070
que os dados possam arquivar ou mudança
controle, identificação mudança, mudança

2225
01:38:02,070 --> 01:38:03,600
gestão.

2226
01:38:03,600 --> 01:38:07,160
>> A nova imagem, o que é agora, depois de
a atualização, que é um outro tipo de visão

2227
01:38:07,160 --> 01:38:07,660
você pode ter.

2228
01:38:07,660 --> 01:38:09,660
Você pode obter tanto as imagens antigas e novas.

2229
01:38:09,660 --> 01:38:10,660
Talvez eu quero os dois.

2230
01:38:10,660 --> 01:38:11,790
Eu quero ver o que era.

2231
01:38:11,790 --> 01:38:13,290
Eu quero ver o que mudou para.

2232
01:38:13,290 --> 01:38:15,340
>> Eu tenho um tipo de conformidade
do processo que corre.

2233
01:38:15,340 --> 01:38:17,430
Ele precisa verificar se
quando essas coisas mudam,

2234
01:38:17,430 --> 01:38:21,840
que eles estão dentro de certos limites
ou dentro de certos parâmetros.

2235
01:38:21,840 --> 01:38:23,840
>> E então talvez eu só
precisa saber o que mudou.

2236
01:38:23,840 --> 01:38:26,240
Eu não me importo o que item foi modificado.

2237
01:38:26,240 --> 01:38:28,580
Eu não precisa precisa saber
que atributos alterado.

2238
01:38:28,580 --> 01:38:30,882
Eu só preciso saber que
os itens estão sendo tocadas.

2239
01:38:30,882 --> 01:38:33,340
Então esses são os tipos de pontos de vista
que você sair do córrego

2240
01:38:33,340 --> 01:38:35,960
e você pode interagir com.

2241
01:38:35,960 --> 01:38:37,840
>> O aplicativo que
consome a corrente,

2242
01:38:37,840 --> 01:38:39,298
este é o tipo de forma como isto funciona.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB cliente pedir para
enviar dados para as tabelas.

2244
01:38:42,570 --> 01:38:44,750
Streams implantar no que chamamos de cacos.

2245
01:38:44,750 --> 01:38:47,380
Shards são escalados
independentemente da mesa.

2246
01:38:47,380 --> 01:38:50,660
Eles não se alinham completamente
para as partições de sua mesa.

2247
01:38:50,660 --> 01:38:52,540
E a razão pela qual é
porque eles se alinham

2248
01:38:52,540 --> 01:38:55,430
com a capacidade, a actual
capacidade da tabela.

2249
01:38:55,430 --> 01:38:57,600
>> Eles implantar em sua
próprio grupo escalonamento auto,

2250
01:38:57,600 --> 01:39:00,800
e eles começam a girar para fora, dependendo
de quantas gravações estão chegando,

2251
01:39:00,800 --> 01:39:03,090
quantos reads-- realmente é escreve.

2252
01:39:03,090 --> 01:39:05,820
Não há nenhuma reads-- mas como
muitas gravações estão chegando.

2253
01:39:05,820 --> 01:39:08,200
>> E, em seguida, na parte de trás
fim, temos o que

2254
01:39:08,200 --> 01:39:11,390
chamar um KCL, ou Biblioteca de Kinesis Cliente.

2255
01:39:11,390 --> 01:39:19,190
Kinesis é um fluxo de dados
tecnologia de processamento da Amazônia.

2256
01:39:19,190 --> 01:39:22,040
E córregos é construído sobre isso.

2257
01:39:22,040 --> 01:39:25,670
>> Então você usa um KCL habilitado
aplicação para ler o fluxo.

2258
01:39:25,670 --> 01:39:28,752
A Biblioteca Kinesis cliente, na verdade,
gerencia os trabalhadores para você.

2259
01:39:28,752 --> 01:39:30,460
E ele também faz alguns
coisas interessantes.

2260
01:39:30,460 --> 01:39:35,630
Ele vai criar algumas tabelas up
em sua tabela DynamoDB

2261
01:39:35,630 --> 01:39:38,410
para controlar quais itens
ter sido processada.

2262
01:39:38,410 --> 01:39:41,190
Então, dessa maneira, se ele cai para trás, se
ele cai e vem e fica

2263
01:39:41,190 --> 01:39:45,570
estava de volta, pode determinar onde
foi no processamento da corrente.

2264
01:39:45,570 --> 01:39:48,360
>> Isso é muito importante quando
você está falando de replicação.

2265
01:39:48,360 --> 01:39:50,350
Eu preciso saber o que
dados foi foi processada

2266
01:39:50,350 --> 01:39:52,810
e os dados que ainda tem de ser processada.

2267
01:39:52,810 --> 01:39:57,380
Assim, a biblioteca de KCL para fluxos vai
dar-lhe um monte de que a funcionalidade.

2268
01:39:57,380 --> 01:39:58,990
Ela cuida de todas as tarefas domésticas.

2269
01:39:58,990 --> 01:40:01,140
Ele levanta-se um trabalhador para cada fragmento.

2270
01:40:01,140 --> 01:40:04,620
Ela cria uma tabela administrativa
para cada fragmento, para cada trabalhador.

2271
01:40:04,620 --> 01:40:07,560
E como os trabalhadores fogo,
eles mantêm essas tabelas

2272
01:40:07,560 --> 01:40:10,510
assim você sabe este registro
foi lido e processado.

2273
01:40:10,510 --> 01:40:13,850
E, em seguida, dessa forma, se o processo
morre e voltar a ficar online,

2274
01:40:13,850 --> 01:40:17,940
ele pode retomar exatamente onde ele decolou.

2275
01:40:17,940 --> 01:40:20,850
>> Então, nós usamos isso para
replicação cross-região.

2276
01:40:20,850 --> 01:40:24,680
Muitos clientes têm a necessidade de
mover dados ou partes de suas tabelas de dados

2277
01:40:24,680 --> 01:40:25,920
em torno de diferentes regiões.

2278
01:40:25,920 --> 01:40:29,230
Existem nove regiões
tudo em volta do mundo.

2279
01:40:29,230 --> 01:40:32,100
Portanto, pode haver um eu need--
pode ter usuários na Ásia, os usuários

2280
01:40:32,100 --> 01:40:34,150
na Costa Leste dos Estados Unidos.

2281
01:40:34,150 --> 01:40:38,980
Eles têm que dados diferentes
necessita de ser distribuído localmente.

2282
01:40:38,980 --> 01:40:42,510
E talvez um usuário voa de
Ásia para os Estados Unidos,

2283
01:40:42,510 --> 01:40:45,020
e eu quero replicar
seus dados com ele.

2284
01:40:45,020 --> 01:40:49,340
Então, quando ele sai do avião, ele tem
uma boa experiência usando seu aplicativo móvel.

2285
01:40:49,340 --> 01:40:52,360
>> Você pode usar o cross-região
biblioteca de replicação para fazer isso.

2286
01:40:52,360 --> 01:40:55,730
Basicamente, temos
fornecida duas tecnologias.

2287
01:40:55,730 --> 01:40:59,400
Um é um aplicativo de console que puder
levantar-se sobre o seu próprio instância EC2.

2288
01:40:59,400 --> 01:41:01,240
Ele é executado a replicação puro.

2289
01:41:01,240 --> 01:41:02,720
E, em seguida, deu-lhe a biblioteca.

2290
01:41:02,720 --> 01:41:06,070
A biblioteca pode ser usada para construir
seu próprio aplicativo se você

2291
01:41:06,070 --> 01:41:10,740
quero fazer coisas malucas com que data--
filtro, replicar apenas uma parte dela,

2292
01:41:10,740 --> 01:41:14,120
rodar os dados, movê-lo para um
tabela diferente, assim por diante e assim por diante.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Então, esse é o tipo de o que parece.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams pode ser
processadas pelo que chamamos de Lambda.

2296
01:41:23,690 --> 01:41:27,394
Mencionamos um pouco sobre o evento
arquiteturas de aplicativos acionados.

2297
01:41:27,394 --> 01:41:28,810
Lambda é um componente fundamental do que isso.

2298
01:41:28,810 --> 01:41:32,840
Lambda é o código que dispara na demanda
em resposta a um acontecimento particular.

2299
01:41:32,840 --> 01:41:36,020
Um desses eventos pode ser um
registro que aparece no stream.

2300
01:41:36,020 --> 01:41:39,100
Se um registro aparece no córrego,
vamos chamar essa função Java.

2301
01:41:39,100 --> 01:41:44,980
Bem, este é JavaScript, e Lambda
suporta Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
e em breve apoiar
outras línguas também.

2303
01:41:47,820 --> 01:41:50,940
E escusado será dizer, é puro código.

2304
01:41:50,940 --> 01:41:53,610
escrever em Java, você define uma classe.

2305
01:41:53,610 --> 01:41:55,690
Você aperta o JAR-se em Lambda.

2306
01:41:55,690 --> 01:42:00,200
E então você especificar qual classe
a chamada em resposta ao qual o evento.

2307
01:42:00,200 --> 01:42:04,770
E, em seguida, a infra-estrutura do Lambda
por trás que irá executar esse código.

2308
01:42:04,770 --> 01:42:06,730
>> Esse código pode processar
registros fora do córrego.

2309
01:42:06,730 --> 01:42:08,230
Ele pode fazer o que quiser com ele.

2310
01:42:08,230 --> 01:42:11,650
Neste exemplo em particular, todos nós somos
fazendo realmente está registrando os atributos.

2311
01:42:11,650 --> 01:42:13,480
Mas este é apenas código.

2312
01:42:13,480 --> 01:42:15,260
Código pode fazer qualquer coisa, certo?

2313
01:42:15,260 --> 01:42:16,600
>> Então, você pode rodar esses dados.

2314
01:42:16,600 --> 01:42:18,160
Você pode criar uma visão derivada.

2315
01:42:18,160 --> 01:42:21,160
Se é uma estrutura do documento,
você pode achatar a estrutura.

2316
01:42:21,160 --> 01:42:24,300
Você pode criar índices alternativos.

2317
01:42:24,300 --> 01:42:27,100
Todos os tipos de coisas que você pode
fazer com os córregos DynamoDB.

2318
01:42:27,100 --> 01:42:28,780
>> E realmente, isso é o que parece.

2319
01:42:28,780 --> 01:42:29,940
Então você obter essas atualizações chegando.

2320
01:42:29,940 --> 01:42:31,190
Eles estão saindo da cadeia.

2321
01:42:31,190 --> 01:42:32,720
Eles são lidos pela função Lambda.

2322
01:42:32,720 --> 01:42:37,480
Eles estão girando os dados e
empurrando-se em tabelas de derivativos,

2323
01:42:37,480 --> 01:42:42,200
notificando sistemas externos de mudança,
e enviar dados em ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Nós conversamos sobre como colocar o cache
na frente da base de dados para que as vendas

2325
01:42:45,900 --> 01:42:46,450
cenário.

2326
01:42:46,450 --> 01:42:50,049
Bem, o que acontece se eu
atualizar a descrição do item?

2327
01:42:50,049 --> 01:42:52,340
Bem, se eu tivesse um Lambda
função de execução em que a tabela,

2328
01:42:52,340 --> 01:42:55,490
se eu atualizar a descrição do item, ele vai
pegar o registro fora do córrego,

2329
01:42:55,490 --> 01:42:58,711
e ele vai atualizar o ElastiCache
exemplo, com os novos dados.

2330
01:42:58,711 --> 01:43:00,460
Então, isso é um monte de
o que fazemos com Lambda.

2331
01:43:00,460 --> 01:43:02,619
É código de cola, conectores.

2332
01:43:02,619 --> 01:43:04,410
E ele realmente dá
a capacidade de lançar

2333
01:43:04,410 --> 01:43:07,930
e para executar aplicativos muito complexos
sem um servidor dedicado

2334
01:43:07,930 --> 01:43:10,371
infra-estrutura, o que é muito legal.

2335
01:43:10,371 --> 01:43:13,100
>> Então, vamos voltar ao nosso
em tempo real arquitetura votação.

2336
01:43:13,100 --> 01:43:17,984
Esta é uma nova e melhorada com o nosso
riachos e KCL habilitado aplicativo.

2337
01:43:17,984 --> 01:43:20,150
Mesmo que antes, nós podemos
lidar com qualquer escala de eleição.

2338
01:43:20,150 --> 01:43:21,100
Nós gostamos disso.

2339
01:43:21,100 --> 01:43:24,770
Nós estamos fazendo a coleta de dispersão
em vários baldes.

2340
01:43:24,770 --> 01:43:26,780
Temos de bloqueio otimista acontecendo.

2341
01:43:26,780 --> 01:43:30,192
Nós podemos manter os nossos eleitores
de mudar seus votos.

2342
01:43:30,192 --> 01:43:31,400
Eles só podem votar apenas uma vez.

2343
01:43:31,400 --> 01:43:32,880
Isso é fantástico.

2344
01:43:32,880 --> 01:43:35,895
Tolerância a falhas em tempo real,
agregação escalável agora.

2345
01:43:35,895 --> 01:43:38,270
Se a coisa cai, ele
sabe onde reiniciar-se

2346
01:43:38,270 --> 01:43:41,300
quando se trata back-up porque
estamos usando o aplicativo KCL.

2347
01:43:41,300 --> 01:43:45,700
E então nós também podemos usar isso
Aplicação KCL para enviar dados para fora

2348
01:43:45,700 --> 01:43:48,820
para redshift para outro
analytics App ou uso

2349
01:43:48,820 --> 01:43:51,990
os MapReduce elástico para executar
em tempo real agregações de streaming fora

2350
01:43:51,990 --> 01:43:53,180
de que os dados.

2351
01:43:53,180 --> 01:43:55,480
>> Então, essas são coisas que nós
não falamos sobre muita coisa.

2352
01:43:55,480 --> 01:43:57,375
Mas eles são adicional
tecnologias que vêm

2353
01:43:57,375 --> 01:44:00,310
de suportar quando você está olhando
nestes tipos de cenários.

2354
01:44:00,310 --> 01:44:03,160
>> Tudo bem, então isso é sobre
analytics com DynamoDB Streams.

2355
01:44:03,160 --> 01:44:05,340
Você pode coletar de-dupe
dados, fazer todos os tipos

2356
01:44:05,340 --> 01:44:09,490
de coisas legais, dados agregados em
memória, criar essas tabelas de derivativos.

2357
01:44:09,490 --> 01:44:13,110
Isso é um caso de uso enorme
que um monte de clientes

2358
01:44:13,110 --> 01:44:16,950
está envolvido com, tomando a nested
propriedades desses documentos JSON

2359
01:44:16,950 --> 01:44:18,946
e criação de índices adicionais.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Nós estamos no fim.

2362
01:44:23,150 --> 01:44:26,689
Obrigado por suportar comigo.

2363
01:44:26,689 --> 01:44:28,480
Então vamos falar sobre
arquitetura de referência.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB fica no meio dos assim
grande parte da infraestrutura da AWS.

2365
01:44:33,440 --> 01:44:37,090
Basicamente, você pode ligá-lo
até o que quiser.

2366
01:44:37,090 --> 01:44:45,600
Os aplicativos criados usando Dynamo incluem
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
empurrar os dados para fora em Elastic
MapReduce, importação e exportação de DynamoDB

2368
01:44:49,890 --> 01:44:52,370
em S3, todos os tipos de fluxos de trabalho.

2369
01:44:52,370 --> 01:44:54,120
Mas, provavelmente, a melhor
coisa para falar,

2370
01:44:54,120 --> 01:44:56,119
e isso é o que é realmente
interessante é quando nós

2371
01:44:56,119 --> 01:44:58,350
falar sobre aplicativos orientados a eventos.

2372
01:44:58,350 --> 01:45:00,300
>> Este é um exemplo de
um projeto interno

2373
01:45:00,300 --> 01:45:04,850
que temos onde nós estamos, na verdade,
publicação de reunir os resultados da pesquisa.

2374
01:45:04,850 --> 01:45:07,700
Assim, em um link de e-mail que
nós enviamos para fora, lá vai

2375
01:45:07,700 --> 01:45:11,350
ser um pequeno estalo ligação dizendo
aqui para responder à pesquisa.

2376
01:45:11,350 --> 01:45:14,070
E quando uma pessoa clica
esse link, o que acontece

2377
01:45:14,070 --> 01:45:18,020
é que eles puxar para baixo um seguro
Formulário do exame de código HTML S3.

2378
01:45:18,020 --> 01:45:18,980
Não há nenhum servidor.

2379
01:45:18,980 --> 01:45:20,600
Este é apenas um objeto S3.

2380
01:45:20,600 --> 01:45:22,770
>> Essa forma surge,
carrega-se no navegador.

2381
01:45:22,770 --> 01:45:24,240
Tem Backbone.

2382
01:45:24,240 --> 01:45:30,160
Tem complexo JavaScript
que ele está correndo.

2383
01:45:30,160 --> 01:45:33,557
Por isso é aplicação muito rico
em execução no navegador do cliente.

2384
01:45:33,557 --> 01:45:36,390
Eles não sabem que eles não são
interagindo com um servidor back-end.

2385
01:45:36,390 --> 01:45:38,220
Neste ponto, é tudo browser.

2386
01:45:38,220 --> 01:45:41,780
>> Eles publicam os resultados para o
chamamos a Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway é simplesmente uma API web
que você pode definir e ligar

2388
01:45:46,270 --> 01:45:47,760
para o que quiser.

2389
01:45:47,760 --> 01:45:50,990
Neste caso particular, estamos
ligado a uma função Lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Assim, a minha operação POST é
acontecendo com nenhum servidor.

2391
01:45:54,797 --> 01:45:56,380
Basicamente gateway de API que se senta lá.

2392
01:45:56,380 --> 01:45:58,770
Ele me custa nada até que as pessoas
comece a postar a ele, certo?

2393
01:45:58,770 --> 01:46:00,269
A função Lambda apenas se senta lá.

2394
01:46:00,269 --> 01:46:03,760
E isso me custa nada até
as pessoas começam a bater.

2395
01:46:03,760 --> 01:46:07,270
Assim você pode ver, como o volume
aumentos, que é quando as acusações vir.

2396
01:46:07,270 --> 01:46:09,390
Eu não estou executando um servidor 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Então eu puxo a forma
para baixo para fora do balde,

2398
01:46:12,310 --> 01:46:15,719
e eu postar por meio da API
Porta de entrada para a função Lambda.

2399
01:46:15,719 --> 01:46:17,510
E, em seguida, o Lambda
função diz, você sabe

2400
01:46:17,510 --> 01:46:20,600
o que, eu tenho algumas PIIs, alguns
informação pessoalmente identificável

2401
01:46:20,600 --> 01:46:21,480
nestas respostas.

2402
01:46:21,480 --> 01:46:23,020
Eu tenho comentários vindos de usuários.

2403
01:46:23,020 --> 01:46:24,230
Tenho endereços de email.

2404
01:46:24,230 --> 01:46:26,190
Eu tenho nomes de usuários.

2405
01:46:26,190 --> 01:46:27,810
>> Deixe-me dividir este fora.

2406
01:46:27,810 --> 01:46:30,280
Eu estou indo para gerar algum
metadados off esse registro.

2407
01:46:30,280 --> 01:46:32,850
E eu estou indo para empurrar o
metadados em DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
E eu poderia criptografar todos os dados
e empurrá-lo para DynamoDB se eu quiser.

2409
01:46:36,059 --> 01:46:38,600
Mas é mais fácil para mim, neste
caso de uso, para ir em frente uma palavra a dizer,

2410
01:46:38,600 --> 01:46:42,800
Eu estou indo para empurrar os dados em bruto
em um balde S3 encriptada.

2411
01:46:42,800 --> 01:46:47,240
Então eu usar construído no lado do servidor S3
criptografia e gerenciamento de chaves da Amazon

2412
01:46:47,240 --> 01:46:51,600
Serviço para que eu tenha uma chave que
pode rodar em um intervalo regular,

2413
01:46:51,600 --> 01:46:55,010
e eu posso proteger esses dados PII
como parte de todo este fluxo de trabalho.

2414
01:46:55,010 --> 01:46:55,870
>> Então o que foi que eu fiz?

2415
01:46:55,870 --> 01:47:00,397
Acabei implantado um todo
aplicação, e eu não tenho servidor.

2416
01:47:00,397 --> 01:47:02,980
Então é o que aplicação dirigida evento
arquitetura faz para você.

2417
01:47:02,980 --> 01:47:05,730
>> Agora, se você pensar sobre
o caso de uso para isto--

2418
01:47:05,730 --> 01:47:08,730
temos outros clientes que eu estou falando
a arquitetura exata sobre o que

2419
01:47:08,730 --> 01:47:14,560
executar fenomenalmente grandes campanhas, que
está olhando para isso e vai, oh meu.

2420
01:47:14,560 --> 01:47:17,840
Porque agora, eles podem
basicamente empurrá-lo para fora lá,

2421
01:47:17,840 --> 01:47:21,900
deixe que a campanha apenas sentar
lá até que ele lança, e não

2422
01:47:21,900 --> 01:47:24,400
tem que se preocupar um figo sobre
que tipo de infra-estrutura

2423
01:47:24,400 --> 01:47:26,120
vai estar lá para apoiá-lo.

2424
01:47:26,120 --> 01:47:28,600
E, em seguida, logo que
que a campanha é feita,

2425
01:47:28,600 --> 01:47:31,520
é como a infra-estrutura
apenas vai embora imediatamente

2426
01:47:31,520 --> 01:47:33,680
porque não há realmente
há infra-estrutura.

2427
01:47:33,680 --> 01:47:35,660
É código apenas que se sente em Lambda.

2428
01:47:35,660 --> 01:47:38,560
É apenas dados que fica no DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
É uma forma incrível
para construir aplicações.

2430
01:47:41,340 --> 01:47:43,970
>> AUDIÊNCIA: Então é mais
efémero do que seria

2431
01:47:43,970 --> 01:47:45,740
se ele foi armazenado em um servidor real?

2432
01:47:45,740 --> 01:47:46,823
>> RICK HOULIHAN: Absolutamente.

2433
01:47:46,823 --> 01:47:49,190
Porque essa instância de servidor
teria de ser um 7/24.

2434
01:47:49,190 --> 01:47:51,954
Tem que estar disponível para
alguém para responder.

2435
01:47:51,954 --> 01:47:52,620
Bem, adivinhem?

2436
01:47:52,620 --> 01:47:55,410
S3 é disponível 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 responde sempre.

2438
01:47:57,100 --> 01:47:59,320
E S3 é muito, muito bom
a servir-se objetos.

2439
01:47:59,320 --> 01:48:02,590
Esses objetos podem ser arquivos HTML, ou
Arquivos JavaScript, ou o que você quiser.

2440
01:48:02,590 --> 01:48:07,430
Você pode executar aplicações web muito ricas
fora de baldes S3, e as pessoas fazem.

2441
01:48:07,430 --> 01:48:10,160
>> E então essa é a idéia aqui
é para ficar longe do caminho

2442
01:48:10,160 --> 01:48:11,270
estamos acostumados a pensar sobre isso.

2443
01:48:11,270 --> 01:48:14,270
Todos nós costumava pensar em
termos de servidores e anfitriões.

2444
01:48:14,270 --> 01:48:16,580
Não é sobre isso mais.

2445
01:48:16,580 --> 01:48:19,310
Trata-se de infra-estrutura como código.

2446
01:48:19,310 --> 01:48:22,470
Implantar o código para a nuvem e
deixe a nuvem executá-lo para você.

2447
01:48:22,470 --> 01:48:24,980
E é isso que a AWS está tentando fazer.

2448
01:48:24,980 --> 01:48:29,690
>> AUDIÊNCIA: sua caixa de ouro no meio Então,
do API Gateway não é servidor-like,

2449
01:48:29,690 --> 01:48:30,576
mas em vez disso é apenas--

2450
01:48:30,576 --> 01:48:32,850
>> RICK HOULIHAN: Você pode pensar
nisso como fachada servidor.

2451
01:48:32,850 --> 01:48:38,040
Tudo o que é que vai demorar um HTTP
solicitar e mapeá-la para outro processo.

2452
01:48:38,040 --> 01:48:39,192
Isso é tudo que ele faz.

2453
01:48:39,192 --> 01:48:41,525
E, neste caso, estamos mapeando
-lo para uma função lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Tudo bem, então isso é tudo que eu tenho.

2456
01:48:45,410 --> 01:48:46,190
Muito obrigado.

2457
01:48:46,190 --> 01:48:46,800
Eu agradeço.

2458
01:48:46,800 --> 01:48:48,100
Eu sei que nós queremos um pouco ao longo do tempo.

2459
01:48:48,100 --> 01:48:49,980
E espero que vocês tem
um pouco de informação

2460
01:48:49,980 --> 01:48:51,410
que você pode tirar hoje.

2461
01:48:51,410 --> 01:48:53,520
E peço desculpa se eu fui
sobre algumas de suas cabeças,

2462
01:48:53,520 --> 01:48:56,697
mas há um monte de bom
conhecimento fundamental fundamentais

2463
01:48:56,697 --> 01:48:58,280
que eu acho que é muito valioso para você.

2464
01:48:58,280 --> 01:48:59,825
Então, obrigado por me receber.

2465
01:48:59,825 --> 01:49:00,325
[Aplausos]

2466
01:49:00,325 --> 01:49:02,619
AUDIÊNCIA: [inaudível]
é quando você estava dizendo

2467
01:49:02,619 --> 01:49:05,160
você tinha que ir através da coisa
a partir do início ao fim

2468
01:49:05,160 --> 01:49:07,619
para obter os valores corretos
ou os mesmos valores,

2469
01:49:07,619 --> 01:49:09,410
como é que os valores
mudar se [inaudível].

2470
01:49:09,410 --> 01:49:10,480
>> RICK HOULIHAN: Oh, idempotentes?

2471
01:49:10,480 --> 01:49:11,800
Como os valores mudam?

2472
01:49:11,800 --> 01:49:15,180
Bem, porque se eu não correr
todo o caminho até o fim,

2473
01:49:15,180 --> 01:49:19,770
então eu não sei o que muda
foram feitas na última milha.

2474
01:49:19,770 --> 01:49:22,144
Não vai ser a
mesmos dados que o que eu vi.

2475
01:49:22,144 --> 01:49:24,560
AUDIÊNCIA: Ah, então você apenas
não ter chegado a entrada inteira.

2476
01:49:24,560 --> 01:49:24,770
RICK HOULIHAN: Certo.

2477
01:49:24,770 --> 01:49:26,895
Você tem que ir do começo
ao fim, e então é

2478
01:49:26,895 --> 01:49:29,280
vai ser um estado consistente.

2479
01:49:29,280 --> 01:49:31,520
Frio.

2480
01:49:31,520 --> 01:49:35,907
>> AUDIÊNCIA: Então você nos mostrou DynamoDB
pode fazer documento ou o valor da chave.

2481
01:49:35,907 --> 01:49:38,740
E nós passamos muito tempo no
valor-chave com um hash e as formas

2482
01:49:38,740 --> 01:49:40,005
para lançá-lo ao redor.

2483
01:49:40,005 --> 01:49:43,255
Quando você olhou para essas tabelas, é que
deixando para trás a abordagem documento?

2484
01:49:43,255 --> 01:49:44,600
>> RICK HOULIHAN: eu não faria
dizer deixá-lo para trás.

2485
01:49:44,600 --> 01:49:45,855
>> AUDIÊNCIA: Eles foram separados de as--

2486
01:49:45,855 --> 01:49:49,140
>> RICK HOULIHAN: Com o documento
abordagem, o tipo de documento em DynamoDB

2487
01:49:49,140 --> 01:49:50,880
é apenas pensar em como outro atributo.

2488
01:49:50,880 --> 01:49:53,560
É um atributo que contém
uma estrutura de dados hierárquica.

2489
01:49:53,560 --> 01:49:56,980
E, em seguida, nas consultas,
você pode usar as propriedades

2490
01:49:56,980 --> 01:49:59,480
desses objetos usando Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Para que eu possa filtrar em um nested
propriedade do documento JSON.

2492
01:50:03,562 --> 01:50:05,520
AUDIÊNCIA: Então qualquer momento I
fazer uma abordagem documento,

2493
01:50:05,520 --> 01:50:07,906
Eu posso classificar de chegar ao tabular--

2494
01:50:07,906 --> 01:50:08,780
AUDIÊNCIA: Absolutamente.

2495
01:50:08,780 --> 01:50:09,800
Audiência: --indexes e
coisas que você falou.

2496
01:50:09,800 --> 01:50:11,280
RICK HOULIHAN: Sim, o
índices e tudo o que,

2497
01:50:11,280 --> 01:50:13,363
quando você quer indexar o
propriedades do JSON,

2498
01:50:13,363 --> 01:50:18,230
a maneira que nós teríamos de fazer isso é se
você insere um objeto JSON ou um documento

2499
01:50:18,230 --> 01:50:20,780
em Dynamo, você usaria correntes.

2500
01:50:20,780 --> 01:50:22,400
Streams iria ler a entrada.

2501
01:50:22,400 --> 01:50:24,340
Você deseja obter que JSON
objeto e você diria OK,

2502
01:50:24,340 --> 01:50:26,030
o que é a propriedade que eu quero para o índice?

2503
01:50:26,030 --> 01:50:28,717
>> Você cria uma tabela derivada.

2504
01:50:28,717 --> 01:50:30,300
Agora que é a forma como ele funciona agora.

2505
01:50:30,300 --> 01:50:32,650
Nós não permitimos que você índice
diretamente essas propriedades.

2506
01:50:32,650 --> 01:50:33,520
>> AUDIÊNCIA: Tabularizing seus documentos.

2507
01:50:33,520 --> 01:50:36,230
>> RICK HOULIHAN: Exatamente, achatando
ele, tabularizing isso, exatamente.

2508
01:50:36,230 --> 01:50:37,415
Isso é o que você faz com ele.

2509
01:50:37,415 --> 01:50:37,860
>> AUDIÊNCIA: Obrigado.

2510
01:50:37,860 --> 01:50:39,609
>> RICK HOULIHAN: Sim,
absolutamente, obrigado.

2511
01:50:39,609 --> 01:50:42,240
AUDIÊNCIA: Então é tipo de
Mongo atende classifers Redis.

2512
01:50:42,240 --> 01:50:43,990
>> RICK HOULIHAN: Sim,
é muito parecido.

2513
01:50:43,990 --> 01:50:45,940
Essa é uma boa descrição para ele.

2514
01:50:45,940 --> 01:50:47,490
Frio.

2515
01:50:47,490 --> 01:50:49,102