È una cattiva idea sincronizzare il file system con il server remoto usando HTTP?

Question

È una cattiva idea sincronizzare il file system con il server remoto usando HTTP?

#1 da (2 voti)
#2 da (2 voti)

4

Ho avviato un progetto che duplicherà il comportamento di Dropbox o Google Drive ma utilizzando Amazon S3 az un back-end.

L'idea è molto semplice, un server Node.js che guarda una directory per le modifiche ai file e li mette sull'S3. O guarderà S3 per le modifiche e le applicherà alla struttura del file system. Ho caricato la prima versione della mia app su Github. Puoi trovarlo qui .

Poiché sono uno sviluppatore web, sto utilizzando le tecnologie web per risolvere il problema. Ho paura della mia mentalità limitata e della scelta di strumenti sbagliati per il lavoro. Esistono altre soluzioni a questo problema. Uno è S3FS che è un file system FUSE per sistemi Unix. Secondo me è molto difficile da usare e limitato alla piattaforma. La mia soluzione utilizza Node.js per superare i problemi multipiattaforma. Posso imballare la mia app Node.js con App.js e renderla un software facile da usare.

Per chiarire, le mie domande sono:

HTTP / HTTPS è abbastanza buono per il trasferimento di file?
Node.js è abbastanza buono per lavorare con File System?
Scalabilità: questo approccio può fallire in file di grandi dimensioni?

file-systems synchronization development-approach

posta Mohsen 25.04.2013 - 03:47

fonte

2 risposte

2

HTTP / HTTPS è abbastanza buono per il trasferimento di file?

Molte applicazioni si basano su HTTP / HTTPS per i trasferimenti di file, il miglior esempio è mega.com. Così come hai detto potrebbero esserci modi migliori per mantenerlo sincronizzato, ma non è assolutamente sbagliato usare HTTP / HTTPS per i trasferimenti di file.

Node.js è abbastanza buono per lavorare con File System?

Node.js è un sistema davvero eccezionale e, naturalmente, è possibile risolvere il problema, ma è ancora il modo migliore per risolverlo? "Un'applicazione di sincronizzazione dedicata come S3FS ti impedisce sicuramente di fare alcuni grossi errori.

Scalabilità: questo approccio può fallire in file di grandi dimensioni?

Non so come stai facendo lo scambio di file, ma penso a due problemi più comuni: Troppa memoria (se carichi tutto il file in memoria) e timeout, se il download richiede troppo tempo o la connessione è interrotta.

risposta data 25.04.2013 - 08:21

fonte

Leggi altre domande sui tag file-systems synchronization development-approach

Approcci per la memorizzazione e l'analisi di grandi quantità di dati basati sul tempo Elaborazione batch continua in Java

score 2 · Accepted Answer

Because I am a web developer, I am using web technologies to solve the problem. I'm afraid of my limited mindset and picking wrong tools for the job.

Stai cadendo nella trappola "quando tutto quello che hai è un martello, tutto sembra un chiodo". Ma sei in grado di riconoscerlo, che è un'ottima cosa.

Is HTTP/HTTPS good enough for file transfer?

Naturalmente. Miliardi, se non miliardi, di file vengono trasferiti via HTTP giornalmente. Qualsiasi file trasferito su S3 andrà in questo modo.

Is Node.js good enough for working with File System?

Non conosco molto su Node.js, ma se il tuo obiettivo è semplicemente avere un programma standalone che gira su una macchina e mantiene sincronizzati una directory e S3, non sembra il giusto strumento per il lavoro.

Se sei disposto ad imparare Java, il file system virtuale di Apache Commons può parlare con una varietà di backend (incluso il file system locale) e VFS-S3 è un componente aggiuntivo che funziona con S3. VFS include una classe chiamata AbstractSyncTask che richiede cura il 90% del lavoro sporco, lasciandoti solo estendere la classe e implementare le tue regole di trasferimento. Essendo Java, funzionerà ovunque Java.

Scalability: can this approach fail in large file sizes?

Ciò dipenderebbe dai limiti di Node.js, anche se sarei sorpreso se qualcuno non si fosse già imbattuto in quel problema e si fosse assicurato che potesse trasferire file di lunghezza arbitraria.