noSQL - Ist es eine gültige Option für webbasiertes Spiel? [geschlossen]

20

Aus einer Gelegenheit und Langeweile heraus beschlossen ein Freund und ich, ein webbasiertes Spiel zu machen. Dies ist das erste "Spiel", das ich machen werde, da ich normalerweise Web-Apps in Django programmiere.

Ich habe mich für die Verwendung des gleichen Frameworks für das Spiel entschieden, bin mir jedoch hinsichtlich der Datenspeicherung nicht ganz sicher, da ich zukünftige Anforderungen und DB-bezogene Probleme nicht vorhersehen kann. In letzter Zeit gewinnt die noSQL-Bewegung an Kraft und ich möchte diesen Bereich erkunden.

Deshalb habe ich folgende Fragen:

  • Wäre ein noSQL-Datenspeicher (dokumentbasiert wie MongoDB) für ein webbasiertes Spiel geeignet?
  • Welche Probleme können bei der Verwendung eines herkömmlichen RDBMS wie MySQL auftreten?
  • Wie kann die Konsistenz von Versicherungsdaten zwischen Benutzern mit MongoDB, während des Spiels oder bei zeitgesteuerten Ereignissen, wie z. B. Cron-Jobs, sichergestellt werden?

Spielübersicht: Typisches Abenteuerspiel, bei dem der Spieler gegen Monster kämpft und Gegenstände und dergleichen erhält.

  • Einige Daten sind für alle Spieler statisch: Gegenstände, Waffen, Tränke, Karten usw.
  • Einige Daten, die an den Player gebunden sind: Inventar, Metriken (Statistiken), Fortschritt usw.
  • Ein Spieler muss möglicherweise die Statistiken und den Status eines anderen Spielers kennen
  • Geplante Aufgaben werden in bestimmten Zeitintervallen ausgeführt
Pran
quelle
1
Ein Problem mit einigen NoSQL - Datenbanken ist , dass sie keine Abfragen bei „Design“ Zeit auf eine schnelle Art und Weise auf große Datenmengen wie Ereignisprotokolle unpredicted tun können: gamedev.stackexchange.com/q/4465/450 Beachten Sie bitte , dass NoSQL - Datenbanken die gleiche erfordern Techniken gegen Query Injection normal als normale Datenbanken.
Hendrik Brummermann
1
@nhnb: Eine gute Möglichkeit, Ihren Punkt zu wiederholen, besteht darin, "eine relationale Datenbank für Beziehungsdaten und eine Objekt- / Dokumentdatenbank für Objekt- / Dokumentdaten zu verwenden". Leider glaube ich nicht, dass die meisten Leute Erfahrung mit dem Modellieren haben oder viel Zeit damit verbringen, sich damit zu beschäftigen, was zu schlechten Designs führt, egal welche Wahl sie treffen.
2
Antwort auf Ihre Frage "Ist NoSQL eine gültige Option für webbasierte Spiele?" Ich glaube die Antwort ist ja. NoSQL-Datenbanken wurden zuvor für webbasierte Spiele (wie FarmVille) verwendet und bieten viel Flexibilität. Der Hauptstreitpunkt für diese Frage scheint zu sein: "Was ist besser (NoSQL oder SQL)?". Jedes System hat Vor- und Nachteile, aber beide sind absolut legitime Optionen. Wenn Sie nach einer detaillierten Liste der Vorteile eines Systems gegenüber dem anderen suchen, sollten Sie dem Programmierer StackExchange einen Besuch abstatten. :)
Ari Patrick

Antworten:

21

Wäre eine noSQL-Datenbank für ein webbasiertes Spiel geeignet?

Absolut! Im Allgemeinen sind nicht-relationale Datenbanken (wie MongoDB) für Spiele viel besser geeignet, da sie flexibler in der Modellierung von Daten sind und gleichzeitig eine höhere Leistung als relationale Datenbanken (wie SQL) aufweisen - was sie zu einer "Win-Win" -Datei macht. Wahl.

Welche Probleme können bei der Verwendung eines herkömmlichen RDBMS auftreten?

Die Verwendung relationaler Datenbanken hat zwei Hauptnachteile:

  • Fehlende Flexibilität bei der Modellierung von Daten
  • Performance

Die mangelnde Flexibilität bei der Modellierung von Daten ist ein großer Nachteil, da Sie bei Verwendung einer relationalen Datenbank gezwungen sind, Daten so zu modellieren, dass sie den Anforderungen der Datenbank entsprechen, anstatt dass die Datenbank den Anforderungen des Modells entspricht. Angenommen, Sie erstellen ein Modell für das Speichern von Objekten in einem Spiel mithilfe einer relationalen Datenbank und entscheiden sich für das folgende Modell:

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

