Mal das andere Ende: Persistenz

In Kreisen wie unseren werden ja in den vergangenen Monaten vor allem Möglichkeiten diskutiert, wie man Spiele auf der Darstellungsseite an die Grenzen des technischen Möglichen treiben kann, um den Spielern ein "interaktiveres" Spielerlebnis zu bieten, ohne dabei den Browser zu verlassen. Sicher wird sich dort in Zukunft einiges tun, aber wenn man mal davon ausgeht, dass nicht alle auf simple Spielkonzepte setzen, bei denen es nur um eine schönere Grafik für das immer gleiche Prinzip geht, dann wird man auch irgendwann am anderen Ende ansetzen müssen, um mehr Leistung aus den Systemen zu holen. Ich denke hierbei, wie der Titel vermuten lässt, vor allem an die Persistenz.
Heute basieren die meisten BGs auf einer Kombination aus irgendeiner Oberfläche und einer SQL Datenbank. Das funktioniert soweit auch ganz gut, aber SQL kommt ja nun wahrlich nicht aus dem Spielebereich und ist eigentlich für ganz andere Zwecke gedacht. Je nach Komplexität und Interaktivität gerät man also mit diesem Setup früher oder später an technische Grenzen, an denen das Ganze einfach nicht mehr performant ist.
Nun bieten aber SQL-Datenbanken in der Regeln einige entscheidende Vorteile, weshalb sie sich auch so wacker halten...Transaktionen seien nur eines der genannten Stichwörter, insbesondere für die armen Seelen die sich mit Skriptsprachen wie PHP rumquälen (sorry, konnte die Spitze nicht lassen, bitte darüber keine Diskussion ). Und irgendwo müssen die Daten nunmal festgehalten werden...das ganze möglichst lückenlos, man weiß ja nie wann der 5-Euro-Server mal wieder wie aus dem Nichts still steht (oder auch der für 2,5 tausend).
Daher meine Frage, bzw. mein Denkanstoß, in der Hoffnung dass es dazu ein paar Meinungen gibt: In welche Richtung gehen die Persistenzlösungen? Was gibt es vielleicht sogar schon heute, was aber "keiner" kennt? Oder wird man auf Gedeih und Verderb versuchen, noch mehr aus den relationalen Vertretern herauszukitzeln?

SQL -> LoadBalancing, Replication, PreLoading, alternate Caching
AppServer -> LoadBalancing, FailSafe, PreCaching
Meinst du solche Sachen?
Bin im moment ein wenig in Eile, von daher nur dies als Frage.

> Was gibt es vielleicht sogar schon heute, was aber "keiner" kennt?
Sehr interessant finde ich heute immer noch db4o und insbesondere das neueste Feature: LINQ for db4o und transparente Persistenz:
developer.db4o.com/blogs/product_news/archive/2008/02/12/linq-is-here.aspx - LINQ
developer.db4o.com/blogs/product_news/archive/2008/01/10/from-transparent-activation-to-transparent-persistence.aspx - db4o.
Wenn ich eines Tages mal ein GPL-Projekt starten werde, dann wird db4o die von mir genutzte Datenbank.

Sagen wir mal so...ich dachte an einen Rundumblick. Wenn man das Ganze aus der Sicht von Hobbyentwicklern und kleinen Studios sieht, dann ist eben nicht immer eine Serverfarm finanzierbar, um mehr Leistung zu kriegen. Von daher muss was neues auf der Softwareseite her.
Und der Hintergedanke war ja: Die Spiele werden komplexer und damit die Anforderungen höher. Also wenn bisher 5000 User auf einem Server spielen konnten und bei höherer Interaktivität nur noch 2500, dann bedeutet das de facto eine Verdopplung meines Fixkostenanteils...und da erscheint mir ein weiteres Erhöhen dieser Kosten mit neuer Hardware nicht als die erste Wahl wenn es darum geht, mehr Leistung zu erreichen.

ich denke kaum das sich da groß was ändern wird.
Webserver sind ohne aufwand clusterbar. Bleibt die DB als flaschenhals.
Ein vernünftiges gameserver-konzept skalierbar mit vernünftiges Caching und ein bis viele sql dbs als backend speicher wird jedes vernünftige bedürfnis zufriedenstellen können, so wie es vermutlich auch bei den großen client-(mmo)-spielen gelöst ist.

