Дмитрий Кольцов authored 2 years ago and Denis Smirnov committed 2 years ago

Co-authored-by: Denis Smirnov <sd@picodata.io>

As a side effect we lost an ability to replace already existing
tuples. As a result we have detected a problem in regression tests:
concurrent distributed truncate and insert commands can execute out
of order on different segments. As a result we get "duplicate key"
errors. To deal with it, init tables and truncate them only once:
at the beginning and at the end of the test group.

After implementing cartridge sharding mock tests were mostly
useless: we didn't see how we modify SQL according to some specific
shard.

Now (in a case of the filtered buckets when we send a query to exact
shards) mock engine generates SQL for every shard. This behavior
differs from the cartridge engine that groups buckets by replicasets
first and then generated SQL for a replicaset bucket group. But the
idea of the mock engine is to detect errors but not to implement
actual Tarantool. So, lets make things simple and use this approach.

Previously we had a data sharding only on the planner side.

docs(README): state that Sbroad is an executor for `cartridge`-based cluster, because `vshard` cluster is required but not enough

Also added missed pretty_assertions to some of the tests in the
cartridge module.

At the moment all the query ASTs are cached in the engine LRU cache.
There is not much sense in it since we don't support parameters at
the moment, but it would be done later.

To get ready for parameters we have also added parameters support
in the grammar, but didn't implement it in the AST code.

At the moment our grammar doesn't support any sub-queries in the
projection list. So it is a waste of CPU resourcies to transform
projection lists (a big performance penalty for projections with
a huge amount of columns).

Previously for every query we hold a mutable reference on an engine
and tried to load a cluster metadata if the cache was empty. The
problem was that tarantool yields on a first query uploading the
cache to a new one, that also tries to get a mutable reference to
the engine.
The main problem was that we should never hold a mutable reference
to an object with a Lua code, that can be yielded by tarantool
(such behavior is opaque to the Rust compiler). To deal with it we
shrink a metadata upload to a list of separate methods. For the
ones that can yield we always hold an immutable reference. Those
methods that need a mutable reference to the engine never yield.