अपने डेटा को डिस्क पर सहेजने के बजाय डेटाबेस का उपयोग क्यों करें?

Question

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

केवल डेटा को डिस्क पर सहेजने के बजाय एक डेटाबेस का उपयोग क्यों करना चाहिए?

Comments

यदि आपके एप्लिकेशन में आपके डेटा के रिश्तों को प्रबंधित करना वास्तव में डेटाबेस में करने से अधिक तेज है (जो मुझे विश्वास करना बहुत कठिन लगता है) तो आपको SQL और डेटाबेस के सामान्यीकरण पर पढ़ना होगा। आप जो अनुभव कर रहे हैं, वह शायद एक भयानक रूप से डिज़ाइन किए गए डेटाबेस का साइड-इफ़ेक्ट है।

— यानिस

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

— यानिस

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

— btilly

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

— बेनेडिक्ट

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

— jernernerny

Answer 1

1. आप एक डेटाबेस में डेटा क्वेरी कर सकते हैं (यह सवाल पूछें)।
2. आप अपेक्षाकृत तेज़ी से डेटाबेस से डेटा देख सकते हैं।
3. आप JOIN का उपयोग करके डेटा को दो अलग-अलग तालिकाओं से एक साथ जोड़ सकते हैं।
4. आप डेटाबेस में डेटा से सार्थक रिपोर्ट बना सकते हैं।
5. आपके डेटा में एक अंतर्निहित संरचना है।
6. किसी दिए गए प्रकार की जानकारी हमेशा केवल एक बार संग्रहीत की जाती है।
7. डेटाबेस ACID हैं ।
8. डेटाबेस दोष-सहिष्णु हैं।
9. डेटाबेस बहुत बड़े डेटा सेट को संभाल सकता है।
10. डेटाबेस समवर्ती हैं; कई उपयोगकर्ता डेटा को दूषित किए बिना एक ही समय में उनका उपयोग कर सकते हैं।
11. डेटाबेस पैमाने पर अच्छी तरह से।

संक्षेप में, आप कई वर्षों में विकसित कई स्मार्ट लोगों की एक विस्तृत श्रृंखला से अच्छी तरह से ज्ञात, सिद्ध प्रौद्योगिकियों से लाभान्वित होते हैं।

यदि आप चिंतित हैं कि एक डेटाबेस ओवरकिल है, तो SQLite देखें।

Comments

6. सामान्यीकरण, 7. लिंक देखें, 8. गलती-सहिष्णुता पर पढ़ें। ओह, और इससे पहले कि आप NoSQL सनक में चूसा हो, SQL डेटाबेस के बारे में जानें; उन्हें अपनी शर्तों पर जानें। तुम समझ जाअोगे। यदि आप केवल साधारण कॉन्फ़िगरेशन डेटा के बारे में बात कर रहे हैं, तो JSON आपकी ज़रूरत का सब कुछ हो सकता है। लेकिन वहाँ प्रोग्राम सेटिंग्स के अलावा कई अन्य प्रकार के डेटा हैं।

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

@ डॉककट यह आवश्यक नहीं है, कुछ भी नहीं है। यदि आपका दृष्टिकोण आपके लिए काम करता है, तो हर तरह से इसके लिए जाएं। मुझे हालांकि उल्लेख करना चाहिए कि अधिकांश आधे सभ्य rdbms मेमोरी आधारित स्टोरेज का समर्थन करते हैं, आप अपने ऐप में उठने वाली हर चीज़ को लोड कर सकते हैं जब आपका ऐप उठता है (जैसा कि आप पहले से ही करते हैं), और उन्हें क्वेरी करें जैसा कि आप एक विशिष्ट डेटाबेस (सभी लाभों को रखते हुए रॉबर्ट का उल्लेख करते हैं) )।

— यानिस

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

— रॉबर्ट हार्वे

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

— डैनियल बी

Answer 2

जब भी मैं रॉबर्ट की हर बात से सहमत होता हूं, तो उसने आपको यह नहीं बताया कि जब आपको डेटा को डिस्क पर सहेजने के लिए डेटाबेस का उपयोग करना चाहिए।

तो इसके अलावा रॉबर्ट ने स्केलेबिलिटी, विश्वसनीयता, गलती सहिष्णुता आदि के बारे में क्या कहा।

