AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Datenbank für schnelle Bilder, Vorschläge bitte.
Thema durchsuchen
Ansicht
Themen-Optionen

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

Ein Thema von KodeZwerg · begonnen am 22. Apr 2018 · letzter Beitrag vom 28. Apr 2018
Antwort Antwort
Benutzerbild von KodeZwerg
KodeZwerg

Registriert seit: 1. Feb 2018
3.691 Beiträge
 
Delphi 11 Alexandria
 
#1

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

  Alt 23. Apr 2018, 12:50
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
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken.
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!
Gruß vom KodeZwerg
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
562 Beiträge
 
Delphi 10.3 Rio
 
#2

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

  Alt 24. Apr 2018, 08:34
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 (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?


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
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken.
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!
  Mit Zitat antworten Zitat
Benutzerbild von KodeZwerg
KodeZwerg

Registriert seit: 1. Feb 2018
3.691 Beiträge
 
Delphi 11 Alexandria
 
#3

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

  Alt 24. Apr 2018, 09:16
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.
Gruß vom KodeZwerg

Geändert von KodeZwerg (24. Apr 2018 um 09:35 Uhr)
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.600 Beiträge
 
Delphi 7 Professional
 
#4

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

  Alt 24. Apr 2018, 10:31
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.
  Mit Zitat antworten Zitat
Benutzerbild von KodeZwerg
KodeZwerg

Registriert seit: 1. Feb 2018
3.691 Beiträge
 
Delphi 11 Alexandria
 
#5

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

  Alt 24. Apr 2018, 13:21
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
Gruß vom KodeZwerg
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.590 Beiträge
 
Delphi 12 Athens
 
#6

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

  Alt 24. Apr 2018, 13:45
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/
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.882 Beiträge
 
Delphi 11 Alexandria
 
#7

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

  Alt 24. Apr 2018, 13:58
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.
Markus Kinzler
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#8

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

  Alt 24. Apr 2018, 15:09
..
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:37 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz