なぜ画像を表に入れないのか
前回、データベースは表計算のような見た目だと述べた。名前と日付と数字を一行ずつ積むのに向いた構造である。
写真や動画はそのマスに入れる物ではない。概念としては入れられる。ただ効率が出ない。
理由は取り出し方にある。一覧画面を一つ描くのに二十行を照会するとして、各行に画像が丸ごと入っていれば、画面に出もしない画像まで全部引きずり出される。データベースはそういう重い塊が頻繁に行き来するために作られた道具ではない。
だから分けておく。ファイル本体はファイル置き場に置き、データベースにはそのファイルがどこにあるかの経路だけを書く。
posts テーブル
─────────────────────────────────────────────
id title cover_path
1 最初の記事 /uploads/2026/09/cover-1.webp
2 二つ目の記事 /uploads/2026/09/cover-2.webp
① 画面が posts を照会して cover_path を読む
② その経路でストレージにファイルを別途要求するストレージと二度目の要求
ファイルを置く場所をストレージという。サービスが小さければサーバー内のフォルダでもよく、大きくなればファイル専用のサービスを別に使う。
この構造で画面は要求を二度する。まずバックエンドに値を尋ねて経路を受け取り、次にその経路でファイルを別途要求する。ブラウザは画像のアドレスに出会えば自分で二度目の要求を送るので、人が気にすることではない。
値を返す側とファイルを返す側を分けておけば、サーバーを別に置くこともできる。値は値でよく応答するサーバーが担い、ファイルはファイルでよく送り出すサーバーが担う。性質の違う仕事なので、分けたほうがそれぞれ得意になる。
CDN — 距離と頻度を扱う層
ここにもう一つ付く。距離の問題だ。
アメリカにあるサーバーに画像を置いてあり、見る人が韓国にいるとしよう。要求は海底ケーブルを通って太平洋を渡る。一行の文字ならともかく、画像や動画のような大きな塊が毎回その距離を往復すれば遅い。
だから写しをあらかじめ配っておく。よく使われるファイルを世界各地の拠点に複製し、要求が来ればその人に最も近い拠点が送り出す。この網を CDN という。コンテンツ配信ネットワークの略である。
頻度も扱う。サイトのロゴは訪問者ごとに取りに来るが、人気のない記事の画像はほとんど取りに来られない。前者は常に近くに備えておく価値があり、後者は要求が実際に来てから元から取るほうがよい。その判断を代わりにするのがこの層の仕事だ。
| 層 | 何を置くか | 何を判断するか |
|---|---|---|
| データベース | 値とファイルの経路 | どの値がどうつながるか |
| ストレージ | ファイルの原本 | どこに安全に保管するか |
| CDN | よく使うファイルの写し | 誰にどこから送り出すか |
サイトが遅いという訴えの多くはここから始まる
遅いという報告を受けるとコードから開きたくなる。だが実際にはこの層であることが多い。
確かめることは決まっている。画像が原寸のまま出ていないか。画面で横四百ピクセルに見える場所に四千ピクセルのファイルを送れば、その分の時間はそのまま捨てられる。
形式も見る。同じ絵でもウェブ向けに作られた形式のほうがはるかに軽い。そして距離とキャッシュを見る。写しが近い場所から出ているか、一度受け取ったファイルをブラウザが再び取らずに済む設定になっているかだ。
ブラウザの開発者ツールのネットワークタブを開けば、どのファイルにどれだけかかったかがそのまま見える。コードに手を入れる前にここを見れば、たいてい答えが出る。次回は最後に、この全体を別のコンピュータへ移す話をする。