Bigtable per gli utenti di DynamoDB

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

Bigtable e DynamoDB sono archivi di coppie chiave-valore distribuiti in grado di supportare milioni di query al secondo (QPS), fornire spazio di archiviazione che fa lo scale up fino a petabyte di dati e tollerare errori dei nodi.

Sebbene i set di funzionalità di questi servizi di database siano simili, le architetture sottostanti e i dettagli delle interazioni differiscono in modi che è importante 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 consente di configurare la capacità e impostare e gestire le risorse. DynamoDB è un prodotto serverless e il livello di interazione più elevato con DynamoDB è il livello di tabella. Nella modalità di capacità con provisioning, è qui che esegui il provisioning delle unità di richiesta di lettura e scrittura, selezioni le regioni e la replica e gestisci i backup. Bigtable non è un prodotto serverless. Devi creare un'istanza con uno o più cluster, la cui capacità è determinata dal numero di nodi che hanno. Per maggiori dettagli su queste risorse, consulta Istanze, cluster e nodi.

La tabella seguente confronta 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 diverse zone o regioni Google Cloud tra cui si verificano replica e routing delle connessioni. I criteri di replica sono impostati a livello di istanza.

Cluster: un gruppo di nodi nella stessa zona geografica Google Cloud, idealmente collocata insieme al tuo server applicazioni per motivi di latenza e replica. La capacità viene gestita regolando il numero di nodi in ogni cluster.

Tabella: un'organizzazione logica di valori indicizzati per chiave di riga.

I backup sono 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. Vengono addebitate le unità di lettura o scrittura per ogni operazione con payload di dimensioni maggiori.

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 interessa un sottoinsieme degli attributi dell'elemento.		 Nodo: una risorsa di computing virtuale responsabile della lettura e della scrittura dei dati. Il numero di nodi di un cluster si traduce in limiti di velocità effettiva per letture, scritture e analisi. Puoi regolare il numero di nodi in base alla combinazione di obiettivi di latenza, numero di richieste e dimensioni del payload.

I nodi SSDD offrono la stessa velocità effettiva per le letture e le scritture, a differenza della 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) cologate 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 mezzo 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 in Bigtable, ma sul file system distribuito di Google, che consente una ridistribuzione rapida dei dati durante la scalabilità e una maggiore durabilità mantenendo più copie.
Tabelle globali: un modo per aumentare la disponibilità e la durabilità dei dati propagando automaticamente le modifiche ai dati in più regioni. Replica: un modo per aumentare la disponibilità e la durabilità dei dati propagando automaticamente le modifiche ai dati in più regioni o in più zone all'interno della stessa regione.
Non applicabile (N/A) Profilo applicazione: impostazioni che indicano a Bigtable come instradare una chiamata API client al cluster appropriato nell'istanza. Puoi anche usare il profilo di un'app come tag per segmentare le metriche per l'attribuzione.

Replica geografica

La replica viene utilizzata per soddisfare i requisiti dei clienti per quanto segue:

  • Disponibilità elevata per la continuità aziendale in caso di errore a livello di zona o di regione.
  • Mettere i dati dei tuoi servizi nelle vicinanze degli utenti finali per fornire servizi a bassa latenza ovunque si trovino nel mondo.
  • Isolamento del carico di lavoro quando devi implementare un carico di lavoro batch su un cluster e utilizzare la replica nei cluster di gestione.

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. Bigtable replica automaticamente i dati tra i cluster in una topologia multi-primaria, il che significa che puoi leggere e scrivere su qualsiasi cluster. La replica di Bigtable è a coerenza finale. Per maggiori dettagli, consulta la panoramica della replica.

DynamoDB fornisce tabelle globali per supportare la replica delle tabelle in più regioni. Le tabelle globali sono multi-primarie e si replicano automaticamente tra regioni. La replica è coerente.

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

Proprietà DynamoDB Bigtable
Replica multi-primaria Sì,

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

Puoi leggere e scrivere su qualsiasi cluster Bigtable.
Modello di coerenza Alla fine coerenti.

Coerenza Read-your-writes a livello di regione per le tabelle globali.		 Alla fine coerenti.

Coerenza di Read-your-writes a livello di regione per tutte le tabelle.
Latenza di replica Nessun accordo sul livello del servizio (SLA).

secondi		 Nessuno SLA (accordo sul livello del servizio).

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.

Livello regionale.

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

Nelle tabelle devono essere abilitati gli stream DynamoDB e il flusso contenente le immagini nuove e precedenti dell'elemento.

Elimina una regione per rimuovere la relativa tabella globale.		 Creare un'istanza con più di un cluster.
La replica è automatica tra i cluster nell'istanza.

Livello zona.

