[Música tocando] Rick Houlihan: Todo ben. Ola, persoal. O meu nome é Rick Houlihan. Eu son un director Senior arquitecto de solucións da AWS. Concentrar-me en NoSQL e Tecnoloxías DynamoDB. Estou aquí hoxe para falar con vostede un pouco sobre aqueles. 

Miña formación é principalmente na capa de datos. Pasei a metade da miña desenvolvemento escrita da carreira de base de datos, acceso a datos, solucións para varias aplicacións. Eu estiven en virtualización na nube por preto de 20 anos. Entón, antes de que a nube se a nube, acostumabamos chamalo utility computing. E a idea foi, é como PG & E, paga polo que usa. Hoxe o chamamos nube. 

Pero co paso dos anos, eu traballei para un par de empresas probablemente nunca escoitou falar. Pero eu compilar unha lista de técnico realizacións, eu creo que diría. Teño oito patentes en sistemas en nube virtualización, deseño de microprocesadores, procesamento de eventos complexos, e outras áreas. 

Entón, estes días, vou concentrar principalmente sobre NoSQL tecnoloxías e da seguinte xeración base de datos. E iso é xeralmente o que eu vou estar aquí falando contigo hoxe sobre. Entón, o que pode esperar dende esta sesión, nós imos pasar por un breve historia de procesamento de datos. É sempre útil comprender de onde vimos e por iso que estamos onde estamos. E imos falar un pouco pouco sobre tecnoloxía NoSQL desde un punto de vista fundamental. 

Nós imos entrar en algunhas das os internos DynamoDB. DynamoDB é da AWS non sabor. É un totalmente xestionado e solución NoSQL aloxado. E nós imos falar un pouco sobre a táboa estrutura, APIs, tipos de datos, índices, e algunhas das partes internas de que a tecnoloxía DynamoDB. Nós imos entrar en algún do deseño estándares e mellores prácticas. Nós imos falar sobre como usar a tecnoloxía para algúns as aplicacións de hoxe. E entón nós imos falar un pouco sobre a evolución ou a emerxencia dun novo paradigma na programación chamados aplicacións orientados a eventos e como DynamoDB desempeña no que, como ben. E nós imos deixar que un pouco de unha arquitectura de referencia discusión así que podemos falar sobre algunhas das as formas que pode usar DynamoDB. 

Entón, primeiro off-- esta é unha cuestión Escoito moito é, o que é unha base de datos. Moita xente pensa que eles sabe o que é unha base de datos. Se Google, vai ver iso. É unha dun conxunto estruturado de datos realizada nun ordenador, especialmente un que é accesible de varias maneiras. Creo que é unha boa definición de unha base de datos moderno. Pero eu non me gusta, porque implica un par de cousas. Implica estrutura. E iso implica que é nun ordenador. E bases de datos non sempre existir en computadores. Bases de datos, en realidade existía en moitas maneiras. 

Así, unha mellor definición dun base de datos é algo así. Unha base de datos é unha organizada mecanismo para almacenamento, xestión, e recuperación de información. Isto é de About.com. Entón, me gusta diso porque realmente fala sobre unha base de datos de ser un repositorio, un repositorio de información, non necesariamente algo que se sente nun ordenador. E ao longo da historia, nós non sempre tiveron ordenadores. 

Agora, se eu preguntar a media creador de hoxe o que é unha base de datos, esa é a resposta que recibín. Nalgún lugar que eu poida manter o material. Non? E é verdade. Pero é lamentable. Porque a base de datos é realmente a fundación do app moderno. É a fundación de cada aplicación. E como construír ese base de datos, como estrutura que datos vai dictar como que aplicación execútase como escala. 

Así, gran parte do meu traballo hoxe é xestionar o que acontece cando os desenvolvedores adoptar esa visión e ante as consecuencias dunha aplicación que agora está ampliando ademais do orixinal intención e sufrimento de mal deseño. Polo tanto, esperamos que cando ir hoxe, vai ten un par de ferramentas en seu cinto que vai mantelo de facer os mesmos erros. Todo ben. Entón imos falar sobre un pouco de a liña do tempo da tecnoloxía de base de datos. Creo que lin un artigo non moito tempo atrás e el dixo algo sobre o lines-- é unha afirmación moi poético. El dixo que a historia de procesamento de datos é cheo de altos marcas de auga abundancia de datos. Aceptar. Agora, eu creo que é o tipo de verdade. Pero realmente ollar é como a historia é realmente cheo con marca de auga de alta presión de datos. Unha vez que a taxa de datos Inxestión Nunca vai para abaixo. El só vai para arriba. 

E a innovación ocorre cando vemos presión de datos, que representa a cantidade de datos que é Agora, no que entra no sistema. E non pode ser procesado eficientemente, tanto no tempo ou no custo. E foi alí onde comezamos a ollar para a presión de datos. 

Así, cando miramos para o primeira base de datos, esta é a única que estaba entre os nosos oídos. Todos nacemos con el. É unha base de datos ben. El ten unha alta dispoñibilidade. É sempre conectado. Sempre pode obtelo. 

Pero é único usuario. Non podo compartir meus pensamentos con vostede. Non pode obter os meus pensamentos cando quere que eles. E a súa abilitiy non é tan bo. Esquecemos nos de cousas. De cando en vez, un de nós follas e móvese a outra existencia e perdemos todo que estaba no banco de datos. Entón iso non é todo o que é bo. 

E iso funcionou ben no tempo cando estabamos de volta ao día cando todo o que realmente precisaba saber é onde estamos indo a ir mañá ou onde nos reunimos a mellor comida. Pero cando comezamos a crecer como civilización e goberno comezou para chegar a ser, e as empresas comezaron a evolucionar, nós comezamos a entender que necesitamos un pouco máis que o poderiamos poñer na nosa cabeza. Todo ben? 

Necesitabamos de sistemas de rexistro. Necesitabamos lugares para ser almacenar datos capaces. Entón comezamos a escribir documentos, a creación de bibliotecas e arquivos. Comezamos a desenvolver un sistema de contabilidade Ledger. E que o sistema de conta de contabilidade correu o mundo por moitos séculos, e quizais mesmo milenios, como nós medio que creceu a tal punto onde esa carga de datos superou a capacidade destes sistemas para poder conter. 

E iso realmente aconteceu na década de 1880. Non? No Censo de 1880 de Estados Unidos. Isto é realmente onde a viraxe apuntar procesamento de datos moderno. Este é o punto en que a cantidade de datos que estaba sendo recollidas por Goberno dos Estados Unidos chegou a un punto onde levou oito anos para ser procesada. 

Agora, oito anos-- como vostede sabe, o censo sae cada 10 anos-- polo que é bastante obvio que polo tempo que obtivo o censo de 1890, a cantidade de datos que ía ser procesado polo goberno foi vai exceder os 10 anos que sería necesario para lanzar o novo censo. Este foi un problema. 

Entón, un cara chamado Herman Hollerith veu xunto e inventou rexistro zócolo unidade tarxetas, lector de tarxetas perfurados, tarxetas perfurados tabulator, eo agrupación de os mecanismos para esta tecnoloxía. E que a empresa que el formou no tempo, xunto cun par de outros, de feito, chegou a ser un dos piares dunha pequena empresa que coñecemos hoxe chamada IBM. 

Entón IBM orixinalmente estaba base de datos da empresa. E iso é realmente o que eles fixeron. Fixeron procesamento de datos. 

Como así a proliferación de perforado tarxetas, un enxeñoso mecanismos de poder aproveitar ese tecnoloxía para votación conxuntos de resultados clasificados. Podes ver nesta foto aí temos un little-- é un pouco small-- pero verás un mecanismo mecánico moi enxeñoso onde temos unha plataforma de cartóns perforados. E toma de alguén un pouco de chave de fenda e furando a través do slots e levantando- para este partido, que resultados clasificados definido. 

Esta é unha agregación. Facemos todo o tempo hoxe no ordenador, onde facelo na base de datos. Nós acostumabamos facelo manualmente, non? Persoas poñer isto en conxunto. E foi a proliferación destes tarxetas perfurados para o que chamamos tambores de datos e bobinas de datos, cinta de papel. 

A industria de procesamento de datos levou unha lección cos pianos de xogador. Xogador pianos de volta ao Na virada do século adoitaba usar bobinas de papel con slots para dicirlle que as claves para xogar. Así que a tecnoloxía foi adaptada finalmente, para almacenar datos dixitais, porque eles poderían poñer eses datos para os rolos de cinta de papel. 

Agora, como un resultado, os datos foi actually-- como vostede acceder a estes datos foi directamente dependente da forma como está almacenado. Entón, se eu poñer os datos nunha cinta, Tiven acceder aos datos de xeito lineal. Tiven que rolar a todo cinta para acceder todos os datos. Se eu poñer os datos no zócalo tarxetas, eu podería acceder a ela en algo máis aleatoria forma, quizais non tan rapidamente. 

Pero había limitacións en como nós acceso a datos en base a como foi almacenado. E por iso foi un problema vai para os anos 50. Unha vez máis, podemos comezar a ver que, coma nós desenvolver novas tecnoloxías para procesar os datos, non, ela abre a porta a novas solucións, para novos programas, novo aplicacións para estes datos. E realmente, gobernanza pode ser a razón por iso que realizamos algúns destes sistemas. Pero o negocio tornouse rapidamente o condutor detrás da evolución da base de datos moderno e o sistema de ficheiros moderno. 

Polo tanto, a seguinte cousa que xurdiu foi nos anos 50 foi o sistema de ficheiros e desenvolvemento de almacenamento de acceso aleatorio. Esta foi a fermosa. Agora, de súpeto, podemos poñer o noso arquivos en calquera lugar neses discos duros e podemos acceder a estes datos de forma aleatoria. Podemos analizar que información de arquivos. E nós decidimos todo o mundo problemas con procesamento de datos. 

E que durou preto de 20 ou 30 anos ata a evolución da base de datos relacional, que é cando o mundo decidiu que agora Debe ter un repositorio que derrota a expansión dos datos a través do arquivo sistemas que construímos. Non? Moitos datos distribuídos en moitos lugares, a de-duplicación de datos, eo custo de almacenamento era enorme. 

Os anos 70, o recurso máis caro que un ordenador tiña era o de almacenamento. O procesador foi visto como un custo fixo. Cando mercar a caixa, a CPU fai un traballo. Será xiro se é realmente funciona ou non. Isto é realmente un custo afundido. 

Pero o que me custou como un negocio é o almacenamento. Se eu teño que mercar máis discos próximo mes, iso é un custo real que pagar. E que o almacenamento é caro. 

Agora nós avance rápido 40 anos e temos un problema diferente. A computación é agora o recurso máis caro. O almacenamento é barato. Quero dicir, podemos ir a calquera lugar no nube e podemos atopar almacenamento barato. Pero o que eu non podo atopar é computación barato. 

Así, a evolución de hoxe tecnoloxía, da tecnoloxía de base de datos, Está realmente focado en torno a bases de datos distribuídas que non sofren o mesmo tipo de escala limitacións dos bancos de datos relacionais. Imos falar un pouco sobre o que iso realmente significa. 

Pero unha das razóns e o condutor detrás de nós isto-- falou sobre a presión de datos. Presión de datos é algo que impulsa a innovación. E se ollar para arriba Nos últimos cinco anos, este é un gráfico de que os datos carga toda a empresa xeral Parece que, nos últimos cinco anos. 

E a regra xeral do polgar estes dias-- se vai Google-- é do 90% do que os datos nós gardados hoxe, e foi xerado dentro dos últimos dous anos. Aceptar. Agora, iso non é unha tendencia que hai de novo. Esta é unha tendencia que foi saíndo por 100 anos. Desde Herman Hollerith desenvolveu a tarxeta de perforado, temos está a construír repositorios de datos e recolección de datos en taxas fenómenos. 

Así, ao longo dos últimos 100 anos, vimos esa tendencia. Iso non vai cambiar. Aquí para diante, imos ver este, se non unha tendencia acelerada. E podes ver o que parece. 

Se unha empresa, en 2010, tivo un terabyte de datos baixo xestión, hoxe que significa que son xestión de 6,5 petabytes de datos. Isto é 6.500 veces máis datos. E sei que iso. Eu traballo con estas empresas todos os días. Cinco anos, eu falaría con empresas quen ía falar comigo sobre o que é unha dor é para xestionar terabytes de datos. E falarían para min sobre como podemos ver que se trata probablemente ser un ou dous petabyte dentro dun par de anos. 

Estas mesmas empresas hoxe vou atopar con, e eles están falando comigo sobre o problema está aí ter xestión decenas, 20 petabytes de datos. Así, a explosión da datos na industria Está dirixido a enorme precisa mellores solucións. E a base de datos relacional é só non vivir de acordo coa demanda. 

E por iso hai unha lineal correlación entre a presión de datos e innovación técnica. A historia ten nos mostra este, que co paso do tempo, sempre que o volume de datos que ten que ser procesado supera a capacidade do sistema para proceso-lo nun tempo razoable ou a un custo razoable, a continuación, as novas tecnoloxías son inventadas para resolver estes problemas. Estas novas tecnoloxías, á súa vez, abre a porta a outro conxunto de problemas, o que está reunindo aínda máis datos. 

Agora, non imos parar con iso. Non? Non imos parar con iso. Por que? Porque non pode saber todo que hai para saber o universo. E mentres nós estivemos vivos, ao longo da historia do home, temos sempre conducido para saber máis. 

Entón, parece que cada polgada nos movemos no camiño do descubrimento científica, estamos a multiplicación da cantidade de datos que necesitamos para procesar exponencialmente como descubrimos máis e máis e máis sobre o funcionamento interno da vida, sobre como o universo funciona, sobre dirixir o descubrimento científica, e que a invención nós estamos facendo hoxe. O volume de datos só aumenta continuamente. Así, ser capaz de xestionar este problema é enorme. 

Entón, unha das cousas Mira por NoSQL? Como é que NoSQL solucionar este problema? Ben, bases de datos relacionais, Structured Query Language, SQL-- que é realmente unha construción do relacional database-- esas cousas son optimizada para o almacenamento. 

Volver na década de 70, unha vez máis, disco é caro. O exercicio de provisionais de almacenamento na empresa é interminable. Eu sei. Eu vivín isto. Escribín controladores de almacenamento para un empresa superserver enterprised de volta os anos 90. E a liña de fondo é outra trasfega matriz de almacenamento foi só algo que Pasou cada día na empresa. E non parou máis. Maior densidade de almacenamento, a demanda para almacenamento de alta densidade, e para un almacenamento máis eficiente devices-- nunca parou. 

E NoSQL é unha gran tecnoloxía xa que normaliza os datos. É de-duplica os datos. Isto pon os datos nunha estrutura que é agnóstica para cada nivel de acceso. Varias aplicacións poden bater ese Base de datos SQL, realizar consultas ad hoc, e obter datos en forma que Debe proceso para a súa carga de traballo. Isto soa fantástico. Pero a liña de fondo é con calquera sistema, se é agnóstico a todo, é óptimo para nada. OK? 

E iso é o que nós comezamos con a base de datos relacional. É óptimo para almacenamento. É normalizada. É relacional. Soporta as consultas ad hoc. E el e el escalas verticalmente. 

