Because otherwise I have no ways to walk all the keys in some of my largest
buckets, paginated query not supported, RpbListKeysReq fails with Riak
'timeout' error. All hopes for Yokozuna then!
On 11 March 2016 at 18:49, Oleksiy Krivoshey wrote:
> Hi Magnus,
>
> Yes, thank you. Though I'm stuck a
Hi Magnus,
Yes, thank you. Though I'm stuck a bit. When I experienced recursive
behaviour with paginated $bucket query I tried to create Yokozuna Solr
index with an empty schema (just _yz_* fields). Unfortunately querying
Yokozuna gives me inconsistent number of results as described in my another
Hi Oleksiy,
As Russel pointed out, 2i queries, including $bucket queries, are only
supported when the backend supports ordered keys. This is currently not the
case with bitcask.
It appears, though, that you have discovered a bug where the multi-backend
module accepts the query despite the fact th
The problem is not a problem then :)
Thanks!
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
But still requires ordered keys to do pagination. the $bucket index is only
available if you’re using 2i, which requires leveldb.
On 11 Mar 2016, at 16:32, Oleksiy Krivoshey wrote:
> I know that 2i requires leveldb, but I'm not using my custom index, I'm using
> $bucket, I thought $bucket inde
I know that 2i requires leveldb, but I'm not using my custom index, I'm
using $bucket, I thought $bucket index is some kind of special internal
index?
On 11 March 2016 at 18:28, Russell Brown wrote:
> You can’t…can you? I mean, 2i requires level. It requires ordered keys.
> Which explains your p
You can’t…can you? I mean, 2i requires level. It requires ordered keys. Which
explains your problem, but you should have failed a lot earlier.
On 11 Mar 2016, at 16:26, Oleksiy Krivoshey wrote:
> Hi Magnus,
>
> The bucket type has the following properties:
>
> '{"props":{"backend":"fs_chunks"
Hi Magnus,
The bucket type has the following properties:
'{"props":{"backend":"fs_chunks","allow_mult":"false","r":1,"notfound_ok":"false","basic_quorum":"false"}}'
fs_chunks backend is configured as part of riak_kv_multi_backend:
{<<"fs_chunks">>, riak_kv_bitcask_backend, [
{da
Hi Fred,
This is production environment but I can delete the index. However this
index covers ~3500 buckets and there are probably 10,000,000 keys.
The index was created after the buckets. The schema for the index is just
the basic required fields (_yz_*) and nothing else.
Yes, I'm willing to re
Hi Oleksiy,
This is definitely pointing to an issue either in the coverage plan (which
determines the distributed query you are seeing) or in the data you have in
Solr. I am wondering if it is possible that you have some data in Solr that is
causing the rebuild of the YZ AAE tree to incorrectl
Hi Oleksiy,
Could you please share the bucket or bucket-type properties for that small
bucket? If you open an issue on github, please add the properties there,
too.
Many Thanks,
On 11 March 2016 at 13:46, Oleksiy Krivoshey wrote:
> I got the recursive behavior with other, larger buckets but I
I’ve never seen this before. I’m pretty sure our tests would catch it if it
were a general issue.
Would you mind opening an issue on github for riak? If possible any information
you can give that can help us repro would be great.
Thanks
Russell
On 11 Mar 2016, at 13:46, Oleksiy Krivoshey wr
I got the recursive behavior with other, larger buckets but I had no
logging so when I enabled debugging this was the first bucket to replicate
the problem. I have a lot of buckets of the same type, some have many
thousands keys some are small. My task is to iterate the keys (once only)
of all buck
Not the answer, by why pagination for 200 keys? Why the cost of doing the query
20 times vs once?
On 11 Mar 2016, at 13:28, Oleksiy Krivoshey wrote:
> Unfortunately there are just 200 keys in that bucket. So with larger
> max_results I just get all the keys without continuation. I'll try to
>
Unfortunately there are just 200 keys in that bucket. So with larger
max_results I just get all the keys without continuation. I'll try to
replicate this with a bigger bucket.
On Fri, Mar 11, 2016 at 15:21 Russell Brown wrote:
> That seems very wrong. Can you do me a favour and try with a larger
That seems very wrong. Can you do me a favour and try with a larger
max_results. I remember a bug with small results set, I thought it was fixed,
I’m looking into the past issues, but can you try “max_results=1000” or
something, and let me know what you see?
On 11 Mar 2016, at 13:03, Oleksiy Kr
Here it is without the `value` part of request:
curl '
http://127.0.0.1:8098/types/fs_chunks/buckets/0r0e5wahrhsgpolk9stbnrqmp77fjjye.chunks/index/$bucket/_?max_results=10&continuation=g20ja1AzdzJwOXpYcVoyb0F4NDhTMVNnRUpBbGJ0ZkhVdkk6MjU=
'
{"keys":["4rpG2PwRTs3YqasGGYrhACBvZqTg7mQW:0","4rpG2P
I'm actually using PB interface, but I can replicate the problem with HTTP
as in my previous email. Request with '&continuation=' returns the
result set with the same continuation .
On 11 March 2016 at 14:55, Magnus Kessler wrote:
> Hi Oleksiy,
>
> How are you performing your 2i-based ke
Hi Oleksiy,
How are you performing your 2i-based key listing? Querying with pagination
as shown in the documentation[0] should work.
As an example here is the HTTP invocation:
curl "
https://localhost:8098/types/default/buckets/test/index/\$bucket/_?max_results=10&continuation=g20CNTM=
"
On
Here is an example of the HTTP 2i query returning the same continuation as
provided in query params:
curl '
http://127.0.0.1:8098/types/fs_chunks/buckets/0r0e5wahrhsgpolk9stbnrqmp77fjjye.chunks/index/$bucket/0r0e5wahrhsgpolk9stbnrqmp77fjjye.chunks?max_results=10&continuation=g20ja1AzdzJwOXpYc
Here are two consequent requests, one returns 30118 keys, another 37134
0
6
_yz_pn:92 OR _yz_pn:83 OR _yz_pn:71 OR
_yz_pn:59 OR _yz_pn:50 OR _yz_pn:38 OR _yz_pn:17 OR _yz_pn:5
_yz_pn:122 OR _yz_pn:110 OR _yz_pn:98 OR
_yz_pn:86 OR _yz_pn:74 OR _yz_pn:62 OR _yz_pn:26 OR
So event when I fixed 3 documents which caused AAE errors,
restarted AAE with riak_core_util:rpc_every_member_ann(yz_entropy_mgr,
expire_trees, [], 5000).
waited 5 days (now I see all AAE trees rebuilt in last 5 days and no AAE or
Solr errors), I still get inconsistent num_found.
For a bucket with
Anyone?
On 4 March 2016 at 19:11, Oleksiy Krivoshey wrote:
> I have a bucket with ~200 keys in it and I wanted to iterate them with the
> help of $bucket index and 2i request, however I'm facing the recursive
> behaviour, for example I send the following 2i request:
>
> {
> bucket: 'BUCKET_NAME'
23 matches
Mail list logo
