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

**jobo**

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

**jobo**

Zitat von Neutral General:

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

Ja sagst Du als alter Hase!

Aber woher soll der Fragesteller wissen, dass unter den ersten 3 schon eine gute Antwort war. Ok, jetzt weiß er es, zumindest kennt er Deine Einschätzung nun. Das wäre ein cooles Feature, wenn irgendwo so KI mäßig ein Pfeil erscheint => gute Antwort!

**KodeZwerg**

Da ich mich mit dieser Materie bis lang noch nie Auseinander setzen musste erhoffte ich mir einen Rat von Leuten die täglich bzw mehr damit zu tun haben.
Ich bin ja bereits am Lesen der verschiedensten Dokumentationen und stelle keine Fragen mehr.
Eine DB anlegen mit 450k Datensätzen, nur mal so zum probieren um am Ende herauszufinden das es doof ist wollte ich verhindern aber okay, dann eben so.
Danke auf jeden Fall für all Eure Meinungen!

**Neutral General**

Zitat von KodeZwerg:

Eine DB anlegen mit 450k Datensätzen, nur mal so zum probieren um am Ende herauszufinden das es doof ist wollte ich verhindern aber okay, dann eben so.

Ich schreibe weder den anderen Leuten vor nichts mehr zu sagen noch musst du dich an meinen Rat halten

Und das Einfügen der Datensätze wird ja hoffe ich mal nicht von Hand geschehen sondern automatisiert. Dementsprechend sollte das auch nicht ewig dauern.
Falls doch dann teste halt erst mal nur mit 100k.
Ich denke ab nem gewissen Punkt helfen Ratschläge und das Lesen von Anleitungen/Dokumentationen/Tutorials nur noch bedingt und das einfachste und effektivste ist einfach mal loszulegen und zu probieren.
Wenn man dann ein (besseres) Gefühl für das Problem entwickelt hat kann man ja durchaus wieder Informationen und Ratschläge suchen die mit der neuen Erfahrung wahrscheinlich ein ganzes Stück hilfreicher sind als zuvor

**Delphi.Narium**

Also auch nochmal meinen Senf dazu:

Die eigentlichen Daten werden getrennt von den Blobs abgelegt.

Je Bild wird die MD5-Checksumme errechnet, das geht bei den kleinen Bildern schnell, entsprechendes liefert Delphi.

Die Bilder kommen in Blobs einer Tabelle, die neben dem Blob nur noch die MD5-Checksumme hat. Da kommt ein eindeutiger Index drauf. Doppelte MD5-Checksummen weisen auf identische Blobs hin, die brauchen wir nicht.

Der Datensatz, zu dem ein Blob gehört, enthält ebenfalls die MD5-Checksumme.

Wird nun für einen Datensatz das Bild angefordert, so nimmt man aus dem Datensatz die MD5-Checksumme und sucht in der "Blob-Tabelle" und hat sein passendes Bild.

Die Beschreibung dessen, was gemacht werden muss, ist vermutlich deutlich länger, als der zur Umsetzung erforderliche Quelltext.

Gehören mehrere Bilder zu einem Datensatz, dann muss man sich noch eine "Zwischentabelle" machen, die einerseits den Schlüssel der Daten enthält und daneben die MD5-Checksumme des Bildes. Damit kann man dann das 1:n-Verhältnis zwischen Daten und Blobs aufzulösen.

450.000 * 15 kb = 6.750.000 kb = ca. 6.750 MB oder knapp 7 Gigabyte + unbekannter Verwaltungsoverhead der Datenbank. Das ist in heutiger Zeit keine so exorbitante Datenbankgröße.

Und ja: Der Vorschlag zu testen ist sinnvoll. Und wenn nur mal die weiter oben vorgeschlagenen minimale Tabellenstruktur erstellt wird und dann ein Bild 100 oder 200k mal in die Datenbank gepumpt wird, mit 'nem erstmal nur Autoinc (oder ähnlichem) als eindeutigem Schlüssel. Und dann mal ein paar hundert Selects drauf loslassen und schauen, wie lange die Antwortzeit so ist. Und dann mal schauen, wie schnell oder langsam das Einfügen weiterer Kopien des Blobs wird.

(Da die Blobs im Produktivbetrieb aber nur einmal erstellt werden, dürfte eine Zeitverzögerung beim Speichern aber immernoch im akzeptablen Bereich bleiben.)

Und wenn dieser Minimalaufbau zu Ergebnissen führt, die inakzeptabel sind, dann weiterforschen.

Meine tausende Texte in Blobs dauern, wenn etwas größer, schon ein bisserl beim Speichern, das Lesen ist (fast vernachlässigbar) schnell und alles liegt in einer Datenbankdatei, keine Trennung von Daten und Blobs in irgendeinen anderen Bereich (oder sowas), alles in der einen Datenbankdatei.

Da die Bilder nur einmal in die DB geschrieben werden sollen, und dann nur noch gelesen werden, würd' ich mit Firebird ein insgesamt schnelles System, mit relativ wenig Programmmieraufwand, erwarten.

**MichaelT**

Ich habe das mal getestet und du brauchst dir keine Sorgen zu machen.

FB 2.5.4 32-bit (Affinity Mask 14) oder einfach Classic Server verwenden
Schätze aber 2 CPUs genügen oder sogar eine.
Delphi 10.2 - FireDAC

Nur mit Command einfach alternierend ein Bild zu 21k und eines zu 4k einfach mit LoadFrom File reingeladen in die zuvorganannte Tabellenstruktur.

Commit nach 10k Sätzen und Transaktion neu gestartet.

Größe ca. 7,5GB. Sind so 250k Sätze im Moment.

Pro 1000 Sätze ca. 3 Sekunden leicht zunehmend ab 100k.

DB über TCP (auf lokalen Rechner) 4 Sek.
DB über Locales Protocol 3 bis 3,5 Sekunden im Schnitt.

und die DB ist nicht von den Einstellungen her optimiert.

Zuerst degradete die Performance vermutlich da Windows die Festplatte mitformatierte.

Jetzt habe ich noch ein paar dazugeladen und die DB hat 9GB. Macht keinen Unterschied. Blobs in eigenem Table mit PK Spalte MD5.

Zitat von KodeZwerg:

Da ich mich mit dieser Materie bis lang noch nie Auseinander setzen musste erhoffte ich mir einen Rat von Leuten die täglich bzw mehr damit zu tun haben.
Ich bin ja bereits am Lesen der verschiedensten Dokumentationen und stelle keine Fragen mehr.
Eine DB anlegen mit 450k Datensätzen, nur mal so zum probieren um am Ende herauszufinden das es doof ist wollte ich verhindern aber okay, dann eben so.
Danke auf jeden Fall für all Eure Meinungen!