infinispan based md-sal data store poc

www.opendaylight.org

Infinispan based MD-SALData Store POC


Validate the Data Store SPI by plugging an alternate implementation

Gain experience with MD-SAL Internals Measure the overhead incurred by encode/decode when

NormalizedNode is NOT the native format for the store Provide a Data Point for comparison

Goals

2


Architecture

3

ISPNTreeCache

ISPNTreeCache

Encode/DecodeEncode/Decode

TxnMgmtTxn

Mgmt

ChangeNotifications

ChangeNotifications

DataStore Impl


Mapping to Tree Cache API InstanceIdentier of Parent -> Tree Cache Node FQN InstanceIdentifier of LeafNode/LeafSetEntryNode ->Map

Key LeafNode/LeafSetEntryNode Value->Map Value

Data Store Transaction mapped to TreeCache JTA Transaction

DataChange Notifications Take a NormalizedNode Snapshot at beginning of Txn Maintain a Transaction Log Prepare ChangeEvents during Pre-Commit Asynchronously send change events after commit

Implementation Notes

4


Mapping Data Store Transactions to ISPN JTA Transactions

Read Only Transactions may not get closed Write and Delete methods in read-write transaction do

not return a future Data change events can be VERY expensive for

anything but the In Memory store Mapping to and from NormalizedNode can get

complicated TreeCache RemoveNode API does not work reliably

Learnings

5


Data Store supports multiple transactions per thread JTA supports only one active transaction per thread Transactions will need to be suspended/resumed

appropriately Suggestion

Allow only one active transaction per thread Add an explicit suspend/resume method on a transaction

Mapping Datastore Transactions

6


For In-Memory Transactions, NOT closing a Read-Only Transaction is not an issue. It would be garbage collected

For JTA Transactions supported by other persistent data stores this may cause issues

Suggestion Document that transaction close is mandatory for Read-Only

Transactions as well

Closing Read-only Transactions

7


Write and Delete methods on DOMWriteTransactions return a void giving the impression that they are synchronous

Synchronous implementation may not be always possible

Suggestion Return a ListenableFuture for Write and Delete for consistency

Write and Delete methods without Future

8


DataChange events require old and new data subtrees to be returned

Since the scope of the transactions is not known in advance, Entire data tree snap-shot has to be preserved

Tree snap-shot is trivial for in-memory store but could be VERY expensive for alternate implementations

Suggestion Validate the use cases for returning entire sub-tree Implementation must implement MVCC to support efficient

data change notifications

DataChange events

9


For the In-Memory Store, NormalizedNode is the native format

For any alternate implementation, NormalizedNodes have to be constructed from native formats like SQL, K-V Store or Document store

Suggestion: Provide utility classes to map NormalizedNodes to/from a

simple tree structure

Mapping to NormalizedNode

10


Fully functional. Not well tested Integrated with the controller. With Data Change Events performance is HORRIBLE Without Data Change Events, performs same or better

than the In Memory Data Store Potential Optimization: Leverage ISPN MVCC or

eliminate tree snap-shot at beginning and apply use Txn log to derive original

Seems to perform more consistently than the In Memory data store which slowly degrades over time

Next Steps: No plans to pursue an Infinispan implementation at the

moment. Incorporate the learnings into data store design for Helium

State of POC

11

infinispan based md-sal data store poc

Documents