MariaDB vs. MySQL 8.0: Teste de performanță & Ghid de configurare VPS

Nu e despre filozofie, e despre RAM

În comunitatea open-source, dezbaterea dintre MariaDB și MySQL degenerează adesea în certuri despre corporația Oracle versus puritatea open-source. La ServerSpan, noi nu alegem software-ul pe bază de ideologie; îl alegem pe cel care ne trezește cel mai rar la 3 dimineața. Din experiența noastră în gestionarea a mii de instanțe Linux VPS, divergența tehnică dintre aceste două baze de date a devenit suficient de mare încât "drop-in replacement" (înlocuitor direct) nu mai este o afirmație 100% corectă.

Când provizionăm un nou Managed VPS, setăm implicit MariaDB dintr-un motiv specific: eficiența resurselor pe hardware limitat. Totuși, MySQL 8.0 are funcționalități pe care aplicațiile enterprise le cer în mod specific. Acest ghid descompune diferențele de configurare care impactează cu adevărat performanța VPS, ignorând marketingul.

1. Diferența majoră: Thread Pool vs. One-Thread-Per-Connection

Teoria:
Acesta este cel mai mare diferențiator pentru site-urile cu trafic mare. MySQL Community Edition standard folosește un model "un fir de execuție per conexiune". Dacă ai 500 de utilizatori concurenți, MySQL generează 500 de thread-uri. Asta creează un overhead masiv de "context-switching" pentru procesor. MariaDB include un "Thread Pool" (similar cu modelul worker din Nginx) care menține un număr fix de thread-uri active și pune cererile în coadă.

Implementarea:
Pe un VPS de înaltă performanță care rulează MariaDB, noi activăm explicit această funcție în `/etc/mysql/mariadb.conf.d/50-server.cnf` dacă nu este pornită implicit (depinde de versiune):

[mysqld]
thread_handling = pool-of-threads
thread_pool_size = 16  # De obicei egal cu numărul de nuclee CPU 

Cazul limită (Edge Case):
Interogările (queries) de lungă durată. Dacă un query prost scris blochează un thread din pool timp de 10 secunde, blochează și alte interogări rapide. Noi configurăm `thread_pool_stall_limit` pentru a preveni ca un singur raport complex să dărâme procesul de checkout.

---

---

2. Amprenta de memorie: MySQL 8 este "flămând"

Teoria:
MySQL 8.0 a introdus o refactorizare semnificativă a dicționarului de date. Deși arhitectural este solid, a rezultat într-o cerință de memorie de bază mult mai mare. Am observat că o instanță MySQL 8 goală consumă aproximativ 400-500MB RAM în idle, în timp ce MariaDB 10.11 stă undeva la 150MB.

Implementarea:
Dacă ești pe un VPS Ieftin cu 2GB RAM sau mai puțin, recomandăm cu tărie MariaDB. Dacă ești obligat să folosești MySQL 8, trebuie să fii agresiv cu `innodb_buffer_pool_size` și să dezactivezi performance schema dacă nu o folosești.

# Pentru MySQL 8 pe VPS cu RAM puțin
performance_schema = OFF
innodb_buffer_pool_size = 512M

Cazul limită (Edge Case):
OOM Killer (Out of Memory Killer). Vedem frecvent în log-urile Server VPS cum kernel-ul "omoară" procesul MySQL 8 în timpul unui backup pentru că amprenta de memorie a crescut puțin peste limită. Profilul mai suplu al MariaDB oferă o marjă de siguranță mai mare pe instanțele mici.

3. Replicare și Clustering: Galera vs. Group Replication

Teoria:
Când un client cere "High Availability" (Disponibilitate Ridicată), de obicei vrea un cluster. MariaDB utilizează nativ Galera Cluster (multi-master). Este testat în luptă și sincronizează nodurile virtual instantaneu. MySQL are "InnoDB Cluster" (Group Replication), care este robust, dar semnificativ mai complex de configurat și gestionat pentru un sysadmin obișnuit.

Implementarea:
Inițializarea unui cluster Galera pe MariaDB implică editarea setărilor `wsrep_`. Asta ne permite să configurăm un cluster Cloud VPS de 3 noduri unde poți scrie date pe oricare dintre ele.

Cazul limită (Edge Case):
Latența rețelei. Galera este sincronă. Dacă unul dintre noduri este în New York și altul în Frankfurt, viteza de scriere este limitată de timpul de ping dintre ele. Noi desfășurăm întotdeauna clusterele în același datacenter sau regiune pentru a evita blocarea aplicației.

4. Suport JSON: Capcana compatibilității

Teoria:
Aici "drop-in replacement" dă greș. MySQL 5.7+ a introdus un tip de date nativ JSON. MariaDB stochează JSON ca `LONGTEXT` cu verificări de constrângere (constraint checks). Deși ambele suportă funcții precum `JSON_EXTRACT`, sintaxa a divergent. MySQL are funcții precum `JSON_TABLE` pe care MariaDB le-a implementat diferit sau mai târziu.

Implementarea:
Dacă migrezi o aplicație Laravel sau o aplicație custom de pe un VPS Self Hosted cu MySQL către MariaDB, verifică interogările SQL brute.

-- Sintaxa MySQL
SELECT col->"$.key" FROM table;

-- Sintaxa MariaDB (Compatibilă, dar uneori mai strictă)
SELECT JSON_UNQUOTE(JSON_EXTRACT(col, "$.key")) FROM table;

Cazul limită (Edge Case):
Am migrat un client care folosea un plugin WordPress specializat pentru gestionarea stocurilor, care se baza pe o funcție JSON specifică MySQL 8.0 indisponibilă în MariaDB 10.6. Site-ul a returnat erori 500. A trebuit să facem upgrade specific la MariaDB 11.x pentru o compatibilitate mai bună, dar riscul rămâne.

---

---

5. Motoare de stocare (Storage Engines): Nu există doar InnoDB

Teoria:
MySQL este efectiv doar InnoDB în zilele noastre (MyISAM este mort). MariaDB, totuși, vine cu motoare alternative precum MyRocks (optimizat pentru compresie pe stocare flash) și Aria (un înlocuitor crash-safe pentru tabele temporare). Pentru un VPS pentru Developeri care experimentează cu big data, MariaDB oferă mai multe "jucării".

Implementarea:
Rareori schimbăm motorul implicit pentru tabelele principale, dar optimizăm tabelele temporare. MariaDB folosește Aria pentru tabele temporare interne pe disc, care este mai rapid decât MyISAM.

Cazul limită (Edge Case):
Căutarea full-text. Dacă te bazezi pe căutarea full-text la nivel de bază de date (în loc de Elasticsearch), implementarea diferă ușor ca performanță. Noi recomandăm în general descărcarea căutării către un serviciu dedicat decât să cerem bazei de date să facă parsare grea de text.

6. Calea de upgrade: mysql_upgrade a murit

Teoria:
În trecut, după actualizarea binarelor, rulam `mysql_upgrade`. În MySQL 8.0, acest lucru se face automat de către binar. MariaDB încă se bazează pe `mariadb-upgrade` (fostul `mysql_upgrade`) în multe contexte pentru a repara tabelele de permisiuni.

Implementarea:
Când efectuăm management VPS și actualizări de sistem (`apt upgrade`), dacă versiunea bazei de date sare la una superioară, verificăm întotdeauna log-urile.

# Pentru actualizări MariaDB
mariadb-upgrade --force -u root -p

Cazul limită (Edge Case):
Dacă sari peste acest pas, vedem adesea erori de tip "Table 'performance_schema...' doesn't exist" care umplu log-urile și consumă inutil stocarea VPS.

Gânduri de final din partea echipei de Ops

Deci, ce alegem? Pentru 90% din implementările noastre de Managed Cloud VPS, alegem MariaDB. Este mai ușor, thread pool-ul ne salvează de vârfurile de trafic, iar configurația implicită este mai logică pentru web.

Totuși, dacă dezvoltatorii tăi cer funcții JSON specifice MySQL 8 sau folosești unelte enterprise specifice Oracle, rămâi la MySQL. Doar fii pregătit să aloci cu 20-30% mai mult RAM pentru a obține același throughput. Dacă nu ești sigur ce motor se potrivește volumului tău de lucru, deschide un tichet la noi. Ne putem uita la schema ta de date și îți vom oferi un răspuns pragmatic, nu unul filozofic.