आर्किटेक्चरल एस्ट्रोनॉट्स के लिए SQLAlchemy एक्सेलेरेशन

हेबर, यह मॉस्को में मॉस्को पायथन कॉन्फ ++ 2018 सम्मेलन में सॉफ्टवेयर इंजीनियर एलेक्सी स्टार्कोव की एक रिपोर्ट है। पोस्ट के अंत में वीडियो।

सभी को नमस्कार! मेरा नाम अलेक्सई स्टार्कोव है - यह मैं हूं, मेरे सबसे अच्छे वर्षों में, मैं एक कारखाने में काम करता हूं।
अब मैं Qrator Labs पर काम करता हूँ। मूल रूप से, मेरे पूरे जीवन में, मैंने सी और सी ++ का अध्ययन किया - मुझे अलेक्जेंड्रेस्कु, द गैंग ऑफ फोर, सॉलिड के सिद्धांत - बहुत पसंद हैं। जो मुझे एक वास्तुशिल्प अंतरिक्ष यात्री बनाता है। मैं पिछले कुछ वर्षों से पायथन लिख रहा हूं क्योंकि मुझे यह पसंद है।

वास्तव में, "वास्तुशिल्प ब्रह्मांड" कौन हैं? जब मैं पहली बार जोएल स्पोल्स्की के साथ इस शब्द से मिला, तो आपने शायद इसे पढ़ा। वह "अंतरिक्ष यात्रियों" का वर्णन उन लोगों के रूप में करता है जो एक आदर्श वास्तुकला का निर्माण करना चाहते हैं जो अमूर्त पर, अमूर्त पर, अमूर्त पर लटका हुआ है, जो अधिक से अधिक सामान्य हो रहा है। अंत में, ये स्तर इतने अधिक हो जाते हैं कि वे सभी संभावित कार्यक्रमों का वर्णन करते हैं, लेकिन किसी भी व्यावहारिक समस्या का समाधान नहीं करते हैं। इस समय, "अंतरिक्ष यात्री" (यह अंतिम बार यह शब्द उद्धरण चिह्नों से घिरा हुआ है) हवा से बाहर चलाता है और वह मर जाता है।

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

मेरी रिपोर्ट का सारांश: था / था।



हजारों और लाखों बार की वृद्धि। जब मैंने यह स्लाइड बनाई, तो केवल यही सोचा था कि मैं "कैसे?"



मैं इतना पेंच कहां कर सकता था? यदि आप मेरी तरह पंगा नहीं लेना चाहते हैं - पर पढ़ें।



मैं विन्यास प्रणाली के बारे में बात करूंगा। कॉन्फ़िगरेशन सिस्टम Qrator Labs में एक आंतरिक उपकरण है जो सॉफ़्टवेयर डिफ़ाइंड नेटवर्क (SDN) - हमारे फ़िल्टरिंग नेटवर्क के लिए कॉन्फ़िगरेशन संग्रहीत करता है। यह घटकों के बीच कॉन्फ़िगरेशन को सिंक्रनाइज़ करने और इसकी स्थिति की निगरानी के लिए प्रतिबद्ध है।



संक्षेप में, इसमें क्या है? हमारे पास एक डेटाबेस है जो पूरे नेटवर्क के लिए हमारे कॉन्फ़िगरेशन का एक स्नैपशॉट संग्रहीत करता है, और हमारे पास एक सर्वर है जो इसके पास आने वाले आदेशों को संसाधित करता है और किसी तरह कॉन्फ़िगरेशन को बदलता है।

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

टीमें या तो बहुत सरल या अधिक जटिल हो सकती हैं। फिर, हमारे पास कुछ निश्चित रिसीवर हैं जो हमारे SDN को बनाते हैं और सर्वर इन रिसीवरों में कॉन्फ़िगरेशन को आगे बढ़ाता है। यह बहुत सरल लगता है। मूल रूप से, मैं इस हिस्से के बारे में बात करूंगा।



चूंकि यह वह है जो डेटाबेस से संबंधित है और कीमिया है।



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

