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 scalabili lineare. Se eviti le cause di prestazioni più lente descritte di seguito, ogni nodo Bigtable può fornire la seguente velocità effettiva approssimativa, in base al 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 tipico carico di lavoro di sola lettura o sola scrittura.

Pianifica la capacità di Bigtable

Scelta di un compromesso tra velocità effettiva elevata e bassa latenza

Quando pianifichi i cluster Bigtable, è importante valutare 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, ti potrebbe interessare più la velocità effettiva, ma meno la latenza. Un servizio online che gestisce le richieste degli utenti potrebbe invece dare la priorità a una minore latenza rispetto alla velocità effettiva. Di conseguenza, è importante pianificare la capacità di conseguenza.

I valori nella sezione Prestazioni per i carichi di lavoro tipici sono raggiungibili quando si dai 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 della CPU di un cluster è inferiore al 70%. Per le applicazioni sensibili alla latenza, tuttavia, ti consigliamo di pianificare almeno il doppio della capacità per il numero massimo di query Bigtable al secondo (QPS) dell'applicazione. Questa capacità garantisce che il cluster Bigtable venga eseguito con un carico della CPU inferiore al 50%, in modo da offrire una bassa latenza ai servizi front-end. Questa capacità fornisce inoltre un buffer per i picchi di traffico o gli hotspot di accesso alle chiavi, che possono causare un traffico sbilanciato tra i nodi del cluster.

compromesso tra utilizzo dello spazio di archiviazione e prestazioni

Un altro aspetto da considerare nella pianificazione della capacità è lo spazio di 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 in tutti i nodi del cluster.

Per determinare l'utilizzo dello spazio di archiviazione per nodo, puoi dividere 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 memorizza circa 3 TB, ovvero il 18,75% dello spazio di archiviazione HDD per 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 generali della CPU. Questo perché più elevato è lo spazio di archiviazione per nodo, maggiore sarà l'esecuzione di operazioni in background, come l'indicizzazione. L'aumento del lavoro in background per gestire più spazio di archiviazione può comportare una latenza maggiore e una velocità effettiva inferiore.

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

Per le applicazioni che non sono sensibili alla latenza, puoi archiviare più del 70% del limite, come spiegato in Spazio di archiviazione per nodo.

Esegui i tuoi carichi di lavoro tipici su Bigtable

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

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

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

Cause di prestazioni più lente

Esistono diversi fattori che possono causare prestazioni più lente di Bigtable rispetto alle stime mostrate sopra:

  • Hai letto un numero elevato di chiavi di riga o intervalli di righe non contigue 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 colpiscono un nodo ad accesso frequente possono aumentare la latenza tail. Per maggiori dettagli, consulta Letture e prestazioni.
  • Lo schema della tabella non è progettato correttamente. Per ottenere buone prestazioni da Bigtable, è essenziale progettare uno schema che renda possibile la distribuzione uniforme delle operazioni di lettura e scrittura su ogni tabella. Inoltre, gli hotspot in una tabella possono influire sulle prestazioni di altre tabelle nella stessa istanza. Per ulteriori informazioni, 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 verrà ridotto 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 attraverso la rete. Ad esempio, se stai memorizzando 1 kB (1024 byte) di dati, è molto più efficiente in termini di spazio archiviare i dati in una singola cella, anziché distribuirli in 1024 celle che contengono 1 byte ciascuna. Se suddividi i dati su più celle del necessario, potresti non ottenere le migliori prestazioni. 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 è inviare un'eliminazione per tutte le versioni precedenti con ogni riscrittura.

  • Il cluster non ha abbastanza nodi. I nodi di un cluster forniscono al cluster il calcolo necessario 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 abbia un numero sufficiente di nodi per soddisfare i limiti consigliati sia per le risorse di calcolo sia per l'archiviazione. Utilizza gli strumenti di monitoraggio per verificare se il cluster è sovraccarico.

    • Computing: se la CPU del tuo cluster Bigtable è sovraccaricata, 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 una latenza e una velocità effettiva ottimali, anche se il cluster dispone di 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, consulta 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 che le prestazioni del cluster registrino un miglioramento significativo. Bigtable scala i nodi in un cluster in base alle esperienze di caricamento.

    Quando diminuisci il numero di nodi in un cluster per fare lo scale down, prova a 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 hanno prestazioni notevolmente migliori rispetto ai dischi HDD. Per maggiori dettagli, vedi Scelta tra archiviazione SSD e HDD.

  • Si sono verificati problemi con la 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 cluster Bigtable o se i client eseguono 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 abilitato la replica, assicurati che la libreria client di Cloud Bigtable utilizzata dalla tua 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 verificare 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 l'attività di replica oltre al carico che riceve dalle applicazioni. I cluster con provisioning insufficiente possono causare una maggiore latenza. Per verificarlo, controlla i grafici relativi all'utilizzo della CPU dell'istanza nella console Google Cloud.

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

Avvii a freddo

