Desenvolvimento com Amazon DynamoDB

A Amazon fornece um kit para desenvolvimento (software development kit ou SDK em inglês) para as tecnologias: Android, iOS, Java, .NET, PHP e Ruby. Esse kit permite o desenvolvimento e integração com toda a plataforma de serviços em nuvem da Amazon, inclusive com o DynamoDB.

Como o Kwitter foi desenvolvido em .NET, existem duas formas de realizar a codificação:

  • Primeira é utilizando .NET Low-Level API que fornece um controle maior sobre a codificação (pode-se realizar a analogia com o ADO.NET).
  • Segunda é .NET Object Persistence Model que possui uma abstração ainda maior agilizando o desenvolvimento de rotinas mais simples (análogo ao ADO.NET Entity Framework).

Nesse projeto utilizou-se uma junção de ambos. Na parte de gravação de registros, foi utilizado .NET Object Persistence Model, já, na parte de consultas seletivas (query), foi utilizada a .NET Low-Level API. Isso permitiu um controle melhor e mais especifico buscando o melhor desempenho nas consultas.

O principal motivo pelo qual o DynamoDB foi escolhido entre os bancos de dados apresentados foi pelo fornecimento da infraestrutura juntamente com o SGBD. Como já mencionado, esse critério foi plenamente atendido pela Amazon, fornecendo uma arquitetura robusta e escalável a um valor justo.

Uma das principais ressalvas é com relação ao modelo de consistência eventual. Porém, isso não se tornou um problema em vista que a mensagem é um registro estável, uma vez gravada não é mais alterada, o que pode ocorrer é a alteração na taxonomia necessitando uma reanalise de cada mensagem, mas isso não é uma necessidade constante.

Mesmo que as mensagens fossem seguidamente alteradas, seria necessária uma quantidade muito grande de acessos multiusuário ao mesmo registro para causar problemas, já que a latência da aplicação é muito baixa.

Uma das grandes dificuldades percebida é que a equipe de desenvolvimento tem que se adaptar aos novos tempos. O desenvolvimento tem que pensar em como fazer melhor uso da arquitetura, pois agora o custo de uso é medido rapidamente. No modelo de banco de dados relacional quando uma aplicação não está obtendo muito desempenho deixa-se ao cargo do DBA criar índices ou stored procedure. Neste paradigma a criação de uma nova tabela vai necessitar de desenvolvimento, além de um monitoramento das métricas do sistema, mas enquanto isso não acontece o custo de aumentar a vazão de uma determinada tabela pode ser alto.

O DynamoDB atendeu todas as expectativas de um banco de dados, o autor desse trabalho com base na experiência de 8 anos utilizando o modelo relacional, o DynamoDB se encaixaria em muitas dessas aplicações, em alguns casos muito melhor que o banco relacional adotado. Um exemplo é o sistema para controle de ponto eletrônico onde é necessário armazenar cada uma das batidas de cada funcionário.

Mais informações e referências podem ser encontradas na página Avaliação NOSQL para indexação do Twitter.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s