In the distributed architecture of OceanBase Database, data is distributed across multiple OBServer nodes. OceanBase Database Proxy (ODP), formerly known as OBProxy, is introduced to simplify data access in the distributed architecture so that applications can access OceanBase Database the same way they access a standalone database. ODP is a reverse proxy service designed for SQL statement routing and disaster recovery in OceanBase database.
Three ways are available to deploy ODP as a core component of the data link.
Deployed with an OBServer node: An ODP and an OBServer node are deployed on the same server. This deployment mode is typically used in private cloud scenarios but can cause difficulty in troubleshooting due to resource contention during high traffic.
Deployed independently: ODP is deployed as a cluster independent of OBServer nodes. This deployment mode is usually used in public cloud scenarios.
Deployed on a client: ODP runs in a container near the AppServer container within the same pod and can be upgraded, published, and maintained separately. This deployment mode has high requirements for the control plane and is rarely used in practice.
In the first two deployment modes, AppServer accesses ODP through a load balancer that manages high availability and load balancing for ODP. For example, F5 distributes requests to multiple ODP instances.
ODP can be provided as instances or SDKs. ODP SDKs are integrated into business code as libraries. ODP SDKs shorten the access link by one hop, achieving higher performance and simplifying the troubleshooting process. However, ODP SDKs are more tightly coupled to business code, causing mutual interference. In addition, upgrade and maintenance operations also affect the business.
After ODP is introduced, a data link in OceanBase Database is as follows: AppServer <-> ODP <-> OBServer nodes. AppServer accesses ODP by using a database driver to send requests. In the distributed architecture of OceanBase Database, user data is distributed on multiple OBServer nodes through multiple log streams and multiple replicas. ODP forwards requests to the most appropriate OBServer nodes for execution and returns the execution results. Each OBServer node can also provide routing and forwarding capabilities. If an OBServer node receives a request it cannot execute, it forwards the request to the correct node. This scenario involves remote execution and has a longer request response time (RT).
As the reverse proxy layer of OceanBase Database, ODP provides routing and disaster recovery from the client to the database, so that applications are unaware of the distributed architecture of the database. An OBServer node has a SQL engine, storage engine, and distributed transaction engine, which parse SQL statements to generate and execute physical execution plans while committing transactions based on the Paxos protocol. OBServer nodes provide database services featuring high performance, high availability, and high scalability. ODP is loosely coupled to an OBServer node to tolerate incorrect routing in case that the routing information on ODP is not updated in a timely manner. The OBServer node forwards the request again. When the OBServer node returns the results, it notifies ODP to update the routing information.
In the data link, AppServer sends user requests to ODP, and ODP forwards the requests to active OBServer nodes. The execution results are returned to AppServer through a reverse path. Different components in the data link contribute to high availability in different ways.