V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  nicoljiang  ›  全部回复第 47 页 / 共 57 页
回复总数  1134
1 ... 43  44  45  46  47  48  49  50  51  52 ... 57  
@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 (是搜索服务的重要收入命脉之一);
2018-09-13 18:38:19 +08:00
回复了 aboutboy 创建的主题 分享创造 想做一个类似百度脑图的平台,有谁感兴趣?
另外,这个帖子更适合「奇思妙想」这个节点吧。
2018-09-13 18:37:53 +08:00
回复了 aboutboy 创建的主题 分享创造 想做一个类似百度脑图的平台,有谁感兴趣?
@aboutboy 这个国外有产品在做(作为增值点)。但卖点本身是非常强大完善的脑图系统。
@whileFalse 有夸大成分。我的意思是你来猜测这个本身没有太大意义,更别说以这种无端揣测为依据的观点论述。
( V 站现在咋这么多牛角尖 er )
2018-09-11 21:23:46 +08:00
回复了 djyde 创建的主题 分享创造 高效的 GraphQL + Ant.Design
虽然个人不是很赞同 GraphQL 的理念,但很支持技术整合、创新。
劝你不要考虑这个了。给你 1000 万台服务器,你也做不了。
@buffge 不管是 Spider 还是 Crawler,实际上指的都是一类的东西。
@whileFalse 每次搜索会有多少台服务器服务,这个东西情况太多了。可能多达几千上万台,也可能少到几台。
@whileFalse
100 台?
百度搜索数量至少是百万台以上( Google 的服务器数量是千万级)。
@Joyboo 你指的是什么框架?
@jiabing520a 真全。不过屏蔽了一些 WinHTTP、HttpClient 之类的,恐怕使用的时候得具体看看场景。
@Leigg 嗯 也有道理。但爬虫名还是不能少,你也可以补充一下 robots 的版本。

@longyujin9 你们都知道 444

@Xrong 好东西,star
@asilin 学习了
@buffge 倒是不认为 UA 能解决所有问题,但理论上比 robots.txt 的适用性更广,且更高效直接。这个观点应该没问题。
@SukkaW
@airyland
@CEBBCAT
1. 不一定所有的都支持
2. 不会立马生效
1 ... 43  44  45  46  47  48  49  50  51  52 ... 57  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2934 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 02:44 · PVG 10:44 · LAX 18:44 · JFK 21:44
Developed with CodeLauncher
♥ Do have faith in what you're doing.