@NX15 我记得客服之前跟我也说过不行的，你这个是不是有点看人品了。

@JungleHi 但我的 url 其实很干净，只有 0-1 个参数。

@okjb 当然不是。。。。

@JungleHi 哦 还没弄过 search console，去研究研究

@t6attack 这个有点吓人啊。。。ISP 内容监控的爬虫？？？

@zarte
@leir
就普通的内容站，实际上之前并没有这么多，这几天翻了十倍，有点扛不住。

@SukkaW 哦哦 好像这是个好办法，我看看怎么试一下。

@vtwoextb 其实相比被爬数据这个点，我目前更心疼服务器负载和流量。已经连续四天超量采集了，难受。

@SukkaW 这是什么高难度操作啊。。。哭哭

@shingle 是，YouTube 的直播。

500 错误，兼容一下： https://www.youtube.com/watch?v=UR2YXccrtOE

@xuanwu

有点钻牛角尖了。在问题一大堆的前提下，你甚至跟本就无法回答这东西能给用户带来什么独特的价值（相较于目前的搜索引擎来说）。你能解决什么它们解决不好的问题？？

咱们只能讨论客观的东西，如果你只是坚持内心所望，那话无多说，开干便是。

Yacy 就符合这个条件，不过 3-5 个爱好者，自己有能力，自己干就是。至于多少人力物力，那只跟你自己的斤两有关，你要是全能搞定，那成本就是 你一个人 + 一台电脑。



说点题外话：

如果你要跟人讨论问题，就不要随便拿万分之一说事。这不仅关乎你的智商问题，更有道德问题。

知乎的提问，你自是可以拭目以待。毕竟，到最后的最后之前，你都有权利说：一切还未盖棺定论。

@xuanwu 这个问题流产概率比较大，因为问题太大，而且并不是一个值得讨论的事情。

@xuanwu 我没有在说爬取数据的问题，我在说数据存储和可靠性的问题。你现在陷入一腔热情当中，你自己冷静想想 吧。你口口声声说的 Yacy，你觉得算成功，做出标杆了吗？

@xuanwu
1、假设百度索引的中文网页数量是 Google 的 1%，且以 百度 为目标；
2、那么你的总处理页面相当于 3000 亿个，以一个网页平均 8k 大小来算，加上向量关系、分词、权重、索引 等内容，一个页面占用的磁盘为 10k （非常保守）；
3、那么你总共有近 30 亿 M 的内容要存储 —— 平均每个设备分担 100M，得 3000 万个 设备参与，每台设备分担 1000M，要 300 万台设备参与；
4、这些设备松散度极高，且可靠性非常低，你至少得做 10 个备份才有可能保证最基本的稳定可用，那么即便每台设备即便都能分担 1000M 数据，必须要参与的设备也来到了 3000 万台；
5、由于存储的极致分布式，导致某些 IO、CPU 甚至 GPU 密集型的运算几乎无法工作的。

其他的应该不用说了。

PS：非常不想泼冷水，但不得不感叹：艺高胆大 和 初生牛犊，真的只是一线之隔。

@xuanwu
1、缓存部分我已经说过了。搜索引擎虽然大部分的搜索量也会集中在少数高频关键词中，但同时也及其长尾。尤其像 Google 这种多地区、多语言，并且针对结果做了千人千面，所以传统的缓存命中率会很低，所以并不适用。50 个搜索 QPS，我已经算了缓存在内了，并且后面已经又做了个翻倍。
2、说到算法和数据，别说算法了，你现在的资源连大规模的爬虫都搞不定的。对普通用户来说，他安装了你的插件的确是可以分担网络资源和计算资源，但这本身是 IO 密集型的需求，而每个人的电脑手机配置和使用情况也是千差万别。只要用户一感知出来你这个东西长期在耗资源、耗网络，马上就会卸掉（参考 BT、电驴）。

@xuanwu
看了你这个回答，我感到特别恶心。。
你拿一个讨论 Web Server 的问答给我看是啥意思？也不知道你是真不懂还是钻牛角尖。
我那个帖子是在说 Web 服务器吗？是在说 LB 服务器吗？是在说 CDN 服务器吗？这些我统统没有说，我只是单单纯纯在说「搜索服务器」好吗？？？

@xuanwu

你拿 12306 跟 Google 这么比合适吗？一个数据量那么大，用 SSD 都嫌贵，一个数据量那么小，全放内存就行。

而...Redis 1 万 QPS ？ Redis 是完全基于内存的查询，而且 Redis 是什么查询复杂度？综合搜索引擎是什么查询复杂度？

为什么我感觉我在跟你说着两个世界的东西？

@xuanwu 传言有不少，有人估计 250 万台，有人说全球服务器的 2%，也有前技术总监说大约相当于当年的第三大 PC 厂商的年产量。先不听传言，来自己大概粗浅地估算一下：

基于的事实：
1、谷歌 14 年左右时候就宣称过网页索引量到达了 10 万亿，那么这些年互联网特别是移动互联网爆发，算 30 万亿吧；
2、谷歌 2016 年每秒越处理 63000 个请求，到了 2018 年 每秒 10 万的预计不过分吧；

估算：
1、根据我做搜索的经验，一台 32C128G+SSD 服务器算上要稳定高效（ 50 QPS 毫秒级返回结果）地简单处理 2KW 条索引记录就已算难得，Google 的实时算法很复杂（暂且不说 PageRank 等离线算法），远比 Lucene 复杂，但 Google 这么牛，算单台服务器能顶 5KW 条记录吧。那么处理这整个集群下来，即便不考虑任何损耗和可靠性保障，也差不多要 60 万台服务器能保证一个「完整搜索实例」地正常运行；
2、Google 的集群肯定做了关键词的类型、语言、相关性聚类。所以大部分时候，一次搜索，可能都只需要调用数百 - 数千台服务器，即是算上超大集群的各种大的性能损耗（如何降低损耗绝对是个技术含量很高的活），整个「完整搜索实例」的 QPS 也能有百倍的提升，达到 5000 QPS ；
3、Google 2016 年 高峰时每秒处理超过 63000 个请求（ 63000 QPS ），那么处理这些 QPS 就需要有至少 12 个这样的完整实例，这大概就需要 800 万台服务器的规模了。
4、Google 的技术实在太牛了，我这个估计太粗浅，再打个折，光是这一项的基本至少也要 500 万台服务器；
5、那么，这种超大集群的运行，一定要有好的阈值管理，高峰负载绝对不能超过集群极限的 60%，那么，单单整个搜索系统的负载，都要 800 万 台服务器以上；

其他：
1、可能有人说为什么不算缓存，单机 5KW 索引，50 QPS 的估算已经算上基本的缓存了。而且 Google 的算法极其复杂，搜索结果很早就做了千人千面，再加上地域众多，语言众多，实际的缓存命中并不会有那么高；
2、可能有人说 Google 的技术是你想象不到的，你这个估算还是低估了 Google。那我也要说，这些以数据为命脉的企业，为保障数据安全性、可靠性所花销的额外成本，也是你想象不到的，更别说还要应对黑客、DDoS 之类的攻击。
3、这里没有算一些搜索周边部件所需要的硬件：CDN、LB、存储 等；
4、这里也没有算一些对搜索有重要支撑的业务所需要的硬件：Pagerank 等离线运算服务器、爬虫、Adsense （是搜索服务的重要收入命脉之一）；