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

Steve Warren swarren at myvest.com
Wed May 23 16:08:27 EDT 2012


I'm seeing this pretty consistently and have no explanation for it. I
delete a large number of keys (20k to 100k), but when I then search on the
keys ($key/0/g) anywhere from 0-200 or so of the deleted keys show up in
the results. It doesn't matter how long I wait after completing the
deletion step, the keys stay in the list until I try to access the object
and then it goes away. I'm using 1.1.2 and the riak-java client, and
getting no errors on the deletion step.

On Tue, May 22, 2012 at 9:34 AM, Steve Warren <swarren at myvest.com> wrote:

> Thank you for the reply. My observation does not quite match up with this
> though so I'm still a bit confused. The deleted keys appeared to stay long
> past the 3 seconds described in the post you referenced. In fact, I don't
> know if they ever "went away". I'll run some more tests to see if I can
> narrow down the exact behavior, for example not all key deletions exhibited
> this behavior (the test I ran resulted in 118 residual keys out of around
> 20K deletes). If I directly queried any of the keys it would respond with
> "not found" and immediately stop showing up in the key list or $key index
> query.
>
> I'm still running a bunch of tests just to learn the behavior of the
> system so I'll keep plugging away at it. For example, I'm observing that
> $key index queries halt inserts into the same bucket while the query is
> running, I don't know yet if this halts all server activity or just the
> inserts for that bucket though.
>
> Regards
> Steve
>
> On Tue, May 22, 2012 at 8:58 AM, Kelly McLaughlin <kelly at basho.com> wrote:
>
>> Hi Steve. There is no caching of key lists in riak. What you are seeing
>> is likely the fact that listing of keys or index queries can pick up
>> deleted keys due to the fact that riak keeps tombstone markers around for
>> deleted objects for some period. For a really good explanation of riak's
>> delete behavior check out this writeup by Jon Meredith:
>> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/006048.html.
>> You can set delete_mode to immediate as described in that post and you will
>> most likely not see any deleted keys when you do an index query or key
>> list. The tradeoff is that you may get the unexpected behavior when doing
>> concurrent updates to the same set of keys that the delete_mode changes
>> were designed to address as Jon also indicates in that post.  We are
>> considering different options on this front, but at this time no actual
>> changes have been made to address this.
>>
>> Kelly
>>
>> On May 20, 2012, at 10:13 AM, Steve Warren wrote:
>>
>> The last message I saw on this (from a year ago) says the caching of key
>> lists will be removed. I just ran into it while running a $key index range
>> search. I then ran a ?key=stream search on the bucket and the same stale
>> key list appeared (I had created a bunch of data and then deleted it as a
>> test). Did the caching removal not happen? I'm running 1.1.2
>>
>> The query:
>>
>> curl 'localhost:8098/buckets/testbucket/index/$key/0/g'
>>
>> As others have noted, this behavior is quite disconcerting and I don't
>> want to pepper the application with otherwise unnecessary checks for stale
>> keys even on 2i range queries. Or is that unavoidable?
>>
>> Regards
>> Steve
>> _______________________________________________
>> 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/20120523/b79017ce/attachment.html>


More information about the riak-users mailing list