Riak Client Resources, Deleting a Key Doesn't Remove it from bucket.keys

Jonathan Langevin jlangevin at loomlearning.com
Thu May 26 13:23:45 EDT 2011


A cache seems legitimate for performance, but perhaps the cache could
additionally be maintained for inserts/deletes?
At least then the cache is still being used, but is also accurate.

I don't know how expensive that would be though, but hopefully less
expensive than a key list reload, correct?
*

<http://www.loomlearning.com/>
Jonathan Langevin
Systems Administrator
Loom Inc.
Wilmington, NC: (910) 241-0433 - jlangevin at loomlearning.com -
www.loomlearning.com - Skype: intel352
*


On Thu, May 26, 2011 at 1:18 PM, Keith Bennett <
keith.bennett at lmnsolutions.com> wrote:

>
> On May 26, 2011, at 12:40 PM, Sean Cribbs wrote:
>
> With recent commits (
> https://github.com/seancribbs/ripple/compare/35d7323fb0e179c8c971...da3ab71a19d194c65a7b ),
> it is cached until you either refresh it manually by passing :reload => true
> or a block (for streaming key lists). This was the compromise reached in
> that pull-request.
>
> All of this caching discussion glosses over the fact that you *should
> not list keys* in any real application. It really begs the question -- how
> often do you list keys in Redis, or memcached?  I suspect that generally you
> don't.  This isn't a relational database. (Also, how often do you actually
> do a full-table scan in MySQL? You don't if you're sane -- you use an index,
> or even LIMIT + OFFSET.)
>
> I'm tempted to remove Document::all and make Bucket#keys harder to access,
> but the balance between discouraging bad behavior and exposing available
> functionality is a hard one to strike. I don't want new developers to
> immediately use list-keys and then be discouraged from using Riak because
> it's slow; on the other hand, it *can be useful* in some circumstances.
>
>
>
> In those cases where it's useful, the developer should probably be
> responsible enough to request the key list only once; the caching behavior
> simply does this for them. I guess whether it *should* do this for them is
> the issue at hand.
>
>
> YES!  Exactly!  The decision to expose the functionality has been made;
> questioning whether or not this should have been done is orthogonal to
> whether or not the results should be cached, and the two should be
> considered separately.
>
> Regarding the latter, the function name represents an implied promise to
> the caller; my position is that the function's behavior is a substantial and
> surprising deviation from that implied promise.
>
> Although buckets do not *contain* key/values in the riak *implementation*,
> the bucket / key-value containment metaphor pervades the developer
> interface, evidenced by, for example, the existence of the Riak::Bucket
> class, and the structure of the URL's with which values are manipulated.  In
> software products that have containment metaphors, how often do we see a
> function return a cached value rather than the up-to-date value, especially
> for products that manage shared data?
>
> All that said, I'm really torn on this issue, and the same problem applies
> to full-bucket MapReduce. Caveat emptor.
>
>
> Ok, I'll be quiet now. ;)
>
> Thanks,
> Keith
>
>
> Sean Cribbs <sean at basho.com>
> Developer Advocate
> Basho Technologies, Inc.
> http://basho.com/
>
> On May 26, 2011, at 10:35 AM, Jonathan Langevin wrote:
>
> How long is the key list cached like that, naturally?*
>
>  <http://www.loomlearning.com/>
>  Jonathan Langevin
> Systems Administrator
> Loom Inc.
> Wilmington, NC: (910) 241-0433 - jlangevin at loomlearning.com -
> www.loomlearning.com - Skype: intel352
> *
>
>
> On Thu, May 26, 2011 at 10:35 AM, Sean Cribbs <sean at basho.com> wrote:
>
>> Keith,
>>
>> There was a pull-request issue out for this on the Github project (
>> https://github.com/seancribbs/ripple/pull/168). For various reasons, the
>> list of keys is memoized in the Riak::Bucket instance.  Passing :reload =>
>> true to the #keys method will cause it to refresh.  I like to discourage
>> list-keys, but with the memoized list you don't shoot yourself in the foot
>> as often.
>>
>> Sean Cribbs <sean at basho.com>
>> Developer Advocate
>> Basho Technologies, Inc.
>> http://basho.com/
>>
>> On May 26, 2011, at 10:29 AM, Keith Bennett wrote:
>>
>> > All -
>> >
>> > I just started working with Riak, and am using the riak-client Ruby gem.
>> >
>> > When I delete a key from a bucket, and try to fetch the value associated
>> with that key, I get a 404 error (which is reasonable).  However, it remains
>> in the bucket's list of keys (i.e. the value returned by bucket.keys().  Why
>> is the key still reported to exist in the bucket? Is bucket.keys cached, and
>> therefore unaware of the deletion? Here's a riak-client Ruby script and its
>> output in irb that illustrates this:
>> >
>> > ree-1.8.7-2010.02 :001 > require 'riak'
>> > => true
>> > ree-1.8.7-2010.02 :002 >
>> > ree-1.8.7-2010.02 :003 >   client = Riak::Client.new
>> > => #<Riak::Client http://127.0.0.1:8098>
>> > ree-1.8.7-2010.02 :004 > bucket = client['links']
>> > => #<Riak::Bucket {links}>
>> > ree-1.8.7-2010.02 :005 > key = bucket.keys.first
>> > => "4000-17.xml"
>> > ree-1.8.7-2010.02 :006 > object = bucket[key]
>> > => #<Riak::RObject {links,4000-17.xml} [text/xml]:(6430 bytes)>
>> > ree-1.8.7-2010.02 :007 > object.delete
>> > => #<Riak::RObject {links,4000-17.xml} [text/xml]:(6430 bytes)>
>> > ree-1.8.7-2010.02 :008 > bucket.keys.first
>> > => "4000-17.xml"
>> > ree-1.8.7-2010.02 :009 > object = bucket[key]
>> > Riak::HTTPFailedRequest: Expected [200, 300] from Riak but received 404.
>> not found
>> >
>> >       from
>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:55:in
>> `perform'
>> >       from
>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1054:in
>> `request'
>> >       from
>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:2142:in
>> `reading_body'
>> >       from
>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1053:in
>> `request'
>> >       from
>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1037:in
>> `request'
>> >       from
>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:543:in
>> `start'
>> >       from
>> /Users/kbennett/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/net/http.rb:1035:in
>> `request'
>> >       from
>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:47:in
>> `perform'
>> >       from
>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:46:in
>> `tap'
>> >       from
>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/net_http_backend.rb:46:in
>> `perform'
>> >       from
>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/http_backend/transport_methods.rb:59:in
>> `get'
>> >       from
>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/client/http_backend.rb:72:in
>> `fetch_object'
>> >       from
>> /Users/kbennett/.rvm/gems/ree-1.8.7-2010.02/gems/riak-client-0.9.4/lib/riak/bucket.rb:101:in
>> `[]'
>> >       from riak-delete-failure.rb:9
>> >
>> > Thanks,
>> > Keith
>> >
>> >
>> >
>> > _______________________________________________
>> > riak-users mailing list
>> > riak-users at lists.basho.com
>> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>> _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110526/2a02c702/attachment-0001.html>


More information about the riak-users mailing list