Tips and info
Contributors: I am seeking the right people to get involved in the decision. Add your comments to this page, let's get the conversation started.
We agreed to examine the potential of Option 2 in more detail, and have now ultimately taken that approach to a released state.
A common scenario we come across with almost all metadata repositories we have seen is that they lack the ability to store historical information about metadata and respond to point-in-time inquiries. While Egeria's type system and APIs have been built from the beginning to support such history, we have not yet implemented a backend storage option that implements history.
Considering this comes up frequently as a common need, even to augment existing metadata repositories, providing such a historical store for metadata could be a somewhat narrow but nonetheless extremely common adoption point for Egeria.
We are currently considering implementation options for an initial approach to such a repository.
Data for decision support
- Identification of potential technologies to use as the backing store for such a repository.
|Option 1: bi-temporal RDBMS
|Option 2: bi-temporal graph
|Option 3: ?search index
|Using a bi-temporal relational database like DB2
Using a bi-temporal graph store like Crux
|Using a search index like Elastic
Start with some initial proof of concept activities like building some of the basic methods in a repository connector.
Leaving as an alternative approach that was suggested, but no further details available.
|Pros and cons
Estimated cost and effort
Follow-up action items
Copyright © 2016 Atlassian
This work is licensed under a Creative Commons Attribution-Non Commercial-Share Alike 4.0 International License.