ApsaraDB for OceanBase uses a shared-nothing architecture. This means that nodes do not share storage. A cluster is deployed across at least three zones. A data replica is stored in each zone. ApsaraDB for OceanBase contains no single point of failure. Each zone has multiple OBServer nodes. This ensures high reliability and high availability.
- The nodes are peers to one another. Each node has an independent SQL engine and storage engine. The storage engine can only access local data. The SQL engine can access global schemas and generate distributed query plans. The query executor accesses the storage engine of each node, distributes and collects data across nodes, executes the distributed query plans, and returns the results to the user.
- A node in one of the zones serves as the primary RootService node. Each of the other zones contains a node that serves as a backup for the primary RootService node. If an OBServer node fails, the primary RootService node can detect the failure and perform recovery operations. RootService is a functional module of the OBServer process. Each OBServer node has RootService features. RootService provides the following features: server and zone management, partition management, daily merge control, system bootstrap, and DDL operations.
Each ApsaraDB for OceanBase cluster is deployed in several zones. In most cases, a zone corresponds to a data center. To ensure data security and high availability, replicas of data are distributed across multiple zones. A failure in a single zone does not affect the database services of ApsaraDB for OceanBase. Each data center hosts several physical servers.
An OBServer is a service process of ApsaraDB for OceanBase. In most cases, an OBServer is the exclusive owner of a physical server. An OBServer can be used as an equivalent to the physical server where it resides. ApsaraDB for OceanBase identifies an OBServer by using the IP address and service port of the OBServer.
A table is the most basic database object. Tables in ApsaraDB for OceanBase are relational tables. Each table consists of several rows of records. Each row has the same predefined columns. Users can use SQL statements to add, delete, query, and modify tables. In most cases, a table has a primary key that consists of one or more columns. Each value set of the primary key is unique throughout the table.
A partition is a separate part of a table in a database. A table that is split into partitions is called a partition table. The data of a partition table is distributed across multiple partitions. A large table can be split into several partitions. Each partition contains several rows of the table. Based on different row-to-partition mapping methods, three partitioning types are available: hash partitioning, range partitioning, and key partitioning. Each partition can be split into subpartitions based on various dimensions. For example, a transaction record table is split into several hash partitions based on the user ID, and each hash partition is split into several range subpartitions based on the transaction time.