Perché usare un database invece di salvare i dati sul disco?

Invece di un database, ho appena serializzato i miei dati su JSON, salvandoli e caricandoli su disco quando necessario. Tutta la gestione dei dati viene effettuata sul programma stesso, che è più veloce E più facile rispetto all'utilizzo di query SQL. Per questo motivo non ho mai capito perché i database siano assolutamente necessari.

Perché si dovrebbe usare un database invece di salvare semplicemente i dati su disco?

1. È possibile eseguire query sui dati in un database (porre domande).
2. È possibile cercare i dati da un database in modo relativamente rapido.
3. È possibile mettere in relazione i dati di due diverse tabelle insieme utilizzando JOIN.
4. È possibile creare report significativi dai dati in un database.
5. I tuoi dati hanno una struttura integrata.
6. Le informazioni di un determinato tipo vengono sempre memorizzate una sola volta.
7. I database sono ACID .
8. I database sono tolleranti agli errori.
9. I database possono gestire set di dati molto grandi.
10. I database sono simultanei; più utenti possono usarli contemporaneamente senza corrompere i dati.
11. I database si ridimensionano bene.

In breve, beneficiate di una vasta gamma di tecnologie ben note e comprovate sviluppate nel corso di molti anni da un'ampia varietà di persone molto intelligenti.

Se sei preoccupato che un database sia eccessivo, controlla SQLite.

Mentre sono d'accordo con tutto ciò che Robert ha detto, non ti ha detto quando dovresti usare un database invece di salvare semplicemente i dati su disco.

Quindi prendi questo in aggiunta a ciò che Robert ha detto su scalabilità, affidabilità, tolleranza agli errori, ecc.

Per quando usare un RDBMS, ecco alcuni punti da considerare:

• Hai dati relazionali, cioè hai un cliente che acquista i tuoi prodotti e quei prodotti hanno un fornitore e un produttore
• Hai una grande quantità di dati e devi essere in grado di individuare rapidamente le informazioni pertinenti
• È necessario iniziare a preoccuparsi dei problemi precedenti identificati: scalabilità, affidabilità, conformità ACID
• È necessario utilizzare strumenti di reporting o intelligence per risolvere i problemi aziendali

Per quanto riguarda quando utilizzare un NoSQL

• Hai molti dati che devono essere archiviati e che non sono strutturati
• Scalabilità e velocità richieste
• In genere non è necessario definire lo schema in anticipo, quindi se si hanno esigenze di modifica questo potrebbe essere un buon punto

Infine, quando utilizzare i file

• Hai dati non strutturati in quantità ragionevoli che il file system può gestire
• Non ti importa di struttura, relazioni
• Non ti interessa la scalabilità o l'affidabilità (anche se questi possono essere fatti, a seconda del file system)
• Non si desidera o non è possibile gestire l'overhead che verrà aggiunto da un database
• Hai a che fare con dati binari strutturati che appartengono al file system, ad esempio: immagini, PDF, documenti, ecc.

Una cosa che nessuno sembra aver menzionato è l'indicizzazione dei record. Il tuo approccio al momento va bene, e presumo che tu abbia un set di dati molto piccolo e pochissime persone vi accedono.

Man mano che diventi più complesso, stai effettivamente creando un database. Qualunque cosa tu voglia chiamarlo, un database è solo un insieme di record memorizzati su disco. Sia che tu stia creando il file, o MySQL , SQLite o qualunque cosa stia creando i file, sono entrambi database.

Ciò che manca è la complessa funzionalità che è stata integrata nei sistemi di database per renderli più facili da usare.

La cosa principale che mi viene in mente è l'indicizzazione. OK, quindi puoi archiviare 10 o 20 o anche 100 o 1000 record in un array serializzato o una stringa JSON ed estrarlo dal tuo file e iterarlo relativamente rapidamente.

Ora, immagina di avere 10.000, 100.000 o persino 1.000.000 di record. Quando qualcuno tenta di accedere, dovrai aprire un file che è ora di diverse centinaia di megabyte, caricarlo nella memoria del tuo programma, estrarre un array di informazioni di dimensioni simili e quindi scorrere centinaia di migliaia di record solo per trova l'unico record a cui vuoi accedere.

Un database adeguato ti permetterà di impostare indici su determinati campi nei record, permettendoti di interrogare il database e ricevere una risposta molto rapidamente, anche con enormi set di dati. Combinalo con qualcosa come Memcached , o anche un sistema di memorizzazione nella cache di home brew (ad esempio, archivia i risultati di una ricerca in una tabella separata per 10 minuti e carica quei risultati nel caso in cui qualcun altro cerchi la stessa cosa subito dopo), e avrai query incredibilmente veloci, qualcosa che non otterrai con un set di dati così grande quando stai leggendo / scrivendo manualmente su file.

