Descrizione delle prestazioni

Questa pagina descrive le prestazioni approssimative che Bigtable può fornire in condizioni ottimali, i fattori che possono influire sulle prestazioni e suggerimenti per testare e risolvere i problemi di prestazioni di Bigtable.

Prestazioni per carichi di lavoro tipici

Bigtable offre prestazioni altamente prevedibili e scalabili linearmente. Se eviti le cause di prestazioni più lente descritte in questa pagina, ogni nodo Bigtable può fornire il seguente throughput approssimativo, a seconda del tipo di spazio di archiviazione utilizzato dal cluster:

Tipo di archiviazione	Letture		Scritture		Scansioni
SSD	fino a 17.000 righe al secondo	o	fino a 14.000 righe al secondo	o	fino a 220 MB/s
HDD	fino a 500 righe al secondo	o	fino a 10.000 righe al secondo	o	fino a 180 MB/s
Spazio di archiviazione per dati consultati di rado	fino a 100 righe al secondo	o	fino a 10.000 righe al secondo	o	fino a 36 MBps

Queste stime presuppongono che ogni riga contenga 1 KB.

In generale, le prestazioni di un cluster scalano in modo lineare man mano che aggiungi nodi al cluster. Ad esempio, se crei un cluster SSD con 10 nodi, il cluster può supportare fino a 140.000 righe al secondo per un tipico carico di lavoro di sola lettura o sola scrittura.

Nota :questi numeri di prestazioni sono solo stime e riflettono un carico di lavoro di sola lettura o sola scrittura. Le prestazioni di Bigtable dipendono molto dal carico di lavoro, dalla progettazione dello schema e dalle caratteristiche del set di dati. Questi numeri di rendimento possono essere utili come punto di partenza per stimare le tue esigenze di calcolo, ma non devono essere utilizzati per il dimensionamento esatto del cluster o per le stime dei costi.

Pianificare la capacità di Bigtable

Quando pianifichi i cluster Bigtable, decidi se vuoi ottimizzare la latenza o la velocità effettiva. Ad esempio, per un job di elaborazione dei dati batch, potresti dare più importanza alla velocità effettiva e meno alla latenza. Al contrario, per un servizio online che gestisce le richieste degli utenti, potresti dare la priorità a una latenza inferiore rispetto al throughput. Puoi ottenere i numeri nella sezione Rendimento per carichi di lavoro tipici quando esegui l'ottimizzazione per il throughput.

Utilizzo CPU

In quasi tutti i casi, ti consigliamo di utilizzare la scalabilità automatica, che consente a Bigtable di aggiungere o rimuovere nodi in base all'utilizzo. Per saperne di più, consulta Scalabilità automatica.

Segui queste linee guida quando configuri i target di scalabilità automatica o se scegli l'allocazione manuale dei nodi. Queste linee guida si applicano indipendentemente dal numero di cluster dell'istanza. Per un cluster con allocazione manuale dei nodi, devi monitorare l'utilizzo della CPU del cluster con l'obiettivo di mantenerlo al di sotto di questi valori per prestazioni ottimali.

Obiettivo di ottimizzazione	Utilizzo massimo CPU
Throughput	90%
Latenza	60%

Per ulteriori informazioni sul monitoraggio, consulta Monitoraggio.

Utilizzo archiviazione

Lo spazio di archiviazione è un altro aspetto da considerare nella pianificazione della capacità. La capacità di archiviazione di un cluster è determinata dal tipo di archiviazione e dal numero di nodi nel cluster. Quando la quantità di dati archiviati in un cluster aumenta, Bigtable ottimizza l'archiviazione distribuendo i dati su tutti i nodi del cluster.

Puoi determinare l'utilizzo dello spazio di archiviazione per nodo dividendo l'utilizzo dello spazio di archiviazione (byte) del cluster per il numero di nodi nel cluster. Ad esempio, considera un cluster con tre nodi HDD e 9 TB di dati. Ogni nodo memorizza circa 3 TB, ovvero il 18,75% del limite di spazio di archiviazione HDD per nodo di 16 TB.

Quando l'utilizzo dello spazio di archiviazione aumenta, i workload possono subire un aumento della latenza di elaborazione delle query anche se il cluster dispone di un numero di nodi sufficiente a soddisfare le esigenze complessive della CPU. Questo perché maggiore è lo spazio di archiviazione per nodo, maggiore è il lavoro in background richiesto, ad esempio l'indicizzazione. L'aumento del lavoro in background per gestire più spazio di archiviazione può comportare una latenza maggiore e un throughput inferiore.

