本章节主要为您介绍针对订单系统的一些传统解决方案,以及面对亿量级订单,表格存储(Table Store)提供的更全面的解决方案。



传统方案一:MySQL分库分表

MySQL自身拥有强大的数据查询、分析功能,基于MySQL创建订单系统,可以应对订单数据多维查询、统计场景。伴随着订单数据量的增加,采取分库、分表方案应对,通过这种伪分布式方案解决数据膨胀带来的问题。但数据一旦达到瓶颈,便出现明显的弊端:
  • 数据纵向(数据规模)膨胀:采用分库分表方案,MySQL在部署时需要预估分库规模,数据量一旦达到上限后,重新部署并做数据全量迁移。
  • 数据横向(字段维度)膨胀:schema需预定义,迭代新增新字段变更复杂。而维度到达一定量后影响数据库性能。

传统方案二: MySQL+HBase

引入双数据的方案应运而生,通过实时数据、历史数据分存的方案,可以一定程度解决数据量膨胀问题。该方案将数据归类成两部分存储:实时数据、历史数据。

  • 实时订单数据(例如:近3个月的订单):将实时订单存入MySQL数据库。实时订单的总量膨胀的速度得到了限制,同时保证了实时数据的多维查询、分析能力。
  • 历史订单数据(例如:3个月以前的订单):通过数据同步服务,将历史订单数据存入HBase,借助于HBase这一分布式NoSQL数据库,有效应对了订单数据膨胀困扰。也保证了历史订单数据的持久化。

但是,该方案牺牲了历史订单数据对用户、商家、平台的使用价值,假设了历史数据的需求频率极低。但是一旦有需求,便需要全表扫描,查询速度慢、I/O成本很高。而维护数据同步又带来了数据一致性、同步运维成本飙升等难题。

传统方案三:MySQL+Elasticsearch

此方案同样是将数据分两部分存储,可以一定程度解决订单索引维度增长问题。用户自己维护数据同步服务,保证两部分数据的一致性。

  • 全量数据:将全量的订单数据存入MySQL数据库,订单ID之外的数据整体存为一个字段。该全量数据作为持久化存储,也用于非索引字段的反查。
  • 查询数据:仅将需要检索的字段存入Elasticsearch(基于Lucene分布式索引数据库),借助于Elasticsearch的索引能力,提供可以应付维度膨胀的订单数据,然后必要时反查MySQL获取订单完整信息。

该方案应付了数据维度膨胀带来的困扰,但是随着订单量的不断膨胀,MySQL扩展性差的问题再次暴露出来。同时数据同步至Elasticsearch的方案,开发、运维成本很高,方案选择也存在弊端。

表格存储解决方案

由上可以看出,传统的方案并不能完全应对亿量级订单场景。使用Table Store研发的多元索引(SearchIndex)方案,则可以完美地解决亿量级订单系统问题。Table Store具有即开即用,按量收费等特点。多元索引随时创建,是海量电商订单元数据管理的优质方案。

Table Store作为阿里云提供的一款全托管、分布式NoSQL型数据存储服务,具有海量数据存储、热点数据自动分片、海量数据多维检索等功能,天然地解决了订单数据大爆炸这一挑战。同时,多元索引功能在保证用户数据高可用的基础上,提供了数据多维度搜索、统计等能力。针对多种场景创建多种索引,实现多种模式的检索。可以仅在需要的时候创建、开通索引。由Table Store来保证数据同步的一致性,这极大的降低了用户的方案设计、服务运维、代码开发等工作量。

下图为Table Store与传统订单方案使用的工具在各项性能上的对比:

方案实现

参见准备工作以及搭建订单系统

方案样例

基于表格存储搭建的订单系统样例内嵌在表格存储控制台中,用户可登录控制台体验系统。该样例提供了亿量级订单数据。官网控制台地址:项目样例

说明 若为表格存储的新用户,需要点击开通服务后体验,开通免费,订单数据存储在公共实例中,体验不消耗用户存储、流量、读写吞吐。