[[440897]]

圖片來(lái)自 包圖網(wǎng)

下面是核心的報(bào)告內(nèi)容，先上結(jié)論：

• 對(duì)于隔離寫(xiě)入(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ì)受到影響。

以下是具體的數(shù)據(jù)：

• RedisJSON* 支持的操作數(shù)/秒比 MongoDB 高約 50 倍，比 ElasticSearch 高 7 倍/秒。
• RedisJSON* 的延遲比 MongoDB 低約 90 倍，比 ElasticSearch 低 23.7 倍。

此外，RedisJSON 的讀取、寫(xiě)入和負(fù)載搜索延遲在更高的百分位數(shù)中遠(yuǎn)比 ElasticSearch 和 MongoDB 穩(wěn)定。

當(dāng)增加寫(xiě)入比率時(shí)，RedisJSON 還能處理越來(lái)越高的整體吞吐量，而當(dāng)寫(xiě)入比率增加時(shí)，ElasticSearch 會(huì)降低它可以處理的整體吞吐量。

查詢(xún)引擎

如前所述，reresearch 和 RedisJSON 的開(kāi)發(fā)非常強(qiáng)調(diào)性能。對(duì)于每一個(gè)版本，我們都想確保開(kāi)發(fā)者可以體驗(yàn)到穩(wěn)定和產(chǎn)品。為此，我們我們給出了一些分析工具、探測(cè)器來(lái)進(jìn)行性能分析。

并且，我們每次發(fā)行新版本時(shí)時(shí)，也在不斷的提升性能。特別是對(duì)于 reresearch 來(lái)說(shuō)，2.2 版本在加載和查詢(xún)性能上都比 2.0 快了 1.7 倍，同時(shí)還改進(jìn)了吞吐量和數(shù)據(jù)加載的延遲。

①加載優(yōu)化

接下來(lái)的兩個(gè)圖顯示了運(yùn)行紐約市出租車(chē)基準(zhǔn)測(cè)試的運(yùn)行結(jié)果。

從這些圖表中可以看出，每一個(gè) reresearch 的新版本都有一個(gè)實(shí)質(zhì)性的性能改進(jìn)。

②全文搜索優(yōu)化

為了評(píng)估搜索性能，我們索引了 590 萬(wàn)篇維基百科摘要。然后我們運(yùn)行一個(gè)全文搜索查詢(xún)面板，得到的結(jié)果如下圖所示。

從上面的圖可以看出，通過(guò)從 v2.0 遷移到 v2.2，同樣的數(shù)據(jù)，在寫(xiě)、讀、搜索(延遲圖)方面都有了大幅度的改進(jìn)，從而提高了運(yùn)行 Search 和 JSON 的可實(shí)現(xiàn)吞吐量。

和其他框架的對(duì)比

為了評(píng)估 RedisJSON 的性能，我們決定將它與 MongoDB 和 ElasticSearch 進(jìn)行比較。

為了方便對(duì)比，我們會(huì)從文檔存儲(chǔ)、本地可用、云中可用、專(zhuān)業(yè)支持和提供可伸縮性、性能等方面進(jìn)行全方位的對(duì)比。

我們使用了完善的 YCSB 標(biāo)準(zhǔn)來(lái)進(jìn)行測(cè)試對(duì)比，它能夠基于常見(jiàn)的工作負(fù)載來(lái)評(píng)估不同的產(chǎn)品，測(cè)量延遲、吞吐量曲線(xiàn)直到飽和。

除了 CRUD YCSB 操作之外，我們還添加了一個(gè)兩個(gè)字的搜索操作，專(zhuān)門(mén)幫助開(kāi)發(fā)人員、系統(tǒng)架構(gòu)師和 DevOps 從業(yè)者找到適合他們用例的最佳搜索引擎。

①基準(zhǔn)測(cè)試

此次測(cè)試，我們使用了如下的一些軟件環(huán)境：

• MongoDB v5.0.3
• ElasticSearch 7.15
• RedisJSON(RediSearch 2.2+RedisJSON 2.0)

此次是在 Amazon Web Services 實(shí)例上運(yùn)行基準(zhǔn)測(cè)試，這三種解決方案都是分布式數(shù)據(jù)庫(kù)，并且最常用于生產(chǎn)中的分布式方式。

這就是為什么所有產(chǎn)品都使用相同的通用 m5d.8xlarge VM 和本地 SSD，并且每個(gè)設(shè)置由四個(gè) VM 組成：1 個(gè)客戶(hù)端 + 3 個(gè)數(shù)據(jù)庫(kù)服務(wù)器。

基準(zhǔn)測(cè)試客戶(hù)端和數(shù)據(jù)庫(kù)服務(wù)器都在處于最佳網(wǎng)絡(luò)條件下的單獨(dú) m5d.8xlarge 實(shí)例上運(yùn)行，將實(shí)例緊密地打包在一個(gè)可用區(qū)內(nèi)，實(shí)現(xiàn)穩(wěn)態(tài)分析所需的低延遲和穩(wěn)定的網(wǎng)絡(luò)性能。

