রিয়েলটাইম মাল্টিপ্লেয়ার গেমের জন্য কোন ডেটাবেস (আরডিবিএমএস বনাম নোএসকিউএল বনাম দুটি) ব্যবহার করবে?


12

আমি রিয়েলটাইম মাল্টিপ্লেয়ার গেমটিতে কাজ করছি যার জন্য একটি ডেটাবেস প্রয়োজন হবে (প্লেয়ার প্রোফাইল, বন্ধু, আনলক, সংবাদ ইত্যাদি বৈশিষ্ট্যের জন্য) এটি একটি স্ট্যান্ডার্ড পিসি গেম (ব্রাউজার-ভিত্তিক নয়) এবং ক্লায়েন্ট-সার্ভার ব্যবহার করবে স্থাপত্য। আমি ডাটাবেসগুলি ব্যবহারে নতুন এবং আমি উত্তপ্ত বিতর্কে হোঁচট খেয়ে গত কয়েকদিন ধরে কিছু গবেষণা করেছি: আরডিবিএমএস বনাম নোএসকিউএল। বর্তমানে আমি নোএসকিউএল এর দিকে ঝুঁকছি তবে প্রতিটি (আরডিবিএমএস এবং নোএসকিউএল) এর ব্যবহার সম্পর্কে পড়ার পরে, আমি উভয়ই ব্যবহার করতে প্ররোচিত হই। আমি জানি এটি অদ্ভুত মনে হতে পারে তবে আমার পরিস্থিতিটি আমাকে ব্যাখ্যা করতে দিন:

আমার টিমের একটি শেয়ারড ওয়েবহোস্টিং প্যাকেজ রয়েছে যা সীমাহীন মাইএসকিউএল স্টোরেজ এবং ব্যান্ডউইদথ সরবরাহ করে, এটি কেবলমাত্র আমাদের একসাথে কেবল 25 টি সংযোগ খোলা থাকতে পারে (শেয়ারিং হোস্টিংয়ের নিয়ম)। আমি নিউজ আপডেটগুলি পোস্ট করতে, সম্প্রদায়ের বৈশিষ্ট্যগুলিকে সমর্থন করতে (মতামত জানাতে, ফ্যান আর্ট ইত্যাদি আপলোড করা) এবং এ জাতীয় পছন্দ করতে আমার ওয়েবসাইটের জন্য (একটি সাধারণ ব্যবহারে সন্দেহ নেই) সন্দেহ করার চেষ্টা করছি। সব ঠিক আছে এবং ভাল - কিন্তু! এখানেই জিনিসগুলি আকর্ষণীয় হয়ে ওঠে ... আমি আমার ওয়েবসাইটে পোস্ট করা একই তথ্যটি খেলতে চাই। এর অর্থ আমার ওয়েবসাইট এবং আমার গেম উভয়ের জন্য মাইএসকিউএল ব্যবহার করা। নিউজ পোস্ট এবং লাইক ছাড়াও, আমি চ্যাট এবং সার্ভার তালিকার মতো জিনিসের জন্য এটিকে গেমটি ব্যবহার করার পরিকল্পনা করি। আমি প্রায় 25-সংযোগ-বিধি সম্পর্কে উদ্বিগ্ন।

যা আমাকে প্রশ্ন # 1 জিজ্ঞাসা করতে পরিচালিত করে: এটি কি কাজ করবে এবং এর চেয়ে আরও ভাল বিকল্প আছে?

এখন এটির পাশাপাশি, আমি নোএসকিউএল কতটা ভাল পারফর্ম করে এবং রিয়েলটাইম গেমসের জন্য উপযোগী তা সম্পর্কে আমি পড়েছি (আমি ভুল হতে পারি, আমি এখানে পৌঁছানোর জন্য NoSQL শিখা যুদ্ধ বনাম একটি বিশাল আরডিবিএমএস পেরিয়েছি এবং সম্ভবত পুড়ে গেছে)। মূলত, আমি আমার সমস্ত গেমের অবজেক্টের ডেটার জন্য মঙ্গোডিবি ব্যবহার করতে চাই।

