फ़ाइल एक्सेस स्पीड बनाम डेटाबेस एक्सेस स्पीड

Question

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

1) क्या फ़ाइल I/O आमतौर पर डेटाबेस अनुरोधों से तेज़ है? क्या यह सर्वर पर निर्भर करता है? क्या यह जांचने का कोई तरीका है कि आपका प्रत्येक सर्वर कितने संभाल सकता है?

2) पृष्ठों में से एक फ़ाइल फ़ाइल नाम के लिए डेटाबेस की जांच करता है, फिर सर्वर को यह देखने के लिए जांचता है कि यह मौजूद है या नहीं, फिर तय करना है कि क्या प्रदर्शित करना है। यह मुझे लगता है कि एक कैश किए गए पृष्ठ दृश्य से लाभ होगा?

यदि इस विषय पर कोई अन्य जानकारी है तो आप मुझे अग्रेषित कर सकते हैं, इसकी सराहना की जाएगी।

धन्यवाद

Answer 1

यदि आप पढ़ने-भारी पहुंच (फ़ाइल नाम देख रहे हैं, आदि) कर रहे हैं तो आपको memcached से लाभ हो सकता है। आप स्मृति में डेटा "सबसे गर्म" (हाल ही में बनाया गया, हाल ही में उपयोग किया गया, आपके ऐप के आधार पर) स्टोर कर सकते हैं, फिर कैश याद होने पर केवल डीबी (और संभवतः फाइलें) से पूछताछ करें। मेमोरी एक्सेस डेटाबेस या फ़ाइलों की तुलना में बहुत तेज है।

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

लेकिन आखिरकार, यह डेटा पर निर्भर करता है।

Answer 2

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

Answer 3

यह इस बात पर निर्भर करता है कि डेटा कैसे संरचित किया गया है, कितना है और यह कितनी बार बदलता है।

यदि अपेक्षाकृत सरल संबंधों के साथ अपेक्षाकृत स्थिर डेटा की अपेक्षाकृत छोटी मात्रा मिलती है - तो फ्लैट फाइलें नौकरी के लिए सही उपकरण हैं।

डेटा के बीच कनेक्शन अधिक जटिल होने पर रिलेशनल डेटाबेस स्वयं ही आते हैं। बुनियादी 'लुकअप टेबल' के लिए वे थोड़ी अधिक हो सकती हैं।

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

Answer 4

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

यदि आपके पास प्रदर्शन समस्याएं हैं, तो आपको वास्तविक बाधाओं को देखने के लिए पृष्ठों को प्रोफ़ाइल करना चाहिए। यहां तक ​​कि जब आप मेरे जैसे होते हैं- अनुकूलित कोड के प्रशंसक, समीकरण में एक मजबूत/अधिक हार्डवेयर डालकर लंबे समय तक सस्ता है।

यदि आपको अभी भी कैश का उपयोग करने की आवश्यकता है, तो मौजूदा समाधान का उपयोग करने पर विचार करें, जैसे memcached।