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

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

3
00:00:06,010 --> 00:00:06,600
Ola, persoal.

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

5
00:00:07,670 --> 00:00:10,330
Eu son un director Senior
arquitecto de solucións da AWS.

6
00:00:10,330 --> 00:00:14,070
Concentrar-me en NoSQL e
Tecnoloxías DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Estou aquí hoxe para falar con
vostede un pouco sobre aqueles.

8
00:00:16,930 --> 00:00:18,970
>> Miña formación é
principalmente na capa de datos.

9
00:00:18,970 --> 00:00:21,390
Pasei a metade da miña desenvolvemento
escrita da carreira de base de datos,

10
00:00:21,390 --> 00:00:25,930
acceso a datos, solucións
para varias aplicacións.

11
00:00:25,930 --> 00:00:30,000
Eu estiven en virtualización na nube
por preto de 20 anos.

12
00:00:30,000 --> 00:00:33,460
Entón, antes de que a nube se a nube,
acostumabamos chamalo utility computing.

13
00:00:33,460 --> 00:00:37,170
E a idea foi, é como
PG & E, paga polo que usa.

14
00:00:37,170 --> 00:00:38,800
Hoxe o chamamos nube.

15
00:00:38,800 --> 00:00:41,239
>> Pero co paso dos anos, eu traballei
para un par de empresas

16
00:00:41,239 --> 00:00:42,530
probablemente nunca escoitou falar.

17
00:00:42,530 --> 00:00:47,470
Pero eu compilar unha lista de técnico
realizacións, eu creo que diría.

18
00:00:47,470 --> 00:00:51,620
Teño oito patentes en sistemas en nube
virtualización, deseño de microprocesadores,

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

20
00:00:54,440 --> 00:00:58,290
>> Entón, estes días, vou concentrar principalmente sobre NoSQL
tecnoloxías e da seguinte xeración

21
00:00:58,290 --> 00:00:59,450
base de datos.

22
00:00:59,450 --> 00:01:03,370
E iso é xeralmente o que eu vou
estar aquí falando contigo hoxe sobre.

23
00:01:03,370 --> 00:01:06,030
Entón, o que pode esperar
dende esta sesión,

24
00:01:06,030 --> 00:01:08,254
nós imos pasar por un breve
historia de procesamento de datos.

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

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

27
00:01:12,400 --> 00:01:15,600
E imos falar un pouco
pouco sobre tecnoloxía NoSQL

28
00:01:15,600 --> 00:01:17,500
desde un punto de vista fundamental.

29
00:01:17,500 --> 00:01:19,870
>> Nós imos entrar en algunhas das
os internos DynamoDB.

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

31
00:01:24,350 --> 00:01:27,340
É un totalmente xestionado e
solución NoSQL aloxado.

32
00:01:27,340 --> 00:01:32,420
E nós imos falar un pouco sobre a táboa
estrutura, APIs, tipos de datos, índices,

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

34
00:01:35,177 --> 00:01:37,760
Nós imos entrar en algún do deseño
estándares e mellores prácticas.

35
00:01:37,760 --> 00:01:39,968
Nós imos falar sobre como
usar a tecnoloxía para algúns

36
00:01:39,968 --> 00:01:41,430
as aplicacións de hoxe.

37
00:01:41,430 --> 00:01:44,820
E entón nós imos falar un pouco
sobre a evolución ou a emerxencia

38
00:01:44,820 --> 00:01:48,980
dun novo paradigma na programación
chamados aplicacións orientados a eventos

39
00:01:48,980 --> 00:01:51,580
e como DynamoDB desempeña no que, como ben.

40
00:01:51,580 --> 00:01:54,690
E nós imos deixar que un pouco de
unha arquitectura de referencia discusión

41
00:01:54,690 --> 00:01:59,540
así que podemos falar sobre algunhas das
as formas que pode usar DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Entón, primeiro off-- esta é unha cuestión
Escoito moito é, o que é unha base de datos.

43
00:02:04,116 --> 00:02:06,240
Moita xente pensa que eles
sabe o que é unha base de datos.

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

45
00:02:08,360 --> 00:02:11,675
É unha dun conxunto estruturado de datos realizada
nun ordenador, especialmente un que

46
00:02:11,675 --> 00:02:13,600
é accesible de varias maneiras.

47
00:02:13,600 --> 00:02:16,992
Creo que é unha boa
definición de unha base de datos moderno.

48
00:02:16,992 --> 00:02:19,450
Pero eu non me gusta, porque
implica un par de cousas.

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

50
00:02:20,935 --> 00:02:23,120
E iso implica que é nun ordenador.

51
00:02:23,120 --> 00:02:25,750
E bases de datos non
sempre existir en computadores.

52
00:02:25,750 --> 00:02:28,020
Bases de datos, en realidade existía en moitas maneiras.

53
00:02:28,020 --> 00:02:32,000
>> Así, unha mellor definición dun
base de datos é algo así.

54
00:02:32,000 --> 00:02:34,786
Unha base de datos é unha organizada
mecanismo para almacenamento, xestión,

55
00:02:34,786 --> 00:02:35,910
e recuperación de información.

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

57
00:02:36,868 --> 00:02:42,080
Entón, me gusta diso porque realmente fala
sobre unha base de datos de ser un repositorio,

58
00:02:42,080 --> 00:02:44,800
un repositorio de
información, non necesariamente

59
00:02:44,800 --> 00:02:46,780
algo que se sente nun ordenador.

60
00:02:46,780 --> 00:02:49,290
E ao longo da historia, nós
non sempre tiveron ordenadores.

61
00:02:49,290 --> 00:02:52,110
>> Agora, se eu preguntar a media
creador de hoxe o que é

62
00:02:52,110 --> 00:02:54,770
unha base de datos, esa é a resposta que recibín.

63
00:02:54,770 --> 00:02:56,070
Nalgún lugar que eu poida manter o material.

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

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

66
00:02:58,725 --> 00:02:59,600
Pero é lamentable.

67
00:02:59,600 --> 00:03:02,700
Porque a base de datos é realmente
a fundación do app moderno.

68
00:03:02,700 --> 00:03:04,810
É a fundación
de cada aplicación.

69
00:03:04,810 --> 00:03:07,240
E como construír ese
base de datos, como estrutura

70
00:03:07,240 --> 00:03:11,750
que datos vai dictar como que
aplicación execútase como escala.

71
00:03:11,750 --> 00:03:14,640
>> Así, gran parte do meu traballo hoxe
é xestionar o que

72
00:03:14,640 --> 00:03:17,180
acontece cando os desenvolvedores
adoptar esa visión

73
00:03:17,180 --> 00:03:19,510
e ante as consecuencias
dunha aplicación que

74
00:03:19,510 --> 00:03:24,966
agora está ampliando ademais do orixinal
intención e sufrimento de mal deseño.

75
00:03:24,966 --> 00:03:26,840
Polo tanto, esperamos que cando
ir hoxe, vai

76
00:03:26,840 --> 00:03:29,010
ten un par de ferramentas en
seu cinto que vai mantelo

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

78
00:03:32,566 --> 00:03:33,066
Todo ben.

79
00:03:33,066 --> 00:03:36,360
Entón imos falar sobre un pouco de
a liña do tempo da tecnoloxía de base de datos.

80
00:03:36,360 --> 00:03:38,830
Creo que lin un
artigo non moito tempo atrás

81
00:03:38,830 --> 00:03:43,020
e el dixo algo sobre o lines--
é unha afirmación moi poético.

82
00:03:43,020 --> 00:03:46,590
El dixo que a historia
de procesamento de datos é

83
00:03:46,590 --> 00:03:49,350
cheo de altos marcas de auga
abundancia de datos.

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

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

86
00:03:52,532 --> 00:03:54,990
Pero realmente ollar é como
a historia é realmente cheo

87
00:03:54,990 --> 00:03:56,820
con marca de auga de alta presión de datos.

88
00:03:56,820 --> 00:04:00,040
Unha vez que a taxa de datos
Inxestión Nunca vai para abaixo.

89
00:04:00,040 --> 00:04:01,360
El só vai para arriba.

90
00:04:01,360 --> 00:04:03,670
>> E a innovación ocorre cando
vemos presión de datos, que

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

92
00:04:07,825 --> 00:04:12,027
E non pode ser procesado
eficientemente, tanto no tempo ou no custo.

93
00:04:12,027 --> 00:04:14,110
E foi alí onde comezamos
a ollar para a presión de datos.

94
00:04:14,110 --> 00:04:15,920
>> Así, cando miramos para o
primeira base de datos, esta

95
00:04:15,920 --> 00:04:17,180
é a única que estaba entre os nosos oídos.

96
00:04:17,180 --> 00:04:18,310
Todos nacemos con el.

97
00:04:18,310 --> 00:04:19,194
É unha base de datos ben.

98
00:04:19,194 --> 00:04:21,110
El ten unha alta dispoñibilidade.

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

100
00:04:21,959 --> 00:04:23,930
Sempre pode obtelo.

101
00:04:23,930 --> 00:04:24,890
>> Pero é único usuario.

102
00:04:24,890 --> 00:04:26,348
Non podo compartir meus pensamentos con vostede.

103
00:04:26,348 --> 00:04:28,370
Non pode obter os meus pensamentos
cando quere que eles.

104
00:04:28,370 --> 00:04:30,320
E a súa abilitiy non é tan bo.

105
00:04:30,320 --> 00:04:32,510
Esquecemos nos de cousas.

106
00:04:32,510 --> 00:04:36,540
De cando en vez, un de nós follas
e móvese a outra existencia

107
00:04:36,540 --> 00:04:39,110
e perdemos todo
que estaba no banco de datos.

108
00:04:39,110 --> 00:04:40,640
Entón iso non é todo o que é bo.

109
00:04:40,640 --> 00:04:43,189
>> E iso funcionou ben no tempo
cando estabamos de volta ao día

110
00:04:43,189 --> 00:04:46,230
cando todo o que realmente precisaba saber é
onde estamos indo a ir mañá

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

112
00:04:49,630 --> 00:04:52,820
Pero cando comezamos a crecer como
civilización e goberno comezou

113
00:04:52,820 --> 00:04:55,152
para chegar a ser, e
as empresas comezaron a evolucionar,

114
00:04:55,152 --> 00:04:57,360
nós comezamos a entender que
necesitamos un pouco máis que o

115
00:04:57,360 --> 00:04:58,210
poderiamos poñer na nosa cabeza.

116
00:04:58,210 --> 00:04:58,870
Todo ben?

117
00:04:58,870 --> 00:05:00,410
>> Necesitabamos de sistemas de rexistro.

118
00:05:00,410 --> 00:05:02,220
Necesitabamos lugares para ser almacenar datos capaces.

119
00:05:02,220 --> 00:05:05,450
Entón comezamos a escribir documentos,
a creación de bibliotecas e arquivos.

120
00:05:05,450 --> 00:05:08,000
Comezamos a desenvolver un
sistema de contabilidade Ledger.

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

122
00:05:12,200 --> 00:05:15,580
e quizais mesmo milenios, como
nós medio que creceu a tal punto

123
00:05:15,580 --> 00:05:18,420
onde esa carga de datos superou
a capacidade destes sistemas

124
00:05:18,420 --> 00:05:19,870
para poder conter.

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

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

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

128
00:05:24,390 --> 00:05:26,976
Isto é realmente onde a viraxe
apuntar procesamento de datos moderno.

129
00:05:26,976 --> 00:05:28,850
Este é o punto en
que a cantidade de datos

130
00:05:28,850 --> 00:05:32,060
que estaba sendo recollidas por
Goberno dos Estados Unidos chegou a un punto

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

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

133
00:05:36,350 --> 00:05:39,180
sae cada 10 anos-- polo que é
bastante obvio que polo tempo que

134
00:05:39,180 --> 00:05:41,419
obtivo o censo de 1890,
a cantidade de datos que

135
00:05:41,419 --> 00:05:43,210
ía ser procesado
polo goberno foi

136
00:05:43,210 --> 00:05:46,335
vai exceder os 10 anos que
sería necesario para lanzar o novo censo.

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

138
00:05:47,250 --> 00:05:49,000
>> Entón, un cara chamado Herman
Hollerith veu xunto

139
00:05:49,000 --> 00:05:52,640
e inventou rexistro zócolo unidade
tarxetas, lector de tarxetas perfurados, tarxetas perfurados

140
00:05:52,640 --> 00:05:58,420
tabulator, eo agrupación de
os mecanismos para esta tecnoloxía.

141
00:05:58,420 --> 00:06:01,860
E que a empresa que el formou no
tempo, xunto cun par de outros,

142
00:06:01,860 --> 00:06:05,450
de feito, chegou a ser un dos piares dunha
pequena empresa que coñecemos hoxe chamada IBM.

143
00:06:05,450 --> 00:06:08,417
>> Entón IBM orixinalmente estaba
base de datos da empresa.

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

145
00:06:09,750 --> 00:06:11,110
Fixeron procesamento de datos.

146
00:06:11,110 --> 00:06:15,400
>> Como así a proliferación de perforado
tarxetas, un enxeñoso mecanismos

147
00:06:15,400 --> 00:06:18,560
de poder aproveitar ese
tecnoloxía para votación conxuntos de resultados clasificados.

148
00:06:18,560 --> 00:06:20,726
Podes ver nesta foto
aí temos un little--

149
00:06:20,726 --> 00:06:23,970
é un pouco small-- pero verás
un mecanismo mecánico moi enxeñoso

150
00:06:23,970 --> 00:06:26,970
onde temos unha plataforma de cartóns perforados.

151
00:06:26,970 --> 00:06:28,720
E toma de alguén
un pouco de chave de fenda

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

153
00:06:31,400 --> 00:06:34,820
para este partido, que
resultados clasificados definido.

154
00:06:34,820 --> 00:06:36,270
>> Esta é unha agregación.

155
00:06:36,270 --> 00:06:38,690
Facemos todo o tempo
hoxe no ordenador,

156
00:06:38,690 --> 00:06:40,100
onde facelo na base de datos.

157
00:06:40,100 --> 00:06:41,620
Nós acostumabamos facelo manualmente, non?

158
00:06:41,620 --> 00:06:42,994
Persoas poñer isto en conxunto.

159
00:06:42,994 --> 00:06:45,440
E foi a proliferación
destes tarxetas perfurados

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

161
00:06:50,070 --> 00:06:55,980
>> A industria de procesamento de datos levou
unha lección cos pianos de xogador.

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

163
00:06:57,855 --> 00:07:02,100
adoitaba usar bobinas de papel con slots
para dicirlle que as claves para xogar.

164
00:07:02,100 --> 00:07:05,380
Así que a tecnoloxía foi adaptada
finalmente, para almacenar datos dixitais,

165
00:07:05,380 --> 00:07:08,070
porque eles poderían poñer eses datos
para os rolos de cinta de papel.

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

167
00:07:10,870 --> 00:07:14,960
vostede acceder a estes datos foi directamente
dependente da forma como está almacenado.

168
00:07:14,960 --> 00:07:17,825
Entón, se eu poñer os datos nunha cinta,
Tiven acceder aos datos de xeito lineal.

169
00:07:17,825 --> 00:07:20,475
Tiven que rolar a todo
cinta para acceder todos os datos.

170
00:07:20,475 --> 00:07:22,600
Se eu poñer os datos no zócalo
tarxetas, eu podería acceder a ela

171
00:07:22,600 --> 00:07:26,270
en algo máis aleatoria
forma, quizais non tan rapidamente.

172
00:07:26,270 --> 00:07:30,770
>> Pero había limitacións en como nós
acceso a datos en base a como foi almacenado.

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

174
00:07:32,890 --> 00:07:37,890
Unha vez máis, podemos comezar a ver que, coma nós
desenvolver novas tecnoloxías para procesar

175
00:07:37,890 --> 00:07:41,670
os datos, non, ela abre
a porta a novas solucións,

176
00:07:41,670 --> 00:07:45,852
para novos programas, novo
aplicacións para estes datos.

177
00:07:45,852 --> 00:07:47,810
E realmente, gobernanza
pode ser a razón

178
00:07:47,810 --> 00:07:49,435
por iso que realizamos algúns destes sistemas.

179
00:07:49,435 --> 00:07:52,290
Pero o negocio tornouse rapidamente
o condutor detrás da evolución

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

181
00:07:54,720 --> 00:07:56,870
>> Polo tanto, a seguinte cousa que
xurdiu foi nos anos 50

182
00:07:56,870 --> 00:08:00,780
foi o sistema de ficheiros e
desenvolvemento de almacenamento de acceso aleatorio.

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

184
00:08:02,050 --> 00:08:06,230
Agora, de súpeto, podemos poñer o noso
arquivos en calquera lugar neses discos duros

185
00:08:06,230 --> 00:08:09,760
e podemos acceder a estes datos de forma aleatoria.

186
00:08:09,760 --> 00:08:11,950
Podemos analizar que
información de arquivos.

187
00:08:11,950 --> 00:08:14,920
E nós decidimos todo o mundo
problemas con procesamento de datos.

188
00:08:14,920 --> 00:08:17,550
>> E que durou preto de 20 ou
30 anos ata a evolución

189
00:08:17,550 --> 00:08:22,100
da base de datos relacional, que
é cando o mundo decidiu que agora

190
00:08:22,100 --> 00:08:27,940
Debe ter un repositorio que derrota
a expansión dos datos a través do arquivo

191
00:08:27,940 --> 00:08:29,540
sistemas que construímos. Non?

192
00:08:29,540 --> 00:08:34,270
Moitos datos distribuídos en moitos
lugares, a de-duplicación de datos,

193
00:08:34,270 --> 00:08:37,120
eo custo de almacenamento era enorme.

194
00:08:37,120 --> 00:08:43,760
>> Os anos 70, o recurso máis caro
que un ordenador tiña era o de almacenamento.

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

196
00:08:46,200 --> 00:08:49,030
Cando mercar a caixa,
a CPU fai un traballo.

197
00:08:49,030 --> 00:08:51,960
Será xiro se
é realmente funciona ou non.

198
00:08:51,960 --> 00:08:53,350
Isto é realmente un custo afundido.

199
00:08:53,350 --> 00:08:56,030
>> Pero o que me custou como un
negocio é o almacenamento.

200
00:08:56,030 --> 00:09:00,020
Se eu teño que mercar máis discos próximo
mes, iso é un custo real que pagar.

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

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

203
00:09:05,020 --> 00:09:10,020
A computación é agora o
recurso máis caro.

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

205
00:09:11,470 --> 00:09:14,570
Quero dicir, podemos ir a calquera lugar no
nube e podemos atopar almacenamento barato.

206
00:09:14,570 --> 00:09:17,190
Pero o que eu non podo atopar é computación barato.

207
00:09:17,190 --> 00:09:20,700
>> Así, a evolución de hoxe
tecnoloxía, da tecnoloxía de base de datos,

208
00:09:20,700 --> 00:09:23,050
Está realmente focado en torno a
bases de datos distribuídas

209
00:09:23,050 --> 00:09:26,960
que non sofren
o mesmo tipo de escala

210
00:09:26,960 --> 00:09:29,240
limitacións dos bancos de datos relacionais.

211
00:09:29,240 --> 00:09:32,080
Imos falar un pouco sobre
o que iso realmente significa.

212
00:09:32,080 --> 00:09:34,760
>> Pero unha das razóns e
o condutor detrás de nós isto--

213
00:09:34,760 --> 00:09:38,290
falou sobre a presión de datos.

214
00:09:38,290 --> 00:09:41,920
Presión de datos é algo
que impulsa a innovación.

215
00:09:41,920 --> 00:09:44,610
E se ollar para arriba
Nos últimos cinco anos,

216
00:09:44,610 --> 00:09:48,180
este é un gráfico de que os datos
carga toda a empresa xeral

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 xeral do polgar
estes dias-- se vai Google--

219
00:09:52,570 --> 00:09:55,290
é do 90% do que os datos
nós gardados hoxe, e foi

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

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

222
00:09:57,911 --> 00:09:59,410
Agora, iso non é unha tendencia que hai de novo.

223
00:09:59,410 --> 00:10:01,230
Esta é unha tendencia que foi
saíndo por 100 anos.

224
00:10:01,230 --> 00:10:03,438
Desde Herman Hollerith
desenvolveu a tarxeta de perforado,

225
00:10:03,438 --> 00:10:08,040
temos está a construír repositorios de datos
e recolección de datos en taxas fenómenos.

226
00:10:08,040 --> 00:10:10,570
>> Así, ao longo dos últimos 100 anos,
vimos esa tendencia.

227
00:10:10,570 --> 00:10:11,940
Iso non vai cambiar.

228
00:10:11,940 --> 00:10:14,789
Aquí para diante, imos ver
este, se non unha tendencia acelerada.

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

230
00:10:16,330 --> 00:10:23,510
>> Se unha empresa, en 2010, tivo un
terabyte de datos baixo xestión,

231
00:10:23,510 --> 00:10:27,080
hoxe que significa que son
xestión de 6,5 petabytes de datos.

232
00:10:27,080 --> 00:10:30,380
Isto é 6.500 veces máis datos.

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

234
00:10:31,200 --> 00:10:33,292
Eu traballo con estas empresas todos os días.

235
00:10:33,292 --> 00:10:35,000
Cinco anos, eu
falaría con empresas

236
00:10:35,000 --> 00:10:38,260
quen ía falar comigo sobre o que é unha dor
é para xestionar terabytes de datos.

237
00:10:38,260 --> 00:10:39,700
E falarían
para min sobre como podemos ver

238
00:10:39,700 --> 00:10:41,825
que se trata probablemente
ser un ou dous petabyte

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

240
00:10:43,030 --> 00:10:45,170
>> Estas mesmas empresas
hoxe vou atopar con,

241
00:10:45,170 --> 00:10:48,100
e eles están falando comigo sobre o
problema está aí ter xestión

242
00:10:48,100 --> 00:10:51,440
decenas, 20 petabytes de datos.

243
00:10:51,440 --> 00:10:53,590
Así, a explosión da
datos na industria

244
00:10:53,590 --> 00:10:56,670
Está dirixido a enorme
precisa mellores solucións.

245
00:10:56,670 --> 00:11:00,980
E a base de datos relacional é
só non vivir de acordo coa demanda.

246
00:11:00,980 --> 00:11:03,490
>> E por iso hai unha lineal
correlación entre a presión de datos

247
00:11:03,490 --> 00:11:05,210
e innovación técnica.

248
00:11:05,210 --> 00:11:07,780
A historia ten nos mostra
este, que co paso do tempo,

249
00:11:07,780 --> 00:11:11,090
sempre que o volume de datos
que ten que ser procesado

250
00:11:11,090 --> 00:11:15,490
supera a capacidade do sistema
para proceso-lo nun tempo razoable

251
00:11:15,490 --> 00:11:18,870
ou a un custo razoable,
a continuación, as novas tecnoloxías

252
00:11:18,870 --> 00:11:21,080
son inventadas para resolver estes problemas.

253
00:11:21,080 --> 00:11:24,090
Estas novas tecnoloxías,
á súa vez, abre a porta

254
00:11:24,090 --> 00:11:27,840
a outro conxunto de problemas, o que
está reunindo aínda máis datos.

255
00:11:27,840 --> 00:11:29,520
>> Agora, non imos parar con iso.

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

257
00:11:30,020 --> 00:11:31,228
Non imos parar con iso.

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

259
00:11:31,830 --> 00:11:35,520
Porque non pode saber todo
que hai para saber o universo.

260
00:11:35,520 --> 00:11:40,510
E mentres nós estivemos vivos,
ao longo da historia do home,

261
00:11:40,510 --> 00:11:43,440
temos sempre conducido para saber máis.

262
00:11:43,440 --> 00:11:49,840
>> Entón, parece que cada polgada nos movemos
no camiño do descubrimento científica,

263
00:11:49,840 --> 00:11:54,620
estamos a multiplicación da cantidade de datos
que necesitamos para procesar exponencialmente

264
00:11:54,620 --> 00:11:59,920
como descubrimos máis e máis e máis
sobre o funcionamento interno da vida,

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

266
00:12:04,530 --> 00:12:06,440
e que a invención
nós estamos facendo hoxe.

267
00:12:06,440 --> 00:12:09,570
O volume de datos só
aumenta continuamente.

268
00:12:09,570 --> 00:12:12,120
Así, ser capaz de xestionar
este problema é enorme.

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

270
00:12:14,790 --> 00:12:17,410
>> Entón, unha das cousas
Mira por NoSQL?

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

272
00:12:19,200 --> 00:12:24,980
Ben, bases de datos relacionais,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- que é realmente unha construción do
relacional database-- esas cousas son

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

275
00:12:30,770 --> 00:12:33,180
>> Volver na década de 70, unha vez máis,
disco é caro.

276
00:12:33,180 --> 00:12:36,990
O exercicio de provisionais de almacenamento
na empresa é interminable.

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

278
00:12:37,490 --> 00:12:38,020
Eu vivín isto.

279
00:12:38,020 --> 00:12:41,250
Escribín controladores de almacenamento para un
empresa superserver enterprised

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

281
00:12:42,470 --> 00:12:45,920
E a liña de fondo é outra trasfega
matriz de almacenamento foi só algo que

282
00:12:45,920 --> 00:12:47,600
Pasou cada día na empresa.

283
00:12:47,600 --> 00:12:49,030
E non parou máis.

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

285
00:12:52,690 --> 00:12:56,340
e para un almacenamento máis eficiente
devices-- nunca parou.

286
00:12:56,340 --> 00:13:00,160
>> E NoSQL é unha gran tecnoloxía
xa que normaliza os datos.

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

288
00:13:02,210 --> 00:13:07,180
Isto pon os datos nunha estrutura que
é agnóstica para cada nivel de acceso.

289
00:13:07,180 --> 00:13:11,600
Varias aplicacións poden bater ese
Base de datos SQL, realizar consultas ad hoc,

290
00:13:11,600 --> 00:13:15,950
e obter datos en forma que
Debe proceso para a súa carga de traballo.

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

292
00:13:17,570 --> 00:13:21,350
Pero a liña de fondo é con calquera
sistema, se é agnóstico a todo,

293
00:13:21,350 --> 00:13:23,500
é óptimo para nada.

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

295
00:13:24,050 --> 00:13:26,386
>> E iso é o que nós comezamos con
a base de datos relacional.

296
00:13:26,386 --> 00:13:27,510
É óptimo para almacenamento.

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
Soporta as consultas ad hoc.

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

301
00:13:34,000 --> 00:13:39,030
>> Se eu teño para obter unha base de datos SQL maior
ou unha base de datos SQL máis poderoso,

302
00:13:39,030 --> 00:13:41,090
Vou mercar unha peza grande de ferro.

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

304
00:13:41,600 --> 00:13:44,940
Eu traballei con unha morea de clientes
que xa pasou por grandes actualizacións

305
00:13:44,940 --> 00:13:48,340
na súa infraestrutura SQL única
para descubrir seis meses despois,

306
00:13:48,340 --> 00:13:49,750
están acertando a parede de novo.

307
00:13:49,750 --> 00:13:55,457
E a resposta de Oracle ou MSSQL
ou calquera outra persoa é obter unha caixa máis grande.

308
00:13:55,457 --> 00:13:58,540
Ben, máis cedo ou máis tarde, non pode mercar un
maior caixa, e iso é problema real.

309
00:13:58,540 --> 00:14:00,080
Necesitamos realmente cambiar as cousas.

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

311
00:14:01,080 --> 00:14:06,560
Funciona ben para offline
Analytics, do tipo OLAP carga de traballo.

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

313
00:14:08,670 --> 00:14:12,540
Agora, é usado hoxe en moitos en liña
transacional-tipo de procesamento

314
00:14:12,540 --> 00:14:13,330
aplicacións.

315
00:14:13,330 --> 00:14:16,460
E funciona moi ben no
algún nivel de uso,

316
00:14:16,460 --> 00:14:18,670
pero simplemente non escala
a forma que NoSQL fai.

317
00:14:18,670 --> 00:14:20,660
E imos falar un pouco
pouco sobre por que isto ocorre.

318
00:14:20,660 --> 00:14:23,590
>> Agora, NoSQL, por outra banda,
é máis óptimo para computación.

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

320
00:14:24,540 --> 00:14:26,830
Non é agnóstico
o estándar de acceso.

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

322
00:14:31,620 --> 00:14:35,000
Os datos nunha base de datos relacional é
Xuntáronse a partir de varias táboas

323
00:14:35,000 --> 00:14:36,850
para producir a visión de que precisa.

324
00:14:36,850 --> 00:14:40,090
Os datos na base de datos NoSQL un
é almacenado nun documento que

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

326
00:14:42,100 --> 00:14:45,670
Todos os datos que normalmente se recomenda que
uníronse para producir ese punto de vista

327
00:14:45,670 --> 00:14:47,160
é almacenado nun único documento.

328
00:14:47,160 --> 00:14:50,990
E imos falar un pouco sobre
como funciona en un par de cartas.

329
00:14:50,990 --> 00:14:55,320
>> Pero a idea aquí é que almacenar
seus datos como estes puntos de vista instanciado.

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

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

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

333
00:14:59,556 --> 00:15:02,100
Se eu ter que aumentar o
tamaño do meu agrupación NoSQL,

334
00:15:02,100 --> 00:15:03,700
Eu non teño de obter unha caixa máis grande.

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

336
00:15:05,200 --> 00:15:07,700
E eu agrupar estes xuntos,
e podo caco que os datos.

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

338
00:15:10,780 --> 00:15:14,270
capaz de escalar ese banco de datos
en distintos dispositivos físicos

339
00:15:14,270 --> 00:15:18,370
e eliminar a barreira que
obrígame a escalar verticalmente.

340
00:15:18,370 --> 00:15:22,080
>> Entón, é realmente construído para en liña
procesamento de transaccións e escala.

341
00:15:22,080 --> 00:15:25,480
Hai unha gran distinción
aquí entre os informes, non?

342
00:15:25,480 --> 00:15:27,810
Informes, eu non sei o
preguntas que eu vou pedir.

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

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

345
00:15:30,570 --> 00:15:34,520
quere só-- como moitos dos meus clientes
teñen esta característica en particular que

346
00:15:34,520 --> 00:15:37,850
Compras nesta dia-- Non sei
que consultar van preguntar.

347
00:15:37,850 --> 00:15:39,160
Entón eu teño ser agnóstico.

348
00:15:39,160 --> 00:15:41,810
>> Agora, nunha liña
aplicación transacional,

