Die Henne oder das Ei? MySQL Bzw. Firebird, oder PostgreSQL
-
Das Problem ist einfach, dass die Kommerziellen dann wie MySQL-Enterpreise einiges im Jahr kosten. Oder eben wie MS dann mal eben zwischen 5000 und 30000. Wir haben die Datenbank-Server aber pro Anlage. Damit haben wir so 10 Stück, die pro Jahr rausgehen. Das ist ein Posten, der jeden Verkaufspreis nochmal böse anhebt. Das ist leider nicht ein Server, der irgendwo steht und Ende... Da hat jede Anlage ihre eigene Datenbank onboard. Bisher wurde alles in Dateien abgelegt. Was sich als schrecklich inperformant und unsicher heraustellt. Sämtliche Berater sagen ganz klar nutzt Datenbanken. Sowohl für Speicherung als auch Kommunikation zwischen den Anwendungen.
Und wenn ich so die Industrie in unserem Umfeld betrachte, dann hat eigentlich JEDES Messgerät oder jede Software Datenbanken am Laufen.
Also mich hat gerade bei der Postgres-Installation beeindruckt, dass beispielsweise die ganzen Tools und Packages bei der Isntallation ausgewählt und mitinstalliert werden können. Firebird und MySQL haben nur die Server beinhaltet. Fertig.
-
Warum sollen die Grafiken mit in die DB gesichert werden? Es könnte ja auch nur eine Referenz auf ein Filesystem-Objekt in der DB verwaltet werden. Soll deren Verarbeitung in eine Transaktion gekapselt werden, so dass eine Rollback()-Operation auf sie ausgeführt werden muss? Ein Filesystem wäre preiswerter. Wenn die Images dennoch in die DB gesichert werden sollen und Du postgresql verwenden willst, kannst Du Dir die Dokumentation zur TOAST-Speicherarchitektur mal durchlesen, um zu prüfen, wieweit diese eingelagerten Images die Performance drücken.
-
witte_ schrieb:
Warum sollen die Grafiken mit in die DB gesichert werden? Es könnte ja auch nur eine Referenz auf ein Filesystem-Objekt in der DB verwaltet werden. Soll deren Verarbeitung in eine Transaktion gekapselt werden, so dass eine Rollback()-Operation auf sie ausgeführt werden muss? Ein Filesystem wäre preiswerter. Wenn die Images dennoch in die DB gesichert werden sollen und Du postgresql verwenden willst, kannst Du Dir die Dokumentation zur TOAST-Speicherarchitektur mal durchlesen, um zu prüfen, wieweit diese eingelagerten Images die Performance drücken.
Hilfe langsam. Ich bin noch frisches DB-Opfer. Quasi bis auf ein wenig phpbb2-Datenbank-Erfahrung noch unerfahren in der Thematik.
Erklärst du mir bitte kurz die Rollback-Aktion?Naja dass die rein MÜSSEN war nicht meine Idee. Verknüpfung geht natürlich auch. Hat hatl den NAchteil, dass das Filesystem mitgesichert werden müsste... Und wir wollen von den Files weg. Aber wenn das die Karre so ausbremst...
Hab gerade angefangen mir die Postgres Tutorials mal durchzulesen. IRgendwo muss man ja anfangen... Hab noch ein Video2Brain SQL Video... DAs ist danach fällig...
-
Und hier gibts noch ein komplettes Buch zu PostgreSQL
http://www.postgresql.org/docs/books/pghandbuch.html.de
-
War das nun dein ernst:
XEON Quad-CPU WIN XP
So große Bilder als BLOB ist nicht ratsam.
Wie wollt ihr den hier die DB sichern wenn die Bilder als BLOB gespeichert werden.
Ihr sollte schon dem Endkunden überlassen wie er seine Daten ablegen möchte.
Was wenn er bereits einen DB-Server oder eine Farm hat.
-
Na da sag ich doch jetzt mal fett Danke für den Link. Soweit war ich noch gar nicht auf der Postgres-Page unterwegs.
Übrigends auch hier nochmal danke an alle anderen Poster für die Tips und die Hilfe. In Foren wird sich ja selten bedankt.
-
witte_ schrieb:
Warum sollen die Grafiken mit in die DB gesichert werden? Es könnte ja auch nur eine Referenz auf ein Filesystem-Objekt in der DB verwaltet werden...
Ich will zumindestens auch Gründe nennen die dafür sprechen könnten (Man muss halt gegeneinander abwägen):
a) Einheitliches Rechtemanagement
b) Dateien können nicht einfach weg gelöscht werden, was zu toten Links führen könnteWenn es sich jetzt nicht um die wahnsinnigen Datenmengen handeln würden wie vom OP genannt, wären diese zwei Punkte aus sehr schlechten Erfahrungen durchaus überlegenswert (Komprimieren sollte man sofern möglich aber egal wie).
cu André
-
Habt Ihr eigentlich mal Euer Speicheraufkommen berechnet? Wieweit sollen diese Images augehoben werden? Also bei 1440min/d und maximal alle 3 min ein Shot sind 500 das Images/d. Können die Daten auf 1/10 komprimiert werden sind das 20G/d. Nach zwei Monaten ist ein Terabyte gefüllt. Vielleicht solltet Ihr erstmal die Anwendungslogik überlegen, bevor wir über DB vs. Filesystem reden.
-
Sehe ich auch so wie _witte.
Was ihr dann also unbedingt noch braucht, ist ein gescheites Archivierungssystem (oder aber ihr müßt irgendwann die alten Images wegschmeissen). Ich würde aber auf keinen Fall (zumindestens mit den aktuellen Datenbanken) die Bilder mit in die DB speichern, weil dann ist jede Performanz im Keller (bzgl. des Page-Cachings).
Was soll denn sonst noch an Daten in die DB gespeichert werden (d.h. wieviele Daten kommen noch pro Bild hinzu)?
Ich halte PostgreSQL auch für die beste kostenlose Datenbank, aber ich befürchte, für euer Projekt benötigt ihr wahrscheinlich dann doch früher oder später eine proprietäre Lösung...
-
Shogun schrieb:
Wir reden hier von Bildern 6144x640x31. Und nein das ist kein Tippfehler. 31 Dimensionen. Keine 3.
klugscheiß: 6144x640x31 sind sehr wohl 3 dimensionen, und zwar 6133 px in die 1. dimension, 640 in die zweite und 31 pixel/einheiten in die 3. dimension
ein 31-dimensionales bild hätte z.B. folgende Ausmaße 1x2x3x4x3x2x1x2x3x4x5x6x7x8x8x9x7x6x5x4x3x4x5x6x5x4x3x2x3x4x1. Hier könnte ich mir allerdings keinen einzigen praktischen anwendungszweck vorstellen
-
Ich war noch nie so recht begeistert die großen Bilder zu sichern. Zur Zeit werden nur RGBs als TIF rausgeschrieben und alle 2 Monate müssen wir so schon eine 500GB Platte wieder teilweise abräumen.
Die letzte Planung ist ja noch nciht gelaufen. Das ist alles noch in der Schwebe. Es sind zwar in der Realität weit weniger Messungen am Tag als die 500, aber trotzdem. Ne Möglichkeit wär beispielsweise die Bilder nur im Fehlerfall zu sichern. Oder eben nur die letzten X Messungen, damit man was zum Nachschauen hat wenn das System abschmiert.Ich verlier immer den Überblick was der Kollege da alles speichern will. Muss ich nochmal auflisten. Die Bilder wären aber der übelste Brocken. Der Rest besteht aus 33-66 Fließkommas. Ein kurzer String, ein Datum. Hier und da noch die eine oder andere Einstellung. Da dürfe mein Post mehr Platz in der DB fressen. Und dann halt unabhängig von der Messung noch die Settings der Anwendung, ein wenig Kommunikation, 1-2 größere Datensätze die nur ab und zu neu beschrieben werden.
Die Daten die rein sollen werden sowieso bei Beginn in einer Designphase erst festgelegt. Dann machen wir auch das Datenbank-Design an sich. Und da haben wir jemanden der viel Ahnung von DAtenbanken hatund uns dann unter die Arme greift.
Eine Datenbank wird definitiv zum Einsatz kommen. Da gibts kein hin oder her.Die Menge an DAten kann man gar nicht anders verwalten, speichern und auswerten. Die Kommunikation zwischen den Anwendungen geht auch so am Besten.In erster Linie geht es JETZT darum mit Datenbanken zu arbeiten und zu lernen. Bzw. ist mein Kollege gerade dabei eine Stückliste von Excel mit Access in eine Datenbank zu packen. Und wieso soll ich jetzt mit einer Datenbank lernen und später wenns an die Software dann doch eine Andere nehmen? Jetzt bin ich noch an keine gebunden. Also suche ich mir doch gleich die Richtige aus.
Bisher stehen die Zeichen auch auf Postgres. Wobei mich die Doku der C++-Lib dafür schon wieder annervt...
-
OIch kann Dir nur empfehlen eine eigene Schnittstelle zu machen und dann auf diese den Datenbankcode aufzubauen.
Dadurch bist Du nicht von einer DB anhängig falls etwas mit der verwnedeten DB nicht funktioniert.Ich habtte das Problem auch mal.
Habe früher MySQl verwendet.
Aufgrund der Anzahl Datennsätze wurde die DB aber zu langsam und ich bin auf MSSQL 2005 umgestiegen.
Da ich aber einen eigenen WRAPPER pro RDBMS geschrieben habe war es bei mir einfach nur ein austausch der DLL.
-
Hab ich auch schon überlegt.
Müsste da dann nicht Cosi als SQL-Lib gehen? ODBC hab ich irgendwo beim überfliegen gelesen wär langsamer.
-
Himmelherrgott... Wie komm ich immer auf Cosi... SOCI meine ich. Mensch... Sorry.
-
Aus Erfahrung (habe Mysql und Postgresql probiert) würde ich als
kostenlose Datenbank auch Postgresql empfehlen. Das ist auch was
für den Anwendungsentwickler, da Postgresql auch eine
High-Level-Programmierschnittstelle ala Oracle und DB/2 mit
exec sql... und Hostvariablen hat. Das macht die Entwicklung
(für mich persönlich - da vom IBM-Host kommend) wesentlich
einfacher und übersichtlicher als das Gefummel mit
Funktionsaufrufen und dem Parameterzusammensuchen.
Desweiteren würde ich die Bilder im Dateisystem ablegen und
wie schon Vorposter gesagt haben, nicht in der Datenbank - da nur
den Verweis. Postgresql bietet auch die Möglichkeit, wie die großen - grins
Tablespaces zu definieren. Da kann man dann auch z. B den Index und
die Daten einer großen Tabelle auf verschiedene Platten legen - bringt auch
einiges an Performance.
So einfach ist ein Insert mit Postgresql in C. Verzeit das Goto - ich
komme aus der Cobol-Assembler-Welt der S/370 - ja ich hab noch Lochkarten
gestanzt - grins.exec sql begin work;
exec sql insert into pferdlock values (:programm, :userid);
if (sqlca.sqlcode < 0) goto schluss1;
exec sql commit work;
-
Ich spiel seit etwa einem Jahr - eigentlich nur so zum Spass und Lernen - mit Firebird rum und bin ziemlich angetan davon. Ich teste das ganze aus einer MFC Anwendung heraus. Für die Kommunikation zur Datenbank verwende ich ADO in einer Selbstbau Kapselung - Quasi per msadoxx.dll Direktimport. Der Rest läuft dann per Microsoft OLEDB via ODBC Treiber, der auf dem standard Firebird ODBC Treiber aufsetzt (Mit den Firebird OLEDB Providern hab ich leider keine guten Erfahrungen gemacht). Mit dieser Schnittstelle funktioniert das wunderbar und wenn ich mich halbwegs an die SQL Standards halte (da ist Firebird erfreulicherweise sehr konform) kann ich auch relativ problemlos ein anderes DBMS, z.B. Oracle ranklemmen. Das einzige was mich an Firebird stört ist der Umfang erhältlicher Tools. Da ist wirklich kaum was brauchbares (kostenloses) zu finden um die Datenbank aufzusetzen. Man macht viel "per Hand", also SQL Konsole oder schreibt sich seine eigenen Tools. Ich werd mir in Zukunft mal Postgre ansehen, bin da auch ein wenig neugierig geworden.
-
Ich finde bei PostgreSQL insbesondere das Admin-Tool sehr gut gelungen (Tabellen, Indizes, Trigger, Prozeduren, ... erstellen geht damit wirklich einfach und schnell).
-
Hi Shogun,
ich hatte fast die gleiche Aufgabenstellung: Archivierung von TIFFs, PDF und
Textdaten, Aufkommen bis 100 Mio / Jahr, Umfang ca. 120-140 GB / Jahr (also ein
kleines bißchen weniger :)).Das ganze mit maximaler Verfügbarkeit und täglichem Dateimport.
Die Laufzeiten mit Standarddatenbanken (in diesem Fall Btrieve) waren immens,
also ein eigenes System. Da, wie bei Dir, keine Daten mehr geändert werden müssen,
kannst Du den ganzen Oberhead für Record-Locking etc. rauswerfen und voll auf
die Laufzeit und die sichere Speicherung gehen (man muß den Kram auch mal sichern,
vergiß das nicht. Bei großen Dateien machen alle OS schlapp).Die 4GB-Grenze ist auch tückisch, auch bei 2 GB aufpassen. Oberhalb von 4 GB wird
Windows etwas krückelig.Ich habe alles tageweise ebgelegt und dann über alles einen großen Index zum
Suchen gelegt. Es sind reine sortierte ASCII-Tabellen, mit einer Paar Vergleichen
habe ich den passenden Record. Die Suchzeiten sind trotz der Datenmenge recht
flott und liegen meist im Bereich 0.1-0.3 sec.
-
unterstützt jedes windows xp 4 cores? ich kenne mich da wenig aus. grundsätzlich sollte man sich aber wohl eher den einsatz eines unix überlegen, wenn man postgresql oder ähnliche einsetzen möchte. ein argument wäre, dass für eine spätere erweiterung keine lizenzkosten für das os benötigt werden.
postgresql unterstützt so etwas wie events. die sql kommandos listen und notify sind dafür zu verwenden. ich habe das selbst nie ausprobiert. ich weiß nur, dass es sie gibt.
postgresql verwendet mvcc. das könnte probleme mit den großen dateien probleme machen, hat aber vorteile bei gleichzeitigen zugriffen, die du ja anscheinend oft hast. mysql kann mvcc mit innodb und der neuen falcon engine auch.
postgresql unterstützt auch trigger und stored procedures. man liest, dass postgresql auf mehreren cores besser skaliert als mysql. es unterstützt mehr sql features als mysql, wobei hier mysql schneller aufholt als postgresql erweitert wird.
postgresql steht unter der bsd lizenz und ist ein reines community projekt. mysql hat eine firma hinter sich. seit jahren tauchen immer wieder gerüchte bezüglich des endes der open source variante auf. man sollte das bedenken.
-
noch ein argument für unix: die dateigröße ist mehr oder weniger nur von der festplattengröße beschränkt.
