Informazioni sul rendimento

In questa pagina vengono descritte le prestazioni approssimative offerte da Cloud Bigtable in condizioni ottimali, i fattori che possono influire sulle prestazioni e i suggerimenti per i test e la risoluzione dei problemi relativi alle prestazioni Bigtable.

Prestazioni per carichi di lavoro tipici

Bigtable offre prestazioni altamente prevedibili e scalabili in modo lineare. Quando eviti le cause di prestazioni più lente descritte di seguito, ogni nodo Bigtable può fornire la seguente velocità effettiva, a seconda del tipo di spazio di archiviazione utilizzato dal cluster:

Tipo di portaoggetti Letture   Scritture   Scansioni
SSD Fino a 10.000 righe al secondo o Fino a 10.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

Queste stime presuppongono che ogni riga contenga 1 kB di dati.

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 100.000 righe al secondo per un carico di lavoro tipico di sola lettura o di sola scrittura.

Pianificare la capacità di Bigtable

Compromesso tra velocità effettiva elevata e bassa latenza

Quando si pianificano i cluster Bigtable, è importante considerare il compromesso tra velocità effettiva e latenza. Bigtable viene utilizzato in un ampio spettro di applicazioni e casi d'uso diversi possono avere obiettivi di ottimizzazione diversi. Ad esempio, per un job di elaborazione dati in batch, potresti essere più interessato alla velocità effettiva, ma alla latenza. D'altro canto, un servizio online che soddisfa le richieste degli utenti potrebbe dare la priorità a una latenza più bassa rispetto alla velocità effettiva. Di conseguenza, è importante pianificare la capacità di conseguenza.

I numeri nella sezione Prestazioni per carichi di lavoro tipici sono raggiungibili quando assegni la priorità alla velocità effettiva, ma la latenza di coda per Bigtable in un carico di questo tipo potrebbe essere troppo elevata per le applicazioni sensibili alla latenza. In generale, Bigtable offre una latenza ottimale quando il carico CPU per un cluster è inferiore al 70%. Tuttavia, per le applicazioni sensibili alla latenza, ti consigliamo di pianificare una capacità almeno doppia rispetto alle query Bigtable al secondo (QPS) massimo della tua applicazione. Questa capacità garantisce che il cluster Bigtable venga eseguito con un carico della CPU inferiore al 50%, in modo da poter offrire una bassa latenza ai servizi front-end. Questa capacità fornisce anche un buffer per i picchi di traffico o gli hotspot con accesso alle chiavi, il che può causare il bilanciamento del traffico tra i nodi nel cluster.

Compromesso tra prestazioni e utilizzo dello spazio di archiviazione

Un'altra considerazione nella pianificazione della capacità è l'archiviazione. 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 lo spazio di archiviazione distribuendo la quantità di dati tra tutti i nodi nel cluster.

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

Quando l'utilizzo dello spazio di archiviazione aumenta, i carichi di lavoro possono riscontrare un aumento della latenza di elaborazione delle query anche se il cluster ha un numero sufficiente di nodi per soddisfare le esigenze complessive di CPU. Ciò è dovuto al fatto che più elevato è lo spazio di archiviazione per nodo, maggiore è il lavoro in background necessario, come ad esempio l'indicizzazione. L'aumento del lavoro in background per gestire più spazio di archiviazione può comportare una latenza più elevata e una velocità effettiva inferiore.

Per le applicazioni sensibili alla latenza, ti consigliamo di mantenere l'utilizzo dello spazio di archiviazione per nodo al di sotto del 60%. Se il set di dati cresce, aggiungi altri nodi per mantenere una bassa latenza.

Per le applicazioni non sensibili alla latenza, puoi archiviare oltre il 70% del limite, come spiegato in Archiviazione per nodo.

Esegui i tuoi carichi di lavoro tipici contro Bigtable

Esegui sempre i tuoi carichi di lavoro tipici su un cluster Bigtable quando esegui la pianificazione della capacità, in modo da poter individuare l'allocazione delle risorse migliore per le tue applicazioni.

Lo strumento PerfKit Benchmarker di Google utilizza YCSB per eseguire il benchmarking dei servizi cloud. Puoi seguire il tutorial di PerfKitBenchmarker per Bigtable per creare test per i tuoi carichi di lavoro. Durante questa operazione, devi regolare i parametri nei file yaml di configurazione di benchmarking per assicurarti che il benchmark generato rifletta le seguenti caratteristiche nella tua produzione:

Per ulteriori best practice, consulta la pagina relativa al test delle prestazioni con Bigtable.

Cause di prestazioni più lente

Esistono diversi fattori che possono causare un rendimento di Bigtable più lento rispetto alle stime sopra riportate:

  • Leggi un numero elevato di chiavi di riga o contigue non contigue in una singola richiesta di lettura. Bigtable scansiona la tabella e legge le righe richieste in sequenza. Questa mancanza di parallelismo influisce sulla latenza complessiva e qualsiasi lettura che abbia un nodo caldo può aumentare la latenza di coda. Consulta Letture e prestazioni per maggiori dettagli.
  • Lo schema della tabella non è progettato correttamente. Per ottenere prestazioni ottimali da Bigtable, è essenziale progettare uno schema che consenta di distribuire le letture e le scritture in modo uniforme tra 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 nella tabella Bigtable contengono grandi quantità di dati. Le stime di rendimento mostrate sopra presuppongono che ogni riga contenga 1 kB di dati. Puoi leggere e scrivere quantità di dati maggiori per riga, ma aumentando la quantità di dati per riga si ridurrà anche il numero di righe al secondo.
  • Le righe nella tabella Bigtable contengono un numero molto elevato di celle. Bigtable ha bisogno di tempo per elaborare ogni cella di seguito. Inoltre, ogni cella aggiunge un certo sovraccarico alla quantità di dati archiviati nella tabella e inviati sulla rete. Ad esempio, se stai archiviando 1 KB (1024 byte) di dati, è molto più efficiente archiviare lo stesso in un'unica cella invece di distribuire i dati su 1024 celle contenenti ciascuna 1 byte. Se suddividi i dati in più celle del necessario, potresti non ottenere il miglior rendimento possibile. Se le righe contengono un numero elevato di celle, perché le colonne contengono più versioni con timestamp dei dati, ti consigliamo di conservare solo il valore più recente. Un'altra opzione per una tabella già esistente è inviare un'eliminazione per tutte le versioni precedenti a ogni riscrittura.

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

    • Computing: se la CPU del cluster Bigtable è sovraccarica, l'aggiunta di più nodi può migliorare le prestazioni distribuendo il carico di lavoro su più nodi.
    • Archiviazione: se l'utilizzo dello spazio di archiviazione per nodo è diventato superiore a quanto consigliato, devi aggiungere altri nodi per mantenere una latenza e una velocità effettiva ottimali, anche se il cluster ha una CPU sufficiente per elaborare le richieste. Questo perché l'aumento dello spazio di archiviazione per nodo aumenta la quantità di lavoro di manutenzione in background per nodo. Per i dettagli, consulta i compromessi tra utilizzo e prestazioni dello spazio di archiviazione.

  • Di recente è stato fatto lo scale up o lo scale down del cluster Bigtable. Dopo aver aumentato il numero di nodi in un cluster per fare lo scale up, possono essere necessari fino a 20 minuti sotto carico prima di notare un miglioramento significativo delle prestazioni del cluster. 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, consulta la pagina Scelta tra SSD e spazio di archiviazione HDD.

  • Problemi di connessione di rete. I problemi di rete possono ridurre la velocità effettiva e causare tempi di lettura e scrittura più lunghi del solito. In particolare, potresti riscontrare problemi se i tuoi client non sono in esecuzione nella stessa zona del tuo cluster Bigtable o se vengono eseguiti al di fuori di Google Cloud.

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

  • Hai abilitato la replica, ma non hai aggiunto altri nodi ai 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. Per verificare, controlla i grafici di utilizzo CPU dell'istanza nella console Google Cloud.

Poiché i diversi carichi di lavoro possono variare nelle prestazioni, ti consigliamo di eseguire test con i tuoi carichi di lavoro per ottenere benchmark più precisi.

