6

大量のシミュレーションを実行して大量のデータを生成し、それらを保存して後で再度アクセスする必要があります。シミュレーション プログラムからの出力データは、テキスト ファイルに書き込まれます (シミュレーションごとに 1 つ)。これらのテキスト ファイルを読み取り、後で分析するのにより便利な形式でデータを保存する Python プログラムを作成する予定です。かなりの検索の後、私は情報過多に苦しんでいると思うので、この質問を Stack Overflow に投稿してアドバイスを求めています。詳細は次のとおりです。

私のデータは基本的に多次元配列の形式を取り、各エントリは次のようになります。

data[ stringArg1, stringArg2, stringArg3, stringArg4, intArg1 ] = [ floatResult01, floatResult02, ..., floatResult12 ]

各引数には、おおよそ次の数の潜在的な値があります。

stringArg1: 50

stringArg2: 20

stringArg3: 6

stringArg4: 24

intArg1: 10,000

ただし、データセットはまばらになることに注意してください。たとえば、stringArg1 の特定の値に対して、stringArg2 の約 16 個の値のみが入力されます。また、(stringArg1, stringArg2) の特定の組み合わせに対して、intArg1 の約 5000 の値が入力されます。3 番目と 4 番目の文字列引数は次のとおりです。常に完全に満たされています。

したがって、これらの数値を使用すると、配列にはおよそ 50*16*6*24*5000 = 576,000,000 の結果リストが含まれます。

この配列を保存して後で再度開いて、データを追加したり、既存のデータを更新したり、分析のために既存のデータをクエリしたりできるようにするための最良の方法を探しています。これまで、私は 3 つの異なるアプローチを検討してきました。

  1. リレーショナル データベース

  2. PyTable

  3. タプルをディクショナリ キーとして使用する Python ディクショナリ (保存とリロードに pickle を使用)

3 つのアプローチすべてで遭遇する問題が 1 つあります。私は常に (stringArg1、stringArg2、stringArg3、stringArg4、intArg1) のすべてのタプルの組み合わせを、テーブルのフィールドとして、または Python 辞書のキーとして格納することになります。私の(おそらく素朴な)観点からは、これは必要ないように思えます。これらがすべて整数の引数である場合、それらは配列内の各データ エントリのアドレスを形成するだけであり、考えられるすべてのアドレスの組み合わせを別のフィールドに格納する必要はありません。たとえば、2x2 配列 = [[100, 200] , [300, 400]] がある場合、アドレス配列 [0][1] の値を要求して値を取得します。すべての可能なアドレス タプル (0,0) (0,1) (1,0) (1,1) を別の場所に保存する必要はありません。だから私はこれを回避する方法を見つけることを望んでいます。

私ができるようになりたいのは、PyTables でテーブルを定義することです。この最初のテーブルのセルには他のテーブルが含まれています。たとえば、最上位テーブルには 2 つの列があります。最初の列のエントリは、stringArg1 の可能な値になります。2 番目の列の各エントリはテーブルになります。これらのサブテーブルには 2 つの列があり、最初の列は stringArg2 のすべての可能な値であり、2 番目の列はサブサブテーブルの別の列です...

この種のソリューションは、参照とクエリが簡単です (特に、ViTables を使用してデータを参照できる場合)。問題は、PyTables が 1 つのテーブルのセルに他のテーブルを含めることをサポートしていないように見えることです。だから私はそこで行き止まりにぶつかったようです。

私はデータ ウェアハウジングとスター スキーマ アプローチについて調べてきましたが、それでも、ファクト テーブルには考えられるすべての引数の組み合わせのタプルを含める必要があるようです。

さて、それは私がいるところです。あらゆるアドバイスをいただければ幸いです。この時点で、私は頭が痛いほど探し回っています。専門家に聞く時が来たと思います。

4

3 に答える 3

2

5億のエントリすべてを保持するために大きなテーブルを使用しないのはなぜですか? オンザフライト圧縮 (ここでは Blosc コンプレッサーを推奨) を使用すると、重複したエントリのほとんどが重複排除されるため、ストレージのオーバーヘッドは最小限に抑えられます。これを試してみることをお勧めします。単純な解決策が最適な場合もあります;-)

于 2011-02-23T17:40:40.863 に答える
0

基本的な 6 テーブル アプローチが適用されない理由はありますか?

つまり、テーブル 1 ~ 5 は、各フィールドの有効な値を定義する 1 列のテーブルであり、最終的なテーブルは、実際に存在するエントリを定義する 5 列のテーブルです。

または、説明したように 3 番目と 4 番目の文字列値にすべての値が常に存在する場合、6 番目のテーブルは 3 つの列 (string1、string2、int1) で構成され、string3 と string4 の組み合わせをデカルト結合によって動的に生成できます。

于 2011-02-21T03:37:32.473 に答える
0

ここで何をしようとしているのか完全にはわかりませんが、(潜在的に)まばらな多次元配列を作成しようとしているようです。したがって、特定の問題を解決するための詳細には立ち入りませんが、これを扱うことがわかっている最適なパッケージは Numpy Numpyです。ナンピー缶

一般的なデータの効率的な多次元コンテナーとして使用できます。任意のデータ型を定義できます。これにより、NumPy はさまざまなデータベースとシームレスかつ迅速に統合できます。

私は Numpy をシミュレーション データ処理に何度も使用しており、簡単なファイル ストレージ/アクセスなど、多くの便利なツールを提供しています。

非常に読みやすいドキュメントで何かを見つけることができれば幸いです。

例を含む Numpy ドキュメント

于 2011-07-21T19:33:09.677 に答える