The main distinctive features are our main document store index, features inherited by ZFS (checksums in parent pointers, the main index, a trie, compression and hopefully soon encryption of page-fragments, always consistent on-disk, log-structured without the need of a WAL...), versioned user-defined indexes, highly concurrent data structures (every transaction has access to one snapshot and we only allow one read/write transaction, parallelization has to be done by the client code) and record-level versioning (also a novel sliding window algorithm -- whereas a slightly other implementation is patented by the founder Marc Kramis).
I might implement pointer swizzling for the upcoming 1.0.0 release, should speedup Sirix considerably :-)
I think XQuery is great for querying JSON data. That said in the future I'd also implement something based on Spark to distribute queries...
The documentation page alludes to payroll, audit and decision support applications -- have you implemented one or more of those already? I have been compiling a list of known uses for bitemporality in the Crux docs which you are more than welcome to borrow from:
It is great to see all this new enthusiasm for temporal databases now that they are finally viable, decades after all the major research happened :)
- storing business time in Datomic is inefficient because it has to be added to the transaction which I don't think is added to indexes, this is the primary use case of crux though
- cardinality is defined up front in Datomic which I suspect catches data integrity errors, I haven't seen anything in crux to support this
- crux doesn't support either the pull or entity syntax ( I don't know which one or why that's important, I'm a bit out of my depth now)
And Sebastian worked under supervision from Dr. Theo Härder :-)
Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification.
from here https://www.w3.org/TR/xml/#sec-common-syn
so I think the following
is not well-formed, or has there been some change I've missed?
So what's the real use-case?
Furthermore Sirix does not have to copy whole record pages which have changed, it depends on the chosen versioning algorithm. The whole structure is highly concurrent and allows client side parallelism. We also do not have to write in a WAL first, but the structure is always consistent (if no hardware failure occurs...).
Thanks and have a great day :)
Oh and maybe another interesting article:
More information: https://github.com/JohannesLichtenberger/master-thesis/raw/m...
And maybe adding memory mapped files in the future.
Have a great evening