掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
Elasticsearch 是一個基于 Lucene 庫的搜索引擎。它提供了一個分布式、支持多租戶的全文搜索引擎,具有 HTTP Web 接口和無模式 JSON 文檔。Elasticsearch 是用 Java 開發(fā)的,并在 SSPL+Elastic License 許可證下作為開源軟件發(fā)布。官方客戶端在 Java、.NET(C#)、PHP、Python、Apache Groovy、Ruby 和許多其他語言中都是可用的。

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),定陶企業(yè)網(wǎng)站建設(shè),定陶品牌網(wǎng)站建設(shè),網(wǎng)站定制,定陶網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,定陶網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿,時刻以成就客戶成長自我,堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
時隔近三年,Elasticsearch 8 正式發(fā)布,新增的功能包括:
8.0 為 Elasticsearch REST APIs 引入了一些重大的變化。雖然更新你的應(yīng)用程序以適應(yīng)這些變化十分重要,但在升級后尋找和更新每一個 API 調(diào)用可能對開發(fā)者而言十分痛苦且容易出錯。為了使這個過程變得更加容易,Elasticsearch 已經(jīng)在 REST API 中增加了對 7.x 兼容性 header 的支持。這些可選的 header 文件讓你向 8.0 集群發(fā)出 7.x 兼容的請求,并收到 7.x 兼容的響應(yīng)。
雖然官方仍然建議開發(fā)者更新你的應(yīng)用程序以使用原生的 8.0 請求和響應(yīng),但 7.x API 兼容 header 文件讓你可以在更長的時間內(nèi)安全地進行這些更改。
在沒有安全保障的情況下運行 Elasticsearch 會讓你的集群暴露在任何可以向 Elasticsearch 發(fā)送請求的用戶面前。在以前的版本中,你必須明確地啟用 Elasticsearch 的安全功能,如認證、授權(quán)和網(wǎng)絡(luò)加密(TLS)。從 Elasticsearch 8.0 開始,當?shù)谝淮螁?Elasticsearch 時,安全功能被默認啟用和配置。
在啟動時,Elasticsearch 8.0 會生成注冊令牌,你可以用它來連接 Kibana 實例或在安全的 Elasticsearch 集群中注冊其他節(jié)點,而無需生成安全證書或更新 YAML 配置文件。只需在啟動新節(jié)點或 Kibana 實例時使用生成的注冊令牌,Elastic Stack 就會為你處理所有安全配置。
已知問題:
bin/elasticsearch-reset-password -u elastic
bin/elasticsearch-create-enrollment-token -s kibana
系統(tǒng)索引為 Elastic 功能存儲配置和內(nèi)部數(shù)據(jù)。一般來說,系統(tǒng)索引僅保留供這些功能內(nèi)部使用。雖然有可能,但直接訪問或改變系統(tǒng)索引會導(dǎo)致不穩(wěn)定和其他問題。
在 Elasticsearch 8.0 中做了一些改變來保護系統(tǒng)索引不被直接訪問。要訪問系統(tǒng)索引的話,用戶現(xiàn)在必須把 allow_restricted_indices 權(quán)限設(shè)置為 true。
superuser 角色也不再給予系統(tǒng)索引的寫入權(quán)限。因此,內(nèi)置的 elastic superuser 默認不能改變系統(tǒng)索引。
此后,開發(fā)者應(yīng)使用 Kibana 或相關(guān)的 Elasticsearch APIs 來管理某個功能的數(shù)據(jù),而不是訪問系統(tǒng)索引。如果你直接訪問系統(tǒng)索引,Elasticsearch 將在 API 響應(yīng)的 header 中和廢棄日志中返回警告。
在 Elasticsearch 8.0 中推出了 KNN 搜索 API 的技術(shù)預(yù)覽版。通過使用 dense_vector 字段,k-nearest neighbor(KNN)搜索可以找到與查詢向量最近的 k 個向量(這是由相似度指標來衡量的)。KNN 通常被用來支持推薦引擎和基于自然語言處理(NLP)算法的相關(guān)性排名。
以前,Elasticsearch 只支持精確的 KNN 搜索,使用帶向量函數(shù)的 script_score 查詢。雖然這種方法保證了準確的結(jié)果,但它往往導(dǎo)致搜索速度緩慢,而且在大型數(shù)據(jù)集上不能很好地擴展。作為對較慢的索引和不完美的準確性的交換,新的 KNN 搜索 API 讓你在更大的數(shù)據(jù)集上以更快的速度運行近似的 KNN 搜索。
該版本更新了倒排索引,這是一個內(nèi)部數(shù)據(jù)結(jié)構(gòu),可以使用更節(jié)省空間的編碼。這一變化將使 keyword、 match_only_text 字段以及 text 字段受益。在使用應(yīng)用程序日志的基準測試中,這一轉(zhuǎn)變?yōu)?message 字段(映射為 match_only_text)的索引大小減少了 14.4%,總體上減少了 3.5% 的磁盤占用空間。
新版本優(yōu)化了多維點(multi-dimensional points)的索引速度,多維點是用于 geo_point、geo_shape 和范圍字段的內(nèi)部數(shù)據(jù)結(jié)構(gòu)。Lucene 級別的基準測試顯示,這些字段類型的索引速度提高了 10-15%。主要由這些字段組成的 Elasticsearch 索引和數(shù)據(jù)流可能會在索引速度方面有顯著的改進。
現(xiàn)在可以上傳在 Elasticsearch 之外訓(xùn)練的 PyTorch 模型,并使用它們進行推理。第三方模型支持為 Elastic Stack 帶來了現(xiàn)代自然語言處理(NLP)和搜索用例。
Aggregations:
Allocation:
Analysis:
Authentication:
Cluster Coordination:
Distributed:
Engine:
Features/CAT APIs:
Features/ILM+SLM:
Features/Indices APIs
Infra/Core
Packaging
……
更多詳情可查看:??https://www.elastic.co/cn/blog/whats-new-elastic-8-0-0??

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流