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

controller-dev mailing list

Reply via email to