一、記憶體檔案系統足夠的快取
Elasticsearch嚴重依賴于檔案系統快取,以加快搜索速度,通常,您應確保至少有一半的可用記憶體分配給檔案系統快取,以便Elasticsearch可以將索引的熱區保留在物理記憶體中,
二、使用更快的硬體
如果搜索是受CPU限制的,那就加大CPU,ES對CPU的要求,使用多核CPU優于單核CPU,
如果搜索是在I/O上受限制的話,就需要提供更多的記憶體和更快的硬碟,SSD硬碟性能優于機械硬碟,本地硬碟性能優于遠程虛擬硬碟,
三、檔案建模設計
檔案應該建模設計,是搜索盡可能的快,避免使用 nested(慢幾倍)和父子關系(慢百倍),可以通過對檔案進行非規范化的建模設計來達到相同的目的,解決問題,
四、搜索盡可能少的欄位
query_string或 multi_match查詢目標的欄位越多,它的速度就越慢,
五、預索引資料
您應該利用查詢中的模式來優化資料索引的方式,例如:你有一個型別的檔案所有檔案都包含一個欄位 price,并且你大多數查詢的時候都是使用比較固定的大小范圍查詢或者聚合,此時如果把這個時間分為預索引到檔案中,并且使用terms聚合查詢會更快,
例如,你有一型別的資料如下
PUT index/_doc/1
{
"designation": "spoon",
"price": 13
}
并且你搜索的時候經常使用以下范圍查詢
GET index/_search
{
"aggs": {
"price_ranges": {
"range": {
"field": "price",
"ranges": [
{ "to": 10 },
{ "from": 10, "to": 100 },
{ "from": 100 }
]
}
}
}
}
此時你就應該在檔案索引時添加一個price_range欄位,并且映射成keyword型別的
PUT index
{
"mappings": {
"_doc": {
"properties": {
"price_range": {
"type": "keyword"
}
}
}
}
}
PUT index/_doc/1
{
"designation": "spoon",
"price": 13,
"price_range": "10-100"
}
然后查詢、聚合的時候就使用這個新的欄位來代替price的range聚合
GET index/_search
{
"aggs": {
"price_ranges": {
"terms": {
"field": "price_range"
}
}
}
}
六、將識別符號映射為keyword型別
有些欄位雖然是數字型別的,但是實際上并不是都要映射為數字型別,ES能夠通過數字型別優化range查詢,但是terms查詢使用keyword更適合,一般的像ISBN(國際標準書號)這樣的識別符號(ID)都是適合映射為keyword而不是數字的,
七、避免使用腳本
通常,應避免使用腳本,如果絕對需要它們,則應首選painless和expressions引擎,
八、搜索舍入日期
對日期欄位的查詢now通常是不可快取的,因為匹配一直是在變化的,但是,就用戶體驗而言,切換到舍入日期通常是可以接受的,并且具有更好地利用查詢快取的好處,
例如下面的查詢
PUT index/_doc/1
{
"my_date": "2016-05-11T16:30:55.328Z"
}
GET index/_search
{
"query": {
"constant_score": {
"filter": {
"range": {
"my_date": {
"gte": "now-1h",
"lte": "now"
}
}
}
}
}
}
可以使用下面的查詢代替
GET index/_search
{
"query": {
"constant_score": {
"filter": {
"range": {
"my_date": {
"gte": "now-1h/m",
"lte": "now/m"
}
}
}
}
}
}
在這種情況下,我們四舍五入為分鐘,因此,如果當前時間為16:31:29,則范圍查詢將匹配my_date欄位值介于15:31:00和16:31:59之間的所有內容,而且,如果多個用戶在同一分鐘內運行包含此范圍的查詢,則查詢快取可以幫助加快速度,用于舍入的時間間隔越長,查詢快取可以提供的幫助越多,但是請注意,過于激進的舍入也會損害用戶體驗,
九、強制合并只讀索引
只讀的索引將從合并到單個段中受益 ,對于基于時間的索引,通常是這種情況:只有當前時間范圍的索引才能獲取新檔案,而較舊的索引則為只讀,
提示
不要合并正在寫入的索引,
十、預熱全域序數詞
全域序數詞是一種資料結構,用于在keyword欄位上運行terms聚合 ,它們被延遲加載到記憶體中,因為Elasticsearch不知道terms聚合中將使用哪些欄位,而哪些欄位則不會,您可以通過如下所述配置映射,讓Elasticsearch在重繪時緊急加載全域序數詞:
PUT index
{
"mappings": {
"_doc": {
"properties": {
"foo": {
"type": "keyword",
"eager_global_ordinals": true
}
}
}
}
}
十一、預熱檔案快取系統
如果重新啟動運行Elasticsearch的計算機,則檔案系統快取將為空,因此,作業系統需要一些時間才能將索引的熱區加載到記憶體中,以便快速進行搜索操作,您可以使用該index.store.preload設定明確告訴作業系統哪些檔案應該急切地加載到記憶體中,具體取決于檔案擴展名 ,
十二、使用索引排序來加快連接的
索引排序可能有用,以便使連接更快,但以稍微慢一些的索引為代價,在索引排序檔案中閱讀有關它的更多資訊,
十三、使用preference以優化快取利用率
有多個可以幫助提高搜索性能的快取,例如 檔案系統快取, 請求快取或查詢快取,但是所有這些快取都在節點級別維護,這意味著如果您連續兩次運行相同的請求,具有一個或多個副本,并使用默認路由演算法round-robin,則這兩個請求將轉到不同的分片副本,從而阻止了節點級快取的幫助,
由于搜索應用程式的用戶通常會依次運行類似的請求(例如為了分析索引的較窄子集),因此使用標識當前用戶或會話的首選項值可以幫助優化快取的使用,
十四、副本可能有助于提高吞吐量,但并非總是可以
除了提高彈性之外,副本還可以幫助提高吞吐量,例如,如果您有一個單碎片索引和三個節點,則需要將副本數設定為2,以便總共擁有3個碎片副本,以便利用所有節點,
現在,假設您有一個2碎片索引和兩個節點,在一種情況下,副本數為0,這意味著每個節點都擁有一個分片,在第二種情況下,副本數為1,這意味著每個節點都有兩個分片,哪種設定在搜索效果方面效果最好?通常,每個節點的分片總數較少的設定會更好地執行,這樣做的原因是,它為每個分片提供了更多的可用檔案系統快取份額,并且檔案系統快取可能是Elasticsearch的第一性能因素,同時,請注意,在單節點故障的情況下,沒有副本的安裝會失敗,因此在吞吐量和可用性之間要進行權衡,
那么正確的副本數是多少?如果您的集群中有num_nodes節點,則總共有 num_primaries主要分片,并且如果您希望max_failures一次最多能處理節點故障,那么適合您的副本數是 max(max_failures, ceil(num_nodes / num_primaries) - 1),
十五、打開自適應副本選擇
當存在多個資料副本時,elasticsearch可以使用一組稱為自適應副本選擇的條件來根據回應時間,服務時間和包含每個碎片副本的節點的佇列大小來選擇最佳資料副本,這可以提高查詢吞吐量并減少大量搜索應用程式的延遲,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/227789.html
標籤:其他
