Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 74.125.46.28 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=A3dqM8HtZUzgk7QWlDsWULMI4CwOK8Hl0lcv1tsQSYeMkRzfbJgotUXgS5hPHlTKMx
         iFUwF0GF3VnChqpXP/yXanEwLxvJY6eZcGs2tEve3h1gNNu0mWCKWiui9Ph2XOzQ1y91
         1GC7ndOOL6MDi/IsZ69HLsFCY7ynrmG+zJ0/A=
MIME-Version: 1.0
In-Reply-To: <94A51F43-404D-4728-B5B6-8B502EC07E24@apache.org>
References: <cd7634ce0902261049v904ffdds8608623cd79fe089@mail.gmail.com>
	 <60D10DCD-C1F7-4663-B6DF-60DD4641672C@apache.org>
	 <4703936A-A1E8-46C0-B2F4-0DA9FD5D5B9A@apache.org>
	 <8A824EA9-82FA-482C-BF87-691D522C4FC3@cisco.com>
	 <94A51F43-404D-4728-B5B6-8B502EC07E24@apache.org>
Date: Fri, 27 Feb 2009 11:23:36 -0500
Message-ID: <e2111bbb0902270823g6269e497ycd47e52fc3d36790@mail.gmail.com>
Subject: Re: Why sequential document ids? [was: Re: What's the
	speed(performance) of couchdb?]
From: Paul Davis <paul.joseph.davis@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 y=
ou
> 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 th=
e
>>> other ids, so long as they are clustered together. =A0The each btree no=
des
>>> that have to be loaded that isn't in cache is expensive. The more the k=
eys
>>> have to be inserted into random places in the btree, the worse the cach=
ing
>>> 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=3D[1|4] url parameter to choose with
a config file default but people seemed to not like that idea.

HTH,
Paul Davis