A look at the top reasons why teams decide to leave DynamoDB: throttling, latency, item size limits, and limited flexibility…not to mention costs Disclaimer completo: Eu amo o DynamoDB. Ele tem sido comprovado em escala e é o back-end que muitos líderes da indústria têm usado para alimentar cargas de trabalho críticas ao negócio por muitos anos. Ele também se encaixa bem no ecossistema da AWS, tornando super fácil começar, integrar com outros produtos da AWS e manter-se com ele à medida que sua empresa cresce. Disclaimer completo: Eu amo o DynamoDB. Ele tem sido comprovado em escala e é o back-end que muitos líderes da indústria têm usado para alimentar cargas de trabalho críticas ao negócio por muitos anos. Ele também se encaixa bem no ecossistema da AWS, tornando super fácil começar, integrar com outros produtos da AWS e manter-se com ele à medida que sua empresa cresce. Mas (esperamos!), chega um momento em que sua organização cresce bastante significativamente.Com o crescimento maciço, os custos se tornam uma preocupação natural para a maioria das empresas lá fora, e o DynamoDB é frequentemente citado como uma das principais razões para fugas de contas devido à sua modelo de serviço. Pagamento por operação Você provavelmente está pensando: Oh, este é mais um post tentando me convencer de que os custos do DynamoDB são muito altos, e eu deveria mudar para o seu banco de dados, que você vai reivindicar é menos caro”. Embora os custos sejam definitivamente uma consideração importante ao selecionar uma solução de banco de dados (e o ScyllaDB oferece um desempenho de preço bastante impressionante em comparação com o DynamoDB), não é sempre a consideração mais crítica. Se os custos são uma consideração crítica para você, há muitos outros recursos que você pode revisar. ScyllaDB vs. DynamoDB Benchmark: comparando o desempenho de preços entre cargas de trabalho Artigo de Alex Debrie sobre como você deve pensar sobre os custos do DynamoDB Preço muito abrangente do Amazon DynamoDB de Tobias Schmidt explicado Mas vamos mudar a narrativa e discutir outros aspectos que você deve considerar ao decidir se deve se afastar do DynamoDB. HTTPS://WW.SCYLLADB.COMDynamoDB Cost Optimization MasterclassEsta masterclass ensinará estratégias sobre otimização de custos do DynamoDB e outras alternativas da AWS para atender às suas necessidades técnicas. HTTPS://WW.SCYLLADB.COMDynamoDB Cost Optimization MasterclassEsta masterclass ensinará estratégias sobre otimização de custos do DynamoDB e outras alternativas da AWS para atender às suas necessidades técnicas. HTTPS://WW.SCYLLADB.COMDynamoDB Cost Optimization MasterclassEsta masterclass ensinará estratégias sobre otimização de custos do DynamoDB e outras alternativas da AWS para atender às suas necessidades técnicas. HTTPS://WW.SCYLLADB.COMDynamoDB Cost Optimization MasterclassEsta masterclass ensinará estratégias sobre otimização de custos do DynamoDB e outras alternativas da AWS para atender às suas necessidades técnicas. HTTPS://WWW.SCYLLADB.COM em WEB DynamoDB Masterclass de otimização de custos Esta masterclass ensinará estratégias sobre otimização de custos do DynamoDB e outras alternativas da AWS para atender às suas necessidades técnicas. O DynamoDB Throttling Não se divertir em qualquer contexto. Se você já viu isso, provavelmente o odiou e aprendeu a viver com isso.Alguns podem até afirmar que o amam depois de entendê-lo completamente. ProvisionedThroughputExceededException Há uma variedade de maneiras pelas quais você pode se tornar uma vítima do throttling do DynamoDB. Na verdade, acontece com tanta frequência que a AWS até tem uma Uma das recomendações aqui é “mudar para o modo on-demand” antes de realmente discutir padrões de acesso distribuídos uniformemente. Página de solução de problemas dedicada O principal problema com o throttling do DynamoDB é que ele prejudica consideravelmente as latências. cargas de trabalho com uma distribuição Zipfian são propensas a isso... e os resultados alcançados em um benchmark recente não são bonitos: Durante essa referência, tornou-se óbvio que o throttling poderia fazer com que a partição afetada se tornasse inacessível por até Isso aumenta muito as latências da cauda do seu P99. 2.5 seconds Embora seja verdade que a maioria dos bancos de dados tem algum mecanismo de throttling incorporado, o throttling do DynamoDB é simplesmente muito agressivo. É improvável que o seu aplicativo possa escalar ainda mais se acontecer de aceder frequentemente a um conjunto específico de itens atravessando a partição ou os limites da tabela do DynamoDB. A intuição pode dizer: “Bem, se estamos atingindo os limites do DynamoDB, então vamos colocar um cache na frente dele!” É - na verdade - particularmente difícil encontrar números rígidos nos critérios precisos do DynamoDB Accelerator para o throttling, que parece ser principalmente direcionado para a utilização da CPU (o que não é o e) o Tire você para baixo Melhores critérios para loading Latença DynamoDB Você pode argumentar que a distribuição Zipfian mostrada acima visa o calcanhar de Aquiles do DynamoDB, e que a solução da AWS é mais adequada para cargas de trabalho que seguem um tipo uniforme de distribuição. Mesmo dentro do ponto doce do DynamoDB, as latências do P99 são consideravelmente maiores em comparação com o ScyllaDB em uma variedade de cenários. Claro, você pode ser capaz de alcançar latências mais baixas do DynamoDB do que as apresentadas aqui.No entanto, o DynamoDB fica curto quando necessário para fornecer transmissões mais altas, causando latências que eventualmente começam a se degradar. Uma maneira de evitar tais picos é usar o DynamoDB Accelerator (ou qualquer outra solução de cache, na verdade) para um grande impulso de desempenho.Como prometido, eu não vou entrar na discussão de custos aqui, mas sim apontar que as latências de milissegundo de um dígito prometidas do DynamoDB são mais difíceis de alcançar na prática. Para saber mais sobre por que colocar uma memória cache na frente de seu banco de dados é muitas vezes uma má ideia, você pode querer assistir a este vídeo em . Substituindo seu cache com o ScyllaDB DynamoDB Limites de Tamanho de Item Cada banco de dados tem um limite de tamanho de item, incluindo o DynamoDB. No entanto, o limite de 400KB pode eventualmente se tornar muito restritivo para você.Alex DeBrie lança alguma luz sobre isso e explica detalhadamente algumas das razões por trás disso em seu : Blog sobre o DynamoDB O DynamoDB está apontando para como você deve modelar seus dados em um banco de dados OLTP. Os sistemas de processamento de transações on-line (ou OLTP) são caracterizados por grandes quantidades de pequenas operações contra um banco de dados. (...) Para essas operações, você quer filtrar rapidamente e eficientemente em campos específicos para encontrar as informações que você deseja, como um nome de usuário ou um ID de Tweet. O DynamoDB está apontando para como você deve modelar seus dados em um banco de dados OLTP. Os sistemas de processamento de transações on-line (ou OLTP) são caracterizados por grandes quantidades de pequenas operações contra um banco de dados. (...) Para essas operações, você quer filtrar rapidamente e eficientemente em campos específicos para encontrar as informações que você deseja, como um nome de usuário ou um ID de Tweet. Embora seja verdade que cargas úteis menores (ou itens) geralmente fornecerão latências melhoradas, impor um limite rígido pode não ser a melhor ideia. usuários ScyllaDB que decidiram abandonar o ecossistema DynamoDB muitas vezes mencionam esse limite, posicionando-o como um grande bloqueador para a funcionalidade de seus aplicativos. Se você não pode armazenar esses itens no DynamoDB, o que você faz? Você provavelmente vem com estratégias como comprimir as partes relevantes de sua carga útil ou armazená-los em outros meios, como o AWS S3. De qualquer forma, a solução se torna sub-ótima. Na ScyllaDB, tomamos uma abordagem diferente: um único pode ser tão grande quanto 16 MB por padrão (isso é configurável). Acreditamos que você deve ser capaz de decidir o que funciona melhor para você e seu aplicativo. mutation Falando de liberdade: vamos falar sobre... O limitado F do DynamoDB LECTIVIDADE Reedão Reedão Este é bastante fácil. O DynamoDB integra-se perfeitamente dentro do ecossistema da AWS. Mas é exatamente aí que o benefício termina. Assim que você se envolver em uma estratégia multi-nuvem ou decidir mudar para outro fornecedor de nuvem, ou talvez voltar para on-prem (não me faça começar no AWS Outposts!), você inevitavelmente precisará encontrar outro lugar para suas cargas de trabalho. Claro, você NÃO PODE prever o futuro, mas PODE evitar problemas futuros.É isso que diferencia bons engenheiros dos brilhantes: se sua solução está pronta para atender às crescentes demandas de sua organização. Afinal, você não quer se encontrar em uma posição onde você precisa aprender uma nova tecnologia, mudar sua aplicação, realizar testes de carga no novo DBMS, migrar dados, potencialmente avaliar vários fornecedores... Muitas vezes, isso pode se tornar um projeto de vários anos dependendo do tamanho da sua organização e do número de cargas de trabalho envolvidas. As cargas de trabalho do DynamoDB são naturalmente um bom ajuste para o ScyllaDB. Mais frequentemente do que não, você pode simplesmente seguir a mesma modelagem de dados que você já tem no DynamoDB e usá-lo no ScyllaDB. Para permitir que você migre sem problemas se quiser continuar usando a mesma API para se comunicar com seu banco de dados, exigindo assim menos alterações de código. ScyllaDB Alternator – uma API compatível com DynamoDB de código aberto Comentários finais é uma boa postagem do Reddit que você pode querer conferir. cobre uma série de histórias interessantes da vida real, algumas das quais tocam os pontos que cobrimos aqui. Apesar do notório feedback da comunidade, ele inclui uma lista justa de outras considerações que você pode querer estar ciente antes de ficar com o DynamoDB. Pessoas, não me façam começar no DynamoDB... Ainda assim, a primeira frase deste artigo permanece verdadeira: eu amo o DynamoDB. É uma ótima opção e uma solução econômica quando sua empresa ou caso de uso tem requisitos baixos de transmissão ou não é incomodado por alguns picos de latência inesperados. À medida que você cresce, modelar dados e garantir que você não ultrapasse os limites rígidos do DynamoDB pode se tornar particularmente desafiador. Ao selecionar um banco de dados, trata-se, em última análise, de escolher a ferramenta certa para o trabalho. ScyllaDB não é de modo algum um substituto para cada e cada caso de uso do DynamoDB lá fora. com baixa latência, ScyllaDB é sempre a escolha certa. predictable
