{"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 wird sich mit der effektiven Speicherung und Abgabe von Hunderten Millionen kleiner Dateien befassen. Auf dieser Stufe wird eine endg\u00fcltige L\u00f6sung f\u00fcr POSIX-kompatible Dateisysteme mit vollst\u00e4ndiger Unterst\u00fctzung f\u00fcr Sperren, einschlie\u00dflich Cluster-Sperren, angeboten, und anscheinend sogar schon ohne Workarounds.<\/p>\n

Deshalb habe ich einen eigenen spezialisierten Server geschrieben.
\nIm Verlauf der Umsetzung dieser Aufgabe gelang es, das Hauptproblem zu l\u00f6sen und gleichzeitig den Speicherplatz und den Arbeitsspeicher zu sparen, den unser Cluster-Dateisystem gnadenlos beanspruchte. Tats\u00e4chlich ist eine solche Anzahl von Dateien sch\u00e4dlich f\u00fcr jedes Cluster-Dateisystem. <\/a><\/noindex><\/p>\n

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

Einfach gesagt, \u00fcber den Server werden kleine Dateien hochgeladen, sie werden direkt im Archiv gespeichert und ebenso aus diesem gelesen, w\u00e4hrend gr\u00f6\u00dfere Dateien daneben abgelegt werden. Schema: 1 Ordner = 1 Archiv, insgesamt haben wir mehrere Millionen Archive mit kleinen Dateien, anstatt mehrere Hundert Millionen Dateien. Und all dies wurde vollumf\u00e4nglich umgesetzt, ohne irgendwelche Skripte und ohne die Dateien in tar\/zip-Archive zu stapeln.<\/p>\n

Ich werde versuchen, mich k\u00fcrzer zu fassen und entschuldige mich im Voraus, wenn der Beitrag langatmig wird.<\/p>\n

Alles begann damit, dass ich keinen geeigneten Server auf der Welt finden konnte, der Daten, die \u00fcber das HTTP-Protokoll empfangen wurden, direkt in Archive speichern konnte, ohne die Nachteile, die herk\u00f6mmlichen Archiven und Objektspeichern eigen sind. Der Grund f\u00fcr die Suche war ein auf gro\u00dfe Ma\u00dfst\u00e4be angewachsener Origin-Cluster von 10 Servern, in dem bereits 250.000.000 kleine Dateien angesammelt waren, und die Wachstumsrate wollte nicht aufh\u00f6ren.<\/p>\n

F\u00fcr diejenigen, die keine Artikel m\u00f6gen, hier eine kurze Dokumentation:<\/b><\/p>\n

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

Und Docker gleich mit, momentan gibt es nur die Option zusammen mit Nginx drin, f\u00fcr alle F\u00e4lle:<\/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 sehr viele Dateien gibt, sind erhebliche Ressourcen erforderlich, wobei das Frustrierendste ist, dass ein Teil davon umsonst verloren geht. Zum Beispiel ben\u00f6tigt ein Cluster-Dateisystem (in diesem Fall \u2013 MooseFS) f\u00fcr 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 erforderlich sind. Wenn es viertel Milliarde Dateien gibt, verlieren wir zwischen 2 und 10 Terabyte. Unendlich viele neue Dateien zu erstellen, wird nicht m\u00f6glich sein, da es in MooseFS eine Einschr\u00e4nkung gibt: nicht mehr als 1 Milliarde bei einer Replik jeder Datei.<\/p>\n
Mit zunehmender Anzahl von Dateien wird viel RAM f\u00fcr die Metadaten ben\u00f6tigt. Auch h\u00e4ufige gro\u00dfe Dumps der Metadaten f\u00f6rdern den Verschlei\u00df von SSD-Speichern.<\/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 reduzieren. Wie kann ich das erreichen? Durch Archivierung, aber in diesem Fall ohne Kompression, da meine Dateien durchweg komprimierte Bilder sind. BoltDB war eine hilfreiche L\u00f6sung, die ich zudem von ihren Nachteilen befreien musste, was in der Dokumentation festgehalten ist.<\/p>\n
Insgesamt sind anstelle von viertel Milliarde Dateien in meinem Fall nur noch 10 Millionen Bolt-Archive \u00fcbrig geblieben. Wenn ich die aktuelle Struktur der Verzeichnisse, die mit Dateien gef\u00fcllt sind, \u00e4ndern k\u00f6nnte, w\u00e4re es m\u00f6glicherweise m\u00f6glich, die Anzahl auf etwa 1 Million Dateien zu reduzieren. <\/p>\n
Alle kleinen Dateien werden in Bolt-Archive verpackt, die automatisch die Namen der Verzeichnisse erhalten, in denen sie sich befinden, w\u00e4hrend alle gro\u00dfen Dateien neben den Archiven bleiben; es macht keinen Sinn, sie zu verpacken, dies ist konfigurierbar. Kleine \u2014 archivieren wir, gro\u00dfe \u2014 lassen wir unver\u00e4ndert. Der Server funktioniert sowohl mit den einen als auch mit den anderen transparent.<\/p>\n
Architektur und Besonderheiten des Servers wZD.<\/b><\/p>\n
\"Effektive
\n
\nDer Server funktioniert unter den Betriebssystemen Linux, BSD, Solaris und OSX. Ich habe ihn 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