नोएसQL डाटाबेस

Question

से संबंधित यह प्रश्न सभी नोएसक्यूएल और विशेष रूप से एमओएनओडीबी विशेषज्ञों के लिए है। मैंने एक परियोजना के लिए एक रिलेशनल डीबी डिजाइन करके शुरू किया लेकिन क्लाइंट चाहता है कि हम एक डीबी का उपयोग करें जो आसानी से स्केल कर सके। इसे प्राप्त करने के लिए हमने mongoDB का उपयोग करने का निर्णय लिया है। इन दिनों मुझे NoSQL के लिए मेरे संबंध मॉडल मैपिंग में परेशानी हो रही है।

विकल्प:

मैं जब यह MongoDB के लिए परिवर्तित करने के लिए कुछ विकल्प हैं: मैं जो अन्य तालिकाओं का एक बहुत कुछ के साथ एक बहुत-से-अनेक संबंध नहीं एक उपयोगकर्ता तालिका के रूप में नीचे बताया गया है

users:{ 
    _id:<user_id>, 
    battles:{[battle1, battle2, ...]}, 
    items:{[item1, item2, ...]}, 
    locations:{[location1, location2, ...]}, 
    units:{[unit1, unit2, ...]}, 
} 

battles:{ 
    <battle_info> 
} 

locations:{ 
    <location_info> 
} 

units:{ 
    <units_info> 
} 

items:{ 
    <items_info> 
} 

Option2 (उन में केवल विदेशी कुंजी के साथ):

1 (उन में पूरा पंक्तियों के साथ)

users:{ 
    _id:<user_id>, 
    battles:{[battle1_id, battle2_id, ...]}, 
    items:{[item1_id, item2_id, ...]}, 
    locations:{[location1_id, location2_id, ...]}, 
    units:{[unit1_id, unit2_id, ...]}, 
} 

battles:{ 
    <battle_info> 
} 

locations:{ 
    <location_info> 
} 

units:{ 
    <units_info> 
} 

items:{ 
    <items_info> 
} 

विकल्प 3 (अन्य तालिकाओं में उपयोगकर्ता आईडी): के रूप में हम अन्य तालिकाओं की पूरी पंक्तियों को जोड़ रहे हैं

users:{ 
    _id:<user_id>, 
} 

battles:{ 
    <battle_info>, 
    user:{[user1_id, user2_id, ...]} 
} 

locations:{ 
    <location_info>, 
    user:{[user1_id, user2_id, ...]} 
} 

units:{ 
    <units_info>, 
    user:{[user1_id, user2_id, ...]} 
} 

items:{ 
    <items_info>, 
    user:{[user1_id, user2_id, ...]} 
} 

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

विकल्प 2 अधिक रिलेशनल है जहां हमारे पास उपयोगकर्ता तालिका में अन्य तालिकाओं के mongoIds हैं। इस विकल्प का लाभ यह है कि युद्ध या वस्तु को अद्यतन करने की लागत बहुत अधिक नहीं होती है क्योंकि पंक्तियों का संदर्भ नहीं दिया जाता है। दूसरी तरफ, जब उपयोगकर्ता लॉग इन करता है तो हमें संपूर्ण संदर्भ ऑब्जेक्ट के जवाब देने के लिए सभी संदर्भित इकाइयों, युद्धों, वस्तुओं और स्थानों को ढूंढना होगा।

विकल्प 3 विकल्प 2 के विपरीत है जहां उपयोगकर्ता तालिका के mongoIds अन्य तालिकाओं में रखा जाता है। यह विकल्प मेरे लिए बहुत अपील नहीं करता है।

मैं वास्तव में किसी की मार्गदर्शिका या बेहतर मॉडल के साथ आने की सराहना करता हूं।

संपादित करें:

मूल रूप से यह एक MMORPG खेल है जहाँ कई ग्राहकों क्षुधा webservices के माध्यम से सर्वर से कनेक्ट होगा। डेटा स्टोर करने के लिए हमारे पास क्लाइंट पर स्थानीय डीबी है। मैं एक मॉडल चाहता हूं जिसके माध्यम से सर्वर एक पूर्ण उपयोगकर्ता ऑब्जेक्ट के साथ प्रतिक्रिया दे सकता है और उसके बाद क्लाइंट ऐप्स पर डेटा को अपडेट या सम्मिलित कर सकता है।

