CouchDB消息應用程序的體系結構選項

Question

我有一個關於couchDB上適用於我的消息應用程序用例的最合適體系結構的問題。

該用例用於一個簡單的消息傳遞平臺，該平臺目前有一個包含所有消息作爲文檔的沙發數據庫。每個文檔都有一個「to」字段，用於指示消息的預期收件人。當客戶端應用程序醒來時，它會在最後一次檢查後向數據庫查詢發送給特定用戶的所有新消息。這是通過使用普通過濾器查詢_changes feed來檢查文檔中「到」字段中是否存在用戶標識來實現的。

據我所知，couchDB的操作，這需要數據庫檢索最後一個序列後的變更飼料的所有文件，並針對他們運行過濾功能。由於在我的用例中新消息的可能性非常低，這會導致相當大的開銷（假設我有100 000個用戶每天獲得兩條消息，它將需要DB讀取全部200 000條消息200 000次，以支持所有用戶？）

選項1：從我讀的是不可能把一個參數過濾器頂部的_changes飼料。這將是很好的，因爲那樣我就可以使用複製功能來提取消息。 - 非入門？

選項2：使用組合「to」字段和更新順序的鍵實現視圖。然後，我可以查詢此視圖以查看用戶值和序列>最後一個序列。 - 在這裏，我正努力從Map函數獲取文檔的更新Seq。 - 這是可行的嗎？

選項3：在服務器上爲每個用戶實施數據庫，並在公用數據庫上爲每個用戶特定數據庫設置複製。然後，用戶查詢她自己的數據庫的_changes訂閱源，該訂閱源僅包含指向她的消息，非常容易。現在您需要在服務器上維護100 000 x 2個複製。這有其他缺點，但可以工作。

從上面，這聽起來像最可行/可擴展的方法？或者我錯過了另一種選擇？

感謝

Answer 1

我會去與選項2取而代之的文件序列ID（我不認爲你可以從視圖功能得到），只是一個日期/時間字段添加到您的郵件文件？

如果您擔心客戶端的時鐘歪斜（您應該發佈這條消息作爲對我的答案的評論，而不是嘗試對其進行編輯，而該錯誤會被拒絕），您可以在檢索中應用一些容差。我假設只是提供一些你已經看到的額外信息並不算太壞。

（我也不會擔心時鐘歪斜，但我不知道你將要使用什麼樣的客戶端。）