सभी उत्तर (इस लेखन के समय) रेडिस, मोंगोबडी में से प्रत्येक को मानते हैं, और शायद एक SQL- आधारित रिलेशनल डेटाबेस अनिवार्य रूप से एक ही उपकरण है: "डेटा संग्रहीत करें"। वे डेटा मॉडल पर बिल्कुल भी विचार नहीं करते हैं।
MongoDB: जटिल डेटा
MongoDB एक डॉक्यूमेंट स्टोर है। SQL- संचालित रिलेशनल डेटाबेस के साथ तुलना करने के लिए: रिलेशनल डेटाबेस अनुक्रमित CSV फ़ाइलों को सरल करता है, प्रत्येक फ़ाइल एक टेबल है; दस्तावेज़ भंडार अनुक्रमित JSON फ़ाइलों को सरल करते हैं, प्रत्येक फ़ाइल एक दस्तावेज़ है, जिसमें कई फाइलें एक साथ समूहीकृत हैं।
JSON फाइलें XML और YAML फ़ाइलों की संरचना में और पायथन में शब्दकोशों के समान हैं, इसलिए अपने डेटा को उस प्रकार के पदानुक्रम में समझें। अनुक्रमण करते समय, संरचना कुंजी है: एक दस्तावेज़ में कुंजी नाम होते हैं, जिसमें या तो आगे दस्तावेज़, सरणियाँ या स्केलर मान शामिल होते हैं। नीचे दिए गए दस्तावेज़ पर विचार करें।
{
_id: 0x194f38dc491a,
Name: "John Smith",
PhoneNumber:
Home: "555 999-1234",
Work: "555 999-9876",
Mobile: "555 634-5789"
Accounts:
- "379-1111"
- "379-2574"
- "414-6731"
}
उपरोक्त दस्तावेज़ में एक कुंजी है PhoneNumber.Mobile, जिसका मूल्य है 555 634-5789। आप दस्तावेजों के संग्रह के माध्यम से खोज सकते हैं जहां कुंजी, PhoneNumber.Mobileकुछ मूल्य है; वे अनुक्रमित हैं।
इसका एक सरणी भी है Accountsजिसमें कई अनुक्रमित हैं। किसी ऐसे दस्तावेज़ के लिए क्वेरी करना संभव है, Accountsजिसमें मानों के कुछ सबसेट होते हैं , सभी मानों के कुछ सबसेट या मानों के कुछ सबसेट में से किसी एक को शामिल किया जाता है। इसका मतलब है कि आप खोज सकते हैंAccounts = ["379-1111", "379-2574"] ऊपर और नहीं ; आप Accounts includes ["379-1111"]उपरोक्त दस्तावेज़ खोज सकते हैं और पा सकते हैं ; और आप खोज सकते Accounts includes any of ["974-3785","414-6731"]हैं और उपरोक्त और जो भी दस्तावेज शामिल हैं, उसे "974-3785", यदि कोई हो
दस्तावेज़ आप चाहते हैं के रूप में गहरे जाते हैं। PhoneNumber.Mobileएक सरणी, या यहां तक कि एक उप-दस्तावेज़ ( PhoneNumber.Mobile.Workऔर PhoneNumber.Mobile.Personal) पकड़ सकता है । यदि आपका डेटा अत्यधिक संरचित है, तो दस्तावेज़ रिलेशनल डेटाबेस से एक बड़ा कदम है।
यदि आपका डेटा ज्यादातर सपाट, संबंधपरक और कठोर रूप से संरचित है, तो आप एक रिलेशनल डेटाबेस के साथ बेहतर हैं। फिर, बड़ा संकेत यह है कि आपके डेटा मॉडल परस्पर संबंधित CSV फ़ाइलों के संग्रह या XML / JSON / YAMT फ़ाइलों के संग्रह के लिए सबसे अच्छा है।
अधिकांश परियोजनाओं के लिए, आपको कुछ छोटे क्षेत्रों में-जहाँ एसक्यूएल या डॉक्यूमेंट स्टोर फिट नहीं होते हैं, को मामूली काम को स्वीकार करते हुए समझौता करना होगा; कुछ बड़े, जटिल प्रोजेक्ट्स के लिए डेटा का व्यापक प्रसार (कई कॉलम; पंक्तियाँ अप्रासंगिक) हैं, यह कुछ डेटा को एक मॉडल में और दूसरे डेटा को किसी अन्य मॉडल में संग्रहीत करने के लिए समझ में आएगा। फेसबुक SQL और एक ग्राफ़ डेटाबेस (जहाँ डेटा नोड्स में डाला जाता है, और नोड्स अन्य नोड्स से जुड़े हैं) दोनों का उपयोग करता है; क्रेगलिस्ट ने MySQL और MongoDB का उपयोग किया था, लेकिन MongoDB पर पूरी तरह से आगे बढ़ रहा था। ये ऐसी जगहें हैं जहां डेटा के स्पैन और रिलेशनशिप में एक मॉडल के तहत महत्वपूर्ण बाधाएं आती हैं।
रेडिस: की-वैल्यू
रेडिस, सबसे मूल रूप से, एक कुंजी-मूल्य की दुकान है। रेडिस आपको इसकी एक कुंजी देता है और एक एकल मान दिखता है। रेडिस स्वयं स्ट्रिंग्स, सूचियों, हैश और कुछ अन्य चीजों को स्टोर कर सकता है; हालाँकि, यह केवल नाम से दिखता है।
कैश अमान्य होना कंप्यूटर विज्ञान की कठिन समस्याओं में से एक है; दूसरी चीजों का नामकरण है। इसका मतलब है कि जब आप सैकड़ों अतिरिक्त लुक-अप से बचना चाहते हैं, तो आप रेडिस का उपयोग करेंगे, लेकिन जब आपको नए लुक-अप की आवश्यकता होगी, तो आपको यह पता लगाना होगा।
अमान्य होने का सबसे स्पष्ट मामला अद्यतन पर है: यदि आप पढ़ते हैं user:Simon:lingots = NOTFOUND, तो आप SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simonपरिणाम को 100, जैसे भी हो , स्टोर कर सकते हैं SET user:Simon:lingots = 100। फिर जब आप साइमन 5 lingots पुरस्कार, आप पढ़ सकते हैं user:Simon:lingots = 100, SET user:Simon:lingots = 105, और UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon। अब आपके पास अपने डेटाबेस में और Redis में 105 हैं, और user:Simon:lingotsडेटाबेस को क्वेरी किए बिना प्राप्त कर सकते हैं ।
दूसरा मामला निर्भर जानकारी को अद्यतन कर रहा है। मान लें कि आप किसी पृष्ठ का हिस्सा बनाते हैं और उनके आउटपुट को कैश करते हैं। हेडर खिलाड़ी के अनुभव, स्तर और पैसे की मात्रा को दर्शाता है; खिलाड़ी के प्रोफाइल पेज में एक ब्लॉक होता है जो उनके आंकड़े दिखाता है; इत्यादि। खिलाड़ी कुछ अनुभव हासिल करता है। खैर, अब आप कई है templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon, और इसके आगे-प्रांगण जहां एक आधा दर्जन डेटाबेस प्रश्नों एक टेम्पलेट इंजन के माध्यम से चलाने के उत्पादन में कैश की गई है। आम तौर पर, जब आप इन पृष्ठों को प्रदर्शित करते हैं, तो आप कहते हैं:
$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
$t = BuildTemplate("StatsBox.tmpl",
GetStatsFromDatabase($playerName));
SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;
क्योंकि आपने अभी-अभी के परिणामों को अपडेट किया है GetStatsFromDatabase("Simon"), इसलिए आपको templates:*:Simonअपने कुंजी-मूल्य कैश से बाहर करना होगा। जब आप इनमें से किसी भी टेम्प्लेट को रेंडर करने का प्रयास करते हैं, तो आपका एप्लिकेशन आपके डेटाबेस (पोस्टग्रेएसक्यूएल, मोंगोडीबी) से डेटा लाने और इसे आपके टेम्पलेट में डालने पर मंथन करेगा; इसके बाद यह रिडिस में रिजल्ट को स्टोर करेगा और उम्मीद है कि अगली बार जब यह आउटपुट के ब्लॉक को प्रदर्शित करता है तो डेटाबेस क्वेश्चन तैयार करना और टेम्प्लेट करना परेशान नहीं करेगा।
रेडिस आपको प्रकाशक-सदस्यता संदेश कतार और ऐसे भी देता है। यह एक और विषय है। यहाँ बिंदु Redis एक कुंजी-मूल्य कैश है, जो एक संबंधपरक डेटाबेस या दस्तावेज़ स्टोर से भिन्न होता है।
निष्कर्ष
अपनी आवश्यकताओं के आधार पर अपने उपकरण चुनें। सबसे बड़ी जरूरत आमतौर पर डेटा मॉडल की होती है, जो यह निर्धारित करता है कि आपका कोड कितना जटिल और त्रुटि रहित है। विशिष्ट अनुप्रयोग प्रदर्शन पर झुकेंगे, ऐसे स्थान जहां आप सी और असेंबली के मिश्रण में सब कुछ लिखते हैं; अधिकांश अनुप्रयोग केवल सामान्यीकृत मामले को संभालेंगे और एक कैशिंग प्रणाली जैसे कि रेडिस या मेमकाटेड का उपयोग करेंगे, जो कि उच्च-प्रदर्शन वाले SQL डेटाबेस या दस्तावेज़ स्टोर की तुलना में बहुत तेज़ है।