บทความและคอมเมนต์ทั้งหมดของ Hacker News ช่วงปี 2006–2025 ที่สำรองไว้ใน SQLite ขนาด 22GB

 (hackerbook.dosaygo.com)
16 คะแนน โดย GN⁺ 2025-12-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Hacker Book เป็นโปรเจ็กต์ที่ เก็บรักษาข้อมูลทั้งหมดของ Hacker News ในรูปแบบ SQLite ตั้งแต่ปี 2006 ถึง 2025
  • ประกอบด้วย โพสต์ทั้งหมด 46,399,072 รายการ และ 1,637 ชาร์ด ครอบคลุม บันทึกของ HN ตลอด 19 ปี
  • ไม่ใช่แอปฝั่งเซิร์ฟเวอร์ แต่ใช้ SQLite ที่คอมไพล์เป็น WASM และเมื่อจำเป็นจะ ดาวน์โหลดเฉพาะบางชาร์ด มาแสดงผล
  • สามารถสำรวจ โพสต์ ผู้ใช้ และคอมเมนต์ ผ่านเว็บอินเทอร์เฟซได้ พร้อม UI ที่คล้ายกับโครงสร้างแบบเรียลไทม์ของ HN
  • โพสต์ยอดนิยมครอบคลุมหัวข้อหลากหลาย เช่น AI, โอเพนซอร์ส, ประวัติศาสตร์เทคโนโลยี, ประเด็นสังคม
  • เป็นแหล่งข้อมูลที่มอบ พื้นฐานสำหรับการวิเคราะห์ข้อมูลระยะยาวของชุมชนเทคโนโลยีบนอินเทอร์เน็ต ให้แก่นักพัฒนาและนักวิจัย

ภาพรวมของ Hacker Book

  • Hacker Book เป็นโปรเจ็กต์ที่ให้ข้อมูลทั้งหมดของ Hacker News ในรูปแบบ ฐานข้อมูล SQLite
    • ข้อมูลครอบคลุมช่วงเวลา 9 ตุลาคม 2006 ถึง 28 ธันวาคม 2025
    • ประกอบด้วย รายการทั้งหมด 46,399,072 รายการ (items), 1,637 ชาร์ด (shards), และมี ขนาด 8.5GB (ข้อมูลที่ส่วนล่างของหน้า)
  • สามารถเข้าถึงเว็บไซต์ได้ที่ https://hackerbook.dosaygo.com/
    • อินเทอร์เฟซมีลักษณะคล้าย Hacker News โดยแสดง รายการโพสต์, คะแนน, จำนวนคอมเมนต์, ข้อมูลผู้เขียน

โครงสร้างข้อมูลและความสามารถในการสำรวจ

  • แต่ละรายการประกอบด้วย ชื่อโพสต์, โดเมนต้นทาง, คะแนน, ผู้เขียน, จำนวนคอมเมนต์, เวลาที่เขียน
  • สามารถสำรวจผ่าน หน้าต่อผู้ใช้ (view=user&id=) และ หน้ารายละเอียดต่อโพสต์ (view=item&id=)
  • สามารถโหลดรายการเพิ่มเติมเป็นรายหน้าได้ผ่านลิงก์ ‘More’

รายละเอียดทางเทคนิค

  • ข้อมูลถูกจัดให้อยู่ใน ฟอร์แมต SQLite ทำให้สามารถ คิวรีและวิเคราะห์ ได้ในสภาพแวดล้อมโลคัล
  • มีการ รวมบันทึกทั้งหมดของ HN ไว้ในฐานข้อมูลเดียว เพื่อให้นักวิจัยและนักพัฒนาสามารถ วิเคราะห์เทรนด์ตามช่วงเวลา ได้
  • รองรับการจัดการข้อมูลขนาดใหญ่ได้อย่างมีประสิทธิภาพผ่านโครงสร้าง การแบ่งข้อมูลเป็นชาร์ด (sharding)

ความสำคัญของโปรเจ็กต์

  • ทำหน้าที่เป็นดิจิทัลอาร์ไคฟ์ที่ เก็บรักษาความรู้ของชุมชน Hacker News ที่สะสมมาตลอด 19 ปี
  • เพิ่ม การเข้าถึงข้อมูลแบบเปิด ทำให้สามารถนำไปใช้ในการศึกษาประวัติศาสตร์เทคโนโลยีหรือวิเคราะห์ชุมชนได้
  • ตามสโลแกน “All the HN Belong to You” จึงเปิดให้ทุกคนสามารถสำรวจบันทึกทั้งหมดของชุมชนได้