349
00:15:41,810 --> 00:15:43,820
Sei que preguntas que eu estou pedindo.

350
00:15:43,820 --> 00:15:46,581
Eu constrúe a solicitude de
un fluxo de traballo moi específico.

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

352
00:15:47,080 --> 00:15:50,540
Entón, se eu optimizar a datos
almacenar a apoiar ese fluxo de traballo,

353
00:15:50,540 --> 00:15:52,020
que vai ser máis rápido.

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

355
00:15:55,190 --> 00:15:57,710
un destes tipos de servizos.

356
00:15:57,710 --> 00:15:58,210
Todo ben.

357
00:15:58,210 --> 00:16:00,501
>> Entón, nós estamos indo a entrar
un pouco de teoría aquí.

358
00:16:00,501 --> 00:16:03,330
E algúns de vostedes, os seus ollos
pode desfacer un pouco.

359
00:16:03,330 --> 00:16:06,936
Pero eu vou tentar mantelo
tan alto nivel que eu poida.

360
00:16:06,936 --> 00:16:08,880
Entón, se está no proxecto
xestión, hai

361
00:16:08,880 --> 00:16:12,280
unha construción chamada
triángulo de restricións.

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

363
00:16:12,936 --> 00:16:16,060
O triángulo de constrangimentos ditados
non pode ter todo o tempo.

364
00:16:16,060 --> 00:16:17,750
Non pode ter o seu bolo e come-lo.

365
00:16:17,750 --> 00:16:22,310
Así, en xestión de proxectos, que triángulo
limitacións é que pode telo barato,

366
00:16:22,310 --> 00:16:24,710
podes telo rápido,
ou pode telo ben.

367
00:16:24,710 --> 00:16:25,716
Escolla dous.

368
00:16:25,716 --> 00:16:27,090
Porque non pode ter todos os tres.

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

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

371
00:16:27,820 --> 00:16:28,920
>> Entón se escoita moito sobre iso.

372
00:16:28,920 --> 00:16:31,253
É unha restrición tripla,
triángulo de restrición tripla,

373
00:16:31,253 --> 00:16:34,420
ou o triángulo de ferro é oftentimes--
cando fala aos xerentes de proxecto,

374
00:16:34,420 --> 00:16:35,420
eles van falar sobre iso.

375
00:16:35,420 --> 00:16:37,640
Agora, bases de datos teñen
seu propio triángulo de ferro.

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

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

378
00:16:41,580 --> 00:16:43,770
>> PAC dictames teorema
como bases de datos operar

379
00:16:43,770 --> 00:16:45,627
baixo unha condición moi específica.

380
00:16:45,627 --> 00:16:47,460
E nós imos falar sobre
o que é esa condición.

381
00:16:47,460 --> 00:16:52,221
Pero os tres vértices do triángulo,
por así dicir, son A, consistencia.

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

383
00:16:52,720 --> 00:16:56,760
Así, no PAC, a consistencia significa que todos
clientes que poden acceder á base de datos

384
00:16:56,760 --> 00:16:59,084
terá sempre un moi
visión consistente dos datos.

385
00:16:59,084 --> 00:17:00,750
Ninguén vai ver dúas cousas diferentes.

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

387
00:17:01,480 --> 00:17:04,020
Se eu ver a base de datos,
Estou vendo a mesma visión

388
00:17:04,020 --> 00:17:06,130
como o meu compañeiro que ve
a mesma base de datos.

389
00:17:06,130 --> 00:17:07,470
Esa é a consistencia.

390
00:17:07,470 --> 00:17:12,099
>> Dispoñibilidade significa que, se o
base de datos en liña, se poida ser alcanzado,

391
00:17:12,099 --> 00:17:14,760
que todos os clientes serán sempre
ser capaz de ler e escribir.

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

393
00:17:15,260 --> 00:17:17,010
Así, cada cliente que
pode ler a base de datos

394
00:17:17,010 --> 00:17:18,955
será sempre capaz de lectura
datos de datos e escribir.

395
00:17:18,955 --> 00:17:21,819
E se ese é o caso,
É un sistema dispoñible.

396
00:17:21,819 --> 00:17:24,230
>> E o terceiro punto é o que
que chamamos tolerancia partición.

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

398
00:17:24,730 --> 00:17:28,160
Medios de tolerancia partición
que o sistema funciona ben

399
00:17:28,160 --> 00:17:32,000
a pesar de rede física
divisorias entre os nós.

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

401
00:17:32,760 --> 00:17:36,270
Entón nós do cluster non pode
falar entre si, o que pasa?

402
00:17:36,270 --> 00:17:36,880
Todo ben.

403
00:17:36,880 --> 00:17:39,545
>> Bases de datos relacionais Entón choose--
pode escoller dous destes.

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

405
00:17:40,045 --> 00:17:43,680
Bases de datos relacionais Entón escolla
para ser consistente e dispoñible.

406
00:17:43,680 --> 00:17:47,510
Se a partición acontece entre
os DataNodes no almacenamento de datos,

407
00:17:47,510 --> 00:17:48,831
a base de datos falla.

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

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

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

411
00:17:51,450 --> 00:17:54,230
>> E é por iso que eles teñen
crecendo coas caixas maiores.

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

413
00:17:54,730 --> 00:17:58,021
Porque non hai Não-- xeralmente, un cluster
base de datos, non hai moito moitos deles

414
00:17:58,021 --> 00:17:59,590
que operan desa forma.

415
00:17:59,590 --> 00:18:03,019
Pero a maioría dos bancos de datos de escala
vertical dentro dunha única caixa.

416
00:18:03,019 --> 00:18:05,060
Porque precisan ser
consistente e está dispoñible.

417
00:18:05,060 --> 00:18:10,320
Se unha partición foron sendo inxectado,
entón tería que facer unha selección.

418
00:18:10,320 --> 00:18:13,720
Ten que facer unha selección entre
sendo consistente e dispoñible.

419
00:18:13,720 --> 00:18:16,080
>> E iso é o que bancos de datos NoSQL facer.

420
00:18:16,080 --> 00:18:16,580
Todo ben.

421
00:18:16,580 --> 00:18:20,950
Así, unha base de datos NoSQL, el
vén en dous sabores.

422
00:18:20,950 --> 00:18:22,990
Nós have-- ben,
vén en moitos sabores,

423
00:18:22,990 --> 00:18:26,140
pero ven con dous básico
characteristics-- o que

424
00:18:26,140 --> 00:18:30,050
nós chamariamos de base de datos CP, ou un
tolerancia e consistente partición

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

426
00:18:31,040 --> 00:18:34,930
Eses faces a facer a elección que, cando
os nós perder o contacto entre si,

427
00:18:34,930 --> 00:18:37,091
nós non imos permitir
a xente a escribir máis.

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

429
00:18:37,590 --> 00:18:41,855
>> Ata que esta partición é eliminada,
acceso de gravación é bloqueada.

430
00:18:41,855 --> 00:18:43,230
Isto significa que eles non están dispoñibles.

431
00:18:43,230 --> 00:18:44,510
Son consistentes.

432
00:18:44,510 --> 00:18:46,554
HTML
partición inxectar-se,

433
00:18:46,554 --> 00:18:48,470
estamos agora consistente,
porque non imos

434
00:18:48,470 --> 00:18:51,517
para permitir o cambio de datos en dous
lados da partición independentemente

435
00:18:51,517 --> 00:18:52,100
un do outro.

436
00:18:52,100 --> 00:18:54,130
Teremos que
restablecer a comunicación

437
00:18:54,130 --> 00:18:56,930
antes de calquera actualización
os datos están permitidos.

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

439
00:18:58,120 --> 00:19:02,650
>> O seguinte sabor sería un sistema AP,
ou un dispoñible e repartiu

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

441
00:19:03,640 --> 00:19:05,320
Eses faces non lles importa.

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

443
00:19:06,020 --> 00:19:08,960
Calquera nodo que recibe unha
escribir, nós imos toma-lo.

444
00:19:08,960 --> 00:19:11,480
Entón, eu estou replicar meus datos
en varios nós.

445
00:19:11,480 --> 00:19:14,730
Estes nós obter un cliente, o cliente vén
en, di, eu vou escribir algúns datos.

446
00:19:14,730 --> 00:19:16,300
Nó di, non hai problema.

447
00:19:16,300 --> 00:19:18,580
O nó ó lado queda
unha gravación no mesmo rexistro,

448
00:19:18,580 --> 00:19:20,405
vai dicir non problema.

449
00:19:20,405 --> 00:19:23,030
Nalgún lugar de volta no back-end,
que os datos vai replicar.

450
00:19:23,030 --> 00:19:27,360
E entón alguén vai entender,
uh-oh, eles van entender sistema, uh-oh,

451
00:19:27,360 --> 00:19:28,870
houbo unha actualización para os dous lados.

452
00:19:28,870 --> 00:19:30,370
O que imos facer?

453
00:19:30,370 --> 00:19:33,210
E o que fan é, entón,
fan algo que

454
00:19:33,210 --> 00:19:36,080
lles permite resolver este estado de datos.

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

456
00:19:39,000 --> 00:19:40,000
>> Cousa que salientar aquí.

457
00:19:40,000 --> 00:19:42,374
E eu non vou ir moi
moi a este, porque esta

458
00:19:42,374 --> 00:19:43,510
entra en teoría datos de profundidade.

459
00:19:43,510 --> 00:19:46,670
Pero hai un transacional
cadro que

460
00:19:46,670 --> 00:19:50,680
é executado en un sistema relacional que
permite que faga con seguridade actualizacións

461
00:19:50,680 --> 00:19:53,760
para varias entidades na base de datos.

462
00:19:53,760 --> 00:19:58,320
E esas actualizacións deben ocorrer
todo dunha vez ou de xeito ningún.

463
00:19:58,320 --> 00:20:00,500
E iso é chamado de transaccións ACID.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID dános atomicidade, consistencia,
illamento, e durabilidade.

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

467
00:20:07,070 --> 00:20:13,550
Isto significa que, transaccións atómicas, todo
miñas actualizacións tanto ocorrer ou non fan.

468
00:20:13,550 --> 00:20:16,570
Consistencia significa que
a base de datos será sempre

469
00:20:16,570 --> 00:20:19,780
ser levado a un consistente
estado tras unha actualización.

470
00:20:19,780 --> 00:20:23,900
Eu nunca vou deixar a base de datos en un
mal estado despois de aplicar unha actualización.

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

472
00:20:24,400 --> 00:20:26,720
>> Polo tanto, é un pouco diferente
de consistencia PAC.

473
00:20:26,720 --> 00:20:29,760
Consistencia PAC significa toda a miña
os clientes poden sempre ver os datos.

474
00:20:29,760 --> 00:20:34,450
Consistencia ÁCIDO significa que cando
unha transacción está feito, datos de boa.

475
00:20:34,450 --> 00:20:35,709
Meus relacións son todo de bo.

476
00:20:35,709 --> 00:20:38,750
Eu non estou indo para eliminar unha liña pai
e deixar unha morea de nenos orfas

477
00:20:38,750 --> 00:20:40,970
nalgunha outra táboa.

478
00:20:40,970 --> 00:20:44,320
Isto non pode ocorrer se eu está consistente
nunha transacción de ácido.

479
00:20:44,320 --> 00:20:49,120
>> Illamento significa que as transaccións
sempre producen despois da outra.

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

481
00:20:51,920 --> 00:20:54,770
como se estas operacións
que foron emitidos simultaneamente

482
00:20:54,770 --> 00:20:57,340
foron executados en serie.

483
00:20:57,340 --> 00:21:00,030
Polo tanto, é a simultaneidade
control da base de datos.

484
00:21:00,030 --> 00:21:04,130
Entón, basicamente, eu non podo incrementar o
mesmo valor dobre con dúas operacións.

485
00:21:04,130 --> 00:21:08,580
>> Pero se eu digo engadir 1 a este valor,
e dúas operacións veñen

486
00:21:08,580 --> 00:21:10,665
e tentar facelo, é unha
vai chegar alí primeiro

487
00:21:10,665 --> 00:21:12,540
e do outro un
vai chegar alí despois.

488
00:21:12,540 --> 00:21:15,210
Entón, ao final, eu engade dous.

489
00:21:15,210 --> 00:21:16,170
Ve o que quero dicir?

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

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

492
00:21:19,220 --> 00:21:21,250
>> A durabilidade é moi sinxelo.

493
00:21:21,250 --> 00:21:23,460
Cando a transacción
é recoñecido, é

494
00:21:23,460 --> 00:21:26,100
vai estar alí mesmo
se o sistema falla.

495
00:21:26,100 --> 00:21:29,230
Cando este sistema recupera, isto
transacción que foi cometida

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

497
00:21:30,480 --> 00:21:33,130
Entón, iso é as garantías
de transaccións ACID.

498
00:21:33,130 --> 00:21:35,470
Estas son garantías moi agradables
para ter nunha base de datos,

499
00:21:35,470 --> 00:21:36,870
pero eles veñen para ese custo.

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

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

502
00:21:40,520 --> 00:21:44,540
Se hai unha partición en datos
set, eu teño que tomar unha decisión.

503
00:21:44,540 --> 00:21:48,000
Vou ter para que
actualizacións dun lado ou do outro.

504
00:21:48,000 --> 00:21:50,310
E se isto acontecer,
entón eu xa non estou indo

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

506
00:21:52,630 --> 00:21:53,960
Eles non van ser consistente.

507
00:21:53,960 --> 00:21:55,841
Eles non van ser illado.

508
00:21:55,841 --> 00:21:58,090
Este é o lugar onde se descompón
para bases de datos relacionais.

509
00:21:58,090 --> 00:22:01,360
Esta é a razón relacional
bases de datos de escala vertical.

510
00:22:01,360 --> 00:22:05,530
>> Por outra banda, temos
o que se chama tecnoloxía BASE.

511
00:22:05,530 --> 00:22:07,291
E estes son os seus bancos de datos NoSQL.

512
00:22:07,291 --> 00:22:07,790
Todo ben.

513
00:22:07,790 --> 00:22:10,180
Polo tanto, temos a nosa CP, bases de datos de AP.

514
00:22:10,180 --> 00:22:14,720
E estes son, basicamente, o que chama
dispoñible, estado brando, finalmente,

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 dispoñible, porque
son partición tolerante.

518
00:22:19,690 --> 00:22:21,470
Eles serán sempre
alí, mesmo se non hai

519
00:22:21,470 --> 00:22:23,053
unha divisoria entre os nós da rede.

520
00:22:23,053 --> 00:22:25,900
Se podo falar con un nó, eu son
vai ser capaz de ler datos.

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

522
00:22:26,460 --> 00:22:30,810
Podo non ser sempre capaz de escribir
datos se eu son unha plataforma consistente.

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

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

525
00:22:34,960 --> 00:22:38,010
>> O estado indica brando
que cando eu ler estes datos,

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

527
00:22:40,790 --> 00:22:43,390
Un dereito foi emitido nun nodo
noutro lugar no cluster

528
00:22:43,390 --> 00:22:46,650
e non foi replicado en toda a
aglomerado aínda cando lin que os datos,

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

530
00:22:48,680 --> 00:22:51,650
Con todo, será
finalmente, consistente,

531
00:22:51,650 --> 00:22:53,870
o que significa que cando unha gravación
está feito para o sistema,

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

533
00:22:56,480 --> 00:22:59,095
E, finalmente, ese estado
será posto en orde,

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

535
00:23:00,890 --> 00:23:05,000
>> Agora, o teorema PAC realmente
xoga só nunha condición.

536
00:23:05,000 --> 00:23:08,700
Esta condición é cando isto ocorre.

537
00:23:08,700 --> 00:23:13,710
Porque sempre que está operando en
modo normal, non hai ningunha partición,

538
00:23:13,710 --> 00:23:16,370
todo é consistente e dispoñible.

539
00:23:16,370 --> 00:23:19,990
Só preocuparse CAP
cando temos esa partición.

540
00:23:19,990 --> 00:23:21,260
Polo tanto, estas son raras.

541
00:23:21,260 --> 00:23:25,360
Pero como o sistema reacciona cando os
ocorren dictar 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ón, imos dar un ollo ao que
parecer 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 veñen dous sabores.

546
00:23:34,830 --> 00:23:38,514
Veñen en sabor que é un
mestre mestre, 100%, sempre dispoñible.

547
00:23:38,514 --> 00:23:40,430
E veñen en
outro sabor, que di:

548
00:23:40,430 --> 00:23:43,330
vostede sabe o que, eu vou preocuparme
sobre esa cousa de particionamento

549
00:23:43,330 --> 00:23:44,724
cando ocorre unha partición real.

550
00:23:44,724 --> 00:23:47,890
Se non, non vai ser primaria
nós que vai levar os dereitos.

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

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

553
00:23:50,040 --> 00:23:54,440
Cassandra sería un mestre
mestre, imos escribir-me en calquera nodo.

554
00:23:54,440 --> 00:23:55,540
Entón o que ocorre?

555
00:23:55,540 --> 00:23:58,270
Entón, eu teño un obxecto no
base de datos que existe en dous nós.

556
00:23:58,270 --> 00:24:01,705
Imos chamar ese obxecto S.
Polo tanto, temos estado a S.

557
00:24:01,705 --> 00:24:04,312
Temos algunhas operacións
S en que están en curso.

558
00:24:04,312 --> 00:24:06,270
Cassandra permíteme
escribir para varios nós.

559
00:24:06,270 --> 00:24:08,550
Entón, digamos que eu recibín unha
escribir para sa dous nós.

560
00:24:08,550 --> 00:24:12,274
Ben, o que acaba pasando é
chamamos iso de un evento de particionamento.

561
00:24:12,274 --> 00:24:14,190
Non pode ser un
partición de rede física.

562
00:24:14,190 --> 00:24:15,950
Pero por mor do proxecto
do sistema, que é

563
00:24:15,950 --> 00:24:18,449
particionamento realmente logo
que eu conseguir unha gravación en dous nós.

564
00:24:18,449 --> 00:24:20,830
Non me forzando a
escribir todo a través dun nodo.

565
00:24:20,830 --> 00:24:22,340
Estou escribindo sobre dous nós.

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

567
00:24:23,330 --> 00:24:25,740
>> Entón agora eu teño dous estados.

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

569
00:24:26,360 --> 00:24:28,110
O que vai ocorrer
é, máis cedo ou máis tarde,

570
00:24:28,110 --> 00:24:29,960
alí vai ser un evento de replicación.

571
00:24:29,960 --> 00:24:33,300
Non vai ser o que nós
chamado de recuperación de partición, que

572
00:24:33,300 --> 00:24:35,200
é onde estes dous
estados volver xuntos

573
00:24:35,200 --> 00:24:37,310
e alí vai ser un algoritmo
que corre dentro da base de datos,

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

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

576
00:24:39,110 --> 00:24:43,057
Por defecto, última actualización
vence na maioría dos sistemas de AP.

577
00:24:43,057 --> 00:24:44,890
Polo tanto, hai xeralmente unha
algoritmo estándar, o que

578
00:24:44,890 --> 00:24:47,400
eles chaman dun callback
función, algo que

579
00:24:47,400 --> 00:24:51,000
chamarase cando esta condición
sexa detectado para realizar algunha lóxica

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

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

582
00:24:53,850 --> 00:24:58,770
O retorno de chamada predeterminado e estándar
resolver a maioría dos bancos de datos AP

583
00:24:58,770 --> 00:25:01,130
é, difícil de adiviñar, timestamp gaña.

584
00:25:01,130 --> 00:25:02,380
Esta foi a última actualización.

585
00:25:02,380 --> 00:25:04,320
Vou poñer esta actualización alí.

586
00:25:04,320 --> 00:25:08,440
Podo botan este rexistro que eu
despexado fóra nun rexistro de recuperación

587
00:25:08,440 --> 00:25:11,670
de xeito que o usuario pode volver máis tarde
e dicir, hey, houbo unha colisión.

588
00:25:11,670 --> 00:25:12,320
Que pasou?

589
00:25:12,320 --> 00:25:16,370
E realmente pode botan un rexistro de
todas as colisións e as reversões

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

591
00:25:17,550 --> 00:25:21,580
>> Agora, como un usuario, tamén se pode
incluír lóxica en que callback.

592
00:25:21,580 --> 00:25:24,290
Así, pode cambiar isto
operación de retorno de chamada.

593
00:25:24,290 --> 00:25:26,730
Pode dicir, hey, quero
para remediar estes datos.

594
00:25:26,730 --> 00:25:28,880
E quero probar e
mesturar estes dous rexistros.

595
00:25:28,880 --> 00:25:30,050
Pero iso é ata.

596
00:25:30,050 --> 00:25:32,880
A base de datos non sabe como
facelo por defecto. A maior parte do tempo,

597
00:25:32,880 --> 00:25:34,850
o único que a base de datos
sabe facer é dicir,

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

599
00:25:36,100 --> 00:25:39,183
Iso é o que vai gañar,
e ese é o valor que eu vou poñer.

600
00:25:39,183 --> 00:25:41,490
Xa que a recuperación partición
e replicación ocorre,

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

602
00:25:43,930 --> 00:25:46,890
o estado de fusión de todos estes obxectos.

603
00:25:46,890 --> 00:25:49,700
Así, os sistemas AP ter iso.

604
00:25:49,700 --> 00:25:51,615
Sistemas CP non ten
se preocupar con iso.

605
00:25:51,615 --> 00:25:54,490
Porque así como unha partición vén
en xogo, eles simplemente deixar de tomar

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

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

608
00:25:56,180 --> 00:25:58,670
Entón, iso é moi fácil
xestionar ser consistente

609
00:25:58,670 --> 00:26:01,330
cando non aceptar as actualizacións.

610
00:26:01,330 --> 00:26:04,620
Iso é cos sistemas CP facer.

611
00:26:04,620 --> 00:26:05,120
Todo ben.

612
00:26:05,120 --> 00:26:07,590
>> Entón imos falar un pouco
pouco sobre patróns de acceso.

613
00:26:07,590 --> 00:26:11,580
Cando falamos de NoSQL, é
todo sobre o nivel de acceso.

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
É almacenamento relacional.

616
00:26:14,481 --> 00:26:16,480
Non temos que preocupar-se
sobre o nivel de acceso.

617
00:26:16,480 --> 00:26:17,688
Eu escribir consulta moi complexa.

618
00:26:17,688 --> 00:26:19,250
Vai e colle os datos.

619
00:26:19,250 --> 00:26:21,210
Iso é o que iso parece
como, normalización.

620
00:26:21,210 --> 00:26:24,890
>> Polo tanto, neste estrutura particular,
nós estamos mirando para un catálogo de produtos.

621
00:26:24,890 --> 00:26:26,640
I teñen diferentes tipos de produtos.

622
00:26:26,640 --> 00:26:27,217
Teño libros.

623
00:26:27,217 --> 00:26:27,800
Teño álbums.

624
00:26:27,800 --> 00:26:30,090
Teño vídeos.

625
00:26:30,090 --> 00:26:33,370
A relación entre os produtos
e calquera destes libros, discos,

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

627
00:26:34,860 --> 00:26:35,800
Todo ben?

628
00:26:35,800 --> 00:26:38,860
Eu teño un ID do produto,
e que se corresponde ID

629
00:26:38,860 --> 00:26:41,080
para un libro, un disco ou un vídeo.

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

631
00:26:41,580 --> 00:26:44,350
Isto é unha relación 1: 1
a través destas táboas.

632
00:26:44,350 --> 00:26:46,970
>> Agora todos eles books--
ten é propiedades da raíz.

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

634
00:26:47,550 --> 00:26:48,230
Isto é óptimo.

635
00:26:48,230 --> 00:26:52,130
One-to-one relación, eu recibín todo
os datos que eu teño para describir ese libro.

636
00:26:52,130 --> 00:26:54,770
Albums Albums-- teñen pistas.

637
00:26:54,770 --> 00:26:56,470
Isto é o que chamamos un para moitos.

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

639
00:26:58,905 --> 00:27:00,780
Así, para cada tema
o álbum, eu podería ter

640
00:27:00,780 --> 00:27:02,570
outro récord nesta táboa fillo.

641
00:27:02,570 --> 00:27:04,680
Entón eu crear un rexistro
na miña táboa de álbums.

642
00:27:04,680 --> 00:27:06,700
Eu crear varios rexistros
na táboa de pistas.

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

644
00:27:08,850 --> 00:27:11,220
>> Esta relación é o que
que chamamos moitos-a-moitos.

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

646
00:27:11,750 --> 00:27:17,000
Ve que os actores poderían ser
en moitos filmes, moitos vídeos.

647
00:27:17,000 --> 00:27:21,450
Entón, o que facemos é poñer este mapa
mesa entre aqueles, que só

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

649
00:27:24,040 --> 00:27:28,464
Agora podo crear unha consulta da xunta
videos a través de vídeo actor para actores,

650
00:27:28,464 --> 00:27:31,130
e que me dá unha boa lista de
todas as películas e todos os actores

651
00:27:31,130 --> 00:27:32,420
que eran naquel filme.

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

653
00:27:33,290 --> 00:27:33,880
Entón, imos alí.

654
00:27:33,880 --> 00:27:38,040
One-to-one é a de nivel superior
relación; un a moitos,

655
00:27:38,040 --> 00:27:40,240
álbums de rutas; moitos-a-moitos.

656
00:27:40,240 --> 00:27:44,990
Estes son os tres de nivel superior
relacións en calquera base de datos.

657
00:27:44,990 --> 00:27:48,050
Se sabe como aqueles
relacións de traballo en conxunto,

658
00:27:48,050 --> 00:27:51,490
entón vostede sabe moi
sobre base de datos xa.

659
00:27:51,490 --> 00:27:55,660
Entón NoSQL funciona un pouco diferente.

660
00:27:55,660 --> 00:27:58,930
Imos pensar por un segundo o que
miradas lle gusta ir obter todos os meus produtos.

661
00:27:58,930 --> 00:28:01,096
>> Nunha tenda relacional, I
quere obter todos os meus produtos

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

663
00:28:02,970 --> 00:28:04,910
Iso é unha chea de consultas.

664
00:28:04,910 --> 00:28:07,030
Eu teño unha consulta para todos os meus libros.

665
00:28:07,030 --> 00:28:08,470
Eu teño unha consulta dos meus álbums.

666
00:28:08,470 --> 00:28:09,970
E eu teño unha consulta para todos os meus vídeos.

667
00:28:09,970 --> 00:28:11,719
E eu teño que poñelo
todos xuntos nunha lista

668
00:28:11,719 --> 00:28:15,250
e servi-lo de volta ata o
aplicación que está pedindo iso.

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

670
00:28:18,000 --> 00:28:21,680
Para obter os meus albums, eu comece a xuntar-se
Produtos, Álbums, e pistas.

671
00:28:21,680 --> 00:28:25,330
E para os meus vídeos, eu teño
para xuntar-se os produtos a vídeos,

672
00:28:25,330 --> 00:28:28,890
xuntar-se a través Actor vídeos,
e traer os actores.

673
00:28:28,890 --> 00:28:31,020
Entón, iso é tres consultas.

674
00:28:31,020 --> 00:28:34,560
Consultas moi complexas para
montar un conxunto de resultados.

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

676
00:28:36,540 --> 00:28:39,200
É por iso que cando falamos
sobre unha estrutura de datos que é

677
00:28:39,200 --> 00:28:42,900
construído para ser agnóstico ao acceso
pattern-- ben, iso é gran.

678
00:28:42,900 --> 00:28:45,730
E podes ver que é realmente
agradable como organizamos os datos.

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

680
00:28:46,550 --> 00:28:49,750
Eu só teño unha marca para un actor.

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

682
00:28:50,440 --> 00:28:53,750
Eu deduplicados todos os meus actores,
e eu mantiven miñas asociacións

683
00:28:53,750 --> 00:28:55,200
nesta táboa de cartografía.

684
00:28:55,200 --> 00:29:00,620
Con todo, obter os datos
fóra convértese en caro.

685
00:29:00,620 --> 00:29:04,500
Estou enviando a CPU en todo o sistema
xuntando esas estruturas de datos en conxunto

686
00:29:04,500 --> 00:29:05,950
para poder tirar os datos de volta.

687
00:29:05,950 --> 00:29:07,310
>> Entón, como podo evitar isto?

688
00:29:07,310 --> 00:29:11,200
En NoSQL é sobre
agregación, non normalización.

689
00:29:11,200 --> 00:29:13,534
Por iso, queremos dicir que queremos
apoiar o estándar de acceso.

690
00:29:13,534 --> 00:29:15,283
O nivel de acceso
para as aplicacións,

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

692
00:29:16,770 --> 00:29:19,027
Imos poñer todos os produtos nunha táboa.

693
00:29:19,027 --> 00:29:22,110
Se eu poñer todos os produtos nunha táboa,
Só podo seleccionar todos os produtos

694
00:29:22,110 --> 00:29:23,850
a partir desa mesa e eu entendín todo.

695
00:29:23,850 --> 00:29:25,240
Ben, como fago isto?

696
00:29:25,240 --> 00:29:28,124
Ben en NoSQL non hai ningunha
estrutura para a mesa.

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

698
00:29:30,540 --> 00:29:33,570
Pero non ten o mesmo
atributos e as mesmas propiedades

699
00:29:33,570 --> 00:29:37,751
en cada liña única, en cada
elemento, como fai nunha táboa SQL.

700
00:29:37,751 --> 00:29:39,750
E o que me permite
para facer unha chea de cousas

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

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

703
00:29:45,360 --> 00:29:49,090
E nese particular
exemplo todo

704
00:29:49,090 --> 00:29:51,930
é un documento na táboa Produtos.

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

706
00:29:56,510 --> 00:29:59,180
E a aplicación
cambiarían en que ID.

707
00:29:59,180 --> 00:30:02,570
>> Na capa de aplicación, vou
para dicir oh, que tipo de rexistro é iso?

708
00:30:02,570 --> 00:30:04,100
Oh, é un rexistro libro.

709
00:30:04,100 --> 00:30:05,990
Rexistros do libro teñen esas propiedades.

710
00:30:05,990 --> 00:30:08,100
Déixeme crear un obxecto libro.

711
00:30:08,100 --> 00:30:11,289
Entón, eu estou indo a cubrir o
libro obxecto con este elemento.

712
00:30:11,289 --> 00:30:13,080
Seguinte elemento vén e
di, o que é este elemento?

713
00:30:13,080 --> 00:30:14,560
Ben, este elemento é un álbum.

