搜索智能提示suggestion

題目詳情：百度搜索框中，輸入“北京”，搜索框下面會以北京為前綴，展示“北京愛情故事”、“北京公交”、“北京醫院”等等搜索詞，輸入“結構之”，會提示“結構之法”，“結構之法 算法之道”等搜索詞。
請問，如何設計此系統，使得空間和時間復雜度盡量低。

題目分析：本題來源于去年2012年百度的一套實習生筆試題中的系統設計題（為尊重愿題，本章主要使用百度搜索引擎展開論述，而不是google等其它搜索引擎，但原理不會差太多。然脫離本題，平時搜的時候，鼓勵用...），題目比較開放，考察的目的在于看應聘者解決問題的思路是否清晰明確，其次便是看能考慮到多少細節。

我去年整理此題的時候，曾簡單解析過，提出的方法是：

直接上Trie樹「Trie樹的介紹見：從Trie樹（字典樹）談到后綴樹」 + ?TOP K「hashmap+堆，hashmap+堆 統計出如10個近似的熱詞，也就是說，只存與關鍵詞近似的比如10個熱詞」

方法就是這樣子的：Trie樹+TOP K算法，但在實際中，真的只要Trie樹 + TOP K算法就夠了么，有什么需要考慮的細節？OK，請看下文娓娓道來。

解法一、Trie樹 + TOP K

步驟一、trie樹存儲前綴后綴

若看過博客內這篇介紹Trie樹和后綴樹的文章http://blog.csdn.net/v_july_v/article/details/6897097的話，應該就能對trie樹有個大致的了解，為示本文完整性，引用下原文內容，如下：

“1.1、什么是Trie樹

?Trie樹，即字典樹，又稱單詞查找樹或鍵樹，是一種樹形結構，是一種哈希樹的變種。典型應用是用于統計和排序大量的字符串（但不僅限于字符串），所以經常被搜索引擎系統用于文本詞頻統計。它的優點是：最大限度地減少無謂的字符串比較，查詢效率比哈希表高。

?Trie的核心思想是空間換時間。利用字符串的公共前綴來降低查詢時間的開銷以達到提高效率的目的。
它有3個基本性質：

根節點不包含字符，除根節點外每一個節點都只包含一個字符。

從根節點到某一節點，路徑上經過的字符連接起來，為該節點對應的字符串。

每個節點的所有子節點包含的字符都不相同。

1.2、樹的構建

舉個在網上流傳頗廣的例子，如下：

題目：給你100000個長度不超過10的單詞。對于每一個單詞，我們要判斷他出沒出現過，如果出現了，求第一次出現在第幾個位置。

分析：這題當然可以用hash來解決，但是本文重點介紹的是trie樹，因為在某些方面它的用途更大。比如說對于某一個單詞，我們要詢問它的前綴是否出現過。這樣hash就不好搞了，而用trie還是很簡單。

現在回到例子中，如果我們用最傻的方法，對于每一個單詞，我們都要去查找它前面的單詞中是否有它。那么這個算法的復雜度就是O(n^2)。顯然對于100000的范圍難以接受?，F在我們換個思路想。假設我要查詢的單詞是abcd，那么在他前面的單詞中，以b，c，d，f之類開頭的我顯然不必考慮。而只要找以a開頭的中是否存在abcd就可以了。同樣的，在以a開頭中的單詞中，我們只要考慮以b作為第二個字母的，一次次縮小范圍和提高針對性，這樣一個樹的模型就漸漸清晰了。

好比假設有b，abc，abd，bcd，abcd，efg，hii 這6個單詞，我們構建的樹就是如下圖這樣的：

當時第一次看到這幅圖的時候，便立馬感到此樹之不凡構造了。單單從上幅圖便可窺知一二，好比大海搜人，立馬就能確定東南西北中的到底哪個方位，如此迅速縮小查找的范圍和提高查找的針對性，不失為一創舉。

ok，如上圖所示，對于每一個節點，從根遍歷到他的過程就是一個單詞，如果這個節點被標記為紅色，就表示這個單詞存在，否則不存在。

那么，對于一個單詞，我只要順著他從根走到對應的節點，再看這個節點是否被標記為紅色就可以知道它是否出現過了。把這個節點標記為紅色，就相當于插入了這個單詞。”

借用上面的圖，當用戶輸入前綴a的時候，搜索框可能會展示以a為前綴的“abcd”，“abd”等關鍵詞，再當用戶輸入前綴b的時候，搜索框下面可能會提示以b為前綴的“bcd”等關鍵詞，如此，實現搜索引擎智能提示suggestion的第一個步驟便清晰了，即用trie樹存儲大量字符串，當前綴固定時，存儲相對來說比較熱的后綴。那又如何統計熱詞呢？請看下文步驟二、TOP K算法統計熱詞。

