Just want to add: driver (client) dev is listening! Adding this our clients is a fairly easy thing, and I'll ad it to our todo list.
- Roach On Wed, Mar 26, 2014 at 4:03 PM, Alexander Sicular <[email protected]> wrote: > 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 > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
