BT9G LABS / DHT 詳解 #17

数十億InfoHashをどうDedupするか：無駄なMetadata作業を防ぐ多層設計

Exact key、Bloom filter、hot cache、durable state を組み合わせた大規模 DHT ingestion の dedup 設計。

BT9G Labs公開日 2026-09-162 分で読めます

BT9G Labs / DHT Deep Dive #17. Deduplication は単なる DB の EXISTS ではなく、crawler の長期コストを決める独立サブシステムです。

数十億InfoHashをどうDedupするか：無駄なMetadata作業を防ぐ多層設計

クイックサマリー

テーマ: 数十億InfoHashをどうDedupするか：無駄なMetadata作業を防ぐ多層設計
主要キーワード: InfoHash deduplication, Bloom filter, Redis, large-scale DHT, Metadata scheduler
対象読者: バックエンドエンジニア、プロトコル研究者、検索エンジニア、BitTorrent 実装者
目的: DHT と BitTorrent の仕組みを、実際のクローラ・インデックス・検索基盤の設計判断に使える精度で説明すること。

システム構成

Raw EventsHot Bloom / CacheExact StoreSchedulerMetadata

Raw Events → Hot Bloom / Cache; Hot Bloom / Cache → Exact Store; Exact Store → Scheduler; Scheduler → Metadata

多層Dedupが必要な理由

人気 InfoHash は短時間に何度も観測されます。毎 event で primary DB を引き、新しい Metadata job を作ると、重複仕事だけで資源を失います。process-local recent set、Bloom filter、hot cache、durable exact store の順で重い処理を減らす構成が実用的です。

最終的な source of truth は正確な store に残します。

Bloom filterは真実ではない

Bloom filter は小さなメモリで高速 lookup ができ false negative はありませんが false positive はあります。そのため「おそらく既知」を判定する前段フィルタには向きますが、新規 hash を永久に捨てる最終判定には使えません。

必要に応じて exact store へ確認します。

ExistenceとScheduling Stateを分ける

「以前見たことがある」と「今 Metadata を取り直す必要がない」は別です。durable record には first_seen、last_seen、metadata_state、retry_state、activity を分けて持ちます。

数十億キーを想定するなら hash prefix などの partitioning、primary-key exact lookup、index size、backup strategy を早めに設計します。

実装スケッチ

CREATE TABLE infohash_state (
  hash VARBINARY(32) NOT NULL,
  hash_type TINYINT NOT NULL,
  first_seen DATETIME NOT NULL,
  last_seen DATETIME NOT NULL,
  seen_count BIGINT NOT NULL,
  metadata_status TINYINT NOT NULL,
  next_retry DATETIME NULL,
  PRIMARY KEY(hash_type, hash)
);

BT9G Labs エンジニアリングノート

BT9G のようなインデックス基盤では、イベント件数そのものより、コンテンツ ID、短命なネットワーク観測、取得状態、検索用ドキュメントを分離することが重要です。DHT や Peer から得た値には取得元と時刻を持たせ、discovery、接続、handshake、拡張対応、Metadata 取得、検証、保存、検索反映を段階別に計測すると、実際のボトルネックを特定しやすくなります。

よくある誤解

raw event ごとに primary DB を読む。
Bloom filter を絶対的 source of truth にする。
seen だけで Metadata/retry state を持たない。
十億件になってから partitioning を考える。

参考資料

次の記事: 失敗したInfoHashを残すべき理由：長期Retry Scheduler設計 →

本記事は公開 BitTorrent プロトコルの挙動を技術・研究目的で解説するものであり、観測されたすべての Swarm が利用可能、正当、または再配布を許可されていることを意味しません。