noSQL - มันเป็นตัวเลือกที่ถูกต้องสำหรับเกมบนเว็บ? [ปิด]

20

จากโอกาสและความเบื่อหน่ายเพื่อนและฉันตัดสินใจทำเกมบนเว็บ นี่เป็นเกมแรกที่ฉันจะทำเพราะปกติฉันจะตั้งโปรแกรมเว็บแอพใน django

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

ดังนั้นฉันมีคำถามต่อไปนี้:

  • noast datastorage (ตามเอกสารเช่น MongoDB) จะเหมาะสำหรับเกมบนเว็บหรือไม่?
  • ปัญหาที่อาจเกิดขึ้นจากการใช้ RDBMS ทั่วไปเช่น MySQL มีอะไรบ้าง
  • วิธีการประกันความสอดคล้องของข้อมูลระหว่างผู้ใช้กับ MongoDB ในระหว่างการเล่นเกมหรือในเหตุการณ์ที่กำหนดเวลาเช่นงาน cron

ภาพรวมของเกม: เกมผจญภัยทั่วไปที่ผู้เล่นต่อสู้กับมอนสเตอร์และได้รับไอเทมและสิ่งต่าง ๆ

  • ข้อมูลบางอย่างคงที่ในผู้เล่นทุกคน: รายการอาวุธยาพิษแผนที่ ฯลฯ
  • ข้อมูลบางอย่างที่เชื่อมโยงกับโปรแกรมเล่น: สินค้าคงคลังตัวชี้วัด (สถิติ) ความคืบหน้า ฯลฯ
  • ผู้เล่นอาจจำเป็นต้องรู้สถิติและสถานะของผู้เล่นอื่น
  • งานที่กำหนดเวลาไว้จะถูกเรียกใช้ในบางช่วงเวลา
architecture  web  python  databases 
— ปราณ
แหล่งที่มา
ที่เกี่ยวข้อง: gamedev.stackexchange.com/questions/2282/…
— Ricket
1
ปัญหาเกี่ยวกับฐานข้อมูล noSQL บางอย่างคือพวกเขาไม่สามารถทำการสืบค้นที่ไม่มีการคาดเดาเวลา "ออกแบบ" ในวิธีที่รวดเร็วบนชุดข้อมูลขนาดใหญ่เช่นบันทึกเหตุการณ์: gamedev.stackexchange.com/q/4465/450 โปรดทราบว่าฐานข้อมูล noSQL นั้นต้องการสิ่งเดียวกัน เทคนิคกับการฉีดแบบสอบถามปกติกว่าฐานข้อมูลปกติทำ
— Hendrik Brummermann
1
@nhnb: วิธีที่ดีในการเรียกคืนจุดของคุณคือ "ใช้ฐานข้อมูลเชิงสัมพันธ์สำหรับข้อมูลความสัมพันธ์และใช้ฐานข้อมูลวัตถุ / เอกสารสำหรับข้อมูลวัตถุ / เอกสาร" น่าเสียดายที่ฉันไม่คิดว่าคนส่วนใหญ่มีประสบการณ์กับหรือใช้เวลาคิดเกี่ยวกับการสร้างแบบจำลองซึ่งนำไปสู่การออกแบบที่ไม่ดีไม่ว่าพวกเขาจะเลือก
2
เพื่อตอบคำถามของคุณ "NoSQL เป็นตัวเลือกที่ถูกต้องสำหรับเกมบนเว็บหรือไม่" ฉันเชื่อว่าคำตอบคือใช่ มีการใช้ฐานข้อมูล NoSQL สำหรับเกมบนเว็บมาก่อน (เช่น FarmVille) และให้ความยืดหยุ่นสูง ประเด็นหลักของการโต้แย้งสำหรับคำถามนี้น่าจะเป็น "ซึ่งดีกว่า (NoSQL หรือ SQL)" แต่ละระบบมีข้อดีข้อเสีย แต่ทั้งคู่เป็นตัวเลือกที่ถูกต้องสมบูรณ์แบบ หากคุณกำลังมองหารายการโดยละเอียดเกี่ยวกับข้อดีของระบบหนึ่งเหนืออีกระบบคุณอาจต้องจ่ายโปรแกรมเมอร์ Vortex StackExchange :)
— Ari Patrick

คำตอบ:

21

ฐานข้อมูล NoSQL จะเหมาะสำหรับการเล่นเกมบนเว็บ?

