[REPRODUCCIÓN DE MÚSICA] RICK HOULIHAN: De acuerdo. Hola a todos. Mi nombre es Rick Houlihan. Yo soy un director de alto nivel arquitecto de soluciones de AWS. Me concentro en NoSQL y Tecnologías DynamoDB. Estoy hoy aquí para hablar que un poco sobre ellos. 

Mi formación es principalmente en la capa de datos. Pasé la mitad de mi desarrollo carrera escribiendo base de datos, de acceso a datos, soluciones para diversas aplicaciones. He estado en la virtualización de la nube durante unos 20 años. Así que antes de que la nube era la Nube, solíamos llamarlo utility computing. Y la idea fue, es como PG & E, que paga por lo que usa. Hoy lo llamamos la nube. 

Pero con los años, he trabajado durante un par de empresas probablemente nunca has oído hablar. Pero he compilado una lista de técnicos logros, supongo que dirías. Tengo ocho patentes en los sistemas de la nube virtualización, diseño de microprocesadores, procesamiento de eventos complejos, y otras áreas también. 

Así que en estos días, me centro sobre todo en NoSQL tecnologías y la próxima generación base de datos. Y eso es por lo general lo que voy estar aquí hablando con usted hoy sobre. Entonces, ¿qué se puede esperar de esta sesión, vamos a ir a través de una breve historia de procesamiento de datos. Siempre es útil entender de dónde venimos y por qué estamos donde estamos. Y hablaremos un poco poco sobre la tecnología NoSQL desde un punto de vista fundamental. 

Vamos a entrar en algunos de las interioridades DynamoDB. DynamoDB es de AWS sin sabor. Es una totalmente gestionado y NoSQL solución alojada. Y hablaremos un poco sobre la mesa estructura, API, tipos de datos, índices, y algunos de los internals de que la tecnología DynamoDB. Vamos a entrar en algunos de los diseños patrones y mejores prácticas. Vamos a hablar de cómo se utilizar esta tecnología para algunos de las aplicaciones de hoy en día. Y luego vamos a hablar un poco acerca de la evolución o de la emergencia de un nuevo paradigma en la programación llamados aplicaciones orientadas a eventos y cómo juega DynamoDB en eso también. Y os dejamos un poco de una arquitectura de referencia discusión por lo que podemos hablar de algunas de las formas en que se pueden utilizar DynamoDB. 

Así que primero off-- esta es una pregunta He oído hablar mucho es, lo que es una base de datos. Mucha gente piensa que sabe lo que es una base de datos. Si Google, verás esto. Es un un conjunto estructurado de datos celebrada en un ordenador, especialmente uno que es accesible de varias maneras. Supongo que es una buena definición de una base de datos moderno. Pero no me gusta, porque implica un par de cosas. Implica estructura. Y esto implica que está en una computadora. Y las bases de datos no lo hicieron siempre existirá en las computadoras. Bases de datos realmente existían en muchas maneras. 

Así que una mejor definición de un base de datos es algo como esto. Una base de datos es una organizada mecanismo para almacenar, gestionar, y recuperación de información. Se trata de About.com. Así que me gusta esto porque realmente habla sobre una base de datos es un repositorio, un depósito de información, no necesariamente algo que se sienta en un ordenador. Y a través de la historia, no siempre han tenido las computadoras. 

Ahora, si le pregunto a la media hoy desarrollador lo que es una base de datos, que es la respuesta que recibo. En algún lugar que puedo meter cosas. ¿Correcto? Y es cierto. Pero es lamentable. Debido a que la base de datos es realmente el fundamento de la aplicación moderna. Es la base de cada aplicación. Y la forma de construir que base de datos, cómo se estructura que los datos que va a dictar la forma en que aplicación realiza como se cambia la escala. 

Así que una gran parte de mi trabajo hoy se trata de lo que ocurre cuando los desarrolladores adoptar este enfoque y hacer frente a las secuelas de una aplicación que ahora está más allá de la escala original intención y el sufrimiento de mal diseño. Así que espero que cuando alejarse de hoy, podrás tener un par de herramientas el cinturón que te mantendrá de hacer los mismos errores. Correcto. Así que vamos a hablar un poco de la línea de tiempo de la tecnología de base de datos. Creo que leí un artículo no hace tanto tiempo y dijo algo sobre la lines-- que es una declaración muy poético. Dijo que la historia de procesamiento de datos es llena de altas marcas de agua de la abundancia de datos. OKAY. Ahora, supongo que eso es algo de cierto. Pero yo en realidad mirar es como la historia es en realidad llena con alta marca de agua de la presión de datos. Debido a que la velocidad de datos de la ingestión no se pone. Sólo sube. 

Y la innovación se produce cuando vemos presión de datos, que es la cantidad de datos que es Ahora en que entra en el sistema. Y no puede ser procesada de manera eficiente, ya sea en el tiempo o en el costo. Y fue entonces cuando empezamos para mirar la presión de datos. 

Así que cuando nos fijamos en la primera base de datos, esta es el que estaba entre nuestros oídos. Todos nacemos con ella. Es una base de datos bien. Tiene una alta disponibilidad. Es siempre encendido. Usted siempre puede conseguirlo. 

Pero es solo usuario. No puedo compartir mis pensamientos con ustedes. No se puede tener en mis pensamientos cuando quieras. Y su abilitiy no es tan bueno. Nos olvidamos de las cosas. De vez en cuando, uno de nosotros hojas y se mueve a otra existencia y perdemos todo eso fue en esa base de datos. Así que no es tan bueno. 

Y esto funcionó bien con el tiempo cuando estábamos de vuelta en el día cuando todo lo que realmente necesitamos saber es ¿a dónde vamos a ir mañana o cuando nos reunimos la mejor comida. Pero, como hemos empezado a crecer como la civilización y el gobierno comenzaron para venir a ser, y las empresas comenzaron a evolucionar, empezamos a darnos cuenta de que necesitan un poco más de lo que podríamos poner en nuestra cabeza. ¿Correcto? 

Necesitábamos los sistemas de registro. Necesitábamos lugares para ser capaces de almacenar datos. Así que empezamos a escribir documentos, la creación de bibliotecas y archivos. Comenzamos el desarrollo de un sistema de un libro mayor de contabilidad. Y ese sistema de conteo de libro mayor corrió el mundo durante muchos siglos, y tal vez incluso milenios como que tipo de crecimos hasta el punto donde esa carga de datos superó la capacidad de esos sistemas para ser capaz de contenerlo. 

Y esto realmente ocurrió en la década de 1880. ¿Correcto? En los EE.UU. Censo 1880. Esto es realmente donde el giro punto de procesamiento de datos moderno. Este es el punto en que la cantidad de datos que estaba siendo recogido por el Gobierno de Estados Unidos llegó al punto donde tomó ocho años para procesar. 

Ahora, ocho años-- como usted sabe, el censo sale cada 10 años-- por lo que es bastante obvio que para el momento en que tiene el censo de 1890, la cantidad de datos que que iba a ser procesado por el gobierno era va a superar los 10 años que llevaría a puesto en marcha el nuevo censo. Esto era un problema. 

Así que un tipo llamado Herman Hollerith llegó e inventó ponche registro de la unidad tarjetas, lector de tarjetas perforadas, tarjetas perforadas tabulador, y el cotejo de los mecanismos para esta tecnología. Y esa empresa que se formó en el tiempo, junto con un par de los demás, en realidad se convirtió en uno de los pilares de un pequeña empresa que hoy conocemos llama IBM. 

Así IBM originalmente estaba en el negocio de base de datos. Y eso es realmente lo que hicieron. Lo hicieron de procesamiento de datos. 

Como lo que la proliferación de golpe tarjetas, un mecanismos ingeniosos de ser capaz de aprovechar ese tecnología para sondear conjuntos de resultados ordenados. Se puede ver en esta foto no tenemos un poco-- que es un poco small-- pero se puede ver un mecanismo mecánico muy ingenioso donde tenemos una baraja de tarjetas perforadas. Y la toma de alguien un poco de destornillador y ajustarse a través de la ranuras y levantándolo para conseguir que el partido, que resultados ordenados establecen. 

Esta es una agregación. Hacemos esto todo el tiempo hoy en el ordenador, cuando lo haces en la base de datos. Solíamos hacerlo de forma manual, ¿no? La gente pone estas cosas juntas. Y fue la proliferación de estas tarjetas perforadas en lo que llamamos la batería de datos y carretes de datos, cinta de papel. 

La industria de procesamiento de datos se llevó una lección de los jugadores pianos. Reproductor de pianos de vuelta en el cambio de siglo utilizado para utilizar bobinas de papel con ranuras a decirle que qué teclas para jugar. Así que la tecnología se adaptó finalmente para almacenar datos digitales, porque podrían poner esos datos en esos carretes de cinta de papel. 

Ahora, como resultado, los datos fue actually-- cómo accede a este dato fue directamente depende de lo guardaste. Así que si pongo los datos en una cinta, Tuve acceso a los datos de forma lineal. Tuve que rodar el todo cinta para acceder a todos los datos. Si pongo los datos en el golpe tarjetas, que podrían acceder a ella en un poco más al azar la moda, tal vez no tan rápido. 

Pero hubo limitaciones en la forma en que acceso a los datos en función de cómo se almacenó. Y por lo que este era un problema entrar en los '50s. Una vez más, podemos empezar a ver que a medida que desarrollar nuevas tecnologías para procesar los datos, a la derecha, se abre la puerta a nuevas soluciones, para los nuevos programas, nuevos las solicitudes de esos datos. Y realmente, la gobernanza pudo haber sido la razón Por eso hemos desarrollado algunos de estos sistemas. Pero el negocio se convirtió rápidamente el conductor detrás de la evolución de la base de datos moderno y el sistema de archivos moderno. 

Así que la próxima cosa que ocurrió fue en los años 50 fue el sistema de archivos y la desarrollo de almacenamiento de acceso aleatorio. Esta era hermosa. Ahora, de repente, podemos poner nuestra archivos en cualquier parte de estos discos duros y podemos acceder a estos datos al azar. Podemos analizar que la información de los archivos. Y hemos resuelto todo el mundo problemas con el procesamiento de datos. 

Y que duró alrededor de 20 o 30 años, hasta la evolución de la base de datos relacional, que es cuando el mundo decidió que ahora necesita tener un repositorio que derrota la dispersión de los datos a través del archivo sistemas que hemos construido. ¿Correcto? Demasiados datos distribuidos en demasiados lugares, la de-duplicación de datos, y el costo de almacenamiento fue enorme. 

En los años 70, el recurso más caro que un equipo tenía era el de almacenamiento. El procesador era visto como un costo fijo. Cuando compro la caja, la CPU hace algún trabajo. Se va a estar girando si que está trabajando o no en realidad. Eso es realmente un costo hundido. 

Pero lo que me ha costado como negocio es el almacenamiento. Si tengo que comprar más discos próximo mes, eso es un costo real que tengo que pagar. Y que el almacenamiento es caro. 

Ahora tenemos avance rápido 40 años y tenemos un problema diferente. El cálculo es ahora la recurso más caro. El almacenamiento es barato. Quiero decir, podemos ir a cualquier parte de la Cloud y podemos encontrar almacenamiento barato. Pero lo que no puedo encontrar es compute barato. 

Así que la evolución de hoy la tecnología, de la tecnología de base de datos, que realmente está centrado alrededor bases de datos distribuidas que no sufren de el mismo tipo de escala limitaciones de las bases de datos relacionales. Hablaremos un poco sobre lo que realmente significa. 

Pero una de las razones y el conductor detrás de esto- nos habló de la presión de datos. Los datos de presión es algo que impulsa la innovación. Y si nos fijamos en más de los últimos cinco años, esta es una gráfica de lo que los datos carga a través de la empresa en general parece que en los últimos cinco años. 

Y la regla general estos days-- si van Google-- es 90% de los datos que almacenamos hoy, y fue generada en los últimos dos años. OKAY. Ahora, esto no es una tendencia que hay de nuevo. Esta es una tendencia que ha estado salir por 100 años. Desde Herman Hollerith desarrollado la tarjeta perforada, hemos estado construyendo depósitos de datos y la recolección de datos a velocidades fenomenales. 

Así que en los últimos 100 años, que hemos visto esta tendencia. Eso no va a cambiar. En el futuro, vamos a ver esto, si no una tendencia acelerada. Y usted puede ver lo que parece. 

Si un negocio en el año 2010 tenía una terabyte de datos bajo gestión, hoy que significa que son la gestión de 6,5 petabytes de datos. Eso es 6.500 veces más datos. Y sé que esto. Yo trabajo con estos negocios todos los días. Hace cinco años, sería hablar con empresas quien hablar conmigo sobre lo que es un dolor que es gestionar terabytes de datos. Y que hablarían a mí sobre cómo vemos que este es probablemente va ser un petabyte o dos dentro de un par de años. 

Estas mismas empresas hoy me voy a reunir con, y que están hablando conmigo sobre la problema se haya teniendo gestión decenas, 20 petabytes de datos. Así la explosión de la datos en la industria está impulsando el enorme la necesidad de mejores soluciones. Y la base de datos relacional es simplemente no vivir de acuerdo a la demanda. 

Y así hay un lineal correlación entre la presión de datos y la innovación técnica. La historia nos ha demostrado esto, que con el tiempo, siempre que el volumen de datos que necesita ser procesada excede la capacidad del sistema de para procesarlo en un tiempo razonable oa un costo razonable, a continuación, las nuevas tecnologías han sido inventados para resolver esos problemas. Esas nuevas tecnologías, a su vez, abre la puerta a otra serie de problemas, que está reuniendo aún más datos. 

Ahora, nosotros no vamos a parar esto. ¿Correcto? No vamos a parar esto. ¿Por qué? Porque no se puede saber todo que hay que saber en el universo. Y mientras hemos estado vivos, en toda la historia del hombre, siempre hemos impulsado saber más. 

Así que parece que cada pulgada que avanzamos por el camino de los descubrimientos científicos, estamos multiplicando la cantidad de datos que necesitamos para procesar de forma exponencial como descubrimos más y más y más sobre el funcionamiento interno de la vida, acerca de cómo funciona el universo, sobre conduciendo el descubrimiento científico, y la invención que que estamos haciendo hoy. El volumen de datos simplemente aumenta continuamente. Así que ser capaz de hacer frente este problema es enorme. 

Así que una de las cosas miramos como por qué NoSQL? ¿Cómo NoSQL a resolver este problema? Bueno, bases de datos relacionales, Lenguaje de consulta estructurado, SQL-- eso es realmente una construcción de la relacional database-- estas cosas son optimizado para el almacenamiento. 

Allá por los años 70, de nuevo, disco es caro. El ejercicio de aprovisionamiento de almacenamiento en la empresa es de nunca acabar. Lo sé. Yo lo viví. Escribí controladores de almacenamiento para un empresa SuperServer Enterprised allá por los años 90. Y el resultado final está acumulando otra matriz de almacenamiento era sólo algo que pasó todos los días en la empresa. Y nunca se detuvo. Mayor densidad de almacenamiento, la demanda para el almacenamiento de alta densidad, y para el almacenamiento más eficiente devices-- nunca se detuvo. 

Y NoSQL es una gran tecnología porque normaliza los datos. Es de-duplica los datos. Se pone los datos en una estructura que es agnóstico a cada patrón de acceso. Múltiples aplicaciones pueden llegar a ese Base de datos SQL, ejecutar consultas ad hoc, y obtener datos en la forma que tenga que procesar para sus cargas de trabajo. Eso suena fantástico. Pero la conclusión es que con cualquier sistema, si es agnóstico a todo, está optimizado para nada. ¿De acuerdo? 

Y eso es lo que conseguimos con la base de datos relacional. Está optimizado para su almacenamiento. Es normalizada. Es relacional. Es compatible con las consultas ad hoc. Y ella y se escala verticalmente. 

Si tengo que conseguir una base de datos SQL grande o una base de datos SQL más potente, Voy comprar un pedazo más grande de hierro. ¿De acuerdo? He trabajado con muchos clientes que han sido a través de mejoras importantes en su infraestructura de SQL única para averiguar seis meses más tarde, que están golpeando la pared de nuevo. Y la respuesta de Oracle o MSSQL o cualquier otra persona es conseguir una caja más grande. Bueno, tarde o temprano, no se puede comprar una caja más grande, y eso es un problema real. Tenemos que cambiar realmente las cosas. Entonces, ¿dónde funciona esto? Funciona bien para fuera de línea análisis, las cargas de trabajo de tipo OLAP. Y eso es realmente donde SQL pertenece. Ahora, se utiliza hoy en día en muchos en línea transaccional de tipo de procesamiento aplicaciones. Y funciona muy bien en un cierto nivel de utilización, pero simplemente no escala la forma en que NoSQL hace. Y hablaremos un poco poco acerca de por qué es así. 

