Milioni di (piccoli) file di testo in una cartella

Vorremmo archiviare milioni di file di testo in un filesystem Linux, con lo scopo di essere in grado di comprimere e servire una raccolta arbitraria come servizio. Abbiamo provato altre soluzioni, come un database chiave / valore, ma i nostri requisiti di concorrenza e parallelismo rendono l'utilizzo del filesystem nativo la scelta migliore.

Il modo più semplice è archiviare tutti i file in una cartella:

$ ls text_files/
1.txt
2.txt
3.txt

che dovrebbe essere possibile su un file system EXT4 , che non ha limiti al numero di file in una cartella.

I due processi FS saranno:

1. Scrivi file di testo dal web scrape (non dovrebbe essere influenzato dal numero di file nella cartella).
2. Comprimi i file selezionati, forniti da un elenco di nomi di file.

La mia domanda è: l'archiviazione di un massimo di dieci milioni di file in una cartella influirà sulle prestazioni delle operazioni di cui sopra o sulle prestazioni generali del sistema, diversamente dalla creazione di un albero di sottocartelle in cui i file devono vivere?

Il lscomando, o anche il completamento TAB o l'espansione jolly da parte della shell, presenteranno normalmente i loro risultati in ordine alfanumerico. Ciò richiede la lettura dell'intero elenco di directory e l'ordinamento. Con dieci milioni di file in una singola directory, questa operazione di ordinamento richiederà un tempo non trascurabile.

Se riesci a resistere all'impulso del completamento di TAB e ad esempio scrivi i nomi dei file da comprimere per intero, non dovrebbero esserci problemi.

Un altro problema con i caratteri jolly potrebbe essere l'espansione dei caratteri jolly che probabilmente produce più nomi di file di quelli che si adattano a una riga di comando di lunghezza massima. La lunghezza massima tipica della riga di comando sarà più che adeguata per la maggior parte delle situazioni, ma quando parliamo di milioni di file in una singola directory, questo non è più un presupposto sicuro. Quando viene superata una lunghezza massima della riga di comando nell'espansione dei caratteri jolly, la maggior parte delle shell fallisce semplicemente l'intera riga di comando senza eseguirla.

Questo può essere risolto eseguendo le operazioni con i caratteri jolly utilizzando il findcomando:

find <directory> -name '<wildcard expression>' -exec <command> {} \+

o una sintassi simile quando possibile. Il find ... -exec ... \+prenderà automaticamente in considerazione la lunghezza della linea di comando massima, ed eseguirà il comando come numero di volte necessario durante il montaggio la quantità massima di nomi di file per ogni linea di comando.

Questo è pericolosamente vicino a una domanda / risposta basata sull'opinione ma cercherò di fornire alcuni fatti con le mie opinioni.

1. Se si dispone di un numero molto elevato di file in una cartella, qualsiasi operazione basata su shell che tenti di enumerarli (ad es. mv * /somewhere/else) Potrebbe non riuscire a espandere correttamente il carattere jolly oppure il risultato potrebbe essere troppo grande da utilizzare.
2. ls richiederà più tempo per enumerare un numero molto elevato di file rispetto a un numero ridotto di file.
3. Il filesystem sarà in grado di gestire milioni di file in una singola directory, ma le persone probabilmente avranno difficoltà.

Una raccomandazione è quella di dividere il nome del file in blocchi di due, tre o quattro caratteri e usarli come sottodirectory. Ad esempio, somefilename.txtpotrebbe essere memorizzato come som/efi/somefilename.txt. Se stai usando nomi numerici, dividi da destra a sinistra anziché da sinistra a destra in modo che ci sia una distribuzione più uniforme. Ad esempio, 12345.txtpotrebbe essere memorizzato come 345/12/12345.txt.

È possibile utilizzare l'equivalente di zip -j zipfile.zip path1/file1 path2/file2 ...per evitare di includere i percorsi della sottodirectory intermedia nel file ZIP.

Se stai servendo questi file da un server web (non sono del tutto sicuro che sia pertinente) è banale nascondere questa struttura a favore di una directory virtuale con regole di riscrittura in Apache2. Suppongo che lo stesso sia vero per Nginx.

Gestisco un sito Web che gestisce un database per film, TV e videogiochi. Per ognuna di queste sono presenti più immagini con TV contenenti dozzine di immagini per spettacolo (ad esempio istantanee di episodi ecc.).

