MariaDB contro MySQL, Tecnologie Database a Confronto

In un precedente articolo, abbiamo illustrato la storia del web server Apache, il suo ruolo nell’ascesa di Internet e come la sua quota di mercato viene ora divorata da concorrenti come Nginx. Apache fa parte dello stack LAMP —Linux + Apache + MySQL + PHP — e non è un’esagerazione affermare che più della metà di Internet deve la sua esistenza a LAMP.

Oggi daremo uno sguardo ad alcune delle differenze tra MariaDB e MySQL, due tecnologie database simili eppure diverse, utilizzate per spingere milioni di siti web in tutto il mondo.

Cos’è MySQL

MySQL è un database relazionale (RDBMS) che ha visto la luce per la prima volta nel 1995, creato da Michael Monty Widenius e David Axmark. È nato nel periodo in cui il mercato era dominato dalle soluzioni proprietarie (e costose) di Microsoft e Oracle.

Oggi MySQL è un marchio archetipico. Il suo ruolo è stato fondamentale nella costruzione di Internet come la conosciamo oggi. Questo articolo su Linux Journal fa luce sui suoi primi giorni di vita.

Con la sua prima adozione della doppia licenza – e l’utilizzo di GNU GPL per la sua versione gratuita – MySQL ha spianato la strada a molti altri fornitori di software arrivati ​​dopo.

Nelle parole di Michael Widenius sulla doppia licenza:

… dal momento che MySQL è un prodotto di infrastruttura che è facilmente integrabile in altri prodotti, abbiamo potuto vendere licenze a coloro che volevano incorporare MySQL nel loro prodotto ma non volevano renderlo open source.

Le applicazioni web distribuite su server, come parte dello stack LAMP, di solito non incorporano MySQL e distribuiscono il loro codice. Ciò significava che chiunque poteva usare liberamente il software per i propri prodotti web.

Meno di un decennio dopo la sua uscita pubblica, MySQL dominava il mercato dei database relazionali open source.

Google Trends mostra che l’interesse della ricerca globale in MySQL ha raggiunto il picco tra il 2004 e il 2005:

Tra le aziende degne di nota che utilizzano MySQL ricordiamo:

• Facebook, un rapporto del 2011 menziona “60 milioni di query al secondo e quasi 4 milioni di modifiche di riga al secondo” e MySQL gestisce “praticamente ogni interazione dell’utente: Mi piace, condivisioni, aggiornamenti di stato, avvisi, richieste”.
• La parte legata alla fatturazione della piattaforma di Netflix
• Youtube
• Booking.com
• Airbnb
• e molti altri.

Un altro fattore che ha contribuito all’ascesa e all’adozione di MySQL degno di nota è phpMyAdmin.

PhpMyAdmin è uno strumento di amministrazione di database basato sul web che risale al 1998, che si è fatto strada abbastanza presto tra le console di gestione dei provider di hosting condiviso, tra cui cPanel. È uno strumento scritto in PHP che ha semplificato l’amministrazione di MySQL su server LAMP. Importare, esportare, comporre query complesse, eliminare e creare tabelle, condurre ricerche complesse sono solo alcune delle cose rese possibili da phpMyAdmin senza che gli utenti debbano mai usare il terminale Linux.

WordPress e MySQL

Uno dei fattori alla base della popolarità di MySQL è senza dubbio WordPress, che oggi alimenta circa il 60% dei sistemi CMS o il 34% dell’intero web.
WordPress è stato creato nel 2003 da Matt Mullenweg e Mike Little, come fork di un altro progetto. È stato scritto in PHP, con MySQL come database e, quando è apparso, si è diffuso con la rapidità di un incendio.

WordPress è divenuto rapidamente sinonimo del concetto di software open source e così è successo per lo stack server sottostante. DisplayWP ha un bel grafico della versione minima richiesta di MySQL per ogni versione di WordPress.

Uno dei fattori che ha favorito l’adozione di MySQL è stato l’aspetto GPL delle sue licenze. Dato che è compatibile con Linux, ha iniziato a essere incluso di default nelle distribuzioni Linux. Oggi viene incluso di default con Ubuntu.

Breve Panoramica di MySQL e del Relational Database Model

MySQL è stato concepito come un RDBMS (Relational Database Management System). Il modello del database relazionale risale agli anni ’70, come indicato dai “Dodici comandamenti di Codd”. Per dirla brevemente, questo modello struttura i dati in tabelle costituite da righe e colonne. Ogni riga è identificata in modo univoco da una chiave (chiave primaria per utilizzare il gergo SQL).

