Couchdb芒果性能vs地圖減少查看

Question

我剛剛注意到，在Couchdb 2.0的the release notes，它被提及芒果查詢推薦用於新的應用程序。它也mentionned，顯然芒果指數從2倍到X10不是JavaScript查詢這着實讓我吃驚得更快，因此我有一些問題：

• 是的Map/Reduce的觀點被淘汰？我期待答案是否定的，因爲在我看來，Mango並沒有涵蓋Map/Reduce的所有用例（最簡單的例子就是Reduce本身），而且這種查詢風格的靈活性似乎也更加有限。但米喜歡問，因爲該建議：

我們建議所有新應用開始使用芒果作爲默認值。

• 我們知道的Map/Reduce意見依靠B樹，但我找不到任何見解，在文檔或關於芒果背後神奇的郵件列表。芒果對於我來說基本上是白色的魔法。然而，我可以說，深入瞭解javascript視圖如何在幕後編入索引，對於避免陷阱，簡化實現以及優化性能非常有幫助。有沒有人有任何關於芒果如何工作的見解？索引B-trees是否也是？由於不再有設計文件，何時更新索引？性能收益從哪裏來？ （這些收益對我來說是違反直覺的，因爲在我的理解中，javascript查詢的性能來自Map函數的預先計算性質）

我基本上追求的是一方面關於芒果另一方面，概述Mango和Map/Reduce如何在2.x時代共同生活。

Answer 1

答：

一些很好的問題。我不認爲芒果會完全取代Map/Reduce 。它是一種替代查詢工具。芒果查詢語法 的好處在於它更容易理解，並且 開始使用。我們可以在 以外的很多地方查詢文檔。它可用於複製過濾和 更改提要。我們希望很快能夠支持驗證文檔 更新。

芒果底下是使用erlang map/reduce。意思是 就像map/reduce那樣創建一個B樹索引。使其更快的是 它使用erlang/native函數來創建B-Tree，而不是使用javascript的 。我很久以前寫了一篇關於PouchDB-find [1]的內部 的博客文章，這是PouchDB的芒果語法。它可能幫助你更多地理解內部工作。要了解的關鍵是 有一個Map查詢部分，它使用了B樹和內存中的過濾器。理想情況下，內存過濾越少，您的查詢速度越快。

我想說芒果是一個在製作中的工作，但基本的工作已經完成。肯定有些事情我們可以改進。 當開發人員開始一個新項目 時，我發現它很有用，因爲它可以快速簡單地進行基本查詢，比如通過電子郵件地址 查找地址或查找名爲「John Rambo」的所有用戶。

希望有所幫助。

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

Answer 2

我最近嘗試將我的應用程序切換爲使用芒果查詢，並將結果完全取消並切換回地圖/縮小。以下是我的一些原因：

1. 芒果在處理不完全指定要使用的索引的查詢時出錯。上週末這段時間讓我bat bat了一陣子。如果您未指定索引，則有時會選擇替代索引並返回無（或不正確）結果。
2. 芒果的表現不是'魔術'。許多類型的查詢最終都會在內存搜索中進行。沙發將選擇最合適的指數，然後穿過記憶中的所有記錄以適應角落案例。 Cloudant通過說使用基於「文本」的搜索來解決其中一些問題，這些搜索在Couchdb中不可用。
3. 正如您所指出的，芒果搜索根本無法很好地處理某些類型的查詢結構。我不認爲我的應用過於複雜，但我遇到了幾種情況，我無法爲手頭的任務構建合適的芒果查詢。這裏主要是搜索數組來查找標籤（例如，搜索查看哪些用戶是組的成員）。芒果不能索引數組元素，因此可以在內存中進行全面掃描。
4. 視圖具有一些非常強大的功能，用於以列表形式對搜索結果進行轉換。這在芒果中不存在。

您的里程可能會有所不同，但只是想留下警告，這仍然是相當新的功能。

Answer 3

我是Mango和CouchDB的新手，但我想我可以提供一些見解。一旦你的索引/視圖更新，芒果沒有更快。芒果的巨大性能增益是當您第一次創建索引時，因爲沙發不需要爲此創建單獨的couchjs過程。

我發現即使你的一些文件很大，芒果也能很好地工作。目前使用CouchDB 2.0.0，至少在Windows中，大型文檔會崩潰與Map/Reduce一起使用的couchjs.exe視圖服務器。這不是使用CouchDB 1.6.1的情況，並已固定在開發版本由核心開發者https://github.com/apache/couchdb-couch/commit/1659fda5dd1808f55946a637fc26c73913b57e96