同じ20万件を、名前つきの文字なら15.8MB、形を決めた形式なら2.3MBで表せます。
読み取りは50.9msが0.4msです。大きさより時間のほうが大きく変わります。
何を呼べるかを定義として書きます。呼ぶ側と受ける側の両方が、その定義から作られます。
gRPCの出発点は、定義です。公式は多くの遠隔手続き呼び出しの仕組みと同じく、gRPCは、遠隔から呼べる手続きを引数と戻り値の型とともに指定する、サービスを定義するという考えを土台にしていると述べています。
定義から両側が作られます。呼ぶ側は手元の対象のように呼べる形になります。
公式もgRPCでは、呼ぶ側のアプリケーションが、別の機械にある受け側のアプリケーションの手続きを、手元の対象であるかのように直接呼べると説明しています。
4番目が、次の節で測る部分です。公式は既定では、gRPCは構造を持つデータを直列化するための成熟した仕組みを使うと述べています。
同時に、他のデータ形式と一緒に使うこともできるとも書かれています。既定が固定ではありません。
定義を置く場所が要ります。呼ぶ側と受ける側が同じ定義を見ていることが前提だからです。
そのため、定義そのものを版で管理することになります。片方だけが新しい定義を持つ状態が、あとで測る問題につながります。
As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types.原文gRPC 公式ドキュメント「Introduction to gRPC」 この内容の有効期限2027-02-18
形を先に決めているので、項目名を毎回送りません。効くのは大きさより読み取りの時間です。
gRPCが既定で使う詰め方は、形を先に決める方式です。公式は既定では、gRPCはProtocol Buffersを使う。ただし、JSONのような他のデータ形式とともに使うこともできると述べています。
どれだけ違うのかを、20万件を実際に符号化して測りました。
注文の記録 200,000件。1件は5項目（番号・分類・金額・日・個数） 詰め方 そのまま 縮めたあと そのままの比 名前つきの文字で書く 15.8MB 1.9MB 6.88倍 形を決めて行ごとに並べる 2.3MB 1.4MB 1.00倍 形を決めて列ごとに並べる 2.3MB 1.4MB 1.00倍 金額の合計を出すのにかかる時間 名前つきの文字 50.9ms 行ごとに並べたもの 0.4ms（142倍速い） 列ごとに並べたもの 0.4ms（141倍速い）
大きさは6.88分の1、読み取りの時間は142分の1です。
時間のほうが20倍も大きく変わります。減っているのは量ではなく、1件あたりの解析の作業です。
縮めたあとの列も見てください。1.9MBと1.4MBで、1.36倍まで差が縮みます。
つまり通信の量だけを見ると、差は思ったより小さいことになります。効いているのは受け取ったあとの処理です。
詰め方そのものの比較はAvroの記事で扱いました。同じ形式の族に属する考え方です。
量は6.88倍、時間は142倍。効き方が違う。
By default, gRPC uses Protocol Buffers, Google's mature open source mechanism for serializing structured data (although it can be used with other data formats such as JSON).原文gRPC 公式ドキュメント「Introduction to gRPC」 この内容の有効期限2027-02-18
同じ形で呼べることが利点であり、落とし穴でもあります。往復は隠れたままです。
gRPCでは、呼ぶ側に代理が用意されます。公式は呼ぶ側では、受け側と同じ手続きを提供する代理を持つと述べています。
同じ手続きに見えるので、繰り返し呼ぶ書き方が自然に出てきます。1件ずつ呼ぶ形です。
1往復 0.8ms、1行を返す手間 0.002ms として計算する 一覧の件数を変えて、1件ずつ引く場合とまとめて引く場合を比べる 一覧の件数 1件ずつ（往復） 1件ずつ（時間） まとめて（往復） まとめて（時間） 比 10件 11回 8.8ms 2回 1.6ms 5.4倍 50件 51回 40.9ms 2回 1.7ms 24.1倍 200件 201回 161.2ms 2回 2.0ms 80.6倍 1000件 1001回 802.8ms 2回 3.6ms 223.0倍
1000件では223.0倍です。返す量は同じで、差は往復だけから来ています。
前の節で測った詰め方の効き目は142倍でした。呼び方の設計のほうが、それを上回ることがあります。
もう1つの注意は、定義の変え方です。形を先に決める方式では、足す位置に制約が出ます。
形を先に決めておく方式で、あとから項目を変えた場合 古い読み手が新しい記録を読めるかを整理する 変え方 古い読み手 理由 末尾に項目を足す 読める 知らない項目を飛ばせる形なら 途中に項目を足す 読めない 位置で読む形では、以降がすべてずれる 項目名を変える 読めない 名前で引く形では見つからなくなる 項目を消す 読めない 必須として読んでいれば失敗する 既定値つきで足す 読める 古い記録にはその値が入っているものとして扱える
読めるのは2つだけです。呼ぶ側と受ける側を同時に入れ替えられない以上、ここは規則にしておく必要があります。
面の変更が呼ぶ側を壊す話はAPI設計の記事でも扱いました。考え方は同じです。
実在のgRPCとProtocol Buffersの実装は使わず、形を決めて値だけを並べる方式をその場で実装して測っています。実際の実装は可変長の整数などを使うため、大きさはここより小さくなります。往復の0.8msという値も置いたもので、同じ機械の中ならもっと短くなります。ここで見せているのは、詰め方の効きが大きさより読み取りの時間に出ること、呼ぶ回数の設計がそれを上回りうることの2つです。
On the client side, the client has a stub (referred to as just a client in some languages) that provides the same methods as the server.原文gRPC 公式ドキュメント「Introduction to gRPC」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る