分散ファイルシステム上でのファイルの移動

Question

私はファイル数が数億（数ペタバイト）のファイルシステムを持っており、statが返すすべてのものを取得して何らかのデータベースに格納したいと考えています。現在、私たちは中央キューからディレクトリ名を与えられたMPIプログラムと、statコールを使ってNFSをスラムするワーカーノード（これはあまりにも苦労せずにこれを処理できます）を持っています。その後、作業者ノードはpostgresにヒットして結果を保存します。

これは機能しますが、非常に遅いです。最新の30ノードクラスタでは、1回の実行で24時間以上がかかります。

誰でも集中的なキューを持つ代わりにディレクトリ構造を分割するアイデアがありますか（私はこのための正確なアルゴリズムはNP困難です）？また、postgresをMongoDBのautoshardingのようなものに置き換えることを検討してきました（ポストグルは現在大きなボトルネックになっているので）。

私は、この設定がどのように改善されるかについての一般的なアイデアを探しています。

残念なことに、2.6カーネル監査サブシステムのようなものを使用することは、このファイルシステムにぶつかるすべてのマシンで実行するのが（政治的な方法で）非常に難しいため、おそらく疑問にはなりません。

このファイルシステムを使用するすべてのマシン（数千）は、Linux 2.6.xを実行しています。

実際の主な目的は、特定の日付より古いファイルを検索して削除できるようにすることです。また、ファイルシステムの使用方法に関する一般的なデータも収集したいと考えています。

Answer 1

私のコメントを拡大してください。

ファイルを中央に置くことは、最大のボトルネックの1つです。ファイルシステムのアクセス時間を他の方法で最適化できない場合は、1人（または2人）の従業員にstatコールを行うことが最善の方法でしょう。彼らはすべて同じファイルシステムにアクセスしているので、2人以上のワーカーを追加することでパフォーマンスが向上することはありません。

このため、（NFS経由でアクセスするのではなく）ファイルシステムがあるノードに作業者を置くと、パフォーマンスが大幅に向上するはずです。

一方、データベースエンジンを変更することによって、データベース書き込みを最適化することができます。コメントで予想されているように、Redisキー値モデルはそのようなタスク（例えば、is pretty fast）に適しています。hash typeを使用して、完全パス名をキーとしてstat呼び出しの結果を格納できます。

さらに、redisは近い将来clusteringもサポートします。

Answer 2

私たちは最終的にこれを（redisを使用して）独自のソリューションを作成しました。私たちはそれを実行するために約24時間から約2.5時間に時間をダウンさせました。

• http://github.com/hpc/libcircle
• http://github.com/hpc/purgerすべてを制御するツールです。