如何迅猛的實現(xiàn)搜索需求

一、緣起

---

《深入淺出搜索架構（上篇）》詳細介紹了：

（1）全網(wǎng)搜索引擎架構與流程

（2）站內(nèi)搜索引擎架構與流程

（3）搜索原理與核心數(shù)據(jù)結構

本文重點介紹：

（4）流量數(shù)據(jù)量由小到大，常見搜索方案與架構變遷

（5）數(shù)據(jù)量、并發(fā)量、擴展性方案

二、檢索需求的滿足與架構演進

---

任何互聯(lián)網(wǎng)需求，或多或少有檢索需求，還是以58同城的帖子業(yè)務場景為例，帖子的標題，帖子的內(nèi)容有很強的用戶檢索需求，在業(yè)務、流量、并發(fā)量逐步遞增的各個階段，應該如何實現(xiàn)檢索需求呢？

原始階段-LIKE

數(shù)據(jù)在數(shù)據(jù)庫中可能是這么存儲的：

t_tiezi(tid, title, content)

滿足標題、內(nèi)容的檢索需求可以通過LIKE實現(xiàn)：

select tid from t_tiezi where content like ‘%天通苑%’

能夠快速滿足業(yè)務需求，存在的問題也顯而易見：

（1）效率低，每次需要全表掃描，計算量大，并發(fā)高時cpu容易100%

（2）不支持分詞

初級階段-全文索引

如何快速提高效率，支持分詞，并對原有系統(tǒng)架構影響盡可能小呢，第一時間想到的是建立全文索引：

alter table t_tiezi add fulltext(title,content)

使用match和against實現(xiàn)索引字段上的查詢需求。

全文索引能夠快速實現(xiàn)業(yè)務上分詞的需求，并且快速提升性能（分詞后倒排，至少不要全表掃描了），但也存在一些問題：

（1）只適用于MyISAM

（2）由于全文索引利用的是數(shù)據(jù)庫特性，搜索需求和普通CURD需求耦合在數(shù)據(jù)庫中：檢索需求并發(fā)大時，可能影響CURD的請求；CURD并發(fā)大時，檢索會非常的慢；

（3）數(shù)據(jù)量達到百萬級別，性能還是會顯著降低，查詢返回時間很長，業(yè)務難以接受

（4）比較難水平擴展

中級階段-開源外置索引

為了解決全文索的局限性，當數(shù)據(jù)量增加到大幾百萬，千萬級別時，就要考慮外置索引了。外置索引的核心思路是：索引數(shù)據(jù)與原始數(shù)據(jù)分離，前者滿足搜索需求，后者滿足CURD需求，通過一定的機制（雙寫，通知，定期重建）來保證數(shù)據(jù)的一致性。

原始數(shù)據(jù)可以繼續(xù)使用Mysql來存儲，外置索引如何實施？Solr，Lucene，ES都是常見的開源方案。

樓主強烈推薦ES（ElasticSearch），原因是Lucene雖好，但始終有一些不足：

（1）Lucene只是一個庫，潛臺詞是，需要自己做服務，自己實現(xiàn)高可用/可擴展/負載均衡等復雜特性

（2）Lucene只支持Java，如果要支持其他語言，還是得自己做服務

（3）Lucene不友好，這是很致命的，非常復雜，使用者往往需要深入了解搜索的知識來理解它的工作原理，為了屏蔽其復雜性，一個辦法是自己做服務

…

…

為了改善Lucene的各項不足，解決方案都是“封裝一個接口友好的服務，屏蔽底層復雜性”，于是有了ES：

（1）ES是一個以Lucene為內(nèi)核來實現(xiàn)搜索功能，提供REStful接口的服務

（2）ES能夠支持很大數(shù)據(jù)量的信息存儲，支持很高并發(fā)的搜索請求

（3）ES支持集群，向使用者屏蔽高可用/可擴展/負載均衡等復雜特性

目前58到家使用ES作為核心，實現(xiàn)了自己的搜索服務平臺，能夠通過在平臺上簡單的配置，實現(xiàn)業(yè)務方的搜索需求。

搜索服務數(shù)據(jù)量最大的“接口耗時數(shù)據(jù)收集”需求，數(shù)據(jù)量大概在7億左右；并發(fā)量最大的“經(jīng)緯度，地理位置搜索”需求，線上平均并發(fā)量大概在600左右，壓測數(shù)據(jù)并發(fā)量在6000左右。

高級階段-自研搜索引擎

當數(shù)據(jù)量進一步增加，達到10億、100億數(shù)據(jù)量；并發(fā)量也進一步增加，達到每秒10萬吞吐；業(yè)務個性也逐步增加的時候，就需要自研搜索引擎了，定制化實現(xiàn)搜索內(nèi)核了。

三、數(shù)據(jù)量、并發(fā)量、擴展性方案

---

到了定制化自研搜索引擎的階段，超大數(shù)據(jù)量、超高并發(fā)量為設計重點，為了達到“無限容量、無限并發(fā)”的需求，架構設計需要重點考慮“擴展性”，力爭做到：增加機器就能擴容（數(shù)據(jù)量+并發(fā)量）。

（1）上層proxy（粉色）是接入集群，為對外門戶，接受搜索請求，其無狀態(tài)性能夠保證增加機器就能擴充proxy集群性能

（2）中層merger（淺藍色）是邏輯集群，主要用于實現(xiàn)搜索合并，以及打分排序，業(yè)務相關的rank就在這一層實現(xiàn)，其無狀態(tài)性也能夠保證增加機器就能擴充merger集群性能

（3）底層searcher（暗紅色大框）是檢索集群，服務和索引數(shù)據(jù)部署在同一臺機器上，服務啟動時可以加載索引數(shù)據(jù)到內(nèi)存，請求訪問時從內(nèi)存中l(wèi)oad數(shù)據(jù)，訪問速度很快

（3.1）為了滿足數(shù)據(jù)容量的擴展性，索引數(shù)據(jù)進行了水平切分，增加切分份數(shù)，就能夠無限擴展性能，如上圖searcher分為了4組

（3.2）為了滿足一份數(shù)據(jù)的性能擴展性，同一份數(shù)據(jù)進行了冗余，理論上做到增加機器就無限擴展性能，如上圖每組searcher又冗余了2份

四、總結

---

為了滿足搜索業(yè)務的需求，隨著數(shù)據(jù)量和并發(fā)量的增長，搜索架構一般會經(jīng)歷這么幾個階段：

（1）原始階段-LIKE

（2）初級階段-全文索引

（3）中級階段-開源外置索引

（4）高級階段-自研搜索引擎

五、下章預告

---

實時搜索引擎核心技術，站長發(fā)布1個新網(wǎng)頁，Google如何做到15分鐘后檢索出來。