Alle Artikel und Kommentare von Hacker News von 2006–2025, gesichert in 22 GB SQLite

• Hacker Book ist ein Projekt, das die vollständigen Daten von Hacker News von 2006 bis 2025 im SQLite-Format bewahrt
• Es besteht aus insgesamt 46.399.072 Beiträgen und 1.637 Shards und umfasst 19 Jahre HN-Geschichte
• Es ist keine serverseitige App, sondern nutzt zu WASM kompiliertes SQLite und lädt bei Bedarf nur Teile als Shards herunter, um sie anzuzeigen
• Über die Weboberfläche lassen sich Beiträge, Nutzer und Kommentare durchsuchen; sie bietet eine der Live-Struktur von HN ähnliche UI
• Zu den Top-Beiträgen gehören verschiedene Themen wie KI, Open Source, Technikgeschichte und gesellschaftliche Fragen
• Es ist eine Ressource, die Entwicklern und Forschern eine Grundlage für langfristige Datenanalysen von Internet-Technik-Communities bietet

---

Überblick über Hacker Book

• Hacker Book ist ein Projekt, das die vollständigen Daten von Hacker News als SQLite-Datenbank bereitstellt
  • Die Daten decken den Zeitraum vom 9. Oktober 2006 bis zum 28. Dezember 2025 ab
  • Insgesamt besteht es aus 46.399.072 Einträgen (items), 1.637 Shards und 8,5 GB Größe (Informationen am Seitenende)
• Die Website ist unter https://hackerbook.dosaygo.com/ erreichbar
  • Die Oberfläche ähnelt Hacker News und zeigt Beitragslisten, Punkte, Anzahl der Kommentare und Autorinformationen an

Datenstruktur und Navigationsfunktionen

• Jeder Eintrag besteht aus Beitragstitel, Ursprungsdomain, Punkten, Autor, Kommentaranzahl und Erstellungszeit
• Die Navigation ist über nutzerspezifische Seiten (view=user&id=) und Detailseiten zu Beiträgen (view=item&id=) möglich
• Über den Link „More“ können seitenweise weitere Einträge geladen werden

Technische Details

• Die Daten werden im SQLite-Format bereitgestellt, sodass in einer lokalen Umgebung Abfragen und Analysen möglich sind
• Durch die Zusammenführung der vollständigen HN-Historie in einer einzigen Datenbank können Forscher oder Entwickler zeitbasierte Trendanalysen durchführen
• Die Struktur mit Datenaufteilung (Sharding) unterstützt die effiziente Verwaltung sehr großer Datenmengen

Bedeutung des Projekts

• Es fungiert als digitales Archiv zur Bewahrung von 19 Jahren angesammeltem Community-Wissen von Hacker News
• Es erhöht die Zugänglichkeit offener Daten und kann für Forschungen zur Technikgeschichte oder Community-Analysen genutzt werden
• Wie der Slogan „All the HN Belong to You“ andeutet, wird die gesamte Aufzeichnung der Community öffentlich zugänglich gemacht, damit sie jeder durchsuchen kann

[GN⁺]

Hacker-News-Meinungen

• Der Kern dieses Projekts ist, dass alles vollständig im Browser läuft, nicht auf dem Server
  SQLite wird zu WASM kompiliert verwendet, und statt die komplette 22-GB-Datenbank herunterzuladen, werden nur die shardweisen Daten geladen, die für die jeweilige Seite nötig sind
  Im Netzwerk-Panel war zu sehen, wie Dateien wie shard_1636.sqlite.gz und shard_1635.sqlite.gz nacheinander geladen werden
  Das erinnert an den früheren SQLite.js-HTTPVFS-Trick, aber diesmal werden statt Range-Headern geshardete Dateien verwendet
  In der interaktiven SQL-Abfrageoberfläche kann man direkt auswählen, auf welchem Shard die Abfrage ausgeführt werden soll (insgesamt 1636)

  • So ein Read-only-VFS lässt sich mit der passenden API sehr einfach implementieren
    Ein VFS-Beispiel, das ich gebaut habe, ist hier zu finden
    Ein Beispiel mit Range-Requests gibt es unter diesem Link
    Um mit Zstandard komprimierte SQLite-Datenbanken zu unterstützen, muss man nur diese Bibliothek hinzufügen

  • Ich frage mich, ob es noch mehr Beispiele gibt, die diese HTTP-Range-basierte Idee auf echtem Produktionsniveau umgesetzt haben. Das wirkt sehr vielversprechend

  • Die VFS-Unterstützung ist wirklich erstaunlich

• Es wäre großartig, wenn sich das in Kiwix integrieren ließe
  Ich benutze inzwischen ein reines Offline-Handy und lese darauf Wikipedia, Wiktionary und die 100rabbits-Website komplett offline

• Ich frage mich, wie viel kleiner es mit stärkerer Komprimierung noch werden könnte
  Kommentare wie „Ich mag diese Website nicht, weil sie die Scrollbar kapert“ ließen sich vermutlich schon mit ein paar Bits kodieren

  • Es wäre wohl nicht einmal seltsam, etwas wie das hartkodierte Wörterbuch von Brotli zu bauen (passender Link)
  • Wenn man all meine Kommentare entfernt, würden wohl 5 Bit reichen

• Ich habe select * from items limit 10 ausgeführt, aber es kam kein Ergebnis zurück, weil die Shards einzeln durchlaufen wurden
  Es blieb bei etwa 60 Shards hängen. Wenn man nur einen einzelnen Shard angibt, kommt das Ergebnis sofort
  DuckDB wäre vermutlich schneller, weil es bei Parquet-Dateien nur die per HTTP benötigten Teile lesen kann
  Der Fehler bei den Tabellen users und user_domains lässt sich beheben, wenn man den Shard-Filter auf den User-Stats-Shard umstellt

  • Merkwürdig. Wenn es ein VFS wäre, sollte sich das nicht so verhalten. Vielleicht ist es gar kein VFS

• So wie es Single-page applications (SPA) gibt, könnte es vielleicht auch das Konzept einer Single-table application (STA) geben
  Wenn man eine Tabelle nach mehreren Schlüsseln shardet und als statische Dateien bereitstellt, ließe sich öffentlich freigegebene Daten ähnlich wie statisches HTML verteilen

  • Das Baked-Data-Architekturmuster ist ähnlich
  • Meintest du statt „single table“ vielleicht eher „single database“? Anwendungen ohne Relationen sind schwer zu bauen, aber Reddit lief mit einer riesigen einzelnen Tabelle namens „things“

• Das Repository ist als 404 verschwunden
  Ich hätte gern wenigstens bei einem Teil der Daten die interne Struktur gesehen

  • Es wurde wirklich sehr schnell entfernt. Ich suche gerade nach aktuellen HN-Datensätzen, aber man findet fast keine

• Ich bekomme ebenfalls einen 404-Fehler
  Ich frage mich, ob die Trade-offs zwischen einem spaltenorientierten Store wie DuckDB und SQLite berücksichtigt wurden

  • Vielleicht hat MS das Repository entfernt, die anderen Repositories sind noch da
  • Ich bin einfach direkt zu SQLite gegangen. Ich kenne mich mit DuckDB nicht besonders gut aus
  • DuckDB würde wahrscheinlich besser komprimieren, aber wenn man die Allgegenwärtigkeit von SQLite bedenkt, ist es als Standardwahl völlig ausreichend
  • SQLite ist fürs Archivieren nützlich, weil man die gesamte Datenbank als einzelne Datei handhaben kann

• Mir ist wieder klar geworden, dass Text viel effizienter ist als Video
  Ich will mir gar nicht vorstellen, wie groß dieselbe Wissensmenge in Videoform wäre

  • YouTube packt in ein 20-Minuten-Video vielleicht 100 nützliche Wörter und optimiert auf Klicks. Die Ineffizienz ist enorm
  • Ein 1080p60-Video mit 5 Mbit/s entspricht 120.000 Wörtern pro Sekunde. Bei einer durchschnittlichen Sprechgeschwindigkeit von 150 Wörtern pro Minute ist Text 50.000-mal effizienter
    Wenn man 22 GB Text in Video umwandeln würde, käme man auf etwa 1 PB (1000 TB)
  • Heute kann man mit Video-LLMs auch textbasierte Videos oder Diagramme automatisch erzeugen
    Bei Brettspielen oder Programmiervideos ist es aber meist besser, einfach eine Textzusammenfassung zu lesen

• Es wäre schön, wenn man das als .zim-Datei bauen könnte, damit es sich in einem Offline-Browser wie Kiwix ansehen lässt
  Ich lege gelegentlich einen „Nur-offline-Tag“ ein, um Lerninhalte zu ordnen, und nutze dann Kiwix für Wikipedia oder StackOverflow
  Vorstellung der Kiwix-Bibliothek

  • Es wäre wirklich großartig, wenn sich solche Inhalte direkt in der Kiwix-App durchsuchen ließen

• Ich habe auch etwas Ähnliches gemacht
  Ich habe in Rust ein Tool gebaut, das den Project-Arctic-Shift-Dump von Reddit nach SQLite importiert
  Wenn man keinen FTS5-Index anlegt und ohne WAL mit --unsafe-mode importiert, lassen sich alle Kommentare und Beiträge in ungefähr 24 Stunden importieren, und es entsteht eine Datenbank von etwa 10 TB
  Die JSON-Funktionen von SQLite sind großartig, aber ich habe mich dafür entschieden, beim Laden einmal zu parsen und dann zu normalisieren
  Der Datenbank-Build ist schnell, aber wenn man direkt danach VACUUM ausführt, werden die Abfragen deutlich schneller. VACUUM selbst dauert allerdings mehrere Tage
  Pushshift Importer / Arctic-Shift-Dump-Link

  • Mit dem auto_vacuum von SQLite kann man Speicherplatz zurückgewinnen, ohne die gesamte Datenbank neu aufzubauen