Welche Datenbank (RDBMS vs NoSQL vs BOTH) soll für ein Echtzeit-Multiplayer-Spiel verwendet werden?

Ich arbeite an einem Echtzeit-Multiplayer-Spiel, für das eine Datenbank erforderlich ist (für Funktionen wie Spielerprofile, Freunde, Freischaltungen, Nachrichten usw.). Dies ist ein Standard-PC-Spiel (nicht browserbasiert) und verwendet einen Client-Server die Architektur. Ich bin neu im Umgang mit Datenbanken und habe in den letzten Tagen einige Nachforschungen angestellt, als ich auf die hitzige Debatte gestoßen bin: RDBMS vs NoSQL. Momentan neige ich zu NoSQL, aber nachdem ich die Verwendungsmöglichkeiten für beide (RDBMS und NoSQL) gelesen habe, bin ich versucht, beide zu verwenden. Ich weiß, dass das seltsam erscheinen mag, aber lassen Sie mich meine Situation erklären:

Mein Team hat ein gemeinsames Webhosting-Paket, das unbegrenzten mySQL-Speicher und unbegrenzte Bandbreite bietet. Die einzige Einschränkung besteht darin, dass nur 25 Verbindungen gleichzeitig geöffnet sein können (gemeinsame Hosting-Regel). Ich beabsichtige, dies für meine Website zu verwenden (ohne Zweifel eine typische Verwendung), um News-Updates zu veröffentlichen, Community-Funktionen zu unterstützen (wie Kommentare, das Hochladen von Fanartikeln usw.) und dergleichen. Das ist alles in Ordnung und gut - aber! Hier wird es interessant ... Ich möchte die gleichen Informationen anzeigen, die auf meiner Website im Spiel veröffentlicht sind. Dies bedeutet, mySQL sowohl für meine Website als auch für mein Spiel zu verwenden. Zusätzlich zu Nachrichten und Ähnlichem plane ich, es im Spiel für Dinge wie Chat und eine Serverliste zu verwenden. Ich mache mir hauptsächlich Sorgen um diese 25-Verbindungs-Regel.

Was mich dazu bringt, Frage 1 zu stellen: Funktioniert das und gibt es eine bessere Alternative?

Außerdem habe ich gelesen, wie gut NoSQL funktioniert und für Echtzeitspiele geeignet ist (ich könnte mich irren, ich bin durch einen riesigen RDBMS-gegen-NoSQL-Flame-Krieg gelaufen, um hierher zu kommen, und wahrscheinlich bin ich verbrannt). Grundsätzlich möchte ich MongoDB für alle meine Spielobjektdaten verwenden.

Auch hier ist es hilfreich, wenn ich einen Kontext zur Verfügung stelle: Ich habe einen Host (MongoLab) gefunden, der ein kostenloses 240-MB-MongoDB-Paket anbietet, das ich verwenden möchte, bis ein Upgrade erforderlich ist. Angesichts von 240 MB habe ich berechnet, dass ich in der Lage sein werde, ungefähr 60.000 Spieler zu speichern (wenn jeder Spieler ungefähr 4 KB groß ist und wir andere Dinge, die gespeichert werden könnten, ignorieren). Der Speicherplatz und in Zukunft mehr bezahlen zu müssen (sollte unser Spiel erfolgreich sein) ist kein Problem. Der einzige Grund, warum ich derzeit beabsichtige, MongoDB für alle meine Spielobjektdaten zu verwenden, besteht darin, wie oft auf diese Spielobjektdaten zugegriffen wird (z. B. wenn ein Spieler getötet wird, einen Gegenstand aufnimmt, eine Waffe abfeuert usw.) gefällt auch den einfachen schemafreien Dokumenten (die das Abbilden von Spielobjektdaten erleichtern). Ich sollte beachten, dass auf einmal

Ich beabsichtige, dieselbe MongoDB auf meiner Website zu verwenden, um Informationen zum Spielerprofil anzuzeigen (ich bin nicht an vollständiger Konsistenz interessiert, einige Verzögerungen bei Updates im Spiel sind in Ordnung). Was mich zu meiner zweiten Frage führt, Frage 2: Ist das eine gute Idee oder gibt es etwas Besseres, das ich tun sollte?

Das Spiel wird eine ähnliche Starterfahrung haben:

1. Client-Logins (MongoDB)
2. Der Client befindet sich auf der Startseite des Spiels mit Chatrooms (MySQL).
3. Client geht zur Serverliste (MySQL)

4. Der Client stellt eine Verbindung zu einem Server her und spielt darin

5. Server kommuniziert Updates für alle Spieler (MongoDB)

Das ist genau so, wie ich es mir vorgestellt habe. Sieht das für Sie gut aus oder haben Sie Vorschläge, wie dieser Plan verbessert werden kann?

Mein Vorschlag ist, dass Ihr Spiel mit einem von Ihnen erstellten Webdienst kommuniziert, der sich selbst mit dem Abfragen der Datenbank befasst. Zu diesem Zeitpunkt ist es sehr einfach, verschiedene Arten von Datenbanken zu testen, indem Sie die Webdienst-Implementierungen "wechseln" (Ihre Webdienst-Oberfläche bleibt immer gleich, damit Ihr Spiel nicht kaputt geht) und zu entscheiden, welche für Sie die richtige ist.

Es ist auch viel sicherer, Ihre Datenbank nicht direkt dem Internet auszusetzen.