Se eu teño para obter unha base de datos SQL maior ou unha base de datos SQL máis poderoso, Vou mercar unha peza grande de ferro. OK? Eu traballei con unha morea de clientes que xa pasou por grandes actualizacións na súa infraestrutura SQL única para descubrir seis meses despois, están acertando a parede de novo. E a resposta de Oracle ou MSSQL ou calquera outra persoa é obter unha caixa máis grande. Ben, máis cedo ou máis tarde, non pode mercar un maior caixa, e iso é problema real. Necesitamos realmente cambiar as cousas. Entón, onde é que isto funciona? Funciona ben para offline Analytics, do tipo OLAP carga de traballo. E iso é realmente onde a SQL pertence. Agora, é usado hoxe en moitos en liña transacional-tipo de procesamento aplicacións. E funciona moi ben no algún nivel de uso, pero simplemente non escala a forma que NoSQL fai. E imos falar un pouco pouco sobre por que isto ocorre. 

Agora, NoSQL, por outra banda, é máis óptimo para computación. OK? Non é agnóstico o estándar de acceso. É o que chamamos-normalizado estrutura ou unha estrutura xerárquica. Os datos nunha base de datos relacional é Xuntáronse a partir de varias táboas para producir a visión de que precisa. Os datos na base de datos NoSQL un é almacenado nun documento que contén a estrutura xerárquica. Todos os datos que normalmente se recomenda que uníronse para producir ese punto de vista é almacenado nun único documento. E imos falar un pouco sobre como funciona en un par de cartas. 

Pero a idea aquí é que almacenar seus datos como estes puntos de vista instanciado. OK? Vostede escala horizontal. Non? Se eu ter que aumentar o tamaño do meu agrupación NoSQL, Eu non teño de obter unha caixa máis grande. Recibe outra caixa. E eu agrupar estes xuntos, e podo caco que os datos. Imos falar un pouco sobre sharding que é, para ser capaz de escalar ese banco de datos en distintos dispositivos físicos e eliminar a barreira que obrígame a escalar verticalmente. 

Entón, é realmente construído para en liña procesamento de transaccións e escala. Hai unha gran distinción aquí entre os informes, non? Informes, eu non sei o preguntas que eu vou pedir. Non? Reporting-- se alguén do meu departamento de marketing quere só-- como moitos dos meus clientes teñen esta característica en particular que Compras nesta dia-- Non sei que consultar van preguntar. Entón eu teño ser agnóstico. 

Agora, nunha liña aplicación transacional, Sei que preguntas que eu estou pedindo. Eu constrúe a solicitude de un fluxo de traballo moi específico. OK? Entón, se eu optimizar a datos almacenar a apoiar ese fluxo de traballo, que vai ser máis rápido. E é por iso que pode NoSQL realmente acelerar a entrega un destes tipos de servizos. Todo ben. 

Entón, nós estamos indo a entrar un pouco de teoría aquí. E algúns de vostedes, os seus ollos pode desfacer un pouco. Pero eu vou tentar mantelo tan alto nivel que eu poida. Entón, se está no proxecto xestión, hai unha construción chamada triángulo de restricións. Aceptar. O triángulo de constrangimentos ditados non pode ter todo o tempo. Non pode ter o seu bolo e come-lo. Así, en xestión de proxectos, que triángulo limitacións é que pode telo barato, podes telo rápido, ou pode telo ben. Escolla dous. Porque non pode ter todos os tres. Non? Aceptar. 

Entón se escoita moito sobre iso. É unha restrición tripla, triángulo de restrición tripla, ou o triángulo de ferro é oftentimes-- cando fala aos xerentes de proxecto, eles van falar sobre iso. Agora, bases de datos teñen seu propio triángulo de ferro. E o triángulo de ferro de datos é o que chamamos teorema de CAP. OK? 

PAC dictames teorema como bases de datos operar baixo unha condición moi específica. E nós imos falar sobre o que é esa condición. Pero os tres vértices do triángulo, por así dicir, son A, consistencia. OK? Así, no PAC, a consistencia significa que todos clientes que poden acceder á base de datos terá sempre un moi visión consistente dos datos. Ninguén vai ver dúas cousas diferentes. OK? Se eu ver a base de datos, Estou vendo a mesma visión como o meu compañeiro que ve a mesma base de datos. Esa é a consistencia. 

Dispoñibilidade significa que, se o base de datos en liña, se poida ser alcanzado, que todos os clientes serán sempre ser capaz de ler e escribir. OK? Así, cada cliente que pode ler a base de datos será sempre capaz de lectura datos de datos e escribir. E se ese é o caso, É un sistema dispoñible. 

E o terceiro punto é o que que chamamos tolerancia partición. OK? Medios de tolerancia partición que o sistema funciona ben a pesar de rede física divisorias entre os nós. OK? Entón nós do cluster non pode falar entre si, o que pasa? Todo ben. 

Bases de datos relacionais Entón choose-- pode escoller dous destes. Aceptar. Bases de datos relacionais Entón escolla para ser consistente e dispoñible. Se a partición acontece entre os DataNodes no almacenamento de datos, a base de datos falla. Non? El só vai para abaixo. Aceptar. 

E é por iso que eles teñen crecendo coas caixas maiores. Non? Porque non hai Não-- xeralmente, un cluster base de datos, non hai moito moitos deles que operan desa forma. Pero a maioría dos bancos de datos de escala vertical dentro dunha única caixa. Porque precisan ser consistente e está dispoñible. Se unha partición foron sendo inxectado, entón tería que facer unha selección. Ten que facer unha selección entre sendo consistente e dispoñible. 

E iso é o que bancos de datos NoSQL facer. Todo ben. Así, unha base de datos NoSQL, el vén en dous sabores. Nós have-- ben, vén en moitos sabores, pero ven con dous básico characteristics-- o que nós chamariamos de base de datos CP, ou un tolerancia e consistente partición sistema. Eses faces a facer a elección que, cando os nós perder o contacto entre si, nós non imos permitir a xente a escribir máis. OK? 

Ata que esta partición é eliminada, acceso de gravación é bloqueada. Isto significa que eles non están dispoñibles. Son consistentes. HTML partición inxectar-se, estamos agora consistente, porque non imos para permitir o cambio de datos en dous lados da partición independentemente un do outro. Teremos que restablecer a comunicación antes de calquera actualización os datos están permitidos. OK? 

O seguinte sabor sería un sistema AP, ou un dispoñible e repartiu sistema de tolerancia. Eses faces non lles importa. Non? Calquera nodo que recibe unha escribir, nós imos toma-lo. Entón, eu estou replicar meus datos en varios nós. Estes nós obter un cliente, o cliente vén en, di, eu vou escribir algúns datos. Nó di, non hai problema. O nó ó lado queda unha gravación no mesmo rexistro, vai dicir non problema. Nalgún lugar de volta no back-end, que os datos vai replicar. E entón alguén vai entender, uh-oh, eles van entender sistema, uh-oh, houbo unha actualización para os dous lados. O que imos facer? E o que fan é, entón, fan algo que lles permite resolver este estado de datos. E nós imos falar sobre que, no cadro seguinte. 

Cousa que salientar aquí. E eu non vou ir moi moi a este, porque esta entra en teoría datos de profundidade. Pero hai un transacional cadro que é executado en un sistema relacional que permite que faga con seguridade actualizacións para varias entidades na base de datos. E esas actualizacións deben ocorrer todo dunha vez ou de xeito ningún. E iso é chamado de transaccións ACID. OK? 

ACID dános atomicidade, consistencia, illamento, e durabilidade. OK? Isto significa que, transaccións atómicas, todo miñas actualizacións tanto ocorrer ou non fan. Consistencia significa que a base de datos será sempre ser levado a un consistente estado tras unha actualización. Eu nunca vou deixar a base de datos en un mal estado despois de aplicar unha actualización. OK? 

Polo tanto, é un pouco diferente de consistencia PAC. Consistencia PAC significa toda a miña os clientes poden sempre ver os datos. Consistencia ÁCIDO significa que cando unha transacción está feito, datos de boa. Meus relacións son todo de bo. Eu non estou indo para eliminar unha liña pai e deixar unha morea de nenos orfas nalgunha outra táboa. Isto non pode ocorrer se eu está consistente nunha transacción de ácido. 

Illamento significa que as transaccións sempre producen despois da outra. O resultado final dos datos será o mesmo estado como se estas operacións que foron emitidos simultaneamente foron executados en serie. Polo tanto, é a simultaneidade control da base de datos. Entón, basicamente, eu non podo incrementar o mesmo valor dobre con dúas operacións. 

Pero se eu digo engadir 1 a este valor, e dúas operacións veñen e tentar facelo, é unha vai chegar alí primeiro e do outro un vai chegar alí despois. Entón, ao final, eu engade dous. Ve o que quero dicir? Aceptar. 

A durabilidade é moi sinxelo. Cando a transacción é recoñecido, é vai estar alí mesmo se o sistema falla. Cando este sistema recupera, isto transacción que foi cometida está realmente indo para estar alí. Entón, iso é as garantías de transaccións ACID. Estas son garantías moi agradables para ter nunha base de datos, pero eles veñen para ese custo. Non? 

Porque o problema con este cadro é Se hai unha partición en datos set, eu teño que tomar unha decisión. Vou ter para que actualizacións dun lado ou do outro. E se isto acontecer, entón eu xa non estou indo para ser capaz de manter esas características. Eles non van ser consistente. Eles non van ser illado. Este é o lugar onde se descompón para bases de datos relacionais. Esta é a razón relacional bases de datos de escala vertical. 

Por outra banda, temos o que se chama tecnoloxía BASE. E estes son os seus bancos de datos NoSQL. Todo ben. Polo tanto, temos a nosa CP, bases de datos de AP. E estes son, basicamente, o que chama dispoñible, estado brando, finalmente, consistente. OK? 

Basicamente dispoñible, porque son partición tolerante. Eles serán sempre alí, mesmo se non hai unha divisoria entre os nós da rede. Se podo falar con un nó, eu son vai ser capaz de ler datos. OK? Podo non ser sempre capaz de escribir datos se eu son unha plataforma consistente. Pero eu vou ser capaz de ler os datos. 

O estado indica brando que cando eu ler estes datos, pode non ser o mesmo que os outros nós. Un dereito foi emitido nun nodo noutro lugar no cluster e non foi replicado en toda a aglomerado aínda cando lin que os datos, que o estado pode non ser consistente. Con todo, será finalmente, consistente, o que significa que cando unha gravación está feito para o sistema, vai replicar en todos os nós. E, finalmente, ese estado será posto en orde, e será un estado consistente. 

Agora, o teorema PAC realmente xoga só nunha condición. Esta condición é cando isto ocorre. Porque sempre que está operando en modo normal, non hai ningunha partición, todo é consistente e dispoñible. Só preocuparse CAP cando temos esa partición. Polo tanto, estas son raras. Pero como o sistema reacciona cando os ocorren dictar que tipo de sistema estamos lidando. 

Entón, imos dar un ollo ao que parecer para os sistemas AP. OK? Sistemas AP veñen dous sabores. Veñen en sabor que é un mestre mestre, 100%, sempre dispoñible. E veñen en outro sabor, que di: vostede sabe o que, eu vou preocuparme sobre esa cousa de particionamento cando ocorre unha partición real. Se non, non vai ser primaria nós que vai levar os dereitos. OK? 

Entón, se nós algo Cassandra. Cassandra sería un mestre mestre, imos escribir-me en calquera nodo. Entón o que ocorre? Entón, eu teño un obxecto no base de datos que existe en dous nós. Imos chamar ese obxecto S. Polo tanto, temos estado a S. Temos algunhas operacións S en que están en curso. Cassandra permíteme escribir para varios nós. Entón, digamos que eu recibín unha escribir para sa dous nós. Ben, o que acaba pasando é chamamos iso de un evento de particionamento. Non pode ser un partición de rede física. Pero por mor do proxecto do sistema, que é particionamento realmente logo que eu conseguir unha gravación en dous nós. Non me forzando a escribir todo a través dun nodo. Estou escribindo sobre dous nós. OK? 

Entón agora eu teño dous estados. OK? O que vai ocorrer é, máis cedo ou máis tarde, alí vai ser un evento de replicación. Non vai ser o que nós chamado de recuperación de partición, que é onde estes dous estados volver xuntos e alí vai ser un algoritmo que corre dentro da base de datos, decide o que facer. OK? Por defecto, última actualización vence na maioría dos sistemas de AP. Polo tanto, hai xeralmente unha algoritmo estándar, o que eles chaman dun callback función, algo que chamarase cando esta condición sexa detectado para realizar algunha lóxica para resolver este conflito. OK? O retorno de chamada predeterminado e estándar resolver a maioría dos bancos de datos AP é, difícil de adiviñar, timestamp gaña. Esta foi a última actualización. Vou poñer esta actualización alí. Podo botan este rexistro que eu despexado fóra nun rexistro de recuperación de xeito que o usuario pode volver máis tarde e dicir, hey, houbo unha colisión. Que pasou? E realmente pode botan un rexistro de todas as colisións e as reversões e ver que pasa. 

Agora, como un usuario, tamén se pode incluír lóxica en que callback. Así, pode cambiar isto operación de retorno de chamada. Pode dicir, hey, quero para remediar estes datos. E quero probar e mesturar estes dous rexistros. Pero iso é ata. A base de datos non sabe como facelo por defecto. A maior parte do tempo, o único que a base de datos sabe facer é dicir, este foi o último rexistro. Iso é o que vai gañar, e ese é o valor que eu vou poñer. Xa que a recuperación partición e replicación ocorre, temos o noso estado, que agora é S principal, que é o estado de fusión de todos estes obxectos. Así, os sistemas AP ter iso. Sistemas CP non ten se preocupar con iso. Porque así como unha partición vén en xogo, eles simplemente deixar de tomar escribe. OK? Entón, iso é moi fácil xestionar ser consistente cando non aceptar as actualizacións. Iso é cos sistemas CP facer. Todo ben. 

Entón imos falar un pouco pouco sobre patróns de acceso. Cando falamos de NoSQL, é todo sobre o nivel de acceso. Agora, o SQL é ad hoc, as consultas. É almacenamento relacional. Non temos que preocupar-se sobre o nivel de acceso. Eu escribir consulta moi complexa. Vai e colle os datos. Iso é o que iso parece como, normalización. 

Polo tanto, neste estrutura particular, nós estamos mirando para un catálogo de produtos. I teñen diferentes tipos de produtos. Teño libros. Teño álbums. Teño vídeos. A relación entre os produtos e calquera destes libros, discos, e vídeos táboas é 1: 1. Todo ben? Eu teño un ID do produto, e que se corresponde ID para un libro, un disco ou un vídeo. OK? Isto é unha relación 1: 1 a través destas táboas. 

Agora todos eles books-- ten é propiedades da raíz. Non hai problema. Isto é óptimo. One-to-one relación, eu recibín todo os datos que eu teño para describir ese libro. Albums Albums-- teñen pistas. Isto é o que chamamos un para moitos. Cada álbum pode ter moitas pistas. Así, para cada tema o álbum, eu podería ter outro récord nesta táboa fillo. Entón eu crear un rexistro na miña táboa de álbums. Eu crear varios rexistros na táboa de pistas. One-to-many relationship. 

Esta relación é o que que chamamos moitos-a-moitos. OK? Ve que os actores poderían ser en moitos filmes, moitos vídeos. Entón, o que facemos é poñer este mapa mesa entre aqueles, que só mapea o ID actor para o ID de vídeo. Agora podo crear unha consulta da xunta videos a través de vídeo actor para actores, e que me dá unha boa lista de todas as películas e todos os actores que eran naquel filme. 

Aceptar. Entón, imos alí. One-to-one é a de nivel superior relación; un a moitos, álbums de rutas; moitos-a-moitos. Estes son os tres de nivel superior relacións en calquera base de datos. Se sabe como aqueles relacións de traballo en conxunto, entón vostede sabe moi sobre base de datos xa. Entón NoSQL funciona un pouco diferente. Imos pensar por un segundo o que miradas lle gusta ir obter todos os meus produtos. 

Nunha tenda relacional, I quere obter todos os meus produtos nunha lista de todos os meus produtos. Iso é unha chea de consultas. Eu teño unha consulta para todos os meus libros. Eu teño unha consulta dos meus álbums. E eu teño unha consulta para todos os meus vídeos. E eu teño que poñelo todos xuntos nunha lista e servi-lo de volta ata o aplicación que está pedindo iso. 

Para obter os meus libros, eu juntar- Produtos e Libros. Para obter os meus albums, eu comece a xuntar-se Produtos, Álbums, e pistas. E para os meus vídeos, eu teño para xuntar-se os produtos a vídeos, xuntar-se a través Actor vídeos, e traer os actores. Entón, iso é tres consultas. Consultas moi complexas para montar un conxunto de resultados. 

Iso é menos que ideal. É por iso que cando falamos sobre unha estrutura de datos que é construído para ser agnóstico ao acceso pattern-- ben, iso é gran. E podes ver que é realmente agradable como organizamos os datos. E vostede sabe o que? Eu só teño unha marca para un actor. 

Iso é legal. Eu deduplicados todos os meus actores, e eu mantiven miñas asociacións nesta táboa de cartografía. Con todo, obter os datos fóra convértese en caro. Estou enviando a CPU en todo o sistema xuntando esas estruturas de datos en conxunto para poder tirar os datos de volta. 

Entón, como podo evitar isto? En NoSQL é sobre agregación, non normalización. Por iso, queremos dicir que queremos apoiar o estándar de acceso. O nivel de acceso para as aplicacións, Eu teño para obter todos os meus produtos. Imos poñer todos os produtos nunha táboa. Se eu poñer todos os produtos nunha táboa, Só podo seleccionar todos os produtos a partir desa mesa e eu entendín todo. Ben, como fago isto? Ben en NoSQL non hai ningunha estrutura para a mesa. Imos falar un pouco sobre como funciona na Dynamo DB. Pero non ten o mesmo atributos e as mesmas propiedades en cada liña única, en cada elemento, como fai nunha táboa SQL. E o que me permite para facer unha chea de cousas e me dar unha morea de flexibilidade. Neste caso particular, eu teño os meus documentos do produto. E nese particular exemplo todo é un documento na táboa Produtos. E o produto dun libro pode ter un ID de tipo que especifica un libro. E a aplicación cambiarían en que ID. 

Na capa de aplicación, vou para dicir oh, que tipo de rexistro é iso? Oh, é un rexistro libro. Rexistros do libro teñen esas propiedades. Déixeme crear un obxecto libro. Entón, eu estou indo a cubrir o libro obxecto con este elemento. Seguinte elemento vén e di, o que é este elemento? Ben, este elemento é un álbum. Oh, eu teño un diferente enteiro rutina de procesamento para que, porque é un álbum. Ve o que quero dicir? 

Así, a aplicación tier-- I basta escoller todos estes rexistros. Todos comezan a chegar. Poden ser de todos os tipos. E é a lóxica da aplicación que alterna entre tipo e decide como proceso-los. 

Unha vez máis, polo que estamos optimizando o esquema para o estándar de acceso. Estamos facendo isto por colapso desas táboas. Estamos basicamente tomando estas estruturas normalizados, e estamos construíndo estruturas xerárquicas. Dentro de cada un destes rexistros Eu estou indo a ver propiedades de matriz. 

Dentro deste documento para Álbums, Estou vendo matrices de pistas. Estas pistas agora become-- basicamente esta táboa fillo que existe aquí nesta estrutura. Así, pode facelo no DynamoDB. Podes facelo no MongoDB. Podes facelo en calquera base de datos NoSQL. Crear estes tipos de estruturas de datos xerárquicos que permiten que recuperar datos moi rapidamente, porque agora eu Non ten que se conformar. Cando inserir un ficheiro para as Faixas mesa, ou un ficheiro nunha tabela de álbums, Teño que estar de acordo con este esquema. Eu teño que ter o atributo ou a propiedade que é definida nesa táboa. Cada un deles, cando inserir esa liña. Isto non é o caso en NoSQL. 

Podo ter totalmente diferente propiedades en cada documento que introducir na colección. Entón mecanismo moi poderoso. E é realmente como optimizar o sistema. Porque agora que consulta, no canto de xuntar todas esas táboas e execución dunha media ducia de consultas para tirar a datos que eu teño, Estou executando unha consulta. E eu estou a iteración en todo o conxunto de resultados. dálle unha idea do poder de NoSQL. Eu estou indo a ir ao lado tipo de aquí e falar un pouco sobre iso. Isto é máis do tipo comercialización ou technology-- a comercialización de tecnoloxía tipo de discusión. Pero é importante entender porque, se miramos a arriba aquí nesta carta, o que nós estamos mirando para é o que chamamos curva campaña publicitaria tecnoloxía. E o que isto significa material novo entra en xogo. A xente pensa que é óptimo. Eu xa resolveu todos os meus problemas. 

Esta podería ser a extrema todo, ser todo de todo. E comezan a usalo. E din, esa cousa non funciona. Iso non é certo. O material antigo era mellor. E eles van voltar a facer as cousas do xeito que estaban. E despois, finalmente, van, vostede sabe o que? Este material non é tan malo. Oh, así é como funciona. E xa que descubrir como obras, comezan a ir mellor. 

E o curioso sobre iso é, que tipo de liñas ata que chamamos a Curva de Adopción de Tecnoloxía. Entón o que pasa é que temos algún tipo de gatillo tecnoloxía. No caso das bases de datos, é a presión de datos. Nós falamos sobre os puntos de auga altos datos de presión ao longo do tempo. Cando esta presión alcanza un certo datos punto, iso é un gatillo tecnoloxía. 

Está quedando moi caro. Leva moito tempo para procesar os datos. Necesitamos algo mellor. Obtén os innovadores aí correndo por aí, tentando descubrir cal é a solución. Cal é a nova idea? 

Cal é a mellor próxima forma de facelo? E eles veñen para arriba con algo. E a xente coa dor real, os individuos no bordo do sangramento, van ir todo sobre el, porque precisan dunha resposta. Agora, o que inevitablemente happens-- e isto está a suceder agora en NoSQL. Eu vexo iso o tempo. 

O que pasa é inevitablemente persoas comezan a usar a nova ferramenta do mesmo xeito que usou a ferramenta de idade. E descubrir que non funciona tan ben. Non lembro quen era falando antes hoxe. Pero é como, cando o britadeira foi inventado, a xente non balanza-lo sobre súa cabeza para romper o formigón. 

Pero iso é o que é pasando con NoSQL hoxe. Se camiña para a maioría das tendas, eles están tentando ser tendas NoSQL. O que están facendo é eles están usando NoSQL, e eles están carregando- cheo de esquema relacional. Porque é así que eles proxectan bases de datos. E eles están se pregunta, por que é non realizar moi ben? Rapaz, esa cousa fede. Tiven que manter toda a miña xunta-se em-- como é, non, non. Manter xunta? Por que está xuntando datos? Non unirse datos NoSQL. Vostede agregar-lo. 

Entón, se quere evitar isto, aprender como a ferramenta funciona antes de que realmente comezar a usalo. Non tente utilizar as novas ferramentas do mesmo xeito que usou as ferramentas antigas. Terá unha experiencia malo. E cada vez iso é o que se trata. Cando comezan a chegar ata aquí, é porque a xente descubriron como usar as ferramentas. 

Fixeron o mesmo cando bases de datos relacionais foron inventados, e eles estaban substituíndo os sistemas de ficheiros. Intentaron construír sistemas de ficheiros con bases de datos relacionais porque iso é o que a xente entendesen. Non funcionou. Así, a comprensión das prácticas da tecnoloxía está a traballar con é enorme. Moi importante. 

Entón, nós estamos indo a entrar en DynamoDB. DynamoDB é AWS de totalmente de xestión plataforma NoSQL. Que totalmente de xestión significa? Isto significa que non precisa realmente se preocupe de nada. 

Entra, di nós, eu teño unha mesa. El que de tanta capacidade. Prema o botón, e provisión nós toda infraestrutura detrás da escena. Agora que é enorme. 

Porque cando fala sobre o deseño dunha base de datos, Clusters de datos NoSQL na escala, petabytes de funcionamento, executando millóns de transaccións por segundo, estas cousas non son pequenos clusters. Estamos a falar de miles de casos. Xestión de miles de exemplares, incluso instancias virtuais, é unha verdadeira dor na bunda. É dicir, pensar en cada vez que un parche de sistema operativo sae ou unha nova versión da base de datos. Que significa iso operativo a vostede? Isto significa que ten 1200 servidores que precisan ser actualizados. Agora mesmo coa automatización, que pode levar moito tempo. Isto pode causar unha serie de dores de cabeza operativos, porque eu podería servizos abaixo. 

Cómo actualizar esas bases de datos, I pode facer implantacións verde azul onde implantar e actualizar a metade da miña nós, e despois actualizar a outra metade. Tome aqueles abaixo. Polo tanto, a xestión da infraestrutura escala é moi doloroso. E AWS asumir que a dor de fóra. E bases de datos NoSQL pode ser extraordinariamente Dolores por mor da maneira que escala. 

Dimensionar horizontal. Se quere obter un maior NoSQL base de datos, compra máis nós. Cada nodo que compra é outra cabeza operativo. Entón deixe alguén facelo por vostede. AWS pode facelo. 

Apoiamos os valores clave do documento. Agora non ir moi Doutra en gráfico. Hai unha morea de diferentes sabor de NoSQL. Son todo tipo de conseguir munged xuntos neste momento. Podes ollar para DynamoDB e dicir que si, nos dous somos un documento e un valor de clave almacenar este punto. E pode discutir as características dun sobre o outro. Para min, unha morea de presente é realmente seis dunha media ducia de outro. Cada unha destas tecnoloxías é un tecnoloxía de multa e unha solución ben. Eu non diría que é mellor ou MongoDB peor que Couch, a continuación, Cassandra, entón Dynamo, ou viceversa. Quero dicir, estes son só opcións. 

É rápido e é consistente en calquera escala. Polo tanto, este é un dos maiores bonos que comeza coa AWS. Con DynamoDB é a posibilidade para obter un baixo único díxito latencia milissegundo en calquera escala. Esa era unha meta de proxecto do sistema. E temos clientes que están a facer millóns de operacións por segundo. 

Agora eu vou pasar por algunhas das persoas usar casos en poucos minutos aquí. Control-- acceso integrado temos o que chamamos Xestión de Acceso identidade ou IAM. Ela permeia todos os sistemas, todos os servizos que a AWS ofrece. DynamoDB sen excepción. Pode controlar o acceso para as táboas DynamoDB. En todas as súas contas por AWS definición de funcións de acceso e permisos na infraestrutura de IAM. 

E é un compoñente fundamental e integral en o que chamamos eventos programación orientada. Agora, este é un novo paradigma. 

Audiencia: Como é a súa taxa de certa positivos contra falsos negativos no seu sistema de control de acceso? Rick Houlihan: Certos positivas contra falsos negativos? Audiencia: Devolver o que ten que estar retornando? A diferenza de cando en cando non retorna cando debe validar? 

Rick Houlihan: Eu non podería che dicir iso. Se hai calquera fallos calquera que sexa, que, Non son a persoa para preguntar esta cuestión particular. Pero iso é unha boa pregunta. Eu sería curioso para saber que, en realidade. 

E así, de novo, novo paradigma está dirixida evento programación. Esta é a idea de que se pode implantar aplicacións complexos que pode operar un moi, moi alta escala sen infraestrutura calquera. Sen fixo infraestrutura calquera. E nós imos falar un pouco sobre o que iso significa que nós obter no seguinte par de cartas. 

O primeiro que imos facer é falaremos sobre mesas. Tipos de datos API para Dynamo. E o primeiro que vai notar cando mira para iso, se está familiarizado con calquera base de datos, bases de datos teñen realmente dous tipos de APIs Eu diría que é. Ou dous conxuntos de API. Unha delas sería API administrativa. 

As cousas que coidan de as funcións de base de datos. Configurar o mecanismo de almacenamento, a creación e inclusión de táboas. creación de bases de datos catálogos e instancias. Estes coisas- en DynamoDB, vostede teñen listas moi curto, curto. 

Polo tanto, noutras bases de datos, podes ver decenas de comandos, de administrativa comandos, para a configuración estas opcións adicionais. En DynamoDB non precisa os porque non configurar o sistema, o que facemos. Entón o único que tes que facer é me diga o que mesa tamaño eu teño. Entón comeza un moi conxunto limitado de comandos. 

Comeza unha Create Table Update, Mesa, Eliminar Mesa, e describir Table. Estas son as únicas cousas precisa para DynamoDB. Non precisa de un almacenamento configuración do motor. Non se preocupe coa replicación. Non se preocupe sharding. 

Non se preocupe sobre algún deste material. Facemos todo para ti. Entón, iso é unha enorme cantidade de sobrecarga iso é só despegou seu prato. Entón temos os operadores CRUD. CRUD é algo que temos chamar base de datos que é Crear, actualizar, eliminar operadores. Estes son os seus común operacións de base de datos. Cousas como elemento de venda, obter elemento, actualización elementos, borrar obxectos, consulta de lote, dixitalizar. Se quere comprobar a táboa enteira. Puxe todo fóra da mesa. Unha das cousas agradables sobre DynamoDB é que permite a dixitalización paralela. Entón pode realmente deixe-me saber cantas temas que quere executar no que dixitalización. E podemos facer eses temas. Podemos xirar que dixitalizar ata a través de múltiples threads para que poida comprobar a táboa enteira espazo moi, moi rapidamente no DynamoDB. 

A outra API que temos é o que chamamos a nosa API Fluxos. Non imos falar moito moito sobre iso agora. Eu teño algún contido máis tarde en no baralla sobre iso. Pero Fluxos é realmente un running-- pense nisto como o tempo orde e rexistro de cambios partición. Todo o que está a suceder no a táboa móstrase no fluxo. 

Cada escribir á mesa móstrase no fluxo. Podes ler este fluxo, e pode facer cousas con el. Imos falar sobre o que tipo de cousas que facer as cousas como replicación, a creación de índices secundarios. Todo tipo de moi legal cousas que podes facer con iso. 

Tipo de datos. En DynamoDB, apoiamos tanto clave valor e de datos documento tipos. Na parte esquerda da pantalla aquí, temos os nosos tipos básicos. Tipo de valor clave. Estes son cordas, números e binarios. 

Entón, só tres tipos básicos. E entón vostede pode ter conxuntos de aqueles. Unha das cousas agradables sobre NoSQL é pode conter matrices como propiedades. E con DynamoDB pode conter matrices de tipos básicos como unha propiedade raíz. 

E despois hai os tipos de documentos. Cantas persoas están familiarizado con JSON? Vostedes familiarizado con JSON tanto? É basicamente JavaScript, Object, Notation. Permite que basicamente definir unha estrutura xerárquica. 

Pode almacenar un documento JSON en DynamoDB usando compoñentes comúns ou bloques de construción que están dispoñibles na maioría das linguaxes de programación. Entón, se ten o Java, está mirando os mapas e listas. Podo crear obxectos que zona do mapa. Un mapa como valores clave almacenado como propiedades. E pode que as listas de valores dentro destas propiedades. Pode almacenar este complexo estrutura xerárquica como un único atributo dun elemento de DynamoDB. 

