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