avvii completi

Bigtable funziona al meglio con tabelle di grandi dimensioni a cui si accede di frequente. Per questo motivo, se inizi a inviare richieste dopo un periodo di mancato utilizzo, potresti notare un'elevata latenza mentre Bigtable ristabilisce le connessioni.

Se sai che a volte invierai richieste a una tabella Bigtable dopo un periodo di inattività, puoi provare le seguenti strategie per mantenere calda la connessione ed evitare questa alta latenza. Queste metriche possono anche contribuire a migliorare il rendimento nei periodi di bassa QPS.

Se usi il client Cloud Bigtable per Java, puoi utilizzare anche le seguenti strategie:

Durante gli avvii completi o i periodi con QPS basso, il numero di errori restituiti da Bigtable è più rilevante della percentuale di operazioni che restituiscono un errore.

Replica e prestazioni

L'abilitazione della replica influirà sulle prestazioni di un'istanza Bigtable. L'effetto è positivo per alcune metriche e negativo per altre. Prima di attivare la replica, devi comprendere i potenziali effetti sulle prestazioni.

Velocità effettiva di lettura

La replica può migliorare la velocità effettiva di lettura, soprattutto quando utilizzi il routing multi-cluster. Inoltre, la replica può ridurre la latenza di lettura posizionando i tuoi dati Bigtable in modo geograficamente più vicino agli utenti della tua applicazione.

Velocità effettiva di scrittura

Sebbene la replica possa migliorare la disponibilità e le prestazioni di lettura, non aumenta la velocità effettiva di scrittura. Una scrittura in un cluster deve essere replicata in tutti gli altri cluster dell'istanza. Di conseguenza, ogni cluster sta spendendo le risorse della CPU per eseguire il pull delle modifiche dagli altri cluster. La velocità effettiva di scrittura potrebbe diminuire in realtà perché la replica richiede che ogni cluster esegua operazioni aggiuntive.

Ad esempio, supponiamo di avere un'istanza di un cluster singolo e che il cluster ha tre nodi:

Istanza a cluster singolo con tre nodi

Se aggiungi nodi al cluster, l'effetto sulla velocità effettiva di scrittura è diverso rispetto all'abilitazione della replica mediante l'aggiunta di un secondo cluster a tre nodi all'istanza.

Aggiunta di nodi al cluster originale: puoi aggiungere 3 nodi al cluster, per un totale di 6 nodi. La velocità effettiva di scrittura per l'istanza raddoppia, ma i dati dell'istanza sono disponibili in una sola zona:

Istanza a cluster singolo con 6 nodi

Con replica: in alternativa, puoi aggiungere un secondo cluster con 3 nodi, per un totale di 6 nodi, L'istanza ora scrive ogni dato due volte: quando la scrittura viene ricevuta per la prima volta e di nuovo quando viene replicata nell'altro cluster. La velocità effettiva di scrittura non aumenta e potrebbe diminuire, ma è possibile che i dati siano disponibili in due zone diverse:

Istanza a due cluster con sei nodi

In questi esempi, l'istanza a cluster singolo può gestire la velocità effettiva di scrittura doppia che l'istanza replica può gestire, anche se i cluster di ciascuna istanza hanno un totale di 6 nodi.

Latenza di replica

Quando utilizzi il routing multi-cluster, la replica per Bigtable è alla fine coerente. Come regola generale, occorre più tempo per replicare i dati su una distanza maggiore. I cluster replicati in aree geografiche diverse hanno in genere una latenza di replica più elevata rispetto ai cluster replicati nella stessa area geografica.

Utilizzo del nodo

Come spiegato in Velocità effettiva di scrittura, quando un'istanza utilizza la replica, ogni cluster nell'istanza deve gestire il lavoro di replica oltre al carico che riceve dalle applicazioni. Per questo motivo, un cluster in un'istanza con più cluster spesso richiede più nodi di un cluster in un'istanza con un singolo cluster con traffico simile.

Profili di app e routing del traffico

A seconda del caso d'uso, utilizzerai uno o più profili di app per instradare il traffico Bigtable. Ogni profilo di app utilizza il routing multi-cluster o single-cluster. La scelta del routing può influire sulle prestazioni.

