关于运维:基于-MySQL-Tablestore-分层存储架构的大规模订单系统实践架构篇

简介: 本文简要介绍了基于 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搜寻、实时与全量数据分析,且部署简略、运维成本低。

原文链接
本文为阿里云原创内容,未经容许不得转载。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据