一,方案背景
订单系统存在于各行各业,如电商订的单,银行流水,运营商话费账单等,是一个非常广泛,通用的系统。对于这类系统,在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展,以及各企业对数据的重视,需要存储和持久化的订单量越来越大。数据的重视程度与数据规模的膨胀带来了新的挑战。
需求场景
某电商平台,需要进行持久化所有平台产生的订单数据,同时,基于所有的订单数据,系统又需要向外提供面向多种角色:消费者,店家,平台三类人群的多元化的查询服务。消费者可以查询自己的历史订单,商家可以统计热销产品,平台也可以分析用户行为,平台交易规模等。主要查询方式涵盖订单的多维度检索,以及订单数据的分析,统计等,例如:
面向消费者:【消费者】【近1年】* *【卖出电脑】订单查询;
面向售货员:【B售货员】*【近1个月】销售订单;
……
技术点
在订单场景中,技术上通常需要考虑的技术点,主要包含如下几个方面:
查询能力:需要具备丰富的查询类型,如多维度,范围,模糊查询等,同时具备排序,统计等功能;
李 <李>数据量:存储海量数据的同时,满足强一致,高可用,低成本等要求;
李 <李>服务性能:应对高并发请求高并发的同时,保证低延迟;
李
实现多维,实时查询功能,是订单管理解决方案的核心功能,官网控制台地址:
项目样例
二,方案演进
应对订单场景,电商通常会采用MySQL传统方案。借助关系型数据库强大的查询能力,用户可直接通过SQL语句实现订单数据的多维度查询,数据统计等。所谓数据膨胀,分为横向,纵向两种,横向即不断迭代引入的新字段维度,纵向即总的存储数据量。在面对这两种订单数据膨胀上,单MySQL方案逐渐变得吃力。
便应运而生,借助两个数据库各自的优势分别解决不同场景各自的需求,但
同样也带来了新的问题,组合方案牺牲空间成本,同时也增加了开发工作量与运维复杂度。在保证数据一致性上产生额外开销。
下面让我们看一下如下几个常规方案:
常规方案
1,MySql分库分表方案
MySql自身拥有强大的数据查询,分析功能,基于MyQql创建订单系统,可以应对订单数据多维查询,统计场景。伴随着订单数据量的增加,用户会采取分库,分表方案应对,通过这种伪分布式方案,解决数据膨胀带来的问题。但数据一旦达到瓶颈,便需要重新创建更大规模的分库+数据的全量迁移,麻烦就会不断出现。数据迭代,膨胀带来的困扰,是MySql方案难于逾越的。仅仅依靠MySql的传统订单方案短板凸显。
1、数据纵向(数据规模)膨胀:采用分库分表方案,MySql在部署时需要预估分库规模,数据量一旦达到上限后,重新部署并做数据全量迁移;
2、数据横向(字段维度)膨胀:模式需预定义,迭代新增新字段变更复杂,而维度到达一定量后影响数据库性能;
2,MySql + HBase方案
引入双数据的方案应运而生,通过实时数据,历史数据分存的方案,可以一定程度解决数据量膨胀问题。该方案将数据归类成两部分存储:实时数据,历史数据。同时通过数据同步服务,将过期数据同步至历史数据。
1、实时订单数据(例如:近3个月的订单):将实时订单存入MySql数据库。实时订单的总量膨胀的速度得到了限制,同时保证了实时数据的多维查询,分析能力;
2,历史订单数据(例如:3个月以前的订单):将历史订单数据存入HBase,借助于HBase这一分布式NoSql数据库,有效应对了订单数据膨胀困扰。也保证了历史订单数据的持久化;
但是,该方案牺牲了历史订单数据对用户,商家,平台的使用价值,假设了历史数据的需求频率极低。但是一旦有需求,便需要全表扫描,查询速度慢,IO成本很高。而维护数据同步又带来了数据一致性,同步运维成本飙升等难题;
