MariaDB mi MySQL mi; Projeniz için doğru seçim

Sunucuyu ayağa kaldırdınız, kurulum betiğini çalıştırdınız ve şimdi ekranda kaldınız: mariadb-server mı kuracaksınız yoksa mysql-server mı? Paylaşımlı hostingden geldiyseniz, muhtemelen düne kadar sadece bir "veritabanı oluştur" düğmesi görmüştünüz ve şimdi kendiniz karar vermelisiniz. Yanlış karar da hemen kendini göstermez; üç ay sonra, yükseltme yapmak veya bir eklentiyi etkinleştirmek istediğinizde ortaya çıkar.

İyi haber şu ki, vakaların %90'ında cevap basittir. Kötü haber şu ki, geriye kalan %10 tam da gerçek projelerin tökezlediği yerdir.

MariaDB mi MySQL mi; ayrılık hikayesi nereden başladı

2009 yılına kadar bu ikisi aynıydı. MySQL'in Oracle tarafından satın alınmasından sonra projenin ana ekibi fork'u aldı ve MariaDB'yi oluşturdu. Yıllar boyunca bu ikisi neredeyse aynı koddu ve bu yüzden birçok kişi farklarının sadece isimde olduğunu düşündü. MySQL 8.0'dan itibaren bu varsayım yanlış oldu.

Bugün iki ayrı geliştirme hattımız var. MySQL 8.0 ve 8.4 kendi yolunu gitti; MariaDB 10.2'den itibaren başka bir yol izledi. Her ikisi de standart SQL'i anlar, her ikisinde de InnoDB var (MariaDB'de XtraDB adında, InnoDB'nin daha eski fork'u olan bir sürüm), ancak depolama motoru detaylarında, fonksiyonlarda ve optimizer davranışında birbirlerinden uzaklaştılar.

Pratikte karşılaşacağınız farklar

• JSON: MySQL'de yol üzerinde indeksleme yapabilen gerçek JSON veri tipi var. MariaDB'de aynı JSON aslında bir CHECK constraint ile LONGTEXT'tir. JSON sütunu üzerinde ağır sorgu çalıştırıyorsanız, bu farkı hissedersiniz.
• CTE ve pencereler: Her ikisinde de var, ancak MySQL'de 8.0'dan ve MariaDB'de 10.2'den itibaren. Daha eski bir sürümdeyseniz, analitik sorgularınız çalışmaz.
• Depolama motorları: MariaDB ana pakette Aria, ColumnStore ve MyRocks motorlarına sahiptir. MySQL eşdeğerleri için ticari sürümlere veya eklentilere başvurmalıdır.
• Replication: MariaDB kendi formatıyla GTID kullanır ve bu MySQL'deki GTID ile uyumlu değildir. Bu, bir MariaDB slave'ini MySQL master'a bağlayıp sorunsuz çalışmasını bekleyemeyeceğiniz anlamına gelir.

Hangisini seçmeliyim? Pratik bir kural

Projeniz WordPress, Joomla veya herhangi bir yaygın CMS üzerindeyse, MariaDB'yi alın. Nedeni önyargı değil; nedeni, çoğu hosting panelinin ve otomatik kurulum betiğinin yıllardır MariaDB üzerinde test edilmesi ve en az sürtünmeyi yaşamanızdır. İran sanal sunucusunda da MariaDB kurulumu bir apt install mariadb-server ile tamamlanır ve hiçbir ek ayar gerektirmez.

MySQL 8.0'a bağlıysanız, genellikle belirli bir nedeniniz vardır: resmi olarak yalnızca MySQL'i destekleyen ticari bir uygulama veya yıllardır MySQL'e özel izleme araçları üzerinde çalışan bir ekip. Bu durumda MySQL ile kalın. Sadece "özgür olmak" için değiştirmek risk almaya değmez.

Birinden diğerine geçiş; herkesin takıldığı yer

MariaDB'den MySQL'e (veya tersine) geçiş teoride bir mysqldump'tır. Pratikte üç şey önünüzü keser.

Birincisi: sadece ismi değil, sürümleri kontrol edin

mysql --version
mariadb --version
SELECT VERSION();

Çıktı 10.11.6-MariaDB ise, mysql komutunu çalıştırmış olsanız bile MariaDB üzerindesiniz. Bu, hikayenin en kafa karıştırıcı kısmıdır: MariaDB'de binary'ler ve istemciler hâlâ uyumluluğu korumak için mysql adını taşır. Birçok kişi MySQL'e sahip olduğunu düşünür ama aslında MariaDB'ye sahiptir.

İkincisi: dump'ı körü körüne geri yüklemeyin

mysqldump --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 mydb > mydb.sql

--single-transaction bayrağı InnoDB tabloları için tablo kilitlemesini önler ve canlı sitede hayati önem taşır. Onsuz, yoğun trafik saatlerinde bir tablo kilitlenir ve site birkaç dakika uyur. MyISAM tablonuz varsa, bu bayrak yardımcı olmaz ve bir bakım penceresi ayarlamanız gerekir.

Üçüncüsü: charset'i ciddiye alın

Veritabanınız eski utf8 (aslında üç baytlı) üzerinde oluşturulmuşsa, utf8mb4'ye geçişi hemen şimdi yapın. Emoji ve bazı Farsça karakterler üç baytlı utf8'de doğru şekilde saklanmaz ve geçişten sonra ???? olarak görünür. Bu hata loglara düşmez; sadece sitede görürsünüz.

Burada hata yapıyorlar: birçok kişi dump'ı --default-character-set=latin1 ile alır çünkü eski sunucu yapılandırmasında böyleydi, sonra varsayılanı utf8mb4 olan yeni sunucuda geri yükler ve tüm Farsça metin bozulur. Belirtisi şudur: site açılır, tablolar sağlıklı görünür, ancak her şey سلام gibi görünür. Doğru yol, kaynak charset'i SHOW CREATE DATABASE'den okumak ve dump'ta aynısını belirtmektir.

Performans; gerçek sayı ne anlama gelir

Hafif OLTP benchmark'larında, bu ikisi arasındaki fark genellikle %5'in altındadır. Yani siteniz saniyede 200 sorgu ile çalışıyorsa, veritabanını değiştirmek hızını iki katına çıkarmaz. Hızı gerçekten değiştiren üç şey vardır: doğru indeks, innodb_buffer_pool_size boyutu ve disk.

8 gigabayt RAM'e sahip bir sunucuda, MariaDB'de innodb_buffer_pool_size varsayılan değeri yaklaşık 128 megabayttır. Bu sayı ortalama bir WordPress sitesi için felakettir. Bunu 4 ila 5 gigabayta ayarlayın ve TTFB'deki farkı görün. SATA diskteyseniz, NVMe'ye geçiş veritabanını değiştirmekten daha fazla hız kazandırır.

Darboğazın gerçekten nerede olduğunu görmek için, herhangi bir değişiklikten önce mevcut durumu ölçün. Ağ araçları ve hız testleri, sorunun veritabanından mı yoksa web katmanından mı olduğunu gösterebilir. Yüksek TTFB'niz varsa ama sorgular hızlıysa, sorun muhtemelen başka bir yerdedir ve zamanınızı veritabanında harcıyorsunuzdur.

Proje büyüdüğünde

Küçük ve orta ölçekte, bu ikisi arasındaki seçim neredeyse önemsizdir. Büyük ölçekte, mimari markadan daha önemlidir. Okuma replica'sı, uygulama katmanında önbellekleme ve büyük tabloların bölümlendirilmesi, motor seçiminden daha çok işinize yarar.

Bir sunucunun yetmediği noktaya geldiyseniz, veritabanını değiştirmeden önce sunucu mimarisini düşünün. Ağır veritabanı yükleri için, veritabanını NVMe diskli ayrı bir fiziksel makinede ayırmak genellikle yazılımdaki herhangi bir değişiklikten daha etkilidir. ServerNet'in dokümantasyonu ve bilgi tabanı da farklı yükler için önerilen ayarlara sahiptir ve bu iyi bir başlangıç noktası olabilir.

Az söylenen bir nokta: MariaDB son sürümlerinde, çok sayıda JOIN içeren karmaşık sorgularda MySQL 8.0'dan daha yavaş çalışabilen bazı optimizer davranışlarını değiştirdi. Uygulamanız ağır analitik sorgulara sahipse, geçişten önce örnek veri setiyle değil, gerçek verilerle test edin.

Sık sorulan sorular

MariaDB, MySQL'in tam bir alternatifi mi?

Çoğu web uygulaması için evet. MariaDB, drop-in replacement olacak şekilde tasarlanmıştır ve MySQL ile çalışan çoğu kod değişiklik yapılmadan üzerinde çalışır. Ancak "çoğu" ile "hepsi" farklıdır. MySQL 8.0'e özgü özellikleri, örneğin gerçek JSON veri tipini veya belirli fonksiyonlarını kullanıyorsanız, tam bir alternatif değildir.

Sunucumun MySQL mi yoksa MariaDB mi olduğunu nasıl anlarım?

mysql --version komutunu çalıştırın. Çıktıda MariaDB kelimesini görürseniz, sunucu MariaDB'dir. Ayrıca istemci içinde SELECT VERSION(); çalıştırabilirsiniz. Önemli nokta, mysql adında bir binary'nin varlığının sunucunun MySQL olduğu anlamına gelmemesidir; MariaDB uyumluluğu korumak için aynı isimleri tutmuştur.

MySQL'den MariaDB'ye geçiş ne kadar sürer?

Birkaç gigabaytlık bir veritabanı için, dump ve restore işleminin kendisi genellikle disk hızına ve tablo sayısına bağlı olarak 10 ila 40 dakika arasında sürer. Ancak projenin gerçek süresi daha çok testte harcanır. Geçişi en az bir kez bir staging ortamında deneyin ve sonra production'da çalıştırın.

Her ikisini de aynı sunucuda bulundurabilir miyim?

Evet, ancak önerilmez. Her ikisi de 3306 portunu dinler ve birini başka bir porta taşımanız gerekir. Bunun yanı sıra, RAM tüketimi ve yönetim karmaşıklığı artar. Sadece test için istiyorsanız, ana ortamın dokunulmamış kalması için ayrı bir container kullanmak daha iyidir.

Nihai karar basittir: MySQL için belirli bir nedeniniz yoksa, MariaDB'yi alın ve zamanınızı innodb_buffer_pool_size ayarına ve indekslemeye harcayın. Bu ikisi, site hızını veritabanı markası hakkındaki herhangi bir tartışmadan daha fazla değiştirir.