nicht angemeldet
Hallo Forum,
- 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.
-> 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?).
- 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.
- 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.
- 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).
(*) 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.
ich hoffe mal ich hab nichts übersehen...
Was könnt ihr mir empfehlen?
Ich würde mehr zu PostgreSQL tendieren:
- wegen MVCC (damit ist Punkt 1 nur halb so schlimm - oder?)
- Transaktionen und Fremschlüsselbeziehungen sind kein Problem (und falls notwendig kann der Kampf auch von der DB übernommen werden)
- Punkt 4 ist auch kein Problem, wegen WAL
Der Grund warum ich mich noch nicht für pg entschieden habe ist letztendlich eigentlich nur weil Leute im IRC immer wieder sagen ich soll MySQL nehmen, weil das so schnell ist, und ein Browsergame genau das braucht - deswegen würde ich mir gern nochmal die Meinung von Experten einholen :D
MySQL ist nicht per se schneller als PostgreSQL, aber MySQL kann von mehreren Prozessoren und/oder Rechnern profitieren. PostgreSQL kann das AFAIK nicht.
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.
Gruß
Alexander Brock