Bigtable offre i migliori risultati con tabelle di grandi dimensioni a cui si accede di frequente. Per questo motivo, se inizi a inviare richieste dopo un periodo di inattività, potresti notare un'alta 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 la connessione attiva ed evitare questa latenza elevata. Inoltre, possono favorire le prestazioni durante i periodi con un valore QPS ridotto.

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, il priming del canale è abilitato per impostazione predefinita.

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

In che modo Bigtable ottimizza i dati nel tempo

Per archiviare i dati sottostanti per ciascuna delle tue tabelle, Bigtable suddivide i dati in cluster 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 approssimativamente la stessa quantità di dati su ciascun nodo Bigtable.
  2. Bigtable prova a distribuire le letture e le scritture in modo uguale su tutti i nodi

A volte queste strategie sono in conflitto tra loro. Ad esempio, se le righe di un tablet vengono lette molto spesso, Bigtable potrebbe archiviare il tablet sul proprio nodo, anche se questo fa sì che alcuni nodi memorizzino 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 di un tablet o per isolare le hot-row all'interno di un tablet esistente.

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

La distribuzione della quantità di dati tra i nodi

Quando scrivi dati in una tabella Bigtable, Bigtable esegue il frazionamento dei dati della tabella nei tablet. Ogni tablet contiene un intervallo contiguo di righe all'interno della tabella.

Se nella tabella hai scritto meno di diversi GB di dati, Bigtable archivia tutti i tablet in 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 sposta alcuni in altri nodi del cluster in modo che la quantità di dati venga bilanciata in modo più uniforme nel cluster:

Altri tablet sono distribuiti su più nodi.

La distribuzione uniforme di letture e scritture tra i nodi

Se hai progettato lo schema correttamente, le operazioni di lettura e scrittura devono essere distribuite in modo abbastanza uniforme nell'intera tabella. Tuttavia, in alcuni casi non è possibile evitare di accedere a determinate righe con maggiore frequenza rispetto ad altre. Bigtable ti aiuta a gestire questi casi, considerando le letture e le scritture quando bilancia i tablet tra i nodi.

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

Su 48 tablet, il 25% delle letture andrà a 3 tablet.

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

I tre tablet caldi sono isolati sul proprio nodo.

Testa le prestazioni con Bigtable

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

  • Esegui i test con una quantità sufficiente di dati.
    • Se le tabelle nell'istanza di produzione contengono un massimo di 100 GB di dati in totale 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 test con una singola tabella.
  • Rimani al di sotto dell'utilizzo dello spazio di archiviazione consigliato per nodo. Per maggiori dettagli, consulta Utilizzo dello spazio di archiviazione per nodo.
  • Prima di effettuare 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 dati e di assicurarti di testare le letture dal disco e le letture della memoria memorizzate nella cache.

Risolvere i problemi di prestazioni

Se ritieni che Bigtable potrebbe creare un collo di bottiglia per le 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 che mostrano i pattern di utilizzo per ogni tabella in un cluster. Key Visualizer consente di verificare se i tuoi pattern di utilizzo causano risultati indesiderati, come 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 operazioni di lettura e scrittura di Bigtable. Se il problema di rendimento scompare, è probabile che tu stia utilizzando Bigtable in modo da non funzionare correttamente. Se il problema di prestazioni persiste, probabilmente non riguarda Bigtable.

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

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

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

  • Assicurati di leggere e scrivere molte righe diverse nella tabella. Bigtable offre prestazioni migliori quando le operazioni di lettura e scrittura sono distribuite in modo uniforme nella tabella, consentendo a Bigtable di distribuire il carico di lavoro tra tutti i nodi del 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, potrebbe essere necessario 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 identiche. Se scopri che le letture sono molto più veloci delle scritture, potresti cercare di leggere chiavi di riga che non esistono o un ampio intervallo di chiavi di riga che contengono solo un numero limitato di righe.

    Per fare un confronto valido tra letture e scritture, dovresti puntare ad almeno il 90% delle letture per restituire risultati validi. Inoltre, se stai leggendo un'ampia gamma 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.

  • Utilizza il tipo corretto 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 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 per una richiesta ReadRows include la latenza per ogni riga nella richiesta, nonché 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 dai tempi di elaborazione, anziché da un problema con Bigtable.

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

  • Utilizza un profilo dell'app separato per ogni carico di lavoro. Se riscontri problemi di prestazioni dopo aver aggiunto un nuovo carico di lavoro, crea un nuovo profilo dell'app per il nuovo carico di lavoro. Poi puoi monitorare separatamente le metriche per i profili delle app per risolvere ulteriormente i problemi. Per informazioni dettagliate sul motivo per cui è consigliabile utilizzare più profili di app, consulta Come funzionano i profili di 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 un valore di QPS elevato a distribuzione uniforme, una latenza P100 (max) aumentata per una piccola percentuale di richieste non indica necessariamente un problema di prestazioni maggiore in Bigtable. Le metriche lato client possono fornirti insight su quale parte del ciclo di vita delle richieste potrebbe causare la latenza.

Passaggi successivi