ฐานข้อมูลใด (RDBMS เทียบกับ NoSQL และ BOTH) สำหรับเกม Realtime Multiplayer

ฉันทำงานกับเกมแบบเรียลไทม์ที่จะต้องใช้ฐานข้อมูล (สำหรับคุณสมบัติเช่นโปรไฟล์ผู้เล่นเพื่อนปลดล็อคข่าว ฯลฯ ) เกมนี้เป็นเกมพีซีมาตรฐาน (ไม่ใช่เบราว์เซอร์) และจะใช้ไคลเอนต์เซิร์ฟเวอร์ สถาปัตยกรรม. ฉันยังใหม่กับการใช้ฐานข้อมูลและได้ทำการวิจัยบางอย่างในช่วงไม่กี่วันที่ผ่านมาเมื่อฉันได้พบกับการอภิปรายที่ร้อนแรง: RDBMS vs NoSQL ขณะนี้ฉันกำลังโน้มเอียงไปทาง NoSQL แต่หลังจากอ่านเกี่ยวกับการใช้งานสำหรับแต่ละ (RDBMS และ NoSQL) ฉันก็อยากจะใช้ทั้งสองอย่าง ฉันรู้ว่ามันอาจดูแปลก แต่ขอให้ฉันอธิบายสถานการณ์ของฉัน:

ทีมของฉันมีแพ็คเกจเว็บโฮสติ้งที่ใช้ร่วมกันซึ่งมีพื้นที่เก็บข้อมูลและแบนด์วิดธ์ mySQL ไม่ จำกัด ซึ่งเป็นข้อแม้เดียวที่เราสามารถเปิดได้ 25 การเชื่อมต่อในครั้งเดียว (กฎการโฮสต์ที่ใช้ร่วมกัน) ฉันตั้งใจจะใช้สิ่งนี้กับเว็บไซต์ของฉัน (เป็นการใช้งานทั่วไปอย่างไม่ต้องสงสัย) เพื่อโพสต์การอัปเดตข่าวสนับสนุนคุณลักษณะของชุมชน (เช่นความคิดเห็นการอัปโหลดภาพหน้าปกของแฟน ๆ ฯลฯ ) และอื่น ๆ นั่นคือทั้งหมดที่ดีและดี - แต่! นี่คือสิ่งที่น่าสนใจ ... ฉันต้องการแสดงข้อมูลเดียวกันนี้ที่โพสต์บนเว็บไซต์ของฉันในเกม นี่หมายถึงการใช้ mySQL สำหรับทั้งเว็บไซต์และเกมของฉัน นอกจากโพสต์ข่าวและสิ่งที่ชอบฉันวางแผนที่จะใช้มันในเกมสำหรับสิ่งต่าง ๆ เช่นการแชทและรายชื่อเซิร์ฟเวอร์ ฉันกังวลว่ากฎการเชื่อมต่อ 25 นั้นส่วนใหญ่

ซึ่งทำให้ฉันถามคำถาม # 1: งานนี้และจะมีทางเลือกที่ดีกว่า

ตอนนี้นอกจากนี้ฉันได้อ่านแล้วว่า NoSQL ทำงานได้ดีเพียงใดและเหมาะกับเกมเรียลไทม์ (ฉันอาจผิดฉันได้เดินผ่านสงครามเปลวไฟขนาดใหญ่กับ RDBMS vs NoSQL เพื่อมาที่นี่และอาจถูกไฟไหม้) โดยทั่วไปฉันต้องการใช้ MongoDB สำหรับข้อมูลวัตถุเกมทั้งหมดของฉัน

และอีกครั้งจะเป็นประโยชน์ถ้าฉันให้บริบท: ฉันได้พบโฮสต์ (MongoLab) ซึ่งมีแพ็คเกจ MongoDB 240MB ฟรีซึ่งฉันตั้งใจจะใช้จนกว่าจะจำเป็นต้องอัปเกรด ด้วยขนาด 240MB ฉันได้คำนวณว่าฉันจะสามารถเก็บผู้เล่นได้ประมาณ 60,000 คน (หากผู้เล่นแต่ละคนมีระดับ 4KB โดยประมาณและเราไม่สนใจสิ่งอื่น ๆ ที่อาจถูกจัดเก็บไว้) พื้นที่เก็บข้อมูลและการจ่ายเงินเพิ่มเติมในอนาคต (เกมของเราควรประสบความสำเร็จ) ไม่เป็นปัญหา เหตุผลเดียวที่ฉันตั้งใจจะใช้ MongoDB สำหรับข้อมูลวัตถุในเกมทั้งหมดของฉันคือเพราะความถี่ในการเข้าถึงข้อมูลวัตถุเกมนี้ (เช่นเมื่อใดก็ตามที่ผู้เล่นถูกฆ่าตายหยิบรายการยิงปืน ฯลฯ ) ฉัน เช่นเดียวกับเอกสารที่ปราศจากสกีมาตรงไปข้างหน้า (ซึ่งทำให้ง่ายต่อการจับคู่ข้อมูลวัตถุในเกม) ฉันควรทราบว่าในครั้งเดียว

