一、方案背景

訂單系統(tǒng)存在于各行各業(yè)，如電商訂單、銀行流水、運(yùn)營(yíng)商話費(fèi)賬單等，是一個(gè)非常廣泛、通用的系統(tǒng)。對(duì)于這類系統(tǒng)，在過去十幾年發(fā)展中已經(jīng)形成了經(jīng)典的做法。但是隨著互聯(lián)網(wǎng)的發(fā)展，以及各企業(yè)對(duì)數(shù)據(jù)的重視，需要存儲(chǔ)和持久化的訂單量越來越大。數(shù)據(jù)的重視程度與數(shù)據(jù)規(guī)模的膨脹帶來了新的挑戰(zhàn)。

需求場(chǎng)景

某電商平臺(tái)A，需要進(jìn)行持久化所有平臺(tái)產(chǎn)生的訂單數(shù)據(jù)。同時(shí)，基于所有的訂單數(shù)據(jù)，系統(tǒng)又需要向外提供面向多種角色：消費(fèi)者、店家、平臺(tái)三類人群的多元化的查詢服務(wù)。消費(fèi)者可以查詢自己的歷史訂單，商家可以統(tǒng)計(jì)熱銷產(chǎn)品，平臺(tái)也可以分析用戶行為、平臺(tái)交易規(guī)模等。主要查詢方式涵蓋訂單的多維度檢索，以及訂單數(shù)據(jù)的分析、統(tǒng)計(jì)等，例如：
面向消費(fèi)者：【A消費(fèi)者】*【近1年】*【賣出電腦】訂單查詢；
面向售貨員：【B售貨員】*【近1個(gè)月】銷售訂單；
......

技術(shù)點(diǎn)

在訂單場(chǎng)景中，技術(shù)上通常需要考慮的技術(shù)點(diǎn)，主要包含如下幾個(gè)方面：

• 查詢能力：需要具備豐富的查詢類型，如多維度、范圍、模糊查詢等，同時(shí)具備排序、統(tǒng)計(jì)等功能；
• 數(shù)據(jù)量：存儲(chǔ)海量數(shù)據(jù)的同時(shí)，滿足強(qiáng)一致、高可用、低成本等要求；
• 服務(wù)性能：應(yīng)對(duì)高并發(fā)請(qǐng)求高并發(fā)的同時(shí)，保證低延遲；

實(shí)現(xiàn)多維、實(shí)時(shí)查詢功能，是訂單管理解決方案的核心功能。

二、方案演進(jìn)

應(yīng)對(duì)訂單場(chǎng)景，電商通常會(huì)采用MySQL傳統(tǒng)方案。借助關(guān)系型數(shù)據(jù)庫(kù)強(qiáng)大的查詢能力，用戶可直接通過SQL語句實(shí)現(xiàn)訂單數(shù)據(jù)的多維度查詢、數(shù)據(jù)統(tǒng)計(jì)等。所謂數(shù)據(jù)膨脹，分為橫向、縱向兩種，橫向即不斷迭代引入的新字段維度，縱向即總的存儲(chǔ)數(shù)據(jù)量。在面對(duì)這兩種訂單數(shù)據(jù)膨脹上，單MySql方案逐漸變得吃力。?SQL + NoSQL的組合方案（以下稱：組合方案）便應(yīng)運(yùn)而生，借助兩個(gè)數(shù)據(jù)庫(kù)各自的優(yōu)勢(shì)分別解決不同場(chǎng)景各自的需求。但組合方案同樣也帶來了新的問題，組合方案犧牲空間成本，同時(shí)也增加了開發(fā)工作量與運(yùn)維復(fù)雜度。在保證數(shù)據(jù)一致性上產(chǎn)生額外開銷。
下面讓我們看一下如下幾個(gè)常規(guī)方案：

常規(guī)方案

1、MySql分庫(kù)分表方案

