O node.js é um bom ajuste para o processamento em segundo plano?


10

Estou aprendendo lentamente node.jse tenho um pequeno projeto que quero começar. O projeto terá muitos processos em segundo plano (download de dados de sites externos, análise de arquivos CSV etc.).

Uma grande "vitória" para mim e para o nó é o fato de usar JavaScript para cliente e servidor. Eu codigo em Java e JavaScript no meu trabalho diário, mas também sou muito bom em Ruby.

Mas, como eu disse, parece atraente usar um idioma em todos os lugares e o JS parece se encaixar nesse projeto.

No entanto, não tive muita experiência no uso de JS para executar trabalhos em segundo plano. Ruby parece se sobressair nisso. E eu não sou contra usá-lo. Então, o que você pensa em usar 100% de JS para isso? Percebo que projetos muito grandes exigem soluções personalizadas. Só estou me perguntando se vale a pena o esforço. Ou devo ficar com Ruby nesse tipo de tarefa?

Opiniões apreciadas.

obrigado


Você também pode considerar o vert.x como uma alternativa ao nó.
21713 Mike

Respostas:


13

É particularmente forte ao lidar com uma tonelada de E / S de arquivo e eu esperaria que ele gerencie também uma tonelada de comunicação de rede. Parece particularmente popular para aplicativos baseados em soquete. O importante é ter em mente que, se suas necessidades não forem atendidas pelas bibliotecas existentes (existem muitas), talvez seja necessário mergulhar em algum C que possa ser vinculado aos comandos JS. Você também pode gerar processos adicionais de Nó, mas suspeito que muito disso pode ser tributado (suponho - pode estar errado - há uma instância V8 gerada para cada um deles).

JS é de thread único e bloqueador, o que significa que nada mais pode ser executado até que uma chamada de função seja concluída. Esse era um recurso desejado do JS, essencialmente tirando todas as preocupações de enfileiramento e enfileiramento de suas mãos. O JS não impede que o material C / C ++ seja executado de maneira mais multithread sob o capô, de modo que o papel do JS é realmente mais arquitetura / messenger. Se você estiver processando imagens, não vai querer lidar com isso com comandos JavaScript síncronos, porque todo o resto no seu aplicativo ou servidor será bloqueado até que seja concluído. A idéia é que você solicite que uma imagem seja processada pela funcionalidade C / C ++ vinculada e, em seguida, responda ao evento 'done' quando a imagem terminar de ser processada.

Isso requer que a JS em qualquer aplicativo Node.js. seja fortemente orientada a eventos e retorno de chamada ou provavelmente terá um desempenho muito ruim. Portanto, você não verá muitas chamadas de método no Node que não receberão uma função para uso posterior. Uma coisa que se torna muito clara e muito rápida no Node é que você terá um mundo feio se não encontrar uma maneira de lidar com a pirâmide de retorno de chamada. por exemplo

//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 );
    } );
} );

Felizmente, existem muitas ferramentas e exemplos disponíveis para lidar melhor com isso. A maioria costuma girar em torno de mecanismos promissores e simplesmente encadear uma série de funções destinadas a responder aos estados de retorno de chamada um do outro em uma matriz que faz as coisas feias da pirâmide para você por baixo do capô.

Pessoalmente, eu adoro o fato de termos JS em alto nível e C / C ++ mais perto do chrome. É a melhor combinação e me inspirou a começar a aprender C. E não deixe a falta de potencial da biblioteca te assustar até que você faça alguma pesquisa. As bibliotecas de nós estão sendo produzidas em um ritmo muito rápido e estão amadurecendo muito rapidamente. Se você não estiver fazendo nada, probabilidades altamente incomuns são boas para alguém.

A maior diferença do Rails é que o JS provavelmente nunca está no Rails. Nós tendemos a codificar para poder tê-lo como quiser rapidamente, para que haja a possibilidade de se envolver com fatores e a arquitetura tenha sido bastante DIY em JS até os anos mais recentes. Eu chamo isso de liberdade, mas percebo que isso não é visto como ideal para muitos desenvolvedores.

Além disso, você nunca terá um problema "gem" no Node.js. porque tentou instalar em algo diferente de um Mac. Os desenvolvedores da Web do lado do cliente desprezam os problemas de dependência e é daí que vem a maior parte do núcleo do Node. Se não funcionar em 5 minutos ou menos em todas as plataformas populares, geralmente amassamos e jogamos fora. Ainda não encontrei um módulo popular que exigisse que eu fizesse algo especial para fazê-lo funcionar. O sistema de pacotes é excelente.

Mas, para responder à sua pergunta principal de forma mais explícita / sucinta: É bom nos processos em segundo plano?

Sim, o Nó é basicamente processos em segundo plano com um meio de direcionar um aplicativo por meio de eventos e retornos de chamada.


1
Há muitas informações gerais aqui, mas você não disse nada sobre a capacidade do node.js de manipular solicitações de forma assíncrona.
Robert Harvey

