基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践

背景

订单系统存在于各行各业，如电商订单、银行流水、运营商话费账单等，是一个非常广泛、通用的系统。对于这类系统，在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展，以及各企业对数据的重视，需要存储和持久化的订单量越来越大，数据的重视程度与数据规模的膨胀带来了新的挑战。首先，订单量对于数据的存储、持久化、访问带来了挑战，这不仅增加了开发面对的困难，也为系统的运维带来了挑战。其次，随着大数据技术的发展以及运营水平的不断提高，订单数据的后续数据分析工作，如流批处理、ETL，也越来越重要，这也对数据的存储系统提出了更高的要求。

本文提出了一种基于MySQL+Tablestore的大规模订单系统设计方案。这种方案基于分层存储的思想，使用Tablestore辅助MySQL共同完成订单系统支持。在系统中，利用MySQL的事务能力来处理对事务强需求的写操作与部分读操作；利用Tablestore的检索能力、大数据存储能力等弥补MySQL在功能上的短板。详细可见文章：云上应用系统数据架构实践。

本文作为MySQL+Tablestore分层存储架构的大规模订单系统的架构篇，

需求场景

订单系统，面向C端，除了在系统性能要求高外，对于数据的存储、后续数据的计算、数据实时处理、数据批处理都有一定的要求。而对于C端客户、产品运营、系统运维等不同的角色，他们对系统的需求也有所不同。

C端需求

对于C端客户以及面向C端的开发而言，系统首先需要支持高并发、高稳定性。其次，系统需要能够支持基于用户id的搜索以及搜索用户id下包含特定关键词的记录。具体的需求有：

这对于系统的索引能力以及搜索能力有较高的要求。

运营需求

运营同学需要能够在不影响线上的情况下使用SQL对实时数据进行分析，能够根据非主键字段进行检索；他们还需要系统对流批计算的支持，需要流式数据处理来进行实时数据统计，需要批处理来进行历史数据统计。运营同学常见的需求场景有：

运维需求

运维同学更关注系统的稳定性、复杂度并期待低运维成本。而基于MySQL+Tablestore的订单系统可以将运维同学从繁琐的运维工作中解放出来，大大降低运维成本。它能够做到：

传统订单系统订单系统架构演进

最简单的订单系统就是单点的MySQL架构，但随着订单规模的增长，用户采用分库分表的MySQL替代单点MySQL方案。但这种方案下，当数据量达到当前MySQL集群瓶颈，集群扩容仍然会相当具有难度，需要更大的集群以及大量数据的迁移工作。数据迭代、膨胀带来的困扰，是分库分表MySQL方案难于逾越的。

NoSQL被引入，MySQL+HBase的方案应运而生。这种方案将实时数据和历史数据分层存储，MySQL中只存储实时数据，历史数据归档进入HBase存储。这种方案解决了数据扩容带来的存储和运维难题，但它的缺点在于，存储于HBase的数据很难被合理利用，并且方案整体也不支持检索功能。

因此，架构中引入了Elasticsearch，形成了MySQL+HBase+Elasticsearch的方案。这种方案利用了Elasticsearch提供的数据检索能力，解决了订单数据的搜索问题。但在这种架构下，用户要维护HBase、Elasticsearch两个集群，还需要关注向HBase、Elasticsearch同步数据的任务，维护成本很高。并且这种架构仍无法支持流批处理、ETL等数据分析、加工工作。

MySQL分库分表方案

MySQL自身拥有强大的数据查询、分析功能，基于MySQL创建订单系统，可以应对订单数据多维查询、统计场景。伴随着订单数据量的增加，用户会采取分库、分表方案应对，通过这种伪分布式方案，解决数据膨胀带来的问题。但数据一旦达到瓶颈，便需要重新创建更大规模的分库+数据的全量迁移，麻烦就会不断出现。数据迭代、膨胀带来的困扰，是MySQL方案难于逾越的。仅仅依靠MySQL的传统订单方案短板凸显。1、数据纵向（数据规模）膨胀：采用分库分表方案，MySQL在部署时需要预估分库规模，数据量一旦达到上限后，重新部署并做数据全量迁移；2、数据横向（字段维度）膨胀：schema需预定义，迭代新增新字段变更复杂。而维度到达一定量后影响数据库性能；

数据膨胀还会提高系统运维难度和成本。且MySQL集群一般采用双倍策略扩容，在重储存低计算的订单场景下，CPU的浪费情况也会比较严重。

MySQL+HBase方案

引入双数据的方案应运而生，通过实时数据、历史数据分存的方案，可以一定程度解决数据量膨胀问题。该方案将数据归类成两部分存储：实时数据、历史数据。同时通过数据同步服务，将过期数据同步至历史数据。1、实时订单数据（例如：近3个月的订单）：将实时订单存入MySQL数据库。实时订单的总量膨胀的速度得到了限制，同时保证了实时数据的多维查询、分析能力；2、历史订单数据（例如：3个月以前的订单）：将历史订单数据存入HBase，借助于HBase这一分布式NoSQL数据库，有效应对了订单数据膨胀困扰。也保证了历史订单数据的持久化；但是，该方案牺牲了历史订单数据对用户、商家、平台的使用价值，假设了历史数据的需求频率极低。但是一旦有需求，便需要全表扫描，查询速度慢、IO成本很高。而维护数据同步又带来了数据一致性、同步运维成本飙升等难题；

MySQL+HBase+Elasticsearch方案

MySQL+HBase+Elasticsearch方案通过引入Elasticsearch集群，解决了其他方案无法应对的数据检索问题。