Leistung wird einfacher, und datenbanken kann man auch skalieren - der gründer von flickr hat ein buch darüber geschrieben, und ich glaub der sollt fast ahnung davon haben.

Das Hauptproblem, das ich bei SQL-DBs als Backend für Spiele sehe ist die Performance. Das liegt nicht mal so sehr daran, dass die DB-Engine zu lahm wäre.
Vielmehr halte ich es für suboptimal Objekte in SQL-Daten zu "übersetzen" und umgekehrt.
Das ist für PHP wahrscheinlich nicht so ausschlaggebend, bei nativen Sprachen (Java, .Net, C++) aber ausgesprochen lästig. Die üblichen Persistenzframeworks verstecken das zwar, aber das Problem bleibt.
Alternative dazu sind native Datenbanken. Am unteren Ende bietet sich da z.B. BerkeleyDB an. Ist auch hübsch schnell.
In begrenztem Umfang lässt sich die Serialisierung noch load-balancen, aber Amdahls Law schlägt auch da erbarmungslos zu.

So.. mal aus dem Nähkastle plaudere...
Bei meinem vorherigen Arbeitgeber (Bank) wurde z.B. ein CSV-Basierendes System eingesetzt um die Marktdaten aus SAP, Reuters etc. vorhalten zu können und sie je nach Anforderung instant zur Verfügung stellen zu können.
Dazu kam eine selbstgeschriebene StorageEngine und ein eigenes Caching zum Einsatz.
Die gängigen Datenbanken konnten die Anforderungen nicht mehr erfüllen und man wählte deshalb diesen doch anfangs seltsam anmutenden Weg.
Nachteilig wirkt sich diese Lösung bei Backups aus. Versucht mal innerhalb weniger Stunden einen Restore zu fahren, wenn dabei mehrere Millionen kleiner Files (1 KB im Dreh) zurück gesichert werden müssen.
Ich kenne viele Situationen wo man entweder auf die Normalisierungsregeln beim Datenbankdesign verzichtet, oder wo man vollständig auf andere Lösungen umsteigt.
Ein Freund von mir arbeitet bei einem Unternehmen was Adressdaten verarbeitet.
Beispiel:
80 Mio Datensätze als Ausgangsgrundlage und die Aufgabe ist alle Männer mit dem Vornamen Max, dem Nachnamen Müller und zusätzlich einem Scoring aufgrund weiterer Informationen zzgl. einer Ähnlichkeitssuche (Maximilian oder z.B. Macks) durchzuführen.
Dies bitte mit Unicode und bei bestimmten Kundenaufträgen sogar Weltweit. Ach und bitte auch noch beachten das Japan und Co. andere Suchroutinen benötigen bei der Sprache...
Und das bitte min. 2 Mio mal in der Stunde.
Da brechen die gängigen Datenbanksysteme gnadenlos ein.

In unserem Projekt versuchen wir einen anderen Weg - weg von den DB im üblichen Sinne.
Die Daten, die oft benötigt werden, werden im RAM gehalten (in einem Windows-Service). Größere Daten (z.B. Nachrichten oder so) gehen doch noch an eine SQL-DB (damit der RAM nicht sinnlos verstopft wird). Aller 6 Stunden werden die Daten des Caches in xml-Dateien serialisiert (= Backup), also verlieren wir bei einem Servercrash eben nur die 6 Stunden (kann man wohl verkraften).
Ich kann dir leider noch nicht sagen wie performat dies bei größeren User-Anzahlen läuft, aber bei rund 50 hatten wir noch keine Probleme (aber das sollte man auch bei keiner DB haben ).
Der Hauptvorteil ist, dass wir uns um die Serialisierung der Objekte keine Gedanken machen müssen...da auf beiden Seiten (Asp.Net + WindowsService) .Net eingesetzt wird und die Kommunizierung über WCF läuft, übernimmt das .Net Framework die ganze Arbeit für uns
Nachteile haben wir bisher noch keine entdeckt, ab und zu gibt es noch ein paar Probleme mit der Erweiterbarkeit (z.B bei Umbennenungen) aber finde ich das immernoch um einiges besser als 20 SQl-Queries umzuschreiben
Nur als ein kleines Beispiel für einen alternativen Weg

Ich glaube, dass neben den Standardprodukten wie MySql mit Replikation und den ganzen Finessen auch Eigenbausysteme eine gewisse Daseinsberechtigung haben (werden). Immerhin ist ein Datenbanksystem wie Mysql ja als "Allzweckwaffe" konzipiert und bietet eine Menge Features, die man gar nicht benötigt. Wer sich seine eigene "Datenbank" bastelt, muss ja nur die Teile replizieren, die er auch benötigt, der Rest verursacht weder Last noch muss er implementiert werden. Ich sehe da aber drei große "abers":

• Flexibilität: Das Spiel sollte nicht oder nur sehr wenig fortentwickelt werden. Sonst ist eine passgenaue Lösung wieder nur ein Klotz am Bein, denn die Anforderungen ändern sich ja mit einer Weiterentwicklung in der Regel. Und Abstraktion sowie Flexibilität knabbern nun mal an der Leistung, bzw. eine Eigenentwicklung ist dann nicht mehr so sinnvoll.
• Größe: Sowas lohnt sich nicht für ein kleines Spiel, sondern für extrem große Spiele, die so noch mehr Leistung rausholen wollen (z.B. um die oben angesprochenen Fixkosten zu drücken).
• Hintergrundwissen: Sowas baut man nicht mal eben an einem Nachmittag nachdem man eine Userverwaltung geschrieben hat. Ein Mindestmaß an Hintergrundwissen, Datenbanktheorie und vor allem Anforderungsabschätzung gehört dazu, sonst kommt verläßlich Murks bei raus.

Im Großen und Ganzen sehe ich sowas für einmal entwickelte, große Spiele die dann nur noch gewartet werden, also sowas wie Ogame oder was Bigpoint so anbietet. Das typische Php-Schülerprojekt dass mit einer Anmeldung startet und dann nach und nach (nicht) weiterentwickelt wird hat für sowas glaube ich keinen Bedarf.
Hat das Forum schon wieder einen längeren Text gefressen. Aber Duke Nukem for ever kommt ja bald.

ich möchte noch ein paar gedanken zu abuzeus ergänzen.
die entwicklung und wartung einer angepassten datenablage welche schneller ist als eine standarddb benötigt zeit und damit manpower. und ich denke das auch nicht zu knapp.
somit wäre auch die frage, wann die kosten die man durch die dadurch gebundene manpower hat, geringer sind als die fixkosten für einen weiteren db server.
ich würde sogar soweit gehen, zu sagen, das es selbst für grosse spiele einfach nicht lohnt, weil man die manpower für neue projekte einfach besser gebrauchen kann.

Es geht ja nicht zwangsweise um Eigenentwicklungen. Eigentlich das Gegenteil: Wo geht der allgemeine Trend hin, wie man Persistenz im Hochlast-Hochdynamik-Bereich löst. Und wenn ich Trend sage, dann meine ich, dass es nur eine Frage der Zeit ist, bis sich wieder Standard-Programme oder Libraries etablieren.
Mich würde nur interessieren, wo da die Technik hingeht wenn relationale Datenbanken nicht mehr das richtige sind...also bei Daten die in großen Mengen auftreten und sich beispielsweise sekündlich ändern. Wie man das in einem dynamischen Spiel mit tausenden Spielern eben gerne mal hat. Gleichzeitig will man aber auf gewisse Dinge nicht verzichten bzw. sie nicht neu Erfinden. Ich persönlich denke da immer zuerst an Transaktionen...selbst eine Datenhaltung für Objekte schreiben, die eine wasserdichte Transaktions-Sicherheit liefert ist, wie bereits in diesem Thread erwähnt, nicht ganz ohne.

Also ich bin ja generell für ORM (Object-Relational-Mapper). Ist meiner Meinung nach in der Verwendung bei der Programmierung das intuitivste. Wie der Krams dann im Endeffekt gespeichert wird ist mir als Entwickler egal. Bei den ORMs die ich kenne ist das bisher ausschließlich über SQL, aber das ließe sich ja auch problemlos austauschen. In meinen Augen geht der Trend also zu ORM.

