Couchdb芒果性能与地图减少视图

Question

我刚才注意到在Couchdb 2.0 的发行说明中,提到Mango查询建议用于新的应用程序.还有人提到,Mango索引显然比javascript查询快2到x10,这让我感到很惊讶,因此我有很多问题:

• Map/Reduce视图是否被淘汰？我希望答案是否定的,因为在我看来,Mango并没有涵盖Map/Reduce的所有用例(最简单的例子是Reduce本身),而且这种查询风格的灵活性似乎也更加有限.但由于建议,我更愿意提问:

我们建议所有新应用都默认使用Mango.

• 我们知道Map/Reduce视图依赖于B树,但我无法在文档或邮件列表中找到有关Mango背后魔术的任何见解.芒果对我来说基本上是白魔法.然而,我可以说,深入了解javascript视图如何在幕后编入索引,对于避免陷阱,天真实现以及优化性能非常有帮助.有没有人对芒果如何运作有任何见解？索引B树也是吗？由于不再有设计文档,索引何时更新？性能提升来自哪里？(这些收益对我来说是违反直觉的,因为根据我的理解,javascript查询的性能来自Map函数的预先计算性质)

我主要关注的是一方面有关芒果的一些见解,另一方面,概述芒果和地图/减少应该如何在2.x时代共同生活.

Answer 1

我最近尝试将我的应用切换到使用Mango查询,结果是完全废弃它并切换回map/reduce.以下是我的一些原因:

1. 在处理未完全指定要使用的索引的查询时,Mango是错误的.上周末,这个让我吵了一阵.如果未指定索引,则有时会选择备用索引并返回no(或不正确)结果.
2. 芒果表现不是"神奇".许多类型的查询最终会在内存搜索中完成.Couch将选择最适合的索引然后在内存中遍历所有这些记录以适应角落情况.Cloudant通过使用基于文本的搜索来解决其中一些问题,这些搜索在Couchdb中不可用.
3. 正如您所指出的,Mango搜索根本无法很好地处理某些类型的查询构造.我不认为我的应用程序过于复杂,但我遇到了几种情况,我无法为手头的任务构建合适的Mango查询.这里主要的是搜索数组以查找标记(例如,搜索以查看用户是组的成员).Mango无法索引数组元素,因此可以在内存中进行完全扫描.
4. 视图具有一些非常强大的功能,可以以列表的形式转换搜索结果.芒果不存在这种情况.

您的里程可能会有所不同,但只是想留下一个警告,这仍然是一个很新的功能.

Answer 2

来自核心开发人员的回答:

一些好问题.我不认为芒果会完全取代Map/Reduce.它是一种替代查询工具.理解Mango查询语法的好处在于它易于理解和入门.我们可以在很多地方使用它来查询文档.它可用于复制过滤和更改源.我们希望尽快支持验证文档更新.

Mango正在使用erlang map/reduce.这意味着它正在创建一个B树索引,就像map/reduce一样.更快的是它使用erlang/native函数来创建B-Tree而不是javascript.很久以前我写了一篇关于PouchDB-find [1]内部的博客文章,它是PouchDB的芒果语法.它可能会帮助您更好地了解内部的工作原理.要理解的关键是有一个Map查询部分,它使用B-Tree和内存中的过滤器.理想情况下,您执行的内存过滤越少,查询速度就越快.

我会说芒果是一个非常重要的工作,但基本的基础工作已经完成.肯定有一些我们可以改进的东西.我已经看到它在开发人员启动一个新项目时使用了很多,因为它可以快速简单地进行基本查询,例如通过电子邮件地址查找或查找名为"John Rambo"的所有用户.

希望有所帮助.

[1] http://www.redcometlabs.com/blog/2015/12/1/a-look-under-the-covers-of-pouchdb-find