एकाधिक डेटाबेस एक्सेस या एक बड़े पैमाने पर एक्सेस?

25

जब प्रदर्शन और इष्टतम संसाधन उपयोग की बात आती है तो एक बेहतर तरीका क्या है: AJAX के माध्यम से एक डेटाबेस को कई बार एक्सेस करना केवल आवश्यक जानकारी प्राप्त करने के लिए आवश्यक होने पर, या किसी ऑब्जेक्ट को प्राप्त करने के लिए एक एक्सेस करना जो सभी जानकारी रखता है जिसकी आवश्यकता हो सकती है एक उच्च संभावना के साथ कि वास्तव में सभी की आवश्यकता नहीं है?

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

performance sql

— DudeOnRock
स्रोत

जो मंच का उपयोग कर रहे हैं। अगर LAMP u cud मेमेकिंग का उपयोग करता है

— ravi404

किसी भी अन्य प्रदर्शन अनुकूलन के रूप में भी, आप इसे मापते हैं।

— तेलस्टिन

2

@Telastyn: मैं कुछ मौलिक डिजाइन निर्णय ले रहा हूं और एक मंचन सर्वर नहीं है। मेरे सभी डीबी-कॉल एए डीबी के लिए हैं जो उसी मशीन पर रहते हैं जहां पीएचपी निष्पादित होता है। मैं इस संबंध में अन्य लोगों के अनुभव से सीखने की उम्मीद कर रहा था, इससे पहले कि मुझे इस बात का एहसास हो जाए कि जिस मार्ग को मैंने तय किया था वह बहुत अच्छा था जब सब कुछ स्थानीय था, लेकिन उप-इष्टतम जब लाइव लिया गया था।

— ड्यूडेऑनॉक

1

@DudeOnRock - मंजूरी सामान्य रूप में यह डेटा परिवर्तन आपके उपयोग पैटर्न पर और कैसे निर्भर करता है। यदि कोई क्वेरी 80% लोगों को प्रदान करती है और डेटा अक्सर बदलता नहीं है, तो उसके साथ जाएं। आसान कैश करने के लिए, अनुकूलन करने के लिए आसान है। यदि कोई क्वेरी 5% की तरह लौटाता है जो आमतौर पर उपयोगकर्ताओं को चाहिए, तो शायद नहीं। मैं कम से अधिक प्रश्नों की ओर रुख करूंगा। डीबी में जाने से पहले आप सर्वर पर हमेशा उन्हें काट सकते हैं। 'सब कुछ एक क्वेरी बनाता है' को पूर्ववत करने के लिए कठिन।

— तेलास्टिन डे

@ravz: दिलचस्प लगता है!

— ड्यूडॉनरॉक

27

इसका कोई सही उत्तर नहीं है; किसी भी अनुकूलन की तरह यह संदर्भ / उपयोग पर बहुत अधिक निर्भर करता है।

हालांकि, अंगूठे के नियम के रूप में निम्नलिखित पर विचार करें:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

— एड हेस्टिंग्स
स्रोत

24

अनुकूलन का पहला नियम याद रखें: माप, अनुमान न करें । दोनों की कोशिश करें, उन्हें किसी प्रकार के स्टॉपवॉच कोड के साथ उपकरण दें, और देखें कि क्या अधिक समय लगता है।

और पुराने मजाक को भी ध्यान में रखें कि "कंप्यूटर विज्ञान में केवल दो कठिन समस्याएं हैं: कैश अमान्य होना और चीजों को अच्छी तरह से नाम देना।" यदि आप एक ही बार में DB से सब कुछ खींचते हैं और इसे मेमोरी में रखते हैं, तो आपके पास कैश है। और अब आपको एक नई समस्या है: कभी भी सिस्टम में कहीं भी कुछ भी परिवर्तन होता है , उसे दो स्थानों पर एक ही परिवर्तन करना पड़ता है: डेटाबेस और कैश। यदि आपके पास सर्वर को संशोधित करने के लिए DB, या कई API से बात करने वाले एक से अधिक सर्वर हैं, तो यह बहुत जल्दी बहुत मुश्किल हो सकता है।

— मेसन व्हीलर
स्रोत

और सुनिश्चित करें कि आप क्या मापते हैं। उदाहरण के लिए परिणाम डेटाबेस कनेक्शन बैंडविथ और विलंबता के आधार पर भिन्न हो सकते हैं।

— स्पेसट्रॉकर

4

इस प्रश्न का कोई सिल्वर बुलेट समाधान नहीं है । मुझे लगता है कि आपको इसका सबसे अच्छा लाभ प्राप्त करने के लिए संभावित व्यापार-बंदों और अपने सर्वर (यों) को ट्राय करने की आवश्यकता है।

पहला बिंदु: किसी भी सुधार को करने से पहले आपको अपने वर्तमान प्रदर्शन बेंचमार्क को सेट करने की आवश्यकता है , इसे मापना , और इसे बेहतर बनाने के लिए तुलनात्मक समाधानों में आधारभूत उपाय करना।

दूसरी बात यह है कि, एप्लिकेशन उपयोग को ट्रैक करना होगा। जिस तरह से एप्लिकेशन का उपयोग अंतिम उपयोगकर्ताओं द्वारा किया जाता है। लौटाए गए डेटा कच्चे नंबरों को काटना जो अंतिम उपयोगकर्ता के लिए आवश्यक नहीं है, आपको बहुत कीमती सर्वर संसाधनों को बचा सकता है । उदाहरण के लिए: 5000 रिकॉर्ड वापस करने का कोई मतलब नहीं है जबकि उपयोगकर्ता पहले 50 में रुचि रखते हैं।

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

— एल युसुबोव
स्रोत

2

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

— TMN
स्रोत

टिप्पणियों के अनुसार, यह एक स्थानीय डेटाबेस का उपयोग कर रहा है, इसलिए यहां "तार पर" विलंबता नहीं है।

— मेसन व्हीलर

1

टिप्पणियों के अनुसार, वह ऐसी रणनीतियों की तलाश कर रहा था जो "महान होगा जब सब कुछ स्थानीय था, लेकिन लाइव होने पर उप-इष्टतम"।

— टीएमएन

1

यदि आप वास्तु निर्णय ले रहे हैं, तो REST एक विकल्प है। REST के साथ, आप हमेशा एक संसाधन के लिए कई बार अनुरोध करते हैं, अर्थात आप 2 ऑब्जेक्ट प्राप्त करने के लिए अनुरोध नहीं भेजते क्योंकि प्रत्येक वस्तु का अपना url होता है। इस शैली को करने के साथ प्रदर्शन की चिंता शायद तब हल हो जाएगी जब HTTP / 2.0 बाहर आएगा। अन्यथा, आप इसे जितनी जल्दी हो सके बनाने के लिए अनुकूलित करते हैं। बहुत सारी कंपनियां इस तरह से कर रही हैं।

— imel96
स्रोत