Meiner Info nach ist Oracle grade dabei, einen ORM-Mapper in der Datenbank aufzubauen.
Wenn ich es richtig verstanden habe, übergibt man die Objekte einfach an die Datenbank und die kümmert sich darum sie persistent zu halten. Im Hintergrund soll nach wie vor ne SQL-DB liegen, die Objekte jedoch auch persistent vorgehalten werden.
Damit soll der Nachteil des Suchens nach bestimmten Objekten (SELECT * FROM user WHERE name = 'blub' oder entsprechend komplexer) in Objektorientierten Datenbanken ausgemerzt werden.
Mal sehen was da noch kommt.

Hört sich für mich fast nach LINQ an

Original von Lunikon
Eigentlich das Gegenteil: Wo geht der allgemeine Trend hin, wie man Persistenz im Hochlast-Hochdynamik-Bereich löst. Und wenn ich Trend sage, dann meine ich, dass es nur eine Frage der Zeit ist, bis sich wieder Standard-Programme oder Libraries etablieren.

Was ist denn Trend? Was wir/hier einige denken oder was Unternehmen mit riesigen Seiten a la eBay, Amazon oder Google daraus machen?
Die haben bei sich Oracle-Datenbanken, Java/Ruby-und noch viel mehr Anwendungen oder nutzen sogar ein eigenes Datei- bzw. sogar Betriebssystem. Hardwarebasiertes Clustering, Caching, Balancing mal aussen vor..

Ich habe bei einem Projekt mal einen Cache für die Datenbank geschrieben. Es ging dabei um ein Zugdispositionssystem, Zugstandortmeldungen wurden von einem Prozess angenommen, die Daten des Zuges aus der Datenbank gelesen, ein paar Änderungen an den Daten vorgenommen und Trigger an andere Prozesse geschickt, die dann ihre Arbeit an den Daten des Zuges vorgenommen haben. Nach einer solchen Zugstandortmeldung hätten dann typischer Weise 5 Prozesse die gleichen Daten, hintereinander aus der Datenbank gelesen. Also habe wir es so gemacht, dass in einem Shared Memory die Daten aus der Datenbank zwischen gespeichert wurden. Wenn ein Prozess die Daten aus der DB gelesen hatte, standen die Daten im Cache um musten nicht wieder von der DB gelesen werden. Das war um den Faktor 1000 schneller, als die Daten direkt von einer gut mit Cache ausgestatteten Oracle Datenbank, die auf dem gleichen Rechner lief, zu lesen. Dabei hat der Cache nur lesend gearbeitet und Änderungen wurden direkt im Cache und in der DB durchgeführt.
Relationale Datenbanken sind halt Tools, die alle Fälle abdecken müssen. Die setzen Locks in einer Granularität, wie sie nicht nötig sind. Die Abfragen müssen häufig manuel optimiert werden, weil die Datenbank natürlich nur wenig über die Daten weis. Wir hatten in dem Projekt auch mal das Problem, dass der Optimizer plötzlich meinte, den QEP (Query Execution Plan) umstellen zu müssen und dann Stand das System, weil eine sehr häufig gestellte Anfrage plötzlich um Dekaden langsamer war.

Relationale Datenbanken sind halt Tools, die alle Fälle abdecken müssen. Die setzen Locks in einer Granularität, wie sie nicht nötig sind. Die Abfragen müssen häufig manuel optimiert werden, weil die Datenbank natürlich nur wenig über die Daten weis. Wir hatten in dem Projekt auch mal das Problem, dass der Optimizer plötzlich meinte, den QEP (Query Execution Plan) umstellen zu müssen und dann Stand das System, weil eine sehr häufig gestellte Anfrage plötzlich um Dekaden langsamer war.

Ich dachte schon das war bei uns ein Sonderfall. Von normal maximal 0,4 Sekunden wurden 38 Sekunden bei einer solchen Umstellung. Durch hinzufügen eines weiteren Datenbankfeldes (nur Spaßeshalber probiert) gings dann wieder richtig.