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

  • 时间:
  • 浏览:6

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

  作者:黄哲铿

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

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

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

  本次分享将由以下多少每段组成:

  多租户SAAS系统场景简介

  系统面临的挑战

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

  过低及展望

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

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

一起去,应用中会有实时读写,血块的冗杂的SQL分页查询。在座有些做金融系统或来自银行的我们我们我们 都们应该很清楚,结算系统原因说金融系统对数据的实时性、一致性的要求非常高。用户的使用习惯是把明细数据导出来,比如说每天原因有几十万甚至百万的数据要去用Excel导出来,这顶端觉得会有有些工程方面的优化,以及SQL方面的有些优化。

二、系统面临的挑战

接下来是我们我们我们 都面临的有些挑战,我们我们我们 全是做结算系统或财务方面的我们我们我们 都应该知道,用户对当时人账户里的钱是非常敏感的,比如有有些人排队去把OFO账户中的钱兑现,觉得没多少钱,但我们我们我们 都觉得这名 是我的钱,我并且随时、马上就看,拿到。在结算系统中也一样的道理,这名 数据我改了马上就才能在系统顶端得到反映。一般的小系统很好实现,有些我原因每天有上亿增量数据的系统,这觉得是个比较大的挑战。

刚才我们我们我们 都提到应用场景所面临的有些挑战和对系统的挑战,包括亿级增量的结算和数据的存储,单表肯定是放不下的,自然而然会想到去分表、分库。那按照什么样的逻辑去分?这又是原先现象,我们我们我们 都接下来会讲。

应用场景刚才也介绍过了,结算系统对一致性、实时性、可用性全是非常高的要求,我们我们我们 都的应用部署的规模要花费有几百个应用实例,部署在系统上。那几百个实例对数据库这名生活有些我原先很大的压力。假设说有两百个应用,每个应用有三4个数据库的链接,那有些我有六千个链接,对吗?有些,这对整个系统的压力、架构办法全是非常大的挑战,以及我们我们我们 都的结算系统要求这名 高可用,99.9%、99.99%类似于于的要求。

我们我们我们 都的数据主要来源于消费,消费的数据须要做实时的外理,觉得他是跑批的,用分布式job来跑。有些我在跑批的过程中,单个业务逻辑的外理的业务冗杂度觉得是非常高的。单个业务逻辑算一根绳子 账单、一根绳子 费用时,原因会涉及到十几、二4个逻辑规则。那什么数据是实时去抽,做有些预外理,放在缓存顶端,有些我在数据量大的以前,缓存原因又不一定是非常好的原先外理方案。这有些我我们我们我们 都遇到的有些现象。

觉得我们我们我们 都都能否想就看,以电商系统为例,电商系统觉得有些我在下订单的环节才有原先的原先应用场景。在下订单的以须要扣积分,扣库存等等,那个以前须要用实时数据去计算,对系统我压力比较大。

原先们的结算场景的冗杂度要花费什么?要花费有五万多个用户一起去在下单。国内原因也那么几家电商公司才能达到原先的数量。那么这名 系统它的难度,它的挑战在什么地方呢?

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

有些接下来介绍的是我们我们我们 都如何架构原先原先的系统去应对刚才我们我们我们 都所面临的什么挑战。

1、云原生微服务架构

首先我们我们我们 都采用的是云原生的微服务架构,微服务架构的好处觉得我们我们我们 都应该都很清楚。有些我它的解耦性、横向可扩、团队之间的独立性以及沉淀的业务逻辑等等。

觉得微服务也带来了有些现象,最明显的原先现象是什么?原先原先团队开发原先中台,原先现在按照业务线去拆,比如说你是用户组,右边的这张图有些我用户下单的场景,从左到右注册、下订单、结算等等。那竖着来看,按照业务逻辑来垂直去拆分它的微服务,从应用到数据存储一根绳子 线打通。那它带来的现象有些我团队媒体媒体合作的现象、团队之间的进程联调的现象以及服务治理和服务依赖的现象。有些为啥从以前的SOA发展到微服务,再发展到现在所谓的云原生微服务,要用容器化的办法以及DevOps的什么工具,来使微服务的开发才能快速地、独立地运行下去。

我当时人认为小的应用及小团队碰那么微服务的有些架构,原因根本用不上。十几当时人的团队原因是几十当时人的团队,你的架构否则我外理:加机器就才能实现横向可扩,才能支撑你的业务量,比如一天几十万单的规模,有些无须轻易去尝试原先的有些架构。这名 系统觉得也是一样的,我们我们我们 都一以前刚开始英语 在设计的以前它并全是现在的架构。以前以前开始英语 它有些我单体应用,有些我通过这名 几千人、上万人用的以前,我们我们我们 都以前刚开始英语 思考,接下来原因有些我几万人一起去在线的这名 场景,为啥办呢?我们我们我们 都也经历了应用的拆分、分表、分库,有些我为啥去抽取中台等等,也是原先演变过来的。

这顶端提到原先业务中台,包括业务中台、数据中台、AI中台。我当时人认为有些我说基于公司的有些规模,觉得全是所有公司都须要有那么原先中台。首先你没那么大的体量,你的业务没那么冗杂,服务化就都能否了。刚才全是提到,觉得微服务比较难的地方有些我它的这名 服务之间的调用、依赖等等。原先们就须要有原先服务治理的平台,去管理每一组服务,那么原因单个服务的故障,使整体系统可用性受到影响,有些要有这名 熔断机制以及限流机制。这名 觉得是系统架构和工程方面的有些实践和经验,就不细讲了。

2、MySQL 分表分库策略

那下面我们我们我们 都通过原先的原先系统,看我们我们我们 全是数据存储方面做了有些什么样的调整。首先,刚才介绍过,我们我们我们 都的数据源主有些我来自于消息同步,当然消息的量是非常大的。我们我们我们 都会用分布式Job去外理什么数据,有些我们我们我们 都会采用TBSchedule,淘宝的原先开源的分布式job。我们我们我们 都会把什么消费的数据按分配规则进行分片,有些我做外理,这是原先比较灵活的框架。

从这张图来看,消费数据进了我们我们我们 都的业务库,当然这全是所有的业务库,我们我们我们 全是按照这名 不一样的业务场景、业务逻辑去进行了库的拆分。

原因这名 场景它是原先写多读少原因说基本不太读的原先原先场景,有些我们我们我们 都就落到主库,有些我有原先从库用来做备份。一起去我们我们我们 都会把什么主库里计算完成并结算的数据,通过MQ的办法同步到TiTB,把它作为原先只读库。把数据同步到TiTB觉得是不再进行分表了,原先才能降低系统冗杂性。

觉得这名 数据我们我们我们 都会定期地做删除,间隔要花费是三到4个月,有些我会把什么三到4个月以前主库产生的数据做有些清理,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的有些接口。

前后端分离会原因原先如何的现象呢?当你进到这名 页面的以前,展示原先完正的页面,但觉得前端会向服务端发出,要花费十几、二4个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/