php: file system <>db, casi e casi

[Uno]

Lo so che è vecchia, ma io non ho ancora le idee chiare e non avrei voglia di farmi mille benchmark, quindi se qualcuno ha dei dati da condividere mi farebbe un piacere.

Faccio qualche esempio:
E' più veloce leggere un array (per esempio un config) da file o da db?
E' più veloce caricare un'immagine da file system o da db?

Qualcuno afferma che è importante il numero di file per directory, cioè che fino a 100 file è più veloce il file system, sopra il db. Ma che in ricerca il numero di file è 30.

immagino che 100 si riferisca al fatto di usare il nome dei file come indice, mentre la ricerca intende in qualsiasi parola contenuta nei file...

Se così fosse avrebbe poco senso un sistema di cache che memorizza su file system le query più frequenti... a meno di limitare queste ad un numero inferiore ai 100.

Altro punto di vista interessante è il fatto che l'ottimizzazione lato programmazione se non è seguita da quella sistemistica conta poco poco.... però ora mi interessa vedere la prima, la seconda è discorso a parte.

Ho visto alcuni cms che usano mysql per far tutto, ma poi a seconda delle impostazioni (a tempo, su comando, ad aggiornamento) riproducono l'intero sito su file system e da quello viene letto alle richieste del browser.
Spazio a parte visti i presupposti sopra mi chiedo se è effetivamente più veloce....

Io sto pensando ad un sistema ibrido, una sorta di cache su mysql.
Cioè la pagina è spezzettata in vari punti del db per comodità organizzativa, poi però è messa in cachè in un unico campo in modo tale che con un'unica query sia richiamabile.
In sostanza un'unica pagina tra gestione ACl, contenuti e qualche altra cosa potrebbe stare entro le 2/3 query totali, neanche troppo complesse.

Sta parlando dell'organizzazione per siti ad alto traffico, ovviamente per 300 pagine non ha neanche senso perderci tempo

Commenti?

[TheDarkITA]

Ciao,

nelle tabelle con dimensioni grandi leggere i record non è proprio veloce come operazione... poichè in linea generale ne risentirà di ciò l'intero database, per i dati che vengono richiamati poco io preferisco metterli su file, e tutto il sito ha tempi di generazioni inferiori...

Però se fai un array con dimensione un 1000000, è sicuramente più veloce usare il db che scorrerti tutto l'array...

Da tenere in considerazione che un dato che in un database occupa una certa dimensione, se lo crei come file ha dimensioni molto maggiori...

Il db è certamente più facilmente gestibile di quanto lo sia con i file...

Secondo me dipende pure di che sito stiamo parlando, in un sito "statico" (per statico intendo che viene aggiornato 10 volte al giorno e resta tutto in quel modo) sicuramente conviene mettere su file dopo la prima elaborazione, piuttosto che rifare 3000 query, è molto più veloce.

Per me non c'è una soluzione che vada bene per tutti, ma bisogna analizzare bene la situazione per vedere cosa conviene...

[Uno]

Per me non c'è una soluzione che vada bene per tutti, ma bisogna analizzare bene la situazione per vedere cosa conviene...

In ogni caso grazie per la risposta, è sempre utile sentire cosa ne pensano gli altri e le loro esperienze.
In sostanza comunque alla fin fine quello che ho pensato cioè

Io sto pensando ad un sistema ibrido, una sorta di cache su mysql.
Cioè la pagina è spezzettata in vari punti del db per comodità organizzativa, poi però è messa in cachè in un unico campo in modo tale che con un'unica query sia richiamabile.
In sostanza un'unica pagina tra gestione ACl, contenuti e qualche altra cosa potrebbe stare entro le 2/3 query totali, neanche troppo complesse.

