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

Jonathan Langevin jlangevin at loomlearning.com
Thu May 26 13:25:28 EDT 2011


Additionally, perhaps the automatically updating cache (regarding
inserts/deletes) could be an optionally enabled behavior?
As there are cases where it could be needlessly expensive (i.e. - high
write/delete scenarios), especially when someone does not use the key
listing feature.
*

<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:23 PM, Jonathan Langevin <
jlangevin at loomlearning.com> wrote:

> 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/71bbb017/attachment.html>


More information about the riak-users mailing list