Il routing multi-cluster può ridurre al minimo la latenza. Un profilo di app con routing a cluster multipli instrada automaticamente le richieste al cluster più vicino in un'istanza dal punto di vista dell'applicazione, quindi le scritture vengono replicate negli altri cluster dell'istanza. La scelta automatica della distanza più breve genera la latenza più bassa possibile.

Un profilo di app che utilizza il routing a cluster singolo può essere ottimale per alcuni casi d'uso, come la separazione dei carichi di lavoro o la semantica dell'API Read-after-Write su un singolo cluster, ma non riduce la latenza come il routing multi-cluster.

Per comprendere come configurare i profili dell'app per questi e altri casi d'uso, consulta gli esempi di impostazioni di replica.

Abbandono degli intervalli di righe

Se possibile, evita di perdere un intervallo di righe in un'istanza che utilizza la replica perché l'operazione è lenta e l'utilizzo della CPU aumenta durante l'operazione.

In che modo Bigtable ottimizza i dati nel tempo

Per archiviare i dati sottostanti per ciascuna delle tue tabelle, Bigtable sposta i dati in più tablet, che possono essere spostati tra i nodi nel cluster Bigtable. Questo metodo di archiviazione consente a Bigtable di utilizzare due diverse strategie per ottimizzare i dati nel tempo:

  1. Bigtable cerca di archiviare all'incirca la stessa quantità di dati su ogni nodo Bigtable.
  2. Bigtable tenta di distribuire le letture e scritture in modo uniforme tra tutti i nodi Bigtable.

A volte queste strategie sono in conflitto tra loro. Ad esempio, se le righe di un tablet vengono lette molto spesso, Bigtable potrebbe memorizzare il tablet su un proprio nodo, anche se questo causa ad alcuni nodi di archiviare un volume maggiore di dati rispetto ad altri.

Nell'ambito di questo processo, Bigtable potrebbe anche suddividere il tablet in due o più tablet più piccoli per ridurre le dimensioni del tablet o isolare le righe calde all'interno di un tablet esistente.

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

Distribuzione della quantità di dati tra nodi

Mentre scrivi i dati in una tabella Bigtable, Bigtable imposta i dati della tabella in tablet. Ogni tablet contiene un intervallo di righe contigue all'interno della tabella.

Se hai scritto solo una piccola quantità di dati nella tabella, Bigtable archivia tutti i tablet su un singolo nodo all'interno del cluster:

Un cluster con quattro tablet su un singolo nodo.

Man mano che si accumulano più tablet, Bigtable ne trasferisce alcuni in altri nodi del cluster in modo che la quantità di dati venga bilanciata in modo più uniforme tra i cluster:

I tablet aggiuntivi sono distribuiti su più nodi.

Distribuzione di letture e scritture in modo uniforme tra i nodi

Se hai progettato correttamente lo schema, le operazioni di lettura e scrittura devono essere distribuite in modo abbastanza uniforme nell'intera tabella. Tuttavia, in alcuni casi non puoi evitare di accedere a determinate righe più spesso di altre. Bigtable ti aiuta ad affrontare questi casi prendendo in considerazione le operazioni di lettura e scrittura quando bilancia i tablet tra i nodi.

Ad esempio, supponiamo che il 25% delle letture avvenga su un numero limitato di tablet all'interno di un cluster e che le letture siano distribuite in modo uniforme tra tutti gli altri tablet:

Su 48 tablet, il 25% delle letture è destinato a 3 tablet.

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

I tre tablet attivi sono isolati sui propri nodi.

Testa le prestazioni con Bigtable

