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

[KodeZwerg]

Hallo Community!
Ich schreibe gerade ein Programm was anhand von Daten ein Bild erstellt.
Das ein Bild nicht ständig neu berechnet werden muss wenn Daten gleich bleiben, so dachte ich mir kreiere ich eine Datenbank dafür.
Ziel soll sein eine DB zu haben die mir schnell das Image zurückgibt und mit Datensätzen von 500k bis 1mio keine großen Probleme hat.

Datenbank sollte diese Möglichkeit bieten:
1. Einen Namen zu speichern damit ich es im nachhinein Daten zuordnen kann.
2. Ein/Zwei Bild(er) zu speichern (darum geht es ja Eigentlich) und schnell laden zu können
- noch sind Bilder unkomprimiert, falls eine Kompression den Ladevorgang beschleunigen kann, mache ich es

Es wird nur lokal gearbeitet und es wird keine DB Anzeige im Hauptprogramm existieren.
Es wird nur unter Windows gearbeitet.

Programm Ablauf:
- Programm starten
- Programm lädt Daten und schaut in DB anhand des Namens ob es dafür schon ein vorberechnetes Bild gibt
- Falls Möglich, das man auch optional ein zweites Bild dem Datensatz zufügen kann, das wäre toll
- entweder Bild neu Berechnen oder DB-Bild laden
- Programm beenden (oder weitere Daten laden etc)

Hauptprogramm DB features, alle transparent, User wird darauf keinen Einfluss haben
- Datensatz erzeugen
- Datensatz laden
- Datensatz löschen
- Datensatz updaten
- Datensatz speichern
- Datensatz schnell nach Namen durchsuchen
- eventuell eine doch User-Steuerbare Möglichkeit die DB neu zu schreiben um verwaiste Datensätze zu entfernen bzw alphabetisch sortieren zu lassen, falls das ein Suchen beschleunigen würde

Was schlagt ihr vor für welches Framework ich mich entscheiden sollte?
Momentan ist nur Delphi Tokyo 10.2.3 voll installiert, keine weiteren DB Komponenten.

Für Ratschläge wäre ich dankbar, Fragen beantworte ich auch gerne falls das oben zu lütt bzw falsch an Information ist.

[Schokohase]

Bis jetzt sehe ich hier nichts wo eine Datenbank benötigt wird.

Die Direktablage auf der Festplatte tut es da auch.

Für die Ablage im Dateisystem schaut man sich an, wie so ein

Delphi-Quellcode:

TDictionary

seine Daten intern verwaltet (über Buckets).

[mkinzler]

Datenbank hat den Vorteil, dass alles nur eine oder 2 Dateien abgelegt wird. Bei der genannten Anzahl solte aber jedes DBMS geeignet sein. Gut eines mit BLOB-Unterstützung.

[Delphi.Narium]

Embeddedversion von Firebird, dann brauchst Du nichtmal 'nen Datenbankserver aufsetzen, da der quasi Teil Deines Programmes wird.

Aber: Solltest Du irgendwann mal sagen: Oh, da Programm wird jetzt ein Mehrbenutzersystem, dann tauschst Du die Embeddedversion gegen 'nen Firebirdserver aus, die Datenbankdatei kannst Du weiterhin nutzen, eine Konvertierung, irgendwie geartete Datenübernahme ... ist nicht notwendig.

Und schnell ist die eigentlich auch.

Und Bilder ablegen kann sie auch: https://firebirdsql.org/refdocs/langrefupd21-blob.html

[KodeZwerg]

Danke für Eure Aussagen, embedded mit Blob hört sich an nach dem was ich brauche, hoffe ich ;-)
Dem werde ich Nachgehen und zur Post #2, wir haben einen Ordner mit schlapp 450000 Dateien, Ziel soll eine Datei sein die alles schnell bereithält, ich könnte auch Zippen aber das geht mir zu sehr auf die Performance bei Veränderungen.
Im Nachhinein ist mir eingefallen das ich noch eine Definition pro record brauche, einen Hash oder CRC Wert der original Daten damit ich auch auf Veränderungen reagieren kann :-D
Vielen Dank für Feedback!

Ps: Daran soll später nie was verändert werden, Bild(er) plus Name plus CRC in die DB und per Hauptprogramm gesteuert ohne da direkt DB spezifische Knöpfe/funktionen bereitzustellen, alles im Hintergrund.

