On Aug 3, 2010, at 8:10 PM, James Sadler wrote: <snip> > > I'm talking about creating something new > here, on top of riak_core. My questions are about the feasibility of > whether I could extend riak_core to be able to handle these > situations.
<snip> If you are truly considering doing this then it is entirely feasible. riak_core contains the components Riak uses to coordinate its distributed processing and nothing else. It's better to think of riak_core as a toolkit than a framework. There are still a number of items you have to write yourself in order to get a functioning datastore including but not limited to: * Persistence -- either reuse an existing Riak backend, like bitcask, or roll your own. This goes hand-in-hand with writing your own vnodes, too. * Sibling values -- Riak's object merging logic is specific to the key/value store so you'd need to roll your own * Hinted handoff protocol -- riak_core provides the hooks, in the form of callback functions, for handoff processing. * Client APIs -- both the HTTP and protocol buffers interfaces are part of key/value not core * Fetching/storing/querying -- For now all of this logic is tied to the operation of the key/value store. You'll need to write your own replacements. See riak_kv_get_fsm, riak_kv_put_fsm for examples of the kind of code necessary. I hope this helps clarify what's required to build a system on top of riak_core. --Kevin _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