Ahora, NoSQL, por otro lado, está más optimizado para cálculo. ¿De acuerdo? No es agnóstico a el patrón de acceso. Es lo que llamamos de-normalizada estructura o una estructura jerárquica. Los datos en una base de datos relacional es unido de varias tablas para producir la opinión de que lo que necesita. Los datos en la base de datos NoSQL un se almacena en un documento que contiene la estructura jerárquica. Todos los datos que normalmente sería unido para producir ese punto de vista se almacena en un único documento. Y hablaremos un poco acerca de lo que funciona en un par de cartas. 

Pero la idea aquí es que usted almacena tus datos mientras que estos puntos de vista instanciados. ¿De acuerdo? Usted escalar horizontalmente. ¿Correcto? Si tengo que aumentar el tamaño de mi grupo de NoSQL, No necesito conseguir una caja más grande. Tengo otra caja. Y yo Cluster las juntas, y puedo fragmentar esos datos. Hablaremos un poco sobre lo sharding es, para ser capaz de escalar esa base de datos a través de múltiples dispositivos físicos y quitar la barrera que me requiere para escalar verticalmente. 

Así que es realmente construido para en línea procesamiento de transacciones y la escala. Hay una gran diferencia aquí entre la información, ¿no? Informes, yo no sé la preguntas voy a preguntar. ¿Correcto? Reporting-- si alguien de mi departamento de marketing quiere solo-- cómo muchos de mis clientes tener esta característica particular que comprado en este día-- No sé lo consulta van a preguntar. Así que tengo que ser agnóstico. 

Ahora, en una línea aplicación transaccional, Yo sé lo que estoy pidiendo preguntas. Construí la solicitud de un flujo de trabajo muy específico. ¿De acuerdo? Así que si puedo optimizar los datos almacenar para apoyar ese flujo de trabajo, que va a ser más rápido. Y es por eso que NoSQL puede realmente acelerar la entrega de esos tipos de servicios. Correcto. 

Así que vamos a entrar en un poco de la teoría aquí. Y algunos de ustedes, sus ojos podría hacer retroceder un poco. Pero voy a tratar de mantenerlo tan alto nivel como pueda. Así que si usted está en proyecto gestión, hay un constructo llamado triángulo de restricciones. OKAY. El triángulo de Restringe dictados no se puede tener todo, todo el tiempo. No puede tener su pastel y comérselo también. Así que en la gestión de proyectos, ese triángulo limitaciones es que se puede tener barato, se puede tener rápido, o se puede tener buena. Elige dos. Debido a que no se puede tener a los tres. ¿Correcto? OKAY. 

Así se enteró de esto mucho. Es una triple restricción, triángulo de la triple restricción, o en el triángulo de hierro es oftentimes-- cuando hablas con los gerentes de proyecto, van a hablar de esto. Ahora, bases de datos tienen su propio triángulo de hierro. Y el triángulo de hierro de los datos es lo que llamamos teorema CAP. ¿De acuerdo? 

Dictados teorema CAP cómo funcionan las bases de datos bajo una condición muy específica. Y hablaremos de lo que la condición es. Pero los tres puntos del triángulo, por así decirlo, son C, la consistencia. ¿De acuerdo? Así que en la PAC, la coherencia significa que todas clientes que pueden acceder a la base de datos siempre tendrá un vista consistente de los datos. Nadie va a ver dos cosas diferentes. ¿De acuerdo? Si veo a la base de datos, Estoy viendo la misma vista como mi compañero que ve la misma base de datos. Esa es la consistencia. 

Disponibilidad significa que si el base de datos en línea, si se puede llegar, que todos los clientes será siempre ser capaz de leer y escribir. ¿De acuerdo? Así que cada cliente que puede leer la base de datos siempre será capaz de leer datos de datos y escribir. Y si ese es el caso, es un sistema disponible. 

Y el tercer punto es lo que que llamamos tolerancia partición. ¿De acuerdo? Medios de tolerancia de reparto que el sistema funciona bien a pesar red física particiones entre los nodos. ¿De acuerdo? Así que los nodos del clúster no puede hablar el uno al otro, ¿qué sucede? Correcto. 

Bases de datos relacionales Así choose-- usted puede escoger dos de ellos. OKAY. Bases de datos relacionales Así que eligen ser consistentes y disponibles. Si la partición ocurre entre los DataNodes en el almacén de datos, la base de datos se bloquea. ¿Correcto? Simplemente va hacia abajo. OKAY. 

Y es por eso que tienen para crecer con las cajas más grandes. ¿Correcto? Porque hay no-- lo general, un clúster base de datos, no hay muchos de ellos que funcionan de esa manera. Pero la mayoría de las bases de datos de escala verticalmente dentro de una sola caja. Debido a que tienen que ser consistente y disponible. Si una partición iban a ser inyectado, entonces usted tendría que tomar una decisión. Usted tiene que hacer una elección entre ser coherente y disponible. 

Y eso es lo que las bases de datos NoSQL hacen. Correcto. Así que una base de datos NoSQL, se viene en dos sabores. Nos tener-- bien, viene en muchos sabores, pero viene con dos concepciones fundamentales characteristics-- lo que llamaríamos base de datos de PC, o una tolerancia consistente y partición sistema. Estos chicos tomar la decisión de que cuando los nodos pierden contacto entre sí, no vamos a permitir que gente escriba más. ¿De acuerdo? 

Hasta que se elimina la partición, se bloquea el acceso a escritura. Eso significa que no están disponibles. Son consistentes. Cuando vemos que partición inyectar sí mismo, ahora somos coherentes, porque no vamos para permitir el cambio de datos en dos lados de la partición de forma independiente el uno del otro. Tendremos que restablecer la comunicación antes de cualquier actualización de se deja que la de datos. ¿De acuerdo? 

El siguiente sabor sería un sistema AP, o un disponibles y se repartió sistema de tolerancia. Estos chicos no les importa. ¿Correcto? Cualquier nodo que recibe una escribimos, lo tomaremos. Así que estoy replicando mis datos a través de múltiples nodos. Estos nodos reciben un cliente, cliente viene en, dice, voy a escribir algunos datos. Nodo dice, no hay problema. El nodo junto a él consigue una escritura en el mismo registro, él va a decir que no hay problema. En algún lugar de nuevo en la parte de atrás, que los datos que va a replicar. Y entonces alguien va a realizar, uh-oh, que el sistema se dará cuenta de, uh-oh, ha habido una actualización de dos lados. qué hacemos? Y lo que hacen es, entonces, hacen algo que les permite resolver ese estado de datos. Y hablaremos de que, en la siguiente tabla. 

Cosa a destacar aquí. Y yo no voy a ser demasiado mucho en esto, porque este se mete en la teoría de los datos de profundidad. Pero hay una transaccional marco que se ejecuta en un sistema relacional que me permite hacer de forma segura las actualizaciones a múltiples entidades en la base de datos. Y esos cambios se producirán todos a la vez o no en absoluto. Y esto se llama transacciones ACID. ¿De acuerdo? 

ÁCIDO nos da la atomicidad, consistencia, el aislamiento y la durabilidad. ¿De acuerdo? Eso significa atómicas, transacciones, todo mis actualizaciones o bien ocurren o no lo hacen. La consistencia significa que la base de datos será siempre ser llevado a un constante estado después de una actualización. Nunca voy a dejar la base de datos en un mal estado después de aplicar una actualización. ¿De acuerdo? 

Así que es un poco diferente que la PAC consistencia. CAP consistencia significa toda mi clientes siempre pueden ver los datos. Significa que cuando la consistencia ACID una transacción ha hecho, de los datos buenos. Mis relaciones son todos buenos. Yo no voy a eliminar una fila padre y dejar un montón de niños huérfanos en alguna otra tabla. No puede suceder si soy coherente en una transacción de ácido. 

Aislamiento significa que las transacciones siempre ocurrir uno después del otro. El resultado final de los datos será el mismo estado como si esas transacciones que se emitieron simultáneamente fueron ejecutados en serie. Así que es de concurrencia control en la base de datos. Así que, básicamente, no puedo incrementar el mismo valor dos veces con dos operaciones. 

Pero si digo añadir 1 a este valor, y dos transacciones vienen en y tratar de hacerlo, una es va a llegar primero y el otro de un solo va a llegar después. Así que al final, he añadido dos. ¿Ves lo que quiero decir? OKAY. 

La durabilidad es bastante sencillo. Cuando la transacción se reconoce, es va a estar allí, incluso si el sistema se bloquea. Cuando ese sistema se recupera, que transacción que se cometió es en realidad va a estar allí. Así que esa es la garantía de transacciones ACID. Esas son muy buenas garantías para tener a una base de datos, pero vienen en ese costo. ¿Correcto? 

Debido a que el problema con este marco es si hay una partición de datos en el conjunto, tengo que tomar una decisión. Voy a tener que permitir actualizaciones de un lado o del otro. Y si eso sucede, entonces yo ya no soy de ir para ser capaz de mantener esas características. No van a ser consistente. No van a ser aislados. Aquí es donde se rompe para bases de datos relacionales. Esta es la razón relacional bases de datos escalar verticalmente. 

Por otro lado, tenemos lo que llama la tecnología BASE. Y estos son sus bases de datos NoSQL. Correcto. Así que tenemos nuestro CP, las bases de datos de AP. Y estos son lo que se llama básicamente disponible, estado blando, finalmente consistente. ¿De acuerdo? 

Básicamente disponible, porque son tolerantes partición. Siempre serán allí, incluso si hay una partición de red entre los nodos. Si puedo hablar con un nodo, estoy va a ser capaz de leer datos. ¿De acuerdo? No siempre podría ser capaz de escribir datos si soy una plataforma consistente. Pero voy a ser capaz de leer los datos. 

El estado blando indica que cuando leí que los datos, tal vez no sea el mismo que el resto de los nodos. Si el derecho se emitió en un nodo en otro lugar en el clúster y no se ha replicado en todo el racimo sin embargo, cuando leí que los datos, ese estado podría no ser consistente. Sin embargo, será finalmente consistente, lo que significa que cuando una escritura se hace al sistema, se replicará en todos los nodos. Y con el tiempo, ese estado será puesto en orden, y será un estado coherente. 

Ahora, CAP teorema realmente juega sólo en una condición. Esa condición es cuando esto sucede. Debido a que cada vez se está operando en modo normal, no hay ninguna partición, todo es coherente y disponible. Sólo se preocupe por la PAC cuando tenemos esa partición. Así que estos son raros. Pero, ¿cómo reacciona el sistema cuando los ocurren dictar qué tipo de sistema que estamos tratando. 

Así que echemos un vistazo a lo que se ve como para los sistemas de AP. ¿De acuerdo? Sistemas de AP son de dos tipos. Vienen en el sabor que es un amo amo, 100%, siempre disponible. Y vienen en el otro sabor, que dice: Sabes qué, yo me voy a preocupar acerca de esta cosa de particionamiento cuando se produce una partición real. De lo contrario, no va a ser primaria nodos que va a tomar los derechos. ¿De acuerdo? 

Así que si tenemos algo así como Cassandra. Cassandra sería un maestro maestra, vamos a escribir a cualquier nodo. ¿Así que lo que ocurre? Así que tengo un objeto en el base de datos que existe en dos nodos. Vamos a llamar a ese objeto S. Así que tenemos el estado de S. Tenemos algunas operaciones en S que están en curso. Cassandra me permite escribir en varios nodos. Así que digamos que recibo una escribir para s de dos nodos. Bueno, lo que termina sucediendo es llamamos a que un evento de partición. Puede que no haya una partición de red física. Pero debido al diseño del sistema, es en realidad particionar tan pronto como puedo obtener una escritura en dos nodos. No me está obligando a escribir todo a través de un nodo. Estoy escribiendo en dos nodos. ¿De acuerdo? 

Así que ahora tengo dos estados. ¿De acuerdo? Qué va a pasar es más pronto o más tarde, que va a ser un evento de replicación. No va a ser lo que llamado recuperación de la partición, el cual es donde estos dos estados vienen de nuevo juntos y no va a haber un algoritmo que se ejecuta dentro de la base de datos, decide qué hacer. ¿De acuerdo? Por defecto, última actualización gana en la mayoría de los sistemas de AP. Así que por lo general hay una algoritmo por defecto, lo que que ellos llaman una devolución de llamada función, algo que será llamado cuando esta condición se detecta para ejecutar alguna lógica para resolver ese conflicto. ¿De acuerdo? La devolución de llamada por defecto y por defecto resolver la mayoría de las bases de datos de AP en Es decir, ¿adivinen qué, marca de tiempo gana. Esta fue la última actualización. Me voy a poner esa actualización en ese país. Puedo volcar este disco que me objeto de dumping fuera en un registro de recuperación de modo que el usuario puede volver más tarde y decir, bueno, hubo una colisión. ¿Que pasó? Y en realidad se puede volcar un registro de todas las colisiones y las reversiones y ver qué pasa. 

Ahora, como usuario, también puede incluir lógica en esa devolución de llamada. Así que usted puede cambiar eso operación de devolución de llamada. Se puede decir, bueno, yo quiero para remediar estos datos. Y quiero tratar de fusionar esos dos registros. Pero eso depende de ti. La base de datos no sabe cómo hacerlo de forma predeterminada. La mayor parte del tiempo, lo único que la base de datos sabe que hacer es decir, éste fue el último registro. Ese es el que va a ganar, y ese es el valor que voy a poner. Una vez que la recuperación de la partición y la replicación se produce, tenemos nuestro estado, que ahora es el Primer, que es el estado de combinación de todos esos objetos. Así que los sistemas de AP tienen esto. Sistemas de CP no necesitan que preocuparse por esto. Porque tan pronto como llega una partición en juego, simplemente dejan de tomar escribe. ¿De acuerdo? Así que eso es muy fácil tratar de ser coherente cuando usted no acepta las actualizaciones. Eso es con los sistemas CP hacen. Correcto. 

Así que vamos a hablar un poco poco acerca de los patrones de acceso. Cuando hablamos de NoSQL, es todo sobre el patrón de acceso. Ahora, SQL es ad hoc, las consultas. Es almacén relacional. No tenemos que preocuparnos sobre el patrón de acceso. Escribo una consulta muy compleja. Se va y obtiene los datos. Eso es lo que esto se ve como, la normalización. 

Así que en esta estructura particular, estamos mirando un catálogo de productos. Tengo diferentes tipos de productos. Tengo libros. Tengo álbumes. Tengo vídeos. La relación entre los productos y cualquiera de estos libros, álbumes, y Vídeos de mesas es de 1: 1. ¿Correcto? Tengo un identificador de producto, y que corresponde identificación a un libro, un álbum o un vídeo. ¿De acuerdo? Eso es una relación 1: 1 a través de esas mesas. 

Ahora, todo lo que books-- tener es las propiedades de la raíz. No hay problema. Eso es genial. Uno a uno, relación, me sale todo los datos que necesita para describir ese libro. Álbumes Albums-- tienen pistas. Esto es lo que llamamos uno a muchos. Cada álbum podría tener muchas pistas. Así, por cada pista en el álbum, que podría tener otro récord en esta tabla secundaria. Así que puedo crear un registro en mi mesa de álbumes. Puedo crear varios registros en la tabla de pistas. Uno-a-muchos relación. 

Esta relación es lo que que llamamos de muchos a muchos. ¿De acuerdo? Usted ve que los actores podrían ser en muchas películas, muchos videos. Así que lo que hacemos es que ponemos este mapeo mesa, entre los que sólo mapas de la ID de actor para el ID de vídeo. Ahora puedo crear una consulta de las uniones videos a través actor de vídeo a los actores, y me da una buena lista de todas las películas y todos los actores que estaban en esa película. 

OKAY. Así que, aquí vamos. Uno-a-uno es el de nivel superior relación; uno-a-muchos, álbumes a las pistas; muchos a muchos. Esos son los tres de nivel superior relaciones en cualquier base de datos. Si usted sabe cómo los relaciones trabajan juntos, entonces usted sabe mucho sobre la base de datos ya. Así NoSQL funciona un poco diferente. Pensemos por un segundo lo que parece que ir a buscar todos mis productos. 