1、实时订单数据（例如：近3个月的订单）：将实时订单存入MySQL数据库。实时订单的总量膨胀的速度得到了限制，同时保证了实时数据的多维查询、分析能力；2、历史订单数据（例如：3个月以前的订单）：将历史订单数据存入HBase，借助于HBase这一分布式NoSQL数据库，有效应对了订单数据膨胀困扰。也保证了历史订单数据的持久化；

3、数据检索：数据同步任务将需要检索的字段从HBase同步至Elasticsearch，借助于Elasticsearch的索引能力，为系统提供数据检索能力。然后必要时反查MySQL获取订单完整信息；

该方案虽然解决了数据膨胀带来的扩容问题，也能够支持数据检索。但可以看到的是，客户要维护至少两套集群，关注两处数据同步任务，该方案的系统复杂度很高，运维成本也会很高。此外，这个方案依然不能对数据的流批处理、数据ETL再加工提供支持。

传统订单架构总结

总之，MySQL分库分表方案无法解决数据膨胀带来的扩容问题。基于MySQL+HBase的架构在数据检索上面存在明显短板。而MySQL+HBase+Elasticsearch的方案，虽然能够解决扩容和数据检索问题，但其系统复杂，维护成本高；另外，这种方案无法对数据分析工作、数据再加工ETL工作提供有效支持。而MySQL+Tablestore不仅解决了扩容问题、检索问题，还支持数据流批处理以及ETL再加工工作，且系统复杂度低，运维成本低，能够满足大规模订单系统的各项需求。

MySQL+Tablestore方案

表格存储（Tablestore）是阿里云自研的多模型结构化数据存储大数据存储架构，提供海量结构化数据存储以及快速的查询和分析服务。详情见什么是表格存储。

MySQL+Tablestore后，可以很好的满足大规模订单场景下遇到的各种需求。其整体架构图如图。

MySQL处理订单的写入和近期数据的基本读取，并且利用数据同步工具如DTS将数据实时同步给Tablestore。在Tablestore中，利用其二级索引和多元索引，可以处理检索需求。通过DLA，可以实现使用SQL直接查询Tablestore。Tablestore的通道服务可以对接Sparkstreaming以及Flink，可以实现实时数据分析。将Tablestore和ODPS对接，可以很便捷的实现对订单数据的ETL作业。而结合OSS和Tablestore，可以实现订单数据的归档，并且可以在OSS中实现全量历史数据的分析工作。

数据同步

传统的订单架构中，开发者不可避免需要处理数据同步进入HBase或者Elasticsearch之类的工作。这不仅加重了开发者的开发工作，也提高了运维难度。在Tablestore中，阿里云提供DataX、DataTransmissionService（DTS）、Canal多种数据同步工具完成数据从MySQL到Tablestore的同步工作。用户只需要进行少量的开发和配置工作就可以完成数据实时同步。操作方便简单，实时性高，大大降低了维护成本。详情请参见文章：

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-数据同步DTS篇

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-数据同步Canal篇

数据检索

Tablestore提供了二级索引和多元索引来支持数据的检索。二级索引可以完成基于主键列和预定义列的数据查询，例如查询用户过去一个月成交的订单情况。而多元索引，基于倒排索引和列式存储，对外提供了更加强大的数据检索功能，他解决大数据的复杂查询难题。它可以实现如搜索购买过某产品的用户这样的需求。

Tablestore的多元索引补齐了MySQL、HBase等在搜索上面的短板。而相对于Elasticsearch，多元索引不再需要使用者专门维护集群、维护数据同步任务，成本更低。详情请参见文章：

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-订单搜索篇

基于SQL的数据分析

Tablestore以多种方式支持SQL对Tablestore中数据的读写。若想直接读取Tablestore中的数据，建议直接使用Tablestore的SQL支持能力进行操作；而若希望进行多数据存储的联邦查询，推荐使用DLA所支持的SQL。对于两种形式的SQL，Tablestore都利用多元索引对其进行了充分的优化。拥有SQL处理能力，开发者可以更加高效率的进行代码开发、代码迁移工作。直接使用SQL查询Tablestore也会为MySQL主库卸载流量。详情请参见文章：

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-SQL查询和分析

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-基于DLA的联邦查询

实时数据分析

Tablestore的通道服务，可以将Tablestore库中数据的变化传入通道。使用Sparkstreaming或者Flink等流式数据处理工具对接通道，可以实现例如统计实时成交额这一类的实时数据分析需求。详情请参见文章：

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-数据流计算篇

历史数据分析

Tablestore可以将数据投递到OSS系统，这样可以完成订单的归档需求，并且利用OSS系统对接Spark，可以完成对全量历史数据的分析工作。这样，在Tablestore中存储近期数据，在OSS中存储全量历史数据，以OSS来支持涉及全量历史数据的分析工作。详情请参见文章：

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-历史数据分析篇

ETL数据再加工

通过将Tablestore数据接入ODPS，可以利用ODPS强大的数据处理能力，更便捷的对数据做ETL作业，进行数据的再次加工。详情请参见文章：

基于MySQL+Tablestore分层存储架构的大规模订单系统实践-数据处理ETL篇

总结

本文简要介绍了基于MySQL结合Tablestore的大规模订单系统方案。这种方案支持大数据存储、高性能数据检索、SQL搜索、实时与全量数据分析，且部署简单、运维成本低。

希望本次分享对你设计数据架构有帮助，如果希望继续交流，可以加入我们的开发者技术交流群，可搜索群号『11789671』或『23307953』，亦可直接扫码加入。

（编辑：广州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!