# MariaDB

MariaDB è un RDBMS nato da un fork di MySQL creato dal programmatore originale di tale programma. Aperto ai contributi della comunità, l'area di sviluppo principale è lo storage engine Aria, precedentemente chiamato Maria da cui deriva MariaDB; si tratta di un'evoluzione di MyISAM. Viene dedicata attenzione anche ai plugin.

## Storia

MariaDB è nato nel 2009 come fork di MySQL. L'ideatore e responsabile del progetto è Michael "Monty" Widenius, il programmatore finlandese che ha iniziato e guidato per molti anni MySQL. Quando, all'inizio del 2008, la Sun Microsystems ha acquistato MySQL AB, Widenius si è trovato a disagio nella nuova situazione lavorativa, criticando la gestione dello sviluppo della versione 5.1 di MySQL.
Molti sviluppatori importanti avevano già lasciato il progetto MySQL per seguire Brian Aker nel suo fork Drizzle. In seguito all'annuncio dell'acquisizione della Sun da parte di Oracle, Widenius ha fondato il nuovo fork MariaDB e, per la sua gestione, ha avviato una nuova società chiamata Monty Program AB. Altri sviluppatori dipendenti della Sun lo hanno seguito.
Per attirare interesse attorno a MariaDB, oltre che per decentrare l'universo di MySQL rispetto alla Sun, Widenius ha lanciato la Open Database Alliance con Arjen Lentz, ex sviluppatore di MySQL che ha lasciato il progetto per fondare Open Query, e Peter Zaitsev, ex-core developer di MySQL che ha lasciato il progetto per fondare Percona.
La prima versione pubblicata, la 5.1.32, è dell'aprile 2009, disponibile solo per Linux. Pur rimanendo questa la sua piattaforma di riferimento, a partire dalla versione 5.1.38 dell'ottobre dello stesso anno è stata rilasciata anche per Windows. A partire dalla stessa versione è iniziata la distribuzione di pacchetti OurDelta, che già era disponibile per MySQL ma non più mantenuta.
Nel marzo 2013 gli sviluppatori della distribuzione Arch Linux hanno annunciato il passaggio da MySQL a MariaDB, seguendo le orme di Slackware.
Con la RHEL 7 del giugno 2014, anche Red Hat distribuisce nativamente MariaDB al posto di MySQL.
Nel dicembre 2012 è nata la MariaDB Foundation, allo scopo di garantire che MariaDB rimanga sempre un software libero, aperto al dialogo con la comunità e con una buona interoperabilità verso altri programmi.
Nel 2013 Monty Program Ab si è fusa con SkySQL, società di consulenza formata principalmente da ex-dipendenti di Oracle, Sun e MySQL Ab. La proprietà del marchio MariaDB è rimasta comunque alla MariaDB Foundation.

## Versioni

MariaDB, fino alla versione 5.5, ha seguito gli stessi numeri di versione di MySQL. In questo modo chi utilizza MariaDB 5.5 sa che vi troverà le funzionalità di MySQL 5.5.
Ne è stata seguita la numerazione anche quando MySQL ha saltato alcuni numeri: per esempio quando MySQL è passato dalla versione 5.0 alla 5.5, le versioni MariaDB 5.1, 5.2 e 5.3 contenevano funzionalità specifiche del fork, ma non tutte le funzionalità di MySQL 5.5.
Dopo la versione 5.5, MariaDB ha deciso di passare al ramo 10. La decisione è stata presa per evidenziare il fatto che MariaDB non intende, per il momento, importare tutte le funzionalità di MySQL 5.6, alcune delle quali sono giudicate instabili, né reimplementarle. Tuttavia, poiché molte nuove funzionalità sono state implementate, il cambiamento nel numero di versione è sembrato opportuno.

## Requisiti

MariaDB si compila sia su processori a 32 bit sia su processori a 64.
È sviluppato principalmente per sistemi GNU/Linux: esistono pacchetti ufficiali rpm (per Red Hat e derivate, openSUSE) e deb (per Debian, Ubuntu e derivate). MariaDB è anche inclusa nei repository di diverse distribuzioni.
Vi sono poi pacchetti ufficiali per Solaris e BSD.
Anche per Windows esistono dei binari ufficiali, sia installabili sia portabili.

## Differenze con MySQL