Aggiungi e rimuovi cluster da un'istanza Bigtable.
Opzioni di replica Per tabella. Per istanza.
Routing e disponibilità del traffico Traffico instradato 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 di applicazione per configurare i criteri di routing del traffico dei 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'alta disponibilità.
Scalabilità La capacità di scrittura nelle unità di richiesta di scrittura replicate (R-WRU) è 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 normali WRU. Ti vengono addebitati i nodi e lo spazio di archiviazione di ogni cluster.
Non sono previsti costi di replica di rete per la replica a livello di regione tra le zone.
Sono addebitati costi se la replica avviene in più regioni o continenti.
SLA (accordo sul livello del servizio) 99,999% 99,999%

Piano dati

La seguente tabella mette a confronto i concetti 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 relativa chiave primaria. La dimensione massima consentita è 400 kB. Riga : una singola entità identificata dalla chiave di riga. La dimensione massima consentita è 256 MB.
N/A 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 di attributo può essere uno scalare, un insieme o un tipo di documento. Non esiste un limite esplicito alle dimensioni degli attributi. Tuttavia, poiché ogni articolo ha un limite di 400 kB, per un articolo che ha un solo attributo, quest'ultimo può arrivare fino a 400 kB meno le dimensioni occupate dal nome dell'attributo. Qualificatore di colonna : l'identificatore univoco all'interno di una famiglia di colonne per una colonna. L'identificatore completo di una colonna è espresso come colonna-famiglia:colonna-qualificatore. I qualificatori di colonna vengono ordinati lessicograficamente all'interno della famiglia di colonne.

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


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

Chiave di partizione: una chiave primaria semplice, 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'ordine 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 una chiave di ordinamento o un attributo intervallo.		 Chiave di riga : un identificatore univoco di un elemento in una tabella. Solitamente rappresentato da una concatenazione di valori e delimitatori. La dimensione massima consentita è 4 kB.

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

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

Per ulteriori dettagli, consulta l'esempio di traduzione dello schema nella sezione Progettazione degli schemi di questo documento.
Durata: i timestamp per singolo articolo determinano quando un articolo non è più necessario. Dopo la data e l'ora del timestamp specificato, l'elemento viene eliminato dalla tabella senza consumare la velocità effettiva di scrittura. Raccolta 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 garbage collection 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 supportare la compattazione durante il dimensionamento dei cluster.

Suite operativa

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

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable tratta le operazioni di scrittura come upsert.
UpdateItem
  • Scrittura condizionale
  • Aumenta e diminuisci
Bigtable tratta le operazioni di scrittura come upsert.
GetItem
BatchGetItem, Query e Scan		 "ReadRow"
"ReadRows" (intervallo, prefisso, scansione inversa)
Bigtable supporta una scansione efficiente in base al prefisso della chiave di riga, allo schema di espressione regolare o all'intervallo di chiavi di riga in avanti o indietro.

Tipi di dati

Sia Bigtable che DynamoDB sono senza schema. Le colonne possono essere definite in fase di scrittura senza alcuna applicazione a livello di tabella per l'esistenza delle colonne o i tipi di dati. Analogamente, un determinato tipo di dati di colonna o attributo può differire 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 del 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 client conosce il tipo e la codifica, in modo che il client possa analizzare correttamente le risposte. Un'eccezione sono le operazioni di incremento, che interpretano i valori come numeri interi con segno big-endian a 64 bit.

La seguente tabella confronta le differenze nei tipi di dati tra DynamoDB e Bigtable.

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

Increment interpreta il valore come un numero intero con segno di big-endian a 64 bit
Imposta: una raccolta non ordinata di elementi univoci. Famiglia di colonne: puoi utilizzare i qualificatori di colonna come nomi dei membri impostati e, per ciascuno di essi, fornire un singolo byte a 0 byte come valore della cella. I membri degli insiemi vengono ordinati lessicograficamente all'interno della famiglia di colonne.
Mappa: una raccolta non ordinata di coppie chiave-valore con chiavi univoche. Famiglia di colonne
Utilizza il qualificatore di colonna come chiave della mappa e il valore della cella per il valore. Le chiavi della mappa sono ordinate lessicograficamente.
Elenco : una raccolta ordinata di elementi. Qualificatore di colonna
Utilizza il timestamp di inserimento per ottenere l'equivalente del comportamento list_append, inverso del timestamp di inserimento per prepend.

Progettazione dello schema

Un aspetto importante nella progettazione dello schema è il modo in cui vengono archiviati i dati. Tra le principali differenze tra Bigtable e DynamoDB c'è 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 la dimensione maggiore tra le dimensioni "prima" e "dopo" dell'elemento, anche se l'aggiornamento interessa un sottoinsieme degli attributi dell'elemento. Ciò significa che in DynamoDB potresti inserire le colonne aggiornate di frequente in righe separate, anche se logicamente appartengono alla stessa riga con altre colonne.

