1
00:00:00,000 --> 00:00:04,969
>> [REPRODUCCIÓN DE MÚSICA]

2
00:00:04,969 --> 00:00:06,010
RICK HOULIHAN: De acuerdo.

3
00:00:06,010 --> 00:00:06,600
Hola a todos.

4
00:00:06,600 --> 00:00:07,670
Mi nombre es Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Yo soy un director de alto nivel
arquitecto de soluciones de AWS.

6
00:00:10,330 --> 00:00:14,070
Me concentro en NoSQL y
Tecnologías DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Estoy hoy aquí para hablar
que un poco sobre ellos.

8
00:00:16,930 --> 00:00:18,970
>> Mi formación es
principalmente en la capa de datos.

9
00:00:18,970 --> 00:00:21,390
Pasé la mitad de mi desarrollo
carrera escribiendo base de datos,

10
00:00:21,390 --> 00:00:25,930
de acceso a datos, soluciones
para diversas aplicaciones.

11
00:00:25,930 --> 00:00:30,000
He estado en la virtualización de la nube
durante unos 20 años.

12
00:00:30,000 --> 00:00:33,460
Así que antes de que la nube era la Nube,
solíamos llamarlo utility computing.

13
00:00:33,460 --> 00:00:37,170
Y la idea fue, es como
PG & E, que paga por lo que usa.

14
00:00:37,170 --> 00:00:38,800
Hoy lo llamamos la nube.

15
00:00:38,800 --> 00:00:41,239
>> Pero con los años, he trabajado
durante un par de empresas

16
00:00:41,239 --> 00:00:42,530
probablemente nunca has oído hablar.

17
00:00:42,530 --> 00:00:47,470
Pero he compilado una lista de técnicos
logros, supongo que dirías.

18
00:00:47,470 --> 00:00:51,620
Tengo ocho patentes en los sistemas de la nube
virtualización, diseño de microprocesadores,

19
00:00:51,620 --> 00:00:54,440
procesamiento de eventos complejos,
y otras áreas también.

20
00:00:54,440 --> 00:00:58,290
>> Así que en estos días, me centro sobre todo en NoSQL
tecnologías y la próxima generación

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

22
00:00:59,450 --> 00:01:03,370
Y eso es por lo general lo que voy
estar aquí hablando con usted hoy sobre.

23
00:01:03,370 --> 00:01:06,030
Entonces, ¿qué se puede esperar
de esta sesión,

24
00:01:06,030 --> 00:01:08,254
vamos a ir a través de una breve
historia de procesamiento de datos.

25
00:01:08,254 --> 00:01:10,420
Siempre es útil
entender de dónde venimos

26
00:01:10,420 --> 00:01:12,400
y por qué estamos donde estamos.

27
00:01:12,400 --> 00:01:15,600
Y hablaremos un poco
poco sobre la tecnologí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
>> Vamos a entrar en algunos de
las interioridades DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB es de AWS sin sabor.

31
00:01:24,350 --> 00:01:27,340
Es una totalmente gestionado y
NoSQL solución alojada.

32
00:01:27,340 --> 00:01:32,420
Y hablaremos un poco sobre la mesa
estructura, API, tipos de datos, índices,

33
00:01:32,420 --> 00:01:35,177
y algunos de los internals
de que la tecnología DynamoDB.

34
00:01:35,177 --> 00:01:37,760
Vamos a entrar en algunos de los diseños
patrones y mejores prácticas.

35
00:01:37,760 --> 00:01:39,968
Vamos a hablar de cómo se
utilizar esta tecnología para algunos

36
00:01:39,968 --> 00:01:41,430
de las aplicaciones de hoy en día.

37
00:01:41,430 --> 00:01:44,820
Y luego vamos a hablar un poco
acerca de la evolución o de la emergencia

38
00:01:44,820 --> 00:01:48,980
de un nuevo paradigma en la programación
llamados aplicaciones orientadas a eventos

39
00:01:48,980 --> 00:01:51,580
y cómo juega DynamoDB en eso también.

40
00:01:51,580 --> 00:01:54,690
Y os dejamos un poco de
una arquitectura de referencia discusión

41
00:01:54,690 --> 00:01:59,540
por lo que podemos hablar de algunas de
las formas en que se pueden utilizar DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Así que primero off-- esta es una pregunta
He oído hablar mucho es, lo que es una base de datos.

43
00:02:04,116 --> 00:02:06,240
Mucha gente piensa que
sabe lo que es una base de datos.

44
00:02:06,240 --> 00:02:08,360
Si Google, verás esto.

45
00:02:08,360 --> 00:02:11,675
Es un un conjunto estructurado de datos celebrada
en un ordenador, especialmente uno que

46
00:02:11,675 --> 00:02:13,600
es accesible de varias maneras.

47
00:02:13,600 --> 00:02:16,992
Supongo que es una buena
definición de una base de datos moderno.

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

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

50
00:02:20,935 --> 00:02:23,120
Y esto implica que está en una computadora.

51
00:02:23,120 --> 00:02:25,750
Y las bases de datos no lo hicieron
siempre existirá en las computadoras.

52
00:02:25,750 --> 00:02:28,020
Bases de datos realmente existían en muchas maneras.

53
00:02:28,020 --> 00:02:32,000
>> Así que una mejor definición de un
base de datos es algo como esto.

54
00:02:32,000 --> 00:02:34,786
Una base de datos es una organizada
mecanismo para almacenar, gestionar,

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

56
00:02:35,910 --> 00:02:36,868
Se trata de About.com.

57
00:02:36,868 --> 00:02:42,080
Así que me gusta esto porque realmente habla
sobre una base de datos es un repositorio,

58
00:02:42,080 --> 00:02:44,800
un depósito de
información, no necesariamente

59
00:02:44,800 --> 00:02:46,780
algo que se sienta en un ordenador.

60
00:02:46,780 --> 00:02:49,290
Y a través de la historia,
no siempre han tenido las computadoras.

61
00:02:49,290 --> 00:02:52,110
>> Ahora, si le pregunto a la media
hoy desarrollador lo que es

62
00:02:52,110 --> 00:02:54,770
una base de datos, que es la respuesta que recibo.

63
00:02:54,770 --> 00:02:56,070
En algún lugar que puedo meter cosas.

64
00:02:56,070 --> 00:02:56,670
¿Correcto?

65
00:02:56,670 --> 00:02:58,725
Y es cierto.

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

67
00:02:59,600 --> 00:03:02,700
Debido a que la base de datos es realmente
el fundamento de la aplicación moderna.

68
00:03:02,700 --> 00:03:04,810
Es la base
de cada aplicación.

69
00:03:04,810 --> 00:03:07,240
Y la forma de construir que
base de datos, cómo se estructura

70
00:03:07,240 --> 00:03:11,750
que los datos que va a dictar la forma en que
aplicación realiza como se cambia la escala.

71
00:03:11,750 --> 00:03:14,640
>> Así que una gran parte de mi trabajo hoy
se trata de lo que

72
00:03:14,640 --> 00:03:17,180
ocurre cuando los desarrolladores
adoptar este enfoque

73
00:03:17,180 --> 00:03:19,510
y hacer frente a las secuelas
de una aplicación que

74
00:03:19,510 --> 00:03:24,966
ahora está más allá de la escala original
intención y el sufrimiento de mal diseño.

75
00:03:24,966 --> 00:03:26,840
Así que espero que cuando
alejarse de hoy, podrás

76
00:03:26,840 --> 00:03:29,010
tener un par de herramientas
el cinturón que te mantendrá

77
00:03:29,010 --> 00:03:32,566
de hacer los mismos errores.

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

79
00:03:33,066 --> 00:03:36,360
Así que vamos a hablar un poco de
la línea de tiempo de la tecnología de base de datos.

80
00:03:36,360 --> 00:03:38,830
Creo que leí un
artículo no hace tanto tiempo

81
00:03:38,830 --> 00:03:43,020
y dijo algo sobre la lines--
que es una declaración muy poético.

82
00:03:43,020 --> 00:03:46,590
Dijo que la historia
de procesamiento de datos es

83
00:03:46,590 --> 00:03:49,350
llena de altas marcas de agua
de la abundancia de datos.

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

85
00:03:49,920 --> 00:03:52,532
Ahora, supongo que eso es algo de cierto.

86
00:03:52,532 --> 00:03:54,990
Pero yo en realidad mirar es como
la historia es en realidad llena

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

88
00:03:56,820 --> 00:04:00,040
Debido a que la velocidad de datos de
la ingestión no se pone.

89
00:04:00,040 --> 00:04:01,360
Sólo sube.

90
00:04:01,360 --> 00:04:03,670
>> Y la innovación se produce cuando
vemos presión de datos, que

91
00:04:03,670 --> 00:04:07,825
es la cantidad de datos que es
Ahora en que entra en el sistema.

92
00:04:07,825 --> 00:04:12,027
Y no puede ser procesada
de manera eficiente, ya sea en el tiempo o en el costo.

93
00:04:12,027 --> 00:04:14,110
Y fue entonces cuando empezamos
para mirar la presión de datos.

94
00:04:14,110 --> 00:04:15,920
>> Así que cuando nos fijamos en la
primera base de datos, esta

95
00:04:15,920 --> 00:04:17,180
es el que estaba entre nuestros oídos.

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

97
00:04:18,310 --> 00:04:19,194
Es una base de datos bien.

98
00:04:19,194 --> 00:04:21,110
Tiene una alta disponibilidad.

99
00:04:21,110 --> 00:04:21,959
Es siempre encendido.

100
00:04:21,959 --> 00:04:23,930
Usted siempre puede conseguirlo.

101
00:04:23,930 --> 00:04:24,890
>> Pero es solo usuario.

102
00:04:24,890 --> 00:04:26,348
No puedo compartir mis pensamientos con ustedes.

103
00:04:26,348 --> 00:04:28,370
No se puede tener en mis pensamientos
cuando quieras.

104
00:04:28,370 --> 00:04:30,320
Y su abilitiy no es tan bueno.

105
00:04:30,320 --> 00:04:32,510
Nos olvidamos de las cosas.

106
00:04:32,510 --> 00:04:36,540
De vez en cuando, uno de nosotros hojas
y se mueve a otra existencia

107
00:04:36,540 --> 00:04:39,110
y perdemos todo
eso fue en esa base de datos.

108
00:04:39,110 --> 00:04:40,640
Así que no es tan bueno.

109
00:04:40,640 --> 00:04:43,189
>> Y esto funcionó bien con el tiempo
cuando estábamos de vuelta en el día

110
00:04:43,189 --> 00:04:46,230
cuando todo lo que realmente necesitamos saber es
¿a dónde vamos a ir mañana

111
00:04:46,230 --> 00:04:49,630
o cuando nos reunimos la mejor comida.

112
00:04:49,630 --> 00:04:52,820
Pero, como hemos empezado a crecer como
la civilización y el gobierno comenzaron

113
00:04:52,820 --> 00:04:55,152
para venir a ser, y
las empresas comenzaron a evolucionar,

114
00:04:55,152 --> 00:04:57,360
empezamos a darnos cuenta de que
necesitan un poco más de lo que

115
00:04:57,360 --> 00:04:58,210
podríamos poner en nuestra cabeza.

116
00:04:58,210 --> 00:04:58,870
¿Correcto?

117
00:04:58,870 --> 00:05:00,410
>> Necesitábamos los sistemas de registro.

118
00:05:00,410 --> 00:05:02,220
Necesitábamos lugares para ser capaces de almacenar datos.

119
00:05:02,220 --> 00:05:05,450
Así que empezamos a escribir documentos,
la creación de bibliotecas y archivos.

120
00:05:05,450 --> 00:05:08,000
Comenzamos el desarrollo de un
sistema de un libro mayor de contabilidad.

121
00:05:08,000 --> 00:05:12,200
Y ese sistema de conteo de libro mayor
corrió el mundo durante muchos siglos,

122
00:05:12,200 --> 00:05:15,580
y tal vez incluso milenios como
que tipo de crecimos hasta el punto

123
00:05:15,580 --> 00:05:18,420
donde esa carga de datos superó
la capacidad de esos sistemas

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

125
00:05:19,870 --> 00:05:22,070
>> Y esto realmente ocurrió en la década de 1880.

126
00:05:22,070 --> 00:05:22,570
¿Correcto?

127
00:05:22,570 --> 00:05:24,390
En los EE.UU. Censo 1880.

128
00:05:24,390 --> 00:05:26,976
Esto es realmente donde el giro
punto de procesamiento de datos moderno.

129
00:05:26,976 --> 00:05:28,850
Este es el punto en
que la cantidad de datos

130
00:05:28,850 --> 00:05:32,060
que estaba siendo recogido por el
Gobierno de Estados Unidos llegó al punto

131
00:05:32,060 --> 00:05:34,005
donde tomó ocho años para procesar.

132
00:05:34,005 --> 00:05:36,350
>> Ahora, ocho años-- como
usted sabe, el censo

133
00:05:36,350 --> 00:05:39,180
sale cada 10 años-- por lo que es
bastante obvio que para el momento en que

134
00:05:39,180 --> 00:05:41,419
tiene el censo de 1890,
la cantidad de datos que

135
00:05:41,419 --> 00:05:43,210
que iba a ser procesado
por el gobierno era

136
00:05:43,210 --> 00:05:46,335
va a superar los 10 años que
llevaría a puesto en marcha el nuevo censo.

137
00:05:46,335 --> 00:05:47,250
Esto era un problema.

138
00:05:47,250 --> 00:05:49,000
>> Así que un tipo llamado Herman
Hollerith llegó

139
00:05:49,000 --> 00:05:52,640
e inventó ponche registro de la unidad
tarjetas, lector de tarjetas perforadas, tarjetas perforadas

140
00:05:52,640 --> 00:05:58,420
tabulador, y el cotejo de
los mecanismos para esta tecnología.

141
00:05:58,420 --> 00:06:01,860
Y esa empresa que se formó en el
tiempo, junto con un par de los demás,

142
00:06:01,860 --> 00:06:05,450
en realidad se convirtió en uno de los pilares de un
pequeña empresa que hoy conocemos llama IBM.

143
00:06:05,450 --> 00:06:08,417
>> Así IBM originalmente estaba en
el negocio de base de datos.

144
00:06:08,417 --> 00:06:09,750
Y eso es realmente lo que hicieron.

145
00:06:09,750 --> 00:06:11,110
Lo hicieron de procesamiento de datos.

146
00:06:11,110 --> 00:06:15,400
>> Como lo que la proliferación de golpe
tarjetas, un mecanismos ingeniosos

147
00:06:15,400 --> 00:06:18,560
de ser capaz de aprovechar ese
tecnología para sondear conjuntos de resultados ordenados.

148
00:06:18,560 --> 00:06:20,726
Se puede ver en esta foto
no tenemos un poco--

149
00:06:20,726 --> 00:06:23,970
que es un poco small-- pero se puede ver
un mecanismo mecánico muy ingenioso

150
00:06:23,970 --> 00:06:26,970
donde tenemos una baraja de tarjetas perforadas.

151
00:06:26,970 --> 00:06:28,720
Y la toma de alguien
un poco de destornillador

152
00:06:28,720 --> 00:06:31,400
y ajustarse a través de la
ranuras y levantándolo

153
00:06:31,400 --> 00:06:34,820
para conseguir que el partido, que
resultados ordenados establecen.

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

155
00:06:36,270 --> 00:06:38,690
Hacemos esto todo el tiempo
hoy en el ordenador,

156
00:06:38,690 --> 00:06:40,100
cuando lo haces en la base de datos.

157
00:06:40,100 --> 00:06:41,620
Solíamos hacerlo de forma manual, ¿no?

158
00:06:41,620 --> 00:06:42,994
La gente pone estas cosas juntas.

159
00:06:42,994 --> 00:06:45,440
Y fue la proliferación
de estas tarjetas perforadas

160
00:06:45,440 --> 00:06:50,070
en lo que llamamos la batería de datos
y carretes de datos, cinta de papel.

161
00:06:50,070 --> 00:06:55,980
>> La industria de procesamiento de datos se llevó
una lección de los jugadores pianos.

162
00:06:55,980 --> 00:06:57,855
Reproductor de pianos de vuelta en
el cambio de siglo

163
00:06:57,855 --> 00:07:02,100
utilizado para utilizar bobinas de papel con ranuras
a decirle que qué teclas para jugar.

164
00:07:02,100 --> 00:07:05,380
Así que la tecnología se adaptó
finalmente para almacenar datos digitales,

165
00:07:05,380 --> 00:07:08,070
porque podrían poner esos datos
en esos carretes de cinta de papel.

166
00:07:08,070 --> 00:07:10,870
>> Ahora, como resultado, los datos
fue actually-- cómo

167
00:07:10,870 --> 00:07:14,960
accede a este dato fue directamente
depende de lo guardaste.

168
00:07:14,960 --> 00:07:17,825
Así que si pongo los datos en una cinta,
Tuve acceso a los datos de forma lineal.

169
00:07:17,825 --> 00:07:20,475
Tuve que rodar el todo
cinta para acceder a todos los datos.

170
00:07:20,475 --> 00:07:22,600
Si pongo los datos en el golpe
tarjetas, que podrían acceder a ella

171
00:07:22,600 --> 00:07:26,270
en un poco más al azar
la moda, tal vez no tan rápido.

172
00:07:26,270 --> 00:07:30,770
>> Pero hubo limitaciones en la forma en que
acceso a los datos en función de cómo se almacenó.

173
00:07:30,770 --> 00:07:32,890
Y por lo que este era un problema
entrar en los '50s.

174
00:07:32,890 --> 00:07:37,890
Una vez más, podemos empezar a ver que a medida que
desarrollar nuevas tecnologías para procesar

175
00:07:37,890 --> 00:07:41,670
los datos, a la derecha, se abre
la puerta a nuevas soluciones,

176
00:07:41,670 --> 00:07:45,852
para los nuevos programas, nuevos
las solicitudes de esos datos.

177
00:07:45,852 --> 00:07:47,810
Y realmente, la gobernanza
pudo haber sido la razón

178
00:07:47,810 --> 00:07:49,435
Por eso hemos desarrollado algunos de estos sistemas.

179
00:07:49,435 --> 00:07:52,290
Pero el negocio se convirtió rápidamente
el conductor detrás de la evolución

180
00:07:52,290 --> 00:07:54,720
de la base de datos moderno y
el sistema de archivos moderno.

181
00:07:54,720 --> 00:07:56,870
>> Así que la próxima cosa que
ocurrió fue en los años 50

182
00:07:56,870 --> 00:08:00,780
fue el sistema de archivos y la
desarrollo de almacenamiento de acceso aleatorio.

183
00:08:00,780 --> 00:08:02,050
Esta era hermosa.

184
00:08:02,050 --> 00:08:06,230
Ahora, de repente, podemos poner nuestra
archivos en cualquier parte de estos discos duros

185
00:08:06,230 --> 00:08:09,760
y podemos acceder a estos datos al azar.

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

187
00:08:11,950 --> 00:08:14,920
Y hemos resuelto todo el mundo
problemas con el procesamiento de datos.

188
00:08:14,920 --> 00:08:17,550
>> Y que duró alrededor de 20 o
30 años, hasta la evolución

189
00:08:17,550 --> 00:08:22,100
de la base de datos relacional, que
es cuando el mundo decidió que ahora

190
00:08:22,100 --> 00:08:27,940
necesita tener un repositorio que derrota
la dispersión de los datos a través del archivo

191
00:08:27,940 --> 00:08:29,540
sistemas que hemos construido. ¿Correcto?

192
00:08:29,540 --> 00:08:34,270
Demasiados datos distribuidos en demasiados
lugares, la de-duplicación de datos,

193
00:08:34,270 --> 00:08:37,120
y el costo de almacenamiento fue enorme.

194
00:08:37,120 --> 00:08:43,760
>> En los años 70, el recurso más caro
que un equipo tenía era el de almacenamiento.

195
00:08:43,760 --> 00:08:46,200
El procesador era
visto como un costo fijo.

196
00:08:46,200 --> 00:08:49,030
Cuando compro la caja,
la CPU hace algún trabajo.

197
00:08:49,030 --> 00:08:51,960
Se va a estar girando si
que está trabajando o no en realidad.

198
00:08:51,960 --> 00:08:53,350
Eso es realmente un costo hundido.

199
00:08:53,350 --> 00:08:56,030
>> Pero lo que me ha costado como
negocio es el almacenamiento.

200
00:08:56,030 --> 00:09:00,020
Si tengo que comprar más discos próximo
mes, eso es un costo real que tengo que pagar.

201
00:09:00,020 --> 00:09:01,620
Y que el almacenamiento es caro.

202
00:09:01,620 --> 00:09:05,020
>> Ahora tenemos avance rápido 40 años
y tenemos un problema diferente.

203
00:09:05,020 --> 00:09:10,020
El cálculo es ahora la
recurso más caro.

204
00:09:10,020 --> 00:09:11,470
El almacenamiento es barato.

205
00:09:11,470 --> 00:09:14,570
Quiero decir, podemos ir a cualquier parte de la
Cloud y podemos encontrar almacenamiento barato.

206
00:09:14,570 --> 00:09:17,190
Pero lo que no puedo encontrar es compute barato.

207
00:09:17,190 --> 00:09:20,700
>> Así que la evolución de hoy
la tecnología, de la tecnología de base de datos,

208
00:09:20,700 --> 00:09:23,050
que realmente está centrado alrededor
bases de datos distribuidas

209
00:09:23,050 --> 00:09:26,960
que no sufren de
el mismo tipo de escala

210
00:09:26,960 --> 00:09:29,240
limitaciones de las bases de datos relacionales.

211
00:09:29,240 --> 00:09:32,080
Hablaremos un poco sobre
lo que realmente significa.

212
00:09:32,080 --> 00:09:34,760
>> Pero una de las razones y
el conductor detrás de esto- nos

213
00:09:34,760 --> 00:09:38,290
habló de la presión de datos.

214
00:09:38,290 --> 00:09:41,920
Los datos de presión es algo
que impulsa la innovación.

215
00:09:41,920 --> 00:09:44,610
Y si nos fijamos en más de
los últimos cinco años,

216
00:09:44,610 --> 00:09:48,180
esta es una gráfica de lo que los datos
carga a través de la empresa en general

217
00:09:48,180 --> 00:09:49,640
parece que en los últimos cinco años.

218
00:09:49,640 --> 00:09:52,570
>> Y la regla general
estos days-- si van Google--

219
00:09:52,570 --> 00:09:55,290
es 90% de los datos que
almacenamos hoy, y fue

220
00:09:55,290 --> 00:09:57,330
generada en los últimos dos años.

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

222
00:09:57,911 --> 00:09:59,410
Ahora, esto no es una tendencia que hay de nuevo.

223
00:09:59,410 --> 00:10:01,230
Esta es una tendencia que ha estado
salir por 100 años.

224
00:10:01,230 --> 00:10:03,438
Desde Herman Hollerith
desarrollado la tarjeta perforada,

225
00:10:03,438 --> 00:10:08,040
hemos estado construyendo depósitos de datos
y la recolección de datos a velocidades fenomenales.

226
00:10:08,040 --> 00:10:10,570
>> Así que en los últimos 100 años,
que hemos visto esta tendencia.

227
00:10:10,570 --> 00:10:11,940
Eso no va a cambiar.

228
00:10:11,940 --> 00:10:14,789
En el futuro, vamos a ver
esto, si no una tendencia acelerada.

229
00:10:14,789 --> 00:10:16,330
Y usted puede ver lo que parece.

230
00:10:16,330 --> 00:10:23,510
>> Si un negocio en el año 2010 tenía una
terabyte de datos bajo gestión,

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

232
00:10:27,080 --> 00:10:30,380
Eso es 6.500 veces más datos.

233
00:10:30,380 --> 00:10:31,200
Y sé que esto.

234
00:10:31,200 --> 00:10:33,292
Yo trabajo con estos negocios todos los días.

235
00:10:33,292 --> 00:10:35,000
Hace cinco años,
sería hablar con empresas

236
00:10:35,000 --> 00:10:38,260
quien hablar conmigo sobre lo que es un dolor
que es gestionar terabytes de datos.

237
00:10:38,260 --> 00:10:39,700
Y que hablarían
a mí sobre cómo vemos

238
00:10:39,700 --> 00:10:41,825
que este es probablemente va
ser un petabyte o dos

239
00:10:41,825 --> 00:10:43,030
dentro de un par de años.

240
00:10:43,030 --> 00:10:45,170
>> Estas mismas empresas
hoy me voy a reunir con,

241
00:10:45,170 --> 00:10:48,100
y que están hablando conmigo sobre la
problema se haya teniendo gestió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í la explosión de la
datos en la industria

244
00:10:53,590 --> 00:10:56,670
está impulsando el enorme
la necesidad de mejores soluciones.

245
00:10:56,670 --> 00:11:00,980
Y la base de datos relacional es
simplemente no vivir de acuerdo a la demanda.

246
00:11:00,980 --> 00:11:03,490
>> Y así hay un lineal
correlación entre la presión de datos

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

248
00:11:05,210 --> 00:11:07,780
La historia nos ha demostrado
esto, que con el tiempo,

249
00:11:07,780 --> 00:11:11,090
siempre que el volumen de datos
que necesita ser procesada

250
00:11:11,090 --> 00:11:15,490
excede la capacidad del sistema de
para procesarlo en un tiempo razonable

251
00:11:15,490 --> 00:11:18,870
oa un costo razonable,
a continuación, las nuevas tecnologías

252
00:11:18,870 --> 00:11:21,080
han sido inventados para resolver esos problemas.

253
00:11:21,080 --> 00:11:24,090
Esas nuevas tecnologías,
a su vez, abre la puerta

254
00:11:24,090 --> 00:11:27,840
a otra serie de problemas, que
está reuniendo aún más datos.

255
00:11:27,840 --> 00:11:29,520
>> Ahora, nosotros no vamos a parar esto.

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

257
00:11:30,020 --> 00:11:31,228
No vamos a parar esto.

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

259
00:11:31,830 --> 00:11:35,520
Porque no se puede saber todo
que hay que saber en el universo.

260
00:11:35,520 --> 00:11:40,510
Y mientras hemos estado vivos,
en toda la historia del hombre,

261
00:11:40,510 --> 00:11:43,440
siempre hemos impulsado saber más.

262
00:11:43,440 --> 00:11:49,840
>> Así que parece que cada pulgada que avanzamos
por el camino de los descubrimientos científicos,

263
00:11:49,840 --> 00:11:54,620
estamos multiplicando la cantidad de datos
que necesitamos para procesar de forma exponencial

264
00:11:54,620 --> 00:11:59,920
como descubrimos más y más y más
sobre el funcionamiento interno de la vida,

265
00:11:59,920 --> 00:12:04,530
acerca de cómo funciona el universo, sobre
conduciendo el descubrimiento científico,

266
00:12:04,530 --> 00:12:06,440
y la invención que
que estamos haciendo hoy.

267
00:12:06,440 --> 00:12:09,570
El volumen de datos simplemente
aumenta continuamente.

268
00:12:09,570 --> 00:12:12,120
Así que ser capaz de hacer frente
este problema es enorme.

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

270
00:12:14,790 --> 00:12:17,410
>> Así que una de las cosas
miramos como por qué NoSQL?

271
00:12:17,410 --> 00:12:19,200
¿Cómo NoSQL a resolver este problema?

272
00:12:19,200 --> 00:12:24,980
Bueno, bases de datos relacionales,
Lenguaje de consulta estructurado,

273
00:12:24,980 --> 00:12:28,600
SQL-- eso es realmente una construcción de la
relacional database-- estas cosas son

274
00:12:28,600 --> 00:12:30,770
optimizado para el almacenamiento.

275
00:12:30,770 --> 00:12:33,180
>> Allá por los años 70, de nuevo,
disco es caro.

276
00:12:33,180 --> 00:12:36,990
El ejercicio de aprovisionamiento de almacenamiento
en la empresa es de nunca acabar.

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

278
00:12:37,490 --> 00:12:38,020
Yo lo viví.

279
00:12:38,020 --> 00:12:41,250
Escribí controladores de almacenamiento para un
empresa SuperServer Enterprised

280
00:12:41,250 --> 00:12:42,470
allá por los años 90.

281
00:12:42,470 --> 00:12:45,920
Y el resultado final está acumulando otra
matriz de almacenamiento era sólo algo que

282
00:12:45,920 --> 00:12:47,600
pasó todos los días en la empresa.

283
00:12:47,600 --> 00:12:49,030
Y nunca se detuvo.

284
00:12:49,030 --> 00:12:52,690
Mayor densidad de almacenamiento, la demanda
para el almacenamiento de alta densidad,

285
00:12:52,690 --> 00:12:56,340
y para el almacenamiento más eficiente
devices-- nunca se detuvo.

286
00:12:56,340 --> 00:13:00,160
>> Y NoSQL es una gran tecnología
porque normaliza los datos.

287
00:13:00,160 --> 00:13:02,210
Es de-duplica los datos.

288
00:13:02,210 --> 00:13:07,180
Se pone los datos en una estructura que
es agnóstico a cada patrón de acceso.

289
00:13:07,180 --> 00:13:11,600
Múltiples aplicaciones pueden llegar a ese
Base de datos SQL, ejecutar consultas ad hoc,

290
00:13:11,600 --> 00:13:15,950
y obtener datos en la forma que
tenga que procesar para sus cargas de trabajo.

291
00:13:15,950 --> 00:13:17,570
Eso suena fantástico.

292
00:13:17,570 --> 00:13:21,350
Pero la conclusión es que con cualquier
sistema, si es agnóstico a todo,

293
00:13:21,350 --> 00:13:23,500
está optimizado para nada.

294
00:13:23,500 --> 00:13:24,050
¿De acuerdo?

295
00:13:24,050 --> 00:13:26,386
>> Y eso es lo que conseguimos con
la base de datos relacional.

296
00:13:26,386 --> 00:13:27,510
Está optimizado para su almacenamiento.

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

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

299
00:13:29,370 --> 00:13:31,660
Es compatible con las consultas ad hoc.

300
00:13:31,660 --> 00:13:34,000
Y ella y se escala verticalmente.

301
00:13:34,000 --> 00:13:39,030
>> Si tengo que conseguir una base de datos SQL grande
o una base de datos SQL más potente,

302
00:13:39,030 --> 00:13:41,090
Voy comprar un pedazo más grande de hierro.

303
00:13:41,090 --> 00:13:41,600
¿De acuerdo?

304
00:13:41,600 --> 00:13:44,940
He trabajado con muchos clientes
que han sido a través de mejoras importantes

305
00:13:44,940 --> 00:13:48,340
en su infraestructura de SQL única
para averiguar seis meses más tarde,

306
00:13:48,340 --> 00:13:49,750
que están golpeando la pared de nuevo.

307
00:13:49,750 --> 00:13:55,457
Y la respuesta de Oracle o MSSQL
o cualquier otra persona es conseguir una caja más grande.

308
00:13:55,457 --> 00:13:58,540
Bueno, tarde o temprano, no se puede comprar una
caja más grande, y eso es un problema real.

309
00:13:58,540 --> 00:14:00,080
Tenemos que cambiar realmente las cosas.

310
00:14:00,080 --> 00:14:01,080
Entonces, ¿dónde funciona esto?

311
00:14:01,080 --> 00:14:06,560
Funciona bien para fuera de línea
análisis, las cargas de trabajo de tipo OLAP.

312
00:14:06,560 --> 00:14:08,670
Y eso es realmente donde SQL pertenece.

313
00:14:08,670 --> 00:14:12,540
Ahora, se utiliza hoy en día en muchos en línea
transaccional de tipo de procesamiento

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

315
00:14:13,330 --> 00:14:16,460
Y funciona muy bien en
un cierto nivel de utilización,

316
00:14:16,460 --> 00:14:18,670
pero simplemente no escala
la forma en que NoSQL hace.

317
00:14:18,670 --> 00:14:20,660
Y hablaremos un poco
poco acerca de por qué es así.

318
00:14:20,660 --> 00:14:23,590
>> Ahora, NoSQL, por otro lado,
está más optimizado para cálculo.

319
00:14:23,590 --> 00:14:24,540
¿De acuerdo?

320
00:14:24,540 --> 00:14:26,830
No es agnóstico a
el patrón de acceso.

321
00:14:26,830 --> 00:14:31,620
Es lo que llamamos de-normalizada
estructura o una estructura jerárquica.

322
00:14:31,620 --> 00:14:35,000
Los datos en una base de datos relacional es
unido de varias tablas

323
00:14:35,000 --> 00:14:36,850
para producir la opinión de que lo que necesita.

