OceanBaseデータベースは分散データベースとして、データは自然に複数のノードに分散されています。分散データベースがアプリケーションにもたらす複雑さを隠蔽し、アプリケーションがOceanBaseデータベースに単一マシンのデータベースにアクセスするかのように簡単にアクセスできるようにするため、アーキテクチャ上、ODP（OceanBase Database Proxy、別名OBProxy）が導入されています。ODPはOceanBase専用のリバースサービスプロキシであり、OceanBaseデータベースのSQLルーティングと災害復旧の問題を解決します。
ODPはデータリンク上のコアコンポーネントとして、様々なデプロイメント形態が存在します：
OBServer側へのデプロイ：ODPとOBServerを同一マシンにデプロイします。負荷が高い場合、リソース競合が発生する可能性があり、問題の調査が困難になることがあります。プライベートクラウドのシナリオで一般的です。
ODP単独デプロイ：ODPを独立したクラスタとしてデプロイすることで、ODPとOBServerの相互影響を軽減します。パブリッククラウドのシナリオで一般的です。
クライアント側へのデプロイ：APPServerコンテナの横に別のコンテナを起動してODPを実行し、両者を同一Pod内に配置します。これにより、独立したアップグレード、リリース、運用保守などが可能です。このデプロイメント形態は制御面での要件が高く、実際の使用はあまりありません。
最初の2つのデプロイメント形態では、APPServerがODPにアクセスする際には、負荷分散コンポーネントの層を経由する必要があります。この負荷分散コンポーネントはODPの高可用性と負荷分散を担当します。例えば、F5はリクエストを複数のODPに分散します。
製品形態として、ODPにはプロキシ形態の他にSDK形態もあります。SDK形態はライブラリとして業務コードに統合され、プロキシモードと比較して、アクセスリンクが1ホップ少なく、パフォーマンスが優れ、問題の調査におけるリンクが短くなります。しかし、業務コードとの結合度が高く相互に影響し合い、ODP SDKのアップグレード時には業務の再起動が必要などの欠点があります。
ODPを導入した後、OceanBaseのデータリンクはAPPServer <-> OBProxy <-> OBServerとなります。APPServerはデータベースドライバを通じてODPに接続し、リクエストを送信します。OceanBaseデータベースの分散アーキテクチャにより、ユーザーデータは複数のログストリーム・複数レプリカの形式で複数のOBServerに分散されています。ODPはユーザーリクエストを最適なOBServerに転送して実行し、実行結果をユーザーに返します。各OBServerにもルーティング転送機能があり、リクエストが現在のノードで実行できない場合は、正しいOBServerに転送します。このシナリオでは1回のリモート実行が必要となり、リクエストのRT（Response Time）に一定の影響があります。
ODPはOceanBaseデータベースのリバースプロキシ層であり、ユーザー端からデータベース端へのルーティング選択と災害復旧機能を提供し、アプリケーションの分散データベースに対する認識を隠蔽します。OBServerは完全なSQLエンジン、ストレージエンジン、分散トランザクションエンジンを含み、SQLの解析、物理実行計画の生成と実行、およびトランザクションコミット時のPaxosプロトコルによる多数派コミットを担当し、高性能・高可用性・高拡張性のデータベースサービスを提供します。ODPとOBServerは疎結合の方式を採用しており、ODP上のルーティング情報の更新が遅延し誤ったルーティング選択が発生した場合でも、OBServer内部で再度転送し、結果を返す際にODPにルーティング情報の更新を通知します。
上述のように、アプリケーション層はユーザーリクエストをプロキシサービスのODPに送信し、ODPのルーティングを経て、実際のサービスデータを持つデータベースノードであるOBServerに送信され、実行結果は逆の経路でアプリケーション層に返されます。リンク全体のコンポーネントは、それぞれ異なる方法で高可用性を実現しています。
関連ドキュメント
データリンクに関する詳細情報については、データリンクの概要を参照してください。