{"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 alla memorizzazione e distribuzione efficace di centinaia di milioni di piccoli file. In questa fase, viene proposta una soluzione finale per i sistemi di file compatibili con POSIX, con supporto completo per il blocco, incluso quello cluster, e sembra che anche senza soluzioni temporanee.<\/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 nel contempo ottenere un risparmio di spazio su disco e di memoria, che la nostra infrastruttura di file cluster consumava. In effetti, una tale quantit\u00e0 di file \u00e8 dannosa per qualsiasi sistema di file cluster. <\/a><\/noindex><\/p>\n

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

In parole semplici, attraverso il server vengono caricati piccoli file, che vengono salvati direttamente in un archivio e letti allo stesso modo, mentre i file grandi vengono posizionati accanto. Schema: 1 cartella = 1 archivio, il che significa che abbiamo diversi milioni di archivi con piccoli file, invece di diverse centinaia di milioni di file. E tutto ci\u00f2 \u00e8 realizzato in modo completo, senza alcun script o distribuzione di file in archivi tar\/zip.<\/p>\n

Cercher\u00f2 di esprimermi in modo pi\u00f9 conciso, mi scuso in anticipo se il post sar\u00e0 denso.<\/p>\n

Tutto \u00e8 iniziato perch\u00e9 non riuscivo a trovare un server adatto nel mondo che potesse salvare i dati ricevuti tramite il protocollo HTTP direttamente negli archivi, evitando gli svantaggi tipici degli archivi comuni e degli oggetti di memorizzazione. La ragione della mia ricerca \u00e8 stata un cluster Origin di 10 server cresciuto enormemente, in cui si erano accumulati gi\u00e0 250.000.000 piccoli file, e la tendenza alla crescita non accennava a fermarsi.<\/p>\n

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

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

E anche con Docker, al momento c'\u00e8 un'opzione solo insieme a nginx per sicurezza:<\/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
\nSuccessivamente:<\/p>\n
Se ci sono molti file, sono necessarie risorse significative, e la cosa pi\u00f9 frustrante \u00e8 che parte di esse va sprecata. Ad esempio, nell'utilizzare un file system a cluster (in questo caso, MooseFS) un file, indipendentemente dalla dimensione reale, occupa sempre almeno 64 KB. Ci\u00f2 significa che per file delle dimensioni di 3, 10 o 30 KB su disco servono 64 KB. Se ci sono un quarto di miliardo di file, perdiamo da 2 a 10 terabyte. Non \u00e8 possibile creare nuovi file all'infinito, poich\u00e9 anche in MooseFS c'\u00e8 un limite: non pi\u00f9 di 1 miliardo con una replica di ciascun file.<\/p>\n
Con l'aumentare del numero di file, \u00e8 necessaria molta memoria RAM per i metadati. Inoltre, i grandi dump di metadati frequenti contribuiscono all'usura degli SSD.<\/p>\n
Server wZD. Mettiamo ordine nei dischi.<\/b><\/p>\n
Il server \u00e8 scritto in linguaggio 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. A soccorrere \u00e8 arrivato BoltDB, a cui ho dovuto rimuovere alcune carenze, come indicato nella documentazione.<\/p>\n
In totale, invece di un quarto di miliardo di file, nel mio caso sono rimasti solo 10 milioni di archivi Bolt. Se avessi potuto cambiare la struttura attuale di riempimento delle directory con i file, sarebbe stato possibile ridurre a circa 1 milione di file. <\/p>\n
Tutti i file piccoli vengono impacchettati in archivi Bolt, che ricevono automaticamente i nomi delle directory in cui si trovano, mentre tutti i file di grandi dimensioni rimangono accanto agli archivi, non ha senso impacchettarli, \u00e8 configurabile. Piccoli \u2014 archiviati, grandi \u2014 lasciati invariati. Il server funziona in modo trasparente con entrambi.<\/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