6

何百万ものxmlファイルを保存および取得する簡単な方法を探しています。現在、すべてがファイルシステムで実行されていますが、パフォーマンスに問題があります。

要件は次のとおりです。

  1. バッチプロセスで数百万のxmlファイルを保存する機能。XMLファイルのサイズは最大で数メガバイトで、ほとんどが100KBの範囲です。
  2. IDによる非常に高速なランダムルックアップ（例：ドキュメントURL）
  3. JavaとPerlの両方からアクセス可能
  4. 最も重要なLinuxで利用可能-ディストリビューションとWindows

私はいくつかのNoSQLプラットフォーム（CouchDB、Riakなど）を調べましたが、これらのシステムは見栄えがしますが、ほとんどやり過ぎのようです。

  1. クラスタリングは必要ありません
  2. デーモン（「サービス」）は必要ありません
  3. 巧妙な検索機能は必要ありません

Riakを深く掘り下げてみると、Bitcask（イントロを参照）が見つかりました。これはまさに私が望んでいるもののようです。イントロで説明されている基本は本当に興味をそそられます。しかし、残念ながら、Javaを介してビットキャスクリポジトリにアクセスする手段はありません（またはありますか？）

スー私の質問は要約すると

  • Bitcaskモデル（追加のみの書き込み、メモリ内のキー管理）は、何百万ものドキュメントを保存/取得する正しい方法です。
  • Javaを介して利用可能なBitcaskの実行可能な代替手段はありますか？（BerkleyDBが思い浮かびます...）
  • （riakスペシャリスト向け）Riakは、「裸の」Bitcaskと比較して、オーバーヘッドの実装/管理/リソースの面ではるかに優れていますか？
4

2 に答える 2

6

Bitcaskがあなたのユースケースでうまく機能するとは思わない。Bitcaskモデルは、各値のサイズが比較的小さいユースケース向けに設計されているようです。

問題は、Bitcaskのデータファイルのマージプロセスにあります。これには、多数の「古いデータファイル」から「マージされたデータファイル」にすべてのライブ値をコピーすることが含まれます。それぞれ100Kbの領域に数百万の値がある場合、これは非常に大量のデータコピーです。

上記は、XMLドキュメントが比較的頻繁に更新されることを前提としていることに注意してください。更新がまれである場合、および/または大量のスペースの「無駄」に対処できる場合は、マージを行う必要があるのはまれであるか、まったく必要ない場合があります。

于 2011-05-15T14:28:56.140 に答える
4

大量の上書きがあるかどうかに応じて、この場合（大きな値）にはビットキャスクが適切な場合があります。特に、新しい値が古い値と同じキーで到着した場合にのみ発生する大量の無駄なスペースがない限り、ファイルをマージする理由はありません。

Bitcaskは、着信データストリームをディスクに直接書き込むため、このバッチロードの場合に特に適しています。ほとんどの場合、ルックアップには1回のシークが必要ですが、一時的な局所性がある場合はファイルキャッシュが役立ちます。

Javaバージョン/ラッパーのステータスがわかりません。

于 2011-05-17T06:03:05.473 に答える