L’intégralité des articles et commentaires de Hacker News de 2006 à 2025 sauvegardée dans 22 Go de SQLite

• Hacker Book est un projet qui préserve l’ensemble des données de Hacker News au format SQLite de 2006 à 2025
• Il se compose de 46 399 072 publications au total, réparties en 1 637 shards, et couvre 19 ans d’historique de HN
• Il ne s’agit pas d’une application côté serveur, mais d’une solution utilisant SQLite compilé en WASM, qui télécharge seulement certains shards à la demande pour les afficher
• Via l’interface web, il est possible d’explorer les publications, les utilisateurs et les commentaires, avec une UI proche de la structure en temps réel de HN
• Les publications les mieux classées couvrent des sujets variés comme l’IA, l’open source, l’histoire des technologies et les enjeux de société
• C’est une ressource qui offre aux développeurs et aux chercheurs une base pour l’analyse à long terme des communautés techniques sur Internet

---

Présentation de Hacker Book

• Hacker Book est un projet qui fournit l’ensemble des données de Hacker News sous la forme d’une base de données SQLite
  • Les données couvrent la période du 9 octobre 2006 au 28 décembre 2025
  • L’ensemble comprend 46 399 072 éléments (items), 1 637 shards, pour un volume de 8,5 Go (information en bas de page)
• Le site est accessible à l’adresse https://hackerbook.dosaygo.com/
  • L’interface ressemble à celle de Hacker News et affiche la liste des publications, les points, le nombre de commentaires et les informations sur l’auteur

Structure des données et fonctions d’exploration

• Chaque élément comprend le titre de la publication, le domaine source, les points, l’auteur, le nombre de commentaires et l’heure de publication
• La navigation est possible via des pages par utilisateur (view=user&id=) et des pages de détail par publication (view=item&id=)
• Le lien « More » permet de charger des éléments supplémentaires page par page

Détails techniques

• Les données sont fournies au format SQLite, ce qui permet de les interroger et de les analyser en local
• En regroupant l’historique complet de HN dans une base de données unique, le projet permet aux chercheurs et aux développeurs de mener des analyses de tendances dans le temps
• Une structure de partitionnement des données (sharding) facilite la gestion efficace d’un volume important de données

Importance du projet

• Il joue le rôle d’archive numérique en préservant 19 ans de connaissances accumulées par la communauté Hacker News
• Il améliore l’accessibilité aux données ouvertes, utiles pour l’étude de l’histoire des technologies ou l’analyse de communautés
• Comme l’indique le slogan « All the HN Belong to You », l’ensemble des archives de la communauté est rendu publiquement explorable par tous

[GN⁺]

Avis Hacker News

• Le point clé de ce projet, c’est que tout s’exécute entièrement dans le navigateur, pas sur le serveur
  SQLite est compilé en WASM, et au lieu de télécharger la base complète de 22 Go, il ne récupère que les données par shard nécessaires à la page
  On peut voir dans le panneau réseau que des fichiers comme shard_1636.sqlite.gz et shard_1635.sqlite.gz se chargent l’un après l’autre
  Ça rappelle l’ancien truc SQLite.js HTTPVFS, mais cette fois on utilise des fichiers shardés au lieu du header range
  Dans l’interface interactive de requêtes SQL, on peut choisir directement sur quel shard exécuter la requête (1636 au total)

  • Ce type de VFS en lecture seule peut être implémenté très simplement avec la bonne API
    Un exemple de VFS que j’ai créé est ici
    Pour un exemple utilisant les range requests, voir ce lien
    Pour prendre en charge une base SQLite compressée avec Zstandard, il suffit d’ajouter cette bibliothèque

  • Je me demande s’il existe d’autres exemples de cette idée basée sur HTTP range mis en œuvre à un vrai niveau production. Ça semble très prometteur

  • La prise en charge du VFS est vraiment impressionnante

• Ce serait bien de pouvoir intégrer ça à Kiwix
  En ce moment, j’utilise un téléphone entièrement hors ligne, donc je consulte Wikipedia, Wiktionary et les sites de 100rabbits totalement hors ligne

