Hi Daniel, Sorry for the delay here.
It looks like it's going to take a more investigation to nail down the cause. Engel just opened an issue you can keep an eye on: https://github.com/basho/riak/issues/305 Thanks for reporting. Feel free to add any relevant information to the issue. Mark On Thursday, March 14, 2013, Daniel Iwan wrote: > Maybe someone from Basho could shed some light on that issue? > > Regards > Daniel > > > On 12 March 2013 11:55, Daniel Iwan <iwan.dan...@gmail.com<javascript:_e({}, > 'cvml', 'iwan.dan...@gmail.com');> > > wrote: > >> Just to add to that. >> Further test shows that 2i searches aso suffer form the problem of not >> showing all results durring active vnode transfer. >> Is this a known issue with Riak 1.2.1? Has it been solved in 1.3? >> >> Anyone else experienced that? I guess attaching a node would trigger that >> as well, maybe in less severe way. >> Also I've read somewhere that you should attach one node at a time to >> Riak cluster, and wait until vnode transfer completes. >> I think it's no longer true in 1.2 since you have a plan that you commit, >> but attaching a node and shuffling vnodes will cause problem described >> >> What is the solution here? Waiting until vnode transfer finishes is not >> acceptable (availability) and recent findings show it may take a while on >> big clusters. >> >> Regards >> Daniel >> >> >> >> On 11 March 2013 23:06, Daniel Iwan <iwan.dan...@gmail.com<javascript:_e({}, >> 'cvml', 'iwan.dan...@gmail.com');> >> > wrote: >> >>> I'm aware that listing keys is not for production. >>> I'm using it mainly during testing, which started to be unreliable after >>> changes described above. >>> >>> What I was not expecting at all was that some of the keys won't be >>> listed. >>> I'm not sure if that is stated in documentation to tell the truth. >>> To me it looks like it should be called 'listSomeKeys' >>> >>> About alternatives. >>> Some time ago I did comparison of listing and 2i and MapReduce and >>> surprisingly listing was quickest. >>> I'm not sure why it was happening. I did similar tests today and what I >>> got is: >>> >>> 1000 keys, grouped with 2i into 10 equal groups, each value < 1kB >>> Listing: >>> - via listkeys 276ms >>> - via keyindex $key: 255ms >>> - via 2i (10 calls), total 2480ms >>> >>> So for that simple case 2i is 10 times slower. >>> Further test shows that 100k keys (100 groups, 1000 each) gives query >>> response between 250-5500ms. >>> Not good. It's almost silly NOT to use listing keys. >>> >>> I may need to do that test on different hardware to compare. At the >>> moment I'm using just one 7200rpm HDD for Riak db. >>> >>> Daniel >>> >>> >> >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
