यदि मेरे पास फ़ोल्डर्स और फाइलों का एक स्थिर डेटाबेस है, तो SQL सर्वर प्रकार डेटाबेस से एक्सेस और हेरफेर तेज होगा, क्योंकि इसका उपयोग सीजीआई स्क्रिप्ट में किया जाएगा?क्या यह फ़ाइलों या डेटाबेस सर्वर से डेटा तक पहुंचने के लिए तेज़ है?
फ़ाइलों और फ़ोल्डरों के साथ काम करते समय, बेहतर प्रदर्शन के लिए चाल क्या हैं?
मैं इसे जोड़ दूंगा भीड़ पर निर्भर करता है।
यह एक ऐसा प्रश्न है जिसका कोई सामान्य जवाब नहीं है लेकिन वह स्थिति में भारी निर्भर है। मैंने हाल ही में एक SQL डेटाबेस से कुछ डेटा को एक फ्लैट फ़ाइल सिस्टम में ले जाया है क्योंकि डीबी के ओवरहेड, कुछ डीबी कनेक्शन विश्वसनीयता मुद्दों के साथ संयुक्त, फ्लैट फ़ाइलों का उपयोग करके बेहतर विकल्प बनाते हैं।
कुछ सवाल मैं अपने आप को पूछना होगा जब विकल्प बन में शामिल हैं:
मैं डेटा कैसे लेने वाली हूँ? उदाहरण के लिए क्या मैं बस शुरुआत से अंत पंक्तियों में दर्ज क्रम में पढ़ रहा हूं? या मैं उन पंक्तियों की खोज करूँगा जो एकाधिक मानदंडों से मेल खाते हैं?
मैं एक प्रोग्राम निष्पादन के दौरान कितनी बार डेटा तक पहुंचूँगा? क्या मैं एक बार लेखक के रूप में सलिंगर के साथ सभी किताबें प्राप्त करने के लिए जाऊंगा या क्या मैं कई अलग-अलग लेखकों को प्राप्त करने के लिए कई बार जाऊंगा? क्या मैं कई अलग-अलग मानदंडों के लिए एक से अधिक बार जाऊंगा?
मैं डेटा कैसे जोड़ूं? क्या मैं सिर्फ अंत तक एक पंक्ति जोड़ सकता हूं और यह मेरे पुनर्प्राप्ति के लिए सही है या इसे सहारा लेने की आवश्यकता होगी?
कोड छह महीने में कितना तार्किक होगा? मैं इस पर जोर देता हूं क्योंकि मुझे लगता है कि यह अक्सर चीजों को डिजाइन करने में भूल जाता है (केवल कोड नहीं, यह शौक घोड़ा वास्तव में मेरे दिनों से नौसेना मैकेनिक शापित यांत्रिक इंजीनियरों के रूप में होता है)। छह महीने में जब मुझे अपना कोड बनाए रखना होगा (या आप किसी अन्य प्रोजेक्ट के काम करने के बाद करते हैं) डेटा संग्रह और पुनर्प्राप्त करने का तरीका अधिक समझ में आता है। यदि फ्लैट फाइलों से डीबी परिणामों में 1% दक्षता में सुधार होता है, तो कोड को अपडेट करने के दौरान चीजों को समझने के एक सप्ताह में आप वास्तव में चीजों में सुधार कर चुके हैं।
क्या आप अपने प्रश्नों के अनुसार उपयोग करने वाले टूल को जोड़ सकते हैं? ऐसा लगता है कि पैटर्न यह है: यदि प्रश्न का पहला भाग हां है तो फ़ाइल का उपयोग करें, यदि यह दूसरा डीबी का उपयोग करता है लेकिन मुझे यकीन नहीं है। – mbigras
आपकी जानकारी क्या है और आपके पहुंच पैटर्न और पैमाने क्या हैं इस पर निर्भर करता है। एक संबंधपरक डेटाबेस के दो सबसे बड़े लाभ हैं:
कैशिंग। जब तक आप बहुत चालाक न हों, आप एक कैश को डीबी सर्वर
अनुकूलक के रूप में उतना अच्छा नहीं लिख सकते हैं।
हालांकि, कुछ विशेष अनुप्रयोगों के लिए, इन 2 लाभ की न तो स्पष्ट नजर फ़ाइलों + फ़ोल्डरों डेटा संग्रह की तुलना में - इसलिए जवाब एक शानदार "निर्भर करता है।"
फ़ाइलें/फ़ोल्डर के रूप में, चाल हैं:
मुझे आपके द्वारा लिखे गए बहुत से असहमत हैं: 1) डीबी सर्वर पर कैशिंग सामान्य होना चाहिए। यदि आप अपना खुद का विशिष्ट आवेदन ज्ञान लिखते हैं - तो आप इसे हाथों में गिरावट करने में सक्षम होना चाहिए। 2) अनुकूलक - फिर से आशावादी को सामान्य होना चाहिए; विशिष्ट अनुप्रयोग ज्ञान के साथ आप महत्वपूर्ण रूप से अधिक कुशल पहुंच पथों को कोड कर सकते हैं, आप सामान्य आरडीबीएमएस इंडेक्सिंग विकल्पों के भीतर उपलब्ध संरचनाओं का भी उपयोग नहीं कर सकते हैं। 3) बड़ी निर्देशिका केवल धीमी होती है अगर आपको फ़ाइलों के लिए 'खोज' करना पड़ता है; अगर आपके पास फ़ाइल के लिए पूर्ण पथ है, तो आपको "एक बड़ी निर्देशिका की सामग्री को पढ़ने" की आवश्यकता नहीं होगी। –
@Sinan - ठीक है, मुझे कॉफी झटका की जरूरत है रंग। डीबी बनाम फाइलों तक आप "सीजीआई-विशिष्ट" मुद्दों से क्या कहते हैं? – DVK
@ क्रेग - मुझे नहीं पता कि उनके उपयोग पैटर्न क्या हैं। यहां तक कि उसका डेटा क्या है। तो आपके अंक मान्य हो सकते हैं या नहीं भी हो सकते हैं - यह निर्भर करता है। लेकिन क्या आपकी कस्टम फ़ाइल संरचना डिस्क के तेज़ क्षेत्रों में सबसे अधिक उपयोग किए जाने वाले डेटा को रखने के बारे में जानती है? क्या आप अच्छे कैश लिखने में विशेषज्ञ हैं?यही कारण है कि मैंने कहा "यह निर्भर करता है" - अपने ऐप के ब्योरे को जानने के बिना, मैं एक तरह से न्याय करने के लिए तैयार नहीं हूं कि दूसरी जरूरतों के लिए एक कस्टम फ़ाइल आधारित संरचना लिखना कितना आसान है जो डीबी – DVK
यह डेटा की प्रोफाइल पर निर्भर करता है और आप इसका उपयोग करने के लिए किस तर्क का उपयोग कर रहे हैं। यदि आपको बस नामित नोड्स को सहेजने और लाने की आवश्यकता है तो एक फाइल सिस्टम-आधारित डेटाबेस तेज और अधिक कुशल हो सकता है। (आप उस उद्देश्य के लिए बर्कले डीबी पर भी देख सकते हैं।) यदि आपको इंडेक्स-आधारित खोज करने की ज़रूरत है, और विशेष रूप से यदि आपको कुंजी के आधार पर डेटा के विभिन्न सेट में शामिल होने की आवश्यकता है, तो एक SQL डेटाबेस आपकी सबसे अच्छी शर्त है।
मैं आपके आवेदन के लिए जो भी समाधान सबसे प्राकृतिक लगता है, उसके साथ जाऊंगा।
सामान्य नियम के रूप में, डेटाबेस फ़ाइलों की तुलना में धीमे होते हैं।
आप अपनी फ़ाइलों के अनुक्रमण की आवश्यकता है, अनुकूलित अनुक्रमण ढांचे पर एक हार्ड-कोडेड पहुंच पथ हमेशा संभावित होने के लिए यदि आप इसे सही ढंग से कर होगा तेजी से।
लेकिन 'प्रदर्शन' नहीं लक्ष्य जब एक फ़ाइल आधारित समाधान पर एक डेटाबेस का चयन है।
आप अपने आप से पूछना चाहिए आपके सिस्टम लाभ है कि एक डेटाबेस प्रदान करेगा के किसी भी जरूरत है या नहीं। यदि ऐसा है, तो छोटे प्रदर्शन ओवरहेड काफी स्वीकार्य है।
तो:
असल में, प्रश्न अधिक विकसित करना आसान होगा। दोनों के बीच प्रदर्शन अंतर देव समय बर्बाद करने लायक नहीं है।
मैं जोड़ता हूं कि प्रदर्शन लाभ केवल तभी मौजूद है यदि आप जानते हैं कि आप क्या कर रहे हैं। एक अच्छी और तेज़ अनुक्रमण योजना बनाना आसान नहीं है। डेटा जेनेरिक होने के बावजूद डेटाबेस में उनके एल्गोरिदम को ठीक करने के लिए कई सालों हैं। अधिकांश लोग जिन्हें मैं जानता हूं कि फ्लैट फाइलों के साथ डेटाबेस को हरा करने का प्रयास करने में विफल रहता है। लेकिन कुछ ऐसे हैं जो दुर्लभ मामले के लिए सफल होते हैं जिन्हें आपको इसकी आवश्यकता होती है। – mpeters
जैसा कि अन्य ने बताया है: यह निर्भर करता है!
यदि आप वास्तव में यह पता लगाने की आवश्यकता है कि आपके उद्देश्यों के लिए कौन सा प्रदर्शन करने वाला है, तो आप प्रत्येक प्रारूप में स्टोर करने के लिए कुछ नमूना डेटा जेनरेट करना चाहते हैं और फिर कुछ मानक चला सकते हैं। Benchmark.pm मॉड्यूल पर्ल के साथ आता है, और यह काफी सरल कुछ इस तरह के साथ एक साइड-बाई-साइड तुलना करने के लिए बनाता है:
use Benchmark qw(:all) ;
my $count = 1000; # Some large-ish number of trials is recommended.
cmpthese($count, {
'File System' => sub { ...your filesystem code... },
'Database' => sub { ...your database code... }
});
आप perldoc Benchmark टाइप अधिक पूर्ण प्रलेखन प्राप्त करने के लिए कर सकते हैं।
जैसा कि अन्य ने कहा है, यह पर निर्भर करता है: डेटा के आकार और प्रकृति और संचालन पर आप इसे चलाने की योजना बना रहे हैं।
विशेष रूप से CGI स्क्रिप्ट के लिए, आप प्रत्येक पृष्ठ दृश्य पर डेटाबेस सर्वर से कनेक्ट करने के लिए प्रदर्शन हिट करने जा रहे हैं। हालांकि यदि आप एक निष्पक्ष फ़ाइल-आधारित दृष्टिकोण बनाते हैं, तो आप आसानी से खराब प्रदर्शन समस्याओं को बना सकते हैं ;-)
साथ ही साथ बर्कले डीबी फ़ाइल समाधान आप SQLite का उपयोग करने पर भी विचार कर सकते हैं। यह स्थानीय फ़ाइल में संग्रहीत डेटाबेस में एक SQL इंटरफ़ेस बनाता है। आप इसे डीबीआई और एसक्यूएल के साथ एक्सेस कर सकते हैं लेकिन कोई सर्वर, कॉन्फ़िगरेशन या नेटवर्क प्रोटोकॉल नहीं है। यदि भविष्य में डेटाबेस सर्वर आवश्यक है तो यह आसान माइग्रेशन की अनुमति दे सकता है (उदाहरण: यदि आप एकाधिक फ्रंट-एंड सर्वर रखने का निर्णय लेते हैं, लेकिन राज्य को साझा करने की आवश्यकता है)।
कोई जानकारी जानने के बिना, मैं SQL12/DBI समाधान का उपयोग करके का सुझाव देता हूं और फिर प्रदर्शन का उपयोग करता हूं। यह एक उचित सरल स्टार्टअप और सभ्य प्रदर्शन के साथ लचीलापन देगा।
आप जो भी कर रहे हैं उसके आधार पर फ़ाइलों को तेज़ी से एक्सेस करने के लिए, एक mmap बहुत आसान हो सकता है। मैंने इस बारे में Effective Perl ब्लॉग में Memory-map files instead of slurping them के रूप में लिखा है।
हालांकि, मुझे उम्मीद है कि डेटाबेस सर्वर बहुत तेज होगा। यह कहना मुश्किल है कि आपके लिए क्या तेज़ होगा जब हमें पता नहीं है कि आप क्या कर रहे हैं, आपको किस प्रकार का डेटा एक्सेस करने की आवश्यकता है, और इसी तरह।
मेरे थोड़ा सा अनुभव से, सर्वर-आधारित डेटाबेस (यहां तक कि स्थानीय मशीन पर भी सेवा दी गई) स्थानीय फाइल सिस्टम की तुलना में बहुत धीमी थ्रूपुट होती है। हालांकि, यह कुछ चीजों पर निर्भर करता है, जिनमें से एक एसिम्प्टोटिक जटिलता है। किसी आइटम को देखने के लिए किसी इंडेक्स के साथ डेटाबेस का उपयोग करने के खिलाफ फ़ाइलों की एक बड़ी सूची स्कैनिंग की तुलना करना, डेटाबेस जीतता है।
मेरा थोड़ा सा अनुभव PostgreSQL के साथ है। मेरे पास तीन मिलियन पंक्तियों वाली एक टेबल थी, और मैं केवल 8,000 रिकॉर्ड अपडेट करने गया। इसमें 8 सेकंड लग गए।
उद्धरण के लिए "समयपूर्व अनुकूलन सभी बुराइयों की जड़ है।", मैं इसे नमक के अनाज के साथ ले जाऊंगा। यदि आप डेटाबेस का उपयोग करके अपना आवेदन लिखते हैं, तो इसे धीमा होने के लिए ढूंढें, इसमें फाइल सिस्टम-आधारित दृष्टिकोण या कुछ और (जैसे SQLite) पर स्विच करने में काफी समय लग सकता है। मैं कहूंगा कि आपका सबसे अच्छा शर्त है कि आप अपने वर्कलोड का एक बहुत ही सरल प्रोटोटाइप बनाएं, और दोनों दृष्टिकोणों के साथ इसका परीक्षण करें। मेरा मानना है कि यह जानना महत्वपूर्ण है कि इस मामले में कौन सा तेज़ है।
साइट संरचना के अनुकूल होने पर छवियों की बात आती है जब डीबी की बजाय फ़ाइलों का उपयोग करना बहुत उपयोगी होता है। अपने मिलान करने वाले डेटा का प्रतिनिधित्व करने वाले फ़ोल्डर बनाएं और अंदर छवियां रखें। उदाहरण के लिए आपके पास एक लेख साइट है, आप अपने लेख डीबी में स्टोर करते हैं। आपको डीबी पर अपना इमेज पथ नहीं रखना है, अपनी प्राथमिक कुंजी के साथ नाम फ़ोल्डर्स जैसे 1,2,3 .. और छवियों को अंदर रखें। ई-किताबें, संगीत फ़ाइलें, वीडियो, इस दृष्टिकोण का उपयोग सभी मीडिया फ़ाइलों में किया जा सकता है। यदि आप कुछ खोज नहीं करेंगे तो एक्सएमएल फाइलों के साथ वही तर्क काम करता है।
आप जानकारी के साथ क्या करने की योजना बना रहे हैं? –