Es können nur 25 Verbindungen gleichzeitig geöffnet sein (Shared Hosting-Regel).

Das ist mehr als genug für dein Spiel. Das Problem ist, dass wenn Ihre Website mehrere Verbindungen verwendet, Sie auslaufen könnten. Sie müssen Ihren Webserver so konfigurieren, dass nur eine kleine Anzahl von ihnen verwendet wird. Der Rest verbleibt auf Ihrem Spieleserver. Ihr Spieleserver benötigt nicht wirklich mehr als eine Verbindung, könnte aber von einer Handvoll profitieren.

Außerdem habe ich gelesen, wie gut NoSQL funktioniert und wie gut es für Echtzeitspiele geeignet ist (ich könnte mich irren, ich bin durch einen riesigen Krieg zwischen RDBMS und NoSQL gelaufen, um hierher zu kommen, und wahrscheinlich bin ich verbrannt). Grundsätzlich möchte ich MongoDB für alle meine Spielobjektdaten verwenden.

Dies ist ein falsches Argument, da keines der beiden Systeme schnell genug ist, um als Hauptspeicher für ein schnelles Echtzeitspiel verwendet zu werden. Sie müssen die Werte im Speicher unbedingt beibehalten und bearbeiten. Sie greifen also nur dann auf die Datenbank zu, wenn Sie es unbedingt müssen, was möglicherweise nur dazu dient, den gesamten Charakter von Zeit zu Zeit zu speichern (z. B. einmal pro Minute), und an diesem Punkt werden die Geschwindigkeitsunterschiede vernachlässigbar.

Das Lustige ist, wenn Sie MongoDB auf Höchstgeschwindigkeit einstellen, können Sie es fast so weit bringen, dass es schnell genug ist, um synchrone Schreibvorgänge in einem relativ schnellen Spiel durchzuführen, aber dies würde den Preis kosten der Datenintegrität, weil die Schreibvorgänge gepuffert sind. Dies bedeutet, dass Sie diese Daten im Falle eines Absturzes verlieren. Es hat also wenig Sinn, den Schreibvorgang überhaupt durchzuführen, und es ist immer noch langsamer, als wenn Sie die Bearbeitung nur im Speicher durchgeführt und später gespeichert haben, sodass Sie das Schlimmste aus beiden Welten erhalten .

Der einzige Grund, warum ich momentan beabsichtige, MongoDB für alle meine Spielobjektdaten zu verwenden, ist, wie oft auf diese Spielobjektdaten zugegriffen wird (z. B. wenn ein Spieler getötet wird, einen Gegenstand aufhebt, eine Waffe abfeuert usw.).

Fragen Sie sich, warum Sie in die Datenbank schreiben müssen, wenn ein Spieler eine Waffe abfeuert. Warum kann das nicht einfach im Speicher des Spielservers erledigt werden? Wenn Ihr Spiel abstürzt und später neu startet und der Spieler feststellt, dass er drei Kugeln mehr hat als erwartet, ist das ein kritisches Geschäftsproblem?

Ich mag auch die einfachen schemafreien Dokumente (die das Abbilden von Spielobjektdaten erleichtern).

Dies ist ein viel besserer Grund, sich für einen NOSQL-Ansatz zu entscheiden als das Leistungsproblem.

Ich beabsichtige, dieselbe MongoDB auf meiner Website zu verwenden, um Informationen zum Spielerprofil anzuzeigen (ich bin nicht an der vollständigen Konsistenz interessiert, einige Verzögerungen bei Updates im Spiel sind in Ordnung).

Das ist in Ordnung und sinnvoll. Später möchten Sie möglicherweise eine separate Instanz verwenden, damit das Lesen und Schreiben im Web nicht mit dem Lesen und Schreiben im Spiel in Konflikt steht. Dieses Problem ist jedoch eine triviale Lösung im Vergleich zu dem Problem, dass es so populär wird, dass es ein Problem darstellt.

Persönlich würde ich nur eine der beiden Datenbanken auswählen, auf deren Basis eine weniger Arbeit für mich wäre, und dies standardisieren - aber es gibt keinen Grund, warum Sie nicht bei zwei bleiben können, wenn Sie möchten.

Alle Echtzeitdaten müssen im Anwendungsspeicher gespeichert werden, alles andere wäre unsinnig.

Es ist ziemlich einfach, die Anmeldedaten, Statistiken usw. der Benutzer beizubehalten. Ich werde also mutig sein und sagen, dass Sie so ziemlich alles verwenden können, was Sie wollen. Auch wenn Sie mit der Website vorsichtig sein möchten, können Dinge wie Benutzerlisten die Datenbankleistung erheblich beeinträchtigen, wenn Sie kein ordnungsgemäßes Caching-System verwenden.

Und wie Bummzack sagte, sollten Sie alles im selben Netzwerk halten. Darüber hinaus sollten Sie sich vor kostenlosen Inhalten hüten, 240 MB freier Datenbankspeicher klingt gut, aber da die Maschine wahrscheinlich auf eine große Anzahl kostenloser Benutzer aufgeteilt ist, kann der Dienst ziemlich langsam sein.

Vertrauen Sie Ihren 60.000 Benutzern pro Datenbank? Wenn nicht, sollten Sie die Idee des "Datenbankzugriffs vom Client" ignorieren, es sei denn, Sie verfügen über erstklassiges Know-how in Bezug auf die Sicherheit der Datenbanksoftware und sind zuversichtlich, dass Sie alle daraus resultierenden Probleme bewältigen können.