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 ?
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 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) 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 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) As mentioned, I have further questions as to what CDT means in terms of transactions, ACID properties of transactions, Concistency model of individual shards etc when a non-CDS backend is involved. But, I would be able to better articulate my subsequent queries based on above clarifications -- Regards Shirley
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
