Welche Datenbank?
Cybernd
Welche Datenbank verwendet Ihr für größere Datenmengen? Bei meinem
konkreten Anwendungsfall handelt es sich um Produktionsdaten die 24/7/7
gesammelt werden.
Genaugenommen priorisieren alle Kollegen Oracle, aber es kann ja
eigentlich nicht schaden, wenn ich diese Entscheidung mal hinterfrage.
Schließlich kostet jede weitere CPU-Lizenz einen richtig großen Batzen Geld.
Ich hab da heute mal ein wenig Nachgeforscht und bin über einige
interessante Produkte gestolpert. Genaugenommen wäre wohl PostgreSQL,
MaxDB, Ingres, Firebird und (???Sybase???) eine echte alternative.
Sybase in Fragezeichen, da ich bisher noch nicht herausfinden konnte ob
die DB nun OpenSource ist oder nicht. Eine Quelle hat dies berichtet,
aber um ehrlich zu sein konnte ich dies nicht verifizieren.
Welche der genannten Produkte würdet Ihr favorisieren? Wenn ja, aus
welchem Grund?
Bei den AdminToolsets ist wohl Firebird nicht so gut - nur
Consolentools. Unter Sol 10 x86 würde wohl die MaxDB nicht laufen. Etc.
Falls sich ebenfalls jemand für das Thema interessiert: bin da über was
interesanntes gestolpert:
http://opendb.de/2005/06/06/studie-uber-open-source-datenbanken/
(Man betrachte die 60 seitige PDF)
PostgreSQL hat in meinen Augen vielleicht eine Schwäche beim ODBC. Ein
Treiber der Version 0.2 schreckt mich im Produktionsfall doch ein wenig
ab. Alternativ gibt es aber glaub ich einen komerziellen ODBC Treiber
der mit PostgreSQL arbeiten würde. (Einige Win-Clients müssen sich über
ODBC verbinden. Gibts eigentlich sowohl ODBC-JDBC als auch JDBC-ODBC
Bridges? grübel)
so oder so, Feedback würde mich freuen
Bernhard Neuhauser
Sven Köhler
> konkreten Anwendungsfall handelt es sich um Produktionsdaten die 24/7/7
> gesammelt werden.
>
> Genaugenommen priorisieren alle Kollegen Oracle, aber es kann ja
> eigentlich nicht schaden, wenn ich diese Entscheidung mal hinterfrage.
> Schließlich kostet jede weitere CPU-Lizenz einen richtig großen Batzen
> Geld.
Also da wären: MySQL MaxDB und PostgreSQL
Wenn es sich um einfache Daten handelt, ohne irgentwelche Fremdschlüssel
und sowas, dann tut's auch das normale MySQL.
> Ich hab da heute mal ein wenig Nachgeforscht und bin über einige
> interessante Produkte gestolpert. Genaugenommen wäre wohl PostgreSQL,
> MaxDB, Ingres, Firebird und (???Sybase???) eine echte alternative.
> Sybase in Fragezeichen, da ich bisher noch nicht herausfinden konnte ob
> die DB nun OpenSource ist oder nicht. Eine Quelle hat dies berichtet,
> aber um ehrlich zu sein konnte ich dies nicht verifizieren.
Bei Ingres und Firebird weiss ich nicht. Firebird sah mir eher wie eine
verkappte embedded DB aus.
> Welche der genannten Produkte würdet Ihr favorisieren? Wenn ja, aus
> welchem Grund?
MaxDB deshalb, weil sie früher mal SAPDB hieß, und nicht von MySQL ist.
Darüberhinaus hat sie alle Fähigkeiten die man so für eine richtige
Datenbank braucht: Fremdschlüssel, Trigger, Stored Procedures (demnächst
auch Stored Functions), eingebaute Backup-Funktion, usw.
Allerdings merkt man, dass die Datenbank sehr alt ist. Sie wird zwar
weiterentwickelt, aber einige Dinge kommen einem recht steinzeitlich vor.
PostgreSQL wäre die "man kann es auch jeder beliebigen Platform
kompilieren" alternative. (Wie man MaxDB kompiliert, willst du gar nicht
wissen) Es bietet glaube mehr features als MaxDB, von denen man aber
zumindest Tabellenvererbung mit vorsicht genißen sollte. Welche Features
sonst kaputt sind, kann ich nicht sagen. Jedenfalls werden defekte
Features beim Release nicht deaktiviert, was mich stört.
Darüberhinaus kennt PostGreSQL keine richtigen Auto-Increment Spalten.
Es kennt nur spalten, die ihr default aus einer serial beziehen. Das hat
zur Folge, dass wenn man manuell den Wert "7" in die Auto-Increment
Spalte einfügt, man sich auch um das Serial-Objekt kümmern muss, falls
dieses bei einem Wert <= 7 ist.
> Bei den AdminToolsets ist wohl Firebird nicht so gut - nur
> Consolentools. Unter Sol 10 x86 würde wohl die MaxDB nicht laufen. Etc.
Sicherlich würde MaxDB laufen, wenn man sie denn mal so eben kompilieren
könnte :-)
> PostgreSQL hat in meinen Augen vielleicht eine Schwäche beim ODBC. Ein
> Treiber der Version 0.2 schreckt mich im Produktionsfall doch ein wenig
> ab. Alternativ gibt es aber glaub ich einen komerziellen ODBC Treiber
> der mit PostgreSQL arbeiten würde. (Einige Win-Clients müssen sich über
> ODBC verbinden. Gibts eigentlich sowohl ODBC-JDBC als auch JDBC-ODBC
> Bridges? grübel)
Version 0.2 würde ich auch nicht benutzen. Schließlich gibt es doch
Version 8.0:
http://www.postgresql.org/ftp/odbc/versions/msi/
Thomas Kellerer
> Welche Datenbank verwendet Ihr für größere Datenmengen? Bei meinem
> konkreten Anwendungsfall handelt es sich um Produktionsdaten die 24/7/7
> gesammelt werden.
>
> Genaugenommen priorisieren alle Kollegen Oracle, aber es kann ja
> eigentlich nicht schaden, wenn ich diese Entscheidung mal hinterfrage.
> Schließlich kostet jede weitere CPU-Lizenz einen richtig großen Batzen
> Geld.
>
> Treiber der Version 0.2 schreckt mich im Produktionsfall doch ein wenig
> ab. Alternativ gibt es aber glaub ich einen komerziellen ODBC Treiber
> der mit PostgreSQL arbeiten würde. (Einige Win-Clients müssen sich über
> ODBC verbinden. Gibts eigentlich sowohl ODBC-JDBC als auch JDBC-ODBC
> Bridges? grübel)
Zu dem ODBC Treiber kann ich nichts sagen. Nachdem das eine Java Gruppe
ist, wirst Du wohl auch mehr Infos zum JDBC Treiber bekommen :)
Aber meine Erfahrungen mit PostgreSQL waren bis jetzt eher positiv. Ein
paar Ecken und Kanten gibt es natürlich.
Ich habe auch mit Firebird ein wenig gearbeitet. Ich habe den Eindruck, das
Postgres für richtig grosse Datenbank besser skaliert als Firebird.
Postgres ist (meiner Meinung nach) auf jeden Fall MySQL vorzuziehen. MySQL
hinterlässt bei mir immer einen etwas bitteren Nachgeschmack wenn ich
wieder damit zu tun hatte. Wenn es wirklich *nur* auf Performance ankommt,
ist MySQL mit MyIsam allerdings wohl kaum zu schlagen. Ob man sich das
antun möchte sei dahingestellt.
Ich finde auch die Postgres Doku die Beste aus dem Gespann Firebird, MySQL
und Postgres (ich bin allerdings auch jemand, der eher einen
Reference-Guide benutzt als eine genaue Anleitung).
Ein Punkt der vielleicht auch für Postgres spricht: seit einer Weile gibt
es auch eine Implementierung um Java als Sprache für Stored Procedures
einzusetzen.
Interessant sind sicherlich diese beiden Links:
http://sql-info.de/postgresql/postgres-gotchas.html
http://sql-info.de/mysql/gotchas.html
Thomas
Chrischan
> Hiho
>
Hi.
[...]
> Schließlich kostet jede weitere CPU-Lizenz einen richtig großen Batzen
> Geld.
>
Nicht ganz, kommt auf den Anwendungskontext an. Unter der "Developer
License" kannst du in eingeschränkten Rahmen (non-commercial und so
weiter) Oracle benutzen.
Befürchte aber das du Oracle in einem Produktivsystem einsetzt und daher
die DB doch den von Dir angesprochenen Batzen kosten dürfte...
Chrischan
Cybernd
Naja bei mir ists so, das ich bisher unter "Developer" Falle ;o) Ich
Entwickle zum ersten mal mit Oracle und von daher kann ich sie (falls
ich die Lizenz richtig interpretiere) unter meinen Bedingungen
einsetzen. Da wir aber schon damit beginnen (eigentlich nur testweise)
Produktivdaten einzuspeisen um eine Datenbasis fürs Entwickeln zur
Verfügung zu haben, bin ich eigentlich wohl schon an der Grenze zum
komerziellen. Ich kann das zwar damit legitimieren, das wir eigentlich
einen echten richtig schweren Oracle Server im Haus haben, aber da wir
den ja genaugenommen nicht benutzen wäre jetzt der Zeitpunkt gekommen um
über einen wechsel nachzudenken. Entweder auf eine andere DB, oder auf
die lizenzierte Oracle.
Bei der lizenzierten stellt ergeben sich wohl zwei Problempunkte: a)
wieviele Ressourcen sind für meine Zwecke verfügbar und b) wieviel
Kontrolle muß ich abgeben :| Kann ich dann noch immer bedenkenlos mit
allen relevanten Features rumexperimentieren etc.?
Die User Lizenz würde auch nix bringen, da ja dank 24/7 Betrieb doch
ettliche Schichten zusammenkommen und ja laut der User Lizenz
deklaration der benutzende Arbeiter Lizenziert wäre. Und nicht die
Anzahl der konkurrierenden Zugriffe. Von daher kommt so oder so ein
enormer Batzen Geld zusammen, der vielleicht besser in Hardware
investiert werden könnte, da ja die freien Alternativen für den einen
Einsatzzweck auszureichen scheinen ;o)
Bin zum ersten mal mit derartigen Überlegungen konfrontiert, denn bei
den bisherigen privaten Unternehmungen reichte mir die normale mysql
hinterm tomcat.
Ärgerlich empfinde ich zudem beim Oracle, das man wohl ettliche
relevante Downloads nur als Kunde erhält. Die öffentlichen
Developerdownloads scheinen eingeschränkt (der Hausinterne lizenzierte
Client hat eindeutig mehr Features :|). Stört mich aber nicht, da ich
diese Features in der Regel nicht brauche.
Zudem kann man sich ja anders helfen - Irontrack bei sql Analysen als
Beispiel.
cybi
Cybernd
> Also da wären: MySQL MaxDB und PostgreSQL
> Wenn es sich um einfache Daten handelt, ohne irgentwelche Fremdschlüssel
> und sowas, dann tut's auch das normale MySQL.
Sind leider keine einfachen Daten. Hab schon ettliche mit FKs verknüpfte
Entitäten die wohl den einen oder anderen komplexen Analysequery zur
Folge haben werden. Da gerade dort MySQL nicht mehr ganz so gut
skaliert, möchte ich von dieser Variante abstand nehmen. (Bei den
Analysen werd ich wohl selten ohne 10 Tabellen wegkommen :|)
> Bei Ingres und Firebird weiss ich nicht. Firebird sah mir eher wie eine
> verkappte embedded DB aus.
Dachte ich auch bei Firebird. Scheint aber mächtiger zu sein und dennoch
auch embedded Verfügbar zu sein. Was Firebird wohl definitiv von den
anderen Konkurrenten zu unterscheiden scheint, ist die Tatsache das
diese DB scheinbar ohne Daemon auskommt, der ständig die Daten
reorganisieren muß. (Zumindestens stand etwas derartiges in einem
Artikel *g*)
Ist aber bei diversen Polls recht beliebt und hat auch viele
interessante Features.
> MaxDB deshalb, weil sie früher mal SAPDB hieß, und nicht von MySQL ist.
Weil sie von SAP kommt - Ja dabei klingelte es auch bei mir ;o)
Aber das MySQL argument zieht wohl nicht mehr so. Wurde ja an die MySQL
Firma übergeben (wie auch immer die offiziell heißen)
> Allerdings merkt man, dass die Datenbank sehr alt ist. Sie wird zwar
> weiterentwickelt, aber einige Dinge kommen einem recht steinzeitlich vor.
Steinzeitlich schreckt mich nicht ab. Bedeutet zumindestens das die DB
halbwegs erwachsen ist, also viele Kinderkrankheiten bereits behoben
sein müssten.
> PostgreSQL wäre die "man kann es auch jeder beliebigen Platform
> kompilieren" alternative.
Scheinbar aber z.b. recht schlecht unter Windows. Oder klappt das
mittlerweile schon ohne Cygwin layer? Andererseits wer will schon eine
DB unter Windows betreiben ..
> (Wie man MaxDB kompiliert, willst du gar nicht
> wissen)
Okay sol x86 schmink ich mir somit bei der maxDB ab. Ich habs geschafft
Oracle unter Debian zum laufen zu bekommen und ich weiß seit dem wie
haarig das mit dem compilieren sein kann. Recht nett wenn man wärend des
Vorgangs zwischendurch z.b. das JRE auf ein anderes umbiegen muß.
> Es bietet glaube mehr features als MaxDB, von denen man aber
> zumindest Tabellenvererbung mit vorsicht genißen sollte. Welche Features
> sonst kaputt sind, kann ich nicht sagen. Jedenfalls werden defekte
> Features beim Release nicht deaktiviert, was mich stört.
> Darüberhinaus kennt PostGreSQL keine richtigen Auto-Increment Spalten.
> Es kennt nur spalten, die ihr default aus einer serial beziehen. Das hat
> zur Folge, dass wenn man manuell den Wert "7" in die Auto-Increment
> Spalte einfügt, man sich auch um das Serial-Objekt kümmern muss, falls
> dieses bei einem Wert <= 7 ist.
Das mit den Autoincrements lasse ich eigentlich sowieso von Hibernate
erledigen. Dennoch wär es schon angenehm, wenn die Datenbank selber ein
Feature zur Verfügung stellen würde, wodurch man mit standalone
Wartungstools auch mal mühelos einen Eintrag tätigen könnte.
> Sicherlich würde MaxDB laufen, wenn man sie denn mal so eben kompilieren
> könnte :-)
Eventuell wäre ja maxDB so gut um bei Linux hängen zu bleiben.
Andererseits hätt ich schon ganz gern meine isolierenden Zones (hat die
Sol eigentlich schon, oder werden die nachgeliefert? grübel .. muß da
mal nachforschen. Müsste eigentlich sowieso bald mal die nächste Release
erscheinen. Jonas als Zusatz würd mich freuen - Linux binaries ausführen
wär doch ein angenehmes feature)
> Version 0.2 würde ich auch nicht benutzen. Schließlich gibt es doch
> Version 8.0:
> http://www.postgresql.org/ftp/odbc/versions/msi/
Hmmm .. mal nachsehen ob ich die Site noch finde, auf der ich heute den
ganzen Tag lang landete: Postgresql => downloads => odbc =>
Ahhh ich hätt genauer lesen sollen sfg. Das ist ja gar nicht die Version
des Treibers, sondern nur eine Info, von welchem Projekt der Treiber
ursprünglich herkam.
cybi
Sven Roeseler
> Sven Köhler schrieb:
>> PostgreSQL wäre die "man kann es auch jeder beliebigen Platform
>> kompilieren" alternative.
>
> Scheinbar aber z.b. recht schlecht unter Windows. Oder klappt das
> mittlerweile schon ohne Cygwin layer? Andererseits wer will schon eine
> DB unter Windows betreiben ..
Seit Version 8.0 läuft PostgreSQL nativ - also ohne Cygwin - unter
Windows. Bei mir bisher sehr stabil - auch wenn ich sie nur zum
Entwickeln benutze und nicht produktiv.
Sven
--
http://www.svero.in-berlin.de/ - ICQ: #118490064
Peter Köker
> Welche Datenbank verwendet Ihr für größere Datenmengen? Bei meinem
> konkreten Anwendungsfall handelt es sich um Produktionsdaten die 24/7/7
> gesammelt werden.
>
> Genaugenommen priorisieren alle Kollegen Oracle, aber es kann ja
> eigentlich nicht schaden, wenn ich diese Entscheidung mal hinterfrage.
> Schließlich kostet jede weitere CPU-Lizenz einen richtig großen Batzen
> Geld.
Ist auch ähnlich schwergewichtig wie Oracle; in der Hinsicht muß man
sich also nicht umgewöhnen :-)
meint
Peter
geo...@deelite.de
Nachdem ihr Euch nun (bei den kommerziellen Produkten) auf Oracle
festgeschossen habt, wollte ich Euch mal fragen, was eigentlich gegen
die DB2 von IBM spricht? Tests im Internet sind alle pro und contra
Oracle/Db2. Gibt es wirklich so gravierende Unterschiede, weswegen man
auf einem Windows/Linux Server Oracle/Db2 präferieren sollte? Ich
persönlich komme aus der DB2-Ecke und habe mich mit Oracle9i/10g am
Anfang sehr schwer getan. Angefangen hat es schon bei der Installation,
die erst beim x-ten mal sauber durchgelaufen ist. Die Verwaltung der
Datenbank über den OracleManager fand ich eher auch eine Katastrophe.
Nun gut, jetzt kann man sagen, man macht eh nur alles über die
Konsole, aber zum Testen wärs so erst mal praktischer.
Gruß
Daniel
Ingo R. Homann
Sven Köhler wrote:
> Wenn es sich um einfache Daten handelt, ohne irgentwelche Fremdschlüssel
> und sowas, dann tut's auch das normale MySQL.
Nur der Vollständigkeit halber: MySQL unterstützt *mittlerweile*
(Version 4.x?) Fremdschlüssel (zumindest für den DB-Typ InnoDB).
Ciao,
Ingo
Peter Dunkel
Hallo Daniel,
> Nachdem ihr Euch nun (bei den kommerziellen Produkten) auf Oracle
> festgeschossen habt, wollte ich Euch mal fragen, was eigentlich gegen
> die DB2 von IBM spricht?
zu Preisen kann ich wenig sagen, insbesondere da wohl gerne mit Rabatten bei
beiden Anbietern gearbeitet wird.
Pro Oracle: Mit PL/SQL steht eine Scriptsprache, auch für Trigger, zur
Verfügung, vor einigen Jahren gab es bei Oracle einige wichtige Features,
die es bei DB2 nicht gab, Oracle gibt es für MacOSX.
Kontra Oracle: gibt es nicht für die AS/400 (IBM I-Serie), einige Dinge
(Outer Joins) vom Syntaks gewöhnungsbedürftig, Administration eher
aufwendig.
Pro DB2: DB2 "skaliert" besser (wirklich "dicke" Datenbanken laufen auf DB2
unter z/OS), die Einbindung von Scriptsprachen (REXX) ist möglich, die
Einbindung von Compilersprachen auch in Triggern ist möglich. Bei Kunden,
wo es IBM Mainframe im Einsatz ist (ich arbeite eigentlich nur für solche
Kunden) macht Oracle wenig Sinn.
Nachteil DB2: Es fehlt etwas wie PL/SQL.
> Gibt es wirklich so gravierende Unterschiede, weswegen man
> auf einem Windows/Linux Server Oracle/Db2 präferieren sollte?
Was Angebot von IBM ist etwas runder, wenn man die WebSphere, Rational und
DB2 zusammen nimmt. Wenn es um Windows-Server geht, würde ich übrigens eher
an MS-SQL-Server denken, bei Linux könnte man auch andere (Open-Source) DBM
nutzen (bei einem OLTP-Systen eher nicht MySQL, es gibt aber ausreichend
Auswahl). Eine andere Alternative, insbesondere bei kleineren Projekten
wäre Apache Derby, wenn man dort an die Grenzen stösst, ist der Weg
Richtung IBM DB2 leicht möglich.
> Ich
> persönlich komme aus der DB2-Ecke und habe mich mit Oracle9i/10g am
> Anfang sehr schwer getan. Angefangen hat es schon bei der Installation,
> die erst beim x-ten mal sauber durchgelaufen ist. Die Verwaltung der
> Datenbank über den OracleManager fand ich eher auch eine Katastrophe.
Ich habe mal mit Kollegen eine Oracle 8 auf WinNT aufgesetzt, war recht
problematisch, mit DB2 hatte ich unter OS/2, Linux und WinXP nie solche
Probleme.
Historisch (also vor gut 10 Jahren) gabe es DB2 eigentlich nur für
IBM-Rechner (OS/2, AIX, OS/400, OS/390), für die Unix-Welt hatte man die
Auwahl zwischen Sybase, Informix und Oracle, wobei Oracle klar an den
anderen Beiden vorbeizog. Deshalb haben die meisten Admins im Unix-Bereich
(Solaris, ...) gute Oracle-Kenntnisse.
Ist so ähnlich wie mit dem "vi" als Editor, dessen Bedienung sich für
jemanden, der mit anderen Editoren arbeitet, schwer erschliesst. Die heute
auf allen Unixen verfügbaren Alternativen (ich mag JEdit, bei Bedarf nujtze
ich auch einen Pico-Klone, es gibt aiuch brauchbare Editoren unter X11)
gelten bei vielen Unix-Freaks wenig.
mfg Peter