Suggestion(搜索建議)產品和技術

今天來簡單聊聊Suggestion產品

什麼是Suggestion服務？ 一圖勝千言：

當你想要搜索某個長詞語或者一句話輸入部分時，Suggestion服務預測你極大可能的候選項，並羅列出來，供你選擇。

產品的意義：

1. 降低用戶搜索的輸入成本，用戶總是懶惰的,誰能讓用戶最懶惰還能幫他把事辦好，這就是好的產品。當然如果真有一天能用腦電波搜索了，這個產品功能就沒意義了.

2. 為用戶提供提示，因為有部分用戶多一個長片語很有可能只能記住部分。如有部電影叫"心急吃不了熱豆腐"，朋友A推薦給朋友B，只記得"心急吃不了啥"了

3. 提高搜索轉化率，用戶在任何過程中都有可能流失，打字打完"心急吃不了",一個朋友說別看這個了，看<冰與火之歌>吧，可能還差那最後3個字就能轉戰別的電影了

什麼樣的詞應該納入到Suggestion裡面去呢？

如果把所用所有的搜索記錄都作為suggestion服務，那用戶輸入完一個首碼後，就會出現滿屏的詞語；在這種場景下,儘量提供好用的suggestion而保持簡潔的結果的秘訣在於把控數量並提高轉化率,所以一般可以用雙重法則

1. 如果這個首碼的所有搜索詞不超過N個，按轉化概率從大到小排序

2. 如果超過N個, 放棄掉用戶轉化率小於a的搜索詞，按轉化概率從大到小排序

整體技術上怎麼實現呢？

如果你在做一個Suggestion總詞語量較小的產品. (<千萬級)

短平快，直接用小腳本掃每天的用戶搜索日誌，然後根據策略得出整個搜索詞表，放到Mysql中；

查詢直接用  select XXX from TABLE_XXX where SuggestionWords like {QUERY}% 進行查詢

訪問量大怎麼辦?

mysql 的查詢成為瓶頸，在前面加一層緩存，來存儲結果List即可.

訪問量極大怎麼辦？

這裡極大的意思時，一瞬間的某個詞語的緩存未命中（失效或者DB更新後delete）查詢會拖死Mysql

兩個思路

1. mysql加從庫 Master-Slave集群

2. 更新時主動生成緩存，讓前端查詢任何時刻都看不到緩存未命中

如果你在做一個Suggestion總詞語量較大的產品. (>千萬級)

類似的場景我之前遇到的是百度的帳號註冊時的Suggestion, N億的註冊用戶，新用戶上來了想註冊abcd這個帳號，已經被占用了，所以一般推薦abcd作為首碼能用的帳號如abcd1,abcd11等，類似的場景如功能變數名稱註冊服務商的推薦。

技術實現上可以用Tire樹，Tire樹的每個條邊就是每個詞,從非根節點到根節點經過的所有的邊組成了一個詞，如下圖的最長詞dcba

通過這種方式就能對海量基數詞進行Suggestion服務了。

另外tire樹的插入、查找、刪除的時間複雜度都是o(N),N為待插入、查找、刪除字元串的長度。