Best practice per il caricamento collettivo

Questa pagina fornisce 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 sul rendimento 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 carico di dati tra le risorse di calcolo dell'istanza. Dopo alcuni minuti di carico elevato, Spanner introduce confini suddivisi tra le righe. In generale, se le tue il carico di dati sia ben distribuito e rispetti 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.

Partiziona i dati in base alla chiave primaria

Spanner partiziona automaticamente le tabelle in intervalli più piccoli. La 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 le righe alle partizioni:

  • Ordina i dati in base alla chiave primaria.
  • Suddividi i dati in 10 * (numero di nodi) partizioni separate di uguale dimensione.
  • Crea e assegna un'attività di worker separata a ogni partizione. La creazione delle attività dei worker avviene nella tua 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 3 nodi. Hai 90.000 righe in una tabella non interlacciata. 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 insieme congruo di righe in un commit e probabilmente toccare i dati in partizioni diverse. La latenza e il sovraccarico dei commit sono più elevati quando vengono scritti più split in un commit, a causa dell'aumento del coordinamento tra i server. È probabile che siano coinvolte più suddivisioni, poiché ogni riga casuale potrebbe appartenere a una suddivisione diversa. Nel peggiore dei casi, ogni scrittura coinvolge ogni suddivisione dell'istanza Spanner. Come accennato in precedenza, la velocità in scrittura si riduce quando sono coinvolte 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 menzionato In precedenza, la velocità effettiva di scrittura diminuirà quando sono coinvolte più partizioni.

Evita il sovraccarico

È possibile inviare più richieste di scrittura di quante ne possa fare Spanner . Spanner gestisce il sovraccarico interrompendo le transazioni, operazione chiamata pushback. Per le transazioni di sola scrittura, Spanner ritenta automaticamente la transazione. In questi casi, il pushback viene visualizzato come latenza elevata. Durante i carichi pesanti, il respingimento può durare fino a un minuto. Durante molto pesanti, il respingimento può durare diversi minuti. Per evitare il pushback, devi limitare le richieste di scrittura per mantenere l'utilizzo della CPU entro limiti ragionevoli. In alternativa, gli utenti possono aumentare il numero di nodi in modo che l'utilizzo della CPU rimanga nei limiti.

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

Ogni scrittura in Spanner comporta un sovraccarico, indipendentemente dal fatto che sia di piccole o grandi dimensioni. Per massimizzare la velocità effettiva, massimizza la quantità di dati archiviati per e scrivere. Le scritture più grandi riducono il rapporto di overhead per scrittura. Una buona tecnica è che ogni commit modifichi centinaia di righe. Quando scrivi righe relativamente grandi, solitamente una dimensione del commit compresa tra 1 MB e 5 MB offre le migliori prestazioni. Quando scrivi valori piccoli o valori indicizzati, in genere è meglio scrivere al massimo alcune centinaia di righe in un singolo commit. Indipendentemente dalle dimensioni e dal numero di righe del commit, tieni presente che esiste un limite di 80.000 mutazioni per commit. Per determinare il rendimento ottimale, devi testare e misurare la velocità in bit.

I commit di dimensioni superiori a 5 MB o a più di qualche centinaio di righe non offrono vantaggi extra e rischiano di superare Spanner Limiti relativi alle dimensioni e alle mutazioni dei commit 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 di completare immediatamente la modifica dello schema. 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.

  • L'aggiunta dell'indice dopo il caricamento dei dati significa che ogni scrittura è efficiente. Tuttavia, la modifica allo schema per ogni backfill dell'indice può richiedere molto tempo. Il database non è completamente utilizzabile e le query non possono utilizzare gli indici finché tutte le modifiche allo schema non sono state completate. Il database può continuare a eseguire operazioni di scrittura ma a una velocità inferiore.

Ti consigliamo di aggiungere gli 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 sull'utilizzo del partizionamento e del monitoraggio delle prestazioni, consulta Massimizzare il throughput del 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 documento continueranno .

Se disponi di indici secondari, le istruzioni potrebbero generare le prestazioni dei dispositivi. Il rendimento dipende dal numero di suddivisioni, in media, coinvolte nelle tue 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 è più grande delle dimensioni attuali totali della tabella aggiornata, elimina gli indici secondari e aggiungili di nuovo dopo aver caricato i dati. In genere questo passaggio non è necessario, ma potrebbe migliorare la throughput.