Answer 1

पहले, NoSQL नहीं एक आकार सभी फिट बैठता है। एसक्यूएल में, लगभग हर 1: एन और एम: एन संबंध उसी तरह से मॉडलिंग किया जाता है। नोएसक्यूएल दर्शन यह है कि जिस तरह से आप डेटा मॉडल करते हैं, वह डेटा और उसके उपयोग पैटर्न पर निर्भर करता है।

दूसरा, मैं मार्क बेकर से सहमत हूं: स्केलिंग कठिन है, और यह बाधाओं को ढीला करके हासिल किया जाता है।यह एक तकनीकी बात नहीं है। मैं MongoDB के साथ काम से प्यार है, लेकिन अन्य कारणों के लिए (बदसूरत एसक्यूएल कोड करने के लिए कोई जरूरत नहीं; जटिल, फूला हुआ ORM के लिए कोई ज़रूरत नहीं है; आदि)

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

विकल्प 2/3 वे बहुत समान हैं। यहां कुंजी है: कौन लिख रहा है? आप नहीं चाहते हैं कि बहुत से क्लाइंट एक ही दस्तावेज़ में लेखन-पहुंच कर रहे हों, क्योंकि इससे आपको लॉकिंग तंत्र का उपयोग करने के लिए मजबूर किया जाएगा, और/या केवल संशोधक संचालन के लिए स्वयं को प्रतिबंधित कर दिया जाएगा। इसलिए, विकल्प 2 शायद 3 से बेहतर है। हालांकि, यदि कोई हमला बी है, तो वे उपयोगकर्ता बी को भी लिखना शुरू कर देंगे, इसलिए आपको यह सुनिश्चित करना होगा कि आपके लेखन सुरक्षित हैं।

विकल्प 4 आंशिक असमान्यीकरण: आपका उपयोगकर्ता वस्तु सबसे महत्वपूर्ण प्रतीत हो रहा है, तो कैसे इस बारे में:

user { 
battles : [ {"Name" : "The battle of foo", "Id" : 4354 }, ... ] 
... 
} 

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

विकल्प 5 किनारों पर डेटा। अक्सर, संबंध डेटा रखने के लिए और साथ ही जरूरत है:

user { 
battles : [ {"Name" : "The battle of foo", "unitsLost" : 54, "Id" : 34354 }, ... ] 
} 

यहाँ

, unitsLost उपयोगकर्ता और लड़ाई के लिए विशिष्ट है, इसलिए डेटा ग्राफ के किनारे पर बैठता है। युद्ध के नाम के विपरीत, यह डेटा denormalized नहीं है।

विकल्प 6 लिंकर संग्रह। बेशक, इस तरह का 'एज-डेटा' बड़ा हो सकता है और यहां तक ​​कि एक अलग संग्रह (लिंकर संग्रह) भी कह सकता है।

user { 
    "_id" : 3443 
} 

userBattles { 
    userId : 3443, 
    battleId : 4354, 
    unitsLost : 43, 
    itemsWon : [ <some list > ], 
    // much more data 
} 

इनमें से कौन सबसे अच्छा है अपने आवेदन का विवरण का एक बहुत पर निर्भर करता है: यह पूरी तरह से उपयोग कर सकते ताले की समस्या का निराकरण किया। यदि उपयोगकर्ता बहुत सारे क्लिक करते हैं (यानी आपके पास एक बढ़िया इंटरफ़ेस है), तो विकल्प 4 या 6 में ऑब्जेक्ट्स को विभाजित करना समझ में आता है। यदि आपको वास्तव में एक बैच में सभी डेटा की आवश्यकता है, तो आंशिक denormalization मदद नहीं करता है, इसलिए विकल्प 2 बेहतर होगा। कई लेखक समस्या को ध्यान में रखें।

Answer 2

विकल्प 2 जाने का तरीका है।

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

भी 10gen "मैन्युअल" संदर्भ आईडी उपयोग करने की सलाह: http://www.mongodb.org/display/DOCS/Database+References