最小のファイルが48000フィールド×1600行（22番染色体の数人のハプロタイプ）であるデータセットが表示されたとき、私は今日、実際の科学コンピューティングに最初の一歩を踏み出しました。そして、これは小さいと考えられています。
私はPythonを書いているので、ここ数時間HDF5、Numpy、PyTableについて読んでいますが、それでも、テラバイトサイズのデータセットがプログラマーとして実際に何を意味するのかを理解しているわけではないようです。
たとえば、データセットが大きくなると、マシンのRAMが不十分なためではなく、アーキテクチャのアドレススペースが不十分なために、すべてをメモリに読み込むことができなくなるとの指摘がありました。それは私の心を吹き飛ばしました。
これほど大きな入力では機能しない、教室で私が信頼している他の仮定は何ですか？何か違うことをしたり考えたりするために、どのようなことをする必要がありますか？（これはPython固有である必要はありません。）
私は現在、石油業界の小さな一角で高性能コンピューティングに従事しており、懸念している桁違いのデータセットを定期的に処理しています。考慮すべき点は次のとおりです。
このドメインでは、データベースの牽引力はあまりありません。ほとんどすべてのデータはファイルに保存されており、それらのファイルの一部は70年代に設計されたテープファイル形式に基づいています。データベースを使用しない理由の一部は歴史的なものだと思います。10、5年前でさえ、オラクルとその同類は、O（TB）の単一のデータセットを管理するタスク、ましてやそのようなデータセットの数千のデータベースを管理するタスクに対応していなかったと思います。
もう1つの理由は、効果的なデータベース分析と設計のための正規化ルールと科学データセットの性質との間の概念的な不一致です。
私は（私にはわかりませんが）パフォーマンスの理由は今日でははるかに説得力がないと思います。また、利用可能な主要なデータベースのほとんどが、他の科学データセットに一般的にはるかに近い概念的適合である空間データセットに対応できるようになったため、概念の不一致の理由もおそらくそれほど差し迫っていません。メタデータを保存するためのデータベースの使用が増えており、ある種の参照を使用して、センサーデータを含むファイルを参照しています。
しかし、私はまだHDF5を見ている、実際には見ています。それにはいくつかの魅力があります（a）それは単なる別のファイル形式なので、DBMSをインストールしてその複雑さに取り組む必要はありません、そして（b）適切なハードウェアでHDF5ファイルを並行して読み書きできます。（はい、データベースの読み取りと書き込みも並行して実行できることを知っています）。
これは私を2番目のポイントに連れて行きます：非常に大きなデータセットを扱うとき、あなたは本当に並列計算を使うことを考える必要があります。私は主にFortranで作業していますが、その強みの1つは、多くの科学計算に非常によく適合する配列構文です。もう1つは、利用可能な並列化の優れたサポートです。Pythonにはあらゆる種類の並列化サポートもあると思うので、おそらくあなたにとって悪い選択ではありません。
確かに、順次システムに並列処理を追加することはできますが、並列処理の設計から始める方がはるかに優れています。一例を挙げると、問題に最適なシーケンシャルアルゴリズムは、並列化の最適な候補ではないことがよくあります。複数のプロセッサでより適切に拡張できる別のアルゴリズムを使用する方がよい場合があります。それは次のポイントにきちんとつながります。
また、すべてのデータがメモリに常駐している場合にうまく機能する多くの巧妙なアルゴリズムとデータ構造に、（持っている場合は）添付ファイルを放棄することに同意する必要があるかもしれません。データを一度にメモリに取り込むことができない状況にそれらを適応させようとすることは、ブルートフォースよりもはるかに難しく（パフォーマンスが低下し）、ファイル全体を1つの大きな配列と見なすことがよくあります。
プログラムの実行パフォーマンスと開発者のパフォーマンスの両方で、パフォーマンスが深刻な問題になり始めます。1TBデータセットは1GBデータセットの10倍のコードを必要とするため、より高速に作業する必要があるわけではありません。実装する必要のあるアイデアの一部は非常に複雑であり、おそらくドメインスペシャリストが作成する必要があります。つまり、あなたが一緒に働いている科学者たちです。ここでは、ドメインスペシャリストがMatlabで記述しています。
しかし、これは長すぎるので、仕事に戻ったほうがいいです
一言で言えば、主な違いIMO：
帯域幅と I/O
最初は、帯域幅と I/O がボトルネックになることがよくあります。概観を示すと、 SATA 3の理論上の限界では、1 TB を読み取るのに約 30 分かかります。ランダムアクセス、数回の読み取りまたは書き込みが必要な場合は、ほとんどの場合これをメモリ内で行うか、かなり高速なものが必要です (例: InfiniBandを使用したiSCSI )。システムは、理想的には、使用しているインターフェースの理論上の限界にできるだけ近づけるために、並列 I/Oを実行できる必要があります。たとえば、異なるプロセスで異なるファイルに並列にアクセスしたり、 MPI-2 I/O の上でHDF5にアクセスしたりするだけです。はかなり一般的です。理想的には、2 つのうちの 1 つが「無料」になるように、計算と I/O も並行して実行します。
クラスター
ケースによっては、I/O または CPU のいずれかがボトルネックになる可能性があります。いずれにせよ、タスクを効果的に分散できれば、クラスターを使用して大幅なパフォーマンスの向上を実現できます (例: MapReduce )。これには、典型的な教科書の例とはまったく異なるアルゴリズムが必要になる場合があります。多くの場合、ここでの開発時間は最高の時間です。
アルゴリズム
アルゴリズムを選択する際には、アルゴリズムの大きな O が非常に重要ですが、同様の大きな O を持つアルゴリズムは、場所によってパフォーマンスが劇的に異なる可能性があります。アルゴリズムのローカル性が低いほど (つまり、キャッシュ ミスとメイン メモリ ミスが多い)、パフォーマンスが低下します。通常、ストレージへのアクセスは、メイン メモリよりも 1 桁遅くなります。改善の古典的な例は、行列の乗算またはループ交換のタイリングです。
コンピュータ、言語、専用ツール
ボトルネックが I/O である場合、これは、大規模なデータ セットのアルゴリズムが、より多くのメイン メモリ (64 ビットなど) またはメモリ消費量の少ないプログラミング言語/データ構造 (Python など) の恩恵を受けることができることを意味し__slots__ます。 CPU 時間あたりの I/O が少なくなる可能性があります。ところで、TB のメイン メモリを搭載したシステムは前代未聞ではありません (たとえば、HP スーパードーム)。
同様に、ボトルネックが CPU である場合、より高速なマシン、言語、およびアーキテクチャの特別な機能 ( SSEのようなSIMDなど) を使用できるコンパイラを使用すると、パフォーマンスが桁違いに向上する可能性があります。
データを検索してアクセスし、メタ情報を保存する方法は、パフォーマンスにとって非常に重要です。多くの場合、フラット ファイルまたはドメイン固有の非標準パッケージを使用して、より効率的にデータにアクセスできるようにするデータを格納します (たとえば、リレーショナル データベースに直接ではありません)。たとえば、kdb+は大規模な時系列に特化したデータベースであり、ROOTはTTreeオブジェクトを使用してデータに効率的にアクセスします。あなたが言及したpyTablesは別の例です。
一部の言語では、他の言語よりも型のメモリ オーバーヘッドが自然に低くなりますが、このサイズのデータでは問題になりません。使用している言語に関係なく、データ セット全体をメモリに保持しているわけではないため、「費用」ここではPythonの関係は関係ありません。ご指摘のとおり、このすべてのデータを参照するだけでなく、それを保持するのに十分なアドレス空間がありません。
これが通常意味することは、a) データをデータベースに保存するか、b) 追加のコンピューターの形でリソースを追加して、使用可能なアドレス空間とメモリを追加することです。現実的には、これらの両方を行うことになります。データベースを使用する際に心に留めておくべき重要な点の 1 つは、データベースは、使用していないときにデータを配置するだけの場所ではないということです。データベースで WORK を実行できます。そうするようにしてください。使用するデータベース テクノロジは、実行できる作業の種類に大きな影響を与えますが、たとえば SQL データベースは、多くの集合計算を効率的に実行するのに適しています (もちろん、これはスキーマ設計が次のようになることを意味します)。アーキテクチャ全体の非常に重要な部分です)。ドン'
主な前提条件は、許容可能な価格で1台のマシンに搭載できるCPU/キャッシュ/RAM/ストレージ/帯域幅の量です。スタックオーバーフローには、4G RAMと約1テラバイトのストレージと1Gbネットワークを備えた32ビットマシンの古い仮定に基づいた、多くの答えがあります。220ユーロの16GBDDR-3RAMモジュール、512 GB RAMを使用すると、48コアのマシンをリーズナブルな価格で構築できます。ハードディスクからSSDへの切り替えも重要な変更です。