文章來源：虹科云科技

越來越多的應用程序依賴于龐大的數(shù)據(jù)集合，而這些應用程序必須快速響應。借助自動分層，Redis Enterprise 7.2 幫助開發(fā)人員輕松創(chuàng)建超快的應用程序。何樂而不為？

Redis將數(shù)據(jù)存儲在內(nèi)存中，因此應用程序能以最快的速度檢索和處理數(shù)據(jù)。然而，隨著應用程序需要處理的數(shù)據(jù)越多，存儲數(shù)據(jù)集所需的內(nèi)存越大，所耗費的成本則更高，Redis Enterprise自動分層技術(shù)能很好地化解這個兩難的局面。

一、問題：內(nèi)存有限且昂貴

當應用程序訪問的數(shù)據(jù)量很大，例如達到TB級時，開發(fā)人員就面臨著內(nèi)存有限的問題，他們一般使用基于磁盤的解決方案來在幕后支持 Redis。這樣一來，開發(fā)人員就不得不在應用程序中構(gòu)建整個數(shù)據(jù)管理系統(tǒng)，這意味著他們要把時間花在不相干的任務上。

利用Redis Enterprise 的自動分層功能 ，開發(fā)人員可以使用固態(tài)硬盤（SSD）作為可用內(nèi)存的一部分，將大容量數(shù)據(jù)庫擴展到SSD中。Redis Enterprise 可以隨時識別哪些數(shù)據(jù)應留在內(nèi)存中，哪些數(shù)據(jù)應留在固態(tài)硬盤上，從而將吞吐量提高一倍，并將延遲減半。

因此，開發(fā)人員無需編寫額外的代碼或?qū)W習其他新技術(shù)。通過將動態(tài)RAM 與高速外部存儲相結(jié)合，Redis Enterprise 可以輕松高效地使用系統(tǒng)資源，同時還能快速訪問熱數(shù)據(jù)。

二、自動分層的工作原理

自動分層可自動管理數(shù)據(jù)。它會將熱數(shù)據(jù)轉(zhuǎn)移到DRAM，并智能地將未使用的數(shù)據(jù)轉(zhuǎn)移到 SSD。這為依賴大型數(shù)據(jù)集的應用帶來了新的可能性。

通過將訪問頻率較低的冷數(shù)據(jù)轉(zhuǎn)移到固態(tài)硬盤，開發(fā)人員可以優(yōu)化內(nèi)存使用，降低與大容量內(nèi)存需求相關(guān)的成本。

實際上，這可以使數(shù)據(jù)量大的應用程序運行得更快，而無需開發(fā)人員額外付出。與僅使用DRAM 的部署相比，它還能節(jié)省高達 70% 的基礎硬件設施成本。而且，由于自動分層可以高效地自動管理數(shù)據(jù)訪問模式，因此您無需花費時間（計算或人工篩選）來識別熱數(shù)據(jù)和冷數(shù)據(jù)。

為了增強這一功能，Redis 與創(chuàng)新的鍵值存儲引擎 Speedb 建立了戰(zhàn)略合作伙伴關(guān)系。我們將其技術(shù)整合為默認的自動分層引擎。

集成Speedb 后，Redis Enterprise 的性能顯著提升，在訪問相同資源的情況下，吞吐量翻倍，延遲減半。這大大拓寬了可利用自動分層優(yōu)勢的用例范圍。在這一改進之后，Redis Enterprise 使用自動分層的數(shù)據(jù)庫規(guī)模由每個內(nèi)核 5k ops/秒增至10k ops/秒。

三、數(shù)據(jù)案例

我們來看一個案例。

下圖展示了自動分層在實際工作負載場景中的性能演變示例。藍色條代表使用以前的存儲引擎（RocksDB）的 Redis Enterprise 6.4，紅色條代表使用 Speedb 的 Redis Enterprise 7.2。在基礎設施方面，我們使用 I4i.8xlarge AWS 實例在 10 個分片上托管 1TB 數(shù)據(jù)庫，為實現(xiàn)高可用性，采用總共 20 個分片，為 1,024 個客戶端提供服務。

為了模擬最標準的Redis 用例，我們在 20% DRAM 和 80% SSD 的配置上定義了兩種不同的有效載荷（1KiB 和 10KiB），并提供了三種可能的使用模式：平衡讀/寫（1:1）、重讀（1:4）和重寫（4:1）。在這兩種情況下，我們測量了以每秒操作數(shù)為單位的吞吐量和相應的延遲。以下圖表顯示了結(jié)果。

RAM/SSD數(shù)據(jù)占比2:8，單次操作1KB值

與RS 6.4 (RocksDB) 相比，RS 7.2 (Speedb) 改進了：

· 85% 命中率時：每秒操作次數(shù)增加 1.4 倍至 1.6 倍，同時延遲降低高達 2.4 倍

· 50% 命中率時：每秒操作次數(shù)增加 1.9 倍至 2.3 倍，同時延遲降低高達 3.8 倍

RAM/SSD數(shù)據(jù)占比2:8，單次操作10KB值

與RS 6.4 (RocksDB) 相比，RS 7.2 (Speedb) 改進了：

· 85% 命中率時：每秒操作次數(shù)增加 2.3 倍至 3.0 倍，同時延遲降低高達 3.0 倍

· 50% 命中率時：每秒操作次數(shù)增加 2.1 倍至 3.5 倍，同時延遲降低高達 3.5 倍

在所有情況下，帶有Speedb 的 Redis Enterprise 7.2 都具有更好的吞吐量，這意味著維持這種性能水平所需的應用程序速度更快，基礎設施更少。

四、應用場景

自動分層尤其適用于將數(shù)據(jù)分為熱數(shù)據(jù)和冷數(shù)據(jù)的情況。

1.移動銀行

讓我們來看看移動銀行應用的例子。

如今，每個人的移動設備上都有銀行應用程序。 用戶登錄應用程序，獲取余額，查看最后一筆交易，并獲取其他相對較小和集中的信息。 每個人都希望這一過程流暢、簡單、即時。這些數(shù)據(jù)就是我們的熱數(shù)據(jù)，存放在Redis Enterprise 數(shù)據(jù)庫的 DRAM 中。

用戶希望獲得更多信息的情況并不常見，例如舊交易記錄--也許是兩年前的稅務數(shù)據(jù)。用戶需要訪問這些數(shù)據(jù)，但數(shù)據(jù)訪問速度并不那么重要。這種數(shù)據(jù)集是我們的冷數(shù)據(jù)，可以保存在高速外部存儲如固態(tài)硬盤中。

2.游戲行業(yè)

速度在游戲行業(yè)也很重要。例如， 游戲應用對延遲有嚴格要求 。另外，從本質(zhì)上講，游戲是一種潮流。隨著時間的推移，游戲公司會積累越來越多的用戶數(shù)據(jù)，并將其存儲在用戶資料數(shù)據(jù)庫中，但并非所有用戶都是活躍用戶。通過自動分層，活躍用戶的資料數(shù)據(jù)可以存儲在DRAM 中，而其他用戶的數(shù)據(jù)則存儲在 SSD 中。

審核編輯 黃宇