714
00:30:14,560 --> 00:30:17,340
Oh, eu teño un diferente enteiro
rutina de procesamento para que,

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

716
00:30:18,487 --> 00:30:19,320
Ve o que quero dicir?

717
00:30:19,320 --> 00:30:21,950
>> Así, a aplicación tier-- I
basta escoller todos estes rexistros.

718
00:30:21,950 --> 00:30:23,200
Todos comezan a chegar.

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

720
00:30:24,680 --> 00:30:27,590
E é a lóxica da aplicación
que alterna entre tipo

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

722
00:30:29,530 --> 00:30:33,640
>> Unha vez máis, polo que estamos optimizando o
esquema para o estándar de acceso.

723
00:30:33,640 --> 00:30:36,390
Estamos facendo isto por
colapso desas táboas.

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 estamos construíndo
estruturas xerárquicas.

726
00:30:42,000 --> 00:30:45,130
Dentro de cada un destes rexistros
Eu estou indo a ver propiedades de matriz.

727
00:30:45,130 --> 00:30:49,400
>> Dentro deste documento para Álbums,
Estou vendo matrices de pistas.

728
00:30:49,400 --> 00:30:53,900
Estas pistas agora become--
basicamente esta táboa fillo que

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

730
00:30:56,520 --> 00:30:57,975
Así, pode facelo no DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Podes facelo no MongoDB.

732
00:30:59,810 --> 00:31:01,437
Podes facelo en calquera base de datos NoSQL.

733
00:31:01,437 --> 00:31:03,520
Crear estes tipos de
estruturas de datos xerárquicos

734
00:31:03,520 --> 00:31:07,120
que permiten que recuperar datos
moi rapidamente, porque agora eu

735
00:31:07,120 --> 00:31:08,537
Non ten que se conformar.

736
00:31:08,537 --> 00:31:11,620
Cando inserir un ficheiro para as Faixas
mesa, ou un ficheiro nunha tabela de álbums,

737
00:31:11,620 --> 00:31:13,110
Teño que estar de acordo con este esquema.

738
00:31:13,110 --> 00:31:18,060
Eu teño que ter o atributo ou a
propiedade que é definida nesa táboa.

739
00:31:18,060 --> 00:31:20,480
Cada un deles,
cando inserir esa liña.

740
00:31:20,480 --> 00:31:21,910
Isto non é o caso en NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Podo ter totalmente diferente
propiedades en cada documento

742
00:31:24,440 --> 00:31:26,100
que introducir na colección.

743
00:31:26,100 --> 00:31:30,480
Entón mecanismo moi poderoso.

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

745
00:31:32,852 --> 00:31:35,310
Porque agora que consulta, no canto
de xuntar todas esas táboas

746
00:31:35,310 --> 00:31:39,160
e execución dunha media ducia de consultas
para tirar a datos que eu teño,

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

748
00:31:40,890 --> 00:31:43,010
E eu estou a iteración
en todo o conxunto de resultados.

749
00:31:43,010 --> 00:31:46,512
dálle unha idea
do poder de NoSQL.

750
00:31:46,512 --> 00:31:49,470
Eu estou indo a ir ao lado tipo de aquí
e falar un pouco sobre iso.

751
00:31:49,470 --> 00:31:53,240
Isto é máis do tipo
comercialización ou technology--

752
00:31:53,240 --> 00:31:55,660
a comercialización de tecnoloxía
tipo de discusión.

753
00:31:55,660 --> 00:31:58,672
Pero é importante entender
porque, se miramos a arriba

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

755
00:32:00,380 --> 00:32:04,030
é o que chamamos
curva campaña publicitaria tecnoloxía.

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

757
00:32:06,121 --> 00:32:07,120
A xente pensa que é óptimo.

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

759
00:32:09,200 --> 00:32:11,630
>> Esta podería ser a extrema
todo, ser todo de todo.

760
00:32:11,630 --> 00:32:12,790
E comezan a usalo.

761
00:32:12,790 --> 00:32:14,720
E din, esa cousa non funciona.

762
00:32:14,720 --> 00:32:17,600
Iso non é certo.

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

764
00:32:19,105 --> 00:32:21,230
E eles van voltar a facer
as cousas do xeito que estaban.

765
00:32:21,230 --> 00:32:22,730
E despois, finalmente,
van, vostede sabe o que?

766
00:32:22,730 --> 00:32:24,040
Este material non é tan malo.

767
00:32:24,040 --> 00:32:26,192
Oh, así é como funciona.

768
00:32:26,192 --> 00:32:28,900
E xa que descubrir como
obras, comezan a ir mellor.

769
00:32:28,900 --> 00:32:32,050
>> E o curioso sobre iso
é, que tipo de liñas ata que

770
00:32:32,050 --> 00:32:34,300
chamamos a Curva de Adopción de Tecnoloxía.

771
00:32:34,300 --> 00:32:36,910
Entón o que pasa é que temos
algún tipo de gatillo tecnoloxía.

772
00:32:36,910 --> 00:32:39,100
No caso das bases de datos,
é a presión de datos.

773
00:32:39,100 --> 00:32:42,200
Nós falamos sobre os puntos de auga altos
datos de presión ao longo do tempo.

774
00:32:42,200 --> 00:32:46,310
Cando esta presión alcanza un certo datos
punto, iso é un gatillo tecnoloxía.

775
00:32:46,310 --> 00:32:47,830
>> Está quedando moi caro.

776
00:32:47,830 --> 00:32:49,790
Leva moito tempo para procesar os datos.

777
00:32:49,790 --> 00:32:50,890
Necesitamos algo mellor.

778
00:32:50,890 --> 00:32:52,890
Obtén os innovadores
aí correndo por aí,

779
00:32:52,890 --> 00:32:55,050
tentando descubrir cal é a solución.

780
00:32:55,050 --> 00:32:56,050
Cal é a nova idea?

781
00:32:56,050 --> 00:32:58,170
>> Cal é a mellor próxima
forma de facelo?

782
00:32:58,170 --> 00:32:59,530
E eles veñen para arriba con algo.

783
00:32:59,530 --> 00:33:03,140
E a xente coa dor real,
os individuos no bordo do sangramento,

784
00:33:03,140 --> 00:33:06,390
van ir todo sobre el,
porque precisan dunha resposta.

785
00:33:06,390 --> 00:33:09,690
Agora, o que inevitablemente happens-- e
isto está a suceder agora en NoSQL.

786
00:33:09,690 --> 00:33:11,090
Eu vexo iso o tempo.

787
00:33:11,090 --> 00:33:13,610
>> O que pasa é inevitablemente
persoas comezan a usar a nova ferramenta

788
00:33:13,610 --> 00:33:15,490
do mesmo xeito que usou a ferramenta de idade.

789
00:33:15,490 --> 00:33:17,854
E descubrir que
non funciona tan ben.

790
00:33:17,854 --> 00:33:20,020
Non lembro quen era
falando antes hoxe.

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

792
00:33:22,080 --> 00:33:24,621
a xente non balanza-lo sobre
súa cabeza para romper o formigón.

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

794
00:33:27,360 --> 00:33:30,610
>> Pero iso é o que é
pasando con NoSQL hoxe.

795
00:33:30,610 --> 00:33:33,900
Se camiña para a maioría das tendas,
eles están tentando ser tendas NoSQL.

796
00:33:33,900 --> 00:33:36,510
O que están facendo é
eles están usando NoSQL,

797
00:33:36,510 --> 00:33:39,900
e eles están carregando-
cheo de esquema relacional.

798
00:33:39,900 --> 00:33:41,630
Porque é así que
eles proxectan bases de datos.

799
00:33:41,630 --> 00:33:44,046
E eles están se pregunta, por que é
non realizar moi ben?

800
00:33:44,046 --> 00:33:45,230
Rapaz, esa cousa fede.

801
00:33:45,230 --> 00:33:49,900
Tiven que manter toda a miña
xunta-se em-- como é, non, non.

802
00:33:49,900 --> 00:33:50,800
Manter xunta?

803
00:33:50,800 --> 00:33:52,430
Por que está xuntando datos?

804
00:33:52,430 --> 00:33:54,350
Non unirse datos NoSQL.

805
00:33:54,350 --> 00:33:55,850
Vostede agregar-lo.

806
00:33:55,850 --> 00:34:00,690
>> Entón, se quere evitar isto, aprender
como a ferramenta funciona antes de que realmente

807
00:34:00,690 --> 00:34:02,010
comezar a usalo.

808
00:34:02,010 --> 00:34:04,860
Non tente utilizar as novas ferramentas do
mesmo xeito que usou as ferramentas antigas.

809
00:34:04,860 --> 00:34:06,500
Terá unha experiencia malo.

810
00:34:06,500 --> 00:34:08,848
E cada vez
iso é o que se trata.

811
00:34:08,848 --> 00:34:11,389
Cando comezan a chegar ata aquí,
é porque a xente descubriron

812
00:34:11,389 --> 00:34:13,449
como usar as ferramentas.

813
00:34:13,449 --> 00:34:16,250
>> Fixeron o mesmo cando
bases de datos relacionais foron inventados,

814
00:34:16,250 --> 00:34:17,969
e eles estaban substituíndo os sistemas de ficheiros.

815
00:34:17,969 --> 00:34:20,420
Intentaron construír sistemas de ficheiros
con bases de datos relacionais

816
00:34:20,420 --> 00:34:22,159
porque iso é o que a xente entendesen.

817
00:34:22,159 --> 00:34:23,049
Non funcionou.

818
00:34:23,049 --> 00:34:26,090
Así, a comprensión das prácticas
da tecnoloxía está a traballar con

819
00:34:26,090 --> 00:34:26,730
é enorme.

820
00:34:26,730 --> 00:34:29,870
Moi importante.

821
00:34:29,870 --> 00:34:32,440
>> Entón, nós estamos indo a entrar en DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB é AWS de
totalmente de xestión plataforma NoSQL.

823
00:34:36,480 --> 00:34:37,719
Que totalmente de xestión significa?

824
00:34:37,719 --> 00:34:40,010
Isto significa que non precisa
realmente se preocupe de nada.

825
00:34:40,010 --> 00:34:42,060
>> Entra, di
nós, eu teño unha mesa.

826
00:34:42,060 --> 00:34:43,409
El que de tanta capacidade.

827
00:34:43,409 --> 00:34:47,300
Prema o botón, e provisión nós
toda infraestrutura detrás da escena.

828
00:34:47,300 --> 00:34:48,310
Agora que é enorme.

829
00:34:48,310 --> 00:34:51,310
>> Porque cando fala
sobre o deseño dunha base de datos,

830
00:34:51,310 --> 00:34:53,917
Clusters de datos NoSQL na
escala, petabytes de funcionamento,

831
00:34:53,917 --> 00:34:55,750
executando millóns de
transaccións por segundo,

832
00:34:55,750 --> 00:34:58,180
estas cousas non son pequenos clusters.

833
00:34:58,180 --> 00:35:00,830
Estamos a falar de miles de casos.

834
00:35:00,830 --> 00:35:04,480
Xestión de miles de exemplares,
incluso instancias virtuais,

835
00:35:04,480 --> 00:35:06,350
é unha verdadeira dor na bunda.

836
00:35:06,350 --> 00:35:09,110
É dicir, pensar en cada vez que un
parche de sistema operativo sae

837
00:35:09,110 --> 00:35:11,552
ou unha nova versión da base de datos.

838
00:35:11,552 --> 00:35:13,260
Que significa iso
operativo a vostede?

839
00:35:13,260 --> 00:35:16,330
Isto significa que ten 1200
servidores que precisan ser actualizados.

840
00:35:16,330 --> 00:35:18,960
Agora mesmo coa automatización,
que pode levar moito tempo.

841
00:35:18,960 --> 00:35:21,480
Isto pode causar unha serie de
dores de cabeza operativos,

842
00:35:21,480 --> 00:35:23,090
porque eu podería servizos abaixo.

843
00:35:23,090 --> 00:35:26,070
>> Cómo actualizar esas bases de datos, I
pode facer implantacións verde azul

844
00:35:26,070 --> 00:35:29,420
onde implantar e actualizar a metade da miña
nós, e despois actualizar a outra metade.

845
00:35:29,420 --> 00:35:30,490
Tome aqueles abaixo.

846
00:35:30,490 --> 00:35:33,410
Polo tanto, a xestión da infraestrutura
escala é moi doloroso.

847
00:35:33,410 --> 00:35:36,210
E AWS asumir que a dor de fóra.

848
00:35:36,210 --> 00:35:39,210
E bases de datos NoSQL pode
ser extraordinariamente Dolores

849
00:35:39,210 --> 00:35:41,780
por mor da maneira que escala.

850
00:35:41,780 --> 00:35:42,926
>> Dimensionar horizontal.

851
00:35:42,926 --> 00:35:45,550
Se quere obter un maior NoSQL
base de datos, compra máis nós.

852
00:35:45,550 --> 00:35:48,660
Cada nodo que compra é
outra cabeza operativo.

853
00:35:48,660 --> 00:35:50,830
Entón deixe alguén facelo por vostede.

854
00:35:50,830 --> 00:35:52,000
AWS pode facelo.

855
00:35:52,000 --> 00:35:54,587
>> Apoiamos os valores clave do documento.

856
00:35:54,587 --> 00:35:56,670
Agora non ir moi
Doutra en gráfico.

857
00:35:56,670 --> 00:35:58,750
Hai unha morea de diferentes
sabor de NoSQL.

858
00:35:58,750 --> 00:36:02,670
Son todo tipo de conseguir
munged xuntos neste momento.

859
00:36:02,670 --> 00:36:06,260
Podes ollar para DynamoDB e dicir que si,
nos dous somos un documento e un valor de clave

860
00:36:06,260 --> 00:36:08,412
almacenar este punto.

861
00:36:08,412 --> 00:36:10,620
E pode discutir as características
dun sobre o outro.

862
00:36:10,620 --> 00:36:13,950
Para min, unha morea de presente é realmente seis
dunha media ducia de outro.

863
00:36:13,950 --> 00:36:18,710
Cada unha destas tecnoloxías é un
tecnoloxía de multa e unha solución ben.

864
00:36:18,710 --> 00:36:23,390
Eu non diría que é mellor ou MongoDB
peor que Couch, a continuación, Cassandra,

865
00:36:23,390 --> 00:36:25,994
entón Dynamo, ou viceversa.

866
00:36:25,994 --> 00:36:27,285
Quero dicir, estes son só opcións.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> É rápido e é
consistente en calquera escala.

869
00:36:32,700 --> 00:36:36,210
Polo tanto, este é un dos maiores
bonos que comeza coa AWS.

870
00:36:36,210 --> 00:36:40,850
Con DynamoDB é a posibilidade
para obter un baixo único díxito

871
00:36:40,850 --> 00:36:44,040
latencia milissegundo en calquera escala.

872
00:36:44,040 --> 00:36:45,720
Esa era unha meta de proxecto do sistema.

873
00:36:45,720 --> 00:36:49,130
E temos clientes que están a facer
millóns de operacións por segundo.

874
00:36:49,130 --> 00:36:52,670
>> Agora eu vou pasar por algunhas das persoas
usar casos en poucos minutos aquí.

875
00:36:52,670 --> 00:36:55,660
Control-- acceso integrado
temos o que chamamos

876
00:36:55,660 --> 00:36:57,920
Xestión de Acceso identidade ou IAM.

877
00:36:57,920 --> 00:37:01,980
Ela permeia todos os sistemas,
todos os servizos que a AWS ofrece.

878
00:37:01,980 --> 00:37:03,630
DynamoDB sen excepción.

879
00:37:03,630 --> 00:37:06,020
Pode controlar o acceso
para as táboas DynamoDB.

880
00:37:06,020 --> 00:37:09,960
En todas as súas contas por AWS
definición de funcións de acceso e permisos

881
00:37:09,960 --> 00:37:12,140
na infraestrutura de IAM.

882
00:37:12,140 --> 00:37:16,630
>> E é un compoñente fundamental e integral en
o que chamamos eventos programación orientada.

883
00:37:16,630 --> 00:37:19,056
Agora, este é un novo paradigma.

884
00:37:19,056 --> 00:37:22,080
>> Audiencia: Como é a súa taxa de certa
positivos contra falsos negativos

885
00:37:22,080 --> 00:37:24,052
no seu sistema de control de acceso?

886
00:37:24,052 --> 00:37:26,260
Rick Houlihan: Certos positivas
contra falsos negativos?

887
00:37:26,260 --> 00:37:28,785
Audiencia: Devolver o que
ten que estar retornando?

888
00:37:28,785 --> 00:37:33,720
A diferenza de cando en cando
non retorna cando debe validar?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> Rick Houlihan: Eu non podería che dicir iso.

891
00:37:38,050 --> 00:37:40,140
Se hai calquera fallos
calquera que sexa, que,

892
00:37:40,140 --> 00:37:42,726
Non son a persoa para preguntar
esta cuestión particular.

893
00:37:42,726 --> 00:37:43,850
Pero iso é unha boa pregunta.

894
00:37:43,850 --> 00:37:45,905
Eu sería curioso para saber
que, en realidade.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> E así, de novo, novo paradigma
está dirixida evento programación.

897
00:37:51,320 --> 00:37:55,160
Esta é a idea de que se pode
implantar aplicacións complexos que

898
00:37:55,160 --> 00:37:59,720
pode operar un moi, moi alta escala
sen infraestrutura calquera.

899
00:37:59,720 --> 00:38:02,120
Sen fixo
infraestrutura calquera.

900
00:38:02,120 --> 00:38:04,720
E nós imos falar un pouco
sobre o que iso significa que nós

901
00:38:04,720 --> 00:38:06,550
obter no seguinte par de cartas.

902
00:38:06,550 --> 00:38:08,716
>> O primeiro que imos facer
é falaremos sobre mesas.

903
00:38:08,716 --> 00:38:10,857
Tipos de datos API para Dynamo.

904
00:38:10,857 --> 00:38:13,190
E o primeiro que vai
notar cando mira para iso,

905
00:38:13,190 --> 00:38:17,930
se está familiarizado con calquera base de datos,
bases de datos teñen realmente dous tipos de APIs

906
00:38:17,930 --> 00:38:18,430
Eu diría que é.

907
00:38:18,430 --> 00:38:21,570
Ou dous conxuntos de API.

908
00:38:21,570 --> 00:38:23,840
Unha delas sería
API administrativa.

909
00:38:23,840 --> 00:38:26,710
>> As cousas que coidan de
as funcións de base de datos.

910
00:38:26,710 --> 00:38:31,340
Configurar o mecanismo de almacenamento,
a creación e inclusión de táboas.

911
00:38:31,340 --> 00:38:35,180
creación de bases de datos
catálogos e instancias.

912
00:38:35,180 --> 00:38:40,450
Estes coisas- en DynamoDB, vostede
teñen listas moi curto, curto.

913
00:38:40,450 --> 00:38:43,120
>> Polo tanto, noutras bases de datos,
podes ver decenas

914
00:38:43,120 --> 00:38:45,680
de comandos, de administrativa
comandos, para a configuración

915
00:38:45,680 --> 00:38:47,290
estas opcións adicionais.

916
00:38:47,290 --> 00:38:51,234
En DynamoDB non precisa os porque
non configurar o sistema, o que facemos.

917
00:38:51,234 --> 00:38:54,150
Entón o único que tes que facer é
me diga o que mesa tamaño eu teño.

918
00:38:54,150 --> 00:38:55,660
Entón comeza un moi
conxunto limitado de comandos.

919
00:38:55,660 --> 00:38:58,618
>> Comeza unha Create Table Update, Mesa,
Eliminar Mesa, e describir Table.

920
00:38:58,618 --> 00:39:01,150
Estas son as únicas cousas
precisa para DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Non precisa de un almacenamento
configuración do motor.

922
00:39:03,294 --> 00:39:04,960
Non se preocupe coa replicación.

923
00:39:04,960 --> 00:39:06,490
Non se preocupe sharding.

924
00:39:06,490 --> 00:39:07,800
>> Non se preocupe
sobre algún deste material.

925
00:39:07,800 --> 00:39:08,740
Facemos todo para ti.

926
00:39:08,740 --> 00:39:11,867
Entón, iso é unha enorme cantidade de sobrecarga
iso é só despegou seu prato.

927
00:39:11,867 --> 00:39:13,200
Entón temos os operadores CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD é algo que temos
chamar base de datos que é

929
00:39:17,740 --> 00:39:19,860
Crear, actualizar, eliminar operadores.

930
00:39:19,860 --> 00:39:24,180
Estes son os seus común
operacións de base de datos.

931
00:39:24,180 --> 00:39:31,299
Cousas como elemento de venda, obter elemento, actualización
elementos, borrar obxectos, consulta de lote, dixitalizar.

932
00:39:31,299 --> 00:39:32,840
Se quere comprobar a táboa enteira.

933
00:39:32,840 --> 00:39:34,220
Puxe todo fóra da mesa.

934
00:39:34,220 --> 00:39:37,130
Unha das cousas agradables sobre DynamoDB
é que permite a dixitalización paralela.

935
00:39:37,130 --> 00:39:40,602
Entón pode realmente deixe-me saber cantas
temas que quere executar no que dixitalización.

936
00:39:40,602 --> 00:39:41,810
E podemos facer eses temas.

937
00:39:41,810 --> 00:39:43,985
Podemos xirar que dixitalizar ata
a través de múltiples threads

938
00:39:43,985 --> 00:39:49,060
para que poida comprobar a táboa enteira
espazo moi, moi rapidamente no DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> A outra API que temos é
o que chamamos a nosa API Fluxos.

940
00:39:51,490 --> 00:39:52,940
Non imos falar moito
moito sobre iso agora.

941
00:39:52,940 --> 00:39:55,189
Eu teño algún contido máis tarde
en no baralla sobre iso.

942
00:39:55,189 --> 00:39:59,910
Pero Fluxos é realmente un running--
pense nisto como o tempo orde

943
00:39:59,910 --> 00:40:01,274
e rexistro de cambios partición.

944
00:40:01,274 --> 00:40:03,940
Todo o que está a suceder no
a táboa móstrase no fluxo.

945
00:40:03,940 --> 00:40:05,940
>> Cada escribir á mesa
móstrase no fluxo.

946
00:40:05,940 --> 00:40:08,370
Podes ler este fluxo, e
pode facer cousas con el.

947
00:40:08,370 --> 00:40:10,150
Imos falar sobre o que
tipo de cousas que

948
00:40:10,150 --> 00:40:13,680
facer as cousas como replicación,
a creación de índices secundarios.

949
00:40:13,680 --> 00:40:17,620
Todo tipo de moi legal
cousas que podes facer con iso.

950
00:40:17,620 --> 00:40:19,150
>> Tipo de datos.

951
00:40:19,150 --> 00:40:23,320
En DynamoDB, apoiamos tanto clave
valor e de datos documento tipos.

952
00:40:23,320 --> 00:40:26,350
Na parte esquerda da pantalla
aquí, temos os nosos tipos básicos.

953
00:40:26,350 --> 00:40:27,230
Tipo de valor clave.

954
00:40:27,230 --> 00:40:30,040
Estes son cordas,
números e binarios.

955
00:40:30,040 --> 00:40:31,640
>> Entón, só tres tipos básicos.

956
00:40:31,640 --> 00:40:33,700
E entón vostede pode ter conxuntos de aqueles.

957
00:40:33,700 --> 00:40:37,650
Unha das cousas agradables sobre NoSQL é
pode conter matrices como propiedades.

958
00:40:37,650 --> 00:40:42,050
E con DynamoDB pode conter matrices
de tipos básicos como unha propiedade raíz.

959
00:40:42,050 --> 00:40:43,885
>> E despois hai os tipos de documentos.

960
00:40:43,885 --> 00:40:45,510
Cantas persoas están familiarizado con JSON?

961
00:40:45,510 --> 00:40:47,130
Vostedes familiarizado con JSON tanto?

962
00:40:47,130 --> 00:40:49,380
É basicamente JavaScript,
Object, Notation.

963
00:40:49,380 --> 00:40:52,510
Permite que basicamente
definir unha estrutura xerárquica.

964
00:40:52,510 --> 00:40:58,107
>> Pode almacenar un documento JSON en
DynamoDB usando compoñentes comúns

965
00:40:58,107 --> 00:41:00,940
ou bloques de construción que están dispoñibles
na maioría das linguaxes de programación.

966
00:41:00,940 --> 00:41:03,602
Entón, se ten o Java, está
mirando os mapas e listas.

967
00:41:03,602 --> 00:41:05,060
Podo crear obxectos que zona do mapa.

968
00:41:05,060 --> 00:41:08,030
Un mapa como valores clave
almacenado como propiedades.

969
00:41:08,030 --> 00:41:10,890
E pode que as listas de
valores dentro destas propiedades.

970
00:41:10,890 --> 00:41:13,490
Pode almacenar este complexo
estrutura xerárquica

971
00:41:13,490 --> 00:41:16,320
como un único atributo
dun elemento de DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Entón táboas no DynamoDB, como a maioría
Bases de datos NoSQL, as táboas teñen elementos.

974
00:41:24,460 --> 00:41:26,469
En MongoDB faría
chamar estes documentos.

975
00:41:26,469 --> 00:41:27,760
E sería a base sofá.

976
00:41:27,760 --> 00:41:28,900
Ademais unha base de datos de documento.

977
00:41:28,900 --> 00:41:29,941
Chama eses documentos.

978
00:41:29,941 --> 00:41:32,930
Documentos ou elementos teñen atributos.

979
00:41:32,930 --> 00:41:35,850
Pode existir atributos ou
non existe no produto.

980
00:41:35,850 --> 00:41:38,520
En DynamoDB, hai
un atributo obrigatorio.

981
00:41:38,520 --> 00:41:43,880
Así como nunha base de datos relacional,
ten unha chave primaria nunha tabela.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB ten o que chamamos unha chave de hash.

983
00:41:46,010 --> 00:41:48,280
Clave de hash debe ser exclusivo.

984
00:41:48,280 --> 00:41:52,580
Entón, cando definir unha táboa hash,
basicamente o que eu digo

985
00:41:52,580 --> 00:41:54,110
cada elemento terá unha clave de hash.

986
00:41:54,110 --> 00:41:58,520
E cada clave de hash debe ser exclusivo.

987
00:41:58,520 --> 00:42:01,200
>> Cada elemento defínese
por esa chave de mestura orixinal.

988
00:42:01,200 --> 00:42:02,940
E só pode haber un.

989
00:42:02,940 --> 00:42:05,820
Este é OK, pero moitas veces
que as persoas precisan

990
00:42:05,820 --> 00:42:08,170
é que eles queren é ese hash
clave para facer un pouco máis

991
00:42:08,170 --> 00:42:11,010
que ser un identificador único.

992
00:42:11,010 --> 00:42:15,240
Moitas veces queremos usar esta chave de hash
como o cumio balde agregación nivel.

993
00:42:15,240 --> 00:42:19,160
E o xeito de facermos isto é por
engadindo o que chamamos unha clave intervalo.

994
00:42:19,160 --> 00:42:22,460
>> Entón, se é só un hash
mesa, esta debe ser exclusivo.

995
00:42:22,460 --> 00:42:27,040
Se é unha táboa hash e variedade, o
combinación do hash eo intervalo

996
00:42:27,040 --> 00:42:28,640
debe ser exclusivo.

997
00:42:28,640 --> 00:42:30,110
Entón, pense nisto deste xeito.

998
00:42:30,110 --> 00:42:32,140
Se eu tivera un foro.

999
00:42:32,140 --> 00:42:39,010
E a forma ten temas, ten
lanza, e ten respostas.

1000
00:42:39,010 --> 00:42:42,630
>> Entón, eu podería ter un hash
clave, que é a identificación de tema.

1001
00:42:42,630 --> 00:42:46,650
E eu podería ter unha clave de gama,
que representa a identificación da resposta.

1002
00:42:46,650 --> 00:42:49,650
Desta forma, se eu queira obter toda a
respostas a determinado tema,

1003
00:42:49,650 --> 00:42:52,370
Só podo consultar o hash.

1004
00:42:52,370 --> 00:42:55,190
Podo só dicir que me dar todo
os elementos que teñen ese hash.

1005
00:42:55,190 --> 00:43:01,910
E eu estou indo a obter todas as preguntas
ou engadir a este tema particular.

1006
00:43:01,910 --> 00:43:03,910
Estas agregacións de nivel superior
é moi importante.

1007
00:43:03,910 --> 00:43:07,370
Eles soportan o acceso primario
estándar da aplicación.

1008
00:43:07,370 --> 00:43:09,420
Dun modo xeral, esta
é o que queremos facer.

1009
00:43:09,420 --> 00:43:11,780
Queremos que mesa--
como cargar a táboa,

1010
00:43:11,780 --> 00:43:16,640
queremos estruturar a datos
dentro da táboa de tal xeito

1011
00:43:16,640 --> 00:43:20,140
que a aplicación pode moi
recuperar rapidamente eses resultados.

1012
00:43:20,140 --> 00:43:24,510
E moitas veces a forma de facelo é
para manter estas agregacións como nós

1013
00:43:24,510 --> 00:43:25,650
introducir os datos.

1014
00:43:25,650 --> 00:43:31,110
Basicamente, estamos espallando os datos
no balde brillante como ven en.

1015
00:43:31,110 --> 00:43:35,210
>> Intervalo de claves de hash permitir me--
claves ten que ser igualdade.

1016
00:43:35,210 --> 00:43:39,490
Cando consultar un hash, eu teño que dicir
déame un hash que é igual a este.

1017
00:43:39,490 --> 00:43:41,950
Cando consultar un intervalo, eu
pode dicir-me dar un intervalo

1018
00:43:41,950 --> 00:43:47,040
que está a usar calquera tipo de
operador rico que apoiamos.

1019
00:43:47,040 --> 00:43:49,200
Déame todos os elementos para un hash.

1020
00:43:49,200 --> 00:43:52,520
É igual, maior que,
menos que, non é comezar,

1021
00:43:52,520 --> 00:43:54,145
existe entre estes dous valores?

1022
00:43:54,145 --> 00:43:56,811
Entón, estes tipos de consultas de intervalo
que estamos sempre interesados ​​en.

1023
00:43:56,811 --> 00:43:59,650
Agora unha cousa sobre os datos, cando
ollar para o acceso a datos, cando

1024
00:43:59,650 --> 00:44:02,360
acceder os datos, é
sempre sobre unha agregación.

1025
00:44:02,360 --> 00:44:05,770
É sempre sobre os rexistros
que están relacionados con este.

