RedisJson 橫空出世，性能碾壓 ES 和 MongoDB！！
點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)
近期官網(wǎng)給出了RedisJson（RedisSearch）的性能測(cè)試報(bào)告，可謂碾壓其他NoSQL，下面是核心的報(bào)告內(nèi)容，先上結(jié)論：
對(duì)于隔離寫入(isolated writes)，RedisJSON 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上。
對(duì)于隔離讀取(isolated reads)，RedisJSON 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上。
在混合工作負(fù)載場(chǎng)景中，實(shí)時(shí)更新不會(huì)影響 RedisJSON 的搜索和讀取性能，而 ElasticSearch 會(huì)受到影響。
RedisJSON* 支持的操作數(shù)/秒比 MongoDB 高約 50 倍，比 ElasticSearch 高 7 倍/秒。
◆ 測(cè)試過(guò)程
◆ 基礎(chǔ)設(shè)施
MongoDB v5.0.3, ElasticSearch 7.15, and RedisJSON (RediSearch 2.2+RedisJSON 2.0).
推薦一個(gè) Spring Boot 基礎(chǔ)教程及實(shí)戰(zhàn)示例：https://github.com/javastacks/spring-boot-best-practice
測(cè)試是在三節(jié)點(diǎn)集群上執(zhí)行的，部署細(xì)節(jié)如下：
MongoDB 5.0.3: 三成員副本集（Primary-Secondary-Secondary）。副本用于增加讀取容量并允許更低的延遲讀取。為了支持對(duì)字符串內(nèi)容的文本搜索查詢，在搜索字段上創(chuàng)建了一個(gè)文本索引。 ElasticSearch 7.15: 15 個(gè)分片設(shè)置，啟用查詢緩存，并為 2 個(gè)基于 NVMe 的本地 SSD 提供 RAID 0 陣列，以實(shí)現(xiàn)更高級(jí)別的文件系統(tǒng)相關(guān)彈性操作性能。這 15 個(gè)分片為我們?yōu)?Elastic 所做的所有分片變體提供了可實(shí)現(xiàn)的最佳性能結(jié)果。 RedisJSON*: RediSearch 2.2 and RedisJSON 2.0: OSS Redis Cluster v6.2.6，有27個(gè)分片，均勻分布在三個(gè)節(jié)點(diǎn)上，加載了RediSearch 2.2和RedisJSON 2.0 OSS模塊。
我們將從提供每個(gè)單獨(dú)的操作性能 [100% 寫入] 和 [100% 讀取] 開(kāi)始，并以一組混合工作負(fù)載結(jié)束以模擬現(xiàn)實(shí)生活中的應(yīng)用程序場(chǎng)景。最新面試題整理好了，大家可以在Java面試庫(kù)小程序在線刷題。
◆ 100% 寫入基準(zhǔn)
結(jié)合延遲和吞吐量改進(jìn)，RedisJSON* 比 Mongodb 快 5.4 倍，比 ElasticSearch 快 200 倍以上，用于隔離寫入。
◆ 100% 讀取基準(zhǔn)
與寫類似，我們可以觀察到 Redis 在讀取方面表現(xiàn)最佳，允許讀取比 ElasticSearch 多 15.8 倍，比 MongoDB 多 2.8 倍，同時(shí)在整個(gè)延遲范圍內(nèi)保持亞毫秒級(jí)延遲，如下表所示。
在結(jié)合延遲和吞吐量改進(jìn)時(shí)，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上，用于隔離讀取。另外，Redis 系列面試題和答案全部整理好了，微信搜索Java技術(shù)棧，在后臺(tái)發(fā)送：面試，可以在線閱讀。
◆ 混合讀/寫/搜索基準(zhǔn)
實(shí)際應(yīng)用程序工作負(fù)載幾乎總是讀取、寫入和搜索查詢的混合。因此，在接近飽和時(shí)了解由此產(chǎn)生的混合工作負(fù)載吞吐量曲線更為重要。最新面試題整理好了，大家可以在Java面試庫(kù)小程序在線刷題。
作為起點(diǎn)，我們考慮了 65% 搜索和 35% 讀取的場(chǎng)景，這代表了一個(gè)常見(jiàn)的現(xiàn)實(shí)世界場(chǎng)景，在該場(chǎng)景中，我們執(zhí)行的搜索/查詢比直接讀取更多。65% 搜索、35% 讀取和 0% 更新的初始組合也導(dǎo)致 ElasticSearch 和 RedisJSON* 的吞吐量相等。盡管如此，YCSB 工作負(fù)載允許您指定搜索/讀取/更新之間的比率以滿足您的要求。
“搜索性能”可以指不同類型的搜索，例如“匹配查詢搜索”、“分面搜索”、“模糊搜索”等等。我們所做的最初向 YCSB 增加的搜索工作負(fù)載僅專注于“匹配查詢搜索”，模仿分頁(yè)的兩詞查詢匹配，按數(shù)字字段排序?！捌ヅ洳樵兯阉鳌笔侨魏螁⒂盟阉鞴δ艿墓?yīng)商進(jìn)行搜索分析的起點(diǎn)，因此，每個(gè)支持 YCSB 的數(shù)據(jù)庫(kù)/驅(qū)動(dòng)程序都應(yīng)該能夠在其基準(zhǔn)驅(qū)動(dòng)程序上輕松啟用此功能。
在每個(gè)測(cè)試變體中，我們添加了 10% 的寫入，以按相同的比例混合和減少搜索和讀取百分比。這些測(cè)試變體的目標(biāo)是了解每個(gè)產(chǎn)品如何處理數(shù)據(jù)的實(shí)時(shí)更新，我們認(rèn)為這是事實(shí)上的架構(gòu)目標(biāo)，即寫入立即提交到索引，讀取始終是最新的。
點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)
◆ 每個(gè)解決方案的完整延遲分析
與測(cè)量每個(gè)解決方案飽和之前產(chǎn)生的吞吐量曲線類似，在所有解決方案通用的可持續(xù)負(fù)載下進(jìn)行完整的延遲分析也很重要。這將使您能夠了解對(duì)于所有已發(fā)布操作在延遲方面最穩(wěn)定的解決方案是什么，以及哪種解決方案不易受到應(yīng)用程序邏輯引發(fā)的延遲峰值的影響（例如，彈性查詢緩存未命中）。如果您想更深入地了解我們?yōu)槭裁匆@樣做，Gil Tene 提供了延遲測(cè)量注意事項(xiàng)的深入概述。
查看上一節(jié)的吞吐量圖表，并關(guān)注 10% 更新基準(zhǔn)以包含所有三個(gè)操作，我們做了兩種不同的可持續(xù)負(fù)載變化：
250 ops/sec：比較 MongoDB、ElasticSearch 和 RedisJSON*，低于 MongoDB 的壓力率。
6000 ops/sec：比較 ElasticSearch 和 RedisJSON*，低于 ElasticSearch 壓力率。
◆ MongoDB 與 ElasticSearch 與 RedisJSON* 的延遲分析
在下面的第一張圖片中，展示了從 p0 到 p9999 的百分位數(shù)，很明顯，在每次搜索時(shí)，MongoDB 的表現(xiàn)都遠(yuǎn)遠(yuǎn)優(yōu)于 Elastic 和 RedisJSON*。此外，關(guān)注 ElasticSearch 與 RedisJSON*，很明顯，ElasticSearch 容易受到較高延遲的影響，這很可能是由垃圾收集 (GC) 觸發(fā)器或搜索查詢緩存未命中引起的。RedisJSON* 的 p99 低于 2.61 毫秒，而 ElasticSearch p999 搜索達(dá)到 10.28 毫秒。
在下面的讀取和更新圖表中，我們可以看到 RedisJSON* 在所有延遲范圍內(nèi)表現(xiàn)最佳，其次是 MongoDB 和 ElasticSearch。
RedisJSON* 是在所有分析的延遲百分位數(shù)上保持亞毫秒級(jí)延遲的唯一解決方案。在 p99，RedisJSON* 的延遲為 0.23 毫秒，其次是 MongoDB 的 5.01 毫秒和 ElasticSearch 的 10.49 毫秒。
在寫入時(shí)，MongoDB 和 RedisJSON* 即使在 p99 時(shí)也能保持亞毫秒級(jí)的延遲。另一方面，ElasticSearch 顯示出高尾延遲（> 10 毫秒），這很可能與導(dǎo)致 ElasticSearch 搜索峰值的原因 (GC) 相同。
◆ ElasticSearch 與 RedisJSON 的延遲分析
僅關(guān)注 ElasticSearch 和 RedisJSON*，在保持 6K ops/sec 的可持續(xù)負(fù)載的同時(shí)，我們可以觀察到 Elastic 和 RedisJSON* 的讀取和更新模式與以 250 ops/sec 進(jìn)行的分析保持一致。RedisJSON* 是更穩(wěn)定的解決方案，其 p99 讀取時(shí)間為 3 毫秒，而 Elastic 的 p99 讀取時(shí)間為 162 毫秒。
在更新時(shí)，RedisJSON* 保留了 3 毫秒的 p99，而 ElasticSearch 則保留了 167 毫秒的 p99。
專注于搜索操作，ElasticSearch 和 RedisJSON* 以個(gè)位數(shù) p50 延遲開(kāi)始（p50 RedisJSON* 為 1.13 毫秒，而 ElasticSearch 的 p50 為 2.79 毫秒），其中 ElasticSearch 付出了 GC 觸發(fā)和查詢緩存未命中的代價(jià)在較高的百分位數(shù)上，在 >= p90 百分位數(shù)上清晰可見(jiàn)。
RedisJSON* 將 p99 保持在 33 毫秒以下，而 ElasticSearch 上的 p99 百分位數(shù)為 163 毫秒，高出 5 倍。
◆ 總結(jié)
從上面測(cè)試結(jié)論可以看出，RedisJson幾乎在各個(gè)方面的性能可謂碾壓ES和MongoDB，所以未來(lái)怎么搞，NoSQL要變天了嗎？
原文：https://redis.com/blog/redisjson-public-preview-performance-benchmarking/
譯文：https://www.toutiao.com/a7032573350941590049/
關(guān)注Java技術(shù)?？锤喔韶?/strong>
