Por que o Amazon DynamoDB não é para todos

Como decidir quando é certo para você

Em 2004, o negócio da Amazon já estava esticando os limites de sua infraestrutura de banco de dados Oracle. A fim de escalar o negócio em crescimento, a AWS criou uma loja de valor-chave interna premiada – Amazon Dynamo – para atender aos requisitos de desempenho, escalabilidade e confiabilidade.

Dínamo da Amazônia
Em duas semanas, apresentaremos um artigo sobre a tecnologia Dynamo no SOSP, o prestigiado sistema operacional bianual … www.allthingsdistributed.com

O Amazon Dynamo agora está subjacente a uma grande parte da Amazon.com e definiu uma categoria totalmente nova de bancos de dados de lojas de valores-chave – "NoSQL". Em 2012, a AWS anunciou a disponibilidade do DynamoDB como um serviço de dados NoSQL totalmente gerenciado para clientes com a promessa de escalabilidade contínua.

Por que usar DynamoDB?

Como o Dynamo comemora seu décimo aniversário , a AWS deve considerar um serviço complementar chamado " WhynamoDB ". Toda vez que um desenvolvedor tentar fornecer uma nova tabela DynamoDB, o serviço apareceria no AWS Console e simplesmente perguntaria: " Por quê?"

A resposta para " por que usar DynamoDB " não é tão direta quanto a promessa de marketing de escalabilidade contínua.

Nas últimas semanas, entrevistei vários engenheiros e desenvolvedores sobre suas experiências com o serviço de banco de dados. Tão excelente quanto o DynamoDB é – e tão excitante como as suas histórias de sucesso – também deixou muitas implementações falhadas no auge.

Existem poucos casos de uso adequados para DynamoDB | Notícias do hacker
Fundamentalmente, o problema parece ser a escolha de uma chave de particionamento apropriada para as operações … news.ycombinator.com da DynamoDB

Para entender o que faz com que algumas implementações do DynamoDB sejam bem-sucedidas e outras falhem, precisamos examinar a tensão essencial entre as duas grandes promessas do DynamoDB – simplicidade e escalabilidade.

DynamoDB é simples – até que ele não escala

Eu realmente não posso exagerar o quão fácil é começar a lançar dados no DynamoDB. A equipe da AWS fez um ótimo trabalho de abstrair a complexidade – você não precisa se conectar a um estúdio de gerenciamento, não precisa se preocupar com drivers de banco de dados, você não precisa configurar um cluster.

Para começar com o DynamoDB, basta girar um botão para a capacidade provisória, pegar seu SDK favorito e começar a jogar JSON.

Com esse conjunto de recursos, não é de admirar que o DynamoDB seja especialmente atraente para desenvolvedores de aplicativos "sem servidor". Afinal, muitos aplicativos sem servidor começam como protótipos, priorizando a velocidade de entrega e a configuração mínima. Por que mexer com um armazenamento de dados relacionais quando você nem sabe ainda qual será o seu modelo de dados final?

Neste ponto, precisamos fazer uma distinção fundamental – sem trocadilhos. O DynamoDB pode ser simples de interagir, mas uma arquitetura com suporte DynamoDB não é absolutamente simples de projetar.

DynamoDB é uma loja de valor-chave. Funciona muito bem se você estiver recuperando registros individuais com base em pesquisas-chave. As consultas ou varreduras complexas exigem uma indexação cuidadosa e são difíceis ou simples de serem desconsiderados para escrever – mesmo que você não tenha uma quantidade de dados extremamente grande e, mesmo que tenha alguma familiaridade com os princípios de design do NoSQL.

Essa última parte é o kicker, é claro – há uma enorme quantidade de desenvolvedores que não sabem muito sobre o NoSQL em comparação com o design clássico do banco de dados relacional. Além disso, a experiência anterior do NoSQL nem sempre é um positivo líquido. Falei com alguns engenheiros cujos times foram gravados quando trouxeram um monte de expectativas do MongoDB, um banco de dados de documentos, para sua implementação DynamoDB.

Então, quando você combina desenvolvedores inexperientes, a falta de um plano claro sobre como modelar um conjunto de dados no DynamoDB e um serviço de banco de dados gerenciado que facilita a ingestão de muitos dados desestruturados – você pode acabar com uma solução que espira de controle mesmo em pequena escala.

