MySQL veritabanı motorunu nasıl seçersiniz

Özellikle, MyISAM ve InnoDB arasında, gerekli özelliklerin hiçbiri eksik olmadığında nasıl seçim yaparsınız (örneğin, yabancı anahtarlara ihtiyacınız yoktur).

Her zaman her ikisini de denemek ve ölçmek mi? Yoksa okumaların yazımlara karşı sayısı ve sıklığı ve bunun gibi diğer önlemlerle ilgili iyi kurallar var mı? Tablonun boyutunun tipik seçim üzerinde herhangi bir etkisi var mı?

Cevap, daima mümkünse kendi verileriniz ve iş yükünüzle ölçmeniz gerektiğidir.

Veri erişim kalıpları uygulamadan uygulamaya büyük ölçüde değişebileceğinden, söylemek zor ve tüm iş yükleri için "en iyi" bir depolama motoru belirlemek imkansızdır.

Ancak, geçen hafta MySQLConf / Percona Performance Conf'e katılan MySQL alanında çok cesaret verici gelişmeler var.

Alternatif depolama motorlarından bazıları:

1. XtraDB (InnoDB çatalı)
2. InnoDB eklentisi
3. PBXT
4. TokuDB

Buna ek olarak, Percona, Google vb. InnoDB performansına büyük ölçüde yardımcı olan yamalara katkıda bulunmuştur. Şahsen bir OurDelta derlemesi yürütüyorum. Benim için iyi çalışıyor ve OurDelta ve Percona yapılarını kontrol etmeyi teşvik ediyorum.

Sadece basit bir mağaza / rapor sistemi ise, ham performansı için MyISAM kullanıyorum.

Satır düzeyinde kilitlemeden yararlanmak için çok sayıda yazma işlemiyle birden fazla eşzamanlı erişim konusunda endişeliysem InnoDB'yi kullanırdım.

Farklı MySQL veritabanı motorları için çok sayıda kıyaslama vardır. Percona MySQL Performans Blogunda MyISAM, InnoDB ve Falcon'u karşılaştıran iyi bir tane var , buraya bakın .

Yukarıda bahsedilen iki motor (MyISAM ve InnoDB) arasında göz önünde bulundurulması gereken bir başka şey de kilitlenme yaklaşımlarıdır. MyISAM tablo kilitleme yaparken InnoDB sıra kilitleme yapar. Sadece düpedüz performans rakamları değil, dikkate alınması gereken çeşitli şeyler vardır.

Uygulamanız için kesinlikle gerekli olmasa bile, operasyonel nedenlerle çok yararlı bulacağınız özellikler vardır:

• InnoDB'nin MVCC'si vardır, bu da engellemeyen tutarlı yedeklemeler alabileceğiniz anlamına gelir
• InnoDB otomatik kurtarma özelliğine sahiptir, bu da temiz olmayan bir kapatma işleminden sonra uzun REPAIR TABLE işlemleri anlamına gelmez
• InnoDB ile okuyucular asla yazarları engellemez ve bunun tersi de geçerlidir (genel olarak konuşursak) daha fazla eşzamanlılık (bu genel durumda daha iyi performans anlamına gelmez)
• InnoDB, birincil anahtardaki satırlarını kümeler; bu, birincil anahtar yeterince iyi seçilmişse, okuma işlemleri için daha az IO işlemi anlamına gelebilir.

Yabancı anahtar kısıtlamalarına rağmen, muhtemelen InnoDB'yi yine de kullanmak istersiniz.

Tabii ki bu Yığın Taşması değil, ServerFault, bu yüzden doğru cevap:

• Uygulama geliştiricilerinin seçtiği motoru her zaman kullanmalısınız
• Belirli bir motor seçmediyse, MySQL'i kullanma konusunda çok ciddi değiller ve muhtemelen onu nasıl doğru kullanacaklarını bilmiyorlar.
• Uygulamanızın test edildiği motora farklı bir motora geçemezsiniz, hata verebilir.

Hosting sağlayıcım, MyISAM'den tamamen kurtulmamızı ve mümkün olmadığı sürece InnoDB'ye geçmemizi tavsiye etti.

Bizim durumumuzda, günde birkaç kez ila birkaç kez gösterilmeye başlanan ve her zaman büyük masalarda yaş alan ONARIM TABLOSU ve ilgili komutlar gerektiren ciddi veri bozulması yaşadık.

InnoDB'ye geçtikten (veya: dönüştürüldükten sonra), sorunlar anında ortadan kalktı. Olumsuz / uyarılar vardı:

• FULLTEXT endeksi ile tablolar dönüştürülemiyor (bu sorun zamanla kendi kendine gitti; yerini daha iyi bir kaliteye sahip Solr / Lucene tabanlı bir çözüm aldı)
• Genellikle COUNT (*) gerektiren milyonlarca satır içeren büyük tablolar çok yavaştı, bunları da değiştiremedik.

Ancak not: bunların hepsi çevremize vb. Özgüdür, bu nedenle genellikle geçerli olmayabilir.