image.png
360 搜索的百億級網(wǎng)頁搜索引擎架構(gòu)實現(xiàn)
這個文章講的挺細致了蜻韭。
不過還是有幾個可以思考的細節(jié)。
- 需要一個global的id 生成器柿扣，給每個url文檔生成一個doc id肖方，放進倒排里。
- 索引庫在分片的時候不完全按照hash值未状，而是有部分重要索引（高質(zhì)量網(wǎng)站）放在重要分片里俯画，其他的放在普通分片里。
- 倒排索引里面如果按照文章說doc id排序司草，那page rank是不是就不能保證順序活翩。那如果一個word對應(yīng)了1千萬個doc，不可能都取出來然后和其他的做交翻伺。理論上應(yīng)該是取出來前1000個材泄？所以page rank高的要盡量用小的doc id？ 所以在給url生成id的時候就把rank高的生成小的doc id吨岭？不過這就有額外的要求拉宗。
- 分發(fā)到每個分片的搜索先做本地的交計，做相關(guān)性計算辣辫，然后再返回到一個節(jié)點做并計算旦事，排序。我覺得這樣才比較合理急灭。這每個節(jié)點都要做若干并發(fā)查詢姐浮，并發(fā)計算，對多線程要求應(yīng)該是很高的葬馋。加入對每個word取出10w個doc卖鲤，也可以拆成100個線程去分段算吧肾扰。這樣計算資源索然大了，但是還相應(yīng)速度會很快蛋逾。
- 當(dāng)然這里的廣播集晚，一個query會hit到所有的分片。這個讀代價還是挺大的区匣。 對于重要索引庫可以多等些時間偷拔，對于普通索引庫，超過一定時間就應(yīng)該不等待返回了亏钩。
全文搜索引擎 ElasticSearch 還是 Solr
這個比較了下目前兩個流行的搜索引擎莲绰。
全文搜索引擎Elasticsearch，這篇文章給講透了姑丑！
這塊講的比較全钉蒲，但是對于segment的那一塊不詳細。
https://blog.csdn.net/smithallenyu/article/details/52789872
這個把概念用英文說了下彻坛，更準(zhǔn)確也就能幫助理解shard和segment的表達了。
segment實際上是個單獨的倒排縮影踏枣，不變的昌屉。而且會不斷的合并。
從原理到應(yīng)用茵瀑，Elasticsearch詳解
這個講的更詳細點间驮，包括了正排和倒排文件的格式和布局（后面的一些東西沒有特別細看）。
和360的架構(gòu)比較起來马昨，感覺360是不去update已經(jīng)存在的倒排竞帽？一周一個庫或者一月一個庫？然后其他的更新都在實時庫里鸿捧。
ES的沒有那種操作屹篓，所以就需要實時的更新，更新很多個segment就會導(dǎo)致索引速度低一些吧匙奴，畢竟每個segment都要查一遍堆巧。再做合并。