บทความที่เกี่ยวข้อง

  • HN Arcade
    2 คะแนน · 1 ความคิดเห็น · 2026-01-30

1 ความคิดเห็น

 
GN⁺ 2025-12-31
ความเห็นจาก Hacker News

  • แก่นของโปรเจ็กต์นี้คือมัน รันทั้งหมดในเบราว์เซอร์ ไม่ใช่บนเซิร์ฟเวอร์
    ใช้ SQLite ที่คอมไพล์เป็น WASM และแทนที่จะดาวน์โหลด DB ทั้งก้อน 22GB ก็จะดึงมาเฉพาะ ข้อมูลระดับ shard ที่จำเป็นต่อหน้าเท่านั้น
    ผมยืนยันได้จากใน network panel ว่ามีการโหลดไฟล์อย่าง shard_1636.sqlite.gz, shard_1635.sqlite.gz ตามลำดับ
    มันทำให้นึกถึง ทริก SQLite.js HTTPVFS แบบเก่า แต่คราวนี้ใช้ ไฟล์แบบ sharded แทน range header
    ใน อินเทอร์เฟซสำหรับรัน SQL query แบบโต้ตอบ คุณสามารถเลือกได้เองว่าจะรัน query กับ shard ไหน (ทั้งหมด 1636 shard)

    • VFS แบบ read-only ลักษณะนี้ทำได้ค่อนข้างง่ายมากถ้ามี API ที่เหมาะสม
      ตัวอย่าง VFS ที่ผมทำไว้ดูได้ ที่นี่
      ตัวอย่างที่ใช้ range request ดูได้จากลิงก์นี้
      ถ้าจะรองรับ SQLite DB ที่บีบอัดด้วย Zstandard ก็แค่เพิ่ม ไลบรารีนี้ เข้าไปตัวเดียวพอ

    • ผมสงสัยว่ามีตัวอย่างการเอาไอเดียแบบ HTTP range based นี้ไปทำถึงระดับ production จริง ๆ อีกไหม ดูมีศักยภาพมาก

    • การรองรับ VFS น่าทึ่งจริง ๆ

  • ถ้ารวมสิ่งนี้เข้ากับ Kiwix ได้ก็น่าจะดีมาก
    ช่วงนี้ผมใช้ โทรศัพท์แบบออฟไลน์ล้วน อยู่ เลยดูทั้ง Wikipedia, Wiktionary และเว็บไซต์ของ 100rabbits แบบออฟไลน์ทั้งหมด

  • สงสัยว่าถ้าบีบอัดเพิ่มจะเล็กลงได้อีกแค่ไหน
    คอมเมนต์อย่าง “เว็บไซต์นี้แย่งควบคุม scrollbar เลยไม่ชอบ” น่าจะเข้ารหัสได้ด้วยไม่กี่บิต

    • จะทำเหมือนพจนานุกรมแบบ hardcoded ของ Brotli ก็คงไม่แปลก (ลิงก์ที่เกี่ยวข้อง)
    • ถ้าตัดคอมเมนต์ของผมออกหมด 5 บิตก็น่าจะพอแล้ว

  • ผมลองรัน select * from items limit 10 แล้ว แต่ผลลัพธ์ไม่กลับมาเพราะมันไล่วน shard ทีละก้อน
    ไปถึงราว 60 shard แล้วก็หยุด ถ้าระบุแค่ shard เดียวผลจะออกมาทันที
    DuckDB น่าจะเร็วกว่าเพราะอ่านเฉพาะส่วนที่ต้องการของไฟล์ parquet ผ่าน HTTP ได้
    ข้อผิดพลาดของตาราง users กับ user_domains แก้ได้โดยเปลี่ยน shard filter ไปเป็น user stats shard

    • แปลกนะ ถ้าเป็น VFS จริงไม่ควรทำงานแบบนี้ อาจจะไม่ใช่ VFS ก็ได้

  • เหมือนกับ Single-page application (SPA) เราอาจได้แนวคิด Single-table application (STA) ก็ได้
    ถ้า shard ตารางด้วยคีย์หลายแบบแล้วเสิร์ฟเป็นไฟล์ static ข้อมูลที่เปิดเผยได้ก็อาจแจกจ่ายได้เหมือน HTML แบบ static

    • สถาปัตยกรรมแพตเทิร์น Baked Data ก็คล้ายกับแนวคิดนี้
    • หรือจริง ๆ หมายถึง “single database” มากกว่า? แอปที่ไม่มีความสัมพันธ์กันทำยาก แต่ Reddit ก็เคยรันบนตารางเดี่ยวขนาดมหึมาที่ชื่อ “things”

  • รีโพซิทอรีกลายเป็น 404 หายไปแล้ว
    เสียดาย อยากดูโครงสร้างภายในบ้างแม้จะมีแค่บางส่วนของข้อมูลก็ตาม

    • หายไปเร็วมากจริง ๆ ช่วงนี้ผมหาชุดข้อมูล HN ล่าสุดอยู่ แต่แทบหาไม่ได้เลย

  • ของผมก็ขึ้น 404 เหมือนกัน
    สงสัยว่าเขาได้พิจารณา trade-off ระหว่างคอลัมน์สโตร์แบบ DuckDB กับ SQLite บ้างไหม

    • เป็นไปได้ว่า MS อาจถอดรีโพซิทอรีลง แต่รีโพอื่นยังปกติดี
    • ผมเลือกไปทาง SQLite ตรง ๆ เลย ไม่ค่อยรู้จัก DuckDB เท่าไร
    • DuckDB อาจบีบอัดได้ดีกว่า แต่ถ้าคิดถึง ความแพร่หลาย ของ SQLite การเลือกมันเป็นมาตรฐานก็สมเหตุสมผลแล้ว
    • SQLite จัดการ DB ได้ในไฟล์เดียว เลยเหมาะกับงาน จัดเก็บถาวร

  • ยิ่งทำให้รู้สึกว่า ข้อความมีประสิทธิภาพกว่าวิดีโอมาก
    ถ้าจะบรรจุความรู้ปริมาณเท่ากันเป็นวิดีโอ ขนาดจะใหญ่แค่ไหนนึกไม่ออกเลย

    • YouTube ใส่คำที่มีประโยชน์ในวิดีโอ 20 นาทีแค่ราว 100 คำแล้วยังเน้นล่อให้คลิกอีก ไร้ประสิทธิภาพ มาก
    • วิดีโอ 1080p60 อยู่ที่ 5Mbps หรือเทียบเท่าประมาณ 120,000 คำต่อวินาที ถ้าคิดจากความเร็วพูดเฉลี่ย 150wpm ข้อความจะ มีประสิทธิภาพกว่าถึง 50,000 เท่า
      ถ้าเอาข้อความ 22GB ไปแปลงเป็นวิดีโอจะได้ประมาณ 1PB (1000TB)
    • เดี๋ยวนี้มี video LLM ที่สร้างวิดีโอหรือไดอะแกรมจากข้อความอัตโนมัติได้แล้ว
      แต่วิดีโอเกี่ยวกับบอร์ดเกมหรือการเขียนโปรแกรม แค่อ่านสรุปแบบข้อความก็ดีกว่า

  • อยากให้ทำสิ่งนี้เป็นไฟล์ .zim เพื่อเปิดในเบราว์เซอร์ออฟไลน์อย่าง Kiwix ได้
    ผมชอบกำหนด “วันออฟไลน์ล้วน” เป็นบางครั้งเพื่อจัดระเบียบสิ่งที่เรียนรู้ และใช้ Kiwix อ้างอิง Wikipedia หรือ StackOverflow
    แนะนำไลบรารี Kiwix

    • ถ้าเนื้อหาแบบนี้เปิดสำรวจได้ตรงจากแอป Kiwix จะดีมากจริง ๆ

  • ผมก็เคยทำอะไรคล้าย ๆ กัน
    ผมทำเครื่องมือด้วย Rust สำหรับนำเข้า Project Arctic Shift dump ของ Reddit ลง SQLite
    ถ้าไม่สร้างดัชนี FTS5 และนำเข้าแบบไม่มี WAL ด้วย --unsafe-mode จะนำเข้าคอมเมนต์และโพสต์ทั้งหมดได้ในเวลาราว 24 ชั่วโมง และได้ DB ขนาดประมาณ 10TB
    ความสามารถ JSON ของ SQLite นั้นยอดเยี่ยม แต่ผมเลือก parse แค่ครั้งเดียวตอนโหลดแล้ว normalize ไปเลย
    การ build DB เร็วก็จริง แต่ถ้ารัน VACUUM ทันที ความเร็ว query จะดีขึ้นมาก แม้ว่า VACUUM จะใช้เวลาหลายวัน
    Pushshift Importer / ลิงก์ dump ของ Arctic Shift

    • ใช้ auto_vacuum ของ SQLite ก็คืนพื้นที่ได้โดยไม่ต้อง build DB ใหม่ทั้งก้อน