?步驟二、TOP K算法統計熱詞

當每個搜索引擎輸入一個前綴時，下面它只會展示0~10個候選詞，但若是碰到那種候選詞很多的時候，如何取舍，哪些展示在前面，哪些展示在后面？這就是一個搜索熱度的問題。

如本題描述所說，在去年的這個時候，當我在搜索框內搜索“北京”時，它下面會提示以“北京”為前綴的諸如“北京愛情故事”，“北京公交”，“北京醫院”，且“ 北京愛情故事”展示在第一個：

為何輸入“北京”，會首先提示“北京愛情故事”呢？因為去年的這個時候，正是《北京愛情故事》這部電影上映正火的時候（其上映日期為2012年1月8日，火了至少一年），那個時候大家都一個勁的搜索這部電影的相關信息，當10個人中輸入“北京”后，其中有8個人會繼續敲入“愛情故事”（連起來就是“北京愛情故事”）的時候，搜索引擎對此當然不會無動于衷。

也就是說，搜索引擎知道了這個時間段，大家都在瘋狂查找北京愛情故事，故當用戶輸入以“北京”為前綴的時候，搜索引擎猜測用戶有80%的機率是要查找“北京愛情故事”，故把“北京愛情故事”在下面提示出來，并放在第一個位置上。

但為何今年這個時候再次搜索“北京”的時候，它展示出來的詞不同了呢？

原因在于隨著時間變化，人們對北京愛情故事這部影片的關注度逐漸下降，與此同時，又出現了新的熱詞，新的電影，故現在雖然同樣是輸入“北京”，后面提示的詞也相應跟著起了變化。那解決這個問題的辦法是什么呢？如開頭所說：定期分析某段時間內的人們搜索的關鍵詞，統計出搜索次數比較多的熱詞，繼而當用戶輸入某個前綴時，優先展示熱詞。

故說白了，這個問題的第二個步驟便是統計熱詞，我們把統計熱詞的方法稱為TOP K算法，此算法的應用場景便是此文http://blog.csdn.net/v_july_v/article/details/7382693中的第2個問題，再次原文引用：

“尋找熱門查詢，300萬個查詢字符串中統計最熱門的10個查詢

原題：搜索引擎會通過日志文件把用戶每次檢索使用的所有檢索串都記錄下來，每個查詢串的長度為1-255字節。假設目前有一千萬個記錄（這些查詢串的重復度比較高，雖然總數是1千萬，但如果除去重復后，不超過3百萬個。一個查詢串的重復度越高，說明查詢它的用戶越多，也就是越熱門），請你統計最熱門的10個查詢串，要求使用的內存不能超過1G。

解答：由上面第1題，我們知道，數據大則劃為小的，如一億個Ip求Top 10，可先%1000將ip分到1000個小文件中去，并保證一種ip只出現在一個文件中，再對每個小文件中的ip進行hashmap計數統計并按數量排序，最后歸并或者最小堆依次處理每個小文件的top10以得到最后的結果。

但如果數據規模本身就比較小，能一次性裝入內存呢？比如這第2題，雖然有一千萬個Query，但是由于重復度比較高，因此事實上只有300萬的Query，每個Query255Byte，因此我們可以考慮把他們都放進內存中去（300萬個字符串假設沒有重復，都是最大長度，那么最多占用內存3M*1K/4=0.75G。所以可以將所有字符串都存放在內存中進行處理），而現在只是需要一個合適的數據結構，在這里，HashTable絕對是我們優先的選擇。

所以我們放棄分而治之/hash映射的步驟，直接上hash統計，然后排序。So，針對此類典型的TOP K問題，采取的對策往往是：hashmap + 堆。如下所示：

hashmap統計：先對這批海量數據預處理。具體方法是：維護一個Key為Query字串，Value為該Query出現次數的HashTable，即hash_map(Query，Value)，每次讀取一個Query，如果該字串不在Table中，那么加入該字串，并且將Value值設為1；如果該字串在Table中，那么將該字串的計數加一即可。最終我們在O(N)的時間復雜度內用Hash表完成了統計；

堆排序：第二步、借助堆這個數據結構，找出Top K，時間復雜度為N‘logK。即借助堆結構，我們可以在log量級的時間內查找和調整/移動。因此，維護一個K(該題目中是10)大小的小根堆，然后遍歷300萬的Query，分別和根元素進行對比。所以，我們最終的時間復雜度是：O（N） + N' * O（logK），（N為1000萬，N’為300萬）。