And again, it will be helpful if I provide some context: I have found a host (MongoLab) which offers a 240MB MongoDB package for free, which I intend on using until it's necessary to upgrade. Given 240MB, I've calculated that I will be able to store roughly 60,000 players (if each player is roughly 4KB and we ignore other things that might be stored). The storage space, and having to pay for more in the future (should our game be successful) is not a problem. The only reason I currently intend on using MongoDB for all of my game object data is because of how often this game object data will be accessed (such as whenever a player is killed, picks up an item, fires a gun, etc.) I also like the straight forward schema-free documents (which make it easier to map game object data). I should note that, at one time, there will only ever be one server writing to a player's profile in the database (the server the player is in).

আমি প্লেয়ার প্রোফাইলের তথ্য প্রদর্শন করার জন্য, আমার ওয়েবসাইটে একই মঙ্গোডিবি ব্যবহার করার ইচ্ছা নিয়েছি (আমি সম্পূর্ণ ধারাবাহিকতায় উদ্বিগ্ন নই, গেম আপডেটগুলি থেকে কিছুটা বিলম্ব করা ঠিক আছে)। যা আমাকে আমার দ্বিতীয় প্রশ্নের দিকে নিয়ে যায়, প্রশ্ন # 2: এটি কি একটি ভাল ধারণা বা আমার আরও ভাল কিছু করা উচিত?

গেমটির সাথে শুরু করার মতো অভিজ্ঞতা থাকবে:

  1. ক্লায়েন্ট লগ ইন (মঙ্গোডিবি)
  2. ক্লায়েন্ট ইন-গেমের হোম পেজে ডাব্লু / চ্যাট রুমে রয়েছে (মাইএসকিউএল)
  3. ক্লায়েন্ট সার্ভার তালিকায় যায় (মাইএসকিউএল)
  4. ক্লায়েন্ট একটি সার্ভারের সাথে সংযোগ স্থাপন করে এবং এতে প্লে করে

  5. সার্ভার সমস্ত প্লেয়ারের জন্য আপডেট যোগাযোগ করে (মঙ্গোডিবি)

এটি কল্পনা করেছিলাম এটি ঠিক কাজ করবে। এটি কি আপনার কাছে ভাল দেখাচ্ছে, বা কীভাবে এই পরিকল্পনাটি উন্নত করা যায় সে সম্পর্কে আপনার কাছে পরামর্শ রয়েছে?


9
অন্তত আপনার প্রদত্ত প্রচুর এর তথ্য কিছু মতো মানুষ যারা দিতে না যথেষ্ট তথ্য।
সাইক্লোপস

7
আপনি কী পরামর্শ দিচ্ছেন তা আমি ভুল বুঝে উঠতে পারি তবে সুরক্ষার বিষয়টি হিসাবে আপনার গেমটি যে কোনও উপায়ে আপনার ডাটাবেসের সাথে সরাসরি সংযোগ স্থাপন করা উচিত নয়, তাই সংযোগের গণনা কোনও বিষয় নয়। যদি আপনার গেমটি সংযোগ করতে পারে তবে অন্য যে কেউ তা করতে পারে। আপনার গেম সার্ভার থেকে সংযুক্ত প্রতিটি প্লেয়ারের ডাটাবেসে নতুন সংযোগটি খোলা উচিত নয়।
ম্যাথু শার্লে

1
পিছনের শেষের প্রোগ্রামিংয়ের জন্য আপনি কোন ভাষা / সরঞ্জামগুলি ব্যবহারের পরিকল্পনা করছেন?
এআআআআআআআআআআআআআআআআআআআআ

4
আপনি যদি কোনও হোস্ট করা ডিবি চয়ন করেন তবে আপনার গেম থেকে আপনার সার্ভার এবং সেখান থেকে ডিবি সার্ভারে একটি রাউন্ড ট্রিপ হবে। এটি গেম থেকে আপনার সার্ভারের চেয়ে ধীর হতে চলেছে (যা কোনও স্থানীয় ডিবি সংযোগ খোলে) এবং নোএসকিউএল ব্যবহারের ধরে নেওয়া পারফরম্যান্স-অর্জনকে বাতিল করে দেবে।
বাম্মজ্যাক

"টিমের একটি শেয়ারড ওয়েবহোস্টিং প্যাকেজ রয়েছে যা সীমাহীন মাইএসকিউএল স্টোরেজ এবং ব্যান্ডউইথ সরবরাহ করে" ... তারা আপনাকে কী বলে এবং আপনি কী পান তা দুটি ভিন্ন জিনিস। আপনি বিশ্বের সমস্ত স্থান "রাখতে" পারেন তবে আপনি যদি চর্বিযুক্ত পাইপের পরিবর্তে ভার্চুয়াল স্ট্রের মাধ্যমে এটি অ্যাক্সেস করতে পারেন তবে এটি অকেজো।
কেন

উত্তর:


11

আমার পরামর্শটি হ'ল আপনার গেমটি এমন একটি ওয়েব সেবার সাথে যোগাযোগ করা যা আপনি তৈরি করেছেন যা এটি নিজেই ডেটাবেস অনুসন্ধানের সাথে সম্পর্কিত। এই মুহুর্তে, "স্যুইচিং" ওয়েব পরিষেবা বাস্তবায়ন (আপনার ওয়েব সার্ভিস ইন্টারফেস সর্বদা একই থাকে যাতে আপনার গেমটি না ভেঙে যায়) এবং কোনটি আপনার পক্ষে ঠিক তা সিদ্ধান্ত নিয়ে বিভিন্ন ধরণের ডাটাবেস চেষ্টা করা খুব সহজ simple

আপনার ডেটাবেস সরাসরি ইন্টারনেটে প্রকাশ না করাও অনেক বেশি সুরক্ষিত।


এটি একটি দুর্দান্ত ধারণা, আপনাকে ধন্যবাদ, আমি অবশ্যই করব। আমি ডেটাবেস ব্যবহার করতে নতুন, তাই এই জিনিস আমার কাছে ঘটেনি।
অ্যান্ড্রু

2
+1 ক্লায়েন্টকে সরাসরি ডিবির সাথে যোগাযোগ করা হ'ল ছাগল.সিএক্স ক্যালিবারের সুরক্ষা গর্ত।
কিছু মনে করবেন না

6

আমাদের একসাথে কেবল 25 টি সংযোগ খোলা থাকতে পারে (শেয়ারিং হোস্টিংয়ের নিয়ম)।

এটি আপনার খেলার জন্য যথেষ্ট বেশি than সমস্যাটি হ'ল যদি আপনার ওয়েবসাইটটি একাধিক সংযোগ ব্যবহার করে তবে আপনি শেষ হয়ে যেতে পারেন। আপনার গেম সার্ভারের জন্য বাকী রেখে কেবলমাত্র অল্প সংখ্যক ব্যবহার করার জন্য আপনাকে আপনার ওয়েব সার্ভারটি কনফিগার করতে হবে। আপনার গেম সার্ভারটির আসলে 1 টির বেশি সংযোগের প্রয়োজন নেই, তবে মুষ্টিমেয় থাকার ফলে উপকৃত হতে পারে।

এখন এটির পাশাপাশি, আমি নোএসকিউএল কতটা ভাল পারফর্ম করে এবং রিয়েলটাইম গেমসের জন্য উপযোগী তা সম্পর্কে আমি পড়েছি (আমি ভুল হতে পারি, আমি এখানে পৌঁছানোর জন্য NoSQL শিখা যুদ্ধ বনাম একটি বিশাল আরডিবিএমএস পেরিয়েছি এবং সম্ভবত পুড়ে গেছে)। মূলত, আমি আমার সমস্ত গেমের অবজেক্টের ডেটার জন্য মঙ্গোডিবি ব্যবহার করতে চাই।

এটি কিছুটা মিথ্যা যুক্তি, কারণ কোনও সিস্টেমই দ্রুতগতির রিয়েলটাইম গেমের মূল স্টোর হিসাবে ব্যবহার করার পক্ষে যথেষ্ট দ্রুত নয় - আপনাকে সত্যই মেমোরিতে মূল্যবোধগুলি রাখা এবং পরিচালনা করতে হবে। সুতরাং আপনি কেবল তখনই ডাটাবেসটিকে হিট করেন যখন আপনার পুরো অক্ষরটি প্রায়শই প্রায়শই সংরক্ষণ করা যায় (উদাহরণস্বরূপ: একবারে একবার) একবার, গতির পার্থক্য নগণ্য হয়ে ওঠে।