324
00:14:36,850 --> 00:14:40,090
Los datos en la base de datos NoSQL un
se almacena en un documento que

325
00:14:40,090 --> 00:14:42,100
contiene la estructura jerárquica.

326
00:14:42,100 --> 00:14:45,670
Todos los datos que normalmente sería
unido para producir ese punto de vista

327
00:14:45,670 --> 00:14:47,160
se almacena en un único documento.

328
00:14:47,160 --> 00:14:50,990
Y hablaremos un poco acerca de
lo que funciona en un par de cartas.

329
00:14:50,990 --> 00:14:55,320
>> Pero la idea aquí es que usted almacena
tus datos mientras que estos puntos de vista instanciados.

330
00:14:55,320 --> 00:14:56,410
¿De acuerdo?

331
00:14:56,410 --> 00:14:58,610
Usted escalar horizontalmente.

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

333
00:14:59,556 --> 00:15:02,100
Si tengo que aumentar el
tamaño de mi grupo de NoSQL,

334
00:15:02,100 --> 00:15:03,700
No necesito conseguir una caja más grande.

335
00:15:03,700 --> 00:15:05,200
Tengo otra caja.

336
00:15:05,200 --> 00:15:07,700
Y yo Cluster las juntas,
y puedo fragmentar esos datos.

337
00:15:07,700 --> 00:15:10,780
Hablaremos un poco sobre
lo sharding es, para ser

338
00:15:10,780 --> 00:15:14,270
capaz de escalar esa base de datos
a través de múltiples dispositivos físicos

339
00:15:14,270 --> 00:15:18,370
y quitar la barrera que
me requiere para escalar verticalmente.

340
00:15:18,370 --> 00:15:22,080
>> Así que es realmente construido para en línea
procesamiento de transacciones y la escala.

341
00:15:22,080 --> 00:15:25,480
Hay una gran diferencia
aquí entre la información, ¿no?

342
00:15:25,480 --> 00:15:27,810
Informes, yo no sé la
preguntas voy a preguntar.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- si alguien de
mi departamento de marketing

345
00:15:30,570 --> 00:15:34,520
quiere solo-- cómo muchos de mis clientes
tener esta característica particular que

346
00:15:34,520 --> 00:15:37,850
comprado en este día-- No sé
lo consulta van a preguntar.

347
00:15:37,850 --> 00:15:39,160
Así que tengo que ser agnóstico.

348
00:15:39,160 --> 00:15:41,810
>> Ahora, en una línea
aplicación transaccional,

349
00:15:41,810 --> 00:15:43,820
Yo sé lo que estoy pidiendo preguntas.

350
00:15:43,820 --> 00:15:46,581
Construí la solicitud de
un flujo de trabajo muy específico.

351
00:15:46,581 --> 00:15:47,080
¿De acuerdo?

352
00:15:47,080 --> 00:15:50,540
Así que si puedo optimizar los datos
almacenar para apoyar ese flujo de trabajo,

353
00:15:50,540 --> 00:15:52,020
que va a ser más rápido.

354
00:15:52,020 --> 00:15:55,190
Y es por eso que NoSQL puede
realmente acelerar la entrega

355
00:15:55,190 --> 00:15:57,710
de esos tipos de servicios.

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

357
00:15:58,210 --> 00:16:00,501
>> Así que vamos a entrar en
un poco de la teoría aquí.

358
00:16:00,501 --> 00:16:03,330
Y algunos de ustedes, sus ojos
podría hacer retroceder un poco.

359
00:16:03,330 --> 00:16:06,936
Pero voy a tratar de mantenerlo
tan alto nivel como pueda.

360
00:16:06,936 --> 00:16:08,880
Así que si usted está en proyecto
gestión, hay

361
00:16:08,880 --> 00:16:12,280
un constructo llamado
triángulo de restricciones.

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

363
00:16:12,936 --> 00:16:16,060
El triángulo de Restringe dictados
no se puede tener todo, todo el tiempo.

364
00:16:16,060 --> 00:16:17,750
No puede tener su pastel y comérselo también.

365
00:16:17,750 --> 00:16:22,310
Así que en la gestión de proyectos, ese triángulo
limitaciones es que se puede tener barato,

366
00:16:22,310 --> 00:16:24,710
se puede tener rápido,
o se puede tener buena.

367
00:16:24,710 --> 00:16:25,716
Elige dos.

368
00:16:25,716 --> 00:16:27,090
Debido a que no se puede tener a los tres.

369
00:16:27,090 --> 00:16:27,460
¿Correcto?

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

371
00:16:27,820 --> 00:16:28,920
>> Así se enteró de esto mucho.

372
00:16:28,920 --> 00:16:31,253
Es una triple restricción,
triángulo de la triple restricción,

373
00:16:31,253 --> 00:16:34,420
o en el triángulo de hierro es oftentimes--
cuando hablas con los gerentes de proyecto,

374
00:16:34,420 --> 00:16:35,420
van a hablar de esto.

375
00:16:35,420 --> 00:16:37,640
Ahora, bases de datos tienen
su propio triángulo de hierro.

376
00:16:37,640 --> 00:16:40,350
Y el triángulo de hierro de los datos
es lo que llamamos teorema CAP.

377
00:16:40,350 --> 00:16:41,580
¿De acuerdo?

378
00:16:41,580 --> 00:16:43,770
>> Dictados teorema CAP
cómo funcionan las bases de datos

379
00:16:43,770 --> 00:16:45,627
bajo una condición muy específica.

380
00:16:45,627 --> 00:16:47,460
Y hablaremos de
lo que la condición es.

381
00:16:47,460 --> 00:16:52,221
Pero los tres puntos del triángulo,
por así decirlo, son C, la consistencia.

382
00:16:52,221 --> 00:16:52,720
¿De acuerdo?

383
00:16:52,720 --> 00:16:56,760
Así que en la PAC, la coherencia significa que todas
clientes que pueden acceder a la base de datos

384
00:16:56,760 --> 00:16:59,084
siempre tendrá un
vista consistente de los datos.

385
00:16:59,084 --> 00:17:00,750
Nadie va a ver dos cosas diferentes.

386
00:17:00,750 --> 00:17:01,480
¿De acuerdo?

387
00:17:01,480 --> 00:17:04,020
Si veo a la base de datos,
Estoy viendo la misma vista

388
00:17:04,020 --> 00:17:06,130
como mi compañero que ve
la misma base de datos.

389
00:17:06,130 --> 00:17:07,470
Esa es la consistencia.

390
00:17:07,470 --> 00:17:12,099
>> Disponibilidad significa que si el
base de datos en línea, si se puede llegar,

391
00:17:12,099 --> 00:17:14,760
que todos los clientes será siempre
ser capaz de leer y escribir.

392
00:17:14,760 --> 00:17:15,260
¿De acuerdo?

393
00:17:15,260 --> 00:17:17,010
Así que cada cliente que
puede leer la base de datos

394
00:17:17,010 --> 00:17:18,955
siempre será capaz de leer
datos de datos y escribir.

395
00:17:18,955 --> 00:17:21,819
Y si ese es el caso,
es un sistema disponible.

396
00:17:21,819 --> 00:17:24,230
>> Y el tercer punto es lo que
que llamamos tolerancia partición.

397
00:17:24,230 --> 00:17:24,730
¿De acuerdo?

398
00:17:24,730 --> 00:17:28,160
Medios de tolerancia de reparto
que el sistema funciona bien

399
00:17:28,160 --> 00:17:32,000
a pesar red física
particiones entre los nodos.

400
00:17:32,000 --> 00:17:32,760
¿De acuerdo?

401
00:17:32,760 --> 00:17:36,270
Así que los nodos del clúster no puede
hablar el uno al otro, ¿qué sucede?

402
00:17:36,270 --> 00:17:36,880
Correcto.

403
00:17:36,880 --> 00:17:39,545
>> Bases de datos relacionales Así choose--
usted puede escoger dos de ellos.

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

405
00:17:40,045 --> 00:17:43,680
Bases de datos relacionales Así que eligen
ser consistentes y disponibles.

406
00:17:43,680 --> 00:17:47,510
Si la partición ocurre entre
los DataNodes en el almacén de datos,

407
00:17:47,510 --> 00:17:48,831
la base de datos se bloquea.

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

409
00:17:49,330 --> 00:17:50,900
Simplemente va hacia abajo.

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

411
00:17:51,450 --> 00:17:54,230
>> Y es por eso que tienen
para crecer con las cajas más grandes.

412
00:17:54,230 --> 00:17:54,730
¿Correcto?

413
00:17:54,730 --> 00:17:58,021
Porque hay no-- lo general, un clúster
base de datos, no hay muchos de ellos

414
00:17:58,021 --> 00:17:59,590
que funcionan de esa manera.

415
00:17:59,590 --> 00:18:03,019
Pero la mayoría de las bases de datos de escala
verticalmente dentro de una sola caja.

416
00:18:03,019 --> 00:18:05,060
Debido a que tienen que ser
consistente y disponible.

417
00:18:05,060 --> 00:18:10,320
Si una partición iban a ser inyectado,
entonces usted tendría que tomar una decisión.

418
00:18:10,320 --> 00:18:13,720
Usted tiene que hacer una elección entre
ser coherente y disponible.

419
00:18:13,720 --> 00:18:16,080
>> Y eso es lo que las bases de datos NoSQL hacen.

420
00:18:16,080 --> 00:18:16,580
Correcto.

421
00:18:16,580 --> 00:18:20,950
Así que una base de datos NoSQL, se
viene en dos sabores.

422
00:18:20,950 --> 00:18:22,990
Nos tener-- bien,
viene en muchos sabores,

423
00:18:22,990 --> 00:18:26,140
pero viene con dos concepciones fundamentales
characteristics-- lo

424
00:18:26,140 --> 00:18:30,050
que llamaríamos base de datos de PC, o una
tolerancia consistente y partición

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

426
00:18:31,040 --> 00:18:34,930
Estos chicos tomar la decisión de que cuando
los nodos pierden contacto entre sí,

427
00:18:34,930 --> 00:18:37,091
no vamos a permitir que
gente escriba más.

428
00:18:37,091 --> 00:18:37,590
¿De acuerdo?

429
00:18:37,590 --> 00:18:41,855
>> Hasta que se elimina la partición,
se bloquea el acceso a escritura.

430
00:18:41,855 --> 00:18:43,230
Eso significa que no están disponibles.

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

432
00:18:44,510 --> 00:18:46,554
Cuando vemos que
partición inyectar sí mismo,

433
00:18:46,554 --> 00:18:48,470
ahora somos coherentes,
porque no vamos

434
00:18:48,470 --> 00:18:51,517
para permitir el cambio de datos en dos
lados de la partición de forma independiente

435
00:18:51,517 --> 00:18:52,100
el uno del otro.

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

437
00:18:54,130 --> 00:18:56,930
antes de cualquier actualización de
se deja que la de datos.

438
00:18:56,930 --> 00:18:58,120
¿De acuerdo?

439
00:18:58,120 --> 00:19:02,650
>> El siguiente sabor sería un sistema AP,
o un disponibles y se repartió

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

441
00:19:03,640 --> 00:19:05,320
Estos chicos no les importa.

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

443
00:19:06,020 --> 00:19:08,960
Cualquier nodo que recibe una
escribimos, lo tomaremos.

444
00:19:08,960 --> 00:19:11,480
Así que estoy replicando mis datos
a través de múltiples nodos.

445
00:19:11,480 --> 00:19:14,730
Estos nodos reciben un cliente, cliente viene
en, dice, voy a escribir algunos datos.

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

447
00:19:16,300 --> 00:19:18,580
El nodo junto a él consigue
una escritura en el mismo registro,

448
00:19:18,580 --> 00:19:20,405
él va a decir que no hay problema.

449
00:19:20,405 --> 00:19:23,030
En algún lugar de nuevo en la parte de atrás,
que los datos que va a replicar.

450
00:19:23,030 --> 00:19:27,360
Y entonces alguien va a realizar,
uh-oh, que el sistema se dará cuenta de, uh-oh,

451
00:19:27,360 --> 00:19:28,870
ha habido una actualización de dos lados.

452
00:19:28,870 --> 00:19:30,370
qué hacemos?

453
00:19:30,370 --> 00:19:33,210
Y lo que hacen es, entonces,
hacen algo que

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

455
00:19:36,080 --> 00:19:39,000
Y hablaremos de
que, en la siguiente tabla.

456
00:19:39,000 --> 00:19:40,000
>> Cosa a destacar aquí.

457
00:19:40,000 --> 00:19:42,374
Y yo no voy a ser demasiado
mucho en esto, porque este

458
00:19:42,374 --> 00:19:43,510
se mete en la teoría de los datos de profundidad.

459
00:19:43,510 --> 00:19:46,670
Pero hay una transaccional
marco que

460
00:19:46,670 --> 00:19:50,680
se ejecuta en un sistema relacional que
me permite hacer de forma segura las actualizaciones

461
00:19:50,680 --> 00:19:53,760
a múltiples entidades en la base de datos.

462
00:19:53,760 --> 00:19:58,320
Y esos cambios se producirán
todos a la vez o no en absoluto.

463
00:19:58,320 --> 00:20:00,500
Y esto se llama transacciones ACID.

464
00:20:00,500 --> 00:20:01,000
¿De acuerdo?

465
00:20:01,000 --> 00:20:06,570
>> ÁCIDO nos da la atomicidad, consistencia,
el aislamiento y la durabilidad.

466
00:20:06,570 --> 00:20:07,070
¿De acuerdo?

467
00:20:07,070 --> 00:20:13,550
Eso significa atómicas, transacciones, todo
mis actualizaciones o bien ocurren o no lo hacen.

468
00:20:13,550 --> 00:20:16,570
La consistencia significa que
la base de datos será siempre

469
00:20:16,570 --> 00:20:19,780
ser llevado a un constante
estado después de una actualización.

470
00:20:19,780 --> 00:20:23,900
Nunca voy a dejar la base de datos en un
mal estado después de aplicar una actualización.

471
00:20:23,900 --> 00:20:24,400
¿De acuerdo?

472
00:20:24,400 --> 00:20:26,720
>> Así que es un poco diferente
que la PAC consistencia.

473
00:20:26,720 --> 00:20:29,760
CAP consistencia significa toda mi
clientes siempre pueden ver los datos.

474
00:20:29,760 --> 00:20:34,450
Significa que cuando la consistencia ACID
una transacción ha hecho, de los datos buenos.

475
00:20:34,450 --> 00:20:35,709
Mis relaciones son todos buenos.

476
00:20:35,709 --> 00:20:38,750
Yo no voy a eliminar una fila padre
y dejar un montón de niños huérfanos

477
00:20:38,750 --> 00:20:40,970
en alguna otra tabla.

478
00:20:40,970 --> 00:20:44,320
No puede suceder si soy coherente
en una transacción de ácido.

479
00:20:44,320 --> 00:20:49,120
>> Aislamiento significa que las transacciones
siempre ocurrir uno después del otro.

480
00:20:49,120 --> 00:20:51,920
El resultado final de los datos
será el mismo estado

481
00:20:51,920 --> 00:20:54,770
como si esas transacciones
que se emitieron simultáneamente

482
00:20:54,770 --> 00:20:57,340
fueron ejecutados en serie.

483
00:20:57,340 --> 00:21:00,030
Así que es de concurrencia
control en la base de datos.

484
00:21:00,030 --> 00:21:04,130
Así que, básicamente, no puedo incrementar el
mismo valor dos veces con dos operaciones.

485
00:21:04,130 --> 00:21:08,580
>> Pero si digo añadir 1 a este valor,
y dos transacciones vienen en

486
00:21:08,580 --> 00:21:10,665
y tratar de hacerlo, una es
va a llegar primero

487
00:21:10,665 --> 00:21:12,540
y el otro de un solo
va a llegar después.

488
00:21:12,540 --> 00:21:15,210
Así que al final, he añadido dos.

489
00:21:15,210 --> 00:21:16,170
¿Ves lo que quiero decir?

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

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

492
00:21:19,220 --> 00:21:21,250
>> La durabilidad es bastante sencillo.

493
00:21:21,250 --> 00:21:23,460
Cuando la transacción
se reconoce, es

494
00:21:23,460 --> 00:21:26,100
va a estar allí, incluso
si el sistema se bloquea.

495
00:21:26,100 --> 00:21:29,230
Cuando ese sistema se recupera, que
transacción que se cometió

496
00:21:29,230 --> 00:21:30,480
es en realidad va a estar allí.

497
00:21:30,480 --> 00:21:33,130
Así que esa es la garantía
de transacciones ACID.

498
00:21:33,130 --> 00:21:35,470
Esas son muy buenas garantías
para tener a una base de datos,

499
00:21:35,470 --> 00:21:36,870
pero vienen en ese costo.

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

501
00:21:37,640 --> 00:21:40,520
>> Debido a que el problema
con este marco es

502
00:21:40,520 --> 00:21:44,540
si hay una partición de datos en el
conjunto, tengo que tomar una decisión.

503
00:21:44,540 --> 00:21:48,000
Voy a tener que permitir
actualizaciones de un lado o del otro.

504
00:21:48,000 --> 00:21:50,310
Y si eso sucede,
entonces yo ya no soy de ir

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

506
00:21:52,630 --> 00:21:53,960
No van a ser consistente.

507
00:21:53,960 --> 00:21:55,841
No van a ser aislados.

508
00:21:55,841 --> 00:21:58,090
Aquí es donde se rompe
para bases de datos relacionales.

509
00:21:58,090 --> 00:22:01,360
Esta es la razón relacional
bases de datos escalar verticalmente.

510
00:22:01,360 --> 00:22:05,530
>> Por otro lado, tenemos
lo que llama la tecnología BASE.

511
00:22:05,530 --> 00:22:07,291
Y estos son sus bases de datos NoSQL.

512
00:22:07,291 --> 00:22:07,790
Correcto.

513
00:22:07,790 --> 00:22:10,180
Así que tenemos nuestro CP, las bases de datos de AP.

514
00:22:10,180 --> 00:22:14,720
Y estos son lo que se llama básicamente
disponible, estado blando, finalmente

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

516
00:22:15,740 --> 00:22:16,420
¿De acuerdo?

517
00:22:16,420 --> 00:22:19,690
>> Básicamente disponible, porque
son tolerantes partición.

518
00:22:19,690 --> 00:22:21,470
Siempre serán
allí, incluso si hay

519
00:22:21,470 --> 00:22:23,053
una partición de red entre los nodos.

520
00:22:23,053 --> 00:22:25,900
Si puedo hablar con un nodo, estoy
va a ser capaz de leer datos.

521
00:22:25,900 --> 00:22:26,460
¿De acuerdo?

522
00:22:26,460 --> 00:22:30,810
No siempre podría ser capaz de escribir
datos si soy una plataforma consistente.

523
00:22:30,810 --> 00:22:32,130
Pero voy a ser capaz de leer los datos.

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

525
00:22:34,960 --> 00:22:38,010
>> El estado blando indica
que cuando leí que los datos,

526
00:22:38,010 --> 00:22:40,790
tal vez no sea el mismo que el resto de los nodos.

527
00:22:40,790 --> 00:22:43,390
Si el derecho se emitió en un nodo
en otro lugar en el clúster

528
00:22:43,390 --> 00:22:46,650
y no se ha replicado en todo el
racimo sin embargo, cuando leí que los datos,

529
00:22:46,650 --> 00:22:48,680
ese estado podría no ser consistente.

530
00:22:48,680 --> 00:22:51,650
Sin embargo, será
finalmente consistente,

531
00:22:51,650 --> 00:22:53,870
lo que significa que cuando una escritura
se hace al sistema,

532
00:22:53,870 --> 00:22:56,480
se replicará en todos los nodos.

533
00:22:56,480 --> 00:22:59,095
Y con el tiempo, ese estado
será puesto en orden,

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

535
00:23:00,890 --> 00:23:05,000
>> Ahora, CAP teorema realmente
juega sólo en una condición.

536
00:23:05,000 --> 00:23:08,700
Esa condición es cuando esto sucede.

537
00:23:08,700 --> 00:23:13,710
Debido a que cada vez se está operando en
modo normal, no hay ninguna partición,

538
00:23:13,710 --> 00:23:16,370
todo es coherente y disponible.

539
00:23:16,370 --> 00:23:19,990
Sólo se preocupe por la PAC
cuando tenemos esa partición.

540
00:23:19,990 --> 00:23:21,260
Así que estos son raros.

541
00:23:21,260 --> 00:23:25,360
Pero, ¿cómo reacciona el sistema cuando los
ocurren dictar qué tipo de sistema

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

543
00:23:26,750 --> 00:23:31,110
>> Así que echemos un vistazo a lo
que se ve como para los sistemas de AP.

544
00:23:31,110 --> 00:23:32,621
¿De acuerdo?

545
00:23:32,621 --> 00:23:34,830
Sistemas de AP son de dos tipos.

546
00:23:34,830 --> 00:23:38,514
Vienen en el sabor que es un
amo amo, 100%, siempre disponible.

547
00:23:38,514 --> 00:23:40,430
Y vienen en el
otro sabor, que dice:

548
00:23:40,430 --> 00:23:43,330
Sabes qué, yo me voy a preocupar
acerca de esta cosa de particionamiento

549
00:23:43,330 --> 00:23:44,724
cuando se produce una partición real.

550
00:23:44,724 --> 00:23:47,890
De lo contrario, no va a ser primaria
nodos que va a tomar los derechos.

551
00:23:47,890 --> 00:23:48,500
¿De acuerdo?

552
00:23:48,500 --> 00:23:50,040
>> Así que si tenemos algo así como Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra sería un maestro
maestra, vamos a escribir a cualquier nodo.

554
00:23:54,440 --> 00:23:55,540
¿Así que lo que ocurre?

555
00:23:55,540 --> 00:23:58,270
Así que tengo un objeto en el
base de datos que existe en dos nodos.

556
00:23:58,270 --> 00:24:01,705
Vamos a llamar a ese objeto S.
Así que tenemos el estado de S.

557
00:24:01,705 --> 00:24:04,312
Tenemos algunas operaciones
en S que están en curso.

558
00:24:04,312 --> 00:24:06,270
Cassandra me permite
escribir en varios nodos.

559
00:24:06,270 --> 00:24:08,550
Así que digamos que recibo una
escribir para s de dos nodos.

560
00:24:08,550 --> 00:24:12,274
Bueno, lo que termina sucediendo es
llamamos a que un evento de partición.

561
00:24:12,274 --> 00:24:14,190
Puede que no haya una
partición de red física.

562
00:24:14,190 --> 00:24:15,950
Pero debido al diseño
del sistema, es

563
00:24:15,950 --> 00:24:18,449
en realidad particionar tan pronto
como puedo obtener una escritura en dos nodos.

564
00:24:18,449 --> 00:24:20,830
No me está obligando a
escribir todo a través de un nodo.

565
00:24:20,830 --> 00:24:22,340
Estoy escribiendo en dos nodos.

566
00:24:22,340 --> 00:24:23,330
¿De acuerdo?

567
00:24:23,330 --> 00:24:25,740
>> Así que ahora tengo dos estados.

568
00:24:25,740 --> 00:24:26,360
¿De acuerdo?

569
00:24:26,360 --> 00:24:28,110
Qué va a pasar
es más pronto o más tarde,

570
00:24:28,110 --> 00:24:29,960
que va a ser un evento de replicación.

571
00:24:29,960 --> 00:24:33,300
No va a ser lo que
llamado recuperación de la partición, el cual

572
00:24:33,300 --> 00:24:35,200
es donde estos dos
estados vienen de nuevo juntos

573
00:24:35,200 --> 00:24:37,310
y no va a haber un algoritmo
que se ejecuta dentro de la base de datos,

574
00:24:37,310 --> 00:24:38,540
decide qué hacer.

575
00:24:38,540 --> 00:24:39,110
¿De acuerdo?

576
00:24:39,110 --> 00:24:43,057
Por defecto, última actualización
gana en la mayoría de los sistemas de AP.

577
00:24:43,057 --> 00:24:44,890
Así que por lo general hay una
algoritmo por defecto, lo que

578
00:24:44,890 --> 00:24:47,400
que ellos llaman una devolución de llamada
función, algo que

579
00:24:47,400 --> 00:24:51,000
será llamado cuando esta condición
se detecta para ejecutar alguna lógica

580
00:24:51,000 --> 00:24:52,900
para resolver ese conflicto.

581
00:24:52,900 --> 00:24:53,850
¿De acuerdo?

582
00:24:53,850 --> 00:24:58,770
La devolución de llamada por defecto y por defecto
resolver la mayoría de las bases de datos de AP en

583
00:24:58,770 --> 00:25:01,130
Es decir, ¿adivinen qué, marca de tiempo gana.

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

585
00:25:02,380 --> 00:25:04,320
Me voy a poner esa actualización en ese país.

586
00:25:04,320 --> 00:25:08,440
Puedo volcar este disco que me
objeto de dumping fuera en un registro de recuperación

587
00:25:08,440 --> 00:25:11,670
de modo que el usuario puede volver más tarde
y decir, bueno, hubo una colisión.

588
00:25:11,670 --> 00:25:12,320
¿Que pasó?

589
00:25:12,320 --> 00:25:16,370
Y en realidad se puede volcar un registro de
todas las colisiones y las reversiones

590
00:25:16,370 --> 00:25:17,550
y ver qué pasa.

591
00:25:17,550 --> 00:25:21,580
>> Ahora, como usuario, también puede
incluir lógica en esa devolución de llamada.

592
00:25:21,580 --> 00:25:24,290
Así que usted puede cambiar eso
operación de devolución de llamada.

593
00:25:24,290 --> 00:25:26,730
Se puede decir, bueno, yo quiero
para remediar estos datos.

594
00:25:26,730 --> 00:25:28,880
Y quiero tratar de
fusionar esos dos registros.

595
00:25:28,880 --> 00:25:30,050
Pero eso depende de ti.

596
00:25:30,050 --> 00:25:32,880
La base de datos no sabe cómo
hacerlo de forma predeterminada. La mayor parte del tiempo,

597
00:25:32,880 --> 00:25:34,850
lo único que la base de datos
sabe que hacer es decir,

598
00:25:34,850 --> 00:25:36,100
éste fue el último registro.

599
00:25:36,100 --> 00:25:39,183
Ese es el que va a ganar,
y ese es el valor que voy a poner.

600
00:25:39,183 --> 00:25:41,490
Una vez que la recuperación de la partición
y la replicación se produce,

601
00:25:41,490 --> 00:25:43,930
tenemos nuestro estado, que
ahora es el Primer, que es

602
00:25:43,930 --> 00:25:46,890
el estado de combinación de todos esos objetos.

603
00:25:46,890 --> 00:25:49,700
Así que los sistemas de AP tienen esto.

604
00:25:49,700 --> 00:25:51,615
Sistemas de CP no necesitan
que preocuparse por esto.

605
00:25:51,615 --> 00:25:54,490
Porque tan pronto como llega una partición
en juego, simplemente dejan de tomar

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

607
00:25:55,530 --> 00:25:56,180
¿De acuerdo?

608
00:25:56,180 --> 00:25:58,670
Así que eso es muy fácil
tratar de ser coherente

609
00:25:58,670 --> 00:26:01,330
cuando usted no acepta las actualizaciones.

610
00:26:01,330 --> 00:26:04,620
Eso es con los sistemas CP hacen.

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

612
00:26:05,120 --> 00:26:07,590
>> Así que vamos a hablar un poco
poco acerca de los patrones de acceso.

613
00:26:07,590 --> 00:26:11,580
Cuando hablamos de NoSQL, es
todo sobre el patrón de acceso.

614
00:26:11,580 --> 00:26:13,550
Ahora, SQL es ad hoc, las consultas.

615
00:26:13,550 --> 00:26:14,481
Es almacén relacional.

616
00:26:14,481 --> 00:26:16,480
No tenemos que preocuparnos
sobre el patrón de acceso.

617
00:26:16,480 --> 00:26:17,688
Escribo una consulta muy compleja.

618
00:26:17,688 --> 00:26:19,250
Se va y obtiene los datos.

619
00:26:19,250 --> 00:26:21,210
Eso es lo que esto se ve
como, la normalización.

620
00:26:21,210 --> 00:26:24,890
>> Así que en esta estructura particular,
estamos mirando un catálogo de productos.

621
00:26:24,890 --> 00:26:26,640
Tengo diferentes tipos de productos.

622
00:26:26,640 --> 00:26:27,217
Tengo libros.

623
00:26:27,217 --> 00:26:27,800
Tengo álbumes.

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

625
00:26:30,090 --> 00:26:33,370
La relación entre los productos
y cualquiera de estos libros, álbumes,

626
00:26:33,370 --> 00:26:34,860
y Vídeos de mesas es de 1: 1.

627
00:26:34,860 --> 00:26:35,800
¿Correcto?

628
00:26:35,800 --> 00:26:38,860
Tengo un identificador de producto,
y que corresponde identificación

629
00:26:38,860 --> 00:26:41,080
a un libro, un álbum o un vídeo.

630
00:26:41,080 --> 00:26:41,580
¿De acuerdo?

631
00:26:41,580 --> 00:26:44,350
Eso es una relación 1: 1
a través de esas mesas.

632
00:26:44,350 --> 00:26:46,970
>> Ahora, todo lo que books--
tener es las propiedades de la raíz.

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

634
00:26:47,550 --> 00:26:48,230
Eso es genial.

635
00:26:48,230 --> 00:26:52,130
Uno a uno, relación, me sale todo
los datos que necesita para describir ese libro.

636
00:26:52,130 --> 00:26:54,770
Álbumes Albums-- tienen pistas.

637
00:26:54,770 --> 00:26:56,470
Esto es lo que llamamos uno a muchos.

638
00:26:56,470 --> 00:26:58,905
Cada álbum podría tener muchas pistas.

639
00:26:58,905 --> 00:27:00,780
Así, por cada pista en
el álbum, que podría tener

640
00:27:00,780 --> 00:27:02,570
otro récord en esta tabla secundaria.

641
00:27:02,570 --> 00:27:04,680
Así que puedo crear un registro
en mi mesa de álbumes.

642
00:27:04,680 --> 00:27:06,700
Puedo crear varios registros
en la tabla de pistas.

643
00:27:06,700 --> 00:27:08,850
Uno-a-muchos relación.

644
00:27:08,850 --> 00:27:11,220
>> Esta relación es lo que
que llamamos de muchos a muchos.

645
00:27:11,220 --> 00:27:11,750
¿De acuerdo?

646
00:27:11,750 --> 00:27:17,000
Usted ve que los actores podrían ser
en muchas películas, muchos videos.

647
00:27:17,000 --> 00:27:21,450
Así que lo que hacemos es que ponemos este mapeo
mesa, entre los que sólo

648
00:27:21,450 --> 00:27:24,040
mapas de la ID de actor para el ID de vídeo.

649
00:27:24,040 --> 00:27:28,464
Ahora puedo crear una consulta de las uniones
videos a través actor de vídeo a los actores,

650
00:27:28,464 --> 00:27:31,130
y me da una buena lista de
todas las películas y todos los actores

651
00:27:31,130 --> 00:27:32,420
que estaban en esa película.

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

653
00:27:33,290 --> 00:27:33,880
Así que, aquí vamos.

654
00:27:33,880 --> 00:27:38,040
Uno-a-uno es el de nivel superior
relación; uno-a-muchos,

655
00:27:38,040 --> 00:27:40,240
álbumes a las pistas; muchos a muchos.

656
00:27:40,240 --> 00:27:44,990
Esos son los tres de nivel superior
relaciones en cualquier base de datos.

657
00:27:44,990 --> 00:27:48,050
Si usted sabe cómo los
relaciones trabajan juntos,

658
00:27:48,050 --> 00:27:51,490
entonces usted sabe mucho
sobre la base de datos ya.

659
00:27:51,490 --> 00:27:55,660
Así NoSQL funciona un poco diferente.

660
00:27:55,660 --> 00:27:58,930
Pensemos por un segundo lo que
parece que ir a buscar todos mis productos.

661
00:27:58,930 --> 00:28:01,096
>> En un almacén relacional, yo
que desee obtener todos mis productos

662
00:28:01,096 --> 00:28:02,970
en una lista de todos mis productos.

663
00:28:02,970 --> 00:28:04,910
Eso es un montón de preguntas.

664
00:28:04,910 --> 00:28:07,030
Tengo una consulta para todos mis libros.

665
00:28:07,030 --> 00:28:08,470
Tengo una pregunta de mis discos.

666
00:28:08,470 --> 00:28:09,970
Y tengo una consulta para todos mis videos.

