Elasticsearch 6 個不明顯但很重要的注意事項

ElasticSearch · 發表 2019-02-18 10:39:20

摘要：題記 Elasticsearch是被Netflix，微軟，eBay，Facebook等Top N 頂級公司使用的搜尋引擎。它很容易使用，但從長遠來看相對難掌握。在本文中，我們分享了在系統中使用Elasticsearch六個不太明顯但非常值得了解的注意事項。 1. Elastic ...

題記

Elasticsearch是被Netflix，微軟，eBay，Facebook等Top N 頂級公司使用的搜尋引擎。它很容易使用，但從長遠來看相對難掌握。在本文中，我們分享了在系統中使用Elasticsearch六個不太明顯但非常值得了解的注意事項。

1. Elastic Stack

Elasticsearch最初是作為獨立產品開發的。它的核心作用是提供可擴充套件的搜尋引擎服務，它提供多種語言庫API，基於分散式模型建立，並對外提供REST API介面服務。

隨著Elastic生態圈的發展，衍生出了與Elasticsearch並肩作戰的其他工具集合。從最早的Kibana （用於視覺化和資料分析）、Logstash （用於日誌收集），到如下的N多工具都是Elastic公司開發的：

Beats - 核心功能：資料傳輸目的，
Elastic Cloud - 託管Elasticsearch叢集，
Machine Learning - 用於發現數據模式，
APM - 應用程式效能監控，
Swiftype - 一鍵式網站搜尋。

工具數量每年都在增長，這使得公司能夠實現新的目標並創造新的機會。

銘毅：Elastic早已不單單是Elasticsearch，而是一體化的工具集合、一體化大資料解決方案工具集。

2.兩種資料集

2.1 資料集分類

基本上，你可以在Elasticsearch中索引（即儲存）您想要的任何資料。但實際上有兩類：靜態資料和時間序列資料。它們會嚴重影響群集的配置和管理方式。

靜態資料是可能會緩慢增長或變化的資料集。像目錄或物品清單。
你可以將它們視為儲存在常規資料庫中的資料。如：部落格文章，圖書館書籍，訂單等。你可能希望在Elasticsearch中索引此類資料以啟用快速搜尋，常規資料庫很難實現這些功能。
時間序列資料集，可以是與通常快速增長的時刻相關聯的事件資料，例如：日誌檔案或度量。
你需要上在Elasticsearch中為它們編制索引，以進行資料分析，模式發現和系統監視。

2.2 資料集建模方式

根據您儲存的資料型別，你應該以不同的方式為叢集建模。

對於靜態資料：你應該選擇固定數量的索引和分片。它們不會快速增長，您總是希望搜尋資料集中的所有文件。
對於時間序列資料，你應該選擇基於時間的滾動索引。您會相對頻繁地查詢最近的資料，並且最終甚至會刪除或者至少歸檔過時的文件以便在機器物理儲存上節省資金。

銘毅：兩種資料集，決定了我們資料的兩種不同的建模方式。

3.搜尋評分

對於每個搜尋查詢，Elasticsearch都會計算相關性分數。該分數基於tf-idf演算法，該演算法代表詞項頻率 - 反向文件頻率。
基本上，在該演算法中計算兩個值。

第一個：詞項頻率TF - 表示在文件中使用給定詞項的頻率。
第二個 - 反向文件頻率IDF - 表示給定詞項在所有文件中的唯一性。

3.1 TF計算

例如，如果我們有兩個文件：

文件1：To be or not to be, that is the question.
文件2：To be. I am. You are. He, she is.

question詞項的TF計算如下：

對於文件1：1/10（10個詞項中有1個出現）
對於文件2：0/9（9個詞項中出現0次）。

3.2 IDF計算

IDF計算為整個資料集的單個值。它是所有文件與包含搜尋詞的文件的比率。
在我們的例子中它是：log（2/1）= 0.301
其中：

2 - 所有檔案的數量，
1 - 包含“question”詞項的檔案數量。

3.3 相關性得分結果

最後，兩個文件的tf-idf分數計算為兩個值的乘積：

文件1：1/10 x 0.301 = 0.1 * 0.301 = 0.03
文件2：0/9 x 0.301 = 0 * 0.301 = 0.00
現在我們看到文件1的值為0.03，而文件2的值為0.00。
因此，文件1將在結果列表中優先返回。

銘毅：實際應用中比這要複雜一些，可以結合explain:true驗證一把

如下：

1PUT my_index32{3  "mappings": {4    "_doc": {5      "properties": {6        "title": { 7          "type": "text"8        }9      } 10    } 11  } 12} 13 14POST my_index3/_doc/1 15{ 16  "title":"To be or not to be, that is the question." 17} 18 19POST my_index3/_doc/2 20{ 21  "title":"To be. I am. You are. He, she is." 22} 23 24POST my_index3/_search 25{ 26  "explain": true,  27  "query": { 28    "match": { 29        "title":"question" 30    } 31  } 32}

4 資料模型

Elasticsearch在效能方面有兩個好處。它可以水平擴充套件，速度非常快。其中速度主要取決於：資料的儲存方式。

4.1 索引階段資料模型

索引文件時，它將通過三個步驟：character filters（字元過濾器），tokenizer（標記生成器）和token filters（標記過濾器）。它們用於規範化文件。
例如：一個文件

To be or not to be, that is the question.

1）可能實際儲存為：
如果標點符號被刪除且所有詞項都是小寫的：

to be or not to be that is the question

2）它也可以儲存為：
如果應用了停用詞過濾器，它將刪除所有常用語言術語，例如：to，be，or，not，that，is，the。
僅剩下：

