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