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

[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

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