Postgres-XL 9.6 . में नया क्या है?

पिछले कुछ महीनों से, हम 2ndQuadrant में PostgreSQL 9.6 को Postgres-XL में मर्ज करने पर काम कर रहे हैं, जो विभिन्न कारणों से काफी चुनौतीपूर्ण साबित हुआ, और कई आक्रामक अपस्ट्रीम परिवर्तनों के कारण शुरू में नियोजित की तुलना में अधिक समय लगा। यदि आप रुचि रखते हैं, तो यहां आधिकारिक भंडार देखें (अभी के लिए "मास्टर" शाखा देखें)।

अभी भी काफी काम किया जाना बाकी है - अपस्ट्रीम से कुछ शेष बिट्स को मर्ज करना, ज्ञात बग्स और रिग्रेशन विफलताओं, परीक्षण इत्यादि को ठीक करना। यदि आप पोस्टग्रेस-एक्सएल में योगदान देने पर विचार कर रहे हैं, तो यह एक आदर्श अवसर है (मुझे एक भेजें ई-मेल और मैं पहले चरणों में आपकी मदद करूंगा)।

लेकिन कुल मिलाकर, Postgres-XL 9.6 स्पष्ट रूप से कई महत्वपूर्ण क्षेत्रों में एक बड़ा कदम है।

Postgres-XL 9.6 में नई सुविधाएं

तो, PostgreSQL 9.6 मर्ज से Postgres-XL को कौन सी नई सुविधाएँ प्राप्त होती हैं? मैं आपको केवल अपस्ट्रीम रिलीज़ नोट्स की ओर संकेत कर सकता हूँ - अधिकांश सुधार सीधे XL 9.6 पर लागू होते हैं, XL पर असमर्थित सुविधाओं से संबंधित अपवादों को छोड़कर।

PostgreSQL 9.6 में मुख्य उपयोगकर्ता-दृश्यमान सुधार स्पष्ट रूप से समानांतर क्वेरी था, और यह Postgres-XL 9.6 पर भी लागू होता है।

इंट्रा-नोड समानांतरवाद

PostgreSQL 9.6 से पहले, Postgres-XL समानांतर प्रश्न प्राप्त करने के तरीकों में से एक था (एक ही मशीन पर कई Postgres-XL नोड्स रखकर)। चूंकि PostgreSQL 9.6 अब आवश्यक नहीं है, लेकिन इसका मतलब यह भी है कि Postgres-XL इंट्रा-नोड समानांतर क्षमता हासिल करता है।

तुलना के लिए, यह वही है जो Postgres-XL 9.5 ने आपको करने की अनुमति दी है - एक क्वेरी को कई डेटा नोड्स में वितरित करना, लेकिन प्रत्येक डेटा नोड अभी भी सादे PostgreSQL की तरह "एक बैकएंड प्रति क्वेरी" सीमा के अधीन था।

PostgreSQL 9.6 समानांतर क्वेरी सुविधा के लिए धन्यवाद, Postgres-XL 9.6 अब यह कर सकता है:

अर्थात्, प्रत्येक डेटा नोड अब अपस्ट्रीम समानांतर क्वेरी इन्फ्रास्ट्रक्चर का उपयोग करके क्वेरी के अपने हिस्से को समानांतर में चला सकता है। जब विश्लेषणात्मक कार्यभार की बात आती है तो यह बहुत अच्छा होता है और Postgres-XL को और अधिक शक्तिशाली बनाता है।

एक कांटा बनाए रखना

मैंने उल्लेख किया है कि यह विलय कई कारणों से शुरू में हमारी अपेक्षा से अधिक चुनौतीपूर्ण निकला।

सबसे पहले, सामान्य रूप से कांटे को बनाए रखना कठिन है, खासकर जब अपस्ट्रीम प्रोजेक्ट पोस्टग्रेएसक्यूएल के रूप में तेजी से आगे बढ़ रहा है। आपको अपने कांटे के लिए विशिष्ट विशेषताओं को विकसित करने की आवश्यकता है, यही वजह है कि कांटे पहले स्थान पर मौजूद हैं। लेकिन आप भी अपस्ट्रीम के साथ बने रहना चाहते हैं, अन्यथा आप निराशाजनक रूप से पीछे रह जाते हैं। यही कारण है कि कुछ मौजूदा कांटे अभी भी PostgreSQL 8.x पर अटके हुए हैं, तब से किए गए सभी उपहारों को याद कर रहे हैं।

दूसरे, पिछले सभी (9.5, 9.2,…) की तरह, एक बड़ी गांठ में विलय किया गया था। यानी, सभी अपस्ट्रीम कमिट्स को सिंगल गिट मर्ज कमांड में मर्ज कर दिया गया था। यह बहुत सारे मर्ज संघर्षों का कारण बनने की गारंटी है, इस हद तक कि कोड संकलित भी नहीं करता है, चल रहे प्रतिगमन परीक्षण या ऐसा कुछ भी उल्लेख नहीं करने के लिए।

तो फिक्स का पहला बैच इसे एक संकलित स्थिति में लाने के बारे में है, अगला बैच इसे वास्तव में तत्काल सेगफॉल्ट के बिना चलाने के बारे में है, और फिर अंत में "नियमित" फिक्सिंग शुरू होता है (प्रतिगमन परीक्षण चलाएं, मुद्दों को ठीक करें, कुल्ला और दोहराएं) ।

ये जटिलताएं फोर्क रखरखाव के लिए अंतर्निहित हैं (और एक कारण है कि आपको शायद एक और कांटा शुरू करने पर पुनर्विचार करना चाहिए, और इसके बजाय सीधे पोस्टग्रेज़ और/या पोस्टग्रेस-एक्सएल में योगदान देना चाहिए)।

लेकिन प्रभाव को महत्वपूर्ण रूप से कम करने के तरीके हैं - उदाहरण के लिए हम अगले विलय (PostgreSQL 10 के साथ) को छोटे टुकड़ों में करने की योजना बना रहे हैं। इससे मर्ज विरोधों की सीमा कम होनी चाहिए और हमें विफलताओं को बहुत तेज़ी से हल करने की अनुमति मिलनी चाहिए।

PostgreSQL के करीब

दिलचस्प रूप से पर्याप्त है, अपस्ट्रीम से समानांतरवाद को अपनाने से हमें XL कोडबेस से बहुत सारे कोड से छुटकारा पाने की अनुमति मिली - इसका एक प्रमुख उदाहरण समानांतर एग्रीगेट कोड है, जो आसानी से XL-विशिष्ट कोड को बदल देता है।

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

जब मैं कहता हूं कि विलय ने हमें XL कोड को सरल बनाने और इसे PostgreSQL के करीब बनाने की अनुमति दी, तो मेरा क्या मतलब है? परिवर्तन की मात्रा निर्धारित करने का सबसे सरल तरीका है मिलान करने वाली अपस्ट्रीम शाखा के विरुद्ध "गिट डिफ-स्टेट" करना और संख्याओं की तुलना करना। 9.5 और 9.6 शाखाओं के लिए, परिणाम इस तरह दिखते हैं:

जाहिर है, 9.6 मर्ज अपस्ट्रीम के मुकाबले डेल्टा को काफी कम कर देता है (कुल मिलाकर ~ 14%)। यह अंतर कहां से आता है?

सबसे पहले, उस कमी में से कुछ वास्तविक कोड सरलीकरण के कारण है। इसका एक प्रमुख उदाहरण समानांतर समुच्चय है, जो मूल पोस्टग्रेज-एक्सएल कार्यान्वयन का 1:1 प्रतिस्थापन है। इसलिए हमने अभी इसे हटा दिया है और इसके बजाय अपस्ट्रीम कार्यान्वयन का उपयोग किया है। हम भविष्य में ऐसे और स्थानों को खोजने की उम्मीद करते हैं, और अपने स्वयं के बनाए रखने के बजाय अपस्ट्रीम कार्यान्वयन का उपयोग करते हैं।

दूसरे, डेड कोड को हटाने से बहुत सी कमी आती है। न केवल हमने कोड के कुछ मृत/पहुंच योग्य बिट्स को कम किया है, हमने कुछ स्रोत फ़ाइलें भी खोजी हैं जिन्हें संकलित भी नहीं किया गया था, और इसी तरह।

आगे क्या है?

इस बिंदु पर हमने b5bce6c1 तक के परिवर्तनों को मर्ज कर दिया है, जो कि वह स्थान है जहां PostgreSQL 9.6 मास्टर से विभाजित होता है। तो PostgreSQL 9.6.2 के साथ पकड़ने के लिए हमें शेष परिवर्तनों को 9.6 शाखा में मर्ज करने की आवश्यकता है। यह ध्यान में रखते हुए कि ज्यादातर केवल बगफिक्स होना चाहिए, जो पूर्ण विलय की तुलना में एक (उम्मीद है) काफी सरल काम होना चाहिए।

बेशक, बग होंगे। वास्तव में, इस बिंदु पर अभी भी कुछ असफल प्रतिगमन परीक्षण हैं। एक्सएल 9.6 की आधिकारिक रिलीज करने से पहले इसे ठीक करने की जरूरत है। और हमें और परीक्षण करने की आवश्यकता है, इसलिए यदि आप Postgres-XL की मदद करने में रुचि रखते हैं, तो यह बेहद फायदेमंद होगा।

एक झुंझलाहट जिसके बारे में हम सुनते रहते हैं वह है पैकेज, या उनकी कमी। आपने देखा होगा कि उपलब्ध अंतिम पैकेज काफी पुराने हैं, और केवल .rpm है, और कुछ नहीं। हम इसे संबोधित करने की योजना बना रहे हैं और कई स्वादों (जैसे .rpm और .deb) में अद्यतित पैकेज पेश करना शुरू कर रहे हैं।

हम विकास प्रक्रिया को व्यवस्थित करने के तरीके में कुछ बदलाव करने की भी योजना बना रहे हैं, ताकि विकास प्रक्रिया में योगदान करना और भाग लेना आसान हो सके। यह वास्तव में 9.6 शाखा से असंबंधित एक अलग विषय है, इसलिए मैं कुछ दिनों में इसके बारे में अधिक विवरण पोस्ट करूंगा।