Best practice di progettazione dello schema

Uno schema Bigtable efficace ti consente di massimizzare il throughput di lettura e scrittura, prevenire gli hotspot e scalare lo spazio di archiviazione in modo efficiente. Prima di iniziare, consulta la panoramica di Bigtable per comprendere l'architettura e il modello di archiviazione sottostanti.

Concetti generali

La progettazione di uno schema Bigtable è diversa da quella di uno schema per un database relazionale. Uno schema Bigtable è definito dalla logica dell'applicazione anziché da un oggetto o file di definizione dello schema. Puoi aggiungere famiglie di colonne a una tabella quando la crei o la aggiorni, ma i pattern delle colonne e chiave di riga sono definiti dai dati che scrivi nella tabella.

In Bigtable, uno schema è un progetto o un modello di una tabella, inclusa la struttura dei seguenti componenti della tabella:

  • Chiavi di riga
  • Famiglie di colonne, incluse le relative policy di garbage collection
  • Colonne

In Bigtable, la progettazione dello schema è guidata principalmente dalle query o dalle richieste di lettura che prevedi di inviare alla tabella. Poiché la lettura di un intervallo di righe è il modo più rapido per leggere i dati di Bigtable, i suggerimenti in questa pagina sono progettati per aiutarti a ottimizzare le letture degli intervalli di righe. Nella maggior parte dei casi, ciò significa inviare una query basata sui prefissi delle chiave di riga.

Una considerazione secondaria è l'evitare gli hotspot: per farlo, devi considerare i pattern di scrittura e come puoi evitare di accedere a uno spazio di chiavi ridotto in un breve periodo di tempo.

I seguenti concetti generali si applicano alla progettazione dello schema Bigtable:

  • Bigtable è un archivio di coppie chiave/valore, non un archivio relazionale. Non supporta i join e le transazioni sono supportate solo all'interno di una singola riga.
  • Ogni tabella ha un indice: la chiave di riga. Ogni chiave di riga deve essere univoca. Per creare un indice secondario, utilizza una vista materializzata continua. Per saperne di più, consulta Crea un indice secondario asincrono.
  • Le chiavi di riga ordinano le righe lessicograficamente dalla stringa di byte più bassa a quella più alta. Questo ordine è big-endian (a volte chiamato ordine dei byte di rete), l'equivalente binario dell'ordine alfabetico.
  • Le famiglie di colonne non vengono archiviate in un ordine specifico.
  • Le colonne sono raggruppate per famiglia di colonne e ordinate in ordine lessicografico all'interno della famiglia di colonne. Ad esempio, in una famiglia di colonne denominata SysMonitor con i qualificatori di colonna ProcessName, User, %CPU, ID, Memory, DiskRead e Priority, Bigtable archivia le colonne in questo ordine:
SysMonitor
%CPU DiskRead ID Memoria Priorità ProcessName Utente
  • L'intersezione di una riga e di una colonna può contenere più celle con timestamp. Ogni cella contiene una versione univoca dei dati con timestamp per la riga e la colonna corrispondenti.
  • Le famiglie di colonne aggregate contengono celle aggregate. Puoi creare famiglie di colonne che contengono solo celle aggregate. Un'aggregazione ti consente di unire i nuovi dati a quelli già presenti nella cella.
  • Tutte le operazioni sono atomiche a livello di riga. Un'operazione interessa un'intera riga o nessuna riga.
  • Idealmente, sia le letture che le scritture dovrebbero essere distribuite in modo uniforme nello spazio delle righe di una tabella.
  • Le tabelle Bigtable sono sparse. Una colonna non occupa spazio in una riga che non la utilizza.

Best practice

Uno schema ben progettato garantisce prestazioni e scalabilità eccellenti, mentre uno schema progettato male può portare a un sistema con prestazioni scadenti. Ogni caso d'uso è diverso e richiede un design specifico, ma le seguenti best practice si applicano alla maggior parte dei casi d'uso. Le eccezioni sono indicate.

