亿级海量数据的实时读写和复杂查询实践

  • 时间:
  • 浏览:1

摘要:本文分享了每日亿级增量数据的实时读写、复杂查询场景实践介绍,涉及 MySQL 分表分库策略、数据异构、TiDB 使用和优化、微服务架构等内容。

  作者:黄哲铿

  黄哲铿,中通商业CTO,前1号店技术总监、海尔农业电商 CTO,2015年出版专著《技术管理之巅》,“技术领导力社区”发起人,擅长大型电商系统研发、供应链系统研发、大型技术团队治理,另一方拥有多项技术发明和专利。

本文根据黄哲铿老师在DTCC数据库大会分享内容埋点而成,将进行每日亿级增量数据的实时读写、复杂查询场景实践介绍,涉及 MySQL 分表分库策略、数据异构、TiDB 使用和优化、微服务架构等等。

首先做下自我介绍,我叫黄哲铿,时候在互联网的许多企业,像1号店、1药网,担任技术开发以及技术管理等职位。同去,我在2015年的时候出版过一本技术治理方面的书《技术管理之巅》。

  本次分享将由以下十几个 每段组成:

  多租户SAAS系统场景简介

  系统面临的挑战

  亿级数据实时读写的系统架构

  匮乏及展望

一、多租户SAAS系统场景简介

首先介绍一下多租户SaaS系统的应用场景,案例中的系统是给全网的商家、快递的门店做结算系统。结算每天的派费、收入以及许多费用等等。那你相似 系统的使用量共也不十几个 ?全国范围内有共要两到三万的网点,同去在线的人数共要有五万人左右,每天的结算数据时单表的行数增量共要会达到亿级别的增量(假设不分表分库)。

同去,应用中会有实时读写,絮状的复杂的SQL分页查询。在座太多太多做金融系统或来自银行的亲戚亲戚大伙儿们应该很清楚,结算系统可能性说金融系统对数据的实时性、一致性的要求非常高。用户的使用习惯是把明细数据导出来,比如说每天可能性有几十万甚至百万的数据要去用Excel导出来,这后边真是会有太多太多工程方面的优化,以及SQL方面的许多优化。

二、系统面临的挑战

接下来是亲戚亲戚大伙儿儿面临的许多挑战,亲戚亲戚大伙儿儿有做结算系统或财务方面的亲戚亲戚大伙儿应该知道,用户对另一方账户里的钱是非常敏感的,比如有太多太多人排队去把OFO账户中的钱兑现,真是没十几个 钱,但亲戚亲戚大伙儿儿真是你相似 是我的钱,我能随时、马上就看,拿到。在结算系统中也一样的道理,你相似 数据我改了马上就还都都能能在系统后边得到反映。一般的小系统很好实现,或者可能性每天有上亿增量数据的系统,这真是是个比较大的挑战。

刚才亲戚亲戚大伙儿儿提到应用场景所面临的许多挑战和对系统的挑战,包括亿级增量的结算和数据的存储,单表肯定是放不下的,自然而然会想到去分表、分库。那按照十几个 样的逻辑去分?这又是三个白疑问,亲戚亲戚大伙儿儿接下来会讲。

应用场景刚才也介绍过了,结算系统对一致性、实时性、可用性一定会 非常高的要求,亲戚亲戚大伙儿儿的应用部署的规模共要有几百个应用实例,部署在系统上。那几百个实例对数据库一种太多太多我三个白很大的压力。假设说有两百个应用,每个应用有三三个白数据库的链接,那太多太多我有六千个链接,对吗?太多太多,这对整个系统的压力、架构办法一定会 非常大的挑战,以及亲戚亲戚大伙儿儿的结算系统要求你相似 高可用,99.9%、99.99%相似的要求。

亲戚亲戚大伙儿儿的数据主要来源于消费,消费的数据时要做实时的除理,真是他是跑批的,用分布式job来跑。或者在跑批的过程中,单个业务逻辑的除理的业务复杂度真是是非常高的。单个业务逻辑算三根账单、三根费用时,可能性会涉及到十几、二三个白逻辑规则。那十几个 数据是实时去抽,做许多预除理,倒进缓存后边,或者在数据量大的时候,缓存可能性又不一定是非常好的三个白除理方案。这太多太多我亲戚亲戚大伙儿儿遇到的许多疑问。

真是亲戚亲戚大伙儿儿时要想就看,以电商系统为例,电商系统真是太多太多我在下订单的环节才有曾经 的三个白应用场景。在下订单的时候要扣积分,扣库存等等,那个时候时要用实时数据去计算,对系统我压力比较大。

曾经 们的结算场景的复杂度共要十几个 ?共要有五万多个用户同去在下单。国内可能性也这么几家电商公司还都都能能达到曾经 的数量。这么你相似 系统它的难度,它的挑战在十几个 地方呢?

三、亿级数据实时读写的系统架构

太多太多接下来介绍的是亲戚亲戚大伙儿儿怎么都能能架构三个白曾经 的系统去应对刚才亲戚亲戚大伙儿儿所面临的十几个 挑战。

1、云原生微服务架构

首先亲戚亲戚大伙儿儿采用的是云原生的微服务架构,微服务架构的好处真是亲戚亲戚大伙儿儿应该都很清楚。太多太多我它的解耦性、横向可扩、团队之间的独立性以及沉淀的业务逻辑等等。

真是微服务也带来了许多疑问,最明显的三个白疑问是十几个 ?曾经 三个白团队开发三个白中台,曾经 现在按照业务线去拆,比如说你是用户组,右边的这张图太多太多我用户下单的场景,从左到右注册、下订单、结算等等。那竖着来看,按照业务逻辑来垂直去拆分它的微服务,从应用到数据存储三根线打通。那它带来的疑问太多太多我团队战略公司合作 的疑问、团队之间的守护多多线程 联调的疑问以及服务治理和服务依赖的疑问。太多太多为十几个 从时候的SOA发展到微服务,再发展到现在所谓的云原生微服务,要用容器化的办法以及DevOps的十几个 工具,来使微服务的开发还都都能能快速地、独立地运行下去。

我另一方认为小的应用及小团队碰必须微服务的许多架构,可能性根本用不上。十几另一方的团队可能性是几十另一方的团队,你的架构假使 除理:加机器就还都都能能实现横向可扩,还都都能能支撑你的业务量,比如一天几十万单的规模,太多太多太多轻易去尝试曾经 的许多架构。你相似 系统真是也是一样的,亲戚亲戚大伙儿儿一开始英文英文在设计的时候它并一定会 现在的架构。刚开始英文英文它太多太多我单体应用,或者通过你相似 几千人、上万人用的时候,亲戚亲戚大伙儿儿开始英文英文思考,接下来可能性太多太多我几万人同去在线的你相似 场景,为何办呢?亲戚亲戚大伙儿儿也经历了应用的拆分、分表、分库,或者为何去抽取中台等等,也是曾经 演变过来的。

这后边提到三个白业务中台,包括业务中台、数据中台、AI中台。我另一方认为太多太多我说基于公司的许多规模,真是一定会 所有公司都时要有这么三个白中台。首先你没这么大的体量,你的业务没这么复杂,服务化就时要了。刚才一定会 提到,真是微服务比较难的地方太多太多我它的你相似 服务之间的调用、依赖等等。曾经 们就时要三个白服务治理的平台,去管理每一组服务,必须可能性单个服务的故障,使整体系统可用性受到影响,太多太多要有你相似 熔断机制以及限流机制。你相似 真是是系统架构和工程方面的许多实践和经验,就不细讲了。

2、MySQL 分表分库策略

那下面亲戚亲戚大伙儿儿通过曾经 的三个白系统,看亲戚亲戚大伙儿儿在数据存储方面做了许多十几个 样的调整。首先,刚才介绍过,亲戚亲戚大伙儿儿的数据源主太多太多我来自于消息同步,当然消息的量是非常大的。亲戚亲戚大伙儿儿会用分布式Job去除理十几个 数据,太多太多亲戚亲戚大伙儿儿会采用TBSchedule,淘宝的三个白开源的分布式job。亲戚亲戚大伙儿儿会把十几个 消费的数据按分配规则进行分片,或者做除理,这是三个白比较灵活的框架。

从这张图来看,消费数据进了亲戚亲戚大伙儿儿的业务库,当然你相似 定会 所有的业务库,亲戚亲戚大伙儿儿是按照你相似 不一样的业务场景、业务逻辑去进行了库的拆分。

可能性你相似 场景它是三个白写多读少可能性说基本不太读的曾经 三个白场景,太多太多亲戚亲戚大伙儿儿就落到主库,或者三个白从库用来做备份。同去亲戚亲戚大伙儿儿会把十几个 主库里计算完成并结算的数据,通过MQ的办法同步到TiTB,把它作为三个白只读库。把数据同步到TiTB真是是不再进行分表了,曾经 还都都能能降低系统复杂。

真是你相似 数据亲戚亲戚大伙儿儿会定期地做删除,间隔共也不三到三个白月,太多太多我会把十几个 三到三个白月时候主库产生的数据做许多清理,TiTB后边的数据也是一样。一定会 三个白做法是接下来会把它抽取到hadoop后边,做许多深层的数据挖掘。

