आपके आवेदन में प्रत्येक पृष्ठ दृश्य पर कुछ डेटा रिकॉर्ड करने की आवश्यकता होने पर सबसे कुशल समाधान क्या होता है - क्या आपको फ़ाइल में लिखना चाहिए या डेटाबेस में लिखना चाहिए?प्रत्येक पृष्ठ दृश्य पर अधिक महंगा क्या है - डेटाबेस लेखन या फ़ाइल लेखन?
या शायद न तो - शायद आपको स्मृति या फ़ाइल में डेटा कैश करना चाहिए और कभी-कभी इसे डेटाबेस में लिखना चाहिए (या फ़ाइल सिस्टम यदि आप मेमोरी कैश का उपयोग करते हैं) कभी-कभी?
यदि यह पूरी तरह से बिना किसी लुकअप वाले डेटा की एक छोटी राशि रिकॉर्ड कर रहा है, तो सीधे फ़ाइल I/O लगभग अधिक कुशल होने की गारंटी है। हालांकि आप एक डीबीएमएस के सभी फायदे खो रहे हैं - इंडेक्सिंग, ट्रांजैक्शनल अखंडता (वास्तव में, सामान्य रूप से एसीआईडी), समवर्ती एक्सेस, आदि ..
ऐसा लगता है जैसे आप सरल लॉगिंग के लिए कितनी मात्रा में बात कर रहे हैं। यदि ऐसा है, और आपको परिणामी डेटा पर लगातार जटिल प्रश्नों की आवश्यकता नहीं है, तो प्रदर्शन शायद एक गंभीर समस्या है, तो आप शायद सीधे फ़ाइल I/O के साथ बेहतर हो। हालांकि, समवर्ती-लिखने के मुद्दों से सावधान रहें।
यदि आरडीबीएमएस के गुण वांछनीय हैं, तो आप SQLite का उपयोग करने के बारे में सोच सकते हैं, जो कि सरल लाभ के लिए आपको कुछ लाभों की लागत पर कम ओवरहेड वाले अधिकांश आरडीबीएमएस की तुलना में बेहतर प्रदर्शन मिलेगा (अत्यधिक समवर्ती पहुंच और उपलब्धता नेटवर्क पर अन्य मशीनों में से कुछ "biggies" हैं)। हालांकि, सामान्य मामले में यह अभी भी सीधे फ़ाइल I/O के रूप में तेज़ नहीं होगा। यदि आप एक काउंटर incrementing रहे हैं, बल्कि पृष्ठ दृश्य के बारे डेटा प्रवेश करने से:
आपका यह पृष्ठ दृश्य ट्रैकिंग के लिए किया जा रहा है की बाद में उल्लेख मुझे पूछने के लिए क्या कारण हैं? हां, तो मैं दृढ़ता से SQLite की तरह कुछ के साथ जा रहा सुझाव है कि चाहते हैं तो (अद्यतन tbl सेट काउंटर = काउंटर + 1 की तरह कुछ कर रही है)। आप वास्तव में हाथ से ऐसा करने में शामिल समय मुद्दों में पाने के लिए नहीं करना चाहते हैं - अगर आप इसे सही नहीं करते हैं, आप एक साथ अभिगम पर गिना जाता है खोने शुरू करेंगे (ए पढ़ता है "100", बी पढ़ता है "100" , एक लिखते हैं, "101", बी लिखते हैं, "101", बी 102 लिखा जाना चाहिए था, लेकिन वह जानते हुए भी) का कोई रास्ता नहीं है।
यह निर्भर करता है।
एंड्स यह वास्तव में करता है: यह डीबीएमएस और/या आपके द्वारा उपयोग किए जाने वाले ओएस + फाइल सिस्टम पर निर्भर करता है। दूसरे शब्दों में: आपका लाभ भिन्न होता है।
यदि आप डेटा को कहीं भी जोड़ते हैं तो कहीं भी आधुनिक डीबीएमएस/ओएस + फाइल सिस्टम को इसे समान रूप से अच्छी तरह से और तेज़ तरीके से संभालना चाहिए। जब आप डेटा बदलना चाहते हैं तो समस्याएं उत्पन्न होती हैं।
कैशिंग - यह भी निर्भर करता है कि आप किस प्रकार की कैशिंग ग्रैन्युलरिटी का जोखिम उठा सकते हैं (प्रत्येक चरण में क्रैश-सुरक्षित बनाम संभावित बचत की आवश्यकता है)।
यह डेटा सुरक्षा के लिए आपकी आवश्यकताओं पर निर्भर करता है। यदि आप किसी दुर्घटना के मामले में कुछ डेटा खोना चाहते हैं तो डेटा को स्मृति में रखते हुए और समय-समय पर इसे लगातार स्टोर में लिखना निश्चित रूप से जाने का सबसे प्रभावी तरीका है।
संपादित करें: आपने पृष्ठदृश्यों का उल्लेख किया है। उस स्थिति में मैं काउंटर को स्मृति में रखूंगा और समय-समय पर डेटाबेस तालिका अपडेट करूंगा (जैसे हर मिनट या तो)।
डेटाबेस साधते सबसे अधिक संभावना एक फाइल करने के लिए लिखने की तुलना में अधिक महंगा होने जा रहा है।
यदि प्रति पृष्ठ आपके पृष्ठदृश्य उच्च हैं, और यदि डेटा को तुरंत डेटाबेस में उपलब्ध होने की आवश्यकता नहीं है, तो फ़ाइल में लिखना और समय-समय पर डीबी में डेटा लोड करना एक अधिक इष्टतम समाधान होगा।
हालांकि यह सब उस डेटा की प्रकृति पर निर्भर करता है जिसे आप प्रति पृष्ठ दृश्य रिकॉर्ड कर रहे हैं और यह जो भी व्यवसाय कार्य करता है, उसके लिए कितना महत्वपूर्ण है।
संकल्पनात्मक रूप से, डेटाबेस को लिखना हमेशा फ़ाइल में लिखने से धीमा होता है। डेटाबेस को डेटा प्राप्त करने के लिए संचार के अतिरिक्त ओवरहेड के साथ, डेटाबेस को भी फ़ाइल में लिखना है, इसलिए यह इसे फ़ाइल में लिख सकता है। इसलिए, यह धीमा होना चाहिए।
उस ने कहा, डेटाबेस डिस्क I/O बहुत अच्छी तरह से करते हैं, शायद आपके से बेहतर होगा। अगर आपको पता चलता है कि एक साधारण फ़ाइल लॉगर डेटाबेस को लिखने से धीमा है तो आश्चर्यचकित न हों। डेटाबेस में बहुत सारे I/O अनुकूलन हैं, और इसमें कुछ चाल उपलब्ध हैं जो आप नहीं कर सकते (आपके वेब लैनागुएज और पर्यावरण के आधार पर)।
समय के साथ उत्तर में परिवर्तन होने पर आश्चर्यचकित न हों। जब आपकी साइट छोटी होती है, तो डेटाबेस में लॉगिंग बहुत तेज होती है। जैसे-जैसे आपकी साइट बढ़ती है, लॉगिंग टेबल एक बड़ा दर्द बन सकता है: यह बहुत सी डिस्क स्पेस का उपयोग करता है, बैकअप हमेशा के लिए लेता है, और जब आप इसे पूछने का प्रयास करते हैं तो सभी डिस्क I/O का उपभोग करता है। यही कारण है कि आपको अपने दोनों तरीकों को बेंचमार्क करना चाहिए। फिर आप भविष्य में फिर से परीक्षण कर सकते हैं, जब हालात बदलते हैं।
redis अपने सामान
इस तरह की यह सिर्फ ट्रैकिंग पृष्ठ दृश्य वास्तव में के लिए है के लिए बनाया गया है जैसे एक संकर समाधान का उपयोग करें। यह महत्वपूर्ण जानकारी जैसे ऑर्डर जानकारी नहीं है। –