BT9G LABS / DHT Deep Dive #19

Membangun BitTorrent Search Index: Dari DHT ke Metadata hingga Elasticsearch

Arsitektur pipeline search yang memisahkan discovery, validasi metadata, canonical storage, enrichment, dan Elasticsearch agar indexing aman dan dapat direbuild.

BT9G LabsTerbit 3 menit baca

BT9G Labs / DHT Deep Dive #19. Search index seharusnya menjadi turunan dari metadata terverifikasi, bukan tempat pertama data mentah DHT disimpan.

Membangun BitTorrent Search Index: Dari DHT ke Metadata hingga Elasticsearch

Ringkasan cepat

  • Topik: Membangun BitTorrent Search Index: Dari DHT ke Metadata hingga Elasticsearch
  • Kata kunci utama: BitTorrent search engine, DHT, metadata pipeline, Elasticsearch, search indexing
  • Untuk pembaca: engineer backend, peneliti protokol, search engineer, dan pengembang implementasi BitTorrent
  • Tujuan: Menjelaskan protokol dan desain sistem dengan cukup presisi agar dapat diterapkan pada pipeline discovery, metadata, indexing, dan search di dunia nyata.

Gambaran sistem

Search index berada setelah validasi

Discovery event dan metadata dari Peer belum otomatis layak masuk Elasticsearch. Pipeline ideal melakukan dedup identitas, akuisisi metadata, hash verification, parsing, dan canonical persistence terlebih dahulu. Hanya record valid yang diterjemahkan menjadi dokumen pencarian.

Dengan batas ini, index dapat dihapus dan dibangun ulang tanpa kehilangan sumber kebenaran.

Canonical storage dan derived search storage

Database canonical menyimpan identitas, metadata terverifikasi, file list, ukuran, versi hash, serta status lifecycle. Elasticsearch menyimpan bentuk yang dioptimalkan untuk full-text, filter, aggregation, autocomplete, dan ranking.

Jangan membuat Elasticsearch satu-satunya tempat menyimpan raw metadata. Mapping dapat berubah dan reindex adalah operasi normal.

Enrichment tanpa merusak identitas

Language detection, tokenization, kategori, tags, normalized title, media hints, dan safe-display fields dapat ditambahkan sebagai enrichment. Field ini adalah derivasi dan dapat dihitung ulang ketika model atau aturan berubah.

Jangan mencampurkan hasil enrichment ke bytes yang digunakan untuk verifikasi InfoHash. Identitas protokol harus tetap immutable.

Sinyal ranking

Ranking dapat menggabungkan text relevance, freshness metadata, last_seen, recent activity, file completeness, source diversity, serta kualitas dokumen. Setiap sinyal perlu normalisasi agar event volume dari crawler tertentu tidak mendominasi.

Simpan feature secara terpisah bila memungkinkan sehingga formula ranking dapat dieksperimenkan tanpa mengubah canonical data.

Sketsa implementasi

{
  "infohash": "...",
  "title": "Example Release",
  "total_size": 734003200,
  "file_count": 12,
  "extensions": ["mkv", "srt"],
  "first_seen": "...",
  "last_seen": "...",
  "metadata_verified": true,
  "activity_score": 0.73
}

Catatan engineering BT9G Labs

Untuk sistem indeks seperti BT9G, metrik yang paling berguna bukan sekadar jumlah paket atau jumlah InfoHash yang terlihat. Pisahkan identitas konten, observasi jaringan, status akuisisi, metadata terverifikasi, serta dokumen pencarian menjadi lapisan data yang berbeda. Simpan sumber dan waktu observasi untuk data yang datang dari DHT atau Peer. Dengan begitu, bottleneck dapat dilacak dari tahap discovery, koneksi, handshake, negosiasi extension, pengambilan metadata, validasi, penyimpanan, hingga indexing.

Kesalahan umum

  • Mengindeks metadata sebelum verifikasi hash.
  • Menjadikan Elasticsearch sebagai satu-satunya source of truth.
  • Mengubah data identitas saat melakukan enrichment.
  • Membiarkan satu metrik activity mentah mendominasi ranking.

Artikel BT9G Labs terkait

Referensi

Artikel berikutnya: Bagaimana BT9G Dapat Mengindeks Metadata BitTorrent pada Skala Besar: Arsitektur Referensi DHT →

Artikel ini menjelaskan protokol BitTorrent publik dan pola engineering. Observasi terhadap sebuah Swarm tidak berarti kontennya tersedia, valid, atau diizinkan untuk didistribusikan.