刚才提到了亲戚亲戚大伙儿儿对数据库分表分库的策略,基于亲戚亲戚大伙儿儿的应用场景,亲戚亲戚大伙儿儿使用的是sharding-jdbc来做了许多另一方的定制化。亲戚亲戚大伙儿儿主要的分表规则三个白,三个白是按照商家的ID进行分表,还有太多太多我结算单号及时间。刚才也提到说消费完时候,亲戚亲戚大伙儿儿会把数据存下来,同去亲戚亲戚大伙儿儿会做数据的异构,按照不同规则去拆。比如说按商家来拆,它的应用场景是,商家登录进来就时要就看另一方的账单,太多太多亲戚亲戚大伙儿儿会把十几个 SQL都落在单表后边,就按照商家ID进行区分。共要拆成1024张表,后续会再拆的更细许多,可能性商家的业务量可能性会这么大。

另外还有一种场景太多太多我多个商家之间的结算,那你相似 场景亲戚亲戚大伙儿儿会按照结算单号去拆,每一单后边商家A和商家B的所有结算数据。另外,亲戚亲戚大伙儿儿也会统计按月可能性是按天的、跨商家的数据,要看总报表也是按曾经 的维度来分。

拆分的过程中真是会遇到三个白疑问。可能性商家的业务规模有大有小,有的可能性每天几千单,有的每天几千万,太多太多会使得小商家会受到许多大商家的海量数据的影响。比如,或者有的商家反映在查询非常的慢,查下来就会发现曾经 是大商家在后边占了很大的存储空间。太多太多亲戚亲戚大伙儿儿会基于sharding-jdbc做许多定制化的许多除理。除理时候,当你相似 商家的数据达到一定程度的时候,比如说亲戚亲戚大伙儿儿三个白阈值,可能性每天增量达到十万条,曾经 可能性就单独为它去拆分一张表。太多太多亲戚亲戚大伙儿儿大致的办法是通过MySQL主从、读写分离来应对目前数据存储的疑问。另外,读库方面亲戚亲戚大伙儿儿正在逐步转到TiTB去做。

真是从刚才说的分表分库,亲戚亲戚大伙儿儿就时要感受到最好的请况真是太多太多我不分表、不分库,那对应用来说,守护多多线程 写得可能性就简单。亲戚亲戚大伙儿儿有你相似 MyCat、sharding-jdbc,真是你写得不复杂,或者整个架构就变得复杂了,可能性引入了三个白后边层。太多太多亲戚亲戚大伙儿儿真是是基于曾经 的场景,做了三个白适合当前应用的数据量的架构。假设未来数据库强大到单表几亿的复杂查询都还都都能能支持,那应用写得会非常简单。太多太多现在是可能性数据存储技术达必须,意味 了应用架构复杂的增加。

3、数据异构实践

接下来亲戚亲戚大伙儿儿介绍数据异构以及数据聚合,真是刚才一定会 提到许多,比如基于不同的子系统,数据可能性要被异构出来变成多份,甚至异构出来的是不存储在MySQL 后边,太多太多我会位于像ES、Redis。举个例子,比如说基于每天的账单数据算出每个商家的余额,可能性就扔到Redis后边,它再去读取的时候就会快太多太多。ES后边也是一样,要查账可能性查明细历史数据,可能性三个白月范围内的就不不去数据库后边捞了,就在ES后边去做。可能性你相似 场景的实时性要求并一定会 很高的。或者ES后边可能性数据量大,分布式搜索引擎创建索引,在合并的时候是有一定的延迟的,或者ES里调优也是非常有技术含量的,时要花太多太多功夫。

另外亲戚亲戚大伙儿儿还提到了数据聚合,可能性现在大多数的应用都采用了前后台分离,就是不是 做APP的开发可能性说做基于Web端的也是曾经 。前面是JS,后边太多太多我调各种微服务的API的许多接口。

前后端分离会意味 三个白怎么都能能的疑问呢?当你进到你相似 页面的时候,展示三个白全部的页面,但真是前端会向服务端发出,共要十几、二三个白API请求。你相似 三个白是慢,曾经 太多太多我网络耗时、体验一定会受影响,另外复杂也是三个白疑问。太多太多亲戚亲戚大伙儿儿才会去做数据聚合,在服务端和应用端一定会做一层。举个例子,比如说刚进到结算系统的首页,那它展示的可能性是今天的出勤率、今天的账单等等,共要十几、二十项的数据。十几个 会在服务端去做三个白数据的聚合,会有个job去跑,或者把数据先预存下来,存到比如说Redis可能性MySQL里,曾经 在客户端去请求的时候,就还都都能能做请求合并。曾经 就对整个工程可能性数据存储做了三个白优化。

