डेटाबेस ट्रांज़ैक्शन क्या है?

 (planetscale.com)
2 पॉइंट द्वारा GN⁺ 2026-02-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ट्रांज़ैक्शन डेटाबेस में कई ऑपरेशनों को एक atomic unit के रूप में चलाने की संरचना है, जिसमें read, write, update और delete शामिल होते हैं
  • MySQL और Postgres begin; और commit; के ज़रिए ट्रांज़ैक्शन को नियंत्रित करते हैं, और failure या error होने पर rollback; से बदलाव रद्द करते हैं
  • दोनों डेटाबेस consistent read की गारंटी देते हैं, लेकिन Postgres MVCC (Multi-Version Concurrency Control) का उपयोग करता है, जबकि MySQL undo log का उपयोग करता है
  • isolation level ट्रांज़ैक्शनों के बीच डेटा हस्तक्षेप को नियंत्रित करता है, और इसे Serializable से Read Uncommitted तक चार चरणों में बांटा जाता है
  • Postgres और MySQL concurrent write conflicts को अलग-अलग तरीकों से संभालते हैं; Postgres optimistic validation का उपयोग करता है, जबकि MySQL row-level locking का उपयोग करता है

ट्रांज़ैक्शन की मूल अवधारणा

  • ट्रांज़ैक्शन डेटाबेस में कई SQL ऑपरेशनों को एक atomic execution unit में बांधने की संरचना है
    • यह begin; से शुरू होकर commit; पर समाप्त होता है, और बीच में कई queries चलाई जा सकती हैं
    • commit; के समय सभी बदलाव एक साथ लागू होते हैं
  • अप्रत्याशित विफलता (जैसे बिजली कटना, डिस्क त्रुटि) या जानबूझकर रद्द करने की स्थिति में rollback; से बदलाव वापस कर दिए जाते हैं
    • Postgres recovery के लिए WAL(Write-Ahead Log) का समर्थन करता है
  • ट्रांज़ैक्शन के दौरान बदला गया डेटा isolated रहता है और दूसरे sessions में दिखाई नहीं देता
    • rollback; होने पर सभी बदलाव रद्द हो जाते हैं और डेटाबेस अपनी मूल स्थिति में लौट आता है

Consistent Reads

  • ट्रांज़ैक्शन को चलते समय बाहरी बदलावों से प्रभावित हुए बिना डेटा का एक consistent view बनाए रखना चाहिए
  • MySQL और Postgres REPEATABLE READ मोड या उससे ऊपर के स्तर पर इसे सपोर्ट करते हैं, लेकिन implementation अलग है
    • Postgres: MVCC (Multi-Version Concurrency Control) के ज़रिए हर row के version को manage करता है
    • MySQL: undo log का उपयोग करके पुराने versions को reconstruct करता है

Postgres में Multi-Version Row Storage

  • हर बार row update होने पर एक नया version बनता है; पुराने version में xmax और नए version में xmin के रूप में transaction ID दर्ज होती है
  • ट्रांज़ैक्शन commit होने से पहले दूसरे sessions इन बदलावों को नहीं देख सकते
  • commit के बाद नया version पूरे डेटाबेस में लागू माना जाता है
  • rollback; होने पर बदलाव त्याग दिए जाते हैं और मूल डेटा बना रहता है
  • पुराने row versions को VACUUM FULL command से साफ किया जाता है ताकि storage space वापस पाया जा सके

MySQL का Undo Log

  • MySQL row को सीधे overwrite करता है, लेकिन undo log में पुरानी value रिकॉर्ड करता है ताकि ज़रूरत पड़ने पर उसे restore किया जा सके
  • हर row के पास metadata के रूप में xid (हाल की modification का transaction ID) और ptr (undo log pointer) होता है
  • जब एक साथ कई ट्रांज़ैक्शन चल रहे हों, तो undo log के ज़रिए हर ट्रांज़ैक्शन अपनी ज़रूरत के मुताबिक version चुनकर पढ़ सकता है
  • एक ही row के लिए कई undo log records हो सकते हैं, और उचित version transaction ID के आधार पर चुना जाता है

Isolation Levels

  • यह एक ऐसी setting है जो ट्रांज़ैक्शनों के बीच डेटा हस्तक्षेप को नियंत्रित करती है, और Serializable → Repeatable Read → Read Committed → Read Uncommitted क्रम में ढील बढ़ती जाती है
  • Serializable: सभी ट्रांज़ैक्शन ऐसे व्यवहार करते हैं मानो वे क्रम से चले हों
  • Repeatable Read: एक ही query को दोबारा चलाने पर परिणाम समान रहता है, लेकिन phantom read संभव है
  • Read Committed: दूसरे ट्रांज़ैक्शनों के पहले से commit किए गए बदलाव पढ़े जा सकते हैं
  • Read Uncommitted: dirty read की अनुमति होती है; यह सबसे कम सुरक्षा स्तर है, लेकिन performance अधिक होती है

