本文主要為您介紹針對訂單系統的一些傳統解決方案，以及面對億量級訂單，表格存儲提供的更全面的解決方案。
傳統方案一：MySQL分庫分表
MySQL自身擁有強大的數據查詢、分析功能，基于MySQL創建訂單系統，可以應對訂單數據多維查詢和統計場景。伴隨著訂單數據量的增加，采取分庫分表方案應對，通過這種偽分布式方案解決數據膨脹帶來的問題。但數據一旦達到瓶頸，便會出現明顯的弊端。
- 數據縱向（數據規模）膨脹：采用分庫分表方案，MySQL在部署時需要預估分庫規模，數據量一旦達到上限后，重新部署并做數據全量遷移。
- 數據橫向（字段維度）膨脹：schema需預定義，迭代新增新字段變更復雜。而維度到達一定量后影響數據庫性能。
傳統方案二：MySQL+HBase
引入雙數據的方案應運而生，通過實時數據和歷史數據分存的方案，可以一定程度解決數據量膨脹問題。該方案將數據歸類成兩部分存儲：實時數據、歷史數據。
- 實時訂單數據（例如近3個月的訂單）：將實時訂單存入MySQL數據庫。實時訂單的總量膨脹的速度得到了限制，同時保證了實時數據的多維查詢和分析能力。
- 歷史訂單數據（例如3個月以前的訂單）：通過數據同步服務，將歷史訂單數據存入HBase，借助于HBase這一分布式NoSQL數據庫，有效應對了訂單數據膨脹困擾。也保證了歷史訂單數據的持久化。
但是，該方案犧牲了歷史訂單數據對用戶、商家、平臺的使用價值，假設了歷史數據的需求頻率極低。但是一旦有需求，便需要全表掃描，查詢速度慢、I/O成本很高。而維護數據同步又帶來了數據一致性、同步運維成本飆升等難題。
傳統方案三：MySQL+Elasticsearch
此方案同樣是將數據分兩部分存儲，可以一定程度解決訂單索引維度增長問題。用戶自己維護數據同步服務，保證兩部分數據的一致性。
- 全量數據：將全量的訂單數據存入MySQL數據庫，訂單ID之外的數據整體存為一個字段。該全量數據作為持久化存儲，也用于非索引字段的反查。
- 查詢數據：僅將需要檢索的字段存入Elasticsearch（基于Lucene分布式索引數據庫），借助于Elasticsearch的索引能力，提供可以應付維度膨脹的訂單數據，然后必要時反查MySQL獲取訂單完整信息。
該方案應付了數據維度膨脹帶來的困擾，但是隨著訂單量的不斷膨脹，MySQL擴展性差的問題再次暴露出來。同時數據同步到Elasticsearch的方案，開發、運維成本很高，方案選擇也存在弊端。
表格存儲解決方案
由上可以看出，傳統的方案并不能完全應對億量級訂單場景。使用表格存儲研發的多元索引（SearchIndex）方案，則可以解決億量級訂單系統問題。表格存儲具有即開即用，按量收費等特點。多元索引隨時創建，是海量電商訂單元數據管理的優質方案。
表格存儲作為面向海量結構化數據提供的Serverless表存儲服務，具有海量數據存儲、熱點數據自動分片、海量數據多維檢索等功能，能有效解決訂單數據大爆炸的挑戰。同時，多元索引功能在保證用戶數據高可用的基礎上提供了數據多維度搜索、統計等能力。針對多種場景創建多種索引，實現多種模式的檢索。可以僅在需要時創建索引，由表格存儲來保證數據同步的一致性，降低了用戶的方案設計、服務運維、代碼開發等工作量。
下圖為表格存儲與傳統訂單方案使用的工具在各項性能上的對比：
