Istanze, cluster e nodi
Per utilizzare Bigtable, devi creare istanze, che contengono cluster a cui le tue applicazioni possono connettersi. Ogni cluster contiene nodi, ovvero le unità di calcolo che gestiscono i dati ed eseguono attività di manutenzione.
Questa pagina fornisce ulteriori informazioni su istanze, cluster e nodi Bigtable.
- Per scoprire come creare un'istanza, consulta Crea un'istanza.
- Per scoprire come aggiungere o eliminare i cluster, consulta Modificare un'istanza.
- Per scoprire come monitorare un'istanza e i relativi cluster, consulta Monitoraggio di un'istanza.
- Per scoprire come aggiornare il numero di nodi in un cluster, vedi Aggiungere o rimuovere nodi.
Prima di leggere questa pagina, devi acquisire familiarità con la panoramica di Bigtable.
Istanze
Un'istanza Bigtable è un contenitore per i tuoi dati. Le istanze hanno uno o più cluster, situati in zone diverse. Ogni cluster ha almeno un nodo.
Una tabella appartiene a un'istanza, non a un cluster o a un nodo. Se hai un'istanza con più di un cluster, stai utilizzando la replica. Ciò significa che non puoi assegnare una tabella a un singolo cluster o creare criteri di garbage collection unici per ogni cluster in un'istanza. Inoltre, non puoi fare in modo che ogni cluster memorizzi un insieme diverso di dati nella stessa tabella.
Un'istanza ha alcune proprietà importanti che devi conoscere:
- Il tipo di archiviazione (SSD o HDD)
- I profili di applicazione, che sono principalmente per le istanze che utilizzano la replica
Le sezioni seguenti descrivono queste proprietà.
Tipi di archiviazione
Quando crei un'istanza, devi scegliere se i cluster dell'istanza archivieranno i dati su unità a stato solido (SSD) o unità disco rigido (HDD). L'SSD è spesso, ma non sempre, la scelta più efficiente ed economica.
La scelta tra SSD e HDD è definitiva e ogni cluster nella tua istanza deve utilizzare lo stesso tipo di spazio di archiviazione, quindi assicurati di scegliere il tipo di spazio di archiviazione giusto per il tuo caso d'uso. Per ulteriori informazioni che ti aiutino a decidere, consulta la sezione Scelta tra SSD e HDD.
Se devi archiviare dati storici per motivi quali requisiti normativi, utilizza l'archiviazione Bigtable ad accesso sporadico nell'ambito dell'archiviazione a livelli (anteprima). Questa opzione è disponibile per le istanze SSD.
Profili di applicazione
Dopo aver creato un'istanza, Bigtable la utilizza per archiviare i profili delle applicazioni. Per le istanze che utilizzano la replica, i profili app controllano il modo in cui le tue applicazioni si connettono ai cluster dell'istanza.
Se l'istanza non utilizza la replica, puoi comunque utilizzare i profili dell'app per fornire identificatori separati per ciascuna delle tue applicazioni o per ciascuna funzione all'interno di un'applicazione. Puoi quindi visualizzare grafici separati per ogni profilo dell'app nella Google Cloud console.
Per scoprire di più sui profili delle app, consulta la sezione Profili di applicazione. Per scoprire come configurare i profili app della tua istanza, vedi Configurazione dei profili app.
Cluster
Un cluster rappresenta il servizio Bigtable in una località specifica. Ogni cluster appartiene a una singola istanza Bigtable e un'istanza può avere cluster in un massimo di 8 regioni. Quando l'applicazione invia richieste a un'istanza Bigtable, queste vengono gestite da uno dei cluster dell'istanza.
Ogni cluster si trova in una singola zona.
Un'istanza può avere cluster in un massimo di 8 regioni in cui
è disponibile Bigtable.
Ogni zona di una regione può contenere un solo cluster.
Ad esempio, se un'istanza ha un cluster in us-east1-b, puoi aggiungere un cluster
in una zona diversa della stessa regione, ad esempio us-east1-c, o in una zona di una regione
separata, ad esempio europe-west2-a.
Il numero di cluster che puoi creare in un'istanza dipende dal numero di zone disponibili nelle regioni che scegli. Ad esempio, se crei cluster in 8 regioni con 3 zone ciascuna, il numero massimo di cluster che l'istanza può avere è 24. Per un elenco delle zone e delle regioni in cui Bigtable è disponibile, consulta Località Bigtable.
Le istanze Bigtable con un solo cluster non utilizzano la replica. Se aggiungi un secondo cluster a un'istanza, Bigtable inizia automaticamente a replicare i dati mantenendo copie separate dei dati nelle zone di ciascun cluster e sincronizzando gli aggiornamenti tra le copie. Puoi scegliere a quale cluster si connettono le tue applicazioni, il che consente di isolare diversi tipi di traffico. Puoi anche consentire a Bigtable di bilanciare il traffico tra i cluster. Se un cluster non è più disponibile, puoi eseguire il failover da un cluster all'altro. Per scoprire di più su come funziona la replica, consulta la panoramica della replica.
Nella maggior parte dei casi, devi abilitare la scalabilità automatica per un cluster, in modo che Bigtable aggiunga e rimuova i nodi in base alle esigenze per gestire i workload del cluster.
Quando crei un cluster, puoi abilitare la scalabilità dei nodi in incrementi di 2, una configurazione che imposta il cluster in modo che venga scalato sempre in incrementi di due nodi. Per ulteriori informazioni, consulta Fattore di scalabilità dei nodi.
Nodi
Ogni cluster in un'istanza ha uno o più nodi, ovvero le risorse di calcolo utilizzate da Bigtable per gestire i dati.
Dietro le quinte, Bigtable suddivide tutti i dati di una tabella in tablet separati. Le tabelle sono memorizzate su disco, separate dai nodi ma nella stessa zona dei nodi. Un tablet è associato a un singolo nodo.
Ogni nodo è responsabile di:
- Tenere traccia di tablet specifici sul disco.
- Gestione delle letture e scritture in entrata per i suoi tablet.
- Eseguire attività di manutenzione sui suoi tablet, ad esempio compattazioni periodiche.
Un cluster deve avere nodi sufficienti per supportare il carico di lavoro attuale e la quantità di dati archiviati. In caso contrario, il cluster potrebbe non essere in grado di gestire le richieste in entrata e la latenza potrebbe aumentare. Monitora l'utilizzo della CPU e del disco dei cluster e aggiungi nodi a un'istanza quando le relative metriche superano i suggerimenti riportati in Pianificare la capacità.
Per ulteriori dettagli su come Bigtable archivia e gestisce i dati, vedi Architettura di Bigtable.
Per i job di lettura con portata elevata, puoi utilizzare Data Boost per Bigtable per il calcolo anziché i nodi del cluster. Data Boost ti consente di inviare query e job di lettura di grandi dimensioni utilizzando il serverless computing, mentre l'applicazione principale continua a utilizzare i nodi del cluster per il computing. Per saperne di più, vedi la panoramica di Data Boost.
Per i carichi di lavoro di dati storici a cui non devi accedere spesso, puoi utilizzare il livello di accesso non frequente nelle istanze SSD.
Nodi per i cluster replicati
Quando l'istanza ha più di un cluster, il failover diventa un aspetto da considerare quando configuri il numero massimo di nodi per la scalabilità automatica o allochi manualmente i nodi.
Se utilizzi il routing multi-cluster in uno dei tuoi profili app, può verificarsi un failover automatico nel caso in cui uno o più cluster non siano disponibili.
Quando esegui il failover manuale da un cluster a un altro o quando si verifica il failover automatico, il cluster di ricezione dovrebbe idealmente avere una capacità sufficiente per supportare il carico. Puoi allocare sempre un numero sufficiente di nodi per supportare il failover, il che può essere costoso, oppure puoi fare affidamento sulla scalabilità automatica per aggiungere nodi quando il traffico esegue il failover, ma tieni presente che potrebbe esserci un breve impatto sulle prestazioni mentre il cluster viene scalato.
Se tutti i tuoi profili di app utilizzano il routing a cluster singolo, ogni cluster può avere un numero diverso di nodi. Ridimensiona ogni cluster in base alle esigenze in base al workload del cluster.
Poiché Bigtable archivia una copia separata dei tuoi dati in ogni cluster, ogni cluster deve sempre avere un numero di nodi sufficiente per supportare l'utilizzo del disco e per replicare le scritture tra i cluster.
Se necessario, puoi comunque eseguire manualmente il failover da un cluster a un altro. Tuttavia, se un cluster ha molti più nodi di un altro e devi eseguire il failover al cluster con meno nodi, potresti dover aggiungere nodi. Non è garantito che siano disponibili nodi aggiuntivi quando devi eseguire il failover. L'unico modo per prenotare i nodi in anticipo è aggiungerli al cluster.