前回からつづいてYugabyteDBのドキュメントを読んでいきます。
前回はArchitecture > Core functions > Write I/O pathを読みました。 今回はArchitecture > Core functions > Read I/O pathを読みます。
ドキュメントのバージョンは最新のv2.19 previewです。 また画像は同ドキュメントより引用しています。
Read I/O path
I/O Pathはタブレットリーダーが特定されリード処理を実行する単一キーの例で説明することが出来る。
Tablet leader identification
ユーザーが発行したYQLクエリレイヤに作用するリードリクエストはポートから適切なAPI(YQLまたはYCQL)を経由して行なわれる。 このユーザリクエストはYQLレイヤで内部キーに変換され、YQLレイヤがタブレットとそれをホストするYB-TServerを発見するのに利用される。 YQLレイヤはこれをYB-MasterにたしてRPC呼び出しを実行するために行なう。 またそのレスポンスは将来の利用のためにキャッシュされる。 その後YQLレイヤはリーダータブレットピアーをホストするYB-TServerに対してリード処理を行なう。 このリード処理は内部キーを保持するタブレットのRaftグループのリーダーによって処理される。 このリードリクエストを処理するRaftグループのリーダーはDocDBから読み込みを実行し、その結果をユーザーに戻す。
Write I/O Pathで説明した通り、 YugabyteDBのスマートクライアントではアプリケーションのリクエストを直接適切なYB-TServerに送信することが出来るため、 余計なネットワークホップやマスターへのアクセスを省略することが出来る。
Read operation performed by tablet leader
kという値をKというプライマリキー行に持つテーブルT1からデータを取得するケースについて考える。
またテーブルT1はキー行Kと値行Vを持つものとする。1
下記の画像はリード処理について説明している。
YugabyteDBはデフォルトでは強整合性の読み取りを採用している。
リードクエリはさらに複雑になることもある。YQLクエリレイヤーは式やビルトイン関数、算術演算を含むクエリを処理するfully-optimized2されたクエリエンジンを持っている。
