@nicoljiang 多谢详细分析. 几个问题:

- "单台服务器能顶 5KW 条记录". 这是按照硬盘存储限制得出的吗?

- 第二点的 60 万台服务器提供 5000QPS 是如何得出的?

- 处理 60k 的 QPS 需要 12 个处理 5 千 QPS 的完整实例吗?

关于 qps 的一些资料:
https://www.csdn.net/article/2013-12-30/2817959-look-at-12306
在只采用 10 几台 X86 服务器实现了以前数十台小型机的余票计算和查询能力，单次查询的最长时间从之前的 15 秒左右下降到 0.2 秒以下，缩短了 75 倍以上。2012 年春运的极端高流量并发情况下，支持每秒上万次的并发查询，高峰期间达到 2.6 万 QPS 吞吐量，整个系统效率显著提高。

https://www.jianshu.com/p/608da9336acb
单台实例连接 redis，能达到 2 万的 QPS，四台实例的时候，每台 1 万 5 的 QPS

国外有吗？

对 浏览器渲染很耗资源. 当时好像看到 headless browser 都有这那的问题(页面内容不完全加载等等), 所以直接试了用 Chrome 渲染.

@wizardforcel 嗯, 个人觉得储存总量来说, 并不是最大的问题(假设这个 p2p 网络至少有数万台机器同时在线的话).

当然如果可以做到在不同的计算节点上采用不同层次的抓取细节, 应该可以拓展节点类型. 比如说, 手机也可以做一个轻量级的节点(存储和计算能力有限, 因此抓取较少, 只存摘要, 索引压力也小很多).

"代码翻译尝试-使用 Roaster 解析和生成 Java 源码": https://zhuanlan.zhihu.com/p/44536065
此文是前文使用现有在线翻译服务进行代码翻译的体验的编程语言方面第二点的一个尝试. 初步汉化后 Java 代码效果如下:

package com.company.example;

import java.io.Serializable;

public class 人 implements Serializable {

private static final long serialVersionUID = 1L;
private final 整型 号;
private 字符串 全名;

public 整型 get 号() {
return 号;
}

public 字符串 get 全名() {
return 全名;
}

public void set 全名(字符串 全名) {
this.全名 = 全名;
}

public 人(java.lang.Integer id) {
this.id = id;
}
}

@mythmgn 额, 确实是分布式啊. 设想的就是类似 YaCy 那样的.

http://www.worldwidewebsize.com/ 共 4.5 billion 网页. 按上面的最后一个数据, 大约 450 天更新一次. 而这只是单节点可以做到的.
个人计算机的算力上升+SSD 的普及+5G 的实现还会把上面的数据提高更多.

@mythmgn 储存和抓取成本. 一点参考 https://stackoverflow.com/questions/1935148/how-to-crawl-billions-of-pages
亮点:
1. 2014 年回答节选: "bought by EBay for about 3000 Euro and contains 24x1TB 2,5" Disks (running as Single Disks) with two 6 Core Intel Xeons (making it 12cores/24 threads) and 96GB RAM using a 10GBit Line (with just 33% percentile) in a Luxembourg Datacenter.
It's using 100,000 concurrent HTTP connections which results in about 30,000 pages per second crawled."

2. 2010 年回答节选: "suppose you get a cheapo $200 machine with 1Gb or ram and 160Gb harddrive. At 20KB a page (use Range requests to avoid swallowing big pages whole), 10 million pages would take 200 GB, but compressed is about 70 GB."

3. 2011 年回答节选 "@20 Mbps (upper end of home bandwidth) / 22 kB/page = ~116 pps: it would take about 100 days (~3 months) to download 1 billion pages."

@mythmgn 先说一下非技术部分吧。存活的最大动力之一应该就是公开公平的排序算法和本地化的索引数据。理论上说, 一个新网站在上线之前就可以根据排序算法和索引数据在本地运行测试出此站在不同关键词搜索时的排位。而搜索用户可以完全信任搜索结果, 因为所有数据和算法都是公开的。

@nicoljiang 谷歌服务器总数(所有服务)在 2016 年的估计是 2.5 百万 https://www.datacenterknowledge.com/archives/2017/03/16/google-data-center-faq
用于搜索服务应该不过一半吧

说起猎奇 中文命名的代码比脏话代码应该稀少的多了

@whileFalse 第一, 把最常用的索引数据本地化(并且按时同步). 比如说, 假设全网万分之一(或者十万分之一, 取决于索引大小和用户能负担的空余硬盘空间)的内容可以应付最常用的 60%的搜索. 那么就把这万分之一的索引数据本地化. 这样 60%的搜索就可以在本地进行.

第二, 针对个人感兴趣的主题和搜索历史, 提前获取相应的索引部分到本地, 进一步减少实时对其他节点 /主节点的搜索请求压力. 假设这可以应付剩下 40%的 60%. 还剩 16%. 一二两步都有额外的同步开销, 但因为是以大块的索引数据形式同步, 应该远小于省去的远程搜索开销.

第三, 每次搜索并不需要全网信息. 只需返回排序最靠前的 10 个即可(应该也是主流搜索引擎预先缓存的). 而排序靠后的可以在第一次搜索之后按照第二条进行预获取(在用户浏览前十个搜索结果时).

另外, "每次搜索需要 100 个请求，这一次搜索多久能完成，用户等不等得起？" 这个应该是主流搜索引擎解决了的问题吧, 毕竟不需要等候所有请求都返回.

@ antileech https://www.v2ex.com/t/487957?p=2#r_6154772 在这里回复.
> 太理想化了，倒不是技术问题，而是国内政治风险太大。如果不做审查，负责人很快就会被约谈；如果审查，投入的人力成本又不是社区负担得起的。

审查是无论国内外搜索引擎都需要处理的. 社区是广泛的搜索引擎使用者社区, 而非它的开发者社区. 还需要一套开放的举报和审核机制.

@yoyohaha 应该是持续投入吧？考虑主站服务器投入等等。

@kersbal 嗯, 短期内很可能. 不过排位算法在刚出现的时候也是被不停钻空子的(这个帖子的问题说不定也是被钻了空子). 个人认为 SEO vs. 排位(算法+人工)类似于加 /解密的关系. 哪里看到过的说法是, 闭源的加密算法往往比开源的不安全.

@kersbal duckduckgo 并不是分布式的吧? 而且它搜索算法应该不开源吧? 我的设想是这样的: [支撑一个面向国内的开源分布式搜索引擎需要多少人力物力?]( https://www.v2ex.com/t/488032)

这么多年了 有没有试过靠志愿力量维护一个分布式+社区监督维护的开源搜索引擎? 感觉技术人力和计算资源都不是问题啊

"使用现有在线翻译服务进行代码翻译的体验": https://zhuanlan.zhihu.com/p/44169542
用两个小例程测试了楼上的 4 个翻译服务. 最后有初步的需求分析.