web-dev-qa-db-ja.com

超高速ファイルストレージエンジン

私は基本的に、次のフィールドを持つデータベースに1つの大きな巨大なテーブル（約1.000.000.000.000レコード）を持っています。

id、block_id、record

idは一意であり、block_idは一意ではなく、block_idが同じでレコードが異なる約10k（最大）のレコードが含まれます

DBを扱う仕事を簡略化するために、次のようなAPIを持っています。

Engine e = new Engine(...);
// this method must be thread safe but with fine grained locked (block_id) to improve concurrency
e.add(block_id, "asdf"); // asdf up to 1 Kilobyte  max

// this must concatenate all the already added records added block_id, and won't need to be bigger than 10Mb (worst case) average will be <5Mb
String s = e.getConcatenatedRecords(block_id);

各ブロックをファイルにマップする場合（まだ実行していない場合）、各レコードはファイル内の1行であり、そのAPIを引き続き使用できます

しかし、よく調整されたpostgresqlデータベースと比較して、フラットファイルを使用することでパフォーマンスが向上するかどうかを知りたいですか？ （少なくともこの特定のシナリオでは）

ただし、私の最大の要件は、getConcatenatedRecordsメソッドが愚かに高速に戻ることです（追加操作ではそうではありません）。キャッシングとメモリマッピングも検討していますが、この種類のシナリオで既に作成されたソリューションがあるかどうかを尋ねる前に、自分を複雑にしたくありません。

javaperformanceconcurrencypostgres
2
David Hofmann

いくつかの研究の後。これらのデータストアは、私が持っているほとんどのユースケースに役立つことがわかりました。

興味深い部分は、Javaコレクション（リスト、セット、マップ...）のAPIをほとんどサポートしていることです。

これらすべてのプロジェクトでは、ファイルを巨大なコレクションのデータストアとして開くことができ、名前でそれらを参照できます。また、ファイルごとに多くのコレクションが存在する場合があります。それらのそれぞれにインデックスが付けられます。これらのプロジェクトは実際のデータベースの基盤として使用されるという考えであり、データベースのデータストアエンジン（SQLまたはNoSQL）として見ることができます。

これらのプロジェクトは、mongodb、h2database、orientdbなどのプロジェクトの基盤であるため、単純化したデータストアのアプローチが私のニーズに合っている場合は、問題なくスケーリングできると確信しています。私のパーティションのニーズは非常に単純なので、他のノードと負荷を共有することもできます。

2
David Hofmann

非常にシンプルな抽象化インターフェースを備えた「ストレージシステム」のようです。本質的には「これはid、gimmeデータです」です。

したがって、このインターフェイスを簡単に定義して、アプリ全体をその上に構築できます。舞台裏では、今日と同じようにPostgreSQLを使い続けることができます。また、フラットファイルストレージを試す場合は、ディスク上でファイルを直接読み書きする非常にシンプルなものを実装するのに1日または2日以上かかるはずです（最初の部分に基づいて1〜3層のディレクトリを用意することをお勧めします） IDの1つであるため、1つのフラットディレクトリに多くのファイルが存在することはありません）。

その場合は、パフォーマンスを直接比較して、それで十分かどうかを確認できます。

ただし、Euphoricが指摘したように、ほとんどのNOSQLストアは、達成しようとしているまさにその目的のために導入され、人気を博しました。特定の店をお勧めするつもりはありません。それはあなたが決めることですが、それらが提供するいくつかの利点は次のとおりです。

  1. バッファリングし、より大きなチャンクで書き込みを行うことにより、大量の小さなエンティティのストレージを管理します。私の経験では、ほとんどのファイルシステムは非常に多数のファイルを処理できますが、最も効率的な方法では機能しません。たとえば、ディスクからその数のファイルを削除しようとした場合、ディスク全体を再フォーマットしない限り、「rm -rf *」コマンドだけで数時間かかることがあります。
  2. 単一の物理ボックスの制限を超えた場合、多くのNoSQLソリューションを使用して水平方向にスケーリングできるため、a）より多くのストレージ、b）データの冗長性により、1つのホストがダウンしてもストレージサーバーはオンラインのままです。 c）クライアントは情報を取得する場所で負荷を分散できるため、クエリ時間が短縮されます。

考慮すべきもう1つのオプションは、ストレージとインデックス作成を同じシステムに実装する必要がないことです。 SolrやElasticsearchなどの個別のインデックス製品を使用して、実際のデータをNoSQL DB（またはストレートアップファイルシステム）に保存できます。

4
DXM

Key-value NoSQL このシナリオでは、データベースが実際に作成されます。あなたのケースでは、キー値ストアの上に セカンダリインデックス のようなものを探しています。

私はこの分野での経験がないので、具体的な実装や使用するツールを説明することはできません。しかし、私はあなたがあなたのニーズに合うことができる何かを見つけることができると信じています。

2
Euphoric