Bom ponto. Vou colocar um pouco mais de foco lá.
Erik Reppen

Como ex-desenvolvedor do Rails e um desenvolvedor semi-experiente do Node.js., eu definitivamente discordo da comparação de sistemas de pacotes entre o mundo Ruby / Rails e o mundo JS / Node.js. que Erik fez. Qualquer desenvolvedor experiente (ou mesmo não experiente) do Rails sabe que "gemas" são, literalmente, como gemas. Eles trabalham sem esforço. A maioria deles é bem testada, robusta e estável. No entanto, mais da metade dos módulos NPM são mal projetados, não testados e nem concluídos. Por exemplo, ninguém pode me mostrar substituições JS de Devise ou Paperclip com exatamente a mesma qualidade e riqueza de recursos. De jeito nenhum.
Julio

Essa não é minha experiência em nada além de um Mac. Dito isso, estou menos impressionado com a compatibilidade entre sistemas operacionais do seu módulo de nó típico do que costumava estar. Não tenho certeza se acabei de encontrar mais ovos ruins com a experiência ou se a comunidade cresceu para incluir muitos desenvolvedores que não levam a plataforma cruzada tão a sério quanto deveriam. Mas há definitivamente alguns esnobes do Linux por aí.
Erik Reppen

Essa resposta merece tantos upvotes
Amin Mohamed Ajani

2

Um problema a ser observado é o que ocorre ao processar arquivos grandes em um ambiente assíncrono : se o fluxo de entrada (um arquivo) for mais rápido que o fluxo de saída (o db), não será possível lidar com os eventos de dados de entrada rapidamente o suficiente. Isso sobrecarregará parte de seu sistema (fluxo de saída ou memória) ou fará com que você perca dados. Por esse motivo, o processamento de dados de forma assíncrona pode ser um pouco complicado. Mas, como explica o artigo ao qual vinculei, a capacidade de pausar o fluxo de entrada torna possível acelerar do modo que se adapta à sua situação.


1

O Node.js se destaca no IO. É muito improvável que você descubra um dia que seu processo ficou congestionado, pois a maioria dos seus threads está bloqueando as chamadas SQL.

No entanto, o node.js é muito ruim no trabalho vinculado à computação. Quando ouço "muito IO", penso "sim! Vá nó!", Mas quando ouço "análise", hesito um pouco. Não tenho certeza se, por alguma razão, isso ocorre além de pessoas que não possuem um nó multithreading corretamente, mas até agora todo o trabalho vinculado à computação do meu produto ocorre fora do nó.

A multithreading no node.js é complicada de configurar corretamente. Tudo é encadeado por padrão e a maioria dos códigos é escrita sob a suposição de que ele será executado apenas em um encadeamento. Você certamente precisará usar domínios para impedir que um erro em um encadeamento interrompa todo o aplicativo.

Observe também que o nó pode ser um pouco mais fraco em alguns recursos da empresa. Por exemplo, suas bibliotecas de log não se comparam às Java. No momento, não existe uma boa estrutura de registro que suporte o MDC, o que, na prática, significa que você pode fazer var logPrefix = userId + ": "muito.

Também nunca executei um repo npm privado. Você pode precisar de um deles, dependendo se seu código é proprietário.


1

Se seus processos em segundo plano puderem ser executados sequencialmente, pode ser muito bom. Na minha última posição, tive que escrever vários pré-processadores, exportações e utilitários de tradução para muitas fontes de dados. Usar o NodeJS foi fácil aqui.

Se você não está executando muito processamento vinculado à computação, manipulação simples de seqüências curtas e análise de números inteiros não é tão ruim, se você precisar manipular imagens, provavelmente não é a melhor ferramenta (embora existam invólucros e módulos solicitáveis isso pode funcionar bem).

Conselho, atenha-se aos módulos que usam fluxos. Isso pode facilitar a canalização de seu processamento para módulos para essa etapa específica. Se você observar como o fluxo de eventos é usado no gulp-jade para a ferramenta de construção gulp, por exemplo, poderá ver como é capaz.

Para CSV, você pode usar o node-csv , que é muito bom em estabelecer uma base para registros de canalização em um fluxo de processador.

Para XML ish grande, em que você deseja fazer um único registro de cada vez, eu observaria o node-halfstreamxml que lê seu fluxo XML usando um processador SAX e gera eventos para cada nó. Eu colocaria isso em um fluxo de leitura / gravação para que você possa aumentar as correspondências desejadas. Muitos analisadores de objetos xml no nó tentarão ler / analisar todo o xml de uma só vez e, por exemplo, 100mb de xml que fica enorme ... onde o halfstreamxml lerá como um fluxo.

NOTA: existem outros processadores, como xml-stream, que usarão o expat (biblioteca C) abaixo, que podem oferecer mais desempenho, mas menos portáteis sem um ambiente de construção.

Em geral, tem sido uma verdadeira alegria usar ...

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.