基於X-Engine引擎的PolarDB-X叢集支撐了淘寶歷史訂單資料庫業務，解決了使用HBase資料庫遺留的問題，降低儲存成本的同時，滿足了使用者隨時查詢訂單的需求。
背景資訊
阿里巴巴旗下的淘寶是中國著名的線上購物平台，活躍使用者數量超過數億人。
在如此體量巨大的平台上，每天的實物和虛擬商品交易達到億層級。每次交易會涉及到會員資訊驗證、商品庫資訊查詢、訂單建立、庫存扣減、優惠扣減、訂單支付、物流資訊更新和確認支付等，每個環節都涉及到資料庫記錄建立和狀態更新，整個流程可能涉及到數百次資料庫事務操作，整個資料庫叢集每天會執行數百億次事務讀寫。資料庫團隊不僅要保證資料庫系統效能穩定，還需要考慮每日遞增海量資料帶來的巨大儲存成本壓力。
交易訂單是整個交易過程最為關鍵的資訊，由於可能涉及到交易糾紛處理，需要隨時提供使用者查詢，必須永久記錄在資料庫中。淘寶成立至今，與訂單相關的資料庫記錄總量達到了萬億層級，所佔用磁碟空間也早已超過PB級。
下文將為您詳細介紹淘寶是如何做到既滿足使用者隨時查詢訂單的低延時需求，又控制儲存成本。
架構演化歷史
淘寶從2003年成立至今，近17年時間，隨著流量不斷增加，交易訂單資料庫結構描述也經歷過數次演化：
第一階段
淘寶起步階段由於流量較小，使用Oracle資料庫儲存所有訂單資訊，訂單建立和歷史訂單查詢都在同一資料庫進行。
第二階段
由於歷史訂單資料量越來越大，單一資料庫已經不能同時滿足效能和容量需求，於是對交易訂單庫進行拆分，分為線上庫和歷史庫，將三個月之前的歷史訂單遷移進歷史庫，但是由於資料量巨大，不能滿足查詢需求，因此當時的使用者只能查詢三個月之內的歷史訂單資訊。
第三階段
為瞭解決儲存成本和歷史訂單查詢問題，淘寶將歷史訂單遷移到HBase資料庫。
整體方案是使用主表結合索引表，查詢訂單詳細資料通過主表完成，通過買家或者賣家ID查詢訂單，則需要藉助索引表先得到訂單號。這個方案遺留一個問題，訂單不一定按照時間順序遷移到歷史訂單庫，很多類型訂單並不遷移到歷史訂單庫，所以會導致訂單列表不是嚴格按照時間排序，使用者可能會發現自己的近期訂單出現在不正確的位置。
第四階段
歷史訂單資料庫採用基於X-Engine引擎的PolarDB-X叢集，既降低了儲存成本，也解決了亂序問題。
業務痛點
回顧淘寶交易訂單資料庫演化歷史，自拆分出歷史訂單資料庫，在後續十年時間裡，業務團隊和資料庫團隊一直在應對幾個核心挑戰：
儲存成本
由於每日寫入資料量巨大，必須保證儲存成本極低。
查詢功能
提供豐富查詢功能，例如按時間排序、按訂單類型尋找等，因此底層資料庫需要支援二級索引，且二級索引需要保證一致性和效能。
查詢延時
保證較低查詢延時，不影響使用者體驗。雖然90天前的歷史訂單查詢量比90天內少很多，但仍然需要保證延時在一定範圍內。
基於X-Engine引擎的歷史訂單資料庫方案
交易訂單系統在線上庫和歷史庫分離的架構下迭代了十年時間，很多業務代碼對這套分離架構做了相容，考慮到對業務代碼改造以及遷移的風險，我們在初期延續了分離架構，只是將原有HBase叢集替換成PolarDB-X叢集（X-Engine引擎）。詳細方案如下：
線上庫依然沿用之前MySQL叢集（InnoDB引擎），但是只儲存最近90天訂單，資料量少，可以保證較高的快取命中率，確保讀寫延時。
通過資料同步將線上庫中超過90天的訂單遷移到歷史庫中，並從線上庫中刪除。
歷史庫儲存引擎切換為X-Engine，儲存超過90天的所有交易訂單資料，超過90天的訂單讀寫，直接操作歷史庫。
使用新方案後，歷史庫儲存成本相比使用HBase時沒有上升；歷史庫和線上庫互相相容，可以建立完全一樣的索引，解決了排序異常問題；歷史庫的冷熱分離保證了讀取延時。
總結
淘寶交易訂單記錄流水型的訪問特徵是最近寫入的記錄會被大量訪問，隨著時間推移，記錄訪問頻次急劇衰減。X-Engine引擎的冷熱分離機制能很好地處理這種流水型業務，單一X-Engine資料庫叢集完全可以解決此類需求。
對於新開業務或者有大量流水型記錄儲存需求的現有業務，如果業務層面還未做冷熱分離，建議您直接使用X-Engine引擎，基於X-Engine引擎的分散式資料庫PolarDB-X可以同時解決擴充問題和儲存成本問題。
目前X-Engine引擎已經在阿里雲上線， 需要的使用者可以購買使用。詳情請參見快速建立RDS MySQL執行個體。