-------------------ELK(Elasticsearch+Logstash+Kiabana)-------------
EK和solr對比
1、當單純的對已有數據進行搜索時，Solr更快
當實時建立索引時, Solr會產生io阻塞，查詢性能較差 。（Solr的架構不適合實時搜索的應用，適合不會新增數據的純檢索數據場景）
實時建立索引 Elasticsearch具有明顯的優勢（ES初始新字段進入會自動創建索引）
隨着數據量的增加，Solr的搜索效率會變得更低，而Elasticsearch卻沒有明顯的變化
2、
3、
4、
5、
ELK(Elasticsearch+Logstash+Kiabana)的原理？
安裝過程：
1、安裝Elasticsearch
2、 Logstash安裝，logstash改配置，監聽業務服務器的日誌，將其輸入；並且配置好每個業務系統輸出到ES的索引是啥
2、安裝Kinaba，連接ES地址，把日誌顯示到客戶端
原理圖：
Elasticsearch是存儲數據.
Logstash是蒐集、分析、過濾日誌.（不同業務查日誌的原理----logstash解析成不同的index存入ES）
Kibana是客戶端顯示。
Elasticsearch的優點？和關係型數據庫的區別是啥？
一、優點：是一個基於Lucene構建的，分佈式全文搜索引擎。 還是一個分佈式文檔數據庫，每個字段均是被索引的數據且可被搜索，快速存儲、搜索和分析大量數據。還支持模糊分詞查詢
橫向可擴展性:只需要增加臺服務器，做一點兒配置，啓動一下Elasticsearch就可以併入集羣。
二、結構區別：
關係數據庫 ⇒ 數據庫 ⇒ 表 ⇒ 行 ⇒ 列(Columns) （提前創建表定義好字段）
Elasticsearch ⇒ 索引(Index) ⇒ 類型(type) ⇒ 文檔(Docments) ⇒ 字段(Fields) （動態映射字段）
-------------------ELK+Kafka-------------
參考：https://blog.csdn.net/qq_36807862/article/details/81283568
？工作原理？
普通ELK缺點：Logstash運行佔用CPU和內存較高，並且Client和server之間沒有消息緩存，如果server宕機不可用，會存在消息丟失的風險；
改進：引入消息隊列機制Kafka，保證了即使Logstash Server因故障停止運行，數據也會緩存下來，避免了數據丟失；
（還能再改進---官方推薦：將收集端logstash替換爲beats，更靈活，消耗資源更少）
？的作用或優點？
-------------------Elasticsearch-------------
？ES集羣核心原理？
1、每個索引會被分成多個分片shards進行存儲，默認創建索引是分配5個分片進行存儲。
每個分片都會分佈式部署在多個不同的節點上進行部署，該分片成爲primary shards。
注意：索引的主分片primary shards定義好後，後面不能做修改。
2、爲了實現高可用數據的高可用，主分片可以有對應的備分片replics shards，replic shards分片承載了負責容錯、以及請求的負載均衡(寫主，讀主備)。
注意: 每一個主分片爲了實現高可用，都會有自己對應的備分片，主分片對應的備分片不能存放同一臺服務器上(避免宕機就一起掛)。，主分片primary shards可以和其他replics shards存放在同一個node節點上。
？的作用或優點（爲什麼要使用Elasticsearch）？
1、（大型電商商品搜索系統、網盤搜索引擎）門戶網站都用es查詢，因爲快，原因：做了分詞查詢，查詢範圍也廣。（採用以往的mysql模糊查詢，%在前面會放棄索引，全表掃面，百萬級別，效率非常低）
1、ELK日誌收集（現在kafka比它更高效）（同上）
?ES分詞查詢+自定義拓展熱詞?
//執行分詞器信息查詢命令（用默認的），只會顯示a41、奧、迪.
存在問題1：中文單個字分詞問題。
解決1：//下載ik插件---把ik放入es插件目錄plugins下，然後再查分詞器信息（換成ik），就不會再按中文單個字分詞了。
存在問題2：王者榮耀，這樣的詞會分成王者和榮耀，沒有‘王者榮耀’這個熱詞。
解決2：//自定義擴展字典---關鍵熱詞
在/usr/local/elasticsearch-6.4.3/plugins/ik/config目錄下，自定義建個文件放入一些關鍵熱詞
比如，建個custom/new_word.dic文件，在裏面放入：
王者榮耀
？ES數據結構？
索引-類型（最新版本移除）-文檔-字段
？Term與Match區別？
Term查詢不會對字段進行分詞查詢，會採用精確匹配。
Match會根據該字段的分詞器，進行分詞查詢。
GET mymayikt/user/_search
{
"query": {
"term": {
"name": "xiaoming"
}
}
}
ES是如何解決高併發？
ES是一個分佈式全文檢索框架，隱藏了複雜的處理機制，內部使用 分片機制、集羣發現、分片負載均衡請求路由。
？ES是如何解決分佈式日誌收集？
1、傳統系統日誌收集的問題：集羣多臺機器時，查問題日誌需要查多臺，很麻煩，效率低
2、Logstash操作工作原理：蒐集輸入、解析、輸出日誌.
3、分佈式日誌收集ELK原理： Logstash蒐集輸入、解析、輸出日誌， Elasticsearch是存儲數據，Kibana是客戶端顯示。
4、Elasticsearch+Logstash+Kiabana整合
5、Logstash將數據推送到ES
6、Kiabana圖形界面展示ES日誌信息
請問mongodb ， elasticsearch ， mysql各有什麼優缺點？
對比：
1、在存儲上，mongodb和es是document格式的存儲，mysql是行格式的、需要顯式定義字段。
2、在架構上，es天然就是分佈式的，很容易橫向擴容，而mongo和mysql不行。
3、在針對場景下，es無法做到實時，而mysql和mongo可以，es需要額外考慮下場景是否適用。
4、在數據存儲量及性能上，mysql由於其索引在數據量大到一定級別後會出現性能衰減，而mongo和es只要給足足夠內存就沒太大問題（mongo內存不足時性能衰減的更爲厲害，es不明顯）。
5、插入速度上如果正確的配置mysql其性能並不低，當然相對於正常狀態mongo和es而言還是差了一個到多個量級（es>mongo>mysql）。查詢速度這個主要看索引和數量，這個不太好說，mongo謎一樣的索引選擇曾經讓我糾結過很久，在需要複雜關聯查詢的時候建議優先考慮mysql。
6、資源開銷上當數據量上去了後如果爲了維持性能的話，es喫內存的能力絕對可以傲視羣雄，但畢竟沒有不喫草就能跑的快的馬兒。
易用性上當然是mysql>mongo>es，如果考慮使用mysql的話可以再考慮下postgresql，雖然小衆點，但有些mysql功能上的缺失會讓你寫sql寫到哭。 其實刨掉全文檢索場景，mysql（5.6以後）加上良好的設計就能很好的支持絕大部分需求了，所以不要太過於糾結到底用啥了。
選擇：
1、業務所需字段已經確定了，就用mysql，實時新增查詢都挺快的。
2、但是某些場景下業務所需的字段不確定，需要實時新增新的字段且查詢，用MongoDB方便點。
3、然後就是es，做大量數據的存儲和查詢，性能也不錯，就是新插入的數據，並不會馬上被搜索到，起碼也得幾秒鐘之後才能檢索出來。
Elasticsearch和MongoDB簡要對比？
相同點：
1、都是以json格式管理數據的nosql文檔型數據庫。
2、都支持CRUD操作。
3、都支持聚合和全文檢索。
4、都支持分片和複製。
5、都支持閹割版的join操作。
6、都支持處理超大規模數據。
7、目前都不支持事務或者叫支持閹割版的事務。
不同點：
1、es是java編寫，通過RESTFul接口操作數據。mongodb是C++編寫，通過driver操作數據。（es對java開發更有好，利於排查理解）
2、mongodb的分片有hash和range兩種方式，es只有hash一種。
3、es是天生分佈式，主副分片自動分配和複製，開箱即用。mongodb的分佈式是由“前置查詢路由+配置服務+shard集合”，需要手動配置集羣服務。
4、內部存儲ES是倒排索引+docvalues+fielddata。mongodb暫時未知。
5、es全文檢索有強大的分析器且可以靈活組合，查詢時智能匹配。mongodb的全文檢索字段個數有限制。
6、es所有字段自動索引，mongodb的字段需要手動索引。
7、es非實時有數據丟失窗口。mongodb實時理論上無數據丟失風險。
-------------------ElasticSearch常見經典面試題-------------
ElasticSearch常見經典面試題
1.爲什麼要使用Elasticsearch?
因爲在我們商城中的數據，將來會非常多，所以採用以往的模糊查詢，模糊查詢前置配置，會放棄索引，導致商品查詢是全表掃面，在百萬級別的數據庫中，效率非常低下，而我們使用ES做一個全文索引，將經常查詢的商品的某些字段，比如說商品名，描述、價格還有id這些字段放入我們索引庫裏，可以提高查詢速度。
2.Elasticsearch是如何實現Master選舉的？
Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分；
對所有可以成爲master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然後選出第一個（第0位）節點，暫且認爲它是master節點。
如果對某個節點的投票數達到一定的值（可以成爲master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
補充：master節點的職責主要包括集羣、節點和索引的管理，不負責文檔級別的管理；data節點可以關閉http功能。
3.Elasticsearch中的節點（比如共20個），其中的10個選了一個master，另外10個選了另一個master，怎麼辦？
當集羣master候選數量不小於3個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點,投票一半以上來解決腦裂問題；
當候選數量爲兩個時，只能修改爲唯一的一個master候選，其他作爲data節點，避免腦裂問題。
4.詳細描述一下Elasticsearch索引文檔的過程。
協調節點默認使用文檔ID參與計算（也支持通過routing），以便爲路由提供合適的分片。
shard = hash(文檔ID) % (分片機器數)
當分片所在的節點接收到來自協調節點的請求後，會將請求寫入到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）時；
5.詳細描述一下Elasticsearch更新和刪除文檔的過程
刪除和更新也都是寫操作，但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
磁盤上的每個段都有一個相應的.del文件。當刪除請求發送後，文檔並沒有真的被刪除，而是在.del文件中被標記爲刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合併時，在.del文件中被標記爲刪除的文檔將不會被寫入新段。
在新的文檔被創建時，Elasticsearch會爲該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del文件中被標記爲刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。
6.詳細描述一下Elasticsearch搜索的過程
搜索被執行成一個兩階段過程，我們稱之爲 Query Then Fetch；
在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜索並構建一個匹配文檔的大小爲 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。
每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合併這些值到自己的優先隊列中來產生一個全局排序後的結果列表。
接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回並向相關的分片提交多個 GET 請求。每個分片加載並 豐富 文檔，如果有需要的話，接着返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。
補充：Query Then Fetch的搜索類型在文檔相關性打分的時候參考的是本分片的數據，這樣在文檔數量較少的時候可能不夠準確，DFS Query Then Fetch增加了一個預查詢的處理，詢問Term和Document frequency，這個評分更準確，但是性能會變差。
9.Elasticsearch對於大數據量（上億量級）的聚合如何實現？
Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個字段的基數，即該字段的distinct或者unique值的數目。它是基於HLL算法的。HLL 會先對我們的輸入作哈希運算，然後根據哈希運算的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制內存的使用（更精確 ＝ 更多內存）；小的數據集精度是非常高的；我們可以通過配置參數，來設置去重需要的固定內存使用量。無論數千還是數十億的唯一值，內存使用量只與你配置的精確度相關 .
10.在併發情況下，Elasticsearch如果保證讀寫一致？
可以通過版本號使用樂觀併發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的衝突；
另外對於寫操作，一致性級別支持quorum/one/all，默認爲quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因爲網絡等原因導致寫入副本失敗，這樣該副本被認爲故障，分片將會在一個不同的節點上重建。
對於讀操作，可以設置replication爲sync(默認)，這使得操作在主分片和副本分片都完成後纔會返回；如果設置replication爲async時，也可以通過設置搜索請求參數_preference爲primary來查詢主分片，確保文檔是最新版本。
14.ElasticSearch中的集羣、節點、索引、文檔、類型是什麼？
羣集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，並提供跨所有節點的聯合索引和搜索功能。羣集由唯一名稱標識，默認情況下爲“elasticsearch”。此名稱很重要，因爲如果節點設置爲按名稱加入羣集，則該節點只能是羣集的一部分。
節點是屬於集羣一部分的單個服務器。它存儲數據並參與羣集索引和搜索功能。
索引就像關係數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，並且可以有零個或多個副本分片。 MySQL =>數據庫 ElasticSearch =>索引
文檔類似於關係數據庫中的一行。不同之處在於索引中的每個文檔可以具有不同的結構（字段），但是對於通用字段應該具有相同的數據類型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔
類型是索引的邏輯類別/分區，其語義完全取決於用戶。
15.ElasticSearch中的分片是什麼?
在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。
索引 - 在Elasticsearch中，索引是文檔的集合。
分片 -因爲Elasticsearch是一個分佈式搜索引擎，所以索引通常被分割成分佈在多個節點上的被稱爲分片的元素。
問題一：
什麼是ElasticSearch？
Elasticsearch是一個基於Lucene的搜索引擎。它提供了具有HTTP Web界面和無架構JSON文檔的分佈式，多租戶能力的全文搜索引擎。Elasticsearch是用Java開發的，根據Apache許可條款作爲開源發佈。
問題三：
Elasticsearch中的倒排索引是什麼？
倒排索引是搜索引擎的核心。搜索引擎的主要目標是在查找發生搜索條件的文檔時提供快速搜索。倒排索引是一種像數據結構一樣的散列圖，可將用戶從單詞導向文檔或網頁。它是搜索引擎的核心。其主要目標是快速搜索從數百萬文件中查找數據。
問題四：
ElasticSearch中的集羣、節點、索引、文檔、類型是什麼？
羣集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，並提供跨所有節點的聯合索引和搜索功能。羣集由唯一名稱標識，默認情況下爲“elasticsearch”。此名稱很重要，因爲如果節點設置爲按名稱加入羣集，則該節點只能是羣集的一部分。
節點是屬於集羣一部分的單個服務器。它存儲數據並參與羣集索引和搜索功能。
索引就像關係數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，並且可以有零個或多個副本分片。 MySQL =>數據庫 ElasticSearch =>索引
文檔類似於關係數據庫中的一行。不同之處在於索引中的每個文檔可以具有不同的結構（字段），但是對於通用字段應該具有相同的數據類型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔
類型是索引的邏輯類別/分區，其語義完全取決於用戶。
問題五：
ElasticSearch是否有架構？
ElasticSearch可以有一個架構。架構是描述文檔類型以及如何處理文檔的不同字段的一個或多個字段的描述。Elasticsearch中的架構是一種映射，它描述了JSON文檔中的字段及其數據類型，以及它們應該如何在Lucene索引中進行索引。因此，在Elasticsearch術語中，我們通常將此模式稱爲“映射”。
Elasticsearch具有架構靈活的能力，這意味着可以在不明確提供架構的情況下索引文檔。如果未指定映射，則默認情況下，Elasticsearch會在索引期間檢測文檔中的新字段時動態生成一個映射。
問題六：
ElasticSearch中的分片是什麼？
在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。
索引 - 在Elasticsearch中，索引是文檔的集合。
分片 -因爲Elasticsearch是一個分佈式搜索引擎，所以索引通常被分割成分佈在多個節點上的被稱爲分片的元素。
問題七：
ElasticSearch中的副本是什麼？
一個索引被分解成碎片以便於分發和擴展。副本是分片的副本。一個節點是一個屬於一個集羣的ElasticSearch的運行實例。一個集羣由一個或多個共享相同集羣名稱的節點組成。
問題八：
ElasticSearch中的分析器是什麼？
在ElasticSearch中索引數據時，數據由爲索引定義的Analyzer在內部進行轉換。 分析器由一個Tokenizer和零個或多個TokenFilter組成。編譯器可以在一個或多個CharFilter之前。分析模塊允許您在邏輯名稱下注冊分析器，然後可以在映射定義或某些API中引用它們。
Elasticsearch附帶了許多可以隨時使用的預建分析器。或者，您可以組合內置的字符過濾器，編譯器和過濾器器來創建自定義分析器。
問題九：
什麼是ElasticSearch中的編譯器？
編譯器用於將字符串分解爲術語或標記流。一個簡單的編譯器可能會將字符串拆分爲任何遇到空格或標點的地方。Elasticsearch有許多內置標記器，可用於構建自定義分析器。
問題十一：
啓用屬性，索引和存儲的用途是什麼？
enabled屬性適用於各類ElasticSearch特定/創建領域，如index和size。用戶提供的字段沒有“已啓用”屬性。 存儲意味着數據由Lucene存儲，如果詢問，將返回這些數據。
存儲字段不一定是可搜索的。默認情況下，字段不存儲，但源文件是完整的。因爲您希望使用默認值(這是有意義的)，所以不要設置store屬性 該指數屬性用於搜索。
索引屬性只能用於搜索。只有索引域可以進行搜索。差異的原因是在分析期間對索引字段進行了轉換，因此如果需要的話，您不能檢索原始數據。