2008-12-02 13 views
11

फ्लैट फ़ाइल डेटाबेस की योग्यता के बारे में सूचित विकल्पों की आवश्यकता है। मैं कस्टम ब्लॉग के लिए डेटा प्रबंधित करने के लिए एक फ्लैट फ़ाइल डेटाबेस योजना का उपयोग करने पर विचार कर रहा हूं। इसे लिनक्स ओएस संस्करण पर तैनात किया जाएगा और जावा में लिखा जाएगा।फ्लैट फ़ाइल डेटाबेस किसी भी अच्छे हैं?

लेख और टिप्पणियों दोनों को पढ़ने और लिखने के प्रदर्शन के संबंध में संभावित नकारात्मक या सकारात्मक क्या हैं?

क्या आरडीबीएमएस की बजाय एक फ्लैट फ़ाइल होने के कारण आलेख पुनर्प्राप्ति होगी क्योंकि इसे स्लैश-डॉट किया जाना था? (विशुद्ध सोच)

मैं आरडीबीएमएस का उपयोग करने के खिलाफ नहीं हूं, सिर्फ समुदाय को ऐसी सॉफ्टवेयर आर्किटेक्चर योजना की व्यवहार्यता पर उनकी राय पूछ रहा हूं।

फ़ॉलो अप: इस सवाल के मामले में मैं देखना होगा "फ्लैट फ़ाइल == फाइल सिस्टम आधारित" उदाहरण के लिए प्रत्येक ब्लॉग प्रविष्टि एवं इसके मेटाडाटा एक एकल फाइल में होगा। कई फ़ाइल फ़ोल्डरों की तारीख संरचना (ब्लॉगों \ testblog2 \ 2008 \ 12 \ 01) == 12/01/2008

+0

कृपया "फ्लैट फ़ाइल" और "फाइल सिस्टम-आधारित" डेटाबेस के बीच के अंतर की अपनी समझ को स्पष्ट करें। अन्यथा, प्रश्न का उत्तर नहीं दिया जा सकता है। –

+0

उत्कृष्ट बिंदु, इस प्रश्न के मामले में मुझे "फ्लैट फ़ाइल == फ़ाइल सिस्टम-आधारित" दिखाई देगा उदाहरण के लिए प्रत्येक ब्लॉग प्रविष्टि और इसके साथ मेटाडेटा एक फ़ाइल में होगी। फ़ाइल फ़ोल्डरों की तारीख संरचना द्वारा व्यवस्थित कई फ़ाइलों के लिए बनाना (ब्लॉग \ testblog2 \ 2008 \ 12 \ 01) == 12/01/2008 –

उत्तर

16

फ्लैट फ़ाइल डेटाबेस में उनकी जगह है और सही डोमेन के लिए काफी काम करने योग्य हैं।

अतीत के मेल सर्वर और एनएनटीपी सर्वर वास्तव में इस बात को सीमित करते हैं कि आप वास्तव में इन चीजों को कितनी दूर ले सकते हैं (जो वास्तव में काफी दूर है - फाइल सिस्टम में लाखों फाइलें और निर्देशिकाएं हो सकती हैं)।

फ्लैट फ़ाइल डीबी दो सबसे बड़ी कमजोरियां इंडेक्सिंग और परमाणु अद्यतन हैं, लेकिन यदि डोमेन उपयुक्त है तो ये कोई समस्या नहीं हो सकती है।

लेकिन उदाहरण के लिए, उचित लॉकिंग के साथ, आप कम से कम यूनिक्स पर मूल फ़ाइल सिस्टम कमांड का उपयोग करके "परमाणु" इंडेक्स अपडेट कर सकते हैं।

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

नई प्रविष्टियां बनाने के साथ ही।मूल रूप से फ़ाइल को एक temp फ़ाइल में पूरी तरह से लिखें, फिर उसका नाम बदलें या इसे अंतिम स्थान पर एमवी करें। तब आपके पास "डीबी" में "इंटरमीडिएट" फ़ाइल नहीं है। अन्यथा, आपके पास दौड़ की स्थिति हो सकती है (जैसे कि एक फ़ाइल को पढ़ने की प्रक्रिया जो अभी भी लिखी जा रही है, और लिखने की प्रक्रिया पूरी होने से पहले अंत तक हो सकती है - बदसूरत दौड़ की स्थिति)।

यदि आपकी प्राथमिक अनुक्रमणिका निर्देशिका नामों के साथ अच्छी तरह से काम करती है, तो यह ठीक काम करता है। आप एक हैशिंग योजना का उपयोग कर सकते हैं, उदाहरण के लिए, नई फ़ाइलों का पता लगाने के लिए निर्देशिकाएं और उपनिर्देशिकाएं बनाने के लिए।

फ़ाइल नाम और निर्देशिका संरचना का उपयोग कर फ़ाइल ढूंढना बहुत तेज है क्योंकि अधिकांश फाइल सिस्टम आज अपनी निर्देशिकाओं को सूचीबद्ध करते हैं।

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