Überlegen Sie nun, wie Sie das Modell ändern müssen, um die folgenden Anforderungen zu erfüllen:

  • Fügen Sie einen neuen Artikeltyp hinzu
  • Erstellen Sie eine Waffe mit mehreren Waffentypen
  • Erstellen Sie einen Trank, der auch als Waffe verwendet werden kann

Sicher sind all diese Aktionen machbar, aber Sie werden nicht die glücklichste Person sein, wenn Sie sie machen, und Sie werden sich wahrscheinlich fragen, "gibt es eine bessere Lösung für das, was ich tun möchte?", Wenn Sie könnten Entwerfen Sie ein flexibleres Modell in einer nicht relationalen Datenbank.

Hinweis: Wenn Sie nicht wissen, wie dokumentbasierte Datenbanken Informationen speichern, lesen Sie diesen Link, bevor Sie fortfahren. Das unten dargestellte Modell wurde entwickelt, um eine ähnliche Logik zu verwenden wie das, was in dem oben genannten Artikel dargestellt wird.

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

Es gibt viele gute Artikel über die Leistung von NoSQL-Datenbanken im Vergleich zu SQL-Datenbanken. Hier finden Sie jedoch einige Anwendungsbeispiele, mit denen Sie Ihre eigenen Tests durchführen können: MongoDB im Vergleich zu SQL Server 2008 Performance Showdown

Wie kann ich mit MongoDB die Datenkonsistenz zwischen Benutzern sicherstellen?

MongoDB unterstützt atomare Lese- / Schreibvorgänge für einzelne Datenentitäten (Dokumente). Daher sollten die Abfrageergebnisse von MongoDB immer mit den in der Datenbank gespeicherten Daten übereinstimmen.

Bearbeiten: Bereitgestelltes NoSQL-Beispiel für eine Artikeldatenbank

Ari Patrick
quelle
In dem Beispiel, das Sie mit SQL geschrieben haben, wie würden Sie es auf hoher Ebene mit NOSQL modellieren?
Pran
4
-1, Ihre Antwort zeigt nur statische Daten. Die gesamte Debatte über SQL vs. NoSQL für Spieledatenbanken beinhaltet hochdynamische Daten. Das Beste wäre, eine NoSQL-Transaktion zu zeigen, bei der zwischen zwei Spielern etwas getauscht wird - ein sehr häufiges Ereignis, und eines der meisten Spiele schlägt fehl, unabhängig davon, welchen Typ sie wählen.
3
@Ari: Es gibt viel mehr statische Daten, aber niemand kümmert sich um den Durchsatz der Schreibvorgänge, weil niemand darauf schreibt - keine Schreibvorgänge, keine Transaktionen, keine ACID, keine echte Datenbankfrage, auch wenn Sie sie gerade speichern in Eins. Diese Frage ist dann leicht zu beantworten - behalten Sie sie einfach im Gedächtnis. Sicher "Wie können wir statische Daten schneller laden?" ist eine interessante Frage, aber ich glaube nicht, dass sie mit Fragen von SQL vs. NoSQL zu tun hat. - Bedeutet dies für Multi-Document-Vorgänge, dass Ihre Datenbank ein Dokument mit z. B. allen Playern enthält?
2
@Ari: Bitte verwechseln Sie nicht NoSQL, was eine Idee ist, und MongoDB, was eine bestimmte Datenbank ist. Bei meinem letzten Job haben wir zwei Spiele in einer NoSQL-Datenbank ausgeliefert und eine hervorragende Parallelität mit geringer Latenz erhalten. Unsere NoSQL-Datenbank unterstützt jedoch auch Transaktionen mit mehreren Dokumenten und Sperren auf Feldebene. NoSQL ist kein "Ding" wie SQL, sondern bezieht sich auf jede Datenbank, die kein SQL verwendet (und normalerweise keine relationalen Schemata verwendet).
5
Nur meine $ .02, aber "nicht performant" ist kein Nachteil von RDBMS. Es ist ein Nachteil, nicht relationale Daten in einem RDBMS zu speichern, Ihr RDBMS nicht zu optimieren, nicht zu verstehen, was Ihr SQL tut, nicht zu indizieren usw. usw. Wenn Sie relationale Daten haben, werden Sie feststellen, dass RDBMS unglaublich optimiert sind.
Robbie
19

