《Elasticsearch in Action》書評與作者訪談

jopen 8年前發布 | 33K 次閱讀 Elastic Search

如今，企業淹沒在系統生成的浩瀚數據流當中。大數據技術業已集中在如何存儲和處理這些海量的數據上。雖然離線數據的批處理非常重要，但我們通常需要對相應的實時數據做出明智的判斷。這就是搜索引擎的用武之地， siteber.com 將其描述為“最具活力的行業”：

搜索引擎行業在過去幾年的成長，已經足以鞏固其在美國最具創新性行業之一的地位。

于是乎， Elasticsearch 和 Apache Solr 這兩款當世領先的開源搜索引擎，正在享受著更廣泛的使用，吸引著更多人的關注。Gheorghe、Hinman和Russo所著的新書《Elasticsearch in Action》是一本非常好的書，簡潔地一步步介紹了搜索，解釋了Elasticsearch是如何實現搜索功能的，并提供很多代碼示例。這本書還深入講述了Elasticsearch的管理和配置，強調了索引和搜索性能之間的權衡。

這本書的主要內容分為兩部分：“核心功能”和“高級功能”，隨后是幾個附錄，覆蓋了非常重要但不通用的功能（只適用于一些特殊的應用場景）。

本書的第一部分描述了Elasticsearch核心構建塊及其功能。覆蓋了Elasticsearch建模和索引數據的主要功能和方法，它們將用于支持基于應用系統的查詢和分析。

第一章介紹了通用搜索引擎的功能，及其在Elasticsearch中的實現。這章的最后介紹了Elasticsearch的安裝，用于運行全書提供的示例。
第二章講述了Elasticsearch服務器中的數據組織，包括邏輯數據模型（搜索應用與Elasticsearch交互的方式）和物理布局（服務器內部處理數據的方式）。接下來，展示了這種數據模型是如何運用于典型的操作場景之中，即索引文檔、查詢文檔、通過聚合分析數據，并水平擴展到多個節點上。
第三章詳述了從Elasticsearch讀寫數據和維護數據的細節：索引、更新和刪除文檔。通過分析文檔的字段，詳述了索引過程；向讀者講述了當我們寫入時，都包含哪些內容，會發生什么事情。
第四章詳述了全文搜索，包括主要的查詢器和過濾器、它們的內部工作機制，以及各種搜索方法的權衡。本章的最后，演示了一些最常用的過濾器和查詢器，并解釋了它們對于不同應用場景的適用性。
第五章闡述了如何將文檔和查詢器中的文本，分析和拆分為用于搜索的詞條。本章介紹了Elasticsearch提供的不同類型的分析器，并說明了如何構建我們自己的分析器，以充分利用Elasticsearch的全文搜索潛能。本章還介紹了用于解決復雜搜索業務的Ngrams、Shingles和Stemming。
第六章關注于相關性計算，也就是打分（score），它定義了文檔對原始查詢的相關性。本章描述了影響文檔打分的因素及其維護方式——使用不同的打分算法、調整指定查詢器或者字段的boost值。本章還展示了Elasticsearch中，用于計算打分的API。
第七章展示了如何使用聚合來執行實時數據分析。在Elasticsearch中的具體做法是，加載文檔、匹配搜索條件，以及執行各種排序計算，比如統計字符類型字段中詞項的數量，或者計算數值類型字段的平均值。聚合被分為兩種：度量和桶。度量聚合是指對一組文檔進行靜態分析，得到度量值，比如最小值、最大值、均方差等。桶式聚合將匹配的文檔拆分進一個或多個桶容器，然后告訴你每個桶里有多少文檔。
第八章是第一部分的最后一章，講述了Elasticsearch對關系的支持。本章討論了Elasticsearch提供的處理關系的幾種常見方法，包括對象類型、嵌套文檔、父子關系和一般的非規范化。同時，說明了如何使用每一種方法，以及它的優點和缺點。

本書的第二部分講述了如何在生產環境中使用Elasticsearch。書中提供了每種功能的工作原理，及其對性能和穩定性的影響：

第九章講述了水平擴展Elasticsearch到多個節點。包括增加、刪除、解除節點、選舉Master的過程和分片遷移的機制。還深入分析了擴展的策略，包括索引分片和副本的最佳實踐，比如，使用Oversharding或者基于時間的索引來確保當前的設計可以處理明年的數據。此外，還說明了如何使用索引別名和路由來提高集群的靈活性和可擴展性。在本章的最后，演示了如何使用Elasticsearch的API展示集群的狀態和健康狀況。
第十章講述了多種提高集群性能的辦法。首先是如何將多個請求，比如index、update、delete、get和search合并成一次HTTP調用。這種分組通過最小化網絡往返流量，可以大幅提高應用的性能。接著是Elasticsearch如何處理Lucene（底層搜索庫）段：如何設置讀寫的刷新（refresh和flush）、合并策略和存儲，這些設置對索引和搜索性能有何影響，以及在索引和搜索之間性能調優的權衡。本章的最后，討論了影響Elasticsearch速度的一個重要的因素，緩存。詳述了過濾器緩存的細節和最佳實踐。還講述了分片查詢緩存，以及如何在預留足夠的空間給Elasticsearch堆空間的同時，給操作系統足夠的空間去緩存索引。
第十一章講述了監控和管理生產集群。包括額外的設置方法、簡化集群管理，以及監控生產環境必要的度量指標。最后，討論了備份和恢復一個數據節點。

六個附錄包含了有關Elasticsearch的更多信息：

附錄A是關于地理空間搜索的。它可以為應用帶來位置感知能力。Elasticsearch支持存儲位置信息（點和多邊形）和通用的空間操作，比如兩點間距離、圖形包含點、圖形間重疊等計算。附錄演示了如何在搜索中使用這一功能。
附錄B是講如何管理Elasticsearch插件的。插件是一種開箱即用的，能為Elasticsearch帶來擴展和增強功能的強大方式。附錄中介紹了兩種類型的插件。一種是site插件，沒有額外的功能，只是為Elasticsearch提供了網頁服務。另一種是code插件，可以是任何包含JVM代碼、能被Elasticsearch執行的插件。附錄講述了如何安裝、使用和卸載插件。
附錄C是關于Highlighting選項及其實現的。Highlighting指示為什么文檔出現再查詢結果中，匹配的詞項被加上強調樣式，讓用戶感受到文檔是說什么的，以及和查詢之間的關系。
附錄D是關于監控插件的。Elasticsearch社區提供了很多監控插件，可以通過引人入勝的圖形界面，更容易地管理集群的狀態、索引，以及執行查詢。
附錄E是關于如何使用Elasticsearch滲濾器（percolator）的。滲濾器通常被定義為『搜索倒置』。滲濾器索引的是查詢信息而不是索引文檔。將查詢注冊并存儲到內存當中，以便日后快速執行。使用滲濾器時，我們發送給Elasticsearch的是文檔，而不是查詢信息。這被稱為滲濾文檔，基本上會對其索引到小內存索引上。Elasticsearch根據小索引從已然注冊的查詢信息中查詢，并返回匹配的查詢信息。
最后，附錄F是關于建議器（suggester）的。附錄解釋了如何使用不同的建議器實現用戶意圖的自動補全功能。這里所描述的基本功能，包括詞項和短語的建議、補全和上下文的建議。附錄描述了各種建議器和Elasticsearch中與此功能相關的API。

Manning出版社為InfoQ的讀者提供了這本書的第八章節選，“文檔之間的關系”。

InfoQ采訪了本書的作者，一起討論更多關于Elasticsearch的實現和使用的信息。

InfoQ：本書中，在討論典型Elasticsearch用例時，你們提出的一個選項是“增加Elasticsearch到現有系統中”。這個選項假定增加Elasticsearch到現有的數據存儲系統。由于Elasticsearch的數據可用性有延遲，這可能導致在不同的存儲系統中，產生數據之間的競賽條件。特別是當數據被刪除的時候，Elasticsearch仍然會返回查詢結果。關于如何應對這樣的情況，有什么好的建議嗎？

Roy Russo：這種場景的最簡回答是在應用層面管理整個過程，將分別從不同的數據存儲系統中刪除，封裝為一個 try-catch 代碼塊，就像我們執行一次寫操作。因此，第一步是調用Elasticsearch刪除記錄，然后調用主數據存儲節點。如果任何階段失敗了，要處理異常邏輯。這里沒有事務可用，因此異常處理需要手動回滾。

因為我所見過的最常用的Elasticsearch使用是基于時間序列的數據，這種場景并不常見。除非在某種罕見環境中，大多數軟件沒有規律地從時間序列存儲中刪除記錄。還有一個辦法是使用Elasticsearch作為單獨的數據存儲系統，但是這將帶來其他健康方面的討論，我不想陷于此處。

InfoQ：在Otis Gospodneti?所寫的 Elasticsearch對比Solr的文章中說，相比控制在一家公司手中的Elasticsearch而言，Solr更加開源。你同意這種評價嗎，這對Elasticsearch用戶來說是個問題嗎？

Roy Russo：首先，我得說自己是Otis在Sematext所做成就的粉絲，但是我不同意他的觀點。兩個項目都是以Apache Software許可分發的，它們都接受來自社區的提交，受益于透明的缺陷、pull 請求和討論。任何情況下，給出一個專業的開源軟件和一個業余的開源軟件供選擇，留給讀者去選擇哪個最適合他的下一次關鍵的部署。

Elasticsearch用戶受益于一個資金雄厚的公司提供的支持服務、插件和輔助產品，比如：Watcher，一種告警裝置、Shield，支持認證和授權，以及與 Hadoop集成。在很短的時間里，Elastic已經將這個開源項目打造成一款產品。這里有一個區別，因為有一家公司在驅動產品，因此增加了質量保證流程、產品管理以決定哪些功能被添加、工藝路線圖，以及結構化的工程團隊做具體執行。我目前的角色是在關鍵任務的情況下部署大型集群、熟知這款由一個財務健康、專業的工程師團隊所支持的產品。

InfoQ：Elasticsearch集群的每一個節點都提供了REST API端點，Elasticsearch是否提供了負載均衡的實現，以確保某個客戶端不會壓垮某一節點？

Roy Russo：雖然每個節點可以靈活地配置為不同的節點類型（Master、Client、Data）作為不完全解決方案，但是確實需要一個容錯系統，我建議用戶在Elasticsearch前面使用他們自己的負載均衡器。Nginx常用于負載均衡/反向代理。因此，有很多的教程和示例在線演示不同的負載均衡方案（輪詢、最后連接等等），甚至是使用Nginx為指定的API端點或者HTTP方法做重定向（認證/授權）。

InfoQ：在這本書中，你們只展示了如何使用REST API操作Elasticsearch。與此同時，還存在很多Elasticsearch的 Java客戶端。有什么好的推薦嗎？

Roy Russo：就全功能的實現而言，官方提供的Java客戶端是最好的選擇。使用官方的客戶端，你的軟件不會通過REST API通信，而是扮演一個正在加入集群的額外節點。以此方式附加到集群的好處是省去了每次請求中額外的跳（hop），因為操作會被自動路由到相關的節點。對于Spring用戶來說，Spring Data Elasticsearch可以完美地處理這些，通過在ORM中增加一些方便的屬性即可。Spring Data Elasticsearch以依賴包的方式內置了官方的Elasticsearch Java客戶端，因此它的行為和使用Spring Data帶來的益處一致。

InfoQ：父子關系實現上的描述稍微令人困惑。首先，你說父文檔的索引過程不受到任何特殊影響，但子文檔必須參考的父文檔。你又說一個子文檔參考一個父文檔。我會認為這是指一個ID引用，但你后面又說，父文檔可以在以后添加。因此，在這種情況下，如何指定引用呢？此外，你后面又談到了父文檔中有子文檔的字段。這個字段是何時填充的呢？

Lee Hinman：子文檔中對父文檔的引用是通過URL中特殊的'parent'參數傳入的，因此在索引子文檔的時候父文檔是不存在的，縱然這個父文檔不存在，Elasticsearch還是允許指定'parent'參數的。父子關系在子文檔的特殊字段中指定（不是在父文檔，這就是為什么在父文檔不存在的情況下，可以索引子文檔），has_child查詢或者has_parent查詢，可以自動加載id mapping緩存。

InfoQ：在講述多節點集群搜索時，你說“默認情況下，主分片和分片副本是輪詢搜索的。”在這種情況下，是否存在本地因素？比如，一個副本存在與接收請求的節點，它將被使用？