667
00:28:09,970 --> 00:28:11,719
Y tengo que decirlo
todos juntos en una lista

668
00:28:11,719 --> 00:28:15,250
y servir de nuevo hasta la
aplicación que se soliciten.

669
00:28:15,250 --> 00:28:18,000
>> Para conseguir mis libros, me uno a
Productos y Libros.

670
00:28:18,000 --> 00:28:21,680
Para obtener mis álbumes, llegué a unirse
Productos, álbumes y canciones.

671
00:28:21,680 --> 00:28:25,330
Y para conseguir mis videos, tengo
para unirse a los productos a los vídeos,

672
00:28:25,330 --> 00:28:28,890
unirse a través Actor Videos,
y traer a los actores.

673
00:28:28,890 --> 00:28:31,020
Así que eso es tres consultas.

674
00:28:31,020 --> 00:28:34,560
Consultas muy complejas a
ensamblar un conjunto de resultados.

675
00:28:34,560 --> 00:28:36,540
>> Eso es menos que óptimo.

676
00:28:36,540 --> 00:28:39,200
Por eso, cuando hablamos
sobre una estructura de datos que es

677
00:28:39,200 --> 00:28:42,900
construido para ser agnóstico al acceso
pattern-- bien eso es genial.

678
00:28:42,900 --> 00:28:45,730
Y se puede ver que esto es realmente
agradable cómo hemos organizado los datos.

679
00:28:45,730 --> 00:28:46,550
¿Y sabes qué?

680
00:28:46,550 --> 00:28:49,750
Sólo tengo un récord para un actor.

681
00:28:49,750 --> 00:28:50,440
>> Eso es genial.

682
00:28:50,440 --> 00:28:53,750
He deduplicado todos mis actores,
y mantuve mis asociaciones

683
00:28:53,750 --> 00:28:55,200
en esta tabla de asignaciones.

684
00:28:55,200 --> 00:29:00,620
Sin embargo, obtener los datos
fuera se convierte en caro.

685
00:29:00,620 --> 00:29:04,500
Estoy enviando la CPU en todo el sistema
unirse a estas estructuras de datos junto

686
00:29:04,500 --> 00:29:05,950
ser capaz de tirar que volver datos.

687
00:29:05,950 --> 00:29:07,310
>> Entonces, ¿cómo hago para que todo eso?

688
00:29:07,310 --> 00:29:11,200
En NoSQL se trata
agregación, no normalización.

689
00:29:11,200 --> 00:29:13,534
Por eso queremos decir que queremos
apoyar el patrón de acceso.

690
00:29:13,534 --> 00:29:15,283
Si el patrón de acceso
a las aplicaciones,

691
00:29:15,283 --> 00:29:16,770
Tengo que conseguir todos mis productos.

692
00:29:16,770 --> 00:29:19,027
Vamos a poner todos los productos en una sola mesa.

693
00:29:19,027 --> 00:29:22,110
Si pongo todos los productos en una tabla,
Yo sólo puedo seleccionar todos los productos

694
00:29:22,110 --> 00:29:23,850
de esa mesa y me sale todo.

695
00:29:23,850 --> 00:29:25,240
Bueno, ¿cómo lo hago?

696
00:29:25,240 --> 00:29:28,124
Bueno, en NoSQL no hay
estructura a la mesa.

697
00:29:28,124 --> 00:29:30,540
Hablaremos un poco sobre
cómo funciona esto en Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Pero usted no tiene el mismo
atributos y las mismas propiedades

699
00:29:33,570 --> 00:29:37,751
en cada hilera, en cada
tema, como lo hace en una tabla de SQL.

700
00:29:37,751 --> 00:29:39,750
Y lo que esto me permite
que hacer un montón de cosas

701
00:29:39,750 --> 00:29:41,124
y me da mucha flexibilidad.

702
00:29:41,124 --> 00:29:45,360
En este caso particular,
tener mis documentos de productos.

703
00:29:45,360 --> 00:29:49,090
Y en este particular,
ejemplo, todo

704
00:29:49,090 --> 00:29:51,930
es un documento en la tabla Productos.

705
00:29:51,930 --> 00:29:56,510
Y el producto de un libro puede
tener un ID de tipo que especifica un libro.

706
00:29:56,510 --> 00:29:59,180
Y la aplicación
cambiaría en ese ID.

707
00:29:59,180 --> 00:30:02,570
>> En el nivel de aplicación, voy
para decir ¡oh, qué tipo de registro es esto?

708
00:30:02,570 --> 00:30:04,100
Oh, es un registro de libros.

709
00:30:04,100 --> 00:30:05,990
Registros de la Libreta tienen estas propiedades.

710
00:30:05,990 --> 00:30:08,100
Déjame crear un objeto de libro.

711
00:30:08,100 --> 00:30:11,289
Así que me voy a llenar el
libro objeto con este concepto.

712
00:30:11,289 --> 00:30:13,080
Siguiente artículo viene y
dice, ¿qué es este artículo?

713
00:30:13,080 --> 00:30:14,560
Bueno, este artículo es un álbum.

714
00:30:14,560 --> 00:30:17,340
Oh, tengo toda una diferente
rutina de procesamiento para que,

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

716
00:30:18,487 --> 00:30:19,320
¿Ves lo que quiero decir?

717
00:30:19,320 --> 00:30:21,950
>> Así que la aplicación tier-- I
sólo tienes que seleccionar todos estos registros.

718
00:30:21,950 --> 00:30:23,200
Todos empiezan a entrar.

719
00:30:23,200 --> 00:30:24,680
Podrían ser todos los tipos diferentes.

720
00:30:24,680 --> 00:30:27,590
Y es la lógica de la aplicación
que los conmutadores a través de esos tipos

721
00:30:27,590 --> 00:30:29,530
y decide cómo procesar ellos.

722
00:30:29,530 --> 00:30:33,640
>> Una vez más, por lo que estamos optimizando el
esquema para el esquema de acceso.

723
00:30:33,640 --> 00:30:36,390
Lo estamos haciendo por
colapso esas mesas.

724
00:30:36,390 --> 00:30:39,670
Básicamente estamos tomando
estas estructuras normalizadas,

725
00:30:39,670 --> 00:30:42,000
y estamos construyendo
estructuras jerárquicas.

726
00:30:42,000 --> 00:30:45,130
Dentro de cada uno de estos registros
Voy a ver propiedades de la matriz.

727
00:30:45,130 --> 00:30:49,400
>> Dentro de este documento para los álbumes,
Estoy viendo series de pistas.

728
00:30:49,400 --> 00:30:53,900
Esas pistas ahora become-- es
básicamente esta tabla secundaria que

729
00:30:53,900 --> 00:30:56,520
existe aquí mismo en esta estructura.

730
00:30:56,520 --> 00:30:57,975
Así que usted puede hacer esto en DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Usted puede hacer esto en MongoDB.

732
00:30:59,810 --> 00:31:01,437
Usted puede hacer esto en cualquier base de datos NoSQL.

733
00:31:01,437 --> 00:31:03,520
Crear este tipo de
estructuras de datos jerárquicas

734
00:31:03,520 --> 00:31:07,120
que le permiten recuperar datos
muy rápidamente porque ahora

735
00:31:07,120 --> 00:31:08,537
no tienen que conformarse.

736
00:31:08,537 --> 00:31:11,620
Al insertar una fila en las Pistas
mesa, o una fila en la tabla Álbumes,

737
00:31:11,620 --> 00:31:13,110
Tengo que cumplir con ese esquema.

738
00:31:13,110 --> 00:31:18,060
Tengo que tener el atributo o la
propiedad que se define en esa mesa.

739
00:31:18,060 --> 00:31:20,480
Cada uno de ellos,
cuando inserto esa fila.

740
00:31:20,480 --> 00:31:21,910
Ese no es el caso en el NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Puedo tener totalmente diferente
propiedades en todos los documentos

742
00:31:24,440 --> 00:31:26,100
que inserto en la colección.

743
00:31:26,100 --> 00:31:30,480
Así mecanismo muy poderoso.

744
00:31:30,480 --> 00:31:32,852
Y es realmente cómo
optimizar el sistema.

745
00:31:32,852 --> 00:31:35,310
Porque ahora esa consulta, en lugar
de unirse a todas estas tablas

746
00:31:35,310 --> 00:31:39,160
y la ejecución de una media docena de consultas
a retirar los datos que necesito,

747
00:31:39,160 --> 00:31:40,890
Estoy ejecutando una consulta.

748
00:31:40,890 --> 00:31:43,010
Y estoy iteración
a través de los conjunto de resultados.

749
00:31:43,010 --> 00:31:46,512
que te da una idea
del poder de NoSQL.

750
00:31:46,512 --> 00:31:49,470
Voy a clase de ir de lado aquí
y hablar un poco acerca de esto.

751
00:31:49,470 --> 00:31:53,240
Esto es más clase de la
comercialización o la tecnología, como

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

753
00:31:55,660 --> 00:31:58,672
Pero es importante entender
porque si nos fijamos en la parte superior

754
00:31:58,672 --> 00:32:00,380
aquí en esta tabla,
lo que estamos viendo

755
00:32:00,380 --> 00:32:04,030
es lo que llamamos el
curva bombo tecnología.

756
00:32:04,030 --> 00:32:06,121
Y lo que esto significa es
cosas nuevas entra en juego.

757
00:32:06,121 --> 00:32:07,120
La gente piensa que es genial.

758
00:32:07,120 --> 00:32:09,200
He resuelto todos mis problemas.

759
00:32:09,200 --> 00:32:11,630
>> Este podría ser el fin
todo, ser todo para todo.

760
00:32:11,630 --> 00:32:12,790
Y comienzan a usarlo.

761
00:32:12,790 --> 00:32:14,720
Y dicen, esto no funciona.

762
00:32:14,720 --> 00:32:17,600
Esto no esta bien.

763
00:32:17,600 --> 00:32:19,105
El material viejo era mejor.

764
00:32:19,105 --> 00:32:21,230
Y vuelven a hacer
las cosas como estaban.

765
00:32:21,230 --> 00:32:22,730
Y luego, finalmente,
que vayan, ¿sabes qué?

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

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

768
00:32:26,192 --> 00:32:28,900
Y una vez que averiguar cómo
obras, empiezan a mejorar.

769
00:32:28,900 --> 00:32:32,050
>> Y lo curioso al respecto
es, que tipo de líneas hasta qué

770
00:32:32,050 --> 00:32:34,300
que llamamos la curva de adopción de tecnología.

771
00:32:34,300 --> 00:32:36,910
Así que lo que pasa es que tenemos
algunos gatillo tecnología tipo.

772
00:32:36,910 --> 00:32:39,100
En el caso de bases de datos,
que es la presión de datos.

773
00:32:39,100 --> 00:32:42,200
Hablamos de los puntos altos de agua
de la presión de los datos a través del tiempo.

774
00:32:42,200 --> 00:32:46,310
Cuando la presión que realiza un cierto datos
punto, que es un disparador tecnología.

775
00:32:46,310 --> 00:32:47,830
>> Se está haciendo demasiado caro.

776
00:32:47,830 --> 00:32:49,790
Se tarda demasiado tiempo para procesar los datos.

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

778
00:32:50,890 --> 00:32:52,890
Usted obtiene los innovadores
por ahí dando vueltas,

779
00:32:52,890 --> 00:32:55,050
tratando de averiguar cuál es la solución.

780
00:32:55,050 --> 00:32:56,050
¿Cuál es la nueva idea?

781
00:32:56,050 --> 00:32:58,170
>> ¿Cuál es la mejor alternativa
manera de hacer esto?

782
00:32:58,170 --> 00:32:59,530
Y vienen con algo.

783
00:32:59,530 --> 00:33:03,140
Y la gente, el verdadero dolor,
los chicos de la punta de lanza,

784
00:33:03,140 --> 00:33:06,390
que van a saltar por todas partes,
porque necesitan una respuesta.

785
00:33:06,390 --> 00:33:09,690
Ahora lo que inevitablemente happens-- y
está sucediendo ahora mismo en NoSQL.

786
00:33:09,690 --> 00:33:11,090
Lo veo todo el tiempo.

787
00:33:11,090 --> 00:33:13,610
>> Lo que pasa, inevitablemente, es
la gente comienza a usar la nueva herramienta

788
00:33:13,610 --> 00:33:15,490
de la misma manera que utiliza la herramienta de edad.

789
00:33:15,490 --> 00:33:17,854
Y se dan cuenta de que
no funciona tan bien.

790
00:33:17,854 --> 00:33:20,020
No puedo recordar quién era yo
hablando con el día de hoy.

791
00:33:20,020 --> 00:33:22,080
Pero es como, cuando el
martillo neumático fue inventado,

792
00:33:22,080 --> 00:33:24,621
la gente no swing más
su cabeza para romper el hormigón.

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

794
00:33:27,360 --> 00:33:30,610
>> Pero eso es lo que hay
pasando con NoSQL hoy.

795
00:33:30,610 --> 00:33:33,900
Si entras en la mayoría de tiendas,
que están tratando de ser tiendas NoSQL.

796
00:33:33,900 --> 00:33:36,510
Lo que están haciendo es
que están usando NoSQL,

797
00:33:36,510 --> 00:33:39,900
y están cargarlo
llena de esquema relacional.

798
00:33:39,900 --> 00:33:41,630
Porque así es como
diseñar bases de datos.

799
00:33:41,630 --> 00:33:44,046
Y están preguntando, ¿por qué es
no llevar a cabo muy bien?

800
00:33:44,046 --> 00:33:45,230
Chico, esto apesta.

801
00:33:45,230 --> 00:33:49,900
Tuve que mantener todo mi
une en-- es como, no, no.

802
00:33:49,900 --> 00:33:50,800
Mantener une?

803
00:33:50,800 --> 00:33:52,430
¿Por qué están uniendo a los datos?

804
00:33:52,430 --> 00:33:54,350
Usted no se inscribe datos NoSQL.

805
00:33:54,350 --> 00:33:55,850
Usted agregada ella.

806
00:33:55,850 --> 00:34:00,690
>> Así que si quieres evitar esto, aprender
cómo funciona la herramienta antes de que realmente

807
00:34:00,690 --> 00:34:02,010
empezar a usarlo.

808
00:34:02,010 --> 00:34:04,860
No tratar de utilizar las nuevas herramientas de la
misma manera que utilizó las viejas herramientas.

809
00:34:04,860 --> 00:34:06,500
Vas a tener una mala experiencia.

810
00:34:06,500 --> 00:34:08,848
Y cada vez
eso es lo que se trata.

811
00:34:08,848 --> 00:34:11,389
Cuando empezamos a venir aquí,
es porque la gente descubierto

812
00:34:11,389 --> 00:34:13,449
cómo usar las herramientas.

813
00:34:13,449 --> 00:34:16,250
>> Ellos hicieron lo mismo cuando
bases de datos relacionales se inventaron,

814
00:34:16,250 --> 00:34:17,969
y fueron reemplazando a los sistemas de archivos.

815
00:34:17,969 --> 00:34:20,420
Trataron de crear sistemas de archivos
con bases de datos relacionales

816
00:34:20,420 --> 00:34:22,159
porque eso es lo entienden las personas.

817
00:34:22,159 --> 00:34:23,049
No funcionó.

818
00:34:23,049 --> 00:34:26,090
Así que la comprensión de las mejores prácticas
de la tecnología que está trabajando

819
00:34:26,090 --> 00:34:26,730
es enorme.

820
00:34:26,730 --> 00:34:29,870
Muy importante.

821
00:34:29,870 --> 00:34:32,440
>> Así que vamos a entrar en DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB es de AWS
totalmente gestionados plataforma NoSQL.

823
00:34:36,480 --> 00:34:37,719
¿Qué significa gestionados totalmente significa?

824
00:34:37,719 --> 00:34:40,010
Esto significa que no es necesario
realmente preocuparse de nada.

825
00:34:40,010 --> 00:34:42,060
>> Entras, le dices
nosotros, que necesitamos una mesa.

826
00:34:42,060 --> 00:34:43,409
Se necesita tanta capacidad.

827
00:34:43,409 --> 00:34:47,300
Se pulsa el botón, y la provisión que
toda la infraestructura detrás de la escena.

828
00:34:47,300 --> 00:34:48,310
Ahora que es enorme.

829
00:34:48,310 --> 00:34:51,310
>> Porque cuando hablas
acerca de la expansión de una base de datos,

830
00:34:51,310 --> 00:34:53,917
Clústeres de datos NoSQL en
escala, petabytes de funcionamiento,

831
00:34:53,917 --> 00:34:55,750
corriendo millones de
transacciones por segundo,

832
00:34:55,750 --> 00:34:58,180
estas cosas no son pequeños racimos.

833
00:34:58,180 --> 00:35:00,830
Estamos hablando de miles de casos.

834
00:35:00,830 --> 00:35:04,480
La gestión de miles de casos,
incluso instancias virtuales,

835
00:35:04,480 --> 00:35:06,350
es un verdadero dolor en el trasero.

836
00:35:06,350 --> 00:35:09,110
Quiero decir, pienso cada vez que un
parche de sistema operativo sale

837
00:35:09,110 --> 00:35:11,552
o una nueva versión de la base de datos.

838
00:35:11,552 --> 00:35:13,260
Qué significa eso
a usted operacionalmente?

839
00:35:13,260 --> 00:35:16,330
Eso significa que tienes 1200
servidores que necesitan ser actualizados.

840
00:35:16,330 --> 00:35:18,960
Ahora, incluso con la automatización,
que puede llevar mucho tiempo.

841
00:35:18,960 --> 00:35:21,480
Eso puede causar una gran cantidad de
dolores de cabeza operacionales,

842
00:35:21,480 --> 00:35:23,090
porque voy a tener servicios de abajo.

843
00:35:23,090 --> 00:35:26,070
>> Como puedo actualizar estas bases de datos, que
podría hacer despliegues verde azul

844
00:35:26,070 --> 00:35:29,420
donde puedo implementar y actualizar la mitad de mi
nodos y, a continuación, actualizar la otra mitad.

845
00:35:29,420 --> 00:35:30,490
Tome los abajo.

846
00:35:30,490 --> 00:35:33,410
Por lo tanto la gestión de la infraestructura
escala es enormemente doloroso.

847
00:35:33,410 --> 00:35:36,210
Y AWS tomar que el dolor fuera de él.

848
00:35:36,210 --> 00:35:39,210
Y las bases de datos NoSQL puede
ser extraordinariamente dolorosa

849
00:35:39,210 --> 00:35:41,780
debido a la manera en que la escala.

850
00:35:41,780 --> 00:35:42,926
>> Escala horizontal.

851
00:35:42,926 --> 00:35:45,550
Si usted desea conseguir un NoSQL grande
base de datos, usted compra más nodos.

852
00:35:45,550 --> 00:35:48,660
Cada nodo que usted compra es
otro dolor de cabeza operativa.

853
00:35:48,660 --> 00:35:50,830
Así que deje que alguien más lo haga por usted.

854
00:35:50,830 --> 00:35:52,000
AWS puede hacer eso.

855
00:35:52,000 --> 00:35:54,587
>> Apoyamos valores clave documento.

856
00:35:54,587 --> 00:35:56,670
Ahora no fuimos demasiado
en en el otro gráfico.

857
00:35:56,670 --> 00:35:58,750
Hay un montón de diferentes
sabores de NoSQL.

858
00:35:58,750 --> 00:36:02,670
Son todo tipo de conseguir
munged juntos en este punto.

859
00:36:02,670 --> 00:36:06,260
Usted puede mirar en DynamoDB y decir que sí,
los dos somos un documento y un valor clave

860
00:36:06,260 --> 00:36:08,412
almacenar este punto.

861
00:36:08,412 --> 00:36:10,620
Y usted puede discutir las características
de uno sobre el otro.

862
00:36:10,620 --> 00:36:13,950
Para mí, mucho de esto es realmente de seis
de la mitad de una docena de los otros.

863
00:36:13,950 --> 00:36:18,710
Cada una de estas tecnologías es una
tecnología fina y una multa solución.

864
00:36:18,710 --> 00:36:23,390
Yo no diría que MongoDB es mejor o
peor que Couch, a continuación, Cassandra,

865
00:36:23,390 --> 00:36:25,994
entonces Dynamo, o viceversa.

866
00:36:25,994 --> 00:36:27,285
Quiero decir, estos son sólo opciones.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Es rápido y es
consistente en cualquier escala.

869
00:36:32,700 --> 00:36:36,210
Así que este es uno de los más grandes
bonificaciones que reciben con AWS.

870
00:36:36,210 --> 00:36:40,850
Con DynamoDB es la capacidad
para obtener un solo dígito bajo

871
00:36:40,850 --> 00:36:44,040
latencia de milisegundos a cualquier escala.

872
00:36:44,040 --> 00:36:45,720
Ese fue un objetivo de diseño del sistema.

873
00:36:45,720 --> 00:36:49,130
Y tenemos clientes que están haciendo
millones de transacciones por segundo.

874
00:36:49,130 --> 00:36:52,670
>> Ahora voy a ir a través de algunos de los
casos de uso en pocos minutos aquí.

875
00:36:52,670 --> 00:36:55,660
Control-- acceso integrado
tenemos lo que llamamos

876
00:36:55,660 --> 00:36:57,920
Identidad Access Management o IAM.

877
00:36:57,920 --> 00:37:01,980
Impregna todo sistema,
todos los servicios que ofrece AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB no es una excepción.

879
00:37:03,630 --> 00:37:06,020
Puede controlar el acceso
a las tablas DynamoDB.

880
00:37:06,020 --> 00:37:09,960
A través de todas sus cuentas de AWS
definición de funciones de acceso y permisos

881
00:37:09,960 --> 00:37:12,140
en la infraestructura de IAM.

882
00:37:12,140 --> 00:37:16,630
>> Y es un componente esencial en el
lo que llamamos Evento Programación Driven.

883
00:37:16,630 --> 00:37:19,056
Ahora bien, este es un nuevo paradigma.

884
00:37:19,056 --> 00:37:22,080
>> AUDIENCIA: ¿Cómo es su tasa de verdad
positivos frente a falsos negativos

885
00:37:22,080 --> 00:37:24,052
en su sistema de control de acceso?

886
00:37:24,052 --> 00:37:26,260
RICK HOULIHAN: Los verdaderos positivos
frente a falsos negativos?

887
00:37:26,260 --> 00:37:28,785
AUDIENCIA: Volviendo lo
usted debe devolver?

888
00:37:28,785 --> 00:37:33,720
A diferencia de vez en cuando
no devuelve cuando debería validar?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK HOULIHAN: No le podía decir eso.

891
00:37:38,050 --> 00:37:40,140
Si hay cualquier fallo
alguno en que,

892
00:37:40,140 --> 00:37:42,726
No soy la persona para preguntar
esa pregunta en particular.

893
00:37:42,726 --> 00:37:43,850
Pero eso es una buena pregunta.

894
00:37:43,850 --> 00:37:45,905
Sería curioso saber
que yo, en realidad.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> Y así, de nuevo, nuevo paradigma
es la programación orientada a eventos.

897
00:37:51,320 --> 00:37:55,160
Esta es la idea que pueda
implementar aplicaciones complejas que

898
00:37:55,160 --> 00:37:59,720
puede operar una muy alta escala muy
sin cualquier infraestructura de ningún tipo.

899
00:37:59,720 --> 00:38:02,120
Sin ningún tipo fijo
infraestructura alguna.

900
00:38:02,120 --> 00:38:04,720
Y hablaremos un poco
acerca de lo que eso significa, ya que

901
00:38:04,720 --> 00:38:06,550
llegar a la siguiente par de cartas.

902
00:38:06,550 --> 00:38:08,716
>> Lo primero que vamos a hacer
es hablaremos de tablas.

903
00:38:08,716 --> 00:38:10,857
Tipos de datos API para Dynamo.

904
00:38:10,857 --> 00:38:13,190
Y la primera cosa que usted
cuenta cuando nos fijamos en esto,

905
00:38:13,190 --> 00:38:17,930
si está familiarizado con cualquier base de datos,
bases de datos tienen realmente dos tipos de APIs

906
00:38:17,930 --> 00:38:18,430
Yo lo llamaría.

907
00:38:18,430 --> 00:38:21,570
O dos conjuntos de API.

908
00:38:21,570 --> 00:38:23,840
Uno de ellos sería
API administrativa.

909
00:38:23,840 --> 00:38:26,710
>> Las cosas que se ocupan de
las funciones de la base de datos.

910
00:38:26,710 --> 00:38:31,340
Configuración del motor de almacenamiento,
la configuración y la adición de tablas.

911
00:38:31,340 --> 00:38:35,180
base de datos de creación
catálogos e instancias.

912
00:38:35,180 --> 00:38:40,450
Estos cosas-- en DynamoDB, que
tienen muy cortos, listas cortas.

913
00:38:40,450 --> 00:38:43,120
>> Así que en otras bases de datos,
usted puede ver a decenas

914
00:38:43,120 --> 00:38:45,680
de comandos, de administrativo
comandos, para configurar

915
00:38:45,680 --> 00:38:47,290
estas opciones adicionales.

916
00:38:47,290 --> 00:38:51,234
En DynamoDB que no es necesario porque los
no configura el sistema, lo que hacemos.

917
00:38:51,234 --> 00:38:54,150
Así que lo único que tiene que hacer es
dime qué tamaño de la tabla Qué necesito.

918
00:38:54,150 --> 00:38:55,660
Así se obtiene una muy
conjunto limitado de comandos.

919
00:38:55,660 --> 00:38:58,618
>> Usted recibe un CREATE TABLE actualización, Mesa,
Eliminar la tabla, y describir la tabla.

920
00:38:58,618 --> 00:39:01,150
Esas son las únicas cosas
lo que necesitas para DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Usted no necesita un almacenamiento
configuración del motor.

922
00:39:03,294 --> 00:39:04,960
No necesito que preocuparse acerca de la replicación.

923
00:39:04,960 --> 00:39:06,490
No necesito que preocuparse sharding.

924
00:39:06,490 --> 00:39:07,800
>> No necesito que preocuparse
acerca de cualquiera de estas cosas.

925
00:39:07,800 --> 00:39:08,740
Lo hacemos todo por usted.

926
00:39:08,740 --> 00:39:11,867
Así que eso es una gran cantidad de sobrecarga
eso es sólo levantó su plato.

927
00:39:11,867 --> 00:39:13,200
Luego tenemos los operadores CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD es algo de lo que
llamar a la base de datos que es

929
00:39:17,740 --> 00:39:19,860
Crear, actualizar, eliminar operadores.

930
00:39:19,860 --> 00:39:24,180
Estos son el común
las operaciones de base de datos.

931
00:39:24,180 --> 00:39:31,299
Cosas como punto de venta, consigue el artículo, actualización
elementos, eliminar elementos, consulta por lotes, escanear.

932
00:39:31,299 --> 00:39:32,840
Si desea escanear toda la tabla.

933
00:39:32,840 --> 00:39:34,220
Tire todo lo de la mesa.

934
00:39:34,220 --> 00:39:37,130
Una de las cosas buenas de DynamoDB
es que permite el escaneo paralelo.

935
00:39:37,130 --> 00:39:40,602
Así que en realidad se puede hacerme saber cuántos
hilos desea ejecutar en esa exploración.

936
00:39:40,602 --> 00:39:41,810
Y podemos ejecutar esos hilos.

937
00:39:41,810 --> 00:39:43,985
Podemos girar que mira para arriba
a través de múltiples hilos

938
00:39:43,985 --> 00:39:49,060
así que usted puede escanear toda la tabla
espacio muy, muy rápidamente en DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> La otra API que tenemos es
lo que llamamos nuestra API Arroyos.

940
00:39:51,490 --> 00:39:52,940
No vamos a hablar demasiado
mucho de esto ahora.

941
00:39:52,940 --> 00:39:55,189
Tengo algo de contenido más tarde
en la baraja sobre esto.

942
00:39:55,189 --> 00:39:59,910
Pero Streams es realmente un running--
pensar en él como el tiempo ordenó

943
00:39:59,910 --> 00:40:01,274
y registro de cambios de particiones.

944
00:40:01,274 --> 00:40:03,940
Todo lo que está sucediendo en
la tabla se muestra en la secuencia.

945
00:40:03,940 --> 00:40:05,940
>> Cada escritura en la tabla
aparece en la corriente.

946
00:40:05,940 --> 00:40:08,370
Usted puede leer esa corriente, y
se pueden hacer cosas con él.

947
00:40:08,370 --> 00:40:10,150
Vamos a hablar de lo que
tipos de cosas que usted

948
00:40:10,150 --> 00:40:13,680
ver con las cosas como la replicación,
la creación de índices secundarios.

949
00:40:13,680 --> 00:40:17,620
Todo tipo de genial
cosas que puedes hacer con eso.

950
00:40:17,620 --> 00:40:19,150
>> Tipos de datos.

951
00:40:19,150 --> 00:40:23,320
En DynamoDB, apoyamos tanto clave
de valor y datos de documentos tipos.

952
00:40:23,320 --> 00:40:26,350
En el lado izquierdo de la pantalla
aquí, tenemos nuestros tipos básicos.

953
00:40:26,350 --> 00:40:27,230
Tipos de valor clave.

954
00:40:27,230 --> 00:40:30,040
Estos son cadenas,
números y los binarios.

955
00:40:30,040 --> 00:40:31,640
>> Así que sólo tres tipos básicos.

956
00:40:31,640 --> 00:40:33,700
Y entonces usted puede tener conjuntos de esos.

957
00:40:33,700 --> 00:40:37,650
Una de las cosas buenas de NoSQL es
puede contener matrices como propiedades.

958
00:40:37,650 --> 00:40:42,050
Y con DynamoDB puede contener matrices
de tipos básicos como una propiedad raíz.

959
00:40:42,050 --> 00:40:43,885
>> Y luego están los tipos de documentos.

960
00:40:43,885 --> 00:40:45,510
¿Cuántas personas están familiarizados con JSON?

961
00:40:45,510 --> 00:40:47,130
Ustedes están familiarizados con JSON tanto?

962
00:40:47,130 --> 00:40:49,380
Se trata básicamente de JavaScript,
Objeto, notación.

963
00:40:49,380 --> 00:40:52,510
Le permite, básicamente,
definir una estructura jerárquica.

964
00:40:52,510 --> 00:40:58,107
>> Puede guardar un documento en JSON
DynamoDB usando componentes comunes

965
00:40:58,107 --> 00:41:00,940
o bloques de construcción que están disponibles
en la mayoría de los lenguajes de programación.

966
00:41:00,940 --> 00:41:03,602
Así que si usted tiene Java, eres
mirando los mapas y listas.

967
00:41:03,602 --> 00:41:05,060
Puedo crear objetos que del 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
Y podría tener listas de
valores dentro de esas propiedades.

970
00:41:10,890 --> 00:41:13,490
Puede almacenar este complejo
estructura jerarquica

971
00:41:13,490 --> 00:41:16,320
como un solo atributo
de un elemento DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Así tablas en DynamoDB, como la mayoría
Bases de datos NoSQL, mesas tienen elementos.

974
00:41:24,460 --> 00:41:26,469
En MongoDB lo haría
llamar a estos documentos.

975
00:41:26,469 --> 00:41:27,760
Y sería la base sofá.

976
00:41:27,760 --> 00:41:28,900
También una base de datos documental.

977
00:41:28,900 --> 00:41:29,941
Usted llama a estos documentos.

978
00:41:29,941 --> 00:41:32,930
Documentos o elementos tienen atributos.

979
00:41:32,930 --> 00:41:35,850
Pueden existir atributos o
no existe en el artículo.

980
00:41:35,850 --> 00:41:38,520
En DynamoDB, hay
un atributo obligatorio.

981
00:41:38,520 --> 00:41:43,880
Al igual que en una base de datos relacional,
usted tiene una clave principal en la tabla.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB tiene lo que llamamos una clave hash.

983
00:41:46,010 --> 00:41:48,280
Clave hash debe ser único.

984
00:41:48,280 --> 00:41:52,580
Así que cuando me defino una tabla hash,
básicamente lo que estoy diciendo

985
00:41:52,580 --> 00:41:54,110
es cada artículo tendrá una clave hash.

986
00:41:54,110 --> 00:41:58,520
Y cada tecla almohadilla debe ser único.

987
00:41:58,520 --> 00:42:01,200
>> Cada artículo se define
por esa clave hash único.

988
00:42:01,200 --> 00:42:02,940
Y sólo puede haber una.

989
00:42:02,940 --> 00:42:05,820
Esto está bien, pero muchas veces
lo que la gente necesita

