ハクソク

世界を動かす技術を、日本語で。

Show HN: SQLiteに保存された22GBのHacker News

146日前原文(hackerbook.dosaygo.com)

概要

  • Hacker News の20年分のアーカイブを ローカル端末 で利用可能
  • オフライン で閲覧できる 静的アーカイブ
  • GitHubリポジトリから 簡単ダウンロード
  • Big Query とETLを活用したデータ処理
  • 2026年 への感謝と新年のメッセージ

Hacker News完全アーカイブの紹介

  • Hacker News の全アーカイブを ブラウザ上 で閲覧可能
  • HN Made of Primes 開発経験を活かした オフラインsqlite/wasm アプローチ
  • 数GB規模の 全データセット を端末に保存可能
  • オフライン での利用により、 永続的なアクセス を実現
  • Hacker News の20年分の議論や知見を いつでも 参照可能

導入手順と利用方法

  • GitHubリポジトリ （https://github.com/DOSAYGO-STUDIO/HackerBook）にアクセス
  • 必要なファイルを ダウンロード
  • Big Query によるデータ抽出と ETL でデータ変換
  • コマンド「 npx serve docs」でローカルサーバーを起動
  • ブラウザから アーカイブ を閲覧

プロジェクトの意義とメッセージ

  • Hacker News の情報が 永久的 に保存される意義
  • 誰でも 簡単に利用できる 静的アーカイブ
  • 知識と議論 の遺産を未来へ継承
  • 2026年 への感謝の気持ちと、 新しい挑戦 への激励
  • 「何かを作る」 ことの大切さを強調

Hackerたちの意見

そのリポジトリ、404エラーが出てるんだけど。質問なんだけど、DuckDB（または他のカラムストア）とSQLiteのトレードオフについて考えたことある？

└

いや、私はそのままSQLiteに行ったよ。DuckDBって何？

└

ここでの作者じゃないけど、DuckDBについてはよくわからない。でもSQLiteはファイルをそのままデータベースとして使えるから、アーカイブにはすごく便利だよ。一つのファイル、それだけ。

└

DuckDBの方が圧縮効率が良いかもしれないけど、SQLiteの普及率を考えると、標準的な選択としては悪くないと思う。

└

もしかしてMSに消されたのかな？他のリポジトリはちゃんと残ってるけど。

これをオフラインブラウジング用の.zimファイルに変換できるかな？Kiwixみたいなオフラインブラウザで使えるやつ。最近、学んだことをまとめるために「オフライン専用の日」を頻繁に取ってて、KiwixはオフラインのWikipediaやStackOverflowのリファレンスにすごく役立ってるよ。 [0] https://kiwix.org/en/the-new-kiwix-library-is-available/

└

これ、Kiwixアプリで情報をスクロールしてる人たちにも絶対に提供されるべきだよね！

これがどう動くか見逃さないでね。これはサーバーサイドアプリケーションじゃなくて、このコードはSQLiteをWASMにコンパイルしてブラウザ内で完全に動いてるんだ。22GBのデータベースを丸ごと取得するんじゃなくて、閲覧中のページに必要なSQLiteデータベースの「シャード」だけを賢く取得するハックを使ってる。ブラウザのネットワークパネルで見てたら、こんな感じで取得してたよ： https://hackerbook.dosaygo.com/static-shards/shard_1636.sqlite.gz https://hackerbook.dosaygo.com/static-shards/shard_1635.sqlite.gz https://hackerbook.dosaygo.com/static-shards/shard_1634.sqlite.gz 過去の日付にページを移動するたびにね。数年前のあの素晴らしいSQLite.js VFSトリックを思い出させるね： https://github.com/phiresky/sql.js-httpvfs - あれはHTTPレンジヘッダーを使ってたけど、こっちはシャードファイルを使ってる。 https://hackerbook.dosaygo.com/?view=query のインタラクティブSQLクエリインターフェースでは、どのシャードに対してクエリを実行するか選ぶようになってて、合計1636個あるよ。

└

VFSのサポートはマジで素晴らしいね。

└

そのSQLiteのやつみたいに、HTTPレンジリクエストの同じアイデアを基にしたもっと生産的なものってあるのかな？これ、めっちゃポテンシャルあるよね。

テキストが動画よりもずっと効率的だってことを思い出させてくれるね、マジで！同じ量の知識（または無駄話）が動画形式だったらどうなると思う？どれくらいの大きさになるんだろう。

└

平均的な高品質の1080p60動画はビットレートが5Mbpsで、これは毎秒120,000単語の英語に相当するんだ。平均的な英語のスピーチが150単語/分だから、テキストは50,000倍もスペース効率がいいってことになる。22GBの非圧縮テキストを動画エッセイに変換すると、約1PB、つまり1000TBになるよ。

└

テキストに基づいて動画や図、静止画を自動生成するために動画LLMを使うこともできるよね。ただ、ボードゲームのプレイ動画やプログラミングの場合は、テキストに書き起こして要約してYouTube動画を読むだけなんだけど。

└

それがYouTubeの悲しいところだよね。100語の使えるコンテンツを得るために20分の動画をエンコードするなんて、効率が信じられないくらい悪い。

シングルページアプリケーション（SPA）に似て、シングルテーブルアプリケーション（STA）も流行るかもしれないね。複数のキーでテーブルをシャードして、データが共有可能なら静的ファイルとしてシャードを提供するって感じで、静的HTMLコンテンツを共有するのと似てる。

└

単一のデータベースってこと？単一のテーブル（関係なし）でアプリを作るのはかなり難しいし、ほぼ不可能だと思う。でも、redditはやったよね。確か「もの」の巨大なテーブルがあったはず。

└

ベイクドデータのアーキテクチャパターン

圧縮すればどれくらい小さくなるんだろう。たぶん「このウェブサイトはスクロールバーをハイジャックしてて、私はそれが嫌い」ってコメントを数ビットにエンコードできるかも。

└

それで少なくとも45%だね。俺のコメント全部抜かしたら、5個だけ残るよ！

└

ハードコーディングされた辞書はBrotliのよりもおかしくないと思うよ。https://news.ycombinator.com/item?id=27160590

サイトがFirefoxで読み込まれないんだけど、コンソールエラーに「Uncaught (in promise) TypeError: can't access property "wasm", sqlite3 is null」って出る。SharedArrayBuffer（SQLite wasm）がクロスオリジン攻撃のせいでFFでは動かないのは常識みたいだね（今知ったけど；）。最初のデータが読み込まれたら、Chromeでは残りがほぼ瞬時に読み込まれるよ。GitHubのリンク（今404になってる）を直してくれたら、コードを見てみたいな。ありがとう！

└

macOSのFirefoxでは問題なく動いてるよ。

これが基づいているデータの公開ダンプってどこかにあるのかな？それとも自分たちでスクレイピングしたのかな？DBがあったら面白そうだし、コメントのスレッド構造は初心者が効率的な再帰クエリを練習するのに役立ちそう（StackExchangeのダンプよりもね）。

└

正確にはダンプじゃないけど、HNデータをプログラム的に取得できるAPIがあるから、スクレイピングは必要ないよ。https://github.com/HackerNews/API

リポジトリが削除されたみたいだね（404）。残念だな、データの一部を使って中身を見てみたかったのに、投稿やコメントのプレースホルダーでもいいから。

└

早いね。最近のHNデータセットを探してたんだけど、見つけるのが難しいんだよね。

どうやってダウンロードするの？そのリポジトリは404だよ。