Sante Caserio

I miei ultimi articoli su MySQL e argomenti affini sono stati pubblicati su MySQL Italia (e per pigrizia non su questo blog, almeno per ora). La licenza con cui sono distribuiti è la Creative Commons Attribution Non-Commercial Share Alike versione 2.5, che ritengo libera. Potete trovare i miei testi nelle sezioni wiki e articoli, insieme ad altro materiale altrettanto interessante, se non di più.

Ringrazio sentitamente lo staff e in particolare Gianluigi e colgo l’occasione per invitare gli utenti di MySQL a utilizzare MySQL Italia, uno dei pochi siti ben curati e precisi.

Si chiama MariaDB il principale fork di MySQL, nato dal suo stesso creatore Monty Widenius in seguito all’acquisizione di MySQL da parte della Sun e, infine, di quest’ultima società da parte della Oracle.

Il nome suggerisce che, nelle intenzioni iniziali di Widenius, l’aspetto su cui il fork si sarebbe dovuto concentrare avrebbe dovuto essere Maria, lo storage engine da lui stesso creato. In realtà MariaDB include anche altri storage engine, sviluppati da terze parti. Vi sono poi alcuni contributi apportati dalla comunità, che in MySQL non sono stati inclusi – probabilmente a causa di procedure troppo rigide, che per la verità non sono state introdotte né da Sun né da Oracle. Ma il lavoro principale degli sviluppatori di MariaDB consiste probabilmente nel migliorare il codice già esistente e quello che viene man mano sviluppato per MySQL, testandolo e correggendo bug e problemi di performance.

La piattaforma primaria per MariaDB è certamente GNU/Linux. In particolare sono stati creati dei pacchetti per varie versioni di Ubuntu, mentre non sono ancora pronti gli RPM per Red Hat e CentOS. Vi sono però i binari per GNU/Linux a 32 e a 64 bit. E’ inoltre scaricabile una versione per Windows che non necessita di installazione. Il sito di MariaDB al momento non menziona la volontà di supportare (o meno) MacOS o altri sistemi UNIX.

Il programma è attualmente in fase beta, quindi non pronto per essere utilizzato in ambienti di produzione. Scaricando l’ultima versione è comunque possibile farsi un’idea abbastanza precisa di come sarà la versione stabile.

La licenza utilizzata è la GNU GPL versione 2, ereditata da MySQL.

Analizziamo di seguito le varie novità di MariaDB rispetto al progenitore MySQL.

Maria

Si tratta di uno storage engine che deriva da MyISAM. Rispetto a quest’ultimo è più performante, soprattutto per quanto riguarda il caching; inoltre può gestire tabelle transazionali. Questa caratteristica sacrifica in parte le performance dei comandi SQL ed è attiva di default quando si crea una tabella. Per creare un’entità non transazionale ma più performante si può usare un’istruzione simile alla seguente:

CREATE TABLE new_tab (…) ENGINE=Maria TRANSACTIONAL=0;

Come per le tabelle MyISAM, le entità Maria non transazionali possono utilizzare il formato FIXED (più performante) o il formato DYNAMIC (richiede meno spazio). Esiste poi il formato PAGE (l’unico disponibile per le tabelle transazionali), ideato per velocizzare il chaching. Tramite la utility maria_pack è possibile generare tabelle compresse di sola lettura, esattamente come si fa con MyISAM.

MariaDB utilizza Maria per gestire le tabelle temporanee create internamente e questo velocizza l’esecuzione di alcune query.

MyISAM, comunque, è ancora presente in MariaDB.

XtraDB

Questo storage engine è un fork di InnoDB sviluppato dalla Percona. Esso incorpora diversi contributi apportati dalla comunità e non presenti nel suo progenitore e, in MariaDB, lo sostituirà.

Allo stato attuale si può notare come l’inclusione di questo engine sia in qualche modo iniziata (ad esempio la presenza della tabella XTRADB_ENHANCEMENTS), ma non è ancora possibile utilizzarlo.

PBXT

