在過去的項(xiàng)目上，總會遇到很多關(guān)于某個字段的模糊查詢的需求，一般對于客戶來說他會認(rèn)為這個功能很簡單，可能1天就可以完成這樣一個功能，但是現(xiàn)實(shí)總是殘酷的，往往這個功能是非常復(fù)雜的，今天我們就來聊聊一個關(guān)于姓名模糊搜索的功能，在不同的場景是如何決策的。

模糊搜索

模糊搜索主要用于用戶搜索意圖不明確或者數(shù)據(jù)較少想返回更多查詢結(jié)果的場景,在說技術(shù)上如何實(shí)現(xiàn)這個模糊搜索的場景的時(shí)候，我想先聊聊現(xiàn)實(shí)生活中的場景

現(xiàn)實(shí)生活中的場景

我們在看書的時(shí)候，如果讓我們在圖1-1圖片中找出產(chǎn)品兩個字出現(xiàn)多少次，我們的大腦會把所有的字過一遍，然后得出一個結(jié)果，這個時(shí)間可能也就1分鐘左右。

1-1.png

我們把場景更換一下，如果讓我們在圖1-2圖片中找出產(chǎn)品"兩個字出現(xiàn)的位置，我們的大腦依然會把所有的字過一遍，然后記錄產(chǎn)品"這兩個字出現(xiàn)的位置，然后得出一個結(jié)果，但是這個時(shí)間就不是一分鐘就可以搞定的了，當(dāng)然最終我們可以把這個結(jié)果集記錄下來，下次如果還需要查產(chǎn)品"兩個字，我們就不用重復(fù)上一步的步驟，而我們記錄這個動作其實(shí)就是我們常說的緩存。

1-2.png

但是如果我們不想統(tǒng)計(jì)產(chǎn)品這兩個字出現(xiàn)的次數(shù)，而是找出架構(gòu)這個兩個字出現(xiàn)多少次，我們該怎么辦？看來只能在把書讀一遍，然后記錄下所有架構(gòu)這個兩個字出現(xiàn)的次數(shù)了。前面提到的記錄次數(shù)這件事可以記錄到一張紙上，但是我們總不能通過每次閱讀一本書的方式來記錄這個次數(shù)，或者查找某個詞出現(xiàn)的地方，給我們所指引，這種效率太慢了，我們能不能把這些重要的信息提前寫到書上，方便讀者查詢呢，事實(shí)上是可以的，就是我們常見的目錄，附錄，以及索引，如圖1-3所示

1-3.png

而索引種類就很多了，我們在看不同的書有不同的索引，比較經(jīng)典的書籍就是我們小時(shí)候?qū)W習(xí)的新華字典，他根據(jù)不同的場景，把索引創(chuàng)建了不同類型例如拼音(圖1-4)，偏旁部首(圖1-5）,筆畫(圖-1-6)索引等

1-4(拼音索引).png

1-5(偏旁部首索引).png

1-6(筆畫索引).png

而這個神奇的設(shè)計(jì)就可以大大減少我們大腦通過全書查找某個關(guān)鍵信息的時(shí)間，所以理論上我們只要把所有的關(guān)鍵規(guī)則都變成索引頁存在書的目錄中，就可以很快查詢到我們想要查詢的信息，這一設(shè)計(jì)不僅深深的融入到我們現(xiàn)實(shí)的生活，而且也在軟件系統(tǒng)上發(fā)光發(fā)熱。

軟件系統(tǒng)上中的場景

互聯(lián)網(wǎng)也常常有模糊查找的需求，但是這個需求針對的是軟件系統(tǒng)，而不再是現(xiàn)實(shí)生活中的書，比如在一個社區(qū)APP上按照昵稱查找某個用戶，在電商網(wǎng)站上搜索我們想要查找的商品(圖2-1)，而這和我們現(xiàn)實(shí)生活中所查找的的算法是一摸一樣的。

2-1.png

如圖2-1所示我通過“sw”它匹配到的結(jié)果有“switch,三文魚,絲襪，數(shù)位板..等，他們分別到了
1.拼音首字母索引:三文魚(san wen yu),絲襪(si wa)
2.英文前綴索引: switch(switch)
而軟件系統(tǒng)中的索引要遠(yuǎn)遠(yuǎn)多余上述兩種，比如還有后綴搜索(是指搜索以指定后綴結(jié)尾的內(nèi)容的檢索),
單字或單字母搜索(模糊搜索支持單字或單字母搜索),短語查詢(連續(xù)的字母和數(shù)字可以用短語查詢)等，但這些無一例外都是建立在我們大腦中的邏輯認(rèn)知所擴(kuò)展出來了，也都逃脫不了現(xiàn)實(shí)場景，因?yàn)橄到y(tǒng)畢竟服務(wù)于人。

軟件系統(tǒng)如果沒有上述的索引，實(shí)際上也是能工作的，這就回歸到了文章開頭所說的，一個關(guān)于姓名的搜索，計(jì)算機(jī)CPU掃描一本書的時(shí)間可是要比人腦快的不是一個數(shù)量級，就讓他掃描不就行了嘛，個人理解這句話只能說對了一半，軟件系統(tǒng)里的計(jì)算機(jī)的算力雖然很高，但是軟件系統(tǒng)里的一本書(數(shù)據(jù))可能要比現(xiàn)實(shí)生活中一本厚幾萬倍，這樣的話計(jì)算機(jī)掃描一本書所消耗的時(shí)間也會增加，在加上同一時(shí)間里，如果每個客戶有不同的搜索需求，就需要計(jì)算機(jī)同時(shí)對數(shù)據(jù)做掃描，這樣即便是計(jì)算機(jī)也會很累的，這就會導(dǎo)致一些常見的問題出現(xiàn)，例如高峰時(shí)間段系統(tǒng)累壞了，垮掉了，或者響應(yīng)很慢了(請求很久才返回查詢結(jié)果)。當(dāng)然如果軟件系統(tǒng)中這本書如果很薄，那么對計(jì)算機(jī)而言就很簡單，因?yàn)樗梢燥w快的掃描完得到結(jié)果。

既然結(jié)論說完了，咱們就看看不同的數(shù)據(jù)場景，都有哪些可以選型的技術(shù)，最終完成這樣一個簡單的搜索功能，是不是真的1天就可以完成。

數(shù)據(jù)庫

如果說你開發(fā)一個姓名搜索的功能對應(yīng)數(shù)據(jù)庫是數(shù)據(jù)庫例如mysql，那么恭喜你，對于模糊搜索的需求，你只能支持到前綴索引階段，因?yàn)閙ysql原生只是支持到前綴索引,否則就要面臨全表掃描的性能問題，或者應(yīng)用相對復(fù)雜的全文索引，但是你要忍受查詢精度問題，而這個問題往往是業(yè)務(wù)無法忍受的。如果數(shù)據(jù)量很小，那無所謂，我們就任由它全表掃描吧，1天完成這個功能還真的可以。

你可能會考慮使用文檔類數(shù)據(jù)庫例如mongodb，但是往往業(yè)務(wù)系統(tǒng)不會優(yōu)先考慮使用文檔數(shù)據(jù)庫，而如果部分業(yè)務(wù)拿到文檔里，也要考慮的成本，1天完成是有點(diǎn)難的

搜索引擎

在使用數(shù)據(jù)庫搜索時(shí)，我們更多的是基于「精確匹配」的搜索，但是數(shù)據(jù)庫畢竟只是個存儲的工具，所以想追尋大量數(shù)據(jù)「相關(guān)性匹配」的查詢速度，就必須有強(qiáng)大的文檔索引支持，例如偏旁部首匹配，多音字匹配，語意匹配等就需要用到搜索引擎比如Elasticsearch，原理就是把數(shù)據(jù)庫的相關(guān)信息傳給搜索引擎，他會幫你把數(shù)據(jù)相關(guān)的索引全部創(chuàng)建好，這樣就可以滿足豐富的搜索需求，但這個成本是不可能1天完成的。

所以最終回到文章開頭，如果業(yè)務(wù)人員說這個查詢功能我必須要，是不是可以快速完成這個功能的時(shí)候，希望你可以根據(jù)現(xiàn)實(shí)情況考慮清楚后在答應(yīng)他，否則你將會把自己陷入深淵。