Partendo dal livello della tabella e scendendo fino al livello della chiave di riga, le sezioni seguenti descrivono le best practice per la progettazione dello schema:

Tutti gli elementi della tabella, in particolare le chiavi di riga, devono essere progettati tenendo conto delle richieste di lettura pianificate. Controlla le quote e i limiti per i limiti di dimensioni consigliati e rigidi per tutti gli elementi della tabella.

Poiché tutte le tabelle di un'istanza sono archiviate sugli stessi tablet, un design dello schema che genera hotspot in una tabella può influire sulla latenza di altre tabelle nella stessa istanza. Gli hotspot sono causati dall'accesso frequente a una parte della tabella in un breve periodo di tempo.

Tabelle

Archivia i set di dati con schemi simili nella stessa tabella, anziché in tabelle separate.

In altri sistemi di database, potresti scegliere di archiviare i dati in più tabelle in base all'oggetto e al numero di colonne. In Bigtable, invece, di solito è meglio archiviare tutti i dati in un'unica tabella. Puoi assegnare un prefisso di chiave di riga univoco da utilizzare per ogni set di dati, in modo che Bigtable memorizzi i dati correlati in un intervallo contiguo di righe su cui puoi eseguire query in base al prefisso di chiave di riga.

Bigtable ha un limite di 1000 tabelle per istanza, ma ti consigliamo di evitare di creare un numero elevato di tabelle per i seguenti motivi:

  • L'invio di richieste a molte tabelle diverse può aumentare l'overhead della connessione di backend, con un conseguente aumento della latenza di coda.
  • La creazione di più tabelle non migliora il bilanciamento del carico e può aumentare l'overhead di gestione.

Potresti legittimamente voler utilizzare una tabella separata per un caso d'uso diverso che richiede uno schema diverso, ma non dovresti utilizzare tabelle separate per dati simili. Ad esempio, non dovresti creare una nuova tabella perché è un nuovo anno o hai un nuovo cliente.

Famiglie di colonne

Inserisci le colonne correlate nella stessa famiglia di colonne. Quando una riga contiene più valori correlati tra loro, è buona norma raggruppare le colonne che contengono questi valori nella stessa famiglia di colonne. Raggruppa i dati nel modo più preciso possibile per evitare di dover progettare filtri complessi e per ottenere solo le informazioni di cui hai bisogno, ma non di più, nelle richieste di lettura più frequenti.

Crea fino a circa 100 famiglie di colonne per tabella. La creazione di più di 100 famiglie di colonne potrebbe causare un peggioramento delle prestazioni.

Scegli nomi brevi per le famiglie di colonne. I nomi sono inclusi nei dati trasferiti per ogni richiesta.

Inserisci le colonne con esigenze di conservazione dei dati diverse in famiglie di colonne diverse. Questa pratica è importante se vuoi limitare i costi di archiviazione. Le policy di garbage collection vengono impostate a livello di famiglia di colonne, non a livello di colonna. Ad esempio, se devi conservare solo la versione più recente di un determinato dato, non archiviarlo in una famiglia di colonne impostata per archiviare 1000 versioni di un altro dato. In caso contrario, pagherai per archiviare 999 celle di dati di cui non hai bisogno.

Colonne

Crea tutte le colonne che ti servono nella tabella. Le tabelle Bigtable sono sparse e non è prevista alcuna penalità di spazio per una colonna non utilizzata in una riga. Puoi avere milioni di colonne in una tabella, purché nessuna riga superi il limite massimo di 256 MB per riga.

Evita di utilizzare troppe colonne in una singola riga. Anche se una tabella può avere milioni di colonne, una riga non dovrebbe averne così tante. Alcuni fattori contribuiscono a questa best practice:

  • Bigtable impiega del tempo per elaborare ogni cella in una riga.
  • Ogni cella aggiunge un overhead alla quantità di dati archiviati nella tabella e inviati sulla rete. Ad esempio, se memorizzi 1 KB (1024 byte) di dati, è molto più efficiente in termini di spazio memorizzare questi dati in una singola cella, anziché distribuirli su 1024 celle che contengono ciascuna 1 byte.

