Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <9061005.1250781795149.JavaMail.jira@brutus>
Date: Thu, 20 Aug 2009 08:23:15 -0700 (PDT)
From: "Paul Joseph Davis (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Commented: (COUCHDB-465) Produce sequential, but unique,
 document id's
In-Reply-To: <1495659442.1250179574899.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745458#action_12745458 ] 

Paul Joseph Davis commented on COUCHDB-465:
-------------------------------------------

For Bob's comment on times:

The documentation for Erlang's now() function guarantees that its monotonically increasing so there's no need for me to force the suffix to be random then +1 as it'll already be ordered and the extra randomness will help prevent spurious conflicts when replicating.

Yes, clocks can go out of sync but its not critical to have them in sync, and its a non-standard option. And adding a comment in the ini file about time syncing would be just fine.

Regarding the sequential default, I don't remember anyone convincing me to make it something other than random. Though I may have just forgotten that conversation. I fear that any algorithm beyond completely random is a performance hack and I think that we should force people to consider the consequences when using one.


> Produce sequential, but unique, document id's
> ---------------------------------------------
>
>                 Key: COUCHDB-465
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-465
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: Robert Newson
>         Attachments: couch_uuids.patch, uuid_generator.patch
>
>
> Currently, if the client does not specify an id (POST'ing a single document or using _bulk_docs) a random 16 byte value is created. This kind of key is particularly brutal on b+tree updates and the append-only nature of couchdb files.
> Attached is a patch to change this to a two-part identifier. The first part is a random 12 byte value and the remainder is a counter. The random prefix is rerandomized when the counter reaches its maximum. The rollover in the patch is at 16 million but can obviously be changed. The upshot is that the b+tree is updated in a better fashion, which should lead to performance benefits.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.