Concurrent Writes

  • जब दो ट्रांज़ैक्शन एक ही row को एक साथ modify करते हैं, तो उसे संभालने का तरीका डेटाबेस के अनुसार अलग होता है

MySQL: Row-level Locking

  • Shared lock (S lock) में कई ट्रांज़ैक्शन एक साथ read कर सकते हैं
  • Exclusive lock (X lock) में केवल एक ट्रांज़ैक्शन ही row को modify कर सकता है
  • SERIALIZABLE मोड में हर update पर X lock लेना पड़ता है, और conflict होने पर deadlock हो सकता है
  • MySQL deadlock को detect करके किसी एक ट्रांज़ैक्शन को समाप्त कर देता है

Postgres: Serializable Snapshot Isolation

  • Postgres predicate lock का उपयोग करके row set स्तर पर access को track करता है
    • उदाहरण: WHERE id BETWEEN 10 AND 20 शर्त पर लगा lock
  • यह वास्तविक access को block नहीं करता, बल्कि conflict detect करके violation होने पर ट्रांज़ैक्शन समाप्त कर देता है
  • optimistic conflict resolution के ज़रिए deadlock से बचा जाता है
  • MySQL की तरह, conflict होने पर एक ट्रांज़ैक्शन समाप्त हो जाता है और application को retry logic लागू करना चाहिए

निष्कर्ष

  • ट्रांज़ैक्शन डेटाबेस का एक मुख्य घटक है, जो atomicity, consistency, isolation, durability (ACID) की गारंटी देता है
  • Postgres और MySQL एक ही लक्ष्य को अलग-अलग आंतरिक संरचनाओं के ज़रिए हासिल करते हैं
  • चार isolation levels और ट्रांज़ैक्शन के काम करने के तरीके को समझने से डेटाबेस को अधिक स्थिर रूप से चलाया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2026-02-24