पढ़ने के अनुरोधों को लिखने के अनुरोधों का अनुपात लगभग 15: 1 है। यहां यह स्पष्ट है: कॉन्फ़िगरेशन बदलने के लिए बहुत सारी कमांड हैं और एक निश्चित समय की अवधि में एक बार हमारे पास अंतिम बिंदुओं पर पुश कॉन्फ़िगरेशन है।

MySQL का उपयोग आंतरिक रूप से किया जाता है - यह हमारी कंपनी के अन्य उत्पादों में भी उपलब्ध है, हमारे पास इस डेटाबेस में काफी गंभीर विशेषज्ञता है, ऐसे लोग हैं जो इसके साथ काम कर सकते हैं: एक डेटा योजना, डिज़ाइन क्वेरी और अन्य सभी चीज़ों का निर्माण करें। इसलिए, हमने MySQL को एक सार्वभौमिक रिलेशनल डेटाबेस के रूप में लिया।



इस प्रणाली को डिजाइन करने के बाद हमें क्या समस्या थी? एक कमांड का निष्पादन टीम की जटिलता के आधार पर एक से तीस सेकंड तक होता है। तदनुसार, निष्पादन में देरी पांच मिनट तक पहुंच गई। एक टीम आई - 30 सेकंड, दूसरा और इतने पर, संचित का ढेर - 5 मिनट की देरी।

कॉन्फ़िगरेशन को लागू करने में देरी दस मिनट तक है। यह तय किया गया कि यह हमारे लिए पर्याप्त नहीं था और यह अनुकूलन आवश्यक था।



सबसे पहले, किसी भी अनुकूलन का संचालन करने से पहले, एक जांच करना और यह पता लगाना आवश्यक है कि वास्तव में, मामला क्या है।



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



अगर आपके पास टेलीमेट्री नहीं है तो आगे क्या किया जा सकता है? आप लॉग का विश्लेषण कर सकते हैं। यहां, काफी सरल स्क्रिप्ट हमारे लॉग से गुजरती हैं और उन्हें इस तरह की तालिका में बदल देती हैं, जो सबसे तेज़, सबसे धीमी और औसत कमांड निष्पादन बार दिखाती है। यहां से शुरू करते हुए, हम पहले से ही देख सकते हैं कि हमारे पास किस स्थान पर गैग्स हैं: कौन सी टीमों को निष्पादित करने में अधिक समय लगता है, जो कि तेजी से होता है।



केवल ध्यान देने योग्य बात यह है कि लॉग का विश्लेषण करते समय, हम केवल सर्वर पर इन कमांड के निष्पादन समय पर विचार करते हैं। यह पहला चरण है - टी 2 के रूप में चिह्नित। t1 - यह है कि क्लाइंट हमारी टीम के निष्पादन समय को कैसे देखेगा: सर्वर पर कतार, प्रतीक्षा, निष्पादन में हो रही है। यह समय लंबा होगा, इसलिए हम समय t2 का अनुकूलन करते हैं, और फिर समय t1 का उपयोग यह निर्धारित करने के लिए करते हैं कि क्या हम लक्ष्य तक पहुंच गए हैं।

t1 हमारे प्रदर्शन की गुणवत्ता मीट्रिक है।



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

बेंच () कई बार चलाई गई और हमारे लिए अलग-अलग मेट्रिक्स मानी गईं - इसी तरह हमने प्रदर्शन का मूल्यांकन किया।

लेकिन यह पता चला कि यह समस्या नहीं है!



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



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

यह बड़ी रूपरेखा का एक टुकड़ा है जिसे मैं यहां प्रस्तुत कर रहा हूं ताकि उदाहरणों को और समझा जा सके।

जब वह किसी और के एपीआई को देखता है तो हर वास्तुशिल्प ब्रह्मांड क्या करना चाहता है? वह इसे छुपाना चाहता है, अमूर्त है और अपने इंटरफ़ेस को लिखने के लिए इस एपीआई को हटाने में सक्षम है, या इसे छिपाने के लिए।



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



