<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1267344923293614&amp;ev=PageView&amp;noscript=1">

Blog

MariaDB: quando l’High Availability fa la differenza nel business

Gianluca Parlangeli

Gianluca Parlangeli, 29 novembre 2019 | Big Data Management Big Data Tools , Big Data

Per decenni la parola database è stata associata ad un unica modalità di memorizzazione dei dati, ossia quella relazionale. Questa metodologia di gestione dell'informazione ha permesso di sviluppare complesse applicazioni garantendo in ogni circostanza affidabilità e robustezza.

Contattaci per una consulenza sulle tue esigenze di Big Data Monitoring!

ACID o non ACID: perdere il passato significa perdere il futuro

Tutte le aziende hanno nella propria realtà un parco applicativo basato su database relazionali. Nella maggior parte dei casi essi ricoprono un ruolo fondamentale per il corretto funzionamento delle attività quotidiane dell'impresa: quanto potrebbe costarci la perdita dei dati se ad esempio fossi un'azienda di moda? E come potremmo dormire sonni tranquilli se non fossimo sicuri della consistenza dei dati fiscali all'interno del nostro ERP?

Con l'aumentare dei Big Data in possesso diventa però sempre più critico riuscire a garantire alte performance pur mantenendo lo stesso livello di affidabilità.

Spesso bisogna scontrarsi con la necessità di memorizzare grandi volumi di dati per molto tempo. Per affrontare la crescita improvvisa dei dati viene subito naturale pensare ad una nuova tecnologia di tipo NoSql, ma questa rappresenta davvero la soluzione migliore?

Il caso MariaDB per la gestione dei Big Data

In uno dei nostri recenti casi di successo abbiamo dato supporto ad un nostro partner nella scelta tecnologica da utilizzare, proponendo valide alternative o confermando l’architettura presente basata su un’istanza di MariaDB.

Al fine di compiere la scelta giusta, il primo passo che abbiamo fatto è stato quello di analizzare in maniera approfondita le varie comunicazioni tra le applicazioni utilizzatrici della base dati e i vari processi coinvolti. Dopo aver raccolto le varie informazioni necessarie, ci siamo fatti guidare da queste per prendere la giusta scelta:

  • Presenza di un considerevole numero di applicazione WEB basate su PHP
  • Presenza di librerie specifiche per comunicazioni JDBC
  • Garantire la robustezza a basso livello (data storage) e non a livello applicativo

Date queste considerazioni, abbiamo deciso che NoSQL non era la tecnologia adatta nella nostra architettura.

I vantaggi di High Availability e scalabilità

Il primo passo per migliorare l’architettura di MariaDB consiste nell’effettuare l’upgrade alla nuova versione 10.3.11, presente nel repository ufficiale del sistema operativo CentOS 8.

I benefici introdotti nella nuova versione sono molteplici ed hanno aiutato i nostri tecnici a disegnare una nuova architettura per il cliente in alta affidabilità e scalabilità mantenendo invariato lo schema della base dati e limitando gli interventi sugli applicativi collegati:

  • Introduzione di Galera - (soluzione di clustering) è ora parte integrante di MariaDB
  • Introduzione di Spider
  • Parallel replication - le scritture sul master possono essere effettuate in parallelo attraverso una logica di multi thread su tutti i nodi slave selezionati
  • Nuovi storage engine - Spider, RocksDB, Mroonga, Cassandra, S3 ecc... (non tutti compatibili con Galera, vedere paragrafo successivo)
  • Possibilità di limitare il carico di lavoro per utente - è possibile limitare l’impatto degli utenti sul database limitando il tempo a disposizione delle query per l’esecuzione, il numero di connessioni massime in un dato periodo di tempo e molto altro
  • Funzionalità colonne virtuali - Aggiunta possibilità di indicizzare le colonne e virtuali e rimozione di alcune limitazioni presenti nella precedente versione (colonne virtuali non fisicamente presenti nello schema del DB
  • Introdotte le colonne invisibili - colonne che vengono mostrate solo se esplicitamente richiamate nella query e nascoste con i SELECT

Vediamo in dettaglio i primi due punti della lista. Galera è un software autonomo rispetto a MariaDB prodotto in collaborazione con Codership. Si occupa di unire insieme istanze di MariaDB in un cluster sincrono multi-master dove ogni nodo del cluster è una replica esatta del database principale. Al momento l’unico storage manager compatibile è InnoDB, ma in futuro è prevista la compatibilità con TokuDB.

Per la replica, il programma usa delle tecniche particolari:

  • Riordino delle transazioni: prima di eseguire il COMMIT agli altri nodi, l’ordine delle transazioni precedentemente eseguito viene riordinato. In questo modo è più difficile che avvengano errori durante la replica
  • Set di scrittura: le scritture avvengono in modalità batch per diminuire le operazioni di coordinamento fra i nodi
  • Comunicazione di gruppo: un’astrazione di alto livello per la comunicazione tra nodi garantisce la consistenza
  • Stati del database: le transazioni di sola lettura sono eseguite sul nodo locale. Le scritture invece sono eseguite localmente su copie shadow e poi riportate in blocco agli altri nodi per la certificazione e il commit

Per garantire la consistenza e ID simili fra nodi, Galera si avvale di GTID, che è simile alla funzione di replicazione di MariaDB 10.

Il partizionamento

Normalmente, partizionare un database è un buon modo per incrementare le performance dato che si ha una ricerca parallela su sottoinsiemi di una tabella più grande. Tuttavia, nativamente, in ogni versione di MariaDB vi sono alcuni problemi che limitano fortemente questa pratica:

  • Una tabella partizionata non può contenere, o essere referenziata da, chiavi esterne
  • L’esecuzione delle query non può essere fatta in parallelo (annullando così molti benefici di performance)

Viene in aiuto lo storage manager Spider, disponibile a partire da MariaDB 10.0.4, che si può frapporre fra una serie di istanze MariaDB, MySQL o OracleDB (non è necessario che siano tutte MariaDB).

Grazie a questo si può ottenere il partizionamento orizzontale (e, in futuro, anche verticale, separando per colonne invece che per righe), secondo numero di righe, hash o altro. L’idea è quella di avere un’istanza il cui unico compito è montare Spider e, dietro di essa, avere almeno 2 istanze di MariaDB. L’istanza con Spider conterrà la definizione del partizionamento scelto delle tabelle che risiedono fisicamente nei nodi backend.

Conclusioni

Sulla base dei requisiti inizialmente raccolti, la soluzione Spider in combinazione con Galera per la creazione di Cluster composti da istanze partizionate rappresenta la migliore scelta in termini di robustezza, affidabilità e performance per un’architettura basata su MariaDB:

  • Ottimo supporto al PHP
  • Buone performance in combinazione con applicazioni che sostengono un discreto carico di richieste, soprattutto se scritte in linguaggi che hanno librerie ottimizzate
  • Migliori performance rispetto a MySQL a parità di condizioni, soprattutto su database di dimensioni medio-grandi
  • Sviluppo interamente open source e molto attivo
  • Galera: indispensabile per la creazione di cluster in alta affidabilità
  • Spider: ottimo sistema introdotto per per il partizionamento di una tabella

Se vuoi approfondire l'argomento e consultarti con un team di esperti in soluzione per il monitoraggio dei Big Data, clicca qui sotto per prenotare una consulenza gratuita!

Red - Big Data Analytics - consulenza

Lascia un commento