Entón táboas no DynamoDB, como a maioría Bases de datos NoSQL, as táboas teñen elementos. En MongoDB faría chamar estes documentos. E sería a base sofá. Ademais unha base de datos de documento. Chama eses documentos. Documentos ou elementos teñen atributos. Pode existir atributos ou non existe no produto. En DynamoDB, hai un atributo obrigatorio. Así como nunha base de datos relacional, ten unha chave primaria nunha tabela. 

DynamoDB ten o que chamamos unha chave de hash. Clave de hash debe ser exclusivo. Entón, cando definir unha táboa hash, basicamente o que eu digo cada elemento terá unha clave de hash. E cada clave de hash debe ser exclusivo. 

Cada elemento defínese por esa chave de mestura orixinal. E só pode haber un. Este é OK, pero moitas veces que as persoas precisan é que eles queren é ese hash clave para facer un pouco máis que ser un identificador único. Moitas veces queremos usar esta chave de hash como o cumio balde agregación nivel. E o xeito de facermos isto é por engadindo o que chamamos unha clave intervalo. 

Entón, se é só un hash mesa, esta debe ser exclusivo. Se é unha táboa hash e variedade, o combinación do hash eo intervalo debe ser exclusivo. Entón, pense nisto deste xeito. Se eu tivera un foro. E a forma ten temas, ten lanza, e ten respostas. 

Entón, eu podería ter un hash clave, que é a identificación de tema. E eu podería ter unha clave de gama, que representa a identificación da resposta. Desta forma, se eu queira obter toda a respostas a determinado tema, Só podo consultar o hash. Podo só dicir que me dar todo os elementos que teñen ese hash. E eu estou indo a obter todas as preguntas ou engadir a este tema particular. Estas agregacións de nivel superior é moi importante. Eles soportan o acceso primario estándar da aplicación. Dun modo xeral, esta é o que queremos facer. Queremos que mesa-- como cargar a táboa, queremos estruturar a datos dentro da táboa de tal xeito que a aplicación pode moi recuperar rapidamente eses resultados. E moitas veces a forma de facelo é para manter estas agregacións como nós introducir os datos. Basicamente, estamos espallando os datos no balde brillante como ven en. 

Intervalo de claves de hash permitir me-- claves ten que ser igualdade. Cando consultar un hash, eu teño que dicir déame un hash que é igual a este. Cando consultar un intervalo, eu pode dicir-me dar un intervalo que está a usar calquera tipo de operador rico que apoiamos. Déame todos os elementos para un hash. É igual, maior que, menos que, non é comezar, existe entre estes dous valores? Entón, estes tipos de consultas de intervalo que estamos sempre interesados ​​en. Agora unha cousa sobre os datos, cando ollar para o acceso a datos, cando acceder os datos, é sempre sobre unha agregación. É sempre sobre os rexistros que están relacionados con este. Dáme todo aquí that's-- todo as transaccións de tarxeta de crédito nesta para o último mes. Isto é unha agregación. 

Case todo o que fai no base de datos é un tipo de agregación. Así, ser capaz de poder establecer estes baldes e darlle estes varían atributos de poder consulta en, esas consultas ricos apoiar moitos, moitos, moitos patróns de acceso da aplicación. 

Entón a outra cousa a clave de hash fai é que nos dá un mecanismo para poder difundir os datos de volta. Bases de datos NoSQL funcionar mellor cando os datos están uniformemente distribuídos en todo o cluster. Cantas persoas están familiarizado con algoritmos de hash? Cando digo de hash e un hashing-- porque un algoritmo de hashing é un xeito de ser capaz de xerar un valor aleatorio de calquera valor dado. Polo tanto, neste caso particular, o algoritmo de hash que corremos é ND 5 con base. 

E se eu tivera un ID, e este é a miña chave de hash, eu teño 1, 2, 3. Cando executar o algoritmo de hash, vai volver e dicir, pozo 1 é igual a 7B, 2 é igual a 48, é igual a 3 CD. Eles están espallados por todo o espazo da chave. E por que fai iso? Porque iso garante que podo poñer os rexistros en varios nós. 

Se eu estou facendo iso incrementalmente, 1, 2, 3. E eu teño unha variedade de hash que rons, neste caso concreto, un pequeno espazo de hash, que vai de 00 a FF, a continuación, os rexistros van vir en e eles están indo a ir 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Que pasa? Cada inserción é indo ao mesmo nodo. Ve o que quero dicir? 

Porque cando dividir o espazo, e eu estender eses rexistros transversalmente, e partición eu, eu vou dicir partición 1 ten espazo clave 0-54. Partición 2 é 55-89. Partición 3 é AA a FF. Entón, se está a usar linearmente incrementando IDs, podes ver o que está pasando. 1, 2, 3, 4, 5, 6, todos fórmase a 54. Entón, como eu estou martelé a rexistros no sistema, todo acaba indo a un nodo. 

Iso non é bo. Esa é unha antipattern. En MongoDB teñen este problema se non usar unha chave de hash. MongoDB lle dá a opción de hash o valor da clave. Ten que sempre facer iso, se está a usar un hash incrementando clave no MongoDB, ou vai ser cravando cada gravación para un nó, e vai ser un factor limitante o seu rendemento escribir mal. 

Audiencia: É que A9 169 en decimal? 

Rick Houlihan: Si, é algo en torno de alí. A9, eu non sei. Vostede tería que incorporarse miña binario a calculadora decimal. Meu cerebro non funciona así. Audiencia: Só un rápido Seus comentarios Mongo. Así é a identificación do obxecto que vén nativamente con Mongo facelo? Rick Houlihan: Será que faría iso? Se especifica-lo. Con MongoDB, ten a opción. Pode specify-- cada documento MongoDB ten que ter un ID subliñado. Ese é o valor único. 

En MongoDB pode especificar a hash-lo ou non. Eles só darlle a opción. Se sabe que é aleatoria, non hai problema. Non precisa facelo. Se sabe que non é aleatorio, que está incrementando, a continuación, facer o hash. 

Agora, a cousa sobre hashing, xa que o hash un value-- e esta é por que claves de hash son sempre consultas únicas, porque eu mudei o valor, agora eu non podo facer unha consulta intervalo. Non podo dicir é isto entre iso ou aquilo, porque o valor de hash non vai como equivalente ao valor real. Entón, cando hash que clave, é só a igualdade. É por iso que en clave de hash DynamoDB consultas son sempre só a igualdade. 

Entón, agora a unha escala key-- cando engadir esta chave gama, estes rexistros principais alcance todos entrar e quedan almacenados no mesmo partición. Entón, eles están moi rapidamente, facilmente recuperado porque este é o hash, esta é a variedade. E ve todo co mesmo hash fica almacenado no mesmo espazo de partición. Pode usar esta chave para axudar a gama atopar os seus datos preto do seu pai. Entón, o que realmente estou facendo aquí? Esta é unha relación un para moitos. A relación entre unha chave de hash ea tecla de intervalo é de un a moitos. Podo ter varias claves de hash. Só pode ter rango múltiple claves dentro de cada clave de hash. 

O hash define o pai, o intervalo define os nenos. Así pode ver que hai analóxica aquí entre o construto relacional e os mesmos tipos de constrúe en NoSQL. A xente fala sobre NoSQL como non relacional. Non é nonrelational. Datos sempre relacións. Estas relacións só son modeladas polo diferente. Imos falar un pouco pouco sobre durabilidade. Cando escribe para DynamoDB, escribe son sempre tres vías replicado. O que significa que temos tres AZ de. Z son de Zonas de dispoñibilidade. Podes pensar en un Dispoñibilidade Zona como un centro de datos ou un conxunto de centros de datos. Esas cousas son xeograficamente illados uns dos outros en diferentes zonas de fallos, a través diferentes redes de enerxía e chairas aluviais. Un fallo nun AZ non é indo para derrubar o outro. Eles están conectados xunto coa fibra escura. Soporta unha sub 1 latencia milissegundo entre AZS. Así repeticións de datos en tempo real capaz de multi AZS. 

E implementacións miúdo multi-Z atender aos requirimentos de alta dispoñibilidade da maioría das organizacións empresariais. Entón DynamoDB está espallada en tres AZS por defecto. Estamos indo só para o coñecemento da escrita cando dous destes tres nós volver e dicir: Si, eu teño. Por que é iso? Porque no lado da lectura estamos só vai darlle os datos de volta cando nós obtelo de dous nós. 

Se eu estou replicar en toda tres, e eu estou lendo a partir de dous, Estou sempre garantida ter polo menos un daqueles lese o máis de copia actual dos datos. Isto é o que fai DynamoDB consistente. Agora podes escoller activar as lecturas consistentes fóra. Caso en que eu vou dicir, Eu só vou ler dun nodo. E eu non podo asegurar que vai sendo os datos máis actuais. 

Así, se unha gravación está chegando, que aínda non foi duplicado, está indo a obter esta copia. Esa é unha lectura finalmente consistente. E que é o que é a metade do custo. Entón, iso é algo para pensar. Cando está lendo fóra DynamoDB, e está configurando a súa capacidade de lectura unidades, se escolle finalmente lecturas consistentes, é moito máis barato, é aproximadamente a metade do custo. 

E así aforrar diñeiro. Pero esa é a súa elección. Se quere unha lectura consistente ou unha lectura finalmente consistente. Isto é algo que pode escoller. 

Imos falar sobre índices. Entón, nós mencionados que agregación de nivel superior. Temos claves de hash, e temos claves alcance. Está ben. E iso é sobre a mesa principal, I ten unha chave de hash, eu teño unha clave intervalo. 

Que significa iso? Eu teño un atributo que Pode realizar consultas contra ricos. É a clave intervalo. Os outros atributos que item-- Podo filtrar eses atributos. Pero eu non podo facer cousas como, el iníciase coa, ou é maior que. 

Como podo facer iso? Eu crear un índice. Hai dous tipos de índices en DynamoDB. Un índice é realmente outra visión da táboa. E o índice secundario local. 

O primeiro imos falar. Entón secundarios locais son coexistiram na mesma partición como os datos. E como tal, son sobre o mesmo nodo físico. Son o que chamamos consistente. Significado, van recoñecer a gravación, xunto coa mesa. Cando a gravación entra, imos escribir a través do índice. Imos escribir-se á mesa, e despois imos recoñecer. Entón, iso é consistente. Xa que a escrita foi recoñecido dende a táboa, se pode garantir que o Índice secundaria local terá a mesma visión dos datos. Pero o que eles permiten que fai é definir claves Faixa suplentes. 

Ten que empregar o mesmo hash clave como a táboa principal, porque son co-situado na mesma partición, e son consistentes. Pero podo crear un índice con diferentes claves de alcance. Así, por exemplo, se eu tivese un fabricante que tiña unha táboa de pezas en bruto chegando. E pezas brutas entrar, e están agregados por montaxe. E quizais haxa un recall. 

Calquera parte que se fixo por este fabricante tras esta data, Necesito tirar da miña liña. Podo xirar un índice que estaría mirando, agregación na data de Fabricación de que parte particular. Entón, se a miña mesa nivel superior era xa hash polo fabricante, quizais foi organizado en parte ID, I Pode crear un índice que a táboa off como hash polo fabricante e variaron en data de fabricación. E de que xeito eu podería dicir, calquera cousa que foi fabricado entre esas datas, Necesito tirar dende a liña. Entón, iso é un índice secundario local. 

Estes teñen o efecto de limitar o seu espazo de clave hash. Porque coexistiram no mesmo nodo de almacenamento, eles limitan a clave de hash espazo de 10 gigabytes. DynamoDB, baixo a táboas, particionará súa mesa cada 10 gigabytes. Cando poñer 10 GB de datos, nos ir [PHH], e nós engadimos outro nodo. 

Non imos dividir o LSI a través de múltiples particións. Imos dividir a táboa. Pero non imos dividir o LSI. Entón, iso é algo importante comprender é se está facendo moito, moi, moi grandes agregacións, entón vai ser limitado 10 gigabytes no seu LSIs. 

En tal caso, podemos usar secundarios globais. Secundarios globais son realmente outra mesa. Eles existen completamente fóra de o lado da súa táboa primaria. E me permita atopar unha estrutura totalmente diferente. Entón, pense nisto como os datos están sendo inseridas en dúas táboas diferentes, estruturado de dous xeitos diferentes. 

Podo definir un totalmente diferente clave de hash. Podo definir un totalmente diferente clave de gama. E podo executar este de forma totalmente independente. Por unha cuestión de feito, eu teño provisionais miña capacidade de lectura e capacidade para escribir o meu índices secundarios globais de forma totalmente independente da miña táboa primaria. Se eu definir ese índice, digo- el o que ler e escribir capacidade que vai estar a usar. 

E que é separado da miña mesa principal. Agora, tanto dos índices permitir non só definen claves de hash e alcance, pero nos permiten proxectar valores adicionais. Entón, se eu quero ler fóra do índice, e quero obter un conxunto de datos, Eu non teño de volver para o inicio mesa para obter os atributos adicionais. Podo proxectar os adicional atributos na táboa para soportar o estándar de acceso. Sei que probablemente está metendo algúns realmente, realmente-- metendo as herbas daniñas aquí en algunhas destas cousas. Agora eu teño a deriva fóra deste. 

Audiencia: [inaudível] clave --table quería dicir foi un hash? O hash orixinal? Múltiples slats? 

Rick Houlihan: Si. Si. A clave táboa basicamente apunta para o elemento. Así, un índice é un punteiro ao os elementos orixinais na mesa. Agora podes optar por construír un índice que só ten a chave da táboa, e hai outras propiedades. E por que eu podería facelo? Ben, quizais teña moi grandes elementos. 

Realmente só precisa saber which-- meu nivel de acceso pode dicir, os elementos que conteñen esa propiedade? Non é preciso devolver o elemento. Eu só teño que saber os elementos que contelo. Así, pode crear índices que só ten a chave da táboa. 

Pero iso é todo o que un índice na base de datos é para. É para poder rapidamente identificar cales rexistros, cales liñas, que elementos na táboa ten as propiedades que eu estou buscando. 

GSIS, entón como funcionan? GSIS basicamente son asíncrono. A actualización ven a mesa, táboa é actualizada a continuación, de forma asíncrona todo o seu GSIS. É por iso que son GSIS finalmente, consistente. 

É importante ter en conta que, cando está construíndo GSIS, e entender que está creando outra dimensión da aggregation-- Agora, imos dicir que un bo exemplo aquí é un fabricante. Eu creo que eu podería ter falado sobre un fabricante de dispositivos médicos. Fabricantes de dispositivos médicos moitas veces teñen partes serializado. As pezas que entran en unha substitución da anca todo ter un pouco de número de serie neles. E poderían millóns e millóns e millóns de pezas en todos os dispositivos que elas traen. Ben, eles precisan agregar baixo diferentes dimensións, as pezas nunha montaxe, todo o partes que se fixeron nunha determinada liña, todo as pezas que viñeron a partir dun determinado fabricante nunha determinada data. E, ás veces, estas agregacións plantexa-se na casa dos millóns. 

Entón, eu traballo con algúns dos estes faces que están sufrindo porque están creando estas agregacións ginormous nos seus índices secundarios. Poden ter unha pezas de materias táboa que ven como única de hash. Cada parte ten un número de serie único. Eu uso o número de serie como o hash. É fermoso. Miña táboa de datos en bruto é espallada en todo o espazo da chave. Meu [? escribir?] [? inxestión?] é incrible. Eu tomo unha morea de datos. Entón o que fan é crear un GSI. E digo, xa sabe o que, eu teño ver todas as partes para este fabricante. Ben, de súpeto eu son tendo mil millóns de liñas, e enche-los para un nó, porque cando I agregar como o ID fabricante coma a suma, e número de peza como o intervalo, a continuación, de súpeto eu son poñer mil millóns de partes en que este fabricante ten me entregado. 