यहां कार्यान्वयन बहुत सरल है। हमारे पास एक लोड विधि है जो डेटाबेस के लिए एक प्रश्न बनाती है और प्रत्येक प्राप्त वस्तु के लिए अपना स्वयं का पायथन ऑब्जेक्ट बनाता है। एक बचत विधि है जो विपरीत ऑपरेशन करती है - ऐसा लगता है कि प्राथमिक कुंजी का उपयोग करके डेटाबेस में कोई ऑब्जेक्ट है, यदि नहीं - यह बनाता है, जोड़ता है, और फिर हम इस ऑब्जेक्ट की स्थिति को बचाते हैं। प्राथमिक कुंजी को हटाता है और डेटाबेस से ऑब्जेक्ट को हटाता है।



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

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

ऊपरी दाएं कोने में आइकन देखें? तो मैं उन स्लाइडों को चिह्नित करूंगा जिन पर "शुद्धता" के लिए कुछ किया गया है, अमूर्तता के स्तर को बढ़ाने के लिए, वास्तुशिल्प अंतरिक्ष यात्रियों के लिए। यही है, इस आइकन के बिना स्लाइड व्यावहारिक और उबाऊ हैं, निर्बाध है और इसे पढ़ा नहीं जा सकता है।

अगर बहुत सारे सवाल धीमे हैं तो क्या करें। कितने हैं? वास्तव में बहुत कुछ। विरासत की एक श्रृंखला की कल्पना करें: एक वस्तु, इसमें एक अभिभावक है, कि एक के पास दूसरा माता-पिता है। हम बच्चे की वस्तु को सिंक्रनाइज़ करते हैं - ऐसा करने के लिए, आपको पहले माता-पिता को सिंक्रनाइज़ करने की आवश्यकता है। माता-पिता को सिंक्रनाइज़ करने के लिए, आपको इसके माता-पिता को सिंक्रनाइज़ करने की आवश्यकता है। खैर, सभी को सिंक्रनाइज़ किया गया था। वास्तव में, हमने ग्राफ का निर्माण कैसे किया है, इस पर निर्भर करते हुए, हम इन सभी वस्तुओं को सौ बार पैदल और सिंक्रनाइज़ कर सकते हैं - इसलिए बड़ी संख्या में अनुरोध।



हमने क्या किया है? हमने अपने सभी व्यावसायिक तर्क ले लिए और इसे मैपर में चिपका दिया। यहाँ अन्य सभी वस्तुएँ भी मैपर के साथ विलीन हो गईं, और हमारी संपूर्ण API, संपूर्ण डेटा एब्सट्रैक्शन लेयर, मैली हो गई।



पायथन में यह कैसा दिखता है - हमारे मैपर में किसी प्रकार का व्यावसायिक तर्क है, इस प्लेट के बारे में घोषणात्मक विवरण है। कॉलम सूचीबद्ध हैं, रिश्ते। यहाँ हमारे पास ऐसा वर्ग है।



बेशक, किसी भी अंतरिक्ष यात्री के दृष्टिकोण से, एक गंदा एपीआई एक खामी है। आधार के घोषणात्मक विवरण में व्यावसायिक तर्क। योजनाओं को व्यावसायिक तर्क के साथ मिलाया जाता है। फू। बदसूरत।

सर्किट का वर्णन अव्यवस्थित है। यह वास्तव में एक समस्या है - यदि व्यावसायिक तर्क में दो लाइनें नहीं हैं, लेकिन एक बड़ी मात्रा है, तो इस वर्ग में हमें विशिष्ट विवरण प्राप्त करने के लिए बहुत लंबे समय तक स्क्रॉल करने या खोज करने की आवश्यकता है। इससे पहले, सब कुछ सुंदर था: एक स्थान पर आधार का वर्णन, घोषणात्मक, योजनाओं का विवरण, एक अन्य स्थान पर व्यापार तर्क। और फिर सर्किट को अव्यवस्थित किया जाता है।

लेकिन, दूसरी ओर, हम तुरंत कीमिया के तंत्र को प्राप्त करते हैं: काम की इकाई, जो आपको ट्रैक करने की अनुमति देती है कि कौन सी वस्तुएं गंदी हैं और किन रिले को अपडेट करने की आवश्यकता है; हमें एक ऐसा संबंध मिलता है जो हमें डेटाबेस में अतिरिक्त प्रश्नों से छुटकारा पाने की अनुमति देता है, यह सुनिश्चित किए बिना कि संबंधित संग्रह भरे हुए हैं; और पहचान मानचित्र जिसने हमें सबसे अधिक मदद की। पहचान मानचित्र सुनिश्चित करता है कि दो पायथन ऑब्जेक्ट एक ही पायथन ऑब्जेक्ट होंगे यदि उनके पास एक ही प्राथमिक कुंजी है।

