Datenbank im Onlinespiel
-
ProfEich
********Ich wollte mal fragen ob es sinnvoll ist eine mySQL Datenbank in einem Online-
Rollenspiel zu nehmen..ja es ist sinnvoll eine Datenbank zu nutzen, wenn ich auch kein mysql fan bin, du könntest natürlich auch postgres nehmen (geht nur unter unix, linux)
Ich denke ja eher nicht da man erst den Syntax aufbauen muss ("SELECT * ...")
und mySQL diesen dann wieder mit einem Parser umbauen muss wie es den grad
braucht.??? mal ganz davon abgesehen verstehe ich diesen Satz nicht richtig. DU musst Anfragen selber "bauen" und MySQL und auch jedes andere DMBS wird da überhaupt nix umbauen die werden deine Anfragen auswerten und dir die dementsprechenden Daten zur Verfügung stellen.
Und mal ganz davon abgesehen du als "DB designer" hast in diesem Falle erstmal eine ordentliche und möglichst Redunanzfreie Datenbank zu erstellen, entweder aus einem ER diagramm oder über die 1-3 Normalform vielleicht bis zur BCNF runter, aber ohne Abhängigkeitsverlust.
Und natürlich hast DU auch die Aufgabe eine Schnittstelle mit Standardabfragen für deine Datenbank zu programmieren. Die dann meinetwegen über PHP angesprochen werden und an die DB gesendet werden.aber das sind nur Vorschläge dafür um eine ordentliche, stabile und lange haltende DB zu entwerfen. Was du machst bleibt dir überlassen aber einfach so husch husch ist DB Entwurf nun mal nicht da steckt Arbeit dahinter und sowas lässt sich auch nicht ohne ordentliche Planung mal einfach so in einer Stunde realisieren. Naja zumindest nicht bei komplexen Modellen. Bei einfachen Sachen kann man auch mal über den Daumen peilen...aber ich denke ein Onlinegame ist nich so einfach.
ChrisM
*******du musst ja nicht gleich die großen Geschütze wie MySQL ausfahren,
große Geschütze sind ja dann erst wohl Sachen wie Oracle
bye
apo
-
Sehr Amüsant.
Bye, TGGC (Der Held ist zurück)
-
Hi,
TheTester schrieb:
große Geschütze sind ja dann erst wohl Sachen wie Oracle
Oracle ist für mich ein sehr großes Geschütz, was man vorerst wirklich außen vorlassen soll, es sei denn, man hat schon Erfahrung damit oder will es unbedingt lernen.
Vorerst kann er ja auch einfach die Datenbankklasse hardcoden (if (User != "TestUser") return false; usw.), für Einmann-Betatests reicht das vollkommen und später kann er die Datenbank zentral an einer Stelle und nicht überall verstreut einbauen.
ChrisM
-
mySQL wäre für ein großes Ogame durchaus empfehlenswert aufgrunf der Geschwindigkeit,
aber rein von den Möglichkeiten und Stabilität wäre Postgres wohl eher zu empfehlen,
kommt halt jetzt ganz drauf an für wieviele Benutzer du das vorerst planst
bzw. das wirst du dann sehen wenn es fertig ist.
Du könntest natürlich durch User-Spenden und Werbung dann bei bedarf weitere
Server dazunehmen.
-
Hi,
wie gesagt, ihr diskutiert hier doch über Details. Wichtig ist, dass er seine Abfragen mit SQL macht. Den genauen Typ der Datenbank kann er später ja noch wählen.
ChrisM
-
ChrisM schrieb:
Hi,
wie gesagt, ihr diskutiert hier doch über Details. Wichtig ist, dass er seine Abfragen mit SQL macht. Den genauen Typ der Datenbank kann er später ja noch wählen.
ChrisM
Die Datenbanken unerscheiden sich aber auch in den SQL-Abfragen, da hat jede
auch wieder ihre Eigenheiten, ungefähr so wie HTML und die verschiedenen Browser.
-
Hi,
schon klar, aber die Unterschiede bzw. nicht unterstützten Features von mySQL sind jetzt wirklich nicht erheblich. Wie gesagt, ich würde zuerst die Datenbankklasse komplett hardcoden oder diese Lib einsetzen, die eine Datenbank mit einer normalen Datei ohne Server emuliert. Später kann man dann relativ leicht auf eine richtige Datenbank für mehrere Spielserver usw. umsteigen.
ChrisM
-
Nutze testweise erstmal SQLite. Das schreibt alles in eine Datei.
Ich würde mir einen Wrapper für alle Anfragen, die Du machen mußt, bauen, damit Du später problemlos auf eine andere DB umsteigen kannst, und nur den Wrapper ändern mußt (SQL unterscheidet sich schwer!)...Bei DAOC wurde z.B. MySQL verwendet.
Die wollten erst Oracle, aber das war zu teuer!
-
Oracle gibts für den nicht kommerziellen Gebrauch doch kostenlos, soweit ich weiß.
-
SirLant schrieb:
Oracle gibts für den nicht kommerziellen Gebrauch doch kostenlos, soweit ich weiß.
DAOC ist ja leider kommerziell...
-
Kommt doch im Sinne des Witzes bitte nochmal auf die Ursprungsfrage zurück: "Was ist schneller?"
Bye, TGGC (Der Held ist zurück)
-
Für ein Browserspiel im Sinne von Droidwars und was es da so gibt, ist eine DB ein muss.
Für ein anderes MMORPG ... du meinst also weil das Programm dem Mysql Server andauernd ganze Strings sendet und wieder zurückbekommt ist er langsam.
Was blieben dir denn sonst noch für Alternativen?
Mir fallen 3 Möglichkeiten ein wie man die Daten verwaltet:
- Items, Spells usw kannst du direkt in den Quellcode einbauen, wenn du dann aber eins ändern oder hinzufügen darfst du jedesmal neucompilieren und den Server neustarten, davon abgesehen das du alle Daten nicht fest einbinden kannst und auch nicht nur im Ram über vectoren oder so speichern kannst(Benutzerdaten/Invantar usw sollten ja auch nach einem Neustart noch existieren und bei vielen Benutzern irgendwann RAM platt).
Also bestenfalls für Teile de sSpiels geeignet und dann auch nur, wenn es primär auf Geschwindigkeit ankommt und diese Daten sich nicht so oft ändern.
- in eine Datei speichern/laden.
Das ist bei vielen Benutzern auch 1000 mal langsamer als eine Datenbank zu nehmen.
Du musst ja am besten gleich damit rechnen das du 1000 Benutzer hast.
Wenn du dann eine 1000 MB Datei hast hast du ein Problem: komplett ins RAM laden geht nicht weil das dein PC nicht hergibt und jedesmal die komplette Datei ins Spiel laden, das was man haben will rauslesen und dann wieder löschen... geht nicht.
Geht sicherlich auch mit vielen kleinen Dateien, nur bestimmte Stellen lesen oder soetwas in der Art, aber ist auf jeden Fall ab einer bestimmten Benutzerzahl IMMER langsamer als per DB und auch Fehleranfälliger und schwerer zu debuggen.
- Datenbank nehmen.
Ist auch für ein MMORPG afaik am besten geeignet und du kannst dann auch ohne Probleme zur Laufzeit rumadministrieren.
Ein Vorteil ist auch das du gleich einen Webserver nehmen kannst und dann über den Browser die Spielerlevel, eine Ladder usw anzeigen kannst, ähnlich wie es das bnet von Blizzard macht.
-
Verstehe das Problem mit der Performance nicht ganz. Ich sehe kein Problem.
Du mußt doch unterscheiden, was du alles in der Datenbank speichern mußt und was nicht. Und dann wirst du feststellen, das die performanten Daten garnicht in die Datenbank gehören - zumindest nicht zur Laufzeit.
Ein Beispiel: zwei Spieler bewegen sich in der Welt. Egal ob Actionspiel oder Rundenstrategie, diese Aktionen werden höchstens im RAM des Servers gehalten. Bei Actionspielen geht das am besten sogar per P2P, den Server intressiert das doch nicht. Wenn ein Spieler seine Session beendet, kann der Server den letzten Standpunkt ja in die DB speicher - und da ist performance sekundär.
Weiteres Beispiel: Inventare werden auch meist sekundär in Sachen Performance gehandelt. Selbst wenn du bei jedem Vorgang einen DB-Zugriff machst, würde das Inventar keinen Speedverlust aufweisen.
Die performanten Aktionen würde ich im RAM des Servers halten und nur bei bedarf in die DB ablegen. Das Game (Client) selbst würde dabei keine SQL-Statements aufbauen, das macht dann dein Server.
So würde ich es machen, vorallem wenn es auf Performance ankommt. Bei Rundenstrategie u.ä. wäre Performance auf jedenfall zweitrangig.
-
Generell könntest Du Dir in Deinem DB-Wrapper eine Art "Cache" einrichten, die erstmal soweit wie möglich alle Write-Anfragen sammelt (im RAM) (und vorwiegend Read-Anfragen behandelt (welche natürlich auch gecacht sein können)) und nur wenn sie Idle-Zeit zur Verfügung hat in aller Ruhe in die DB schreibt.
-
na, ich schätze mal, die db in diesem spiel muß echt speed bringen. damit fliegen mysql und konsorten mit hohem bogen raus.
win und linux haben null problemo mit file mapping. also funktionen um MapViewOfFile bzw mmap. damit haste einfachen zugriff, als läge alles im ram und trotzdem wird nur geladen, auf was gerade wirklich zugegriffen wird.
danach gilt es, zu überlegen, welche datenstrukturen angesagt sind. für riesige datenmengen ist als kandidat wie immer der bayer-baum dabei. feiner können erweiterbare hashtables sein. solche ansatze sind aber nur einfach, wenn man keine polymorphie innerhalb der db braucht. naja, die relationalen dbs bringen ja erst recht keine.
es gibt dbs für c++, die genau das anbieten. wrapper ums filemapping mit bäumen und hashtables. leseanfang bei google unter post++. je nach zugriffsgewohnheiten biste durchaus auch um faktor 1000 über mysql dabei. schätze das spiel hat oft popelige einzelzugriffe wie "ändere von objekt mit id=0815 mal die x-koordinate auf 4711", und da nen sql-parser anzuschmeißen ist wirklich nicht ok.
die schrecklichen kosten: du kriegst nicht leicht ein absturzrecovery hin (keine transaktionen (ja, mysql leidet auch))! die großen datenbanke können das einfach. haut's denen den rechner aus, ist irgendwie nix inkonsistent. du müßtest am besten regelmäßig (z.b. stündlich) backuppen und beim abkacker den spielern nen time warp zumuten. oder, was ich für höchst elegant halte, ner backup-datenbank per tcp die ganzen buchungen auch schicken, steht die backup-bank im anderen haus, ist kaum ein echter verlust zu fürchten. und als wichtigstes beim tcpip-trick: dein sync() muß nicht auf nen plattenflush warten, netzbestätigung reicht, ist schneller als platte.
edit: so ein game könnte sehr viel mehr lesungen als schreibungen haben. dann ist Sgt. Nukems cache vor nen beliebig lahmen db auch sehr fein.
