Bigtable per gli utenti di DynamoDB

Questo documento è destinato agli sviluppatori e al database DynamoDB amministratori che vogliono eseguire la migrazione o progettare per l'uso 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 consente di configurare la tua capacità e configurare e gestire le risorse. DynamoDB è un prodotto serverless, mentre il livello più alto di interazione con DynamoDB è il livello della tabella. Nel in 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 che hanno. 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 un'entità principale definita chiave. 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 area geografica Zona Google Cloud, idealmente collocata con la tua applicazione per motivi di latenza e replica. La capacità è gestita da modificando il numero di nodi in ogni cluster.

Tabella: un'organizzazione logica di valori indicizzati 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 valore fisso la dimensione del payload. 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 l'esecuzione taglia più grande di un articolo aggiornato, prima o dopo l'aggiornamento, anche se l'aggiornamento interessa un sottoinsieme degli attributi dell'articolo.		 Nodo: una risorsa di computing virtuale responsabile per la lettura e la scrittura dei dati. Il numero di nodi di un cluster si traduce in limiti di velocità effettiva per letture, scritture e scansioni. Puoi regolare il numero di nodi, a seconda della combinazione gli obiettivi di latenza, il numero di richieste e le 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) collocate insieme ai nodi.

Ogni partizione è soggetta a un limite fisso di 1.000 WCU, 3.000 RCU, e 10 GB di dati.		 Tablet: un blocco di righe contigue, circondato dal simbolo il mezzo di archiviazione prescelto (SSD o HDD).

Lo sharding delle tabelle viene eseguito 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 applicazione: impostazioni che indicano Bigtable come instradare una chiamata API client il 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.
  • Mettere i dati di servizio vicini agli utenti finali per e 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 è alla fine coerente.

La tabella seguente 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 Coerenza finale.

Coerenza di 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.

Livello regionale.

Replica automatica tra le repliche convertendo una tabella in una una tabella globale.

Le tabelle devono avere i flussi DynamoDB abilitati, con il flusso contenente sia la nuova che la vecchia immagine dell'articolo.

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

Livello di zona.

Aggiungi e rimuovi cluster da Bigtable in esecuzione in un'istanza Compute Engine.
Opzioni di replica Per tabella. Per istanza.
Routing del traffico e disponibilità 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 del 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 normali WRU. Ti vengono addebitati i costi per i nodi e lo spazio di archiviazione di ciascun 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
Articolo : un gruppo di attributi univoci identificabile tra tutti gli altri elementi dalla sua chiave primaria. Massima è 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 per le 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 del nome dell'attributo. Qualificatore di colonna : l'identificatore univoco all'interno di un famiglia di colonne per una colonna. L'identificatore completo di una colonna è espresso come colonna-famiglia:colonna-qualificatore. I qualificatori di colonna sono ordinate in modo grammaticale 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 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 . 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 l'elemento si trova individuarlo. 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 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.

È possibile utilizzare i qualificatori di colonna per pubblicare il comportamento equivalente a quella della chiave di ordinamento di DynamoDB.

Le chiavi composte possono essere create utilizzando righe concatenate e dei qualificatori di colonna.

Per ulteriori dettagli, vedi l'esempio di traduzione dello schema nella sezione nella sezione dedicata alla progettazione di questo documento.
Durata : i timestamp per elemento determinano quando un non è più necessario. Dopo la data e l'ora del timestamp, l'elemento viene eliminato dalla tabella senza consumare in scrittura. Raccolta di rifiuti : i timestamp per cella stabiliscono quando un articolo non è più necessario. Operazioni di eliminazione della garbage collection scadute 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 consentono di eseguire la creazione, la lettura, l'aggiornamento e l'eliminazione (CRUD) azioni sui dati di una tabella. La tabella seguente mette a confronto un piano dati simile operazioni 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 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. È possibile definire le colonne in fase di scrittura senza applicare l'applicazione forzata a livello di tabella per i dati o l'esistenza delle colonne di testo. 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 con i tipi di dati in vari modi.

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

Bigtable tratta tutto come byte e si aspetta il codice client per conoscere il tipo e la codifica in modo che il client possa analizzare correttamente le risposte. Un'eccezione è incrementa operazioni, che interpretano i valori come numeri interi con segno big-endian a 64 bit.

La tabella seguente confronta 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.

Increment interpreta il valore come Numero intero con segno big-endian a 64 bit
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.
Mappa: una raccolta non ordinata di coppie chiave/valore con chiavi univoche. Famiglia di colonne
Utilizza il qualificatore di colonna come chiave di mappa e valore della cella per il valore. Chiavi della mappa sono in ordine grammaticale.
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 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 grandi

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 solo colonna in una determinata riga o una tra molte 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 delle chiavi casuali 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 analisi illimitate vengono comuni, in particolare per i casi d'uso che prevedono una dimensione temporale.

