共计 4871 个字符，预计需要花费 13 分钟才能阅读完成。
简介：本文简要介绍了基于 MySQL 联合 Tablestore 的大规模订单零碎计划。这种计划反对大数据存储、高性能数据检索、SQL 搜寻、实时与全量数据分析，且部署简略、运维成本低。
作者 | 弘楠
起源 | 阿里技术公众号
一 背景
订单零碎存在于各行各业，如电商订单、银行流水、运营商话费账单等，是一个十分宽泛、通用的零碎。对于这类零碎，在过来十几年倒退中曾经造成了经典的做法。然而随着互联网的倒退，以及各企业对数据的器重，须要存储和长久化的订单量越来越大，数据的器重水平与数据规模的收缩带来了新的挑战。首先，订单量对于数据的存储、长久化、拜访带来了挑战，这不仅减少了开发面对的艰难，也为零碎的运维带来了挑战。其次，随着大数据技术的倒退以及经营程度的一直进步，订单数据的后续数据分析工作，如流批处理、ETL，也越来越重要，这也对数据的存储系统提出了更高的要求。
本文提出了一种基于 MySQL + Tablestore 的大规模订单零碎设计方案。这种计划基于分层存储的思维，应用 Tablestore 辅助 MySQL 共同完成订单零碎反对。在零碎中，利用 MySQL 的事务能力来解决对事务强需要的写操作与局部读操作；利用 Tablestore 的检索能力、大数据存储能力等补救 MySQL 在性能上的短板。具体可见文章：云上利用零碎数据存储架构演进。
本文作为 MySQL + Tablestore 分层存储架构的大规模订单零碎的架构篇。
首先具体论述，在大规模订单零碎中，存在哪些需要，存在哪些痛点。
进而比拟传统的架构，其现状如何，各存在什么样的劣势，无奈满足哪些需要。
而后讲述 MySQL + Tablestore 架构，论述这种架构是如何满足大规模订单零碎的需要的。
二 需要场景
订单零碎，面向 C 端，除了在零碎性能要求高外，对于数据的存储、后续数据的计算、数据实时处理、数据批处理都有肯定的要求。而对于 C 端客户、产品经营、零碎运维等不同的角色，他们对系统的需要也有所不同。
1 C 端需要
对于 C 端客户以及面向 C 端的开发而言，零碎首先须要反对高并发、高稳定性。其次，零碎须要可能反对基于用户 id 的搜寻以及搜寻用户 id 下蕴含特定关键词的记录。具体的需要有：
- 基于用户 id 查找用户近一月的订单。
- 基于订单号查问订单详情。
- 搜寻用户购买过的蕴含某关键字的商品。
这对于零碎的索引能力以及搜寻能力有较高的要求。
2 经营需要
经营同学须要可能在不影响线上的状况下应用 SQL 对实时数据进行剖析，可能依据非主键字段进行检索；他们还须要零碎对流批计算的反对，须要流式数据处理来进行实时数据统计，须要批处理来进行历史数据统计。经营同学常见的需要场景有：
- 统计在某旗舰店生产过的用户有哪些。
- 统计生产过某一件产品的客户有哪些并且他们还购买了什么产品，进而向客户举荐商品。
- 实时统计双十一开始后的实时成交额，用于宣传时的实时数据展现。
- 统计某店铺过来 10 年的成交额。
- 依赖订单数据对客户做实时更新的画像剖析，以反对商品的举荐。
3 运维需要
运维同学更关注零碎的稳定性、复杂度并期待低运维老本。而基于 MySQL + Tablestore 的订单零碎能够将运维同学从繁琐的运维工作中解放出来，大大降低运维老本。它可能做到：
零碎高可用，并发能力强。
零碎复杂度低，不须要保护多个集群，也不须要关注各集群间的数据同步过程，运维工作简略易上手。
三 传统订单零碎
1 订单零碎架构演进
最简略的订单零碎就是单点的 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 再加工提供反对。
2 传统订单架构总结
总之，MySQL 分库分表计划无奈解决数据收缩带来的扩容问题。基于 MySQL + HBase 的架构在数据检索下面存在显著短板。而 MySQL + HBase + Elasticsearch 的计划，尽管可能解决扩容和数据检索问题，但其零碎简单，保护老本高；另外，这种计划无奈对数据分析工作、数据再加工 ETL 工作提供无效反对。而 MySQL + Tablestore 不仅解决了扩容问题、检索问题，还反对数据流批处理以及 ETL 再加工工作，且零碎复杂度低，运维成本低，可能满足大规模订单零碎的各项需要。
四 MySQL + Tablestore 计划
表格存储（Tablestore）是阿里云自研的多模型结构化数据存储，提供海量结构化数据存储以及疾速的查问和剖析服务。
MySQL + Tablestore 后，能够很好的满足大规模订单场景下遇到的各种需要。其整体架构图如图。
MySQL 解决订单的写入和近期数据的根本读取，并且利用数据同步工具如 DTS 将数据实时同步给 Tablestore。在 Tablestore 中，利用其二级索引和多元索引，能够解决检索需要。通过 DLA，能够实现应用 SQL 间接查问 Tablestore。Tablestore 的通道服务能够对接 Spark streaming 以及 Flink，能够实现实时数据分析。将 Tablestore 和 ODPS 对接，能够很便捷的实现对订单数据的 ETL 作业。而联合 OSS 和 Tablestore，能够实现订单数据的归档，并且能够在 OSS 中实现全量历史数据的剖析工作。
1 数据同步
传统的订单架构中，开发者不可避免须要解决数据同步进入 HBase 或者 Elasticsearch 之类的工作。这不仅减轻了开发者的开发工作，也进步了运维难度。在 Tablestore 中，阿里云提供 DataX、Data Transmission Service（DTS）、Canal 多种数据同步工具实现数据从 MySQL 到 Tablestore 的同步工作。用户只须要进行大量的开发和配置工作就能够实现数据实时同步。操作不便简略，实时性高，大大降低了保护老本。
2 数据检索
Tablestore 提供了二级索引和多元索引来反对数据的检索。二级索引能够实现基于主键列和预约义列的数据查问，例如查问用户过来一个月成交的订单状况。而多元索引，基于倒排索引和列式存储，对外提供了更加弱小的数据检索性能，他解决大数据的简单查问难题。它能够实现如搜寻购买过某产品的用户这样的需要。
Tablestore 的多元索引补齐了 MySQL、HBase 等在搜寻下面的短板。而绝对于 Elasticsearch，多元索引不再须要使用者专门保护集群、保护数据同步工作，老本更低。
3 基于 SQL 的数据分析
Tablestore 以多种形式反对 SQL 对 Tablestore 中数据的读写。若想间接读取 Tablestore 中的数据，倡议间接应用 Tablestore 的 SQL 反对能力进行操作；而若心愿进行多数据存储的联邦查问，举荐应用 DLA 所反对的 SQL。对于两种模式的 SQL，Tablestore 都利用多元索引对其进行了充沛的优化。领有 SQL 解决能力，开发者能够更加高效率的进行代码开发、代码迁徙工作。间接应用 SQL 查问 Tablestore 也会为 MySQL 主库卸载流量。
4 实时数据分析
Tablestore 的通道服务，能够将 Tablestore 库中数据的变动传入通道。应用 Spark streaming 或者 Flink 等流式数据处理工具对接通道，能够实现例如统计实时成交额这一类的实时数据分析需要。
5 历史数据分析
Tablestore 能够将数据投递到 OSS 零碎，这样能够实现订单的归档需要，并且利用 OSS 零碎对接 Spark，能够实现对全量历史数据的剖析工作。这样，在 Tablestore 中存储近期数据，在 OSS 中存储全量历史数据，以 OSS 来反对波及全量历史数据的剖析工作。
6 ETL 数据再加工
通过将 Tablestore 数据接入 ODPS，能够利用 ODPS 弱小的数据处理能力，更便捷的对数据做 ETL 作业，进行数据的再次加工。
五 总结
本文简要介绍了基于 MySQL 联合 Tablestore 的大规模订单零碎计划。这种计划反对大数据存储、高性能数据检索、SQL 搜寻、实时与全量数据分析，且部署简略、运维成本低。
原文链接
本文为阿里云原创内容，未经容许不得转载。
