就是这么迅猛的实现搜索需求--转
一、緣起
《深入淺出搜索架構(gòu)(上篇)》詳細(xì)介紹了:
(1)全網(wǎng)搜索引擎架構(gòu)與流程
(2)站內(nèi)搜索引擎架構(gòu)與流程
(3)搜索原理與核心數(shù)據(jù)結(jié)構(gòu)
?
本文重點介紹:
(4)流量數(shù)據(jù)量由小到大,常見搜索方案與架構(gòu)變遷
(5)數(shù)據(jù)量、并發(fā)量、擴展性方案
?
只要業(yè)務(wù)有檢索需求,本文一定對你有幫助。
?
二、檢索需求的滿足與架構(gòu)演進(jìn)
任何互聯(lián)網(wǎng)需求,或多或少有檢索需求,還是以58同城的帖子業(yè)務(wù)場景為例,帖子的標(biāo)題,帖子的內(nèi)容有很強的用戶檢索需求,在業(yè)務(wù)、流量、并發(fā)量逐步遞增的各個階段,應(yīng)該如何實現(xiàn)檢索需求呢?
?
原始階段-LIKE
數(shù)據(jù)在數(shù)據(jù)庫中可能是這么存儲的:
t_tiezi(tid, title, content)
滿足標(biāo)題、內(nèi)容的檢索需求可以通過LIKE實現(xiàn):
select tid from t_tiezi where content like ‘%天通苑%’
?
能夠快速滿足業(yè)務(wù)需求,存在的問題也顯而易見:
(1)效率低,每次需要全表掃描,計算量大,并發(fā)高時cpu容易100%
(2)不支持分詞
?
初級階段-全文索引
如何快速提高效率,支持分詞,并對原有系統(tǒng)架構(gòu)影響盡可能小呢,第一時間想到的是建立全文索引:
alter table t_tiezi add fulltext(title,content)
使用match和against實現(xiàn)索引字段上的查詢需求。
?
全文索引能夠快速實現(xiàn)業(yè)務(wù)上分詞的需求,并且快速提升性能(分詞后倒排,至少不要全表掃描了),但也存在一些問題:
(1)只適用于MyISAM
(2)由于全文索引利用的是數(shù)據(jù)庫特性,搜索需求和普通CURD需求耦合在數(shù)據(jù)庫中:檢索需求并發(fā)大時,可能影響CURD的請求;CURD并發(fā)大時,檢索會非常的慢;
(3)數(shù)據(jù)量達(dá)到百萬級別,性能還是會顯著降低,查詢返回時間很長,業(yè)務(wù)難以接受
(4)比較難水平擴展
?
中級階段-開源外置索引
為了解決全文索的局限性,當(dāng)數(shù)據(jù)量增加到大幾百萬,千萬級別時,就要考慮外置索引了。外置索引的核心思路是:索引數(shù)據(jù)與原始數(shù)據(jù)分離,前者滿足搜索需求,后者滿足CURD需求,通過一定的機制(雙寫,通知,定期重建)來保證數(shù)據(jù)的一致性。
?
原始數(shù)據(jù)可以繼續(xù)使用Mysql來存儲,外置索引如何實施?Solr,Lucene,ES都是常見的開源方案。
樓主強烈推薦ES(ElasticSearch),原因是Lucene雖好,但始終有一些不足:
(1)Lucene只是一個庫,潛臺詞是,需要自己做服務(wù),自己實現(xiàn)高可用/可擴展/負(fù)載均衡等復(fù)雜特性
(2)Lucene只支持Java,如果要支持其他語言,還是得自己做服務(wù)
(3)Lucene不友好,這是很致命的,非常復(fù)雜,使用者往往需要深入了解搜索的知識來理解它的工作原理,為了屏蔽其復(fù)雜性,一個辦法是自己做服務(wù)
…
…
?
為了改善Lucene的各項不足,解決方案都是“封裝一個接口友好的服務(wù),屏蔽底層復(fù)雜性”,于是有了ES:
(1)ES是一個以Lucene為內(nèi)核來實現(xiàn)搜索功能,提供REStful接口的服務(wù)
(2)ES能夠支持很大數(shù)據(jù)量的信息存儲,支持很高并發(fā)的搜索請求
(3)ES支持集群,向使用者屏蔽高可用/可擴展/負(fù)載均衡等復(fù)雜特性
?
目前58到家使用ES作為核心,實現(xiàn)了自己的搜索服務(wù)平臺,能夠通過在平臺上簡單的配置,實現(xiàn)業(yè)務(wù)方的搜索需求。
搜索服務(wù)數(shù)據(jù)量最大的“接口耗時數(shù)據(jù)收集”需求,數(shù)據(jù)量大概在7億左右;并發(fā)量最大的“經(jīng)緯度,地理位置搜索”需求,線上平均并發(fā)量大概在600左右,壓測數(shù)據(jù)并發(fā)量在6000左右。
?
結(jié)論:ES完全能滿足10億數(shù)據(jù)量,5k吞吐量的常見搜索業(yè)務(wù)需求,強烈推薦。
?
高級階段-自研搜索引擎
當(dāng)數(shù)據(jù)量進(jìn)一步增加,達(dá)到10億、100億數(shù)據(jù)量;并發(fā)量也進(jìn)一步增加,達(dá)到每秒10萬吞吐;業(yè)務(wù)個性也逐步增加的時候,就需要自研搜索引擎了,定制化實現(xiàn)搜索內(nèi)核了。
?
三、數(shù)據(jù)量、并發(fā)量、擴展性方案
到了定制化自研搜索引擎的階段,超大數(shù)據(jù)量、超高并發(fā)量為設(shè)計重點,為了達(dá)到“無限容量、無限并發(fā)”的需求,架構(gòu)設(shè)計需要重點考慮“擴展性”,力爭做到:增加機器就能擴容(數(shù)據(jù)量+并發(fā)量)。
?
58同城的自研搜索引擎E-search初步架構(gòu)圖如下:
?
(1)上層proxy(粉色)是接入集群,為對外門戶,接受搜索請求,其無狀態(tài)性能夠保證增加機器就能擴充proxy集群性能
(2)中層merger(淺藍(lán)色)是邏輯集群,主要用于實現(xiàn)搜索合并,以及打分排序,業(yè)務(wù)相關(guān)的rank就在這一層實現(xiàn),其無狀態(tài)性也能夠保證增加機器就能擴充merger集群性能
(3)底層searcher(暗紅色大框)是檢索集群,服務(wù)和索引數(shù)據(jù)部署在同一臺機器上,服務(wù)啟動時可以加載索引數(shù)據(jù)到內(nèi)存,請求訪問時從內(nèi)存中l(wèi)oad數(shù)據(jù),訪問速度很快
(3.1)為了滿足數(shù)據(jù)容量的擴展性,索引數(shù)據(jù)進(jìn)行了水平切分,增加切分份數(shù),就能夠無限擴展性能,如上圖searcher分為了4組
(3.2)為了滿足一份數(shù)據(jù)的性能擴展性,同一份數(shù)據(jù)進(jìn)行了冗余,理論上做到增加機器就無限擴展性能,如上圖每組searcher又冗余了2份
?
如此設(shè)計,真正做到做到增加機器就能承載更多的數(shù)據(jù)量,響應(yīng)更高的并發(fā)量。
?
三、總結(jié)
為了滿足搜索業(yè)務(wù)的需求,隨著數(shù)據(jù)量和并發(fā)量的增長,搜索架構(gòu)一般會經(jīng)歷這么幾個階段:
(1)原始階段-LIKE
(2)初級階段-全文索引
(3)中級階段-開源外置索引
(4)高級階段-自研搜索引擎
?
你的搜索架構(gòu)到了哪一個階段?數(shù)據(jù)量、并發(fā)量、好的經(jīng)驗歡迎分享?
?
歡迎留言,有問必答。
如果有收獲,歡迎幫轉(zhuǎn)。
?
四、下章預(yù)告
實時搜索引擎核心技術(shù),站長發(fā)布1個新網(wǎng)頁,Google如何做到15分鐘后檢索出來。?
==【(中)完】==
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/7550098.html
總結(jié)
以上是生活随笔為你收集整理的就是这么迅猛的实现搜索需求--转的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 一个细节翔实、可供参考的支付体系架构演进
- 下一篇: 百度如何能实时检索到15分钟前新生成的网