La via FOREIGN KEY i vincoli sono implementati in MySQL (o, meglio, nel motore di archiviazione InnoDB) interferisce con le operazioni DDL online. Scopri di più in questo post del blog Vitess.

Limitato a un singolo ambito del server MySQL, FOREIGN KEY i vincoli sono impossibili da mantenere una volta che i dati crescono e vengono suddivisi su più server di database. Ciò si verifica in genere quando si introduce il partizionamento/sharding funzionale e/o lo sharding orizzontale.

Questo mi ha portato a pensare:fai FOREIGN KEY i vincoli influiscono sulla scalabilità in generale? e se sì, come?

Penso che sia importante rendersi conto che i join di tabelle SQL sono piuttosto costosi, ma per quanto ne so non è stato influenzato molto dall'integrità referenziale? Ora, se stiamo facendo qualcosa come l'analisi dei dati, ovviamente non abbiamo bisogno dell'integrità referenziale perché vorremmo semplicemente scaricare i nostri dati in un'unica tabella, ma PlanetScale e Vitess si vantano di essere utilizzati da grandi applicazioni web come YouTube.

Questo mi ha portato a essere confuso sul motivo per cui avrebbero abbandonato la FOREIGN KEY vincolo in quanto database come CockroachDB e Spanner mantengono ancora l'integrità referenziale oltre ad essere scalabili.

Che cos'è l'integrità referenziale e perché è importante?

Cominciamo con le basi, nel caso tu sia nuovo. Immagino che la maggior parte delle persone che leggono questo post abbiano una buona idea di cosa stanno parlando, ma lo spiegherò come formalità. In parole semplici, una FOREIGN KEY vincolo è una chiave di database che possiamo utilizzare per creare relazioni tra due tabelle diverse facendo riferimento a una colonna o a un insieme di colonne. L'integrità referenziale si riferisce semplicemente allo stato del database in cui sono validi tutti i valori di tutte le chiavi.

Perché è importante?

Ora che abbiamo un'idea di cosa sono, passiamo alla seconda parte:perché sono importanti?

L'integrità referenziale è importante in quanto impedisce di introdurre nuovi errori nel database. È una funzionalità spesso fornita dai database relazionali che impedisce agli utenti o alle applicazioni di inserire dati incoerenti nel database. Ciò porta a una migliore qualità dei dati, uno sviluppo più rapido, un numero molto inferiore di bug e una coerenza nell'applicazione.

Perché Vitess non ce l'ha?

Quindi, per capire perché Vitess non è in grado di supportare l'integrità referenziale, dobbiamo fare un tuffo nell'architettura del database. Vitess è un database SQL non ACID frammentato, non un vero database SQL ACID distribuito.

Ora, ti starai chiedendo quali siano questi termini. Lascia che te li spieghi:ACID è l'acronimo di Atomicity, Consistency, Isolation e Durability.

Qui, l'atomicità si riferisce a un'azione che completa o non riesce completamente, nessun completamento parziale di una transazione. La coerenza si riferisce alla transazione che lascia il database in uno stato valido. L'isolamento significa semplicemente che due transazioni vengono eseguite senza alcuna interferenza l'una con l'altra e la durata significa che le modifiche della transazione vengono salvate.

Uno shard è una partizione orizzontale di dati in un database e ogni shard viene conservato su un'istanza del server di database separata per distribuire il carico. Quindi, quando ci riferiamo a un database che è suddiviso in partizioni, stiamo parlando di qualcosa del genere. Ora, come ho detto prima, Vitess è un database SQL non ACID frammentato, il che sostanzialmente significa che NON garantisce le proprietà ACID delle transazioni.

Perché lasciarlo cadere?

Bene, il problema inizia quando hai un database MySQL con uno schema ben definito e il tuo servizio diventa popolare con il problema di troppe letture che colpiscono il database. Quello che la maggior parte delle persone fa qui è iniziare a memorizzare nella cache le query eseguite di frequente, ma le letture non sono più ACIDic.

Insieme a troppe letture, avere una quantità eccessiva di scritture sul database è un problema serio che molti potrebbero dover affrontare. Diciamo che siamo pronti a dare fuoco alle nostre tasche:possiamo scalare verticalmente, aggiungendo più RAM, un processore a 16 core e un sacco di unità a stato solido davvero veloci.

Ovviamente abbiamo ancora il problema dei join di tabelle SQL che aumentano in complessità, quindi inizi a denormalizzare per evitare i join tra tabelle.

Tempo fa ho tenuto una conferenza al Prisma Meetup, dove ho spiegato i fondamenti della progettazione di un database relazionale. Un argomento che ho trattato qui è stata la denormalizzazione, se sei interessato, assicurati di dare un'occhiata.

Ma la denormalizzazione è fondamentalmente il processo in cui si aggiungono dati ridondanti alle tabelle nel database, il che migliora le prestazioni sul costo dello spazio su disco poiché non si utilizza più la potenza della CPU per i join. Sebbene la denormalizzazione migliori la velocità di lettura, è importante rendersi conto che rende le scritture più lente.

Tuttavia, nonostante tutto ciò, il nostro database è ancora lento, quindi spostiamo i calcoli del database sul client, ad esempio generando un UUID o assegnando una data.

Anche dopo tutto questo, le query saranno ancora lente, quindi manteniamo pronto il risultato dei dati più richiesti in un processo noto come materializzazione del database. Ora le letture potrebbero essere più veloci, ma le scritture stanno diventando più lente di giorno in giorno. L'unica situazione logica ora è eliminare gli indici secondari.

Quindi, a questo punto, il nostro database ha

• Nessuna proprietà ACID a causa della memorizzazione nella cache
• Nessuno schema normalizzato
• Nessun trigger
• Nessun calcolo del database
• Nessun indice secondario

Ciò ha aperto la strada ai database Vitess e NoSQL, poiché le aziende avevano problemi con il ridimensionamento del proprio database. Il modo in cui è stato progettato, non sono stati in grado di mantenere la coerenza dei dati, una proprietà ACID, quando le transazioni si estendevano su diversi shard. L'integrità referenziale è tutta una questione di coerenza quando i dati si estendono su più shard, quindi ha senso che non siano in grado di supportarla bene.

Possiamo approfondire la struttura dei database NoSQL senza FOREIGN KEY vincolo e problemi che dovremo affrontare adottando quel modello, ma questo è l'argomento di un altro post.

Non è solo Vitess, è stata una pratica standard per i database partizionati evitare l'integrità referenziale poiché semplicemente non c'è altra scelta. In termini di modello ACID, la loro documentazione afferma che garantiscono l'atomicità ma non l'isolamento, e arrivano addirittura a dire: