आपने इसे पिछले महीने हमारा CHAR(10) सम्मेलन बनाया है या नहीं, अब आप सम्मेलन की स्लाइड्स को डाउनलोड करके अनुभव का हिस्सा पुनः प्राप्त कर सकते हैं। उनमें से कुछ को सम्मेलन के दौरान लाइव पोस्ट किया गया था, कुछ को बाद में दिखाया गया था, लेकिन अब लगभग सब कुछ है। अफसोस की बात है कि निक फेरियर की मनोरंजक प्रस्तुति इस बारे में थी कि कैसे लोंडिस्ट का उपयोग करके वूमे (ज़ूस्क द्वारा अधिग्रहित) को बढ़ाया गया था और Django एक ऐसे रूप में उपलब्ध नहीं था जिसे हम आसानी से फिर से चला सकें। उस एक के लिए, आपको निश्चित रूप से एक से अधिक तरीकों से वहां रहना होगा।
मुझे जिन दो वार्ताओं में सबसे अधिक जानकारी मिली, वे थे पीजीपूल-द्वितीय और पीजीमेमकेचे की स्थिति पर अपडेट। उन दोनों टूल में वास्तव में उपयोगी होने का थोड़ा निराशाजनक संयोजन है और वे कितने जटिल हैं (अंग्रेजी में कम से कम!), इसलिए कोड पर वास्तव में काम करने वालों से उनके बारे में अतिरिक्त जानकारी प्राप्त करना बहुत अच्छा था।
एमवीसीसी और क्लस्टरिंग के बारे में मार्कस की चर्चा में भी एक मजेदार मोड़ था। उनकी बात का अंत पीजीपूल-द्वितीय, पोस्टग्रेस-एक्ससी, और पोस्टग्रेएसक्यूएल 9 के खिलाफ उनके पोस्टग्रेज-आर के प्रदर्शन विश्लेषण के साथ हुआ, जिसमें स्ट्रीमिंग प्रतिकृति प्लस हॉट स्टैंडबाय का उपयोग किया गया था, सभी डीबीटी 2 परीक्षा परिणामों में तेजी लाने के लिए क्लस्टर कॉन्फ़िगरेशन में उपयोग किए गए थे। मैं वहां उनके इस सिद्धांत से पूरी तरह सहमत नहीं हूं कि नेटवर्क कंजेशन सबसे महत्वपूर्ण क्लस्टर घटक है क्योंकि "समग्र कंप्यूटिंग शक्ति, मेमोरी और स्टोरेज क्षमता का पैमाना आसानी से" - यह हमेशा सच नहीं होता है - लेकिन यह देखना संतोषजनक था कि पीजी 9 एचएस / एसआर इस संबंध में युग्मन कुशल है।
कॉन्फ्रेंस ने सामान्य क्लस्टरिंग विषयों के बारे में अपेक्षाकृत असंरचित तरीके से बात करने के लिए दो सत्रों को अलग रखा। अधिक गरमागरम चर्चा ने इस बारे में बात की कि क्लाउड कंप्यूटिंग इन्फ्रास्ट्रक्चर में PostgreSQL की तैनाती से निपटने में क्या आसान होगा। इसने मेरे सहकर्मियों से पहले से ही दो ब्लॉग प्रविष्टियाँ उत्पन्न करने के लिए पर्याप्त विचारों को उभारा।
उस सत्र के विचारों में से एक जो मुझे विशेष रूप से दिलचस्प लगा, वह यह नोट कर रहा था कि यदि आपके पास एक परिनियोजन है जहाँ नोड्स को "लोचदार" तरीके से जोड़ा जाता है जिसे लोग पसंद करते हैं क्लाउड अवधारणा के संबंध में चर्चा करने के लिए, अनुप्रयोगों के लिए उस नोड सेट से बात करना आसान बनाने के मामले में अभी एक प्रबंधनीयता अंतर है। यदि आप अपने एप्लिकेशन और नोड्स के सेट के बीच pgpool-II या pgBouncer रख सकते हैं, तो आप अभी नोड्स के पीछे जो कुछ भी है उसे दूर कर सकते हैं। लेकिन अब आपने एक और परत जोड़ दी है और इसलिए पूरी चीज़ में एक संभावित अड़चन है। यह इलास्टिक क्लाउड परिनियोजन के बारे में माना जाता है कि इसके विपरीत है:न्यूनतम प्रबंधन कार्य के साथ केवल आवश्यकतानुसार क्षमता जोड़ना।
एक समाधान दृष्टिकोण का सुझाव दिया गया था जो एप्लिकेशन स्तर पर डेटाबेस रूटिंग निर्देशिका बनाना आसान बना रहा था, ताकि ऐप्स केवल आवश्यक नोड के प्रकार के लिए पूछ सकते हैं और एक को सीधे कनेक्ट करने के लिए प्राप्त कर सकते हैं। नोड्स खुद को निर्देशिका में पंजीकृत कर सकते हैं क्योंकि उन्हें ऑनलाइन लाया जाता है (या नीचे ले जाया जाता है)। इसमें कुछ घटकों की समानता है जो पहले से ही तैर रहे हैं। निर्देशिका लुकअप भाग जिसे आप LDAP में डाल सकते हैं; PostgreSQL सर्वर पहले से ही ZeroConf AKA Bonjour के माध्यम से खुद की घोषणा कर सकते हैं। उन दोनों को एक साथ बोल्ट करने की कल्पना करना मुश्किल नहीं है, एक एप्लिकेशन परत डालना जो एलडीएपी लुकअप को रूटिंग बैकएंड से कनेक्ट करता है जो किसी भी प्रोटोकॉल के माध्यम से उपलब्ध नोड्स को ट्रैक करता है। हमेशा की तरह, शैतान विवरण में है। विफल नोड्स का समय समाप्त करना, पढ़ने और लिखने के ट्रैफ़िक के बीच अंतर करना (pgpool-II वास्तव में SQL को पार्स करके करता है, जो महंगा है), और परिणामी निर्देशिका प्रसारण को उच्च प्रदर्शन के लिए कैश्ड बनाना, जबकि कैश अमान्यता की विशेषता सभी मुश्किल कार्यान्वयन विवरण हैं सही पाने के लिए।
पोस्टग्रेएसक्यूएल 9.0 में ऊपर की ओर डेटाबेस आर्किटेक्चर को स्केल करने के लिए पहले से कहीं अधिक तरीके हैं, हालांकि यह समस्या दूर नहीं हो रही है। मुझे यकीन नहीं है कि लोग इसे किस रूप में हल करने जा रहे हैं, लेकिन यह एक सामान्य समस्या है जिसे हल करने लायक है।
