ExtendDB: Execute o DynamoDB API em seu banco de dados

Digamos que um sistema de registros hospitalares precise ficar dentro do prédio – os dados do paciente podem nunca saia da rede local, um auditor assina todas as dependências e os laptops de desenvolvimento não têm internet alguma. A equipe já escreveu o aplicativo contra o DynamoDB API e gosta: pesquisas de chave de milissegundos de um dígito, um modelo de item limpo, sem migrações de esquema para babá. Mas o DynamoDB gerenciado é um serviço em nuvem e "enviar os dados para AWS" é um fracasso aqui.

ExtendDB foi criado exatamente para essa lacuna. Ele fala o Protocolo de conexão DynamoDB, mas armazena os dados em um banco de dados que você executa.

O que é ExtendDB?

ExtendDB é o adaptador de código aberto do AWS (escrito em Rust) que implementa o protocolo de conexão DynamoDB JSON em cima de um banco de dados que você mesmo executa, como PostgreSQL. Seus SDKs AWS existentes e a CLI do AWS continuam funcionando inalterados – apenas o endpoint URL é movido – então você obtém o DynamoDB API sem enviar dados para o serviço de nuvem gerenciado.

ExtendDB é um adaptador de código aberto do AWS - escrito pelos engenheiros do AWS DynamoDB e anunciado no blog do banco de dados AWS — que implementa o protocolo de fio DynamoDB JSON em Rust. Porque isso responde ao mesmo HTTP API que o serviço gerenciado responde, seus SDKs AWS existentes e a CLI do AWS funciona inalterada. A única coisa que se move é o endpoint URL — sem reescrita de código, sem nova biblioteca cliente.

A parte interessante é o que está por trás do API. ExtendDB tem conectável back-ends de armazenamento : PostgreSQL é a implementação de referência e Cassandra é citado como outro possível back-end. Novos back-ends são implementado sem modificar o núcleo, portanto a camada de compatibilidade DynamoDB e a camada de armazenamento evolui de forma independente.

Portanto, uma solicitação flui assim:

O que ele suporta — e o que não suporta

De acordo com os documentos de primeiros passos e o anúncio, ExtendDB (v0.1) cobre as operações que a maioria dos aplicativos realmente chama:

• Tabelas — Criar, Excluir, Descrever, Listar, Atualizar.
• Itens — Colocar, Obter, Excluir, Atualizar (incluindo SET / REMOVE / ADD / Ações de atualização do DELETE).
• Consulta e verificação — condições principais, filter expressions, projeções, paginação e índices secundários.
• Lote — BatchGetItem e BatchWriteItem.
• Transactions — TransactGetItems e TransactWriteItems.
• Streams, TTL, Importar/Exportar e Tags.

O que ele deliberadamente não implementa é o conjunto de Recursos gerenciados específicos do DynamoDB — mais notavelmente Tabelas Globais e replicação entre regiões. Essas são propriedades do serviço gerenciado infraestrutura global, não da superfície API, para que não sejam transferidos para um adaptador que você mesmo hospeda.

vs DynamoDB local

Você já pode usar DynamoDB Local para desenvolvimento offline. Isso é um único JAR (ou imagem amazon/dynamodb-local Docker) destinado a testes de unidade em um máquina. O objetivo do ExtendDB é mais amplo do que aquela ferramenta de processo único: local desenvolvimento, implantações no local, ambientes de borda e sem ar e configurações híbridas/multinuvem onde você deseja o DynamoDB API, mas os dados residem infraestrutura que você controla.

vs DynamoDB gerenciado

Esta é a linha que o AWS traça explicitamente e é importante:

ExtendDB não é DynamoDB. É uma implementação compatível, não uma substituição para o serviço gerenciado. Características de desempenho, comportamento de escalonamento e as propriedades operacionais diferem.

Concretamente, quando você executa o ExtendDB:

• Você é o proprietário da disponibilidade e dos backups do banco de dados. Não há gerenciamento durabilidade multi-AZ ou recuperação pontual fazendo isso por você - isso é por sua conta e suas operações PostgreSQL.
• TLS é obrigatório no endpoint.
• As credenciais são semelhantes às do IAM, mas separadas do AWS IAM — o ExtendDB tem o seu próprio modelo de credencial; ele não é autenticado em sua conta AWS.