MySql自身擁有強(qiáng)大的數(shù)據(jù)查詢、分析功能，基于MyQql創(chuàng)建訂單系統(tǒng)，可以應(yīng)對(duì)訂單數(shù)據(jù)多維查詢、統(tǒng)計(jì)場(chǎng)景。伴隨著訂單數(shù)據(jù)量的增加，用戶會(huì)采取分庫(kù)、分表方案應(yīng)對(duì)，通過這種偽分布式方案，解決數(shù)據(jù)膨脹帶來的問題。但數(shù)據(jù)一旦達(dá)到瓶頸，便需要重新創(chuàng)建更大規(guī)模的分庫(kù)+數(shù)據(jù)的全量遷移，麻煩就會(huì)不斷出現(xiàn)。數(shù)據(jù)迭代、膨脹帶來的困擾，是MySql方案難于逾越的。僅僅依靠MySql的傳統(tǒng)訂單方案短板凸顯。
1、數(shù)據(jù)縱向（數(shù)據(jù)規(guī)模）膨脹：采用分庫(kù)分表方案，MySql在部署時(shí)需要預(yù)估分庫(kù)規(guī)模，數(shù)據(jù)量一旦達(dá)到上限后，重新部署并做數(shù)據(jù)全量遷移；
2、數(shù)據(jù)橫向（字段維度）膨脹：schema需預(yù)定義，迭代新增新字段變更復(fù)雜。而維度到達(dá)一定量后影響數(shù)據(jù)庫(kù)性能；

2、MySql+HBase方案

引入雙數(shù)據(jù)的方案應(yīng)運(yùn)而生，通過實(shí)時(shí)數(shù)據(jù)、歷史數(shù)據(jù)分存的方案，可以一定程度解決數(shù)據(jù)量膨脹問題。該方案將數(shù)據(jù)歸類成兩部分存儲(chǔ)：實(shí)時(shí)數(shù)據(jù)、歷史數(shù)據(jù)。同時(shí)通過數(shù)據(jù)同步服務(wù)，將過期數(shù)據(jù)同步至歷史數(shù)據(jù)。
1、實(shí)時(shí)訂單數(shù)據(jù)（例如：近3個(gè)月的訂單）：將實(shí)時(shí)訂單存入MySql數(shù)據(jù)庫(kù)。實(shí)時(shí)訂單的總量膨脹的速度得到了限制，同時(shí)保證了實(shí)時(shí)數(shù)據(jù)的多維查詢、分析能力；
2、歷史訂單數(shù)據(jù)（例如：3個(gè)月以前的訂單）：將歷史訂單數(shù)據(jù)存入HBase，借助于HBase這一分布式NoSql數(shù)據(jù)庫(kù)，有效應(yīng)對(duì)了訂單數(shù)據(jù)膨脹困擾。也保證了歷史訂單數(shù)據(jù)的持久化；
但是，該方案犧牲了歷史訂單數(shù)據(jù)對(duì)用戶、商家、平臺(tái)的使用價(jià)值，假設(shè)了歷史數(shù)據(jù)的需求頻率極低。但是一旦有需求，便需要全表掃描，查詢速度慢、IO成本很高。而維護(hù)數(shù)據(jù)同步又帶來了數(shù)據(jù)一致性、同步運(yùn)維成本飆升等難題；

3、MySql+Elasticsearch方案

組合方案還有MySql+Elasticsearch，該方案同樣是將數(shù)據(jù)分兩部分存儲(chǔ)，可以一定程度解決訂單索引維度增長(zhǎng)問題。用戶自己維護(hù)數(shù)據(jù)同步服務(wù)，保證兩部分?jǐn)?shù)據(jù)的一致性；
1、全量數(shù)據(jù)：將全量的訂單數(shù)據(jù)存入MySql數(shù)據(jù)庫(kù)，訂單ID之外的數(shù)據(jù)整體存為一個(gè)字段。該全量數(shù)據(jù)作為持久化存儲(chǔ)，也用于非索引字段的反查；
2、查詢數(shù)據(jù)：僅將需要檢索的字段存入Elasticsearch（基于Lucene分布式索引數(shù)據(jù)庫(kù)），借助于Elasticsearch的索引能力，提供可以應(yīng)付維度膨脹的訂單數(shù)據(jù)，然后必要時(shí)反查MySql獲取訂單完整信息；
該方案應(yīng)付了數(shù)據(jù)維度膨脹帶來的困擾，但是隨著訂單量的不斷膨脹，MySql擴(kuò)展性差的問題再次暴露出來。同時(shí)數(shù)據(jù)同步至Elasticsearch的方案，開發(fā)、運(yùn)維成本很高，方案選擇也存在弊端。

能力分析MySqlHBaseElasticsearchTableStore

存儲(chǔ)方式	行存儲(chǔ)	列存儲(chǔ)	索引存儲(chǔ)	列存儲(chǔ)+索引存儲(chǔ)
擴(kuò)展性	單機(jī)、擴(kuò)展性差	水平擴(kuò)展	水平擴(kuò)展	（自動(dòng)）水平擴(kuò)展
一致性	強(qiáng)一致性	強(qiáng)一致性、時(shí)序一致性	?	強(qiáng)一致性、時(shí)序一致性
檢索	較弱的支持	不支持	支持	支持
數(shù)據(jù)量	~ 1T，~億行	~10 PB，~萬億行	~1 PB，~千億行	~10 PB，~萬億行

表格存儲(chǔ)（TableStore）方案

如果使用表格存儲(chǔ)（TableStore）研發(fā)的多元索引（SearchIndex）方案，則可以完美地解決億量級(jí)訂單系統(tǒng)問題。TableStore具有即開即用，按量收費(fèi)等特點(diǎn)。多元索引隨時(shí)創(chuàng)建，是海量電商訂單元數(shù)據(jù)管理的優(yōu)質(zhì)方案。
TableStore作為阿里云提供的一款全托管、分布式NoSql型數(shù)據(jù)存儲(chǔ)服務(wù)，具有【海量數(shù)據(jù)存儲(chǔ)】、【熱點(diǎn)數(shù)據(jù)自動(dòng)分片】、【海量數(shù)據(jù)多維檢索】等功能，天然地解決了訂單數(shù)據(jù)大爆炸這一挑戰(zhàn)；
同時(shí)，SearchIndex功能在保證用戶數(shù)據(jù)高可用的基礎(chǔ)上，提供了數(shù)據(jù)多維度搜索、統(tǒng)計(jì)等能力。針對(duì)多種場(chǎng)景創(chuàng)建多種索引，實(shí)現(xiàn)多種模式的檢索。用戶可以僅在需要的時(shí)候創(chuàng)建、開通索引。由TableStore來保證數(shù)據(jù)同步的一致性，這極大的降低了用戶的方案設(shè)計(jì)、服務(wù)運(yùn)維、代碼開發(fā)等工作量。

基于表格存儲(chǔ)搭建的訂單系統(tǒng)頁面一覽

樣例內(nèi)嵌在表格存儲(chǔ)控制臺(tái)中，用戶可登錄控制臺(tái)體驗(yàn)系統(tǒng)（若為表格存儲(chǔ)的新用戶，需要點(diǎn)擊開通服務(wù)后體驗(yàn)，開通免費(fèi)，訂單數(shù)據(jù)存儲(chǔ)在公共實(shí)例中，體驗(yàn)不消耗用戶存儲(chǔ)、流量、Cu）。
注：該樣例提供了【億量級(jí)】訂單數(shù)據(jù)。

?

二、搭建準(zhǔn)備

若您對(duì)于億量級(jí)訂單系統(tǒng)的體驗(yàn)不錯(cuò)，希望開始自己系統(tǒng)的搭建之旅，只需按照如下步驟便可以著手搭建了：

1、開通表格存儲(chǔ)

通過控制臺(tái)開通表格存儲(chǔ)服務(wù)，表格存儲(chǔ)即開即用（后付費(fèi)），采用按量付費(fèi)方式，已為用戶提供足夠功能測(cè)試的免費(fèi)額度。表格存儲(chǔ)官網(wǎng)控制臺(tái)、免費(fèi)額度說明。

2、創(chuàng)建實(shí)例

通過控制臺(tái)創(chuàng)建表格存儲(chǔ)實(shí)例，選擇支持多元索引的Region。（當(dāng)前階段SearchIndex功能尚未商業(yè)化，暫時(shí)開放北京、上海、深圳、杭州四地，后續(xù)逐漸開放）

?

創(chuàng)建實(shí)例后，提交工單申請(qǐng)多元索引功能邀測(cè)（商業(yè)化后默認(rèn)打開，不使用不收費(fèi)）。

• 邀測(cè)地址：提工單，選擇【表格存儲(chǔ)】>【產(chǎn)品功能、特性咨詢】>【創(chuàng)建工單】，申請(qǐng)內(nèi)容如下：
• 問題描述:請(qǐng)?zhí)顚憽旧暾?qǐng)SearchIndex邀測(cè)】
• 機(jī)密信息:請(qǐng)?zhí)顚憽镜赜?#43;實(shí)例名】，例：上海+myInstanceName

?

3、SDK下載

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

java-SDK

<dependency><groupId>com.aliyun.openservices</groupId><artifactId>tablestore</artifactId><version>4.7.4</version> </dependency>

go-SDK

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

