Datenbanken auf externe Platten auslagern?

[jobo]

Zitat von Delbor:

Was spricht dagegen, eine Datenbank (zB. SQLite) auf einem externen Laufwerk anzulegen?

Wer meine Threads etwas verfolgt hat, weiss, dass ich für meine Bilderdatenbank aktuell MySQL verwende. Doch schon seit geraumer Zeit liebäugele ich damit, dafür SQLite einzusetzen, da meine Anwendung grundsätzlich keine Multiuserfähige DB benötigt.

Die Lösung sehe ich darin, für die verschiedenen benötigten Formate jeweils eine eigene DB zu erstellen, und jede dieser separaten DB's muss sich auf einem beliebigen, auch externen, Laufwerk befinden.
Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden (es gibt, zumindest in der Community-Version nur ein DataDir), bin ich nicht sicher, ob mein Vorhaben (mehrere DBs auf verschiedenen externen Laufwerken) so ohne weiteres umsetzbar ist.

Also bei SQLite spricht nichts gegen ein externes Laufwerk. Außer dass man die mal versehentlich abklemmt und das auch eine SQLite DB vielleicht nicht überlebt (ähnlich wie ein FileCopy in einer laufenden mySQL Instance schwerlich funktioniert)
Erinnere ich mich richtig, dass Du mit der mySQL DB "Schwierigkeiten" hattest, nachdem Du Dateien im laufenden Betrieb kopiert hast?

Falls ja oder auch falls ich mich vertue:
Ich krieg bei solchen Fragen leichtes Magenzwicken. (Der Thread mit der defekten mySQL DB steckt mir wahrscheinlich noch irgendwo quer)

Ich kann verstehen, wenn Du mit SQLite Komplexität abbauen willst gegenüber mySQL. Aber ich habe Zweifel, ob Du da richtig dran gehst.

zuerst: Auch wenn SQLite nur noch eine Datei ist, sowas gehört allenfalls als Backup oder vielleicht in Form eines Netzlaufwerks nicht auf eine lokale Platte.
Wie DB auf Verbindungsabbrüche, Schreibstörungen, .. reagieren kann man in dem erwähnten Thread nachlesen. Das gilt auch für DB, die nur aus einer Datei bestehen.
Dass Du fehlende Multiuserzugriffe anführst, zeigt ja, dass Du Dir Gedanken gemacht hast, aber wenn es um meine eigenen Daten geht und davon noch Terrabyte, würde ich mir recht viele Gedanken machen.

zweitens: gleichförmige Daten in verschiedene Tabellen oder sogar Datenbanken zu speichern ist möglich, aber erhöht den Programmier / Adminaufwand unnötig. Es muss halt alles 2x, 3x, 5x gemacht werden und im Zweifel muss es sogar noch konsistent sein.

drittens: wenn man Daten in diesem Volumen bewegt, will man das gar nicht monolitisch in einer Datei haben. Auslesen und Befüllen, Hoch- Runterladen will man in bequemen Häppchen machen, asynchron, internet / Bandbreitenfreundlich

4tens
"Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden .."
Vergiß diese Gedanken einfach, fast jedes RDBMS, dass mehr als eine Datei benötigt (also nicht SQLite, sondern alles was größer ist), erwartet einen Dateizugriff nach klaren Regeln. Die sollte man einhalten.
Datentransport erfolgt demnach per Backup/Restore, Export/Import, ..
Also egal wieviel Dateien und wo sie liegen und was (scheinbar) an oder aus ist, Datenbankdateien werden nicht kopiert, ob by mySQL oder anderswo (Ausnahmen habe ich genannt und sollten nur gemacht werden, wenn die Doku zweifelfreie Wege beschreibt, das zu tun)

Zu Deiner Frage: Für die Datenverwaltung ausschließlich mit gespeicherten Links (Basispfade + relative + Dateinamen) zu arbeiten wurde ja schon vorgeschlagen. Das scheint mir hier ein brauchbarer Ansatz, weil Zitat "kein Multiuserzugriff". Du musst also die Inhalte nicht besonders schützen (vor multiplen Usern) und kannst vermutlich bei Fehlbedienung oder Störung auch persönlich eingreifen und korrigieren.
Wenn Du mit solchen Links arbeitest, ist es dennoch sinnvoll, die Ziele der Links, Deine Dateien vor ungewollten Änderungen zu schützen.

[mkinzler]

Zitat:

... fast jedes RDBMS, dass mehr als eine Datei benötigt (also nicht SQLite, sondern alles was größer ist ...

Wobei die Anzahl der Dateien eines RDBMS ja nichts über es aussagt

[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