Jepsen द्वारा MySQL 8.0.34 का मूल्यांकन

 (jepsen.io)
3 पॉइंट द्वारा GN⁺ 2023-12-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें

MySQL की पृष्ठभूमि

  • MySQL पिछले 28 वर्षों से सबसे व्यापक रूप से डिप्लॉय किए गए SQL डेटाबेस में से एक है.
  • इसका मुख्य उपयोग ऑनलाइन ट्रांज़ैक्शन प्रोसेसिंग (OLTP) में होता है, और इसे OLAP तथा queueing systems के हिस्से के रूप में भी डिप्लॉय किया जाता है.
  • इसे एक single-server डेटाबेस के रूप में डिज़ाइन किया गया था, लेकिन बाद में विभिन्न multi-node replication तरीकों के साथ इसका विस्तार हुआ.
  • यह विश्लेषण InnoDB storage engine का उपयोग करने वाले MySQL पर केंद्रित है.

ANSI SQL isolation levels वास्तव में खराब हैं

  • SQL isolation levels की बारीकियों पर चर्चा करने के लिए, 1977 में प्रस्तावित transaction consistency के चार safety levels और 1986 में ANSI द्वारा प्रकाशित SQL standard की ऐतिहासिक पृष्ठभूमि को समझना ज़रूरी है.
  • ANSI SQL isolation levels को तीन संभावित phenomena — dirty read, non-repeatable read, और phantom — के माध्यम से परिभाषित करता है.
  • 1995 में ANSI SQL isolation levels की कमियों की ओर इशारा किया गया, और 1999 में Adya ने ANSI SQL isolation levels के लिए एक formal और implementation-independent definition विकसित की.

MySQL के isolation levels

  • MySQL documentation कहती है कि यह SQL:1992 standard में वर्णित transaction isolation के चार स्तर प्रदान करता है.
  • इसमें यह भी बताया गया है कि हर isolation level पर MySQL इसे कैसे हासिल करता है.
  • MySQL का Repeatable Read isolation level snapshot mechanism के माध्यम से safety सुनिश्चित करता है.

टेस्ट डिज़ाइन

  • Jepsen test library का उपयोग करके MySQL के लिए एक test suite डिज़ाइन किया गया.
  • single MySQL node, binlog replication cluster, और AWS RDS cluster सहित विभिन्न environments में टेस्ट किए गए.
  • transaction isolation के प्रमुख workloads चलाने के लिए Elle के list-append checker का उपयोग किया गया.

परिणाम

  • MySQL का Repeatable Read, Adya के PL-2.99 isolation level द्वारा प्रतिबंधित G2-item को अनुमति देता है.
  • MySQL का Repeatable Read, G-single (read skew) को भी अनुमति देता है.
  • MySQL का Repeatable Read, P4 (lost update) phenomenon को अनुमति देता है.
  • MySQL का Repeatable Read internal consistency errors दिखाता है.
  • MySQL का Repeatable Read Monotonic Atomic View का उल्लंघन करता है.

GN⁺ की राय

  • यह तथ्य कि MySQL का Repeatable Read isolation level standard में निर्दिष्ट व्यवहार से अलग तरीके से काम करता है, developers और database administrators के लिए महत्वपूर्ण जानकारी है. इसका मतलब है कि यह data consistency और isolation के अपेक्षित स्तरों को पूरा न कर पाए.
  • test results, database system के isolation levels को समझने और उपयुक्त isolation mechanism चुनने के लिए आवश्यक जानकारी प्रदान करते हैं.
  • ये निष्कर्ष इस बात पर अंतर्दृष्टि देते हैं कि database isolation standards वास्तविक implementations से कैसे अलग हो सकते हैं. इससे database technology की जटिलता और isolation levels के सूक्ष्म अंतर समझने में मदद मिलती है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-20
Hacker News राय

  • मैं लंबे समय से यह तर्क देता आया हूँ कि "repeatable read" एक खराब आइडिया है। भले ही इसका implementation परफेक्ट हो, और डेटाबेस में सही तरह से काम भी करे, जटिल queries के साथ काम करते समय इसे समझना मुश्किल होता है.

    • मुझे लगता है कि सिर्फ दो isolation levels समझ में आते हैं:
      • read committed
      • serializable
    • serializable सेटिंग में कोई अप्रत्याशित बात नहीं होती। read committed में यह साफ़ है कि अगर आपको डेटा का consistent view चाहिए, तो rows को पढ़ना शुरू करने से पहले lock करना होगा.
    • read committed सामान्य multi-threaded code और memory management से बहुत मिलता-जुलता है, इसलिए ज़्यादातर engineers इसे सहज रूप से समझ सकते हैं.
    • serializable इतना सख्त है कि इसमें अनजाने में गलती करना मुश्किल है.
    • बीच का स्तर ऐसी ज़मीन है जो किसी की नहीं, और Read Committed से कम consistent कुछ हो तो वह अब डेटाबेस जैसा नहीं रह जाता.

  • FOSSDEM-2024 में "Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study" पर प्रस्तुति होने वाली है.

    • Oracle, MySQL, SQL Server, PostgreSQL, YugabyteDB का comparative study.

  • मैं AWS RDS पर लिखे गए लेख का मूल्यांकन कर रहा हूँ, लेकिन यह जानना चाहता हूँ कि क्या इसमें AWS Aurora (MySQL) पर फोकस है। AWS ने ऐसे database platforms बनाए हैं जो MySQL या PostgreSQL होने का आभास देते हैं। यह देखना दिलचस्प होगा कि Aurora MySQL में RDS या MariaDB जैसे "features" हैं या नहीं.

  • मुझे लगता है कि यह उन "असल में काम करने वाले systems" का शानदार उदाहरण है जो कई consistency artifacts दिखाने वाली नींव पर बनाए गए हैं.

  • यह थोड़ा चिंताजनक है कि RDS replication सिर्फ 5 मिनट में काम करना बंद कर देती है और health check failure की कोई alert भी नहीं आती.

  • मैं जानना चाहता हूँ कि append (a) किसी दिए गए table में असली SQL operations से कैसे map होता है, और क्या TEXT field को list की तरह इस्तेमाल किया जाता है.

    • MySQL के repeatable read mode में एक समस्या थी जहाँ एक single SELECT ने single row चुनी और असंभव result लौटाया। उदाहरण के लिए, SELECT min(value), max(value) FROM table WHERE id = 1; में, जहाँ id primary key है, मुझे min और max के लिए अलग-अलग values मिली थीं.

  • सिर्फ सैद्धांतिक isolation mode definitions से तुलना ही नहीं, बल्कि PostgreSQL, MS SQL, Oracle जैसे दूसरे लोकप्रिय relational databases के साथ तुलना भी मददगार होगी। compatibility सुनिश्चित करना चाहने वाले developers को इसे ध्यान में रखना चाहिए.

  • ऐसा लगता है कि "SELECT ... FOR UPDATE" इन सभी समस्याओं का जवाब है; update की जाने वाली rows को lock कर दें, तो सब कुछ वैसा ही काम करता है जैसा बताया गया है.

  • मैं आज थोड़ा काम करने की कोशिश कर रहा था, लेकिन aphyr का 'call me maybe' और jepsen.io इंटरनेट पर पढ़ी गई बेहतरीन चीज़ों में से कुछ हैं, इसके लिए आभारी हूँ.

  • मैं सोच रहा हूँ कि MySQL के विश्लेषण का कितना हिस्सा MariaDB पर भी उसी तरह लागू होगा, क्योंकि वह default storage engine के रूप में InnoDB का उपयोग करता है.