[mkinzler]

Firebird ist definitiv gut geeignet.

[KodeZwerg]

Ich bin bereits hier aber finde keine embedded Version, muss ich zu einer älteren als Firebird 3.03?

Hat sich erledigt, gerade gefunden/gelesen ist im Paket/gibt nur ein Paket, sorry!

[mkinzler]

Ja, ab v3 gibt es keine speziellen embedded (server) Client mehr.

[KodeZwerg]

Um Deine Kritik zu beantworten:
1.
Ich war auf der Hersteller-Seite und mir wurde eine embeddedVersion empfohlen, auf der Hersteller-Seite ist es nicht gleich offensichtlich da es für mich neu ist frage ich lieber nach bevor ich es falsch mache und von vorne anfangen muss.
Was ist daran Fatal nachzufragen? Wozu googeln wenn man bereits an der Quelle ist, da sollte es ja vermerkt sein, war es ja auch, nur ein wenig versteckt.
2.
Nachdem ich's fand editierte ich meine Eigene Aussage damit darauf keiner reagieren brauch.
3.
Verallgemeinert, wenn Du mir helfen magst dann bitte hilf ansonsten lass es doch einfach bleiben, das führt zu nichts.

*Winke-Winke LaLa*

[mensch72]

neben dem Henne/Ei Problem ala "Fragen/Suchen/Finden/Wissen" von mir noch folgendes;)


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.


So Vergleiche mache ich abundzu für unser sagen wir "Finanzdatenbackend" mit zugegeben etwas größeren Datensatzmengen (5Mio..5+Mrd) aber im Endeffekt gleicher Aufgabenstellung(existiert schon für DatenpunktXY eine passende errechnete&hinterlegte "Übersichtsmatrix", wenn ja schnell anzeigen, wenn nein eventuell errechnen&zugeordnet sichern).
Echte simple FileIndex-Systeme sind einfach schneller wie alle mir bekannten universellen SQL basierten Sachen FBembedded, SQlite, MSaccess, MSsql(Express,Workgroup,Ent,DatacenterArray).


Daher setzen wir für echte Highspeed Anwendungen weiter auf ein eigenes verteiltes MultipleRead/SingleWrite-StorrageArray.
Ansonsten für solche einfache "Local" 1..8 User Systeme sparen wir uns den eigenen Aufwand, und nutzen ein Zukauftool. (Letztendlich eine "SingleFileEngine", welche Single/Multiuser, Compress/Crypto und SimpleIndex/SQLselect sauber und wirklich schnell selbst löst)
Gute SQL Server haben in schlechten Netzwerken erst ab sagen wir 6 parallelen HiSpeed-Zugriffen Vorteile, in guten Netzwerken merken wir erst ab 10 parallelen HiSpeed-Zugriffen Vorteile bei sehr guten Last verteilen SQL Servern.

http://www.componentace.com/bde_repl...e_database.htm
Da der Test und die private Anwendung kostenlos ist, hindert dich nix das mal mit der sicher guten Kombi aus z.B. IBexpert und FB zu vergleichen.
Solltest du zusätzlich noch Zeit haben, probiere mal UniDac speziell mit einem MSsql-WorkgroupServer... die erreichen per native API unglaublich gute "Connect,Open,Query,Fetch,Close,Disconnect" Zeiten. (ob dir UNIdac mit MultiDB Flexibilität aber ohne MultiPlattform(willst ja nur Windows) das Geld wert ist, das musst selbst wissen)


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:)

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

[mkinzler]

Wenn Datenbank, würde ich alles in diese speichern.

[KodeZwerg]

Zitat:

Zitat von Daniel (Beitrag 1400223)

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.

Ja Danke dafür, also DB ist schon das Ziel, alle Fileserver oder kryptische Dateinamen o.ä. Möglichkeiten kenne ich, vielen Dank für alle Dateisystem basierten Vorschläge aber die scheiden partout aus. Vorgabe ist eine DB oder etwas was die Funktionen die ich brauche schnell bereitstellen kann. Es gibt ja auch virtuelle Dateisysteme, darüber habe ich auch schon nachgedacht, was da halt performanter wäre im Vergleich zu einer DB. Das wäre für mich die einzige alternative, so das lokal nur ein paar Zusatzdateien entstehen aber die Bilder in einer großen zusammengefasst werden (bei virtuellem Dateisystem wahrscheinlich dann egal).

