पोस्टग्रेएसक्यूएल प्रक्रियात्मक भाषाएं ओवरहेड (प्लिपथॉन / plsql / pllua…)

12

मैं वास्तविक समय कार्यों के लिए प्रक्रियात्मक भाषाओं के प्रदर्शन में PostgreSQL उपयोगकर्ता परिभाषित कार्यों के बारे में जानकारी खोजने की कोशिश कर रहा हूं ।

वे अंतर्निहित कार्यों की तुलना कैसे करते हैं?
क्या कोई अंतर है (ओवरहेड में) पोस्टग्रैज कॉल कैसे करता है / plpython बनाम plpgsql बनाम pllua फ़ंक्शन का प्रबंधन करता है (मैं पोस्टग्रेज एकीकरण / संदर्भ / डेटा ट्रांसफर पक्ष में दिलचस्पी रखता हूं, केवल वीएम ही नहीं)?
क्या संदर्भ एक बड़ा उपरि है? क्या मैं रियलटाइम डेटा मैपिंग के लिए इसका इस्तेमाल कर सकता हूं (मान लीजिए 1000 प्रश्न / सेकंड)
क्या plpgsql में अन्य निर्धारित / भाषा में उपयोगकर्ता परिभाषित कार्यों को लिखने का कोई लाभ है? पर प्रलेखन वे लाभ की गणना, लेकिन मुझे लगता है कि वे सब PostgreSQL प्रक्रियात्मक भाषाओं पर लागू होते हैं।

संबंधित निष्कर्ष:

postgresql plpgsql plpython

— रॉबर्ट ज़रेम्बा
स्रोत

13

UDFs की व्याख्या की गई भाषाओं में C या बिल्ट-इन फ़ंक्शन में लिखी गई UDF की तुलना में हमेशा बहुत धीमी होती हैं, अन्य सभी चीजें समान होती हैं।
प्रत्येक भाषा बाइंडिंग में पोस्टग्रैसक्यूएल को भाषा से जोड़ने के लिए अलग-अलग कोड होते हैं, अनुकूलन की विभिन्न डिग्री के साथ, कुछ डेटा प्रकारों को पास करने के विभिन्न तरीके आदि। इसलिए भिन्नता निश्चित रूप से मौजूद है। यह तब तक बहुत बड़ा नहीं होना चाहिए जब तक आप एक डेटा प्रकार पास नहीं कर रहे हैं जो एक भाषा से दूसरे की तुलना में बहुत अलग हो जाता है, जैसे एक hstoreस्ट्रिंग के रूप में गुजरता है , और दूसरा इसे एक में कनवर्ट करता है dict।
अस्पष्ट है कि "संदर्भ" क्या है। क्या आप इसे "रियल टाइम डेटा मैपिंग" के लिए उपयोग कर सकते हैं ... अच्छी तरह से, यह निर्भर करता है कि फ़ंक्शन क्या करता है और यदि यह सर्वर पर चल रहा है, तो यह ग्राहकों के लिए, और आपकी आवश्यकताओं के लिए पर्याप्त तेज़ है। तार का एक टुकड़ा कितना लंबा है? बेंचमार्क।
PL / PgSQL लिखने में सरल है, और SQL तक तेजी से पहुंच प्रदान करता है। जब आप बहुत सारे एसक्यूएल के आसपास थोड़ा तर्क लपेटने की आवश्यकता होती है तो यह आम तौर पर बेहतर होता है। यह गणितीय संचालन और जटिल एल्गोरिदम के लिए बहुत धीमा है, इसलिए पीएल / पीजीएसक्यूएल में विशुद्ध रूप से कम्प्यूटेशनल कोड को सी के पक्ष में, या तेज प्रक्रियात्मक भाषा में जब भी संभव हो, से बचना चाहिए।

जब C में PL / PgSQL कोड को फिर से लागू करते हैं तो स्पीडअप नगण्य से 1000 गुना तक भिन्न हो सकते हैं। यह सब इस बात पर निर्भर करता है कि कोड वास्तव में क्या कर रहा है।

(इस तरह के बहु-प्रश्न स्टैक एक्सचेंज के लिए अच्छी तरह से अनुकूल नहीं है क्योंकि इसका निश्चित उत्तर होना कठिन है)

— क्रेग रिंगर
स्रोत

संदर्भ से मेरा मतलब है कि सभी डेटा जो आगे और पीछे एक प्रक्रियात्मक वातावरण में

— रॉबर्ट ज़ेरेम्बा

4

यह बताना बहुत कठिन है। यह वास्तव में आप क्या कर रहे हैं पर निर्भर करता है। उदाहरण के लिए: यदि आपको इसमें बड़े SQL स्टेटमेंट मिले हैं तो PL / pgSQL अद्भुत है - यह वास्तव में पागल हो जाता है यदि आपको सभी प्रकार की ब्रांचिंग, सबस्ट्रिंग मैनेजमेंट और वह सब मिल गया।

आप वास्तव में मामले से परीक्षण करने के लिए मिला है।

— हंस-जुरगेन स्कोनिग
स्रोत

4

क्या संदर्भ एक बड़ा उपरि है? क्या मैं रियलटाइम डेटा मैपिंग के लिए इसका इस्तेमाल कर सकता हूं (मान लीजिए 1000 प्रश्न / सेकंड)

प्रदर्शन हार्डवेयर और आपके कार्यों की जटिलता पर निर्भर करता है। मैंने एक उपकरण बनाया जो 12-कोर सर्वर और एक फ्यूजनियो-कार्ड (कुल लागत 10000 यूरो) पर चलता था और 20 समवर्ती उपयोगकर्ताओं के साथ प्रति सेकंड लगभग 2500 लेनदेन करता था। प्रत्येक लेनदेन डेटा को संसाधित करने और क्लाइंट को कुछ उपयोगी जानकारी वापस करने के लिए 29 संग्रहीत प्रक्रियाओं को कॉल करता है। कुछ फ़ंक्शंस सिर्फ एक क्वेरी को निष्पादित करते हैं, दूसरों को कुछ क्वेरी। कुल में, यह लगभग 200000 INSERT, SELECT और UPDATE स्टेटमेंट प्रति सेकंड निष्पादित करता है।

यह सब PL / SQL, PL / pgSQL और PL / PerlU में लिखा गया है। और मुझे पूरा यकीन है कि सिस्टम तब और भी तेज गति से चल सकता है जब (कुछ) फ़ंक्शन सी में फिर से लिखे गए हों।

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

— फ्रैंक हाइकेंस
स्रोत