Se il tuo set di dati richiede logicamente più colonne per riga di quelle che Bigtable può elaborare in modo efficiente, valuta la possibilità di archiviare i dati come protobuf in una singola colonna.

Facoltativamente, puoi trattare i qualificatori di colonna come dati. Poiché devi archiviare un qualificatore di colonna per ogni colonna, puoi risparmiare spazio assegnando un nome alla colonna con un valore. Ad esempio, considera una tabella che memorizza i dati sulle amicizie in una famiglia di colonne Friends. Ogni riga rappresenta una persona e tutte le sue amicizie. Ogni qualificatore di colonna può essere l'ID di un amico. Il valore di ogni colonna di quella riga può essere la cerchia sociale di cui fa parte l'amico. In questo esempio, le righe potrebbero essere simili alle seguenti:

Chiave di riga Fred Gabriel Hiroshi Seo Yoon Jakob
Jose book-club lavorare al meglio tennis
Sofia lavorare al meglio school club-di-scacchi

Confronta questo schema con uno schema per gli stessi dati che non tratta i qualificatori di colonna come dati e, invece, ha le stesse colonne in ogni riga:

Chiave di riga Amico Galleria
Jose#1 Fred book-club
Jose#2 Gabriel lavorare al meglio
Jose#3 Hiroshi tennis
Sofia#1 Hiroshi lavorare al meglio
Sofia#2 Seo Yoon school
Sofia#3 Jakob club-di-scacchi

Il secondo design dello schema fa crescere la tabella molto più velocemente.

Se utilizzi i qualificatori di colonna per archiviare i dati, assegna loro nomi brevi, ma significativi. Questo approccio ti consente di ridurre la quantità di dati trasferiti per ogni richiesta. La dimensione massima è 16 kB.

Righe

Mantieni la dimensione di tutti i valori in una singola riga al di sotto di 100 MB. Assicurati che i dati in una singola riga non superino i 256 MB. Le righe che superano questo limite possono comportare una riduzione delle prestazioni di lettura.

Mantieni tutte le informazioni relative a un'entità in un'unica riga. Per la maggior parte dei casi d'uso, evita di archiviare i dati che devi leggere in modo atomico o tutti contemporaneamente in più di una riga per evitare incoerenze. Ad esempio, se aggiorni due righe di una tabella, è possibile che una riga venga aggiornata correttamente e l'altro aggiornamento non vada a buon fine. Assicurati che lo schema non richieda l'aggiornamento di più di una riga contemporaneamente per garantire l'accuratezza dei dati correlati. Questa pratica garantisce che se una parte di una richiesta di scrittura non va a buon fine o deve essere inviata di nuovo, quel dato non è temporaneamente incompleto.

Eccezione: se la conservazione di un'entità in una singola riga genera righe di centinaia di MB, devi suddividere i dati in più righe.

Archivia le entità correlate in righe adiacenti per rendere le letture più efficienti.

Celle

Non archiviare più di 10 MB di dati in una singola cella. Ricorda che una cella contiene i dati archiviati per una determinata riga e colonna con un timestamp univoco e che è possibile archiviare più celle nell'intersezione di quella riga e colonna. Il numero di celle conservate in una colonna è regolato dalla policy di garbage collection impostata per la famiglia di colonne che contiene la colonna.

Utilizza le celle aggregate per archiviare e aggiornare i dati aggregati. Se ti interessa solo il valore aggregato degli eventi per un'entità, ad esempio la somma mensile delle vendite per dipendente in un negozio di vendita al dettaglio, puoi utilizzare le aggregazioni. Per saperne di più, consulta Aggrega i valori al momento della scrittura.

Chiavi di riga

Progetta la chiave di riga in base alle query che utilizzerai per recuperare i dati. Le chiavi di riga ben progettate consentono di ottenere le migliori prestazioni da Bigtable. Le query Bigtable più efficienti recuperano i dati utilizzando uno dei seguenti elementi:

  • Chiave di riga
  • Prefisso chiave di riga
  • Intervallo di righe definito dalle chiavi di riga iniziale e finale

