Page History

...

Looking at the evaluation, it's easy to notice that our protocol design is of “one size fits all” types. It is an intentional choice, because AI Apache Ignite is intended to be a general use case database designed for commodity hardware and work “fine” out of the box in common cases. Of course, there are cases where specialized solutions would work better. Additional optimizations and tuning capabilities can be introduced later.

...

The third requirement implies a CC protocol which allows for serialized schedules. We will look for alternatives later.

The fourth requirement implies not buffering a whole transaction in memory / or on disk.

The system also has to be horizontally scalable. To achieve scalability, the data will be partitioned using a hash or range partitioning method.  The exact partitioning method is not important for the purpose of this document. We treat a partition here as a synonym for a shard. Each partition is assigned to a cluster node and replicated to a predefined number of replicas to achieve high availability. Adding more nodes increases a number of partitions in the cluster (or reduces a number of partitions per node in case of static partitioning), thus increasing the scalability.

...

The performance is of not much importance attention in the proposed design. No goal is set to make the fastest database in the world. We just need the acceptable level of performance and the great level of usability. We can optimize later, following the step-by-step improvement of the product.

Turns out we want aGoogle Spanner clone. It seems it was designed keeping the similar goals in mind. Other known Spanner clones are Cockroachdb, Yugabyte.

...