内存管理方法中RavenDb与CouchDb的比较

Question

RavenDB (一个支持查询的.Net JSON存储数据库)在它自己的控制下(通过它自己的存储引擎Munin)提供了积极的缓存/内存管理，并带有配置参数来调整各种缓存大小等。Google group建议，以前(最新版本可能不是这种情况)由于未调优参数(具有足够大小的db / index)而偶尔出现内存不足异常。

CouchDB似乎采取了一种不同的方法，将缓存留给了操作系统。这意味着，当我获得/db1/doc-id-1时，它对于针对文件系统编写文件读取操作至关重要，因为操作系统可以优化文件系统，因为它有自己的缓存。同样，我相信这对于视图和reduce结果也是一样的(b树的多个部分需要根据范围从磁盘加载/计算)。

后者对我来说似乎更好，操作系统在缓存/分页等方面已经经历了多年的演变。来自其他服务的压力可以平衡内存。

首先。我的理解是正确的吗？CouchDB的方法是基于Unix的OSes所独有的吗(尽管我看到他们有一个Windows端口)？.Net数据库不能依赖于操作系统来优化文件读取等等，这是有原因的吗？在构建数据存储时，影响选择的每种方法的优缺点是什么？

附注:我相信Redis是一样的，只是将索引保存在内存中，每个GET键都是磁盘命中(这取决于操作系统文件缓存是否命中磁盘头)。

Answer 1

Jia93，我们之所以这样工作，其中一个原因是我们在各层之间有了更强的分离。CouchDB与我们有很多相同的优化(将东西保存在内存中)，但它是在直接向应用程序公开的BTree结构之上进行优化的。

缓存结果的另一个原因是避免在每个请求上解析json的成本。