Hi,
On Mon, Feb 11, 2013 at 3:22 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
I've now spent a few days drafting some initial implementation code to
see how such a design would work in practice.
Fast forward one week ahead and we have also a MongoDB binding and
performance that's already
On Mon, Feb 18, 2013 at 1:01 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Mon, Feb 11, 2013 at 3:22 PM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
I've now spent a few days drafting some initial implementation code to
see how such a design would work in practice.
Fast forward
Hi,
I'm a bit skeptical if the added complexity is worth the disk space
saving.
As for disk space: when storing data as JSON (as I guess 99% of all users
of MongoDB do), MongoDB compresses the data as well. Currently the format
seems to be BSON, and there are plans to Snappy / LZO / LZ4. See
Hi,
On Thu, Feb 14, 2013 at 10:52 AM, Thomas Mueller muel...@adobe.com wrote:
So I guess disk space and memory usage is just different, but it's not
so easy to say whether it's better or worse.
Indeed. Ultimately we'll need higher-level performance benchmarks to
properly evaluate these things.
Hi,
On Tue, Jan 29, 2013 at 12:48 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
On Tue, Jan 29, 2013 at 12:01 PM, Marcel Reutegger mreut...@adobe.com wrote:
Template records
I'm a bit skeptical if the added complexity is worth the disk space saving.
I thought so too, but simple
Hi,
On Tue, Jan 29, 2013 at 11:10 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
So, to spark off some discussion on this, see below for my quick draft
of what such a MongoMK^2 could look like.
Thanks all for feedback!
I've now spent a few days drafting some initial implementation code to
Hi,
On Mon, Feb 11, 2013 at 3:22 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Excluding those main issues the implementation already works pretty
well. It still lacks a number of features (most notably garbage
collection) and optimizations (templates, O(log n) updates of flat
nodes,
Hi,
On Wed, Feb 6, 2013 at 2:25 PM, Michael Marth mma...@adobe.com wrote:
Excuse my ignorance, but I never came across the concept of a tree of journals
before. Is this an entirely new idea or has this been around somewhere?
It hasn't come up in exactly the same format before. The inspiration
Hi,
+
MongoMK^2 design proposal
+
Segments
The content tree and all its revisions are stored in a collection of
immutable *segments*. Each segment is identified by a UUID and typically
contains a continuous subset of the content
Hi,
On Tue, Jan 29, 2013 at 12:01 PM, Marcel Reutegger mreut...@adobe.com wrote:
both internal storage (as seen below) and garbage collection. Segments
that are no longer referenced can be efficiently identified by
traversing the graph of segment-level references without having to
parse or
or less
any underlying storage engine, as the number of MongoDB-specific parts
is minimal.
BR,
Jukka Zitting
+
MongoMK^2 design proposal
+
Segments
The content tree and all its revisions are stored in a collection of
immutable *segments
Hi,
Thanks for putting this together. I think this makes a lot of sense.
Primarily since it will reduce coupling with the underlying storage
mechanism. But also since it pro-actively tackles our main pain points
like write scalability, large and flat hierarchies, fragmentation and
Hi,
On Tue, Jan 29, 2013 at 1:21 PM, Thomas Mueller muel...@adobe.com wrote:
It's not clear to me how to support scalable concurrent writes. This is
also a problem with the current MongoMK design, but I in your design I
actually see more problems in this area (concurrent writes to nodes in the
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
Hi,
On Tue, Jan 29, 2013 at 2:07 PM, Thomas Mueller muel...@adobe.com wrote:
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?
Here's a
Hi,
On Tue, Jan 29, 2013 at 1:43 PM, Michael Dürig mdue...@apache.org wrote:
Maybe we can even pick up an earlier idea and use the node type information
(i.e. template records here) to optimise how nodes are stored.
That would clearly be useful but I'm a bit hesitant about mixing
higher level
On Jan 29, 2013, at 3:45 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Tue, Jan 29, 2013 at 1:21 PM, Thomas Mueller muel...@adobe.com wrote:
It's not clear to me how to support scalable concurrent writes. This is
also a problem with the current MongoMK design, but I in your
17 matches
Mail list logo
