00:04
腾讯一共对外开源的项目已经超过了120个。那同样,腾讯云数据库的开源建设和治理,我们秉承的也是打造可持续发展的国产数据库开源的一个生态。那今天我给大家分享的主要有三个方面的一个思考。那首先我们提倡开源的,一定要是已经成熟完善的一个产品体系,这是一个项目长期演进的一个基础。那比如腾讯开源的数据库T版。那它在2019年开始开源,那开源的十天内,我们大数就上升到超过了500个。那TSOPC版也是一款具备h tap能力,经过了八年的持续投入的一个数据库产品,那记得当时开源不久我们就收到了。欧洲。呃,航天局,国家天文台以及医疗健康、零售等各个行业用户的一个青睐。
01:04
这也得益于T已经具备了成熟完善,成熟成熟完善的一个产品能力,这也是我们坚持开源优质项目的一个价值的体现。那同时还需要强调的一点是,腾讯开源的项目与正式商用的产品是保持完全一致的。并且保持着长期的一个迭代升级,那再结合社区的一个回馈的一个贡献,那基本我们保持每月一次小型的升级,半每半年会有一次重大升级的一个节奏。那比如在2020年7月,那TSOPG版重大版本的一个升级,我们实现了查询性能上千倍的一个提升。那另外一个方面的话,产业互联网时代呢,企业也需要不同的数据库技术来满足不同的场景,因此我们近期还会推出企业级MY内核的一个开源项目。代号为T搜,这是一款针对于大规模交易场景的企业级的分布式数据库内核。
02:06
那整体来看,开源是未来技术升级重要的一个模式,我们也希望说以更加开放的姿态和机制,打造一个可持续发展的具有生命力的国产数据库开源,生态开源啊。回馈广大的用户以及开发者。那第二个方面的话,不仅仅是数据库引擎,我们也希望社区真正能够把先进的国产数据库产品能力用起来。而且用的更好。所以我们也知道说,数据库产品是一个复杂的系统应用的发展,出了技术还需要完善的一个产品服务生态。所以近期我们也计划啊,数据库SARS服务工具平台的一个开源。那其中就包括了可以完成90%日常自动调优智能诊断的AI自动化运营工具,以及可以进行大规模异构数据迁移、分发、聚合的数据库迁移平台。
03:02
那这两方面的工具应对的正好也是数据库日常运营工作中,以及啊数据库系统迁移的关键的一个应用场景。那在这里也想给大家分享一个我的一个开源的一个思考,就面对企业客户、开发者,我们希望提供的是一套成熟完整的一整套的产品能力,而不仅仅只是一份代码。那么最后回到数据库技术生态演进的角度,那我们当前除了需要解决自主可控的问题,还需要聚焦发展下一代,下下一代数据库技术,实现更高层面的基础创新的一个问题。那事实上到了今天。业内也越来越多的力量投入到基础技术的研究当中啊,但是基础研究的投入,行业包括学术界会面临着比如说基础研究设施共享不足,实际应用场景缺乏等方面的问题。
04:02
在这方面,我们也希望通过开源的方式来探索如何助力基础研究的发展。因此,从腾讯的角度出发,我们会提供更多的平台型的能力来帮助降低研究者的。研究门槛,带动更多的技术新生。那在2020年,呃,腾讯和中国人民大学合作开源了三天S。啊,他沉淀了腾讯云啊与人大在。数据库核心技术方面很多的一个研究成果,那可以提供统一的事物处理框架,快速构建新的并发控制算法以及检测数据异常等等的能力。那3TS系统在开放、深度进化的理念下发展,帮助行业对于事物处理技术的本质问题进行研究,这也是腾讯数据库开源理念的一个延续。那从技术创新到产品应用,到基础研究深化,我们希望构建的是完整闭环的技术演进的生命周期。
05:06
那么最后呃,我这边也总结一句话吧,就是如果说未来我们的。国产数据库技术发展,能够像火箭一样发射升空。遨游宇宙。那么,腾讯数据库开源项目愿做这个发射器的坚实底座?好,我的分享就有那么多,非常感谢大家。开源是未来技术升级的一个重要模式,说的非常好,非常感谢李总的致辞,感谢李总。在数据库在建设数据库开源生态的过程中,技术社区汇聚众多开发力量,推动数据库技术的创新与发展。在接下来我们就有请PG中文社区主席张文生张老师为我们带来他的分享,Post社区十周年原创共生,逐梦未来。
06:03
各位线上的朋友大家好,我是PG中国社区主席张文生。啊,非常感谢腾讯云主办的这次开源技术沙龙,让PG社区和广大数据库从业者呢,然后共同来探讨新时代下数据库开源生态的发展与实践。截止现在,关型数据库系统已经发展了40年,是一个传统又古老的领域。90年代,开源数据库展露头角,出现了post Grace,然后MYSQ等优秀的开源数据库。Post呢,是世界上最先进的开源数据库。它的起源可以追溯到1986年,是加州大学伯克利分校post斯Grace项目的一部分,到现在呢,已经持续了将近30年的研发,是一个德德才兼备,一端多长的全站式数据库。Post凭借其丰富的特性,然后稳定的表现,友善的协议,开放的生态,在广大数据库用户中呢是备受赞誉。
07:07
根据engineer排行榜,Gras分别摘得2017年、一八年、二零年年度数据库桂冠。截至目前呢,是唯有POST3度荣获殊荣。Postql中文社区呢是post gras国际社区指引下诞生的华语世界规模最大的公益开源组织。随着时代的发展,5G等新技术的出现,数据量与十年前已经不可同日而语,数据库系统也在面临着新的挑战。在全球范围内,各种分析型、交易型的数据库,时序、no circle图等等数据库百花齐放。国内数据库发展起步较晚,近期大家都知道因为中美贸易摩擦等等原因,国内的数据库市场呢,对信息技术应用创新已经是势在必行了。今年的信创数据库名单中,保守说呢,有接近60%的oltp型的国产信创数据库呢,是基于posts研发而来。
08:07
这个呢,得益于posts极其稳定的表现。UE的架构,清晰的高质量代码,更得益于PG本身商业极其友好的开源协议。在PG的基础上呢,还发展出一些非常好的分布式数据库,例如PGXCXL等等。在各行各业的关键系统呢,都在发挥的重要的作用,国内也涌现出一批UE的分布式数据库,例如DB max DB等等。当然更少不了我们今天的主角T贝斯。让缤纷多彩的数据库世界呢更添异彩。在早在193年,伟生已经开始研究post,并了文十余载。历经十余载。现在网上还可以到处可以看得到何瑞平先生当时所翻译的PG4.0~8.0等各个版本的手册。
09:04
尤其是那天post的昨天、今天和明天在网络上广为流传。何伟平先生的工作呢?为广大中国数据库从业者了解PG起到了重要的作用。在此,我们向何老师。的贡献表示由衷的敬意,2011年的时候呢?就是十年以前,在袁家,少聪德哥阿弟。韩峰、李海龙等人的倡议下,我们创建了PG的中国用户会,并在2013年杭州post gra用户大会上经过讨论呢,正式成立了post k中国用户协会。2015年的时候正式更名为post gra中文社区。post gra中文社区呢建立是为了服务广大的post gra用户、post gras相关的企业而成立的非营利性的公益组织。社区呢一直致力于post开源数据库技术在国内的宣传推广和使用,紧跟潮流,敏锐观察和把握数据库发展趋势,和各界人士共谋同筹,提升post相关企业技术竞争力。
10:11
为PG的使用者呢?搭建一个展现才华的舞台,共建post技术生态。十年间,开源软件如铁如高铁般的发展速度向前迈进。众多PG相关的从业者纷纷加入社区,为社区发展出谋划策,社区逐渐壮大。PG中文社区呢也完成了数字变,使得呢PG从一个国内数据库从业者和开发者知之甚少的数据库产品,发展到今天生态完善,枝繁叶茂。成为华语世界规模最大的PG组织。向社区组织的向中国PG大会、PG走进民企,PG走进高校等等活动呢,也已经声名远播。十年间,PG中文社区始终不忘初心,坚持公益。走过了不平凡的旅程,取得了不凡的成绩。
11:03
原创共生。因累而更精彩。讲到这里呢,我想再回到我们今天的分享主题。原创共生,筑梦未来这个源呢?我想post gra是众多数据库的源头,Post。是开源世界中的一个璀璨明珠,创呢是信息技术应用,创新是技术创新,也可以是。近年大家都在说的一个高频词,信创的创新呢,不仅是让我们拥有自主可控的it生态系统。也是拉动新经济发展的重要抓手之一。在未来呢,更是拥有万亿市场的潜力。中国有句古话,问渠哪得清如许,为有源头活水来,意思是要问,为何那方塘的水会这样清澈呢?是因为。不枯竭的源头,为它源源不断的输送活水。我觉得这句话正体现了我们源与创。相待而成,生生不息的关系,也非常适合我们今天的主题。
12:04
当原和创相融合,将携手创建更多优质的产品和服务。通过科技创新提升信息技术的国际竞争力,加快推动中国特色新基建构建进程。为我国经济向创新驱动转型提供助力,未来呢?PG社区和T社区在技术、生态、企业、服务上更深的合作。勇于开创,为用户和企业呢提供更好的支持和服务。共建开源数据库生态。同时也希望线上的朋友就参会的朋友们呢,能一如既往的支持PG社区不断的发展进步。合抱之生于豪门,我们一起携手,在下一个十年呢,共创辉煌。嗯。再次呢,感谢腾讯云海量数据cug电子工业出版社为本次活动提供的大力支持,以上就是我今天的分享,感谢大家,谢谢主持人。
13:10
感谢张老师带来的分享,作为国内最早致力于开源的厂商之一,腾讯一直在推动国产数据库的发展,助力众多开发者应用前沿数据库技术,推动开源社区生态不断完善。接下来我们就有请腾讯云数据库技术总监李跃森老师,李老师为我们带来他的TTPG与开发者共建开源生态的演进之路。大家下午好。呃,我是呃,腾讯数据库的李跃森,首先感谢前面李刚李总,嗯,对我们指引方向,然后呢,也感谢我们张文生主席,呃,给我们提供这么多的支持。
14:03
今天我给大家带来分享的题目是PC社会PG与开源开发者共建开源生态的演进之路。呃,我的分享的话分这么四个部分,首先嗯,跟大家分享一下我整个TCPG的开源的整个的历程,另外的话也回顾一下和展望一下,呃,我们现在的这次。重磅的一次版本的升级。呃,第三部分的话就是跟大家分享一下,我们在。呃,开源开源用户生态里面的。一些用户案例,最后的话我们会去,呃,回归到我们的主题,我们如何与如何与开源拥抱,开源与开源生态共生。下面开始我的第一个部分。呃,开始之前的话,先先跟。直播间里的各位朋友介绍一下TSQPGTSPG的话以前叫t base,他是我们那个腾讯自主研发的新一代的分布式的国产数据库。
15:11
具备领先的HTP能力,在架构上来讲的话,我们是一个无共享的MPP的架构,然后呃,我们完整的兼容SQ220002011的标准。同时的话,我们具备那个呃,高性能的HTP能力,然后我在伴随着腾讯内部的业务发展的过程中呢,我们衍生出了完整的三权分立的安全体系,来保证用户的数据安全。这个项目的话,我们最早呃是在2008年开始做的,然后后面最早的时候使用的是呃单机的post,后面呢,随着那个业务的发展,单机逐渐不能满足业务的需要,然后我们就引入了呃分布式的这样的一个版本进来。呃,最早是服务于腾讯公司内部的那个大数据平台,后面又接入了微信支付的商户系统,呃,随着业务的发展,慢慢的,呃,随着腾讯云,嗯,踏入了。
16:07
像外部的一个技术输出的一个一个一个一个途径。在202020年的时候呢,我们对整个的呃,腾讯的数据库的品牌进行了一个整合的升级。升级了之后呢,呃。腾讯云的整体的品牌,腾讯数据库的那个品牌叫做TTC口,然后呢,我们呃,T base的话,呃就分别呃在分在了两个产品矩阵里面,一个就是左边的那个分布式的TT口,然后的TCQ的TG版本,这对应原来的T配式的VR和V5版本,然后还有一个的话就是TTC口的杠A的PG版本,这个的话是对应以前T配的V3的版本。在这里的话,这两个版本的话,现在在我们的公有云上都有提供服务,也有专门的售卖入口。对,也欢迎大家去体验。
17:02
呃。在2019年的时候呢,随着公司内部业务的发展,然后我们当时对于整个的开源这块,我们进行了非常慎重的一个思考,就是我们要不要开源,如果我们开源能够为大家带来什么,就是像刚才李刚李总讲的,我们。要不要做一个国产数据库火箭的一个发动机,然后推动国产数据库飞往更高更远的地方去?我们当时就非常慎重的思考了,我们整个的开源的技术路线,能够为用户,能够为社会带来什么价值。第一个TPS的整个版本的话,我们其实是一直在公司内部的各个BG,七个BG的大量的业务系统在使用的,我们有充有丰富的场景的验证。而且我们还计划说把我们的开源版本和我们的自用版本供基线,这样子的话就能帮助用户快速的构建用户的核心业务。
18:01
另外的话,因为从设计之初,TB或者TPG,我们就是支持o lap和OTP的一个混合能力的,这样子对于我们的用户来讲,我们可以提供一站式的数据库服务。还有一个就是得益于push社社区的一个开放性和它的生态协议的一个一个一个自由性。这样子的话,我们。就可以达到一个完整的一个技术的一个自主可控,同时的话,我们还有专业的研发团队和运营团队投入运营和开发,然后推动这个社区的演进。同时的话。腾讯,包括腾讯数据库,我们一直以非常开放的态度去拥抱科研社区,和社区进行互动,也希望说能够在这个过程中及时的去吸纳社会的需求。然后。为开源创造更多的社会价值。基于这么多考虑呢,我们就在。2019年2019年的11月7号正式宣布了TP的对外开源。
19:02
对。这上面的话是当时我们开源了之后,我们的一些核心的getup地址和我们的参考文档。呃,回顾了这个过程,先下面先简单介绍一下TB这个架构,这个架构呃,如果之前了解过TP应该都比较清楚,我简单介绍一下TB的整体架构的话,还是一个非常典型的共享的MPP的一个数据库架构,我们最左边是我们的GTM,也就是我们的事务管理器,右边的话上面是我们的协调节点,嗯,它是整个数据库访问的一个接入节点,也是我们业务访问的入口。我们的业务在访问着任何一个CN的时候,它都能达到一个完整的数据库视图。这样子我们就可以得到一个,呃,整个剧情可以提供一个很好的读写的一个扩展性。最右下角的呢,这些是我们的,是我们的数据节点,数据节点也是我们真正存储数据的地方,这些节点的话,每个节点只会存储一个数据的分片,这些数据节点结合在一起,就是一个完整的数据的一个一个副副本。
20:07
这是我们的数据库内核,数据库内核外面的话是我们的整个的运维管控系统,运维管控系统呃,主要是支持整个数据库的一些运营监控,以及告警审计等等这些数据库的运维工作。下面。介绍完了我们前面的。PQPG的整个的演开源和内部的发展路径,下面就进入到我们的今天的,呃,主要的内容就是。来。分享一下我们这次,呃。开源的升级的主要内容。在开始介绍我们本次升级之前的话,先先简单回顾一下我们上次上次版本升级的一些个主要内容,在这个其实之前整个TPTPPG的整个开源的一个演进的版本路线的话,我们是计划每半年会发布一个大版本,嗯,包括发布一些新特性以及bug fix,然后来提升整个呃,整个用户的一个用户体验。
21:13
因此我们在202020年7月13号的时候,我们进行了一次版本发布,当时的话我们是2.1.0版本,这个版本的话,我呃简简单介绍一下这里面我们发布的一些一些主要的一些特性。这个我们在做数据库的话,都会考虑,都会需要面对一个容灾的问题,我们传统常用的话是两地三中心的容灾,这种容灾方式的话,我们一般在我们的备库,或者在我们的容灾库里面来讲,它呃会使用异步备份,然后呢异步复制,然后呢,它会有一个RPU和RPU相对偏大的问题,另外的话,如果我们的主库发生了完整的,就是发生了全部的跨市的话,我们的容灾库是不能提供完整服务的。所以说很多业务的话,就提出了说我们要做多活,就是右边这个,我们这种双双多,所谓的多活就是两边两南方和北方的业务都可以进行写入。
22:11
然后南方北方呃,在进行故障切换的时候,可以自由切换,然后。R tu为零。RPU的话,在业务控制的范围里面,这个的话其实在一些呃,非常核心的业务场景,比如说我们之前跟国内某个头部的保险公司出过类似这样的方案,而且还在他的整个的核心系统进行了上线。这种能力的话,我们在我们的2.1.0这个版本里面,完完整整的把内核能力也释放了出来。也就是说基于TBS的2.1.0这个版本的话,我们可以搭建像这个图上这样的一个双活的一个结构,我们可以在呃很很远的两个机房,包括两像深圳、上海或者说北京到广州这么远的距离,分别去搭建一个数据库集群,中间使用我们呃TP内置的那个双向同步的多活的能力,来提供一个呃异地容灾的多活写入能力。
23:06
在这个架构下的话,我们的业务层可以自由的切换选择我们的业务接入点,然后数据库底层的话,来完成整个的底层的数据复制和完整的可靠性。呃,我们在发布了2.1.0这个版本之后的话,后面原计划是今年的年初,就是2021年的年初要发布我们的下个版本的,但是因为当时发疫情比较严重,然后呢,各方面的工作都都受到了冲击,所以说我们上个版本就和今年2020年2022020年七月份这个版本就合并在一起,我们叫他2.2.0这个版本的话,现在我们在getup上已经把代码完整的都推出去了。这个版本里面的话,我们主要包括了几部分内容,第一部分来讲的话,就是我们优化了,呃,针对针对开源PG的。内存使用这块的一些问题,我们都知道那个post是一个多进程的一个框架,它的每个每个进程的话,它里面需要维护一套完整的cash,包括包括real cash和cat cash,以及对应的一些共享。
24:13
以及共享的一些数据状态都需要在这个里面来维护,在我们在我们变化量很大,或者说系统的对象很多的时候,比如说表格数很多的时候,就会带来一些问题。呃。会占用大量的内存,所以这块的话也是我们重要要考虑的一个点。对,另外一个的话,就是说在TP这个分TTSPG这个分布式框架下的话。在我们我们一些复杂的查询,包括一些CT子查询,还有一些的这种查询的话,其实在分布式场景下,如果不进行专门的优化,它的性能表现是非常一般的。我们也对这些进行进行了一些优化,还有还有另外两个优化的话,主要是针对的是我们在这个,呃。TP这个架构下,就是MPP的分布式架构下,我们如何去呃诊断分析我们的系统,然后呢,如何去提升这个呃诊断分析的效率。
25:07
然后需要一个可靠的手段出来,这样的话可以很高效的来完成我们系统的开发和问题的定位。下面就针针对我们这次科研的内容做开一个详细的解读。第一个的话,我们提供了一个完整的一个extension,这个tension的话,它其实是那个。呃,一个。嗯,可以对可以对内存使用的状态进行完整分析的一个视图。在这个extension里面呢。呃,我们可以看到上面的这些信息,比如说我们可以可以看到每个memory contact,也就是我们内存上下文那个内存的大小,以及它的复制关系,还有它,呃里面的一些。使用的状态,有了状这个状态之后的话,我们就就会看得出来,其实在整个这个呃。
26:00
进程里面在使用的时候呢,我们是我们那个cash memory con,这个con是最大的,也就是刚才我提到的,它里面存的主要是real cash和cat cash。为了解决这个问题的话,我们又对这个这块real cash和。这上面基本上来讲,那个也列举了我们在一万一万张表的访问的时候,我们整个内存的一个使用情况。为了解决那个cat catch和开过大的问题呢,我们在呃内核里面引入了一些呃淘汰,淘汰管理的算法。主要是在那个real cash和cat cash引擎里面引入了。LRU来淘汰一些低频使用的结构来达到内存控制的目的。在这个场景下的话,我们可以把我们的内存,内存的使用降低到原来的40%多。另外一个的话就是在TBS这个TC和PC这个分布式的框架下的话,我们我们的连接管理都是通过上面的poer。
27:01
就是po来跟下面的进程来建立。建立数据库连接,同时的话。每个进程在使用这个连接的时候呢,向pro发起请求来获取连接,这样子的话。在这个连接管理里面,我们就需要面对一个长有那个连接闲置连接内存占用的问题,为了为了避免闲置连接占用过多内存,我们在分布式这个场景下的话,对po进行了专门的优化,它会去探测。他所管理的每个进程的连接的连接的内存的使用情况在超过了我们的预知之后,它就会进行一些释放和重建来降低这个内存使用。在这个参数配置比较好的情况下,我们可以减少系统的内存使用,减少到原来的10%多一点点。然后呃,进行一个简单的测试,我们假设呃,CND都是两个访问1万张表,然后访问完成之后的话,我们整体上来讲,我们就我们会。
28:04
相比之前,相比那个原生的pop的话,我们能把内存降少,减少到原来的10%多一点点。然后对于新生来讲,呃,通过优化real cash和cat cash,我们能够把内存降减少到原来的45%,把内存的使用率降下来之后的话,我们就会发现整个系统的那个稳定性和整个系统的这个。性能会比之前稳定很多。另外一个的话就是在这个子查,在这个查询优化器和查询执行器这一块。在特别讲一下子查询优化,这里有一个简单的一个例子,就是在这个上面,这个搜Q场景下的话,在你在。我们优化以前呢,它是。每外面的每行记录,他都需要把里面的,就是外面这个表A的每一行记录,在扫描的时候,他都需要把这个括号里面那个子查询完完整整的执行一遍,也就是说这个复杂度是on的平方的一个复杂度。
29:00
在这种场景下,其实性能我们是可以想象的。为了优化这个场景呢,我们就引入了一个哈希的表,然后这个哈希表呢,对提前这个。内表进行一个提前的扫描,扫描完成之后把结果固化下来,然后把它传递给外面的。外面的这个查询。这样子的话,我们就把整个整个的复杂度优化成了on。然后另外一个的话就是这个distinct的查询,在的话,以前的时候在我们做这个在一些外部的测试和和这种。业务在开发的过程中,我们就发现distinct的话,我们需要把所有的数据全部拉到C上来进行整个的distinct,这时候如果这个我们要处理的数据非常多的话,这个时间是非常长的。有些查询的话可能。非常小的数据量,就要查询几个小时。为了为了解决这个问题,我们就把这个distinct进行了一个呃,分阶段,第一阶段的话,我们叫他partial distinct,在每个第义上完成本地的一个部分数据的一个in,完成了之后呢,然后把它这个爬的结果。
30:09
爬的结果以会比之前会小很多,然后再进行第二次的distinct,我们叫做final distinct,这个distinct的话就以之前的爬的结果作为一个输入来完成。这样的话能大幅的减少那个网络的传输,然后提升我们的查询效率。但这里是举了两个简单的例子,其实整个的优化器的优化的话,有点就是星星点点的,也零零总总的非常的多,就一起都合入到这个版本里面去。经过这些优化吧,整体优化下来之后呢,我们就会发现在一些复杂查询,我们这里拿的是那个TPPDS的一些查询的circle进行对比,整体上可以看的出来,在。我们2.2.0这个版本里面的话,我们的对复杂查询的优化能力和处理能力,相比之前的版本有一个数量级的一个提升。
31:00
另外一个的话就是这个分布式分布式。分布式诊断和分布式的可视化的能力。再一个那个。分布式的一个数据库环境里面,特别是我们这种MP的环境里面,我们的查询的复杂度是随着我们的数据量,我们的集群规模,就是我们的节点数。以及我们的查询关联的表的个数。是一个。N的N的N次方的一个关系。就是可以认为它是一个N的N次方的一个复杂度。这里举了一个简单的例子,这上面拿两张表,一个表A和表B,两张表进行一个。进行一个非分不可的关联查询,在我们在TPS里面在执行的时候,我们的执行计划会变成这个样子,从上面看出来,呃,执行计划上面那个。红色的那一部分。然后我们真正执行的时候呢。在执行的过程中,我们会生成假如说这个这个集群里面有两个节点,我们会有有七个进程参与,这七个进程包括C上的一个进程作为输入,包括两个D上各三个进程作为后面的一个查询的,呃,一个执行进程,这个还是在查询相对来讲两张表两个节点的情况下的一个情况,看起来已经有点复杂了。
32:11
如果说我们把这个查询搞得稍微再复杂一点。假如说我们是有。就是会变成一个这么样的一个查询,还是两张表的查询,但是呢,它它里面多了多了一些那个子查询。这个时候的话,我们的。执行的状态就会变成这个样子。大家可以想象一下,如果我们的低音数再double,或者说变成上千个节点,表格数变成七八个的话,那这个这个结构基本上来讲,靠我们的肉眼或者靠我们的人力是没办法去分析的,因此这个时候我们就需要一个很有效的手段或者一个工具,能够把我们这个查询的过程可视化出来,方便我们的问题定位和诊断。因此的话,我们就引入了一个一个插件叫那个。C class activity这个插件是干什么的呢?它的主要的作用就是去把我们的呃,查询的执行计划和执行的状态通过实时的方式把它可视化出来。这个插件的话,它可以在C上创建,然后在任何一个C上都能获得整个集群的一个执行状态。
33:14
这里举了一个简单的例子,还是拿前面那个两张表之后那个例子来看,我们可以通过第一步根据我们PG里面常用的那个查询方式来获取到我们这个查询的一个session session ID,拿到session ID之后的话,作为查查询条件,我们就会过滤出来这个。查询。在。每个D上它对应的是哪些进程,以及他每个进程它对应的执行计划和相关的一些信息。这样子的话,对于我们分析问题,定位问题,以及说。去对整个系统做深入的深入的性能调优都会很有帮助。这个我相信也是。众多的。那个数据库的DBA,或者说开发者非常需要的一个工具。还有一个的话就是说,呃,在我们在定位性能问题,或者说在进行代码调优的时候。
34:06
呃,我们经常我们常用的方法是explain verbs,或者说explain。那个。就是这基于explain这个工具来进行这种性能分析,但是我们在这个分布式环境下,我们缺乏一个analysis的能力。也就是说我们需要把这个。呃,ANA analysis的这些数据在这个执行激活里面,把它完整的显示和统统计和显示出来,方便我们后后面性能的定位,在2.2.0里面,我们引入了explain ANA analysis的能力,在这里的话我们就可以。很好的针对我们的,不管是应用的代码,就是业务的代码,还是说对数据库内核的代码进行一个性能上的调优。相信有了这两个利器,以及前面的那些性能优化的手段的话。呃,大家在TBS或者TPPG上开发应用程序,或者进行进一步的优化,都会如鱼得水。呃,讲讲到这里的话。
35:01
呃呃,就需要进到我们的第三个篇章了,这里的话,第三个篇章主要是跟大家分享一下,我们回顾一下吧。我们过去TSPG在开源的这。快两年的时间里面,我们在外面的一些。一些客户的一些进展。在那个202019年,我们准备开源的时候呢,当时就这个。欧洲航天局呢,这个他们的他们该项目的数据数据数据部分的那个负责人就联系到我,说他们想把他们的,他想想把他们的那个。呃,数据库使用TB来做。那个当然这个东西也是因为各种原因吧,然后盖盖IA这个项目,我先简单介绍一下,盖IA项目呢,其实是欧洲航天局当前也是最大的一个。呃,天文项目它的主要的目的呢,是寻找太阳,寻找那个行星,我们可以简单理解,他是找星星的,他的。
36:01
呃,它里面包括,呃,包括他这个项目其实非常非常庞大的一个项目,包括卫星,然后地面站,还有各种数据的处理采集,以及空间计算等等。他选择TPS是用来存储和计算他们采集到的那个空间数据,来进行整个呃星际的一个地图的一个一个绘制。当前的话,这个集群里面应该存储了超过300个TB的数据。因为这个项目呢,其实我们也和国内相关的一些机构进相关的一些组织和部门嘛,进行交流,希望能够说在相关方面去呃推推动我们国内在相关技术领域的一些进步。对,这是这个项目的一个基本的介绍,在2019年之后的话,他们就跟一直在跟我们频繁的进行一些接触吧,我们也对他们,嗯,对他们提供一些支持,毕竟。欧欧洲航天局在在国内或者在国际这个技术圈里面的。
37:00
那个地位还是很高的,我们还是非常愿意跟他们合作,跟他们支持,所以整个过程中的话,我们也交流的比较密切。到目前为止的话,他们已经把他们的整个的核心库已经完整的切换到T上来。然后这下面这个链接的话,是他们上次发布的一个完整的一个,呃,他们的项目的一个介绍,以及他们进展的一个分享。这两页截图呢,是他们的PPT里面提到的内容,他们也专门在他们的PPT里面提到了对TP团队的一些呃,认可和感谢,对。今年,其实在今年三月份的时候,他们KR3已经完整切换到了TP的开源版本上去。然后他们在我们的,这是他们在开源社区里面对我们的一些。一些声音吧,也是对我们的一些一些一些肯定,因为过去过去的一年多时间,我们团队里面的研发的同学,研发的小伙伴们一直在跟他们进行非常深入的一些交流,因为他们的环境就是欧欧航局他们的研发环境,我们是没有办法去登录的,他们就一直给我们提供一些日志啊,还有说一些呃呃,比较比较简单的定位手段,帮让我帮他们分,让我们帮他们解决问题。
38:08
整个整个过程,整个过程下来的话,我觉得。我们还是很很,就是站在今天,站在现在这个时候回头看的话,我是觉得我们还是觉得,呃,非常非常幸运的能够跟欧洲航天局。合作,然后一起去完成这个项目。他们明年的话会进行整个G的data release的一个发布,然后邀请了我们团队一起去参加。第四部分的话。主要是分享一下我们在PPG在未来开源生态方面的一些发展计划。第一个的话。呃,还回到我们的主题上,我们TTDPG其实是来源于post社的呃社区的,如果没有PG社区以及呃PG的整个生态的话,其实呃PG社会PG也很难发展的更好。所以这里的话,我们还是希望说能够和。
39:07
呃,P中文社区深入的合作,然后呢,借助我们,嗯,PG中文社区以及PG国际社区的力量。去发展,持续发展我们的PMC成员,然后呢,呃,希望有更多的对中国数据库技术发展有兴趣的同学,以及说呃,对PG。生态,有兴趣的同学加入到我们的科研社区里面去,然后呢,一起呃去。贡献自己的力量,推动整个社区的全面的发展。还有一个的话就是说,嗯,听说过PG。就是因为我们我们整个team的话,在在PG这个圈里面呢,就是算是呃。玩PG就是跟这个生态一起。一起合作了有很长的时间了,我我本人的话是从2009年前后开始接触社区,我们团队里面的同学的话,包括刚才像那个呃,张张主席,张文生主席提到的阿弟,还有一些其他的一些呃,对PG非常有感情的一些同学在这里,所以说我们对于整个PG的呃。
40:17
技术的架构以及他的优点和他的一些不足都是有非常清楚的认识的,然后呢,我们是希望说,呃,结合我们团队的,团队的技术研发能力,以及腾讯的这个。呃,丰富的丰富的业务生态,然后呢,去解决PG它的一些短板,然后呢,让它变得更加的完善,去适合更多的业务场景。所以这里的话,我们就对他的整个的技术路径进行规划。呃,第一部分来讲的话,我们是。持续的要去优化我们的呃分布式,分布式场景下的易用性,呃诊断能力以及我们的稳定性。包括session的可视化,Q可视化以及事物状态的可视化,还有说我们所的可视化。
41:03
在这之后的话,呃。现在我们也能明显的能感觉到,就是说开源生态的话,在这个呃,分区减脂以及这种。呃,分区表的一些深入能力上来讲,还是有些欠缺的,这块我们还会持续的去优化。另外的话就是说在这个PSOPG里面的话,我们。在子查询能力以及说分布式join以及分布式并行的能力上来讲,还是有一定的提升的空间,这块也是我们后面持续努力的一个方向。基于第四点的话,在存储和索引这块。我们都知道那个PG的话,我们在存储层的话,现在使用的是那个buff IO,然后这里我们会存在double double cash的问题,另外的话,我们的存储层我们呃,现在的话,呃,对于定常字段,或者对于一些那个常见的字段,我们是没有压缩能力的,这在一定程度上。呃,降低了PG的竞争力。
42:03
这些也是我们后面需要持续去改善和提升的地方。这些能力在我们团队完成了技术研发和呃内部的一些测试之后的话,呃在合适的时候我们都会开放给整个TPG的,就是TB的开源社区。嗯。如果大家有兴趣的话,也可以一起参与进来。最后的话,呃,回还是要回到我们这次呃开发者共建这个活动上去,我们是希望说嗯。希望大家呃,能够从我们这次发布的这些特性里面能够获得实实在在的收益,觉得这样哪些特性用的爽的,大家可以讲出来。对。OK,最后的话,呃,我们还是要放眼未来,来日方长,呃,欢迎大家来star watch for或者说来给我们提基术,如果能给我们提交代码就最好了。然后右边的话是我的我个人的微信,大家如果对TPS或者对T社PG未来的发展有任何的想法或建议,或者说呃,其他的想交流的问题随时可以加我的微信,好。
43:19
谢谢大家。感谢李跃森老师带来的分享。作为腾讯推动数据库开源生态建设的重要产品,TDSOPG具备良好的企业级特性,在提供大型数据仓库处理能力的同时,还能完整的支持分布式事务的acid特性。接下来我们就有请腾讯高级工程师万志颖万老师为我们带来基于TDS狗、PG构建数据密集型应用微信支付实践经验分享,我们有请万老师。OK,各位线上的朋友们大家好,然后那个首先刚才月森哥的分享非常有深度,然后感谢月森哥,然后那个我是,呃,我叫王志颖,是来自于腾讯微信支付的,呃,现在高呃高级工程师,然后目前主要是在从事微信支付数据平台相关的研发工作,然后今天呢,然后非常荣幸能够在此跟大家分享一下微信支付基于咱们TTSOPG来构建数据密集英语相关的几点经验。
44:15
呃,首先回顾微信支付与TTSOPG的陪跑历程了,然后我们可以说呃用一个行词来描述就是你罗我我轮,真的是的,然后TTSOPG为我们提供呃武器,而我们微信支付为TTSOPG提供了充足的试炼战场。呃,从20016年开始,我们的商务服务就已经作为PG叉Z的首个商业化应用进行落地。呃,这里要插述一下,P叉Z就是咱们TDSPG的呃前身。而在2019年,我们又将我们的报表系统底层存储全面从MYS切换到了TSPG,也给我们整体报表系统的稳定性和呃性能带来了极大的提升。而在2021年,然后我们又发现TSPG在于然后某一些RTP和RP的融合领域有着极佳的优势,所以说我们又基于T操PG来构建了我们数据仓库中的维表管理系统,然后使其成为了我们大数据生态中的呃,重要的组件。
45:12
呃,那么我们为什么要使用TTSOPG呢?呃,这个得从我们最开始的商户服务平台讲起,微信支付的商户服务平台主要是为我们千万级的商家提供一个账单明细下载及账单复杂条件查询及统计分析这样的一个平台。那么最开始我们这个平台使用的是MYSQL作为点单的存储,但是随着我们一些大呃商大商户的一些接入,包括交比数的一个逐步的提升,这一块其实遇到了非常严重的容量瓶颈和性能瓶颈,而且在当时的技术背景下,然后呃有也很很,也没有太好的就是解决方案,然后于是乎呃,针对这些问题,我们与PPG叉Z,然后呃一拍而合,然后基于P叉Z提供的解决方案,然后我们那个很好的解决了相关的问题,那么PG叉Z解解决方案有哪些呢?首先是容量问题,然后P叉Z给我们提供了海量数据存储的在线线性扩容能力,其次的话,对于大商户的数据倾斜问题的话,呃,PG叉Z也基于双K分布等机。
46:13
批质来我们解决了数据的存储的呃均匀分布问题,而在于性能方面,P叉也提供了基于index o game索引的相关的一些优化方案,然后来解决了我们传统web分页应用下的每次需要去查询总呃总行数非常消耗耗时的这样的一个问题。而在进一步的使用中,然后我们又将我们的报表系统的底层,然后MYSQL数据库完全切换为了咱们的TDSPG数据库,呃图图中是我们的一个报表系统的基本架构,然后首先从数写的一端来讲的话,我们一般会有两种写方式,一种呢是基于呃Spark的离线计算平台,周期性的,就比如说一天然后写入一次,每次写入数据可能很小,但写的数呃,但也有可能写入数据是10亿级或百亿级。
47:00
然后而除此之外的话,另一种写方式则是基于我们的类似于类呃,基于类似于flink这样的实时的计算平台,通过消息队列的方式进行实时写入来构建我们的实时报表。那其实因为写入端是有是大数据系统,因此它的每次写入的数据量是呃极其巨大的,因此对于我们底层数据存储的一个写入的性能要求是比较高的,而相对相比较于my sol TP,呃,TSPG在于并行写入方面有着明显的优势,然给我们大呃大大的缩。大大的缩短了我们的一个写入的呃,时间消耗。而在读的一端的话,除了传统的精确匹配查询之外,TPG还可以基于一些呃索引扩展能力来支持一些类似于全文匹配这样的一些能力,就是我们有一个场景是呃商户查询场景,就是呃有一个表,然后有百亿级的数据,用户需要基于商户名称去呃模糊匹配商户相关的相关的数据,在引入TSP、呃,PG之前的跟索引之前。
48:01
该场景的查询耗时接近17秒,优化之后该场景的耗时直接降到了50毫秒以内,呃性能可以说是有着极大的提升,呃基于这这一套呃存储我们现在总共一共是呃平台陈列了3600家的这样的一个报表总数,然后基本上每个报表的打开的耗时都呃基本上都在三秒以内,可以说是给我们整个报表平台然后的。呃,性能,性能包括是稳定性都带来了极大的改善。呃呃,接下来呃主要跟大家分享一下微信支付在基于T这个PG来构建我们的维表系统这样的一个业余案例。呃,什么是维表了?维表就是我们描述一个事物的不同的角度,举个例子就是说比如说呃性别有男女,比如说我们平时写代码的时候有维,呃有类各种枚举值,枚举值其实也可以认为是一种呃维表。那么接下来我们就以呃咱们写代码过程中这个维枚举值作为一个案例来深入帮大家阐述我们基是怎么样基于TPG来构建维表系统的。首先微信支付所有的所有系统的枚举值都是基于我们的领域鉴保系统进行统一的录入的,目前的话总共是有2700家的这样的一个枚举值数据,而下游数据的读取方,比如说是我们RTP数据仓库中的呃计算任务,比如说我们八表系统中也可能去要去读这些枚举值,当然我们应应用系统里边也会去读取,那么在2700家这样的一个枚举值的一个数量基础之上,如果说一旦上游的比呃。
49:33
配置比枚举值进行了修改或者说是新增,而下游得不到感知的话,其实对我们整个系统的稳定性会带来非常严重的问题,那么为了解决这一类问题的话,我们呃就发现,然后就是基可以基于have的外表与TDSPG进行一个连接的形式,来构建我们实时的这样的一个维表管理系统,这样的话,上游的呃媒值一旦变更,下游的话不管是在离线阶段系统,还是说是在应用系统以及我们的报表系统都能够实时的感知到相应的变化。这样的话,我们整体的。
50:07
在媒体制管理这一块的复杂性就可以得以控制,然后来降低相应的一个呃,质量风险,达到我们技术领域的一个的一个要求。嗯。那么我们整体的应用,呃应用的情况是怎么样子的?目前整个微信支付,然后在TPG这一块的存储量已经达到400TB加每秒钟的请求量超过了24万次,然后我觉得呃更厉害的是什么呢?就是说我们99.6%的请求基本上都可以控制在呃,耗时可以控制在十毫秒以内。呃。那么最后呢,然后呃总结一下,然后TPG让我们业务方作为应务方,然后呃让我们心动的主要累积点,第一点就是说是他的海量扩容能力,其次的话就是比如说是他的自动扩容,这呃海量存储和自动扩容能力这一块的话,让我们不需要在每天不是经常半夜起来,然后哎服务器容量告警,然后我们要去紧急的扩容或迁移数据,降非降低了我们非常多的一个运维成本,其次的话就是说在大数据里域的话,它的写入的读写的高通吐能力也是我们所呃心动的一个点,除此之外的话,呃,我觉得更好的是它的扩展能力吧,比如说他支持呃各种各样的一个索引的插件,来在特定的场景下支持我们特定的一些性能优化,使我们的呃查询性能更高。
51:33
好,以上就是我的分享,然后谢谢大家。感谢万老师带来的分享,作为新一代分布式企业级HTP数据库引擎TDPG的研发创新离不开开源post这个根基。接下来我们有请橙树科技创始人唐成唐老师为我们分享14版本的新特性,我们有请唐老师。
52:01
呃,大家好,大家下午好啊,非常感谢这个腾讯云数据库给我们提供这个讲台啊,让我来给大家分享一下PG14的一个版本的新特性,那PG14版本目前呢,已经发了这个贝塔二版本。呃,正式版本的话,应该是在下个月或者一般下个月或者十月份发布。PG呢,每年发一个大版本,大致呢,一般是在九月份十月份会发一个大的版本。那我我今天的这个分享呢,主要是有四个部分啊,第一个部分呢,会讲这个PP14在这个性能方面的。性性能方面的一个提升,第二个第二个部分呢,是在这个C口。C和一些数据类型上面的,第三个是跟DV管理方面的一个提升,第四个呢,可能是跟主备库复制的。呃,首先呢,我们来先介绍这个性能的一个提升啊,这个性能最大的,呃,最大有个变化呢,是说呢,有大量数据库连接的时候呢,它的这个事物的冲突量有个明显的一个改进啊。
53:09
呃,不管这些连接是处于这个活动还是空闲的状态啊。这个变化是很大,比方说这个是我我自己亲自做的一个测试。呃,这个测试呢,实际上是用了一台这个戴尔的。740的一个机器啊,做了一个测试。测试时候呢,在这个P14,当你的连接数很多的时候,比方说在某一些特别的应用场景,比方说这个连接数超过1000。呃,比方说达到5000或1万个连接的时候呢,在这个性能呢,会有一个比较大的一个提升,在以前的版本里面,当你的连接数非常多的时候呢,它的这个每一个连接呢,相当于在内存里面都要画个东西,那我们知道在PG里面,在这个。他这个read committed这种快照读的时候呢,他要读一个快照。
54:02
那你的你的这个连接特别多的时候,这个建这个快照呢,就比较慢。那到这个PG14呢,这一块呢,有一个提升,我们可以看到,看到这个底下有一个测试啊。测试的时候,当你连接数是1万的时候,对吧。那P14呢,它的这个。TPS这个能力呢,还可以达到是24万。呃,但是PG13呢,就只有十十三万多了,对吧,那这边还有一个图我们可以看到,就是当连接数非常多的时候呢,那P14的这个性能下降是较少的。那这是一个比较大的一个。呃,提升这对于你的连接数很多的时候是比较有意义的。那还有一点呢,就是说呢,在PG14呢,其实在这个缩影方面做了很大的一个。呃,改进那最主要的,比方说我们最普通,我们经常用的缩引就是避树索引。
55:02
B数缩引在G14的,我们经常有一些业务呢,会频繁的更新,那在这个PG10次之后呢,这个频繁的更新之后呢,这个B数呢,它也减少了这个膨胀,那它其实在很多个方面做了一些改进啊,具体呢,比方说在我这个PPT里面第一行呢,实际上实际上有一个链接,这个链接呢,是这个PG官方的对这个改进的一个说明啊。它是它是怎么来做呢?首先呢,它可以让这个底下的拈P内部拈呢,呃,有一个MBK啊,就是它这个数和这个表之间的这个结合起来更好,这样呢,以便把一些更多一些信息呢,推到这个缩引这一层。呃,让他能更积极的移除呢,因这个多版本的MACC啊,这个多版本并发控制产生这个重复行。可以,可以移出更多的。同时呢,还能避免这种因为这个多版本的重复行呢,导致的这个缩影块儿分裂。
56:03
呃,在很早的版本里面,它其实是这个缩引的,这个下的删除呢,是自上而下的,它现在呢,它其实是增加了由自下而上的这个缩影像的删除。这种东西它就能避免这个块的分裂,同时呢,他把这个呢,他同时做了有一个叫hit,就是其实是一种提示,他把这个删除。就是说如果说在这个逻辑层面上,只上这个这个缩引的这个像它是没有改变的时候呢,他把这个提示信息推到这个下,推到这个缩引这个层面呢,能够增加,这能够让这个底层能检测它,实际上这样的话,这种改变就不需要再去更新。降低了这种改变。那这个地方呢,也是提供了一个。URL链接,大家如果想了解这个更深一步的情况呢,可以看这个链接里面,或者更深一步的可以看这个源代码这块。
57:01
那如果说只是。想了解呢,我们就知道呢,就是说B在这个PG10这个版本呢,对B数来说,它更新是减少了膨胀。如果说我们不想深入了解,我们看这个就就基本上就明白了。呃,同时呢,在这个PG14呢,它对这个G的作用GT。这个索引呢,它可以在它构建过程中进行一个预排序,这样呢可以更快的创建索引,并减少这索引的大小。呃,这个里面,我我这边呢,也把这个官方的这个提交的这些这些讨论啊和一些链接放在这儿。那这个地方呢,还举了一个例子啊,比方说在这个里面呢,我们先是创建了一个表。呃,这个这个表呢,它实际上因为我们一般要用这个索引是吧,那这个首先呢,我们建了一个点的,就是点的这个数据类型。那我们创建这个点的一个数据类型呢,那我们在这呢,建了有一个有一个有个表插了一个300万条记录,对吧?那我们可以看在这个PD14里面呢,当我们见了个介介似的缩影呢,它见了时时间呢,只用了这个2.5秒左右就见完了,那大小呢。
58:19
是一。呃,148兆。但是在呃十,但是在但是在我们前面的版本PG13位是吧,我们可以看见这个索引就花了多呢,花了将近49秒,将近50秒。大小也变了,大了很多。224。223兆这样。那在这个。这个改进呢,其实对这个介词的缩影,在这种情况下,它是有很大的一个提升,呃,但是它的提升呢,实际上呢,是增在这个底层的这个缩影的时候呢。是增加了一个函数,叫做呢排序的一个支持,其实我们如果说搞这个PG时间比较久的话,我们知道GST这个缩引呢,所谓的GS索引,其实给大家提供了一个索引框架,那大家只要实现这些索引框架里面需要的这些函数之后啊,其实是不需要你再考虑这些重复啊,方方面的这些东西。
59:16
那到这个P14呢,它其实在底层内又增加了这么一个函数啊。啊,这个函数之后你实现了,你在这个里面实现了这个函数之后呢,就可以让它预排序,让创建这个GS缩引这个时间,可是大小呢都大幅下降。呃,同时呢,我们在这里面呢,它其实对这个空间的这种介词与SP介词的作用呢,也有一个也有一个提升。他现在呢,可以支持这种覆盖缩影了。就说不需要我查这个东西呢,我如果字段在这个缩里面有呢,我可以直接走,就不需要回表,而且这个索引现在可以把用这个include这个子句呢,把这个非缩引项的给加进来,这样呢就可以不用回表了。
60:05
这时候呢,我们在这边也建了一张表啊,一张测试表,这张建了一张,呃,表这里面也有一个,也有一个点的位置,然后一个地址。呃,建完之后呢,我们可以可以看呢。呃,这个样子,我们查询的是说呢,我们要找找到这个点呢,是大于十逗号十这么一个点的这么这么一个值,我们可以看到这个执行计划呢,它其实是呃,走到了这个。Only only index only sky是吧?呃,我们可以看到这样走到了index欧斯卡。这个东西就不需要再回表了。那其实呢,这个前面那个可能有些人说空间的SSP就是缩用的比较少,那下面这个索引呢,其实是我们用的比较常见的一个索引。这个就是块范围索引B索引,这种索引呢,其实是PG里面的最大的一个特色的索引。
61:06
在其他的这种这种数据库里面,基本上很少有这个这个缩,呃,特别是包括这个呃很多比方说对奥克数据库来说呢,其实奥克数据库的原帧,它也没有这种缩影,它有这个缩影其实是它的X塔一体机啊。那这种索引呢,其实在这个PG14里面呢,把这种索引呢,又进行了增强,比方说它这个索引呢,可以支持布隆过滤器的索引。实际上呢,它就是利用这个B索引的这种功能呢,实现了这个布隆过滤器索引,就是它存储的是一个站位比特是吧。每每一个这个连续的这个黑block里面其实存储一个呃比特位,那这个时候呢,它其实是在我们这这个整个这个看的这个地方呢,可以看它提供了有一个。
62:00
有个布隆过滤器的,有一个算子是吧?比方说对这个整数字节,它有int_lo_OPS这么一个东西,它同时还提供了有一些这个参数。这个地方有个例子啊,创建出来之后。啊,当然这个后面呢,还有一个这个不同的这个缩影的有一个大小,那布隆过滤器的这个这种P缩影它会大一些,但是呢,比B数缩引还是小很多是吧。那这个呢,实际上相当于是实现了一种布隆过滤器的作用。啊,实际上呢,在这个P14,它还是这个以前的BI'm缩呢,它其实还可以支持现在这个PG14之后呢,这个BIM缩还能支持这个多间。呃,以前的时候我们用这个B缩引的时候,有一个难点是什么呢?B缩引它要求你的这个插入的你这个缩引的这个这个的这个范围,这个物理的值范围呢,它必须是一个呃范围,但实际上我们经常有这么一个情况,但我们建立这个东西,但是有偶玩这个数据块里面会插入一个很大的一个值啊。
63:10
这就破坏了它这个值的范围,这时候呢。我们会导致这个BM这种缩呢,就呃失去了这个过滤的这个数据块的作用啊。但是呢,从这个P14之后呢,它可以把这个范围呢,分成多个范围。可以搞成多个范围,多范围的这个数目呢,它其实呢,还可以有一个参数指定啊。而且呢,当你不断插入这个新的这个数据的时候呢,这些值呢,还能被。呃,合并。那我们可以看到啊,嗯,这个地方呢,也有例子建了一个表,然后它它使用这个BM缩的时候呢,它这个地方呢,有一个呃,相当于这种BRM缩的有一个算子的。东西叫INT4,这个最最小最大这个多值这个范围,你要上面指定之后呢,它就可建出来一个多区间的这种B缩引。
64:08
那这个呢,对以前的这个PM缩影这个痛点呢,就基本上解决了以前这个痛点。那如果说你有更复杂的一些情况,你可能还可以用前面的这个不容过滤器的这种作用。那这些功能呢?其实都是PG数据库里边的一些非常特色的功能,但很多其他数据库都没有这些功能。啊。这前面的这些缩影都提升了,那我们再说一下这个在B形的这一块儿,B形的这一块呢,其实呢,在这个PG14之后呢,他对这种。呃,全表扫描呢。吸能有一个比较大的提升,以前的时候他这个分这个并型的是说,比方说我现在有一二三四五六十十个块,那我我分这个并行的,那第一个块儿呢,可能有第一个并行来搞第二块儿有第二个第三,然后呢,他的这个。
65:06
任务数呢,跟这个框儿呢,它是交叉的,但这种交叉呢,不太不太好把这种顺序独立用起来。那到这个P14之后呢,它其实是可以顺序读了,那把多个顺序的读的框呢,放到一个叫过来,这样提升了这个性。呃,这还是比较好的一个提升啊。那还有呢,在这个B型里面呢,它其实是呢,对这个PLP就是写我们这个过程函数的时候呢,你这个que这个指令呢,它也可以在走到B行。呃,包括这个对我们这种物化视图的这种刷新啊。现在呢,也能也能走到这个并行是吧。这还这还是对这个有比较好的一个,其实。那在这个PG14里面,其实还有一个很大的一个提升,就就是在这个外部表PGFDW这一块,那首先第一点它可以支持这种。
66:06
呃,批量的。批量的这个插入,他做了一下这个接口,对吧,这种批量的插入呢,比方说比方说假设我们以后拿要拿这个做一个简单的这个分布分表啊。那如果说你一条条去查都没人返回来的时候,那他花的时间很长对吧。特别是在这个你的这个本地库和远端的这个数据源之间交互的时候,有延迟的时候,那他现在呢,增加了这种批量的插入接口呢,你就可以减少这个来回这个交互的次数,这个时间,这样的话可以让这个性能有个较大的一个提升啊。呃,同时呢,他这个现在这个PGSR呢,还可以,还可以,现在对这个分析表支持一个能把这个远程的这个PG里面的分析表的这些呃词表呢,一次都导进来。是吧?
67:01
啊,也可以单独导一个某一个分区。是吧,这个东西呢,它是有个提升是吧。那同时呢,同时还可以在这个外部表里面可以提升这个圈啊,同时对这个长连接啊,它可以专门有个参数啊,来表示是不是这个长连接。在这个FDW这一块呢,实际上都有一个改进。呃,在这个分析表这一块呢。啊,他现在呢,其实对这个外建这一块呢,性能也有提升啊。他是说呢,我们外建其实是说呢,因为其实每个分区表的分区啊,它都有相同的结构,它其实呢,不需要再创建一些重复的一些开启,为这个实行计划,但以前的时候创建很多,但现在他可以把这些全消除掉,那节省了内存是吧。同时你更新删除操作呢,它现在可以更定位到更精细的分析啊。啊,同时呢,你还可以把这个呃直径计划是呃这种它有一个判的这个开这个目可以设成这个东西。
68:10
呃,分期表呢,它其实还有一个很大的一个东西呢,就是说他现在可以可以把一个分,把一个分区可以太去掉。的时候呢,不主塞是吧,他现在是加了一个concurrent类的这么一个参数对吧。嗯。同时呢,对于我们o table的时候,比方说要把这个数据重建的时候,重建的这类操作时候,它现在呢,也可以支持这个两阶段的重启啊,只持有一个短暂的锁,我们知道如果是out table的话,它如果是一些简单操作的话,它直接是,比如说加字段,加字段的时候它直接是。把这个算加上去,在很早PG就是直接加上去,但是对于有一些比方说把这个数据类型改了之后呢,呃,整个这个表要重建的情况下呢,这时候呢,会有交叉那个主塞,那到这个P10次之后呢,它相当于主塞也更少了,相当于这种在线的操作能力更强了。
69:10
啊,其实呢,我们知道在PG13呢,它就增加了有一个叫增量排序的一个功能。那现在在这个P14,它可以窗口函数呢,可以使用到这个增量排序,所谓增量排序就是前面的一个排序操作啊,他可能是只排了一部分的一个东西,他给你给你后面的这个操作的排序,肯定要需要进一步的时候,进一步的这个排序呢,可以利用到之前的排序。呃,比方说啊,我们说一个可能大家可能对这个增量排序不太了解啊,比方在这个P13里面,它就提供这个功能,假设我们建立一个索引是吧。建立一个索引呢,这个索引字段是这个表里面是按照这个A字段来。来建的,这是但是呢,我们有一条查询语句呢,呃是是希望呢,是按照A的A逗号B这两个字段来排序的,对吧。
70:02
呃,以前的这个版本,它其实是不能走到这个光是A呀,因为A完了之后,他B还有另外一个字段需要排,那从这个PE13开始呢,它可以把这个排序呢。相当于是我只要根据A的这个字段建排序,我可以把这A的排序之后呢,它我可以利用到之前这个排序,然后呢,我们再对这个B这个字段呢,稍微再没排,再稍微再排一下,我们就可以得到这个结果,对吧。那相当于它可以利用到之前的这个缩影,对吧,这叫增量排序的功能。那在这个P14之后呢,它把增量功能在这个窗口函数啊,比方说我们这个例子里面啊,这个例子里面,它比方说它这个里面是按照一个排序,连我查这个第一个员工,这个部门里面最早进来的一个员工和最晚进来的一个员工啊。那实际上呢,其实这种来的话,都是按照这个部门的一个号来进行一个排序,那排序的呢,应该是说呢。他这种排序之前的一个排序呢,这两个其实只要排一次就够了。
71:03
那在这个现在这个PG14呢,它这个窗口函数里面,它只要排一次就够了,它能就能利用的上是吧。呃,还有呢,在这个其实在这个P13里面,或者之前的版本里面呢,应该在P12里面啊,就就增加了扩展的统计信息是吧。什么叫扩展统计信息呢?就是说我们以前的时候呢,这个列的这种直方图啊,我们是干按照各个列来单独弄的,各个列之间他认为是没有任何关联关系的。这样的话,其实,但是在实际上我们有些数据,呃,一个表里面两个列,它可能有关联关系。比方说这一列是呃,说的最简单的一个例子,假设有的有个列是个细节是吧,男的他可能都喜欢,喜欢可能做一些更激烈的运动,对吧,女的不太喜欢。啊,这种情况下呢。
72:00
这种东西呢,应该是把这种关联链放在一起,就放相成一个字段一样,建立一个直方图,站起来会更准。那在之前的版本就是功能,那现在呢,我们可以把这个直方图这东西还能变成一个表达式啊,它这个这个语法呢,是通过这个create这个stat这个这个东西,然后呢,后面有一个表达式,我一看到这上加了一个mod的这个。函数啊,我们可以搞成是这样,同时呢,它现在这种呢,对这种O和暗的这种东西啊,多的这种它会走的更好。啊,这是在P14里面的一个,真巧。呃,性能里面呢。呃,它其实性能里面还有一种就是说我们我们对一个CQ里面一个等于很多,一个1234567等多这个这个这个当你的这个值很多的时候啊,在以前的版本里面这个比较慢,为什么慢呢?因为它要进行线性的一个搜索。当select from。
73:02
很多的时候呢。呃,这个就比较慢。嗯,到这个PG14呢,它其实是可以组成一个哈希的一个搜索的一个方法。这个性能就比较大的一个提升啊,以前的时候呢,我们可能还得还得想一些办法,或者不能这么用啊,那现在呢,它其实是当你进了一个里面的东西呢,大于一个参数的时候啊,我们就可以,它就会自动的构建一个哈希表,通过一个哈希的匹配的方式,而不是通过一种线性的搜索,这个搜索呢,那就会很慢。那你看这个地方有个例子啊,这个例子是查询这这一个东西,这这一个构语句是吧,以前这个构语要执行640毫秒,现在变成变成30毫秒,就相当于快了20倍是吧。这个呢,也是个比较比较好的一个提升啊。呃,其实呢,还有呢,在这个利PQ里面,它现在支持一种叫称为叫time烂的模式,所谓拍烂就是就是我的客户端跟这个服务器之间通信,我可以异步啊,我可以异步一下发好多个C过去。
74:09
我不必像以前的那种,我发一个C口,我必须要等这个C处理完了,我才能发下一个,他现在可以把多条一次性发过来,然后呢,一次性再获得这么一个结果。这个呢,特别是对于我这个网络延迟的这个情况,有一个有个很大的性能提示,比方说在这个本地网络,网络延迟只有0.1个毫秒的时候呢,假设我们放到50个C功能,这样交式的发是吧,和这个一次性发过去呢,它性能可能是只提升四倍,但如果我这延迟达到一毫秒呢,这这个提升就直接提升个50倍。相当于在这个利用机构这个地方呢,有一个异步的这个模式。呃,当然他这个异步呢,它起个名字叫timeline模式就是。呃,这么一个模式是吧,那这个模式呢,其实这个东西呢,通常是需要我们写代码的时候可以用到这个模式啊。
75:03
啊,同时它自带的这个P泵这个压测工具呢,它就可以使到这个模式了。哎,它有一个专门有一个语法是斜杠这个pipeline和一个斜杠一个under pipeline是吧,他就可以把这多少个C都一次性都发过去,不必等到这结果对吧。这个呢,就有一个比较大的一个。呃,性能的一个提升啊。啊,还有一个功能呢,其实是压缩压缩我们知道P。很早的版本呢,就有这种透的,就是说当你一当你一个字段的数据超过一个8K的1/4,一个数据块1/4的时候,它会自动启动这个压缩,在以前这个压缩啊,它都是用的这个GZ的这种。类似这种微力压缩法,就是GZ基本上相等的压缩。
76:03
但这种压缩呢,它的坏处就是说消耗CPU很多。但是到现在的到这个P14呢,它其实是呃,可以增加更的一些压缩。其他的压缩算法,它目前呢,它现在现在直接就支持了LZ4的,LZ4呢,我们知道它的压缩力和这个耗CPU之间是比较平衡的。当然我们要用这个功能的时候呢,我们编译这个PG版的时候呢,我们一定要加上这个杠杠这个位置,LZ4啊,它才有这个功能,否则的话,你不加这个功能,你编出来P没这个功能,你加完之后呢,它其实是。我们这个量呢,其实有个例子啊,这个例子里面可以这个字可能有点小,大家可以看一下,在用这L4的时候呢,它这个数据呢。呃,花的时间啊,是会更小,插入这个时间会更少了。我们大家可以可以看到这个,这有有几个时间。
77:01
啊,那下一个部分就前面我们说把这个性能都讲了,那我们再说呢,他其实在讲的这个C口和这个数据类型的增强,那在这个PG呢。呃,14这个版本之后,它其实是增加了一个叫做呃区间的这一个多范围的类的类型,以前呢,我们说这个润景呢,只能有一个起始值,一个最大值,那现在呢,可以这个起始值最大值多个这样子组成一个数组一样的这个东西,那我们可以更好的表示表示这个现实中一些比较复杂的情况。比方说这个地方呢,就有一个日期的一个多区间的一个范围。就对这个地方呢,有一个可以直接使使用的这个东西对吧。啊,它实际上就相当于是把多个范围呢,放在了一个数组里面。当当然这个功能其实最早呢,就是用在那个我刚说啊,这个B缩引的内部呢,它其实是我们刚刚说的一个多区间的BM缩引,它也是应用的这一块的功能。
78:03
啊,这这块功能呢,我觉得有的时候呢,存一个数据来说比较实用呢。那还有呢,这个P14呢,它其实其实以前呢,对这个杰森的这种数据类型啊,我们以前是说,比方说这一个域里面在一个域啊,我们都是用一个一杠一个箭头啊,一个箭头来来指向下一下一个域。呃,这种方式呢,可能。可能很多的,我们搞过很多开发语言的时候呢,我们希望是一个动态数组呢,肯定是通过一个中括号是吧。啊,然后一个K值在里面,就得到它的Y值是吧,一个中括一个中括,那对于P14呢,它现在呢,这个建测数据类型也能用,这种更通用的一个牵套对象的这么一个框架都可以用了。啊,PG14呢,它其实呢,在这个语句里面还可以再加一个distinct来删除这个重复的这个group setting的这一个值啊。
79:00
呃,这边其实是有一个例子啊,如果说以前那个版本会出来很多重旁。那现在呢,其实是把这个呢,加上之后呢,这个。这个我们可以看这个group by这个这后面有个这个语句啊,加上加上之后就可以把很多这个去掉。啊,这是一个窗口函数的一个增强啊。啊,刚刚刚才讲的那个窗户函数呢,可能大家用的比较少,那这个呢,递归查询这个就是说这个CT。呃,或者说我们在这个al里面,我们叫做位查询,对其实在里面我们其实就叫C啊。这种递归的这种差距呢,它现在呢,PG14呢,增加了这个色系和这个循环的语语法检测。啊,首先它增加有两类,第一第一类呢,就是说呢,它可以。进行这个我到底我到这个DV查询组是按照这个深度优先还是广度优先。
80:04
那它其实是可以加一个加一个子句啊,这底下我们可以看到那个色系有一个depth。这个呢,就是说这个事呢,按照这个深度优先,这边呢有一个B。Adth这个词呢,就是一个广度的意思啊,它这个两个色系的时候,我们看到按照这个深度或者广度优先。那这个呢,还有一个东西,他是说可以可以我直接加个语句的,可以做一个循环检测。我们看这个循环检测,这循环检测现现在也比较简单了,就加一个加一个cycle,然后后面搞一个这个ID是吧,再一下。啊,用的字段,如果说我们。呃,这个这个循环检测呢,我们就我们知道,如果说我们在我们以前的版本里面呢,呃,如果我们加这不加这个循环检测的话,如果我们数据之间形成一个环的是啊,我们本身拿这个地位查询它主要是主要是做很多的一些数形查询啊,如果形成一个环的话,这个这个数据库这个这个就出问题了,对吧。
81:12
呃,可能会,可能会产生一个类似像迭卡耳机一样,产生很大的一个临时文件,是把这个数据会撑爆。呃,但是呢,如果我们自己想加一个这个循环检测,我们需要把这个C构写的比较复杂,对吧。其实在这个P的官方手册里面,我们在这个,在这个片子里面有一个PPT里面有一个URL,我们可以看到在这个官方手册里面,他就讲了这个就在以前P10字之前是吧,我们怎么样写这个东西来避免这个循环检测。啊。到这个P14之后呢,它其实直接提供这个语法呢,那我们就不需要写这么复杂的一个CQ。那简单直接加上这个语法之后呢,就把这个循环就可以避免这个无限的这个死循环了,对吧。
82:08
啊,然后呢,我们。啊,我我们其实其实在这个刚刚才也说了,这这几个地方,可能这个片子可能有点重复对吧。啊,这就是我刚刚说的这个多的这个范围的这个东西啊。我们我们再看一下这个。这个地方呢,也有一个压缩的。诶,这块。哦,我按错了。片子我按到上面去,我说怎么看着好像是之前的呀。对,这个光要比。还有点不太熟悉。你看我再翻到刚才的地方啊。
83:07
嗯,按错了。这个地方啊,这个地方其实现在呢,还有一个很好的一个功能,就是就是这个按照TD的这个范围搜索呢,它可以。TD我们知道以前是通过TD搜索呢,它可以现在也可以走到一个范围的搜索。啊,这个功能呢,我觉得还是个非常实用的功能,比方说我们要干一个什么东西呢,假设我们要把一个P的数据呢。想更短的时间倒出来,那我们期望可能可能开成一个。呃,必须呢,把它导出。在导出的时候呢,我们要开很多个任务呢,我们肯定需要画一个范围。以前画画范围呢,可能我们必须要有个主见,那现在呢,其实是说可以用这个D,我们知道TD是代表的这个数据物理数据块的这个范围啊,从一个最大值,一个最小值,从哪一个范围,对吧。啊,那现在呢,但是呢,以前的版本呢,如果说你走这个TD的最小最大值最小值啊。
84:07
你你以前的时候他还是会走这个全表扫描,他不会走到这个TD的损TD以前的时候必须是等值查询才能走到。呃,但是现在从P14之后呢,它就可以走到这个范围,这时候呢,我们假设要导出数据呢,我们先把这个这个表的这个这这个都多大是吧,多大个块儿数据块算出来,那我们就可以,呃,比方说开不同这个进程,这个比方说开十个并发,第一个并发从第一个块儿再到比方说第10万块,第二个呢,从第十十万零一个块再到12,那这样的话,它都是通过这个扫描就会非常的快啊。啊,这个还是个比较。呃,好的一个功能。同时呢,现在这个我们知道呢,在像以前克的这种,呃,Po c的这种这种就是拿这种有点像拿这个C语言,把这个C给我迁套出来这个C语言的时候呢,他现在呢,这个支持这个declare这个语句了。
85:11
也跟这个阿克样,它这个兼容性有点小的改进啊。呃,同时呢,在这个P14呢,它在对这个存过程啊,函数里面,它存置过程里面这个存储过程啊,这个out参数的知识。啊,这种这种东西呢,以前的时候呢,只能是以前时候只能是in out的这个类型,那现在呢,能够指定成一个out呢。呃,会更方便了是吧。这个也有个例子,我就不细讲了。啊。现在呢,它其实其实呢,可以可以还支持了什么呢?Create or replace这个trigger。
86:03
以前呢,可能只能创建一个缺,不能替代啊,现在能个replace,然后index这个current index这个concurrent,现在可以直接搞到这个分析表上,分析表这边有些增强。呃,还有呢,这个spring part这个函数,它也可以支持一个负负的一个缩影啊,以前是不行的,那还增加了一个bit。上线抗的这个来计算这个比特币的个数。呃,B-count一个聚合函数的。嗯。那我们下面再讲下一个大的部分啊,就是在DBA管理这方面有比较哪些事项,刚才讲那些可能有一些D不太关注啊。呃,首先呢,我们在这个在书上P14,对这个是吧,这块是持续的,我们知道P在不同的版本里面,对这个垃圾回收都是在持续的优化,这有点像这个Java程序啊,对这个垃圾回收也是。
87:07
不同的版本都有优化。那这个呢,首先呢,它这个呢,对这个缩影进行优化了。这一块,那我们后面还有一个更更详细的讲讲解啊,同时呢,这个auto现在可以直接分析这个分析表,并把这个行数信息传递到这个附表。呃,并在这个A里面的性能有提升啊,它主要是可以通过这个病,呃底下的并发IO来做。实施呢,还可以监监控很多的一些。监控的信息方面有很多的一些改进啊,我们后面有具体例子。啊,在P14呢,它还有几个新的参数,包括这个I塞星太out,就是如果说你有一个空闲连接,连太长了,给你断下来。是吧,以及以及呢,我们可以让这个端设一个check是吧。那那这个客户端,它它隔一段时间可以探测一下,隔一段探测一下,那取消这个长时间运行的一些。
88:03
呃,一些C是吧。那那这个东西呢,还可以处理一个分区的所有人这个查询。同时呢,还增加了这个PG,这个am check里面可以检查这个数据画框。我们我我们再来说一下这个ycu这块,Ycu这块它现在呢,其实增加了一个全速ycu的模式啊啊意思就是说我们当进到进到一种紧急的一个情况的时候啊,我们这时候就是说可以跳过以前的我们设了一个参数,说我们的vacu是为为了呃减少对这个线上影响的,我们是做一段s sleep下做一段sleep,这比较慢的,那到了这个紧急的时候,我们要救急了,是吧,我们要尽快的完成。那这时候呢,它默认这个参数,它可以设在这个什么,当我们的事物到达16亿的时候呢,我们就可以呃,让他全速的这个激进的这个垃圾回收,主要是回收这个室外的啊是吧。
89:02
还有呢,在这个防止这个长时间创建缩呢,导致这个不能回收这个垃圾啊,我们在以前的这个版本里面就create indexcurrent的时候呢。啊,它这个东西呢,会主塞这个垃圾回收,那现在这个版本它可以探测到之后啊,它这个我做这个长时间的这个创建缩引这个动作,并不会主宰其他的垃圾回收啊。还有呢,在这个垃圾回收里面呢,当我们这个这个表其实是变更的比较少的时候啊,其实是对这个缩的这个垃圾回收其实没有必要的。但是在以前版本他也要去对这个缩引呢,也要做一个垃圾回收去扫描呀,这样的话就会让这个客这个动作的比较慢,也也比较大的一个负担啊,他现在呢,他可以他可以有一个。啊,当你比较少的时候,它就不回收,它目目目前设置的是不超过20%的路径的时候呢,它就不回收这个东西是吧,为什么2%呢,它现在是代码写死的。
90:10
以后呢,也可能会做成一个参数对吧。啊呃,刚才说的这个少的时候跳过啊。然后呢,这个使用预读呢,加快这个速度,就是在里面也可以通过这个快速的这个L啊。那我们在这个同时呢,我们其实在这个DB里面,我们拷贝这个导数据的时候呢,他现在可以给你提供一个视图啊,能看导入多少,排出到多好,能看到一个相当于一个进度,同时呢,可以看到一个过滤条件,过滤多少行啊。啊,同时呢,他现在还提供了一个PG state w日志,这个W日志呢,它这个读写的这个情况呢,也也可以有一个监控。等待的时长的一些统计啊。
91:00
啊对这个还有呢,增加了这个复制槽的这个统计信息复制槽,这个这个东西呢,其实最实用的这个点呢,它就是对这个逻辑复制。我们知道这个逻辑复制里面呢,它有的时候逻辑复制当来了个大数啊,它有可能会产生一个零,内存方面它会产生一个交换文件。就溢出文件放到这个磁盘里面。这个磁盘里面会影响性能,那我们现在有这个视图之后呢,它现在有这个叫SPSP这个这个东西,它可以看看溢出了多大的一个统计,那我们根据这个统计很能知道我们这个逻辑复制会不会产生一些大,呃曾经是不是产生了文件。这样的话会让这个逻辑复制走的更稳定啊。呃,那我们这里面呢,在这个p lock这个表里面还增加了,就是我这个锁一等待开始多长时间是吧,以前我不知道这个锁锁了多久,那现在可以看到。那同时在这个PG state data里面还增加了一些参数啊,能看到一些更好的一些监控。
92:04
啊,还这个PG的这个prepare这个里面可以增加了这个硬解析和软解析次数这个统计啊。这个可以看到这个次数,这样呢,我们可以更好的一些CQ的优化吧。呃,当然他自己还加了有一些对内存的一些调试啊,比方说它增加了一个视图啊,我们看到我们当前自己这个绘画里面这内存的这个,呃,上下文的一些消耗。当然如果想看这个其他的时候呢,它其实还提供了个函数,相当于把这个别的这个某一个进程的ID的内存打到这个日志里,比方在这里面它有个pglo,这个back案,这个memory context后面指定一个这个受啊晋程ID,就其他的进程ID,这时候呢,他就会输出到这个。日志里面到,我们可以在日志里面看别的进程的一个内存分布,但这个主要是肯定还是开发人员有用啊。定位问题。
93:01
呃,同时呢,其实现在还有一个比较实在的一个功能,就是说呢,我们以前的时候,假设我们备注提供查询的时候呢,他有的时候呢,它这个查询和这个应用会有冲突,是吧,会导致这个应用延迟。呃,那个延时情况到底严不严重呢?有的时候不好看是吧,那现在他可以,呃,加一个这个日志的时候,把这种信息打印出来是吧。那这时候呢,对我们对我们做这种只读的这种给报表查询的库啊,更容易定位这个问题是吧。呃,同时呢,我们其实在这协议层呢,我们还增加了一个客户端这个连接这个检查这个超时是吧。呃,可以快速中断这个客户端运行中的这个C啊,这个东西呢,是在我们今后的一些开发中可以使用到这个是吧。啊,这个呢,就是就是说呢,就是说在这个这个是服务端呢,是向这个客户端的去探测客户端还在不在。
94:00
比方说假设有个人执行了一个很大的一个C口,他要他要比方说返回1亿条数据,但一执行他自己就中断了,那我这我这个服务器这段他傻傻的给他来算都没意意义是吧,应该检测到就很快退出是吧。啊,这些东西呢,就是说呢,这个建这个缩的时候呢,我可以用增加这个table space,我可以在通过index这个缩的时候,就可以把它移到其他的空间里面。同时在这个里面呢,其实还增加了一个插件叫PG,所谓的这个插件,我们可以看到一个快的坏的这个列,我们可以跳过去它修复这个东西。这个地方呢,我们可以大家。可以在更细的。大家如果兴趣的话可以去看,还有一个有一个插件呢,可以通过命令行的方式检测这个里面有没有坏坏的。呃,剩下的像这个PG state这张表里面,它增加了一个呃KID。
95:04
这样的话,他可以跟那个其他的那个PG那个里面对接起来啊。啊,最后呢,我们还有一个部分呢,就是就是有个复制和恢复啊,这里面其实它有很多的这个。一些一些接口啊。啊,比方说这些我们就。呃,这个呢,其实说这里面呢,其实比较重要就是P呢,现在可以以这个备库为原故了,这是个比较有用的功能,还有一个就是command,这个参数改了之后可以用reload生效,不需要重启这个生效了。啊,同时在现在还增加了一个只读的一个角色和一个写的角色,我们以前的时候要增加一个只读用户还挺麻烦的,那现在可以去,他现在直接加了一个系统角色,把这个角色付给一个用户,你就可以直接搞在这里面。
96:03
当然底下还有一些HBA的增强啊,大家感兴趣可以去看。呃,这里面还有一些例PQ的这些状态的一些检测。啊,那我今天说的分分享内容就这些,那感谢大家。嗯,感谢唐老师带来的分享,接下来我们将进入本次活动的圆桌讨论环节,我们今天探讨的议题是数据库开源产业生态建设与合作,我们邀请了PG中文社区主席张文生张老师,腾讯云数据库技术总监李跃森李老师,腾讯高级工程师万志颖万老师。陈树科技创始人唐成唐老师,还有我们重量级的神秘嘉宾didel labs联合创始人吴炳希吴老师,一共五位嘉宾,我们有请五位。
97:11
OK,行,我们今天要探讨的议题是数据库开源产业生态建设与合作,大家可以发表一些自己的一些看法和观点,呃,我们先从P社区主席张文生张老师开始,张张老师,呃,你可以从PG社区的一些角度来看一下,对数据库开源产业生态建设与合作有什么看法呢?张老师。好的主持人。呃,我先说说我的想法,个人认为数据库开源的生态建设呢,是一个成体系的一个长期的事业。除了技术体系上的克难攻坚之外,也应该更多的站在解决用户。还有使用者的痛点和痒点的角度进行建设。
98:00
狙击社区和T社区可以多从技术、人才培养、储备这些方面入手,通过社区之间的运营合作呢,发挥开源社区的社会价值。以上是我的观点,谢谢主持人。呃,很好的一个角度来发表了一下自己的看法,我们感谢张老师的一些看法和观点啊,呃,接下来我们想我想问一下那个成熟科技创始人唐成唐老师,呃,你这边是不是可以从创业角的角角度来。对大家进行发表一下那个数据库开源产业生态建设与合作,呃,你你有什么看法呢?唐老师。啊,主持人我在。啊,我说一下啊,因为现在这两年呢,特别是今年啊,现在数据库的一些东西,数据库的一些新的数据库啊,有点像这个井喷的在发展,那发展呢,其实呢,现在呢,可能对这个创业者来说呢,其实还是一个比较好的一个,呃,一个时候啊。
99:02
当了现在这个数据库呢,这个从这个发展来说呢,进入到一个深水区,那可能像以前的时候啊,我们在比如五年前可对一个数据库呢,它可能只是需要比如对一个分布数据库啊,它只是需要一个简单的功能,一个AV的功能。那现在呢,客户呢,其实对我们提提了一个更高的一个要求啊呃,像你的这个分布式数据库啊,也要像这个单机数据库一样。啊,如这个比方说你的这个事物也必须要有啊,你的这个呃,一致性啊是吧。事物的一致性强,一致性也必须有,还性能还不能够低,对吧。那实际上这一块呢,其实是对这个我们各个这个创业啊,搞这个数据库人提提了一个更高的一个要求啊。啊,主持人,我主要是这么一个想法,呃,很实用的一个角度来看哈,呃,非常感谢唐老师分享自己的一些看法观点。
100:03
呃,诶,我想接下来我想问一下咱们那个吴炳希吴老师,呃,像你经营了一些成熟的这种满的一些生态,呃,你可否从一这种成熟的一些开源生态来发表一下对数据库开源产业生态建设与合作这个这个议题有什么看法呢?我们吴老师。嗯,好的,我我来讲一下我的一个看法吧。首先来讲那个,我从事买CQ这个方向大概十多年了,今年切到一个数据分析行业,叫对life,是我创业的公司,那这块里面我在这几年里面其实有一些看法就是这样的,就说在开源的过程中,其实我们不能只是简单说是代码的开源,我觉得在开源过程中应该有一套整个策略来支持,比方说我们在有一些入map的公开,怎么去说我们要做什么,这个过程里面是不是说是客户需要的,我们有一些用户组的讨论和企业客户的讨论,那这块里面我们有这样一个收集的过程,同时最终有公开出去。
101:09
那还有像我们在。开发过程中还有一些像在get up上这种A的支持,包括我们在用户沙龙,或者说企业客户怎么建立一些一些合作,比方说像买这里面跟Google Facebook他们就有这样一些深度的合作,像Facebook也会开发自己的版本,但是呢,它也不,它也是。呃,它也是那个企业版的,应该说是企业版的一个付费用户,那这一块里面,他们我觉得就是一个比较一个开源和企业的一个深度合作一个状态,呃,另外我觉得开源还是一个。文档的开源,而且是一个非常完善的文档的开源,在这一块里面,如果如果看MYSQL的话,你可以看到不管不只是有用户的使用文档,而且非常非常的清晰,还有专家的文档,像用户源码级别这种截读,呃,让你怎么去快速的在MYSQL里面添加一个功能,那这这是看到是有这些方面。
102:08
另外也看到了中国其实来讲,在呃互联网这块里面发展可以说也是比较先进的,也让我们看到了,呃,中国可能是在未来的开源事业里面,可能为全球赋能也带来了很多机会,这个也可以看到从腾讯的开源出来的一些产品,包括T贝斯,在整个社区我们也看到一些非常优秀的这种影响。那这块里面我们也希望说在不远的将来,我们中国的数据库在全球吧,也可以看到,大家可以对中国开源数据库说出来一个yes,呃这样一个呃,一个这一个这样的生态吧,呃,当然这一块里面我觉得我们还需要走的路还比较远,那么我们也需要我们更多的这个用户来参与进来,呃。来一块儿来合作,来就把这个事情来做的更好一点,呃,我大概有这样一个观点。
103:01
呃,我们非常感谢老师的一些观点哈,呃,从多元化的角度来对这个议题进行了一个分享和解读,呃,接下来我想问一下我们的万志颖万老师哈,作为我们腾讯内部的一个,呃。内部的一项业务,可否从我们内部的一个业务的角度来解读一下,就是你说一下你对数据库开源产业生态建设与合作的一些看法,呃,我们作为开源的一个运用方呢,其实那个其实我们我们也是有很多顾虑的,一方面是包括性能,然后问题我们都会提前去考虑,但除此之外的话,我们呃还有一个点关注的就是说它的扩展能力,其实我们没引入一个开源产品的话,其实对于我们的系统的复杂性都是有一个提高,也就是增加了我们的技术商,增加了我们的维护成本,那么呃,对,如果说呃,那么一般什么情况下我们才会去有一新产品的,一是老的技术,技术上遇到了技术瓶颈,第二是或者有新的技术能够带来跨越性的提升,然后利如体S,其实其实呃,就是这样的一个存在,与此同时的话,为什么要强调扩展性呢?因为那个呃,业界有很多产品其实都只能关注到,就是大家90%的通用性需求需求,那么对于另外10%的这样的一个定制化的需求可能。
104:17
可能就没有这样的一个支持能力,而我们t tto PG,然后又因为有那个插件扩展的能力,在我们的实际运用中,也帮我们解决了很多定制化场景的性能性能提升问题。呃,感谢万老师的一个自己的分享的一些观点看法,就是很务实嘛,作为一个开发者,他就是内部业务使用很务实的一个角度来进行了个解读,呃,下面我想问一下我们李月森李老师,你作为一个TTSOPG的一个研发的一个负责人,你是怎么观看着这个数据库开源产业生态建设与合作,对他有什么看法?OK,那个。感谢主持人。那个。
105:00
呃。我觉得这个。数据库技术本身的,呃,开源生态发展的这个东西。嗯,其实他需要。方方面面呃,各种各样不同的角色,不同定位的呃,组织力量的共同的协作,来去推进。因为那个从研发角度来讲的话。嗯。因为现在来讲的话,就是说整个整个国内这个开源的业态啊呃,用户。用户就是说用的多。呃,主动去贡献的,一方面来讲,可能是大家的工作比较忙,没那么多的精力和时间去做这个事情。呃,另外一方面来讲的话,也许跟大家的这个技术站也有关系,但是整体来讲的话,就是说我们的整个用户群是用的多,但是主动贡献的少,一般来讲的话,呃,一个开源社区想要长期呃稳定的去发展,同时还要有一定的竞争力的话,这个是一定离不开。原创研发团队的强力支持的。
106:02
嗯。也正如我刚才我在那个。我的那个PPT里面提到的就是说我们。嗯,团队我们团队会一直的去关注。整个TT社会,PG社区的一个技术演进,它的一个先进性和它的一个在行业的一个竞争力的一个提升。我们当然这个地方刚才我也提到,我们需要各方面的力量的一个支持,我们也很欢迎呃。业界的或者说PG生态里面的,以及数据库技术圈里面的各位的技术的粉丝,或者说技术的呃,专家能够加入到TQPG这个。技术的发展的这个过程中去,一起把这个生态能力提升上去。当然的话就是说我们把技术做好了,只是我们呃有了一个很好的一个基础,有了个产品的本身,后面的话,我觉得刚才那个吴炳希吴老师。
107:04
呃。讲的很对啊,因为之前那个我们也也去也去了解过一些开源社区的运营,就是说如果想去把这个。一个好的技术在在业界,在工业界或者在产业界能够做到很好的推广,很好的应用的话,它其实离不开一个完善的支撑体系,就是我们需要让更多的人去了解我们,然后呢,同时的话,他还会呃,还需要有对应的像刚才那个张文生张老师提到的,有对应的那个人才支撑体系来去玩,进行这个产品的推广和应用。同时的话,我觉得我们还需要跟这个。我们各个头部的厂商其实也是头,我说头部的厂商只是头部的互联网公司这种典型的业务场景有一些紧密的一些配合,这样子的话才能去。呃,更好的去让大家去接受我们是吧,包括我们的扩展性,稳定性,以及我们的性能,这些能力方面,对我觉得整体来讲的话,就是说整个开源。
108:04
这我觉得这个整个我们的开源数据库,呃,在业界的一个推广和合作的话,其实是需要呃。研发的强力支持,需要我们的背后的人才体系,还有一开源的人才技术文档的完整的支持。同样的话,我们还需要在发展的过程中去考虑到我们业界主流的业务场景,以及主流业务痛点在哪里,结合在一起才能去做好这个开源。生态的发展。这是我的。也是一点思考吧,对,OK。呃,感谢李月李月森老师对发表他自己的一些思考和看法哈,说的非常好,其实大家开源呢,也就是想通过开源的一些力量去加速产品的一个演进和创新,以满足更广泛客户的一些需求,呃,除此之外,现场的嘉宾有没有想跟其他嘉宾做一些沟通交流的呢?有没有?
109:00
那个今天这个机会很难得啊,主持人我我就那个。呃,因为那个像。张张文生是吧,张张主席就是我们PG中国社区的主席,以及那个呃,吴炳熙吴老师,这两位老师呢,都是我非常尊敬的两位业界的前辈。然后呢,其实我也很难有这样的机会能够在一个在一个会场里面,虽然今天是分开的,但是我们现场是在一个会场里面,很难有机会在在一个会场里面进行这种比较充分的开放的交流,我就就有一些简单的问题吧,因为t t circle PG的话,我们开源的。呃,时间也到目前为止也就一年半一点点。然后的话,其实而且TCPG的话是脱胎于POS接口的,就是我们整个的技术站,还有我们整个的技术架构,还有我们整个的技术能力,其实是非常依赖于PG社区的。
110:00
那其实我就想嗯,向请教一下那个张张文生。我们。TDPG的话,如果我们这个。社区是吧,我们这个社区的发展,你你从PG社区的发展角度来看。怎么样才能让TCPE的社续发展的更好?我们需要去补哪些东西呢?啊,那个张文生老师还在吗?能不能帮忙回答一下。在的在的。嗯。就是啊这个问题啊,我说一下我的一些看法吧。大家都知道这个PG本身呢,是一个集中式数据库的内核,对于绝大多数场景来说是非常够用的,当然前提是有比较高水平的数据库管理员。和架构团队。就对业务研发团队的要求也会比较高。而国内的有一些使用场景呢,和一些独特的用户习惯。
111:02
对于集中式数据库系统的管理者来说是有一定挑战的。那TS,我个人认为TS本身就是为了应对这些挑战而生的。从T1开源,然后我就已经开始关注了,T开源是非常令人激动的。是我们PG体系中开源的重量级的分布式解决方案。而T开源第一呢,是充分展现了腾讯云T团队的技术硬实力。第二呢,T通过开放源代码。在很大程度上带动了国内数据库内核研发从业者的技术水平。这个呢,是T团队的社会责任的体现。第三,呃,我觉得t bases使用了一个非常友好的一个开源协议,这也很好的体现了腾讯云t base遵守开源规则,恪守开源理论。开源伦理。这点呢是值得尊敬的,这个给国内开源项目,包括开源项目的使用者。
112:05
做了一个非常好的榜样。这个是我的一些看法,谢谢约森和主持人好。嗯,多谢文生那个。就是吴老师。呃。也是差不多同样的问题吧,吴老师那个,因为吴老师是那个。是我们那个。呃,LAS的那个创始人,然后呢,之前是一直是在做个呃,植树堂相关的运营项目,嗯,对MYSQ的科研生态,以及现在他在自己也重新启动了这个data。就是这个data f LAS这个开源项目,其实我觉得。在相关的这个开源领域的发展这块,吴老师应该也是经验丰富的,就是就同样的问题,吴老师你是怎么看的?嗯,感谢姚森,嗯,这个问题我我是这样想的啊,我我一直在社区里面强调的概念是产品带动社区,而不是产品,而不是社区带动产品,我们一个社区是不是优秀,我觉得需要我们本身的产品来去带。
113:11
所以这个是我一直在强调的概念,而且就是说,呃,现在就是怎么说呢,就是说。呃,一个是一个产品,如果说你像TBTB,呃是一个我们觉得是一个MYSQL,就是就是个PG比较优秀的版本,但是呢,这个你要不去讲,其实来讲,包括整个用户合作伙伴里面,你怎么样让他大家认识到。我觉得这个是社区的社社区的事情,但是更多的还是说要放到我们产品本身的打磨上面,内功上,因为现在呃,大家能选择的东西非常非常多,呃主要说我们最终能跟用户,包括文成说到了一个问题,就说我们怎么让用户用的更舒服一点,而不是让用户还要去。啊,安装一个PG的过程中各种问题,或者安装一个MYSQ中各种问题,那这种单机版本里面使用在这种性能瓶颈和容量扩展上都有问题的时间。
114:09
很难去处理,那么我们的产品如果能弥补用户这些痛点,我觉得也是一个非常非常好的一个生存空间,那这个我觉得就是,呃,从t base上来讲,我觉得是能达到,就是说从原来的一个单机的OS data base,然后我们像一个分布式数据库过渡。嗯,那至于我现在在做的data这个项目,呃,我们现在定位是这样的,就是说我们原来还是在OS data上,包括用户在所有的东西,你还需要去后得到数据库的,呃,安装部署什么样的场景,这些一堆的东西,包括性能,情景扩展,我们现在是想他定位到云人生项目里面,让用户只是在用这个数据库,你不用再关心这个数据库下面的容量这个问题了,也不用再关心计算能力,那么它可以很方便方便的。让用户去扩展这个能力,那这块里面其实我们还是一个理念就是。
115:03
让用户用的更舒服一点,让用户更关心他自己的业务,而不是说数据库本身下面是怎么支撑他的业务,我觉得是我我是这样一个想法。OK,好。那个多谢吴老师的观点,我觉得。吴老师和那个文胜这边给了我很多启发吧,这个呃,下面线下有机会我们再当面的交流。所以还有一个问题,就是那个。呃,还是要请请那个我们文生这边,请问一下文生这边就是TTPG啊或者t base,其实在这个。呃,生态开源那个生态圈里面,我们是一个新人,才两年的时间,你觉得。我们。开源之后对我们整个这个开源生态会有哪些影响,以及后面的话,我们如何去扮演好我们自己在这个开源生态里面这个角色呢?
116:04
张老师还在线吗?对的好的,OK,嗯。那我先说说我这么多年,然后参与开源社区的一个感想。首先呢,要明确就是就我自身呢,做开源社区的目标和意义,开源本身肯定是工业驱动,而且呢是一个需要长期坚持的事情。其实中社区到现在已经发展了十年,这一点我相信T贝也是可以做的很好。另外呢,作为开源社区,我们可以组织更多的开源社区联盟,以及更多的数据库使用者、开发者。以及数据库服务企业加入社区,通过技术迭代、服务升级,共同把社区建设的更好。以上是我的观点。谢谢约瑟和主持人。谢谢张老师。我这边。我这边就没有其他问题了,看其他同学还有没有。
117:03
OK,好像其他嘉宾也没有什么问题。嗯,都是一些很好的建议哈,像老师们的建议都是这些都是我们未来数据库开源工作中非常值得参考和借鉴的,也非常感谢各位老师的分享,那我们今天的那个腾讯云数据库技术沙龙就到此结束,再次感谢各位到来的嘉宾以及观看我们直播的朋友们,呃,疫情过后我们线下再见,再见,谢谢大家好,谢谢大家。
我来说两句