Mi sa che è la più concreta per i sistemi moderni.
Faccio fare il grosso del lavoro query solo quando si aggiorna qualcosa e poi rimane tutto aggregato in una specie di cache che con pochissime query veloci sforno. Non mi rompo le scatole con il file system (compresi prob di sicurezza) ma non ho bisogno di 10/15 query come vedo fare anche a sistemi blasonati.
E' pur vero che già solo il sistema di cache di mysql se attivato porta buoni benefici, ma penso che strutturare bene il tutto dall'inizio sia la miglior cosa.
Sulle immagini e gli allegati sono realmente indeciso....
Da una parte non mi andrebbe di caricarli sul db (penso ai backup per esempio, o al fatto che il software possa essere caricato su hosting con il db limitato) dall'altra sarebbe comodo.

Ascolto volentieri altri pareri/esperienze...

[ale]

Ascolto volentieri altri pareri/esperienze...

Già un po vecchio, ma i miei due cents sarebbero di usare il file system per l'immagine perché in generale sarà più veloce per il fatto che anche con un database il contenuto alla fine viene scritto sul disco ma con uno strato in più. Capisco cosa vuoi intendere con la comodità, ci sarebbe anche il motivo della integrità dei dati, ma - come hai scritto - c'è il backup, il carico non necessario sul database server etc.

Con dati "leggeri" come una lista/array, come un config, invece direi che è diverso, perché qui puoi anche utilizzare il database caching al massimo. Soprattutto quando si tratta di un config potresti utilizzare anche qui un file - particolarmente facile con PHP includendolo - ma un database è spesso più facile da gestire, anche come update.

Solo i miei two cents

[andrea.paiola]

per siti Web con pagine che hanno poche modifiche/interazioni col db la cosa migliore è generare le pagine statiche ( .html :P ) ovviamente ( quindi non siti di community, ecommerce eccetera... )

per quanto riguarda la questione db/filesystem si deve valutare in base ai tipi di dati ( i filesystem gestiscono molto meglio unità più grosse ) e alle operazioni che ci devi fare

[softhare]

Io posso solo dirti come mi regolo pe me e per i miei clienti.

Considerazioni generali:
a) il filesystem è mediamente molto più veloce di un server dbr (tant'è che anche memcache usa tale fatto per migliorare le prestazioni): si preferirà per ottenere prestazioni migliori in tutti i casi dove ciò è applicabile.
b) il server dbr è molto migliore nella ricerca dei dati, e quindi in generale sarà la scelta obbligata per archivi molto grandi nei quali si dovranno fare ricerche frequenti.
c) i file salvati nel filesystem sono passibili anche di utilizzi ulteriori (deepling, possibilmente autorizzato),
vengono gestiti meglio dai browser (cache, caricamento http della sola intestazione anzichè dell'intero file),
possibilità di gestione via ftp.
Ciò può essere un bene se se ne desidera una maggiore diffusione, un minore utilizzo della banda e delle risorse del server.
Viceversa puiò essere male se si desidera proteggere i dati (immagini, documenti) da deeplinking o download diretto.
Quindi si valuterà caso per caso quale è più indicato.

DATI TESTUALI:
Per i dati testuali, ovvvero i Record di Utenti, item, contenuti testuali di pagine dinamiche, dati testuali di immagini, media od allegati, mi regolo così:
- Se non servono funzioni di ricerca frequenti è meglio filesystem (meno operazioni da compiere sul server, tempi più brevi di servizio, utilizzi alternativi dei file).
- Se i record sono meno di duemila è meglio il filesystem creando magari un indice su un apposito file (ho gestio un negozio online con 1600 articoli senza nessuna difficoltà in tale modo).
- Se i record sono più di duemila o se si prevede di fare frequenti ricerche complesse allora è meglio il DBR.

FILE IMMAGINI, VIDEO, DOCUMENTI:
La quasi totalità dei file non testuali preferisco metterli nel filesystem (a meno che non desideri occultarli).
Se ai vari file vanno associate proprietà testuali (nome, descrizione, etc) allora questi ultimi dati potranno andare nel DBR.

ALTRI FATTORI:
Chiaramente altri fattori andranno tenuti in considerazione caso per caso:
- costo di storage filesystem vs dbr;
- server dbr sulla stessa macchina del server o su altra macchina;
- limiti di banda o di query per il dbr;
- complessità e frequenza delle ricerche da eseguire;
- complessità e frequenza delle modifiche da effettuare ai dati.