Jump to: navigation, search

OpenDaylight Controller:MD-SAL:Architecture:Clustered Data Store:Persistence Options

Pre-requisites:

  1. Only Java based DBs
  2. should have proper OSS licensing

Embeddable Persistence DB Choices

Pros:

  • Easy to manage in terms of deployment
  • Tied to lifecycle of controller

Consq: You have to deal with replication yourself for most of them-- Most of the DB engine have replication support in standalone version only

Candidates: OrientDB -- EmbeddedVersion -- claims to support replcation even used in embedded fashion -- handle recovery -- Licensing -- Community Edition -- Apache 2.0
Apache Derby -- Embedded Version -- handle recovery -- Licensing - Apache 2.0 -- didn't find any docs on replications

H2- Embedded Version -- handle recovery -- Licensing -- Mozilla Public License 1.1. (Modified), Eclipse Public License 1.0 -- not sure if replication is supported in embedded version

Shard Persisting Strategy

Option 1: Have multi-shard on a node in a single physical database

Pros:

  • In terms of accessing from the Code -- you have fixed set of connections etc
  • In terms of backup/restore you have to deal with one DB.
  • Replication if supported by DB Engine -- easy to setup need to deal with one physical DB.

Consq:

  • All shards data is in one physical db there could be contention?
  • Cannot apply different B&R and replication strategies ?
  • Purging particular shard data might be difficult i.e. leading to fragmentation etc.

Option 2: Have multi-shard on a node in different physical databases

Pros:

  • Provides flexibility in terms of moving shards ?
  • Logical separation might help in maintenance/performance evaluations -- leading to conclusions like we can support "n" shards on a node of this many resources?
  • backup and restore per shard might help?
  • Purging data is easier/efficient.

Consq:

  • Maintaining different physical files /transaction logs
  • Maintaining different set of connections in code?