It's only really that a significant portion of our application is in the RDBMS so we can't invest the time to re-write and migrate at this time. New features and services that makes sense are being moved off on a case by case basis.
Thanks for the info about the status of Riak Search. Eric On Mon, May 21, 2012 at 11:02 AM, Ryan Zezeski <rzeze...@basho.com> wrote: > > > On Wed, May 16, 2012 at 2:01 PM, Eric Boyer <eric.bo...@firmex.com> wrote: >> >> >> I can understand wanting to make Search more focused on indexing KV >> data instead of a 'backdoor'. I was a little confused at first about >> where the search data was being stored. > > > The confusion is one of the reason I want to see non-KV indexing go away. > >> >> >> We currently don't store the actual data in Riak because after the >> Riak Search we still have to check permissions and retrieve the data >> from our Relational DB. We've put searching into Riak to better >> distribute the load, and have a quicker update to the search indexes >> instead of having to commit/optimize with Solr. It was very convenient >> to just point to the Riak search/update endpoint and speak the same >> protocol even if the semantics are slightly different. > > > I'm glad Search is meeting your needs. I'm curious what parts of RDBMS do > you need that prevented you from using Riak to store the data itself? > > There has been some internal discussion about not deprecating/killing the > solr emulation but instead moving it off into it's own layer/application > that sits atop Riak. I thought you should know. > > -Z _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
