Datenbank für schnelle Bilder, Vorschläge bitte.

[KodeZwerg]

Zitat von Daniel:

er fragte halt nach einer DB - und so völlig abstrus ist der Gedanke ja auch nicht, für eine Datensammlung eine Datenbank nutzen zu wollen.

Ja Danke dafür, also DB ist schon das Ziel, alle Fileserver oder kryptische Dateinamen o.ä. Möglichkeiten kenne ich, vielen Dank für alle Dateisystem basierten Vorschläge aber die scheiden partout aus. Vorgabe ist eine DB oder etwas was die Funktionen die ich brauche schnell bereitstellen kann. Es gibt ja auch virtuelle Dateisysteme, darüber habe ich auch schon nachgedacht, was da halt performanter wäre im Vergleich zu einer DB. Das wäre für mich die einzige alternative, so das lokal nur ein paar Zusatzdateien entstehen aber die Bilder in einer großen zusammengefasst werden (bei virtuellem Dateisystem wahrscheinlich dann egal).

[rokli]

Hallo,

vielleicht teilst Du Deine Daten in 2 Bereiche:

1. Verwaltung in einer DB/Tabelle -> Name des Bildes, ID des Bildes, weitere Informationen insbesondere zum Suchen und in der
2. DB/Tabelle -> die Bilddaten mit ihrer ID.

Der Vorteil ist, dass Deine Verwaltung schlank bleibt und beim Suchen von Bildern mit wenigen Daten ausgekommen wird.

Gruß

[mkinzler]

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

[KodeZwerg]

Zitat von mkinzler:

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

Das beantwortet schon mal eine meiner Fragen wo ich noch am lesen/lernen der Doku bin, was mein Grundkonzept, weil ich es nicht besser wusste, bereits allen Wind aus den Segeln nimmt
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken.
Ich breche an dieser Stelle mal ab bevor hier noch ein Streit wegen meiner Unwissenheit entsteht.
Erstmal werde ich nun als Hausaufgabe lesen/lernen/Konzept planen auf haben und melde mich bei Fragen zurück.
Vielen Dank für all Eure Verschiedenen Ansätze mir helfen zu wollen und es tut mir leid wenn ich mich falsch Ausdrücke!

[MichaelT]

Du wirst vermutlich ein wenig auf die Größe von Änderungslogs der DB gegebenenfalls aufpassen müssen.

Je nachdem möglw. hilft eine zeitliche Partitionierung. Zumindest ein Poor Mans's Partitioning könnte gegebenfall helfen. Eine View macht ein UNION über Tabelle mit Einträgen über bspw. einen Zeitraum. Aber das vermutlich nicht wirklich gehen, sonst bräuchtest du vermutlich nicht die Voranzeige.

Pfade in der DB sind nicht unbedingt immer gut, sobald Benutzer die Möglichkeit haben umzustrukturieren. Eine Filesystem ist ein hierarchische DB (ala LDAP).

Habe ich das richtig verstanden. Du speicherst so eine Art 'Thumbnails'/Vorschaubild von größeren Dateien ein der DB zur Ansicht und willst nicht die Datei holen.

Du hast keine Chance das Processing des Bilds von 5 Sekunden zu beschleunigen?

Zitat von KodeZwerg:

Zitat von mkinzler:

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

Das beantwortet schon mal eine meiner Fragen wo ich noch am lesen/lernen der Doku bin, was mein Grundkonzept, weil ich es nicht besser wusste, bereits allen Wind aus den Segeln nimmt
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken.
Ich breche an dieser Stelle mal ab bevor hier noch ein Streit wegen meiner Unwissenheit entsteht.
Erstmal werde ich nun als Hausaufgabe lesen/lernen/Konzept planen auf haben und melde mich bei Fragen zurück.
Vielen Dank für all Eure Verschiedenen Ansätze mir helfen zu wollen und es tut mir leid wenn ich mich falsch Ausdrücke!

[KodeZwerg]

Hallo, in der DB soll kein Pfad, nur der Name der Datei als Referenz + dessen CRC + ein/zwei Bilder.
.....ich könnte auch auf Name verzichten und nur noch CRC als Referenz nutzen, aber da würde ich nicht Wissen wie ich einen Eintrag wieder los werde (wenn Original Datei fehlt).....
Ziel: Es soll auf gar keinen Fall "extern" angefangen werden Bild-Dateien wild zu schreiben, ob mit System oder nicht -> das ist ein No-Go.
Konzept: In Planung.
Der Programm Ablauf ausführlicher Erklärt:
Haupt .exe hat verschiedene Funktionen, unter anderem eine Bild-Analyse.
Die Bild-Analyse ist realisiert durch eine Dll an der wir arbeiten.
Die Übergabe an Dll erfolgt als Handle + Namen + Boolean, es wird ein Bild als Result wiedergegeben oder dessen Fehler-Code.
Das Handle ist ein Stream, der Name wird aufs Bild projeziert und der Boolean steuert welchen Bild-Typ generiert werden soll.
Die Berechnung selbst erfolgt bereits multi-threaded und ist auf gleicher Höhe wie bei Konkurenzprodukten.

Das was ich gerne hätte wäre Vergleichbar vom Prinzip mit so etwas:
Ein Ordner mit sehr viel Bild-Dateien für die Du einen Betrachter programmierst der eine Thumbnail Datenbank intern verwendet/verwaltet um eine schnelle Vorschau präsentieren zu können. Ich brauche als Result halt immer nur eines dieser Thumbnails und nicht alle wie beim Betrachter Beispiel.

edit
Zu dem No-Go:
Es gab bereits eine alpha-phase in der wir pro Datei ein Bild generierten was intern über Meta-Daten gesteuert wurde, funktionierte auch tadellos aber der Vorschlag wurde abgelehnt.

[Delphi.Narium]

Wie groß sind die Thumbnails so ca. in Kilobyte?

Habe mehrere Firebirddatenbanken mit Texten in Blobs. Die einzelnen Texte sind schonmal so um die zwei, drei Megabyte groß. Das funktioniert problemlos und ist performant (allerdings komme ich da nicht an die 450.000 Sätze).

Meiner Meinung nach spricht nichts gegen eine Struktur in der Art:

SQL-Code:

create table Daten
(
  alles was Du so brauchst,
  MD5 VarChar(32) -- oder anderer CRC
)

create table Thumbnails
(
  MD5 VarChar(32) not null primary key, -- oder anderer CRC
  Thumbnail blob sub_type binary
)

Die Tabelle Thumbnails kann dann durchaus auch in einer anderen Datenbank liegen, man braucht dann halt zwei Datenbankverbindungen. Wenn man alle "Geschäftsdaten" z. B. in 'ner Oracle-DB hat, kann man so auch die Bilder in 'ne Firebird-DB packen. Wenn der Zugriff nur aus einem eigenen Programm erfolgt, dürfte das mit wenig Aufwand umzusetzen sein.
Gibt es irgendwelche fachlichen Kriterien, nach denen man die Daten aufteilen kann? Dann könnte man auch je Kriterium die Bilder in eine eigene DB legen. Je weiter man aufteilt, um so mehr Aufwand hat man dann aber auch bei der Programmierung und dem Konsistenthalten der Daten.

Wenn ich das bisher richtig verstanden habe, wird ein Bild einmal erstellt und bleibt dann "für immer" so. Es gibt also keine Änderungen in der Bildtabelle, sondern nur einen kontinuierlichen Zuwachs? Und wie groß ist der (sowohl in ca. Bildgröße pro Bild als auch in Datensätzen pro Zeitraum)?

Hier könnte man dann auch zeitraumabhängig "neue" Datenbanken anlegen, z. B. eine pro Monat, eine pro Jahr oder Tag oder Woche oder wie auch immer. In die Datentabelle schreibt man dann neben dem CRC-Schlüssel rein, in welcher DB das Bild liegt.

Wenn mir im Laufe der Zeit meine Datenbanken zu langsam werden, dann werden sie reorganisiert, das geht mit dieser Batchdatei:

Code:

@if "%1"=="" goto fehler1
@if not exist .\%1 goto fehler2
@if exist .\%1.Save del .\%1.Save
@if exist .\%1.backup del .\%1.backup
c:\Datenbanksoftware\Firebird_3_0\gbak.exe -b -t -user sysdba -password masterkey .\%1 .\%1.backup
ren %1 %1.Save
c:\Datenbanksoftware\Firebird_3_0\gbak.exe -r -v -user sysdba -password masterkey .\%1.backup .\%1
@goto ende
:fehler1
@echo Aufruf:
@echo %0 Datenbankname
@echo.
@echo Beispiel:
@echo %0 Rezepte.fdb
@goto ende
:fehler2
@echo Die Datei %1 konnte nicht gefunden werden.
@goto ende
:ende

Man hat dann anschließend noch die "alte" Datenbankdaei, ein Backup und die "neue" Datenbankdatei. Wie oft man das macht (wenn überhaupt erforderlich) kann man ausprobieren.

[TigerLilly]

Mir fällt da MediaMonkey (der MP3 Player/Verwalter). Da hast du die Verwaltungsdaten in der Datenbank, die Datei aber im Filesystem.

Das würde ich hier ebenso machen. Zigtausend Bilder IN der Datenbank zu haben bläht die Datenbank unglaublich auf. Deine DB bekommt da ja eine beachtliche Größe! Eigentlich geht es dir ja nur darum, den Zugriff auf das Bild zu beschleunigen. da ist die DB schon gut, aber bitte nicht die Bilder selbst auch drin speichern. Nur den Pfad, das genügt.

[jobo]

Hybridlösungen hatte ich ja bereits vorgeschlagen. Aber hier läuft man jenach Umsetzung Gefahr Inkonsistenzen zu bekommen. Besonders wenn die Dateien lokal auf dem System liegen. Ist wahrscheinlich hier unporblematisch, weil kein echter Verlust, wird halt neu generiert, wenn ein Bild (versehentlich) verschoben/gelöscht wurde.