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

[jobo]

Zitat von KodeZwerg:

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

Würde mich jetzt überraschen, wenn sqlite schnell ist. Aber für single user Betrieb vielleicht okay.

[KodeZwerg]

Erste Tests mit MyBase/TClientDataSet werden arg langsam bei Datensätzen jenseits von 10k, das erschien mir am einfachsten zu Testen und fällt bei mir als Möglichkeit raus, Perfomance Vergleiche zwischen Firebird und SQLite finde ich nur veraltete, werde da auch meine Eigenen Tests erstellen aber wenn Du einen Hinweis/Link hättest der verschiedene Freie DBs vergleicht schau ich da auch gerne mal rein.

[IBExpert]

Firebird ist de facto eine gute Wahl für Blobs in der Datenbank, Referenzen ins Filesystem speichern ist lustig, aber Unsinn, wenn man mit richtig großen Datenmengen zu tun hat.

Auch die schönste Directory Struktur, die vermeidet das man 1 mio Dateien in einem Verzeichnis hat, ist durch den Super DAU User mit der Maus schneller verschoben als man denkt und dann findet man nix wieder. Es hindert auch nur ein Readonly Verfahren oder NAS Techniken einen daran, davon einfach Dateien zu löschen. Speziell die NAS Technik geht dabei extrem auf die Performance. Von interessierter Verschlüsselungstrojanern, die gerne mal alle erreichbaren Dateien in allen Laufwerken encrypten rede ich da jetzt noch mal gar nicht.

Wir haben in einer Produktivdatenbank beim Kunden ca 300 GB PDFs und passende Png Previews der erste Seite, sind insgesamt ca. 900000 Images und 900000 Pdfs.

Sicherlich lässt sich die DB nicht so einfach backup/restoren, aber wir haben die auch aufgeteilt in Daten bis inkl 2017 (die db ist readonly, hat ca 250GB und muss nur ein mal pro Jahr gesichert werden) und in eine aktuelle Jahres DB, in der alle Dateien aus dem aktuellen Jahr landen. Diese wird täglich gesichert (und durch Replikation transaktionsecht auf 2 Servern gespeichert, aber das ist ein anderes Thema). Ende 2018 werden wir dann ggf die DB von Ende 2017 wieder Readwrite machen, die Daten aus der 2018 DB dahin verschieben und danach die große als neue 2018 DB wieder Readonly setzen.

Den Zugriff auf die Inhalte machen wir immer über eine Stored Procedure und diese sucht dann den Blobinhalt per execute statement on external zunächst auf der aktuellen Jahres DB und wenn da nix zu finden ist, dann eben auf der Archiv DB. Per Updatable View kann man das in der Produktionsdatenbank auch direkt einbinden, so das die Blobsspalte in der Tabelle zwar so aussieht, als ob die dazu gehören würden, in Wirklichkeit aber die SP zum Abruf nutzt und eine schreibende SP benutzt, um die daten in die aktuelle Jahres DB zu packen.

Die Datei Metadaten (also welche Blob Dateien existieren denn überhaupt) bleiben in der Produktionsdatenbank, die Blobs landen immer schon beim Schreiben gleich in der Jahres DB.

Mit dem Updatable View lassen sich sogar Programme austricksen, die gar nicht wissen das die Blobs woanders sind. Das haben wir gerade für einen Kunden in USA so gemacht und realisieren das auch für einen Softwareanbieter in Deutschland. Dabei wird unter dem alten Tabellennamen ein updatable view erzeugt und die Blobspalte kommt aus einer anderen db und wird auch da geschrieben, im Programm muss nichts geändert werden.

Bei dem Kunden in Deutschland steht übrigens dann auch immer in der Produktionsdatenbank in der Tabellen mit den blob metadaten das Erstellungsdatum und wir benutzen da die Jahreszahl, um pro Jahr jeweils eine DB zu haben. Das sind dann zwar ein paar mehr dateien auf dem Datenbankserver, aber man ist sehr flexibel und da alle alten dbs readonly sind, muss man das nicht ständig sichern.

Mein Erfahrung damit ist übrigens das die Blob daten sehr schnell aus der DB geholt werden. egal ob eine db oder mehrere, wenn du aber eine Übericht von zB 300 Bilder darstellen willst, verbraucht die meiste zeit gar nicht das Laden vom Blob, sondern das decodieren von png oder jpg. Das war bei uns ein Unterschied von 0,2 sekunden (in der zeit waren alle blobs geladen, aber nicht angezeit) und 10 Sekunden (das war Laden der Blobs aus der DB und Anzeigen von 300 150*250 pixel pngs jeweils in 50*75 images auf einer scrollbox. Das können verschiedene Image Komponenten sehr unterschiedlich schnell oder lahm)

[Rollo62]

Firbird ist extrem stabil bei zig GB von Daten, setze ich gerne ein (im Moment 2.5.x, Planung zu 3.0.2 bald).
Sqlite auch gerne, weil Crossplattform, nicht mit mehreren GB getestet.

Dies ist vielleicht auch lesenswert, noch nicht ganz so alt ...
https://blog.devart.com/increasing-s...rformance.html
https://code.i-harness.com/de/q/365eb
http://www.itexto.net/devkico/?p=398

Rollo

[KodeZwerg]

Firebird: Test-Project mit 50000 Datensätze ausprobiert, das Bereitstellen der Daten von DB wenn Index bekannt ist geht extrem rasant, längste Zeit wird beim Suchen und Vergleichen von Feld "Name" verballert, suche läuft bereits im Eigenen Thread.
Dennoch wird momentan weniger Zeit mit suchen verbraucht als mit einer Bild-Neuberechnung. Wenn sich das beim zehnfachen Datensatz nicht ändert bin ich am Ziel
Momentan wird Datenbank wild beschrieben, ohne sortierung oder der gleichen.
Suchen und finden eines Datensatzes dauert grob 2 Wimpernschläge, vielleicht auch weniger/mehr, alles nur objektiv betrachtet, keine Nanosekunden genau Benchmark Session nötig gewesen.
Als Unterbau/Schnittstelle für Delphi nutze ich UIB.
Nun fang ich an mich dem Thema partitionieren zu nähern, da weiß ich das weder FB3 noch SQlite3 das nativ können.
Mit dem "Jahreszahlen" Tipp kann ich auch etwas anfangen und werde es so umsetzen, das klingt für mich logisch nachvollziehbar (kleinere DB = schnellere Suche).
Vielen Dank das Ihr mich in die Richtung bewegt habt wo ich nun bin, Danke!

[mkinzler]

Zitat:

längste Zeit wird beim Suchen und Vergleichen von Feld "Name" verballert, suche läuft bereits im Eigenen Thread.

?
Suche sollte doch das DBMS machen?
Was steht genau in diesem Feld? Passender Index?

[KodeZwerg]

Die Suche ist Aufgebaut nach diesem Beispiel-Code von UIB:

Delphi-Quellcode:

unit main;

interface

uses
{$IFDEF LINUX}
  libc, QForms, QStdCtrls, QControls, QGraphics, QDialogs, QExtCtrls,
{$ELSE}
  Windows, Graphics, Controls, Forms, Messages, Dialogs, StdCtrls,
{$ENDIF}
  SysUtils, Classes, uib, SyncObjs;

type
  TForm1 = class(TForm)
    DataBase: TUIBDataBase;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;

  TMyThread = class(TThread)
  protected
    procedure Execute; override;
    destructor destroy; override;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
begin
  for i := 0 to 49 do
    TMyThread.Create(False);
end;

var
  x: integer = 0;

{ TMyThread }

destructor TMyThread.destroy;
begin
  inherited;
end;

procedure TMyThread.Execute;
var
  Query: TUIBQuery;
  Transaction: TUIBTransaction;
