ExtendDB: esegui DynamoDB API sul tuo database

Supponiamo che un sistema di registrazione ospedaliero debba rimanere all'interno dell'edificio, i dati dei pazienti possono farlo non lasciare mai la rete in sede, un revisore approva ogni dipendenza e i laptop degli sviluppatori non hanno alcuna connessione Internet. Il team ha già scritto la domanda contro l'DynamoDB API e gli piace: ricerche di tasti a cifra singola in millisecondi, a modello di articolo pulito, nessuna migrazione dello schema a babysit. Ma DynamoDB gestito è un file servizio cloud e "inviare i dati a AWS" non è un punto di partenza qui.

ExtendDB è stato creato esattamente per questo divario. Parla il Protocollo wire DynamoDB ma memorizza i dati in un database eseguito dall'utente.

Cos'è ExtendDB?

ExtendDB è l'adattatore open source di AWS (scritto in Rust) che implementa il protocollo wire DynamoDB JSON su un database eseguito da te, come PostgreSQL. Gli AWS SDK esistenti e la AWS CLI continuano a funzionare invariati (si sposta solo l'endpoint URL), quindi ottieni DynamoDB API senza inviare dati al servizio cloud gestito.

ExtendDB è un adattatore open source di AWS, scritto dagli ingegneri di AWS DynamoDB e annunciato sul blog del database AWS — che implementa il protocollo wire DynamoDB JSON in Rust. Perché esso risponde allo stesso HTTP API del servizio gestito, degli AWS SDK esistenti e la AWS CLI funziona invariato. L'unica cosa che si muove è l'endpoint URL — nessuna riscrittura del codice, nessuna nuova libreria client.

La parte interessante è ciò che si trova dietro l'API. ExtendDB ha collegabile backend di archiviazione: PostgreSQL è l'implementazione di riferimento e Cassandra lo è citato come un altro possibile backend. I nuovi backend sono implementato senza modificare il core, quindi il livello di compatibilità DynamoDB e il livello di archiviazione si evolve in modo indipendente.

Quindi una richiesta scorre in questo modo:

Cosa supporta e cosa no

Secondo la documentazione introduttiva e l'annuncio, ExtendDB (v0.1) copre le operazioni effettivamente chiamate dalla maggior parte delle applicazioni:

• Tables: crea, elimina, descrivi, elenca, aggiorna.
• Items: inserisci, ottieni, elimina, aggiorna (inclusi SET / REMOVE / ADD / azioni di aggiornamento DELETE).
• Query e Scan: condizioni chiave, filter expressions, proiezioni, impaginazione e indici secondari.
• Lotto: BatchGetItem e BatchWriteItem.
• Transactions — TransactGetItems e TransactWriteItems.
• Streams, TTL, Importa/Esporta e Tag.

Ciò che deliberatamente non implementa è l'insieme di Funzionalità gestite specifiche per DynamoDB, in particolare Tables globali e Replica tra regioni. Queste sono le proprietà del servizio gestito infrastruttura globale, non della superficie API, quindi non vengono trasferiti su un'infrastruttura adattatore che ospiti tu stesso.

rispetto a DynamoDB locale

Potresti già usarlo DynamoDB Locale per lo sviluppo offline. Questo è un singolo JAR (o immagine Docker amazon/dynamodb-local) pensato per i test unitari su uno macchina. ExtendDB ha obiettivi più ampi rispetto allo strumento a processo singolo: locale sviluppo, implementazioni in sede, ambienti edge e air-gapped e configurazioni ibride/multi-cloud in cui desideri l'DynamoDB API ma i dati risiedono infrastruttura che controlli.

rispetto all'DynamoDB gestito

Questa è la linea tracciata esplicitamente da AWS ed è importante:

ExtendDB non è DynamoDB. Si tratta di un'implementazione compatibile, non di una sostituzione per il servizio gestito. Caratteristiche prestazionali, comportamento di ridimensionamento e le proprietà operative differiscono.

Concretamente, quando esegui ExtendDB:

• Possiedi la disponibilità e i backup del database. Non c'è gestione La durabilità multi-AZ o il ripristino point-in-time lo fanno per te: dipende da te e le tue operazioni PostgreSQL.
• TLS è obbligatorio sull'endpoint.
• Le credenziali sono simili a IAM ma separate da AWS IAM — ExtendDB ha le proprie modello di credenziali; non esegue l'autenticazione con il tuo account AWS.

