Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC
यह शोध पत्र वास्तविक समय में डेटाबेस सिंक्रोनाइज़ेशन के लिए REST पोलिंग, WebSocket पुश, और CockroachDB CDC आर्किटेक्चर की तुलना करने वाले एक नियंत्रित बेंचमार्क को प्रस्तुत करता है, जो यह प्रकट करता है कि जहाँ WebSocket पुश सबसे कम मध्यिका (median) विलंबता प्रदान करता है और REST पोलिंग अनुमानित सीमित विलंब प्रदान करता है, वहीं CDC प्रतिस्पर्धी मध्यिकाओं को वितरित करता है लेकिन बैचिंग और विशिष्ट प्रोटोकॉल असंगतताओं के कारण महत्वपूर्ण टेल लेटेंसी (tail latency) से ग्रस्त होता है।
मूल पेपर CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
आधुनिक सॉफ्टवेयर की दुनिया में, ऐसे अनुप्रयोगों की बढ़ती इच्छा है जो आपके डिवाइस पर जीवित महसूस हों, भले ही आप इंटरनेट से जुड़े न हों। यह दृष्टिकोण, जिसे अक्सर 'लोकल-फर्स्ट सॉफ्टवेयर' कहा जाता है, आपको ऑफलाइन रहते हुए भी एक दस्तावेज़ को संपादित करने या सूची को अपडेट करने की अनुमति देता है, जिसमें परिवर्तन आपके कनेक्शन वापस आने पर केंद्रीय सर्वर को भेजे जाने के लिए प्रतीक्षा करते हैं। चुनौती उस क्षण में निहित है जब कनेक्शन बहाल होता है: कंप्यूटर यह कैसे तय करता है कि डेटा का कौन सा संस्करण सही है, और वह कितनी जल्दी केंद्रीय सर्वर को अपडेट कर सकता है ताकि उपयोगकर्ता को प्रतीक्षा न करनी पड़े? सुचारू रूप से काम करने के लिए, सिस्टम को नई जानकारी सुनने और उसे तुरंत वितरित करने का एक विश्वसनीय तरीका चाहिए। यदि अपडेट बहुत धीमा है, तो उपयोगकर्ता को लैग (lag) महसूस होगा; यदि सिस्टम बहुत जटिल है, तो यह बैटरी को खत्म कर देगा या क्रैश हो जाएगा। इंजीनियरों के लिए मुख्य प्रश्न यह है कि इस सुनने वाली प्रक्रिया (listening mechanism) को कैसे बनाया जाए: क्या डिवाइस को लगातार सर्वर से पूछना चाहिए कि क्या कुछ बदला है, क्या सर्वर को परिवर्तनों को तुरंत चिल्लाकर (shout) बताना चाहिए, या क्या डेटाबेस को बाद में पढ़े जाने के लिए हर क्रिया का एक चलता-फिरता लॉग रखना चाहिए?
भारतीय प्रौद्योगिकी संस्थान खड़गपुर के एक शोधकर्ता ने यह देखने के लिए इन तीन सामान्य रणनीतियों को एक नियंत्रित वातावरण में आमने-सामने परखने का निर्णय लिया कि वास्तव में कौन सा सबसे अच्छा प्रदर्शन करता है। अध्ययन ने एक ऐसी विधि की तुलना की जहाँ क्लाइंट निश्चित समय अंतराल पर अपडेट की जाँच करता है, एक ऐसी विधि की जहाँ सर्वर एक स्थायी कनेक्शन के माध्यम से परिवर्तनों को तुरंत भेजता है, और एक ऐसी विधि की जहाँ डेटाबेस सब्सक्राइबरों को परिवर्तनों के लॉग को स्ट्रीम करता है। एक निष्पक्ष परीक्षण सुनिश्चित करने के लिए, शोधकर्ता ने तीन अलग-अलग सिस्टम बनाए जो उपयोगकर्ता के लिए समान दिखते थे लेकिन उनके आंतरिक पुर्जे अलग थे। एक सिस्टम ने एक मानक डेटाबेस का उपयोग किया जिसमें एक सरल "चेक-इन" लूप था। दूसरे ने उसी डेटाबेस का उपयोग किया लेकिन इसमें एक ट्रिगर जोड़ा गया जो बदलाव होने के क्षण में एक सिग्नल सक्रिय करता था। तीसरे ने एक अलग, वितरित (distributed) डेटाबेस का उपयोग किया जिसे अपने इतिहास को स्ट्रीम करने के लिए डिज़ाइन किया गया था। लक्ष्य यह मापना था कि एक उपयोगकर्ता द्वारा किए गए बदलाव को सिस्टम के माध्यम से यात्रा करने और सुनने वाले (listener) की स्क्रीन पर दिखने में बिल्कुल कितना समय लगता है, जिसमें एक एकल उपयोगकर्ता से लेकर एक साथ लिखने वाले पचास उपयोगकर्ताओं तक का परीक्षण किया गया।
परिणामों ने एक स्पष्ट तस्वीर पेश की कि दबाव में प्रत्येक विधि कैसे व्यवहार करती है। वह सिस्टम जो एक स्थायी कनेक्शन के माध्यम से तुरंत परिवर्तन चिल्लाकर भेजने (server pushing) पर निर्भर था, सबसे तेज़ साबित हुआ। सर्वोत्तम मामलों में, एक बदलाव सुनने वाले की स्क्रीन पर केवल दो मिलीसेकंड में दिखाई दिया, और जब पचास लोग एक साथ लिख रहे थे, तब भी विलंब (delay) शायद ही कभी साठ-तीन मिलीसेकंड से अधिक हुआ। इस विधि ने अपनी गति को उल्लेखनीय रूप से स्थिर रखा, जहाँ सबसे धीमी अपडेट भी एक चौथाई सेकंड से कम समय में पहुँच गई। वह विधि जो क्लाइंट को हर सौ मिलीसेकंड में अपडेट के लिए पूछने पर निर्भर थी, अनुमानित (predictable) लेकिन धीमी थी। क्योंकि क्लाइंट को पूछने के लिए अपनी बारी का इंतजार करना पड़ता था, औसत विलंब लगभग साठ मिलीसेकंड था, लेकिन यह जाँचों के बीच के समय से तेज़ नहीं हो सकता था। जब कई उपयोगकर्ताओं ने एक साथ लिखा, तो यह प्रतीक्षा समय बढ़ गया, जिससे औसत विलंब सौ मिलीसेकंड से ऊपर चला गया। उस सिस्टम ने जो डेटाबेस के आंतरिक लॉग का उपयोग करता था, मिश्रित प्रदर्शन दिखाया। हालांकि विशिष्ट अपडेट तेजी से आए, जो अक्सर एक सेकंड से कम समय में होते थे, लेकिन इस सिस्टम को कुछ सबसे धीमी अपडेट्स के लिए गंभीर विलंब का सामना करना पड़ा। कभी-कभी, एक बदलाव को आने में दो सेकंड से अधिक का समय लग गया, और कुछ मामलों में, विलंब साढ़े तीन सेकंड से अधिक बढ़ गया।
शोधकर्ता ने पाया कि लॉग-आधारित सिस्टम में सबसे धीमी अपडेट्स का कारण लॉगिंग की विचार प्रक्रिया में दोष नहीं था, बल्कि यह था कि विशिष्ट सॉफ़्टवेयर कैसे जुड़ा हुआ था। सिस्टम ने डेटाबेस लॉग को पढ़ने के लिए एक वर्कअराउंड (workaround) का उपयोग किया क्योंकि मानक कनेक्शन टूल डेटाबेस की भाषा को सही ढंग से नहीं बोल पा रहा था। इस वर्कअराउंड के लिए कनेक्शन बाधित होने पर हर बार एक नई प्रक्रिया शुरू करने की आवश्यकता थी, जिसने विलंब में एक से चार सेकंड का भारी दंड (penalty) जोड़ दिया। इस विशिष्ट तकनीकी बाधा के बिना, लॉग-आधारित विधि बहुत बेहतर प्रदर्शन कर सकती थी, लेकिन इस परीक्षण में, लंबे विलंब ने इसे इंटरैक्टिव उपयोग के लिए अनुपयुक्त बना दिया। अध्ययन ने जाँच पद्धति के लिए एक सरल नियम की भी पुष्टि की: आप जाँचों के बीच जितना लंबा इंतजार करेंगे, औसत विलंब उतना ही अधिक होगा। यदि सिस्टम हर पचास मिलीसेकंड में जाँच करता है, तो औसत प्रतीक्षा लगभग छत्तीस मिलीसेकंड होती है; यदि यह पाँच सौ मिलीसेकंड के बीच प्रतीक्षा करता है, तो औसत प्रतीक्षा बढ़कर तीन सौ मिलीसेकंड से अधिक हो जाती है।
ये निष्कर्ष उन सॉफ़्टवेयर को बनाने के लिए एक व्यावहारिक मार्गदर्शिका प्रदान करते जिन्हें सिंक (sync) में रहने की आवश्यकता है। उन अनुप्रयोगों के लिए जहाँ गति महत्वपूर्ण है, जैसे कि सहयोगात्मक संपादन उपकरण (collaborative editing tools) जहाँ उपयोगकर्ता वास्तविक समय में एक साथ टाइप करते हैं, वह विधि जहाँ सर्वर तुरंत परिवर्तन भेजता है, स्पष्ट विकल्प है। यह सबसे कम विलंब और सबसे सुसंगत प्रदर्शन प्रदान करता है, भले ही कई लोग एक साथ सिस्टम का उपयोग कर रहे हों। वह विधि जहाँ क्लाइंट नियमित अंतराल पर अपडेट की जाँच करता है, उन सरल अनुप्रयोगों के लिए एक ठोस विकल्प है जहाँ कुछ सौ मिलीसेकंड का विलंब स्वीकार्य है, या जहाँ कनेक्शन को खुला रखना कठिन है, जैसे कि बैटरी बचाने की कोशिश कर रहे मोबाइल डिवाइस पर। वह विधि जो डेटाबेस लॉग को स्ट्रीम करती है, बड़े पैमाने पर डेटा ले जाने या बैकअप बनाने के लिए शक्तिशाली है, लेकिन यहाँ परीक्षण किया गया विशिष्ट कार्यान्वयन इंटरैक्टिव उपयोग के लिए बहुत धीमा और अप्रत्याशित था। अध्ययन निष्कर्ष निकालता है कि जबकि तीनों विधियाँ काम करती हैं, सबसे अच्छा चुनाव पूरी तरह से इस बात पर निर्भर करता है कि प्राथमिकता तत्काल प्रतिक्रिया (instant responsiveness) है या परिचालन सरलता (operational simplicity)।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।