Ich habe eine dateibasierte Datenbank mit etwa 2 Millionen Dateien, die in drei Ebenen von Unterverzeichnissen gespeichert sind.
2/2/6253
2/2/6252
...
Dateigröße variiert zwischen 30 Byte und 60 KB. Die gesamte Datenbank ist schreibgeschützt. Die Datenbank ist etwa 125 Gigabyte groß.
Hinzugefügt:Alle Dateien werden mit zlib (Python) komprimiert.
Ich möchte alles als eine Datei mit darin enthaltenem Dateisystem behandeln. Welches Dateisystem wäre für mich die beste Wahl?
Im Moment verwende ich folgendes Skript:
dd if=/dev/zero of=/my_file.iso bs=1024K count=60000
mkfs.ext4 -f /my_file.iso
mount -o loop /my_file.iso /mnt/
Antwort1
Sie möchten wahrscheinlich nur XFS verwenden.
Es ist durchaus in der Lage, Ihren Anforderungen gerecht zu werden und erledigt die Arbeit.
Es gibt keinen Grund, dies mit weniger genutzten Dateisystemen zu verkomplizieren, was mit anderen Kompromissen verbunden sein kann.
Bitte beachten Sie:Welchen Einfluss hat die Anzahl der Unterverzeichnisse auf die Lese-/Schreibleistung des Laufwerks unter Linux? UndDie Auswirkungen eines hohen Verzeichnis-zu-Datei-Verhältnisses auf XFS
Wenn Sie etwas Esoterischeres möchten, könnten ZFS-Zvols mit einem darüber liegenden Dateisystem eine interessante Alternative darstellen (für Komprimierung, Integrität und Portabilität).
Siehe hier:Transparentes Komprimierungsdateisystem in Verbindung mit ext4
Antwort2
Angesichts der Anzahl der kleinen Dateien würde ich die Verwendung von SquashFS in Betracht ziehen. Insbesondere, wenn Sie über eine ausreichend leistungsstarke CPU verfügen (also keinen Pentium III oder 1-GHz-ARM).
Abhängig von der Art der gespeicherten Daten kann SquashFS die Größe und damit die E/A beim Lesen erheblich reduzieren. Der einzige Nachteil ist die CPU-Auslastung beim Lesen. Andererseits kann jede moderne CPU bei Geschwindigkeiten dekomprimieren, die die von Festplatten und wahrscheinlich sogar SSDs bei weitem übertreffen.
Ein weiterer Vorteil: Sie sparen Speicherplatz/Bandbreite und/oder Zeit für die Dekomprimierung nach der Übertragung.
Einige BenchmarksVergleichen Sie es mit ISO und anderen ähnlichen Mitteln. Wie bei jedem Benchmark sollten Sie es mit Vorsicht genießen und besser noch Ihren eigenen Benchmark fälschen. ;-)
Edit: Je nach Umständen (und ich wage hier nicht zu raten) mksquashfs -noDkönnte SquashFS ohne Komprimierung ( ) ext4 übertreffen, da der Code zum Lesen viel einfacher und für den Nur-Lese-Betrieb optimiert sein sollte. Aber das müssen Sie wirklich in Ihrem Anwendungsfall vergleichen. Ein weiterer Vorteil ist, dass das SquashFS-Image nur ein wenig größer ist als Ihre Daten. Mit Ext4 müssen Sie immer ein größeres Loop-Gerät erstellen. Der Nachteil ist natürlich, dass es ziemlich unbequem ist, wenn Sie die Daten ändern müssen. Das ist mit ext4 viel einfacher.
Antwort3
Wenn die Datei schreibgeschützt ist, warum verwenden Sie dann keine ISO-Datei? Sie können genisoimageoder verwenden mkisofs.
Wenn Sie das Ganze komprimieren möchten, können Sie auch verwenden squashfs, ein anderes schreibgeschütztes Dateisystem mit sehr hoher Komprimierungsrate.
Antwort4
Ich bin nicht sicher, ob das Ihren Zweck erfüllt, aber haben Sie schon einmal daran gedacht, tarmehrere Dateien zu kombinieren? Das könnte den Druck und den Platzbedarf des Dateisystems verringern, und Ihre Datenbankanwendung kann Daten für eine bestimmte Datei mit einer der vielen tarverfügbaren Bibliotheken lesen.
Abhängig von Ihrem Zugriffsmuster kann dies sogar die Leistung steigern.