Feature Request: multi-tenant, should add a concept "tenant" above "keyspace"

[weicao]

Is your improvement request related to a problem? Please describe.

in original vitess topology, keyspace means logic database, and each keyspace contains multiple shards. each tablet manages no more than one keyspace. vitess addresses tablets with keyspace.

while in wesql-scale, we allows a tablet manages multiple databases, and there is only one global implict keyspace for one backend wesql-server cluster. so the concept "keyspace" is of little use now.

In the future, wesql-scale may supports multi-tenants, that is, a single wesql-cluster may serve multiple wesql-server clusters. In this scenario, we should introduce a concept named "tenant", each tenant means a standalone wesql-server cluster, which contains multiple databases.

The similiarity of "keyspace" and "tenant" is that, vitess will distinguish, organize and lookup tablet using this concept.

So my suggestion is, we can use "tenant" to replace "keyspace", and before we supports multi-tenant, there is only one tenant for each vitess cluster.

[earayu]

and there is only one global implict keyspace for one backend wesql-server cluster.

Actually, there is one implict keyspace for each backend wesql-server database.
If there's a database 'db1' in wesql-server, there will be a 'db1' keyspace in wesql-scale.

So my suggestion is, we can use "tenant" to replace "keyspace", and before we supports multi-tenant, there is only one tenant for each vitess cluster.

Based on the fact above, 'tenant' is not a replacement of 'keyspace', it's more like a collection of 'keyspace'.

[weicao]

I see, yeah, then we will have a higher concept above the keyspace.
"tenant" <- "keyspace" (which is also a "database") <- "table"

[earayu]

As a prerequisite for multi-tenancy, we need to refactor our current routing module, which includes route.go, routing.go, resolver.go and modify some metadata structures. This is important for implementing multi-tenancy. The current routing module was customized for sharding and contains a lot of unnecessary code for our use case.

[earayu]

A thought:

1. keyspace is a collection of 'physical' databases in mysqld. keyspace act like 'logical' database, but we have this idea just for vertical splitting, not horizontal split.
2. A tenant can have multiple keyspaces of course
3. 'physical' databases should be able to move between mysqld instances, we can build some very interesting features based on this, for example: locality, geo-vertical-splitting, ...

[earayu]

3. 'physical' databases should be able to move between mysqld instances

What should be the granularity for allowing freedom to migrate in mysqld?
A group of tables (table group?), or a database.

[earayu]

Do we want to perform computational tasks, such as joining, in the proxy?

One approach is to specify a concept, such as a table group, where all tables within the group must be placed in the same MySQL server. The proxy pushes all computations to MySQL. However, if tables from different groups need to perform a join, it will not be supported.

The other approach is to implement a more complete planner and executor within the proxy, allowing joins to be performed within the proxy.