RedisJSON 橫空出世！
往期熱門文章：
? ?
? ?
? ?
? ?
? ?
? ?
? ?
近期官網(wǎng)給出了RedisJson（RedisSearch）的性能測試報告，可謂碾壓其他NoSQL，下面是核心的報告內(nèi)容，先上結(jié)論：
對于隔離寫入(isolated writes)，RedisJSON 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上。
對于隔離讀取(isolated reads)，RedisJSON 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上。
在混合工作負(fù)載場景中，實時更新不會影響 RedisJSON 的搜索和讀取性能，而 ElasticSearch 會受到影響。以下是具體的數(shù)據(jù)：
RedisJSON* 支持的操作數(shù)/秒比 MongoDB 高約 50 倍，比 ElasticSearch 高 7 倍/秒。
RedisJSON* 的延遲比 MongoDB 低約 90 倍，比 ElasticSearch 低 23.7 倍。
此外，RedisJSON 的讀取、寫入和負(fù)載搜索延遲在更高的百分位數(shù)中遠(yuǎn)比 ElasticSearch 和 MongoDB 穩(wěn)定。當(dāng)增加寫入比率時，RedisJSON 還能處理越來越高的整體吞吐量，而當(dāng)寫入比率增加時，ElasticSearch 會降低它可以處理的整體吞吐量。
查詢引擎
1.加載優(yōu)化
接下來的兩個圖顯示了運行紐約市出租車基準(zhǔn)測試的運行結(jié)果。該基準(zhǔn)測試測量了吞吐量和加載耗時等基礎(chǔ)數(shù)據(jù)。
從這些圖表中可以看出，每一個reresearch的新版本都有一個實質(zhì)性的性能改進(jìn)。
2.全文搜索優(yōu)化
為了評估搜索性能，我們索引了590萬篇維基百科摘要。然后我們運行一個全文搜索查詢面板，得到的結(jié)果如下圖所示
從上面的圖可以看出，通過從v2.0遷移到v2.2，同樣的數(shù)據(jù)，在寫、讀、搜索(延遲圖)方面都有了大幅度的改進(jìn)，從而提高了運行Search和JSON的可實現(xiàn)吞吐量。
和其他框架的對比
1. 基準(zhǔn)測試
此次測試，我們使用了如下的一些軟件環(huán)境：
MongoDB v5.0.3
ElasticSearch 7.15
RedisJSON (RediSearch 2.2+RedisJSON 2.0)
此次是在Amazon Web Services 實例上運行基準(zhǔn)測試，這三種解決方案都是分布式數(shù)據(jù)庫，并且最常用于生產(chǎn)中的分布式方式。這就是為什么所有產(chǎn)品都使用相同的通用 m5d.8xlarge VM 和本地 SSD，并且每個設(shè)置由四個 VM 組成：一個客戶端 + 三個數(shù)據(jù)庫服務(wù)器。基準(zhǔn)測試客戶端和數(shù)據(jù)庫服務(wù)器都在處于最佳網(wǎng)絡(luò)條件下的單獨 m5d.8xlarge 實例上運行，將實例緊密地打包在一個可用區(qū)內(nèi)，實現(xiàn)穩(wěn)態(tài)分析所需的低延遲和穩(wěn)定的網(wǎng)絡(luò)性能。
測試是在三節(jié)點集群上執(zhí)行的，部署細(xì)節(jié)如下：
MongoDB 5.0.3：三成員副本集（Primary-Secondary-Secondary）。副本用于增加讀取容量并允許更低的延遲讀取。為了支持對字符串內(nèi)容的文本搜索查詢，在搜索字段上創(chuàng)建了一個文本索引。
ElasticSearch 7.15：15 個分片設(shè)置，啟用查詢緩存，并為 2 個基于 NVMe 的本地 SSD 提供 RAID 0 陣列，以實現(xiàn)更高級別的文件系統(tǒng)相關(guān)彈性操作性能。這 15 個分片為我們?yōu)?Elastic 所做的所有分片變體提供了可實現(xiàn)的最佳性能結(jié)果。
RedisJSON*：RediSearch 2.2 and RedisJSON 2.0: OSS Redis Cluster v6.2.6，有27個分片，均勻分布在三個節(jié)點上，加載了RediSearch 2.2和RedisJSON 2.0 OSS模塊。
接下來，我們將從提供單獨的操作性能 [100% 寫入] 和 [100% 讀取] 開始，并以一組混合工作負(fù)載結(jié)束以模擬現(xiàn)實工作中的應(yīng)用程序場景。
2. 100% 寫入基準(zhǔn)
如下圖所示，該基準(zhǔn)測試表明，RedisJSON* 的攝取速度比 ElasticSearch 快 8.8 倍，比 MongoDB 快 1.8 倍，同時保持每個操作的亞毫秒級延遲。值得注意的是，99% 的 Redis 請求在不到 1.5 毫秒的時間內(nèi)完成。
此外，RedisJSON* 是我們測試過的唯一一種在每次寫入時自動更新其索引的解決方案。這意味著任何后續(xù)的搜索查詢都會找到更新的文檔。ElasticSearch 沒有這種細(xì)粒度的容量；它將攝取的文檔放在一個內(nèi)部隊列中，并且該隊列由服務(wù)器（不受客戶端控制）每 N 個文檔或每 M 秒刷新一次。他們稱這種方法為近實時 (NRT)。Apache Lucene 庫（它實現(xiàn)了 ElasticSearch 的全文功能）旨在快速搜索，但索引過程復(fù)雜且繁重。如這些 WRITE 基準(zhǔn)測試圖表所示，由于這種“設(shè)計”限制，ElasticSearch 付出了巨大的代價。
結(jié)合延遲和吞吐量改進(jìn)，RedisJSON* 比 Mongodb 快 5.4 倍，比 ElasticSearch 快 200 倍以上，用于隔離寫入。
3. 100% 讀取基準(zhǔn)
與寫類似，我們可以觀察到 Redis 在讀取方面表現(xiàn)最佳，允許讀取比 ElasticSearch 多 15.8 倍，比 MongoDB 多 2.8 倍，同時在整個延遲范圍內(nèi)保持亞毫秒級延遲，如下表所示。
在結(jié)合延遲和吞吐量改進(jìn)時，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上，用于隔離讀取。
4. 混合讀/寫/搜索基準(zhǔn)
實際應(yīng)用程序工作負(fù)載幾乎總是讀取、寫入和搜索查詢的混合。因此，在接近飽和時了解由此產(chǎn)生的混合工作負(fù)載吞吐量曲線更為重要。
正如您在圖表中所看到的，在 RedisJSON* 上不斷更新數(shù)據(jù)和增加寫入比例不會影響讀取或搜索性能并提高整體吞吐量。對數(shù)據(jù)產(chǎn)生的更新越多，對 ElasticSearch 性能的影響就越大，最終導(dǎo)致讀取和搜索速度變慢。
ElasticSearch 可實現(xiàn)的 ops/sec 從 0% 更新到 50% 的演變，我們注意到它在 0% 更新基準(zhǔn)上以 10k Ops/sec 開始，并受到嚴(yán)重影響，減少了 5 倍的 ops/sec，在50% 更新率基準(zhǔn)。
與我們在上述單個操作基準(zhǔn)中觀察到的類似，MongoDB 搜索性能比 RedisJSON* 和 ElasticSearch 慢兩個數(shù)量級，MongoDB 的最大總吞吐量為 424 ops/sec，而 RedisJSON* 為 16K 最大 ops/sec。
最后，對于混合工作負(fù)載，RedisJSON* 支持的操作數(shù)/秒比 MongoDB 高 50.8 倍，比 ElasticSearch 高 7 倍。如果我們將分析集中在混合工作負(fù)載期間的每種操作類型的延遲上，與 MongoDB 相比，RedisJSON* 可將延遲降低多達(dá) 91 倍，與 ElasticSearch 相比，延遲降低 23.7 倍。
5. 完整延遲分析
與測量每個解決方案飽和之前產(chǎn)生的吞吐量曲線類似，在所有解決方案通用的可持續(xù)負(fù)載下進(jìn)行完整的延遲分析也很重要。這將使您能夠了解對于所有已發(fā)布操作在延遲方面最穩(wěn)定的解決方案是什么，以及哪種解決方案不易受到應(yīng)用程序邏輯引發(fā)的延遲峰值的影響（例如，彈性查詢緩存未命中）。如果您想更深入地了解我們?yōu)槭裁匆@樣做，Gil Tene 提供了延遲測量注意事項的深入概述。
查看上一節(jié)的吞吐量圖表，并關(guān)注 10% 更新基準(zhǔn)以包含所有三個操作，我們做了兩種不同的可持續(xù)負(fù)載變化：
250 ops/sec：比較 MongoDB、ElasticSearch 和 RedisJSON*，低于 MongoDB 的壓力率。
6000 ops/sec：比較 ElasticSearch 和 RedisJSON*，低于 ElasticSearch 壓力率。
1 MongoDB 與 ElasticSearch 與 RedisJSON* 的延遲分析
在下面的第一張圖片中，展示了從 p0 到 p9999 的百分位數(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ù)上保持亞毫秒級延遲的唯一解決方案。在 p99，RedisJSON* 的延遲為 0.23 毫秒，其次是 MongoDB 的 5.01 毫秒和 ElasticSearch 的 10.49 毫秒。
在寫入時，MongoDB 和 RedisJSON* 即使在 p99 時也能保持亞毫秒級的延遲。另一方面，ElasticSearch 顯示出高尾延遲（> 10 毫秒），這很可能與導(dǎo)致 ElasticSearch 搜索峰值的原因 (GC) 相同。
2. ElasticSearch 與 RedisJSON 的延遲分析
在更新時，RedisJSON* 保留了 3 毫秒的 p99，而 ElasticSearch 則保留了 167 毫秒的 p99。
專注于搜索操作，ElasticSearch 和 RedisJSON* 以個位數(shù) p50 延遲開始（p50 RedisJSON* 為 1.13 毫秒，而 ElasticSearch 的 p50 為 2.79 毫秒），其中 ElasticSearch 付出了 GC 觸發(fā)和查詢緩存未命中的代價在較高的百分位數(shù)上，在 >= p90 百分位數(shù)上清晰可見。
RedisJSON* 將 p99 保持在 33 毫秒以下，而 ElasticSearch 上的 p99 百分位數(shù)為 163 毫秒，高出 5 倍。
來源：
來源：xiangzhihong8
鏈接：https://blog.csdn.net/xiangzhihong8/article/details/121530019
如果看到這里，說明你喜歡這篇文章，請?轉(zhuǎn)發(fā)、點贊。同時?標(biāo)星（置頂）本公眾號可以第一時間接受到博文推送。
推薦閱讀：（點擊標(biāo)題可跳轉(zhuǎn)）
基于 SpringBoot + Vue 的前后端分離的考試系統(tǒng)
干掉 XML Mapper，新出的 Fluent Mybatis 真香！
最牛逼的性能監(jiān)控系統(tǒng)！集強(qiáng)大功能于一身
編程·技術(shù)·經(jīng)驗
歡迎掃碼關(guān)注