[linux-l] MySQL PostgreSqL Drupal

[Steffen Dettmer]

* Peter Ross wrote on Sun, Dec 30, 2007 at 11:31 +1100:
> > Ja, ist das so? Ich hatte die letzten Kontakte zu SQL Server 7 (? das
> > vor 2000 jedenfalls) und vermisste etliche Sachen, die in PostgreSQL
> > rudimentär und in Oracle wohl alle vollständig da waren.
> 
> Ich bin kein DBA, aber als SysAdmin sehe ich viele Dinge, die ich
> unter MySQL und PostgreSQL nicht gesehen habe. Z.B. Vollständiges
> Clustering, 

ahh, klingt schonmal komplex :) Was ist Vollständiges Clustering, haste
da zufällig einen Link zur Hand? Hab jetzt ne Stunde gegoogelesen, aber
viele unterschiedlich Sachen gefunden.

> Tablespaces etc. 

Ja, geht wohl erst mit aktuellen PGs komfortabel. Aber auch MSSQL hat
sich ja in den letzten Jahren ganz schön entwickelt... :)

> (Metadata auf anderen Disks als Tables, Indexes anderwo als Logs etc.) 

Indexe in tablespaces geht mit PG 8.1 frei. Ob das früher über `Umwege'
ging, weiss ich nicht. Was man nicht alles braucht, BTW ;)
Logs, also bei PG das WAL auf extra Platte geht seit 7 irgendwas, glaub
ich. Will man dass? Dachte immer, man packt alles auf'n RAID0+1 oder so,
weil die DB WAL und Tablespace nacheinander nutzt und lieber RAID als
extra-Disk? Aber hab davon leider keine Ahnung/Erfahrung.

> - vergleichbar mit DB/2 und Oracle.
> 
> Solche (nicht wirklich) "ausgefallenen" Sachen habe ich mit MySQL oder
> PostgreSQL nie gesehen. Was entweder an fehlenden Features oder
> "hingeschluderten" Installationen liegt.

und/oder daran, dass man für solch anspruchsvollen Projekte lieber DB/2
oder Oracle einsetzt (aus Garantie und Supporterwägungen z.B.).

> Deshalb wollen wir ja auch einen richtigen DBA. Mein Halbwissen reicht da 
> eben nicht.

ich hatte mit sowas nie zu tun, hab immer nur ein-Server-Installationen
gesehen. Spannendes Thema jedenfalls, faszinierend, finde ich.

> Wie die Entscheidung für MYSQL, nebenbei, getroffen  wurde, weiß ich
> nicht zu sagen. Mir scheint, es war ein "Wenn Drupal und wir müssen
> uns entscheiden, nehmen wir am besten das, was hier am verbreitesten
> zu sein scheint, um bei Problemen nicht in irgendeiner Nische ohne
> Support zu stehen" (deshalb ja auch kein MS SQL hier, obwohl wir das
> im Hause haben).
> 
> Wenn das eine offensichtliche Fehlentscheidung ist, dann ist das sicher 
> überdenkenswert.

(mir gings darum gar nicht, wollte bloss bissel was über `richtige'
Datenbanken [nicht DBMSes, sondern DBs] lernen. So wie ich Drupal
verstehe, möchte man [mochte man?] ganz bestimmt nichts anderes als
mySQL, es sei denn, man ist Masochist, und was man über die MSSQL
Unterstützung liest [geht, ging mal, geht doch noch aber], ermutigt
einen auch nur, mySQL zu nehmen)

> Wie sieht es denn z.B. mit o.g. Dingen (Clustering, Tablespaces) unter 
> MySQL und PostgreSQL aus?
> 
> Vor einigen Jahren habe ich mit beiden DBs mehr zu tun gehabt, da war
> Clusterung nicht möglich, MySQL hatte eine
> Master/Servent-DB-Replikation, die wacklig war, Transaktionen gingen
> nicht, PostgreSQL hatte ein Add-On dafur, was noch Beta war...

Ja, das interessiert mich auch. Für PG gibts inzwischen ja mehrere async
replicas. Vielleicht machen einfach zu viele Websachen, wo viel
Session-Kram in Datenbanken steht (was vielleicht gar nicht
müsste/sollte?). Ich glaube, das führt zu eigentlich recht spezifischen
Anforderungen. Wenn ein Webserver nicht weiter cacht, hab ich vielleicht
99% reads auf 1% der Daten, aber ob das verallgemeinerbar ist? Na ja,
komplexes Thema, da sind sich scheinbar die Leute in den PG Foren/Listen
auch nicht so ganz einig...

> Teil des Problems ist auch, daß Features immer schon als vorhanden 
> bezeichnet werden, wenn man bei der Benutzung viele Abers feststellt.

Sogar, dass Features unterschiedlich verstanden werden. Clustering von
Datensätzen vs. Server Clustering, dass man zum load balancing verwenden
kann (idealerweise ohne Einschränkungen) - ein weites Feld...

> Das ist unseriös und macht die Entscheidung nicht einfach. Wer will
> schon alles dreimal implementieren, um die Abers zu finden, bis er
> sich dann für die wirklich funktionierende Lösung entscheiden kann.

bzw. merkt man das auch erst zu spät, genau.

> Langes Rumquälen und vielleicht gar alles wegschmeißen müssen - nichts 
> ruiniert den Ruf einer Lösung so nachhaltig. Das sollten Open 
> Source-Entwickler bedenken. Auch Linux hat dadurch sehr gelitten (lange 
> vielerlei Filesysteme mit verschiedenen Macken, hackeriges Virtual Memory 
> Management, Benchmarks, die mit meinen Erfahrungen nicht übereinstimmten 
> etc.) 

inzwischen geht ja alles wichtige. 3D, Hotplug, automount via Mausklick
mit "Aktion wählen" Dialog (da nimmt man paar Einschränkungen an diesem
Kernel, den man eh nicht sieht, doch gern in Kauf). SCNR as always

> Oder auch wenn die Erfahrungen eines "Mickie-Maus-Projektes", wie
> Volker es so schön nannte, Ausgangspunkt einer seriösen
> Serverimplementierung werden. Manager, aber auch Entwickler, kennen
> nicht unbedingt die Ansprüche, die Administratoren an 24x7-Lösungen
> unter Last stellen müssen.

Ja, das stimmt, ein Grund, Probleme erst zu spät zu erkennen, ja.
Entwickler wissen machmal sogar nichtmal genau, welche Last eigentlich
entsteht (z.B. welche Daten wie oft benutzt werden, welche Sachen wie
`voll' sind und wie benutzt werden etc).

> > MS SQL mit Windows DAO und so ging prima, aber mit ODBC (am besten
> > noch nicht-MS-Treibern) gab es wohl Probleme, so richtig interoperabel
> > wirkte es nicht. Ist das jetzt besser (z.B. wegen JDBC) oder ist das in
> > der Praxis einfach nicht so wichtig?
> 
> Ich lese gerade recht viel über MS SQL und Drupal. Die PHP-Schnitzstelle 
> scheint wohl das Problem zu sein. Man gedenkt, auf ODBC aufzusetzen, um 
> Limitierungen zu vermeiden.
> Zuletzt haben wir MS SQL immer mit Java benutzt, und die Schnittstelle 
> wurde den Java-Entwicklern überlassen, ich höre diesbezüglich keine 
> Klagen.

Muss man gucken. Damals zu MSSQL 2000 Zeiten gab es keinen
MSSQL-ODBC-Treiber für Linux. Eine Lösung war eine `Brücke', die die
logischen Queries über eine eigene Schnittstelle empfängt und via JDBC
ausführt (um ODBC zu umgehen). Gab auch ne ODBC-ODBC Bridge, die wohl
sämtliche Queries konnte (jedenfalls alle, die wir testeten, gingen),
aber Kostenpunkt wohl 2000 EUR aufwärts, weiss nicht mehr genau,
und brauchte extra NT Server. naja, alles lange her.

> Ärger mit Interoperabilität habe ich auch schon mit Oracle erlebt, mit
> Red Hat Enterprise 3.0 und verschiedenen Updates. Zwischen Update 1
> und 3 hat sich das Threading geändert, und dann mußte man auch den
> JDBC-Treiber anders konfigurieren, was mich wohl zwei Tage gekostet
> hat, herauszufinden:-(

na ja, das geht ja, aber wenn sich IS NULL von access und DAO aus
richtig und via ODBC falsch verhält, ist das schon komisch, find ich.

> Aber letztendlich gings, war nur ein "gewußt wie"-Problem. Und unser
> Job wäre ja langweilig, wenns nicht solche Überraschungen gäbe;-)

sagt der Admin oder der Entwickler? ;)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.