Svantaggi di avere (potenzialmente) migliaia di directory in un server anziché in un database?

Question

Sto cercando di iniziare a utilizzare file di solo testo per archiviare i dati su un server, piuttosto che archiviarli tutti in un grande database MySQL. Il problema è che probabilmente genererei migliaia di cartelle e centinaia di migliaia di file (se mai dovessi scalare). Quali sono i problemi con questo? Diventa veramente lento? Si tratta delle stesse prestazioni dell'utilizzo di un database?

Quello che voglio dire: Invece di avere un database che memorizza una tabella blog, quindi ha una riga che contiene, "messaggio" e "data" "autore" Vorrei invece avere: Una cartella per la posta specifica, quindi i file * .txt all'interno di quella cartella che contengono "autore", "messaggio" e "data" in essi memorizzati.

Answer 1

Questa lettura sarebbe molto più lenta di un database (il file scrive tutto alla stessa velocità - non è possibile memorizzare una scrittura in memoria).

I database sono ottimizzati e pensati per gestire quantità così grandi di dati strutturati. I file system non lo sono. Sarebbe un errore provare a replicare un database con un file system. Dopo tutto, è possibile indicizzare le colonne del database, ma è difficile indicizzare il file system senza un altro strumento.

I database sono progettati per l'accesso e il recupero rapido dei dati. I file system sono costruiti per l'archiviazione dei dati. Usa lo strumento giusto per il lavoro. In questo caso, è assolutamente un database.

Detto questo, se si desidera creare file HTML per i post e quindi memorizzare tali impostazioni locali in un DB in modo che sia possibile raggiungerli facilmente, è sicuramente una buona soluzione (un tipo mobile).

Ma se si memorizzano queste cose su un file system, come si può scoprire il tuo ultimo post? L'autore più prolifico? L'autore più controverso? Tutte queste cose sono banali con un database e molto difficili con un file system. Rimani con il database, sarai contento di averlo fatto.

Answer 2

I database NON sono più veloci. Pensaci: alla fine memorizzano i dati anche nel filesystem. Quindi la domanda se un database è più veloce dipende fortemente dal percorso di accesso.

Se si dispone di un solo percorso di accesso, correlato alla struttura del file, il file system potrebbe essere molto più veloce di un database. Assicurati di avere un po 'di cache disponibile per il filesystem.

Ovviamente si perdono tutte le cose belle di un database: - transazioni - modi flessibili per indicizzare i dati, e quindi accedere ai dati in modo flessibile ragionevolmente veloce. - linguaggio di query flessibile (anche se brutto) - alta recuperabilità.

Il ridimensionamento dipende molto dal file system utilizzato. La maggior parte dei file system AFAIK ha una sorta di limite superiore per il numero di file (totalmente o per directory), sebbene su quelli nuovi questo è spesso molto alto. Per centinaia e migliaia di file con una struttura di directory tale da mantenere le directory di dimensioni ragionevoli, dovrebbe essere possibile trovare un file system ben funzionante.

@ Commento di Eric: Dipende da ciò che ti serve.Se avete solo bisogno il contenuto del esatto in archivio per query, ed è possibile determinare la posizione e il nome del file in modo deterministico l'accesso diretto è più veloce di quello che fa un database, che è più o meno:

• accesso un gruppo di voci di indice, al fine di
• accedere a un gruppo di righe di tabella (rdbms in genere leggono i blocchi che contengono più righe), al fine di
• scegliere una singola riga dal blocco.

Se la si guarda: avete indici e righe aggiuntive in memoria, che rendono il vostro caching inefficiente, dove si trova il l'aumento di velocità di un db dovrebbero provenire da?

I database sono ottimi per il caso generale. Ma se hai un caso particolare, c'è quasi sempre una soluzione speciale che è meglio in un certo senso.

Answer 3

E 'in realtà dipende:

• Qual è la dimensione del file
• requisiti di durabilità Cosa avete?
• Quanti aggiornamenti esegui?
• Che cos'è il file system?

Non è ovvio che MySQL sarebbe più veloce:

ho fatto una volta tale confronto per piccolo oggetto al fine di utilizzarlo come deposito per le sessioni CppCMS. Con un solo indice (solo chiave) e due indici (chiave primaria e timeout secondario).

File System: XFS  ext3 
----------------------------- 
Writes/s:  322  20,000 

Data Base \ Indexes: Key Only Key+Timeout 
----------------------------------------------- 
Berkeley DB    34,400  1,450 
Sqlite No Sync   4,600  3,400 
Sqlite Delayed Commit 20,800  11,700 

