I have the same question. According to the comments in riak_claim.erl, the
claims will be arranged so that partition sequences of length at most
target_n_val will have no repeated nodes, if possible, but that there will
be cases where there may be repeats. Is the sequence of N partitions taken
ve
Regarding #2, I think bitcask could be modified to support an efficient list
keys by bucket fairly easily, without sacrificing free buckets:
The current bitcask stores record locators (key, file_id, file_offset) in
memory in a big hash table by key (the bitcask key, in Riak's case, is the
Riak {bu
Riak is not aware of the data types. It just presents a list of values to
the client for conflict resolution.
Curtis
On Tue, Aug 3, 2010 at 7:15 AM, James Sadler wrote:
> Hi Dmitry,
>
> Being able to represent any Erlang term is a good start.
>
> Which leads me to Riak's conflict resolution.
