寫入性能
服務(wù)器資源
| 資源 | 數(shù)值 |
|---|---|
| 服務(wù)器 | 華為 |
| 系統(tǒng) | centos7.9 |
| cpu | Intel? Core? i5-10500 CPU @ 3.10GHz、6核12線程 |
| mem | 62G |
| disk | 機械硬盤、3.6T |
單機寫入性能
將es堆內(nèi)存增大到20G，其余配置不做任何修改，數(shù)據(jù)單條寫入。測試結(jié)果如下
| 線程 | 線程延遲時間(ms) | 數(shù)據(jù)量(W) | 平均響應時間(ms) | QPS |
|---|---|---|---|---|
| 300 | 0 | 5.9 | 338 | 222 |
| 300 | 0 | 81 | 369 | 217 |
附件一：
附件二：
??從上面測試結(jié)果來看，在不做優(yōu)化前提下，es并發(fā)寫入單條耗時約在360ms。這個性能相比大多數(shù)場景都已滿足，不過如果項目對數(shù)據(jù)存儲和周轉(zhuǎn)的實時性要求高，那么還是要對寫入性能做優(yōu)化。
寫入性能優(yōu)化
方案一：業(yè)務(wù)優(yōu)化
??在業(yè)務(wù)上，最常見的優(yōu)化手段就是變單條寫入為批量寫入。而es本身支持批量插入，就是bulk操作。我在第三章“Elasticsearch專欄-3.es基本用法-基礎(chǔ)api”中也提到了bulk的使用方法。
??本次測試，我的優(yōu)化方式是：數(shù)據(jù)接入時，先不寫庫，而是直接推送到消息隊列中（這里我使用的是rabbitmq）。然后監(jiān)聽該隊列，批量拿消息。測試時，是一次拿去1000條。最后將這1000條數(shù)據(jù)批量寫入es。實測結(jié)果是，1000條批量寫入耗時和單條寫入耗時相差不大。附圖略。
??除了按數(shù)量批量寫入外，還可以按照時間。比如每秒寫入一次，有多少數(shù)量就寫入多少。其實這種方法應該更合理，像mysql底層數(shù)據(jù)和日志落盤的策略，其中就有每秒落盤一次的策略。上篇文章中，也做了圖說明，有興趣可以參考下。
方案二：底層優(yōu)化
??除了業(yè)務(wù)優(yōu)化外，還有就是從底層優(yōu)化。而底層優(yōu)化，最常見的就是刷盤策略。因為我們都知道，正在的耗時就是磁盤IO。
??這里我直接貼出優(yōu)化的參數(shù)，如下：
| 參數(shù) | 優(yōu)化后值 | 含義 |
|---|---|---|
| index.refresh_interval | 10s | 緩存刷新時間，即10s后數(shù)據(jù)才能被搜索 |
| index.translog.durability | async | 異步 |
| index.translog.flush_threshold_size | 1024mb | translog大小達到多大時落盤 |
| index.translog.sync_interval | 30s | translog每隔多久落盤 |
??其中，效果最明顯的就是index.translog.durability。它表示的是日志持久化策略，默認情況下是同步策略，即寫一條數(shù)據(jù)要等日志落盤后才返回。這種效率慢，但能保證數(shù)據(jù)安全性。
??將index.translog.durability改為async后，就是異步策略。數(shù)據(jù)寫入緩存后，里面返回，不會等待日志是否落盤成功。這種效率很快，但數(shù)據(jù)安全性差。
測試結(jié)果如下:(后臺無報錯，es入庫數(shù)據(jù)量和jemter發(fā)送量一致)
| 線程 | 線程延遲時間(ms) | 數(shù)據(jù)量(W) | 平均響應時間(ms) | QPS |
|---|---|---|---|---|
| 500 | 100 | 1000 | 13 | 4100 |
附件：
從上面測試結(jié)果來看，改同步為異步后，寫入性能有了量級的提升。這個平均耗時（13ms）和吞吐量（4100）已經(jīng)相當于消息隊列了。
查詢性能
因為業(yè)務(wù)需要，有考慮從mysql切換到es。所以查詢性能，我采用es和mysql做對比。數(shù)據(jù)量選用680w,1050w，2000w。查詢內(nèi)容包括：總和統(tǒng)計、多條件列表查詢、分頁查詢、詳情查詢等多個維度。下面列出對比的數(shù)據(jù)。（數(shù)據(jù)結(jié)構(gòu)和查詢邏輯后續(xù)專門章節(jié)說明，本次只展示比對結(jié)果。）
1.總和統(tǒng)計耗時：ms
| 數(shù)據(jù)量 | 680w | 1050w | 2000w |
|---|---|---|---|
| es | 18 | 29 | 45 |
| mysql | 36 | 52 | 144 |
2.近5天數(shù)量趨勢統(tǒng)計耗時：ms
| 數(shù)據(jù)量 | 680w | 1050w | 2000w |
|---|---|---|---|
| es | 71 | 62 | 450 |
| mysql | 2.7s | 4.2s | 8s |
3.分組統(tǒng)計耗時：ms
| 數(shù)據(jù)量 | 680w | 1050w | 2000w |
|---|---|---|---|
| es | 20 | 74 | 54 |
| mysql | 2.8s | 4.3s | 8.4s |
4.es列表查詢及分頁耗時：ms
| 數(shù)據(jù)量 | 第一頁 | 第10頁 | 第100頁 | 第1000頁 |
|---|---|---|---|---|
| 1050w | 79 | 35 | 30 | 34 |
5.詳情查詢耗時：ms
| 數(shù)據(jù)量 | 680w | 1050w | 2000w |
|---|---|---|---|
| es | 61 | 55 | 62 |
| mysql | 37 | 35 | 60 |
從對比結(jié)果來看，es整體性能要優(yōu)于mysql。總結(jié)如下：
1.數(shù)據(jù)量從百萬級到千萬級，對es的查詢耗時影響不大，基本每次查詢都在幾十毫秒。但對mysql影響很大，數(shù)據(jù)量越多，查詢越慢，這也符合實際情況。
2.es分頁沒有想象的那樣，越靠后翻頁越慢。整個分頁查詢都很穩(wěn)定。
3.查詢單條數(shù)據(jù)時，mysql如果走索引情況下，速度是非?？斓?，有可能比es都要快。
4.總的來說，es的性能和穩(wěn)定性要比mysql好。無論查詢條件變化如何，數(shù)據(jù)量多少，es的查詢耗時都不會相差很大。
資源占用情況
cpu
| 線程 | 300t | 500t |
|---|---|---|
| es | 9% | 9% |
| mysql | 64% | 112% |
隨著線程的增加，mysql占用CPU明顯比es高
mem
| 數(shù)據(jù)量 | 680w | 1050w | 2000w |
|---|---|---|---|
| es | 23G | 23G | 23G |
| mysql | 24G | - | 48G |
隨著壓測數(shù)據(jù)量的增加，es內(nèi)存并沒有增大，而mysql增加了很多。因為mysql innodb_buff我設(shè)置的是40G，所以增加這么多內(nèi)存也不難理解，都被mysql底層緩存占用了。
disk文章來源：http://www.zghlxwxcb.cn/news/detail-410981.html
| 數(shù)據(jù)量 | 680w | 1050w | 2000w |
|---|---|---|---|
| es | 2.1G | 2.9G | 5G |
| mysql | 1.9G | 2.7G | 5.3G |
從結(jié)果來看，mysql存儲數(shù)據(jù)占用磁盤還是比es多。
總結(jié)：es對cpu、mem、disk等資源占用，相比mysql來說要少。文章來源地址http://www.zghlxwxcb.cn/news/detail-410981.html
到了這里，關(guān)于Elasticsearch專欄-8.es讀寫性能及優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
