node.jsはバックグラウンド処理に適していますか？
私はゆっくりと勉強していますnode.jsそして私が始めたい小さなプロジェクトがあります。プロジェクトには多くのバックグラウンドプロセス（外部サイトからのデータのダウンロード、CSVファイルの解析など）があります。
私とノードにとって大きな「勝利」は、クライアントとサーバーの両方にJavaScriptを使用していることです。私はJavaおよびJavaScriptを私の日常業務でコーディングしていますが、Rubyもかなり得意です。
しかし、私が言ったように、どこでも1つの言語を使用することは魅力的であり、JSはその法則に適合しているようです。
ただし、JSを使用してバックグラウンドジョブを実行する経験はあまりありません。 RubyこれはExcelのようです。そして私はそれを使用することに反対していません。それで、100％JSをこれに使用することについてのあなたの考えは何ですか？私は非常に大規模なプロジェクトがカスタムソリューションを必要とすることを理解しています。私はm努力する価値があるかどうか疑問に思っているだけなのか、それともRubyのような雑用にこだわる必要がありますか？
ご意見をお寄せください。
ありがとう
これは特に大量のファイルI/Oを処理するのが得意であり、大量のネットワーク通信も適切に処理することが期待されます。ソケット駆動型アプリで特に人気があるようです。覚えておくべき重要なことは、既存のライブラリ（多くある）でニーズが満たされない場合、JSコマンドにバインドできるCに飛び込む必要があるかもしれないということです。追加のNodeプロセスを生成することもできますが、その多くを実行すると、負荷がかかる可能性があると思います（おそらく間違っている可能性があります-それぞれに生成されたV8インスタンスがあると思います）。
JSはシングルスレッドでブロックされます。つまり、関数呼び出しが完了するまで、他に何も実行できません。これはJSの望ましい機能であり、基本的にすべてのスレッド化とキューイングの懸念を解消しました。 JSは、C/C++の要素が内部でよりマルチスレッドの方法で実行されることを妨げないため、JSの役割は実際にはより多くのアーキテクチャー/メッセンジャーです。画像処理をしている場合は、同期JavaScriptコマンドでそれを処理する必要はありません。これは、アプリまたはサーバー上の他のすべてが完了するまでブロックされるためです。アイデアは、バインドされたC/C++機能によって処理される画像を要求し、画像の処理が完了したときに「完了」イベントに応答することです。
これには、任意のNode.jsアプリのJSがイベントとコールバックに大きく依存している必要があります。そうでない場合、パフォーマンスが非常に低下します。したがって、Nodeに多くのメソッド呼び出しがあり、後で使用するために関数を渡されません。）Nodeコールバックピラミッドを処理する方法が見つからなければ、醜い世界にいることになります。例：.
//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 );
} );
} );
幸いなことに、これをよりよく処理するためのツールや例がたくさんあります。ほとんどは、Promiseメカニズムを中心に展開し、内部で醜いピラミッドのようなことを行う配列で、お互いのコールバック状態に応答するための一連の関数を単純にチェーンする傾向があります。
個人的には、JSをハイレベルに、C/C++をクロームに近づけることが大好きです。これは究極のコンボであり、Cの学習を始めるきっかけになりました。さらに、いくつかの研究を終えるまで、ライブラリの欠如があなたを驚かせないようにしてください。 Nodeライブラリは非常に速いペースで作成されており、非常に急速に成熟しています。あなたが何もしていなければ、非常に珍しいオッズは誰かがそれをカバーしているのは良いことです。
Railsとの最大の違いは、JSがRailsである可能性が高いことは決してないということです。私たちはそれを手に入れることができるようにコーディングする傾向があります。ファクターとアーキテクチャーに夢中になることは、最近までJSでかなりDIYでした。私はそれを自由と呼んでいますが、それは多くの開発者にとって理想的とは見なされていません。
また、Mac以外のものにインストールしようとしたため、Node.jsで「gem」問題が発生することは決してありません。クライアント側のWeb開発者は依存関係の問題を軽視し、そこから多くのNodeのコアが生まれています。すべての一般的なプラットフォームで5分以内に箱から出してすぐに機能しない場合は、通常、それをくしゃくしゃにして投げます。私はそれを機能させるために特別なことをする必要がある人気のあるモジュールにまだ遭遇していません。パッケージシステムは、優れています。
しかし、あなたの核心的な質問にもっとはっきりと/簡潔に答えるには：バックグラウンドプロセスで良いですか？
はい、Node基本的にISイベントとコールバックを介してアプリを駆動する手段を備えたバックグラウンドプロセスです。
注意すべき1つの問題は、 非同期環境で大きなファイルを処理する の場合に何が発生するかです：入力ストリーム（ファイル）が出力ストリーム（db）より速い場合、次のことはできません。入力データイベントを十分迅速に処理します。これは、システムの一部（出力ストリームまたはメモリ）を圧倒するか、データを失う原因になります。このため、非同期でのデータ処理は少し注意が必要です。しかし、私がリンクした記事で説明しているように、入力ストリームを一時停止する機能により、状況に合った方法でスロットルすることができます。
バックグラウンドプロセスが連続して実行できる場合、それはかなり良いことです。私の最後のポジションでは、多くのデータソース用にいくつかのプリプロセッサ、エクスポート、および変換ユーティリティを作成する必要がありました。ここでは、NodeJSを簡単に使用できました。
lotの計算バインド処理、短い文字列の単純な操作、および整数解析を行わない場合、必要であれば画像を操作する場合、それはおそらく最良のツールではありません（ただし、呼び出し可能なラッパーと適切に機能するモジュールがあります）。
アドバイス、ストリームを使用するモジュールに固執する。これにより、その特定のステップのモジュールに処理をパイプするのが簡単になります。 gulp-jade で event-stream がどのように使用されているかを見ると、たとえば gulpビルドツール の場合、それがどの程度の能力があるかがわかります。 。
CSVの場合、 node-csv を使用できます。これは、レコードをプロセッサストリームにパイプするためのベースを確立するのに非常に適しています。
大規模なXMLの場合、一度に1つのレコードを実行する場合、SAXプロセッサを使用してXMLストリームを読み取り、各ノードのイベントを発生させる node-halfstreamxml を調べます。私はそれを読み取り/書き込みストリームにラップして、希望の一致を上げることができるようにします。ノード内の多くのxml-objectパーサーは、一度にxml全体の読み取り/解析を試みます。たとえば、100mbのxmlが巨大になる...ここでhalfstreamxmlはストリームとして読み取られます。
注： xml-stream のような他のプロセッサがあり、下にexpat（Cライブラリ）を使用します。これにより、パフォーマンスは向上しますが、ビルド環境がないと移植性が低下します。
一般的に、それを使用することは本当に喜びです...
Node.jsはIOに優れています。ほとんどのスレッドがSQL呼び出しでブロックされているため、ある日プロセスが停止したことを発見することはほとんどありません。
ただし、node.jsは、実際に計算にバインドされた作業ではbadです。 「たくさんのIO」と聞くと「ええ！ノードに行く！」と思いますが、「解析」と聞くと少し迷います。これが何らかの理由でノードを適切にマルチスレッド化する以外の理由であるかどうかはわかりませんが、これまでのところ、私の製品のすべてのコンピューティングバインド作業はノードの外部で行われています。
Node.jsのマルチスレッドは、正しく設定するのが難しいです。すべてはデフォルトでシングルスレッドであり、ほとんどのコードは1つのスレッドでのみ実行されるという想定の下に記述されています。 1つのスレッドでエラーが発生してアプリケーション全体が停止するのを防ぐために、必ず domains を使用する必要があります。
また、一部のエンタープライズ機能ではノードが少し弱い場合があることにも注意してください。たとえば、ロギングライブラリはJavaと比較されません。現時点では、MDCもサポートする優れたロギングフレームワークはありません。つまり、実際には、たくさんのvar logPrefix = userId + ": " たくさん。
また、私はプライベートnpmリポジトリを実行したことがありません。コードがプロプライエタリかどうかによって、これらのいずれかが必要になる場合があります。