En un almacén relacional, yo que desee obtener todos mis productos en una lista de todos mis productos. Eso es un montón de preguntas. Tengo una consulta para todos mis libros. Tengo una pregunta de mis discos. Y tengo una consulta para todos mis videos. Y tengo que decirlo todos juntos en una lista y servir de nuevo hasta la aplicación que se soliciten. 

Para conseguir mis libros, me uno a Productos y Libros. Para obtener mis álbumes, llegué a unirse Productos, álbumes y canciones. Y para conseguir mis videos, tengo para unirse a los productos a los vídeos, unirse a través Actor Videos, y traer a los actores. Así que eso es tres consultas. Consultas muy complejas a ensamblar un conjunto de resultados. 

Eso es menos que óptimo. Por eso, cuando hablamos sobre una estructura de datos que es construido para ser agnóstico al acceso pattern-- bien eso es genial. Y se puede ver que esto es realmente agradable cómo hemos organizado los datos. ¿Y sabes qué? Sólo tengo un récord para un actor. 

Eso es genial. He deduplicado todos mis actores, y mantuve mis asociaciones en esta tabla de asignaciones. Sin embargo, obtener los datos fuera se convierte en caro. Estoy enviando la CPU en todo el sistema unirse a estas estructuras de datos junto ser capaz de tirar que volver datos. 

Entonces, ¿cómo hago para que todo eso? En NoSQL se trata agregación, no normalización. Por eso queremos decir que queremos apoyar el patrón de acceso. Si el patrón de acceso a las aplicaciones, Tengo que conseguir todos mis productos. Vamos a poner todos los productos en una sola mesa. Si pongo todos los productos en una tabla, Yo sólo puedo seleccionar todos los productos de esa mesa y me sale todo. Bueno, ¿cómo lo hago? Bueno, en NoSQL no hay estructura a la mesa. Hablaremos un poco sobre cómo funciona esto en Dynamo DB. Pero usted no tiene el mismo atributos y las mismas propiedades en cada hilera, en cada tema, como lo hace en una tabla de SQL. Y lo que esto me permite que hacer un montón de cosas y me da mucha flexibilidad. En este caso particular, tener mis documentos de productos. Y en este particular, ejemplo, todo es un documento en la tabla Productos. Y el producto de un libro puede tener un ID de tipo que especifica un libro. Y la aplicación cambiaría en ese ID. 

En el nivel de aplicación, voy para decir ¡oh, qué tipo de registro es esto? Oh, es un registro de libros. Registros de la Libreta tienen estas propiedades. Déjame crear un objeto de libro. Así que me voy a llenar el libro objeto con este concepto. Siguiente artículo viene y dice, ¿qué es este artículo? Bueno, este artículo es un álbum. Oh, tengo toda una diferente rutina de procesamiento para que, porque es un álbum. ¿Ves lo que quiero decir? 

Así que la aplicación tier-- I sólo tienes que seleccionar todos estos registros. Todos empiezan a entrar. Podrían ser todos los tipos diferentes. Y es la lógica de la aplicación que los conmutadores a través de esos tipos y decide cómo procesar ellos. 

Una vez más, por lo que estamos optimizando el esquema para el esquema de acceso. Lo estamos haciendo por colapso esas mesas. Básicamente estamos tomando estas estructuras normalizadas, y estamos construyendo estructuras jerárquicas. Dentro de cada uno de estos registros Voy a ver propiedades de la matriz. 

Dentro de este documento para los álbumes, Estoy viendo series de pistas. Esas pistas ahora become-- es básicamente esta tabla secundaria que existe aquí mismo en esta estructura. Así que usted puede hacer esto en DynamoDB. Usted puede hacer esto en MongoDB. Usted puede hacer esto en cualquier base de datos NoSQL. Crear este tipo de estructuras de datos jerárquicas que le permiten recuperar datos muy rápidamente porque ahora no tienen que conformarse. Al insertar una fila en las Pistas mesa, o una fila en la tabla Álbumes, Tengo que cumplir con ese esquema. Tengo que tener el atributo o la propiedad que se define en esa mesa. Cada uno de ellos, cuando inserto esa fila. Ese no es el caso en el NoSQL. 

Puedo tener totalmente diferente propiedades en todos los documentos que inserto en la colección. Así mecanismo muy poderoso. Y es realmente cómo optimizar el sistema. Porque ahora esa consulta, en lugar de unirse a todas estas tablas y la ejecución de una media docena de consultas a retirar los datos que necesito, Estoy ejecutando una consulta. Y estoy iteración a través de los conjunto de resultados. que te da una idea del poder de NoSQL. Voy a clase de ir de lado aquí y hablar un poco acerca de esto. Esto es más clase de la comercialización o la tecnología, como la comercialización de la tecnología tipo de discusión. Pero es importante entender porque si nos fijamos en la parte superior aquí en esta tabla, lo que estamos viendo es lo que llamamos el curva bombo tecnología. Y lo que esto significa es cosas nuevas entra en juego. La gente piensa que es genial. He resuelto todos mis problemas. 

Este podría ser el fin todo, ser todo para todo. Y comienzan a usarlo. Y dicen, esto no funciona. Esto no esta bien. El material viejo era mejor. Y vuelven a hacer las cosas como estaban. Y luego, finalmente, que vayan, ¿sabes qué? Este material no es tan malo. Oh, así es como funciona. Y una vez que averiguar cómo obras, empiezan a mejorar. 

Y lo curioso al respecto es, que tipo de líneas hasta qué que llamamos la curva de adopción de tecnología. Así que lo que pasa es que tenemos algunos gatillo tecnología tipo. En el caso de bases de datos, que es la presión de datos. Hablamos de los puntos altos de agua de la presión de los datos a través del tiempo. Cuando la presión que realiza un cierto datos punto, que es un disparador tecnología. 

Se está haciendo demasiado caro. Se tarda demasiado tiempo para procesar los datos. Necesitamos algo mejor. Usted obtiene los innovadores por ahí dando vueltas, tratando de averiguar cuál es la solución. ¿Cuál es la nueva idea? 

¿Cuál es la mejor alternativa manera de hacer esto? Y vienen con algo. Y la gente, el verdadero dolor, los chicos de la punta de lanza, que van a saltar por todas partes, porque necesitan una respuesta. Ahora lo que inevitablemente happens-- y está sucediendo ahora mismo en NoSQL. Lo veo todo el tiempo. 

Lo que pasa, inevitablemente, es la gente comienza a usar la nueva herramienta de la misma manera que utiliza la herramienta de edad. Y se dan cuenta de que no funciona tan bien. No puedo recordar quién era yo hablando con el día de hoy. Pero es como, cuando el martillo neumático fue inventado, la gente no swing más su cabeza para romper el hormigón. 

Pero eso es lo que hay pasando con NoSQL hoy. Si entras en la mayoría de tiendas, que están tratando de ser tiendas NoSQL. Lo que están haciendo es que están usando NoSQL, y están cargarlo llena de esquema relacional. Porque así es como diseñar bases de datos. Y están preguntando, ¿por qué es no llevar a cabo muy bien? Chico, esto apesta. Tuve que mantener todo mi une en-- es como, no, no. Mantener une? ¿Por qué están uniendo a los datos? Usted no se inscribe datos NoSQL. Usted agregada ella. 

Así que si quieres evitar esto, aprender cómo funciona la herramienta antes de que realmente empezar a usarlo. No tratar de utilizar las nuevas herramientas de la misma manera que utilizó las viejas herramientas. Vas a tener una mala experiencia. Y cada vez eso es lo que se trata. Cuando empezamos a venir aquí, es porque la gente descubierto cómo usar las herramientas. 

Ellos hicieron lo mismo cuando bases de datos relacionales se inventaron, y fueron reemplazando a los sistemas de archivos. Trataron de crear sistemas de archivos con bases de datos relacionales porque eso es lo entienden las personas. No funcionó. Así que la comprensión de las mejores prácticas de la tecnología que está trabajando es enorme. Muy importante. 

Así que vamos a entrar en DynamoDB. DynamoDB es de AWS totalmente gestionados plataforma NoSQL. ¿Qué significa gestionados totalmente significa? Esto significa que no es necesario realmente preocuparse de nada. 

Entras, le dices nosotros, que necesitamos una mesa. Se necesita tanta capacidad. Se pulsa el botón, y la provisión que toda la infraestructura detrás de la escena. Ahora que es enorme. 

Porque cuando hablas acerca de la expansión de una base de datos, Clústeres de datos NoSQL en escala, petabytes de funcionamiento, corriendo millones de transacciones por segundo, estas cosas no son pequeños racimos. Estamos hablando de miles de casos. La gestión de miles de casos, incluso instancias virtuales, es un verdadero dolor en el trasero. Quiero decir, pienso cada vez que un parche de sistema operativo sale o una nueva versión de la base de datos. Qué significa eso a usted operacionalmente? Eso significa que tienes 1200 servidores que necesitan ser actualizados. Ahora, incluso con la automatización, que puede llevar mucho tiempo. Eso puede causar una gran cantidad de dolores de cabeza operacionales, porque voy a tener servicios de abajo. 

Como puedo actualizar estas bases de datos, que podría hacer despliegues verde azul donde puedo implementar y actualizar la mitad de mi nodos y, a continuación, actualizar la otra mitad. Tome los abajo. Por lo tanto la gestión de la infraestructura escala es enormemente doloroso. Y AWS tomar que el dolor fuera de él. Y las bases de datos NoSQL puede ser extraordinariamente dolorosa debido a la manera en que la escala. 

Escala horizontal. Si usted desea conseguir un NoSQL grande base de datos, usted compra más nodos. Cada nodo que usted compra es otro dolor de cabeza operativa. Así que deje que alguien más lo haga por usted. AWS puede hacer eso. 

Apoyamos valores clave documento. Ahora no fuimos demasiado en en el otro gráfico. Hay un montón de diferentes sabores de NoSQL. Son todo tipo de conseguir munged juntos en este punto. Usted puede mirar en DynamoDB y decir que sí, los dos somos un documento y un valor clave almacenar este punto. Y usted puede discutir las características de uno sobre el otro. Para mí, mucho de esto es realmente de seis de la mitad de una docena de los otros. Cada una de estas tecnologías es una tecnología fina y una multa solución. Yo no diría que MongoDB es mejor o peor que Couch, a continuación, Cassandra, entonces Dynamo, o viceversa. Quiero decir, estos son sólo opciones. 

Es rápido y es consistente en cualquier escala. Así que este es uno de los más grandes bonificaciones que reciben con AWS. Con DynamoDB es la capacidad para obtener un solo dígito bajo latencia de milisegundos a cualquier escala. Ese fue un objetivo de diseño del sistema. Y tenemos clientes que están haciendo millones de transacciones por segundo. 

Ahora voy a ir a través de algunos de los casos de uso en pocos minutos aquí. Control-- acceso integrado tenemos lo que llamamos Identidad Access Management o IAM. Impregna todo sistema, todos los servicios que ofrece AWS. DynamoDB no es una excepción. Puede controlar el acceso a las tablas DynamoDB. A través de todas sus cuentas de AWS definición de funciones de acceso y permisos en la infraestructura de IAM. 

Y es un componente esencial en el lo que llamamos Evento Programación Driven. Ahora bien, este es un nuevo paradigma. 

AUDIENCIA: ¿Cómo es su tasa de verdad positivos frente a falsos negativos en su sistema de control de acceso? RICK HOULIHAN: Los verdaderos positivos frente a falsos negativos? AUDIENCIA: Volviendo lo usted debe devolver? A diferencia de vez en cuando no devuelve cuando debería validar? 

RICK HOULIHAN: No le podía decir eso. Si hay cualquier fallo alguno en que, No soy la persona para preguntar esa pregunta en particular. Pero eso es una buena pregunta. Sería curioso saber que yo, en realidad. 

Y así, de nuevo, nuevo paradigma es la programación orientada a eventos. Esta es la idea que pueda implementar aplicaciones complejas que puede operar una muy alta escala muy sin cualquier infraestructura de ningún tipo. Sin ningún tipo fijo infraestructura alguna. Y hablaremos un poco acerca de lo que eso significa, ya que llegar a la siguiente par de cartas. 

Lo primero que vamos a hacer es hablaremos de tablas. Tipos de datos API para Dynamo. Y la primera cosa que usted cuenta cuando nos fijamos en esto, si está familiarizado con cualquier base de datos, bases de datos tienen realmente dos tipos de APIs Yo lo llamaría. O dos conjuntos de API. Uno de ellos sería API administrativa. 

Las cosas que se ocupan de las funciones de la base de datos. Configuración del motor de almacenamiento, la configuración y la adición de tablas. base de datos de creación catálogos e instancias. Estos cosas-- en DynamoDB, que tienen muy cortos, listas cortas. 

Así que en otras bases de datos, usted puede ver a decenas de comandos, de administrativo comandos, para configurar estas opciones adicionales. En DynamoDB que no es necesario porque los no configura el sistema, lo que hacemos. Así que lo único que tiene que hacer es dime qué tamaño de la tabla Qué necesito. Así se obtiene una muy conjunto limitado de comandos. 

Usted recibe un CREATE TABLE actualización, Mesa, Eliminar la tabla, y describir la tabla. Esas son las únicas cosas lo que necesitas para DynamoDB. Usted no necesita un almacenamiento configuración del motor. No necesito que preocuparse acerca de la replicación. No necesito que preocuparse sharding. 

No necesito que preocuparse acerca de cualquiera de estas cosas. Lo hacemos todo por usted. Así que eso es una gran cantidad de sobrecarga eso es sólo levantó su plato. Luego tenemos los operadores CRUD. CRUD es algo de lo que llamar a la base de datos que es Crear, actualizar, eliminar operadores. Estos son el común las operaciones de base de datos. Cosas como punto de venta, consigue el artículo, actualización elementos, eliminar elementos, consulta por lotes, escanear. Si desea escanear toda la tabla. Tire todo lo de la mesa. Una de las cosas buenas de DynamoDB es que permite el escaneo paralelo. Así que en realidad se puede hacerme saber cuántos hilos desea ejecutar en esa exploración. Y podemos ejecutar esos hilos. Podemos girar que mira para arriba a través de múltiples hilos así que usted puede escanear toda la tabla espacio muy, muy rápidamente en DynamoDB. 

La otra API que tenemos es lo que llamamos nuestra API Arroyos. No vamos a hablar demasiado mucho de esto ahora. Tengo algo de contenido más tarde en la baraja sobre esto. Pero Streams es realmente un running-- pensar en él como el tiempo ordenó y registro de cambios de particiones. Todo lo que está sucediendo en la tabla se muestra en la secuencia. 

Cada escritura en la tabla aparece en la corriente. Usted puede leer esa corriente, y se pueden hacer cosas con él. Vamos a hablar de lo que tipos de cosas que usted ver con las cosas como la replicación, la creación de índices secundarios. Todo tipo de genial cosas que puedes hacer con eso. 

Tipos de datos. En DynamoDB, apoyamos tanto clave de valor y datos de documentos tipos. En el lado izquierdo de la pantalla aquí, tenemos nuestros tipos básicos. Tipos de valor clave. Estos son cadenas, números y los binarios. 

Así que sólo tres tipos básicos. Y entonces usted puede tener conjuntos de esos. Una de las cosas buenas de NoSQL es puede contener matrices como propiedades. Y con DynamoDB puede contener matrices de tipos básicos como una propiedad raíz. 

Y luego están los tipos de documentos. ¿Cuántas personas están familiarizados con JSON? Ustedes están familiarizados con JSON tanto? Se trata básicamente de JavaScript, Objeto, notación. Le permite, básicamente, definir una estructura jerárquica. 

Puede guardar un documento en JSON DynamoDB usando componentes comunes o bloques de construcción que están disponibles en la mayoría de los lenguajes de programación. Así que si usted tiene Java, eres mirando los mapas y listas. Puedo crear objetos que del mapa. Un mapa como valores clave almacenado como propiedades. Y podría tener listas de valores dentro de esas propiedades. Puede almacenar este complejo estructura jerarquica como un solo atributo de un elemento DynamoDB. 