PBXT è uno storage engine transazionale sviluppato dalla PrimeBase. Implementa il controllo di versione multipla dei record, che permette di modificare righe delle tabelle senza bloccare l’accesso da parte di altre query, anche durante una transazione. I dati modificati da una transazione vengono scritti su disco una sola volta, in quanto PBXT garantisce l’affidabilità senza che i dati passino prima da un apposito log. Ha inoltre un meccanismo di rilevazione dei deadlock.

I vantaggi di questo storage engine risiedono dunque nelle prestazioni, che possono essere analizzate tramite il tool xstat e la tabella PBXT_STATISTICS nell’INFORMATION_SCHEMA.

Analisi delle prestazioni

E’ stato migliorato lo slow query log, al quale sono state aggiunte numerose informazioni che dovrebbero facilitare l’individuazione dei colli di bottiglia. Sia questo log sia l’istruzione SHOW PROCESSLIST, inoltre, forniscono ora informazioni dettagliate fino al microsecondo (non più al secondo).

Prestazioni e affidabilità

Il sito di MariaDB promette una maggiore stabilità, che deriverebbe anche dalla scelta di eliminare, dove possibile, i warning generati in fase di compilazione.

Abbiamo inoltre un incremento delle prestazioni facilmente rilevabile in almeno un tipo di query scritte male (SELECT che citano nella clausola FROM tabelle non effettivamente utilizzate). E’ infine segnalato un miglioramento prestazionale nella gestione dei thread.

E dopo?

Lo sviluppo di MariaDB, naturalmente, continua. Nel ramo 5.1 dovranno ancora essere inseriti gli storage engine XtraDB, che sostituirà InnoDB, e FederatedX, una evoluzione di FEDERATED, il quale non è più mantenuto. La prossima versione sarà la 5.2.

E’ possibile tenere d’occhio il lavoro svolto dal team di sviluppo grazie al worklog pubblico, che si trova a questo indirizzo: http://askmonty.org/worklog/index.pl

Siti di riferimento

Sito di MariaDB: http://askmonty.org/

Planet MariaDB: http://planetmariadb.org/

Documentazione di Maria: http://dev.mysql.com/doc/refman/5.1-maria/en/se-maria.html

Documentazione di XtraDB: http://www.percona.com/docs/wiki/percona-xtradb:start

Documentazione di PBXT: http://www.primebase.org/documentation/

L’SQL è un linguaggio imperativo. Questo significa che è costituito da una serie di comandi che indicano un’azione da compiere, lasciando poco spazio per le strutture di controllo del flusso. Sappiamo che il suo sottoinsieme noto come DML (Data Manipulation Language) comprende tre istruzioni fondamentali: DELETE per cancellare i record, UPDATE per aggiornarli e INSERT per inserirli. Sono azioni piuttosto elementari, che nel nostro lavoro quotidiano dovrebbero combinarsi formando istruzioni più complesse. Un esempio di richiesta complessa che spesso si vorrebbe rivolgere a un database è: “se un certo record nella tabella XXX esiste già, allora fai questo”. Mancando in SQL le istruzioni condizionali, generalmente questo tipo di logica è contenuta nel programma che si occupa di lanciare le query (esempio: uno script PHP). Un’alternativa è scrivere una Stored Procedure che se ne occupi, perchè tali procedure ammettono estensioni procedurali al linguaggio SQL, o possono essere scritte in altri linguaggi. MySQL però comprende alcune comode estensioni non standard che permettono di comunicare al server come si debba comportare nel caso in cui un certo record già esista.

Valori unici

Cosa significa per un database “questo record esiste già”? Come sappiamo, un record può essere identificato da una o più chiavi, ognuna delle quali può essere un campo, la prima parte di un campo o una combinazione di più campi. Generalmente la Chiave Primaria, che è il modo principale per identificare un record, è costituita da un campo numerico (UNSIGNED INTEGER) chiamato `id`. Vi possono essere delle Chiavi Candidate, che consistono in velori o combinazioni di valori che sono unici per ogni record. In MySQL questi sono i campi che rappresentano gli indici UNIQUE.

INSERT IGNORE

