3 ms·
1) the single-writer principle of the transaction log means there's no need for any transactional locking 2) the separation of reads and writes allows for eleg
by refset 7y ago
1) the single-writer principle of the transaction log means there's no need for any transactional locking
2) the separation of reads and writes allows for elegant horizontal read-scaling without coordination/consensus
3) pluggable storage backends implemented as simple Clojure protocols (as the sibling comment mentions), which eliminates a large number of performance and durability concerns
4) combining schema-on-read with entity-attribute-value indexing means there's no need to interpret and support a user-defined schema
5) Datalog is simpler to implement and use than the full SQL standard or alternative graph query languages
...I work on Crux :)
- simplify 7y agoPlease tell us more about point 5!
- refset 7y agoCrux uses a Worst-Case Optimal Join [0] algorithm with bitemporal indexes, and the Datalog-specific query layer is implemented in less than a thousand lines of Clojure: https://github.com/juxt/crux/blob/master/crux-core/src/crux/query.clj https://github.com/juxt/crux/blob/master/crux-core/src/crux/... SQL certainly provides a lot of bells and whistles but Crux has the advantage of consistent in-process queries (i.e. the "database as a value") which means you can combine custom code with multiple queries efficiently to achieve a much larger range of possibilities, such as graph algorithms like Bidirectional BFS [1]. [0] https://arxiv.org/pdf/1803.09930.pdf https://arxiv.org/pdf/1803.09930.pdf [1] https://github.com/juxt/crux/blob/master/docs/example/imdb/src/imdb/main.clj https://github.com/juxt/crux/blob/master/docs/example/imdb/s...