990
00:42:05,820 --> 00:42:08,170
es que quieren es este hash
clave para hacer un poco más

991
00:42:08,170 --> 00:42:11,010
que simplemente ser un identificador único.

992
00:42:11,010 --> 00:42:15,240
Muchas veces queremos utilizar esa clave hash
como la parte superior de cubo agregación nivel.

993
00:42:15,240 --> 00:42:19,160
Y la manera de hacer eso es por
añadiendo lo que llamamos una clave gama.

994
00:42:19,160 --> 00:42:22,460
>> Así que si es sólo un hash
tabla, este debe ser único.

995
00:42:22,460 --> 00:42:27,040
Si se trata de una tabla hash y el rango, la
combinación del hachís y la gama

996
00:42:27,040 --> 00:42:28,640
debe ser único.

997
00:42:28,640 --> 00:42:30,110
Así que pensar en ello de esta manera.

998
00:42:30,110 --> 00:42:32,140
Si tengo un foro.

999
00:42:32,140 --> 00:42:39,010
Y la forma tiene temas, tiene
puestos, y tiene respuestas.

1000
00:42:39,010 --> 00:42:42,630
>> Así que voy a tener un hash
clave, que es el identificador de tema.

1001
00:42:42,630 --> 00:42:46,650
Y yo podría tener una clave de gama,
que es la ID de respuesta.

1002
00:42:46,650 --> 00:42:49,650
De esta forma si quiero obtener toda la
respuestas para determinado tema,

1003
00:42:49,650 --> 00:42:52,370
Yo sólo puedo consultar el hash.

1004
00:42:52,370 --> 00:42:55,190
Yo sólo puedo decir me da todo
los elementos que tienen este hash.

1005
00:42:55,190 --> 00:43:01,910
Y yo voy a poner todas las preguntas
o publicarlos para ese tema en particular.

1006
00:43:01,910 --> 00:43:03,910
Estas agrupaciones de primer nivel
son muy importantes.

1007
00:43:03,910 --> 00:43:07,370
Apoyan el acceso primario
patrón de la aplicación.

1008
00:43:07,370 --> 00:43:09,420
En términos generales, este
es lo que queremos hacer.

1009
00:43:09,420 --> 00:43:11,780
Queremos que table--
como se carga la tabla,

1010
00:43:11,780 --> 00:43:16,640
queremos estructurar los datos
dentro de la tabla de una manera tal

1011
00:43:16,640 --> 00:43:20,140
que la aplicación puede muy
recuperar rápidamente los resultados.

1012
00:43:20,140 --> 00:43:24,510
Y a menudo la forma de hacerlo es
para mantener estas agregaciones como nos

1013
00:43:24,510 --> 00:43:25,650
insertar los datos.

1014
00:43:25,650 --> 00:43:31,110
Básicamente, estamos extendiendo los datos
en el cubo brillante, ya que viene en.

1015
00:43:31,110 --> 00:43:35,210
>> Teclas Range permiten picadillo mí--
llaves tienen que haber igualdad.

1016
00:43:35,210 --> 00:43:39,490
Cuando consulta una almohadilla, que tengo que decir
dame un hash que es igual a esto.

1017
00:43:39,490 --> 00:43:41,950
Cuando consulta una gama, que
puede decir dame una gama

1018
00:43:41,950 --> 00:43:47,040
que es el uso de cualquier tipo de
rica operador que apoyamos.

1019
00:43:47,040 --> 00:43:49,200
Dame todos los elementos para un hash.

1020
00:43:49,200 --> 00:43:52,520
Es igual, mayor que,
menos, qué empezar,

1021
00:43:52,520 --> 00:43:54,145
¿existe entre estos dos valores?

1022
00:43:54,145 --> 00:43:56,811
Así que este tipo de consultas de rango
que estamos siempre interesados ​​en.

1023
00:43:56,811 --> 00:43:59,650
Ahora una cosa acerca de los datos, cuando
nos fijamos en el acceso a los datos, cuando

1024
00:43:59,650 --> 00:44:02,360
acceder a los datos, es
Siempre se trata de una agregación.

1025
00:44:02,360 --> 00:44:05,770
Siempre se trata de los registros
que tienen que ver con esto.

1026
00:44:05,770 --> 00:44:10,390
Dame todo lo que aquí Eso es-- todo
las transacciones en esta tarjeta de crédito

1027
00:44:10,390 --> 00:44:12,500
para el último mes.

1028
00:44:12,500 --> 00:44:13,960
Eso es una agregación.

1029
00:44:13,960 --> 00:44:17,490
>> Casi todo lo que haces en el
base de datos es una especie de agregación.

1030
00:44:17,490 --> 00:44:21,530
Así que ser capaz de ser capaz de definir
estos cubos y darle estos van

1031
00:44:21,530 --> 00:44:24,950
atributos para poder consultar en,
esas consultas ricos apoyan muchos,

1032
00:44:24,950 --> 00:44:27,165
muchos, muchos patrones de acceso de la aplicación.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Así que la otra cosa la tecla almohadilla
hace es que nos da un mecanismo

1035
00:44:35,000 --> 00:44:37,740
para ser capaz de difundir los datos alrededor.

1036
00:44:37,740 --> 00:44:40,390
Bases de datos NoSQL funcionan mejor
cuando los datos son uniformemente

1037
00:44:40,390 --> 00:44:41,740
distribuido en todo el clúster.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
¿Cuántas personas son familiares
con algoritmos hash?

1040
00:44:47,050 --> 00:44:49,860
Cuando digo hash y un hashing--
porque un algoritmo de hash

1041
00:44:49,860 --> 00:44:54,140
es una forma de ser capaz de generar
un valor aleatorio de cualquier valor dado.

1042
00:44:54,140 --> 00:44:59,300
Así que en este caso particular, el
algoritmo de hash corremos es ND 5 basado.

1043
00:44:59,300 --> 00:45:04,765
>> Y si tengo una identificación, y esto
es mi clave hash, tengo 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Cuando ejecuto el algoritmo de hash,
que va a regresar y decir,

1045
00:45:07,390 --> 00:45:10,800
bien 1 es igual a 7B, 2
es igual a 48, 3 es igual a CD.

1046
00:45:10,800 --> 00:45:13,092
Están repartidos por todo el espacio de claves.

1047
00:45:13,092 --> 00:45:14,050
Y ¿por qué haces esto?

1048
00:45:14,050 --> 00:45:17,120
Debido a que se asegura de que puedo
poner los registros a través de múltiples nodos.

1049
00:45:17,120 --> 00:45:19,574
>> Si yo estoy haciendo esto
incremental, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
Y tengo un rango hash que
carreras en este caso particular,

1051
00:45:21,990 --> 00:45:24,785
un pequeño espacio de hash,
que va desde 00 a FF,

1052
00:45:24,785 --> 00:45:27,951
a continuación, los registros van a venir en
y que van a ir a 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
¿Lo que pasa?

1055
00:45:31,800 --> 00:45:34,860
Cada inserto va al mismo nodo.

1056
00:45:34,860 --> 00:45:36,070
¿Ves lo que quiero decir?

1057
00:45:36,070 --> 00:45:40,910
>> Porque cuando me separé el espacio,
y yo extendí estos registros a través de,

1058
00:45:40,910 --> 00:45:45,950
y la partición yo, yo voy a decir
partición 1 tiene espacio de claves 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partición 2 es 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partición 3 es AA a FF.

1061
00:45:49,780 --> 00:45:53,740
Así que si estoy usando linealmente incrementando
Identificadores, se puede ver lo que está sucediendo.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, todo el camino hasta 54.

1063
00:45:57,410 --> 00:46:00,030
Así como estoy golpeando la
registros en el sistema,

1064
00:46:00,030 --> 00:46:02,030
todo acaba yendo a un nodo.

1065
00:46:02,030 --> 00:46:03,160
>> Eso no es bueno.

1066
00:46:03,160 --> 00:46:04,820
Ese es un anti patrón.

1067
00:46:04,820 --> 00:46:08,760
En MongoDB tienen este problema
si usted no utiliza una clave hash.

1068
00:46:08,760 --> 00:46:11,325
MongoDB le da la opción
de hash el valor clave.

1069
00:46:11,325 --> 00:46:13,950
Usted siempre debe hacer eso, si
está utilizando un hash incrementando

1070
00:46:13,950 --> 00:46:17,380
clave en MongoDB, o va a ser
clavando cada escritura para un nodo,

1071
00:46:17,380 --> 00:46:21,290
y se le limitando
su rendimiento de escritura mal.

1072
00:46:21,290 --> 00:46:24,896
>> AUDIENCIA: ¿Es que A9 169 en decimal?

1073
00:46:24,896 --> 00:46:28,450
>> RICK HOULIHAN: Sí, es
en algún lugar por allí.

1074
00:46:28,450 --> 00:46:29,950
A9, yo no lo sé.

1075
00:46:29,950 --> 00:46:32,200
Habría que conseguir mi binaria
a la calculadora decimal.

1076
00:46:32,200 --> 00:46:34,237
Mi cerebro no funciona de esa manera.

1077
00:46:34,237 --> 00:46:36,320
AUDIENCIA: Sólo una rápida
de sus comentarios Mongo.

1078
00:46:36,320 --> 00:46:39,530
Así es el ID de objeto que viene
nativa con Mongo hacer eso?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK HOULIHAN: ¿Hace eso?

1081
00:46:41,470 --> 00:46:42,970
Si se especifica la misma.

1082
00:46:42,970 --> 00:46:45,030
Con MongoDB, usted tiene la opción.

1083
00:46:45,030 --> 00:46:48,930
Puede specify-- cada documento en
MongoDB tiene que tener un ID de subrayado.

1084
00:46:48,930 --> 00:46:50,300
Ese es el valor único.

1085
00:46:50,300 --> 00:46:55,240
>> En MongoDB puede especificar
ya sea para discutir o no.

1086
00:46:55,240 --> 00:46:56,490
Ellos sólo le dan la opción.

1087
00:46:56,490 --> 00:46:58,198
Si usted sabe que es
al azar, no hay problema.

1088
00:46:58,198 --> 00:46:59,640
Usted no tiene que hacer eso.

1089
00:46:59,640 --> 00:47:04,260
Si usted sabe que no es al azar, que
está incrementando, y luego hacer el hash.

1090
00:47:04,260 --> 00:47:06,880
>> Ahora lo que pasa
hash, una vez que hash de

1091
00:47:06,880 --> 00:47:08,800
un value-- y esto es
por qué claves hash son siempre

1092
00:47:08,800 --> 00:47:13,740
consultas únicas, porque he cambiado
el valor, ahora no puede hacer una consulta gama.

1093
00:47:13,740 --> 00:47:15,640
No puedo decir que es esto
entre esto o aquello,

1094
00:47:15,640 --> 00:47:20,800
debido a que el valor hash no va
ser equivalente al valor real.

1095
00:47:20,800 --> 00:47:24,570
Así que cuando usted hash que
clave, es sólo la igualdad.

1096
00:47:24,570 --> 00:47:28,700
Por eso, en clave hash DynamoDB
consultas son siempre sólo la igualdad.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Así que ahora en un rango key--
cuando agrego esa clave gama,

1099
00:47:34,700 --> 00:47:38,180
esos registros claves alcance todos entran y
que se almacenan en la misma partición.

1100
00:47:38,180 --> 00:47:42,430
Así que son muy rápidamente, fácilmente
recuperada porque este es el hachís,

1101
00:47:42,430 --> 00:47:43,220
este es el rango.

1102
00:47:43,220 --> 00:47:44,928
Y se ve todo
con el mismo hash

1103
00:47:44,928 --> 00:47:48,550
se almacena en el mismo espacio de partición.

1104
00:47:48,550 --> 00:47:53,889
Usted puede usar esa clave gama para ayudar
localizar sus datos cerca de su padre.

1105
00:47:53,889 --> 00:47:55,180
Entonces, ¿qué estoy haciendo realmente aquí?

1106
00:47:55,180 --> 00:47:57,320
Esta es una de uno a muchos relación.

1107
00:47:57,320 --> 00:48:01,490
La relación entre una clave hash
y la tecla de rango es de uno a muchos.

1108
00:48:01,490 --> 00:48:03,490
Puedo tener varias claves hash.

1109
00:48:03,490 --> 00:48:07,610
Sólo puedo tener rango múltiple
claves dentro de cada tecla almohadilla.

1110
00:48:07,610 --> 00:48:11,910
>> El hash define el padre,
el rango define los niños.

1111
00:48:11,910 --> 00:48:15,240
Así que usted puede ver que hay analógico aquí
entre el constructo relacional

1112
00:48:15,240 --> 00:48:18,840
y los mismos tipos de
construye en NoSQL.

1113
00:48:18,840 --> 00:48:20,760
La gente habla de
NoSQL como no relacional.

1114
00:48:20,760 --> 00:48:22,200
No es no relacional.

1115
00:48:22,200 --> 00:48:24,680
Los datos siempre tiene relaciones.

1116
00:48:24,680 --> 00:48:28,172
Esas relaciones simplemente
se modelan de manera diferente.

1117
00:48:28,172 --> 00:48:29,880
Vamos a hablar un poco
poco acerca de la durabilidad.

1118
00:48:29,880 --> 00:48:34,860
Cuando se escribe a DynamoDB, escribe
son siempre tres vías replicado.

1119
00:48:34,860 --> 00:48:37,550
Lo que significa que tenemos tres AZ de.

1120
00:48:37,550 --> 00:48:39,160
AZ de son zonas de disponibilidad.

1121
00:48:39,160 --> 00:48:43,430
Usted puede pensar en una disponibilidad
Zona como un centro de datos

1122
00:48:43,430 --> 00:48:45,447
o una colección de centros de datos.

1123
00:48:45,447 --> 00:48:47,780
Estas cosas son geográficamente
aislados unos de otros

1124
00:48:47,780 --> 00:48:51,610
a través de diferentes zonas de fallas, a través de
diferentes redes eléctricas y las llanuras de inundación.

1125
00:48:51,610 --> 00:48:54,510
Un fallo en uno AZ no es
va a acabar con el otro.

1126
00:48:54,510 --> 00:48:56,890
Ellos también están vinculados
junto con la fibra oscura.

1127
00:48:56,890 --> 00:49:01,240
Es compatible con una sub 1
latencia de milisegundos entre AZS.

1128
00:49:01,240 --> 00:49:05,390
Así replicaciones de datos en tiempo real
capaz en múltiples AZS.

1129
00:49:05,390 --> 00:49:09,990
>> Y muchas veces los despliegues múltiples AZ
cumplir con los requisitos de alta disponibilidad

1130
00:49:09,990 --> 00:49:12,930
de la mayoría de las organizaciones empresariales.

1131
00:49:12,930 --> 00:49:16,139
Así DynamoDB se propaga
a través de tres AZS por defecto.

1132
00:49:16,139 --> 00:49:19,430
Sólo vamos al conocimiento de la escritura
cuando dos de esos tres nodos vuelven

1133
00:49:19,430 --> 00:49:21,470
y digo: Sí, lo tengo.

1134
00:49:21,470 --> 00:49:22,050
¿Porqué es eso?

1135
00:49:22,050 --> 00:49:25,950
Debido a que en el lado de lectura sólo estamos
voy a dar los datos de nuevo cuando

1136
00:49:25,950 --> 00:49:27,570
lo hacemos a partir de dos nodos.

1137
00:49:27,570 --> 00:49:30,490
>> Si estoy replicando en todo
tres, y estoy leyendo de dos,

1138
00:49:30,490 --> 00:49:32,840
Siempre estoy garantizado
para tener al menos una

1139
00:49:32,840 --> 00:49:35,720
de los que lee ser el
más copia actualizada de los datos.

1140
00:49:35,720 --> 00:49:38,340
Eso es lo que hace DynamoDB consistente.

1141
00:49:38,340 --> 00:49:42,450
Ahora usted puede optar por activar
aquellos consistentes lee fuera.

1142
00:49:42,450 --> 00:49:45,070
En este caso voy a decir,
Yo sólo voy a leer de un nodo.

1143
00:49:45,070 --> 00:49:47,430
Y no puedo garantizar que va
siendo los datos más actuales.

1144
00:49:47,430 --> 00:49:49,450
>> Así que si una escritura está entrando,
no ha replicado todavía,

1145
00:49:49,450 --> 00:49:50,360
usted va a conseguir que la copia.

1146
00:49:50,360 --> 00:49:52,220
Esa es una lectura finalmente coherente.

1147
00:49:52,220 --> 00:49:54,640
Y lo que es eso es la mitad del costo.

1148
00:49:54,640 --> 00:49:56,140
Así que esto es algo en que pensar.

1149
00:49:56,140 --> 00:50:00,160
Cuando usted está leyendo DynamoDB, y
está configurando su capacidad de lectura

1150
00:50:00,160 --> 00:50:04,430
unidades, si se eligen con el tiempo
lecturas consistentes, es mucho más barato,

1151
00:50:04,430 --> 00:50:06,010
que es aproximadamente la mitad del costo.

1152
00:50:06,010 --> 00:50:09,342
>> Y por lo que le ahorra dinero.

1153
00:50:09,342 --> 00:50:10,300
Pero esa es su elección.

1154
00:50:10,300 --> 00:50:12,925
Si quieres una lectura consistente o
una lectura finalmente coherente.

1155
00:50:12,925 --> 00:50:15,720
Eso es algo que se puede elegir.

1156
00:50:15,720 --> 00:50:17,659
>> Vamos a hablar de los índices.

1157
00:50:17,659 --> 00:50:19,450
Así mencionamos que
agregación de nivel superior.

1158
00:50:19,450 --> 00:50:23,720
Tenemos claves hash, y
tenemos llaves alcance.

1159
00:50:23,720 --> 00:50:24,320
Eso es bueno.

1160
00:50:24,320 --> 00:50:26,950
Y eso es en la mesa principal, I
nos dieron una clave hash, tengo una llave gama.

1161
00:50:26,950 --> 00:50:27,783
>> Qué significa eso?

1162
00:50:27,783 --> 00:50:30,410
Tengo un atributo que
puede ejecutar consultas ricos contra.

1163
00:50:30,410 --> 00:50:31,800
Es la clave gama.

1164
00:50:31,800 --> 00:50:35,530
Los otros atributos en que item--
Puedo filtrar esos atributos.

1165
00:50:35,530 --> 00:50:40,050
Pero yo no puedo hacer cosas similares,
comienza con, o es mayor que.

1166
00:50:40,050 --> 00:50:40,820
>> ¿Cómo puedo hacer eso?

1167
00:50:40,820 --> 00:50:42,860
Puedo crear un índice.

1168
00:50:42,860 --> 00:50:45,340
Hay dos tipos de
índices en DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Un índice es realmente
otra vista de la tabla.

1170
00:50:49,002 --> 00:50:50,490
Y el índice secundario local.

1171
00:50:50,490 --> 00:50:51,781
>> La primera de ellas hablaremos.

1172
00:50:51,781 --> 00:50:57,740
Así que secundarias locales se coexistieron
en la misma partición que los datos.

1173
00:50:57,740 --> 00:51:00,240
Y como tales, son en
el mismo nodo físico.

1174
00:51:00,240 --> 00:51:01,780
Son lo que llamamos consistente.

1175
00:51:01,780 --> 00:51:04,599
Significado, van a reconocer
la escritura junto con la mesa.

1176
00:51:04,599 --> 00:51:06,890
Cuando la escritura viene,
vamos a escribir a través del índice.

1177
00:51:06,890 --> 00:51:09,306
Vamos a escribir hasta la mesa,
y luego vamos a reconocer.

1178
00:51:09,306 --> 00:51:10,490
Así que eso es consistente.

1179
00:51:10,490 --> 00:51:13,174
Una vez que la escritura ha sido
reconocido de la mesa,

1180
00:51:13,174 --> 00:51:15,090
está garantizado que la
índice secundario locales

1181
00:51:15,090 --> 00:51:18,380
tendrá la misma visión de los datos.

1182
00:51:18,380 --> 00:51:22,390
Pero lo que permiten que haces es
definir teclas de rango alternos.

1183
00:51:22,390 --> 00:51:25,260
>> Tiene que usar el mismo hash
tecla que la tabla principal,

1184
00:51:25,260 --> 00:51:29,050
porque ellos son co-ubicado en la
misma partición, y son consistentes.

1185
00:51:29,050 --> 00:51:33,110
Pero puedo crear un índice
con diferentes claves alcance.

1186
00:51:33,110 --> 00:51:41,590
Así, por ejemplo, si yo tuviera un fabricante
que tenía una mesa de piezas en bruto que entra.

1187
00:51:41,590 --> 00:51:44,590
Y partes primas vienen en y
que están agregados por el montaje.

1188
00:51:44,590 --> 00:51:46,840
Y tal vez hay un retiro.

1189
00:51:46,840 --> 00:51:50,240
>> Cualquier parte que fue hecho por este
fabricante después de esta fecha,

1190
00:51:50,240 --> 00:51:52,840
Tengo que tirar de mi línea.

1191
00:51:52,840 --> 00:51:55,950
Puedo girar un índice
que estaría buscando,

1192
00:51:55,950 --> 00:52:00,760
agregando en la fecha de
fabricación de esa parte en particular.

1193
00:52:00,760 --> 00:52:03,930
Así que si mi mesa de alto nivel fue
ya hash por el fabricante,

1194
00:52:03,930 --> 00:52:07,655
tal vez se organizó en parte ID, I
puede crear un índice de esa mesa

1195
00:52:07,655 --> 00:52:11,140
como hash según el fabricante y
oscilado en la fecha de fabricación.

1196
00:52:11,140 --> 00:52:14,490
Y de esa manera yo podría decir, todo lo que
fue fabricado entre estas fechas,

1197
00:52:14,490 --> 00:52:16,804
Tengo que tirar de la línea.

1198
00:52:16,804 --> 00:52:18,220
Así que eso es un índice secundario local.

1199
00:52:18,220 --> 00:52:22,280
>> Estos tienen el efecto de
limitando su espacio clave hash.

1200
00:52:22,280 --> 00:52:24,360
Debido a que co-existido
en el mismo nodo de almacenamiento,

1201
00:52:24,360 --> 00:52:26,860
limitan la tecla almohadilla
espacio para 10 gigabytes.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, bajo la
tablas, se particionar

1203
00:52:28,950 --> 00:52:31,380
su mesa cada 10 gigabytes.

1204
00:52:31,380 --> 00:52:34,760
Cuando usted pone 10 gigas de datos, nos
ir [PHH], y añadimos otro nodo.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> No vamos a dividir el LSI
en varias particiones.

1207
00:52:42,070 --> 00:52:43,200
Vamos a dividir la tabla.

1208
00:52:43,200 --> 00:52:44,679
Pero no vamos a dividir el LSI.

1209
00:52:44,679 --> 00:52:46,470
Así que eso es algo
importante entender

1210
00:52:46,470 --> 00:52:50,070
es si lo estás haciendo muy,
muy, muy grandes agregaciones,

1211
00:52:50,070 --> 00:52:53,860
entonces usted va a estar limitada
10 gigabytes en su LSI.

1212
00:52:53,860 --> 00:52:56,640
>> Si ese es el caso, podemos
utilizar secundarios globales.

1213
00:52:56,640 --> 00:52:58,630
Secundarias globales son
realmente otra mesa.

1214
00:52:58,630 --> 00:53:01,720
Existen completamente fuera de
el lado de la tabla principal.

1215
00:53:01,720 --> 00:53:04,680
Y ellos me permiten encontrar una
completamente diferente estructura.

1216
00:53:04,680 --> 00:53:08,010
Así que pensar en ello como se está insertando datos
en dos mesas diferentes, estructurados

1217
00:53:08,010 --> 00:53:09,220
de dos maneras diferentes.

1218
00:53:09,220 --> 00:53:11,360
>> Puedo definir una totalmente
diferente clave hash.

1219
00:53:11,360 --> 00:53:13,490
Puedo definir una totalmente
llave diferente rango.

1220
00:53:13,490 --> 00:53:15,941
Y puedo ejecutar este
de forma totalmente independiente.

1221
00:53:15,941 --> 00:53:18,190
Como cuestión de hecho, tengo
aprovisionado mi capacidad de lectura

1222
00:53:18,190 --> 00:53:21,090
y escribir capacidad para mi
índices secundarios globales

1223
00:53:21,090 --> 00:53:24,240
de forma totalmente independiente
de mi tabla principal.

1224
00:53:24,240 --> 00:53:26,640
Si defino ese índice, le digo
que la cantidad de lectura y escritura

1225
00:53:26,640 --> 00:53:28,610
la capacidad que va a utilizar.

1226
00:53:28,610 --> 00:53:31,490
>> Y eso es separada
desde mi tabla principal.

1227
00:53:31,490 --> 00:53:35,240
Ahora, tanto de los índices nos permiten
no sólo definir claves de hash y de alcance,

1228
00:53:35,240 --> 00:53:38,610
pero nos permiten
proyectar valores adicionales.

1229
00:53:38,610 --> 00:53:44,950
Así que si quiero leer el índice,
y quiero conseguir algún conjunto de datos,

1230
00:53:44,950 --> 00:53:48,327
No necesito volver a la principal
tabla para obtener los atributos adicionales.

1231
00:53:48,327 --> 00:53:50,660
Puedo proyectar aquellos adicional
atributos en la tabla

1232
00:53:50,660 --> 00:53:53,440
para apoyar el patrón de acceso.

1233
00:53:53,440 --> 00:53:57,700
Sé que probablemente estamos llegando a algún
Realmente, realmente-- entrar en la maleza

1234
00:53:57,700 --> 00:53:58,910
aquí en algunas de estas cosas.

1235
00:53:58,910 --> 00:54:02,725
Ahora tengo a la deriva fuera de esto.

1236
00:54:02,725 --> 00:54:07,320
>> AUDIENCIA: [inaudible]
clave --table quería decir era un hash?

1237
00:54:07,320 --> 00:54:08,840
El hash original?

1238
00:54:08,840 --> 00:54:09,340
Multi-lamas?

1239
00:54:09,340 --> 00:54:10,200
>> RICK HOULIHAN: Sí.

1240
00:54:10,200 --> 00:54:11,070
Sí.

1241
00:54:11,070 --> 00:54:15,260
La clave de la tabla, básicamente,
apunta de nuevo al tema.

1242
00:54:15,260 --> 00:54:19,280
Así que un índice es un puntero de nuevo a
los elementos originales en la mesa.

1243
00:54:19,280 --> 00:54:22,910
Ahora usted puede elegir para construir un
índice que sólo tiene la clave de la tabla,

1244
00:54:22,910 --> 00:54:24,840
y no hay otras propiedades.

1245
00:54:24,840 --> 00:54:26,570
¿Y por qué podría yo hacer eso?

1246
00:54:26,570 --> 00:54:28,570
Bueno, tal vez tengo artículos muy grandes.

1247
00:54:28,570 --> 00:54:31,660
>> En realidad sólo necesito saber which--
mi patrón de acceso podría decir:

1248
00:54:31,660 --> 00:54:33,760
los elementos que contienen esta propiedad?

1249
00:54:33,760 --> 00:54:35,780
No es necesario devolver el artículo.

1250
00:54:35,780 --> 00:54:37,800
Sólo necesito saber
los elementos que contienen.

1251
00:54:37,800 --> 00:54:40,700
Así que usted puede construir índices
que sólo tienen la clave de la tabla.

1252
00:54:40,700 --> 00:54:43,360
>> Pero eso es principalmente lo que
un índice en la base de datos es para.

1253
00:54:43,360 --> 00:54:46,280
Es para poder rápidamente
identificar que registra,

1254
00:54:46,280 --> 00:54:49,470
qué filas, las cuales
los elementos de la tabla tienen

1255
00:54:49,470 --> 00:54:51,080
las propiedades que estoy buscando.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSI, así que ¿cómo funcionan?

1258
00:54:54,860 --> 00:54:58,340
GSI básicamente son asíncronas.

1259
00:54:58,340 --> 00:55:02,570
La actualización entra en la mesa,
A continuación, se actualiza la tabla de forma asíncrona

1260
00:55:02,570 --> 00:55:03,720
toda su GSI.

1261
00:55:03,720 --> 00:55:06,680
Esta es la razón por GSI son
finalmente consistente.

1262
00:55:06,680 --> 00:55:09,440
>> Es importante observar que
cuando usted está construyendo GSI,

1263
00:55:09,440 --> 00:55:13,110
y usted entiende que está creando
otra dimensión de aggregation--

1264
00:55:13,110 --> 00:55:16,594
Ahora digamos que un buen ejemplo
aquí es un fabricante.

1265
00:55:16,594 --> 00:55:19,260
Creo que podría haber hablado
un fabricante de dispositivos médicos.

1266
00:55:19,260 --> 00:55:23,870
Fabricantes de dispositivos médicos
muchas veces tienen partes serializados.

1267
00:55:23,870 --> 00:55:28,070
Las partes que intervienen en la
un reemplazo de cadera todo

1268
00:55:28,070 --> 00:55:30,200
tener un pequeño número de serie en ellos.

1269
00:55:30,200 --> 00:55:33,584
Y podrían tener millones y
millones y miles de millones de piezas

1270
00:55:33,584 --> 00:55:35,000
en todos los dispositivos que envían.

1271
00:55:35,000 --> 00:55:37,440
Bueno, tienen que agregarse bajo
diferentes dimensiones, todas las piezas

1272
00:55:37,440 --> 00:55:39,520
en una asamblea, toda la
partes que se hicieron

1273
00:55:39,520 --> 00:55:41,670
en una determinada línea, todo
las partes que vienen

1274
00:55:41,670 --> 00:55:44,620
desde un cierto fabricante
en una fecha determinada.

1275
00:55:44,620 --> 00:55:47,940
Y estas agregaciones a veces
levantarse en los miles de millones.

1276
00:55:47,940 --> 00:55:50,550
>> Así que yo trabajo con algunos de
estos chicos que están sufriendo

1277
00:55:50,550 --> 00:55:53,156
porque están creando
estas agregaciones ginormous

1278
00:55:53,156 --> 00:55:54,280
en sus índices secundarios.

1279
00:55:54,280 --> 00:55:57,070
Puede ser que tengan unas partes primas
tabla que viene ya que sólo hash.

1280
00:55:57,070 --> 00:55:59,090
Cada parte tiene un número de serie único.

1281
00:55:59,090 --> 00:56:00,975
Yo uso el número de serie que el hash.

1282
00:56:00,975 --> 00:56:01,600
Es hermoso.

1283
00:56:01,600 --> 00:56:04,160
Mi tabla de datos en bruto se propaga
todo el espacio de claves.

1284
00:56:04,160 --> 00:56:05,930
Mi [? escribe ?]
[? la ingestión?] es impresionante.

1285
00:56:05,930 --> 00:56:07,876
Tengo una gran cantidad de datos.

1286
00:56:07,876 --> 00:56:09,500
Entonces lo que hacen es que crean un GSI.

1287
00:56:09,500 --> 00:56:12,666
Y digo yo, ¿sabes qué, tengo que ver
todas las partes de este fabricante.

1288
00:56:12,666 --> 00:56:15,060
Bueno, de repente estoy
teniendo un billón de filas,

1289
00:56:15,060 --> 00:56:17,550
y meterlos en
un nodo, porque cuando

1290
00:56:17,550 --> 00:56:21,170
Yo agregada como el
ID del fabricante como el hachís,

1291
00:56:21,170 --> 00:56:25,410
y el número de pieza como el rango,
entonces de repente estoy

1292
00:56:25,410 --> 00:56:30,530
poner mil millones de partes en lo que
este fabricante me ha entregado.

1293
00:56:30,530 --> 00:56:34,447
>> Eso puede causar una gran cantidad
de presión sobre el GSI,

1294
00:56:34,447 --> 00:56:36,030
de nuevo, porque estoy martillando un nodo.

1295
00:56:36,030 --> 00:56:38,350
Estoy poniendo todo esto
inserta en un nodo.

1296
00:56:38,350 --> 00:56:40,940
Y eso es un caso real uso problemático.

1297
00:56:40,940 --> 00:56:43,479
Ahora, tengo un buen diseño
patrón de cómo evitar eso.

1298
00:56:43,479 --> 00:56:45,770
Y ese es uno de los problemas
que yo siempre trabajo con.

1299
00:56:45,770 --> 00:56:49,590
Pero lo que sucede, es el GSI podría
no tienen suficiente capacidad de escritura

1300
00:56:49,590 --> 00:56:52,330
para ser capaz de empujar todos aquellos
filas en un solo nodo.

1301
00:56:52,330 --> 00:56:55,390
Y lo que sucede a continuación es la
primaria, la tabla de clientes,

1302
00:56:55,390 --> 00:57:00,180
la tabla principal será estrangulado
debido a que el GSI no puede seguir el ritmo.

1303
00:57:00,180 --> 00:57:02,980
Así que mi tasa de inserción será
caer en la tabla principal

1304
00:57:02,980 --> 00:57:06,230
como mi GSI trata de mantener el ritmo.

1305
00:57:06,230 --> 00:57:08,850
>> Muy bien, así GSI de, LSI de,
cuál debo utilizar?

1306
00:57:08,850 --> 00:57:12,290
LSI de son consistentes.

1307
00:57:12,290 --> 00:57:13,750
GSI de son finalmente consistente.

1308
00:57:13,750 --> 00:57:17,490
Si eso está bien, recomiendo el uso de un
GSI, son mucho más flexibles.

1309
00:57:17,490 --> 00:57:20,270
LSI de se puede modelar como un GSI.

1310
00:57:20,270 --> 00:57:27,040
Y si el tamaño de los datos por claves hash en
su colección supera los 10 gigabytes,

1311
00:57:27,040 --> 00:57:31,050
entonces usted va a querer usar ese
GSI porque es sólo un límite duro.

1312
00:57:31,050 --> 00:57:32,035
>> Muy bien, por lo que la escala.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
El rendimiento en el Dynamo DB,
prestación lata [inaudible]

1315
00:57:37,460 --> 00:57:38,680
rendimiento para una mesa.

1316
00:57:38,680 --> 00:57:42,740
Tenemos clientes que tienen
aprovisionado 60 billion--

1317
00:57:42,740 --> 00:57:45,970
están haciendo 60 mil millones de solicitudes, con regularidad
funcionando a más de un millón solicitudes

1318
00:57:45,970 --> 00:57:47,790
por segundo en nuestras mesas.

1319
00:57:47,790 --> 00:57:50,360
En realidad no hay
límite teórico a la cantidad de

1320
00:57:50,360 --> 00:57:53,730
y la rapidez con la tabla
se puede ejecutar en Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Hay algunos suave
límites en su cuenta

1322
00:57:55,920 --> 00:57:58,170
que ponemos allí, así
que no volverse loco.

1323
00:57:58,170 --> 00:58:00,070
Si desea más
que, no es un problema.

1324
00:58:00,070 --> 00:58:00,820
Vienes decirnos.

1325
00:58:00,820 --> 00:58:02,810
Vamos a subir el dial.

1326
00:58:02,810 --> 00:58:08,210
>> Cada cuenta está limitada a un cierto nivel
en cada servicio, justo al lado del palo

1327
00:58:08,210 --> 00:58:11,920
por lo que las personas no se vuelven locos
se meten en problemas.

1328
00:58:11,920 --> 00:58:12,840
No hay límite de tamaño.

1329
00:58:12,840 --> 00:58:14,940
Usted puede poner cualquier número
de elementos en una tabla.

1330
00:58:14,940 --> 00:58:17,620
El tamaño de un elemento es
limitado a 400 kilobytes cada uno,

1331
00:58:17,620 --> 00:58:20,050
eso sería no tema los atributos.

1332
00:58:20,050 --> 00:58:24,200
Así que la suma de todos los atributos
está limitado a 400 kilobytes.

1333
00:58:24,200 --> 00:58:27,300
Y, de nuevo, tenemos
ese pequeño problema de LSI

1334
00:58:27,300 --> 00:58:30,405
con el límite de 10 gigabytes por hash.

1335
00:58:30,405 --> 00:58:33,280
AUDIENCIA: Pequeño número, estoy desaparecidos
lo que me estás diciendo, que es--

1336
00:58:33,280 --> 00:58:36,830
AUDIENCIA: ¡Oh, 400 kilobytes
es el tamaño máximo por artículo.

1337
00:58:36,830 --> 00:58:39,570
Así que un elemento tiene todos los atributos.

1338
00:58:39,570 --> 00:58:43,950
Así que 400 k es el tamaño total
de ese artículo, 400 kilobytes.

1339
00:58:43,950 --> 00:58:46,170
Así que de todos los atributos
combinados, todos los datos

1340
00:58:46,170 --> 00:58:49,140
eso es en todos esos atributos,
enrollado en un tamaño total,

1341
00:58:49,140 --> 00:58:51,140
Actualmente la actualidad el límite de elementos es de 400 k.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Así escalado de nuevo, logrado
a través de la partición.

1344
00:58:57,046 --> 00:58:58,920
El rendimiento se aprovisiona
a nivel de tabla.

1345
00:58:58,920 --> 00:59:00,160
Y no hay realmente dos perillas.

1346
00:59:00,160 --> 00:59:02,400
Hemos leído la capacidad
y escribir capacidad.

1347
00:59:02,400 --> 00:59:05,530
>> Así que estos se ajustan
independientemente uno del otro.

1348
00:59:05,530 --> 00:59:08,640
Medida de RCU estrictamente lee consistente.

1349
00:59:08,640 --> 00:59:13,005
OK, así que si usted está diciendo que quiero 1000
UCR de esos son estrictamente coherente,

1350
00:59:13,005 --> 00:59:14,130
esos son lecturas consistentes.

1351
00:59:14,130 --> 00:59:17,130
Si dices que quiero
eventual coherente lee,

1352
00:59:17,130 --> 00:59:19,402
usted puede aprovisionar 1000
UCR de, vas

1353
00:59:19,402 --> 00:59:21,840
para llegar finalmente 2000
lee consistente.

1354
00:59:21,840 --> 00:59:25,940
Y la mitad del precio de los
finalmente consistir en lee.

1355
00:59:25,940 --> 00:59:28,520
>> Una vez más, ajustado
independientemente uno del otro.

1356
00:59:28,520 --> 00:59:32,900
Y tienen la throughput--
Si usted consume 100% de su mando a distancia,

1357
00:59:32,900 --> 00:59:35,960
usted no va a afectar el
disponibilidad de sus derechos.

1358
00:59:35,960 --> 00:59:40,161
Por lo que son completamente
independientes entre sí.

1359
00:59:40,161 --> 00:59:43,160
Muy bien, así que una de las cosas que
Mencioné brevemente estaba estrangulando.

1360
00:59:43,160 --> 00:59:44,320
Throttling es malo.

1361
00:59:44,320 --> 00:59:47,311
Throttling indica mal sin SQL.

1362
00:59:47,311 --> 00:59:50,310
Hay cosas que podemos hacer para ayudar
a aliviar el estrangulamiento que

1363
00:59:50,310 --> 00:59:51,040
están experimentando.

1364
00:59:51,040 --> 00:59:53,240
Pero la mejor solución
a esto es que echemos

1365
00:59:53,240 --> 00:59:58,000
Una mirada a lo que está haciendo, porque
hay un anti-patrón en juego aquí.

1366
00:59:58,000 --> 01:00:02,140
>> Estas cosas, cosas como no uniforme
las cargas de trabajo, teclas de acceso rápido, particiones calientes.

1367
01:00:02,140 --> 01:00:06,210
Estoy golpeando un espacio clave particular
muy duro por alguna razón en particular.

1368
01:00:06,210 --> 01:00:07,080
¿Por qué estoy haciendo esto?

1369
01:00:07,080 --> 01:00:08,710
Vamos a darse cuenta de eso.

1370
01:00:08,710 --> 01:00:10,427
Estoy mezclando mis datos calientes con los datos fríos.

1371
01:00:10,427 --> 01:00:12,510
Yo voy a dejar mis cuadros consiguen
enorme, pero no hay realmente

1372
01:00:12,510 --> 01:00:15,970
sólo algunos subconjunto de los datos
eso es muy interesante para mí.

1373
01:00:15,970 --> 01:00:20,290
Así que para los datos de registro, por ejemplo, una gran cantidad de
clientes, que reciben datos de registro todos los días.

1374
01:00:20,290 --> 01:00:22,490
Tienen una enorme cantidad de datos de registro.

1375
01:00:22,490 --> 01:00:25,940
>> Si acaba de vertido todo ese registro
datos en una gran mesa, con el tiempo

1376
01:00:25,940 --> 01:00:28,070
esa mesa se va a poner masiva.

1377
01:00:28,070 --> 01:00:30,950
Pero estoy realmente sólo interesado en
últimas 24 horas, los últimos siete días,

1378
01:00:30,950 --> 01:00:31,659
los últimos 30 días.

1379
01:00:31,659 --> 01:00:34,074
Cualquiera que sea la ventana de tiempo
que estoy interesado en mirar

1380
01:00:34,074 --> 01:00:37,010
para el caso de que me molesta, o
el caso de que es interesante para mí,

1381
01:00:37,010 --> 01:00:39,540
esa es la única ocasión en la ventana que necesito.

1382
01:00:39,540 --> 01:00:42,470
Así que ¿por qué estoy poniendo 10 años
el valor de los datos de registro en la tabla?

1383
01:00:42,470 --> 01:00:45,030
Lo que hace es
la mesa del fragmento.

1384
01:00:45,030 --> 01:00:45,880
>> Se pone enorme.

1385
01:00:45,880 --> 01:00:48,340
Comienza tendido
a través de miles de nodos.

1386
01:00:48,340 --> 01:00:51,380
Y puesto que su capacidad
es tan baja, que está

1387
01:00:51,380 --> 01:00:54,090
en realidad la limitación de velocidad en cada
uno de esos nodos individuales.

1388
01:00:54,090 --> 01:00:57,120
Así que vamos a empezar a mirar cómo
hacemos rodamos esa mesa.

1389
01:00:57,120 --> 01:01:01,502
¿Cómo gestionamos los datos un poco
mejor evitar estos problemas.

1390
01:01:01,502 --> 01:01:02,710
Y ¿qué se parecen?

1391
01:01:02,710 --> 01:01:04,370
Esto es lo que parece.

1392
01:01:04,370 --> 01:01:06,790
Esto es lo malo NoSQL se parece.

1393
01:01:06,790 --> 01:01:07,830
>> Recibí una tecla de acceso rápido aquí.

1394
01:01:07,830 --> 01:01:10,246
Si nos fijamos en el lado aquí,
estos son todos mis particiones.

1395
01:01:10,246 --> 01:01:12,630
Tengo 16 particiones aquí
en esta base de datos particular.

1396
01:01:12,630 --> 01:01:13,630
Lo hacemos todo el tiempo.

1397
01:01:13,630 --> 01:01:15,046
Corro esto para los clientes de todos los tiempos.

1398
01:01:15,046 --> 01:01:16,550
Se llama el mapa de calor.

1399
01:01:16,550 --> 01:01:20,590
Mapa de calor me dice lo que eres
el acceso a su espacio de claves.

1400
01:01:20,590 --> 01:01:23,700
Y lo que esto me está diciendo es
que hay una almohadilla especial

1401
01:01:23,700 --> 01:01:26,330
que este chico le gusta una
muchísimo, porque es

1402
01:01:26,330 --> 01:01:28,250
golpeándolo muy, muy difícil.

1403
01:01:28,250 --> 01:01:29,260
>> Así que el azul es agradable.

1404
01:01:29,260 --> 01:01:29,900
Nos gusta azul.

1405
01:01:29,900 --> 01:01:30,720
No nos gusta el rojo.

1406
01:01:30,720 --> 01:01:33,120
Red donde la presión
se incorpora al 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, ahora vas a ser estrangulado.

1408
01:01:35,560 --> 01:01:39,030
Así que cada vez que hay líneas rojas como
esto-- y no se trata sólo Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
cada base de datos NoSQL tiene este problema.

1410
01:01:41,630 --> 01:01:44,640
No son anti-patrones que pueden
conducir este tipo de condiciones.

1411
01:01:44,640 --> 01:01:49,070
Lo que hago es que trabajo con los clientes
para aliviar estas condiciones.

1412
01:01:49,070 --> 01:01:51,840
>> Y ¿qué se parecen?

1413
01:01:51,840 --> 01:01:54,260
Y esto es cada vez más
fuera del Dynamo DB rendimiento,

1414
01:01:54,260 --> 01:01:56,176
pero es realmente llegar
el máximo provecho de NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Esto no se limita a Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Esto es lo definitely--
solía trabajar en Mongo.

1417
01:02:02,050 --> 01:02:04,090
Estoy familiarizado con muchas plataformas NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Cada uno tiene este tipo
de los problemas claves calientes.

1419
01:02:06,830 --> 01:02:10,320
Para sacar el máximo partido de cualquier NoSQL
base de datos, específicamente Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
desea crear las tablas
donde el elemento clave hash tiene

1421
01:02:13,320 --> 01:02:18,590
un gran número de valores distintos,
un alto grado de cardinalidad.

1422
01:02:18,590 --> 01:02:22,530
Porque eso significa que estoy escribiendo
a un montón de diferentes cubos.

1423
01:02:22,530 --> 01:02:24,870
>> Los más cubos estoy
escrito a, más probable

1424
01:02:24,870 --> 01:02:29,100
Estoy a difundir que la carga de escritura o
leer cargar a cabo a través de múltiples nodos,

1425
01:02:29,100 --> 01:02:33,560
es más probable que soy de tener una
de alto rendimiento en la mesa.

1426
01:02:33,560 --> 01:02:37,440
Y luego quiero que los valores sean
solicitado de manera bastante uniforme en el tiempo

1427
01:02:37,440 --> 01:02:39,430
y uniformemente como al azar como sea posible.

1428
01:02:39,430 --> 01:02:42,410
Bueno, eso es bastante interesante,
porque no puedo realmente

1429
01:02:42,410 --> 01:02:43,960
control cuando los usuarios entran.

1430
01:02:43,960 --> 01:02:47,645
Así que basta con decir, si difundimos
cosas fuera de todo el espacio de claves,

1431
01:02:47,645 --> 01:02:49,270
probablemente estaremos en mejor forma.

1432
01:02:49,270 --> 01:02:51,522
>> Hay una cierta
cantidad de tiempo de entrega

1433
01:02:51,522 --> 01:02:53,230
que no vas
ser capaces de control.

1434
01:02:53,230 --> 01:02:55,438
Pero esos son en realidad el
dos dimensiones que tenemos,

1435
01:02:55,438 --> 01:02:58,800
espacio, el acceso de manera uniforme
propagación, el tiempo, las solicitudes

1436
01:02:58,800 --> 01:03:01,040
lleguen uniformemente espaciadas en el tiempo.

1437
01:03:01,040 --> 01:03:03,110
Y si esos dos
se están cumpliendo las condiciones,

1438
01:03:03,110 --> 01:03:05,610
entonces eso es lo que es
va a parecer.

1439
01:03:05,610 --> 01:03:07,890
Esto es mucho más bonito.

1440
01:03:07,890 --> 01:03:08,890
Estamos muy felices aquí.

1441
01:03:08,890 --> 01:03:10,432
Tenemos un esquema de acceso muy parejo.

1442
01:03:10,432 --> 01:03:13,098
Sí, tal vez usted está recibiendo un
poca presión de vez en cuando,

1443
01:03:13,098 --> 01:03:14,830
pero nada realmente demasiado extensa.

1444
01:03:14,830 --> 01:03:17,660
Así que es increíble la cantidad de veces,
cuando trabajo con los clientes,

1445
01:03:17,660 --> 01:03:20,670
esa primera gráfica la gran roja
bar y todo lo feo de color amarillo que es

1446
01:03:20,670 --> 01:03:23,147
por todo el lugar, nos
conseguir hecho con el ejercicio

1447
01:03:23,147 --> 01:03:24,980
después de un par de meses
de la re-arquitectura,

1448
01:03:24,980 --> 01:03:28,050
están corriendo la misma exacta
carga de trabajo en la misma carga exacta.

1449
01:03:28,050 --> 01:03:30,140
Y esto es lo que está buscando como ahora.

1450
01:03:30,140 --> 01:03:36,600
Así que lo que obtienes con NoSQL es un
esquema de datos que es absolutamente

1451
01:03:36,600 --> 01:03:38,510
atado al patrón de acceso.

1452
01:03:38,510 --> 01:03:42,170
>> Y usted puede optimizar ese esquema de datos
para apoyar ese patrón de acceso.

1453
01:03:42,170 --> 01:03:45,490
Si no lo hace, entonces usted va
ver esos tipos de problemas

1454
01:03:45,490 --> 01:03:46,710
con esas teclas de acceso rápido.

1455
01:03:46,710 --> 01:03:50,518
>> AUDIENCIA: Bueno, inevitablemente, algunos lugares
van a ser más caliente que otros.

1456
01:03:50,518 --> 01:03:51,450
>> RICK HOULIHAN: Siempre.

1457
01:03:51,450 --> 01:03:51,960
Siempre.

1458
01:03:51,960 --> 01:03:54,620
Sí, quiero decir que siempre hay
A-- y otra vez, no hay

1459
01:03:54,620 --> 01:03:56,980
algunos patrones de diseño que van a obtener a través de
que va a hablar sobre cómo tratar

1460
01:03:56,980 --> 01:03:58,480
con estas súper grandes agregaciones.

1461
01:03:58,480 --> 01:04:01,260
Quiero decir, tengo que tenerlas,
¿cómo nos ocupamos de ellos?

1462
01:04:01,260 --> 01:04:03,760
Tengo un muy buen caso de uso
que vamos a hablar de eso.

1463
01:04:03,760 --> 01:04:05,940
>> Muy bien, así que vamos a hablar
sobre algunos clientes ahora.

1464
01:04:05,940 --> 01:04:06,950
Estos chicos son Adroll.

1465
01:04:06,950 --> 01:04:08,990
No sé si estás
familiarizados con Adroll.

1466
01:04:08,990 --> 01:04:10,781
Es probable que los vea
mucho en el navegador.

1467
01:04:10,781 --> 01:04:14,230
Son ad re-focalización, son
el negocio más grande ad re-focalización

1468
01:04:14,230 --> 01:04:14,940
por ahí.

1469
01:04:14,940 --> 01:04:17,792
Normalmente salen regularmente sobre
60 mil millones de transacciones por día.

1470
01:04:17,792 --> 01:04:20,000
Están haciendo más de un millón
transacciones por segundo.

1471
01:04:20,000 --> 01:04:22,660
Tienen una mesa bastante simple
estructura, la mesa más concurrida.

1472
01:04:22,660 --> 01:04:26,450
Es básicamente un
clave hash es la galleta,

1473
01:04:26,450 --> 01:04:29,010
la gama es el demográfico
categoría, y luego

1474
01:04:29,010 --> 01:04:31,220
el tercer atributo es la puntuación.

1475
01:04:31,220 --> 01:04:33,720
>> Así que todos tenemos cookies
nuestro navegador de estos chicos.

1476
01:04:33,720 --> 01:04:35,900
Y cuando vas a un
comercio participante,

1477
01:04:35,900 --> 01:04:39,390
que básicamente se anotan en todo
diversas categorías demográficas.

1478
01:04:39,390 --> 01:04:42,070
Cuando vas a un sitio web y
usted dice que quiero ver esta ad--

1479
01:04:42,070 --> 01:04:44,920
o básicamente no dices que--
pero cuando vas a la página web

1480
01:04:44,920 --> 01:04:47,550
ellos dicen que usted desea ver este anuncio.

1481
01:04:47,550 --> 01:04:49,370
Y van conseguir ese anuncio de Adroll.

1482
01:04:49,370 --> 01:04:51,130
Adroll que mira hacia arriba en su mesa.

1483
01:04:51,130 --> 01:04:52,115
Ellos encuentran que su cookie.

1484
01:04:52,115 --> 01:04:53,990
Los anunciantes dicen
ellos, me quieren a alguien

1485
01:04:53,990 --> 01:04:58,632
que es de mediana edad,
Hombre de 40 años de edad, en los deportes.

1486
01:04:58,632 --> 01:05:01,590
Y te anotan en esos datos demográficos
y deciden si es o no

1487
01:05:01,590 --> 01:05:02,740
eso es un buen anuncio para ti.

1488
01:05:02,740 --> 01:05:10,330
>> Ahora tienen un SLA con
sus proveedores de publicidad

1489
01:05:10,330 --> 01:05:14,510
para proporcionar sub-10 milisegundos
respuesta en cada petición individual.

1490
01:05:14,510 --> 01:05:16,090
Así que están usando Dynamo DB para esto.

1491
01:05:16,090 --> 01:05:18,131
Ellos nos están golpeando un
millón de solicitudes por segundo.

1492
01:05:18,131 --> 01:05:21,120
Son capaces de hacer todo su
búsquedas, triage todos esos datos,

1493
01:05:21,120 --> 01:05:26,130
y conseguir que el enlace añadir de nuevo a ese
anunciante en menos de 10 milisegundos.

1494
01:05:26,130 --> 01:05:29,800
Es realmente bastante fenomenal
aplicación que tienen.

1495
01:05:29,800 --> 01:05:36,210
>> Estos chicos actually--
son éstos los chicos.

1496
01:05:36,210 --> 01:05:38,010
No estoy seguro de si se trata de estos chicos.

1497
01:05:38,010 --> 01:05:40,127
Podría ser que estos chicos.

1498
01:05:40,127 --> 01:05:42,210
Básicamente nosotros-- dije que no, me
no creo que eran ellos.

1499
01:05:42,210 --> 01:05:43,000
Creo que fue otra persona.

1500
01:05:43,000 --> 01:05:44,750
Yo estaba trabajando con un
al cliente que me dijo

1501
01:05:44,750 --> 01:05:47,040
que ahora que han
ido a Dynamo DB, son

1502
01:05:47,040 --> 01:05:50,330
gastar más dinero en bocadillos para
su equipo de desarrollo de cada mes

1503
01:05:50,330 --> 01:05:52,886
lo que gastan en su base de datos.

1504
01:05:52,886 --> 01:05:54,760
Así que él se puede dar una
idea de los ahorros de costes

1505
01:05:54,760 --> 01:05:57,889
que se puede obtener en el Dynamo DB es enorme.

1506
01:05:57,889 --> 01:05:59,430
Muy bien, Dropcam es otra compañía.

1507
01:05:59,430 --> 01:06:02,138
Estos tipo es tipo de-- si usted piensa
de Internet de las cosas, Dropcam

1508
01:06:02,138 --> 01:06:05,150
es básicamente el vídeo de seguridad de Internet.

1509
01:06:05,150 --> 01:06:06,660
Usted pone su cámara por ahí.

1510
01:06:06,660 --> 01:06:08,180
La cámara tiene un detector de movimiento.

1511
01:06:08,180 --> 01:06:10,290
Alguien viene,
desencadena un punto de referencia.

1512
01:06:10,290 --> 01:06:13,540
Cámara empieza a grabar durante un tiempo hasta
no detecta ningún movimiento más.

1513
01:06:13,540 --> 01:06:15,310
Pone ese video en el internet.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam era una empresa que es
básicamente cambiado a Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
porque estaban experimentando
enormes dolores de crecimiento.

1516
01:06:22,200 --> 01:06:25,820
Y lo que nos dijeron,
repentinamente petabytes de datos.

1517
01:06:25,820 --> 01:06:28,070
No tenían idea de su servicio
sería tan exitoso.

1518
01:06:28,070 --> 01:06:32,310
Más de vídeo de entrada de YouTube
es lo que estos chicos están recibiendo.

1519
01:06:32,310 --> 01:06:36,780
Utilizan DynamoDB seguir hasta el
metadatos en todos sus puntos clave de vídeo.

1520
01:06:36,780 --> 01:06:40,282
>> Así que tienen cubos S3 que empujan
todos los artefactos binarios en.

1521
01:06:40,282 --> 01:06:41,990
Y luego tienen
Registros Dynamo DB que

1522
01:06:41,990 --> 01:06:44,070
señalar a la gente a los tres objetos S3.

1523
01:06:44,070 --> 01:06:47,070
Cuando necesitan para mirar un video,
se ven hasta el registro en Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Hacer clic en el enlace.

1525
01:06:47,903 --> 01:06:49,770
Que tire hacia abajo el video de S3.

1526
01:06:49,770 --> 01:06:51,590
Así que eso es algo de lo que esto se parece.

1527
01:06:51,590 --> 01:06:53,580
Y esto es directamente de su equipo.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB reduce su
tiempo de entrega de eventos de vídeo

1529
01:06:56,010 --> 01:06:57,590
de cinco a 10 segundos.

1530
01:06:57,590 --> 01:07:00,470
En su tienda relacional de edad,
solían tener que ir y ejecutar

1531
01:07:00,470 --> 01:07:03,780
múltiples consultas complejas a la figura
qué vídeos para tirar abajo,

1532
01:07:03,780 --> 01:07:06,690
a menos de 50 milisegundos.

1533
01:07:06,690 --> 01:07:08,990
Así que es increíble, increíble
cuánto rendimiento

1534
01:07:08,990 --> 01:07:12,990
usted puede conseguir cuando optimizar y
sintoniza la base de datos subyacente

1535
01:07:12,990 --> 01:07:15,110
para apoyar el patrón de acceso.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, estos chicos, ¿qué es,
Fruit Ninja Supongo que es lo suyo.

1537
01:07:20,500 --> 01:07:22,590
Que todas las carreras y Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
Y estos chicos, que son una gran
equipo de desarrollo, gran desarrollo

1539
01:07:26,810 --> 01:07:27,670
Tienda.

1540
01:07:27,670 --> 01:07:29,364
>> No es un buen equipo de operaciones.

1541
01:07:29,364 --> 01:07:31,280
Ellos no tienen mucho
de los recursos de operación.

1542
01:07:31,280 --> 01:07:33,940
Ellos estaban luchando tratando de mantener
su infraestructura de aplicaciones hasta

1543
01:07:33,940 --> 01:07:34,290
y en ejecución.

1544
01:07:34,290 --> 01:07:35,000
Ellos vinieron a nosotros.

1545
01:07:35,000 --> 01:07:36,251
Se veían en ese Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Ellos dijeron, eso es para nosotros.

1547
01:07:37,291 --> 01:07:39,470
Construyeron su totalidad
marco de aplicación de la misma.

1548
01:07:39,470 --> 01:07:43,640
Algunos comentarios muy bonitos aquí
Del equipo de su capacidad

1549
01:07:43,640 --> 01:07:46,800
ahora a centrarse en la creación
el juego y no

1550
01:07:46,800 --> 01:07:49,010
tener que mantener la
infraestructura, que

1551
01:07:49,010 --> 01:07:51,910
se estaba convirtiendo en una cantidad enorme
de los gastos generales para su equipo.

1552
01:07:51,910 --> 01:07:56,170
Así que esto es algo que-- el
beneficio que se obtiene de Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Muy bien, entrar en
modelado de datos aquí.

1554
01:08:00,930 --> 01:08:03,440
Y hablamos un poco acerca de
este uno a uno, uno a muchos,

1555
01:08:03,440 --> 01:08:05,060
y muchos de muchas relaciones de tipo.

1556
01:08:05,060 --> 01:08:07,630
Y ¿cómo mantener los de Dynamo.

1557
01:08:07,630 --> 01:08:10,500
En Dynamo DB usamos
índices, hablando en general,

1558
01:08:10,500 --> 01:08:12,910
para girar los datos de
un sabor a la otra.

1559
01:08:12,910 --> 01:08:15,210
Claves hash, llaves alcance, y los índices.

1560
01:08:15,210 --> 01:08:18,540
>> En este particular,
ejemplo, como la mayoría de los estados

1561
01:08:18,540 --> 01:08:23,802
tener un requisito de licencia que
Sólo una licencia de un conductor por persona.

1562
01:08:23,802 --> 01:08:26,510
Usted no puede ir a conseguir dos controlador de
licencias en el estado de Boston.

1563
01:08:26,510 --> 01:08:27,500
Yo no puedo hacerlo en Texas.

1564
01:08:27,500 --> 01:08:28,708
Eso es algo de la manera que es.

1565
01:08:28,708 --> 01:08:32,779
Y así en el DMV, tenemos las búsquedas, que
desee buscar la licencia de conducir

1566
01:08:32,779 --> 01:08:35,180
por el número de seguro social.

1567
01:08:35,180 --> 01:08:39,990
Quiero ver los detalles de usuario
por número de licencia de conducir.

1568
01:08:39,990 --> 01:08:43,620
>> Así que puede ser que tengamos la mesa de un usuario que
tiene una clave hash en el número de serie,

1569
01:08:43,620 --> 01:08:47,830
o el número de seguro social, y
varios atributos definidos en el artículo.

1570
01:08:47,830 --> 01:08:49,859
Ahora en esa tabla I
podría definir un GSI que

1571
01:08:49,859 --> 01:08:53,370
mueve de un tirón que alrededor del que dice que quiero
una clave hash en la licencia y después

1572
01:08:53,370 --> 01:08:54,252
todos los demás artículos.

1573
01:08:54,252 --> 01:08:57,210
Ahora si quiero consultar y encontrar la
número de licencia para cualquier Social dada

1574
01:08:57,210 --> 01:08:59,609
Número de Seguro, puedo
consultar la tabla principal.

1575
01:08:59,609 --> 01:09:02,130
>> Si quiero consultar y quiero
para conseguir la seguridad social

1576
01:09:02,130 --> 01:09:05,735
número o otros atributos por una
número de licencia, puedo consultar el GSI.

1577
01:09:05,735 --> 01:09:08,689
Ese modelo es que uno
una relación.

1578
01:09:08,689 --> 01:09:12,460
Sólo un muy simple GSI,
voltear esas cosas.

1579
01:09:12,460 --> 01:09:13,979
Ahora, hablar de uno a muchos.

1580
01:09:13,979 --> 01:09:16,450
Uno de muchos es, básicamente,
su clave gama hash.

1581
01:09:16,450 --> 01:09:20,510
De dónde sacamos mucho con este
de casos de uso es datos del monitor.

1582
01:09:20,510 --> 01:09:23,880
Los datos del monitor viene en regulares
intervalo, como Internet de las cosas.

1583
01:09:23,880 --> 01:09:26,890
Siempre nos dan todos estos
registros viniendo en todo el tiempo.

1584
01:09:26,890 --> 01:09:31,420
>> Y quiero encontrar todas las lecturas
entre un período de tiempo determinado.

1585
01:09:31,420 --> 01:09:34,220
Es una consulta muy común en
infraestructura de monitoreo.

1586
01:09:34,220 --> 01:09:38,430
La manera de ir sobre que es encontrar un
sencilla estructura de la tabla, una tabla.

1587
01:09:38,430 --> 01:09:42,250
Tengo una tabla de mediciones del dispositivo
con una clave hash en el identificador de dispositivo.

1588
01:09:42,250 --> 01:09:47,340
Y tengo una clave de rango en la
marca de tiempo, o en este caso, la épica.

1589
01:09:47,340 --> 01:09:50,350
Y eso me permite ejecutar complejas
consultas en esa clave gama

1590
01:09:50,350 --> 01:09:54,950
y devolver los registros que
son en relación con el resultado

1591
01:09:54,950 --> 01:09:56,310
propuse que yo estoy buscando.

1592
01:09:56,310 --> 01:09:58,360
Y es que uno construye
a muchos relación

1593
01:09:58,360 --> 01:10:02,340
en la tabla principal utilizando la
clave hash, estructura clave gama.

1594
01:10:02,340 --> 01:10:04,600
>> Así que eso es algo construido
en la tabla de Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Cuando defino un hash
y la gama t mesa, estoy

1596
01:10:07,290 --> 01:10:09,240
la definición de una relación de uno a muchos.

1597
01:10:09,240 --> 01:10:12,770
Es una relación padre-hijo.

1598
01:10:12,770 --> 01:10:14,620
>> Vamos a hablar de muchos
a muchas relaciones.

1599
01:10:14,620 --> 01:10:19,170
Y para este ejemplo en particular,
de nuevo, vamos a utilizar GSI de.

1600
01:10:19,170 --> 01:10:23,500
Y vamos a hablar de los juegos
escenario en el que tengo un usuario determinado.

1601
01:10:23,500 --> 01:10:26,500
Quiero saber todos los juegos que
que ha registrado a favor o jugando en.

1602
01:10:26,500 --> 01:10:29,600
Y para un determinado juego, me
que desee encontrar todos los usuarios.

1603
01:10:29,600 --> 01:10:31,010
Entonces, ¿cómo lo hago?

1604
01:10:31,010 --> 01:10:34,330
Mi mesa juegos de usuario, voy
tener una clave hash del ID de usuario

1605
01:10:34,330 --> 01:10:35,810
y una clave gama del juego.

1606
01:10:35,810 --> 01:10:37,810
>> Así, un usuario puede tener varios juegos.

1607
01:10:37,810 --> 01:10:41,380
Es un uno a muchos relación entre
el usuario y los partidos en los que juega.