Inizia con quanto segue quando configuri le impostazioni di scalabilità automatica. Se scegli l'allocazione manuale dei nodi, monitora l'utilizzo dello spazio di archiviazione del cluster e aggiungi o rimuovi nodi per mantenere quanto segue.

Obiettivo di ottimizzazione	Utilizzo massimo dello spazio di archiviazione
Throughput	70%
Latenza	60%

Per maggiori informazioni, consulta Archiviazione per nodo.

Esegui i tuoi carichi di lavoro su Bigtable

Esegui sempre i carichi di lavoro su un cluster Bigtable quando pianifichi la capacità per determinare la migliore allocazione delle risorse per le tue applicazioni.

PerfKit Benchmarker di Google utilizza YCSB per eseguire il benchmark dei servizi cloud. Puoi seguire il tutorial di PerfKitBenchmarker per Bigtable per creare test per i tuoi carichi di lavoro. In questo modo, regola i parametri nei file YAML di configurazione del benchmark per assicurarti che il benchmark generato rifletta le seguenti caratteristiche di produzione:

• Dimensioni totali della tabella (proporzionali, ma almeno 100 GB).
• Forma dei dati delle righe (dimensione della chiave di riga, numero di colonne, dimensioni dei dati delle righe e così via)
• Pattern di accesso ai dati (distribuzione chiave di riga)
• Combinazione di letture e scritture

Per altre best practice, consulta la sezione Testare le prestazioni con Bigtable.

Cause di prestazioni più lente

I seguenti fattori possono causare un rallentamento delle prestazioni di Bigtable rispetto alle stime:

• Leggi un numero elevato di chiavi di riga o intervalli di righe non contigui in una singola richiesta di lettura. Bigtable esegue la scansione della tabella e legge le righe richieste in sequenza. Questa mancanza di parallelismo influisce sulla latenza complessiva e le letture che interessano un nodo caldo possono aumentare la latenza di coda. Per i dettagli, consulta Letture e prestazioni.
• Lo schema della tabella non è progettato in modo corretto. Per ottenere un buon rendimento da Bigtable, è essenziale progettare uno schema che consenta di distribuire uniformemente le letture e le scritture in ogni tabella. Inoltre, gli hotspot di una tabella possono influire sulle prestazioni di altre tabelle nella stessa istanza. Per saperne di più, consulta le best practice per la progettazione degli schemi.
• Le righe della tabella Bigtable contengono grandi quantità di dati. Le stime del rendimento presuppongono che ogni riga contenga 1 KB di dati. Puoi leggere e scrivere quantità maggiori di dati per riga, ma l'aumento della quantità di dati per riga ridurrà anche il numero di righe al secondo.
• Le righe della tabella Bigtable contengono un numero molto elevato di celle. Bigtable impiega del tempo per elaborare ogni cella di una riga. Inoltre, ogni cella aggiunge un overhead alla quantità di dati archiviati nella tabella e inviati tramite la rete. Ad esempio, se memorizzi 1 KB (1024 byte) di dati, è molto più efficiente in termini di spazio memorizzare i dati in una singola cella, anziché distribuirli su 1024 celle, ognuna contenente 1 byte. Se dividi i dati in più celle del necessario, potresti non ottenere il rendimento migliore possibile. Se le righe contengono un numero elevato di celle perché le colonne contengono più versioni dei dati con timestamp, valuta la possibilità di conservare solo il valore più recente. Un'altra opzione per una tabella esistente è inviare un'eliminazione per tutte le versioni precedenti a ogni riscrittura.

• Il cluster non ha un numero sufficiente di nodi. I nodi di un cluster forniscono risorse di calcolo per consentire al cluster di gestire le operazioni di lettura e scrittura in entrata, tenere traccia dell'archiviazione ed eseguire attività di manutenzione come la compattazione. Devi assicurarti che il cluster disponga di nodi sufficienti per soddisfare i limiti consigliati per il calcolo e l'archiviazione. Utilizza gli strumenti di monitoraggio per verificare se il cluster è sovraccarico.

  • Compute: se la CPU del cluster Bigtable è sovraccarica, l'aggiunta di altri nodi migliora il rendimento distribuendo il workload su più nodi.
  • Spazio di archiviazione: se l'utilizzo dello spazio di archiviazione per nodo è superiore a quello consigliato, aggiungi altri nodi per mantenere una latenza e un throughput ottimali, anche se il cluster ha CPU sufficiente per elaborare le richieste. Questo perché l'aumento della quantità di spazio di archiviazione per nodo aumenta la quantità di lavoro di manutenzione in background per nodo. Per saperne di più, vedi Compromessi tra utilizzo dello spazio di archiviazione e prestazioni.