लेकिन यह सब आपके अनुक्रमण और खोज तकनीकों पर निर्भर करता है।

प्रभावी रूप से, स्थैतिक सामग्री की सेवा करने वाले शेल्फ वेब सर्वर से एक स्टॉक एक बड़ा, फ्लैट फ़ाइल डेटाबेस है, और मॉडल बहुत अच्छा काम करता है।

आखिरकार, आपके पास नि: शुल्क यूनिक्स फ़ाइल सिस्टम स्तर के उपकरण हैं जो आपके निपटान में हैं, लेकिन उन सभी के पास फाइलों के साथ समस्याएं हैं (फ़ाइल में कुछ खोजने के लिए grep 1000000 बार फोर्किंग प्रदर्शन ट्रेडऑफ होगा - ओवरहेड बस जोड़ता है)।

यदि आपकी सभी फ़ाइलें एक ही फाइल सिस्टम पर हैं, तो हार्ड लिंक आपको अलग-अलग स्थानों (मूल रूप से अनुक्रमण के लिए) में रखने के संदर्भ में विकल्प भी प्रदान करते हैं (क्योंकि वे भी परमाणु हैं)।

उदाहरण के लिए, आपके पास "आज" निर्देशिका, एक "कल" ​​निर्देशिका, एक "जावा" निर्देशिका, और वास्तविक संदेश निर्देशिका हो सकती है।

तो, "आज" निर्देशिका, "जावा" निर्देशिका में एक पोस्ट जोड़ा जा सकता है (क्योंकि पोस्ट को "जावा" के साथ टैग किया गया है), और इसके अंतिम स्थान पर (कहें/लेख/2008/12 /01/my_java_post.txt)। फिर, मध्यरात्रि में, आप दो प्रक्रियाओं को चलाते हैं। सबसे पहले "आज" निर्देशिका में सभी फाइलें लेती हैं, यह सुनिश्चित करने के लिए उनकी निर्माण तिथि जांचती है कि वे "आज" नहीं हैं (क्योंकि प्रक्रिया में कई सेकंड लग सकते हैं और एक नई फ़ाइल छीन सकती है), और उन फ़ाइलों को " बिता कल"। इसके बाद, आप "कल" ​​निर्देशिका के लिए एक ही काम करते हैं, केवल तभी जब आप पुराने हैं तो आप उन्हें हटा दें।

इस बीच, फ़ाइल अभी भी "जावा" और ".../12/01" निर्देशिका में है। चूंकि आप यूनिक्स फ़ाइल सिस्टम और हार्ड लिंक का उपयोग कर रहे हैं, इसलिए "फ़ाइल" केवल एक बार मौजूद है, ये सभी फाइल के पॉइंटर्स हैं। उनमें से कोई भी "फाइल" नहीं है, वे सब एक जैसे हैं।

आप देख सकते हैं कि प्रत्येक व्यक्तिगत फ़ाइल चाल परमाणु है, थोक नहीं है। उदाहरण के लिए, "आज" स्क्रिप्ट चल रही है, जबकि "कल" ​​निर्देशिका में "कल" ​​और "दिन पहले" दोनों से फ़ाइलें हो सकती हैं क्योंकि "कल" ​​स्क्रिप्ट अभी तक नहीं चल पाई थी।

एक लेनदेन डीबी में, आप सब एक ही समय में ऐसा करेंगे।

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

+0

आपकी पोस्ट में अंतर्निहित समेकन के साथ SQLite जैसे कुछ का उपयोग करने की आवश्यकता को रेखांकित किया गया है - अगर मुझे ऐसा करने की ज़रूरत नहीं है तो मुझे उन मुद्दों से निपटने से नफरत होगी। –

13

(जवाब की नकल की और here से संशोधित)

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

यदि, हालांकि, आप बहुत से डेटाबेस परिवर्तन कर रहे हैं, तो transaction के अंदर उन्हें एक साथ करने के लिए सबसे अच्छा है। यह केवल एक बार फ़ाइल में परिवर्तन लिख देगा, क्योंकि हर बार एक परिवर्तन क्वेरी जारी की जाती है। यह नाटकीय रूप से कई परिवर्तन करने की गति को बढ़ाता है।

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

+0

मुझे समझ में आया है कि जावा लोग SQLite पर HSQLDB पसंद करते हैं (मुझे नहीं पता क्यों)। ओपी के लिए एक सूचक के रूप में। –

+0

ऐसा कहा जाता है कि एच 2 आजकल एचएसक्यूएलडीबी से बेहतर है। – MetroidFan2002

0

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

+0

नोट: मैं एक "फ्लैट फ़ाइल" के बारे में बात कर रहा हूं जो "फाइल सिस्टम-आधारित" डेटाबेस नहीं है। उत्तरार्द्ध एक छोटे पैमाने पर करने योग्य हो सकता है। – tvanfosson