É v0.1 e licenciado Apache 2.0. Trate-o como um software antigo: ótimo para os ambientes acima, não uma troca imediata para DynamoDB gerenciado em escala de produção.

O próprio ExtendDB não mede RCU ou WCU - a capacidade é o problema do PostgreSQL. Quando as mesmas chamadas API atingiram DynamoDB gerenciado em us-east-1 on-demand, um 1 KB Notas PutItem 1 WCU e 4 KB Notas GetItem 0,5 RCU eventualmente consistente. Benchmark ExtendDB para latência; use o calculadora de preços para comparar o que a nuvem bill seria semelhante ao mesmo padrão de acesso.

Configuração

ExtendDB é executado em Linux e macOS e precisa de Rust 1.85+ e PostgreSQL 14+. O fluxo consiste em dois comandos:

extenddb init
extenddb serve

init provisiona o esquema em seu banco de dados PostgreSQL; serve inicia o servidor de protocolo wire, que escuta em um endpoint como https://127.0.0.1:8000 (TLS é necessário, portanto https).

Aponte o SDK do AWS para ele da mesma forma que faria com qualquer endpoint personalizado – apenas o URL e as credenciais mudam:

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

Tudo além da configuração do cliente — PutItem, Query, TransactWriteItems — é idêntico ao código que você escreveria no DynamoDB gerenciado. Uma mesa única o layout do item funciona exatamente como na nuvem:

Faça isso no DynoTable

Como o ExtendDB fala o protocolo de conexão DynamoDB, você não precisa de um ferramenta de administração para ele - aponte DynoTable no endpoint ExtendDB o da mesma forma que você conectaria DynamoDB Local: crie um off-line perfil (local) com a porta ExtendDB e credenciais descartáveis e DynoTable irá navegar, consultar e editar os itens - exceto que agora eles são apoiados pelo PostgreSQL em seu próprio disco, em vez de no armazenamento na memória de um JAR.

Esta é a recompensa da compatibilidade do protocolo wire: o SQL Workbench, o construtor de consulta visual e item editar todo o trabalho no ExtendDB inalterado, para que você obtenha uma GUI real em seu dados auto-hospedados sem escrever scripts scan.

Uma advertência a ser planejada: o endpoint do ExtendDB é somente HTTPS, enquanto o do DynoTable perfil offline (como a maioria das configurações DynamoDB-Local) tem como alvo um loopback host:port. Se o seu cliente ou ferramenta precisa de um ouvinte de loopback de texto simples, encerre o TLS na frente do ExtendDB (ou execute um proxy reverso local) e aponte o GUI – o protocolo no fio ainda é DynamoDB JSON de qualquer maneira.

Armadilhas

• Não trate a v0.1 como DynamoDB de produção. Dimensionamento, latência e durabilidade são seus PostgreSQL, não AWS. Referência para sua carga de trabalho antes de você depende disso.
• Sem tabelas globais/replicação entre regiões. Se o seu design depende de ativo-ativo multirregional, ExtendDB não é o caminho - é um serviço gerenciado recurso.
• Faça você mesmo o backup do banco de dados subjacente. Não há PITR gerenciado; um O volume do PostgreSQL descartado desapareceu. Conecte o arquivamento pg_dump / WAL como qualquer outro outro PostgreSQL.
• As credenciais são do próprio ExtendDB, não do AWS IAM. Não espere políticas do IAM, funções ou chaves de condição para controlar o acesso - esse modelo de autorização não transportar.

Próximos passos

• Modele seus padrões de acesso primeiro – o mesmo A disciplina design de mesa única se aplica se o backend é DynamoDB ou PostgreSQL-via-ExtendDB.
• Construa e inspecione suas leituras e escritas com o Construtor de expressão DynamoDB e, em seguida, converta luminárias entre JSON simples e o formato de fio com o Conversor DynamoDB-JSON.
• Quando estiver pronto para acessar uma instância ativa do ExtendDB, conecte-se DynoTable e navegue como qualquer outra tabela.