Hacker News की राय

  • यह लेख थोड़ा अधूरा लगा
    SQL standard में परिभाषित phenomena के आधार पर isolation levels समझाने के बजाय, serializability की अवधारणा से शुरू करना ज़्यादा सहज लगता है
    serializability को thread safety का सामान्यीकृत रूप माना जा सकता है, और इसे खो देने पर execution order के अनुसार परिणाम बदलने वाले bugs पैदा होते हैं
    डेटाबेस के अलग-अलग isolation levels बस इसी गारंटी के ढीले रूप हैं, और फिर उपयोगकर्ता को दूसरी तरह से गारंटी सुनिश्चित करनी पड़ती है
    phenomena केवल non-serial स्थितियों को visualize करने के tools हैं, serializability से उनका सीधा संबंध नहीं है
    उदाहरण के लिए Kubernetes cluster भी, अगर controller अच्छी तरह डिज़ाइन किए गए हों, serializable तरीके से काम कर सकता है

    • मैं लेखक हूँ। अच्छे feedback के लिए धन्यवाद
      transactions, isolation levels, और MVCC को कई DBs के बीच तुलना सहित एक साथ कवर करना बहुत बड़ा काम है
      technical depth, accessibility, और लेख की लंबाई के बीच संतुलन बनाने की कोशिश की थी
    • Jepsen: MariaDB Galera Cluster विश्लेषण लिंक साझा किया गया
      राय यह है कि और ज़्यादा notation और citations होते तो अच्छा रहता
    • ज़्यादातर RDBMS ज़रूरत पड़ने पर serializable isolation देते हैं
      लेकिन बिना ज़रूरत इसका इस्तेमाल करने पर transactions के बीच coordination cost बढ़ती है, जिससे concurrency और throughput घटते हैं
    • फिर बेहतर व्याख्या सुझाने को कहने वाली प्रतिक्रिया

  • transactions को copy-on-write filesystem (btrfs, zfs) के snapshot की तरह भी सोचा जा सकता है, लेकिन Git branch की उपमा ज़्यादा सहज लगती है
    BEGIN branch बनाना है, UPDATE commit है, ROLLBACK branch हटाना है, और COMMIT git merge जैसा है
    conflict होने पर DB row level पर merge करने की कोशिश करता है, और असफल होने पर config के अनुसार rollback करता है या force merge करता है
    READ UNCOMMITTED तेज़ merge को प्राथमिकता देता है, जबकि SERIALIZABLE सटीकता को
    ऐसी उपमा किसी को transaction की अवधारणा अचानक स्पष्ट करा सकती है

    • (छोटी टिप्पणी) concurrency का संकेत देने वाली प्रतिक्रिया

  • बहुत से लोगों को हैरानी होती है कि Postgres और MySQL डिफ़ॉल्ट रूप से serializable mode में नहीं बल्कि read-committed पर नहीं होते
    performance का अंतर “थोड़ा” नहीं, बल्कि व्यवहार में काफ़ी बड़ा होता है
    read-committed इस्तेमाल करने पर lock प्रबंधन का ध्यान रखना पड़ता है, और race conditions रोकने के लिए UNIQUE constraints भी ज़रूरी होते हैं
    फिर भी serializable mode के performance loss और retry समस्याएँ झेलने के बजाय यही तरीका पसंद है
    संदर्भ: PostgreSQL आधिकारिक दस्तावेज़

    • नए MySQL और MariaDB(InnoDB) में डिफ़ॉल्ट repeatable-read है
      MySQL docs, MariaDB docs देखें
      MyISAM अब लगभग इस्तेमाल नहीं होता
    • SERIALIZABLE की समस्या सिर्फ performance नहीं, बल्कि conflicts, deadlocks, और timeouts के कारण transaction fail हो सकता है
      application को यह detect करके retry strategy रखनी होती है
    • Oracle और SQL Server में भी डिफ़ॉल्ट read committed है
      serializable mode किताबों में अच्छा लगता है, लेकिन व्यवहार में लगभग इस्तेमाल नहीं होता

  • आजकल बहुत से database tools ACID से ज़्यादा real-time update sharing को प्राथमिकता देते हैं
    उदाहरण के लिए Airtable में field बदलते ही वह सहकर्मी की screen पर तुरंत दिखता है, लेकिन transaction न होने से data inconsistency का जोखिम रहता है
    संबंधित बात के लिए VisualDB ब्लॉग पोस्ट देखें

    • प्रतिक्रिया यह है कि यह competitor की आलोचना के बहाने product promotion जैसा दिखता है

  • PlanetScale ब्लॉग पढ़ना सचमुच आनंददायक है
    जिज्ञासा है कि visualization के लिए कौन-सा tool इस्तेमाल हुआ

    • मैं लेखक हूँ। धन्यवाद!
      visualization js + gsap(https://gsap.com) से बनाया गया था

  • अगर इस विषय में रुचि है तो 『Designing Data-Intensive Applications』 की ज़ोरदार सिफारिश है
    इसमें अलग-अलग isolation levels ही नहीं, बल्कि ACID की परिभाषा की अस्पष्टता भी शामिल है
    सुना है कि इसका दूसरा संस्करण जल्द आने वाला है

    • दूसरा संस्करण पहले ही प्रकाशित हो चुका है: O’Reilly लिंक

  • Postgres जैसे MVCC systems में transactions, copy-on-write filesystem के snapshots जैसे लगते हैं
    BEGIN के समय data snapshot बनता है, और UPDATE केवल निजी copy पर लागू होता है
    ROLLBACK होने पर वह copy फेंक दी जाती है, और COMMIT होने पर नया snapshot आधिकारिक version बन जाता है
    यह उपमा किसी को transaction की अवधारणा साफ़ समझाने में मदद कर सकती है
    P.S. Git branch की उपमा भी दी जा सकती है

    • यह पूरी तरह सटीक नहीं है। DB branching और locking दोनों का साथ में उपयोग करता है
      SELECT के बाद UPDATE जैसे मामले में एक thread block हो सकता है
      आज MySQL में इसे single query में बदला जा सकता है या नहीं, यह आज़माने वाला हूँ

  • पहले backend interviews में transaction पर अक्सर सवाल पूछे जाते थे
    सबने इसका इस्तेमाल किया होता है, लेकिन समझ का स्तर अनुभव के अनुसार अलग होता है
    भले ही कोई सारे isolation levels याद न रखे, लेकिन यह जानना कि वे अलग तरह से behave करते हैं, जिज्ञासा और system understanding दिखाने के लिए काफ़ी है

    • एक ही नाम वाले isolation level भी अलग DBs में अलग तरह से काम कर सकते हैं, इसलिए case-by-case detailed behavior देखना चाहिए

  • “phantom read” की व्याख्या गलतफ़हमी पैदा कर सकती है
    repeatable read में मौजूदा rows के values नहीं बदलते, लेकिन नई rows जुड़ सकती हैं
    मौजूदा rows बदलती या delete नहीं होतीं, इसलिए इस बिंदु को साफ़ करना चाहिए

  • “xmin/xmax से इसका संबंध नहीं है” वाला वाक्य अधूरा लगता है
    commit के समय visualization का table header की ओर इशारा करना भी अजीब लगा
    क्या वास्तव में xmax/xmin ही commit status तय करने का मुख्य mechanism नहीं हैं?
    subtransactions को शामिल करें तो बात और जटिल हो जाती है
    फिर भी visualization और व्याख्या कुल मिलाकर पढ़ने में आनंददायक थीं

    • मुझे भी लगा कि xmax/xmin की अवधारणा छूट गई
      isolation levels समझने में यह केंद्रीय है, इसलिए लगा जैसे कोई section गायब हो