कल्पना कीजिए कि आप एक विशाल, अराजक पुस्तकालय को व्यवस्थित करने की कोशिश कर रहे हैं जहाँ लाखों लोग एक ही समय में किताबें उधार लेने, पढ़ने और फिर से लिखने की कोशिश कर रहे हैं। कंप्यूटर विज्ञान की दुनिया में, यह डेटाबेस (databases) की चुनौती है: ऐसे सिस्टम जो जानकारी को इस तरह संग्रहीत करते हैं ताकि एप्लिकेशन उसे तुरंत ढूंढ सकें और बदल सकें। दशकों तक, बड़ा सवाल यह था कि इन पुस्तकालयों को बिना ढहे पूरे इंटरनेट को संभालने के लिए कैसे बढ़ाया जाए। पुराना तरीका एक अकेले लाइब्रेरियन जैसा था जिसे हर किताब पर स्टैम्प लगाना पड़ता था, जिससे एक लंबी कतार बन जाती थी जो सबको धीमा कर देती थी। नया, "इवेंचुअल कंसिस्टेंसी" (eventual consistency) वाला तरीका ऐसा था जैसे लोगों को यह अनुमान लगाने देना कि किताब में क्या लिखा है और बाद में गलतियों को ठीक करना, जो तेज़ तो है लेकिन जोखिम भरा है यदि आपको अभी सच्चाई की आवश्यकता है। आधुनिक डेटाबेस इंजीनियरिंग का लक्ष्य एक ऐसा सिस्टम बनाना है जो अनुमान लगाने वाले तरीके जितना तेज़ हो और स्टैम्प लगाने वाले तरीके जितना विश्वसनीय हो, जो बिना किसी मानवीय प्रबंधन के प्रति सेकंड लाखों ट्रांजेक्शन को संभालने में सक्षम हो।

यह शोध पत्र Aurora DSQL पेश करता है, जो Amazon Web Services द्वारा डिज़ाइन किया गया एक नए प्रकार का डेटाबेस है, जिसे ठीक इसी समस्या को हल करने के लिए बनाया गया है। इसे एक सुपर-स्मार्ट, सेल्फ-ड्राइविंग लाइब्रेरी के रूप में सोचें जो आगंतुकों की संख्या के आधार पर तुरंत फैल या सिकुड़ सकती है। लेखकों ने एक ऐसा सिस्टम बनाया है जो "सोचने" (SQL कोड चलाना) को "स्टोरेज" (किताबों को रखना) और "नियमों" (यह सुनिश्चित करना कि एक ही समय में दो लोग एक ही पन्ने को न बदलें) से अलग करता है। एक विशेष "जर्नल" (Journal) का उपयोग करके, जो हर बदलाव का एक स्थायी, अपरिवर्तनीय डायरी की तरह काम करता है, DSQL सिस्टम के विभिन्न हिस्सों को स्वतंत्र रूप से काम करने की अनुमति देता है। पेपर दिखाता है कि यह डिज़ाइन डेटाबेस को शून्य उपयोगकर्ताओं से लेकर प्रति सेकंड लाखों ट्रांजेक्शन तक स्केल करने देता है, यह विभिन्न महाद्वीपों में बिना धीमे हुए काम करता है, और डेटा को पूरी तरह से सुसंगत (consistent) रखता है ताकि आपको कभी भी ऐसी किताब पढ़ने की चिंता न करनी पड़े जिसे कोई दूसरा व्यक्ति वर्तमान में फिर से लिख रहा है।

विलगित पुस्तकालय का जादू (The Magic of the Disconnected Library)

यह समझने के लिए कि Aurora DSQL कैसे काम करता है, एक विशाल पुस्तकालय की कल्पना करें जहाँ लाइब्रेरियन, बुकशेल्फ़ और नियम-पालक सभी अलग-अलग इमारतों में हैं, जो सुपर-फास्ट टेलीग्राम द्वारा जुड़े हुए हैं। पुराने सिस्टम में, ये हिस्से एक साथ चिपके हुए थे; यदि शेल्फ भर जाते थे, तो पूरे पुस्तकालय को रुकना पड़ता था और पुनर्गठन करना पड़ता था। DSQL इन्हें अलग कर देता है।

