[MarkLogic Dev General] xpath string construction
wayne.feick at marklogic.com
Tue Oct 14 11:02:10 PDT 2008
A disadvantage of sequential ids is that you can end up read locking all
of your documents in order to find the current max id. You can address
this partially by moving the next id into a separate document, but that
document can still become a bottleneck if you have a high insertion
rate. You could also address this by creating a range index on the id
and using cts:element-values() or cts:element-attribute-values() to find
By switching to random ids, you get better parallelism since our indexes
can quickly determine if the id is already in use and will lock at most
one document (or 0 if your existing id search is unfiltered). There is
still a vanishingly small probability that two competing threads would
allocate the same random id at the same moment in time, but that is
improbable enough to be ignored.
On Tue, 2008-10-14 at 13:07 -0400, Eric Palmitesta wrote:
> Wow, thanks for the reply, Michael. I'll probably be using some
> variation of one of your examples.
> Michael Blakeley wrote:
> > Many people ask about sequential ids. It is possible to model an id
> > sequence as a database document. But as with RDBMS sequences, there are
> > serialization penalties. I don't see the advantage of sequential ids, so
> > I rarely, if ever, use this approach.
> Assuming the recursive check isn't feasible (it doesn't scale well), the
> advantage of sequential ids is being able to sleep at night knowing
> collisions are simply impossible, and are not reliant on a 'good-enough'
> random() function. I'm nit-picking of course, I'm sure random() is
> fine. :)
> General mailing list
> General at developer.marklogic.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the General