डेटाबेस और वेब सेवा कॉल के बीच स्पीड अंतर क्या है?

Question

सभी चीजें बराबर होती हैं, और सबसे सरल रूप में, जो तेज़ी से होती है?
1.) एक वेब सेवा विधि
2.) एक डेटाबेस

उदाहरण के लिए, करने के लिए एक कॉल करने के लिए एक कॉल मान लें कि आपके एक सरल वेब सेवा है कि बस एक पूर्णांक है कि एक्स समय में गणना की जाती है रिटर्न है। आपके पास एक डेटाबेस भी है, जब सही तरीके से पूछताछ की जाती है, तो उत्तर की गणना करने के लिए एक्स समय भी लेता है। (इसलिए गणना समय दोनों मामलों में समान है) दोनों मामलों में, मान लें कि डेटा की मात्रा दोनों दिशाओं समान है, कहें, सादगी के लिए एक 32-बिट पूर्णांक।

अब तक, वेब सेवा और डेटाबेस दोनों की गणना समय बिल्कुल वही हैं।

पर्यावरण 1 एप्लिकेशन सर्वर है, जहां ऐप रहता है, और 1 अन्य सर्वर जो वेब सेवा और डेटाबेस दोनों को पकड़ रहा है। एप्लिकेशन में अन्यथा वेब सेवा या डेटाबेस को बार-बार कॉल करने के अलावा पर्यावरण में कुछ भी नहीं चल रहा है। यह सब एक ही लैन के भीतर है, इसलिए कोई नेटवर्क विलंबता बराबर है।

किसी एप्लिकेशन से, जो तेज़ी से होगा, डेटाबेस को कॉल करें, या वेब सेवा पर कॉल करें?

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

Answer 1

ओ (1) किसी भी समय की अवधि का संदर्भ नहीं देता है। एक एकल संचालन एक डेटाबेस में 100 सेकंड एक वेब सेवा पर .001 एमएस और समय लग सकता है और वे दोनों हे का उपयोग कर किया जा सकता है (1) कार्य: http://en.wikipedia.org/wiki/Big_O_notation

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

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

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

यदि आप गतिशीलता की तुलना में चिंतित हैं, जब webservice और डेटाबेस दोनों लैन पर हैं, तो मुझे पूरा यकीन है कि डीबी का ओवरहेड webservice से कम है। एप्लिकेशन आमतौर पर डीबी को एक राज्यव्यापी कनेक्शन बनाए रखता है, जबकि एक webservice के लिए अनुरोध http के माध्यम से होते हैं, जो स्टेटलेस, अपेक्षाकृत अधिक ऊपरी और धीमे होते हैं। हालांकि गलत हो सकता है। सबसे अच्छा जवाब एक सरल webservice, क्वेरी, और (1) दोनों विधियों का उपयोग करके परिणामों को पुनर्प्राप्त करने के लिए उपाय समय, और तुलना, और/या (2) एक ऐप बनाने के लिए होगा जो बहुत सारे धागे खोलता है और कुछ लोड करता है परिक्षण।

एक चेतावनी: यदि आपका ऐप खुले कनेक्शन को बनाए रखता है या डीबी के साथ कनेक्शन के पूल तक पहुंच नहीं है, तो डीबी विकल्प धीमा हो सकता है। एक डीबी कनेक्शन की प्रारंभिक रचना अपेक्षाकृत धीमी हो सकती है। लेकिन यह चीजों में शामिल नहीं होना चाहिए, क्योंकि आपको अपना ऐप लिखना चाहिए ताकि एक खुला कनेक्शन हमेशा बनाए रखा जा सके।

Answer 2

यदि हम मानते हैं कि आप वेब और डेटाबेस कॉल दोनों के लिए एक अलग सर्वर से संचार कर रहे हैं, तो क्या वे बहुत अधिक नहीं होंगे, क्योंकि दोनों अनुरोध टीसीपी/आईपी के माध्यम से स्थानांतरित किए जाते हैं? तब एकमात्र चीज की तुलना की जा सकती है कि तार के बिट्स के संदर्भ में वास्तविक परिणाम कितने बड़े होते हैं।

Answer 3

यह सब नेटवर्क टोपोलॉजी और भाषाओं पर निर्भर करता है जिनका आप उपयोग कर रहे हैं। यदि आप सी # बात कर रहे हैं ... मेरा पैसा डाटाबेस कॉल पर लगभग हर समय तेजी से होगा।

डेटाबेस सर्वर पर आपकी कॉल मूल प्रोटोकॉल पर बनाई जा रही है। सब कुछ अनुकूलित किया जा रहा है।

यदि आप एक वेब सेवा कॉल कर रहे हैं, तो आपको वेब सर्वर से अनुरोध भेजने के लिए कुछ तंत्र की आवश्यकता होगी, वेब सर्वर का जवाब देने के लिए प्रतीक्षा करें, और फिर वेब सेवा कॉल के परिणाम को पार्स करने के लिए कुछ अपने कोड में वापस।

Answer 4

कोई कह सकता है कि आम तौर पर, एक वेब सेवा (जो आम तौर पर इंटरनेट पर होगा) में नेटवर्क की विलंबता डेटाबेस के कॉल से धीमी हो जाएगी (जो आम तौर पर एक लैन या कुछ पर है, जो कि है इंटरनेट से किसी के कनेक्शन से तेज़)।

बेशक, यह सेटअप/सॉफ्टवेयर/इत्यादि के बारे में बहुत सी धारणाएं बनाता है जो प्रभावी रूप से इसे सेब और संतरे की तुलना में कम कर देता है, जिसके लिए कभी भी अच्छा जवाब नहीं होता है।

Answer 5

व्यावहारिक अनुभव के आधार पर, मैं कहूंगा कि डेटाबेस कॉल काफी तेज है।

Answer 6

एल्गोरिदमिक जटिलता केवल एक चर है जो सिस्टम के समग्र प्रदर्शन को प्रभावित करती है। अन्य कारकों में नेटवर्क विलंबता या नेटवर्क बैंडविड्थ शामिल हो सकता है, खासकर जब लौटाए गए डेटा का आकार अलग होता है।

यदि आप स्थानीय मशीन पर एक ही ओ (1) एल्गोरिदम चलाते हैं, तो आप परिणामों को तेज़ी से प्राप्त करेंगे यदि आप किसी अन्य महाद्वीप पर मशीन पर एल्गोरिदम चलाते हैं और नेटवर्क पर भेजे गए परिणामों की आवश्यकता होती है।

अन्य कारकों में शारीरिक रूप से अलग मशीनों पर कॉल किए जाने पर कच्चे CPU की गति शामिल हो सकती है।

यही कारण है कि समयपूर्व अनुकूलन सभी बुराइयों की जड़ है।

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

मैं इसे प्रणाली के विवरण पर और भी अधिक अब निर्भर करता है, कहेंगे यानी, क्या डेटाबेस सॉफ्टवेयर आप एक स्थिर वेब पेज से, या या नहीं, अपने वेब सेवा पढ़ रही है डेटा का उपयोग कर रहे हैं या डेटा को गतिशील रूप से उत्पन्न करना।

लेकिन मैं इस बात को खोने शुरू कर रहा हूं कि आप सवाल क्यों पूछ रहे हैं। आप कहते हैं कि दोनों विधियां एक ही समय लेती हैं। तो यदि वे एक ही समय लेते हैं, तो आप कैसे पूछ सकते हैं कि तेज़ कौन सा है? स्पष्ट रूप से वे समान रूप से तेज़ हैं। आपको हमें यह बताने की ज़रूरत है कि वे कितनी बार और कब एक ही समय लेना बंद कर देते हैं।

Answer 7

ओ (1) गति निर्दिष्ट नहीं करता है, यह आवश्यक समय में 'विकास' निर्दिष्ट करता है क्योंकि अंतर्निहित डेटा बड़ा हो जाता है। स्थिरांक समीकरण से गिराए जाते हैं। इसका अर्थ यह है कि ओ (एन^2) कुछ वास्तव में छोटे एन

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

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

क्या आप छोटे एसक्यूएल को पार्स कर सकते हैं और एक टेबल्ड परिणाम वापस पंच करने से पहले एक सर्वर पर एक पैकेट प्राप्त कर सकते हैं? अधिकतर, इन दिनों मैं कहता हूं कि यह टॉस अप था। कुछ नेटवर्क दूसरों की तुलना में तेज़ होते हैं, जबकि कुछ डेटाबेस और सर्वर बहुत अच्छे होते हैं। कुछ भी निश्चित नहीं है।

सामान्यतः, एक वेब सेवा डेटाबेस से तेज है? हां, अगर और केवल अगर सेवा तुच्छ है (यदि यह डेटाबेस छुपा रहा है, तो यह स्पष्ट रूप से अतिरिक्त समय है)। डेटाबेस बड़े भारी इंजन हैं, और जब वे पिछले कुछ वर्षों में बहुत तेजी से प्राप्त कर चुके हैं, तो उनके आधारभूत लेनदेन की अखंडता का न्यूनतम स्तर कम CPU उपयोग का उल्लेख करता है। वे धीमे हैं क्योंकि वे बहुत अधिक काम कर रहे हैं। तुलना करें कि नेटवर्क पहुंच के पीछे छिपी कुछ स्पष्ट न्यूनतम गणना के साथ। एक फाइबर या गीगाबिट नेटवर्क तेजी से डेटा ले जा सकता है। पूरा करने के लिए यह बहुत कम काम है।

बेशक हम कस्टम लिखित वेब सेवाओं के साथ डेटाबेस को प्रतिस्थापित नहीं करते हैं, समय है। इसे लिखने में बहुत लंबा समय लगता है, और फिर इसे अद्यतित रखें। इसे डेटाबेस में स्लैम करने और इसके प्रदर्शन को स्वीकार करने से अधिक प्रयास करें।

पॉल।

Answer 8

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