• Di recente è stato fatto lo scale up o lo scale down del cluster Bigtable. Dopo che la scalabilità automatica aumenta il numero di nodi in un cluster, possono essere necessari fino a 20 minuti sotto carico prima che le prestazioni migliorino in modo significativo. Bigtable scala i nodi del cluster in base al carico che subiscono.

  Quando riduci il numero di nodi in un cluster per fare lo scale down, cerca di non ridurre le dimensioni del cluster di oltre il 10% in un periodo di 10 minuti per ridurre al minimo i picchi di latenza.

• Il cluster Bigtable utilizza dischi HDD. Nella maggior parte dei casi, il cluster deve utilizzare dischi SSD, che hanno prestazioni significativamente migliori rispetto ai dischi HDD. Per maggiori dettagli, vedi Scelta tra archiviazione SSD e HDD.

• Esistono problemi di connessione di rete. I problemi di rete possono ridurre la velocità effettiva e far sì che le letture e le scritture impieghino più tempo del solito. In particolare, potresti riscontrare problemi se i client non sono in esecuzione nella stessa zona del cluster Bigtable o se vengono eseguiti al di fuori di Google Cloud.

• Stai utilizzando la replica, ma la tua applicazione utilizza una libreria client obsoleta. Se noti un aumento della latenza dopo aver attivato la replica, assicurati che la libreria client Cloud Bigtable utilizzata dalla tua applicazione sia aggiornata. Le versioni precedenti delle librerie client potrebbero non essere ottimizzate per supportare la replica. Consulta la pagina Librerie client di Cloud Bigtable per trovare il repository GitHub della tua libreria client, dove puoi controllare la versione ed eseguire l'upgrade, se necessario.

• Hai abilitato la replica, ma non hai aggiunto altri nodi ai tuoi cluster. In un'istanza che utilizza la replica, ogni cluster deve gestire il lavoro di replica oltre al carico che riceve dalle applicazioni. I cluster con provisioning insufficiente possono causare un aumento della latenza. Puoi verificarlo controllando i grafici relativi all'utilizzo della CPU dell'istanza nella console Google Cloud .

Poiché carichi di lavoro diversi possono far variare le prestazioni, esegui test con i tuoi carichi di lavoro per ottenere i benchmark più accurati.

Avvii a freddo e QPS basso

Gli avvii a freddo e un basso QPS possono aumentare la latenza. Bigtable offre le prestazioni migliori con tabelle di grandi dimensioni a cui si accede di frequente. Per questo motivo, se inizi a inviare richieste dopo un periodo di inattività (avvio a freddo), potresti notare una latenza elevata mentre Bigtable ristabilisce le connessioni. Anche la latenza è più elevata quando QPS è basso.

Se il tuo QPS è basso o se sai che a volte invierai richieste a una tabella Bigtable dopo un periodo di inattività, prova le seguenti strategie per mantenere attiva la connessione ed evitare una latenza elevata.

• Invia sempre un basso tasso di traffico artificiale alla tabella.
• Configura il pool di connessioni per assicurarti che le QPS costanti mantengano attivo il pool.

Durante i periodi di QPS bassa, il numero di errori restituiti da Bigtable è più pertinente rispetto alla percentuale di operazioni che restituiscono un errore.

Avvio a freddo al momento dell'inizializzazione del client. Se utilizzi una versione del client Cloud Bigtable per Java precedente alla versione 2.18.0, puoi abilitare l'aggiornamento del canale. Nelle versioni successive, l'aggiornamento dei canali è attivato per impostazione predefinita. L'aggiornamento del canale svolge due funzioni:

• Quando il client viene inizializzato, prepara il canale prima di inviare le prime richieste.
• Il server disconnette le connessioni a lunga durata ogni ora. Il priming dei canali sostituisce in modo preventivo i canali in scadenza.

Tuttavia, questo non mantiene attivo il canale durante i periodi di inattività.

In che modo Bigtable ottimizza i dati nel tempo

Per archiviare i dati sottostanti di ogni tabella, Bigtable li suddivide in più tablet, che possono essere spostati tra i nodi del tuo cluster Bigtable. Questo metodo di archiviazione consente a Bigtable di utilizzare due strategie per ottimizzare i dati nel tempo:

1. Bigtable archivia all'incirca la stessa quantità di dati su ogni nodo Bigtable.
2. Bigtable distribuisce equamente le letture e le scritture su tutti i nodi Bigtable.

A volte queste strategie sono in conflitto. Ad esempio, se le righe di una tabella vengono lette molto spesso, Bigtable potrebbe archiviare la tabella sul proprio nodo, anche se ciò comporta l'archiviazione di più dati rispetto ad altri nodi.

Nell'ambito di questo processo, Bigtable potrebbe dividere un tablet in due o più tablet più piccoli per ridurne le dimensioni o per isolare le righe calde all'interno di un tablet esistente.

Le sezioni seguenti spiegano in modo più dettagliato ciascuna di queste strategie.

Distribuzione della quantità di dati tra i nodi

Quando scrivi dati in una tabella Bigtable, Bigtable suddivide i dati della tabella in tablet. Ogni tablet contiene un intervallo contiguo di righe all'interno della tabella.

Se hai scritto meno di diversi GB di dati nella tabella, Bigtable archivia tutti i tablet su un singolo nodo all'interno del cluster:

Man mano che si accumulano più tablet, Bigtable sposta alcuni su altri nodi del cluster per bilanciare la quantità di dati in modo più uniforme nel cluster:

Distribuzione uniforme di letture e scritture tra i nodi

Se hai progettato correttamente lo schema, le letture e le scritture dovrebbero essere distribuite in modo abbastanza uniforme su tutta la tabella. Tuttavia, in alcuni casi non puoi evitare di accedere a determinate righe più frequentemente di altre. Bigtable ti aiuta a gestire questi casi tenendo conto delle letture e delle scritture quando bilancia i tablet tra i nodi.

Ad esempio, supponiamo che il 25% delle letture venga eseguito su un numero ridotto di tablet all'interno di un cluster e che le letture siano distribuite uniformemente su tutti gli altri tablet:

Bigtable ridistribuirà i tablet esistenti in modo che le letture siano distribuite nel modo più uniforme possibile nell'intero cluster:

Testare le prestazioni con Bigtable

Se stai eseguendo un test delle prestazioni per un'applicazione che dipende da Bigtable, segui queste linee guida durante la pianificazione e l'esecuzione del test:

• Esegui il test con dati sufficienti.
  • Se le tabelle nell'istanza di produzione contengono un totale di 100 GB di dati o meno per nodo, esegui il test con una tabella con la stessa quantità di dati.
  • Se le tabelle contengono più di 100 GB di dati per nodo, esegui il test con una tabella contenente almeno 100 GB di dati per nodo. Ad esempio, se la tua istanza di produzione ha un cluster di quattro nodi e le tabelle nell'istanza contengono un totale di 1 TB di dati, esegui il test utilizzando una tabella di almeno 400 GB.
• Test con una singola tabella.
• Mantieni l'utilizzo dello spazio di archiviazione per nodo al di sotto del valore consigliato. Per i dettagli, vedi Utilizzo dello spazio di archiviazione per nodo.
• Prima del test, esegui un pre-test intenso per diversi minuti. Questo passaggio consente a Bigtable di bilanciare i dati tra i nodi in base ai modelli di accesso che osserva.
• Esegui il test per almeno 10 minuti. Questo passaggio consente a Bigtable di ottimizzare ulteriormente i tuoi dati e ti aiuta a garantire che i test di lettura dal disco e di lettura dalla memoria della cache vengano eseguiti.

Risolvere i problemi di prestazioni

Se ritieni che Bigtable possa creare un collo di bottiglia delle prestazioni nella tua applicazione, assicurati di controllare quanto segue:

• Esamina le scansioni di Key Visualizer per la tua tabella. Lo strumento Key Visualizer per Bigtable genera nuovi dati di scansione ogni 15 minuti, mostrando i pattern di utilizzo per ogni tabella di un cluster. Key Visualizer ti consente di verificare se i tuoi pattern di utilizzo causano risultati indesiderati, come hotspot su righe specifiche o utilizzo eccessivo della CPU. Per saperne di più, consulta Utilizzare Key Visualizer.
• Commenta il codice che esegue le letture e le scritture di Bigtable. Se il problema di prestazioni scompare, probabilmente stai utilizzando Bigtable in modo da ottenere prestazioni non ottimali. Se il problema di prestazioni persiste, probabilmente non è correlato a Bigtable.