Le differenze più rilevanti tra MariaDB e MySQL indicate in una pagina apposita del sito ufficiale e nelle note di rilascio delle varie versioni pubbliche sono le seguenti:
* Sono stati inclusi i seguenti storage engine:
** Aria
** XtraDB
** PBXT
** FedaratedX
** SphinxSE
** mroonga
** OQGRAPH
** CassandraSE
** Lo storage engine NDB (ClusterDB) non è incluso in MariaDB.
* Plugin:
** HandlerSocket
** PAM
* Colonne virtuali.
* Colonne dinamiche.
* Sono stati implementati i pool di thread.
* Sono stati corretti alcuni bug e alcuni warning dei compilatori.
* Il codice di DBUG e l'istruzione CHECKSUM sono state rese più veloci, mentre alcune conversioni non necessarie dei set di caratteri sono state eliminate.
* Il parser elimina dal piano di esecuzione le tabelle nominate ma non effettivamente utilizzate.
* La precisione temporale di alcuni log è aumentata fino ai millisecondi.
* Migliorate le statistiche utente.
* MariaDB gestisce fino a trentadue segmenti di chiavi (non più sedici)
* Progress Reporting
* API non bloccante
* il client ha un'opzione: abort-source-on-error
* È stata estesa la tabella INFORMATION_SCHEMA.PLUGINS
* È possibile per gli sviluppatori degli storage engine estendere il comando CREATE TABLE con opzioni personalizzate
Grazie a HandlerSocket, CassandraSE, LevelDB e le colonne dinamiche, MariaDB può essere usato come DBMS NoSQL.

### Storage engine

MariaDB è distribuito con diversi storage engine, alcuni dei quali non possono funzionare con MySQL.

#### Aria