1608
01:10:41,380 --> 01:10:43,410
Y luego en el GSI,
Voy a la FLIP que alrededor.

1609
01:10:43,410 --> 01:10:46,679
Voy hash en el juego y
Voy a oscilar en el usuario.

1610
01:10:46,679 --> 01:10:48,970
Así que si quiero obtener toda la
juego el usuario de jugar en,

1611
01:10:48,970 --> 01:10:49,950
Voy a consultar la tabla principal.

1612
01:10:49,950 --> 01:10:52,699
Si quiero conseguir todos los usuarios
que están jugando un juego en particular,

1613
01:10:52,699 --> 01:10:53,887
Yo consultar el GSI.

1614
01:10:53,887 --> 01:10:54,970
Así que ya ves cómo hacemos esto?

1615
01:10:54,970 --> 01:10:58,369
Usted construye de estos GSI para apoyar la
de caso de uso, la aplicación, el acceso

1616
01:10:58,369 --> 01:10:59,410
patrón, la aplicación.

1617
01:10:59,410 --> 01:11:01,440
>> Si tengo que consultar en
esta dimensión, vamos

1618
01:11:01,440 --> 01:11:03,500
me crea un índice en esa dimensión.

1619
01:11:03,500 --> 01:11:05,850
Si no lo hago, no me importa.

1620
01:11:05,850 --> 01:11:09,060
Y dependiendo del caso de uso, I
puede necesitar el índice o yo no podría.

1621
01:11:09,060 --> 01:11:12,390
Si es una simple uno a muchos,
la tabla principal está muy bien.

1622
01:11:12,390 --> 01:11:15,860
Si tengo que hacer esto a muchos a
muchos de, o que tienen que hacer una para unos,

1623
01:11:15,860 --> 01:11:18,390
entonces tal vez lo necesito
al segundo índice.

1624
01:11:18,390 --> 01:11:20,840
Así que todo depende de
lo que estoy tratando de hacer

1625
01:11:20,840 --> 01:11:24,550
y lo que yo estoy tratando de conseguir consumado.

1626
01:11:24,550 --> 01:11:28,000
>> Probablemente no voy a gastar demasiado
mucho tiempo hablando de documentos.

1627
01:11:28,000 --> 01:11:31,460
Esto pone un poco, probablemente,
más profundo que tenemos que entrar.

1628
01:11:31,460 --> 01:11:33,710
Vamos a hablar un poco
sobre la rica expresión de consulta.

1629
01:11:33,710 --> 01:11:37,831
Así que en Dynamo DB tenemos
la capacidad de crear

1630
01:11:37,831 --> 01:11:39,330
lo que llamamos expresiones de proyección.

1631
01:11:39,330 --> 01:11:42,660
Expresiones de proyección son simplemente
recogiendo los campos o los valores

1632
01:11:42,660 --> 01:11:44,290
que desea mostrar.

1633
01:11:44,290 --> 01:11:46,000
OK, así que hago una selección.

1634
01:11:46,000 --> 01:11:48,010
Hago una consulta contra Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
Y digo yo, ¿sabes qué, espectáculo
me sólo las cinco estrellas comentarios

1636
01:11:51,730 --> 01:11:54,544
para este producto en particular.

1637
01:11:54,544 --> 01:11:55,710
Así que eso es todo lo que quiero ver.

1638
01:11:55,710 --> 01:11:57,320
No quiero ver a toda la
otros atributos de la fila,

1639
01:11:57,320 --> 01:11:58,319
Sólo quiero ver esto.

1640
01:11:58,319 --> 01:12:01,209
Es como en SQL cuando
decir selecto estrella o de la mesa,

1641
01:12:01,209 --> 01:12:02,000
usted consigue todo.

1642
01:12:02,000 --> 01:12:05,450
Cuando digo seleccione el nombre de
tabla, sólo tengo un atributo.

1643
01:12:05,450 --> 01:12:09,070
Es el mismo tipo de cosa en
Dynamo DB u otras bases de datos NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Expresiones Filtrar me permiten
básicamente cortar el resultado establecido.

1645
01:12:14,510 --> 01:12:15,540
Así que hago una consulta.

1646
01:12:15,540 --> 01:12:17,260
Consulta puede volver con 500 artículos.

1647
01:12:17,260 --> 01:12:20,255
Pero yo sólo quiero que los elementos que
tienen un atributo que dice esto.

1648
01:12:20,255 --> 01:12:23,380
OK, así que vamos a filtrar hacia fuera los artículos
que no concuerdan con esa consulta particular.

1649
01:12:23,380 --> 01:12:25,540
Así que tenemos expresiones de filtro.

1650
01:12:25,540 --> 01:12:28,310
>> Expresiones filtro puede
ser ejecutado en cualquier atributo.

1651
01:12:28,310 --> 01:12:30,260
No son como consultas de rango.

1652
01:12:30,260 --> 01:12:32,690
Raise consultas son más selectivos.

1653
01:12:32,690 --> 01:12:36,470
Consultas Filtrar me requieren para ir
obtener todo el conjunto de resultados y después

1654
01:12:36,470 --> 01:12:39,170
tallar los datos que yo no quiero.

1655
01:12:39,170 --> 01:12:40,660
¿Por qué es importante?

1656
01:12:40,660 --> 01:12:42,770
Porque he leído todo.

1657
01:12:42,770 --> 01:12:46,597
En una consulta, voy a leer y
que va a ser un gigante sobre los datos.

1658
01:12:46,597 --> 01:12:48,430
Y luego voy a
tallar lo que necesito.

1659
01:12:48,430 --> 01:12:52,080
Y si sólo estoy tallando un
par de filas, entonces eso está bien.

1660
01:12:52,080 --> 01:12:53,620
No es tan ineficiente.

1661
01:12:53,620 --> 01:12:57,800
>> Pero si estoy leyendo toda una pila de
datos, sólo para labrarse un artículo,

1662
01:12:57,800 --> 01:13:01,490
entonces yo voy a ser mejor
fuera mediante una consulta gama,

1663
01:13:01,490 --> 01:13:03,030
porque es mucho más selectivo.

1664
01:13:03,030 --> 01:13:06,330
Se me va a ahorrar un montón de
dinero, porque tengo que pagar por esa lectura.

1665
01:13:06,330 --> 01:13:10,430
Cuando los resultados que viene de vuelta
cruzar ese alambre podría ser más pequeño,

1666
01:13:10,430 --> 01:13:11,890
pero yo estoy pagando por la lectura.

1667
01:13:11,890 --> 01:13:14,340
Así entender cómo
que está recibiendo los datos.

1668
01:13:14,340 --> 01:13:16,420
Eso es muy importante en Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Las expresiones condicionales, esto es lo que
que se podría llamar el bloqueo optimista.

1670
01:13:19,710 --> 01:13:28,470
Actualización SI EXISTE, o si este valor
es equivalente a lo especifico.

1671
01:13:28,470 --> 01:13:31,494
Y si tengo una marca de tiempo en un
registro, podría leer los datos.

1672
01:13:31,494 --> 01:13:32,535
Yo podría cambiar esos datos.

1673
01:13:32,535 --> 01:13:35,030
Yo podría ir de escritura que
volver a la base de datos.

1674
01:13:35,030 --> 01:13:38,100
Si alguien ha cambiado el registro,
la marca de tiempo podría haber cambiado.

1675
01:13:38,100 --> 01:13:40,370
Y de esa manera mi condicional
actualización podría decir de actualización

1676
01:13:40,370 --> 01:13:42,340
Si la marca de tiempo es igual a este.

1677
01:13:42,340 --> 01:13:46,290
O la actualización fallará porque alguien
actualizado el registro en el ínterin.

1678
01:13:46,290 --> 01:13:48,290
>> Eso es lo que llamamos el bloqueo optimista.

1679
01:13:48,290 --> 01:13:50,670
Esto significa que alguien
puede entrar y cambiarla,

1680
01:13:50,670 --> 01:13:53,100
y yo voy a detectarlo
cuando vuelva a escribir.

1681
01:13:53,100 --> 01:13:56,106
Y entonces puedo realmente leído que
datos y decir, ¡oh, cambió esto.

1682
01:13:56,106 --> 01:13:57,230
Tengo que dar cuenta de eso.

1683
01:13:57,230 --> 01:14:00,490
Y puedo cambiar los datos de mi
grabar y aplicar otra actualización.

1684
01:14:00,490 --> 01:14:04,330
Así que usted puede coger los incrementales
cambios que se producen entre el momento

1685
01:14:04,330 --> 01:14:08,740
que lea los datos y la
el tiempo es posible escribir los datos.

1686
01:14:08,740 --> 01:14:11,520
>> AUDIENCIA: ¿Y el filtro
expresión en realidad no significa

1687
01:14:11,520 --> 01:14:13,020
en el número o no--

1688
01:14:13,020 --> 01:14:14,316
>> [Interponiendo VOCES]

1689
01:14:14,316 --> 01:14:16,232
RICK HOULIHAN: No lo haré
tener demasiado en esto.

1690
01:14:16,232 --> 01:14:17,700
Esta es una palabra clave reservada.

1691
01:14:17,700 --> 01:14:20,130
La vista libras es una reserva
palabra clave en Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Cada base de datos tiene su propio reservados
nombres para colecciones que no se puede utilizar.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, si especifica
una libra frente a esto,

1694
01:14:27,240 --> 01:14:29,310
puede definir los nombres arriba.

1695
01:14:29,310 --> 01:14:31,840
Este es un valor de referencia.

1696
01:14:31,840 --> 01:14:34,880
Probablemente no sea la mejor sintaxis para
tener hasta allí para esta discusión,

1697
01:14:34,880 --> 01:14:38,090
porque se mete en algunos real--
Yo he estado hablando más

1698
01:14:38,090 --> 01:14:41,360
sobre eso en un nivel más profundo.

1699
01:14:41,360 --> 01:14:46,130
>> Pero basta con decir, esto podría
sean consulta escanear donde views--

1700
01:14:46,130 --> 01:14:50,190
ni vistas libras es mayor que 10.

1701
01:14:50,190 --> 01:14:54,660
Es un valor numérico, sí.

1702
01:14:54,660 --> 01:14:57,322
Si quieres, podemos hablar de
que después de la discusión.

1703
01:14:57,322 --> 01:15:00,030
Muy bien, así que estamos metiendo
algunos escenarios en las mejores prácticas

1704
01:15:00,030 --> 01:15:02,000
donde vamos a hablar
acerca de algunas aplicaciones aquí.

1705
01:15:02,000 --> 01:15:03,810
¿Cuáles son los casos de uso para Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
¿Cuáles son el diseño
patrones en Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> Y el primero que vamos a
hablar es el Internet de las cosas.

1708
01:15:09,110 --> 01:15:15,010
Así que tenemos una gran cantidad de-- supongo,
lo que es it-- más del 50%

1709
01:15:15,010 --> 01:15:19,370
del tráfico en Internet en estos días
en realidad es generado por las máquinas,

1710
01:15:19,370 --> 01:15:21,930
procesos automatizados y no por seres humanos.

1711
01:15:21,930 --> 01:15:25,140
Quiero decir esta cosa esta cosa que
que llevas en el bolsillo,

1712
01:15:25,140 --> 01:15:28,840
la cantidad de datos que esa cosa es
enviar realmente todo sin ti

1713
01:15:28,840 --> 01:15:30,550
sabiendo que es absolutamente increíble.

1714
01:15:30,550 --> 01:15:34,970
Su ubicación, la información
acerca de qué tan rápido se va.

1715
01:15:34,970 --> 01:15:38,400
¿Cómo crees que Google Maps obras
cuando te dicen lo que el tráfico es.

1716
01:15:38,400 --> 01:15:41,275
Es porque hay millones y
millones de personas que conducen alrededor

1717
01:15:41,275 --> 01:15:44,667
con los teléfonos que están enviando
datos en todo lugar todo el tiempo.

1718
01:15:44,667 --> 01:15:46,500
Así que una de las cosas
sobre este tipo de datos

1719
01:15:46,500 --> 01:15:50,980
que viene en, datos de monitorización, registro
los datos, los datos de series de tiempo, es que es

1720
01:15:50,980 --> 01:15:53,540
por lo general sólo es interesante
por un poco de tiempo.

1721
01:15:53,540 --> 01:15:55,580
Después de ese tiempo, es
no tan interesante.

1722
01:15:55,580 --> 01:15:58,390
Así que hablamos, no dejes
esas mesas crecer sin límites.

1723
01:15:58,390 --> 01:16:03,410
La idea aquí es que a lo mejor tengo 24
horas de valor de los acontecimientos en mi mesa caliente.

1724
01:16:03,410 --> 01:16:06,160
Y esa mesa caliente va a ser
aprovisionado a un ritmo muy alto,

1725
01:16:06,160 --> 01:16:07,950
porque está teniendo una gran cantidad de datos.

1726
01:16:07,950 --> 01:16:10,920
Se trata de tomar una gran cantidad de datos
y estoy leyendo mucho.

1727
01:16:10,920 --> 01:16:14,560
Tengo un montón de funcionamiento
consultas que se ejecutan en contra de que los datos.

1728
01:16:14,560 --> 01:16:18,120
>> Después de 24 horas, bueno,
sé qué, no me importa.

1729
01:16:18,120 --> 01:16:21,150
Así que tal vez cada rollo medianoche
mi mesa a una nueva tabla

1730
01:16:21,150 --> 01:16:22,430
y yo desabastecer esta tabla.

1731
01:16:22,430 --> 01:16:26,440
Y voy a tomar de la UCR y
Abajo de WCU porque 24 horas después

1732
01:16:26,440 --> 01:16:28,630
No estoy corriendo hasta
consultas en esos datos.

1733
01:16:28,630 --> 01:16:30,200
Así que me voy a ahorrar dinero.

1734
01:16:30,200 --> 01:16:32,940
Y tal vez 30 días después no lo hago
incluso necesidad de preocuparse por todo.

1735
01:16:32,940 --> 01:16:35,020
Yo podría tomar la UMM de
todo el camino a uno,

1736
01:16:35,020 --> 01:16:36,990
porque sabes qué, es
nunca va a quedar por escrito a.

1737
01:16:36,990 --> 01:16:38,300
Los datos son de 30 días de edad.

1738
01:16:38,300 --> 01:16:40,000
Nunca cambia.

1739
01:16:40,000 --> 01:16:44,200
>> Y casi nunca va a conseguir leer,
así que vamos a tomar ese UCR hasta 10.

1740
01:16:44,200 --> 01:16:49,372
Y yo estoy ahorrando un montón de dinero en este
de datos, y sólo para pagar mis datos calientes.

1741
01:16:49,372 --> 01:16:52,330
Así que eso es lo más importante para buscar
en cuando nos fijamos en una serie temporal

1742
01:16:52,330 --> 01:16:54,716
datos que entran en el volumen.

1743
01:16:54,716 --> 01:16:55,590
Estas son estrategias.

1744
01:16:55,590 --> 01:16:58,010
Ahora, yo podría dejarlo
todos van a la misma mesa

1745
01:16:58,010 --> 01:16:59,461
y dejar que la mesa crezca.

1746
01:16:59,461 --> 01:17:01,460
Con el tiempo, voy a
ver los problemas de rendimiento.

1747
01:17:01,460 --> 01:17:04,060
Voy a tener que empezar a archivar
algunos de que los datos de la mesa,

1748
01:17:04,060 --> 01:17:04,720
cualquier cosa.

1749
01:17:04,720 --> 01:17:07,010
>> Vamos mucho mejor
diseñar la aplicación

1750
01:17:07,010 --> 01:17:08,900
para que pueda operar de esta manera derecha.

1751
01:17:08,900 --> 01:17:11,460
Así que es sólo automático
en el código de aplicación.

1752
01:17:11,460 --> 01:17:13,580
A la medianoche cada noche
rueda de la mesa.

1753
01:17:13,580 --> 01:17:17,170
Tal vez lo que necesito es un deslizamiento
ventana de 24 horas de datos.

1754
01:17:17,170 --> 01:17:20,277
A continuación, sobre una base regular estoy
llamando a los datos de la mesa.

1755
01:17:20,277 --> 01:17:22,360
Estoy recorte con un
Cron trabajo y me estoy poniendo

1756
01:17:22,360 --> 01:17:24,160
en estas otras tablas,
lo que sea que necesites.

1757
01:17:24,160 --> 01:17:25,940
Así que si un vuelco funciona, eso es genial.

1758
01:17:25,940 --> 01:17:27,080
Si no, recortarlo.

1759
01:17:27,080 --> 01:17:29,640
Pero vamos a mantener esos datos en caliente
lejos de sus datos fríos.

1760
01:17:29,640 --> 01:17:32,535
Le ahorrará mucho dinero y
hacer sus cuadros más rendimiento.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Así que lo siguiente que vamos a hablar
aproximadamente es el catálogo de productos.

1763
01:17:38,210 --> 01:17:42,000
Catálogo de productos es
caso de uso muy común.

1764
01:17:42,000 --> 01:17:46,600
Esto es en realidad un patrón muy común
que vamos a ver en una variedad de cosas.

1765
01:17:46,600 --> 01:17:48,870
Ya sabes, para Twitter
ejemplo, un tweet caliente.

1766
01:17:48,870 --> 01:17:51,280
Todo el mundo viene y
agarrando ese tweet.

1767
01:17:51,280 --> 01:17:52,680
Catálogo de productos, tengo una venta.

1768
01:17:52,680 --> 01:17:54,120
Tengo una venta caliente.

1769
01:17:54,120 --> 01:17:57,277
Tengo 70.000 solicitudes por
la segunda venida de un producto

1770
01:17:57,277 --> 01:17:58,860
Descripción de mi catálogo de productos.

1771
01:17:58,860 --> 01:18:02,384
Vemos esto en la venta al por menor
operación bastante.

1772
01:18:02,384 --> 01:18:03,550
Entonces, ¿cómo podemos hacer frente a eso?

1773
01:18:03,550 --> 01:18:04,924
No hay manera de lidiar con eso.

1774
01:18:04,924 --> 01:18:07,110
Todos mis usuarios quieren ver
la misma pieza de datos.

1775
01:18:07,110 --> 01:18:09,410
Están están llegando, al mismo tiempo.

1776
01:18:09,410 --> 01:18:11,920
Y todos están haciendo peticiones
para la misma pieza de datos.

1777
01:18:11,920 --> 01:18:16,240
Esto me da esa tecla de acceso rápido, que rojo grande
raya en mi carta que no nos gusta.

1778
01:18:16,240 --> 01:18:17,720
Y eso es lo que parece.

1779
01:18:17,720 --> 01:18:22,290
Así que a través de mi espacio de claves que estoy recibiendo
martillado en los artículos de la venta.

1780
01:18:22,290 --> 01:18:24,070
Me estoy poniendo nada en ningún otro lugar.

1781
01:18:24,070 --> 01:18:26,050
>> ¿Cómo puedo solucionar este problema?

1782
01:18:26,050 --> 01:18:28,410
Bueno, nos aliviamos esto con caché.

1783
01:18:28,410 --> 01:18:33,630
Cache, que puso básicamente un in-memory
partición en frente de la base de datos.

1784
01:18:33,630 --> 01:18:37,260
Hemos logrado
[Inaudible] caché, cómo

1785
01:18:37,260 --> 01:18:40,260
puede configurar su propia caché, [inaudible]
cache [? d,?] lo que quieras.

1786
01:18:40,260 --> 01:18:42,220
Pon eso en frente de la base de datos.

1787
01:18:42,220 --> 01:18:47,250
Y de esa manera usted puede almacenar los datos
de esas teclas de acceso rápido en ese caché

1788
01:18:47,250 --> 01:18:49,390
espacio y leer a través de la memoria caché.

1789
01:18:49,390 --> 01:18:51,962
>> Y entonces la mayoría de tus lecturas
empezar a buscar de esta manera.

1790
01:18:51,962 --> 01:18:54,920
Conseguí todos estos aciertos de caché aquí
y yo no tengo nada pasa aquí abajo

1791
01:18:54,920 --> 01:18:59,330
porque la base de datos está sentado detrás de la
caché y nunca lee vienen a través.

1792
01:18:59,330 --> 01:19:02,520
Si cambio de los datos de la
base de datos, tengo que actualizar la caché.

1793
01:19:02,520 --> 01:19:04,360
Podemos usar algo
como vapores de hacer eso.

1794
01:19:04,360 --> 01:19:07,360
Y voy a explicar cómo funciona.

1795
01:19:07,360 --> 01:19:09,060
Muy bien, la mensajería.

1796
01:19:09,060 --> 01:19:11,180
Correo electrónico, todos usamos correo electrónico.

1797
01:19:11,180 --> 01:19:12,540
>> Este es un muy buen ejemplo.

1798
01:19:12,540 --> 01:19:14,950
Tenemos una especie de tabla de mensajes.

1799
01:19:14,950 --> 01:19:17,040
Y llegamos bandeja de entrada y bandeja de salida.

1800
01:19:17,040 --> 01:19:19,760
Esto es lo que el SQL haría
parecerse a construir esa bandeja de entrada.

1801
01:19:19,760 --> 01:19:23,350
Es como que usamos el mismo tipo
de la estrategia de utilizar GSI de, GSI de

1802
01:19:23,350 --> 01:19:25,320
para mi bandeja de entrada y mi bandeja de salida.

1803
01:19:25,320 --> 01:19:27,600
Así que me dieron mensajes primas procedentes
en mi tabla de mensajes.

1804
01:19:27,600 --> 01:19:30,194
Y la primera aproximación a este
podría ser, por ejemplo, está bien, no hay problema.

1805
01:19:30,194 --> 01:19:31,110
Tengo mensajes primas.

1806
01:19:31,110 --> 01:19:33,710
Mensajes próximos [inaudible],
ID de mensaje, que es grande.

1807
01:19:33,710 --> 01:19:35,070
Esa es mi hash único.

1808
01:19:35,070 --> 01:19:38,280
Voy a crear de dos GSI de uno
para mi bandeja de entrada, uno para mi buzón de salida.

1809
01:19:38,280 --> 01:19:40,530
Y lo primero que voy a hacer
es que me voy a decir mi clave hash es

1810
01:19:40,530 --> 01:19:43,310
va a ser el receptor y
Voy a organizar en la fecha.

1811
01:19:43,310 --> 01:19:44,220
Esto es fantástico.

1812
01:19:44,220 --> 01:19:45,890
Tengo mi bonita vista aquí.

1813
01:19:45,890 --> 01:19:47,780
Pero hay un pequeño problema aquí.

1814
01:19:47,780 --> 01:19:50,891
Y llegas a tener esto en
bases de datos relacionales, así.

1815
01:19:50,891 --> 01:19:52,390
Llamaron a la partición vertical.

1816
01:19:52,390 --> 01:19:55,840
Usted quiere mantener sus datos grande
lejos de sus pocos datos.

1817
01:19:55,840 --> 01:20:00,470
>> Y la razón es porque tengo que
ve a leer los artículos para obtener los atributos.

1818
01:20:00,470 --> 01:20:05,570
Y si mis órganos son todos aquí,
luego de leer unos pocos artículos

1819
01:20:05,570 --> 01:20:08,560
si mi longitud del cuerpo es
un promedio de 256 kilobytes cada uno,

1820
01:20:08,560 --> 01:20:10,991
las matemáticas se pone muy fea.

1821
01:20:10,991 --> 01:20:12,490
Así que digo quiero leer la bandeja de entrada de David.

1822
01:20:12,490 --> 01:20:14,520
Bandeja de entrada de David tiene 50 artículos.

1823
01:20:14,520 --> 01:20:17,880
El promedio y el tamaño es de 256 kilobytes.

1824
01:20:17,880 --> 01:20:21,730
Aquí está mi relación de conversión
para la UCR de es cuatro kilobytes.

1825
01:20:21,730 --> 01:20:24,450
>> OK, vamos a ir con
lee finalmente consistente.

1826
01:20:24,450 --> 01:20:28,640
Todavía estoy comiendo 1600 RCU de
sólo para leer la bandeja de entrada de David.

1827
01:20:28,640 --> 01:20:29,950
Ay.

1828
01:20:29,950 --> 01:20:31,980
Bien, ahora vamos a pensar
acerca de cómo funciona la aplicación.

1829
01:20:31,980 --> 01:20:35,340
Si estoy en una aplicación de correo electrónico y
Estoy buscando a mi bandeja de entrada,

1830
01:20:35,340 --> 01:20:39,680
y miro el cuerpo de cada mensaje,
no, yo estoy mirando a los resúmenes.

1831
01:20:39,680 --> 01:20:41,850
Estoy mirando sólo los encabezados.

1832
01:20:41,850 --> 01:20:46,310
Así que vamos a construir una estructura de tabla
que se parece más a eso.

1833
01:20:46,310 --> 01:20:49,470
>> Así que aquí está la información
que mi flujo de trabajo necesita.

1834
01:20:49,470 --> 01:20:50,890
Está en mi bandeja de entrada de GSI.

1835
01:20:50,890 --> 01:20:53,800
Es la fecha, el remitente,
el tema, y ​​luego

1836
01:20:53,800 --> 01:20:56,790
el ID de mensaje, que apunta
volver a la tabla de mensajes

1837
01:20:56,790 --> 01:20:57,850
donde puedo conseguir el cuerpo.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Bueno, estos serían los ID de registro.

1840
01:21:04,420 --> 01:21:09,850
Ellos señalar de nuevo a la
ID de elementos sobre la mesa Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Cada índice siempre creates--
siempre tiene el elemento

1842
01:21:12,220 --> 01:21:15,750
ID como parte de-- que
viene con el índice.

1843
01:21:15,750 --> 01:21:17,414
>> Correcto.

1844
01:21:17,414 --> 01:21:19,080
AUDIENCIA: Se dice que donde se almacena?

1845
01:21:19,080 --> 01:21:21,420
RICK HOULIHAN: Sí, dice
exactly-- eso es exactamente lo que hace.

1846
01:21:21,420 --> 01:21:22,644
Se dice que aquí está mi disco re.

1847
01:21:22,644 --> 01:21:24,310
Y que va a señalar de nuevo a mi disco re.

1848
01:21:24,310 --> 01:21:26,460
Exactamente.

1849
01:21:26,460 --> 01:21:29,490
OK, así que ahora mi bandeja de entrada es
en realidad mucho más pequeño.

1850
01:21:29,490 --> 01:21:32,210
Y esto apoya realidad
el flujo de trabajo de una aplicación de correo electrónico.

1851
01:21:32,210 --> 01:21:34,230
Así que mi bandeja de entrada, hago clic.

1852
01:21:34,230 --> 01:21:38,160
Que avanzo y hago clic en el mensaje,
eso es cuando tengo que ir a buscar el cuerpo,

1853
01:21:38,160 --> 01:21:40,180
porque yo voy a
ir a un punto de vista diferente.

1854
01:21:40,180 --> 01:21:43,870
Así que si usted piensa sobre el tipo de MVC
marco, modelo vista controlador.

1855
01:21:43,870 --> 01:21:46,120
>> El modelo contiene la
datos que las necesidades vista

1856
01:21:46,120 --> 01:21:48,130
y el controlador interactúa con.

1857
01:21:48,130 --> 01:21:51,670
Cuando cambio la trama, al
Puedo cambiar la perspectiva,

1858
01:21:51,670 --> 01:21:55,080
que está bien para volver a la
servidor y repoblar el modelo,

1859
01:21:55,080 --> 01:21:56,860
porque eso es lo que espera el usuario.

1860
01:21:56,860 --> 01:22:00,530
Cuando cambian puntos de vista, que es cuando
podemos volver a la base de datos.

1861
01:22:00,530 --> 01:22:02,480
Así de correo electrónico, haga clic en.

1862
01:22:02,480 --> 01:22:03,710
Estoy buscando el cuerpo.

1863
01:22:03,710 --> 01:22:04,330
Ida y vuelta.

1864
01:22:04,330 --> 01:22:05,680
Ve a buscar el cuerpo.

1865
01:22:05,680 --> 01:22:06,950
>> Leo mucho menos datos.

1866
01:22:06,950 --> 01:22:09,960
Yo sólo estoy leyendo los cuerpos que
David necesita cuando las necesita.

1867
01:22:09,960 --> 01:22:14,230
Y no me quemo en 1600
UCR de simplemente para mostrar su bandeja de entrada.

1868
01:22:14,230 --> 01:22:17,670
Así que ahora que-- este es el camino
que LSI o GSI-- lo siento,

1869
01:22:17,670 --> 01:22:19,900
GSI, iba a salir.

1870
01:22:19,900 --> 01:22:25,450
Tenemos nuestra hachís en el destinatario.

1871
01:22:25,450 --> 01:22:27,030
Tenemos la llave de rango en la fecha.

1872
01:22:27,030 --> 01:22:31,380
Y tenemos los atributos proyectados
que sólo tenemos que apoyar a la vista.

1873
01:22:31,380 --> 01:22:34,300
>> Giramos por que en el buzón de salida.

1874
01:22:34,300 --> 01:22:35,770
Hash en el remitente.

1875
01:22:35,770 --> 01:22:39,612
Y en esencia, tenemos
la muy agradable, vista limpia.

1876
01:22:39,612 --> 01:22:41,570
Y es que basically--
tener este agradable mensajes

1877
01:22:41,570 --> 01:22:45,870
tabla que está siendo difundido muy bien porque
es sólo hachís, ID de mensaje hash.

1878
01:22:45,870 --> 01:22:51,750
Y tenemos dos índices que
están girando fuera de dicho cuadro.

1879
01:22:51,750 --> 01:22:57,411
Muy bien, así que la idea aquí no es hacer
mantener a los grandes datos y esta pequeña datos

1880
01:22:57,411 --> 01:22:57,910
juntos.

1881
01:22:57,910 --> 01:23:00,700
Partición vertical,
particionar las tablas.

1882
01:23:00,700 --> 01:23:03,150
No lea los datos que usted no tiene que.

1883
01:23:03,150 --> 01:23:04,850
Muy bien, los juegos.

1884
01:23:04,850 --> 01:23:06,990
A todos nos gusta los juegos.

1885
01:23:06,990 --> 01:23:10,902
Por lo menos me gustan los juegos entonces.

1886
01:23:10,902 --> 01:23:12,735
Así que algunas de las cosas
que nos ocupamos cuando

1887
01:23:12,735 --> 01:23:14,193
estamos pensando en el juego, ¿no?

1888
01:23:14,193 --> 01:23:16,999
Gaming estos días, especialmente móvil
juegos, tiene que ver con el pensamiento.

1889
01:23:16,999 --> 01:23:19,540
Y voy a girar aquí
poco lejos de DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Voy a traer
Parte de la discusión

1891
01:23:21,373 --> 01:23:24,240
alrededor de algunos de los
otras tecnologías de AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Pero la idea de juego es pensar
acerca en términos de API, API que son,

1893
01:23:28,930 --> 01:23:31,730
en términos generales, HTTP y JSON.

1894
01:23:31,730 --> 01:23:34,550
Es la forma de juegos móviles tipo de
interactuar con sus extremos traseros.

1895
01:23:34,550 --> 01:23:35,850
Lo hacen JSON publicación.

1896
01:23:35,850 --> 01:23:40,660
Obtienen los datos, y es todo,
en términos generales, en las API JSON agradables.

1897
01:23:40,660 --> 01:23:44,950
>> Cosas como conseguir amigos, consiguen
los datos de la tabla de posiciones, de cambio,

1898
01:23:44,950 --> 01:23:47,699
contenido generado por el usuario,
hacer retroceder al sistema,

1899
01:23:47,699 --> 01:23:49,740
estos son los tipos de cosas
que vamos a hacer.

1900
01:23:49,740 --> 01:23:52,542
Datos activo binario, estos datos
podría no sentarse en la base de datos.

1901
01:23:52,542 --> 01:23:54,250
Esto podría sentarse en una
almacén de objetos, ¿verdad?

1902
01:23:54,250 --> 01:23:56,541
Pero la base de datos se va a
terminar diciendo al sistema,

1903
01:23:56,541 --> 01:23:59,140
diciendo la aplicación
dónde ir a buscarlo.

1904
01:23:59,140 --> 01:24:03,550
E inevitablemente, multijugador
servidores, infraestructura back-end,

1905
01:24:03,550 --> 01:24:06,180
y diseñado para alta
disponibilidad y escalabilidad.

1906
01:24:06,180 --> 01:24:09,400
Así que estas son las cosas que todos queremos
en la infraestructura de juego hoy.

1907
01:24:09,400 --> 01:24:12,160
>> Así que echemos un vistazo a
lo que parece.