La prima di queste estensioni è la clausola IGNORE dell’istruzione INSERT. Essa semplicemente chiede a MySQL di ignorare gli errori dovuti al tentativo di inserire valori duplicati nella chiave primaria. In altre parole, se si tenta di inserire un record ma esso non può essere scritto poiché contiene un valore unico già presente in tabella, non viene generato alcun messaggio di errore. Se si tenta di inserire diversi record con un’unica INSERT e alcuni di questi non possono essere scritti perchè contengono valori duplicati, gli altri record verranno scritti senza problemi e non viene restituito alcun errore. Spesso i messaggi di errore hanno effetti collaterali che si desidera evitare.
Un’ulteriore possibilità è usare, oltre alla clausola IGNORE, anche la clausola DELAYED. Essa chiede a MySQL di non generare alcun messaggio di errore in nessun caso. Questo vale per gli errori di tipo “Duplicate key”, ma anche ogni altro tipo di errore - ad esempio la mancanza dei permessi necessari per scrivere sulla tabella, disco pieno, etc. Se tale comportamento ci è comunque gradito (perchè non abbiamo intenzione di gestire alcun tipo di errore) allora la clausola DELAYED è da preferire per ragioni di performance. Infatti ciò che rallenta maggiormente le applicazioni sono le comunicazioni di rete e il mancato invio di messaggi di errore che verrebbero comunque ignorati è un’ottimizzazione intelligente. Comunque, è bene ricordare che gli unici Storage Engine a supportare questa clausola sono MyISAM, MEMORY, ARCHIVE e BLACKHOLE. Se usata su tabelle che usano altri motori, DELAYED provoca un errore.

Esempi:

INSERT IGNORE INTO `clienti` (`nome`, `cognome`, `tel`) VALUES ('Mario', 'Rossi', '123456');
INSERT DELAYED IGNORE INTO `clienti` (`nome`, `cognome`, `tel`) VALUES ('Maria', 'Bianchi', '654321');

REPLACE

Il comportamento appena illustrato è desiderabile nel caso in cui il record che si tenta di inserire non possa essere più completo di quello già esistente. Se però nel record già presente in tabella alcuni campi sono vuoti (o meglio, impostati ai valori di DEFAULT), anche nel caso in cui l’istruzione INSERT contenga tali valori, essi andranno persi.
Esiste però il caso opposto, cioè quello in cui si presume che il record già presente contenga meno informazioni (o informazioni meno aggiornate) rispetto a quelle che si sta tentando di inserire. In tal caso è ragionevole chiedere a MySQL si inserire sempre e comunque il nuovo record, sostituendo quello che eventualmente potrebbe essere già presente. Per fare questo si utilizza l’istruzione REPLACE.
Essa è una combinazione di DELETE + INSERT. Questo implica alcune conseguenze non del tutto ovvie. La prima riguarda i permessi: per eseguire REPLACE bisogna avere i permessi di DELETE e INSERT. Inoltre, se si esegue REPLACE su una tabella InnoDB (o su altre tabelle che supportano le Chiavi Esterne) prima di inserire il nuovo record si cancellerà il vecchio, scatenando l’evento ad esso associato (come ON DELETE SET NULL). Infine, se sulla tabella sulla quale si esegue una REPLACE esiste un trigger associato all’evento DELETE, questo verrà lanciato.

Esempi:

REPLACE INTO `clienti` SET `nome`='Mario', `cognome`='Rossi', `tel`='123456';
REPLACE DELAYED INTO `clienti` SET `nome`='Maria', `cognome`='Bianchi', `tel`='654321';

Si noti, infine, che REPLACE potrebbe eliminare più di un record prima di inserire il nuovo. Infatti, come si è detto, una tabella può avere più chiavi uniche (PRIMARY KEY e campi UNIQUE) e naturalmente un record potrebbe contenere diversi valori duplicati. Dopo aver lanciato questa istruzione, il numero di affected_rows() restituito corrisponde a 1 (il nuovo record inserito) + il numero di record eliminati. Sapere questo ci permette di determinare facilmente se uno o più record sono stati liminati e quanti:

