jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: MongoMK^2 design proposal
Date Tue, 29 Jan 2013 12:07:57 GMT
Hi,

To better understand the design it would help me if you could list the
MongoDb collections, and the key / properties / values. I guess the
segment ids are MongoDB object ids? Or is it (part of) the path?

> Segments are immutable, so a commit would create a new segment

So there are no MongoDB updates, as in the current design? A potential
problem (depending on the segment id) is that all writes go to the same
MongoDb shard, or to a random one. I would actually prefer if the primary
key represents (part of) the path, so that MongoDb sharding works well
(locality of access).


>A quick estimate of the size overhead of a minimal
>commit that updates just a single property is in the order of hundreds
>of bytes, depending a bit on the content structure.

I thought the segment size is a few KB. So would you buffer writes to get
the "hundreds of bytes"? In my view, commits should be written immediately
so that other cluster nodes can read them. Or does "hundreds of bytes"
take into account that you can split segments?

>Note that the proposed design actually does rely on lots of MongoDB
>features beyond basic CRUD. Things like sharding, distributed access,
>atomic updates, etc. are essential for the design to scale up well.

Well, it depends on what you consider the main features of MongoDB :-)
About atomic updates: I thought segments are immutable? With atomic
updates I mean 
http://docs.mongodb.org/manual/applications/update/#update-operators

Regards,
Thomas


Mime
View raw message