incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Why sequential document ids? [was: Re: What's the speed(performance) of couchdb?]
Date Fri, 27 Feb 2009 16:23:36 GMT
On Fri, Feb 27, 2009 at 9:00 AM, Damien Katz <damien@apache.org> wrote:
> 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.
>
>

There was talk of switching the internal uuid generationg to a version
1 style instead of the version 4 (random) style. My suggestion was to
make the _uuids endpoint accept a v=[1|4] url parameter to choose with
a config file default but people seemed to not like that idea.

HTH,
Paul Davis

Mime
View raw message