$deleted_rows = mysqli_affected_rows($con) – 1;

INSERT … ON DUPLICATE KEY UPDATE

Vi è poi un ultimo caso, che è una via di mezzo tra i due precedenti. Può darsi che si voglia inserire un record nel caso esso non sia già esistente, ma che se esso esiste non vogliamo perdere né alcune informazioni già scritte in tabella, né alcune informazioni presenti nell’istruzione. In tal caso si utilizzerà INSERT con la clausola ON DUPLICATE KEY UPDATE.

Vediamo subito un esempio, nel quale tentiamo di inserire un nuovo utente; se esso esiste, vengono modificati il suo indirizzo email e l’url del suo blog, lasciando però inalterate tutte le altre informazioni.

INSERT INTO `utenti` (`username`, `password`, `email`, `www`)
VALUES ('pippo', 'sesamo', 'pippo@topolinia.com', 'pippo.noblogs.org')
ON DUPLICATE KEY UPDATE `email`='pippo@topolinia.com', `www`='pippo.noblogs.org';

INSERT … ON DUPLICATE KEY UPDATE non può essere utilizzata con DELAYED, sebbene ciò non generi alcun errore. E’ possibile inserire diversi record come si fa talvolta con le INSERT anche utilizzando la clausola ON DUPLICATE KEY UPDATE. Il numero di affected_rows() equivale al numero di record inseriti + (il numero di record modificati * 2). Questo implica che non è possibile sapere con esattezza quanti record sono stati aggiunti e quanti sono stati modificati basandosi esclusivamente su affected_rows().

Ho appena aggiunto una sezione di una pagina del progetto di documentazione libera di MySQL (metadati sugli eventi). E’ un lavoro sporco, o meglio noioso, ma qualcuno doveva pur farlo. Mi dispiace solo che al momento il progetto sia un po’ abbandonato a sè stesso, perchè non ce n’è mai stato così bisogno come oggi.

Spero che a qualcuno venga voglia di contribuire. Non fatevi intimidire dall’inglese. Prima di tutto, credo che i contributor più attivi non siano madrelingua inglese. E poi c’è sempre bisogno di una traduzione in italiano - anche se fosse parziale e aggiornata di rado sarebbe meglio di niente.

Buona rivolta.

L’acquisizione della Sun Microsystems da parte della Oracle ha scosso un po’ tutti i sostenitori del software libero. MySQL comprata prima dalla Sun e ora dalla diretta concorrente Oracle? Orrore! O forse no.

Oracle ha acquisito la Sun per molti motivi: Java (molto usato da Oracle), i server, i prodotti per il backup dei database su nastro, Solaris e altri minori. E, dimenticavo… MySQL. Come come? Sento qualcuno pensare “ma che se ne fa Oracle di MySQL!”. Che se ne fa?? Oh, niente, bazzeccole… in fondo è solo il dbms più utilizzato, che non teme di essere sorpassato da nessuno almeno per diversi anni. Forse quei mattacchioni pensano di usarlo per convincere una parte dei clienti a passare ad Oracle. Cosa volete che sia: in fondo se comprassero le televisioni di tutto il mondo e trasmettessero i loro spot 24 ore al giorno otterrebbero lo stesso risultato, ma pare preferiscano usare MySQL.

MySQL non ci sta. O meglio, i programmatori che lavorano per MySQL non ci stanno. MySQL ci sta eccome, è solo un marchio, un loro, un sito interattivo fatto coi colori tipici del web 2.0 (scusate: non c’entra niente; però erano anni che volevo scrivere anch’io “web 2.0″, ma non ho mai potuto farlo perchè non so cosa sia). I programmatori invece sono persone che hanno scelto di lavorare a un grosso progetto di software libero, e questa scelta non è stata casuale.

Uno di loro è il fondatore di MySQL, Monty Widenius. Come molti altri, anche lui era già scappato a gambe levate dopo l’acquisizione da parte della Sun. Ha messo su una sua società chiamata The Monty Program e ha pensato bene di fondare un fork liberi chiamato MariaDB. Ora che MySQL appartiene alla Oracle, Widenius si sfrega le mani: i pochi programmatori importanti che non sono ancora scappati scapperanno entro pochi giorni, e la scelta più logica per la maggior parte di loro sarà entrare nel Monty Program.

Il progetto procede bene. La prima versione di MariaDB sarà la 5.1, perchè corrisponderà al numero di versione di MySQL da cui deriva. Stanno già lavorando, anche se non vi è ancora alcun rilascio pubblico. Appena ce ne sarà uno, rilasceranno una versione ogni 3 mesi. Naturalmente questo non significa che la prima versione pubblica potrà essere considerata stabile.

Nel TO-DO scopriamo che le novità più importanti che verranno aggiunte nella 5.1 saranno:

• PBXT e XtraDB, due storage engine creati dagli utenti;
• il nuovo FederatedX;
• alcuni contributi degli utenti presi da OurDelta;
• pulizia del codice;
• miglioramenti nelle performance.

Intanto, Brian Aker (ex-capo architetto di MySQL) ha fondato il suo fork, Drizzle. Essenzialmente, hanno preso una piccola parte di MySQL, hanno ripulito completamente quelle parti di codice e le stanno riscrivendo in maniera modulare. Le funzionalità previste da Drizzle, in sè, saranno pochissime; in compenso, molto altro si potrà fare utilizzando i plugin o implementandone di nuovi. Ogni installazione, virtualmente, potrebbe essere complessa il minimo necessario.

Ma Drizzle apparteneva a Sun. Che ne sarà ora? Lo scopriremo tutti nelle prossime puntate.

Nel frattempo, chi usa MySQL può aspettare MariaDB e, appena sarà stabile, iniziare a utilizzarlo. Sarà un’alternativa libera a MySQL, che era è libero solo a livello formale, essendo proprietà di una multinazionale concorrente. Passare a MariaDB però non dovrebbe essere un trauma. Non affezioniamoci ai marchi: le parole e i loghi non sono niente. “Oracle”, “Sun”, “MySQL”, ma anche “MariaDB”, “Drizzle” o perfino “Free Software Foundation” sono solo inutili termini. Possono passare, col tempo: sparire, diventare inutili, diventare nemici della libertà. Chi se ne frega? Possiamo fare a meno delle parole. Della libertà invece no. La libertà è tutto.

Non avevamo ancora finito di imprecare contro Monty Widenius e soci per aver (s)venduto MySQL alla Sun Microsystems. (S)vendita della quale queste persone sono state le prime a pentirsi, visto che Monty ha dovuto lasciare la Sun per avviare una propria società, e che la maggior parte degli sviluppatori principali del progetto abbiano seguito Widenius oppure Brian Aker nel suo fork Drizzle.

Ora dobbiamo incazzarci di nuovo. Ci era passata? Allora siamo stupidi. Perchè quello che è successo ora non è che l’ovvia conseguenza della suddetta svendita. Sun ha speso un sacco di soldi per comprare MySQL, ha licenziato un sacco di dipendenti e ora si (s)vende a un’altra multinazionale un po’ più stabile economicamente. Chi? Ma è ovvio, la concorrenza: Oracle.

Oracle aveva già comprato, anni fa, InnoDB e SleepyCat, che produceva BerkeleyDB. InnoDB ha continuato ad essere un ottimo motore, ma BDB è stato abbandonato da MySQL lasciando in sospeso delle patch utilissime, che erano già state realizzate.

Ora sarà divertente vedere cosa farà la Oracle con MySQL. Prima, su mysql.com, vedevamo un sacco di testimonianze di clienti che sostenevano di aver risparmiato un sacco di soldi e aver ottenuto miracolosi aumenti di performance passando da Oracle a MySQL. Difficilmente la Oracle permetterà che campagne di questo genere proseguano. MySQL è il dbms più diffuso al mondo, un must per chi vuole avere un sito web. Ma non genera che una parte infinitesimale degli introiti generati da Oracle.