Einige Wörter schützen SQL-Datenbanken.

1 - Wenn Sie eine SQL-Datenbank haben, können Sie mit Ihren Daten nicht nur über den Primärschlüssel arbeiten. Die meisten Abfragen in MMO werden von PK durchgeführt, aber wenn Sie alle Benutzer mit Level> 30 suchen müssen, was werden Sie dann in der NoSQL-Welt tun?

2 - Wenn Sie SQL-Sprache haben, können Sie "Hotfixes" erstellen, um beschädigte Daten zu reparieren. Zum Beispiel: "update player_items set flag = 0 wobei item_type_id = 100". Wie können Sie dies in NoSQL beheben? Ich denke, Sie müssen ein Skript erstellen, das alle Ihre Daten analysiert ...

3 - SQL-Datenbanken sind nicht so langsam, wie Sie denken können. Meine Kollegen erstellen das webbasierte MMO-Spiel, das in MySQL 5000 Transaktionen pro Sekunde durchführt. Reicht es dir nicht Wenn nicht, können Sie Ihre Datenbank mithilfe von Sharding skalieren.

4 - SQL hat Fremdschlüsseleinschränkungen und solche guten Dinge, die Ihnen helfen, Fehler in Ihrem Code zu finden.

NoSQL ist keine Wunderwaffe. Es löst nur ein paar Probleme und bringt viele neue Probleme mit sich. Also mein Rat - überlege es dir gut, bevor du dich für NoSQL entscheidest.

Andrey Frolov
quelle
1
Dies sind alles gute Gründe, um NoSQL zu vermeiden, bis Sie tatsächlich einen Bedarf dafür haben. Besonders # 3. Wenn Sie nicht bereits zig Benutzer haben (und sich weigern, irgendetwas zu zerstören), werden Sie mit MySQL wahrscheinlich viel produktiver sein.
Ojrac
5
1. Sie würden verwenden: "für x in db.user.find ({" level ": {" $ gt ": 30}})" 2. Technisch gesehen ist das, was Sie geschrieben haben, auch ein Skript, also bin ich Ich bin mir nicht ganz sicher, was du meinst. 3. Es ist SEHR möglich, ein MMO mit SQL zu erstellen, und tatsächlich wurden viele MMOs mit dieser Technologie entwickelt. Die NoSQL-Technologie ist relativ neu und wurde bereits von Diensten wie Amazon, Google und Facebook aufgrund ihrer Leistung und Flexibilität übernommen. 4. In NoSQL müssten Sie Ihre eigenen Einschränkungen schreiben, aber das ist einfach der Preis für zusätzliche Flexibilität.
Ari Patrick
2
Ich stimme Ihrer Aussage zu, zweimal darüber nachzudenken. Das ist zum Teil das, was ich hier mit dieser Frage tue :)
Pran
10
SQL ist keine Splitterkugel. NoSQL ist keine Wunderwaffe. Überlegen Sie zweimal, bevor Sie eine Technologie einsetzen.
Stonemetal
5
In Bezug auf 3 ist das Problem nicht so sehr, dass SQL langsam ist , sondern dass SQL verzögert ist . Im Allgemeinen erzielen SQL-Datenbanken auf Kosten der Latenz einen hervorragenden Durchsatz. Für ein webbasiertes Spiel ist das wahrscheinlich das, was Sie wollen! Für ein Echtzeit-Netzwerkspiel ist dies wahrscheinlich nicht der Fall, und die meisten "WoW-ähnlichen" MMOs, die SQL verwenden, verwenden eine Caching-Ebene davor, die die meisten Vorteile von SQL beseitigt. Aus diesem Grund ist NoSQL ein großer Fortschritt Sie.
18

Die Antwort ist ja, es ist eine gültige Option, aber nein, es ist wahrscheinlich keine gute Idee .

Es gibt zwei Hauptprobleme mit SQL, die NoSQL zu lösen versucht, wenn es um Spiele geht.

Die erste ist Latenz oder Verzögerung. In gewisser Hinsicht sind SQL-Datenbanken blitzschnell und verarbeiten Tausende von Transaktionen oder mehr in Zehntelsekunden. In einem anderen Sinne sind sie unglaublich langsam, da die Verarbeitung von nur wenigen Transaktionen genauso viel Zeit in Anspruch nehmen kann. Bei den meisten Datenbankverwendungen spielt dies keine Rolle, aber Spiele haben eine Echtzeitkomponente. Es geht also nicht nur darum, wie viele Transaktionen Sie pro Sekunde ausführen können, sondern auch um die durchschnittliche Zeit, die zum Antworten auf eine Datenbanktransaktion benötigt wird.

