RavenDb与CouchDb内存管理方法

RavenDB（一个带有查询功能的.Net JSON存储数据库）在自己的控制下（通过自己的存储引擎Munin）提供积极的缓存/内存管理，并使用配置参数调整各种缓存大小等。。。谷歌集团建议，以前（可能不是最新版本的情况）由于未调整的参数（具有足够大小的db/索引）而偶尔出现内存不足异常

CouchDB似乎采取了不同的方法，将缓存留给操作系统。这意味着当我得到/db1/doc-id-1时，它对于针对文件系统编写文件读取操作非常重要，操作系统可以通过自己的缓存对文件系统进行优化。类似地，我认为视图和reduce结果也是如此（b树的多个部分需要从磁盘加载/计算，具体取决于范围）

后者似乎优于我，OS在缓存/分页等方面经历了多年的发展。。来自其他服务的压力可以平衡内存

首先。 我的理解正确吗？ CouchDB的方法是否是基于Unix的操作系统所独有的（尽管我看到它们有Windows端口）？ 是否有理由.Net DB不能依赖操作系统来优化文件读取等。。？ 在构建数据存储时，每种方法的优缺点是什么

旁注：我相信Redis是一样的，只是将索引保存在内存中，每个GET键都是一个磁盘命中（它要么命中磁头，要么不命中操作系统文件缓存）

93， 我们采用这种方式工作的原因之一是层与层之间有更强的分离。CouchDB的优化与我们的基本相同（将内容保留在mem中），但它是在直接向应用程序公开的BTree结构之上进行的

---

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

CouchDB大量使用OS文件系统缓存来提高性能，而我看到RavenDB在其自己的进程空间中显式地缓存内容。因此，当系统面临压力时（来自其他进程，mysql、apache、IIS等），操作系统文件系统缓存会减少，但CouchDB的内存使用量保持不变。我可以看到避免使用RavenDB方法进行json解析的好处。Net/RavenDB是否提供钩子来检测资源紧张的情况以减少缓存，还是使用软/弱参考系统？