Polardb X-engine 如何服務巨量資料情況下的業務 (翻譯)- 1
來源:AustinDatabases
為了應對圖1中顯示的122倍峰值,阿里巴巴採用了OLTP資料庫的共享無關體系結構,其中分片用於將實物分佈在多個資料庫實力之間,並在峰值到來之前增加資料庫實力的數量,儘管這樣方法有效,但由於需要的例項的數量之多,他會帶來巨大的經濟和工程成本。
我們透過改進儲存引擎的單機容量來解決這個問題,儲存引擎是OLTP資料庫的核心元件之一,從而減少給定的峰值和吞吐量所需的實力數量,或者在固定的成本下提高可事先的吞吐量。線上促銷活動在電子商務交易中製造了高峰時段,于飛高峰時段相比,這些交易包含了更多的寫入操作,儘管近年來主記憶體容量穩步在增長,但在雙十一,需要更多更新的交易記錄,這些仍然超過設計的容量,因此我們必須利用RAM SSD HDD 組成有層次結構的儲存來解決問題。X-engine ,透過利用這種層次結構,根據資料的溫度降資料防止在不同的層次中,並使用新的記憶體技術,這就像透過主機增加水庫來排放劉聰的洪水一樣,LSM 樹結構來加速寫操作的常見技術,這裡還包括了日誌的資料結構的追加方法,最佳化基於樹結構儲存方式,以及兩者的混合形式等,我們發現其中任何一種方法都不能滿足電子交易的寫入效能,一些列儲存,不適合寫入密集交易,其他一些提升了寫入效能,但億犧牲點查詢和範圍查詢效能為代價,不適合混合讀寫的電子商務工作負載,LSM樹結構包含一個儲存在記憶體中的元件,我們可以對其應用追加方法,以事先快速的插入,病包含多個磁碟的元件,每個元件都包含級別,組成一個樹狀的結構,其中每個級別的大小明顯大於其上一級,這種資料結構非常適合分層儲存,有助於解決我們資料流湧入引起問題的處理。
快速流動的當前問題在對於大多數資料庫工作負載尤其在告訴產生資料記錄的業務中,在固定的時間段中有較強的空間特性,在雙11購物節這樣的重大促銷活動中,如全天都會舉辦不同類別的品牌的秒殺活動,以刺需求並引起客戶的注意,和購買不同的商品。這意味資料庫快取中的熱資料會不斷地變化,任何記錄的溫度也可以從熱轉溫,在轉冷。如果將資料庫快取視為水庫,底層資料視為海洋,這將產生一個冷熱資料的快速交換的過程,任何方向移動於非常深的底部,如X-engine ,儲存引擎需要確保新出現的熱資料能儘快從深層檢出並有效的進行快取。
X-Engine 是一個基於LSM樹用於OLTP資料庫的儲存引擎,主要是為了解決阿里雲巴巴電子商務平臺面臨的挑戰透過多核心的處理器執行緒的並行性,在主記憶體中處理大部分請求將寫操作與事務解耦使其非同步進行,並且將長時間的寫入分成多個步驟來進行,在多個通道中進行,增加總的資料吞吐量,為解決資料洪水的問題,X-engine 利用分層儲存的方式在不同的層級之間移動資料,利用精細化的LSM樹狀結構和最佳化的壓縮演算法。最終我們透過錨定當前資料流大量湧入的問題,透過多版本源資料索引,在資料庫寫入的時候進行更新,加快我們在分層儲存中的資料提取的速度,而不需要考慮資料的溫度。
這裡我們做了相關的工作如下並解決了我們識別了面向電子商務中的OLTP儲存引起面臨的三個挑戰,針對這個三個挑戰我們開發出基於lsm tree 下的x-engine,引入了一套最佳化的方法,解決問題,如降息後LSM樹的資料結構,PFGA加速壓縮,事務中非同步寫入多階段流水線和多版本的後設資料索引。
透過使用標準基準測試和實際的業務我們對 X-Engine進行了廣泛的評估,透過測試,結果中展現在促銷期間,透過x-engine在電子商務工作負載中的效能優於 innodb, rocksdb 這樣的資料庫引擎。
系統設計,X-Engine 是一種基於最佳化的LSM樹結構的分層OLTP的儲存引擎,基於電子商務失誤工作負載中的資料的溫度不斷的變化,我們將記錄放置在不同的儲存層,億分別提供不同的狀態的記錄的訪問的方案,這使得x-engine 可以根據記錄的熱度,來靈活的設計資料機構和訪問方法,同時我們在設計中也發現LSM樹並不能完全支援電子商務工作負載,在X-EGINE中我們設計並應用了一套最佳化方案來解決之前確定的需要解決的問題,作為 POLARDB 的一部分,X-Engine 可以部署在POLARDB 上的POLARFS上,PolarDB FS 採用了許多新的技術,以實現超低延遲的檔案系統,如使用RDMA 和 NVMe .
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70027826/viewspace-3006907/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料庫事務併發問題----各種事務隔離下的情況資料庫
- 如何在不影響整個業務情況下重構AppAPP
- Springboot在有鎖的情況下如何正確使用事務Spring Boot
- [翻譯]微服務設計模式 - 5. 服務發現 - 服務端服務發現微服務設計模式服務端
- 口譯翻譯類別及服務內容
- 中國翻譯協會:2022中國翻譯及語言服務行業發展行業
- 如何在不重構的情況下將單體拆分成微服務?微服務
- 居家辦公情況下如何使用CRM保護企業資料?
- 微服務上 AWS 雲, 在使用ALB 的情況下, Eurek 中如何配置微服務
- 服裝企業在飽和的情況下,如何避免交期延誤?
- RabbitMQ如何解決各種情況下丟資料的問題MQ
- 如何管理服務業務中的專案收入?
- [翻譯]微服務設計模式 - 3. 按業務功能拆分模式微服務設計模式
- 記一次索引分裂造成rac業務短暫業務不可用的情況索引
- 業務系統中資源爭奪情況是不存在的 - udidahan
- gorm使用事務併發情況下切有最大mysql連線數限制的情況下的BUG,踩坑了GoORMMySql
- 企業在什麼情況下引入分散式資料庫?分散式資料庫
- Filecoin Spec 翻譯 —— 【1】概述(下)
- 大資料如何改善企業業務大資料
- 資料服務在新媒體業務體系中的實踐
- 巨量算數:2023抖音生活服務綜合行業洞察白皮書(附下載)行業
- 商務部:2020年一季度我國服務貿易發展情況
- 流程挖掘:業務資料驅動如何改變你的業務? - leonardo
- 使用 Ledger 記錄(財務)情況
- 服務型企業的資源管理:助服務行業突破瓶頸!行業
- .NET應用系統的國際化-多語言翻譯服務
- 淘寶從百到千萬級併發情況下服務端架構的演進過程服務端架構
- [譯]2018 年度最佳資料庫即服務解決方案資料庫
- SqlServer 高併發的情況下,如何利用鎖保證資料的穩定性SQLServer
- 資料監控可以監測業務指標的實現情況,發現是否有升高或降低指標
- 使用Jacoco統計服務端程式碼覆蓋情況實踐服務端
- [翻譯]微服務設計模式 - 1. 單體應用模式微服務設計模式
- 2.8.1 資料庫服務資料庫
- HarmonyOS SDK實況窗服務
- 使用阿里雲PolarDB替代Oracle資料庫,申通完美扛過618業務高峰阿里Oracle資料庫
- MySQL資料庫事務各隔離級別加鎖情況--read uncommittMySql資料庫MIT
- MySQL資料庫事務各隔離級別加鎖情況--Repeatable ReaMySql資料庫
- [非專業翻譯] Mapster - 資料型別資料型別