To better manage OceanBase Database, you need to learn about its basic concepts, including OceanBase clusters, zones, OBServer nodes (servers that run the observer process), resource pools, tenants, and partitions.
OceanBase Database is a financial-grade distributed relational database independently developed by Ant Group and Alibaba. OceanBase Database is managed based on OceanBase clusters. An OceanBase cluster consists of multiple OBServer nodes. Each OBServer node belongs to a zone. Generally, the number and configuration of servers are the same among zones. Multiple OBServer nodes constitute a resource pool for each application. Administrators can divide the resources into resource pools of different sizes and allocate them to tenants. Generally, we recommend that you allocate large resource pools to applications with high performance requirements and small resource pools to applications with low performance requirements.
Tenants can use resources in their resource pools to create databases, tables, and partitions.
The following figure shows the relationship between the basic concepts of OceanBase Database.
OceanBase clusters, zones, and OBServer nodes
A cluster consists of multiple OBServer nodes that belong to different zones. Each OBServer node belongs to a zone. A zone is a logical concept that represents a group of nodes with similar hardware availability in a cluster. It has different meanings in different deployment modes. For example, when the cluster is deployed in one IDC, nodes in a zone can belong to the same rack or switch. When the cluster is distributed across IDCs, each zone can correspond to an IDC. Each zone has two attributes: IDC and region, which describe the IDC to which the zone belongs and the region where the IDC is located. Generally, the region refers to the city where the IDC is located. The IDC and region attributes of zones must reflect the actual deployment conditions so that automatic disaster recovery and optimization strategies in the cluster can work better.
Resource pools and tenants
Multiple OBServer nodes in a cluster form a large resource pool. Administrators create virtual resource pools with different CPU, memory, and storage resources for tenants based on the tenant requirements. Resources allocated to each tenant are isolated to prevent resource contention among tenants. Memory resources are physically isolated, whereas CPU resources are logically isolated.
A tenant is a logical concept. In OceanBase Database, a tenant is a resource allocation unit and the basis for the management of database objects and resources. It is critical for system O&M, especially for the O&M of cloud databases. 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 Database forbids cross-tenant data access to avoid data theft. In terms of resource utilization, a tenant in OceanBase Database has exclusive resource quotas. In summary, a tenant can be seen as a container for database objects and resources such as CPU, memory, and I/O.
Data partitions and replicas
Based on the concept of table partitioning in conventional database services, OceanBase Database can divide the data of a table into different partitions. In addition, as a distributed database service, OceanBase Database copies the data in the same partition to multiple OBServer nodes to ensure high availability (HA) of data reads and writes. These data copies on different OBServer nodes are called replicas. The Paxos consensus protocol is used to ensure strong consistency among different replicas of the same partition. Each partition and its replicas comprise an independent Paxos group. One partition is the leader and the other partitions are followers. The leader supports strong-consistency reads and writes, and the followers support weak-consistency reads.
More information
For more information about the overall architecture of OceanBase Database and the cluster architecture, see the following topics: