After poking around, I've found a presentation by John Muellerleile at Boundary's meetup on October 6, 2011. He addresses Riak, Solr and other technologies in use at showyou.com.
http://blog.boundary.com/2011/10/11/Boundary-Tech-Talk-1.html http://thinkdifferent.ly/stuff/scaling-at-showyou-jmm.pdf http://twitter.com/jrecursive Around 11:10 in the video, he addresses the Pre/Post Commit Hook question. He uses a Post Commit Hook for the reason Ryan outlined above... he doesn't want a write to be blocked. :) Hope this helps others. Thanks, Simeon On Wed, Dec 28, 2011 at 11:13 AM, Simeon F. Willbanks <[email protected]> wrote: > Ryan, > > I really appreciate the detailed answer and breakdown of Pre/Post > Commit Hook options. > > Thanks, > Simeon > > On Wed, Dec 28, 2011 at 10:42 AM, Ryan Zezeski <[email protected]> wrote: >> Simeon, >> >> I think the assumption is that if it's a precommit hook you "know" that if >> an object was written then it has also been indexed. Whereas if it's a >> postcommit the object may be written but the indexing fails. I think the >> guiding decision would probably be what you favor, 1) that for any object >> it's index will exist first, therefore your query results are "consistent" >> with your data or 2) that data persistence is the foremost priority and >> inconsistent or eventually consistent query results are acceptable (because >> maybe objects are constantly updated and eventually they will get indexed). >> The thing to keep in mind is that the precommit will block the write, and >> if you're using a persistent backend like bitcask or level you may not want >> your data sitting in memory waiting for the indexing to finish. Another >> thing to think about is using a postcommit that fires off into a queue that >> is indexed thus reducing latency on your clients writes to Riak. My point >> is that there are many factors and if you are going to go down the Riak/Solr >> route you should take your applications requirements into consideration. >> >> HTH, >> -Ryan >> >> >> On Wed, Dec 28, 2011 at 12:56 PM, Simeon F. Willbanks >> <[email protected]> wrote: >>> >>> Ryan, >>> >>> Thanks for the timely answer. >>> >>> Yea, faceting in code doesn't sound like the right solution. :) >>> >>> In the talk 'Riak Search Explained,' Daniel Reverri described how Riak >>> Search integrates with Riak KV via a Pre-Commit Hook. If you were to >>> roll your own search (Solr Cluster), is the recommendation to initiate >>> a indexing process from a Pre-Commit Hook as opposed to a Post-Commit >>> Hook? >>> >>> Thanks again, >>> Simeon >>> >>> >>> On Wed, Dec 28, 2011 at 8:04 AM, Ryan Zezeski <[email protected]> wrote: >>> > Simeon, >>> > >>> > There are currently no plans to implement faceted queries. The first >>> > thought is that you pull back all results and do the faceting yourself, >>> > but >>> > what's the point of that, right? I think other than that some Erlang >>> > would >>> > need to be written for Search to properly support faceting. >>> > >>> > -Ryan >>> > >>> > On Tue, Dec 27, 2011 at 4:54 PM, Simeon F. Willbanks >>> > <[email protected]> wrote: >>> >> >>> >> Are there plans to implement Faceted Queries? >>> >> >>> >> "Facet querying through the Solr interface is not yet supported." >>> >> >>> >> >>> >> http://wiki.basho.com/Riak-Search---Querying.html#Faceted-Queries-via-the-Solr-Interface >>> >> >>> >> In the meantime, is there a recommended alternative way to build >>> >> facets with Riak-Search? >>> >> >>> >> Thanks, >>> >> Simeon >>> >> >>> >> _______________________________________________ >>> >> 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
