Jepsen’in MySQL 8.0.34 değerlendirmesi

 (jepsen.io)
3 puan yazan GN⁺ 2023-12-20 | 1 yorum | WhatsApp'ta paylaş

MySQL’in arka planı

  • MySQL, son 28 yılda en yaygın dağıtılan SQL veritabanlarından biri oldu.
  • Başlıca çevrimiçi işlem işleme (OLTP) için kullanılır; ayrıca OLAP ve kuyruk sistemlerinin bir parçası olarak da dağıtılır.
  • Tek sunuculu bir veritabanı olarak tasarlandı, ancak çeşitli çok düğümlü replikasyon yöntemleriyle genişletildi.
  • Analiz, InnoDB depolama motorunu kullanan MySQL’e odaklanıyor.

ANSI SQL yalıtım seviyeleri aslında kötü

  • SQL yalıtım seviyelerinin inceliklerini tartışmak için, 1977’de önerilen işlem tutarlılığının dört güvenlik seviyesi ile 1986’da ANSI’nin yayımladığı SQL standardının tarihsel arka planını açıklamak gerekiyor.
  • ANSI SQL, yalıtım seviyelerini üç olası olgu üzerinden tanımlar: dirty read, non-repeatable read ve phantom.
  • 1995’te ANSI SQL yalıtım seviyelerinin kusurları ortaya kondu ve 1999’da Adya, ANSI SQL yalıtım seviyeleri için biçimsel ve uygulamadan bağımsız bir tanım geliştirdi.

MySQL’in yalıtım seviyeleri

  • MySQL dokümantasyonu, SQL:1992 standardında açıklanan dört işlem yalıtım seviyesini sunduğunu söylüyor.
  • Her yalıtım seviyesinde MySQL’in bunu nasıl sağladığına dair açıklamalar yer alıyor.
  • MySQL’in Repeatable Read yalıtım seviyesi, snapshot mekanizması üzerinden güvenliği sağlıyor.

Test tasarımı

  • Jepsen test kütüphanesi kullanılarak MySQL için bir test paketi tasarlandı.
  • Tek bir MySQL düğümü, binlog replikasyon kümesi ve AWS RDS kümesi gibi çeşitli ortamlarda testler yapıldı.
  • Elle’in list-append denetleyicisi kullanılarak işlem yalıtımına yönelik temel iş yükleri çalıştırıldı.

Sonuçlar

  • MySQL’in Repeatable Read seviyesi, Adya’nın PL-2.99 yalıtım seviyesinin yasakladığı G2-item durumuna izin veriyor.
  • MySQL’in Repeatable Read seviyesi ayrıca G-single’ı (okuma çarpıtması) da kabul ediyor.
  • MySQL’in Repeatable Read seviyesi P4 (kaybolan güncelleme) olgusuna izin veriyor.
  • MySQL’in Repeatable Read seviyesi iç tutarlılık hataları gösteriyor.
  • MySQL’in Repeatable Read seviyesi Monotonic Atomic View’ı ihlal ediyor.

GN⁺ görüşü

  • MySQL’in Repeatable Read yalıtım seviyesinin standartta belirtilenden farklı davranması, geliştiriciler ve veritabanı yöneticileri için önemli bir bilgi. Bu, veri tutarlılığı ve yalıtım konusundaki beklentileri karşılamayabileceği anlamına geliyor.
  • Test sonuçları, veritabanı sistemlerinin yalıtım seviyelerini anlamak ve uygun yalıtım mekanizmasını seçmek için kritik bilgiler sunuyor.
  • Bu bulgular, veritabanı yalıtım seviyelerine ilişkin standartların gerçek uygulamalardan nasıl farklılaşabileceğine dair içgörü sağlıyor. Bu da veritabanı teknolojisinin karmaşıklığını ve yalıtım seviyeleri arasındaki ince farkları anlamaya yardımcı oluyor.

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-20
Hacker News görüşleri

  • Uzun zamandır "repeatable read"'ın kötü bir fikir olduğunu savunuyorum. Uygulaması kusursuz olsa, veritabanında doğru çalışsa bile karmaşık sorgular söz konusu olduğunda anlaması zor.

    • Anlamlı olduğunu düşündüğüm iki yalıtım seviyesi var:
      • read committed
      • serializable
    • serializable ayarında beklenmedik bir şey olmaz. read committed tarafında ise veri üzerinde tutarlı bir görünüm istiyorsanız satırları okumaya başlamadan önce kilitlemeniz gerektiği açıktır.
    • read committed, genel çok iş parçacıklı kod ve bellek yönetimine çok benzer; bu yüzden çoğu mühendis bunu sezgisel olarak anlayabilir.
    • serializable o kadar katıdır ki beklenmedik hatalar yapmak zordur.
    • Ara seviye kimseye ait olmayan bir alandır ve Read Committed'dan daha az tutarlı olan şey artık veritabanı değildir.

  • FOSSDEM-2024'te "Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study" sunumu yapılacak.

    • Oracle, MySQL, SQL Server, PostgreSQL, YugabyteDB karşılaştırmalı olarak inceleniyor.

  • AWS RDS hakkındaki yazıyı değerlendiriyorum, ancak odak AWS Aurora (MySQL) üzerinde mi diye merak ediyorum. AWS, MySQL veya PostgreSQL gibi davranan veritabanı platformları inşa ediyor. Aurora MySQL'in RDS ya da MariaDB ile aynı tür "özelliklere" sahip olup olmadığını görmek ilginç olurdu.

  • Bunu, çok sayıda tutarlılık artefaktı gösteren bir temel üzerine kurulmuş "gerçekte çalışan sistemler" için harika bir örnek olarak görüyorum.

  • RDS replikasyonunun 5 dakika içinde çalışmayı durdurması ve sağlık kontrolü başarısızlığına dair bir uyarı olmaması biraz endişe verici.

  • append (a)'nın verilen tabloda gerçek SQL işlemlerine nasıl eşlendiğini, TEXT alanının bir liste gibi kullanılıp kullanılmadığını merak ediyorum.

    • MySQL'in repeatable read modunda, tek bir SELECT'in tek bir satırı seçip imkansız bir sonuç döndürdüğü bir sorun vardı. Örneğin, id birincil anahtar iken SELECT min(value), max(value) FROM table WHERE id = 1; sorgusunda min ve max için farklı değerler gördüm.

  • Sadece teorik yalıtım modu tanımlarıyla karşılaştırma değil, PostgreSQL, MS SQL, Oracle gibi diğer popüler ilişkisel veritabanlarıyla karşılaştırma da yararlı olurdu. Geliştiricilerin uyumluluk sağlamaya çalışırken akılda tutması gereken şeyler bunlar.

  • Görünüşe göre "SELECT ... FOR UPDATE" tüm bu sorunların cevabı; güncellenecek satırları kilitlerseniz her şey vaat edildiği gibi çalışır.

  • Bugün biraz iş yapmaya çalışıyordum ama aphyr'in 'call me maybe' yazıları ile jepsen.io'nun internette okuduğum en iyi içeriklerden bazıları olduğunu söylemeden geçemeyeceğim.

  • MySQL analizinin ne kadarının, varsayılan depolama motoru olarak InnoDB kullanan MariaDB için de geçerli olduğunu merak ediyorum.