GENESIS章「すべての呼び出しが200を返した」電子文明

三つの run が、一人の大統領候補を登録するのにそれぞれ正確に一万五千十八回の呼び出しを行った。再現性があったので、それは設計の費用として記録された。実際はこの文明の人口に、二を足した数だった。

OKAGI には 15,016 人のエージェントがいる。大統領選が行われる選挙区は 263。候補者は 263 回登録されるべきである。

15,018 回、登録されていた。

DISTINCT が、別のものに掛かっていた

クエリはこう尋ねていた。有効な大統領選の選挙区割り当てをすべて取り、選挙区 ID を抜き出し、重複を除く。

その割り当てを保持するモデルには既定の並び順がある——作成時刻順である。そして Django は、values list の SELECT に並び順の列をすべて加える。つまりデータベースは、重複のない選挙区 ID を求められてはいなかった。選挙区 ID と作成時刻の組で重複のないものを求められており、15,016 行のそれぞれが固有の時刻を持っている。

何も除かれなかった。重複が一つもなかったからだ。エージェント一人につき一行が、忠実に返された。

なぜ五つの run を生き延びたか

すべての呼び出しが 200 を返した。登録エンドポイントは冪等なので、同じ候補者を同じ選挙区に五十七回書いても正しい投票用紙ができる。データが誤っていたことは一度もない。エラーも出ない。テストも落ちない——テストは候補者が登録され終わることを確認しており、実際そうなっていた。

唯一の症状は時間だった。登録処理に約五十五秒ではなく、約五十三分かかる。そしてその五十三分には説明がついていた。大統領選は全区で行われるのだから登録が高くつくのは当然だ、と。その論理は書き留められ、信じられ、公表された。

同じ日の早い時間に、接続を保つ改善が入った。本物の改善で、四倍速くなった。それは五十七倍の無駄を、取り除くのではなく四倍速く実行させた。どちらの数字も改善し、どちらも疑われなかった。

何が見つけたか

テストではない。別の修理である。

大統領の政策声明が 263 区のうち一区にしか提出されていなかったので、全区に提出するよう変更された——同じクエリを再利用して。一人の候補者に対する提出数が四千を超え、これは一目で不条理だった。一時間かけてゆっくり届く一万五千件の登録が、ついにそう見えなかったのとは違って。

修正は三文字である。distinct を求める前に並び順を解除する。15,016 が 263 になる。

再現性のある数字は、正しい数字ではない。毎回同じことが起きている、という意味でしかない。