Datenbanken auf externe Platten auslagern?

[jobo]

nein, nicht viel, wie soll man das formulieren? Ab >1 ist mit großer Wahrscheinlichkeit ein innerer Zusammenhang der beiden Dateien gegeben und wenn es nur .ini und .data ist. Das scheint mir filigraner als 1x .sqlite oder .doc oder .xls
Und selbst die kann man zersemmeln.

[Delbor]

Hi zusammen

@Daniel:

Zitat:

Ich habe den Titel mal angepasst.

Vielen Dank dafür !

@alle: Herzlichen Dank für eure Antworten!

Ich nehme mir da noch etwas mehr Zeit, um mal alles etwas zu studieren. Aber grundsätzlich scheint mir das bis jetzt dahin zu gehen:
Meine Anwendung ist gewissermassen die "Zentrale". Und daher und auch aus Gründen der geplanten Client-Server-Kommunikation kann/sollte die selbst nicht auf SQLite aufbauen, sondern weiterhin auf MySQL.

Übrigens, um Missverständnissen vorzubeugen: Die Webserver-DB und diejenige meiner Anwendung werden nicht die selben Strukturen aufweisen; auf dem Webserver gibt es weder ein Feld für NEF-Dateien noch ein solches für Bitmaps. Vielmehr tendiere ich bis jetzt dazu, die Webinhalte selbst, also HTML, Jpeg, CSS und allfällige Javascripts da in Dateien abzulegen

@jobo:

Zitat:

Erinnere ich mich richtig, dass Du mit der mySQL DB "Schwierigkeiten" hattest, nachdem Du Dateien im laufenden Betrieb kopiert hast?

Ja.

Zitat:

Da dein Programm eigentlich wie ein DMS funktioniert und mit kein DMS bekannt ist, welches so große Dateien in seine DB speichert, solltest Du Dir vielleicht überlegen die Dateien nicht mehr in die DB zu packen, sondern extern und nur eine Verlinkung mit Tags und Co in der DB zu speichern.

Dann kannst Du auch SQLite verwenden..

Hmmm... Da muss ich jetzt doch zusehen, dass ich das richtig verstehe. Du sprichst da von einer Anwendungs-DB, die auch SQLite sein könnte? Und Dateien der benötigten Formate, die auf externen Festplatten vorliegen und deren Pfade in der Anwendungs-DB stehen?

Was spricht dagegen, diese Dateien statt direkt auf der Platte in einer eigenen DB abzulegen? Und zwar jeweils eine für Bitmaps (3 Felder: PK, Blob(Bitmaps), Boolean (un- bzw.bearbeitet) und eine für RAW-Bilder (3 Felder: PK, Blob(NEF) und Boolean (un- bzw.bearbeitet*). Klar, die Kommunikation dürfte so nur über eine OOP-Lösung möglich sein. Aber die beiden 'Datenbanken' könnten so auf verschiedenen externen Platten liegen.

In DataSnap selbst muss ich mich noch einarbeiten und kann mir desshalb noch keine Vorstellung machen, was damit alles möglich ist.

* Gibt an, ob es für das NEF-Bild schon eine Bitmap gibt.


Gruss
Delbor

[himitsu]

Bei DataSnap kannst du praktisch "Prozeduren" auf dem Server aufrufen, so als wären die direkt bei dir im Programm.

DataSet/Streams können dabei als Parameter/Result übergeben und abgefragt werden.
Bei dem Stream am anderen Ende muß man nur etwas aufpassen, da viele Dinge nicht damit zurecht kommen, wenn Stream.Size plötzlich mal -1 sagt.
Size ist nur >0 wenn alle Streamdaten in eine Netzwerkpaket passen. Sonst werden die Daten erst beim Abruft übertragen, so lange bis man beim Leseversuch (Read) 0 Byte zurück bekommt.
Aus diesem Grund hatten wir damals das DataSnap nochmal weggekapselt und kopieren die Streams nach dem Übertragen nochmal in einen MemoryStream um.

[Delbor]

Hi himitsu
Auch dir vielen Dank für deine Antwort! Datasnap wird wohl noch manchmal Grund liefern, hier Fragen zu stellen. So aus dem Stegreif erinnere ich mich gerade mal an eine sehr einfache Client-Server-Demo.
Datasnap und Demos, die mit Firedac arbeiten, ist allerdings auch einer der Gründe, wieso ich auf letzteres umgestiegen bin/umsteige.

Ich frage mich jetzt aber auch, ob nicht gerade Firedac eine mögliche Antwort auf meine Frage ist. Stichwort: TFDMemTable - aber da kann ich falsch liegen.

Gruss
Delbor

[Mavarik]

OK nur damit auch ich es verstehe...

Du willst eine externe Platte verwenden, weil Du nicht alle Daten gleichzeitig hast, richtig?

Der Server hat wieder anderen Datenbanken / Felder... Willst Du die Datenbank direkt auf den Karten der Kamera speichern?

Also Bilder die lokal vorliegen als Kopie in einen Datenbank zu speichern, macht für mich keinen Sinn... Also nur einen Pfad in die Datenbank oder die RAW-Daten erstmal Packen und dann in die Datenbank...

Die Übertragung zum Server würde ich - falls FTP keine option ist - entweder per SOAP (Einfacher in der Handhabung) oder per REST (weniger overhead) zum Server übertragen.

Mavarik

[Delbor]

Hi Maverik

Zum jetzigen Ist-Zustand:

• Meine Anwendung baut auf einer MySQL-Bilderdatenbank auf. Die Bilder sollen/werden von Festplatte (Dateien, extern, Festplatten oder Sandisk-Karten) im Rohdatenformat (NEF) eingelesen. Davon gibt es
• Bitmaps mit den Pixelabmessngen des Roh-Bildes (Originale Datenmenge zur Bearbeitung)
• Jpegs, grösste Seitenlänge max.(?) 1200px, Webseitenverträglich
• Daneben gibt es noch Tabellen/Felder für HTML, CSS und Javascript

Ideen zur weiteren Entwicklung:
Aufgrund der zu erwartenden Datenmenge/Dateigrösse der Bilder denke ich, sollten die beiden Formate auf externen Festplatten (In je einer DB? Je einer/mehreren Festplatten?) gespeichert werden, so dass die "Mutteranwendung" die Bilder zur Bearbeitung aus der NEF- bzw. Bitmapdatenbank lädt. Nef_Dateien werden dabei in Bitmaps konvertiert, so dass diese mit einem externen Programm zur Bearbeitung gestartet werden können.
Anschliessend wird die Bitmap in ein Jpeg konvertiert und in der DB der Mutteranwendung gespeichert.
Die bearbeitete Bitmap wird der Bitmap-DB übergeben und da gespeichert.
Die Mutteranwendung erstellt (bzw. der User) aus den in der DB vorgehaltenen Daten Webseiten (In je einer Klasse), denen der User per drag and Drop Bilder und Kommentare zuweisen kann.
Diese Webseiten bleiben in der DB gespeichert, entweder zur weiteren Bearbeitung oder um sie nach Fertigstellung an eine Webserveranwendung zu übermitteln.

Soweit mal ein kurzer Überblick, wobei der Listenabschnitt den Ist-Zustand wiedergibt. Der zweite Abschnitt enthält hingegen bereits einige Ideen zur Weiterentwicklung.
MySQL wird von meinem Hoster als Webseitendatenbank bereitgestellt, weshalb dies das DBMS für meine Webserveranwendung ist.
Auf meinem Rechner würde ich allerdings gerne SQLite einsetzen, wobei ich an eine solche DB für alle drei Anwendungen (Mutteranwendung, Nef-DB und Bitmap-DB) dachte. Mir ist bewusst, dass ich zum Datenaustausch eine OOP-Lösung benötige.

Noch zuwenig angesehen habe ich mir die vorgeschlagene NoSQL-Datenbank. Wobei - wenn ich mir das überlege, wäre ja eine Client-Server-Lösung mit DataSnap/FireDac und allenfalls SQLite eben eine NoSQL-Datenbank - laut Wikkipedia ist eine NoSQL-DB eben nicht unbedingt (oder gar nicht?) eine DB ohne SQL, sondern eine DB, die nicht ausschliesslich auf SQL aufbaut (zumindest, soweit ich das bisher verstanden habe).

Zitat:

Du willst eine externe Platte verwenden, weil Du nicht alle Daten gleichzeitig hast, richtig?

Nicht ganz. Die Gesamtheit der Bilddaten wird schnell mal zu gross. Diese füllen jetzt schon (zugegebenermassen etwas Chaotisch) eine Terrabyte-Platte. Dies zwar dank der Verarbeitung "von Hand". Trotzdem würden diese Bilder in einer DB-Lösung nicht viel weniger Platz beanspruchen.

Zitat:

1. Der Server hat wieder anderen Datenbanken /
2. Felder... Willst Du die Datenbank direkt auf den Karten der Kamera speichern?

1. Ja, die DB der Webserveranwendung wird ganz anders aufgebaut sein(User- und Sessionverwaltung etc)
2. Nein, da hat sie definitiv keinen Platz. Hingegen kommen sie von da, entweder direkt oder mit Umweg über die Festplatte.

Zitat:

Also Bilder die lokal vorliegen als Kopie in einen Datenbank zu speichern, macht für mich keinen Sinn... Also nur einen Pfad in die Datenbank oder die RAW-Daten erstmal Packen und dann in die Datenbank...

Tatsächlich liegen die Bilder noch als Dateien auf der Festplatte - dies allerdings nur sollange, bis sie in der DB sind und eine gute Backuplösung vorliegt. Was ist eine "gute" Backuplösung? Eine, die die vorhandenen Rohdaten speichert, oder eine, die dasselbe mit bearbeiteeten Bitmaps macht?

Zitat:

Die Übertragung zum Server würde ich - falls FTP keine option ist - entweder per SOAP (Einfacher in der Handhabung) oder per REST (weniger overhead) zum Server übertragen.

Danke für den Tip! Weniger overhead spricht doch schonmal für REST. Alenfalls müsste ich zusehen, wie gut ich das dann verstehe.

Gruss
Delbor

[mikhal]

Schon mal darüber nachgedacht, in deiner Datenbank nur "Thumbnails" vorzuhalten, um einen Eindruck des Bildes mitzugeben und die "richtigen" Bilder in den Verzeichnissen zu lassen, wo sie gerade sind oder wo sie bleiben sollen. Selbst bei einem Thumbnail von z.B. 200 Pixel Breite liegen die Daten als Jpeg bei einigen hundert KBytes pro Bild. Du speicherst dann noch zusätzlich den Pfad zum richtigen Bild und schön ist.

Ich sehe darin folgende Vorteile:

1. Die Datenbank bleibt überschaubar in ihrer Größe und die Datenbanksicherung ist in einem vernünftigen Zeitrahmen zu realisieren.
2. Die Sicherung der Bilddaten erfolgt über ein Backup-Programm, das zu verteilten Zeiten bestimmte Verzeichnisse oder Laufwerke sichert. Bei vernünftiger Planung mit regelmäßiger, zeitaufwendiger Vollsicherung und täglicher Differenzsicherung bis zur nächsten Vollsicherung kannst du sowohl den Speicherbedarf als auch den Zeitaufwand begrenzen.
3. Für mich schon fast das Totschlagargument gegen "Alle Daten in einer Datenbank": Du hast es ja bereits erlebt: Datenbank defekt - alle Daten futsch!

Bei deinem Vorhaben musst du sowieso von einem echten Client-Server-Umfeld ausgehen, du benötigst enorm viel Speicher, egal wie du dich entscheidest. Technisch ist deine Datenflut, mit der du ja rechnest, nur mit einem entsprechenden Speichersystem zu begegnen - sei es ein SAN oder ein NAS.

Die Verteilung auf mehrere Platten / Speichermedien lässt sich am einfachsten über die Trennung deiner Bilder von deiner Datenbank realisieren. Dann ist es schon fast egal, welches Datenbanksystem du einsetzt.

Grüße
Mikhal

[Delbor]

Hi mikhal

Zitat:

Schon mal darüber nachgedacht, in deiner Datenbank nur "Thumbnails" vorzuhalten,

JA, habe ich.
Sir Rufo hat mir damals den Vorschlag gemacht, mit GUIDS zu arbeiten.

Der aktuelle Stand ist demnach: es gibt kein Feld für NEFs mehr in der DB, für Bitmaps hingegen schon:

Delphi-Quellcode:

function TFDMySQLDml.BildInsertQuery(BJpeg: TJPEGImage; WorkMap : TBitmap; LIdFolder: String): integer;
  var  SQLString: string;                //  BJpeg,
begin
  SQLString := 'Insert Into Bildtabelle(Thumbnail, Bitmap, FolderID) Values (:BJpeg, :Workmap, :LIDFolder)';
  FDQueryMain.SQL.Text := SQLString;
  FDQueryMain.Params[0].Assign(Bjpeg); 
  FDQueryMain.Params[1].Assign(Workmap);
  FDQueryMain.Params[2].AsString := LIDFolder;
  FDQueryMain.ExecSQL(false);
  if FDQueryMain.Active then
     FDQueryMain.Close;
  SQLString := 'Select Last_Insert_ID()AS LastID';
  FDQueryMain.SQL.Text := SQLString;
  FDQueryMain.Open;
  if not FDQueryMain.IsEmpty then
    result := FDQueryMain.FieldByName('LastID').AsInteger;      //
end;

Dabei wird in der aufrufenden Methode das NEF in ein TPicture-Objekt geladen, dieses dann in 2 TBitmaps, wovon eine skaliert und in ein Jpeg konvertiert wird. Das NEF-Bild wird anschliessend verworfen.
Es mag doof klingen, aber mit der TGuid-Lösung kann ich mich nicht wirklich anfreunden. Und zwar, weil dieser GUID nun in allen jenen Bildverzeichnissen steht, die schon mal eingelesen wurden. Das bedeutet: Wenn die Bilder, aus welchem Grund auch immer, neu eingelesen werden müssen, muss das Programm erstmal per Abfrage ermitteln, ob die Bilder in der DB sind oder nicht - und das verlängert die Zeit für Insert-Statements.

Andrerseits habe ich mir auch mal TFDMemTable angesehen. Das Schöne daranist: das Ding kann seinen Inhalt von der Patte laden und auch dahin speichern. Das Schöne daran ist: dieses Ding selbst ist, soweit ich das bisher verstanden habe, unabhängig vom verwendeten DBMS.

Und wenn ich mir die einzelnen Festplatten-Ordner und deren durchschnittliche Gösse ansehe (etwa 3GB für NEF-Ordner und rund das dreifache für Bitmap-Ordner (10 - 11GB) und das mit der Grösse meines neuesten USB-Sticks vergleiche (64GB), dann kkommen mir da einige Ideen...

Das heisst aber auch, dass es gar keine Datenbanken auf externen Laufwerken braucht - die sind je nach Zielsetzung eventuell bloss wünschbar...


Gruss
Delbor