ฉันตั้งใจจะใช้ MongoDB เดียวกันในเว็บไซต์ของฉันเพื่อแสดงข้อมูลโปรไฟล์ของผู้เล่น (ฉันไม่ได้กังวลกับความสอดคล้องที่สมบูรณ์การล่าช้าในการอัปเดตในเกมนั้นใช้ได้) ข้อใดทำให้ฉันถึงคำถามที่สองคำถาม # 2: นี่เป็นความคิดที่ดีหรือมีบางสิ่งที่ดีกว่าที่ฉันควรทำ

เกมดังกล่าวจะมีประสบการณ์เริ่มต้นในลักษณะนี้:

1. ลูกค้าเข้าสู่ระบบ (MongoDB)
2. ลูกค้าอยู่ที่หน้าแรกของเกมพร้อมห้องสนทนา (MySQL)
3. ลูกค้าไปที่รายชื่อเซิร์ฟเวอร์ (MySQL)

4. ลูกค้าเชื่อมต่อกับเซิร์ฟเวอร์และเล่นกับมัน

5. เซิร์ฟเวอร์สื่อสารการอัพเดทสำหรับผู้เล่นทุกคน (MongoDB)

นี่เป็นเพียงวิธีที่ฉันจินตนาการว่ามันจะได้ผล สิ่งนี้ดูดีสำหรับคุณหรือคุณมีคำแนะนำเกี่ยวกับวิธีการปรับปรุงแผนนี้หรือไม่?

คำแนะนำของฉันคือให้เกมของคุณสื่อสารกับเว็บเซอร์วิสที่คุณสร้างขึ้นเองซึ่งเกี่ยวข้องกับการสืบค้นฐานข้อมูล ณ จุดนั้นมันง่ายมากที่จะลองใช้ฐานข้อมูลประเภทต่าง ๆ โดยการ "ปรับใช้" การให้บริการเว็บ (การใช้งานอินเตอร์เฟซบริการเว็บของคุณจะยังคงเหมือนเดิมเสมอเพื่อให้เกมของคุณไม่หยุด) และตัดสินใจว่าอันไหนเหมาะกับคุณ

นอกจากนี้ยังปลอดภัยกว่ามากหากไม่เปิดเผยฐานข้อมูลของคุณกับอินเทอร์เน็ตโดยตรง

เราสามารถเปิดได้ 25 การเชื่อมต่อในครั้งเดียว (กฎการโฮสต์ที่ใช้ร่วมกัน)

นั่นเกินพอสำหรับเกมของคุณ ปัญหาคือหากเว็บไซต์ของคุณใช้การเชื่อมต่อหลายรายการคุณอาจหมด คุณต้องกำหนดค่าเว็บเซิร์ฟเวอร์ของคุณให้ใช้เพียงจำนวนเล็กน้อยเท่านั้นโดยเหลือให้เซิร์ฟเวอร์เกมของคุณ เซิร์ฟเวอร์เกมของคุณไม่ต้องการการเชื่อมต่อมากกว่า 1 แต่อาจได้รับประโยชน์จากการหยิบ

ตอนนี้นอกจากนี้ฉันได้อ่านแล้วว่า NoSQL ทำงานได้ดีแค่ไหนและเหมาะกับเกมเรียลไทม์ (ฉันอาจผิดฉันได้เดินผ่านสงครามเปลวไฟขนาดใหญ่ RDBMS กับ NoSQL เพื่อมาที่นี่และอาจถูกเผา) โดยทั่วไปฉันต้องการใช้ MongoDB สำหรับข้อมูลวัตถุเกมทั้งหมดของฉัน

มันเป็นข้อโต้แย้งที่ผิดพลาดเล็กน้อยเนื่องจากระบบไม่เร็วพอที่จะใช้เป็นที่เก็บหลักสำหรับเกมเรียลไทม์ที่รวดเร็วคุณต้องเก็บและจัดการค่าในหน่วยความจำ ดังนั้นคุณจะไปที่ฐานข้อมูลเมื่อคุณจำเป็นต้องทำอย่างแน่นอนซึ่งอาจเป็นการบันทึกอักขระทั้งหมดทุก ๆ ครั้ง (เช่นหนึ่งครั้งต่อนาที) ซึ่งเป็นจุดที่ความแตกต่างของความเร็วกลายเป็นเล็กน้อย

