Re: Core Claim and Property-Based Tests

[Martin Sumner]

Jon,

BTW, I wasn't suggesting that claim v3 would choose a plan with violations
over one without - so I don't think there is a bug.

The plan below which I said scored well, but was "worse" than a purely
sequential plan, is worse only in the sense that it does not cope as well
with dual node failures (which is not something the algorithm even tries to
score for).  So in the two plans below the first plan scores better for
diversity, but there are numerous dual-node failures (e.g n1, n2) that
would lead to writes to some partitions being stored on just two physical
nodes.  There are no target_n_val violations in either cluster.

> ScoreFun([n1, n2, n3, n4, n1, n2, n3, n4, n5, n6, n7, n8, n5, n6, n7,
n8], 4).
66.0

> ScoreFun([n1, n2, n3, n4, n5, n6, n7, n8, n1, n2, n3, n4, n5, n6, n7,
n8], 4).
109.7142857142855

Perhaps the algorithm could be expanded to include other factors such as
the minimum spacing for any node, but then I assume other anomalies will
occur.  I suspect the scoring algorithm could be made ever more complex
without ever managing to please all of the people all of the time.  It is
because of this that I think claim v3 is perhaps best suited as a secondary
option rather than it being the default algorithm: and we should work on
ironing out some of the v2 issues rather than just switching to v3.

Thanks

Martin


On 19 May 2017 at 05:06, Jon Meredith  wrote:

> That's what I get for doing things from memory and not running the
> simulator :)
> I think you're right about the actual operation of the preference lists -
> but i haven't had a chance to look over the code or run some simulations.
> The effect isn't quite as severe, but as you say unevenly loads the cluster
> which is best avoided.
>
> I took a quick look at the v3 code from my phone and it looks like the
> plans are ordered by target nval violations, node ownership balance and
> finally diversity.
> It shouldn't ever pick a plan that increases violations, however if the
> starting plan has violations that aren't resolved (which is very possible
> for lots of combinations of Q and S) then it will start optimizing on the
> balance and then diversity. Maybe there's a bug somewhere.
>
> One thing I thought about but never implemented was adding some freedom to
> the algorithm to move a small number of unnecessary partitions to see if
> that would free things up and get better balance/diversity.
>
> For improving v2 you might try seeing if there's a way to
> deterministically shuffle the starting point where it starts to look for
> patitions to take - rather than always from the beginning or end.
>
> Jon
>
>
> On Thu, May 18, 2017 at 12:21 PM Martin Sumner <
> martin.sum...@adaptip.co.uk> wrote:
>
>> Jon,
>>
>> With regards to this snippet below, I think I get your point, but I don't
>> think the example is valid:
>>
>> >>>
>>
>> If with N=3 if a node goes down, all of the responsibility for that
>> node is shift to another single node in the cluster.
>>
>> n1 | n2 | n3 | n4 | n1 | n2 | n3 | n4(Q=8 S=4,TargetN4)
>>
>> Partition   All Up n4 down
>> (position)
>> 0   n2 n3 n4   n2 n3 n1
>> 1   n3 n4 n1   n3 n1 n1
>> 2   n4 n1 n2   n1 n1 n2
>> 3   n1 n2 n3   n1 n2 n3
>> 4   n2 n3 n4   n2 n3 n1
>> 5   n3 n4 n1   n3 n1 n1
>> 6   n4 n1 n2   n1 n1 n2
>> 7   n1 n2 n3   n1 n2 n3
>>
>> With all nodes up, the number of times each node appears in a preflist
>> is equal.  6 * n1, 6 * n2, 6 * n3, 6 * n4 each appears (TN*Q/S)
>>
>> But during single node failure
>> 12 * n1, 6 * n2, 6 * n3, n4 down.
>>
>> The load on n1 is doubled.
>>
>> >>>
>>
>>
>> This is not how I understood fallback election works.  My understanding
>> is that the fallback is the node which owns the first vnode after the
>> preflist, where the node is up.  Not the node which owns the first vnode
>> after the unavailable vnode.  That is to say to find fallbacks for a
>> preflist, Riak will iterate around the ring from after the primaries, not
>> iterate around the ring from after the unavailable vnode.
>>
>> So I would expect the following arrangement on n4 going down.
>>
>> ring = n1 | n2 | n3 | n4 | n1 | n2 | n3 | n4 (Q=8 S=4,TargetN4)
>>
>> Partition   All Up
>> (position)
>> 0   n2   n3   n4 (p3)
>> 1   n3   n4 (p3) n1
>> 2   n4 (p3) n1   n2
>> 3   n1   n2n3
>> 4   n2   n3n4 (p7)
>> 5   n3   n4 (p7) n1
>> 6   n4 (p7) n1   n2
>> 7   n1n2   n3
>>
>> Partition   n4 down
>> (position)
>> 0   n2  n3  n1 (fb for p3)
>> 1   n3  n1  n2 (fb for p3)
>> 2   n1  n2  n3 (fb for p3)
>> 3   n1  n2  n3
>> 4   n2  n3  n1 (fb for p7)
>> 5   n3  n1  n2 (fb for p7)
>> 6   n1  n2  n3 (fb for p7)
>> 7   n1  n2  n3
>>
>> So there isn't a biasing of load in this case, all nodes 33.3% more
>> load.  Interestingly we do go from having