Queste chiavi primarie possono essere utilizzate come perni di un tipo utilizzato da altre tabelle per definire una relazione con la riga specifica. Quindi la colonna FOREIGN KEY di una tabella di database relazionale farà riferimento a una colonna PRIMARY KEY in un’altra tabella, definendo una relazione tra le righe in tabelle diverse.

Come spiega Essential SQL, “La chiave primaria è costituita da una o più colonne i cui dati vengono utilizzati per identificare univocamente ogni riga della tabella”. Le colonne della chiave primaria devono essere univoche e non possono essere vuote o NULL. In un database relazionale “la tabella ha solo una chiave primaria e la sua definizione è obbligatoria”.
Allo stesso tempo, “una foreign key è un insieme di una o più colonne di una tabella che fa riferimento alla chiave primaria in un’altra tabella. Non ci sono codici speciali, configurazioni o definizioni di tabelle da inserire per “designare” ufficialmente una chiave esterna”.

In questo modo, con i database relazionali, è possibile modellare i dati in modi sofisticati e definire connessioni tra vari elementi. Nel nostro semplice esempio qui sopra, abbiamo due tabelle, con righe che possono essere correlate tra loro, ad es. ogni persona possiede una macchina.

Siamo in grado di eseguire una query di questi dati secondo la logica di cui abbiamo bisogno, possiamo filtrare il set di risultati in base a diversi insiemi di criteri e possiamo costruire la nostra query in un modo molto più complesso di quanto descritto sopra.

Per questo motivo, i database relazionali – e i database in generale – utilizzano linguaggi di dominio specifici, tra cui l’SQL, che sta per Structured Query Language, è quello prevalente se non l’unico usato dai RDBMS.

L’Acquisizione da Parte di Sun

Nel 2008, MySQL AB, l’azienda dietro MySQL, è stata acquisita da Sun Microsystems. L’azienda ha creato JAVA, Solaris Unix OS e ha contribuito in modo significativo a diverse tecnologie informatiche. Come all’epoca riportava Business Wire:

“Sun Microsystems, Inc. (NASDAQ: JAVA) ha annunciato oggi di aver siglato un accordo definitivo per acquisire MySQL AB, un’icona dell’open source e sviluppatore di uno dei database open source in più rapida crescita al mondo, dal valore stimato di circa 1 miliardo di dollari”

Dimostrerà presto che questa acquisizione non è stata sufficiente ad evitare la caduta di Sun, ma dipinge un quadro di quanto fosse grande MySQL in quei giorni.

Oracle

Oracle Corporation è fornitore del più grande database chiuso di oggi, il database Oracle.

È stato un diretto concorrente di MySQL e praticamente l’antitesi del modello software GPL, gratuito e open source in cui MySQL stava evolvendo in quel momento.

Quando Oracle nel 2010 ha acquistato la Sun, e con questa MySQL (superando in questo la IBM), il mondo FOSS lo vide “sinistro” come un attacco Borg in Star Trek. Un utente ricorda l’evento su Quora:

MySQL rappresentava una grave minaccia per Oracle – all’epoca il database Oracle rappresentava qualcosa al di sopra dell’80% di tutte le entrate (e dato il personale minimo necessario a mantenerlo, qualcosa ancora in più per quel che riguarda i profitti).

MySQL si stava facendo strada sul serio – le grandi aziende Fortune 50, con licenze su siti che costavano milioni, trasferivano i database (soprattutto quelli di sola lettura) da Oracle a MySQL perché il sovraccarico amministrativo era molto più basso. Lo so, ho contribuito anche io a farlo in alcuni casi.

Molti nella community di MySQL volevano aggiungere funzionalità che avrebbero reso obsoleta persino una versione gratuita di Oracle. MySQL stava decisamente seguendo questa strada. Gli strumenti stavano maturando e Larry aveva paura.

Quindi Oracle acquistò MySQL per assicurarsi il controllo sul brand, diffuse la community e salvò il suo fiore all’occhiello dalla massa.

Era una conclusione logica, perché MySQL, a quel tempo, era divenuto così popolare che avrebbe potuto essere visto come una vera minaccia per il core business di Oracle. Come la mise Ankush Thakur di Geekflare, MySQL divenne così popolare che ben presto gli sviluppatori dimenticarono che SQL e MySQL fossero due cose diverse.