1026
00:44:05,770 --> 00:44:10,390
Dáme todo aquí that's-- todo
as transaccións de tarxeta de crédito nesta

1027
00:44:10,390 --> 00:44:12,500
para o último mes.

1028
00:44:12,500 --> 00:44:13,960
Isto é unha agregación.

1029
00:44:13,960 --> 00:44:17,490
>> Case todo o que fai no
base de datos é un tipo de agregación.

1030
00:44:17,490 --> 00:44:21,530
Así, ser capaz de poder establecer
estes baldes e darlle estes varían

1031
00:44:21,530 --> 00:44:24,950
atributos de poder consulta en,
esas consultas ricos apoiar moitos,

1032
00:44:24,950 --> 00:44:27,165
moitos, moitos patróns de acceso da aplicación.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Entón a outra cousa a clave de hash
fai é que nos dá un mecanismo

1035
00:44:35,000 --> 00:44:37,740
para poder difundir os datos de volta.

1036
00:44:37,740 --> 00:44:40,390
Bases de datos NoSQL funcionar mellor
cando os datos están uniformemente

1037
00:44:40,390 --> 00:44:41,740
distribuídos en todo o cluster.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Cantas persoas están familiarizado
con algoritmos de hash?

1040
00:44:47,050 --> 00:44:49,860
Cando digo de hash e un hashing--
porque un algoritmo de hashing

1041
00:44:49,860 --> 00:44:54,140
é un xeito de ser capaz de xerar
un valor aleatorio de calquera valor dado.

1042
00:44:54,140 --> 00:44:59,300
Polo tanto, neste caso particular, o
algoritmo de hash que corremos é ND 5 con base.

1043
00:44:59,300 --> 00:45:04,765
>> E se eu tivera un ID, e este
é a miña chave de hash, eu teño 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Cando executar o algoritmo de hash,
vai volver e dicir,

1045
00:45:07,390 --> 00:45:10,800
pozo 1 é igual a 7B, 2
é igual a 48, é igual a 3 CD.

1046
00:45:10,800 --> 00:45:13,092
Eles están espallados por todo o espazo da chave.

1047
00:45:13,092 --> 00:45:14,050
E por que fai iso?

1048
00:45:14,050 --> 00:45:17,120
Porque iso garante que podo
poñer os rexistros en varios nós.

1049
00:45:17,120 --> 00:45:19,574
>> Se eu estou facendo iso
incrementalmente, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
E eu teño unha variedade de hash que
rons, neste caso concreto,

1051
00:45:21,990 --> 00:45:24,785
un pequeno espazo de hash,
que vai de 00 a FF,

1052
00:45:24,785 --> 00:45:27,951
a continuación, os rexistros van vir en
e eles están indo a 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
Que pasa?

1055
00:45:31,800 --> 00:45:34,860
Cada inserción é indo ao mesmo nodo.

1056
00:45:34,860 --> 00:45:36,070
Ve o que quero dicir?

1057
00:45:36,070 --> 00:45:40,910
>> Porque cando dividir o espazo,
e eu estender eses rexistros transversalmente,

1058
00:45:40,910 --> 00:45:45,950
e partición eu, eu vou dicir
partición 1 ten espazo clave 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partición 2 é 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partición 3 é AA a FF.

1061
00:45:49,780 --> 00:45:53,740
Entón, se está a usar linearmente incrementando
IDs, podes ver o que está pasando.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, todos fórmase a 54.

1063
00:45:57,410 --> 00:46:00,030
Entón, como eu estou martelé a
rexistros no sistema,

1064
00:46:00,030 --> 00:46:02,030
todo acaba indo a un nodo.

1065
00:46:02,030 --> 00:46:03,160
>> Iso non é bo.

1066
00:46:03,160 --> 00:46:04,820
Esa é unha antipattern.

1067
00:46:04,820 --> 00:46:08,760
En MongoDB teñen este problema
se non usar unha chave de hash.

1068
00:46:08,760 --> 00:46:11,325
MongoDB lle dá a opción
de hash o valor da clave.

1069
00:46:11,325 --> 00:46:13,950
Ten que sempre facer iso, se
está a usar un hash incrementando

1070
00:46:13,950 --> 00:46:17,380
clave no MongoDB, ou vai ser
cravando cada gravación para un nó,

1071
00:46:17,380 --> 00:46:21,290
e vai ser un factor limitante
o seu rendemento escribir mal.

1072
00:46:21,290 --> 00:46:24,896
>> Audiencia: É que A9 169 en decimal?

1073
00:46:24,896 --> 00:46:28,450
>> Rick Houlihan: Si, é
algo en torno de alí.

1074
00:46:28,450 --> 00:46:29,950
A9, eu non sei.

1075
00:46:29,950 --> 00:46:32,200
Vostede tería que incorporarse miña binario
a calculadora decimal.

1076
00:46:32,200 --> 00:46:34,237
Meu cerebro non funciona así.

1077
00:46:34,237 --> 00:46:36,320
Audiencia: Só un rápido
Seus comentarios Mongo.

1078
00:46:36,320 --> 00:46:39,530
Así é a identificación do obxecto que vén
nativamente con Mongo facelo?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
Rick Houlihan: Será que faría iso?

1081
00:46:41,470 --> 00:46:42,970
Se especifica-lo.

1082
00:46:42,970 --> 00:46:45,030
Con MongoDB, ten a opción.

1083
00:46:45,030 --> 00:46:48,930
Pode specify-- cada documento
MongoDB ten que ter un ID subliñado.

1084
00:46:48,930 --> 00:46:50,300
Ese é o valor único.

1085
00:46:50,300 --> 00:46:55,240
>> En MongoDB pode especificar
a hash-lo ou non.

1086
00:46:55,240 --> 00:46:56,490
Eles só darlle a opción.

1087
00:46:56,490 --> 00:46:58,198
Se sabe que é
aleatoria, non hai problema.

1088
00:46:58,198 --> 00:46:59,640
Non precisa facelo.

1089
00:46:59,640 --> 00:47:04,260
Se sabe que non é aleatorio, que
está incrementando, a continuación, facer o hash.

1090
00:47:04,260 --> 00:47:06,880
>> Agora, a cousa sobre
hashing, xa que o hash

1091
00:47:06,880 --> 00:47:08,800
un value-- e esta é
por que claves de hash son sempre

1092
00:47:08,800 --> 00:47:13,740
consultas únicas, porque eu mudei
o valor, agora eu non podo facer unha consulta intervalo.

1093
00:47:13,740 --> 00:47:15,640
Non podo dicir é isto
entre iso ou aquilo,

1094
00:47:15,640 --> 00:47:20,800
porque o valor de hash non vai
como equivalente ao valor real.

1095
00:47:20,800 --> 00:47:24,570
Entón, cando hash que
clave, é só a igualdade.

1096
00:47:24,570 --> 00:47:28,700
É por iso que en clave de hash DynamoDB
consultas son sempre só a igualdade.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Entón, agora a unha escala key--
cando engadir esta chave gama,

1099
00:47:34,700 --> 00:47:38,180
estes rexistros principais alcance todos entrar e
quedan almacenados no mesmo partición.

1100
00:47:38,180 --> 00:47:42,430
Entón, eles están moi rapidamente, facilmente
recuperado porque este é o hash,

1101
00:47:42,430 --> 00:47:43,220
esta é a variedade.

1102
00:47:43,220 --> 00:47:44,928
E ve todo
co mesmo hash

1103
00:47:44,928 --> 00:47:48,550
fica almacenado no mesmo espazo de partición.

1104
00:47:48,550 --> 00:47:53,889
Pode usar esta chave para axudar a gama
atopar os seus datos preto do seu pai.

1105
00:47:53,889 --> 00:47:55,180
Entón, o que realmente estou facendo aquí?

1106
00:47:55,180 --> 00:47:57,320
Esta é unha relación un para moitos.

1107
00:47:57,320 --> 00:48:01,490
A relación entre unha chave de hash
ea tecla de intervalo é de un a moitos.

1108
00:48:01,490 --> 00:48:03,490
Podo ter varias claves de hash.

1109
00:48:03,490 --> 00:48:07,610
Só pode ter rango múltiple
claves dentro de cada clave de hash.

1110
00:48:07,610 --> 00:48:11,910
>> O hash define o pai,
o intervalo define os nenos.

1111
00:48:11,910 --> 00:48:15,240
Así pode ver que hai analóxica aquí
entre o construto relacional

1112
00:48:15,240 --> 00:48:18,840
e os mesmos tipos de
constrúe en NoSQL.

1113
00:48:18,840 --> 00:48:20,760
A xente fala sobre
NoSQL como non relacional.

1114
00:48:20,760 --> 00:48:22,200
Non é nonrelational.

1115
00:48:22,200 --> 00:48:24,680
Datos sempre relacións.

1116
00:48:24,680 --> 00:48:28,172
Estas relacións só
son modeladas polo diferente.

1117
00:48:28,172 --> 00:48:29,880
Imos falar un pouco
pouco sobre durabilidade.

1118
00:48:29,880 --> 00:48:34,860
Cando escribe para DynamoDB, escribe
son sempre tres vías replicado.

1119
00:48:34,860 --> 00:48:37,550
O que significa que temos tres AZ de.

1120
00:48:37,550 --> 00:48:39,160
Z son de Zonas de dispoñibilidade.

1121
00:48:39,160 --> 00:48:43,430
Podes pensar en un Dispoñibilidade
Zona como un centro de datos

1122
00:48:43,430 --> 00:48:45,447
ou un conxunto de centros de datos.

1123
00:48:45,447 --> 00:48:47,780
Esas cousas son xeograficamente
illados uns dos outros

1124
00:48:47,780 --> 00:48:51,610
en diferentes zonas de fallos, a través
diferentes redes de enerxía e chairas aluviais.

1125
00:48:51,610 --> 00:48:54,510
Un fallo nun AZ non é
indo para derrubar o outro.

1126
00:48:54,510 --> 00:48:56,890
Eles están conectados
xunto coa fibra escura.

1127
00:48:56,890 --> 00:49:01,240
Soporta unha sub 1
latencia milissegundo entre AZS.

1128
00:49:01,240 --> 00:49:05,390
Así repeticións de datos en tempo real
capaz de multi AZS.

1129
00:49:05,390 --> 00:49:09,990
>> E implementacións miúdo multi-Z
atender aos requirimentos de alta dispoñibilidade

1130
00:49:09,990 --> 00:49:12,930
da maioría das organizacións empresariais.

1131
00:49:12,930 --> 00:49:16,139
Entón DynamoDB está espallada
en tres AZS por defecto.

1132
00:49:16,139 --> 00:49:19,430
Estamos indo só para o coñecemento da escrita
cando dous destes tres nós volver

1133
00:49:19,430 --> 00:49:21,470
e dicir: Si, eu teño.

1134
00:49:21,470 --> 00:49:22,050
Por que é iso?

1135
00:49:22,050 --> 00:49:25,950
Porque no lado da lectura estamos só
vai darlle os datos de volta cando

1136
00:49:25,950 --> 00:49:27,570
nós obtelo de dous nós.

1137
00:49:27,570 --> 00:49:30,490
>> Se eu estou replicar en toda
tres, e eu estou lendo a partir de dous,

1138
00:49:30,490 --> 00:49:32,840
Estou sempre garantida
ter polo menos un

1139
00:49:32,840 --> 00:49:35,720
daqueles lese o
máis de copia actual dos datos.

1140
00:49:35,720 --> 00:49:38,340
Isto é o que fai DynamoDB consistente.

1141
00:49:38,340 --> 00:49:42,450
Agora podes escoller activar
as lecturas consistentes fóra.

1142
00:49:42,450 --> 00:49:45,070
Caso en que eu vou dicir,
Eu só vou ler dun nodo.

1143
00:49:45,070 --> 00:49:47,430
E eu non podo asegurar que vai
sendo os datos máis actuais.

1144
00:49:47,430 --> 00:49:49,450
>> Así, se unha gravación está chegando,
que aínda non foi duplicado,

1145
00:49:49,450 --> 00:49:50,360
está indo a obter esta copia.

1146
00:49:50,360 --> 00:49:52,220
Esa é unha lectura finalmente consistente.

1147
00:49:52,220 --> 00:49:54,640
E que é o que é a metade do custo.

1148
00:49:54,640 --> 00:49:56,140
Entón, iso é algo para pensar.

1149
00:49:56,140 --> 00:50:00,160
Cando está lendo fóra DynamoDB, e
está configurando a súa capacidade de lectura

1150
00:50:00,160 --> 00:50:04,430
unidades, se escolle finalmente
lecturas consistentes, é moito máis barato,

1151
00:50:04,430 --> 00:50:06,010
é aproximadamente a metade do custo.

1152
00:50:06,010 --> 00:50:09,342
>> E así aforrar diñeiro.

1153
00:50:09,342 --> 00:50:10,300
Pero esa é a súa elección.

1154
00:50:10,300 --> 00:50:12,925
Se quere unha lectura consistente ou
unha lectura finalmente consistente.

1155
00:50:12,925 --> 00:50:15,720
Isto é algo que pode escoller.

1156
00:50:15,720 --> 00:50:17,659
>> Imos falar sobre índices.

1157
00:50:17,659 --> 00:50:19,450
Entón, nós mencionados que
agregación de nivel superior.

1158
00:50:19,450 --> 00:50:23,720
Temos claves de hash, e
temos claves alcance.

1159
00:50:23,720 --> 00:50:24,320
Está ben.

1160
00:50:24,320 --> 00:50:26,950
E iso é sobre a mesa principal, I
ten unha chave de hash, eu teño unha clave intervalo.

1161
00:50:26,950 --> 00:50:27,783
>> Que significa iso?

1162
00:50:27,783 --> 00:50:30,410
Eu teño un atributo que
Pode realizar consultas contra ricos.

1163
00:50:30,410 --> 00:50:31,800
É a clave intervalo.

1164
00:50:31,800 --> 00:50:35,530
Os outros atributos que item--
Podo filtrar eses atributos.

1165
00:50:35,530 --> 00:50:40,050
Pero eu non podo facer cousas como, el
iníciase coa, ou é maior que.

1166
00:50:40,050 --> 00:50:40,820
>> Como podo facer iso?

1167
00:50:40,820 --> 00:50:42,860
Eu crear un índice.

1168
00:50:42,860 --> 00:50:45,340
Hai dous tipos de
índices en DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Un índice é realmente
outra visión da táboa.

1170
00:50:49,002 --> 00:50:50,490
E o índice secundario local.

1171
00:50:50,490 --> 00:50:51,781
>> O primeiro imos falar.

1172
00:50:51,781 --> 00:50:57,740
Entón secundarios locais son coexistiram
na mesma partición como os datos.

1173
00:50:57,740 --> 00:51:00,240
E como tal, son sobre
o mesmo nodo físico.

1174
00:51:00,240 --> 00:51:01,780
Son o que chamamos consistente.

1175
00:51:01,780 --> 00:51:04,599
Significado, van recoñecer
a gravación, xunto coa mesa.

1176
00:51:04,599 --> 00:51:06,890
Cando a gravación entra,
imos escribir a través do índice.

1177
00:51:06,890 --> 00:51:09,306
Imos escribir-se á mesa,
e despois imos recoñecer.

1178
00:51:09,306 --> 00:51:10,490
Entón, iso é consistente.

1179
00:51:10,490 --> 00:51:13,174
Xa que a escrita foi
recoñecido dende a táboa,

1180
00:51:13,174 --> 00:51:15,090
se pode garantir que o
Índice secundaria local

1181
00:51:15,090 --> 00:51:18,380
terá a mesma visión dos datos.

1182
00:51:18,380 --> 00:51:22,390
Pero o que eles permiten que fai é
definir claves Faixa suplentes.

1183
00:51:22,390 --> 00:51:25,260
>> Ten que empregar o mesmo hash
clave como a táboa principal,

1184
00:51:25,260 --> 00:51:29,050
porque son co-situado na
mesma partición, e son consistentes.

1185
00:51:29,050 --> 00:51:33,110
Pero podo crear un índice
con diferentes claves de alcance.

1186
00:51:33,110 --> 00:51:41,590
Así, por exemplo, se eu tivese un fabricante
que tiña unha táboa de pezas en bruto chegando.

1187
00:51:41,590 --> 00:51:44,590
E pezas brutas entrar, e
están agregados por montaxe.

1188
00:51:44,590 --> 00:51:46,840
E quizais haxa un recall.

1189
00:51:46,840 --> 00:51:50,240
>> Calquera parte que se fixo por este
fabricante tras esta data,

1190
00:51:50,240 --> 00:51:52,840
Necesito tirar da miña liña.

1191
00:51:52,840 --> 00:51:55,950
Podo xirar un índice
que estaría mirando,

1192
00:51:55,950 --> 00:52:00,760
agregación na data de
Fabricación de que parte particular.

1193
00:52:00,760 --> 00:52:03,930
Entón, se a miña mesa nivel superior era
xa hash polo fabricante,

1194
00:52:03,930 --> 00:52:07,655
quizais foi organizado en parte ID, I
Pode crear un índice que a táboa off

1195
00:52:07,655 --> 00:52:11,140
como hash polo fabricante e
variaron en data de fabricación.

1196
00:52:11,140 --> 00:52:14,490
E de que xeito eu podería dicir, calquera cousa que
foi fabricado entre esas datas,

1197
00:52:14,490 --> 00:52:16,804
Necesito tirar dende a liña.

1198
00:52:16,804 --> 00:52:18,220
Entón, iso é un índice secundario local.

1199
00:52:18,220 --> 00:52:22,280
>> Estes teñen o efecto de
limitar o seu espazo de clave hash.

1200
00:52:22,280 --> 00:52:24,360
Porque coexistiram
no mesmo nodo de almacenamento,

1201
00:52:24,360 --> 00:52:26,860
eles limitan a clave de hash
espazo de 10 gigabytes.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, baixo a
táboas, particionará

1203
00:52:28,950 --> 00:52:31,380
súa mesa cada 10 gigabytes.

1204
00:52:31,380 --> 00:52:34,760
Cando poñer 10 GB de datos, nos
ir [PHH], e nós engadimos outro nodo.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Non imos dividir o LSI
a través de múltiples particións.

1207
00:52:42,070 --> 00:52:43,200
Imos dividir a táboa.

1208
00:52:43,200 --> 00:52:44,679
Pero non imos dividir o LSI.

1209
00:52:44,679 --> 00:52:46,470
Entón, iso é algo
importante comprender

1210
00:52:46,470 --> 00:52:50,070
é se está facendo moito,
moi, moi grandes agregacións,

1211
00:52:50,070 --> 00:52:53,860
entón vai ser limitado
10 gigabytes no seu LSIs.

1212
00:52:53,860 --> 00:52:56,640
>> En tal caso, podemos
usar secundarios globais.

1213
00:52:56,640 --> 00:52:58,630
Secundarios globais son
realmente outra mesa.

1214
00:52:58,630 --> 00:53:01,720
Eles existen completamente fóra de
o lado da súa táboa primaria.

1215
00:53:01,720 --> 00:53:04,680
E me permita atopar unha
estrutura totalmente diferente.

1216
00:53:04,680 --> 00:53:08,010
Entón, pense nisto como os datos están sendo inseridas
en dúas táboas diferentes, estruturado

1217
00:53:08,010 --> 00:53:09,220
de dous xeitos diferentes.

1218
00:53:09,220 --> 00:53:11,360
>> Podo definir un totalmente
diferente clave de hash.

1219
00:53:11,360 --> 00:53:13,490
Podo definir un totalmente
diferente clave de gama.

1220
00:53:13,490 --> 00:53:15,941
E podo executar este
de forma totalmente independente.

1221
00:53:15,941 --> 00:53:18,190
Por unha cuestión de feito, eu teño
provisionais miña capacidade de lectura

1222
00:53:18,190 --> 00:53:21,090
e capacidade para escribir o meu
índices secundarios globais

1223
00:53:21,090 --> 00:53:24,240
de forma totalmente independente
da miña táboa primaria.

1224
00:53:24,240 --> 00:53:26,640
Se eu definir ese índice, digo-
el o que ler e escribir

1225
00:53:26,640 --> 00:53:28,610
capacidade que vai estar a usar.

1226
00:53:28,610 --> 00:53:31,490
>> E que é separado
da miña mesa principal.

1227
00:53:31,490 --> 00:53:35,240
Agora, tanto dos índices permitir
non só definen claves de hash e alcance,

1228
00:53:35,240 --> 00:53:38,610
pero nos permiten
proxectar valores adicionais.

1229
00:53:38,610 --> 00:53:44,950
Entón, se eu quero ler fóra do índice,
e quero obter un conxunto de datos,

1230
00:53:44,950 --> 00:53:48,327
Eu non teño de volver para o inicio
mesa para obter os atributos adicionais.

1231
00:53:48,327 --> 00:53:50,660
Podo proxectar os adicional
atributos na táboa

1232
00:53:50,660 --> 00:53:53,440
para soportar o estándar de acceso.

1233
00:53:53,440 --> 00:53:57,700
Sei que probablemente está metendo algúns
realmente, realmente-- metendo as herbas daniñas

1234
00:53:57,700 --> 00:53:58,910
aquí en algunhas destas cousas.

1235
00:53:58,910 --> 00:54:02,725
Agora eu teño a deriva fóra deste.

1236
00:54:02,725 --> 00:54:07,320
>> Audiencia: [inaudível]
clave --table quería dicir foi un hash?

1237
00:54:07,320 --> 00:54:08,840
O hash orixinal?

1238
00:54:08,840 --> 00:54:09,340
Múltiples slats?

1239
00:54:09,340 --> 00:54:10,200
>> Rick Houlihan: Si.

1240
00:54:10,200 --> 00:54:11,070
Si.

1241
00:54:11,070 --> 00:54:15,260
A clave táboa basicamente
apunta para o elemento.

1242
00:54:15,260 --> 00:54:19,280
Así, un índice é un punteiro ao
os elementos orixinais na mesa.

1243
00:54:19,280 --> 00:54:22,910
Agora podes optar por construír un
índice que só ten a chave da táboa,

1244
00:54:22,910 --> 00:54:24,840
e hai outras propiedades.

1245
00:54:24,840 --> 00:54:26,570
E por que eu podería facelo?

1246
00:54:26,570 --> 00:54:28,570
Ben, quizais teña moi grandes elementos.

1247
00:54:28,570 --> 00:54:31,660
>> Realmente só precisa saber which--
meu nivel de acceso pode dicir,

1248
00:54:31,660 --> 00:54:33,760
os elementos que conteñen esa propiedade?

1249
00:54:33,760 --> 00:54:35,780
Non é preciso devolver o elemento.

1250
00:54:35,780 --> 00:54:37,800
Eu só teño que saber
os elementos que contelo.

1251
00:54:37,800 --> 00:54:40,700
Así, pode crear índices
que só ten a chave da táboa.

1252
00:54:40,700 --> 00:54:43,360
>> Pero iso é todo o que
un índice na base de datos é para.

1253
00:54:43,360 --> 00:54:46,280
É para poder rapidamente
identificar cales rexistros,

1254
00:54:46,280 --> 00:54:49,470
cales liñas, que
elementos na táboa ten

1255
00:54:49,470 --> 00:54:51,080
as propiedades que eu estou buscando.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, entón como funcionan?

1258
00:54:54,860 --> 00:54:58,340
GSIS basicamente son asíncrono.

1259
00:54:58,340 --> 00:55:02,570
A actualización ven a mesa,
táboa é actualizada a continuación, de forma asíncrona

1260
00:55:02,570 --> 00:55:03,720
todo o seu GSIS.

1261
00:55:03,720 --> 00:55:06,680
É por iso que son GSIS
finalmente, consistente.

1262
00:55:06,680 --> 00:55:09,440
>> É importante ter en conta que,
cando está construíndo GSIS,

1263
00:55:09,440 --> 00:55:13,110
e entender que está creando
outra dimensión da aggregation--

1264
00:55:13,110 --> 00:55:16,594
Agora, imos dicir que un bo exemplo
aquí é un fabricante.

1265
00:55:16,594 --> 00:55:19,260
Eu creo que eu podería ter falado sobre
un fabricante de dispositivos médicos.

1266
00:55:19,260 --> 00:55:23,870
Fabricantes de dispositivos médicos
moitas veces teñen partes serializado.

1267
00:55:23,870 --> 00:55:28,070
As pezas que entran en
unha substitución da anca todo

1268
00:55:28,070 --> 00:55:30,200
ter un pouco de número de serie neles.

1269
00:55:30,200 --> 00:55:33,584
E poderían millóns e
millóns e millóns de pezas

1270
00:55:33,584 --> 00:55:35,000
en todos os dispositivos que elas traen.

1271
00:55:35,000 --> 00:55:37,440
Ben, eles precisan agregar baixo
diferentes dimensións, as pezas

1272
00:55:37,440 --> 00:55:39,520
nunha montaxe, todo o
partes que se fixeron

1273
00:55:39,520 --> 00:55:41,670
nunha determinada liña, todo
as pezas que viñeron

1274
00:55:41,670 --> 00:55:44,620
a partir dun determinado fabricante
nunha determinada data.

1275
00:55:44,620 --> 00:55:47,940
E, ás veces, estas agregacións
plantexa-se na casa dos millóns.

1276
00:55:47,940 --> 00:55:50,550
>> Entón, eu traballo con algúns dos
estes faces que están sufrindo

1277
00:55:50,550 --> 00:55:53,156
porque están creando
estas agregacións ginormous

1278
00:55:53,156 --> 00:55:54,280
nos seus índices secundarios.

1279
00:55:54,280 --> 00:55:57,070
Poden ter unha pezas de materias
táboa que ven como única de hash.

1280
00:55:57,070 --> 00:55:59,090
Cada parte ten un número de serie único.

1281
00:55:59,090 --> 00:56:00,975
Eu uso o número de serie como o hash.

1282
00:56:00,975 --> 00:56:01,600
É fermoso.

1283
00:56:01,600 --> 00:56:04,160
Miña táboa de datos en bruto é espallada
en todo o espazo da chave.

1284
00:56:04,160 --> 00:56:05,930
Meu [? escribir?]
[? inxestión?] é incrible.

1285
00:56:05,930 --> 00:56:07,876
Eu tomo unha morea de datos.

1286
00:56:07,876 --> 00:56:09,500
Entón o que fan é crear un GSI.

1287
00:56:09,500 --> 00:56:12,666
E digo, xa sabe o que, eu teño ver
todas as partes para este fabricante.

1288
00:56:12,666 --> 00:56:15,060
Ben, de súpeto eu son
tendo mil millóns de liñas,

1289
00:56:15,060 --> 00:56:17,550
e enche-los para
un nó, porque cando

1290
00:56:17,550 --> 00:56:21,170
I agregar como o
ID fabricante coma a suma,

1291
00:56:21,170 --> 00:56:25,410
e número de peza como o intervalo,
a continuación, de súpeto eu son

1292
00:56:25,410 --> 00:56:30,530
poñer mil millóns de partes en que
este fabricante ten me entregado.

1293
00:56:30,530 --> 00:56:34,447
>> Isto pode causar unha serie
de presión sobre o GSI,

1294
00:56:34,447 --> 00:56:36,030
de novo, porque estou martelé un nó.

1295
00:56:36,030 --> 00:56:38,350
Estou poñendo todos estes
inserir un nó.

1296
00:56:38,350 --> 00:56:40,940
E iso é un caso de uso problemático real.

1297
00:56:40,940 --> 00:56:43,479
Agora, eu teño un bo deseño
patrón de como evitar isto.

1298
00:56:43,479 --> 00:56:45,770
E iso é un dos problemas
que sempre traballar.

1299
00:56:45,770 --> 00:56:49,590
Pero o que pasa, é a GSI pode
non ten capacidade de gravación suficiente

1300
00:56:49,590 --> 00:56:52,330
para poder empuxar todos aqueles
liñas nun único nodo.

1301
00:56:52,330 --> 00:56:55,390
E o que pasa a continuación é a
primario, a táboa de cliente,

1302
00:56:55,390 --> 00:57:00,180
táboa principal será estrangulada
porque o GSI non pode manter-se.

1303
00:57:00,180 --> 00:57:02,980
Así, a miña taxa de inserción vai
caer na mesa principal

1304
00:57:02,980 --> 00:57:06,230
como o meu GSI intenta manterse.

1305
00:57:06,230 --> 00:57:08,850
>> Todo ben, entón GSI de, LSI de,
cal deles debo empregar?

1306
00:57:08,850 --> 00:57:12,290
LSI de son consistentes.

1307
00:57:12,290 --> 00:57:13,750
GSI de, finalmente, son consistentes.

1308
00:57:13,750 --> 00:57:17,490
Se iso é OK, eu recomendo usar un
GSI, son moito máis flexibles.

1309
00:57:17,490 --> 00:57:20,270
LSI de pode ser modelado como un GSI.

1310
00:57:20,270 --> 00:57:27,040
E se o tamaño dos datos claves hash en
súa colección sexa superior a 10 gigabytes,

1311
00:57:27,040 --> 00:57:31,050
entón vai querer usar isto
GSI porque é só un límite duro.

1312
00:57:31,050 --> 00:57:32,035
>> Todo ben, entón escala.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Rendemento no Dynamo DB, vostede
prestación lata [inaudível]

1315
00:57:37,460 --> 00:57:38,680
throughput para unha mesa.

1316
00:57:38,680 --> 00:57:42,740
Temos clientes que teñen
provisionado 60 billion--

1317
00:57:42,740 --> 00:57:45,970
está facendo 60 millóns de pedidos, regularmente
rodando a máis de un millón solicitudes

1318
00:57:45,970 --> 00:57:47,790
por segundo nas nosas mesas.

1319
00:57:47,790 --> 00:57:50,360
Non hai realmente ningunha
límite teórico de canto

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
Hai uns suave
límites na súa conta

1322
00:57:55,920 --> 00:57:58,170
que poñemos alí, entón
que non tolear.

1323
00:57:58,170 --> 00:58:00,070
Se queres máis que
que, non un problema.

1324
00:58:00,070 --> 00:58:00,820
Vén dicirnos.

1325
00:58:00,820 --> 00:58:02,810
Imos converter-se no mostrador.

1326
00:58:02,810 --> 00:58:08,210
>> Cada conta é limitado a un certo nivel
en todos os servizos, só fóra do pau

1327
00:58:08,210 --> 00:58:11,920
para que a xente non tolear
se meten en problemas.

1328
00:58:11,920 --> 00:58:12,840
Non hai límite de tamaño.

1329
00:58:12,840 --> 00:58:14,940
Pode pór calquera número
de elementos nunha táboa.

1330
00:58:14,940 --> 00:58:17,620
O tamaño dun elemento é
limitada a 400 kilobytes cada,

1331
00:58:17,620 --> 00:58:20,050
que sería elemento non os atributos.

1332
00:58:20,050 --> 00:58:24,200
Así, a suma de todos os atributos
está limitado a 400 kilobytes.

1333
00:58:24,200 --> 00:58:27,300
E entón, de novo, temos
ese pequeno problema LSI

1334
00:58:27,300 --> 00:58:30,405
co límite de 10 gigabyte por hash.

1335
00:58:30,405 --> 00:58:33,280
Audiencia: número pequeno, eu estou falta
o que está me dicindo que é--

1336
00:58:33,280 --> 00:58:36,830
Audiencia: Oh, 400 kilobytes
é o tamaño máximo por elemento.

1337
00:58:36,830 --> 00:58:39,570
Así, un elemento ten todos os atributos.

1338
00:58:39,570 --> 00:58:43,950
Entón, 400 K é o tamaño total
dese elemento, 400 kilobytes.

1339
00:58:43,950 --> 00:58:46,170
Así, de todos os atributos
combinados, todos os datos

1340
00:58:46,170 --> 00:58:49,140
que está en todos estes atributos,
enrolado nun tamaño total,

1341
00:58:49,140 --> 00:58:51,140
Actualmente o límite de elementos hoxe é de 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Así dimensionamento de novo, conseguida
través de particionamento.

1344
00:58:57,046 --> 00:58:58,920
O throughput é provisionado
no nivel da táboa.

1345
00:58:58,920 --> 00:59:00,160
E non hai realmente dous botóns.

1346
00:59:00,160 --> 00:59:02,400
Temos capacidade de lectura
e escribir capacidade.

1347
00:59:02,400 --> 00:59:05,530
>> Entón, estas son axustados
independentemente un do outro.

1348
00:59:05,530 --> 00:59:08,640
Medida do estrictamente RCU lecturas consistentes.

1349
00:59:08,640 --> 00:59:13,005
OK, entón se está dicindo que quero 1000
RCU de eses son estrictamente consistente,

1350
00:59:13,005 --> 00:59:14,130
estas son as lecturas consistentes.

1351
00:59:14,130 --> 00:59:17,130
Se digo que quero
eventual lecturas consistentes,

1352
00:59:17,130 --> 00:59:19,402
podes provisionar 1000
RCU do, vai

1353
00:59:19,402 --> 00:59:21,840
para, finalmente, 2000
lecturas consistentes.

1354
00:59:21,840 --> 00:59:25,940
E a metade do prezo para os
finalmente, consisten le.

1355
00:59:25,940 --> 00:59:28,520
>> Unha vez máis, axustada
independentemente un do outro.

1356
00:59:28,520 --> 00:59:32,900
E eles teñen o throughput--
Se consumir o 100% do seu RCU,

1357
00:59:32,900 --> 00:59:35,960
non vai ter impacto no
dispoñibilidade dos seus dereitos.

1358
00:59:35,960 --> 00:59:40,161
Entón, eles están completamente
independentes uns dos outros.

1359
00:59:40,161 --> 00:59:43,160
Todo ben, entón unha das cousas que
Mencionei brevemente foi estrangulamento.

1360
00:59:43,160 --> 00:59:44,320
Estrangulamento é malo.

1361
00:59:44,320 --> 00:59:47,311
Estrangulamento indica mal non SQL.

1362
00:59:47,311 --> 00:59:50,310
Hai cousas que podemos facer para axuda-
vostede aliviar o estrangulamento que

1363
00:59:50,310 --> 00:59:51,040
está enfrentando.

1364
00:59:51,040 --> 00:59:53,240
Pero a mellor solución
para iso é, imos dar

1365
00:59:53,240 --> 00:59:58,000
un ollar para o que está facendo, porque
hai un anti-estándar en xogo aquí.

1366
00:59:58,000 --> 01:00:02,140
>> Esas cousas, cousas como non uniforme
carga de traballo, teclas de acceso, anteparos quentes.

1367
01:00:02,140 --> 01:00:06,210
Estou batendo un espazo de clave en particular
moi difícil por algún motivo particular.

1368
01:00:06,210 --> 01:00:07,080
Por que estou a facer iso?

1369
01:00:07,080 --> 01:00:08,710
Imos descubrir iso.

1370
01:00:08,710 --> 01:00:10,427
Estou mesturando meus datos quentes con datos fríos.

1371
01:00:10,427 --> 01:00:12,510
Estou deixando miñas táboas chegar
enorme, pero non hai realmente

1372
01:00:12,510 --> 01:00:15,970
só algunhas subconxunto dos datos
que é realmente interesante para min.

1373
01:00:15,970 --> 01:00:20,290
Así, para os datos de rexistro, por exemplo, unha gran cantidade de
clientes, que reciben os datos de rexistro a cada día.

1374
01:00:20,290 --> 01:00:22,490
Teñen unha enorme cantidade de datos de rexistro.

1375
01:00:22,490 --> 01:00:25,940
>> Se vostede está só botan todo o que rexistro
datos en unha gran mesa, co paso do tempo

1376
01:00:25,940 --> 01:00:28,070
que a táboa se ve enorme.

1377
01:00:28,070 --> 01:00:30,950
Pero eu estou realmente interesado só en
últimas 24 horas, os últimos sete días,

1378
01:00:30,950 --> 01:00:31,659
nos últimos 30 días.

1379
01:00:31,659 --> 01:00:34,074
Sexa cal sexa a xanela de tempo
que eu estou interesado en ollar

1380
01:00:34,074 --> 01:00:37,010
para o evento que me molesta, é
o evento que é interesante para min,

1381
01:00:37,010 --> 01:00:39,540
esa é a única vez que a fiestra que eu teño.

1382
01:00:39,540 --> 01:00:42,470
Entón por que estou poñendo 10 anos
val de datos de rexistro na táboa?

1383
01:00:42,470 --> 01:00:45,030
O que fai que é
a táboa de fragmento.

1384
01:00:45,030 --> 01:00:45,880
>> El está enorme.

1385
01:00:45,880 --> 01:00:48,340
Comeza a se espallar para fóra
a través de miles de nós.

1386
01:00:48,340 --> 01:00:51,380
E xa que a súa capacidade
é tan baixo, é

1387
01:00:51,380 --> 01:00:54,090
de feito, en cada tipo de limitar
un deses nodos individuais.

1388
01:00:54,090 --> 01:00:57,120
Entón, imos comezar mirando como
nós rolar aquela mesa.

1389
01:00:57,120 --> 01:01:01,502
Como podemos xestionar estes datos algo
mellor evitar estes problemas.

1390
01:01:01,502 --> 01:01:02,710
E o que iso 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 mal NoSQL parece.

1393
01:01:06,790 --> 01:01:07,830
>> Eu teño unha tecla de acceso aquí.

1394
01:01:07,830 --> 01:01:10,246
Se ollar para o lado aquí,
estas son as miñas particións.

1395
01:01:10,246 --> 01:01:12,630
Teño 16 particións-se aquí
nese base de datos particular.

1396
01:01:12,630 --> 01:01:13,630
Facemos isto todo o tempo.

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 di como é
accedendo seu espazo clave.

1400
01:01:20,590 --> 01:01:23,700
E o que iso está me dicindo é
que hai un hash de especial

1401
01:01:23,700 --> 01:01:26,330
que este cara gusta de unha
lote terrible, porque é

1402
01:01:26,330 --> 01:01:28,250
bate-lo moi, moi difícil.

1403
01:01:28,250 --> 01:01:29,260
>> Así, o azul é bo.

1404
01:01:29,260 --> 01:01:29,900
Gústanos azul.

1405
01:01:29,900 --> 01:01:30,720
Nós non nos gusta de vermello.

1406
01:01:30,720 --> 01:01:33,120
Onde a presión da Rede
levántase a 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, agora vai ser estrangulado.

1408
01:01:35,560 --> 01:01:39,030
Así, sempre que ver todas as liñas vermellas, como
isto-- e non é só Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
cada base de datos NoSQL ten este problema.

1410
01:01:41,630 --> 01:01:44,640
Hai anti-patróns que poden
conducir este tipo de condicións.

1411
01:01:44,640 --> 01:01:49,070
O que fago é traballar cos clientes
para aliviar estas condicions.

1412
01:01:49,070 --> 01:01:51,840
>> E o que iso parece?

1413
01:01:51,840 --> 01:01:54,260
E iso está quedando máis
Fóra do Dynamo DB rendemento,

1414
01:01:54,260 --> 01:01:56,176
pero é realmente quedando
o máximo de NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Este non é restrinxida a dínamo.

1416
01:01:58,740 --> 01:02:02,050
Este é definitely-- I
adoitaba traballar no Mongo.

1417
01:02:02,050 --> 01:02:04,090
Eu estou familiarizado con moitas plataformas NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Cada un ten estes tipos
de problemas de teclas de atallo.

1419
01:02:06,830 --> 01:02:10,320
Para aproveitar o máximo proveito de calquera NoSQL
base de datos, especialmente Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
quere crear as táboas
onde o elemento clave de hash ten

1421
01:02:13,320 --> 01:02:18,590
un gran número de valores distintos,
un elevado grao de cardinalidade.

1422
01:02:18,590 --> 01:02:22,530
Porque iso significa que eu estou escribindo
para os lotes de diferentes baldes.

1423
01:02:22,530 --> 01:02:24,870
>> Os máis baldes que eu son
escribir para, o máis probable

1424
01:02:24,870 --> 01:02:29,100
Eu son a espallar a carga de gravación ou
ler cargar para fóra a través de varios nós,

1425
01:02:29,100 --> 01:02:33,560
o máis probable que eu estou a ter un
alto rendemento sobre a mesa.

1426
01:02:33,560 --> 01:02:37,440
E entón eu quero que os valores que se
solicitadas de forma bastante equilibrada no tempo

1427
01:02:37,440 --> 01:02:39,430
e uniforme posible de forma aleatoria.

1428
01:02:39,430 --> 01:02:42,410
Ben, iso é ben interesante,
porque eu non podo realmente

1429
01:02:42,410 --> 01:02:43,960
control cando os usuarios veñen.

1430
01:02:43,960 --> 01:02:47,645
Entón, só tes que dicir que, se espallar
cousas para fóra en todo o espazo da chave,

1431
01:02:47,645 --> 01:02:49,270
probablemente estaremos en mellor forma.

1432
01:02:49,270 --> 01:02:51,522
>> Hai un certo
cantidade de tempo de entrega

1433
01:02:51,522 --> 01:02:53,230
que non vai
para poder control.

1434
01:02:53,230 --> 01:02:55,438
Pero estes son realmente o
dúas dimensións que temos,

1435
01:02:55,438 --> 01:02:58,800
espazo, o acceso uniformemente
propagación, tempo, solicitudes

1436
01:02:58,800 --> 01:03:01,040
que chegan uniformemente espazos no tempo.

1437
01:03:01,040 --> 01:03:03,110
E se os dous
condicións están a ser cumpridas,

1438
01:03:03,110 --> 01:03:05,610
a continuación, que é o que é
vai parecer.

1439
01:03:05,610 --> 01:03:07,890
Este é moito máis agradable.

1440
01:03:07,890 --> 01:03:08,890
Estamos moi felices aquí.

1441
01:03:08,890 --> 01:03:10,432
Temos un nivel de acceso moi mesmo.

1442
01:03:10,432 --> 01:03:13,098
Si, quizais está a recibir un
pouca presión de cando en vez,

1443
01:03:13,098 --> 01:03:14,830
pero nada realmente moi extensa.

1444
01:03:14,830 --> 01:03:17,660
Por iso, é incrible como moitas veces,
cando eu traballo cos clientes,

1445
01:03:17,660 --> 01:03:20,670
que primeiro gráfico co vermello gran
bar e todo o que feo amarelo é

1446
01:03:20,670 --> 01:03:23,147
en todo o lugar, nós
facer co exercicio

1447
01:03:23,147 --> 01:03:24,980
despois dun par de meses
de re-arquitectura,

1448
01:03:24,980 --> 01:03:28,050
están executando exactamente o mesmo
carga de traballo coa mesma carga exacta.

1449
01:03:28,050 --> 01:03:30,140
E iso é o que está parecendo agora.

1450
01:03:30,140 --> 01:03:36,600
Entón, o que lle gañou con NoSQL é un
esquema de datos que é absolutamente

1451
01:03:36,600 --> 01:03:38,510
amarre ao estándar de acceso.

1452
01:03:38,510 --> 01:03:42,170
>> E pode optimizar o sistema de datos
para soportar ese patrón de acceso.

1453
01:03:42,170 --> 01:03:45,490
Se non fai iso, entón está indo
para ver estes tipos de problemas

1454
01:03:45,490 --> 01:03:46,710
con esas teclas de atallo.

1455
01:03:46,710 --> 01:03:50,518
>> Audiencia: Ben, inevitablemente, algúns lugares
vai ser máis 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
Si, quero dicir, sempre
um-- e, de novo, hai

1459
01:03:54,620 --> 01:03:56,980
algúns patróns de deseño imos pasar por
que vai falar sobre como trata

1460
01:03:56,980 --> 01:03:58,480
con estas super-grandes agregacións.

1461
01:03:58,480 --> 01:04:01,260
É dicir, eu teño que telos,
como imos tratar con eles?

1462
01:04:01,260 --> 01:04:03,760
I got un bo caso de uso
que nós imos falar sobre por que.

1463
01:04:03,760 --> 01:04:05,940
>> Todo ben, entón imos falar
sobre algúns clientes agora.

1464
01:04:05,940 --> 01:04:06,950
Eses faces son AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Non sei se é
familiarizados con AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Probablemente velos
moi no navegador.

1467
01:04:10,781 --> 01:04:14,230
Son re-segmentación de anuncios, son
o maior negocio ad re-segmentación

1468
01:04:14,230 --> 01:04:14,940
alí fora.

1469
01:04:14,940 --> 01:04:17,792
Eles normalmente executado regularmente durante
60 millóns de transaccións ao día.

1470
01:04:17,792 --> 01:04:20,000
Están facendo máis dun millón
transaccións por segundo.

1471
01:04:20,000 --> 01:04:22,660
Teñen unha táboa moi sinxelo
estrutura, a táboa máis movido.

1472
01:04:22,660 --> 01:04:26,450
É basicamente só un
clave hash é o cookie,

1473
01:04:26,450 --> 01:04:29,010
o intervalo é o grupo demográfico
categoría, e en seguida,

1474
01:04:29,010 --> 01:04:31,220
o terceiro atributo é a puntuación.

1475
01:04:31,220 --> 01:04:33,720
>> Polo tanto, todos temos galletas en
noso navegador a partir destes eles.

1476
01:04:33,720 --> 01:04:35,900
E cando vai a un
comerciante participante,

1477
01:04:35,900 --> 01:04:39,390
eles basicamente marcar vostede fronte
varias categorías demográficas.

1478
01:04:39,390 --> 01:04:42,070
Cando vai a un sitio web e
di que quero ver iso AD--

1479
01:04:42,070 --> 01:04:44,920
ou, basicamente, non di que--
pero cando vai para o sitio

1480
01:04:44,920 --> 01:04:47,550
din que quere ver este anuncio.

1481
01:04:47,550 --> 01:04:49,370
E van obter ese anuncio de AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll te mira arriba na súa mesa.

1483
01:04:51,130 --> 01:04:52,115
Eles atopar o seu cookie.

1484
01:04:52,115 --> 01:04:53,990
Os anunciantes din
eles, quero alguén

1485
01:04:53,990 --> 01:04:58,632
que é de mediana idade,
Home de 40 anos de idade, en deportes.

1486
01:04:58,632 --> 01:05:01,590
E marcaren vostede nestes datos demográficos
e decidir se quere ou non

1487
01:05:01,590 --> 01:05:02,740
iso é un bo anuncio para ti.

1488
01:05:02,740 --> 01:05:10,330
>> Agora eles teñen un SLA con
seus provedores de publicidade

1489
01:05:10,330 --> 01:05:14,510
para proporcionar sub-10 milissegundo
resposta a cada solicitude.

1490
01:05:14,510 --> 01:05:16,090
Entón, eles están a usar Dynamo DB para iso.

1491
01:05:16,090 --> 01:05:18,131
Están nos a bater
millón de solicitudes por segundo.

1492
01:05:18,131 --> 01:05:21,120
Son capaces de facer toda a súa
investigacións, selección todos os datos,

1493
01:05:21,120 --> 01:05:26,130
e obter ese enlace engadir ao que
anunciante en menos de 10 milisegundos.

1494
01:05:26,130 --> 01:05:29,800
Realmente fenomenal
aplicación que teñen.

1495
01:05:29,800 --> 01:05:36,210
>> Eses faces actually--
son estes os mozos.

1496
01:05:36,210 --> 01:05:38,010
Eu non estou seguro se é estes faces.

1497
01:05:38,010 --> 01:05:40,127
Pode ser estes faces.

1498
01:05:40,127 --> 01:05:42,210
Basicamente dixo US-- non,
non creo que foron eles.

1499
01:05:42,210 --> 01:05:43,000
Creo que foi outra persoa.

1500
01:05:43,000 --> 01:05:44,750
Eu estaba a traballar cun
cliente que me dixo

1501
01:05:44,750 --> 01:05:47,040
que, agora que teñen
ir para Dynamo DB, son

1502
01:05:47,040 --> 01:05:50,330
gastar máis diñeiro en lanches para
seu equipo de desenvolvemento cada mes

1503
01:05:50,330 --> 01:05:52,886
do que gastan en base de datos.

1504
01:05:52,886 --> 01:05:54,760
Por iso, imos darlle un
idea da redución de custos

1505
01:05:54,760 --> 01:05:57,889
que pode obter no Dynamo DB é enorme.

1506
01:05:57,889 --> 01:05:59,430
Todo ben, Dropcam é outra empresa.

1507
01:05:59,430 --> 01:06:02,138
Estes cara é tipo de-- se pensa
de internet das cousas, Dropcam

1508
01:06:02,138 --> 01:06:05,150
é basicamente vídeo de seguridade de internet.

1509
01:06:05,150 --> 01:06:06,660
Se pon a súa cámara para fóra alí.

1510
01:06:06,660 --> 01:06:08,180
Cámara ten un detector de movemento.

1511
01:06:08,180 --> 01:06:10,290
Alguén ven xunto,
desencadea un punto de sinalización.

1512
01:06:10,290 --> 01:06:13,540
Cámara comeza a gravar por un tempo ata
non detecta calquera movemento máis.

1513
01:06:13,540 --> 01:06:15,310
Pon-se que o vídeo en Internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam era unha empresa que está
basicamente ligado ao Dínamo DB

1515
01:06:19,800 --> 01:06:22,200
porque estaban experimentando
enormes dores de crecemento.

1516
01:06:22,200 --> 01:06:25,820
E o que nos dixeron,
de súpeto petabytes de datos.

1517
01:06:25,820 --> 01:06:28,070
Eles non tiñan idea seu servizo
sería tan exitoso.

1518
01:06:28,070 --> 01:06:32,310
Máis que de entrada de vídeo YouTube
é o que estes faces están quedando.

1519
01:06:32,310 --> 01:06:36,780
Falan DynamoDB para seguir todo o
metadatos en todos os seus puntos clave de vídeo.

1520
01:06:36,780 --> 01:06:40,282
>> Entón eles teñen baldes S3 eles empurran
todos os artefactos binarios en.

1521
01:06:40,282 --> 01:06:41,990
E entón eles teñen
Rexistros Dynamo DB que

1522
01:06:41,990 --> 01:06:44,070
apuntar a xente para estas S3 tres obxectos.

1523
01:06:44,070 --> 01:06:47,070
Cando precisan de ollar para un vídeo,
eles miran a ser o rexistro no Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Eles click no enlace.

1525
01:06:47,903 --> 01:06:49,770
Eles tirar abaixo o vídeo S3.

1526
01:06:49,770 --> 01:06:51,590
Entón, iso é o tipo que isto parece.

1527
01:06:51,590 --> 01:06:53,580
E isto é en liña recta do seu equipo.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB reduce a súa
tempo de entrega para eventos 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
Na súa tenda relacional de idade,
eles acostumaban ter que ir e executar

1531
01:07:00,470 --> 01:07:03,780
varias consultas complexas figura
cales vídeos para tirar abaixo,

1532
01:07:03,780 --> 01:07:06,690
a menos de 50 milisegundos.

1533
01:07:06,690 --> 01:07:08,990
Polo que é incrible, incrible
o que de rendemento

1534
01:07:08,990 --> 01:07:12,990
pode comezar cando optimizar e
sintonizar a base de datos subxacente

1535
01:07:12,990 --> 01:07:15,110
para soportar o estándar de acceso.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, estes faces, o que é,
Fruit Ninja creo que é a súa cousa.

1537
01:07:20,500 --> 01:07:22,590
Que todas as carreiras en Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
E estes tíos, son unha boa
equipo de desenvolvemento, gran desenvolvemento

1539
01:07:26,810 --> 01:07:27,670
tenda.

1540
01:07:27,670 --> 01:07:29,364
>> Non é un bo equipo de operacións.

1541
01:07:29,364 --> 01:07:31,280
Eles non teñen moito
de recursos de operación.

1542
01:07:31,280 --> 01:07:33,940
Estaban loitando intentando manter
súa infraestrutura de aplicación up

1543
01:07:33,940 --> 01:07:34,290
e en execución.

1544
01:07:34,290 --> 01:07:35,000
Eles viñeron ata nós.

1545
01:07:35,000 --> 01:07:36,251
Eles ollaron para que Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Eles dixeron, que é para nós.

1547
01:07:37,291 --> 01:07:39,470
Eles construíron o seu todo
estrutura de aplicacións nel.

1548
01:07:39,470 --> 01:07:43,640
Algúns moi bos comentarios aquí
do equipo na súa capacidade

1549
01:07:43,640 --> 01:07:46,800
agora concentrarse no edificio
o xogo e non

1550
01:07:46,800 --> 01:07:49,010
ter que manter o
infraestrutura, o que

1551
01:07:49,010 --> 01:07:51,910
estaba facendo unha enorme cantidade
de sobrecarga para o seu equipo.

1552
01:07:51,910 --> 01:07:56,170
Entón, iso é algo que-- o
beneficio que comeza a partir Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Todo ben, metendo
modelaxe de datos aquí.

1554
01:08:00,930 --> 01:08:03,440
E nós falamos un pouco sobre
este 1-1, un para moitos,

1555
01:08:03,440 --> 01:08:05,060
e moitos para moitos relacións de tipo.

1556
01:08:05,060 --> 01:08:07,630
E como manter os de Dynamo.

1557
01:08:07,630 --> 01:08:10,500
En Dynamo DB usan
índices, dun modo xeral,

1558
01:08:10,500 --> 01:08:12,910
para rodar os datos de
un sabor a outro.

1559
01:08:12,910 --> 01:08:15,210
Claves de hash, claves de gama, e índices.

1560
01:08:15,210 --> 01:08:18,540
>> Nese particular
exemplo, como a maioría dos estados

1561
01:08:18,540 --> 01:08:23,802
ten unha esixencia de licenza que
só a licenza de conducir de un por persoa.

1562
01:08:23,802 --> 01:08:26,510
Non pode ir para obter dúas condutor
licenzas no estado de Boston.

1563
01:08:26,510 --> 01:08:27,500
Non podo facelo en Texas.

1564
01:08:27,500 --> 01:08:28,708
Ese é un tipo do xeito que é.

1565
01:08:28,708 --> 01:08:32,779
E así o DMV, temos investigacións, nós
quero mirar para arriba a carteira de motores

1566
01:08:32,779 --> 01:08:35,180
polo número de seguridade social.

1567
01:08:35,180 --> 01:08:39,990
Quero ollar-se os detalles do usuario
polo número de carné de conducir.

1568
01:08:39,990 --> 01:08:43,620
>> Así, poderiamos ter unha mesa de usuario que
ten unha chave de hash no número de serie,

1569
01:08:43,620 --> 01:08:47,830
ou o número de seguridade social, e
varios atributos definidos no elemento.

1570
01:08:47,830 --> 01:08:49,859
Agora, naquela mesa I
podería definir un GSI que

1571
01:08:49,859 --> 01:08:53,370
flips que preto que di que quero
unha chave de hash na licenza e, a continuación,

1572
01:08:53,370 --> 01:08:54,252
todos os outros elementos.

1573
01:08:54,252 --> 01:08:57,210
Agora, se eu quere consultar e atopar o
número de licenza para calquera Sociais

1574
01:08:57,210 --> 01:08:59,609
Número de seguridade, podo
consultar a táboa principal.

1575
01:08:59,609 --> 01:09:02,130
>> Se eu queira consultar e quero
para obter a seguridade social

1576
01:09:02,130 --> 01:09:05,735
número ou outros atributos por un
número de licenza, podo consultar o GSI.

1577
01:09:05,735 --> 01:09:08,689
Este modelo é que un
a unha relación.

1578
01:09:08,689 --> 01:09:12,460
Só unha forma moi simple GSI,
virar as cousas arredor.

1579
01:09:12,460 --> 01:09:13,979
Agora, falar sobre un para moitos.

1580
01:09:13,979 --> 01:09:16,450
Un para moitos é basicamente
súa chave gama hash.

1581
01:09:16,450 --> 01:09:20,510
Onde temos unha morea con este
caso de uso é datos do monitor.

1582
01:09:20,510 --> 01:09:23,880
Monitor de datos ven en común
rango, como internet das cousas.

1583
01:09:23,880 --> 01:09:26,890
Sempre obter todos estes
rexistros benvida en todo o tempo.

1584
01:09:26,890 --> 01:09:31,420
>> E quero atopar todas as lecturas
entre un determinado período de tempo.

1585
01:09:31,420 --> 01:09:34,220
É unha consulta moi común en
infraestrutura de seguimento.

1586
01:09:34,220 --> 01:09:38,430
A forma de ir sobre isto é atopar un
estrutura de tabela, unha mesa.

1587
01:09:38,430 --> 01:09:42,250
Eu teño unha táboa de medicións do dispositivo
cunha chave de hash sobre a identificación do dispositivo.

1588
01:09:42,250 --> 01:09:47,340
E eu teño unha clave intervalo na
timestamp, ou neste caso, o épico.

1589
01:09:47,340 --> 01:09:50,350
E iso permíteme facer complexo
consultas en que a clave gama

1590
01:09:50,350 --> 01:09:54,950
e voltar os rexistros que
son en relación ao resultado

1591
01:09:54,950 --> 01:09:56,310
definir que eu estou buscando.

1592
01:09:56,310 --> 01:09:58,360
E constrúe que un
para moitos relación

1593
01:09:58,360 --> 01:10:02,340
na táboa usando o fondo
clave de hash, estrutura de clave intervalo.

1594
01:10:02,340 --> 01:10:04,600
>> Entón, ese é o tipo de construción
na táboa da Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Cando definir un hash
e mesa de gama t, eu son

1596
01:10:07,290 --> 01:10:09,240
a definición dunha relación un para moitos.

1597
01:10:09,240 --> 01:10:12,770
É unha relación pai-fillo.

1598
01:10:12,770 --> 01:10:14,620
>> Imos falar sobre moitos
para moitos relacións.

1599
01:10:14,620 --> 01:10:19,170
E para este exemplo concreto
de novo, imos usar GSI de.

1600
01:10:19,170 --> 01:10:23,500
E imos falar sobre o xogo
escenario onde eu teño un determinado usuario.

1601
01:10:23,500 --> 01:10:26,500
Quero descubrir todos os xogos que
está rexistrado para ou xogar en.

1602
01:10:26,500 --> 01:10:29,600
E para un determinado partido, eu
quere atopar todos os usuarios.

1603
01:10:29,600 --> 01:10:31,010
Entón, como podo facer iso?

1604
01:10:31,010 --> 01:10:34,330
Miña táboa de xogos do usuario, eu vou
para ter unha clave de hash de ID de usuario

1605
01:10:34,330 --> 01:10:35,810
e unha chave intervalo do xogo.

1606
01:10:35,810 --> 01:10:37,810
>> Así, un usuario pode ter varios xogos.

1607
01:10:37,810 --> 01:10:41,380
É unha relación un para moitos entre
o usuario e os xogos que xoga.

1608
01:10:41,380 --> 01:10:43,410
E a continuación, no GSI,
Vou virar esa volta.

1609
01:10:43,410 --> 01:10:46,679
Vou botar no xogo e
Vou variar sobre o usuario.

1610
01:10:46,679 --> 01:10:48,970
Entón, se eu queira obter toda a
xogo o usuario de xogar en,

1611
01:10:48,970 --> 01:10:49,950
Vou consultar a táboa principal.

1612
01:10:49,950 --> 01:10:52,699
Se eu queira obter todos os usuarios
que están xogando un xogo particular,

1613
01:10:52,699 --> 01:10:53,887
Eu consultar o GSI.

1614
01:10:53,887 --> 01:10:54,970
Así ves como imos facelo?

1615
01:10:54,970 --> 01:10:58,369
Constrúe a apoiar estes do GSI o
caso de uso, a aplicación, o acceso

1616
01:10:58,369 --> 01:10:59,410
modelo, a aplicación.

1617
01:10:59,410 --> 01:11:01,440
>> Se eu ter consultar en
esta dimensión, deixe-

1618
01:11:01,440 --> 01:11:03,500
me crear un índice en que dimensión.

1619
01:11:03,500 --> 01:11:05,850
Se non fai iso, eu non me importa.

1620
01:11:05,850 --> 01:11:09,060
E, dependendo do caso de uso, I
Pode o índice ou non podería.

1621
01:11:09,060 --> 01:11:12,390
Se é un simple un para moitos,
da táboa principal é bo.

1622
01:11:12,390 --> 01:11:15,860
Se eu teño que facer estes moitos a
moitos de, ou eu teño que facer un para queridos,

1623
01:11:15,860 --> 01:11:18,390
entón quizais eu teño
a segunda no índice.

1624
01:11:18,390 --> 01:11:20,840
Entón, todo depende
o que eu estou tentando facer

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
>> Probablemente non vou gastar moito
tempo falando sobre documentos.

1627
01:11:28,000 --> 01:11:31,460
Isto torna-se un pouco, probablemente,
máis profundo do que necesitamos para entrar.

