>> [Música tocando]
RICK HOULIHAN: Tudo bem.
Oi pessoal.
Meu nome é Rick Houlihan.
Eu sou um diretor sênior arquiteto de soluções da AWS.
Concentro-me em NoSQL e Tecnologias DynamoDB.
Estou aqui hoje para falar com você um pouco sobre aqueles.
>> Minha formação é principalmente na camada de dados.
Passei metade da minha desenvolvimento escrita da carreira de banco de dados,
acesso a dados, soluções para várias aplicações.
Eu estive em virtualização em nuvem por cerca de 20 anos.
Então, antes que a nuvem se a nuvem, costumávamos chamá-lo de utility computing.
E a ideia foi, é como PG & E, você paga pelo que usa.
Hoje nós o chamamos de nuvem.
>> Mas ao longo dos anos, eu tenho trabalhado para um par de empresas
você provavelmente nunca ouviu falar.
Mas eu compilei uma lista de técnico realizações, eu acho que você diria.
Eu tenho oito patentes em sistemas em nuvem virtualização, design de microprocessadores,
processamento de eventos complexos, e outras áreas.
>> Então, esses dias, vou me concentrar principalmente sobre NoSQL tecnologias e da próxima geração
banco de dados.
E isso é geralmente o que eu vou estar aqui falando com você hoje sobre.
Então, o que você pode esperar a partir desta sessão,
nós vamos passar por um breve história de processamento de dados.
É sempre útil compreender de onde viemos
e por isso que estamos onde estamos.
E vamos falar um pouco pouco sobre tecnologia NoSQL
a partir de um ponto de vista fundamental.
>> Nós vamos entrar em algumas das os internos DynamoDB.
DynamoDB é da AWS não sabor.
É um totalmente gerenciado e solução NoSQL hospedado.
E nós vamos falar um pouco sobre a tabela estrutura, APIs, tipos de dados, índices,
e algumas das partes internas de que a tecnologia DynamoDB.
Nós vamos entrar em algum do design padrões e melhores práticas.
Nós vamos falar sobre como você utilizar esta tecnologia para alguns
as aplicações de hoje.
E então nós vamos falar um pouco sobre a evolução ou a emergência
de um novo paradigma na programação chamados aplicativos orientados a eventos
e como DynamoDB desempenha em que, como bem.
E nós vamos deixar você um pouco de uma arquitetura de referência discussão
assim que nós podemos falar sobre algumas das as maneiras que você pode usar DynamoDB.
>> Então, primeiro off-- esta é uma questão Eu ouço muito é, o que é um banco de dados.
Muita gente acha que eles sabe o que é um banco de dados.
Se você Google, você vai ver isso.
É uma de um conjunto estruturado de dados realizada em um computador, especialmente um que
é acessível de várias maneiras.
Acho que é uma boa definição de um banco de dados moderno.
Mas eu não gosto, porque ela implica um par de coisas.
Implica estrutura.
E isso implica que é em um computador.
E bases de dados não sempre existir em computadores.
Bases de dados, na verdade existia em muitas maneiras.
>> Assim, uma melhor definição de um banco de dados é algo como isto.
Um banco de dados é uma organizada mecanismo para armazenamento, gerenciamento,
e recuperação de informações.
Isto é de About.com.
Então, eu gosto disso porque ele realmente fala sobre uma base de dados de ser um repositório,
um repositório de informações, não necessariamente
algo que se sente em um computador.
E ao longo da história, nós nem sempre tiveram computadores.
>> Agora, se eu perguntar a média desenvolvedor de hoje o que é
um banco de dados, essa é a resposta que recebo.
Em algum lugar que eu possa manter o material.
Certo?
E é verdade.
Mas é lamentável.
Porque o banco de dados é realmente a fundação do app moderno.
É a fundação de cada aplicação.
E como você construir esse banco de dados, como você estrutura
que dados vai ditar como que aplicação executa como você escala.
>> Assim, muito do meu trabalho hoje é lidar com o que
acontece quando os desenvolvedores adotar essa abordagem
e lidando com as conseqüências de um aplicativo que
agora está ampliando para além do original intenção e sofrimento de mau design.
Portanto, esperamos que quando você ir embora hoje, você vai
tem um par de ferramentas em seu cinto que vai mantê-lo
de fazer os mesmos erros.
Tudo certo.
Então vamos falar sobre um pouco de a linha do tempo da tecnologia de banco de dados.
Acho que eu li um artigo não muito tempo atrás
e ele disse algo sobre o lines-- é uma afirmação muito poético.
Ele disse que a história de processamento de dados é
cheio de altos marcas d'água abundância de dados.
ESTÁ BEM.
Agora, eu acho que é o tipo de verdade.
Mas eu realmente olhar é como a história é realmente cheio
com marca de água de alta pressão de dados.
Uma vez que a taxa de dados Ingestão Nunca vai para baixo.
Ele só vai para cima.
>> E a inovação ocorre quando vemos pressão de dados, que
representa a quantidade de dados que é Agora, no que entra no sistema.
E não pode ser processado eficientemente, quer no tempo ou em custo.
E foi aí que começamos a olhar para a pressão de dados.
>> Assim, quando olhamos para o primeira base de dados, esta
é a única que estava entre os nossos ouvidos.
Todos nós nascemos com ele.
É um banco de dados bom.
Ele tem uma alta disponibilidade.
É sempre ligado.
Você sempre pode obtê-lo.
>> Mas é único usuário.
Eu não posso compartilhar meus pensamentos com você.
Você não pode obter os meus pensamentos quando você quer que eles.
E a sua abilitiy não é tão bom.
Esquecemo-nos de coisas.
De vez em quando, um de nós folhas e se move para outra existência
e perdemos tudo que estava no banco de dados.
Então isso não é tudo o que é bom.
>> E isso funcionou bem ao longo do tempo quando estávamos de volta ao dia
quando tudo o que realmente precisava saber é onde estamos indo para ir amanhã
ou onde nos reunimos a melhor comida.
Mas quando começamos a crescer como civilização e governo começou
para vir a ser, e as empresas começaram a evoluir,
nós começamos a perceber que precisamos de um pouco mais do que o
poderíamos colocar na nossa cabeça.
Tudo certo?
>> Precisávamos de sistemas de registro.
Precisávamos de lugares para ser armazenar dados capazes.
Então começamos a escrever documentos, a criação de bibliotecas e arquivos.
Começamos a desenvolver um sistema de contabilidade Ledger.
E que o sistema de contagem de contabilidade correu o mundo por muitos séculos,
e talvez até mesmo milênios, como nós meio que cresceu a tal ponto
onde essa carga de dados superou a capacidade desses sistemas
para ser capaz de conter.
>> E isso realmente aconteceu na década de 1880.
Certo?
No Censo de 1880 dos EUA.
Isto é realmente onde a viragem apontar processamento de dados moderno.
Este é o ponto em que a quantidade de dados
que estava sendo recolhidas pela Governo dos Estados Unidos chegou a um ponto
onde ele levou oito anos para ser processado.
>> Agora, oito anos-- como você sabe, o censo
sai a cada 10 anos-- por isso é bastante óbvio que pelo tempo que
obteve o censo de 1890, a quantidade de dados que
ia ser processado pelo governo foi
vai exceder os 10 anos que seria necessário para lançar o novo censo.
Este foi um problema.
>> Então, um cara chamado Herman Hollerith veio junto
e ele inventou registro soco unidade cartões, leitor de cartões perfurados, cartões perfurados
tabulator, eo agrupamento de os mecanismos para essa tecnologia.
E que a empresa que ele formou no tempo, juntamente com um par de outros,
na verdade, tornou-se um dos pilares de uma pequena empresa que conhecemos hoje chamada IBM.
>> Então IBM originalmente estava em base de dados da empresa.
E isso é realmente o que eles fizeram.
Eles fizeram processamento de dados.
>> Como assim a proliferação de perfurador cartões, um engenhoso mecanismos
de ser capaz de alavancar esse tecnologia para votação conjuntos de resultados classificados.
Você pode ver nesta foto aí temos um little--
é um pouco small-- mas você pode ver um mecanismo mecânico muito engenhoso
onde temos uma plataforma de cartões perfurados.
E tomada de alguém um pouco de chave de fenda
e furando através do slots e levantando-
para obter esse jogo, que resultados classificados definido.
>> Esta é uma agregação.
Fazemos isso o tempo todo hoje no computador,
onde você fazê-lo no banco de dados.
Nós costumávamos fazê-lo manualmente, certo?
Pessoas colocar essas coisas em conjunto.
E foi a proliferação destes cartões perfurados
para o que chamamos de tambores de dados e bobinas de dados, fita de papel.
>> A indústria de processamento de dados levou uma lição com os pianos de jogador.
Jogador pianos de volta ao a virada do século
costumava usar bobinas de papel com slots para dizer-lhe que as chaves para jogar.
Assim que a tecnologia foi adaptada eventualmente, para armazenar dados digitais,
porque eles poderiam colocar esses dados para aqueles rolos de fita de papel.
>> Agora, como um resultado, os dados foi actually-- como
você acessar esses dados foi diretamente dependente da forma como ele está armazenado.
Então, se eu colocar os dados em uma fita, Eu tive acessar os dados de forma linear.
Eu tive que rolar a todo fita para acessar todos os dados.
Se eu colocar os dados no soco cartões, eu poderia acessá-lo
em um pouco mais aleatória forma, talvez não tão rapidamente.
>> Mas havia limitações em como nós acesso a dados com base em como foi armazenado.
E por isso foi um problema vai para os anos 50.
Mais uma vez, podemos começar a ver que, como nós desenvolver novas tecnologias para processar
os dados, certo, ela abre a porta para novas soluções,
para novos programas, novo aplicações para esses dados.
E realmente, governança pode ter sido a razão
por isso que desenvolvemos alguns desses sistemas.
Mas o negócio tornou-se rapidamente o motorista por trás da evolução
da base de dados moderno e o sistema de arquivos moderno.
>> Portanto, a próxima coisa que surgiu foi na década de 50
foi o sistema de arquivos eo desenvolvimento de armazenamento de acesso aleatório.
Esta foi a bela.
Agora, de repente, podemos colocar o nosso arquivos em qualquer lugar nesses discos rígidos
e nós podemos acessar esses dados de forma aleatória.
Podemos analisar que informações de arquivos.
E nós resolvemos todo o mundo problemas com processamento de dados.
>> E que durou cerca de 20 ou 30 anos até a evolução
do banco de dados relacional, que é quando o mundo decidiu que agora
precisa ter um repositório que derrota a expansão dos dados através do arquivo
sistemas que nós construímos. Certo?
Muitos dados distribuídos em muitos lugares, a de-duplicação de dados,
e o custo de armazenamento era enorme.
>> Nos anos 70, o recurso mais caro que um computador tinha era o de armazenamento.
O processador foi visto como um custo fixo.
Quando eu comprar a caixa, a CPU faz algum trabalho.
Vai ser giro se ele é realmente funcionando ou não.
Isso é realmente um custo afundado.
>> Mas o que me custou como um negócio é o armazenamento.
Se eu tenho que comprar mais discos próximo mês, isso é um custo real que eu pagar.
E que o armazenamento é caro.
>> Agora nós avanço rápido 40 anos e nós temos um problema diferente.
A computação é agora o recurso mais caro.
O armazenamento é barato.
Quero dizer, nós podemos ir a qualquer lugar no nuvem e podemos encontrar armazenamento barato.
Mas o que eu não consigo encontrar é computação barato.
>> Assim, a evolução de hoje tecnologia, da tecnologia de banco de dados,
está realmente focado em torno de bancos de dados distribuídos
que não sofrem o mesmo tipo de escala
limitações dos bancos de dados relacionais.
Vamos falar um pouco sobre o que isso realmente significa.
>> Mas uma das razões e o motorista atrás de nós isto--
falou sobre a pressão de dados.
Pressão de dados é algo que impulsiona a inovação.
E se você olhar para cima Nos últimos cinco anos,
este é um gráfico de que os dados carga toda a empresa geral
Parece que, nos últimos cinco anos.
>> E a regra geral do polegar estes dias-- se você vai Google--
é de 90% do que os dados nós armazenamos hoje, e foi
gerado dentro dos últimos dois anos.
ESTÁ BEM.
Agora, isso não é uma tendência que há de novo.
Esta é uma tendência que tem sido saindo por 100 anos.
Desde Herman Hollerith desenvolveu o cartão de perfurador,
temos vindo a construir repositórios de dados e coleta de dados em taxas fenomenais.
>> Assim, ao longo dos últimos 100 anos, nós vimos essa tendência.
Isso não vai mudar.
Daqui para frente, vamos ver este, se não uma tendência acelerada.
E você pode ver o que parece.
>> Se uma empresa, em 2010, teve um terabyte de dados sob gestão,
hoje que significa que eles são gestão de 6,5 petabytes de dados.
Isso é 6.500 vezes mais dados.
E eu sei que isso.
Eu trabalho com essas empresas todos os dias.
Cinco anos atrás, eu falaria com empresas
quem iria falar comigo sobre o que é uma dor é para gerir terabytes de dados.
E eles falariam para mim sobre como podemos ver
que este é provavelmente vai ser um ou dois petabyte
dentro de um par de anos.
>> Estas mesmas empresas hoje vou me encontrar com,
e eles estão falando comigo sobre o problema está lá ter gestão
dezenas, 20 petabytes de dados.
Assim, a explosão da dados na indústria
está dirigindo a enorme precisa de melhores soluções.
E o banco de dados relacional é apenas não viver de acordo com a demanda.
>> E por isso há uma linear correlação entre a pressão de dados
e inovação técnica.
A história tem nos mostrado este, que ao longo do tempo,
sempre que o volume de dados que tem de ser processado
excede a capacidade do sistema para processá-lo em um tempo razoável
ou a um custo razoável, em seguida, as novas tecnologias
são inventadas para resolver esses problemas.
Essas novas tecnologias, por sua vez, abre a porta
para um outro conjunto de problemas, o que está reunindo ainda mais dados.
>> Agora, nós não vamos parar com isso.
Certo?
Nós não vamos parar com isso.
Por quê?
Porque você não pode saber tudo que há para saber no universo.
E enquanto nós estivemos vivos, ao longo da história do homem,
temos sempre conduzido para saber mais.
>> Então, parece que cada polegada nos movemos no caminho da descoberta científica,
estamos a multiplicação da quantidade de dados que precisamos para processar exponencialmente
como descobrimos mais e mais e mais sobre o funcionamento interno da vida,
sobre como o universo funciona, sobre dirigir a descoberta científica,
e que a invenção nós estamos fazendo hoje.
O volume de dados apenas aumenta continuamente.
Assim, ser capaz de lidar com este problema é enorme.
>> Então, uma das coisas olharmos como por NoSQL?
Como é que NoSQL resolver este problema?
Bem, bancos de dados relacionais, Structured Query Language,
SQL-- que é realmente uma construção do relacional database-- essas coisas são
optimizada para o armazenamento.
>> Voltar na década de 70, mais uma vez, disco é caro.
O exercício de provisionamento de armazenamento na empresa é interminável.
Eu sei.
Eu vivi isso.
Eu escrevi drivers de armazenamento para um empresa superserver enterprised
de volta nos anos 90.
E a linha de fundo é outra trasfega matriz de armazenamento foi apenas algo que
Aconteceu a cada dia na empresa.
E não parou mais.
Maior densidade de armazenamento, a demanda para armazenamento de alta densidade,
e para um armazenamento mais eficiente devices-- ele nunca parou.
>> E NoSQL é uma grande tecnologia uma vez que normaliza os dados.
É de-duplica os dados.
Isto coloca os dados numa estrutura que é agnóstica para cada padrão de acesso.
Vários aplicativos podem bater esse Banco de dados SQL, executar consultas ad hoc,
e obter dados na forma que eles precisa processo para a sua carga de trabalho.
Isso soa fantástico.
Mas a linha inferior é com qualquer sistema, se é agnóstico a tudo,
ele é otimizado para nada.
ok?
>> E é isso que nós começamos com o banco de dados relacional.
Ele é otimizado para armazenamento.
É normalizada.
É relacional.
Ele suporta as consultas ad hoc.
E ele e ele escalas verticalmente.
>> Se eu preciso para obter um banco de dados SQL maior ou um banco de dados SQL mais poderoso,
Eu vou comprar um pedaço maior de ferro.
ok?
Eu trabalhei com um monte de clientes que já passou por grandes atualizações
em sua infra-estrutura SQL única para descobrir seis meses depois,
eles estão acertando a parede novamente.
E a resposta da Oracle ou MSSQL ou qualquer outra pessoa é obter uma caixa maior.
Bem, mais cedo ou mais tarde, você não pode comprar um maior caixa, e isso é problema real.
Precisamos realmente mudar as coisas.
Então, onde é que isto funciona?
Ele funciona bem para off-line analytics, do tipo OLAP cargas de trabalho.
E isso é realmente onde o SQL pertence.
Agora, ele é usado hoje em muitos on-line transacional-tipo de processamento
aplicações.
E ele funciona muito bem no algum nível de utilização,
mas ele simplesmente não escala a maneira que NoSQL faz.
E vamos falar um pouco pouco sobre por que isso acontece.
>> Agora, noSQL, por outro lado, é mais otimizado para computação.
ok?
Não é agnóstico o padrão de acesso.
É o que chamamos de-normalizado estrutura ou uma estrutura hierárquica.
Os dados em um banco de dados relacional é Juntaram-se a partir de várias tabelas
para produzir a visão de que você precisa.
Os dados no banco de dados NoSQL um é armazenado em um documento que
contém a estrutura hierárquica.
Todos os dados que, normalmente, seria uniram-se para produzir esse ponto de vista
é armazenado em um único documento.
E vamos falar um pouco sobre como isso funciona em um par de cartas.
>> Mas a idéia aqui é que você armazene seus dados como esses pontos de vista instanciado.
ok?
Você escala horizontal.
Certo?
Se eu precisar de aumentar o tamanho do meu agrupamento NoSQL,
Eu não preciso de obter uma caixa maior.
Recebo outra caixa.
E eu agrupar esses juntos, e eu posso caco que os dados.
Vamos falar um pouco sobre sharding que é, para ser
capaz de escalar esse banco de dados em vários dispositivos físicos
e remover a barreira que me obriga a escalar verticalmente.
>> Então, é realmente construído para on-line processamento de transações e escala.
Há uma grande distinção aqui entre os relatórios, certo?
Relatórios, eu não sei o perguntas que eu vou pedir.
Certo?
Reporting-- se alguém do meu departamento de marketing
quer só-- como muitos dos meus clientes têm essa característica em particular que
comprei nesta dia-- Não sei que consultar eles vão perguntar.
Então eu preciso ser agnóstico.
>> Agora, numa linha aplicativo transacional,
Eu sei que perguntas que eu estou pedindo.
Eu construí o pedido de um fluxo de trabalho muito específico.
ok?
Então, se eu otimizar a dados armazenar a apoiar esse fluxo de trabalho,
ele vai ser mais rápido.
E é por isso que pode NoSQL realmente acelerar a entrega
um destes tipos de serviços.
Tudo certo.
>> Então, nós estamos indo para entrar em um pouco de teoria aqui.
E alguns de vocês, seus olhos pode reverter um pouco.
Mas eu vou tentar mantê-lo tão alto nível que eu puder.
Então, se você está no projeto gestão, há
uma construção chamada triângulo de restrições.
ESTÁ BEM.
O triângulo de constrangimentos ditados você não pode ter tudo o tempo todo.
Não pode ter seu bolo e comê-lo.
Assim, em gerenciamento de projetos, que triângulo limitações é que você pode tê-lo barato,
você pode tê-lo rápido, ou você pode tê-lo bom.
Escolha dois.
Porque você não pode ter todos os três.
Certo?
ESTÁ BEM.
>> Então você ouve muito sobre isso.
É uma restrição tripla, triângulo de restrição tripla,
ou o triângulo de ferro é oftentimes-- quando você fala aos gerentes de projeto,
eles vão falar sobre isso.
Agora, bancos de dados têm seu próprio triângulo de ferro.
E o triângulo de ferro de dados é o que chamamos de teorema de CAP.
ok?
>> PAC ditames teorema como bancos de dados operar
sob uma condição muito específica.
E nós vamos falar sobre o que é essa condição.
Mas os três vértices do triângulo, por assim dizer, são C, consistência.
ok?
Assim, no PAC, a consistência significa que todos clientes que podem acessar o banco de dados
terá sempre um muito visão consistente dos dados.
Ninguém vai ver duas coisas diferentes.
ok?
Se eu ver o banco de dados, Estou vendo a mesma visão
como meu parceiro que vê a mesma base de dados.
Essa é a consistência.
>> Disponibilidade significa que, se o banco de dados on-line, se puder ser alcançado,
que todos os clientes serão sempre ser capaz de ler e escrever.
ok?
Assim, cada cliente que pode ler o banco de dados
será sempre capaz de leitura dados de dados e escrever.
E se esse for o caso, É um sistema disponível.
>> E o terceiro ponto é o que que chamamos de tolerância partição.
ok?
Meios de tolerância partição que o sistema funciona bem
apesar de rede física divisórias entre os nós.
ok?
Então nós do cluster não pode falar uns com os outros, o que acontece?
Tudo certo.
>> Bancos de dados relacionais Então choose-- você pode escolher dois destes.
ESTÁ BEM.
Bancos de dados relacionais Então escolha para ser consistente e disponível.
Se a partição acontece entre os DataNodes no armazenamento de dados,
o banco de dados falha.
Certo?
Ele só vai para baixo.
ESTÁ BEM.
>> E é por isso que eles têm a crescer com as caixas maiores.
Certo?
Porque não há Não-- geralmente, um cluster banco de dados, não há muito muitos deles
que operam dessa forma.
Mas a maioria dos bancos de dados de escala verticalmente dentro de uma única caixa.
Porque eles precisam ser consistente e disponível.
Se uma partição foram a ser injectado, então você teria que fazer uma escolha.
Você tem que fazer uma escolha entre sendo consistente e disponível.
>> E é isso que bancos de dados NoSQL fazer.
Tudo certo.
Assim, uma base de dados noSQL, ele vem em dois sabores.
Nós have-- bem, vem em muitos sabores,
mas ele vem com dois básico characteristics-- o que
nós chamaríamos de banco de dados CP, ou um tolerância e consistente partição
sistema.
Esses caras a fazer a escolha que, quando os nós perder o contacto uns com os outros,
nós não vamos permitir as pessoas a escrever mais.
ok?
>> Até que essa partição é removida, acesso de gravação é bloqueada.
Isso significa que eles não estão disponíveis.
Eles são consistentes.
Quando vemos que partição injectar-se,
estamos agora consistente, porque nós não vamos
para permitir a mudança de dados em dois os lados da partição independentemente
de cada um.
Nós teremos que restabelecer a comunicação
antes de qualquer atualização os dados são permitidos.
ok?
>> O próximo sabor seria um sistema AP, ou um disponível e repartiu
sistema de tolerância.
Esses caras não se importam.
Certo?
Qualquer nó que recebe uma escrever, nós vamos tomá-lo.
Então, eu estou replicar meus dados em vários nós.
Esses nós obter um cliente, o cliente vem em, diz, eu vou escrever alguns dados.
Nó diz, não há problema.
O nó ao lado dele fica uma gravação no mesmo registro,
ele vai dizer não problema.
Em algum lugar de volta no back-end, que os dados vai replicar.
E então alguém vai perceber, uh-oh, eles vão perceber sistema, uh-oh,
houve uma atualização para os dois lados.
O que nós fazemos?
E o que eles fazem é, então, eles fazem algo que
lhes permite resolver esse estado de dados.
E nós vamos falar sobre que, no quadro seguinte.
>> Coisa a salientar aqui.
E eu não vou ficar muito muito a este, porque esta
entra em teoria dados de profundidade.
Mas há um transacional quadro que
é executado em um sistema relacional que permite que eu faça com segurança atualizações
para várias entidades no banco de dados.
E essas atualizações devem ocorrer todo de uma só vez ou de modo nenhum.
E isso é chamado de transações ACID.
ok?
>> ACID nos dá atomicidade, consistência, isolamento, e durabilidade.
ok?
Isso significa que, transações atômicas, tudo minhas atualizações tanto acontecer ou não fazem.
Consistência significa que o banco de dados será sempre
ser levado a um consistente estado após uma atualização.
Eu nunca vou deixar o banco de dados em um mau estado depois de aplicar uma atualização.
ok?
>> Portanto, é um pouco diferente de consistência PAC.
Consistência PAC significa toda minha os clientes podem sempre ver os dados.
Consistência ÁCIDO significa que quando uma transação é feito, dados de boa.
Meus relacionamentos são tudo de bom.
Eu não estou indo para apagar uma linha pai e deixar um monte de crianças órfãs
em alguma outra tabela.
Isso não pode acontecer se eu estiver consistente em uma transação de ácido.
>> Isolamento significa que as transações sempre ocorrer uma depois da outra.
O resultado final dos dados será o mesmo estado
como se essas operações que foram emitidos simultaneamente
foram executados em série.
Portanto, é a simultaneidade controlo na base de dados.
Então, basicamente, eu não posso incrementar o mesmo valor duas vezes com duas operações.
>> Mas se eu disser adicionar 1 a este valor, e duas operações vêm em
e tentar fazê-lo, é uma vai chegar lá primeiro
e do outro um vai chegar lá depois.
Então, no final, eu adicionei dois.
Você vê o que eu quero dizer?
ESTÁ BEM.
>> A durabilidade é bastante simples.
Quando a transação é reconhecido, é
vai estar lá mesmo se o sistema falhar.
Quando esse sistema recupera, isto transação que foi cometida
está realmente indo para estar lá.
Então, isso é as garantias de transações ACID.
Essas são garantias bastante agradáveis para ter em um banco de dados,
mas eles vêm para esse custo.
Certo?
>> Porque o problema com este quadro é
Se houver uma partição na dados set, eu tenho que tomar uma decisão.
Eu vou ter para permitir que atualizações de um lado ou do outro.
E se isso acontecer, então eu já não estou indo
para ser capaz de manter essas características.
Eles não vão ser consistente.
Eles não vão ser isolado.
Este é o lugar onde se decompõe para bancos de dados relacionais.
Esta é a razão relacional bancos de dados de escala vertical.
>> Por outro lado, temos o que é chamado de tecnologia BASE.
E estes são os seus bancos de dados NoSQL.
Tudo certo.
Portanto, temos nossa CP, bancos de dados de AP.
E estes são, basicamente, o que você chama disponível, estado macio, eventualmente,
consistente.
ok?
>> Basicamente disponível, porque eles são partição tolerante.
Eles serão sempre lá, mesmo se não houver
uma divisória entre os nós da rede.
Se eu posso falar com um nó, eu sou vai ser capaz de ler dados.
ok?
Eu posso não ser sempre capaz de escrever dados se eu sou uma plataforma consistente.
Mas eu vou ser capaz de ler os dados.
>> O estado indica macio que quando eu ler esses dados,
ele pode não ser o mesmo que os outros nós.
Se um direito foi emitido em um nó em outro lugar no cluster
e não foi replicado em toda a aglomerado ainda quando li que os dados,
que o estado pode não ser consistente.
No entanto, será eventualmente, consistente,
o que significa que quando uma gravação é feito para o sistema,
ele vai replicar em todos os nós.
E, eventualmente, esse estado será posto em ordem,
e será um estado consistente.
>> Agora, o teorema PAC realmente joga apenas em uma condição.
Essa condição é quando isso acontece.
Porque sempre que ele está operando em modo normal, não há nenhuma partição,
tudo é consistente e disponível.
Você só se preocupar com CAP quando temos essa partição.
Portanto, estas são raras.
Mas como o sistema reage quando os ocorrem ditar que tipo de sistema
estamos lidando.
>> Então, vamos dar uma olhada no que que parece para os sistemas AP.
ok?
Sistemas AP vêm em dois sabores.
Eles vêm em o sabor que é um mestre mestre, 100%, sempre disponível.
E eles vêm na outro sabor, que diz:
você sabe o quê, eu vou me preocupar sobre essa coisa de particionamento
quando ocorre uma partição real.
Caso contrário, não vai ser primária nós que vai levar os direitos.
ok?
>> Então, se nós algo como Cassandra.
Cassandra seria um mestre mestre, vamos escrever-me a qualquer nó.
Então o que acontece?
Então, eu tenho um objeto no banco de dados que existe em dois nós.
Vamos chamar esse objeto S. Portanto, temos estado para S.
Temos algumas operações S em que estão em curso.
Cassandra me permite escrever para vários nós.
Então, digamos que eu recebo uma escrever para s para dois nós.
Bem, o que acaba acontecendo é chamamos isso de um evento de particionamento.
Não pode ser um partição de rede física.
Mas por causa do projeto do sistema, que é
particionamento realmente logo que eu conseguir uma gravação em dois nós.
Não está me forçando a escrever tudo através de um nó.
Eu estou escrevendo sobre dois nós.
ok?
>> Então agora eu tenho dois estados.
ok?
O que vai acontecer é, mais cedo ou mais tarde,
lá vai ser um evento de replicação.
Não vai ser o que nós chamado de recuperação de partição, que
é o lugar onde estes dois estados voltar juntos
e lá vai ser um algoritmo que é executado dentro do banco de dados,
decide o que fazer.
ok?
Por padrão, última atualização vence na maioria dos sistemas de AP.
Portanto, há geralmente um algoritmo padrão, o que
eles chamam de um callback função, algo que
será chamado quando esta condição seja detectado para executar alguma lógica
para resolver esse conflito.
ok?
O retorno de chamada padrão e padrão resolver na maioria dos bancos de dados AP
é, adivinhem, timestamp ganha.
Esta foi a última atualização.
Eu vou colocar essa atualização lá.
Eu posso despejar este registro que eu despejado fora em um log de recuperação
de modo que o usuário pode voltar mais tarde e dizer, hey, houve uma colisão.
O que aconteceu?
E você pode realmente despejar um registro de todas as colisões e as reversões
e ver o que acontece.
>> Agora, como um usuário, você também pode incluir lógica em que callback.
Assim, você pode mudar isso operação de retorno de chamada.
Você pode dizer, hey, eu quero para remediar esses dados.
E eu quero tentar e mesclar esses dois registros.
Mas isso é até você.
O banco de dados não sabe como fazer isso por padrão. A maior parte do tempo,
a única coisa que o banco de dados sabe fazer é dizer,
este foi o último registro.
Isso é o que vai ganhar, e esse é o valor que eu vou colocar.
Uma vez que a recuperação partição e replicação ocorre,
temos o nosso estado, que agora é S principal, que é
o estado de mesclagem de todos esses objetos.
Assim, os sistemas AP ter isso.
Sistemas CP não precisa se preocupar com isso.
Porque assim como uma partição vem em jogo, eles simplesmente parar de tomar
escreve.
ok?
Então, isso é muito fácil lidar com ser consistente
quando você não aceitar quaisquer atualizações.
Isso é com os sistemas CP fazer.
Tudo certo.
>> Então vamos falar um pouco pouco sobre padrões de acesso.
Quando falamos de NoSQL, é tudo sobre o padrão de acesso.
Agora, o SQL é ad hoc, as consultas.
É armazenamento relacional.
Nós não temos que preocupar-se sobre o padrão de acesso.
Eu escrever uma consulta muito complexa.
Ele vai e pega os dados.
Isso é o que isso parece como, normalização.
>> Portanto, neste estrutura particular, nós estamos olhando para um catálogo de produtos.
I têm diferentes tipos de produtos.
Tenho livros.
Eu tenho álbuns.
Eu tenho vídeos.
A relação entre os produtos e qualquer um desses livros, álbuns,
e vídeos tabelas é 1: 1.
Tudo certo?
Eu tenho um ID do produto, e que corresponde ID
para um livro, um álbum ou um vídeo.
ok?
Isso é uma relação 1: 1 através dessas tabelas.
>> Agora, todos eles books-- tem é propriedades da raiz.
Sem problemas.
Isso é ótimo.
One-to-one relacionamento, eu recebo tudo os dados que eu preciso para descrever esse livro.
Álbuns Albums-- têm faixas.
Isto é o que chamamos de um para muitos.
Cada álbum pode ter muitas faixas.
Assim, para cada faixa o álbum, eu poderia ter
outro recorde nesta tabela filho.
Então eu criar um registro na minha tabela de álbuns.
Eu criar vários registros na tabela de faixas.
One-to-many relationship.
>> Esta relação é o que que chamamos de muitos-para-muitos.
ok?
Você vê que os atores poderiam ser em muitos filmes, muitos vídeos.
Então, o que fazemos é colocar esse mapeamento mesa entre aqueles, que ele só
mapeia o ID ator para o ID de vídeo.
Agora eu posso criar uma consulta da junta vídeos através de vídeo ator para atores,
e isso me dá uma boa lista de todos os filmes e todos os atores
que eram naquele filme.
>> ESTÁ BEM.
Então, vamos lá.
One-to-one é a de nível superior relação; um-para-muitos,
álbuns de trilhas; muitos-para-muitos.
Esses são os três de nível superior relacionamentos em qualquer banco de dados.
Se você sabe como aqueles relações de trabalho em conjunto,
então você sabe muito sobre banco de dados já.
Então NoSQL funciona um pouco diferente.
Vamos pensar por um segundo o que olhares gosta de ir obter todos os meus produtos.
>> Em uma loja relacional, I quer obter todos os meus produtos
em uma lista de todos os meus produtos.
Isso é um monte de consultas.
Eu tenho uma consulta para todos os meus livros.
Eu tenho uma consulta dos meus álbuns.
E eu tenho uma consulta para todos os meus vídeos.
E eu tenho que colocá-lo todos juntos em uma lista
e servi-lo de volta até o aplicativo que está solicitando isso.
>> Para obter os meus livros, eu juntar- Produtos e Livros.
Para obter os meus álbuns, eu comecei a juntar-se Produtos, Álbuns, e faixas.
E para obter meus vídeos, eu tenho para juntar-se os produtos a vídeos,
juntar-se através Ator vídeos, e trazer os atores.
Então, isso é três consultas.
Consultas muito complexas para montar um conjunto de resultados.
>> Isso é menos do que ideal.
É por isso que quando falamos sobre uma estrutura de dados que é
construído para ser agnóstico ao acesso pattern-- bem, isso é ótimo.
E você pode ver isso é realmente agradável como nós organizamos os dados.
E você sabe o que?
Eu só tenho um recorde para um ator.
>> Isso é legal.
Eu deduplicados todos os meus atores, e eu mantive minhas associações
nesta tabela de mapeamento.
No entanto, obter os dados fora torna-se caro.
Estou enviando a CPU em todo o sistema juntando essas estruturas de dados em conjunto
para ser capaz de puxar os dados de volta.
>> Então, como posso contornar isso?
Em NoSQL é sobre agregação, não normalização.
Por isso, queremos dizer que nós queremos apoiar o padrão de acesso.
Se o padrão de acesso para as aplicações,
Eu preciso para obter todos os meus produtos.
Vamos colocar todos os produtos em uma tabela.
Se eu colocar todos os produtos em uma tabela, Eu só posso selecionar todos os produtos
a partir dessa mesa e eu entendi tudo.
Bem, como eu faço isso?
Bem em NoSQL não há nenhuma estrutura para a mesa.
Vamos falar um pouco sobre como isso funciona na Dynamo DB.
Mas você não tem o mesmo atributos e as mesmas propriedades
em cada linha única, em cada item, como você faz em uma tabela SQL.
E o que isso me permite para fazer um monte de coisas
e me dar um monte de flexibilidade.
Neste caso particular, eu tenho meus documentos do produto.
E nesse particular exemplo, tudo
é um documento na tabela Produtos.
E o produto de um livro pode ter um ID de tipo que especifica um livro.
E a aplicação mudariam em que ID.
>> Na camada de aplicativo, eu vou para dizer oh, que tipo de registro é isso?
Oh, é um registro livro.
Registros do livro têm essas propriedades.
Deixe-me criar um objeto livro.
Então, eu estou indo para preencher o livro objeto com este item.
Próximo item vem e diz, o que é este item?
Bem, este item é um álbum.
Oh, eu tenho um diferente inteiro rotina de processamento para que,
porque é um álbum.
Você vê o que eu quero dizer?
>> Assim, a aplicação tier-- I basta selecionar todos esses registros.
Todos eles começam a vir.
Eles podem ser de todos os tipos diferentes.
E é a lógica do aplicativo que alterna entre os tipos
e decide como processá-los.
>> Mais uma vez, por isso estamos otimizando o esquema para o padrão de acesso.
Estamos fazendo isso por colapso dessas tabelas.
Estamos basicamente tomando estas estruturas normalizados,
e nós estamos construindo estruturas hierárquicas.
Dentro de cada um destes registos Eu estou indo para ver propriedades de matriz.
>> Dentro deste documento para Álbuns, Eu estou vendo matrizes de faixas.
Essas faixas agora é become-- basicamente esta tabela filho que
existe aqui nesta estrutura.
Assim, você pode fazer isso no DynamoDB.
Você pode fazer isso no MongoDB.
Você pode fazer isso em qualquer banco de dados NoSQL.
Criar estes tipos de estruturas de dados hierárquicos
que permitem que você recuperar dados muito rapidamente, porque agora eu
não tem que se conformar.
Quando eu inserir uma linha para as Faixas mesa, ou uma linha na tabela de álbuns,
Eu tenho que estar em conformidade com esse esquema.
Eu tenho que ter o atributo ou a propriedade que é definida nessa tabela.
Cada um deles, quando eu inserir essa linha.
Isso não é o caso em NoSQL.
>> Eu posso ter totalmente diferente propriedades em cada documento
que eu inserir na coleção.
Então mecanismo muito poderoso.
E é realmente como você optimizar o sistema.
Porque agora que consulta, em vez de juntar todas essas tabelas
e execução de uma meia dúzia de consultas para puxar a dados que eu preciso,
Estou executando uma consulta.
E eu estou a iteração em todo o conjunto de resultados.
dá-lhe uma ideia do poder de NoSQL.
Eu estou indo para ir para o lado tipo de aqui e falar um pouco sobre isso.
Isto é mais do tipo comercialização ou technology--
a comercialização de tecnologia tipo de discussão.
Mas é importante entender porque, se olharmos para o topo
aqui nesta carta, o que nós estamos olhando para
é o que chamamos de curva campanha publicitária tecnologia.
E o que isto significa é material novo entra em jogo.
As pessoas pensam que é ótimo.
Eu já resolveu todos os meus problemas.
>> Esta poderia ser a extremidade tudo, ser tudo de tudo.
E eles começam a usá-lo.
E eles dizem, essa coisa não funciona.
Isto não está certo.
O material antigo era melhor.
E eles vão voltar a fazer as coisas do jeito que estavam.
E depois, eventualmente, eles vão, você sabe o quê?
Este material não é tão ruim.
Oh, é assim que funciona.
E uma vez que descobrir como ele obras, eles começam a ficar melhor.
>> E o engraçado sobre isso é, que tipo de linhas até que
chamamos a Curva de Adoção de Tecnologia.
Então o que acontece é que temos algum tipo de gatilho tecnologia.
No caso das bases de dados, é a pressão de dados.
Nós conversamos sobre os pontos de água altos dados de pressão ao longo do tempo.
Quando esta pressão atinge um certo dados ponto, isso é um gatilho tecnologia.
>> Está ficando muito caro.
Leva muito tempo para processar os dados.
Precisamos de algo melhor.
Você obtém os inovadores lá fora, correndo por aí,
tentando descobrir qual é a solução.
Qual é a nova idéia?
>> Qual é a melhor próxima maneira de fazer isso?
E eles vêm para cima com alguma coisa.
E as pessoas com a dor real, os indivíduos na borda do sangramento,
eles vão saltar tudo sobre ele, porque eles precisam de uma resposta.
Agora, o que inevitavelmente happens-- e isso está acontecendo agora em NoSQL.
Eu vejo isso o tempo todo.
>> O que acontece é inevitavelmente pessoas começam a usar a nova ferramenta
da mesma forma que usou a ferramenta de idade.
E eles descobrir que não funciona tão bem.
Não consigo me lembrar quem eu era falando mais cedo hoje.
Mas é como, quando o britadeira foi inventado,
as pessoas não balançá-lo sobre sua cabeça para quebrar o concreto.
>> Mas isso é o que é acontecendo com NoSQL hoje.
Se você caminhada para a maioria das lojas, eles estão tentando ser lojas NoSQL.
O que eles estão fazendo é eles estão usando NoSQL,
e eles estão carregando- cheio de esquema relacional.
Porque é assim que eles projetam bancos de dados.
E eles estão se perguntando, por que é não realizar muito bem?
Rapaz, essa coisa fede.
Eu tive que manter toda a minha junta-se em-- como é, não, não.
Manter junta?
Por que você está juntando dados?
Você não se juntar dados NoSQL.
Você agregar-lo.
>> Então, se você quiser evitar isso, aprender como a ferramenta funciona antes que você realmente
começar a usá-lo.
Não tente usar as novas ferramentas do mesma maneira que você usou as ferramentas antigas.
Você vai ter uma experiência ruim.
E cada vez isso é o que se trata.
Quando começam a vir até aqui, é porque as pessoas descobriram
como usar as ferramentas.
>> Eles fizeram a mesma coisa quando bancos de dados relacionais foram inventados,
e eles estavam substituindo os sistemas de arquivos.
Eles tentaram construir sistemas de arquivos com bancos de dados relacionais
porque é isso que as pessoas entendessem.
Não funcionou.
Assim, a compreensão das melhores práticas da tecnologia você está trabalhando com
é enorme.
Muito importante.
>> Então, nós estamos indo para entrar em DynamoDB.
DynamoDB é AWS de totalmente de gestão plataforma NoSQL.
O que totalmente de gestão significa?
Isso significa que você não precisa realmente se preocupar com nada.
>> Você entra, você diz nós, eu preciso de uma mesa.
Ele precisa de tanta capacidade.
Você pressiona o botão, e provisão nós toda infra-estrutura por trás da cena.
Agora que é enorme.
>> Porque quando você fala sobre o dimensionamento de um banco de dados,
Clusters de dados NoSQL na escala, petabytes de funcionamento,
executando milhões de transações por segundo,
estas coisas não são pequenos clusters.
Estamos falando de milhares de casos.
Gerenciamento de milhares de instâncias, até mesmo instâncias virtuais,
é uma verdadeira dor na bunda.
Quer dizer, pensar em cada vez que um patch de sistema operacional sai
ou uma nova versão do banco de dados.
O que isso significa operacionalmente a você?
Isso significa que você tem 1200 servidores que precisam ser atualizados.
Agora, até mesmo com a automação, que pode levar um longo tempo.
Isso pode causar uma série de dores de cabeça operacionais,
porque eu poderia ter serviços para baixo.
>> Como eu atualizar essas bases de dados, I pode fazer implantações verde azul
onde eu implantar e atualizar a metade da minha nós, e depois atualizar a outra metade.
Tome aqueles para baixo.
Portanto, o gerenciamento da infra-estrutura escala é extremamente doloroso.
E AWS assumir que a dor de fora.
E bancos de dados NoSQL pode ser extraordinariamente dolorosa
por causa da maneira que escala.
>> Dimensionar horizontalmente.
Se você quiser obter um maior NoSQL banco de dados, você compra mais nós.
Cada nó que você compra é outra cabeça operacional.
Então deixe outra pessoa fazer isso por você.
AWS pode fazer isso.
>> Apoiamos os valores-chave do documento.
Agora nós não ir muito Por outro em gráfico.
Há um monte de diferente sabores de NoSQL.
Eles são todos os tipos de conseguir munged juntos neste momento.
Você pode olhar para DynamoDB e dizer que sim, nós dois somos um documento e um valor de chave
armazenar este ponto.
E você pode discutir as características de um sobre o outro.
Para mim, um monte de presente é realmente seis de uma meia dúzia de outro.
Cada uma dessas tecnologias é um tecnologia de multa e uma solução bem.
Eu não diria que é melhor ou MongoDB pior do que Couch, em seguida, Cassandra,
então Dynamo, ou vice-versa.
Quero dizer, estes são apenas opções.
>> É rápido e é consistente em qualquer escala.
Portanto, este é um dos maiores bônus que você começa com a AWS.
Com DynamoDB é a capacidade para obter um baixo único dígito
latência milissegundo em qualquer escala.
Essa era uma meta de projeto do sistema.
E temos clientes que estão fazendo milhões de operações por segundo.
>> Agora eu vou passar por algumas das pessoas usar casos em poucos minutos aqui.
Control-- acesso integrado nós temos o que chamamos
Gerenciamento de Acesso identidade ou IAM.
Ela permeia todos os sistemas, todos os serviços que a AWS oferece.
DynamoDB não é excepção.
Você pode controlar o acesso para as tabelas DynamoDB.
Em todas as suas contas pela AWS definição de funções de acesso e permissões
na infra-estrutura de IAM.
>> E é um componente fundamental e integral em o que chamamos de eventos programação orientada.
Agora, este é um novo paradigma.
>> AUDIÊNCIA: Como é a sua taxa de verdadeira positivos contra falsos negativos
em seu sistema de controle de acesso?
RICK HOULIHAN: Verdadeiros positivos contra falsos negativos?
AUDIÊNCIA: Devolver o que você deve estar retornando?
Ao contrário de vez em quando ele não retorna quando ele deve validar?
>> RICK HOULIHAN: Eu não poderia te dizer isso.
Se houver quaisquer falhas seja qual for, que,
Eu não sou a pessoa para perguntar essa questão particular.
Mas isso é uma boa pergunta.
Eu seria curioso para saber que eu, na verdade.
>> E assim, novamente, novo paradigma é dirigida evento programação.
Esta é a idéia de que você pode implantar aplicativos complexos que
pode operar um muito, muito alta escala sem qualquer infra-estrutura qualquer.
Sem qualquer fixo infra-estrutura qualquer.
E nós vamos falar um pouco sobre o que isso significa que nós
obter para o próximo par de cartas.
>> A primeira coisa que vamos fazer é falaremos sobre mesas.
Tipos de dados API para Dynamo.
E a primeira coisa que você vai notar quando você olha para isso,
se você estiver familiarizado com qualquer banco de dados, bancos de dados têm realmente dois tipos de APIs
Eu diria que é.
Ou dois conjuntos de API.
Uma delas seria API administrativa.
>> As coisas que eles cuidam de as funções da base de dados.
Configurando o mecanismo de armazenamento, a criação e inclusão de tabelas.
criação de banco de dados catálogos e instâncias.
Estes coisas- em DynamoDB, você têm listas muito curto, curto.
>> Portanto, em outras bases de dados, você pode ver dezenas
de comandos, de administrativa comandos, para a configuração
estas opções adicionais.
Em DynamoDB você não precisa aqueles porque você não configurar o sistema, o que fazemos.
Então a única coisa que você precisa fazer é me diga o que mesa tamanho eu preciso.
Então você começa um muito conjunto limitado de comandos.
>> Você começa uma Create Table Update, Mesa, Excluir Mesa, e descrever Table.
Essas são as únicas coisas você precisa para DynamoDB.
Você não precisa de um armazenamento configuração do motor.
Eu não precisa se preocupar com a replicação.
Eu não precisa se preocupar com sharding.
>> Eu não precisa se preocupar sobre algum deste material.
Fazemos tudo para você.
Então, isso é uma enorme quantidade de sobrecarga isso é só decolou seu prato.
Então nós temos os operadores CRUD.
CRUD é algo que temos chamar banco de dados que é
Criar, atualizar, excluir operadores.
Estes são os seus comum operações de banco de dados.
Coisas como item de venda, obter item, atualização itens, apagar objetos, consulta de lote, digitalizar.
Se você quiser verificar a tabela inteira.
Puxe tudo fora da mesa.
Uma das coisas agradáveis ​​sobre DynamoDB é que permite a digitalização paralela.
Então você pode realmente deixe-me saber quantas tópicos que você deseja executar em que digitalização.
E nós podemos executar esses tópicos.
Nós podemos girar que digitalizar até através de múltiplas threads
assim você pode verificar a tabela inteira espaço muito, muito rapidamente no DynamoDB.
>> A outra API que temos é o que chamamos de nossa API Streams.
Nós não vamos falar muito muito sobre isso agora.
Eu tenho algum conteúdo mais tarde em no baralho sobre isso.
Mas Streams é realmente um running-- pense nisso como o tempo encomendado
e log de alterações partição.
Tudo o que está acontecendo no a tabela mostra-se no fluxo.
>> Cada escrever para a mesa mostra-se no fluxo.
Você pode ler esse fluxo, e você pode fazer coisas com ele.
Vamos falar sobre o que tipos de coisas que você
fazer com as coisas como replicação, a criação de índices secundários.
Todos os tipos de muito legal coisas que você pode fazer com isso.
>> Os tipos de dados.
Em DynamoDB, apoiamos tanto chave valor e de dados documento tipos.
No lado esquerdo do ecrã aqui, nós temos os nossos tipos básicos.
Tipos de valor-chave.
Estes são cordas, números e binários.
>> Então, apenas três tipos básicos.
E então você pode ter conjuntos de aqueles.
Uma das coisas agradáveis ​​sobre NoSQL é você pode conter matrizes como propriedades.
E com DynamoDB pode conter matrizes de tipos básicos como uma propriedade raiz.
>> E depois há os tipos de documentos.
Quantas pessoas estão familiarizadas com JSON?
Vocês familiarizadas com JSON tanto?
É basicamente JavaScript, Object, Notation.
Ele permite que você, basicamente, definir uma estrutura hierárquica.
>> Você pode armazenar um documento JSON em DynamoDB usando componentes comuns
ou blocos de construção que estão disponíveis na maioria das linguagens de programação.
Então, se você tem o Java, você está olhando os mapas e listas.
Eu posso criar objetos que área do mapa.
Um mapa como valores-chave armazenado como propriedades.
E pode ter listas de valores dentro dessas propriedades.
Você pode armazenar este complexo estrutura hierárquica
como um único atributo de um item de DynamoDB.
>> Então tabelas no DynamoDB, como a maioria Bancos de dados NoSQL, as tabelas têm itens.
Em MongoDB você faria chamar esses documentos.
E seria a base sofá.
Além disso uma base de dados de documento.
Você chama esses documentos.
Documentos ou itens têm atributos.
Pode existir atributos ou não existe no produto.
Em DynamoDB, há um atributo obrigatório.
Assim como em um banco de dados relacional, você tem uma chave primária na tabela.
>> DynamoDB tem o que chamamos de uma chave de hash.
Chave de hash deve ser exclusivo.
Então, quando eu definir uma tabela hash, basicamente o que eu estou dizendo
é cada item terá uma chave de hash.
E cada chave de hash deve ser exclusivo.
>> Cada item é definido por essa chave da mistura original.
E só pode haver um.
Este é OK, mas muitas vezes que as pessoas precisam
é que eles querem é esse hash chave para fazer um pouco mais
que apenas ser um identificador único.
Muitas vezes nós queremos usar essa chave de hash como o topo balde agregação nível.
E a maneira de fazermos isso é por acrescentando o que chamamos de uma chave intervalo.
>> Então, se é apenas um hash mesa, esta deve ser exclusivo.
Se é uma tabela hash e gama, o combinação do hash eo intervalo
deve ser exclusivo.
Então, pense nisso desta maneira.
Se eu tiver um fórum.
E a forma tem tópicos, tem lança, e tem respostas.
>> Então, eu poderia ter um hash chave, que é a identificação de tópico.
E eu poderia ter uma chave de gama, que representa a identificação da resposta.
Dessa forma, se eu quiser obter todas as respostas para determinado tópico,
Eu só posso consultar o hash.
Posso apenas dizer que me dar tudo os itens que têm esse hash.
E eu estou indo para obter todas as perguntas ou postar para esse tópico particular.
Essas agregações de nível superior são muito importantes.
Eles suportam o acesso primário padrão do aplicativo.
De um modo geral, esta é o que nós queremos fazer.
Queremos que mesa-- como você carregar a tabela,
queremos estruturar a dados dentro da tabela de tal maneira
que a aplicação pode muito recuperar rapidamente esses resultados.
E muitas vezes a maneira de fazer isso é para manter estas agregações como nós
inserir os dados.
Basicamente, nós estamos espalhando os dados no balde brilhante como ele vem em.
>> Intervalo de chaves de hash permitir me-- chaves tem que ser igualdade.
Quando eu consultar um hash, eu tenho que dizer dê-me um hash que é igual a este.
Quando eu consultar um intervalo, eu pode dizer-me dar um intervalo
que está usando qualquer tipo de operador rico que apoiamos.
Dê-me todos os itens para um hash.
É igual, maior que, menos do que, não é começar,
ela existe entre estes dois valores?
Então, esses tipos de consultas de intervalo que estamos sempre interessados ​​em.
Agora uma coisa sobre os dados, quando você olhar para o acesso a dados, quando
você acessar os dados, é sempre sobre uma agregação.
É sempre sobre os registros que estão relacionadas com este.
Dá-me tudo aqui that's-- tudo as transações de cartão de crédito nesta
para o último mês.
Isso é uma agregação.
>> Quase tudo que você faz no banco de dados é um tipo de agregação.
Assim, ser capaz de ser capaz de definir estes baldes e dar-lhe estes variam
atributos de ser capaz de consulta em, essas consultas ricos apoiar muitos,
muitos, muitos padrões de acesso do aplicativo.
>> Então a outra coisa a chave de hash faz é que nos dá um mecanismo
para ser capaz de difundir os dados de volta.
Bancos de dados NoSQL funcionar melhor quando os dados são uniformemente
distribuídos em todo o cluster.
Quantas pessoas estão familiarizados com algoritmos de hash?
Quando eu digo de hash e um hashing-- porque um algoritmo de hashing
é um modo de ser capaz de gerar um valor aleatório de qualquer valor dado.
Portanto, neste caso particular, o algoritmo de hash que corremos é ND 5 com base.
>> E se eu tiver um ID, e este é a minha chave de hash, eu tenho 1, 2, 3.
Quando eu executar o algoritmo de hash, ele vai voltar e dizer,
poço 1 é igual a 7B, 2 é igual a 48, é igual a 3 CD.
Eles estão espalhados por todo o espaço da chave.
E por que você faz isso?
Porque isso garante que eu posso colocar os registros em vários nós.
>> Se eu estou fazendo isso incrementalmente, 1, 2, 3.
E eu tenho uma gama de hash que runs, neste caso específico,
um pequeno espaço de hash, que vai de 00 a FF,
em seguida, os registros vão vir em e eles estão indo para ir 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
O que acontece?
Cada inserção é indo para o mesmo nó.
Você vê o que eu quero dizer?
>> Porque quando eu dividir o espaço, e eu espalhar esses registros transversalmente,
e partição eu, eu vou dizer partição 1 tem espaço chave 0-54.
Partição 2 é 55-89.
Partição 3 é AA a FF.
Então, se eu estou usando linearmente incrementando IDs, você pode ver o que está acontecendo.
1, 2, 3, 4, 5, 6, todos forma-se a 54.
Então, como eu estou martelando a registros no sistema,
tudo acaba indo para um nó.
>> Isso não é bom.
Essa é uma antipattern.
Em MongoDB eles têm esse problema se você não usar uma chave de hash.
MongoDB lhe dá a opção de hash o valor da chave.
Você deve sempre fazer isso, se você está usando um hash incrementando
chave no MongoDB, ou você vai ser cravando cada gravação para um nó,
e você vai ser um fator limitante o seu rendimento escrever mal.
>> AUDIÊNCIA: É que A9 169 em decimal?
>> RICK HOULIHAN: Sim, é algo em torno de lá.
A9, eu não sei.
Você teria que pegar minha binário a calculadora decimal.
Meu cérebro não funciona assim.
AUDIÊNCIA: Apenas um rápido Seus comentários Mongo.
Assim é a identificação do objeto que vem nativamente com Mongo fazer isso?
RICK HOULIHAN: Será que ela faria isso?
Se você especificá-lo.
Com MongoDB, você tem a opção.
Você pode specify-- cada documento MongoDB tem que ter um ID sublinhado.
Esse é o valor único.
>> Em MongoDB você pode especificar se a hash-lo ou não.
Eles apenas dar-lhe a opção.
Se você sabe que é aleatória, não há problema.
Você não precisa fazer isso.
Se você sabe que não é aleatório, que ele está incrementando, em seguida, fazer o hash.
>> Agora, a coisa sobre hashing, uma vez que o hash
um value-- e esta é por que chaves de hash são sempre
consultas únicas, porque eu mudei o valor, agora eu não posso fazer uma consulta intervalo.
Eu não posso dizer é isto entre isso ou aquilo,
porque o valor de hash não vai como sendo equivalente ao valor real.
Então, quando você hash que chave, é apenas a igualdade.
É por isso que na chave de hash DynamoDB consultas são sempre apenas a igualdade.
>> Então, agora em uma escala key-- quando eu adicionar essa chave gama,
esses registros principais alcance todos entrar e eles ficam armazenados na mesma partição.
Então, eles estão muito rapidamente, facilmente recuperado porque este é o hash,
esta é a gama.
E você vê tudo com o mesmo hash
fica armazenado no mesmo espaço de partição.
Você pode usar essa chave para ajudar a gama localizar seus dados perto de seu pai.
Então, o que eu realmente estou fazendo aqui?
Esta é uma relação um para muitos.
A relação entre uma chave de hash ea tecla de intervalo é de um para muitos.
Eu posso ter várias chaves de hash.
Eu só pode ter intervalo múltiplo chaves dentro de cada chave de hash.
>> O hash define o pai, o intervalo define as crianças.
Assim você pode ver que há analógica aqui entre o construto relacional
e os mesmos tipos de constrói em NoSQL.
As pessoas falam sobre NoSQL como não-relacional.
Não é nonrelational.
Dados sempre tem relações.
Essas relações apenas são modeladas de modo diferente.
Vamos falar um pouco pouco sobre durabilidade.
Quando você escreve para DynamoDB, escreve são sempre três vias replicado.
O que significa que temos três AZ de.
AZ são de Zonas de disponibilidade.
Você pode pensar em um Disponibilidade Zona como um centro de dados
ou um conjunto de centros de dados.
Essas coisas são geograficamente isolados uns dos outros
em diferentes zonas de falhas, através diferentes redes de energia e planícies aluviais.
Uma falha em um AZ não é indo para derrubar o outro.
Eles também estão ligados juntamente com a fibra escura.
Ele suporta uma sub 1 latência milissegundo entre AZs.
Assim repetições de dados em tempo real capaz em multi AZs.
>> E implementações muitas vezes multi-AZ atender aos requisitos de alta disponibilidade
da maioria das organizações empresariais.
Então DynamoDB está espalhada em três AZs por padrão.
Nós estamos indo apenas para o conhecimento da escrita quando dois desses três nós voltar
e dizer: Sim, eu tenho.
Por que é que?
Porque no lado da leitura estamos apenas vai dar-lhe os dados de volta quando
nós obtê-lo de dois nós.
>> Se eu estou replicar em toda três, e eu estou lendo a partir de dois,
Eu estou sempre garantida ter pelo menos um
daqueles lê-se o mais de cópia atual dos dados.
É isso que faz DynamoDB consistente.
Agora você pode optar por ativar as leituras consistentes fora.
Caso em que eu vou dizer, Eu só vou ler de um nó.
E eu não posso garantir que vai a ser os dados mais atuais.
>> Assim, se uma gravação está chegando, que ainda não foi duplicado,
você está indo para obter essa cópia.
Essa é uma leitura eventualmente consistente.
E o que é que é metade do custo.
Então, isso é algo para se pensar.
Quando você está lendo fora DynamoDB, e você estiver configurando sua capacidade de leitura
unidades, se você escolher, eventualmente, leituras consistentes, é muito mais barato,
é cerca de metade do custo.
>> E assim você economiza dinheiro.
Mas essa é a sua escolha.
Se você quiser uma leitura consistente ou uma leitura eventualmente consistente.
Isso é algo que você pode escolher.
>> Vamos falar sobre índices.
Então, nós mencionamos que agregação de nível superior.
Temos chaves de hash, e temos chaves alcance.
Isso é bom.
E isso é sobre a mesa principal, I tem uma chave de hash, eu tenho uma chave intervalo.
>> O que isso significa?
Eu tenho um atributo que eu pode executar consultas contra ricos.
É a chave intervalo.
Os outros atributos em que item-- Eu posso filtrar esses atributos.
Mas eu não posso fazer coisas como, ele inicia-se com, ou é maior do que.
>> Como eu faço isso?
Eu criar um índice.
Há dois tipos de índices em DynamoDB.
Um índice é realmente outra visão da tabela.
E o índice secundário local.
>> O primeiro vamos falar sobre.
Então secundários locais são coexistiram na mesma partição como os dados.
E como tal, eles são sobre o mesmo nó físico.
Eles são o que chamamos consistente.
Significado, eles vão reconhecer a gravação, juntamente com a mesa.
Quando a gravação entra, vamos escrever através do índice.
Vamos escrever-se para a mesa, e depois vamos reconhecer.
Então, isso é consistente.
Uma vez que a escrita foi reconhecido a partir da tabela,
é garantido que o Índice secundária local
terá a mesma visão dos dados.
Mas o que eles permitem que você faz é definir chaves Faixa suplentes.
>> Tem que usar o mesmo hash chave como a tabela primária,
porque eles são co-localizado na mesma partição, e eles são consistentes.
Mas eu posso criar um índice com diferentes chaves de alcance.
Assim, por exemplo, se eu tivesse um fabricante que tinha uma tabela de peças em bruto chegando.
E peças brutas entrar, e eles estão agregados por montagem.
E talvez haja um recall.
>> Qualquer parte que foi feito por este fabricante após esta data,
Eu preciso puxar da minha linha.
Eu posso girar um índice que estaria olhando,
agregação na data de Fabricação de que parte particular.
Então, se minha mesa nível superior era já hash pelo fabricante,
talvez ele foi organizado em parte ID, I pode criar um índice que a tabela off
como hash pelo fabricante e variaram em data de fabricação.
E de que maneira eu poderia dizer, qualquer coisa que foi fabricado entre essas datas,
Eu preciso puxar a partir da linha.
Então, isso é um índice secundário local.
>> Estes têm o efeito de limitar o seu espaço de chave hash.
Porque eles coexistiram no mesmo nó de armazenamento,
eles limitam a chave de hash espaço de 10 gigabytes.
DynamoDB, sob a tabelas, particionará
sua mesa a cada 10 gigabytes.
Quando você colocar 10 GB de dados, nós ir [PHH], e nós adicionamos outro nó.
>> Nós não vamos dividir o LSI através de múltiplas partições.
Vamos dividir a tabela.
Mas não vamos dividir o LSI.
Então, isso é algo importante compreender
é se você está fazendo muito, muito, muito grandes agregações,
então você vai ser limitado 10 gigabytes em seu LSIs.
>> Se for esse o caso, nós podemos usar secundários globais.
Secundários globais são realmente outra mesa.
Eles existem completamente fora de o lado de sua tabela primária.
E eles me permita encontrar uma estrutura completamente diferente.
Então, pense nisso como os dados estão sendo inseridas em duas tabelas diferentes, estruturado
de duas maneiras diferentes.
>> Posso definir um totalmente diferente chave de hash.
Posso definir um totalmente diferente chave de gama.
E eu posso executar este de forma totalmente independente.
Por uma questão de fato, eu tenho provisionados minha capacidade de leitura
e capacidade para escrever meu índices secundários globais
de forma totalmente independente da minha tabela primária.
Se eu definir esse índice, digo- ele o quanto ler e escrever
capacidade que ela vai estar usando.
>> E que é separado da minha mesa principal.
Agora, tanto dos índices nos permitir não só definem chaves de hash e alcance,
mas eles nos permitem projetar valores adicionais.
Então, se eu quero ler fora do índice, e eu quero obter um conjunto de dados,
Eu não preciso de voltar para o principal mesa para obter os atributos adicionais.
Eu posso projetar os adicional atributos na tabela
para suportar o padrão de acesso.
Eu sei que provavelmente está se metendo alguns realmente, realmente-- metendo as ervas daninhas
aqui em algumas dessas coisas.
Agora eu tenho a deriva fora deste.
>> AUDIÊNCIA: [inaudível] chave --table quis dizer foi um hash?
O hash original?
Multi-slats?
>> RICK HOULIHAN: Sim.
Sim.
A chave tabela, basicamente, aponta para o item.
Assim, um índice é um ponteiro de volta para os itens originais na mesa.
Agora você pode optar por construir um índice que só tem a chave da tabela,
e há outras propriedades.
E por que eu poderia fazer isso?
Bem, talvez eu tenha muito grandes itens.
>> Eu realmente só precisa saber which-- meu padrão de acesso pode dizer,
os itens que contêm essa propriedade?
Não precisa devolver o item.
Eu só preciso saber os itens que contê-lo.
Assim, você pode criar índices que só tem a chave da tabela.
>> Mas isso é principalmente o que um índice no banco de dados é para.
É para ser capaz de rapidamente identificar quais registros,
quais linhas, que itens na tabela tem
as propriedades que eu estou procurando.
>> GSIS, então como eles funcionam?
GSIS basicamente são assíncronas.
A atualização vem para a mesa, tabela é atualizada em seguida, de forma assíncrona
todo o seu GSIS.
É por isso que são GSIS eventualmente, consistente.
>> É importante notar que, quando você está construindo GSIS,
e você entender que você está criando outra dimensão da aggregation--
Agora, vamos dizer que um bom exemplo aqui é um fabricante.
Eu acho que eu poderia ter falado sobre um fabricante de dispositivos médicos.
Fabricantes de dispositivos médicos muitas vezes têm partes serializados.
As peças que entram em uma substituição da anca tudo
ter um pouco de número de série neles.
E eles poderiam ter milhões e milhões e bilhões de peças
em todos os dispositivos que elas trazem.
Bem, eles precisam agregar sob diferentes dimensões, todas as peças
em uma montagem, todo o partes que foram feitas
em uma determinada linha, todos as peças que vieram
a partir de um determinado fabricante em uma determinada data.
E, por vezes, estas agregações levantar-se em casa dos bilhões.
>> Então, eu trabalho com alguns dos esses caras que estão sofrendo
porque eles estão criando estas agregações ginormous
em seus índices secundários.
Eles podem ter uma peças de matérias- tabela que vem como única de hash.
Cada parte tem um número de série único.
Eu uso o número de série como o hash.
É lindo.
Minha tabela de dados brutos é espalhada em todo o espaço da chave.
Minhas [? Escreva ?] [? ingestão?] é incrível.
Eu tomo um monte de dados.
Então o que eles fazem é criar um GSI.
E eu digo, você sabe o quê, eu preciso ver todas as partes para este fabricante.
Bem, de repente eu sou tendo um bilhão de linhas,
e enchê-los para um nó, porque quando
I agregar como o ID fabricante como o hash,
e número da peça como o intervalo, em seguida, de repente eu sou
colocar um bilhão de partes em que este fabricante tem me entregue.
>> Isso pode causar uma série de pressão sobre o GSI,
novamente, porque estou martelando um nó.
Estou colocando todos estes insere um nó.
E isso é um caso de uso problemático real.
Agora, eu tenho um bom design padrão de como você evitar isso.
E isso é um dos problemas que eu sempre trabalhar.
Mas o que acontece, é a GSI pode não tem capacidade de gravação suficiente
para ser capaz de empurrar todos aqueles linhas em um único nó.
E o que acontece em seguida é a primário, a tabela de cliente,
tabela primária será estrangulada porque o GSI não pode manter-se.
Assim, a minha taxa de inserção vai cair sobre a mesa principal
como meu GSI tenta manter-se.
>> Tudo bem, então GSI de, LSI de, qual deles devo usar?
LSI de são consistentes.
GSI de, eventualmente, são consistentes.
Se isso é OK, eu recomendo usar um GSI, eles são muito mais flexíveis.
LSI de pode ser modelado como um GSI.
E se o tamanho dos dados por chaves hash em sua coleção seja superior a 10 gigabytes,
então você vai querer usar isso GSI porque é apenas um limite rígido.
>> Tudo bem, então escala.
Rendimento no Dynamo DB, você prestação lata [inaudível]
throughput para uma mesa.
Temos clientes que têm provisionado 60 billion--
está fazendo 60 bilhões de pedidos, regularmente rodando a mais de um milhão pedidos
por segundo em nossas mesas.
Não há realmente nenhuma limite teórico de quanto
e quão rápido a mesa pode ser executado no Dynamo DB.
Há alguns suave limites na sua conta
que nós colocamos lá, então que você não enlouquecer.
Se você quer mais do que que, não um problema.
Você vem dizer-nos.
Vamos transformar-se no mostrador.
>> Cada conta é limitado a um certo nível em todos os serviços, apenas fora do bastão
para que as pessoas não enlouquecer se metem em problemas.
Não há limite de tamanho.
Você pode colocar qualquer número de itens em uma tabela.
O tamanho de um item é limitada a 400 quilobytes cada,
que seria item não os atributos.
Assim, a soma de todos os atributos está limitado a 400 kilobytes.
E então, novamente, temos esse pequeno problema LSI
com o limite de 10 gigabyte por hash.
AUDIÊNCIA: número pequeno, eu estou faltando o que você está me dizendo, que é--
AUDIÊNCIA: Oh, 400 kilobytes é o tamanho máximo por item.
Assim, um item tem todos os atributos.
Então, 400 K é o tamanho total desse item, 400 kilobytes.
Assim, de todos os atributos combinados, todos os dados
que está em todos esses atributos, enrolado em um tamanho total,
Atualmente o limite de itens hoje é de 400 k.
Assim dimensionamento novamente, conseguida através de particionamento.
O throughput é provisionado no nível da tabela.
E não há realmente dois botões.
Temos capacidade de leitura e escrever capacidade.
>> Então, essas são ajustados independentemente um do outro.
Medida do estritamente RCU leituras consistentes.
OK, então se você está dizendo que eu quero 1000 RCU de esses são estritamente consistente,
estas são as leituras consistentes.
Se você disser que eu quero eventual leituras consistentes,
você pode provisionar 1000 RCU do, você vai
para obter, eventualmente, 2000 leituras consistentes.
E metade do preço para aqueles eventualmente, consistem em lê.
>> Mais uma vez, ajustada independentemente um do outro.
E eles têm o throughput-- Se você consumir 100% do seu RCU,
você não vai ter impacto no disponibilidade de seus direitos.
Então, eles estão completamente independentes uns dos outros.
Tudo bem, então uma das coisas que Mencionei brevemente foi estrangulamento.
Estrangulamento é ruim.
Estrangulamento indica mau não SQL.
Há coisas que podemos fazer para ajudá- você aliviar o estrangulamento que você
está enfrentando.
Mas a melhor solução para isso é, vamos dar
um olhar para o que você está fazendo, porque há um anti-padrão em jogo aqui.
>> Essas coisas, coisas como não-uniforme cargas de trabalho, teclas de atalho, divisórias quentes.
Eu estou batendo um espaço de chave em particular muito difícil por algum motivo particular.
Por que estou fazendo isso?
Vamos descobrir isso.
Eu estou misturando meus dados quentes com dados frios.
Eu estou deixando minhas tabelas chegar enorme, mas não há realmente
apenas algumas subconjunto dos dados que é realmente interessante para mim.
Assim, para os dados de log, por exemplo, uma grande quantidade de clientes, que recebem os dados de registro a cada dia.
Eles têm uma enorme quantidade de dados de registro.
>> Se você está apenas despejar tudo o que log dados em uma grande mesa, ao longo do tempo
que a tabela vai ficar enorme.
Mas eu estou realmente interessado apenas em últimas 24 horas, nos últimos sete dias,
nos últimos 30 dias.
Seja qual for a janela de tempo que eu estou interessado em olhar
para o evento que me incomoda, ou o evento que é interessante para mim,
essa é a única vez que a janela que eu preciso.
Então por que estou colocando 10 anos vale de dados de registro na tabela?
O que faz com que é a tabela de fragmento.
>> Ele fica enorme.
Ele começa a se espalhar para fora através de milhares de nós.
E uma vez que a sua capacidade é tão baixo, você é
na verdade, em cada taxa de limitar um desses nodos individuais.
Então, vamos começar olhando como nós rolar aquela mesa.
Como podemos gerenciar esses dados um pouco melhor evitar estes problemas.
E o que isso parece?
Isto é o que parece.
Isto é o que mau NoSQL parece.
>> Eu tenho uma tecla de atalho aqui.
Se você olhar para o lado aqui, estas são todas as minhas partições.
Eu tenho 16 partições-se aqui nesse banco de dados particular.
Fazemos isso o tempo todo.
Eu corro isto para clientes todos os tempos.
É o chamado mapa de calor.
Mapa de calor me diz como você é acessando seu espaço chave.
E o que isso está me dizendo é que há um hash de especial
que esse cara gosta de uma lote terrível, porque ele é
batê-lo muito, muito difícil.
>> Assim, o azul é bom.
Nós gostamos azul.
Nós não gostamos de vermelho.
Onde a pressão da Red levanta-se a 100%.
100%, agora você vai ser estrangulado.
Assim, sempre que você ver todas as linhas vermelhas, como isto-- e não é apenas Dynamo DB--
cada banco de dados NoSQL tem este problema.
Há anti-padrões que podem conduzir estes tipos de condições.
O que eu faço é trabalhar com os clientes para aliviar essas condições.
>> E o que isso parece?
E isso está ficando mais Fora do Dynamo DB rendimento,
mas é realmente ficando o máximo de NoSQL.
Este não é restrita a dínamo.
Este é definitely-- I costumava trabalhar no Mongo.
Eu estou familiarizado com muitas plataformas NoSQL.
Cada um tem esses tipos de problemas de teclas de atalho.
Para tirar o máximo proveito de qualquer NoSQL banco de dados, especificamente Dynamo DB,
você deseja criar as tabelas onde o elemento chave de hash tem
um grande número de valores distintos, um elevado grau de cardinalidade.
Porque isso significa que eu estou escrevendo para os lotes de diferentes baldes.
>> Os mais baldes que eu sou escrever para, o mais provável
Eu sou a espalhar a carga de gravação ou leia carregar para fora através de vários nós,
o mais provável que eu estou a ter um alto rendimento sobre a mesa.
E então eu quero que os valores a serem solicitadas de forma bastante equilibrada ao longo do tempo
e uniforme quanto possível de forma aleatória.
Bem, isso é bem interessante, porque eu não posso realmente
controle quando os usuários vêm.
Então, basta dizer que, se espalhar coisas para fora em todo o espaço da chave,
provavelmente vamos estar em melhor forma.
>> Há um certo quantidade de tempo de entrega
que você não vai para ser capaz de controle.
Mas esses são realmente o duas dimensões que temos,
espaço, o acesso uniformemente propagação, tempo, pedidos
que chegam uniformemente espaçados no tempo.
E se aqueles dois condições estão a ser cumpridas,
em seguida, que é o que é vai parecer.
Este é muito mais agradável.
Estamos muito felizes aqui.
Temos um padrão de acesso muito mesmo.
Sim, talvez você está recebendo um pouca pressão de vez em quando,
mas nada realmente muito extensa.
Por isso, é incrível como muitas vezes, quando eu trabalho com os clientes,
que primeiro gráfico com o vermelho grande bar e tudo o que feio amarelo é
em todo o lugar, nós ter feito com o exercício
depois de um par de meses de re-arquitetura,
eles estão executando exatamente o mesmo carga de trabalho com a mesma carga exata.
E isso é o que está parecendo agora.
Então, o que você ganha com NoSQL é um esquema de dados que é absolutamente
amarrado ao padrão de acesso.
>> E você pode otimizar o esquema de dados para suportar esse padrão de acesso.
Se você não fizer isso, então você está indo para ver esses tipos de problemas
com essas teclas de atalho.
>> AUDIÊNCIA: Bem, inevitavelmente, alguns lugares vai ser mais quente do que outros.
>> RICK HOULIHAN: Sempre.
Sempre.
Sim, quero dizer, há sempre um-- e, novamente, há
alguns padrões de design nós vamos passar por que vai falar sobre como você lida
com estas super-grandes agregações.
Quer dizer, eu tenho que tê-los, como vamos lidar com eles?
I got um bom caso de uso que nós vamos falar sobre por que.
>> Tudo bem, então vamos falar sobre alguns clientes agora.
Esses caras são AdRoll.
Eu não sei se você é familiarizados com AdRoll.
Você provavelmente vê-los muito no browser.
Eles são re-segmentação de anúncios, eles são o maior negócio ad re-segmentação
lá fora.
Eles normalmente executado regularmente durante 60 bilhões de transações por dia.
Eles estão fazendo mais de um milhão transações por segundo.
Eles tem uma tabela muito simples estrutura, a tabela mais movimentado.
É basicamente apenas um chave hash é o cookie,
o intervalo é o grupo demográfico categoria, e em seguida,
o terceiro atributo é a pontuação.
>> Portanto, todos nós temos biscoitos em nosso navegador a partir desses eles.
E quando você vai a um comerciante participante,
eles basicamente marcar você em frente várias categorias demográficas.
Quando você vai para um site e você diz que eu quero ver isso AD--
ou, basicamente, você não diz que-- mas quando você vai para o site
eles dizem que você quer ver este anúncio.
E eles vão obter esse anúncio de AdRoll.
AdRoll te olha de cima em sua mesa.
Eles encontrar o seu cookie.
Os anunciantes dizem eles, eu quero alguém
que é de meia-idade, Homem de 40 anos de idade, em esportes.
E eles marcarem você nesses dados demográficos e eles decidir se quer ou não
isso é um bom anúncio para você.
>> Agora eles têm um SLA com seus provedores de publicidade
para proporcionar sub-10 milissegundo resposta a cada requisição.
Então, eles estão usando Dynamo DB para isso.
Eles estão nos a bater milhão de pedidos por segundo.
Eles são capazes de fazer toda a sua pesquisas, triagem todos os dados,
e obter esse link adicionar de volta para que anunciante em menos de 10 milissegundos.
É realmente fenomenal aplicação que eles têm.
>> Esses caras actually-- são estes os caras.
Eu não tenho certeza se é esses caras.
Pode ser esses caras.
Basicamente disse US-- não, eu não acho que foram eles.
Acho que foi outra pessoa.
Eu estava trabalhando com um cliente que me disse
que, agora que eles têm ido para Dynamo DB, eles são
gastar mais dinheiro em lanches para sua equipe de desenvolvimento a cada mês
do que gastam em seu banco de dados.
Por isso, vamos dar-lhe um idéia da redução de custos
que você pode obter no Dynamo DB é enorme.
Tudo bem, Dropcam é outra empresa.
Estes cara é tipo de-- se você pensa de internet das coisas, Dropcam
é basicamente vídeo de segurança internet.
Você coloca sua câmera para fora lá.
Câmara tem um detector de movimento.
Alguém vem junto, desencadeia um ponto de sinalização.
Câmara começa a gravar por um tempo até ele não detecta qualquer movimento mais.
Coloca-se que o vídeo na internet.
>> Dropcam era uma empresa que é basicamente ligado ao Dínamo DB
porque eles estavam experimentando enormes dores de crescimento.
E o que eles nos disseram, de repente petabytes de dados.
Eles não tinham idéia seu serviço seria tão bem sucedido.
Mais do que de entrada de vídeo YouTube é o que esses caras estão ficando.
Eles usam DynamoDB para acompanhar todo o metadados em todos os seus pontos-chave de vídeo.
>> Então eles têm baldes S3 eles empurram todos os artefatos binários em.
E então eles têm Registros Dynamo DB que
apontar as pessoas para essas S3 três objetos.
Quando eles precisam de olhar para um vídeo, eles olham-se o registro no Dynamo DB.
Eles clicam no link.
Eles puxar para baixo o vídeo do S3.
Então, isso é o tipo do que isto parece.
E isto é em linha reta de sua equipe.
>> Dynamo DB reduz a sua tempo de entrega para eventos de vídeo
de cinco a 10 segundos.
Em sua loja relacional de idade, eles costumavam ter que ir e executar
várias consultas complexas a figura quais vídeos para puxar para baixo,
para menos de 50 milissegundos.
Por isso é incrível, incrível o quanto de desempenho
você pode começar quando você otimizar e você sintonizar o banco de dados subjacente
para suportar o padrão de acesso.
Halfbrick, esses caras, o que é, Fruit Ninja eu acho que é a sua coisa.
Que todas as corridas em Dynamo DB.
E esses caras, eles são uma ótima equipe de desenvolvimento, grande desenvolvimento
loja.
>> Não é uma boa equipe de operações.
Eles não têm muito de recursos de operação.
Eles estavam lutando tentando manter sua infra-estrutura de aplicação up
e em execução.
Eles vieram até nós.
Eles olharam para que Dynamo DB.
Eles disseram, isso é para nós.
Eles construíram seu todo estrutura de aplicativos nele.
Alguns muito bons comentários aqui da equipe em sua capacidade
agora se concentrar no edifício o jogo e não
ter de manter o infra-estrutura, o que
estava se tornando uma enorme quantidade de sobrecarga para sua equipe.
Então, isso é algo que-- o benefício que você começa a partir Dynamo DB.
>> Tudo bem, metendo modelagem de dados aqui.
E nós conversamos um pouco sobre este 1-1, um para muitos,
e muitos para muitos relacionamentos de tipo.
E como você manter aqueles na Dynamo.
Em Dynamo DB usamos índices, de um modo geral,
para rodar os dados a partir de um sabor para o outro.
Chaves de hash, chaves de gama, e índices.
>> Nesse particular exemplo, como a maioria dos estados
tem uma exigência de licenciamento que apenas a licença de motorista de um por pessoa.
Você não pode ir para obter duas motorista licenças no estado de Boston.
Eu não posso fazê-lo no Texas.
Esse é um tipo da maneira que é.
E assim no DMV, temos pesquisas, nós quero olhar para cima a carteira de motorista
pelo número de segurança social.
Eu quero olhar-se os detalhes do usuário pelo número da carteira de motorista.
>> Assim, poderíamos ter uma mesa do usuário que tem uma chave de hash no número de série,
ou o número de segurança social, e vários atributos definido no item.
Agora, naquela mesa I poderia definir um GSI que
flips que cerca que diz que eu quero uma chave de hash na licença e, em seguida,
todos os outros itens.
Agora, se eu deseja consultar e encontrar o número de licença para qualquer Sociais
Número de segurança, eu posso consultar a tabela principal.
>> Se eu quiser consultar e eu quero para obter a segurança social
número ou outros atributos por um número da licença, posso consultar o GSI.
Esse modelo é que um a uma relação.
Apenas uma forma muito simples GSI, virar as coisas ao redor.
Agora, falar sobre um para muitos.
Um para muitos é, basicamente, sua chave gama hash.
Onde temos um monte com este caso de uso é dados do monitor.
Monitor de dados vem em comum intervalo, como internet das coisas.
Nós sempre obter todos estes registos vindo em todo o tempo.
>> E eu quero encontrar todas as leituras entre um determinado período de tempo.
É uma consulta muito comum em infra-estrutura de monitoramento.
A maneira de ir sobre isso é encontrar um estrutura de tabela simples, uma mesa.
Eu tenho uma tabela de medições do dispositivo com uma chave de hash sobre a identificação do dispositivo.
E eu tenho uma chave intervalo na timestamp, ou neste caso, o épico.
E isso permite-me executar complexo consultas em que a chave gama
e retornar os registros que são em relação ao resultado
definir que eu estou procurando.
E ele constrói que um para muitos relação
na tabela usando o primário chave de hash, estrutura de chave intervalo.
>> Então, esse é o tipo de construção na tabela da Dynamo DB.
Quando eu definir um hash e mesa de gama t, eu sou
a definição de uma relação um para muitos.
É uma relação pai-filho.
>> Vamos falar sobre muitos para muitos relacionamentos.
E para este exemplo particular, novamente, nós vamos usar GSI de.
E vamos falar sobre o jogo cenário onde eu tenho um determinado usuário.
Eu quero descobrir todos os jogos que ele está registrado para ou jogar em.
E para um determinado jogo, eu quer encontrar todos os utilizadores.
Então, como posso fazer isso?
Minha tabela de jogos do usuário, eu vou para ter uma chave de hash de ID do usuário
e uma chave intervalo do jogo.
>> Assim, um usuário pode ter vários jogos.
É uma relação um para muitos entre o usuário e os jogos que ele joga.
E em seguida, no GSI, Eu vou virar essa volta.
Vou botar no jogo e Vou variar sobre o usuário.
Então, se eu quiser obter todas as jogo o usuário de jogar em,
Vou consultar a tabela principal.
Se eu quiser obter todos os usuários que estão jogando um jogo particular,
Eu consultar o GSI.
Assim você ver como vamos fazer isso?
Você constrói a apoiar estes do GSI o caso de uso, o aplicativo, o acesso
teste padrão, o aplicativo.
>> Se eu precisar consultar on esta dimensão, deixe-
me criar um índice em que dimensão.
Se eu não fizer isso, eu não me importo.
E, dependendo do caso de uso, I pode precisar o índice ou eu não poderia.
Se é um simples um para muitos, da tabela primária é bom.
Se eu preciso fazer estes muitos a muitos de, ou eu preciso fazer um para queridos,
então talvez eu preciso a segunda no índice.
Então, tudo depende o que eu estou tentando fazer
eo que eu estou tentando obter realizado.
>> Provavelmente eu não vou gastar muito muito tempo falando sobre documentos.
Isto torna-se um pouco, provavelmente, mais profundo do que precisamos para entrar.
Vamos falar um pouco expressão de consulta sobre a rica.
Assim, no Dynamo DB temos a capacidade de criar
o que chamamos de expressões de projeção.
Projeção expressões são simplesmente escolher os campos ou os valores
que você deseja exibir.
OK, então eu fazer uma seleção.
Eu faço uma consulta contra Dynamo DB.
E eu digo, você sabe o que, mostra me apenas os cinco estrelas comentários
para este produto particular.
Então, isso é tudo que eu quero ver.
Eu não quero ver todas as outros atributos da linha,
Eu só quero ver isso.
É como quando você em SQL dizer selecione estrela ou de mesa,
você começa tudo.
Quando eu digo selecione o nome de mesa, eu só obter um atributo.
É o mesmo tipo de coisa em Dynamo DB ou mais bancos de dados NoSQL.
As expressões de filtro permita-me basicamente cortar o conjunto de resultados para baixo.
Então eu faço uma consulta.
Consulta pode voltar com 500 itens.
Mas eu só quero os itens que tem um atributo que diz isso.
OK, então vamos filtrar esses itens que não correspondem a essa consulta particular.
Então nós temos expressões de filtro.
>> As expressões de filtro pode ser executado em qualquer atributo.
Eles não são como consultas por abrangência.
Levantar questões são mais seletivos.
Consultas de filtro de me obrigar a ir se os resultados inteiros definir e, em seguida
esculpir os dados que eu não quero.
Por que isso é importante?
Porque eu li tudo.
Em uma consulta, eu vou ler e ele vai ser um gigante sobre os dados.
E então eu vou esculpir o que eu preciso.
E se eu só estou conquistando um par de linhas, então isso é OK.
Não é tão ineficiente.
>> Mas se eu estou lendo uma pilha de dados, só para esculpir um item,
então eu vou ser melhor fora de usar uma consulta de gama,
porque é muito mais seletivo.
Ele vai me salvar um monte de dinheiro, porque eu pagar por essa leitura.
Sempre que os resultados que vem de volta cruzar essa fio pode ser menor,
mas eu estou pagando para a leitura.
Assim, entender como você está recebendo os dados.
Isso é muito importante na Dynamo DB.
>> As expressões condicionais, isto é o que você poderia chamar de bloqueio otimista.
Atualização se existe, ou se esse valor é equivalente ao que eu especificar.
E se eu tiver um carimbo de tempo em um registro, eu poderia ler os dados.
Eu poderia mudar esses dados.
Eu poderia ir gravação que dados de volta para o banco de dados.
Se alguém mudou o registro, o timestamp poderia ter mudado.
E de que maneira a minha condicional atualização poderia dizer actualização
Se a data e hora é igual a este.
Ou a atualização falhará porque alguém atualizou o registro no mesmo período.
>> Isso é o que chamamos de bloqueio otimista.
Isso significa que alguém pode entrar e mudá-lo,
e eu estou indo para detectá-lo quando eu voltar a escrever.
E então eu posso realmente ler que dados e dizer, oh, ele mudou isso.
Eu preciso explicar isso.
E eu posso mudar os dados na minha gravar e aplicar outra atualização.
Então você pode pegar aqueles incrementais atualizações que ocorrem entre o momento
que você lê os dados ea tempo você pode gravar os dados.
>> AUDIÊNCIA: E o filtro expressão, na verdade, não significa
no número ou não--
>> [Interpondo VOZES]
RICK HOULIHAN: Eu não vou obter muito para isso.
Esta é uma palavra-chave reservada.
A vista é uma libra reservados palavra-chave no Dynamo DB.
Cada banco de dados tem sua própria reservados nomes para as coleções que você não pode usar.
Dynamo DB, se você especificar uma libra na frente desta,
você pode definir os nomes acima.
Este é um valor de referência.
Provavelmente não é o melhor para sintaxe tem lá em cima para esta discussão,
porque ele recebe em alguns real-- Eu teria falado mais
sobre isso em um nível mais profundo.
>> Mas basta dizer, isso poderia ser consulta digitalizar onde views--
nem libra vista é superior a 10.
É um valor numérico, sim.
Se você quiser, podemos falar sobre que, após a discussão.
Tudo bem, então estamos entrando em alguns cenários em melhores práticas
onde nós estamos indo falar sobre alguns aplicativos aqui.
Quais são os casos de uso para Dynamo DB.
O que são o design padrões em Dynamo DB.
>> E o primeiro que vamos falar é a internet das coisas.
Então nós temos um monte de-- eu acho, o que é mais do que ele-- 50%
de tráfego na internet nos dias de hoje é na verdade gerado por máquinas,
processos automatizados, não por seres humanos.
Quero dizer esta coisa essa coisa que você carrega no seu bolso,
quantos dados que essa coisa é realmente enviando ao redor sem você
sabendo que é absolutamente incrível.
Sua localização, informações sobre o quão rápido você está indo.
Como você acha que o Google Maps funciona quando lhe dizem que o tráfego é.
É porque existem milhões e milhões de pessoas em torno de condução
com os telefones que estão enviando dados em todo lugar o tempo todo.
Então, uma das coisas sobre este tipo de dados
que vem em, dados do monitor, ingresse dados, dados de séries temporais, é que é
geralmente só é interessante para um pouco de tempo.
Após esse tempo, é não é tão interessante.
Então nós conversamos sobre, não deixe essas tabelas crescer sem limites.
A idéia aqui é que talvez eu tenha 24 horas no valor de acontecimentos na minha mesa quente.
E que mesa quente vai ser provisionados em uma taxa muito alta,
porque ele está tomando um monte de dados.
Está levando um monte de dados e eu estou lendo muito.
Eu tenho um monte de operação consultas que executam em relação a esses dados.
>> Após 24 horas, hey, você sabe, eu não me importo.
Então, talvez eu rolo cada meia-noite sobre minha mesa para uma nova tabela
e eu desprovisione esta tabela.
E eu vou levar da RCU e Para baixo do WCU porque 24 horas depois
Eu não estou correndo como muitos consultas em que os dados.
Então, eu estou indo para poupar dinheiro.
E talvez 30 dias mais tarde, eu não ainda precisa se preocupar com tudo.
Eu poderia assumir a WCU de todo o caminho para um,
porque você sabe o que, é Nunca vai ficar gravado.
Os dados são de 30 dias de idade.
Ele nunca muda.
>> E é quase nunca vai conseguir ler, então vamos ter que RCU para 10.
E eu estou economizando uma tonelada de dinheiro com isso dados, e só pagando por meus dados quentes.
Então essa é a coisa importante é olhar em quando você olha para uma série temporal
dados entrando em volume.
Estas são estratégias.
Agora, eu poderia simplesmente deixá-lo vão todos para a mesma tabela
e deixe que a tabela crescer.
Eventualmente, eu vou ver problemas de desempenho.
Eu vou ter que começar a arquivar alguns desses dados para fora da mesa,
que não.
>> Vamos muito melhor projetar seu aplicativo
para que você possa operar este caminho certo.
Então é só automática no código do aplicativo.
À meia-noite todas as noites rola a tabela.
Talvez o que eu preciso é de um deslizamento janela de 24 horas de dados.
Em seguida, em uma base regular que eu sou chamando de dados fora da mesa.
Eu estou cortando-o com uma Cron trabalho e eu estou colocando-
para estes quadros, o que você precisar.
Portanto, se um rollover trabalha, isso é ótimo.
Se não, cortá-la.
Mas vamos manter os dados quente longe de seus dados frios.
Ele vai te salvar um monte de dinheiro e fazer suas tabelas mais desempenho.
Portanto, a próxima coisa que vou falar é cerca de catálogo de produtos.
Catálogo dos produtos é caso de uso bastante comum.
Este é realmente um padrão muito comum que vamos ver em uma variedade de coisas.
Você sabe, para Twitter exemplo, um tweet quente.
Todo mundo está vindo e agarrando que tweet.
Catálogo dos produtos, eu tenho uma venda.
Eu tenho uma venda quente.
Eu tenho 70.000 pedidos por segunda vinda de um produto
descrição do meu catálogo de produtos.
Vemos isso no varejo operação um pouco.
Então, como vamos lidar com isso?
Não há nenhuma maneira de lidar com isso.
Todos os meus usuários querem ver o mesmo pedaço de dados.
Eles estão estão chegando, simultaneamente.
E eles estão todos fazendo pedidos para o mesmo pedaço de dados.
Isso me dá a chave quente, que grande e vermelho listra no meu gráfico que nós não gostamos.
E isso é o que parece.
Assim, em toda a minha tecla espaço que estou recebendo martelado nos itens de venda.
Estou recebendo nada em qualquer outro lugar.
>> Como faço para aliviar este problema?
Bem, nós aliviar esta com cache.
Cache, você coloca basicamente um in-memory partição na frente da base de dados.
Conseguimos [Inaudível] cache, como você
pode configurar o seu próprio cache, [inaudível] cache de [? d,?] o que quiser.
Ponha isso na frente do banco de dados.
E de que maneira você pode armazenar esses dados a partir dessas teclas de atalho para cima em que o cache
espaço e ler o cache.
>> E então a maioria de suas leituras começar a olhar como este.
Eu tenho todos estes cache de bate-se aqui e eu não tenho nada acontecendo aqui
porque banco de dados está sentado atrás do cache e não a lê passar.
Se eu mudar os dados na banco de dados, eu tenho que atualizar o cache.
Podemos usar algo como vapores de fazer isso.
E eu vou explicar como isso funciona.
Tudo bem, messaging.
E-mail, todos nós usamos e-mail.
>> Este é um bom exemplo.
Temos algum tipo de tabela de mensagens.
E nós temos caixa de entrada e caixa de saída.
Isto é o que o faria SQL Look Like a construir essa caixa de entrada.
Nós tipo de usar o mesmo tipo da estratégia de usar GSI de, GSI de
para minha caixa de entrada e minha caixa de saída.
Então, eu tenho mensagens de matérias-vindo em minha tabela de mensagens.
E a primeira abordagem a este pode ser, digamos, OK, não há problema.
Eu tenho mensagens matérias.
Mensagens provenientes [inaudível], mensagem de ID, isso é ótimo.
Esse é o meu hash exclusivo.
Eu vou criar dois GSI de, um para minha caixa de entrada, uma para minha caixa de saída.
E a primeira coisa que vou fazer é que eu vou dizer a minha chave de hash é
vai ser o destinatário e Vou organizar na data.
Isso é fantástico.
Eu tenho a minha bela vista aqui.
Mas há um pequeno problema aqui.
E você tiver isso em bases de dados relacionais bem.
Eles chamado de particionamento vertical.
Você deseja manter seus dados grande longe de seus dados pequenos.
>> E a razão por que é porque eu tenho que vá ler os itens de obter os atributos.
E se meus corpos estão todos aqui, depois de ler apenas alguns itens
se o meu comprimento do corpo é média 256 quilobytes cada,
a matemática fica muito feio.
Então, digamos que eu quero ler caixa de entrada de David.
Caixa de entrada de David tem 50 itens.
A média eo tamanho é de 256 kilobytes.
Aqui está a minha taxa de conversão para RCU é de quatro kilobytes.
>> OK, vamos com leituras eventualmente consistentes.
Eu ainda estou comendo 1600 RCU do só para ler caixa de entrada de David.
Ouch.
OK, agora vamos pensar sobre como o aplicativo funciona.
Se eu estou em um aplicativo de e-mail e Eu estou olhando para minha caixa de entrada,
e eu olhar para o corpo de cada mensagem, não, eu estou olhando para os resumos.
Eu estou olhando apenas os cabeçalhos.
Então, vamos construir uma estrutura de tabela que se parece mais com isso.
>> Então aqui está a informação que o meu fluxo de trabalho precisa.
Está na minha caixa de entrada GSI.
É a data, o remetente, o assunto e, em seguida,
a identificação da mensagem, que aponta de volta para a tabela de mensagens
onde posso obter o corpo.
Bem, estes seriam IDs de registro.
Eles iriam apontar de volta para o IDs de item na tabela de Dynamo DB.
Cada índice sempre creates-- sempre tem o item
ID como parte de-- que vem com o índice.
>> Tudo certo.
AUDIÊNCIA: Diz-lo onde ele é armazenado?
RICK HOULIHAN: Sim, diz- exactly-- isso é exatamente o que ele faz.
Diz aqui é o meu recorde re.
E vai apontá-lo de volta para o meu recorde re.
Exatamente.
OK, então agora é minha caixa de entrada na verdade, muito menor.
E isso realmente suporta o fluxo de trabalho de um aplicativo de e-mail.
Assim, a minha caixa de entrada, eu clicar.
Eu ir junto e eu clicar sobre a mensagem, que é quando eu preciso ir buscar o corpo,
porque eu vou ir para uma visão diferente.
Então, se você pensar sobre o tipo de MVC quadro, controlador de vista do modelo.
>> O modelo contém a dados que a visão necessidades
e o controlador interage com.
Quando eu mudar o quadro, quando Eu mudar a perspectiva,
que é OK para voltar ao servidor e repovoar o modelo,
porque é o que o usuário espera.
Quando mudar de vista, que é quando nós podemos ir de volta para o banco de dados.
Então e-mail, clique em.
Eu estou olhando para o corpo.
Ida e volta.
Vá buscar o corpo.
>> Eu leio muito menos dados.
Eu só estou lendo os corpos que David precisa de quando ele precisa deles.
E eu não estou queimar em 1600 RCU é só para mostrar a sua caixa de entrada.
Então agora isso-- este é o caminho que LSI ou GSI-- Sinto muito,
GSI, daria certo.
Nós temos nossa haxixe no destinatário.
Nós temos a chave gama na data.
E nós temos os atributos projectados que precisamos apenas para apoiar a visão.
>> Nós girar para que a caixa de saída.
Hash no remetente.
E, em essência, temos a, vista limpo muito agradável.
E é que basically-- tem este agradável mensagens
tabela que está sendo espalhado bem porque é hash somente, hash ID mensagem.
E nós temos dois índices que estão girando fora do referido quadro.
Tudo bem, então idéia aqui não é fazer manter os grandes dados e este pequeno dados
junto.
Particionar verticalmente, particionar essas tabelas.
Não leia dados que você não tem que.
Tudo bem, jogo.
Nós todos gostamos de jogos.
Pelo menos eu gosto de jogos depois.
Assim, algumas das coisas que lidar com quando
nós estamos pensando sobre o jogo, certo?
Jogos nestes dias, especialmente móvel jogo, é tudo sobre o pensamento.
E eu estou indo para rodar aqui um pouco longe DynamoDB.
Vou trazer a discussão de alguns
em torno de alguns dos outras tecnologias da AWS.
>> Mas a idéia sobre o jogo é pensar sobre em termos de APIs, APIs que são,
de um modo geral, HTTP e JSON.
É como jogos para celular tipo de interagir com suas extremidades traseiras.
Eles fazem JSON postagem.
Eles ficam de dados, e é tudo, de um modo geral, em Nice APIs JSON.
>> Coisas como fazer amigos, obter os dados leaderboard, câmbio,
conteúdo gerado por usuários, empurre de volta para o sistema,
estes são os tipos de coisas que nós vamos fazer.
Dados de ativos binário, estes dados pode não se sentar no banco de dados.
Isso pode sentar-se em um armazenamento de objeto, certo?
Mas o banco de dados vai acabam dizendo ao sistema,
contando a aplicação onde ir buscá-la.
E, inevitavelmente, para múltiplos jogadores servidores, infra-estrutura de back-end,
e projetado para alta disponibilidade e escalabilidade.
Então, essas são as coisas que todos nós queremos na infra-estrutura do jogo hoje.
>> Então, vamos dar uma olhada o que parece.
Obteve um back-end núcleo, muito simples.
Nós temos um sistema aqui com múltiplas zonas de disponibilidade.
Nós conversamos sobre como AZs being-- pensar deles como centros de dados separados.
Mais de um centro de dados por AZ, mas isso é OK,
basta pensar-los como dados separado centros que estão geograficamente
e falha isolada.
>> Nós vamos ter um instâncias EC2 casal.
Nós vamos ter algum servidor back-end.
Talvez se você é um legado arquitetura, estamos
usando o que chamamos de RDS, serviços de banco de dados relacional.
Poderia ser MSSQL, MySQL, ou algo assim.
Esta é a maneira como um aplicações de lote são projetados hoje.
>> Bem, nós pode querer ir com isto é, quando nós escalar.
Vamos ir em frente e colocar o balde S3 lá em cima.
E isso balde S3, em vez de servir se esses objetos do nosso servers--
nós poderíamos fazer isso.
Você colocar todo o seu binário objetos em seus servidores
e você pode usar aqueles servidor instâncias de servir-se de que os dados.
Mas isso é muito caro.
>> Melhor maneira de fazer é ir em frente e colocar os objetos em um balde S3.
S3 é um repositórios de objetos.
Ele é construído especificamente para servindo-se esses tipos de coisas.
E deixe que os clientes solicitam diretamente desses baldes de objetos,
descarregar os servidores.
Então, nós estamos começando a escalar aqui.
>> Agora temos usuários em todo o mundo.
Eu tenho usuários.
Eu preciso ter conteúdo localmente localizado próximo a esses usuários, certo?
Eu criei um balde S3 como meu repositório de origem.
E eu vou frente que, com a distribuição CloudFront.
>> CloudFront é um CD e um rede de distribuição de conteúdo.
Basicamente é preciso de dados que você especificar e armazena em cache-lo por toda a internet
assim os usuários em todos os lugares podem ter uma resposta muito rápida quando
eles solicitam esses objetos.
>> Então, você ter uma idéia.
Você está meio que aproveitando toda a aspectos da AWS aqui para obter este feito.
E, eventualmente, jogamos em um grupo de auto escala.
Assim, nossos casos AC2 de nossos servidores de jogo,
como eles começam a ficar mais agitado e cada vez mais ocupados,
eles só vai girar outra exemplo, girar outra instância,
girar outra instância.
Assim, a tecnologia AWS tem, ele permite que você especifique os parâmetros
em torno do qual seus servidores vai crescer.
Então você pode ter n número de servidores lá fora, em um dado momento.
E se a sua carga vai embora, eles vão encolher, o número irá diminuir.
E se a carga de volta, ele vai crescer de volta para fora, elasticamente.
>> Então, isso parece ótimo.
Nós temos um monte de instâncias de EC2.
Podemos colocar cache frente dos bancos de dados,
tentar acelerar os bancos de dados.
O próximo ponto de pressão normalmente as pessoas vêem
é que eles escalar um jogo usando um sistema de banco de dados relacional.
Eita, o banco de dados desempenho é terrível.
Como podemos melhorar isso?
Vamos tentar colocar cache na frente daquele.
>> Bem, o cache não funciona tão grande nos jogos, certo?
Para os jogos, a escrita é doloroso.
Os jogos são muito pesados ​​escrever.
Cache não funciona quando você está escrever pesado, porque você sempre
tem que atualizar o cache.
Você atualizar o cache, é irrelevantes para ser cache.
Na verdade, é apenas um trabalho extra.
>> Então, para onde vamos daqui?
Você tem um grande gargalo lá em baixo no banco de dados.
E o lugar para ir obviamente, é o particionamento.
Particionamento não é fácil de fazer quando você está
lidar com bancos de dados relacionais.
Com bancos de dados relacionais, você é responsável pela gestão, de forma eficaz,
o espaço chave.
Você está dizendo usuários entre A e M aqui, entre N e Z ir para lá.
E você está comutação em toda a aplicação.
Então, você está lidando com esta fonte de dados partição.
Você tem restrições transacionais que não ocupam partições.
Você tem todos os tipos de messiness que você é
lidar com lá tentando para lidar com dimensionando
e construção de uma infra-estrutura maior.
É só não é divertido.
>> AUDIÊNCIA: Então você está dizendo que o aumento dos pontos de origem acelera
o processo?
RICK HOULIHAN: Aumentando?
Pontos Fonte: platéia.
RICK HOULIHAN: pontos Fonte?
AUDIÊNCIA: A partir das informações, onde a informação está vindo?
RICK HOULIHAN: Não.
O que estou dizendo é o aumento da número de partições no armazenamento de dados
melhora a taxa de transferência.
Então, o que está acontecendo aqui é usuários entrando na instância EC2 aqui em cima,
bem, se eu precisar de um usuário isso é A a M, eu vou aqui.
De N a p, eu vou aqui.
De P a Z, eu vou aqui.
>> AUDIÊNCIA: OK, então essas são aqueles todos armazenados em diferentes nós?
>> RICK HOULIHAN: Sim.
Pense nisso como diferentes silos de dados.
Então, você está tendo que fazer isso.
Se você está tentando fazer isso, se você está tentando
a escala em uma plataforma relacional, isto é o que você está fazendo.
Você está levando de dados e você está cortando-o para baixo.
E você está dividindo-o em toda a várias instâncias do banco de dados.
E você está administrando tudo o que na camada de aplicativo.
Não é divertido.
Então, o que nós queremos ir?
Queremos ir DynamoDB, totalmente gerenciado, Armazenamento de dados NoSQL, prestação de transferência.
Nós usamos índices secundários.
É basicamente HTTP API e inclui suporte documento.
Então você não precisa se preocupar sobre qualquer um que o particionamento.
Fazemos tudo para você.
Então, agora, em vez disso, você basta escrever para a mesa.
Se a tabela precisa ser particionado, que acontece nos bastidores.
Você está completamente isolado do que como um desenvolvedor.
Então vamos falar sobre alguns dos casos de uso
que nos deparamos no jogo, comum cenários de jogos, tabela de classificação.
Então você tem os usuários entrando, os BoardNames que eles são
em, a pontuação para este usuário.
Podemos estar hash na UserID, e então nós temos variedade no jogo.
Assim, cada usuário quer ver todo o jogo que ele jogou
e toda a sua pontuação máxima em todos o jogo.
Então, esse é o seu ranking pessoal.
>> Agora eu quero ir e eu quero get-- por isso fico com esses leaderboards pessoais.
O que eu quero fazer é ir buscar a pontuação máxima para todos os usuários.
Então, como posso fazer isso?
Quando o meu recorde é hash em o UserID, variou no jogo,
bem, eu estou indo para ir em frente e reestruturar, criar um GSI,
e eu estou indo para reestruturar esses dados.
>> Agora vou para hash no BoardName, que é o jogo.
E eu estou indo para variar na pontuação máxima.
E agora eu criei diferentes baldes.
Eu estou usando a mesma tabela, os mesmos dados do item.
Mas eu estou criando um balde que dá me uma agregação de pontuação máxima por jogo.
>> E eu posso consultar essa tabela para obter essa informação.
Então eu definir esse padrão de consulta até ser suportada por um índice secundário.
Agora, eles podem ser classificados por BoardName e classificados por topscore, dependendo.
Assim você pode ver, estes são tipos de casos de uso que você começa no jogo.
Outro caso bom uso chegarmos em jogos é prêmios e quem ganhou os prêmios.
E este é um grande caso de uso onde chamamos índices esparsos.
Índices esparsos são o capacidade de gerar
um índice que não faz necessariamente conter todos os único item sobre a mesa.
E por que não?
Como o atributo que está sendo não indexado não existir em cada item.
>> Portanto, neste particular, usar caso, eu estou dizendo,
você sabe o quê, eu vou criar um atributo chamado Award.
E eu vou dar a todo usuário que tem um prêmio que atribuem.
Usuários que não têm prêmios são não vai ter esse atributo.
Então, quando eu criar o índice, os únicos usuários
que vão mostrar no índice são
aqueles que realmente ganharam prêmios.
Então essa é uma ótima maneira de ser capaz para criar índices filtrados que
são muito, muito seletiva que não fazer tem que indexar a tabela inteira.
>> Então, nós estamos ficando com pouco tempo aqui.
Eu estou indo para ir em frente e pular fora e ignorar este cenário.
Fale um pouco about--
>> AUDIÊNCIA: Posso fazer uma pergunta rápida?
Um deles é escrever pesado?
RICK HOULIHAN: O que é?
AUDIÊNCIA: Escrever pesado.
RICK HOULIHAN: Escrever pesado.
Deixe-me ver.
>> AUDIÊNCIA: Ou que não é algo que você pode apenas
voz para em questão de segundos?
RICK HOULIHAN: Vamos através do cenário de votação.
Não é tão ruim.
Vocês têm alguns minutos?
ESTÁ BEM.
>> Então, vamos falar sobre a votação.
Assim, a votação em tempo real, temos requisitos para votar.
Os requisitos são que nós permitimos cada pessoa para votar apenas uma vez.
Queremos que ninguém seja capaz para mudar seu voto.
Queremos agregação em tempo real e análise de dados demográficos
que vamos ser mostrando aos usuários do site.
>> Pense neste cenário.
Trabalhamos muito da realidade TV mostra onde eles estão
fazendo estes tipo exato de coisas.
Então você pode pensar no cenário, nós temos milhões e milhões
meninas de adolescentes lá com seus telefones celulares
e votação, e votação, e votar em quem eles são
encontrar para ser o mais popular.
Então, essas são algumas das requisitos corremos para fora.
>> E assim o primeiro tomar na resolução deste problema
seria construir um aplicação muito simples.
Então eu tenho esse app.
Eu tenho alguns eleitores lá fora.
Eles chegam, eles bateram o aplicativo de votação.
Eu tenho um pouco de votos tabela raw Eu só vou despejar esses votos em.
Eu vou ter algum agregado votos tabela que
farei o meu analytics e demografia, e vamos colocar tudo isso lá dentro.
>> E isso é ótimo.
A vida é boa.
A vida é boa até descobrirmos o que há sempre apenas um ou dois
pessoas que são populares em uma eleição.
Há apenas uma ou duas coisas que as pessoas realmente se preocupam.
E se você está votando em escala, de repente eu sou
vai ser martelando o inferno fora de dois candidatos, um ou dois candidatos.
Um número muito limitado de itens pessoas acham que ser popular.
>> Este não é um bom padrão de design.
Esta é realmente uma padrão de design muito ruim
porque cria exatamente o que nós falou sobre o que era teclas de atalho.
Teclas de atalho são algo de que não gostamos.
>> Então, como vamos consertar isso?
E realmente, a maneira de corrigir isso é tomando aqueles baldes candidatos
e para cada candidato que temos, vamos acrescentar um valor aleatório,
algo que sabemos, aleatório um valor entre 100 e,
entre 100 e 1000, ou entre um e 1000,
porém muitos valores aleatórios que você quer anexar para o final desse candidato.
>> E o que eu realmente feito, então?
Se eu estou usando o ID como candidato o balde para agregar votos,
se eu adicionei um aleatório número para o fim de que,
Eu criei agora 10 baldes, um centenas de baldes, mil baldes
que eu estou agregando votos de diâmetro.
>> Então, eu tenho milhões e milhões, e milhões de registros vindo
Para estes candidatos, agora estou espalhando os votos em todo A_1 Candidate
através A_100 Candidato, porque cada vez que um voto vem,
Eu estou gerando uma aleatório valor entre um e 100.
Eu estou aderência que na extremidade do candidato que pessoa de votar.
Eu estou jogando-o em que balde.
>> Agora na parte de trás, eu sei que eu tenho mais de cem baldes.
Então, quando eu quiser ir em frente e agregar os votos,
Eu li a partir de todos esses baldes.
Então eu ir em frente e adicionar.
E então eu a dispersão reunir onde eu sair e dizer hey,
Você sabe o que, esta chave do candidato espaços é mais de cem baldes.
Vou reunir todas as votos dos cem baldes.
Eu estou indo para agregar -los e eu vou dizer,
Um candidato tem agora contagem total de votos de x.
>> Agora, tanto o write consulta ea consulta de leitura
são bem distribuídos porque eu estou escrevendo em frente
e eu estou lendo em centenas de chaves.
Eu não estou escrevendo e leitura através de uma chave agora.
Então, isso é um grande teste padrão.
>> Este é provavelmente um realmente do projeto o mais importante
padrões para a escala em NoSQL.
Você vai ver este tipo de padrão de design em cada sabor.
MongoDB, DynamoDB, isso não acontece importa, todos nós temos que fazer isso.
Porque quando você está lidando com aqueles enormes agregações,
você tem que descobrir uma maneira de espalhá-los para fora através de baldes.
Portanto, esta é a maneira de fazer isso.
Tudo bem, então o que você está fazendo agora
é que você está trocando de leitura custo para gravação escalabilidade.
O custo de minha leitura é um pouco mais complexo
e eu tenho que ir ler a partir de um centenas de baldes em vez de um.
Mas eu sou capaz de escrever.
E o meu rendimento, minha escrita throughput é incrível.
Portanto, é geralmente um valioso técnica para escalar DynamoDB,
ou qualquer banco de dados NoSQL para esse assunto.
Então, nós descobrimos como escalá-lo.
E nós figuramos como eliminar nossas teclas de atalho.
E isso é fantástico.
E nós temos este sistema agradável.
E isso nos deu muito correto votação porque temos registro voto de-dupe.
Ele é construído em DynamoDB.
Falamos sobre direitos condicionais.
>> Quando um eleitor entra, puts uma inserção na tabela,
eles inserir com a sua identificação do eleitor, se tentarem inserir outra votação,
Eu faço uma gravação condicional.
Digam apenas escrever este se este não existe.
Assim, logo que eu vejo que que a votação de bater na mesa,
ninguém mais vai ser capaz de colocar o seu voto no.
E isso é fantástico.
E nós estamos incrementando nossos contadores de candidatos.
E nós estamos fazendo nosso demografia e tudo isso.
Mas o que acontece se o meu aplicação cai?
Agora, de repente votos estão chegando, e eu
Não sei se eles estão sendo processados em minhas análises e demografia
anymore.
E quando a aplicação volta para cima, como
diabos eu sei o que tenho de votos foi processado e por onde eu começo?
>> Portanto, este é um problema real quando você começar a olhar para esse tipo de cenário.
E como é que vamos resolver isso?
Nós resolvê-lo com o que nós chamar DynamoDB Streams.
Streams é um tempo de pedidos e log de alterações particionado de cada acesso
para a mesa, cada gravação acesso à tabela.
Quaisquer dados que está escrito à tabela mostra-se no fluxo.
>> É basicamente uma fila de 24 horas.
Itens bater o córrego, eles vivem por 24 horas.
Eles podem ser lidas múltiplas vezes.
Garantido para ser entregue apenas uma vez para o fluxo,
pode ser lido n número de vezes.
Então porém muitos processos você deseja consumir esses dados, você pode consumi-lo.
Ele aparecerá a cada atualização.
Cada gravação será apenas aparecer uma vez no fluxo.
Então você não precisa se preocupar sobre o processamento de duas vezes
a partir do mesmo processo.
>> É estritamente ordenada por item.
Quando dizemos tempo ordenada e particionado,
você vai ver por partição no fluxo.
Você vai ver os itens, atualizações em ordem.
Nós não estamos garantindo sobre o fluxo que você é
indo para obter todas as transações na ordem em todo itens.
>> Então córregos são idempotent.
Será que todos nós sabemos o que significa idempotent?
Idempotente significa que você pode fazê-lo mais, e mais, e outra vez.
O resultado vai ser o mesmo.
>> Streams são idempotent, mas eles têm que ser
reproduzidos a partir do ponto de partida, onde quer que você escolher, até o fim,
ou eles não vão resultar nos mesmos valores.
>> A mesma coisa com MongoDB.
MongoDB tem uma construção eles chamam a oplog.
É a mesma construção exata.
Muitos bancos de dados NoSQL tem esta construção.
Eles usá-lo para fazer coisas como replicação, que
é exatamente o que fazemos com os córregos.
AUDIÊNCIA: Talvez um pergunta herética, mas você
falar sobre aplicativos fazendo derrubou um assim por diante.
São fluxos garantido para Nunca possivelmente ir para baixo?
RICK HOULIHAN: Sim, córregos são garantidos para nunca mais ir para baixo.
Nós administramos a infra-estrutura atrás. córregos automaticamente
implantar em seu grupo Auto Scaling.
Nós vamos passar por um pouco pouco sobre o que acontece.
>> Eu não deveria dizer que eles não são garantido que nunca ir para baixo.
Os elementos são garantidos para aparecer no córrego.
E o fluxo será acessível.
Então, o que vai para baixo ou volta up, que acontece por baixo.
Ele covers-- é OK.
Tudo bem, então você começa diferente tipos de vista fora da tela.
Os tipos de vista que são importantes para a programador normalmente é, o que era?
Recebo a antiga visão.
Quando uma atualização atinge a mesa, ele vai empurrar o velho vista para o fluxo
que os dados possam arquivar ou mudança controle, identificação mudança, mudança
gestão.
>> A nova imagem, o que é agora, depois de a atualização, que é um outro tipo de visão
você pode ter.
Você pode obter tanto as imagens antigas e novas.
Talvez eu quero os dois.
Eu quero ver o que era.
Eu quero ver o que mudou para.
>> Eu tenho um tipo de conformidade do processo que corre.
Ele precisa verificar se quando essas coisas mudam,
que eles estão dentro de certos limites ou dentro de certos parâmetros.
>> E então talvez eu só precisa saber o que mudou.
Eu não me importo o que item foi modificado.
Eu não precisa precisa saber que atributos alterado.
Eu só preciso saber que os itens estão sendo tocadas.
Então esses são os tipos de pontos de vista que você sair do córrego
e você pode interagir com.
>> O aplicativo que consome a corrente,
este é o tipo de forma como isto funciona.
DynamoDB cliente pedir para enviar dados para as tabelas.
Streams implantar no que chamamos de cacos.
Shards são escalados independentemente da mesa.
Eles não se alinham completamente para as partições de sua mesa.
E a razão pela qual é porque eles se alinham
com a capacidade, a actual capacidade da tabela.
>> Eles implantar em sua próprio grupo escalonamento auto,
e eles começam a girar para fora, dependendo de quantas gravações estão chegando,
quantos reads-- realmente é escreve.
Não há nenhuma reads-- mas como muitas gravações estão chegando.
>> E, em seguida, na parte de trás fim, temos o que
chamar um KCL, ou Biblioteca de Kinesis Cliente.
Kinesis é um fluxo de dados tecnologia de processamento da Amazônia.
E córregos é construído sobre isso.
>> Então você usa um KCL habilitado aplicação para ler o fluxo.
A Biblioteca Kinesis cliente, na verdade, gerencia os trabalhadores para você.
E ele também faz alguns coisas interessantes.
Ele vai criar algumas tabelas up em sua tabela DynamoDB
para controlar quais itens ter sido processada.
Então, dessa maneira, se ele cai para trás, se ele cai e vem e fica
estava de volta, pode determinar onde foi no processamento da corrente.
>> Isso é muito importante quando você está falando de replicação.
Eu preciso saber o que dados foi foi processada
e os dados que ainda tem de ser processada.
Assim, a biblioteca de KCL para fluxos vai dar-lhe um monte de que a funcionalidade.
Ela cuida de todas as tarefas domésticas.
Ele levanta-se um trabalhador para cada fragmento.
Ela cria uma tabela administrativa para cada fragmento, para cada trabalhador.
E como os trabalhadores fogo, eles mantêm essas tabelas
assim você sabe este registro foi lido e processado.
E, em seguida, dessa forma, se o processo morre e voltar a ficar online,
ele pode retomar exatamente onde ele decolou.
>> Então, nós usamos isso para replicação cross-região.
Muitos clientes têm a necessidade de mover dados ou partes de suas tabelas de dados
em torno de diferentes regiões.
Existem nove regiões tudo em volta do mundo.
Portanto, pode haver um eu need-- pode ter usuários na Ásia, os usuários
na Costa Leste dos Estados Unidos.
Eles têm que dados diferentes necessita de ser distribuído localmente.
E talvez um usuário voa de Ásia para os Estados Unidos,
e eu quero replicar seus dados com ele.
Então, quando ele sai do avião, ele tem uma boa experiência usando seu aplicativo móvel.
>> Você pode usar o cross-região biblioteca de replicação para fazer isso.
Basicamente, temos fornecida duas tecnologias.
Um é um aplicativo de console que puder levantar-se sobre o seu próprio instância EC2.
Ele é executado a replicação puro.
E, em seguida, deu-lhe a biblioteca.
A biblioteca pode ser usada para construir seu próprio aplicativo se você
quero fazer coisas malucas com que data-- filtro, replicar apenas uma parte dela,
rodar os dados, movê-lo para um tabela diferente, assim por diante e assim por diante.
Então, esse é o tipo de o que parece.
>> DynamoDB Streams pode ser processadas pelo que chamamos de Lambda.
Mencionamos um pouco sobre o evento arquiteturas de aplicativos acionados.
Lambda é um componente fundamental do que isso.
Lambda é o código que dispara na demanda em resposta a um acontecimento particular.
Um desses eventos pode ser um registro que aparece no stream.
Se um registro aparece no córrego, vamos chamar essa função Java.
Bem, este é JavaScript, e Lambda suporta Node.js, Java, Python,
e em breve apoiar outras línguas também.
E escusado será dizer, é puro código.
escrever em Java, você define uma classe.
Você aperta o JAR-se em Lambda.
E então você especificar qual classe a chamada em resposta ao qual o evento.
E, em seguida, a infra-estrutura do Lambda por trás que irá executar esse código.
>> Esse código pode processar registros fora do córrego.
Ele pode fazer o que quiser com ele.
Neste exemplo em particular, todos nós somos fazendo realmente está registrando os atributos.
Mas este é apenas código.
Código pode fazer qualquer coisa, certo?
>> Então, você pode rodar esses dados.
Você pode criar uma visão derivada.
Se é uma estrutura do documento, você pode achatar a estrutura.
Você pode criar índices alternativos.
Todos os tipos de coisas que você pode fazer com os córregos DynamoDB.
>> E realmente, isso é o que parece.
Então você obter essas atualizações chegando.
Eles estão saindo da cadeia.
Eles são lidos pela função Lambda.
Eles estão girando os dados e empurrando-se em tabelas de derivativos,
notificando sistemas externos de mudança, e enviar dados em ElastiCache.
>> Nós conversamos sobre como colocar o cache na frente da base de dados para que as vendas
cenário.
Bem, o que acontece se eu atualizar a descrição do item?
Bem, se eu tivesse um Lambda função de execução em que a tabela,
se eu atualizar a descrição do item, ele vai pegar o registro fora do córrego,
e ele vai atualizar o ElastiCache exemplo, com os novos dados.
Então, isso é um monte de o que fazemos com Lambda.
É código de cola, conectores.
E ele realmente dá a capacidade de lançar
e para executar aplicativos muito complexos sem um servidor dedicado
infra-estrutura, o que é muito legal.
>> Então, vamos voltar ao nosso em tempo real arquitetura votação.
Esta é uma nova e melhorada com o nosso riachos e KCL habilitado aplicativo.
Mesmo que antes, nós podemos lidar com qualquer escala de eleição.
Nós gostamos disso.
Nós estamos fazendo a coleta de dispersão em vários baldes.
Temos de bloqueio otimista acontecendo.
Nós podemos manter os nossos eleitores de mudar seus votos.
Eles só podem votar apenas uma vez.
Isso é fantástico.
Tolerância a falhas em tempo real, agregação escalável agora.
Se a coisa cai, ele sabe onde reiniciar-se
quando se trata back-up porque estamos usando o aplicativo KCL.
E então nós também podemos usar isso Aplicação KCL para enviar dados para fora
para redshift para outro analytics App ou uso
os MapReduce elástico para executar em tempo real agregações de streaming fora
de que os dados.
>> Então, essas são coisas que nós não falamos sobre muita coisa.
Mas eles são adicional tecnologias que vêm
de suportar quando você está olhando nestes tipos de cenários.
>> Tudo bem, então isso é sobre analytics com DynamoDB Streams.
Você pode coletar de-dupe dados, fazer todos os tipos
de coisas legais, dados agregados em memória, criar essas tabelas de derivativos.
Isso é um caso de uso enorme que um monte de clientes
está envolvido com, tomando a nested propriedades desses documentos JSON
e criação de índices adicionais.
>> Nós estamos no fim.
Obrigado por suportar comigo.
Então vamos falar sobre arquitetura de referência.
DynamoDB fica no meio dos assim grande parte da infraestrutura da AWS.
Basicamente, você pode ligá-lo até o que quiser.
Os aplicativos criados usando Dynamo incluem Lambda, ElastiCache, CloudSearch,
empurrar os dados para fora em Elastic MapReduce, importação e exportação de DynamoDB
em S3, todos os tipos de fluxos de trabalho.
Mas, provavelmente, a melhor coisa para falar,
e isso é o que é realmente interessante é quando nós
falar sobre aplicativos orientados a eventos.
>> Este é um exemplo de um projeto interno
que temos onde nós estamos, na verdade, publicação de reunir os resultados da pesquisa.
Assim, em um link de e-mail que nós enviamos para fora, lá vai
ser um pequeno estalo ligação dizendo aqui para responder à pesquisa.
E quando uma pessoa clica esse link, o que acontece
é que eles puxar para baixo um seguro Formulário do exame de código HTML S3.
Não há nenhum servidor.
Este é apenas um objeto S3.
>> Essa forma surge, carrega-se no navegador.
Tem Backbone.
Tem complexo JavaScript que ele está correndo.
Por isso é aplicação muito rico em execução no navegador do cliente.
Eles não sabem que eles não são interagindo com um servidor back-end.
Neste ponto, é tudo browser.
>> Eles publicam os resultados para o chamamos a Amazon API Gateway.
API Gateway é simplesmente uma API web que você pode definir e ligar
para o que quiser.
Neste caso particular, estamos ligado a uma função Lambda.
>> Assim, a minha operação POST é acontecendo com nenhum servidor.
Basicamente gateway de API que se senta lá.
Ele me custa nada até que as pessoas comece a postar a ele, certo?
A função Lambda apenas se senta lá.
E isso me custa nada até as pessoas começam a bater.
Assim você pode ver, como o volume aumentos, que é quando as acusações vir.
Eu não estou executando um servidor 7/24.
>> Então eu puxo a forma para baixo para fora do balde,
e eu postar por meio da API Porta de entrada para a função Lambda.
E, em seguida, o Lambda função diz, você sabe
o que, eu tenho algumas PIIs, alguns informação pessoalmente identificável
nestas respostas.
Eu tenho comentários vindos de usuários.
Tenho endereços de email.
Eu tenho nomes de usuários.
>> Deixe-me dividir este fora.
Eu estou indo para gerar algum metadados off esse registro.
E eu estou indo para empurrar o metadados em DynamoDB.
E eu poderia criptografar todos os dados e empurrá-lo para DynamoDB se eu quiser.
Mas é mais fácil para mim, neste caso de uso, para ir em frente uma palavra a dizer,
Eu estou indo para empurrar os dados em bruto em um balde S3 encriptada.
Então eu usar construído no lado do servidor S3 criptografia e gerenciamento de chaves da Amazon
Serviço para que eu tenha uma chave que pode rodar em um intervalo regular,
e eu posso proteger esses dados PII como parte de todo este fluxo de trabalho.
>> Então o que foi que eu fiz?
Acabei implantado um todo aplicação, e eu não tenho servidor.
Então é o que aplicação dirigida evento arquitetura faz para você.
>> Agora, se você pensar sobre o caso de uso para isto--
temos outros clientes que eu estou falando a arquitetura exata sobre o que
executar fenomenalmente grandes campanhas, que está olhando para isso e vai, oh meu.
Porque agora, eles podem basicamente empurrá-lo para fora lá,
deixe que a campanha apenas sentar lá até que ele lança, e não
tem que se preocupar um figo sobre que tipo de infra-estrutura
vai estar lá para apoiá-lo.
E, em seguida, logo que que a campanha é feita,
é como a infra-estrutura apenas vai embora imediatamente
porque não há realmente há infra-estrutura.
É código apenas que se sente em Lambda.
É apenas dados que fica no DynamoDB.
É uma forma incrível para construir aplicações.
>> AUDIÊNCIA: Então é mais efémero do que seria
se ele foi armazenado em um servidor real?
>> RICK HOULIHAN: Absolutamente.
Porque essa instância de servidor teria de ser um 7/24.
Tem que estar disponível para alguém para responder.
Bem, adivinhem?
S3 é disponível 7/24.
S3 responde sempre.
E S3 é muito, muito bom a servir-se objetos.
Esses objetos podem ser arquivos HTML, ou Arquivos JavaScript, ou o que você quiser.
Você pode executar aplicações web muito ricas fora de baldes S3, e as pessoas fazem.
>> E então essa é a idéia aqui é para ficar longe do caminho
estamos acostumados a pensar sobre isso.
Todos nós costumava pensar em termos de servidores e anfitriões.
Não é sobre isso mais.
Trata-se de infra-estrutura como código.
Implantar o código para a nuvem e deixe a nuvem executá-lo para você.
E é isso que a AWS está tentando fazer.
>> AUDIÊNCIA: sua caixa de ouro no meio Então, do API Gateway não é servidor-like,
mas em vez disso é apenas--
>> RICK HOULIHAN: Você pode pensar nisso como fachada servidor.
Tudo o que é que vai demorar um HTTP solicitar e mapeá-la para outro processo.
Isso é tudo que ele faz.
E, neste caso, estamos mapeando -lo para uma função lambda.
Tudo bem, então isso é tudo que eu tenho.
Muito obrigado.
Eu agradeço.
Eu sei que nós queremos um pouco ao longo do tempo.
E espero que vocês tem um pouco de informação
que você pode tirar hoje.
E peço desculpa se eu fui sobre algumas de suas cabeças,
mas há um monte de bom conhecimento fundamental fundamentais
que eu acho que é muito valioso para você.
Então, obrigado por me receber.
[Aplausos]
AUDIÊNCIA: [inaudível] é quando você estava dizendo
você tinha que ir através da coisa a partir do início ao fim
para obter os valores corretos ou os mesmos valores,
como é que os valores mudar se [inaudível].
>> RICK HOULIHAN: Oh, idempotentes?
Como os valores mudam?
Bem, porque se eu não correr todo o caminho até o fim,
então eu não sei o que muda foram feitas na última milha.
Não vai ser a mesmos dados que o que eu vi.
AUDIÊNCIA: Ah, então você apenas não ter chegado a entrada inteira.
RICK HOULIHAN: Certo.
Você tem que ir do começo ao fim, e então é
vai ser um estado consistente.
Frio.
>> AUDIÊNCIA: Então você nos mostrou DynamoDB pode fazer documento ou o valor da chave.
E nós passamos muito tempo no valor-chave com um hash e as formas
para lançá-lo ao redor.
Quando você olhou para essas tabelas, é que deixando para trás a abordagem documento?
>> RICK HOULIHAN: eu não faria dizer deixá-lo para trás.
>> AUDIÊNCIA: Eles foram separados de as--
>> RICK HOULIHAN: Com o documento abordagem, o tipo de documento em DynamoDB
é apenas pensar em como outro atributo.
É um atributo que contém uma estrutura de dados hierárquica.
E, em seguida, nas consultas, você pode usar as propriedades
desses objetos usando Object Notation.
Para que eu possa filtrar em um nested propriedade do documento JSON.
AUDIÊNCIA: Então qualquer momento I fazer uma abordagem documento,
Eu posso classificar de chegar ao tabular--
AUDIÊNCIA: Absolutamente.
Audiência: --indexes e coisas que você falou.
RICK HOULIHAN: Sim, o índices e tudo o que,
quando você quer indexar o propriedades do JSON,
a maneira que nós teríamos de fazer isso é se você insere um objeto JSON ou um documento
em Dynamo, você usaria correntes.
Streams iria ler a entrada.
Você deseja obter que JSON objeto e você diria OK,
o que é a propriedade que eu quero para o índice?
>> Você cria uma tabela derivada.
Agora que é a forma como ele funciona agora.
Nós não permitimos que você índice diretamente essas propriedades.
>> AUDIÊNCIA: Tabularizing seus documentos.
>> RICK HOULIHAN: Exatamente, achatando ele, tabularizing isso, exatamente.
Isso é o que você faz com ele.
>> AUDIÊNCIA: Obrigado.
>> RICK HOULIHAN: Sim, absolutamente, obrigado.
AUDIÊNCIA: Então é tipo de Mongo atende classifers Redis.
>> RICK HOULIHAN: Sim, é muito parecido.
Essa é uma boa descrição para ele.
Frio.