RecallGraph - A versioning data store for time-variant graph data.
RecallGraph is a versioned-graph data store - it retains all changes that its data (vertices and edges) have gone through to reach their current state. It supports point-in-time graph traversals, letting the user query any past state of the graph just as easily as the present.
It is a Foxx Microservice for ArangoDB that features VCS-like semantics in many parts of its interface, and is backed by a transactional event tracker. It is currently being developed and tested on ArangoDB v3.5, with support for v3.6 in the pipeline.
While the software has demonstrated ample stability under test conditions, it is still under active development, and subject to potentially breaking changes from time to time. The latest tagged version may be used in lightweight, non-critical production deployments, i.e., systems which do not impact primary business functions if they face downtime or data loss/corruption. Note that there are no battle-hardened, stable releases yet.
The authors and maintainers of RecallGraph are not liable for damages or indemnity (express or implied) for loss of any kind incurred directly or indirectly as a result of using this software.
Do I Need a 'Versioned Graph' Database?
To get an idea of where such a data store might be used, see:
TL;DR: RecallGraph is a potential fit for scenarios where data is best represented as a network of vertices and edges (i.e., a graph) having the following characteristics:
- Both vertices and edges can hold properties in the form of attribute/value pairs (equivalent to JSON objects).
- Documents (vertices/edges) mutate within their lifespan (both in their individual attributes/values and in their relations with each other).
- Past states of documents are as important as their present, necessitating retention and queryability of their change history.
Salient API Features
RecallGraph's API is split into 3 top-level categories:
- Create - Create single/multiple documents (vertices/edges).
- Replace - Replace entire single/multiple documents with new content.
- Delete - Delete single/multiple documents.
- Update - Add/Update specific fields in single/multiple documents.
- (Planned) Explicit Commits - Commit a document's changes separately, after it has been written to DB via other means (AQL / Core REST API / Client).
- (Planned) CQRS/ES Operation Mode - Async implicit commits.
- Log - Fetch a log of events (commits) for a given path pattern (path determines scope of documents to pick). The log can be optionally grouped/sorted/sliced within a specified time interval.
- Diff - Fetch a list of forward or reverse commands (diffs) between commits for specified documents.
- (Planned) Branch/Tag - Create parallel versions of history, branching off from a specific event point of the main timeline. Also, tag specific points in branch+time for convenient future reference.
- (Planned) Materialization - Point-in-time checkouts.
- Show - Fetch a set of documents, optionally grouped/sorted/sliced, that match a given path pattern, at a given point in time.
- Filter - In addition to a path pattern like in 'Show', apply an expression-based, simple/compound post-filter on the retrieved documents.
- Traverse - A point-in-time traversal (walk) of a past version of the graph, with the option to apply additional post-filters to the result.
RecallGraph installs like any other Foxx Microservice inside a database on an ArangoDB instance.
- Download the latest release.
- Follow the instructions in the Foxx Deployment Manual. The web interface is the easiest, while the
foxx-cliis more suitable for power users.
Note: A one-click cloud deployment option might be made available in the future for those who wish to take RecallGraph for a test ride without having to set up a server from scratch.
- Quick-reference API documentation is available directly in the Swagger console (accessed through ArangoDB's web UI).
- Detailed API docs, tutorials and technical docs are being worked on, and will be available soon.
- Although the test cases are quite extensive and have good coverage, this service has only been tested on single-instance DB deployments, and not on clusters.
- As of version 3.5, ArangoDB does not support ACID transactions for multi-document/collection writes in cluster mode. Transactional ACIDity is not guaranteed for such deployments.
- Support for absolute/relative revision-based queries on individual documents (in addition to the timestamp-based queries supported currently),
- Branching/tag support,
- Support for the valid time dimension in addition to the currently implemented transaction time dimension (https://www.researchgate.net/publication/221212735_A_Taxonomy_of_Time_in_Databases),
- Support for ArangoDB v3.6,
- Multiple, simultaneous materialized checkouts (a la
git) of selectable sections of the database (entire DB, named graph, named collection, document list, document pattern), with eventual branch-level specificity,
- CQRS/ES operation mode (async implicit commits),
- Explicit commits,
- Support for ArangoDB clusters (limited at present by lack of support for multi-document ACID transactions in clusters).
- Multiple authentication and authorization mechanisms.
Get in Touch
- Raise an issue or PR on this repo, or
- Mail me (email link in Github profile), or
- Join the Gitter channel - https://gitter.im/RecallGraph/community.