मुझे समझ में नहीं आता कि SQL कमांड कैसे एक बड़े परिणाम को सॉर्ट करेगा। क्या यह मक्खी पर स्मृति में किया जाता है (यानी जब कोई प्रश्न छिद्रित होता है)?एसक्यूएल ऑर्डर द्वारा कितना महंगा है?
एसक्यूएल में ORDER BY का उपयोग करके सॉर्ट करने के लिए तेज़ होने जा रहा है, बजाय जावा जैसी भाषा में परिणाम युक्त ऑब्जेक्ट्स की एक लिंक्ड सूची कहें (एक तेज़ बिल्ट-इन सॉर्ट, शायद क्विकॉर्ट का उपयोग करके)?
यह डेटाबेस में डेटा को सॉर्ट करने के लिए लगभग निश्चित रूप से अधिक कुशल होगा। डेटाबेस को बड़े डेटा वॉल्यूम से निपटने के लिए डिज़ाइन किया गया है। और डेटाबेस के लिए कई अनुकूलन उपलब्ध हैं जो मध्यम स्तर पर उपलब्ध नहीं होंगे। यदि आप मध्यम स्तर पर एक हाइपर-कुशल सॉर्ट रूटीन लिखने की योजना बनाते हैं जो आपके डेटा के बारे में जानकारी का लाभ उठाता है जो डेटाबेस नहीं करता है (यानी मध्यम स्तर की दर्जनों मशीनों के समूह के लिए डेटा को खेती करना ताकि सॉर्ट कभी डिस्क पर नहीं फैलता है, इस तथ्य का लाभ उठाते हुए कि आपका डेटा अधिकतर एल्गोरिदम चुनने का आदेश दिया जाता है जो आमतौर पर विशेष रूप से कुशल नहीं होता), आप शायद डेटाबेस की सॉर्ट गति को हरा सकते हैं। लेकिन यह दुर्लभ हो जाता है।
क्वेरी के आधार पर, उदाहरण के लिए, डेटाबेस ऑप्टिमाइज़र एक क्वेरी प्लान चुन सकता है जो बिना किसी प्रकार के डेटा को क्रम में लौटाता है। उदाहरण के लिए, डेटाबेस जानता है कि किसी इंडेक्स में डेटा सॉर्ट किया गया है, इसलिए यह पूरे परिणाम सेट को पूरा करने और सॉर्ट किए बिना डेटा को वापस करने के लिए इंडेक्स स्कैन करने का विकल्प चुन सकता है। अगर इसे पूरे नतीजे को पूरा करना पड़ता है, तो इसे केवल उन कॉलमों की आवश्यकता होती है जिन्हें आप सॉर्ट कर रहे हैं और किसी प्रकार की पंक्ति पहचानकर्ता (यानी ओरेकल में एक ROWID) की बजाय डेटा की पूरी पंक्ति को सॉर्ट करने के बजाय एक निष्क्रिय मध्यम स्तरीय कार्यान्वयन की संभावना है । उदाहरण के लिए, यदि आपके पास एक समग्र इंडेक्स है (col1, col2) और आप UPPER (col2), लोअर (col1) को सॉर्ट करने का निर्णय लेते हैं, तो डेटाबेस इंडेक्स से col1 & col2 मानों को पढ़ सकता है, पंक्ति पहचानकर्ताओं को सॉर्ट कर सकता है, और फिर तालिका से डेटा लाने के लिए जाओ। बेशक, डेटाबेस को ऐसा करने की ज़रूरत नहीं है - ऑप्टिमाइज़र खाते से डेटा या विभिन्न इंडेक्स से डेटा लाने की लागत के खिलाफ एक प्रकार की लागत को ध्यान में रखेगा। डेटाबेस अच्छी तरह से निष्कर्ष निकाल सकता है कि सबसे कुशल तरीका तालिका स्कैन करना है, पूरी पंक्ति को स्मृति में पढ़ें, और इसे सॉर्ट करें। यह निष्कर्ष निकाला जा सकता है कि डेटा लाने के लिए इंडेक्स का परिणाम अधिक I/O होता है लेकिन इस तरह की लागत को कम या समाप्त करके इसके लिए बनाता है।
क्या आप केवल आवश्यकता कॉलम और पंक्ति आईडी के बारे में विस्तार कर सकते हैं। आपका मतलब है कि यह कुछ कॉलम लाएगा, उन्हें सॉर्ट करेगा, फिर वापस जाएं और सॉर्ट ऑर्डर के आधार पर पूर्ण कॉलम लाएगा? डिस्क –
@ जोडा से प्रत्येक पंक्ति को डबल लाने के साथ यह बहुत धीमा लगता है - थोड़ा विस्तारित। मेरा मतलब यह नहीं था कि इसे डेटा को कई बार लाने के लिए था कि डेटाबेस में विभिन्न संरचनाएं हो सकती हैं जो कि एक तरह की आवश्यकता को अनुकूलित (या खत्म) करने के लिए लाभ उठा सकती हैं। –
उत्तर है ... यह निर्भर करता है। यदि डेटाबेस में किसी इंडेक्स का उपयोग करके ऑर्डर द्वारा किया जा सकता है, तो क्वेरी के लिए निष्पादन योजना उस इंडेक्स का उपयोग करेगी और परिणाम सीधे डीबी से सही क्रम में वापस आ जाएंगे। यदि नहीं, तो डेटाबेस सॉर्टिंग निष्पादित करेगा, लेकिन यह संभवतः स्मृति में सभी परिणामों को पढ़ने से बेहतर होगा (और लिंक सूची में परिणाम पढ़ने से निश्चित रूप से बेहतर है)।
मुझे लगता है कि मैं समझ में नहीं आता कि मध्यवर्ती डेटा संरचनाएं आम तौर पर इस तरह दिखती हैं कि डीबी अपने स्वयं के सॉर्टिंग के लिए उपयोग करेगा। किसी भी प्रकाश को बहाल करने की देखभाल? –
सॉर्टिंग जैसे कार्य वे चीजें हैं जो डेटाबेस अच्छे हैं, इसलिए डेटा संरचनाओं को उस कुशल बनाने के लिए डिज़ाइन किया गया है - उदाहरण के लिए, संतुलित बाइनरी पेड़ जिन्हें प्रत्येक रिकॉर्ड डालने के साथ अद्यतन रखा जाता है। इंडेक्स में पूरी पंक्ति नहीं है, केवल एक रिकॉर्ड आईडी, प्राथमिक कुंजी, डीबी के भीतर स्थान। जब आप एक क्रमबद्ध परिणाम मांगते हैं, तो यह उन स्थानों को तुरंत आपके द्वारा भेजे गए क्रम में वापस कर सकता है, और फिर परिणामसेट के लिए पूर्ण पंक्तियों को देख सकता है। –
केवल ** सबसे छोटे डेटा सेट ** में, प्रदर्शन डेटाबेस और एक एप्लिकेशन भाषा के बीच बराबर होगा। –
सटीक विधि आपके द्वारा उपयोग किए जा रहे उत्पाद पर निर्भर करती है, लेकिन आम तौर पर एक पूरी तरह से विशेष रुप से प्रदर्शित डीबीएमएस के पास इसके निपटारे में एकाधिक प्रकार के एल्गोरिदम होते हैं। डिस्क पर कुछ काम, समय के साथ अंतरिक्ष के लिए अनुकूलित, स्मृति में कुछ काम, गति के लिए अनुकूलन। यदि आप गोरी के विवरण में रूचि रखते हैं, तो उपलब्ध ओपन सोर्स वाले के स्रोत कोड की जांच करें।
यह संभावना नहीं है कि आप स्वयं को सॉर्ट करने या कुछ अन्य लाइब्रेरी का उपयोग करके बेहतर परिणाम प्राप्त करने जा रहे हैं, हालांकि कुछ ऑपरेटिंग सिस्टम के qsort() जैसे कुछ डेटा वितरण के साथ पैथोलॉजिकल केस हो सकते हैं। यदि आपको जरूरी है तो इसे आज़माएं, लेकिन अपने डेटा को प्रबंधित करने के लिए डीबीएमएस का उपयोग करना पसंद करें, क्योंकि यही वह है जो वे अच्छे हैं।
जब तक आप डेटाबेस प्रकार का उपयोग नहीं करते हैं, तो सॉर्ट इंडेक्स आधारित नहीं है, आप गारंटी दे रहे हैं कि परिणाम परिणाम की एक पंक्ति भी देखने से पहले आप पूरे परिणाम सेट को हल करने और डेटाबेस में सॉर्ट करने की प्रतीक्षा करेंगे।
यदि आप इसे स्वयं सॉर्ट करते हैं तो डेटा को क्रमशः स्ट्रीम किया जा सकता है (नेटवर्क बाधित वातावरण के लिए बेहतर) और शायद सॉफ़्टवेयर ऑपरेशन कुल समय की समान मात्रा में उपभोग करने के बावजूद निष्पादन विलंब को कम करने के लिए वृद्धिशील रूप से उपयोगी हो सकता है।
परिनियोजन परिदृश्य के आधार पर यह एक बड़ा अंतर डाल सकता है जहां सॉर्टिंग से जुड़ी अतिरिक्त लागत का भुगतान किया जाना चाहिए। परिदृश्य में मैं मध्यम स्तर के साथ काम करता हूं डिस्पोजेबल और स्केलेबल होता है जबकि डेटा स्तर अधिक महंगा होता है। यदि यह एक ही सीपीयू खर्च करता है लेकिन परिचालन लागत के मामले में डेटाबेस सीपीयू की लागत 5x या 10x होती है तो यह डेटाबेस के बाहर इसे करने के लिए असली शर्तों में सस्ता हो जाती है।
डेटाबेस यह करता है तो यह लगभग हमेशा तेज है। – rook
आप किस परिमाण का अनुमान लगाएंगे? –
आप इसे स्वयं ही समय दे सकते हैं। यहां कुछ भी ज्यादा आधिकारिक है। –