+0

@tvanfosson: क्या कोई कारण है कि आप अपने उत्तर पर टिप्पणी क्यों कर रहे हैं? क्यों न सिर्फ अपना उत्तर अपडेट करें? इस टिप्पणी ने मुझे बिल्ली से उलझन में डाल दिया। –

3

यह डीएसब्लॉग के साथ एएसपीनेट के साथ किया गया है। यह फ़ाइल आधारित भंडारण का उपयोग करता है।

कुछ पुराने विवरण इस पुराने लिंक पर सूचीबद्ध हैं। http://www.hanselman.com/blog/UpcomingDasBlog19.aspx

तुम भी पर http://dasblog.info/Features.aspx

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

+0

यह फ़ाइल-आधारित (या अधिक सटीक, निर्देशिका-आधारित) है, न कि एक फ्लैट फ़ाइल (जैसे, कहें,/etc/passwd)। एक फ़ाइल-सिस्टम आधारित डेटाबेस, यानी, निर्देशिका पदानुक्रम द्वारा व्यवस्थित किया जा सकता है। मैं अभी भी एक डीबी पसंद करेंगे, हालांकि। – tvanfosson

2

मूल कोड में अपना स्वयं का इंजन लिखना एक सामान्य उद्देश्य डेटाबेस से बेहतर प्रदर्शन कर सकता है।

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

पहिया को फिर से शुरू करने से कुछ भी गलत नहीं है (आखिरकार, लिनक्स बस यही था), लेकिन अपनी अपेक्षाओं और समय प्रतिबद्धता को ध्यान में रखें।

+1

यह केवल सामान्य प्रयोजन डेटाबेस से बेहतर प्रदर्शन करता है क्योंकि यह सभी सुविधाओं को लागू नहीं करता है। एक बार जब आप अपने डीबीएस के समान फीचर स्तर पर अपना डेटाबेस प्राप्त कर लेते हैं, तो मुझे संदेह है कि आपका घर उगाए जाने वाला इंजन तेज होगा। – Kibbee

+0

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

0

वे उच्च-लेखन, कम-पढ़ने, अपडेट न किए गए डेटाबेस के लिए काफी अच्छा काम करते हैं, जहां नया डेटा जोड़ा जाता है।

वेब सर्वर और उनके चचेरे भाई लॉग फाइलों के लिए भारी भरोसा करते हैं।

डीबीएमएस सॉफ़्टवेयर के साथ-साथ उन्हें लॉग के लिए भी उपयोग करें।

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

0

फ्लैट फ़ाइल डेटाबेस संभव हैं लेकिन निम्नलिखित पर विचार करें।

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

तो क्यों पहले स्थान पर एक पूर्ण उड़ा डीबीएमएस का उपयोग नहीं करते?

यदि आप बस एक मुफ्त विकल्प (SQLite, MySQL, PostgresSQL, और इसी तरह से) के साथ जाते हैं, तो आप स्वयं को लिखने के साथ शामिल समय और धन बचाएंगे (और मैं कई बार फिर से लिखूंगा) ।

0

यदि आप पर्याप्त छोटे हैं तो यादृच्छिक पहुंच खोने के लिए आप फिएट फ़ाइल डेटाबेस का उपयोग कर सकते हैं। बहुत यादृच्छिक पहुंच के साथ बड़ी फ़ाइल बहुत धीमी होगी। और कोई जटिल सवाल नहीं है। कोई भी शामिल नहीं है, कोई योग नहीं है, आदि। आप फ्लैट फ़ाइल से पदानुक्रमित डेटा लाने की भी उम्मीद नहीं कर सकते हैं। जटिल संरचनाओं के लिए एक्सएमएल प्रारूप बहुत बेहतर है।

2

मैं इसका जवाब देने का उत्तर नहीं दे रहा हूं कि क्यों फ्लैट फ़ाइल डेटाबेस अच्छे या बुरे हैं, अन्य ने उस पर पर्याप्त काम किया है।

हालांकि, कुछ SQLite जो यह काम ठीक है करता है पर इशारा करते हुए किया गया है। चूंकि आप जावा का उपयोग कर रहे हैं, तो आपका सबसे अच्छा विकल्प HSQLDB का उपयोग करना होगा, जो SQLite के समान ही है, लेकिन जावा में लागू किया गया है और आपके एप्लिकेशन में एम्बेड किया गया है।

2

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

-1

चेक इस बाहर http://jsondb.io एक opensource जावा आधारित डेटाबेस के लिए आप क्या देख रहे हैं के सबसे है। डेटा को फ्लैट। जेसन फाइलों, मल्टीथ्रेडिंग सपोर्ट, एन्क्रिप्शन सपोर्ट, ओआरएम सपोर्ट, परमाणु समर्थन, XPATH आधारित उन्नत क्वेरी समर्थन के रूप में सहेजता है।

अस्वीकरण: मैंने यह डेटाबेस बनाया है।