image.png
360 搜索的百亿级网页搜索引擎架构实现
这个文章讲的挺细致了。
不过还是有几个可以思考的细节。
- 需要一个global的id 生成器，给每个url文档生成一个doc id，放进倒排里。
- 索引库在分片的时候不完全按照hash值，而是有部分重要索引（高质量网站）放在重要分片里，其他的放在普通分片里。
- 倒排索引里面如果按照文章说doc id排序，那page rank是不是就不能保证顺序。那如果一个word对应了1千万个doc，不可能都取出来然后和其他的做交。理论上应该是取出来前1000个？所以page rank高的要尽量用小的doc id？ 所以在给url生成id的时候就把rank高的生成小的doc id？不过这就有额外的要求。
- 分发到每个分片的搜索先做本地的交计，做相关性计算，然后再返回到一个节点做并计算，排序。我觉得这样才比较合理。这每个节点都要做若干并发查询，并发计算，对多线程要求应该是很高的。加入对每个word取出10w个doc，也可以拆成100个线程去分段算吧。这样计算资源索然大了，但是还相应速度会很快。
- 当然这里的广播，一个query会hit到所有的分片。这个读代价还是挺大的。 对于重要索引库可以多等些时间，对于普通索引库，超过一定时间就应该不等待返回了。
全文搜索引擎 ElasticSearch 还是 Solr
这个比较了下目前两个流行的搜索引擎。
全文搜索引擎Elasticsearch，这篇文章给讲透了！
这块讲的比较全，但是对于segment的那一块不详细。
https://blog.csdn.net/smithallenyu/article/details/52789872
这个把概念用英文说了下，更准确也就能帮助理解shard和segment的表达了。
segment实际上是个单独的倒排缩影，不变的。而且会不断的合并。
从原理到应用，Elasticsearch详解
这个讲的更详细点，包括了正排和倒排文件的格式和布局（后面的一些东西没有特别细看）。
和360的架构比较起来，感觉360是不去update已经存在的倒排？一周一个库或者一月一个库？然后其他的更新都在实时库里。
ES的没有那种操作，所以就需要实时的更新，更新很多个segment就会导致索引速度低一些吧，毕竟每个segment都要查一遍。再做合并。
