22GB SQLite에 백업한 해커뉴스의 2006–2025 전체 기사와 댓글
(hackerbook.dosaygo.com)- 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” 라는 슬로건처럼, 커뮤니티 전체의 기록을 누구나 탐색할 수 있도록 공개
Hacker News 의견들
-
이 프로젝트의 핵심은 서버가 아닌 브라우저 내에서 전부 실행된다는 점임
SQLite를 WASM으로 컴파일해 사용하고, 전체 22GB DB를 받는 대신 페이지에 필요한 shard 단위 데이터만 가져오는 방식임
네트워크 패널에서shard_1636.sqlite.gz,shard_1635.sqlite.gz같은 파일이 순차적으로 로드되는 걸 확인했음
예전의 SQLite.js HTTPVFS 트릭을 떠올리게 하지만, 이번엔 range header 대신 sharded 파일을 사용함
인터랙티브 SQL 쿼리 인터페이스에서는 어떤 shard에 쿼리를 실행할지 직접 선택할 수 있음 (총 1636개) -
이걸 Kiwix에 통합할 수 있다면 좋겠음
나는 요즘 오프라인 전용 폰을 쓰고 있어서 Wikipedia, Wiktionary, 100rabbits 사이트를 전부 오프라인으로 보고 있음 -
압축을 더 하면 얼마나 작아질지 궁금함
“이 웹사이트는 스크롤바를 납치해서 싫다” 같은 댓글은 몇 비트로도 인코딩 가능할 듯함- Brotli의 하드코딩 사전처럼 만드는 것도 이상하지 않을 듯함 (관련 링크)
- 내 댓글을 다 빼면 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 아키텍처 패턴이 이와 유사함
- “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 라이브러리 소개- 이런 콘텐츠가 Kiwix 앱에서 바로 탐색 가능하면 정말 좋겠음
-
나도 비슷한 걸 해봤음
Reddit의 Project Arctic Shift dump를 SQLite로 가져오는 툴을 Rust로 만들어봤음
FTS5 인덱스를 안 만들고 WAL 없이--unsafe-mode로 가져오면 전체 댓글과 게시글을 24시간 정도에 가져오고 약 10TB DB가 생성됨
SQLite의 JSON 기능은 멋지지만, 난 로드 시 한 번만 파싱해서 정규화하는 쪽을 택했음
DB 빌드는 빠르지만, VACUUM을 바로 실행하면 쿼리 속도가 훨씬 빨라짐. 다만 VACUUM은 며칠 걸림
Pushshift Importer / Arctic Shift dump 링크- SQLite의 auto_vacuum을 쓰면 전체 DB를 다시 빌드하지 않고도 공간을 회수할 수 있음