{"id":55408,"date":"2020-01-20T00:00:00","date_gmt":"2020-01-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie"},"modified":"2020-02-18T14:03:31","modified_gmt":"2020-02-18T11:03:31","slug":"effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Effektive Speicherung von Hunderten Millionen kleiner Dateien. Self-Hosted L\u00f6sung.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Effektive
\n
\nSehr geehrte Community, dieser Artikel widmet sich der effizienten Speicherung und Ausgabe von Hunderten Millionen kleiner Dateien. An dieser Stelle wird eine endg\u00fcltige L\u00f6sung f\u00fcr POSIX-kompatible Dateisysteme mit vollst\u00e4ndiger Unterst\u00fctzung f\u00fcr Sperren, einschlie\u00dflich Cluster-Sperren, und anscheinend sogar ohne Workarounds angeboten.<\/p>\n

F\u00fcr diesen Zweck habe ich meinen eigenen spezialisierten Server geschrieben.
\nW\u00e4hrend der Umsetzung dieser Aufgabe gelang es mir, das Hauptproblem zu l\u00f6sen und gleichzeitig Speicherplatz und RAM zu sparen, den unser clustergest\u00fctztes Dateisystem unbarmherzig beansprucht hat. Eine solche Menge an Dateien ist f\u00fcr jedes clustergest\u00fctzte Dateisystem sch\u00e4dlich. <\/a><\/noindex><\/p>\n

Die Idee ist folgende:<\/p>\n

Einfach gesagt: \u00dcber den Server werden kleine Dateien hochgeladen, sie werden direkt in einem Archiv gespeichert und ebenso aus diesem gelesen, w\u00e4hrend gro\u00dfe Dateien daneben abgelegt werden. Schema: 1 Ordner = 1 Archiv, somit haben wir mehrere Millionen Archive mit kleinen Dateien anstelle von mehreren Hundert Millionen Dateien. Und das alles wurde vollst\u00e4ndig umgesetzt, ohne irgendwelche Skripte und das Ablegen von Dateien in tar\/zip Archiven.<\/p>\n

Ich werde versuchen, mich kurz zu fassen, und entschuldige mich im Voraus, falls der Beitrag umfangreich wird.<\/p>\n

Alles begann damit, dass ich keinen geeigneten Server in der Welt finden konnte, der Daten, die \u00fcber das HTTP-Protokoll empfangen wurden, direkt in Archive speichern kann, ohne die M\u00e4ngel herk\u00f6mmlicher Archive und Objektspeicher zu haben. Der Grund f\u00fcr die Suche war ein stark gewachsener Origin-Cluster aus 10 Servern, der bereits 250.000.000 kleine Dateien angesammelt hatte und dessen Wachstumstendenz nicht aufh\u00f6ren wollte.<\/p>\n

F\u00fcr diejenigen, die keine Artikel lesen m\u00f6gen und kurze Dokumentationen bevorzugen:<\/b><\/p>\n

hierhin<\/a><\/noindex> und hierhin<\/a><\/noindex>.<\/p>\n

Und Docker gleichzeitig, derzeit gibt es nur die Option zusammen mit nginx, falls n\u00f6tig:<\/p>\n

docker run -d --restart=always -e host=localhost -e root=\/var\/storage \n-v \/var\/storage:\/var\/storage --name wzd -p 80:80 eltaline\/wzd<\/code><\/pre>\n
\nWeiter:<\/p>\n
Wenn es viele Dateien gibt, sind erhebliche Ressourcen erforderlich, und das Frustrierende ist, dass ein Teil davon sinnlos verloren geht. Bei der Verwendung eines verteilten Dateisystems (in diesem Fall MooseFS) ben\u00f6tigt eine Datei, unabh\u00e4ngig von ihrer tats\u00e4chlichen Gr\u00f6\u00dfe, immer mindestens 64 KB. Das bedeutet, dass f\u00fcr Dateien mit einer Gr\u00f6\u00dfe von 3, 10 oder 30 KB auf der Festplatte jeweils 64 KB ben\u00f6tigt werden. Wenn es sich um viertel Milliarden Dateien handelt, verlieren wir zwischen 2 und 10 Terabyte. Es wird nicht m\u00f6glich sein, unendlich viele neue Dateien zu erstellen, da es auch in MooseFS eine Begrenzung gibt: nicht mehr als 1 Milliarde mit einer Kopie jeder Datei.<\/p>\n
Mit steigender Anzahl an Dateien ben\u00f6tigt man viel RAM f\u00fcr Metadaten. Auch h\u00e4ufige gro\u00dfe Dumps von Metadaten tragen zum Verschlei\u00df von SSD-Laufwerken bei.<\/p>\n
Server wZD. Wir bringen Ordnung auf die Festplatten.<\/b><\/p>\n
Der Server ist in der Programmiersprache Go geschrieben. Zun\u00e4chst musste ich die Anzahl der Dateien verringern. Wie macht man das? Durch Archivierung, aber in diesem Fall ohne Kompression, da meine Dateien durchgehend komprimierte Bilder sind. Dabei kam mir BoltDB zugute, die ich zudem von M\u00e4ngeln befreien musste, was in der Dokumentation festgehalten ist.<\/p>\n
Anstatt viertel Milliarde Dateien sind in meinem Fall nur noch 10 Millionen Bolt-Archive \u00fcbrig geblieben. H\u00e4tte ich die M\u00f6glichkeit, die aktuelle Struktur der Verzeichnisse zu \u00e4ndern, k\u00f6nnte die Anzahl m\u00f6glicherweise auf etwa 1 Million Dateien reduziert werden. <\/p>\n
Alle kleinen Dateien werden in Bolt-Archive gepackt, die automatisch die Namen der Verzeichnisse annehmen, in denen sie liegen, w\u00e4hrend alle gro\u00dfen Dateien neben den Archiven verbleiben, da es keinen Sinn macht, sie zu verpacken. Kleinere \u2014 archivieren wir, gro\u00dfe \u2014 lassen wir unver\u00e4ndert. Der Server arbeitet transparent mit beiden.<\/p>\n
Architektur und Besonderheiten des Servers wZD.<\/b><\/p>\n
\"Effektive
\n
\nDer Server l\u00e4uft unter den Betriebssystemen Linux, BSD, Solaris und OSX. Ich habe nur f\u00fcr die AMD64-Architektur unter Linux getestet, aber er sollte auch f\u00fcr ARM64, PPC64, MIPS64 geeignet sein.<\/p>\n
Hauptmerkmale:<\/b><\/p>\n