Altri tipi di query attivano una scansione completa della tabella, che è molto meno efficiente. Scegliendo ora la chiave di riga corretta, puoi evitare un doloroso processo di migrazione dei dati in un secondo momento.

Scegli chiavi di riga brevi. Una chiave di riga deve avere una dimensione massima di 4 KB. Le chiavi di riga lunghe occupano memoria e spazio di archiviazione aggiuntivi e aumentano il tempo necessario per ricevere risposte dal server Bigtable.

Archivia più valori delimitati in ogni chiave di riga. Poiché il modo migliore per eseguire query su Bigtable in modo efficiente è tramite la chiave di riga, spesso è utile includere più identificatori nella chiave di riga. Quando la chiave di riga include più valori, è particolarmente importante avere una chiara comprensione di come utilizzi i dati.

I segmenti della chiave di riga sono in genere separati da un delimitatore, ad esempio i due punti, una barra o un simbolo di hash. Il primo segmento o insieme di segmenti contigui è il prefisso della chiave di riga, mentre l'ultimo segmento o insieme di segmenti contigui è il suffisso della chiave di riga.

Chiave di riga di esempio

I prefissi chiave di riga ben pianificati ti consentono di sfruttare l'ordinamento integrato di Bigtable per archiviare i dati correlati in righe contigue. L'archiviazione di dati correlati in righe contigue consente di accedere ai dati correlati come un intervallo di righe, anziché eseguire scansioni inefficienti delle tabelle.

Se i dati includono numeri interi che vuoi archiviare o ordinare numericamente, aggiungi degli zeri iniziali ai numeri interi. Bigtable archivia i dati in ordine lessicografico. Ad esempio, in ordine lessicografico, 3 > 20, ma 20 > 03. Se aggiungi uno zero iniziale al 3, i numeri vengono ordinati numericamente. Questa tattica è importante per i timestamp in cui vengono utilizzate query basate su intervalli.

È importante creare una chiave di riga che consenta di recuperare un intervallo di righe ben definito. In caso contrario, la query richiede una scansione della tabella, che è molto più lenta del recupero di righe specifiche.

Ad esempio, se la tua applicazione monitora i dati dei dispositivi mobili, puoi avere una chiave di riga composta da tipo di dispositivo, ID dispositivo e giorno in cui vengono registrati i dati. Le chiavi di riga per questi dati potrebbero avere il seguente aspetto:

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

Questo design della chiave di riga consente di recuperare i dati con una singola richiesta per:

  • Un tipo di dispositivo
  • Una combinazione di tipo di dispositivo e ID dispositivo

Questo design della chiave di riga non sarebbe ottimale se vuoi recuperare tutti i dati per un determinato giorno. Poiché il giorno è memorizzato nel terzo segmento o nel suffisso della chiave di riga, non puoi semplicemente richiedere un intervallo di righe in base al suffisso o a un segmento centrale della chiave di riga. Devi invece inviare una richiesta di lettura con un filtro che analizzi l'intera tabella alla ricerca del valore del giorno.

Se possibile, utilizza valori di stringa leggibili nelle chiavi di riga. Questa pratica semplifica l'utilizzo dello strumento Key Visualizer per risolvere i problemi relativi a Bigtable.

Spesso, è consigliabile progettare chiavi di riga che iniziano con un valore comune e terminano con un valore granulare. Ad esempio, se la chiave di riga include un continente, un paese e una città, puoi creare chiavi di riga simili alle seguenti in modo che vengano ordinate automaticamente prima in base ai valori con cardinalità inferiore:

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

Chiavi di riga strutturate

Se prevedi di eseguire query sulla tabella utilizzando SQL, puoi definire chiavi di riga strutturate, che ti consentono di accedere ai dati di Bigtable utilizzando chiavi in più parti, simili alle chiavi composite nei database relazionali. La definizione di chiavi di riga strutturate per una tabella consente di accedere a segmenti specifici delle chiavi di riga utilizzando le query GoogleSQL per Bigtable.

Le chiavi di riga strutturate vengono create automaticamente quando crei una vista materializzata continua. Per implementare chiavi di riga strutturate per una tabella Bigtable, puoi creare uno schema della chiave di riga che definisce il tipo di dati e la codifica di ogni segmento della chiave di riga. Bigtable archivia le chiavi di riga come byte ordinati lessicograficamente e lo schema chiave di riga indica a GoogleSQL per Bigtable come decodificare e interpretare questi byte.

Gli schemi delle chiavi di riga vengono ignorati quando esegui query sulla tabella utilizzando il metodo ReadRows dell'API Bigtable Data con una libreria client di Bigtable.

Per saperne di più, consulta Gestisci chiave di riga riga e Query chiave di riga strutturate.

Chiavi di riga da evitare

Alcuni tipi di chiavi di riga possono rendere difficile l'esecuzione di query sui dati e altri possono causare un rendimento scadente. Questa sezione descrive alcuni tipi di chiavi di riga che dovresti evitare di utilizzare in Bigtable.

Chiavi di riga che iniziano con un timestamp. Questo pattern fa sì che le scritture sequenziali vengano inviate a un singolo nodo, creando un hotspot. Se inserisci un timestamp in una chiave di riga, anteponi un valore ad alta cardinalità, ad esempio un ID utente, per evitare hotspot.

Chiavi di riga che impediscono il raggruppamento dei dati correlati. Evita chiavi di riga che causano l'archiviazione dei dati correlati in intervalli di righe non contigui, che non sono efficienti da leggere insieme.

ID numerici sequenziali. Supponiamo che il tuo sistema assegni un ID numerico a ciascun utente della tua applicazione. Potresti avere la tentazione di utilizzare l'ID numerico dell'utente come chiave di riga per la tabella. Tuttavia, poiché i nuovi utenti hanno maggiori probabilità di essere utenti attivi, questo approccio probabilmente indirizzerà la maggior parte del traffico a un numero ridotto di nodi.

Un approccio più sicuro consiste nell'utilizzare una versione invertita dell'ID numerico dell'utente, che distribuisce il traffico in modo più uniforme su tutti i nodi della tabella Bigtable.

Identificatori aggiornati di frequente. Evita di utilizzare una singola chiave di riga per identificare un valore che deve essere aggiornato di frequente. Ad esempio, se memorizzi i dati sull'utilizzo della memoria per un numero di dispositivi una volta al secondo, non utilizzare una singola chiave di riga per ogni dispositivo composta dall'ID dispositivo e dalla metrica memorizzata, ad esempio 4c410523#memusage, e aggiorna la riga ripetutamente. Questo tipo di operazione sovraccarica il tablet che memorizza la riga utilizzata di frequente. Può anche causare il superamento del limite di dimensioni di una riga, perché i valori precedenti di una colonna occupano spazio finché le celle non vengono rimosse durante la garbage collection.

Archivia invece ogni nuova lettura in una nuova riga. Utilizzando l'esempio di memoria utilizzata, ogni chiave di riga può contenere l'ID dispositivo, il tipo di metrica e un timestamp, quindi le chiavi di riga sono simili a 4c410523#memusage#1423523569918. Questa strategia è efficiente perché in Bigtable la creazione di una nuova riga non richiede più tempo della creazione di una nuova cella. Inoltre, questa strategia ti consente di leggere rapidamente i dati di un intervallo di date specifico calcolando le chiavi di inizio e di fine appropriate.

Per i valori che cambiano di frequente, ad esempio un contatore che viene aggiornato centinaia di volte al minuto, è meglio conservare i dati in memoria, a livello di applicazione, e scrivere periodicamente nuove righe in Bigtable.

