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

[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.

[KodeZwerg]

Hallo,
ein Bild ist schwach JPEG komprimiert in etwa 15kb groß, stärker (aber noch brauchbar) JPEG komprimiert in etwa 10kb.
der Geschwindigkeit zuliebe war nur so etwas wie CRC16 geplant, die Daten die reinkommen und analysiert werden sind meistens 10-15MB groß, ein paar 400-600MB files sind auch da zwischen aber eher die Ausnahme.
Die analysierten (binär) Daten werden in der Regel nicht mehr verändert aber um dennoch darauf reagieren zu können die schnelle CRC Prüfung. CRC ist auch nur so ein "es entsteht gerade ein Konzept, gehört sowas rein, ja/nein" dingens.

DB Partitionieren, ist damit so etwas gemeint wie DB_X.db DB_Y.db DB_Z.db für verschiedene Anfangsbuchstaben bzw DB_XYZ.db um drei zusammenzufassen in einer?

Und nach wie vor, ein einzelnes abspeichern der Bilder, egal wie toll es sein mag, geht absolut gar nicht @himitsu
Bei NoSQL bin ich gerade am Lesen was das überhaupt ist, danke für Input

[himitsu]

Bei uns MD5, weil der Hash groß/sicher genug war und die Hash-Funktionen sowohl in der DB, als auch im Programm bereits vorhanden waren.
(Wir hashen auch die Logindaten/Passwörter schon clientseitig und übertragen sie nur "verschlüsselt")


Partitionieren:
Die DB speichert ihre Tabellen doch in großen Dateien.
Durch Partitionierung wird die Tabelle aufgeteilt, also z.B. nach Anfangsbuchstaben von Namen oder nach Datum (Jahr).
Eventuell werden dabei auch die Indize verteilt, aber Indize kann man bei vielen DBMS auch getrennt partitionieren/aufteilen, um den Speicherverbrauch und die Zugriffszeit zu verbessern.
Bei uns bleiben gelöschte Dateien erhalten. aber für die "normale" Suche verwenden wir Indize, wo die gelöschten Dateien nicht enthalten sind. (Index ist kleiner und noch schneller)

Am Ende werden einfach die vielen Datensätze der Tabelle nach frei definierbaren Regeln aufgeteilt und vom DBMS einzeln verwaltet, aber aus Sicht eines SELECT/UPDATE/... ist dennoch alles "logisch" in einer Tabelle vereint.

https://gi.de/informatiklexikon/part...nbanktabellen/

[mkinzler]

Blobs werden bei FireBird , wenn sich nicht (inklusive) der restlichen Felder in eine Page passen automatisch getrennt von den restlichen Feldern in einem eigenen Datenbankbereich gespeichert.

[jobo]

Zitat von himitsu:

..
Partitionieren:
..
Eventuell werden dabei auch die Indize verteilt, aber Indize kann man bei vielen DBMS auch getrennt partitionieren/aufteilen, um den Speicherverbrauch und die Zugriffszeit zu verbessern.
Bei uns bleiben gelöschte Dateien erhalten. aber für die "normale" Suche verwenden wir Indize, wo die gelöschten Dateien nicht enthalten sind. (Index ist kleiner und noch schneller)

Am Ende werden einfach die vielen Datensätze der Tabelle nach frei definierbaren Regeln aufgeteilt und vom DBMS einzeln verwaltet, aber aus Sicht eines SELECT/UPDATE/... ist dennoch alles "logisch" in einer Tabelle vereint.

https://gi.de/informatiklexikon/part...nbanktabellen/

Vorsicht, partielle Indexierung ist eher eine Spezialität von Postgres (da kenne ich es zumindest), nicht unbedingt von FB.

Und: Die große Datenmenge, von der hier immer die Rede ist, entsteht durch die Bilder (hauptsächlich) (also die Bilddateien/Blobs selbst) und die werden sicher hier (oder woanders) nicht indiziert, weil nicht gesucht.

Wenn FB tatsächlich die BLOBS separat auslagert (automatisch, so wie mkinzler schon mehrfach darauf hingewiesen hat), gibt es glaub ich keinen Grund, sich den Indexkopf zu zerbrechen oder über Partitionierung nachzudenken.