Dilemma: Lokal Speicherung oder Datenbank?

Servus,

ich brauche den Rat des weisen Forums:

Szenario:
Momentan bau ich an einem Game, das für maximal 200 Personen ausgelegt werden sein soll. Dieses Game ist nicht über HTTP erreichbar, aber es tut im Prinzip nichts zur Sache. Der Steuerung des Servers läuft über den üblichen 'Request-Response'-Prinzip ab. Der Server kann allerdings auch dieses am Client durchführen

Mein Problem:

Momentan benutze ich die MySQL-Datenbank zur Speicherung aller Objekte. Da man dort die Objekte zur Verarbeitung dort herausziehen muss, ändern und wieder zurückspeichern, geht für das Datenbank-Handling ein großer Teil der Laufzeit flöten.

Weiterhin kann man ordentliche Objekte im Sinne der OOP nicht richtig in Datenbanken speichern. Manche vererbte Objekte besitzen wesentlich mehr Eigenschaften als das Grundobjekt. Welche Spalten soll nun die Tabelle beinhalten? Nur die Grundspalten und eine zusätzliche Spalte, die den Rest beinhaltet, oder den größten gemeinsamen Nenner, was dazuführt, dass Großteile der Tabelle einfach leer sind?

Ich habe mir überlegt nen lokalen Cache aufzubauen, der die wichtigen Objekte speichert. Nur: Was ist wichtig? Wie weit soll ich gehen? Außerdem ist es dann verpflichtend, dass Cache und Datenbank absolut synchron ist.

Meine Idee:

Die Datenbank wird herausgeschmissen und alle Daten werden lokal im RAM gehalten. Dies führt zu einem absoluten Geschwindigkeits-Boost, da man das elende Umtransformieren der Anfrage in nen SQL-Request sparen kann. Bei ordentlicher Programmierung können alle Objekte mit einem Befehl in einer Xml oder proprietärer Datei gespeichert werden. Das heißt: Der Server manipuliert einfach nur die Daten im Ram und speichert diese in festgelegten Intervallen in der Datenbank

Was denkt ihr über diese Idee? Ist sie für ein typisches 200 Personenspiel akzeptabel, was denkt ihr über die Ausfallsicherheit (was passiert, wenn die Applikation nen Fehler verursacht und interne Daten verliert) und dem Speicherbedarf?

Der größte Vorteil wäre meines Erachtens, dass ich über das gesamte Spiel über eine ordentliche objektorientierte API zugreifen kann, ohne jeweils Wrapper schreiben zu müssen, die die Daten aus der Db schreibt und wieder zurück liest:

Also konkret:
CurrentConnection.Player.GetTown ( "Trulla-Stadt" ).DistributeEnerge();

Zur reinen Info: Der Server wird in C#.Net geschrieben. Aber das Problem ist ja theoretisch unabhängig von der genutzten Sprache. Der Server läuft als Ein-Prozess-Anwendung mit einem Thread pro verbundenem Client. Dies klappt sehr gut, nur benötigt die Datenbank etwa 70% der gesamten Rechenzeit.



Vielen Dank für Tipps aller Art

mhh ich würde mal denken das das speichern im ram völlig ausreichend ist, wenn die anwendung stabil läuft. bzw wenn der server unter einem os läuft welches shared mem unterstützt, kann man das ja auch dort speichern und ist dann nur noch von server offs betroffen. und sowas sollte recht selten vorkommen und durch regelmässiges speichern durchaus abgefedert sein.
alternativ mach nach einer oop db umguggen, allerdings kenne ich da keine frei verfügbaren

Also ich find die Idee gut, bei unserem Daemon ist das auch so geplant dass er alles bereithält und in Intervallen in der DB sichert.

Wie schon geschrieben hätte die Sache nicht zuverachtende Vorteile. Und es freut mich zu sehen, dass ich nicht der einzige bin, der mit dem Gedanken spielt.
Nur muss dafür leider einen Großteil meiner schon geschriebenen Daten-Handling-Routinen modifiziert werden.

Nur ist die Frage, wie ich speichere:
- Eigene Datenbank
- Proprietäre .Net Serialisierung
- Xml-Dateien

Es muss garantiert werden, dass Strukturen erweitert werden können und noch aus dem vorhandenen Datenpool gelesen werden können.

Dies liefert leider die .Net-Serialisierung nicht. Die meldet eine Exception, sobald eine Struktur eine neue Member-Variable erhalten hat.

Aber ich versuche es die Tage mal mit Reflections, so dass ich einer Struktur erklären kann, welche Daten automatisch in eine Xml-Datei gespeichert wird:

[MyXmlSerializableClass()]
class Town
{
[MyXmlSerializableMember()]
Building [] Buildings;

[MyXmlSerializableMember()]
String Title;
};

Sämtliche Klassen und Eigenschaften müssten automatisch automatisch aus der Instanz ermittelt werden und bei Bedarf automatisch zurückgespeichert werden. Ich denke, dies wird die Hauptarbeit.

Der in .Net integrierte Xml-Serialisierer funktioniert zwar soweit so gut, fliegt aber sofort mit ner Exception drauf, sobald zum Beispiel Town um eine neue Eigenschaft erweitert wurde.
etc,

daraus soll dann per MyXmlSerializer.Store ( Stream, Town ) folgende Xml-Datei werden:


....
Bischofshausen


Eine komplett eigene Datenbank will ich soweit wie möglich vermeiden. Die integrierten Xml-Routinen von .Net sollten evtl meinen Ansprüchen genügen. Was denkt ihr?

Also ich werd alles in MySQL sichern.
Vererbung kannst du doch so realisieren dass du da Untertabellen mit Verweisen machst.

Drüber nachgedacht hab ich auch schon, allerdings ist es momentan nicht realisierbar bei uns. Vielleicht irgendwann mal.

Ich experimentiere momentan mit HSQLDB.

Das ist eine lightweight Java-Datenbank, die auch rein im Speicher laufen kann. Der Zugriff ist per SQL, aber nur per JDBC möglich. Ich weiss nicht, ob man das von .NET hin bekommt - ich hab damit noch zu wenig gemacht.

Files erscheint mir zu langsam (I/O). Generell würde ich möglichst viel im Speicher machen. Die großen MMORPG-Server arbeiten meist einen ganzen Tag, bis zu einer nächtlichen Downtime, fast ausschließlich im Speicher und speichern nur wichtige Events (Tod, Level-up, etc.) direkt in einer DB.

Danke für die Info...

Habe mich jetzt entschieden das gesamte Projekte in 2 Stufen umzubauen.
Zuerst wird es nach dem bestehendem Schema mit Referenz auf der MySQL-Datenbank erweitert, bis ich der Meinung bin, dass alle wichtigen Konzeptpunkte umgesetzt worden sind.

Danach beginnt die Portierung auf Xml und lokaler Speicherhaltung. MySQL fliegt komplett heraus und alle Objekte werden in der Lage sein sich selbst zu speichern auf Platte zu sein. Dies geschieht dann alle 6 Stunden, bzw bei Beendigung oder Absturz des Server-Prozesses.

Diese Umsetzung wird ein fließender Übergang im laufenden Betrieb.

Ich wünsch mir auf jeden Fall schon mal viel Spaß

Wenn es dir nur um geschwindigkeit geht und die menge der daten überschaubar bleibt oder du immer wieder genutzte daten optimieren willst würde ich mir mal die HASH tables von MySQL ansehen. Wenn du in deinen daten strukturen freier sein möchtest, als mit normalen datenbanktabellen solltest du die entwicklung im bereich der relationellen datenbanken weiter verfolgen.

noch bin ich nicht davon überzeugt das objektorientierung bei jeder art von browsergame von vorteil ist.

reg4rds
chojin