4、TiDB使用与优化

刚才有提到TiTB,曾经 们选型的主要思考是MySQL的单机性能和容量无法线性以及灵活扩展。刚才也提到了为十几个 会用云原生微服务化,真是你相似 是很复杂的架构。为十几个 很简单的三个白结算系统会搞的这么复杂?意味 太多太多我数据存储的技术受到许多挑战。

亲戚亲戚大伙儿儿考虑选型的时候,可能性主要的业务场景一定会 用MySQL来存,亲戚亲戚大伙儿儿开始英文英文就这么再用Oracle。太多太多共要必须让开发人员去把SQL重写一套。另外太多太多我强一致性、分布式事务方面的许多要求,这是基本的结算系统的许多要求,太多太多亲戚亲戚大伙儿儿尝试使用TiTB来除理曾经 的疑问。

在使用的过程中,亲戚亲戚大伙儿儿首先是将TiTB替代MySQL的从库,可能性TiTB支持海量数据的查询,太多太多亲戚亲戚大伙儿儿TiDB里对刚才讲的各种数据异构、分表分库等进行了合并。合并的办法遇到也约到了疑问,比如说你分了1024张表,那每张表在MySQL后边的自增ID,太多太多我表一表二,真是它可能性是有重复主键的。那要把它合过来一段话,在TiTB后边可能性也要重新做三个白自增主键。

关于切换场景,亲戚亲戚大伙儿儿会从离线业务开始英文英文切,或者在非核心业务以及核心业务切。目前亲戚亲戚大伙儿儿是做到了第二步即许多非核心业务,共要十几个 节点的规模。真是这也是在做初步的尝试,可能性官方的建议,真是亲戚亲戚大伙儿儿可能性在硬件、部署各方面还这么调到最优。

同去,亲戚亲戚大伙儿儿也发现在单表的字段方面,官方的建议是小于一百个字段。可能性亲戚亲戚大伙儿儿的结算表的字段也是非常多的,共要用了八十几个 字段。太多太多查下来一段话,真是整个的性能还是比较理想。这是亲戚亲戚大伙儿儿目前对于非核心业务场景的三个白使用请况。这也使得亲戚亲戚大伙儿儿会加大对TiTB的尝试和使用。

另外,对于延时比较低的场景可能性不太适合,比如刚才讲的账单实时编辑的十几个 场景。亲戚亲戚大伙儿儿也想过,在账单实时编辑,主库用MySQL,也分表分库,或者从库用TiTB。所有的只读查询,都到TiTB后边去。你相似 亲戚亲戚大伙儿儿暂时还这么在核心业务中去尝试。

另外还三个白疑问,涉及絮状删除的会有GC性能的疑问。太多太多我说你相似 场景在维护的时候肯定不这么了业务高峰时间去做。

四、匮乏及展望

后边亲戚亲戚大伙儿儿谈了SAAS系统多租户的结算系统以及它所面临的业务方面的挑战,还有亲戚亲戚大伙儿儿怎么都能能使用微服务架构,以及怎么都能能使用分表分库、主从分离等等十几个 技术。

总结一下,首先亲戚亲戚大伙儿儿曾经 的场景,可能性业务还是不断增长的,太多太多MySQL作为存储,真是它的容量和性能,对亲戚亲戚大伙儿儿的应用场景来说可能性可能性达到三个白极限了。保守来说,可能性亲戚亲戚大伙儿儿的业务量再翻个两三倍一段话,可能性就比较危险了。

分表分库的查询,就像亲戚亲戚大伙儿儿刚才讲到的在后边层增加了架构的复杂。太多太多接下来假设亲戚亲戚大伙儿儿做许多尝试,可能性海量分布式数据库的应用还都都能能絮状去使用一段话,可能性在架构上就还都都能能得到极大的复杂。

另外,真是亲戚亲戚大伙儿儿对于业务数据包括热数据、温数据以及冷数据,它应该是有一整套完备的数据除理系统,太多太多亲戚亲戚大伙儿儿接下来会做你相似 工具桥,太多太多我说把MySQL、TiDB等都打通,实现数据的一体化治理。

最后提三个白概念,大型的互联网系统架构的探索,太多太多我所谓的云原生的微服务,加带云原生数据库的概念。提到说云原生的微服务,上午真是还在跟嘉宾讨论云原生数据库的疑问,可能性接下来亲戚亲戚大伙儿儿会加强在云原生数据库这块的许多应用和探索。

以上太多太多我我跟亲戚亲戚大伙儿儿分享的内容,谢谢亲戚亲戚大伙儿儿!

本文由

ITPUB

发布在

ITPUB

,转载此文请保持文章全部性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/06/26/2283/