您好,登錄后才能下訂單哦!
訂單系統存在于各行各業,如電商訂單、銀行流水、運營商話費賬單等,是一個非常廣泛、通用的系統。對于這類系統,在過去十幾年發展中已經形成了經典的做法。但是隨著互聯網的發展,以及各企業對數據的重視,需要存儲和持久化的訂單量越來越大。數據的重視程度與數據規模的膨脹帶來了新的挑戰。
某電商平臺A,需要進行持久化所有平臺產生的訂單數據。同時,基于所有的訂單數據,系統又需要向外提供面向多種角色:消費者、店家、平臺三類人群的多元化的查詢服務。消費者可以查詢自己的歷史訂單,商家可以統計熱銷產品,平臺也可以分析用戶行為、平臺交易規模等。主要查詢方式涵蓋訂單的多維度檢索,以及訂單數據的分析、統計等,例如:
面向消費者:【A消費者】*【近1年】*【賣出電腦】訂單查詢;
面向售貨員:【B售貨員】*【近1個月】銷售訂單;
......
在訂單場景中,技術上通常需要考慮的技術點,主要包含如下幾個方面:
查詢能力:需要具備豐富的查詢類型,如多維度、范圍、模糊查詢等,同時具備排序、統計等功能;
數據量:存儲海量數據的同時,滿足強一致、高可用、低成本等要求;
服務性能:應對高并發請求高并發的同時,保證低延遲;
實現多維、實時查詢功能,是訂單管理解決方案的核心功能,官網控制臺地址:
項目樣例
cdn.com/01df85ba45158cf32b5254759dd6a128847d2984.gif">
應對訂單場景,電商通常會采用MySQL傳統方案。借助關系型數據庫強大的查詢能力,用戶可直接通過SQL語句實現訂單數據的多維度查詢、數據統計等。所謂數據膨脹,分為橫向、縱向兩種,橫向即不斷迭代引入的新字段維度,縱向即總的存儲數據量。在面對這兩種訂單數據膨脹上,單MySql方案逐漸變得吃力。
SQL + NoSQL的組合方案(以下稱:組合方案)
便應運而生,借助兩個數據庫各自的優勢分別解決不同場景各自的需求。但
組合方案
同樣也帶來了新的問題,組合方案犧牲空間成本,同時也增加了開發工作量與運維復雜度。在保證數據一致性上產生額外開銷。
下面讓我們看一下如下幾個常規方案:
MySql自身擁有強大的數據查詢、分析功能,基于MyQql創建訂單系統,可以應對訂單數據多維查詢、統計場景。伴隨著訂單數據量的增加,用戶會采取分庫、分表方案應對,通過這種偽分布式方案,解決數據膨脹帶來的問題。但數據一旦達到瓶頸,便需要重新創建更大規模的分庫+數據的全量遷移,麻煩就會不斷出現。數據迭代、膨脹帶來的困擾,是MySql方案難于逾越的。僅僅依靠MySql的傳統訂單方案短板凸顯。
1、數據縱向(數據規模)膨脹:采用分庫分表方案,MySql在部署時需要預估分庫規模,數據量一旦達到上限后,重新部署并做數據全量遷移;
2、數據橫向(字段維度)膨脹:schema需預定義,迭代新增新字段變更復雜。而維度到達一定量后影響數據庫性能;
引入雙數據的方案應運而生,通過實時數據、歷史數據分存的方案,可以一定程度解決數據量膨脹問題。該方案將數據歸類成兩部分存儲:實時數據、歷史數據。同時通過數據同步服務,將過期數據同步至歷史數據。
1、實時訂單數據(例如:近3個月的訂單):將實時訂單存入MySql數據庫。實時訂單的總量膨脹的速度得到了限制,同時保證了實時數據的多維查詢、分析能力;
2、歷史訂單數據(例如:3個月以前的訂單):將歷史訂單數據存入HBase,借助于HBase這一分布式NoSql數據庫,有效應對了訂單數據膨脹困擾。也保證了歷史訂單數據的持久化;
但是,該方案犧牲了歷史訂單數據對用戶、商家、平臺的使用價值,假設了歷史數據的需求頻率極低。但是一旦有需求,便需要全表掃描,查詢速度慢、IO成本很高。而維護數據同步又帶來了數據一致性、同步運維成本飆升等難題;
組合方案還有MySql+
Elasticsearch
,該方案同樣是將數據分兩部分存儲,可以一定程度解決訂單索引維度增長問題。用戶自己維護數據同步服務,保證兩部分數據的一致性;
1、全量數據:將全量的訂單數據存入MySql數據庫,訂單ID之外的數據整體存為一個字段。該全量數據作為持久化存儲,也用于非索引字段的反查;
2、查詢數據:僅將需要檢索的字段存入
Elasticsearch
(基于Lucene分布式索引數據庫),借助于
Elasticsearch
的索引能力,提供可以應付維度膨脹的訂單數據,然后必要時反查MySql獲取訂單完整信息;
該方案應付了數據維度膨脹帶來的困擾,但是隨著訂單量的不斷膨脹,MySql擴展性差的問題再次暴露出來。同時數據同步至
Elasticsearch
的方案,開發、運維成本很高,方案選擇也存在弊端。
能力分析 | MySql | HBase | Elasticsearch | TableStore |
---|---|---|---|---|
存儲方式 | 行存儲 | 列存儲 | 索引存儲 | 列存儲+索引存儲 |
擴展性 | 單機、擴展性差 | 水平擴展 | 水平擴展 | (自動)水平擴展 |
一致性 | 強一致性 | 強一致性、時序一致性 |
|
強一致性、時序一致性 |
檢索 | 較弱的支持 | 不支持 | 支持 | 支持 |
數據量 | ~ 1T,~億行 | ~10 PB,~萬億行 | ~1 PB,~千億行 | ~10 PB,~萬億行 |
如果使用表格存儲(TableStore)研發的多元索引(SearchIndex)方案,則可以完美地解決億量級訂單系統問題。TableStore具有即開即用,按量收費等特點。多元索引隨時創建,是海量電商訂單元數據管理的優質方案。
TableStore作為阿里云提供的一款全托管、分布式NoSql型數據存儲服務,具有【海量數據存儲】、【熱點數據自動分片】、【海量數據多維檢索】等功能,天然地解決了訂單數據大爆炸這一挑戰;
同時,SearchIndex功能在保證用戶數據高可用的基礎上,提供了數據多維度搜索、統計等能力。針對多種場景創建多種索引,實現多種模式的檢索。用戶可以僅在需要的時候創建、開通索引。由TableStore來保證數據同步的一致性,這極大的降低了用戶的方案設計、服務運維、代碼開發等工作量。
樣例內嵌在表格存儲控制臺中,用戶可登錄控制臺體驗系統(若為表格存儲的新用戶,需要點擊開通服務后體驗,開通免費,訂單數據存儲在公共實例中,體驗不消耗用戶存儲、流量、Cu)。
注:該樣例提供了【億量級】訂單數據。官網控制臺地址:
項目樣例
若您對于億量級訂單系統的體驗不錯,希望開始自己系統的搭建之旅,只需按照如下步驟便可以著手搭建了:
通過控制臺開通表格存儲服務,表格存儲即開即用(后付費),采用按量付費方式,已為用戶提供足夠功能測試的免費額度。 表格存儲官網控制臺 、 免費額度說明 。
通過控制臺創建表格存儲實例,選擇支持多元索引的Region。(當前階段SearchIndex功能尚未商業化,暫時開放 北京、上海、深圳、杭州四地,后續逐漸開放)
創建實例后,提交工單申請多元索引功能邀測(商業化后默認打開,不使用不收費)。
邀測地址: 提工單 ,選擇 【表格存儲】>【產品功能、特性咨詢】>【創建工單】,申請內容如下:
問題描述:請填寫【申請SearchIndex邀測】
機密信息:請填寫【地域+實例名】,例:上海+myInstanceName
使用具有多元索引(SearchIndex)的SDK, 官網地址 ,暫時java、go、node.js三種SDK增加了新功能
<dependency> <groupId>com.aliyun.openservices</groupId> <artifactId>tablestore</artifactId> <version>4.7.4</version></dependency>
$ go get github.com/aliyun/aliyun-tablestore-go-sdk
訂單系統不僅僅是訂單一張數據表,它應包含:消費者表、售貨員表、產品表、供貨商表、交易訂單表、支付訂單表等。在本樣例中,豬腰使用最基本的四張表(消費者表、售貨員表、產品表、交易訂單表),僅以訂單表舉例如下:
表名:order_contract
列名 | 數據類型 | 索引類型 | 字段說明 |
---|---|---|---|
_id(主鍵列) | String |
|
MD5(oId)避免熱點 |
oId | String | KEYWORD | 訂單編號 |
pName | String | TEXT | 產品名,TEXT類型索引可模糊查詢,但不能排序 |
totalPrice | double | DOUBLE | 訂單總價 |
orderTime | long | LONG | 下單時間(時間戳) |
... | ... | ... | ... |
四張表:訂單表、消費者表、售貨員表、產品表
用戶僅需維護一個實例,按如下方式創建:通過控制臺創建、管理數據表(用戶也可以通過SDK直接創建):
2、創建數據表索引
TableStore自動做全量、增量的索引數據同步:用戶可以通過控制臺創建、管理SearchIndex(用戶也可通過SDK創建):
插入部分測試數據(控制臺樣例中插入了1億條數據,用戶自己可以通過控制臺插入少量測試數據);
訂單號 | 訂單(md5)(主鍵) | 消費者編號 | 消費者姓名 | 售貨員編號 | 售貨員姓名 | 產品編號 | 產品名 | 產品品牌 | 產品類型 | 下單時間 | 支付時間 | 支付狀態 | 產品單價 | 數量 | 總價錢 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
o0000000000 | c49f5fd5aba33159accae0d3ecd749a7 | c0019 | 消陳九 | s0020 | 售楚十 | p0003004 | vivo x21 | vivo | 手機 | 2018-07-17 21:00:00 |
|
否 | 2498.99 | 2 | 4997.98 |
消費者編號(主鍵) | 消費者姓名 | 消費者積分 | 注冊時間 |
---|---|---|---|
c0001 | 消趙一 | 818 | 2018-07-07 14:33:51 |
售貨員編號(主鍵) | 售貨員姓名 | 售貨員積分 | 入職日期 |
---|---|---|---|
s0001 | 售趙一 | 613 | 2018-07-07 14:27:59 |
產品編號(主鍵) | 產品名 | 產品品牌 | 產品類型 | 產品單價 | 新增時間 |
---|---|---|---|---|---|
p0001001 | iphone 6 | 蘋果 | 手機 | 6969.00 | 2018-07-07 14:44:39 |
數據讀取分為兩類:
基于原生表格存儲的主鍵列獲取:getRow, getRange, batchGetRow等。主鍵讀取用于索引(自動)反查,用戶也可以提供主鍵(訂單md5)的單條查詢的頁面,億量級下查詢速度極快。單主鍵查詢方式不支持多維度檢索;
基于新SearchIndex功能Query:search接口。用戶可以自由設計索引字段的多維度條件組合查詢。通過設置選擇不同的查詢參數,構建不同的查詢條件、不同排序方式;目前支持:精確查詢、范圍查詢、前綴查詢、匹配查詢、通配符查詢、短語匹配查詢、分詞字符串查詢,并通過布爾與、或組合。
如【c0001號消費者,且消費在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);
這樣,系統的核心代碼已經完成,基于表格存儲搭建訂單系統,是不是很簡單?
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。