Enable In-Place Updates For Fixed-Length Fields

This enhancement request is prompted by a Support Ticket in which a bucket was undergoing approximately 3 compactions per minute.

The application was a control repository for millions of remote devices and the primary update was an "I'm alive" ping generated by each device once every 5 minutes. Each ping resulted in an update to a single timestamp field in that device's document in the bucket: each update resulted in an append write of 600 bytes (not including overhead) where the only data updated was the single timestamp field.

Other than having the customer increase his fragmentation threshold as high as he could without introducing adverse impacts in indexing and querying, I had no remedy for this customer's problem.

It seems to me that this kind of use case could be quite common. I am therefore suggesting that we investigate the possibility of being able to enable in-place updates for fixed-length fields - datestamps, numeric totals, booleans, code-fields, etc. - so that they could be updated without requiring the entire document to be rewritten. I believe that significant performance improvements in terms of reduced write output, reduced compaction and reduced index maintenance could be made possible if in-place updates could be enabled.

I can think of 2 ways that such updates might be implemented:

(1) provide new "in-place update" primitive commands which users would have to use in order to perform an in-place update.

(2) equip the bucket engine with logic to determine when the fields being updated were eligible for in-place updating and perform in-place updates transparently when possible.

As can be seen in this customer's application, Couchbase's append-update architecture is problematic in situations where a small update results in a large write to disk: it is worth investigating whether we can minimize this problem.