4

いくつかの大きな (200 GB が通常) データのフラット ファイルがあり、データが論理的に編成されている直感的な方法ですばやくアクセスできるように、ある種のデータベースに保存したいと考えています。これは、非常に長いオーディオ録音の大きなセットと考えてください。各録音は同じ長さ (サンプル) で、行と見なすことができます。これらのファイルの 1 つには、通常、それぞれの長さが 2,000,000 サンプルの約 100,000 の録音が含まれています。

これらの記録を BLOB データの行としてリレーショナル データベースに格納するのは簡単ですが、データ セット全体の特定の列 (サンプル 1,000 ～ 2,000 など) のみをメモリにロードしたい場合がよくあります。これを行うための最もメモリ効率と時間効率の良い方法は何ですか?

推奨事項を作成するために、私のデータの詳細についてさらに明確にする必要がある場合は、遠慮なくお尋ねください.

編集：データの次元を明確にするために... 1つのファイルは、100,000行（記録）×2,000,000列（サンプル）で構成されています。私が調査したほとんどのリレーショナル データベースでは、1 つのテーブルに最大で数百から数千の行が許可されます。繰り返しになりますが、私はオブジェクト指向データベースについてあまり知らないので、そのようなものがここで役立つのではないかと思っています。もちろん、良い解決策は大歓迎です。ありがとう。

編集：データの使用法を明確にするために...データは、私が作成するカスタムデスクトップ/分散サーバーアプリケーションによってのみアクセスされます。各データ「セット」 (これまでは 200 GB ファイルと呼んでいました) には、メタデータ (収集日、フィルター、サンプル レート、所有者など) があります。また、各レコーディングに関連付けられたメタデータもあります (テーブル内の行になることを望んでいたので、レコーディング メタデータの各部分に列を追加するだけで済みます)。すべてのメタデータは一貫しています。つまり、特定のメタデータが 1 つの記録に存在する場合、そのファイル内のすべての記録にも存在します。サンプル自体にはメタデータがありません。各サンプルは、8 ビットの単純なバイナリ データです。

4

4 に答える 4

2

DBストレージは、大きなファイルには理想的ではない場合があります。はい、できます。はい、動作します。しかし、DBバックアップはどうですか？ファイルの内容は頻繁には変更されない可能性があります。一度追加すると、同じままになります。

ファイルをディスクに保存することをお勧めしますが、DBベースのインデックスを作成します。フォルダ/ディレクトリなどに10,000を超えるファイルがあると、ほとんどのファイルシステムが不安定になったり遅くなったりします。アプリケーションは、ファイル名を生成してメタデータをDBに保存し、生成された名前でディスクに整理できます。欠点は、ファイルの内容が名前から直接わからない場合があることです。ただし、特殊なDBバックアッププラグインや高度なパーティショニング、増分バックアップスキームがなくても、変更されたファイルを簡単にバックアップできます。また、ファイル内のシークははるかに簡単な操作になります（先にスキップ、巻き戻しなど）。一般に、DBよりもファイルシステムでのこれらの操作のサポートが優れています。

于 2011-12-29T16:58:09.200 に答える
1

RDBMS が数千行に制限されると思われるのはなぜでしょうか。これが事実である理由はありません。

また、少なくとも一部のデータベース (例として Oracle) では、必要なオフセットと長さがわかっている場合、LOB 全体をロードせずに LOB データの一部に直接アクセスできます。したがって、検索可能なメタデータと LOB 列を含むテーブルを作成し、必要に応じて、LOB コンテンツのメタデータを含む追加のメタデータ テーブルを作成して、ある種のキーワード->(オフセット,長さ) 関係を利用できるようにすることができます。 LOB の部分ロード用。

ここでの別の投稿に多少反響しますが、増分バックアップ (ここで行いたいと思うかもしれません) は、データベースでは実現可能ではありません (可能かもしれませんが、少なくとも私の経験では、厄介な値札が付けられる傾向があります)。

于 2011-12-29T21:23:18.583 に答える
0

Microsoft SQL は、filestream ストレージと組み合わせて使用​​される varbinary(MAX) フィールド型 WHEN で必要なことを行うと思います。

詳細については、TechNetを参照してください: (http://technet.microsoft.com/en-us/library/bb933993.aspx)。

基本的に、任意の説明フィールドを通常どおりデータベースに入力できますが、実際の BLOB は NTFS に格納され、SQL エンジンによって管理され、NTFS ファイル システムによってのみサイズが制限されます。

これがお役に立てば幸いです - 私はそれが私の心にあらゆる種類の可能性をもたらすことを知っています. ;-)

于 2011-12-29T22:07:10.940 に答える
0

各サンプルの大きさと各録音の大きさは? 各録音が 2,000,000 サンプル、または各ファイルが 2,000,000 サンプルだと言っているのですか? （どちらでも読めます）

200 GB を構成するサンプル数が 200 万の場合、各サンプルは ~10 K で、各記録は 200K になります (ファイルごとに 100,000、記録ごとに 20 サンプル)。

これは、ディスク上のファイルではなく、DB に行を配置するのに非常に妥当なサイズのようです。

特定の範囲のみをメモリにロードする場合、サンプル ID にインデックスを付けていれば、DB クエリの結果からその範囲のみをメモリにロードして、必要なサブセットのみを非常に迅速にクエリできます。

于 2011-12-29T16:44:48.803 に答える