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粗粒度分詞。
1
然後在搜尋階段，您可以定義要掃描的字段，獲得你想要的檢索結果。
通過應用此行為，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
2
3
4
查詢包含單分片的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![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)