• Assicurati di creare il minor numero possibile di clienti. La creazione di un client per Bigtable è un'operazione relativamente costosa. Pertanto, devi creare il minor numero possibile di clienti:

  • Se utilizzi la replica o i profili app per identificare diversi tipi di traffico verso la tua istanza, crea un client per ogni profilo app e condividi i client nell'applicazione.
  • Se non utilizzi la replica o i profili delle app, crea un singolo client e condividilo in tutta l'applicazione.

  Se utilizzi il client HBase per Java, crei un oggetto Connection anziché un client, quindi crea il minor numero possibile di connessioni.

• Assicurati di leggere e scrivere molte righe diverse nella tabella. Bigtable offre le prestazioni migliori quando le letture e le scritture sono distribuite in modo uniforme nella tabella, il che aiuta Bigtable a distribuire il carico di lavoro su tutti i nodi del cluster. Se le letture e le scritture non possono essere distribuite su tutti i nodi Bigtable, le prestazioni ne risentiranno.

  Se noti di leggere e scrivere solo un numero ridotto di righe, potresti dover riprogettare lo schema in modo che le letture e le scritture siano distribuite in modo più uniforme.

• Verifica che il rendimento sia più o meno lo stesso per le letture e le scritture. Se noti che le letture sono molto più veloci delle scritture, potresti tentare di leggere chiavi di riga inesistenti o un intervallo ampio di chiavi di riga che contiene solo un numero ridotto di righe.

  Per effettuare un confronto valido tra letture e scritture, punta a far sì che almeno il 90% delle letture restituisca risultati validi. Inoltre, se stai leggendo un ampio intervallo di chiavi di riga, misura il rendimento in base al numero effettivo di righe in quell'intervallo, anziché al numero massimo di righe che potrebbero esistere.

• Utilizza il tipo corretto di richieste di scrittura per i tuoi dati. La scelta del modo migliore per scrivere i dati contribuisce a mantenere prestazioni elevate.

• Controlla la latenza per una singola riga. Se noti una latenza imprevista durante l'invio delle richieste ReadRows, puoi controllare la latenza della prima riga della richiesta per restringere la causa. Per impostazione predefinita, la latenza complessiva di una richiesta ReadRows include la latenza di ogni riga della richiesta e il tempo di elaborazione tra le righe. Se la latenza complessiva è elevata, ma la latenza della prima riga è bassa, ciò suggerisce che la latenza è causata dal numero di richieste o dal tempo di elaborazione, anziché da un problema con Bigtable.

  Se utilizzi la [libreria client Bigtable per Java] [java-client], puoi visualizzare la metrica read_rows_first_row_latency in Esplora metriche della consoleGoogle Cloud dopo aver attivato le metriche lato client.

• Utilizza un profilo app separato per ogni carico di lavoro. Se riscontri problemi di prestazioni dopo aver aggiunto un nuovo workload, crea un nuovo profilo dell'app per il nuovo workload. Poi puoi monitorare le metriche per i profili della tua app separatamente per risolvere ulteriormente i problemi. Per informazioni dettagliate sul motivo per cui è una best practice utilizzare più profili app, consulta la pagina Come funzionano i profili app.

• Attiva le metriche lato client. Puoi configurare le metriche lato client per ottimizzare e risolvere i problemi di prestazioni. Ad esempio, poiché Bigtable funziona meglio con una distribuzione uniforme, un numero elevato di query al secondo e una latenza P100 (max) maggiore per una piccola percentuale di richieste non indica necessariamente un problema di prestazioni più grave con Bigtable. Le metriche lato client possono fornire informazioni su quale parte del ciclo di vita della richiesta potrebbe causare latenza.

• Assicurati che l'applicazione utilizzi le richieste di lettura prima che scada il timeout. Se la tua applicazione elabora i dati durante un flusso di lettura, rischi che la richiesta scada prima di aver ricevuto tutte le risposte dalla chiamata. Ciò genera un messaggio ABORTED. Se visualizzi questo errore, riduci la quantità di elaborazione durante lo stream di lettura.

Passaggi successivi

• Scopri come progettare uno schema Bigtable.
• Scopri come monitorare le prestazioni di Bigtable.
• Scopri come risolvere i problemi relativi a Key Visualizer.
• Scopri come risolvere i problemi di latenza.
• Visualizza codice campione per aggiungere nodi a un cluster Bigtable in modo programmatico.