Bigtable per gli utenti di DynamoDB

Questo documento è rivolto agli sviluppatori di DynamoDB e agli amministratori di database che vogliono eseguire la migrazione o progettare applicazioni da utilizzare con Bigtable come datastore. Prima di leggere questo documento, consulta la panoramica di Bigtable.

Bigtable e DynamoDB sono store key-value distribuiti che possono supportare milioni di query al secondo (QPS), fornire spazio di archiviazione fino a petabyte di dati e tollerare i guasti dei nodi.

Sebbene gli insiemi di funzionalità di questi servizi di database siano simili, le loro architetture sottostanti e i dettagli di interazione differiscono in modi importanti da comprendere prima di iniziare una migrazione. Questo documento evidenzia le somiglianze e le differenze tra i due sistemi di database.

Piano di controllo

In DynamoDB e Bigtable, il piano di controllo ti consente di configurare la tua capacità e di configurare e gestire le risorse. DynamoDB è un prodotto serverless e il livello più alto di interazione con DynamoDB è a livello di tabella. In modalità di capacità provisionata, puoi eseguire il provisioning delle unità di richiesta di lettura e scrittura, selezionare le regioni e la replica e gestire i backup. Bigtable non è un prodotto serverless; devi creare un'istanza con uno o più cluster, la cui capacità è determinata dal numero di nodi di cui dispongono. Per informazioni dettagliate su queste risorse, consulta Istanze, cluster e nodi.

La tabella seguente mette a confronto le risorse del piano di controllo per DynamoDB e Bigtable.

DynamoDB Bigtable
Tabella: una raccolta di elementi con una chiave primaria definita. Le tabelle hanno impostazioni per backup, replica e capacità. Istanza:un gruppo di cluster Bigtable in regioni o zone Google Cloud diverse, tra cui avviene la replica e il routing delle connessioni. I criteri di replica vengono impostati a livello di istanza.

Cluster: un gruppo di nodi nella stessa zona geografica di Google Cloud, idealmente in co-locazione con il server di applicazioni per motivi di latenza e replica. La capacità viene gestita modificando il numero di nodi in ogni cluster.

Tabella: un'organizzazione logica dei valori indicizzata in base alla chiave di riga.

I backup vengono controllati a livello di tabella.
Unità di capacità di lettura (RCU) e unità di capacità di scrittura (WCU): unità che consentono letture o scritture al secondo con dimensione del payload fissa. Ti vengono addebitate unità di lettura o scrittura per ogni operazione con dimensioni del payload più grandi.Le operazioni

UpdateItem consumano la capacità di scrittura utilizzata per la dimensione più grande di un elemento aggiornato, prima o dopo l'aggiornamento, anche se l'aggiornamento coinvolge un sottoinsieme degli attributi dell'elemento.		 Nodo: una risorsa di calcolo virtuale responsabile della lettura e della scrittura dei dati. Il numero di nodi di un cluster si traduce in limiti di throughput per letture, scritture e scansioni. Puoi aggiustare il numero di nodi in base alla combinazione di obiettivi di latenza, numero di richieste e dimensioni del payload.

I nodi SSD offrono lo stesso throughput per letture e scritture, diversamente dalla differenza significativa tra RCU e WCU. Per ulteriori informazioni, consulta Prestazioni per carichi di lavoro tipici.
Partizione: un blocco di righe contigue, supportato da unità a stato solido (SSD) colocate con i nodi.

Ogni partizione è soggetta a un limite fisso di 1000 WCU, 3000 RCU e 10 GB di dati.		 Tablet : un blocco di righe contigue supportato dal medio di archiviazione scelto (SSD o HDD).

Le tabelle vengono suddivise in tablet per bilanciare il carico di lavoro. I tablet non vengono archiviati sui nodi di Bigtable, ma nel file system distribuito di Google, che consente una rapida ridistribuzione dei dati durante il ridimensionamento e offre una maggiore durabilità mantenendo più copie.
Tabelle globali : un modo per aumentare la disponibilità e la durabilità dei dati mediante la propagazione automatica delle modifiche dei dati in più regioni. Replica: un modo per aumentare la disponibilità e la durabilità dei dati mediante la propagazione automatica delle modifiche dei dati su più regioni o più zone all'interno della stessa regione.
Non applicabile (N/A) Profilo dell'applicazione : impostazioni che indicano a Bigtable come instradare una chiamata all'API client al cluster appropriato nell'istanza. Puoi anche utilizzare un profilo dell'app come tag per segmentare le metriche per l'attribuzione.

Replicazione geografica

La replica viene utilizzata per supportare i requisiti dei clienti per quanto riguarda:

  • Alta disponibilità per la continuità aziendale in caso di guasto a livello di zona o regione.
  • Posiziona i dati del tuo servizio in prossimità degli utenti finali per un servizio con bassa latenza ovunque si trovino nel mondo.
  • Isolamento dei carichi di lavoro quando devi implementare un carico di lavoro batch su un cluster e fare affidamento sulla replica ai cluster di servizio.

Bigtable supporta i cluster replicati in tutte le zone disponibili in un massimo di otto regioni Google Cloud in cui è disponibile Bigtable. La maggior parte delle regioni ha tre zone. Per ulteriori informazioni, consulta Regioni e zone.

Bigtable replica automaticamente i dati nei cluster in una topologia multi-primary, il che significa che puoi leggere e scrivere in qualsiasi cluster. La replica di Bigtables è a coerenza finale. Per informazioni dettagliate, consulta la panoramica della replica.

DynamoDB fornisce tabelle globali per supportare la replica delle tabelle in più regioni. Le tabelle globali sono multi-principali e si replicano automaticamente nelle regioni. La replica è a coerenza finale.

La tabella seguente elenca i concetti di replica e descrive la loro disponibilità in DynamoDB e Bigtable.

Proprietà DynamoDB Bigtable
Replica multi-principale Sì.

Puoi leggere e scrivere in qualsiasi tabella globale.		 Sì.

Puoi leggere e scrivere in qualsiasi cluster Bigtable.
Modello di coerenza Coerenza finale.

Coerenza read-your-writes a livello regionale per le tavole globali.		 Coerenza finale.

Coerenza read-your-writes a livello di cluster per tutte le tabelle, a condizione che invii sia le letture sia le scritture allo stesso cluster.
Latenza di replica Nessun accordo sul livello del servizio (SLA).

Secondi		 Nessuno SLA.

Secondi
Granularità della configurazione A livello di tabella. A livello di istanza.

Un'istanza può contenere più tabelle.
Implementazione Crea una tabella globale con una replica della tabella in ogni regione selezionata.

A livello di regione.

Replica automatica tra le repliche mediante la conversione di una tabella in una tabella globale.

Le tabelle devono avere gli stream DynamoDB abilitati, con lo stream contenente sia le nuove che le vecchie immagini dell'articolo.

Elimina una regione per rimuovere la tabella globale in quella regione.		 Crea un'istanza con più di un cluster.
La replica è automatica tra i cluster dell'istanza.

A livello di zona.

Aggiungi e rimuovi cluster da un'istanza Bigtable.
Opzioni di replica Per tabella. Per istanza.
Routing e disponibilità del traffico Il traffico viene indirizzato alla replica geografica più vicina.

In caso di errore, applichi una logica di business personalizzata per determinare quando reindirizzare le richieste ad altre regioni.		 Utilizza i profili delle applicazioni per configurare i criteri di routing del traffico del cluster.

Utilizza il routing multi-cluster per instradare automaticamente il traffico al cluster integro più vicino.

In caso di errore, Bigtable supporta il failover automatico tra i cluster per l'HA.
Scalabilità La capacità di scrittura in unità di richieste di scrittura replicate (R-WRU) viene sincronizzata tra le repliche.