Lo sviluppo futuro del dbms libero sarà chiaramente pianificato in modo da invogliare i clienti a passare a Oracle. Le performance di MySQL dovranno per forza di cose essere peggiori. La sua stabilità non potrà mai eguagliare quella di Oracle, sarebbe un suicidio economico. Le funzionalità che Oracle non ha e non vuole avere, non può averle nemmeno MySQL. Quelle che Oracle ha può averle anche MySQL, ma dovrà sempre mancare un qualcosa che si potrà ottenere solo acquistando una licenza Oracle.

Anche Drizzle apparteneva alla Sun e quindi ora appartiene a Oracle. E’ un prodotto diverso da MySQL, non ha le stesse pretese. Di fatto, non è stata rilasciata alcuna versione pubblica. Oracle avrà interesse a finanziare questo progetto ancora in fase embrionale? L’ennesima concorrenza gratuita? Se decideranno di si, le risorse dedicate a questo progetto saranno certamente minori a quelle che Brian Aker sperava di avere fino a qualche mese fa.

Lezione numero 0: fare qualcosa di bello e poi venderlo a una multinazionale è da imbecilli.

Ho già parlato dell’importanza della documentazione Libera. Essa è un componente fondamentale di un programma. Se non so come funziona, non sono libero di usarlo e quindi viene meno la libertà numero 0 e, comunque, ogni sua possibile utilità. Se non posso modificare la documentazione, è molto difficile posso distribuire copie modificate del programma, non posso correggere errori nella documentazione, integrarla, etc. E’ forzato definire libero un programma per il quale non esiste documentazione libera.

La documentazione ufficiale di MySQL, pur essendo famosa per la sua qualità, non è libera. Il fatto che gli utenti possano aggiungere commenti non ha niente a che vedere con la libertà della documentazione stessa.

Recentemente sono nati ben tre fork di MySQL di cui ho già parlato: Drizzle, MariaDB e OurDelta releases for MySQL. La stessa Sun trarra giovamento da questi tre fork, anche perchè la maggior parte degli sviluppatori/architetti più importanti di MySQL ha lasciato il progetto originale

(però!!! è stato un affarone vendere tutto a una multinazionale!!! oltre che una mancanza di rispetto verso tutti quelli che hanno contribuito al progetto negli anni passati!!!).

Però? C’è un però, vero? E certo che c’è un però! Questi fork non potranno trarre giovamento dalla documentazione di MySQL, perchè essa è proprietaria. Per chi non sapesse cosa significa proprietaria: significa che è come Windows, con l’unica differenza che non crasha quando la apri.

Esiste però un progetto su Wikibooks atto a creare una documentazione Libera per MySQL. Il testo è modificabile da chiunque ed è rilasciato con licenza GFDL 1.2 (la licenza di tutti i progetti su Wikibooks). Il tutto è appoggiato anche da Savannah, la forgeria di software libero usata da GNU.

L’invito è:

• Usatela
• Correggete gli errori
• Aggiungete ciò che sapete
• Aggiungete esercizi
• Traducetela in italiano, in spagnolo, in klingon, nel vostro dialetto, insomma in quello che vi pare

Community do it better!!

Voglio parlare di due errori molto banali che possono essere farti in SQL, soprattutto dai principianti. La particolarità di questi due errori, che sicuramente non saranno gli unici nel loro genere, è che sembrano avere un significato e invece ne hanno un altro. Di conseguenza il server (almeno MySQL, usato per provare le sintassi) eseguirà ciò che gli si chiede di fare, che forse non è ciò che si intendeva realmente.

Creiamo la tabella che useremo per il test:

USE test

CREATE TABLE `t1` (
`c1` INT ,
`c2` INT
)

Inseriamo un record che ci servirà:

INSERT INTO t1 VALUES (1, 2)

Fin qui dovrebbe essere andato tutto bene e lo possiamo verificare così:

SELECT * FROM t1

Uso errato di OR

Questo errore non riguarda solo SQL ma un po’ tutti i linguaggi. Esempio:

SELECT * FROM t1 WHERE c1=100 OR 200

