PostgreSQL-Vorteile

Stehe zwischen der Entscheidung MySql oder PostgreSQL als Datenbank einzusetzen. Wenn es nur nach mir ginge wäre die Entscheidung schon auf PostgreSQL gefallen. :wink: Nur leider gibt es da noch einige Personen die ich überzeugen muss, das PostgreSQL einfach besser ist. Da ich noch kaum Erfahrung habe (~3 Wochen) kann ich die auf vielen Seiten beschriebenen Vorteile noch schlecht einschätzen. Es wäre also nett, wenn alle die Erfahrungen mit beiden Datenbanken gemacht haben einfach mal ein paar Vorteile und Nachteile beschreiben :slight_smile: (Ist sicherlich nicht nur für mich nützlich so eine Liste)

Mir sind bis jetzt 3 Dinge besonders aufgefallen:

  1. Trigger - sind kaum funktionsfähig in mysql

  2. Datensicherung - fehlt eigentlich völlig in mysql oder ?

  3. Tabellen-Partitionierung
    Scheint mir sehr sinnvoll für mein Projekt, da Abfragen nur einen bestimmten Teil von Tabellen einbeziehen. Die Tabellen können somit theoretisch beliebig groß werden aber die Abfragen sollten nicht länger dauern.
    (In MySQL müsste man wohl “alte” Daten in andere Tabellen auslagern um keinen Geschwindigkeitsverlust zu bekommen)

Besonders bei Punkt 3 kenn ich nur die Theorie, weiss also nicht ob das auch wirklich so läuft wie es beschrieben ist.

MfG Rover

Hallo Rover,

gibt uns etwas mehr an Information. Wozu willst Du die Datenbank verwenden, ~ Anzahl der Tabellen, ~ Anzahl der Datensätze, … ?

Der Vergleich zwischen PostgreSQL und MySQL betrifft im Grunde zwei unterschiedliche Klassen von Datenbanken!



mfg

fristo

Ist es Deine Entscheidung oder die anderer?

Egal.

Du scheinst viele Daten reinpacken zu wollen. Wie viele?
Du willst Geschwindikgeit, also wirst Du EXPLAIN brauchen. Vergleich das, was EXPLAIN unter
MySQL auskotzt mit dem von PostgreSQL. Du willst Geschwindigkeit? Dann wirst Du Indexe nutzen wollen. MySQL konnte bis vor kurzem zumindest pro SELECT nur einen nutzen,
PostgreSQL nutzt alle sinnvoll, die verfügbar sind. Seit 8.1 kann es auch InMemory Bitmap Index
Scan. Du willst Datensicherheit? Falls ja, MySQL nimmt kaputte Daten an, z.B. 29.2.2006 als Datum. Sowas ist krank, sowas will man nicht. Du willst eine gescheite Lizenz? MySQL hat da
Probleme, PostgreSQL ist BSD. Du willst alle gebotenen Features nutzen? Bei MySQL hast Du pro Storage Engine immer nur eine Teilmenge. Lächerlich.

Trigger, Stored Procs, Trigger, Rules, Referentielle Integrität, Subselects und anderes sind, zumindest bei nicht ganz frischen MySQL-Mutationen, Fremdwörter.

Ansonsten: Du solltest genauer spezifizieren, was Du brauchst.

Ach ja, zu den Datenmengen: Mysql speichert alle Daten, die zu einer Tabelle gehören, in eine Datei. Nun stell dir vor, was passiert, wenn da etwas mehr Daten reinkommen … und rechne dir aus, was mit der Performance passiert.

Nun, PG ist auch nicht nur eitel Sonnenschein, es gibt auch an einigen Stellen Probleme zu verzeichnen. Also wäre ein Testcase für das, was ihr vorhabt, sehr praktisch. Wenn ihr dabei Hilfe braucht, sag Bescheid.

Ich und ein Kollege müssen zumindest die Datenbank designen und später wahrscheinlich warten usw. Aber wir sind erst knapp nen Monat im Betrieb und deshalb müssen wir uns da an andere Leute halten, es sei denn wir beweisen das Postgresql wirklich besser ist.

Es geht um eine Auftragsbearbeitung. Es werden pro Tag wohl knapp 40000 Zugriffe auf die Datenbank geschehen. Dabei werden ~10000 Datensätze eingefügt. (Anzahl der Tabellen ist schwer zu sagen wahrscheinlich ~100 aber nur knapp 10 davon werden wohl größere Ausmaße haben (>40 felder) der rest sind dann schlüsseltabellen u.ä)

Über die Jahre kommen da schon ein paar gb and Daten zusammen, ABER zu 99% wird nur mit Daten die bis zu 3 wochen alt sind gearbeitet. Deshalb scheint mir die Tabellenpartitionierung so interessant.

Sicherheit der Daten ist sehr wichtig nur bis jetzt wurd halt gute Erfahrung mit Mysql gemacht (allerdings nicht im vollen betrieb) und die Leute sind schwer davon abzubringen.

Ihr habt gute Erfahrungen mit Mysql und Datensicherheit gemacht? In welcher Parallelwelt lebt ihr? Hallo?

Anyway, wenn ihr solche Datenmengen speichert, ist das nicht wirklich ein Problem. Je nachdem, wieviele Daten sich ändern (updates, deletes) braucht ihr eine brauchbare Strategie, mit den anfallenden Datenmengen an Transaktionsdaten umzugehen. Aber das ist ohne weiteres machbar, halt nur eine Aufgabe, die geklärt werden muss.

