Production rule engine feature

[huahaiy]

Likely will use iterative rules application (to take advantage of fast query engine) and support truth maintenance.

The goal is to support good balance between persistence, latency and truth-maintenance.

Some notes:

In term of functionality, see TypeDB and O'Doyle Rules.

Engines in the clojure world: clara, odoyle rules, naga don't have their own db, have to do inference in memory after feteching data from other dbs. clara and naga do not support relationship among the same type objects, e.g. person1 is a friend of person2.

Engines in the java world: drools are too heavy; easyrules and rulebook have similar problems of clara and naga. TypeDB is slow, for it does not cache inference results.

Some thoughts:

Inferred facts are stored separately from original. Inferred are invertedly indexed with the original, so truth maintenance is cheap.

[huahaiy]

For truth maintenance, see e.g. https://dspace.mit.edu/handle/1721.1/130767

[huahaiy]

We will keep the current Datalog rules as the API.

However, the current implementation of rule evaluation is a top-down approach, which can be less efficient than a bottom-up Datalog evaluation strategy. In fact, the current implementation cannot handle the math genealogy benchmark task (out of memory). The top-down approach also does not mesh well with our query optimizer.

So we will implement a new bottom-up rule evaluation algorithm. The progress is tracked at https://github.com/juji-io/datalevin/blob/rule/doc/rules.md