近期官網給出了RedisJson（RedisSearch）的性能測驗報告，可謂碾壓其他NoSQL，下面是核心的報告內容，先上結論：
對于隔離寫入(isolated writes)，RedisJSON 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上，
對于隔離讀取(isolated reads)，RedisJSON 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上，
在混合作業負載場景中，實時更新不會影響 RedisJSON 的搜索和讀取性能，而 ElasticSearch 會受到影響，
RedisJSON* 支持的運算元/秒比 MongoDB 高約 50 倍，比 ElasticSearch 高 7 倍/秒，
RedisJSON* 的延遲比 MongoDB 低約 90 倍，比 ElasticSearch 低 23.7 倍，
此外，RedisJSON 的讀取、寫入和負載搜索延遲在更高的百分位數中遠比 ElasticSearch 和 MongoDB 穩定，當增加寫入比率時，RedisJSON 還能處理越來越高的整體吞吐量，而當寫入比率增加時，ElasticSearch 會降低它可以處理的整體吞吐量，
◆ 測驗程序
◆ 基礎設施
MongoDB v5.0.3, ElasticSearch 7.15, and RedisJSON (RediSearch 2.2+RedisJSON 2.0).
此次是在Amazon Web Services 實體上運行基準測驗，這三種解決方案都是分布式資料庫，并且最常用于生產中的分布式方式，這就是為什么所有產品都使用相同的通用 m5d.8xlarge VM 和本地 SSD，并且每個設定由四個 VM 組成：一個客戶端 + 三個資料庫服務器，基準測驗客戶端和資料庫服務器都在處于最佳網路條件下的單獨 m5d.8xlarge 實體上運行，將實體緊密地打包在一個可用區內，實作穩態分析所需的低延遲和穩定的網路性能，
測驗是在三節點集群上執行的，部署細節如下：
- MongoDB 5.0.3: 三成員副本集（Primary-Secondary-Secondary），副本用于增加讀取容量并允許更低的延遲讀取，為了支持對字串內容的文本搜索查詢，在搜索欄位上創建了一個文本索引，
- ElasticSearch 7.15: 15 個分片設定，啟用查詢快取，并為 2 個基于 NVMe 的本地 SSD 提供 RAID 0 陣列，以實作更高級別的檔案系統相關彈性操作性能，這 15 個分片為我們為 Elastic 所做的所有分片變體提供了可實作的最佳性能結果，
- RedisJSON*: RediSearch 2.2 and RedisJSON 2.0: OSS Redis Cluster v6.2.6，有27個分片，均勻分布在三個節點上，加載了RediSearch 2.2和RedisJSON 2.0 OSS模塊，
除了這個主要的基準/性能分析場景之外，我們還在網路、記憶體、CPU 和 I/O 上運行基準基準測驗，以了解底層網路和虛擬機特性，在整個基準測驗集期間，網路性能保持在帶寬和 PPS 的測量限制以下，以產生穩定穩定的超低延遲網路傳輸（每個資料包 p99 < 100micros），
我們將從提供每個單獨的操作性能 [100% 寫入] 和 [100% 讀取] 開始，并以一組混合作業負載結束以模擬現實生活中的應用程式場景，
◆ 100% 寫入基準
如下圖所示，該基準測驗表明，RedisJSON* 的攝取速度比 ElasticSearch 快 8.8 倍，比 MongoDB 快 1.8 倍，同時保持每個操作的亞毫秒級延遲，值得注意的是，99% 的 Redis 請求在不到 1.5 毫秒的時間內完成，
此外，RedisJSON* 是我們測驗過的唯一一種在每次寫入時自動更新其索引的解決方案，這意味著任何后續的搜索查詢都會找到更新的檔案，ElasticSearch 沒有這種細粒度的容量；它將攝取的檔案放在一個內部佇列中，并且該佇列由服務器（不受客戶端控制）每 N 個檔案或每 M 秒重繪一次，他們稱這種方法為近實時 (NRT)，Apache Lucene 庫（它實作了 ElasticSearch 的全文功能）旨在快速搜索，但索引程序復雜且繁重，如這些 WRITE 基準測驗圖表所示，由于這種“設計”限制，ElasticSearch 付出了巨大的代價，
結合延遲和吞吐量改進，RedisJSON* 比 Mongodb 快 5.4 倍，比 ElasticSearch 快 200 倍以上，用于隔離寫入，
◆ 100% 讀取基準
與寫類似，我們可以觀察到 Redis 在讀取方面表現最佳，允許讀取比 ElasticSearch 多 15.8 倍，比 MongoDB 多 2.8 倍，同時在整個延遲范圍內保持亞毫秒級延遲，如下表所示，
在結合延遲和吞吐量改進時，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上，用于隔離讀取，
◆ 混合讀/寫/搜索基準
實際應用程式作業負載幾乎總是讀取、寫入和搜索查詢的混合，因此，在接近飽和時了解由此產生的混合作業負載吞吐量曲線更為重要，
作為起點，我們考慮了 65% 搜索和 35% 讀取的場景，這代表了一個常見的現實世界場景，在該場景中，我們執行的搜索/查詢比直接讀取更多，65% 搜索、35% 讀取和 0% 更新的初始組合也導致 ElasticSearch 和 RedisJSON* 的吞吐量相等，盡管如此，YCSB 作業負載允許您指定搜索/讀取/更新之間的比率以滿足您的要求，
“搜索性能”可以指不同型別的搜索，例如“匹配查詢搜索”、“分面搜索”、“模糊搜索”等等，我們所做的最初向 YCSB 增加的搜索作業負載僅專注于“匹配查詢搜索”，模仿分頁的兩詞查詢匹配，按數字欄位排序，“匹配查詢搜索”是任何啟用搜索功能的供應商進行搜索分析的起點，因此，每個支持 YCSB 的資料庫/驅動程式都應該能夠在其基準驅動程式上輕松啟用此功能，
在每個測驗變體中，我們添加了 10% 的寫入，以按相同的比例混合和減少搜索和讀取百分比，這些測驗變體的目標是了解每個產品如何處理資料的實時更新，我們認為這是事實上的架構目標，即寫入立即提交到索引，讀取始終是最新的，
正如您在圖表中所看到的，在 RedisJSON* 上不斷更新資料和增加寫入比例不會影響讀取或搜索性能并提高整體吞吐量，對資料產生的更新越多，對 ElasticSearch 性能的影響就越大，最終導致讀取和搜索速度變慢，
ElasticSearch 可實作的 ops/sec 從 0% 更新到 50% 的演變，我們注意到它在 0% 更新基準上以 10k Ops/sec 開始，并受到嚴重影響，減少了 5 倍的 ops/sec，在50% 更新率基準，
與我們在上述單個操作基準中觀察到的類似，MongoDB 搜索性能比 RedisJSON* 和 ElasticSearch 慢兩個數量級，MongoDB 的最大總吞吐量為 424 ops/sec，而 RedisJSON* 為 16K 最大 ops/sec，
最后，對于混合作業負載，RedisJSON* 支持的運算元/秒比 MongoDB 高 50.8 倍，比 ElasticSearch 高 7 倍，如果我們將分析集中在混合作業負載期間的每種操作型別的延遲上，與 MongoDB 相比，RedisJSON* 可將延遲降低多達 91 倍，與 ElasticSearch 相比，延遲降低 23.7 倍，
◆ 每個解決方案的完整延遲分析
與測量每個解決方案飽和之前產生的吞吐量曲線類似，在所有解決方案通用的可持續負載下進行完整的延遲分析也很重要，這將使您能夠了解對于所有已發布操作在延遲方面最穩定的解決方案是什么，以及哪種解決方案不易受到應用程式邏輯引發的延遲峰值的影響（例如，彈性查詢快取未命中），如果您想更深入地了解我們為什么要這樣做，Gil Tene 提供了延遲測量注意事項的深入概述，
查看上一節的吞吐量圖表，并關注 10% 更新基準以包含所有三個操作，我們做了兩種不同的可持續負載變化：
-
250 ops/sec：比較 MongoDB、ElasticSearch 和 RedisJSON*，低于 MongoDB 的壓力率，
-
6000 ops/sec：比較 ElasticSearch 和 RedisJSON*，低于 ElasticSearch 壓力率，
◆ MongoDB 與 ElasticSearch 與 RedisJSON* 的延遲分析
在下面的第一張圖片中，展示了從 p0 到 p9999 的百分位數，很明顯，在每次搜索時，MongoDB 的表現都遠遠優于 Elastic 和 RedisJSON，此外，關注 ElasticSearch 與 RedisJSON，很明顯，ElasticSearch 容易受到較高延遲的影響，這很可能是由垃圾收集 (GC) 觸發器或搜索查詢快取未命中引起的，RedisJSON* 的 p99 低于 2.61 毫秒，而 ElasticSearch p999 搜索達到 10.28 毫秒，
在下面的讀取和更新圖表中，我們可以看到 RedisJSON* 在所有延遲范圍內表現最佳，其次是 MongoDB 和 ElasticSearch，
RedisJSON* 是在所有分析的延遲百分位數上保持亞毫秒級延遲的唯一解決方案，在 p99，RedisJSON* 的延遲為 0.23 毫秒，其次是 MongoDB 的 5.01 毫秒和 ElasticSearch 的 10.49 毫秒，
在寫入時，MongoDB 和 RedisJSON* 即使在 p99 時也能保持亞毫秒級的延遲，另一方面，ElasticSearch 顯示出高尾延遲（> 10 毫秒），這很可能與導致 ElasticSearch 搜索峰值的原因 (GC) 相同，
◆ ElasticSearch 與 RedisJSON 的延遲分析
僅關注 ElasticSearch 和 RedisJSON，在保持 6K ops/sec 的可持續負載的同時，我們可以觀察到 Elastic 和 RedisJSON 的讀取和更新模式與以 250 ops/sec 進行的分析保持一致，RedisJSON* 是更穩定的解決方案，其 p99 讀取時間為 3 毫秒，而 Elastic 的 p99 讀取時間為 162 毫秒，
在更新時，RedisJSON* 保留了 3 毫秒的 p99，而 ElasticSearch 則保留了 167 毫秒的 p99，
專注于搜索操作，ElasticSearch 和 RedisJSON* 以個位數 p50 延遲開始（p50 RedisJSON* 為 1.13 毫秒，而 ElasticSearch 的 p50 為 2.79 毫秒），其中 ElasticSearch 付出了 GC 觸發和查詢快取未命中的代價在較高的百分位數上，在 >= p90 百分位數上清晰可見，
RedisJSON* 將 p99 保持在 33 毫秒以下，而 ElasticSearch 上的 p99 百分位數為 163 毫秒，高出 5 倍，
◆ 總結
從上面測驗結論可以看出，RedisJson幾乎在各個方面的性能可謂碾壓ES和Mongo，所以未來怎么搞，NoSQL要變天了嗎？
原文：https://redis.com/blog/redisjson-public-preview-performance-benchmarking/
譯文：https://www.toutiao.com/a7032573350941590049/
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.勁爆！Java 協程要來了，，，
3.玩大了！Log4j 2.x 再爆雷，，，
4.Spring Boot 2.6 正式發布，一大波新特性，，
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/396028.html
標籤：Java