簡介
ElasticSearch是一款基於 Apache Lucene的開源搜索引擎產品，之後成了獨立的商業公司，繼而發佈了ELK等一系列產品，特點是開源、分佈式、準實時，標準的RESTFul接口等。
ElasticSearch可以單機部署，也可以集群部署。ES的分佈式屬性，可以輕鬆的處理超過單機負載能力的數據量，集群也是無間斷服務的一種解決方案。
整體架構
基本概念
- Node：單個的ElasticSearch服務實例。
- Master：負責監督、控制其它節點的工作。
- Data：持有數據，並提供數據的索引功能，主要用途是索引和查詢數據。
- 協調節點：每一個節點都是一個潛在的協調節點，協調節點會處理請求，將各分片裡的數據彙集起來一併返回給客戶端，ES的節點需要有足夠的CPU和內存去處理協調節點的gather 階段。
- 索引：EasticSearch將數據存儲在一個或多個索引中， 用SQL領域的術語來類比，索引就像數據庫，可以向索引中寫入文檔或者從索引中讀取文檔，內部使用Lucene。
- 分片：ES將數據分散到多個物理的Lucene索引，這些Lucene索引就稱為分片。分散分片的過程，稱之為sharding。
- 主分片：主分片的數量在索引創建時就被配置好了，之後無法改變，除非創建一個新索引並重新索引全部數據。
- 副本分片：副本主要有以下作用，1 分擔訪問壓力；2 給ES集群提供安全機制；3會增加寫入的時長。
- 類型（type）
5.x 版本中index和 type為一對多關係，不同type定義對應的mapping。
6.x 版本中index和 type為一對一關係。
7.x 版本中移除了type，一個索引只定義一個數據類型。
將來會在8.x中徹底移除。
- 文檔（doc）
doc是ES中的主要實體：
- 對於所有使用ES的案例來說，最終都會被歸結到文檔的搜索之上。
- 文檔由字段構成，每個字段包含字段名以及一個或多個字段值。
- 從用戶端的角度看，文檔是一個Json對象。
- 集群健康狀態
Green：表示所有主分片和副本分片都可用。
Yellow：表示所有主分片可用，但不是所有副本分片都可用。
Red：表示部分主分片處於不可用狀態
ES操作
索引設計
索引設計主要包括 mapping和setting兩部分
Settings用於設置分片和副本數
查看setting：
Mapping（映射）
mappings用於設置字段和類型。
動態mapping：根據索引的數據動態的生成 mapping
不建議使用動態mapping，主要原因：
- 會引發性能下降。
- 影響磁盤空間的使用。
- 導致與預期查詢不符的結果。
查看mapping語法：
模板
Logstash 使用事件中的時間戳來生成索引名，@timestamp 為 2019-10-01 00:00:01 事件將被髮送至索引 logstash-2019.10.01 中，通常我們想要控制新建索引的設置（settings）和映射（mappings）
上面的API做了如下操作：
- 創建一個名為 my_logs 的模板；
- 將這個模板應用於所有以 logstash- 為起始的索引；
- 設置模版的順序級別；
- 限制主分片數量為 10；
- 為所有類型禁用 _all 域。
常用API：
寫入操作：
實際過程中，提交操作會進行一次完整的 HTTP POST 請求和 ES indexing，單條數據是一種極大的性能浪費，ES 設計了批量提交方式， bulk接口：
Bulk像一個集合，把一系列操作批量提交，這在很大程度上提高了ES的寫入效率。
bulk的使用和大小設置
- 整個bulk請求需要被加載到接收請求節點的內存裡，所以請求越大，給其它請求可用的內存就越小。因此，有一個最佳的bulk請求大小，超過這個大小，性能不再提升而且可能降低。
- 最佳大小，並不是一個固定的數字, 取決於硬件、文檔的大小和複雜度以及索引和搜索的負載情況。
- 開始的數量可以在1000~5000個文檔之間，如果文檔非常大，可以使用較小的批次。通常著眼於你請求批次的物理大小是非常有用的，一千個1kB的文檔和一千個1MB的文檔大不相同。
- 一個好的批次最好保持在5-15MB大小間。
數據檢索過程
數據檢索主要分為兩個階段，query階段和fetch階段：
query階段：
- 客戶端發送一個search請求到Node 3上，然後Node 3會創建一個優先級隊列（大小=from+size）。
- Node 3轉發這個search請求到索引裡面每一個主shard或者副本shard上，每個shard會在本地查詢然後添加結果到本地的排序好的優先級隊列裡面。
- 每個shard返回docId和所有參與排序字段的值到優先級隊列裡面，然後再返回給coordinating節點也就是Node 3，然後Node 3負責將所有shard裡面的數據合併到一個全局的排序列表。
Fetch階段：
- coordinating節點標識了那些document需要被拉取出來，併發送一個批量的mutil get請求到相關的shard上。
- 每個shard加載相關document，如果需要它們將會被返回到coordinating 節點上。
- 一旦所有的document被拉取回來，coordinating節點將會返回結果集到客戶端上。
scroll 讀取（遊標查詢）
優點：
Scroll 有效地執行大批量的文檔查詢，而又不用付出深度分頁的代價，類似於傳統數據庫中的cursor。
scroll使用方法：
遊標查詢每次返回一個新字段 _scroll_id。每次做下一次遊標查詢時， 需要把前一次查詢返回的字段 _scroll_id 傳遞進去
在一些語言如 Python、perl的ElasticSearch包中，提供了這個功能易用的封裝。
別名 Index aliases
別名很簡單，但是能解決重建索引必須更新應用中索引名的問題，實現索引切換的無縫過渡。
別名像一個快捷方式或軟連接，可以指向一個或多個索引，需要注意，別名不能與索引同名。
相關API：
重命名別名：
針對DSL查詢，淺顯的優化建議：
- 正確使用 match、match_phrase、term， 區分 must 、must_not 、should等Bool查詢
- 儘量多使用filter
- 如果不必須涉及相關性和評分的話，儘量避免相應的操作
- 合適的數據類型（如Mapping中合理使用keyword類型）
結束語
本篇文章主要介紹了ElasticSearch的基本概念和實踐中常用的一些方法，並沒有涉及深層原理和優化的知識，在DSL、讀寫優化、7.x新版本等方面，還有不少知識點可以深入研究。
關於360技術：360技術是360技術團隊打造的技術分享公眾號，每天推送技術乾貨內容，更多技術信息歡迎關注“360技術”微信公眾號
閱讀更多 360技術 的文章
