一、背景

訂單系統存在於各行各業，如電商訂單、銀行流水、運營商話費賬單等，是一個非常廣泛、通用的系統。對於這類系統，在過去十幾年發展中已經形成了經典的做法。但是隨著網際網路的發展，以及各企業對資料的重視，需要儲存和持久化的訂單量越來越大。資料的重視程度與資料規模的膨脹帶來了新的挑戰，原有的系統是否還能繼續滿足需求成了焦點？

需求場景

某電商平臺A，需要進行持久化所有平臺產生的訂單資料。同時，基於所有的訂單資料，系統又需要向外提供面向多種角色：消費者、店家、平臺三類人群的多元化的查詢服務。消費者可以查詢自己的歷史訂單，商家可以統計熱銷產品，平臺也可以分析使用者行為、平臺交易規模等。主要查詢方式涵蓋訂單的多維度檢索，以及訂單資料的分析、統計等，例如：
面向消費者：【A消費者】*【近1年】*【產品名含'電腦'欄位】訂單查詢；
面向店家：【B店家】*【近1個月】*【每個產品】銷售量排名；
......

技術點

在訂單場景中，技術上通常需要考慮的技術點，主要包含如下幾個方面：

• 查詢能力：需要具備豐富的查詢型別，如多維度、範圍、模糊查詢等，同時具備排序、統計等功能；

• 資料量：儲存海量資料的同時，滿足強一致、高可用、低成本等要求；

• 服務效能：應對高併發請求高併發的同時，保證低延遲；

二、方案演進

應對訂單場景，電商通常會採用MySQL傳統方案。藉助關係型資料庫強大的查詢能力，使用者可直接透過SQL語句實現訂單資料的多維度查詢、資料統計等。所謂資料膨脹，分為橫向、縱向兩種，橫向即不斷迭代引入的新欄位維度，縱向即總的儲存資料量。在面對這兩種訂單資料膨脹上，單MySql方案逐漸變得吃力。 SQL + NoSQL的組合方案（以下稱：組合方案） 便應運而生，藉助兩個資料庫各自的優勢分別解決不同場景各自的需求。但 組合方案 同樣也帶來了新的問題，組合方案犧牲空間成本，同時也增加了開發工作量與運維複雜度。在保證資料一致性上產生額外開銷。

下面讓我們看一下如下幾個常規方案：

常規方案

1、MySql分庫分表方案

MySql自身擁有強大的資料查詢、分析功能，基於MyQql建立訂單系統，可以應對訂單資料多維查詢、統計場景。伴隨著訂單資料量的增加，使用者會採取分庫、分表方案應對，透過這種偽分散式方案，解決資料膨脹帶來的問題。但資料一旦達到瓶頸，便需要重新建立更大規模的分庫+資料的全量遷移，麻煩就會不斷出現。資料迭代、膨脹帶來的困擾，是MySql方案難於逾越的。僅僅依靠MySql的傳統訂單方案短板凸顯。
1、資料縱向（資料規模）膨脹：採用分庫分表方案，MySql在部署時需要預估分庫規模，資料量一旦達到上限後，重新部署並做資料全量遷移；
2、資料橫向（欄位維度）膨脹：schema需預定義，迭代新增新欄位變更復雜。而維度到達一定量後影響資料庫效能；

2、MySql+HBase方案

引入雙資料的方案應運而生，透過實時資料、歷史資料分存的方案，可以一定程度解決資料量膨脹問題。該方案將資料歸類成兩部分儲存：實時資料、歷史資料。同時透過資料同步服務，將過期資料同步至歷史資料。
1、實時訂單資料（例如：近3個月的訂單）：將實時訂單存入MySql資料庫。實時訂單的總量膨脹的速度得到了限制，同時保證了實時資料的多維查詢、分析能力；
2、歷史訂單資料（例如：3個月以前的訂單）：將歷史訂單資料存入HBase，藉助於HBase這一分散式NoSql資料庫，有效應對了訂單資料膨脹困擾。也保證了歷史訂單資料的持久化；
但是，該方案犧牲了歷史訂單資料對使用者、商家、平臺的使用價值，假設了歷史資料的需求頻率極低。但是一旦有需求，便需要全表掃描，查詢速度慢、IO成本很高。而維護資料同步又帶來了資料一致性、同步運維成本飆升等難題；

3、MySql+ Elasticsearch 方案

組合方案還有MySql+ Elasticsearch ，該方案同樣是將資料分兩部分儲存，可以一定程度解決訂單索引維度增長問題。使用者自己維護資料同步服務，保證兩部分資料的一致性；
1、全量資料：將全量的訂單資料存入MySql資料庫，訂單ID之外的資料整體存為一個欄位。該全量資料作為持久化儲存，也用於非索引欄位的反查；
2、查詢資料：僅將需要檢索的欄位存入 Elasticsearch （基於Lucene分散式索引資料庫），藉助於 Elasticsearch 的索引能力，提供可以應付維度膨脹的訂單資料，然後必要時反查MySql獲取訂單完整資訊；
該方案應付了資料維度膨脹帶來的困擾，但是隨著訂單量的不斷膨脹，MySql擴充套件性差的問題再次暴露出來。同時資料同步至 Elasticsearch 的方案，開發、運維成本很高，方案選擇也存在弊端。

能力分析	MySql	HBase	Elasticsearch	TableStore
儲存方式	行儲存	列儲存	索引儲存	列儲存+索引儲存
擴充套件性	單機、擴充套件性差	水平擴充套件	水平擴充套件	（自動）水平擴充套件
一致性	強一致性	強一致性、時序一致性		強一致性、時序一致性
檢索	較弱的支援	不支援	支援	支援
資料量	~ 1T，~億行	~10 PB，~萬億行	~1 PB，~千億行	~10 PB，~萬億行

TableStore方案

如果使用表格儲存（TableStore）研發的多元索引（SearchIndex）方案，則可以完美地解決以上問題。TableStore具有即開即用，按量收費等特點。多元索引隨時建立，是海量電商訂單後設資料管理的優質方案。
TableStore作為阿里雲提供的一款全託管、分散式NoSql型資料儲存服務，具有【海量資料儲存】、【熱點資料自動分片】、【海量資料多維檢索】等功能，天然地解決了訂單資料大爆炸這一挑戰；
同時，SearchIndex功能在保證使用者資料高可用的基礎上，提供了資料多維度搜尋、統計等能力。針對多種場景建立多種索引，實現多種模式的檢索。使用者可以僅在需要的時候建立、開通索引。由TableStore來保證資料同步的一致性，這極大的降低了使用者的方案設計、服務運維、程式碼開發等工作量。