RavenDB（带查询的.Net JSON存储存储分区）在其自己的控制下（通过自己的存储引擎Munin）提供积极的缓存/内存管理，配置参数可调整各种缓存大小等... Google团队建议之前（可能不是最新版本的情况）由于未调整的参数（具有足够大小的db / index）而偶尔会出现内存不足异常。
CouchDB似乎采取了不同的方法，并将缓存留给了操作系统。在GET / db1 / doc-id-1时的含义，对于文件系统编程文件系统而言，这是必不可少的，操作系统可以根据自己的缓存进行优化。同样地，我相信这对于视图和减少结果是相同的（b树的多个部分需要根据范围从磁盘加载/计算）。
后者似乎优于我，操作系统已经从多年的缓存/分页等方面发展而来。来自其他服务的压力可以平衡内存。
首先。 我的理解是正确的吗？ CouchDB的方法是基于Unix的操作系统独有的（虽然我看到他们有一个Windows端口）？ 有没有理由.Net DB不能依赖操作系统来优化文件读取等。？ 每种方法有哪些缺点和优势会影响构建数据存储的选择？
旁注：我认为Redis只是将索引保留在内存中，每个GET KEY都是一个磁盘命中（根据操作系统文件缓存，它是否会击中磁盘头）
答案 0 :(得分：2)
Jia93， 我们按照我们的方式工作的原因之一是我们在层之间有更强的分离。 CouchDB具有与我们相同的优化（将内容保留在mem中），但它是在直接暴露给应用程序的BTree结构之上进行的。
缓存结果的另一个原因是避免在每个请求上解析json的成本。