An easy answer is that Crux is "strongly consistent" with ACID semantics.
A Crux ClusterNode system provides sequential consistency by default due to
the use of a single unpartitioned Kafka topic for the transaction log. Being
able to read your writes requires stickiness to a particular node. For a
ClusterNode system to be linearizable as a whole would require that every node
always sees the result of every transaction immediately after it is written.
This could be achieved with the cost of non-trivial additional latency. Forms
of causal consistency across multiple Crux systems could potentially be
achieved through the use of valid time
. Further reading:
http://www.bailis.org/papers/hat-vldb2014.pdf,
https://jepsen.io/consistency/models/sequential
Crux does not try to enforce consistency among nodes, which all
consume the log in the same order, but may be at different points. A
client using the same node will have a consistent view. Reading your own
writes can be achieved by providing the transaction time Kafka assigned
to the submitted transaction, which is returned in a promise from
crux.tx/submit-tx
, in the call to crux.query/db
. This will block
until this transaction time has been seen by the cluster node.
Write consistency across nodes is provided via the :crux.db/cas
operation. The user needs to attempt to perform a CAS, then wait for the
transaction time (as above), and check that the entity got updated. More
advanced algorithms can be built on top of this. As mentioned above, all
CAS operations in a transaction must pass their pre-condition check for
the transaction to proceed and get indexed, which enables one to enforce
consistency across documents. There is currently no way to check if a
transaction got aborted, apart from checking if the write succeeded.
It of course depends.
While Crux does not enforce a schema, the user may do so in a layer above to achieve the semantics of schema-on-read (per node) and schema-on-write (via a gateway node). Crux only requires that the data can be represented as valid EDN documents. Data ingested from different systems can still be assigned qualified keys, which does not require a shared schema to be defined while still avoiding collision. Defining such a common schema up front might be prohibitive and Crux instead aims to enable exploration of the data from different sources early. This exploration can also help discover and define the common schema of interest.
Enforcing constraints on the data to avoid indexing all attributes can
be done with crux.index.ValueToBytes
. Crux does this internally via
crux.index.ValueToBytes
for strings for example, only indexing the
full string with range query support up to 128 characters, and as an
opaque hash above that limit. Returning an empty byte array does not
index a value. We are aiming to extend this to give further control over
what to index. This is useful both to increase throughput and to save
disk space. A smaller index also leads to more efficient queries.
The valid time can be set manually per transaction operation, and might already be defined by an upstream system before reaching Crux. This also allows to deal with integration concerns like when a message queue is down and data arrives later than it should.
If not set, Crux defaults valid time to the transaction time, which
is the LogAppendTime
assigned by the Kafka broker to the transaction
record. This time is taken from the local clock of the Kafka broker,
which acts as the master wall clock time.
Crux does not rely on clock synchronisation or try to make any guarantees about valid time. Assigning valid time manually needs to be done with care, as there has to be either a clear owner of the clock, or that the exact valid time ordering between different nodes doesn’t strictly matter for the data where it’s used. NTP can mitigate this, potentially to an acceptable degree, but it cannot fully guarantee ordering between nodes.
No. We have a simple ingestion mechanism for RDF data in crux.rdf
but this is not a core feature. There is a also a query translator for a
subset of SPARQL. RDF and SPARQL support could eventually be written as
a layer on top of Crux as a module, but there are no plans for this by
the core team.
Not directly, currently. As the log is ingested in the same order at all
nodes, purely functional transformations of the tx-ops are possible. The
current transaction operations are implemented via a multi-method,
crux.tx/tx-command
which is possible to extend with further implementations.
To make this work the spec :crux.tx/tx-op
also needs to be extended to accept
the new operation. A transaction command returns a map containing the keys
:kvs
:pre-condition-fn
and :post-condition-fn
(the functions are
optional). Alternatively you may use a "gatekeeper" pattern to enforce the
desired level of transaction function consistency required.
No. The :where
part is similar, but only the map form of queries are
supported. There is no support for Datomic’s built-in functions, or for
accessing the log and history directly. There is also no support for variable
bindings or multiple source vars.
Other differences include that :rules
and :args
, which is a relation
represented as a list of maps which is joined with the query, are being
provided in the same query map as the :find
and :where
clause. Crux
additionally supports the built-in ==
for unification as well as the
!=
. Both these unification operators can also take sets of literals as
arguments, requiring at least one to match, which is basically a form of
or.
Many of these aspects may be subject to change, but compatibility with other Datalog databases is not a goal for Crux.
The goal is to support different languages, and decouple the query
engine from its syntax, but this is not currently the case.
There is a query translator for a subset of SPARQL in crux.rdf
.
Not currently. We are considering support for sharding the document topic as
this would allow nodes to easily consume only the documents they are interested
in. At the moment the tx-topic
must use a single partition to guarantee
transaction ordering. We are also considering support for sharding this topic
via partitioning or by adding more transaction topics. Each partition / topic
would have its own independent time line, but Crux would still support for
cross shard queries. Sharding is mainly useful to increase throughput.
No. As each Crux query node is its own document store, the documents are local to the query node and can easily be accessed directly via the lower level read operations. We aim to make this more convenient soon.
We are also considering support for remote document stores via the
crux.db.ObjectStore
interface, mainly to support larger data sets, but
there would still be a local cache. The indexes would stay local as this
is key to efficient queries.
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close