本文介紹PolarDB高壓縮引擎(X-Engine)的產品優勢、架構及適用情境。
挑戰和訴求:歷史資料歸檔
歷史資料歸檔的挑戰
大部分業務資料的讀寫特徵,都是最新產生的資料會被更頻繁地讀取或更新,而更久之前的資料(如1年前的聊天記錄或訂單資訊)很少被訪問。 隨著業務發展,資料庫系統中會積累大量訪問頻率很低甚至為0的資料,這些資料的積累容易導致如下問題:
歷史資料和最新資料存放區在同一資料庫系統中,導致磁碟空間不足。
大量資料共用資料庫系統的記憶體、緩衝空間、磁碟IOPS等,導致效能問題。
資料量太大導致資料備份時間過長甚至備份失敗;同時如何存放備份資料也是一個問題。
針對如上問題,一種做法是對歷史資料做歸檔,將長期不使用的資料移轉至以檔案形式儲存的廉價存放裝置上,如阿里雲OSS或者阿里雲資料庫DBS服務。然而,在實際業務中,歷史資料並不完全是靜態,針對幾個月甚至幾年前的歷史資料,依舊可能存在即時地、低頻地查詢甚至更新需求。例如,在阿里巴巴內部,對淘寶或天貓歷史訂單的查詢、對企業級辦公軟體DingTalk歷史聊天記錄的查詢或對菜鳥海量歷史物流訂單的查詢等。
歷史資料歸檔的訴求
為瞭解決歷史資料的讀取和更新問題,可以使用一個單獨的資料庫用來儲存歸檔的資料,即高壓縮引擎(X-Engine)。業務對單獨的高壓縮引擎(X-Engine)一般有如下訴求:
具備大型存放區空間,支援業務持續將線上資料儲存到高壓縮引擎(X-Engine)中,而無需擔心容量問題。
與線上資料庫系統使用相同的提供者,如都支援MySQL協議等,確保應用程式端無需修改任何代碼即可同時訪問線上庫和高壓縮引擎(X-Engine)。
成本低廉,如支援通過壓縮減少資料所佔磁碟空間、使用廉價儲存介質等,確保可以使用較小的代價儲存海量的資料。
具備一定的讀寫能力,能夠滿足低頻讀寫的需求。
MySQL作為世界上使用最廣泛的開來源資料庫系統,一直缺乏一個既能滿足大容量低成本要求,又具備一定讀寫能力的歷史資料Archive Storage方案。雖然業界曾經推出過一些高壓縮引擎,如TokuDB、MyRocks等,但受限於單物理機磁碟容量限制,儲存的資料量有限。
解決方案:PolarDB高壓縮引擎(X-Engine)
為應對如上歷史資料Archive Storage方面的挑戰和訴求,PolarDB基於如下技術創新和突破,推出了高壓縮引擎(X-Engine)產品系列:
阿里巴巴自研的基於LSM-tree架構的儲存引擎X-Engine提供了強大的資料壓縮能力,滿足了歸檔資料庫低儲存成本的要求。通過LSM-Tree(Log-Structured Merge-Tree)層次化架構和Zstandard(ZSTD)壓縮演算法實現了更高的資料壓縮率,對比使用InnoDB作為儲存引擎,最高可節省70%的儲存空間。更多關於X-Engine儲存引擎的詳情,請參見X-Engine簡介。但由於採用了X-Engine引擎,在使用高壓縮引擎(X-Engine)時也存在一些限制(尤其是與MySQL的相容性限制),具體限制請參見使用說明。
PolarDB藉助於共用分布式儲存服務,實現了儲存容量線上平滑擴容,同時計算資源和儲存資源間採用高速網路互聯,並通過RDMA協議進行資料轉送,使I/O效能不再成為瓶頸。整合到PolarDB的X-Engine引擎同樣獲得了這些技術優勢。
如下技術創新將X-Engine移植進PolarDB,從而進入PolarDB雙引擎時代:
合并X-Engine的事務WAL日誌流和InnoDB的REDO日誌流,實現了一套日誌流和傳輸通道同時服務於InnoDB引擎和X-Engine引擎,管控邏輯以及與共用儲存的互動邏輯無需做任何改變,同時新增其他引擎時也可以複用這套架構。
將X-Engine的IO模組對接到PolarDB InnoDB所使用的使用者態檔案系統PFS上,實現了InnoDB與X-Engine共用同一個分布式塊裝置。同時依靠底層分布式儲存實現了快速備份。
高壓縮引擎(X-Engine)計算節點架構
高壓縮引擎(X-Engine)採用多節點架構基於共用儲存實現了一寫多讀,叢集中有一個主節點(可讀可寫)和至少一個唯讀節點,支援獨享規格和通用規格兩個子系列。
高壓縮引擎(X-Engine)多節點架構可用於保障叢集的高可用,當系統發生故障時,可讀寫的主節點和唯讀節點之間會自動進行故障切換(Failover),保證了服務可用性不低於99.99%。高壓縮引擎(X-Engine)多節點架構圖如下:
產品優勢
超大儲存容量。200 TB的儲存空間加上X-Engine資料壓縮能力,可提供500 TB以上的未經處理資料儲存容量,同時儲存空間採用Serverless方式,購買時無需選擇容量,隨著資料增長而線上自動擴容,只按實際資料量大小收費。
PolarDB高壓縮引擎(X-Engine)與官方MySQL的協議一致,相比於將歷史資料備份到HBase等NoSQL產品,應用程式端無需修改任何代碼即可同時訪問線上庫和高壓縮引擎(X-Engine)。
藉助PolarDB底層共用儲存的快速備份能力,實現對海量資料的快速備份,備份資料可以上傳到OSS等廉價存放裝置,確保資料不丟失。
高壓縮引擎(X-Engine)多節點架構藉助X-Engine引擎的資料壓縮能力,不僅能夠有效降低儲存成本,還可用於保障叢集的高可用。當系統發生故障時,可讀寫的主節點和唯讀節點之間會自動進行故障切換(Failover),保證了服務可用性不低於99.99%。
在Sysbench測試情境下,與叢集版的單InnoDB引擎相比較,這種雙引擎(InnoDB和X-Engine)混合部署方式,使叢集整體效能下降控制在20%以內。當業務資料的儲存空間達到一定規模(幾百GB或幾百TB),在叢集整體效能可控範圍內,使用者能明顯地享受到降本紅利。
適用情境
PolarDB高壓縮引擎(X-Engine)提供了超大儲存容量,它可以同時作為多個業務歷史資料的匯聚地,以方便對所有歷史資料進行集中儲存和管理,主要適用於如下幾個情境:
將PolarDB高壓縮引擎(X-Engine)作為線下自建資料庫執行個體的冷資料存放區地,線下自建資料庫包括但不限於MySQL、TiDB、PostgreSQL、SQL Server等關係型資料庫。
將PolarDB高壓縮引擎(X-Engine)作為阿里雲RDS MySQL或者PolarDB MySQL版資料庫服務的Archive Storage地,將訪問較少的歷史資料移轉到PolarDB MySQL版 X-Engine中儲存,釋放線上資料庫的空間以降低成本並提升效能。
直接將PolarDB高壓縮引擎(X-Engine)作為大容量關聯式資料庫使用,以滿足一些寫入資料量巨大,但讀頻次較低的業務的需求(如系統監控日誌等)。
您可以通過阿里雲DTS持續即時地將線上庫的資料移轉至PolarDB 高壓縮引擎(X-Engine),或通過阿里雲DMS周期性地將線上資料大量匯入到PolarDB 高壓縮引擎(X-Engine)。
版本要求
您的叢集核心版本需滿足以下條件:
MySQL 8.0.1,且修訂版本需為8.0.1.1.31及以上。
MySQL 8.0.2,且修訂版本需為8.0.2.2.12及以上。
節點規格與定價
高壓縮引擎(X-Engine)支援通用規格和獨享規格。更多詳情,請參見企業版計算節點規格。
關於高壓縮引擎(X-Engine)的計費規則,請參見計算節點計費規則。