Database per sito di file hosting

[Heretic Curse]

Salve, vorrei mettere su un sito di file hosting specializzato in schemi di circuiti elettrici, modelli di stampa per stampanti 3D e simili. A grandi linee conosco MySQL, però non oltre le sue linee essenziale, quindi vorrei sapere cosa devo conoscere per poter creare ciò che ho in mente.
Vorrei inoltre creare un sistema di ricerca per questo sito, in modo da rendere il reperire file molto più semplice di come è necessario fare attualmente in siti come mega ecc; potrei essere in grado di realizzare ciò utilizzando qualche specifica libreria di python?

Grazie in anticipo :)

[lorenzo.c]

Molto a grandi linee dovresti conoscere un database relazionale e un linguaggio di programmazione adatto per il web, come PHP o appunto Python, ed eventualmente dei framework a partire dai quali sviluppare la tua applicazione. Per la ricerca, SQL offre le sue funzionalita' (es. funzione LIKE (http://www.html.it/articoli/ricerche-con-mysql-2/)).

[Heretic Curse]

Ottimo, grazie mille. Qualche lettura consigliata?

[Tasslehoff]

La cosa che vuoi realizzare non è banale ne semplice imho.
Potrà sembrarlo per piccoli numeri (del resto che ci vuole? Un webserver che permette di uplodare e scaricare un binario...) ma crescendo imho diventa ingestibile, te lo dico per esperienza dato che per lavoro mi sono ritrovato per le mani repository di file gestiti male diventati pressochè inusabili, l'ultimo un volume da 3.3TB composto da 9 lun distribuite su due diverse san e aggregate con lvm, milioni di file con una dimensione media di circa 300KB distribuiti di centinaia di migliaia di directory, un incubo che impediva manutenzione dei filesytem (un fsck in sola lettura richiedeva giorni) e backup (archive una tantum abortito dopo una settimana).

Visto che chiedi info sul database mi vien da pensare se tu stia ipotizzando di salvare i file come blob, soluzione che imho presenta più ombre che luci e che alla lunga renderebbe ingestibile il db.
Io userei un filesystem con checksumming (es btrfs o zfs) e features avanzate (snapshot, ridimensionamento dei volumi a caldo etc etc), oppure un filesystem distribuito tipo Glusterfs (ci sono case di filesystem gluster arrivati a dimensioni considerebili di diversi petabyte).

Anche la componente applicativa di upload e download non è banale, se usi del banale codice php dovrai scontrarti con i soliti limiti di upload e post tipici di questo linguaggio di scripting, magari in java (o altri linguaggi più evoluti) potresti riuscire a costruire qualcosa di più sofisticato ed efficiente.
Pensa anche soltanto ai problemi legati ai permessi, alla gestione della autenticazione e autorizzazione (due concetti molto diversi che spesso vengono banalmente ed erroneamente sovrapposti), oppure alla logica di archiviazione (buttare brutalmente in una directory renderebbe il servizio inutilizzabile crescendo).

Per la ricerca puoi sfruttare progetti come Apache Lucene o Solr che di fatto sono il punto di riferimento nel campo dei servizi di indicizzazione e ricerca in ambito open.

Ti ripeto, la cosa che vuoi realizzare non è affatto banale, ed è il tipico progetto che deve partire subito bene e con una forte attività di analisi, perchè correggere in corso d'opera diventerebbe un bagno di sangue.
Come avrai immaginato (vedo che non l'hai citato) l'hardware in questi casi è l'ultimo dei problemi (e a ben vedere è così in quasi tutti gli scenari).

[lorenzo.c]

Ottima risposta di Tasslehoff, in effetti io avevo in mente qualcosa di infinitamente piu' piccolo (sotto le migliaia di record, credo)... non mi sono mai trovato a lavorare su progetti con archivi cosi' grandi. :)

[Heretic Curse]

La cosa che vuoi realizzare non è banale ne semplice imho.
Potrà sembrarlo per piccoli numeri (del resto che ci vuole? Un webserver che permette di uplodare e scaricare un binario...) ma crescendo imho diventa ingestibile, te lo dico per esperienza dato che per lavoro mi sono ritrovato per le mani repository di file gestiti male diventati pressochè inusabili, l'ultimo un volume da 3.3TB composto da 9 lun distribuite su due diverse san e aggregate con lvm, milioni di file con una dimensione media di circa 300KB distribuiti di centinaia di migliaia di directory, un incubo che impediva manutenzione dei filesytem (un fsck in sola lettura richiedeva giorni) e backup (archive una tantum abortito dopo una settimana).

Visto che chiedi info sul database mi vien da pensare se tu stia ipotizzando di salvare i file come blob, soluzione che imho presenta più ombre che luci e che alla lunga renderebbe ingestibile il db.
Io userei un filesystem con checksumming (es btrfs o zfs) e features avanzate (snapshot, ridimensionamento dei volumi a caldo etc etc), oppure un filesystem distribuito tipo Glusterfs (ci sono case di filesystem gluster arrivati a dimensioni considerebili di diversi petabyte).

Anche la componente applicativa di upload e download non è banale, se usi del banale codice php dovrai scontrarti con i soliti limiti di upload e post tipici di questo linguaggio di scripting, magari in java (o altri linguaggi più evoluti) potresti riuscire a costruire qualcosa di più sofisticato ed efficiente.
Pensa anche soltanto ai problemi legati ai permessi, alla gestione della autenticazione e autorizzazione (due concetti molto diversi che spesso vengono banalmente ed erroneamente sovrapposti), oppure alla logica di archiviazione (buttare brutalmente in una directory renderebbe il servizio inutilizzabile crescendo).

Per la ricerca puoi sfruttare progetti come Apache Lucene o Solr che di fatto sono il punto di riferimento nel campo dei servizi di indicizzazione e ricerca in ambito open.

Ti ripeto, la cosa che vuoi realizzare non è affatto banale, ed è il tipico progetto che deve partire subito bene e con una forte attività di analisi, perchè correggere in corso d'opera diventerebbe un bagno di sangue.
Come avrai immaginato (vedo che non l'hai citato) l'hardware in questi casi è l'ultimo dei problemi (e a ben vedere è così in quasi tutti gli scenari).

Ti ringrazio per l'esauriente risposta. Comunque sia si, presupponevo già sarebbe stato un lavoraccio, ma anche per questo mi attrae. In più credo potrebbe risultare davvero utile.
Java dici? Grazie per il consiglio.
Vedrò di organizzarmi il meglio possibile :)

[malatodihardware]

Tutto ma non Java per favore.. Soprattutto nei browser è veramente una rovina secondo me. Io starei su PHP o ASP

Inviato dal mio Nexus 5 con Tapatalk

[lorenzo.c]

Tutto ma non Java per favore.. Soprattutto nei browser è veramente una rovina secondo me. Io starei su PHP o ASP

Inviato dal mio Nexus 5 con Tapatalk

Penso intendesse lato server... spero :D

[Tasslehoff]

Penso intendesse lato server... spero :DAssolutamente sì, niente robaccia che gira lato client :)

Cmq il mio non voleva essere un invito a sviluppare tutto in java a prescindere, non sono uno sviluppatore quindi non conosco ne le classi ne le features di java nell'interazione con le periferiche di I/O.
I due progetti che citavo per il motore di indicizzazione e ricerca sono prodotti java, ma nulla vieta di sviluppare l'applicazione con qualsiasi linguaggio (da php a .net a ruby o perl o qualsiasi altro) e poi utilizzare Lucene come motore di ricerca, del resto la ricerca è una form la cui action può puntare ovunque, anche un application server Tomcat dove gira una web application che sfrutta Lucene (da un cliente mi è capitato proprio questo su un portalino fatto con Joomla).

[malatodihardware]

Non mi occupo neanche io di sviluppo back-end (solo un po di front-end), ma da quello che ho visto nello sviluppo di applicazioni desktop (per hobby ho usato diversi linguaggi) Java è decisamente il meno ottimizzato, l'unico vantaggio che ci vedo è il multiplatform.
Chiuso il piccolo OT, spero che invece lato server sappia offrire qualcosa in più..
Prova a vedere anche node.js ultimamente ci stanno facendo di tutto (non ho idea però delle performance)

Inviato dal mio Nexus 5 con Tapatalk

[lorenzo.c]

nulla vieta di sviluppare l'applicazione con qualsiasi linguaggio (da php a .net a ruby o perl o qualsiasi altro) e poi utilizzare Lucene come motore di ricerca, del resto la ricerca è una form la cui action può puntare ovunque, anche un application server Tomcat dove gira una web application che sfrutta Lucene (da un cliente mi è capitato proprio questo su un portalino fatto con Joomla).

Ho notato che la cosa bella di Lucene e' che si integra con tutto... puo' indicizzare anche MySQL: http://www.lucenetutorial.com/techniques/indexing-databases.html
Sullo stesso sito c'e' anche un'introduzione carina ("Lucene in 5 minutes"). :)

[Heretic Curse]

Beh, ho scoperto che hackaday ha già realizzato qualcosa di simile (se non migliore) a quello che avevo in mente :)