# 22GB SQLite에 백업한 해커뉴스의 2006–2025 전체 기사와 댓글

> Clean Markdown view of GeekNews topic #25461. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25461](https://news.hada.io/topic?id=25461)
- GeekNews Markdown: [https://news.hada.io/topic/25461.md](https://news.hada.io/topic/25461.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-31T10:32:52+09:00
- Updated: 2025-12-31T10:32:52+09:00
- Original source: [hackerbook.dosaygo.com](https://hackerbook.dosaygo.com)
- Points: 16
- Comments: 1

## Summary

2006년부터 2025년까지의 **Hacker News 전체 기록을 SQLite 데이터베이스로 보존**한 아카이브 프로젝트입니다. 특이하게도 서버에 기능을 특별히 만들지않고, 1,600여 개의 샤드로 분할된 약 22GB 규모의 데이터를 **WASM 기반 SQLite**로 구성해, 브라우저에서 직접 탐색할 수 있습니다.

## Topic Body

- **Hacker Book**은 2006년부터 2025년까지의 **Hacker News 전체 데이터를 SQLite 형식으로 보존**한 프로젝트  
- 총 **46,399,072개의 게시물**, **1,637개의 샤드**로 구성되어 있으며, **HN의 19년 기록**을 포함  
- 서버사이드 앱이 아니라 **WASM으로 컴파일된 SQLite**를 이용하며, 필요시 **일부만 샤드로 내려받아**서 보여주는 형태   
- 웹 인터페이스를 통해 **게시물, 사용자, 댓글**을 탐색할 수 있고, **HN의 실시간 구조와 유사한 UI**를 제공  
- 상위 게시물에는 **AI, 오픈소스, 기술사, 사회 이슈** 등 다양한 주제가 포함되어 있음  
- 개발자와 연구자에게 **인터넷 기술 커뮤니티의 장기적 데이터 분석 기반**을 제공하는 자료  
  
---  
### Hacker Book 개요  
- **Hacker Book**은 Hacker News의 전체 데이터를 **SQLite 데이터베이스**로 제공하는 프로젝트  
  - 데이터는 **2006년 10월 9일부터 2025년 12월 28일까지**의 기간을 포함  
  - 총 **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”** 라는 슬로건처럼, 커뮤니티 전체의 기록을 누구나 탐색할 수 있도록 공개

## Comments



### Comment 48503

- Author: neo
- Created: 2025-12-31T10:32:52+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46435308) 
- 이 프로젝트의 핵심은 서버가 아닌 **브라우저 내에서 전부 실행**된다는 점임  
  SQLite를 WASM으로 컴파일해 사용하고, 전체 22GB DB를 받는 대신 페이지에 필요한 **shard 단위 데이터**만 가져오는 방식임  
  네트워크 패널에서 `shard_1636.sqlite.gz`, `shard_1635.sqlite.gz` 같은 파일이 순차적으로 로드되는 걸 확인했음  
  예전의 [SQLite.js HTTPVFS 트릭](https://github.com/phiresky/sql.js-httpvfs)을 떠올리게 하지만, 이번엔 range header 대신 **sharded 파일**을 사용함  
  [인터랙티브 SQL 쿼리 인터페이스](https://hackerbook.dosaygo.com/?view=query)에서는 어떤 shard에 쿼리를 실행할지 직접 선택할 수 있음 (총 1636개)

  - 이런 **read-only VFS**는 적절한 API만 있으면 아주 단순하게 구현 가능함  
    내가 만든 VFS 예시는 [여기](https://github.com/ncruces/go-sqlite3/blob/main/vfs/readervfs/reader.go)에 있음  
    range request를 사용하는 예시는 [이 링크](https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/readervfs#example-package-Http) 참고  
    Zstandard로 압축된 SQLite DB를 지원하려면 [이 라이브러리](https://pkg.go.dev/github.com/SaveTheRbtz/zstd-seekable-format-go/pkg) 하나만 추가하면 됨

  - 이런 **HTTP range 기반** 아이디어를 실제 프로덕션 수준으로 구현한 사례가 더 있는지 궁금함. 가능성이 커 보임

  - VFS 지원이 정말 놀라움

- 이걸 [Kiwix](https://kiwix.org/en/)에 통합할 수 있다면 좋겠음  
  나는 요즘 **오프라인 전용 폰**을 쓰고 있어서 Wikipedia, Wiktionary, 100rabbits 사이트를 전부 오프라인으로 보고 있음  

- 압축을 더 하면 얼마나 작아질지 궁금함  
  “이 웹사이트는 스크롤바를 납치해서 싫다” 같은 댓글은 몇 비트로도 인코딩 가능할 듯함
  - **Brotli**의 하드코딩 사전처럼 만드는 것도 이상하지 않을 듯함 ([관련 링크](https://news.ycombinator.com/item?id=27160590))
  - 내 댓글을 다 빼면 5비트면 충분하겠음

- `select * from items limit 10`을 실행해봤는데, shard를 하나씩 순회하느라 결과가 안 돌아옴  
  60개 shard까지 가다가 멈췄음. shard 하나만 지정하면 즉시 결과가 나옴  
  **DuckDB**는 parquet 파일의 필요한 부분만 HTTP로 읽을 수 있어서 더 빠를 듯함  
  `users`와 `user_domains` 테이블 오류는 shard 필터를 user stats shard로 바꾸면 해결됨
  - 이상함. VFS였다면 이런 동작은 안 나와야 함. 아마 VFS가 아닐 수도 있음

- **Single-page application(SPA)** 처럼, **Single-table application(STA)** 개념이 생길 수도 있겠음  
  테이블을 여러 키로 shard해서 static 파일로 제공하면, 공개 가능한 데이터라면 정적 HTML처럼 배포 가능함
  - [Baked Data 아키텍처 패턴](https://simonwillison.net/2021/Jul/28/baked-data/)이 이와 유사함  
  - “single table”이 아니라 “single database”를 말한 건가? 관계가 없는 앱은 만들기 어렵지만, Reddit은 “things”라는 거대한 단일 테이블로 운영했음

- 저장소가 **404로 사라졌음**  
  일부 데이터만이라도 내부 구조를 보고 싶었는데 아쉬움
  - 정말 빠르게 내려갔음. 최근 HN 데이터셋을 찾고 있는데 거의 구할 수가 없음

- 나도 404 오류가 뜸  
  혹시 **DuckDB** 같은 컬럼형 스토어와 SQLite의 트레이드오프를 고려했는지 궁금함
  - 아마 **MS가 저장소를 내렸을 수도 있음**, 다른 저장소는 멀쩡함  
  - 난 그냥 SQLite로 바로 갔음. DuckDB가 뭔지 잘 모름  
  - DuckDB가 압축은 더 잘하겠지만, SQLite의 **보편성**을 생각하면 표준 선택으로 충분함  
  - SQLite는 단일 파일로 DB를 다룰 수 있어서 **아카이빙**에 유용함

- 텍스트가 **비디오보다 훨씬 효율적**이라는 걸 새삼 느꼈음  
  같은 양의 지식을 비디오로 담는다면 얼마나 클지 상상도 안 됨
  - 유튜브는 20분짜리 영상에 쓸모 있는 단어 100개 정도만 담고 클릭 유도함. **비효율**이 심함  
  - 1080p60 영상은 초당 5Mbps로, 초당 12만 단어에 해당함. 평균 말속도 150wpm 기준, 텍스트가 **5만 배 더 효율적**임  
    22GB 텍스트를 영상으로 바꾸면 약 1PB(1000TB) 정도 됨  
  - 요즘은 **video LLM**으로 텍스트 기반 영상이나 다이어그램을 자동 생성할 수도 있음  
    보드게임이나 프로그래밍 영상은 그냥 텍스트로 요약해서 읽는 게 나음

- 이걸 **.zim 파일**로 만들어 Kiwix 같은 오프라인 브라우저에서 볼 수 있으면 좋겠음  
  나는 종종 “오프라인 전용일”을 정해 학습 내용을 정리하는데, Kiwix로 Wikipedia나 StackOverflow를 참고함  
  [Kiwix 라이브러리 소개](https://kiwix.org/en/the-new-kiwix-library-is-available/)
  - 이런 콘텐츠가 Kiwix 앱에서 바로 탐색 가능하면 정말 좋겠음

- 나도 비슷한 걸 해봤음  
  Reddit의 **Project Arctic Shift dump**를 SQLite로 가져오는 툴을 Rust로 만들어봤음  
  FTS5 인덱스를 안 만들고 WAL 없이 `--unsafe-mode`로 가져오면 전체 댓글과 게시글을 24시간 정도에 가져오고 약 10TB DB가 생성됨  
  SQLite의 JSON 기능은 멋지지만, 난 로드 시 한 번만 파싱해서 **정규화**하는 쪽을 택했음  
  DB 빌드는 빠르지만, **VACUUM**을 바로 실행하면 쿼리 속도가 훨씬 빨라짐. 다만 VACUUM은 며칠 걸림  
  [Pushshift Importer](https://github.com/Paul-E/Pushshift-Importer) / [Arctic Shift dump 링크](https://github.com/ArthurHeitmann/arctic_shift/blob/master/download_links.md)
  - SQLite의 [auto_vacuum](https://sqlite.org/pragma.html#pragma_auto_vacuum)을 쓰면 전체 DB를 다시 빌드하지 않고도 공간을 회수할 수 있음