La capacità di lettura in unità di capacità di lettura replicata (R-RCU) è per replica.		 Puoi scalare i cluster in modo indipendente aggiungendo o rimuovendo nodi da ciascun cluster replicato, in base alle esigenze.
Costo Le R-WRU costano il 50% in più rispetto alle WRU standard. Ti viene addebitato il costo per i nodi e lo spazio di archiviazione di ogni cluster.
Non sono previsti costi di replica di rete per la replica regionale tra zone.
I costi vengono sostenuti quando la replica avviene in più regioni o continenti.
SLA (accordo sul livello del servizio) 99,999% 99,999%

Piano dati

La tabella seguente mette a confronto i concetti del modello dei dati per DynamoDB e Bigtable. Ogni riga della tabella descrive funzionalità analoghe. Ad esempio, un elemento in DynamoDB è simile a una riga in Bigtable.

DynamoDB Bigtable
Elemento: un gruppo di attributi identificabile in modo univoco tra tutti gli altri elementi tramite la chiave primaria. La dimensione massima consentita è 400 KB. Riga : una singola entità identificata dalla chiave di riga. La dimensione massima consentita è di 256 MB.
N/D Famiglia di colonne:uno spazio dei nomi specificato dall'utente che raggruppa le colonne.
Attributo: un raggruppamento di un nome e un valore. Un valore dell'attributo può essere un tipo scalare, un insieme o un documento. Non esiste un limite esplicito per le dimensioni dell'attributo stesso. Tuttavia, poiché ogni elemento è limitato a 400 KB, per un elemento con un solo attributo, l'attributo può essere fino a 400 KB meno le dimensioni occupate dal nome dell'attributo. Qualificatore di colonna : l'identificatore univoco di una colonna all'interno di una famiglia di colonne. L'identificatore completo di una colonna è expressed as colonna-famiglia:colonna-qualificatore. I qualificatori di colonna sono ordneti in ordine lessicografico all'interno della famiglia di colonne.

La dimensione massima consentita per un qualificatore di colonna è 16 KB.


Cella: una cella contiene i dati relativi a una determinata riga, colonna e timestamp. Una cella contiene un valore che può essere fino a 100 MB.
Chiave primaria: un identificatore univoco per un elemento in una tabella. Può essere una chiave di partizione o una chiave composita.

Chiave di partizione: una semplice chiave primaria composta da un attributo. Questo determina la partizione fisica in cui si trova l'elemento. La dimensione massima consentita è 2 KB.

Chiave di ordinamento: una chiave che determina l'ordinamento delle righe all'interno di una partizione. La dimensione massima consentita è 1 KB.

Chiave composita: una chiave primaria composta da due proprietà, la chiave di partizione e un attributo intervallo o chiave di ordinamento.		 Chiave riga : un identificatore univoco per un elemento in una tabella. In genere è rappresentato da una concatenazione di valori e delimitatori. La dimensione massima consentita è 4 KB.

I qualificatori di colonna possono essere utilizzati per ottenere un comportamento equivalente a quello della chiave di ordinamento di DynamoDB.

Le chiavi composite possono essere create utilizzando chiavi di riga e qualificatori di colonna concatenati.

Per maggiori dettagli, consulta l'esempio di traduzione dello schema nella sezione Progettazione dello schema di questo documento.
Time to live: i timestamp per elemento determinano quando un elemento non è più necessario. Dopo la data e l'ora del timestamp specificato, l'elemento viene eliminato dalla tabella senza consumare alcuna throughput di scrittura. Raccolta dei rifiuti: i timestamp per cella determinano quando un elemento non è più necessario. La garbage collection elimina gli elementi scaduti durante un processo in background chiamato compattazione. I criteri di raccolta dei rifiuti vengono impostati a livello di famiglia di colonne e possono eliminare gli elementi non solo in base alla loro età, ma anche in base al numero di versioni che l'utente vuole mantenere. Non è necessario tenere conto della capacità per la compattazione durante la definizione delle dimensioni dei cluster.

Operazioni

