एक भी ओआरएम नहीं

सभी को नमस्कार! मैं Ostrovok.ru होटल आरक्षण सेवा के भागीदार विकास विभाग का प्रभारी हूं। इस लेख में मैं इस बारे में बात करना चाहूंगा कि कैसे हमने एक परियोजना पर Django ORM का उपयोग किया।

वास्तव में, मैं धोखा दे रहा था, नाम होना चाहिए था " नहीं ORM एकल "। यदि आप सोच रहे हैं कि मैंने यह क्यों लिखा है, साथ ही साथ:

• आपके पास स्टैक पर Django है, और आप ORM से अधिकतम Model.objects.all() , न कि केवल Model.objects.all() ,
• आप डेटाबेस स्तर पर व्यावसायिक तर्क का हिस्सा स्थानांतरित करना चाहते हैं,
• या क्या आप यह जानना चाहते हैं कि B2B.Ostrovok.ru पर डेवलपर्स के लिए सबसे लगातार बहाना "इतना ऐतिहासिक" क्यों है ,

... बिल्ली का स्वागत है।

2014 में, हमने B2B.Ostrovok.ru शुरू किया - पर्यटन बाजार में पेशेवरों (ट्रैवल एजेंटों, ऑपरेटरों और कॉर्पोरेट ग्राहकों) के लिए होटल, स्थानान्तरण, कारों और अन्य यात्रा सेवाओं के लिए एक ऑनलाइन बुकिंग सेवा।

B2B में, हमने GenericForeignKey - मेटा ऑर्डर - MetaOrder आधार पर एक अमूर्त ऑर्डर मॉडल का सफलतापूर्वक और काफी सफलतापूर्वक उपयोग किया है।

एक मेटा ऑर्डर एक अमूर्त इकाई है जिसका उपयोग किसी भी प्रकार के आदेश से नहीं किया जा सकता है: होटल ( Hotel ), अतिरिक्त सेवा ( Upsell ) या कार ( Car )। भविष्य में, अन्य प्रकार दिखाई दे सकते हैं।

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

मेरा लक्ष्य हमारे उदाहरण में Django ORM की शक्ति दिखाना है।

प्रागितिहास

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

(सभी मान परीक्षण हैं और किसी विशिष्ट भागीदार पर लागू नहीं होते हैं)

पहली नज़र में, सब कुछ काफी सरल है - हम साथी के सभी आदेशों को फ़िल्टर करते हैं, संक्षिप्त करते हैं और दिखाते हैं।

समाधान के विकल्प

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

"माथे में"

वास्तव में, यह Model.objects.all() और स्थितियां लूप हैं:

 def output(partner_id): today = dt.date.today() # query_get_one -    partner = query_get_one(Partner.objects.filter(id=partner_id)) #    -  query = MetaOrder.objects.filter(partner=partner) result = defaultdict(Decimal) for morder in query: #  ,     #     payment_pending = morder.get_payment_pending() payment_due = morder.get_payment_due() #        # (     ) payable = morder.get_payable_in_cur() #       if payment_pending > today: result['payment_pending'] += payable # ,     if payment_pending < today and payment_due > today: result['payment_due'] += payable return result 

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

आप prefetch_related विधि को जोड़कर चीज़ों को थोड़ा तेज़ कर सकते हैं:

 # object -      GenericForeignKey. query = query.prefetch_related('object') 

तब डेटाबेस के लिए थोड़े कम अनुरोध होंगे ( GenericForeignKey पर GenericForeignKey ), लेकिन फिर भी, अंत में, हम उनकी संख्या पर रोक देंगे, क्योंकि चक्र के प्रत्येक पुनरावृत्ति पर डेटाबेस के लिए अनुरोध अभी भी किया जाएगा।

output विधि (और होनी चाहिए) को कैश किया जा सकता है, लेकिन फिर भी पहली कॉल एक मिनट के आदेश को पूरा करती है, जो पूरी तरह से अस्वीकार्य है।

इस दृष्टिकोण के परिणाम इस प्रकार हैं:

औसत प्रतिक्रिया समय 4 सेकंड है, और 21 सेकंड तक पहुंचने वाली चोटियां हैं। बहुत लंबा समय है।

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

नीचे दाईं ओर की संख्याएँ प्रश्नों की संख्या हैं: न्यूनतम, अधिकतम, औसत, कुल।

मन के साथ

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

अनुरोध योजना

क्वेरी प्लान के विस्तृत स्ट्रोक इस तरह वर्णित किए जा सकते हैं:

• प्रारंभिक शर्तों के अनुसार आदेश एकत्र करें,
• annotate माध्यम से गणना के लिए फ़ील्ड तैयार करें,
• फ़ील्ड मानों की गणना करें
• राशि और मात्रा के aggregate से aggregate बनाएं

प्रारंभिक शर्तें

साइट पर जाने वाले साथी अपने अनुबंध पर केवल जानकारी देख सकते हैं।

 partner = query_get_one(Partner.objects.filter(id=partner_id)) 