सबसे पहले, क्वेरी प्रोसेसर (Query Processors) हैं। ये वे लाइब्रेरियन हैं जो आपसे बात करते हैं। जब आप किसी किताब के बारे में पूछते हैं, तो वे भारी किताबें खुद नहीं उठाते। इसके बजाय, वे Firecracker MicroVMs नामक छोटे, सुरक्षित वर्चुअल कमरों के भीतर चलते हैं। ये कमरे इतने कुशल हैं कि उन्हें पलक झपकते ही बनाया या नष्ट किया जा सकता है। यदि अचानक आगंतुकों की भीड़ बढ़ जाती है, तो सिस्टम तुरंत और अधिक कमरे बना देता है। यदि भीड़ कम हो जाती है, तो यह उन्हें हटा देता है ताकि आप खाली जगह के लिए भुगतान न करें। यह "सर्वरलेस" (serverless) हिस्सा है: आप लाइब्रेरियन का प्रबंधन नहीं करते; वे बस तभी दिखाई देते हैं जब आपको उनकी आवश्यकता होती है।

इसके बाद, स्टोरेज नोड्स (Storage Nodes) हैं। ये बुकशेल्फ़ हैं। वे पूरे पुस्तकालय को नहीं रखते; वे केवल एक "शार्ड की" (shard key) के आधार पर किताबों के विशिष्ट खंड रखते हैं (जैसे लेखक के नाम के पहले अक्षर के आधार पर किताबें छाँटना)। क्योंकि लाइब्रेरियन और शेल्फ अलग-अलग हैं, इसलिए लाइब्रेरियन शेल्फ के पीछे चलने का इंतज़ार किए बिना अपना काम चला सकते हैं। वे अपने स्वयं के पड़ोस (Availability Zone) के निकटतम शेल्फ से पढ़ते हैं, जो पढ़ने की प्रक्रिया को अविश्वसनीय रूप से तेज़ बनाता है।

अंत में, एडजुडिकेटर्स (Adjudicators) और जर्नल (Journal) हैं। एडजुडिकेटर्स वे नियम-पालक हैं जो तय करते हैं कि क्या कोई बदलाव मान्य है। जर्नल मास्टर डायरी है। जब आप किसी किताब को बदलना चाहते हैं (एक "राइट" या लेखन), तो लाइब्रेरियन बदलाव को कागज के एक टुकड़े पर लिखता है लेकिन उसे अभी शेल्फ पर नहीं रखता। वे इसे नियम-पालक को भेजते हैं। नियम-पालक जाँच करता है कि क्या कोई और भी उसी समय उसी किताब को बदलने की कोशिश कर रहा है। यदि सब स्पष्ट है, तो नियम-पालक उस बदलाव को जर्नल में लिख देता है। यह जर्नल सबसे महत्वपूर्ण हिस्सा है: यह हर उस बदलाव की एक स्थायी, क्रमबद्ध सूची है जो कभी भी हुआ है। एक बार जब कुछ जर्नल में आ जाता है, तो वह हमेशा के लिए सुरक्षित होता है, भले ही शेल्फ या लाइब्रेरियन गायब हो जाएं।

"नो-वेट" (No-Wait) रीडिंग ट्रिक

इस पेपर की सबसे शानदार ट्रिक्स में से एक यह है कि यह पढ़ने (reading) को कैसे संभालता है। कई डेटाबेस में, यदि आप कोई किताब पढ़ना चाहते हैं, तो आपको लाइब्रेरियन के यह सुनिश्चित करने तक प्रतीक्षा करनी पड़ती है कि कोई वर्तमान में उसमें लिख तो नहीं रहा है। इससे लाइनें और देरी होती है। DSQL एक चतुर टाइम-ट्रैवल ट्रिक का उपयोग करता है जिसे मल्टी-वर्जन कंसिस्टेंसी कंट्रोल (MVCC) कहा जाता है।

कल्पना कीजिए कि जब भी किसी किताब को बदला जाता है, पुस्तकालय पुराने संस्करण को मिटाता नहीं है। इसके बजाय, यह एक टाइमस्टैम्प के साथ एक नई प्रति बनाता है। जब आप किसी किताब के लिए पूछते हैं, तो आप "किताब" नहीं मांगते; आप "किताब जैसा कि वह दोपहर 2:00 बजे थी" मांगते हैं। सिस्टम फिर उस संस्करण को खोज लेता है जो 2:00 बजे वैध था। क्योंकि सिस्टम अत्यंत सटीक घड़ियों (माइक्रोसेकंड तक सटीक) का उपयोग करता है, इसलिए यह जानता है कि आपको कौन सा संस्करण दिखाना है। इसका मतलब है कि आप किसी और के नया संस्करण लिखते समय भी किताब पढ़ सकते हैं, और आप उनके अधूरे या अस्त-व्यस्त बदलावों को नहीं देखेंगे। आप अतीत का एक पूर्ण, स्थिर स्नैपशॉट देखते हैं। यह लाखों लोगों को एक-दूसरे को रोके बिना एक साथ पढ़ने की अनुमति देता है।

मल्टी-रीजन सुपरपावर (The Multi-Region Superpower)

पेपर दूरी की समस्या को भी संबोधित करता है। आमतौर पर, यदि आपके पास न्यूयॉर्क में एक पुस्तकालय और लंदन में एक पुस्तकालय है, तो उन्हें सिंक में रखने में समय लगता है क्योंकि प्रकाश की गति सीमित है। यदि आप एक ही समय में दोनों जगहों पर किताब को अपडेट करने की कोशिश करते हैं, तो आपको संदेश के महासागर पार करने का इंतज़ार करना पड़ता है, जो सब कुछ धीमा कर देता है।

DSQL इसे एक्टिव-एक्टिव (active-active) होकर हल करता है। इसका मतलब है कि आप न्यूयॉर्क में एक पुस्तकालय और लंदन में एक पुस्तकालय रख सकते हैं, और दोनों एक ही समय में पूरी तरह से व्यवसाय के लिए खुले हैं। जब आप न्यूयॉर्क में कोई बदलाव करते हैं, तो सिस्टम इसे जर्नल में लिखता है। जर्नल फिर लंदन को इसकी एक प्रति भेजता है। जादू यह है कि यह केवल एक बार होता है, ठीक उसी क्षण जब आप "कमिट" (लेनदेन पूरा करना) करते हैं। सिस्टम आपको संदेश यात्रा करने के दौरान पढ़ने या लिखने से नहीं रोकता है। यह एक "कोरम" (quorum) सिस्टम का उपयोग करता है, जिसका अर्थ है कि इसे सुरक्षित कहने के लिए इसे तीन क्षेत्रों में से केवल दो में परिवर्तन की पुष्टि करने की आवश्यकता होती है।

लेखकों ने इसका मापन किया और पाया कि वर्जीनिया और ओरेगन के बीच की दूरी (लगभग 62 मिलीसेकंड राउंड-ट्रिप) के बावजूद, सिस्टम प्रत्येक ट्रांजेक्शन के लिए केवल एक बार उस "दूरी टैक्स" का भुगतान करता है। पढ़ने के लिए, यह और भी तेज़ है क्योंकि आप स्थानीय पुस्तकालय से पढ़ते हैं। लेखक बताते हैं कि यह डिज़ाइन डेटाबेस को तेज़ और सुसंगत रहने की अनुमति देता है, भले ही किसी आपदा के कारण एक पूरा क्षेत्र (जैसे कि एक पूरा शहर) ऑफलाइन हो जाए।

खेल के नियम (The Rules of the Game)

लेखक इस बात को लेकर बहुत सावधान थे कि उन्होंने क्या वादा किया है। उन्होंने स्नैपशॉट आइसोलेशन (Snapshot Isolation) को चुना, जो लेनदेन के व्यवहार के लिए नियमों का एक विशिष्ट सेट है। यह कहने जैसा है कि, "आप किताब को वैसा पढ़ सकते हैं जैसी वह आपके पढ़ने शुरू करने के समय थी, और आप इसे तब बदल सकते हैं जब आप इसे समाप्त करते हैं, लेकिन यदि इस बीच किसी और ने इसे बदल दिया है, तो आपको फिर से प्रयास करना होगा।" यह उन सख्त नियमों से अलग है जो आपको लॉक (lock) के लिए प्रतीक्षा करने के लिए मजबूर करेंगे, जो चीजों को धीमा कर देता है।

