MariaDB
 sql >> Database >  >> RDS >> MariaDB

Comprendere la granularità dei blocchi in MySQL

Se lavori con MySQL da un po' di tempo, probabilmente hai sentito i termini "blocco a livello di tabella" e "blocco a livello di riga". Questi termini si riferiscono alla granularità del blocco in MySQL:in questo blog spiegheremo cosa significano e per cosa possono essere utilizzati.

Cos'è Lock Granularity in MySQL?

Ogni motore di archiviazione MySQL supporta diversi livelli di granularità per i propri blocchi. MySQL ha tre livelli di blocco:blocco a livello di riga, blocco a livello di pagina e blocco a livello di tabella. Ogni motore di archiviazione MySQL implementa il blocco in modo diverso offrendoti alcuni vantaggi e svantaggi distinti. Per prima cosa esamineremo cos'è la granularità del blocco, quindi esamineremo come funziona tutto in diversi motori di archiviazione.

In generale, i blocchi in MySQL rientrano in una di queste categorie. I blocchi possono essere:

  • A livello di pagina:tali tipi di granularità di blocco erano disponibili nei motori precedenti di MySQL, in particolare BDB, che è ora obsoleto a partire da MySQL 5.1. In breve, BDB era un motore di archiviazione incluso nelle versioni precedenti di MySQL ed era un motore di archiviazione transazionale che eseguiva i blocchi a livello di pagina. Poiché questi tipi di granularità dei blocchi non vengono più utilizzati, non li approfondiremo qui, ma in generale questi blocchi sono limitati ai dati e agli indici che risiedono su una pagina particolare. Se vuoi saperne di più su BDB, la pagina su MariaDB dovrebbe fornire qualche informazione in più.

  • A livello di tabella:MySQL utilizza il blocco a livello di tabella per tutti i motori di archiviazione eccetto InnoDB.

  • Il blocco a livello di riga viene utilizzato da InnoDB.

I vantaggi e gli svantaggi del blocco a livello di tabella

MySQL utilizza il blocco a livello di tabella per tutti i motori di archiviazione eccetto InnoDB, il che significa che il blocco a livello di tabella viene utilizzato per le tabelle che eseguono i motori di archiviazione MyISAM, MEMORY e MERGE, consentendo a una sola sessione di aggiornare le tabelle alla volta . I blocchi a livello di tabella presentano alcuni vantaggi distinti rispetto ai blocchi a livello di riga (ad esempio, il blocco a livello di tabella in generale richiede un po' meno memoria rispetto al blocco a livello di riga perché il blocco a livello di riga richiede un po' di memoria per riga (o gruppo) delle righe che sono bloccati e di solito è veloce perché è coinvolto un solo blocco I blocchi di scrittura della tabella vengono inseriti su una tabella se non ci sono blocchi su di essa - se ci sono blocchi preesistenti sulla tabella in questione, le richieste di blocco della tabella vengono inserite la coda delle richieste di lettura.Vale la pena ricordare che anche il blocco a livello di tabella presenta alcuni svantaggi distinti unici per se stesso - ad esempio, potrebbe non essere adatto per applicazioni che richiedono molte transazioni che vanno "avanti e indietro" (ad es. , un'applicazione di online banking) perché solo una sessione può scrivere su una tabella alla volta e alcune delle tabelle che supportano il blocco a livello di tabella (come MyISAM) non supportano il modello ACID.

Ecco un esempio:immagina un'applicazione bancaria che utilizza due tabelle in un database - diciamo che quelle tabelle sono chiamate "controllo" e "risparmio". Devi spostare $ 100 dal conto corrente di una persona al suo conto di risparmio. Logicamente, dovresti eseguire i seguenti passaggi:

  1. Assicurati che il saldo del conto sia maggiore di $ 100.

  2. Sottrai $ 100 dal conto corrente.

  3. Aggiungi $ 100 al conto di risparmio.

Per eseguire queste azioni, avresti bisogno di un paio di query, ad esempio:

SELECT balance FROM checking WHERE account_id = 123;
UPDATE checking SET balance = balance - 100 WHERE account_id = 123;
UPDATE savings SET balance = balance + 100 WHERE account_id = 123;

Queste query potrebbero sembrare semplici, ma se usi MyISAM (usiamo MyISAM come esempio poiché è uno dei principali motori di archiviazione che supporta i blocchi a livello di tabella), dovresti avere familiarità con il fatto che il motore non supporta nemmeno ACID, il che significa che se il server del database si arresta in modo anomalo durante l'esecuzione di una di queste query, sei sfortunato:le persone potrebbero finire con denaro contante in entrambi i conti o in nessuno dei due. L'unico motore che supporta le transazioni basate su ACID in MySQL è InnoDB, quindi se hai bisogno di molte transazioni affidabili, potrebbe valere la pena esaminarlo. InnoDB supporta anche il blocco a livello di riga:questo è ciò che esamineremo ora.

I vantaggi e gli svantaggi del blocco a livello di riga

MySQL utilizza il blocco a livello di riga per le tabelle InnoDB per supportare l'accesso simultaneo in scrittura da più sessioni. Alcuni dei vantaggi dell'utilizzo del blocco a livello di riga includono la possibilità di bloccare una singola riga per lunghi periodi di tempo e meno conflitti di blocco quando molti thread accedono a righe diverse. Tuttavia, il blocco a livello di riga presenta anche degli svantaggi:uno di questi è che il blocco a livello di riga di solito occupa più memoria rispetto al blocco a livello di pagina o di tabella, inoltre è solitamente più lento dei blocchi a livello di pagina o di tabella perché il motore deve acquisire più serrature. InnoDB è uno dei motori che supporta un meccanismo di blocco a livello di riga:è anche conforme ad ACID, il che significa che è adatto per applicazioni basate su transazioni (fare riferimento all'esempio sopra). Ora esamineremo come funziona la granularità dei blocchi in uno dei motori di archiviazione MySQL.

Come funziona Lock Granularity in InnoDB?

InnoDB è ampiamente noto per supportare il blocco a livello di riga, ma vale anche la pena notare che il motore supporta più tipi di blocco, il che significa che puoi utilizzare entrambi i blocchi a livello di riga e di tabella. InnoDB esegue il blocco a livello di riga impostando blocchi condivisi o esclusivi sui record di indice che incontra durante la ricerca o la scansione di un indice di tabella. Un blocco condiviso è un tale blocco che consente alla transazione che detiene il blocco di leggere la riga in questione, un blocco esclusivo d'altra parte consente alla transazione che detiene il blocco di aggiornare o eliminare una riga.

InnoDB ha anche altri tipi di lock:alcuni includono lock condivisi ed esclusivi, blocchi di intenzione, blocchi di record, blocchi di gap, blocchi del tasto successivo e blocchi dell'intenzione successiva. I blocchi intenzionali, ad esempio, possono anche essere condivisi o esclusivi - tali blocchi di solito indicano che una transazione intende impostare un certo tipo di blocco (un blocco condiviso o un blocco esclusivo) su singole righe in una tabella, un blocco di record è un bloccare un record di indice, ecc.

In generale, la granularità del blocco InnoDB differisce dalla granularità del blocco presente in altri motori di archiviazione MySQL (ad esempio, MyISAM) perché quando è in uso il blocco a livello di tabella, solo una sessione per aggiornare determinate tabelle in un il tempo può scorrere. Quando è in uso il blocco a livello di riga, MySQL supporta l'accesso simultaneo in scrittura su più sessioni, rendendo i motori di archiviazione con blocco a livello di riga (InnoDB) una scelta adatta per le applicazioni mission-critical.

Blocca granularità e deadlock

Il blocco della granularità e dei livelli di blocco in MySQL può essere un'ottima cosa, ma possono anche causare problemi. Uno dei problemi più frequenti causati dalla granularità del blocco sono i deadlock:un deadlock si verifica quando diverse transazioni MySQL non sono in grado di procedere perché ognuna di esse contiene un blocco di cui l'altra ha bisogno. Per fortuna, quando si utilizza il motore di archiviazione InnoDB, il rilevamento dei deadlock è abilitato per impostazione predefinita:quando viene rilevato un deadlock, InnoDB ripristina automaticamente una transazione. Se incontri deadlock quando hai a che fare con la granularità dei blocchi in MySQL, non preoccuparti:considera semplicemente di riavviare la transazione. Per monitorare in modo proattivo il tuo database, dovresti anche considerare l'utilizzo delle funzionalità fornite da ClusterControl.

In che modo ClusterControl può aiutarti?

Ecco alcune delle cose che ClusterControl sviluppato da Multiplenines può aiutarti:

  • La protezione di tutti i tuoi dati aziendali

    • Se i tuoi dati sono danneggiati (questo può essere causato dal mancato utilizzo di un motore di archiviazione compatibile con ACID o anche da altri fattori come descritto sopra) lo strumento può eseguire un processo automatico che verifica effettivamente che puoi recuperare i tuoi dati.

    • Lo strumento può farti sapere quali database non sono stati sottoposti a backup o mostrarti lo stato dei tuoi backup (se hanno avuto successo o hanno fallito)

  • L'automazione delle operazioni del tuo database

    • ClusterControl può aiutarti a garantire che amministratori di sistema, sviluppatori e DBA gestiscano interi cluster di database in modo efficiente con rischi minimi utilizzando l'industria migliori pratiche

  • Gestire efficacemente la tua infrastruttura di database in generale

    • L'odierno cambiamento tecnologico combinato con soluzioni infrastrutturali sofisticate richiede strumenti e conoscenze avanzati per ottenere un'elevata disponibilità e prestazioni ottimali per le tue applicazioni business-critical. ClusterControl può anche aiutarti con l'implementazione, il monitoraggio, la gestione e il ridimensionamento delle più popolari tecnologie di database open source tra cui MySQL, MariaDB, MongoDB, PostgreSQL, TimeScaleDB e il resto.

Per saperne di più su come ClusterControl può aiutarti a semplificare le operazioni aziendali, assicurati di tenere d'occhio il blog del database Diversinines.

Riepilogo

Diversi motori di archiviazione MySQL hanno diversi tipi di granularità di blocco disponibili. Prima di decidere il motore di archiviazione da utilizzare, assicurarsi di conoscere quante più informazioni possibili sullo storage engine in questione (ad esempio, come già notato MyISAM dovrebbe essere evitato quando si tratta di dati mission-critical perché non è conforme ad ACID), comprendere tutte le relative implicazioni sulle prestazioni, inclusi granularità di blocco, deadlock e il resto, e scegli con saggezza.