Prima ancora dell’acquisizione, alla fine del 2009, Monty Widenius, che quell’anno aveva lasciato il team MySQL per creare il proprio fork e la propria azienda per il database, pubblicò un appello drammatico sul suo blog (citeremo solo l’inizio):

Aiutaci a salvare MySQL

Io, Michael “Monty” Widenius, il creatore di MySQL, ti chiedo con urgenza di aiutarci a salvare MySQL dalle grinfie di Oracle. Senza il tuo immediato aiuto, Oracle potrebbe arrivare alla proprietà di MySQL da un giorno all’altro. Scrivendo alla Commissione Europea (CE) è possibile supportare questa causa e contribuire a proteggere il futuro sviluppo del prodotto MySQL come progetto Open Source.

L’acquisizione, però, avvenne un mese dopo, tra lo sgomento di molti nella community dell’open source. Widenius aveva già lasciato Sun, formato Monty Program AB e creato un fork di MySQL, gettando le basi per MariaDB. Tutto questo portando con sé molti sviluppatori MySQL.

Fino ad oggi, la gente continua a mettere in discussione la legittimità delle paure di Monty. Soprattutto perché lo scenario peggiore non si è mai verificato: Oracle non ha acquisito MySQL solo per ucciderlo.

Alcuni sostengono che MySQL sia stato acquistato da Oracle come nient’altro che una “vittima collaterale” dell’acquisizione di Sun. Nel 2009 chi aveva gli occhi puntati sul mercato dei database aveva motivi di preoccupazione.

Gli avvertimenti c’erano. Lo sviluppatore del principale motore di archiviazione di MySQL, InnoDB, un’azienda finlandese, è stato acquisito da Oracle nel 2005. Successivamente, è stata completamente integrata in Oracle, che ha chiuso l’azienda originale. Nel 2006, Oracle ha acquistato l’azienda che aveva creato Berkeley DB, fornitore di un altro motore di archiviazione BDB meno importante. Ci stavano girando intorno.

Cos’è MariaDB

La prima versione di MariaDB è stata rilasciata a ottobre 2009, con la versione 5.1.38 Beta, basata su MySQL 5.1.38. Era un fork destinato a “garantire che la base di codice MySQL fosse libera per sempre”.

Al momento del fork, la paura più sentita era che l’acquisizione fosse un’acquisizione ostile, con l’obiettivo di uccidere MySQL. Quella preoccupazione, almeno in parte, si è rivelata infondata.

Sempre nel 2009, Monty Program AB e Percona, una società che fornisce servizi MySQL premium, hanno fondato Open Database Alliance. Il loro obiettivo era “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”.

L’idea era “diventare l’hub del settore dei database open source MySQL, inclusi MySQL e codice derivato, binari, formazione, supporto e altri miglioramenti per la comunità di MySQL e per l’ecosistema dei partner”

Ripensandoci: è possibile che questi passaggi abbiano impedito uno scenario peggiore per il famoso database.

MariaDB contro MySQL: Compatibilità

Il punto centrale del fork di MySQL di MariaDB (dal nome della figlia di Widenius) era quello di garantire il futuro accesso a MySQL e il suo ulteriore sviluppo. Questo è il motivo per cui MariaDB è stato concepito come una sostituzione binaria completa – una sostituzione “drop-in”, per così dire – che consente a tutti gli utenti di MySQL di scambiare uno con l’altro sui propri sistemi.

MySQL è un’applicazione client-server e sia il suo programma server mysqld, il suo client mysql, sia i programmi ausiliari, come mysqldump, mantengono lo stesso nome con MariaDB.

La sostituzione di MySQL con MariaDB diventa un processo continuo per la maggior parte delle applicazioni e degli scopi, in particolare con WordPress. I software esistenti, dai CMS popolari ad app come phpMyAdmin, funzionano immediatamente e i dati possono essere esportati/importati dall’uno all’altro senza alcuna modifica.

L’obiettivo dichiarato di MariaDB è mantenere la compatibilità con MySQL. Secondo il sito web MariaDB,

• I file di definizione dei dati e delle tabelle sono compatibili.
• Tutte le API e i protocolli client sono compatibili.
• Nomi dei file, binari e percorsi sono gli stessi su MySQL e MariaDB.
• Le porte e i socket sono gli stessi.
• Tutti i connettori MySQL – PHP, Perl, Python, Java e altri – funzionano con MariaDB.
• Il pacchetto client MySQL funziona in modo intercambiabile con MariaDB, proprio come con MySQL.

