2006–2025 arasındaki Hacker News yazılarının ve yorumlarının 22 GB’lık SQLite yedeği

 (hackerbook.dosaygo.com)
16 puan yazan GN⁺ 2025-12-31 | 1 yorum | WhatsApp'ta paylaş
  • Hacker Book, 2006'dan 2025'e kadar Hacker News'un tüm verilerini SQLite formatında koruyan bir proje
  • Toplam 46.399.072 gönderi, 1.637 shard içeriyor ve HN'in 19 yıllık kaydını kapsıyor
  • Sunucu taraflı bir uygulama yerine WASM'a derlenmiş SQLite kullanıyor; gerektiğinde yalnızca bir kısmını shard olarak indirip gösteriyor
  • Web arayüzü üzerinden gönderiler, kullanıcılar ve yorumlar gezilebiliyor; HN'in gerçek zamanlı yapısına benzer bir UI sunuyor
  • Üst sıralardaki gönderiler arasında yapay zeka, açık kaynak, teknoloji tarihi ve toplumsal konular gibi çeşitli başlıklar yer alıyor
  • Geliştiriciler ve araştırmacılar için internet teknoloji topluluklarının uzun vadeli veri analizi temeli sunan bir kaynak

Hacker Book genel bakış

  • Hacker Book, Hacker News'un tüm verilerini SQLite veritabanı olarak sunan bir proje
    • Veriler 9 Ekim 2006'dan 28 Aralık 2025'e kadar olan dönemi kapsıyor
    • Toplam 46.399.072 öğe (items), 1.637 shard, 8,5 GB boyut içeriyor (sayfanın altındaki bilgiye göre)
  • Web sitesine https://hackerbook.dosaygo.com/ adresinden erişilebiliyor
    • Arayüz, Hacker News'a benzer yapıda olup gönderi listesi, puanlar, yorum sayısı ve yazar bilgisi gösteriyor

Veri yapısı ve gezinme özellikleri

  • Her öğe gönderi başlığı, kaynak alan adı, puan, yazar, yorum sayısı ve gönderim zamanından oluşuyor
  • Kullanıcı sayfaları (view=user&id=) ve gönderi ayrıntı sayfaları (view=item&id=) üzerinden gezinmek mümkün
  • More bağlantısı ile sayfa bazında ek öğeler yüklenebiliyor

Teknik ayrıntılar

  • Veriler SQLite formatında sunulduğu için yerel ortamda sorgulama ve analiz yapılabiliyor
  • HN'in tüm geçmişini tek bir veritabanında birleştirerek, araştırmacıların ve geliştiricilerin zaman içindeki trend analizlerini yapmasına olanak tanıyor
  • Veri bölümlendirme (sharding) yapısı sayesinde büyük hacimli verilerin verimli biçimde yönetilmesini destekliyor

Projenin önemi

  • Hacker News'un 19 yılda birikmiş topluluk bilgisini koruyan bir dijital arşiv işlevi görüyor
  • Açık veri erişilebilirliğini artırarak teknoloji tarihi araştırmaları veya topluluk analizlerinde kullanılabiliyor
  • “All the HN Belong to You” sloganında olduğu gibi, tüm topluluğun kayıtlarını herkesin keşfedebilmesi için açık hale getiriyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-31
