支撑一个面向国内的开源分布式搜索引擎需要多少人力物力?

如果是用于商业，那资金会需要非常多。
如果只是玩玩，1k 可以搞定。

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

那又不是搜索引擎 就一个导航而已

我觉得楼主想多了。

想想分布式数据库无法同时满足的三点：
可用性、一致性、分区容忍程度。

在分布式搜索引擎这个命题下，相当于：
响应时间、数据完整程度、单个节点承载数据的量足够小。

只要想一个问题：楼主预期在每次搜索过程中，有多少主机参与？
打比方说，每次搜索，需要 100 台主机的响应。那么，在理想情况下，每台主机需要索引全网百分之一的信息。楼主猜猜百度搜索有多少数据？除以 100，每台主机能不能承受？再想想，每次搜索需要 100 个请求，这一次搜索多久能完成，用户等不等得起？
当然，这是要求返回数据完整的情况下。如果可以大幅度地容忍数据不完整，那么这货可能还真的在响应时间和数据承载方面可用。但是，此时大概就退化为“浏览历史社交”平台了吧。

@whileFalse
100 台？
百度搜索数量至少是百万台以上（ Google 的服务器数量是千万级）。

@nicoljiang 那你觉得你百度一下的时候这一百万台服务器有多少为你服务了？我说的是“每次搜索，需要 100 台主机的响应”，可没说全网只有 100 台主机。

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

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

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

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

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

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

@whileFalse 每次搜索会有多少台服务器服务，这个东西情况太多了。可能多达几千上万台，也可能少到几台。

劝你不要考虑这个了。给你 1000 万台服务器，你也做不了。

@nicoljiang 百度一次的用时是多少毫秒？几千上万台服务器参与的过来吗？

@whileFalse 有夸大成分。我的意思是你来猜测这个本身没有太大意义，更别说以这种无端揣测为依据的观点论述。
（ V 站现在咋这么多牛角尖 er ）

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

如果真的如楼主所言想索引全网 （支撑全网数据更新），成本非常非常大，几乎不可能。

只说其中一个小环节（存储）中的冰山一角：
a. 如果想索引亿级别的 pages，存储成本是天量的。这还没算需要进行 cache 缓存之类、热点处理之类的实时库更新
b. 技术上成本也非常大：
- 能找到成熟且良好支持 scan 操作的分布式开源项目么？ 能开发、维护、运维这个开源项目项目的 team 人力成本有多大？
- 海量存储最后怎么跟实际提供服务缓存存储对接？ 缓存怎么设计？
- pages 更新机制是怎么样的? 热点数据怎么存储？ 冷数据怎么存？数据备份怎么办？


另外，商业上想，为什么这个项目能存活？ Github 能运营是有内部商业逻辑的。如果没有内部的商业逻辑推动，这个开源项目怎么活下来呢？

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

@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."

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

@xuanwu

