Is this confirmed?

Thanks,
Andre

On Tue, Mar 27, 2018 at 10:14 AM Abhijit Kumbhare <abhijitk...@gmail.com>
wrote:

> Hi folks,
>
> Resurrecting an old thread that we have talked about for a while. I
> believe some folks were planning to discuss this at the DDF but for some
> reason there was no topic proposed on this. Chris, Robert and I were
> discussing having a meeting about this sometime tomorrow morning - say at
> 10 am. Chris will be able to arrange a room for us. We can ask Casey to
> have a Zoom session. It will be great if you guys can attend - at least
> Robert, Tom, Michael, Stephen, Muthu, etc.
>
> Thanks,
> Abhijit
>
>
>
>
> On Sun, Jan 1, 2017 at 11:22 PM, Muthukumaran K <
> muthukumara...@ericsson.com> wrote:
>
>> Thanks for the explanation Robert.
>>
>> When we refer access pattern and shard layout, I assume that it is in
>> context of a given transaction owned by an application - please correct me
>> if I am wrong.
>>
>> As a detour, the reference to transactions leads to a bunch of questions
>> on how MD-SAL transactions - as we know in context of IMDS, could map on to
>> external backend for a given shard (which CDT enables)
>>
>> For few transaction capabilities which are inherent in IMDS, there may
>> not be equivalent concept/support in an external backend of choice. For
>> example, concept like Transaction Chain.
>>
>> Other implementation-specific aspects of transaction could also vary
>> drastically - for example,
>> a) Snapshotting+MVCC as "I" of ACID is applicable for IMDS - but may not
>> be true in case of Etcd / Cassandra - this mismatch may not have deeper
>> ramifications to the end-user
>> b) strong-consistency for writes may be a do-it-yourself if backend
>> choice is Cassandra whereas its ingrained in IMDS
>>
>> Does this essentially mean that based on choice of backend, some concepts
>> of transactions could be just no-op/ will be thrown with an unsupported
>> exception (eg. transaction-chain) to manage the uniformity of broker
>> contracts?
>>
>> Regards
>> Muthu
>>
>>
>>
>>
>> -----Original Message-----
>> From: Robert Varga [mailto:n...@hq.sk]
>> Sent: Tuesday, December 27, 2016 9:10 PM
>> To: Muthukumaran K <muthukumara...@ericsson.com>; Colin Dixon <
>> co...@colindixon.com>; Shrenik Jain <shrenik.j...@research.iiit.ac.in>
>> Cc: integration-...@lists.opendaylight.org <d...@lists.opendaylight.org>;
>> controller-dev <controller-dev@lists.opendaylight.org>;
>> mdsal-...@lists.opendaylight.org; intern-ad...@opendaylight.org
>> Subject: Re: [controller-dev] Interested in Contribution : "Replacing the
>> MD-SAL data store with etcd"
>>
>> On 12/27/2016 11:38 AM, Muthukumaran K wrote:
>> > Hi Robert,
>> >
>> > Looking at
>> > https://github.com/opendaylight/mdsal/blob/master/dom/mdsal-dom-api/sr
>> > c/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeShardingService.
>> > java
>> >
>> > Few clarifications:
>> > For same prefix duplicate producers are not allowed - this is
>> > understandable. But there is a possibility that two distinct
>> > producers/shards can have overlapping prefixes - if this is allowed,
>> > would not there be a scenario wherein we could end up with a superset
>> > shard and subset shard
>> >
>> > Eg. Let's assume there is a subtree whose prefix is /a/b/c/d mapped to
>> shard 1 and another /a/b/c/d/e/f mapped to another shard.
>> > In other words, we can have recursive shards (hypothetical worst case
>> could be that these recursive shards could have their own backend
>> instances).
>> > Would this not lead to relatively complex read and write routing
>> implementations? Are such overlaps prevented by Sharding service contracts ?
>>
>> This is allowed and the two shards have a parent/child relationship,
>> where the parent understands that it has a subordinate shard. There can (in
>> theory) be infinite nesting, although I am not sure if the implementation
>> handles more than one level.
>>
>> As for complexity of data access... it is *relatively* complex, but all
>> it really boils down to is a recursive scatter/gather algorithm, where the
>> superior shard delegates parts of the request to its subordinates and
>> merges the responses -- which is pretty much bread-and-butter when dealing
>> with tree-based structures.
>>
>> In any case, while possible, we envision that most applications will only
>> talk to leaf shards, hence scatter/gather will not kick in. The cost of
>> determining which shard is the apex for a producer is paid when the
>> producer is instantiated, hence the steady-state cost should typically be
>> zero.
>>
>> If the application access pattern and sharding layout do not align, you
>> will get sucky performance, similar to what you get if you try to write to
>> multiple module-based shards today. But that is a deployment-time
>> engineering and application co-existence issue, which we cannot solve at
>> the infrastructure layer.
>>
>> Regards,
>> Robert
>>
>> _______________________________________________
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>
> _______________________________________________
> dev mailing list
> d...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/dev
>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to