Vengono condotte fusioni mensili per garantire la compatibilità e ottenere da Oracle nuove funzionalità e correzioni di bug.

MariaDB contro MySQL: le Ragioni del Fork

C’erano diverse ragioni dietro il rilascio di MariaDB. Una delle principali ragioni era sicuramente il timore che Oracle avrebbe ucciso il suo crescente concorrente per proteggere il suo prodotto principale più redditizio. Gli utenti avrebbero perso un prodotto fantastico e gratuito!

Altre ragioni erano legate al fatto che MySQL sarebbe rimasto libero e open source. Oggi, MariaDB è totalmente sotto licenza GPL, con l’intero set di funzionalità, mentre MySQL mantiene un approccio a doppia licenza, con funzionalità premium concesse in licenza proprietaria, a pagamento:

“MySQL Enterprise Edition include il più completo set di funzionalità avanzate, strumenti di gestione e supporto tecnico per raggiungere i massimi livelli di scalabilità, sicurezza, affidabilità e uptime di MySQL. Riduce il rischio, i costi e la complessità nello sviluppo, nella distribuzione e nella gestione di applicazioni MySQL fondamentali per il business.“

Se confrontiamo i due, MariaDB ha un chiaro vantaggio dato dalla licenza GPL con cui è rilasciato. A causa della base di codice proprietario, Oracle non può legalmente trarre vantaggio dal codice di MariaDB e farlo confluire nel proprio database.

Widenius ha promesso: “Quando Oracle rilascerà un’estensione chiusa per MySQL, anche noi ne rilasceremo una open source.”

La Community è Importante

Un’altra ragione alla base del fork è stata quella di mantenere “aperto” il progetto, nel senso che è un progetto guidato dalla community (come WordPress), la cui direzione e sviluppo sono aperti proprio come la sua licenza. Se diamo un’occhiata al commit log, è facile concludere che la maggior parte del codice MySQL proviene da sviluppatori interni. Gli sviluppatori di Oracle ringraziano per contributi occasionali e notevoli che provengono dalla community, ma una cosa ben lontana dall’apertura di MariaDB e da quello che era MySQL.

Per mettere le cose in prospettiva, la server repository di MariaDB, al momento in cui scriviamo, conta oltre 186k ​​commit, 370+ branch e 200 contributor. MySQL, d’altra parte, ha più di 148k commit, 9 branch e 72 contributor.

La discussione sullo sviluppo di MariaDB, la sua direzione, il voto sulle funzionalità, ecc. è fatta su una mailing list pubblica:

Oltre a questa, c’è anche la mailing list Maria Discuss.

Maria Captains è un team di sviluppatori fidati a cui gli sviluppatori possono inviare patch. Come dice la pagina del team su Launchpad:

“I capitani sono sviluppatori fidati con accesso in scrittura ai principali alberi di MariaDB. Se vuoi avere una patch nell’albero, inviala all’elenco dei maria-developer e uno o più capitani collaboreranno con te per far rivedere, approvare e infine inserire la patch nell’albero appropriato di MariaDB.”

In alcune occasioni, il vivace processo di sviluppo di MariaDB ha dimostrato i suoi vantaggi rispetto a quello chiuso di Oracle.

Alla fine del 2012, è stata costituita la MariaDB foundation, con lo scopo di supervisionare lo sviluppo del database.

Poco dopo il fork, molti degli originali sviluppatori MySQL hanno abbandonato la nave e si sono uniti al progetto MariaDB. Vendor Linux come Red Hat, CentOS, Arch Linux, Debian, OpenSuse, Slackware, Fedora sono passati a MariaDB come RDBMS predefinito, così come le distribuzioni BSD, FreeBSD e OpenBSD, mentre Ubuntu include MariaDB. L’intero elenco è disponibile qui.

Aziende come Alibaba Cloud, Tencent, IBM, Microsoft, Booking.com sono diventate sponsor del platino.

Per Kinsta, che è il miglior hosting WordPress per applicazioni, database e servizi gestiti, è importante menzionare che tra i membri del consiglio di amministrazione della MariaDB Foundation ci sono persone di Automattic, un chiaro segno che coloro che hanno creato WordPress hanno scelto MariaDB.