Lynn Langit , um consultor de dados em nuvem com experiência em todas as três grandes nuvens públicas, já viu o suficiente dessas implementações mal sucedidas para se justificar com cuidado de empresas que dependem de soluções NoSQL como o DynamoDB.

Quando entrevistei Lynn recentemente para a série "Serverless Superheroes", ela compartilhou uma história sobre como mover um cliente do DynamoDB para o Aurora – o serviço de banco de dados relacional ING, mesmo que a arquitetura de referência da AWS para o projeto utilizasse o DynamoDB.

"O cliente estava tendo todos os tipos de problemas, e um dia eu simplesmente decidi mudar para Aurora. Freaked todo mundo – eles disseram, 'O que você está fazendo?' Eu disse: "O que estamos fazendo? Nós estamos enviando um produto. ' E nós fizemos. "

A Primeira Lei do DynamoDB
Suponha que uma implementação DynamoDB será mais difícil, não mais fácil, do que usar um banco de dados relacional que você já conhece.

Um banco de dados relacional fará mais qualquer coisa que você precisa em pequena escala. Pode demorar um pouco mais a ser configurado inicialmente do que o DynamoDB, mas as convenções bem estabelecidas de uma implementação de SQL podem protegê-lo de um grande número de dias perdidos no caminho.

Isso não é porque DynamoDB é uma pior tecnologia – mas porque é novo para você, e coisas que parecem "fáceis" e "convenientes" absolutamente o morderão se você não as entender.

DynamoDB é escalável – até que não seja simples

Agora explore o outro extremo do espectro – grandes tabelas do DynamoDB. Para este artigo, entrevistei clientes felizes obtendo latência de sub-segunda com bilhões de registros em suas tabelas DynamoDB. DynamoDB promete desempenho consistente em escala essencialmente infinita, limitada apenas pelo tamanho físico da nuvem AWS.

Sem exceção, esses clientes estão no centro do caso de uso canônico do DynamoDB – fazendo pesquisas de valores-chave em registros bem distribuídos, evitando consultas complexas e, o mais importante, limitando hot keys.

Lidar com hot keys é, sem dúvida, o mais conhecido "gotcha" da DynamoDB. O problema com hot keys é bem explicado em muitos lugares, incluindo a documentação do guia do desenvolvedor DynamoDB .

Melhores Práticas para Tabelas – Amazon DynamoDB
Use estas melhores práticas para trabalhar com itens de tabelas para obter o melhor desempenho com custos de transferência reduzidos usando … docs.aws.amazon.com

Embora o DynamoDB possa escalar indefinidamente, seus dados não são armazenados em um servidor único, mágico e em constante expansão. À medida que seus dados crescem maiores do que a capacidade de um único fragmento DynamoDB, ou "partição" (até 10 GB), ele é dividido em pedaços, cada pedaço morando em uma partição diferente.

Se você tem uma chave "quente" no seu conjunto de dados – um registro específico que você está acessando com freqüência – você precisa ter certeza de que a capacidade provisionada em sua tabela esteja configurada suficientemente alta para lidar com todas essas consultas.

O "gotcha" é que você só pode fornecer a capacidade DynamoDB no nível de toda a tabela – não por partição – e a capacidade é dividida entre as partições usando uma fórmula bastante wonky . Como resultado, sua capacidade de leitura e gravação em qualquer registro é muito menor do que sua capacidade total provisionada.

Portanto, se sua aplicação estiver usando muitas RCUs em uma única chave, você precisará sobrecarregar todas as outras partições (caro), gerar uma tonelada de erros "Excesso de transferência" (não ideal) ou descobrir como diminuir o acesso para essa chave.

Um local de viagem aqui é que o DynamoDB não é necessariamente adequado para conjuntos de dados que tenham uma mistura de registros quentes e frios. Mas a escala suficientemente grande, cada conjunto de dados tem uma mistura dessas. Você poderia dividir os dados em diferentes tabelas, é claro – mas, se você fizer isso, perdeu a vantagem de escalabilidade que o DynamoDB deveria fornecer em primeiro lugar.

Um blog foi publicado recentemente sobre este assunto chamado "The Million Dollar Engineering Problem" . Ele mostrou como o Segmento diminuiu substancialmente sua conta do AWS ao corrigir o excesso de provisionamento do DynamoDB relacionado à chave quente. A parte mais interessante desse artigo são os gráficos do "heatmap" que mostram exatamente quais as partições que foram os problemas.

Um mapa de calor fornecido pela AWS das partições totais, juntamente com a pressão-chave sobre cada

