Hallo,
für einen Server unter meiner Obhut muss mich mich jetzt entscheiden, ob ich in Zukunft PostgreSQL oder weiter MySQL einsetzen werde.
Ich weiß, dass viele hier PostgreSQL für besser befinden, aber da ich mich mit Datenbanken nicht so gut auskenne sind mir die Gründe dafür leider unklar. Auch scheint mir Postgres ein bißchen langsamer zu sein. (Ich kann mich täuschen.) Für MySQL spricht weiterhin, dass es von mehr Anwendungen unterstützt wird.
Zu den Rahmenbedingungen: Es handelt sich um einen 800MHz Athlon mit 320MB RAM. Darauf läuft ein Forum (MySQL) und diverse kleine Datenbank-Anwendungen (z.B. ulogd). In Zukunft will ich dort auch eine Groupware (testweise auf Postgres) betreiben, die, wie es scheint, einiges an Resourcen braucht. Eigene Datenbankanwendungen zu entwickeln, ist nicht geplant, ich will hauptsächlich auf schon vorhandene Software zurückgreifen. Im Testbetrieb laufen beide Datenbankserver nebeneinander, was mich nicht gerade glücklich macht.
Ich hoffe ihr könnt mir eine Entscheidungshilfe geben. Lohnt es sich, das Forum zu migrieren und MySQL abzuschalten? Oder soll ich die Groupware auf MySQL neuinstallieren (da ist noch nicht viel geschehen) und auf den überlegenen(?) Postgres verzichten?
Es grüßt
Frank Benkstein.
PS: Google habe ich schon zu PostgreSQL vs. MySQL befragt, aber nicht viel Hilfreiches gefunden.
am Mon, dem 12.04.2004, um 14:40:36 +0200 mailte Frank Benkstein folgendes:
Ich weiß, dass viele hier PostgreSQL für besser befinden, aber da ich
Beides hat Vor- und Nachteile.
mich mit Datenbanken nicht so gut auskenne sind mir die Gründe dafür leider unklar. Auch scheint mir Postgres ein bißchen langsamer zu sein. (Ich kann mich täuschen.) Für MySQL spricht weiterhin, dass es von mehr Anwendungen unterstützt wird.
PostgreSQL kann Dinge, die MySQL nicht oder nicht richtig gut kann: - referentielle Integrität - Transaktionen - vollständigere Umsetzung von SQL-Befehlen (Subselects) - integrierte Sprachen
Lohnt es sich, das Forum zu migrieren und MySQL abzuschalten?
Wenn es tut und Du bisher Dinge, die PostgreSQL kann, nicht gebraucht hast, dann brauchst Du es nicht ;-)
In Umgebungen, wo sehr viele schreibend und lesend zugreifen und Du Dinge wie referentielle Integrität und Transaktionen brauchst, macht PostgreSQL Sinn, ansonsten ist MySQL keine schlechte Wahl. Viele Dinge, die MySQL vor 2-3 Jahren noch nicht konnte, kann es mittlerweile, die Entwicklung geht sehr schnell. Möglicherweise habe ich weiter oben auch Dinge gesagt, die mittlerweile überholt sind.
Oder soll ich die Groupware auf MySQL neuinstallieren (da ist noch nicht viel geschehen) und auf den überlegenen(?) Postgres verzichten?
Wenn die Groupware OpenGroupWare ist, wirst Du IMHO PostgreSQL brauchen. Ansonsten ist PostgreSQL halt eben die 'größere' Alternative. Ich verwende sie auch, obwohl MySQL es sicher auch täte, verwende aber auch Dinge wie referentielle Integritätsprüfungen, weil ich zu faul bin, es selber zu stricken ;-)
Andreas
On Mon, 12 Apr 2004 14:57:02 +0200 Andreas Kretschmer kretschmer@kaufbach.delug.de wrote:
am Mon, dem 12.04.2004, um 14:40:36 +0200 mailte Frank Benkstein folgendes:
Ich weiß, dass viele hier PostgreSQL für besser befinden, aber da ich
Beides hat Vor- und Nachteile.
Das dachte ich mir schon. ;-)
[...]
PostgreSQL kann Dinge, die MySQL nicht oder nicht richtig gut kann:
- referentielle Integrität
- Transaktionen
- vollständigere Umsetzung von SQL-Befehlen (Subselects)
- integrierte Sprachen
Aha.
Lohnt es sich, das Forum zu migrieren und MySQL abzuschalten?
Wenn es tut und Du bisher Dinge, die PostgreSQL kann, nicht gebraucht hast, dann brauchst Du es nicht ;-)
Eigentlich tut es, aber ich dachte, dass Postgres "sicherer"(?) ist.
In Umgebungen, wo sehr viele schreibend und lesend zugreifen und Du Dinge wie referentielle Integrität und Transaktionen brauchst, macht PostgreSQL Sinn, ansonsten ist MySQL keine schlechte Wahl. Viele Dinge, die MySQL vor 2-3 Jahren noch nicht konnte, kann es mittlerweile, die Entwicklung geht sehr schnell. Möglicherweise habe ich weiter oben auch Dinge gesagt, die mittlerweile überholt sind.
Hm, ok, ich setze ja einen relativ aktuellen MySQL ein.
Oder soll ich die Groupware auf MySQL neuinstallieren (da ist noch nicht viel geschehen) und auf den überlegenen(?) Postgres verzichten?
Wenn die Groupware OpenGroupWare ist, wirst Du IMHO PostgreSQL brauchen.
Es handelt sich um phpgroupware, bzw. um deren Fork egroupware. Die betonen in ihrer Doku weder den einen noch den anderen.
Ansonsten ist PostgreSQL halt eben die 'größere' Alternative. Ich verwende sie auch, obwohl MySQL es sicher auch täte, verwende aber auch Dinge wie referentielle Integritätsprüfungen, weil ich zu faul bin, es selber zu stricken ;-)
Selber entwickeln wollte ich ja gerade nicht.
Danke für deine Meinung.
On Monday 12 April 2004 14:40, Frank Benkstein wrote:
Ich weiß, dass viele hier PostgreSQL für besser befinden, aber da ich mich mit Datenbanken nicht so gut auskenne sind mir die Gründe dafür leider unklar. Auch scheint mir Postgres ein bißchen langsamer zu sein. (Ich kann mich täuschen.) Für MySQL spricht weiterhin, dass es von mehr Anwendungen unterstützt wird.
*besseres Transaktionsmanagement *komplettere Umsetzung des SQL-Standard *skaliert besser
Postgres skaliert anders als MySQL: *MySQL ist auf kleine Anwendungen optimiert (MyFotoAlbum oder so) *MySQL performt besser, solange Schreibzugriffe selten sind
*Postgres ist auf grosse DBs optimiert (das CERN hat angeblich eine im TeraByte Bereich) *wesentlich bessere Transaktionstrennung ("concurrent versions" statt "lock") *skaliert auch bei starkem Mischbetrieb gut (es ist kein Problem zu lesen, während jemand das selbe Datenfeld schreibt: bis die Schreibtransaktion abgeschlossen ist sieht man die alte Version; es können viele gleichzeitig in die selbe Tabelle schreiben) *verträgt mehr Nutzer
Zu den Rahmenbedingungen: Es handelt sich um einen 800MHz Athlon mit 320MB RAM. Darauf läuft ein Forum (MySQL) und diverse kleine Datenbank-Anwendungen (z.B. ulogd). In Zukunft will ich dort auch eine Groupware (testweise auf Postgres) betreiben, die, wie es scheint, einiges an Resourcen braucht.
Dann würde ich das Teil auf Postgres lassen. Den Rest zu migrieren macht nur Sinn, wenn es trivial geht. Ansonsten sind Foren relativ unkritische Anwendungen für eine DB.
Die DB von ulogd wird vermutlich nur von dem ulogd benutzt, ohne grosse Anforderungen an Interaktivität. Also auch relativ unkritisch.
Andererseits sind die Anforderungen an eine Groupware höher (Multiuser, es dürfen keine Daten verlorengehen, inkonsistente Daten können schnell in eine Katastrophe ausarten). Also halte ich MySQL für eine schlechte Wahl für Groupware (sollten die Autoren es geschafft haben die Integritäts-Probleme von MySQL zu umgehen, dann wird es sehr schlecht skalieren).
Eigene Datenbankanwendungen zu entwickeln, ist nicht geplant, ich will hauptsächlich auf schon vorhandene Software zurückgreifen. Im Testbetrieb laufen beide Datenbankserver nebeneinander, was mich nicht gerade glücklich macht.
Was ist daran schlimm? Bei mir laufen auf allen Maschinen diese beiden parallel, zeitweise noch weitere DBMs.
Ich hoffe ihr könnt mir eine Entscheidungshilfe geben. Lohnt es sich, das Forum zu migrieren und MySQL abzuschalten? Oder soll ich die Groupware auf MySQL neuinstallieren (da ist noch nicht viel geschehen) und auf den überlegenen(?) Postgres verzichten?
Weder noch. Ich würde beide parallel laufen lassen - der Portierungsaufwand von MySQL auf Postgres ist vermutlich recht hoch; die Groupware auf MySQL laufen zu lassen schreit aber regelrecht nach Problemen.
Neue Anwendungen würde ich konsequent auf Postgres aufsetzen.
Wie gesagt, die beiden vertragen sich auf meinen Rechnern hervorragend. Zanken sich kaum, lassen sich die meiste Zeit in Ruhe... ;-)
Konrad
On Mon, 12 Apr 2004 16:29:03 +0200 Konrad Rosenbaum konrad@silmor.de wrote:
On Monday 12 April 2004 14:40, Frank Benkstein wrote:
Im Testbetrieb laufen beide Datenbankserver nebeneinander, was mich nicht gerade glücklich macht.
Was ist daran schlimm? Bei mir laufen auf allen Maschinen diese beiden parallel, zeitweise noch weitere DBMs.
Lohnt es sich, das Forum zu migrieren und MySQL abzuschalten? Oder soll ich die Groupware auf MySQL neuinstallieren (da ist noch nicht viel geschehen) und auf den überlegenen(?) Postgres verzichten?
Weder noch. Ich würde beide parallel laufen lassen - der Portierungsaufwand von MySQL auf Postgres ist vermutlich recht hoch; die Groupware auf MySQL laufen zu lassen schreit aber regelrecht nach Problemen.
Neue Anwendungen würde ich konsequent auf Postgres aufsetzen.
Wie gesagt, die beiden vertragen sich auf meinen Rechnern hervorragend. Zanken sich kaum, lassen sich die meiste Zeit in Ruhe... ;-)
Schon klar, aber ich habe da Performance-Bedenken. Die Groupware scheint manchmal ganz schön lange zu "überlegen", kann aber auch an meiner momentan mal wieder schlechten Netz-Verbindung liegen.
Deinen Rat zu befolgen hat natürlich einen großen Vorteil: ich muss nichts machen.
Danke erstmal.
On Monday 12 April 2004 17:32, Frank Benkstein wrote:
Schon klar, aber ich habe da Performance-Bedenken. Die Groupware scheint manchmal ganz schön lange zu "überlegen", kann aber auch an meiner momentan mal wieder schlechten Netz-Verbindung liegen.
Was liegt da sonst noch drunter? Ein IMAP-Verzeichnis zu scannen kann ganz schön lange dauern (mein Squirrelmail nimmt sich für große Folder jedenfalls reichlich Zeit).
Konrad
On Mon, 12 Apr 2004 18:35:16 +0200 Konrad Rosenbaum konrad@silmor.de wrote:
On Monday 12 April 2004 17:32, Frank Benkstein wrote:
Schon klar, aber ich habe da Performance-Bedenken. Die Groupware scheint manchmal ganz schön lange zu "überlegen", kann aber auch an meiner momentan mal wieder schlechten Netz-Verbindung liegen.
Was liegt da sonst noch drunter?
Nix. Das hakt schon bei den Zugriffen auf das Adressbuch, ToDo etc.
Ein IMAP-Verzeichnis zu scannen kann ganz schön lange dauern (mein Squirrelmail nimmt sich für große Folder jedenfalls reichlich Zeit).
IMAP geht bei mir eigentlich angenehm flott, so viele Emails sind da bei mir ja nicht drin. Ich werde es morgen mal von einer richtigen Leitung aus testen.
On Mon, Apr 12, 2004 at 04:29:03PM +0200, Konrad Rosenbaum wrote:
On Monday 12 April 2004 14:40, Frank Benkstein wrote:
Hi Konrad,
Andererseits sind die Anforderungen an eine Groupware höher (Multiuser, es dürfen keine Daten verlorengehen, inkonsistente Daten können schnell in eine Katastrophe ausarten). Also halte ich MySQL für eine schlechte Wahl für Groupware (sollten die Autoren es geschafft haben die Integritäts-Probleme von MySQL zu umgehen, dann wird es sehr schlecht skalieren).
Hmm, also irgendwie kommt MySQL hier etwas schlecht weg... MySQL ist ein ausgereiftes und auch im Mission Critical Bereich eingesetztes Datenbanksystem das für so etwas lapidaren wie eine Groupware-Anwendung auf alle Fälle geeignet ist.
Ciao, Tobias
Tobias Koenig said:
On Mon, Apr 12, 2004 at 04:29:03PM +0200, Konrad Rosenbaum wrote:
Andererseits sind die Anforderungen an eine Groupware höher (Multiuser, es dürfen keine Daten verlorengehen, inkonsistente Daten können schnell in eine Katastrophe ausarten). Also halte ich MySQL für eine schlechte Wahl für Groupware (sollten die Autoren es geschafft haben die Integritäts-Probleme von MySQL zu umgehen, dann wird es sehr schlecht skalieren).
Hmm, also irgendwie kommt MySQL hier etwas schlecht weg... MySQL ist ein ausgereiftes und auch im Mission Critical Bereich eingesetztes Datenbanksystem das für so etwas lapidaren wie eine Groupware-Anwendung auf alle Fälle geeignet ist.
Ich muss zugeben ich habe mich schon eine Weile nicht mehr intensiv mit MySQL beschaeftigt. Aber nach allem, was ich gehoert habe funktionieren deren Transaktion nur mit bestimmten Tabellentypen. Ich persoenlich habe kein sehr gutes Gefuehl bei dem Gedanken dass Transaktionen, also etwas Tabellenuebergreifendes, vom Tabellentyp abhaengen.
...uebrigens werden manchmal Dinge als "mission critical" bezeichnet, die es nicht sind. Und es wird in diesem Bereich oefter geschlampt als Du denkst.
Konrad
On Tue, Apr 13, 2004 at 03:51:50PM +0200, Konrad Rosenbaum wrote:
Tobias Koenig said:
Hi Konrad,
Hmm, also irgendwie kommt MySQL hier etwas schlecht weg... MySQL ist ein ausgereiftes und auch im Mission Critical Bereich eingesetztes Datenbanksystem das für so etwas lapidaren wie eine Groupware-Anwendung auf alle Fälle geeignet ist.
Ich muss zugeben ich habe mich schon eine Weile nicht mehr intensiv mit MySQL beschaeftigt. Aber nach allem, was ich gehoert habe funktionieren deren Transaktion nur mit bestimmten Tabellentypen. Ich persoenlich habe kein sehr gutes Gefuehl bei dem Gedanken dass Transaktionen, also etwas Tabellenuebergreifendes, vom Tabellentyp abhaengen.
Transaktionen sind nicht abhängig vom verwendeten Tabellentyp, sondern vom verwendeten Datenbankbackend (also wenn man Transaktionen möchte verwendet man nicht ISAM sondern irgend so ein anderes Format).
Ciao, Tobias
Tobias Koenig said:
On Tue, Apr 13, 2004 at 03:51:50PM +0200, Konrad Rosenbaum wrote:
Ich muss zugeben ich habe mich schon eine Weile nicht mehr intensiv mit MySQL beschaeftigt. Aber nach allem, was ich gehoert habe funktionieren deren Transaktion nur mit bestimmten Tabellentypen. Ich persoenlich habe kein sehr gutes Gefuehl bei dem Gedanken dass Transaktionen, also etwas Tabellenuebergreifendes, vom Tabellentyp abhaengen.
Transaktionen sind nicht abhängig vom verwendeten Tabellentyp, sondern vom verwendeten Datenbankbackend (also wenn man Transaktionen möchte verwendet man nicht ISAM sondern irgend so ein anderes Format).
InnoDB zum Beispiel. Quote von www.mysql.org: "In SQL queries you can freely mix InnoDB type tables with other table types of MySQL, even within the same query."
Die InnoDB Engine speichert also durchaus mehrere Tabellen, aber eine Datenbank ist nicht auf diesen Typ beschraenkt. Obwohl MySQL behauptet voll "ACID compliant" zu sein, sehe ich nicht ganz, wie man in so einer Umgebung volle Transaktionsisolation (Serialized Level) hinbekommen will.
Fuer die meisten Anwendungen wird das erreichbare Level sicherlich ausreichen, aber ich zweifle noch immer ob es fuer kritische Umgebungen geeignet ist.
...kann natuerlich sein, dass mein Intellekt einfach zu beschraenkt ist, um das zu begreifen.
Konrad
On Tue, Apr 13, 2004 at 04:23:35PM +0200, Konrad Rosenbaum wrote:
Tobias Koenig said:
Hi Konrad,
Transaktionen sind nicht abhängig vom verwendeten Tabellentyp, sondern vom verwendeten Datenbankbackend (also wenn man Transaktionen möchte verwendet man nicht ISAM sondern irgend so ein anderes Format).
InnoDB zum Beispiel. Quote von www.mysql.org: "In SQL queries you can freely mix InnoDB type tables with other table types of MySQL, even within the same query."
Also wenn man nur Tabellen vom Typ InnoDB verwendet hat man volle Transaktionunterstützung, wo liegt das Problem? Man hat sogar den Vorteil (gegenüber PostgreSQL), das man für Tabellen die keine Transaktionen benötigen (da z.B. nur lesend zugegriffen wird oder das atomare Schreiben eine Ebene höher sowieso schon geregelt wird) auf den Overhead verzichten kann. IMHO ist das keine Einschränkung sondern sogar ein richtig nettes Feature.
Die InnoDB Engine speichert also durchaus mehrere Tabellen, aber eine Datenbank ist nicht auf diesen Typ beschraenkt. Obwohl MySQL behauptet voll "ACID compliant" zu sein, sehe ich nicht ganz, wie man in so einer Umgebung volle Transaktionsisolation (Serialized Level) hinbekommen will.
Hmm, also MySQL.com verkaufen Lösungen die auf MySQL beruhen auch an große Firmen, wenn die Software so schlecht wäre wie du behauptest wäre das Unternehmen sicher schon Pleite...
Ciao, Tobias
On Wed, 2004-04-14 at 16:45, Tobias Koenig wrote:
Hmm, also MySQL.com verkaufen Lösungen die auf MySQL beruhen auch an große Firmen, wenn die Software so schlecht wäre wie du behauptest wäre das Unternehmen sicher schon Pleite...
Du bist noch nicht lange in dieser Branche tätig, oder? ;-)
Eric
p.s. Das soll keine Wertung von mysql sein...
On Wednesday 14 April 2004 19:21, Eric Schaefer wrote:
On Wed, 2004-04-14 at 16:45, Tobias Koenig wrote:
Hmm, also MySQL.com verkaufen Lösungen die auf MySQL beruhen auch an große Firmen, wenn die Software so schlecht wäre wie du behauptest wäre das Unternehmen sicher schon Pleite...
Du bist noch nicht lange in dieser Branche tätig, oder? ;-)
Genau Eric.
Um mal was gutes über MySQL AB zu sagen: deren SW ist immernoch um Größenordnungen besser als einige andere SW von Firmen, die partout nicht pleite gehen wollen. Ich habe schon Sachen gesehen... (und dabei bin ich erst 3-4 Jahre dabei).
Ich bin mir inzwischen sicher, dass Wirtschaft absolut intuitionswidrig funktioniert(*):
*Erfolgreiche Firmen sind nicht "wegen", sondern "trotz" ihres Management erfolgreich.
*Hard-/Software verkauft sich nicht "wegen", sondern "trotz" ihrer Qualität.
*Standards erreichen nur in Ausnahmefällen Kompatibilität.
*Der Anbieter mit den buntesten Prospekten bekommt den Vertrag.
*Die teuerste Lösung ist nahezu zwangsläufig die schlechteste, passt also am besten zu Qualität der vorhandenen Umgebung und wird deswegen genommen.
*Interfaces sind nicht zum effizienten Datentransfer da, sondern zum zuverlässigen Löschen der wichtigsten Daten.
*Effizienz hält nur unnötig von der Arbeit ab. (**)
*Terminüberschreitungen gleichen sich gegenseitig aus. (**)
*etc.pp.
(*)"funktioniert" ist eigentlich ein zu optimistischer Begriff.
(**)Die Lösung für diese beiden Terme versteht man erst, wenn man es oft genug erlebt hat. Versuch' es mal... ;-)
Konrad
On Thursday 15 April 2004 01:26, Holger Dietze wrote:
On Wed, Apr 14, 2004 at 07:51:20PM +0200, Konrad Rosenbaum wrote:
*Standards erreichen nur in Ausnahmefällen Kompatibilität.
Standards _sollen_ ja zueinander inkompatibel sein - wozu braeuchten wir sonst die vielen Kommisionen?
Nein, ich meine schon einzelne "eindeutige" Standards. Beispiel: nahezu alle X.509-Implementationen sind zueinander inkompatibel.
Konrad
Hallo,
On Wed, Apr 14, 2004 at 07:21:58PM +0200, Eric Schaefer wrote:
On Wed, 2004-04-14 at 16:45, Tobias Koenig wrote:
Hmm, also MySQL.com verkaufen L�sungen die auf MySQL beruhen auch an gro�e Firmen, wenn die Software so schlecht w�re wie du behauptest w�re das Unternehmen sicher schon Pleite...
Du bist noch nicht lange in dieser Branche t�tig, oder? ;-)
Ausserdem macht es einen gewaltigen Unterschied, ob man sehr viele kleine Problem loest oder ein riesengrosses.
Holger
On Wednesday 14 April 2004 16:45, Tobias Koenig wrote:
Also wenn man nur Tabellen vom Typ InnoDB verwendet hat man volle Transaktionunterstützung, wo liegt das Problem?
Normalerweise werden Transaktionen pro DB geregelt. Wenn Du sie auf Tabellenebene runterziehst wird die Lock- bzw. Versions-verwaltung/-erkennung extrem aufwändig (zumindest, wenn Du das Serializable Level erreichen willst). Theoretisch alles möglich aber eben extrem schwierig.
Wie gesagt: ich teste das mal bei Gelegenheit.
Man hat sogar den Vorteil (gegenüber PostgreSQL), das man für Tabellen die keine Transaktionen benötigen (da z.B. nur lesend zugegriffen wird oder das atomare Schreiben eine Ebene höher sowieso schon geregelt wird) auf den Overhead verzichten kann.
Bei Versionierung (im Gegensatz zu Locking) ist der Transaktionsoverhead für das Lesen minimal. Ausserdem würde ich jedem Designer, der eine Tabelle als Read-Only einstuft, zum Arzt schicken: das mag in dieser Version stimmen, in der nächsten ändert sich garantiert alles.
Philosophische Frage: Wozu nehme ich eine Datenbank, wenn ich nur eine Datei brauche?
<seufz> Ich hab' schon zuviel Realität abgekriegt! Das ist das, wo keiner überlegt, warum optimiert wurde, wo keiner ein Redesign wagt, wo es meistens gutgeht und keiner weiß warum, wo es schiefgeht und keiner war's gewesen, .... ...wo man es von Anfang an RICHTIG machen muss, weil es sonst nie in Ordnung gebracht wird, wo man den Entwicklern/Designern keine Intelligenz abverlangen darf...
Ich will wieder in den Kindergarten!
...ach halt. Da bin ich ja schon(*). ;-( </seufz>
(*)Nein, ich meine nicht die Mailliste.
IMHO ist das keine Einschränkung sondern sogar ein richtig nettes Feature.
<irony> Bei dieser Klospülung geht unter Umständen nicht alles weg, aber wir haben da ein viel praktischeres Feature installiert: mit der Wassereimereinrichtung haben Sie die volle Kontrolle über den Spülvorgang. </irony>
Sorry.
Konrad
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Eric Schaefer -
Frank Benkstein -
Holger Dietze -
Konrad Rosenbaum -
Stefan Lagotzki -
Tobias Koenig