Isto pode causar unha serie de presión sobre o GSI, de novo, porque estou martelé un nó. Estou poñendo todos estes inserir un nó. E iso é un caso de uso problemático real. Agora, eu teño un bo deseño patrón de como evitar isto. E iso é un dos problemas que sempre traballar. Pero o que pasa, é a GSI pode non ten capacidade de gravación suficiente para poder empuxar todos aqueles liñas nun único nodo. E o que pasa a continuación é a primario, a táboa de cliente, táboa principal será estrangulada porque o GSI non pode manter-se. Así, a miña taxa de inserción vai caer na mesa principal como o meu GSI intenta manterse. 

Todo ben, entón GSI de, LSI de, cal deles debo empregar? LSI de son consistentes. GSI de, finalmente, son consistentes. Se iso é OK, eu recomendo usar un GSI, son moito máis flexibles. LSI de pode ser modelado como un GSI. E se o tamaño dos datos claves hash en súa colección sexa superior a 10 gigabytes, entón vai querer usar isto GSI porque é só un límite duro. 

Todo ben, entón escala. Rendemento no Dynamo DB, vostede prestación lata [inaudível] throughput para unha mesa. Temos clientes que teñen provisionado 60 billion-- está facendo 60 millóns de pedidos, regularmente rodando a máis de un millón solicitudes por segundo nas nosas mesas. Non hai realmente ningunha límite teórico de canto e quão rápido a mesa pode ser executado no Dynamo DB. Hai uns suave límites na súa conta que poñemos alí, entón que non tolear. Se queres máis que que, non un problema. Vén dicirnos. Imos converter-se no mostrador. 

Cada conta é limitado a un certo nivel en todos os servizos, só fóra do pau para que a xente non tolear se meten en problemas. Non hai límite de tamaño. Pode pór calquera número de elementos nunha táboa. O tamaño dun elemento é limitada a 400 kilobytes cada, que sería elemento non os atributos. Así, a suma de todos os atributos está limitado a 400 kilobytes. E entón, de novo, temos ese pequeno problema LSI co límite de 10 gigabyte por hash. Audiencia: número pequeno, eu estou falta o que está me dicindo que é-- Audiencia: Oh, 400 kilobytes é o tamaño máximo por elemento. Así, un elemento ten todos os atributos. Entón, 400 K é o tamaño total dese elemento, 400 kilobytes. Así, de todos os atributos combinados, todos os datos que está en todos estes atributos, enrolado nun tamaño total, Actualmente o límite de elementos hoxe é de 400 k. Así dimensionamento de novo, conseguida través de particionamento. O throughput é provisionado no nivel da táboa. E non hai realmente dous botóns. Temos capacidade de lectura e escribir capacidade. 

Entón, estas son axustados independentemente un do outro. Medida do estrictamente RCU lecturas consistentes. OK, entón se está dicindo que quero 1000 RCU de eses son estrictamente consistente, estas son as lecturas consistentes. Se digo que quero eventual lecturas consistentes, podes provisionar 1000 RCU do, vai para, finalmente, 2000 lecturas consistentes. E a metade do prezo para os finalmente, consisten le. 

Unha vez máis, axustada independentemente un do outro. E eles teñen o throughput-- Se consumir o 100% do seu RCU, non vai ter impacto no dispoñibilidade dos seus dereitos. Entón, eles están completamente independentes uns dos outros. Todo ben, entón unha das cousas que Mencionei brevemente foi estrangulamento. Estrangulamento é malo. Estrangulamento indica mal non SQL. Hai cousas que podemos facer para axuda- vostede aliviar o estrangulamento que está enfrentando. Pero a mellor solución para iso é, imos dar un ollar para o que está facendo, porque hai un anti-estándar en xogo aquí. 

Esas cousas, cousas como non uniforme carga de traballo, teclas de acceso, anteparos quentes. Estou batendo un espazo de clave en particular moi difícil por algún motivo particular. Por que estou a facer iso? Imos descubrir iso. Estou mesturando meus datos quentes con datos fríos. Estou deixando miñas táboas chegar enorme, pero non hai realmente só algunhas subconxunto dos datos que é realmente interesante para min. Así, para os datos de rexistro, por exemplo, unha gran cantidade de clientes, que reciben os datos de rexistro a cada día. Teñen unha enorme cantidade de datos de rexistro. 

Se vostede está só botan todo o que rexistro datos en unha gran mesa, co paso do tempo que a táboa se ve enorme. Pero eu estou realmente interesado só en últimas 24 horas, os últimos sete días, nos últimos 30 días. Sexa cal sexa a xanela de tempo que eu estou interesado en ollar para o evento que me molesta, é o evento que é interesante para min, esa é a única vez que a fiestra que eu teño. Entón por que estou poñendo 10 anos val de datos de rexistro na táboa? O que fai que é a táboa de fragmento. 

El está enorme. Comeza a se espallar para fóra a través de miles de nós. E xa que a súa capacidade é tan baixo, é de feito, en cada tipo de limitar un deses nodos individuais. Entón, imos comezar mirando como nós rolar aquela mesa. Como podemos xestionar estes datos algo mellor evitar estes problemas. E o que iso parece? Isto é o que parece. Isto é o que mal NoSQL parece. 

Eu teño unha tecla de acceso aquí. Se ollar para o lado aquí, estas son as miñas particións. Teño 16 particións-se aquí nese base de datos particular. Facemos isto todo o tempo. Eu corro isto para clientes todos os tempos. É o chamado mapa de calor. Mapa de calor me di como é accedendo seu espazo clave. E o que iso está me dicindo é que hai un hash de especial que este cara gusta de unha lote terrible, porque é bate-lo moi, moi difícil. 

Así, o azul é bo. Gústanos azul. Nós non nos gusta de vermello. Onde a presión da Rede levántase a 100%. 100%, agora vai ser estrangulado. Así, sempre que ver todas as liñas vermellas, como isto-- e non é só Dynamo DB-- cada base de datos NoSQL ten este problema. Hai anti-patróns que poden conducir este tipo de condicións. O que fago é traballar cos clientes para aliviar estas condicions. 

E o que iso parece? E iso está quedando máis Fóra do Dynamo DB rendemento, pero é realmente quedando o máximo de NoSQL. Este non é restrinxida a dínamo. Este é definitely-- I adoitaba traballar no Mongo. Eu estou familiarizado con moitas plataformas NoSQL. Cada un ten estes tipos de problemas de teclas de atallo. Para aproveitar o máximo proveito de calquera NoSQL base de datos, especialmente Dynamo DB, quere crear as táboas onde o elemento clave de hash ten un gran número de valores distintos, un elevado grao de cardinalidade. Porque iso significa que eu estou escribindo para os lotes de diferentes baldes. 

Os máis baldes que eu son escribir para, o máis probable Eu son a espallar a carga de gravación ou ler cargar para fóra a través de varios nós, o máis probable que eu estou a ter un alto rendemento sobre a mesa. E entón eu quero que os valores que se solicitadas de forma bastante equilibrada no tempo e uniforme posible de forma aleatoria. Ben, iso é ben interesante, porque eu non podo realmente control cando os usuarios veñen. Entón, só tes que dicir que, se espallar cousas para fóra en todo o espazo da chave, probablemente estaremos en mellor forma. 

Hai un certo cantidade de tempo de entrega que non vai para poder control. Pero estes son realmente o dúas dimensións que temos, espazo, o acceso uniformemente propagación, tempo, solicitudes que chegan uniformemente espazos no tempo. E se os dous condicións están a ser cumpridas, a continuación, que é o que é vai parecer. Este é moito máis agradable. Estamos moi felices aquí. Temos un nivel de acceso moi mesmo. Si, quizais está a recibir un pouca presión de cando en vez, pero nada realmente moi extensa. Por iso, é incrible como moitas veces, cando eu traballo cos clientes, que primeiro gráfico co vermello gran bar e todo o que feo amarelo é en todo o lugar, nós facer co exercicio despois dun par de meses de re-arquitectura, están executando exactamente o mesmo carga de traballo coa mesma carga exacta. E iso é o que está parecendo agora. Entón, o que lle gañou con NoSQL é un esquema de datos que é absolutamente amarre ao estándar de acceso. 

E pode optimizar o sistema de datos para soportar ese patrón de acceso. Se non fai iso, entón está indo para ver estes tipos de problemas con esas teclas de atallo. 

Audiencia: Ben, inevitablemente, algúns lugares vai ser máis quente do que outros. 

Rick Houlihan: Sempre. Sempre. Si, quero dicir, sempre um-- e, de novo, hai algúns patróns de deseño imos pasar por que vai falar sobre como trata con estas super-grandes agregacións. É dicir, eu teño que telos, como imos tratar con eles? I got un bo caso de uso que nós imos falar sobre por que. 

Todo ben, entón imos falar sobre algúns clientes agora. Eses faces son AdRoll. Non sei se é familiarizados con AdRoll. Probablemente velos moi no navegador. Son re-segmentación de anuncios, son o maior negocio ad re-segmentación alí fora. Eles normalmente executado regularmente durante 60 millóns de transaccións ao día. Están facendo máis dun millón transaccións por segundo. Teñen unha táboa moi sinxelo estrutura, a táboa máis movido. É basicamente só un clave hash é o cookie, o intervalo é o grupo demográfico categoría, e en seguida, o terceiro atributo é a puntuación. 

Polo tanto, todos temos galletas en noso navegador a partir destes eles. E cando vai a un comerciante participante, eles basicamente marcar vostede fronte varias categorías demográficas. Cando vai a un sitio web e di que quero ver iso AD-- ou, basicamente, non di que-- pero cando vai para o sitio din que quere ver este anuncio. E van obter ese anuncio de AdRoll. AdRoll te mira arriba na súa mesa. Eles atopar o seu cookie. Os anunciantes din eles, quero alguén que é de mediana idade, Home de 40 anos de idade, en deportes. E marcaren vostede nestes datos demográficos e decidir se quere ou non iso é un bo anuncio para ti. 

Agora eles teñen un SLA con seus provedores de publicidade para proporcionar sub-10 milissegundo resposta a cada solicitude. Entón, eles están a usar Dynamo DB para iso. Están nos a bater millón de solicitudes por segundo. Son capaces de facer toda a súa investigacións, selección todos os datos, e obter ese enlace engadir ao que anunciante en menos de 10 milisegundos. Realmente fenomenal aplicación que teñen. 

Eses faces actually-- son estes os mozos. Eu non estou seguro se é estes faces. Pode ser estes faces. Basicamente dixo US-- non, non creo que foron eles. Creo que foi outra persoa. Eu estaba a traballar cun cliente que me dixo que, agora que teñen ir para Dynamo DB, son gastar máis diñeiro en lanches para seu equipo de desenvolvemento cada mes do que gastan en base de datos. Por iso, imos darlle un idea da redución de custos que pode obter no Dynamo DB é enorme. Todo ben, Dropcam é outra empresa. Estes cara é tipo de-- se pensa de internet das cousas, Dropcam é basicamente vídeo de seguridade de internet. Se pon a súa cámara para fóra alí. Cámara ten un detector de movemento. Alguén ven xunto, desencadea un punto de sinalización. Cámara comeza a gravar por un tempo ata non detecta calquera movemento máis. Pon-se que o vídeo en Internet. 

Dropcam era unha empresa que está basicamente ligado ao Dínamo DB porque estaban experimentando enormes dores de crecemento. E o que nos dixeron, de súpeto petabytes de datos. Eles non tiñan idea seu servizo sería tan exitoso. Máis que de entrada de vídeo YouTube é o que estes faces están quedando. Falan DynamoDB para seguir todo o metadatos en todos os seus puntos clave de vídeo. 

Entón eles teñen baldes S3 eles empurran todos os artefactos binarios en. E entón eles teñen Rexistros Dynamo DB que apuntar a xente para estas S3 tres obxectos. Cando precisan de ollar para un vídeo, eles miran a ser o rexistro no Dynamo DB. Eles click no enlace. Eles tirar abaixo o vídeo S3. Entón, iso é o tipo que isto parece. E isto é en liña recta do seu equipo. 

Dynamo DB reduce a súa tempo de entrega para eventos vídeo de cinco a 10 segundos. Na súa tenda relacional de idade, eles acostumaban ter que ir e executar varias consultas complexas figura cales vídeos para tirar abaixo, a menos de 50 milisegundos. Polo que é incrible, incrible o que de rendemento pode comezar cando optimizar e sintonizar a base de datos subxacente para soportar o estándar de acceso. Halfbrick, estes faces, o que é, Fruit Ninja creo que é a súa cousa. Que todas as carreiras en Dynamo DB. E estes tíos, son unha boa equipo de desenvolvemento, gran desenvolvemento tenda. 

Non é un bo equipo de operacións. Eles non teñen moito de recursos de operación. Estaban loitando intentando manter súa infraestrutura de aplicación up e en execución. Eles viñeron ata nós. Eles ollaron para que Dynamo DB. Eles dixeron, que é para nós. Eles construíron o seu todo estrutura de aplicacións nel. Algúns moi bos comentarios aquí do equipo na súa capacidade agora concentrarse no edificio o xogo e non ter que manter o infraestrutura, o que estaba facendo unha enorme cantidade de sobrecarga para o seu equipo. Entón, iso é algo que-- o beneficio que comeza a partir Dynamo DB. 

Todo ben, metendo modelaxe de datos aquí. E nós falamos un pouco sobre este 1-1, un para moitos, e moitos para moitos relacións de tipo. E como manter os de Dynamo. En Dynamo DB usan índices, dun modo xeral, para rodar os datos de un sabor a outro. Claves de hash, claves de gama, e índices. 

Nese particular exemplo, como a maioría dos estados ten unha esixencia de licenza que só a licenza de conducir de un por persoa. Non pode ir para obter dúas condutor licenzas no estado de Boston. Non podo facelo en Texas. Ese é un tipo do xeito que é. E así o DMV, temos investigacións, nós quero mirar para arriba a carteira de motores polo número de seguridade social. Quero ollar-se os detalles do usuario polo número de carné de conducir. 

Así, poderiamos ter unha mesa de usuario que ten unha chave de hash no número de serie, ou o número de seguridade social, e varios atributos definidos no elemento. Agora, naquela mesa I podería definir un GSI que flips que preto que di que quero unha chave de hash na licenza e, a continuación, todos os outros elementos. Agora, se eu quere consultar e atopar o número de licenza para calquera Sociais Número de seguridade, podo consultar a táboa principal. 

Se eu queira consultar e quero para obter a seguridade social número ou outros atributos por un número de licenza, podo consultar o GSI. Este modelo é que un a unha relación. Só unha forma moi simple GSI, virar as cousas arredor. Agora, falar sobre un para moitos. Un para moitos é basicamente súa chave gama hash. Onde temos unha morea con este caso de uso é datos do monitor. Monitor de datos ven en común rango, como internet das cousas. Sempre obter todos estes rexistros benvida en todo o tempo. 

E quero atopar todas as lecturas entre un determinado período de tempo. É unha consulta moi común en infraestrutura de seguimento. A forma de ir sobre isto é atopar un estrutura de tabela, unha mesa. Eu teño unha táboa de medicións do dispositivo cunha chave de hash sobre a identificación do dispositivo. E eu teño unha clave intervalo na timestamp, ou neste caso, o épico. E iso permíteme facer complexo consultas en que a clave gama e voltar os rexistros que son en relación ao resultado definir que eu estou buscando. E constrúe que un para moitos relación na táboa usando o fondo clave de hash, estrutura de clave intervalo. 

