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 Per questo documento, leggi la panoramica di Bigtable.

Bigtable e DynamoDB sono archivi chiave-valore distribuiti che supportano milioni di query al secondo (QPS), forniscono uno spazio di archiviazione scalabile e petabyte di dati e tollerano errori dei nodi.

Sebbene gli insiemi di funzionalità di questi servizi di database siano simili, le loro architetture sottostanti e i dettagli dell'interazione differiscono che è importante 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, mentre il livello più alto di interazione con DynamoDB è il livello della tabella. Nella per la modalità di provisioning della capacità, è qui che esegui il provisioning le unità di richiesta, 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 maggiori dettagli 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 i backup, replication e capacity. Istanza: un gruppo di cluster Bigtable in diverse zone o regioni Google Cloud, tra cui repliche e il routing della connessione. 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 tuo server di applicazioni per motivi di latenza e replica. La capacità è gestita da modificando il numero di nodi in ogni cluster.

Tabella: un'organizzazione logica di valori indicizzato per 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 operativa 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 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 velocità effettiva 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 la stessa velocità effettiva per le operazioni di lettura e scrittura, a differenza la 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, circondato dal simbolo il mezzo di archiviazione prescelto (SSD o HDD).

Le tabelle vengono suddivise in tablet per bilanciare il carico di lavoro. I tablet sono non è archiviato sui nodi in Bigtable, ma file system distribuito, che consente una rapida ridistribuzione dei dati durante la scalabilità e offre ulteriore durabilità mantenendo più copie.
Tabelle globali: un modo per aumentare disponibilità e durabilità dei dati mediante la propagazione automatica delle modifiche ai dati in più regioni. Replica: un modo per aumentare la disponibilità e durabilità dei dati mediante la propagazione automatica delle modifiche ai dati in più regioni o in più zone all'interno dello stesso 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 usare anche un profilo dell'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 problemi a livello di zona a livello di regione.
  • Posiziona i dati del tuo servizio in prossimità degli utenti finali per un servizio a bassa latenza ovunque si trovino nel mondo.
  • Isolamento dei carichi di lavoro quando è necessario implementare un carico di lavoro batch su uno e si affidano alla replica nei cluster di gestione.

Bigtable supporta i cluster replicati in tante zone disponibili in un massimo di 8 regioni Google Cloud in cui Bigtable è disponibile. La maggior parte delle regioni ha tre zone. Bigtable replica automaticamente i dati nei cluster in un Topologia multi-primaria, vale a dire che consente di leggere e scrivere su qualsiasi cluster. La replica di Bigtable è alla fine coerente. Per maggiori dettagli, vedi il Panoramica della replica.

DynamoDB fornisce tabelle globali per supportare la replica delle tabelle in più regioni. Le tabelle globali sono multi-principale e la replica automatica tra 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-primaria Sì.

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

Puoi leggere e scrivere su qualsiasi cluster Bigtable.
Modello di coerenza Coerenti nel tempo.

Coerenza in Read-your-writes a livello di regione per le operazioni globali tabelle.		 Coerenza finale.

Coerenza read-your-write a livello di cluster per tutti a condizione che invii operazioni di lettura e scrittura allo stesso cluster.
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. Livello di istanza.

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

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 al suo interno.		 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 Traffico instradato alla replica geografica più vicina.

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

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

In caso di errore, Bigtable supporta per l'alta disponibilità tra cluster.
Scalabilità La capacità di scrittura nelle unità di richiesta di scrittura replicate (R-WRU) è sincronizzati tra le repliche.

La capacità di lettura nelle unità di capacità di lettura replicata (R-RCU) è per replica.		 Puoi scalare i cluster in modo indipendente aggiungendo o rimuovendo nodi a ciascun cluster replicato, come richiesto.
Costo Le R-WRU costano il 50% in più rispetto alle WRU standard. Ti vengono addebitati i costi per 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 zone diverse.
Vengono addebitati costi se la replica avviene in più regioni o continenti.
SLA (accordo sul livello del servizio) 99,999% 99,999%

Piano dati

La tabella seguente confronta i concetti dei modello dei dati per DynamoDB e Bigtable. Ogni riga della tabella descrive caratteristiche 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/D Famiglia di colonne:uno spazio dei nomi specificato dall'utente che gruppi.
Attributo : un raggruppamento di un nome e un valore. Un può essere un tipo scalare, un insieme o un documento. Non sono presenti esplicito limite sulle dimensioni degli attributi stessi. Tuttavia, poiché ogni elemento è limitato a 400 kB, per un articolo che ha un solo attributo, può essere fino a 400 kB meno le dimensioni occupate dall'attributo il 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 è espresso come 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 non può superare i 100 MB.
Chiave principale : un identificatore univoco di un elemento in una tabella. Può essere una chiave di partizione o una chiave composita.

Chiave di partizione: una chiave primaria semplice, composta da una . 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 la chiave di partizione e una chiave di ordinamento o un attributo di intervallo.		 Chiave di 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 throughput di scrittura. Raccolta di rifiuti : i timestamp per cella stabiliscono quando un articolo non è più necessario. La garbage collection elimina gli elementi scaduti durante un processo in background chiamato compattazione. Rifiuti I criteri di raccolta sono impostati a livello di famiglia di colonne e possono eliminare articoli non solo in base all'età, ma anche in base al numero di versioni che l'utente desidera mantenere. Non è necessario soddisfare di compattazione durante il dimensionamento 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 un'analisi efficiente per prefisso della chiave di riga, un pattern con espressioni regolari o un intervallo di chiave di riga in avanti o 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 dato tipo di dati di una colonna o di un attributo può differire rispetto a una singola riga o un elemento a un 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 con segno big endian a 64 bit.

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

DynamoDB Bigtable
Tipi scala: restituiti come tipo di dati. descrittori nella risposta del server. Byte : i byte vengono trasmessi ai tipi previsti nel client. un'applicazione.

Incrementa interpreta il valore come numero intero a 64 bit con segno big endian
Insieme : una raccolta non ordinata di contenuti unici. elementi. Famiglia di colonne. Puoi utilizzare i qualificatori di colonna come impostati i nomi dei membri e, per ciascuno, fornire un singolo byte 0 come valore. I membri dell'insieme sono ordinati in ordine grammaticale all'interno della loro colonna famiglia.
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 l'equivalente di list_append il comportamento inverso, inverso rispetto all'inserimento del timestamp per l'anteposizione.

Progettazione dello schema

Una considerazione importante nella progettazione dello schema è il modo in cui vengono archiviati i dati. Tra le differenze chiave tra Bigtable e DynamoDB sono il modo in cui le seguenti:

  • 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 maggiore tra il "prima" e "dopo" le taglie degli articoli anche se l'aggiornamento riguarda un sottoinsieme del attributi dell'articolo. Ciò significa che in DynamoDB, potresti inserire aggiornamenti colonne 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, vedi Scritture semplici.

Ordinamento dei dati

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

La distribuzione casuale delle chiavi non è ottimale per tutti i pattern di accesso. Riduce rischio di intervalli di riga diretta, ma crea pattern di accesso che coinvolgono scansioni oltre i confini, costoso e inefficiente. 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 un'impaginazione 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 della 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 hot table.

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 comporta la creazione di due copie di ciascun elemento: una copia con il prefisso zero del numero di versione, ad esempio v0_, all'inizio della chiave di ordinamento e un'altra copia con il prefisso del numero di versione di uno, come v1_. Ogni volta che l'elemento viene aggiornato, viene utilizzato il prefisso della versione successivo la chiave di ordinamento della versione aggiornata e copia i contenuti aggiornati nell'elemento con prefisso 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 un esempio di questo approccio. Consulta Progettazione di una tabella singola .

Memorizzazione di valori di grandi dimensioni

Poiché un elemento DynamoDB, analogo a una riga Bigtable, viene limitato a 400 kB, l'archiviazione di valori di grandi dimensioni richiede la suddivisione del valore tra elementi o archiviazione su altri contenuti multimediali, S3. Entrambi di questi 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 di schemi

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 Realizzato in lana di alta qualità... 30 https://storage…
cappelli fedora#brandB Tela resistente e resistente all'acqua realizzata 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 Caratteristiche classiche con materiali contemporanei... 50 https://storage…

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

SKU
Chiave di riga Descrizione Prezzo Miniatura
cappelli#fedora#marcaA Realizzato in lana di alta qualità... 30 https://storage…
hats#fedoras#brandB Tela resistente e impermeabile progettata per.. 28 https://storage…
cappelli#berretto#marcaB Aggiungi un tocco di fascino vintage al tuo look di tutti i giorni. 25 https://storage…
scarpe#sneakers#brandA 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 duplica questo schema così com'è 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 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 e poi emettere più richieste di eliminazione, iterando su ciascuna. DynamoDB supporta 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 che si sia verificato un problema audio alle ore 1:05.
VideoStatsLikes Conteggio
3
VideoStatsViews Numero
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.
Commentovideo#87616471 Contenuti
Lo stile mi ricorda un regista ma non riesco a capirlo li annotino.
VideoStats ViewCount
45

Modifica questo schema durante la migrazione in modo da semplificare il codice e rendere le richieste di dati in modo più rapido ed economico. Le righe di Bigtable hanno una capacità molto più elevata 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.

Perché i contatori possono essere aggiornati senza l'overhead associato all'aggiornamento dell'intero riga di comando, non devi neanche suddividerle. Non è necessario utilizzare una data di caricamento colonna o di calcolare un timestamp inverso e fare in modo che la chiave di ordinamento perché i timestamp di Bigtable offrono cronologicamente inversi automaticamente i commenti in ordine. Ciò semplifica notevolmente lo schema e, se un video viene rimosso, puoi rimuovere la riga del video a livello transazionale, includendo tutti i commenti, in un'unica richiesta.

Infine, le colonne in Bigtable sono ordinate dal punto di vista didattico, come ottimizzazione, puoi rinominare le colonne in modo consente una scansione rapida, dalle proprietà video ai primi N più recenti commenti, in un'unica richiesta di lettura, che è l'azione che è meglio eseguire quando caricamento del video. In un secondo momento, lo spettatore potrà sfogliare il resto dei commenti mentre scorre la pagina.

Attributi
Chiave di riga Formati Mi piace Visualizzazioni CommentiUtente
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 capirlo li annotino. @2023-10-12T07:08:51

Pattern di design dell'elenco di adiacenze

Considera una versione leggermente diversa di questo design, che spesso DynamoDB si riferisce a come il pattern di progettazione dell'elenco di 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":"Gianni...",
"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":"Via Cavour 32..."}
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 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 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":"Via Cavour 21..."}
@ 09-09-2023T10:11:03		 {"amount_usd": 180, "bill_to":"Bob…",
"address":"321 Cba St…"}
@ 2023-09-09T10:11:10

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

Passaggi successivi