Tenant is a logical concept that represents a resource allocation unit in OceanBase Database. It is the basis for the management of database objects and resources. It is critical for system O&M, especially for databases residing in the cloud. In a sense, tenants are comparable to "instances" in a conventional database system. Tenants are completely isolated from each other. In terms of data security, OceanBase forbids cross-tenant access to protect user's data assets from exposure. In terms of resource utilization, a tenant has exclusive ownership of its allocated resource. In summary, a tenant can be seen as a container for database objects and resources such as CPU, memory, and I/O.
In OceanBase, tenants can be either system tenants or general tenants.
The system tenant is a built-in tenant that plays three major roles:
A container for system tables
All system tables are stored in the space for the system tenant.
A container for cluster administrators
Cluster-wide administration tasks such as adding/removing tenants, modifying system configuration, and the daily major compaction are only allowed for users under the system tenant.
Providing resources needed for system maintenance and administration tasks
The system tenant also allocates resources for operations that are not specific to any tenant, such as the leader election, log synchronization, and daily major compaction.
General tenants are created by the system tenant based on, for example, business requirements. A general tenant is equivalent to a database instance. When you create a tenant, you must specify its name and, more importantly, its resource allocation. A general tenant has all the characteristics of an instance:
It may create its users
It may create all objects such as database and tables
It has a separate set of system databases such as information_schema
It has a separate set of system variables
and other characteristics of a database instance
Multi-tenant separation can be implemented in a variety of ways with similar effects. OceanBase Database does this by implementing a virtualized SQL server within the database. The advantage is that the management of database service is centralized and transparent to the user. The overhead of tenant isolation is also low, making it possible to accommodate more tenants on a single server and reduce the overall cost of cloud-based service. Tenants are isolated in terms of CPU, I/O, and memory. Network isolation is not applied because the network is not a bottleneck.
As OceanBase Database is a distributed system, its multi-tenant architecture not only includes isolation on a single server but also involves scheduling among multiple servers. Load balancing in OceanBase Database can be divided into two layers. The first is tenant load balancing, which involves distributing the resource containers of each tenant among multiple OBServers. The second layer is partition load balancing. This is not necessary if the tenant is associated with only one server. If a tenant is spread across multiple servers, the tenant's partition must be evenly distributed among its resource containers. To avoid distributed transactions, OceanBase Database attempts to use single servers to accommodate smaller tenants as best as it can. As the resource demand of a tenant increases, OceanBase Database is able to automatically scale up in a way that's transparent to the user.