Le operazioni del piano dati ti consentono di eseguire azioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) sui dati di una tabella. La seguente tabella confronta operazioni simili del piano di dati per DynamoDB e Bigtable.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable tratta le operazioni di scrittura come upsert.
UpdateItem
  • Scrittura condizionale
  • Incremento e decremento
Bigtable tratta le operazioni di scrittura come upsert.
GetItem
BatchGetItem, Query, Scan		 `ReadRow`
`ReadRows` (intervallo, prefisso, scansione inversa)
Bigtable supporta la scansione efficiente in base al prefisso della chiave di riga, al pattern di espressioni regolari o all'intervallo di chiavi riga in avanti o all'indietro.

Tipi di dati

Sia Bigtable che DynamoDB sono senza schema. Le colonne possono essere definite al momento della scrittura senza alcuna applicazione a livello di tabella per l'esistenza delle colonne o per i tipi di dati. Analogamente, un determinato tipo di dati di colonna o attributo può variare da una riga o da un elemento all'altro. Tuttavia, le API DynamoDB e Bigtable gestiscono i tipi di dati in modi diversi.

Ogni richiesta di scrittura DynamoDB include una definizione di tipo per ogni attributo, che viene restituita con la risposta per le richieste di lettura.

Bigtable tratta tutto come byte e si aspetta che il codice del client conosca il tipo e la codifica in modo che il client possa analizzare correttamente le risposte. Fanno eccezione le operazioni di incremento, che interpretano i valori come numeri interi a 64 bit con formato big endian.

La seguente tabella mette a confronto le differenze nei tipi di dati tra DynamoDB e Bigtable.

DynamoDB Bigtable
Tipi scalari: restituiti come token descrittore del tipo di dati nella risposta del server. Byte: i byte vengono trasmessi ai tipi previsti nell'applicazione client.

Incrementa interpreta il valore come numero intero a 64 bit con segno big endian
Set: una raccolta non ordinata di elementi unici. Famiglia di colonne: puoi utilizzare i qualificatori di colonna come nomi dei membri dell'insieme e per ciascuno specificare un singolo byte 0 come valore della cella. I membri dell'insieme sono ordinati in ordine lessicografico all'interno della famiglia di colonne.
Map: una raccolta non ordinata di coppie chiave-valore con chiavi univoche. Famiglia di colonne
Utilizza il qualificatore di colonna come chiave mappa e il valore della cella per il valore. Le chiavi mappa sono ordinate in ordine lessicografico.
Elenco : una raccolta ordinata di elementi. Qualificatore colonna
Utilizza il timestamp di inserimento per ottenere il comportamento equivalente di list_append, ovvero l'opposto del timestamp di inserimento per prepend.

Progettazione dello schema

Un aspetto importante nella progettazione dello schema è la modalità di archiviazione dei dati. Tra le principali differenze tra Bigtable e DynamoDB figurano il modo in cui gestiscono quanto segue:

  • Aggiornamenti a singoli valori
  • Ordinamento dei dati
  • Controllo delle versioni dei dati
  • Archiviazione di valori di grandi dimensioni

Aggiornamenti a singoli valori

Le operazioni UpdateItem in DynamoDB consumano la capacità di scrittura per il valore maggiore tra le dimensioni degli elementi "prima" e "dopo", anche se l'aggiornamento coinvolge un sottoinsieme degli attributi dell'elemento. Ciò significa che in DynamoDB puoi inserire colonne aggiornate di frequente in righe separate, anche se logicamente appartengono alla stessa riga con altre colonne.

Bigtable può aggiornare una cella con la stessa efficienza indipendentemente dal fatto che sia l'unica colonna in una determinata riga o una tra migliaia. Per maggiori dettagli, consulta Scritture semplici.

Ordinamento dei dati

DynamoDB esegue l'hashing e distribuisce in modo casuale le chiavi di partizione, mentre Bigtable memorizza le righe in ordine alfabetico in base alla chiave di riga e lascia all'utente la scelta dell'hashing.

