訂單系統存在于各行各業，如電商訂單、銀行流水、運營商話費賬單等，是一個非常廣泛、通用的系統。對于這類系統，在過去十幾年發展中已經形成了經典的做法。但是隨著互聯網的發展，以及各企業對數據的重視，需要存儲和持久化的訂單量越來越大。數據的重視程度與數據規模的膨脹帶來了新的挑戰。

需求場景

某電商平臺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的方案，開發、運維成本很高，方案選擇也存在弊端。

表格存儲（TableStore）方案

如果使用表格存儲（TableStore）研發的多元索引（SearchIndex）方案，則可以完美地解決億量級訂單系統問題。TableStore具有即開即用，按量收費等特點。多元索引隨時創建，是海量電商訂單元數據管理的優質方案。

TableStore作為阿里云提供的一款全托管、分布式NoSql型數據存儲服務，具有【海量數據存儲】、【熱點數據自動分片】、【海量數據多維檢索】等功能，天然地解決了訂單數據大爆炸這一挑戰；

同時，SearchIndex功能在保證用戶數據高可用的基礎上，提供了數據多維度搜索、統計等能力。針對多種場景創建多種索引，實現多種模式的檢索。用戶可以僅在需要的時候創建、開通索引。由TableStore來保證數據同步的一致性，這極大的降低了用戶的方案設計、服務運維、代碼開發等工作量。

基于表格存儲搭建的訂單系統頁面一覽

樣例內嵌在表格存儲控制臺中，用戶可登錄控制臺體驗系統（若為表格存儲的新用戶，需要點擊開通服務后體驗，開通免費，訂單數據存儲在公共實例中，體驗不消耗用戶存儲、流量、Cu）。

注：該樣例提供了【億量級】訂單數據。官網控制臺地址：項目樣例

二、搭建準備

若您對于億量級訂單系統的體驗不錯，希望開始自己系統的搭建之旅，只需按照如下步驟便可以著手搭建了：

1、開通表格存儲

通過控制臺開通表格存儲服務，表格存儲即開即用（后付費），采用按量付費方式，已為用戶提供足夠功能測試的免費額度。表格存儲官網控制臺、免費額度說明。

2、創建實例

通過控制臺創建表格存儲實例，選擇支持多元索引的Region。（當前階段SearchIndex功能尚未商業化，暫時開放北京、上海、深圳、杭州四地，后續逐漸開放）

創建實例后，提交工單申請多元索引功能邀測（商業化后默認打開，不使用不收費）。

邀測地址：提工單，選擇【表格存儲】》【產品功能、特性咨詢】》【創建工單】，申請內容如下：

問題描述：請填寫【申請SearchIndex邀測】

機密信息：請填寫【地域+實例名】，例：上海+myInstanceName

3、SDK下載

使用具有多元索引（SearchIndex）的SDK，官網地址，暫時java、go、node.js三種SDK增加了新功能

java-SDK

go-SDK

$ go get github.com/aliyun/aliyun-tablestore-go-sdk

4、表設計

訂單系統不僅僅是訂單一張數據表，它應包含：消費者表、售貨員表、產品表、供貨商表、交易訂單表、支付訂單表等。在本樣例中，豬腰使用最基本的四張表（消費者表、售貨員表、產品表、交易訂單表），僅以訂單表舉例如下：

表名：order_contract

三、開始搭建（核心代碼）

1、創建數據表

四張表：訂單表、消費者表、售貨員表、產品表

用戶僅需維護一個實例，按如下方式創建：通過控制臺創建、管理數據表（用戶也可以通過SDK直接創建）：

2、創建數據表索引

TableStore自動做全量、增量的索引數據同步：用戶可以通過控制臺創建、管理SearchIndex（用戶也可通過SDK創建）：

3、數據導入

插入部分測試數據（控制臺樣例中插入了1億條數據，用戶自己可以通過控制臺插入少量測試數據）；

4、數據讀取

數據讀取分為兩類：

主鍵讀取

基于原生表格存儲的主鍵列獲取：getRow， getRange， batchGetRow等。主鍵讀取用于索引（自動）反查，用戶也可以提供主鍵（訂單md5）的單條查詢的頁面，億量級下查詢速度極快。單主鍵查詢方式不支持多維度檢索；

索引讀取

基于新SearchIndex功能Query：search接口。用戶可以自由設計索引字段的多維度條件組合查詢。通過設置選擇不同的查詢參數，構建不同的查詢條件、不同排序方式；目前支持：精確查詢、范圍查詢、前綴查詢、匹配查詢、通配符查詢、短語匹配查詢、分詞字符串查詢，并通過布爾與、或組合。

如【c0001號消費者，且消費在99.99以上的訂單】組合方式如下：

作者：云棲社區 wangtantan