本文主要为您介绍针对订单系统的一些传统解决方案以及面对亿量级订单表格存储提供的更全面的解决方案。
传统方案
传统方案一：MySQL分库分表
MySQL自身拥有强大的数据查询和分析功能，基于MySQL创建订单系统，可以应对订单数据多维查询和统计场景。伴随着订单数据量的增加，采取分库分表方案应对，通过这种伪分布式方案解决数据膨胀带来的问题。但是如果数据达到瓶颈，则会出现明显的弊端。
数据纵向（数据规模）膨胀：采用分库分表方案，MySQL在部署时需要预估分库规模，当数据量达到上限后，需重新部署并做数据全量迁移。
数据横向（字段维度）膨胀：schema需预定义，迭代新增新字段变更复杂。而且当维度到达一定量后会影响数据库性能。
传统方案二：MySQL+HBase
基于MySQL分库分表方案的数据横向膨胀和纵向膨胀问题，双数据的方案应运而生，通过实时数据和历史数据分层存储的方案，可以一定程度解决数据量膨胀问题。该方案将数据分为实时数据和历史数据两类进行存储。
实时订单数据（例如近3个月的订单）：将实时订单存入MySQL数据库。实时订单的总量膨胀速度得到了限制，同时保证了实时数据的多维查询和分析能力。
历史订单数据（例如3个月以前的订单）：通过数据同步服务将历史订单数据存入HBase，借助于HBase这一分布式NoSQL数据库，有效应对了订单数据膨胀困扰。也保证了历史订单数据的持久化。
但是，该方案牺牲了历史订单数据对用户、商家、平台的使用价值，假设了历史数据的需求频率极低。然而如果有历史数据的需求，需要全表扫描，查询速度慢、I/O成本很高。而维护数据同步又带来了数据一致性、同步运维成本飙升等难题。
传统方案三：MySQL+Elasticsearch
此方案同样是将数据分两部分存储，可以一定程度解决订单索引维度增长问题。由用户自行维护数据同步服务，保证两部分数据的一致性。
全量数据：将全量的订单数据存入MySQL数据库，订单ID之外的数据整体存为一个字段。该全量数据作为持久化存储，也用于非索引字段的反查。
查询数据：只将需要检索的字段存入Elasticsearch（基于Lucene分布式索引数据库），借助于Elasticsearch的索引能力，提供可以应对维度膨胀的订单数据，然后必要时反查MySQL获取订单完整信息。
该方案解决了数据维度膨胀带来的困扰，但是随着订单量的不断增加，MySQL扩展性差的问题会凸显出来。同时数据同步到Elasticsearch的方案，开发、运维成本很高，方案选择也存在弊端。
表格存储方案
由以上对传统方案的分析可知，传统方案并不能完全应对亿量级订单场景。使用表格存储的多元索引（SearchIndex）方案，可以解决亿量级订单系统问题。表格存储具有即开即用，按量收费等特点。多元索引支持按需创建，是海量电商订单元数据管理的优质方案。
表格存储作为面向海量结构化数据提供的Serverless表存储服务，具有海量数据存储、热点数据自动分片、海量数据多维检索等功能，能有效解决订单数据大爆炸的挑战。同时，多元索引能够在保证用户数据高可用的基础上提供数据多维度搜索、统计等能力。针对多种场景创建多种索引，实现多种模式的检索。用户可以在需要时创建索引，由表格存储来保证数据同步的一致性，降低用户的方案设计、服务运维、代码开发等工作量。
下表为表格存储与传统订单方案使用的工具在各项性能上的对比。
能力分析 | MySQL | HBase | Elasticsearch | Tablestore |
存储方式 | 行存储 | 列存储 | 索引存储 | 列存储+索引存储 |
扩展性 | 单机、扩展性差 | 水平扩展 | 水平扩展 | （自动）水平扩展 |
一致性 | 强一致性 | 强一致性、时序一致性 | - | 强一致性、时序一致性 |
检索 | 较弱的支持 | 不支持 | 支持 | 支持 |
数据量 | ~1 TB、~亿行 | ~10 PB、~万亿行 | ~1 PB、~千亿行 | ~10 PB、~万亿行 |