HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    系统与基础设施michaelnielsen.org

    如何在 40 小时内抓取 2.5 亿个网页

    How to crawl a quarter billion webpages in 40 hours

    3次上首页
    6年跨度
    755累计得分
    151条评论

    2012 — 2018,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    Michael Nielsen 复盘了他的一次实验:用一小批云服务器在约 40 小时内抓取 2.5 亿个网页。文章讲清了爬虫的工程细节——URL 前沿队列、用 Bloom filter 做 URL 去重、并发与带宽的权衡,以及对被抓网站的礼貌策略,并给出了这次抓取的实际花费。它不是教你写通用搜索引擎爬虫的教程,而是一份关于大规模抓取在工程和成本上到底意味着什么的第一手记录。

    为什么经久不衰:十多年后它仍是理解「爬全网」真实门槛的入门文本:把规模、成本和对网站的负担都摆到台面上,这在今天的大模型数据抓取时代反而更有讨论价值。

    关键词 网络爬虫Bloom filter分布式系统规模与成本

    HN 评论精选

    真正的难点是 URL 选择、去重和防垃圾站,本文因抓取范围有限而绕开了这部分。

    根据我的经验,写网络爬虫最难的部分之一是 URL 选择:爬完种子 URL 列表后,接下来去哪?如何确保不会因为 URL 略有不同而重复抓取同一内容?如何避免陷在自动生成内容的垃圾站点里?因为作者只在有限的一组域名上、且只爬了很短时间,他不需要操心这部分。尽管如此,这仍是一篇好文章,展示了写爬虫会踩的许多坑。

    soult查看英文原文

    In my experience, one of the hardest parts of writing a web crawler is URL selection: After crawling your list of seed URLs, where do you go next? How do you make sure you don't crawl the same content multiple times because it has a slightly different URL? How to avoid getting stuck on unimportant spam sites with autogenerated content? Because the author only crawled domains from a limited set and only for a short time, he did not need to care about that part. Nonetheless, it's a great article that shows many of the pitfalls of writing a webcrawler.

    指出文中对 Bloom filter 假阳性方向的描述说反了:代价是漏抓,而非重复抓。

    是不是说反了?Bloom filter 提供的是很低的概率把没添加过的 URL 误判为已添加,而把一个实际已添加的 URL 误判为未添加的概率为零。这样用 Bloom filter 能保证你绝不会重复抓到同一页面,但会有一个非零比例的页面你以为下载过了其实没有,取决于你怎么调参。

    brey查看英文原文

    > I used a Bloom filter to keep track of which urls had already been seen and added to the url frontier. This enabled a very fast check of whether or not a new candidate url should be added to the url frontier, with only a low probability of erroneously adding a url that had already been added. other way round? bloom filter provides a low probability of erroneously believing a URL had already been added when it had not, zero probability of believing a URL had not already been added to the filter when in fact it had. using a bloom filter in this way guarantees you won't ever hit a page twice, but you'll have a non-zero rate of pages you think you've downloaded but you actually haven't, depending how you tune it.

    按文中成本线性外推,爬完整个网络的量级约在 4 万美元。

    给像我一样好奇的人算一笔账:按文中方法和数字,2.5 亿页面约合 580 美元。据 internetlivestats 统计有 18 亿个网站,假设平均每站 10 页,就是 180 亿页,是这次测试规模的 72 倍。所以只要约 41,760 美元,你也能启动自己的 Google!

    dstick查看英文原文

    For those curious like I was how much it would cost to scrape the entire internet with the method and numbers provided: 250.000.000 pages come in at $580 There are 1.8b websites according to http://www.internetlivestats.com/total-number-of-websites/ Lets say on average each site has 10 pages (you have a dozen of huge blogs vs tens of thousands of onepagers), that would put the number at 18 billion pages. Following that logic would mean the total web is 72 times larger than what was scraped in this test. So for a mere $41.760 you too can bootstrap your own Google! ;-)

    不公开代码意义有限,真正值得思考的是爬取能力集中化决定了谁有机会挑战搜索巨头。

    (作者原话大意:本打算在 GitHub 上开源爬虫代码,但越了解爬虫给网站带来的负担就越犹豫;我的爬虫设计得礼貌、对单个站点压力很小,但很容易被轻率或恶意的人改成重压站点,因此决定推迟甚至无限期不发布代码。)既然已有大量开源爬虫引擎(比如 Apache Nutch,据称 Common Crawl 用的就是它),这个决定其实没起到什么作用。这里有个更普遍的问题:谁有权爬取网络?在我看来这是文章引出的最有意思的问题。原则上没有理由非得由 Google 主宰搜索——如果有人想出更好的排序算法,就该能像 Google 取代 Altavista 那样把它拉下马。但这只有在任何人都能爬网、或 Common Crawl 这类项目在数据量和抓取频率上追平 Google 时才成立。

    frogfish查看英文原文

    Previous discussions: with [1] 67 comments, [2] 23 comments. [1] https://news.ycombinator.com/item?id=4367933 [2] https://news.ycombinator.com/item?id=10865568

    历次讨论

    同类还值得读

    1. TTY 揭秘(2008)

      The TTY demystified (2008)

      经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理,包括线路规程、终端驱动、信号与控制字符等机制。

      系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选
    2. 为什么 GNU grep 这么快

      Why GNU grep is Fast

      FreeBSD 邮件列表上一篇广为流传的帖子,解释 GNU grep 为什么快:核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O,让程序在搜索时“…

      系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.org
    3. Xplain:为普通人讲解 X11

      Xplain – Explaining X11 for the rest of us

      《Xplain》是作者(HN 用户 Jasper_)写的一系列 X11 长文,用他在浏览器中重建的 X11 绘图模型做交互演示,讲解 X11 的绘图模型与窗口系统设计。

      系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选
    4. 旋风教程:为 Linux 创建极小 ELF 可执行文件(1999)

      A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)

      breadbox 写于 1999 年的经典教程,主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。

      系统与基础设施上首页 6 次 · 2007–2025muppetlabs.com
    5. PostgreSQL 内部原理

      The internals of PostgreSQL

      《The Internals of PostgreSQL》是一本免费在线书籍,系统讲解 PostgreSQL 的内部实现,包括查询处理、并发控制、WAL、缓冲区管理等核心机制。

      系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。