Ai tempi in cui qualcuno diceva MySQL, c'era solo MySQL. Potresti scegliere versioni diverse (4.0, 4.1) ma il fornitore era lo stesso. Questo è cambiato intorno a MySQL 5.0/5.1 quando Percona ha deciso di rilasciare la propria versione di MySQL - Percona Server. Poco dopo, MariaDB si è unita a MariaDB 5.1 e il divertimento (o la confusione) è aumentato. Quale versione dovrei usare? Qual è la differenza tra MySQL 5.1, Percona Server 5.1 e MariaDB 5.1? Quale è più veloce? Quale è più stabile? Quale ha una funzionalità superiore? Con il tempo, questo è peggiorato poiché sono stati introdotti sempre più cambiamenti in ciascuno dei gusti. Questo post sul blog sarà il nostro tentativo di riassumere le caratteristiche chiave che li differenziano. Cercheremo anche di darvi alcuni suggerimenti su quale sapore potrebbe essere il migliore per un determinato tipo di progetto. Iniziamo.
Oracle MySQL
Prima era MySQL, ora è a monte. La maggior parte dello sviluppo inizia qui, ogni versione a partire dalla 5.6 risolve alcune controversie interne e offre prestazioni migliori. Nuove funzionalità vengono anche aggiunte regolarmente. MySQL 5.6 ci ha portato (tra gli altri) GTID e un'implementazione iniziale della replica parallela. Ci ha anche dato la possibilità di eseguire la maggior parte degli ALTER in modo online. Diamo un'occhiata alle funzionalità dell'ultima versione di MySQL:MySQL 5.7
Caratteristiche di MySQL 5.7
Uno dei cambiamenti principali sono i cambiamenti nel processo di distribuzione:invece di script diversi, puoi semplicemente eseguire mysqld --initialize per configurare MySQL da zero. Un altro cambiamento molto importante:la replica parallela basata sull'orologio logico. Infine, possiamo utilizzare la replica parallela in tutti i casi, indipendentemente dal fatto che utilizzi più schemi o meno. Un altro miglioramento della replica è la replica multi-sorgente:uno slave 5.7 può avere più master:è un'ottima funzionalità se si desidera creare uno slave di aggregazione e, diciamo, combinare dati da più cluster separati.
InnoDB ha iniziato a supportare i tipi spaziali, il pool di buffer InnoDB può finalmente essere ridimensionato in fase di esecuzione, gli ALTER online sono stati migliorati per supportare più casi come il partizionamento e gli ALTER no-op.
MySQL ha iniziato a supportare i tipi di dati JSON in modo nativo insieme a diverse nuove funzioni incentrate sull'aggiunta di funzionalità attorno a JSON. La sicurezza dei tuoi dati è molto importante in questi giorni, MySQL 5.7 supporta la crittografia dei dati inattivi per i tablespace file per tabella. Sono stati aggiunti anche alcuni miglioramenti al supporto SSL (SSL verrà configurato se le chiavi sono presenti, è incluso uno script che può essere utilizzato per creare certificati). Dal punto di vista della gestione degli utenti, è stata aggiunta la configurazione della durata della password che dovrebbe rendere un po' più semplice la progettazione delle politiche di scadenza delle password.
Un'altra funzionalità che ha lo scopo di assistere i DBA è lo schema "sys", un insieme di viste progettate per semplificare l'uso dello schema delle prestazioni. È stato incluso per impostazione predefinita in MySQL 5.7.
Infine, MySQL Group Replication (e infine MySQL InnoDB Cluster) è stato aggiunto a MySQL 5.7. Funziona come un plug-in ed è incluso nelle versioni recenti del ramo 5.7, ma questo è un argomento a sé stante. In breve, Group Replication consente di creare un cluster sincrono “virtualmente”.
Questo non è sicuramente un elenco completo di funzionalità:se sei interessato a tutte, puoi consultare la documentazione di MySQL 5.7.
Server Percona
All'inizio, c'era una serie di patch da applicare al codice sorgente di MySQL che aggiungeva alcuni miglioramenti delle prestazioni e delle funzionalità. Ad un certo punto, Percona ha deciso di rilasciare la propria build di MySQL che includeva queste patch. Col tempo sono diventate disponibili più risorse di sviluppo, quindi sono state aggiunte sempre più funzionalità.
In generale, è possibile visualizzare Percona Server come l'ultima versione di MySQL con più patch/miglioramenti. Con il tempo, alcuni dei miglioramenti delle funzionalità di Percona Server vengono sostituiti da funzionalità a monte, ogni volta che Oracle sviluppa una funzionalità che sostituisce una delle funzionalità aggiunte in Percona Server. Finché l'implementazione è alla pari, Percona rimuove il proprio codice a favore del codice dall'upstream. Questo rende Percona Server fondamentalmente un sostituto drop-in per MySQL di Oracle. Una delle aree in cui sono stati apportati importanti miglioramenti alle prestazioni è InnoDB. È stato modificato in modo abbastanza significativo da marchiarlo come XtraDB. Attualmente è completamente compatibile con InnoDB ma non è sempre stato così. Ad esempio, alcune funzionalità di Percona Server 5.5 non erano compatibili con MySQL 5.5. Vale anche per le versioni più recenti di Percona Server. L'importante è che, per impostazione predefinita, Percona Server viene fornito con tutte le funzionalità incompatibili disabilitate:semplifica il test e il rollback a MySQL di Oracle, se necessario. Tenendo conto di quanto sopra, dovresti comunque prestare attenzione quando prevedi di migrare da Percona Server a MySQL:qualcuno potrebbe aver abilitato una delle funzionalità incompatibili.
Ciò che vale la pena sottolineare è che Percona si sforza di reimplementare le funzionalità aziendali dell'upstream. Nel caso di MySQL, esempi sono l'implementazione di un pool di thread o di un plug-in di autenticazione PAM. Diamo una rapida occhiata ad alcune delle funzionalità di Percona Server.
Caratteristiche di Percona Server 5.7
Una delle caratteristiche principali di XtraDB è la migliore scalabilità del pool di buffer:anche se ci sono sempre meno contese a causa del lavoro svolto da Oracle su ogni versione di MySQL, il team di ingegneri di Percona si impegna a spingere ulteriormente le prestazioni e rimuovere mutex aggiuntivi che potrebbero limitare le prestazioni. Inoltre, più dati vengono scritti nel monitor InnoDB (accessibile tramite SHOW ENGINE INNODB STATUS) per quanto riguarda le contese all'interno di InnoDB, ad esempio è stata aggiunta una sezione sui semafori.
Un'altra serie di miglioramenti è stata apportata nell'area dell'I/O. In InnoDB, puoi impostare un metodo flush solo per i tablespace InnoDB e questo provoca il doppio buffering per i redo log di InnoDB. XtraDB permette di usare O_DIRECT anche per quei file. Aggiunge inoltre più dati relativi al checkpoint all'output di SHOW ENGINE INNODB STATUS. In aggiunta a ciò, sono stati implementati buffer a doppia scrittura parallela e flusher LRU multi-thread per ridurre i conflitti nelle operazioni di I/O all'interno di InnoDB.
Il pool di thread è un'altra funzionalità resa disponibile da Percona Server. In Oracle MySQL è disponibile solo nell'edizione Enterprise. Qui puoi utilizzare gratuitamente l'implementazione di Percona. In generale, il pool di thread riduce i conflitti mentre serve un numero elevato di connessioni dall'applicazione riutilizzando le connessioni esistenti al database.
Altre due funzionalità sostituiscono direttamente le funzionalità della versione Enterprise di MySQL. Uno di questi è il plug-in di autenticazione PAM che è stato sviluppato da Percona ed è progettato per consentire l'uso di numerose opzioni di autenticazione diverse come LDAP, RSA SecurID o qualsiasi altro metodo supportato da PAM. La seconda funzionalità è anche correlata alla sicurezza:plug-in del registro di controllo. Creerà un file con un record delle azioni intraprese sul server del database.
Di tanto in tanto, Percona introduce miglioramenti significativi ad altri motori di archiviazione come le modifiche apportate al motore MEMORY che consentivano l'utilizzo di dati di tipo VARCHAR o BLOB.
Anche l'introduzione dei blocchi di backup è stato un miglioramento piuttosto significativo. In Oracle e MariaDB l'unico metodo per bloccare la tabella per ottenere un backup coerente era utilizzare FLUSH TABLES WITH READ LOCK (FTWRL). È piuttosto pesante e costringe MySQL a chiudere tutte le tabelle aperte. I blocchi di backup, d'altra parte, utilizzano un approccio più leggero ai blocchi dei metadati. In molti casi di server con carichi pesanti che eseguono FTWRL impiega troppo tempo (e blocca il server troppo a lungo) per essere considerato fattibile mentre i blocchi di backup consentono di eseguire un backup utilizzando mysqldump o xtrabackup.
Percona è aperto anche per il porting di funzionalità di altri fornitori. Uno di questi esempi è il porting di START TRANSACTION WITH CONSISTENT SNAPSHOT di MariaDB. Questa funzione è anche correlata ai backup:con il suo aiuto, puoi eseguire un backup logico coerente (usando mysqldump) senza eseguire FLUSH TABLE CON READ LOCK.
Infine, tre caratteristiche che migliorano l'osservabilità:la prima:le statistiche degli utenti. Questa è una funzione abbastanza leggera che raccoglie dati su utenti, indici, tabelle e thread. Ti consente di trovare indici inutilizzati o determinare quale utente è responsabile del carico sul server. Attualmente è parzialmente ridondante per performance_schema ma è un po' più leggero ed è stato creato ai tempi di MySQL 5.0 - 5.1, dove nessuno si sognava nemmeno performance_schema.
Secondo:registro delle query lente migliorato. Ancora una volta, è stato aggiunto nei momenti in cui la granularità massima di long_query_time era di 1 secondo. Con questa aggiunta avevi una granularità di microsecondi e una serie di dati aggiuntivi sulle statistiche di InnoDB per query o sulle sue caratteristiche di prestazioni complessive. Ha creato una tabella temporanea? Ha usato un indice? È stato memorizzato nella cache delle query MySQL?
Terza caratteristica che abbiamo menzionato un paio di volte sopra:Percona Server espone significativamente più dati in SHOW ENGINE INNODB STATUS rispetto a monte. Aiuta sicuramente a comprendere meglio il carico di lavoro e rilevare più problemi prima che si manifestino.
Naturalmente, questo non è un elenco completo:se sei interessato a maggiori dettagli, puoi consultare la documentazione di Percona Server.
MariaDB
MariaDB è nata come un fork di MySQL ma, con l'ingresso di una parte del team di sviluppo originale di MySQL in MariaDB, si è rapidamente concentrata sull'aggiunta di funzionalità. In MariaDB 5.3, molte funzionalità sono state aggiunte all'ottimizzatore:Batch Key Access, MultiRange Read, Index Condition Pushdown solo per citarne alcuni. Ciò ha consentito a MariaDB di eccellere in alcuni carichi di lavoro in cui MySQL o Percona Server avrebbero avuto difficoltà. Finora, alcune di queste funzionalità sono state aggiunte a MySQL (principalmente in MySQL 5.6), ma alcune sono ancora esclusive di MariaDB.
Un'altra caratteristica importante introdotta da MariaDB è stata l'ID transazione globale. Non molto tempo dopo Oracle ha rilasciato la propria implementazione, ma MariaDB è stata la prima ad averla. Una storia simile è con un'altra funzionalità di replica:replica multisorgente:MariaDB lo aveva prima di Oracle. Ora, MariaDB 10.2 recentemente rilasciato contiene anche funzionalità che saranno rese disponibili in MySQL 8.0, che è ancora in fase di sviluppo. Stiamo parlando, ad esempio, di espressioni di tabelle comuni ricorsive o di funzioni di finestra.
Caratteristiche di MariaDB 10.2
Come accennato, MariaDB 10.2 introduce funzioni di finestra ed espressioni di tabelle comuni ricorsive:miglioramenti in SQL che dovrebbero aiutare gli sviluppatori a scrivere query SQL più efficienti.
Un cambiamento molto importante è che MariaDB 10.2 utilizza InnoDB. Fino alla versione 10.1, XtraDB è stato utilizzato come storage predefinito. Questo, sfortunatamente, rende le funzionalità aggiunte nell'ultimo XtraDB non disponibili per gli utenti di MariaDB 10.2.
Sono stati apportati miglioramenti alle colonne virtuali:altre limitazioni sono state eliminate in 10.2.
Infine, è stato aggiunto il supporto per più trigger per lo stesso evento:ora puoi crearne diversi, ad esempio ON UPDATE sulla stessa tabella.
Gli sviluppatori dovrebbero beneficiare del supporto JSON, insieme a un paio di funzioni ad esso correlate. Dovrebbero anche apprezzare le nuove funzioni che consentono loro di esportare dati spaziali in formato GeoJSON. Parlando di JSON, sono stati apportati miglioramenti nell'output EXPLAIN FORMAT=JSON - vengono mostrati più dati.
Sul fronte della sicurezza, è stato aggiunto il supporto per OpenSSL 1.1 e LibreSSL.
Naturalmente, questo elenco non è completo e se sei interessato a ciò che è stato aggiunto a MySQL 10.2, puoi consultare la documentazione.
Oltre alle nuove funzionalità, MariaDB 10.2 beneficia delle funzionalità implementate nelle versioni precedenti. Analizzeremo i più importanti.
Le caratteristiche più importanti di MariaDB 10.1
Prima di tutto, MariaDB dalla 10.1 viene fornito in bundle con il cluster Galera:non è necessario installare librerie aggiuntive, tutto è pronto per l'uso.
MariaDB 10.1 ha portato l'implementazione della crittografia dei dati inattivi. Rispetto alla funzionalità implementata in MySQL di Oracle, MariaDB l'ha più estesa. Non solo crittografa i tablespace, ma crittografa anche i registri di ripristino, i file temporanei e i registri binari. Ciò comporta alcuni problemi:strumenti CLI come mysqldump o xtrabackup non possono accedere ai log binari e potrebbero avere problemi con il backup di istanze crittografate (questo è particolarmente vero per xtrabackup - abbastanza recentemente MariaDB ha creato un fork di xtrabackup chiamato MariaDB Backup che supporta i dati inattivi crittografia).
Ok, quindi quale aroma dovrei usare?
Come di consueto, la risposta corretta sarebbe:“Dipende” :-) . Condivideremo un paio delle nostre osservazioni che potrebbero aiutarti o meno a decidere, ma, alla fine, spetta a te eseguire i benchmark e trovare l'opzione che funzionerà meglio per il tuo ambiente e la tua applicazione.
Prima di tutto, parliamo del flusso. Oracle rilascia una nuova versione, diciamo MySQL 5.7. Per quanto riguarda le prestazioni, in quel momento, questo è il gusto MySQL più veloce sul mercato. Questo perché solo Oracle ha risorse sufficienti per lavorare sul miglioramento di InnoDB in tale misura. Entro un paio di mesi (in caso di 5.7, erano 4 mesi) Percona rilascia Percona Server 5.7 con la loro serie di miglioramenti:a seconda del tipo di carico di lavoro, potrebbe fornire prestazioni anche migliori rispetto all'upstream. Infine, MariaDB adotta la nuova versione upstream e costruisce la sua nuova versione su di essa.
Ecco come appariva in un calendario (stiamo ancora parlando di MySQL 5.7).
MySQL 5.7 GA:21 ottobre 2015
Percona Server 5.7 GA:23 febbraio 2016
MariaDB 10.2 GA:23 maggio 2017
Si prega di notare quanto tempo ha impiegato MariaDB per rilasciare una versione basata su MySQL 5.7:tutte le versioni precedenti erano basate su MySQL 5.6 e, ovviamente, fornivano prestazioni inferiori a MySQL 5.7. D'altra parte, MariaDB 10.2 è stato rilasciato con InnoDB che sostituisce XtraDB. Sebbene sia vero che Oracle ha per lo più colmato il divario di prestazioni tra MySQL e Percona Server, è ancora solo "principalmente". Di conseguenza, MariaDB 10.2 può fornire prestazioni inferiori a quelle di Percona Server in alcuni casi (e migliori in altri casi, a causa del lavoro di ottimizzazione svolto in MariaDB 5.3, alcuni dei quali non sono stati ancora ricreati in MySQL).
Dal punto di vista delle funzionalità, è più complesso. MariaDB ha aggiunto molte funzionalità, quindi se sei interessato ad alcune di esse, potresti sicuramente prendere in considerazione l'utilizzo di MariaDB. C'è anche un aspetto negativo. Percona Server aveva molte caratteristiche che lo differenziavano da MySQL upstream, ma quando Oracle ha iniziato a implementarle in MySQL, Percona ha deciso di deprezzare le loro implementazioni a favore dell'utilizzo dell'implementazione da upstream. Ciò ha ridotto la quantità di codice diverso tra MySQL e Percona Server, semplifica la manutenzione del codice di Percona Server e, cosa più importante, rende Percona Server compatibile al 100% con MySQL.
Questo, sfortunatamente, non è vero per MariaDB. MariaDB ha introdotto per prima GTID, è vero, ma dopo che Oracle ha sviluppato la propria versione di GTID, MariaDB ha deciso di attenersi alla propria implementazione. Questo blog non è il luogo in cui decidere quale implementazione è migliore, ma di conseguenza dobbiamo gestire due sistemi GTID diversi e incompatibili:aggiunge onere a qualsiasi strumento che gestisce la replica e riduce l'interoperabilità. Attenersi alla replica - commit di gruppo e replica parallela:sia Oracle che MariaDB hanno la propria implementazione e se si lavora con entrambi, è necessario impararli entrambi per applicare l'ottimizzazione richiesta - le manopole sono diverse e funzionano in modo diverso. Un caso simile è con il supporto delle colonne virtuali:due implementazioni diverse, non compatibili al 100% che, di conseguenza, non hanno reso possibile scaricare facilmente i dati da MariaDB e caricarli in MySQL di Oracle (e viceversa) perché la sintassi è leggermente diversa. Quindi, se dovessi decidere di utilizzare una versione di MariaDB per alcune nuove funzionalità, potresti finire per rimanere bloccato anche se desideri migrare di nuovo a MySQL per utilizzare l'implementazione di Oracle. Nella migliore delle ipotesi, l'esecuzione della migrazione richiederebbe uno sforzo molto maggiore. Naturalmente, se rimani sempre in un unico ambiente, potrebbe non influire gravemente su di te. Ma anche allora, una mancanza di compatibilità sarà evidente per te, se non altro mentre leggi blog su Internet e trovi soluzioni che non sono realmente applicabili al tuo gusto di MySQL.
Quindi, per riassumere, se sei interessato a mantenere la compatibilità con MySQL, Percona Server (o MySQL stesso, ovviamente) sarebbe probabilmente la strada da percorrere. Se sei interessato alle prestazioni, fintanto che Percona Server è basato sull'ultimo MySQL, potrebbe essere la strada da percorrere. Naturalmente, potresti voler confrontare MariaDB e vedere se il tuo carico di lavoro non può beneficiare di alcune delle ottimizzazioni che sono ancora uniche per MariaDB. Dal punto di vista operativo, probabilmente è bene attenersi a uno degli ambienti (Oracle/Percona o MariaDB), a seconda di quale funzionerebbe meglio per te. MySQL o Percona Server hanno il vantaggio di essere usati più comunemente ed è leggermente più facile integrarli con strumenti esterni (perché non tutti gli strumenti supportano tutte le funzionalità di MariaDB). Se potresti trarre vantaggio da una nuova e brillante funzionalità che è stata appena implementata in MariaDB, dovresti prenderla in considerazione, tenendo presente eventuali problemi di compatibilità e possibili prestazioni inferiori.
Ci auguriamo che questo post sul blog ti abbia dato alcune idee sulle diverse scelte che abbiamo nel mondo MySQL e su diverse angolazioni da cui puoi confrontarle. Alla fine della giornata, sarà tuo compito decidere cosa è meglio per la tua configurazione. Potrebbe non essere facile, ma dovremmo comunque essere grati di avere una scelta e di poter scegliere ciò che funziona meglio per noi.
