node.js è adatto per l'elaborazione in background?

10

Sto lentamente imparando node.js e ho un piccolo progetto che voglio iniziare. Il progetto avrà molti processi in background (scaricamento di dati da siti esterni, analisi di file CSV, ecc.).

Una grande "vittoria" per me e per il nodo è il fatto che utilizza JavaScript sia per il client che per il server. Io codice in Java e JavaScript nel mio lavoro diurno, ma sono anche abbastanza bravo in Ruby.

Ma, come ho detto, sembra interessante usare una lingua ovunque e JS sembra adattarsi a quella proposta.

Tuttavia, non ho avuto molta esperienza nell'uso di JS per l'esecuzione di processi in background. Ruby sembra eccellere in questo. E non sono contrario a usarlo. Allora, quali sono i tuoi pensieri su come andare al 100% JS per questo? Realizzo progetti molto grandi richiedono soluzioni personalizzate. Mi sto solo chiedendo se ne valga la pena. Oppure, dovrei limitarmi a Ruby con quel tipo di faccende?

Le opinioni sono state apprezzate.

Grazie

    
posta cbmeeks 17.07.2013 - 21:18
fonte

4 risposte

13

È particolarmente efficace nel gestire una tonnellata di I / O di file e mi aspetto che gestisca anche un sacco di comunicazioni di rete. Sembra particolarmente popolare per le app basate su socket. La cosa importante da tenere a mente è che se le tue esigenze non sono soddisfatte dalle librerie esistenti (ce ne sono molte) potresti aver bisogno di immergerti in una C che può essere associata ai comandi JS. È anche possibile generare processi Node aggiuntivi, ma sospetto che fare un sacco di quello che potrebbe diventare tassativo (presumo - potrebbe essere sbagliato - c'è un'istanza V8 generata per ognuno di questi).

JS è single-threaded e blocking, il che significa che nient'altro può essere eseguito fino al completamento di una chiamata di funzione. Questa era una caratteristica desiderata di JS, essenzialmente prendendo tutte le preoccupazioni di threading e accodamento dalle tue mani. Il JS non impedisce al materiale C / C ++ di funzionare in un modo più multi-thread sotto il cofano, quindi il ruolo di JS è davvero più architettura / messenger. Se stai elaborando le immagini, non vorrai gestirle con i comandi sincroni di JavaScript, perché tutto il resto della tua app o del tuo server verrà bloccato fino al completamento. L'idea è che tu richieda che un'immagine venga elaborata dalla funzionalità C / C ++ associata e poi risponda all'evento 'done' quando l'immagine è finita in fase di elaborazione.

Ciò richiede che il JS in qualsiasi app Node.js sia pesantemente supportato da eventi e callback o che probabilmente funzionerà molto male. Quindi non vedrai molte chiamate al metodo in Node che non ricevono una funzione per un uso successivo. Una cosa che diventa molto chiara in Node è che ti trovi in un mondo di brutti se non trovi un modo per gestire la piramide del callback. per es.

//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
    e.fileObj.find('some snippet', function(e){
        someFinalCallBackHandler( e.snippetLocations );
    } );
} );

Fortunatamente ci sono molti strumenti ed esempi là fuori per gestirlo meglio. La maggior parte tende a ruotare intorno a meccanismi di promessa e semplicemente a concatenare una serie di funzioni pensate per rispondere ai reciproci stati di callback in un array che fa la brutta piramide per te sotto il cofano.

Personalmente, mi fa impazzire l'amore che otteniamo JS ad alto livello e C / C ++ più vicino al cromo. È l'ultima combo e mi ha ispirato a iniziare a imparare C. E non lasciare che la mancanza di potenziale della biblioteca ti faccia impazzire finché non hai fatto qualche ricerca. Le librerie dei nodi vengono prodotte a un ritmo molto rapido e stanno maturando molto rapidamente. Se non stai facendo nulla di molto insolito, le probabilità sono buone, qualcuno lo ha coperto.

La più grande differenza rispetto a Rails è che JS non è mai probabile che si trovi su binari. Tendiamo a codificarci per poterlo avere, ma lo vuoi molto rapidamente, quindi c'è la corda per impiccarti con il fattore e l'architettura è stata abbastanza fai-da-te in JS fino agli anni più recenti. Lo chiamo libertà, ma mi rendo conto che non è visto come ideale per molti sviluppatori.

