[+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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
