Solr&ElasticSearch原理及應用
一、綜述
搜索
http://baike.baidu.com/item/%E6%90%9C%E7%B4%A2/2791632#viewPageContent
早期的搜索引擎是把因特網中的資源服務器的地址收集起來，由其提供的資源的類型不同而分成不同的目錄，再一層層地進行分類。人們要找自己想要的信息可按他們的分類一層層進入，就能最后到達目的地，找到自己想要的信息（樹狀結構）。這其實是最原始的方式，只適用于因特網信息并不多的時候。
隨著因特網信息按幾何式增長，出現了真正意義上的搜索引擎，這些搜索引擎知道網站上每一頁的開始，隨后搜索因特網上的所有超級鏈接，把代表超級鏈接的所有詞匯放入一個數據庫。這就是現在搜索引擎的原型。
它包括信息搜集、信息整理和用戶查詢三部分。
發展
隨著yahoo!的出現，搜索引擎的發展也進入了黃金時代，相比以前其性能更加優越。現在的搜索引擎已經不只是單純的搜索網頁的信息了，它們已經變得更加綜合化，完美化了。以搜索引擎權威yahoo!為例，從1995年3月由美籍華裔楊致遠等人創辦yahoo!開始，到現在，他們從一個單一的搜索引擎發展到現在有電子商務、新聞信息服務、個人免費電子信箱服務等多種網絡服務，充分說明了搜索引擎的發展從單一到綜合的過程。
ETL-數據倉庫技術
Extraction-Transformation-Loading的縮寫，中文名稱為數據提取、轉換和加載。
http://baike.so.com/doc/2126217-2249603.html
ETL，是英文Extract-Transform-Load的縮寫，用來描述將數據從來源端經過抽取(extract)、轉換(transform)、加載(load)至目的端的過程。ETL一詞較常用在數據倉庫，但其對象并不限于數據倉庫。
ETL是構建數據倉庫的重要一環，用戶從數據源抽取出所需的數據，經過數據清洗,最終按照預先定義好的數據倉庫模型，將數據加載到數據倉庫中去。
原理
每個獨立的搜索引擎都有自己的網頁抓取程序（spider）。Spider順著網頁中的超鏈接，連續地抓取網頁。由于互聯網中超鏈接的應用很普遍，理論上，從一定范圍的網頁出發，就能搜集到絕大多數的網頁。
搜索引擎抓到網頁后，還要做大量的預處理工作才能提供檢索服務。其中，最重要的就是提取關鍵詞，建立索引文件。其他還包括去除重復網頁、分析超鏈接、計算網頁的重要度等。
用戶輸入關鍵詞進行檢索，搜索引擎從索引數據庫中找到匹配該關鍵詞的網頁；為了用戶便于判斷，除了網頁標題和URL外，還會提供一段來自網頁的摘要以及其他信息。
二、搜索引擎
搜索引擎（Search Engine）是指根據一定的策略、運用特定的計算機程序從互聯網上搜集信息，在對信息進行組織和處理后，為用戶提供檢索服務，將用戶檢索相關的信息展示給用戶的系統。搜索引擎包括全文索引、目錄索引、元搜索引擎、垂直搜索引擎、集合式搜索引擎、門戶搜索引擎與免費鏈接列表等。
一個搜索引擎由搜索器、索引器、檢索器和用戶接口四個部分組成。
1.搜索器的功能是在互聯網中漫游，發現和搜集信息。
2.索引器的功能是理解搜索器所搜索的信息，從中抽取出索引項，用于表示文檔以及生成文檔庫的索引表。
3.檢索器的功能是根據用戶的查詢在索引庫中快速檢出文檔，進行文檔與查詢的相關度評價，對將要輸出的結果進行排序，并實現某種用戶相關性反饋機制。
4.用戶接口的作用是輸入用戶查詢、顯示查詢結果、提供用戶相關性反饋機制。
搜索引擎現主要為全文索引和目錄索引。垂直搜索引擎由于其在特定領域的更高的用戶體驗，以及更小的硬件成本，也開始逐漸興起。
1.分類：
1.1全文搜索引擎
搜索引擎分類部分提到過全文搜索引擎從網站提取信息建立網頁數據庫的概念。搜索引擎的自動信息搜集功能分兩種。
一種是定期搜索，即每隔一段時間（比如Google一般是28天），搜索引擎主動派出“蜘蛛”程序，對一定IP地址范圍內的互聯網網站進行檢索，一旦發現新的網站，它會自動提取網站的信息和網址加入自己的數據庫。
另一種是提交網站搜索，即網站擁有者主動向搜索引擎提交網址，它在一定時間內（2天到數月不等）定向向你的網站派出“蜘蛛”程序，掃描你的網站并將有關信息存入數據庫，以備用戶查詢。隨著搜索引擎索引規則發生很大變化，主動提交網址并不保證你的網站能進入搜索引擎數據庫，最好的辦法是多獲得一些外部鏈接，讓搜索引擎有更多機會找到你并自動將你的網站收錄。
當用戶以關鍵詞查找信息時，搜索引擎會在數據庫中進行搜尋，如果找到與用戶要求內容相符的網站，便采用特殊的算法——通常根據網頁中關鍵詞的匹配程度、出現的位置、頻次、鏈接質量——計算出各網頁的相關度及排名等級，然后根據關聯度高低，按順序將這些網頁鏈接返回給用戶。這種引擎的特點是搜全率比較高
1.2目錄索引
目錄索引也稱為：分類檢索，是因特網上最早提供WWW資源查詢的服務，主要通過搜集和整理因特網的資源，根據搜索到網頁的內容，將其網址分配到相關分類主題目錄的不同層次的類目之下，形成像圖書館目錄一樣的分類樹形結構索引。目錄索引無需輸入任何文字，只要根據網站提供的主題分類目錄，層層點擊進入，便可查到所需的網絡信息資源。
嚴格意義上，目錄索引不能稱為搜索引擎。
1.2.1目錄索引與搜索引擎的不同
1.搜索引擎為程序自動索引；而目錄索引則依賴人為操作。
2.搜索引擎不考慮網站分類，根據關鍵詞網站頻率構建搜索索引；而目錄索引需要甄別網站的分類目錄位置。
3.搜索引擎檢索到的信息是程序爬蟲自動獲取的，沒有或少有過濾機制，而目錄索引有大量的人為審查過濾機制，因而信息目錄構建也相對緩慢。
1.2.2目錄索引與搜索引擎的融合
現在的搜索引擎一般也提供分類查詢的功能。如Google使用Open Directory目錄提供分類查詢。在默認搜索模式下，一些目錄類搜索引擎首先返回的是自己目錄中匹配的網站，如中國的搜狐、新浪、網易等；而另外一些則默認的是網頁搜索，如Yahoo。這種引擎的特點是檢索的準確率比較高。
1.3垂直搜索引擎
垂直搜索引擎為2006年后逐步興起的一類搜索引擎。不同于通用的網頁搜索引擎，垂直搜索專注于特定的搜索領域和搜索需求（例如：機票搜索、旅游搜索、生活搜索、小說搜索、視頻搜索、購物搜索等等），在其特定的搜索領域有更好的用戶體驗。相比通用搜索動輒數千臺檢索服務器，垂直搜索具備需要的硬件成本低、用戶需求特定、查詢的方式多樣等優點。比較適合中小型公司和創業型公司的搜索服務。
2.工作原理
按照搜索引擎的定義，一般將其工作原理分為四部分，即爬行，抓取存儲，預處理，排名。
2.1爬行（信息獲取）
網絡搜索引擎通過特定算法的軟件，跟蹤網頁中的超鏈接，逐層深入鏈接，逐漸擴張成一張遍布網絡。因此，也形象的稱之為蜘蛛（Spider）或爬蟲。這種軟件的爬行，需要遵循一定的規則，按照指定的爬行深度和爬行廣度來進行網頁爬取。
除了爬取Web之上的資源，可獲取的數據庫，文本文件，PDF等可解析出文字形成有效數據的信息資源都可以成為爬取的資源。當然，針對不同的文件格式和文檔編碼，都需要有相對應的文件解析和預處理器配合，才能實現信息的爬取。
2.2抓取存儲（信息存儲）
搜索引擎將爬蟲爬取到的可識別存儲信息存儲到原始頁面數據庫中。其中的數據是還未經處理的信息，還不具備數據的有效性，因此還不能稱之為數據。
在爬取頁面的過程中，爬蟲也會對數據進行初步的重復性檢測，根據相應的權重以及重復比有選擇的爬取頁面信息，并忽略被大量轉載、抄襲、復制的內容。
2.3預處理（信息-數據）
搜索引擎的預處理器會將爬蟲爬取回來的數據進行各種的預處理操作，減小數據音噪比，提煉有效數據。并通過索引器根據指定的索引構建方式構建索引。
一般會進行的預處理包括但不限于：提取文字，特定語種分詞（如中文分詞），去除停止詞，消除噪音（如版權聲明文字、導航條、廣告等……），鏈接關系計算，特殊文件處理等。
索引構建一般有正向索引（順序索引），倒排索引等方式。
2.4排名
搜索引擎會根據多種指標來對根據檢索詞匯檢索到的初步結果進行結果排名。如有名的Google創始人拉里·佩奇的PageRank算法就是Google搜索引擎排名運算法則的一部分。
Google的PageRank根據網站的外部鏈接和內部鏈接的數量和質量來衡量網站的價值。PageRank背后的概念是，每個到頁面的鏈接都是對該頁面的一次投票，被鏈接的越多，就意味著被其他網站投票越多。這個就是所謂的"鏈接流行度"--衡量多少人愿意將他們的網站和你的網站掛鉤。PageRank這個概念引自學術中一篇論文的被引述的頻度--即被別人引述的次數越多，一般判斷這篇論文的權威性就越高。
但是這樣的一種排名機制導致后來出現了SEO中的鏈接銷售和交換策略，市場泛濫的同時，也讓搜索的準確率不斷下降。因此Google通過修改規則，對相關度不高的網頁中鏈接，以及缺乏內容的鏈接工廠（Link Farm）進行了排除。同時降低了PR值得更新頻率，一般一年更新四次，抑制了互聯網鏈接的不正常發展。
當然，Google作為世界上最為著名的搜索引擎（=。=），它的排名算法不僅僅只是PageRank，PR只是它排名規則的一部分而已。
關于排名規則與指標，還有更多其它考慮因素，如網站與網站內容的符合程度等，其中還涉及到反黑帽SEO作弊技術的相關算法規則。
排名作為搜索引擎面向用戶接口的重要一環以及一個可獲得利益點，在百度的競價排名規則中表現明顯。而Google則遵循其“Don’t be evil”的組織文化原則，根據搜索結果提供更大可能對用戶有用的廣告產品來獲取收益，從而保證了自身搜索引擎排名的公正性和有用性。
排名算法規則和方式自誕生以來就廣受爭議，站在成本角度考量，要維持一個普適性強的搜索引擎的正常良好運作，需要巨大的人力和機器成本，如果不能從中獲取收益，對運行維護公司來說將是巨大的損失。但是在互聯網時代虛假消息橫行的時代，反虛假、反捏造信息的責任更多的放到了作為互聯網網頁入口的搜索引擎的身上，促使它們不斷的更改自己的算法，添加新的規則，來讓用戶得到真實有效的信息。
三、Lucene
1.概念
Solr和Elasticsearch都是基于Lucene實現的。
Lucene是apache軟件基金會4
jakarta項目組的一個子項目，是一個開放源代碼的全文檢索引擎工具包，但它不是一個完整的全文檢索引擎，而是一個全文檢索引擎的架構，提供了完整的查詢引擎和索引引擎，部分文本分析引擎（英文與德文兩種西方語言）。
Lucene的目的是為軟件開發人員提供一個簡單易用的工具包，以方便的在目標系統中實現全文檢索的功能，或者是以此為基礎建立起完整的全文檢索引擎。Lucene提供了一個簡單卻強大的應用程式接口，能夠做全文索引和搜尋。在Java開發環境里Lucene是一個成熟的免費開源工具。信息檢索程序庫，雖然與搜索引擎有關，但不應該將信息檢索程序庫與搜索引擎相混淆。
全文搜索引擎：國外具代表性的有Google、Fast/AllTheWeb、AltaVista、Inktomi、Teoma、WiseNut等，國內著名的有百度（Baidu）。
2.倒排索引
http://baike.baidu.com/item/%E5%80%92%E6%8E%92%E7%B4%A2%E5%BC%95/11001569#reference-[2]-676861-wrap
2.1概念
倒排索引源于實際應用中需要根據屬性的值來查找記錄。這種索引表中的每一項都包括一個屬性值和具有該屬性值的各記錄的地址。由于不是由記錄來確定屬性值，而是由屬性值來確定記錄的位置，因而稱為倒排索引(inverted index)。
2.2應用背景
在關系數據庫系統里，索引是檢索數據最有效率的方式,。但對于搜索引擎，它并不能滿足其特殊要求:
1)海量數據:搜索引擎面對的是海量數據，像Google，百度這樣大型的商業搜索引擎索引都是億級甚至百億級的網頁數量，面對如此海量數據,使得數據庫系統很難有效的管理。
2)數據操作簡單:搜索引擎使用的數據操作簡單,一般而言,只需要增、刪、改、查幾個功能,而且數據都有特定的格式,可以針對這些應用設計出簡單高效的應用程序。而一般的數據庫系統則支持大而全的功能,同時損失了速度和空間。最后,搜索引擎面臨大量的用戶檢索需求,這要求搜索引擎在檢索程序的設計上要分秒必爭,盡可能的將大運算量的工作在索引建立時完成,使檢索運算盡量的少。一般的數據庫系統很難承受如此大量的用戶請求,而且在檢索響應時間和檢索并發度上都不及我們專門設計的索引系統。
2.3概念辨析
2.3.1倒排列表
利用倒排索引方式構建而成的單詞與文檔的映射，其中文檔部分的結構就是倒排列表。
倒排列表用來記錄有哪些文檔包含了某個單詞。一般在文檔集合里會有很多文檔包含某個單詞，每個文檔會記錄文檔編號（DocID），單詞在這個文檔中出現的次數（TF）及單詞在文檔中哪些位置出現過等信息，這樣與一個文檔相關的信息被稱做倒排索引項（Posting），包含這個單詞的一系列倒排索引項形成了列表結構，這就是某個單詞對應的倒排列表。
在實際的搜索引擎系統中，并不存儲倒排索引項中的實際文檔編號，而是代之以文檔編號差值（D-Gap）。文檔編號差值是倒排列表中相鄰的兩個倒排索引項文檔編號的差值，一般在索引構建過程中，可以保證倒排列表中后面出現的文檔編號大于之前出現的文檔編號，所以文檔編號差值總是大于0的整數。之所以要對文檔編號進行差值計算，主要原因是為了更好地對數據進行壓縮，原始文檔編號一般都是大數值，通過差值計算，就有效地將大數值轉換為了小數值，而這有助于增加數據的壓縮率。
2.3.2倒排索引
https://zh.wikipedia.org/wiki/%E5%80%92%E6%8E%92%E7%B4%A2%E5%BC%95
倒排索引（Inverted index），也常被稱為反向索引、置入檔案或反向檔案，是一種索引方法，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。它是文檔檢索系統中最常用的數據結構。通過倒排索引，可以根據單詞快速獲取包含這個單詞的文檔列表。倒排索引主要由兩個部分組成：“單詞詞典”和“倒排文件”。
倒排索引有兩種不同的反向索引形式：
一條記錄的水平反向索引（或者反向檔案索引）包含每個引用單詞的文檔的列表。
一個單詞的水平反向索引（或者完全反向索引）又包含每個單詞在一個文檔中的位置。
后者的形式提供了更多的兼容性（比如短語搜索），但是需要更多的時間和空間來創建。
現代搜索引擎的索引都是基于倒排索引。相比“簽名文件”、“后綴樹”等索引結構，“倒排索引”是實現單詞到文檔映射關系的最佳實現方式和最有效的索引結構。
2.3.2.1構建方法
構建方法有簡單法和合并法兩種。
簡單法：
索引的構建相當于從正排表到倒排表的建立過程。當我們分析完網頁時,得到的是以網頁為主碼的索引表。當索引建立完成后,應得到倒排表,流程描述如下：
1）將文檔分析成單詞term，
2）使用hash去重單詞term
3）對單詞生成倒排列表
倒排列表就是文檔編號DocID，沒有包含其他的信息（如詞頻，單詞位置等），這就是簡單的索引。
這個簡單索引功能可以用于小數據，例如索引幾千個文檔。然而它有兩點限制：
1）需要有足夠的內存來存儲倒排表，對于搜索引擎來說，都是G級別數據，特別是當規模不斷擴大時,我們根本不可能提供這么多的內存。
2）算法是順序執行，不便于并行處理。
合并法：
歸并法，即每次將內存中數據寫入磁盤時，包括詞典在內的所有中間結果信息都被寫入磁盤，這樣內存所有內容都可以被清空，后續建立索引可以使用全部的定額內存。
合并流程：
1）頁面分析，生成臨時倒排數據索引A，B，當臨時倒排數據索引A，B占滿內存后，將內存索引A，B寫入臨時文件生成臨時倒排文件，
2)對生成的多個臨時倒排文件,執行多路歸并,輸出得到最終的倒排文件(
inverted file)。
索引創建過程中的頁面分析,特別是分詞為主要時間開銷。算法的第二步相對很快。這樣創建索引算法的優化就集中在分詞效率上了。
2.3.2.2更新策略
更新策略有四種：完全重建、再合并策略、原地更新策略以及混合策略。
1）完全重建策略：當新增文檔到達一定數量，將新增文檔和原先的老文檔整合，然后利用靜態索引創建方法對所有文檔重建索引，新索引建立完成后老索引會被遺棄。此法代價高，但是主流商業搜索引擎一般是采用此方式來維護索引的更新。
2）再合并策略：當新增文檔進入系統，解析文檔，之后更新內存中維護的臨時索引，文檔中出現的每個單詞，在其倒排表列表末尾追加倒排表列表項；一旦臨時索引將指定內存消耗光，即進行一次索引合并，這里需要倒排文件里的倒排列表存放順序已經按照索引單詞字典順序由低到高排序，這樣直接順序掃描合并即可。其缺點是：因為要生成新的倒排索引文件，所以對老索引中的很多單詞，盡管其在倒排列表并未發生任何變化，也需要將其從老索引中取出來并寫入新索引中，這樣對磁盤消耗是沒必要的。
3）原地更新策略：試圖改進再合并策略，在原地合并倒排表，這需要提前分配一定的空間給未來插入，如果提前分配的空間不夠了需要遷移。實際顯示，其索引更新的效率比再合并策略要低。
4）混合策略：出發點是能夠結合不同索引更新策略的長處，將不同索引更新策略混合，以形成更高效的方法。
四、Solr
http://www.importnew.com/12707.html
搜索總體上劃分為兩個過程索引和搜索。
1.索引(Indexing)
Sorl/Lucene采用的是方向索引方式，即從關鍵詞到文檔的映射過程。
通過構建關鍵詞和文檔之間的關系，在查詢關鍵詞的過程中能夠快速定位文檔位置。
索引創建步驟：
1.1索引文檔詞條化（文檔Document-詞匯單元Token）
把原始待索引文檔內容交給分詞組件（Tokenizer），分詞組件通過Tokenize過程將文檔分解為詞匯單元（Token）。
其中Tokenize過程包含這些操作：
1.將文檔分成單詞
2.去除文檔中的標點符號
3.去除停詞（Stop word）（停詞，即語言之中的助詞，謂語等沒有實際含義的詞。例：英語中的“a”，“the”，中文中的“啊”，“唉”，“之”，“乎”，“者”，“也”等）
1.2語言分析再處理（詞匯單元Token-詞Term）
此過程是語言處理組件（Linguistic Processor）對詞匯單元Token的再處理工作，通常是根據不同的語種來進行相應的特性處理，如英語語種會進行的操作：變為小寫（Lowercase），單詞縮為詞根形式（stemming），單詞轉變為詞根形式（Lemmatization）等。
詞匯單元Token經過此過程處理后的到詞（Term）
1.3倒排索引構建索引庫
此過程會由索引組件（Indexer）將上一步的詞Term與文檔Document之間建立索引關系，從而形成索引庫。在這個過程中索引組件會對所有的詞進行創建詞典，排序，和合并相同詞等操作，從而保證可檢索詞的唯一性。
索引庫中包含了一下幾列：詞（Term），文檔頻率（Document Frequency），文檔中則擁有文檔ID（Document ID），頻率（Frequency）。其中：
詞（Term），即為構建索引庫后要檢索的關鍵詞。而它對應的文檔頻率則表明這個詞在多少篇文檔中出現了。
文檔中的文檔ID用來和詞鏈接，從而能根據詞索引到文檔，而頻率則說明了，所搜索的詞在該文檔中出現的次數。
2.搜索（Search）
搜索是面向用戶接口的主要操作，對檢索的處理是搜索技術是否能夠達到預期效果的重要一步。
技術原理核心-空間向量模型
https://zh.wikipedia.org/wiki/%E5%90%91%E9%87%8F%E7%A9%BA%E9%96%93%E6%A8%A1%E5%9E%8B
我們在構建索引時，將文檔切分為Term，那么當我們要根據關鍵詞或者語句進行檢索時，怎么通過語句來尋找Term，再通過Term來找到對應的文檔呢？
反過來想，根據面向文檔的思想，其實用戶界面輸入的關鍵詞也是一篇文檔。那么當我們使用構建索引的操作對關鍵詞進行分詞構建索引之后，通過這些索引去搜索匹配索引數據庫中的索引，就可以找到相對應的結果了。
而匹配搜索之后我們需要根據關鍵詞和各文檔之間的相關性進行排序，這時候之前對關鍵詞構建的索引又派上了用場。這里我們就可以使用空間向量模型算法來評價文檔結果集中的文檔的索引和關鍵詞索引之間的相關性了。
這個過程，其實就是尋找在兩篇文檔中，哪些詞對文檔之間關系的更重要，哪些最重要，主要文檔中的詞在待匹配文檔中出現頻率的高低的過程，這個判斷關鍵詞的Term對文檔的Term的重要性的過程稱為計算詞的權重（Term Weight）的過程。
計算詞的權重有兩個參數：一是詞（Term），二是文檔（Document）。詞的權重表示此詞在文檔中的重要程度，越重要的詞有越大的權重，因為i在計算文檔之間的相關性中將發揮更大的作用。
向量空間模型算法就可以用來判斷詞之間的關系，從而量化得到文檔之間的相關性。
1.計算權重（Term Weight）的過程
影響一個詞(Term)在一篇文檔中的重要性主要有兩個因素：
1）Term Frequency (tf)：即此Term在此文檔中出現了多少次。tf越大說明越重要。
2）Document Frequency
(df)：即有多少文檔包含次Term。df越大說明越不重要。
當一個Term在某篇文檔中出現的次數越多，即tf越大，說明文檔的主要工作都是在介紹或者重點引用這個概念，那么他們之間的相關性也就越高，權重越大。而當很多的文檔都包含這一個Term時，這個Term對文檔的區分性就越差，即通過df指標非常大的Term更不能區分出文檔之間的相關性，所以表現為權重越不重要。
上公式即為計算權重的一個簡單典型，實際情況可能會有不同，但基本比相同。
2.判斷Term之間的關系從而得到文檔相關性的過程，也即向量空間模型（VSM）的算法
我們把文檔看做一系列Term，通過和關鍵詞文檔的Term的計算，每一個詞都獲得了一個權重，通過空間向量模型算法，根據這些權重，來為不同詞與文檔的相關性計算打分。
我們把文檔中的詞的全助攻看做一個向量：
Document = {term1, term2, …… ,term N}
Document Vector = {weight1, weight2, ……,weight N}
也同樣把關鍵詞看做一個文檔，用向量來表示它們：
Query = {term1, term 2, …… , term N}
Query Vector = {weight1, weight2, …… ,weight N}
把所有搜索出來的文檔向量以及查詢向量放到一個N維空間中，每個Term是一個維度。向量空間的維度數取二者的Term集合的并集。
當兩個向量之間的夾角，即余弦值越小，我們就人為他們的相關性越大，所計算得到的相關性得分也就越高。相關性的分值計算公式如下：通過將關鍵詞文檔與檢索結果集中的各文檔的打分分值，進行降序排序，就得到了這個關鍵詞檢索后的具有相關性排序的結果列表。2.1對查詢內容進行詞法分析、語法分析、語言處理
詞法分析，即區分查詢內容中的單詞與關鍵字。關鍵字例如：“and”，“not”等。
語法分析，通過語法分析將查詢單詞與關鍵字區分開來之后，根據定義好的語法規則，形成語法樹。
語言處理，類似于索引階段的語言分析處理部分，將包含數量和時態等屬性的單詞轉變為它的原型詞。例：“bananas”的原型詞為“banana”，“gone”或“went”的原型詞為“go”。
2.2搜索索引，得到符合語法樹的文檔集合
將經過詞法分析、語法分析、語言處理過后的語法樹，在構建好的索引庫中進行隨機查詢，初步得到所有符合語法樹的文檔集合。
2.3根據查詢語句與文檔的相關性，對結果進行排序
相關性處理詳見“技術原理核心-控件向量模型”一節。
實際應用中，相關性的計算因素不只有文檔分詞權重，在商業化運營中，如百度就發展出了相當豐富的如競價排名的更多的相關性計算因素。
相關性的技術原理是空間向量模型，其本身也具有一些局限性：
1.不適用于較長的文檔，因為它的相似值不理想（過小的內積和過高的維數）。
2.檢索詞組必須與文檔中出現的詞組精確匹配；詞語子字串可能會導致“假陽性”匹配。
3.語義敏感度不佳；具有相同的語境但使用不同的詞組的文檔不能被關聯起來，導致“假陰性匹配”。
4.詞組在文檔中出現的順序在向量形式中無法表示出來。
5.假定詞組在統計上是獨立的。
6.權重是直觀上獲得的而不夠正式。
因此，在相關性排序時，可以利用其它的數學技術如奇異值分解或詞匯數據庫的方式對算法局限進行彌補。
五、ElasticSearch
1.相關概念
1.1集群-節點
單個節點可以作為一個運行中的Elasticsearch的實例。而一個集群是一組擁有相同cluster.name的節點，他們能一起工作并共享數據，還提供容錯與可伸縮性。(當然，一個單獨的節點也可以組成一個集群)
多節點組成的集群擁有冗余能力，它可以在一個或幾個節點出現故障時保證服務的整體可用性。
1.2面向文檔（DO）
在應用程序中對象很少只是一個簡單的鍵和值的列表。通常，它們擁有更復雜的數據結構，可能包括日期、地理信息、其他對象或者數組等。
也許有一天你想把這些對象存儲在數據庫中。使用關系型數據庫的行和列存儲，這相當于是把一個表現力豐富的對象擠壓到一個非常大的電子表格中：你必須將這個對象扁平化來適應表結構--通常一個字段對應一列而且又不得不在每次查詢時重新構造對象。
Elasticsearch是面向文檔的，意味著它存儲整個對象或文檔。Elasticsearch不僅存儲文檔，而且索引每個文檔的內容使之可以被檢索。在Elasticsearch中，你對文檔進行索引、檢索、排序和過濾，而不是對行列數據。這是一種完全不同的思考數據的方式，也是Elasticsearch能支持復雜全文檢索的原因。
1.3索引的概念
名詞關系：
集群-索引-類型-文檔-屬性：
一個Elasticsearch集群可以包含多個索引，相應的每個索引可以包含多個類型。這些不同的類型存儲著多個文檔，每個文檔又有多個屬性。
索引（名詞）：如前所述，一個索引類似于傳統關系數據庫中的一個數據庫，是一個存儲關系型文檔的地方。
索引（動詞）：索引一個文檔就是存儲一個文檔到一個索引（名詞）中以便它可以被檢索和查詢到。這非常類似于SQL語句中的INSERT關鍵詞，除了文檔已存在時新文檔會替換舊文檔情況之外。
倒排索引：關系型數據庫通過增加一個索引比如一個B樹（B-tree）索引到指定的列上，以便提升數據檢索速度。Elasticsearch和Lucene使用了一個叫做倒排索引的結構來達到相同的目的。
默認的，一個文檔中的每一個屬性都是被索引的（有一個倒排索引）和可搜索的。一個沒有倒排索引的屬性是不能被搜索到的。
1.4分片(Shard)和副本(Replica)
ES的“分片(shard)”機制可將一個索引內部的數據分布地存儲于多個節點，它通過將一個索引切分為多個底層物理的Lucene索引完成索引數據的分割存儲功能，這每一個物理的Lucene索引稱為一個分片(shard)。
每個分片其內部都是一個全功能且獨立的索引，因此可由集群中的任何主機存儲。創建索引時，用戶可指定其分片的數量，默認數量為5個。
Shard有兩種類型：primary和replica，即主shard及副本shard。
Primary shard用于文檔存儲，每個新的索引會自動創建5個Primary
shard，當然此數量可在索引創建之前通過配置自行定義，不過，一旦創建完成，其Primary shard的數量將不可更改。
Replica shard是Primary Shard的副本，用于冗余數據及提高搜索性能。
特點：
1.每個Primary shard默認配置了一個Replica
shard，但也可以配置多個，且其數量可動態更改。ES會根據需要自動增加或減少這些Replica shard的數量。
2. ES集群可由多個節點組成，各Shard分布式地存儲于這些節點上。
3. ES可自動在節點間按需要移動shard，例如增加節點或節點故障時。簡而言之，分片實現了集群的分布式存儲，而副本實現了其分布式處理及冗余功能。
2.原理示意圖
著名的開源程序Lucene是索引組件，它提供了搜索程序的核心索引和搜索模塊，例如圖中的“Index”及下面的部分；而ElasticSearch則更像一款搜索組件，它利用Lucene進行文檔索引，并向用戶提供搜索組件，例如“Index”上面的部分。二者結合起來組成了一個完整的搜索引擎。
3.深入知識討論
3.1ES的精確值（Exact Values）和全文（full-text）類型
ES的數據可被廣義的分為兩種類型：“types:exact”和“full-text”。
精確值(Exact values)就是指數據未曾加工過的原始值，而Full-text則用于引用文本中的數據。
在查詢中，精確值是很容易進行搜索的，但full-text則需要判斷文檔在“多大程度上”匹配查詢請求，換句話講，即需要評估文檔與給定查詢的相關度(relevant)。
所謂的full-text查詢通常是指在給定的文本域內部搜索指定的關鍵字，但搜索操作需要真正理解查詢者的目的。為了完成此類full-text域的搜索，ES必須首先分析文本并將其構建成為倒排索引(inverted index)，倒排索引由各文檔中出現的單詞列表組成，列表中的各單詞不能重復且需要指向其所在的各文檔。
3.2倒排索引
倒排索引的原理在第三部分2小節已經介紹，這里主要介紹ES下的構建分詞過程。
3.2.1分析
如上一小節所講，倒排索引構建完成之后的索引要保證能夠完成full-text的搜索工作，那么在構建索引過程中進行對應的分詞（Tokenization）操作就是必要的過程。這個過程會將文檔中域的值切分為獨立的單詞（Term或Token）。
知道了搜索所使用的空間向量模型原理后，我們知道，要在搜索結果完成后進行相應的匹配，那么在構建索引和搜索時構建索引的過程中，使用的分詞語法規則必須是統一的，一致的。在ES中，這個過程叫做正規化（Normalization）。通過將數據統一為一個標準格式，從而方便搜索匹配以及結果相關性的衡量。
這里的分詞（Tokenization）以及正規化（Normalization）也稱為分析（Analysis）。
分析過程有兩個步驟的操作組成，都由指定的分析器（Analyzers）完成：
1）首先，將文本切分為Term以適合構建倒排索引；
2）其次，將各Term正規化為標準格式以提升其“可搜索度”。
3.2.2分析器
一個分析器通常由三個組件構成：字符過濾器(Character filters)、分詞器(Tokenizer)和分詞過濾器(Token filters)組成。
字符過濾器(Character
filters)：在文本被切割之前進行清理操作，例如移除HTML標簽，將&替換為字符等；
分詞器(Tokenizer)：將文本切分為獨立的詞項；簡單的分詞器通常是根據空白及標點符號進行切分；
分詞過濾器(Token
filters)：轉換字符(如將大寫轉為小寫)、移除詞項(如移除a、an、of及the等)或者添加詞項(例如，添加同義詞)；
Elasticsearch內置了許多字符過濾器、分詞器和分詞過濾器，用戶可按需將它們組合成“自定義”的分析器。
固然，創建倒排索引時需要用到分析器，但傳遞搜索字符串時也可能需要分析器，甚至還要用到與索引創建時相同的分析器才能保證單詞匹配的精確度。
執行full-text域搜索時，需要用到分析器，但執行精確值搜索時，查詢過程不會分析查詢字符串而是直接進行精確值匹配。
3.3ES的數據查詢
查詢執行過程通常要分成兩個階段，分散階段及合并階段。分散階段是向所查詢的索引中的所有shard發起執行查詢的過程；合并階段是將各shard返回的結果合并、排序并響應給客戶端的過程。
向ElasticSearch發起查詢操作有兩種方式：一是通過RESTful request API傳遞查詢參數，也稱“query-string”；另一個是通過發送REST request body，也稱作JSON格式。而REST形式的請求保證了ES可以做到跨平臺和跨語言。
ES的查詢語句稱為Query DSL，它分為兩種：查詢DSL(query DSL)和過濾DSL(filter
DSL)。
兩種DSL的區別：
1）就使用場景來說，當執行full-text查詢或查詢結果依賴于相關度分值時應該使用查詢DSL，當執行精確值(extac-value)查詢或查詢結果僅有“yes”或“no”兩種結果時應該使用過濾DSL。
2）Filter
DSL計算及過濾速度較快，且適于緩存，因此可有效提升后續查詢請求的執行速度。而query DSL不僅要查找匹配的文檔，還需要計算每個文件的相關度分值，因此為更重量級的查詢，其查詢結果不會被緩存。不過，由于倒排索引方式的緣故，一個僅返回少量文檔的簡單query或許比一個跨數百萬文檔的filter執行起來并不顯得更慢。
3）Queries用于查詢上下文，而filters用于過濾上下文，不過，Elasticsearch的API也支持此二者合并運行。組合查詢可用于合并查詢子句，組合過濾用于合并過濾子句，然而，Elasticsearch的使用習慣中，也常會把filter用于query上進行過濾。不過，很少有機會需要把query用于filter上的。
4.主要特性：
1.實時文檔存儲，文檔對象的每個field都建立了索引，都能被檢索
2.構建適應于不同規模的應用的體系結構，在此之上實現分布式搜索。
3.為其他平臺系統提供了具有rest風格的原生java api。也有hadoop的依賴包
4.簡單可用性強，不需要對搜索原理有深入的理解。平臺有免費模式。
具有可伸縮性，靈活的構建和易用性。提供一個易用性的平臺，進行規模擴展時無需考慮核心功能與用戶自定義選項間妥協。
5.應用
使用廠商：Dell、ebay、Fackbook、netflix等。
應用場景：熱點圖，交通情況地理信息圖等需要實時數據搜索和顯示的場景，數據更新頻繁的場景等。
1）2013年初，GitHub拋棄了Solr，采取ElasticSearch來做PB級的搜索。“GitHub使用ElasticSearch搜索20TB的數據，包括13億文件和1300億行代碼”。
2）維基百科：啟動以elasticsearch為基礎的核心搜索架構。
3）SoundCloud：“SoundCloud使用ElasticSearch為1.8億用戶提供即時而精準的音樂搜索服務”。
4）百度：百度目前廣泛使用ElasticSearch作為文本數據分析，采集百度所有服務器上的各類指標數據及用戶自定義數據，通過對各種數據進行多維分析展示，輔助定位分析實例異常或業務層面異常。目前覆蓋百度內部20多個業務線（包括casio、云分析、網盟、預測、文庫、直達號、錢包、風控等），單集群最大100臺機器，200個ES節點，每天導入30TB+數據。
另外，新浪，阿里，有贊等著名公司也開始了ES方面的技術研發和實踐。
六、Solr和ElasticSearch的不同
1.Solr利用Zookeeper進行分布式管理；而Elasticsearch自身帶有分布式協調管理功能;
2.Solr支持更多格式的數據json，XML等；而Elasticsearch僅支持json文件格式；
3.Solr官方提供的功能更多；而Elasticsearch本身更注重于核心功能，高級功能多由第三方插件提供；
4.Solr在傳統的搜索應用中表現好于Elasticsearch，但在處理實時搜索應用時效率明顯低于Elasticsearch。
5.Solr是傳統搜索應用的有力解決方案，但Elasticsearch更適用于新興的實時搜索應用。
Ps：走過的路，每一步都算數，沉淀我所學習，累積我所見聞，分享我所體驗;
