Komprimieren Sie den Zugriff auf 10 Millionen Dateien und stellen Sie den Zugriff auf einzelne Dateien bereit

424
Denis Kulagin

Ich habe ~ 10 Millionen kleine Textdateien und möchte folgende Aufgaben lösen:

  • komprimieren Sie alle Daten;
  • Legen Sie alles in eine Datei, die Sie über das Internet übertragen können.
  • in der Lage sein, auf jede einzelne Datei sehr schnell zuzugreifen;
  • (Aktualisieren) einzelner Dateien, damit sie vom Python-Ökosystem aus leicht zugänglich sind.

Ich habe folgende Lösung gefunden:

  • gzip jede Datei (Komprimierung);

  • Fügen Sie alle gezippten Dateien einem einzelnen Archiv hinzu:

    single.tar -> /1/100/1001451.gz ... -> /9/956/9562548.gz

Löst es meine Aufgaben?

0
Wenn Ihre eigentliche Frage lautet "löst meine Idee meine Aufgabe?", Scheint es, als wären Sie am besten in der Lage, das zu beantworten. Probieren Sie es einfach aus und sehen Sie, dann sagen Sie es uns. Wenn es sich bei Ihrer Frage um etwas anderes handelt, geben Sie dies bitte ausdrücklich an. Es ist für die Site zu offen, diese Kommentare nur für Kommentare zu werfen. fixer1234 vor 5 Jahren 1

1 Antwort auf die Frage

4
Eugen Rieck

Ich denke, es könnte eine bessere Möglichkeit, dies zu lösen: tar, zip, rarusw. haben alle die Eigenschaft (zu einem diferent Grad), dass der Zugang zu einer einzigen Datei

  • nicht sehr schnell
  • nicht transparent: Sie können es nicht direkt anzeigen, müssen es jedoch an anderer Stelle dekomprimieren und dann anzeigen

Es gibt jedoch eine Alternative: Verwenden Sie eine komprimierte Image-Datei mit einem Dateisystem (z. B. cloopext4) oder eine einfache Image-Datei mit einem komprimierten Dateisystem (z. B. squashfs) - normalerweise verwende ich das letztere.

Auf diese Weise können Sie Ihre Datei über das Internet verschieben und auf dem Zielsystem direkt anhängen und schnell und transparent auf die darin enthaltenen Dateien zugreifen.

BEARBEITEN

Zur Aktualisierung von Dateien: Ich hatte das gleiche Problem und habe es mit mksquashfsund gelöst overlayfs. Geänderte Dateien werden in das Overlay eingefügt, die Originale verbleiben in der unveränderten Transportdatei (ich halte dies für eine wichtige Funktion)

Ich würde behaupten, dass Dateisysteme und Archivformate hier fast genauso funktionieren und dieselben allgemeinen Eigenschaften aufweisen, die sich nur in der Effizienz einer Pfadsuche unterscheiden. (Sehr effektiv in Formaten wie Ext4, akzeptabel in Formaten wie Zip, die einen zentralen linearen Index haben, schlecht in Tar, der überhaupt keinen Index hat.) Insbesondere wenn es um Write-Once-Formate wie Squashfs geht, scheinen sie sich nur in zufälliger Reihenfolge zu unterscheiden Zugriff _innerhalb einer Datei (Zip erfordert das Dekomprimieren der gesamten Datei, Squashfs ermöglicht das Dekomprimieren einzelner Blöcke), ist jedoch fast gleich, wenn eine ganze Datei auf einmal extrahiert wird. grawity vor 5 Jahren 0
squashfs ist immer schneller, da es sich im Kernelspace befindet, während zip im Benutzerbereich ist. und Sie müssen die unzip-Binärdatei bei jedem Zugriff selbst aufrufen, was viel mehr Aufwand bedeutet als eine einfache offene Funktion. Ipor Sircer vor 5 Jahren 0
@IporSircer: Kernelspace beschleunigt nicht automatisch. Es läuft auf der gleichen CPU mit der gleichen Geschwindigkeit. Was die Sache schneller macht, ist ein gut durchdachtes Format / Struktur (Squashfs ist in der Tat viel optimierter), das Zwischenspeichern der Metadaten und - wie Sie bereits erwähnt haben - die Notwendigkeit, einen neuen Prozess zu starten und das Archiv jedes Mal erneut zu lesen, ... Dies ist unter der Annahme, dass das Laichen von "entpacken" die einzige andere Option ist. Das ist nicht der Fall: Viele Programmiersprachen verfügen über eine integrierte Unterstützung für das Zip-Format (seltener Rar und 7z). grawity vor 5 Jahren 0
Nette Lösung, aber nicht sehr freundlich für das nicht-technische Publikum, das nur mit Python vertraut ist. Die Frage wurde jedoch aktualisiert. Denis Kulagin vor 5 Jahren 1
@ grawity: Sie haben viele von gcc eingearbeitete Sicherheitsfunktionen vergessen, z. B. Stack Protector, Pie; plus Heutzutage Specter / Meltdown Workarounds, die nur die Userpace-Programme verlangsamen. Also ist der exakt gleiche Algorithmus im Kernelspace in Wirklichkeit noch schneller. Ipor Sircer vor 5 Jahren 0
@DenisKulagin: Mounten Sie die Squashfs in einem Ordner, und der unerfahrene Benutzer merkt keinen Unterschied, wenn Sie eine lokale Datei direkt öffnen. Ipor Sircer vor 5 Jahren 2
@DenisKulagin Das Schöne an einem Dateisystem als Abstraktionsebene ist, wenn Sie eine solche mounten, deren Dateien für * jedes * Ökosystem / Programm / alles verfügbar sind, das mit Dateien umgehen kann. Sehr unix-y Ansatz. Kamil Maciorowski vor 5 Jahren 0
@IporSircer: Der Kernel meiner Distribution scheint auch mit STACKPROTECTOR_STRONG kompiliert zu sein. Problemumgehungen bei der Kernschmelze verlangsamen den Kontextwechsel des Kernel-Bereichs, und sowohl der gesamte Kernelspace- als auch der gesamte Benutzerraum-Code bleiben gleichermaßen davon unberührt. Specter-Minderungen werden auf Kernel-Code angewendet. grawity vor 5 Jahren 0
Um es noch einmal zu sagen: Die Geschwindigkeit des Zugriffs auf eine einzelne Datei hängt vom verwendeten Format ab - `tar` ist sehr langsam, andere sind viel schneller. Keines ist so schnell wie ein Dateisystem. Aber das ist der kleinere Punkt: Was mir wichtiger ist, ist die Transparenz: Montieren Sie die FS, und jedes Werkzeug, das Sie benötigen, kann direkt darauf zugreifen, ohne zu bemerken, dass es aus einer Transportdatei stammt. Eugen Rieck vor 5 Jahren 3
Benutzerfreundlich: `mksquashfs` ist nicht komplizierter als` tar '. Wenn Ihre Benutzer es nicht beherrschen, packen Sie es einfach in ein Shellskript und automatisieren den Prozess vollständig. Eugen Rieck vor 5 Jahren 1
In Bezug auf die Benutzerfreundlichkeit: Das sagt nicht viel aus, da "Teer" häufig der Scheitel vieler "arkaner Unix-Tools" ist. Ich stimme der allgemeinen Idee zu, das Archiv als Dateisystem mounten zu können ([siehe auch] (https://github.com/tmbdev/archivefs)), aber es scheint nicht, dass OP Linux tatsächlich als das erwähnt hat Ziel OS ... grawity vor 5 Jahren 0
@ grawity Da die erste Idee des OP "tar" war, erschien es logisch, in Linux zu denken. Und `unsquashfs` für Windows funktioniert ziemlich gut. Eugen Rieck vor 5 Jahren 1

Verwandte Probleme