Así tablas en DynamoDB, como la mayoría Bases de datos NoSQL, mesas tienen elementos. En MongoDB lo haría llamar a estos documentos. Y sería la base sofá. También una base de datos documental. Usted llama a estos documentos. Documentos o elementos tienen atributos. Pueden existir atributos o no existe en el artículo. En DynamoDB, hay un atributo obligatorio. Al igual que en una base de datos relacional, usted tiene una clave principal en la tabla. 

DynamoDB tiene lo que llamamos una clave hash. Clave hash debe ser único. Así que cuando me defino una tabla hash, básicamente lo que estoy diciendo es cada artículo tendrá una clave hash. Y cada tecla almohadilla debe ser único. 

Cada artículo se define por esa clave hash único. Y sólo puede haber una. Esto está bien, pero muchas veces lo que la gente necesita es que quieren es este hash clave para hacer un poco más que simplemente ser un identificador único. Muchas veces queremos utilizar esa clave hash como la parte superior de cubo agregación nivel. Y la manera de hacer eso es por añadiendo lo que llamamos una clave gama. 

Así que si es sólo un hash tabla, este debe ser único. Si se trata de una tabla hash y el rango, la combinación del hachís y la gama debe ser único. Así que pensar en ello de esta manera. Si tengo un foro. Y la forma tiene temas, tiene puestos, y tiene respuestas. 

Así que voy a tener un hash clave, que es el identificador de tema. Y yo podría tener una clave de gama, que es la ID de respuesta. De esta forma si quiero obtener toda la respuestas para determinado tema, Yo sólo puedo consultar el hash. Yo sólo puedo decir me da todo los elementos que tienen este hash. Y yo voy a poner todas las preguntas o publicarlos para ese tema en particular. Estas agrupaciones de primer nivel son muy importantes. Apoyan el acceso primario patrón de la aplicación. En términos generales, este es lo que queremos hacer. Queremos que table-- como se carga la tabla, queremos estructurar los datos dentro de la tabla de una manera tal que la aplicación puede muy recuperar rápidamente los resultados. Y a menudo la forma de hacerlo es para mantener estas agregaciones como nos insertar los datos. Básicamente, estamos extendiendo los datos en el cubo brillante, ya que viene en. 

Teclas Range permiten picadillo mí-- llaves tienen que haber igualdad. Cuando consulta una almohadilla, que tengo que decir dame un hash que es igual a esto. Cuando consulta una gama, que puede decir dame una gama que es el uso de cualquier tipo de rica operador que apoyamos. Dame todos los elementos para un hash. Es igual, mayor que, menos, qué empezar, ¿existe entre estos dos valores? Así que este tipo de consultas de rango que estamos siempre interesados ​​en. Ahora una cosa acerca de los datos, cuando nos fijamos en el acceso a los datos, cuando acceder a los datos, es Siempre se trata de una agregación. Siempre se trata de los registros que tienen que ver con esto. Dame todo lo que aquí Eso es-- todo las transacciones en esta tarjeta de crédito para el último mes. Eso es una agregación. 

Casi todo lo que haces en el base de datos es una especie de agregación. Así que ser capaz de ser capaz de definir estos cubos y darle estos van atributos para poder consultar en, esas consultas ricos apoyan muchos, muchos, muchos patrones de acceso de la aplicación. 

Así que la otra cosa la tecla almohadilla hace es que nos da un mecanismo para ser capaz de difundir los datos alrededor. Bases de datos NoSQL funcionan mejor cuando los datos son uniformemente distribuido en todo el clúster. ¿Cuántas personas son familiares con algoritmos hash? Cuando digo hash y un hashing-- porque un algoritmo de hash es una forma de ser capaz de generar un valor aleatorio de cualquier valor dado. Así que en este caso particular, el algoritmo de hash corremos es ND 5 basado. 

Y si tengo una identificación, y esto es mi clave hash, tengo 1, 2, 3. Cuando ejecuto el algoritmo de hash, que va a regresar y decir, bien 1 es igual a 7B, 2 es igual a 48, 3 es igual a CD. Están repartidos por todo el espacio de claves. Y ¿por qué haces esto? Debido a que se asegura de que puedo poner los registros a través de múltiples nodos. 

Si yo estoy haciendo esto incremental, 1, 2, 3. Y tengo un rango hash que carreras en este caso particular, un pequeño espacio de hash, que va desde 00 a FF, a continuación, los registros van a venir en y que van a ir a 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. ¿Lo que pasa? Cada inserto va al mismo nodo. ¿Ves lo que quiero decir? 

Porque cuando me separé el espacio, y yo extendí estos registros a través de, y la partición yo, yo voy a decir partición 1 tiene espacio de claves 0-54. Partición 2 es 55-89. Partición 3 es AA a FF. Así que si estoy usando linealmente incrementando Identificadores, se puede ver lo que está sucediendo. 1, 2, 3, 4, 5, 6, todo el camino hasta 54. Así como estoy golpeando la registros en el sistema, todo acaba yendo a un nodo. 

Eso no es bueno. Ese es un anti patrón. En MongoDB tienen este problema si usted no utiliza una clave hash. MongoDB le da la opción de hash el valor clave. Usted siempre debe hacer eso, si está utilizando un hash incrementando clave en MongoDB, o va a ser clavando cada escritura para un nodo, y se le limitando su rendimiento de escritura mal. 

AUDIENCIA: ¿Es que A9 169 en decimal? 

RICK HOULIHAN: Sí, es en algún lugar por allí. A9, yo no lo sé. Habría que conseguir mi binaria a la calculadora decimal. Mi cerebro no funciona de esa manera. AUDIENCIA: Sólo una rápida de sus comentarios Mongo. Así es el ID de objeto que viene nativa con Mongo hacer eso? RICK HOULIHAN: ¿Hace eso? Si se especifica la misma. Con MongoDB, usted tiene la opción. Puede specify-- cada documento en MongoDB tiene que tener un ID de subrayado. Ese es el valor único. 

En MongoDB puede especificar ya sea para discutir o no. Ellos sólo le dan la opción. Si usted sabe que es al azar, no hay problema. Usted no tiene que hacer eso. Si usted sabe que no es al azar, que está incrementando, y luego hacer el hash. 

Ahora lo que pasa hash, una vez que hash de un value-- y esto es por qué claves hash son siempre consultas únicas, porque he cambiado el valor, ahora no puede hacer una consulta gama. No puedo decir que es esto entre esto o aquello, debido a que el valor hash no va ser equivalente al valor real. Así que cuando usted hash que clave, es sólo la igualdad. Por eso, en clave hash DynamoDB consultas son siempre sólo la igualdad. 

Así que ahora en un rango key-- cuando agrego esa clave gama, esos registros claves alcance todos entran y que se almacenan en la misma partición. Así que son muy rápidamente, fácilmente recuperada porque este es el hachís, este es el rango. Y se ve todo con el mismo hash se almacena en el mismo espacio de partición. Usted puede usar esa clave gama para ayudar localizar sus datos cerca de su padre. Entonces, ¿qué estoy haciendo realmente aquí? Esta es una de uno a muchos relación. La relación entre una clave hash y la tecla de rango es de uno a muchos. Puedo tener varias claves hash. Sólo puedo tener rango múltiple claves dentro de cada tecla almohadilla. 

El hash define el padre, el rango define los niños. Así que usted puede ver que hay analógico aquí entre el constructo relacional y los mismos tipos de construye en NoSQL. La gente habla de NoSQL como no relacional. No es no relacional. Los datos siempre tiene relaciones. Esas relaciones simplemente se modelan de manera diferente. Vamos a hablar un poco poco acerca de la durabilidad. Cuando se escribe a DynamoDB, escribe son siempre tres vías replicado. Lo que significa que tenemos tres AZ de. AZ de son zonas de disponibilidad. Usted puede pensar en una disponibilidad Zona como un centro de datos o una colección de centros de datos. Estas cosas son geográficamente aislados unos de otros a través de diferentes zonas de fallas, a través de diferentes redes eléctricas y las llanuras de inundación. Un fallo en uno AZ no es va a acabar con el otro. Ellos también están vinculados junto con la fibra oscura. Es compatible con una sub 1 latencia de milisegundos entre AZS. Así replicaciones de datos en tiempo real capaz en múltiples AZS. 

Y muchas veces los despliegues múltiples AZ cumplir con los requisitos de alta disponibilidad de la mayoría de las organizaciones empresariales. Así DynamoDB se propaga a través de tres AZS por defecto. Sólo vamos al conocimiento de la escritura cuando dos de esos tres nodos vuelven y digo: Sí, lo tengo. ¿Porqué es eso? Debido a que en el lado de lectura sólo estamos voy a dar los datos de nuevo cuando lo hacemos a partir de dos nodos. 

Si estoy replicando en todo tres, y estoy leyendo de dos, Siempre estoy garantizado para tener al menos una de los que lee ser el más copia actualizada de los datos. Eso es lo que hace DynamoDB consistente. Ahora usted puede optar por activar aquellos consistentes lee fuera. En este caso voy a decir, Yo sólo voy a leer de un nodo. Y no puedo garantizar que va siendo los datos más actuales. 

Así que si una escritura está entrando, no ha replicado todavía, usted va a conseguir que la copia. Esa es una lectura finalmente coherente. Y lo que es eso es la mitad del costo. Así que esto es algo en que pensar. Cuando usted está leyendo DynamoDB, y está configurando su capacidad de lectura unidades, si se eligen con el tiempo lecturas consistentes, es mucho más barato, que es aproximadamente la mitad del costo. 

Y por lo que le ahorra dinero. Pero esa es su elección. Si quieres una lectura consistente o una lectura finalmente coherente. Eso es algo que se puede elegir. 

Vamos a hablar de los índices. Así mencionamos que agregación de nivel superior. Tenemos claves hash, y tenemos llaves alcance. Eso es bueno. Y eso es en la mesa principal, I nos dieron una clave hash, tengo una llave gama. 

Qué significa eso? Tengo un atributo que puede ejecutar consultas ricos contra. Es la clave gama. Los otros atributos en que item-- Puedo filtrar esos atributos. Pero yo no puedo hacer cosas similares, comienza con, o es mayor que. 

¿Cómo puedo hacer eso? Puedo crear un índice. Hay dos tipos de índices en DynamoDB. Un índice es realmente otra vista de la tabla. Y el índice secundario local. 

La primera de ellas hablaremos. Así que secundarias locales se coexistieron en la misma partición que los datos. Y como tales, son en el mismo nodo físico. Son lo que llamamos consistente. Significado, van a reconocer la escritura junto con la mesa. Cuando la escritura viene, vamos a escribir a través del índice. Vamos a escribir hasta la mesa, y luego vamos a reconocer. Así que eso es consistente. Una vez que la escritura ha sido reconocido de la mesa, está garantizado que la índice secundario locales tendrá la misma visión de los datos. Pero lo que permiten que haces es definir teclas de rango alternos. 

Tiene que usar el mismo hash tecla que la tabla principal, porque ellos son co-ubicado en la misma partición, y son consistentes. Pero puedo crear un índice con diferentes claves alcance. Así, por ejemplo, si yo tuviera un fabricante que tenía una mesa de piezas en bruto que entra. Y partes primas vienen en y que están agregados por el montaje. Y tal vez hay un retiro. 

Cualquier parte que fue hecho por este fabricante después de esta fecha, Tengo que tirar de mi línea. Puedo girar un índice que estaría buscando, agregando en la fecha de fabricación de esa parte en particular. Así que si mi mesa de alto nivel fue ya hash por el fabricante, tal vez se organizó en parte ID, I puede crear un índice de esa mesa como hash según el fabricante y oscilado en la fecha de fabricación. Y de esa manera yo podría decir, todo lo que fue fabricado entre estas fechas, Tengo que tirar de la línea. Así que eso es un índice secundario local. 

Estos tienen el efecto de limitando su espacio clave hash. Debido a que co-existido en el mismo nodo de almacenamiento, limitan la tecla almohadilla espacio para 10 gigabytes. DynamoDB, bajo la tablas, se particionar su mesa cada 10 gigabytes. Cuando usted pone 10 gigas de datos, nos ir [PHH], y añadimos otro nodo. 

No vamos a dividir el LSI en varias particiones. Vamos a dividir la tabla. Pero no vamos a dividir el LSI. Así que eso es algo importante entender es si lo estás haciendo muy, muy, muy grandes agregaciones, entonces usted va a estar limitada 10 gigabytes en su LSI. 

Si ese es el caso, podemos utilizar secundarios globales. Secundarias globales son realmente otra mesa. Existen completamente fuera de el lado de la tabla principal. Y ellos me permiten encontrar una completamente diferente estructura. Así que pensar en ello como se está insertando datos en dos mesas diferentes, estructurados de dos maneras diferentes. 

Puedo definir una totalmente diferente clave hash. Puedo definir una totalmente llave diferente rango. Y puedo ejecutar este de forma totalmente independiente. Como cuestión de hecho, tengo aprovisionado mi capacidad de lectura y escribir capacidad para mi índices secundarios globales de forma totalmente independiente de mi tabla principal. Si defino ese índice, le digo que la cantidad de lectura y escritura la capacidad que va a utilizar. 

Y eso es separada desde mi tabla principal. Ahora, tanto de los índices nos permiten no sólo definir claves de hash y de alcance, pero nos permiten proyectar valores adicionales. Así que si quiero leer el índice, y quiero conseguir algún conjunto de datos, No necesito volver a la principal tabla para obtener los atributos adicionales. Puedo proyectar aquellos adicional atributos en la tabla para apoyar el patrón de acceso. Sé que probablemente estamos llegando a algún Realmente, realmente-- entrar en la maleza aquí en algunas de estas cosas. Ahora tengo a la deriva fuera de esto. 

AUDIENCIA: [inaudible] clave --table quería decir era un hash? El hash original? Multi-lamas? 

RICK HOULIHAN: Sí. Sí. La clave de la tabla, básicamente, apunta de nuevo al tema. Así que un índice es un puntero de nuevo a los elementos originales en la mesa. Ahora usted puede elegir para construir un índice que sólo tiene la clave de la tabla, y no hay otras propiedades. ¿Y por qué podría yo hacer eso? Bueno, tal vez tengo artículos muy grandes. 

En realidad sólo necesito saber which-- mi patrón de acceso podría decir: los elementos que contienen esta propiedad? No es necesario devolver el artículo. Sólo necesito saber los elementos que contienen. Así que usted puede construir índices que sólo tienen la clave de la tabla. 

Pero eso es principalmente lo que un índice en la base de datos es para. Es para poder rápidamente identificar que registra, qué filas, las cuales los elementos de la tabla tienen las propiedades que estoy buscando. 

GSI, así que ¿cómo funcionan? GSI básicamente son asíncronas. La actualización entra en la mesa, A continuación, se actualiza la tabla de forma asíncrona toda su GSI. Esta es la razón por GSI son finalmente consistente. 

Es importante observar que cuando usted está construyendo GSI, y usted entiende que está creando otra dimensión de aggregation-- Ahora digamos que un buen ejemplo aquí es un fabricante. Creo que podría haber hablado un fabricante de dispositivos médicos. Fabricantes de dispositivos médicos muchas veces tienen partes serializados. Las partes que intervienen en la un reemplazo de cadera todo tener un pequeño número de serie en ellos. Y podrían tener millones y millones y miles de millones de piezas en todos los dispositivos que envían. Bueno, tienen que agregarse bajo diferentes dimensiones, todas las piezas en una asamblea, toda la partes que se hicieron en una determinada línea, todo las partes que vienen desde un cierto fabricante en una fecha determinada. Y estas agregaciones a veces levantarse en los miles de millones. 

Así que yo trabajo con algunos de estos chicos que están sufriendo porque están creando estas agregaciones ginormous en sus índices secundarios. Puede ser que tengan unas partes primas tabla que viene ya que sólo hash. Cada parte tiene un número de serie único. Yo uso el número de serie que el hash. Es hermoso. Mi tabla de datos en bruto se propaga todo el espacio de claves. Mi [? escribe ?] [? la ingestión?] es impresionante. Tengo una gran cantidad de datos. Entonces lo que hacen es que crean un GSI. Y digo yo, ¿sabes qué, tengo que ver todas las partes de este fabricante. Bueno, de repente estoy teniendo un billón de filas, y meterlos en un nodo, porque cuando Yo agregada como el ID del fabricante como el hachís, y el número de pieza como el rango, entonces de repente estoy poner mil millones de partes en lo que este fabricante me ha entregado. 

Eso puede causar una gran cantidad de presión sobre el GSI, de nuevo, porque estoy martillando un nodo. Estoy poniendo todo esto inserta en un nodo. Y eso es un caso real uso problemático. Ahora, tengo un buen diseño patrón de cómo evitar eso. Y ese es uno de los problemas que yo siempre trabajo con. Pero lo que sucede, es el GSI podría no tienen suficiente capacidad de escritura para ser capaz de empujar todos aquellos filas en un solo nodo. Y lo que sucede a continuación es la primaria, la tabla de clientes, la tabla principal será estrangulado debido a que el GSI no puede seguir el ritmo. Así que mi tasa de inserción será caer en la tabla principal como mi GSI trata de mantener el ritmo. 

Muy bien, así GSI de, LSI de, cuál debo utilizar? LSI de son consistentes. GSI de son finalmente consistente. Si eso está bien, recomiendo el uso de un GSI, son mucho más flexibles. LSI de se puede modelar como un GSI. Y si el tamaño de los datos por claves hash en su colección supera los 10 gigabytes, entonces usted va a querer usar ese GSI porque es sólo un límite duro. 

Muy bien, por lo que la escala. El rendimiento en el Dynamo DB, prestación lata [inaudible] rendimiento para una mesa. Tenemos clientes que tienen aprovisionado 60 billion-- están haciendo 60 mil millones de solicitudes, con regularidad funcionando a más de un millón solicitudes por segundo en nuestras mesas. En realidad no hay límite teórico a la cantidad de y la rapidez con la tabla se puede ejecutar en Dynamo DB. Hay algunos suave límites en su cuenta que ponemos allí, así que no volverse loco. Si desea más que, no es un problema. Vienes decirnos. Vamos a subir el dial. 

Cada cuenta está limitada a un cierto nivel en cada servicio, justo al lado del palo por lo que las personas no se vuelven locos se meten en problemas. No hay límite de tamaño. Usted puede poner cualquier número de elementos en una tabla. El tamaño de un elemento es limitado a 400 kilobytes cada uno, eso sería no tema los atributos. Así que la suma de todos los atributos está limitado a 400 kilobytes. Y, de nuevo, tenemos ese pequeño problema de LSI con el límite de 10 gigabytes por hash. AUDIENCIA: Pequeño número, estoy desaparecidos lo que me estás diciendo, que es-- AUDIENCIA: ¡Oh, 400 kilobytes es el tamaño máximo por artículo. Así que un elemento tiene todos los atributos. Así que 400 k es el tamaño total de ese artículo, 400 kilobytes. Así que de todos los atributos combinados, todos los datos eso es en todos esos atributos, enrollado en un tamaño total, Actualmente la actualidad el límite de elementos es de 400 k. Así escalado de nuevo, logrado a través de la partición. El rendimiento se aprovisiona a nivel de tabla. Y no hay realmente dos perillas. Hemos leído la capacidad y escribir capacidad. 

Así que estos se ajustan independientemente uno del otro. Medida de RCU estrictamente lee consistente. OK, así que si usted está diciendo que quiero 1000 UCR de esos son estrictamente coherente, esos son lecturas consistentes. Si dices que quiero eventual coherente lee, usted puede aprovisionar 1000 UCR de, vas para llegar finalmente 2000 lee consistente. Y la mitad del precio de los finalmente consistir en lee. 

Una vez más, ajustado independientemente uno del otro. Y tienen la throughput-- Si usted consume 100% de su mando a distancia, usted no va a afectar el disponibilidad de sus derechos. Por lo que son completamente independientes entre sí. Muy bien, así que una de las cosas que Mencioné brevemente estaba estrangulando. Throttling es malo. Throttling indica mal sin SQL. Hay cosas que podemos hacer para ayudar a aliviar el estrangulamiento que están experimentando. Pero la mejor solución a esto es que echemos Una mirada a lo que está haciendo, porque hay un anti-patrón en juego aquí. 

Estas cosas, cosas como no uniforme las cargas de trabajo, teclas de acceso rápido, particiones calientes. Estoy golpeando un espacio clave particular muy duro por alguna razón en particular. ¿Por qué estoy haciendo esto? Vamos a darse cuenta de eso. Estoy mezclando mis datos calientes con los datos fríos. Yo voy a dejar mis cuadros consiguen enorme, pero no hay realmente sólo algunos subconjunto de los datos eso es muy interesante para mí. Así que para los datos de registro, por ejemplo, una gran cantidad de clientes, que reciben datos de registro todos los días. Tienen una enorme cantidad de datos de registro. 

Si acaba de vertido todo ese registro datos en una gran mesa, con el tiempo esa mesa se va a poner masiva. Pero estoy realmente sólo interesado en últimas 24 horas, los últimos siete días, los últimos 30 días. Cualquiera que sea la ventana de tiempo que estoy interesado en mirar para el caso de que me molesta, o el caso de que es interesante para mí, esa es la única ocasión en la ventana que necesito. Así que ¿por qué estoy poniendo 10 años el valor de los datos de registro en la tabla? Lo que hace es la mesa del fragmento. 

Se pone enorme. Comienza tendido a través de miles de nodos. Y puesto que su capacidad es tan baja, que está en realidad la limitación de velocidad en cada uno de esos nodos individuales. Así que vamos a empezar a mirar cómo hacemos rodamos esa mesa. ¿Cómo gestionamos los datos un poco mejor evitar estos problemas. Y ¿qué se parecen? Esto es lo que parece. Esto es lo malo NoSQL se parece. 

Recibí una tecla de acceso rápido aquí. Si nos fijamos en el lado aquí, estos son todos mis particiones. Tengo 16 particiones aquí en esta base de datos particular. Lo hacemos todo el tiempo. Corro esto para los clientes de todos los tiempos. Se llama el mapa de calor. Mapa de calor me dice lo que eres el acceso a su espacio de claves. Y lo que esto me está diciendo es que hay una almohadilla especial que este chico le gusta una muchísimo, porque es golpeándolo muy, muy difícil. 

Así que el azul es agradable. Nos gusta azul. No nos gusta el rojo. Red donde la presión se incorpora al 100%. 100%, ahora vas a ser estrangulado. Así que cada vez que hay líneas rojas como esto-- y no se trata sólo Dynamo DB-- cada base de datos NoSQL tiene este problema. No son anti-patrones que pueden conducir este tipo de condiciones. Lo que hago es que trabajo con los clientes para aliviar estas condiciones. 

Y ¿qué se parecen? Y esto es cada vez más fuera del Dynamo DB rendimiento, pero es realmente llegar el máximo provecho de NoSQL. Esto no se limita a Dynamo. Esto es lo definitely-- solía trabajar en Mongo. Estoy familiarizado con muchas plataformas NoSQL. Cada uno tiene este tipo de los problemas claves calientes. Para sacar el máximo partido de cualquier NoSQL base de datos, específicamente Dynamo DB, desea crear las tablas donde el elemento clave hash tiene un gran número de valores distintos, un alto grado de cardinalidad. Porque eso significa que estoy escribiendo a un montón de diferentes cubos. 

Los más cubos estoy escrito a, más probable Estoy a difundir que la carga de escritura o leer cargar a cabo a través de múltiples nodos, es más probable que soy de tener una de alto rendimiento en la mesa. Y luego quiero que los valores sean solicitado de manera bastante uniforme en el tiempo y uniformemente como al azar como sea posible. Bueno, eso es bastante interesante, porque no puedo realmente control cuando los usuarios entran. Así que basta con decir, si difundimos cosas fuera de todo el espacio de claves, probablemente estaremos en mejor forma. 

Hay una cierta cantidad de tiempo de entrega que no vas ser capaces de control. Pero esos son en realidad el dos dimensiones que tenemos, espacio, el acceso de manera uniforme propagación, el tiempo, las solicitudes lleguen uniformemente espaciadas en el tiempo. Y si esos dos se están cumpliendo las condiciones, entonces eso es lo que es va a parecer. Esto es mucho más bonito. Estamos muy felices aquí. Tenemos un esquema de acceso muy parejo. Sí, tal vez usted está recibiendo un poca presión de vez en cuando, pero nada realmente demasiado extensa. Así que es increíble la cantidad de veces, cuando trabajo con los clientes, esa primera gráfica la gran roja bar y todo lo feo de color amarillo que es por todo el lugar, nos conseguir hecho con el ejercicio después de un par de meses de la re-arquitectura, están corriendo la misma exacta carga de trabajo en la misma carga exacta. Y esto es lo que está buscando como ahora. Así que lo que obtienes con NoSQL es un esquema de datos que es absolutamente atado al patrón de acceso. 

Y usted puede optimizar ese esquema de datos para apoyar ese patrón de acceso. Si no lo hace, entonces usted va ver esos tipos de problemas con esas teclas de acceso rápido. 

AUDIENCIA: Bueno, inevitablemente, algunos lugares van a ser más caliente que otros. 

RICK HOULIHAN: Siempre. Siempre. Sí, quiero decir que siempre hay A-- y otra vez, no hay algunos patrones de diseño que van a obtener a través de que va a hablar sobre cómo tratar con estas súper grandes agregaciones. Quiero decir, tengo que tenerlas, ¿cómo nos ocupamos de ellos? Tengo un muy buen caso de uso que vamos a hablar de eso. 

Muy bien, así que vamos a hablar sobre algunos clientes ahora. Estos chicos son Adroll. No sé si estás familiarizados con Adroll. Es probable que los vea mucho en el navegador. Son ad re-focalización, son el negocio más grande ad re-focalización por ahí. Normalmente salen regularmente sobre 60 mil millones de transacciones por día. Están haciendo más de un millón transacciones por segundo. Tienen una mesa bastante simple estructura, la mesa más concurrida. Es básicamente un clave hash es la galleta, la gama es el demográfico categoría, y luego el tercer atributo es la puntuación. 

Así que todos tenemos cookies nuestro navegador de estos chicos. Y cuando vas a un comercio participante, que básicamente se anotan en todo diversas categorías demográficas. Cuando vas a un sitio web y usted dice que quiero ver esta ad-- o básicamente no dices que-- pero cuando vas a la página web ellos dicen que usted desea ver este anuncio. Y van conseguir ese anuncio de Adroll. Adroll que mira hacia arriba en su mesa. Ellos encuentran que su cookie. Los anunciantes dicen ellos, me quieren a alguien que es de mediana edad, Hombre de 40 años de edad, en los deportes. Y te anotan en esos datos demográficos y deciden si es o no eso es un buen anuncio para ti. 

Ahora tienen un SLA con sus proveedores de publicidad para proporcionar sub-10 milisegundos respuesta en cada petición individual. Así que están usando Dynamo DB para esto. Ellos nos están golpeando un millón de solicitudes por segundo. Son capaces de hacer todo su búsquedas, triage todos esos datos, y conseguir que el enlace añadir de nuevo a ese anunciante en menos de 10 milisegundos. Es realmente bastante fenomenal aplicación que tienen. 

Estos chicos actually-- son éstos los chicos. No estoy seguro de si se trata de estos chicos. Podría ser que estos chicos. Básicamente nosotros-- dije que no, me no creo que eran ellos. Creo que fue otra persona. Yo estaba trabajando con un al cliente que me dijo que ahora que han ido a Dynamo DB, son gastar más dinero en bocadillos para su equipo de desarrollo de cada mes lo que gastan en su base de datos. Así que él se puede dar una idea de los ahorros de costes que se puede obtener en el Dynamo DB es enorme. Muy bien, Dropcam es otra compañía. Estos tipo es tipo de-- si usted piensa de Internet de las cosas, Dropcam es básicamente el vídeo de seguridad de Internet. Usted pone su cámara por ahí. La cámara tiene un detector de movimiento. Alguien viene, desencadena un punto de referencia. Cámara empieza a grabar durante un tiempo hasta no detecta ningún movimiento más. Pone ese video en el internet. 

Dropcam era una empresa que es básicamente cambiado a Dynamo DB porque estaban experimentando enormes dolores de crecimiento. Y lo que nos dijeron, repentinamente petabytes de datos. No tenían idea de su servicio sería tan exitoso. Más de vídeo de entrada de YouTube es lo que estos chicos están recibiendo. Utilizan DynamoDB seguir hasta el metadatos en todos sus puntos clave de vídeo. 

Así que tienen cubos S3 que empujan todos los artefactos binarios en. Y luego tienen Registros Dynamo DB que señalar a la gente a los tres objetos S3. Cuando necesitan para mirar un video, se ven hasta el registro en Dynamo DB. Hacer clic en el enlace. Que tire hacia abajo el video de S3. Así que eso es algo de lo que esto se parece. Y esto es directamente de su equipo. 

Dynamo DB reduce su tiempo de entrega de eventos de vídeo de cinco a 10 segundos. En su tienda relacional de edad, solían tener que ir y ejecutar múltiples consultas complejas a la figura qué vídeos para tirar abajo, a menos de 50 milisegundos. Así que es increíble, increíble cuánto rendimiento usted puede conseguir cuando optimizar y sintoniza la base de datos subyacente para apoyar el patrón de acceso. Halfbrick, estos chicos, ¿qué es, Fruit Ninja Supongo que es lo suyo. Que todas las carreras y Dynamo DB. Y estos chicos, que son una gran equipo de desarrollo, gran desarrollo Tienda. 

No es un buen equipo de operaciones. Ellos no tienen mucho de los recursos de operación. Ellos estaban luchando tratando de mantener su infraestructura de aplicaciones hasta y en ejecución. Ellos vinieron a nosotros. Se veían en ese Dynamo DB. Ellos dijeron, eso es para nosotros. Construyeron su totalidad marco de aplicación de la misma. Algunos comentarios muy bonitos aquí Del equipo de su capacidad ahora a centrarse en la creación el juego y no tener que mantener la infraestructura, que se estaba convirtiendo en una cantidad enorme de los gastos generales para su equipo. Así que esto es algo que-- el beneficio que se obtiene de Dynamo DB. 

Muy bien, entrar en modelado de datos aquí. Y hablamos un poco acerca de este uno a uno, uno a muchos, y muchos de muchas relaciones de tipo. Y ¿cómo mantener los de Dynamo. En Dynamo DB usamos índices, hablando en general, para girar los datos de un sabor a la otra. Claves hash, llaves alcance, y los índices. 

En este particular, ejemplo, como la mayoría de los estados tener un requisito de licencia que Sólo una licencia de un conductor por persona. Usted no puede ir a conseguir dos controlador de licencias en el estado de Boston. Yo no puedo hacerlo en Texas. Eso es algo de la manera que es. Y así en el DMV, tenemos las búsquedas, que desee buscar la licencia de conducir por el número de seguro social. Quiero ver los detalles de usuario por número de licencia de conducir. 

Así que puede ser que tengamos la mesa de un usuario que tiene una clave hash en el número de serie, o el número de seguro social, y varios atributos definidos en el artículo. Ahora en esa tabla I podría definir un GSI que mueve de un tirón que alrededor del que dice que quiero una clave hash en la licencia y después todos los demás artículos. Ahora si quiero consultar y encontrar la número de licencia para cualquier Social dada Número de Seguro, puedo consultar la tabla principal. 

Si quiero consultar y quiero para conseguir la seguridad social número o otros atributos por una número de licencia, puedo consultar el GSI. Ese modelo es que uno una relación. Sólo un muy simple GSI, voltear esas cosas. Ahora, hablar de uno a muchos. Uno de muchos es, básicamente, su clave gama hash. De dónde sacamos mucho con este de casos de uso es datos del monitor. Los datos del monitor viene en regulares intervalo, como Internet de las cosas. Siempre nos dan todos estos registros viniendo en todo el tiempo. 

Y quiero encontrar todas las lecturas entre un período de tiempo determinado. Es una consulta muy común en infraestructura de monitoreo. La manera de ir sobre que es encontrar un sencilla estructura de la tabla, una tabla. Tengo una tabla de mediciones del dispositivo con una clave hash en el identificador de dispositivo. Y tengo una clave de rango en la marca de tiempo, o en este caso, la épica. Y eso me permite ejecutar complejas consultas en esa clave gama y devolver los registros que son en relación con el resultado propuse que yo estoy buscando. Y es que uno construye a muchos relación en la tabla principal utilizando la clave hash, estructura clave gama. 

Así que eso es algo construido en la tabla de Dynamo DB. Cuando defino un hash y la gama t mesa, estoy la definición de una relación de uno a muchos. Es una relación padre-hijo. 