Ci sono molti file di immagini. Da qualche parte nella gamma di oltre 250.000. Questi sono tutti memorizzati in un dispositivo di archiviazione a blocchi montato in cui il tempo di accesso è ragionevole.

Il mio primo tentativo di memorizzare le immagini è stato in una singola cartella come /mnt/images/UUID.jpg

Ho incontrato le seguenti sfide.

• lstramite un terminale remoto si bloccherebbe e basta. Il processo sarebbe andato zombie eCTRL+C non lo spezzerebbe.
• prima di raggiungere quel punto qualsiasi lscomando riempirebbe rapidamente il buffer di output eCTRL+C non fermerebbe lo scrolling infinito.
• La compressione di 250.000 file da una singola cartella ha richiesto circa 2 ore. È necessario eseguire il comando zip staccato dal terminale, altrimenti qualsiasi interruzione della connessione significa che è necessario ricominciare da capo.
• Non rischierei di provare a utilizzare il file zip su Windows.
• La cartella divenne rapidamente una zona vietata agli umani .

Ho finito per dover archiviare i file in sottocartelle usando il tempo di creazione per creare il percorso. Come /mnt/images/YYYY/MM/DD/UUID.jpg. Ciò ha risolto tutti i problemi di cui sopra e mi ha permesso di creare file zip destinati a una data.

Se l'unico identificativo per un file che hai è un numero numerico e questi numeri tendono ad essere eseguiti in sequenza. Perché non raggrupparli per 100000, 10000e1000 .

Ad esempio, se si dispone di un file denominato, 384295.txtil percorso sarebbe:

/mnt/file/300000/80000/4000/295.txt

Se sai che raggiungerai qualche milione. Usa 0prefissi per 1.000.000

/mnt/file/000000/300000/80000/4000/295.txt

Scrivi file di testo dal web scrape (non dovrebbe essere influenzato dal numero di file nella cartella).

Per creare un nuovo file è necessario eseguire la scansione del file di directory alla ricerca di spazio sufficiente per la nuova voce di directory. Se non viene individuato spazio sufficiente per memorizzare la nuova voce della directory, verrà posizionata alla fine del file della directory. All'aumentare del numero di file in una directory, aumenta anche il tempo di scansione della directory.

Fintanto che i file di directory rimangono nella cache di sistema, l'hit prestazioni da questo non sarà negativo, ma se i dati vengono rilasciati, la lettura del file di directory (di solito altamente frammentato) dal disco potrebbe richiedere un bel po 'di tempo. Un SSD migliora questo, ma per una directory con milioni di file, potrebbe esserci ancora un notevole impatto sulle prestazioni.

Comprimi i file selezionati, forniti da un elenco di nomi di file.

È probabile che ciò richieda tempo aggiuntivo in una directory con milioni di file. In un file system con voci di directory con hash (come EXT4), questa differenza è minima.

la memorizzazione di un massimo di dieci milioni di file in una cartella influirà sulle prestazioni delle operazioni di cui sopra o sulle prestazioni generali del sistema, diversamente dalla creazione di un albero di sottocartelle in cui i file devono vivere?

Un albero di sottocartelle non presenta nessuno degli svantaggi delle prestazioni sopra indicati. Inoltre, se il file system sottostante viene modificato per non avere nomi di file con hash, la metodologia ad albero funzionerà comunque bene.

In primo luogo: impedire a 'ls' di ordinare con 'ls -U', magari aggiornare ~ / bashrc per avere 'alias ls = "ls -U"' o simile.

Per il tuo set di file di grandi dimensioni, puoi provare questo in questo modo:

• creare un set di file di test

• vedere se molti nomi di file causano problemi

• utilizzare xargs parmeter-batching e il comportamento (predefinito) di zip nell'aggiungere file a uno zip per evitare problemi.

Questo ha funzionato bene:

# create ~ 100k files
seq 1 99999 | sed "s/\(.*\)/a_somewhat_long_filename_as_a_prefix_to_exercise_zip_parameter_processing_\1.txt/" | xargs touch
# see if zip can handle such a list of names
zip -q /tmp/bar.zip ./*
    bash: /usr/bin/zip: Argument list too long
# use xargs to batch sets of filenames to zip
find . -type f | xargs zip -q /tmp/foo.zip
l /tmp/foo.zip
    28692 -rw-r--r-- 1 jmullee jmullee 29377592 2017-12-16 20:12 /tmp/foo.zip