[+mdsal-dev]

On 10/14/2016 03:13 AM, Shirley Anend wrote:
> I was going through the slides and presentation in ODL summit on the
> Conceptual Data Tree. A semblance I can think of is how DNS server
> partitioning and forwarding can be realized. If I have to draw parallels
> wrt Conceptual Data Tree, there is a possibility of root, children and
> grandchildren shards as a composite structure. Writes and reads are
> recursively delegated to shards / sub-shards as per shard-layout. Is my
> understanding better at this high-level ?

Correct. We also provide APIs which allow an application to initiate
transactions at a particular subtree rather than always starting at the
root, so when the application's access pattern is aligned with the
sharding layout we can limit/eliminate recursion.

> 
> Now. specific assumptions (before going into transactions, ACID,
> concistency etc.). So, please correct if following assumptions are right
> 
> 1. With Conceptual Data Tree, a shard-implemention "claims" read/write
> responsibility for a given subtree and become composite part of
> shard-layout. This offers a more fine-grained sharding layout when
> compared to current module-sharding layout of CDS

Yes.

> 2. Above point also - hypothetically, implies that we can have a
> shard-implementation (with suitable SPI abstractions of MD-SAL) which
> can use an external datastore oher than CDS (eg. a clustered IMDG like
> Apache Ignite or other suitable nosql solutions can be used as backend -
> in theory)

Yes.

> 3. An external backend for shard may not provide all contractual
> cpabilities as ODL CDS or IMDS. For example, change notifications. I
> surmise it would be a great impedance mismatch to seal if capabilities
> like listeners are provided agnostic to backend capabilities. Please
> correct me if I am wrong

Yes, but since the request to attach a listener is forwarded to the
implementation it can refuse it -- leading to a fail-fast scenario if
such impedance occurs.

Even if the backing store does not have a mechanism similar to DTCN, I
suspect in many scenarios it can be successfully emulated.

> 4. Shard-partitioning - as proposed by Conceptual Data Tree, is
> schema-based or instance-based ? for example, can a list can be
> range-partitioned by key and expressed that way in shard-layout
> configuration without any changes in model ? 
> I understand that there is a possibility that list - as container, can
> be owned by a shard and its backend may choose to partition it agnostic
> to the shard-layout of CDT - this is what I refer as schema-based
> partitioning. There is another possibility of expressing sharding meta
> in model - but that pollutes domain model - so not a nice option. A
> rough example of instance-based partitioning - create a dedicated shard
> for each openflow-switch (unless such a design approach is audacious
> from resource consumption perspective)

It is both :) A shard can be attached to any entity which is addressable
via YangInstanceIdentifier -- which means it can either claim a complete
list or just a single item in a list.

Range-partitioning is not supported at the CDT level because we
currently do not have a way to express key mapping functions. Ideas
around this are more than welcome.

That does not preclude such partitioning being implemented within a
shard (which would claim the entire list at which point it becomes an
implementation-internal matter).

Regards,
Robert

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to