Jepsen: MySQL 8.0.34

मूल लेख ↗ Hacker News चर्चा ↗

MySQL 8.0.34 पर Jepsen के विश्लेषण ने database की transactional guarantees पर फिर से ध्यान केंद्रित किया है, यह दिखाते हुए कि इसकी default “repeatable read” isolation single node पर भी आश्चर्यजनक anomalies पैदा कर सकती है, और कि vendors तथा users अक्सर यह गलत समझते हैं कि वे वास्तव में किस safety level को प्राप्त कर रहे हैं। Commenters MySQL की PostgreSQL और अन्य systems से performance, replication, operational complexity, और isolation semantics के आधार पर तुलना करते हैं; कई लोग तर्क देते हैं कि serializable isolation को default होना चाहिए, जबकि इसकी performance लागत को भी स्वीकार करते हैं। यह चर्चा इस बात को उजागर करती है कि वास्तविक दुनिया के systems कमजोर या कम-स्वरूपित consistency models के ऊपर भी “काफ़ी अच्छे” दिख सकते हैं, और सामान्य developers के लिए isolation levels को सही ढंग से समझना कितना कठिन है।

MySQL पर नए प्रोजेक्ट क्यों शुरू करें?

  • कई लोग MySQL इसलिए इस्तेमाल करते हैं क्योंकि वे इसे पहले से जानते हैं, इसका ट्रबलशूट कर सकते हैं, और यह सामान्य वर्कलोड के लिए “काफ़ी अच्छा काम” करता है।
  • यह अधिकांश कंपनियों के लिए पर्याप्त रूप से स्केल करता है; अधिक चरम मामलों में Vitess जैसे टूल इस्तेमाल किए जा सकते हैं।
  • ऐतिहासिक रूप से इसमें प्लगेबल इंजन और आसान रेप्लिकेशन उपलब्ध थे; इसे चलाने में सरल और read-heavy ऐप्स के लिए अच्छा माना जाता था।
  • कुछ लोगों को इसकी CLI और tooling विकल्पों की तुलना में अधिक “developer-friendly” लगती है।

MySQL बनाम PostgreSQL: फीचर्स और संचालन

  • PostgreSQL को एक अधिक समझदार SQL dialect, समृद्ध फीचर्स (JSONB, partial/expression indexes), और मज़बूत ecosystem के लिए सराहा जाता है।
  • MySQL को operationally अधिक सरल बताया जाता है: आसान upgrades, लंबे समय से मौजूद logical replication, और autovacuum-जैसी tuning का कम दर्द।
  • कुछ लोगों का दावा है कि MySQL का MVCC और threading model तकनीकी रूप से PostgreSQL के process-per-connection plus vacuuming से बेहतर है, हालांकि scaling दावों पर अन्य लोग असहमति जताते हैं।
  • Postgres query planner को अधिक उन्नत माना जाता है, लेकिन यह कभी-कभी बिना आसान forcing के खराब plans चुन सकता है; MySQL का अधिक सीमित planner आपात स्थितियों में अधिक predictable माना जाता है।

Isolation levels, correctness, और defaults

  • चर्चा का केंद्र MySQL का “Repeatable Read” formal model से मेल न खाना और single node पर भी anomalies पैदा करना है।
  • कई लोगों का तर्क है कि default isolation SERIALIZABLE होना चाहिए क्योंकि अधिकांश developers isolation को नहीं समझते; कमजोर levels subtle, कठिन-से-debug bugs पैदा करते हैं।
  • अन्य लोग SERIALIZABLE की performance cost और बार-बार transaction retries पर ज़ोर देते हैं, और इसे केवल तभी अपनाने की वकालत करते हैं जब यह सख़्ती से आवश्यक हो।
  • कुछ लोग अधिकांश apps के लिए केवल दो meaningful levels प्रस्तावित करते हैं: READ COMMITTED और SERIALIZABLE; इनके बीच की हर चीज़ को भ्रमित करने वाली “no man’s land” माना जाता है।
  • Snapshot isolation को read-only queries के लिए मूल्यवान माना जाता है।

Developer practices और locking

  • कई commenters कहते हैं कि developers isolation या consistency के बारे में शायद ही कभी सोचते हैं; वे बस defaults को स्वीकार कर लेते हैं।
  • SELECT … FOR UPDATE और explicit locking anomalies को “ठीक” कर सकते हैं, लेकिन performance, lock contention, और संभावित deadlocks की कीमत पर।
  • लंबे समय तक चलने वाले या बड़े transactions को MVCC के तहत प्रमुख performance और scaling जोखिम बताया गया है।

MySQL variants और व्यापक प्रभाव

  • MariaDB में भी MySQL जैसी ही anomaly classes दिखाई जाती हैं, यहाँ तक कि single-node tests में भी।
  • Aurora MySQL मोटे तौर पर MySQL/InnoDB semantics को बनाए रखता है, हालांकि shared storage और purge के आसपास कुछ cluster-specific quirks मौजूद हैं।
  • Commenters को यह देखकर आश्चर्य होता है कि कितने “व्यावहारिक रूप से काम करने वाले” systems ऐसे engines पर बने हैं जिनमें इतने स्पष्ट consistency artifacts हैं।