Un'altra cosa vagamente correlata all'indicizzazione è il trasferimento di informazioni. Come ho detto sopra, quando hai file di centinaia o migliaia di megabyte devi caricare tutte queste informazioni in memoria, iterarle manualmente (probabilmente sullo stesso thread) e quindi manipolare i tuoi dati.

Con un sistema di database verrà eseguito sul proprio thread (s), o anche sul proprio server. Tutto ciò che viene trasmesso tra il programma e il server di database è una query SQL e tutto ciò che viene ritrasmesso sono i dati a cui si desidera accedere. Non stai caricando l'intero set di dati in memoria, tutto ciò che invii e ricevi è una piccola frazione del tuo set di dati totale.

Quando hai dati semplici, come un elenco di cose come descrivi nei commenti della tua domanda, un database SQL non ti darà molto. Molte persone li usano ancora, perché sanno che i loro dati possono diventare più complicati nel tempo e ci sono molte librerie che rendono banale lavorare con il database.

Ma anche con un semplice elenco che carichi, tieni in memoria, quindi scrivi quando necessario, può soffrire di una serie di problemi:

La chiusura anomala del programma può perdere dati o durante la scrittura dei dati su disco qualcosa va storto e si può finire per uccidere l'intero file. Puoi gestire i tuoi meccanismi per gestirlo, ma i database gestiscono questo per te usando tecniche comprovate.

Se i tuoi dati iniziano a crescere troppo e si aggiornano troppo spesso, la serializzazione di tutti i tuoi dati e il salvataggio diventeranno un grosso ostacolo per le risorse e rallenteranno tutto. Dovresti iniziare a capire come dividere le cose, quindi non sarà così costoso. I database sono ottimizzati per salvare solo le cose che cambiano su disco in modo tollerante agli errori. Inoltre sono progettati, in modo da poter caricare rapidamente i pezzetti di dati necessari in qualsiasi momento.

Inoltre, non è necessario utilizzare database SQL. Puoi usare i "database" NoSQL che molti fanno, basta usare JSON per archiviare i dati. Ma viene fatto in modo tollerante ai guasti e in un modo in cui i dati possono essere suddivisi, interrogati e suddivisi in modo intelligente tra più computer.

Inoltre, alcune persone mescolano le cose. Potrebbero utilizzare un archivio dati NoSQL come Redis per archiviare le informazioni di accesso. Quindi utilizzare database relazionali per archiviare dati più complessi dove devono fare query più interessanti.

Vedo molte risposte incentrate sul problema della concorrenza e dell'affidabilità. I database offrono altri vantaggi oltre a concorrenza, affidabilità e prestazioni. Consentono di non disturbare il modo in cui byte e caratteri sono rappresentati nella memoria. In altre parole, i database consentono al programmatore di concentrarsi su "cosa" piuttosto che su "come".

Una delle risposte menziona le domande. "Chiedere una domanda al database SQL" si adatta bene alla complessità di una domanda. Man mano che il codice si evolve durante lo sviluppo, semplici query come "recupera tutto" possono facilmente espandersi fino a "recuperare tutto dove proprietà1 è uguale a questo valore e quindi ordinare per proprietà2" senza preoccuparsi del programmatore di ottimizzare la struttura dei dati per tale query. Le prestazioni della maggior parte delle query possono essere accelerate creando un indice per una determinata proprietà.

Altro vantaggio sono le relazioni. Con le query è più semplice eseguire il riferimento incrociato di dati provenienti da set di dati diversi, quindi con loop nidificati. Ad esempio, la ricerca di tutti i post dei forum degli utenti con meno di 3 post in un sistema in cui utenti e post sono set di dati diversi (o tabelle DB o oggetti JSON) può essere eseguita con una singola query senza sacrificare la leggibilità.

Tutto sommato, i database SQL sono meglio degli array semplici se il volume dei dati può essere grande (diciamo più di 1000 oggetti), l'accesso ai dati in parti non banali e diverse parti dell'accesso al codice a diversi sottogruppi di dati.

TLDR

Sembra che tu abbia preso una decisione tecnica essenzialmente valida, a breve termine per l'archivio dati per la tua applicazione: hai scelto di scrivere uno strumento di gestione dell'archivio dati personalizzato.

Sei seduto su un continuum, con opzioni per spostarti in entrambe le direzioni.

A lungo termine, probabilmente (quasi, ma certamente non al 100%) vi troverete a trovarvi nei guai e potrebbe essere meglio passare all'utilizzo delle soluzioni di archivio dati esistenti. Esistono problemi prestazionali specifici, molto comuni, prevedibili, che sarai costretto a gestire e che stai meglio utilizzando gli strumenti esistenti invece di implementare i tuoi.

Sembra che tu abbia scritto un (piccolo) database personalizzato, integrato e utilizzato direttamente dalla tua applicazione. Suppongo che ti affidi a un sistema operativo e un file system per gestire la scrittura e la lettura del disco e trattare la combinazione come un archivio dati.

Quando fare quello che hai fatto

Sei seduto in un punto debole per l'archiviazione dei dati. Un archivio dati di sistemi operativi e file system è incredibilmente conveniente, accessibile e portatile multipiattaforma. La combinazione esiste da così tanto tempo che sei certo di essere supportato e far funzionare la tua applicazione su quasi tutte le configurazioni di distribuzione standard.

È anche una combinazione facile per cui scrivere codice: l' API è abbastanza semplice e di base e ci vogliono relativamente poche righe di codice per farlo funzionare.

In generale, è l'ideale per fare ciò che hai fatto quando:

• Prototipazione di nuove idee
• Creazione di applicazioni che è altamente improbabile che debbano essere ridimensionate, per quanto riguarda le prestazioni
• Vincolato da circostanze insolite, come la mancanza di risorse per l'installazione di un database

alternative

Sei su un continuum di opzioni e ci sono due "direzioni" che puoi seguire da qui, quello che io penso come "giù" e "su":

Giù

Questa è l'opzione meno probabile da applicare, ma è qui per completezza:

Puoi, se vuoi, andare giù , cioè bypassare completamente il sistema operativo e il file system e davvero scrivere e leggere direttamente dal disco. Questa scelta è generalmente pertinente solo nei casi in cui è richiesta un'estrema efficienza: pensate, ad esempio, a un dispositivo lettore MP3 minimale / minuscolo , senza RAM sufficiente per un sistema operativo completamente funzionante o a qualcosa come la Wayback Machine , che richiede una massa incredibilmente efficiente operazioni di scrittura dei dati (la maggior parte degli archivi di dati scambia scritture più lente per letture più veloci, poiché questo è il caso di utilizzo più comune per quasi tutte le applicazioni).

Su

Esistono diverse sottocategorie qui, ma non sono esattamente esclusive. Alcuni strumenti si estendono su entrambi, fornendo alcune funzionalità in ciascuno, alcuni possono passare completamente dal lavorare in una modalità all'altra e alcuni possono essere sovrapposti l'uno sull'altro, fornendo funzionalità diverse a diverse parti dell'applicazione.

Archivi di dati più potenti

Potrebbe essere necessario archiviare volumi sempre più elevati di dati, pur facendo affidamento sulla propria applicazione per gestire la complessità della manipolazione dei dati. È disponibile una vasta gamma di negozi di valori-chiave, con diverse dimensioni di supporto per le funzioni correlate. Gli strumenti NoSQL rientrano in questa categoria, così come in altri.

Questo è l'ovvio percorso su cui scalare quando quanto segue descrive la tua applicazione:

• È insolitamente pesante da leggere
• Stai bene negoziando prestazioni più elevate per garanzie di coerenza inferiori (a breve termine) (molte offrono "eventuale coerenza").
• Gestisce "direttamente" la maggior parte della manipolazione dei dati e la mancanza di coerenza (in pratica, probabilmente finirai per utilizzare inizialmente uno strumento di terze parti, anche se alla fine lo porterai nella tua applicazione o in un livello intermedio scritto personalizzato) .
• Stai cercando di ridimensionare in modo massiccio la quantità di dati che stai memorizzando e / o la tua capacità di cercarli, con requisiti di manipolazione dei dati "relativamente semplici".

C'è un po 'di spazio qui: puoi forzare una migliore coerenza della lettura, per letture più lente. Vari strumenti e opzioni forniscono API di manipolazione dei dati, indicizzazione e altre opzioni, che possono essere più o meno adatte per scrivere facilmente l'applicazione specifica. Quindi, se i punti sopra descritti descrivono quasi completamente la tua applicazione, potresti essere "abbastanza vicino" per lavorare con una soluzione di archiviazione dati più potente.

Esempi noti: CouchDB , MongoDB , Redis , soluzioni di archiviazione cloud come Microsoft Azure , Google App Data Store e Amazon ECE.

Motori di manipolazione dei dati più complessi

La famiglia di applicazioni di archiviazione dei dati "SQL", così come una serie di altre, sono meglio descritte come strumenti di manipolazione dei dati, piuttosto che motori di archiviazione puri. Forniscono una vasta gamma di funzionalità aggiuntive, oltre alla memorizzazione dei dati e spesso al di là di ciò che è disponibile nel lato archivio valori chiave delle cose. Ti consigliamo di seguire questo percorso quando:

• Devi assolutamente leggere la coerenza, anche se ciò significa che subirai un colpo di performance.
• Stai cercando di eseguire in modo efficiente manipolazioni di dati molto complessi - pensa a operazioni JOIN e UPDATE molto complesse, cubi di dati e slicing, ecc ...
• Stai bene scambiando la rigidità per le prestazioni (pensa a formati di archiviazione dati forzati e fissi, come le tabelle, che non possono essere modificati facilmente e / o in modo efficiente).
• Hai le risorse per gestire un insieme di strumenti e interfacce spesso più complessi.

Questo è il modo più "tradizionale" di pensare a un database o un archivio dati, ed è in circolazione da molto più tempo - quindi qui c'è molto che è disponibile e spesso c'è molta complessità da affrontare. È possibile, anche se richiede un po 'di esperienza e conoscenza e crea soluzioni semplici / evita gran parte della complessità - molto probabilmente finirai per utilizzare strumenti e librerie di terze parti per gestirne la maggior parte, però.

Esempi ben noti sono MySQL , SQL Server , Oracle's Database e DB2 .

Esternalizzare il lavoro

Esistono diversi e moderni strumenti e librerie di terze parti, che si interpongono tra gli strumenti di archiviazione dei dati e l'applicazione, per aiutarti a gestire la complessità.

Tentano inizialmente di eliminare la maggior parte o tutto il lavoro di gestione e manipolazione degli archivi di dati e, idealmente, consentono di effettuare una transizione graduale alla complessità solo quando e se necessario. Questa è un'area attiva di imprenditoria e ricerca, con alcuni risultati recenti che sono immediatamente accessibili e utilizzabili.

Esempi ben noti sono gli strumenti MVC ( Django , Yii ), Ruby on Rails e Datomic . È difficile essere onesti qui perché ci sono letteralmente dozzine di strumenti e librerie che fungono da involucri attorno alle API di vari archivi di dati.

PS: se preferisci i video al testo, potresti voler guardare alcuni dei video relativi al database di Rich Hickey; fa un buon lavoro nel chiarire la maggior parte del pensiero che va nella scelta, nella progettazione e nell'uso di un archivio dati.

Un file system si adatta alla descrizione di un database NoSQL, quindi direi che dovresti assolutamente considerare di usarlo quando decidi come archiviare i tuoi dati e non semplicemente scartarli a favore di RDBMS, come alcune risposte sembrano suggerire qui.

Un problema con i file system (e NoSQL in generale) è la gestione delle relazioni tra i dati. Se questo non è un grosso blocco qui, direi per ora saltare l'RDBMS. Ricorda anche i lati positivi dell'utilizzo di un file system come memoria:

• Amministrazione zero
• Bassa complessità, facile da configurare
• Funziona con qualsiasi sistema operativo, lingua, piattaforma, librerie ecc
• L'unica impostazione di configurazione è la directory
• Triviale da testare
• Triviale da esaminare con strumenti esistenti, backup, modifica ecc
• Buone caratteristiche prestazionali e ottimizzate dal sistema operativo
• Facile da capire per qualsiasi sviluppatore
• Nessuna dipendenza, nessun driver aggiuntivo
• Il modello di sicurezza è banale da capire ed è una parte base del sistema operativo
• I dati non sono accessibili dall'esterno

( fonte )

I file system sono un tipo di database. Forse non un RDBMS come tutti gli altri stanno parlando, ma sicuramente un DB nel senso più stretto. Fornisci le chiavi (nome del file) per cercare i dati (contenuto del file), che ha una memoria astratta e un'API con cui comunica il tuo programma.

Quindi, stai utilizzando un database. Gli altri post possono discutere delle virtù di diversi tipi di database ...

È necessario un database se si dispone di più processi (utenti / server) che modificano i dati. Quindi il database serve per impedire loro di sovrascrivere a vicenda le modifiche.

È inoltre necessario un database quando i dati sono più grandi della memoria. Oggi con la memoria che abbiamo a disposizione, ciò rende davvero obsoleto l'uso dei database in molte applicazioni.