Roy Russo：是的，如果主分片或者分片副本存在于當前節點，它將被使用。但是，有一點非常重要，我們必須意識到查詢會在集群中廣播到索引的每一個分片。那些分片執行本地查詢并匯報匹配文檔。

InfoQ：書中講述了通過每個文檔的版本號實現并發控制。Elasticsearch為每個文檔存儲很多的版本號還是只存最后一個版本號？

Roy Russo：這是個常見話題而且令人困惑。Elasticsearch根本沒有提供版本控制，因為它保留了原始文檔的拷貝。它只持有一個計數器，當文檔更新、索引或者刪除時，“_version”會自增。這是一個便捷的樂觀鎖，有助于保證在并發更新中，更新的是同一版本號的文檔，而不是不同版本的。

InfoQ：書中講述了兩種節點的發現機制，多播（multicast）和單播（unicast，提供host列表）。兩者都能用于AWS。是否還有其他的發現機制，比如基于AWS的負載均衡組？

Roy Russo：在AWS上部署時，我強烈推薦Elasticsearch cloud-aws插件。使用AWS IAM角色分配到EC2實例上，或者使用AWS Access key配置Elasticsearch配置文件，可以神奇般地讓節點彼此發現。如果希望使用IAM角色配置，需要注意的是只能在EC2創建的時候指定IAM角色，此后不能再次修改。這個cloud-aws插件，可以無縫地讓同一集群名稱的各個節點彼此通信，是AWS環境中確定推薦和支持的。

額外需要注意的是，因為2.x的發布，這款插件從S3插件中分離出來。那些我們自動備份在S3上的插件，現在需要單獨安裝。

InfoQ：在Elasticsearch實現Lucene索引合并時，是只對主分片操作，然后拷貝全部副本嗎？

Lee Hinman：不是這樣的，Elasticsearch中的合并是獨立運行的。因為Elasticsearch使用文檔級別的副本，而不是文件級別，所以每個索引的每個分片的合并方式是不確定的。

InfoQ：現在AWS提供了Elasticsearch 托管服務，對Elasticsearch的采用會有什么影響？如何簡化集群管理？

Roy Russo：坦白地講，我希望這對Elasticsearch的采用沒有傷害。我很喜歡AWS，但是Elasticsearch的發展需要業余時間，也許會給Elasticsearch用戶數月之久的糟糕體驗。

使用AWS Elasticsearch服務部署一個集群只需要非常方便的幾次點擊，但是需要你為便捷犧牲靈活性和可擴展性，直到他們開放配置信息和功能。我已經看到和經歷的一些顯著問題是，無法調優和自定義Elasticsearch性能和日志，無法安裝插件，無法支持Elasticsearch v1.5.x，以及受阻于CORS。此外，你無法在VPC及相關軟件中運行該服務，我會規避直到Amazon在該服務上解決。誰知道呢？也許他們能閱讀我們這本書，然后為Elasticsearch服務做出成功的改變。

作者簡介

Roy Russo 是預測分析公司Predikto的工程副總裁。在加入Predikto之前，Roy是佐治亞州亞特蘭大AltiSource實驗室的首席架構師。Roy曾是亞特蘭大營銷自動化軟件供應商LoopFuse（最近被亞特蘭大的SalesFusion收購）的聯合創始人和產品管理副總裁。Roy還幫助聯合創建JBoss Portal，JSR-168兼容的企業級Java門戶網站，是Java內容倉庫，JSR-170中，JBoss的代表。他目前是領先的ElasticSearch集群開源監控和管理應用，ElasticHQ.org的創始人《Elasticsearch in Action》一書的合作者。

《Elasticsearch in Action》書評與作者訪談 Radu Gheorghe 供職于Sematext，他為客戶提供搜索咨詢、產品支持，培訓各種Elasticsearch和Solr的部署。他熱衷于日志工具，比如rsyslog（是的，這可能是鐘愛之一），他在Sematext也得到了負責日志分析服務Logsene的機會。

《Elasticsearch in Action》書評與作者訪談 Matthew Lee Hinman 是一位充滿激情的軟件開發者，尋找具有挑戰性的軟件開發。活躍于開源社區，是Clojure和Elasticsearch社區的貢獻者。Lee樂于在解決挑戰性和趣味性問題的團隊中工作。他非常關心代碼質量，開源了他大部分業余時間編寫的代碼。