私は天体物理学の大学院生です。私は、大部分が他の人が 10 年ほどかけて開発したコードを使用して、大規模なシミュレーションを実行しています。これらのコードの例については、ガジェットhttp://www.mpa-garching.mpg.de/gadget/と enzo http://code.google.com/p/enzo/を参照してください。これらは間違いなく最も成熟した 2 つのコードです (異なる方法を使用しています)。
これらのシミュレーションから得られる成果は膨大です。コードによって、データは少し異なりますが、常にビッグ データです。通常、何十億もの粒子とセルを使用して、現実的なことを行います。最大の実行は、スナップショットあたり数テラバイト、シミュレーションあたり数百のスナップショットです。
現在、この種のデータを読み書きする最良の方法は、基本的にバイナリ ファイルを使用する体系的な方法であるHDF5 http://www.hdfgroup.org/HDF5/を使用することです。これは、カスタム ヘッダー ブロックを使用したフォーマットされていないバイナリ ファイルに比べて大幅に改善されていますが (それでも悪夢に悩まされます)、これを行うためのより良い方法があるのではないかと思わずにはいられません。
ここで問題になるのは膨大なデータ サイズだと思いますが、テラバイト単位のバイナリ データを効率的に処理できる何らかのデータストアがあるのでしょうか、それとも現時点ではバイナリ ファイルが唯一の方法なのでしょうか?
それが役立つ場合は、通常、データを列ごとに保存します。つまり、すべての粒子 ID のブロック、すべての粒子位置のブロック、粒子速度のブロックなどがあります。これは最もきれいではありませんが、あるボリュームで粒子ルックアップのようなことを行うには最速です。
編集：問題について曖昧で申し訳ありません。これはデータの保存方法ではなく、データ構造の問題である可能性があるという Steve の意見は正しいです。今すぐ走らなければなりませんが、今夜か明日遅くに詳細をお知らせします.
編集 2:したがって、これを調べれば調べるほど、これはおそらくデータストアの問題ではないことがわかります。フォーマットされていないバイナリの主な問題は、データを正しく読み取る (ブロック サイズと順序を正しく取得し、それを確認する) という頭痛の種でした。HDF5 ではそれがほぼ修正されており、ファイル システムの制限が改善されるまで、より高速なオプションはありません (Matt Turk に感謝)。
新しい問題は、おそらくデータ構造に帰着します。HDF5 は、クエリを実行するのに最適なインターフェイスではありませんが、最高のパフォーマンスを発揮します。データベースに慣れているので、「いつでも x を超える速度のすべての粒子を教えてください」などのクエリを実行できると、非常に興味深い/強力だと思いました。今でもそのようなことはできますが、より低いレベルで作業する必要があります。もちろん、データがどれだけ大きいかを考えると、それを使って何をするかにもよりますが、パフォーマンスのために低いレベルで作業することは良いことかもしれません.