Re: Datenspeicherung in Datenbanken (war: DigiKam und die alten Bilder)
On 04/08/2010 02:28 PM, Michael Schuerig wrote:
> Das stimmt so nicht. Programme schreiben Dateien idealerweise atomar.
Leider sieht die Welt aber eher so aus das dies nicht jedes Programm
macht. Oder sollte man vielleicht auch sagen, gott sei dank?
Die KDE entwickler hatten es ja mit ihren Config Dateien nicht gemacht,
weswegen sie danach leer waren.
Atomar speichern bedeutet ansonsten noch das du synchron speichern
musst. Daher nach jeder kleinen änderung an einer datei musst du alle
puffer leeren, weiterhin muss dein Programm blockieren bis die
änderungen geschrieben wurden. Insgesamt gesehen bedeutet das einen
erheblichen Performance verlusts. Und der steigt an, je mehr dateien man
nutzt.
Weiterhin ist es unmöglich mehrere Dateien gleichzeitig atomar zu
speichern. Wen der Datenbestand auf mehrere Dateien aufgeteilt ist (wie
jemand ja meinte) kannst du schlecht alle neuen Dateien oder alle alten
dateien erlauben.
Weitere nachteile hatte "Lars Rohwedder" genannt. Du musst alle Daten
vollständig im Speicher halten können damit das geht. Du musst bei jeder
änderung den kompletten Datenbestand neu schreiben. Hardlinks werden
komplett unbrauchbar da du damit immer wieder neue Dateien erzeugst.
Weiterhin benötigst du somit auch immer den doppelten Speicherplatz. Den
du musst alte und neue Datei gleichzeitig speichern. Nachteile können
auch die Portabilität sein. Den eine Temp Datei erzeugen, den neuen
inhalt dort hineinschreiben, und dann zur neuen renamen geht wunderbar
auf linux. Windows maschienen haben aber erzwungene locks, da geht das
nicht, solange ein programm eine datei liest kannst du nicht einfach
eine neu erstellte datei über die alte renamen. Und wie bereits genannt
benötigst du immer synchrone Operationen was stark die Performance belastet.
Ansonsten ist damit nur das "schreiben" mit geregelt. Aber nichtmal das
Lesen. In der Regel möchtest du auch auf deine Daten zugreifen und die
daten lesen. Was waren die letzten xx Einträge ist mit SQL einfach, bei
einer XML, CSV basierten Speicherung musst du diese Logik selber
nachprogrammieren. Auch ist mehrfacher gleichzeitiger zugriff möglich.
Das pure Dateisystem hilft dir bei all diesen Sachen kein bisschen. Das
Dateisystem und das OS stellt dir nur die Möglichkeit zur verfügung
dateien zu lesen/erzeugen/ändern/löschen. All die anderen sachen musst
du selber Programmieren.
Und ich finde es etwas naiv zu glauben all diese sachen löst man mal
eben so. Den Datenbanken sind genau dafür da diese Probleme zu lösen.
Datenbanken wie SQLite haben nunmal Logs, Transaktionen, sie kümmern
sich darum daten zu lesen das nicht alle daten im RAM geladen werden
müssen, genauso beim schreiben der datenbestand nicht immer wieder
komplett neu geschrieben werden muss. Daten werden immer blockweise
geschrieben und nicht nach jeder fitzeländerung gleich neu
synchronisiert etc. Das korrekte Handling mit Dateien und das bedeutet
schreiben/lesen und dieses auch performant ist nunmal schwer. Das OS und
das Dateisysteme sind nur dafür da Dateien selber zu pflegen, aber nicht
Dateiinhalte. Für Dateiinhalte hat man nunmal Datenbanken.
> Datenbanken schreiben ihre Daten nicht in dieser Weise, sie führen
> Ändern innerhalb einer oder mehreren Dateien durch. Dabei garantieren
> sie zwar durchaus eine konsistente Sicht auf die Daten und können sie
> auch nach einem Absturz wiederherstellen. Das gilt aber nur für die
> Sicht, die das DBMS selbst auf die Daten hat. Für ein Backup-Programm,
> das am DBMS vorbei auf dessen Dateien zugreift, gelten diese Garantien
> nicht.
Ist bei normalen Programmen nicht anders. Atomare Speicherung ist eine
Sache, macht aber nicht jedes Programm. Erstelle einfach mal ein großes
Bild in Gimp. Speichere die datei und schau dir im dateisystem an was
passiert. Gimp speichert die datei sofort in-place neu.
Stürzt Gimp ab dabei, ist hier aber die komplette datei verloren. Ein
Backup Programm sieht ebenfalls nicht ob eine datei noch geschrieben
wird oder nicht.
> Ich will darauf hinaus, dass die Datensicherung möglicherweise nicht
> ganz so einfach ist, oder nicht das leistet, was vermutlich die meisten
> Benutzer erwarten.
Sicherlich, eine korrekte Datensicherung ist nie einfach.
> Es ist möglich, dass man zwar ein Backup einer dieser
> Datenbanken hat, dieses aber nicht brauchbar ist.
Und das kann dir bei normalen dateien ebenso passieren. Man könnte
höchsten erwähnen das bei Datenbanken Schreibzugriff wohl öfter
auftreten, und dort die chance höher ist.
Wobei die schreibzugriffe ja anscheind nötig sind, und wenn man soetwas
selber implementiert man nicht unbedingt etwas besseres auf die beine
stellt. bzw damit endet das man praktisch seine eigene Datenbank im
Programm nachprogrammiert.
Daher man verschwendet mehr zeit damit daten/dateien korrekt zu
lesen/schreiben/ändern als effektiv etwas sinvolles zu erledigen.
Reply to: