用戶上次訪問CouchDB的時間

我是CouchDB的新手，但這與問題無關。這個問題很簡單，但我不清楚。用戶上次訪問CouchDB的時間

例如：鮑里斯5秒鐘前在網站上查看他的個人資料伊凡看到它。

如何正確實現此功能（用戶上次訪問時間）？

問題是，如果我們更新用戶在CouchDB中的配置文件，例如。 last_access_time屬性，每次頁面刷新時，我們都會得到最相關的信息（在MySQL中，我們是這樣做的），但另一方面，我們將在文檔的末尾有大約100000 ++的文檔_rev那天。

那麼，你如何做到這一點，或者你有什麼想法？

來源

2011-01-30 unno

答案取決於您是使用Couch應用程序（直接瀏覽器連接到CouchDB）還是傳統的中間層（例如PHP，Ruby on Rails，Tomcat，Django）。這是什麼？謝謝。 – JasonSmith 2011-01-31 04:48:03

如果文檔中（很大一部分）是相對靜態的，而且（小部分）是高度動態的，那麼我會考慮將它分成兩個不同的文檔。

另一種選擇可能是使用更適合這種性質的小塊數據（如Redis或可能的MongoDB）的高寫入吞吐量，並且（如有必要）有後臺任務偶爾將信息寫入CouchDB。

來源

2011-01-30 21:03:15 Evan

+1，即使我有相互競爭的答案，我同意Redis是一個好主意。定期同步的快速更新對於Redis來說是完美的。儘可能遠離CouchDB;這取決於您的應用程序的整個利弊。但Redis（memcache等）無論如何都是應用程序的普遍增強。 – JasonSmith 2011-01-31 05:10:04

CouchDB在快速文檔更新中沒有問題。就像MySQL一樣。高_rev是沒有問題的。

唯一的問題是，您必須對從第1天開始的沙發負責。所有CouchDB用戶都必須這樣做，但您可能需要儘快完成此操作。（有一些更新的應用程序有一個全盤的風險較低，因此開發人員可以推遲這項工作。）

民意調查數據庫和運行壓縮是否需要它（根據大小，文件數，seq_id號）
輪詢您的觀點並進行壓縮
始終有足夠的磁盤容量和I/O帶寬來支持壓縮。數學最差情況：您需要數據庫大小的兩倍，寫入速度是兩倍;但是，大多數應用程序需要較少。由於您正在更新文檔，不添加它們，您將需要方式更少。

來源

2011-01-31 04:57:57 JasonSmith

這不是一個完整的答案，而是一個可能的優化。除了這裏的任何其他答案之外，它將起作用。

除了存儲最新的時間戳之外，只有在時間戳已經被例如改變後才更新時間戳。 5秒或60秒。

假設用戶每天刷新一天。這是86,400更新。但是，如果您只更新5秒間隔的時間戳，即17,280; 60秒是1440。

您可以在客戶端執行此操作。當你想更新時間戳時，獲取當前文檔並檢查舊的時間戳。如果它是小於 5秒鐘，不要做任何事情。否則，請正常更新。

你也可以在服務器端做到這一點。在CouchDB中編寫一個_update函數，您可以像查詢那樣查詢。 POST /db/_design/my_app/_update/last-access/the_doc_id?time=2011-01-31T05:05:31.872Z。更新函數將執行相同的操作：檢查舊時間戳，並且不執行任何操作，或根據已用時間更新它。

來源

2011-01-31 05:06:25 JasonSmith

謝謝你的回答。看起來60秒延遲是安靜的，所以我會用它。 – unno 2011-01-31 14:18:10

用戶上次訪問CouchDB的時間

回答

相關問題