Descrizione delle prestazioni

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

Prestazioni per workload tipici

Bigtable offre prestazioni altamente prevedibili e scalabilità lineare. 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 archiviazione utilizzato dal cluster:

Livello di archiviazione	Letture		Scritture		Scansioni
Livello in memoria (anteprima)	fino a 120.000 righe al secondo^1	o	fino a 10.000 righe al secondo^2		N/D
SSD	fino a 17.000 righe al secondo	o	fino a 14.000 righe al secondo	o	Fino a 220 MBps
HDD	fino a 500 righe al secondo	o	fino a 10.000 righe al secondo	o	Fino a 180 MBps
Archiviazione ad accesso sporadico	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.

¹ Un nodo Enterprise Plus include 40.000 righe al secondo e può scalare verticalmente fino a 120.000 righe al secondo per nodo con incrementi di 40.000. Per saperne di più, consulta Livello in-memory.

² Un numero elevato di scritture di righe al secondo nei dati nel livello in memoria può influire sul throughput di scrittura.

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 workload di sola lettura o di sola scrittura senza il livello in-memory abilitato. Con il livello in memoria abilitato, il cluster può supportare una velocità effettiva di lettura fino a 1,2 milioni di righe al secondo.

Nota: questi numeri relativi alle prestazioni sono solo stime e riflettono un workload di sola lettura o di sola scrittura. Le prestazioni di Bigtable sono strettamente correlate al workload, alla progettazione dello schema e alle caratteristiche del set di dati. Questi numeri relativi alle prestazioni 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.

Pianifica la capacità di Bigtable

Quando pianifichi i cluster Bigtable, decidi se vuoi ottimizzare la latenza o il throughput. Ad esempio, per un job di trattamento dati in 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 alla velocità effettiva. Puoi raggiungere i numeri nella sezione Prestazioni per i workload tipici quando esegui l'ottimizzazione per il throughput.

Livello in memoria

Anteprima

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Con il livello in memoria abilitato, ogni nodo include 40.000 righe al secondo. L'aggiunta di nodi in orizzontale aumenta la capacità totale del cluster. Inoltre, ogni nodo può scalare verticalmente fino a un massimo di 120.000 righe al secondo per nodo per supportare il throughput di lettura in memoria. Quando viene raggiunto il limite di scalabilità verticale, la scalabilità automatica di Bigtable aggiunge altri nodi per scalare orizzontalmente. Un cluster con scalabilità manuale supporta la scalabilità verticale in memoria fino al raggiungimento della capacità di throughput. La scalabilità verticale oltre le 40.000 righe al secondo di base viene fatturata applicando un moltiplicatore al costo orario del nodo. Per saperne di più, consulta i prezzi.

Ogni nodo in memoria include 8 GB di capacità di archiviazione. Mentre il throughput può scalare verticalmente, la capacità di archiviazione rimane fissa per nodo. Tuttavia, lo scale out aggiunge altri 8 GB di memoria per ogni nuovo nodo. Poiché lo spazio di archiviazione non aumenta durante la scalabilità verticale, il tasso di mancati riscontri di un workload potrebbe aumentare quando un nodo scala verticalmente il throughput in memoria.

Utilizzo CPU

Nella maggior parte dei 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.

Utilizza le seguenti 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 della tua 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 ottenere prestazioni ottimali.

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

Per saperne di più 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 lo spazio di archiviazione distribuendo i dati su tutti i nodi del cluster.

Quando stimi i requisiti di archiviazione e il numero di nodi del cluster per la pianificazione della capacità, basa i calcoli sulle dimensioni previste dei dati compressi anziché sui dati di origine non compressi. Bigtable comprime i dati automaticamente durante la scrittura nello spazio di archiviazione. A seconda della progettazione dello schema e del pattern dei dati, la compressione può ridurre notevolmente l'impatto dell'archiviazione fisica sul disco. Per linee guida sulla comprimibilità dei dati, consulta Compressione dei dati.

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 archivia 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 ha un numero di nodi sufficiente per 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 più elevata e un throughput inferiore.

Per configurare le impostazioni di scalabilità automatica, inizia con quanto segue. 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 saperne di più, consulta Spazio di archiviazione per nodo.

Esegui i tuoi workload su Bigtable

Esegui sempre i workload su un cluster Bigtable quando pianifichi la capacità per determinare l'allocazione delle risorse migliore 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 workload. In questo caso, ottimizza 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 ulteriori best practice, consulta Test delle prestazioni con Bigtable.

Cause del rallentamento delle prestazioni

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 un'unica richiesta di lettura. Bigtable analizza la tabella e legge le righe richieste in sequenza. Questa mancanza di parallelismo influisce sulla latenza complessiva e le letture che raggiungono un nodo hot possono aumentare la latenza tail. Per i dettagli, consulta Letture e prestazioni.
• Lo schema della tabella non è progettato in modo corretto. Per ottenere buone prestazioni da Bigtable, è essenziale progettare uno schema che consenta di distribuire uniformemente le letture e le scritture in ogni tabella. Inoltre, gli hotspot in una tabella possono influire sulle prestazioni di altre tabelle nella stessa istanza. Per saperne di più, consulta Best practice per la progettazione degli schemi.
• Le righe della tabella Bigtable contengono grandi quantità di dati. Le stime delle prestazioni 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 in una riga. Inoltre, ogni cella aggiunge un overhead alla quantità di dati archiviati nella tabella e inviati sulla rete. Ad esempio, se memorizzi 1 KB (1024 byte) di dati, è molto più efficiente in termini di spazio memorizzarli in una singola cella, anziché distribuirli su 1024 celle che contengono ciascuna 1 byte. 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 esistente è inviare un'eliminazione per tutte le versioni precedenti con ogni riscrittura.

• Il cluster non ha un numero sufficiente di nodi. I nodi di un cluster forniscono il computing per il cluster 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 per soddisfare i limiti consigliati sia per il computing che per lo spazio di archiviazione. Utilizza gli strumenti di monitoraggio per verificare se il cluster è sovraccarico.

  • Computing: se la CPU del cluster Bigtable è sovraccarica, l'aggiunta di altri nodi migliora le prestazioni 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 la latenza e il 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ù, consulta 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, consulta 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 dei problemi se i client non sono in esecuzione nella stessa zona del cluster Bigtable o se i client 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 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 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 di utilizzo della CPU dell'istanza nella console Google Cloud .

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

Avvii a freddo e QPS basse

Gli avvii a freddo e le QPS basse 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 inutilizzo (un avvio a freddo), potresti osservare una latenza elevata mentre Bigtable ristabilisce le connessioni. La latenza è più elevata anche quando le QPS sono basse.

Se le QPS sono basse 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 una frequenza ridotta 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 basse, il numero di errori restituiti da Bigtable è più rilevante della 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.17.1, puoi attivare l'aggiornamento del canale. Nelle versioni successive, l'aggiornamento del canale è abilitato per impostazione predefinita. L'aggiornamento del canale ha due effetti:

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

Tuttavia, questo non mantiene attivo il canale quando ci sono periodi di inattività.

In che modo Bigtable ottimizza i dati nel tempo

Per archiviare i dati sottostanti per ciascuna delle tue tabelle, Bigtable suddivide i dati 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 tra loro. Ad esempio, se le righe di un tablet vengono lette con estrema frequenza, Bigtable potrebbe archiviare quel tablet sul proprio nodo, anche se ciò comporta che alcuni nodi archivino più dati di altri.

Nell'ambito di questo processo, Bigtable potrebbe suddividere un tablet in due o più tablet più piccoli per ridurne le dimensioni o per isolare le righe hot 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 suddivide i dati della tabella in tablet. Ogni tablet contiene un intervallo contiguo di righe all'interno della tabella.

Se hai scritto meno di qualche 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 per bilanciare la quantità di dati in modo più uniforme nel cluster:

Distribuzione uniforme di letture e scritture tra i nodi

Se hai progettato lo schema correttamente, le letture e le scritture dovrebbero essere distribuite in modo abbastanza uniforme su tutta la tabella. Tuttavia, in alcuni casi non è possibile evitare di accedere ad alcune 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 indirizzato 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 nel modo più uniforme possibile nell'intero cluster:

Testa 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 i 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 della 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 l'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.
• Esegui il 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 eseguire il test, esegui un pre-test intensivo per diversi minuti. Questo passaggio consente a Bigtable 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 contribuisce a garantire che vengano testate le letture dal disco e le letture memorizzate nella cache dalla memoria.
• Per i test del livello in memoria (anteprima), assicurati che la durata del test sia sufficiente per completare il livello in memoria con le letture.

Risolvi 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 stanno causando risultati indesiderati, come hotspot su righe specifiche o un utilizzo eccessivo della CPU. Per saperne di più, consulta Utilizza 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 un modo che comporta prestazioni non ottimali. Se il problema di prestazioni persiste, probabilmente non è correlato a Bigtable.

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

  • Se utilizzi la replica o i profili app per identificare diversi tipi di traffico verso la tua istanza, crea un client per profilo app e condividi i client nell'applicazione.
  • Se non utilizzi la replica o i profili dell'app, crea un singolo client e condividilo nell'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 migliori prestazioni quando le letture e le scritture sono distribuite in modo uniforme nella tabella, il che aiuta Bigtable a distribuire il workload 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 ti accorgi che stai leggendo e scrivendo 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 le prestazioni di lettura e scrittura siano approssimativamente le stesse. Se noti che le letture sono molto più veloci delle scritture, è possibile che tu stia tentando di leggere chiavi di riga che non esistono o un intervallo di chiavi di riga di grandi dimensioni 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 intervallo ampio di chiavi di riga, misura le prestazioni in base al numero effettivo di righe in quell'intervallo, anziché al numero massimo di righe che potrebbero esistere.

• Utilizza il tipo di richieste di scrittura appropriato per i tuoi dati. La scelta del modo ottimale per scrivere i dati aiuta a mantenere prestazioni elevate.

• Controlla la latenza per 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 il campo delle cause. Per impostazione predefinita, la latenza complessiva di una richiesta ReadRows include la latenza di ogni riga della richiesta, nonché 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, puoi visualizzare la metrica read_rows_first_row_latency in Esplora metriche della consoleGoogle Cloud dopo aver abilitato le metriche lato client.

• Utilizza un profilo dell'app separato per ogni workload. Se riscontri problemi di prestazioni dopo aver aggiunto un nuovo workload, crea un nuovo profilo istanza per il nuovo workload. In questo modo, puoi monitorare le metriche dei profili dell'app separatamente per risolvere ulteriori problemi. Consulta Come funzionano i profili app per informazioni dettagliate sul motivo per cui è una best practice utilizzare più profili app.

• Abilita 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 elevati e distribuiti in modo uniforme, una latenza P100 (massima) aumentata per una piccola percentuale di richieste non indica necessariamente un problema di prestazioni più ampio con Bigtable. Le metriche lato client possono darti informazioni su quale parte del ciclo di vita della richiesta potrebbe causare la latenza.

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

Connettività diretta

Bigtable supporta la connettività diretta per il traffico delle applicazioni che soddisfa determinati criteri, bypassando il frontend di Google e ottimizzando le prestazioni. Eseguire l'upgrade all'ultima versione della libreria client per sfruttare la connettività diretta può migliorare il throughput e la latenza. La connettività diretta è fornita per le applicazioni con le seguenti caratteristiche:

• In esecuzione su una macchina virtuale Compute Engine o Google Kubernetes Engine (GKE) in una rete Virtual Private Cloud (VPC)
• Utilizzo di una libreria client Bigtable supportata
• Utilizzo di un profilo dell'app standard (non Data Boost)
• In una rete configurata con route e regole firewall che consentono al traffico in uscita di raggiungere 34.126.0.0/18 e 2001:4860:8040::/42

La connettività diretta è supportata e abilitata per impostazione predefinita quando utilizzi una delle seguenti librerie client di Bigtable:

• Java versione 2.76.0 o successive
• Adattatore HBase versione 2.17.0 o successive
• Go versione 1.50.1 o successiva

Sono supportati sia IPv4 che IPv6. Per saperne di più, consulta Connettività diretta ad API e servizi nella documentazione VPC.

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 il codice campione per aggiungere nodi a un cluster Bigtable in modo programmatico.