Persistenza: alberi di dati archiviati come alberi di directory

Question

Mi chiedevo quali fossero gli aspetti pratici della memorizzazione di una struttura ad albero di memoria come albero di directory a fini di persistenza. Nel mio caso, il suo filesystem di destinazione sarà ZFS e una volta creata la struttura, accederà raramente a più processi.

In che modo un performer sta usando un albero di directory come meccanismo di persistenza per alberi di dati?

Answer 1

Per leggere e scrivere il tuo albero, chiamerai il filesystem più volte per nodo. Questo è molto più costoso di qualsiasi codice sano che potresti escogitare per camminare su un'immagine di memoria.

Il fatto che si tratti di un approccio sensato dipende dal modello di utilizzo previsto. Se in una tipica invocazione del tuo codice ti aspetti di leggere nell'intera struttura ad albero, lavoraci su, quindi scrivilo per intero - è meglio smistarlo in un singolo file. Se, tuttavia, ti aspetti di leggere / lavorare su / mutare solo pochi nodi, senza leggendo nella maggior parte dell'albero, la differenza di prestazioni tra camminare sulla struttura della directory e fare più ricerche / letture per attraversare un albero memorizzato in un singolo file sarà molto più piccolo e potrebbe valere la pena fare il primo per semplicità / chiarezza / evitando di reinventare le ruote. Inoltre, se più processi lo fanno contemporaneamente, bloccare nodi e sottotitoli diventa molto più semplice con l'approccio basato su directory.

Tenere presente che per alcuni filesystem di uso comune il tempo di apertura di una voce della directory dipende dal numero totale di voci nella directory.

EDIT: ho fatto cose simili con ext3 per il backend CGI di un sito; non reinventare la ruota ha reso la prototipazione più rapida e la manutenzione più semplice, legge / scrive / blocca in scala abbastanza bene, ma modifiche molto frequenti - nell'ordine di centinaia al secondo - alla struttura della directory stessa hanno funzionato male sulla memoria reale ; alla fine ho ristrutturato le cose in modo che le sezioni dell'albero delle directory alle quali le voci della directory sarebbero state aggiunte / rimosse molto frequentemente finissero su un volume tmpfs - per me questo set di stati potrebbe (costoso) essere ricostruito da quello archiviato in una memoria meno volatile a seguito di un riavvio. Ho poca esperienza di ZFS e non conosco il modello di utilizzo previsto, quindi non so se questo sarebbe un problema per te. Se lo facessi ora per un sito molto utilizzato, probabilmente arrotolerei invece la mia libreria di blocco denominata.

Answer 2

La maggior parte dei filesystem sono ottimizzati per l'accesso a un file aperto, quindi l'apertura / chiusura di un file richiede un tempo significativo. Se ogni foglia del tuo albero è piccola, leggere / scrivere l'intera struttura richiederebbe molte volte più tempo del necessario.

Inoltre, la maggior parte dei filesystem ha un blocco di allocazione minimo, di solito intorno a 2-8 KB. se le tue foglie sono molto più piccole di quelle, sprecherai molto spazio.

In breve, più piccole sono le tue foglie, peggio è l'idea.

Answer 3

Se ho capito bene stai parlando di costruire una struttura ad albero che darebbe una rappresentazione in-code del tuo filesystem, quindi sospetto che all'inizio dovresti leggere un overhead dove stai leggendo nella tua struttura ad albero, ma le successive ricerche e traversate dell'albero sarebbero probabilmente più veloci che colpire ogni volta l'archiviazione su disco.

Answer 4

Possibili problemi:

• Può fare un uso inefficiente dello spazio su disco (in molti file system una directory è un file e come tale occupa un intero blocco sul disco ...)
• Sarà lento leggere / scrivere perché si effettuano molti accessi al file system
• Il file system può / imporrà limiti sulla lunghezza di ciascun nome di elemento e / o caratteri che è possibile utilizzare per i nomi
• Sarà facile per altri processi corrompere i tuoi dati e / o richiedere cospicui costi di blocco
• Quando si usano `` dischi '' a stato solido, ciò può comportare più scritture di altri metodi e ridurre la durata dei media

In conclusione: potrebbe non valerne la pena.