使用ElasticSearch搭建動態排序引擎

本來打算至少一月一更的，結果寫完第一篇後爆忙了一段時間（眼神死）...

在這個專欄里，我不會翻譯官方文檔。所有關於ES本身的介紹，推薦直接看英文版官方文檔，或者google之。ES本身以驚人的速度在迭代，現在的中文材料很容易就跟不上最新版的節奏。特別是5.0出來之後，會有非常大的變化。

在這個專欄里，我會根據自己的實戰經驗，寫一下Elastic Search全家桶（官方自稱為Elastic Stack）的應用。從年初到現在，我個人也從ES吹，到ES與Sphinx混用，到了自造輪子的階段。ES很好用，也有坑；ES不僅僅是一個搜索引擎，配合其全家桶，可以干更多事情。我相信，告訴大家ES可以用來幹嘛，比起搬運文檔要更有價值。

第二篇文章，準備寫一下Elastic Search的一個經典、簡單的應用場景：動態排序引擎。

舉個例子，現在你做了一個UGC圖床產品，需要將用戶最新PO的圖按某種順序（例如時間或熱度）排序展示出來。用戶發了圖之後，在「最新」那一頁一刷新，就能看到他/她剛發的圖，然後可以一直往下翻。圖片可能存在不同的TAG（例如「妹子圖」、「無聊圖」，甚至做二級的細分）。等等，我才不是在說某網站呢，這是個很常見的需求好么！

如果你用MySQL來實現這個需求，可以是可以。不過，隨著圖片數量和查詢請求的增加，很快就會出現性能瓶頸，產生大量的慢查詢。你需要一個高性能動態排序引擎，有以下的功能：

? 動態索引，即可以隨時增刪查改條目；

? 排序，輸入from和size（從哪到哪），根據某個數值（熱度或插入時間戳），倒序排序、輸出結果；

? Filter，例如根據TAG篩選圖片；

假定圖片是先存MySQL、再同步去ES。用MySQL存數據和保證原子性，用ES來頂查詢請求。在ES裡面，你可以這麼設計索引結構：

{n "properties": {n "id": {n "type": "long"n },n "tags": {n "type": "string"n },n "hot": {n "type": "double"n },n "new": {n "type": "double"n },n "update_time": {n "type": "date",n "format": "epoch_second"n },n "is_searchable": {n "type": "short"n }n }n}n

id：即MySQL的id，使用AUTO_INCREMENT保證唯一性。

tags：即「妹子圖」、「無聊圖」這樣的TAG，空格隔開，確保ES默認分詞器可以工作。

hot：熱度數據，例如妹子圖的OO數量（甚至威爾遜區間啥的）。

new：即上傳時間戳。

update_time：等於new。這裡是Kibana里看數用的（一定要有個date屬性）。

is_searchable：0或1，默認0，1的時候才能被搜出來。用於自動鑒黃、人工去黃啥的。

每次更新數據，同步更新到ES裡面，這個需求就做好了。什麼，這麼簡單？是的，ES把剩下的事情都完成了。

搜的時候這麼搜：

{n "from": 0,n "size": 10,n "query": {n "filtered": {n "query": {ntt"bool": {n "must": [n {n "term": {n "tags": {n "value": "妹子圖"n }n }n }n ]n }nt },n "filter": {n "or": [n {n "and": [n {nttt "term": {n "is_searchable": 1n }n }nttt]nt }ntt]n }n }n },n "sort": {n "hot": {nt "order": "desc"nt}n }n}n

稍微解釋一下這個語句。query裡面最簡單的做法是填入`"match_all": {}`，這樣可以搜所有東西出來。filter先一層or再套一層and，是便於擴展的一個寫法。

這個語句，可以把TAG=「妹子圖」的所有內容，按熱度倒序排序（嘖嘖）。注意，上面的語句並非性能最佳的寫法，如果妹子圖非常高頻，就不應用must query搜索TAG，而是應該用type或者filter來過濾。

這就是我為啥那麼喜歡用Elastic Search。ES是動態索引，新插入的數據馬上就可以被搜出來；強大的DSL，我能想到的查詢基本都能做到。

動態排序引擎這個需求，用ES幾下子就能搞定，性能還不差。