本文主要为您介绍针对订单系统的一些传统解决方案，以及面对亿量级订单，表格存储提供的更全面的解决方案。
传统方案一：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的方案，开发、运维成本很高，方案选择也存在弊端。
表格存储解决方案
由上可以看出，传统的方案并不能完全应对亿量级订单场景。使用表格存储研发的多元索引（SearchIndex）方案，则可以解决亿量级订单系统问题。表格存储具有即开即用，按量收费等特点。多元索引随时创建，是海量电商订单元数据管理的优质方案。
表格存储作为面向海量结构化数据提供的Serverless表存储服务，具有海量数据存储、热点数据自动分片、海量数据多维检索等功能，能有效解决订单数据大爆炸的挑战。同时，多元索引功能在保证用户数据高可用的基础上提供了数据多维度搜索、统计等能力。针对多种场景创建多种索引，实现多种模式的检索。可以仅在需要时创建索引，由表格存储来保证数据同步的一致性，降低了用户的方案设计、服务运维、代码开发等工作量。
下图为表格存储与传统订单方案使用的工具在各项性能上的对比：