तदनुसार, हमने तुरंत रैखिक को जटिलता को कम कर दिया।



ये मध्यवर्ती परिणाम हैं। प्रदर्शन तुरंत 10 गुना बढ़ गया, डेटाबेस में प्रश्नों की संख्या लगभग 40-80 गुना गिर गई और आरपीएस 1-5 हो गया। अच्छा, अच्छा। लेकिन एपीआई गंदा है। क्या करें?



Hagfish। हम व्यापारिक तर्क लेते हैं, फिर से हम इसे अपने मैपर से हटा देते हैं, लेकिन ताकि फिर से मैपिंग न हो, हम अपने मिक्सचर से एल्केमी के अंदर अपने मैपर को विरासत में लेंगे। दूसरा रास्ता क्यों नहीं? यह कीमिया में काम नहीं करेगा, वह कसम खाएगी और कहेगी: "आपके पास एक गोली का जिक्र करने के लिए दो अलग-अलग वर्ग हैं, कोई भी पॉलीफ़ॉर्मिज्म नहीं है - यहां से जाएं।" और इसलिए - यह संभव है।

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

कीमिया इतना अच्छा, प्रसिद्ध, ढांचा नहीं होता अगर उसने मुझे इससे लड़ने का मौका नहीं दिया होता।



मिक्सचर कैसा दिखता है। उनके पास व्यावसायिक तर्क हैं, अलग से मैपर हैं, प्लेट का एक घोषणात्मक विवरण है। कनेक्शन कीमिया के भीतर रहते हैं, लेकिन व्यावसायिक तर्क अलग है।

सामान्य रूपरेखा क्या दिखती है?



हमारे पास एक स्कीम है जिसमें हमारे सभी घोषणात्मक वर्गों को एकत्र किया जाता है - आइए इसे स्कीमाफ्रेम कहते हैं। और हमारे पास अलग-अलग व्यापारिक तर्क हैं। और, इन संस्थाओं को स्कीमा फ़ाइल के अंदर विरासत में मिला है - हम प्रत्येक इकाई के लिए एक अलग वर्ग लिखते हैं, और इसे स्कीमा में इनहेरिट करते हैं। इस प्रकार, व्यापारिक तर्क एक ढेर में, दूसरे में योजना निहित है और उन्हें स्वतंत्र रूप से बदला जा सकता है।



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

कीमिया के "गंदे" इंटरफ़ेस के भीतर संबंधों को छिपाने के लिए, हम रिश्तों और संग्रह का उपयोग करते हैं।



वे हमें क्लाइंट कोड से हमारे मैपर को छिपाने की अनुमति देते हैं।



विशेष रूप से, दो बहुत ही उपयोगी संग्रह हैं Association_proxy और attribute_mapped_collection। हम उन्हें एक साथ उपयोग करते हैं। कैसे कीमिया में शास्त्रीय संबंध काम करता है: हमारा एक संबंध है - यह एक निश्चित संग्रह, सूची, मैपर है। मैपर दूर के रिश्ते की वस्तुएं हैं। Attribute_mapped_collection आपको एक श्रुति के साथ इस सूची को बदलने की अनुमति देता है, जिसमें कुंजियाँ मैपर की कुछ विशेषताएं होंगी, और मान स्वयं मैपर्स होते हैं।

यह पहला कदम है।



दूसरा कदम, हम इस संबंध पर Association_proxy करते हैं। यह हमें संग्रह करने के लिए मैपर को पारित करने की अनुमति नहीं देता है, लेकिन कुछ मूल्य पारित करने के लिए जो बाद में हमारे मैपर, रिसीवररप्लानेस को इनिशियलाइज़ करने के लिए उपयोग किया जाएगा।

यहां हमारे पास लैम्ब्डा है, जिसमें हम कुंजी और मूल्य पास करते हैं। कुंजी कॉन्फ़िगरेशन स्लाइस के नाम में बदल जाती है, और कॉन्फ़िगरेशन स्लाइस के मूल्य में मूल्य। परिणामस्वरूप, क्लाइंट कोड में, सब कुछ इस तरह दिखता है।



हमने बस किसी तरह के डिक्शनरी में किसी तरह का डिक्टेशन डाला। सब कुछ काम करता है: कोई मैपर, कोई कीमिया, कोई डेटाबेस।

सच है, नुकसान हैं।



यदि हम अलग-अलग, या यहां तक ​​कि एक, एक ही कुंजी के लिए दो बार मान देते हैं - लैम्ब्डा को ऐसे प्रत्येक सेट आइटम के लिए कहा जाता है, एक ऑब्जेक्ट बनाया जाता है - एक मैपर। और, यह योजना कैसे संरचित है, इस पर निर्भर करते हुए, यह विभिन्न परिणामों को जन्म दे सकता है, "केवल स्थिरांक के उल्लंघन" से अप्रत्याशित परिणामों तक। उदाहरण के लिए, आपने संग्रह से किसी ऑब्जेक्ट को हटा दिया है, लेकिन यह अभी भी वहां बना हुआ है: आपने केवल एक को हटा दिया है। जब मैंने पहली बार शुरुआत की, तो मैंने इस तरह की चीजों पर बहुत समय लगाया।

और थोड़ा अंतर्निहित सिंक्रनाइज़ेशन। Association_proxy और attribute_mapped_collection में थोड़ी देरी हो सकती है: जब हम एक मैपर ऑब्जेक्ट बनाते हैं, तो इसे डेटाबेस में जोड़ा जाता है, लेकिन यह अभी तक संग्रह विशेषता में मौजूद नहीं है। यह तभी दिखाई देगा जब इस सत्र में विशेषता समाप्त हो जाएगी। जब यह समाप्त हो जाता है, तो डेटाबेस के साथ एक नया तुल्यकालन होगा और यह वहां पहुंच जाएगा।

इसे दूर करने के लिए, हमने अपने, स्व-लिखित, संग्रह का उपयोग किया। यह भी कीमिया नहीं है - आप बस इस सब को दूर करने के लिए अपना खुद का संग्रह बना सकते हैं।



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

यहां हम साधारण चीजें करते हैं - हम इसे कुछ प्राथमिक कुंजी द्वारा नाम से प्राप्त करने की कोशिश करते हैं और यदि यह नहीं है, तो हम इस ऑब्जेक्ट को बनाते हैं और वापस करते हैं।

अगला, हम सिर्फ दो तरीकों को फिर से परिभाषित करते हैं: __setitem__ और __getitem__
__Setitem__ में, हम इन वस्तुओं को अपने संग्रह में, एक रिश्ते में डालते हैं। केवल एक चीज यह है कि हम बहुत अंत में मूल्य प्रदान करते हैं। इस प्रकार, हम एक ही तंत्र को Association_proxy के रूप में कार्यान्वित करते हैं - मान पास करें, वहां तानाशाही करें, और इसे संबंधित विशेषता को सौंपा जाए।

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



यह संग्रह हमारे मिश्रणों पर कैसे थप्पड़ मारता है? हमेशा की तरह - एक संग्रह विशेषता सेट करें। एकमात्र दिलचस्प जगह यह है कि जब हम डेटाबेस से एक उदाहरण लोड करते हैं, तो __init__ विधि को नहीं कहा जाता है। सभी विशेषताओं को पूर्व पद से प्रतिस्थापित किया जाता है।

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



लेकिन हमारी योजना में, डेटाबेस के कान अभी भी दिखाई दे रहे हैं - यह कॉन्फ़िगरेशन है। किस प्रकार का विन्यास? क्या यह varchar है या यह blob है? वास्तव में, ग्राहक रुचि नहीं है।उसे अपने स्तर की अमूर्त संस्थाओं के साथ काम करना चाहिए। इसके लिए, कीमिया प्रकार की सजावट प्रदान करता है।



एक सरल उदाहरण। हमारा डेटाबेस IPAddress को varchar के रूप में संग्रहीत करता है। हम टाइप-डेकोरेटर वर्ग का उपयोग करते हैं, जो कीमिया का हिस्सा है, जो सबसे पहले, यह सूचित करने के लिए अनुमति देता है कि इस प्रकार के लिए किस अंतर्निहित डेटाबेस प्रकार का उपयोग किया जाएगा, और दूसरी बात, दो मापदंडों को निर्धारित करने के लिए: process_bind_param डेटाबेस मान और process_result_value के मान को परिवर्तित करते हुए जब हम मूल्य देते हैं। डेटाबेस के प्रकार से, पायथन ऑब्जेक्ट में कनवर्ट करें।

पते की विशेषता अजगर प्रकार IPAddress पर होती है। और हम दोनों इस प्रकार के तरीकों को कॉल कर सकते हैं, और इस प्रकार की वस्तुओं को असाइन कर सकते हैं, और हमारे लिए सब कुछ काम करता है। और यह डेटाबेस में संग्रहीत है ... मुझे नहीं पता कि क्या संग्रहीत है, varchar (45), लेकिन हम उस लाइन को बदल सकते हैं और बूँद को संग्रहीत किया जाएगा। या यदि कुछ देशी प्रकार आईपी पते का समर्थन करते हैं, तो आप इसका उपयोग कर सकते हैं।

क्लाइंट कोड इस पर निर्भर नहीं करता है, इसे फिर से लिखने की आवश्यकता नहीं है।



एक और दिलचस्प बात यह है कि हमारे पास एक संस्करण है। हम चाहते हैं कि जैसे ही हम अपनी वस्तु को बदलते हैं, संस्करण तुरंत बढ़ जाता है। हमारे पास कुछ संस्करण काउंटर हैं, हमने ऑब्जेक्ट को बदल दिया है - यह बदल गया है, संस्करण में वृद्धि हुई है। हम इसे स्वचालित रूप से करते हैं ताकि भूल न जाए।



इसके लिए, हमने घटनाओं का उपयोग किया। घटनाएं ऐसी घटनाएं होती हैं जो किसी मैपर के जीवन के विभिन्न चरणों में होती हैं और उन्हें तब ट्रिगर किया जा सकता है जब विशेषताएँ बदल जाती हैं, जब एक इकाई एक राज्य से दूसरे में बदल जाती है, उदाहरण के लिए, "बनाया", "डेटाबेस में सहेजा गया", "डेटाबेस से लोड", "हटा दिया गया"; और यह भी - सत्र-स्तर की घटनाओं में, वर्ग कोड से पहले डेटाबेस के लिए उत्सर्जित किया जाता है, प्रतिबद्ध से पहले, कमिट के बाद, और रोलबैक के बाद भी।

अल्केमी हमें इन सभी घटनाओं के लिए हैंडलर आवंटित करने की अनुमति देता है, लेकिन उसी घटना के लिए हैंडलर को जिस क्रम में निष्पादित किया जाता है, उसकी गारंटी नहीं है। अर्थात्, यह विशिष्ट है, लेकिन यह ज्ञात नहीं है कि कौन सा है। इसलिए, यदि निष्पादन आदेश आपके लिए महत्वपूर्ण है, तो आपको एक पंजीकरण तंत्र करने की आवश्यकता है।



यहाँ एक उदाहरण है। तीन घटनाओं का उपयोग यहां किया जाता है:
on_before_flush - डेटाबेस में sql कोड उत्सर्जित होने से पहले, हम उन सभी ऑब्जेक्ट्स से गुजरते हैं, जो कीमिया इस सत्र में गंदे के रूप में चिह्नित होते हैं और जाँचते हैं कि यह ऑब्जेक्ट संशोधित है या नहीं। अगर कीमिया पहले से ही सब कुछ चिह्नित कर चुकी है, तो यह आवश्यक क्यों है? जैसे ही कुछ विशेषता बदली है, कीमिया किसी वस्तु को गंदा कर देती है। यदि हम इस विशेषता के लिए समान मान प्रदान करते हैं कि यह गंदा था। इसके लिए एक is_modified सत्र विधि है - इसका उपयोग आंतरिक रूप से किया जाता है, मैंने इसे नहीं खींचा। इसके अलावा, हमारे शब्दार्थ के दृष्टिकोण से, हमारे व्यापारिक तर्क के दृष्टिकोण से, भले ही विशेषता बदल गई हो, वस्तु अभी भी अनमनी रह सकती है। उदाहरण के लिए, एक निश्चित सूची है जिसमें दो तत्व आपस में जुड़े हुए हैं - कीमिया के दृष्टिकोण से, विशेषता बदल गई है, लेकिन यह व्यवसाय तर्क के लिए मायने नहीं रखता है, अगर कहते हैं,किसी तरह।