Entón, ese é o tipo de construción na táboa da Dynamo DB. Cando definir un hash e mesa de gama t, eu son a definición dunha relación un para moitos. É unha relación pai-fillo. 

Imos falar sobre moitos para moitos relacións. E para este exemplo concreto de novo, imos usar GSI de. E imos falar sobre o xogo escenario onde eu teño un determinado usuario. Quero descubrir todos os xogos que está rexistrado para ou xogar en. E para un determinado partido, eu quere atopar todos os usuarios. Entón, como podo facer iso? Miña táboa de xogos do usuario, eu vou para ter unha clave de hash de ID de usuario e unha chave intervalo do xogo. 

Así, un usuario pode ter varios xogos. É unha relación un para moitos entre o usuario e os xogos que xoga. E a continuación, no GSI, Vou virar esa volta. Vou botar no xogo e Vou variar sobre o usuario. Entón, se eu queira obter toda a xogo o usuario de xogar en, Vou consultar a táboa principal. Se eu queira obter todos os usuarios que están xogando un xogo particular, Eu consultar o GSI. Así ves como imos facelo? Constrúe a apoiar estes do GSI o caso de uso, a aplicación, o acceso modelo, a aplicación. 

Se eu ter consultar en esta dimensión, deixe- me crear un índice en que dimensión. Se non fai iso, eu non me importa. E, dependendo do caso de uso, I Pode o índice ou non podería. Se é un simple un para moitos, da táboa principal é bo. Se eu teño que facer estes moitos a moitos de, ou eu teño que facer un para queridos, entón quizais eu teño a segunda no índice. Entón, todo depende o que eu estou tentando facer eo que eu estou tentando obter realizado. 

Probablemente non vou gastar moito tempo falando sobre documentos. Isto torna-se un pouco, probablemente, máis profundo do que necesitamos para entrar. Imos falar un pouco expresión de consulta sobre a rica. Así, no Dynamo DB temos a capacidade de crear o que chamamos expresións de proxección. Proxección expresións son simplemente escoller os campos ou os valores que desexe ver. OK, entón eu facer unha selección. Fago unha consulta contra Dynamo DB. E digo, xa sabe o que, mostra me só os cinco estrelas comentarios para este produto particular. Entón, iso é todo o que quero ver. Non quero ver todas as outros atributos da liña, Eu só quero ver iso. É como cando en SQL dicir selecciona estrela ou de mesa, comeza todo. Cando digo seleccione o nome mesa, só obter un atributo. É o mesmo tipo de cousas en Dynamo DB ou máis bases de datos NoSQL. As expresións de filtro permítame basicamente cortar o conxunto de resultados para abaixo. Entón fago unha consulta. Consulta pode volver con 500 elementos. Pero eu só quero os elementos que ten un atributo que di iso. OK, entón imos filtrar estes elementos que non corresponden a esta consulta particular. Entón temos expresións de filtro. 

As expresións de filtro pode ser executado en calquera atributo. Eles non son como consultas por eido. Levantar cuestións son máis selectivos. Consultas de filtro me obrigar a ir se os resultados completos definir e, a continuación esculpir os datos que eu non quero. Por que iso é importante? Porque lin todo. Nunha consulta, eu vou ler e vai ser un xigante sobre os datos. E entón eu vou esculpir o que eu teño. E se eu só estou conquistando un par de liñas, entón iso é OK. Non é tan ineficiente. 

Pero se eu estou lendo unha pila de datos, só para esculpir un elemento, entón eu vou ser mellor fóra de usar unha consulta de gama, porque é moito máis selectivo. El me vai gardar unha chea de diñeiro, porque pagar por esa lectura. Sempre que os resultados que vén de volta cruzar esa fío pode ser menor, pero eu estou pagando para a lectura. Así, entender como está a recibir os datos. Isto é moi importante na Dynamo DB. 

As expresións condicionais, isto é o que podería chamar de bloqueo optimista. Actualización se existe, ou se este valor é equivalente ao que especifiques. E se eu tivera un selo de tempo nun rexistro, eu podería ler os datos. Podería cambiar eses datos. Eu podería ir gravación que datos ao seu banco de datos. Se alguén cambiou o rexistro, o timestamp podería cambiar. E de que xeito a miña condicional actualización podería dicir actualización A data e hora é igual a este. Ou a actualización fallará porque alguén actualizar o rexistro no mesmo período. 

Iso é o que chamamos de bloqueo optimista. Isto significa que alguén pode entrar e mudalo, e eu estou indo a detecta-lo cando volten a escribir. E entón eu podo realmente ler que datos e dicir, oh, el cambiou iso. Necesito explicar iso. E podo cambiar os datos na miña gravar e aplicar outra actualización. Entón pode incorporarse os incrementar actualizacións que se producen entre o momento que le os datos ea tempo pode gravar os datos. 

Audiencia: E o filtro expresión, de feito, non significa no número ou não-- 

[Interpoñendo voces] Rick Houlihan: Non vou obter moito para iso. Esta é unha palabra chave reservada. A vista é unha libra reservados contrasinal no Dynamo DB. Cada banco de datos ten a súa propia reservados nomes para as coleccións que non pode usar. Dynamo DB, se se especifica unha libra diante desta, pode definir os nomes anteriores. Este é un valor de referencia. Probablemente non é o mellor para sintaxe ten alí enriba desta discusión, porque recibe nalgúns real-- Eu falaría máis sobre iso nun nivel máis profundo. 

Pero basta dicir, isto podería ser consulta dixitalizar onde views-- nin libra vista é superior a 10. É un valor numérico, si. Se quere, podemos falar de que, tras a discusión. Todo ben, entón estamos entrando algúns escenarios en prácticas onde imos falar sobre algunhas aplicacións aquí. Cales son os casos de uso para Dynamo DB. ¿Qué son o deseño patróns en Dynamo DB. 

E o primeiro que imos falar é a internet das cousas. Entón temos unha morea de-- creo, o que é máis que ele-- 50% de tráfico en internet hoxe en día é en realidade xerado por máquinas, procesos automatizados, non por seres humanos. Quero dicir esta cousa esa cousa que leva no seu peto, cantos datos que esa cousa é realmente enviando arredor sen ti sabendo que é absolutamente incrible. Súa localización, información sobre o quão rápido está indo. Como pensas que Google Maps funciona cando lle din que o tráfico é. É porque hai millóns e millóns de persoas en torno de condución cos teléfonos que están enviando datos en todas partes o tempo. Entón, unha das cousas sobre este tipo de datos que vén en, datos do monitor, ingrese datos, datos de series temporais, é que é xeralmente só é interesante para un pouco de tempo. Tras este tempo, é non é tan interesante. Entón nós falamos sobre, non deixe esas táboas crecer sen límites. A idea aquí é que talvez teña 24 horas por valor de acontecementos na miña mesa quente. E que mesa quente será provisionais nunha taxa moi alta, porque está tomando unha morea de datos. Está levando unha morea de datos e eu estou lendo moito. Eu teño unha morea de operación consultas que executan en relación a estes datos. 

Tras 24 horas, hey, sabe, eu non me importa. Entón, talvez rolo cada medianoite sobre a miña mesa para unha nova táboa e eu desprovisione esta táboa. E eu vou levar de RCU e Abaixo do WCU porque 24 horas despois Non estou correndo como moitos consultas en que os datos. Entón, eu estou indo a aforrar diñeiro. E quizais 30 días máis tarde, eu non aínda se preocupe todo. Podería asumir a WCU de todo o camiño para un, porque sabe o que é Nunca se ve gravado. Os datos son de 30 días de idade. Nunca cambia. 

E é case nunca vai conseguir ler, entón teremos que RCU para 10. E eu estou aforrar unha tonelada de diñeiro con iso datos, e só pagando por meus datos quentes. Entón esa é a cousa importante é ollar en cando mira para unha serie temporal datos entrando en volume. Estas son estratexias. Agora, eu podería simplemente deixalo van todos para a mesma táboa e deixe que a táboa crecer. Finalmente, eu vou ver problemas de rendemento. Vou ter que comezar a arquivar algúns deses datos para fóra da mesa, que non. 

Imos moito mellor proxecto seu programa para que poida operar este camiño correcto. Entón é só automática no código da aplicación. Á medianoite cada noite rula a táboa. Quizais o que eu teño é de un deslizamento ventá de 24 horas de datos. A continuación, nunha base regular que eu son chamando de datos fóra da mesa. Estou cortando-o con unha Cron traballo e estou colocando- para estes cadros, o que necesitas. Polo tanto, se un rollover traballa, iso é gran. Se non, corte-la. Pero imos manter os datos quente lonxe dos seus datos fríos. Vai salvarte unha morea de cartos e facer as súas táboas máis rendemento. Polo tanto, a seguinte cousa que vou falar é de case catálogo de produtos. Catálogo de productos é caso de uso moi común. Este é realmente un estándar moi común que veremos nunha variedade de cousas. Vostede sabe, para Twitter exemplo, un tweet quente. Todo o mundo está benvida e agarrando que tweet. Catálogo de produtos, eu teño unha venda. Eu teño unha venda quente. Teño 70.000 solicitudes por segunda vinda dun produto descrición do meu catálogo de produtos. Vémolo no polo miúdo operación un pouco. Entón, como imos tratar con isto? Non hai ningunha forma de tratar con isto. Todos os meus usuarios queren ver o mesmo anaco de datos. Están están chegando, ao mesmo tempo. E eles están todos facendo peticións para o mesmo anaco de datos. Tanto me dá a clave quente, que grande e vermello Listra no meu gráfico que non nos gusta. E iso é o que parece. Así, en toda a miña tecla espazo que estou a recibir martelé nos elementos de venda. Estou recibindo nada en calquera outro lugar. 

¿Como aliviar este problema? Ben, nós aliviar esta con caché. Cache, se pon basicamente un in-memory partición diante da base de datos. Conseguimos [Inaudível] caché, como Pode configurar o seu propio caché, [inaudível] caché de [? d ,?] o que quere. Poña isto diante da base de datos. E de que xeito pode almacenar eses datos a partir desas teclas de acceso superior en que o caché espazo e ler a caché. 

E entón a maioría das súas lecturas comezar a ollar como este. Teño todos estes caché de bate-se aquí e eu non teño nada a suceder aquí porque base de datos está sentado detrás do cache e non a le pasar. Se eu cambiar os datos na base de datos, eu teño que actualizar a caché. Podemos usar algo como vapores de facelo. E eu vou explicar como funciona isto. Todo ben, messaging. Correo electrónico, todos usamos e-mail. 

Este é un bo exemplo. Temos algún tipo de táboa de mensaxes. E nós temos caixa de entrada e caixa de saída. Isto é o que o faría SQL Look Like a construír esta caixa de entrada. Nós tipo de usar o mesmo tipo da estratexia de usar GSI de, GSI de para a miña caixa de entrada e miña caixa de saída. Entón, eu teño mensaxes de materias benvida na miña táboa de mensaxes. E o primeiro achegamento a este pode ser, por exemplo, OK, non hai problema. Teño mensaxes materias. Mensaxes procedentes [inaudível] mensaxe de ID, iso é óptimo. Ese é o meu hash exclusivo. Vou crear dous GSI de un para a miña caixa de entrada, unha para a miña caixa de saída. E o primeiro que vou facer é que eu vou dicir a miña chave de hash é será o destinatario e Vou organizar na data. Isto é fantástico. Eu teño a miña fermosa vista aquí. Pero hai un pequeno problema aquí. E ten iso en bases de datos relacionais ben. Eles chamado de particionamento vertical. Quere manter os seus datos gran lonxe dos seus datos pequenos. 

E a razón pola que é porque eu teño que vaia ler os elementos de obter os atributos. E se os meus corpos están todos aquí, despois de ler só algúns elementos o meu lonxitude do corpo é media 256 kilobytes cada, a matemática está moi feo. Entón, digamos que quero ler caixa de entrada de David. Caixa de entrada de David ten 50 elementos. A media eo tamaño é de 256 kilobytes. Aquí está a miña taxa de conversión para RCU é de catro kilobytes. 

OK, imos con lecturas finalmente consistentes. Eu aínda estou comendo 1600 RCU do só para ler caixa de entrada de David. Ouch. OK, agora imos pensar sobre como a aplicación funciona. Se eu estou nunha aplicación de correo electrónico e Eu estou mirando para a miña caixa de entrada, e eu ollar para o corpo de cada mensaxe, non, eu estou ollando para os resumos. Estou mirando só as cabeceiras. Entón, imos construír unha estrutura de táboa que se parece máis con iso. 

Entón aquí está a información que o meu fluxo de traballo precisa. Está na miña caixa de entrada GSI. É a data, o remitente, o tema e, a continuación, a identificación da mensaxe, que apunta de volta para a táboa de mensaxes onde podo obter o corpo. Ben, estes serían IDs de rexistro. Eles ían apuntar ao seu IDs de elemento na táboa de Dynamo DB. Cada índice sempre creates-- sempre o elemento ID como parte de-- que vén co índice. 

Todo ben. Audiencia: Di-lo onde se garda? Rick Houlihan: Si, di- exactly-- iso é o que fai. Di aquí é o meu record re. E vai apuntala-lo de volta para o meu record re. Exactamente. OK, entón agora é a miña caixa de entrada de feito, moito menor. E iso realmente soporta o fluxo de traballo dun programa de correo electrónico. Así, a miña caixa de entrada, eu premer. Eu ir xunto e eu premer sobre a mensaxe, que é cando eu teño ir buscar o corpo, porque eu vou ir a unha visión diferente. Entón, se pensar sobre o tipo de MVC cadro, controlador de vista do modelo. 

O modelo contén a datos que a visión necesidades eo controlador interactúa con. Cando cambiar o cadro, cando Eu cambiar a perspectiva, que é OK para volver ao servidor e repoboar o modelo, porque é o que o usuario espera. Cando cambiar de vista, que é cando podemos ir ao seu banco de datos. Entón correo electrónico, faga clic en. Eu estou mirando para o corpo. Ida e volta. Vai buscar o corpo. 

Eu leo ​​moito menos datos. Eu só estou lendo os corpos que David necesita cando precisa deles. E eu non estou queimar en 1600 RCU é só para mostrar a súa bandexa de entrada. Entón agora isso-- este é o camiño que LSI ou GSI-- Sinto moito, GSI, daría correcto. Temos a nosa haxix no destinatario. Temos a clave gama na data. E nós temos os atributos proxectados que necesitamos só para apoiar a visión. 

Nós virar para que a caixa de saída. Hash no remitente. E, en esencia, temos a, vista limpo moi agradable. E é que basically-- ten este agradable mensaxes táboa que está a ser espallado ben porque é hash soamente, hash ID mensaxe. E nós temos dous índices que están xirando fóra de devandito cadro. Todo ben, entón idea aquí non é facer manter os grandes datos e este pequeno datos en conxunto. Particionar vertical, particionar esas táboas. Non le datos que non ten que. Todo ben, xogo. Todos gusta de xogos. Polo menos me gusta de xogos despois. Así, algunhas das cousas que xestione cando estamos a pensar sobre o xogo, non? Xogos nestes días, especialmente móbil xogo, é todo sobre o pensamento. E eu estou indo a executar aquí un pouco lonxe DynamoDB. Vou traer a discusión dalgúns en torno a algúns dos outras tecnoloxías da AWS. 

