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に送信され、実行結果は逆の経路でアプリケーション層に返されます。リンク全体のコンポーネントは、異なる方法で高可用性を実現します。
関連ドキュメント
データリンクに関する詳細情報については、データリンクの概要を参照してください。