Vamos a hablar de muchos a muchas relaciones. Y para este ejemplo en particular, de nuevo, vamos a utilizar GSI de. Y vamos a hablar de los juegos escenario en el que tengo un usuario determinado. Quiero saber todos los juegos que que ha registrado a favor o jugando en. Y para un determinado juego, me que desee encontrar todos los usuarios. Entonces, ¿cómo lo hago? Mi mesa juegos de usuario, voy tener una clave hash del ID de usuario y una clave gama del juego. 

Así, un usuario puede tener varios juegos. Es un uno a muchos relación entre el usuario y los partidos en los que juega. Y luego en el GSI, Voy a la FLIP que alrededor. Voy hash en el juego y Voy a oscilar en el usuario. Así que si quiero obtener toda la juego el usuario de jugar en, Voy a consultar la tabla principal. Si quiero conseguir todos los usuarios que están jugando un juego en particular, Yo consultar el GSI. Así que ya ves cómo hacemos esto? Usted construye de estos GSI para apoyar la de caso de uso, la aplicación, el acceso patrón, la aplicación. 

Si tengo que consultar en esta dimensión, vamos me crea un índice en esa dimensión. Si no lo hago, no me importa. Y dependiendo del caso de uso, I puede necesitar el índice o yo no podría. Si es una simple uno a muchos, la tabla principal está muy bien. Si tengo que hacer esto a muchos a muchos de, o que tienen que hacer una para unos, entonces tal vez lo necesito al segundo índice. Así que todo depende de lo que estoy tratando de hacer y lo que yo estoy tratando de conseguir consumado. 

Probablemente no voy a gastar demasiado mucho tiempo hablando de documentos. Esto pone un poco, probablemente, más profundo que tenemos que entrar. Vamos a hablar un poco sobre la rica expresión de consulta. Así que en Dynamo DB tenemos la capacidad de crear lo que llamamos expresiones de proyección. Expresiones de proyección son simplemente recogiendo los campos o los valores que desea mostrar. OK, así que hago una selección. Hago una consulta contra Dynamo DB. Y digo yo, ¿sabes qué, espectáculo me sólo las cinco estrellas comentarios para este producto en particular. Así que eso es todo lo que quiero ver. No quiero ver a toda la otros atributos de la fila, Sólo quiero ver esto. Es como en SQL cuando decir selecto estrella o de la mesa, usted consigue todo. Cuando digo seleccione el nombre de tabla, sólo tengo un atributo. Es el mismo tipo de cosa en Dynamo DB u otras bases de datos NoSQL. Expresiones Filtrar me permiten básicamente cortar el resultado establecido. Así que hago una consulta. Consulta puede volver con 500 artículos. Pero yo sólo quiero que los elementos que tienen un atributo que dice esto. OK, así que vamos a filtrar hacia fuera los artículos que no concuerdan con esa consulta particular. Así que tenemos expresiones de filtro. 

Expresiones filtro puede ser ejecutado en cualquier atributo. No son como consultas de rango. Raise consultas son más selectivos. Consultas Filtrar me requieren para ir obtener todo el conjunto de resultados y después tallar los datos que yo no quiero. ¿Por qué es importante? Porque he leído todo. En una consulta, voy a leer y que va a ser un gigante sobre los datos. Y luego voy a tallar lo que necesito. Y si sólo estoy tallando un par de filas, entonces eso está bien. No es tan ineficiente. 

Pero si estoy leyendo toda una pila de datos, sólo para labrarse un artículo, entonces yo voy a ser mejor fuera mediante una consulta gama, porque es mucho más selectivo. Se me va a ahorrar un montón de dinero, porque tengo que pagar por esa lectura. Cuando los resultados que viene de vuelta cruzar ese alambre podría ser más pequeño, pero yo estoy pagando por la lectura. Así entender cómo que está recibiendo los datos. Eso es muy importante en Dynamo DB. 

Las expresiones condicionales, esto es lo que que se podría llamar el bloqueo optimista. Actualización SI EXISTE, o si este valor es equivalente a lo especifico. Y si tengo una marca de tiempo en un registro, podría leer los datos. Yo podría cambiar esos datos. Yo podría ir de escritura que volver a la base de datos. Si alguien ha cambiado el registro, la marca de tiempo podría haber cambiado. Y de esa manera mi condicional actualización podría decir de actualización Si la marca de tiempo es igual a este. O la actualización fallará porque alguien actualizado el registro en el ínterin. 

Eso es lo que llamamos el bloqueo optimista. Esto significa que alguien puede entrar y cambiarla, y yo voy a detectarlo cuando vuelva a escribir. Y entonces puedo realmente leído que datos y decir, ¡oh, cambió esto. Tengo que dar cuenta de eso. Y puedo cambiar los datos de mi grabar y aplicar otra actualización. Así que usted puede coger los incrementales cambios que se producen entre el momento que lea los datos y la el tiempo es posible escribir los datos. 

AUDIENCIA: ¿Y el filtro expresión en realidad no significa en el número o no-- 

[Interponiendo VOCES] RICK HOULIHAN: No lo haré tener demasiado en esto. Esta es una palabra clave reservada. La vista libras es una reserva palabra clave en Dynamo DB. Cada base de datos tiene su propio reservados nombres para colecciones que no se puede utilizar. Dynamo DB, si especifica una libra frente a esto, puede definir los nombres arriba. Este es un valor de referencia. Probablemente no sea la mejor sintaxis para tener hasta allí para esta discusión, porque se mete en algunos real-- Yo he estado hablando más sobre eso en un nivel más profundo. 

Pero basta con decir, esto podría sean consulta escanear donde views-- ni vistas libras es mayor que 10. Es un valor numérico, sí. Si quieres, podemos hablar de que después de la discusión. Muy bien, así que estamos metiendo algunos escenarios en las mejores prácticas donde vamos a hablar acerca de algunas aplicaciones aquí. ¿Cuáles son los casos de uso para Dynamo DB. ¿Cuáles son el diseño patrones en Dynamo DB. 

Y el primero que vamos a hablar es el Internet de las cosas. Así que tenemos una gran cantidad de-- supongo, lo que es it-- más del 50% del tráfico en Internet en estos días en realidad es generado por las máquinas, procesos automatizados y no por seres humanos. Quiero decir esta cosa esta cosa que que llevas en el bolsillo, la cantidad de datos que esa cosa es enviar realmente todo sin ti sabiendo que es absolutamente increíble. Su ubicación, la información acerca de qué tan rápido se va. ¿Cómo crees que Google Maps obras cuando te dicen lo que el tráfico es. Es porque hay millones y millones de personas que conducen alrededor con los teléfonos que están enviando datos en todo lugar todo el tiempo. Así que una de las cosas sobre este tipo de datos que viene en, datos de monitorización, registro los datos, los datos de series de tiempo, es que es por lo general sólo es interesante por un poco de tiempo. Después de ese tiempo, es no tan interesante. Así que hablamos, no dejes esas mesas crecer sin límites. La idea aquí es que a lo mejor tengo 24 horas de valor de los acontecimientos en mi mesa caliente. Y esa mesa caliente va a ser aprovisionado a un ritmo muy alto, porque está teniendo una gran cantidad de datos. Se trata de tomar una gran cantidad de datos y estoy leyendo mucho. Tengo un montón de funcionamiento consultas que se ejecutan en contra de que los datos. 

Después de 24 horas, bueno, sé qué, no me importa. Así que tal vez cada rollo medianoche mi mesa a una nueva tabla y yo desabastecer esta tabla. Y voy a tomar de la UCR y Abajo de WCU porque 24 horas después No estoy corriendo hasta consultas en esos datos. Así que me voy a ahorrar dinero. Y tal vez 30 días después no lo hago incluso necesidad de preocuparse por todo. Yo podría tomar la UMM de todo el camino a uno, porque sabes qué, es nunca va a quedar por escrito a. Los datos son de 30 días de edad. Nunca cambia. 

Y casi nunca va a conseguir leer, así que vamos a tomar ese UCR hasta 10. Y yo estoy ahorrando un montón de dinero en este de datos, y sólo para pagar mis datos calientes. Así que eso es lo más importante para buscar en cuando nos fijamos en una serie temporal datos que entran en el volumen. Estas son estrategias. Ahora, yo podría dejarlo todos van a la misma mesa y dejar que la mesa crezca. Con el tiempo, voy a ver los problemas de rendimiento. Voy a tener que empezar a archivar algunos de que los datos de la mesa, cualquier cosa. 

Vamos mucho mejor diseñar la aplicación para que pueda operar de esta manera derecha. Así que es sólo automático en el código de aplicación. A la medianoche cada noche rueda de la mesa. Tal vez lo que necesito es un deslizamiento ventana de 24 horas de datos. A continuación, sobre una base regular estoy llamando a los datos de la mesa. Estoy recorte con un Cron trabajo y me estoy poniendo en estas otras tablas, lo que sea que necesites. Así que si un vuelco funciona, eso es genial. Si no, recortarlo. Pero vamos a mantener esos datos en caliente lejos de sus datos fríos. Le ahorrará mucho dinero y hacer sus cuadros más rendimiento. Así que lo siguiente que vamos a hablar aproximadamente es el catálogo de productos. Catálogo de productos es caso de uso muy común. Esto es en realidad un patrón muy común que vamos a ver en una variedad de cosas. Ya sabes, para Twitter ejemplo, un tweet caliente. Todo el mundo viene y agarrando ese tweet. Catálogo de productos, tengo una venta. Tengo una venta caliente. Tengo 70.000 solicitudes por la segunda venida de un producto Descripción de mi catálogo de productos. Vemos esto en la venta al por menor operación bastante. Entonces, ¿cómo podemos hacer frente a eso? No hay manera de lidiar con eso. Todos mis usuarios quieren ver la misma pieza de datos. Están están llegando, al mismo tiempo. Y todos están haciendo peticiones para la misma pieza de datos. Esto me da esa tecla de acceso rápido, que rojo grande raya en mi carta que no nos gusta. Y eso es lo que parece. Así que a través de mi espacio de claves que estoy recibiendo martillado en los artículos de la venta. Me estoy poniendo nada en ningún otro lugar. 

¿Cómo puedo solucionar este problema? Bueno, nos aliviamos esto con caché. Cache, que puso básicamente un in-memory partición en frente de la base de datos. Hemos logrado [Inaudible] caché, cómo puede configurar su propia caché, [inaudible] cache [? d,?] lo que quieras. Pon eso en frente de la base de datos. Y de esa manera usted puede almacenar los datos de esas teclas de acceso rápido en ese caché espacio y leer a través de la memoria caché. 

Y entonces la mayoría de tus lecturas empezar a buscar de esta manera. Conseguí todos estos aciertos de caché aquí y yo no tengo nada pasa aquí abajo porque la base de datos está sentado detrás de la caché y nunca lee vienen a través. Si cambio de los datos de la base de datos, tengo que actualizar la caché. Podemos usar algo como vapores de hacer eso. Y voy a explicar cómo funciona. Muy bien, la mensajería. Correo electrónico, todos usamos correo electrónico. 

Este es un muy buen ejemplo. Tenemos una especie de tabla de mensajes. Y llegamos bandeja de entrada y bandeja de salida. Esto es lo que el SQL haría parecerse a construir esa bandeja de entrada. Es como que usamos el mismo tipo de la estrategia de utilizar GSI de, GSI de para mi bandeja de entrada y mi bandeja de salida. Así que me dieron mensajes primas procedentes en mi tabla de mensajes. Y la primera aproximación a este podría ser, por ejemplo, está bien, no hay problema. Tengo mensajes primas. Mensajes próximos [inaudible], ID de mensaje, que es grande. Esa es mi hash único. Voy a crear de dos GSI de uno para mi bandeja de entrada, uno para mi buzón de salida. Y lo primero que voy a hacer es que me voy a decir mi clave hash es va a ser el receptor y Voy a organizar en la fecha. Esto es fantástico. Tengo mi bonita vista aquí. Pero hay un pequeño problema aquí. Y llegas a tener esto en bases de datos relacionales, así. Llamaron a la partición vertical. Usted quiere mantener sus datos grande lejos de sus pocos datos. 

Y la razón es porque tengo que ve a leer los artículos para obtener los atributos. Y si mis órganos son todos aquí, luego de leer unos pocos artículos si mi longitud del cuerpo es un promedio de 256 kilobytes cada uno, las matemáticas se pone muy fea. Así que digo quiero leer la bandeja de entrada de David. Bandeja de entrada de David tiene 50 artículos. El promedio y el tamaño es de 256 kilobytes. Aquí está mi relación de conversión para la UCR de es cuatro kilobytes. 

OK, vamos a ir con lee finalmente consistente. Todavía estoy comiendo 1600 RCU de sólo para leer la bandeja de entrada de David. Ay. Bien, ahora vamos a pensar acerca de cómo funciona la aplicación. Si estoy en una aplicación de correo electrónico y Estoy buscando a mi bandeja de entrada, y miro el cuerpo de cada mensaje, no, yo estoy mirando a los resúmenes. Estoy mirando sólo los encabezados. Así que vamos a construir una estructura de tabla que se parece más a eso. 

Así que aquí está la información que mi flujo de trabajo necesita. Está en mi bandeja de entrada de GSI. Es la fecha, el remitente, el tema, y ​​luego el ID de mensaje, que apunta volver a la tabla de mensajes donde puedo conseguir el cuerpo. Bueno, estos serían los ID de registro. Ellos señalar de nuevo a la ID de elementos sobre la mesa Dynamo DB. Cada índice siempre creates-- siempre tiene el elemento ID como parte de-- que viene con el índice. 

Correcto. AUDIENCIA: Se dice que donde se almacena? RICK HOULIHAN: Sí, dice exactly-- eso es exactamente lo que hace. Se dice que aquí está mi disco re. Y que va a señalar de nuevo a mi disco re. Exactamente. OK, así que ahora mi bandeja de entrada es en realidad mucho más pequeño. Y esto apoya realidad el flujo de trabajo de una aplicación de correo electrónico. Así que mi bandeja de entrada, hago clic. Que avanzo y hago clic en el mensaje, eso es cuando tengo que ir a buscar el cuerpo, porque yo voy a ir a un punto de vista diferente. Así que si usted piensa sobre el tipo de MVC marco, modelo vista controlador. 

El modelo contiene la datos que las necesidades vista y el controlador interactúa con. Cuando cambio la trama, al Puedo cambiar la perspectiva, que está bien para volver a la servidor y repoblar el modelo, porque eso es lo que espera el usuario. Cuando cambian puntos de vista, que es cuando podemos volver a la base de datos. Así de correo electrónico, haga clic en. Estoy buscando el cuerpo. Ida y vuelta. Ve a buscar el cuerpo. 

Leo mucho menos datos. Yo sólo estoy leyendo los cuerpos que David necesita cuando las necesita. Y no me quemo en 1600 UCR de simplemente para mostrar su bandeja de entrada. Así que ahora que-- este es el camino que LSI o GSI-- lo siento, GSI, iba a salir. Tenemos nuestra hachís en el destinatario. Tenemos la llave de rango en la fecha. Y tenemos los atributos proyectados que sólo tenemos que apoyar a la vista. 

Giramos por que en el buzón de salida. Hash en el remitente. Y en esencia, tenemos la muy agradable, vista limpia. Y es que basically-- tener este agradable mensajes tabla que está siendo difundido muy bien porque es sólo hachís, ID de mensaje hash. Y tenemos dos índices que están girando fuera de dicho cuadro. Muy bien, así que la idea aquí no es hacer mantener a los grandes datos y esta pequeña datos juntos. Partición vertical, particionar las tablas. No lea los datos que usted no tiene que. Muy bien, los juegos. A todos nos gusta los juegos. Por lo menos me gustan los juegos entonces. Así que algunas de las cosas que nos ocupamos cuando estamos pensando en el juego, ¿no? Gaming estos días, especialmente móvil juegos, tiene que ver con el pensamiento. Y voy a girar aquí poco lejos de DynamoDB. Voy a traer Parte de la discusión alrededor de algunos de los otras tecnologías de AWS. 

Pero la idea de juego es pensar acerca en términos de API, API que son, en términos generales, HTTP y JSON. Es la forma de juegos móviles tipo de interactuar con sus extremos traseros. Lo hacen JSON publicación. Obtienen los datos, y es todo, en términos generales, en las API JSON agradables. 

Cosas como conseguir amigos, consiguen los datos de la tabla de posiciones, de cambio, contenido generado por el usuario, hacer retroceder al sistema, estos son los tipos de cosas que vamos a hacer. Datos activo binario, estos datos podría no sentarse en la base de datos. Esto podría sentarse en una almacén de objetos, ¿verdad? Pero la base de datos se va a terminar diciendo al sistema, diciendo la aplicación dónde ir a buscarlo. E inevitablemente, multijugador servidores, infraestructura back-end, y diseñado para alta disponibilidad y escalabilidad. Así que estas son las cosas que todos queremos en la infraestructura de juego hoy. 

Así que echemos un vistazo a lo que parece. Consiguió un extremo posterior del núcleo, muy sencillo. Tenemos un sistema de aquí con múltiples zonas de disponibilidad. Hablamos de AZS como being-- pensar de ellos como centros de datos independientes. Más de un centro de datos por AZ, pero eso está bien, sólo pensar en ellos como datos independiente centros que están geográficamente y se aisló fallo. 

Vamos a tener un casos pareja EC2. Vamos a tener algún servidor back-end. Tal vez si usted es un legado arquitectura, estamos utilizando lo que llamamos RDS, servicios de bases de datos relacionales. Podría ser MSSQL, MySQL, o algo así. Esta es la manera muchas de las aplicaciones hoy son diseñados. 

Bien podríamos desear ir con esto es cuando escalamos a cabo. Vamos a seguir adelante y poner el cubo S3 hasta allí. Y ese cubo S3, en vez de servir hasta los objetos de nuestro servers-- podríamos hacer eso. Pones toda tu binaria objetos en sus servidores y puede utilizar los servidores casos para servir que los datos arriba. Pero eso es bastante caro. 

Mejor manera de hacerlo es seguir adelante y poner los objetos en un cubo de S3. S3 es una repositorios de objetos. Está construido específicamente para sirviendo este tipo de cosas. Y que solicitan los clientes directamente desde esos cubos de objeto, descargar los servidores. Así que estamos empezando a escalar aquí. 

Ahora que tenemos los usuarios de todo el mundo. Tengo usuarios. Necesito tener contenido localmente situado cerca de estos usuarios, ¿no? He creado un cubo S3 como mi repositorio de código fuente. Y voy a frente que con la distribución CloudFront. 

CloudFront es un CD y un Red de entrega de contenidos. Básicamente se toma los datos que especifique y almacena en caché todo en internet para que los usuarios de todo el mundo pueden tener una respuesta muy rápida cuando solicitan esos objetos. 

Para que pueda obtener una idea. Estás tipo de aprovechamiento de todo el aspectos de AWS aquí para hacer esto. Y finalmente, nos tiramos en un grupo de escala automática. Así que nuestros casos AC2 de nuestros servidores de juego, cuando empiezan a conseguir más concurrido y cada vez más ocupado, ellos sólo hacen girar otra ejemplo, girar otra instancia, girar otra instancia. Así que la tecnología AWS tiene, es le permite especificar los parámetros alrededor de la cual los servidores crecerá. Así que usted puede tener un número n de servidores por ahí en un momento dado. Y si la carga se va, que va a reducir el tamaño, el número se reducirá. Y si la carga se vuelve, que va a volver a crecer hacia fuera, elásticamente. 

Así que esto se ve muy bien. Tenemos una gran cantidad de instancias de EC2. Podemos poner en caché delante de las bases de datos, tratar de acelerar las bases de datos. El siguiente punto de presión normalmente la gente ve es que la escala de un juego utilizando un sistema de base de datos relacional. Por Dios, la base de datos rendimiento es terrible. ¿Cómo podemos mejorar eso? Vamos a tratar de poner caché frente a eso. 

Bueno, caché no funciona tan grande en los juegos, ¿verdad? Para los juegos, la escritura es doloroso. Los juegos son muy escriben pesado. Caché no funciona cuando estás escribir pesada porque tienes siempre tiene que actualizar la caché. Actualiza la caché, es irrelevante para ser el almacenamiento en caché. En realidad es solo un trabajo extra. 

Entonces, ¿dónde vamos aquí? Tienes un gran cuello de botella allá en la base de datos. Y el lugar para ir obviamente está particionado. La partición no es fácil de hacer cuando estás se trata de bases de datos relacionales. Con las bases de datos relacionales, eres responsable de la gestión, de manera efectiva, el espacio de claves. ¿Estás diciendo que los usuarios entre A y M ir aquí, entre N y Z van allí. Y usted está cambiando a través de la aplicación. Así que usted está tratando con esta fuente de datos de la partición. Usted tiene limitaciones transaccionales que no abarcan las particiones. Tienes todo tipo de desorden que eres se trata de ahí abajo tratando para hacer frente a escalar y la construcción de una infraestructura más grande. Es simplemente no es divertido. 

AUDIENCIA: Entonces, ¿estás diciendo que aumentando los puntos de origen acelera ¿el proceso? RICK HOULIHAN: El aumento? Puntos Fuente: AUDIENCIA. RICK HOULIHAN: puntos de origen? AUDIENCIA: A partir de la información, donde la información está viniendo? RICK HOULIHAN: No. Lo que estoy diciendo es el aumento de la número de particiones en el almacén de datos mejora el rendimiento. Entonces, ¿qué está pasando aquí es que los usuarios que entra en la instancia EC2 aquí, así, si necesito un usuario esa es la A a la M, voy a ir aquí. Desde N hasta p, voy a ir aquí. Desde P hasta Z, voy a ir aquí. 

AUDIENCIA: OK, así que esos son los todos los almacenados en diferentes nodos? 

RICK HOULIHAN: Sí. Piense en esto como diferentes silos de datos. Así que tienes que hacer esto. Si usted está tratando de hacer esto, si usted está tratando a escala en una plataforma relacional, esto es lo que estás haciendo. Usted está tomando los datos y que está a cortarlo. Y usted está al otro lado de la partición varias instancias de la base de datos. Y va a administrar todo lo que en el nivel de aplicación. No es divertido. Entonces, ¿qué es lo que queremos ir? Queremos ir DynamoDB, logró plenamente, Almacén de datos NoSQL, rendimiento disposición. Utilizamos índices secundarios. Se trata básicamente de HTTP API y incluye soporte de documentos. Así que usted no tiene que preocuparse nada de eso partición. Lo hacemos todo por usted. Así que ahora, en cambio, simplemente escribir en la tabla. Si la tabla tiene que ser dividido, eso sucede detrás de las escenas. Usted está completamente aislado de que como desarrollador. Así que vamos a hablar de algunos de los casos de uso que nos encontramos en los juegos, común escenarios de juego, tabla de clasificación. Así que tienes a los usuarios a llegar, los BoardNames que son en adelante, las calificaciones de este usuario. Podríamos estar hash en la identificación de usuario, y luego tenemos variedad en el juego. Así que cada usuario quiere ver todo el juego que ha jugado y toda su puntuación más alta a través de todo el juego. Así que ese es su clasificación personal. 

Ahora quiero ir y quiero get-- por lo que obtener estas tablas de clasificación personales. Lo que quiero hacer es ir a buscar la puntuación más alta entre todos los usuarios. Entonces, ¿cómo lo hago? Cuando se hash en mi disco la ID de usuario, osciló en el juego, así que voy a seguir adelante y reestructurar, crear un GSI, y yo voy a reestructurar esos datos. 

Ahora me voy para discutir sobre la BoardName, que es el juego. Y yo voy a ir a la puntuación más alta. Y ahora que he creado diferentes cubos. Estoy usando la misma mesa, los mismos datos del elemento. Pero estoy creando un cubo que da me una agregación de puntuación máxima por juego. 

Y puedo consultar esa mesa para obtener esa información. Así que me he fijado que el patrón de consulta hasta con el apoyo de un índice secundario. Ahora pueden ordenarse por BoardName y ordenados por topscore, dependiendo. Así se puede ver, se trata de tipos de los casos de uso que obtiene en los videojuegos. Otro buen caso de uso que obtenemos en los juegos es premios y que ha ganado los premios. Y este es un gran caso de uso donde nos llamamos índices dispersos. Escasos son los índices capacidad de generar un índice que no necesariamente contener cada artículo sobre la mesa. ¿Y por qué no? Debido a que el atributo que está siendo indexada no existe en cada artículo. 

Así que en este particular, caso de uso, lo que estoy diciendo, Sabes qué, voy a crear un atributo llamado Premio. Y yo voy a dar a cada usuario que tiene un premio que atribuyen. Los usuarios que no tienen premios son No va a tener ese atributo. Así que cuando creo el índice, los únicos usuarios que se van a mostrar en el índice son los que realmente han ganado premios. Así que eso es una gran manera de poder para crear índices filtrados que son muy, muy selectivo que no lo hacen que índice de toda la tabla. 

Así que nos estamos bajo el tiempo aquí. Voy a seguir adelante y saltar y omitir este escenario. Hable un poco sobre-- 

AUDIENCIA: ¿Puedo hacer una pregunta rápida? Uno es escribir pesado? RICK HOULIHAN: ¿Qué es? AUDIENCIA: Escriba pesado. RICK HOULIHAN: Escribir pesado. Déjame ver. 

AUDIENCIA: ¿O es que no algo que usted puede simplemente voz a en cuestión de segundos? RICK HOULIHAN: Vamos a través del escenario electoral. No está tan mal. ¿Ustedes tienen un par de minutos? OKAY. 

Así que vamos a hablar acerca de la votación. Así que la votación en tiempo real, tenemos requisitos para votar. Los requisitos son que permitamos cada persona a votar sólo una vez. Queremos que nadie sea capaz cambiar su voto. Queremos que la agregación en tiempo real y el análisis de datos demográficos que nosotros vamos a ser mostrando a los usuarios en el sitio. 

Piense en este escenario. Trabajamos mucho de la realidad Programas de televisión donde están haciendo este tipo exacto de las cosas. Así que usted puede pensar en el escenario, tenemos millones y millones niñas de adolescentes allí con sus teléfonos celulares y el voto, y la votación, y votar por quienquiera que sean encontrar a ser el más popular. Así que estos son algunos de los requisitos que se agoten. 

Y así, la primera toma en la solución de este problema sería la de construir un aplicación muy simple. Así que tengo esta aplicación. Tengo algunos votantes que hay. Vienen en, que lleguen a la aplicación de la votación. Tengo un poco de mesa califican prima Sólo voy a volcar esos votos en. Voy a tener algún agregado mesa de votos que Haré mi análisis y los datos demográficos, y vamos a poner todo esto en ese país. 

Y esto es muy bueno. La vida es buena. De buena hasta que nos damos cuenta que la vida siempre hay uno o dos las personas que son populares en una elección. Hay sólo una o dos cosas que la gente realmente se preocupan. Y si usted está votando en escala, de repente estoy va a estar golpeando a la mierda de dos candidatos, uno o dos candidatos. Un número muy limitado de artículos personas encuentran para ser popular. 

Este no es un buen patrón de diseño. Esto es realmente una patrón de diseño muy malo porque crea exactamente lo que habló de que era teclas de acceso rápido. Teclas de acceso son algo que no nos gusta. 

Entonces, ¿cómo solucionarlo? Y realmente, la forma de solucionar este problema es mediante la adopción de esos cubos candidatos y para cada candidato que tenemos, vamos a añadir un valor aleatorio, algo que sabemos, al azar valor entre uno y 100, entre 100 y 1.000, o entre uno y 1.000, Sin embargo muchos valores aleatorios que quieren anexar en el extremo de ese candidato. 

Y ¿qué he hecho realmente entonces? Si estoy usando el ID de candidato el cubo a los votos totales, si he añadido un azar número al final de eso, He creado ahora 10 cubos, un cien cubos, mil cubos que estoy agregando califican de ancho. 

Así que tengo millones y millones, y millones de registros procedentes de para estos candidatos, ahora estoy difundiendo esos votos en todo A_1 Candidato a través A_100 Candidato, porque cada vez que un voto entra, Estoy generando un azar valor entre uno y 100. Estoy viradas sobre el extremo de la candidato a esa persona de votar a favor. Estoy de dumping en ese cubo. 

Ahora en la parte trasera, lo sé que me dieron cien cubos. Así que cuando me quiero ir por delante y agregar los votos, He leído de todos los cubos. Así que sigo adelante y añadir. Y entonces yo recojo la dispersión donde salgo y digo bueno, usted sabe lo que, la clave de este candidato espacios es más de cien cubos. Voy a reunir toda la los votos de los cien cubos. Voy a agregar ellos y voy a decir, Candidato A tiene ahora recuento total de votos de x. 

Ahora tanto la escritura consulta y la consulta de lectura están muy bien distribuida porque yo estoy escribiendo otro lado y yo estoy leyendo a través de cientos de llaves. No estoy escribiendo y la lectura a través de una clave ahora. Así que eso es un gran modelo. 

Esto es en realidad probablemente uno del diseño más importante las pautas de escala en NoSQL. Usted verá este tipo de patrón de diseño de todos los sabores. MongoDB, DynamoDB, no lo hace importa, todos tenemos que hacer esto. Porque cuando se trata con esos enormes agregaciones, usted tiene que encontrar una manera de esparcirán por todo baldes. Así que esta es la forma de hacer eso. Muy bien, así que lo que que estás haciendo en este momento es lo que está operando fuera de lectura costo para escribir escalabilidad. El costo de mi lectura es un poco más complejo y tengo que ir a leer a partir de un cien cubos en lugar de uno. Pero soy capaz de escribir. Y mi rendimiento, mi escritura rendimiento es increíble. Así que es por lo general una valiosa técnica para escalar DynamoDB, o cualquier base de datos NoSQL para el caso. Entonces nos dimos cuenta de cómo escalar ella. Y nos dimos cuenta de cómo eliminar las llaves calientes. Y esto es fantástico. Y tenemos este bonito sistema. Y nos ha dado de votación muy correcto porque tenemos registro de voto de-dupe. Está construido en DynamoDB. Hablamos de los derechos condicionales. 

Cuando un votante entra, pone una inserción en la tabla, insertan con su credencial de elector, si tratan de insertar otra votación, Hago una escritura condicional. Digamos solamente escribir este si esto no existe. Así que tan pronto como veo que que el voto de golpear la mesa, nadie más va a ser capaz de poner su voto en. Y eso es fantástico. Y estamos incrementando nuestros contadores de candidatos. Y estamos haciendo nuestro demografía y todo eso. ¿Pero qué sucede si mi aplicación se cae? Ahora, de repente votos están entrando, y yo no saben si están recibiendo procesados en mis análisis y demografía nunca más. Y cuando la aplicación vuelve, ¿cómo diablos voy a saber lo que califican tienen sido procesado y ¿por dónde empiezo? 

Así que este es un problema real cuando empezar a mirar este tipo de escenario. ¿Y cómo se resuelve esto? Resolvemos con lo que llamar DynamoDB Arroyos. Corrientes se ordena la vez y registro de cambios particionado de cada acceso a la mesa, cada escritura el acceso a la tabla. Todos los datos que se escriben en el tabla aparece en la secuencia. 

Se trata básicamente de una cola de 24 horas. Los productos que lleguen al arroyo, viven durante 24 horas. Se pueden leer varias veces. Garantizado para ser entregados sólo una vez a la corriente, se podía leer un número n de veces. Así que sin embargo muchos procesos que deseas consumir esos datos, se puede consumir. Aparecerá cada actualización. Cada escritura sólo se aparecer una vez en la secuencia. Así que usted no tiene que preocuparse acerca del procesamiento de dos veces Del mismo proceso. 

Está estrictamente ordenado por artículo. Cuando decimos que el tiempo ordenado y se repartió, verás por partición en la secuencia. Verá artículos, actualizaciones en orden. No estamos garantizando sobre el arroyo que eres va a poner cada transacción en el orden a través de artículos. 

Así arroyos son idempotente. ¿Tenemos todos sabemos lo idempotente significa? Idempotente significa que usted puede hacerlo otra y otra y otra vez. El resultado va a ser el mismo. 

Streams son idempotente, pero tienen que ser jugado desde el punto de partida, dondequiera que usted elija, hasta el final, o que no se traducirá en los mismos valores. 

Lo mismo con MongoDB. MongoDB tiene una construcción que ellos llaman el oplog. Es la misma construcción exacta. Muchas bases de datos NoSQL tener este constructo. Lo usan para hacer las cosas como la replicación, que es exactamente lo que hacemos con las corrientes. AUDIENCIA: Tal vez un pregunta herética, pero hablar de aplicaciones haciendo de suelo así sucesivamente. Son corrientes garantizados para Nunca posiblemente bajar? RICK HOULIHAN: Sí, arroyos están garantizados para no bajar. Gestionamos la infraestructura detrás. arroyos automáticamente implementar en su grupo de escala automática. Vamos a ir a través de una pequeña poco acerca de lo que sucede. 

