Datenspeicherung in Datenbanken (war: DigiKam und die alten Bilder)
On Thursday 08 April 2010, David Raab wrote:
> Wem seine Daten wichtig sind macht vorher ein Backup. Auch bevor er
> eine neue Version einspielt. Die Argumentation das ich eventuell
> viel rumfrickeln kann wenn irgendetwas schief geht, finde ich
> unpassend.
Hier liegt allerdings eine Schwierigkeit, wenn man Daten in Datenbanken
speichert. Wenn alle Daten in strukturierten Textdateien liegen, INI
oder XML, dann ist die Wahrscheinlichkeit ziemlich groß, dass man beim
Backup eine konsistente Sicht zumindest der einzelnen Dateien bekommt.
Bei Datenbanken sieht das anders aus. Wenn der Backup-Prozess gerade
dann eine (der) Datenbankdatei(n) kopiert während das DBMS in die
Datenbank schreibt, ist die Konsistenz der gesicherten Datei fragwürdig.
Das Backup braucht für den Kopiervorgang Zeit und bekommt daher eben
nicht die Sicht zu einem Augenblick auf die Datenbank. Um ein sicheres
Backup zu bekommen, muss man -- eigentlich -- entweder vorher den
Datenbankprozess beenden oder transaktional einen Dump ausführen und
diesen sichern.
Ein solches Vorgehen ist, denke ich, üblich bei Benutzern, die
Datenbankserver nicht nur "zufällig" auf ihren Rechnern haben. Bei
Benutzern, die gar nicht wissen, welche Datenbanken sie überhaupt haben,
sieht das wohl ganz anders aus. Nehmen wir den Fall KDE 4:
Akonadi und Nepomuk, die das Backend für die Speicherung von PIM-Daten
und für den "semantischen" Desktop bilden, starten (für jeden
angemeldeten Benutzer!) eine eigene MySQL-Instanz und eine Virtuoso-
Instanz.
Digikam speichert seine Daten in einer SQLite-Datenbank.
Amarok verwendet ein eingebettetes (ohne eigenen Prozess) MySQL.
Michael
--
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/
Reply to: