ElasticSearch簡介
本文針對ElasticSearch進行簡單的介紹，包括ES的功能，相關概念和基本結構。該部分內容參考自：ElasticSearch Introduction官方文檔。
Elasticsearch是Elastic Stack的核心分佈式搜索和分析引擎。 Elastic Stack技術棧中，Logstash和Beats用於收集、聚合和豐富數據，並將數據存儲在Elasticsearch中。 Kibana可以幫助用戶進行交互式地探索，可視化和共享對數據的見解，並管理和監視整個Stack的運行情況。而Elasticsearch便是爲數據建立索引，提供搜索和進行數據分析的地方。
Elasticsearch可以爲所有類型的數據提供實時的搜索和分析，包括結構化文本、非結構化文本、數字數據或地理空間數據。Elasticsearch都能夠以快速搜索的方式有效地對其進行存儲和建立索引（search其實就是對索引的快速查找）。 ElasticSearch不僅可以進行簡單的數據檢索，還可以聚合信息來發現數據中的趨勢和模式。 隨着數據和查詢量的增長，Elasticsearch的分佈式特性可以使部署的集羣隨之無縫地擴容。
雖然不是每個問題都是搜索問題，但Elasticsearch可以快速和靈活的處理各種使用場景中的數據：
- 爲應用（APP）或網站添加內容搜索框
- 存儲和分析日誌，監測值（metrices）和安全事件數據（security event data）
- 使用機器學習（ML）自動實時爲數據行爲建模
- 使用Elasticsearch作爲存儲引擎自動化業務工作流程
- 使用Elasticsearch作爲地理信息系統（GIS）管理，集成和分析空間信息
- 使用Elasticsearch作爲生物信息學研究工具來存儲和處理遺傳數據
數據導入：建立文檔和索引
Elasticsearch是一個分佈式文件存儲系統（distributed document store）。 它不會將信息使用結構化的行列表進行存儲，而是存儲已序列化爲JSON文檔的複雜數據結構。 當集羣中有多個Elasticsearch節點時，存儲的文檔將分佈式的存儲在集羣的多個節點中，並且可以從任何節點立即訪問。
ES在存儲文檔時，將在1秒鐘內，幾乎實時地對文檔進行建立索引和完成搜索。 Elasticsearch使用倒排索引（inverted index）的數據結構，該結構支持非常快速的全文本搜索。 倒排索引列出了出現在任何文檔中的每個唯一單詞，並標識了每個單詞出現的所有文檔。
ES中的索引可以看做是優化後的文檔集合，其中每個文檔都是多個字段（filed）組成的集合結構，這些字段是包含數據（data）的鍵值對（key:value）。默認情況下，Elasticsearch對每個字段中的所有數據建立索引，並且每個索引字段都具有專用的優化數據結構。例如，文本字段存儲在倒排索引中，數字字段和地理字段存儲在BKD樹中。這種使用字段的數據結構，在組合並返回搜索結果時，使得Elasticsearch的搜索非常快速。
Elasticsearch還具有無模式（schema-less）的能力，這意味着無需顯式的指定如何處理文檔中可能出現的每個不同字段，就可對文檔建立索引。啓用動態映射（dynamic mapping）後，Elasticsearch會自動檢測並向索引添加新字段。這種默認的方式，使索引和瀏覽數據變得容易——只需開始建立索引文檔，Elasticsearch就會自動檢測布爾值，浮點數和整數值，日期和字符串並將其映射到適當的Elasticsearch數據類型。
當然，如果不使用以上的默認方式，用戶也可以自定義規則來控制動態映射，顯式定義映射以指定字段的存儲和索引方式。如果使用自定義的映射，則能夠：
- 區分全文字符串字段和精確值字符串字段
- 執行特定於語言的文本分析
- 優化字段以進行部分匹配
- 使用自定義日期格式
- 使用無法自動檢測到的數據類型，例如geo_point和geooshape
一般來說，根據不同的目的以不同的方式對同一字段（field）建立索引通常很有用。 例如，有時可能希望將一個字符串字段（string field）構建爲全文搜索的文本字段（full-text search），或者是索引關鍵字（keyword field）以便對數據進行排序或彙總。 或者，有時可能會使用多個語言分析器來處理用戶輸入的同一字符串字段的內容。
ES在搜索數據時，會使用在索引期間建立的全文字段的分析鏈。 當查詢全文字段時，對查詢文本進行相同的分析，然後才能在索引中進行搜索。
信息導出：數據搜索和分析
雖然Elasticsearch常被用作文檔存儲，或檢索文檔及其元數據，但其真正的強大之處在於能夠輕鬆訪問基於Apache Lucene搜索引擎庫構建的全套搜索功能。
Elasticsearch提供了一個簡單、統一的REST API，用於管理ES集羣、索引和搜索數據。 使用戶可以輕鬆地直接從命令行或通過Kibana中的開發者控制檯（Developer Console）提交請求。 在應用程序中，可以爲Elasticsearch客戶端選擇需要使用的開發語言，例如：Java，JavaScript，Go，.NET，PHP，Perl，Python或Ruby，具體見：Elasticsearch client。
搜索數據
Elasticsearch REST API支持結構化查詢（structured query）、全文查詢（full text query）和結合了兩者的複雜查詢（complex query）：
- 結構化查詢類似於在SQL中構造的查詢類型。例如，在員工索引中搜索性別和年齡字段，然後按Hire_date字段對匹配項進行排序。
- 全文查詢會找到所有與查詢字符串匹配的文檔，並按相關性（relevance）對它們進行返回——它們與搜索詞的匹配程度（相關性分數）。
除了搜索單個術語（terms）外，還可以執行短語搜索、相似性搜索和前綴搜索。如果需要搜索地理空間或其他數字數據，Elasticsearch支持高性能的在地理和數字查詢的優化數據結構中，索引非文本的數據。
用戶可以使用Elasticsearch詳細的JSON樣式的查詢語言（Query DSL）訪問上述所有搜索功能。還可以構造SQL樣式的查詢（SQL-style queries）以在Elasticsearch內部本地搜索和聚合數據，並且可以使用JDBC和ODBC驅動程序，通過第三方應用程序使用SQL與Elasticsearch進行交互。
分析數據
Elasticsearch聚合（aggregation）提供了構建數據的複雜彙總，並深入瞭解關鍵指標（key metrics），模式（patterns）和趨勢（trends）的功能。 通過聚合操作，不僅可以找到諺語“大海撈針”這種文本的檢索數據，還可以回答以下問題：
- 大海撈針有多少根？
- 針的平均長度是多少？
- 針頭的中位長度是多少，由製造商細分？
- 在過去六個月的每個月中，有多少根針被添加到大海里？
還可以使用聚合來回答更細微的問題，例如：
- 最受歡迎的針的製造商是哪些？
- 是否存在異常或者異常的針有哪些？
由於聚合功能使用了於搜索相同的優化數據結構，因此聚合的過程也非常快。 因此ES可以近乎實時的分析和可視化數據，及時的更新報告和系統監控儀表板上的數據，使得用戶可以根據最新信息採取措施。
而且，聚合操作和搜索請求可以一起運行。 可以在單個請求中同時對數據進行搜索、過濾結果並執行分析。 而且由於聚合是在特定搜索結果的基礎之上完成計算的，因此搜索結果不僅可以顯示所有長度70大小的針數，而且還可以返回符合用戶搜索條件（搜索子句criteria）的針——例如， 所有尺寸爲70的不粘繡針（non-stick embroidery needles）。
機器學習數據分析
ElasticSearch提供了Machine Learning進行數據分析的功能，具體見：machine learning。
ES的可伸縮性和彈性：集羣，節點和分片（shards）
Elasticsearch旨在提供高可用，和可擴展的系統功能，並通過自身具有的分佈式存儲結構來實現系統的彈性和可擴展性。用戶可以將服務器（物理主機節點）添加到集羣以增加計算和存儲容量，此時Elasticsearch會自動在所有可用節點之間分配數據和均衡查詢負載。很大程度的減少了用戶對應用程序的修改，Elasticsearch知道如何平衡多節點集羣以提供擴展性和高可用性。節點越多，系統的可用性和負載均衡的能力越好。
那麼上面的可擴展性和彈性是如何運作的呢？在ES底層，Elasticsearch索引（index）實際上是一個或多個物理分片（shards）的邏輯分組，其中每個分片都是一個獨立的索引。通過將文檔分佈在多個分片組成的一個邏輯索引，然後將這些分片分佈在多個節點中，Elasticsearch實現了數據的冗餘存儲。這既可以防止硬件故障，又可以在將節點添加到集羣中時提高查詢能力。隨着集羣的增長（或收縮），Elasticsearch會自動遷移碎片以重新平衡集羣。
上述的分片有兩種類型：主分片和副本。索引中的每個文檔都只屬於一個主分片。副本分片是主分片的副本。副本可提供數據的冗餘副本，以防止硬件故障並提高處理讀取請求（例如搜索或檢索文檔）的能力。
創建索引時，索引中主分片的數量是固定的，但是副本碎片的數量可以隨時更改，而不會中斷索引或查詢操作。
分片的數量配置
對於上述分片的大小和爲索引配置的主分片數量方面，存在許多性能方面的考慮和權衡取捨。 碎片越多，維護這些索引的開銷就越大。 分片大小越大，當Elasticsearch需要重新平衡集羣時，移動分片所需的時間就越長。
查詢很多小的分片會使每個分片的處理速度更快，但是更多的分片也查詢意味着更多的開銷，因此查詢較小數量的大分片可能會更快。 簡而言之，分片數量的設置需要視情況而定。
一般情況下：
- 將平均分片大小保持在幾GB到幾十GB之間。 對於基於時間的數據存儲，通常會看到20GB到40GB範圍內的碎片。
- 避免龐大的碎片問題。 節點可以容納的分片數量與可用堆（heap）空間成比例。 通常，每GB堆空間中的分片數量應少於20。
此外，確定使用中最佳配置的最好方法是通過使用自己的數據和查詢進行測試，來確定分片的大小和數量，具體參見：testing with your own data and queries。
集羣容災問題
出於性能的原因，ES集羣內的節點必須位於同一網絡上。 跨不同數據中心中的節點的羣集中的碎片平衡將花費更長的時間開銷。 但是高可用性架構的要求，避免將所有雞蛋都放在一個籃子裏。 如果一個位置發生重大故障，則另一個位置的服務器需要能夠接管。 這就需要：跨集羣複製（Cross-cluster replication，CCR）。
CCR提供了一種方法：可以自動將索引從主集羣同步到可以用作熱備份的輔助遠程集羣。 如果主集羣出現故障，則輔助集羣可以接管。 同時，還可以使用CCR創建輔助集羣，以接近地理位置的方式向用戶響應讀取請求。
跨集羣複製是主動——被動的。 主集羣上的索引是活動的leader索引，並處理所有寫請求。 複製到輔助集羣的索引是隻讀的follower。
集羣監控和管理
與任何企業系統一樣，需要工具來保護、管理和監視Elasticsearch集羣。 Kibana作爲控制中心來管理ES集羣，它爲Elasticsearch提供了安全性、監視和管理等功能。 數據彙總（data rollups ）和索引生命週期管理（index lifecycle management）等功能則可幫助用戶隨着時間的推移智能地管理數據。