Diese Latenz ist ein großes Problem bei Echtzeitspielen. Viele Entwickler, die große Datenbanken benötigen (normalerweise für MMOs), bauen eine Caching-Ebene auf, die sich zwischen der Datenbank und den Spieleservern befindet, um diese Blockierungen zu vermeiden, und leeren dann den Cache regelmäßig. Das Problem? Sie haben gerade die Hauptgründe für die Verwendung einer Datenbank genannt - Atomarität, Konsistenz, Isolation und Beständigkeit .

Dieses Problem trifft jedoch nicht auf Web-Spiele zu.Sie haben bereits eine Verbindung mit hoher Latenz zwischen dem Player und dem Spiel, sodass Sie möglicherweise den von SQL bereitgestellten Durchsatz sowie die Vorteile ausgereifter, bekannter Software nutzen können.

Das zweite Problem trifft jedoch auf Sie zu, und das ist die Fehlanpassung der objektrelationalen Impedanz . Spiele beschäftigen sich mit Objekten, Datenbanken beschäftigen sich mit Zeilen. Wenn Sie Glück haben, können Sie ein Objekt in eine Zeile verwandeln, indem Sie nur die Felder auflisten. Die meisten Objekte sind jedoch hierarchisch und müssen auf irgendeine Weise abgeflacht werden, um sie in Zeilen zu unterteilen.

Dokumentbasierte Datenbanken wie CouchDB und MongoDB lösen dieses Problem, indem sie das Dokument zum Objekt der obersten Ebene und nicht zur Zeile heraufstufen ("document" ist in diesem Fall ein Synonym für "object"). Auf diese Weise verlieren sie jedoch viele der Vorteile von SQL-Datenbanken. Der Durchsatz ist viel geringer und die Sperralgorithmen werden viel komplizierter.

Die gute Nachricht ist, dass bereits viele ORM- Tools (Object Relational Mapping) für die von Ihnen verwendete Sprache verfügbar sind. Mit ihnen können Sie zwischen Objekten im Arbeitsspeicher und Zeilen in der Datenbank ziemlich transparent übersetzen. Diese Tools sind im Allgemeinen nicht für große Echtzeitspiele geeignet, da sie die schlechtesten Leistungsaspekte von SQL- und NoSQL-Datenbanken aufweisen können. Aber für ein Web-Spiel ist es in Ordnung - im schlimmsten Fall, wenn Sie auf Leistungsprobleme stoßen, können Sie wieder Transaktionen auf die altmodische Weise durchführen. Das Latenzproblem schadet Ihnen nicht und der höhere Durchsatz hilft Ihnen.

Abschließend möchte ich einen Punkt an anderer Stelle erläutern : Es geht nicht um statische Spieldaten. Ich spreche hier nicht über Ihre Artikelbeschreibungen oder Ihren Waffenschaden oder Sprites oder irgendetwas. Ich meine die realen, veränderlichen Spieldaten, wie zum Beispiel, was sich im Inventar eines Spielers befindet oder was seine Statistiken sind. Für die statischen Daten benötigen Sie lediglich einen Datenspeicher. Möglicherweise stellt sich heraus, dass es am einfachsten ist, dieselbe Datenbank wie den Datenspeicher zu verwenden, da Sie über ein hervorragendes ORM verfügen. Vielleicht brauchst du nur das Dateisystem. Es sind zwei getrennte Probleme, und eine Antwort muss (und wird wahrscheinlich nicht) für beide Fälle passen.

Gemeinschaft
quelle
1
+1 Danke für den Vergleich beider Optionen. Darüber hinaus weisen Sie darauf hin, dass sich statische Daten nicht in der Datenbank befinden sollten.
Pran
1
+1 Ich denke jedoch, dass Sie es versäumen, einen der Hauptvorteile von No SQL zu erwähnen (nun ja, pro oder contra, je nach Perspektive). Ich werde für mein aktuelles Projekt mit PostgreSQL eine Mischung aus beidem für Dinge verwenden, die gut in das relationale Modell passen, und Mongo für semi-statische Dinge, die dies nicht tun. (Zum Beispiel ein Protokoll, das zur Generierung einer Wiederholung verwendet werden kann. Relational müsste entweder eine Spalte vorhanden sein, in der eine PK aus einer von vielen anderen Tabellen gespeichert ist, oder eine Tabelle mit generischen Spaltennamen, z. B. param1 param2.)
Davy8
1
@ Davy88: noSQL ist nicht unbedingt schemafrei, und eine "hochdynamische" Datenbank zu haben, ist kein wirkliches Plus. Wenn Sie nur Datensuppe haben, können Sie keine Indizierung durchführen, keine Sperre auf Feldebene durchführen, und selbst einfache Abfragen sind mit Fragen behaftet, was passiert, wenn kein Schlüssel vorhanden ist.
@ user744, was bewirken diese Dinge, die Sie erwähnen?
Expiredninja
5
  • Wäre ein noSQL-Datenspeicher (dokumentbasiert wie MongoDB) für ein webbasiertes Spiel geeignet?