La distribuzione casuale delle chiavi non è ottimale per tutti i pattern di accesso. Riduce il rischio di intervalli di righe calde, ma rende i pattern di accesso che prevedono scansioni che attraversano i confini della partizione costosi e inefficaci. Queste scansioni illimitate sono comuni, soprattutto per i casi d'uso che hanno una dimensione temporale.

La gestione di questo tipo di pattern di accesso, ovvero le scansioni che attraversano i confini delle partizioni, richiede un indice secondario in DynamoDB, ma Bigtable lo gestisce senza la necessità di un indice secondario. Analogamente, in DynamoDB le operazioni di query e scansione sono limitate a 1 MB di dati scansionati, richiedendo la paginazione oltre questo limite. Bigtable non ha questo limite.

Nonostante le chiavi di partizione distribuite in modo casuale, DynamoDB può comunque avere partizioni calde se una chiave di partizione scelta non distribuisce uniformemente il traffico che sta influenzando negativamente il throughput. Per risolvere il problema, DynamoDB consiglia di utilizzare lo sharding delle scritture, suddividendo in modo casuale le scritture in più valori chiave della partizione logica.

Per applicare questo pattern di progettazione, devi creare un numero casuale da un insieme fisso (ad esempio da 1 a 10) e utilizzarlo come chiave di partizione logica. Poiché la chiave di partizione viene randomizzata, le scritture nella tabella vengono distribuite in modo uniforme tra tutti i valori della chiave di partizione.

Bigtable definisce questa procedura come aggiunta di sale alle chiavi e può essere un modo efficace per evitare le chiavi calde.

Controllo delle versioni dei dati

Ogni cella Bigtable ha un timestamp e il timestamp più recente è sempre il valore predefinito per una determinata colonna. Un caso d'uso comune per i timestamp è il controllo delle versioni: la scrittura di una nuova cella in una colonna che si differenzia dalle versioni precedenti dei dati per quella riga e colonna in base al relativo timestamp.

DynamoDB non ha questo concetto e richiede schemi complessi per supportare il controllo delle versioni. Questo approccio prevede la creazione di due copie di ogni elemento: una copia con un prefisso del numero di versione pari a zero, ad esempio v0_, all'inizio della chiave di ordinamento e un'altra copia con un prefisso del numero di versione pari a uno, ad esempio v1_. Ogni volta che l'elemento viene aggiornato, utilizza il prefisso della versione successivo più alto nella chiave di ordinamento della versione aggiornata e copia i contenuti aggiornati nell'elemento con prefisso della versione pari a zero. In questo modo, la versione più recente di qualsiasi elemento può essere individuata utilizzando il prefisso zero. Questa strategia non solo richiede la gestione della logica lato applicazione, ma rende anche le scritture dei dati molto costose e lente, perché ogni scrittura richiede una lettura del valore precedente più due scritture.

Transazioni con più righe rispetto alla capacità di righe di grandi dimensioni

Bigtable non supporta le transazioni multiriga. Tuttavia, poiché consente di archiviare righe molto più grandi rispetto a quanto consentito in DynamoDB, spesso puoi ottenere la transazionalità prevista progettando gli schemi in modo da raggruppare gli elementi pertinenti in base a una chiave di riga condivisa. Per un esempio che illustra questo approccio, consulta Modello di progettazione a tabella singola.

Memorizzazione di valori di grandi dimensioni

Poiché un elemento DynamoDB, analogo a una riga di Bigtable, è limitato a 400 KB, per memorizzare valori di grandi dimensioni è necessario suddividere il valore tra gli elementi o memorizzarlo su altri media come S3. Entrambi i due approcci aggiungono complessità alla tua applicazione. Al contrario, una cella Bigtable può memorizzare fino a 100 MB e una riga Bigtable può supportare fino a 256 MB.

Esempi di traduzione dello schema

Gli esempi in questa sezione traducono gli schemi da DynamoDB a Bigtable tenendo conto delle differenze principali nel design degli schemi.

Migrazione degli schemi di base

