開發與維運

【最佳實踐】esrally:Elasticsearch 官方壓測工具及運用詳解

作者介紹

魏彬,普翔科技 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 日誌類數據的壓測結果。

image.png

寫性能

image.png

讀性能

image.png

其他系統指標

快速入門

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

運行結束後,會得到如下的結果。

image.png

壓測結果

對於第一次見到壓測結果的同學來說可能有些暈,這麼多數據,該怎麼看?!別急,一步步來!

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

image.png

兩次 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)中,如下圖所示:

image.png

壓測結果

在 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),在壓測的過程中就能查看相關指標。

image.png

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 數據。

image.png

Metric 數據

第一列時間是指某一次壓測的時間,第二列時間是指標採集的時間,第三列 operation 指具體執行的操作,operation 為空的指標都是總計類的,比如indexing total time 記錄的是總索引數據的時間、segments_count 是總段數等等。其他的 operation 都記錄了每一個操作的數據。需要注意的是,這裡記錄的是 operation 的所有采樣數據,不是一個最終的彙總數據。上面截圖中也可以看出同一個 hour_agg 的operation 有多項名為 service_time 的指標數據,但他們的採集時間是不同的。基於這些數據,我們可以做出某一次 race 中某個指標的可視化圖表,比如你想觀察本次 race 中 index-log 這個 task 的 throughput 指標數據,便可以通過如下圖的方式實現。

image.png

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(延遲時間)對比。

image.png

多次 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 可以提升寫性能。
image.png

測試結果

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,而且這些數據本身也不小,簡單列在下面:

image.png

這些數據文件位於 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 簡介》作者“魏彬”授權轉載,對未經許可擅自使用者,保留追究其法律責任的權利。

參考資料

  1. esrally 官方文檔
  2. Using Rally to benchmark Elasticsearch queries
    3. esrally 作者的演講視頻

4. Benchmarking Elasticsearch for your use case with Rally


image.png

阿里雲Elastic Stack】100%兼容開源ES,獨有9大能力,提供免費X-pack服務(單節點價值$6000)

相關活動


更多折扣活動,請訪問阿里雲 Elasticsearch 官網

阿里雲 Elasticsearch 商業通用版,1核2G ,SSD 20G首月免費
阿里雲 Logstash 2核4G首月免費


image.png

image.png

Leave a Reply

Your email address will not be published. Required fields are marked *