মজার বিষয়টি হ'ল, আপনি যদি শীর্ষ গতির জন্য মঙ্গোডিবিকে টুইট করেন তবে আপনি কেবলমাত্র একটি বিন্দুতে পৌঁছাতে পারেন যেখানে একটি যুক্তিসঙ্গত দ্রুত গতির গেমের মধ্যে থেকে আপনার কাছে সমকালীন লেখাগুলি সম্পাদন করা যথেষ্ট দ্রুত হবে তবে এটি ব্যয় হবে ডেটা অখণ্ডতা কারণ লেখক বাফার হয়। এর অর্থ হল আপনি হারান একটি ক্র্যাশ ঘটনা ডেটা, তাই সামান্য বিন্দু এ সব লেখ অভিনয় করছিলেন, এবং এটা এখনও ধীর চেয়ে যদি আপনি শুধু মেমরি সম্পাদন করা সঞ্চালিত এবং এটি পরে সংরক্ষিত, যাতে আপনি উভয় বোথ ওয়ার্ল্ডস সবচেয়ে খারাপ পেতে ।

আমার সমস্ত গেমের অবজেক্ট ডেটার জন্য আমি বর্তমানে মঙ্গোডিবি ব্যবহারের কেবলমাত্র কারণেই এই গেমের অবজেক্টের ডেটা কতবার অ্যাক্সেস করা হবে (যেমন যখনই কোনও খেলোয়াড় মারা যায়, কোনও আইটেম তুলে নেয়, বন্দুক চালায় ইত্যাদি))

নিজেকে জিজ্ঞাসা করুন কেন কোনও খেলোয়াড় যখন বন্দুক চালায় তখন আপনাকে ডাটাবেসে কেন লিখতে হবে। কেন এটি কেবল গেম সার্ভারে মেমরির মধ্যে পরিচালনা করা যায় না? যদি আপনার গেমটি ক্র্যাশ হয় এবং পরে পুনরায় চালু হয় এবং প্লেয়ারটি জানতে পারে যে তাদের কাছে প্রত্যাশার চেয়ে ৩ টি বেশি গুলি রয়েছে, তবে এটি কি একটি জটিল সমস্যা?

আমি স্ট্রেট ফরোয়ার্ড স্কিমা-মুক্ত নথিও পছন্দ করি (যা গেম অবজেক্টের ডেটা ম্যাপ করা সহজ করে)।

পারফরম্যান্স ইস্যুর চেয়ে NOSQL পদ্ধতির পছন্দ করার পক্ষে এটি আরও ভাল কারণ।

আমি প্লেয়ার প্রোফাইলের তথ্য প্রদর্শন করার জন্য, আমার ওয়েবসাইটে একই মঙ্গোডিবি ব্যবহার করার ইচ্ছা নিয়েছি (আমি সম্পূর্ণ ধারাবাহিকতায় উদ্বিগ্ন নই, গেম আপডেটগুলি থেকে কিছুটা বিলম্ব করা ঠিক আছে)।

এটা ঠিক, এবং বুদ্ধিমান। পরে আপনি একটি পৃথক উদাহরণ ব্যবহার করতে চাইতে পারেন, যাতে ওয়েব রিডগুলি গেম রিড এবং লেখার সাথে প্রতিদ্বন্দ্বিতা করে না, তবে সমস্যাটি হওয়ার পক্ষে যথেষ্ট জনপ্রিয় হওয়ার সমস্যার তুলনায় সেই সমস্যাটি সমাধান করা খুব তুচ্ছ।

ব্যক্তিগতভাবে আমি কেবলমাত্র দুটি ডাটাবেসের মধ্যে একটি বেছে নেব, যার ভিত্তিতে আমার জন্য কম কাজ হবে, এবং এটি মানক করে তোলা - তবে আপনি পছন্দ করেন তবে দুটি দিয়ে রাখতে পারবেন না এমন কোনও কারণ নেই।


আপনি কি এর জন্য কোনও কাঠামো পরামর্শ দিতে পারেন? "আপনাকে সত্যই স্মৃতিতে মান রাখতে এবং পরিচালনা করতে হবে।" আমি রেডিসের কথা শুনেছি, তবে এর একমাত্র মূল মানের সম্পর্ক, এমন কোনও কি আছে যেখানে আমরা হেরফের করতে পারি?
ব্যবহারকারী 1735921

