रीयलटाइम मल्टीप्लेयर गेम का उपयोग करने के लिए कौन सा डेटाबेस (RDBMS बनाम NoSQL बनाम दोनों)?


12

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

मेरी टीम के पास एक साझा वेबहोस्टिंग पैकेज है जो असीमित mySQL स्टोरेज और बैंडविड्थ प्रदान करता है, एकमात्र कैविट यह है कि हम एक समय में केवल 25 कनेक्शन खोल सकते हैं (साझा होस्टिंग नियम)। मैं अपनी वेबसाइट के लिए इसका उपयोग करने का इरादा कर रहा हूं (समाचारों को पोस्ट करने के लिए एक विशिष्ट उपयोग कोई संदेह नहीं है), सामुदायिक सुविधाओं का समर्थन करने के लिए (जैसे टिप्पणी, प्रशंसक कला को अपलोड करना, आदि) और पसंद है। यह सब ठीक है और अच्छा है - लेकिन! यह वह जगह है जहाँ चीजें दिलचस्प हो जाती हैं ... मैं अपनी वेबसाइट पर इन-गेम पर पोस्ट की गई इस जानकारी को प्रदर्शित करना चाहता हूं। इसका मतलब मेरी वेबसाइट और मेरे खेल दोनों के लिए mySQL का उपयोग करना है। न्यूज पोस्ट और लाइक के अलावा, मैं चैट और सर्वर सूची जैसी चीजों के लिए इन-गेम का उपयोग करने की योजना बना रहा हूं। मैं उस 25-कनेक्शन-नियम के बारे में चिंतित हूं।

जो मुझे प्रश्न # 1 पूछने की ओर ले जाता है: क्या यह काम करेगा और क्या एक बेहतर विकल्प है?

अब इसके अलावा, मैंने पढ़ा है कि NoSQL कितना अच्छा प्रदर्शन करता है और रीयलटाइम गेम्स के लिए अनुकूल है (मैं गलत हो सकता है, मैं यहां पहुंचने के लिए एक विशाल RDBMS बनाम NoSQL लौ युद्ध के माध्यम से चला गया हूं और शायद जला दिया गया हूं)। मूल रूप से, मैं अपने गेम ऑब्जेक्ट डेटा के सभी के लिए MongoDB का उपयोग करना चाहूंगा।

और फिर से, यह उपयोगी होगा यदि मैं कुछ संदर्भ प्रदान करता हूं: मुझे एक होस्ट (मोंगोलैब) मिला है जो मुफ्त में 240 एमबी का मोंगबीडी पैकेज प्रदान करता है, जिसे मैं अपग्रेड करने के लिए आवश्यक होने तक उपयोग करने का इरादा रखता हूं। 240MB को देखते हुए, मैंने गणना की है कि मैं लगभग 60,000 खिलाड़ियों को स्टोर करने में सक्षम हो जाऊंगा (यदि प्रत्येक खिलाड़ी लगभग 4KB है और हम अन्य चीजों को अनदेखा कर सकते हैं जिन्हें संग्रहीत किया जा सकता है)। भंडारण स्थान, और भविष्य में अधिक भुगतान करना चाहिए (हमारा खेल सफल होना चाहिए) कोई समस्या नहीं है। एकमात्र कारण जो मैं वर्तमान में अपने सभी गेम ऑब्जेक्ट डेटा के लिए MongoDB का उपयोग करने का इरादा रखता हूं, वह यह है कि इस गेम ऑब्जेक्ट डेटा को कितनी बार एक्सेस किया जाएगा (जैसे कि जब भी कोई खिलाड़ी मारा जाता है, एक आइटम उठाता है, एक बंदूक फायर करता है, आदि) I स्ट्रेट फॉरवर्ड स्कीमा-फ्री डॉक्यूमेंट (जो गेम ऑब्जेक्ट डेटा को मैप करना आसान बनाते हैं) को भी पसंद करते हैं। मुझे ध्यान देना चाहिए कि, एक समय में,

मैं अपनी वेबसाइट में एक ही MongoDB का उपयोग करने का इरादा रखता हूं, खिलाड़ी प्रोफ़ाइल जानकारी प्रदर्शित करने के लिए (मैं पूरी निरंतरता से चिंतित नहीं हूं, खेल में अपडेट से कुछ देरी ठीक है)। जो मुझे मेरे दूसरे प्रश्न की ओर ले जाता है, प्रश्न # 2: क्या यह एक अच्छा विचार है या क्या मुझे कुछ बेहतर करना चाहिए?

