Question

I want to generate IDs for use with CouchDB. I’d like the IDs to be lexographically ascending by time so that I can sort on id without maintaining a seperate timestamp field. I know that CouchDB will generate ids with this property, but I don’t want the performance hit of querying the database, I’d rather just run an algorithm on my servers. I’d go with an implementation of rfc 4112 except that the results aren’t lexographically ascending. Is there any good reason I shouldn’t just do:

(Date.now()) + 'x' + Math.round(Math.random() *1E18)

(I’m using nodejs). Are there any costs of using a non-standard uuid, or of relying on javascript’s built in random function?

Answer 1

You have some choices when it comes to uuids.

The first choice is if you want the _id generated client side(node, browser, etc..), or by couch. It sounds like you want to generate your own uuid on the client side. That is fine. Just stick the result of your function into the _id field of the doc you save to couchdb. Couch will just use that.

You could have couch create the id. Couchdb only generates a _id if you don’t choose one for yourself. Couchdb by default uses a ‘sequential’ uuid generation algorithm. You can change the algorithm to others via futon and config. There is a section called ‘uuids’ with a key of ‘algorithm’. You can see the source for these algorithms here:

https://github.com/apache/couchdb/blob/master/src/couchdb/couch_uuids.erl

With descriptions about them here:

http://wiki.apache.org/couchdb/HttpGetUuids?highlight=%28utc%5C_random%29

As you can see the utc_random function is very similiar to your suggestion. But if you wanted your own,If you were inclined you could add you algorithm on the serverside and recompile couch.

The second part of your question is about the performance of choosing different algorithms. I am going to quote Dave Cottlehuber from a user list post:

CouchDB will have best insert time when your doc ids are
continually increasing, as this minimises rewrites to the b~tree. This
will also help
your view build time for the same reason, and also minimises wasted doc space,
although that would also be recovered during compaction.

So both your algorithm and the utc_random should be fine as they doc ids are continually increasing do to the seemingly helpful one direction of time.