Hacker News görüşleri

  • Bu projenin kilit noktası, her şeyin sunucuda değil doğrudan tarayıcı içinde çalışması
    SQLite, WASM’a derlenerek kullanılıyor ve 22GB’lık veritabanının tamamını indirmek yerine sayfa için gereken shard düzeyindeki veriler getiriliyor
    Ağ panelinde shard_1636.sqlite.gz, shard_1635.sqlite.gz gibi dosyaların sırayla yüklendiği görülebiliyor
    Bu, eski SQLite.js HTTPVFS hilesini hatırlatıyor ama bu kez range header yerine shard’lanmış dosyalar kullanılıyor
    Etkileşimli SQL sorgu arayüzünde sorgunun hangi shard üzerinde çalıştırılacağını doğrudan seçebiliyorsunuz (toplam 1636 tane)

    • Böyle bir salt okunur VFS, uygun bir API varsa oldukça basit şekilde uygulanabilir
      Benim yaptığım VFS örneği burada
      Range request kullanan örnek için şu bağlantıya bakılabilir
      Zstandard ile sıkıştırılmış SQLite DB desteği için yalnızca şu kütüphaneyi eklemek yeterli

    • Böyle HTTP range tabanlı fikrin gerçek üretim seviyesinde uygulanmış başka örnekleri var mı merak ediyorum. Potansiyeli büyük görünüyor

    • VFS desteği gerçekten şaşırtıcı

  • Bunun Kiwix ile entegre edilebilmesi güzel olurdu
    Bu aralar yalnızca çevrimdışı çalışan bir telefon kullanıyorum; Wikipedia, Wiktionary ve 100rabbits sitelerinin tamamına çevrimdışı bakıyorum

  • Daha fazla sıkıştırılırsa ne kadar küçüleceğini merak ediyorum
    “Bu web sitesi scrollbar’ı gasp ettiği için nefret ediyorum” gibi yorumlar muhtemelen birkaç bitte kodlanabilir

    • Brotli’nin gömülü sözlüğüne benzer bir şey yapmak da garip olmazdı (ilgili bağlantı)
    • Benim yorumlarımı tamamen çıkarırsanız 5 bit yeter de artar bile

  • select * from items limit 10 çalıştırmayı denedim ama shard’ları tek tek dolaştığı için sonuç dönmüyor
    60 shard’a kadar gidip orada kaldı. Tek bir shard seçildiğinde sonuç anında geliyor
    DuckDB, parquet dosyasının yalnızca gereken kısmını HTTP üzerinden okuyabildiği için daha hızlı olabilir
    users ve user_domains tablo hataları, shard filtresi user stats shard olarak değiştirildiğinde düzeliyor

    • Garip. VFS olsaydı böyle davranmaması gerekirdi. Belki de VFS değildir

  • Single-page application (SPA) gibi, belki de bir Single-table application (STA) kavramı ortaya çıkabilir
    Tabloyu birden fazla anahtara göre shard’layıp statik dosya olarak sunarsanız, herkese açık veriler için statik HTML gibi dağıtılabilir

    • Baked Data mimari deseni buna benziyor
    • “single table” değil de “single database” mi demek istedin? İlişkisiz uygulamalar yapmak zor ama Reddit, “things” adlı devasa tek bir tabloyla çalışıyordu

  • Depo 404 olup kaybolmuş
    En azından verinin bir kısmının iç yapısına bakmak istiyordum, yazık olmuş

    • Gerçekten çok hızlı kaldırılmış. Son dönem HN veri seti arıyorum ama neredeyse hiç bulunmuyor

  • Bende de 404 hatası çıkıyor
    Acaba DuckDB gibi sütun bazlı bir store ile SQLite arasındaki trade-off düşünülmüş mü merak ediyorum

    • Muhtemelen MS depoyu kaldırmış olabilir, diğer depolar yerinde duruyor
    • Ben doğrudan SQLite’a gittim. DuckDB hakkında pek bilgim yok
    • DuckDB sıkıştırmada daha iyi olabilir ama SQLite’ın yaygınlığı düşünülünce varsayılan seçim olarak yeterince iyi
    • SQLite veritabanını tek dosya olarak ele alabildiği için arşivleme açısından kullanışlı

  • Metnin videodan çok daha verimli olduğunu yeniden fark ettim
    Aynı miktarda bilgiyi videoya koysanız ne kadar büyük olacağını hayal bile edemiyorum

    • YouTube, 20 dakikalık videoya işe yarar 100 kelime koyup tık avcılığı yapıyor. Verimsizlik çok yüksek
    • 1080p60 video saniyede 5Mbps, yani saniyede 120 bin kelimeye denk geliyor. Ortalama konuşma hızı 150 wpm kabul edilirse metin 50 bin kat daha verimli
      22GB metni videoya çevirmek yaklaşık 1PB(1000TB) eder
    • Bugünlerde video LLM ile metin tabanlı videolar veya diyagramlar da otomatik üretilebiliyor
      Masa oyunu ya da programlama videolarında en iyisi metin özetini çıkarıp okumak

  • Bunun .zim dosyası haline getirilip Kiwix gibi çevrimdışı tarayıcılarda görüntülenebilmesi güzel olurdu
    Ben bazen “yalnızca çevrimdışı günler” belirleyip öğrendiklerimi derliyorum; Kiwix üzerinden Wikipedia veya StackOverflow’a bakıyorum
    Kiwix kütüphanesi tanıtımı

    • Bu tür içeriklerin Kiwix uygulamasında doğrudan gezilebilir olması harika olurdu

  • Ben de benzer bir şey yaptım
    Reddit’in Project Arctic Shift dump verisini SQLite’a aktaran bir aracı Rust ile yazdım
    FTS5 indeksi oluşturmadan ve WAL kullanmadan --unsafe-mode ile içe aktarırsanız, tüm yorumlar ve gönderiler yaklaşık 24 saatte içe aktarılıyor ve yaklaşık 10TB’lık bir DB oluşuyor
    SQLite’ın JSON özellikleri harika ama ben yükleme sırasında bir kez parse edip normalize etme yolunu seçtim
    DB oluşturma hızlı, ancak hemen ardından VACUUM çalıştırılırsa sorgu hızı çok artıyor. Yalnız VACUUM günler sürüyor
    Pushshift Importer / Arctic Shift dump bağlantısı

    • SQLite’ın auto_vacuum özelliği kullanılırsa tüm DB’yi yeniden oluşturmadan da alan geri kazanılabilir