Download manager - cosa preferite?

[d@niele]

Originariamente inviato da daniele_dll
scusami, daniele, ma non ti seguo affatto ... secondo te un database, qualsiasi esso sia, non ha, per principio, limiti?

Hai mai considerato l'opzione che un filesystem è, +/- anche se specificatamente per i file e relativi metadata, un database?

Ho consigliato la suddivisione per il semplice motivo che 100 mila file, per fare un esempio, richiedono tempo, in base al filesystem, per effettuare ricerche e non ... ma lo stesso problema lo avrebbe, ad esempio, mysql se nel mezzo della tabella ci stasse un bel longblog e tutta una serie di campi text o mediumtext ^^

eeeh nn mi sentirei di paragonare un filesystem a un db come mysql, oracle, sql server. parlo per diretta esperienza avuta nell'archiviazione di centinaia di migliaia di fatture pdf in campi blob precedentemente storati in filesystem

con un tunning deciso (formattazione del db ad hoc , datamodel come si deve per separare il piu possibile blob da campi text, ecc ecc) la resa che può dare un db è infinitamente superiore, imparagonabile a una di filesystem.
ok può avere dei limiti ma aggirabili, con esempio un architettura a cluster.

[MicheleWT]

sono riuscito a creare uno split.

Le immagini saranno prese da filesystem mentre i file per le aree di download li posso inserire su database.

In quest'ottica come è meglio fare per realizzare un download manager da database?

Ora sto studiando i campi blob che fino ad ora non avevo mai utilizzato.

quindi diciamo che una tabella files può avere i seguenti campi?

id, name_it, description_it, category_id, blob, data, login_check

mi potete consigliare su come impostare il lavoro e se avete qualche accorgimento da prendere per avere un risultato migliore? quello che voglio è arrivare a sviluppare è un modulo che gestisca i download multi categoria (quindi categorie e sotto categorie) che impedisca il download diretto con link ecc e che controlli se è stato effettuato il login solo per i file che lo richiedono.

conoscete una buona guida che spiega come usare i campi blob in mysql per gestire i file? sto guardando un pò in giro ora

[daniele_dll]

Originariamente inviato da d@niele
con un tunning deciso (formattazione del db ad hoc , datamodel come si deve per separare il piu possibile blob da campi text, ecc ecc) la resa che può dare un db è infinitamente superiore, imparagonabile a una di filesystem.
ok può avere dei limiti ma aggirabili, con esempio un architettura a cluster.

scusami eh, ma fammi dire che chi ha configurato la macchina allora l'ha configurata male o, alternativamente, ha usato windows

ci sono filesystem come XFS e JFS, o anche i non più recenti ext3 o reiserfs 3, che rendono MOLTO bene anche sotto estremo stress

considera che le richieste del database passano COMUNQUE dal filesystem (in realtà ci sono rdbms avanzati che accedono direttamente alla partizione o al disco ma sono pochi e costano abbastanza) ed hai un inutile strato aggiuntivo per certe situazioni

Inoltre non credo che "l'archiviazione centinaia di migliaia di file pdf" possa darti piena conoscenza dell'architettura e della struttura di un filesystem

Prenditi in mano un libro che parla dell'architettura dei filesystem, un pò di documentazione su ext3 o reiserfs, giusto per evitare roba troppo complicata, o anche la semplice fat12/16/32 come punto di partenza, e ti accorgerai che un filesystem non è altro che un database strutturato per fare una specifica cosa ... gestire file con tutto quello che comporta

[xnavigator]

Originariamente inviato da d@niele
assolutamente si!
ovvio che si deve avere una dimestichezza nell uso dei Db...se nn la si ha il filesystem sembra sicuramente piu facile da gesitre ma nn è cosi

senza tralasciare i limiti fisici che un filesystem ha, dalla letture al numero di file archiviabili alla grandezza.....piu grande sono i file peggio è! a differenza del db che di questi problemi nn ne ha

ma quali limiti ma di cosa parli?

i file su database sono salvati su filesystem.. e per file di grosse dimensione e meglio saltare il apssaggio mysql->filesystem e andare direttamente al filesystem

(ripeto per file di piccola dimensione il campo blob va ancora bene)

...

[MicheleWT]

quindi alla fine è meglio usare file su filesystem?

conoscete un tutorial di download manager sviluppato in questa ottica in php?


a che pro in questo modo usare i campi blob? solo per i file che vengono uploadati dagli utenti come foto di profili, etc?

[d@niele]

Originariamente inviato da daniele_dll
scusami eh, ma fammi dire che chi ha configurato la macchina allora l'ha configurata male o, alternativamente, ha usato windows

ci sono filesystem come XFS e JFS, o anche i non più recenti ext3 o reiserfs 3, che rendono MOLTO bene anche sotto estremo stress

considera che le richieste del database passano COMUNQUE dal filesystem (in realtà ci sono rdbms avanzati che accedono direttamente alla partizione o al disco ma sono pochi e costano abbastanza) ed hai un inutile strato aggiuntivo per certe situazioni

