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

[KodeZwerg]

@mensch72: Das muss ich mir gleich nochmal langsam durchlesen ;-)
@noname2018: Es gibt in den Profil-Einstellungen eine Ignorier Funktionalität, verwende sie und Du bist mich los, Problem gelöst, oder?

edit

Zitat:

Zitat von mensch72 (Beitrag 1400178)

FB ist wenn es um echte komplette SQL Funktionalität geht sicher eine gute Lösung.
Mit IBexpert gibt es da hier im Forum Support, wenn man (s)einen FB Server auch "richtig" schnell bekommen will/muss.

ABER:
0,5..1M+ Records "schnell" mal "öffnen", "suchen/selektieren", "Daten auslesen/abfragen", "schließen"... da sind die echten SQL Datenbanken auch lokal oft einfach nicht optimal genutzt.

Ich habe mir bis jetzt nur Gedanken wegen Performance gemacht und dachte da an so ein Konzept:
Eine DB mit "Name"+"CRC"+"ID" Felder pro Record, eine zweite DB wo in "ID" = ein oder zwei Bilder hinterlegt werden können/Blob
500k-1m halt damit es wenigstens Zehn Jahre keine Probleme am Einsatzort geben soll, momentan 450k files aus denen halt ein bis zwei Bilder generiert werden sollen und später abgerufen werden können oder updaten oder komplett entfernen.
Das beschleunigt hoffentlich den Datenfluss oder wäre dieser Ansatz kompletter blödsinn?
Bevor ich gross weiterschreibe belese ich mich mal mehr, wird wohl das beste sein ;-)

[Schokohase]

Zitat:

Zitat von mensch72 (Beitrag 1400178)

Anbei noch ein Beispiel, wohin die Methode "DB is unnötig, FileSystem tuts auch" führen kann... da speichert z.B. ein Mitbewerber von uns einfach seine Daten in einer Datei pro Stunde... klingt zunächst nicht weiter aufregend, nur wenn dies über Jahrzehnte und zig Werte geschieht, hat man plötzlich fast 5Mio einzelne Dateien... und da zerlegt es dann so langsam einige 32Bit Windowsprogramme und auch die NTFS Funktionen von Win64 im Explorer und Zwischenablage werden mit sowas arg strapaziert... und wenn da da jeweils auch noch mehr wie 1000Datensätze anfallen braucht es auch eine DB/Logik die mit mehr wie 4Mrd(>2^32) Records umgehen kann:)

Und mit einer DB wäre das Problem nicht da?

Es liegt hier nicht am Ablageort, sondern an der generellen Umsetzung.

[KodeZwerg]

Zitat:

Zitat von Schokohase (Beitrag 1400181)

Und mit einer DB wäre das Problem nicht da? Es liegt hier nicht am Ablageort, sondern an der generellen Umsetzung.

Also das war schon einer meiner Grundgedanken, dass das Dateisystem völlig vollzgestopft wird, pro Datei dynamisch doppelte Bild-Dateien plus einer CRC-Datei, das ist viel.
Im schlimmsten Fall beim bisherigen Datenbestand wären das 450k * 3 Dateien und die Eigentlichen Dateien um die es geht verlangsamen sich immer weiter.
Ich bin der Meinung mit einer DB, welche auch immer, momentan lese ich noch Firebird Dokumentation, bin ich auf dem Richtigen Weg.

[jobo]

Mir ist nicht richtig klar, wie die Bilder "berechnet" werden sollen (oder ist es doch ein simpler Upload), auch die "Einzelplatzlösung lokal" ist mir nicht ganz klar, die Lösung existiert alles nur einmal an einem spezialisierten Arbeitsplatz?
Also mal zwei, drei Gedanken dazu:
Datenbanken spielen m.E. ihre Stärke nicht bei der Verteilung von Dateien aus. Auch sparen sie dabei (Dateispeicherung in Tabellen) nicht unbedingt Speicherplatz, denn sie arbeiten wie Dateisysteme bei BLOBS mit einer (einstellbar) groben Stückelung.
Ein Fileserver ist ein Fileserver und kann das eigentlich ganz gut. Jenseits von irgendwelchen Windowsbeschränkungen (die ich nicht alle Auswendig kenne) gibt es ja noch andere Dateisysteme im Linuxbereich, die teilweise hochspezialisiert sind. Der Zugriff in einer Windowswelt kann mit geeigneten Mitteln natürlich auch für diese Systeme erreicht werden.
Kompression ist bei Bildern mit Fingerspitzengefühl zu handhaben. JPEG bspw. ist per se ein komprimierendes Bildformat, man kann recht genau einstellen, wie toll es denn sein soll. Erneute Kompression bringt dann von außen wenig, außer Zeitverlust. PNG sind eher nett für "cleane" Bilder, also Screenshots z.B. (Stichwort "Verlustfrei")
Vorteil einer Datenbank wäre gegenüber einer Fileserverlösung vor allem, wenn die Suche mit mehreren, insbesondere stark unterschiedlichen Attributen zum Fileserver ermöglicht wird. Hier kann eine DB wirklich ihre Stärken ausspielen. Also Angaben zu Bildinhalt wie Artikel, Artikelzustand, beteiligte Personen/Abteilungen, Bildauflösung, usw., je nach Themenschwerpunkt könnte man auch einen OCR Prozess dazwischenhängen und ein Textextrakt des Bildes in die Datenbank schreiben.
Was auch immer in der Richtung gemacht wird, geht m.E. über Standardfunktion und Nutzen eines Fileservers und die erzielbare Suchgeschwindigkeit hinaus.

[OT]Ich habe auf einem Windows-Rechner einen "großen" Ordner "downloads" (99Elemente, 19GB), hier landen zufällig Downloads eines bestimmten Browsers. Wird der Ordner im Explorer geöffnet, dauert es ewig bis die Dateien angezeigt werden. Darstellungsmodus "Details", kaum Bilder, kein Preview. Es ist nur bei diesem Ordner so, die 10-15 Sekunden haben mich noch nicht so sehr genervt, der Sache auf den Grund zu gehen. Solche Effekte eines Windows Fileservers mit hilfreichen Geistern, äh Diensten, die mehr stören als nützen, sprächen natürlich auch für eine DB oder einfach gegen einen (schlechten) Fileserver[/OT]

Diese Gedanken kann man vor Eigentwicklung/Kauf mal durchspielen. Bei einer eigenen Entwicklung wäre es vielleicht noch ratsam, die Nähe bzw. den Integrationsgrad von Programm Suchfunktion und Dateiserver durchzudenken. Statt stumpf Pfade oder ganze Bilder zu speichern, ginge es auch anders (Hybridlösung): Versteht man das Rumschubsen der Dateien als Dienst, könnte man es auch direkt so implementieren, also einen Client, der beliebige (z.B. Dropbox, Samba, FTP, ..) Adressen und Anmeldedaten (intern) verwaltet und nur eine komfortable Suche, Dateiannahme, -Auslieferung übernimmt.

[KodeZwerg]

Zitat:

Zitat von jobo (Beitrag 1400203)

Mir ist nicht richtig klar, wie die Bilder "berechnet" werden sollen (oder ist es doch ein simpler Upload), auch die "Einzelplatzlösung lokal" ist mir nicht ganz klar, die Lösung existiert alles nur einmal an einem spezialisierten Arbeitsplatz?

Es ist kein Upload, wir haben binär Dateien, die, wenn Sie über das Hauptprogramm abgerufen werden, Analysiert werden, die Analyse wiederum ergibt neue Daten die als Bild dargestellt werden, ähnlich einem Diagramm. Ein zweites Bild optional für eine andere Art der Berechnung/Darstellung. Momentan wird leider jedes mal alles neu berechnet. Eine Berechnung dauert so circa 5-10 Sekunden, es ist kein Weltuntergang aber auf Dauer schon nervig. Die Bilder an sich spielen im Hauptprogramm nur eine untergeordnete Rolle, da geht es um etwas anderes, also Bilder sind nicht der primäre Task.
Um hier nun ein besseres Echtzeit-Erlebnis genießen zu können, so dachte ich jedenfalls, warum nicht die Bilder speichern wenn sie eh schon berechnet sind.
Dafür hatte ich mir ein Performance Konzept wie bereits beschrieben überlegt, eine DB mit den Dateinamen und einer CRC sowie einer ID die den Index der zweiten DB angibt wo letztendlich die Bilder/Blobs für die Dateien gespeichert sind.
Mit der Fileserver Methode wäre ich da aktuell im Worst-Case bei doppelt berechneten Bildern mit 1.35mio Dateien dabei was ich dem Dateisystem nicht antun möchte und da die Bilder nur Sinn im Zusammenhang mit einer Analysierten Datei ergeben, hielt ich eine DB für sinnvoll.
Ja es wird nur lokal von einem Ort aufgerufen, nein das Hauptprogramm geht nicht um die Welt es ist nur für einen Zweck an einem Ort gut.
Was ich verhindern wollte war ein Ergebnis wie das Bild von mensch72 zu erreichen (Hut ab übrigens, da bekomme ich Angst).
Ich hoffe ich habe mich klar genug ausgedrückt.
Danke für Deine Sichtweise zu den anderen Punkten!

[jobo]

Ok, danke für die Erläuterung. Ich wollte nicht ohne weiteres für Fileserver plädieren. Man sieht ja, auch wenn es ihr Job ist, müssen sie dabei nicht unbedingt glänzen.
Langsam ist also erstmal die Analyse/Berechnung des Bildes? Oder sogar das Laden der Binärdaten?
Dann wäre es evtl. spannend, diesen Prozess zu beschleunigen und sich das Bildcaching zu sparen. Dieser Vorschlag ist wahrscheinlich blöd, weil ihr das sicher bereits sinnvoll optimiert habt.

Je nach Ergebnis (der Berechnung), wäre vielleicht SVG eine gute Wahl (Vektordaten) als Bildformat. Das ist ja mittlerweile recht mächtig (und sehr schlank).

[Schokohase]

Was macht ihr euch mit dem Datei-System so sehr in die Hose?

Natürlich muss man dem eine gewisse Aufmerksamkeit widmen, aber vor Angst erstarren?

Ein Verzeichnis mit 1.000.000 Einträgen lässt den Explorer bei der Darstellung ganz schön schwitzen, aber was ist denn mit 256 Einträgen? Das stellt gar kein Problem dar.

Wenn man jetzt Dateien anhand einer ID (UInt32) abspeichern möchte, dann baut man sich den Pfad dazu wie folgt:

Code:

ID = 123456789
ID(hex) = $075BCD15
Pfad = .\07\5B\CD\075BCD15.dat

[mkinzler]

Ist es wichtig unabhängig von dem Programm auf die "Dateien" zuzugreifen, dann Dateisystem. Wenn nicht dann eine DB. Ein embedded DBMS muss in der Regel nicht installiert werden und stellt daher auch kein großer Mehaufwand dar.

[Daniel]

Man kann vieles machen, wenn man denn möchte. Aber er fragte halt nach einer DB - und so völlig abstrus ist der Gedanke ja auch nicht, für eine Datensammlung eine Datenbank nutzen zu wollen.

[Jumpy]

Oder halt eine Kombination von beidem, wie bei einem Dokument-Verwaltungs-System?

Die Dateien liegen (ggf. unter einem kryptischen Namen) in einem dafür ausgelegten Filesystem.
In der Datenbank ist dieser Ablageort samt Dateinamen gespeichert, zusammen mit den Attributen, durch die das Bild ggf. zugeordnet werden soll.
Die DB ermöglicht nun eine schnelle Suche, ob es das Bild (zu gewissen Werten o.ä.) schon gibt und liefert den Ort, von dem es geladen werden kann.