爲什麼CouchDB文檔提示文檔不應該在視圖中發佈？

在第一個示例（http://docs.couchdb.org/en/1.6.1/couchapp/views/collation.html#views-collation）下的CouchDB官方文檔的視圖歸類章節中，建議不建議在視圖中發佈文檔本身，而是建議在包含文檔的主體時包含文檔的主體請求視圖，請求?include_docs=true。爲什麼CouchDB文檔提示文檔不應該在視圖中發佈？

如果我理解正確的話，而不是：

emit(doc._id, doc);

，並得到結果的格式如下：

{"id":"1","key":"1","value":{"_id": "1", "someProp": "someVal"}},

故建議空值發送發出：

emit(doc._id, null)

然後當使用include_docs參數查詢我的視圖以下列形式獲取結果時在：

{ 
    "id": "1", 
    "key": "1", 
    "value": null, 
    "doc": { 
     "_id": "1", 
     "_rev": "1-0eee81fecb5aa4f51e285c621271ff02", 
     "someProp": "someVal" 
}

如果有人建議，比我假設的是，性能會更好，但不幸的是，文件沒有詳細說明爲什麼和其他的例子發出文件通常在信號發送的值。任何人都可以在這方面得到更多的啓示

來源

2016-03-24 sigman.pl

當您在視圖中整個文檔emit時，您正在有效地複製磁盤上的文檔。這是因爲每個視圖都有自己的文件，其中包含在數據庫上運行視圖的結果。因此，如果您有3個視圖在輸出文檔的位置，則有4個副本在浮動。（不包括文檔的多個修訂版本，這當然會增加更多的重複項）

CouchDB非常寬鬆地使用磁盤空間，以便使寫入發生得更快，很大程度上是由於他們選擇使用僅附加結構。因此，使用視圖重複輸出相同的文檔可能會導致磁盤使用情況迅速增長。（壓縮你的數據庫和視圖通常是有幫助的，但它不應該是你想要不斷強制你進入的東西）

將文檔留出的權衡是，當你從視圖中讀取時，CouchDB需要在內部找到文檔並將其包含在視圖的輸出中。由於它基於id查找事物，所以它是一個非常快速的操作，但它仍然會產生開銷。因此，儘管這種模式通常是最佳實踐，但您應該開放考慮應用環境下的權衡。

來源

2016-03-25 04:23:19

感謝Dominic，因此在查詢時收集emit（doc._id，doc）速度更快，但使用include_docs = true的更多磁盤空間用於緩存/索引vs emit（doc._id，null）可能會更慢，因爲引擎由於缺少緩存/索引文檔，需要進行查詢，但是我們節省了磁盤空間。 –

@Dominic Barnes你能確定sigman.pl在他的評論中寫道什麼嗎？ – Magiranu

@Magiranu對我來說聽起來是對的 –

爲什麼CouchDB文檔提示文檔不應該在視圖中發佈？

回答

相關問題