私は現在、データ解析プログラムに取り組んでいる核物理学の大学院生です。データは、数十億の多次元ポイントで構成されています。ディスクに展開するための戦略ディスク
とにかく、複数のディメンションを1つのディメンションにマップするために空白の塗りつぶし曲線を使用しています。データのページにインデックスを付けるためにB +ツリーを使用しています。各ページには一定の最大点数があります。
元のファイルから生データ(数百ギガ)を読み込み、前処理してインデックス化するときに、個々のポイントをページに挿入する必要があります。明らかに、あまりにも多くのページがメモリに格納され、ディスクにダンプされるだけです。だから私の質問は、これは次のとおりです。ページをディスクに書き込むための良い戦略は、ページが最大サイズに達して分割する必要があるときにデータの再シャッフルを最小限に抑えることです。
コメントに基づいて少し減らしてみましょう。
私は、注文されたレコードを含むファイルを持っています。これらのレコードはファイルに挿入されており、メモリ内でこれを単に実行してファイルに書き込むためには、これらのレコードが多すぎます。レコードを挿入するときに必要な再切り換えの量を最小限に抑えるためにどのような戦略をとるべきですか。
これが意味をなさないのであれば、私があなたに持っている可能性のある解決策に感謝します。
編集:
データは多次元スペースのポイントです。本質的に整数のリスト。これらの整数はそれぞれ2バイトですが、各整数には2バイトのメタデータも関連付けられています。したがって、1座標あたり4バイト、3〜20座標のどこかに座標があります。つまり、本質的にデータは、12〜100バイトのどこかの各チャンクで構成されています。 (明らかに、4次元が抽出されると、5次元の点とは異なるファイルに配置されます)。
私はこの記事で説明したものと同様の技術使用しています: http://www.ddj.com/184410998
編集2: を私はちょっとここにこの質問をして後悔するので、それが正式に撤回を検討。しかし、ここには棚用製品を使わないという理由があります。私のデータは、3次元から22次元の任意の範囲にある点です。それぞれの点を単なるリストと考えると、どのようにポイントを照会したいのか、これらの数字と同じリストにあるすべての数字が何であるか考えることができます。以下の低次元(及び通常より多くの、より少ないデータ点)といくつかの例は、 例: データ 237、661、511、 1047 1021 661、237 511、237、1021 511、661、1047、1021
Queries:
511
1021
237, 661
1021, 1047
511, 237, 1047
Responses:
237, 661, 1021, 237, 1021, 661, 1047, 1021
237, 661, 511, 511, 237, 511, 661, 1047
511, 1021, 1047
511, 661
_
これは、ほとんどのデータベースプログラムではほとんど問題ではありませんが、これをうまく処理できるものがいくつかあります。
しかし、問題はより複雑になります。すべての座標が同じではありません。多くの場合、ガンマ球は単独で走り、各座標はガンマ線エネルギーを表します。しかし、他の時には、中性子検出器をgammasphereまたはマイクロボールと呼ばれる検出器システムに挿入するか、時にはgammasphereで生成された核種をフラグメント質量分析計に流し込み、これらの検出器システムはすべて単独で、またはgammasphereと組み合わせて使用できます。残念ながら、私たちはほとんどの場合、上記のような方法でこの追加データを選択できるようにしたいと考えています。だから座標は異なる意味を持つことができます。もしあなたが数式x + y = nに対して肯定的な解があるのと同じくらい多くの方法でn次元の出来事を作るようにすれば、さらに、各座標にはメタデータが関連付けられています。私が示した数字のそれぞれには、それらに関連する少なくとも2つの追加番号があります。第1に、イベントを取得した検出器の検出器番号、第2のもの、特定のガンマ線の回数を表す有効性値(実際に検出される検出器に入射するガンマ線の割合は、検出器およびエネルギーによって変化するため)。
棚卸しデータベースソリューションは、これらのすべてを実行し、同時に膨大な量のカスタマイズを行うことなく、うまく機能することを誠実に疑っています。私はそれに費やされた時間が私自身の、より一般的ではない解決策を書くことに費やされたと考えています。一般性を失うため、データバインディングコードの削除機能を実装する必要はありません。異なるタイプの座標にゲートするためのセカンダリインデックスを構築する必要はありません(各ポイントを1回だけ有効に数えます)
「SQLのような棚のようなものは本当にうまくいっていない」という記述を説明できますか?これは、インデックスをカバーするものです...他のRDBMSの場合と同様に、SQL Server 2008はこの問題に対処できるはずです –
ファイル内のデータは、作成するインデックスの適切な順序で既に座っていますか? – jn29098
あなたのファイル形式についての洞察はありますか? – jn29098