Ich würde empfehlen, sich couchdb anzuschauen

Die Benutzeroberfläche basiert auf Javascript, sodass sie sich gut in HTML5- / Javascript-basierte Spiele einfügt.

Es ist auch in der Lage, offline zu arbeiten (eine lokale Kopie der Datenbank zu erstellen) und sich dann später selbst mit dem Server zu synchronisieren (dies kann beispielsweise für instanziierte Dungeons verwendet werden).

  • Welche Probleme können bei der Verwendung eines herkömmlichen RDBMS wie MySQL auftreten?

Das Hauptproblem wäre, dass No-SQL-Datenbanken ganz anders mit relationalen Datenbanken umgehen. Es kann schwierig sein, den mentalen Wechsel herbeizuführen.

Schauen Sie sich zum Beispiel an, wie " Abfragen " in couchdb ausgeführt werden. Alles wird in Javascript gemacht.

  • Wie kann die Konsistenz von Versicherungsdaten zwischen Benutzern mit MongoDB, während des Spiels oder bei zeitgesteuerten Ereignissen, wie z. B. Cron-Jobs, sichergestellt werden?

Der Vorgang des Synchronisierens von Datenbanken wird in der Sprache von couchdb als Replikation bezeichnet . Sie werden auch den Begriff Konsistenz häufig sehen . Es gibt mehrere integrierte Dienste, die sich mit Replikation und Konsistenz befassen. Siehe zum Beispiel den inkrementellen Replikationsprozess .

egarcia
quelle
Ja, ich habe auch von couchdb gehört, sogar auf der mongodb-Website, die im Allgemeinen mit ihr verglichen wird. Ich denke, ich muss über couchdb vs mongodb recherchieren.
Pran
2

Je nachdem, was Sie in Ihrem Spiel haben, werden Sie möglicherweise beide verwenden und sie über die Modelle in Ihrem Spiel verbinden. Zum Beispiel könnte und sollte sich der Player in der RDB (Anmeldeinformationen) befinden, aber das Player-Inventar / der Variablenspeicher könnten an noSQL gehen, so dass Ihr Player-Modul dies könntelogin() RDB und fetchInventory()noSQL über den Primärschlüssel verwenden könnte.

Karten zum Beispiel besser in NoSQL zu speichern (Koordinaten => Array von verschiedenen Objekten zum Beispiel) Ich kann mir nicht vorstellen, zu speichern, was ein Bereich in RDB enthält (außer einer serialisierten Zeichenfolge, die Sie vollständig unserialisieren müssen, um einen Teil von mehr CPU zu lesen und RAM verschwendet!) Nun, Sie könnten noch Bereiche in RDB speichern, zum Beispiel enthält der Bereich "Stadt X" die folgenden Koordinaten / Blöcke ([3,4], [8,7] ...)

Sie könnten und sollten wahrscheinlich beides verwenden und einen Blick auf flüchtigen Speicher werfen, wie Memcache, den Sie möglicherweise benötigen, oder auf einige temporäre Daten (wäre sicher schneller als die Verwendung von Festplatten! und spart Ihnen viel CPU, aber sicher keinen RAM).

also am Ende>

es kommt darauf an, was du in deinem Spiel haben willst! cheerz

Ronan Dejhero
quelle
Welche Funktionen würden Sie Ihrer Meinung nach mehr in NoSQL oder die Persistenzschicht hineinziehen, als ich gerne daran denke?
Expiredninja
1
Möglicherweise ein Koordinatensystem, wenn Ihr Spiel auf GPS basiert. Möglicherweise ist eine erweiterte Suche erforderlich. Grundsätzlich ist es möglich, MySQL auch als NOSQL zu verwenden, wenn Sie gut mit MySQL umgehen können
Ronan Dejhero