1908
01:24:12,160 --> 01:24:16,070
Consiguió un extremo posterior del núcleo,
muy sencillo.

1909
01:24:16,070 --> 01:24:19,880
Tenemos un sistema de aquí con
múltiples zonas de disponibilidad.

1910
01:24:19,880 --> 01:24:23,780
Hablamos de AZS como being-- pensar
de ellos como centros de datos independientes.

1911
01:24:23,780 --> 01:24:26,040
Más de un centro de datos
por AZ, pero eso está bien,

1912
01:24:26,040 --> 01:24:28,831
sólo pensar en ellos como datos independiente
centros que están geográficamente

1913
01:24:28,831 --> 01:24:30,090
y se aisló fallo.

1914
01:24:30,090 --> 01:24:32,172
>> Vamos a tener un
casos pareja EC2.

1915
01:24:32,172 --> 01:24:33,880
Vamos a tener
algún servidor back-end.

1916
01:24:33,880 --> 01:24:35,800
Tal vez si usted es un legado
arquitectura, estamos

1917
01:24:35,800 --> 01:24:38,920
utilizando lo que llamamos RDS,
servicios de bases de datos relacionales.

1918
01:24:38,920 --> 01:24:42,040
Podría ser MSSQL, MySQL,
o algo así.

1919
01:24:42,040 --> 01:24:47,080
Esta es la manera muchas de las aplicaciones
hoy son diseñados.

1920
01:24:47,080 --> 01:24:49,594
>> Bien podríamos desear ir con
esto es cuando escalamos a cabo.

1921
01:24:49,594 --> 01:24:51,510
Vamos a seguir adelante y poner
el cubo S3 hasta allí.

1922
01:24:51,510 --> 01:24:54,200
Y ese cubo S3, en vez de servir
hasta los objetos de nuestro servers--

1923
01:24:54,200 --> 01:24:55,220
podríamos hacer eso.

1924
01:24:55,220 --> 01:24:57,210
Pones toda tu binaria
objetos en sus servidores

1925
01:24:57,210 --> 01:24:59,751
y puede utilizar los servidores
casos para servir que los datos arriba.

1926
01:24:59,751 --> 01:25:01,860
Pero eso es bastante caro.

1927
01:25:01,860 --> 01:25:05,107
>> Mejor manera de hacerlo es seguir adelante y
poner los objetos en un cubo de S3.

1928
01:25:05,107 --> 01:25:06,315
S3 es una repositorios de objetos.

1929
01:25:06,315 --> 01:25:10,860
Está construido específicamente para
sirviendo este tipo de cosas.

1930
01:25:10,860 --> 01:25:13,690
Y que solicitan los clientes
directamente desde esos cubos de objeto,

1931
01:25:13,690 --> 01:25:15,390
descargar los servidores.

1932
01:25:15,390 --> 01:25:17,020
Así que estamos empezando a escalar aquí.

1933
01:25:17,020 --> 01:25:19,140
>> Ahora que tenemos los usuarios de todo el mundo.

1934
01:25:19,140 --> 01:25:19,730
Tengo usuarios.

1935
01:25:19,730 --> 01:25:23,380
Necesito tener contenido localmente
situado cerca de estos usuarios, ¿no?

1936
01:25:23,380 --> 01:25:26,200
He creado un cubo S3
como mi repositorio de código fuente.

1937
01:25:26,200 --> 01:25:29,370
Y voy a frente que con
la distribución CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront es un CD y un
Red de entrega de contenidos.

1939
01:25:31,720 --> 01:25:35,750
Básicamente se toma los datos que especifique
y almacena en caché todo en internet

1940
01:25:35,750 --> 01:25:39,230
para que los usuarios de todo el mundo pueden tener
una respuesta muy rápida cuando

1941
01:25:39,230 --> 01:25:40,960
solicitan esos objetos.

1942
01:25:40,960 --> 01:25:41,960
>> Para que pueda obtener una idea.

1943
01:25:41,960 --> 01:25:48,230
Estás tipo de aprovechamiento de todo el
aspectos de AWS aquí para hacer esto.

1944
01:25:48,230 --> 01:25:50,790
Y finalmente, nos tiramos
en un grupo de escala automática.

1945
01:25:50,790 --> 01:25:52,737
Así que nuestros casos AC2
de nuestros servidores de juego,

1946
01:25:52,737 --> 01:25:54,820
cuando empiezan a conseguir más concurrido
y cada vez más ocupado,

1947
01:25:54,820 --> 01:25:57,236
ellos sólo hacen girar otra
ejemplo, girar otra instancia,

1948
01:25:57,236 --> 01:25:58,210
girar otra instancia.

1949
01:25:58,210 --> 01:26:02,090
Así que la tecnología AWS tiene, es
le permite especificar los parámetros

1950
01:26:02,090 --> 01:26:04,650
alrededor de la cual los servidores crecerá.

1951
01:26:04,650 --> 01:26:08,110
Así que usted puede tener un número n de servidores
por ahí en un momento dado.

1952
01:26:08,110 --> 01:26:11,870
Y si la carga se va, que va a
reducir el tamaño, el número se reducirá.

1953
01:26:11,870 --> 01:26:15,250
Y si la carga se vuelve,
que va a volver a crecer hacia fuera, elásticamente.

1954
01:26:15,250 --> 01:26:17,050
>> Así que esto se ve muy bien.

1955
01:26:17,050 --> 01:26:19,800
Tenemos una gran cantidad de instancias de EC2.

1956
01:26:19,800 --> 01:26:21,671
Podemos poner en caché
delante de las bases de datos,

1957
01:26:21,671 --> 01:26:23,045
tratar de acelerar las bases de datos.

1958
01:26:23,045 --> 01:26:25,030
El siguiente punto de presión
normalmente la gente ve

1959
01:26:25,030 --> 01:26:28,850
es que la escala de un juego utilizando un
sistema de base de datos relacional.

1960
01:26:28,850 --> 01:26:30,790
Por Dios, la base de datos
rendimiento es terrible.

1961
01:26:30,790 --> 01:26:31,932
¿Cómo podemos mejorar eso?

1962
01:26:31,932 --> 01:26:33,640
Vamos a tratar de poner
caché frente a eso.

1963
01:26:33,640 --> 01:26:36,780
>> Bueno, caché no funciona
tan grande en los juegos, ¿verdad?

1964
01:26:36,780 --> 01:26:39,330
Para los juegos, la escritura es doloroso.

1965
01:26:39,330 --> 01:26:40,930
Los juegos son muy escriben pesado.

1966
01:26:40,930 --> 01:26:43,610
Caché no funciona cuando estás
escribir pesada porque tienes siempre

1967
01:26:43,610 --> 01:26:44,610
tiene que actualizar la caché.

1968
01:26:44,610 --> 01:26:47,780
Actualiza la caché, es
irrelevante para ser el almacenamiento en caché.

1969
01:26:47,780 --> 01:26:49,780
En realidad es solo un trabajo extra.

1970
01:26:49,780 --> 01:26:51,970
>> Entonces, ¿dónde vamos aquí?

1971
01:26:51,970 --> 01:26:54,400
Tienes un gran cuello de botella
allá en la base de datos.

1972
01:26:54,400 --> 01:26:57,661
Y el lugar para ir
obviamente está particionado.

1973
01:26:57,661 --> 01:26:59,410
La partición no es
fácil de hacer cuando estás

1974
01:26:59,410 --> 01:27:01,900
se trata de bases de datos relacionales.

1975
01:27:01,900 --> 01:27:05,080
Con las bases de datos relacionales, eres
responsable de la gestión, de manera efectiva,

1976
01:27:05,080 --> 01:27:06,210
el espacio de claves.

1977
01:27:06,210 --> 01:27:10,527
¿Estás diciendo que los usuarios entre A y M
ir aquí, entre N y Z van allí.

1978
01:27:10,527 --> 01:27:12,360
Y usted está cambiando
a través de la aplicación.

1979
01:27:12,360 --> 01:27:15,000
Así que usted está tratando con
esta fuente de datos de la partición.

1980
01:27:15,000 --> 01:27:18,670
Usted tiene limitaciones transaccionales
que no abarcan las particiones.

1981
01:27:18,670 --> 01:27:20,560
Tienes todo tipo de
desorden que eres

1982
01:27:20,560 --> 01:27:23,040
se trata de ahí abajo tratando
para hacer frente a escalar

1983
01:27:23,040 --> 01:27:25,120
y la construcción de una infraestructura más grande.

1984
01:27:25,120 --> 01:27:27,284
Es simplemente no es divertido.

1985
01:27:27,284 --> 01:27:30,930
>> AUDIENCIA: Entonces, ¿estás diciendo que
aumentando los puntos de origen acelera

1986
01:27:30,930 --> 01:27:31,430
¿el proceso?

1987
01:27:31,430 --> 01:27:32,513
RICK HOULIHAN: El aumento?

1988
01:27:32,513 --> 01:27:33,520
Puntos Fuente: AUDIENCIA.

1989
01:27:33,520 --> 01:27:34,410
RICK HOULIHAN: puntos de origen?

1990
01:27:34,410 --> 01:27:37,500
AUDIENCIA: A partir de la información,
donde la información está viniendo?

1991
01:27:37,500 --> 01:27:38,250
RICK HOULIHAN: No.

1992
01:27:38,250 --> 01:27:41,820
Lo que estoy diciendo es el aumento de la
número de particiones en el almacén de datos

1993
01:27:41,820 --> 01:27:44,060
mejora el rendimiento.

1994
01:27:44,060 --> 01:27:48,300
Entonces, ¿qué está pasando aquí es que los usuarios
que entra en la instancia EC2 aquí,

1995
01:27:48,300 --> 01:27:50,780
así, si necesito un usuario
esa es la A a la M, voy a ir aquí.

1996
01:27:50,780 --> 01:27:53,560
Desde N hasta p, voy a ir aquí.

1997
01:27:53,560 --> 01:27:55,060
Desde P hasta Z, voy a ir aquí.

1998
01:27:55,060 --> 01:27:57,120
>> AUDIENCIA: OK, así que esos son los
todos los almacenados en diferentes nodos?

1999
01:27:57,120 --> 01:27:57,911
>> RICK HOULIHAN: Sí.

2000
01:27:57,911 --> 01:28:00,210
Piense en esto como
diferentes silos de datos.

2001
01:28:00,210 --> 01:28:01,660
Así que tienes que hacer esto.

2002
01:28:01,660 --> 01:28:02,910
Si usted está tratando de hacer
esto, si usted está tratando

2003
01:28:02,910 --> 01:28:05,730
a escala en una plataforma relacional,
esto es lo que estás haciendo.

2004
01:28:05,730 --> 01:28:08,100
Usted está tomando los datos y
que está a cortarlo.

2005
01:28:08,100 --> 01:28:10,975
Y usted está al otro lado de la partición
varias instancias de la base de datos.

2006
01:28:10,975 --> 01:28:13,580
Y va a administrar todo lo que
en el nivel de aplicación.

2007
01:28:13,580 --> 01:28:14,729
No es divertido.

2008
01:28:14,729 --> 01:28:15,770
Entonces, ¿qué es lo que queremos ir?

2009
01:28:15,770 --> 01:28:20,240
Queremos ir DynamoDB, logró plenamente,
Almacén de datos NoSQL, rendimiento disposición.

2010
01:28:20,240 --> 01:28:22,680
Utilizamos índices secundarios.

2011
01:28:22,680 --> 01:28:26,154
Se trata básicamente de HTTP API y
incluye soporte de documentos.

2012
01:28:26,154 --> 01:28:28,570
Así que usted no tiene que preocuparse
nada de eso partición.

2013
01:28:28,570 --> 01:28:30,740
Lo hacemos todo por usted.

2014
01:28:30,740 --> 01:28:33,260
Así que ahora, en cambio,
simplemente escribir en la tabla.

2015
01:28:33,260 --> 01:28:36,490
Si la tabla tiene que ser dividido,
eso sucede detrás de las escenas.

2016
01:28:36,490 --> 01:28:40,642
Usted está completamente aislado
de que como desarrollador.

2017
01:28:40,642 --> 01:28:42,350
Así que vamos a hablar de
algunos de los casos de uso

2018
01:28:42,350 --> 01:28:47,564
que nos encontramos en los juegos, común
escenarios de juego, tabla de clasificación.

2019
01:28:47,564 --> 01:28:49,980
Así que tienes a los usuarios a llegar,
los BoardNames que son

2020
01:28:49,980 --> 01:28:52,930
en adelante, las calificaciones de este usuario.

2021
01:28:52,930 --> 01:28:57,700
Podríamos estar hash en la identificación de usuario,
y luego tenemos variedad en el juego.

2022
01:28:57,700 --> 01:28:59,960
Así que cada usuario quiere ver
todo el juego que ha jugado

2023
01:28:59,960 --> 01:29:01,770
y toda su puntuación más alta
a través de todo el juego.

2024
01:29:01,770 --> 01:29:04,000
Así que ese es su clasificación personal.

2025
01:29:04,000 --> 01:29:10,010
>> Ahora quiero ir y quiero get--
por lo que obtener estas tablas de clasificación personales.

2026
01:29:10,010 --> 01:29:12,827
Lo que quiero hacer es ir a buscar
la puntuación más alta entre todos los usuarios.

2027
01:29:12,827 --> 01:29:13,660
Entonces, ¿cómo lo hago?

2028
01:29:13,660 --> 01:29:18,070
Cuando se hash en mi disco
la ID de usuario, osciló en el juego,

2029
01:29:18,070 --> 01:29:20,740
así que voy a seguir adelante
y reestructurar, crear un GSI,

2030
01:29:20,740 --> 01:29:22,370
y yo voy a reestructurar esos datos.

2031
01:29:22,370 --> 01:29:27,310
>> Ahora me voy para discutir sobre la
BoardName, que es el juego.

2032
01:29:27,310 --> 01:29:29,800
Y yo voy a ir a la puntuación más alta.

2033
01:29:29,800 --> 01:29:31,540
Y ahora que he creado diferentes cubos.

2034
01:29:31,540 --> 01:29:34,790
Estoy usando la misma mesa,
los mismos datos del elemento.

2035
01:29:34,790 --> 01:29:39,870
Pero estoy creando un cubo que da
me una agregación de puntuación máxima por juego.

2036
01:29:39,870 --> 01:29:43,180
>> Y puedo consultar esa mesa
para obtener esa información.

2037
01:29:43,180 --> 01:29:50,890
Así que me he fijado que el patrón de consulta hasta
con el apoyo de un índice secundario.

2038
01:29:50,890 --> 01:29:54,556
Ahora pueden ordenarse por BoardName
y ordenados por topscore, dependiendo.

2039
01:29:54,556 --> 01:29:57,180
Así se puede ver, se trata de tipos
de los casos de uso que obtiene en los videojuegos.

2040
01:29:57,180 --> 01:30:02,190
Otro buen caso de uso que obtenemos en los juegos
es premios y que ha ganado los premios.

2041
01:30:02,190 --> 01:30:05,340
Y este es un gran caso de uso
donde nos llamamos índices dispersos.

2042
01:30:05,340 --> 01:30:07,340
Escasos son los índices
capacidad de generar

2043
01:30:07,340 --> 01:30:10,850
un índice que no necesariamente
contener cada artículo sobre la mesa.

2044
01:30:10,850 --> 01:30:11,470
¿Y por qué no?

2045
01:30:11,470 --> 01:30:14,540
Debido a que el atributo que está siendo
indexada no existe en cada artículo.

2046
01:30:14,540 --> 01:30:16,460
>> Así que en este particular,
caso de uso, lo que estoy diciendo,

2047
01:30:16,460 --> 01:30:19,240
Sabes qué, voy a
crear un atributo llamado Premio.

2048
01:30:19,240 --> 01:30:22,970
Y yo voy a dar a cada usuario
que tiene un premio que atribuyen.

2049
01:30:22,970 --> 01:30:25,950
Los usuarios que no tienen premios son
No va a tener ese atributo.

2050
01:30:25,950 --> 01:30:27,800
Así que cuando creo el
índice, los únicos usuarios

2051
01:30:27,800 --> 01:30:28,960
que se van a mostrar
en el índice son

2052
01:30:28,960 --> 01:30:31,050
los que realmente han ganado premios.

2053
01:30:31,050 --> 01:30:34,440
Así que eso es una gran manera de poder
para crear índices filtrados que

2054
01:30:34,440 --> 01:30:40,580
son muy, muy selectivo que no lo hacen
que índice de toda la tabla.

2055
01:30:40,580 --> 01:30:43,050
>> Así que nos estamos bajo el tiempo aquí.

2056
01:30:43,050 --> 01:30:49,190
Voy a seguir adelante y saltar
y omitir este escenario.

2057
01:30:49,190 --> 01:30:52,625
Hable un poco sobre--

2058
01:30:52,625 --> 01:30:54,460
>> AUDIENCIA: ¿Puedo hacer una pregunta rápida?

2059
01:30:54,460 --> 01:30:56,722
Uno es escribir pesado?

2060
01:30:56,722 --> 01:30:57,680
RICK HOULIHAN: ¿Qué es?

2061
01:30:57,680 --> 01:30:58,596
AUDIENCIA: Escriba pesado.

2062
01:30:58,596 --> 01:31:01,270
RICK HOULIHAN: Escribir pesado.

2063
01:31:01,270 --> 01:31:03,460
Déjame ver.

2064
01:31:03,460 --> 01:31:06,220
>> AUDIENCIA: ¿O es que no
algo que usted puede simplemente

2065
01:31:06,220 --> 01:31:08,809
voz a en cuestión de segundos?

2066
01:31:08,809 --> 01:31:10,850
RICK HOULIHAN: Vamos
a través del escenario electoral.

2067
01:31:10,850 --> 01:31:11,670
No está tan mal.

2068
01:31:11,670 --> 01:31:14,580
¿Ustedes tienen un par de minutos?

2069
01:31:14,580 --> 01:31:15,860
OKAY.

2070
01:31:15,860 --> 01:31:17,890
>> Así que vamos a hablar acerca de la votación.

2071
01:31:17,890 --> 01:31:20,250
Así que la votación en tiempo real, tenemos
requisitos para votar.

2072
01:31:20,250 --> 01:31:25,250
Los requisitos son que permitamos
cada persona a votar sólo una vez.

2073
01:31:25,250 --> 01:31:28,060
Queremos que nadie sea capaz
cambiar su voto.

2074
01:31:28,060 --> 01:31:31,045
Queremos que la agregación en tiempo real
y el análisis de datos demográficos

2075
01:31:31,045 --> 01:31:34,210
que nosotros vamos a ser
mostrando a los usuarios en el sitio.

2076
01:31:34,210 --> 01:31:35,200
>> Piense en este escenario.

2077
01:31:35,200 --> 01:31:37,550
Trabajamos mucho de la realidad
Programas de televisión donde están

2078
01:31:37,550 --> 01:31:38,960
haciendo este tipo exacto de las cosas.

2079
01:31:38,960 --> 01:31:41,584
Así que usted puede pensar en el escenario,
tenemos millones y millones

2080
01:31:41,584 --> 01:31:43,959
niñas de adolescentes allí
con sus teléfonos celulares

2081
01:31:43,959 --> 01:31:46,250
y el voto, y la votación, y
votar por quienquiera que sean

2082
01:31:46,250 --> 01:31:48,610
encontrar a ser el más popular.

2083
01:31:48,610 --> 01:31:50,830
Así que estos son algunos de los
requisitos que se agoten.

2084
01:31:50,830 --> 01:31:52,990
>> Y así, la primera toma
en la solución de este problema

2085
01:31:52,990 --> 01:31:55,090
sería la de construir un
aplicación muy simple.

2086
01:31:55,090 --> 01:31:56,490
Así que tengo esta aplicación.

2087
01:31:56,490 --> 01:31:57,950
Tengo algunos votantes que hay.

2088
01:31:57,950 --> 01:31:59,980
Vienen en, que lleguen a la aplicación de la votación.

2089
01:31:59,980 --> 01:32:03,440
Tengo un poco de mesa califican prima
Sólo voy a volcar esos votos en.

2090
01:32:03,440 --> 01:32:05,780
Voy a tener algún agregado
mesa de votos que

2091
01:32:05,780 --> 01:32:09,490
Haré mi análisis y los datos demográficos,
y vamos a poner todo esto en ese país.

2092
01:32:09,490 --> 01:32:11,420
>> Y esto es muy bueno.

2093
01:32:11,420 --> 01:32:12,332
La vida es buena.

2094
01:32:12,332 --> 01:32:15,040
De buena hasta que nos damos cuenta que la vida
siempre hay uno o dos

2095
01:32:15,040 --> 01:32:16,879
las personas que son populares en una elección.

2096
01:32:16,879 --> 01:32:19,420
Hay sólo una o dos cosas
que la gente realmente se preocupan.

2097
01:32:19,420 --> 01:32:22,340
Y si usted está votando en
escala, de repente estoy

2098
01:32:22,340 --> 01:32:26,360
va a estar golpeando a la mierda de
dos candidatos, uno o dos candidatos.

2099
01:32:26,360 --> 01:32:29,390
Un número muy limitado de artículos
personas encuentran para ser popular.

2100
01:32:29,390 --> 01:32:31,710
>> Este no es un buen patrón de diseño.

2101
01:32:31,710 --> 01:32:33,549
Esto es realmente una
patrón de diseño muy malo

2102
01:32:33,549 --> 01:32:36,340
porque crea exactamente lo que
habló de que era teclas de acceso rápido.

2103
01:32:36,340 --> 01:32:38,960
Teclas de acceso son algo que no nos gusta.

2104
01:32:38,960 --> 01:32:40,470
>> Entonces, ¿cómo solucionarlo?

2105
01:32:40,470 --> 01:32:47,640
Y realmente, la forma de solucionar este problema es
mediante la adopción de esos cubos candidatos

2106
01:32:47,640 --> 01:32:51,490
y para cada candidato que tenemos,
vamos a añadir un valor aleatorio,

2107
01:32:51,490 --> 01:32:54,192
algo que sabemos, al azar
valor entre uno y 100,

2108
01:32:54,192 --> 01:32:56,620
entre 100 y 1.000,
o entre uno y 1.000,

2109
01:32:56,620 --> 01:32:59,940
Sin embargo muchos valores aleatorios que quieren
anexar en el extremo de ese candidato.

2110
01:32:59,940 --> 01:33:01,330
>> Y ¿qué he hecho realmente entonces?

2111
01:33:01,330 --> 01:33:05,830
Si estoy usando el ID de candidato
el cubo a los votos totales,

2112
01:33:05,830 --> 01:33:08,780
si he añadido un azar
número al final de eso,

2113
01:33:08,780 --> 01:33:12,000
He creado ahora 10 cubos, un
cien cubos, mil cubos

2114
01:33:12,000 --> 01:33:14,160
que estoy agregando califican de ancho.

2115
01:33:14,160 --> 01:33:18,030
>> Así que tengo millones y millones,
y millones de registros procedentes de

2116
01:33:18,030 --> 01:33:22,050
para estos candidatos, ahora estoy difundiendo
esos votos en todo A_1 Candidato

2117
01:33:22,050 --> 01:33:24,630
a través A_100 Candidato, porque
cada vez que un voto entra,

2118
01:33:24,630 --> 01:33:26,530
Estoy generando un azar
valor entre uno y 100.

2119
01:33:26,530 --> 01:33:29,446
Estoy viradas sobre el extremo de la
candidato a esa persona de votar a favor.

2120
01:33:29,446 --> 01:33:31,120
Estoy de dumping en ese cubo.

2121
01:33:31,120 --> 01:33:33,910
>> Ahora en la parte trasera, lo sé
que me dieron cien cubos.

2122
01:33:33,910 --> 01:33:36,350
Así que cuando me quiero ir por delante
y agregar los votos,

2123
01:33:36,350 --> 01:33:38,244
He leído de todos los cubos.

2124
01:33:38,244 --> 01:33:39,160
Así que sigo adelante y añadir.

2125
01:33:39,160 --> 01:33:42,410
Y entonces yo recojo la dispersión
donde salgo y digo bueno,

2126
01:33:42,410 --> 01:33:45,399
usted sabe lo que, la clave de este candidato
espacios es más de cien cubos.

2127
01:33:45,399 --> 01:33:47,940
Voy a reunir toda la
los votos de los cien cubos.

2128
01:33:47,940 --> 01:33:49,981
Voy a agregar
ellos y voy a decir,

2129
01:33:49,981 --> 01:33:53,830
Candidato A tiene ahora
recuento total de votos de x.

2130
01:33:53,830 --> 01:33:55,690
>> Ahora tanto la escritura
consulta y la consulta de lectura

2131
01:33:55,690 --> 01:33:58,160
están muy bien distribuida
porque yo estoy escribiendo otro lado

2132
01:33:58,160 --> 01:34:00,320
y yo estoy leyendo a través de cientos de llaves.

2133
01:34:00,320 --> 01:34:03,500
No estoy escribiendo y
la lectura a través de una clave ahora.

2134
01:34:03,500 --> 01:34:04,950
Así que eso es un gran modelo.

2135
01:34:04,950 --> 01:34:08,090
>> Esto es en realidad probablemente uno
del diseño más importante

2136
01:34:08,090 --> 01:34:10,420
las pautas de escala en NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Usted verá este tipo de
patrón de diseño de todos los sabores.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, no lo hace
importa, todos tenemos que hacer esto.

2139
01:34:19,100 --> 01:34:21,840
Porque cuando se trata
con esos enormes agregaciones,

2140
01:34:21,840 --> 01:34:26,650
usted tiene que encontrar una manera de
esparcirán por todo baldes.

2141
01:34:26,650 --> 01:34:29,512
Así que esta es la forma de hacer eso.

2142
01:34:29,512 --> 01:34:31,220
Muy bien, así que lo que
que estás haciendo en este momento

2143
01:34:31,220 --> 01:34:35,252
es lo que está operando fuera de lectura
costo para escribir escalabilidad.

2144
01:34:35,252 --> 01:34:37,085
El costo de mi lectura es
un poco más complejo

2145
01:34:37,085 --> 01:34:40,220
y tengo que ir a leer a partir de un
cien cubos en lugar de uno.

2146
01:34:40,220 --> 01:34:41,310
Pero soy capaz de escribir.

2147
01:34:41,310 --> 01:34:44,860
Y mi rendimiento, mi escritura
rendimiento es increíble.

2148
01:34:44,860 --> 01:34:49,450
Así que es por lo general una valiosa
técnica para escalar DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
o cualquier base de datos NoSQL para el caso.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Entonces nos dimos cuenta de cómo escalar ella.

2152
01:34:55,240 --> 01:34:56,930
Y nos dimos cuenta de cómo
eliminar las llaves calientes.

2153
01:34:56,930 --> 01:34:57,820
Y esto es fantástico.

2154
01:34:57,820 --> 01:34:58,960
Y tenemos este bonito sistema.

2155
01:34:58,960 --> 01:35:02,043
Y nos ha dado de votación muy correcto
porque tenemos registro de voto de-dupe.

2156
01:35:02,043 --> 01:35:03,130
Está construido en DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Hablamos de los derechos condicionales.

2158
01:35:05,380 --> 01:35:08,170
>> Cuando un votante entra, pone
una inserción en la tabla,

2159
01:35:08,170 --> 01:35:11,220
insertan con su credencial de elector,
si tratan de insertar otra votación,

2160
01:35:11,220 --> 01:35:13,320
Hago una escritura condicional.

2161
01:35:13,320 --> 01:35:16,960
Digamos solamente escribir este
si esto no existe.

2162
01:35:16,960 --> 01:35:19,270
Así que tan pronto como veo que
que el voto de golpear la mesa,

2163
01:35:19,270 --> 01:35:20,460
nadie más va a ser
capaz de poner su voto en.

2164
01:35:20,460 --> 01:35:21,634
Y eso es fantástico.

2165
01:35:21,634 --> 01:35:23,550
Y estamos incrementando
nuestros contadores de candidatos.

2166
01:35:23,550 --> 01:35:25,466
Y estamos haciendo nuestro
demografía y todo eso.

2167
01:35:25,466 --> 01:35:29,110
¿Pero qué sucede si mi
aplicación se cae?

2168
01:35:29,110 --> 01:35:31,350
Ahora, de repente votos
están entrando, y yo

2169
01:35:31,350 --> 01:35:34,840
no saben si están recibiendo procesados
en mis análisis y demografía

2170
01:35:34,840 --> 01:35:36,040
nunca más.

2171
01:35:36,040 --> 01:35:38,462
Y cuando la aplicación
vuelve, ¿cómo

2172
01:35:38,462 --> 01:35:41,420
diablos voy a saber lo que califican tienen
sido procesado y ¿por dónde empiezo?

2173
01:35:41,420 --> 01:35:44,530
>> Así que este es un problema real cuando
empezar a mirar este tipo de escenario.

2174
01:35:44,530 --> 01:35:45,571
¿Y cómo se resuelve esto?

2175
01:35:45,571 --> 01:35:48,070
Resolvemos con lo que
llamar DynamoDB Arroyos.

2176
01:35:48,070 --> 01:35:53,470
Corrientes se ordena la vez y
registro de cambios particionado de cada acceso

2177
01:35:53,470 --> 01:35:55,700
a la mesa, cada escritura
el acceso a la tabla.

2178
01:35:55,700 --> 01:35:58,810
Todos los datos que se escriben en el
tabla aparece en la secuencia.

2179
01:35:58,810 --> 01:36:01,815
>> Se trata básicamente de una cola de 24 horas.

2180
01:36:01,815 --> 01:36:03,690
Los productos que lleguen al arroyo,
viven durante 24 horas.

2181
01:36:03,690 --> 01:36:05,990
Se pueden leer varias veces.

2182
01:36:05,990 --> 01:36:09,400
Garantizado para ser entregados
sólo una vez a la corriente,

2183
01:36:09,400 --> 01:36:11,180
se podía leer un número n de veces.

2184
01:36:11,180 --> 01:36:14,910
Así que sin embargo muchos procesos que deseas
consumir esos datos, se puede consumir.

2185
01:36:14,910 --> 01:36:16,350
Aparecerá cada actualización.

2186
01:36:16,350 --> 01:36:18,455
Cada escritura sólo se
aparecer una vez en la secuencia.

2187
01:36:18,455 --> 01:36:20,621
Así que usted no tiene que preocuparse
acerca del procesamiento de dos veces

2188
01:36:20,621 --> 01:36:22,500
Del mismo proceso.

2189
01:36:22,500 --> 01:36:25,350
>> Está estrictamente ordenado por artículo.

2190
01:36:25,350 --> 01:36:28,180
Cuando decimos que el tiempo
ordenado y se repartió,

2191
01:36:28,180 --> 01:36:30,680
verás por partición en la secuencia.

2192
01:36:30,680 --> 01:36:33,169
Verá artículos, actualizaciones en orden.

2193
01:36:33,169 --> 01:36:35,210
No estamos garantizando
sobre el arroyo que eres

2194
01:36:35,210 --> 01:36:40,240
va a poner cada transacción
en el orden a través de artículos.

2195
01:36:40,240 --> 01:36:42,440
>> Así arroyos son idempotente.

2196
01:36:42,440 --> 01:36:44,037
¿Tenemos todos sabemos lo idempotente significa?

2197
01:36:44,037 --> 01:36:46,620
Idempotente significa que usted puede hacerlo
otra y otra y otra vez.

2198
01:36:46,620 --> 01:36:48,200
El resultado va a ser el mismo.

2199
01:36:48,200 --> 01:36:49,991
>> Streams son idempotente,
pero tienen que ser

2200
01:36:49,991 --> 01:36:54,860
jugado desde el punto de partida,
dondequiera que usted elija, hasta el final,

2201
01:36:54,860 --> 01:36:57,950
o que no se traducirá
en los mismos valores.

2202
01:36:57,950 --> 01:36:59,727
>> Lo mismo con MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB tiene una construcción
que ellos llaman el oplog.

2204
01:37:01,560 --> 01:37:04,140
Es la misma construcción exacta.

2205
01:37:04,140 --> 01:37:06,500
Muchas bases de datos NoSQL
tener este constructo.

2206
01:37:06,500 --> 01:37:08,790
Lo usan para hacer las cosas
como la replicación, que

2207
01:37:08,790 --> 01:37:10,475
es exactamente lo que hacemos con las corrientes.

2208
01:37:10,475 --> 01:37:12,350
AUDIENCIA: Tal vez un
pregunta herética, pero

2209
01:37:12,350 --> 01:37:13,975
hablar de aplicaciones haciendo de suelo así sucesivamente.

