ODPは、ユーザーのリクエストに関連するレプリカの場所、ユーザーが設定した読み書き分離のルーティングポリシー、OceanBaseデータベースの複数地域展開における最適なリンク、およびOceanBaseデータベースの各マシンの状態と負荷状況を十分に考慮し、ユーザーのリクエストを最適なOBServerノードにルーティングします。これにより、OceanBaseデータベース全体の高いパフォーマンスを最大限に保証します。
このセクションの内容を読み始める前に、以下の内容をより深く理解するために、ルーティングに関連するいくつかの概念を確認しておくと役立ちます。
Zone
Region
Server List
RS List
Location Cache
レプリカ
メジャーコンパクション
強整合性読み取り/弱整合性読み取り
読み書きZone
パーティションテーブル
パーティションキー
OceanBaseデータベースの実行計画
実行計画は3種類に分類されます：Local、Remote、Distribute。ODPの主な役割は、Remote計画（効率が低く、パフォーマンスが悪い）をできるだけ回避し、ルーティングをできるだけ正確にLocal計画に変換することです。
ODPルーティングの仕組み
上記の可用ゾーン/リージョン/パーティション/レプリカの基本概念と物理的意味を理解すれば、ODPのルーティングの考え方を理解できます。パーティションの設計からその物理的配置、およびローカル実行計画の効率性を考慮し、ODPはSQLを可能な限り正確にルーティングする必要があります。主な処理過程は、SQL解析、パーティション計算、パーティション情報取得、レプリカポリシー選択などです。
非パーティションテーブルのルーティング
非パーティションテーブルは、Location Cache内のレプリカ情報を直接利用できます。ODPはパーティションとOBServerノードアドレスのマッピングを保持しており、SQL内のテーブル名を解析し、そのテーブル名に基づいてODPキャッシュ内のパーティション対応のマシンIPを照会します。キャッシュの有効性には、以下の3つのケースがあります：
キャッシュで見つからない場合、OBServerノードにアクセスして最新のマッピングを照会し、キャッシュします。
キャッシュに存在するが利用できない場合、OBServerノードに再度クエリを実行し、更新する必要があります。
キャッシュに存在し、利用可能な場合、そのまま使用できます。
パーティションテーブルのルーティング
パーティションテーブルのルーティングは、非パーティションテーブルと比較して、パーティションIDおよび関連する計算とクエリプロセスが追加されます。Location Cacheを取得した後、パーティションテーブルは、テーブルのパーティションおよびサブパーティションを判断し、さまざまなパーティションキーの種類と計算方法に基づいてパーティションIDを計算し、対応するプライマリ/スタンバイレプリカ情報を取得する必要があります。
パーティション計算時には、テーブル構造からパーティションキーとそのタイプを把握し、SQL文を解析して対応するパーティションキーの値を取得します。そして、テーブル構造とパーティションキーのタイプに基づいてパーティション計算を行い、対応するパーティションが配置されているマシンに転送します。
通常、パーティション計算により、ODPはSQLをパーティションに対応するマシンにルーティングし、Remote実行を回避して効率を向上させます。ODP V3.2.0では、パーティションテーブルでパーティションルートが計算できない場合に対する最適化が行われました。これにより、テナントのマシンをランダムに選択するルーティングから、パーティションが分散配置されているマシンの中からランダムにルーティングする方式へと最適化され、ヒット率が向上し、Remote実行を可能な限り減らすことができます。
レプリカルーティングの選択（通常デプロイメント）
強整合性読み取りで、かつSQLにテーブル名が指定されている場合、そのテーブルの対応するパーティションのLeaderを保持するOBServerノードにルーティングされます。弱整合性読み取り、ログイン認証リクエスト、強整合性読み取りでテーブル名が指定されていない場合などには、プライマリ/スタンバイ均等ルーティング（デフォルト）、スタンバイ優先ルーティング、非メジャーコンパクション時のスタンバイ優先ルーティングの3つのルーティングポリシーが存在します。
プライマリ/スタンバイ均等ルーティング（デフォルト）
ルーティングの選択は以下の優先順位で行われます：
同一リージョン、同一IDC（同一データセンター）で、メジャーコンパクション状態にないノード。
同一リージョン、異なるIDC（異なるデータセンター）で、メジャーコンパクション状態にないノード。
同一リージョン、同一IDC（同一データセンター）で、メジャーコンパクション状態のノード。
同一リージョン、異なるIDC（異なるデータセンター）で、メジャーコンパクション状態のノード。
異なるリージョンで、メジャーコンパクション状態にないノード。
異なるリージョンで、メジャーコンパクション状態のノード。
スタンバイ優先ルーティング
通常デプロイメントでは、スタンバイ優先読み取りポリシーをサポートしています。ユーザーレベルのシステム変数 proxy_route_policy で制御され、通常デプロイメントと弱整合性読み取りの場合にのみ有効で、プライマリ/スタンバイ均等ルーティングではなく、Followerから優先的に読み取ります。
通常モードデプロイメントと弱整合性読み取り時に、set @proxy_route_policy='follower_first'; を設定すると、ルーティングはOBServerノードがメジャーコンパクション状態にあっても、優先的にスタンバイノードに送信されます。ルーティングの選択は以下の優先順位で行われます：
同一リージョン、同一IDCで、メジャーコンパクション状態にないスタンバイノード。
同一リージョン、異なるIDCで、メジャーコンパクション状態にないスタンバイノード。
同一リージョン、同一IDCで、メジャーコンパクション状態のスタンバイノード。
同一リージョン、異なるIDCで、メジャーコンパクション状態のスタンバイノード。
同一リージョン、同一IDCで、メジャーコンパクション状態にないプライマリノード。
同一リージョン、異なるIDCで、メジャーコンパクション状態にないプライマリノード。
異なるリージョンにある、メジャーコンパクション中でないスタンバイノード。
異なるリージョンにある、メジャーコンパクション中のスタンバイノード。
異なるリージョンにある、メジャーコンパクション中でないプライマリノード。
異なるリージョンにある、メジャーコンパクション中のプライマリノード。
メジャーコンパクション中でないスタンバイノードへの優先ルーティング
通常デプロイメントでは、弱い整合性読み取りにおいて、set @proxy_route_policy='unmerge_follower_first'; を設定すると、ルーティングはメジャーコンパクション中でないスタンバイノードに優先的に送信されます。ルーティングの選択は以下の優先順位で行われます：
同一リージョン、同一IDC、メジャーコンパクション中でないスタンバイノード。
同一リージョン、異なるIDC、メジャーコンパクション中でないスタンバイノード。
同一リージョン、同一IDC、メジャーコンパクション中でないプライマリノード。
同一リージョン、異なるIDC、メジャーコンパクション中でないプライマリノード。
同一リージョン、同一IDC、メジャーコンパクション中のスタンバイノード。
同一リージョン、異なるIDC、メジャーコンパクション中のスタンバイノード。
異なるリージョンにある、メジャーコンパクション中でないスタンバイノード。
異なるリージョンにある、メジャーコンパクション中でないプライマリノード。
異なるリージョンにある、メジャーコンパクション中のスタンバイノード。
異なるリージョンにある、メジャーコンパクション中のプライマリノード。
読み取り専用レプリカへの強制ルーティング
通常デプロイメントでは、弱い整合性読み取りにおいて、set @proxy_route_policy='FORCE_READONLY_ZONE'; を設定すると、ルーティングはすべての読み取り専用リクエストを非読み取り専用レプリカに転送しません。そのルールは以下の通りです：
- 弱い整合性読み取りリクエスト：読み取り専用レプリカ内のノードにルーティングします。
- 強い整合性読み取りリクエスト：
4007エラーを返します。このルーティングルールでは非読み取り専用リクエストは許可されません。業務上非読み取り専用リクエストの送信が必要な場合は、変数ob_route_policyの値を他のルールに設定してください。
その他
通常デプロイメントでは、弱い整合性読み取りにおいて、proxy_route_policy 変数が他の値を取る場合、ルーティングの選択は通常の弱い整合性読み取りのプライマリ/スタンバイ均等ルーティングポリシー、すなわちプライマリ/スタンバイ均等ルーティング（デフォルト）に退化します。
レプリカのルーティング選択（読み書き分離デプロイメント）
読み取り専用レプリカを使用したデプロイメントモードです。読み書き分離デプロイメントでは、スタンバイ優先読み取りのルーティングポリシーは存在せず、ルーティングはシステム変数 ob_route_policy に依存します。主なケースは以下の通りです：
強い整合性読み取り文で、かつSQLにテーブル名が指定されている場合、そのテーブルに関連するパーティションのリーダーであるOBServerノードに直接ルーティングされます。
強い整合性読み取り文で、SQLが「select テーブル名未指定/use database/set session セッションレベルのシステム変数」の場合、Zone属性を無視し、この場合は通常デプロイメントのプライマリ/スタンバイ均等ルーティング（デフォルト）と同等です。
強い一貫性の読み取りステートメントについて、ログイン認証リクエストを含まず、かつ1および2のシナリオを除外した場合、次のポリシーに従ってルーティングされます：
同一リージョン、同一IDC内で、マージ状態にない読み書きゾーンにあるノード。
同一リージョン、異なるIDC内で、マージ状態にない読み書きゾーンにあるノード。
同一リージョン、同一IDC内で、マージ状態にある読み書きゾーンにあるノード。
同一リージョン、異なるIDC内で、マージ状態にある読み書きゾーンにあるノード。
異なるリージョン内で、マージ状態にない読み書きゾーンにあるノード。
異なるリージョン内で、マージ状態にある読み書きゾーンにあるノード。