You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Brian Candler <B....@pobox.com> on 2009/03/02 19:17:40 UTC
Re: Why sequential document ids? [was: Re: What's the
speed(performance) of couchdb?]
On Fri, Feb 27, 2009 at 10:11:12AM -0800, Chris Anderson wrote:
> I wonder if there's a way to get roughly ascending uuids (v1-ish)
> without the security issues that come from having the originating node
> permanently inscribed on each document...
If doing bulk inserts: the client can ask for a uuid, take the top N bits,
and append its own M-bit sequence number to the end?
(The docs say that clients have to be able to recover from collisions
anyway, so no harm making them slightly more likely)
Re: Why sequential document ids? [was: Re: What's the speed(performance) of couchdb?]
Posted by Jan Lehnardt <ja...@apache.org>.
On 2 Mar 2009, at 19:29, Damien Katz wrote:
>
> On Mar 2, 2009, at 1:22 PM, Jan Lehnardt wrote:
>
>>
>> On 2 Mar 2009, at 19:17, Brian Candler wrote:
>>
>>> On Fri, Feb 27, 2009 at 10:11:12AM -0800, Chris Anderson wrote:
>>>> I wonder if there's a way to get roughly ascending uuids (v1-ish)
>>>> without the security issues that come from having the originating
>>>> node
>>>> permanently inscribed on each document...
>>>
>>> If doing bulk inserts: the client can ask for a uuid, take the top
>>> N bits,
>>> and append its own M-bit sequence number to the end?
>>
>> it can also get document-count UUIDs sort them and bulk insert docs
>> in that order. :)
>
> That won't help because the insertions places in the btree are still
> evenly distributed, and besides CouchDB does that step itself.
>
> A better way would be to grab a UUID and increment it by 1 for the
> id of each new document you are saving. You still don't get great
> caching behavior as you are still inserting into a random place in
> the btree, but it's much better than N random inserts.
right, I only read the first half of your earlier remark: "And they
don't need to sort higher or lower than all the other ids, so long as
they are clustered together. "
nevermind.
Cheers
Jan
--
Re: Why sequential document ids? [was: Re: What's the speed(performance) of couchdb?]
Posted by Damien Katz <da...@apache.org>.
On Mar 2, 2009, at 1:22 PM, Jan Lehnardt wrote:
>
> On 2 Mar 2009, at 19:17, Brian Candler wrote:
>
>> On Fri, Feb 27, 2009 at 10:11:12AM -0800, Chris Anderson wrote:
>>> I wonder if there's a way to get roughly ascending uuids (v1-ish)
>>> without the security issues that come from having the originating
>>> node
>>> permanently inscribed on each document...
>>
>> If doing bulk inserts: the client can ask for a uuid, take the top
>> N bits,
>> and append its own M-bit sequence number to the end?
>
> it can also get document-count UUIDs sort them and bulk insert docs
> in that order. :)
That won't help because the insertions places in the btree are still
evenly distributed, and besides CouchDB does that step itself.
A better way would be to grab a UUID and increment it by 1 for the id
of each new document you are saving. You still don't get great caching
behavior as you are still inserting into a random place in the btree,
but it's much better than N random inserts.
-Damien
Re: Why sequential document ids? [was: Re: What's the speed(performance) of couchdb?]
Posted by Jan Lehnardt <ja...@apache.org>.
On 2 Mar 2009, at 19:17, Brian Candler wrote:
> On Fri, Feb 27, 2009 at 10:11:12AM -0800, Chris Anderson wrote:
>> I wonder if there's a way to get roughly ascending uuids (v1-ish)
>> without the security issues that come from having the originating
>> node
>> permanently inscribed on each document...
>
> If doing bulk inserts: the client can ask for a uuid, take the top N
> bits,
> and append its own M-bit sequence number to the end?
it can also get document-count UUIDs sort them and bulk insert docs
in that order. :)
Cheers
Jan
--