[rokli]

Hallo,

vielleicht teilst Du Deine Daten in 2 Bereiche:

1. Verwaltung in einer DB/Tabelle -> Name des Bildes, ID des Bildes, weitere Informationen insbesondere zum Suchen und in der
2. DB/Tabelle -> die Bilddaten mit ihrer ID.

Der Vorteil ist, dass Deine Verwaltung schlank bleibt und beim Suchen von Bildern mit wenigen Daten ausgekommen wird.

Gruß

[mkinzler]

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

[TigerLilly]

Mir fällt da MediaMonkey (der MP3 Player/Verwalter). Da hast du die Verwaltungsdaten in der Datenbank, die Datei aber im Filesystem.

Das würde ich hier ebenso machen. Zigtausend Bilder IN der Datenbank zu haben bläht die Datenbank unglaublich auf. Deine DB bekommt da ja eine beachtliche Größe! Eigentlich geht es dir ja nur darum, den Zugriff auf das Bild zu beschleunigen. da ist die DB schon gut, aber bitte nicht die Bilder selbst auch drin speichern. Nur den Pfad, das genügt.

[jobo]

Hybridlösungen hatte ich ja bereits vorgeschlagen. Aber hier läuft man jenach Umsetzung Gefahr Inkonsistenzen zu bekommen. Besonders wenn die Dateien lokal auf dem System liegen. Ist wahrscheinlich hier unporblematisch, weil kein echter Verlust, wird halt neu generiert, wenn ein Bild (versehentlich) verschoben/gelöscht wurde.

[KodeZwerg]

Zitat:

Zitat von mkinzler (Beitrag 1400239)

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

Das beantwortet schon mal eine meiner Fragen wo ich noch am lesen/lernen der Doku bin, was mein Grundkonzept, weil ich es nicht besser wusste, bereits allen Wind aus den Segeln nimmt :thumb:
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken. :warn:
Ich breche an dieser Stelle mal ab bevor hier noch ein Streit wegen meiner Unwissenheit entsteht.
Erstmal werde ich nun als Hausaufgabe lesen/lernen/Konzept planen auf haben und melde mich bei Fragen zurück.
Vielen Dank für all Eure Verschiedenen Ansätze mir helfen zu wollen und es tut mir leid wenn ich mich falsch Ausdrücke!

[MichaelT]

Du wirst vermutlich ein wenig auf die Größe von Änderungslogs der DB gegebenenfalls aufpassen müssen.

Je nachdem möglw. hilft eine zeitliche Partitionierung. Zumindest ein Poor Mans's Partitioning könnte gegebenfall helfen. Eine View macht ein UNION über Tabelle mit Einträgen über bspw. einen Zeitraum. Aber das vermutlich nicht wirklich gehen, sonst bräuchtest du vermutlich nicht die Voranzeige.

Pfade in der DB sind nicht unbedingt immer gut, sobald Benutzer die Möglichkeit haben umzustrukturieren. Eine Filesystem ist ein hierarchische DB :-D (ala LDAP).

Habe ich das richtig verstanden. Du speicherst so eine Art 'Thumbnails'/Vorschaubild von größeren Dateien ein der DB zur Ansicht und willst nicht die Datei holen.

Du hast keine Chance das Processing des Bilds von 5 Sekunden zu beschleunigen?

Zitat:

Zitat von KodeZwerg (Beitrag 1400245)

Zitat:

Zitat von mkinzler (Beitrag 1400239)

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

Das beantwortet schon mal eine meiner Fragen wo ich noch am lesen/lernen der Doku bin, was mein Grundkonzept, weil ich es nicht besser wusste, bereits allen Wind aus den Segeln nimmt :thumb:
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken. :warn:
Ich breche an dieser Stelle mal ab bevor hier noch ein Streit wegen meiner Unwissenheit entsteht.
Erstmal werde ich nun als Hausaufgabe lesen/lernen/Konzept planen auf haben und melde mich bei Fragen zurück.
Vielen Dank für all Eure Verschiedenen Ansätze mir helfen zu wollen und es tut mir leid wenn ich mich falsch Ausdrücke!

[KodeZwerg]