RDBMS का उपयोग कब करें, इस पर विचार करने के लिए यहां कुछ बिंदु दिए गए हैं:

• आपके पास संबंधपरक डेटा है, यानी आपके पास एक ग्राहक है जो आपके उत्पादों को खरीदता है और उन उत्पादों में एक आपूर्तिकर्ता और निर्माता होता है
• आपके पास बड़ी मात्रा में डेटा है और आपको प्रासंगिक जानकारी का शीघ्र पता लगाने में सक्षम होना चाहिए
• आपको पहचाने गए पिछले मुद्दों के बारे में चिंता करने की आवश्यकता है: स्केलेबिलिटी, विश्वसनीयता, एसीआईडी ​​अनुपालन
• आपको व्यावसायिक समस्याओं को हल करने के लिए रिपोर्टिंग या खुफिया उपकरणों का उपयोग करने की आवश्यकता है

जब एक NoSQL का उपयोग करने के लिए के रूप में

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

अंत में, फ़ाइलों का उपयोग कब करें

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

Comments

+1, मुझे लगता है कि इसकी महत्वपूर्ण बात यह है कि आपने कई बार बताया कि फाइलें वास्तव में भंडारण के लिए उपयुक्त हैं।

— ग्रैंडमास्टरबी

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

— गोरान जोविक

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

— सैम

@GoranJovic कभी-कभी समझ में आता है। एक निर्देशिका में 10,000+ चित्र स्टोर करें और कुछ फाइल सिस्टम एक पड़ाव में पीसेंगे - एक डीबी एक मैनुअल उप-निर्देशिका अभियान योजना की तुलना में आसान हो सकता है।

— मार्टिन बेकेट

@MartinBeckett: पिछले एक दशक की फाइलसिस्टम क्या करती है?

— ईमोन नेरबोन

Answer 3

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

जैसे ही आप अधिक जटिल होते हैं, आप वास्तव में एक डेटाबेस बना रहे हैं। जो भी आप इसे कॉल करना चाहते हैं, एक डेटाबेस डिस्क पर संग्रहीत रिकॉर्ड का एक सेट है। चाहे आप फ़ाइल बना रहे हों, या MySQL , SQLite या जो भी फ़ाइल (s) बना रहे हैं, वे दोनों डेटाबेस हैं।

आप जो याद कर रहे हैं वह जटिल कार्यक्षमता है जिसे डेटाबेस सिस्टम में बनाया गया है ताकि उनका उपयोग करना आसान हो सके।

मुख्य बात जो मन को झरती है वह अनुक्रमण है। ठीक है, तो आप क्रमबद्ध सरणी में 10 या 20 या यहां तक ​​कि 100 या 1000 रिकॉर्ड स्टोर कर सकते हैं, या एक JSON स्ट्रिंग और इसे अपनी फ़ाइल से बाहर निकाल सकते हैं और इसे अपेक्षाकृत जल्दी से मिटा सकते हैं ।

अब, कल्पना कीजिए कि आपके पास 10,000, 100,000 या 1,000,000 रिकॉर्ड हैं। जब कोई व्यक्ति आपको लॉग इन करने की कोशिश करता है, तो आपको एक फाइल खोलने की जरूरत होती है, जो अब कई सौ मेगाबाइट की बड़ी है, इसे अपने प्रोग्राम में मेमोरी में लोड करें, सूचना के समान आकार के सरणी को बाहर निकालें और फिर 100 के हजारों रिकॉर्डों को पुन: टाइप करें वह एक रिकॉर्ड ढूंढें जिसे आप एक्सेस करना चाहते हैं।

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

अनुक्रमण से संबंधित एक और बात जानकारी का हस्तांतरण है। जैसा कि मैंने ऊपर कहा है, जब आपको सैकड़ों या हजारों मेगाबाइट की फाइलें मिली हैं, तो आपको उस जानकारी को मेमोरी में लोड करना होगा, इसे मैन्युअल रूप से पुनरावृत्त करें (संभवतः उसी थ्रेड पर) और फिर अपने डेटा में हेरफेर करें।

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

Comments

