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