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

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

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

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.

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.

• 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 .

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