Riak is eventually consistent. Deleting it doesn't show up immediately. There is an option like delete_immediate
Shuhao On May 23, 2012 4:08 PM, "Steve Warren" <swar...@myvest.com> wrote: > 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 <swar...@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 <ke...@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@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >>> >> > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