यदि हम नए प्रकार के ऑर्डर / बुकिंग दिखाना नहीं चाहते हैं, तो हमें केवल समर्थित लोगों को फ़िल्टर करना होगा:

 query = MetaOrder.objects.filter( partner=partner, content_type__in=[ Hotel.get_content_type(), Car.get_content_type(), Upsell.get_content_type(), ] ) 

आदेश की स्थिति महत्वपूर्ण है ( Q बारे में अधिक):

 query = query.filter( Q(hotel__status__in=['completed', 'cancelled']) #     ,    # | Q(car__status__in=[...]) ) 

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

 query = MetaOrder.exclude_non_payable_metaorders(query) 

जैसा कि आप देख सकते हैं, यह एक क्लास विधि है जो एक QuerySet भी QuerySet ।

हम सशर्त निर्माणों के लिए और गणना परिणामों को संग्रहीत करने के लिए कुछ चर भी तैयार करेंगे:

 import datetime as dt from typing.decimal import Decimal today = dt.date.today() result = defaultdict(Decimal) 

फील्ड तैयारी ( annotate )

इस तथ्य के कारण कि हमें ऑर्डर के प्रकार के आधार पर खेतों का उल्लेख करना है, हम Coalesce उपयोग करेंगे। इस प्रकार, हम किसी भी क्षेत्र में किसी भी प्रकार के नए आदेशों को सार कर सकते हैं।

यहाँ annotate ब्लॉक का पहला भाग है:

 #     , #      from app.helpers.numbers import ZERO, ONE query_annoted = query.annotate( _payment_pending=Coalesce( 'hotel__payment_pending', 'car__payment_pending', 'upsell__payment_pending', ), _payment_due=Coalesce( 'hotel__payment_due', 'car__payment_due', 'upsell__payment_due', ), _refund=Coalesce( 'hotel__refund', Value(ZERO) ), _refund_currency_rate=Coalesce( 'hotel__refund_currency_rate', Value(ONE) ), _sell=Coalesce( 'hotel__sell', Value(ZERO) ), _sell_currency_rate=Coalesce( 'hotel__sell_currency_rate', Value(ONE) ), ) 

Coalesce यहां धमाके के साथ काम करता है, क्योंकि होटल के ऑर्डर में कई विशेष गुण हैं, और अन्य सभी मामलों में (अतिरिक्त सेवाओं और कारों) ये गुण हमारे लिए महत्वपूर्ण नहीं हैं। यह है कि राशियों के लिए Value(ZERO) और विनिमय दरों के लिए Value(ONE) प्रकट होते हैं। ZERO और ONE केवल Decimal('0') और Decimal(1) , केवल स्थिरांक के रूप में। एक शौकिया दृष्टिकोण, लेकिन हमारी परियोजना में इसे इस तरह से स्वीकार किया जाता है।

आपके मन में सवाल हो सकता है कि मेटा ऑर्डर में कुछ फ़ील्ड्स को एक स्तर तक क्यों नहीं रखा जाए? उदाहरण के लिए, payment_pending , जो हर जगह है। दरअसल, समय के साथ, हम ऐसे क्षेत्रों को मेटा-ऑर्डर में स्थानांतरित करते हैं, लेकिन अब कोड अच्छी तरह से काम करता है, इसलिए ऐसे कार्य हमारी प्राथमिकता नहीं हैं।

एक और तैयारी और गणना

अब हमें उन राशियों के साथ कुछ गणनाएँ करने की ज़रूरत है जो हमें पिछले annotate ब्लॉक में मिली थीं। ध्यान दें कि अब आपको आदेश के प्रकार (एक अपवाद को छोड़कर) से बंधे रहने की आवश्यकता नहीं है।

 .annotate( #  _base     _sell_base=( F('_sell') * F('_sell_currency_rate') ), _refund_base=( F('_refund') * F('_refund_currency_rate') ), _payable_base=( F('_sell_base') - F('_refund_base') ), _reporting_currency_rate=Case( When( content_type=Hotel.get_content_type(), then=RawSQL( '(hotel.currency_data->>%s)::numeric', (partner.reporting_currency,), ), ), output_field=DecimalField(), default=Decimal('1'), ), ) 

इस ब्लॉक का सबसे दिलचस्प हिस्सा _reporting_currency_rate फ़ील्ड या बिक्री के समय संदर्भ मुद्रा के लिए विनिमय दर है। एक होटल के ऑर्डर के लिए सभी मुद्राओं की विनिमय दरों पर डेटा मुद्रा मुद्रा में संग्रहीत किया जाता है। यह सिर्फ JSON है। हम ऐसा क्यों रखते हैं? यह ऐतिहासिक रूप से मामला है ।

और यहाँ, यह प्रतीत होता है, क्यों नहीं F उपयोग करें और अनुबंध मुद्रा के मूल्य को प्रतिस्थापित करें? यदि आप ऐसा कर सकते हैं, तो यह अच्छा होगा:

 F(f'currency_data__{partner.reporting_currency}') 

लेकिन f-strings समर्थन नहीं किया जाता है F हालांकि यह तथ्य कि Django ORM में पहले से ही नेस्टेड json फ़ील्ड्स को एक्सेस करने की क्षमता है, बहुत ही मनभावन है - F('currency_data__USD') ।

और अंतिम annotate ब्लॉक _payable_in_cur गणना है, जिसे सभी आदेशों के लिए _payable_in_cur किया जाएगा। यह मूल्य अनुबंध मुद्रा में होना चाहिए।

 .annotate( _payable_in_cur=( F('_payable_base') / F('_reporting_currency_rate') ) ) 

annotate विधि की ख़ासियत यह है कि यह बहुत SELECT something AS something_else निर्माण करता SELECT something AS something_else कि SELECT something AS something_else निर्माण करता है जो सीधे अनुरोध में शामिल नहीं होते हैं। इसे SQL क्वेरी - query.__str__() को अनलोड करके देखा जा सकता है।

यह वह आधार है जो Django ORM द्वारा base_query_annotated लिए जनरेट किया गया SQL कोड base_query_annotated । आपको यह समझने के लिए बहुत बार पढ़ना होगा कि आप अपनी क्वेरी को कहां अनुकूलित कर सकते हैं।

अंतिम गणना

aggregate लिए एक छोटा आवरण होगा, ताकि भविष्य में, यदि साथी को किसी अन्य मीट्रिक की आवश्यकता हो, तो इसे आसानी से जोड़ा जा सके।

 def _get_data_from_query(query: QuerySet) -> Decimal: result = query.aggregate( _sum_payable=Sum(F('_payable_in_cur')), ) return result['_sum_payable'] or ZERO 

और एक और बात - यह व्यवसाय की स्थिति से अंतिम फ़िल्टरिंग है, उदाहरण के लिए, हमें उन सभी आदेशों की आवश्यकता है जिन्हें जल्द ही भुगतान करने की आवश्यकता होगी।

 before_payment_pending_query = _get_data_from_query( base_query_annotated.filter(_payment_pending__gt=today) ) 

डिबगिंग और सत्यापन

बनाए गए अनुरोध की शुद्धता को सत्यापित करने के लिए एक बहुत ही सुविधाजनक तरीका यह है कि गणना के अधिक पठनीय संस्करण के साथ इसकी तुलना करें।

 for morder in query: payable = morder.get_payable_in_cur() payment_pending = morder.get_payment_pending() if payment_pending > today: result['payment_pending'] += payable 

क्या आप "माथे" विधि जानते हैं?

अंतिम कोड

परिणामस्वरूप, हमें निम्नलिखित जैसा कुछ मिला:

 def _get_data_from_query(query: QuerySet) -> tuple: result = query.aggregate( _sum_payable=Sum(F('_payable_in_cur')), ) return result['_sum_payable'] or ZERO def output(partner_id: int): today = dt.date.today() partner = query_get_one(Partner.objects.filter(id=partner_id)) query = MetaOrder.objects.filter(partner=partner, content_type__in=[ Hotel.get_content_type(), Car.get_content_type(), Upsell.get_content_type(), ]) result = defaultdict(Decimal) query_annoted = query.annotate( _payment_pending=Coalesce( 'hotel__payment_pending', 'car__payment_pending', 'upsell__payment_pending', ), _payment_due=Coalesce( 'hotel__payment_due', 'car__payment_due', 'upsell__payment_due', ), _refund=Coalesce( 'hotel__refund', Value(ZERO) ), _refund_currency_rate=Coalesce( 'hotel__refund_currency_rate', Value(Decimal('1')) ), _sell=Coalesce( 'hotel__sell', Value(ZERO) ), _sell_currency_rate=Coalesce( 'hotel__sell_currency_rate', Value(Decimal('1')) ), ).annotate( # Calculated fields _sell_base=( F('_sell') * F('_sell_currency_rate') ), _refund_base=( F('_refund') * F('_refund_currency_rate') ), _payable_base=( F('_sell_base') - F('_refund_base') ), _reporting_currency_rate=Case( # Only hotels have currency_data, therefore we need a # check and default value When( content_type=Hotel.get_content_type(), then=RawSQL( '(hotel.currency_data->>%s)::numeric', (partner.reporting_currency,), ), ), output_field=DecimalField(), default=Decimal('1'), ), ) .annotate( _payable_in_cur=( F('_payable_base') / F('_reporting_currency_rate') ) ) before_payment_pending_query = _get_data_from_query( base_query_annotated.filter(_payment_pending__gt=today) ) after_payment_pending_before_payment_due_query = _get_data_from_query( base_query_annotated.filter( Q(_payment_pending__lte=today) & Q(_payment_due__gt=today) ) ) 

यह अब कैसे काम करता है:

निष्कर्ष

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

टिप्पणी लिखें, सवाल पूछें - हम जवाब देने की कोशिश करेंगे! धन्यवाद!