2009-11-29 15 views
14

के बारे में सलाह चाहिए हाल ही में मैं NoSQL डेटाबेस की खोज कर रहा हूं। मुझे किसी दिए गए समस्या के लिए सबसे इष्टतम और कुशल तरीके से डेटा को स्टोर करने के बारे में सलाह चाहिए। मैं अब मोंगो डीबी को लक्षित कर रहा हूं। हालांकि यह कॉच डीबी के साथ समान होना चाहिए।मुझे NoSQL/MongoDb और डेटा/मॉडल संरचना

मान लें कि हम इन 3 मॉडल है:

Story: 
id 
title 

User: 
id 
name 

Vote: 
    id 
    story_id 
    user_id 

मैं डेटाबेस इन सवाल पूछने के लिए सक्षम होना चाहते हैं:

  • कौन इस कहानी के लिए मतदान किया गया है?
  • इस उपयोगकर्ता ने क्या वोट दिया है?

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

उदाहरण के लिए, यदि मैं वोट ऑब्जेक्ट्स को कहानियों के उप-संग्रह के रूप में संग्रहीत करता हूं तो यह जानकारी प्राप्त करना आसान नहीं होगा - "उपयोगकर्ता ने क्या वोट दिया है"।

उत्तर

7

मैं प्रत्येक उपयोगकर्ता में कहानी _id एस की सूची के रूप में वोट संग्रहीत करने का सुझाव दूंगा। इस तरह आप यह पता लगा सकते हैं कि उपयोगकर्ता ने सूची को देखकर क्या कहानियों को वोट दिया है। उपयोगकर्ताओं को, जो एक कहानी आप की तरह कुछ कर सकते हैं के लिए मतदान किया पाने के लिए:

db.users.find({stories: story_id})

जहां story_id प्रश्न में कहानी का _id है। यदि आप stories फ़ील्ड पर एक अनुक्रमणिका बनाते हैं तो वे दोनों प्रश्न तेजी से होंगे।

+0

अच्छा, वास्तव में मैं एक वोट मॉडल में अधिक जानकारी स्टोर करना चाहता हूं। उदाहरण के लिए: बनाया_at, ip, user_agent। क्या मुझे डेटा संग्रह की कहानियों की सूची में डेटा स्टोर करना चाहिए? –

+0

आप वोटों को उप-दस्तावेजों की एक सरणी के रूप में स्टोर कर सकते हैं, प्रत्येक '{story_id: ..., created_at: ..., ip: ...}', आदि। फिर क्वेरी 'ढूंढें ({' कहानियां .story_id ': ...}) '। आप उस पर भी इंडेक्स कर सकते हैं। – mdirolf

+0

वैसे मेरे पास कुछ एम रिकॉर्ड के साथ काफी बड़ा डेटाबेस है और उपर्युक्त परिदृश्य का परीक्षण करेगा। –

2

ठीक है, आपने एक सामान्यीकृत डेटा मॉडल दिया है जैसा कि आप SQL सेटअप में करेंगे।

मेरी समझ में आप इसे मोंगोडीबी में नहीं करते हैं। आप संदर्भों को स्टोर कर सकते हैं, लेकिन आप सामान्य मामले में प्रदर्शन कारणों के लिए नहीं हैं।

मैं नोएसक्यूएल क्षेत्र में किसी भी तरह से विशेषज्ञ नहीं हूं, लेकिन आप अपनी जरूरतों का पालन क्यों नहीं करते हैं और उपयोगकर्ता (आईडी) को स्टोर करते हैं जिन्होंने कहानियों के संग्रह और कहानी (ids) में एक कहानी के लिए वोट दिया है) उपयोगकर्ता ने उपयोगकर्ता संग्रह में वोट दिया है?

1

कॉच डीबी में यह बहुत आसान है। एक राय यह उत्सर्जन करता है:

function(doc) { 
if(doc.type == "vote") { 
    emit(doc.story_id, doc.user_id); 
} 
} 

एक अन्य दृश्य का उत्सर्जन करता है:

function(doc) { 
if(doc.type == "vote") { 
    emit(doc.user_id, doc.story_id); 
} 
} 

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

+0

मुझे इस परिदृश्य में प्रश्न पूछने की आवश्यकता होगी, क्या मैं? वोट दस्तावेजों के लिए एक सूचकांक पूछने के लिए और उपयोगकर्ता/कहानी के लिए दस्तावेज़ प्राप्त करने के लिए एक। –

+0

@ स्टैनिस्लाव। वह सही है। आपको पहले वोट प्राप्त करने और फिर उन वोटों के लिए उपयोगकर्ताओं और/या कहानियां लाने की आवश्यकता होगी। – dnolen

3
  • चिंता मत करो अगर आपके प्रश्नों कुशल हैं जब तक यह उद्धरण नीचे के अनुसार
  • बात करने के लिए, आप कर रहे हैं शुरू होता है यह गलत

तरह से मैं के बारे में जा रहा किया गया है दिमाग स्विच डेटाबेस के बारे में भूलना है। संबंधपरक डीबी दुनिया में आपको हमेशा डेटा सामान्यीकरण और आपकी तालिका संरचना के बारे में चिंता करने की आवश्यकता है। यह सब खाओ। बस अपना वेब पेज लेआउट करें। उन्हें सभी बाहर रखें। अब उन्हें देखो। आपका पहले से ही 2/3 है। यदि आप धारणा को भूल जाते हैं कि डेटाबेस आकार मायने रखता है और डेटा को आपके 3/4 से डुप्लिकेट नहीं किया जाना चाहिए और आपके पास भी कोई कोड नहीं लिखना चाहिए! अपने विचारों को अपने मॉडल को निर्देशित करने दें। आपको अपनी ऑब्जेक्ट्स लेने की आवश्यकता नहीं है और उन्हें आयामी अब संबंधपरक दुनिया में बनाना है। आप आकार के साथ ऑब्जेक्ट्स स्टोर कर सकते हैं।

how-to-think-in-data-stores-instead-of-databases

0

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

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

संबंधित मुद्दे