The doc ids can be generated client side, so clients can use any
scheme you want. For how the server generates UUIDs, there has been
some talk about doing some work there, but I don't think anyone has
started it.
-Damien
On Feb 27, 2009, at 7:44 AM, Wout Mertens wrote:
On Feb 26, 2009, at 8:18 PM, Damien Katz wrote:
Also, he Ids don't need to be sequential (1,2,3,4...), just ordered
(1,5,19,22...). And they don't need to sort higher or lower than
all the other ids, so long as they are clustered together. The
each btree nodes that have to be loaded that isn't in cache is
expensive. The more the keys have to be inserted into random places
in the btree, the worse the caching behavior. Right now, with the
crypto random UUIDs we generate, it's basically the worst case
scenario for doc inserts.
So why not decrease security by a tunable factor and add a random
number to the previous UUID instead?
And while we're on the subject, I've wished for automatic doc UUIDs
that nonetheless have a fixed prefix. More human readable plus it
doubles as a type field... Any chance of that or is that one of the
beginner mistakes?
Wout.