Inoltre non credo che "l'archiviazione centinaia di migliaia di file pdf" possa darti piena conoscenza dell'architettura e della struttura di un filesystem

Prenditi in mano un libro che parla dell'architettura dei filesystem, un pò di documentazione su ext3 o reiserfs, giusto per evitare roba troppo complicata, o anche la semplice fat12/16/32 come punto di partenza, e ti accorgerai che un filesystem non è altro che un database strutturato per fare una specifica cosa ... gestire file con tutto quello che comporta

qundi mi stai facendo capire che un filesystem "basta e avanza" per archiviare milioni di file? bello allora niente piu campi blob! vallo a dire alle aziende che spendono centinaia e centinaia di euro per archiviare i dati in DB quando un bel filesystem risolverebbe tutti i loro problemi

scherzi a parte, senza rispondere alle polemiche, come storage di archiviazione nulla è piu performante di un db per archiviare grandi quantita di dati, per facilitarne richiesta, ottimizzazione, ecc

mi spieghi come potrebbe esser scalare l archviazione su filesystem? come la ottimizzeresti? come garantiresti l integrità?

se dici che il filesystem può esser utilizzato (e anche con ottimi risultati) per archiviare dati va benissimo, ma il confronto con DB nn lo regge

spero in una risposta seria e non in un "vatti a leggere un libro", per risposte cosi vado su altri forum

[d@niele]

Originariamente inviato da xnavigator
ma quali limiti ma di cosa parli?

i file su database sono salvati su filesystem.. e per file di grosse dimensione e meglio saltare il apssaggio mysql->filesystem e andare direttamente al filesystem

(ripeto per file di piccola dimensione il campo blob va ancora bene)

...

be studia un po poi ne riparliamo......ti serve un bicchiere di latte?

[MicheleWT]

insomma database vs filesystem

sto leggendo molto e sembra che il conflitto tra i due mondi sia acceso da anni senza accennare a diminuire.

QUI viene detta cosa: database per applicazioni con pochi file e poco traffico, filesystem per le cose più impegnative.

accenna anche a soluzioni miste, usare il database per la sua portabilità ma richiamare i file nella cache del filesystem per goderne dei vantaggi.

che ne dite?

[MicheleWT]

ah un'altra cosa, e in termini di sicurezza cosa ritenete migliore database o filesystem?

e cosa usate dal quel punto di vista per i vostri upload/download.

non vorrei che con malware venga inserito con upload nella cartella download.

[daniele_dll]

Originariamente inviato da d@niele
qundi mi stai facendo capire che un filesystem "basta e avanza" per archiviare milioni di file? bello allora niente piu campi blob! vallo a dire alle aziende che spendono centinaia e centinaia di euro per archiviare i dati in DB quando un bel filesystem risolverebbe tutti i loro problemi

ci sono anche grosse aziende che spendono (o buttano) soldi per usare phpnuke, ma non per questo in automatico diventa la strada migliore

spesso le aziende più grosse cercano il modo più economico di fare le cose (spesso != sempre)

scherzi a parte, senza rispondere alle polemiche, come storage di archiviazione nulla è piu performante di un db per archiviare grandi quantita di dati, per facilitarne richiesta, ottimizzazione, ecc

allora, partiamo dal fatto che per poter essere più veloce devi, obbligatoriamente, escludere lo strato che si interfaccia con il filesyste, altrimenti avresti un oneroso rallentamento, e di conseguenza hai necessità di un rdbms di fascia alta che fa volare i costi verso l'alto

mi spieghi come potrebbe esser scalare l archviazione su filesystem? come la ottimizzeresti? come garantiresti l integrità?

quale sarebbe il problema della scalabilità, scusa? esistono filesystem come GFS o OCFS2 ed altri software come DRBD che insieme ad LVM2 (se proprio lo vogliamo buttare nella mischia) ti fanno TUTTO quello che ti serve senza il benché minimo problema

Senza considerare che, dato che stanno su disco, la possibilità di acquisire il fila da uno storage specifico non lo vieta nessuno riducendo ancora di più i costi del software e dell'hardware: non hai più tutto come una unità logica ma hai strutture separate per lo storage! Se hai 10TB di roba, ed ogni storage (almeno 2 macchine in mirror per 1TB) tiene un TB di spazio sul database non devi fare altro che segnare dove sta il dato file ... in questo modo decentralizzi la struttura, la rendi veramente scalabile ma soprattutto la ripieghi come vuoi tu

se dici che il filesystem può esser utilizzato (e anche con ottimi risultati) per archiviare dati va benissimo, ma il confronto con DB nn lo regge

spero in una risposta seria e non in un "vatti a leggere un libro", per risposte cosi vado su altri forum

mi spiace, ma se ti ostini a dire che, strutturalmente, un filesystem ed un database non c'hanno niente a che fare solamente questa può essere la mia risposta.

Pure la FAT(12/16/32) ha, per forza di cosa, la struttura di un database, seppur estremamente banale: tabelle con elenco dei file, tabelle dei cluster occupati, meta dati sulla struttura, e poi i dati veri e propri