La lunga e affascinante storia delle banche dati elettroniche, che oggi costituiscono il cuore pulsante di ogni applicazione informatica, è costellata di grandi successi, clamorose disfatte, gruppi di lavoro affiatati e geniali ma anche di incomprensioni, litigi e scissioni che, di fatto, hanno contribuito a creare interesse intorno a un universo estremamente tecnico se non proprio “asettico”. Uno dei casi più clamorosi ed inizialmente drammatici è rappresentato dall’acquisizione del più famoso DMBS open source, MySQL, da parte di un colosso dei database come Oracle che ha portato, tra l’altro, alla nascita di una “fork” destinata a salire agli onori delle cronache con il nome di “MariaDB”.
Breve storia di MariaDB
Per comprendere al meglio le caratteristiche e i principi basilari di questo DBMS è, pertanto, imprescindibile partire dal 2009, ossia dal momento in cui il mondo dei software aperti incrociava la propria rotta con quella di una multinazionale che, fino a quel momento, aveva costruito le proprie fortune su prodotti a pagamento fortemente orientati al mercato.
Dopo un fisiologico momento di disorientamento, dovuto all’incredibile novità che in pochi avrebbero mai pronosticato alla vigilia, nella sterminata community di sviluppatori, utilizzatori e addetti ai lavori il sentimento più diffuso era certamente rappresentato dal timore per la fine imminente di una piattaforma software che aveva segnato un’epoca, scalando in brevissimo tempo le speciali classifiche di popolarità e utilizzo in tutto il mondo.
Seguirono una serie di fuoriuscite eccellenti e scissioni che portarono alla nascita di diversi “spin-off” finalizzati a proseguire, in maniera indipendente, il percorso originario secondo i canoni del codice aperto e libero.
In questo clima di generale incertezza, è addirittura il padre fondatore di MySQL, Michael “Monty” Widenius, a guidare un gruppo di “ribelli” verso la creazione di un ulteriore progetto alternativo ma soprattutto a fermare la “diaspora” lanciando la Open Database Alliance con l’obiettivo di “unificare tutti gli sviluppi e i servizi relativi a MySQL, fornendo una soluzione alla frammentazione e all’incertezza con cui si devono misurare le community, le aziende e i tecnici esperti che lavorano con MySQL”.
MySQL e MariaDB: una storia di famiglia
Per comprendere al meglio lo stretto legame che intercorre tra MySQL e MariaDB ma anche tra Widenius e le sue creature è necessario partire dai nomi assegnati da “Monty” ai due DBMS: My e Maria, infatti, sono rispettivamente la prima e l’ultima figlia dell’informatico finlandese, che da un lato ha sempre considerato le proprie invenzioni come un’estensione della famiglia naturale e dall’altro ha voluto consacrare MariaDB quale erede ufficiale di una dinastia in grado di conquistare il mondo delle banche dati.
L’obiettivo primario di MariaDB, in sintesi, era quello di garantire un vero e proprio clone “opensource” di MySQL, proseguendone lo sviluppo aperto, tanto da permettere una “sostituzione binaria completa” e consentire a tutti gli utenti di scambiare i due DBMS in maniera del tutto naturale sui propri sistemi.
Particolarmente interessante, sotto questo profilo, è la scelta di conservare i nomi originari dei servizi che compongono MySQL così da facilitare la migrazione e “mascherare” al sistema operativo l’utilizzo di un database al posto di un altro: oltre al modulo server “mysqld” e al client “mysql” anche i componenti non direttamente connessi alla gestione del DBMS, come ad esempio “mysqldump”, continuano a chiamarsi nel medesimo modo.
MariaDB può, pertanto, essere importato immediatamente senza alcuna difficoltà in tutti i software e divenire la banca dati di riferimento dei CMS che supportano MySQL ma anche di applicazioni estremamente utilizzate e famose come phpMyAdmin.
In base a quanto è possibile leggere sul sito web ufficiale di MariaDB, esiste una piena compatibilità per i file di definizione dei dati e delle tabelle, per tutte le API, per i protocolli di comunicazione, per i “connettori” verso i principali linguaggi di programmazione (PHP, Perl, Python, Java, C#, etc) e addirittura per il modulo client MySQL che funziona in modo intercambiabile con MariaDB.
MariaDB e la licenza open source
La prima grande differenza, che caratterizza in maniera netta MariaDb rispetto a MySQL, è rappresentata dal modello di licenza proposto: mentre il prodotto acquistato da Oracle ha lanciato l’ormai celebre sistema del doppio binario, che prevede la compresenza di una versione commerciale e una “aperta”, lo spin-off rimane saldamente nel solco tracciato dalle cosiddette licenze “GPL” (General Public License), come ampiamente spiegato nella sezione dedicata del portale nella quale sono disponibili le FAQ, una copia della licenza GNU adottata e una lista di tutte le eccezioni connesse soprattutto a singoli moduli rilasciati con termini e vincoli differenti.
Da tale previsione, invero, derivano anche una serie di implicazioni decisamente importanti, che contribuiscono a rimarcare il complicato rapporto di “familiarità” ma anche “diffidenza” da sempre intercorrente tra MySQL e MariaDB.
La prima, e probabilmente la più importante, è costituita dall’impossibilità per Oracle di riutilizzare direttamente nel proprio prodotto le innovazioni introdotte dal progetto figlio a causa della presenza di soluzioni proprietarie all’interno del proprio DBMS. Si tratta, invero, di un modo per tutelare e salvaguardare, seppur indirettamente, il lavoro e l’operato della community che da anni supporta e contribuisce al sempre crescente successo di MariaDB.
Ribaltando completamente la prospettiva, invece, in un’intervista rilasciata al portale Linux.com, Widenius ha promesso che “quando Oracle rilascerà un’estensione chiusa per MySQL, anche noi ne rilasceremo una open source”.
La novità della “Business Source License”
Puntando a divenire un framework in grado di gestire i dati e le informazioni in maniera integrata e completa, MariaDB ha dovuto fin da subito affrontare il problema dell’utilizzo di moduli software altamente specialistici che possono richiedere, per la progettazione, lo sviluppo e la messa a punto, investimenti importanti oltre al coinvolgimento di terze parti.
In tale contesto, confermare la tipologia di licenza GPL anche per le componenti “ortogonali” del DBMS avrebbe certamente costituito un deterrente per molte software house che, a fronte di un impegno finanziario non indifferente, avrebbero dovuto rinunciare completamente a ogni tipologia di entrata o “fee”.
Per risolvere tale problema, Michael Widenius e David Axmark, compagni d’avventure fin dai tempi di MySQL, hanno definito la cosiddetta “Business Source License” (conosciuta anche con l’acronimo BSL) con l’obiettivo di individuare un punto di equilibrio tra i vantaggi per l’utente del software Open Source “puro” e le esigenze di sostenibilità degli sviluppatori.
La BSL, invero, è strutturata in maniera tale da consentire un utilizzo libero e aperto per la maggior parte dei casi d’uso di un software e richiede, per un periodo limitato di tempo, l’acquisto di una licenza commerciale per coloro che intendono utilizzare il software al di sopra di una determinata soglia (ad esempio per l’utilizzo su server che hanno un determinato numero di processori o core).
Una volta trascorso l’intervallo di tempo prestabilito, fissato generalmente intorno ai 3 anni, la BLS si trasforma automaticamente nella versione GPL equivalente, assumendo, a tutti gli effetti, le caratteristiche delle licenze open-source.
In tal modo è possibile, continuare a preservare e tutelare gli aspetti di “libertà critica” del software aperto, così come stabilita dall’Iniziativa “Open Source” nella propria definizione ufficiale disponibile al seguente indirizzo), garantendo, al contempo, un modello di business praticabile per i professionisti del software.
La community, punto di forza di MariaDB
Come anticipato in precedenza, uno dei punti cardine di MariaDB è costituito dalla volontà di creare una comunità aperta, trasparente, attiva e sempre pronta a lavorare per migliorare un DBMS che, nel tempo, sta assumendo connotazioni proprie e peculiari.
Se, infatti, anche il prodotto di Oracle è supportato da una “community”, è sufficiente analizzare il registro delle attività per comprendere come la maggior parte dei contributi arrivi da sviluppatori interni e che il ruolo degli outsider sia effettivamente marginale.
Un ulteriore elemento di confronto è fornito dal numero dei “branch”, ossia delle diramazioni aperte da singoli sviluppatori, che in MySQL è fermo, al momento della redazione del presente articolo, a quota 9 (a fronte di circa 178mila commit e una settantina di contributori) mentre è pari addirittura a 707 in MariaDB (con circa 190mila commit e 200 contributori).
Da non sottovalutare, inoltre, soprattutto per il messaggio altamente democratico lanciato verso il mondo esterno, sono gli strumenti adottati per favorire le interlocuzioni tra gli sviluppatori come le mailing list “Maria developers”, “Maria-captains” e “Maria Discuss” sul portale “launchpad.net”.
Particolarmente interessante è la figura dei “capitani”, che rappresentano sviluppatori altamente fidati che possono accedere con privilegi di scrittura alle principali alberature del progetto. Si tratta di una previsione importante e rappresentativa di un gruppo eterogeneo e fortemente organizzato, nel quale ognuno può fornire il proprio contributo ma dove tutti riconoscono il valore della “gerarchia”, dell’esperienza e dei processi di revisione finalizzati a rendere il codice quanto più possibile corretto, funzionale ed efficiente.
MariaDB alla rincorsa di MySQL
Se ancora oggi MySQL è di gran lunga il primo database opensource al mondo per popolarità e utilizzo, è pur vero che MariaDB sta vivendo negli ultimi anni un periodo di splendore, grazie soprattutto a una crescente affidabilità, alla capacità di attrarre partner e sponsor di altissimo livello ma anche e soprattutto per la sua fedeltà ai principi fondanti del software open-source dai quali era partito anche il suo celebre progenitore.
È necessario innanzitutto precisare come, nelle primissime fasi dopo la nascita dello spin-off, MySQL abbia goduto anche dell’estrema diffusione di un “marchio” che si era già imposto nel tempo e che continuava ad essere associato, nella percezione degli addetti ai lavori, al progetto originale lanciato da Widenius mentre MariaDb si presentava come uno dei tanti “branch” e doveva, pertanto, conquistare la fiducia degli sviluppatori e delle grandi aziende di software.
Per comprendere meglio le straordinarie cifre di un fenomeno ancora in ascesa è sufficiente analizzare i risultati forniti da Google Search Trend che vedono MariaDB in costante crescita fin dalla sua nascita, ma soprattutto testimoniano una graduale e apparentemente inarrestabile “rimonta” rispetto a MySQL (basti pensare che il rapporto è passato da uno stratosferico “50 a 1” del 2009 a un lusinghiero “8 ad 1” alla fine del 2019.
A testimoniare il continuo successo di MariaDB sono arrivate negli anni anche illustri adesioni come quella di “MediaWiki Foundation”, Google, Booking.com e Automattic, la big company che sviluppa “Word Press” e che aveva contribuito in maniera decisiva alla crescita di MySQL alla fine della prima decade del terzo millennio.
Accanto al gradimento tributato da colossi dell’economia mondiale, un risultato per certi versi ancora più prestigioso, in relazione ai principi fondanti del DBMS, è rappresentato dalla decisione degli sviluppatori di alcune tra le principali e rappresentative distribuzioni “Linux”, quali Red Hate, Suse, CentOS, Arch Linux, Debian, Slackware, Fedora, di inglobare nei propri pacchetti il codice di MariaDB.
Si tratta di una vera e propria consacrazione ma anche, in qualche modo, di un passaggio di consegne che segna un deciso punto a favore dello spin-off nell’agguerrita lotta per divenire l’icona o il prodotto simbolo nell’ampio e redditizio mondo dei database open-source.
MariaDB, un database pienamente alternativo e innovativo
Pur essendo nato per garantire la sopravvivenza del progetto originario, tanto da essere stato presentato fin dalle sue origini come un clone completamente opensource di MySQL, nel corso del tempo MariaDB si è evoluto fino a divenire un DMBS pienamente alternativo e innovativo, che punta a superare i limiti e le criticità connesse alle piattaforme attualmente in uso per la gestione delle banche date relazionali.
Con l’intenzione di rimarcare le importanti evoluzioni rispetto al progetto iniziale e fornire al DBMS una propria identità ben definita, gli sviluppatori di MariaDB hanno modificato anche il processo di “versioning”: se, infatti, fino alla versione 5.5 il fork aveva seguito pedissequamente la numerazione proposta da MySQL (arrivando anche a emulare i “buchi” lasciati in alcuni casi dal progetto originario), a partire da novembre 2012 è stato effettuato un vero e proprio salto con il rilascio della versione 10.0, che ha segnato, di fatto, l’inizio di una nuova era per la creatura di Widenius.
Allo stato attuale, invero, sono tante e importanti le differenze che oggi intercorrono tra il branch e il famoso genitore, come orogogliosamente riportato in una sezione del sito ufficiale ma anche in un interessante “libro bianco” denominato “MariaDB vs. Oracle MySQL vs. EnterpriseDB”, nel quale i tre DBMS sono confrontati tra loro sotto molteplici aspetti.
Il primo punto che caratterizza in maniera eclatante il grande lavoro di sviluppo effettuato dal team di MariaDB è sicuramente rappresentato dal numero di “database engine” utilizzati per gestire le proprie tabelle: se, infatti, MySQL si ferma a quota 9, lo spin-off arriva addirittura a quota 19, includendo versioni NoSQL, basate sull’XML e in grado di garantire elevate performance a fronte di banche dati anche decisamente moderne e “schema-less”.
Un caso particolare è costituito da Aria, che rappresenta una evoluzione “a prova di crash” di MyISAM, il famoso motore di MySQL. Sviluppato originariamente da Widenius in persona, questo engine era stato presentato nel 2010 come “Maria”, in onore, ancora una volta della secondogenita di “Monty” ma, dopo il successo del quasi omonimo DMBS, la community propose di ribattezzarlo con il fine di non generare confusione tra gli addetti ai lavori.
Un ulteriore motore degno di nota utilizzato da MariaDB è “Percona XtraDB” che, invero, rappresenta una versione migliorata e rivisitata di “InnoDB”, ossia il db-engine di nuova generazione introdotto da MySQL a partire dalla versione 5.5.
Partendo dalle novità già previste da “InnoDB”, il nuovo modulo è stato ideato e progettato per adattarsi meglio ai dispositivi hardware moderni, include una serie di funzionalità particolarmente adatte in ambienti caratterizzati da alte prestazioni e, seguendo i principi cardine di MariaDB, si presenta come completamente retrocompatibile ed in grado di sostituire a “caldo” l’engine di punta di MySQL.
Come è possibile leggere sul sito ufficiale di MariaDB, le nuove funzionalità di Percona XtraDB sono state appositamente progettate per superare alcune limitazioni di InnoDB partendo dalle segnalazioni rilasciate dagli utenti di MySQL con l’intento di attingere a un bacino potenzialmente molto elevato di nuovi utilizzatori.
MariaDB, architettura generale
Dal punto di vista infrastrutturale, MariaDB si presenta come un sistema composto da quattro macro-aree tra loro profondamente interconnesse che contribuiscono a creare un framework fortemente orientato verso una gestione dei dati olistica, unitaria e armonica.
Le vere e proprie fondamenta digitali sulle quali poggia l’intera architettura sono rappresentate dal modulo “MariaDB Server” che viene enfaticamente presentato come “l’unico database open source con le stesse funzionalità presenti nei database proprietari” e che ingloba al proprio interno una serie di funzionalità decisamente interessanti come la gestione delle “tabelle temporali”, la possibilità di lavorare in ambienti distribuiti (attraverso le cosiddette tecniche di sharding che consentono di creare veri e propri cluster), la capacità di continuare ad erogare i servizi critici anche a fronti di eventi anomali o errori critici, la crittografia dei dati, la compatibilità con Oracle e con il linguaggio PL/SQL, etc.
Il secondo modulo, che dalla versione 10.5.4 costituisce il cuore pulsante dell’intero sistema, è il “MariaDB ColumnStore” che estende le funzionalità della componente server essendo in grado di elaborare nativamente informazioni in maniera parallela e concorrente e gestire, senza eccessive difficoltà, grandi quantità di dati.
La terza “anima” è, infine, costituita da un “proxy”, denominato MaxScale, pensato per garantire alta disponibilità, resilienza, scalabilità al modulo server permettendo anche di generare un filtro tra la gestione del database e le applicazioni “verticali” che intendono utilizzare le funzionalità ed i servizi messi a disposizione dal DBMS.
L’ultimo componente essenziale è “Xpand” che è stato pensato per trasformare MariaDB in un database SQL distribuito in grado di scalare fino a milioni di transazioni al secondo attraverso una “share-nothing architecture” nella quale i nodi del cluster non condividono l’accesso alle risorse ma possono lavorare in maniera autonoma, indipendente e parallela.
Particolare attenzione alle performance
Una delle proprietà che maggiormente caratterizzano e rendono appetibile un DBMS è sicuramente quella correlata alla capacità di fornire risposte in tempi relativamente brevi così da introdurre il minimo livello di ritardo all’interno delle architetture digitali aziendali e permettere di assumere, in tempi rapidi, decisioni strategiche, scelte operative o misure organizzative.
Da questo punto di vista il team di MariaDB si rivela particolarmente attivo e propositivo tanto da aver introdotto nel corso degli anni una serie di meccanismi implementativi in grado di garantire prestazioni decisamente elevate.
A partire dalla versione 10.0.1, in particolare, il DBMS ha deciso di puntare, per l’ottimizzazione delle query, su statistiche indipendenti dal motore, che vengono salvate in tabelle tradizionali nel database e consentono la registrazione di più valori per individuare un piano ideale per l’esecuzione di dichiarazioni SQL.
Analizzando i dati presenti nelle citate tabelle, MariaDB è in grado di valutare in tempo reale i migliori percorsi e le soluzioni implementative più efficienti con il fine di fornire risposte nella maniera più veloce possibile.
Tutti gli addetti ai lavori, inoltre, possono trovare preziose istruzioni per l’ottimizzazione della performance del database nella documentazione ufficiale, che offre anche suggerimenti in merito all’ hardware maggiormente idoneo ed informazioni sulle configurazioni del sistema operativo, sulle strategie di gestione delle strutture di database, sul perfezionamento dell’indice e delle tabelle.
La gestione della disponibilità
Anche nell’implementazione delle contromisure finalizzate a garantire la “disponibilità” del database, che deve essere posto nelle condizioni di fornire i propri servizi in maniera continuata nel tempo anche a fronte di imprevisti o eventi anomali, MariaDB conferma la propria linea di pensiero, prendendo spunto dalle attività poste in essere dal progetto “genitore” con l’intento di garantire una valida alternativa e, allo stesso tempo, integrare e differenziare l’offerta attraverso soluzioni innovative.
In questo caso, l’asticella del confronto è posta decisamente in alto, considerando che il cluster di MySQL riesce a garantire disponibilità del 99,9999% grazie a un’architettura “multimaster” senza “Single Point of Failure” resa disponibile con la solita formula della licenza duale (ossia GPL nella versione community e commerciale per ambienti “enterprise”).
Partendo da tali premesse, MariaDB ha deciso di puntare, per la gestione dei database distribuiti, sul software “Galera cluster” sviluppato dall’azienda finlandese “Codership”, che è stato completamente integrato nel DBMS a partire dalla versione 10.1, e di offrire un’estensione speciale attraverso il già citato modulo “MaxScale”, che garantisce agli utenti numerose funzioni aggiuntive per la gestione dei “cluster”.
MaxScale può essere considerato come un filtro (o, in termini tecnici, un “proxy”) in grado di gestire il bilanciamento del carico su più database, coordinare i processi di anonimizzazione e pseudonimizzazione dei dati sensibili (anche in ossequio a quanto richiesto dal Regolamento Generale per la Protezione dei Dati Personali), bloccare le richieste in base a regole preconfigurate, proteggere da attacchi di tipo “Denial of Service” (DoS), avviare automaticamente le strategie di failover e incrementare le prestazioni del database.
Tale modulo, inoltre, rappresenta uno degli esempi più noti di applicazione della licenza ibrida BLS, che, nel caso specifico, limita per un intervallo di tre anni l’utilizzo gratuito del software ad un massimo di tre istanze di database per poi divenire completamente libero e “open source”, secondo i canoni tradizionali del GPL.
L’innovazione del modulo Flashback
Un’interessante novità, introdotta a partire dalla versione 10.2.4 di MariaDB, è rappresentata dal modulo “Flashback” che punta a risolvere in maniera semplice ed elegante uno dei problemi più ricorrenti nella gestione delle banche dati, ossia quello connesso all’errata o involontaria esecuzione di operazioni di inserimento, modifica e cancellazione su una o più tabelle.
Si tratta, invero, di una tematica di grande importanza soprattutto perché una corretta ed efficiente gestione di tali eventi può condurre a elevati risparmi in termini di tempo, lavoro svolto e capacità di fornire risposte corrette anche a fronte di situazioni anomale.
Se, infatti, il metodo tradizionale è quello di effettuare un “restore” da un backup, il nuovo componente implementato in MariaDB consente di riportare indietro nel tempo una porzione di database in maniera agevole e controllata attraverso funzionalità conosciute in ambito tecnico come “Point-in-time recovery”.
Al momento, tali attività di recupero sono consentite solamente sulle cosiddette attività di “manipolazione dei dati” (note anche con l’acronimo DML dalla locuzione anglosassone “Data Manipulation Language”), ossia alle operazioni SQL di insert, update e delete ma è già stato annunciata un’estensione del modulo Flashback che permetterà di gestire anche le attività di “definizione dei dati” (DDL da “Data Definition Language”) quali ad esempio la creazione, la cancellazione o la modifica della struttura di una tabella.
Il focus sulla sicurezza
Garantire la disponibilità, l’integrità e la riservatezza dei dati trattati è considerato ormai da lungo tempo un’attività di “Core Business” per i DBMS che, anche in ossequio a quanto previsto dalle normative sulla protezione dei dati personali e sulla cyber-security adottate in tutto il mondo, devono necessariamente implementare contromisure adeguate, proporzionate ed al passo con i tempi.
Sotto questo aspetto, MariaDB presenta numerose funzionalità ed in alcuni casi si differenzia in maniera sostanziale dalla concorrenza opensource, proponendo soluzioni innovative ed efficaci.
In linea con quanto previsto da MySQL, anche lo spin-off riesce a gestire la crittografia a livello di tabelle, log e database così come è in grado di aggiornare i parametri connessi al protocollo TLS anche a “run time”, senza dover essere riavviato.
Decisamente interessante è la scelta di aver previsto l’integrazione di due plug-in, riconducibili a due colossi come Amazon ed Eperi, che consentono la gestione e la crittografia delle chiavi. In particolare, “AWS Key Management Encryption Plugin”, che offre un unico punto di controllo per definire le policy in modo coerente tra più servizi integrati, non può essere rilasciato con licenza GPL e non è, quindi, proposto direttamente nel pacchetto standard ma può essere scaricato direttamente dal sito ufficiale del produttore mentre “Eperi Key Management Encryption Plugin”, associato ad una licenza GNU, è fornito insieme al codice di MariaDB ma la sua installazione non è prevista nel processo standard.
Estremamente avanzato è anche il funzionamento del Firewall che, integrato all’intero di MaxScale, si spinge ben oltre le funzionalità standard previste da numerosi DBMS tanto da essere presentato dalla community come “il DB firewall più evoluto al mondo”.
Particolarmente utile risulta essere, tra l’altro, la possibilità di filtrare le query attraverso whitelist o blacklist basate su espressioni regolari e su una specifica sintassi in grado di garantire ampia discrezionalità e flessibilità ai gestori delle banche dati.
Conclusioni
L’acquisizione di MySQL, ossia di una icona del software opensource che si era ampiamente affermata in tutto il mondo diffondendo i principi del codice aperto, ha senz’altro segnato uno spartiacque nella storia dei database, non tanto per le conseguenze (sicuramente limitate) che ha avuto sul prodotto stesso quanto per le reazioni che ha determinato nella comunità di sviluppatori internazionale.
Se, infatti, a distanza di anni il famoso DMBS continua a rimanere in gran parte gratuito, libero ed aperto, il suo passaggio verso Oracle ha sicuramente stimolato l’avvio di una nuova era, che ha trovato il proprio simbolo in un progetto lanciato dallo stesso creatore di MySQL con l’intento di difendere, valorizzare ed esaltare i principi del software open source e il lavoro di un team unito e vincente.
Partito per essere un clone praticamente speculare del proprio genitore, MariaDB si è però imposto sulla scena mondiale grazie ad una serie di scelte implementative che lo rendono un prodotto differente da MySQL e ne stanno decretando un crescente successo.
Coerente con le proprie origini, MariaDB continua a proporsi con una licenza di tipo GPL ma ha anche lanciato, grazie alle idee illuminate del proprio management, la cosiddetta “Business Source License” che mira a coniugare i vantaggi associati al software open source a meccanismi di tutela e difesa degli interessi degli sviluppatori.
Tali decisioni hanno fortemente rafforzato l’immagine e la reputazione di un progetto che ha ampliato e rafforzato negli anni la propria community ma ha saputo anche attrarre prestigiosi partner tanto da essere integrato nei pacchetti ufficiali delle principali distribuzioni Linux e avere tra i propri “sponsor” aziende del calibro di “MediaWiki Foundation”, Google, Booking.com e Automattic.
L’architettura generale basata su quattro grandi componenti ed una innumerevole serie di plug-in garantisce, inoltre, una estrema flessibilità ma anche una grande capacità di affrontare verticalmente tematiche di fondamentale importanza quali la gestione delle performance, della sicurezza, della resilienza e del disaster recovery.
Sicuramente oggi MariaDB può essere considerato un “prodotto” in piena ascesa, che ha raggiunto un buon livello di maturità e sta gradualmente provando a rimarcare la propria identità rispetto al progetto originario, tanto da far presagire una sempre maggiore divergenza nello sviluppo, negli obiettivi e nelle scelte strategiche.
Anche grazie a una comunicazione ben strutturata ed a campagne mediatiche finalizzate ad esaltare e diffondere le peculiarità del prodotto e del “brand”, MariaDB prosegue la propria rincorsa verso il primato tra i DBMS opensource in un contesto altamente competitivo che condurrà sicuramente ad importanti novità per gli addetti ai lavori e per gli utenti finali.
