Gestisco un sito Web in cui sono archiviati circa 10 milioni di file (copertine di libri) in 3 livelli di sottodirectory, che vanno da [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

Questo porta a circa 2400 file per directory, il che è molto veloce quando dobbiamo recuperare un file. Questa è inoltre una pratica suggerita da molte domande .

Tuttavia, quando ho bisogno di fare il backup di questi file, ci vogliono molti giorni solo per sfogliare le directory 4k che contengono file da 10m.

Quindi mi chiedo se potrei archiviare questi file in un contenitore (o in contenitori 4K), ognuno dei quali si comporterebbe esattamente come un filesystem (una specie di contenitore ext3 / 4 montato?). Immagino che sarebbe quasi altrettanto efficace dell'accesso diretto a un file nel filesystem e questo avrebbe il grande vantaggio di essere copiato su un altro server in modo molto efficiente.

Qualche suggerimento su come farlo meglio? O qualche alternativa praticabile (noSQL, ...)?

Opzioni per l'accesso rapido e il backup di milioni di file

Prendi in prestito da persone con problemi simili

Questo suona molto come un tipo di problema più semplice che deve affrontare i server di notizie USENET e i proxy Web di memorizzazione nella cache: centinaia di milioni di piccoli file a cui si accede in modo casuale. Potresti voler prendere un suggerimento da loro (tranne che in genere non devono mai fare backup).

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

Ovviamente la natura ciclica del filesystem di notizie cicliche è irrilevante per te, ma il concetto di livello inferiore di avere più file / dispositivi su disco con immagini compresse e un indice veloce dalle informazioni che l'utente fornisce per cercare le informazioni sulla posizione è molto appropriato.

File system dedicati

Naturalmente, questi sono concetti simili a quelli di cui parlavano le persone creando un file system in un file e montandolo su loopback, tranne per il fatto che si riesce a scrivere il proprio codice del file system. Naturalmente, dal momento che hai detto che il tuo sistema era in gran parte letto, potresti effettivamente dedicare una partizione del disco (o partizione lvm per la flessibilità nel dimensionamento) a questo scopo. Quando si desidera eseguire il backup, montare il filesystem in sola lettura e quindi creare una copia dei bit di partizione.

LVM

Ho menzionato LVM sopra come utile per consentire il dimensionamento dinamico di una partizione in modo che non sia necessario eseguire il backup di molto spazio vuoto. Ma, naturalmente, LVM ha altre caratteristiche che potrebbero essere molto applicabili. In particolare la funzionalità "snapshot" che consente di bloccare un filesystem in un momento. Qualsiasi accidentale rm -rfo altro non disturberebbe l'istantanea. A seconda di ciò che si sta tentando di fare, ciò potrebbe essere sufficiente per le esigenze di backup.

RAID-1

Sono sicuro che hai già familiarità con RAID e probabilmente lo usi già per affidabilità, ma RAID-1 può essere utilizzato anche per i backup, almeno se stai utilizzando RAID software (puoi usarlo con RAID hardware, ma in realtà offre una minore affidabilità perché potrebbe essere necessario leggere lo stesso modello / controller di revisione). Il concetto è che crei un gruppo RAID-1 con un disco in più di quello di cui hai effettivamente bisogno per le tue normali esigenze di affidabilità (es. Un terzo disco se usi il software RAID-1 con due dischi, o forse un disco grande e un hardware- RAID5 con dischi più piccoli con un software RAID-1 sopra l'hardware RAID-5). Quando arriva il momento di eseguire un backup, installare un disco, chiedere a mdadm di aggiungere quel disco al gruppo raid, attendere fino a quando non indica completezza, facoltativamente chiedere uno scrub di verifica, quindi rimuovere il disco. Ovviamente,

È possibile montare un filesystem virtuale utilizzando il gestore di loopback ma mentre ciò accelererebbe il processo di backup, potrebbe influire sulle normali operazioni.

Un'altra alternativa è il backup dell'intero dispositivo tramite dd. Ad esempio dd if=/dev/my_device of=/path/to/backup.dd,.

Come probabilmente saprai, il tuo problema è la località. Una ricerca del disco tipica richiede circa 10 ms. Quindi, chiamare semplicemente "stat" (o open ()) su 10 milioni di file posizionati casualmente richiede 10 milioni di ricerche, o circa 100000 secondi, o 30 ore.

Quindi è necessario inserire i file in contenitori più grandi, in modo tale che il numero rilevante sia la larghezza di banda dell'unità (50-100 MB / sec per un singolo disco, in genere) anziché il tempo di ricerca. Inoltre, puoi lanciarvi un RAID, che ti consente di aumentare la larghezza di banda (ma non ridurre i tempi di ricerca).

Probabilmente non ti sto dicendo nulla che non conosci già, ma il mio punto è che la tua idea di "contenitore" risolverà definitivamente il problema, e praticamente qualsiasi contenitore lo farà. I montaggi di loopback probabilmente funzioneranno come qualsiasi altra cosa.

Ci sono un paio di opzioni. Il più semplice, e dovrebbe funzionare con tutti i filesystem Linux, è ddcopiare l'intera partizione ( /dev/sdb3o /dev/mapper/Data-ImageVol) su una singola immagine e archiviarla. In caso di ripristino di singoli file, montare in loopback l'immagine ( mount -o loop /usr/path/to/file /mountpoint) e copiare i file necessari. Per un ripristino completo della partizione, è possibile invertire la direzione del ddcomando iniziale , ma in realtà è necessaria una partizione di dimensioni identiche.

A giudicare dal tuo caso d'uso, immagino che i singoli ripristini di file siano un evento molto raro, se mai si verificano affatto. Questo è il motivo per cui un backup basato su immagini ha davvero senso qui. Se è necessario eseguire ripristini individuali più spesso, l'utilizzo di snapshot LVM per fasi sarà molto più conveniente; ma è comunque necessario eseguire il backup basato su immagini per i disastri critici "abbiamo perso tutto". I ripristini basati su immagini tendono ad andare molto più velocemente rispetto ai ripristini basati su tar semplicemente perché stanno solo ripristinando i blocchi, non stanno subendo un bel po 'di operazioni di metadati con ogni fopen / fclose e possono anche essere un'operazione su disco altamente sequenziale per ulteriori aumenti di velocità.

In alternativa, come sottolineato dal video di Google @casey a metà strada, XFS è un ottimo file system (se complesso). Una delle utility più belle con XFS è l' xfsdumputility, che scaricherà un intero file system in un singolo file e generalmente lo farà più velocemente di quanto tarpossa. È un'utilità specifica del filesystem, quindi può trarre vantaggio dagli interni di fs in modi che tar non può.

Ti suggerirei prima di provare ad aggiornare a EXT4, se non lo stai già eseguendo.

Google ha fatto molte ricerche sul perché EXT4 sia una buona idea .

Successivamente, è necessario esaminare la distribuzione di un'architettura di file system distribuita. Per esempio:

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

Forse una risposta semplicistica, ma il mio primo pensiero è stato quello di utilizzare qualcosa come GridFS che si basa su MongoDB . Molti dei driver di lingua principale lo supportano immediatamente, quindi dovresti essere in grado di scambiarlo con le sezioni di lettura dei file del tuo codice. Inoltre, potresti semplicemente rendere le tue directory esistenti le chiavi di questi file.

Un problema che potresti avere è che Mongo tende a rallentare abbastanza velocemente se cerca continuamente dal disco. Con 10 milioni di file, mi aspetto che la maggior parte dei tuoi dati sarà su disco. I blocchi di file in GridFS sono 4 MB, per quanto ricordo, quindi se i tuoi file sono più grandi di quello, eseguirai diverse operazioni costose per ottenere un file. La chiave, penso, sarebbe quella di frammentare i tuoi file in base alla tua struttura di directory già ordinata in modo da poter avere diverse istanze di Mongo in esecuzione su più scatole per alleggerire il carico. Tuttavia, non so quali siano i tuoi requisiti di prestazione, quindi potrei pensarci troppo.

Qual è il vantaggio di tutto questo? Prestazioni che corrispondono abbastanza da vicino alle letture del disco se eseguite correttamente. Inoltre, Mongo offre diversi modi integrati per eseguire rapidamente il backup dell'intera fascia di dati in un'istanza di database, e anche con il database ancora in esecuzione.

Se sei soddisfatto di un modello di dispositivo per l'archiviazione dei dati, forse potresti prendere in considerazione NexentaStor . Esegue ZFS su OpenSolaris sotto copertura, ma tutta l'amministrazione avviene tramite una GUI web.

Ci sono un paio di funzioni che potrebbero aiutarti a risolvere il tuo problema.

• La versione Enterprise supporta una forma di replica remota basata su snapshot che non richiede la scansione dell'intero filesystem.

• Se non ti dispiace sporcarti le mani, ZFS ha un comando ZFS diff molto utile che ti dice in modo efficiente quali file sono stati aggiunti, modificati o eliminati dall'ultima istantanea, senza dover scansionare l'intero file system. È possibile incorporarlo nel sistema di backup per ridurre notevolmente il tempo necessario per eseguire backup incrementali.

È possibile utilizzare dumpun'utilità standard per il backup del filesystem EXT4 con molti file. Questa utility controlla innanzitutto quali blocchi vengono utilizzati su un filesystem e quindi li esegue il backup nell'ordine del disco, eliminando la maggior parte delle ricerche.

Esiste restoreun'utilità corrispondente per ripristinare i backup creati da dump.

Supporta backup incrementali utilizzando i livelli - file di backup di livello 1 modificati dall'ultimo backup di livello 0 (completo), livello 2 - modificati dal backup di livello 1 e così via.

Per i backup incrementali, un'opzione sarebbe quella di avere un secondo albero delle ombre per le nuove copertine. Cioè, avresti il ​​tuo albero principale che viene utilizzato per tutte le operazioni di lettura. Avresti anche una newfiles/012345.....jpgdirectory; le copertine appena aggiunte creano un collegamento fisico qui e nell'albero principale. Quando si eseguono backup, è possibile eseguire occasionalmente il backup dell'albero principale, ma eseguire il backup dell'albero (molto più piccolo) newfilesmolto più regolarmente.

Si noti che per mantenere l' newfilesalbero piccolo, prima di eseguire un nuovo backup dell'albero principale, è possibile svuotare l'albero dei newfile:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Una volta che lo fai, ovviamente, ti impegni a produrre un nuovo backup dell'albero principale.

L'aggiunta di un po 'di concorrenza di solito aiuta.

Ho un problema simile a te; nel mio caso devo eseguire il backup di circa 30 milioni di file, molti dei quali sono file HTML, PHP o JPEG. Per me BackupPC + rsync su ssh funziona in modo OK; il backup completo richiede circa un giorno, ma gli incrementali di solito finiscono in un paio d'ore.

Il trucco è aggiungere ogni directory di livello principale (0, 1, 2 ... a, b, c ...) come nuova destinazione da copiare in BackupPC e lasciare che esegua il backup in parallelo, in modo da eseguire contemporaneamente il backup delle directory un/ , b / , c / * e così via. A seconda del sottosistema del disco, qualsiasi cosa tra un paio di processi e circa 10 processi è probabilmente il modo più rapido per eseguire il backup.

Anche le istantanee LVM e il backup a livello di blocco sono un'opzione, ma con BackuPC e il backup a livello di file è ancora possibile ripristinare singoli file o directory, se necessario.

Benjamin,

Penso che il tuo problema possa essere risolto al numero di file per livello di directory!

Il tempo di accesso cambia di un fattore significativo se si memorizzano 20.000 file in una directory?

Hai anche pensato di archiviare i metadati del filesystem su un'unità di accesso più veloce separata (come un SSD).

Consiglierei invece un buon vecchio database relazionale.

Userei un PostgreSQL con, diciamo, 256 tabelle partizionate (cover_00, cover_01, ..., cover_ff) con dati immagine come byteacolonna (binaria) con memoria esterna, con identificatore di file come chiave primaria. Il recupero di un'immagine sarebbe rapido (grazie a un indice sulla chiave primaria), l'integrità dei dati sarebbe garantita (database conforme ACID), il backup sarebbe nell'ordine del disco, quindi non troppo da cercare.