1. कृपया कभी भी अपने सभी उपयोगकर्ता की जानकारी क्लाइंट साइड कोड में लोड न करें! (मुझे यकीन है कि यह केवल एक उदाहरण था) 2. लोड हो रहा है कि एक फ़ाइल से पहली बार 100 एमबी की बड़ी में कुछ समय लगेगा। 3. आप उदाहरण के लिए सही हैं, हालांकि यह मान लेते हैं कि आप केवल उपयोगकर्ता नाम से ही खोज करने वाले हैं। यदि आप किसी उपयोगकर्ता के बारे में अधिक डेटा संग्रहीत करना चाहते हैं तो क्या होता है? जैसे उम्र। अब आप उन सभी उपयोगकर्ताओं को खोजना चाहते हैं जो 20-30 की उम्र के बीच के हैं। या और भी सरल, एक उपयोगकर्ता को उस पते से ढूंढें जब आपका जोंस इस तरह दिखता है: {लॉगिन: {पास: पास, Add1: "123 sasd", शहर: "जहां भी"}}।

— थॉमस क्लेसन

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

— थॉमस क्लेसन

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

— MaiaVictor

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

— सम्राट ओरियोनी

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

— सिल्वरबैकनेट

Answer 4

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

लेकिन यहां तक ​​कि एक साधारण सूची के साथ जो आप लोड करते हैं, स्मृति में पकड़ते हैं, फिर जब आवश्यक हो, तब लिखें, कई समस्याओं से पीड़ित हो सकते हैं:

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

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

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

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

Answer 5

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

एक उत्तर में प्रश्नों का उल्लेख है। "एसक्यूएल डेटाबेस को एक प्रश्न पूछना" एक प्रश्न की जटिलता के साथ अच्छी तरह से तराजू। जैसा कि विकास के दौरान कोड विकसित होता है, "सभी को लाने" जैसे सरल प्रश्न आसानी से "सभी को प्राप्त कर सकते हैं, जहां प्रॉपर्टी 1 इस मूल्य के बराबर होती है और फिर प्रॉपर्टी 2 के आधार पर छाँटती है", ऐसे प्रश्न के लिए डेटा संरचना को अनुकूलित करने के लिए प्रोग्रामर की चिंता किए बिना। अधिकांश प्रश्नों के प्रदर्शन को एक निश्चित संपत्ति के लिए सूचकांक बनाकर गति दी जा सकती है।

अन्य लाभ संबंध हैं। प्रश्नों के साथ यह विभिन्न डेटा सेटों से डेटा को फिर से संदर्भित करने के लिए क्लीनर है, फिर नेस्टेड लूप होते हैं। उदाहरण के लिए, उन उपयोगकर्ताओं से सभी फ़ोरम पोस्ट की खोज करना, जिनकी सिस्टम में 3 पोस्ट कम हैं, जहाँ उपयोगकर्ता और पोस्ट अलग-अलग डेटा सेट (या DB टेबल या JSON ऑब्जेक्ट) हैं, जिन्हें पठनीयता का त्याग किए बिना एक ही क्वेरी के साथ किया जा सकता है।

सभी में, SQL डेटाबेस बेहतर हैं तो सादे सरणियाँ यदि डेटा की मात्रा बड़ी हो सकती है (1000 से अधिक ऑब्जेक्ट्स कह सकते हैं), गैर-तुच्छ में डेटा एक्सेस और कोड एक्सेस के विभिन्न भागों में डेटा का अलग-अलग सबसेट होता है।

Comments

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

— ईमोन नेरबोन

Answer 6

TLDR

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

आप किसी भी दिशा में जाने के विकल्पों के साथ, एक निरंतरता पर बैठे हैं।

लंबी अवधि में, आप संभावना (लगभग, लेकिन 100% निश्चित रूप से नहीं) अपने आप को मुसीबत में पाते हैं, और मौजूदा डेटा स्टोर समाधान का उपयोग करने के लिए बदलने के लिए बेहतर हो सकता है। विशिष्ट, बहुत ही सामान्य, पूर्वानुमेय, प्रदर्शन समस्याएं हैं जिनसे आपको निपटने के लिए मजबूर किया जाएगा, और आप अपने स्वयं के रोल करने के बजाय मौजूदा उपकरणों का उपयोग करने से बेहतर हैं।

---

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

जब जो करना था कर लिया

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

कोड लिखने के लिए भी यह एक आसान संयोजन है - एपीआई काफी सीधा-आगे और बुनियादी है, और इसे काम करने के लिए कोड की अपेक्षाकृत कुछ पंक्तियां लगती हैं।

आमतौर पर, यह आदर्श है कि आपने क्या किया है:

• नए विचारों का प्रोटोटाइप
• बिल्डिंग अनुप्रयोगों को जो बड़े पैमाने पर, प्रदर्शन के हिसाब से होने की संभावना नहीं है
• असामान्य परिस्थितियों से विवश, जैसे डेटाबेस स्थापित करने के लिए संसाधनों की कमी

वैकल्पिक

आप विकल्पों की एक निरंतरता पर हैं, और दो 'दिशाएं' हैं आप यहां से जा सकते हैं, जो मैं 'डाउन' और 'अप' के रूप में सोचता हूं:

नीचे

यह लागू करने के लिए कम से कम विकल्प है, लेकिन यह पूर्णता के लिए यहां है:

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

यूपी

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

अधिक शक्तिशाली डेटा स्टोर

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

जब आपके आवेदन का वर्णन किया जाता है, तो इसे स्केल करने का स्पष्ट रास्ता है:

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

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

प्रसिद्ध उदाहरण: CouchDB , MongoDB , Redis , Microsoft के Azure , Google App Data Store और Amazon के ECE जैसे क्लाउड स्टोरेज समाधान ।

अधिक जटिल डेटा हेरफेर इंजन

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

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

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

प्रसिद्ध उदाहरण MySQL , SQL सर्वर , Oracle का डेटाबेस और DB2 हैं ।

कार्य को आउटसोर्स करता है

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

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

प्रसिद्ध उदाहरण एमवीसी उपकरण ( Django , Yii ), रूबी ऑन रेल्स , और डाटोमिक हैं । यहां उचित होना कठिन है क्योंकि वहाँ दर्जनों उपकरण और पुस्तकालय हैं जो विभिन्न डेटा स्टोरों के एपीआई के आसपास रैपर के रूप में कार्य करते हैं।

---

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

Answer 7

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

फ़ाइल सिस्टम (और सामान्य रूप से NoSQL) के साथ एक मुद्दा डेटा के बीच संबंधों को संभाल रहा है। अगर वह यहाँ प्रमुख अवरोधक नहीं है, तो मैं कहूंगा कि अभी के लिए RDBMS छोड़ें। भंडारण के रूप में फ़ाइल सिस्टम का उपयोग करने के सकारात्मक पक्षों को भी याद रखें:

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

( स्रोत )

Answer 8

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

तो, आप एक डेटाबेस का उपयोग कर रहे हैं। अन्य पोस्ट विभिन्न प्रकार के डेटाबेस के गुणों के बारे में बहस कर सकते हैं ...

Comments

डेटाबेस और स्टोरेज को वास्तव में एक दूसरे के साथ इस्तेमाल नहीं किया जा सकता है। एक डेटाबेस एक प्रकार का स्टोरेज है, लेकिन एक फाइल सिस्टम निश्चित रूप से एक प्रकार का डेटाबेस नहीं है

— Gaz_Edge

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

— क्रिस एस

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

— क्रिस एस

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

— रोब मोइर

Answer 9

यदि आप कई प्रक्रियाओं (उपयोगकर्ता / सर्वर) डेटा को संशोधित करने के लिए एक डेटाबेस की जरूरत है। तब डेटाबेस उन्हें एक-दूसरे के परिवर्तन को ओवरराइट करने से रोकने के लिए कार्य करता है।

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

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

Comments

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

— MaiaVictor

