2009-07-05 17 views
7

मैंने कभी भी पाइथन फ्रेमवर्क डीजेगो के आधार पर कई परियोजनाएं विकसित की हैं। और यह मेरे उत्पादन में काफी सुधार हुआ। लेकिन जब परियोजना जारी की गई और वहां अधिक से अधिक आगंतुक हैं तो डीबी प्रदर्शन की बाधा बन जाती है।ओआरएम का क्या अर्थ है?

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

मैं ORM सोच रहा हूँ निश्चित रूप से उपयोगी है और यह कर सकते हैं:

  1. ऑफर progarammers के लिए एक समान OO इंटरफ़ेस
  2. db बैकएंड प्रवास बहुत आसान (mysql से एसक्यूएल सर्वर या दूसरों को) सुनिश्चित
  3. कोड के मजबूत में सुधार (का उपयोग करते हुए ORM कम कोड का मतलब है, और कम कोड कम त्रुटि का अर्थ है)

लेकिन अगर मैं प्रवास की आवश्यकता नहीं है, का अर्थ क्या है मेरे लिए ओआरएम?

ps। हाल ही में मेरे दोस्त ने मुझे बताया कि वह अब क्या कर रहा है, बेहतर प्रदर्शन पाने के लिए कच्चे वर्ग के लिए ओआरएम कोड को फिर से लिखना है। अफ़सोस की बात है!

तो ऊपर उल्लेखित किए गए ओआरएम के वास्तविक अर्थ क्या हैं? (अगर मैंने कोई गलती की है तो कृपया मुझे सही करें। धन्यवाद।)

+5

'अर्थ' की बजाय मुझे लगता है कि आपका मतलब 'मूल्य' है? –

+0

आप सही हैं। धन्यवाद। –

उत्तर

7

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

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

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

+0

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

3

एक अच्छा ओआरएम आपको डेटा एक्सेस को ट्यून करने की अनुमति देता है यदि आपको पता चलता है कि कुछ प्रश्न एक बाधा हैं।

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

यदि आप हाथ से सभी एसक्यूएल लिखते हैं, तो आप पूरे उत्पाद में "माइक्रो ऑप्टिमाइज़िंग" कर रहे हैं, जिसमें उन हिस्सों को शामिल किया गया है जिनकी आवश्यकता नहीं है। तो आप ज्यादातर प्रयास बर्बाद कर रहे हैं।

+0

क्या होगा यदि आपके पास डेवलपर डीबीए डेटाबेस को एक्सेस करने वाली कई अलग-अलग क्लाइंट टीमों के साथ डेटा प्रबंधित कर रहा है? – gbn

+0

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

+0

मेरी दिशा है: मेरी सभी क्लाइंट टीमों को मेरी संग्रहीत प्रक्रियाओं के खिलाफ कोड। यह मुझे जावा, सी #, vb.net और वीबीए ग्राहकों से निपटने की अनुमति देता है। डीएएल प्रक्रियाओं को संग्रहीत किया जाता है। क्लाइंट लैंगेज और ओआरएम अप्रासंगिक है। – gbn

1

यहाँ Wikipedia

वस्तु संबंधपरक मानचित्रण से परिभाषा रिलेशनल डेटाबेस और वस्तु उन्मुख प्रोग्रामिंग भाषाओं में असंगत प्रकार प्रणालियों के बीच डेटा परिवर्तित करने के लिए एक प्रोग्रामिंग तकनीक जाता है।यह वास्तव में एक "वर्चुअल ऑब्जेक्ट डेटाबेस" बनाता है जिसे प्रोग्रामिंग भाषा के भीतर से उपयोग किया जा सकता है।

0

एक अच्छा ओआरएम (जैसे डैंजो) आपके विकास को विकसित करने और विकसित करने के लिए बहुत तेज बनाता है; यह आपको लगता है कि आप अपने हाथ से जुड़े प्रश्नों में हर प्रयोग को कारक के बिना सभी संबंधित डेटा उपलब्ध करा सकते हैं।

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

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

+0

धन्यवाद। लेकिन डीबी को ट्यून करने के बाद, और आपको एक ही समस्या का सामना करना पड़ सकता है। हो सकता है कि डीबी को और भी ट्यून नहीं किया जा सके, और आपको बेहतर प्रदर्शन प्राप्त करने के लिए ओआरएम ऑपरेशंस को कच्चे एसक्यूएल में फिर से लिखना होगा। बेशक –

+0

। मुझे विश्वास है कि ओआरएम की प्रदर्शन छत वास्तव में उच्च है। अधिकतर साइटें कहीं भी नहीं होंगी। इसके अलावा यह सिर्फ 'डीबी ट्यूनिंग' नहीं है; यह सही डेटा संरचना और एल्गोरिदम का उपयोग करने के बारे में भी है। यदि आप प्रति पृष्ठ 50 प्रश्न करते हैं, तो डीबी ट्यूनिंग की कोई भी मदद नहीं करेगा, आपको इसे कम से कम 5 से कम, 5 से कम आदर्श में ले जाना होगा। – Javier

0

ओआरएम आपको उस अजीब एसक्यूएल को लिखने से अलग करता है।

यह भी उपयोगी है जब आप अपने सॉफ़्टवेयर को किसी अन्य डेटाबेस इंजन पर पोर्ट नहीं करते हैं।

नकारात्मक पक्ष पर: आप प्रदर्शन खो देते हैं, जिसे आप एसक्यूएल के कस्टम स्वाद लिखकर ठीक करते हैं - कि उसने पहली जगह लिखने से इंस्यूलेट करने की कोशिश की।

+0

धन्यवाद। लेकिन मुझे लगता है कि आपने मेरी पोस्ट नहीं पढ़ी है। –

+0

नहीं, मैंने इसे पढ़ा। आपके पास ओआरएम के दो कारण हैं। –

0

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

उदाहरण के लिए ओरेकल, यदि आपको तेज़ी से उठने की आवश्यकता है तो मुझे ट्यून करने की आवश्यकता है (मुझे नहीं पता क्यों, लेकिन मेरे डीबी व्यवस्थापक ने ऐसा किया और यह प्रश्नों के साथ तेज़ी से काम करता है जिसमें बहुत सारे डेटा शामिल हैं)।

मुझे सलाह है, अगर आपको जटिल क्वेरी (उदाहरण: रिपोर्ट) को अन्य (अद्यतन हटाएं/सीआरयूडी बनाएं) की आवश्यकता है और यदि आपका एप्लिकेशन किसी अन्य डेटाबेस का उपयोग नहीं करेगा, तो आपको सीधे एसक्यूएल का उपयोग करना चाहिए (मुझे लगता है कि Django यह सुविधा)

+0

धन्यवाद। और आपका निष्कर्ष मेरे साथ लगभग समान है। –

संबंधित मुद्दे