Informazioni sul rendimento

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

Prestazioni per carichi di lavoro tipici

Bigtable offre prestazioni altamente prevedibili in modo lineare e scalabile. Evitando le cause di un rallentamento delle prestazioni descritte di seguito, ciascun nodo Bigtable può fornire velocità effettiva approssimativa, in base al tipo di archiviazione del cluster utilizza:

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 e i dati di Google Cloud.

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

Nota: questi dati relativi al rendimento sono solo stime e riflettono una di sola lettura o sola scrittura. Le prestazioni di Bigtable sono elevate dipendono dal carico di lavoro, dalla progettazione dello schema e dalle caratteristiche del set di dati. Questi i dati relativi al rendimento possono essere utili come punto di partenza per fare una stima del per esigenze di calcolo, ma non devono essere usate per il dimensionamento esatto del cluster o per stime dei costi.

Pianifica la capacità di Bigtable

Quando pianifichi i cluster Bigtable, decidi se vuoi ottimizzare la latenza o la velocità effettiva. Ad esempio, per un'elaborazione dati in batch, un job, potresti essere più interessato alla velocità effettiva e meno alla latenza. Al contrario, per un servizio online che soddisfa le richieste degli utenti, potresti dare la priorità a valori superiore rispetto alla velocità effettiva. Puoi ottenere i risultati desiderati nella scheda Rendimento per tipico carichi di lavoro quando esegui l'ottimizzazione per la velocità effettiva.

Utilizzo CPU

In quasi tutti i casi, consigliamo di utilizzare la scalabilità automatica, Bigtable aggiunge o rimuove nodi in base all'utilizzo. Per ulteriori informazioni le informazioni, vedi Scalabilità automatica.

Utilizza le seguenti linee guida quando configuri i target di scalabilità automatica scegli l'allocazione manuale dei nodi. Queste linee guida si applicano indipendentemente di cluster della tua istanza. Per un cluster con allocazione manuale dei nodi, devi monitorare l'utilizzo della CPU del cluster con l'obiettivo di mantenere al di sotto di questi valori per ottenere 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 è determinato dal tipo di archiviazione e dal numero di nodi in un cluster Kubernetes. Quando la quantità di dati archiviati in un cluster aumenta, Bigtable ottimizza lo spazio di archiviazione distribuendo la quantità dati in tutti i nodi del cluster.

Puoi determinare l'utilizzo dello spazio di archiviazione per nodo dividendo lo spazio di archiviazione del cluster (byte) per il numero di nodi nel cluster. Per Prendiamo come esempio 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 HDD per nodo (16 TB).

Quando l'utilizzo dello spazio di archiviazione aumenta, i carichi di lavoro possono registrare un incremento latenza di elaborazione delle query anche se il cluster ha nodi sufficienti per soddisfare la totalità di utilizzo della CPU. Questo perché maggiore è lo spazio di archiviazione per nodo, maggiore sarà lo sfondo come l'indicizzazione. L'aumento del lavoro in background da gestire più spazio di archiviazione può comportare una latenza più alta e una velocità effettiva inferiore.

Inizia con quanto segue quando configuri le impostazioni di scalabilità automatica. Se scegliere l'allocazione manuale dei nodi, monitorare l'uso dello spazio di archiviazione del cluster aggiungi o rimuovi 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

Esegui sempre i tuoi carichi di lavoro tipici su Bigtable cluster quando si pianifica la capacità, per individuare la risorsa migliore alla distribuzione per le tue applicazioni.

Lo strumento PerfKit Benchmarker di Google utilizza YCSB per eseguire il benchmarking del cloud i servizi di machine learning. Puoi seguire Tutorial PerfKitBenchmarker per Bigtable per creare test per i tuoi carichi di lavoro. Nel farlo, dovresti regolare nei file di configurazione yaml di benchmarking per verificare che il benchmark generato riflette le seguenti caratteristiche nella tua 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 saperne di più, consulta Test delle prestazioni con Bigtable best practice.

Cause di un rallentamento delle prestazioni

Esistono diversi fattori che possono aumentare le prestazioni di Bigtable rispetto alle stime sopra indicate:

• Leggi un numero elevato di chiavi di riga o intervalli di righe non contigui in un richiesta di lettura. Bigtable analizza la tabella e legge le richieste di righe in sequenza. Questa mancanza di parallelismo influisce sulla latenza complessiva, e qualsiasi lettura che raggiunge un nodo attivo può aumentare la latenza tail. Consulta Letture e rendimento per i dettagli.
• Lo schema della tabella non è progettato correttamente. Per ottenere un buon rendimento Bigtable è essenziale progettare uno schema che permetta per distribuire le letture e le scritture in modo uniforme in ogni tabella. Inoltre, gli hotspot dati in una tabella può 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à dati. Le stime di rendimento mostrate sopra presuppongono che ogni riga contenga 1 kB di dati. Puoi leggere e scrivere grandi quantità 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 celle. Bigtable impiega tempo per elaborare ogni cella in una riga. Inoltre, ogni cella aggiunge alla quantità di dati archiviati nella tabella e inviati sulla rete. Ad esempio: se archivi 1 KB (1.024 byte) di dati, è molto più efficiente in termini di spazio archiviare quei dati singola cella, invece di diffondere i dati in 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 Considera di conservare solo il valore più recente. Un altro per una tabella già esistente è inviare un'eliminazione per tutti i a ogni riscrittura.

• Il cluster non ha un numero sufficiente di nodi. I nodi di un cluster forniscono affinché il cluster gestisca le letture e le scritture in entrata, tieni traccia archiviazione ed eseguire attività di manutenzione come la compattazione. Devi assicurarti in modo che il cluster abbia un numero sufficiente di nodi per soddisfare i limiti consigliati computing e archiviazione. Utilizza gli strumenti di monitoraggio per verificare se il cluster è sovraccarico.

  • Computing: se la CPU del tuo cluster Bigtable è sovraccarico, l'aggiunta di altri nodi può migliorare le prestazioni distribuendo carico di lavoro su più nodi.
  • Spazio di archiviazione - Se l'utilizzo dello spazio di archiviazione per nodo è diventato superiore a quella consigliata, devi aggiungere altri nodi per mantenere latenza e velocità effettiva, anche se il cluster ha una CPU sufficiente per l'elaborazione richieste. Questo perché aumentando lo spazio di archiviazione per nodo aumenta la quantità di manutenzione in background per nodo. Per maggiori dettagli, consulta Permute tra dell'utilizzo e delle prestazioni dello spazio di archiviazione.

• Di recente è stato fatto lo scale up o lo scale down del cluster Bigtable. Una volta aumentato il numero di nodi in un cluster, possono essere necessarie fino a 20 minuti sotto carico, prima di osservare un miglioramento significativo delle prestazioni. Bigtable scala i nodi in un cluster in base per caricarle.

  Quando riduci il numero di nodi di 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 dei picchi di latenza.

• Il cluster Bigtable utilizza dischi HDD. Nella maggior parte dei casi, dovrebbe usare dischi SSD, che hanno prestazioni notevolmente migliori rispetto a quelli i dischi HDD. Consulta Scelta tra archiviazione SSD e HDD per i dettagli.

• Si sono verificati problemi con la connessione di rete. I problemi di rete possono ridurre e causano letture e scritture più lunghe del solito. In particolare, potresti riscontrare problemi se i tuoi clienti non utilizzano zona come cluster Bigtable o se i tuoi client eseguono al di fuori di Google Cloud.

• Stai utilizzando la replica, ma la tua applicazione utilizza un modello non aggiornato libreria client. Se noti un aumento della latenza dopo aver abilitato la replica, assicurati che la libreria client di Cloud Bigtable utilizzata dalla tua applicazione sia aggiornate. Le versioni precedenti delle librerie client potrebbero non essere ottimizzate per e supportare la replica. Consulta le librerie client di Cloud Bigtable per trova 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 che utilizza la replica, ogni cluster deve gestire il lavoro di replica oltre al carico che riceve dalle applicazioni. Con underprovisioning dei cluster possono causare un aumento della latenza. Puoi verificarlo controllando i grafici relativi all'utilizzo della CPU nella console Google Cloud.

Poiché carichi di lavoro diversi possono causare variazioni delle prestazioni, è consigliabile 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 esegue è la scelta migliore con tabelle di grandi dimensioni a cui si accede di frequente. Per questo motivo, se iniziare a inviare richieste dopo un periodo di non utilizzo (avvio a freddo), osservare una latenza elevata 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 delle 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 che precedenti alla 2.18.0, puoi attivare l'aggiornamento dei canali. Nelle versioni successive, il priming del canale sono abilitate per impostazione predefinita.

Durante gli avvii a freddo o i periodi con QPS basse, il numero di errori che I dati restituiti da Bigtable sono più rilevanti della percentuale che restituiscono un errore.

In che modo Bigtable ottimizza i dati nel tempo

Per archiviare i dati sottostanti per ciascuna delle tue tabelle, Bigtable esegue lo sharding dei dati su più tablet, che possono essere spostati tra i nodi un cluster Bigtable. Questo metodo di archiviazione abilita Bigtable per utilizzare due diverse strategie per l'ottimizzazione dei dati nel tempo:

1. Bigtable tenta di archiviare più o meno la stessa quantità di dati Nodo Bigtable.
2. Bigtable prova a distribuire le letture e le scritture in modo uniforme tra a tutti i nodi Bigtable.

A volte queste strategie sono in conflitto tra loro. Ad esempio, se uno le righe del tablet vengono lette con estrema frequenza, Bigtable il tablet sul proprio nodo, anche se questo fa sì che alcuni nodi archivino dati di altri utenti.

Nell'ambito di questo processo, Bigtable potrebbe anche suddividere un tablet due o più tablet più piccoli, per ridurne le dimensioni o per isolare righe 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

Quando scrivi dati in una tabella Bigtable, Bigtable esegue lo sharding dei 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 nel tuo cluster:

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

Distribuzione di letture e scritture in modo uniforme tra i nodi

Se hai progettato lo schema correttamente, allora legge e scrive devono essere distribuiti in modo abbastanza uniforme sull'intera tabella. Tuttavia, ci sono alcuni casi in cui non è possibile evitare di accedere a determinate righe con maggiore frequenza altri. Bigtable ti aiuta a gestire questi casi eseguendo letture e scrive quando bilancia i tablet tra i nodi.

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

Bigtable ridistribuirà i tablet esistenti in modo che le letture vengano distribuite il più uniformemente possibile nell'intero cluster:

Testa le prestazioni con Bigtable

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

• Esegui test con una quantità sufficiente di dati.
  • 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 della stessa quantità di dati.
  • Se le tabelle contengono più di 100 GB di dati per nodo, esegui il test con una contenente almeno 100 GB di dati per nodo. Ad esempio, se 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 il test con una singola tabella.
• Resta al di sotto dell'utilizzo dello spazio di archiviazione consigliato per nodo. Per maggiori dettagli, vedi 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 i pattern di accesso che osserva.
• Esegui il test per almeno 10 minuti. Questo passaggio consente Bigtable ottimizza ulteriormente i dati e aiuta a garantire testerà le letture dal disco e quelle memorizzate nella cache dalla memoria.

Risolvere i problemi di prestazioni

Se ritieni che Bigtable possa creare una performance collo di bottiglia nella tua applicazione, assicurati di controllare tutti gli elementi seguenti:

• Guarda le scansioni di Key Visualizer per la tua tabella. Lo strumento Key Visualizer per Bigtable genera nuovi dati di scansione ogni 15 che mostra i pattern di utilizzo per ciascuna tabella in un cluster. Legenda Il visualizzatore consente di verificare se i pattern di utilizzo stanno causando risultati indesiderati, come hotspot su righe specifiche o CPU eccessiva all'utilizzo delle risorse. Scopri come iniziare a utilizzare Key Visualizer.
• Prova a commentare il codice che esegue le letture e le scrive. Se il problema di prestazioni scompare, è probabile che tu stia utilizzando Bigtable in un modo che si traduce in prestazioni non ottimali. Se il problema di prestazioni persiste, probabilmente non è correlato Bigtable.

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

  • Se usi la replica o l'app profili per identificare diversi tipi di traffico verso il tuo Ad esempio, crei un client per ogni profilo dell'app e condividi i client in tutta l'applicazione.
  • Se non utilizzi la replica o i profili dell'app, crea un singolo client e condividerlo in tutta l'applicazione.

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

• Assicurati di leggere e scrivere molte righe diverse nella tabella. Bigtable offre prestazioni migliori quando letture e scritture sono uniformi distribuiti in tutta la tabella, il che aiuta Bigtable a distribuire il carico di lavoro in tutti i nodi del cluster. Se le operazioni di lettura e scrittura non possono distribuiti tra tutti i nodi Bigtable, le prestazioni soffrire.

  Se ti accorgi che stai leggendo e scrivendo solo un numero limitato di righe, Potrebbe essere necessario riprogettare lo schema in modo che le operazioni di lettura e scrittura sono distribuiti in modo più uniforme.

• Verifica che il rendimento sia quasi uguale per le letture e scrive. Se noti che le letture sono molto più veloci delle scritture, potresti dover leggere chiavi di riga che non esistono o un ampio intervallo di chiavi di riga contiene solo un numero limitato di righe.

  Per fare un confronto valido tra letture e scritture, dovresti puntare a almeno il 90% delle letture restituisca risultati validi. Inoltre, se leggi un un ampio intervallo di chiavi di riga, misura le prestazioni in base al numero effettivo righe incluse in quell'intervallo, anziché il numero massimo di righe che potrebbe essere. esistono.

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

• Controlla la latenza di una singola riga. Se noti una latenza imprevista durante inviando ReadRows richieste, puoi controllare la latenza della prima riga per individuare la causa. Per impostazione predefinita, la latenza complessiva La richiesta ReadRows include la latenza per ogni riga della richiesta, nonché il tempo di elaborazione tra le righe. Se la latenza complessiva è elevata, ma la prima di riga è bassa, ciò indica che la latenza è causata dal numero da richieste o tempi di elaborazione delle richieste, piuttosto che da un problema Bigtable.

  Se utilizzi la libreria client di Bigtable per Java, puoi visualizzare la metrica read_rows_first_row_latency nella 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 riscontri a problemi di prestazioni dopo l'aggiunta di un nuovo carico di lavoro, crea un nuovo profilo dell'app per il nuovo carico di lavoro. Poi puoi monitorare per i profili delle app separatamente per risolvere il problema. Consulta Come funzionano i profili delle app per scoprire perché è una best practice per usare più profili di app.

• Attiva le metriche lato client. Puoi configurare le metriche lato client per facilitare ottimizzare e risolvere i problemi relativi alle prestazioni. Ad esempio, poiché Bigtable funziona meglio con QPS elevate, distribuite uniformemente e P100 aumentato la latenza (max) per una piccola percentuale di richieste non indica necessariamente una un problema di prestazioni più grande con Bigtable. Le metriche lato client possono per fornirti 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 a Key Visualizzatore.
• Visualizza il codice campione per aggiungere nodi in modo programmatico a una Cluster Bigtable.