Dynamo DB em um projeto Django: vale a pena?

As migrações e modelos do Django são ferramentas que permitem desenvolvimento e entrega rápidos e contínuos em projetos ágeis. Além disso, graças ao seu ORM (Object Relational Mapping), um projeto pode migrar de um banco de dados para outro, fazendo com que a lógica de negócios não seja afetada pelo local de armazenamento. E embora o ORM do Jango não suporte todos os bancos de dados existentes, dependências externas podem ser usadas.

Por outro lado, um banco de dados que está sendo muito utilizado é o Dynamo DB, pois permite que a capacidade de cada tabela seja ajustada automaticamente sob demanda. Essa flexibilidade e integração com outros serviços da Amazon Web Services (AWS) são recursos atraentes para usar em um aplicativo.

Boto3 e Pynamo DB (interface do Dynamo com Python) são as melhores alternativas desenvolvidas para conectar o Django com o Dynamo DB. No entanto, se você deseja integrar o Dynamo DB no início ou no processo de desenvolvimento de um projeto Django, há algumas coisas a serem lembradas. E então mostro as vantagens e desvantagens de fazer essa integração com Pynamo DB, Boto3 e Django.db.models.

Tabelas e atributos no DynamoDB

Criar uma tabela é elementar para trabalhar com o Dynamo DB. Para fazer isso, 3 abordagens podem ser usadas:

Pynamo DB

• Um código mais rápido e de fácil manutenção pode ser escrito por meio de sua classe Model. O código a seguir mostra que basta definir os atributos da tabela e as chaves hash e range.
• Tendo uma estrutura semelhante a django.db.models.Model, a migração de outro banco de dados é fácil, pois permite reaproveitar a lógica e apenas alterar a assinatura de alguns métodos ou inicializações.

• Está alinhado com o padrão de projeto Django. Existe uma classe equivalente para cada campo em django.db.models e até mesmo uma classe chamada JSONAttribute que permite armazenar conteúdo JSON.

Boto3

• É uma biblioteca de nível inferior com a qual a definição de um modelo ou classe que pode ser usado em nosso aplicativo é mais tediosa. Por esse motivo, devemos implementar uma classe semelhante a pynamodb.models.Model.

• Estas definições dependem das necessidades do projeto, embora devam ser incluídos alguns métodos para definir e modificar os atributos de uma tabela. Embora a classe ModelBoto3 seja reutilizável, isso exigiria bastante esforço de desenvolvimento e teste, o que é valioso ao iniciar um projeto.
  

Django.db.models.Model

Outra abordagem possível para definir uma tabela e seus atributos é usar o modelo django.db.models.Model, reescrevendo os métodos create, create, from_db, __init__ e save, entre outros.

A vantagem é a economia de tempo e esforço no início do projeto, mas isso pode variar de acordo com a necessidade do projeto, por exemplo _save_table ao atualizar as chaves hash e range. Além disso, deve-se acrescentar que os atributos da tabela devem ser criados do zero, semelhante ao caso do Boto3.

Actualização de atributos

Embora seja verdade que as migrações no Django permitem atualizações de tabelas, objetos ou documentos em bancos de dados por meio de modelos, essas operações têm uma diferenciação mais marcante para cada abordagem mencionada na seção anterior.

Pynamo DB

Adicionar ou remover um atributo simples é relativamente rápido. Por exemplo, se regimen_laboral (regime de trabalho em português) for adicionado como um campo opcional, basta escrever o seguinte:

No Dynamo DB, esse atributo terá automaticamente um valor nulo para os registros existentes, enquanto os novos registros podem ter um valor.

• No caso de ter um valor padrão, você deve realizar uma migração de dados no Django e escrever o código para obter todos os registros anteriores e atualizar o novo valor para regimen_laboral.

Para isso, você precisa criar uma migration vazia:

Lembre-se de que app deve ser substituído pelo nome do aplicativo no qual você está trabalhando.

O comando executado criará um arquivo e você deverá substituí-lo pelo seguinte conteúdo:

WorkerBoto3Table deve ser o nome da tabela nos Metadados da tabela WorkerBoto3. Você pode fazer uma varredura ou uma consulta para obter os registros nos quais deseja adicionar um valor padrão para o novo campo regimen_laboral.

Lembre-se que caso você tenha um grande número de registros no DynamoDB, você pode melhorar o tempo de execução dessa data migration usando algum método de atualização em lote como batch_update_table_rows.

Até aqui tudo parece ser simples, mas fica complicado quando você quer alterar, adicionar ou remover uma hash key ou range key.

Actualização de chaves de uma tabela

O Dynamo DB permite que você trabalhe com duas chaves primárias em uma tabela: hash key y range key. A primeira chave é um identificador único que o diferencia dos demais registros e sua ideia é mais próxima de uma chave primária de um banco de dados.

Por outro lado, uma range key pode representar dois atributos de registro que permitem que um item seja identificado de forma única (por exemplo, registros de viajantes com uma determinada companhia aérea podem ter um identificador, id ou chave primária, mas também podem ser identificados pelo bilhete de identidade do viajante juntamente com o identificador do voo).

Esses conceitos são importantes porque caso se queira modificar a chave primária em uma tabela relacional, pode-se realizar a seguinte sequência de passos:

• Copie a tabela para uma tabela temporária com outro identificador temporário e um novo campo com o novo identificador (com outro nome e como campo comum).
• Exclua a primeira tabela ou original.
• Crie a primeira tabela novamente com o esquema atualizado.
• Copie os dados da tabela temporária para a nova tabela.

Pynamo DB

Com o Pynamo DB, esse processo é longo porque é aplicado da mesma forma que seria feito com outro banco de dados relacional como Postgres ou MySQL.

Primeiro, o processo de copiar de uma tabela para outra pode ser feito desta forma:

Se você tiver acesso para descartar uma tabela do Dynamo DB da interface com a qual se comunica a partir do seu projeto Django, não deverá ter problemas. Você pode usar a instrução a seguir, substituindo WorkerPynamoDB pelo nome de seu modelo original.

Caso você não tenha permissões de sua interface, você deve fazer uma cópia local ou em outro ambiente, solicitar a exclusão e criação da tabela e fazer a cópia com o novo esquema.

Além disso, você pode recriar uma tabela com WorkerPynamoDB.create_table() no Pynamo DB com:

Boto3

• Se você estiver usando o Boto3, o processo é demorado porque a mesma sequência de etapas também deve ser executada, embora você deva usar um cliente ou recurso Boto3. Por exemplo:

• Por outro lado, o processo de recriação da tabela original é simples e basta adicionar algumas linhas de código e criar um comando shell para ser executado no pipeline do projeto ou fazê-lo manualmente.

Se você acha que com isso a parte difícil acabou, você se engana porque existem mais dois cenários:

1. Modificar um Global Secondary Index (GSI) ou um Local Secondary Index (LSI).
2. Modificar o tipo de dado de um GSI ou LSI.

Modificar um GSI ou LSI

É importante saber a diferença dos índices. Um GSI é um índice que possui uma chave de partição e uma chave de classificação opcional diferente da chave primária da tabela base. E um LSI é um índice que deve ter a mesma chave de partição, mas uma chave de classificação diferente da tabela base.

Por outro lado, um GSI não possui restrição de tamanho enquanto um LSI possui. Para cada valor de chave de partição, o tamanho máximo é de 10 GB. Em um GSI, a criação e exclusão podem ser feitas a qualquer momento, enquanto no LSI somente quando a tabela DDB é excluída.

Pynamo DB

Adicionar ou remover um GSI é uma tarefa que não é tão fácil usando o Pynamo DB e, na prática, muitas vezes é necessário, especialmente quando você deseja criar um novo filtro para um modelo.

Você pode usar uma varredura, mas essa operação é muito cara em termos de recursos e tempo, portanto, usar uma query é mais conveniente.

Boto3

• Nesse caso, o Boto3 possui métodos que permitem a interação em um nível inferior e, portanto, modificar os índices em um modelo existente é possível e mais intuitivo.

• Permite aprimorar integrações com outras bibliotecas de forma mais limpa. Várias chamadas para outros métodos são feitas no código, porque as tabelas de modelo são usadas com o Pynamo DB. O método _hash_key_attribute retornará a chave hash da tabela, caso o índice possua uma range key, ela também deve ser chamada e armazenada em outra variável.

O código dentro de update_table cresce de acordo com o número de atributos que a tabela possui e deve levar em consideração que pelo menos todos os atributos obrigatórios (null=False) devem ser incluídos em AttributeDefinitions e o tipo de dados deve ser honrado com aquele que é salvo no Dynamo DB.

• Outra característica importante do Boto3 é que várias atualizações de índice podem ser feitas em uma atualização ou update_table. No exemplo, é atualizado um GSI, que é adicionado em GlobalSecondaryIndexUpdates, mas se você quiser modificar um LSI, também pode enviá-lo no parâmetro LocalSecondaryIndexUpdates.
  

Modificar tipo de dado GSI ou LSI

Agora, alterar o tipo de dados de uma chave (hash key o range key) de um índice é um processo mais longo, pois envolve fazer uma cópia dos dados já existentes (como na primeira parte desta seção) e depois uma atualização com o Boto3 como acabou de explicar.

Pode haver casos mais estruturados de atualizações nas tabelas. No entanto, esses casos representam uma abordagem que pode ser aplicada em situações mais complexas.

Conexão de banco de dados

Pynamo DB

• As configurações de conexão do projeto são transparentes, pois podem ser abstraídas por meio de variáveis ​​de ambiente e das principais configurações do projeto (geralmente em settings.py).

Os valores devem ser definidos para cada ambiente e as classes do Pynamo DB usam automaticamente essas variáveis ​​para usar o banco de dados em nuvem.

Se você quiser trabalhar localmente, lembre-se que 'AWS_REGION_NAME' deve ter o valor de local e os valores de 'AWS_ACCESS_KEY_ID' e 'AWS_SECRET_ACCESS_KEY' são nulos por padrão.

Boto3

• Embora você mesmo deva integrar essa inicialização no pipeline, o esforço necessário é pequeno e pode ser feito escrevendo o seguinte código:

Como alternativa, você pode substituir o uso de um cliente por um recurso da seguinte maneira:

As instruções acima são bem parecidas, mas a diferença entre usar um cliente e um recurso no Boto3 é que o recurso permite realizar operações em um nível superior, como o Pynamo DB, é ideal quando você quer ler registros ou atualizá-los em lotes, como ao executar um backup ou cópia de uma tabela. Por outro lado, usar um cliente permite trabalhar em um nível inferior, como atualizar o esquema de uma tabela ou índice.

Conclusão

Resumindo, a manutenção do código em produção ao trabalhar com Dynamo DB e Django vai depender das necessidades do projeto que está sendo realizado, muitas vezes a escolha de uma solução não vai cobrir todas essas necessidades, então você pode combinar essas bibliotecas entre si. , principalmente para migrações ou atualizações de esquema.

Espero que este artigo tenha lhe dado uma ideia dos desafios que você enfrentará com essas tecnologias e lhe dê uma visão melhor ao escolher a tecnologia ou tecnologias a serem usadas.

Se você tiver perguntas mais específicas ou quiser conversar sobre esse assunto, pode me escrever em milapacompiamachaca@gmail.com ou me encontrar no LinkedIn.