測(cè)試是在三節(jié)點(diǎn)集群上執(zhí)行的，部署細(xì)節(jié)如下：

• MongoDB 5.0.3：三成員副本集(Primary-Secondary-Secondary)。副本用于增加讀取容量并允許更低的延遲讀取。為了支持對(duì)字符串內(nèi)容的文本搜索查詢(xún)，在搜索字段上創(chuàng)建了一個(gè)文本索引。
• ElasticSearch 7.15：15 個(gè)分片設(shè)置，啟用查詢(xún)緩存，并為 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è)主要的基準(zhǔn)/性能分析場(chǎng)景之外，我們還在網(wǎng)絡(luò)、內(nèi)存、CPU 和 I/O 上運(yùn)行基準(zhǔn)基準(zhǔn)測(cè)試，以了解底層網(wǎng)絡(luò)和虛擬機(jī)特性。

在整個(gè)基準(zhǔn)測(cè)試集期間，網(wǎng)絡(luò)性能保持在帶寬和 PPS 的測(cè)量限制以下，以產(chǎn)生穩(wěn)定穩(wěn)定的超低延遲網(wǎng)絡(luò)傳輸(每個(gè)數(shù)據(jù)包 p99 < 100micros)。

接下來(lái)，我們將從提供單獨(dú)的操作性能“100% 寫(xiě)入”和“100% 讀取”開(kāi)始，并以一組混合工作負(fù)載結(jié)束以模擬現(xiàn)實(shí)工作中的應(yīng)用程序場(chǎng)景。

②100% 寫(xiě)入基準(zhǔn)

如下圖所示，該基準(zhǔn)測(cè)試表明，RedisJSON* 的攝取速度比 ElasticSearch 快 8.8 倍，比 MongoDB 快 1.8 倍，同時(shí)保持每個(gè)操作的亞毫秒級(jí)延遲。值得注意的是，99% 的 Redis 請(qǐng)求在不到 1.5 毫秒的時(shí)間內(nèi)完成。

此外，RedisJSON* 是我們測(cè)試過(guò)的唯一一種在每次寫(xiě)入時(shí)自動(dòng)更新其索引的解決方案。這意味著任何后續(xù)的搜索查詢(xún)都會(huì)找到更新的文檔。

ElasticSearch 沒(méi)有這種細(xì)粒度的容量;它將攝取的文檔放在一個(gè)內(nèi)部隊(duì)列中，并且該隊(duì)列由服務(wù)器(不受客戶(hù)端控制)每 N 個(gè)文檔或每 M 秒刷新一次。他們稱(chēng)這種方法為近實(shí)時(shí)(NRT)。

Apache Lucene 庫(kù)(它實(shí)現(xiàn)了 ElasticSearch 的全文功能)旨在快速搜索，但索引過(guò)程復(fù)雜且繁重。

如這些 WRITE 基準(zhǔn)測(cè)試圖表所示，由于這種“設(shè)計(jì)”限制，ElasticSearch 付出了巨大的代價(jià)。

結(jié)合延遲和吞吐量改進(jìn)，RedisJSON* 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上，用于隔離寫(xiě)入。

③100% 讀取基準(zhǔn)

與寫(xiě)類(lèi)似，我們可以觀察到 Redis 在讀取方面表現(xiàn)最佳，允許讀取比 ElasticSearch 多 15.8 倍，比 MongoDB 多 2.8 倍，同時(shí)在整個(gè)延遲范圍內(nèi)保持亞毫秒級(jí)延遲，如下表所示。

在結(jié)合延遲和吞吐量改進(jìn)時(shí)，RedisJSON* 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上，用于隔離讀取。

④混合讀/寫(xiě)/搜索基準(zhǔn)

實(shí)際應(yīng)用程序工作負(fù)載幾乎總是讀取、寫(xiě)入和搜索查詢(xún)的混合。因此，在接近飽和時(shí)了解由此產(chǎn)生的混合工作負(fù)載吞吐量曲線(xiàn)更為重要。

作為起點(diǎn)，我們考慮了 65% 搜索和 35% 讀取的場(chǎng)景，這代表了一個(gè)常見(jiàn)的現(xiàn)實(shí)世界場(chǎng)景，在該場(chǎng)景中，我們執(zhí)行的搜索/查詢(xún)比直接讀取更多。

65% 搜索、35% 讀取和 0% 更新的初始組合也導(dǎo)致 ElasticSearch 和 RedisJSON* 的吞吐量相等。

盡管如此，YCSB 工作負(fù)載允許您指定搜索/讀取/更新之間的比率以滿(mǎn)足您的要求。

“搜索性能”可以指不同類(lèi)型的搜索，例如“匹配查詢(xún)搜索”、“分面搜索”、“模糊搜索”等等。

我們所做的最初向 YCSB 增加的搜索工作負(fù)載僅專(zhuān)注于“匹配查詢(xún)搜索”，模仿分頁(yè)的兩詞查詢(xún)匹配，按數(shù)字字段排序。

“匹配查詢(xún)搜索”是任何啟用搜索功能的供應(yīng)商進(jìn)行搜索分析的起點(diǎn)，因此，每個(gè)支持 YCSB 的數(shù)據(jù)庫(kù)/驅(qū)動(dòng)程序都應(yīng)該能夠在其基準(zhǔn)驅(qū)動(dòng)程序上輕松啟用此功能。

在每個(gè)測(cè)試變體中，我們添加了 10% 的寫(xiě)入，以按相同的比例混合和減少搜索和讀取百分比。

這些測(cè)試變體的目標(biāo)是了解每個(gè)產(chǎn)品如何處理數(shù)據(jù)的實(shí)時(shí)更新，我們認(rèn)為這是事實(shí)上的架構(gòu)目標(biāo)，即寫(xiě)入立即提交到索引，讀取始終是最新的。

正如您在圖表中所看到的，在 RedisJSON* 上不斷更新數(shù)據(jù)和增加寫(xiě)入比例不會(huì)影響讀取或搜索性能并提高整體吞吐量。

對(duì)數(shù)據(jù)產(chǎn)生的更新越多，對(duì) ElasticSearch 性能的影響就越大，最終導(dǎo)致讀取和搜索速度變慢。

ElasticSearch 可實(shí)現(xiàn)的 ops/sec 從 0% 更新到 50% 的演變，我們注意到它在 0% 更新基準(zhǔn)上以 10k Ops/sec 開(kāi)始，并受到嚴(yán)重影響，減少了 5 倍的 ops/sec，在50% 更新率基準(zhǔn)。

與我們?cè)谏鲜鰡蝹€(gè)操作基準(zhǔn)中觀察到的類(lèi)似，MongoDB 搜索性能比 RedisJSON* 和 ElasticSearch 慢兩個(gè)數(shù)量級(jí)，MongoDB 的最大總吞吐量為 424 ops/sec，而 RedisJSON* 為 16K 最大 ops/sec。

最后，對(duì)于混合工作負(fù)載，RedisJSON* 支持的操作數(shù)/秒比 MongoDB 高 50.8 倍，比 ElasticSearch 高 7 倍。

如果我們將分析集中在混合工作負(fù)載期間的每種操作類(lèi)型的延遲上，與 MongoDB 相比，RedisJSON* 可將延遲降低多達(dá) 91 倍，與 ElasticSearch 相比，延遲降低 23.7 倍。

⑤完整延遲分析

與測(cè)量每個(gè)解決方案飽和之前產(chǎn)生的吞吐量曲線(xiàn)類(lèi)似，在所有解決方案通用的可持續(xù)負(fù)載下進(jìn)行完整的延遲分析也很重要。

這將使您能夠了解對(duì)于所有已發(fā)布操作在延遲方面最穩(wěn)定的解決方案是什么，以及哪種解決方案不易受到應(yīng)用程序邏輯引發(fā)的延遲峰值的影響(例如，彈性查詢(xún)緩存未命中)。

如果您想更深入地了解我們?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ā)器或搜索查詢(xún)緩存未命中引起的。

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 毫秒。

寫(xiě)入時(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。

專(zhuān)注于搜索操作，ElasticSearch 和 RedisJSON* 以個(gè)位數(shù) p50 延遲開(kāi)始(p50 RedisJSON* 為 1.13 毫秒，而 ElasticSearch 的 p50 為 2.79 毫秒)。

其中 ElasticSearch 付出了 GC 觸發(fā)和查詢(xún)緩存未命中的代價(jià)在較高的百分位數(shù)上，在 >= p90 百分位數(shù)上清晰可見(jiàn)。

RedisJSON* 將 p99 保持在 33 毫秒以下，而 ElasticSearch 上的 p99 百分位數(shù)為 163 毫秒，高出 5 倍。

如何開(kāi)始

開(kāi)始使用RedisJSON*，我們可以創(chuàng)建一個(gè)免費(fèi)的數(shù)據(jù)庫(kù)在所有地區(qū)的 Redis 云，或者使用 RedisJSON docker 容器。

我們已經(jīng)更新了 redisjson 的文檔，以方便開(kāi)發(fā)者快速的開(kāi)始使用查詢(xún)和搜索功能。

此外，正如我們?cè)谧罱目蛻?hù)機(jī)庫(kù)聲明中提到的，以下是幾種流行語(yǔ)言的客戶(hù)機(jī)驅(qū)動(dòng)程序，可以幫助您快速入門(mén)。

作者：xiangzhihong8 編譯

編輯：陶家龍

來(lái)源：http://33h.co/ka0gk