couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Binns <>
Subject Re: svn commit: r897509 - /couchdb/trunk/etc/couchdb/
Date Mon, 11 Jan 2010 00:24:32 GMT
Hash: SHA1

Chris Anderson wrote:
> I'm not feeling super-strong about this. However, making the default
> sequential seems like it will preempt a lot of the problems people
> tend to show up asking about. 

There are several issues conflated together:

- - When doing inserts, sorted ids are faster

- - The resulting size of the db file is the size of the docs plus a multiple
of the _id size (and probably an exponential of the size)

- - Sequential ids give small _id

- - Random ids give large _id

- - Sequentials will clash between different dbs (consider replication,
multiple instances etc).  They'll also lead people to rely on this
functionality as though it was like a SQL primary key

- - Random ids won't clash and better illustrate how CouchDB really works

> I think the info-leakage argument is overblown 

It does make URLs easy to guess like many ecommerce sites that didn't
validate when showing you an invoice - you added one to the numeric id in
the URL and got to see someone elses.

I would far prefer the size of the db file and the size of the _id link
being addressed.  Because the _id size can cause the db file to get so big,
I/O etc is a lot slower mainly because there is just so much more file to
deal with!  (In my original posting I had a db go from 21GB to 4GB by
reducings ids from 16 bytes to 4 bytes.)


Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


View raw message