[
https://issues.apache.org/jira/browse/COUCHDB-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776635#action_12776635
]
Paul Joseph Davis commented on COUCHDB-568:
-------------------------------------------
My current idea is to have each b~tree use a pid between btree actions and the
disk. This would allow writes to be collected and flushed simultaneously thus
saving rewrites of the upper nodes, as well as having transparent "memory-only"
edits to the tree that will be flushed some time in the future.
Then for parallel writers, we allow them to traverse the tree and 'prepare
writes' that can be merged into the current memory state and eventually
flushed. This has the benefit of releasing all of the key collation from being
bound to a single core in a fairly intuitive way.
This would also allow a mapping onto the current database delayed_commits with
a write causing the nodes in RAM to all be flushed or not as well as saving on
the upper node duplications.
Or something to that effect.
> When delayed_commits = true, keep updated btree nodes in memory until the
> commit
> --------------------------------------------------------------------------------
>
> Key: COUCHDB-568
> URL: https://issues.apache.org/jira/browse/COUCHDB-568
> Project: CouchDB
> Issue Type: Improvement
> Affects Versions: 0.10
> Reporter: Adam Kocoloski
>
> rnewson reported on IRC that the new batch=ok implementation results in
> significantly larger overhead in the .couch files. This makes sense; the old
> batch mode waited 1 second before saving, but the new implementation just
> updates the doc asynchronously. With fast hardware and moderate write rates
> it's likely that each document is being written separately.
> The overhead presumably arises from frequently updated btree inner nodes
> being written to disk many times over. I'm interested in exploring a
> modification of the delayed_commits mode whereby the updated btree nodes are
> not actually written to disk immediately, but are instead held in memory
> until the commit. I'd like to think that this will result in more compact
> files without any decrease in durability. New read requests would still be
> able to access these in-memory nodes.
> I realize the notion that updates go directly to disk is baked pretty deeply
> into couch_btree, but I still thought this was worth bringing up to a wider
> audience.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
