請問，如何設計此系統，使得空間和時間復雜度盡量低。
題目分析：本題來源於去年2012年百度的一套實習生筆試題中的系統設計題（為尊重願題，本章主要使用百度搜索引擎展開論述，而不是google等其它搜索引擎，但原理不會差太多。然脫離本題，平時搜的時候，鼓勵用...），題目比較開放，考察的目的在於看應聘者解決問題的思路是否清晰明確，其次便是看能考慮到多少細節。
- 直接上Trie樹「Trie樹的介紹見：從Trie樹（字典樹）談到后綴樹」 + TOP K「hashmap+堆，hashmap+堆 統計出如10個近似的熱詞，也就是說，只存與關鍵詞近似的比如10個熱詞」
解法一、Trie樹 + TOP K
步驟一、trie樹存儲前綴后綴
Trie樹，即字典樹，又稱單詞查找樹或鍵樹，是一種樹形結構，是一種哈希樹的變種。典型應用是用於統計和排序大量的字符串（但不僅限於字符串），所以經常被搜索引擎系統用於文本詞頻統計。它的優點是：最大限度地減少無謂的字符串比較，查詢效率比哈希表高。
Trie的核心思想是空間換時間。利用字符串的公共前綴來降低查詢時間的開銷以達到提高效率的目的。
它有3個基本性質：
- 根節點不包含字符，除根節點外每一個節點都只包含一個字符。
- 從根節點到某一節點，路徑上經過的字符連接起來，為該節點對應的字符串。
- 每個節點的所有子節點包含的字符都不相同。
1.2、樹的構建
分析：這題當然可以用hash來解決，但是本文重點介紹的是trie樹，因為在某些方面它的用途更大。比如說對於某一個單詞，我們要詢問它的前綴是否出現過。這樣hash就不好搞了，而用trie還是很簡單。
現在回到例子中，如果我們用最傻的方法，對於每一個單詞，我們都要去查找它前面的單詞中是否有它。那么這個算法的復雜度就是O(n^2)。顯然對於100000的范圍難以接受。現在我們換個思路想。假設我要查詢的單詞是abcd，那么在他前面的單詞中，以b，c，d，f之類開頭的我顯然不必考慮。而只要找以a開頭的中是否存在abcd就可以了。同樣的，在以a開頭中的單詞中，我們只要考慮以b作為第二個字母的，一次次縮小范圍和提高針對性，這樣一個樹的模型就漸漸清晰了。
好比假設有b，abc，abd，bcd，abcd，efg，hii 這6個單詞，我們構建的樹就是如下圖這樣的：
ok，如上圖所示，對於每一個節點，從根遍歷到他的過程就是一個單詞，如果這個節點被標記為紅色，就表示這個單詞存在，否則不存在。
那么，對於一個單詞，我只要順着他從根走到對應的節點，再看這個節點是否被標記為紅色就可以知道它是否出現過了。把這個節點標記為紅色，就相當於插入了這個單詞。 ”
步驟二、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，或者或不僅僅是前綴匹配這么簡單。”
擴展閱讀
除了上文提到的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。