別忘了這篇文章中所述的堆排序思路：‘維護k個元素的最小堆，即用容量為k的最小堆存儲最先遍歷到的k個數，并假設它們即是最大的k個數，建堆費時O（k），并調整堆(費時O（logk）)后，有k1>k2>...kmin（kmin設為小頂堆中最小元素）。繼續遍歷數列，每次遍歷一個元素x，與堆頂元素比較，若x>kmin，則更新堆（x入堆，用時logk），否則不更新堆。這樣下來，總費時O（k*logk+（n-k）*logk）=O（n*logk）。此方法得益于在堆中，查找等各項操作時間復雜度均為logk?！?-第三章續、Top K算法問題的實現。

當然，你也可以采用trie樹，關鍵字域存該查詢串出現的次數，沒有出現為0。最后用10個元素的最小推來對出現頻率進行排序。”

相信，如此，也就不難理解開頭所提出的方法了：Trie樹+ ?TOP K「hashmap+堆，hashmap+堆 統計出如10個近似的熱詞，也就是說，只存與關鍵詞近似的比如10個熱詞」。

而且你以后就可以告訴你身邊的伙伴們，為何輸入“結構之”，會提示出來一堆以“結構之”為前綴的詞拉：

? ??

方法貌似成型了，但有哪些需要注意的細節呢？如@江申_Johnson所說：“實際工作里，比如當前綴很短的時候，候選詞很多的時候，查詢和排序性能可能有問題，也許可以加一層索引trie（這層索引可以只索引頻率高于某一個閾值的詞，很短的時候查這個就可以了。數量不夠的話再去查索引了全部詞的trie樹）；而且有時候不能根據query頻率來排，而要引導用戶輸入信息量更全面的query，或者或不僅僅是前綴匹配這么簡單?！?/span>

擴展閱讀

除了上文提到的trie樹，三叉樹或許也是一個不錯的解決方案：http://igoro.com/archive/efficient-auto-complete-with-a-ternary-search-tree/。此外，StackOverflow上也有兩個討論帖子，大家可以看看：①http://stackoverflow.com/questions/2901831/algorithm-for-autocomplete，②http://stackoverflow.com/questions/1783652/what-is-the-best-autocomplete-suggest-algorithm-datastructure-c-c。

附近地點搜索

題目詳情：找一個點集中與給定點距離最近的點，同時，給定的二維點集都是固定的，查詢可能有很多次，時間復雜度O(n)無法接受，請設計數據結構和相應的算法。

題目分析：此題是去年微軟的三面題，類似于一朋友@陳利人 出的這題：附近地點搜索，就是搜索用戶附近有哪些地點。隨著GPS和帶有GPS功能的移動設備的普及，附近地點搜索也變得炙手可熱。在龐大的地理數據庫中搜索地點，索引是很重要的。但是，我們的需求是搜索附近地點，例如，坐標(39.91, 116.37)附近500米內有什么餐館，那么讓你來設計，該怎么做？

解法一、R樹二維搜索

假定只允許你初中數學知識，那么你可能建一個X-Y坐標系，即以坐標(39.91, 116.37)為圓心，以500的長度為半徑，畫一個園，然后一個一個坐標點的去查找。此法看似可行，但復雜度可想而知，即便你自以為聰明的說把整個平面劃分為四個象限，一個一個象限的查找，此舉雖然優化程度不夠，但也說明你一步步想到點子上去了。

即不一個一個坐標點的查找，而是一個一個區域的查找，相對來說，其平均查找速度和效率會顯著提升。如此，便自然而然的想到了有沒有一種一次查找定位于一個區域的數據結構呢？

若看過博客內之前介紹R樹的這篇文章http://blog.csdn.net/v_JULY_v/article/details/6530142#t2?的讀者立馬便能意識到，R樹就是解決這個區域查找繼而不斷縮小規模的問題。特直接引用原文：

“R樹的數據結構

R樹是B樹在高維空間的擴展，是一棵平衡樹。每個R樹的葉子結點包含了多個指向不同數據的指針，這些數據可以是存放在硬盤中的，也可以是存在內存中。根據R樹的這種數據結構，當我們需要進行一個高維空間查詢時，我們只需要遍歷少數幾個葉子結點所包含的指針，查看這些指針指向的數據是否滿足要求即可。這種方式使我們不必遍歷所有數據即可獲得答案，效率顯著提高。下圖1是R樹的一個簡單實例：