4、表設(shè)計(jì)

訂單系統(tǒng)不僅僅是訂單一張數(shù)據(jù)表，它應(yīng)包含：消費(fèi)者表、售貨員表、產(chǎn)品表、供貨商表、交易訂單表、支付訂單表等。在本樣例中，豬腰使用最基本的四張表（消費(fèi)者表、售貨員表、產(chǎn)品表、交易訂單表），僅以訂單表舉例如下：
表名：order_contract

列名數(shù)據(jù)類型索引類型字段說明

_id(主鍵列)	String	?	MD5(oId)避免熱點(diǎn)
oId	String	KEYWORD	訂單編號(hào)
pName	String	TEXT	產(chǎn)品名，TEXT類型索引可模糊查詢，但不能排序
totalPrice	double	DOUBLE	訂單總價(jià)
orderTime	long	LONG	下單時(shí)間（時(shí)間戳）
...	...	...	...

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

1、創(chuàng)建數(shù)據(jù)表

四張表：訂單表、消費(fèi)者表、售貨員表、產(chǎn)品表
用戶僅需維護(hù)一個(gè)實(shí)例，按如下方式創(chuàng)建：通過控制臺(tái)創(chuàng)建、管理數(shù)據(jù)表（用戶也可以通過SDK直接創(chuàng)建）：

?

2、創(chuàng)建數(shù)據(jù)表索引
TableStore自動(dòng)做全量、增量的索引數(shù)據(jù)同步：用戶可以通過控制臺(tái)創(chuàng)建、管理SearchIndex（用戶也可通過SDK創(chuàng)建）：

?

3、數(shù)據(jù)導(dǎo)入

插入部分測(cè)試數(shù)據(jù)（控制臺(tái)樣例中插入了1億條數(shù)據(jù)，用戶自己可以通過控制臺(tái)插入少量測(cè)試數(shù)據(jù)）；

訂單號(hào)訂單（md5）（主鍵）消費(fèi)者編號(hào)消費(fèi)者姓名售貨員編號(hào)售貨員姓名產(chǎn)品編號(hào)產(chǎn)品名產(chǎn)品品牌產(chǎn)品類型下單時(shí)間支付時(shí)間支付狀態(tài)產(chǎn)品單價(jià)數(shù)量總價(jià)錢

o0000000000

c49f5fd5aba33159accae0d3ecd749a7

c0019

消陳九

s0020

售楚十

p0003004

vivo x21

vivo

手機(jī)

2018-07-17 21:00:00

?

否

2498.99

2

4997.98

消費(fèi)者編號(hào)（主鍵）消費(fèi)者姓名消費(fèi)者積分注冊(cè)時(shí)間

c0001	消趙一	818	2018-07-07 14:33:51

售貨員編號(hào)（主鍵）售貨員姓名售貨員積分入職日期

s0001	售趙一	613	2018-07-07 14:27:59

產(chǎn)品編號(hào)（主鍵）產(chǎn)品名產(chǎn)品品牌產(chǎn)品類型產(chǎn)品單價(jià)新增時(shí)間

p0001001	iphone 6	蘋果	手機(jī)	6969.00	2018-07-07 14:44:39

4、數(shù)據(jù)讀取

數(shù)據(jù)讀取分為兩類：

主鍵讀取

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

索引讀取

基于新SearchIndex功能Query：search接口。用戶可以自由設(shè)計(jì)索引字段的多維度條件組合查詢。通過設(shè)置選擇不同的查詢參數(shù)，構(gòu)建不同的查詢條件、不同排序方式；目前支持：精確查詢、范圍查詢、前綴查詢、匹配查詢、通配符查詢、短語匹配查詢、分詞字符串查詢，并通過布爾與、或組合。
如【c0001號(hào)消費(fèi)者，且消費(fèi)在99.99以上的訂單】組合方式如下：

List<Query> mustQueries = new ArrayList<Query>();TermQuery termQuery = new TermQuery(); termQuery.setFieldName("cId"); termQuery.setTerm(ColumnValue.fromString("c0001")); mustQueries.add(termQuery);RangeQuery rangeQuery = new RangeQuery(); rangeQuery.setFieldName("totalPrice"); rangeQuery.setFrom(ColumnValue.fromDouble(99.99)）; mustQueries.add(rangeQuery);BoolQuery boolQuery = new BoolQuery(); boolQuery.setMustQueries(mustQueries);

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的基于TableStore的亿级订单管理解决方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。