Agree with a lot of your points, Elias. But I've found that as a solo developer pushing product in my organization, and I would venture to say there are others like mine, Riak's ops proposition trumps some of these developer issues. Not having to hire ops personnel to babysit a Riak app is a big win for organizations that barely have money to hire a dev.
If you are a developer that pushes product you can deal with round trip issues, multi fetch issues, etc. Aka. Riak's lack of developer sugar. You mentioned it earlier, but a search > MR is exactly how I've done multi fetch in Riak 1.x and, it seems, will continue to do in Riak 2.x. Of course, solutions are specific to your application. A search > user land multi fetch wrapper function is trivial to implement. Actually, I don't know why Basho doesn't ship just such a wrapper in erlang that would take an array of bucket/key pairs and push out an array of responses. But either way, it's not really a show stopper. Ya sugar is nice but, as you know, eventually you crash. -Alexander Sicular @siculars On Mar 26, 2014, at 2:10 PM, Elias Levy <[email protected]> wrote: > On Wed, Mar 26, 2014 at 10:36 AM, Eric Redmond <[email protected]> wrote: > That is correct. Storing values in solr make the values redundant. That's > because solr and Riak are different systems with different storage > strategies. Since we only return the solr results, the only way we can access > the kv values would be to make a separate call, which is not much different > from your client making that same call. > > As for separating Riak Search from kv entirely, this is a possibility we've > looked into, but it won't be ready for 2.0. I'm sorry to say that, for the > time being, the only option for your request is to store values in both > places. > > > Thanks for the response Eric. I understand the current limitations. My > question was forward looking. > > Riak is an amazing piece of technology that provides great availability. Ops > loves Riak. Alas, in my opinion, its weakness has always been one of easy of > use for developers. When it was just the KV store, the complexities of > eventual consistency were placed squarely in the developer's shoulders and > querability was very limited. > > 2i helped somewhat, and the new CRDT data types improve things tremendously, > as does Yokozuna. But there are still gaps. No bulk loading. No bulk > fetching. > > Riak has always felt like a collection of components, rather than an > integrated system. KV is unaware of Bitcask expirations. Search doesn't > returned matched documents. > > MongoDB's cluster and storage layers may be a disgrace, but the one thing > they got right is the expressive API. Its one reason why developers love > Mongo, at the same time is hated by Ops. > > I'd love to see this ease of use within Riak, so I can actually get our > developers to use it more. > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