Come si può vedere, con un semplice file system Ext3 è stato più veloce o più velocemente Sqlite3 per la memorizzazione dei dati perché non ti dà (D) di acido.

D'altra parte ... DB ti offre molte, molte funzionalità importanti che probabilmente ti servono, quindi Non consiglierei di usare i file come memoria a meno che tu non ne abbia davvero bisogno.

Ricordate, DB è not always il collo di bottiglia del sistema

Answer 4

Non avete davvero dire perché non sarà possibile utilizzare un database da soli ... Ma lo scenario che si sta descrivendo avrei sicuramente usare un DB su una cartella qualsiasi giorno, per un paio di motivi. Prima di tutto, lo scenario del blog sembra molto semplice ma è molto facile immaginare che tu, un giorno, vorresti espanderlo con più funzionalità come ricerca, altri dettagli, categorie ecc.

Penso che crescere il modello sarebbe più difficile da fare in una struttura di cartelle che in un DB.

Inoltre, i database sono in genere MOLTO più veloci rispetto all'accesso ai file a causa di indicizzazione e memorizzazione nella cache.

Answer 5

Penso che la chiave qui sia che NON ci sarà l'indicizzazione sui dati. Quindi, per recuperare qualcosa in una ricerca, sarebbe ridicolmente lento rispetto a un database indicizzato. Inoltre, le operazioni di I/O sono costose, un database potrebbe essere (parzialmente) in memoria, il che rende i dati disponibili molto più veloci.

Answer 6

IIRC Fudforum utilizzava la memorizzazione dei file per motivi di velocità, può essere molto più veloce prendere un file piuttosto che cercare un indice DB, recuperare i dati dal DB e inviarlo all'utente. Stai scambiando l'interfaccia del filesystem con le interfacce DB e librerie DB.

Tuttavia, ciò non significa che sarà più veloce o più lento. Penso che troverete che la scrittura è più veloce sul filesystem, ma la lettura più veloce sul DB per problemi generali. Se, come fudforum, hai dati relativamente immutabili che vuoi mostrare più post in uno, allora un approccio file-basd potrebbe essere molto più veloce: ad esempio non devono cercare ogni post correlato, lo attaccano tutti in 1 file di testo e visualizzalo una volta. Se puoi utilizzare questo tipo di ottimizzazione, allora il tuo approccio basato su file funzionerà.

Inoltre, i server di posta elettronica funzionano anche nell'approccio basato su file, il formato Maildir memorizza ciascun messaggio di posta elettronica come un file in una directory, non in un database.

una cosa direi, sarà meglio memorizzare tutto in 1 file, non in 3. Il file system è migliore per la lettura (e la memorizzazione nella cache) di un singolo file piuttosto che di più. Quindi, se vuoi memorizzare ogni messaggio come 3 parti, salvale in un unico file, leggerlo per ottenere qualsiasi parte e visualizzare solo quello che vuoi mostrare.

Answer 7

Dimenticate risposte prolisso, ecco le ragioni più semplici per cui la memorizzazione dei dati nei file di testo in chiaro è una cattiva idea:

1. E 'quasi impossibile per interrogare. Come classificheresti i post dei blog per data? Dovreste leggere tutti i file e confrontare la data, o mantenere il proprio file di indice (in pratica, scrivere il proprio sistema di database.)

2. E 'un incubo per il backup.tar cjf non lo taglierà, e se ci provi potresti finire con uno snapshot incoerente.

C'è probabilmente una dozzina di altri buoni motivi per non usare i file, è difficile per monitorare le prestazioni, molto difficile da eseguire il debug, quasi impossibile da recuperare in caso di errore, non ci sono strumenti per gestirli, ecc ...

Answer 8

se si è preferito andare via con RDBMS, perchè non prova di u l'altro valore chiave open source o di un documento DB (non-relazionale Dbs) ..

da ur post ho capito che non ur goin da seguire qualsiasi proprietà ACID del db relazionale .. sarebbe meglio adattare un altro valore chiave dbs (mongodb, coutchdb o hyphertable) al posto del proprio sistema di file system azione .. fornirà prestazioni migliori rispetto agli approcci esistenti ..

Nota: Non sono anche esperto in questo .. appena iniziato a lavorare su MongoDB e trovare utile in scenari simili. Volevo solo condividere nel caso in cui non ur a conoscenza di questi approcci

Answer 9

... e poi si desidera cercare tutti i messaggi di un autore e si arriva a leggere un milione di file invece di una semplice query SQL ...