Die Henne oder das Ei? MySQL Bzw. Firebird, oder PostgreSQL
-
Shogun² schrieb:
MySQL? Firebird? PostgreSQL?... Trigger... schnell und einfach zu sichern sein... Leistungsfähig, sicher...
Zu Firebird kann ich dir leider nichts sagen.
Ich weiß jetzt nicht wie weit MySQL mit den aktuellen Versionen aufgeholt hat (entweder hat die aktuelle Version schon Trigger, oder es kommt demnächst). MySQL ist dann schnell wenn du ohne Transaktionen und ohne komplexere Selects arbeitest. Meiner persönlichen Erfahrung nach ist sie aber nicht unbedingt die sicherste. Der übliche Hauptbereich dieser Datenbank liegt wohl eindeutig im Webumfeld.
PostgreSQL ist dann bei den kostenlosen Datenbanken Mittel der Wahl wenn Transaktionen, Trigger, auch mal komplexere Selects etc. hinzukommen. Von der Leistungsfähigkeit und Funktionalität soll sie auch am ehesten mit der kostenpflichtigen Konkurenz mithalten können.
Ich persönlich würde in dem geschilderten Fall zu PostgreSQL greifen.
cu André
-
Was meinst Du mit "verschluckt"? Der Titel sieht doch gut aus...
Ich würde Postgres verwenden. Bei vielen konkurrierenden Zugriffen skaliert es deutlich besser als MySQL und das Sichern ist wesentlich angenehmer als bei MySQL mit InnoDB (MyISAM fällt ohnehin flach).
Lizenztechnisch ist das was Du vorhast mit Postgres auch sehr einfach, geht problemlos.
Firebird ist zwar ganz nett, aber mir fallen keine Gründe ein, warum man Firebird den Vorzug vor Postgres geben sollte, es sei denn, man war bereits zuvor auf Borland Interbase angewiesen.
-
nman schrieb:
Was meinst Du mit "verschluckt"? Der Titel sieht doch gut aus...
Ich würde Postgres verwenden. Bei vielen konkurrierenden Zugriffen skaliert es deutlich besser als MySQL und das Sichern ist wesentlich angenehmer als bei MySQL mit InnoDB (MyISAM fällt ohnehin flach).
Lizenztechnisch ist das was Du vorhast mit Postgres auch sehr einfach, geht problemlos.
Firebird ist zwar ganz nett, aber mir fallen keine Gründe ein, warum man Firebird den Vorzug vor Postgres geben sollte, es sei denn, man war bereits zuvor auf Borland Interbase angewiesen.
@nman: Ich hab im Titel MySQL noich auflisten wollen. Entweder habe ich es verschluckt oder das Board. Da ich aber wieder zu faul zum Einloggen war, kann ich nicht ändern.
Übrigends hab ich deine Ausführungen in anderen Threads vorhin gefunden und mir auch mal den Link zum Leistungstest reingezogen. Ist definitiv registriert.Auf alle Fälle schonmal Danke für die Antworten. Ich les im Web allgemein öfters was darüber, dass die Leute von MySQL zu Firebird oder Postgres wechseln. Leider sind diese Kommentare gerne von 2004 und 2005 (Komischerweise immer 2004 oder 2005 oO). Deswegen weiss ich nicht was heute eingesetzt wird und frage hier.
Zur Zeit läuft Frontbase in einer unsrer Anwendungen. Die wird allerdings von einem Subunternehmer programmiert.
Nur mal so wegen der Dimensionen die ich verarbeiten will, muss, soll. Unser Problem ist eine unheimliche Datenmenge. Ich spreche hier von Messdaten, im Extremfall, alle 3 Minuten. Da sollen auch die Quellbilder gesichert werden (Qualitätssicherung... damit wir Messergebnisse irgendwann mit geänderter Software nachvollziehen können etc.) Wir reden hier von Bildern 6144x640x31. Und nein das ist kein Tippfehler. 31 Dimensionen. Keine 3. Das sind mal eben 300-400MB PRO Bild. (Wir wollen uns noch einen verlustfreien Kompressionsalgorithmus besorgen, damit das nicht sooo große Datenmengen sind). Da kommen eben mit der Zeit, selbst ohne das Speichern der Bilder, unheimliche Datenmengen zusammen. Die Datenbank wird somit tieeef Luft holen müssen. Sie soll wahrscheinlich auf dem Messrechner gehostet werden, der sowieso bei einer laufenden Messung ganz gut ausgelastet ist. Wird wegen der Datenmengen eventuell ein Xeon Quad.
Deswegen darf die Datenbank nicht so schnell an Überlastung sterben.
Also MySQL sehe ich mittlerweile schon leicht abgeschlagen. 1. Das mit der Leistungsfähigkeit bei mehreren Zugriffen. 2. Die Posts die ich im Web finde. 3. Das §%&%&$ Teil ist mir beim Installieren 3x während der Installation gestorben.
Eventuell noch andre Datenbanken? Die Express-Editions haben ja alle 4GB pro Table. Das ist... Naja...
-
Sag mal welches BS auf den Rechner kommt.
Hier ist ja die Verfügbarkeit entscheidend oder?
Bilder werden eigetlich sowieso nicht in der DB abgelegt.
Ihr könnte aber auf dem MSSQL 2008 warten. Da kann man die Bilder in der DB ablegen ohne die Tabellen zu belasten.
Hier legt MSSQL selbst eine Ref. in der DB ab und speichert das Bild in einem eigenen Bereich. Früher wurde das in die Tabelle als BLOB aufgenommen.
Replikation ist recht easy. Sicherung geht schnell über die MS-Tools. (Managementstudio) Auch automatisch.
Unter Windows sicher die bessere Wahl als z.B. MySQL.
Wenn die DB sehr groß wird in jedenfall nicht MySQL.
-
Sorry. Das hatte ich vergessen.
Vorerst XP.
Die MS-Versionen kosten doch massig Geld? Wenn ich mir da die Preise für den 2005er Server Anschau wird mir schlecht.
Mir hat jemand gesagt bei der VC++ Express wäre eine Server-Vollversion dabei. Aber das war auch nur 2005 Express.
-
Unix-Tom schrieb:
...Ihr könnte aber auf dem MSSQL 2008 warten. Da kann man die Bilder in der DB ablegen ohne die Tabellen zu belasten...
Dann kommt man aber wieder auf die komerziellen zurück (wo man dann auch Oracel, DB2 etc. nennen könnte). Soviel ich weiß kommt man im kostenlosen Umfeld bei großen Datenmengen tatsächlich nicht um PostgreSQL herum. Wobei ich hierbei auch auf die Dokumentation verweisen würde, was die zu Grenzen der Datengröße sagt...
cu André
-
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.
