2

大量のファイルを同時に処理する必要があります（数千の異なるファイル、ファイルあたりの平均サイズは2MB）。

すべての情報は1台の（1.5TB）ネットワークハードドライブに保存され、約30台の異なるマシンで処理されます。効率を上げるために、各マシンは異なるファイルを読み取り（および処理）します（処理する必要のあるファイルは数千あります）。

すべてのマシンは、1.5TBハードドライブの「incoming」フォルダからファイルを読み取った後、情報を処理し、処理された情報を1.5TBドライブの「processed」フォルダに出力する準備が整います。すべてのファイルで処理される情報は、入力ファイルとほぼ同じ平均サイズです（ファイルあたり約2MB）。

何をするのが良いですか：

（1）すべての処理マシンMについて、 Mによって処理されるすべてのファイルをローカルハードドライブにコピーしてから、マシンMでローカルにファイルを読み取って処理します。

（2）ファイルをすべてのマシンにコピーする代わりに、すべてのマシンが「着信」フォルダーに直接アクセスし（NFSを使用）、そこからファイルを読み取り、ローカルで処理します。

どちらのアイデアが良いですか？そのようなことをしているときに「する」と「しない」はありますか？

30台ほどのマシンが同じネットワークドライブに同時に情報を読み取る（または書き込む）ことが問題になるかどうか、私は主に興味がありますか？

（注：既存のファイルは読み取りのみで、追加/書き込みは行われません。新しいファイルは最初から作成されるため、同じファイルへの複数のアクセスの問題はありません...）。予想すべきボトルネックはありますか？

（私はLinux、Ubuntu 10.04 LTSをすべてのマシンで使用しています）

4

1 に答える 1

2

私は間違いなく＃2を行います-そして私は次のようにそれを行います：

すべてのファイルを使用してメインサーバーでApacheを実行します。（または、本当に必要な場合は、他のHTTPサーバー）。私がこのようにする理由はいくつかあります。

  1. HTTPは基本的に純粋なTCPです（いくつかのヘッダーがあります）。リクエストが送信されると、それは非常に「一方向」のプロトコルになります。オーバーヘッドが低く、おしゃべりではありません。高性能と効率-低いオーバーヘッド。

  2. （何らかの理由で）データを移動またはスケールアウトする必要があると判断した場合（たとえば、couldサービスを使用）、NFSよりもHTTPの方がオープンインターネット上でデータを移動するためのはるかに優れた方法です。SSLを使用できます（必要な場合）。ファイアウォールを通過する可能性があります（必要な場合）。etc..etc..etc..。

  3. ファイルのアクセスパターンに応じて、ファイル全体を読み取る必要があると仮定すると（1回のネットワーク操作を実行するだけでファイル全体を1回の操作で取り込む方が簡単/高速です）、常にI/Oを要求するよりも簡単です。ファイルの小さな部分を読み取るたびにネットワーク。

  4. これらすべてを実行し、ネットワークマウントの存在（特定のファイルパスなど）に依存しないアプリケーションを配布して実行するのは簡単です。ファイルへのURLがあれば、クライアントはその仕事をすることができます。マウントやハードディレクトリを確立する必要はありません。または、そのようなマウントを設定するためにルートになる必要はありません。

  5. NFS接続の問題がある場合、マウントにアクセスしようとするとシステム全体が不安定になり、ハングする可能性があります。HTTPがユーザースペースコンテキストで実行されている場合（タイムアウトエラーが発生するだけです）、アプリケーションは選択したアクションを実行できます（ページのように、エラーをログに記録するなど）。

于 2010-12-15T21:25:29.957 に答える