Il nome di questo storage engine inizialmente era Maria, ma successivamente è stato rinominato in Aria (togliendo solo l'iniziale) perché non si confondessero i nomi Maria e MariaDB.
Si tratta di un'evoluzione (ma non un vero e proprio fork) di MyISAM. Lo scopo del progetto è la realizzazione di uno storage engine performante quanto MyISAM ma che, opzionalmente, al prezzo di una lieve diminuzione delle prestazioni, possa gestire tabelle transazionali. Inoltre le tabelle di questo tipo sono virtualmente a prova di crash.
Aria viene utilizzata per le tabelle create internamente da MariaDB.
MyISAM è ancora presente in MariaDB.

#### XtraDB

Quando InnoDB è stata acquistata da Oracle il suo sviluppo è stato notevolmente rallentato. XtraDB è un fork di InnoDB sviluppato da Percona, allo scopo di correggere i bug esistenti e implementare nuove funzionalità. XtraDB è completamente compatibile con InnoDB e, man mano che Oracle rilascia nuove versioni, esse vengono integrate in XtraDB.
Per aumentare ulteriormente la compatibilità, XtraDB viene chiamato InnoDB. Tuttavia, MariaDB ha un'opzione di compilazione che consente di usare InnoDB.

#### PBXT

Questo storage engine è ancora distribuito con MariaDB, tuttavia è disabilitato per default perché non è più mantenuto.
Si tratta di uno storage engine sviluppato da PrimeBase. È transazionale e utilizza il multi-versioning dei record. Il locking avviene a livello di riga. È implementata una rilevazione dei deadlock automatica (immediata, secondo gli autori). Supporta le chiavi primarie. Secondo PrimeBase, si tratta di uno SE che si situa "da qualche parte tra MyISAM e InnoDB". In alcune casistiche particolari, i benchmark evidenziano prestazioni migliori rispetto ai concorrenti.

#### FederatedX

Federated è uno storage engine che funge da "collegamento" verso un'altra tabella, che generalmente si trova su un server SQL differente, quindi le comunicazioni avvengono attraverso una rete. Questo meccanismo è però trasparente per l'utilizzatore, che utilizza la tabella di tipo Federated, interrogandola e modificando i dati, come se fosse la tabella di destinazione. Le limitazioni principali di Federated sono l'impossibilità di modificarne la struttura (campi, indici...) e il mancato supporto alle prestazioni.
Lo storage engine Federated, incluso in MySQL, non è più mantenuto. Il suo autore, Patrick Galbraith, in arte captofu, ora mantiene FederatedX per correggere i bug e sviluppare nuove funzionalità. Ha già aggiunto il supporto alle transazioni. Prossimamente verrà aggiunto anche il supporto al protocollo ODBC, che permetterà il collegamento a DBMS differenti da MySQL. FederatedX è incluso in MariaDB e, in futuro, sarà incluso anche in Drizzle.

#### SphinxSE

SphinxSE è un DBMS specializzato nelle ricerche full text. Esso può essere usato in tre modi: come DBMS standalone, come DBMS embedded in un'altra applicazione o, appunto, come storage engine per MySQL o MariaDB. SphinxSE è appunto lo storage engine, ed è molto utile per superare i limiti del fulltext presente in MyISAM.

#### Mroonga

mroonga utilizza la libreria groonga, che a sua volta può essere utilizzata anche come server stand-alone. È specializzata nelle ricerche fulltext. Supporta diversi tipi di tokenizer, perciò è possibile sceglierne uno in base alle proprie esigenze; ma è anche possibile svilupparne uno nuovo, dal momento che l'architettura di groonga lo prevede. Un'altra funzionalità importante sono le query basate sulla geolocalizzazione, che permettono di trovare punti in uno spazio geografico, dando una priorità più elevata a quelli che si trovano più vicini al centro. groonga è distribuito con licenza GNU LGPL 2.1.

#### OQGRAPH

OQGRAPH sta per Open Query Graph ed è un plugin sviluppato da Open Query. Nonostante si presenti come storage engine, di fatto si tratta di una libreria, con interfaccia SQL, che simula i grafi. Le "tabelle" OQGRAPH devono avere tutte la stessa struttura; interrogandole seguendo regole specifiche, si otterranno dati relativi a un albero che si trova in un'altra tabella. Il suo utilizzo è piuttosto semplice, ma segue una logica molto diversa rispetto a quella relazionale, normalmente usata nei database.
OQGRAPH non è attivo per default e prima dell'uso deve essere abilitato (si può farlo anche a runtime).

#### CassandraSE

Lo storage engine CassandraSE è stato sviluppato da Monty Program per connettere un server MariaDB a tabelle create con Apache Cassandra.

#### CONNECT

Questo storage engine permette a MariaDB di connettersi a dati esterni, che possono essere di vario genere. Per ogni tipo di dato supportato, CONNECT fornisce un Table Type corrispondente. La maggior parte dei Table Types servono ad accedere a dati che si trovano nei file. Alcuni invece servono ad accedere a database remoti, tramite il protocollo di MySQL o lo standard ODBC. Questi dati possono essere letti, modificati, creati e indicizzati. CONNECT può sostituire gli storage engine CSV, Federated e FederatedX. Verrà introdotto in MariaDB 10.0.

#### SPIDER

Lo storage engine SPIDER consente di connettersi a una tabella MariaDB o MySQL in remoto. Può essere utilizzato per implementare lo sharding di un database.

#### Sequence

Sequence è uno storage engine introdotto in MariaDB 10.0. Non crea e non legge alcuna tabella fisica. Sequence genera e restituisce una sequenza di numeri naturali. Quando si interroga una tabella inesistente il cui nome segue un certo schema, Sequence interpreta questo nome per determinare i parametri della sequenza. Per esempio la tabella seq_1_to_20_step_2 indica una sequenza numerica che va da 1 a 20, procedendo di 2 numeri alla volta.

#### TokuDB

TokuDB è uno storage engine prodotto da TokuTek. La sua particolarità è che i dati e gli indici sono memorizzati come alberi frattali. Si tratta di una struttura dati i cui nodi sono dotati di buffer; questo permette di ritardare il momento della modifica dei nodi fino a quando i buffer sono pieni, per poter effettuare tali operazioni in massa, rendendole quindi più efficienti. Un'altra conseguenza è che si ha un livello di compressione molto elevato, generalmente superiore a quello di InnoDB. TokuDB è quindi particolarmente adatto a lavorare con grandi quantità di dati, soprattutto quando non si dispone di molta memoria. Supporta le transazioni SQL e XA.

#### Storage engine non presenti in MariaDB

NDB è stato rimosso da MariaDB. Dovrebbe essere possibile compilarlo in MariaDB, ma non è supportato in alcun modo.
Anche IBMDB2I è stato rimosso da MariaDB, ma non è più presente nemmeno in MySQL. Esso consentiva di connettere un server MySQL a tabelle create con IBM DB2.

### Plugin
#### HandlerSocket

Consente di connettersi a tabelle InnoDB senza utilizzare comandi SQL. Siccome il parser non interviene su tali operazioni, l'esecuzione risulta molto più veloce.

#### PAM

Un plugin che permette di gestire l'autenticazione di tipo PAM su sistemi Unix e Linux. A livello client, funziona anche su Windows. È possibile estenderlo per implementare autenticazioni interattive, ad esempio meccanismi in cui il server pone una domanda al client.
Anche MySQL 5.5 ha un plugin simile, ma non è Open Source ed è disponibile solo nell'edizione Enterprise (a pagamento).

#### Query Cache

A partire da MariaDB 10.0, la cache delle query è gestita da un plugin.

#### Sql_error_log

Questo plugin, introdotto nella versione 5.5, registra gli errori SQL in un file di log apposito.

### Altre funzionalità
#### Colonne Virtuali

Le colonne Virtuali sono campi il cui contenuto viene calcolato automaticamente per ogni singolo record, senza che l'utente debba specificarlo o possa modificarlo. Ogni espressione SQL costituisce un valore valido per le colonne virtuali. Esse possono essere di due tipi:
* STORED - La colonna esiste fisicamente e il valore viene calcolato, e inserito, al momento della creazione del record.
* VIRTUAL - La colonna non esiste fisicamente, è una struttura esclusivamente logica; il valore viene calcolato nel momento in cui viene richiesto da una query.
L'uso di colonne VIRTUAL potrebbe essere rimpiazzato da una vista. Tuttavia, se l'unico scopo della vista è aggiungere una o più colonne VIRTUAL, l'uso di queste ultime può risultare più comodo e logico.
L'uso delle colonne STORED potrebbe essere rimpiazzato da un trigger che si attiva dopo un'istruzione INSERT e uno che si attiva dopo un'istruzione UPDATE, che vanno a riempire una o più colonne fisiche. L'utilizzo delle colonne STORED è però più intuitivo. Inoltre, utilizzando le colonne virtuali, modificandone la definizione si modifica automaticamente tutti i valori precedentemente creati; questo, nella maggior parte dei casi, è il comportamento desiderato; qualora non lo fosse, occorre utilizzare i trigger.
MariaDB, come MySQL, non supporta l'uso di espressioni SQL come valore di default per le colonne normali. Questa mancanza viene quasi completamente compensata dalle colonne virtuali.

#### Pool di thread

MySQL gestisce ogni singola connessione ai client tramite un thread dedicato. Questo sistema è efficiente in alcuni casi, ma può essere un considerevole spreco di memoria in altre circostanze. In particolar modo, se i client lasciano trascorrere un lasso di tempo sensibile tra l'invio di un comando SQL e il successivo, la memoria rimarrà allocata inutilmente.
Per questo motivo MariaDB offre la possibilità di gestire tutte le connessioni tramite un unico pool di thread, distribuendo le risorse in un modo che spesso risulterà più ottimale. Solitamente viene riservata (almeno) un thread "extra" per la risoluzione dei problemi, il quale servirà un'unica connessione.
Anche in MariaDB, comunque, non solo rimane disponibile la modalità one thread per connection, ma per il momento rimane anche il comportamento predefinito.
La funzionalità pool-of-threads è stata implementata in MySQL 5.5 come plugin, ma non è open source ed è disponibile esclusivamente nell'edizione Enterprise (a pagamento).

#### Table Elimination

MariaDB supporta la Table Elimination, cioè è in grado di eliminare dalle query ricevute ogni riferimento a tabelle la cui lettura non aiuta a raggiungere i risultati desiderati. Questa funzionalità è molto importante per interrogare database che seguono il modello ad ancora (anchor model). In tali ambienti, infatti, si tende a interrogare viste che sono costituite da JOIN su molte tabelle contenenti pochi campi, anche se solitamente alcune di queste tabelle non contengono dati che ci interessano. Naturalmente questa pratica comporta un grande sovraccarico di lavoro per il DBMS, a meno che questo non supporti appunto la Table Elimination.

#### Plugin per l'autenticazione

In MariaDB, l'autenticazione degli utenti (il login) può essere gestita da plugin appositi. Questo permette, almeno in teoria, di scrivere plugin che autentichino gli utenti utilizzando servizi esterni, come l'autenticazione di UNIX, Kerberos, ecc. Naturalmente, rimane disponibile il vecchio sistema di login. Al momento, nessun plugin per l'autenticazione viene distribuito con MariaDB.

#### Statistiche Utente

Sono state aggiunte le seguenti tabelle al database virtuale INFORMATION_SCHEMA:
* USER_STATISTICS
* CLIENT_STATISTICS
* TABLE_STATISTICS
* INDEX_STATISTICS
Queste entità contengono informazioni molto dettagliate sulle azioni che sono state eseguite da singoli utenti o client, sulle azioni che sono state eseguite su singole tabelle e sull'utilizzo dei singoli indici. Sono stati introdotti anche i relativi comandi di tipo SHOW e FLUSH.
Questa funzionalità è stata inizialmente sviluppata da Percona.

#### Precisione in microsecondi

Il comando SHOW PROCESSLIST e funzioni come NOW, in MariaDB, producono un output con precisione in microsecondi (anziché in secondi).
Questa funzionalità è stata inizialmente sviluppata da Percona.

#### Segmentazione della cache degli indici

Questa funzionalità, in alcuni casi, può velocizzare enormemente l'utilizzo della cache degli indici delle tabelle MyISAM, evitando letture ripetute delle informazioni in memoria.

#### Progress Reporting

È possibile conoscere lo stato di avanzamento di alcuni comandi SQL la cui esecuzione può durare molto tempo. Questo si può controllare nel client da riga di comando, dalle API e dalla tabella information_schema.PROCESSLIST.

#### API non bloccante

Nell'API sono state inserite alcuni metodi detti non bloccanti. Essi fanno sì che il server esegua operazioni che potrebbero richiedere molto tempo, tuttavia consentono di interromperle - mettendole in pausa - per poter eseguire un compito più rapido, e infine riprendere l'esecuzione dell'operazione interrotta.

#### Statistiche estese sullo Slow Query Log

Lo Slow Query Log è stato migliorato in MariaDB. Esso registra maggiori informazioni e sono state introdotte alcune variabili di sistema che possono essere utilizzate per configurarne il comportamento.
Questa funzionalità è stata originariamente sviluppata da Percona.

#### Replica multi-master

MariaDB supporta la replica multi-master. Questo permette a un solo slave di replicare database provenienti da diversi master. Questo è utile soprattutto nel caso in cui gli slave debbano sopportare un carico di lavoro minore rispetto ai master, che devono invece eseguire diverse operazioni di modifica sui dati; dividendo i database su più master, si aumentano le risorse a essi dedicate.
Questa funzionalità è stata originariamente sviluppata dalla società cinese Taobao.

#### Replica multi-thread

MariaDB è in grado (a partire dalla versione 10.0) di utilizzare un pool di thread per la scrittura dei dati sugli slave. Questa tecnica elimina il principale collo di bottiglia presente nelle versioni più vecchie.

#### Delete... returning

La clausola RETURNING può essere utilizzata per leggere dati dalle righe che stanno per essere eliminate.

#### Show explain

Il comando EXPLAIN di MySQL e MariaDB mostra il piano di esecuzione che l'ottimizzatore elabora per eseguire una data query nel modo più efficiente che conosce. Tuttavia il piano di esecuzione che viene elaborato per rispondere al comando EXPLAIN, in qualche caso, può essere diverso da quello che verrebbe elaborato se la query venisse effettivamente eseguita. Sebbene tale discrepanza non si verifichi di frequente, rappresenta un problema piuttosto grave, perché i DBA sono costretti ad affidarsi a EXPLAIN nella delicata attività di ottimizzazione delle query e delle tabelle.
Il comando SHOW EXPLAIN risolve questo problema, perché non chiede all'ottimizzatore di elaborare un piano ad hoc, ma restituisce il piano effettivamente utilizzato da una query eseguita da un'altra connessione. Vi è quindi la certezza che questo piano corrisponde alla realtà. Ma anche SHOW EXPLAIN presenta alcuni limiti. Per esempio, siccome l'ottimizzatore elabora il piano un po' per volta durante l'esecuzione delle query, e siccome cancella appena possibile le parti del piano che sono già state eseguite, potrebbe non esserci un momento in cui l'ottimizzatore sia in grado di fornire a SHOW EXPLAIN l'intero piano; di conseguenza, l'utente in alcuni casi vedrà un piano reale ma incompleto.

## La libreria client

MySQL ha sempre venduto licenze proprietarie per il suo software, per consentire ai software proprietari di utilizzare la libreria client. Infatti la licenza GPL non consente di inglobare l'opera in un software non libero.
La MariaDB Foundation non può vendere licenze proprietarie, perché tecnicamente ha ricevuto molto codice da Oracle con licenza GPL. Per questo motivo ha scritto, con la collaborazione di SkySQL, nuove librerie client rilasciate con licenza LGPL. Questa licenza consente di utilizzare la libreria all'interno di un progetto non open source. Naturalmente non è necessario comprare alcuna licenza aggiuntiva.
Le librerie client sviluppate per MariaDB sono per i linguaggi C e Java. La libreria C è utilizzata da terze parti come base per librerie client in altri linguaggi.
Queste librerie supportano le funzionalità specifiche di MariaDB, come le chiamate non bloccanti e il progress reporting. Tuttavia sono anche compatibili con Oracle MySQL, pertanto possono essere utilizzate per consentire a un programma proprietario di connettersi a MySQL senza acquistare una licenza apposita.