個人開発で100万語規模の辞書サイトを作る。 この挑戦において最大の壁は、データの肥大化によるパフォーマンス低下だ。今回、Xserver（エックスサーバー）という共有サーバー環境で、この巨大なデータをいかに軽快に、かつ安全に動かすか、その設計がようやく固まった。
1. データベース設計：2層の物理分割
「一つのテーブルに100万行」は、インデックスのメンテナンスやバックアップの観点から現実的ではない。そこで、「1000個のコンテンツDB」と「1個の索引DB」に分けることにした。
- ポータルDB（索引）: 全100万語の「名前（Slug）」と「居場所（ID）」だけを管理。すべてのリクエストの玄関口。
- コンテンツDB（実体）: NDC（日本十進分類法）の3桁ごとにDBを物理分割（
db_ndc_000〜db_ndc_999）。
2. URL構造とデータ特定
URLはSEOと人間への分かりやすさを重視し、/大分類/中分類/小分類/スラッグ という形式に決定。
URL例:
/4/47/471/apple
- URLから「471（NDC3桁）」と「apple（スラッグ）」を抽出。
- ポータルDBで
appleを探し、固有IDsci471...を取得。- IDに基づき
db_ndc_471データベースへ接続。- その中の「簡易テーブル」と「1万字超の詳細テーブル」から中身をロード。
3. Xserver APIという突破口
共有サーバーでは通常、プログラムからのDB自動生成は制限されている。しかし、Xserver APIを利用すれば、この1000個超のDB作成を自動化できることが判明。これにより、手動で1000回DBを作るという絶望的な作業を回避しつつ、理想の物理分割を実現できる。
4. 快適な運用のための「三種の神器」
100万記事をサクサク動かすための技術的ポイントは以下の3点。
- オンデマンド接続: 必要な瞬間までコンテンツDBには繋がない。
- 長文の圧縮保存: 1万字超の解説文は
gzcompressで圧縮してDB容量を節約し、I/Oを高速化。 - 静的HTMLキャッシュ: 一度DBから生成したページはHTMLとして保存。2回目以降はDB接続すら発生させない「0.0秒台」のレスポンスを目指す。
今後の展望
設計図は完成した。次は、Xserver APIを叩いて1000個のDBを自動生成するスクリプトの実装に入る。 100万語が並ぶ景色を見るのが楽しみだ。
コメント