Best practice per il caricamento collettivo

Questa pagina fornisce le linee guida per il caricamento collettivo efficiente di grandi quantità di dati in Spanner.

Hai diverse opzioni per il caricamento collettivo dei dati in Spanner:

Sebbene sia possibile inserisci righe utilizzando Google Cloud CLI, non è consigliabile utilizzare gcloud CLI per il caricamento collettivo.

Linee guida sulle prestazioni per il caricamento collettivo

Per ottenere prestazioni ottimali di caricamento collettivo, massimizza l'uso del partizionamento per distribuire i dati di scrittura tra le attività worker.

Spanner usa la suddivisione basata sul carico per distribuire uniformemente i dati alle risorse di calcolo dell'istanza. Dopo alcuni minuti di carico elevato, Spanner introduce confini della suddivisione tra le righe. In generale, se le tue il carico di dati sia ben distribuito e segui le best practice per la progettazione dello schema e il caricamento collettivo, la velocità effettiva di scrittura dovrebbe raddoppiare a intervalli di alcuni minuti saturare le risorse di CPU disponibili nell'istanza.

Partizionare i dati in base alla chiave primaria

Spanner partiziona dinamicamente le tabelle in intervalli più piccoli. Il principale per una riga determina dove è partizionata.

Per ottenere una velocità effettiva di scrittura ottimale per i caricamenti collettivi, suddividi i dati in base ai chiave con questo pattern:

  • Ogni partizione contiene un intervallo di righe consecutive, come determinato dalla chiave colonne.
  • Ogni commit contiene dati relativi a una sola partizione.

Consigliamo che il numero di partizioni sia dieci volte superiore al numero di nodi in dell'istanza Spanner. Per assegnare righe alle partizioni:

  • Ordina i dati in base alla chiave primaria.
  • Dividi i dati in 10 * (numero di nodi), separati e di uguali dimensioni partizioni di Compute Engine.
  • Crea e assegna un'attività worker separata a ciascuna partizione. La creazione del che avvengono nell'applicazione. Non è una funzionalità di Spanner.

Seguendo questo pattern, dovresti vedere una velocità effettiva complessiva massima di scrittura collettiva di 10-20 MB al secondo per nodo per carichi di grandi dimensioni.

Quando carichi i dati, Spanner crea e aggiorna le suddivisioni per bilanciare sui nodi della tua istanza. Durante questa procedura, potresti riscontrare di riduzione temporanea della velocità effettiva.

Esempio

Hai una configurazione regionale con tre nodi. Hai 90.000 righe in un senza interleaving. Le chiavi primarie nella tabella sono comprese tra 1 e 90.000.

  • Righe: 90.000 righe
  • Nodi: 3
  • Partizioni: 10 * 3 = 30
  • Righe per partizione: 90.000 / 30 = 3000.

La prima partizione include l'intervallo di chiavi da 1 a 3000. La seconda partizione include l'intervallo di chiavi da 3001 a 6000. La 30a partizione include l'intervallo di chiavi da 87001 a 90000. Non devi utilizzare chiavi sequenziali in una tabella di grandi dimensioni. Questo esempio è solo a scopo dimostrativo).

Ogni attività worker invia le scritture per una singola partizione. All'interno di ogni partizione, devi scrivere le righe in sequenza in base alla chiave primaria. Se le righe vengono scritte in modo casuale, rispetto alla chiave primaria, dovrebbe anche fornire una velocità effettiva ragionevolmente elevata. Misurare le esecuzioni dei test ti consentirà di capire qual è l'approccio migliore per il tuo set di dati.

Se decidi di non utilizzare le partizioni

La scrittura di righe casuali all'interno di un commit potrebbe essere più lenta rispetto alla scrittura di un un insieme contiguo di righe in un commit e probabilmente riguardano dati in diversi partizioni di Compute Engine. La latenza di commit e l'overhead sono maggiori quando sono in corso più suddivisioni in un commit, grazie al maggiore coordinamento tra i server. Più di uno sono probabilmente coinvolti, perché ogni riga casuale può appartenere a una suddivisione diversa. Nel peggiore dei casi, ogni scrittura coinvolge ogni suddivisione nell'istanza Spanner. Come come detto in precedenza, la velocità effettiva di scrittura viene ridotta quando sono presenti più suddivisioni.

Caricamento collettivo senza partizionamento

Scrivere un insieme contiguo di righe in un commit può essere più veloce rispetto alla scrittura casuale righe. Le righe casuali probabilmente includono anche dati di partizioni diverse.

Quando in un commit vengono scritte più partizioni, si aumenta il coordinamento dei server, con un conseguente aumento della latenza di commit e dell'overhead.

