Informazioni sul rendimento

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

Prestazioni per carichi di lavoro tipici

Bigtable offre prestazioni altamente prevedibili e scalabili in modo lineare. Evitando le cause di rallentamento delle prestazioni descritte di seguito, ciascun nodo Bigtable può fornire la seguente velocità effettiva approssimativa, a seconda del tipo di archiviazione utilizzato dal cluster:

Tipo di archiviazione	Letture		Scritture		Scansioni
SSD	fino a 14.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

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

Nota: questi dati relativi alle prestazioni sono soltanto stime e riflettono un carico di lavoro di sola lettura o di sola scrittura. Le prestazioni di Bigtable dipendono fortemente dal carico di lavoro, dalla progettazione dello schema e dalle caratteristiche dei set di dati. Questi valori relativi alle prestazioni possono essere utili come punto di partenza per la stima delle esigenze di computing, ma non devono essere utilizzati per il dimensionamento esatto dei cluster o per le stime dei costi.

Pianifica la capacità di Bigtable

Quando pianifichi i cluster Bigtable, decidi se ottimizzare la latenza o la velocità effettiva. Ad esempio, per un job di elaborazione dati in batch, potrebbe essere più importante la velocità effettiva e meno la latenza. Al contrario, per un servizio online che gestisce le richieste degli utenti, potresti dare la priorità a una latenza inferiore rispetto alla velocità effettiva. Puoi ottenere i risultati desiderati nella sezione Prestazioni per carichi di lavoro tipici quando esegui l'ottimizzazione per la velocità effettiva.

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 scoprire di più, consulta la sezione Scalabilità automatica.

Attieniti alle linee guida riportate di seguito 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 di cui dispone l'istanza. Per un cluster con allocazione manuale dei nodi, devi monitorare l'utilizzo della CPU del cluster con l'obiettivo di mantenere l'utilizzo della CPU al di sotto di questi valori per prestazioni ottimali.

Obiettivo di ottimizzazione	Utilizzo massimo della CPU
Velocità effettiva	90%
Latenza	60%

Per ulteriori informazioni sul monitoraggio, consulta Monitoraggio.

Utilizzo archiviazione

Un'altra considerazione da considerare 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 l'archiviazione distribuendo la quantità di 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% dello spazio di archiviazione HDD per ogni limite di nodi di 16 TB.

Quando l'utilizzo dello spazio di archiviazione aumenta, i carichi di lavoro possono registrare un aumento della latenza di elaborazione delle query anche se il cluster ha un numero di nodi sufficiente per soddisfare le esigenze complessive della CPU. Questo perché maggiore è lo spazio di archiviazione per nodo, maggiore sarà il lavoro di background come 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.

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 i nodi per mantenere quanto segue.

Obiettivo di ottimizzazione	Utilizzo massimo dello spazio di archiviazione
Velocità effettiva	70%
Latenza	60%

Per maggiori informazioni, consulta Spazio di archiviazione per nodo.

Esegui i carichi di lavoro tipici su Bigtable

Quando pianifichi la capacità, esegui sempre i tuoi carichi di lavoro tipici su un cluster Bigtable, in modo da poter determinare la migliore allocazione delle risorse per le tue applicazioni.

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

• Dimensione totale della tabella. Questo può essere proporzionale, ma utilizza almeno 100 GB.
• Forma dei dati di riga (dimensioni della chiave di riga, numero di colonne, dimensioni dei dati di riga e così via)
• Pattern di accesso ai dati (distribuzione chiave di riga)
• Combinazione di letture e scritture

Per ulteriori best practice, consulta Test delle prestazioni con Bigtable.

Cause di un rallentamento delle prestazioni

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