No debería decir que no son garantizado para no bajar. Los elementos están garantizados a aparecer en la corriente. Y la corriente será accesible. Entonces, ¿qué se cae o se vuelve arriba, eso pasa por debajo. Se Cubiertas está bien. Muy bien, por lo que obtener diferentes tipos de vista de la pantalla. Los tipos de vista que son importantes para un programador normalmente son, ¿qué era? Tengo la vieja visión. Cuando una actualización golpea la mesa, que va a empujar la antigua visión de la corriente lo que los datos se pueden archivar o cambio control, identificación cambio, cambio administración. 

La nueva imagen, lo que es ahora, después de la actualización, que es otro tipo de vista puedes obtener. Usted puede obtener tanto las viejas y nuevas imágenes. Tal vez los dos quiera. Quiero ver lo que era. Quiero ver lo que ha cambiado a. 

Tengo un tipo de cumplimiento del proceso que se ejecuta. Tiene que verificar que Cuando estas cosas cambian, que están dentro de ciertos límites o dentro de ciertos parámetros. 

Y entonces tal vez sólo necesidad de saber lo que ha cambiado. No me importa lo que el tema cambió. No necesito a necesitar saber lo atribuye cambiado. Sólo necesito saber que los artículos están siendo tocados. Así que estos son los tipos de vistas que se baje la corriente y se puede interactuar. 

La aplicación que consume la corriente, esto es una especie de la forma en que esto funciona. Cliente DynamoDB pida enviar datos a las tablas. Streams desplegar en lo que llamamos fragmentos. Fragmentos se escalan independientemente de la mesa. Ellos no se alinean completamente a las particiones de tu mesa. Y la razón por la cual es porque se alinean a la capacidad, la corriente la capacidad de la mesa. 

Se despliegan en su propio grupo de escalado automático, y comienzan a girar a cabo en función de la cantidad de escrituras están entrando, cuántos reads-- realidad es escribe. No hay reads-- sino cómo muchas escrituras están llegando. 

Y luego en la parte posterior fin, tenemos lo que llamar a un KCL o Kinesis Client Library. Kinesis es un flujo de datos tecnología de procesamiento de Amazon. Y arroyos se construye en eso. 

Así se utiliza un KCL habilitado aplicación leer la corriente. La biblioteca de clientes Kinesis realidad gestiona los trabajadores para usted. Y también hace algunos cosas interesantes. Se va a crear algunas tablas hasta en su espacio de tabla DynamoDB para rastrear qué artículos han sido procesados. Así de esta manera si se cae de nuevo, si cae una y viene y se pone se puso de pie, se puede determinar dónde era que en la tramitación de la corriente. 

Eso es muy importante cuando usted está hablando de replicación. Necesito saber lo los datos se ha procesado y lo que los datos aún no se ha procesado. Así que la biblioteca KCL para los flujos voluntad le dará una gran cantidad de esa funcionalidad. Se ocupa de todo el servicio de limpieza. Se pone de pie a un trabajador por cada fragmento. Se crea una tabla administrativa para cada fragmento, por cada trabajador. Y a medida que los trabajadores de incendios, mantienen esas mesas para que sepa este registro fue leída y procesada. Y luego de esa manera si el proceso muere y viene de nuevo en línea, puede reanudar justo donde despegó. 

Así que usamos esto para replicación cruzada región. Muchos clientes tienen la necesidad de mover datos o partes de sus tablas de datos torno a las diferentes regiones. Hay nueve regiones alrededor del mundo. Así que podría haber un yo need-- podría tener los usuarios en Asia, los usuarios en la costa este de los Estados Unidos. Tienen diferentes datos que necesita ser distribuido localmente. Y tal vez un usuario vuela desde Asia a los Estados Unidos, y quiero replicar sus datos con él. Así que cuando él se baja del avión, que tiene una buena experiencia en el uso de su aplicación móvil. 

Puede utilizar la región cruz biblioteca de replicación para hacer esto. Básicamente tenemos proporcionado dos tecnologías. Uno es una aplicación de consola que pueda ponerse de pie en su propia instancia EC2. Se ejecuta la replicación puro. Y luego os dimos la biblioteca. La biblioteca se puede utilizar para construir su propia aplicación si querer hacer cosas locas con ese data-- filtro, replicar sólo parte de ella, rotar los datos, moverse en un diferente de mesa, así sucesivamente y así sucesivamente. Así que eso es algo de lo que parece. 

DynamoDB Streams puede haber procesado por lo que llamamos Lambda. Hemos mencionado un poco acerca de eventos arquitecturas de aplicaciones accionadas. Lambda es un componente clave de eso. Lambda es el código que dispara la demanda en respuesta a un evento en particular. Uno de esos eventos podría ser una registro que aparece en la secuencia. Si un registro aparece en la corriente, vamos a llamar esta función Java. Bueno, este es JavaScript y Lambda apoya Node.js, Java, Python, y pronto apoyar otros idiomas también. Y basta con decir, es de código puro. escribir En Java, se define una clase. Usted aprieta el JAR arriba en Lambda. Y a continuación, se especifica qué clase llamar en respuesta a qué evento. Y entonces la infraestructura Lambda detrás que se ejecutará ese código. 

Ese código puede procesar registros fuera de la corriente. Puede hacer lo que quiera con él. En este ejemplo en particular, todos estamos realmente haciendo es registrar los atributos. Pero esto es sólo código. El código puede hacer cualquier cosa, ¿verdad? 

Así que usted puede girar esos datos. Puede crear una vista derivada. Si se trata de una estructura de documento, usted puede aplanar la estructura. Puede crear índices alternativos. Todos los tipos de cosas que usted puede ver con las corrientes DynamoDB. 

Y realmente, eso es lo que parece. Para que pueda obtener esas actualizaciones entrando. Están saliendo de la cadena. Son leídos por la función de Lambda. Están girando los datos y empujándola hacia arriba en las tablas derivadas, notificar a sistemas externos de cambio, y empujando datos en ElastiCache. 

Hablamos de cómo poner la caché en frente de la base de datos para que las ventas guión. Bueno, ¿qué pasa si actualizar la descripción del artículo? Bueno, si yo tuviera un Lambda función que se ejecuta en esa mesa, si actualizo la descripción del artículo, que va a recoger el registro de la corriente, y que va a actualizar el ElastiCache instancia con los nuevos datos. Así que eso es una gran cantidad de lo que hacemos con Lambda. Es código pegamento, conectores. Y lo que realmente da la capacidad de lanzar y para ejecutar aplicaciones muy complejas sin un servidor dedicado infraestructura, que es realmente genial. 

Así que vamos a volver a nuestro en tiempo real la arquitectura de votación. Esto es nuevo y mejorado con nuestro arroyos y KCL habilitado aplicación. Igual que antes, podemos manejar cualquier escala de las elecciones. Nos gusta esto. Estamos haciendo fuera frunces de dispersión a través de múltiples cubos. Tenemos bloqueo optimista pasando. Podemos mantener nuestros votantes cambien sus votos. Sólo pueden votar sólo una vez. Esto es fantástico. Tolerancia a fallos en tiempo real, agregación escalable ahora. Si la cosa se cae, se sabe dónde para reiniciar en sí cuando se trata de una copia de seguridad, ya estamos usando la aplicación KCL. Y entonces también podemos usar esa Aplicación KCL para empujar datos fuera al desplazamiento al rojo para otros análisis de aplicaciones, o el uso MapReduce los elásticos para ejecutar agregaciones de streaming en tiempo real fuera de esos datos. 

Así que estas son las cosas que nosotros no han hablado mucho. Pero son adicionales tecnologías que vienen tener cuando estás buscando en estos tipos de escenarios. 

Muy bien, así que eso es todo análisis con DynamoDB Arroyos. Usted puede obtener de-dupe datos, hacer todo tipo de cosas bonitas, los datos agregados en memoria, crear esas tablas derivadas. Eso es un caso de uso enorme que muchos de los clientes están involucrados con, tomando el anidada propiedades de los documentos JSON y la creación de índices adicionales. 

Estamos en el final. Gracias por su paciencia conmigo. Así que vamos a hablar de arquitectura de referencia. DynamoDB se encuentra en medio de lo gran parte de la infraestructura de AWS. Básicamente, usted puede conectarlo hasta lo que quieras. Las aplicaciones creadas usando Dynamo incluye Lambda, ElastiCache, CloudSearch, empujar los datos hacia elástico MapReduce, importación y exportación de DynamoDB en S3, todos los tipos de flujos de trabajo. Pero probablemente la mejor cosa de que hablar, y esto es lo que es realmente interesante es cuando hablar de aplicaciones por eventos. 

Este es un ejemplo de un proyecto interno que tenemos cuando estamos en realidad publicación para recoger resultados de la encuesta. Así que en un enlace de correo electrónico que que enviamos, habrá ser un poco clic enlace que dice aquí para responder a la encuesta. Y cuando una persona hace clic ese vínculo, lo que pasa es que tire abajo de un seguro HTML formulario de encuesta de S3. No hay servidor. Esto es sólo un objeto S3. 

Esa forma aparece, carga en el navegador. Tiene Backbone. Tiene complejo JavaScript que se está ejecutando. Así que es de aplicación muy rica se ejecuta en el navegador del cliente. Ellos no saben que no lo son interactuar con un servidor back-end. En este punto, es todo navegador. 

Publican los resultados a lo llamamos a la API de Amazon Gateway. API Gateway es simplemente una API Web que se puede definir y conectar a lo que quieras. En este caso particular, estamos conectado a una función lambda. 

Así que mi operación POST es pasando con ningún servidor. Básicamente esa puerta de enlace API se sienta allí. Me cuesta nada hasta que la gente comienza a publicar a ella, ¿no? La función de Lambda sólo se sienta allí. Y me cuesta nada hasta la gente comienza a golpearlo. Así se puede ver, ya que el volumen aumenta, ahí es cuando las acusaciones vienen. No estoy corriendo un servidor 24.7. 

Así que me tire de la forma descender del cubo, y he puesto a través de la API Puerta de entrada a la función de Lambda. Y entonces el Lambda función dice, ya sabes lo que, tengo algunos PII, algunos información de identificación personal en estas respuestas. Conseguí comentarios procedentes de los usuarios. Tengo direcciones de correo electrónico. Tengo los nombres de usuario. 

Déjame dividir esto. Voy a generar algo de metadatos fuera de este registro. Y voy a empujar el metadatos en DynamoDB. Y podría cifrar todos los datos e introdúzcalo en DynamoDB si quiero. Pero es más fácil para mí, en este utilice caso, para que adelante un ejemplo, Voy a empujar los datos en bruto en un cubo de S3 cifrado. Así que utilizar construido en la lado del servidor S3 encriptación y administración de claves de Amazon Servicio de manera que tengo una llave que puede girar en un intervalo regular, y puedo proteger los datos PII como parte de todo este flujo de trabajo. 

Entonces, ¿qué he hecho? Acabo desplegado en su conjunto aplicación, y no tengo ningún servidor. Así que es lo que de sucesos de aplicación impulsada arquitectura hace por usted. 

Ahora bien, si se piensa en el caso de uso de esto-- tenemos otros clientes que estoy hablando a alrededor de esta arquitectura exacta que ejecutar fenomenalmente grandes campañas, que están mirando esto y va, oh mi. Porque ahora, que pueden básicamente empujarlo hacia fuera allí, dejar que la campaña simplemente sentarse allí hasta que lanza, y no tienes que preocuparte un bledo qué tipo de infraestructura va a estar ahí para apoyarlo. Y entonces tan pronto como que la campaña se lleva a cabo, es como la infraestructura acaba inmediatamente desaparece porque realmente hay infraestructura. Es código solo que se sienta en Lambda. Es sólo que los datos se encuentra en DynamoDB. Es una manera increíble para crear aplicaciones. 

AUDIENCIA: Entonces, ¿es más efímero de lo que sería si se almacena en un servidor real? 

RICK HOULIHAN: Por supuesto. Porque esa instancia de servidor tendría que ser un 7/24. Tiene que estar disponible para alguien para responder a. Bueno ¿adivinen qué? S3 está disponible 7/24. S3 siempre responde. Y S3 es muy, muy bueno a servir a los objetos. Estos objetos pueden ser archivos HTML, o Archivos JavaScript, o lo que quieras. Puede ejecutar aplicaciones web muy ricos de cubos S3, y la gente hace. 

Y así, esa es la idea aquí es alejarse de la forma solíamos pensar en ello. A todos nos acostumbramos a pensar en términos de servidores y anfitriones. No se trata de eso. Se trata de la infraestructura como código. Implementar el código para la nube y deje que la nube dirigido por usted. Y eso es lo AWS está tratando de hacer. 

AUDIENCIA: Así que su caja de oro en el medio de la puerta de enlace API no es como en el servidor, pero en cambio es sólo-- 

RICK HOULIHAN: Usted puede pensar ello como fachada servidor. Todo lo que es es que va a tomar un HTTP solicitar y asignar a otro proceso. Eso es todo lo que hace. Y en este caso, estamos cartografía a una función Lambda. Muy bien, así que eso es todo lo que tengo. Muchas gracias. Lo aprecio. Sé que queremos un poco más de tiempo. Y espero que ustedes ya ha recibido un poco de información que se puede llevar en la actualidad. Y pido disculpas si me fui sobre algunos de sus jefes, pero hay una buena cantidad de conocimientos básicos fundamentales que creo que es muy valioso para usted. Así que gracias por invitarme. [APLAUSOS] AUDIENCIA: [inaudible] es cuando usted decía que tenía que ir a través de la cosa desde el principio hasta el fin para obtener los valores correctos o los mismos valores, ¿cómo los valores cambiar si [inaudible]. 

RICK HOULIHAN: Oh, idempotente? ¿Cómo cambiarían los valores? Bueno, porque si yo no corro todo el camino hasta el final, entonces yo no sé lo que cambia se hicieron en la última milla. No va a ser el mismos datos que lo que vi. AUDIENCIA: Oh, por lo que sólo no han conseguido la entrada completa. RICK HOULIHAN: Correcto. Tienes que ir desde el principio a fin, y entonces es va a ser un estado coherente. Guay. 

AUDIENCIA: ¿Así que nos mostraste DynamoDB puede hacer de documentos o el valor de la clave. Y nos pasamos un montón de tiempo en el valor de la clave con un hash y las formas para darle la vuelta alrededor. Cuando se miraba en esas mesas, es que dejando atrás el enfoque documento? 

RICK HOULIHAN: Yo no lo haría decir dejándolo atrás. 

AUDIENCIA: Ellos fueron separados de el-- 

RICK HOULIHAN: Con el documento enfoque, el tipo de documento en DynamoDB es sólo pensar en como otro atributo. Es un atributo que contiene una estructura de datos jerárquica. Y luego, en las consultas, puede utilizar las propiedades de esos objetos utilizando notación de objetos. Así que puede filtrar en una anidada propiedad del documento JSON. AUDIENCIA: Así que cada vez que hacer un enfoque documento, Puedo especie de llegar a la tabular-- AUDIENCIA: Absolutamente. Audiencia: --indexes y cosas que acabamos de hablar. RICK HOULIHAN: Sí, la índices y todo eso, cuando se quiere indexar el propiedades de la JSON, la forma en que nos gustaría tener que hacer eso es si inserta un objeto JSON o un documento en Dynamo, utilizaría los arroyos. Streams leerían la entrada. Usted conseguiría que JSON objeto y que ibas a decir OK, ¿cuál es la propiedad que quiero índice? 

Se crea una tabla derivada. Ahora esa es la forma en que funciona ahora. Nosotros no permitimos al índice directamente esas propiedades. 

AUDIENCIA: Tabularizing sus documentos. 

RICK HOULIHAN: Exactamente, aplanando que, tabularizing, exactamente. Eso es lo que haces con él. 

AUDIENCIA: Gracias. 

RICK HOULIHAN: Sí, absolutamente, gracias. AUDIENCIA: Así que es una especie de Mongo cumple classifers Redis. 

RICK HOULIHAN: Sí, que es muy parecido a eso. Esa es una buena descripción de la misma. Guay.