I cataloghi di prodotti sono un buon esempio per dimostrare il pattern di base chiave-valore. Di seguito è riportato un esempio di questo tipo di schema in DynamoDB.

Chiave primaria Attributi
Chiave di partizione Chiave di ordinamento Descrizione Prezzo Miniatura
cappelli fedoras#brandA Realizzata in lana di alta qualità… 30 https://storage…
cappelli fedoras#brandB Tela resistente e impermeabile progettata per.. 28 https://storage…
cappelli newsboy#brandB Aggiungi un tocco di fascino vintage al tuo look quotidiano. 25 https://storage…
scarpe sneakers#brandA Esplora la città con stile e comfort con… 40 https://storage…
scarpe sneakers#brandB Elementi classici con materiali contemporanei… 50 https://storage…

Per questa tabella, il mapping da DynamoDB a Bigtable è semplice: converti la chiave primaria composta di DynamoDB in una chiave di riga Bigtable composta. Crea una famiglia di colonne (SKU) che contenga lo stesso insieme di colonne.

SKU
Chiave di riga Descrizione Prezzo Miniatura
cappelli#fedora#marcaA Realizzata in lana di alta qualità… 30 https://storage…
cappelli#fedora#marcaB Tela resistente e impermeabile progettata per.. 28 https://storage…
cappelli#berretto#marcaB Aggiungi un tocco di fascino vintage al tuo look quotidiano. 25 https://storage…
scarpe#sneakers#marcaA Esplora la città con stile e comfort con… 40 https://storage…
scarpe#sneakers#marcaB Elementi classici con materiali contemporanei… 50 https://storage…

Pattern di design a tabella singola

Un pattern di progettazione a tabella singola riunisce quelle che sarebbero più tabelle in un database relazionale in un'unica tabella in DynamoDB. Puoi adottare l'approccio nell'esempio precedente e duplicare questo schema così com'è in Bigtable. Tuttavia, è meglio risolvere i problemi dello schema durante il processo.

In questo schema, la chiave di partizione contiene l'ID univoco di un video, che consente di collocare tutti gli attributi correlati a quel video per un accesso più rapido. Date le limitazioni di dimensione degli elementi di DynamoDB, non puoi inserire un numero illimitato di commenti di testo libero in una singola riga. Pertanto, viene utilizzata una chiave di ordinamento con il patternVideoComment#reverse-timestamp per rendere ogni commento una riga distinta all'interno della partizione, ordinata in ordine cronologico inverso.

Supponiamo che questo video abbia 500 commenti e che il proprietario voglia rimuoverlo. Ciò significa che devono essere eliminati anche tutti i commenti e gli attributi dei video. Per farlo in DynamoDB, devi eseguire la scansione di tutte le chiavi all'interno di questa partizione e poi emettere più richieste di eliminazione, iterando su ciascuna. DynamoDB supporta le transazioni con più righe, ma questa richiesta di eliminazione è troppo grande per essere eseguita in una singola transazione.