और, अंत में, हम प्रत्येक वस्तु के लिए विशिष्ट एक अन्य विधि कहते हैं, ताकि यह समझ सके कि वस्तु संशोधित है या नहीं। और हम उन्हें उस सत्र से जुड़े एक निश्चित चर में जोड़ते हैं, जिसे हमने खुद लाया था - यह हमारा गंदा_स्टेंस चर है, जिसमें हम इस ऑब्जेक्ट को जोड़ते हैं।

निम्न घटना कमिट से पहले होती है - इससे पहले_कैमिट। एक छोटा सा नुकसान भी है: अगर हमारे पास पूरे लेनदेन के लिए एक भी फ्लश नहीं है, तो फ्लश को कमिट से पहले बुलाया जाएगा - मेरे मामले में, हैंडलर को फ्लश से पहले कमिट में बुलाया गया था।

जैसा कि आप देख सकते हैं, पिछले पैराग्राफ में हमने जो किया वह हमारी मदद नहीं कर सकता है और सत्र। इसलिए, हैंडलर के अंदर, हम फिर से फ्लश बनाते हैं ताकि फ्लश से पहले सभी हैंडलर को बुलाया जाए और बस एक-एक करके वर्जन बढ़ाया जाए।

after_commit, after_soft_rollback - कमिट के बाद, हम बस इसे साफ करते हैं ताकि अगली बार कोई अधिकता न हो।

इस प्रकार, आप देखते हैं - यह install_handler विधि एक साथ तीन घटनाओं के लिए हैंडलर स्थापित करती है। एक कक्षा के रूप में, हम यहां सत्र पास करते हैं, क्योंकि यह अपने स्तर की एक घटना है।



खैर यहाँ। मैं आपको याद दिलाऊंगा कि हमने क्या हासिल किया है - जटिल और बड़ी टीमों के लिए 30-40 सेकंड की गति। बिल्कुल नहीं, कुछ एक सेकंड में पूरे हो गए, अन्य 200 मिलीसेकंड में, जैसा कि आप आरपीएस पर देख सकते हैं। डेटाबेस क्वेरीज़ को सैकड़ों में गिना जाने लगा।



परिणाम एक काफी संतुलित प्रणाली है। हालांकि, एक कैविएट था। कुछ अनुरोध बैचों, उत्सर्जन में हमसे आते हैं। यही है, लगभग 30 अनुरोध आते हैं और उनमें से प्रत्येक ऐसा है! (स्पीकर ने अंगूठा दिखाया)

यदि हम उन्हें एक समय में एक सेकंड में संसाधित करते हैं, तो कतार में अंतिम अनुरोध 30 सेकंड के लिए काम करेगा। पहला वाला, दूसरा दो, और इतने पर।



इसलिए, हमें अभी भी तेजी लाने की आवश्यकता है। हम क्या करेंगे?

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

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

नुकसान यह है कि हम फिर से मैनुअल सिंक्रोनाइज़ेशन के लिए आए। सभी घटनाओं, रिले - कोर में यह सब काम नहीं करता है। हमने एक चयन किया, ऑब्जेक्ट हमारे पास आए, हमने उनके साथ कुछ किया, फिर अपडेट करें, डालें ... आपको अपने हाथों से संस्करण को बढ़ाना होगा, स्वयं स्थिरांक जांचें। कोर उच्च स्तर पर यह सब आसानी से करने की अनुमति नहीं देता है।

खैर, हम पहले दिन नहीं जीते हैं।



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



यह बहुत बेहतर हो गया है। सबसे खराब स्थिति में प्रदर्शन 2-4 सेकंड तक गिर गया, सबसे जटिल और सबसे लंबे अनुरोध में 14 कमांड और आरपीएस 10-15 थे। यह ठोस है।



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

यही सब मैं आज आपको बताना चाहता हूं।