一、概述

近期官網給出了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 會降低它可以處理的整體吞吐量。

二、查詢引擎

如前所述，reresearch和RedisJSON的開發非常強調效能。對於每一個版本，我們都想確保開發者可以體驗到穩定和產品。為此，我們我們給出了一些分析工具、探測器來進行效能分析。

並且，我們每次發行新版本時時，也在不斷的提升效能。特別是對於reresearch來說，2.2版本在載入和查詢效能上都比2.0快了1.7倍，同時還改進了吞吐量和資料載入的延遲。

2.1 載入優化

接下來的兩個圖顯示了執行紐約市計程車基準測試的執行結果（詳細資料可以檢視這裡，該基準測試測量了吞吐量和載入耗時等基礎資料。

從這些圖表中可以看出，每一個reresearch的新版本都有一個實質性的效能改進。

2.2 全文搜尋優化

為了評估搜尋效能，我們索引了590萬篇維基百科摘要。然後我們執行一個全文搜尋查詢皮膚，得到的結果如下圖所示(詳細資訊在這裡)。


從上面的圖可以看出，通過從v2.0遷移到v2.2，同樣的資料，在寫、讀、搜尋(延遲圖)方面都有了大幅度的改進，從而提高了執行Search和JSON的可實現吞吐量。

三、和其他框架的對比

為了評估RedisJSON的效能，我們決定將它與MongoDB和ElasticSearch進行比較。為了方便對比，我們會從文件儲存、本地可用、雲中可用、專業支援和提供可伸縮性、效能等方面進行全方位的對比。

我們使用了完善的YCSB標準來進行測試對比，它能夠基於常見的工作負載來評估不同的產品，測量延遲、吞吐量曲線直到飽和。除了CRUD YCSB操作之外，我們還新增了一個兩個字的搜尋操作，專門幫助開發人員、系統架構師和DevOps從業者找到適合他們用例的最佳搜尋引擎。

3.1 基準測試

此次測試，我們使用瞭如下的一些軟體環境：

• MongoDB v5.0.3
• ElasticSearch 7.15
• 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% 讀取] 開始，並以一組混合工作負載結束以模擬現實工作中的應用程式場景。

3.2 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 倍以上，用於隔離寫入。

3.3 100% 讀取基準

與寫類似，我們可以觀察到 Redis 在讀取方面表現最佳，允許讀取比 ElasticSearch 多 15.8 倍，比 MongoDB 多 2.8 倍，同時在整個延遲範圍內保持亞毫秒級延遲，如下表所示。

在結合延遲和吞吐量改進時，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上，用於隔離讀取。

3.4 混合讀/寫/搜尋基準

實際應用程式工作負載幾乎總是讀取、寫入和搜尋查詢的混合。因此，在接近飽和時瞭解由此產生的混合工作負載吞吐量曲線更為重要。

作為起點，我們考慮了 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 倍。

3.5 完整延遲分析

與測量每個解決方案飽和之前產生的吞吐量曲線類似，在所有解決方案通用的可持續負載下進行完整的延遲分析也很重要。這將使您能夠了解對於所有已釋出操作在延遲方面最穩定的解決方案是什麼，以及哪種解決方案不易受到應用程式邏輯引發的延遲峰值的影響（例如，彈性查詢快取未命中）。如果您想更深入地瞭解我們為什麼要這樣做，Gil Tene 提供了延遲測量注意事項的深入概述。

• 檢視上一節的吞吐量圖表，並關注 10% 更新基準以包含所有三個操作，我們做了兩種不同的可持續負載變化：
• 250 ops/sec：比較 MongoDB、ElasticSearch 和 RedisJSON*，低於 MongoDB 的壓力率。
• ops/sec：比較 ElasticSearch 和 RedisJSON*，低於 ElasticSearch 壓力率。

3.5.1 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) 相同。

3.5.2 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*，我們可以建立一個免費的資料庫在所有地區的Redis雲，或者使用RedisJSON docker容器。我們已經更新了redisjson的文件，以方便開發者快速的開始使用查詢和搜尋功能。此外，正如我們在最近的客戶機庫宣告中提到的，以下是幾種流行語言的客戶機驅動程式，可以幫助您快速入門。

參考：RedisJSON: Public Preview & Performance BenchmarkingRedisJson釋出官方效能報告，效能碾壓ES和Mongo