पिछले सप्ताह CHAR(10) . पर सम्मेलन में हमने "क्लाउड डेटाबेस" पर एक कार्यशाला की थी। सीधे शब्दों में कहें तो:क्या करें जब उपयोग के मामले की आवश्यकताएं डेटाबेस सर्वर में उपलब्ध संसाधनों से अधिक हो जाएं।
यह पूरे सम्मेलन का एक मुख्य विषय था, और दिन के दौरान कई समाधानों का चित्रण किया गया है। एक सामान्य विषय यह रहा है कि कोई भी समाधान सभी उपयोग के मामलों में फिट नहीं बैठता है, और यह कि प्रत्येक समाधान अपनी लागत के साथ आता है; इसलिए आपको वह समाधान चुनना होगा जो आपके उपयोग के मामले में वहन कर सकता है।
एक और आम (यद्यपि निहित) बिंदु "उच्च-स्तरीय" समाधानों पर ध्यान केंद्रित कर रहा है, वह है:बड़े संसाधनों के साथ एकल सर्वर का अनुकरण करने के लिए उच्च स्तर पर कई डेटाबेस सर्वरों को जोड़ना।
एक स्पष्ट लाभ यह है कि आपको अच्छी तरह से जांचे गए PostgreSQL कोड को बदलने की आवश्यकता नहीं है; एक कमी यह है कि कई डेटाबेस सर्वरों की स्वतंत्र समय-सीमा के साथ उपयोग करने से आप कुछ उपयोगी गुण खो रहे हैं। दो उदाहरण:लेन-देन संबंधी शब्दार्थ का आंशिक नुकसान संघर्ष उत्पन्न करता है; डेटाबेस के बाहर प्रत्येक क्वेरी को पूर्व-पार्सिंग करने से स्वीकृत प्रश्नों की सीमाएँ आती हैं। संसाधन पूलिंग की समस्या वास्तव में अव्यावहारिक होगी। इससे पहले कि मैं विवरण के बारे में विस्तार से बता पाता, कार्यशाला समाप्त हो गई, और मैं केवल कुछ लोगों के लिए विचार को स्केच कर सकता था जो व्हाइटबोर्ड के आसपास थे (जिनमें से गैब्रिएल बार्टोलिनी, निक फेरियर, मार्को क्रेन, हन्नू क्रोसिंग, ग्रेग स्मिथ) एक साथ बुनियादी प्रश्न "क्या यह व्यवहार्य दिखता है?" और "क्या यह किसी ऐसी चीज़ से मिलता-जुलता है जिसे आप पहले से जानते हैं?"।
एक संक्षिप्त स्केच:एक एप्लिकेशन स्टैक को इस तरह से दर्शाया जा सकता है
(application) --> (connection) --> (db server) --> (resources)
जहां डेटाबेस द्वारा उपयोग किए जाने वाले संसाधनों में स्टोरेज, रैम और सीपीयू शामिल हैं। इसका उद्देश्य क्षमता और गति को बढ़ाने के लिए एप्लिकेशन को अधिक संसाधनों को कमांड करने की अनुमति देना है। कई डेटाबेस को प्रबंधित करने वाले "चतुर" अनुप्रयोगों को इस रूप में दर्शाया जा सकता है
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
जबकि "कनेक्शन पूलिंग" समाधानों को
. के रूप में दर्शाया जा सकता है(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
"निचले स्तर" समाधानों से मेरा मतलब कुछ ऐसा है
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
जो कुछ परिचित जैसा हो सकता है, लेकिन यह वह नहीं है जो मैं यहां प्रस्तावित कर रहा हूं। अंतर समझाने के लिए मैं विवरण बढ़ा सकता हूं और लिख सकता हूं
(resources) = (virtual resources) --> (physical resources)
इस तथ्य का प्रतिनिधित्व करने के लिए कि निम्नतम स्तर पर आप भौतिक वस्तुओं और आभासी लोगों के बीच एक गैर-तुच्छ मानचित्रण कर सकते हैं। उदाहरण के लिए, सैन स्टोरेज या RAID स्ट्रिपिंग छोटे भौतिक डिस्क को एक साथ जोड़कर बड़ी वर्चुअल डिस्क प्रदान कर सकता है। ऐसे मामलों को
. के रूप में चित्रित किया जा सकता है(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
मेरा प्रस्ताव डेटाबेस सर्वर . पर संसाधनों को पूल करना है स्तर, ताकि हम प्रत्येक संसाधन (सीपीयू, रैम, डिस्क) के लिए विशिष्ट उपयोग के मामलों के ज्ञान का उपयोग करके अधिक कुशल "वर्चुअलाइजेशन" प्राप्त कर सकें, और साथ ही हम लेन-देन प्रतिमान की कठिनाइयों से बच सकते हैं। तस्वीर होगी:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
लाभ यह है कि हमें प्रत्येक आभासी संसाधन के लिए सभी संभावित उपयोग मामलों को प्रबंधित करने की आवश्यकता नहीं है; हमें केवल उन उपयोग मामलों का प्रबंधन (और अनुकूलन) करना है जो वास्तव में PostgreSQL द्वारा आवश्यक हैं। उदाहरण के लिए:WAL को अभी भी स्थानीय "अनवर्चुअलाइज़्ड" स्टोरेज में लिखा जाना चाहिए, bgwriter स्थानीय और दूरस्थ संसाधनों (RAM और डिस्क) आदि तक पहुँच प्राप्त करेगा।
विश्वसनीयता के बारे में कुछ अंतिम शब्द। पूरे सिस्टम को ठीक से संचालित करने के लिए प्रत्येक सबसिस्टम की आवश्यकता होती है; आंशिक विफलताओं का प्रबंधन नहीं किया जाता है, क्योंकि यह वास्तुकला बेमानी नहीं है। यह एक वितरित प्रणाली है, लेकिन साझा नहीं है। यदि यह आर्किटेक्चर वर्चुअल डेटाबेस सर्वर के माध्यम से सस्ता और सरल स्केलेबिलिटी प्रदान कर सकता है जो कार्यात्मक रूप से बड़े संसाधनों वाले भौतिक सर्वर के बराबर है, तो हॉट स्टैंडबाय कॉन्फ़िगरेशन में दो समान वर्चुअल सर्वर स्थापित करके मानक तरीके से उच्च उपलब्धता प्राप्त की जा सकती है।
नेटवर्क की गुणवत्ता का समग्र प्रदर्शन पर बड़ा प्रभाव पड़ता है; यह डिज़ाइन केवल तभी उपयोगी हो सकता है जब आपके पास एक ही LAN में मशीनों की एक सरणी हो, न केवल गति कारणों से, बल्कि इसलिए भी कि नेटवर्क विफलता वास्तव में एक सिस्टम विफलता होगी। इन प्रतिबंधों के बावजूद, मेरी राय है कि इस विकल्प का होना काफी उपयोगी होगा।
यह अभी भी एक स्केच है, जिसे आगे की चर्चा के लिए एक संदर्भ के रूप में इस्तेमाल किया जा सकता है। अगले संभावित चरण:
- संसाधन उपयोग के मामलों की विस्तृत सूची बनाने के लिए
- यह तय करने के लिए कि प्रत्येक उपयोग के मामले में कौन सी प्रौद्योगिकियां सबसे अच्छी मदद कर सकती हैं
- वास्तविक प्रदर्शन/विकास लागत का अनुमान लगाने के लिए
