{"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\/it\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Archiviazione efficace di centinaia di milioni di piccoli file. Soluzione Self-Hosted","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Archiviazione
\n
\nGentile comunit\u00e0, questo articolo sar\u00e0 dedicato all'archiviazione e distribuzione efficiente di centinaia di milioni di piccoli file. In questa fase, viene proposto una soluzione finale per i file system compatibili con POSIX, con pieno supporto per il locking, inclusi quelli cluster, e sembra anche senza workaround.<\/p>\n

Pertanto, per questo scopo, ho scritto il mio server specializzato.
\nDurante l'implementazione di questo compito, sono riuscito a risolvere il problema principale e, contemporaneamente, a ottenere un risparmio di spazio su disco e memoria RAM, che la nostra file system cluster consumava in modo implacabile. Infatti, un numero cos\u00ec elevato di file \u00e8 dannoso per qualsiasi file system cluster. <\/a><\/noindex><\/p>\n

L'idea \u00e8 questa:<\/p>\n

In parole semplici, i piccoli file vengono caricati tramite il server, vengono salvati direttamente in un archivio e letti da esso, mentre i file pi\u00f9 grandi vengono collocati a fianco. Schema: 1 cartella = 1 archivio, quindi abbiamo diversi milioni di archivi con piccoli file, e non solo centinaia di milioni di file. E tutto questo \u00e8 realizzato in modo completo, senza script e senza distribuire file in archivi tar\/zip.<\/p>\n

Cercher\u00f2 di essere conciso, mi scuso in anticipo se il post risulter\u00e0 denso.<\/p>\n

Tutto \u00e8 iniziato quando non sono riuscito a trovare un server adatto nel mondo, capace di memorizzare i dati ricevuti tramite il protocollo HTTP direttamente in archivi, evitando i difetti associati ai tradizionali archivi e ai sistemi di storage oggettuali. La causa di questa ricerca \u00e8 stato un cluster Origin, cresciuto a dimensioni notevoli, composto da 10 server e che aveva accumulato gi\u00e0 250.000.000 di piccoli file, con una tendenza alla crescita che non accennava a fermarsi.<\/p>\n

Per chi non ama leggere articoli e troverebbe pi\u00f9 semplice una breve documentazione:<\/b><\/p>\n

qui<\/a><\/noindex> e qui<\/a><\/noindex>.<\/p>\n

E docker insieme, al momento \u00e8 disponibile solo con nginx all'interno, per ogni evenienza:<\/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
\nAvanti:<\/p>\n
Se i file sono molto numerosi, sono necessarie risorse significative e, il pi\u00f9 frustrante, parte di esse si perde inutilmente. Ad esempio, utilizzando un file system cluster (nel caso specifico, MooseFS), un file, indipendentemente dalle dimensioni effettive, occupa sempre almeno 64 KB. Quindi per file delle dimensioni di 3, 10 o 30 KB, sul disco \u00e8 necessario allocare 64 KB. Se ci sono 250 milioni di file, perdiamo da 2 a 10 terabyte. Creare nuovi file all'infinito non sar\u00e0 possibile, poich\u00e9 in MooseFS c'\u00e8 un limite: non pi\u00f9 di 1 miliardo per ogni replica di ciascun file.<\/p>\n
Man mano che il numero di file aumenta, \u00e8 necessaria molta memoria RAM per i metadati. Inoltre, frequenti grandi dump di metadati contribuiscono all'usura degli SSD.<\/p>\n
Server wZD. Facciamo ordine nei dischi.<\/b><\/p>\n
Il server \u00e8 scritto in Go. Prima di tutto, dovevo ridurre il numero di file. Come farlo? Attraverso l'archiviazione, ma in questo caso senza compressione, poich\u00e9 i miei file sono immagini compresse. In aiuto \u00e8 venuto BoltDB, che ho dovuto anche ottimizzare, come indicato nella documentazione.<\/p>\n
Invece di un quarto di miliardo di file, nel mio caso sono rimasti solo 10 milioni di archivi Bolt. Se avessi la possibilit\u00e0 di modificare l'attuale struttura di riempimento delle directory con i file, si potrebbe ridurre fino a circa 1 milione di file. <\/p>\n
Tutti i file di piccole dimensioni vengono impacchettati in archivi Bolt, ricevendo automaticamente i nomi delle directory in cui si trovano, mentre i file di grandi dimensioni rimangono accanto agli archivi, non ha senso impacchettarli, questo \u00e8 configurabile. I piccoli file vengono archiviati, i grandi restano invariati. Il server funziona in modo trasparente sia con l'uno che con l'altro.<\/p>\n
Architettura e caratteristiche del server wZD.<\/b><\/p>\n
\"Archiviazione
\n
\nIl server funziona sotto i sistemi operativi Linux, BSD, Solaris e OSX. Ho testato solo per l'architettura AMD64 su Linux, ma dovrebbe funzionare anche per ARM64, PPC64, MIPS64.<\/p>\n
Caratteristiche principali:<\/b><\/p>\n