जो मुझे लगता है कि मैं हूं। उदाहरण के लिए, जब मैं "प्लेयर लिस्ट" से डेटा को "रैंकिंग" में बदल देता हूं, तो यह कुछ और नहीं बल्कि ऑपरेशन को कम करता है। गेम या इंटरेक्टिव साइट बनाते समय, आपके द्वारा प्रस्तुत किया जाने वाला बहुत कुछ आपके मुख्य डेटा से एक मैपआरड्यूस ऑपरेशन है! तो उस प्रकार का अनुकूलन वास्तव में वांछनीय हो सकता है। खैर, मुझे कोई अंदाजा नहीं है कि मैं जो भी बात कर रहा हूं, वह आगे बढ़ रहा है, लेकिन इससे कोई मतलब नहीं है। आज बहुत कुछ सीखना, और मैं वास्तव में NoSQL अवधारणाओं को पसंद कर रहा हूं। उत्तर के लिए धन्यवाद (:

— MaiaVictor

Answer 10

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

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

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

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

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

Comments

बस ध्यान देने के लिए, मैंने वास्तव में वर्षों तक mysql का उपयोग किया है जब मैंने एक "otserv" की मेजबानी की थी। अंदाज़ा लगाओ? यह सब लाया समस्याओं था। लोग अपने पात्रों को सहेजने के बाद गंदे चाल का उपयोग करके "क्लोन" आइटम कर सकते थे जब वे लॉग आउट होते थे लेकिन सर्वर क्रैश होने पर नहीं। यह otservs के लिए एक गंभीर समस्या है। और otserv समुदाय विशाल है। ऐसा नहीं होगा अगर वे सिर्फ मेमोरी पर डेटा संग्रहीत करते हैं और समय-समय पर इसे क्रमबद्ध करते हैं। इसलिए मैंने अपने आप से स्रोत को संशोधित किया, उन लंबी सी ++ फाइलों को और समय-समय पर वर्णों को लॉग आउट करने के बजाय mysql को सहेजना शुरू कर दिया। अंदाज़ा लगाओ? यह धीमी थी!

— MaiaVictor

Mysql बस पूरी तरह से प्रत्येक 2 मिनट या तो राज्य की बचत नहीं कर सकता। यह बहुत स्पष्ट था जब बचत हुई - पूरा सर्वर एक सेकंड के लिए "पिछड़ गया"। अब मैं वास्तव में सराहना करता हूँ अगर यहाँ पोस्ट करने वाले लोगों के पास उस के लिए एक उत्तर था!

— MaiaVictor

RDBMSs को एक एकल अनुप्रयोग के साथ जो कि शायद खराब कोडित था, के साथ न्याय न करें। खासतौर पर तब जब डेटाबेस का समर्थन करने के लिए संशोधन बिना किसी डेटाबेस अनुभव के किए गए हों।

— alroc

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

— mikerobi

@Dokkat तो आप डॉन; t MySql या किसी अन्य पूर्ण विशेषताओं वाले "सर्वर" शैली DB का उपयोग न करें। आप Sqlite (या समान) का उपयोग करते हैं और यह हर बार डिस्क पर बनी रहती है, जबकि आपको अपने ऐप में एम्बेड किया गया DB देता है (इसलिए अलग इंस्टॉल की कोई आवश्यकता नहीं है) और फिर भी आपको sql एक्सेस, ट्रांसेक्शनल अखंडता और डिस्क दृढ़ता प्रदान करता है।

— gbjbaanb

Answer 11

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

उदाहरण के लिए key = ghostwriter g / ho / stwriter.json या g / h / o / stwriter.json या g / ho / ghostwriter.json या g / h / ghostwriter.json में जाएगा। अपनी कुंजी के वितरण के आधार पर अपनी नामकरण योजना चुनें। यदि वे अनुक्रम संख्या हैं तो 5/4/3 / 12345.json अन्य तरीके से बेहतर है।

यह एक डेटाबेस है और यदि यह वह सब करता है जो आपको चाहिए, तो इसे इस तरह से करें। आजकल जिसे GDBM, या बर्कले db जैसे NoSQL डेटाबेस कहा जाएगा। इतने सारे विकल्प। पहले पता लगाएँ कि आपको क्या चाहिए, फिर विवरणों से निपटने के लिए एक इंटरफ़ेस लाइब्रेरी का निर्माण करें, शायद एक मिल / सेट इंटरफ़ेस जैसे मेम्केड या सीआरयूडी इंटरफ़ेस, और फिर आप पुस्तकालयों को स्वैप करने में सक्षम होंगे यदि आपको डेटाबेस प्रारूप को एक के लिए बदलने की आवश्यकता है विभिन्न विशेषताओं के साथ।

ध्यान दें कि कुछ SQL डेटाबेस जैसे PostgreSQL और Apache Derby DB, आपको अपने स्वयं के होमग्रॉन डेटाबेस सहित कई NoSQL प्रारूपों के ऊपर SQL प्रश्न करने की अनुमति देंगे। MyBatis के बारे में निश्चित नहीं है लेकिन यह समान हो सकती है।

NoSQL प्रचार से बचें। सुविधाओं के बारे में पढ़ें, प्रदर्शन और क्षमता का परीक्षण करें और फिर इस आधार पर चुनें कि यह आपकी एप्लिकेशन आवश्यकताओं से कितनी अच्छी तरह मेल खाता है।

http://www.hdfgroup.org/HDF5/ अभी तक एक और दिलचस्प और व्यापक रूप से उपयोग किया जाने वाला डेटास्टोर प्रारूप है जिसे लोग अक्सर नहीं मानते हैं।

Answer 12

जैसे ही डेटा समवर्ती रूप से अपडेट किया जाता है, डेटाबेस का उपयोग करने वाला दृष्टिकोण (यह अच्छी तरह से मेमोरी डेटाबेस में हो सकता है) संभवतः अधिक सही और अधिक प्रदर्शनकारी होगा, जबकि उसी समय आपका कोड आसान रहता है, क्योंकि आपके पास बस नहीं है समवर्ती अद्यतन, लेनदेन, कैशिंग, अतुल्यकालिक I / O और उस सब के बारे में चिंता करने की।

Comments

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

— धसानन

@ धर्मसेन - यह अच्छे डेटाबेस सिस्टम का एक और फायदा है। आपको कंसीडर मिलता है, और यह सभी मामलों में काम करता है: मल्टी-थ्रेडेड, मल्टी-प्रोसेस, विभिन्न सर्वरों पर मल्टीपल क्लाइंट या कोई भी संयोजन। आपका कुआँ हालांकि बहु-थ्रेडेड प्रोग्राम कुछ मामलों में "अधिक कुशल" हो सकता है, फिर भी यह केवल पैमाना नहीं होगा।

— इंगो

Answer 13

आपको यहां पोस्ट की तरह क्यूए को स्टोर / पुनः प्राप्त करने के लिए डेटाबेस की आवश्यकता है! एक साधारण फ़ाइल विभिन्न विषयों से संबंधित डेटा को व्यवस्थित करने में असमर्थ है।

Comments

नहीं, "विषय" फ़ोल्डर हो सकते हैं, और साइट पर "पोस्ट" फाइलें हो सकती हैं। यह एक फाइल सिस्टम की तरह एक साइट को चलाने के लिए निश्चित रूप से संभव है। यह कुशल नहीं है: धीमी गति से और जटिल, प्रश्नों को चलाने, नए डेटा डालने, आदि

— क्रिस एस

धीमा + जटिल = असमर्थ?

— जो

धीमी और जटिल बनाने के लिए! = धीमी गति से और जटिल कार्य करने के लिए

— जो

@ हाँ, यह वास्तव में सच नहीं है कि एक फ़ाइल (शायद "सरल" फ़ाइल नहीं है, लेकिन इसका क्या मतलब है?) का उपयोग विभिन्न विषयों से संबंधित डेटा को व्यवस्थित करने के लिए नहीं किया जा सकता है। आप JSON का उपयोग कर सकते हैं, जैसा कि Dokkat से पता चलता है, या XML, या मिश्रित-रिकॉर्ड फाइलें जैसे हम पूर्व-XML दिनों में वापस करते थे, या जो भी फ़ाइल प्रारूप आप सपना देख सकते हैं। मैं इनमें से किसी भी परिदृश्य के लिए दृष्टिकोण की सिफारिश नहीं करूंगा, लेकिन इसका मतलब यह नहीं है कि वे नहीं किया जा सकता है।

— जॉन एम गैंट

@ जॉन एम गैंट: पूरी तरह से आपके साथ सहमत हैं, डेटाबेस एकल को प्रतिस्थापित नहीं कर सकता (क्योंकि आपको सरल पसंद नहीं है) फाइलें, और इसके विपरीत, केवल इस कारण से कि कार एक साइकिल को प्रतिस्थापित नहीं कर सकती है। मैं 3 "मानव" भाषाएं बोलता हूं, और शब्दों और शब्दावली की मेरी पसंद यही कारण है कि मुझे गलत समझा गया ... मुझे लगता है

— जो