खेल को इस तरह से एक स्टार्ट अप अनुभव होगा:

  1. (MongoDB) में क्लाइंट लॉग्स
  2. क्लाइंट इन-गेम होम पेज w / चैट रूम (MySQL) पर है
  3. क्लाइंट सर्वर सूची (MySQL) में जाता है
  4. क्लाइंट एक सर्वर से जुड़ता है और उसमें खेलता है

  5. सर्वर सभी खिलाड़ियों के लिए अद्यतन संचार (MongoDB)

यह सिर्फ वह तरीका है जिसकी मैंने कल्पना की थी कि यह काम करेगा। क्या यह आपके लिए अच्छा है, या क्या आपके पास इस योजना में सुधार किया जा सकता है?


9
कम से कम आपने बहुत सी जानकारी प्रदान की है , कुछ लोगों के विपरीत जो पर्याप्त जानकारी नहीं देते हैं।
साइक्लॉप्स

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

1
बैक एंड प्रोग्रामिंग के लिए आप किस भाषा / उपकरण का उपयोग करते हैं?
आआआआआआआआआआआ आआआआआआ

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

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

जवाबों:


11

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

अपने डेटाबेस को सीधे इंटरनेट पर उजागर नहीं करना भी बहुत अधिक सुरक्षित है।


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

2
+1 ग्राहक के पास DB के साथ सीधे संवाद करना, goatse.cx कैलिबर का एक सुरक्षा छेद है।
बात नहीं

6

हम केवल एक बार में 25 कनेक्शन खोल सकते हैं (साझा होस्टिंग नियम)।

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

अब इसके अलावा, मैंने पढ़ा है कि NoSQL कितना अच्छा प्रदर्शन करता है और रीयलटाइम गेम्स के लिए अनुकूल है (मैं गलत हो सकता है, मैं यहां पहुंचने के लिए एक विशाल RDBMS बनाम NoSQL लौ युद्ध के माध्यम से चला गया हूं और शायद जला दिया गया हूं)। मूल रूप से, मैं अपने गेम ऑब्जेक्ट डेटा के सभी के लिए MongoDB का उपयोग करना चाहूंगा।

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

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

वर्तमान में मेरे गेम ऑब्जेक्ट डेटा के लिए MongoDB का उपयोग करने का एकमात्र कारण यह है कि इस गेम ऑब्जेक्ट डेटा को कितनी बार एक्सेस किया जाएगा (जैसे कि जब भी कोई खिलाड़ी मारा जाता है, तो एक आइटम उठाता है, एक बंदूक फायर करता है, आदि)

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

मुझे स्ट्रेट फॉरवर्ड स्कीमा-फ्री दस्तावेज़ भी पसंद हैं (जो गेम ऑब्जेक्ट डेटा को मैप करना आसान बनाते हैं)।

प्रदर्शन मुद्दे की तुलना में NOSQL दृष्टिकोण चुनने का यह एक बेहतर कारण है।

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

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

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


क्या आप इसके लिए कोई रूपरेखा सुझा सकते हैं? "आपको वास्तव में स्मृति में मूल्यों को रखने और हेरफेर करने की आवश्यकता है।" मैंने रेडिस के बारे में सुना है, लेकिन इसका मुख्य मूल्य संबंध है, क्या कुछ ऐसा है जहां हम हेरफेर कर सकते हैं?
user1735921 13

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

4

सभी वास्तविक समय डेटा को एप्लिकेशन मेमोरी में रखा जाना चाहिए, और कुछ भी मूर्खतापूर्ण होगा।

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

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


मैं मानता हूं, आप चाहते हैं कि ओटी आपके गेम डेटा को मेमोरी में बनाए रखे, और आप लॉग इन डेटा को मेमोरी में भी रख सकते हैं (यह देखते हुए कि वे बहुत छोटे हैं)
MarkR

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

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

2

क्या आप प्रति डेटाबेस अपने 60,000 उपयोगकर्ताओं पर भरोसा करते हैं? यदि नहीं, तो आपको "क्लाइंट से डेटाबेस एक्सेस" विचार को निक्स करना चाहिए, जब तक कि डेटाबेस सॉफ़्टवेयर की सुरक्षा में आपकी विशेषज्ञता का स्तर शीर्ष पर नहीं है, और आप आश्वस्त हैं कि आप किसी भी मुद्दे को समायोजित कर सकते हैं।


9
और अगर आप इसके बारे में आश्वस्त हैं, तो वास्तव में डेटाबेस सुरक्षा में आपकी विशेषज्ञता का स्तर शीर्ष पर नहीं है।
झॉकिंग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.