Pero a idea sobre o xogo é pensar sobre en termos de APIs, APIs que son, dun modo xeral, HTTP e JSON. É como xogos para móbil tipo de interactuar coas súas extremidades traseiras. Eles fan JSON mensaxe. Fican de datos, e é todo, dun modo xeral, en Niza APIs JSON. 

Cousas como facer amigos, obter os datos leaderboard, cambio, contido xerado polo usuario, empuxe ao seu sistema, estes son os tipos de cousas que nós imos facer. Datos de activos binario, estes datos Pode non sentir na base de datos. Isto pode sentir-se nun almacenamento de obxecto, non? Pero a base de datos vai acaban dicindo ao sistema, contando a aplicación onde ir busca-la. E, inevitablemente, para varios xogadores servidores, infraestrutura de back-end, e deseñado para alta dispoñibilidade e escalabilidade. Entón, estas son as cousas que todos queremos na infraestrutura do xogo hoxe. 

Entón, imos dar un ollo o que parece. Obtivo un back-end núcleo, moi sinxelo. Temos un sistema aquí con múltiples zonas de dispoñibilidade. Nós falamos sobre como AZS being-- pensar deles como centros de datos separados. Máis dun centro de datos por AZ, pero iso é OK, basta pensar-los como datos separado centros que están xeograficamente e falla illada. 

Nós imos ter un instancias EC2 parella. Nós imos ter un servidor back-end. Quizais se é un legado arquitectura, estamos usando o que chamamos RDS, servizos de base de datos relacional. Podería ser MSSQL, MySQL, ou algo así. Esta é a forma como un aplicacións de lote están deseñados hoxe. 

Ben, nós pode querer ir con é dicir, cando escalar. Imos ir adiante e poñer o balde S3 alí enriba. E iso balde S3, en vez de servir se eses obxectos do noso servers-- poderíamos facelo. Poñer todo o seu par obxectos nos seus servidores e pode usar os servidor instancias de servirse de que os datos. Pero iso é moi caro. 

Mellor forma de facer é ir adiante e poñer os obxectos nun balde S3. S3 é un repositorios de obxectos. A súa construcción especialmente para servindo-se estes tipos de cousas. E deixe que os clientes solicitan directamente destes baldes de obxectos, descargar os servidores. Entón, nós estamos empezando a escalar aquí. 

Agora temos usuarios en todo o mundo. Teño usuarios. Eu preciso ter contido localmente situado preto de eses usuarios, non? Eu creei un balde S3 como o meu depósito de orixe. E eu vou diante que, con a distribución CloudFront. 

CloudFront é un CD e un rede de distribución de contidos. Basicamente hai que de datos que se especifica e almacena na caché-lo por toda a internet así os usuarios en todas partes poden ter unha resposta moi rápida cando eles solicitan estes obxectos. 

Entón, ter unha idea. Está medio que aproveitando toda a aspectos da AWS aquí para obter este feito. E, finalmente, xogamos nun grupo de auto escala. Así, os nosos casos AC2 dos nosos servidores de xogo, como comezan a estar máis axitado e cada vez máis ocupados, eles só vai xirar outra exemplo, xirar outra instancia, xirar outra instancia. Así, a tecnoloxía AWS ten, el permite que especifique os parámetros en torno ao cal os seus servidores vai medrar. Entón vostede pode ter n número de servidores aí, nun momento dado. E se a súa carga vai, eles van encoller, o número pode diminuír. E se a carga de volta, vai crecer de volta para fóra, elasticamente. 

Entón, iso parece gran. Temos unha morea de instancias de EC2. Podemos poñer caché diante dos bancos de datos, tentar acelerar os bancos de datos. O seguinte punto de presión normalmente a xente ven é que escalar un xogo usando un sistema de base de datos relacional. Eita, a base de datos desempeño é terrible. Como podemos mellorar isto? Imos tentar poñer cache diante daquel. 

Ben, a caché non funciona tan grande nos xogos, non? Para os xogos, a escrita é doloroso. Os xogos son moi pesados ​​escribir. Cache non funciona cando está escribir pesado, porque sempre ten que actualizar a caché. Actualizar a caché, é irrelevantes para ser caché. En realidade, é só un traballo extra. 

Entón, a onde imos de aquí? Ten un gran pescozo alí en baixo na base de datos. E o lugar para ir obviamente, é o particionamento. Particionamento non é fácil de facer cando se está xestionar bases de datos relacionais. Con bases de datos relacionais, é responsable da xestión, de forma eficaz, o espazo clave. Está dicindo usuarios entre A e M aquí, entre N e Z ir máis alá. E está conmutación en toda a aplicación. Entón, está lidando con esta fonte de datos partición. Ten restricións transnacionais que non ocupan particións. Ten todo tipo de messiness que é xestionar alí intentando para xestionar dimensionando e construción dunha infraestrutura maior. É só non é divertido. 

Audiencia: Entón está dicindo que o aumento dos puntos de orixe acelera o proceso? Rick Houlihan: Aumentando? Puntos Orixe: platéia. Rick Houlihan: puntos Orixe? Audiencia: A partir da información, onde a información está a benvida? Rick Houlihan: Non. O que estou dicindo é o aumento da número de particións no almacenamento de datos mellora a taxa de transferencia. Entón, o que está a suceder aquí é usuarios entrando na instancia EC2 aquí enriba, ben, se eu ter un usuario iso é A M, eu vou aquí. De N a p, eu vou aquí. De I a Z, eu vou aquí. 

Audiencia: OK, entón esas son aqueles todos almacenados en diferentes nós? 

Rick Houlihan: Si. Pense nisso como diferentes silos de datos. Entón, está a ter que facelo. Se estás a facer tanto, se está tentando a escala nunha plataforma relacional, isto é o que está facendo. Está levando de datos e está cortando-o para abaixo. E está dividíndoo en toda a varias instancias da base de datos. E está administrando o único que na capa de aplicación. Non é divertido. Entón, o que queremos ir? Queremos ir DynamoDB, totalmente xestionado, Almacenamento de datos NoSQL, prestación de transferencia. Usamos índices secundarios. É basicamente HTTP API e inclúe soporte documento. Entón non se preocupe sobre calquera que o particionamento. Facemos todo para ti. Entón, agora, en vez diso, vostede simplemente escriba para a mesa. Se a táboa debe ser particionado, que pasa nos bastidores. Está completamente illado que como un creador. Entón imos falar sobre algúns dos casos de uso que nos atopamos no xogo, común escenarios de xogos, táboa de clasificación. Entón tes os usuarios entrando, os BoardNames que son en, a puntuación para este usuario. Podemos estar hash na userid, e entón temos variedade no xogo. Así, cada usuario quere ver todo o partido que xogou e toda a súa puntuación máxima en todos o partido. Entón, ese é a súa valoración persoal. 

Agora quero ir e quero get-- polo que fico con eses leaderboards persoais. O que quero facer é ir buscar a puntuación máxima para todos os usuarios. Entón, como podo facer iso? Cando o meu record é hash en o userid, varios no xogo, ben, eu estou indo a ir adiante e reestruturar, crear un GSI, e eu estou indo a reestruturar estes datos. 

Agora vou para hash no BoardName, que é o xogo. E eu estou indo a variar na puntuación máxima. E agora eu creei diferentes baldes. Eu estou usando a mesma táboa, os mesmos datos do elemento. Pero eu estou creando un balde que dá me unha agregación de puntuación máxima por xogo. 

E podo consultar esta táboa para obter a información. Entón eu definir ese patrón de consulta ata ser soportada por un índice secundario. Agora, poden ser clasificados por BoardName e clasificados por topscore dependendo. Para que poida ver, estes son tipos de casos de uso que comeza no xogo. Outro caso bo uso chegamos en xogos é premios e quen gañou os premios. E este é un gran caso de uso onde chamamos índices esparsos. Índices esparsos son o capacidade de xerar un índice que non fai necesariamente conter todo único elemento sobre a mesa. E por que non? Como o atributo que está a ser non indexado non existir en cada elemento. 

Polo tanto, neste particular, usar caso, eu estou dicindo, vostede sabe o que, eu vou crear un atributo chamado Award. E eu vou dar a todo usuario que ten un premio que atribúen. Usuarios que non teñen premios son non vai ter ese atributo. Entón, cando crear o índice, os únicos usuarios que van amosar no índice son os que realmente gañaron premios. Entón esta é unha boa forma de poder para crear índices filtrados que son moi, moi selectiva que non facer ten que indexar a táboa enteira. 

Entón, nós estamos quedando con pouco tempo aquí. Eu estou indo a ir adiante e saltar fóra e ignorar este escenario. Contacte algo about-- 

Audiencia: Podo facer unha pregunta rápida? Un deles é escribir pesado? Rick Houlihan: Qué é? Audiencia: Escribir pesado. Rick Houlihan: Escribir pesado. Déixame ver. 

Audiencia: Ou que non é algo que pode só voz para en cuestión de segundos? Rick Houlihan: Imos a través do escenario de votación. Non é tan malo así. Tendes uns minutos? Aceptar. 

Entón, imos falar sobre a votación. Así, a votación en tempo real, temos requisitos para votar. Os requisitos son que permitimos cada persoa para votar unha vez. Queremos que ninguén sexa capaz para cambiar o seu voto. Queremos agregación en tempo real e análise de datos demográficos que imos ser mostrando aos usuarios do sitio web. 

Pense neste escenario. Traballamos moito da realidade TV mostra onde están facendo estes tipo exacto de cousas. Entón pode pensar no escenario, temos millóns e millóns nenas de adolescentes alí cos seus teléfonos móbiles e votación, e votación, e votar en quen son atopar para ser o máis popular. Entón, estas son algunhas das requisitos corremos para fóra. 

E así o primeiro tomar na resolución deste problema sería construír un aplicación moi sinxelo. Entón eu teño ese app. Eu teño algúns votantes por aí. Chegan, eles bateron a aplicación de votación. Eu teño un pouco de votos táboa raw Eu só vou botan estes votos en. Vou ter algún engadido votos táboa que farei o meu Analytics e demografía, e imos poñer todo iso dentro. 

E iso é gran. A vida é boa. A vida é boa ata descubrirmos que sempre hai só un ou dous persoas que son populares nunha elección. Hai só unha ou dúas cousas que a xente realmente se preocupan. E se está votando en escala, de súpeto eu son será martelé o inferno fóra de dous candidatos, un ou dous candidatos. Un número moi limitado de elementos persoas cren que ser popular. 

Este non é un bo nivel de deseño. Esta é realmente unha patrón de deseño moi malo porque crea o que nós falou sobre o que era teclas de atallo. Teclas de atallo son algo que non gusta. 

Entón, como imos fixar iso? E realmente, o xeito de solucionar isto é tomando os baldes candidatos e para cada candidato que temos, imos engadir un valor aleatorio, algo que sabemos, aleatorio un valor entre 100 e, entre 100 e 1000, ou entre un e 1000, porén moitos valores aleatorios que quere achegar ao final dese candidato. 

E o que realmente fixo, entón? Se está a usar o ID como candidato o balde para agregar votos, se eu engade un aleatorio número para o fin de que, Eu creei agora 10 baldes, un centos de baldes, mil baldes que estou agregando votos de diámetro. 

Entón, eu teño millóns e millóns, e millóns de rexistros benvida Para estes candidatos, agora estou estendendo os votos en todo A_1 Candidate través A_100 Candidato porque cada vez que un voto vén, Estou xerando unha chou valor entre un e 100. Estou adherencia que no extremo do candidato que persoa votar. Estou xogando o en que balde. 

Agora na parte de atrás, sei que eu teño máis de cen baldes. Entón, cando eu queira ir adiante e agregar os votos, Lin desde todos estes baldes. Entón eu ir adiante e engadir. E entón eu a dispersión reunir onde eu saír e dicir hey, Vostede sabe o que a chave do candidato espazos é máis de cen baldes. Vou reunir toda a votos dos cen baldes. Eu estou indo a agregar Los e eu vou dicir, Un candidato ten agora conta total de votos de x. 

Agora, tanto write consulta e consulta de lectura son ben distribuídos porque eu estou escribindo fronte e eu estou lendo en centos de claves. Non estou escribindo e lectura a través dunha clave agora. Entón, iso é un gran modelo. 

Este pode ser un realmente do proxecto o máis importante patróns para a escala en NoSQL. Vai ver este tipo de patrón de deseño en cada sabor. MongoDB, DynamoDB, iso non acontece importa, todos temos que facer. Porque cando está lidando con aqueles enormes agregacións, ten que descubrir un xeito de espallalas-los para fóra a través de baldes. Polo tanto, esta é a forma de facelo. Todo ben, entón o que está facendo agora é que está cambiando de lectura custo de gravación escalabilidade. O custo da miña lectura é un pouco máis complexo e eu teño que ir ler a partir dun centos de baldes no canto dun. Pero eu son capaz de escribir. E o meu rendemento, a miña escrita throughput é incrible. Polo tanto, é xeralmente un valioso técnica para escalar DynamoDB, ou calquera base de datos NoSQL para este asunto. Entón, descubrimos como escala-lo. E figuramos como eliminar nosas teclas de atallo. E iso é fantástico. E nós temos este sistema agradable. E iso nos deu moi correcto votación porque temos rexistro voto de-dupe. A súa construcción en DynamoDB. Falamos dereitos condicionais. 

Cando un elector entra, puts unha inserción na táboa, eles introducir coa súa identificación do elector, se tentaren inserir outra votación, Fago unha gravación condicional. Digan só escribir este se este non existe. Así, logo que eu vexo que que a votación de bater na mesa, ninguén máis vai ser capaz de poñer o seu voto no. E iso é fantástico. E nós estamos incrementando nosos contadores de candidatos. E nós estamos facendo noso demografía e todo iso. Pero o que acontece se o meu aplicación cae? Agora, de súpeto votos están chegando, e eu Non sei se eles están sendo procesados nas miñas análises e demografía anymore. E cando a aplicación volta para arriba, como diaños eu sei que teño de votos foi procesado e por onde comezo? 

Polo tanto, este é un problema real cando comezar a ollar para este tipo de escenario. E como é que imos solucionar isto? Nós resolver-lo co que nós chamar DynamoDB Fluxos. Fluxos é un tempo de solicitudes e rexistro de cambios particionado de cada acceso á mesa, cada gravación acceso á táboa. Os datos que está escrito á táboa móstrase no fluxo. 

É basicamente unha fila de 24 horas. Elementos bater o córrego, viven por 24 horas. Poden ser lidas múltiples veces. Garantir a entrega só unha vez ao fluxo, se pode ler n número de veces. Entón porén moitos procesos quere consumir estes datos, pode consumo-lo. Aparecerá cada actualización. Cada gravación será só aparecer xa no fluxo. Entón non se preocupe sobre o procesamento de dúas veces desde o mesmo proceso. 

É estrictamente ordenada por elemento. Cando dicimos tempo ordenada e particionado, vai ver por partición no fluxo. Vai ver os elementos, actualizacións en orde. Non estamos garantindo sobre o fluxo que é indo para obter todas as transaccións na orde en todo elementos. 

Entón regatos son idempotente. Será que todos sabemos o que significa idempotente? Idempotente significa que pode facelo máis, e máis, e outra vez. O resultado será o mesmo. 

Fluxos son idempotente, pero eles teñen que ser reproducidos desde o punto de partida, onde queira que escoller, ata o final, ou eles non van producir nos mesmos valores. 

O mesmo con MongoDB. MongoDB ten unha construción chaman a oplog. É a mesma construción exacta. Moitos bancos de datos NoSQL ten esta construción. Eles usalo para facer cousas como replicación, que é o que facemos cos regatos. Audiencia: Talvez un pregunta herética, pero falar aplicacións facendo derrubou un así por diante. Son fluxos garantir a Nunca posiblemente ir para abaixo? Rick Houlihan: Si, regatos son garantir para nunca máis ir para abaixo. Nós administramos a infraestrutura para atrás. regatos automaticamente implantar no seu grupo Auto Scaling. Nós imos pasar por algo pouco sobre o que pasa. 

Non debería dicir que non son garantir que nunca ir para abaixo. Os elementos son garantir para aparecer no córrego. E o fluxo será accesible. Entón, o que vai para abaixo ou volta up, que pasa por baixo. El covers-- é OK. Todo ben, entón comeza diferente tipo de vista fóra da pantalla. Tipo de vista que son importantes para a programador normalmente, o que era? Recibe a antiga visión. Cando unha actualización atinxe a mesa, que vai empurrar o vello vistas ao fluxo que os datos poidan arquivar ou cambio control, identificación cambio, cambio xestión. 

A nova imaxe, o que é agora, despois de a actualización, que é outro tipo de visión pode comezar. Pode obter tanto as imaxes antigas e novas. Poida que eu quero os dous. Quero ver o que era. Quero ver o que cambiou para. 

Eu teño un tipo de conformidade do proceso que corre. Necesita comprobar que cando estas cousas cambian, que están dentro de certos límites ou dentro de certos parámetros. 

E entón quizais eu só Debe saber o que cambiou. Eu non me importa o que elemento foi modificado. Non ten que saber que atributos modificado. Eu só teño que saber que os elementos están sendo tocadas. Entón eses son os tipos de puntos de vista que saír do córrego e pode interactuar con. 

A aplicación que consome a corrente, este é o tipo de forma como funciona. DynamoDB cliente solicitar a enviar datos para as táboas. Fluxos implantar no que chamamos anacos. Shards son escalados independentemente da mesa. Non se aliñan completamente para as particións da súa mesa. E a razón pola que é porque se aliñan coa capacidade, a actual capacidade da táboa. 

Eles implantar na súa propio grupo escalonamento auto, e comezan a xirar a fóra, dependendo de cantas gravacións están chegando, cantos reads-- realmente é escribe. Non hai ningunha reads-- pero como moitas gravacións están chegando. 

E, a continuación, na parte de atrás fin, temos o que chamar un KCl, ou Biblioteca de kinesis Cliente. Kinesis é un fluxo de datos tecnoloxía de procesamento da Amazonia. E regatos está construído sobre iso. 

Entón usa un KCl habilitado aplicación para ler o fluxo. A Biblioteca kinesis cliente, en realidade, xestiona os traballadores para ti. E tamén fai algúns cousas interesantes. Vai crear algunhas táboas up na súa táboa DynamoDB para controlar cales elementos ser procesada. Entón, desta maneira, se cae cara atrás, se cae e vén e queda estaba de volta, pode determinar onde foi no procesamento da cadea. 

Isto é moi importante cando está falando de replicación. Eu teño que saber o que datos foi foi procesada e os datos que aínda ten que ser procesada. Así, a biblioteca de KCl para fluxos vai darlle unha morea de que a función. Ela coida de todas as tarefas domésticas. El levanta-se un traballador para cada fragmento. Ela crea unha táboa administrativa para cada fragmento, para cada traballador. E como os traballadores lume, eles manteñen esas táboas así vostede sabe este rexistro foi lido e procesado. E, a continuación, desa forma, se o proceso morre e volver a estar en liña, pode retomar exactamente onde despegou. 

Entón, usamos isto para replicación cross-rexión. Moitos clientes teñen a necesidade de mover datos ou partes das súas táboas de datos en torno a diferentes rexións. Existen nove rexións arredor do mundo. Polo tanto, pode haber un eu need-- pode ter usuarios en Asia, os usuarios na Costa Leste dos Estados Unidos. Teñen que datos diferentes ten que ser distribuído localmente. E quizais un usuario voa de Asia para os Estados Unidos, e quero replicar seus datos con el. Entón, cando sae do avión, ten unha boa experiencia usando o seu programa móbil. 

Podes usar o cross-rexión biblioteca de replicación para facelo. Basicamente, temos proporcionada dúas tecnoloxías. Un é unha aplicación de consola que poida plantexa-se sobre o seu propio instancia EC2. É executado a replicación puro. E, a continuación, deulle a biblioteca. A biblioteca pode ser usada para construír súa propia aplicación se quero facer cousas malucas que data-- filtro, replicar só unha parte dela, executar os datos, mover para un táboa diferente, así por diante e así por diante. Entón, ese é o tipo de o que parece. 

DynamoDB Fluxos poden ser procesadas polo que chamamos Lambda. Mencionados un pouco sobre o evento arquitecturas de aplicacións accionados. Lambda é un compoñente fundamental do que iso. Lambda é o código que dispara da demanda en resposta a un acontecemento particular. Un deses eventos pode ser un rexistro que aparece no stream. Un rexistro aparece no córrego, imos chamar esa función Java. Ben, este é JavaScript, e Lambda soporta Node.js, Java, Python, e pronto apoiar outras linguas tamén. E Nin que dicir, é puro código. escribir en Java, que define unha clase. Aperta o JAR-se en Lambda. E entón se especifica cal clase a chamada en resposta ao que o evento. E, a continuación, a infraestrutura do Lambda detrás que executará ese código. 

Este código pode procesar rexistros fóra do córrego. Pode facer o que quere con el. Neste exemplo en particular, todos somos facendo realmente está rexistrando os atributos. Pero este é só código. Código pode facer calquera cousa, non? 

Entón, pode executar estes datos. Pode crear unha visión derivada. Se é unha estrutura do documento, pode esmagar a estrutura. Pode crear índices alternativos. Todo tipo de cousas que podes facer cos regatos DynamoDB. 

E realmente, iso é o que parece. Entón obter esas actualizacións chegando. Están saíndo da cadea. Son lidos pola función Lambda. Eles están xirando os datos e empurrando-se en táboas de derivados, notificando sistemas externos de cambio, e enviar datos en ElastiCache. 

Nós falamos sobre como poñer a caché diante da base de datos para que as vendas escenario. Ben, o que acontece se actualizar a descrición do elemento? Ben, se eu tivese un Lambda función de execución en que a táboa, se eu actualizar a descrición do elemento, que vai incorporarse o rexistro fóra do córrego, e que vai actualizar o ElastiCache exemplo, cos novos datos. Entón, iso é unha chea de o que facemos con Lambda. É código de cola, conectores. E realmente dá a capacidade de lanzar e para executar aplicacións moi complexos sen un servidor dedicado infraestrutura, o que é moi legal. 

Entón, imos voltar ao noso en tempo real arquitectura votación. Esta é unha nova e mellorada co noso regatos e KCl habilitado aplicación. Mesmo que antes, podemos xestionar calquera escala de elección. Gústanos diso. Estamos facendo a obtención de dispersión en varios baldes. Temos de bloqueo optimista suceder. Podemos manter os nosos electores de cambiar os seus votos. Eles só poden votar só unha vez. Isto é fantástico. Tolerancia a fallos en tempo real, agregación scalable agora. Se a cousa cae, el sabe onde reiniciar-se cando se trata backup porque estamos usando a aplicación KCl. E entón nós tamén podemos usar isto Aplicación KCl para enviar datos para fóra para redshift a outro Analíticas App ou uso os MapReduce elástico para realizar en tempo real agregacións de streaming fóra de que os datos. 

Entón, estas son cousas que non falamos moito. Pero son adicional tecnoloxías que veñen de soportar cando está olhando neste tipo de escenarios. 

Todo ben, entón iso é sobre Analytics con DynamoDB Fluxos. Pode recoller de-dupe datos, facer todo tipo de cousas legais, datos agregados en memoria, crear esas táboas de derivados. Isto é un caso de uso enorme que unha morea de clientes toma parte con, tomando a nested propiedades destes documentos JSON e creación de índices adicionais. 

Estamos no fin. Grazas por soportar comigo. Entón imos falar sobre arquitectura de referencia. DynamoDB queda no medio dos así gran parte da infraestrutura da AWS. Basicamente, pode conectar para ata o momento. As aplicacións creados usando Dynamo inclúen Lambda, ElastiCache, CloudSearch, empurrar os datos para fóra en Elastic MapReduce, importación e exportación de DynamoDB en S3, todo tipo de fluxos de traballo. Pero, probablemente, a mellor cousa para falar, e iso é o que é realmente interesante é cando nós falar aplicacións orientados a eventos. 

Este é un exemplo de un proxecto interno que temos onde estamos, en realidade, publicación de reunir os resultados da investigación. Así, nun enlace de correo-e que nós enviamos a fóra, alí vai ser un pequeno estalo conexión dicindo aquí para responder á investigación. E cando unha persoa fai clic ese enlace, o que pasa é que tirar abaixo un seguro Formulario de exame de código HTML S3. Non hai ningún servidor. Este é só un obxecto S3. 

Esa forma xorde, leva-se no navegador. Ten Backbone. Ten complexo JavaScript que está correndo. Polo que é aplicación moi rico en execución no navegador do cliente. Eles non saben que eles non son interactuar cun servidor back-end. Neste punto, é todo navegador. 

Publican os resultados ao chamamos a Amazon API Pasarela. API Pasarela é simplemente unha API web que pode definir e conectar para o que quere. Neste caso particular, estamos conectado a unha función Lambda. 

Así, a miña operación POST é pasando con ningún servidor. Basicamente pasarela de API que se senta alí. Me custa nada ata que a xente comece a publicar a el, non? A función Lambda só se senta alí. E iso me custa nada ata as persoas comezan a bater. Así pode ver, como o volume aumentos, que é cando as acusacións vir. Non estou executando un servidor 7/24. 

Entón eu puxo a forma abaixo para fóra do balde, e eu publicar a través da API Porta de entrada para a función Lambda. E, a continuación, o Lambda función di, sabe o que, eu teño algunhas PIIs, algúns información persoalmente identificable nestas respostas. Teño comentarios vindos de usuarios. Teño enderezos de correo electrónico. Teño nomes de usuarios. 

Déixeme dividir este fóra. Eu estou indo a xerar algún metadatos off este rexistro. E eu estou indo a empurrar o metadatos en DynamoDB. E eu podería cifrar os datos e empurralo para DynamoDB se eu queira. Pero é máis fácil para min, neste caso de uso, para ir adiante unha palabra que dicir, Eu estou indo a empurrar os datos en bruto nun balde S3 cifrada. Entón eu usar construído no lado do servidor S3 cifrado e manexo de claves de Amazon Servizo para que eu teña unha clave que pode executar nun intervalo regular, e podo protexer eses datos PII como parte de todo este fluxo de traballo. 

Entón o que foi que eu fixen? Acaba implantado un todo aplicación, e eu non teño servidor. Entón é o que aplicación dirixida evento arquitectura fai para ti. 

Agora, se pensar sobre o caso de uso para isto-- temos outros clientes que eu estou falando a arquitectura exacta do que executar fenomenalmente grandes campañas, que Está mirando para iso e vai, oh meu. Porque agora, poden basicamente empurralo para fóra alí, deixe que a campaña só sentir alí ata que lanza, e non ten que preocuparse un figo sobre que tipo de infraestrutura vai estar alí para apoia-lo. E, a continuación, unha vez que a campaña está feita, é como a infraestrutura só vai inmediatamente porque non hai realmente hai infraestrutura. É código só que se sente en Lambda. É só datos que queda no DynamoDB. É unha forma incrible para construír aplicacións. 

Audiencia: Entón é máis efémero do que sería se foi almacenado nun servidor real? 

Rick Houlihan: Absolutamente. Porque esa instancia de servidor tería que ser un 7/24. Ten que estar dispoñible para alguén para responder. Ben, difícil de adiviñar? S3 é dispoñible 7/24. S3 responde sempre. E S3 é moi, moi bo a servir-se obxectos. Estes obxectos poden ser arquivos HTML, ou Arquivos JavaScript, ou o que sexa. Pode executar aplicacións web moi ricas fóra de baldes S3, e as persoas fan. 

E entón esa é a idea aquí é para estar lonxe do camiño estamos afeitos a pensar sobre iso. Todos adoitaba pensar termos de servidores e anfitrións. Non é sobre isto máis. Trátase de infraestrutura como código. Implantar o código á nube e deixe a nube executa-lo para ti. E iso é o que a AWS está intentando facer. 

Audiencia: caixa de ouro no medio Entón, do API Pasarela non é servidor-like, pero en vez diso é apenas-- 

Rick Houlihan: Pode pensar niso como fachada servidor. Todo o que é que vai levar un HTTP solicitar e mapea-la para outro proceso. Isto é todo o que fai. E neste caso, estamos estean situados Lo para unha función lambda. Todo ben, entón iso é todo o que eu teño. Moitas grazas. Aprécioo. Sei que queremos un pouco ao longo do tempo. E espero que vós ten un pouco de información que pode aproveitar hoxe. E pido desculpas se eu fun sobre algunhas das súas cabezas, pero hai unha morea de bo coñecemento fundamental fundamentais que eu creo que é moi valioso para ti. Entón, grazas por me recibir. [Aplausos] Audiencia: [inaudível] é cando estaba dicindo tiña que ir a través da cousa dende o principio ao final para obter os valores correctos ou os mesmos valores, como é que os valores cambiar [inaudível]. 

Rick Houlihan: Oh, idempotentes? Como os valores cambian? Ben, porque se eu non correr todo o camiño ata o final, entón eu non sei o que cambia foron feitas na última milla. Non vai ser a mesmos datos que o que vin. Audiencia: Ah, entón só non chegar a entrada enteira. Rick Houlihan: Correcto. Ten que ir do comezo ao fin, e entón é vai ser un estado consistente. Legal. 

Audiencia: Entón mostrounos DynamoDB pode facer documento ou o valor da clave. E nós pasamos moito tempo no valor clave cun hash e as formas para lanzalo ao redor. Cando mirou para estas táboas, é que deixando atrás o enfoque documento? 

Rick Houlihan: eu non faría dicir deixalo atrás. 

Audiencia: Eles foron separados de as-- 

Rick Houlihan: Co documento visión, o tipo de documento en DynamoDB é só pensar en como outro atributo. É un atributo que contén unha estrutura de datos xerárquica. E, a continuación, nas consultas, pode utilizar as propiedades destes obxectos usando Object Notation. Para que eu poida filtrar nun nested propiedade do documento JSON. Audiencia: Entón calquera momento I facer un achegamento documento, Podo clasificar de chegar ao tabular-- Audiencia: Absolutamente. Audiencia: --indexes e cousas que falou. Rick Houlihan: Si, o índices e todo o que, cando quere indexar o propiedades do JSON, a forma que nós teriamos de facelo é se inserir un obxecto JSON ou un documento en Dynamo, usaría correntes. Fluxos ía ler a entrada. Quere obter que JSON obxecto e diría OK, o que é a propiedade que quero para o índice? 

Crea unha táboa derivada. Agora que é a forma como funciona agora. Non permitimos que índice directamente estas propiedades. 

Audiencia: Tabularizing seus documentos. 

Rick Houlihan: Exactamente, achatando el, tabularizing iso, exactamente. Isto é o que fai con el. 

Audiencia: Grazas. 

Rick Houlihan: Si, absolutamente, grazas. Audiencia: Entón é tipo de Mongo atende classifers Redis. 

Rick Houlihan: Si, é moi parecido. Esta é unha boa descrición para el. Legal.