題記

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驗證一把

如下：

PUT my_index3
{
  "mappings": {
    "_doc": {
      "properties": {
        "title": { 
          "type": "text"
        }
      }
    }
  }
}

POST my_index3/_doc/1
{
  "title":"To be or not to be, that is the question."
}

POST my_index3/_doc/2
{
  "title":"To be. I am. You are. He, she is."
}

POST my_index3/_search
{
  "explain": true, 
  "query": {
    "match": {
        "title":"question"
    }
  }
}

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分詞器分析字段以實現不同的目標。
例如：

可以使用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）最後但並非最不重要的。您始終可以一次查詢多個索引。
例如，您可以基於日期遞增的滾動索引，並在一個查詢中簡單地詢問上個月的所有日期的索引或者別名實現一鍵查詢。

logstash_20190201_000001
logstash_20190202_000002
....
logstash_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 配置大型集羣的首選方法是什麼？

以下是建議：

三個主節點 - 維護集羣狀態和集羣設置，
兩個僅協調節點 - 它們監聽外部請求，並充當整個集羣的智能負載平衡器，
許多數據節點 - 取決於數據集需求，
幾個 Ingest節點（可選） - 如果您正在執行攝取管道並希望減輕其他節點對預處理文檔的影響。
具體數字取決於您的特定用例+實際業務場景，並且必須根據性能測試進行調整。

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

7 小結

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

原文作者：Dariusz Mydlarz，系Elastic官方認證工程師。
原文地址：https://blog.softwaremill.com/6-not-so-obvious-things-about-elasticsearch-422491494aa4

銘毅天下——Elasticsearch基礎、進階、實戰第一公衆號

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

題記