È v0.1 e ha la licenza Apache 2.0. Trattatelo come uno dei primi software: ottimo per gli ambienti di cui sopra, non uno scambio immediato con DynamoDB gestito su scala di produzione.

ExtendDB stesso non misura RCU o WCU: la capacità è il problema del tuo PostgreSQL. Quando le stesse chiamate API raggiungono l'DynamoDB gestito in us-east-1 on-demand, un 1 KB PutItem fattura 1 WCU e 4 KB GetItem fattura 0,5 RCU eventualmente coerente. Benchmark ExtendDB per la latenza; utilizzare il calcolatore dei prezzi per confrontare ciò che il cloud la fattura sarebbe simile per lo stesso modello di accesso.

Configurazione

ExtendDB funziona su Linux e macOS e richiede Rust 1.85+ e PostgreSQL 14+. Il flusso è composto da due comandi:

extenddb init
extenddb serve

initeffettua il provisioning dello schema nel database PostgreSQL;serveavvia il server con protocollo wire, che è in ascolto su un endpoint comehttps://127.0.0.1:8000` (È richiesto TLS, quindi https).

Punta l'AWS SDK verso di esso come faresti con qualsiasi endpoint personalizzato: solo URL e le credenziali cambiano:

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>'}
});

Tutto oltre la configurazione del client: PutItem, Query, TransactWriteItems — è identico al codice che scriveresti sull'DynamoDB gestito. Un tavolo unico il layout degli elementi funziona esattamente come nel cloud:

Fallo in DynoTable

Poiché ExtendDB supporta il protocollo wire DynamoDB, non è necessario un protocollo separato strumento di amministrazione per esso: punta DynoTable sull'endpoint ExtendDB il nello stesso modo in cui lo collegheresti a DynamoDB Locale: crea un offline profilo (locale) con la porta ExtendDB e credenziali usa e getta e DynoTable esplorerà, interrogherà e modificherà gli elementi, tranne che ora sono supportati da PostgreSQL sul tuo disco anziché nell'archivio in memoria di un JAR.

Questo è il vantaggio della compatibilità del protocollo wire: il SQL Workbench, il generatore di query visive e item la modifica di tutto funziona su ExtendDB invariata, in modo da ottenere una vera GUI sul tuo dati self-hosted senza scrivere script scan.

Un avvertimento da tenere presente: l'endpoint di ExtendDB è solo HTTPS, mentre quello di DynoTable il profilo offline (come la maggior parte delle configurazioni DynamoDB-Local) mira a un loopback host:port. Se il tuo client o i tuoi strumenti necessitano di un ascoltatore di loopback in testo normale, terminare TLS davanti a ExtendDB (o eseguire un proxy inverso locale) e puntare il file GUI a questo: il protocollo sul cavo è ancora DynamoDB JSON in ogni caso.

Insidie

• Non considerare la v0.1 come DynamoDB di produzione. Scalabilità, latenza e durabilità sono i tuoi PostgreSQL, non AWS. Punto di riferimento per il tuo carico di lavoro davanti a te dipende da questo.
• Nessuna replica Table globale/replica tra regioni. Se il tuo progetto si basa su multi-regione attivo-attivo, ExtendDB non è il percorso: è un servizio gestito caratteristica.
• Eseguire personalmente il backup del database sottostante. Non esiste un PITR gestito; un il volume PostgreSQL caduto è sparito. Collega l'archiviazione pg_dump/WAL come qualsiasi altra altro PostgreSQL.
• Le credenziali sono di proprietà di ExtendDB, non di AWS IAM. Non aspettarti policy IAM, ruoli o chiavi di condizione per governare l'accesso: questo modello di autorizzazione no riporto.

Passaggi successivi

• Modella prima i tuoi modelli di accesso: lo stesso La disciplina progettazione a tabella singola si applica se il backend è DynamoDB o PostgreSQL-via-ExtendDB.
• Costruisci e controlla le tue letture e scritture con DynamoDB Expression Builder, quindi convertire apparecchi tra il semplice JSON e il formato filo con Convertitore DynamoDB-JSON.
• Quando sei pronto per accedere a un'istanza ExtendDB live, connettiti DynoTable e sfoglialo come qualsiasi altra tabella.