26 Mar, 2018

" MariaDB performans ipuçları "

MariaDB, MySQL’in orijinal geliştiricileri tarafından yapılan en popüler veritabanı sunucularından biridir ve güçlü bir geliştirici ve kullanıcı topluluğuna sahiptir. MariaDB’de en iyi performansı elde etmek için performans ayarlaması gerekir. MariaDB’yi nasıl yükleyeceğinizi bu konuda anlattım şimdi daha iyi performans için optimize edilmesinden bahsedeceğim.

MySQL, teknoloji dünyasındaki en popüler açık kaynak veritabanlarından biridir. Daha önce MySQL, açık kaynaklı ve ticari veri tabanları sunan bağımsız bir şirketti. Daha sonra Sun Microsystems MySQL’i satın aldı ve ardından Oracle Sun’ı satın aldı. Oracle Sun’ı satın aldığında, orijinal MySQL geliştiricileri SkyDQL adı verilen bir şirket tarafından desteklenen MariaDB adlı bir proje başlattı. Bu adımı attılar çünkü Oracle tarafından satın alındıktan sonra MySQL’in kapalı kaynak haline gelmesinden korkuyorlardı.

Tüm bu olaylarda sonra, birçok Linux dağıtımı MariaDB’yi varsayılan MySQL sunucusu olarak paketlemeye başladı. Bazı dağıtımlar hem MySQL (Oracle) hem de MariaDB sağlar ve seçimi kullanıcıya bırakır.

Diğer açık kaynak projeleri gibi, MariaDB birçok açıdan MySQL’in önündedir; bazı gelişmiş özelliklere sahiptir ve genellikle daha hızlı bir yayın döngüsünden geçer – MySQL’den daha hızlı yeni özellikler ve hata düzeltmeleri sunar.

MariaDB 10.1’de bulunan depolama motorları
Depolama motorları MySQL ve MariaDB’nin en önemli bölümünü oluşturur. Verilerin nasıl ve nerede depolanacağına karar verir ve veri yönetimi için özellikler sağlarlar. MariaDB tarafından desteklenen birçok depolama motoru var, ancak sadece en çok kullanılanları tartışacağız.

İşlemsel motorlar: Orijinal olarak MySQL ile gelen InnoDB, MySQL için varsayılan olarak işlem motorudur. MariaDB’nin varsayılan işlem motoru olarak XtraDB olarak bilinen bir çatalı vardır; XtraDB Percona tarafından geliştirilmiş ve sürdürülmüştür. XtraDB ayrıca Percona sunucusunun bir parçası olarak da mevcuttur. InnoDB / XtraDB en çok kullanılan ACID uyumlu motordur. Çoğu kullanım durumu için güvenli ve iyidir.

InnoDB’nin yedeklemesi kolay değildir. XtraDB kullanıyorsanız, XtraDB verilerini yedeklemek için kullanılabilecek Xtrabackup olarak bilinen Percona’dan bir araç var. Bu aracın kullanımı, verilerin motor tarafından saklanma şekli ile ilgilidir.

Küçük boyutlu veritabanlarında mysqldump yeterlidir ancak daha büyük olanlar için xtrabackup kullanmak daha iyidir. Başka bir sunucuya çoğaltma ve orada yedek alma daha da iyidir.

MariaDB’de TokuDB adı verilen bir başka ACID uyumlu işlem motoru daha var. Çok miktarda verinin küçük alanlarda depolanması için tasarlanmıştır – 25x’e kadar sıkıştırma yapılabilir. TokuDB için tipik kullanım durumları, birçok verinin aynı zamanda sorgulandığı ve güncellendiği, belirli bir anda çalışılan verinin RAM’e sığamayacağı ortamlardır.

Performans ayarlama
Veritabanı performans ayarlaması büyük bir konudur ve uygulamanın iş yüküne bağlıdır. Yine de, her duruma uygulanabilecek bazı ortak ilkeler vardır. Başlamak için sunucunuzun donanımını kontrol edin. Veritabanları çok miktarda RAM ve hızlı disk IO gerektirir. Daha fazla RAM ve daha hızlı disk, daha mutlu veritabanı sunucusudur.

Büyük bir veri tabanı sistemi ile yüksek verim elde etmek için RAID 10 modunda SSD gibi depolama yapılması tavsiye edilir. Sadece geleneksel bir döner sabit diskten SSD’ye geçmek sunucunun yanıt sürelerini önemli ölçüde artırabilir.

Bir veri tabanından iyi bir verim elde etmek için, veritabanı şemasını tasarlamak ve en uygun sorguları kullanmak çok önemlidir. Örneğin, kullanıcının adı, e-posta adresi, kullanıcı adı gibi ayrıntıları içeren bir tablonuz varsa ve kullanıcı adı alanında bir dizin olmadan kullanıcı adını arayan bir sorgu çalıştırıyorsanız, performans kötü olacaktır. veritabanı sunucusu, bu tür bir sorgu için tam bir tablo taraması yapmalıdır.
Tam bir tablo taraması, sonuçlara ulaşılmadan önce tüm satırların taranması gereken bir taramadır. Kötü tasarlanan sorgular, özellikle birleştirmeler, ciddi performans isabetlerine neden olabilir. MySQL ve MariaDB, birleştirmelerin sonucunu hesaplamak için iç içe döngü algoritmasını kullanır. Yuvalanmış döngü algoritması şu şekilde çalışır: birleştirilmiş sonucun gerekli olduğu üç tablo (t1, t2, t3) olduğunu söyleyelim. Öncelikle, optimiser sürüş tablosuna karar verir ve birleşimdeki bir sonraki tablo, sürüş tablosundan alınan sonuçlara göre sorgulanır. Bu sonuç kümesi, üçüncü tablonun verilerinin eşleştirildiği tabanı oluşturur. Matematiksel olarak, bu bir Kartezyen ürün olarak bilinir.

Önbelleğe almayı kullan (Cache)
MySQL ve MariaDB’nin performansında önemli bir artış sağlayan bir sorgu önbelleği vardır. Daha az yazı olan durumlarda ve çoğunlukla okur. Çok fazla yazma varsa, sunucu sorgularda çalışmak yerine önbelleği yönetmek için daha fazla zaman harcıyor olacak. Bu nedenle, yerleşik MySQL sorgu önbelleği için büyük boyutta olması önerilmez. 512MB’a kadar yeterlidir. Daha fazla kontrol için uygulama Memcached veya Redis gibi kendi önbelleğini kullanmalıdır.

EXPLAIN kullan
Sistem için sorguları tasarlarken, optimal sorgulara sahip olmak önemlidir. MySQL, EXPLAIN’a verilen bir sorgunun yürütme planının ayrıntılarını sunacaktır. Optimizer izi de mevcuttur, bu da diğerinin yerine neden bir planın seçildiğini araştırmak için kullanılabilir. Optimizer izi dahili olarak MySQL tarafından kullanılır, ancak sorguları tasarlarken de kullanılabilir.
Optimizer izlemesi kullanmak için şunu yazın:
mysql> SET optimizer_trace=”enabled=on”

Doğru bellek parametrelerini ayarlama
MySQL, birleştirme ve sıralama içeren karmaşık sorguları işlerken çok sayıda geçici tablo kullanır. Geçici tablonun varsayılan boyutu çok küçüktür ve daha büyük veri kümeleri için yeterli değildir. Geçici bir tablo boyutu ayarlamak için, my.cnf dosyanıza aşağıdakileri ekleyin:

tmp-table-size = 1G

max-heap-table-size = 1G

Geçici tablolar için daha büyük değerler belirlemenin daha fazla RAM tüketileceği anlamına geldiğini belirtmek önemlidir. Sistem yeterli RAM değerine sahip değilse, değerler artırılmamalıdır. Mysqltuner, sunucunun mevcut ayarlarının mevcut RAM değerini geçip geçmeyeceği konusunda bilgi verebilir. İyi bir RAM kullanım şekli yüzde 80-90’dır. Yüzde 90’ın ötesinde, sınırda işlem yapılmasını ima eder ve veri tabanının sunucudaki tek hizmet olduğunu varsayarak hataya neden olabilir. Aynı makine Web gibi diğer hizmetler için kullanılıyorsa, bunun da yapılması gerekir. Ancak, Web ve veritabanı aynı sunucuda büyük iş yüklerinde çalıştırmak kötü bir fikirdir.

Tampon boyutları (Buffer Size)
Ayarlanabilen iki önemli öğe, genellikle, arabellek boyutuna ve sıralama arabelleği boyutuna birleştirilir. Bu tamponlar bağlantı başına tahsis edilir ve sistemin performansında önemli bir rol oynar. Adından da anlaşılacağı gibi, birleştirme işleminin gerçekleştirilmesi için birleştirme arabelleği kullanılır – ancak yalnızca tuşların mümkün olmadığı tam birleşimler.
Sıralama arabelleği boyutu, verileri sıralamak için kullanılır. Uygulamanız çok fazla sıralama içeriyorsa, bu artırılmalıdır. Sort_merge_passes sistem durum değişkeni, değerin artırılıp artırılmayacağını size söyleyecektir. Bu değişken mümkün olduğunca düşük olmalıdır.

InnoDB ayarları
Daha önce de belirtildiği gibi, daha fazla RAM, daha iyi performans. Bir InnoDB sisteminin performansı, mevcut verinin ve arabellek havuzu boyutunun büyüklüğüne doğrudan bağlıdır.

InnoDB günlük dosyası, bir elektrik kesintisi veya veritabanı çökmesi durumunda tekrarlanabilen bir yineleme günlüğünün saklanması için kullanılır. Uygulamada çok fazla yazım varsa, günlük dosyasının boyutu artırılmalıdır. Günlük dosyasının en uygun boyutu innodb_os_log_written durum değişkeninin gözlemlenmesiyle hesaplanabilir.

Günlük dosyasına yazılan her bayt için artırılan bir sayaçtır (bayt). Bu nedenle, belirli bir zaman periyodundaki (60 saniye) değişkenin değerleri arasındaki fark, bir dakika değerinde kurtarma verisini depolamak için en uygun günlük dosyası boyutunu verir.

Daha uzun süreli yineleme günlüğünü saklamak için, boyut birim zaman aralığının katları olabilir. Günlük büyüklüğünün gerçekten ayarlanması gerekiyorsa, durum değişkeni innodb_log_waits de kontrol edilmelidir. Birçok kurulumda, günlük boyutu gereksizdir ve bu da bir çarpışma veya elektrik kesintisi olduğunda kurtarma için gereken süreyi artırır.
Günümüzde sunucuların çoğunda birden çok CPU var (fiziksel olarak veya SMP olarak). InnoDB arabellek havuzu boyutu bir gigabayttan daha fazlaysa, o zaman innodb-buffer-havuzu-örneklerini kullanarak CPU sayısına bölünebilir. Arabellek havuzu örneklerinin sayısı için ideal değer, sunucuda sahip olduğunuz CPU’ların sayısıdır ve her bir örneğin en az 1 GB olması gerektiğini belirtmek önemlidir.

Dosya sistemi ayarları
Veritabanı verilerinin depolandığı dosya sistemi, performans ayarının önemli bir yönüdür. Çoğu Linux sunucusu ext4 veya xfs kullanır.

Bir dosya okunduğunda, dosyanın erişim zamanı güncellenir. Bunun küçük bir faydası var ve devre dışı bırakılması çok fazla performans avantajı sağlayacaktır.  Ek olarak, InnoDB durumunda bir ham diski depolama olarak kullanmak mümkündür – tüm InnoDB veri dosyası bir ham disk bölümü üzerinde saklanabilir. Bu mod, özel bir diske sahipseniz ve dosya sistemi ile MySQL’in çift arabelleğe alınmasını önlemeye yardımcı olabilirse iyidir.
Ubuntu 16.04’ten itibaren, Linux’ta ZFS’yi çalıştırmak mümkündür. Linux dosya sistemleri varsayılan olarak dosya sistemi sayfa önbelleği için LRU (En Az Son Kullanılanlar) algoritmasını kullanır – bellek gerektiğinde en eski sayfa çıkarılır. Aksine, ZFS, hem son zamanlarda okunan blokları hem de sıklıkla okunan blokları dikkate alan bir sayfa değiştirme algoritması kullanan ARC – Adaptif Değiştirme Önbelleği’ne sahiptir – temel olarak LRU ve LFU (En Az Sık Kullanılan) kombinasyonudur. Bu, bazı performans avantajlarının elde edilmesine yardımcı olur, ancak iş yüküne bağlıdır.

ARC’ye ek olarak, NVMe veya SSD gibi RAM’den biraz daha yavaş olan bir bellek cihazında saklanabilen bir ARC olan L2ARC’yi de destekler. InnoDB’nin varsayılan ZFS ayarları ile saklanması en uygun performansı sunmaz – InnoDB depolamanın kayıt boyutu 16k, InnoDB log depolama alanı 128k olmalıdır. Tablo başına innodb dosya bayrağı (varsayılan olarak which açık) durumunda, InnoDB veri dosyaları tek bir büyük dosyada depolanmak yerine ayrı ayrı veritabanı dizinleri içinde oluşturulur. Tüm MySQL veri kümesinin bu durumda 16k kayıt boyutuna sahip olması gerekir.
Bu, MySQL ve MariaDB performans ayarlaması ile ilgili nispeten büyük bir bölümü kapsar; geri kalan uygulama iş yüküne bağlıdır. Bu stratejileri kullanarak sunucuları ortalamada ortalama 1k ila 5.5k sorguları başarıyla yapılandırdım.


Not: Arkadaşlar konu çeviridir yazım hataları olabilir hatalı gördüğünüz kısımları yorumda bildirirseniz güncelleme fırsatım olur.


Bu yazı 85 Defa okundu, Beğendiyseniz üstteki benzer yazıları okumanızı öneririm, isterseniz site içinde farklı içerikleri arama yapabilirsiniz.

Ali Çömez / Slaweally

Kaldırımda yürürken beyaz çizgilere basmamaya çalışan, Sabah yüzünü yıkarken dirseklerinden su sızmasından nefret eden, Dönerle ayranı aynı anda bitirebilen, son dakikada otobüsü kaçırsada grur yapıp arkasından koşmayan... bir insanım :)

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir