メモリ管理アプローチのRavenDbとCouchDb

Question

RavenDB（クエリを使用した.Net JSONストレージストレージデータベース）は、さまざまなキャッシュサイズなどを調整するための設定パラメータを使用して、独自のストレージエンジンMuninを使用して積極的なキャッシュ/メモリ管理を提供します。 ... Googleグループは、チューニングされていないパラメータ（十分なサイズのdb/indexを持つ）の結果として、以前は（最新のリリースではそうでないかもしれない）時々メモリ外の例外を示唆しています。

CouchDBは異なるアプローチをとっているようで、オペレーティングシステムにキャッシュを残しています。意味は、私がGET/db1/doc-id-1を書くときには、OSが独自のキャッシュのために最適化できるファイルシステムに対してファイルを読み込むということです。同様に私はこれがビューと結果を減らすために同じであると考えています（bツリーの複数の部分は、範囲に応じてディスクからロード/計算する必要があります）。

後者は私にとって優れているように見えますが、OSはキャッシュ/ページングなどで何年もの進化を遂げています。

まず、 私は理解していますか？ CouchDBのアプローチはUnixベースのOS特有です（Windowsポートがあるとは思いますが）。 .Net DBがOSに依存しないため、ファイルの読み込みを最適化するなどの理由がありますか？ データストアを構築する際の選択に影響する、各アプローチの短所と利点は何ですか？

サイドノート：私は、各キーが（ディスクヘッドを打つかどうかOSのファイルキャッシュに依存しないのいずれか）ディスクヒット

Answer 1

Jia93でGET、Redisのは、単にメモリ内のインデックスを維持すると同じであると信じて、 私たちがやっているやり方で作業している理由の1つは、レイヤー間の分離が強くなっていることです。 CouchDBは、私たちがやっているのと同じように（mem内にあるものと同じ）最適化を行っていますが、アプリケーションに直接公開されているBTree構造の上でこれを行っています。

結果をキャッシュする別の理由は、1回のリクエストごとにjsonを解析するコストを避けることです。