जब आपको एक बल्क ऑपरेशन को लागू करने की आवश्यकता होती है, तो क्या आपको ORM ढांचे को छोड़ देना चाहिए?


15

यहाँ एक सामान्य स्थिति है:

  • आपको ओआरएम ढांचे का उपयोग करने वाले एप्लिकेशन में बल्क ऑपरेशन को लागू करना होगा।
  • पहली पास के बाद, आपने महत्वपूर्ण प्रदर्शन समस्याओं पर ध्यान दिया है।

यहाँ मेरा सवाल है:

  • इस स्थिति में, आपको एक समाधान का पक्ष लेना चाहिए जिसमें कच्ची एसक्यूएल शामिल है?
  • या ऐसे प्रसिद्ध डिजाइन पैटर्न हैं जो आपको उन समस्याओं को कम करने में मदद कर सकते हैं जो आमतौर पर ओआरएम फ्रेमवर्क के साथ थोक संचालन से जुड़ी हैं?

संपादित करें:

  • मैं यह नहीं पूछ रहा हूं कि क्या आपको पूरे एप्लिकेशन से ORM फ्रेमवर्क को हटा देना चाहिए।
  • मैं पूछ रहा हूं: क्या आपको आवेदन के इस छोटे से स्लाइस के लिए ओआरएम ढांचे से गुजरना चाहिए?

मुझे नहीं पता कि आपको कुछ करना चाहिए , लेकिन क्या आपने अपने बल्क ऑपरेशन को बैचेन करने की कोशिश की है ?
क्रिसनाडेल

जवाबों:


13

ORM का उद्देश्य आपके डेटाबेस तक पूरी तरह से पहुंच बनाना नहीं है। उन 80% कोड के लिए उनका उपयोग करें जो CRUD है, वह सामान जो आपके स्वयं के लिखने के लिए बहुत थकाऊ है। संग्रहीत कार्यविधियों, डायनेमिक SQL, या जो भी आप शेष 20% के लिए चाहते हैं उसका उपयोग करें जिसे सावधानी से अनुकूलित करने की आवश्यकता है।


4
अगर डेटाबेस एब्स्ट्रैक्शन एक मुख्य कारण नहीं था कि आप ORM का उपयोग करने का निर्णय क्यों लेते हैं तो यह काम करेगा।

@ Pierre303, मुझे आपकी टिप्पणी समझने में मुश्किल समय आ रहा है। क्या मतलब?
मार्क कैनलास

@MarkCanlas: मुझे लगता है कि उसका मतलब है "डेटाबेस को दूर करना," इस अर्थ में कि आप डेटाबेस को बदल सकते हैं (उदाहरण के लिए SQL सर्वर से MySQL पर जाएं) यदि आप ऐसा करना चाहते थे। व्यवहार में, यह उपयोग मामला शायद ही कभी होता है।
रॉबर्ट हार्वे

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

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

7

मैं एक आवेदन में ORM (nHibernate) का उपयोग करता हूं जिसके लिए उच्च प्रदर्शन की आवश्यकता होती है और अरबों रिकॉर्डों को संभालता है। समय के साथ हमने देखा कि अधिकांश महत्वपूर्ण प्रदर्शन समस्याएं केवल ORM के कारण ORM का उपयोग करने के हमारे अपने तरीके से संबंधित थीं।

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

आपने एक विशिष्ट ORM निर्दिष्ट नहीं किया, इसलिए यहां वे चीजें हैं जो हमने प्रदर्शन को बेहतर बनाने के लिए की हैं:

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

1

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


1

ORM कुछ भी जादुई नहीं करते हैं। वे SQL में ऑब्जेक्ट एक्सेस विधियों का अनुवाद करते हैं। जिस SQL ​​कथन को वे निष्पादित करते हैं, वह आवश्यक नहीं है कि आप जिस SQL ​​को मैन्युअल रूप से लिखेंगे, उसकी तुलना में धीमा हो। यह कहने के बाद, कुछ मुद्दे हैं जिन पर आप ठोकर खा सकते हैं:

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

प्रदर्शन में सुधार के लिए देशी एसक्यूएल का उपयोग करने में कुछ भी गलत नहीं है। लेकिन पहले यह सुनिश्चित कर लें कि आप समझ रहे हैं कि क्या धीमा हो रहा है।


कैश से बचने के लिए, एक स्टेटलेस सेशन का उपयोग करें। इसके अलावा, ऑटो वेतन वृद्धि आईडी से बचें। इसके बजाय HiLo या Guide का उपयोग किया जाना चाहिए।

1

ORM को बायपास करें। इतना ही नहीं बल्कि "नियमित" sql को भी बायपास करें। स्टेजिंग टेबल पर बेहद बड़े डेटा सेट डालने के लिए अपने डेटाबेस की बल्क यूटिलिटी का उपयोग करें। फिर अपनी स्टेजिंग गतिविधियों को करने के लिए sql का उपयोग करें।

आपका "स्वाद-का-ब्लॉग" ORM सभी स्थितियों के लिए काम नहीं कर सकता है।


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

0

उस स्थिति में हो गया। कभी-कभी, आपको करना होगा।

कुछ ORM डेवलपर को ऑब्जेक्ट मॉडल को छोड़ने और डेटाबेस परत पर सीधे जाने की अनुमति देता है।

ओआरएम भी हैं, जो ऑब्जेक्ट ओरिएंटेड के रूप में, इनकैप्सुलेटेड बल्क ऑपरेशंस का उपयोग करते हैं।


0

जैसा कि umlcat द्वारा बताया गया है , कुछ ORM हैं जो आपको बल्क ऑपरेशन का उपयोग करने देंगे।

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

यह इकाई परीक्षण और डिबगिंग को भी आसान बनाता है। जब आपके पास अपने ORM तरीकों के लिए अच्छा परीक्षण कवरेज हो, तो आप इसे अपने ऐप्स में उपयोग करने के लिए स्वतंत्र हैं। अन्यथा, कच्चे SQL (विशेष रूप से लेनदेन और कई JOIN के साथ बड़े वाले) को डीबग करना एक दर्द हो सकता है।

एक बार मुझे लगभग 100 LOC वाली कच्ची SQL कॉल में बग को देखने के लिए लगभग एक दिन का समय लगा, और बग सिर्फ एक चरित्र था! तब से, मैं ऐप में कच्ची एसक्यूएल से बचने की कोशिश करता हूं, और सभी एसक्यूएल प्रक्रियाओं को अलग-अलग इकाई-परीक्षण किया है।


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.