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

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

[KodeZwerg]

Hier meine Theorie an der ich nun arbeite sie in die Praxis umzusetzen damit ich testen kann ohne hier fragen dazu zu stellen, dafür gibt es die Doku und um diesen Thread zu beenden.
Ich setze hier an:
Dll bekommt Handle + "Namen" + Boolean
DB öffnen/Verbinden
in DB nach "Namen" schauen, gibt es den oder noch nicht.
Wenn noch nicht dann einen neuen Datensatz anlegen.
Wenn doch dann CRC von "Namen" (Original Datei) errechnen und mit CRC aus DB für "Namen" kontrollieren.
Ist CRC gleich dann Bild aus DB an Funktion als Result. <<<<-- darum geht es mir im Eigentlichen Sinne, das ersparen einer Neuberechnung eines Bildes
Ist CRC falsch dann ein neues Bild berechnen und das in DB ersetzen + als Result setzen. <<<<-- und hierbei habe ich bei so vielen Datensätzen Angst
Boolean mit einbeziehen da zwei verschiedene Bilder da sein könnten.
DB schließen/Verbindung Trennen
Einzige Funktion dir User erhalten soll ist ein "ReCreate" o.ä. um nur noch "lebendige" Records zu behalten.
Ende im Gelände.

[Delphi.Narium]

Wie oft wird die DLL aufgerufen?

DB-Verbinden und DB-Schließen dauert auch seine Zeit.

DLL-Aufruf sporadisch, dann ist das ok.
Eher "Dauerbetrieb", also permanente Zugriffe seitens der DLL auf die DB:

Dann beim Laden der DLL die Datenbankverbindung herstellen und erst, wenn die DLL aus dem Speicher entfernt wird, die Verbindung schließen.

[KodeZwerg]

Aufruf ist sporadisch aber den Tipp werde ich dennoch so umsetzen, das finde ich gut, Danke Delphi.Narium!

[Rollo62]

Firebird ist gut geeignet, aber Sqlite3 womöglich genauso.

Interessant wäre ein Performancevergleich von beiden für deinen speziellen Fall mit Blobs.
Beide Engines sollten den Speicher dynamisch nutzen, und gute Performance abliefern.

Rollo

[KodeZwerg]

Puh, noch mehr Hausaufgaben, Danke für SQLite3 Hinweis, mehr zu lesen, bald platze ich