Tach,

ich hätte da ne Frage zu SQL Datenbanken.
Der eine oder andere weis vielleicht, dass ich an einem MMOG Projekt arbeite (Cityrise) zusammen mit einem Kumpel von mir.
Wir sind jetzt gerade am Überlegen evtl. eine andere Datenbank einzusetzen anstatt die MySQL, da wir doch eine sehr große Menge an Daten haben, die wir in die Datenbank ablegen müssen und nicht wissen ob MySQL am besten dafür geeignet ist.
Könnt ihr mir eine Datenbank empfehlen die gut mit großen Datenmengen umgehen kann, oder ist da MySQL doch am besten dafür geeignet? Und wie siehts mit Oracle aus? Ist diese DB bei großen Datenmengen (= sehr viele DB Einträge) schneller/besser als MySQL?
Bei Wikipedia gibt es ja eine schöne Auflistung, aber so gut wie 90% davon sagt mir gar nichts.
http://de.wikipedia.org/wiki/Datenbank_%28Liste%29

Vielleicht kann uns ja einer einen Tipp geben. Wir wären euch sehr dankbar dafür :)

Mein Japan Tagebuch | Japan Gallerie

PostgreSQL ist schnell, gut und OSS. Sonst kannst du dich auch mit Oracle versuchen (vor allem bei sehr grossen Datenbeständen dank guter skalierbarkeit und Clustering-Möglichkeiten sehr stark).
Solange aber die DB nicht auf mehrere DB-Server verteilt werden muss, liegt ihr mit MySQL wohl auch nicht allzu schlecht. Solange das noch klappt, würde ich ev. einen Wechsel auf PostgreSQL überdenken, oder gleich bei MySQL bleiben.

Wie gross ist denn eure DB jetzt? Anz. Tabellen? Anz. Datensätze (pro Tabelle)? Anz. Indices? Anz. Queries / Connects pro sec.?

Ich muss das nacher mal hochrechnen wieviel da zusammenkommen wird. Bis jetzt konnten wir es noch nicht richtig testen, von daher kann ich nur einen Schätzwert liefen wieviel Tabellen und Datensätze es werden. Über die Queries / Connects pro sekunde kann ich nocht nichts aussagen, natürlich versuchen wir sie gering zu halten.
Nagut ouf Oracle muss ich wohl verzichten, kostet zuviel :( Da wir das Spiel nur als Hobby entwickeln, können wir uns da nicht in solche Kosten stürzen.

Mein Japan Tagebuch | Japan Gallerie

Nun, ohne das Projekt jetzt genauer zu kennen wuerde ich sagen: Nehmt weiterhin MySQL oder steigt auf PostgreSQL um. Beide sind schnell und koennen durchaus mit Datenbanken von mehreren Gigabyte halbwegs sicher umgehen. Es wuerde mich wundern wenn ihr wirklich Features von den "grossen" Datenbanksystemen brauchen wuerdet, und selbst wenn, dann ist das meiste in PostgreSQL eh schon vorhanden.
Wo's dann interessant wird ist wenn man die Datenbank z.b. auf mehrere Rechner aufteilt. Aber da muss dann schon heftig was los sein bis nen dedizierter Datenbankserver nicht mehr ausreicht.
Ansonsten aber seht einfach zu dass ihr das Datenbank-Backend flexibel haltet. Das ist glaub ich ueber Standard Java ODBC eh der Fall. Jedenfalls, dann kann man hinterher die Datenbank recht gut austauschen, immerhin ist SQL ein Standard, an den sich sogar teilweise gehalten wird ;)

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Hi, bin der Kumpel vom Angel.

Also wir haben schon mal Tests gemacht mit der DB. Leider hab ich die gerade nicht zur Hand - ich werd die vielleicht bis Ende der Woche mal suchen (und hoffentlich finden).

Aber ich meine wir hätten locker 5 Mio Einträge (nach unserer Hochrechnung) in einer Tabelle gehabt und wenn man dann Querries hatte, wo Tabellen vereint werden (joins), hat er eine unzumutbare Zeit für eine Abfrage gebraucht (im sekundenbereich).

Es geht halt in erster Linie um eine große Menge an Datensätzen.

mfg

Nur wenn man immer wieder das Unmögliche versucht wird man das Mögliche erreichen.

Natürlich war das nur ein grober Versuch, wir haben da schon ein paar neue Ansätze, wie wir das besser Lösen können. Mal schaun wie schnell diese dann sind.

Mein Japan Tagebuch | Japan Gallerie

Mhja, das wuerde ich auch zunaechst empfehlen: Gucken wie ihr die Queries schneller machen koennt. Ergebnisse cachen, Daten anders verteilen, Joins/Indizes optimieren etc. Denn ich glaube nicht, dass ihr durch nen Wechsel auf ein anderes Datenbanksystem signifikante Geschwindigkeitsgewinne bekommt.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Naja, durch den Wechsel auf ein RDBMS mit Ref. Integrität könnte schon ein gewaltiger Geschwindigkeitsunterschied entstehen, da dort automatisch ein Index auf einem Foreign Key erstellt wird. Aber sonst wirds wohl mit der Geschwindigkeit nicht besser werden.
Lass den entsprechenden Query mal mit EXPLAIN [query] laufen und poste das resultat hier (oder gleich selber durchschauen). Da hats wohl full table scans auf grösseren Tabellen drin.
Einige statistische Daten (Tabellengrösse) sowie das DB-Schema wären für das optimieren auch nicht schlecht.

Das mit dem Query mit EXPLAIN werden wir mal am Wochenende durchlaufen lassen und dann das Ergebnis hier posten.
Also wenn ich unsere Idee richtig einschätze, dann könnte es schon um einiges schneller werden.
Auf die ganz große DB wird nur noch minimal zugegriffen und auch möglichst vermieden Joins darauf anzuwenden, falls wir da überhaupt welche brauchen.
Nur dass ihr mal wisst was unsere "große DB" ist. Es ist unsere Weltkarte und beinhaltet die einzelnen Felder. Natürlich nicht alle in einer Tabelle sondern pro Sektor eine Tabelle (250 000 Einträge). Natürlich wird jeder Client die Weltkarte in Form mehrerer Map-Dateien besitzen.
Alles was nötig ist zum "arbeiten" muss sich halt der Client beim Login holen, so dass er dann möglichst wenig mitm Server kommunizieren muss.
Das Problem ist halt dann nur, dass der Server alles validieren muss was der Client schickt, falls mal wieder ein böser User am Werk war...

Na ja, wird schon werden ^^

Mein Japan Tagebuch | Japan Gallerie