Escalabilidade do DynamoDB

Prévia do material em texto

SQL, NoSQL e escala: como o DynamoDB é dimensionado onde os bancos de dados relacionais não
6 de janeiro de 2020· 27 minutos de leitura
Nos últimos anos, o DynamoDB tornou-se cada vez mais popular como banco de dados. Isso ocorre por alguns motivos, como a forma como ele se adapta tão bem às arquiteturas sem servidor usando AWS Lambda ou AWS AppSync ou devido à crescente comunidade em torno de como modelar o DynamoDB, estimulada pelas palestras do incrível Rick Houlihan .
Quando converso com pessoas que são novas no DynamoDB, muitas vezes ouço as mesmas reclamações iniciais:
"Uau, isso parece estranho."
"Por que o DynamoDB não tem junções?"
"Por que não consigo fazer nenhuma agregação?"
"Por que o DynamoDB é tão difícil?"
Para entender a resposta a essas reclamações, você precisa saber uma coisa importante sobre o DynamoDB:
O DynamoDB não permitirá que você escreva uma consulta incorreta
Quando digo "consulta incorreta", quero dizer "consulta que não é escalonável". O DynamoDB foi desenvolvido para escalabilidade. Ao escrever um aplicativo usando o DynamoDB, você obterá as mesmas características de desempenho quando houver 1 GB de dados e quando houver 100 GB de dados ou 100 TB de dados.
O mesmo não acontece com os bancos de dados relacionais. Seu aplicativo pode parecer rápido quando é implementado pela primeira vez, mas você verá uma degradação no desempenho à medida que seu banco de dados crescer.
Nesta postagem, veremos como os bancos de dados são escaláveis ​​ou não. Abordaremos os seguintes tópicos:
O maior problema dos bancos de dados relacionais: imprevisibilidade
Como o DynamoDB 'muda para a esquerda' na escalabilidade
As três razões pelas quais os bancos de dados relacionais enfrentam problemas em grande escala
Como o DynamoDB evita os três problemas
Onde você pode encontrar problemas de desempenho com o DynamoDB.
Observação: nada disso sugere que o DynamoDB seja o único banco de dados verdadeiro que deve ser usado para tudo. Existem vantagens e desvantagens em tudo, e você deve considerar as suas cuidadosamente ao escolher um banco de dados.
Vamos começar!
A imprevisibilidade dos 
Os bancos de dados relacionais são uma peça de tecnologia maravilhosa. Eles são relativamente fáceis de aprender, o que os tornou o primeiro banco de dados a ser aprendido por novos desenvolvedores. Eles funcionam para uma ampla variedade de casos de uso e, portanto, são a escolha padrão para a maioria dos aplicativos. E os bancos de dados relacionais possuem SQL, uma sintaxe de consulta flexível que facilita o tratamento de novos padrões de acesso ou o tratamento de padrões OLTP e OLAP em um único banco de dados.
Mas há um grande problema com os bancos de dados relacionais: o desempenho é como uma caixa preta. Existem vários fatores que afetam a rapidez com que suas consultas retornarão.
Durante o teste e no início do ciclo de vida do seu aplicativo, você pode ter uma consulta no seu aplicativo que retorna rapidamente:
file_0.wmf
Caixa Preta SQL - Desempenho Normal
Nesses estágios iniciais, a consulta retorna rapidamente e está tudo bem.
Mas o que acontece à medida que seu conjunto de dados aumenta? Em nossa consulta de exemplo, temos a JOINe uma GROUP BYinstrução. À medida que o tamanho das suas tabelas aumenta, essas operações ficam cada vez mais lentas.
file_1.wmf
SQL Black Box – Mais dados
E não é apenas com o tamanho das suas mesas que você precisa se preocupar. O desempenho do banco de dados relacional também é afetado por outras consultas em execução ao mesmo tempo. O que acontece com o desempenho da sua consulta quando 100 dessas grandes consultas estão em execução ao mesmo tempo? Ou se o seu gerente de produto estiver executando uma grande consulta analítica em seu banco de dados para encontrar os principais usuários do último mês?
file_2.wmf
Caixa Preta SQL - Vizinhos
O desempenho do seu banco de dados relacional está sujeito a vários fatores – tamanho da tabela, tamanho do índice, consultas simultâneas – que são difíceis de testar com precisão com antecedência. Mesmo que você tenha uma boa ideia do número de solicitações por segundo que precisará suportar, é complicado convertê-lo no tamanho de instância adequado (nº de CPUs + RAM) que possa lidar com essas solicitações.
É essa imprevisibilidade que pode enlouquecer um banco de dados relacional.
Como o DynamoDB muda para a esquerda na 
Uma grande mudança no desenvolvimento de software nos últimos vinte anos é a ideia de testes shift-left . (https://en.wikipedia.org/wiki/Software_testing)
O teste shift-left refere-se a pensar em testar no início do ciclo de vida de desenvolvimento de software, em vez de esperar até o final.
Imagine um gráfico com um eixo X representando todo o ciclo de vida da construção de uma produção, desde os requisitos e design até o desenvolvimento e suporte. Normalmente, os testes seriam realizados posteriormente no ciclo de vida, após a conclusão do projeto e da implementação iniciais.
Linha do tempo - tradicional
file_3.wmf
O modelo tradicional de desenvolvimento de software – a maioria dos testes ocorre após a implementação.
Os proponentes do deslocamento para a esquerda desejam incluir testes no início do ciclo de vida ou mover para a esquerda no eixo X (daí o nome 'shift-esquerda'). O principal motivo é que é melhor encontrar os defeitos antecipadamente, ao mesmo tempo que é mais fácil alterá-los e menos tempo é desperdiçado no desenvolvimento.
Linha do tempo - deslocar para a esquerda
file_4.wmf
O modelo de desenvolvimento de software de mudança para a esquerda – faça mais testes antecipadamente.
Existe um modelo semelhante em jogo com bancos de dados e escalabilidade. Muitos bancos de dados são difíceis de testar o desempenho antecipadamente. Tudo corre bem em ambientes de teste em baixa escala.
Em essência, este é o “modelo tradicional” de escalabilidade – você faz algum trabalho relacionado à escalabilidade antecipadamente, como criação de índice e planejamento de capacidade. No entanto, a maior parte do problema ocorre quando seu aplicativo atinge a escala real e começa a esticar os limites do seu banco de dados.
O DynamoDB, por outro lado, usa um modelo de escalabilidade shift-left. Isso força você a pensar em projetar seu modelo de dados antecipadamente de uma forma que seja escalonável.
Com o DynamoDB, não há nenhuma caixa preta sobre como seu banco de dados será dimensionado:
Com que rapidez minha consulta retornará quando a escala for 100 vezes maior? O mesmo - milissegundos de um dígito
Como minha consulta afetará outras consultas no banco de dados? Isso não acontecerá - as consultas são limitadas pelo impacto nos recursos
Esta abordagem de mudança para a esquerda não é gratuita. Você precisará investir tempo para realmente entender os padrões de acesso do seu aplicativo antecipadamente e projetar seu modelo de dados de acordo. Mas as recompensas são grandes: você não precisará retrabalhar seu modelo de dados devido a problemas de dimensionamento. Você obterá exatamente o mesmo desempenho com 10 TB e 1 GB.
Como o DynamoDB faz isso? Envolve algumas decisões importantes de design no DynamoDB. Mas antes de nos aprofundarmos nisso, vamos examinar as diferentes maneiras pelas quais os bancos de dados relacionais não são dimensionados, pois isso informa as decisões de design por trás do DynamoDB.
Por que os bancos de dados relacionais não 
Ahh, o RDBMS – a maravilhosa tecnologia que sustenta os sistemas bancários, hospitais e, claro, 90% da Internet que roda em Wordpress.
O RDBMS nos serviu muito bem e ainda é uma ótima opção para muitas aplicações. Ele é bem conhecido pelos desenvolvedores, é flexível para evoluir conforme suas necessidades mudam e fornece funcionalidades OLTP e OLAP.
No entanto, vimos várias empresas migrarem de bancos de dados RDBMS para bancos de dados NoSQL nos últimos vinte anos devido a problemas com RDBMS em escala. Para saber mais sobre isso, dê uma olhada no Dynamo Paper , https://www.dynamodbguide.com/the-dynamo-paper/escrito por alguma Amazon .com engenheiros (incluindo o atual CTO da AWS, Werner Vogels ),
https://en.wikipedia.org/wiki/Werner_Vogels que apresenta os conceitos por trás do banco de dados Dynamo criado para a Amazon . com . O Dynamo Paper inclui muitas das decisões de design por trás do DynamoDB e inspirou bancos de dados NoSQL posteriores, como o Apache Cassandra .https://en.wikipedia.org/wiki/Apache_Cassandra
Existem três grandes problemas com bancos de dados relacionais que dificultam o dimensionamento:
As características de baixa complexidade de tempo das junções SQL;
A dificuldade de dimensionar horizontalmente; e
A natureza ilimitada das consultas
Exploraremos cada um deles a seguir.
Junções SQL têm 
O primeiro problema com RDBMS decorre da operação de junção em SQL.
Em uma operação de junção SQL, seu banco de dados relacional combina resultados de duas ou mais tabelas diferentes. Você não apenas está lendo um pouco mais de dados, mas também comparando os valores de um com o outro para determinar quais valores devem ser retornhttps://www.youtube.com/watch?v=6yqfmXiZTlM&t=1581sados.
Rick Houlihan, em sua palestra épica re:Invent de 2019 sobre o DynamoDB, abordou um pouco da complexidade de tempo dos SQL 
JOINs em comparação com as operações do DynamoDB. Seus resultados irão variar com base no tipo de JOIN que você está usando, bem como nos índices de suas tabelas, mas você pode estar obtendo tempo linear 
https://www.datacamp.com/tutorial/sql-tutorial-query#estimating-time-complexity-of-your-query-plan( O (M + N)) ou pior.
Essas operações com uso intensivo de CPU funcionarão bem durante o teste ou enquanto seus dados forem pequenos. À medida que seus dados crescem, você começará lentamente a ver o uso da CPU aumentar e o desempenho das consultas diminuir. Como tal, você pode querer aumentar seu banco de dados. Isso nos leva ao próximo problema com bancos de dados relacionais.
É difícil dimensionar horizontalmente um 
O segundo problema com RDBMS é que eles são difíceis de escalar horizontalmente.
Existem duas maneiras de dimensionar um banco de dados:
Escalonamento vertical , aumentando a CPU ou RAM da(s) sua(s) máquina(s) de banco de dados existente(s), ou
Escalabilidade horizontal , adicionando máquinas adicionais ao cluster de banco de dados, cada uma delas lidando com um subconjunto do total de dados.
Em escala inferior, provavelmente não há uma grande diferença de preço entre a escala vertical e a horizontal. Na verdade, com a AWS, eles fizeram um ótimo trabalho de paridade de preços entre uma máquina grande e várias máquinas menores.
No entanto, você acabará atingindo os limites da escala vertical. Seu provedor de nuvem não terá uma caixa grande o suficiente para lidar com seu crescente banco de dados. Neste ponto você pode querer considerar a escala horizontal. Agora você está enfrentando problemas maiores.
O objetivo do escalonamento horizontal é que cada máquina em seu cluster geral manipulará apenas uma parte do total de dados. À medida que seus dados continuam a crescer, você pode adicionar máquinas adicionais para manter a quantidade de dados em cada máquina relativamente estável.
Isso é complicado com um banco de dados relacional, pois muitas vezes não há uma maneira clara de dividir os dados. Freqüentemente, você desejará armazenar todos os resultados de uma determinada tabela na mesma máquina para poder lidar corretamente com a exclusividade e outros requisitos.
Se você dividir tabelas em máquinas diferentes, agora suas junções SQL exigirão uma solicitação de rede além do cálculo da CPU.
O dimensionamento horizontal funciona melhor quando você pode fragmentar os dados de forma que uma única solicitação possa ser tratada por uma única máquina. Pular em várias caixas e fazer solicitações de rede entre elas resultará em desempenho mais lento.
Consultas relacionais são 
O terceiro problema com o RDBMS é que, por padrão, as consultas SQL são ilimitadas. Não há limite inerente à quantidade de dados que você pode verificar em uma única solicitação ao seu banco de dados, o que também significa que não há limite inerente à forma como uma única consulta incorreta pode consumir seus recursos e bloquear seu banco de dados.
Um exemplo simples seria uma consulta como SELECT * FROM large_table: uma varredura completa da tabela para recuperar todas as linhas. Mas isso é bastante óbvio de se ver no código do seu aplicativo e tem menos probabilidade de consumir todos os recursos do seu banco de dados.
Um exemplo mais nefasto seria algo como o seguinte:
SELECT user_id, sum(amount) AS total_amount
FROM orders
GROUP BY user_id
ORDER BY total_amount DESC
LIMIT 5
O exemplo acima examina a orderstabela em um aplicativo para encontrar os 5 principais usuários pelo valor gasto. Um desenvolvedor de aplicativos pode pensar que esta não é uma operação cara, pois retorna apenas 5 linhas. Mas pense nas etapas envolvidas nesta operação:
Digitalize toda a tabela de pedidos
Agrupe os pedidos pelo ID do usuário e some o valor do pedido por usuário para encontrar um total.
Ordene os resultados da etapa anterior de acordo com o total somado.
Retorne os 5 principais resultados
Isso é caro em vários recursos diferentes – CPU, memória e disco. E está completamente oculto do desenvolvedor.
As agregações são armadilhas para os incautos, prontas para derrubar seu banco de dados assim que você atingir a escala.
Como os bancos de dados NoSQL lidam com esses 
Na seção anterior, vimos como os bancos de dados relacionais enfrentam problemas à medida que são dimensionados. Nesta seção, veremos como bancos de dados NoSQL como o DynamoDB lidam com esses problemas. Não é novidade que eles são essencialmente o inverso dos problemas listados acima:
O DynamoDB não permite junções;
O DynamoDB força você a segmentar seus dados, permitindo um escalonamento horizontal mais fácil; e
O DynamoDB coloca limites explícitos em suas consultas.
Novamente, vamos revisar cada um deles em ordem.
Como os bancos de dados NoSQL substituem 
Primeiro, vamos ver como os bancos de dados NoSQL substituem as junções. Para fazer isso, devemos entender os trabalhos que as junções realizam em um banco de dados relacional.
A maneira canônica de modelar seus dados em um banco de dados relacional é normalizar suas entidades. A normalização é um assunto complexo que não abordaremos em profundidade aqui, mas essencialmente você deve evitar repetir qualquer dado singular em um banco de dados relacional. Em vez disso, você deve criar um registro canônico dos dados e fazer referência a esse registro canônico sempre que necessário.
Por exemplo, um cliente em uma aplicação de comércio eletrônico pode fazer vários pedidos ao longo do ano. Em vez de armazenar todas as informações do cliente no próprio registro do pedido, o registro do pedido conteria uma CustomerIdpropriedade que apontaria para o registro canônico do cliente.
file_5.wmf
Exemplo relacional
No exemplo acima, o pedido nº 348901 possui uma CustomerIdpropriedade com valor 145. Isso aponta para o registro na tabela Clientes com um Idvalor de 145. Se o Cliente nº 145 alterar algo nele, como nome ou endereço, o Pedido não precisará fazer as alterações correspondentes.
Existem dois benefícios nesta abordagem:
Eficiência de armazenamento : como um único registro de dados é 'gravar uma vez, consultar muitos', os bancos de dados relacionais exigem menos armazenamento do que as opções que duplicam os dados em vários registros.
Integridade dos dados : é mais fácil garantir a integridade dos dados entre entidades com um banco de dados relacional. No nosso exemplo acima, se você duplicar as informações do cliente em cada registro de pedido, poderá ser necessário atualizar cada registro de pedido quando o cliente alterar algumas informações sobre si mesmo. Em um banco de dados relacional, você só precisa atualizar o cadastro do cliente. Todos os registros que se referem a ele receberão as atualizações.
No entanto, a normalização significa que seus dados estão espalhados por todo o lugar. Como recupero o registrodo pedido e as informações sobre o cliente que o efetuou?
É aqui que entram as junções. As junções permitem remontar dados de vários registros diferentes em uma única operação. Eles oferecem enorme flexibilidade no acesso aos seus dados. Com a flexibilidade das junções e do restante da gramática SQL, você pode basicamente remontar qualquer um dos seus dados conforme necessário. Devido a essa flexibilidade, você realmente não precisa pensar antecipadamente em como acessará seus dados. Você modela suas entidades de acordo com os princípios de normalização e, em seguida, escreve as consultas para atender às suas necessidades.
No entanto, como observado acima, essa flexibilidade tem um custo: as junções exigem muita CPU e memória. Assim, para se livrar das junções SQL, o NoSQL precisa lidar com os três benefícios das junções:
1.Acesso flexível aos dados
2.Integridade de dados
3.Eficiência de armazenamento
Dois deles são tratados por compensações específicas, enquanto o terceiro é menos preocupante.
Primeiro, os bancos de dados NoSQL evitam a necessidade de flexibilidade no acesso aos dados, exigindo que você faça um planejamento antecipado. Como você lerá seus dados? Como você escreverá seus dados? Ao trabalhar com um banco de dados NoSQL, você precisa considerar essas questões cuidadosamente antes de projetar seu modelo de dados. Depois de conhecer seus padrões, você poderá projetar seu banco de dados para lidar especificamente com essas questões. Em vez de remontar seus dados no momento da leitura, você irá 'pré-juntar' seus dados, organizando-os da maneira como serão lidos.
A segunda desvantagem dos bancos de dados NoSQL é que a integridade dos dados agora é uma preocupação no nível do aplicativo . Embora JOINs permitam um padrão 'gravar uma vez, consultar muitos' para itens referenciados, pode ser necessário desnormalizar e duplicar dados em seu banco de dados NoSQL. Para dados que não mudam – datas de nascimento, datas de pedidos, leituras de sensores – essa duplicação não é problema. Para dados que mudam, como nomes de exibição ou preços listados, você pode atualizar vários registros em caso de alteração.
Finalmente, os bancos de dados NoSQL são menos eficientes em termos de armazenamento do que seus equivalentes relacionais, mas isso não é uma preocupação. Quando os RDBMS foram projetados, o armazenamento era mais valioso do que a computação. Este já não é o caso – os preços de armazenamento caíram ao mínimo enquanto a Lei de Moore está a abrandar. A computação é o recurso mais valioso em seus sistemas, por isso faz sentido otimizar a computação em vez do armazenamento.
Por que os bancos de dados NoSQL podem ser dimensionados 
Na seção anterior, vimos como os bancos de dados NoSQL lidam com o problema de complexidade de tempo em torno das junções SQL, exigindo que você organize seus dados de forma que sejam pré-juntados para seu caso de uso. Nesta seção, veremos como o NoSQL resolve o problema de escalonamento permitindo o escalonamento horizontal.
O principal motivo pelo qual os bancos de dados relacionais não podem ser dimensionados horizontalmente é a flexibilidade da sintaxe da consulta. SQL permite que você adicione todos os tipos de condições e filtros aos seus dados, de modo que seja impossível para o sistema de banco de dados saber quais partes dos seus dados serão buscadas até que sua consulta seja executada. Como tal, todos os dados precisam ser mantidos localmente, no mesmo nó, para evitar chamadas de rede entre máquinas ao executar uma consulta.
Para evitar esse problema, os bancos de dados NoSQL exigem que você divida seus dados em segmentos menores e execute todas as consultas dentro de um desses segmentos. Isso é comum em todos os bancos de dados NoSQL. No DynamoDB e no Cassandra, é chamada de chave de partição . https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey
No MongoDB, é chamado de chave de fragmento . https://www.mongodb.com/docs/manual/core/sharding-shard-key/
A maneira mais fácil de pensar em um banco de dados NoSQL é uma tabela hash onde o valor de cada chave na tabela hash é uma b-tree . A chave de partição é a chave na tabela hash e permite distribuir seus dados por um número ilimitado de nós.
Vamos ver como funciona essa chave de partição. Suponha que você tenha um modelo de dados centrado nos usuários e, portanto, use UserIdcomo sua chave de partição. Quando você grava seus dados no banco de dados, ele usará esse UserIdvalor para determinar qual nó deverá usar para armazenar a cópia primária dos dados.
file_6.wmf
Fragmentação horizontal – três nós
No diagrama simplificado acima, a caixa vermelha indica nossa tabela DynamoDB como um todo. Dentro da tabela, existem três nós que armazenam todos os dados. Cada nó é o primário para um subconjunto diferente de dados.
Quando uma nova gravação chega com um UserIdvalor 741, o roteador de solicitação do DynamoDB determinará qual nó deve manipular os dados. Neste caso, ele é roteado para o Nó 3, pois é responsável por todos UserIdsentre 667 e 999.
file_7.wmf
Dimensionamento horizontal - mediante solicitação
Nota: A maioria dos bancos de dados NoSQL faz hash do valor da chave de partição antes de atribuí-la a um nó. Isso ajuda a distribuir melhor os dados, especialmente quando a chave de partição aumenta monotonicamente. Para obter mais informações, consulte a documentação do MongoDB sobre fragmentação de hash .
No momento da leitura, todas as consultas devem incluir a chave de partição. Assim como acontece com a gravação, esta operação pode ser enviada ao nó responsável por aquele pedaço de dados sem incomodar os outros nós do cluster.
file_8.wmf
Escala horizontal - com solicitação de leitura
Esse mecanismo de fragmentação é o que permite a escala essencialmente infinita do NoSQL sem degradação do desempenho. À medida que o volume de dados aumenta, você pode adicionar nós adicionais conforme necessário. Cada operação atinge apenas um nó no cluster.
Como o DynamoDB limita suas 
A última maneira pela qual o DynamoDB evita problemas de escalabilidade do RDBMS é limitando suas consultas.
Mencionamos antes que o DynamoDB é basicamente uma tabela hash distribuída onde o valor de cada chave é uma árvore B. Encontrar o valor da tabela hash é uma operação rápida, e percorrer sequencialmente uma árvore B é uma operação eficiente. No entanto, se você tiver uma coleção grande de itens, pode demorar um pouco para ler e devolver os itens. Imagine executar uma Queryoperação que corresponda a todos os itens em uma coleção de itens com 10 GB no total. São muitas E/S, tanto no disco quanto na rede, para lidar com tantos dados.
Por causa disso, o DynamoDB impõe um limite de 1 MB em Querye Scan, as duas operações de leitura de 'busca de muitos' no DynamoDB. Se sua operação tiver resultados adicionais após 1 MB, o DynamoDB retornará uma LastEvaluatedKeypropriedade que você pode usar para lidar com a paginação no lado do cliente.
Esse limite é o requisito final para que o DynamoDB ofereça garantias de latência de milissegundos de um dígito em qualquer consulta em qualquer escala. Vamos revisar as operações envolvidas em uma grande operação de consulta:
file_9.wmf
Operação	Estrutura de dados	Notas
1. Encontre o nó para a chave de partição	Tabela hash	Complexidade de tempo deO(1)
2. Encontre o valor inicial para a chave de classificação	Árvore B	Complexidade de tempo de O(log n), onde nestá o tamanho da coleção de itens, não da tabela inteira
3. Leia os valores até o final da correspondência da chave de classificação	--	Leitura sequencial. Limitado a 1 MB de dados
Simplesmente não há muito espaço para que o desempenho de uma única consulta seja prejudicado à medida que seu aplicativo é dimensionado. A operação inicial para segmentar por chave de partição ajuda a restringir sua tabela de uma escala gigantesca (100 TB) a uma coleção de itens únicos (geralmente <10 GB). Em seguida, a pesquisa na árvore b é executada em uma quantidade gerenciávelde dados e os riscos do disco são limitados.
Uma nota final sobre as implicações desta delimitação antes de prosseguir. O DynamoDB não oferece suporte para nenhuma operação de agregação, como max, min, avgou sum. Meu palpite é que isso se deve a esse limite de 1 MB, pois pode retornar resultados inconsistentes. Imagine que você tem uma coleção de itens de 1 GB e executa um Queryarquivo nessa coleção de itens com uma maxagregação em um atributo específico. O DynamoDB deseja ler apenas 1 MB de dados nessa solicitação, portanto, isso maxse aplicaria apenas ao 1 MB lido, e não a todo o 1 GB de dados na coleção de itens.
Isto poderia confundir os usuários quanto ao comportamento das agregações. Provavelmente é melhor para o aplicativo lidar com agregações no momento da gravação, armazenando informações agregadas em um item de resumo em uma coleção de itens.
Além disso, se você deseja o maxvalor do conjunto de resultados de 1 MB que foi retornado, é muito simples calcular esse lado do cliente em seu aplicativo com uma quantidade bastante pequena de dados. Portanto, acho improvável que vejamos qualquer suporte explícito à agregação Queryou Scanoperações num futuro próximo.
Onde você pode ver problemas de desempenho com o DynamoDB conforme você 
Nas seções acima, vimos como o DynamoDB foi projetado para fornecer escala massiva, fazendo você considerar questões de escalabilidade antecipadamente. Na grande maioria dos aplicativos, sua tabela DynamoDB terá exatamente o mesmo desempenho em testes e milhões de solicitações por segundo.
No entanto, há duas situações em que você pode observar degradação do desempenho à medida que seu aplicativo é dimensionado. Essas situações são:
Paginação
Teclas de atalho
Vamos cobrir cada um deles abaixo.
Anteriormente, vimos como o DynamoDB limita o tamanho do resultado de uma operação Queryou Scana 1 MB de dados. Mas o que acontece se a sua operação tiver mais de 1 MB de dados? O DynamoDB retornará uma LastEvaluatedKeypropriedade em sua resposta. Essa propriedade pode ser enviada com uma solicitação de acompanhamento para continuar folheando sua consulta de onde você parou.
Essa paginação pode incomodar você conforme você escala. Quando seus dados são pequenos ou estão em teste, talvez você não precise folhear os resultados ou pode ser apenas uma única solicitação de acompanhamento para buscar a segunda página de resultados. À medida que seus dados crescem, você pode descobrir que esse padrão de acesso demora cada vez mais, pois são necessárias várias páginas.
Felizmente, esse problema é muito fácil de identificar antecipadamente e considerar. Na maioria das vezes, você pode pesquisar a string em sua base de código LastEvaluatedKey. Se você não vir essa propriedade, é provável que não esteja usando paginação e possa pular totalmente esta seção.
Observação: existem outras maneiras de paginar sem usar LastEvaluatedKey, como se você estiver usando um Query Paginator no Boto3 ou se estiver usando um cliente DynamoDB de terceiros que oferece suporte a paginação mais fácil. Se for esse o caso, você precisará olhar mais de perto para ver se está fazendo paginação.
Se você estiver fazendo paginação, precisará pensar mais. Considere as seguintes questões:
Esta paginação está em um caminho ativo onde o tempo de resposta é importante (por exemplo, uma solicitação HTTP voltada para o usuário)?
Existe uma chance de que o tamanho do resultado de uma consulta cresça a ponto de exigir várias (3+) páginas para obter todos os resultados?
Se sim para os dois acima, onde devo lidar com a paginação?
Vejamos um exemplo. Imagine que você está construindo um jogo online multijogador, como Fortnite, onde os jogadores jogam vários jogos ao longo do tempo. Você tem um padrão de acesso - ListGamesForPlayer- onde um jogador pode ver os jogos anteriores que jogou.
Com o tempo, o número de jogos para um único jogador aumentará tanto que você precisará usar paginação para ver os resultados. Ao projetá-lo inicialmente, você pode pensar em buscar todos os resultados em seu aplicativo e depois devolvê-los ao cliente:
file_10.wmf
ListGamesForPlayer – Paginação do aplicativo
No exemplo acima, o usuário faz uma solicitação ao backend para os jogos do usuário. Neste caso, há muitos jogos – mais de 11.000. O aplicativo busca todos esses jogos no backend e os retorna ao usuário.
Esse endpoint ficará mais lento com o tempo para jogadores com muitos jogos, pois o servidor de aplicativos fará toda a paginação naquela única solicitação do cliente.
Se você pensar bem, o jogador que está visualizando esses resultados provavelmente não conseguirá visualizar todos os resultados de uma vez. Visualizar 11.000 resultados em uma página é incontrolável. Eles provavelmente desejam ver os 10 ou 20 resultados mais recentes e raramente desejam se aprofundar nos resultados antigos.
Você pode mudar para que a paginação aconteça no cliente . O ListGamesForPlayerendpoint retorna apenas os 20 resultados mais recentes. Caso o usuário queira ver mais, o aplicativo cliente terá um Nextbotão ou usará rolagem infinita para buscar jogos adicionais.
Agora nosso padrão de acesso fica assim:
ListGamesForuser – paginação do cliente
file_11.wmf
O usuário solicita uma lista de jogos. O aplicativo faz uma única solicitação ao DynamoDB e retorna os primeiros vinte jogos, bem como a hora do último jogo lido. Podemos mostrar vinte jogos em uma UI com bastante facilidade.
Se o usuário quiser revisar jogos mais antigos, o frontend pode usar páginas ou rolagem infinita para permitir que os usuários se aprofundem. Isso faria uma solicitação de acompanhamento ao aplicativo para solicitar jogos antes do último visto. Obteríamos os próximos vinte resultados para mostrar ao usuário.
file_12.wmf
ListGamesForuser – segunda solicitação de paginação do cliente
Nosso endpoint permanece ágil e apenas paginamos os dados para buscar mais resultados quando o usuário realmente precisa deles.
Para obter informações adicionais sobre padrões de paginação no DynamoDB, leia a postagem de Yan Cui, Pessoal, estamos fazendo a paginação errada...
 de atalho
A segunda e mais perniciosa maneira pela qual sua tabela DynamoDB terá problemas ao ser dimensionada é por meio de teclas de atalho.
Uma tecla de atalho é uma coleção de itens acessada com muito mais frequência do que outras coleções de itens em uma tabela. Por exemplo, imagine o Twitter. Justin Bieber , com seus mais de 100 milhões de seguidores, provavelmente será acessado com muito mais frequência do que eu, com meu número de seguidores um pouco menor. Se esses dados fossem lidos diretamente do DynamoDB, as Beliebers poderiam causar uma tecla de atalho no perfil de Justin.
As teclas de atalho podem aparecer em vários padrões diferentes. Você pode ter uma única tecla consistentemente quente, como no exemplo de Justin Bieber acima. Isto também pode ser verdade se você não projetar sua chave de partição corretamente e tiver uma carga de trabalho desequilibrada. Em uma linha diferente, você também pode fazer com que teclas diferentes fiquem quentes em momentos diferentes. Imagine um site de ofertas relâmpago onde diferentes itens foram colocados à venda por curtos períodos de tempo. Enquanto um item estiver à venda, ele será acessado com muito mais frequência do que os outros itens.
Há boas e más notícias em torno das teclas de atalho.
A boa notícia é que as teclas de atalho são principalmente um problema para aplicações de grande escala. E este é um bom problema para se ter! Parabéns por fazer algo que as pessoas usam. Por um tempo, você pode optar por se afastar do problema. O DynamoDB tem no máximo 3.000 RCUs e 1.000 WCUs em uma única partição .https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html RCUs e WCUs são feitos por segundo, então você pode ler um item de 4 KB 3.000 vezes por segundo e ainda assim ficar bem. Isso é bastante espaço para a maioria das aplicações.
Além disso, o DynamoDB trabalhou muito nos últimos anos para ajudar a aliviaros problemas relacionados às teclas de atalho. O DynamoDB é usado para distribuir uniformemente a taxa de transferência provisionada pelas partições. Isso significava que você precisava provisionar demais sua taxa de transferência para lidar com a partição mais ativa. Isso mudou em 2017, quando o DynamoDB anunciou capacidade adaptativa https://aws.amazon.com/pt/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/. A capacidade adaptável transfere automaticamente o rendimento da sua tabela para as partições que mais precisam dele. Inicialmente, levaria alguns minutos para que a capacidade adaptativa reagisse a uma partição quente. Em maio de https://aws.amazon.com/pt/about-aws/whats-new/2019/05/amazon-dynamodb-adaptive-capacity-is-now-instant/a AWS anunciou que a capacidade adaptativa do DynamoDB agora é instantânea . Além disso, eles anunciaram um recurso no final de 2019 para isolar automaticamente itens quentes ,https://aws.amazon.com/pt/about-aws/whats-new/2019/11/amazon-dynamodb-adaptive-capacity-now-handles-imbalanced-workloads-better-by-isolating-frequently-accessed-items-automatically/ movendo-os para outra partição.
A má notícia sobre as teclas de atalho é que pode ser muito complicado conhecê-las ao projetar sua mesa. Não existe um indicador fácil como a LastEvaluatedKeypropriedade no caso de uso de paginação. Estamos quase de volta ao mundo SQL, onde há pouca visibilidade sobre o desempenho da sua consulta à medida que ela é dimensionada.
Uma ferramenta útil nessa área é o CloudWatch Contributor Insights for DynamoDB .https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/contributorinsights_HowItWorks.html Quando você habilita o CloudWatch Contributor Insights em sua tabela ou índice secundário do DynamoDB, o DynamoDB desconectará a partição e classificará as chaves acessadas em sua tabela. Você pode usar gráficos do CloudWatch para encontrar as chaves acessadas com mais frequência e ver como elas se comparam ao restante dos itens da sua tabela.
Isso será útil se você puder gerar tráfego representativo em seu ambiente de teste ou até mesmo no início do lançamento de seu aplicativo. O monitoramento desses CloudWatch Contributor Insights pode ajudá-lo a identificar possíveis problemas antes de começar a atingir o limite de 3.000 RCU em uma única partição.
Nesta postagem, descobrimos por que o DynamoDB pode parecer tão inflexível quando você o aprende pela primeira vez. Vimos como o DynamoDB 'muda para a esquerda' na escalabilidade, fazendo você considerar a escalabilidade durante a fase de design da tabela. Em seguida, vimos os três motivos pelos quais os bancos de dados relacionais enfrentam problemas em escala e as três decisões de design que o DynamoDB toma para evitar esses problemas. Por fim, analisamos duas áreas onde você pode ver problemas de desempenho com o DynamoDB.
O DynamoDB é uma ótima ferramenta e você deve considerar quando ela é adequada para sua arquitetura. Se você deseja um banco de dados que seja dimensionado perfeitamente à medida que a popularidade de seu aplicativo cresce, vale a pena aprender o DynamoDB e projetar sua tabela adequadamente.
Os conceitos deste post estão necessariamente compactados devido ao formato. Se você estiver interessado em saber mais sobre este e outros tópicos relacionados, não deixe de conferir o excelente livro de Martin Kleppmann, Designing Data-Intensive Applications .https://dataintensive.net/
Se você tiver dúvidas ou comentários sobre esta peça, sinta-se à vontade para deixar uma nota abaixo ou me enviar um e-mail diretamente .
é:
Dfufumrh, mbu svc pftjuovd etvä ioermqnhtb0 Vpeí psgfitc pvdoidcu unc npxd pftjuovd.