Inoltre, non avrai mai un problema "gemma" in Node.js perché hai provato a installare su qualcosa di diverso da un Mac. Gli sviluppatori Web sul lato client disprezzano i problemi di dipendenza ed è da lì che proviene un sacco di core di Node. Se non funziona fuori dalla scatola in 5 minuti o meno su ogni piattaforma popolare, generalmente la accartocciamo e la lanciamo. Devo ancora imbattersi in un modulo popolare che richiede che io faccia qualcosa di speciale per farlo funzionare. Il sistema dei pacchetti è eccellente.

Ma per rispondere alla tua domanda principale più esplicitamente / sinteticamente: Funziona bene con i processi in background?

Sì, il nodo è fondamentalmente un processo in background con un mezzo per guidare un'applicazione tramite eventi e callback.

    
risposta data 17.07.2013 - 21:38
fonte
2

Un problema da tenere presente è ciò che si verifica quando elabora file di grandi dimensioni in un ambiente asincrono : se il flusso di input (un file) è più veloce del flusso di output (il db), non sarete in grado di gestire gli eventi dei dati di input abbastanza velocemente. Ciò può sopraffare parte del tuo sistema (flusso di output o memoria) o causare la perdita di dati. Per questo motivo, l'elaborazione dei dati in modo asincrono può essere un po 'complicato. Tuttavia, come spiega l'articolo che ho collegato, la possibilità di mettere in pausa il flusso di input consente di accelerare in un modo che si adatta alla tua situazione.

    
risposta data 13.02.2014 - 22:22
fonte
1

Node.js eccelle nell'IO. È molto improbabile scoprire un giorno che il tuo processo si sia inceppato poiché la maggior parte dei tuoi thread sta bloccando le chiamate SQL.

Tuttavia node.js è veramente non valido durante il lavoro legato all'elaborazione. Quando sento "un sacco di IO", penso "sì! Vai al nodo!", Ma quando sento "analizzare", esito un po '. Non sono sicuro che se questo è per qualsiasi motivo, oltre alla gente non il nodo multithreading correttamente, ma finora tutto il lavoro legato al calcolo del mio prodotto avviene al di fuori del nodo.

Il multithreading in node.js è difficile da configurare correttamente. Tutto è singolo threaded per impostazione predefinita e la maggior parte del codice viene scritto in base al presupposto che verrà eseguito solo sotto un thread. Dovrai certamente utilizzare i domini per evitare che un errore su un thread possa far cadere l'intera applicazione.

Si noti inoltre che il nodo potrebbe essere un po 'più debole in alcune funzionalità aziendali. Ad esempio, le sue librerie di registrazione non sono paragonabili a quelle di Java. Al momento non esiste un buon framework di registrazione che supporti anche MDC, il che significa in pratica che si ottiene molto del var logPrefix = userId + ": " .

Inoltre non ho mai eseguito un repository privato di npm, potresti aver bisogno di uno di questi a seconda che il tuo codice sia proprietario.

    
risposta data 17.07.2013 - 22:39
fonte
1

Se i tuoi processi in background possono essere eseguiti in sequenza, può essere abbastanza buono. Nella mia ultima posizione, ho dovuto scrivere una serie di pre-processori, esportazioni e programmi di traduzione per molte fonti di dati. L'utilizzo di NodeJS è stato un gioco da ragazzi qui.

Se non stai facendo un lotto di elaborazione del calcolo, la semplice manipolazione di stringhe corte e l'analisi di interi non è così male, se hai bisogno di manipolare le immagini, probabilmente non è il miglior strumento (anche se ci sono wrapper e moduli richiamabili che possono funzionare bene).

Consigli, attenersi ai moduli che utilizzano i flussi. In questo modo è più semplice canalizzare l'elaborazione su moduli per quel particolare passaggio. Se osservi come flusso di eventi viene utilizzato in gulp-jade per lo strumento gulp build per esempio, puoi vedere quanto è capace.

Per CSV, puoi utilizzare node-csv , che è abbastanza buono per stabilire una base per le connessioni registra su un flusso di processore.

Per XML di grandi dimensioni, in cui si desidera eseguire un singolo record alla volta, vorrei dare un'occhiata a node-halfstreamxml che legge il flusso XML utilizzando un processore SAX e genera eventi per ciascun nodo. Vorrei inserirlo in un flusso di lettura / scrittura in modo da poter aumentare le partite desiderate. Molti parser di oggetti xml nel nodo cercheranno di leggere / analizzare l'intero xml in una volta, e per esempio 100mb di xml che diventa enorme ... dove halfstreamx leggerà come un flusso.

NOTA: ci sono altri processori come xml-stream che useranno expat (libreria C) sotto, che può dare più prestazioni, ma meno portabili senza un ambiente di sviluppo.

In generale, è stato un vero piacere usare ...

    
risposta data 25.07.2013 - 00:56
fonte

Leggi altre domande sui tag