question

以上是索引部分。

4.2 搜尋階段資料模型

在搜尋文件時會應用相同的步驟。查詢也被過濾為character filters（字元過濾器），tokenizer（標記生成器）和token filters（標記過濾器）。
然後Elasticsearch正在搜尋帶有規範化詞項的文件。
Elasticsearch中的欄位儲存在倒排索引結構中，這使得快速獲取匹配文件。

可以為每個欄位定義特定過濾器。藉助於analyzers實現定義。可以使用多個analyzers分詞器分析欄位以實現不同的目標。
例如：

1可以使用standard分詞器逐字分詞， 使用ik_max_word 細粒度分詞， 使用ik_smart粗粒度分詞。

然後在搜尋階段，您可以定義要掃描的欄位，獲得你想要的檢索結果。
通過應用此行為，ElasticSearch可以比常規資料庫更快地提供結果。

銘毅：模型的好壞除了提升檢索效率，還能節省儲存空間。

5 分片計劃

5.1 我應該有多少分片和索引？

這是新手學習、實操Elasticsearch提出的最常見問題。
為什麼會出現這個問題？只能在索引建立的最開始設定分片數。

所以答案真的取決於你擁有的資料集。根據經驗，單分片最大應包含20-40 GB的資料。 Shards來自Apache Lucene。

考慮到Apache Lucene用於反向索引和快速搜尋的所有結構和開銷，劃分小分片（例如100 MB或1 GB）是沒有意義的。

Elastic顧問建議使用20-40 GB。請記住，分片不能進一步劃分，並且始終駐留在單個節點上。這樣大小的分片也可以很容易地移動到其他節點，或者如果需要，在叢集內複製。具有此分片容量可以為您提供速度和記憶體消耗之間的折衷值。

當然，在您的特定情況下，效能指標可能顯示不同的內容，因此請記住， 這只是一個建議 ，您可能結合您的實際業務場景，希望實現其他效能目標。

5.2 實際分片注意事項

1）為了知道每個索引應該有多少分片，你可以簡單地估計一下，通過將一些文件索引到一個臨時索引中，看看它們消耗了多少記憶體，以及你希望在一段時間內有多少文件。時間指的：部分時間（在時間序列資料集中），或者全部時間（在靜態資料集中）。

2）不要忘記，即使您錯誤配置了分片數或索引數，也可以始終將資料重新索引方式設定正確的資料，然後reindex操作完成資料遷移。

3）最後但並非最不重要的。您始終可以一次查詢多個索引。

例如，您可以基於日期遞增的滾動索引，並在一個查詢中簡單地詢問上個月的所有日期的索引或者

別名 實現一鍵查詢。

1logstash_20190201_000001 2logstash_20190202_000002 3.... 4logstash_20190228_000028

查詢包含單分片的30個索引和包含30個分片的1個大索引的 效能是一致 的。

銘毅：結合業務資料量是分片的根本。

6.節點型別

Elasticsearch節點可以包括多個角色。角色包括：

Master：主節點，
Data：資料節點，
Ingest：攝取節點，
Coordinating-only:僅協調節點。

每個角色都有對應的用途。

6.1 主節點

作用：負責群集範圍的設定和更改，例如建立或刪除索引，新增或刪除節點以及將分片分配給節點。
針對大資料量級規模的叢集，（建議）每個叢集中應至少包含3個候選主節點。系統會從所有符合主節點的節點中，選擇一個節點作為主節點，其作用是執行群集範圍的操作。另外兩個節點純粹是為了獲得高可用性。
硬體要求 ：主節點對CPU，RAM和磁碟儲存的要求相對較低。

6.2 資料節點

作用：用於儲存和搜尋資料。
硬體要求 ：資料節點對所有資源都有很高的要求：CPU，RAM和磁碟。您擁有的資料越多，硬體資源要求也就越高。

6.3 Ingest節點

作用：在實際索引發生之前，Ingest節點用於文件預處理。
Ingest節點攔截批量和索引查詢，應用轉換，然後將文件傳遞迴索引或批量API。
硬體要求 ：低磁碟、中等RAM和高CPU，

6.4 僅協調節點

作用：客戶端請求的負載平衡器。

它知道特定文件可以駐留的位置，並將搜尋請求路由到對應節點。

【官方文件警告】：

將過多的僅協調節點新增到群集會

增加整個群集的負擔

，因為所選主節點必須等待來自每個節點的群集狀態更新的確認！

不應過分誇大僅協調節點的好處 - 資料節點可以愉快地用於相同的目的。

硬體要求：低磁碟，中高速RAM和中高CPU。

6.5 配置大型叢集的首選方法是什麼？

以下是建議：

1) 三個主節點 - 維護叢集狀態和叢集設定，

2) 兩個僅協調節點 - 它們監聽外部請求，並充當整個叢集的智慧負載平衡器，

3) 許多資料節點 - 取決於資料集需求，

4) 幾個 Ingest節點（可選） - 如果您正在執行攝取管道並希望減輕其他節點對預處理文件的影響。

具體數字取決於您的特定用例+實際業務場景，並且

必須根據效能測試 進行調整。

銘毅：需要根據實際業務場景、業務規模做分配。

7 小結

畢竟每個公司業務場景不一致，以上6個特性建議供選型參考。
實際中需要結合業務場景+官方文件+原始碼做進一步優化。
翻譯中，結合自己的實踐做了部分微調+解讀。

原文作者：Dariusz Mydlarz，系Elastic官方認證工程師。

原文地址：

http://t.cn/EVwtn1R