"अतिरिक्त" डेटाबेस क्वेरी होने में कितना बुरा है?

Question

मैं वेब विकास में सामने वाली दुनिया से आया हूं जहां हम जारी किए गए HTTP अनुरोधों की संख्या सीमित करने के लिए वास्तव में कड़ी मेहनत करते हैं (सीएसएस, जेएस फाइलों, छवियों, आदि को समेकित करके)।

डीबी कनेक्शन (MySQL) के साथ, जाहिर है कि आप अनावश्यक कनेक्शन नहीं चाहते हैं, लेकिन एक सामान्य नियम के रूप में, यह कई छोटे प्रश्नों के लिए कितना बुरा है? (वे जल्दी से निष्पादित)

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

हम प्रश्नों की एक टन बात नहीं कर रहे हैं, शायद 2-4 की बजाय 6-8 डीबी कॉल, कुछ हद तक रिकॉर्ड से कुछ हद तक रिकॉर्ड लौट रहे हैं। उनमें से प्रत्येक 30ms से कम (कुछ बहुत कम) जल्दी से निष्पादित करता है, लेकिन मुझे नहीं पता कि कुछ "कनेक्शन विलंबता" है जिसके बारे में मुझे चिंतित होना चाहिए।

आपकी अंतर्दृष्टि के लिए धन्यवाद।

Answer 1

संक्षिप्त उत्तर: (1) सुनिश्चित करें कि आप एक ही बड़े-ओ स्तर पर रह रहे हैं, कनेक्शन का पुन: उपयोग करें, प्रदर्शन मापें; (2) इस बारे में सोचें कि आप डेटा स्थिरता के बारे में कितना ख्याल रखते हैं।

लांग जवाब:

प्रदर्शन

प्रदर्शन के नजरिए से कड़ाई से

, और आम तौर पर बोल, जब तक कि आप पहले से ही इस तरह के अधिकतम कनेक्शन के रूप में अपने डेटाबेस संसाधनों, बाहर maxing के करीब हैं, यह नहीं होने की संभावना है गहरा असर। लेकिन कुछ चीजें हैं जिन्हें आपको ध्यान में रखना चाहिए:

• "2-8" प्रश्नों को प्रतिस्थापित करने के लिए "2-8" प्रश्नों को एक ही निष्पादन समय में रहते हैं? जैसे यदि वर्तमान डेटाबेस इंटरैक्शन O(1) पर है तो यह O(n) पर बदल जाएगा? या वर्तमान O(n)O(n^2) पर बदलने जा रहा है? यदि हां, तो आपको अपने आवेदन के लिए इसका क्या अर्थ है
• अधिकांश एप्लिकेशन सर्वर मौजूदा डेटाबेस कनेक्शन का पुन: उपयोग कर सकते हैं, या लगातार डेटाबेस कनेक्शन पूल कर सकते हैं; सुनिश्चित करें कि आपका एप्लिकेशन प्रत्येक क्वेरी के लिए एक नया कनेक्शन स्थापित नहीं करता है; अन्यथा यह इसे अधिक असुरक्षित बनाने के लिए जा रहा है
• कई आम मामलों में, मुख्य रूप से जटिल इंडेक्स और जुड़ने वाली बड़ी तालिकाओं पर, प्राथमिक कुंजी द्वारा कुछ प्रश्नों को एक ही प्रश्न में उन तालिकाओं में शामिल होने से अधिक कुशल हो सकता है; इस मामले में अगर होगा, जबकि कर इस तरह मिलती है, सर्वर न केवल समय लेता है जटिल क्वेरी प्रदर्शन करने के लिए, लेकिन प्रभावित टेबल

के खिलाफ भी ब्लॉक अन्य प्रश्नों आम तौर पर प्रदर्शन के बारे में बात करते हुए अंगूठे का नियम है - हमेशा मापने।

संगति

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

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

सामान्य प्रश्न यहां है - क्या आप अपने संबंधपरक डेटा के एसीआईडी ​​अनुपालन की परवाह करते हैं क्योंकि यह उन प्रश्नों से संबंधित है जो आप अलग कर रहे हैं? यदि उत्तर हाँ है, तो आपको इस बारे में सोचना चाहिए कि इन विशिष्ट मामलों में आपका एप्लिकेशन तर्क किस प्रकार प्रतिक्रिया करेगा।

Answer 2

एक वेब पेज के लिए 6-8 प्रश्न? आमतौर पर यह ठीक है। मुझे हर व़क्त यह करना है।

हजारों पंक्तियां लौट आईं? गला घोंटना! क्लाइंट उन लोगों के साथ क्या करने जा रहा है? एसक्यूएल अधिक प्रसंस्करण कर सकता है, तो कम पंक्तियों को वापस कर सकते हैं?

दुर्लभ अपवादों के साथ, प्रति वेब पेज केवल 1 कनेक्शन।

प्रत्येक क्वेरी में बहुत अधिक ओवरहेड है। उदाहरण के लिए, INSERTing एक पंक्ति में 100 पंक्तियां - 100 INSERT सिंगल-पंक्ति विवरणों में लगभग 100 बार एक 100-पंक्ति INSERT तक लग जाएगा। तो जब व्यावहारिक सर्वर के लिए कम राउंड-ट्रिप का उपयोग करें। यदि नेटवर्क एक वैन है तो यह बहुत महत्वपूर्ण हो जाता है। दुनिया के दूसरी तरफ केवल विलंबता के लिए 250 मीटर दूर है। एक ही डेटासेंटर में एक सर्वर शायद इतना करीब है कि विलंबता को अनदेखा किया जा सकता है। एक वैन में, गोल यात्रा को कम करने के लिए संग्रहीत रूटीन का उपयोग करें।

मुझे कोड में सक्रिय रूप से प्रत्येक क्वेरी को समय लगता है। फिर, यदि मुझे एक प्रदर्शन समस्या दिखाई देती है, तो मैं देखता हूं कि कौन सी क्वेरी पहले काम करेगी। या SlowLog का उपयोग करें।