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

[xuanwu]

看到又一个搜索引擎坑( https://www.v2ex.com/t/487957), 不吐不快, 在 2010 年的时候做了个火狐插件 FromWhereToWhere 实现基于 clickstream 对本地浏览历史进行可视化(在新版火狐中已不可用). 当时觉得可以通过它共享结构化和主题化, 并且已经过人工过滤的浏览历史 /网页集合. 如果有足够的共享的数据, 就可以做一个小型搜索引擎, 也许能克服纯计算进行信息提取的一些问题. 当时觉得集中式搜索引擎的问题很多是通病, 而且在搜索算法不公开透明的情况下, 很难建立与最终用户的信任. 白驹过隙, 现在的搜索技术和计算资源的普及程度比那时又不可同日而语.

问题: 最小需要多少物资人力投入支撑一个搜索算法开源透明, 靠社区监督报告(也是公开的)补足算法的错漏, 靠自愿投入的计算资源(抓取+索引+共享)支撑全网数据更新的搜索引擎呢? 假设分布式以及数据本地化的架构可以使搜索流量的绝大部分(比如 99/100)通过访问其他节点而非通过直接访问主站进行(是否实际?)

[yoyohaha]

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

[xuanwu]

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

[abmin521]

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

[whileFalse]

我觉得楼主想多了。

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

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

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

[nicoljiang]

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

[whileFalse]

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

[xuanwu]

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

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

[xuanwu]

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

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

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

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

[nicoljiang]

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

[nicoljiang]

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

[whileFalse]

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

[nicoljiang]

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

[xuanwu]

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

[mythmgn]

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

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


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

[xuanwu]

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

[xuanwu]

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

[xuanwu]

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

[mythmgn]

@xuanwu

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

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

[xuanwu]

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

[wizardforcel]

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