search

basho / riak_core

Distributed systems infrastructure used by Riak.
Apache License 2.0
1.22k stars 393 forks source link

Add generic PUT/WRITE and GET/READ Coordinator FSMs [JIRA: RIAK-1633] #722

Open DeadZen opened 9 years ago

DeadZen commented 9 years ago

I believe it's time we put the generalities of the distributed semantics one expects to find in riak_core in with the actual riak_core modules, since riak v2 has essentially decided on the correct "vclock situation" by adding "dots" and has it's own "crdt" library, a correct no-frills implementation of satisfying quorum with conflict resolution can be added to reinforce concepts and reduce buggy ad-hoc implementations.
label:core2015

russelldb commented 9 years ago

Kind of disagree.

Riak_kv uses something like dvvsets, which are part of riak_core, and preferable to the way riak_kv does things. Riak_kv's dotted version vectors are the way they are for backwards compatibility, why force that on new core apps?

Riak_kv uses riak_dt, which is a standalone library of functional data types. It is integrated with a few other riak_core/db apps from the SyncFree research project, and ProjectFifo that I know of.

I do think vnode id management should be in core. It's a thorny issue, hard to get right.

DeadZen commented 9 years ago

Ok, it seemed like that was the most backward compatible way yes. And indeed that aspect should be decoupled in logic, I dont presume to know what is the exact way it should be, more then to indicate if its assumed coordinators are un-generalizable that it may lead to buggy ad-hoc implementations in other riak core based apps. I did review many of these apps, and I spoke with @ricardobcl after reviewing the dvvset implementation comparing riak_kv v2 to the dvvset branch marking the difference between them as well as noting that riak_core_meta_object was more similar in implementation then riak_kv wrt riak_object. Really just researching the benefits of and latest approaches. With respect, I may have made a bad assumption. I would like to identify that aspect in code or what is preferable in coordinating with vnodes and possibly trade offs / defaults in the context of riak cores design.

On Thursday, March 19, 2015, Russell Brown notifications@github.com wrote:

Kind of disagree.

Riak_kv uses something like dvvsets, which are part of riak_core, and preferable to the way riak_kv does things. Riak_kv's dotted version vectors are the way they are for backwards compatibility, why force that on new core apps?

Riak_kv uses riak_dt, which is a standalone library of functional data types. It is integrated with a few other riak_core/db apps from the SyncFree research project, and ProjectFifo that I know of.

I do think vnode id management should be in core. It's a thorny issue, hard to get right.

— Reply to this email directly or view it on GitHub https://github.com/basho/riak_core/issues/722#issuecomment-83761730.

jonmeredith commented 9 years ago

It is interesting how to separate the concerns of

a) Representing where data is normally and in the presence of failures (combination of ownership in the ring, nval in bucket properties, the node watcher to generate the active preference list as seen by a node). b) How messages are exchanged between FSM type things and Vnode type things - unicast, request/response, request/stream etc c) The actual logic of what needs to happen.

Having (c) separate is very interesting for test case generation so you know your stuff works in common failures (fallbacks, partitions etc).

DeadZen commented 9 years ago

Quite right, c is what id like to start with, i have some unique ideas for a and b too but i think heres the best place to start, and forge some partnership from the community at the same time, as I'm sure everyone who has tried to work with riak_core would appreciate a more well lit view of the architecture and capabilities.

On Thursday, March 19, 2015, Jon Meredith notifications@github.com wrote:

It is interesting how to separate the concerns of

a) Representing where data is normally and in the presence of failures (combination of ownership in the ring, nval in bucket properties, the node watcher to generate the active preference list as seen by a node). b) How messages are exchanged between FSM type things and Vnode type things - unicast, request/response, request/stream etc c) The actual logic of what needs to happen.

Having (c) separate is very interesting for test case generation so you know your stuff works in common failures (fallbacks, partitions etc).

— Reply to this email directly or view it on GitHub https://github.com/basho/riak_core/issues/722#issuecomment-83833280.

russelldb commented 9 years ago

Agree wrt to C also, since we recently had discussion in irc about riak_core and chain-replication: not everyone wants a Get/Put fsm that works with quora etc.

Basho-JIRA commented 9 years ago

Sean, please verify that this can be closed.

_[posted via JIRA by Derek Somogyi]_

mbbroberg commented 8 years ago

Hey @DeadZen, are you good with where this landed?

DeadZen commented 8 years ago

Not yet, we've only identified a very basic outline of the problem, and what we shouldn't do- a good start. The exact avenue to proceed with still needs a bit more definition for us to forge ahead with some confidence. Russell has helped me fill some gaps in the forming of a correct solution, now we need to attempt a generic abstraction. I think to make our efforts truly productive we should also see some tooling for analyzing performance and compatibility. This could likely be linked to another ticket focusing on performance improvements that would include gen. coordinators.

On Tue, Aug 4, 2015 at 4:03 PM, Matt Brender notifications@github.com wrote:

Hey @DeadZen https://github.com/DeadZen, are you good with where this landed?

— Reply to this email directly or view it on GitHub https://github.com/basho/riak_core/issues/722#issuecomment-127740647.