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

[himitsu]

Bei vielen/großen Daten in der DB wäre vielleicht eine Partitionierung der Tabellen keine schlechte Idee?
Oder die Daten auf mehrere Tabellen verteilen, aber das wäre ja zu umständlich.

Oder wie wäre es mit einem dateibasiterten NoSQL?
Dateien und Thumbnail sowie Dateiinfos jeweils als XML daneben auf der Festplatte.

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

[Neutral General]

Glaubt ihr nicht dass ihr es grad alle etwas übertreibt?
Ich wette eine 08/15 Tabelle mit nem Blob und vllt. noch einem Index auf dem Namen o.ä. und die Sache ist gegessen
Und soweit ich das überflogen habe wurde bisher ja noch rein gar nichts ausprobiert.

Ich würde vorschlagen dass der KodeZwerg sich eine 08/15 Tabelle anlegt mit den (Blob)Feldern die er braucht und Indices auf den Feldern mit denen er sucht und es einfach mal ausprobiert.
Höchstwahrscheinlich wäre das Thema dann erledigt.
Für den Fall dass der einfache offensichtliche Ansatz keine zufriedenstellende Lösung bringt kann man ja immer noch tief in die Trickkiste greifen und sich in den technischen/internen Details eines DBMS verlieren.

Oder kurz gesagt: Probieren geht über studieren.

[rokli]

und was Dein CRC angeht kannst Du das vielleicht mit einem TIMESTAMP machen der in Deiner Ziel-DB vordefiniert ist.

Ansonsten geb ich dem NeutralGeneral mal Recht!

[jobo]

Zitat von Neutral General:

Glaubt ihr nicht dass ihr es grad alle etwas übertreibt?
..
Oder kurz gesagt: Probieren geht über studieren.

Ja, das Gefühl könnte man bekommen.
Aber ich glaube, einige (oder viele) Überlegungen und Meinungen anzustellen und einzuholen hat jetzt auch noch nicht geschadet (außer man hört damit nicht mehr auf).
Und da der TE ja genau sagt, wo/wenn es ihm reicht, ist doch alles im Lack.

[Neutral General]

Zitat von jobo:

Aber ich glaube, einige (oder viele) Überlegungen und Meinungen anzustellen und einzuholen hat jetzt auch noch nicht geschadet (außer man hört damit nicht mehr auf).

Einen Haufen (verschiedener) Ansätze und Meinungen bevor man überhaupt den kleinen Zeh Wasser hat kann aber auch überfordern und verwirren.
Und nach 4 Seiten Diskussion (wo eigentlich unter den ersten 3 Antworten schon min. eine gute Antwort war) fühlt es sich langsam danach an als würde es nicht mehr aufhören