Hi, On 8 August 2016 at 15:39, Vikas Saurabh <[email protected]> wrote:
> Hi Ian, > > On Mon, Aug 8, 2016 at 3:41 PM, Ian Boston <[email protected]> wrote: > > > > If every successful commit writes the root node, due to every update > > updating a sync prop index, this leaves me wondering how the delayed sync > > reduces the writes to the root node ? > > > > I thought the justification of the 1s sync operation was to reduce the > > writes to the root node to n/s where n is the number of instances in the > > cluster, however based on what you are telling me the rate is (m+n)/s > where > > m is the total commits per second of the whole cluster. I understand that > > the update to test for a conflicted commit may not be the same as the > > update of _lastRevs, but in MongoDB both update the MongoDB document. > > > > I'm not sure of the exact numbers around how MongoDB would perform for > lots of edits to the same document. There's a bit of difference > between _lastRev write and commit-root conditional update - > commit-root update is a change on a sub-document... so, something like > 'set "_revision.rX"="c" on _id=0:/ iff "_conflict.rX"' doesn't exist. > While last rev updates change the same key across commits from the > same cluster node - something like 'set "_lastRevs.r0-0-X"="rY-0-X" '. > I think the idea is to avoid any conflict on MongoDB's update > statements. I'm not sure if such edits (edits to same doc but at a > different sub-doc/key) degrade performance badly. > You are correct, that a conditional update won't cost as much as a non conditional update, if no write is performed. And if no write is performed neither is replication, so cost is low, however, AFAIK, a MongoDB document is a single document stored against a single _id key. _conflict.rX and _lastRevs are all part of the same BSON object. So every write, even conditionally to a sub document, will make the root document hot, and since MongoDB shards on _id, that makes 1 MongoDB shard hot. Every Oak commit will result in an update op to the MongoDB primary holding the root document. This isnt specific to MongoMK, it probably impacts all DocumentMK implementations. OAK-4638 and OAK-4412 will need to eliminate all sync property indexes to change this behaviour. (item 3 in the start of the thread) Alternatively, move the indexes so that a sync property index update doesn't perform a conditional change to the global root document ? ( A new thread would be required to discuss this if worth talking about.) > Thanks, > Vikas > PS: I wonder if we should open a different thread as it seems to be > digressing from the subject :) > I'll try not to digress. Best Regards Ian
