sukebei.nyaa.si
ダウンロードの伸びから人気をランキング化する基盤

0結論サマリ

先に要点だけ。詳細は各セクションへ。

1設計の中核 — 取得層 / 分析層の分離

生データは不変・追記専用で永久保存。意味づけ（分析）は後からいくらでも作り直す。

2サイト構造の網羅観測

実トラフィックを取得して検証した、URL設計・一覧・RSS・ソート・ページネーション・詳細。

2.1 URL設計 / クエリパラメータ

ベース https://sukebei.nyaa.si/。すべて GET パラメータで制御でき、RSSも同じパラメータを共有する。

2.2 データソースの比較 — RSS を主力に

2.3 一覧テーブルの列 / RSS フィールド

<item>
  <guid>…/view/4624184</guid>   // view ID
  <pubDate>… -0000</pubDate>
  <nyaa:downloads>0</…>     // 人気指標
  <nyaa:seeders>1</…>
  <nyaa:leechers>7</…>
  <nyaa:infoHash>9bb4…</…> // 安定ID
  <nyaa:categoryId>2_2</…>
  <nyaa:size>4.6 GiB</…>
</item>

2.4 ソート実測 / ページネーション / 詳細ページ

3「伸び」をどう算出するか

サイトは累計値の現在地しか教えてくれない。傾き（velocity）は自前のスナップショットから導く。

4Cloudflare 構成

SQLite = D1、生原本 = R2、定期実行 = Workers Cron Triggers。言語は TypeScript。

5クロール戦略 — 4カテゴリ × 2軸 × カテゴリ別設定

対象は Doujinshi / Games / Manga / Real Life の4カテゴリ。新着順とseeder順の2軸で観測し、巡回ページ数とクロール頻度をカテゴリごとに設定する。

5.1 2軸クロール（新着順 × seeder順）

5.2 カテゴリ別クロール設定（crawl_config）

頻度（interval）と巡回ページ数（pages）をカテゴリごとに設定。下表は実測アップロード速度から導いた初期値（編集可能）。新着の巡回深さは「直近の活動量 + 余裕」を満たすように設定している。

※ pages はサイト上限の100まで設定可。Real Lifeは100p≈8日でちょうど velocity 窓に一致。低頻度カテゴリは浅め＋低頻度に抑え、無駄な再取得を避ける。値はすべて運用中に変更可能（再デプロイ不要）。

5.3 スケジューラ（カテゴリ別頻度の実現）

単一の Cron Trigger を最小粒度（例: 1時間ごと）で起動。collector は crawl_config を読み、各カテゴリについて now ≥ 前回実行 + interval なら「実行対象」と判定し、対象カテゴリのみを各軸 p1..pages で巡回する。前回実行時刻は crawl_runs で管理。これにより1つのCronでカテゴリごとに異なる頻度を実現する。

5.4 Cloudflare上の実行方式

Durable Object + Alarm によるカーソル型クローラを推奨。DOが「現在の (カテゴリ, 軸, ページ)」を状態として持ち、1ページ取得 → 5秒後に自分を再起動 → 次へを繰り返す。crawl-delay 5sが自然に厳守され、単一Worker実行の時間上限に縛られず、中断しても途中再開できる。（代替: Cloudflare Queues に (cat,sort,page) ジョブを投入し consumer を max_concurrency:1 で消化。）

6D1 スキーマ（取得層）

observations は UPDATE/DELETE 禁止の追記専用。これが「生データ・不削除」の核。

-- 観測事実（追記専用・不変）
CREATE TABLE observations (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  observed_at INTEGER NOT NULL,   -- クロール時刻 (UTC epoch)
  nyaa_id     INTEGER NOT NULL,   -- /view/{ID}
  info_hash   TEXT    NOT NULL,   -- コンテンツ安定ID
  downloads   INTEGER NOT NULL,   -- Completed（人気指標の母数）
  seeders     INTEGER NOT NULL,
  leechers    INTEGER NOT NULL,
  comments    INTEGER NOT NULL,
  size_bytes  INTEGER,
  category_id TEXT,
  trusted     INTEGER,            -- 0/1
  remake      INTEGER,
  source      TEXT NOT NULL       -- 'newest' | 'seeders'（取得した軸）
);
CREATE INDEX idx_obs_nyaa_time ON observations(nyaa_id, observed_at);
CREATE INDEX idx_obs_time      ON observations(observed_at);

-- 寸法表（変化しにくいメタの最新値・UPSERT）
CREATE TABLE torrents (
  nyaa_id INTEGER PRIMARY KEY, info_hash TEXT, title TEXT,
  category_id TEXT, pub_date INTEGER, submitter TEXT,
  first_seen_at INTEGER, last_seen_at INTEGER
);

-- カテゴリ別クロール設定（運用中に編集可能・§5.2）
CREATE TABLE crawl_config (
  category_id  TEXT PRIMARY KEY,   -- '2_0','1_2','1_4','1_3'
  label        TEXT NOT NULL,
  pages        INTEGER NOT NULL,   -- 各軸で巡回する最大ページ数(1..100)
  interval_min INTEGER NOT NULL,   -- クロール間隔（分）
  sorts        TEXT NOT NULL DEFAULT 'newest,seeders',
  enabled      INTEGER NOT NULL DEFAULT 1
);
INSERT INTO crawl_config VALUES
 ('2_0','Real Life',100, 180,'newest,seeders',1),
 ('1_2','Doujinshi', 20, 360,'newest,seeders',1),
 ('1_4','Manga',     15, 720,'newest,seeders',1),
 ('1_3','Games',     10,1440,'newest,seeders',1);

-- 分析層の出力（いつでも DROP→再構築）
CREATE TABLE rankings (
  ranking_key TEXT, rank INTEGER, nyaa_id INTEGER, score REAL,
  computed_at INTEGER, window_from INTEGER, window_to INTEGER,
  PRIMARY KEY (ranking_key, computed_at, rank)
);

容量試算: 初期設定で ≈9万件/日 → 年間 約3,000万行（数GB）。D1単独でも数年もつが、原則どおり D1=ホット窓（直近14〜30日）／ R2=全履歴アーカイブ（Parquet・不削除）に階層化し、分析層は両方を読む。生HTML原本も raw/{cat}/{sort}/{YYYY}/{MM}/{DD}/{run_id}-p{page}.html で R2 保管。

7分析層 — 差し替え自由な「意味づけ」

取得層には触れず observations から派生計算。定義変更＝クエリ差し替えのみ、過去遡及も可能。

• 重複排除: info_hash で torrent単位。タイトル正規化で content単位（後付け可）。
• 「昨日の一覧」: observed_at / pub_date に UTC/JST境界を当てて抽出（生データに日付があるので自由に切れる）。
• 定義を変えても生データは無傷なので、過去に遡って再計算できる。

8未決事項 / 次アクション

確定事項: ストレージ=SQLite/D1 ・ インフラ=Cloudflare中心 ・ 対象=全カテゴリ ・ 取得間隔=3〜6時間。