節省空間的視圖

Question

對於具有特定type的所有文檔，我在我的應用中只有一個查詢，它只選擇最後一個文檔的單個字段。我按日期映射這些文檔，因此將降序查詢限制爲1應該可以做到。我所困擾的問題是這個視圖會緩存所有這種類型的文檔，佔用顯然多餘的空間。

所以我的問題是：

1. 將加入降低功能，這將減少對單一最後一個文檔，這種觀點節省任何空間，我還是認爲仍然必須存儲所有相關的文件？
2. 如果沒有，是否還有其他節省空間的策略？

Answer 1

1. 編號空間仍然會被地圖功能的結果浪費。
2. 此刻我腦海中有些東西：
   • 更改數據庫的設計。如果文檔的ID包含類型和日期，則可以在沒有地圖/縮小的情況下進行一些搜索，如下所示：http://127.0.0.1:5984/YOURDB/_all_docs?start_key="<TYPE>_<CURRENT_TIME>"&descending=true&limit=1。
   • 儘量使用map。不發射任何值，地圖將存儲文檔的密鑰和id/ver。在查詢時使用include_doc來檢索文檔。
   • 添加其他字段，說明文檔是最後一個候選文檔。只映射那些擁有該領域的候選人。定期運行清理，從除最新文檔之外的所有文檔中刪除該字段。注意：在刪除最後添加的文檔時，這可能很困難。

這似乎是對我的CouchDB的想法：通過緩存查詢「浪費」的空間，讓他們能夠通過快速回答如果數據沒有變化頻繁。也許如果你非常在意浪費空間，那麼你的情況不是CouchDB的答案？

Answer 2

我的couchdb安裝程序有sperate RAID驅動器上的數據和索引。地圖是用erlang編寫的，我發現它的速度比JavaScript快8倍，地圖當然返回null。我保持鍵小，我也打破了我的觀點，跨越許多設計文件，我保持我的數據非常平坦，這提高了序列化性能。