Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <1765124407.1250750114846.JavaMail.jira@brutus>
Date: Wed, 19 Aug 2009 23:35:14 -0700 (PDT)
From: "Paul Joseph Davis (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Updated: (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:all-tabpanel ]

Paul Joseph Davis updated COUCHDB-465:
--------------------------------------

    Attachment: couch_uuids.patch

Refactored a bit.
couch_uuid_generator -> couch_uuids
sequential -> hybrid (this was mostly playing, thoughts?)
random is back to default and should stay that way
call to random:uniform() -> crypto:rand_uniform() (someone forgot to call random:seed(), tsk tsk :)
[uuid_generator] -> [uuids] in config
added short description of choices next to option
probably an unneccessary optimization to allow for couch_uuids:new(N) to return N ids.
added simple checks to the uuids.js Futon tests
Pulled in a contribution by Bob Dionne for etap tests.
All calls to couch_util:new_uuid() are replaced with couch_uuuids:random()

We should make the prefix length a configuration parameter I think.

We might also think about adding Brian's algorithm for more diversity as well.

> 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.