nicht angemeldet
Hi :D
In die engere Auswahl haben es (welch Überraschung *g*) MySQL und PostgreSQL geschafft, da andere Produkte entweder zu teuer, oder zu Feature-arm (bzw. zu exotisch) waren.
Falls jemand mit dem Begriff "Browsergame" nichts anfangen kann hier eine kleine Beschreibung der Eigenschaften:
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.
-> 1.1 dafür gibt es nicht selten aber auch Wochenlang kaum Belastung
2. Anzahl der Datensätze ändert sich kaum (selbst über einen längeren Zeitraum) (d.h. großteils select und update Abfragen)
3. es gibt eine Tabelle mit den Daten eines Users auf die so ziemlich jede andere Tabelle verweist + bei dieser Tabelle werden (voraussichtlich) oft row-level Locks mit anschließendem Update notwendig sein(*)
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
5. Transaktionen wären wünschenswert, da nicht selten Güter von A nach B bewegt werden
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
(*) 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)
-> der Webserver (mod_php + apc, Locks sind notwenig)
-> der User selbst ("ajax", Locks sind notwendig + eine Fallbacklösung falls keine Antwort mehr kommt)
oder ob die Attribute dieser Tabelle vllt. nicht doch besser auf mehrere Tabellen aufgeteilt werden sollten (in Benutzer Daten, und ingame Daten)
ich hoffe mal ich hab nichts übersehen...
Was könnt ihr mir empfehlen?
Ich würde mehr zu PostgreSQL tendieren:
1. wegen MVCC (damit ist Punkt 1 nur halb so schlimm - oder?)
2. Transaktionen und Fremschlüsselbeziehungen sind kein Problem (und falls notwendig kann der Kampf auch von der DB übernommen werden)
3. 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
Falls die Wahl auf MySQL fällt wird wohl unweigerlich InnoDB zum einsatz kommen, und da stellt sich eben die Frage inwiefern es Sinn macht MySQL + InnoDB zu verwenden, weil in dem Fall der Geschwindigkeitsvorteil von MySQL dahin ist - oder?
Außerdem dürfte Punkt 4. mit MySQL ein Alptraum sein (zumindest wenn man sich diverse Zwischenfälle bei Wikipedia ansieht) - oder?
Und noch eine Frage zum WAL von pg:
kann man den von Zeit zu Zeit entsprechend leeren, oder muss der immer vom anfang an vollständig vorhanden sein damit er auch nützt? (oder ist der nicht so groß das man sich diesbezüglich Gedanken machen muss?)
noch eine Kleinigkeit:
Irgendwelche vorschläge bezüglich welches Dateisystem in so einem Fall zu empfehlen wäre?
ohh, und bevor ich's Vergesse... THX! :D