Questo articolo è apparso per la prima volta in InfoWorld . È ristampato con il permesso. © IDG Communications, Inc., 2020. Tutti i diritti riservati Come MariaDB raggiunge una scala globale con Xpand. Xpand è ora disponibile in MariaDB SkySQL aggiungendo SQL distribuito per scalabilità ed elasticità nel cloud.
Con l'aumento delle esigenze di informazioni ed elaborazione, punti deboli come prestazioni e resilienza hanno reso necessarie nuove soluzioni. I database devono mantenere la conformità e la coerenza ACID, fornire disponibilità elevata e prestazioni elevate e gestire enormi carichi di lavoro senza consumare risorse. Lo sharding ha offerto una soluzione, ma per molte aziende lo sharding ha raggiunto i suoi limiti, a causa della sua complessità e dei requisiti di risorse. Una soluzione migliore è SQL distribuito.
In un'implementazione SQL distribuita, il database è distribuito su più sistemi fisici, fornendo transazioni a un livello scalabile a livello globale. MariaDB Platform X5, un'importante release che include aggiornamenti per ogni aspetto della piattaforma MariaDB, fornisce SQL distribuito e un'enorme scalabilità attraverso l'aggiunta di un nuovo motore di archiviazione intelligente chiamato Xpand. Con un'architettura nulla condivisa, transazioni ACID completamente distribuite e una forte coerenza, Xpand ti consente di scalare a milioni di transazioni al secondo.
Motori intelligenti collegabili ottimizzati
MariaDB Enterprise Server è progettato per utilizzare motori di archiviazione collegabili (come Xpand) per ottimizzare carichi di lavoro particolari da un'unica piattaforma. Non sono necessari database specializzati per gestire carichi di lavoro specifici. MariaDB Xpand, il nostro motore intelligente per SQL distribuito, è l'aggiunta più recente alla nostra gamma. Xpand aggiunge capacità transazionali distribuite estremamente scalabili alle opzioni fornite dai nostri altri motori. I nostri altri motori collegabili forniscono ottimizzazione per carichi di lavoro analitici (colonnari), pesanti in lettura e carichi di lavoro pesanti in scrittura. Puoi combinare e abbinare tabelle replicate, distribuite e a colonne per ottimizzare ogni database in base ai tuoi requisiti specifici.
L'aggiunta di MariaDB Xpand consente ai clienti aziendali di ottenere tutti i vantaggi dell'SQL distribuito (velocità, disponibilità e scalabilità), pur mantenendo i vantaggi di MariaDB a cui sono abituati.
Diamo uno sguardo ad alto livello su come MariaDB Xpand fornisce SQL distribuito.
SQL distribuito fino agli indici
Xpand fornisce SQL distribuito tagliando, replicando e distribuendo i dati tra i nodi. Cosa significa questo? Useremo un esempio molto semplice con una tabella e tre nodi per dimostrare i concetti. In questo esempio non viene mostrato che tutte le sezioni vengono replicate.
Nella Figura 1 sopra, abbiamo una tabella con due indici. La tabella ha alcune date e abbiamo un indice sulla colonna due e un altro sulle colonne tre e uno. Gli indici sono in un certo senso le tabelle stesse. Sono sottoinsiemi della tabella. La chiave primaria è id , il primo indice nella tabella. Questo è ciò che verrà utilizzato per eseguire l'hashing e distribuire i dati della tabella nel database.
Ora aggiungiamo la nozione di slice . Le fette sono essenzialmente partizioni orizzontali della tabella. Abbiamo cinque righe nella nostra tabella. Nella Figura 2, la tabella è stata tagliata e distribuita. Il nodo n. 1 ha due righe. Il nodo n. 2 ha due righe e il nodo n. 3 ha una riga. L'obiettivo è distribuire i dati nel modo più uniforme possibile tra i nodi.
Gli indici sono stati anche affettati e distribuiti. Questa è una differenza fondamentale tra Xpand e altre soluzioni distribuite. In genere, i database distribuiti hanno indici locali, quindi ogni nodo ha un indice dei propri dati. In Xpand, gli indici sono distribuiti e archiviati indipendentemente dalla tabella. Ciò elimina la necessità di inviare una query a tutti i nodi (scatter/gather). Nell'esempio precedente, il nodo n. 1 contiene le righe 2 e 4 della tabella e contiene anche gli indici per le righe 32 e 35 e le righe aprile e marzo. La tabella e gli indici vengono suddivisi, distribuiti e replicati in modo indipendente tra i nodi.
Il motore di query utilizza gli indici distribuiti per determinare dove trovare i dati. Cerca solo le partizioni di indice necessarie e quindi invia le query solo alle posizioni in cui risiedono i dati necessari. Le query sono tutte distribuite. Vengono eseguiti contemporaneamente e in parallelo. Dove vanno dipende interamente dai dati e da ciò che è necessario per risolvere la query.
Tutte le fette vengono replicate almeno due volte. Per ogni slice, ci sono repliche che risiedono su altri nodi. Per impostazione predefinita, ci saranno tre copie di quei dati:la sezione e due repliche. Ogni copia si troverà su un nodo diverso e, se eri in esecuzione in più zone di disponibilità, tali copie si troverebbero anche in zone di disponibilità diverse.
Gestione di lettura e scrittura
Facciamo un altro esempio. Nella Figura 3, abbiamo cinque istanze di MariaDB Enterprise Server con Xpand (nodi). C'è una tabella per memorizzare i profili dei clienti. La fetta con il profilo di Shane è sul Nodo #1 con le copie sul Nodo #3 e sul Nodo #5. Le query possono arrivare su qualsiasi nodo e verranno elaborate in modo diverso a seconda che si tratti di letture o scritture.
Le scritture vengono eseguite su tutte le copie in modo sincrono all'interno di una transazione distribuita. Ogni volta che aggiorno il mio profilo "Shane" perché ho cambiato la mia email o ho cambiato il mio indirizzo, quelle scritture vanno a tutte le copie contemporaneamente all'interno di una transazione. Questo è ciò che fornisce una forte coerenza.
Nella figura 3, l'istruzione UPDATE è andata al nodo n. 2. Non c'è nulla sul nodo n. 2 per quanto riguarda il mio profilo, ma il nodo n. 2 sa dove si trova il mio profilo e invia aggiornamenti al nodo n. 1, al nodo n. 3 e al nodo n. 5, quindi esegue il commit della transazione e torna all'applicazione.
Le letture vengono gestite in modo diverso. Nel diagramma, la sezione con il mio profilo si trova sul Nodo n. 1 con le copie sul Nodo n. 3 e sul Nodo n. 5. Questo rende il Nodo #1 la replica del ranking. Ogni sezione ha una replica di classificazione, che si potrebbe dire sia il nodo che "proprietario" i dati. Per impostazione predefinita, indipendentemente dal nodo in cui entra una lettura, va sempre alla replica del ranking, quindi ogni SELECT che si risolve andrà al Nodo n. 1.
Fornire elasticità
I database distribuiti come Xpand cambiano e si evolvono continuamente a seconda dei dati nell'applicazione. Il processo di ribilanciamento è responsabile dell'adattamento della distribuzione dei dati alle esigenze attuali e del mantenimento della distribuzione ottimale delle sezioni tra i nodi. Esistono tre scenari generali che richiedono la ridistribuzione:aggiunta di nodi, rimozione di nodi e prevenzione di carichi di lavoro irregolari o "punti critici".
Ad esempio, supponiamo che stiamo funzionando con tre nodi ma scopriamo che il traffico è in aumento e dobbiamo ridimensionare:aggiungiamo un quarto nodo per gestire il traffico. Il nodo n. 4 è vuoto quando lo aggiungiamo come mostrato nella Figura 4. Il ribilanciatore sposta automaticamente le sezioni e le repliche per utilizzare il nodo n. 4, come mostrato nella Figura 5.
Se il Nodo #4 dovesse fallire, il ribilanciatore torna automaticamente a funzionare; questa volta ricreando fette dalle loro repliche. Nessun dato viene perso. Le repliche vengono anche ricreate per sostituire quelle che risiedevano sul nodo n. 4, quindi tutte le sezioni hanno nuovamente repliche su altri nodi per garantire un'elevata disponibilità.
Figura 6. Se un nodo si guasta, il ribilanciatore Xpand ricrea le sezioni e le repliche che risiedevano sul nodo guasto dai dati di replica sugli altri nodi.
Bilanciamento del carico di lavoro
Oltre alla scalabilità orizzontale e all'elevata disponibilità, il ribilanciatore attenua la distribuzione ineguale del carico di lavoro, sia che si tratti di punti caldi o di sottoutilizzo. Anche quando i dati vengono distribuiti casualmente con un algoritmo hash perfetto, possono verificarsi punti caldi. Ad esempio, potrebbe capitare per caso che i 10 prodotti in vendita questo mese si trovino sul Nodo #1. I dati sono distribuiti uniformemente ma il carico di lavoro no (Figura 7). In questo tipo di scenario, il ribilanciatore ridistribuirà le sezioni per bilanciare l'utilizzo delle risorse (Figura 8).
Figura 7. Xpand ha distribuito i dati in modo uniforme ma il carico di lavoro non è uniforme. Il nodo 1 ha un carico di lavoro significativamente maggiore rispetto agli altri tre nodi.
Figura 8. Xpand rebalancer ridistribuisce le sezioni di dati per bilanciare il carico di lavoro tra i nodi.
Scalabilità, velocità, disponibilità, equilibrio
Le esigenze di informazione ed elaborazione continueranno a crescere. Questo è un dato di fatto. MariaDB Xpand fornisce una soluzione di dimensionamento coerente e conforme ad ACID per le aziende con requisiti che non possono essere soddisfatti con altre alternative come la replica e lo sharding.
L'SQL distribuito offre scalabilità e MariaDB Xpand offre la flessibilità di scegliere la scalabilità necessaria. Distribuisci una tabella o più tabelle o anche l'intero database, a te la scelta. Operativamente, la capacità può essere facilmente regolata per soddisfare le mutevoli esigenze del carico di lavoro in qualsiasi momento. Non devi mai essere sovradimensionato.
Xpand protegge inoltre in modo trasparente dall'utilizzo non uniforme delle risorse, ridistribuendo dinamicamente i dati per bilanciare il carico di lavoro tra i nodi e prevenire i punti critici. Per gli sviluppatori, non è necessario preoccuparsi della scalabilità e delle prestazioni. Xpand è elastico. Xpand fornisce anche ridondanza e disponibilità elevata. Con i dati suddivisi, replicati e distribuiti tra i nodi, i dati sono protetti e la ridondanza viene mantenuta in caso di guasto hardware.
E, con l'architettura di MariaDB, le tue tabelle distribuite funzioneranno bene, comprese le JOIN cross-engine, con le altre tue tabelle MariaDB. Crea la soluzione di database di cui hai bisogno combinando e abbinando tabelle replicate, distribuite o a colonne su un unico database sulla piattaforma MariaDB.
