溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關ElasticSearch7的特性有哪些，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
首先要介紹下什么是自適應默認副本選擇，就是說 ElasticSearch 會去記錄各個數據節點過去的請求響應時間和在節點上的執行時間，還有節點上的線程池隊列大小來得出哪個節點的各項指標好，以后的這種請求就落到這個節點去。
Elasticsearch 6 和之前的版本，對同一分片的一系列搜索請求將以循環方式轉發給主分片和每個副本。如果一個節點正好開始了很長時間的垃圾回收（GC），這可能會帶來問題，搜索請求仍然可能被轉發到這種響應速度會很非常慢的節點，這就會對搜索延遲產生影響。
在6.1版本中，Elasticsearch官方添加了一個實驗性的自適應副本選擇的特性。每個節點會跟蹤和比較搜索請求與其他節點的耗時，并使用這個數據調整向特定節點上的分片發送請求的頻率。在官網的基準測試中，這會很顯著的提高搜索的吞吐量，官方說這種操作減少了99%的延遲。
這個配置在整個6.x的版本中被默認是禁用的。但是后來官方陸續從用戶那里得到反饋，用戶和官方都認為這個設置非常有用，所以官方在Elasticsearch 7.0.0中默認打開了它。
PUT /_cluster/settings
{
"transient": {
"cluster.routing.use_adaptive_replica_selection": true
}
}如果關閉這個功能，搜索的操作將會以循環方式發送到所有的索引分片。
Skip shard refreshes if a shard is "search idle
Elasticsearch 6 和之前的版本默認情況下會在后臺自動刷新索引數據。這也就是為什么Elasticsearch可以“近乎實時”得到搜索結果，默認情況下，搜索請求添加后一秒內就可以獲得結果。然而，如果不需要刷新的時候(例如，如果Elasticsearch沒有任何查詢搜索的任務)，那么這個功能就能對Elasticsearch的性能產生顯著的影響。
通過引入這種搜索空閑(search idle)的概念，Elasticsearch 7 在默認情況下，該分片如果在30秒內沒有過任何搜索行為，那么這個就會被認為是搜索空閑。 當分片處于這種階段的時候，所有原計劃的刷新任務都會被跳過，直到你有搜索的問題進來的時候才會觸發下一次的刷新任務。 這會提高 Elasticsearch 的吞吐量，我們都知道，當如果要大量的寫入數據或者重新構建索引的時候，關閉自動刷新進行數據寫入或者更新，速度是可以顯著提高的，這里同理。
很多公司在使用 Elasticsearch 的時候很亂來，其中比較多的就是過度分片，而分片數量的默認值可能是個造成這種現象的主要原因。Elasticsearch 6和之前的版本，每個索引默認有5個分片。如果有一個針對10個不同的應用的每日索引（按日建的索引，類似于數據庫的按日分表），并且每個應用程序默認有5個分片，那么每天將創建50個分片，即使每天只有幾個gb的索引數據，不久之后將會出現數千個分片。
索引生命周期管理是幫助實現這點的第一步: 提供了本地方法按大小來創建索引，而不是僅僅按天來創建索引，并且提供內置的收縮功能來減少每個索引的分片數量。 其次就是減少索引的默認分片數量。 當然，如果創建索引的時候我們依然可以自己設置分片數量，如果不設置就會是默認值1.
這個是重頭戲，這里我要插一下，2015年大四還沒畢業的時候，對這種索引技術不是非常深入了解，想要升級一個項目的Lucene版本，那時候用的還是3.x的版本，要升級到4.x，簡直是噩夢。
與每一個版本一樣，官方都是希望支持Lucene的最新的主要版本，以及它帶來的所有的特性。Elasticsearch 7.0 底層用的是 Lucene 8 ， Lucene 8為Elasticsearch的許多功能的改進奠定了基礎，包括對top-k查詢的搜索性能的改進（top-k,可以用于在海量數據里查找最大或者最小的K個值，我思考了下方法有很多，比如用默認的前1000個值的最小堆和所有數據進行對比；還可以對數據進行分割然后使用快排。。。），以及在保持速度的同時更好地組合相關信號標識進行搜索，提高性能。
在Elasticsearch 5.3中，官方引入了跨集群搜索的功能，允許用戶跨多個集群進行查詢。后面官方對跨集群搜索的這套功能進行了改進，增加了一些特性，最終將其用于棄用和替換tribe節點（tribe 節點，tribe節點是跨多個集群的聯合客戶端節點，通常用于從多個Elasticsearch集群檢索信息，使其看起來像一個組合集群，詳情可以去看下官方的跨集群搜索功能，根據官方的文檔，tribe 節點在7.0版本被移除廢棄。），從而實現聯合查詢。
在Elasticsearch 7.0中，官方為跨集群搜索添加了一種新的執行模式:在不必要的情況下減少往返的耗時。這種模式(ccs_minimize_roundtrips)可以在跨集群搜索查詢避免高延遲(例如，跨網絡)從而更快的得到搜索結果。
Elasticsearch 從設計之初就是易于擴展的，且這種設計能很好的應對災難性的故障。為了更好的支持這類需求，官方創建了一個可插拔的集群協調系統，其默認實現稱為Zen Discovery（大致的意思就是這個功能想簡單點來實現，你們用戶放心使用就好了，這個功能是官方引入的集群發現機制）， Elasticsearch使用量的急劇增加暴露了很多問題，例如，Zen的minimum_master_nodes設置經常配置錯誤，這會使群集更容易出現裂腦和丟失數據的風險。 跨集群（集群是動態的且非常大），因為維護此設置很困難。
在Elasticsearch 7.0，重新設計了集群協調層。 新的實現提供了安全的亞秒級的master選舉時間，而Zen可能要花幾秒鐘來選擇一個新的master，這對于關鍵時候的部署來說，這時間是寶貴的。刪除minimum_master_nodes設置后，集群的增長和收縮變得更安全、更容易，減少了因為系統錯誤配置埋坑。最重要的是，新的集群協調層為Elasticsearch的未來提供了強大的健壯性，確保將來可以為這個模塊設計更高級的功能擴展。
Elasticsearch使用時 7.0加了一個全新的斷路器，可以跟蹤JVM使用的總內存，如果請求導致預留的內存和實際堆使用量超過95%，則拒絕請求。官方還將更改默認的最大桶數search.max_buckets為10000，這在6及之前的版本中是不受限制的。在Elasticsearch 7這兩個改動，可以防止新手菜鳥第一次玩的時候運行大型查詢和聚合操作引起的集群故障。
官方在Elasticsearch 6.5中引入了一個beta功能，跨集群復制。現在在7.0這個功能已經完善成熟，可以用于生產環境。 以前版本的跨集群復制要求復制只能在新索引上開始，無法復制現有索引。現在，跨集群復制可以開始復制在6.7和7.0中啟用了軟刪除的現有索引，并且新索引默認為啟用了軟刪除。還引入了一些很新的技術防止follower嚴重落后于leader（沒有說明是啥新的技術），官方在特意在Kibana中添加了一個管理UI，用于配置遠程集群。
索引生命周期管理（ILM）是Elasticsearch 6.6中的beta功能。現在已將ILM正式從Beta版遷移到GA版！ ILM使得在Elasticsearch中管理數據的生命周期變得更簡單，包括數據在hot，warm，cold，delete階段之間的進度情況。可以通過Elasticsearch中的API來看，或者Kibana中漂亮的UI來創建有關數據如何在這些階段中移動的情況。
在Elasticsearch 6.7和7.0中，ILM現在可以管理凍結索引。凍結索引對于Elasticsearch中的長期數據存儲很有價值，并且相對于節點管理的數據量而言，需要的存儲量（堆）更小。在6.7和7.0中，現在可以將凍結的索引作為ILM中cold階段的一部分進行凍結。此外，ILM現在可以直接與跨集群復制（CCR）一起使用，CCR在Elasticsearch 6.7和7.0版本中也都采用了GA。 ILM是免費使用的，并且是Elasticsearch的默認發行版的一部分。
Elasticsearch的SQL接口現在是GA。 SQL界面在6.3中作為Alpha發行版引入，熟悉SQL的可以直接使用Elasticsearch來查詢需要的數據，它還允許使用SQL的BI工具輕松訪問Elasticsearch中的數據。 不僅僅是這些，使用JDBC和ODBC驅動程序訪問也可以了，也就是說目前官方支持四種方法可以訪問： Elasticsearch SQL，通過Elasticsearch REST端點、Elasticsearch SQL接口、JDBC、ODBC。
官方為這個功能已經準備了很久很久了：創建用于訪問Elasticsearch集群的下一代Java客戶端。 這里插一下嘴，其實我一直喜歡用rest訪問es，真的簡單方便。
7.0之前，Elasticsearch只能存儲毫秒級的時間戳。 如果要處理發生率較高的情況，例如，如果要在Elasticsearch中存儲和分析跟蹤網絡數據包數據，則可能需要更高的時間精度。 從過去的經驗上來看，我們曾使用Joda時間庫來處理日期和時間，而Joda缺乏對如此高精度時間戳的支持。 在JDK 8中，引入了正式的Java時間API，該API也可以處理納秒級的精確時間戳，并且在過去的一年中，官方一直在努力將Joda時間使用情況遷移到本機Java時間，同時試圖保持向后兼容性。 從7.0.0版本開始，可以通過專用的date_nanos字段映射器使用這些納秒級的時間戳。 請注意，此字段的聚合仍處于毫秒級分辨率，以避免發生存儲桶爆炸（好擔心用這個詞會被和諧掉）。
在搜索方面，查詢性能是一項關鍵功能。對于不需要精確的命中數為結果數設置返回數據的下限就可以了，Elasticsearch 7.0中的搜索性能有了顯著提高。例如，如果用戶通常只查看網站上結果的第一頁，而不在乎匹配的文檔有多少，那么可以向他們顯示“超過10,000個結果”，然后為他們提供分頁結果。 用戶在查詢中輸入頻繁出現的詞（例如“ the”和“ a”）是很常見的，從過去經驗來上看，即使這些頻繁出現的詞條可能并沒有太大意義，但是Elasticsearch也會為它們打分。 在這種情況下，Elasticsearch現在可以跳過這些分值很高卻無太大意義的詞。這樣可以大大提高查詢速度。 得分最高的實際結果的實際數量是可配置的，但默認值為10,000。結果集小于此閾值的查詢的行為不會改變，也就是說結果數是準確的，但是對于少量匹配結果的查詢，性能沒有改善。 由于改進是基于跳過低排名的記錄，因此不適用于聚合操作。
Elasticsearch一直是支持加密通信的，官方最近開始支持JDK 11（關于JDK11的介紹可以看我以前的博客 https://my.oschina.net/110NotFound/blog/3046749 ），它提供了很多新功能。 JDK 11現在支持TLSv1.3，因此從7.0開始，在Elasticsearch中為運行JDK 11的用戶提供TLSv1.3的支持。為了幫助新用戶避免無意中以低安全性運行，所以刪除了TLSv1 .0（默認值）。 對于運行舊版Java的用戶，官方提供了具有TLSv1.2和TLSv1.1的默認選項。
官方說很多用戶最突出的入門障礙是不知道Elasticsearch是Java應用程序（如果用戶群體不是熟悉java的開發人員，這的確會是一個很大的問題，話說回來，開發人員本身不應該局限于某種語言）。 在7.0中，Elasticsearch捆綁了一個OpenJDK發行版，以幫助用戶更快地開始使用Elasticsearch。 同時也支持用戶自己配置JDK。 如果想使用自己機器環境的JDK，仍然可以通過在啟動Elasticsearch之前設置JAVA_HOME來實現。
Elasticsearch 7.0有幾種新的字段類型，可以最大程度地利用數據。 兩個核心的可以有助于搜索的用例方法是 rank_feature 和 rank_features 。 它們可用于增強基于數值或分類值的文檔。
rank_feature 與分數負相關的排序特性應該將positive_score_impact設置為false(默認為true)。rank_feature 查詢將使用它來修改評分公式，使評分隨特性值的增加而減少，而不是增加。例如在網絡搜索中，url長度是一個常用的與分數負相關的特征。
PUT my_index
{
"mappings": {
"properties": {
"pagerank": {
"type": "rank_feature"
},
"url_length": {
"type": "rank_feature",
"positive_score_impact": false
}
}
}
}
PUT my_index/_doc/1
{
"pagerank": 8,
"url_length": 22
}
GET my_index/_search
{
"query": {
"rank_feature": {
"field": "pagerank"
}
}
}rank_features 字段可以在索引數值特征向量，以便以后可以使用rank_feature查詢來增強查詢中的文檔。 它類似于rank_feature數據類型，但更適合特性列表稀疏的情況，因此不太可能為每個映射添加一個字段。
PUT my_index
{
"mappings": {
"properties": {
"topics": {
"type": "rank_features"
}
}
}
}
PUT my_index/_doc/1
{
"topics": {
"politics": 20,
"economics": 50.8
}
}
PUT my_index/_doc/2
{
"topics": {
"politics": 5.2,
"sports": 80.1
}
}
GET my_index/_search
{
"query": {
"rank_feature": {
"field": "topics.politics"
}
}
}除了純文本日志外，官方在Elasticsearch中啟用了JSON日志記錄。 從7.0開始，可以在日志目錄中找到擴展名為.json的新文件。 這意味著現在可以使用 jq 之類的過濾工具以更加結構化的方式漂亮地打印和處理日志。
在7.0中，出現了下一代功能評分功能。 這個新的 script_score 查詢提供了一種新的，更簡單且更靈活的方式來為每條記錄生成排名分數。 script_score 查詢由一組函數構成，其中包括算術和距離函數，用戶可以任意搭配這些函數來構造任意的函數進行得分計算。 模塊化結構更易于使用，所以向用戶開放這個重要的功能。
這個功能是實驗性的，在將來的版本中可能會完全改變或刪除。
關于ElasticSearch7的特性有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