我們在上面說過，R樹運用了空間分割的理念，這種理念是如何實現的呢？R樹采用了一種稱為MBR(Minimal Bounding Rectangle)的方法，在此我把它譯作“最小邊界矩形”。從葉子結點開始用矩形（rectangle）將空間框起來，結點越往上，框住的空間就越大，以此對空間進行分割。有點不懂？沒關系，繼續往下看。在這里我還想提一下，R樹中的R應該代表的是Rectangle（此處參考wikipedia上關于R樹的介紹），而不是大多數國內教材中所說的Region（很多書把R樹稱為區域樹，這是有誤的）。我們就拿二維空間來舉例。下圖是Guttman論文中的一幅圖：

?

? ? 我來詳細解釋一下這張圖。

先來看圖（b），首先我們假設所有數據都是二維空間下的點，圖中僅僅標志了R8區域中的數據，也就是那個shape of data object。別把那一塊不規則圖形看成一個數據，我們把它看作是多個數據圍成的一個區域。為了實現R樹結構，我們用一個最小邊界矩形恰好框住這個不規則區域，這樣，我們就構造出了一個區域：R8。R8的特點很明顯，就是正正好好框住所有在此區域中的數據。

其他實線包圍住的區域，如R9，R10，R12等都是同樣的道理。這樣一來，我們一共得到了12個最最基本的最小矩形。這些矩形都將被存儲在子結點中。

下一步操作就是進行高一層次的處理。我們發現R8，R9，R10三個矩形距離最為靠近，因此就可以用一個更大的矩形R3恰好框住這3個矩形。

同樣道理，R15，R16被R6恰好框住，R11，R12被R4恰好框住，等等。所有最基本的最小邊界矩形被框入更大的矩形中之后，再次迭代，用更大的框去框住這些矩形。

我想大家都應該理解這個數據結構的特征了。用地圖的例子來解釋，就是所有的數據都是餐廳所對應的地點，先把相鄰的餐廳劃分到同一塊區域，劃分好所有餐廳之后，再把鄰近的區域劃分到更大的區域，劃分完畢后再次進行更高層次的劃分，直到劃分到只剩下兩個最大的區域為止。要查找的時候就方便了。

下面就可以把這些大大小小的矩形存入我們的R樹中去了。根結點存放的是兩個最大的矩形，這兩個最大的矩形框住了所有的剩余的矩形，當然也就框住了所有的數據。下一層的結點存放了次大的矩形，這些矩形縮小了范圍。每個葉子結點都是存放的最小的矩形，這些矩形中可能包含有n個數據。

地圖查找的實例

講完了基本的數據結構，我們來講個實例，如何查詢特定的數據。又以餐廳為例，假設我要查詢廣州市天河區天河城附近一公里的所有餐廳地址怎么辦？

打開地圖（也就是整個R樹），先選擇國內還是國外（也就是根結點）；

然后選擇華南地區（對應第一層結點），選擇廣州市（對應第二層結點），

再選擇天河區（對應第三層結點）；

最后選擇天河城所在的那個區域（對應葉子結點，存放有最小矩形）；

遍歷所有在此區域內的結點，看是否滿足我們的要求即可。怎么樣，其實R樹的查找規則跟查地圖很像吧？對應下圖：

? ? ? ??

一棵R樹滿足如下的性質：

除非它是根結點之外，所有葉子結點包含有m至M個記錄索引（條目）。作為根結點的葉子結點所具有的記錄個數可以少于m。通常，m=M/2。

對于所有在葉子中存儲的記錄（條目），I是最小的可以在空間中完全覆蓋這些記錄所代表的點的矩形（注意：此處所說的“矩形”是可以擴展到高維空間的）。

每一個非葉子結點擁有m至M個孩子結點，除非它是根結點。

對于在非葉子結點上的每一個條目，i是最小的可以在空間上完全覆蓋這些條目所代表的店的矩形（同性質2）。

所有葉子結點都位于同一層，因此R樹為平衡樹。

葉子結點的結構

先來探究一下葉子結點的結構。葉子結點所保存的數據形式為：(I, tuple-identifier)。

其中，tuple-identifier表示的是一個存放于數據庫中的tuple，也就是一條記錄，它是n維的。I是一個n維空間的矩形，并可以恰好框住這個葉子結點中所有記錄代表的n維空間中的點。I=(I₀,I₁,…,I_n-1)。其結構如下圖所示：

下圖描述的就是在二維空間中的葉子結點所要存儲的信息。

?

在這張圖中，I所代表的就是圖中的矩形，其范圍是a<=I₀<=b，c<=I₁<=d。有兩個tuple-identifier，在圖中即表示為那兩個點。這種形式完全可以推廣到高維空間。大家簡單想想三維空間中的樣子就可以了。這樣，葉子結點的結構就介紹完了。

