Cosa c'è di meglio / più veloce? MySql o FileSystem?

Immaginiamo un sito web che è una directory di persone. Per ogni persona potrebbero esserci una foto del profilo e una biografia.

Devo ammettere che le mie query SQL potrebbero essere migliori, ma in generale cosa sarebbe più veloce e utilizzare meno potenza di elaborazione.

Per verificare se esiste un file e quindi aprirlo o

controlla contro MySql per vedere se esiste una biografia e visualizzala.

Sono abbastanza sicuro che nel caso precedente il filesystem fumerà il database mysql.

Cosa succede se faccio del database un file txt delimitato di sola lettura?

Cosa c'è di più veloce in questo caso?

C'è un certo punto in cui se il file txt ha troppi record è meglio usare MySql?

Il file system è utile se stai cercando un determinato file, poiché i sistemi operativi mantengono una sorta di indice. Tuttavia, il contenuto di un file txt non verrà indicizzato, il che rappresenta uno dei principali vantaggi di un database. Un altro è comprendere il modello relazionale, in modo che i dati non debbano essere ripetuti più e più volte. Un altro è capire i tipi. Se hai un file txt, dovrai analizzare numeri, date, ecc.

Quindi - il file system potrebbe funzionare per te in alcuni casi, ma certamente non tutti.

Dipende davvero da cosa stai facendo. In generale, la velocità con cui è possibile aprire un file per la lettura sarà migliore della velocità con cui è possibile stabilire una connessione di rete. Quindi per operazioni molto semplici, il filesystem è decisamente più veloce. I filesystem probabilmente batteranno un RDBMS anche per il throughput di lettura non elaborato poiché c'è un sovraccarico. In effetti, se ci pensate, il database non può mai essere più veloce del filesystem su cui si trova in termini di throughput non elaborato.

Per operazioni molto complesse, è probabile che il filesystem sia molto lento. Per esempio:

Leggi 10 righe da questo file da 1 miliardo di righe, quindi cerca le righe corrispondenti in questo altro file. Mi dispiace se devi farlo. Un buon server di database ha tuttavia strategie per farlo velocemente e bene, quindi non stai reinventando la ruota.

Inoltre, devi davvero capire cosa stai facendo. Quali dati stai memorizzando? Come hai intenzione di trasformarlo? Se si tratta di file di immagini 100k, la soluzione sarà molto diversa rispetto a quella di una directory per 100k persone. (Forse LDAP? O un database SQL? Dipende da cosa stai facendo, forse.) La chiave qui è scegliere gli strumenti che corrispondono a quello che stai facendo e che ti danno spazio per aggiungere più usi, piuttosto che qualsiasi cosa sembri più veloce per alcuni caso d'uso piuttosto astratto. I database sono strumenti meravigliosi, ma non puoi ottenere una buona risposta a una domanda come questa.

Finalmente l'ottimizzazione prematura è la radice di ogni male. Scegli subito strumenti utili e scopri il resto in seguito.

Il file system inizialmente potrebbe essere più veloce, ma ne dubito. Tuttavia, con l'aumentare delle dimensioni dei dati, sarà probabilmente necessario ristrutturare il file system per mantenere le prestazioni. Oltre alla loro ovvia capacità di indicizzare su più attributi, i database tendono a ridimensionarsi meglio.

Le cache Web che funzionano in modo simile a ciò che si sta prendendo in considerazione utilizzano l'albero delle directory per mantenere le prestazioni. Inoltre tendono ad avere una scala relativamente fissa, quindi non devono fare i conti con una scala crescente.

Per questo tipo di applicazione vorrei iniziare con un database, poiché si adatta meglio alle tue esigenze. Si ridimensionerà molto meglio a lungo termine. Rispetto alla maggior parte dei file system, un database sarà anche più efficiente in termini di spazio.

Mi piace sempre visitare questi forum e leggere tutti i pesanti guru del database che il file system non può fare così velocemente come il database. Al contrario, un albero correttamente disposto, hashtable ben progettati e salvandoli come oggetto in un file produrranno le stesse velocità di un database e dai miei test. Una tabella hash e una directory progettate correttamente vinceranno ogni volta. Molto meno sovraccarico. Di recente mi sono allontanato dalla programmazione basata su database e altro ancora sull'albero dei file per semplicità e portabilità del programma. Nessun DB significa backup facile basta comprimere l'albero e andare. È molto bello e raccomandabile programmare in questo modo per i clienti che usano piccole applicazioni. Guarda l'immagine grande, ho il tempo di progettare il mio o semplicemente sfruttare quello che è già lì come il db. Personalmente mi piace salvare i miei oggetti su file e usarli in un secondo momento basta tenere d'occhio le dimensioni delle tabelle e esaminare l'utilizzo di un RandomAccessFile per essere in grado di cercare rapidamente disporlo come un database e suddividerlo in oggetti hashtable . Godere. Ricorda quali dati archiviati nel file consumeranno il doppio dell'utilizzo della memoria a volte in base al codice. La tabella hash stessa e in genere dove la usi per visualizzarla.