Negli anni successivi alla divisione, MariaDB ha avuto uno sviluppo vivace, tanto che, per l’iontero set di nuove funzionalità introdotte nel 2012, MariaDB è saltato dal numero di versione 5.*, compatibile con MySQL, alla 10.0, volendo riflettere il balzo compiuto nelle funzionalità.

Per motivi legati alle prestazioni, la Wikimedia Foundation ha annunciato nel 2013 che stava passando Wikipedia su MariaDB. La stessa cosa è successa con Google, e l’elenco dei suoi utenti include ora Deutsche Bank, DBS Bank, Nasdaq, Verizon, Craigslist e altri.

Tra gli utenti MySQL abbiamo GitHub, US Navy, NASA, Tesla, Netflix, WeChat, Facebook, Zendesk, Twitter, Zappos, YouTube, Spotify.

Sin dalla sua prima uscita, l’interesse per il successore di MySQL è cresciuto costantemente, come mostra Google Search Trends:

MariaDB contro MySQL: Differenze Chiave

Sebbene all’inizio MariaDB non fosse completamente compatibile con MySQL, possiamo aspettarci che i loro percorsi divergano maggiormente in futuro.

Nel suo ultimo post, Widenius si congratula con Oracle per il suo lavoro sulla versione 8.0 di MySQL, sottolineando alcune differenze e avvertenze come:

Thread pool: simile al problema che il server Nginx risolve rispetto ad Apache, MySQL stava assegnando thread a ogni connessione client e questo, che poteva essere paragonato all’avvio di un intero programma su un PC, era semplicemente inefficiente. MariaDB ha introdotto la propria soluzione a questo problema nella versione 5.5

Invisible Columns sono una funzionalità esclusiva di MariaDB a partire dalla versione 10.3.3. Non restituiscono risultati in un’istruzione SELECT *, né richiedono che venga loro assegnato un valore in un’istruzione INSERT.

MariaDB introduce i microseconds nei suoi datatype temporali.

Motori di archiviazione: MariaDB include XtraDB, InnoDB, MariaDB ColumnStore, Aria, Archive, Blackhole, Cassandra Storage Engine, Connect, CSV, FederatedX, Memory storage engine, Merge, Mroonga, MyISAM, MyRocks, QQGraph, Sequence Storage Engine, SphinxSE, Spider, TokuDB. ColumnsStore è interessante dal punto di vista delle prestazioni, perché rende possibile lo scaling lineare per gestire petabyte di dati. Maggiori informazioni sul blog.

I motori di archiviazione MySQL sono InnoDB, MyISAM, Memory, CSV, Archive, Blackhole, Merge, Federated, Example.

MariaDB introduce ottimizzazioni significative nelle viste del database, eseguendo la query solo delle tabelle necessarie.

Alcune funzionalità introdotte da MySQL sono tipo di dati nativo JSON, MySQL Shell nella versione MySQL 8.0 – che consente lo scripting javascript e python – e non funziona con MariaDB, plugin di autenticazione basato su SHA-256, miglioramento della sicurezza su mysql_native_password.

Qui potete trovare l’elenco completo delle differenze tra MariaDB e MySQL e i vantaggi del primo rispetto al secondo.

Riepilogo

MySQL è sotto l’ombrello del più grande fornitore di database commerciali al mondo. Con tanti ingegneri a tempo pieno che lavorano tutto il giorno per sviluppare nuove funzionalità premium, abbiamo già diversi punti su cui divergono. MariaDB, d’altro canto, di solito tiene il passo delle aggiunte premium, ma non è sempre immediato e non ci sono garanzie.

Detto questo, però, ci sono molte situazioni in cui MariaDB offre prestazioni migliorate. Aggiungete patch e aggiornamenti più agili, un futuro open source più stabile e un po’ più di ottimismo, e vedrete perché in Kinsta non siamo solo dei fan di MariaDB, ma lo utilizziamo come parte del nostro stack server mirato sulle prestazioni.

Tonino Jankov

Tonino er en iværksætter, Linux & OSS entusiast, udvikler og teknisk underviser. Han har over ti års erfaring med udvikling og har været i blockchain-området i 3+ år. Når han ikke koder, skriver han for SitePoint og Alibaba Cloud, overvåger de nyeste skønlitterære værker på Netflix og udforsker nye rejsedestinationer.

• Twitter