1628
01:11:31,460 --> 01:11:33,710
Imos falar un pouco
expresión de consulta sobre a rica.

1629
01:11:33,710 --> 01:11:37,831
Así, no Dynamo DB temos
a capacidade de crear

1630
01:11:37,831 --> 01:11:39,330
o que chamamos expresións de proxección.

1631
01:11:39,330 --> 01:11:42,660
Proxección expresións son simplemente
escoller os campos ou os valores

1632
01:11:42,660 --> 01:11:44,290
que desexe ver.

1633
01:11:44,290 --> 01:11:46,000
OK, entón eu facer unha selección.

1634
01:11:46,000 --> 01:11:48,010
Fago unha consulta contra Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
E digo, xa sabe o que, mostra
me só os cinco estrelas comentarios

1636
01:11:51,730 --> 01:11:54,544
para este produto particular.

1637
01:11:54,544 --> 01:11:55,710
Entón, iso é todo o que quero ver.

1638
01:11:55,710 --> 01:11:57,320
Non quero ver todas as
outros atributos da liña,

1639
01:11:57,320 --> 01:11:58,319
Eu só quero ver iso.

1640
01:11:58,319 --> 01:12:01,209
É como cando en SQL
dicir selecciona estrela ou de mesa,

1641
01:12:01,209 --> 01:12:02,000
comeza todo.

1642
01:12:02,000 --> 01:12:05,450
Cando digo seleccione o nome
mesa, só obter un atributo.

1643
01:12:05,450 --> 01:12:09,070
É o mesmo tipo de cousas en
Dynamo DB ou máis bases de datos NoSQL.

1644
01:12:09,070 --> 01:12:14,510
As expresións de filtro permítame
basicamente cortar o conxunto de resultados para abaixo.

1645
01:12:14,510 --> 01:12:15,540
Entón fago unha consulta.

1646
01:12:15,540 --> 01:12:17,260
Consulta pode volver con 500 elementos.

1647
01:12:17,260 --> 01:12:20,255
Pero eu só quero os elementos que
ten un atributo que di iso.

1648
01:12:20,255 --> 01:12:23,380
OK, entón imos filtrar estes elementos
que non corresponden a esta consulta particular.

1649
01:12:23,380 --> 01:12:25,540
Entón temos expresións de filtro.

1650
01:12:25,540 --> 01:12:28,310
>> As expresións de filtro pode
ser executado en calquera atributo.

1651
01:12:28,310 --> 01:12:30,260
Eles non son como consultas por eido.

1652
01:12:30,260 --> 01:12:32,690
Levantar cuestións son máis selectivos.

1653
01:12:32,690 --> 01:12:36,470
Consultas de filtro me obrigar a ir
se os resultados completos definir e, a continuación

1654
01:12:36,470 --> 01:12:39,170
esculpir os datos que eu non quero.

1655
01:12:39,170 --> 01:12:40,660
Por que iso é importante?

1656
01:12:40,660 --> 01:12:42,770
Porque lin todo.

1657
01:12:42,770 --> 01:12:46,597
Nunha consulta, eu vou ler e
vai ser un xigante sobre os datos.

1658
01:12:46,597 --> 01:12:48,430
E entón eu vou
esculpir o que eu teño.

1659
01:12:48,430 --> 01:12:52,080
E se eu só estou conquistando un
par de liñas, entón iso é OK.

1660
01:12:52,080 --> 01:12:53,620
Non é tan ineficiente.

1661
01:12:53,620 --> 01:12:57,800
>> Pero se eu estou lendo unha pila de
datos, só para esculpir un elemento,

1662
01:12:57,800 --> 01:13:01,490
entón eu vou ser mellor
fóra de usar unha consulta de gama,

1663
01:13:01,490 --> 01:13:03,030
porque é moito máis selectivo.

1664
01:13:03,030 --> 01:13:06,330
El me vai gardar unha chea de
diñeiro, porque pagar por esa lectura.

1665
01:13:06,330 --> 01:13:10,430
Sempre que os resultados que vén de volta
cruzar esa fío pode ser menor,

1666
01:13:10,430 --> 01:13:11,890
pero eu estou pagando para a lectura.

1667
01:13:11,890 --> 01:13:14,340
Así, entender como
está a recibir os datos.

1668
01:13:14,340 --> 01:13:16,420
Isto é moi importante na Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> As expresións condicionais, isto é o que
podería chamar de bloqueo optimista.

1670
01:13:19,710 --> 01:13:28,470
Actualización se existe, ou se este valor
é equivalente ao que especifiques.

1671
01:13:28,470 --> 01:13:31,494
E se eu tivera un selo de tempo nun
rexistro, eu podería ler os datos.

1672
01:13:31,494 --> 01:13:32,535
Podería cambiar eses datos.

1673
01:13:32,535 --> 01:13:35,030
Eu podería ir gravación que
datos ao seu banco de datos.

1674
01:13:35,030 --> 01:13:38,100
Se alguén cambiou o rexistro,
o timestamp podería cambiar.

1675
01:13:38,100 --> 01:13:40,370
E de que xeito a miña condicional
actualización podería dicir actualización

1676
01:13:40,370 --> 01:13:42,340
A data e hora é igual a este.

1677
01:13:42,340 --> 01:13:46,290
Ou a actualización fallará porque alguén
actualizar o rexistro no mesmo período.

1678
01:13:46,290 --> 01:13:48,290
>> Iso é o que chamamos de bloqueo optimista.

1679
01:13:48,290 --> 01:13:50,670
Isto significa que alguén
pode entrar e mudalo,

1680
01:13:50,670 --> 01:13:53,100
e eu estou indo a detecta-lo
cando volten a escribir.

1681
01:13:53,100 --> 01:13:56,106
E entón eu podo realmente ler que
datos e dicir, oh, el cambiou iso.

1682
01:13:56,106 --> 01:13:57,230
Necesito explicar iso.

1683
01:13:57,230 --> 01:14:00,490
E podo cambiar os datos na miña
gravar e aplicar outra actualización.

1684
01:14:00,490 --> 01:14:04,330
Entón pode incorporarse os incrementar
actualizacións que se producen entre o momento

1685
01:14:04,330 --> 01:14:08,740
que le os datos ea
tempo pode gravar os datos.

1686
01:14:08,740 --> 01:14:11,520
>> Audiencia: E o filtro
expresión, de feito, non 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
>> [Interpoñendo voces]

1689
01:14:14,316 --> 01:14:16,232
Rick Houlihan: Non vou
obter moito para iso.

1690
01:14:16,232 --> 01:14:17,700
Esta é unha palabra chave reservada.

1691
01:14:17,700 --> 01:14:20,130
A vista é unha libra reservados
contrasinal no Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Cada banco de datos ten a súa propia reservados
nomes para as coleccións que non pode usar.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, se se especifica
unha libra diante desta,

1694
01:14:27,240 --> 01:14:29,310
pode definir os nomes anteriores.

1695
01:14:29,310 --> 01:14:31,840
Este é un valor de referencia.

1696
01:14:31,840 --> 01:14:34,880
Probablemente non é o mellor para sintaxe
ten alí enriba desta discusión,

1697
01:14:34,880 --> 01:14:38,090
porque recibe nalgúns real--
Eu falaría máis

1698
01:14:38,090 --> 01:14:41,360
sobre iso nun nivel máis profundo.

1699
01:14:41,360 --> 01:14:46,130
>> Pero basta dicir, isto podería
ser consulta dixitalizar onde views--

1700
01:14:46,130 --> 01:14:50,190
nin libra vista é superior a 10.

1701
01:14:50,190 --> 01:14:54,660
É un valor numérico, si.

1702
01:14:54,660 --> 01:14:57,322
Se quere, podemos falar de
que, tras a discusión.

1703
01:14:57,322 --> 01:15:00,030
Todo ben, entón estamos entrando
algúns escenarios en prácticas

1704
01:15:00,030 --> 01:15:02,000
onde imos falar
sobre algunhas aplicacións aquí.

1705
01:15:02,000 --> 01:15:03,810
Cales son os casos de uso para Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
¿Qué son o deseño
patróns en Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> E o primeiro que imos
falar é a internet das cousas.

1708
01:15:09,110 --> 01:15:15,010
Entón temos unha morea de-- creo,
o que é máis que ele-- 50%

1709
01:15:15,010 --> 01:15:19,370
de tráfico en internet hoxe en día
é en realidade xerado por máquinas,

1710
01:15:19,370 --> 01:15:21,930
procesos automatizados, non por seres humanos.

1711
01:15:21,930 --> 01:15:25,140
Quero dicir esta cousa esa cousa que
leva no seu peto,

1712
01:15:25,140 --> 01:15:28,840
cantos datos que esa cousa é
realmente enviando arredor sen ti

1713
01:15:28,840 --> 01:15:30,550
sabendo que é absolutamente incrible.

1714
01:15:30,550 --> 01:15:34,970
Súa localización, información
sobre o quão rápido está indo.

1715
01:15:34,970 --> 01:15:38,400
Como pensas que Google Maps funciona
cando lle din que o tráfico é.

1716
01:15:38,400 --> 01:15:41,275
É porque hai millóns e
millóns de persoas en torno de condución

1717
01:15:41,275 --> 01:15:44,667
cos teléfonos que están enviando
datos en todas partes o tempo.

1718
01:15:44,667 --> 01:15:46,500
Entón, unha das cousas
sobre este tipo de datos

1719
01:15:46,500 --> 01:15:50,980
que vén en, datos do monitor, ingrese
datos, datos de series temporais, é que é

1720
01:15:50,980 --> 01:15:53,540
xeralmente só é interesante
para un pouco de tempo.

1721
01:15:53,540 --> 01:15:55,580
Tras este tempo, é
non é tan interesante.

1722
01:15:55,580 --> 01:15:58,390
Entón nós falamos sobre, non deixe
esas táboas crecer sen límites.

1723
01:15:58,390 --> 01:16:03,410
A idea aquí é que talvez teña 24
horas por valor de acontecementos na miña mesa quente.

1724
01:16:03,410 --> 01:16:06,160
E que mesa quente será
provisionais nunha taxa moi alta,

1725
01:16:06,160 --> 01:16:07,950
porque está tomando unha morea de datos.

1726
01:16:07,950 --> 01:16:10,920
Está levando unha morea de datos
e eu estou lendo moito.

1727
01:16:10,920 --> 01:16:14,560
Eu teño unha morea de operación
consultas que executan en relación a estes datos.

1728
01:16:14,560 --> 01:16:18,120
>> Tras 24 horas, hey,
sabe, eu non me importa.

1729
01:16:18,120 --> 01:16:21,150
Entón, talvez rolo cada medianoite
sobre a miña mesa para unha nova táboa

1730
01:16:21,150 --> 01:16:22,430
e eu desprovisione esta táboa.

1731
01:16:22,430 --> 01:16:26,440
E eu vou levar de RCU e
Abaixo do WCU porque 24 horas despois

1732
01:16:26,440 --> 01:16:28,630
Non estou correndo como moitos
consultas en que os datos.

1733
01:16:28,630 --> 01:16:30,200
Entón, eu estou indo a aforrar diñeiro.

1734
01:16:30,200 --> 01:16:32,940
E quizais 30 días máis tarde, eu non
aínda se preocupe todo.

1735
01:16:32,940 --> 01:16:35,020
Podería asumir a WCU de
todo o camiño para un,

1736
01:16:35,020 --> 01:16:36,990
porque sabe o que é
Nunca se ve gravado.

1737
01:16:36,990 --> 01:16:38,300
Os datos son de 30 días de idade.

1738
01:16:38,300 --> 01:16:40,000
Nunca cambia.

1739
01:16:40,000 --> 01:16:44,200
>> E é case nunca vai conseguir ler,
entón teremos que RCU para 10.

1740
01:16:44,200 --> 01:16:49,372
E eu estou aforrar unha tonelada de diñeiro con iso
datos, e só pagando por meus datos quentes.

1741
01:16:49,372 --> 01:16:52,330
Entón esa é a cousa importante é ollar
en cando mira para unha serie temporal

1742
01:16:52,330 --> 01:16:54,716
datos entrando en volume.

1743
01:16:54,716 --> 01:16:55,590
Estas son estratexias.

1744
01:16:55,590 --> 01:16:58,010
Agora, eu podería simplemente deixalo
van todos para a mesma táboa

1745
01:16:58,010 --> 01:16:59,461
e deixe que a táboa crecer.

1746
01:16:59,461 --> 01:17:01,460
Finalmente, eu vou
ver problemas de rendemento.

1747
01:17:01,460 --> 01:17:04,060
Vou ter que comezar a arquivar
algúns deses datos para fóra da mesa,

1748
01:17:04,060 --> 01:17:04,720
que non.

1749
01:17:04,720 --> 01:17:07,010
>> Imos moito mellor
proxecto seu programa

1750
01:17:07,010 --> 01:17:08,900
para que poida operar este camiño correcto.

1751
01:17:08,900 --> 01:17:11,460
Entón é só automática
no código da aplicación.

1752
01:17:11,460 --> 01:17:13,580
Á medianoite cada noite
rula a táboa.

1753
01:17:13,580 --> 01:17:17,170
Quizais o que eu teño é de un deslizamento
ventá de 24 horas de datos.

1754
01:17:17,170 --> 01:17:20,277
A continuación, nunha base regular que eu son
chamando de datos fóra da mesa.

1755
01:17:20,277 --> 01:17:22,360
Estou cortando-o con unha
Cron traballo e estou colocando-

1756
01:17:22,360 --> 01:17:24,160
para estes cadros,
o que necesitas.

1757
01:17:24,160 --> 01:17:25,940
Polo tanto, se un rollover traballa, iso é gran.

1758
01:17:25,940 --> 01:17:27,080
Se non, corte-la.

1759
01:17:27,080 --> 01:17:29,640
Pero imos manter os datos quente
lonxe dos seus datos fríos.

1760
01:17:29,640 --> 01:17:32,535
Vai salvarte unha morea de cartos e
facer as súas táboas máis rendemento.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Polo tanto, a seguinte cousa que vou falar
é de case catálogo de produtos.

1763
01:17:38,210 --> 01:17:42,000
Catálogo de productos é
caso de uso moi común.

1764
01:17:42,000 --> 01:17:46,600
Este é realmente un estándar moi común
que veremos nunha variedade de cousas.

1765
01:17:46,600 --> 01:17:48,870
Vostede sabe, para Twitter
exemplo, un tweet quente.

1766
01:17:48,870 --> 01:17:51,280
Todo o mundo está benvida e
agarrando que tweet.

1767
01:17:51,280 --> 01:17:52,680
Catálogo de produtos, eu teño unha venda.

1768
01:17:52,680 --> 01:17:54,120
Eu teño unha venda quente.

1769
01:17:54,120 --> 01:17:57,277
Teño 70.000 solicitudes por
segunda vinda dun produto

1770
01:17:57,277 --> 01:17:58,860
descrición do meu catálogo de produtos.

1771
01:17:58,860 --> 01:18:02,384
Vémolo no polo miúdo
operación un pouco.

1772
01:18:02,384 --> 01:18:03,550
Entón, como imos tratar con isto?

1773
01:18:03,550 --> 01:18:04,924
Non hai ningunha forma de tratar con isto.

1774
01:18:04,924 --> 01:18:07,110
Todos os meus usuarios queren ver
o mesmo anaco de datos.

1775
01:18:07,110 --> 01:18:09,410
Están están chegando, ao mesmo tempo.

1776
01:18:09,410 --> 01:18:11,920
E eles están todos facendo peticións
para o mesmo anaco de datos.

1777
01:18:11,920 --> 01:18:16,240
Tanto me dá a clave quente, que grande e vermello
Listra no meu gráfico que non nos gusta.

1778
01:18:16,240 --> 01:18:17,720
E iso é o que parece.

1779
01:18:17,720 --> 01:18:22,290
Así, en toda a miña tecla espazo que estou a recibir
martelé nos elementos de venda.

1780
01:18:22,290 --> 01:18:24,070
Estou recibindo nada en calquera outro lugar.

1781
01:18:24,070 --> 01:18:26,050
>> ¿Como aliviar este problema?

1782
01:18:26,050 --> 01:18:28,410
Ben, nós aliviar esta con caché.

1783
01:18:28,410 --> 01:18:33,630
Cache, se pon basicamente un in-memory
partición diante da base de datos.

1784
01:18:33,630 --> 01:18:37,260
Conseguimos
[Inaudível] caché, como

1785
01:18:37,260 --> 01:18:40,260
Pode configurar o seu propio caché, [inaudível]
caché de [? d ,?] o que quere.

1786
01:18:40,260 --> 01:18:42,220
Poña isto diante da base de datos.

1787
01:18:42,220 --> 01:18:47,250
E de que xeito pode almacenar eses datos
a partir desas teclas de acceso superior en que o caché

1788
01:18:47,250 --> 01:18:49,390
espazo e ler a caché.

1789
01:18:49,390 --> 01:18:51,962
>> E entón a maioría das súas lecturas
comezar a ollar como este.

1790
01:18:51,962 --> 01:18:54,920
Teño todos estes caché de bate-se aquí
e eu non teño nada a suceder aquí

1791
01:18:54,920 --> 01:18:59,330
porque base de datos está sentado detrás do
cache e non a le pasar.

1792
01:18:59,330 --> 01:19:02,520
Se eu cambiar os datos na
base de datos, eu teño que actualizar a caché.

1793
01:19:02,520 --> 01:19:04,360
Podemos usar algo
como vapores de facelo.

1794
01:19:04,360 --> 01:19:07,360
E eu vou explicar como funciona isto.

1795
01:19:07,360 --> 01:19:09,060
Todo ben, messaging.

1796
01:19:09,060 --> 01:19:11,180
Correo electrónico, todos usamos e-mail.

1797
01:19:11,180 --> 01:19:12,540
>> Este é un bo exemplo.

1798
01:19:12,540 --> 01:19:14,950
Temos algún tipo de táboa de mensaxes.

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 faría SQL
Look Like a construír esta caixa de entrada.

1801
01:19:19,760 --> 01:19:23,350
Nós tipo de usar o mesmo tipo
da estratexia de usar GSI de, GSI de

1802
01:19:23,350 --> 01:19:25,320
para a miña caixa de entrada e miña caixa de saída.

1803
01:19:25,320 --> 01:19:27,600
Entón, eu teño mensaxes de materias benvida
na miña táboa de mensaxes.

1804
01:19:27,600 --> 01:19:30,194
E o primeiro achegamento a este
pode ser, por exemplo, OK, non hai problema.

1805
01:19:30,194 --> 01:19:31,110
Teño mensaxes materias.

1806
01:19:31,110 --> 01:19:33,710
Mensaxes procedentes [inaudível]
mensaxe de ID, iso é óptimo.

1807
01:19:33,710 --> 01:19:35,070
Ese é o meu hash exclusivo.

1808
01:19:35,070 --> 01:19:38,280
Vou crear dous GSI de un
para a miña caixa de entrada, unha para a miña caixa de saída.

1809
01:19:38,280 --> 01:19:40,530
E o primeiro que vou facer
é que eu vou dicir a miña chave de hash é

1810
01:19:40,530 --> 01:19:43,310
será o destinatario e
Vou organizar na data.

1811
01:19:43,310 --> 01:19:44,220
Isto é fantástico.

1812
01:19:44,220 --> 01:19:45,890
Eu teño a miña fermosa vista aquí.

1813
01:19:45,890 --> 01:19:47,780
Pero hai un pequeno problema aquí.

1814
01:19:47,780 --> 01:19:50,891
E ten iso en
bases de datos relacionais ben.

1815
01:19:50,891 --> 01:19:52,390
Eles chamado de particionamento vertical.

1816
01:19:52,390 --> 01:19:55,840
Quere manter os seus datos gran
lonxe dos seus datos pequenos.

1817
01:19:55,840 --> 01:20:00,470
>> E a razón pola que é porque eu teño que
vaia ler os elementos de obter os atributos.

1818
01:20:00,470 --> 01:20:05,570
E se os meus corpos están todos aquí,
despois de ler só algúns elementos

1819
01:20:05,570 --> 01:20:08,560
o meu lonxitude do corpo é
media 256 kilobytes cada,

1820
01:20:08,560 --> 01:20:10,991
a matemática está moi feo.

1821
01:20:10,991 --> 01:20:12,490
Entón, digamos que quero ler caixa de entrada de David.

1822
01:20:12,490 --> 01:20:14,520
Caixa de entrada de David ten 50 elementos.

1823
01:20:14,520 --> 01:20:17,880
A media eo tamaño é de 256 kilobytes.

1824
01:20:17,880 --> 01:20:21,730
Aquí está a miña taxa de conversión
para RCU é de catro kilobytes.

1825
01:20:21,730 --> 01:20:24,450
>> OK, imos con
lecturas finalmente consistentes.

1826
01:20:24,450 --> 01:20:28,640
Eu aínda 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 imos pensar
sobre como a aplicación funciona.

1829
01:20:31,980 --> 01:20:35,340
Se eu estou nunha aplicación de correo electrónico e
Eu estou mirando para a miña caixa de entrada,

1830
01:20:35,340 --> 01:20:39,680
e eu ollar para o corpo de cada mensaxe,
non, eu estou ollando para os resumos.

1831
01:20:39,680 --> 01:20:41,850
Estou mirando só as cabeceiras.

1832
01:20:41,850 --> 01:20:46,310
Entón, imos construír unha estrutura de táboa
que se parece máis con iso.

1833
01:20:46,310 --> 01:20:49,470
>> Entón aquí está a información
que o meu fluxo de traballo precisa.

1834
01:20:49,470 --> 01:20:50,890
Está na miña caixa de entrada GSI.

1835
01:20:50,890 --> 01:20:53,800
É a data, o remitente,
o tema e, a continuación,

1836
01:20:53,800 --> 01:20:56,790
a identificación da mensaxe, que apunta
de volta para a táboa de mensaxes

1837
01:20:56,790 --> 01:20:57,850
onde podo obter o corpo.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Ben, estes serían IDs de rexistro.

1840
01:21:04,420 --> 01:21:09,850
Eles ían apuntar ao seu
IDs de elemento na táboa de Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Cada índice sempre creates--
sempre o elemento

1842
01:21:12,220 --> 01:21:15,750
ID como parte de-- que
vén co índice.

1843
01:21:15,750 --> 01:21:17,414
>> Todo ben.

1844
01:21:17,414 --> 01:21:19,080
Audiencia: Di-lo onde se garda?

1845
01:21:19,080 --> 01:21:21,420
Rick Houlihan: Si, di-
exactly-- iso é o que fai.

1846
01:21:21,420 --> 01:21:22,644
Di aquí é o meu record re.

1847
01:21:22,644 --> 01:21:24,310
E vai apuntala-lo de volta para o meu record re.

1848
01:21:24,310 --> 01:21:26,460
Exactamente.

1849
01:21:26,460 --> 01:21:29,490
OK, entón agora é a miña caixa de entrada
de feito, moito menor.

1850
01:21:29,490 --> 01:21:32,210
E iso realmente soporta
o fluxo de traballo dun programa de correo electrónico.

1851
01:21:32,210 --> 01:21:34,230
Así, a miña caixa de entrada, eu premer.

1852
01:21:34,230 --> 01:21:38,160
Eu ir xunto e eu premer sobre a mensaxe,
que é cando eu teño ir buscar o corpo,

1853
01:21:38,160 --> 01:21:40,180
porque eu vou
ir a unha visión diferente.

1854
01:21:40,180 --> 01:21:43,870
Entón, se pensar sobre o tipo de MVC
cadro, controlador de vista do modelo.

1855
01:21:43,870 --> 01:21:46,120
>> O modelo contén a
datos que a visión necesidades

1856
01:21:46,120 --> 01:21:48,130
eo controlador interactúa con.

1857
01:21:48,130 --> 01:21:51,670
Cando cambiar o cadro, cando
Eu cambiar a perspectiva,

1858
01:21:51,670 --> 01:21:55,080
que é OK para volver ao
servidor e repoboar o modelo,

1859
01:21:55,080 --> 01:21:56,860
porque é o que o usuario espera.

1860
01:21:56,860 --> 01:22:00,530
Cando cambiar de vista, que é cando
podemos ir ao seu banco de datos.

1861
01:22:00,530 --> 01:22:02,480
Entón correo electrónico, faga clic en.

1862
01:22:02,480 --> 01:22:03,710
Eu estou mirando para o corpo.

1863
01:22:03,710 --> 01:22:04,330
Ida e volta.

1864
01:22:04,330 --> 01:22:05,680
Vai buscar o corpo.

1865
01:22:05,680 --> 01:22:06,950
>> Eu leo ​​moito menos datos.

1866
01:22:06,950 --> 01:22:09,960
Eu só estou lendo os corpos que
David necesita cando precisa deles.

1867
01:22:09,960 --> 01:22:14,230
E eu non estou queimar en 1600
RCU é só para mostrar a súa bandexa de entrada.

1868
01:22:14,230 --> 01:22:17,670
Entón agora isso-- este é o camiño
que LSI ou GSI-- Sinto moito,

1869
01:22:17,670 --> 01:22:19,900
GSI, daría correcto.

1870
01:22:19,900 --> 01:22:25,450
Temos a nosa haxix no destinatario.

1871
01:22:25,450 --> 01:22:27,030
Temos a clave gama na data.

1872
01:22:27,030 --> 01:22:31,380
E nós temos os atributos proxectados
que necesitamos só para apoiar a visión.

1873
01:22:31,380 --> 01:22:34,300
>> Nós virar para que a caixa de saída.

1874
01:22:34,300 --> 01:22:35,770
Hash no remitente.

1875
01:22:35,770 --> 01:22:39,612
E, en esencia, temos
a, vista limpo moi agradable.

1876
01:22:39,612 --> 01:22:41,570
E é que basically--
ten este agradable mensaxes

1877
01:22:41,570 --> 01:22:45,870
táboa que está a ser espallado ben porque
é hash soamente, hash ID mensaxe.

1878
01:22:45,870 --> 01:22:51,750
E nós temos dous índices que
están xirando fóra de devandito cadro.

1879
01:22:51,750 --> 01:22:57,411
Todo ben, entón idea aquí non é facer
manter os grandes datos e este pequeno datos

1880
01:22:57,411 --> 01:22:57,910
en conxunto.

1881
01:22:57,910 --> 01:23:00,700
Particionar vertical,
particionar esas táboas.

1882
01:23:00,700 --> 01:23:03,150
Non le datos que non ten que.

1883
01:23:03,150 --> 01:23:04,850
Todo ben, xogo.

1884
01:23:04,850 --> 01:23:06,990
Todos gusta de xogos.

1885
01:23:06,990 --> 01:23:10,902
Polo menos me gusta de xogos despois.

1886
01:23:10,902 --> 01:23:12,735
Así, algunhas das cousas
que xestione cando

1887
01:23:12,735 --> 01:23:14,193
estamos a pensar sobre o xogo, non?

1888
01:23:14,193 --> 01:23:16,999
Xogos nestes días, especialmente móbil
xogo, é todo sobre o pensamento.

1889
01:23:16,999 --> 01:23:19,540
E eu estou indo a executar aquí un
pouco lonxe DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Vou traer
a discusión dalgúns

1891
01:23:21,373 --> 01:23:24,240
en torno a algúns dos
outras tecnoloxías da AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Pero a idea sobre o xogo é pensar
sobre en termos de APIs, APIs que son,

1893
01:23:28,930 --> 01:23:31,730
dun modo xeral, HTTP e JSON.

1894
01:23:31,730 --> 01:23:34,550
É como xogos para móbil tipo de
interactuar coas súas extremidades traseiras.

1895
01:23:34,550 --> 01:23:35,850
Eles fan JSON mensaxe.

1896
01:23:35,850 --> 01:23:40,660
Fican de datos, e é todo,
dun modo xeral, en Niza APIs JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Cousas como facer amigos, obter
os datos leaderboard, cambio,

1898
01:23:44,950 --> 01:23:47,699
contido xerado polo usuario,
empuxe ao seu sistema,

1899
01:23:47,699 --> 01:23:49,740
estes son os tipos de cousas
que nós imos facer.

1900
01:23:49,740 --> 01:23:52,542
Datos de activos binario, estes datos
Pode non sentir na base de datos.

1901
01:23:52,542 --> 01:23:54,250
Isto pode sentir-se nun
almacenamento de obxecto, non?

1902
01:23:54,250 --> 01:23:56,541
Pero a base de datos vai
acaban dicindo ao sistema,

1903
01:23:56,541 --> 01:23:59,140
contando a aplicación
onde ir busca-la.

1904
01:23:59,140 --> 01:24:03,550
E, inevitablemente, para varios xogadores
servidores, infraestrutura de back-end,

1905
01:24:03,550 --> 01:24:06,180
e deseñado para alta
dispoñibilidade e escalabilidade.

1906
01:24:06,180 --> 01:24:09,400
Entón, estas son as cousas que todos queremos
na infraestrutura do xogo hoxe.

1907
01:24:09,400 --> 01:24:12,160
>> Entón, imos dar un ollo
o que parece.

1908
01:24:12,160 --> 01:24:16,070
Obtivo un back-end núcleo,
moi sinxelo.

1909
01:24:16,070 --> 01:24:19,880
Temos un sistema aquí con
múltiples zonas de dispoñibilidade.

1910
01:24:19,880 --> 01:24:23,780
Nós falamos sobre como AZS being-- pensar
deles como centros de datos separados.

1911
01:24:23,780 --> 01:24:26,040
Máis dun centro de datos
por AZ, pero iso é OK,

1912
01:24:26,040 --> 01:24:28,831
basta pensar-los como datos separado
centros que están xeograficamente

1913
01:24:28,831 --> 01:24:30,090
e falla illada.

1914
01:24:30,090 --> 01:24:32,172
>> Nós imos ter un
instancias EC2 parella.

1915
01:24:32,172 --> 01:24:33,880
Nós imos ter
un servidor back-end.

1916
01:24:33,880 --> 01:24:35,800
Quizais se é un legado
arquitectura, estamos

1917
01:24:35,800 --> 01:24:38,920
usando o que chamamos RDS,
servizos de base de datos relacional.

1918
01:24:38,920 --> 01:24:42,040
Podería ser MSSQL, MySQL,
ou algo así.

1919
01:24:42,040 --> 01:24:47,080
Esta é a forma como un aplicacións de lote
están deseñados hoxe.

1920
01:24:47,080 --> 01:24:49,594
>> Ben, nós pode querer ir con
é dicir, cando escalar.

1921
01:24:49,594 --> 01:24:51,510
Imos ir adiante e poñer
o balde S3 alí enriba.

1922
01:24:51,510 --> 01:24:54,200
E iso balde S3, en vez de servir
se eses obxectos do noso servers--

1923
01:24:54,200 --> 01:24:55,220
poderíamos facelo.

1924
01:24:55,220 --> 01:24:57,210
Poñer todo o seu par
obxectos nos seus servidores

1925
01:24:57,210 --> 01:24:59,751
e pode usar os servidor
instancias de servirse de que os datos.

1926
01:24:59,751 --> 01:25:01,860
Pero iso é moi caro.

1927
01:25:01,860 --> 01:25:05,107
>> Mellor forma de facer é ir adiante e
poñer os obxectos nun balde S3.

1928
01:25:05,107 --> 01:25:06,315
S3 é un repositorios de obxectos.

1929
01:25:06,315 --> 01:25:10,860
A súa construcción especialmente para
servindo-se estes tipos de cousas.

1930
01:25:10,860 --> 01:25:13,690
E deixe que os clientes solicitan
directamente destes baldes de obxectos,

1931
01:25:13,690 --> 01:25:15,390
descargar os servidores.

1932
01:25:15,390 --> 01:25:17,020
Entón, nós estamos empezando a escalar aquí.

1933
01:25:17,020 --> 01:25:19,140
>> Agora temos usuarios en todo o mundo.

1934
01:25:19,140 --> 01:25:19,730
Teño usuarios.

1935
01:25:19,730 --> 01:25:23,380
Eu preciso ter contido localmente
situado preto de eses usuarios, non?

1936
01:25:23,380 --> 01:25:26,200
Eu creei un balde S3
como o meu depósito de orixe.

1937
01:25:26,200 --> 01:25:29,370
E eu vou diante que, con
a distribución CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront é un CD e un
rede de distribución de contidos.

1939
01:25:31,720 --> 01:25:35,750
Basicamente hai que de datos que se especifica
e almacena na caché-lo por toda a internet

1940
01:25:35,750 --> 01:25:39,230
así os usuarios en todas partes poden ter
unha resposta moi rápida cando

1941
01:25:39,230 --> 01:25:40,960
eles solicitan estes obxectos.

1942
01:25:40,960 --> 01:25:41,960
>> Entón, ter unha idea.

1943
01:25:41,960 --> 01:25:48,230
Está medio que aproveitando toda a
aspectos da AWS aquí para obter este feito.

1944
01:25:48,230 --> 01:25:50,790
E, finalmente, xogamos
nun grupo de auto escala.

1945
01:25:50,790 --> 01:25:52,737
Así, os nosos casos AC2
dos nosos servidores de xogo,

1946
01:25:52,737 --> 01:25:54,820
como comezan a estar máis axitado
e cada vez máis ocupados,

1947
01:25:54,820 --> 01:25:57,236
eles só vai xirar outra
exemplo, xirar outra instancia,

1948
01:25:57,236 --> 01:25:58,210
xirar outra instancia.

1949
01:25:58,210 --> 01:26:02,090
Así, a tecnoloxía AWS ten, el
permite que especifique os parámetros

1950
01:26:02,090 --> 01:26:04,650
en torno ao cal os seus servidores vai medrar.

1951
01:26:04,650 --> 01:26:08,110
Entón vostede pode ter n número de servidores
aí, nun momento dado.

1952
01:26:08,110 --> 01:26:11,870
E se a súa carga vai, eles van
encoller, o número pode diminuír.

1953
01:26:11,870 --> 01:26:15,250
E se a carga de volta,
vai crecer de volta para fóra, elasticamente.

1954
01:26:15,250 --> 01:26:17,050
>> Entón, iso parece gran.

1955
01:26:17,050 --> 01:26:19,800
Temos unha morea de instancias de EC2.

1956
01:26:19,800 --> 01:26:21,671
Podemos poñer caché
diante dos bancos de datos,

1957
01:26:21,671 --> 01:26:23,045
tentar acelerar os bancos de datos.

1958
01:26:23,045 --> 01:26:25,030
O seguinte punto de presión
normalmente a xente ven

1959
01:26:25,030 --> 01:26:28,850
é que escalar un xogo usando un
sistema de base de datos relacional.

1960
01:26:28,850 --> 01:26:30,790
Eita, a base de datos
desempeño é terrible.

1961
01:26:30,790 --> 01:26:31,932
Como podemos mellorar isto?

1962
01:26:31,932 --> 01:26:33,640
Imos tentar poñer
cache diante daquel.

1963
01:26:33,640 --> 01:26:36,780
>> Ben, a caché non funciona
tan grande nos xogos, non?

1964
01:26:36,780 --> 01:26:39,330
Para os xogos, a escrita é doloroso.

1965
01:26:39,330 --> 01:26:40,930
Os xogos son moi pesados ​​escribir.

1966
01:26:40,930 --> 01:26:43,610
Cache non funciona cando está
escribir pesado, porque sempre

1967
01:26:43,610 --> 01:26:44,610
ten que actualizar a caché.

1968
01:26:44,610 --> 01:26:47,780
Actualizar a caché, é
irrelevantes para ser caché.

1969
01:26:47,780 --> 01:26:49,780
En realidade, é só un traballo extra.

1970
01:26:49,780 --> 01:26:51,970
>> Entón, a onde imos de aquí?

1971
01:26:51,970 --> 01:26:54,400
Ten un gran pescozo
alí en baixo na base de datos.

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 non é
fácil de facer cando se está

1974
01:26:59,410 --> 01:27:01,900
xestionar bases de datos relacionais.

1975
01:27:01,900 --> 01:27:05,080
Con bases de datos relacionais, é
responsable da xestión, de forma eficaz,

1976
01:27:05,080 --> 01:27:06,210
o espazo clave.

1977
01:27:06,210 --> 01:27:10,527
Está dicindo usuarios entre A e M
aquí, entre N e Z ir máis alá.

1978
01:27:10,527 --> 01:27:12,360
E está conmutación
en toda a aplicación.

1979
01:27:12,360 --> 01:27:15,000
Entón, está lidando con
esta fonte de datos partición.

1980
01:27:15,000 --> 01:27:18,670
Ten restricións transnacionais
que non ocupan particións.

1981
01:27:18,670 --> 01:27:20,560
Ten todo tipo de
messiness que é

1982
01:27:20,560 --> 01:27:23,040
xestionar alí intentando
para xestionar dimensionando

1983
01:27:23,040 --> 01:27:25,120
e construción dunha infraestrutura maior.

1984
01:27:25,120 --> 01:27:27,284
É só non é divertido.

1985
01:27:27,284 --> 01:27:30,930
>> Audiencia: Entón está dicindo que
o aumento dos puntos de orixe acelera

1986
01:27:30,930 --> 01:27:31,430
o proceso?

1987
01:27:31,430 --> 01:27:32,513
Rick Houlihan: Aumentando?

1988
01:27:32,513 --> 01:27:33,520
Puntos Orixe: platéia.

1989
01:27:33,520 --> 01:27:34,410
Rick Houlihan: puntos Orixe?

1990
01:27:34,410 --> 01:27:37,500
Audiencia: A partir da información,
onde a información está a benvida?

1991
01:27:37,500 --> 01:27:38,250
Rick Houlihan: Non.

1992
01:27:38,250 --> 01:27:41,820
O que estou dicindo é o aumento da
número de particións no almacenamento de datos

1993
01:27:41,820 --> 01:27:44,060
mellora a taxa de transferencia.

1994
01:27:44,060 --> 01:27:48,300
Entón, o que está a suceder aquí é usuarios
entrando na instancia EC2 aquí enriba,

1995
01:27:48,300 --> 01:27:50,780
ben, se eu ter un usuario
iso é A M, eu vou aquí.

1996
01:27:50,780 --> 01:27:53,560
De N a p, eu vou aquí.

1997
01:27:53,560 --> 01:27:55,060
De I a Z, eu vou aquí.

1998
01:27:55,060 --> 01:27:57,120
>> Audiencia: OK, entón esas son aqueles
todos almacenados en diferentes nós?

1999
01:27:57,120 --> 01:27:57,911
>> Rick Houlihan: Si.

2000
01:27:57,911 --> 01:28:00,210
Pense nisso como
diferentes silos de datos.

2001
01:28:00,210 --> 01:28:01,660
Entón, está a ter que facelo.

2002
01:28:01,660 --> 01:28:02,910
Se estás a facer
tanto, se está tentando

2003
01:28:02,910 --> 01:28:05,730
a escala nunha plataforma relacional,
isto é o que está facendo.

2004
01:28:05,730 --> 01:28:08,100
Está levando de datos e
está cortando-o para abaixo.

2005
01:28:08,100 --> 01:28:10,975
E está dividíndoo en toda a
varias instancias da base de datos.

2006
01:28:10,975 --> 01:28:13,580
E está administrando o único que
na capa de aplicación.

2007
01:28:13,580 --> 01:28:14,729
Non é divertido.

2008
01:28:14,729 --> 01:28:15,770
Entón, o que queremos ir?

2009
01:28:15,770 --> 01:28:20,240
Queremos ir DynamoDB, totalmente xestionado,
Almacenamento de datos NoSQL, prestación de transferencia.

2010
01:28:20,240 --> 01:28:22,680
Usamos índices secundarios.

2011
01:28:22,680 --> 01:28:26,154
É basicamente HTTP API e
inclúe soporte documento.

2012
01:28:26,154 --> 01:28:28,570
Entón non se preocupe
sobre calquera que o particionamento.

2013
01:28:28,570 --> 01:28:30,740
Facemos todo para ti.

2014
01:28:30,740 --> 01:28:33,260
Entón, agora, en vez diso, vostede
simplemente escriba para a mesa.

2015
01:28:33,260 --> 01:28:36,490
Se a táboa debe ser particionado,
que pasa nos bastidores.

2016
01:28:36,490 --> 01:28:40,642
Está completamente illado
que como un creador.

2017
01:28:40,642 --> 01:28:42,350
Entón imos falar sobre
algúns dos casos de uso

2018
01:28:42,350 --> 01:28:47,564
que nos atopamos no xogo, común
escenarios de xogos, táboa de clasificación.

2019
01:28:47,564 --> 01:28:49,980
Entón tes os usuarios entrando,
os BoardNames que son

2020
01:28:49,980 --> 01:28:52,930
en, a puntuación para este usuario.

2021
01:28:52,930 --> 01:28:57,700
Podemos estar hash na userid,
e entón temos variedade no xogo.

2022
01:28:57,700 --> 01:28:59,960
Así, cada usuario quere ver
todo o partido que xogou

2023
01:28:59,960 --> 01:29:01,770
e toda a súa puntuación máxima
en todos o partido.

2024
01:29:01,770 --> 01:29:04,000
Entón, ese é a súa valoración persoal.

2025
01:29:04,000 --> 01:29:10,010
>> Agora quero ir e quero get--
polo que fico con eses leaderboards persoais.

2026
01:29:10,010 --> 01:29:12,827
O que quero facer é ir buscar
a puntuación máxima para todos os usuarios.

2027
01:29:12,827 --> 01:29:13,660
Entón, como podo facer iso?

2028
01:29:13,660 --> 01:29:18,070
Cando o meu record é hash en
o userid, varios no xogo,

2029
01:29:18,070 --> 01:29:20,740
ben, eu estou indo a ir adiante
e reestruturar, crear un GSI,

2030
01:29:20,740 --> 01:29:22,370
e eu estou indo a reestruturar estes datos.

2031
01:29:22,370 --> 01:29:27,310
>> Agora vou para hash no
BoardName, que é o xogo.

2032
01:29:27,310 --> 01:29:29,800
E eu estou indo a variar na puntuación máxima.

2033
01:29:29,800 --> 01:29:31,540
E agora eu creei diferentes baldes.

2034
01:29:31,540 --> 01:29:34,790
Eu estou usando a mesma táboa,
os mesmos datos do elemento.

2035
01:29:34,790 --> 01:29:39,870
Pero eu estou creando un balde que dá
me unha agregación de puntuación máxima por xogo.

2036
01:29:39,870 --> 01:29:43,180
>> E podo consultar esta táboa
para obter a información.

2037
01:29:43,180 --> 01:29:50,890
Entón eu definir ese patrón de consulta ata
ser soportada por un índice secundario.

2038
01:29:50,890 --> 01:29:54,556
Agora, poden ser clasificados por BoardName
e clasificados por topscore dependendo.

2039
01:29:54,556 --> 01:29:57,180
Para que poida ver, estes son tipos
de casos de uso que comeza no xogo.

2040
01:29:57,180 --> 01:30:02,190
Outro caso bo uso chegamos en xogos
é premios e quen gañou os premios.

2041
01:30:02,190 --> 01:30:05,340
E este é un gran caso de uso
onde chamamos índices esparsos.

2042
01:30:05,340 --> 01:30:07,340
Índices esparsos son o
capacidade de xerar

2043
01:30:07,340 --> 01:30:10,850
un índice que non fai necesariamente
conter todo único elemento sobre a mesa.

2044
01:30:10,850 --> 01:30:11,470
E por que non?

2045
01:30:11,470 --> 01:30:14,540
Como o atributo que está a ser
non indexado non existir en cada elemento.

2046
01:30:14,540 --> 01:30:16,460
>> Polo tanto, neste particular,
usar caso, eu estou dicindo,

2047
01:30:16,460 --> 01:30:19,240
vostede sabe o que, eu vou
crear un atributo chamado Award.

2048
01:30:19,240 --> 01:30:22,970
E eu vou dar a todo usuario
que ten un premio que atribúen.

2049
01:30:22,970 --> 01:30:25,950
Usuarios que non teñen premios son
non vai ter ese atributo.

2050
01:30:25,950 --> 01:30:27,800
Entón, cando crear o
índice, os únicos usuarios

2051
01:30:27,800 --> 01:30:28,960
que van amosar
no índice son

2052
01:30:28,960 --> 01:30:31,050
os que realmente gañaron premios.

2053
01:30:31,050 --> 01:30:34,440
Entón esta é unha boa forma de poder
para crear índices filtrados que

2054
01:30:34,440 --> 01:30:40,580
son moi, moi selectiva que non facer
ten que indexar a táboa enteira.

2055
01:30:40,580 --> 01:30:43,050
>> Entón, nós estamos quedando con pouco tempo aquí.

2056
01:30:43,050 --> 01:30:49,190
Eu estou indo a ir adiante e saltar
fóra e ignorar este escenario.

2057
01:30:49,190 --> 01:30:52,625
Contacte algo about--

2058
01:30:52,625 --> 01:30:54,460
>> Audiencia: Podo facer unha pregunta rápida?

2059
01:30:54,460 --> 01:30:56,722
Un deles é escribir pesado?

2060
01:30:56,722 --> 01:30:57,680
Rick Houlihan: Qué é?

2061
01:30:57,680 --> 01:30:58,596
Audiencia: Escribir pesado.

2062
01:30:58,596 --> 01:31:01,270
Rick Houlihan: Escribir pesado.

2063
01:31:01,270 --> 01:31:03,460
Déixame ver.

2064
01:31:03,460 --> 01:31:06,220
>> Audiencia: Ou que non é
algo que pode só

2065
01:31:06,220 --> 01:31:08,809
voz para en cuestión de segundos?

2066
01:31:08,809 --> 01:31:10,850
Rick Houlihan: Imos
a través do escenario de votación.

2067
01:31:10,850 --> 01:31:11,670
Non é tan malo así.

2068
01:31:11,670 --> 01:31:14,580
Tendes uns minutos?

2069
01:31:14,580 --> 01:31:15,860
Aceptar.

2070
01:31:15,860 --> 01:31:17,890
>> Entón, imos falar sobre a votación.

2071
01:31:17,890 --> 01:31:20,250
Así, a votación en tempo real, temos
requisitos para votar.

2072
01:31:20,250 --> 01:31:25,250
Os requisitos son que permitimos
cada persoa para votar unha vez.

2073
01:31:25,250 --> 01:31:28,060
Queremos que ninguén sexa capaz
para cambiar o seu voto.

2074
01:31:28,060 --> 01:31:31,045
Queremos agregación en tempo real
e análise de datos demográficos

2075
01:31:31,045 --> 01:31:34,210
que imos ser
mostrando aos usuarios do sitio web.

2076
01:31:34,210 --> 01:31:35,200
>> Pense neste escenario.

2077
01:31:35,200 --> 01:31:37,550
Traballamos moito da realidade
TV mostra onde están

2078
01:31:37,550 --> 01:31:38,960
facendo estes tipo exacto de cousas.

2079
01:31:38,960 --> 01:31:41,584
Entón pode pensar no escenario,
temos millóns e millóns

2080
01:31:41,584 --> 01:31:43,959
nenas de adolescentes alí
cos seus teléfonos móbiles

2081
01:31:43,959 --> 01:31:46,250
e votación, e votación, e
votar en quen son

2082
01:31:46,250 --> 01:31:48,610
atopar para ser o máis popular.

2083
01:31:48,610 --> 01:31:50,830
Entón, estas son algunhas das
requisitos corremos para fóra.

2084
01:31:50,830 --> 01:31:52,990
>> E así o primeiro tomar
na resolución deste problema

2085
01:31:52,990 --> 01:31:55,090
sería construír un
aplicación moi sinxelo.

2086
01:31:55,090 --> 01:31:56,490
Entón eu teño ese app.

2087
01:31:56,490 --> 01:31:57,950
Eu teño algúns votantes por aí.

2088
01:31:57,950 --> 01:31:59,980
Chegan, eles bateron a aplicación de votación.

2089
01:31:59,980 --> 01:32:03,440
Eu teño un pouco de votos táboa raw
Eu só vou botan estes votos en.

2090
01:32:03,440 --> 01:32:05,780
Vou ter algún engadido
votos táboa que

2091
01:32:05,780 --> 01:32:09,490
farei o meu Analytics e demografía,
e imos poñer todo iso dentro.

2092
01:32:09,490 --> 01:32:11,420
>> E iso é gran.

2093
01:32:11,420 --> 01:32:12,332
A vida é boa.

2094
01:32:12,332 --> 01:32:15,040
A vida é boa ata descubrirmos que
sempre hai só un ou dous

2095
01:32:15,040 --> 01:32:16,879
persoas que son populares nunha elección.

2096
01:32:16,879 --> 01:32:19,420
Hai só unha ou dúas cousas
que a xente realmente se preocupan.

2097
01:32:19,420 --> 01:32:22,340
E se está votando en
escala, de súpeto eu son

2098
01:32:22,340 --> 01:32:26,360
será martelé o inferno fóra de
dous candidatos, un ou dous candidatos.

2099
01:32:26,360 --> 01:32:29,390
Un número moi limitado de elementos
persoas cren que ser popular.

2100
01:32:29,390 --> 01:32:31,710
>> Este non é un bo nivel de deseño.

2101
01:32:31,710 --> 01:32:33,549
Esta é realmente unha
patrón de deseño moi malo

2102
01:32:33,549 --> 01:32:36,340
porque crea o que nós
falou sobre o que era teclas de atallo.

2103
01:32:36,340 --> 01:32:38,960
Teclas de atallo son algo que non gusta.

2104
01:32:38,960 --> 01:32:40,470
>> Entón, como imos fixar iso?

2105
01:32:40,470 --> 01:32:47,640
E realmente, o xeito de solucionar isto é
tomando os baldes candidatos

2106
01:32:47,640 --> 01:32:51,490
e para cada candidato que temos,
imos engadir un valor aleatorio,

2107
01:32:51,490 --> 01:32:54,192
algo que sabemos, aleatorio
un valor entre 100 e,

2108
01:32:54,192 --> 01:32:56,620
entre 100 e 1000,
ou entre un e 1000,

2109
01:32:56,620 --> 01:32:59,940
porén moitos valores aleatorios que quere
achegar ao final dese candidato.

2110
01:32:59,940 --> 01:33:01,330
>> E o que realmente fixo, entón?

2111
01:33:01,330 --> 01:33:05,830
Se está a usar o ID como candidato
o balde para agregar votos,

2112
01:33:05,830 --> 01:33:08,780
se eu engade un aleatorio
número para o fin de que,

2113
01:33:08,780 --> 01:33:12,000
Eu creei agora 10 baldes, un
centos de baldes, mil baldes

2114
01:33:12,000 --> 01:33:14,160
que estou agregando votos de diámetro.

2115
01:33:14,160 --> 01:33:18,030
>> Entón, eu teño millóns e millóns,
e millóns de rexistros benvida

2116
01:33:18,030 --> 01:33:22,050
Para estes candidatos, agora estou estendendo
os votos en todo A_1 Candidate

2117
01:33:22,050 --> 01:33:24,630
través A_100 Candidato porque
cada vez que un voto vén,

2118
01:33:24,630 --> 01:33:26,530
Estou xerando unha chou
valor entre un e 100.

2119
01:33:26,530 --> 01:33:29,446
Estou adherencia que no extremo do
candidato que persoa votar.

2120
01:33:29,446 --> 01:33:31,120
Estou xogando o en que balde.

2121
01:33:31,120 --> 01:33:33,910
>> Agora na parte de atrás, sei
que eu teño máis de cen baldes.

2122
01:33:33,910 --> 01:33:36,350
Entón, cando eu queira ir adiante
e agregar os votos,

2123
01:33:36,350 --> 01:33:38,244
Lin desde todos estes baldes.

2124
01:33:38,244 --> 01:33:39,160
Entón eu ir adiante e engadir.

2125
01:33:39,160 --> 01:33:42,410
E entón eu a dispersión reunir
onde eu saír e dicir hey,

2126
01:33:42,410 --> 01:33:45,399
Vostede sabe o que a chave do candidato
espazos é máis de cen baldes.

2127
01:33:45,399 --> 01:33:47,940
Vou reunir toda a
votos dos cen baldes.

2128
01:33:47,940 --> 01:33:49,981
Eu estou indo a agregar
Los e eu vou dicir,

2129
01:33:49,981 --> 01:33:53,830
Un candidato ten agora
conta total de votos de x.

2130
01:33:53,830 --> 01:33:55,690
>> Agora, tanto write
consulta e consulta de lectura

2131
01:33:55,690 --> 01:33:58,160
son ben distribuídos
porque eu estou escribindo fronte

2132
01:33:58,160 --> 01:34:00,320
e eu estou lendo en centos de claves.

2133
01:34:00,320 --> 01:34:03,500
Non estou escribindo e
lectura a través dunha clave agora.

2134
01:34:03,500 --> 01:34:04,950
Entón, iso é un gran modelo.

2135
01:34:04,950 --> 01:34:08,090
>> Este pode ser un realmente
do proxecto o máis importante

2136
01:34:08,090 --> 01:34:10,420
patróns para a escala en NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Vai ver este tipo de
patrón de deseño en cada sabor.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, iso non acontece
importa, todos temos que facer.

2139
01:34:19,100 --> 01:34:21,840
Porque cando está lidando
con aqueles enormes agregacións,

2140
01:34:21,840 --> 01:34:26,650
ten que descubrir un xeito de
espallalas-los para fóra a través de baldes.

2141
01:34:26,650 --> 01:34:29,512
Polo tanto, esta é a forma de facelo.

2142
01:34:29,512 --> 01:34:31,220
Todo ben, entón o que
está facendo agora

2143
01:34:31,220 --> 01:34:35,252
é que está cambiando de lectura
custo de gravación escalabilidade.

2144
01:34:35,252 --> 01:34:37,085
O custo da miña lectura é
un pouco máis complexo

2145
01:34:37,085 --> 01:34:40,220
e eu teño que ir ler a partir dun
centos de baldes no canto dun.

2146
01:34:40,220 --> 01:34:41,310
Pero eu son capaz de escribir.

2147
01:34:41,310 --> 01:34:44,860
E o meu rendemento, a miña escrita
throughput é incrible.

2148
01:34:44,860 --> 01:34:49,450
Polo tanto, é xeralmente un valioso
técnica para escalar DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
ou calquera base de datos NoSQL para este asunto.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Entón, descubrimos como escala-lo.

2152
01:34:55,240 --> 01:34:56,930
E figuramos como
eliminar nosas teclas de atallo.

2153
01:34:56,930 --> 01:34:57,820
E iso é fantástico.

2154
01:34:57,820 --> 01:34:58,960
E nós temos este sistema agradable.

2155
01:34:58,960 --> 01:35:02,043
E iso nos deu moi correcto votación
porque temos rexistro voto de-dupe.

2156
01:35:02,043 --> 01:35:03,130
A súa construcción en DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Falamos dereitos condicionais.

2158
01:35:05,380 --> 01:35:08,170
>> Cando un elector entra, puts
unha inserción na táboa,

2159
01:35:08,170 --> 01:35:11,220
eles introducir coa súa identificación do elector,
se tentaren inserir outra votación,

2160
01:35:11,220 --> 01:35:13,320
Fago unha gravación condicional.

2161
01:35:13,320 --> 01:35:16,960
Digan só escribir este
se este non existe.

2162
01:35:16,960 --> 01:35:19,270
Así, logo que eu vexo que
que a votación de bater na mesa,

2163
01:35:19,270 --> 01:35:20,460
ninguén máis vai ser
capaz de poñer o seu voto no.

2164
01:35:20,460 --> 01:35:21,634
E iso é fantástico.

2165
01:35:21,634 --> 01:35:23,550
E nós estamos incrementando
nosos contadores de candidatos.

2166
01:35:23,550 --> 01:35:25,466
E nós estamos facendo noso
demografía e todo iso.

2167
01:35:25,466 --> 01:35:29,110
Pero o que acontece se o meu
aplicación cae?

2168
01:35:29,110 --> 01:35:31,350
Agora, de súpeto votos
están chegando, e eu

2169
01:35:31,350 --> 01:35:34,840
Non sei se eles están sendo procesados
nas miñas análises e demografía

2170
01:35:34,840 --> 01:35:36,040
anymore.

2171
01:35:36,040 --> 01:35:38,462
E cando a aplicación
volta para arriba, como

2172
01:35:38,462 --> 01:35:41,420
diaños eu sei que teño de votos
foi procesado e por onde comezo?

2173
01:35:41,420 --> 01:35:44,530
>> Polo tanto, este é un problema real cando
comezar a ollar para este tipo de escenario.

2174
01:35:44,530 --> 01:35:45,571
E como é que imos solucionar isto?

2175
01:35:45,571 --> 01:35:48,070
Nós resolver-lo co que nós
chamar DynamoDB Fluxos.

2176
01:35:48,070 --> 01:35:53,470
Fluxos é un tempo de solicitudes e
rexistro de cambios particionado de cada acceso

2177
01:35:53,470 --> 01:35:55,700
á mesa, cada gravación
acceso á táboa.

2178
01:35:55,700 --> 01:35:58,810
Os datos que está escrito á
táboa móstrase no fluxo.

2179
01:35:58,810 --> 01:36:01,815
>> É basicamente unha fila de 24 horas.

2180
01:36:01,815 --> 01:36:03,690
Elementos bater o córrego,
viven por 24 horas.

2181
01:36:03,690 --> 01:36:05,990
Poden ser lidas múltiples veces.

2182
01:36:05,990 --> 01:36:09,400
Garantir a entrega
só unha vez ao fluxo,

2183
01:36:09,400 --> 01:36:11,180
se pode ler n número de veces.

2184
01:36:11,180 --> 01:36:14,910
Entón porén moitos procesos quere
consumir estes datos, pode consumo-lo.

2185
01:36:14,910 --> 01:36:16,350
Aparecerá cada actualización.

2186
01:36:16,350 --> 01:36:18,455
Cada gravación será só
aparecer xa no fluxo.

2187
01:36:18,455 --> 01:36:20,621
Entón non se preocupe
sobre o procesamento de dúas veces

2188
01:36:20,621 --> 01:36:22,500
desde o mesmo proceso.

2189
01:36:22,500 --> 01:36:25,350
>> É estrictamente ordenada por elemento.

2190
01:36:25,350 --> 01:36:28,180
Cando dicimos tempo
ordenada e particionado,

2191
01:36:28,180 --> 01:36:30,680
vai ver por partición no fluxo.

2192
01:36:30,680 --> 01:36:33,169
Vai ver os elementos, actualizacións en orde.

2193
01:36:33,169 --> 01:36:35,210
Non estamos garantindo
sobre o fluxo que é

2194
01:36:35,210 --> 01:36:40,240
indo para obter todas as transaccións
na orde en todo elementos.

2195
01:36:40,240 --> 01:36:42,440
>> Entón regatos son idempotente.

2196
01:36:42,440 --> 01:36:44,037
Será que todos sabemos o que significa idempotente?

2197
01:36:44,037 --> 01:36:46,620
Idempotente significa que pode facelo
máis, e máis, e outra vez.

2198
01:36:46,620 --> 01:36:48,200
O resultado será o mesmo.

2199
01:36:48,200 --> 01:36:49,991
>> Fluxos son idempotente,
pero eles teñen que ser

2200
01:36:49,991 --> 01:36:54,860
reproducidos desde o punto de partida,
onde queira que escoller, ata o final,

2201
01:36:54,860 --> 01:36:57,950
ou eles non van producir
nos mesmos valores.

2202
01:36:57,950 --> 01:36:59,727
>> O mesmo con MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB ten unha construción
chaman a oplog.

2204
01:37:01,560 --> 01:37:04,140
É a mesma construción exacta.

2205
01:37:04,140 --> 01:37:06,500
Moitos bancos de datos NoSQL
ten esta construción.

2206
01:37:06,500 --> 01:37:08,790
Eles usalo para facer cousas
como replicación, que

2207
01:37:08,790 --> 01:37:10,475
é o que facemos cos regatos.

2208
01:37:10,475 --> 01:37:12,350
Audiencia: Talvez un
pregunta herética, pero

2209
01:37:12,350 --> 01:37:13,975
falar aplicacións facendo derrubou un así por diante.

2210
01:37:13,975 --> 01:37:16,089
Son fluxos garantir a
Nunca posiblemente ir para abaixo?

2211
01:37:16,089 --> 01:37:18,630
Rick Houlihan: Si, regatos
son garantir para nunca máis ir para abaixo.

2212
01:37:18,630 --> 01:37:21,040
Nós administramos a infraestrutura
para atrás. regatos automaticamente

2213
01:37:21,040 --> 01:37:22,498
implantar no seu grupo Auto Scaling.

2214
01:37:22,498 --> 01:37:25,910
Nós imos pasar por algo
pouco sobre o que pasa.