Chiave primaria Attributi
Chiave di partizione Chiave di ordinamento UploadDate Formati
0123 Video 2023-09-10T15:21:48 {"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
VideoComment#98765481 Contenuti
Mi piace molto. Gli effetti speciali sono fantastici.
VideoComment#86751345 Contenuti
Sembra esserci un problema audio al minuto 1:05.
VideoStatsLikes Conteggio
3
VideoStatsViews Conteggio
156
0124 Video 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
VideoComment#97531849 Contenuti
L'ho condiviso con tutti i miei amici.
VideoComment#87616471 Contenuti
Lo stile mi ricorda un regista, ma non riesco a ricordare il nome.
VideoStats ViewCount
45

Modifica questo schema durante la migrazione per semplificare il codice e rendere le richieste di dati più rapide ed economiche. Le righe di Bigtable hanno una capacità molto maggiore rispetto agli elementi DynamoDB e possono gestire un numero elevato di commenti. Per gestire un caso in cui un video riceve milioni di commenti, puoi impostare un criterio di raccolta dei commenti per conservare solo un numero fisso di commenti più recenti.

Poiché i contatori possono essere aggiornati senza l'overhead dell'aggiornamento dell'intera riga, non è necessario dividerli. Non devi utilizzare una colonna UploadDate o calcolare un timestamp inverso e impostarlo come chiave di ordinamento, perché i timestamp Bigtable ti forniscono automaticamente i commenti ordinati in ordine cronologico inverso. In questo modo, lo schema viene semplificato notevolmente e, se un video viene rimosso, puoi rimuovere la riga del video, inclusi tutti i commenti, in una singola richiesta.

Infine, poiché le colonne in Bigtable sono ordinate alfabeticamente, come ottimizzazione puoi rinominarle in modo da consentire una rapida scansione dell'intervallo, dalle proprietà video ai commenti più recenti N, in una singola richiesta di lettura, che è ciò che vuoi fare quando il video viene caricato. In un secondo momento, lo spettatore potrà sfogliare il resto dei commenti mentre scorre la pagina.

Attributi
Chiave di riga Formati Mi piace Visualizzazioni UserComments
0123 {"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48 3 156 Mi piace molto. Gli effetti speciali sono fantastici. @ 2023-09-10T19:01:15
Sembra che ci sia un problema audio al minuto 1:05. @ 2023-09-10T16:30:42
0124 {"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21 45 Lo stile mi ricorda un regista, ma non riesco a ricordare il nome. @2023-10-12T07:08:51

Pattern di design dell'elenco di adiacenze

Prendi in considerazione una versione leggermente diversa di questo design, a cui DynamoDB spesso fa riferimento come pattern di progettazione dell'elenco di adiacenze.

Chiave primaria Attributi
Chiave di partizione Chiave di ordinamento DateCreated Dettagli
Invoice-0123 Invoice-0123 2023-09-10T15:21:48 {"discount": 0.10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
Payment-0680 2023-09-10T15:21:40 {"amount_usd": 120, "bill_to":"John…",
"address":"123 Abc St…"}
Payment-0789 2023-09-10T15:21:31 {"amount_usd": 120, "bill_to":"Jane…",
"address":"13 Xyz St…"}
Invoice-0124 Invoice-0124 2023-09-09T10:11:28 {"discount": 0.20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
Payment-0327 2023-09-09T10:11:10 {"amount_usd": 180, "bill_to":"Bob…",
"address":"321 Cba St…"}
Payment-0275 2023-09-09T10:11:03 {"amount_usd": 70, "bill_to":"Kate…",
"address":"21 Zyx St…"}

In questa tabella, le chiavi di ordinamento non si basano sul tempo, ma sugli ID pagamento, quindi puoi utilizzare un modello di colonne larghe diverso e creare colonne separate per questi ID in Bigtable, con vantaggi simili all'esempio precedente.

Fattura Pagamento
chiave di riga Dettagli 0680 0789
0123 {"discount": 0.10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
@ 2023-09-10T15:21:48		 {"amount_usd": 120, "bill_to":"John…",
"address":"123 Abc St…"} @ 2023-09-10T15:21:40		 {"amount_usd": 120, "bill_to":"Jane…",
"address":"13 Xyz St…"}
@ 2023-09-10T15:21:31
chiave di riga Dettagli 0275 0327
0124 {"discount": 0.20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
@ 2023-09-09T10:11:28		 {"amount_usd": 70, "bill_to":"Kate…",
"address":"21 Zyx St…"}
@ 2023-09-09T10:11:03		 {"amount_usd": 180, "bill_to":"Bob…",
"address":"321 Cba St…"}
@ 2023-09-09T10:11:10

Come puoi vedere negli esempi precedenti, con il design dello schema corretto, il modello a colonne larghe di Bigtable può essere molto efficace e offrire molti casi d'uso che richiederebbero transazioni multiriga costose, indexing secondario o comportamento a cascata on-delete in altri database.

Passaggi successivi