作者介紹
魏彬,普翔科技 CTO,開源軟件愛好者,中國第一位 Elastic 認證工程師,《Elastic日報》和 《ElasticTalk》社區項目發起人,被 elastic 中國公司授予 2019 年度合作伙伴架構師特別貢獻獎。對 Elasticsearch、Kibana、Beats、Logstash、Grafana 等開源軟件有豐富的實踐經驗,為零售、金融、保險、證券、科技等眾多行業的客戶提供過諮詢和培訓服務,幫助客戶在實際業務中找準開源軟件的定位,實現從 0 到 1 的落地、從 1 到 N 的拓展,產生實際的業務價值。
為什麼要壓測
關於壓測,我們先來看下百度百科上的一個定義。
壓測,即壓力測試,是確立系統穩定性的一種測試方法,通常在系統正常運作範圍之外進行,以考察其功能極限和隱患。
從定義不難看出壓測的目的,是要測出一個系統的極限,提早發現隱患,早作打算。那麼對於 es 來講,我認為壓測一般有以下幾個目的:
1、驗證 es 的性能,儘管網上把 es 的性能誇上天了,還是自己跑一下才放心。
2、針對 es 的某些配置做試驗性測試,比如關閉索引的 _all 特性,是否能提高寫性能,具體能提高多少。
3、對比 es 新版本和舊版本的性能差異。眾所周知,es 的版本升級非常快,用著 2.x 的同學們 還沒來得及升級 7.x ,眼看 8.x 都要發佈了。此時,你到底要不要升級呢?答案雖然是肯定的,但是你怎麼說服你的 leader 呢?很簡單:壓測新版本,和舊版本做對比,用表格、圖表指明新版本在寫性能、讀性能方面的改善等等,搞定。
4、對 es 集群做容量規劃。俗話說“人無遠慮,必有近憂”,容量規劃就是“遠慮”。簡單講就是你線上的 es 集群一共需要多少節點?每個節點的配置如何?這個集群的寫性能極限是多少?讀性能呢?如果你回答不了這些問題,那就說明你沒有做過容量規劃,只是兩眼一抹黑,說幹就幹,上了再說,好在有驚無險,沒有碰到性能問題。至於什麼時候會遇到問題,你也說不準,感覺是個概率和人品問題……對面的老闆已經黑臉了…… 對於這個問題我們在最後再來詳細討論。
如何壓測
現在我們知道壓測的目的了,接下來該如何進行壓測呢?一般有以下幾個方案:
1、自己寫代碼。無需多言,想怎麼寫怎麼寫,難點在於如果確保測試代碼的專業性。這裡有一些開源項目,留給大家自己探索:esperf 和 elasticsearch-stress-test
2、http壓測工具。es 對外暴露了 Restful API,因此所有的針對 http 協議的壓測工具都可以用來測試 es,比如 JMeter、httpload等等。
3、elastic 官方工具 esrally。
各個壓測方案各有優劣,大家可以根據自己的需求和工具熟悉度來選擇自己的壓測工具。接下來我們就來具體瞭解下 esrally。
入門簡介
esrally 是 elastic 官方開源的一款基於 python3 實現的針對 es 的壓測工具,源碼地址為https://github.com/elastic/rally,
相關博客介紹在這裡。esrally主要功能如下:
1、自動創建、壓測和銷燬 es 集群
2、可分 es 版本管理壓測數據和方案
3、完善的壓測數據展示,支持不同壓測之間的數據對比分析,也可以將數據存儲到指定的es中進行二次分析
4、支持收集 JVM 詳細信息,比如內存、GC等數據來定位性能問題
elastic 官方也是基於 esrally 進行 es 的性能測試,並將結果實時發佈到 https://elasticsearch-benchmarks.elastic.co/ ,大家可以從該網站上直接查看 es 的性能。官方使用兩臺服務器進行壓測,一臺運行 esrally ,一臺運行 es,服務器的配置如下:
CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
RAM: 32 GBSSD: Crucial MX200
OS: Linux Kernel version 4.8.0-53
JVM: Oracle JDK 1.8.0_131-b11
網站頂部的 Geonames、Geopoint、Percolator等都是針對不同的數據集做的壓測,比如下面這些圖展示了 logging 日誌類數據的壓測結果。
寫性能
讀性能
其他系統指標
快速入門
esrally 的文檔在這裡,這裡簡單說下安裝與運行。
esrally 對於軟件環境的要求如下:
• Python 3.4+ 和 pip3
• JDK 8
• git 1.9+
安裝方法為:
pip3 install esrally
Tips:
可以使用國內的pip源,比如豆瓣或者阿里的,這樣安裝會快很多。
安裝完畢後執行如下的配置命令,確認一些數據存放的路徑即可。
esrally configure
接下來就可以開跑了,比如下面這條命令是針對 es 5.0.0 版本進行壓力測試。
esrally --distribution-version=5.0.0
運行結束後,會得到如下的結果。
壓測結果
對於第一次見到壓測結果的同學來說可能有些暈,這麼多數據,該怎麼看?!別急,一步步來!
Tips:
由於 esrally 的測試數據存儲在國外 aws 上,導致下載很慢甚至會超時失敗,從而導致整個壓測無法進行。後面我會把這些測試數據的壓縮包放到國內,大家可以下載後直接放到 esrally 的數據文件夾下面,保證壓測的正常進行。另外由於數據量過大,壓測的時間一般會很久,可能在1個小時左右,所以大家要有耐心哦~
如果你只是想體驗下,可以加上 --test-mode 的參數,此時只會下載1000條文檔進行測試。
相關術語
rally 是汽車拉力賽的意思,也就是說 esrally 是將壓測比作了汽車拉力賽,因此其中的很多術語都是從汽車拉力賽中借鑑來的。
track
track 是賽道的意思,在這裡是指壓測用的數據和測試策略,詳細文檔在這裡。esrally 自帶的track都在 github 上,地址在這裡 https://github.com/elastic/rally-tracks。
在該 repository 中,有很多測試數據,比如 geonames geopoint logging nested 等,每個數據文件夾中的 README.md 中有詳細的數據介紹,而 track.json 便是壓測策略的定義文件。
我們來看下 loggins/track.json 文件
{% import "rally.helpers" as rally with context %}
{
"short-description": "Logging benchmark",
"description": "This benchmark indexes HTTP server log data from the 1998 world cup.",
"data-url": "http://benchmarks.elasticsearch.org.s3.amazonaws.com/corpora/logging",
"indices": [
{
"name": "logs-181998",
"types": [
{
"name": "type",
"mapping": "mappings.json",
"documents": "documents-181998.json.bz2",
"document-count": 2708746,
"compressed-bytes": 13815456,
"uncompressed-bytes": 363512754
}
]
},
{
"name": "logs-191998",
"types": [
{
"name": "type",
"mapping": "mappings.json",
"documents": "documents-191998.json.bz2",
"document-count": 9697882,
"compressed-bytes": 49439633,
"uncompressed-bytes": 1301732149
}
]
}
],
"operations": [
{{ rally.collect(parts="operations/*.json") }}
],
"challenges": [
{{ rally.collect(parts="challenges/*.json") }}
]
}
該 json 文件主要包含下面幾個部分:
• description 和 short-description: track 的描述文字
• data-url: 一個url地址,指明測試數據的下載根路徑,與下方 indices 中的 documents 結合,可得到數據的下載地址。
• indices: 指定該 track 可以操作的索引,包括創建、更新、刪除等操作。詳細信息可以參見這裡。
• operations: 指定具體的操作,比如 index 索引數據的操作、force-merge 強制合併segment的操作、search 搜索的操作等等。具體例子可以看下面的示例。詳細信息可以參見這裡。
• challenges: 通過組合 operations 定義一系列 task ,再組合成一個壓測的流程,請參照下方的 例子。詳細信息可以參見這裡
operations/default.json 中的一個定義如下:
{
"name": "index-append",
"operation-type": "index",
"bulk-size": 5000
}
其中 operation-type 包含 index、force-merge、index-stats、node-stats、search等,每一個operation-type都有自己的可定義參數,比如 index 中可以通過指定 bulk-size 來決定批量寫入的文檔數。
challenges/default.json 中的一個定義如下:
{
"name": "append-no-conflicts",
"description": "",
"default": true,
"index-settings": {
"index.number_of_replicas": 0
},
"schedule": [
{
"operation": "index-append",
"warmup-time-period": 240,
"clients": 8
},
{
"operation": "force-merge",
"clients": 1
},
{
"operation": "index-stats",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 50
},
{
"operation": "node-stats",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 50
},
{
"operation": "default",
"clients": 1,
"warmup-iterations": 100,
"iterations": 500,
"target-throughput": 10
},
{
"operation": "term",
"clients": 1,
"warmup-iterations": 100,
"iterations": 500,
"target-throughput": 60
},
{
"operation": "range",
"clients": 1,
"warmup-iterations": 100,
"iterations": 200,
"target-throughput": 2
},
{
"operation": "hourly_agg",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 0.2
},
{
"operation": "scroll",
"clients": 1,
"warmup-iterations": 100,
"iterations": 200,
"target-throughput": 10
}
]
}
這裡定義了一個名為 append-no-conflicts 的 challenge。由於每次壓測只能運行一個challenge,這裡的 default 參數是指當壓測未指定時默認運行的 challenge。schedule 中指定了該 challenge 中按順序執行 index-append、force-merge、index-stats、node-stats、default、term、range、hourly_agg、scroll 等 9 個task,其中每個 task 都指定了 一個 operation,除此之外還可以設定 clients (併發客戶端數)、warmup-iterations(預熱的循環次數)、iterations(operation 執行的循環次數)等,詳情請參見此處。
通過下面的命令可以查看當前 esrally 可用使用的track。
esrally list tracks
esrally 的 track 數據位於 rally 目錄(mac默認是 ~/.rally
)中 benchmarks/tracks/
下面。
car
car 是賽車的意思,這裡是指不同配置的 es 實例。通過下面的命令可以查看 esrally 當前可用的 car。 esrally list cars
Name
----------
16gheap
1gheap
2gheap
4gheap
8gheap
defaults
ea
verbose_iw
cars 的配置位於 rally 目錄(mac默認是 ~/.rally
)中 benchmarks/teams/default/cars/
下面。具體配置可以參見 cars 的文檔,除了 heap 的配置,所有的 es 配置都可以修改。
race
race 是一次比賽的意思,這裡是指某一次壓測。要比賽,就要有賽道和賽車,如果不指定賽車,就用 default 配置,如果不指定賽道,則默認使用 geonames track。通過下面的命令來執行一次 race。
esrally race --track=logging --challenge=append-no-conflicts --car="4gheap"
上面的命令便是執行一次壓測,並指定使用 logging 的track,運行該 track 中的 append-no-conflicts 的 challenge,指定的 car 為 4gheap 的 es 實例。詳情可以查看 race 相關文檔。
Tournament
tournament 是錦標賽的意思,是由多個 race 組成的。通過下面的命令可以查看所有的 race。
esrally list races
Recent races:
Race Timestamp Track Challenge Car User Tag
---------------- ------- ------------------- -------- ------------------------------
20160518T122341Z pmc append-no-conflicts defaults intention:reduce_alloc_1234
20160518T112057Z pmc append-no-conflicts defaults intention:baseline_github_1234
20160518T101957Z pmc append-no-conflicts defaults
當有了多個 race 後,可以通過下面的命令方便地比較不同 race 之間的數據。
esrally compare --baseline=20160518T112057Z --contender=20160518T112341Z
兩次 race 的數據比較
詳細信息可以參見 tournament 的文檔。
Pipeline
Pipeline 在這裡是指壓測的一個流程,通過下面的命令可以查看已有的pipeline。
esrally list pipeline
Name Description
----------------------- ---------------------------------------------------------------------------------------------
from-sources-complete Builds and provisions Elasticsearch, runs a benchmark and reports results.
from-sources-skip-build Provisions Elasticsearch (skips the build), runs a benchmark and reports results.
from-distribution Downloads an Elasticsearch distribution, provisions it, runs a benchmark and reports results.
benchmark-only Assumes an already running Elasticsearch instance, runs a benchmark and reports results
1、from-sources-complete 是從源代碼編譯 es 後再運行,可以通過 --revision 參數指明要編譯的commit hash ,這樣就可以針對某一個提交版本就行測試了。
2、from-sources-skip-build 如果已經編譯好了,使用該 pipeline,可以跳過編譯的流程,節省測試時間
3、from-distribution 通過 --distribution-version 指定 es 版本,esrally 會從官網直接下載該版本的可執行文件,然後進行測試。
4、benchmark-only 此 pipeline 將 es 集群的管理交由用戶來處理, esrally 只做壓測。如果你想針對已有集群進行測試,那麼要將pipeline設定為該模式。
詳細信息請參見 pipeline 的文檔。
壓測流程
esrally 的壓測流程主要分為以下三個步驟:
1、 根據參數設定自行編譯或者下載 es 可執行實例,然後根據 car 的約定,創建並啟動 es 集群。如果使用 benchmark-only 的pipeline,則該步驟省略。
2.、根據指定 track 去下載數據,然後按照指定的 challenge 進行操作。
3.、記錄並輸出壓測結果數據。
壓測結果分析
壓測結束後,esrally 會將結果輸出到終端和結果文件(位於 esrally 目錄logs 和 benchmarks/races)中,如下圖所示:
壓測結果
在 Metric 一欄,有非常多的指標數據,詳細的解釋可以參見該文檔。一般要關注的數據有:
1、throughput 每個操作的吞吐量,比如 index、search等
2、latency 每個操作的響應時長數據
3、Heap used for x 記錄堆棧的使用情況
先搞懂每個 metric 的含義,然後根據自己的需求去確認自己要關注的指標。
每一次壓測都會以壓測時的時間命名,比如 logs/rally_out_20170822T082858Z.log ,這個日誌便是記錄的 2017年8月22日 8:28:58開始的壓測日誌。而在 benchmarks/races/2017-08-22-08-28-58 中記錄著最終的結果和 es 的運行日誌。
另外對於 benchmark-only 模式的測試,即針對已有集群的壓力測試,也可以通過安裝 X-Pack Basic 版本進行監控(Monitoring),在壓測的過程中就能查看相關指標。
X-Pack Monitoring
esrally 可以在配置的時候指定將所有的 race 壓測結果數據存入一個指定的 es 實例中,配置如下(在 esrally 目錄中 rally.ini 文件中):
[reporting]
datastore.type = elasticsearch
datastore.host = localhost
datastore.port = 9200
datastore.secure = False
datastore.user =
datastore.password =
esrally 會將數據存儲在如下 3 個index中,下面 * 代指月份,即按月存儲結果數據。
1、rally-metrics-* 該索引分指標記錄每次 race 的結果,如下圖所示為某一次race的所有 metric 數據。
Metric 數據
第一列時間是指某一次壓測的時間,第二列時間是指標採集的時間,第三列 operation 指具體執行的操作,operation 為空的指標都是總計類的,比如indexing total time 記錄的是總索引數據的時間、segments_count 是總段數等等。其他的 operation 都記錄了每一個操作的數據。需要注意的是,這裡記錄的是 operation 的所有采樣數據,不是一個最終的彙總數據。上面截圖中也可以看出同一個 hour_agg 的operation 有多項名為 service_time 的指標數據,但他們的採集時間是不同的。基於這些數據,我們可以做出某一次 race 中某個指標的可視化圖表,比如你想觀察本次 race 中 index-log 這個 task 的 throughput 指標數據,便可以通過如下圖的方式實現。
metric 數據展示
2、rally-result-* 該索引分指標記錄了每次 race 的最終彙總結果,比如下面這條數據。
{
"user-tag": "shardSizeTest:size6",
"distribution-major-version": 5,
"environment": "local",
"car": "external",
"plugins": [
"x-pack"
],
"track": "logging",
"active": true,
"distribution-version": "5.5.2",
"node-count": 1,
"value": {
"50_0": 19.147876358032228,
"90_0": 21.03116340637207,
"99_0": 41.644479789733886,
"100_0": 47.20634460449219
},
"operation": "term",
"challenge": "default-index",
"trial-timestamp": "20170831T063724Z",
"name": "latency"
}
這個記錄了 term operation 的 latency 指標數據,彙總值以 percentile(百分位數) 的形式展示。基於該數據,我們可以繪製針對某個指標的多race對比,比如下圖便是對比多 race 之間 hourly_agg(按小時做聚合)、default(match_all 查詢)、term(term查詢)、range(range查詢)的latency(延遲時間)對比。
多次 race 的 latency 對比
3、rally-races-* 該索引記錄了所有 race 的最終結果,即命令行執行的輸出結果。
除了es相關指標數據外,esrally 還會同時記錄測試的一些環境信息,比如操作系統、JVM等等,你可以方便的查看本次測試的軟硬件環境。
實戰
終於到了開賽的時候,下面我們採用問答的形式來進行,希望大家看到問題後先自己思考下再看答案。
問題一
提問
如何對比 5.5.0 相比 2.4.6 的性能改進?
回答:
分別針對 5.5.0 和 2.4.6 做一次壓測,然後比較兩者兩者的相關指標即可,這裡我們的 track 和 challenge 如下:
• track: nyc_taxis
• challenge: append-no-conflicts
測試步驟如下:
1. 測試 2.4.6 的性能esrally race --distribution-version=2.4.6 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="version:2.4.6"
2. 測試 5.5.0 的性能esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="version:5.5.0"
3. 對比兩次 race 的結果
``esrally list races
esrally compare --baseline=[2.4.6 race] --contender=[5.5.0 race]``
Tips:
--user-tag 用於為 race 打標籤,方便後續查找
如果只是試一下,可以加上 --test-mode ,用測試數據來跑,很快。
v
問題二
提問:
如何測試 _all 關閉後對於寫性能的影響?
回答:
針對 5.5.0 版本的 es 做兩次測試,第一次開啟 _all,第二次關閉 _all,對比兩次的結果,由於只測試寫性能,所以我們只需要 index 類型的 operation執行。這裡我們的 track 和 challenge 如下:
• track: nyc_taxis
• challenge: append-no-conflicts
測試步驟如下:
1、默認 nyc_taxis 的 mapping 設置是將 _all 關閉的,直接測試 _all 關閉時的性能。esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="enableAll:false" --include-tasks="type:index"
2、修改 nyc_taxis 的 mapping 設置,打開 _all。mapping 文件位於 rally 主目錄
``benchmarks/tracks/default/nyc_taxis/mappings.json,修改 _all.enabled 為 true。
esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="enableAll:true" --include-tasks="type:index"``
3、對比兩次 race 的結果
``esrally list races
esrally compare --baseline=[enableAll race] --contender=[disableAll race]``
下圖是我在 --test-mode 模式下運行的對比結果,也可以看出關閉 _all 可以提升寫性能。
測試結果
Tips:
--include-tasks 用於只運行 challenge 中的部分 task
問題三
提問:
如何測試已有集群的性能?
回答:
使用 benchmark-only 的 pipeline 即可,這裡我們的 track 和 challenge 如下:
• track: nyc_taxis
• challenge: append-no-conflicts
測試步驟如下:
1. 執行下方命令即可測試已有集群esrally race --pipeline=benchmark-only --target-hosts=127.0.0.1:9200 --cluster-health=yellow --track=nyc_taxis --challenge=append-no-conflicts
Tips:
--cluster-health=yellow 默認 esrally 會檢查集群狀態,非 green 狀態會直接退出。添加該參數可以避免該情況
希望這三個問答可以幫助到大家快速掌握 esrally 的用法。
進階
自定義 car
前面講解 car 的時候,我們提到 esrally 已經自帶了一些可用的 es 配置,但是如果這些還不能滿足你的時候,可以通過下面兩個方案解決。
1. 定製自己的car
car 的配置文件位於 esrally 目錄 benchmarks/teams/default/cars,在這裡新增一個自己的 car 配置文件就可以了。這裡就不贅述了,感興趣的可以查閱 car 的文檔。
2. 自己搭建集群
最簡單的方式是脫離 esrally 的管理,自行搭建集群,這樣想怎麼配置就怎麼配置了。
自定義 track
雖然 esrally 自帶了很多 track,而且這些數據本身也不小,簡單列在下面:
這些數據文件位於 esrally 目錄benchmarks/data
下面。不同的 Track 有不同的測試目的,詳情可以去該 github repo 下面去查看。
當我們做定向測試的時候,還是希望針對自己的數據進行壓測,此時可以自定義 track。操作也很簡單,詳情可以參考官方文檔。這裡簡單列一下操作步驟。
1、 在 上文提到的 data 目錄中創建自己的數據目錄。
2.、準備壓測數據文件。 esrally 使用的是一個json文件,其實是一個一個 json object。
3.、將準備好的數據文件壓縮成 bz2 格式,然後複製到步驟 1 創建的目錄中去。
4.、新增自定義的track。可以直接複製 geoname 目錄,然後修改相關的配置文件,將測試數據與 track 綁定。
5.、添加完後,通過esrally list rack
就可以看到自定義的 track。
分佈式壓測
esrally 還支持分佈式壓測,即如果一個節點的 esrally 無法達到要求的併發數、請求數,那麼可以將 esrally 分佈到多臺機器上去同時執行。分佈式壓測文檔在這裡,此處用到了 esrally dameon,對應命令是 esrallyd
。簡單講就是 esrally 通過 esrallyd 將多臺機器組合成一個集群,然後 esrally 在執行測試任務的時候通過制定 --load-driver-hosts
便可以將測試任務分發到對應的機器上執行。這裡便不贅述了,感興趣的去看前面提到的文檔。
問題四
提問:
一個 index 的 shard 數該如何確認?
回答:
其實針對這個提問,還可以再問下面兩個問題。
1、 shard 設置過少是否有問題?比如一直都採用默認的 5個分片
2、shard 設置過多是否有問題?比如直接設置為100個分片
要回到這兩個問題,我們得先知道 shard 的作用。shard 是 es 實現分佈式特性的基石,文檔在索引進 es 時,es 會根據一個路由算法,將每一個文檔分配到對應的 shard 上。每個 shard 實際對應一個 lucene index。那麼每個 shard 能存儲的文檔數是否有上限呢?答案是有!每個shard最多存儲 2^31 個文檔,即 20億。這是 lucene 設計決定的。那是不是隻要我的文檔數沒有超過20億,就可以只用一個或者很少的shard 呢?不盡然。因為隨著 shard 體積的增大,其查詢效率會下降,而且數據遷移和恢復的成本也會增高。官方建議單個 shard 大小不要超過 50GB,可以參見討論一和討論二。
現在回答上面的兩個問題。
shard數過小不一定好,如果數據量很大,導致每個 shard 體積過大,會影響查詢性能。
shard數過大也不一定好,因為 es 的每次查詢是要分發給所有的 shard 來查詢,然後再對結果做聚合處理,如果 shard 數過多也會影響查詢性能。因此 shard 的數量需要根據自己的情況測出來。
官方文檔有一節關於容量規劃的章節,建議大家去看一下,鏈接在這裡,其給出的步驟如下:
1、 使用生產環境的硬件配置創建單節點集群
2、 創建一個只有一個主分片無副本的索引,設置相關的mapping信息
3、 將真實的文檔導入到步驟 2 的索引中
4、測試實際會用到的查詢語句
測試的過程中,關注相關指標數據,比如索引性能、查詢性能,如果在某一個點相關性能數據超出了你的預期值,那麼此時的 shard size大小便是符合你預期的單個 shard size的大小。接下來通過下面這個簡單的計算公式便大致能確定一個 index 需要設定的 shard 數了。
shard數 = index 的數據總大小/單個shard size的極限值
比如你測出單個 shard size 最大為 20 GB,而你預測該索引數據最大量在1年或者2年內不會超過 200GB,那麼你的 shard 數就可以設置為10。
接下來要做的事情也很明確,我們要用 esrally 完成上面的壓測步驟:
1、自行維護 es 節點的創建和運行,esrally 運行的時候採用 benchmark-only 模式.
2、自定義 track,這裡有以下兩個重點:
• 生成真實數據。如果你的數據無法生成很多,那麼可以在 track 的 schedule 中設置 iterations 參數,即循環進行同一個操作,這樣也可以測試大數據量的寫性能。
• 定義自己的查詢任務。在 track 的 operations 中是可以定義自己的查詢語句的,比如下面這個
{
"name": "hourly_agg",
"operation-type": "search",
"index": "logs-*",
"type": "type",
"body": {
"size": 0,
"aggs": {
"by_hour": {
"date_histogram": {
"field": "@timestamp",
"interval": "hour"
}
}
}
}
}
其中的 body 便是自定義的查詢語句,所以你可以通過自己的需求來設定查詢語句,以貼近實際使用的情況。
3、還要記得設置索引的 mapping 與線上一致,比如是否啟用 _all 等設置。
4、基於自定義的track來進行壓測即可。要注意的是運行 esrally 的機器要和 es 機器分開,防止對 es 性能產生干擾。
Tips:
esrally 默認在每次壓測是會刪除已有的索引後再重新創建索引,如果你不想這樣,可以在每個 index 的配置中設置 auto-managed 為 false,具體文檔在這裡。
通過這個參數,你就可以單獨壓測查詢性能了,而不用每次都要先經過漫長的導入數據的過程。
總結
esrally 針對 es 的壓測設計了一套完備的基於配置文件的測試流程,極大地簡化了操作難度,並且提供了可重複驗證的方式。對國內用戶來講,我認為最大的難處還是在於 esrally 自帶的 track 文件太大,從 國外 aws 下載很慢。好在可以自定義 track,不必完全依賴自帶的 track。
其他沒啥好說的,esrally 棒棒噠,大家趕緊去試試吧,如果有問題歡迎來討論!
聲明:本文由原文《Elasticsearch 壓測方案之 esrally 簡介》作者“魏彬”授權轉載,對未經許可擅自使用者,保留追究其法律責任的權利。
參考資料
4. Benchmarking Elasticsearch for your use case with Rally
【阿里雲Elastic Stack】100%兼容開源ES,獨有9大能力,提供免費X-pack服務(單節點價值$6000)
相關活動
更多折扣活動,請訪問阿里雲 Elasticsearch 官網
阿里雲 Elasticsearch 商業通用版,1核2G ,SSD 20G首月免費
阿里雲 Logstash 2核4G首月免費