È probabile che siano coinvolte più partizioni perché ogni riga casuale potrebbe appartenere a una partizione diversa. Nel peggiore dei casi, ogni scrittura implica ogni partizione dell'istanza Spanner. Come detto in precedenza, la velocità effettiva viene ridotta quando sono coinvolte più partizioni.

Evita il sovraccarico

È possibile inviare più richieste di scrittura di quante ne possa gestire Spanner. Spanner gestisce il sovraccarico interrompendo le transazioni, respingimento. Per le transazioni di sola scrittura, Spanner riproverà automaticamente a transazione. In questi casi, il pushback si presenta con una latenza elevata. Durante le attività intensa viene caricato, il pushback può durare fino a un minuto. In caso di carichi molto pesanti, il pushback può durare diversi minuti. Per evitare respingimenti, devi limitare di scrittura per mantenere l'utilizzo della CPU entro ragionevole limiti. In alternativa, gli utenti possono aumentare il numero di nodi in modo che l'utilizzo della CPU rimanga entro i limiti.

Esegui il commit di mutazioni comprese tra 1 e 5 MB alla volta

Ogni scrittura su Spanner comporta un overhead, indipendentemente dal fatto che la scrittura sia grande o piccole. Per massimizzare la velocità effettiva, massimizza la quantità di dati archiviati per scrittura. Le scritture più grandi riducono il rapporto di overhead per scrittura. Una buona tecnica è quella di ciascuna si impegna a mutare centinaia di righe. Quando si scrivono righe relativamente grandi, una dimensione di commit compresa tra 1 MB e 5 MB di solito le migliori prestazioni possibili. Quando si scrivono valori piccoli o indicizzati, i valori in genere è meglio scrivere al massimo qualche centinaio di righe in un singolo commit. Indipendentemente dalla dimensione del commit e dal numero di righe, tieni presente che il limite è di 80.000, mutazioni per commit. Per determinare il rendimento ottimale, devi testare e misurare la velocità effettiva.

I commit di dimensioni superiori a 5 MB o a più di qualche centinaio di righe non offrono vantaggi extra e rischiano di superare i limiti di Spanner. dimensioni del commit e mutazioni per commit.

Linee guida per gli indici secondari

Se il database ha indici secondari, devi scegliere se aggiungere allo schema del database prima o dopo il caricamento dei dati della tabella.

  • L'aggiunta dell'indice prima del caricamento dei dati consente il completamento della modifica dello schema immediatamente. Tuttavia, ogni scrittura sull'indice richiede più tempo perché deve aggiornare l'indice. Una volta completato il caricamento, il database sia immediatamente utilizzabile con tutti gli indici. Per creare una tabella e i relativi contemporaneamente, invia le istruzioni DDL per la nuova tabella e nuovi indici in una singola richiesta a Spanner.

  • Aggiungere l'indice dopo aver caricato i dati significa che ogni scrittura è efficiente. Tuttavia, la modifica dello schema per ogni backfill dell'indice può richiedere molto tempo. Il database non è completamente utilizzabile e le query non possono usare gli indici fino a quando tutte le modifiche allo schema sono state completate. Il database può continuare a eseguire operazioni di scrittura ma a una velocità inferiore.

Ti consigliamo di aggiungere indici fondamentali per la tua applicazione aziendale prima di caricare i dati. Per tutti gli indici non critici, aggiungili dopo il tag della migrazione dei dati.

Testare e misurare la velocità effettiva

Prevedere la velocità effettiva può essere difficile. Ti consigliamo di verificare il caricamento la strategia di caricamento prima di eseguire il caricamento finale. Per un esempio dettagliato il partizionamento e il monitoraggio delle prestazioni, Massimizzazione della velocità effettiva di caricamento dei dati.

Best practice per il caricamento collettivo periodico su un database esistente

Se stai aggiornando un database esistente che contiene dati, ma non eventuali indici secondari, i suggerimenti in questo argomento continueranno a essere applicati.

Se disponi di indici secondari, le istruzioni potrebbero generare delle prestazioni. Il rendimento dipende da quanti segmenti, in media, sono coinvolte nelle transazioni. Se la velocità effettiva scende troppo bassa, puoi provare seguenti:

  • Includere un numero minore di mutazioni in ogni commit, che potrebbe aumentare e la velocità effettiva effettiva.
  • Se il caricamento è superiore alle dimensioni attuali totali della tabella aggiornati, elimina gli indici secondari e aggiungili di nuovo dopo il caricamento i dati. Questa operazione solitamente non è necessaria, ma potrebbe migliorare il e la velocità effettiva effettiva.