Und 40Tausend Zugriffe am Tag sind ein Zugriff alle zwei Sekunden, das ist gar nichts. Aber ich würde euch raten, zu testen, zu testen, noch einen Testcase aufzubauen und dann noch einen Test hinterherzuschieben. Nur so findet ihr im Detail heraus, wo es Probleme geben kann.

Beim Design der Datenbank achtet auf Normalisierung, das wird sich für später als sehr wichtig erweisen, wenn ihr Performance haben möchtet. Alles andere artet später in Arbeit aus und das ist letztendlich nicht gut für die Datenbank.

Ich meinte nur, das bis jetzt noch nie ein crash oder sowas vorkam. Gute Erfahrungen nur insofern, dass die Daten drin sind und die Abfragen so schnell wie gewünscht. (aber wie gesagt nur für einen teil des betriebs, also nicht die datenmengen die ich ansprach)

Ich bin also auf der suche nach einem K.O. Kriterium für MySql, etwas das sich mit Mysql einfach nicht realisieren lässt, unter Postgre aber laufen würde.
Die 3 Sachen in meinem ersten post sind dinge die die Arbeit meiner Meinung nach viel einfacher machen, aber auf umständlichen wege auch mit Mysql gehen.
Mit Datensicherheit kenn ich mich nicht ganz so gut aus inwiefern man da mit hardware auskommt. (

10.000 pro Tag sind ca. 3.6 Millionen pro Jahr. Lächerlich. Okay, wenn Eure Abfragen Seq-Scans
nach sich ziehen und ihr das auf 286er Rechnern macht, dann dauert dies halt…

Mit Partitionierung hab ich selber bisher keine Erfahrung, meine größten Tabellen haben einige
Millionen Zeilen und Abfragen (auf vergleichweise billiger Hardware, 1 CPU) darauf brauchen irgend was im 1-stelligen Millisekundenbreich.
(Es handelt sich um BDE-Daten. Der Hersteller unseres Softwaresystems ist der Meinung, nach ein paar Monaten diese Daten entsorgen zu müssen, weil deren Datenbank, die mit O anfängt
und mit racle endet würde unter so vielen Daten sonst auf einer 4-CPU-Kiste einbrechen…
daher exportiere ich das nach PostgreSQL)

Aber ich glaube, das ist alleine noch kein Argument für/gegen ein spezielles System.
Selbst ein Network File System mit SQL-Interface würde damit zurecht kommen.

Manche Sachen kann man mit Mysql einfach nicht lösen (oder nur, solange keine Probleme auftreten). Dafür kann man einfach mal ein paar Beispiele aufstellen, wenn man so etwas braucht.

Ein wirkliches K.O. Kriterium findest du nicht wirklich, auch weil Mysql in letzter Zeit immer mehr versucht, sich wie eine richtige Datenbank zu verhalten. Nun gut, da fehlt immer noch jede Menge, aber was solls.

Du wirst auch Probleme haben, eine der beiden Datenbanken als besser hinzustellen, vor allem, wenn es Verfechter der anderen Datenbank gibt. Die wirklich wichtigen Sachen zeigen sich erst im laufenden Betrieb oder wenn wirklich mal Probleme auftreten, wie diese gehandelt werden.

Wir haben hier z.B. eine Datenbank mit unter anderem einer Tabelle, die Gästebucheinträge enthält. Diese Tabelle ist auf einem vielbesuchten Studentenportal schlicht die Tabelle, die mit Abstand die meisten Zugriffe hat. Trotz aller Cachingmaßnahmen ect. Gut, ich muss zugeben, die Mysql Version ist eine 4.x Version, ein Update auf 5.x würde zuviel Arbeit machen und der Nachfolger der Software ist praktisch fertig und wird auf Mysql auch definitiv nicht mehr funktionieren.
Ok, aber zum Thema: diese Tabelle ist derzeit 880 MB groß, wird häufig geschrieben, geändert und noch häufiger ausgelesen. In unregelmäßigen Abständen (alle 6-8 Wochen ungefähr) ist sie kaputt und muss manuell repariert werden. Der letzte Ausfall war vor knapp 2 Wochen Sonntag morgens und das war ein Totalausfall, bei dem Mysql rund 200 MB dieser Tabelle schlicht vergessen hat! Die Tabelle war danach nur etwas über 600 MB groß, ließ sich nicht mehr ansprechen und auch nicht mehr reparieren (klar, fehlen ja ein paar Hunderttausend Einträge). Da durften wir dann auf das letzte Backup zurückgreifen …

So etwas darf einer Datenbank einfach nicht passieren. Auch wenn die Version schon etwas älter ist, auch die 4.x hat sich “Datenbank” genannt.

Datensicherheit beginnt dort, wo MySQL aufhört.

Bei Datenbanken möchten man ref. Integrität, zum Beispiel. Man möchte einen Fehler bekommen,
wenn man versucht, ungültige Daten wie einen29.2.2006 in einen Timestamp speichern zu wollen.
Das hat irgendwo natürlich auch was mit Hardware zu tun, aber Du kannst die Hardware nicht verantwortlich machen, wenn Deine Daten einfach nur Schrott sind, aber von einer HA-Hardware kommen.

Ich werde wohl versuchen den Sicherheitsaspekt in den Vordergrund zu stellen da es ja leider anscheinend kein K.O. Kriterium gibt :slight_smile:
Oder vielleicht den super schnellen Forum support hier :smiley:

Vielen Dank schonmal :slight_smile:

Btw.:

Es gibt 2 deutsche Mailinglisten zu PostgreSQL und einen deutschen IRC-Channel.
Du findest dort noch ein paar Leute mehr als hier, u.a. ein Mitglied des PostgreSQL-CORE - Teams.