OceanBase Database is a cloud-native database service that features high scalability, high availability, high performance, and low costs. It adopts a shared-nothing architecture in which all nodes are identical. Each node has its own SQL engine and storage engine. The nodes run in clusters that consist of regular PC servers.
An OceanBase cluster consists of multiple nodes. Each node belongs to a zone. The term zone is a logical concept that represents a set of nodes with similar hardware availability in a cluster. It has different meanings in different deployment modes. For example, if a cluster is deployed in one IDC, nodes in a zone can belong to the same rack and the same switch. If a cluster is deployed across IDCs, each zone can correspond to one IDC. Each zone has two properties: IDC and region, which specify the IDC in which the zone resides and the region in which the IDC resides. Typically, a region is the city in which an IDC resides. The system improves the policy used to implement and optimize automatic failover in clusters based on the IDCs and regions of zones. OceanBase Database provides multiple deployment modes based on different high-availability requirements for database systems. For more information, see Overview.
In OceanBase Database, data in a table can be horizontally divided into multiple shards based on a specific division rule. Each shard is a partition. A row of data belongs to only one partition. You can specify partitioning rules when you create a table. Partitions of the hash, range, and list types, and subpartitions are supported. For example, you can divide an order table in a transaction database into several partitions by user ID, and then divide each partition into several subpartitions by month. In a subpartition table, each subpartition is a physical partition, while a partition is only a logical concept. Multiple partitions of a table can be distributed across multiple nodes in a zone.
To protect data and ensure service continuity when a node fails, each partition has multiple replicas. Typically, multiple replicas of a partition are distributed across zones. You can modify only one of the replicas, which is referred to as a leader. Other replicas are referred to as followers. Data consistency between the leader and the followers is ensured based on the Multi-Paxos protocol. When the node in which the leader resides fails, a follower is selected as a new leader to provide services. To balance costs and performance, OceanBase Database provides multiple replica types. For more information, see Overview.
Each node in the cluster runs an observer process, which contains multiple operating system threads. All nodes provide the same features. Each observer process accesses data of partitions on the node in which it runs, and parses and executes SQL statements routed to the node. The observer processes communicate with each other by using the TCP/IP protocol. In addition, each observer process listens to connection requests from external applications, establishes connections and database sessions, and provides database services. For more information about observer processes, see Overview.
OceanBase Database provides the unique multi-tenancy feature to simplify the management of multiple business databases deployed on a large scale and reduce resource costs. In an OceanBase cluster, you can create multiple isolated database instances, which are referred to as tenants. From the perspective of applications, each tenant is a separate database. In addition, you can create a tenant in MySQL- or Oracle-compatible mode. After your application is connected to a MySQL-compatible tenant, you can create users and databases in the tenant. The user experience is similar to that with a standalone MySQL database. In the same way, after your application is connected to an Oracle-compatible tenant, you can create schemas and manage roles in the tenant. The user experience is similar to that with a standalone Oracle database. After a new cluster is initialized, a system tenant is created. The system tenant is a MySQL-compatible tenant that stores the metadata of the cluster.
To isolate the resources of different tenants, each observer process can contain multiple VMs that belong to different tenants, which are referred to as resource units. The resource units of a tenant that are distributed on multiple nodes constitute a resource pool. A resource unit consists of CPUs and memory.
OceanBase Database provides OBProxies to shield internal details such as the distribution of partitions and replicas from applications. Therefore, applications can access OceanBase Database like they access a standalone database. An application does not directly connect to an OBServer. Instead, it connects to an ODP. Then, the ODP forwards SQL requests to an appropriate OBServer. OBProxies are stateless. Multiple OBProxies provide a unified network address for applications by using a server load balancer (SLB) instance.