只说技术上， 真的太乐观了：
1. 要不要搞容错（多副本）。 不搞容错，机器不坏的? 搞的话，是不是要搞分布式？
2. 一次大规模顺序 scan(用来建 cache ）一个机器能抗住么？ 多少个机器能抗住？
如果不做 cache，这种海量搜索，多少 s 可以回返？

这还只是存储要解决的非常非常非常非常小的零星问题。 楼主可以看看 bigtable。 然后在说可行性.

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

@xuanwu 谷歌搜索是带缓存的，你可以不带缓存，只保存标题链接和摘要，这样一个记录就不到 1k 了。

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

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

@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 （是搜索服务的重要收入命脉之一）；

@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

@xuanwu

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

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

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

@nicoljiang 主要觉得把 web 服务器和后端的储存检索这么直接联系起来有点问题
这里谷歌工程师提到负责 query 的是 web 服务器
https://www.quora.com/Google-processes-40k-searches-per-second-On-average-a-web-server-can-handle-1000-requests-per-second-Does-that-mean-Google-can-run-using-only-40-web-servers
看各种回答感觉这些直接负责 qps 的机器可能在千 /万台级别 当然配置都很高。

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

@nicoljiang 嗯. 之前以为 Web Server 还会起一部分缓存搜索结果的作用, 但看起来没有.
还是对#23 的三个问题有些疑虑.
不过这个想象中项目的开始肯定不会指望达到任何现有搜索引擎的性能, 更多的优势在于公开算法和数据吧.

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

@nicoljiang 多谢. 下面是另一些谷歌搜索服务器的估计: https://www.quora.com/How-many-servers-does-Google-have-to-run-for-providing-the-search
仅作参考. 关于这个估算问题就止于此吧.

关于爬虫问题, 参考 Yacy, 觉得一般使用它的用户都会了解它的背景. 而且它并不主动抓取, 而是由用户指定网站进行抓取. 不过个人觉得在资源允许的情况下进行低频和小量的主动(后台)抓取也是可行的, 比如设定 100MB 的硬盘限额(用户可调), 以及最低优先级的网络使用. 另外, 可以允许有计算资源的用户从其他用户那里搜集抓取结果(类似骨干节点), 而主站肯定是个骨干节点.

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

其他的应该不用说了。

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

@nicoljiang 嗯, 本身是个开放问题. 要是已经有明确的思路 /技术 /具体路线图的话, 也不至于这么问.

刚看到这个: http://www.michaelnielsen.org/ddi/how-to-crawl-a-quarter-billion-webpages-in-40-hours/

如果有一个比较公平透明的基于计算贡献获取回报的模式(比如现在由搜索引擎获得的广告收入的一部分由计算节点获取的话), 也许会吸引大计算资源(TB 级别存储, 大带宽)的服务器作为骨干节点.

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

@nicoljiang 从商业运营和推广的角度说 Yacy 当然不算"成功". 但它的存活证明, 即使是如此理想化并且不掺杂任何商业因素的搜索引擎项目也有相当的用户群和社区.
个人认为加上合理透明的商业模式, 在现有 P2P 的技术和架构上继续改进, 并不是没有可能实现可与集中式搜索引擎并肩的产品.
另外, 个人重心并不在此. 请勿误会. 此帖仅为有类似想法的提供一个讨论的去处. 比如 https://www.zhihu.com/question/46622280

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

@nicoljiang
是否值得也许要靠后人评判, 不过肯定是有其他人在关注的. 在论文库里搜搜也可以看到 p2p search engine 一直都在研究. 比如这篇最近的"Decentralized Search on Decentralized Web": https://arxiv.org/pdf/1809.00939.pdf

"QueenBee aims to revolutionize the search engine business model by offering incentives to both content providers and peers that participate in QueenBee ’ s page indexing and ranking operations. "

示意图中也有广告收入由计算节点和网站内容提供者分享的商业模式构想.

@xuanwu

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

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

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



说点题外话：

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

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

#35 的 QueenBee 项目, 据了解, 系统设计已完成. 会有一系列论文发表. 预计三个月后开源在 github. 有兴趣的可以持续关注.

@xuanwu 开源了么？

@nicoljiang email 了论文原作者，等回复中

谷歌，90 万台。2011 年
https://www.quora.com/How-many-servers-does-Google-have-1
https://www.datacenterknowledge.com/archives/2011/08/01/report-google-uses-about-900000-servers

曾经做了一个索引 osc,csdn,stackoverflow 等 7 个编程网站数据的搜索引擎。数据压缩后也就几个 G 而已。一台阿里云虚拟机足够

另外一个美国亚马逊，德国亚马逊，日本亚马逊，大部分数据的海淘搜索引擎，大概 7000 万数据。一个月营业额几百万吧，8 核 16G 阿里云虚拟机做均衡。

@encro 专业数据和通用搜索引擎的数据量和负载应该有几个量级的差别吧.

@xuanwu 基本原理（存储结构和索引方式）基本是一样的，所以不存在很大的差别，谷歌百度之类可能性能能提高 10 倍以上，比如利用 GPU，前置缓存层等。