Semua artikel dan komentar Hacker News 2006–2025 dicadangkan ke SQLite 22GB

 (hackerbook.dosaygo.com)
16 poin oleh GN⁺ 2025-12-31 | 1 komentar | Bagikan ke WhatsApp
  • Hacker Book adalah proyek yang melestarikan seluruh data Hacker News dalam format SQLite dari 2006 hingga 2025
  • Terdiri dari total 46.399.072 postingan, 1.637 shard, dan mencakup 19 tahun rekam jejak HN
  • Bukan aplikasi server-side, melainkan menggunakan SQLite yang dikompilasi ke WASM, lalu mengunduh hanya sebagian shard saat diperlukan untuk ditampilkan
  • Melalui antarmuka web, pengguna dapat menjelajahi postingan, pengguna, dan komentar, dengan UI yang mirip struktur real-time HN
  • Postingan teratas mencakup beragam topik seperti AI, open source, sejarah teknologi, dan isu sosial
  • Menjadi sumber yang memberi landasan analisis data jangka panjang komunitas teknologi internet bagi pengembang dan peneliti

Gambaran umum Hacker Book

  • Hacker Book adalah proyek yang menyediakan seluruh data Hacker News sebagai database SQLite
    • Data mencakup periode 9 Oktober 2006 hingga 28 Desember 2025
    • Terdiri dari total 46.399.072 item, 1.637 shard, dan berukuran 8,5GB (informasi di bagian bawah halaman)
  • Situs web dapat diakses di https://hackerbook.dosaygo.com/
    • Antarmukanya mirip Hacker News, menampilkan daftar postingan, poin, jumlah komentar, dan informasi penulis

Struktur data dan fitur penjelajahan

  • Setiap item terdiri dari judul postingan, domain sumber, poin, penulis, jumlah komentar, dan waktu penulisan
  • Dapat dijelajahi melalui halaman per pengguna (view=user&id=) dan halaman detail per postingan (view=item&id=)
  • Melalui tautan ‘More’, item tambahan dapat dimuat per halaman

Detail teknis

  • Data disediakan dalam format SQLite, sehingga dapat di-query dan dianalisis di lingkungan lokal
  • Dengan menggabungkan seluruh riwayat HN ke dalam satu database, peneliti maupun pengembang dapat melakukan analisis tren berdasarkan periode waktu
  • Mendukung pengelolaan data skala besar yang efisien melalui struktur data sharding

Makna proyek ini

  • Berperan sebagai arsip digital yang melestarikan 19 tahun pengetahuan komunitas Hacker News
  • Meningkatkan aksesibilitas data terbuka, sehingga bisa dimanfaatkan untuk riset sejarah teknologi atau analisis komunitas
  • Sesuai slogan “All the HN Belong to You”, seluruh rekam jejak komunitas dibuka agar dapat dijelajahi siapa saja

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-31
Komentar Hacker News

  • Inti proyek ini adalah semuanya berjalan sepenuhnya di dalam browser, bukan di server
    SQLite digunakan dengan cara dikompilasi ke WASM, dan alih-alih mengunduh seluruh DB 22GB, sistem ini hanya mengambil data per shard yang dibutuhkan halaman
    Di panel jaringan terlihat file seperti shard_1636.sqlite.gz, shard_1635.sqlite.gz dimuat secara berurutan
    Ini mengingatkan pada trik SQLite.js HTTPVFS sebelumnya, tetapi kali ini memakai file yang di-shard alih-alih range header
    Di antarmuka kueri SQL interaktif, kita bisa memilih sendiri shard mana yang akan dijalankan untuk kueri (total 1636)

    • VFS read-only seperti ini bisa diimplementasikan dengan sangat sederhana jika ada API yang tepat
      Contoh VFS yang saya buat ada di sini
      Untuk contoh yang memakai range request, lihat tautan ini
      Untuk mendukung SQLite DB yang dikompresi dengan Zstandard, cukup tambahkan library ini

    • Saya penasaran apakah ada contoh lain yang benar-benar mengimplementasikan ide berbasis HTTP range seperti ini pada level produksi. Terlihat sangat menjanjikan

    • Dukungan VFS ini benar-benar mengagumkan

  • Akan bagus kalau ini bisa diintegrasikan ke Kiwix
    Akhir-akhir ini saya memakai ponsel khusus offline, jadi saya melihat Wikipedia, Wiktionary, dan situs 100rabbits sepenuhnya secara offline

  • Saya penasaran seberapa kecil ukurannya kalau dikompresi lebih lanjut
    Komentar seperti “Saya tidak suka situs web ini karena membajak scrollbar” rasanya bisa dienkode hanya dengan beberapa bit

    • Tidak aneh juga kalau dibuat seperti kamus hardcoded milik Brotli (tautan terkait)
    • Kalau semua komentar saya dihapus, mungkin 5 bit saja sudah cukup

  • Saya mencoba menjalankan select * from items limit 10, tetapi hasilnya tidak kembali karena ia menelusuri shard satu per satu
    Sampai shard ke-60 lalu berhenti. Kalau hanya menentukan satu shard, hasilnya langsung keluar
    DuckDB tampaknya akan lebih cepat karena bisa membaca hanya bagian yang diperlukan dari file parquet melalui HTTP
    Error pada tabel users dan user_domains bisa diatasi dengan mengganti filter shard ke shard statistik pengguna

    • Aneh. Kalau ini VFS, seharusnya perilakunya tidak seperti ini. Mungkin ini memang bukan VFS

  • Seperti Single-page application(SPA), mungkin bisa muncul konsep Single-table application(STA)
    Jika tabel di-shard dengan beberapa kunci lalu disajikan sebagai file statis, data yang boleh dipublikasikan bisa didistribusikan seperti HTML statis

    • Pola arsitektur Baked Data mirip dengan ini
    • Maksudnya “single database”, bukan “single table”? Sulit membuat aplikasi tanpa relasi, tetapi Reddit pernah berjalan dengan satu tabel raksasa bernama “things”

  • Repositorinya hilang dengan 404
    Saya ingin setidaknya melihat struktur internalnya walaupun hanya sebagian datanya

    • Turunnya sangat cepat. Saya sedang mencari dataset HN terbaru, tetapi hampir tidak bisa menemukannya

  • Saya juga mendapat error 404
    Saya penasaran apakah trade-off antara store kolumnar seperti DuckDB dan SQLite sudah dipertimbangkan

    • Mungkin MS yang menurunkan repositorinya, repositori lain masih baik-baik saja
    • Saya langsung memilih SQLite. Saya tidak terlalu tahu apa itu DuckDB
    • DuckDB mungkin lebih baik dalam kompresi, tetapi mengingat universalitas SQLite, itu sudah cukup sebagai pilihan standar
    • SQLite bisa menangani DB dalam satu file, jadi berguna untuk pengarsipan

  • Ini kembali mengingatkan saya bahwa teks jauh lebih efisien daripada video
    Bahkan sulit membayangkan seberapa besar ukurannya jika jumlah pengetahuan yang sama dimasukkan ke dalam video

    • YouTube memasukkan kira-kira hanya 100 kata berguna ke dalam video 20 menit lalu memancing klik. Ketidakefisienannya sangat parah
    • Video 1080p60 pada 5Mbps setara dengan 120 ribu kata per detik. Berdasarkan kecepatan bicara rata-rata 150wpm, teks 50 ribu kali lebih efisien
      Jika 22GB teks diubah menjadi video, ukurannya sekitar 1PB(1000TB)
    • Sekarang video LLM juga bisa otomatis membuat video atau diagram berbasis teks
      Untuk video board game atau pemrograman, lebih baik cukup membaca ringkasan teksnya

  • Akan bagus kalau ini dibuat menjadi file .zim agar bisa dibuka di browser offline seperti Kiwix
    Saya kadang menetapkan “hari khusus offline” untuk merapikan hal-hal yang saya pelajari, dan memakai Kiwix untuk merujuk ke Wikipedia atau StackOverflow
    Pengenalan library Kiwix

    • Akan sangat bagus kalau konten seperti ini bisa langsung dijelajahi di aplikasi Kiwix

  • Saya juga pernah membuat sesuatu yang mirip
    Saya membuat tool Rust untuk mengimpor dump Project Arctic Shift dari Reddit ke SQLite
    Tanpa membuat indeks FTS5 dan mengimpor dengan --unsafe-mode tanpa WAL, seluruh komentar dan postingan bisa diimpor dalam sekitar 24 jam dan menghasilkan DB sekitar 10TB
    Fitur JSON SQLite keren, tetapi saya memilih mem-parsing sekali saat load lalu menormalkannya
    Membangun DB memang cepat, tetapi kalau langsung menjalankan VACUUM, kecepatan kueri menjadi jauh lebih cepat. Hanya saja VACUUM memakan waktu beberapa hari
    Pushshift Importer / tautan dump Arctic Shift

    • Dengan auto_vacuum milik SQLite, ruang bisa dipulihkan tanpa membangun ulang seluruh DB