Ankündigung

Einklappen
Keine Ankündigung bisher.

Dateisystem: Physikalisch oder Virtuell?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Dateisystem: Physikalisch oder Virtuell?

    Hallo,

    ich habe vor ein Dateiverwaltungssystem zu bauen. Jetzt habe ich aber grundsätzlich einmal die Frage: physikalisch oder virtuell?

    Die physikalische Variante stelle ich mir so vor, dass jeder Benutzer einen eigenen Unterordner (evtl. mit userid als Namen) bekommt und dort dann via PHP Ordner anlegen kann und Dateien uploaden kann. Nur halt "wirkliche" physikalische Ordner.

    Die virtuelle Variante stelle ich mir dann so vor, dass auch jeder Benutzer einen eigenen Unterordner bekommen und in diesen Unterordner dann seine Dateien hochladen kann. Eine Orderstruktur wird dann via mySQL in einem Nested Sets Model realisiert.

    Ich denke mir mal, dass es für beide Varianten Vor- und Nachteile gibt.

    Einige zähle ich jetzt mal auf:

    Physikalische Methode:

    + keine Probleme, wenn es einen Datenbankfehler gibt
    + Im System kann der selbe Dateiname mehrfach vorkommen
    + leichtere Administration
    - langsame Suche?
    - nur begrenzter Zugriff auf META Daten (nur Änderungsdatum, Typ, etc.)

    Virtuelle Methode:

    + schnelle Suche durch mySQL
    + META Daten in mySQL (Möglichkeit für Rechtebestimmung etc., u.a. für einen öffentlichen Ordner)
    + keine elend langen Links für Dateien
    - Jeder Dateiname darf nur einmal vorkommen, da alle Dateien in einem Ordner sind
    - Fehler bei Datenbankcrash


    So nun weiß ich nicht, inwiefern meine Vor- und Nachteile zutreffen, aber was denkt ihr? Was würdet ihr bevorzugen?


    mfg
    Link

  • #2
    Die virtuelle Variante stelle ich mir dann so vor, dass auch jeder Benutzer einen eigenen Unterordner bekommen und in diesen Unterordner dann seine Dateien hochladen kann. Eine Orderstruktur wird dann via mySQL in einem Nested Sets Model realisiert.
    Ich hoffe doch mal, du legst die Dateien dann trotzdem physikalisch ab. Dateien in einer Datenbank is etwas kontraproduktiv

    Vielleicht auch einfach etwas eng gedacht, physikalische Dateien können doch auch zusätzliche Infos in einer Datenbank bekommen. Insofern fällt der Vor-/Nachteil "Meta-Daten" weg. Ebenso könnteste für die "virtuellen Dateien" Alias vergeben, die dann per Redirect-Script auf die "elend langen Dateinamen" zeigen, oder sogar ein Script, was die Datei unter falscher Flagge "durchschleift". Nebenbei: Nen Datenbankcrash sollte man nicht erhoffen Backup!

    Kommentar


    • #3
      Ja, die Dateien werden natürlich physikalisch abgelegt. Allerdings alle im selben Ordner und nicht in mehreren.

      mfg
      Link

      Kommentar


      • #4
        Hallo,
        ein virtuelles Dateisystem ist schwieriger umzusetzen, dafür aber flexibler und schneller (da du ja zum Beispiel beim Verschieben und Löschen nicht wirklich Dateien verschiebst oder löscht, sondern nur ihren Eintrag in der DB - die Arbeiten die wirklich Arbeit machen, kann ein Cronjob erledigen).

        Dafür ist ein physikalisches Dateisystem natürlich sehr portabel, du musst vermutlich nur einen Basispfad angeben, die passenden Rechte haben und kannst loslegen. Ich halte allerdings nichts davon, dass ein User das Serverdateisystem bearbeiten kann, wenn auch nur in seiner kleinen Spielwiese.

        Ich würde mir für das virtuelle Dateisystem mod_rewrite aktivieren, innoDB verwenden (löscht du einen Ordner, kannst du durch die implementierte Abhängigkeit auch gleich automatisch alle Dateien darin löschen lassen - "Ordner" und "Dateien" natürlich im Sinne von Datenbankeinträgen). Ein rename oder move führt keine Dateioperation mehr aus, sondern ein UPDATE auf die Datenbank. Du kannst Transaktionen einführen, du kannst sogar alte Dateisystem mit wenigen Klicks wiederherstellen, wenn du eine intelligente History einbaust.

        Sagen wirs so, du kannst eigentlich bei beidem alles machen, warum sollte eine History nicht auch für ein physikalisches Dateisystem möglich sein. Allerdings brauchst du je größer die Featurelist wird irgendwann dafür auch eine DB und dann stellt sich die Frage, warum benutz ich dann überhaupt noch ein physikalisches Dateisystem.

        Auf jeden Fall sollten die Dateien auch wirklich als Datei auf der Festplatte bleiben und nicht in ein Datenbank-BLOB-Feld gesteckt werden. Mit mod_rewrite und einer Datenbank, kannst du ja ganz einfach verschleiern, wo die Datei wirklich liegt.

        Ich würde es also so machen, wie dr.e. auch vor einiger Zeit anmahnte um zu Verhindern, dass zuviele Dateien in einem Ordner liegen:
        Erstell dir zur Installation/Initiierung deines Skriptes 255 Ordner. Klingt erstmal viel, wenn die ersten Tage nur 5 User mitmachen und jeweils nur 3 Dateien hochladen. Aber damit steht das Grundgerüst, und es sind vorerst keine weiteren Pfadoperationen nötig.
        255 und zwar in Hexform. Du weißt ja, das Alphabet der Hexwerte ist 0-9 und A-F, als Basis haben wir also 16 und nicht 10 wie beim Dezimalsystem. Erstell jetzt also 255 Ordner, von 00, 01, .. FE, FF. Eigentlich ganz einfach zu automatisieren:
        PHP-Code:
        <?php
        foreach (range(0255) as $i) {
          
        $leadingzero substr("0$i", -2); // macht aus 1 ein 01 etc.
          
        mkdir("$basispfad/$leadingzero");
        }
        ?>
        So und über hochgeladene Dateien läßt du nun ein md5_file() laufen, Rückgabewert ist ein 32-Byte Hexcode, dessen zwei erste Buchstaben sagen dir, in welchen Ordner du die Datei verschiebst (tatsächlich).
        Jetzt legst du in der Datenbank den Eintrag "md5_file | filename | owner | .." an.
        Sollte nun jemand noch einmal eine Datei hochladen mit dem selben MD5-Hash, brauchst du die Datei nicht doppelt abzulegen, du legst einfach nur einen neuen Eintrag in der DB an.
        Möchte nun jemand die Datei bearbeiten oder eine neue Version hochladen, so behandelst du diese wie eine komplett eigenständige neue Datei. So kannst du a) versionieren und b) möglicherweise enormen Speicherplatz sparen, wenn oft die selbe Datei hochgeladen wird (was zugegebenermaßen selten passieren sollte).
        Möchte jemand die Datei löschen, wird sie nur in der Datenbank gelöscht.

        Jede Nacht kannst du dann einen Cronjob drüberlaufen lassen, der prüft ob die Dateien die es physikalisch gibt auch noch in der DB als vermerkt gibt. Wenn nicht kannst du die Datei dann auch physikalisch löschen.

        Nur so als Gedankenanstoss. Hätte grad Bock das selbst alles zu machen.

        Kommentar


        • #5
          Stimmt, in deinem Post sind ein paar sehr nette Anregungen drin, an die ich vorher nicht gedacht hatte. Vor allem eine History Funktion wäre sehr geil. Ich glaube du hast mich überzeugt Bin dann mal in die Tiefen des virtuellen Dateisystems untertauchen (mit brauner Gesichtsbemalung *insider*)

          mfg
          Link

          Kommentar

          Lädt...
          X