• Je me demande jusqu’où on pourrait réduire la taille avec davantage de compression
  Des commentaires du genre « je déteste ce site web parce qu’il détourne la barre de défilement » pourraient sûrement être encodés en quelques bits seulement

  • Ce ne serait pas absurde d’en faire quelque chose comme le dictionnaire codé en dur de Brotli (lien connexe)
  • Si on enlève tous mes commentaires, 5 bits devraient suffire

• J’ai essayé d’exécuter select * from items limit 10, mais la requête ne renvoie rien parce qu’elle parcourt les shards un par un
  Elle s’est arrêtée vers le 60e shard. Si on précise un seul shard, le résultat arrive immédiatement
  DuckDB serait probablement plus rapide, puisqu’il peut lire uniquement les parties nécessaires d’un fichier parquet via HTTP
  L’erreur sur les tables users et user_domains se corrige en changeant le filtre de shard vers celui des statistiques utilisateur

  • Étrange. Si c’était un VFS, ça ne devrait pas se comporter comme ça. Ce n’est peut-être pas un VFS finalement

• Comme pour les Single-page applications (SPA), on pourrait voir émerger le concept de Single-table application (STA)
  Si on découpe une table en shards selon plusieurs clés et qu’on la sert comme fichiers statiques, toute donnée publiable pourrait être distribuée comme du HTML statique

  • Le pattern d’architecture Baked Data est similaire
  • Tu voulais dire « single database » plutôt que « single table » ? Il est difficile de construire une app sans relations, mais Reddit fonctionnait avec une énorme table unique appelée « things »

• Le dépôt a disparu en 404
  C’est dommage, j’aurais voulu examiner la structure interne, même seulement sur une partie des données

  • Il a été retiré vraiment vite. Je cherche un dataset HN récent et c’est presque impossible à trouver

• J’ai aussi une erreur 404
  Je me demande s’ils ont envisagé les compromis entre un store en colonnes comme DuckDB et SQLite

  • MS a peut-être retiré le dépôt, les autres dépôts sont toujours accessibles
  • Moi, je suis parti directement sur SQLite. Je ne connais pas très bien DuckDB
  • DuckDB compressera sans doute mieux, mais vu l’universalité de SQLite, c’est un choix standard tout à fait suffisant
  • SQLite permet de manipuler toute la base dans un seul fichier, ce qui est pratique pour l’archivage

• Ça rappelle à quel point le texte est bien plus efficace que la vidéo
  J’imagine même pas la taille qu’aurait la même quantité de connaissances si elle était stockée en vidéo

  • Sur YouTube, une vidéo de 20 minutes contient à peine une centaine de mots utiles et cherche surtout à faire cliquer. Le niveau d’inefficacité est énorme
  • Une vidéo 1080p60 à 5 Mbps correspond à 120 000 mots par seconde ; avec un débit de parole moyen de 150 wpm, le texte est 50 000 fois plus efficace
    Si on convertissait 22 Go de texte en vidéo, on arriverait à environ 1 Po (1000 To)
  • Aujourd’hui, avec les video LLM, on peut aussi générer automatiquement à partir de texte des vidéos ou des diagrammes
    Pour les vidéos de jeux de société ou de programmation, mieux vaut souvent simplement lire un résumé textuel

• Ce serait bien d’en faire un fichier .zim pour pouvoir le consulter dans un navigateur hors ligne comme Kiwix
  Je me fais parfois des « journées 100 % hors ligne » pour organiser ce que j’ai appris, et j’utilise Kiwix pour consulter Wikipedia ou StackOverflow
  Présentation de la bibliothèque Kiwix

  • Ce serait vraiment bien si ce type de contenu pouvait être exploré directement dans l’app Kiwix

• J’ai fait quelque chose de similaire moi aussi
  J’ai créé en Rust un outil pour importer dans SQLite le dump Project Arctic Shift de Reddit
  Sans index FTS5 et sans WAL, avec --unsafe-mode, l’import de l’ensemble des commentaires et publications prend environ 24 heures et génère une base d’environ 10 To
  Les fonctions JSON de SQLite sont chouettes, mais j’ai préféré parser une seule fois au chargement pour normaliser les données
  La construction de la base est rapide, mais si on lance VACUUM juste après, les requêtes deviennent beaucoup plus rapides. En revanche, VACUUM prend plusieurs jours
  Pushshift Importer / lien vers le dump Arctic Shift

  • On peut utiliser auto_vacuum de SQLite pour récupérer de l’espace sans reconstruire toute la base