แน่นอน! โดยทั่วไปแล้วฐานข้อมูลที่ไม่เกี่ยวข้อง (เช่น MongoDB) จะดีกว่ามากสำหรับเกมเนื่องจากมีความยืดหยุ่นในการสร้างแบบจำลองข้อมูลในขณะที่มีประสิทธิภาพมากกว่าฐานข้อมูลเชิงสัมพันธ์ (เช่น SQL) ทำให้พวกเขาเป็น "win-win" ทางเลือก.

อะไรคือปัญหาที่อาจเกิดขึ้นโดยใช้ RDBMS ธรรมดา?

มีสองข้อเสียเปรียบที่สำคัญในการใช้ฐานข้อมูลเชิงสัมพันธ์:

  • ขาดความยืดหยุ่นในแบบที่คุณสร้างข้อมูล
  • ประสิทธิภาพ

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

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

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

  • เพิ่มประเภทรายการใหม่
  • สร้างอาวุธที่มีอาวุธหลายประเภท
  • สร้างรายการยาที่สามารถใช้เป็นอาวุธได้

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

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

db.itemTypes

name: Weapon
types: Sharp

name: Potion
types: HP, Mana

db.items

name: Short Sword
weapon
    type: Sharp (db.itemTypes reference)
    damage: 5

name: Healing Elixer
potion
    type:  HP (db.itemTypes reference)
    modifier: 5

name: Mana Drainer
potion
    type:  Mana (db.itemTypes reference)
    modifier: -5  

name:  Healing Potion Sword
potion
    type: HP (db.itemTypes reference)
    modifier: 10
weapon
    type: Sharp (db.itemTypes reference)
    damage: 15

มีจำนวนมากของบทความที่ดีในการทำงานของ NoSQL เทียบกับฐานข้อมูล SQL มี แต่ที่นี่เป็นหนึ่งซึ่งมีตัวอย่างการประยุกต์เพื่อให้คุณสามารถดำเนินการทดสอบของคุณเอง: MongoDB กับ SQL Server 2008 ผลการดำเนินงานแบไต๋

ฉันจะประกันความสอดคล้องของข้อมูลระหว่างผู้ใช้กับ MongoDB ได้อย่างไร

MongoDB รองรับการอ่าน / เขียนการดำเนินการปรมาณูในเอนทิตีข้อมูลเดียว (เอกสาร) ดังนั้นผลการสืบค้นจาก MongoDB ควรถูกต้องเสมอกับสิ่งที่เก็บไว้ในฐานข้อมูล

แก้ไข:จัดเตรียมตัวอย่าง NoSQL ของฐานข้อมูลรายการ

— อารีย์แพทริค
แหล่งที่มา
ในตัวอย่างที่คุณเขียนโดยใช้ SQL, วิธีการที่คุณจะในระดับสูงรูปแบบโดยใช้ NoSQL?
— ปราณ
4
-1 คำตอบของคุณแสดงเฉพาะข้อมูลสแตติก การอภิปรายทั้งในช่วง SQL กับ NoSQL สำหรับฐานข้อมูลเกมที่เกี่ยวข้องกับข้อมูลแบบไดนามิกสูง สิ่งที่ดีที่สุดที่จะทำจะแสดงการทำธุรกรรมการซื้อขาย NoSQL ว่าบางสิ่งบางอย่างระหว่างสองผู้เล่น - ธรรมดาที่เกิดขึ้นมากและเป็นหนึ่งในเกมส่วนใหญ่ได้รับความผิดพลาดโดยไม่คำนึงถึงประเภทที่พวกเขาเลือก
3
@Ari: มีข้อมูลจำนวนมากคงที่มากขึ้น แต่ไม่มีใครใส่ใจเกี่ยวกับการส่งผ่านสำหรับการเขียนไปเพราะไม่มีใครเขียนไป - ไม่มีการเขียน, การทำธุรกรรมไม่มีกรดคำถามที่ไม่มีฐานข้อมูลจริงแม้ว่าคุณจะเกิดเก็บไว้ ในหนึ่ง คำถามที่เป็นเรื่องง่ายที่จะแล้วคำตอบ - เพียงแค่เก็บไว้ในหน่วยความจำ แน่นอน "เราจะโหลดข้อมูลสแตติกได้เร็วขึ้นอย่างไร" เป็นคำถามที่น่าสนใจ แต่ผมไม่คิดว่ามันจะอยู่ที่ทั้งหมดที่เกี่ยวข้องกับคำถามของ SQL เทียบกับ NoSQL - ในฐานะที่เป็นสำหรับการดำเนินงานหลายเอกสารนี้หมายความว่าฐานข้อมูลของคุณจะมีเอกสารหนึ่งด้วยเช่นผู้เล่นทุกคนในนั้น?
2
@Ari: โปรดอย่าสับสน NoSQL ซึ่งเป็นความคิดและ MongoDB ซึ่งเป็นฐานข้อมูลโดยเฉพาะอย่างยิ่ง ในงานล่าสุดของฉันเราส่งสองเกมบนฐานข้อมูล NoSQL และได้ดีเยี่ยมเห็นพ้องด้วยความหน่วงต่ำ แต่ฐานข้อมูล NoSQL ของเรายังได้รับการสนับสนุนการทำธุรกรรมหลายเอกสารที่มีระดับฟิลด์ล็อค NoSQL ไม่ได้เป็นคนเดียว "สิ่งที่" ชอบ SQL มันก็หมายถึงฐานข้อมูลใด ๆ ที่ไม่ใช้ SQL (และมักจะไม่ได้ใช้แผนการสัมพันธ์)
5
เพียงแค่ฉัน $ 0.02 แต่ "ไม่ performant" ไม่ได้เป็นข้อเสียเปรียบของ RDBMS มันเป็นข้อเสียเปรียบในการจัดเก็บข้อมูลที่ไม่สัมพันธ์ใน RDBMS ไม่จูน RDBMS ของคุณไม่เข้าใจสิ่งที่ SQL ของคุณจะทำไม่ได้จัดทำดัชนี ฯลฯ ฯลฯ ฯลฯ หากคุณมีข้อมูลเชิงสัมพันธ์คุณจะพบ RDBMSes จะเพิ่มประสิทธิภาพอย่างไม่น่าเชื่อ
— Robbie
19

สองสามคำปกป้องฐานข้อมูล SQL

1 - หากคุณมีฐานข้อมูล SQL คุณสามารถทำงานกับข้อมูลของคุณไม่เพียง แต่โดยคีย์หลัก ส่วนใหญ่แบบสอบถามใน MMO ไปโดย PK แต่เมื่อคุณต้องไปหาผู้ใช้ทุกคนที่มีระดับ> 30 สิ่งที่คุณจะทำใน NoSQL โลก?

2 - หากคุณมีภาษา SQL คุณสามารถสร้าง "โปรแกรมแก้ไขด่วน" เพื่อซ่อมแซมข้อมูลที่เสียหาย ตัวอย่างเช่น: "update player_items set flag = 0 โดยที่ item_type_id = 100" คุณจะแก้ไขใน NoSQL ได้อย่างไร? ฉันคิดว่าคุณจะต้องสร้างสคริปต์ที่จะวิเคราะห์ข้อมูลทั้งหมดของคุณ ...

3 - ฐานข้อมูล SQL นั้นไม่ช้าอย่างที่คิด เพื่อนร่วมงานของฉันสร้างเกม MMO บนเว็บซึ่งทำธุรกรรมได้ 5,000 รายการต่อวินาทีใน MySQL มันไม่เพียงพอสำหรับคุณ หากไม่เป็นเช่นนั้นคุณอาจใช้การแบ่งส่วนเพื่อปรับขนาดฐานข้อมูลของคุณ

4 - SQL มีข้อ จำกัด ของ foreign key และสิ่งที่ดีเช่นนั้นซึ่งจะช่วยให้คุณค้นหาข้อบกพร่องในรหัสของคุณ

NoSQL ไม่ใช่ bullet เงิน มันแก้ปัญหาเพียงไม่กี่ข้อเท่านั้นและนำปัญหาใหม่ ๆ มาให้ ดังนั้นคำแนะนำของฉัน - คิดสองครั้งก่อนเลือก NoSQL

— Andrey Frolov
แหล่งที่มา
1
ทั้งหมดนี้เป็นเหตุผลที่ดีในการหลีกเลี่ยง NoSQL จนกว่าคุณจะต้องการมัน โดยเฉพาะอย่างยิ่ง # 3 ถ้าคุณไม่มีผู้ใช้ zillions อยู่แล้ว (และปฏิเสธที่จะทิ้งสิ่งใด) คุณก็จะมีประสิทธิภาพมากขึ้นด้วย MySQL
— ojrac
5
1. คุณควรใช้: "สำหรับ x ใน db.user.find ({" level ": {" $ gt ": 30}})" 2. ในทางเทคนิคสิ่งที่คุณเขียนก็เป็นสคริปต์เช่นกันดังนั้นฉัน ไม่แน่ใจว่าสิ่งที่จุดของคุณ 3. เป็นไปได้มากที่จะสร้าง MMO โดยใช้ SQL และในความเป็นจริง MMO จำนวนมากได้รับการพัฒนาโดยใช้เทคโนโลยี เทคโนโลยี NoSQL นั้นค่อนข้างใหม่และได้รับการยอมรับจากบริการต่างๆเช่น Amazon, Google และ Facebook เพื่อประสิทธิภาพและความยืดหยุ่น 4. ใน NoSQL คุณจะต้องเขียนข้อ จำกัด ของคุณเอง แต่นั่นเป็นเพียงต้นทุนของความยืดหยุ่นที่เพิ่มขึ้น
— อารีย์แพทริค
2
ผมเห็นด้วยกับคำสั่งของคุณของความคิดสองครั้ง นั่นเป็นบางส่วนสิ่งที่ฉันทำนี่กับคำถามนี้ :)
— ปราณ
10
SQL ไม่ได้เป็นกระสุนเศษไม้ NoSQL ไม่ใช่ bullet เงิน คิดว่าสองครั้งก่อนที่จะใช้เทคโนโลยีใด ๆ
— stonemetal
5
เกี่ยวกับ 3 ปัญหาไม่ได้มากว่า SQL เป็นช้าแต่ที่ SQL เป็นlaggy โดยทั่วไปฐานข้อมูล SQL จะได้รับปริมาณงานที่ยอดเยี่ยมโดยค่าใช้จ่ายในการตอบสนอง สำหรับเกมบนเว็บนั่นอาจเป็นสิ่งที่คุณต้องการ! สำหรับเกมเครือข่ายแบบเรียลไทม์มันอาจจะไม่และ MMO แบบ "WoW-like" ส่วนใหญ่ที่ใช้ SQL จะใช้เลเยอร์แคชที่อยู่ด้านหน้าซึ่งจะกำจัดประโยชน์ส่วนใหญ่ของ SQL ซึ่งเป็นสาเหตุที่ NoSQL เป็นขั้นตอนที่ยิ่งใหญ่สำหรับ พวกเขา
18

คำตอบคือใช่มันเป็นตัวเลือกที่ถูกต้องแต่ไม่มีก็อาจจะไม่ได้เป็นความคิดที่ดี

มีปัญหาหลักสองข้อเกี่ยวกับ SQL ที่ NoSQL พยายามแก้ไขเมื่อพูดถึงเกม

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

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

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

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

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

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

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

— ชุมชน
แหล่งที่มา
1
+1 ขอบคุณสำหรับการเปรียบเทียบตัวเลือกทั้งสอง นอกจากนี้คุณสร้างจุดที่ดีโดยบอกว่าข้อมูลสแตติกไม่ควรอยู่ในฐานข้อมูล
— ปราณ
1
+1 อย่างไรก็ตามฉันคิดว่าคุณละเลยที่จะพูดถึงหนึ่งในข้อดีหลัก (ดี, โปรหรือ con ขึ้นอยู่กับมุมมอง) ของ No SQL ซึ่งเป็น schema-less ซึ่งช่วยให้การจัดเก็บข้อมูลแบบไดนามิกสูง จริง ๆ แล้วฉันจะใช้ทั้งสองอย่างร่วมกันกับโครงการปัจจุบันของฉันกับ PostgreSQL สำหรับสิ่งที่เหมาะกับรูปแบบเชิงสัมพันธ์อย่างมากและ Mongo สำหรับสิ่งกึ่งคงที่ที่ไม่มี (ตัวอย่างเช่นบันทึกที่สามารถใช้ในการสร้างการเล่นซ้ำโดยที่ฉันต้องมีคอลัมน์ที่เก็บ PK จากหนึ่งในตารางอื่น ๆ หรือตารางที่มีชื่อคอลัมน์ทั่วไปเช่น param1 param2)
— Davy8
1
@ Davy88: NoSQL ไม่จำเป็นต้องเป็นสคีน้อยและมี "แบบไดนามิกสูง" ฐานข้อมูลไม่ได้จริงๆเป็นบวก หากสิ่งที่คุณมีคือ data data คุณไม่สามารถทำดัชนีได้คุณไม่สามารถล็อกระดับฟิลด์ได้และแม้แต่แบบสอบถามแบบง่ายก็จะเต็มไปด้วยคำถามเกี่ยวกับสิ่งที่เกิดขึ้นหากไม่มีคีย์
@ user744 สิ่งที่คุณพูดถึงทำให้สำเร็จคืออะไร?
— หมดอายุ
5
  • noast datastorage (ตามเอกสารเช่น MongoDB) จะเหมาะสำหรับเกมบนเว็บหรือไม่?

