前回、SQLの速さはround tripの数だけでは決まらず、境界を越える回数と量の両方で決まる、という話を書きました。今日はその続きで、「では測ればいいのか」の話です。「推測するな、計測せよ」という教えがあります。私もよく言われました。正しい教えですが、そのまま振りかざすと、測らなくていいものを測り、測った結果を過信することになります。
測るまでもないものもある
前回の例で言えば、100万行をガバッと運んで手元で集計する形と、DBで集計して1万行だけ受け取る形の比較は、測るまでもありません。桁の差が構造で決まっていて、測定するまでもなく直感で分かるからです。
「推測するな、計測せよ」が禁じているのは当てずっぽう — 根拠なく「ここが遅いはず」と決めつけること — であって、経験に裏打ちされた直感ではありません。全件を運ぶ形と、集計してから運ぶ形とでは桁が違うはずだ、という見当は、当てずっぽうとは別物です。つまり順番はこうです: 直感で桁が違うと分かるなら、直感に従う。直感が割れたら、計測する。当てずっぽうだけはしない。
ちなみに、この教えの出典を調べ直したところ、Rob Pikeのプログラミング5規則 (1989) でした。原文を読むと面白いことに、計測を説く規則2には続きがあります — “even then don’t unless one part of the code overwhelms the rest”、計測した後でも、その箇所が圧倒的でない限りチューニングするな。つまり「測る場所を絞れ」という塩梅は、原典に最初から書いてあったのです。さらに言えば、原文で禁じられているのは “second guess” (根拠のない決めつけ) であって推測全般ではない、という指摘もあります。標語は旅をするうちに、少し尖ってしまったようです。
なんでも実測、は計測の形式主義です。測定にもコストがかかる以上、測るべきは境界コストが拮抗する際どいものだけ — 行数が数百しかない、キャッシュが効いている、DB側が逼迫している、そういう、直感が割れる場面でこそ、測る価値が出ます。
測るなら、公平に
この手の議論が空転する原因の多くは、比較条件の不公平さです。片方はキャッシュがのった状態で、片方は初回。片方は結果の全件を使い、片方は上位10件しか使わない。比べるなら、同じ結果集合を、同じキャッシュ状態で、実測で比べます。設計論の言い合いを続けるより、そこまで整えて1回測れば、議論は10分で終わります。
計測には賞味期限がある
そして、測った結果は永遠ではありません。行数はalgorithmではなくdataの性質なので、テストデータと本番データは違い、今日と1年後も違います。「本番でも、今日100行だから問題ない」という計測結果は、来年100万行になった日に失効します。計測は今日のデータの静止画であって、保証書ではない。
だから、構造で守れるところは構造で守ります。「起こりうることは起こる」と想定して、データが増えても壊れない形を最初から選ぶ — これがエンジニアとしての誠実な書き方だと思います。
直感こそが経験
まとめると、こうなります。どこまでは直感で決めるか。どこから計測するか。計測をいつまで信じるか。どこを「起こりうることは起こる」の構えで守るか。
このどれにも、マニュアルはありません。そして最近つくづく思うのですが、知識はAIがいくらでも持ってきてくれて、計測もAIが回してくれる時代に、この直感だけは、まだ経験と呼ばれるものの中身として残っていると思います。
(下書きはうちのAIが書き、文責は私にあります)