日前Elastic發布了Elasticsearch 7.10.0。該版本基於Apache Lucene 8.7.0開發，支持在Elasticsearch 在線彈性雲和自建實例使用，有關該版本的功能，請和蟲蟲一起學習。
可搜索的快照可存儲更多內容
大數據流行的幾天，企業數據都每天都以指數級的速率增長。尤其是日誌和監控數據（例如日誌，指標，跟蹤和安全事件）。很多企業都在用Elasticsearch收集和存儲數據，用來做實時告警、在線分析以及機器學習檢測，用來驅動DevOps工作流，監控安全事件。但是大量數據存儲需要大量資源，尤其是靠雲服務企業，每一M都是錢，怎麼能保證數據存儲並保持經濟是一個問題。
為了解決這個問題，Elasticsearch引入了數據的生命周期。使用索引生命周期管理等功能有助於將數據從高性能，高成本的"熱"節點移動到性能較低的磁碟的低成本"熱"節點。將大量數據保留在熱節點上，仍然需要大量的存儲費用。而如果能將其分級，將大量不是需要實時的數據存儲為快照。但是這樣的解決方案存在問題，那就是需要在將快照恢復，需要花費大量恢復時間。
新版本中加入了一個Beta版本的功能可搜索快照，，可讓用戶直接在無需還原的情況下在AWS S3，Microsoft Azure存儲或Google Cloud Storage等低成本對象存儲上搜索快照，而不會顯著影響搜索性能。平衡成本，性能和功能，以滿足存儲和搜索需求。
可搜索快照為稱為冷層（cold tier）的新數據層提供了動力。冷層可以將集群存儲減少50%，而不會顯著影響性能，從而極大的降低只讀數據的存儲成本。它保持與熱層（warm tier）和熱層相同的可靠性和冗餘級別，並完全支持從Elasticsearch獲得的自動恢復。
通過EQL增強Elasticsearch的安全性
在7.9版中，Elasticsearch事件查詢語言（EQL），一種新的實驗性查詢語言。EQL在Endgame中已使用多年，可幫助用戶全面了解威脅調查，識別和預防系統。現在已將安全性領域中使用的這些相同的獨特功能引入了Elasticsearch，並且在7.10中，Elasticsearch中的EQL現在處於Beta版，用於諸如可觀察性和其他時間序列數據之類的用例。
EQL旨在輕鬆地處理一個事件並關聯其他事件或事件序列，以得出系統狀態的結論。可以在一段時間內將這些事件關聯起來，以找到新的結論。
其他功能和可用性增強
搜索時間點(PIT)
在Elasticsearch中查詢索引時，實際上是在給定的時間點搜索數據。如果查詢返回前10%的結果，如何查詢其他90%的結果？在大多數可觀察性和安全性使用案例中，索引不斷變化，因此發送另一個查詢將返回不同的結果，因為索引或數據已更改。時間點讀取器使用戶能夠以給定時間點處的狀態重複查詢索引。時間點閱讀器已經提供了EQL查詢語言希望將來將其用於許多其他用例。
通配符欄位類型大小寫不敏感
在Elasticsearch 7.9中，引入了新的通配符欄位類型。在引入這種新的欄位類型之前，在網絡瀏覽器上進行了人類學習，但是在查詢中使用通配符會佔用大量資源，並且通常導致搜索時間慢於預期。通配符欄位類型提供了額外的靈活性，並且是組合查詢的簡便方法。在7.10中，增加了對不區分大小寫查詢的支持。默認情況下，這只需將可選的case_insensitive標誌設置為true即可對術語級查詢（例如術語，術語，前綴，通配符和正則表達式）啟用不區分大小寫的功能。這將極大地有益於安全性和可觀察性。
GET /my-index-000001/_eql/search
{
"query": """
process where process.executable : "c:\\\\windows\\\\system32\\\\cmd.exe"
"""
}
無符號64位整數
Elasticsearch新版本，支持無符號的64位整數。此新的數字類型支持從0到264-1的非常大的正整數。這對於系統生成的數據（例如來自路由器的計數器或Windows註冊表事件）特別有用。聚合仍然可以在最接近的兩倍上進行。
版本數據類型
如何搜索數值為語義的軟體版本？版本數據類型是關鍵字欄位的一種特殊形式，用於處理軟體版本值並支持基於語義版本控制的軟體優先級規則。例如，主要版本，次要版本和修補程序版本按數字排序（"2.1.0" < "2.4.1" < "2.11.2"），而預發行版本則在發行之前進行排序（"1.0.0-alpha < "1.0.0"）。
新匯總功能
除了在7.8中添加的聚合外，還引入了兩個新的聚合函數：直方圖欄位上的最小/最大聚合，以及直方圖聚合的硬邊界。直方圖數據類型對於處理大量數字數據很有用，該數據經常在生成的地方聚合，從而允許使用更節省空間的Elasticsearch索引。例如，Elastic APM可以匯總直方圖數據或將其匯總為一種結構，以減少從APM代理髮送到Elasticsearch的數據量。能夠在直方圖上進行匯總可以支持新的方案。
第二個聚合是速率指標聚合，它在date_histogram內使用，並計算date_histogram聚合的存儲桶中指定欄位的出現率。以前，計算費率比較困難，由於費率是分析時間序列數據時的基本信息，因此認為簡化費率很有價值。這是我們正在進行的許多此類調整之一，以驗證對時間序列數據使用Elasticsearch通用搜索和分析引擎是否容易且直觀。
新的接收節點管道UI
使用新的接收節點管道UI可以更輕鬆地調試接收流。添加了視覺提示和管道測試，使可以輕鬆地逐步執行流程。查看輸出中的錯誤消息可以幫助確定需要採取哪些措施，以確保的文檔能夠與提取處理器一起正常工作。
REST API對系統索引的訪問已被棄用
Elasticsearch不建議使用REST API訪問系統索引。多數嘗試訪問系統索引的REST API請求都將返回以下棄用警告：
以下REST API端點將訪問系統索引作為其實現的一部分，並且不會返回棄用警告。添加了一個新的元數據標誌來跟蹤索引。升級期間，Elasticsearch會自動將此標誌添加到任何現有系統索引中。
GET _cluster/state
POST _cluster/reroute
GET {index}/_stats
GET {index}/_segments
GET {index}/_shard_stores
GET _cat/[indices,aliases,health,recovery,shards,segments]
系統索引的新線程池
系統索引添加了兩個新的線程池：system_read和 system_write。這些線程池可確保對Elastic Stack至關重要的系統索引（例如安全性或Kibana所使用的系統索引）在集群承受沉重的查詢或索引負載時保持響應能力。
system_read是一個fixed線程池，用於管理針對系統索引的讀取操作的資源。類似地，system_write是一個fixed線程池，用於管理針對系統索引的寫操作的資源。兩者的最大線程數等於5或等於可用處理器的一半，以較小者為準。
機器學習
AUC ROC指標，用於評估分類機器學習模型
新增加了接收器工作特性曲線下的面積（AUC ROC），作為分類分析的評估指標。這是了解模型性能的常用評估指標。
數據框分析中的自定義功能處理器
數據框分析中的新欄位使用戶能夠提供自己的功能轉換和處理器，這些功能和處理器在訓練之前應用，並在推理時自動應用。這使可以在將任何數據行提供給分析之前，對其進行最後一步的特徵轉換。
Elasticsearch 7.10存儲減少
Elasticsearch 7.10依賴於Apache Lucene 8.7，後者引入了對存儲欄位的更高壓縮，這是索引中特別存儲的部分_source。在我們作為基準的各種數據集上，我們注意到空間減少了0%至10%。此更改特別有助於在文檔之間具有大量冗餘數據的數據集，這通常是由我們的可觀察性解決方案生成的文檔的情況，該解決方案重複了有關在每個文檔上生成數據的主機的元數據。
Elasticsearch提供了配置index.codec設置的能力，以告知Elasticsearch如何積極地壓縮存儲的欄位。這兩個值都將支持，default並且best_compression將通過此更改獲得更好的壓縮。
基準測試報告說，使用新的存儲欄位壓縮，最多可減少10%的空間！這是個大新聞，特別是對於為存儲和維護PB級數據付費的組織而言。由Elastic Observability和Elastic Security解決方案創建的索引將獲得最大的節省，因為它們通常保存的數據具有重複性。
Elasticsearch性能改進
Elastic一直致力於不斷提高搜索聚合性能和內存效率。在7.8中，我們通過維護序列化的結果減少了聚合內存的消耗；在7.9中，將search.max_buckets限制增加到65,535。Elasticsearch團隊在7.10中繼續了這項工作，特別針對協調節點和請求級斷路器，以提高性能以及對基數和存儲桶聚合的內存跟蹤。通過預先計算日期範圍，日期直方圖聚合性能也提高了50%。
索引速度提高
Elasticsearch 7.10將索引編制速度提高了20%。我們減少了將條目添加到事務日誌所需的協調。這種減少允許更多的並發性，並將事務日誌緩衝區的大小從增大8KB到1MB。但是，對於全文搜索和其他分析密集型用例而言，性能提升較低。索引鏈越重，收益就越低，因此涉及許多欄位，提取管道或全文本索引的索引鏈將獲得較低的收益。