I database di file flat sono buoni?

Question

Opzioni informate necessarie per i meriti del database di file flat. Sto considerando di utilizzare uno schema di database di file flat per gestire i dati per un blog personalizzato. Sarebbe distribuito su una variante di Linux OS e scritto in Java.

Quali sono i possibili aspetti negativi o positivi relativi alle prestazioni per la lettura e la scrittura di articoli e commenti?

L'articolo recupera schifo perché è un file piatto anziché un RDBMS se si desidera ottenere una barra puntata? (Wishful thinking)

Non sono contrario all'uso di un RDBMS, solo chiedendo alla community la loro opinione sulla fattibilità di tale schema di architettura software.

Follow Up: Nel caso di questa domanda vorrei vedere “Lima piatta == sistema di file-based” Per esempio ogni voce blog e il relativo metadati di accompagnamento sarebbe in un unico file. Rendendo per molti file organizzati dalla struttura data delle cartelle di file (blog \ testblog2 \ 2008 \ 12 \ 01) == 12/01/2008

Answer 1

I database di file flat hanno la loro posizione e sono abbastanza utilizzabili per il dominio corretto.

I server di posta e server NNTP del passato hanno davvero spinto i limiti di quanto realmente si possano prendere queste cose (che in realtà è piuttosto lontano - i file system possono avere milioni di file e directory).

I DB di file flat due punti deboli principali sono gli aggiornamenti di indicizzazione e atomici, ma se il dominio è adatto, questi potrebbero non essere un problema.

Ma è possibile, ad esempio, con un blocco appropriato, eseguire un aggiornamento dell'indice "atomico" utilizzando i comandi di base del file system, almeno su Unix.

