Il filesystem cerca prestazioni con molti piccoli file

Question

Sto cercando di costruire un server con molti piccoli file forniti da un'API XML. Non farà molta iterazione su directory o blocchi di file sequenziali: stiamo parlando di molte e molte ricerche di dati discontinui.

Cercherà che il tempo su BSD UFS degrada nel tempo per le richieste di singoli file? Comprendo che il limite di inode del filesystem si basa sulla dimensione della partizione / slice, ma il disco rigido deve passare attraverso la tabella di inode per ogni richiesta di file prima di poter scoprire la posizione dei dati. Quale filesystem offre le migliori prestazioni per il tempo di ricerca?

L'alternativa è configurare 2-4 GB "blob". file e hanno un sistema separato di ricerca di un file in essi contenuto all'interno del software. La tabella "inode" del software " potrebbe essere ottimizzato per la consegna in base all'utente attualmente connesso, ecc ... Queste "tabelle di inode" verrebbe probabilmente memorizzato nella cache della RAM e riguarderebbe solo gli utenti attualmente connessi in modo da ridurre le risorse sprecate.

Dove valutano queste due soluzioni in termini di scalabilità e manutenzione? Che tipo di prestazioni, se del caso, potrei aspettarmi usando la seconda soluzione?

Answer 1

La tecnica di mitigazione più ovvia e comprovata è quella di utilizzare un buon design gerarchico per le directory (e le strategie di ricerca dei nomi di percorso) e avere più directory con meno file in ciascuna.

Answer 2

Per le recenti versioni di FreeBSD con dirhash e softupdates che ho visto nessun problema con qualche diecimila file per directory. Probabilmente non vorrai andare a nord di circa 500.000 file. Per esempio. l'eliminazione di una directory con 2.500.000 file mi ha richiesto tre giorni.

Answer 3

Non sono sicuro di aver capito correttamente la tua domanda, ma se vuoi cercare molti file, perché non utilizzare una tabella mysql suddivisa in un filesystem RAID0 o VFS?

Modifica: per quanto ne so, molti file in una cartella degraderanno qualsiasi velocità FS in quanto deve mantenere elenchi più grandi di file, autorizzazioni e nomi, un database è progettato per mantenere gli elenchi di dati in memoria e ricercarli in modo molto ottimizzato.

Answer 4

Ulteriori dettagli sulla tua situazione potrebbero essere utili, i file sono già esistenti o verrebbero creati dalla tua applicazione? Se hai bisogno di un modo per archiviare dati arbitrari senza la struttura di un database relazionale hai esaminato database di oggetti

Answer 5

Un'altra opzione, se i tuoi oggetti devono o sono accessibili via HTTP, è quella di utilizzare una vernice cache davanti a un piccolo server web. Inizialmente gli oggetti sarebbero stati archiviati su disco, ma la vernice avrebbe archiviato e servito oggetti dalla memoria dopo il primo accesso a un determinato oggetto.