LINQ कितनी तेज़ है?

Question

मुझे 100,000 - 200,000 रिकॉर्डों में हेरफेर करने की आवश्यकता है।
मैं ऐसा करने के लिए LINQ (SQL में) का उपयोग करने के बारे में सोच रहा हूं।
मुझे अनुभव से पता है कि डेटाव्यू फ़िल्टरिंग बहुत धीमी है।
तो LINQ कितनी जल्दी है?

आप कृपया मुझे अपने अनुभवों को बता सकते हैं और यदि इसे प्रयोग के लायक है, या मैं एसक्यूएल संग्रहित प्रक्रियाओं का उपयोग कर (भारी जा रहा है और कम लचीला) से बेहतर हो सकता है?

रिकॉर्ड मैं डेटा के समूहों को खोजने और उसके बाद की प्रक्रिया उन्हें जरूरत के हजारों के भीतर, प्रत्येक समूह के बारे में 50 रिकॉर्ड है।

Answer 1

LINQ T-SQL में अपनी क्वेरी अभिव्यक्ति तब्दील हो, तो आपकी क्वेरी प्रदर्शन ठीक वही होना चाहिए जैसे कि आप ADO.NET के माध्यम से उस SQL ​​क्वेरी भेज दिया। मुझे लगता है कि थोड़ा सा ओवरहेड है, आपकी क्वेरी के लिए एक्सप्रेशन ट्री को समकक्ष टी-एसक्यूएल में परिवर्तित करने के लिए, लेकिन मेरा अनुभव यह है कि वास्तविक क्वेरी समय की तुलना में यह छोटा है।

आप निश्चित रूप से पता कर सकते हैं कि वास्तव में क्या T-SQL उत्पन्न होता है, और इसलिए सुनिश्चित करें कि आप अच्छा समर्थन अनुक्रमित किया हुआ है।

DataViews से प्राथमिक अंतर यह है कि LINQ एसक्यूएल के लिए स्मृति में सभी डेटा नहीं लाती है और वहाँ यह फ़िल्टर कर है। इसके बजाय यह डेटाबेस को वह करने के लिए प्राप्त करता है जो यह अच्छा है और केवल मिलान डेटा को मेमोरी में लाता है।

Answer 2

आम तौर पर उन कई रिकॉर्डों में हेरफेर डीबी के लिए जितना संभव हो उतना करीब होना चाहिए। अगर यह मेरा काम है जहां मैं इसे संग्रहित प्रोसेस में करना चाहता हूं। वह मुझे व्यक्तिगत रूप से। लिंक अभी तक डेटा एक्सेस के शीर्ष पर अमूर्तता की एक और परत है और यह "सामान्य" आवश्यकताओं के लिए अच्छी तरह से काम करता है यानी यूआई को भेजे गए कुछ सौ इकाइयां इसे डेटा वेयरहाउस प्रकार के संचालन के प्रतिस्थापन के रूप में नहीं सोचना चाहिए। एसक्यूएल को

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

स्टैक ओवरफ्लो लिंक का उपयोग करता है, और यह एक छोटा डेटाबेस नहीं है।

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

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

अपडेट के लिए, एक संग्रहित प्रो या एसक्यूएल में "अद्यतन ... कहां ..." के साथ सेट-आधारित सर्वर-साइड ऑपरेशंस रिकॉर्ड पढ़ने के लिए एकाधिक डेटाबेस राउंड-ट्रिप का उपयोग करने से बहुत तेज़ होगा एक रिकॉर्ड, दोहराना।

Answer 6

मुझे लगता है कि LINQ जेनरेट किए गए प्रश्न अच्छे हैं। linq प्रश्नों में लागू कुछ सर्वोत्तम प्रथाओं, जैसे कि, मालिक से उपसर्ग तालिका नाम, (*) से बचें और इसी तरह से। जब प्रश्न जटिल होते हैं (एक साधारण शामिल होने से अधिक) मैंने पाया कि linq हमेशा एक अच्छा समाधान ढूंढता है, और मेरा समाधान कभी बेहतर नहीं था (इसलिए मेरा एसक्यूएल प्रोफाइलर कहता है)।

फिर सवाल यह है: यह बेहतर सीधी क्वेरी है ... या संग्रहित प्रो में रैपिंग क्वेरी है? संग्रहित प्रो बेहतर होना चाहिए, क्योंकि निष्पादन योजना संग्रहित की जाती है। लेकिन वास्तव में, जब आप .net sql सर्वर प्रदाता द्वारा चयन करते हैं, तो आप एक विशेष संग्रहीत प्रक्रिया को कॉल करते हैं, जहां पहला पैरामीटर आपका क्वेरी टेक्स्ट होता है। फिर निष्पादन योजना वैसे भी कैश किया जाता है।

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

Answer 7

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

थोक अपडेट के लिए यह एक ही अपडेट स्टेटमेंट भेजने के रूप में कहीं भी कुशल नहीं है जो एक समय में पंक्तियों के पूरे बैच पर लागू होता है।