Se stai eseguendo un test delle prestazioni di un'applicazione che dipende da Bigtable, segui queste linee guida mentre pianifichi ed esegui il test:

  • Esegui test con dati sufficienti.
    • Se le tabelle nella tua 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 che contenga almeno 100 GB di dati per nodo. Ad esempio, se l'istanza di produzione ha un cluster a 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.
  • Esegui i test con un'unica tabella.
  • Mantieni un utilizzo inferiore allo spazio di archiviazione consigliato per nodo. Per i dettagli, consulta Utilizzo dello spazio di archiviazione per nodo.
  • Prima di eseguire il test, esegui un test preliminare per alcuni minuti. Questo passaggio offre a Bigtable la possibilità di bilanciare i dati tra i nodi in base ai pattern di accesso osservati.
  • Esegui il test per almeno 10 minuti. Questo passaggio consente a Bigtable di ottimizzare ulteriormente i tuoi dati e contribuisce a testare le letture dal disco e le letture memorizzate nella cache dalla memoria.

Risolvere i problemi di rendimento

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

  • Osserva le scansioni di Key Visualizer per la tua tabella. Lo strumento Key Visualizer per Bigtable genera nuovi dati di scansione ogni 15 minuti che mostrano i pattern di utilizzo per ogni tabella in un cluster. Key Visualizer consente di verificare se i pattern di utilizzo stanno causando risultati indesiderati, ad esempio hotspot su righe specifiche o un utilizzo eccessivo della CPU. Scopri come iniziare a utilizzare Key Visualizer.
  • Prova a commentare il codice che esegue operazioni di lettura e scrittura di Bigtable. Se il problema relativo alle prestazioni scompare, probabilmente stai utilizzando Bigtable in modo da ottenere un rendimento non ottimale. Se il problema relativo alle prestazioni persiste, probabilmente non è correlato a Bigtable.

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

    • Se utilizzi la replica o se usi i profili delle app per identificare diversi tipi di traffico verso la tua istanza, crea un client per profilo di app e condividi i client durante la tua applicazione.
    • Se non utilizzi profili di replica o app, crea un singolo client e condividilo con l'intera applicazione.

    Se utilizzi il client HBase per Java, crei un oggetto Connection invece di un client, quindi devi creare il minor numero possibile di connessioni.

  • Assicurati di leggere e scrivere molte righe diverse nella tabella. Bigtable funziona al meglio quando le operazioni di lettura e scrittura sono distribuite uniformemente tra le tabelle, consentendo a Bigtable di distribuire il carico di lavoro tra tutti i nodi nel cluster. Se le operazioni di lettura e scrittura non possono essere distribuite in tutti i nodi Bigtable, le prestazioni ne risentiranno.

    Se noti che stai leggendo e scrivendo solo un numero limitato di righe, potresti dover riprogettare lo schema in modo che le letture e le scritture siano distribuite in modo più uniforme.

  • Verifica di vedere approssimativamente le stesse prestazioni per operazioni di lettura e scrittura. Se noti che le letture sono molto più veloci delle scritture, potresti provare a leggere le chiavi di riga che non esistono oppure un ampio intervallo di chiavi di riga che contengono solo un numero limitato di righe.

    Per fare un confronto valido tra letture e scritture, devi cercare che almeno il 90% delle letture restituisca risultati validi. Inoltre, se stai leggendo una vasta gamma di chiavi di riga, misura le prestazioni in base al numero effettivo di righe in tale intervallo, anziché al numero massimo di righe che potrebbero esistere.

  • Utilizza il giusto tipo di richieste di scrittura per i tuoi dati. Scegliere il modo ottimale per scrivere i dati aiuta a mantenere prestazioni elevate.

  • Controlla la latenza di una singola riga. Se noti una latenza imprevista quando invii 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 è alta, ma la latenza della prima riga è bassa, significa che la latenza è causata dal numero di richieste o dal tempo di elaborazione, anziché da un problema con Bigtable.

    Se utilizzi la libreria client di Cloud Bigtable per Java, puoi visualizzare la metrica read_rows_first_row_latency in Metrics Explorer di Google Cloud Console dopo aver attivato le metriche lato client.

  • Utilizza un profilo dell'app separato per ogni carico di lavoro. Se riscontri problemi di prestazioni dopo l'aggiunta di un nuovo carico di lavoro, crea un nuovo profilo app per il nuovo carico di lavoro. Successivamente, puoi monitorare le metriche relative ai profili della tua app separatamente per risolvere i problemi. Consulta Come funzionano i profili di app per i dettagli sul motivo per cui è una best practice utilizzare più profili di app.

Passaggi successivi