Search index partitioning in Riak-KV

[Denis]

Hello

I'm trying to understand how Solr indexes are interact with Riak KV store.
Let me explain a bit... The Riak uses sharding per vnode. Each physical
node contains several vnodes and data stored there are indexed by Solr. As
far as i understood, Solr is not clustered solution, i.e. Solr instance
running on #1 node doesn't know anything about index on instance #2 and so
on.
Then when search request comes in, how Riak/Solr decides at which instance
they need to lookup for index? In other words, is this index is
document-based partition or term-based partition?
Thank you.
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Search index partitioning in Riak-KV

[Fred Dushin]

There is a Solr instance per Riak node, and each Solr instance contains a Solr 
core for the Riak index created.  Every replica of a Riak k/v pair has a 
corresponding document in the Solr instance on the same node as the vnode that 
stores the replica (in fact for each sibling, if your objects admit siblings).  
Each document in Solr contains not only the bucket and key as indexed fields, 
but also the Riak partition (well, the partition ordinal, actually).  All of 
these fields are indexed, IIRC.

When a query executed through Riak, a coverage plan is used to generate a 
filter query (based on the node and partition in the cover set) that is used 
with shard parameters on the local Solr instance in which the query was 
executed.  So technically every query is using (legacy) Solr distributed query; 
it's just that all the shard parameters and Solr deployment topology is hidden 
from the user and done internally by Riak.  It's really quite elegant and 
clever (IMO), but it can run into scaling issues, as Solr/Lucene is quite a bit 
more demanding than Riak, in some real-world use-cases.

I made an attempt to explain how a lot of how this works at 
https://www.youtube.com/watch?v=e1yVJqRuLSg 


There are far better presentations on the topic by Ryan Zezeski and other 
pioneers who did the initial implementation.

-Fred

> On May 19, 2017, at 7:10 AM, Denis  wrote:
> 
> Hello
> 
> I'm trying to understand how Solr indexes are interact with Riak KV store. 
> Let me explain a bit... The Riak uses sharding per vnode. Each physical node 
> contains several vnodes and data stored there are indexed by Solr. As far as 
> i understood, Solr is not clustered solution, i.e. Solr instance running on 
> #1 node doesn't know anything about index on instance #2 and so on. 
> Then when search request comes in, how Riak/Solr decides at which instance 
> they need to lookup for index? In other words, is this index is 
> document-based partition or term-based partition?
> Thank you.
> ___
> 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