Questa query restituirà il record che abbiamo inserito, nonostante c1 non valga 100 nè 200. Perchè? Perchè l’espressione viene valutata così:

SELECT * FROM t1 WHERE (c1=100) OR 200

Qualsiasi valore intero diverso da 0, se convertito in booleano, risulta TRUE. Di conseguenza il risultato di (c1=100) OR 200 non può che essere TRUE.

La sintassi corretta è:

SELECT * FROM t1 WHERE c1=100 OR c1=200

Oppure:

SELECT * FROM t1 WHERE c1 IN (100, 200)

Errore nella UPDATE

Mi è capitato di vedere una istruzione UPDATE scritta in modo sbagliato e un programmatore alle prime armi disperato:

UPDATE t1 SET c1=100 AND c2=200

Questa istruzione cambia il valore del campo c1 di tutti i record in 0, perchè viene valutata così:

UPDATE t1 SET c1=(100 AND c2=200)

100 è sempre TRUE, di conseguenza l’espressione restituisce TRUE (1) se c2=200, altrimenti FALSE (0).

Chiaramente la sintassi esatta è la seguente:

UPDATE t1 SET c1=100, c2=200

Conclusione

Nei casi (rari e non certo “puliti”) in cui il programmatore voglia scrivere le query che qui ho presentato come errori, ottenendo esattamente ciò che il server effettivamente fa, dovrebbe comunque usare le parentesi. Altrimenti l’istruzione risulterà chiarissima per un computer ma un po’ meno per un essere umano.

Oltre ai vari problemi elencati nel post precedente e nel post su Drizzle, l’acquisizione di MySQL da parte di Sun ne ha portato un altro, non meno grave: MySQL Community Edition viene ora rilasciato ogni morte di papa. Chi usa questa edizione (cioè tendenzialmente chi non lavora in un’impresa di un certo livello) è costretto a tenersi i bug per parecchio tempo, anche se magari sono già stati corretti da qualche mese.

OurDelta non è proprio un fork - è piuttosto una serie di rilasci non ufficiali che comprendono aggiunte che sono state apportate dalla comunità. Queste build vengono rilasciate certamente più spesso della Community Edition.

Le aggiunte della comunità riguardano per lo più il motore InnoDB, ma riguardano anche altri settori del server. E’ tutto documentato, compreso il grado di stabilità.

E’ attivo un repository contenente i pacchetti deb e (s)rpm.

Il sito di OutDelta è OurDelta.org

MySQL è sicuramente il più diffuso Dbms (DataBase Management System) libero e open source. Storicamente si contendeva gli utenti con PostgreSQL, che era comunque molto diverso. Mentre quest’ultimo era (ed è a maggior ragione oggi) avanzatissimo, estendibile in molti modi e adatto a progetti che richiedono notevoli prestazioni e una notevole complessità, MySQL si manteneva leggero e facile da usare. Il suo codice era pulito, relativamente pochi i bug. Per un progetto di piccole (non per forza piccolissime) dimensioni era spesso la scelta migliore. Molte erano le funzionalità lasciate fuori (viste, stored procedure, trigger…), ma la maggioranza degli utenti non ne aveva bisogno. Chi ne aveva bisogno, naturalmente, doveva dirigersi verso altri lidi.

A partire dalla versione 4.1, la filosofia di MySQL è molto cambiata. Ha iniziato a implementare funzionalità a volte molto complesse, di cui la maggioranza degli utenti non aveva e non ha bisogno. Queste funzionalità aggiungono molto codice al programma, questo codice si porta dietro inevitabilmente: pesantezza, peggioramento delle prestazioni, aumento del consumo di risorse, bug, difficoltà nella programmazione e nella manutenzione. Per quella grande fetta di utenti che utilizza solo funzionalità introdotte prima della versione 4.1, tutto ciò è abbastanza seccante. Non solo: a partire dalla versione 5.0 la qualità del codice è peggiorata tremendamente. Questa versione è stata rilasciata con numerosi bug critici (che provocano il crash) ed era molto lenta rispetto alla 4.1.

