Welches DBMS für Browsergame?

[Montgomery C Burns]

1. nicht selten viele, gleichzeitige, schreibende DB-Zugriffe (Updates) auf die selben Daten (wenn es zum Krieg zw. den Parteien kommt) - blöderweise ist es gerade in solchen Zeiten wichtig schnelle Antwortzeiten zu haben wegen Punkt 4.

Dann würde ich so wenig Indexe wie möglich verwenden, weil die bei Updates Zeit fressen.

naja, die indizierten Felder werden (mal abgesehen vom Fremdschlüssel zur User Tabelle) kaum geändert

-> 1.1 dafür gibt es nicht selten aber auch Wochenlang kaum Belastung

Mir ist leider kein DBMS bekannt, das während Phasen geringer Last häufige Abfragen vorberechnet (gibt es so was?).

Darauf wollte ich nicht hinaus, wollte nur anmerken das es eben nicht dauernd so dahin geht...

2. Anzahl der Datensätze ändert sich kaum (selbst über einen längeren Zeitraum) (d.h. großteils select und update Abfragen)

Mit wie vielen Datensätzen rechnest du? Denke auch daran, dass die Community übelst krass wachsen könnte.

Die User kann man Notfalls begrenzen, geplante Zahlen:
ca. 200-300 User insgesamt aufgeteilt in jeweils ca. 50 User pro "Spielplatz" (man kann zw. den einzelnen Spielplätzen reisen)

• ca. 900k Gegenstände um die gekämpft wird, die nachher (Schrittweise) auf 1,2M erweitert werden (also von 150k für jeden Spielplatz am Anfang, und später 200k)

• ca. 4-6M Items ("Kampfinstrumente und Rüstung") (100 items pro User, pro Itemkategorie, pro Level, bei voraussichtlich 20 Leveln)

• ein Forum, das wird dann aber ein anderer DB-Server (MySQL) übernehmen

4. eine gewisse Ausfallsicherheit sollte gegeben sein, da eine Browsergame Community sehr unangenehm werden kann wenn das Spiel nicht geht, oder gerade während eines Kampfes "lahm" ist, daraus ergibt sich auch:
   -> 4.1 einfache Möglichkeit automatisiert Backups anzulegen (DB kann dabei ruhig in einen nur-lese-Modus gestellt werden, da in der Nacht bzw. den Morgenstunden nur wenige aktiv sind - es sind ja fast alle in der selben Zeitzone)
   -> 4.2 das DBMS sollte sich soweit möglich selbst wiederherstellen können

PostgreSQL erfüllt AFAIK ACID, d.h. bei einem Stromausfall (o.ä.) macht der Server nach dem Starten genau da weiter, wo er aufgehört hat.

aber MySQL nicht :,(

6. folgendes wird permanent geloggt, aber nicht automatisiert abgefragt d.h. falls etwas gelesen wird dann nur "händsich" (auch wenn über diverse Tools) + es gibt keine Updates
   -> 6.1 bezüglich welcher User sich wann und wo angemeldet hat
   -> 6.2 was ein User wann angestellt hat

Dann würde ich möglichst wenige Indexe verwenden (eigentlich nur die notwendigen unique-constraints).

Hierfür wäre MySQL mit MyISAM genau das richtige - oder?

Ich hatte mir auch überlegt hierfür Textdateien zu verwenden, aber das ist dann doch zu umständlich um es zu handhaben :\

(*) Es hängt ganz davon ab wer im Falle eines Kampfes, das austragen vom Kampf übernimmt:
-> Die DB (über stored procedures - sind die atomar? in dem Fall kann man auf Locks verzichten)

Eine stored procedure kann bei PGSQL AFAIK problemlos eine Transaktion sein, also ja.

Hmm? Transaktionen sind aber nicht Atomar...

MySQL ist nicht per se schneller als PostgreSQL, aber MySQL kann von mehreren Prozessoren und/oder Rechnern profitieren. PostgreSQL kann das AFAIK nicht.

Wieso Soll pg nicht mehrere Prozessoren sinnvoll verwenden können? Außerdem gibt es für pg auch Replikationslösungen (aber ich hoffe stark auf diese verzichten zu können)

Ich würde bei so einem großen Projekt zunächst ein Datenbank-Design für beide DBMSe machen, mit massenhaft Zufallsdaten füllen und Stresstests machen.

Ich hatte anfangs überlegt PEAR::DB bzw. ADOdb zu verwenden, hab die Idee dann aber wieder verworfen, weil viele gesagt haben das ist nur unnötiger Overhead und bringt im ernstfall nichts...

Aber gut, ein Testscript 2 mal verfassen dürfte nicht so viel Aufwand sein :>