Dimensione della transazione MySQL - quanto è grande è troppo grande?

Ho un processo di importazione che viene eseguito ogni tanto e voglio che sia un tipo di affare "tutto o niente", ovvero una transazione.

Ci sono molti aspetti e le importazioni possono produrre tra 100k-1mil + record. Ciò equivale a un carico utile che varia da diversi MB a poche centinaia di MB di dati.

So che le tabelle temporanee sono un'altra opzione, ma questo metodo sembra così utile.

Ci sono avvertenze di cui tenere conto riguardo a questo tipo di pratica con una grande quantità di manipolazione dei dati tra commit? (Al di fuori del tipico burst di caricamento in scrittura / indicizzazione una volta eseguito il commit)

— ghiaccio sottile
fonte

Personalmente, mi piace avere un equilibrio. Eseguo importazioni in transazioni da 1k o 10k, perché so solo che arriverebbe a circa 900k righe e poi si arresterà in modo anomalo a causa delle dimensioni del buffer o di qualcos'altro di ridicolo. Abbastanza facile da prendere da quello, e non tanto I / O.

— Capitano Hypertext

Un collo di bottiglia da tenere presente è il buffer di registro InnoDB. La dimensione è impostata da innodb_log_buffer_size . Ecco cosa dice la documentazione MySQL al riguardo:

La dimensione in byte del buffer utilizzata da InnoDB per scrivere nei file di registro sul disco. Il valore predefinito è 8 MB. Un buffer di registro di grandi dimensioni consente l'esecuzione di transazioni di grandi dimensioni senza la necessità di scrivere il registro su disco prima del commit delle transazioni. Pertanto, se si hanno grandi transazioni, allargando il buffer di registro si risparmia l'I / O del disco.

Il buffer di registro InnoDB non deve essere confuso con il pool di buffer InnoDB. La principale differenza tra loro è il loro scopo. Il buffer del registro di InnoDB registra sostanzialmente le modifiche a breve termine che vengono scritte nei registri di ripetizione (ib_logfile0, ib_logfile1). Il pool di buffer InnoDB (dimensionato da innodb_buffer_pool_size ) memorizza nella cache i dati e le pagine dell'indice che devono essere salvate (se le pagine sono sporche) e infine scritte) sul disco. Una volta eseguito il commit, le pagine delle modifiche rimangono nella RAM fino a quando non vengono rimosse tramite le regole LRU.

Le grandi transazioni devono essere incanalate nel Log Buffer. Come accennato, un buffer di registro più grande ridurrà l'I / O del disco. Solo un grande commit presenterebbe un collo di bottiglia.

Potresti voler esaminare altre opzioni di InnoDB da configurare.

innodb_flush_method : determina la modalità di gestione del flush e se consentire o meno al sistema operativo di memorizzare nella cache le scritture su InnoDB ( è necessario sperimentare tra O_DSYNC e O_DIRECT )
innodb_read_io_threads (Usa il massimo: 64)
innodb_write_io_threads (Usa il massimo: 64)
innodb_io_capacity (usa valori più alti come 5000 o 10000, ma l'hardware lo completerà per te, in altre parole, lascia che l'hardware decida la capacità di I / O una volta assegnato un numero enorme)
innodb_thread_concurrency : il valore predefinito è 0. Ho imparato in prima persona da Ronald Bradford a Percona NYC 2011 a lasciare questo numero a 0. Ciò consente a InnoDB di decidere il miglior numero di ticket di concorrenza che è in grado di gestire)

Ho altri post sull'ottimizzazione di InnoDB per ulteriori ricerche

— RolandoMySQLDBA
fonte

in qualche modo sapevo che saresti stato su questo. Grazie per le risposte approfondite che sembri sempre dare. Domanda a margine: disponi di risorse sull'uso di innodb_io_capacity? Quando la documentazione suggerisce che un SATA consumer 5400 / 7200RPM ha un valore di 100, la tua strategia ti suggerisce di "rimuovere il limite" impostando quel valore così alto?

— magrezza

Di solito imposto un valore innodb_io_capacity più alto e lascio che l'hardware lo superi. Aggiungerò questo alla mia risposta proprio ora.

— RolandoMySQLDBA,