ฉันแนะนำให้ดูที่couchdb

อินเทอร์เฟซของมันทำงานบน javascript ดังนั้นมันจะผสมผสานกันได้ดีกับเกมที่ใช้ HTML5 / javascript

นอกจากนี้ยังสามารถทำงาน 'ออฟไลน์' (การทำสำเนาโลคัลของ db) จากนั้นซิงโครไนซ์ตัวเองกับเซิร์ฟเวอร์ในภายหลัง (คุณอาจใช้สิ่งนี้กับดันเจี้ยนอินสแตนซ์ตัวอย่าง)

  • ปัญหาที่อาจเกิดขึ้นจากการใช้ RDBMS ทั่วไปเช่น MySQL มีอะไรบ้าง

ปัญหาหลักคือฐานข้อมูลที่ไม่มี sql นั้นจัดการได้ค่อนข้างแตกต่างจากฐานข้อมูลเชิงสัมพันธ์ การเปลี่ยนจิตอาจเป็นเรื่องยาก

ยกตัวอย่างเช่นดูที่วิธีการที่ " คำสั่ง " จะทำใน CouchDB ทุกอย่างทำในรูปแบบจาวาสคริปต์

  • วิธีการประกันความสอดคล้องของข้อมูลระหว่างผู้ใช้กับ MongoDB ในระหว่างการเล่นเกมหรือในเหตุการณ์ที่กำหนดเวลาเช่นงาน cron

กระบวนการของฐานข้อมูล 'การซิงโครไนซ์' เรียกว่าการจำลองแบบในศัพท์แสงของ couchdb คุณจะเห็นคำว่าสอดคล้องมาก มีบริการในตัวหลายอย่างที่จัดการกับการจำลองแบบ & ความสอดคล้อง ดูตัวอย่างกระบวนการจำลองแบบส่วนเพิ่ม

— egarcia
แหล่งที่มา
ใช่ฉันเคยได้ยินเกี่ยวกับ couchdb เช่นกันในความเป็นจริงแม้แต่บนเว็บไซต์ของ mongodb พวกเขามักจะทำการเปรียบเทียบกับมัน ฉันคิดว่าฉันต้องวิจัยเกี่ยวกับ couchdb กับ mongodb
— ปราณ
2

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

แผนที่ดีกว่าที่จะบันทึกใน NoSQL (พิกัด => อาร์เรย์ของวัตถุที่แตกต่างกันเป็นต้น) ฉันไม่คิดว่าจะบันทึกสิ่งที่พื้นที่มีใน RDB (ยกเว้นสตริงที่ต่อเนื่องซึ่งคุณต้อง unserialize อย่างเต็มที่เพื่ออ่านส่วนหนึ่งของ CPU เพิ่มเติม และ RAM สูญเปล่า!) คุณยังสามารถบันทึกพื้นที่ใน RDB ได้เช่นพื้นที่ "city X" มี cordinates / block ดังต่อไปนี้ ([3,4], [8,7] ... )

คุณสามารถและอาจใช้ทั้งสองอย่างและดูที่การจัดเก็บข้อมูลแบบระเหยเช่น memcache ที่คุณอาจต้องการหรือข้อมูลชั่วคราว (จะเร็วกว่าการใช้ฮาร์ดดิสก์อย่างแน่นอน! และช่วยให้คุณประหยัด CPU มาก แต่ไม่แน่ใจว่า RAM)

ดังนั้นในที่สุด>

มันขึ้นอยู่กับสิ่งที่คุณต้องการมีในเกมของคุณ! cheerz

— Ronan Dejhero
แหล่งที่มา
ซึ่งคุณสมบัติที่คุณคิดว่าจะลากคุณมากยิ่งขึ้นใน NoSQL หรือติดตาชั้นที่ผมอยากจะคิดว่ามันได้หรือไม่
— หมดอายุใน
1
อาจเป็นระบบพิกัดถ้าหากเกมของคุณเป็นระบบ gps จะต้องมีการค้นหาขั้นสูง โดยทั่วไปถ้า youre ดีกับ MySQL แล้วติดมันจะเป็นไปได้ที่จะใช้เป็น NoSQL เช่นกัน
— โรนัน Dejhero
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.