2210
01:37:13,975 --> 01:37:16,089
Son corrientes garantizados para
Nunca posiblemente bajar?

2211
01:37:16,089 --> 01:37:18,630
RICK HOULIHAN: Sí, arroyos
están garantizados para no bajar.

2212
01:37:18,630 --> 01:37:21,040
Gestionamos la infraestructura
detrás. arroyos automáticamente

2213
01:37:21,040 --> 01:37:22,498
implementar en su grupo de escala automática.

2214
01:37:22,498 --> 01:37:25,910
Vamos a ir a través de una pequeña
poco acerca de lo que sucede.

2215
01:37:25,910 --> 01:37:30,060
>> No debería decir que no son
garantizado para no bajar.

2216
01:37:30,060 --> 01:37:33,110
Los elementos están garantizados
a aparecer en la corriente.

2217
01:37:33,110 --> 01:37:36,740
Y la corriente será accesible.

2218
01:37:36,740 --> 01:37:40,580
Entonces, ¿qué se cae o se vuelve
arriba, eso pasa por debajo.

2219
01:37:40,580 --> 01:37:43,844
Se Cubiertas está bien.

2220
01:37:43,844 --> 01:37:46,260
Muy bien, por lo que obtener diferentes
tipos de vista de la pantalla.

2221
01:37:46,260 --> 01:37:51,040
Los tipos de vista que son importantes para un
programador normalmente son, ¿qué era?

2222
01:37:51,040 --> 01:37:52,370
Tengo la vieja visión.

2223
01:37:52,370 --> 01:37:55,630
Cuando una actualización golpea la mesa, que va a
empujar la antigua visión de la corriente

2224
01:37:55,630 --> 01:38:02,070
lo que los datos se pueden archivar o cambio
control, identificación cambio, cambio

2225
01:38:02,070 --> 01:38:03,600
administración.

2226
01:38:03,600 --> 01:38:07,160
>> La nueva imagen, lo que es ahora, después de
la actualización, que es otro tipo de vista

2227
01:38:07,160 --> 01:38:07,660
puedes obtener.

2228
01:38:07,660 --> 01:38:09,660
Usted puede obtener tanto las viejas y nuevas imágenes.

2229
01:38:09,660 --> 01:38:10,660
Tal vez los dos quiera.

2230
01:38:10,660 --> 01:38:11,790
Quiero ver lo que era.

2231
01:38:11,790 --> 01:38:13,290
Quiero ver lo que ha cambiado a.

2232
01:38:13,290 --> 01:38:15,340
>> Tengo un tipo de cumplimiento
del proceso que se ejecuta.

2233
01:38:15,340 --> 01:38:17,430
Tiene que verificar que
Cuando estas cosas cambian,

2234
01:38:17,430 --> 01:38:21,840
que están dentro de ciertos límites
o dentro de ciertos parámetros.

2235
01:38:21,840 --> 01:38:23,840
>> Y entonces tal vez sólo
necesidad de saber lo que ha cambiado.

2236
01:38:23,840 --> 01:38:26,240
No me importa lo que el tema cambió.

2237
01:38:26,240 --> 01:38:28,580
No necesito a necesitar saber
lo atribuye cambiado.

2238
01:38:28,580 --> 01:38:30,882
Sólo necesito saber que
los artículos están siendo tocados.

2239
01:38:30,882 --> 01:38:33,340
Así que estos son los tipos de vistas
que se baje la corriente

2240
01:38:33,340 --> 01:38:35,960
y se puede interactuar.

2241
01:38:35,960 --> 01:38:37,840
>> La aplicación que
consume la corriente,

2242
01:38:37,840 --> 01:38:39,298
esto es una especie de la forma en que esto funciona.

2243
01:38:39,298 --> 01:38:42,570
Cliente DynamoDB pida
enviar datos a las tablas.

2244
01:38:42,570 --> 01:38:44,750
Streams desplegar en lo que llamamos fragmentos.

2245
01:38:44,750 --> 01:38:47,380
Fragmentos se escalan
independientemente de la mesa.

2246
01:38:47,380 --> 01:38:50,660
Ellos no se alinean completamente
a las particiones de tu mesa.

2247
01:38:50,660 --> 01:38:52,540
Y la razón por la cual es
porque se alinean

2248
01:38:52,540 --> 01:38:55,430
a la capacidad, la corriente
la capacidad de la mesa.

2249
01:38:55,430 --> 01:38:57,600
>> Se despliegan en su
propio grupo de escalado automático,

2250
01:38:57,600 --> 01:39:00,800
y comienzan a girar a cabo en función
de la cantidad de escrituras están entrando,

2251
01:39:00,800 --> 01:39:03,090
cuántos reads-- realidad es escribe.

2252
01:39:03,090 --> 01:39:05,820
No hay reads-- sino cómo
muchas escrituras están llegando.

2253
01:39:05,820 --> 01:39:08,200
>> Y luego en la parte posterior
fin, tenemos lo que

2254
01:39:08,200 --> 01:39:11,390
llamar a un KCL o Kinesis Client Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis es un flujo de datos
tecnología de procesamiento de Amazon.

2256
01:39:19,190 --> 01:39:22,040
Y arroyos se construye en eso.

2257
01:39:22,040 --> 01:39:25,670
>> Así se utiliza un KCL habilitado
aplicación leer la corriente.

2258
01:39:25,670 --> 01:39:28,752
La biblioteca de clientes Kinesis realidad
gestiona los trabajadores para usted.

2259
01:39:28,752 --> 01:39:30,460
Y también hace algunos
cosas interesantes.

2260
01:39:30,460 --> 01:39:35,630
Se va a crear algunas tablas hasta
en su espacio de tabla DynamoDB

2261
01:39:35,630 --> 01:39:38,410
para rastrear qué artículos
han sido procesados.

2262
01:39:38,410 --> 01:39:41,190
Así de esta manera si se cae de nuevo, si
cae una y viene y se pone

2263
01:39:41,190 --> 01:39:45,570
se puso de pie, se puede determinar dónde
era que en la tramitación de la corriente.

2264
01:39:45,570 --> 01:39:48,360
>> Eso es muy importante cuando
usted está hablando de replicación.

2265
01:39:48,360 --> 01:39:50,350
Necesito saber lo
los datos se ha procesado

2266
01:39:50,350 --> 01:39:52,810
y lo que los datos aún no se ha procesado.

2267
01:39:52,810 --> 01:39:57,380
Así que la biblioteca KCL para los flujos voluntad
le dará una gran cantidad de esa funcionalidad.

2268
01:39:57,380 --> 01:39:58,990
Se ocupa de todo el servicio de limpieza.

2269
01:39:58,990 --> 01:40:01,140
Se pone de pie a un trabajador por cada fragmento.

2270
01:40:01,140 --> 01:40:04,620
Se crea una tabla administrativa
para cada fragmento, por cada trabajador.

2271
01:40:04,620 --> 01:40:07,560
Y a medida que los trabajadores de incendios,
mantienen esas mesas

2272
01:40:07,560 --> 01:40:10,510
para que sepa este registro
fue leída y procesada.

2273
01:40:10,510 --> 01:40:13,850
Y luego de esa manera si el proceso
muere y viene de nuevo en línea,

2274
01:40:13,850 --> 01:40:17,940
puede reanudar justo donde despegó.

2275
01:40:17,940 --> 01:40:20,850
>> Así que usamos esto para
replicación cruzada región.

2276
01:40:20,850 --> 01:40:24,680
Muchos clientes tienen la necesidad de
mover datos o partes de sus tablas de datos

2277
01:40:24,680 --> 01:40:25,920
torno a las diferentes regiones.

2278
01:40:25,920 --> 01:40:29,230
Hay nueve regiones
alrededor del mundo.

2279
01:40:29,230 --> 01:40:32,100
Así que podría haber un yo need--
podría tener los usuarios en Asia, los usuarios

2280
01:40:32,100 --> 01:40:34,150
en la costa este de los Estados Unidos.

2281
01:40:34,150 --> 01:40:38,980
Tienen diferentes datos que
necesita ser distribuido localmente.

2282
01:40:38,980 --> 01:40:42,510
Y tal vez un usuario vuela desde
Asia a los Estados Unidos,

2283
01:40:42,510 --> 01:40:45,020
y quiero replicar
sus datos con él.

2284
01:40:45,020 --> 01:40:49,340
Así que cuando él se baja del avión, que tiene
una buena experiencia en el uso de su aplicación móvil.

2285
01:40:49,340 --> 01:40:52,360
>> Puede utilizar la región cruz
biblioteca de replicación para hacer esto.

2286
01:40:52,360 --> 01:40:55,730
Básicamente tenemos
proporcionado dos tecnologías.

2287
01:40:55,730 --> 01:40:59,400
Uno es una aplicación de consola que pueda
ponerse de pie en su propia instancia EC2.

2288
01:40:59,400 --> 01:41:01,240
Se ejecuta la replicación puro.

2289
01:41:01,240 --> 01:41:02,720
Y luego os dimos la biblioteca.

2290
01:41:02,720 --> 01:41:06,070
La biblioteca se puede utilizar para construir
su propia aplicación si

2291
01:41:06,070 --> 01:41:10,740
querer hacer cosas locas con ese data--
filtro, replicar sólo parte de ella,

2292
01:41:10,740 --> 01:41:14,120
rotar los datos, moverse en un
diferente de mesa, así sucesivamente y así sucesivamente.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Así que eso es algo de lo que parece.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams puede haber
procesado por lo que llamamos Lambda.

2296
01:41:23,690 --> 01:41:27,394
Hemos mencionado un poco acerca de eventos
arquitecturas de aplicaciones accionadas.

2297
01:41:27,394 --> 01:41:28,810
Lambda es un componente clave de eso.

2298
01:41:28,810 --> 01:41:32,840
Lambda es el código que dispara la demanda
en respuesta a un evento en particular.

2299
01:41:32,840 --> 01:41:36,020
Uno de esos eventos podría ser una
registro que aparece en la secuencia.

2300
01:41:36,020 --> 01:41:39,100
Si un registro aparece en la corriente,
vamos a llamar esta función Java.

2301
01:41:39,100 --> 01:41:44,980
Bueno, este es JavaScript y Lambda
apoya Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
y pronto apoyar
otros idiomas también.

2303
01:41:47,820 --> 01:41:50,940
Y basta con decir, es de código puro.

2304
01:41:50,940 --> 01:41:53,610
escribir En Java, se define una clase.

2305
01:41:53,610 --> 01:41:55,690
Usted aprieta el JAR arriba en Lambda.

2306
01:41:55,690 --> 01:42:00,200
Y a continuación, se especifica qué clase
llamar en respuesta a qué evento.

2307
01:42:00,200 --> 01:42:04,770
Y entonces la infraestructura Lambda
detrás que se ejecutará ese código.

2308
01:42:04,770 --> 01:42:06,730
>> Ese código puede procesar
registros fuera de la corriente.

2309
01:42:06,730 --> 01:42:08,230
Puede hacer lo que quiera con él.

2310
01:42:08,230 --> 01:42:11,650
En este ejemplo en particular, todos estamos
realmente haciendo es registrar los atributos.

2311
01:42:11,650 --> 01:42:13,480
Pero esto es sólo código.

2312
01:42:13,480 --> 01:42:15,260
El código puede hacer cualquier cosa, ¿verdad?

2313
01:42:15,260 --> 01:42:16,600
>> Así que usted puede girar esos datos.

2314
01:42:16,600 --> 01:42:18,160
Puede crear una vista derivada.

2315
01:42:18,160 --> 01:42:21,160
Si se trata de una estructura de documento,
usted puede aplanar la estructura.

2316
01:42:21,160 --> 01:42:24,300
Puede crear índices alternativos.

2317
01:42:24,300 --> 01:42:27,100
Todos los tipos de cosas que usted puede
ver con las corrientes DynamoDB.

2318
01:42:27,100 --> 01:42:28,780
>> Y realmente, eso es lo que parece.

2319
01:42:28,780 --> 01:42:29,940
Para que pueda obtener esas actualizaciones entrando.

2320
01:42:29,940 --> 01:42:31,190
Están saliendo de la cadena.

2321
01:42:31,190 --> 01:42:32,720
Son leídos por la función de Lambda.

2322
01:42:32,720 --> 01:42:37,480
Están girando los datos y
empujándola hacia arriba en las tablas derivadas,

2323
01:42:37,480 --> 01:42:42,200
notificar a sistemas externos de cambio,
y empujando datos en ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Hablamos de cómo poner la caché
en frente de la base de datos para que las ventas

2325
01:42:45,900 --> 01:42:46,450
guión.

2326
01:42:46,450 --> 01:42:50,049
Bueno, ¿qué pasa si
actualizar la descripción del artículo?

2327
01:42:50,049 --> 01:42:52,340
Bueno, si yo tuviera un Lambda
función que se ejecuta en esa mesa,

2328
01:42:52,340 --> 01:42:55,490
si actualizo la descripción del artículo, que va a
recoger el registro de la corriente,

2329
01:42:55,490 --> 01:42:58,711
y que va a actualizar el ElastiCache
instancia con los nuevos datos.

2330
01:42:58,711 --> 01:43:00,460
Así que eso es una gran cantidad de
lo que hacemos con Lambda.

2331
01:43:00,460 --> 01:43:02,619
Es código pegamento, conectores.

2332
01:43:02,619 --> 01:43:04,410
Y lo que realmente da
la capacidad de lanzar

2333
01:43:04,410 --> 01:43:07,930
y para ejecutar aplicaciones muy complejas
sin un servidor dedicado

2334
01:43:07,930 --> 01:43:10,371
infraestructura, que es realmente genial.

2335
01:43:10,371 --> 01:43:13,100
>> Así que vamos a volver a nuestro
en tiempo real la arquitectura de votación.

2336
01:43:13,100 --> 01:43:17,984
Esto es nuevo y mejorado con nuestro
arroyos y KCL habilitado aplicación.

2337
01:43:17,984 --> 01:43:20,150
Igual que antes, podemos
manejar cualquier escala de las elecciones.

2338
01:43:20,150 --> 01:43:21,100
Nos gusta esto.

2339
01:43:21,100 --> 01:43:24,770
Estamos haciendo fuera frunces de dispersión
a través de múltiples cubos.

2340
01:43:24,770 --> 01:43:26,780
Tenemos bloqueo optimista pasando.

2341
01:43:26,780 --> 01:43:30,192
Podemos mantener nuestros votantes
cambien sus votos.

2342
01:43:30,192 --> 01:43:31,400
Sólo pueden votar sólo una vez.

2343
01:43:31,400 --> 01:43:32,880
Esto es fantástico.

2344
01:43:32,880 --> 01:43:35,895
Tolerancia a fallos en tiempo real,
agregación escalable ahora.

2345
01:43:35,895 --> 01:43:38,270
Si la cosa se cae, se
sabe dónde para reiniciar en sí

2346
01:43:38,270 --> 01:43:41,300
cuando se trata de una copia de seguridad, ya
estamos usando la aplicación KCL.

2347
01:43:41,300 --> 01:43:45,700
Y entonces también podemos usar esa
Aplicación KCL para empujar datos fuera

2348
01:43:45,700 --> 01:43:48,820
al desplazamiento al rojo para otros
análisis de aplicaciones, o el uso

2349
01:43:48,820 --> 01:43:51,990
MapReduce los elásticos para ejecutar
agregaciones de streaming en tiempo real fuera

2350
01:43:51,990 --> 01:43:53,180
de esos datos.

2351
01:43:53,180 --> 01:43:55,480
>> Así que estas son las cosas que nosotros
no han hablado mucho.

2352
01:43:55,480 --> 01:43:57,375
Pero son adicionales
tecnologías que vienen

2353
01:43:57,375 --> 01:44:00,310
tener cuando estás buscando
en estos tipos de escenarios.

2354
01:44:00,310 --> 01:44:03,160
>> Muy bien, así que eso es todo
análisis con DynamoDB Arroyos.

2355
01:44:03,160 --> 01:44:05,340
Usted puede obtener de-dupe
datos, hacer todo tipo

2356
01:44:05,340 --> 01:44:09,490
de cosas bonitas, los datos agregados en
memoria, crear esas tablas derivadas.

2357
01:44:09,490 --> 01:44:13,110
Eso es un caso de uso enorme
que muchos de los clientes

2358
01:44:13,110 --> 01:44:16,950
están involucrados con, tomando el anidada
propiedades de los documentos JSON

2359
01:44:16,950 --> 01:44:18,946
y la creación de índices adicionales.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Estamos en el final.

2362
01:44:23,150 --> 01:44:26,689
Gracias por su paciencia conmigo.

2363
01:44:26,689 --> 01:44:28,480
Así que vamos a hablar de
arquitectura de referencia.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB se encuentra en medio de lo
gran parte de la infraestructura de AWS.

2365
01:44:33,440 --> 01:44:37,090
Básicamente, usted puede conectarlo
hasta lo que quieras.

2366
01:44:37,090 --> 01:44:45,600
Las aplicaciones creadas usando Dynamo incluye
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
empujar los datos hacia elástico
MapReduce, importación y exportación de DynamoDB

2368
01:44:49,890 --> 01:44:52,370
en S3, todos los tipos de flujos de trabajo.

2369
01:44:52,370 --> 01:44:54,120
Pero probablemente la mejor
cosa de que hablar,

2370
01:44:54,120 --> 01:44:56,119
y esto es lo que es realmente
interesante es cuando

2371
01:44:56,119 --> 01:44:58,350
hablar de aplicaciones por eventos.

2372
01:44:58,350 --> 01:45:00,300
>> Este es un ejemplo de
un proyecto interno

2373
01:45:00,300 --> 01:45:04,850
que tenemos cuando estamos en realidad
publicación para recoger resultados de la encuesta.

2374
01:45:04,850 --> 01:45:07,700
Así que en un enlace de correo electrónico que
que enviamos, habrá

2375
01:45:07,700 --> 01:45:11,350
ser un poco clic enlace que dice
aquí para responder a la encuesta.

2376
01:45:11,350 --> 01:45:14,070
Y cuando una persona hace clic
ese vínculo, lo que pasa

2377
01:45:14,070 --> 01:45:18,020
es que tire abajo de un seguro
HTML formulario de encuesta de S3.

2378
01:45:18,020 --> 01:45:18,980
No hay servidor.

2379
01:45:18,980 --> 01:45:20,600
Esto es sólo un objeto S3.

2380
01:45:20,600 --> 01:45:22,770
>> Esa forma aparece,
carga en el navegador.

2381
01:45:22,770 --> 01:45:24,240
Tiene Backbone.

2382
01:45:24,240 --> 01:45:30,160
Tiene complejo JavaScript
que se está ejecutando.

2383
01:45:30,160 --> 01:45:33,557
Así que es de aplicación muy rica
se ejecuta en el navegador del cliente.

2384
01:45:33,557 --> 01:45:36,390
Ellos no saben que no lo son
interactuar con un servidor back-end.

2385
01:45:36,390 --> 01:45:38,220
En este punto, es todo navegador.

2386
01:45:38,220 --> 01:45:41,780
>> Publican los resultados a lo
llamamos a la API de Amazon Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway es simplemente una API Web
que se puede definir y conectar

2388
01:45:46,270 --> 01:45:47,760
a lo que quieras.

2389
01:45:47,760 --> 01:45:50,990
En este caso particular, estamos
conectado a una función lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Así que mi operación POST es
pasando con ningún servidor.

2391
01:45:54,797 --> 01:45:56,380
Básicamente esa puerta de enlace API se sienta allí.

2392
01:45:56,380 --> 01:45:58,770
Me cuesta nada hasta que la gente
comienza a publicar a ella, ¿no?

2393
01:45:58,770 --> 01:46:00,269
La función de Lambda sólo se sienta allí.

2394
01:46:00,269 --> 01:46:03,760
Y me cuesta nada hasta
la gente comienza a golpearlo.

2395
01:46:03,760 --> 01:46:07,270
Así se puede ver, ya que el volumen
aumenta, ahí es cuando las acusaciones vienen.

2396
01:46:07,270 --> 01:46:09,390
No estoy corriendo un servidor 24.7.

2397
01:46:09,390 --> 01:46:12,310
>> Así que me tire de la forma
descender del cubo,

2398
01:46:12,310 --> 01:46:15,719
y he puesto a través de la API
Puerta de entrada a la función de Lambda.

2399
01:46:15,719 --> 01:46:17,510
Y entonces el Lambda
función dice, ya sabes

2400
01:46:17,510 --> 01:46:20,600
lo que, tengo algunos PII, algunos
información de identificación personal

2401
01:46:20,600 --> 01:46:21,480
en estas respuestas.

2402
01:46:21,480 --> 01:46:23,020
Conseguí comentarios procedentes de los usuarios.

2403
01:46:23,020 --> 01:46:24,230
Tengo direcciones de correo electrónico.

2404
01:46:24,230 --> 01:46:26,190
Tengo los nombres de usuario.

2405
01:46:26,190 --> 01:46:27,810
>> Déjame dividir esto.

2406
01:46:27,810 --> 01:46:30,280
Voy a generar algo de
metadatos fuera de este registro.

2407
01:46:30,280 --> 01:46:32,850
Y voy a empujar el
metadatos en DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
Y podría cifrar todos los datos
e introdúzcalo en DynamoDB si quiero.

2409
01:46:36,059 --> 01:46:38,600
Pero es más fácil para mí, en este
utilice caso, para que adelante un ejemplo,

2410
01:46:38,600 --> 01:46:42,800
Voy a empujar los datos en bruto
en un cubo de S3 cifrado.

2411
01:46:42,800 --> 01:46:47,240
Así que utilizar construido en la lado del servidor S3
encriptación y administración de claves de Amazon

2412
01:46:47,240 --> 01:46:51,600
Servicio de manera que tengo una llave que
puede girar en un intervalo regular,

2413
01:46:51,600 --> 01:46:55,010
y puedo proteger los datos PII
como parte de todo este flujo de trabajo.

2414
01:46:55,010 --> 01:46:55,870
>> Entonces, ¿qué he hecho?

2415
01:46:55,870 --> 01:47:00,397
Acabo desplegado en su conjunto
aplicación, y no tengo ningún servidor.

2416
01:47:00,397 --> 01:47:02,980
Así que es lo que de sucesos de aplicación impulsada
arquitectura hace por usted.

2417
01:47:02,980 --> 01:47:05,730
>> Ahora bien, si se piensa en
el caso de uso de esto--

2418
01:47:05,730 --> 01:47:08,730
tenemos otros clientes que estoy hablando
a alrededor de esta arquitectura exacta que

2419
01:47:08,730 --> 01:47:14,560
ejecutar fenomenalmente grandes campañas, que
están mirando esto y va, oh mi.

2420
01:47:14,560 --> 01:47:17,840
Porque ahora, que pueden
básicamente empujarlo hacia fuera allí,

2421
01:47:17,840 --> 01:47:21,900
dejar que la campaña simplemente sentarse
allí hasta que lanza, y no

2422
01:47:21,900 --> 01:47:24,400
tienes que preocuparte un bledo
qué tipo de infraestructura

2423
01:47:24,400 --> 01:47:26,120
va a estar ahí para apoyarlo.

2424
01:47:26,120 --> 01:47:28,600
Y entonces tan pronto como
que la campaña se lleva a cabo,

2425
01:47:28,600 --> 01:47:31,520
es como la infraestructura
acaba inmediatamente desaparece

2426
01:47:31,520 --> 01:47:33,680
porque realmente
hay infraestructura.

2427
01:47:33,680 --> 01:47:35,660
Es código solo que se sienta en Lambda.

2428
01:47:35,660 --> 01:47:38,560
Es sólo que los datos se encuentra en DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Es una manera increíble
para crear aplicaciones.

2430
01:47:41,340 --> 01:47:43,970
>> AUDIENCIA: Entonces, ¿es más
efímero de lo que sería

2431
01:47:43,970 --> 01:47:45,740
si se almacena en un servidor real?

2432
01:47:45,740 --> 01:47:46,823
>> RICK HOULIHAN: Por supuesto.

2433
01:47:46,823 --> 01:47:49,190
Porque esa instancia de servidor
tendría que ser un 7/24.

2434
01:47:49,190 --> 01:47:51,954
Tiene que estar disponible para
alguien para responder a.

2435
01:47:51,954 --> 01:47:52,620
Bueno ¿adivinen qué?

2436
01:47:52,620 --> 01:47:55,410
S3 está disponible 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 siempre responde.

2438
01:47:57,100 --> 01:47:59,320
Y S3 es muy, muy bueno
a servir a los objetos.

2439
01:47:59,320 --> 01:48:02,590
Estos objetos pueden ser archivos HTML, o
Archivos JavaScript, o lo que quieras.

2440
01:48:02,590 --> 01:48:07,430
Puede ejecutar aplicaciones web muy ricos
de cubos S3, y la gente hace.

2441
01:48:07,430 --> 01:48:10,160
>> Y así, esa es la idea aquí
es alejarse de la forma

2442
01:48:10,160 --> 01:48:11,270
solíamos pensar en ello.

2443
01:48:11,270 --> 01:48:14,270
A todos nos acostumbramos a pensar en
términos de servidores y anfitriones.

2444
01:48:14,270 --> 01:48:16,580
No se trata de eso.

2445
01:48:16,580 --> 01:48:19,310
Se trata de la infraestructura como código.

2446
01:48:19,310 --> 01:48:22,470
Implementar el código para la nube y
deje que la nube dirigido por usted.

2447
01:48:22,470 --> 01:48:24,980
Y eso es lo AWS está tratando de hacer.

2448
01:48:24,980 --> 01:48:29,690
>> AUDIENCIA: Así que su caja de oro en el medio
de la puerta de enlace API no es como en el servidor,

2449
01:48:29,690 --> 01:48:30,576
pero en cambio es sólo--

2450
01:48:30,576 --> 01:48:32,850
>> RICK HOULIHAN: Usted puede pensar
ello como fachada servidor.

2451
01:48:32,850 --> 01:48:38,040
Todo lo que es es que va a tomar un HTTP
solicitar y asignar a otro proceso.

2452
01:48:38,040 --> 01:48:39,192
Eso es todo lo que hace.

2453
01:48:39,192 --> 01:48:41,525
Y en este caso, estamos cartografía
a una función Lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Muy bien, así que eso es todo lo que tengo.

2456
01:48:45,410 --> 01:48:46,190
Muchas gracias.

2457
01:48:46,190 --> 01:48:46,800
Lo aprecio.

2458
01:48:46,800 --> 01:48:48,100
Sé que queremos un poco más de tiempo.

2459
01:48:48,100 --> 01:48:49,980
Y espero que ustedes ya ha recibido
un poco de información

2460
01:48:49,980 --> 01:48:51,410
que se puede llevar en la actualidad.

2461
01:48:51,410 --> 01:48:53,520
Y pido disculpas si me fui
sobre algunos de sus jefes,

2462
01:48:53,520 --> 01:48:56,697
pero hay una buena cantidad de
conocimientos básicos fundamentales

2463
01:48:56,697 --> 01:48:58,280
que creo que es muy valioso para usted.

2464
01:48:58,280 --> 01:48:59,825
Así que gracias por invitarme.

2465
01:48:59,825 --> 01:49:00,325
[APLAUSOS]

2466
01:49:00,325 --> 01:49:02,619
AUDIENCIA: [inaudible]
es cuando usted decía

2467
01:49:02,619 --> 01:49:05,160
que tenía que ir a través de la cosa
desde el principio hasta el fin

2468
01:49:05,160 --> 01:49:07,619
para obtener los valores correctos
o los mismos valores,

2469
01:49:07,619 --> 01:49:09,410
¿cómo los valores
cambiar si [inaudible].

2470
01:49:09,410 --> 01:49:10,480
>> RICK HOULIHAN: Oh, idempotente?

2471
01:49:10,480 --> 01:49:11,800
¿Cómo cambiarían los valores?

2472
01:49:11,800 --> 01:49:15,180
Bueno, porque si yo no corro
todo el camino hasta el final,

2473
01:49:15,180 --> 01:49:19,770
entonces yo no sé lo que cambia
se hicieron en la última milla.

2474
01:49:19,770 --> 01:49:22,144
No va a ser el
mismos datos que lo que vi.

2475
01:49:22,144 --> 01:49:24,560
AUDIENCIA: Oh, por lo que sólo
no han conseguido la entrada completa.

2476
01:49:24,560 --> 01:49:24,770
RICK HOULIHAN: Correcto.

2477
01:49:24,770 --> 01:49:26,895
Tienes que ir desde el principio
a fin, y entonces es

2478
01:49:26,895 --> 01:49:29,280
va a ser un estado coherente.

2479
01:49:29,280 --> 01:49:31,520
Guay.

2480
01:49:31,520 --> 01:49:35,907
>> AUDIENCIA: ¿Así que nos mostraste DynamoDB
puede hacer de documentos o el valor de la clave.

2481
01:49:35,907 --> 01:49:38,740
Y nos pasamos un montón de tiempo en el
valor de la clave con un hash y las formas

2482
01:49:38,740 --> 01:49:40,005
para darle la vuelta alrededor.

2483
01:49:40,005 --> 01:49:43,255
Cuando se miraba en esas mesas, es que
dejando atrás el enfoque documento?

2484
01:49:43,255 --> 01:49:44,600
>> RICK HOULIHAN: Yo no lo haría
decir dejándolo atrás.

2485
01:49:44,600 --> 01:49:45,855
>> AUDIENCIA: Ellos fueron separados de el--

2486
01:49:45,855 --> 01:49:49,140
>> RICK HOULIHAN: Con el documento
enfoque, el tipo de documento en DynamoDB

2487
01:49:49,140 --> 01:49:50,880
es sólo pensar en como otro atributo.

2488
01:49:50,880 --> 01:49:53,560
Es un atributo que contiene
una estructura de datos jerárquica.

2489
01:49:53,560 --> 01:49:56,980
Y luego, en las consultas,
puede utilizar las propiedades

2490
01:49:56,980 --> 01:49:59,480
de esos objetos utilizando notación de objetos.

2491
01:49:59,480 --> 01:50:03,562
Así que puede filtrar en una anidada
propiedad del documento JSON.

2492
01:50:03,562 --> 01:50:05,520
AUDIENCIA: Así que cada vez que
hacer un enfoque documento,

2493
01:50:05,520 --> 01:50:07,906
Puedo especie de llegar a la tabular--

2494
01:50:07,906 --> 01:50:08,780
AUDIENCIA: Absolutamente.

2495
01:50:08,780 --> 01:50:09,800
Audiencia: --indexes y
cosas que acabamos de hablar.

2496
01:50:09,800 --> 01:50:11,280
RICK HOULIHAN: Sí, la
índices y todo eso,

2497
01:50:11,280 --> 01:50:13,363
cuando se quiere indexar el
propiedades de la JSON,

2498
01:50:13,363 --> 01:50:18,230
la forma en que nos gustaría tener que hacer eso es si
inserta un objeto JSON o un documento

2499
01:50:18,230 --> 01:50:20,780
en Dynamo, utilizaría los arroyos.

2500
01:50:20,780 --> 01:50:22,400
Streams leerían la entrada.

2501
01:50:22,400 --> 01:50:24,340
Usted conseguiría que JSON
objeto y que ibas a decir OK,

2502
01:50:24,340 --> 01:50:26,030
¿cuál es la propiedad que quiero índice?

2503
01:50:26,030 --> 01:50:28,717
>> Se crea una tabla derivada.

2504
01:50:28,717 --> 01:50:30,300
Ahora esa es la forma en que funciona ahora.

2505
01:50:30,300 --> 01:50:32,650
Nosotros no permitimos al índice
directamente esas propiedades.

2506
01:50:32,650 --> 01:50:33,520
>> AUDIENCIA: Tabularizing sus documentos.

2507
01:50:33,520 --> 01:50:36,230
>> RICK HOULIHAN: Exactamente, aplanando
que, tabularizing, exactamente.

2508
01:50:36,230 --> 01:50:37,415
Eso es lo que haces con él.

2509
01:50:37,415 --> 01:50:37,860
>> AUDIENCIA: Gracias.

2510
01:50:37,860 --> 01:50:39,609
>> RICK HOULIHAN: Sí,
absolutamente, gracias.

2511
01:50:39,609 --> 01:50:42,240
AUDIENCIA: Así que es una especie de
Mongo cumple classifers Redis.

2512
01:50:42,240 --> 01:50:43,990
>> RICK HOULIHAN: Sí,
que es muy parecido a eso.

2513
01:50:43,990 --> 01:50:45,940
Esa es una buena descripción de la misma.

2514
01:50:45,940 --> 01:50:47,490
Guay.

2515
01:50:47,490 --> 01:50:49,102