Un caso semplice sta avendo il processo di indicizzazione in esecuzione attraverso i dati per creare il nuovo file di indice con un nome temporaneo. Quindi, una volta terminato, è sufficiente rinominare (il nome di sistema rinominare (2) o il comando shell mv) il vecchio file sul nuovo file. Rinominare e mv sono operazioni atomiche su un sistema Unix (cioè funziona o non funziona e non c'è mai uno "stato intermedio" mancante).

Uguale alla creazione di nuove voci.Fondamentalmente scrivere il file completamente in un file temporaneo, quindi rinominarlo o inserirlo nella sua posizione finale. Quindi non hai mai un file "intermedio" nel "DB". Altrimenti, potresti avere una condizione di competizione (come un processo che legge un file che è ancora in fase di scrittura, e potrebbe arrivare alla fine prima che il processo di scrittura sia completato - condizioni di corsa brutte).

Se l'indicizzazione primaria funziona bene con i nomi di directory, allora funziona perfettamente. È possibile utilizzare uno schema di hashing, ad esempio, per creare directory e sottodirectory per individuare nuovi file.

Trovare un file usando il nome del file e la struttura della directory è molto veloce dato che la maggior parte dei file system oggi indicizza le proprie directory.

Se stai mettendo un milione di file in una directory, potrebbero esserci dei problemi di tuning a cui vorresti dare un'occhiata, ma da quella scatola molti ne gestiranno facilmente 10 di migliaia. Ricorda che se hai bisogno di SCAN la directory, ci saranno un sacco di file da scansionare. Il partizionamento tramite le directory aiuta a impedirlo.

Ma tutto dipende dalle tecniche di indicizzazione e ricerca.

In modo efficace, un server Web di riserva disponibile per scaffale che serve contenuti statici è un database di file grandi e piatti, e il modello funziona piuttosto bene.

Infine, naturalmente, hai a disposizione la pletora di strumenti a livello di file system Unix gratuiti, ma tutti hanno problemi con milioni di file (la foratura di grep 1000000 volte per trovare qualcosa in un file avrà un compromesso in termini di prestazioni - l'overhead si aggiunge semplicemente).

Se tutti i file si trovano sullo stesso file system, anche gli hard link offrono opzioni (poiché anch'esse sono atomiche) in termini di inserimento dello stesso file in posizioni diverse (in pratica per l'indicizzazione).

Ad esempio, è possibile avere una directory "oggi", una directory "ieri", una directory "java" e la directory dei messaggi effettiva.

Quindi, un post può essere collegato nella directory "today", la directory "java" (perché il post è taggato con "java", ad esempio), e nella sua posizione finale (ad esempio/articles/2008/12 /01/my_java_post.txt). Quindi, a mezzanotte, esegui due processi. Il primo prende tutti i file nella directory "today", controlla la loro data di creazione per assicurarsi che non siano "attuali" (dato che il processo può richiedere alcuni secondi e un nuovo file potrebbe introdursi) e li rinomina in " ieri". Successivamente, fai la stessa cosa per la directory "ieri", solo che qui semplicemente li elimini se non sono aggiornati.

Nel frattempo, il file si trova ancora nella directory "java" e ".../12/01". Dato che stai utilizzando un file system Unix e collegamenti reali, il "file" esiste solo una volta, questi sono solo dei puntatori al file. Nessuno di loro è "il" file, sono tutti uguali.

Si può vedere che mentre ogni singolo spostamento di file è atomico, il grosso non lo è. Ad esempio, mentre lo script "oggi" è in esecuzione, la directory "ieri" può contenere file sia di "ieri" che di "il giorno prima" perché lo script "ieri" non è ancora stato eseguito.

In un DB transazionale, lo si farebbe tutto in una volta.

Ma, semplicemente, è un metodo provato e vero. Unix, in particolare, funziona molto bene con quell'idioma, e anche i moderni file system possono supportarlo abbastanza bene.

Answer 2

(risposta copiato e modificato da here)

lo farei sconsigliamo di utilizzare un file flat per qualsiasi cosa, oltre all'accesso in sola lettura, perché in tal caso dovreste affrontare problemi di concorrenza come accertarvi che solo un processo stia scrivendo sul file in una sola volta. Invece, raccomando SQLite, un database SQL completamente funzionale che è memorizzato in un file. SQLite ha già una concomitanza integrata, quindi non devi preoccuparti di cose come il blocco dei file, ed è molto veloce per le letture.

Se, tuttavia, si stanno eseguendo numerose modifiche al database, è preferibile eseguirle tutte contemporaneamente in uno transaction. Ciò scriverà solo le modifiche al file una volta, a differenza di ogni volta che viene inviata una query di modifica. Ciò aumenta notevolmente la velocità di eseguire più modifiche.

Quando viene emessa una query di modifica, indipendentemente dal fatto che si trovi all'interno di una transizione o meno, l'intero database viene bloccato fino al termine della query. Ciò significa che transazioni estremamente grandi potrebbero influire negativamente sulle prestazioni di altri processi perché devono attendere il completamento della transazione prima che possano accedere al database. In pratica, non ho trovato che sia così evidente, ma è sempre buona norma cercare di ridurre al minimo il numero di query di modifica del database che si verificano, ed è sicuramente più veloce di provare a utilizzare un file flat.

Answer 3

Idea orribile. L'aggiunta comporterebbe la ricerca fino alla fine del file ogni volta che si desidera aggiungere qualcosa. L'aggiornamento richiederebbe riscrivere l'intero file ogni volta. La lettura implica una scansione della tabella (o il mantenimento di un indice separato, che avrebbe gli stessi problemi con la scrittura/l'aggiornamento). Basta usare un database, a meno che, naturalmente, non si rieseguano le implementazioni di tutto ciò che un RDBMS già fornisce per rendere la soluzione ancora moderatamente scalabile.

Answer 4

Questo è stato fatto con asp.net con Dasblog. Usa lo storage basato su file.

Alcuni dettagli sono elencati in questo collegamento precedente. http://www.hanselman.com/blog/UpcomingDasBlog19.aspx

È inoltre possibile ottenere maggiori informazioni sul http://dasblog.info/Features.aspx

Ho sentito alcune opinioni contrastanti sulle prestazioni. Ti suggerirei di cercare un po 'di più per vedere se quel tipo di sistema funzionasse bene per te. Questa è la cosa più vicina che ho sentito ancora.

Answer 5

Scrivere il proprio motore in codice nativo può sovraperformare un database di uso generale.

Tuttavia, la qualità del motore e il livello di funzionalità non si avvicinano mai. Tutte le cose che i database ti forniscono come funzionalità principali: indicizzazione, transazioni, integrità referenziale, dovresti implementarle tutte da te.

Non c'è niente di sbagliato nel reinventare la ruota (dopotutto, Linux era proprio questo), ma tieni a mente le tue aspettative e il tuo impegno nel tempo.

Answer 6

Sembrano funzionare abbastanza bene per i database ad alta scrittura, a bassa lettura e senza aggiornamento, in cui vengono aggiunti nuovi dati.

I server Web ei loro cugini si affidano pesantemente a loro per i file di registro.

Anche il software DBMS li utilizza per i registri.

Se il tuo progetto rientra in questi limiti, sembra che tu sia in buona compagnia. Si potrebbe voler mantenere metadati e puntatori in un database e impostare una sorta di veloce queue-writer asincrono per memorizzare i commenti, ma il filesystem è già abbastanza buono a livello di buffering e write-locking.

Answer 7

I database di file flat sono possibili ma si consideri quanto segue.

I database devono ottenere tutti gli elementi ACID (atomicità, consistenza, isolamento, durata) e, se si vuole garantire che tutto sia fatto in un file flat (specialmente con accesso simultaneo), in pratica si è scritto un DBMS in piena regola.

Quindi perché non utilizzare un DBMS completo in primo luogo?

Ti risparmierai il tempo e il denaro necessari per scrivere (e riscriverli molte volte, te lo garantisco) se ti limiti a scegliere una delle opzioni gratuite (SQLite, MySQL, PostgresSQL e così via) .

Answer 8

È possibile utilizzare i database di file fiat se è sufficientemente piccolo non ha perso l'accesso casuale. Il grande file con molto accesso casuale sarà molto lento. E nessuna domanda complessa. Nessun join, nessuna somma, gruppo per ecc. Inoltre non puoi aspettarti di recuperare i dati gerarchici dal file flat. Il formato XML è molto meglio per le strutture complesse.

Answer 9

Sto rispondendo a questo non rispondere perché i database di file flat sono buoni o cattivi, altri hanno fatto un ampio lavoro a tale scopo.

Tuttavia, alcuni hanno puntato su SQLite, che fa bene il suo lavoro. Dato che stai usando Java, l'opzione migliore sarebbe utilizzare HSQLDB, che fa esattamente lo stesso di SQLite, ma è implementato in Java e incorporato nella tua applicazione.

Answer 10

La maggior parte delle volte è sufficiente un database di file flat ora. Ma ringrazierai te stesso se inizi il tuo progetto con un database. Questo potrebbe essere SQLite, se non si desidera impostare un intero sistema di database come PostgreSQL.

Answer 11

Verificare questo http://jsondb.io un database basato su Java opensource ha la maggior parte di quello che stai cercando. Salva i dati come file .json flat, supporto multithreading, supporto crittografia, supporto ORM, supporto per l'atomizzazione, supporto di query avanzate basato su XPATH.

Disclaimer: Ho creato questo database.