CODEWITHSUNDEEP
couchdb
unno
unno

Reputation: 41

Users last-access time with CouchDB

I am new to CouchDB, but that is not related to the problem. The question is simple, yet not clear to me.

For example: Boris was on the site 5 seconds ago and viewing his profile Ivan sees it.

How to correctly implement this feature (users last-access time)?

The problem is that, if we update users profile document in CouchDB, for ex. property last_access_time, each time a page is refreshed, than we will have the most relevant information (with MySQL we did it this way), but on the other hand, we will have _rev of the document somewhere about 100000++ by the end of the day.

So, how do you do that or do you have any ideas?

Upvotes: 3

Views: 504

Answers (3)

JasonSmith
JasonSmith

Reputation: 73752

This is not a full answer but a possible optimization. It will work in addition to any other answers here.

Instead of storing the latest timestamp, update the timestamp only if it has changed by e.g. 5 seconds, or 60 seconds.

Assume a user refreshes every second for a day. That is 86,400 updates. But if you only update the timestamp at 5-second intervals, that is 17,280; for 60-seconds it is 1,440.

You can do this on the client side. When you want to update the timestamp, fetch the current document and check the old timestamp. If it is less than 5 seconds old, don't do anything. Otherwise, update it normally.

You can also do it on the server side. Write an _update function in CouchDB, which you can query like e.g. POST /db/_design/my_app/_update/last-access/the_doc_id?time=2011-01-31T05:05:31.872Z. The update function will do the same thing: check the old timestamp, and either do nothing, or update it, depending on the elapsed time.

Upvotes: 2

JasonSmith
JasonSmith

Reputation: 73752

CouchDB has no problem with rapid document updates. Just do it, like MySQL. High _rev is no problem.

The only thing is, you have to be responsible about your couch from day 1. All CouchDB users must do this anyway, however you may have to do it sooner. (Applications with few updates have lower risk of a full disk, so developers can postpone this work.)

  • Poll your database and run compaction if it needs it (based on size, document count, seq_id number)
  • Poll your views and run compaction too
  • Always have enough disk capacity and i/o bandwidth to support compaction. Mathematical worst-case: you need 2x the database size, and 2x the write speed; however, most applications require less. Since you are updating documents, not adding them, you will need way less.

Upvotes: 0

Evan
Evan

Reputation: 18589

If there was (a large) part of a document that is relatively static, and (a small) part that is highly dynamic, I would consider splitting it into two different documents.

Another option might be to use something more suited to the high write throughput of small pieces of data of that nature such as Redis or possibly MongoDB, and (if necessary) have a background task to occasionally write the info to CouchDB.

Upvotes: 1

Related Questions