• Leggi un numero elevato di chiavi di riga o intervalli di righe non contigue in un'unica 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 raggiunge un nodo attivo può aumentare la latenza tail. Per informazioni dettagliate, consulta Letture e rendimento.
• Lo schema della tabella non è progettato correttamente. Per ottenere buone prestazioni da Bigtable, è essenziale progettare uno schema che permetta di distribuire le letture e le scritture in modo uniforme tra tutte le tabelle. Inoltre, gli hotspot in 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 di rendimento mostrate sopra presuppongono che ogni riga contenga 1 kB di dati. Puoi leggere e scrivere quantità maggiori di dati per riga, ma aumentando la quantità di dati per riga si ridurrà anche il numero di righe al secondo.
• Le righe della tabella Bigtable contengono un numero molto elevato di celle. Bigtable impiega tempo per elaborare ogni cella in una riga. Inoltre, ogni cella aggiunge un certo overhead alla quantità di dati archiviati nella tabella e inviati sulla rete. Ad esempio, se archivi 1 kB (1024 byte) di dati, archiviare i dati in una singola cella è molto più efficiente in termini di spazio, anziché distribuirli in 1024 celle contenenti 1 byte ciascuna. Se suddividi i dati in più celle del necessario, potresti non ottenere le migliori prestazioni possibili. Se le righe contengono un numero elevato di celle perché le colonne contengono più versioni dei dati con timestamp, valuta la possibilità di mantenere solo il valore più recente. Un'altra opzione per una tabella già esistente è l'invio di 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 al cluster le risorse di calcolo necessarie per gestire le letture e le scritture in entrata, tenere traccia dello spazio di archiviazione ed eseguire attività di manutenzione come la compattazione. Devi assicurarti che il cluster disponga di nodi sufficienti a soddisfare i limiti consigliati sia per il calcolo che per l'archiviazione. Usa gli strumenti di monitoraggio per verificare se il cluster è sovraccarico.

  • Computing: se la CPU del cluster Bigtable è sovraccarica, l'aggiunta di altri nodi può migliorare le prestazioni distribuendo il carico di lavoro su più nodi.
  • Spazio di archiviazione: se l'utilizzo dello spazio di archiviazione per nodo è superiore a quello consigliato, devi aggiungere altri nodi per mantenere latenza e 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 maggiori dettagli, vedi Confronto tra utilizzo dello spazio di archiviazione e prestazioni.

• Di recente è stato fatto lo scale up o lo scale down del cluster Bigtable. Una volta aumentato il numero di nodi in un cluster, potrebbero essere necessari fino a 20 minuti sotto carico prima di riscontrare un miglioramento significativo nelle prestazioni del cluster. Bigtable scala i nodi in un cluster in base al carico.

  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 dovrebbe utilizzare dischi SSD, che offrono prestazioni notevolmente migliori rispetto ai dischi HDD. Per maggiori dettagli, consulta Scegliere tra l'archiviazione SSD e HDD.

• Si sono verificati problemi con la connessione di rete. I problemi di rete possono ridurre la velocità effettiva e causare letture e scritture più lunghe del solito. In particolare, potresti riscontrare problemi se i tuoi client non sono in esecuzione nella stessa zona del cluster Bigtable o se i tuoi client vengono eseguiti al di fuori di Google Cloud.

• Stai utilizzando la replica, ma la tua applicazione usa una libreria client non aggiornata. Se noti un aumento della latenza 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 le 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 cluster. In un'istanza che utilizza la replica, ciascun cluster deve gestire il lavoro di replica, oltre al carico che riceve dalle applicazioni. I cluster con underprovisioning possono causare un aumento della latenza. Puoi verificarlo controllando i grafici sull'utilizzo della CPU dell'istanza nella console Google Cloud.

Poiché carichi di lavoro diversi possono causare variazioni delle prestazioni, dovresti eseguire test con i tuoi carichi di lavoro per ottenere i benchmark più accurati.

Avvii a freddo e QPS basse

Gli avvii a freddo e il valore QPS basso possono aumentare la latenza. Bigtable offre prestazioni migliori con le tabelle di grandi dimensioni a cui accedi di frequente. Per questo motivo, se inizi a inviare richieste dopo un periodo di nessun utilizzo (avvio a freddo), potresti notare un'elevata latenza mentre Bigtable ristabilisce le connessioni. La latenza è maggiore anche quando il valore QPS è basso.

Se il valore QPS è basso o se sai che a volte invii richieste a una tabella Bigtable dopo un periodo di inattività, puoi provare le seguenti strategie per mantenere calda la connessione ed evitare questa latenza elevata.

• Invia sempre una bassa percentuale di traffico artificiale alla tabella.
• Configura il pool di connessioni per assicurarti che una QPS costante mantenga attivo il pool.

Se utilizzi una versione del client Cloud Bigtable per Java precedente alla 2.18.0, puoi abilitare l'aggiornamento del canale. Nelle versioni successive, il priming del canale è abilitato per impostazione predefinita.

Durante gli avvii a freddo o i periodi con QPS basse, il numero di errori restituiti da Bigtable è più rilevante rispetto alla percentuale di operazioni che restituiscono un errore.

In che modo Bigtable ottimizza i dati nel tempo

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

1. Bigtable tenta di archiviare più o meno la stessa quantità di dati su ciascun nodo Bigtable.
2. Bigtable tenta di distribuire le letture e le 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 con molta frequenza, Bigtable potrebbe archiviare il tablet sul proprio nodo, anche se questo causa l'archiviazione di alcuni nodi più dati di altri.

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

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

Distribuzione della quantità di dati tra i nodi

Durante la scrittura 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 ne sposta alcuni in altri nodi del cluster, in modo che la quantità di dati venga bilanciata in modo più uniforme nel cluster:

Distribuzione di letture e scritture in modo uniforme tra i nodi

Se hai progettato lo schema correttamente, le letture e le scritture 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 a gestire questi casi prendendo in considerazione le letture e le scritture per il bilanciamento dei tablet tra i nodi.

Ad esempio, supponiamo che il 25% delle letture vada a 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 il più uniformemente possibile nell'intero cluster:

Testa le prestazioni con Bigtable

Se esegui un test delle prestazioni per un'applicazione che dipende da Bigtable, segui queste linee guida quando pianifichi ed esegui il test:

• Esegui test con una quantità sufficiente di dati.
  • Se le tabelle nell'istanza di produzione contengono un totale di 100 GB o meno di dati per nodo, esegui il test con una tabella della stessa quantità di dati.
  • Se le tabelle contengono più di 100 GB di dati per nodo, esegui il test con una tabella che contiene almeno 100 GB di dati per nodo. Ad esempio, se l'istanza di produzione ha un cluster a quattro nodi e le tabelle dell'istanza contengono un totale di 1 TB di dati, esegui il test utilizzando una tabella di almeno 400 GB.
• Esegui il test con una singola tabella.
• Resta al di sotto dell'utilizzo dello 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 impegnativo 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 ti aiuta a garantire che testerai le letture dal disco e le letture memorizzate nella cache dalla memoria.

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:

• Guarda 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 Visualizzatore 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 le letture e le scritture di Bigtable. Se il problema di prestazioni scompare, probabilmente stai utilizzando Bigtable in un modo che non genera prestazioni ottimali. Se il problema di prestazioni persiste, è probabile che il problema non sia correlato a Bigtable.

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

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

  Se utilizzi il client HBase per Java, devi creare un oggetto Connection anziché un client, quindi è consigliabile creare il minor numero di connessioni possibile.

• Assicurati di leggere e scrivere molte righe diverse nella tua tabella. Bigtable offre le migliori prestazioni quando le letture e le scritture sono distribuite uniformemente nella tabella, il che consente a Bigtable di distribuire il carico di lavoro su 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 che le prestazioni di lettura e scrittura siano quasi le stesse. Se le letture sono molto più veloci delle scritture, è possibile che tu stia tentando di leggere chiavi di riga che non esistono o un ampio intervallo di chiavi di riga che contiene solo un numero ridotto di righe.

  Per fare un confronto valido tra letture e scritture, dovresti cercare di ottenere almeno il 90% di queste letture per restituire risultati validi. Inoltre, se stai leggendo un ampio intervallo di chiavi di riga, misura le prestazioni in base al numero effettivo di righe nell'intervallo, anziché al numero massimo di righe che potrebbero esistere.

• Utilizzare il tipo giusto di richieste di scrittura per i tuoi dati. La scelta del modo ottimale per scrivere i dati consente di mantenere prestazioni elevate.

• Controlla la latenza di una singola riga. Se noti una latenza imprevista durante l'invio di richieste ReadRows, puoi controllare la latenza della prima riga della richiesta per restringere la causa. Per impostazione predefinita, la latenza complessiva per una richiesta ReadRows include la latenza per 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ò indica che la latenza è causata dal numero di richieste o dal tempo di elaborazione, piuttosto che da un problema di Bigtable.

  Se utilizzi la libreria client di Bigtable per Java, puoi visualizzare la metrica read_rows_first_row_latency in Esplora metriche della console Google Cloud dopo aver abilitato le metriche lato client.

• Usa un profilo dell'app separato per ogni carico di lavoro. Se si verificano problemi di prestazioni dopo l'aggiunta di un nuovo carico di lavoro, crea un nuovo profilo dell'app per il nuovo carico di lavoro. Dopodiché puoi monitorare separatamente le metriche dei profili delle app per risolvere ulteriormente i problemi. Per informazioni dettagliate sul motivo per cui è consigliabile usare più profili dell'app, consulta Come funzionano i profili dell'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 QPS elevate e distribuite uniformemente, l'aumento della latenza P100 (max) per una piccola percentuale di richieste non indica necessariamente un problema di prestazioni maggiore con Bigtable. Le metriche lato client possono darti insight su quale parte del ciclo di vita della richiesta potrebbe causare latenza.

Passaggi successivi

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