สิ่งที่ตลกคือถ้าคุณปรับแต่ง MongoDB เพื่อความเร็วสูงสุดคุณสามารถไปถึงจุดที่มันจะเร็วพอสำหรับคุณที่จะทำการเขียนแบบซิงโครนัสจากภายในเกมที่เล่นได้อย่างรวดเร็ว ของความถูกต้องของข้อมูลเนื่องจากการเขียนถูกบัฟเฟอร์ นี่หมายความว่าคุณสูญเสียข้อมูลนั้นในกรณีที่เกิดการขัดข้องดังนั้นจึงมีจุดเล็ก ๆ ในการเขียนและมันก็ยังช้ากว่าถ้าคุณเพิ่งแก้ไขหน่วยความจำและบันทึกไว้ในภายหลังดังนั้นคุณจึงแย่ที่สุดทั้งโลก .

เหตุผลเดียวที่ฉันตั้งใจจะใช้ MongoDB สำหรับข้อมูลวัตถุในเกมทั้งหมดของฉันนั้นเป็นเพราะความถี่ในการเข้าถึงข้อมูลวัตถุเกม (เช่นเมื่อใดก็ตามที่ผู้เล่นถูกฆ่าตายหยิบสิ่งของยิงปืน ฯลฯ )

ถามตัวเองว่าทำไมคุณต้องเขียนไปยังฐานข้อมูลเมื่อผู้เล่นยิงปืน เหตุใดจึงไม่สามารถจัดการหน่วยความจำภายในเซิร์ฟเวอร์เกมไม่ได้ หากเกมของคุณล้มเหลวและเริ่มใหม่ในภายหลังและผู้เล่นพบว่าพวกเขามีกระสุนมากกว่าที่พวกเขาคาดว่าจะมี 3 กระสุนนั่นเป็นปัญหาทางธุรกิจที่สำคัญหรือไม่?

ฉันชอบเอกสารที่ปราศจากสคีมาตรงไปตรงมา (ซึ่งทำให้ง่ายต่อการจับคู่ข้อมูลวัตถุในเกม)

นี่เป็นเหตุผลที่ดีกว่ามากในการเลือกวิธี NOSQL มากกว่าปัญหาด้านประสิทธิภาพ

ฉันตั้งใจจะใช้ MongoDB เดียวกันในเว็บไซต์ของฉันเพื่อแสดงข้อมูลโปรไฟล์ของผู้เล่น (ฉันไม่ได้กังวลกับความสอดคล้องที่สมบูรณ์การล่าช้าในการอัปเดตในเกมนั้นใช้ได้)

ไม่เป็นไรและมีเหตุผล หลังจากนั้นคุณอาจต้องการใช้อินสแตนซ์แยกต่างหากเพื่อให้เว็บอ่านไม่ได้แข่งขันกับเกมอ่านและเขียน แต่ปัญหานั้นเป็นปัญหาเล็กน้อยในการแก้ไขเมื่อเทียบกับปัญหาของการได้รับความนิยมมากพอที่จะเป็นปัญหา

โดยส่วนตัวแล้วฉันจะเลือกหนึ่งในสองฐานข้อมูลตามที่จะทำงานให้ฉันได้น้อยลงและสร้างมาตรฐานให้กับมัน - แต่ไม่มีเหตุผลที่คุณจะเก็บสองฐานไว้ได้หากคุณต้องการ

ข้อมูลเรียลไทม์ทั้งหมดจะต้องถูกเก็บไว้ในหน่วยความจำของแอปพลิเคชันสิ่งอื่น ๆ จะโง่

การเก็บข้อมูลการเข้าสู่ระบบของผู้ใช้สถิติ ฯลฯ เป็นงานที่ค่อนข้างเบาดังนั้นฉันจะกล้าพูดว่าคุณสามารถใช้อะไรก็ได้ที่คุณต้องการ แม้ว่าคุณอาจต้องการที่จะระมัดระวังเว็บไซต์ แต่เนื้อหาในรายการผู้ใช้อาจทำให้ประสิทธิภาพของฐานข้อมูลแย่ลงหากคุณไม่สร้างระบบแคชที่เหมาะสม

และอย่างที่ bummzack พูดคุณควรเก็บทุกอย่างไว้ในเครือข่ายเดียวกัน ยิ่งไปกว่านั้นระวังเกี่ยวกับสิ่งต่าง ๆ ฟรีพื้นที่จัดเก็บฐานข้อมูล 240 MB ฟรีฟังดูดี แต่เนื่องจากเครื่องอาจแยกระหว่างบริการผู้ใช้ฟรีจำนวนมากอาจช้า

คุณเชื่อใจผู้ใช้ 60,000 คนต่อฐานข้อมูลหรือไม่? ถ้าไม่คุณควรระวัง "การเข้าถึงฐานข้อมูลจากไคลเอนต์" นอกจากระดับความเชี่ยวชาญของคุณในด้านความปลอดภัยของซอฟต์แวร์ฐานข้อมูลนั้นอยู่ในอันดับต้น ๆ และคุณมั่นใจว่าคุณสามารถรองรับปัญหาใด ๆ ที่เกิดขึ้นได้