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にリクエストを転送します。この場合、リモート実行が必要となり、リクエストのRT(Response Time)に一定の影響が出ます。
ODPはOceanBaseデータベースのリバースプロキシ層であり、ユーザー側からデータベース側へのルーティング選択と災害復旧機能を提供し、アプリケーションが分散型データベースを認識することを隠蔽します。OBServerには完全なSQLエンジン、ストレージエンジン、分散トランザクションエンジンが含まれており、SQLの解析、物理実行計画の生成と実行、およびトランザクションコミット時のPaxosプロトコルによる過半数コミットを担当し、高性能、高可用性、高スケーラビリティのデータベースサービスを提供します。ODPとOBServerは疎結合方式を採用しており、ODP上のルーティング情報の更新が遅延し誤ったルーティング選択が発生した場合でも、OBServer内部で再度転送され、結果を返す際にODPにルーティング情報の更新を通知します。
上述のように、アプリケーション層はユーザーのリクエストをプロキシサービスのODPに送信し、ODPのルーティングを経て、実際のサービスデータを提供するデータベースノードであるOBServerに送信され、実行結果は逆の経路を通じてアプリケーション層に返されます。リンク全体のコンポーネントは、さまざまな方法で高可用性を実現しています。
関連ドキュメント
データリンクに関する詳細情報については、データリンクの概要を参照してください。