Per questo motivo è nato un fork chiamato Drizzle, che comprende solo le funzionalità indispensabili (il codice vecchio è stato quasi completamente… eliminato dal fork, mentre il rimanente è stato risistemato per migliorarne la qualità), però molte funzionalità vengono reimplementate come plugin. In altre parole chi le vuole usare le attiva, gli altri utilizzano solo il codice di cui hanno effettivamente bisogno. Di tutto ciò parlo in maniera più approfondita in questo articolo.

Nel gennaio 2007 MySQL è stato venduto alla Sun Microsystem. Un pessimo affare per entrambi. Per la Sun perchè quest’anno ha annunciato il licenziamento di migliaia di lavoratori: forse quel miliardo di dollari sarebbe stato speso meglio se usato per pagare gli stipendi di esseri umani, piuttosto che la proprietà immateriale di un marchio. Per MySQL perchè da piccola società in cui tutti si conoscono, è diventata una divisione di una multinazionale, in cui forse tutti si conoscono ma certo non conoscono coloro che prendono le decisioni importanti.

Michael Widenius, detto Monty, il fondatore di MySQL, ha lasciato la Sun per mettersi in proprio. Dice di essere comunque contento di aver venduto la società alla Sun… come diceva quella canzone? Ah, si: “parole, parole, parole…”. Uscendo, si è potuto prendere la soddisfazione di rivelare al pubblico un po’ di idiozie commesse dalla Sun.

Prima di tutto la versione 5.1 non è stabile. Le nuove funzionalità sarebbero affette da bug gravi, a volte critici. Questo sarebbe avvenuto perchè è stata dichiarata “beta” quando ancora era in uno stato molto embrionale; dopodichè, sono state rilasciate meno versioni di quanto sarebbe stato necessario, perciò gli utenti non hanno testato il codice a sufficienza. Ma quel che è peggio è che non è stato un errore: è stata una scelta di marketing. La Sun ha pensato che rilasciando troppe versioni beta avrebbero fatto brutta figura. Personalmente ritengo che la brutta figura l’abbiano fatta così, dimostrando la totale incapacità di prendere decisioni sensate.

Insomma Monty, stando a quanto afferma, avrebbe chiesto a più riprese che il modo di lavorare della divisione MySQL cambiasse. In particolare, sostiene, lui avrebbe voluto che il processo di sviluppo fosse più aperto ai volontari esterni. Ciò lascia un po’ perplessi, sapendo che tale processo è sempre stato piuttosto chiuso, fin dagli albori di MySQL. In ogni caso, ora il progetto principale a cui Monty si sta dedicando sarebbe un fork chiamato MariaDB.

MariaDB importerà, man mano, tutte le nuove modifiche che la Sun apporterà al codice di MySQL. Queste modifiche però saranno testate e migliorate da MariaDB. Inoltre si concentreranno soprattutto sullo storage engine Maria. Per chi non lo sapesse, si tratta di una sorta di riscrittura di MyISAM, progettato per essere a prova di crash e per supportare (opzionalmente) le transazioni. Il locking è gestito a livello di pagina, non di riga come in MyISAM. Rinunciando ad alcune funzionalità di Maria è comunque possibile utilizzare gli stessi formati usati da MyISAM (dynamic, fixed, compressed). Maria sarà presente anche in MySQL 6, però tutto lascia pensare che sarà supportato meglio nel fork MariaDB.

La gestione di MariaDB dovrebbe essere molto più aperta ai contributi esterni, così come lo è Drizzle. Entrambi infatti sono progetti ospitati da Launchpad.

A titolo di curiosità… gli altri progetti a cui Monty si sta dedicando sono: OpenOcean (una società che finanzia software libero, cbe esisteva già) e un ristorante che utilizzerebbe i database per migliorare l’esperienza del cliente… qualunque cosa ciò significhi.

Link per approfondimenti

Drizzle

• Drizzle.Org
• Wiki in italiano
• Blog di Brian Aker (fondatore di Drizzle)
• Progetto su Launchpad

MariaDB

• Ask Monty
• Monty Says (blog)
• Documentazione di Maria
  
• Progetto su LaunchPad