Hallo, in der DB soll kein Pfad, nur der Name der Datei als Referenz + dessen CRC + ein/zwei Bilder.
.....ich könnte auch auf Name verzichten und nur noch CRC als Referenz nutzen, aber da würde ich nicht Wissen wie ich einen Eintrag wieder los werde (wenn Original Datei fehlt).....
Ziel: Es soll auf gar keinen Fall "extern" angefangen werden Bild-Dateien wild zu schreiben, ob mit System oder nicht -> das ist ein No-Go.
Konzept: In Planung.
Der Programm Ablauf ausführlicher Erklärt:
Haupt .exe hat verschiedene Funktionen, unter anderem eine Bild-Analyse.
Die Bild-Analyse ist realisiert durch eine Dll an der wir arbeiten.
Die Übergabe an Dll erfolgt als Handle + Namen + Boolean, es wird ein Bild als Result wiedergegeben oder dessen Fehler-Code.
Das Handle ist ein Stream, der Name wird aufs Bild projeziert und der Boolean steuert welchen Bild-Typ generiert werden soll.
Die Berechnung selbst erfolgt bereits multi-threaded und ist auf gleicher Höhe wie bei Konkurenzprodukten.

Das was ich gerne hätte wäre Vergleichbar vom Prinzip mit so etwas:
Ein Ordner mit sehr viel Bild-Dateien für die Du einen Betrachter programmierst der eine Thumbnail Datenbank intern verwendet/verwaltet um eine schnelle Vorschau präsentieren zu können. Ich brauche als Result halt immer nur eines dieser Thumbnails und nicht alle wie beim Betrachter Beispiel.

edit
Zu dem No-Go:
Es gab bereits eine alpha-phase in der wir pro Datei ein Bild generierten was intern über Meta-Daten gesteuert wurde, funktionierte auch tadellos aber der Vorschlag wurde abgelehnt.

[MichaelT]

War bei einer Instandhalteranwendung in der Voest Linz / Stahl auch sehr beliebt und ist es vermutlich immer noch.

Wenn eine Anlage zu reparieren ist muss es schnell gehen und sehr viele Menschen fassen gleichzeitig Materialien aus. Die nn Delphi entwickelte Lösung lief einfach. Selbst als 'das Netzwerk' (ein Teil) ausfiel wurde die DB Datei einfach auf einen anderen Server kopiert und es konnte weitergearbeitet werden.

Bei großen Schuppen wird gerne auch probiert mit SAP zu arbeiten, damit Replikation wird eingespart. Im SAP war was auf eine Delphi Maske mit TabControl passte in SAP 20 Dialogen abgebildet (im SAP). Eigenentwicklung in ABAP wurde abgelehnt, da selbst der einfachst gestaltete Prototyp besser lief als die Standardtransaktionen und das kann nicht sein.

Deswegen kommt man ohne Delphi nicht durch oder zumindest .net hilft schon. Oft sind politische Entscheidungen der Enabler für andere.

Solche straighten Lösungen sind beliebt solange die DB zumindest nicht zu oft und per Anwendung kann reorganisiert werden. Was mit wieder zum Punkt bringt, dass die DB schnell zu sichern sein sollte und gegebenfalls from Scratch der Generierungsprozess eilig reproduziert werden muss können. Wenn mal was wäre, dann wird auf den Codezwerg hingehackt von den Benutzern.

OT:Zumal man seit dem gestern Rider IDE habe probiert neben Go-Land muss ich sagen langsam bilden sich auch komfortable Alternativen für die Entwicklung auf der Serverseite mit gelegentlichem GUI heraus.

Ersatzhardware muss nicht immer gleich schnell sein. Das ist zwar heute nicht mehr so das Thema. Je größer die Datenbestände des schwieriger das Backup usw... und damit singt auch die Willigkeit ein Backup ...

50k neue Sätze im Jahr auf einer großen Tabellen und du weißt warum die Oracle so viele Optionen hat bei so manchem Statement.

Zitat:

Zitat von mensch72 (Beitrag 1400178)

nutzen ein Zukauftool. (Letztendlich eine "SingleFileEngine", welche Single/Multiuser, Compress/Crypto und SimpleIndex/SQLselect sauber und wirklich schnell selbst löst)

[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 :thumb:

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

Zitat von himitsu (Beitrag 1400348)

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

Zitat von Neutral General (Beitrag 1400359)

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:

Zitat von jobo (Beitrag 1400361)

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 :mrgreen: