Atomics are relatively easy to implement as long as we know to which storage server the mutation has to go.
How about cases #2 and #10?
Do you have specific use-cases for the list above?
There are few use cases
Key update rate metric.
We update some key atomically and want to measure how often it is updated. The idea is to dedicate one field within the value for a version stamp and another field for total number of updates and use suggested feature #1 (version stamped field within value subtracted from current version stamp). This wouldn’t work alone and might need some further features to get average rate (or rate within last 5 minutes).
Colocation of multiple Invertible Bloom Lookup Table cells in single FDB value
IBLT requires multiple independent add operations of multiple integer fields. The structure supports blind updates. However the problem is integer overflow. The IBLT needs an operation which would wrap around without corrupting adjacent cells (see proposed features #9 and #6).
Automatic page
We are working on inverted index. This would require us to store references to FDB keys in FDB values. If our references are the same size we could store them under single value atomically if we would be able to append at the end (see proposed feature #7). However FDB has limits on the value size. We want to automatically create a next page when we reach that limit (see feature proposal #10).
The data model for this use case is something like
key/0 = ref1,ref2,ref3.ref4,…
key/1 = ref10,ref20,…
We want to automatically create next key when we reach the maximum allowed size value.
Efficient changes feed
FDB doesn’t support watchers for the range (see some related discussions Changefeeds (watching and getting updates on ranges of keys) and Changes feed without hot keys)
At CouchDB we are trying to introduce sharding to replace our first implementation of the feature. There is an opened RFCs for CouchDB project here
We are looking for a way to create and remove shards automatically based on either rate of updates or number of documents. We probably want to double number of shards as needed. The doubling can be achieved using proposed feature #12.
Bloom filter in FDB value
Bloom filter can be updated blindly using XOR operation. However sometimes it is useful to protect a filter from updates if it is overpopulated. We can implement such protection If we would prevent XOR if population count is exceeding certain threshold (see #11).
implementing lifo queue with ability to update head
If the size of items we intend to store in queue is fixed and small we can implement the queue as multiple keys where multiple items are stored in the same key. When we reach the FDB limit on value size we create next key. In order to implement such a scheme using atomic operations we need to be able to extend last key in the range (see #2) also we need to be able to append to the end and create new key when we reach FDB value limit (see #10). In order to update head
we need to read last field from the value of a last key in a range (see #2 and #4).
This use case probably would require a take operation as well which would remove last field from the value. However IRC it cannot be atomic since it returns a part of a value.