基于TableStore的亿级订单管理解决方案

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

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

需求场景
某电商平台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
<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、表设计
订单系统不仅仅是订单一张数据表,它应包含:消费者表、售货员表、产品表、供货商表、交易订单表、支付订单表等。在本样例中,猪腰使用最基本的四张表(消费者表、售货员表、产品表、交易订单表),仅以订单表举例如下:
表名:order_contract


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

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

3、数据导入
插入部分测试数据(控制台样例中插入了1亿条数据,用户自己可以通过控制台插入少量测试数据);



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);

原文地址:http://blog.51cto.com/14031893/2308899

时间: 2024-07-29 00:13:35

基于TableStore的亿级订单管理解决方案的相关文章

从无到有构建10亿级订单系统(真实工业界案例)

课程下载地址:https://pan.baidu.com/s/1PdRPFg7BM0AV8VBFoooWbA 提取码:a7ll 随着公司业务增长,如果每天1000多万笔订单的话,3个月将有约10亿的订单量,这么大的数据量,我们该怎么存储和查询呢?普通的单表单库已经无法解决这个问题. 本课程将从无到有构建10亿级订单系统,彻底解决这么大的订单数据存储.查询.计算等问题,该课程将采用循序渐进方式一步一步带大家实现该系统,中间将穿插一些技术知识点讲解,让大家实现系统的同时,更深入理解其中的技术点. 该

基于分布式关系型数据库,实现轻松应对百亿级数据分析场景解决方案

MyCat是什么? 从定义和分类来看,它是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库读写分离,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里.也可以指定多个写库多个读库. MyCat发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端

SSM贸易公司订单管理平台

每天记录学习,每天会有好心情.*^_^* 今天记录的项目是基于SSM的贸易公司订单管理平台,基于SSM的贸易公司订单管理平台项目是这么回事:本文设计并实现了一个可扩展的企业订单管理系统物流企业订单管理系统.该系统涉及了物品流通过程中的下订单管理.订单发货管理.订单进度查询及订单异常处理等功能,它将物流过程中各个环节中的信息.数据等情况进行智能化的采集,通过现代的信息技术进行分析和处理,对物流体系进行合理的协调,从而实现物流管理的高效率和高质量,以达到降低物流成本和管理成本的目的.采用当前非常流行

基于TableStore的海量电商订单元数据管理

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

10分钟搞懂:亿级用户的分布式数据存储解决方案!

分布式数据库和分布式存储是分布式系统中难度最大.挑战最大,也是最容易出问题的地方.互联网公司只有解决分布式数据存储的问题,才能支撑更多次亿级用户的涌入. 接下来,你将花费十分钟掌握以下三方面内容:1.MySQL复制:包括主从复制和主主复制:2.数据分片:数据分片的原理.分片的方案.分片数据库的扩容:3.数据库分布式部署的几种方案. 一.MySQL复制 1.MySQL的主从复制MySQL的主从复制,就是将MySQL主数据库中的数据复制到从数据库中去. 主要目的是实现数据库读写分离,写操作访问主数据

百亿级数据10万字段属性的秒级检索解决方案以及实现

课程下载地址: https://pan.baidu.com/s/1zr5riwZtdRgnVQRetQnG7A 提取码: 5xg8 平台型创业型公司,会有多个品类,像生活信息服务类网站的有:58同城,赶集网等等,他们的类别非常多,每个垂直领域都会分为很多类别,每 个类别下又分很多子类别,每个类别或者子类别的属性都不一样,像这么庞大的数据,字段属性可以达到10万级别,同时数据量可以达到百亿级别 ,很多异构数据的存储需求.基于这么庞大的数据,我们需要达到秒级查询. 那么我们该怎么设计呢?本课程讲手把

亿级商品详情页架构演进技术解密 | 高可用架构系列

亿级商品详情页架构演进技术解密 | 高可用架构系列 --http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=210272034&idx=1&sn=3be9d2b53c7fec88716ee8affd2515f8&scene=1&srcid=UfXZNNOVZZyZjQmp0VOh&from=groupmessage&isappinstalled=0#rd 此文是开涛在[三体高可用架构群]之分享内容

转:亿级Web系统的高容错性实践(好博文)

亿级Web系统的高容错性实践 亿级Web系统的高容错性实践 背景介绍 大概三年前,我在腾讯负责的活动运营系统,因为业务流量规模的数倍增长,系统出现了各种各样的异常,当时,作为开发的我,7*24小时地没日没夜处理告警,周末和凌晨也经常上线,疲于奔命.后来,当时的老领导对我说:你不能总扮演一个“救火队长”的角色, 要尝试从系统整体层面思考产生问题的根本原因,然后推进解决. 我幡然醒悟,“火”是永远救不完的,让系统能够自动”灭火”,才是解决问题的正确方向.简而言之,系统的异常不能总是依赖于“人”去恢复

亿级 Web 系统的容错性建设实践

三年多前,我在腾讯负责的活动运营系统,因为业务流量规模的数倍增长,系统出现了各种各样的异常,当时,作为开发的我,7*24小时地没日没夜处理告警,周末和凌晨也经常上线,疲于奔命.后来,当时的老领导对我说:你不能总扮演一个“救火队长”的角色, 要尝试从系统整体层面思考产生问题的根本原因,然后推进解决. 我幡然醒悟,“火”是永远救不完的,让系统能够自动”灭火”,才是解决问题的正确方向.简而言之,系统的异常不能总是依赖于“人”去恢复,让系统本身具备“容错”能力,才是根本解决之道.三年多过去了,我仍然负责