非葉子結點

非葉子結點的結構其實與葉子結點非常類似。想象一下B樹就知道了，B樹的葉子結點存放的是真實存在的數據，而非葉子結點存放的是這些數據的“邊界”，或者說也算是一種索引（有疑問的讀者可以回顧一下上述第一節中講解B樹的部分）。

同樣道理，R樹的非葉子結點存放的數據結構為：(I, child-pointer)。

其中，child-pointer是指向孩子結點的指針，I是覆蓋所有孩子結點對應矩形的矩形。這邊有點拗口，但我想不是很難懂？給張圖：

?

D,E,F,G為孩子結點所對應的矩形。A為能夠覆蓋這些矩形的更大的矩形。這個A就是這個非葉子結點所對應的矩形。這時候你應該悟到了吧？無論是葉子結點還是非葉子結點，它們都對應著一個矩形。樹形結構上層的結點所對應的矩形能夠完全覆蓋它的孩子結點所對應的矩形。根結點也唯一對應一個矩形，而這個矩形是可以覆蓋所有我們擁有的數據信息在空間中代表的點的。

我個人感覺這張圖畫的不那么精確，應該是矩形A要恰好覆蓋D,E,F,G，而不應該再留出這么多沒用的空間了。但為尊重原圖的繪制者，特不作修改。”

但R樹有些什么問題呢？如@宋梟_CD所說：“單純用R樹來作索引，搜索附近的地點，可能會遍歷樹的很多個分支。而且當全國的地圖或者全省的地圖時候，樹的葉節點數目很多，樹的深度也會是一個問題。一般會把地理位置上附近的節點（二維地圖中點線面）預處理成page(大小為4K的倍數)，在這些page上建立R樹的索引。”

解法二、GeoHash算法索引地理位置信息

我在微博上跟一些朋友討論這個附近點搜索的問題時，除了談到R樹，有幾個朋友都指出GeoHash算法可以解決，故才了解了下GeoHash算法，此文http://blog.nosqlfan.com/html/1811.html?清晰闡述了MongoDB借助GeoHash算法實現地理位置索引的原理，特引用其內容加以說明，如下：

“支持地理位置索引是MongoDB的一大亮點，這也是全球最流行的LBS服務foursquare?選擇MongoDB的原因之一。我們知道，通常的數據庫索引結構是B+?Tree，如何將地理位置轉化為可建立B+Tree的形式。首先假設我們將需要索引的整個地圖分成16×16的方格，如下圖（左下角為坐標0,0?右上角為坐標16,16）：

單純的［x，y］的數據是無法建立索引的，所以MongoDB在建立索引的時候，會根據相應字段的坐標計算一個可以用來做索引的hash值，這個值叫做geohash，下面我們以地圖上坐標為［4，6］的點（圖中紅叉位置）為例。我們第一步將整個地圖分成等大小的四塊，如下圖：

劃分成四塊后我們可以定義這四塊的值，如下（左下為00，左上為01，右下為10，右上為11）：

這樣［4，6］點的geohash值目前為?00然后再將四個小塊每一塊進行切割，如下：

這時［4，6］點位于右上區域，右上的值為11，這樣［4，6］點的geohash值變為：0011繼續往下做兩次切分：

最終得到［4，6］點的geohash值為：00110100

這樣我們用這個值來做索引，則地圖上點相近的點就可以轉化成有相同前綴的geohash值了。

我們可以看到，這個geohash值的精確度是與劃分地圖的次數成正比的，上例對地圖劃分了四次。而MongoDB默認是進行26次劃分，這個值在建立索引時是可控的。具體建立二維地理位置索引的命令如下：

? ? 其中的bits參數就是劃分幾次，默認為26次。?”

本章完。

作者：July

來源：http://www.cnblogs.com/v-July-v/p/3320869.html

-----------------

明明共同關注公眾號，彼此卻互不認識；

明明具有相同的愛好，卻無緣相識；

有沒有覺得這就是上帝給我們的一個bug！

想不想認識更多寫程序的小伙伴？

C++，Java，VB……應有盡有。

還等什么？趕快上車加入我們吧！

(･??･?)っ算法與數學之美-計算機粉絲群

我們在這里等你喲

算法數學之美微信公眾號歡迎賜稿

稿件涉及數學、物理、算法、計算機、編程等相關領域。

稿件一經采用，我們將奉上稿酬。

投稿郵箱：math_alg@163.com
商務合作：微信號hengzi5809

總結

以上是生活随笔為你收集整理的搜索智能提示suggestion，附近地点搜索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。