MariaDB
| MariaDB | |
|---|---|
| Sviluppatore | Monty Program |
| Ultima versione | 5.2.2 (28 settembre 2010) |
| S.O. | Multipiattaforma |
| Genere | RDBMS |
| Licenza | GNU GPL versione 2 (Licenza libera) |
| Lingua | en |
| Sito web | http://askmonty.org/ |
MariaDB è un fork di MySQL creato dal programmatore originale di tale programma.
È estremamente aperto ai contributi della comunità. Gli sviluppatori sono particolarmente attenti alla qualità del codice. L'area di sviluppo principale è lo Storage Engine Aria (precedentemente chiamato Maria, da cui MariaDB); si tratta di un'evoluzione di MyISAM. Viene dedicata molta attenzione anche ai plugin.
Indice
|
[modifica] Storia
MariaDB è nato nel 2009 come fork di MySQL. L'ideatore e responsabile del progetto è Michael "Monty" Widenius, il programmatore svedese che ha iniziato (e guidato per molti anni) MySQL. Quando, all'inizio del 2008, la Sun Microsystems ha acquistato MySQL AB, Widenius si è subito trovato a disagio nella sua nuova situazione lavorativa. Ad esempio non ha risparmiato critiche [1] su come è stato gestito lo sviluppo del ramo 5.1 di MySQL, sulla sua prematura uscita in versione "stabile" e su alcune dichiarazioni di marketing.
Molti sviluppatori importanti avevano già lasciato il progetto MySQL per seguire Brian "Crow" 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 dalla Sun lo hanno seguito.
Sempre per attirare interesse attorno a MariaDB, oltre che per decentrare l'universo di MySQL rispetto alla Sun, Widenius ha lanciato[2][3] la Open Database Alliance insieme a Arjen Lentz (ex-core developer 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).
MariaDB è stato creato a partire da MySQL 5.1 e per questo è stato deciso che la prima versione di MariaDB sarebbe stata la 5.1. La prima release pubblica, la 5.1.32, è dell'aprile 2009 ed era disponibile solo per Linux. Pur rimanendo questa la sua piattaforma di riferimento, a partire dalla versione 5.1.38 (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.
[modifica] 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 CentOS/Red Hat) e deb (per Ubuntu e Debian). MariaDB è anche inclusa nei repository di diverse distribuzioni.
Vi sono poi pacchetti ufficiali per Solaris.
Anche per Windows esistono dei binari ufficiali, sia installabili sia noinstall.
[modifica] Differenze con MySQL
Le differenze più rilevanti tra MariaDB e MySQL indicate in una pagina apposita [4] 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
- OQGRAPH
- IBMDB2I
- Lo Storage Engine NDB (ClusterDB)non è incluso in MariaDB.
- 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 32 segmenti di chiavi (non più 16)
- Progress Reporting
- il client ha un'opzione—abort-source-on-error
- È stata estesa la tabella INFORMATION_SCHEMA.PLUGINS
- È stata migliorata la gestione delle opzioni di tabella per gli storage engine
[modifica] Storage Engine
[modifica] 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 SE performante quanto MyISAM ma che, opzionalmente, al prezzo di una lieve diminuzione delle prestazioni, può 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.
[modifica] 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.
Il tool XtraDB Monitor non funziona ancora in MariaDB.
[modifica] PBXT
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.
[modifica] FedaratedX
Federated è uno SE 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 SE 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.
[modifica] SphinxSE
Spinx è un DBMS specializzato nelle ricerche fulltext. 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.
[modifica] 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.
[modifica] IBMDB2I
Questo Search Engine è stato sviluppato per consentire l'interoperabilità tra un server MySQL e le tabelle di IBM DB2. Oracle Corporation ha rimosso IBMDB2I dal codice sorgente, ma il plugin è stato comunque conservato in MariaDB.
[modifica] SE non presenti in MariaDB
L'unico Search Engine presente in MySQL che è stato rimosso da MariaDB è NDB. Dovrebbe essere possibile compilarlo in MariaDB, ma non è supportato il alcun modo.
[modifica] Colonne Virtuali
Le colonne virtuali sono colonne 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.
[modifica] Pool of Threads
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.
[modifica] 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 medel). In tali ambienti, infatti, si tende ad 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.
[modifica] 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.
[modifica] Statistiche Utente
Sono state aggiunte le seguenti tabelle al database vistuale 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.
[modifica] Precisione in microsecondi nella Processlist
Il comando SHOW PROCESSLIST, in MariaDB, produce un output con precisione in microsecondi (anziché in secondi).
Questa funzionalità è stata inizialmente sviluppata da Percona.
[modifica] 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.
[modifica] Progress Reporting
E' 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.
[modifica] 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.
[modifica] Note
- ^ (EN) Oops, we did it again
- ^ (EN) Welcome to the ODBA
- ^ (EN) Open Database Alliance founded
- ^ (EN)MariaDB Versus MySQL
[modifica] Voci correlate
[modifica] Altri progetti
[modifica] Collegamenti esterni
- Knowledge Base in italiano
- (EN) Blog ufficiale
- (EN) Download
- (EN) Knowledge Base
- (EN) Worklog
- (EN) Wiki degli sviluppatori
- (EN) AskMonty.org
- (EN) Monty Program
- (EN) Planet MariaDB
- (EN) Blog di Widenius
- Articolo: Monty lascia MySQL, nasce MariaDB
- Articolo: MariaDB il fork dal creatore di MySQL
|
|