基于Tablestore打造亿量级订单管理解决方案

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: 一、方案背景 订单系统存在于各行各业,如电商订单、银行流水、运营商话费账单等,是一个非常广泛、通用的系统。对于这类系统,在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展,以及各企业对数据的重视,需要存储和持久化的订单量越来越大。

一、方案背景

订单系统存在于各行各业,如电商订单、银行流水、运营商话费账单等,是一个非常广泛、通用的系统。对于这类系统,在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展,以及各企业对数据的重视,需要存储和持久化的订单量越来越大。数据的重视程度与数据规模的膨胀带来了新的挑战。

需求场景

某电商平台A,需要进行持久化所有平台产生的订单数据。同时,基于所有的订单数据,系统又需要向外提供面向多种角色:消费者、店家、平台三类人群的多元化的查询服务。消费者可以查询自己的历史订单,商家可以统计热销产品,平台也可以分析用户行为、平台交易规模等。主要查询方式涵盖订单的多维度检索,以及订单数据的分析、统计等,例如:
面向消费者:【A消费者】*【近1年】*【卖出电脑】订单查询;
面向售货员:【B售货员】*【近1个月】销售订单;
......

技术点

在订单场景中,技术上通常需要考虑的技术点,主要包含如下几个方面:

  • 查询能力:需要具备丰富的查询类型,如多维度、范围、模糊查询等,同时具备排序、统计等功能;
  • 数据量:存储海量数据的同时,满足强一致、高可用、低成本等要求;
  • 服务性能:应对高并发请求高并发的同时,保证低延迟;

实现多维、实时查询功能,是订单管理解决方案的核心功能,官网控制台地址:项目样例
testRecord

二、方案演进

应对订单场景,电商通常会采用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来保证数据同步的一致性,这极大的降低了用户的方案设计、服务运维、代码开发等工作量。

基于表格存储搭建的订单系统页面一览

样例内嵌在表格存储控制台中,用户可登录控制台体验系统(若为表格存储的新用户,需要点击开通服务后体验,开通免费,订单数据存储在公共实例中,体验不消耗用户存储、流量、Cu)。
注:该样例提供了【亿量级】订单数据。官网控制台地址:项目样例

image.png | left | 747x420

二、搭建准备

若您对于亿量级订单系统的体验不错,希望开始自己系统的搭建之旅,只需按照如下步骤便可以着手搭建了:

1、开通表格存储

通过控制台开通表格存储服务,表格存储即开即用(后付费),采用按量付费方式,已为用户提供足够功能测试的免费额度。表格存储官网控制台免费额度说明

2、创建实例

通过控制台创建表格存储实例,选择支持多元索引的Region。(当前阶段SearchIndex功能尚未商业化,暂时开放北京、上海、深圳、杭州四地,后续逐渐开放)

image.png | left | 747x240

创建实例后,提交工单申请多元索引功能邀测(现多元索引功能已商业化,无需申请)。

3、SDK下载

使用具有多元索引(SearchIndex)的SDK,官网地址,暂时java、go、node.js三种SDK增加了新功能

java-SDK

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

go-SDK

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

Nodejs-SDK

$ npm install tablestore@4.1.0

4、表设计

订单系统不仅仅是订单一张数据表,它应包含:消费者表、售货员表、产品表、供货商表、交易订单表、支付订单表等。在本样例中,主要使用最基本的四张表(消费者表、售货员表、产品表、交易订单表),仅以订单表举例如下:
表名:order_contract

列名 数据类型 索引类型 字段说明
_id(主键列) String MD5(oId)避免热点
oId(主键列) String KEYWORD 订单编号
pName String TEXT 产品名,TEXT类型索引可模糊查询,但不能排序
totalPrice double DOUBLE 订单总价
orderTime long LONG 下单时间(时间戳)
... ... ... ...

三、开始搭建(核心代码)

1、创建数据表

四张表:订单表、消费者表、售货员表、产品表
用户仅需维护一个实例,按如下方式创建:通过控制台创建、管理数据表(用户也可以通过SDK直接创建):

image.png | left | 747x307

2、创建数据表索引
TableStore自动做全量、增量的索引数据同步:用户可以通过控制台创建、管理SearchIndex(用户也可通过SDK创建):

image.png | left | 747x362

3、数据导入

插入部分测试数据(控制台样例中插入了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

4、数据读取

数据读取分为两类:

主键读取

基于原生表格存储的主键列获取: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);

四、欢迎加入

这样,系统的核心代码已经完成,基于表格存储搭建订单系统,是不是很简单?
对表格存储(TableStore)感兴趣的用户,欢迎加入【表格存储公开交流群】,群号:11789671。

image.png | left | 409x527

相关实践学习
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
目录
相关文章
|
存储 NoSQL 关系型数据库
基于TableStore的海量气象格点数据解决方案实战 王怀远
基于TableStore的海量气象格点数据解决方案实战 王怀远
301 0
基于TableStore的海量气象格点数据解决方案实战 王怀远
|
存储 SQL 运维
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
前言:从最早的互联网高速发展、到移动互联网的爆发式增长,再到今天的产业互联网、物联网的快速崛起,各种各样新应用、新系统产生了众多订单类型的需求,比如电商购物订单、银行流水、运营商话费账单、外卖订单、设备信息等,产生的数据种类和数据量越来越多;其中订单系统就是一个非常广泛、通用的系统。而随着数据规模的快速增长、大数据技术的发展、运营水平的不断提高,包括数据消费的能力要求越来越高,这对支撑订单系统的数据库设计、存储系统也提出了更多的要求。在新的需求下,传统的经典架构面临着诸多挑战,需要进一步思考架构优化,以更好支撑业务发展;
674 0
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
|
存储 运维 NoSQL
基于Tablestore的一站式物联网存储解决方案-场景篇
## 前言 随着5G时代的来临,万物互联概念的兴起,物联网渐渐覆盖到了各行各业中。本系列文章将为大家介绍基于表格存储Tablestore的一站式物联网存储解决方案。以共享充电宝场景为例,实现物联网场景下元数据、时序数据存储,高并发更新、分析计算等需求。 ## 背景 共享经济是近年来兴起的一种概念,共享概念极大方便了人们的生活。例如共享单车、共享车位、共享充电宝等等。这些场景里包含了大量的设备元
994 0
|
存储 运维 负载均衡
基于Tablestore的一站式物联网存储解决方案-表设计篇
## 前言 本章节主要讲解表格存储Tablestore的实例、表的创建步骤和共享充电宝场景的数据表设计。 ​ ## 表设计 ### 表功能设计 这里按照功能需求分为三张数据表:元数据表、订单数据表、元数据时序表 - 元数据表 元数据表保存了机柜的最新状态数据。用户租借、归还充电宝,以及运维人员上下线机柜,都会更新元数据表记录。在元数据表上建立索引,可提供多维查询的能力。对元数据表按照字段进行
717 0
|
SQL 存储 运维
基于Tablestore的一站式物联网存储解决方案-数据操作篇
## 前言 上一章节介绍了共享充电宝场景的表结构设计。本章节主要为大家介绍如何使用表格存储Tabelstore数据表实现基本数据读写、批量更新,以及利用多元索引特性实现多维度查询功能。 ## 准备工作 - 测试数据说明 | 数据表 | 数据表名 | 数据行数 | 说明 | | --- | --- | --- | --- | | 元数据表 | cabinet | 一千万行 | 模拟一千万台机柜 |
440 0
|
存储 SQL 分布式计算
基于Tablestore的一站式物联网存储解决方案-Spark 分析
## 前言 上一章节[《基于Tablestore的一站式物联网存储解决方案-数据操作篇》](https://ata.alibaba-inc.com/articles/213053) 为大家介绍了如何读写表格存储Tablestore中的数据。可以看到,无论是主键读写还是索引查询,都属于在线实时查询的场景。这些场景都要求某个查询或某个任务的服务响应时间极低(秒级别甚至毫秒级别)。然而,在共享充电宝场景
337 0
|
SQL 存储 运维
基于Tablestore的一站式物联网存储解决方案-数据湖分析
## 背景 在共享充电宝场景中,一些日常的运维操作可能会要求存储系统能够提供快速的OLAP解决方案。例如运维人员可能不具备开发环境,但会有一些简单查询或计算的需求。、表格存储Tablestore控制台提供了主键查询和多元索引查询两种方式。在已经创建了多元索引的表上,可以通过Tablestore控制台实现快速查询;在未建立多元索引的表上,则不能直接根据属性列进行查询、计算。所以,需要存储系统能够提供
278 0
|
存储 SQL 分布式计算
基于Tablestore的一站式物联网存储解决方案-Flink 实时计算
## 需求分析 在共享充电宝场景中,会有一些对实时性要求较高的计算场景。例如大屏展示每个省份、每个机柜的营收情况。这类场景不同于离线计算类的场景,需要实时地根据订单数据的变化来统计营业额,并不能采用前文中介绍的Spark近实时流批计算来实现。整个场景需求链路为根据订单增量变化,触发计算逻辑,计算结果写入Tablestore表中,提供给大屏展示。大致可以归纳成**增量写入-实时
539 0
基于Tablestore的一站式物联网存储解决方案-Flink 实时计算
|
存储 SQL NoSQL
基于DTS+Tablestore的海量订单系统架构设计
DTS支持MySQL同步Tablestore Beta版上线,合力打造完善的订单系统。 本文主要介绍一套基于DTS与Tablestore实现一套完善的订单系统架构。实时订单数据主要针对用户侧的实时生产与修改,实例订单数据则是基于数据同步服务DTS,全、增量订阅TP库中的订单数据,从而保证Tablestore中数据与TP库数据的最终一致性。异步同步的方式不可避免的存在延时,但历史订单库在实时性上要求会适当放宽,但其派生出来的数据在服务能力与功能扩展上得到了极大的提升,尤其是Tablestore这种分布式服务能力强、下游计算生态丰富的NoSQL存储服务。
14468 0
基于DTS+Tablestore的海量订单系统架构设计
|
存储 NoSQL JavaScript
Tablestore入门手册--表(Table)管理
表管理接口概述 API 描述 createTable 创建表 deleteTable 删除表 listTable 列出实例下的所有表 updateTable 更新表(在表被创建之后,动态的更改表的配置或预留吞吐量)
1833 0