目錄
@、Lucene和Solr和Elasticsearch的區別
@、elasticsearch 瞭解多少，說說你們公司 es 的集羣架構，索引數據大小，分片有多少，以及一些調優手段。elasticsearch 的倒排索引是什麼。
@、elasticsearch 索引數據多了怎麼辦，如何調優，部署。
@、Elasticsearch是如何實現Master選舉的？
@、Elasticsearch中的節點（比如共20個），其中的10個選了一個master，另外10個選了另一個master，怎麼辦？
@、Elasticsearch索引文檔的過程@、詳細描述一下Elasticsearch更新和刪除文檔的過程
@、Elasticsearch執行搜索的過程@、Elasticsearch在部署時，對Linux的設置有哪些優化方法？
@、對於GC方面，在使用Elasticsearch時要注意什麼？
@、Elasticsearch對於大數據量（上億量級）的聚合如何實現？
@、在併發情況下，Elasticsearch如果保證讀寫一致？
@、ElasticSearch中的集羣、節點、索引、文檔、類型是什麼？
@、Lucene和Solr和Elasticsearch的區別
Lucene
Lucene是apache下的一個子項目，是一個開放源代碼的全文檢索引擎工具包，但它不是一個完整的全文檢索引擎，而是一個全文檢索引擎的架構，提供了完整的查詢引擎和索引引擎，部分文本分析引擎。官網地址：https://lucene.apache.org/
Solr
Solr是一個高性能，採用Java5開發，基於Lucene的全文搜索服務器。同時對其進行了擴展，提供了比Lucene更爲豐富的查詢語言，同時實現了可配置、可擴展並對查詢性能進行了優化，並且提供了一個完善的功能管理界面，是一款非常優秀的全文搜索引擎。官網地址：http://lucene.apache.org/solr/
Elasticsearch
Elasticsearch跟Solr一樣，也是一個基於Lucene的搜索服務器，它提供了一個分佈式多用戶能力的全文搜索引擎，基於RESTful web接口。官網地址：https://www.elastic.co/products/elasticsearch
@、Elasticsearch的優缺點
優點：
1.Elasticsearch是分佈式的。不需要其他組件，分發是實時的，被叫做”Push replication”。
2.Elasticsearch 完全支持 Apache Lucene 的接近實時的搜索。
3.處理多租戶（multitenancy）不需要特殊配置，而Solr則需要更多的高級設置。
4.Elasticsearch 採用 Gateway 的概念，使得完備份更加簡單。
5.各節點組成對等的網絡結構，某些節點出現故障時會自動分配其他節點代替其進行工作。
缺點：
1.只有一名開發者（當前Elasticsearch GitHub組織已經不只如此，已經有了相當活躍的維護者）
2.還不夠自動（不適合當前新的Index Warmup API）
@、Solr的優缺點：優點
1.Solr有一個更大、更成熟的用戶、開發和貢獻者社區。
2.支持添加多種格式的索引，如：HTML、PDF、微軟 Office 系列軟件格式以及 JSON、XML、CSV 等純文本格式。
3.Solr比較成熟、穩定。
4.不考慮建索引的同時進行搜索，速度更快。
缺點
1.建立索引時，搜索效率下降，實時索引搜索效率不高。
@、Elasticsearch 與 Solr 的比較
1.二者安裝都很簡單；
2.Solr 利用 Zookeeper 進行分佈式管理，而 Elasticsearch 自身帶有分佈式協調管理功能;
3.Solr 支持更多格式的數據，而 Elasticsearch 僅支持json文件格式；
4.Solr 官方提供的功能更多，而 Elasticsearch 本身更注重於核心功能，高級功能多有第三方插件提供；
5.Solr 在傳統的搜索應用中表現好於 Elasticsearch，但在處理實時搜索應用時效率明顯低於 Elasticsearch。
6.Solr 是傳統搜索應用的有力解決方案，但 Elasticsearch 更適用於新興的實時搜索應用。
使用案例：
1.維基百科使用Elasticsearch來進行全文搜做並高亮顯示關鍵詞，以及提供search-as-you-type、did-you-mean等搜索建議功能。
2.英國衛報使用Elasticsearch來處理訪客日誌，以便能將公衆對不同文章的反應實時地反饋給各位編輯。
3.StackOverflow將全文搜索與地理位置和相關信息進行結合，以提供more-like-this相關問題的展現。
4.GitHub使用Elasticsearch來檢索超過1300億行代碼。
5.每天，Goldman Sachs使用它來處理5TB數據的索引，還有很多投行使用它來分析股票市場的變動。
@、solr如何實現搜索的？
倒排索引，先抽取文檔中詞，並建立詞與文檔id的映射關係，然後查詢的時候會根據詞去查詢文檔id，並查詢出文檔
Solr過濾器Solr的過濾器對接收到的標記流（TokenStream ）做額外的處理
過濾查詢，在查詢時設置
@、Solr原理
Solr是基於Lucene開發的全文檢索服務器，而Lucene就是一套實現了全文檢索的api，其本質就是一個全文檢索的過程。全文檢索就是把原始文檔根據一定的規則拆分成若干個關鍵詞，然後根據關鍵詞創建索引，當查詢時先查詢索引找到對應的關鍵詞，並根據關鍵詞找到對應的文檔，也就是查詢結果，最終把查詢結果展示給用戶的過程
@、Solr基於什麼
基於lucene搜索庫的一個搜索引擎框架，lucene是一個開放源碼的全文檢索引擎工具包
@、solr怎麼設置搜索結果排名靠前
設置文檔中域的boost值，值越高相關性越高，排名就靠前
@、IK分詞器原理
本質上是詞典分詞，在內存中初始化一個詞典，然後在分詞過程中逐個讀取字符，和字典中的字符相匹配，把文檔中的所有詞語拆分出來的過程
@、solr的索引查詢爲什麼比數據庫要快
Solr使用的是Lucene API實現的全文檢索。全文檢索本質上是查詢的索引。而數據庫中並不是所有的字段都建立的索引，更何況如果使用like查詢時很大的可能是不使用索引，所以使用solr查詢時要比查數據庫快
@、solr索引庫個別數據索引丟失怎麼辦
首先Solr是不會丟失個別數據的。如果索引庫中缺少數據，那就向索引庫中添加
@、Lucene索引優化
直接使用Lucene實現全文檢索已經是過時的方案，推薦使用solr。Solr已經提供了完整的全文檢索解決方案
多張表的數據導入solr(解決id衝突)在schema.xml中添加uuid，然後solrconfig那邊修改update的部分，改爲使用uuid生成
@、solr如何分詞，新增詞和禁用詞如何解決
schema.xml文件中配置一個IK分詞器，然後域指定分詞器爲IK
新增詞添加到詞典配置文件中ext.dic，禁用詞添加到禁用詞典配置文件中stopword.dic，然後在schema.xml文件中配置禁用詞典：<filter class="solr.StopFilterFactory" ignore="true" words="/禁止詞文件目錄"/>
@、solr多條件組合查詢
創建多個查詢對象，指定他們的組合關係，Occur.MUST（必須滿足and），Occur.SHOULD（應該滿足or），Occur.MUST_NOT（必須不滿足not）
@、elasticsearch 瞭解多少，說說你們公司 es 的集羣架構，索引數據大小，分片有多少，以及一些調優手段。elasticsearch 的倒排索引是什麼。
ElasticSearch（簡稱ES）是一個分佈式、Restful的搜索及分析服務器，設計用於分佈式計算；能夠達到實時搜索，穩定，可靠，快速。和Apache Solr一樣，它也是基於Lucence的索引服務器，而ElasticSearch對比Solr的優點在於：
輕量級：安裝啓動方便，下載文件之後一條命令就可以啓動。
Schema free：可以向服務器提交任意結構的JSON對象，Solr中使用schema.xml指定了索引結構。
多索引文件支持：使用不同的index參數就能創建另一個索引文件，Solr中需要另行配置。
分佈式：Solr Cloud的配置比較複雜。
倒排索引是實現“單詞-文檔矩陣”的一種具體存儲形式，通過倒排索引，可以根據單詞快速獲取包含這個單詞的文檔列表。倒排索引主要由兩個部分組成：“單詞詞典”和“倒排文件”。
@、elasticsearch 索引數據多了怎麼辦，如何調優，部署。
使用bulk API
初次索引的時候，把 replica 設置爲 0
增大 threadpool.index.queue_size
增大 indices.memory.index_buffer_size
增大 index.translog.flush_threshold_ops
增大 index.translog.sync_interval
增大 index.engine.robin.refresh_interval
http://www.jianshu.com/p/5eeeeb4375d4
@、lucence 內部結構是什麼
索引(Index)： 在Lucene中一個索引是放在一個文件夾中的。 如上圖，同一文件夾中的所有的文件構成一個Lucene索引。
段(Segment)： 一個索引可以包含多個段，段與段之間是獨立的，添加新文檔可以生成新的段，不同的段可以合併。
segments.gen和segments_X是段的元數據文件，也即它們保存了段的屬性信息。
文檔(Document)： 文檔是我們建索引的基本單位，不同的文檔是保存在不同的段中的，一個段可以包含多篇文檔。
新添加的文檔是單獨保存在一個新生成的段中，隨着段的合併，不同的文檔合併到同一個段中。
域(Field)：
一篇文檔包含不同類型的信息，可以分開索引，比如標題，時間，正文，作者等，都可以保存在不同的域裏。 不同域的索引方式可以不同，在真正解析域的存儲的時候，我們會詳細解讀。
詞(Term)：
詞是索引的最小單位，是經過詞法分析和語言處理後的字符串。
@、solr和lucene的區別
Solr和Lucene的本質區別有以下三點：搜索服務器，企業級和管理。Lucene本質上是搜索庫，不是獨立的應用程序，而Solr是。Lucene專注於搜索底層的建設，而Solr專注於企業應用。Lucene不負責支撐搜索服務所必須的管理，而Solr負責。所以說，一句話概括Solr: Solr是Lucene面向企業搜索應用的擴展
Lucene: 是一個索引與搜索類庫，而不是完整的程序。
Solr：是一個高性能，採用Java5開發，基於Lucene的一個獨立的企業級搜索應用服務器，它對外提供類似於Web-service的API接口。
solr 實現全文檢索索引流程：客戶端---》solr 服務器(發送post請求,xml文檔包含filed，solr實現對索引的維護)
搜索流程：客戶端---》solr 服務器(發送get 請求，服務器返回一個xml 文檔)
solr和lucene之間的區別lucene全文檢索的工具包,jar包
solr 全文檢索服務器,單獨運行的servlet容器
@、ElasticSearch使用場景
ElasticSearch作爲一個建立在全文搜索引擎Apache Lucene基礎上的實時的分佈式搜索和分析引擎，適用於處理實時搜索應用場景。此外，使用ElasticSearch全文搜索引擎，還可以支持多詞條查詢、匹配度與權重、自動聯想、拼寫糾錯等高級功能。因此，可以使用 ElasticSearch作爲關係型數據庫全文搜索的功能補充，將要進行全文搜索的數據緩存一份到 ElasticSearch上，達到處理複雜的業務與提高查詢速度的目的。
@、爲什麼要使用Elasticsearch?
因爲在我們商城中的數據，將來會非常多，所以採用以往的模糊查詢，模糊查詢前置配置，會放棄索引，導致商品查詢是全表掃面，在百萬級別的數據庫中，效率非常低下，而我們使用ES做一個全文索引，我們將經常查詢的商品的某些字段，比如說商品名，描述、價格還有id這些字段我們放入我們索引庫裏，可以提高查詢速度。
@、Elasticsearch是如何實現Master選舉的？
Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分；
對所有可以成爲master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然後選出第一個（第0位）節點，暫且認爲它是master節點。
如果對某個節點的投票數達到一定的值（可以成爲master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
補充：master節點的職責主要包括集羣、節點和索引的管理，不負責文檔級別的管理；data節點可以關閉http功能。@、Elasticsearch中的節點（比如共20個），其中的10個選了一個master，另外10個選了另一個master，怎麼辦？
當集羣master候選數量不小於3個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；
當候選數量爲兩個時，只能修改爲唯一的一個master候選，其他作爲data節點，避免腦裂問題。@、詳細描述一下Elasticsearch索引文檔的過程。
協調節點默認使用文檔ID參與計算（也支持通過routing），以便爲路由提供合適的分片。
shard = hash(document_id) % (num_of_primary_shards)
當分片所在的節點接收到來自協調節點的請求後，會將請求寫入到Memory Buffer，然後定時（默認是每隔1秒）寫入到Filesystem Cache，這個從Momery Buffer到Filesystem Cache的過程就叫做refresh；
當然在某些情況下，存在Momery Buffer和Filesystem Cache的數據可能會丟失，ES是通過translog的機制來保證數據的可靠性的。其實現機制是接收到請求後，同時也會寫入到translog中，當Filesystem cache中的數據寫入到磁盤中時，纔會清除掉，這個過程叫做flush；
在flush過程中，內存中的緩衝將被清除，內容被寫入一個新段，段的fsync將創建一個新的提交點，並將內容刷新到磁盤，舊的translog將被刪除並開始一個新的translog。
flush觸發的時機是定時觸發（默認30分鐘）或者translog變得太大（默認爲512M）時；@、Elasticsearch索引文檔的過程
@、詳細描述一下Elasticsearch更新和刪除文檔的過程刪除和更新也都是寫操作，但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
磁盤上的每個段都有一個相應的.del文件。當刪除請求發送後，文檔並沒有真的被刪除，而是在.del文件中被標記爲刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合併時，在.del文件中被標記爲刪除的文檔將不會被寫入新段。
在新的文檔被創建時，Elasticsearch會爲該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del文件中被標記爲刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。@、詳細描述一下Elasticsearch搜索的過程
搜索被執行成一個兩階段過程，我們稱之爲 Query Then Fetch；
在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜索並構建一個匹配文檔的大小爲 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。
每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合併這些值到自己的優先隊列中來產生一個全局排序後的結果列表。
接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回並向相關的分片提交多個 GET 請求。每個分片加載並 豐富 文檔，如果有需要的話，接着返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。
補充：Query Then Fetch的搜索類型在文檔相關性打分的時候參考的是本分片的數據，這樣在文檔數量較少的時候可能不夠準確，DFS Query Then Fetch增加了一個預查詢的處理，詢問Term和Document frequency，這個評分更準確，但是性能會變差。@、Elasticsearch執行搜索的過程
@、Elasticsearch在部署時，對Linux的設置有哪些優化方法？64 GB 內存的機器是非常理想的， 但是32 GB 和16 GB 機器也是很常見的。少於8 GB 會適得其反。
如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內核提供的額外併發遠勝過稍微快一點點的時鐘頻率。
如果你負擔得起 SSD，它將遠遠超出任何旋轉介質。 基於 SSD 的節點，查詢和索引性能都有提升。如果你負擔得起，SSD 是一個好的選擇。
即使數據中心們近在咫尺，也要避免集羣跨越多個數據中心。絕對要避免集羣跨越大的地理距離。
請確保運行你應用程序的 JVM 和服務器的 JVM 是完全一樣的。 在 Elasticsearch 的幾個地方，使用 Java 的本地序列化。
通過設置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集羣重啓的時候避免過多的分片交換，這可能會讓數據恢復從數個小時縮短爲幾秒鐘。
Elasticsearch 默認被配置爲使用單播發現，以防止節點無意中加入集羣。只有在同一臺機器上運行的節點纔會自動組成集羣。最好使用單播代替組播。
不要隨意修改垃圾回收器（CMS）和各個線程池的大小。
把你的內存的（少於）一半給 Lucene（但不要超過 32 GB！），通過ES_HEAP_SIZE 環境變量設置。
內存交換到磁盤對服務器性能來說是致命的。如果內存交換到磁盤上，一個 100 微秒的操作可能變成 10 毫秒。 再想想那麼多 10 微秒的操作時延累加起來。 不難看出 swapping 對於性能是多麼可怕。
Lucene 使用了大量的文件。同時，Elasticsearch 在節點和 HTTP 客戶端之間進行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應該增加你的文件描述符，設置一個很大的值，如 64,000。
補充：索引階段性能提升方法
使用批量請求並調整其大小：每次批量數據 5–15 MB 大是個不錯的起始點。
存儲：使用 SSD
段和合並：Elasticsearch 默認值是 20 MB/s，對機械磁盤應該是個不錯的設置。如果你用的是 SSD，可以考慮提高到 100–200 MB/s。如果你在做批量導入，完全不在意搜索，你可以徹底關掉合併限流。另外還可以增加 index.translog.flush_threshold_size 設置，從默認的 512 MB 到更大一些的值，比如 1 GB，這可以在一次清空觸發的時候在事務日誌裏積累出更大的段。
如果你的搜索結果不需要近實時的準確度，考慮把每個索引的index.refresh_interval 改到30s。
如果你在做大批量導入，考慮通過設置index.number_of_replicas: 0 關閉副本。
@、對於GC方面，在使用Elasticsearch時要注意什麼？
SEE：https://elasticsearch.cn/article/32
倒排詞典的索引需要常駐內存，無法GC，需要監控data node上segment memory增長趨勢。
各類緩存，field cache, filter cache, indexing cache, bulk queue等等，要設置合理的大小，並且要應該根據最壞的情況來看heap是否夠用，也就是各類緩存全部佔滿的時候，還有heap空間可以分配給其他任務嗎？避免採用clear cache等“自欺欺人”的方式來釋放內存。
避免返回大量結果集的搜索與聚合。確實需要大量拉取數據的場景，可以採用scan & scroll api來實現。
cluster stats駐留內存並無法水平擴展，超大規模集羣可以考慮分拆成多個集羣通過tribe node連接。
想知道heap夠不夠，必須結合實際應用場景，並對集羣的heap使用情況做持續的監控。@、Elasticsearch對於大數據量（上億量級）的聚合如何實現？
Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個字段的基數，即該字段的distinct或者unique值的數目。它是基於HLL算法的。HLL 會先對我們的輸入作哈希運算，然後根據哈希運算的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制內存的使用（更精確 ＝ 更多內存）；小的數據集精度是非常高的；我們可以通過配置參數，來設置去重需要的固定內存使用量。無論數千還是數十億的唯一值，內存使用量只與你配置的精確度相關 .
@、在併發情況下，Elasticsearch如果保證讀寫一致？
可以通過版本號使用樂觀併發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的衝突；
另外對於寫操作，一致性級別支持quorum/one/all，默認爲quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因爲網絡等原因導致寫入副本失敗，這樣該副本被認爲故障，分片將會在一個不同的節點上重建。
對於讀操作，可以設置replication爲sync(默認)，這使得操作在主分片和副本分片都完成後纔會返回；如果設置replication爲async時，也可以通過設置搜索請求參數_preference爲primary來查詢主分片，確保文檔是最新版本。@、如何監控Elasticsearch集羣狀態？
Marvel 讓你可以很簡單的通過 Kibana 監控 Elasticsearch。你可以實時查看你的集羣健康狀態和性能，也可以分析過去的集羣、索引和節點指標
@、是否瞭解字典樹？常用字典數據結構如下所示：
常用字典數據結構
Trie的核心思想是空間換時間，利用字符串的公共前綴來降低查詢時間的開銷以達到提高效率的目的。它有3個基本性質：
根節點不包含字符，除根節點外每一個節點都只包含一個字符。
從根節點到某一節點，路徑上經過的字符連接起來，爲該節點對應的字符串。
每個節點的所有子節點包含的字符都不相同。字典樹
可以看到，trie樹每一層的節點數是26^i級別的。所以爲了節省空間，我們還可以用動態鏈表，或者用數組來模擬動態。而空間的花費，不會超過單詞數×單詞長度。
實現：對每個結點開一個字母集大小的數組，每個結點掛一個鏈表，使用左兒子右兄弟表示法記錄這棵樹；
對於中文的字典樹，每個節點的子節點用一個哈希表存儲，這樣就不用浪費太大的空間，而且查詢速度上可以保留哈希的複雜度O(1)。@、拼寫糾錯是如何實現的？
拼寫糾錯是基於編輯距離來實現；編輯距離是一種標準的方法，它用來表示經過插入、刪除和替換操作從一個字符串轉換到另外一個字符串的最小操作步數；
編輯距離的計算過程：比如要計算batyu和beauty的編輯距離，先創建一個7×8的表（batyu長度爲5，coffee長度爲6，各加2），接着，在如下位置填入黑色數字。其他格的計算過程是取以下三個值的最小值：如果最上方的字符等於最左方的字符，則爲左上方的數字。否則爲左上方的數字+1。（對於3,3來說爲0）
左方數字+1（對於3,3格來說爲2）
上方數字+1（對於3,3格來說爲2）
最終取右下角的值即爲編輯距離的值3。
編輯距離
對於拼寫糾錯，我們考慮構造一個度量空間（Metric Space），該空間內任何關係滿足以下三條基本條件：
d(x,y) = 0 -- 假如x與y的距離爲0，則x=y
d(x,y) = d(y,x) -- x到y的距離等同於y到x的距離
d(x,y) + d(y,z) >= d(x,z) -- 三角不等式
根據三角不等式，則滿足與query距離在n範圍內的另一個字符轉B，其與A的距離最大爲d+n，最小爲d-n。
BK樹的構造就過程如下：每個節點有任意個子節點，每條邊有個值表示編輯距離。所有子節點到父節點的邊上標註n表示編輯距離恰好爲n。比如，我們有棵樹父節點是”book”和兩個子節點”cake”和”books”，”book”到”books”的邊標號1，”book”到”cake”的邊上標號4。從字典裏構造好樹後，無論何時你想插入新單詞時，計算該單詞與根節點的編輯距離，並且查找數值爲d(neweord, root)的邊。遞歸得與各子節點進行比較，直到沒有子節點，你就可以創建新的子節點並將新單詞保存在那。比如，插入”boo”到剛纔上述例子的樹中，我們先檢查根節點，查找d(“book”, “boo”) = 1的邊，然後檢查標號爲1的邊的子節點，得到單詞”books”。我們再計算距離d(“books”, “boo”)=2，則將新單詞插在”books”之後，邊標號爲2。
查詢相似詞如下：計算單詞與根節點的編輯距離d，然後遞歸查找每個子節點標號爲d-n到d+n（包含）的邊。假如被檢查的節點與搜索單詞的距離d小於n，則返回該節點並繼續查詢。比如輸入cape且最大容忍距離爲1，則先計算和根的編輯距離d(“book”, “cape”)=4，然後接着找和根節點之間編輯距離爲3到5的，這個就找到了cake這個節點，計算d(“cake”, “cape”)=1，滿足條件所以返回cake，然後再找和cake節點編輯距離是0到2的，分別找到cape和cart節點，這樣就得到cape這個滿足條件的結果。@、ElasticSearch中的集羣、節點、索引、文檔、類型是什麼？
羣集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，並提供跨所有節點的聯合索引和搜索功能。羣集由唯一名稱標識，默認情況下爲“elasticsearch”。此名稱很重要，因爲如果節點設置爲按名稱加入羣集，則該節點只能是羣集的一部分。
節點是屬於集羣一部分的單個服務器。它存儲數據並參與羣集索引和搜索功能。
索引就像關係數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，並且可以有零個或多個副本分片。 MySQL =>數據庫 ElasticSearch =>索引
文檔類似於關係數據庫中的一行。不同之處在於索引中的每個文檔可以具有不同的結構（字段），但是對於通用字段應該具有相同的數據類型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔
類型是索引的邏輯類別/分區，其語義完全取決於用戶。@、ElasticSearch中的分片是什麼?
在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。
索引 - 在Elasticsearch中，索引是文檔的集合。
分片 -因爲Elasticsearch是一個分佈式搜索引擎，所以索引通常被分割成分佈在多個節點上的被稱爲分片的元素。