Valori hash. L'hashing di una chiave di riga rimuove la possibilità di sfruttare l'ordinamento naturale di Bigtable, rendendo impossibile l'archiviazione delle righe in modo ottimale per le query. Per lo stesso motivo, l'hashing dei valori hash rende difficile l'utilizzo dello strumento Key Visualizer per risolvere i problemi con Bigtable. Utilizza valori leggibili anziché valori hash.

Valori espressi come byte non elaborati anziché stringhe leggibili. I byte non elaborati vanno bene per i valori delle colonne, ma per la leggibilità e la risoluzione dei problemi, utilizza valori di stringa nelle chiavi di riga.

Casi d'uso speciali

Potresti avere un set di dati univoco che richiede una considerazione speciale durante la progettazione di uno schema per archiviarlo in Bigtable. Questa sezione descrive alcuni, ma non tutti, i diversi tipi di dati Bigtable e alcune strategie suggerite per archiviarli nel modo più ottimale.

Dati basati sul tempo

Se recuperi spesso i dati in base al momento in cui sono stati registrati, puoi includere un timestamp nella chiave di riga.

Ad esempio, l'applicazione potrebbe registrare dati relativi alle prestazioni, come l'utilizzo della CPU e la memoria utilizzata, una volta al secondo per molte macchine. La chiave di riga per questi dati potrebbe combinare un identificatore della macchina con un timestamp per i dati (ad esempio, machine_4223421#1425330757685). Tieni presente che le chiavi di riga sono ordinate lessicograficamente.

Se includi i timestamp nella chiave di riga, non utilizzare un timestamp da solo o all'inizio di una chiave di riga. Questo pattern fa sì che le scritture sequenziali vengano inviate a un singolo nodo, creando un hotspot.

Se di solito recuperi prima i record più recenti nelle query, un pattern da considerare è l'utilizzo di timestamp invertiti nella chiave di riga. Questo pattern fa sì che le righe vengano ordinate dalla più recente alla meno recente, in modo che i dati più recenti si trovino prima nella tabella. Come per qualsiasi timestamp, evita di iniziare una chiave di riga con un timestamp invertito per non causare hotspot.

Puoi ottenere un timestamp invertito sottraendo il timestamp dal valore massimo del linguaggio di programmazione per numeri interi lunghi (in Java, java.lang.Long.MAX_VALUE).

Per informazioni specifiche sull'utilizzo dei dati delle serie temporali, consulta Progettazione dello schema per i dati delle serie temporali.

Multitenancy

I prefissi delle chiavi di riga forniscono una soluzione scalabile per un caso d'uso "multi-tenancy", uno scenario in cui archivi dati simili, utilizzando lo stesso modello dei dati, per conto di più client. L'utilizzo di una tabella per tutti i tenant è il modo più efficiente per archiviare e accedere ai dati multi-tenant.

Ad esempio, supponiamo che tu memorizzi e monitori le cronologie acquisti per conto di molte aziende. Puoi utilizzare l'ID univoco di ogni azienda come prefisso della chiave di riga. Tutti i dati di un tenant vengono archiviati in righe contigue nella stessa tabella e puoi eseguire query o filtrare utilizzando il prefisso della chiave di riga. In seguito, quando un'azienda non è più tua cliente e devi eliminare i dati della cronologia acquisti che avevi archiviato per l'azienda, puoi eliminare l'intervallo di righe che utilizzano il prefisso della chiave di riga di quel cliente.

Ad esempio, se memorizzi i dati dei dispositivi mobili per i clienti altostrat e examplepetstore, puoi creare chiavi di riga come le seguenti. In seguito, se altostrat non è più un tuo cliente, elimini tutte le righe con il prefisso della chiave di riga altostrat.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

Al contrario, se archivi i dati per conto di ogni azienda nella propria tabella, potresti riscontrare problemi di prestazioni e scalabilità. Inoltre,è più probabile che tu raggiunga inavvertitamente il limite di Bigtable di 1000 tabelle per istanza. Una volta che un'istanza raggiunge questo limite, Bigtable impedisce di creare altre tabelle nell'istanza.

Privacy

A meno che il tuo caso d'uso non lo richieda, evita di utilizzare informazioni che consentono l'identificazione personale (PII) o dati utente nelle chiavi di riga o negli ID famiglia di colonne. I valori nelle chiavi di riga e nelle famiglie di colonne sono sia dati dei clienti sia dati di servizio e le applicazioni che li utilizzano, come la crittografia o il logging, possono esporli inavvertitamente a utenti che non dovrebbero avere accesso ai dati privati.

Per saperne di più su come vengono gestiti i dati di servizio, consulta l'Informativa sulla privacy diGoogle Cloud.

Nomi di dominio

Puoi archiviare i nomi di dominio come dati Bigtable.

Ampia gamma di nomi di dominio

Se memorizzi dati su entità che possono essere rappresentate come nomi di dominio, valuta la possibilità di utilizzare un nome di dominio inverso (ad esempio com.company.product) come chiave di riga. L'utilizzo di un nome di dominio inverso è un'idea particolarmente valida se i dati di ogni riga tendono a sovrapporsi a quelli delle righe adiacenti. In questo caso, Bigtable può comprimere i dati in modo più efficiente.

Al contrario, i nomi di dominio standard non invertiti possono causare l'ordinamento delle righe in modo che i dati correlati non vengano raggruppati in un unico posto, il che può comportare una compressione e letture meno efficienti.

Questo approccio è più efficace quando i dati sono distribuiti su molti nomi di dominio inversi diversi.

Per illustrare questo punto, considera i seguenti nomi di dominio, ordinati automaticamente in ordine lessicografico da Bigtable:

      drive.google.com
      en.wikipedia.org
      maps.google.com

Questo non è l'ideale per il caso d'uso in cui vuoi eseguire query su tutte le righe per google.com. Al contrario, considera le stesse righe in cui i nomi di dominio sono stati invertiti:

      com.google.drive
      com.google.maps
      org.wikipedia.en

Nel secondo esempio, le righe correlate vengono ordinate automaticamente in modo da facilitarne il recupero come intervallo di righe.

Pochi nomi di dominio

Se prevedi di archiviare molti dati per uno o un numero ridotto di nomi di dominio, prendi in considerazione altri valori per la chiave di riga. In caso contrario, potresti inviare scritture a un singolo nodo del cluster, con conseguenti hotspot, oppure le righe potrebbero diventare troppo grandi.

Archiviazione dei dati in formato protobuf

Per ridurre i costi di archiviazione e migliorare l'efficienza di lettura e scrittura, puoi raggruppare i dati correlati in un messaggio di buffer di protocollo (protobuf) e archiviarlo in una singola colonna anziché archiviare ogni campo nella propria colonna. Se in genere leggi un insieme di campi insieme, archiviarli in una singola colonna come un unico valore è più efficiente, perché la lettura di una singola colonna è più veloce della lettura di molte colonne singole. Se archivi i dati come messaggi protobuf, puoi sfruttare le seguenti funzionalità di Bigtable:

  • L'utilizzo dei buffer di protocollo per archiviare strutture di dati flessibili riduce i costi di archiviazione mantenendo i dati in posizione ed evitando la duplicazione.
  • Il caricamento dello schema protobuf su Bigtable in bundle di schemi consente l'esecuzione di query lato server. Il bundle di schemi consente a Bigtable di comprendere e analizzare la struttura dei dati serializzati durante l'esecuzione delle query.
  • L'utilizzo di GoogleSQL per eseguire query e filtrare singoli campi all'interno dei messaggi protobuf direttamente in Bigtable è rapido ed efficiente. Deserializzando i dati sul lato server, puoi eseguire query e proiezioni granulari senza dover trasferire l'intero oggetto protobuf al client.
  • L'utilizzo di tabelle esterne di BigQuery per analizzare i dati protobuf archiviati in Bigtable ti consente di semplificare l'analisi.

Per saperne di più, consulta Crea e gestisci schemi Protobuf e Crea e gestisci schemi Avro (anteprima).

Passaggi successivi