Bigtable può aggiornare una cella in modo altrettanto efficiente, sia che si tratti dell'unica colonna in una determinata riga o di una tra molte migliaia. Per maggiori dettagli, consulta Operazioni di scrittura semplici.

Ordinamento dei dati

DynamoDB esegue hash e distribuisce casualmente le chiavi di partizione, mentre Bigtable archivia le righe in ordine lessicografico per chiave di riga e lascia qualsiasi hashing all'utente.

La distribuzione delle chiavi casuale non è ottimale per tutti i pattern di accesso. Riduce il rischio di intervalli di righe ad alta frequenza, ma rende costosi e inefficienti i pattern di accesso che prevedono scansioni che superano i confini delle partizioni. Queste analisi illimitate sono comuni, soprattutto per i casi d'uso con una dimensione temporale.

La gestione di questo tipo di pattern di accesso, ovvero 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, rendendo necessario l'impaginazione oltre questo limite. Bigtable non ha questo limite.

Nonostante le chiavi di partizione distribuite casualmente, DynamoDB può comunque avere partizioni ad accesso frequente se una chiave di partizione scelta non distribuisce in modo uniforme il traffico che influisce negativamente sulla velocità effettiva. Per risolvere questo problema, DynamoDB consiglia lo sharding della scrittura, mediante la suddivisione casuale delle scritture su più valori chiave di partizione logica.

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

Bigtable fa riferimento a questa procedura come salazione delle chiavi e può essere un modo efficace per evitare tablet caldi.

Controllo delle versioni dei dati

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

DynamoDB non ha un concetto di questo tipo e richiede progettazioni di schema complesse per supportare il controllo delle versioni. Questo approccio comporta la creazione di due copie di ogni elemento: una copia con un prefisso numero di versione pari a zero, come v0_, all'inizio della chiave di ordinamento, e un'altra copia con il prefisso numero di versione pari a uno, ad esempio v1_. Ogni volta che l'elemento viene aggiornato, utilizzi il prefisso di versione successivo nella chiave di ordinamento della versione aggiornata e copi i contenuti aggiornati nell'elemento con prefisso di versione pari a zero. Ciò garantisce che sia possibile individuare la versione più recente di un elemento 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 su più righe e capacità di righe elevata

Bigtable non supporta le transazioni multiriga. Tuttavia, poiché consente di archiviare righe molto più grandi di quelle degli elementi in DynamoDB, spesso puoi ottenere la transazione prevista progettando i tuoi schemi in modo da raggruppare gli elementi pertinenti in una chiave di riga condivisa. Per un esempio che illustra questo approccio, consulta Pattern di progettazione a tabella singola.

Archiviazione di valori di grandi dimensioni

Poiché un elemento DynamoDB, simile a una riga Bigtable, è limitato a 400 kB, l'archiviazione di valori di grandi dimensioni richiede la suddivisione del valore tra elementi o l'archiviazione su altri contenuti multimediali come S3. Entrambi questi approcci rendono più complessa l'applicazione. Al contrario, una cella Bigtable può archiviare fino a 100 MB e una riga Bigtable può supportarne fino a 256 MB.

Esempi di traduzione di schemi

Gli esempi in questa sezione traducono gli schemi da DynamoDB a Bigtable tenendo presenti le principali differenze di progettazione degli schemi.

Migrazione degli schemi di base

I cataloghi di prodotti sono un buon esempio per dimostrare il modello di coppia chiave-valore di base. Di seguito è riportato l'aspetto che potrebbe avere uno schema di questo tipo in DynamoDB.

Chiave primaria Attributi
Chiave di partizione Chiave di ordinamento Description Price Miniatura
cappelli fedora#brandA Realizzata in lana di alta qualità... 30 https://storage…
cappelli fedora#brandB Tela resistente resistente all'acqua progettata per... 28 https://storage…
cappelli giornalista#brandB Aggiungi un tocco di fascino vintage al tuo look di tutti i giorni. 25 https://storage…
scarpe sneakers#brandA Esci con stile e comfort con... 40 https://storage…
scarpe sneakers#brandB Caratteristiche classiche con materiali contemporanei... 50 https://storage…

Per questa tabella, il mapping da DynamoDB a Bigtable è semplice: si converti la chiave primaria composita di DynamoDB in una chiave di riga composita di Bigtable. Creeremo una famiglia di colonne (SKU) che contiene lo stesso set di colonne.

SKU
Chiave di riga Description Price Miniatura
cappelli#fedora#brandA Realizzata in lana di alta qualità... 30 https://storage…
cappelli#fedora#brandB Tela resistente resistente all'acqua progettata per... 28 https://storage…
cappelli#newsboy#brandB Aggiungi un tocco di fascino vintage al tuo look di tutti i giorni. 25 https://storage…
scarpe#sneaker#brandA Esci con stile e comfort con... 40 https://storage…
scarpe#sneaker#brandB Caratteristiche classiche con materiali contemporanei... 50 https://storage…

Pattern di progettazione a tabella singola

Un singolo pattern di progettazione a tabella riunisce in un'unica tabella in DynamoDB quelle che sarebbero più tabelle di un database relazionale. 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 al video per un accesso più rapido. Date le limitazioni relative alle dimensioni degli elementi di DynamoDB, non puoi inserire un numero illimitato di commenti di testo libero in una singola riga. Di conseguenza, una chiave di ordinamento con il pattern VideoComment#reverse-timestamp viene utilizzata per rendere ogni commento una riga separata all'interno della partizione, ordinata in ordine cronologico inverso.

Supponi che questo video abbia 500 commenti e che il proprietario voglia rimuoverlo. Ciò significa che dovranno 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 ed emettere più richieste di eliminazione, ripetendo ciascuna di esse. DynamoDB supporta le transazioni su 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..."}
Commento del video#98765481 Contenuti
Mi piace molto. Gli effetti speciali sono incredibili.
Commento del video#86751345 Contenuti
Sembra che si sia verificato un glitch audio al minuto 1:05.
VideoStatsLikes Numero
3
VideoStatsViews Numero
156
0124 Video 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
Commento del video#97531849 Contenuti
L'ho condiviso con tutti i miei amici.
Commento del video#87616471 Contenuti
Lo stile mi ricorda un regista, ma non riesco a toccarlo.
VideoStats ViewCount
45

Modifica questo schema durante la migrazione in modo da poter semplificare il codice e rendere le richieste di dati più veloci ed economiche. Le righe Bigtable hanno una capacità molto maggiore degli elementi DynamoDB e possono gestire un numero elevato di commenti. Per gestire il caso in cui un video riceva milioni di commenti, puoi impostare una norma di garbage collection per conservare solo un numero fisso dei commenti più recenti.

Poiché i contatori possono essere aggiornati senza l'overhead associato all'aggiornamento dell'intera riga, non è necessario dividerli. Non è necessario utilizzare una colonna UploadDate o calcolare un timestamp inverso e impostare la chiave di ordinamento, poiché i timestamp di Bigtable forniscono automaticamente i commenti in ordine cronologico inverso. Ciò semplifica notevolmente lo schema e, se un video viene rimosso, puoi rimuovere in modo transazionale la riga del video, inclusi tutti i commenti, in un'unica richiesta.

Infine, poiché le colonne in Bigtable sono ordinate lessicograficamente, come ottimizzazione, puoi rinominarle in modo da consentire una rapida scansione dell'intervallo, dalle proprietà video ai primi n commenti più recenti, in un'unica richiesta di lettura, che è l'operazione che vuoi eseguire una volta caricato il video. Successivamente, puoi sfogliare il resto dei commenti mentre l'utente scorre la pagina.

Attributi
Chiave di riga Formati Mi piace Viste 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 incredibili. @ 2023-09-10T19:01:15
Sembra che si sia verificato un glitch audio al minuto 1:05. @ 10-09-2023T16: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 toccarlo. @2023-10-12T07:08:51

Pattern di progettazione dell'elenco adiacenti

Considera una versione leggermente diversa di questo design, che DynamoDB spesso indica come pattern di progettazione degli elenchi adiacenti.

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":"Mario...",
"address":"123 Abc St..."}
Payment-0789 2023-09-10T15:21:31 {"amount_usd": 120, "bill_to":"Giorgia...",
"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 sull'ora, ma piuttosto sugli ID pagamento, quindi puoi utilizzare un diverso pattern a colonne larghe e rendere questi ID separati dalle colonne 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.."}
@ 10-09-2023T15:21:48		 {"amount_usd": 120, "bill_to":"John...",
"address":"123 Abc St..."} @ 10-09-2023T15:21:40		 {"amount_usd": 120, "bill_to":"Jane...",
"address":"13 Xyz St..."}
@ 10-09-2023T15:21:31
chiave di riga Dettagli 0275 0327
0124 {"discount": 0,20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
@ 09-09-2023T10:11:28		 {"amount_usd": 70, "bill_to":"Kate...",
"address":"21 Zyx St..."}
@ 09-09-2023T10:11:03		 {"amount_usd": 180, "bill_to":"Bob...",
"address":"321 Cba St..."}
@ 09-09-2023T10:11:10

Come puoi vedere negli esempi precedenti, con la giusta progettazione dello schema, il modello a colonne larghe di Bigtable può essere molto potente e offrire molti casi d'uso che richiederebbero costose transazioni multiriga, indicizzazione secondaria o comportamento a cascata al momento dell'eliminazione in altri database.

Passaggi successivi