Il tuo approccio è decisamente migliore dell'assurdità dei "database in memoria". Quali sono essenzialmente i tuoi approcci, ma con un sacco di spese generali aggiunte.

Dovresti sempre chiederti se una particolare applicazione necessita di un RDBMS. Troppe applicazioni sono costruite con un processo di progettazione che presuppone automaticamente tutti gli strumenti e i framework richiesti all'inizio. I database relazionali sono così comuni e molti sviluppatori hanno lavorato su applicazioni simili come prima, che vengono automaticamente inclusi prima dell'inizio del progetto. Molti progetti possono cavarsela, quindi non giudicare troppo duramente.

Hai iniziato il tuo progetto senza uno e funziona. È stato più facile per te farlo funzionare senza aspettare fino a quando non hai SQL. Non c'è niente di sbagliato in questo.

Man mano che questo progetto si espande e i requisiti diventano più complicati, alcune cose diventeranno difficili da costruire. Fino a quando non effettui ricerche e test su metodi alternativi, come fai a sapere qual è la migliore? Puoi chiedere ai programmatori ed eliminare le fiamme e "dipende" per rispondere a questa domanda. Una volta appreso, puoi considerare quante righe di codice sei disposto a scrivere nella tua lingua per gestire alcuni dei vantaggi di un database. Ad un certo punto, stai reinventando la ruota.

Facile è spesso relativo. Esistono alcuni framework in grado di creare una pagina Web e collegare un modulo a una tabella di database senza richiedere all'utente di scrivere alcun codice. Immagino che se si lotta con il mouse, questo potrebbe essere un problema. Tutti lo sanno, questo non è scalabile o flessibile perché Dio vieta di aver strettamente accoppiato tutto alla GUI. Un non programmatore ha appena costruito un prototipo; molti YAGNI possono essere trovati qui.

Se preferisci imparare un ORM manipolato dalla tua lingua preferita invece di apprendere l'SQL, provalo, ma prova a installare, crea una tabella ed estrai alcuni dati da un database popolare con SQL (Seleziona * Da; non è roba da capogiro). È facile da fare. Ecco perché qualcuno li ha creati in primo luogo. Non sembra un investimento così grande per prendere una decisione informata. Probabilmente potresti anche fare un test delle prestazioni.

Il salvataggio dei dati su disco IS sta scrivendo su un database, soprattutto se si inserisce ciascun oggetto nel proprio file con il nome del file come chiave per il record. E per ridurre al minimo i tempi di ricerca per la lettura del file, creare sottodirectory basate sui primi caratteri della chiave.

Ad esempio key = ghostwriter andrebbe in g / ho / stwriter.json o g / h / o / stwriter.json o g / ho / ghostwriter.json o g / h / o / ghostwriter.json. Scegli il tuo schema di denominazione in base alla distribuzione delle tue chiavi. Se sono numeri di sequenza, il 5/4/3 / 12345.json è migliore del contrario.

Questo è un database e se fa tutto ciò di cui hai bisogno, fallo in quel modo. Oggi sarebbe chiamato un database NoSQL come GDBM o Berkeley db. Così tante scelte Per prima cosa scopri di cosa hai bisogno, quindi crea una libreria di interfaccia per gestire i dettagli, magari un'interfaccia get / set come memcached o un'interfaccia CRUD, e poi sarai in grado di scambiare le librerie se devi cambiare il formato del database per uno con caratteristiche diverse.

Nota che alcuni database SQL come PostgreSQL e Apache Derby DB ti permetteranno di eseguire query SQL su molti formati NoSQL, inclusi i tuoi database nostrani. Non sono sicuro di MyBatis ma potrebbe essere simile.

Evitare l'hype NoSQL. Leggi le caratteristiche, testa le prestazioni e le capacità e poi scegli in base al grado di adattamento alle esigenze della tua applicazione.

http://www.hdfgroup.org/HDF5/ è ancora un altro formato di archivio dati interessante e ampiamente usato che le persone spesso non considerano.

Non appena i dati vengono aggiornati contemporaneamente, l'approccio che utilizza un database (potrebbe essere un database in memoria) sarà probabilmente più corretto e più performante, mentre allo stesso tempo il tuo codice rimarrà facile, perché semplicemente non hai preoccuparsi di aggiornamenti, transazioni, cache, I / O asincroni simultanei e tutto il resto.

È necessario un database per archiviare / recuperare i QA come quelli che pubblichiamo qui! Un semplice file non è in grado di organizzare i dati relativi a diversi argomenti.