पेपर स्पष्ट रूप से इस विचार को खारिज करता है कि आपको सब कुछ प्रबंधित करने के लिए एक एकल "लीडर" की आवश्यकता है। कई सिस्टम में, एक कंप्यूटर बॉस होता है, और यदि वह टूट जाता है, तो सब कुछ रुक जाता है। DSQL में कोई एकल बॉस नहीं है। प्रत्येक भाग स्केल अप या डाउन हो सकता है, और यदि एक भाग विफल हो जाता है, तो अन्य चलते रहते हैं। पेपर इस विचार को भी खारिज करता है कि आपको अपना हार्डवेयर स्वयं प्रबंधित करने की आवश्यकता है। सिस्टम "गर्मी" (कौन से हिस्से बहुत व्यस्त हो रहे हैं) को स्वचालित रूप से संभालता है। यदि पुस्तकालय का कोई हिस्सा बहुत भीड़भाड़ वाला हो जाता है, तो कंट्रोल प्लेन (लाइब्रेरी मैनेजर) उसे स्वचालित रूप से दो छोटे हिस्सों में विभाजित कर देता है और कुछ किताबें एक नए शेल्फ पर स्थानांतरित कर देता है, और यह सब आपके बिना कुछ किए होता है।

सिद्धांत का परीक्षण (Testing the Theory)

लेखकों ने केवल यह अनुमान नहीं लगाया कि यह काम करेगा; उन्होंने इसका गहन परीक्षण किया। उन्होंने डिटरमिनिस्टिक सिमुलेशन (deterministic simulation) नामक एक विधि का उपयोग किया, जहाँ उन्होंने एक कंप्यूटर प्रोग्राम चलाया जो एक सेकंड के अंश में लाखों त्रुटियों, नेटवर्क विलंब और क्रैश का अनुकरण कर सकता था। उन्होंने पाया कि सिस्टम डेटा खोए बिना या भ्रमित हुए इन त्रुटियों को संभाल सकता है।

उन्होंने वास्तविक दुनिया के स्टाइल के परीक्षण भी चलाए (जैसे TPC-C बेंचमार्क, जो एक व्यस्त स्टोर का अनुकरण करता है)। परिणामों ने दिखाया कि DSQL कोल्ड स्टार्ट (जहाँ इसके पास बहुत कम संसाधन होते हैं) से लेकर प्रति मिनट लाखों ऑपरेशन्स संभालने तक स्केल कर सकता है। इसे पूरी तरह से खाली अवस्था से पूर्ण गति तक पहुँचने में लगभग 25 मिनट लगे, लेकिन एक बार गर्म होने के बाद, यह अविश्वसनीय रूप से तेज़ था। पेपर नोट करता है कि हालांकि वे इन परिणामों को लेकर बहुत आश्वस्त हैं, वे अभी भी फॉरेन कीज़ (जो तालिकाओं को जोड़ती हैं) और स्टोर्ड प्रोसीजर जैसे अधिक फीचर्स जोड़ने पर काम कर रहे हैं।

निष्कर्ष (The Bottom Line)

Aurora DSQL इस बात का प्रमाण है कि आप सर्वश्रेष्ठ दोनों दुनिया पा सकते हैं: एक ऐसा डेटाबेस जो एक सरल सेवा (जहाँ आप कुछ भी प्रबंधित नहीं करते) की तरह उपयोग करने में आसान है और एक विशाल, वैश्विक प्रणाली की तरह शक्तिशाली है। सोचने, स्टोरेज और नियमों को अलग करके, और समय का पता लगाने के लिए एक स्थायी जर्नल का उपयोग करके, यह अनुप्रयोगों को बिना किसी परेशानी के शून्य से लाखों ट्रांजेक्शन तक बढ़ने की अनुमति देता है। यह एक ऐसा सिस्टम है जिसे ऐसी दुनिया के लिए डिज़ाइन किया गया है जहाँ चीजें तेज़ी से बदलती हैं, आपदाएँ आती हैं, और जहाँ आपको यह जानने की आवश्यकता होती है कि आप जो जानकारी पढ़ रहे हैं वह अभी के अभी पूर्ण सत्य है।