We are taking care of keeping storage space to a minimum, while supporting the reconstruction of any revision in linear time.
Furthermore we allow time travel queries such that you're able to analyse the history of your data efficiently in order to predict the future or to do audits.
Not enough? What about correcting any human or application errors or to compare any revision of your XML- or JSON-documents efficiently?
We are versioning data as well as index-structures on a per revision and per record/node level. As such versioning takes place at a fine-granular level. Furthermore through a novel versioning algorithm called sliding snapshot we are able to avoid write- and read-peaks.
We allow sophisticated time travel queries, such that you are able to analyse the history of your data or to retrieve the differences efficiently.
You decide how your data looks like and which format fits best. We currently support both the import of XML as well as JSON data.
Several extensions to an XQuery-processor called Brackit are available. We for instance support navigation via novel temporal XPath axis not only in space but also in time. Furthermore, several additional precompiled functions are available to simplify the analysis of your temporal data. The API also provides a very convenient way to interact with Sirix. Think of it as an in-memory representation of a DOM.
Our low-level, transactional, cursor based API is very powerful. We not only provide standard XPath axis and additionally temporal enhancements to navigate in time, but also several other axis as for instance a LevelOrder axis, a PostorderAxis, a DescendantAxis which can skip whole subtrees. Furthermore, we provide several filters and much more.
We provide a way to currently import several revisions of an XML-document with the help of a diffing-algorithm called Fast Matching Simple EditScript. With the help of this diff-algorithm we are able to import not the whole changed second, third and so on version of the document but only the encountered differences between any two versions.
Once we have stored several revisions in Sirix, either through the import diff-algorithm or simply through working with Sirix in the first place we are able to quickly compute diffs between any two revisions because of our stable node identifiers and optionally stored hashes (each time two hashes are equal, the whole subtree can be skipped).