मुझे स्टोर प्रक्रिया की तुलना में वास्तव में ओआरएम पसंद है, लेकिन मुझे लगता है कि एक चीज यह है कि परतों और परतों की परतों के कारण ओआरएम धीमा हो सकता है। ओआरएम का उपयोग मेरे आवेदन को धीमा कर देगा? या इससे कोई फर्क पड़ता है?ओआरएम धीमा है? फर्क पड़ता है क्या?
हां, यह महत्वपूर्ण है। यह अधिक CPU चक्रों का उपयोग कर रहा है और इसके परिणामस्वरूप आपके आवेदन को धीमा कर रहा है। हालांकि मुझे सुनें ...
लेकिन, इस पर विचार करें: अधिक महंगा क्या है? सर्वर हार्डवेयर या अन्य प्रोग्रामर? आमतौर पर सर्वर हार्डवेयर प्रोग्रामर की एक और टीम को भर्ती करने से सस्ता है। इसलिए, जबकि ओआरएम आपको सीपीयू चक्रों की लागत दे रहा है, आपको अपने एसक्यूएल प्रश्नों को प्रबंधित करने के लिए एक कम प्रोग्रामर की आवश्यकता होती है, जिसके परिणामस्वरूप कम शुद्ध लागत होती है।
यह निर्धारित करने के लिए कि क्या यह आपके लिए लायक है, गणना करें या निर्धारित करें कि आपने ओआरएम का उपयोग करके कितने घंटे बचाए हैं। फिर, यह पता लगाएं कि आपने ओआरएम का समर्थन करने के लिए सर्वर पर कितना पैसा खर्च किया था। आपके घंटे की दर से सहेजे गए घंटों को गुणा करें और सर्वर लागत की तुलना करें। यह निर्भर करता है
ORM एसक्यूएल से एक प्रोग्रामर रोधक का एक अच्छा काम करता है:
बेशक, चाहे एक ORM वास्तव में आप समय की बचत होती एक पूरे एक और बहस ...
+1 यह एक महान शुरुआत है। अतिरिक्त चिंताएं हैं, जैसे विलंबता आवश्यकताओं, जिन्हें आपने यहां संबोधित नहीं किया था। मौजूदा आर्किटेक्चर कितना भयानक है, इस पर निर्भर करते हुए, एक और सर्वर जोड़ना एक विकल्प नहीं हो सकता है, क्योंकि आपको किसी समस्या के समाधान के लिए लोगों को किराए पर लेना पड़ सकता है जिसे अभी हल नहीं किया गया है (उदाहरण के लिए भार संतुलन/डीबी डुप्लिकेशन/विफलता, बैकअप एकाधिक स्रोतों से, आदि)। –
मुझे लगता है कि अतिरिक्त CPU चक्र और परत समस्या नहीं हैं, लेकिन डेटाबेस पहुंच, अगर अच्छी तरह अनुकूलित नहीं है। आधुनिक दिन मशीनों में पर्याप्त सीपीयू पावर से अधिक है, लेकिन एक साधारण कार्य के लिए सैकड़ों एसक्यूएल राउंडट्रिप्स अभी भी एक समस्या है। (2013 के साथ-साथ 200 9 में) –
स्पष्ट जवाब है। यह प्रभावशाली है, एक प्रोग्रामर दे सकता है कि विनाशकारी रूप से बुरे प्रश्नों के लिए कंप्यूटर उत्पन्न क्वेरी।
यहां तक कि सबसे अच्छे मामले में, एक ओआरएम कुछ अतिरिक्त काम करने जा रहा है, फ़ील्ड लोड करने की आवश्यकता नहीं है, स्पष्ट रूप से बाधाओं की जांच करनी है, और आगे भी।
जब ये बोतल-गर्दन बन जाते हैं, तो अधिकांश ओआरएम आपको उन्हें साइड-स्टेप करने और कच्चे एसक्यूएल इंजेक्ट करने देते हैं।
यदि आपका आवेदन ऑब्जेक्ट्स के साथ अच्छी तरह से फिट बैठता है, लेकिन संबंधों के साथ इतना आसान नहीं है, तो यह अभी भी एक जीत हो सकता है। यदि इसके बजाय आपका ऐप एक रिलेशनल मॉडल के आसपास अच्छी तरह से फिट बैठता है, तो ओआरएम एक संभावित प्रदर्शन बाधा के शीर्ष पर एक कोडिंग बाधा का प्रतिनिधित्व करता है।
एक चीज़ जो मैंने ज्यादातर ओआरएम के बारे में विशेष रूप से आक्रामक पाया है वह प्राथमिक कुंजी का प्रबंधन है। अधिकांश ओआरएम को उनके द्वारा स्पर्श किए जाने वाले सभी चीज़ों के लिए पीके की आवश्यकता होती है, भले ही उनके लिए कोई अनुचित उपयोग न हो। उदाहरण: लेखकों के पास पीके होना चाहिए, ब्लॉग पोस्ट में पीके होना चाहिए, लेकिन लेखकों और पदों के बीच लिंक (तालिका में शामिल होना) होना चाहिए।
क्या आप कह रहे हैं कि अधिकांश ओआरएम संयुक्त प्राथमिक कुंजी का समर्थन नहीं करता है? – Teson
ठीक है, मैं कई ओआरएम के बारे में बहुत कुछ नहीं कह सकता जिसका मैंने उपयोग नहीं किया है, लेकिन ओआरएम के मैंने उपयोग किया है, हाँ, यह सही है। – SingleNegationElimination
ORM धीमी है?
हां (संग्रहित प्रक्रियाओं के साथ तुलना में)
इससे कोई फर्क पड़ता है?
नहीं (सिवाय अपनी चिंता का विषय है गति)
मुझे लगता है कि समस्या बहुत से लोग, डेटाबेस के लिए एक वस्तु "चाल" के रूप में ORM के बारे में सोच, कम कोड या SQL उपयोग को आसान बनाने के समय में वास्तविकता है .. अच्छी तरह से एक वस्तु - रिलेशनल (डीबी) - मैपिंग।
ORM (बस) स्थानापन्न या बनाने के लिए नहीं एक संबंधपरक डेटाबेस प्रबंधक प्रणाली के लिए अपने वस्तुओं लागू करने के लिए प्रयोग किया जाता है, और SQL आसान
(हालांकि यह भी है कि कम से एक अच्छा काम कर रहे हैं) आप नहीं है, तो एक अच्छा ऑब्जेक्ट मॉडल, या आप रिपोर्ट बनाने के लिए उपयोग कर रहे हैं, या यहां तक कि अगर आप कुछ जानकारी प्राप्त करने की कोशिश कर रहे हैं, तो ओआरएम इसके लायक नहीं है।
यदि दूसरी तरफ आपके पास ऑब्जेक्ट्स के माध्यम से मॉडलिंग की गई एक जटिल प्रणाली है, तो प्रत्येक के पास अलग-अलग नियम होते हैं और वे गतिशील रूप से बातचीत करते हैं और आप चिंता करते हैं कि कुछ मौजूदा SQL स्क्रिप्ट को प्रतिस्थापित करने के बजाय डेटाबेस में जानकारी तब जारी रहती है, फिर ORM के लिए जाएं।
हां, ओआरएम आपके आवेदन को धीमा कर देगा। अमूर्तता कितनी दूर जाती है, इस पर निर्भर करता है कि आपका ऑब्जेक्ट मॉडल डेटाबेस पर कितना अच्छा है, और अन्य कारक। प्रश्न होना चाहिए, क्या आप अधिक डेवलपर समय बिताने के लिए तैयार हैं और धीमी रनटाइम प्रदर्शन के लिए सीधे डेटा एक्सेस का उपयोग करते हैं या कम देव समय का व्यापार करते हैं।
कुल मिलाकर, अच्छे ओआरएम के पास थोड़ा ओवरहेड होता है और, बड़े पैमाने पर, व्यापार को अच्छी तरह से माना जाता है।
मुझे हमेशा यह पता चला है कि इससे कोई फर्क नहीं पड़ता। आपको जो भी सबसे अधिक उत्पादक, परिवर्तनों के प्रति उत्तरदायी बनायेगा, और जो भी डीबग और बनाए रखने के लिए सबसे आसान है, उसका उपयोग करना चाहिए।
अधिकतर अनुप्रयोगों को ओआरएम और एसपी के बीच अंतर के लिए पर्याप्त भार की आवश्यकता नहीं होती है। और ओआरएम तेज़ी से बनाने के लिए अनुकूलन हैं।
अंत में, एक अच्छी तरह से लिखित ऐप में डेटा की पहुंच अन्य सभी चीज़ों से अलग हो जाएगी ताकि भविष्य में ओआरएम से स्विच करने के लिए जो भी संभव हो।
एक ओआरएम हमेशा अमूर्तता की परतों के कारण कुछ ओवरहेड जोड़ देगा, लेकिन जब तक कि यह एक खराब रूप से डिज़ाइन किया गया ओआरएम नहीं है जो न्यूनतम होना चाहिए। वास्तव में डेटाबेस से पूछताछ करने का समय ओआरएम आधारभूत संरचना के अतिरिक्त ओवरहेड से कई गुना अधिक होगा यदि आप इसे सही तरीके से कर रहे हैं, उदाहरण के लिए पूर्ण ऑब्जेक्ट ग्राफ को लोड न होने पर लोड नहीं किया जा रहा है। एक अच्छा ओआरएम (nHibernate) डेटाबेस के विरुद्ध चलने वाले प्रश्नों के लिए आपको कई विकल्प भी देगा ताकि आप आवश्यकतानुसार अनुकूलित भी कर सकें।
मुझे कभी समझ में नहीं आया कि लोग क्यों सोचते हैं कि यह धीमा है या धीमा है ... मैं एक वास्तविक मशीन प्राप्त करता हूं। मेरे पास मिश्रित परिणाम हुए हैं ... मैंने देखा है कि संग्रहीत प्रक्रिया के लिए निष्पादन समय ओआरएम की तुलना में बहुत धीमा है और इसके विपरीत vise .. लेकिन दोनों मामलों में प्रदर्शन हार्डवेयर में अंतर के कारण था।
ओआरएम परिभाषा के अनुसार लगभग धीमा है। यह एक और परत है जिसे डेटाबेस में राज्य और अपने राज्य का ट्रैक रखना है। इसलिए यह एक अच्छी तरह से लिखित क्वेरी से तेज नहीं हो सकता है। इसके अलावा, यदि आप आंतरिक कार्यकलापों को नहीं जानते हैं (आंतरिक कार्य की ढाल के लिए ओआरएम का उद्देश्य क्या है) तो आप भयानक प्रश्न बना सकते हैं। – David
मुझे पता चला है कि "बहुत धीमी" और "बहुत धीमी नहीं" के बीच का अंतर इस बात पर निर्भर करता है कि आपके पास ORM का दूसरा स्तर (सत्र फ़ैक्टरी) कैश सक्षम है या नहीं। इसके साथ ही यह विकास भार के तहत ठीक से संभालता है, लेकिन हल्के उत्पादन भार के तहत आपके सिस्टम को कुचल देगा। द्वितीय स्तर के कैश को चालू करने के बाद सर्वर ने अपेक्षित लोड को संभाला और अच्छी तरह से स्केल किया।
एक ओआरएम का उपयोग आम तौर पर धीमा होता है। लेकिन आपको प्राप्त उत्पादकता में वृद्धि आपके आवेदन को प्राप्त करेगी और बहुत तेजी से चल रही है। और जब आप बचाते हैं तो बाद में आपके आवेदन के उन हिस्सों को ढूंढने में खर्च किया जा सकता है जो सबसे बड़ी धीमी गति से पैदा कर रहे हैं - फिर आप उन क्षेत्रों को अनुकूलित करने में समय व्यतीत कर सकते हैं जहां आपको अपने विकास प्रयास पर सबसे अच्छा रिटर्न मिलता है। सिर्फ इसलिए कि आपने ओआरएम का उपयोग करने का निर्णय लिया है, इसका मतलब यह नहीं है कि आप कोड के उन अनुभागों में अन्य तकनीकों का उपयोग नहीं कर सकते हैं जो वास्तव में इससे लाभ उठा सकते हैं।
एक ओआरएम धीमा हो सकता है, लेकिन डेटा को कैश करने की उनकी क्षमता से यह ऑफसेट होता है, इसलिए विकल्प को तेज़ करता है, आप स्मृति से पढ़ने से ज्यादा तेज नहीं हो सकते हैं।
SqlCe उपयोग करने के खिलाफ एक विंडोज़ मोबाइल 5 परियोजना में, मैं उत्पन्न (CodeSmith) एक ORM टेम्पलेट का उपयोग कर वस्तुओं कोड करने के लिए हाथ कोडित वस्तुओं का उपयोग करने से चला गया। प्रक्रिया में मेरे सभी डेटा एक्सेस बेस बेस के रूप में सीएसएलए का इस्तेमाल करते थे।
सीधे रूपांतरण ने स्थानीय परीक्षण में 32% तक अपने प्रदर्शन में सुधार किया, लगभग सभी इसे बेहतर पहुंच विधियों का परिणाम बनाते हैं।
उस परिवर्तन के बाद, हमने टेम्पलेट्स को समायोजित किया (स्टीव लेस्कर द्वारा पीडीसी में कुछ एसक्लसी प्रदर्शन सामग्री देखने के बाद) और कम से कम 20 मिनट में, हमारी संपूर्ण डेटा परत में काफी सुधार हुआ, हमारी औसत 'धीमी' कॉल 460ms से बढ़ीं ~ 20ms। ओआरएम सामान के बारे में अच्छा हिस्सा यह है कि हमें केवल इन परिवर्तनों को एक बार लागू करना था (और इकाई परीक्षण) और सभी डेटा एक्सेस कोड बदल गए। यह एक अद्भुत समय बचाने वाला था, हम शायद 40 घंटे या उससे अधिक बचाया।
उक्त जा रहा है इसके बाद के संस्करण, हम 'इंतज़ार कर' और 'प्रगति' संवाद नहीं रह गया है की जरूरत थी इस बात का एक गुच्छा बाहर लेने के द्वारा कुछ समय खोना था।
उन दोनों काफी अच्छी तरह से प्रदर्शन किया है और किसी भी प्रदर्शन नुकसान:
मैं ORM उपकरणों के कुछ का इस्तेमाल किया है, और मैं उनमें से दो सिफारिश कर सकते हैं ध्यान देने योग्य नहीं है।
ORM धीमी है?
नहीं स्वाभाविक। कुछ हेवीवेट ओआरएम चीजों को सामान्य ड्रैग जोड़ सकते हैं लेकिन हम परिमाण की मंदी के आदेश नहीं बोल रहे हैं।
करता है ओआरएम धीमा भयानक उपयोग करता है। यदि आप ओआरएम का उपयोग कर रहे हैं क्योंकि यह आसान दिखता है और आप नहीं जानते कि अंतर्निहित संबंधपरक डेटा मॉडल कैसे काम करता है, तो आप ओओ प्रोग्रामर के लिए उचित कोड लिख सकते हैं, लेकिन प्रदर्शन को मार देंगे।
ORM एक उपयोगी टूल है, लेकिन आप निचले स्तर समझ (कि आम तौर पर एसक्यूएल प्रश्नों लिखने से आता है) इसके साथ जाने की जरूरत है।
इससे कोई फर्क पड़ता है?
यदि आप एक साथ तेजी से जुड़ने की बजाय हजारों इकाइयों के लिए एक लूप क्वेरी कर रहे हैं, तो निश्चित रूप से यह कर सकता है।
हां, ओआरएम प्रदर्शन को प्रभावित करते हैं, चाहे वह मायने रखता है अंततः आपके प्रोजेक्ट के विनिर्देशों पर निर्भर करता है।
प्रोग्रामर्स अक्सर ORM पसंद है क्योंकि वे अच्छे सामने के अंत दृश्य स्टूडियो की तरह वातावरण cding पसंद है और कोई IntelliSense साथ कच्चे एसक्यूएल कोडिंग नापसंद करते हैं, आदि
ORMs अन्य सीमाओं एक प्रदर्शन हिट के अलावा है - वे भी अक्सर करते हैं ऐसा न करें जो आपको 100% समय की आवश्यकता है, एक अतिरिक्त अमूर्त परत की जटिलता को जोड़ना चाहिए जिसे हर बार छिंग बनने के बाद बनाए रखा जाना चाहिए और फिर से स्थापित किया जाना चाहिए, इसके साथ निपटने के लिए भी कैशिंग मुद्दे हैं।
बस एक विचार - यदि डेटाबेस विक्रेता एसक्यूएल प्रोग्रामिंग वातावरण को विजुअल स्टूडियो के रूप में अच्छा बनाते हैं, और डीबी कोड और फ्रंट एंड कोड के बीच एक और प्राकृतिक संबंध प्रदान करते हैं, तो हमें ओआरएम की आवश्यकता नहीं होगी .. मुझे लगता है कि चीजें अंततः उस दिशा में जा सकती हैं।
इंटेलिजेंस/स्वतः पूर्ण के साथ शायद GUI- आधारित SQL dev टूल के _hundreds_ हैं। –
@ जॉन लॉल बिल्कुल। –
* यदि डेटाबेस विक्रेता SQL प्रोग्रामिंग वातावरण को विजुअल स्टूडियो के रूप में अच्छा बनाते हैं, और डीबी कोड और फ्रंट-एंड कोड के बीच एक अधिक प्राकृतिक संबंध प्रदान करते हैं, तो हमें ORM * की आवश्यकता नहीं होगी ** ** इसका क्या अर्थ है? * * – nawfal
ओआरएम परिमाण धीमा करने का आदेश प्राप्त कर सकता है, न केवल बहुत सी CPU चक्रों को बर्बाद करने के grount = s पर, बल्कि अधिक स्मृति का उपयोग करके जो जीसी-डी होना चाहिए।
इतना बुरा है कि हालांकि यह है कि ओआरएम (एसक्यूएल के विपरीत) के लिए कोई मानक नहीं है और यह कि मेरे और बड़े ओआरएम का उपयोग एसक्यूएल अक्षमता से भिन्न होता है, इसलिए दिन के अंत में आपको अभी भी एसक्यूएल में खोदना होगा मुद्दों और हर बार एक ओआरएम एक गड़बड़ करता है और आपको इसे डीबग करना होगा। मतलब है कि आपने कुछ भी हासिल नहीं किया है।
यह वास्तविक उत्पादन स्तर के अनुप्रयोगों के लिए बहुत अपरिपक्व तकनीक है। बहुत ही समस्याग्रस्त चीजें इंडेक्स पदानुक्रमों और बहुत लंबे लेनदेन को फिट करने के लिए इंडेक्स, विदेशी कुंजी, ट्विकिंग टेबल को संभालने वाली हैं, जिसका अर्थ है कि अधिकतर डेडलॉक्स और दोहराने का मतलब है - अगर एक ओआरएम जानता है कि इसे कैसे संभालना है।
यह वास्तव में सर्वर को कम स्केलेबल बनाता है जो लागत को बढ़ाता है लेकिन शुरुआत में इन लागतों का उल्लेख नहीं किया जाता है - थोड़ा असुविधाजनक सत्य :-) जब कुछ इष्टतम से 10-100 गुना अधिक लेनदेन का उपयोग करता है तो यह एसक्यूएल पक्ष को स्केल करना असंभव हो जाता है बिलकुल। गंभीर प्रणालियों के बारे में बात करना फिर से घर/खिलौना/अकादमिक सामान नहीं।
ORM की धीमी है और आवेदन करने के लिए भूमि के ऊपर जोड़ने (जब तक आप विशेष रूप से इन समस्याओं, जो बहुत आम नहीं है चारों ओर पाने के लिए जानते हैं) करते हैं। डेटाबेस सबसे महत्वपूर्ण तत्व है और वेब अनुप्रयोगों को इसके चारों ओर डिजाइन किया जाना चाहिए।
सक्रिय रिकॉर्ड या ओआरएम का उपयोग करने वाले कई ओओपी ढांचे, सामान्य रूप से डेवलपर्स - डेटाबेस को एक महत्वहीन विचार के रूप में मानते हैं और इसे देखने के लिए वास्तव में कुछ सीखने की आवश्यकता नहीं होती है। लेकिन प्रदर्शन और स्केलेबिलिटी आमतौर पर पीड़ित होती है क्योंकि डीबी का भारी कर लगाया जाता है!
कई बड़े पैमाने पर किए गए वेब ऐप्लिकेशन फ्लैट गिर गए हैं, समय के वर्षों के लिए लाखों लोगों की और महीनों बर्बाद क्योंकि वे डेटाबेस के महत्व को पहचाना नहीं। लाखों रिकॉर्ड वाले समवर्ती उपयोगकर्ताओं और तालिकाओं के सैकड़ों डेटाबेस डेटाबेस ट्यूनिंग और अनुकूलन की आवश्यकता होती है। लेकिन मेरा मानना है कि समस्या कुछ उपयोगकर्ताओं और कम डेटा के साथ ध्यान देने योग्य है।
क्यों डेवलपर्स बहुत डर उचित एसक्यूएल और ट्यूनिंग उपायों जब यह प्रदर्शन की कुंजी है जानने के लिए कर रहे हैं?
* "स्टोर प्रक्रिया की तुलना में मुझे वास्तव में ओआरएम पसंद है" * - सेब और संतरे। –