Agora, se você lê as letras finas, esses gráficos legais vieram das ferramentas internas da AWS, e não de qualquer segmento de monitoração que pudesse fazer por conta própria. Em outras palavras, alguém do Segment teve que entrar no telefone com a equipe DynamoDB para obter observabilidade em seus problemas de banco de dados.

Mesmo nesse ponto, sua estratégia para bloquear as chaves ofensivas era uma questão de envolver as chamadas do DynamoDB em uma tentativa / captura – e executando uma lógica de rastreamento personalizada se uma determinada chave tropeçasse uma exceção de transferência.

Com efeito, o Segmento teve que lutar contra o problema das teclas rápidas com uma venda nos olhos, e é aqui que voltamos à tensão entre simplicidade e escala.

DynamoDB é projetado como uma caixa preta com muito poucos controles acessíveis pelo usuário. Esta abordagem facilita o uso quando você está apenas começando. Mas na escala de produção – quando os casos de borda dominam sua vida – às vezes, você precisa desesperadamente de mais informações sobre por que seus dados estão mal-comportados.

Você precisa de um pouco de complexidade compassiva.

A Segunda Lei do DynamoDB
Em grande escala, a usabilidade do DynamoDB é limitada por sua própria simplicidade.

Isso não é um problema com a arquitetura do Dynamo. É um problema com o que a AWS escolheu para expor através do serviço DynamoDB .

Neste ponto, nem sequer abordamos a questão dos backups e restaurações – algo que o DynamoDB não suporta nativamente e que é extremamente complicado na escala. A incapacidade de suportar 100 TB de dados do DynamoDB foi aparentemente uma grande razão pela qual o Timehop ??recentemente deslocou o serviço completamente .

Caso contrário DynamoDB, então, o que?

Então, se DynamoDB é apenas uma das muitas opções plausíveis em pequena escala, e tem viabilidade limitada como um serviço em larga escala – por que é bom?

Se você pedir a AWS, quase qualquer coisa. Afinal – Werner Vogels diz que o design Dynamo original poderia lidar com cerca de 90% das cargas de trabalho da Amazon.com.

Com exceção de certos casos especiais, como análises de BI ou transações financeiras, é verdade que você pode redesenhar apenas sobre qualquer aplicativo para mover os relacionamentos comerciais fora do banco de dados, armazenar estado em uma tabela K / V e usar a arquitetura baseada em eventos para o conteúdo do seu coração.

Mas, como dizia o professor de ciência da computação, também é verdade que "só porque você pode, não significa que você deveria".

Se você não entender completamente por que você está usando o DynamoDB no início, é provável que você acabe como Ravelin girando suas rodas através de várias reescritas de código até finalmente aterrar em uma solução que mais ou menos funciona – mas você ainda é um tipo de ódio .

Você provavelmente não deve usar DynamoDB
Os leitores avid do syslog Ravelin lembrarão uma história do ano passado sobre o uso do DynamoDB. Descreveu alguns … syslog.ravelin.com

A Terceira Lei do DynamoDB
O valor do negócio supera sempre o idealismo arquitetônico.

É por isso que a Lynn Langit tem mais ou menos abandonado o NoSQL como uma solução para pequenas e médias empresas. É por isso que a Timehop ??mudou-se de DynamoDB para Aurora, e por que outra empresa bem conhecida que entrevistei mudou para "um gigante cluster ElasticSearch".

É também por isso que o DynamoDB possui estudos de caso de clientes satisfeitos em marcas famosas. Não porque uma dessas tecnologias seja uniformemente melhor do que outra – mas porque os engenheiros de cada empresa, com seus casos específicos de uso e seus níveis de experiência, conseguiram oferecer valor comercial de forma mais rápida e efetiva com diferentes soluções.

Apresentando Amazon WhynamoDB

Em algum momento, a Amazon pode anunciar o lançamento do serviço WhynamoDB que pergunta "por que você está provisionando uma tabela DynamoDB". Em preparação para o lançamento, criei esta útil árvore de decisão que o orienta através do serviço WhynamoDB .

Qual é a sua experiência e reflexão sobre DynamoDB? Eu estaria interessado em ouvir seus pensamentos nos comentários abaixo!

Se você gostou deste artigo, certifique-se de verificar minhas séries comic FaaS e Furious . Você pode seguir no Twitter onde eu sou @ forrestbrazeal .