2215
01:37:25,910 --> 01:37:30,060
>> Non debería dicir que non son
garantir que nunca ir para abaixo.

2216
01:37:30,060 --> 01:37:33,110
Os elementos son garantir
para aparecer no córrego.

2217
01:37:33,110 --> 01:37:36,740
E o fluxo será accesible.

2218
01:37:36,740 --> 01:37:40,580
Entón, o que vai para abaixo ou volta
up, que pasa por baixo.

2219
01:37:40,580 --> 01:37:43,844
El covers-- é OK.

2220
01:37:43,844 --> 01:37:46,260
Todo ben, entón comeza diferente
tipo de vista fóra da pantalla.

2221
01:37:46,260 --> 01:37:51,040
Tipo de vista que son importantes para a
programador normalmente, o que era?

2222
01:37:51,040 --> 01:37:52,370
Recibe a antiga visión.

2223
01:37:52,370 --> 01:37:55,630
Cando unha actualización atinxe a mesa, que vai
empurrar o vello vistas ao fluxo

2224
01:37:55,630 --> 01:38:02,070
que os datos poidan arquivar ou cambio
control, identificación cambio, cambio

2225
01:38:02,070 --> 01:38:03,600
xestión.

2226
01:38:03,600 --> 01:38:07,160
>> A nova imaxe, o que é agora, despois de
a actualización, que é outro tipo de visión

2227
01:38:07,160 --> 01:38:07,660
pode comezar.

2228
01:38:07,660 --> 01:38:09,660
Pode obter tanto as imaxes antigas e novas.

2229
01:38:09,660 --> 01:38:10,660
Poida que eu quero os dous.

2230
01:38:10,660 --> 01:38:11,790
Quero ver o que era.

2231
01:38:11,790 --> 01:38:13,290
Quero ver o que cambiou para.

2232
01:38:13,290 --> 01:38:15,340
>> Eu teño un tipo de conformidade
do proceso que corre.

2233
01:38:15,340 --> 01:38:17,430
Necesita comprobar que
cando estas cousas cambian,

2234
01:38:17,430 --> 01:38:21,840
que están dentro de certos límites
ou dentro de certos parámetros.

2235
01:38:21,840 --> 01:38:23,840
>> E entón quizais eu só
Debe saber o que cambiou.

2236
01:38:23,840 --> 01:38:26,240
Eu non me importa o que elemento foi modificado.

2237
01:38:26,240 --> 01:38:28,580
Non ten que saber
que atributos modificado.

2238
01:38:28,580 --> 01:38:30,882
Eu só teño que saber que
os elementos están sendo tocadas.

2239
01:38:30,882 --> 01:38:33,340
Entón eses son os tipos de puntos de vista
que saír do córrego

2240
01:38:33,340 --> 01:38:35,960
e pode interactuar con.

2241
01:38:35,960 --> 01:38:37,840
>> A aplicación que
consome a corrente,

2242
01:38:37,840 --> 01:38:39,298
este é o tipo de forma como funciona.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB cliente solicitar a
enviar datos para as táboas.

2244
01:38:42,570 --> 01:38:44,750
Fluxos implantar no que chamamos anacos.

2245
01:38:44,750 --> 01:38:47,380
Shards son escalados
independentemente da mesa.

2246
01:38:47,380 --> 01:38:50,660
Non se aliñan completamente
para as particións da súa mesa.

2247
01:38:50,660 --> 01:38:52,540
E a razón pola que é
porque se aliñan

2248
01:38:52,540 --> 01:38:55,430
coa capacidade, a actual
capacidade da táboa.

2249
01:38:55,430 --> 01:38:57,600
>> Eles implantar na súa
propio grupo escalonamento auto,

2250
01:38:57,600 --> 01:39:00,800
e comezan a xirar a fóra, dependendo
de cantas gravacións están chegando,

2251
01:39:00,800 --> 01:39:03,090
cantos reads-- realmente é escribe.

2252
01:39:03,090 --> 01:39:05,820
Non hai ningunha reads-- pero como
moitas gravacións están chegando.

2253
01:39:05,820 --> 01:39:08,200
>> E, a continuación, na parte de atrás
fin, temos o que

2254
01:39:08,200 --> 01:39:11,390
chamar un KCl, ou Biblioteca de kinesis Cliente.

2255
01:39:11,390 --> 01:39:19,190
Kinesis é un fluxo de datos
tecnoloxía de procesamento da Amazonia.

2256
01:39:19,190 --> 01:39:22,040
E regatos está construído sobre iso.

2257
01:39:22,040 --> 01:39:25,670
>> Entón usa un KCl habilitado
aplicación para ler o fluxo.

2258
01:39:25,670 --> 01:39:28,752
A Biblioteca kinesis cliente, en realidade,
xestiona os traballadores para ti.

2259
01:39:28,752 --> 01:39:30,460
E tamén fai algúns
cousas interesantes.

2260
01:39:30,460 --> 01:39:35,630
Vai crear algunhas táboas up
na súa táboa DynamoDB

2261
01:39:35,630 --> 01:39:38,410
para controlar cales elementos
ser procesada.

2262
01:39:38,410 --> 01:39:41,190
Entón, desta maneira, se cae cara atrás, se
cae e vén e queda

2263
01:39:41,190 --> 01:39:45,570
estaba de volta, pode determinar onde
foi no procesamento da cadea.

2264
01:39:45,570 --> 01:39:48,360
>> Isto é moi importante cando
está falando de replicación.

2265
01:39:48,360 --> 01:39:50,350
Eu teño que saber o que
datos foi foi procesada

2266
01:39:50,350 --> 01:39:52,810
e os datos que aínda ten que ser procesada.

2267
01:39:52,810 --> 01:39:57,380
Así, a biblioteca de KCl para fluxos vai
darlle unha morea de que a función.

2268
01:39:57,380 --> 01:39:58,990
Ela coida de todas as tarefas domésticas.

2269
01:39:58,990 --> 01:40:01,140
El levanta-se un traballador para cada fragmento.

2270
01:40:01,140 --> 01:40:04,620
Ela crea unha táboa administrativa
para cada fragmento, para cada traballador.

2271
01:40:04,620 --> 01:40:07,560
E como os traballadores lume,
eles manteñen esas táboas

2272
01:40:07,560 --> 01:40:10,510
así vostede sabe este rexistro
foi lido e procesado.

2273
01:40:10,510 --> 01:40:13,850
E, a continuación, desa forma, se o proceso
morre e volver a estar en liña,

2274
01:40:13,850 --> 01:40:17,940
pode retomar exactamente onde despegou.

2275
01:40:17,940 --> 01:40:20,850
>> Entón, usamos isto para
replicación cross-rexión.

2276
01:40:20,850 --> 01:40:24,680
Moitos clientes teñen a necesidade de
mover datos ou partes das súas táboas de datos

2277
01:40:24,680 --> 01:40:25,920
en torno a diferentes rexións.

2278
01:40:25,920 --> 01:40:29,230
Existen nove rexións
arredor do mundo.

2279
01:40:29,230 --> 01:40:32,100
Polo tanto, pode haber un eu need--
pode ter usuarios en Asia, os usuarios

2280
01:40:32,100 --> 01:40:34,150
na Costa Leste dos Estados Unidos.

2281
01:40:34,150 --> 01:40:38,980
Teñen que datos diferentes
ten que ser distribuído localmente.

2282
01:40:38,980 --> 01:40:42,510
E quizais un usuario voa de
Asia para os Estados Unidos,

2283
01:40:42,510 --> 01:40:45,020
e quero replicar
seus datos con el.

2284
01:40:45,020 --> 01:40:49,340
Entón, cando sae do avión, ten
unha boa experiencia usando o seu programa móbil.

2285
01:40:49,340 --> 01:40:52,360
>> Podes usar o cross-rexión
biblioteca de replicación para facelo.

2286
01:40:52,360 --> 01:40:55,730
Basicamente, temos
proporcionada dúas tecnoloxías.

2287
01:40:55,730 --> 01:40:59,400
Un é unha aplicación de consola que poida
plantexa-se sobre o seu propio instancia EC2.

2288
01:40:59,400 --> 01:41:01,240
É executado a replicación puro.

2289
01:41:01,240 --> 01:41:02,720
E, a continuación, deulle a biblioteca.

2290
01:41:02,720 --> 01:41:06,070
A biblioteca pode ser usada para construír
súa propia aplicación se

2291
01:41:06,070 --> 01:41:10,740
quero facer cousas malucas que data--
filtro, replicar só unha parte dela,

2292
01:41:10,740 --> 01:41:14,120
executar os datos, mover para un
táboa diferente, así por diante e así por diante.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Entón, ese é o tipo de o que parece.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Fluxos poden ser
procesadas polo que chamamos Lambda.

2296
01:41:23,690 --> 01:41:27,394
Mencionados un pouco sobre o evento
arquitecturas de aplicacións accionados.

2297
01:41:27,394 --> 01:41:28,810
Lambda é un compoñente fundamental do que iso.

2298
01:41:28,810 --> 01:41:32,840
Lambda é o código que dispara da demanda
en resposta a un acontecemento particular.

2299
01:41:32,840 --> 01:41:36,020
Un deses eventos pode ser un
rexistro que aparece no stream.

2300
01:41:36,020 --> 01:41:39,100
Un rexistro aparece no córrego,
imos chamar esa función Java.

2301
01:41:39,100 --> 01:41:44,980
Ben, este é JavaScript, e Lambda
soporta Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
e pronto apoiar
outras linguas tamén.

2303
01:41:47,820 --> 01:41:50,940
E Nin que dicir, é puro código.

2304
01:41:50,940 --> 01:41:53,610
escribir en Java, que define unha clase.

2305
01:41:53,610 --> 01:41:55,690
Aperta o JAR-se en Lambda.

2306
01:41:55,690 --> 01:42:00,200
E entón se especifica cal clase
a chamada en resposta ao que o evento.

2307
01:42:00,200 --> 01:42:04,770
E, a continuación, a infraestrutura do Lambda
detrás que executará ese código.

2308
01:42:04,770 --> 01:42:06,730
>> Este código pode procesar
rexistros fóra do córrego.

2309
01:42:06,730 --> 01:42:08,230
Pode facer o que quere con el.

2310
01:42:08,230 --> 01:42:11,650
Neste exemplo en particular, todos somos
facendo realmente está rexistrando os atributos.

2311
01:42:11,650 --> 01:42:13,480
Pero este é só código.

2312
01:42:13,480 --> 01:42:15,260
Código pode facer calquera cousa, non?

2313
01:42:15,260 --> 01:42:16,600
>> Entón, pode executar estes datos.

2314
01:42:16,600 --> 01:42:18,160
Pode crear unha visión derivada.

2315
01:42:18,160 --> 01:42:21,160
Se é unha estrutura do documento,
pode esmagar a estrutura.

2316
01:42:21,160 --> 01:42:24,300
Pode crear índices alternativos.

2317
01:42:24,300 --> 01:42:27,100
Todo tipo de cousas que podes
facer cos regatos DynamoDB.

2318
01:42:27,100 --> 01:42:28,780
>> E realmente, iso é o que parece.

2319
01:42:28,780 --> 01:42:29,940
Entón obter esas actualizacións chegando.

2320
01:42:29,940 --> 01:42:31,190
Están saíndo da cadea.

2321
01:42:31,190 --> 01:42:32,720
Son lidos pola función Lambda.

2322
01:42:32,720 --> 01:42:37,480
Eles están xirando os datos e
empurrando-se en táboas de derivados,

2323
01:42:37,480 --> 01:42:42,200
notificando sistemas externos de cambio,
e enviar datos en ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Nós falamos sobre como poñer a caché
diante da base de datos para que as vendas

2325
01:42:45,900 --> 01:42:46,450
escenario.

2326
01:42:46,450 --> 01:42:50,049
Ben, o que acontece se
actualizar a descrición do elemento?

2327
01:42:50,049 --> 01:42:52,340
Ben, se eu tivese un Lambda
función de execución en que a táboa,

2328
01:42:52,340 --> 01:42:55,490
se eu actualizar a descrición do elemento, que vai
incorporarse o rexistro fóra do córrego,

2329
01:42:55,490 --> 01:42:58,711
e que vai actualizar o ElastiCache
exemplo, cos novos datos.

2330
01:42:58,711 --> 01:43:00,460
Entón, iso é unha chea de
o que facemos con 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 realmente dá
a capacidade de lanzar

2333
01:43:04,410 --> 01:43:07,930
e para executar aplicacións moi complexos
sen un servidor dedicado

2334
01:43:07,930 --> 01:43:10,371
infraestrutura, o que é moi legal.

2335
01:43:10,371 --> 01:43:13,100
>> Entón, imos voltar ao noso
en tempo real arquitectura votación.

2336
01:43:13,100 --> 01:43:17,984
Esta é unha nova e mellorada co noso
regatos e KCl habilitado aplicación.

2337
01:43:17,984 --> 01:43:20,150
Mesmo que antes, podemos
xestionar calquera escala de elección.

2338
01:43:20,150 --> 01:43:21,100
Gústanos diso.

2339
01:43:21,100 --> 01:43:24,770
Estamos facendo a obtención de dispersión
en varios baldes.

2340
01:43:24,770 --> 01:43:26,780
Temos de bloqueo optimista suceder.

2341
01:43:26,780 --> 01:43:30,192
Podemos manter os nosos electores
de cambiar os seus votos.

2342
01:43:30,192 --> 01:43:31,400
Eles só poden votar só unha vez.

2343
01:43:31,400 --> 01:43:32,880
Isto é fantástico.

2344
01:43:32,880 --> 01:43:35,895
Tolerancia a fallos en tempo real,
agregación scalable agora.

2345
01:43:35,895 --> 01:43:38,270
Se a cousa cae, el
sabe onde reiniciar-se

2346
01:43:38,270 --> 01:43:41,300
cando se trata backup porque
estamos usando a aplicación KCl.

2347
01:43:41,300 --> 01:43:45,700
E entón nós tamén podemos usar isto
Aplicación KCl para enviar datos para fóra

2348
01:43:45,700 --> 01:43:48,820
para redshift a outro
Analíticas App ou uso

2349
01:43:48,820 --> 01:43:51,990
os MapReduce elástico para realizar
en tempo real agregacións de streaming fóra

2350
01:43:51,990 --> 01:43:53,180
de que os datos.

2351
01:43:53,180 --> 01:43:55,480
>> Entón, estas son cousas que
non falamos moito.

2352
01:43:55,480 --> 01:43:57,375
Pero son adicional
tecnoloxías que veñen

2353
01:43:57,375 --> 01:44:00,310
de soportar cando está olhando
neste tipo de escenarios.

2354
01:44:00,310 --> 01:44:03,160
>> Todo ben, entón iso é sobre
Analytics con DynamoDB Fluxos.

2355
01:44:03,160 --> 01:44:05,340
Pode recoller de-dupe
datos, facer todo tipo

2356
01:44:05,340 --> 01:44:09,490
de cousas legais, datos agregados en
memoria, crear esas táboas de derivados.

2357
01:44:09,490 --> 01:44:13,110
Isto é un caso de uso enorme
que unha morea de clientes

2358
01:44:13,110 --> 01:44:16,950
toma parte con, tomando a nested
propiedades destes documentos JSON

2359
01:44:16,950 --> 01:44:18,946
e creación de índices adicionais.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Estamos no fin.

2362
01:44:23,150 --> 01:44:26,689
Grazas por soportar comigo.

2363
01:44:26,689 --> 01:44:28,480
Entón imos falar sobre
arquitectura de referencia.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB queda no medio dos así
gran parte da infraestrutura da AWS.

2365
01:44:33,440 --> 01:44:37,090
Basicamente, pode conectar para
ata o momento.

2366
01:44:37,090 --> 01:44:45,600
As aplicacións creados usando Dynamo inclúen
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
empurrar os datos para fóra en Elastic
MapReduce, importación e exportación de DynamoDB

2368
01:44:49,890 --> 01:44:52,370
en S3, todo tipo de fluxos de traballo.

2369
01:44:52,370 --> 01:44:54,120
Pero, probablemente, a mellor
cousa para falar,

2370
01:44:54,120 --> 01:44:56,119
e iso é o que é realmente
interesante é cando nós

2371
01:44:56,119 --> 01:44:58,350
falar aplicacións orientados a eventos.

2372
01:44:58,350 --> 01:45:00,300
>> Este é un exemplo de
un proxecto interno

2373
01:45:00,300 --> 01:45:04,850
que temos onde estamos, en realidade,
publicación de reunir os resultados da investigación.

2374
01:45:04,850 --> 01:45:07,700
Así, nun enlace de correo-e que
nós enviamos a fóra, alí vai

2375
01:45:07,700 --> 01:45:11,350
ser un pequeno estalo conexión dicindo
aquí para responder á investigación.

2376
01:45:11,350 --> 01:45:14,070
E cando unha persoa fai clic
ese enlace, o que pasa

2377
01:45:14,070 --> 01:45:18,020
é que tirar abaixo un seguro
Formulario de exame de código HTML S3.

2378
01:45:18,020 --> 01:45:18,980
Non hai ningún servidor.

2379
01:45:18,980 --> 01:45:20,600
Este é só un obxecto S3.

2380
01:45:20,600 --> 01:45:22,770
>> Esa forma xorde,
leva-se no navegador.

2381
01:45:22,770 --> 01:45:24,240
Ten Backbone.

2382
01:45:24,240 --> 01:45:30,160
Ten complexo JavaScript
que está correndo.

2383
01:45:30,160 --> 01:45:33,557
Polo que é aplicación moi rico
en execución no navegador do cliente.

2384
01:45:33,557 --> 01:45:36,390
Eles non saben que eles non son
interactuar cun servidor back-end.

2385
01:45:36,390 --> 01:45:38,220
Neste punto, é todo navegador.

2386
01:45:38,220 --> 01:45:41,780
>> Publican os resultados ao
chamamos a Amazon API Pasarela.

2387
01:45:41,780 --> 01:45:46,270
API Pasarela é simplemente unha API web
que pode definir e conectar

2388
01:45:46,270 --> 01:45:47,760
para o que quere.

2389
01:45:47,760 --> 01:45:50,990
Neste caso particular, estamos
conectado a unha función Lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Así, a miña operación POST é
pasando con ningún servidor.

2391
01:45:54,797 --> 01:45:56,380
Basicamente pasarela de API que se senta alí.

2392
01:45:56,380 --> 01:45:58,770
Me custa nada ata que a xente
comece a publicar a el, non?

2393
01:45:58,770 --> 01:46:00,269
A función Lambda só se senta alí.

2394
01:46:00,269 --> 01:46:03,760
E iso me custa nada ata
as persoas comezan a bater.

2395
01:46:03,760 --> 01:46:07,270
Así pode ver, como o volume
aumentos, que é cando as acusacións vir.

2396
01:46:07,270 --> 01:46:09,390
Non estou executando un servidor 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Entón eu puxo a forma
abaixo para fóra do balde,

2398
01:46:12,310 --> 01:46:15,719
e eu publicar a través da API
Porta de entrada para a función Lambda.

2399
01:46:15,719 --> 01:46:17,510
E, a continuación, o Lambda
función di, sabe

2400
01:46:17,510 --> 01:46:20,600
o que, eu teño algunhas PIIs, algúns
información persoalmente identificable

2401
01:46:20,600 --> 01:46:21,480
nestas respostas.

2402
01:46:21,480 --> 01:46:23,020
Teño comentarios vindos de usuarios.

2403
01:46:23,020 --> 01:46:24,230
Teño enderezos de correo electrónico.

2404
01:46:24,230 --> 01:46:26,190
Teño nomes de usuarios.

2405
01:46:26,190 --> 01:46:27,810
>> Déixeme dividir este fóra.

2406
01:46:27,810 --> 01:46:30,280
Eu estou indo a xerar algún
metadatos off este rexistro.

2407
01:46:30,280 --> 01:46:32,850
E eu estou indo a empurrar o
metadatos en DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
E eu podería cifrar os datos
e empurralo para DynamoDB se eu queira.

2409
01:46:36,059 --> 01:46:38,600
Pero é máis fácil para min, neste
caso de uso, para ir adiante unha palabra que dicir,

2410
01:46:38,600 --> 01:46:42,800
Eu estou indo a empurrar os datos en bruto
nun balde S3 cifrada.

2411
01:46:42,800 --> 01:46:47,240
Entón eu usar construído no lado do servidor S3
cifrado e manexo de claves de Amazon

2412
01:46:47,240 --> 01:46:51,600
Servizo para que eu teña unha clave que
pode executar nun intervalo regular,

2413
01:46:51,600 --> 01:46:55,010
e podo protexer eses datos PII
como parte de todo este fluxo de traballo.

2414
01:46:55,010 --> 01:46:55,870
>> Entón o que foi que eu fixen?

2415
01:46:55,870 --> 01:47:00,397
Acaba implantado un todo
aplicación, e eu non teño servidor.

2416
01:47:00,397 --> 01:47:02,980
Entón é o que aplicación dirixida evento
arquitectura fai para ti.

2417
01:47:02,980 --> 01:47:05,730
>> Agora, se 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 arquitectura exacta do que

2419
01:47:08,730 --> 01:47:14,560
executar fenomenalmente grandes campañas, que
Está mirando para iso e vai, oh meu.

2420
01:47:14,560 --> 01:47:17,840
Porque agora, poden
basicamente empurralo para fóra alí,

2421
01:47:17,840 --> 01:47:21,900
deixe que a campaña só sentir
alí ata que lanza, e non

2422
01:47:21,900 --> 01:47:24,400
ten que preocuparse un figo sobre
que tipo de infraestrutura

2423
01:47:24,400 --> 01:47:26,120
vai estar alí para apoia-lo.

2424
01:47:26,120 --> 01:47:28,600
E, a continuación, unha vez
que a campaña está feita,

2425
01:47:28,600 --> 01:47:31,520
é como a infraestrutura
só vai inmediatamente

2426
01:47:31,520 --> 01:47:33,680
porque non hai realmente
hai infraestrutura.

2427
01:47:33,680 --> 01:47:35,660
É código só que se sente en Lambda.

2428
01:47:35,660 --> 01:47:38,560
É só datos que queda no DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
É unha forma incrible
para construír aplicacións.

2430
01:47:41,340 --> 01:47:43,970
>> Audiencia: Entón é máis
efémero do que sería

2431
01:47:43,970 --> 01:47:45,740
se foi almacenado nun servidor real?

2432
01:47:45,740 --> 01:47:46,823
>> Rick Houlihan: Absolutamente.

2433
01:47:46,823 --> 01:47:49,190
Porque esa instancia de servidor
tería que ser un 7/24.

2434
01:47:49,190 --> 01:47:51,954
Ten que estar dispoñible para
alguén para responder.

2435
01:47:51,954 --> 01:47:52,620
Ben, difícil de adiviñar?

2436
01:47:52,620 --> 01:47:55,410
S3 é dispoñible 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 é moi, moi bo
a servir-se obxectos.

2439
01:47:59,320 --> 01:48:02,590
Estes obxectos poden ser arquivos HTML, ou
Arquivos JavaScript, ou o que sexa.

2440
01:48:02,590 --> 01:48:07,430
Pode executar aplicacións web moi ricas
fóra de baldes S3, e as persoas fan.

2441
01:48:07,430 --> 01:48:10,160
>> E entón esa é a idea aquí
é para estar lonxe do camiño

2442
01:48:10,160 --> 01:48:11,270
estamos afeitos a pensar sobre iso.

2443
01:48:11,270 --> 01:48:14,270
Todos adoitaba pensar
termos de servidores e anfitrións.

2444
01:48:14,270 --> 01:48:16,580
Non é sobre isto máis.

2445
01:48:16,580 --> 01:48:19,310
Trátase de infraestrutura como código.

2446
01:48:19,310 --> 01:48:22,470
Implantar o código á nube e
deixe a nube executa-lo para ti.

2447
01:48:22,470 --> 01:48:24,980
E iso é o que a AWS está intentando facer.

2448
01:48:24,980 --> 01:48:29,690
>> Audiencia: caixa de ouro no medio Entón,
do API Pasarela non é servidor-like,

2449
01:48:29,690 --> 01:48:30,576
pero en vez diso é apenas--

2450
01:48:30,576 --> 01:48:32,850
>> Rick Houlihan: Pode pensar
niso como fachada servidor.

2451
01:48:32,850 --> 01:48:38,040
Todo o que é que vai levar un HTTP
solicitar e mapea-la para outro proceso.

2452
01:48:38,040 --> 01:48:39,192
Isto é todo o que fai.

2453
01:48:39,192 --> 01:48:41,525
E neste caso, estamos estean situados
Lo para unha función lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Todo ben, entón iso é todo o que eu teño.

2456
01:48:45,410 --> 01:48:46,190
Moitas grazas.

2457
01:48:46,190 --> 01:48:46,800
Aprécioo.

2458
01:48:46,800 --> 01:48:48,100
Sei que queremos un pouco ao longo do tempo.

2459
01:48:48,100 --> 01:48:49,980
E espero que vós ten
un pouco de información

2460
01:48:49,980 --> 01:48:51,410
que pode aproveitar hoxe.

2461
01:48:51,410 --> 01:48:53,520
E pido desculpas se eu fun
sobre algunhas das súas cabezas,

2462
01:48:53,520 --> 01:48:56,697
pero hai unha morea de bo
coñecemento fundamental fundamentais

2463
01:48:56,697 --> 01:48:58,280
que eu creo que é moi valioso para ti.

2464
01:48:58,280 --> 01:48:59,825
Entón, grazas por me recibir.

2465
01:48:59,825 --> 01:49:00,325
[Aplausos]

2466
01:49:00,325 --> 01:49:02,619
Audiencia: [inaudível]
é cando estaba dicindo

2467
01:49:02,619 --> 01:49:05,160
tiña que ir a través da cousa
dende o principio ao final

2468
01:49:05,160 --> 01:49:07,619
para obter os valores correctos
ou os mesmos valores,

2469
01:49:07,619 --> 01:49:09,410
como é que os valores
cambiar [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 cambian?

2472
01:49:11,800 --> 01:49:15,180
Ben, porque se eu non correr
todo o camiño ata o final,

2473
01:49:15,180 --> 01:49:19,770
entón eu non sei o que cambia
foron feitas na última milla.

2474
01:49:19,770 --> 01:49:22,144
Non vai ser a
mesmos datos que o que vin.

2475
01:49:22,144 --> 01:49:24,560
Audiencia: Ah, entón só
non chegar a entrada enteira.

2476
01:49:24,560 --> 01:49:24,770
Rick Houlihan: Correcto.

2477
01:49:24,770 --> 01:49:26,895
Ten que ir do comezo
ao fin, e entón é

2478
01:49:26,895 --> 01:49:29,280
vai ser un estado consistente.

2479
01:49:29,280 --> 01:49:31,520
Legal.

2480
01:49:31,520 --> 01:49:35,907
>> Audiencia: Entón mostrounos DynamoDB
pode facer documento ou o valor da clave.

2481
01:49:35,907 --> 01:49:38,740
E nós pasamos moito tempo no
valor clave cun hash e as formas

2482
01:49:38,740 --> 01:49:40,005
para lanzalo ao redor.

2483
01:49:40,005 --> 01:49:43,255
Cando mirou para estas táboas, é que
deixando atrás o enfoque documento?

2484
01:49:43,255 --> 01:49:44,600
>> Rick Houlihan: eu non faría
dicir deixalo atrás.

2485
01:49:44,600 --> 01:49:45,855
>> Audiencia: Eles foron separados de as--

2486
01:49:45,855 --> 01:49:49,140
>> Rick Houlihan: Co documento
visión, o tipo de documento en DynamoDB

2487
01:49:49,140 --> 01:49:50,880
é só pensar en como outro atributo.

2488
01:49:50,880 --> 01:49:53,560
É un atributo que contén
unha estrutura de datos xerárquica.

2489
01:49:53,560 --> 01:49:56,980
E, a continuación, nas consultas,
pode utilizar as propiedades

2490
01:49:56,980 --> 01:49:59,480
destes obxectos usando Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Para que eu poida filtrar nun nested
propiedade do documento JSON.

2492
01:50:03,562 --> 01:50:05,520
Audiencia: Entón calquera momento I
facer un achegamento documento,

2493
01:50:05,520 --> 01:50:07,906
Podo clasificar de chegar ao tabular--

2494
01:50:07,906 --> 01:50:08,780
Audiencia: Absolutamente.

2495
01:50:08,780 --> 01:50:09,800
Audiencia: --indexes e
cousas que falou.

2496
01:50:09,800 --> 01:50:11,280
Rick Houlihan: Si, o
índices e todo o que,

2497
01:50:11,280 --> 01:50:13,363
cando quere indexar o
propiedades do JSON,

2498
01:50:13,363 --> 01:50:18,230
a forma que nós teriamos de facelo é se
inserir un obxecto JSON ou un documento

2499
01:50:18,230 --> 01:50:20,780
en Dynamo, usaría correntes.

2500
01:50:20,780 --> 01:50:22,400
Fluxos ía ler a entrada.

2501
01:50:22,400 --> 01:50:24,340
Quere obter que JSON
obxecto e diría OK,

2502
01:50:24,340 --> 01:50:26,030
o que é a propiedade que quero para o índice?

2503
01:50:26,030 --> 01:50:28,717
>> Crea unha táboa derivada.

2504
01:50:28,717 --> 01:50:30,300
Agora que é a forma como funciona agora.

2505
01:50:30,300 --> 01:50:32,650
Non permitimos que índice
directamente estas propiedades.

2506
01:50:32,650 --> 01:50:33,520
>> Audiencia: Tabularizing seus documentos.

2507
01:50:33,520 --> 01:50:36,230
>> Rick Houlihan: Exactamente, achatando
el, tabularizing iso, exactamente.

2508
01:50:36,230 --> 01:50:37,415
Isto é o que fai con el.

2509
01:50:37,415 --> 01:50:37,860
>> Audiencia: Grazas.

2510
01:50:37,860 --> 01:50:39,609
>> Rick Houlihan: Si,
absolutamente, grazas.

2511
01:50:39,609 --> 01:50:42,240
Audiencia: Entón é tipo de
Mongo atende classifers Redis.

2512
01:50:42,240 --> 01:50:43,990
>> Rick Houlihan: Si,
é moi parecido.

2513
01:50:43,990 --> 01:50:45,940
Esta é unha boa descrición para el.

2514
01:50:45,940 --> 01:50:47,490
Legal.

2515
01:50:47,490 --> 01:50:49,102