【问题标题】:Couchdb Mango Performance vs Map Reduce ViewsCouchdb Mango 性能与 Map Reduce 视图
【发布时间】:2016-11-22 23:12:56
【问题描述】:

我刚刚注意到,在 Couchdb 2.0 的 the release notes 中,提到了建议将 Mango 查询用于新应用程序。还提到 Mango 索引显然比 javascript 查询快 2 倍到 x10 倍,这真的让我感到惊讶,因此我有很多问题:

  • 是否正在逐步淘汰 Map/Reduce 视图?我希望答案是否定的,因为在我看来 Mango 并没有涵盖 Map/Reduce 的所有用例(最简单的例子是 Reduce 本身),而且这种查询风格的灵活性似乎也更加有限。但是因为推荐,我更喜欢问:

我们建议所有新应用开始默认使用 Mango。

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

我所追求的一方面是对 Mango 的一些见解,另一方面是对 Mango 和 Map/Reduce 在 2.x 时代应该如何共存的概述。

【问题讨论】:

    标签: couchdb couchdb-mango


    【解决方案1】:

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

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

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

    【讨论】:

    • 视图和列表是一个令人难以置信的组合。很遗憾看到列表被弃用。
    【解决方案2】:

    核心开发者的回答:

    一些很好的问题。我认为 Mango 永远不会取代 Map/Reduce 完全地。它是一种替代查询工具。有什么了不起的 Mango 查询语法是它更容易理解和 开始吧。我们可以在很多地方使用它 查询文件。它可用于复制过滤和 更改提要。我们希望尽快支持验证文档 更新。

    Mango 下面使用 erlang map/reduce。这意味着它是 像 map/reduce 一样创建 B-tree 索引。让它更快的是 它正在使用 erlang/native 函数来创建 B-Tree 的JavaScript。我很久以前写了一篇关于内部的博客文章 PouchDB-find [1] 是 PouchDB 的芒果语法。它可能 帮助您更多地了解内部是如何工作的。钥匙 要理解的是,有一个 Map 查询部分使用 B-Tree 和内存过滤器。理想情况下,过滤您的内存越少 查询速度越快。

    我会说 Mango 在很大程度上是一项正在进行的工作,但基本 地面工作已经完成。肯定有我们可以改进的地方。 当开发人员开始一个新项目时,我已经看到它使用了很多 因为它可以快速简单地进行基本查询,例如通过电子邮件查找 地址或查找所有名为“John Rambo”的用户。

    希望对您有所帮助。

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

    【讨论】:

    • 这个答案的来源是什么?我知道它来自核心开发人员 - 谁?
    【解决方案3】:

    我是 Mango 和 CouchDB 的新手,但我想我可以提供一些见解。一旦你的索引/视图更新,Mango 并没有更快。 Mango 的巨大性能提升是在您第一次创建索引时,因为 couch 不需要为此创建单独的 couchjs 进程。

    我发现即使您的某些文档很大,Mango 也能很好地工作。目前在 CouchDB 2.0.0 中,至少在 windows 中,大型文档会使与 Map/Reduce 一起使用的 couchjs.exe 视图服务器崩溃。 CouchDB 1.6.1 不是这种情况,并且已经在开发版本中修复https://github.com/apache/couchdb-couch/commit/1659fda5dd1808f55946a637fc26c73913b57e96

    【讨论】:

    • 我可以确认大型文档的内存问题,couchjs 对我来说也是一个大问题。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-02-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多