না, যখন আমি বলি "স্মৃতিতে মানগুলি রাখুন এবং হেরফের করুন" আমি আক্ষরিকভাবে বলছি "গেমটি ভেরিয়েবলগুলিতে সঞ্চিত ডেটা সহ একটি সাধারণ প্রোগ্রামের মতো চলে", কোনও বিশেষ ডাটাবেস স্তর বা কাঠামো হিসাবে নয়।
কাইলোটন

4

সমস্ত বাস্তব সময়ের ডেটা অ্যাপ্লিকেশন মেমোরিতে রাখা দরকার, অন্য যে কোনও কিছু বোকামি হবে।

ব্যবহারকারীদের লগইন ডেটা, পরিসংখ্যান ইত্যাদি রাখা খুব হালকা কাজ, তাই আমি সাহসী হব এবং বলব যে আপনি যা চান তাই ব্যবহার করতে পারেন। যদিও আপনি ওয়েবসাইটটি সম্পর্কে সাবধানতা অবলম্বন করতে চান, ব্যবহারকারী তালিকার মতো স্টাফ যদি আপনি একটি সঠিক ক্যাচিং সিস্টেম না তৈরি করেন তবে অনেকগুলি ডাটাবেস সম্পাদন করতে পারে।

এবং বামমজ্যাক যেমন বলেছিল, আপনার উচিত সমস্ত কিছু একই নেটওয়ার্কে রাখা উচিত। সর্বোপরি, ফ্রি স্টাফ সম্পর্কে সতর্ক থাকুন, 240 এমবি ফ্রি ডাটাবেস স্টোরেজটি ভাল শোনা যায় তবে মেশিনটি সম্ভবত প্রচুর সংখ্যক ফ্রি ব্যবহারকারীদের মধ্যে বিভক্ত হয়ে যাওয়ার কারণে পরিষেবাটি বেশ ধীর হতে পারে।


আমি সম্মত, আপনি আপনার গেমের ডেটা মেমরির মধ্যে রাখতে চান, এবং আপনি পাশাপাশি স্মৃতিতে লগইন ডেটা রাখতে পারেন (তারা খুব ছোট হিসাবে বিবেচনা করে)
মার্কআর

মেমোরিতে কিছু ডেটা না রাখার কারণ (বা কোনও ডেটাবেস হ্যান্ডেল করা যে এটি মেমরি এবং ডিস্ক উভয় ক্ষেত্রেই দেওয়া) হ'ল আপনি চান সার্ভার ক্রাশ হলে ডেটা স্থির থাকে। এটি নিরাপদ করার সবচেয়ে সহজ উপায় এটি একটি ডেটাবেজে সংরক্ষণ করা।
আআআআআআআআআআআআআআআআআআআআআআচআচ

আপনি এখনও অধ্যবসায়ের জন্য একটি ডাটাবেস ব্যবহার করতে পারেন - তবে এখনও মেমরিতে ডেটা রাখুন, আপনার শক্তিশালী ক্রাশ-নিরাপদ স্টোরেজ রয়েছে তবে লগইন ইত্যাদির যাচাইকরণের প্রয়োজন হলে সার্ভার (অন্য ক্রিয়াকলাপগুলি) অবরুদ্ধ করতে না পারার অ্যাক্সেসটি যথেষ্ট দ্রুত access ।
মার্কআর

2

আপনি কি প্রতি ডাটাবেসে আপনার 60,000 ব্যবহারকারীকে বিশ্বাস করেন? যদি তা না হয় তবে আপনার "ক্লায়েন্টের কাছ থেকে ডেটাবেস অ্যাক্সেস" ধারণাটি নিক্স করা উচিত, যদি না আপনার ডাটাবেস সফ্টওয়্যারটির সুরক্ষার ক্ষেত্রে দক্ষতার স্তরটি শীর্ষ-খাঁজ না থাকে এবং আপনি নিশ্চিত যে আপনি যে কোনও সমস্যার সমাধান করতে পারবেন।


9
এবং যদি আপনি এটি সম্পর্কে আত্মবিশ্বাসী হন, তবে আইপসো আপনার ডাটাবেস সুরক্ষার ক্ষেত্রে দক্ষতার স্তরটি শীর্ষস্থানীয় নয়।
23:25
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.