Indice dei contenuti dell'articolo:
Se c’è una cosa che mi è rimasta a mente nello staging che feci in quinto superiore (ben 23 anni fa) alla Elettromeccanica Cognigni di Civitanova Marche, fu queste poche ma significante parole “I giusti attrezzi sono già metà del lavoro“.
Questa frase fu pronunciata dal nonno di un mio caro amico, che era solito venire a trovare il titolare dell’azienda e curiosare o parlare del più o del meno, come sono soliti fare gli anziani che hanno tempo durante la giornata per coltivare le loro amicizie e fare visite qua e là.
Io ero impegnato a svuotare un indotto di un motore elettrico (un avvolgimento elettrico) battendo lo scalpello con una pinza rimediata, quando sentii queste parole altisonanti e fui successivamente invitato ad usare un martello.
Lavoro più preciso, più veloce e più confortevole. Da li a poche settimane, sarebbe finito lo stage scolastico e avrei terminato questa esperienza a contatto di accumulatori, avvolgimenti, motori elettrici, e simili, lasciando nel dimenticatoio molte delle nozioni apprese in modalità “usa e getta”, tuttavia quel prezioso consiglio e quella solenne frase pronunciata ad effetto è ancora oggi uno dei capisaldi della mia professione, e più ampiamente del mio modo di vivere.
Potremmo mangiare la minestra con la forchetta, ma sicuramente un cucchiaio è meglio.
Il problema delle applicazioni che usano MySQL
C’è un problema che riguarda tutti o quasi, principalmente riguardano tutte quelle situazioni in cui si ha a che fare con software scritto da altri che fa utilizzo di un Database MySQL o relativi fork come MariaDB, Percona Server, che sono comunque basati e derivati da MySQL stesso.
Quando si lavora con CMS come WordPress, WooCommerce, Magento, Prestashop e simili, alla fine ci si ritrova sempre ad avere a che fare con un RDBMS come MySQL o derivato, e sembra che sia normale, giusto e corretto disporre di un RDBMS che sembra anche estremamente veloce e performante.
Il problema non è un gran problema nel momento in cui il database non diventa il collo di bottiglia della nostra applicazione, e delle performance che si riflettono inevitabilmente sull’esperienza utente, sulla SEO, sul fatturato e sull’utile aziendale.
Per quanto possa aver migliorato sensibilmente nel corso degli anni la velocità e le performance di MySQL, ad esempio passando dal vecchio motore MyISAM a InnoDB bisogna sempre chiedersi se MySQL (o relativi fork) sia la migliore soluzione sul mercato in termini di feature, performance e velocità.
MySQL è estremamente lento rispetto a PostgreSQL
Ad esempio, se stessimo cercando un RDBMS compatibile con SQL Standard che sia open source, gratuito, free, ben supportato e documentato, multi architettura, portabile, estremamente performante, andremo sicuramente ad escludere soluzioni closed source commerciali e proprietarie come Oracle DB, SQL Server o DB2 di IBM.
Tuttavia, potremmo e dovremo tenere in considerazione PostgreSQL o semplicemente Postgres.
PostgreSQL è un potente sistema di database relazionale a oggetti open source con oltre 35 anni di sviluppo attivo che gli è valso una solida reputazione per affidabilità, robustezza delle funzionalità e prestazioni.
Noto anche come Postgres , è un sistema di gestione di database relazionale gratuito e open-source ( RDBMS) enfatizzando l’estensibilità e la conformità SQL. Originariamente era chiamato POSTGRES, in riferimento alle sue origini come successore del database Ingres sviluppato presso l’ Università della California, Berkeley . Nel 1996, il progetto è stato rinominato in PostgreSQL per riflettere il suo supporto per SQL . Dopo una revisione nel 2007, il team di sviluppo ha deciso di mantenere il nome PostgreSQL e l’alias Postgres.
PostgreSQL presenta transazioni con proprietà Atomicity, Consistency, Isolation, Durability (ACID), viste aggiornabili automaticamente , viste materializzate , trigger , chiavi esterne e stored procedure . È progettato per gestire una vasta gamma di carichi di lavoro, da singole macchine a data warehouse o servizi Web con molti utenti simultanei . È il database predefinito per macOS Server ed è disponibile anche per Windows , Linux ,FreeBSD e OpenBSD .
Ma quanto è lento MySQL rispetto a PostgreSQL?
O meglio, quanto è più veloce PostgreSQL rispetto a MySQL ?
Come ho eseguito il benchmark dei database?
Fare il benchmark di un database può essere una cosa complicata. Basta guardarsi intorno in Internet. Ci sono benchmark diversi, che misurano cose diverse, a volte parametri, che non ti dicono nulla di significativo.
Dal mio punto di vista, vedo il database come qualcosa che corrisponde esattamente al suo nome. Una base per un file . Niente di più. Quindi nessuna logica dell’applicazione nel database. Il database dovrebbe contenere i dati ed eseguire due operazioni principali il più rapidamente possibile: leggere e scrivere .
Vedo read come qualcosa che non cambia il database e scrivo come qualcosa che cambia il database. Per me, l’eliminazione e l’aggiornamento sono entrambi sottoinsiemi di scrittura.
Inoltre, quando leggo dal database, tendo a rendere il mio selectsil più semplice possibile. Non uso join su join su join su join. Preferisco leggere più tabelle diverse il più velocemente possibile e quindi elaborare i dati al di fuori del database. Ma io uso max, avge minmolto sum. Uso molto le cose semplici e le cose complicate il meno possibile.
Dal mio punto di vista, il mio database ideale dovrebbe essere canticchiato con calma tutto il tempo, servendo letture e scritture il più rapidamente possibile. Niente di più.
Quando ho deciso di fare il mio punto di riferimento stavo cercando tre cose:
- Quale database ha le scritture più veloci
- Quale database ha le letture più veloci
- Quale database ha il minore utilizzo di memoria e CPU
Preparazione
Come ho fatto il mio benchmark due anni fa nel 2019 (che ha portato al passaggio a PostgreSQL), sarà saggio ripeterlo ora, nel 2021.
All’inizio, dobbiamo eseguire tutti i database, vogliamo eseguire il benchmark. Possiamo eseguire tutti i principali database in Docker con i comandi (e un po’ più di informazioni) da questo articolo, ma trovi tutti quei comandi qui sotto.
Ho aggiunto alcune forcelle popolari di tutte e tre le principali famiglie di motori.
Famiglia di motori Postgres: PostgreSQL, TimescaleDB
Famiglia di motori MySQL: MySQL, MariaDB, Percona
Famiglia di motori Microsoft SQL Server: SQL Server
Ecco i comandi Docker per eseguire tutti i database che dobbiamo testare.
PostgreSQL
docker run --name postgres -e POSTGRES_PASSWORD=password -p 5433:5432 -v postgres_data:/var/lib/postgresql/data -d postgres:alpine Timescale DB
docker run --name timescale -e POSTGRES_PASSWORD=password -p 5434:5432 -v timescale_data:/var/lib/postgresql/data -d timescale/timescaledb:latest-pg12 MySQL
docker run --name mysql -e MYSQL_ROOT_PASSWORD=password -p 3306:3306 -v mysql_data:/var/lib/mysql -d mysql:latest MariaDB
docker run --name mariadb -e MYSQL_ROOT_PASSWORD=password -p 3307:3306 -v mariadb_data:/var/lib/mysql -d mariadb:latest Percona Server
docker run --name percona -e MYSQL_ROOT_PASSWORD=password -p 3308:3306 -v percona_data:/var/lib/mysql -d percona:ps-8 Sfortunatamente, grazie all’EULA di Microsoft per SQL Server 2019, non è possibile presentare benchmark per SQL Server, ma posso dirti che è un peccato. Devi fare i tuoi benchmark da solo.
Primo confronto
A questo punto, dovresti avere tutti e sei i database in esecuzione. Tutti e sei nei loro stati predefiniti. Nessuna messa a punto.
Possiamo fare il nostro primo confronto. Possiamo confrontare le dimensioni dell’immagine del database, l’utilizzo iniziale della memoria in Docker e l’utilizzo iniziale della CPU.
Da questi risultati, sembra che PostgreSQL sia il vincitore e SQL Server il perdente. Ma non abbiamo ancora fatto alcun benchmark di lettura e/o scrittura.
Benchmark di scrittura.
Per scrivere benchmark, ho sviluppato un semplice programma Go (repository github alla fine dell’articolo). Questo programma crea una tabella chiamata benchmark_datacon 6 colonne. È necessario creare il database benchmarkmanualmente utilizzando create database benchmark.
Questo programma inserisce 10.000 righe in questa tabella, una per una. Nessun inserimento batch, solo semplici inserti.
Il benchmark verrà eseguito su Macbook Pro 2019, con desktop Docker in esecuzione, tutte le applicazioni non necessarie vengono chiuse.
Questa prima parte del benchmark misurerà il tempo, ci vorranno quegli inserti per completare. Dal mio punto di vista, il tempo rispetto a qualche operazione è l’unica misura ragionevole che si possa fare. Alla fine, vuoi sempre sapere quanto tempo ci vuole o quanto è stato fatto in un tempo specificato.
In questo benchmark, ho eseguito 5 batch di inserimento consecutivi, ciascuno di 10.000 righe. Chiaramente, PostgreSQL è il vincitore e Percona è il perdente.
PostgreSQL è circa due volte più veloce di Percona, in caso di inserimenti. Ciò che mi colpisce qui è la differenza tra MariaDB e MySQL, perché entrambi appartengono alla stessa famiglia di motori. Sembra che le persone dietro MariaDB abbiano fatto qualche magia.
Una semplice conclusione: la famiglia di motori Postgres è circa il doppio più veloce della famiglia di motori MySQL, ad eccezione di MariaDB.
Benchmark di lettura.
Questo benchmark di lettura è stato fatto in questo modo: 2 000 cicli con due letture in ogni ciclo: averagee sumdi datacolonna. Ancora una volta, ho fatto tutto 5 volte.
Di seguito i risultati. PostgreSQL è il vincitore, Percona è il perdente. MariaDB è seconda peggio.
La famiglia di motori Postgres è circa due volte più veloce della famiglia di motori MySQL.
Perché MySQL è più utilizzato e diffuso di PostgreSQL ?
MySQL è uno dei sistemi di gestione di database più diffusi al mondo, nonostante le sue prestazioni non siano paragonabili a quelle di altri database come PostgreSQL. Ci sono diverse motivazioni per cui MySQL è più diffuso rispetto a PostgreSQL, nonostante le prestazioni di quest’ultimo siano superiori.
Innanzitutto, MySQL ha una storia più lunga rispetto a PostgreSQL e quindi ha avuto più tempo per diffondersi e diventare popolare. MySQL è stato rilasciato per la prima volta nel 1995, mentre PostgreSQL è stato rilasciato nel 1996. Ciò significa che MySQL ha avuto un anno in più per diffondersi e diventare conosciuto dai programmatori e dai professionisti del settore.
Inoltre, MySQL è spesso incluso come componente predefinito in molti sistemi operativi e stack di sviluppo, il che lo rende facilmente accessibile a chiunque abbia bisogno di un database. Inoltre, MySQL ha una documentazione molto ampia e una forte presenza online, il che lo rende facile da imparare e da utilizzare per i programmatori alle prime armi.
Infine, MySQL è spesso scelto dalle aziende a causa della sua semplicità e della sua capacità di gestire grandi quantità di dati. MySQL non richiede conoscenze avanzate di amministrazione di sistema per essere utilizzato e può gestire facilmente grandi quantità di dati, il che lo rende ideale per le aziende che hanno bisogno di un database scalabile e facile da gestire.
Impatto sull’ambiente di PostgreSQL rispetto a MySQL.
Utilizzare PostgreSQL invece di MySQL potrebbe avere un impatto positivo sull’ambiente. PostgreSQL è noto per la sua efficienza e velocità, il che significa che può gestire grandi quantità di dati con un consumo di risorse inferiore rispetto a MySQL. Ciò può portare a una riduzione delle emissioni di CO2, poiché i server utilizzeranno meno energia per eseguire le stesse operazioni.
L’utilizzo di PostgreSQL piuttosto che MySQL potrebbe significare ad esempio ridurre il numero dei server all’interno di un’organizzazione, evitare l’utilizzo di Cluster MySQL per sopperire problematiche di performance, nonché evitare un ricambio o un upgrade dell’hardware sia per lo scaling verticale (aumento delle risorse sulla singola macchina), sia per lo scaling orizzontale, ovvero aumentare nodi e macchine.
Conclusioni.
Abbiamo visto come in base ai benchmark sopra citati PostgreSQL sia decisamente migliore e più consigliato per una serie di vantaggi sia in termini di performance e velocità che nell’utilizzo più efficiente della memoria, senza per questo dover rinunciare all’open source o un sistema di licenza libera che permette di adottarlo senza vincoli alcuni a software ed applicazioni gratuite.
Viene dunque da chiedersi come mai e perchè molte realtà, tra cui i CMS più utilizzati come WordPress, Prestashop, Magento, Joomla, abbiano deciso di continuare ad utilizzare un DBMS come MySQL e derivati che di fatto non ha quella caratura e quei requisiti tali da renderlo appetibile rispetto alla controparte PostgreSQL.
Verrebbe da tirare in ballo moltissime considerazioni in merito all’efficienza del software nonchè all’impatto sui consumi e sull’ambiente se si considera questo ragionamento applicato su larga scala, permettendo ad esempio di ridurre il numero di nodi di un cluster o di poter evitare in alcuni casi lo scaling orizzontale o verticale per far fronte all’inefficienza del database.
Tuttavia, eccetto qualche progetto sporadico piuttosto acerbo da usare in produzione con le dovute garanzie, non sembra ancora esserci futuro per PostgreSQL nell’utilizzo come backend per i CMS più popolati sopra citati.
Un vero peccato se si considera che il grado di maturità di PostgreSQL è talmente elevato da non avere praticamente più rivale alcuno (se non forse Oracle DB).
