7

タブ区切りのファイルに保存されている大量の科学データを扱ってい.tsvます。実行される一般的な操作は、いくつかの大きなファイルの読み取り、特定の列/行のみのフィルター処理、他のデータソースとの結合、計算値の追加、および結果を別の.tsvとして書き込むことです。

プレーンテキストは、その堅牢性、寿命、および自己文書化の特徴のために使用されます。データを別の形式で保存することはできません。データを開いたままにして、処理しやすくする必要があります。大量のデータ（数十TB）があり、コピーをリレーショナルデータベースにロードするのは手頃ではありません（2倍のストレージスペースを購入する必要があります）。

私は主に選択と結合を行っているので、基本的に.tsvベースのバッキングストアを備えたデータベースエンジンが必要であることに気付きました。私のデータはすべてwrite-once-read-manyであるため、トランザクションについては気にしません。主要な変換手順やデータの複製を行わずに、データをインプレースで処理する必要があります。

この方法で照会するデータはたくさんあるので、キャッシュとコンピューターのグリッドを利用して、データを効率的に処理する必要があります。

プレーンなタブ区切りファイルをバックエンドとして使用しながら、データベースのような機能を提供するシステムを知っている人はいますか？事実上すべての科学者が何らかの方法で対処するようになるという、非常に一般的な問題のように私には思えます。

4

7 に答える 7

5

大量のデータ (数十 TB) があり、コピーをリレーショナル データベースにロードするのは手頃ではありません (2 倍のストレージ スペースを購入する必要があります)。

あなたは私たちの誰よりもあなたの要件をよく知っていますが、これについてもう一度考えてみることをお勧めします. 16 ビット整数 (0 ～ 65535) が csv ファイルに格納されている場合、.tsv ストレージ効率は約 33% です。ほとんどの 16 ビット整数と区切り文字を格納するのに 5 バイトかかります = 6 バイトですが、ネイティブ整数は2バイトを取ります。浮動小数点データの場合、効率はさらに悪くなります。

既存のデータを取得し、そのまま保存する代わりに、次の 2 つの方法で処理することを検討します。

  1. よく知られている圧縮形式 (gzip や bzip2 など) で圧縮して、永続的なアーカイブ メディア (バックアップ サーバー、テープ ドライブなど) に保存し、.tsv 形式の利点を保持します。
  2. 保存効率の良いデータベースに加工します。ファイルが固定された厳密な形式 (たとえば、列 X は常に文字列、列 Y は常に16 ビット整数) である場合、おそらく問題はありません。それ以外の場合は、NoSQL データベースの方が適している可能性があります (Stefan の回答を参照)。

これにより、データ損失のリスクが低い監査可能な (ただし、アクセスが遅くなる可能性がある) アーカイブと、いつでもデータベースに再読み込みできるため、ソース データの損失を心配する必要のない迅速にアクセス可能なデータベースが作成されます。アーカイブから。

あなたが述べているように、ストレージスペースを減らすことができ、2倍のストレージスペースを必要としないはずです.

インデックス作成は難しい部分です。効率的にクエリを実行できるようにするために必要なデータのサブセットをよく理解しておく必要があります。

于 2010-07-29T21:40:39.533 に答える
2

これらの nosql データベースの 1 つが機能する可能性があります。フラットな区切りファイルの上に配置するように構成できるものがあるとは思えません。オープン ソース プロジェクトの 1 つを見て、独自のデータベース レイヤーを作成することもできます。

于 2010-07-29T21:00:05.670 に答える
2

スケーラビリティは、タブ区切りの ASCII を超えたところから始まります。

ただ実用的であること - アカデミック化しないでください - 慣習はあなたの指だけでなくあなたの心をも解放します.

于 2010-07-29T21:30:06.250 に答える
1

質問はすでに回答済みであり、私はステートメントの大部分に同意します。

私たちのセンターでは、「40TBのデータがあるので」という標準的な講演を行っています。これは、科学者が常にこの状況に新たに直面しているためです。話は名目上は視覚化についてですが、主にそれが初めての人のために大量のデータを管理することについてです。私たちが伝えようとしている基本的なポイントは次のとおりです。

  • I/Oを計画する
    • バイナリファイル
    • 可能な限り、大きなファイル
    • 並行して読み取ることができるファイル形式、抽出されたサブ領域
    • 数え切れないほどのファイルを避ける
    • 特に、単一のディレクトリに無数のファイルを含めることは避けてください
  • データ管理は拡張する必要があります：
    • 来歴のメタデータを含める
      • 再実行の必要性を減らす
    • 賢明なデータ管理
      • それが常に機能する場合にのみ、データディレクトリの階層
    • データベース、メタデータを許可するフォーマット
  • スケーラブルで自動化可能なツールを使用します。
    • 大規模なデータセットの場合、並列ツール-ParaView、VisItなど
    • スクリプト可能なツール-gnuplot、python、R、ParaView / Visit ..
    • スクリプトは再現性を提供します！

大規模なI/Oは、科学者にとってますます一般的な障害となっているため、一般的にかなりの量があります。

于 2012-02-12T15:18:47.840 に答える
1

.NET環境を使用している場合は、LINQtoObjectsを使用してこれを行うことができます。ストリーミング/遅延実行、関数型プログラミングモデル、およびすべてのSQL演算子。結合はストリーミングモデルで機能しますが、1つのテーブルが引き込まれるため、大きなテーブルを小さなテーブルの状況に結合する必要があります。

データの形成のしやすさと独自の表現を書く能力は、科学的なアプリケーションで本当に輝いています。

区切られたテキストファイルに対するLINQは、LINQの一般的なデモンストレーションです。LINQに表形式のモデルを提供する機能を提供する必要があります。いくつかの例のテキストファイル用のGoogleLINQ（たとえば、http ：//www.codeproject.com/KB/linq/Linq2CSV.aspx、http：//www.thereforesystems.com/tutorial-reading-a-text-file-を参照） using-linq /など）。

学習曲線を期待しますが、それはあなたの問題に対する良い解決策です。このテーマに関する最良の治療法の1つは、Jon SkeetのC＃の詳細です。マニングの最新版に早期アクセスするには、マニングから「MEAP」バージョンを入手してください。

私は以前、このような作業を、クレンジング、重複排除、および追加が必要な大規模なメーリングリストで行ってきました。あなたは常にIOバウンドです。ソリッドステートドライブ、特に書き込みパフォーマンスが非常に速いIntelの「E」シリーズを試して、可能な限り並列にRAID化してください。グリッドも使用しましたが、データを削減するマルチパスアプローチを実行するためにアルゴリズムを調整する必要がありました。

データが非常に規則的である場合、データベースへのロードとインデックス作成に重点を置く他の回答に同意することに注意してください。その場合、基本的にETLを実行します。これは、ウェアハウスコミュニティでよく理解されている問題です。ただし、データがアドホックである場合は、結果をディレクトリにドロップするだけの科学者がいます。「アジャイル/ジャストインタイム」変換が必要です。ほとんどの変換がシングルパスである場合は、...ここで...参加して、あなたはそれに正しい方法で近づいています。

于 2010-07-29T21:08:08.417 に答える
1

評判がよければ、ジェイソンの推薦に賛成します。私の唯一の追加は、データベースのような別の形式で保存しない場合、最初に処理するときに一度だけではなく、すべての操作で解析コストを支払うことを提案していたことです。

于 2010-07-29T21:47:27.430 に答える
1

これはVelocityDBで実行できます。タブ区切りのデータを C# オブジェクトとデータベースに読み込むのは非常に高速です。ウィキペディアのテキスト全体は 33GB の xml ファイルです。このファイルを読み込んでオブジェクト (ウィキペディアのトピックごとに 1 つ) として保持し、コンパクトなデータベースに保存するのに 18 分かかります。ダウンロードの一部として、タブ区切りのテキスト ファイルを読み込む方法について、多くのサンプルが示されています。

于 2012-02-12T06:53:54.447 に答える