Filesystem conta Datenbank - wo liegen Stärken und Schwächen?

    In den 15 Jahren als Systemmanager CATIA und Nemetschek Kompetenzpartner habe ich viele Vorteile von Filesystemen kennengelernt.
    Sie sind schnell, wenn die zu bearbeitende Datenmenge beim Aufruf angegeben werden kann. Bei Allplan FT wurde nur ein Teilbild (Layer) geöffnet, während Systeme wie AutoCAD, aber auch IDEAS oder UG immer fast das ganze CAD-Modell beim Start des Programms öffnen und handlen mussten. Folglich waren CATIA (auch ein Filesystem) und Allplan in der Arbeitsgeschwindigkeit vom Start an schneller. Auch das Speichern ging extrem flott. Hakelig wurde es hingegen beim Datenaustausch und beim Sichern der Daten. Beides war und ist im Vergleich mit den Datenbank-basierenden CAD-Systemen ziemlich umständlich.

    Aber wo stehen wir heute, wenn wir Kommunikationssysteme betrachten?
    Wie steht es um die Stärken und Schwächen heutiger Filesysteme, wie sie David nutzt?
    Und wo kann im Vergleich ein Datenbank-basierenden System seine Stärken ausspielen, und wobei hapert es, wenn wir Datenbanken nutzen?

    Ich bin auf Eure Antworten gespannt.

    Einmal editiert, zuletzt von Arno (4. Dezember 2014 um 11:20)

    Ich beschäftige mich beruflich mit Content Managment Systemen (CMS) - für das Druck- und Verlagswesen.
    D.h. große Verlage nutzen diese Systeme um ihre Dokumente zu verwalten und eine Änderungsverfolgung zu haben, bevor die Dokumente gedruckt werden.

    In diesem Umfeld wird mit großen Dateien, oft 100 MB gearbeitet.
    Bei solchen Größen macht eine reine Datenbanklösung keinen Sinn, hier wird ein Hybridsystem genutzt, d.h. die eigentliche Dokumente liegen in einer Ordnerstruktur im Filesystem (dort werden dann auch ältere Versionen vorgehalten).
    Die Metadaten die zu einem solchen Dokument liegen dann in der Datenbank - sodass eine Suche oder das Ändern von Daten blitzschnell geht.

    Bei den EML Dateien, um die es sich ja letztlich bei David handelt, sind die Metadaten ja bereits Bestandteil des Inhalts. Insofern ist der Weg den David geht nachvollziehbar.
    Inzwischen nutzen die ja auch so ein Hybridsystem, und in der Datenbank werden die Metadaten redundant abgelegt und für die Suche indiziert.

    Grundsätzlich erhöht eine Datenbank den Administrationsaufwand und es sind mehr Ressourcen nötig um eine Datenbank performant betreiben zu können, in der heutigen Zeit spielt so etwas allerdings nur noch eine untergeordnete Rolle.
    Aus meiner Sicht, könnte man bei David nur eine Sache anders machen, nämlich die einzelnen E-Mails ebenfalls in der Datenbank speichern und nur die Attachments im Filesystem lassen, in diesem Fall müsste man dann quasi vom EML weg - hin zu einem eigenen Format, aber dann hat man wieder Aufwand wenn man aus David als EML exportieren möchte.

    was david angeht wäre es wohl eher angebraucht ernsthaft in .eml zu speichern anstatt jede mail in min. 2 dateien zu splitten. das würde auch einen import in andere systeme (mail archivierung) und das recovern von daten vereinfachen. grundsätzlich ist das hybrid prinzip aus meiner sicht sinnvoll, bei tobit im speziellen aber schlecht umgesetzt.

    unter kerio z.b. läuft es so - "echte" .eml dateien die die komplette mail enthalten und eine db für die volltext suche.

    Filesysteme haben vor allem einen großen Vorteil, wenn einzelne große Dateien vorliegen. Jedes Plattensystem braucht eine erheblich Zeit um die Datei zu lokalisieren und anzufassen. Die Schreib und Leseraten sind heute kein Engpass mehr. Die Zugriffszeit verbessert sich sicherlich mit den SSD's, aber die hab ich noch nicht im Server.

    Bei vielen kleinen Dateien nimmt daher die Lokalisierung der Dateien auf der Platte die meiste Zeit ein. Genau da liegt der Schwachpunkt des Filesystems, das von Tobit verwendet wird, da hier bewusst viele kleine Dateien verwendet werden.

    Ich habe 800GB Tobit Daten. Wenn ich die kopieren will, kann ich den Rest der Firma in den Urlaub schicken ;( Eine Sicherung auf Dateiebene bringt mir Datenraten von deutlich unter 500MB / min.
    Sicherungen von anderen Daten vom gleichen Server und vom gleichen Festplattensystem laufen mit 3,500MB/min.

    Nach ersten Erfahrungen beschleunigt der Einsatz von SSD-Festplatten David sogar drastisch!
    Zumindest wenn Controller und CPU auf die Leistung des SSDs abgestimmt sind.
    Die SSD-Platte(n) eines Kommunikations- und Fileservers sollte für viele Schreibvorgänge ausgelegt sein.
    Das ist zum Beispiel bei den preiswerten EVO-Serien von Samsung nicht der Fall.
    Die sind eher für viele Lesevorgänge geeignet, wie sie zum Beispiel bei der Archivierung, in Online-Bibliotheken oder auch in Medienservern vorkommen.
    Sie sind ausgelegt für bis zu 600 TBW, also 600 Terabytes Bytes Written, übersetzt insgesamt 600 Terabyte geschriebener Daten bezogen auf die gesamte Plattenlebensdauer plus Reserve bei Normklima (23° C). Bei vielen kleinen zu schreibenden Dateien verringert sich dieser Wert. Und eine beständige Temperaturerhöhung bedeutet pro 10 Grad Celsius jeweils eine halbierte Lebenserwartung der Halbleiterbausteine von SSDs.


    Ausdrücklich für Dauerbetrieb und hohe Schreibraten ausgelegte SSDs von Samsung (Baureihe 845 DC Pro) sind in Terabyte-Größe im laufenden Jahr noch nicht lieferbar. Die aktuelle Obergrenze liegt bei 800 GB Kapazität. SSD Serverplatten dieser Serie und Größe kann ich ab Mitte Dezember 2014 liefern. Die kleineren 400 GB SSDs vom Typ Samsung 845DC Pro MZ-7WD800EW sind innerhalb eines Arbeitstages lieferbar. Beide Server-Festplatten können ab sofort über meinen Webshop oder telefonisch (02131-1515360) bestellt werden.

    Die hohen Durchsatzraten werden bei den Samsung 845 DC Pro-Serien kontinuierlich über Jahre gehalten, während SSDs der EVO-Serien schon binnen Jahresfrist Performanceeinbußen bei der Schreibleistung aufweisen können. Im Serverbetrieb rechtfertigt das die höhere Ausgabe für 845 DC - Pro Platten.

    Notfalls lassen sich die David-Daten bei 800 GB Datenbestand auf zwei oder drei kleinere SSD-Platten aufteilen. Das ist ohne Probleme über Betriebssystem-Funktionen steuerbar, benötigt aber sorgfältige Einrichtung. Es wird auch jeden Fall billiger als ein Tag Produktionsausfall.

    Hinweis für Forumsmitglied Joewol:
    Angesichts langsamer Datenzugriffe auf ihre bestehende David-Installation dürfte es sich lohnen, darauf einen vollständigen Defragmentierungslauf auszuführen. Er könnte bei 800 GB mehr als einen Tag dauern. Ausreichend Kühlung der Platten ist dabei ganz wichtig. Zeigt aber das Auslesen des Smart-Bereichs auch nur einer Platte schon Hinweise auf Verschleiß, dann sollte der Defragmentierungslauf vorsichtshalber unterbleiben.

    Die Investition in eine Server-geeignete SSD-Platte mit Auslegung für viele Schreibvorgänge erhöht die Produktivität von David-Anwendungen so sehr, dass ein Return of Investment innerhalb eines Zeitraums von weniger als zwei Jahren zu erwarten ist. Eine einzelne Server-geeignete SSD-Platte heutiger Bauart liefert mit passendem Controller die Daten weitaus schneller als jedes RAID5-System mit herkömmlichen Festplatten. Daneben braucht eine SSD-Server-Platte für die Bearbeitung der identischen Datenmenge mehr als 400-fach weniger Strom als eine herkömmliche Festplatte und dem entsprechend weniger Kühlung.

    44 Mal editiert, zuletzt von Arno (5. Dezember 2014 um 15:08)

    Ja, bei extrem vielen Dateien in einem Ordner, macht das Betriebssystem auch schnell mal dicke Backen, in diesem Falle ist es sinnvoll Unterordner anzulegen.

    Wir haben schon vor einiger Zeit "Inoxision ArchiveGate" als Archivierungslösung eingeführt, dazu habe ich ein kleines Tool geschrieben, dass über die Aufgabenverwaltung von Windows nachts gestartet wird, und alle E-Mails die, in unserem Fall, älter als 90 Tage sind, archiviert.
    Dadurch hat sich die Datenmenge auf dem David Server erheblich reduziert und das System ist schneller und stabiler. Die Mails werden übrigens als EML aus David exportiert und auch so archiviert.
    Da sich "Inoxision ArchiveGate" direkt in David integrieren lässt, können die Benutzer direkt aus David im Archiv suchen - es kostet zwar etwas mehr Zeit, aber wir müssen nicht so häufig an die älteren Mails ran und die Geschwindigkeit von David im Alltag ist wichtiger.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden