Couchdb Mango 性能与 MapReduce View 的比较

Question

我刚刚注意到 the release notes Couchdb 2.0 中提到，新应用程序推荐使用 Mango 查询。还提到，显然 Mango 索引比 javascript 查询快 2 倍到 10 倍，这确实让我感到惊讶，因此我有很多问题:

• Map/Reduce View 是否正在逐步淘汰？我希望答案是否定的，因为在我看来，Mango 并没有涵盖 Map/Reduce 的所有用例(最简单的例子是 Reduce 本身)，而且这种查询风格的灵 active 似乎也更有限。但由于推荐，我更愿意问:

We recommend all new apps start using Mango as a default.

• 我们知道 Map/Reduce View 依赖于 B 树，但我在文档或邮件列表中找不到任何有关 Mango 背后魔力的见解。芒果对我来说本质上是白魔法。但我可以说，深入了解 javascript View 如何在幕后建立索引对于避免陷阱、简单的实现以及优化性能非常有帮助。有谁了解 Mango 的工作原理吗？索引也是 B 树吗？由于不再有设计文档，索引什么时候更新？性能提升从何而来？ (这些 yield 对我来说是违反直觉的，因为根据我的理解，JavaScript 查询的性能来自于 Map 函数的预先计算性质)

我本质上追求的一方面是对 Mango 的一些见解，另一方面是对 Mango 和 Map/Reduce 在 2.x 时代如何共存的概述。

Answer 1

我最近尝试将我的应用程序切换为使用 Mango 查询，结果完全废弃它并切换回 Map/Reduce。以下是我的一些原因:

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

您的里程可能会有所不同，但只是想留下一个警告，表明这仍然是相当新的功能。