begin
  FreeOnTerminate := true;
  // Form1.DataBase.Lock; //simulate single thread
  try
    Query := TUIBQuery.Create(nil);
    Transaction := TUIBTransaction.Create(nil);
    try
      Transaction.DataBase := Form1.DataBase;
      Query.Transaction := Transaction;
      Query.FetchBlobs := True;
      Query.SQL.Text := 'select * from project';
      Query.Open;
      while not Query.EOF do
      begin
        Query.Next;
        Sleep(10); // simulate activity
      end;
    finally
      Query.Close(etmCommit);
      Query.Free;
      Transaction.Free;
    end;
  finally
    // Form1.DataBase.UnLock; //simulate single thread
  end;
end;

end.

Die Bilder hole ich mir wie in diesem UIB-Code Sample:

Delphi-Quellcode:

unit main;

interface

uses
{$IFDEF LINUX}
  libc, QForms, QStdCtrls, QControls, QGraphics, QDialogs, QExtCtrls,
{$ELSE}
  Windows, Graphics, Controls, Forms, Messages, Dialogs, StdCtrls, ExtCtrls,
{$ENDIF}
  SysUtils, Classes, uib;

type
  TMainForm = class(TForm)
    Image: TImage;
    LoadImage: TButton;
    SaveImage: TButton;
    DataBase: TUIBDataBase;
    Transaction: TUIBTransaction;
    Query: TUIBQuery;
    OpenDialog: TOpenDialog;
    procedure LoadImageClick(Sender: TObject);
    procedure SaveImageClick(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  MainForm: TMainForm;

implementation

uses Math;

{$R *.dfm}

procedure TMainForm.LoadImageClick(Sender: TObject);
var
  Stream: TMemoryStream;
begin
  Query.SQL.Text := 'Select Stream from TBLOB';
  Query.Params.Clear;
  Query.Open;
  Stream := TMemoryStream.Create;
  try
    Query.ReadBlob('STREAM', Stream);
    Image.Picture.Bitmap.LoadFromStream(Stream);
  finally
    Stream.Free;
  end;
  Query.Close(etmCommit);
end;

procedure TMainForm.SaveImageClick(Sender: TObject);
var Stream: TFileStream;
begin
  If OpenDialog.Execute then
  begin
    Stream := TFileStream.Create(OpenDialog.FileName, fmOpenRead);
    try
      Query.SQL.Text := 'UPDATE TBLOB SET STREAM = :blob';
      Query.ParamsSetBlob('blob', Stream);
      Query.ExecSQL;
    finally
      Stream.Free;
    end;
    Query.Close(etmCommit);
  end;
end;

end.

[jobo]

Zu sqlite versus irgendwas habe ich keine Zahlen, nur .
Falls Du selber den Vergleich auf der sqlite Seite meinst, der ist tatsächlich schon sehr alt und die Zahlen auch schwer nachvollziehbar, wie sogar der Artikel selber angibt.

Was hindert Dich, den Hahn aufzudrehen und Deine Tests mit 500k Datensätzen zu machen?
Das sollte problemlos sein. Jedenfalls würde ich das machen, bevor ich mit "künstlicher" Partitionierung ala Jahreszahlen anfange. Dieses Modell würde ich nur unter Zwang und bei ziemlich statischen Daten anwenden, um meinetwegen Backupplatz zu sparen. Oder wenn es sich sonst wie rechnet, also Implementierungsaufwand gegen Nutzen.

Der Frage von mkinzler kann ich mich nur anschließen, was macht der Thread?
Es geht doch nur um das Absetzen einer Abfrage mit einer Antwortzeit von vermutlich Millisekunden?

[jobo]

Zitat von KodeZwerg:

Die Suche ist Aufgebaut nach diesem Beispiel-Code von UIB:

Das sucht aber nicht, sondern kaut alle Datensätze inkl. BLOB durch, lokal.

[mkinzler]

Dieser Code scheint wenig mit dem eigentlichen Programm gemein zu haben und eigenet sich m.M. nach wenig das spätere Verhalten nachzubilden.
Da immer die komplette Tabelle gelesen wird, braucht das natürlich umso länger je mehr Datensätze da sind. Im Normalfall sollte man ja nur die Daten anfordern, welche benötigt werden.
Die Performance einer Datenbankanwendung steht und fällt mit dem Entwurf der Abhängigkeiten und Anlage von Indices.