Gestione di questo tipo di pattern di accesso: analisi delle partizioni limiti: richiede un indice secondario in DynamoDB, Bigtable gestisce tutto senza bisogno 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 tale limite.

Nonostante le sue chiavi di partizione distribuite casualmente, DynamoDB può comunque avere partizioni se una chiave di partizione scelta non distribuisce uniformemente il traffico influisce negativamente sulla velocità effettiva. Per risolvere questo problema, DynamoDB consiglia write-sharding, che consente di suddividere in modo casuale le scritture su più partizioni logiche le coppie chiave-valore.

Per applicare questo pattern di progettazione, devi creare un numero casuale da un (ad esempio, da 1 a 10), quindi utilizzare questo numero come partizione logica chiave. Poiché stai randomizzando la chiave di partizione, le scritture nella tabella vengono distribuiti in modo uniforme tra tutti i valori delle chiavi di partizione.

Bigtable si riferisce a questa procedura come salatura della chiave, e può essere un modo efficace per evitare i tablet caldi.

Controllo delle versioni dei dati

Ogni cella Bigtable ha un timestamp e quello più recente è sempre il valore predefinito per ogni colonna specificata. Un caso d'uso comune per i timestamp sono il controllo delle versioni, ovvero la scrittura di una nuova cella in una colonna differenziate dalle versioni precedenti dei dati per la riga e la colonna in questione timestamp.

DynamoDB non ha un concetto del genere e richiede progettazioni di 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 ti assicuri che la versione più recente di qualsiasi elemento essere posizionato utilizzando il prefisso zero. Questa strategia non richiede solo della logica lato applicazione da mantenere, ma rende anche le scritture di dati molto costose e lenta, perché ogni scrittura richiede una lettura del valore precedente più due scrive.

Transazioni su più righe e capacità di righe elevata

Bigtable non supporta le transazioni su più righe. Tuttavia, poiché puoi archiviare righe molto più grandi degli elementi DynamoDB, spesso puoi ottenere la transazionalità prevista progettando gli schemi per raggruppare gli elementi pertinenti in una chiave di riga condivisa. Per un un esempio di questo approccio. Consulta Progettazione di una tabella singola .

Archiviazione di valori grandi

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, come S3. Entrambi di questi approcci aggiungono complessità alla tua applicazione. Al contrario, un Una cella Bigtable può archiviare fino a 100 MB può supportare fino a 256 MB.

Esempi di traduzione di schemi

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

Migrazione degli schemi di base

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

Chiave primaria Attributi
Chiave di partizione Chiave di ordinamento Descrizione Prezzo Miniatura
cappelli fedora#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 tribù#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 diretta: converti la chiave primaria composita di DynamoDB in un Chiave di riga Bigtable. Crei una famiglia di colonne (SKU) che contiene lo stesso insieme di colonne.

SKU
Chiave di riga Descrizione Prezzo Miniatura
cappelli#fedora#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#ragazzo#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…

Pattern di progettazione a tabella singola

Un singolo pattern di progettazione di tabella 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 aiuta a posizionare tutti gli attributi correlati al video per un accesso più rapido. Dato Limitazioni delle dimensioni degli articoli di DynamoDB: non puoi inserire un numero illimitato di testo libero commenti in una singola riga. Di conseguenza, una chiave di ordinamento con il pattern VideoComment#reverse-timestamp viene utilizzato per creare una riga separata per ogni commento all'interno della partizione, 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 quindi inviare più richieste di eliminazione, ripetendole. DynamoDB supporta su più righe, ma questa richiesta di eliminazione è troppo grande per essere eseguita in una 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 video#98765481 Contenuti
Mi piace molto. Gli effetti speciali sono incredibili.
CommentovideoN.86751345 Contenuti
Sembra che si sia verificato un problema audio alle ore 1:05.
VideoStatsLikes Numero
3
VideoStatsViews Numero
156
0124 Video 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
Commento video#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 Bigtable sono molto più grandi rispetto agli elementi DynamoDB e può gestire un numero elevato di commenti. A se un video riceve milioni di commenti, puoi impostare un norme di raccolta dei dati per mantenere solo un numero 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 a livello 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 seguito, puoi sfogliare il resto dei commenti come 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 problema audio alle ore 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 progettazione dell'elenco di adiacenti

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":"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":"Via Cavour 32..."}
Payment-0275 2023-09-09T10:11:03 {"amount_usd": 70, "bill_to":"Kate…",
"address":"Via Cavour 21..."}

In questa tabella, le chiavi di ordinamento non sono basate sull'ora, ma piuttosto sugli ID pagamento, puoi utilizzare un pattern a colonne larghe diverso e separare questi ID colonne in Bigtable, con vantaggi simili esempio.

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.."}
@ 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":"Via Cavour 321..."}
@ 09-09-2023T10: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