00:03
进入直播间的小伙伴晚上好啊,然后很高兴大家呃。今天来我们线上啊,参加我们这个就是我们的一个在线的这个,呃,数据库方面的这个交流啊,我们进入直播间的小伙伴呢,先看到我们这个屏幕上面有这个签到啊,我们先签到并等候我们的这个正式的这个交流啊在。八点准时开始啊,呃,也可以提前向大家预告一下啊,我们在这个直播的过程当中,还有这个抽奖的环节,也希望大家呃看看一看今天的运气如何。请刚进直播间的小伙伴们先进行这个签到,我们看到进入直播间之后有一个蓝底白字的签到啊,我们就可以点这个进行签到啊,然后并且进行这种等待,然后呢,我们的直播将在大概两到三分钟之后,也就是八点我们准时开始啊。
01:05
大家再稍微等两两三分钟啊。然后也希望这个刚进入直播间的小伙伴啊,先点屏幕上这个我们的签到来进行签到。然后我们再等两分钟,我们就正式开始今天晚上的直播。并且在直播的过程中希望大家走开。因为我们还有。比较精彩的这个抽奖环节。啊,我们也看看我们自己的这个这个手气,今天晚上的运气如何。然后我先把我的PPT放全屏让大家看一下啊。今天晚上我们交流的主要内容啊,其实就是。呃,这个。
02:01
开发规范这一块啊,等我们正式开始之后,我们就。再我们再等个大概两分钟啊,刚进群刚进这个直播间的小伙伴啊,我们再预告一下,就是你要进行这个签到啊,我们看到那个直播间有这个蓝底白字的这个签到,我们进行签到啊。然后。我们在等待一分钟吧,我们等待一分钟就正式开始了。咱们的直播马上开始啊,小伙伴们赶快进行签到。然后呢,我们就。再进行等待最后的一分钟啊。好,那我们现在开始今天的这个我们的一个线上的一个交流啊,今天我们交流的主要内容啊,就是我们昨天给大家介绍的这个啊,这。这两次课啊,郭老师给大家介绍了我们大概的TQ买Q版,它的一个一个我们说的一个一个架构啊,一个介绍,然后呢,包括它的各个功能模块,昨天晚上我们对这个产品啊,就TC买输出版,我们不管是公有云还是我们的这个独立输出版本,我们都进行了这种安装部署。
03:14
那么今天晚上我们要和大家交流什么呢?主要就是我们T购买SQ版呀,它大概的一个,比如说我们。通俗所讲的这个开发指南,或者就是说开发需要注意的一些事项啊,我们今天主要就交流这个,那么我们现在看我们的这个PPT啊。呃,我们可以看一下这个PPT,我们这两天应该是比较熟悉了,这是他大概的一个架构。这个架构我们看啊,你业务APP这一块,也就是前端应用这一块,流量会打到负载均衡这一层,那么负载均衡我们可说了,有这种软负载,像LVS,以及像这种F5这种硬负载是吧,它的主要作用就是将前端的流量通过你的负载均衡策略把流量。
04:01
就是。通过这个负载均衡的策略,然后把它们分发到后端,我们对应的这个SQL引擎,我们也叫proxy。是整个集群的这个接入层啊。就SQ引擎这一块,那SQL引擎作为整个集群的接入层,同时也是这个集群当中非常重要的,我们叫它计算节点,那么S你你的serve过来之,或者你的应用连接过来之后,那么我要对你首先要健全对不对,你有没有相应的权限,对某些库表有没有操作的权限,然后就要对它做这种词法分析啊,包括语法分析啊,啊,甚至是我们要对SQ进行一些改写,你比如说我要从CK里面获取这种路由条目信息啊。然后对相对应的这些circle进行改写,然后呢,如果是这是一个分布式事物,那么我还要作为一个分布式事物的协调者啊,在里面这里面出现。
05:01
最终呢,目的就是把这条circle要下推到底层呢,我们说叫数据节点啊,我们这里面是一个一个set,每个set里面是一主多从的这种高可用架构,主从之间采用这种强同步复制的这种方案。然后那么你在下面的这个数据节点,你你。经过执行之后,你产生的这个结果集最终要返回到我们SQ引擎这一层,然后搜索引擎在这一层啊,在做数据的这种汇聚啊,然后把最终的结果集返回给前端的应用,对应用进行这种应答啊。这是大概的这么一个流程,这里面呢,除了我们说的这个我们说的数据节点,数据节点和我们的计算节点是非常重要的核心以外,还有我们称为集群管理组件,我们也叫它管控的,其中这里面呀,我们这个分布式的框架呀。
06:01
它的这个功能啊,部分来自于我们这个,我们说开源的这种啊,这种CK啊,它是我们说大数据它的这个,呃,分布式的这个框架啊,在这里面的话,我们也是借助了JK啊,它的一些你比如保持啊,包括这个准备这个呃选举啊,包括我们说它保存着我们这个集群里面很多的原数据信息,你比如说我们说的路由条目信息,你比如一些账户信息啊,甚至是一些我们说的sequence啊,包括那个自增序列呀等等这一系列很多的这些原数据信息也在JK里面保存,它甚至可以称为你SQL引擎,它本身它的一个底层的一个类似于数据库这个这个东西,因为SQ引擎本身是无状态的。启动起来之后。那他要有一些初始的数据,这些数据从哪里获取呢?就从CK这里面来进行获取。
07:01
那么除了JK以外,那么我们知道还有一个调度系统,调度系统分两块,一块是scheduler,一块是manager,这两个呢,一个负责我们说的,一般来讲我们叫任务调度,还有一个叫资源调度,任务调度你比如说我。做主备切换啊。可以手动的主动的去做,也可以说是被动的,某一个DB节点出现故障了,那我肯定要做这种切换,还有一些就是资源调度,你比如说我上报资源呀,包括我这个扩容时候也需要资源的这种核实核对呀,等等这一系列的。然后是赤图云管理平台,这个平台就是我们昨天展示的这个外部页面,这个上面的这些功能选项,它的一些技术特特色,我们明天晚上会主要去讲这个管控平台,那么今天我们了解的就是你比如说这个oss是一个接口模块,你通过这个赤兔运营管理平台,比如说我执行一个命令,比如说我创建一个实例,那这个时候你这个命令是通过HTTP。
08:02
HTTP这种方式把这个命令发送到oss,那他oss把这个命令进行封装之后,在这个ZK上我们会。创建一个我们所谓的一个job,一个一个一个一个任务这么一个节点,然后呢就会触发到报纸机制,然后呢就会通知到我们的调度系统。调度系统根据你这个任务的类型,就会执行相对应的这些任务啊,这是我们说大概的一个架构啊,这个架构我们把它复述一下呢。就是因为今天可能可能有一些小伙伴们是第一次来听,所以说这个架构要给大家稍微做一个我们的一个讲解,其他的还有一些非核心的一些我们说的组件,你比如说像HDSS,它是一个分布式文件系统,那这个东西不安装它对整个机器没有影响,安装它是用来做什么呢?主要做整个集群的一个冷备中心,也就是说我们这个集群进行备份呢,它的一些备份的一些物理文件逻辑。
09:00
逻逻辑的这些数据导出啊,包括B浪的日志啊,包括一些慢慢查询的日志啊,像错误日志啊等等这一系列的啊,呃,我们的这些文件日志等等,我要保存到一个指定的一个一个冷卫中心啊,如果说我们有大存储,我们也支持这种通过挂载的方式啊,纳斯啊,小NFS这种方式你可以挂载,如果没有呢,我们也可以使用一些。相对低低的这种pcg server,然后用多个这种PC server来搭建这种我们分布式的这种文件系统,像HDFS啊,把我们的这些备份的文件保存到这个系统里面去。然后就是卡夫卡这一块,卡夫卡的话,它可以。和我们的这个consumer一个一个消费组件结合在一起,做这种多元同步,就做这种数据的迁移,也可以和ES,像K班呐,这这些,呃,组件组成什么呢?组成就是我们说的审计这一块的功能。
10:03
然后啊,刚才是我们对整个架构我们进行的一个一个一个讲解,接下来我们就要说说今天的主题,今天的主题就是说我们。呃。你做开发也好,做做做做数据库的设计也好,我们可能要会面对你不同的数据库,实际上是有一些差异的,你比如说我以前这个开发。啊,是基于这种Oracle的,或者以前我就是互联网公司的,我以前我用的都是这种买SQ这个体系的,虽然是都是数据库啊,你这个SQ的话都是比如SQ99啊,SQ2003啊等等这些标准的,但是各个厂商的数据库有它自己的特点。而这种分布式数据库和集中式的这种数据库系统。他们之间也有一些。相对的技术特点,这些技术特点我们要今天晚上和大家来聊一聊。
11:02
比如说数据库总体设计的一个原则。首先我们得知道你这款数据库它适用的场景,你比如我们的TSQ,买SQ版。它主要其实是针对于这个PP类的,也就是说我们说的这种低延迟啊,高并发啊,大数据量。像这种,那么它也支持这种轻量级的AP的这种啊,你比如说这种,呃,相对来讲就可能是我们说的在线数仓啊,包括一些报表分析啊,但是它是轻量级的,为什么呢?这受限于MYSQL这个这个体系。MYSQL这个题,我们知道MYSQL数据库本身对于复杂查询的能力不如PG。并且买像最早以前像。5.7以及5.7之前呢,它只有一种,比如说多表关联查询,它只有一个所谓的类似于我们说的叫嵌套循环的这种方式。到8.0以后,它才有哈希段,像像这种,所以说它多表关联查询相对来讲啊,能力可能不如这个PG系的。
12:09
那么因为它这种分布式的架构啊,所以说它数据量这种分散呀,呃,包括对SQ的改写,然后下推呀,我们对于这种轻量级的AP场景也是可以支撑的啊,这是我们说的适用场景,主打的就是TP类的。其次是我们说的一般数据库系统,不管是我们集中式的还是分布式的,我们都不建议使用外使用外建。那你说我这个约束我怎么怎么办呢,那么你就。不要用数据库来对他进行约束。外建的话,你这个相应的约束功能,你把它放到应用这这一块来做,数据库不要使用外建,数据库使用外建最大最大的一个缺,缺点就是说什么。对性能啊,其他的我们都不谈,就对性能影响很差。使用外键的话,哪怕你是建对应的索引,对性能来讲,起码买三这个体系来讲,对性能影响是比较大的,所以说我们不建议使用外键。
13:06
然后是业务逻辑和数据这种这种分离,就是我们在创建这个库表结构的时候,我们要注意我创建一张表的话,这个列宽有很多,我们像过去那种商用数据库。这个表的话,他一创建这单独的这一张表可能有几十列甚至上百列,那么在互联网这个场景下面,使用MYSQ这个体系下面,我们就不建议你的列列宽非常长,对吧,那你可能就要对它进行一些我们说的一些,呃,像。就是比如说把它切切成呃分成,就是可能要你比如说这个100多个字段,那我可能要把它拆成几十个字段,甚至是更少的字段,这些表。因为你列宽,如果说非常的情况下,你一行的数据就非常大,一行的数据非常大,那么嗯,这个我们知道MYSQL这个体系啊,它的一个配置那个配四是16K,那你这一行这一这这这一个页都存不下,那你想想你的性能就会非常差。
14:14
然后实力模式啊,是充分考虑数据增长,角色是使用单机实力还是分布式实力,这就是我们说的我们这个t serve,它支持。集中式的和分布式的实力,那集中式的就是它不分分布分表,那分布式的那当然是分布分表。那么我们说你,你比如说我这个,如果说你数据量没有那么那么大的情况下,那我们知道那集集中式的它的性能是更好的,因为它是。最简单的例子,你比如分布式事物来讲,单机的这个事,这个我们说的这个事物肯定要比你分布式的两阶段提交的这个分布式事物,那肯定性能要好很多的,对吧。所以说这也是我们需要考虑的。
15:00
然后这就是我们介绍的,我们支持两种这种实例类型啊,一种是no share,我们叫集中式的,一种叫group,叫分布式的。这个我们现在给出这个数据啊,我们只是做一个参考,你比如说数据量小于2T,我就用集中式的,那大于2T我就用分布式的,这个并不完全对,只是一个参考,为什么呢?那你比如说我现在的硬件环境不一样。我虽然数据量45T超过远远超于2T,可是我现在用的是比较好的这种服务器。现在我们知道PC。PC机的这种server,现在我们有些客户采集的,那那这一台物理机差不多有700多G的这个内存,你包括。我们说的这个,呃,CPU的逻辑盒差不多都128个。然后这个磁盘都是这种固态硬盘,那像这样的机器。
16:00
那他即使跑买circleq跑单机买SQ,撑几T的数据没有问题的啊。并且随着这个买像8.0啊,它对于这种多核的这种啊,虽然它是单线程这种架构,但是它现在对于多CPU逻辑核的这种架构啊,就是目前的适应是非常好,就是过去我们说128核买S根本就使不了,现在没有这个问题啊。所以说像这些什么单表你你单表你你这个单表,比如说我是一行,但是你只有不到十个列,并且都是这种字段,非常瓦X,比如说都是瓦X64,瓦X32的,那你另一个表,你比如说虽然它只有1000万行数。那它有100多个列,每个列甚至还有几个大字段,Test long test,那这时候呢,你单表肯定,那那那我1亿的这个反而性能会好,对吧,数据量不一样,所以说这些只是一个参考。啊,不是绝对值,我们要根据实际情况去。
17:02
来衡量啊,这个我是跟大家说一下。然后数据库实例的配置规范。数据库实例的这个配置规范呀,实际上我们给大家介绍一下而已。我们这个在TQ这个环境下面,你创建的这个实例啊,有很多其实它是给你。就已经。就是固定好了,你比如存储引擎,我们只能使用in DB啊,就它不允许你创建MYSM存储引擎。那为什么呢?其实买SM这种存储引擎,熟悉MYSQL的。小伙伴就知道了,买上这种东西已经被淘汰了,第一,他不支持事物,第二。它的锁力度是表极锁,所以说现在过去来讲说,哎买买S萨这种存储引擎是不是查询性能会好,那么他们网上有很多大牛已经做过这个事情,就是inno DB啊和这个买S还是5.7以前5.6左右的版本。
18:03
我只比这个查询的性能。一样因得DB也要小胜买SM,所以说买SM这种这种群众已经已经退出历史舞台了。就是我们如果你使用的是。就是单机的这种买circleq啊,你自己搭建的买circleq也不建议用SM群擎,就统一的都用in轴DB,这是其一,其二是字符集,字符集的话一般来讲我们就选UTL8或者UTL8MB4啊。那么哪个性能更好呢?当然我们看越小越好,UTL8肯定要优于这个UTL8M4,但是那你要有一你这个系统确实有一些特殊字符的,那你这个也是一种衡量对吧,那究竟选选哪一个啊,你也要进行一些衡量的。然后呢,事务自动提交啊,这个一我们的数据库这个这个一般买C这个体系,它都是自动提交的,除非你特殊的做了设置啊,还有一些就是你程序框架里面你是怎么设定的,它不像RR库是属于你必须要显示的commit。
19:10
然后事物的隔离级别,事物的隔离级别啊,我们其实知道买circle这个原生,买circle默认的是RR这种隔离级别。它的安全性能更好。但是。并发性能不行。那么他你比如说它可以避免换堵,通过盖锁啊,这等等等一系列,它可以避免这个换堵等等这一系列,但是。我们这个t soq这个体系啊,我们默认就是RC这个隔离级别,因为这个隔离级别它的并发性能更好,而且我们知道官方我们知道有一个他他那个官方的叫MJ这个集群,对吧,主复制。那他其实默认也是RC隔离级别的啊。而且官方强烈建议你用RC隔离疾病,那这个时候也对于我们那个写写写应用的这些研发人员也提出了一些要求,就是你呃要要要在应用这一块要避免换毒啊。
20:07
然后大小写设置这一块,设置表面大小写是否区分啊,这个你们要统一的进行设置,你不能说这个实例我设置成不区分,另一个是设置区分等等这一系列的啊。然后数据库对象的命名规范,命名规范其实啊,说白了这个不管你是集中式的还是分布式的,因为我们刚开始可能说我们要讲一些集中式的这种,但是不管你是集中式的还是分布式的,像有些这个我们说的这些规范。啊,或者说是这个公司的数对数据库的这些规章制度,其实它是一样的,不管你是集中式还是分布式。就是你你这个公司都要有你这公司对应的一套标准,你比如说数据库啊命名,比如我DB叫什么,当然你不一定完全按照他这个就你叫有可能你比如说以前你公司的一个简称啊,比如G啊什么啊,这是你们公司的,这都是可以的,但是呢,要有一个统一的一个规范啊,你比如说user数据库。
21:07
用户的一个库表明呢,叫TP下划线,然后是表明你也可以这个这个这个前缀也不一定非得就用这这一块对吧,只要你公司整个要不管是各个业务线,大家要统一起来啊。然后是主键啊,主键我们说是以PK啊,Primary key对吧,以它开头的啊,当然这个都是我们通用的了,像这个唯一索引就用U加IDX。那么普通索引就idx开头的,然后加上你的列名啊,缩写啊,然后最后有编号啊等等,像这些这些只是我们说抛砖引玉啊,大家呢就是了解一下,因为各个公司只要你是做DBA的,或者你研发的啊,肯定各个公司都有自己公司内部的一个详细的。
22:00
关于数据库的开发呀,等等一系列的一个规范啊。然后呢,我们先稍等一下,因为我们马上要进入今天晚上第一轮的这个抽奖了啊。我们先退出来。呃,我们20分钟的时候啊。然后来今天的第一轮抽奖,那我们先看一下其他问题,比如临时表啊,填P开头了,下回见加表名对吧,这个这个这个我们就呃就是这些我们就无过细的去去给大家讲了,因为这些东西各个公司啊都有,这个各个公司呃,你你你实际得得一套开发规范啊。我们先稍等一下,我看一下。然后今天这是我们今天晚上的第一轮抽奖啊,大家。还是应该是毛熊公仔啊,我们来,我给大家放大一点,大家看看大家的运气。
23:02
我们要持续持持续一分多钟啊,大家抓紧看看大家的运气。我看。我看咱们有小伙伴又说无缘了。说实话,白熊想中了,因为他只有三份啊。抽不动听直播了,OK,那咱们一会儿应该再稍微再多等几,多等20秒,然后我们就开始。
24:18
好,OK,那我们继续。然后我们看一下。啊,这个数据库对象命名,这我们就不做过多,这也没有什么,这都都是大白话是吧。然后分布式数据库实例建表的一些规范啊,是这样,就是我们这一块的话,应该讲架构的时候,应该已经给大家做了一个介绍了,对吧。我们这边有这个单表,广播表和分表。所谓单表啊,它创建呀,和我们原生买SQ的这个创建呀是一模一样的,就语法上没有任何的区别啊,只不过这个表创建完成之后。
25:00
他的这个表啊。只会保存在第一个分片里面,这就有点类似于mango DB,我不知道小伙伴们有没有就是呃,了解过no circle,就mango DB的,他们实际上是一样的,就是你只要不对他做这个shading,那它就是保存在第一个这个分片里面啊。这是单表,那单表说说实话,那它有什么好处呢。那你比如比如说吧,先说他的不好的地方。那么第一你如果说这个这个系统里面。单表特别多,那你都放在第一个这个分片,那第一个分片。数据量就会很大呀,那就会造成数据的倾斜,这是第一个,第二个呢。那你你你单表你可能增删改也这这些操作也非常多,你都在第一个分片里面,那这个时候实际上你第一个那个分片的压力也会。比较大压力的倾斜。
26:01
那它有什么好处呢?那你单表的话,如果这种关联查询叭较多,都放在第一个分辨,那在第一个分辨,说白了就在它一每每个分辨就是一组多层的这种架构。那实际上就等于是你对这些单表之间进行这种关联查询的时候,或者做这种关联的这种操作的时候,实际上是不需要跨赛的,都在第一个这个这个这个赛里面就可以执行了啊。这个有什么案例吗?我给大家说一下,就是我们有些客户啊,他有这么一种情况。它有一个系统啊,这个系统是是什么系统我们不说,比如说他这个系统。数据库这一块有100多个表。其中。他只有。五六个大表,其中这些大表的量非常大,甚至是他把应用之间的一些接口信息也存到这个表里面去。这个表可能不到一个月的时间就有。差不多有几百个G啊。
27:02
你想想吧,它的量比较大。那么其他的这些表啊。其实并不是很大,而且关联查询也比较多,所以说当时这个怎么做呢,就是说。这个集群里,它这个数据库,这这这这这个系统这些表啊,100多张表,就这五六张表。做真正的我们说的分布式的表啊,其他的表都作为单表放在第一个分,那刚才我们说了你的这些不好的地方,你比如第一个分片,你的这个,呃,数据倾斜呀,包括你的压力可能会大呀,那怎么办呢?就是我先做好这个分片之后。我在通过垂直。这个扩容的方式,把第一个分片,你比如说我们说的是创建实例的时候,就会有这种。我们说比如一台物理机吧,我可能要创建多实例的方式,就我这一台物理机上,我可能比如说我们3306 3307 3308 3309,我可能需要起多个实力的。
28:04
那么你做分表的这个。那我可能就是这一台物理机上,我可能要要创建多个这个地理服务啊,我们叫单机多实例的部署方式。那么第一个分片,那我就不让它是这个,我就直接把它迁移到什么呢?迁移到单独的一套物理机的环境。说白了就是第一个分辨,我给他更多的物理资源,让他来支撑啊。是这样。这是一种我们说的一种呃,应用的场景啊,这是单表。呃,单表我们不建议过多的使用,那如果你要都是单表的话,那你还不如使用集中式吧。然后是第二个叫广播表,广播表是我所有的赛,所有的分片里面都有这份表的一份全量的数据。我有两个分片,那我就有两个广播,那我要有。四个分片,八个分片,我有32个分片,64个分片呢,那这个表就会有64个,有32个。
29:02
每一个分片里面都是这个表的全量的数据。那这个表有什么好处呢?很显然就是我做关联查询的时候,我在任何一个分片上。与这个任何一个表,与这个广播表进行这种关联查询都不需要跨赛的。就在你本地,我就有这份表的广播表的全量数据,那我做照样操作的时候,我不需要跨赛,这样的话提升了它的查询的性能。那有好就有不好的地方。他的劣势是什么呀?你是查询方便了。问题是每一个分片上都有这个表的一份全量的数据。如果这个表非常大。那你要占有很大的这个空间的,这是其一,其二就是说你比如说我有64个分片,那这个广播表我每一个分片上都有一个,就我就有64个,那这时候对这个表做增删改操作的时候,我们注意这时候就要开启分布式事务了。
30:03
就是说这64个分片上的这个表,你对他执行的任何操作,要么全部成功,要么全部回滚,你哪怕说我前63个分片上的这个广播表执行一条操作。成功了,比如说我insert也好,Update也好,成功了最后一个分辨,因为有些意外。没有执行成功,那对不起,前面63个分片上对他的这个表的操作全部要给我回滚。那这样的话,无疑也增加了这个我们说执行的这个成本。所以说广播表我们一般建议。这个表啊。数据量不能太大。其次是什么呢?就是这个表啊。呃,一个数据量不能太大,增删改不能特别频繁啊,像这种表,比如说一些系统配置表啊,像这些你比如银行它有这个,比如说他类有点类似于他那个银行那个门店那个信息啊,办开ID啊,包括他你比如说他这有一个。
31:09
叫营业所吧,然后搬开店啊什么什么,像这些他不可能频繁的去去去。开张关张,开张关张,频繁的去做操作吧,所以说像这个他可能就定期的,比如他扩容的时候,他可能定期的去去去创建一些,就比如他他新增加了营业所,然后会把信息。进来。可能某些地区这个长期的这个业务啊,包括房租什么的,他可能要退,退掉那个delete或者删除掉,像这些它并不频繁啊,像这些表是可以作为广播表。然后最后一个就是分表,真正的。分布式数据库实例来讲,那它的这个这个体现就在于分表,这个分表的话,实际上就是这个表啊。我们当然我们今天讲的就主要是哈希这个啊,就按照表的某一个字段啊,呃,然后做这种一致性的哈希,然后呢,把这个表里面的数据打散到下面的这些分片里面去,说白了你比如说我现在有四个分片。
32:18
这四个分片,每一个里面都有这个分表的一部分数据啊,这是分表。它的这个规则是按照什么呢?这个规则是按照我们说的,你比如说像我们说的这个哈希这一块啊,呃,然后还有我们支持三种,第一种是哈希的,还有我们说的range的啊,然后还有这个我们说的list range,一般来讲我们比如说我们按照时间啊。然后呢,像这种类似的,你比如说我可能按照各个省,或者按照城市这个维度来进行这种分辨啊。然后这是见分表啊,见分表就是相对来讲的话,如果是哈希方式的,那我前面可以是正式的,你比如说就是创建这个表,然后后面我需要指定一个share key啊,比如说share key等于A,那么这个A就属于这个分片键,那这个表呃说呃,大家稍微等我一。
33:21
这个表如果说做这个呃做这个,比如说我们这个这个这个呃,插入的时候啊,插入数据的时候,那么它就会根据这个A这个字段来做一致性的哈希,然后呢,把这个数据按照我这个取出的这个这个这个这个结果,然后呢,把这个数据啊,然后发送到对应的这个size上面去。如果做查询的时候,我们知道,那么你这个V条件里面有SHK的话,它会通过这个sh key这个值知道你这个数据在哪一个分片上,然后就会把你的这条circle啊下推到。
34:01
具体的你你你获取到的这个set上面去。然后这个字段的选择这块我们也可以简单的了解一下,就是12K字段的类型必须是整形的或者是字符型的啊,Char字段的值不应该有中文啊,因为我们proxy这一块就不能转换字符。不好意思啊,我这有有点感冒。然后呢,是禁止update k字段的值啊。然后这个语法上就是Sha key,这这个等于什么,就放在你创建这个这个这个表的这个语句的最后就OK了。然后访问数据尽量带上12K,这我们刚才介绍了,就是你带上10K之后,这条SQL语句打到我这个计算节点proxy,或者叫SQL引擎这一块,那么SQL引擎就会。通过那个Sha可知道你这条circleq具体要到哪一个set上面去,他就不用说我群发把这个circleq发到所有的set上面去,那这样的话我们说就会大大的节省他的那个就是节省他的这一些资源,就是呃提升那个执行效率,你比如说我现在四个set,那么我明明知道这个这个这条语句是要到第一个赛上面去,那我直接就可以透传的方式把这个circle推下,推到那个第一个set上面。
35:28
你下去到第一个赛上面,你执行完成之后呢,就给我返回了,返回了之后我就直接给前端应用返回,那如果我没有指定char,我不知道我要执行的这条语句究竟是在哪一个set上面有知。即使是它真的是在SET1上面才有值,那我不知道,我也必须把这条circleq下推到这四个set上面,那么你其他的那三个size上面没有值,没有值你也要去执行这条语句,经过我们说的,呃,优化器呀,包括那个分析器,优化器呀,执行器到最后没有值的情况下。
36:05
那我就给prox这块返回为为空的,但是虽然你没有值,可是你这个执行的时候消耗CPU资源,消耗这个IO资源,消耗带宽,这样对整个这个系统的性能也是有影响的。这是这一块分表这一块。然后10K的选择这一块可能要跟大家重点的来介绍一下。我们知道买SQ这个体系很多小伙伴们都非常熟悉。那么我们主见要选什么呀,那很多人第一。感觉就是无符号自增的整形作为这个买circleq这个建表的主键,为什么呢?因为买circleq是这种B加数这种啊呃索索引结构,说白了它的主键索引就是一个B加数,那么它的叶子节点就是这这个整行的这个这个这个比如说它的叶子节点啊,叶子节点是按照呃相互之间是按照主键来码放的啊,这个双向链表,每一个数据页里面的这个。
37:11
我们说的这个航记录是按照单项链表的方式练起来的,对吧,然后整个这个这个它的数据是按照组件来进行码放的。就是那么你这时候如果你是你的那个满SQ这个这个创建的这个表的这个组件呀,如果你是按照这种,比如说我们整形的这种自增的,不管是in还是big in的这种自增的方式,那这个时候如果你插入数据的话,就不会造成它的页分裂,因为你是按照顺序一层一层的码放,一个页插满了,我再插下一个页,对吧,那这样的话效率就高,这是其一,其二呢。就是说你。你的那个二级缩影我们知道。一级,那我们说主键索引那个你的叶子节点里面存储的就是整行的这个行记录,按照主键码放的,那你二级索引里面,它也是一棵比加树啊,由根树根到到。
38:06
最后最底层的叶子节点,那它这个叶子节点存的是什么呢?它是按照里面二二级索引进行码放,但是二级索引这个叶子里面这个记录存存什么了?存的其实就是你那个二级索引的那个列的那个值,以及这个列的值对应的主见值。那这时候你V条件,你比如说我有一个二级索引是name这个字段,那V条件name等于张三,那这个时候我要走二级索引,那你前面那select的时候,你可能还需要获取这个这个整整整张表的其他列的这个字段的值。那这个时候显然你通过二级索引你是获取不到的,因为二级索引里面只有。这个你这个二级索引的这个字段的值和它对应的主键值,那这时候我就要根据主键的值。来到我们主键索引这个B加数里面去,去找到对应的主键对应的那个整行的记录来获取数据,这就是我们说的回表,当然很多小伙伴对这个MY这个这个体系很熟悉了。
39:14
那么那么说了半天的话,那你这个这个。为什么要用这个?In或者big in呢?我们知道in的应该大概是四个字节吧,Big in应该是八个字节。那那它它它占用的空间小啊,你如果用UUID的话,你你动辄要六六十四字节。这样的话,你如果说你用印的这种的话,那么你一个一个一个一个配置页,就一个配置一个,我们说数据页啊,它里面存的这个记录数据多,存的多,他一次你比如提取一个一个一一个数据页,那这样的话,它提取到内存里面的这个,我们都说二级索引那个数就多,这样的话它执行效率。就更好啊。
40:00
那为什么我们说?在分布式数据库实例里面。见表时候这个主键我们不建议大家用这个我们说的。就是这个in或者big in这种自动的形式了,因为啊,我们很少就是说像一些in或者big in像这种类型了。我们很少用它来进行什么呢?进行就是比较有意义的,你比如说这个表啊,我们一般都是用in或者big in都是这个主间都是没有意义的啊,只是一个单向的递增的这么一个一个组件啊。它不像过去我们用UID,你比如说订单的al ID啊,包括UUUID啊等等这一系列的,它有这个业务的逻辑,有业务的逻辑就意味着。你为条件里面要大量使用这个这个这个我们说的这个。呃,比如UID啊,Order ID,像这种订单ID,那你要大量出现,并且在多表关联的时候,你也要进行这种大量的。
41:04
做多表关联,你可能就是说我们去知道,就是说你多表关联的时候,呃,如果是按照这种我们说的主见的。作为这种关联的列的话,性能这一块。所以说。我们的这个分布式数据库由于受限什么呢?受限你位置条件里面,我们要尽量的有这个key,而这个sh key的选择一般我们是按照主见来进行的,所以说我们一定要让这个主见有意义。那么你刚才说的这个int或者big in,我们讲了一大堆它的好处,但是一般来讲它是没有业务逻辑的。没有业务逻辑,也就意味着它不会出现在位尔条件里面,你不会出现在位尔条件里面,如果把它作为杀key,那么你每一次操作肯定都是要把这条色狗。你有多少个赛,你要发多少份,这样的话效率就不行了啊。
42:02
所以说在分布式数据库系统里面,我们创建的这个表的这个组件,一定要让它有意义啊。那么这时候我们就不能用int int了,我们用什么呢?我现在的话呀,我我我们可能有些小伙伴也了解,就是他们有一些研发在用这个雪花算法啊,生成的这种组件啊,它是可以按照顺序啊。来递增的,这个就是不会造成你插入数据的这种一些分裂啊。还有一种就是他们有一种叫叫叫这个自增UUID的这个自增UID啊,不光可以自增,并且啊,它的这个这个占用的这个这个空间呀,还小于传统的类似于我们就阿那个体系下面那那个六十四四字节那那种UID啊,像这两种啊,我们如果说有做DBA的啊。呃,或者有做研发的,我们可以可以就是就是关注一下这一块啊,甚至如果你做DBA的话,当你的这个研发人员使用分布式数据库系统的时候,他们创建组件的时候,你发现他使用的是一些in in的这种自增的,那你也要跟他解释一下啊,同时提醒他一下啊,这是这一块。
43:22
然后这是广播表啊,广播表刚才我们已经和大家已经说了,对吧,首先好处就是说我做关联查询,做表关联查询的时候,那只要你和广播表做这种关联查询,那他就不需要跨赛的,因为它每一个size上都保有他一份全量的数据。不好的地方我们也说了对吧,就说你这个这个这个你最起码你要分布数这一块,你你你你你每一个表的这个,呃,你你你你都要,要么执行全部成功,要么你都得回滚啊,所以说这一块也是影响他一些性能啊。呃,所以说广播表我们建议是啊,嗯,数据量不能太大,并且不能频繁增删改的啊,这些表啊,比如一些配置表。
44:08
他的这个语法我们看。它的语法是你前面也是创建正常表就行,然后它这个这个后面写什么short key等于no short key_outside啊,你只要这样一写,你创建的这个表就是一个广播表,你现在有几个side,它就会到这几个set上面去都创建一个表,并且你每对它增加一个增删改的操作都会到这个,呃,你现有的这个set上面去执行啊。这是我们说的广播表,然后是单表,单表实际上就是我们说的啊,和原生买SQ这个建表没有任何区别,我们只是注意在分布式数据库实例里面,这个单表它会永远都会放在第一个set。坏处我们说了第一个set,你的这个数据倾斜问题,包括你压力问题对吧?好处就是说第一个set里面的这些表之前做关联查询的时候啊,那他也不需要跨赛的性能相对要好一些。
45:16
单表和广播表,我们记住不能把它在线变为分表。只能通过这种导入导出的这种方式啊,所以说这个我们要你要创建单表,你提前你要做好规划的啊。呃,像我们刚才说的,你第一个赛,如果说你你有这个需求的话,那第一个赛你要适当的加大它的物理资源,当然这些的话都是我们在选型之前,架构师啊,包括DBA啊,包括研发这一块的负责人呢,可能要坐下来进行这种我们说的这种交流的。就是我们一般来讲,可能小伙伴们有参加工作的都知道,我新上线一个业务系统的话,或者我老的这个数据环境,我要我比如说我要做迁移等等啊,这个可能大家都要坐坐在一起,要要要要要要这个。
46:03
呃,聊很久的。因为这个数据库其实是是比较重的啊。然后是一些主件约束啊,设计啊,主件包括一些约束设计啊,你比如说所有的表必须指定组件啊,这些我们只是了解一下,也就是说你如果你现在是个DBA,你现在你手里管着一些原生的一些MY搜狗,注意啊,这里也适合就是所有的表必须用文件。没有主见会最大的问题,你比如说这个马克一个痛点叫主层延迟。就是主备之间数据不一致,那这时候你要是在备控上去查询和主库时间,这个时差还还还有时候会拉的越来越长。为什么呢?有很多时候是没有主见。没有主见的时候,如果在对这个表进行大量的这种增删改,那一定会造成主备延迟的,所以说必须有主见,但是在我们TC这个系统里面。
47:02
就我们现在就是你没有主见,他你创建不成功的就是你默认必须要有主见。然后是主建的唯一性啊,然后这一块的话,我们刚才也介绍了,主建的话,在分布式实例里面,我们尽量要让它有意义啊,你比如说一些订单的,比如order ID啊,User ID啊等等这一系列的,但它是这个表最最主要的。我们说啊,这个这个这个是这个表的灵魂,会用在大量的这个威尔条件里面啊,并且多表关联的时候也要用到啊,然后呢。那那我用过去那种or那种UID吗?我们建议大家是用雪花算法生成的组件,或者呢,用自增的UIID的这种方式啊这一块,然后减少外键的使用,注意啊,有些分布式的这种实力,本身是对外键已经屏蔽掉了,就不让你用啊,这是其一,其二,哪怕我们是使用集中式的这种架构,或者是我们是用的原生MYSQ,我们也不建议使用外键。
48:05
早期的时候我们知道这个大表加字段的时候,我们使用一些第三方的工具,你比如说PD工具,那这个时候如果你有外建的话,那有可能造成主备数据不一致。所以说外建这个东西我们尽量。不能用啊。然后有多个唯一键啊,使用最常用的唯一键作为主键啊,像这些当然了,呃,这个我们都都不能说,呃,这个就是一就是真理啊,我们得看结合具体的业务场景啊。逐渐的效率啊。组建的字段总长度越短效率越高,但是这还是按照原生买思后来的,那你在这个分布式的这种架构里面,那你要考虑了啊,你不能说用用int int int肯定长度短呀,那你就用int嘛,对吧,那那那那这是要根据实际情况来的啊,所有这些东西都只是建议啊,Not特纳约束啊,字段属性尽量尽量加上脑特。
49:03
当然这些我们就不过细的讲,因为这些啊很多,你你去网上一搜啊,就是数据库开发呀,包括一些运维啊等等,有多少条规范,有多少军规啊,这些我们都可以去查啊,我们在这里面只是抛砖引玉的带着大家来过一下。然后索引的规范啊,索引的规范,你比如索引字段的选择啊,选择这种就低选择性性的这个列不加索引,说白了就是你比如说是一。Status一个状态,它只有五种状态,那像这种的或者性别只有男女,或者一个一个未知,那像这种列肯定不建议加索引,对吧?那如果这个列里面所有的这个这这个值都不重复,那这如果加上索引,那它的执行效率是非常非常高的。那么有的时候我就必status,相当于我必须得加,所以呢,怎么办呢,他们经常会加在这个联合索引里面啊,并且要放在最右边注意一下。
50:07
然后组合索引啊,也就是我们说的联合索引,常用的字段放在前面,不是常用的字段啊。呃,后边这个对,就是选择性高的,说白了就是你的这个,呃,每个值越不重复的,你越放在。所谓前面就是放在左面啊,因为它有一个最多匹配啊,然后所以的数量就是你单张表控制在三到五个,应该是这也根据你表的这个,呃,我们说有多少列,这都有关系,为什么说要控制索引的数量,所以呢。首先解决查询问题对吧,那你比如说你索引来讲啊,呃,没有索引,有时候查询你都漏不出数据是吧,但是索引维护索引也需要代价的,你每做增删改的操作,那你同时这个索引你也要进行维护的,所以说有些时候你索引过多,而索引的使用的效率又不好的情况下,那也会造成这种性能的瓶颈。
51:06
呃,索引的名称,你比如IDX什么开头的,这我们就不细说了啊,然后前缀索引,对于较长的字符串类型字段啊,建议使用这种我们说的前缀索引啊,你前缀索引当然我们要选择了,呃,这里面我们因为时间的关系,可能讲不了那么细,就怎么选这个前缀索引,我是用这个字段的前六位还是前八位呢?其实你可以算一下大概的它能覆盖多少,用前六位就能覆盖到80%,那你就不用不需要用前八位了,对吧?那那前六位可能覆盖不到,那我就必须要前八位,那这些的话,我们可以去上网去查,这些都是有的啊。然后冗余索引,合理合并索引,避免冗余,像冗余索引啊,像这些啊。呃,我们那个明天我们讲这个赤兔运营管理平台的时候,有冗于索引的,这个我赤兔运营管理平台我都可以把它给,还有那个重复索引,我都可以把它们找出来啊,然后看合不合适。
52:08
这些我们都可以通过工具直接把它们选取出来,还有一个全文索引,注意。全文索引不要放在数据库来做,尤其是买SQ这个这个这个这个这种关系型数据库啊呃呃,他现在支持支持不建议啊,不建议在这个数据库这个这这这块来做。呃,索引字段的数量,单个索引字段数不要超过五个是吧,但这些的话只是一个,我们只是说大概的一个一个一个一个一个一个估值啊,然后我们马上进行咱们的第二轮。抽奖啊,小伙伴们准备一下。好OK,我给大家大家放大一下啊,第二轮还是一样的。T买搜狗无门槛代金券三份啊,看看大家的运气如何啊。
53:41
我们再等20秒啊。OK,好,那我们。呃。我们我看行。
54:02
呃,有,有小伙伴问老师讲课过程中能讲考点吗?考点,你这个咱们现在主要是技术交流,不是说你们一定要考试的吧,我们主要还是以技术交流为主好不好?因为你要说讲考点的话,我也没有准备,因为现在的话,呃,考试内容的话,虽然我是呃。和咱们进行交流啊,但是点是目前我也不是特别知道啊,因为出题的人不是我。哎,好,我们继续。啊,这索引我们讲完了。
55:01
然后我们讲一下二级分区啊,我们说的,刚才我们说的,你比如说我这一个表啊,我按照。这个这个呃,哈希的方式,我们指指定一个Sha k,那么我就根据这个字段啊,进行这种一致性哈希,然后呢,呃,在我有多少个分片,我再取取余数,然后把对应的值去打,打到对应的这个我们size上面去啊。然后。你的这个表里面的数据就按会按照你指定的这种。我们说的这种拍戏的方式,当然我们还支持支持list的,我们介绍了吧,你比如range,我支持这种。按照时间啊,呃,这个范围来划分的,也只是类似的这种啊,有点类似于我去说那种枚举类型的,你比如说我可以按照城市,按照省等等来划分。那么划分之后,把这个数据按照你现有的这个规则打散到下面的各个分片里面之后呢。那么这叫一级分区,那已经打散到具体的某一个分片上面的这些数据,在这些数据之上,我们还能进行二次分区,这个二二级分区呀,我们。
56:13
就有点儿类似于买原生买思扣这个分区啊,但是这种分区我们只支持啊两种,就是在一级分区基础之上我再进行分区。那么我们支持和LIST2种。所谓range的这个,他们一般用的可能会比较多一点,你基于时间的这种维度的啊,呃,因为他们有一些用户啊,他们使用这个,过去MYSQL这一块的时候,他用这种基于实现的,像比如流水表啊等等这些,他经常会做这种我们说的呃,分区表,所以说他到这一块他也需要有这个这个需求,所以说我们有这种二级分区。呃,它的一些语语法啊,和原生买思路一样,你看这个大家可能看不太清楚,我跟大家说一下,你比如这张表创建一张表,这个表啊。
57:04
他本身杀的key等于ID,这个它是这个按照ID做哈希,然后做的一级分区,在一级分基础之上,在每一个size上面已经分好的这个size上面这些数据啊,在做二级分区,二级分区是根据什么呢。根据这个here的这个退休年龄,按照年做的这个二级分区啊,然后呢,他有三个这个我们说的呃,分区P0P1P2啊。然后。你比如说我现在这个分区不够了,P0 p1p2 P0是九一年之前的,P11是九六年之前的,那么P2是2001年。那那2003年呢,那没有没有没有,怎么没有,我还要加分区加1P3啊比小于2010年的这个语法和原生满次数一样。然后删除这个这个这个这个分区啊,也是直接照法提神啊,批零就OK了啊,这个啊,我们大概了解一下,其实啊呃,使用的话不是特别广泛,因为这样的话对性能啊,除非你是我们说第一一级分区你要命中,命中之后再命中二级分区,这样那当然你的效率会非常高了,但是有很多情况下,你一级分区你都命中不上二级分区就没有什么用。并且。
58:26
你做它的时候,我们和索引类似。也就是说。你做二级分区,你去做增删改这个表,做操作的时候,实际上对它也是有一需要维护的,所以说这个性能的这个平衡这一块啊,需要我们考虑,所以说不太建议我们做二级分区。起码从T搜索这一块。啊,这些具体的语法我们可能今天没有时间,呃,有小伙伴们条件控制,只有来STEM啊,这些语法我们没有特别详细的时间给大家,就是说一一列举出来,这个你得去看那个开发手册好吧,因为今天的话时间太太有限了。
59:12
然后我们就来看一看这个我们说的分表全局自增的这个算了啊。啊,你比如说我们说买思Q这一块,它这个体系有这种全局自增对吧,那那这个全局自增,如果是原生买,我们这这个全局自增啊,过去实际上是记录在这个内存里面。呃,然后呢,它会保存在你上上create table,然后你会看到它那个表结构里面会写着这个值是吧。呃,据说是8.0或者更高版本以后啊,它会把这个自增的值啊,放在这个应该是锐度里面去了。就是说你不管重启也好,不重启也好,我基本上我这个自增值,我是能够保证连续这种单调递增的。
60:03
但是像这种情况,那么我如果是这种分布式的这种数据库系统,那那你肯定就不能用这种方式。为什么不能用呢?那就说白了,你分布式系统的话,我们可以看一下。你前端你proxy,你应用都要连到proxy,那你后端实际上你是你是多个set。比如都是一主两层。那你这个时候,如果你前端去写入。你连到第一个pro的时候,你你你你去对这某一个表,比如T这个表。去写入数据,你比如说有一个自增了,那你是从因为这个表里面,你这个自增的话,它。他这个表你插入数据的话,他要根据你的这个我们说的分片键来算,究竟是把这行数据存入到这个这个side还是下一个side。
61:06
那你这个自增值是从这儿取呢,还是从这取呢?所以说这样的话,如果说你到两个便利这两个,然后最后就算出一自增值,然后再去插入,那效率太低了,我们是怎么做的呢?我们是把这个自增值放在这个CK里。放到CK里面之后啊,你比如说我这个表T1啊,它有一个子增值,那这个时候我第一次对这个T进行操作的时候,我这个比如说这个是pro。PRO1啊,Pro就是四一啊,这是二。这是三。那实际上我这一呀,我会从它里面取一段,你比如一到2000是它的死增值。那我插入的时候,实际上插入题到这个自中的时候,我1234这样排。但是问题是这个同时可能这个PROXY2也对这个题进行操作。
62:00
那他也会从这个JK里面。去取一段值。取代值是多少呢?是2001。到4000。那他操作的话,他就是对这个表里面,你看会发现他是从二零零一开始,020304这样来的,那PRO3呢,如果他也对T操作呢,它的取的值是4001。到6000。啊,然后呢,这样的话,我只从他这取取一段,然后就缓存在我这了,那你对题表过来之后,我就在本地啊,我取一个,然后就直接就操作了,这样性能会非常好。这个总体来看它也是递增的。但有一个问题是。它中间会有这个,因为你这插入的时候是,如果说你没有插满之前呀,他到这个你插,比如插到。2100多了。
63:01
那实际上你到这个不是不是2100多,是是1000多了,那实际上你你差到1001的时候,你到1001到这个2000,这有这个,这个中间是没有被覆盖的啊,所以说你不能保证这种完整的单调底层,你会发现它中间是有这个空洞,类似于空洞的啊,所以说我们只保证它唯一单唯一,呃,然后是递增的,但是不表保证它绝对的这种单调递增的,所以这点我们需要注意一下。还有一个就是我们说的那个sequence这个东西,这个sequence东西啊,呃,是我们要兼容这个Oracle Oracle这块sequence实际上类似也是从CK里面去取值的。这是全局自增这一块。然后还有一个叫透传circle。什么叫透传色口呢?实际上你看我们刚才画的这个,你比如说我前proxy。后边我们是具体的数据节点,一个一个的set,每个set里面是一主多从的这种,这个我画的这个圆,就大家认为就是一个DB的服务啊,就是买得起的一个DB服务。
64:09
这里面也是一组两从啊,你比如说现在我实际上这时候到了我们这个第一个pro这一块,我们说了,到了他这,他要做词法分析,语法分析,要做S后的改写,要判断你是不是分布式事物,然后呢。根据你的SHA2的K有没有SHK,如果没有12K,我就把它下下推到所有的side,如果有10K,我通过10K我就可以计算出它是。应该到具体的这个size,我就到指定的赛里面去,但是有一种情况。我不想让。Proxy,帮我去。做这个分析,我只想让我这条circle到指定的set上面去查询,我就想到第一个set上面去查询。我不需要你帮我分析,你就把这条搜索给我扔过去,去执行,执行完了把结果给你返回给我,那这时候我们就用到的。
65:07
这种透传功能啊,你比如说这个是我们的。前面是S冒号,这是我们的是这个set的这个ID,如果是比如说我现在我是一个分布式的这个实例,我里面有两个size,那它就会有两个size是不一样的,有四个size,这四个size值不一样,你想要去查哪个赛的,你就把这个。这个set的这个ID写写上,那我要查两个呢,你就逗号来写第二个啊,注意一下就行,这是我们T搜狗它里面的一些特殊的一些功能啊,和大家就是介绍一下。还有一些,你比如说你看这个下面就是我如果两个赛它是简写了啊,如果有两个set,那这时候呢,你就中间用逗号,如果我想到所有的赛上你全去给我执行一下,那我就这样写says好吧。
66:04
那如果说把circlel语句发到S对应的site中执行啊,像这些,还有像这些,你比如说我是想执行上status啊,查看site的信息的时候,你前面要这样。但是这些的话,如果你们没有做实际操作的话,没有环境,可能讲起来就比较枯燥了,所以说今天可能有小伙伴就觉得你讲这些没有什么意义,那还不如给我们讲讲考点呢,对吧,但是考点这个我今天还真。因为我们这个准备没按照你的考点来准备啊。然后是分布式实例的关联查询,这个我们需要注意一下。这个分布式就是首先我们TC这个,我们说的这个,今天我们重点讲的这个分布式实例,它的一些操作。其中有很重要的就是关联查询,关联查询是任何一个数据库你都都都都都躲不掉的,对吧,那么这时候实际上我们对于这些思Q语句是没有限制的,为什么没有限制的。
67:09
就是你多复杂的领域,到了我TQ这一块都是可以查询的。这个是如何做到的呢?实际上我们一会儿可以讲一下,就是。但是。都能查不代表你效率都高啊,对吧,那么。你比如说效率最高的是什么呢。就是我们说的,要把这个色尽量要下推,下推到DB节点去执行,执行完成之后你返回给我结果。这种实际上是性能最好的一种,并且在下推的过程中,最好这个威尔条件里面,或者说做两表关联的时候,还有这个Sha t。有这个keep可以知道指定的set,这样效率更高。这是一种。就一定要做这种下推。
68:01
那么你比如说12K相同的多表关联查询相同。呃,你比如照音操作啊,10K相就是两个表做照音,那么SK如果相同意味着什么呢?我们想。你这个表,你不管你这个沙名字叫什么,那你的值都是通过这个值做一致性,哈希在与现有的这个分片做这个,呃,现有的这个分片做做做做取余数,然后把这个值打到对应的这个我们说的这个节点,那你只要12K相同,那是不是就意味着你这一行数据这两个表的这一这这这个做这这这个数据一定在同一个size上面去。那这时候你这个时候就可以做下推了。因为你你你哪怕你有两个塞子。他们俩只要是相同刹的相同,那一定可以到这个指定的size上面去。这是第一种。
69:00
还有一种什么单表关联,我们就刚才最开始给大家介绍单表都在第一个时那个赛上面,他怎么做关联查询,也是在第一个赛道,他不需要跨赛。所以说他这一块也是不受影响。然后就是分片表与广播表的,因为广播表我们介绍了是吧,它的特点就是每一个在的上面都有这么这个表的一份全量的数据。你有这个表的全量的数据,那么。你你你有这个表的这个全量数据,那这个时候呢,如果说其他的表和你做这种关联查询,那你本地就有啊,我也不需要花三。还有就是子查询,子查询带有share key的这种啊,像像像这种的也是可以的。那么什么样的这个,我们说不能通过这个这个这个。嗯。就是你什么样的so不能下推。
70:00
不能下推,我们这里面又是怎么处理的啊,我们可以接着看一下。就是分布式实例当中,对于不能满足这种我们说下推的这种方式的搜狗啊。呃,由于需要这种做跨节点的数据交互啊,性能会差一些。形成会差。但是对circleq这个这个执行是没有没有没有什么影响啊,你比如说我们说实际上来讲,你比如刹车K不等的这种情况,那这时候不能做下推,不能做下推是怎么样呢?我比如说我前端是proxy,我后边我比如说我是具体的side。我具体的赛里里里面呢,我不能下推,不能下推我们知道啊,我这个我这个pro,我们讲架构的时候应该讲了,它相当于一个。呃,我们知道买买soq,它分这个搜索层和那个存储引擎层,Soq层有那个,呃。我们说的连接器啊,分析器优化器执行器对吧,其实他目前我们看它主要起到这个。
71:07
连接器和分析器的作用。他他分析完了,就把这个对应磁扣要做到下推,你去给我执行,那你执行不了的情况下,实际上我本地啊,有一个这个嵌入式的一个DB服务,那这个时候我执行不了,那没办法,我把你的数据拉取到我本地来。就多个分片,我不能做下推,那把你们这个数据,我需要的数据我就拉取到我本地,在我本地做这种聚合啊,做这种我们说的这种关联这种操作,然后呢,在这里面把结构机取出来,再给前端的应用啊,这样的话就受限于你底层拉取过来的数据是多多少了。你拉取过这些数据,如果多的情况下。那这个时候实际上你带宽呀,IO啊,包括等等这些,包括你执行这个拉取还要有一个过程,那这时候单比事物的时长可能就会就会要长一些,呃,我也就是我们说的性能可能会差一些啊,这个是我们需要要注意的。
72:08
我们一般来讲尽量要把这个circleq要下推啊,不要把这个结果集取到我本地啊,取到我本地的话,虽然在这在本地你数据真取过来,但我这本地做关联查询那也是一样,但问题是取的过程你要把这个数据啊再再拉取过来呀,这个过程有时候会比较耗时,比你这个执行还要耗时,那你这个单笔的这个交易的这个事物啊。这这这个时长,可能你比如说如果在这里面做做这种关联,可能你也就几十个毫秒,那你这个这个一拉取的过程,可能就就要几个秒,这个这个这个量级了,所以说这个时候我们要尽量避免。这是我们说的复杂的这种关联查询。然后开发规范里边,我们说那个那个所有的使用这一块啊,呃,这些实际上我们不管是你集中式的实力还是分布实力都需要的,你比如说我是分布式实力,你分布式实力啊,绝大部分场景你都是要下推的,对不对。
73:15
你把so下推到下面的这些具体的分片,这些分片你可以把它理解成每一个分片就是一个集中式的一个。一主多从的这么一个环境。你到他这里面去执行的话,你也要遵守这个单机MYSQL一些优化的这个这个这个我们说的一些建议啊。首先你要避免全面扫描啊。全面扫描的话,这个是是非常糟糕的情况啊,一定要让他走索引啊。你要全秒扫描,如果是大表的话。那那那有有有很拿这个这个执行效率你比,因为我们是那个所谓的这个这个这个。B加数的这个,如果你要是说走B加数,你也就两从根节点到到叶子节点,你也就两两跳三跳是四跳,那那就可以找到对应的值了,那你如果要是全部走这个全表扫的话。
74:11
那他这个数据页,你比如说要有。要有几千万行的数据,那你要是这样扫的话,那那这个执行效率那就就就就太糟糕了,呃,然后避免类型转换,避免类型转换这个我们知道,就是你V条件里面两个列做这种关联查询的时候啊,如果是类型不一致,那这时候即使有,所以也是用不到,所以像这些呀。嗯,这个买这个通用的啊,甚至一些其他的库也有类似的问题。还有就是这种组合索引,我们要注意这种最左匹配的原则,你比如说这个组合索引里面,如果说这个索引ABC有这么一个组合索引,那这时候你位置条件里面如果只有B和C,我们知道肯定用不到索引是不是?
75:00
所以说如果有只有A和B呢,那我就可以用到部分,所以像这些的话,我们不细讲,只是给大家。就是跟大家就是简单的聊一下,因为很多我们的这个小伙伴肯定对这些非常熟悉啊。然后合理使用像这个for in单词的单词等等,这些只是合理使用,注意啊,我们不建议你去使用啊,为什么呢?我们建议你还是把你的SQ交给这个。MY的它的这个优化器啊,因为啊,你的这个数据量是不断的发生变化。那这时候。这个优化器的选择执行计划是根据你这个统计信息的,这个统计信息也是不断发生变化啊。所以说你现在你指定了一个false index的,指定了一个索引,在未来数据发生变化以后,它不一定是最合适的啊,所以说我们建议还是交给这个买SQL的优化器来来进行,那什么时候合理使用它呢?你比如我正在促销呢,我系统正在搞大促搞活动,这时候有一条circle他没有。
76:16
按照我的这个指定,就他有索引,他没有走正确的这个索引,像这种情况,我可以临时的做SQ的这种改写,然后呢,指定一个索引啊。然后大促过了之后,我们建议你改回来,你还让优化去去选择,选错索引的场景,肯定就是这个统计信息收集不及时,那么你过后可以重新收集一下统计信息啊。但是这些呀,都是一些非常基础的啊,因为我们线上的小伙伴,我们可能就是说对于数据库的掌握情况,肯定也是因为有些可能我从事的就是这相关的工作,可能有些可能我我我我以前没没有从事相关的工作,甚至可能有一些小伙伴可能还是还是呃学生我没有工作过啊,所以说我们也不能讲的。
77:10
所以说我们选这个内容的时候,有很多都是,呃,相对来讲就是比较浅一些,可能要带大家过一下。但相对来讲,今天晚上的内容啊,相对也会比较枯燥一些。然后开发规范里面,我们看select查询语语where条件啊,这里面我们列举的这些呀,其实啊,说白了我们是,呃,集中式和分布式可能有有一些通用,我们刚才说了,你这个你这个分布式实际上到底层去执行的时候还是。还是到具体的这个DB节点去执行的啊。所以说你比如说where条件子句多使用等值这种操作服务啊,少使用非等值的。你因为这个时候,你比如说你要是一个等于和一个不等于,那可不一样,比如说我位置条件里面有一列,这一列呢,我这个比如说name name等于什么,那你如果要是你是。
78:11
和不等于什么。这个优化器他要进行判断的,他如果发现你这个回表次数过多的情况下,你比如说你不等于什么,他发现诶虽然有索引,但是你这个不等于的太多了,那我这每一次我都要回表,比如说你前面取的列比较多,每一次我都要回表,那这时候他他他。他是不会给你走这个索引的,他就直接给你,他认为你这样算回表次数过多,那我还不如直接扫全表呢,那他直接给你全表扫啊,所以说你这个多使用等值的这种操作。还有像like子句啊,我们知道威尔条件里面,比如说name,我今天要查我们现场的小伙伴有姓刘的,那我刘后面加100分号,那我肯定能查出来,这就最多匹配对吧?那如果我想查什么什么强呢,比如说我想查张强,李强,什么王强,那就是百分号在前边,后面是强,那你这时候like这个,那它就是它就无法。
79:13
用到索引啊,这是最多匹配啊,即使有索引为尔子句匹配的行数不要超过表的30%,否则效率还是很低,它有的时候不是不是效率低,它是。你匹配的行数如果多,这个优化器它会自己做判断的,就是他有时候你有索引,它判断回表啊等等这些这些回表次数过多,他就不会使用索引,他宁可走全秒扫啊。然后像这种哦,这种条件的话呀,你比如左右这个哦,你必须有一个必须所有的这个哦,左右的这个这个条件都有索引,它有可能用到索引,否则你你前面有一个有索引,但是你加了这么一个,后边又有一个条件,那这时候它也不可索引,像这些我们都要注意一下。
80:00
啊,不同的字段使用UN啊来代替啊。然后尽量使用where子句代替having这些词句啊,这些都是我们一些我们说。明天是吃兔嘛,吃兔有什么优点,明天是这个管控平台,我们也将吃兔运营管理平台啊,这些我们一会儿有一个交流时间啊,我们一会儿再。然后病变尽量避免使用子查询等等啊啊,当然了,8.0以后对子查询都是做了一些优化,它会自动的把你给它转换成这种连接的方式啊,我们叫半连接啊,这些避免在数据库层面做算术运算,让应用层来做啊。然后想避免直接使用select星啊,直接列出需要查询的字段啊。呃,你比如谁来听的话,一般来讲,你比如说后期我要加字段啊,这就比较麻烦了,对不对,所以说哪怕我要取这个表里面的全部的字段。那这时候我也要把那个字段的名字给他写在后面啊。后期我们维护什么呢,可能更方便。
81:02
避免使用。用。而不是union啊。应该说是呃使用呃就不不使用这个union,为什么呢?因为他要排序,还要这个我们说的这个呃就是做做做做这种排序啊,所以说呃去重和排序,所以说这些的话,那你如果数据量大的话,对效率也是影响比较大的。像一些基本的原则就是尽量使用,所以尽量简单,尽量匹配更少,反正这些都是大白话,我们可能读读到这些东西我们就会知道。然后一个表的out by和group by的组合都不应该超过三种,否则从业务逻辑考虑进行优化,或者呃,分成多张表。像这种情况下,一般来讲的话,我们买SQ这个体系,就不建议你去写特别复杂的circle。Where子句尽量使用主键。
82:00
那你为什么说尽量使用主键呢?这就是我们今天给大家讲的。主使用主件有一个好处就最好就是我不需要再回表了,我主键,我主键这个B叉必加数的话,我这个叶子节点,我存有这个整行数据,我我也不需要回表对不对,所以说嗯,还有一个就是分布式系统这一块,我一般主件来讲,我都是start key,那这时候呢,我这个如果用主键的话,我既不需要回表,我通过SHK我还能知道我。要去到对应的哪一个分片,我不需要把这个S下推到所有的我们说的这个呃,Set上面去啊。然后呢,我们先。暂停一下,然后我们要进行今天最后一次抽奖。然后大家啊准备好,然后这是第三次抽奖。
83:27
看一看咱们今天晚上的运气啊,这是最后一次了啊。我们还是倒计时20秒。OK,那我们就是今天的抽奖结束啊。
84:02
然后咱们再继续看一看啊。呃,我们还要加快一些速度了啊。我们要加快一些速度,要不然今天可能,呃,除了讲这个的话。然后开发规范。这一块,然后呢,呃,我们说关联照查询这个啊,呃,一个是大表,建议不多于两张以上表的照,就是说还是买SQ,这个体系对于多表关联查询本身支持并不好,就像我们说的哈希照应这种方式也是8.0以后才加的,而且不是特别成熟,所以说我们尽量不要做这种多表关联查询,不管你是集中式的还是分布式。然后照样之间的列上要求要有,所以呃,你比如说一般我们买SQ用的比较多的就是循循环签到里有一个驱动表,有一个被驱动表,那么这个关联列上这个被驱动表一定要有索引,否则的话效率非常差。
85:00
因为它是这样,它从你驱动表里取出一一行几数据,然后呢,取出你的对应的关联列,然后它会去便利去去到你那个被驱动表上逐一的去比对啊。然后他再从这个驱动表上取出第二行,再到你这个被驱动表上去逐一的去去去去便利,那如果你被驱动表上这个这个对应的这个列没有索引,那你每一次都要走这种,我们说全面扫这种,那这个性能就太差了。然后呢,对于小表来讲啊,呃,如果配置信息类的允许超过两张表以上的照,当然这个也是根据你实际的情况来的啊。然后分布式实例中大表关联查询尽量走下推,就是说我们尽量这种大表关联尽量不要采用说我把它那个数据拉取到我这个pro这一块来进行的,如果你比数据量多的情况下,你拉取的数据量比较大。
86:00
这个就比较耗时了。然后这还有一些是我们说的DML这种规范啊,我们说避免大事物对吧,大事物也会影响我们的这个,你比如说有一些锁呀,有一些比如说我们主从复制这个,呃,都会受到大事物的影响啊。然后数据的这种删除更新,注意啊,我们V条件里面也尽量带有这个我们说的,呃,索引呢,主件呀,如果是分布式的话,也要带这种s key,它同样能起到查询的这个相对应的功能。然后数据的写入啊,要多条circle ins色的要合并成一条,为什么呢?就是说你不要每写一条我提交一次,每写一条提交一次,这样的话影响效率,我可能要合并多条,然后我提交一次,这样的话执行的效率会高,词汇的执行效率,你比如说我如果是分布式的情况下,我不管是。增删改查,我都尽量带上start key,这样的话我就可以把这个对应的circle发到指定的这个set,这是我们今天晚上一直在重复的。
87:08
然后还有一些不确定的函数啊,就是你像这些in delete update语句中不要使用不确定的函数啊,但是这些的话,目前的话,如果你是lo是肉格式的话还好啊。然后SQL语句安全啊,这些禁止的update语句中用逗号啊,像这些写上and。大量数据删除的时候我们要注意啊。你删除整表的时候,我们肯定用窗K,但是注意这就不能回滚啊,然后还有一种就是删除的时候我们要注意尽量做到根据主见批量删除,你别delete,嗯。位置条件里面直接删几百万,这样的话很容易造成普通延迟的啊,所以说这个我们也要注意。然后是DDLDDL,也就说我们比如说这个表加索引,比如说我大表加字段,像这种我们只是给大家介绍一下,因为如果你是学过数据库,你就知道买这个体系下,你如果是大点加字段是要。
88:09
就是锁表了,锁表的话,这对这个表的任何操作,增删改的操作,你都都都不能不能进行了,那这这这个业务可能就要中断了,所以说我们会通过一些工具,你比如说PT工具,或者是我们说的那个get up get up那个OS工具啊,然后我们通过这种第三方的工具来进行这种加字段啊,大表加字段就不会有这个索引,那明天我们会带着大家介绍,我这个赤兔上面也有一个数据库DDL这一块,你在这一块对这个大表进行这种DDL操作呀,是不会锁表的啊,这个我明天会详细的跟大家介绍一下。然后呢,还有一些分布式实力的限制,你比如说不支持自定义函数啊,事件呀,表空间等等这些主要是说。如果你比如存储过程啊,可一致性非常差,处罚器效率等等。
89:04
我们分布式实力或支持的这些为什么不支持?主要就是从性能角度考虑。分布式实力我们不支持,集中式实力我们支持,但是我们也不建议你去使用这些啊。就你比如说像什么自建分区啊,外建啊等等啊,你跟这个集中式你肯定支持啊,你完全兼容这个原生的MYSQL嘛,但是我们也不建议你去使用,因为它极其影响性能啊。然后还有一些是大特性的限制啊,这些我们说的也是不支持视图啊,存储过程啊,这个刚才我们也介绍了这些,我们了解一下,不支持外建自建分区啊,这是分布式实力限制。还有一些小语法,你比如说像那种create table,然后创建一个表,然后直接select星,从另一个表里面拉数据,像这些不支持,这些不支持没有关系,我们只要把它换一下,比如我create table like某个表,然后再写第二句insert into这种方式,我把这一句我给它拆成两句啊,我就可以了啊。
90:15
像这些虽然我不支持,但是我有其他的方式,像不支持这种临时表啊,像这种不支持像这种,呃,我们说的一些这这这这这种语句啊。这些的话,如果大家想了解呀,我们可以登录那个我们的那个官网,找到T测后,它有那个在线的那个开发的那个指南在里面,我们可以更详细的去了解啊,如果你当你真正用到T操的时候,我们再去找到那个开发指南,然后呢,再去去就是呃,详细的去去去看去了解,因为现在的话,我只是给大家介绍一下,你现在的话给大家按照这个逐条的来进行这种解读啊。呃,意义好像不大,因为你很快就忘掉了,对吧,连我都记不住,所以说这些的话有一些限制,我们就不逐一的给大家做这种介绍。
91:10
然后还有一些小语法,小语小语法这种限制啊,呃,这些我们就不过多的给大家解读了,我们说一点吧,说一点就是说我。这个T啊,创建这个用户的时候,我们是不能通过这种create这些,包括那个那个什么。Ground这种方式授权的,你必须在吃出运营管理平台上来进行,为什么呢?因为啊,你在那个直接去创建的话,你这些这些创建用户这些信息写不到JK里面去啊。所以说我们必须在这个我们说这个这个这个车图运营管理平台上创建,像这些还有一些你比如flash啊,像这个recet呀等等shutdown这些呃,系统级的命令也是不可以执行的,呃,你必须通过赤图运营管理平台来进行啊,当然这些的话,我们只有实际使用的时候,你才会能更加深理解,现在讲就比较枯燥,所以说我们也不给大家呃详细的展开了。
92:17
呃,然后呢,这个就是我们。呃,今天晚上给大家的一个分享。然后咱们看小伙伴们有没有什么具体的问题啊,今天可能这个时间上后面的话,呃,尤其这个内容比较抽象,也就没有讲的特别细啊,也也是由于时间关系啊,所以说我我我我一直想就是看这个时间,然后看看小伙伴们还有什么有有没有什么问题。我们可以简单的再进行一个交流。嗯。然后呃,提前跟大家说一下,就是说呃有小伙伴说明天是赤兔吗?赤兔有什么优点,这个明天是这个管控平台,我们叫赤兔运营管理平台,会和大家详细介绍这个平台,然后呢,呃,这个平台的优点我们也是明天啊,会结合着我们实际的这个环境给大家逐一的展示啊。呃也希望大家到时候呃准时的来登录到我们的直播间,我们一起来交流。
93:24
没卖关子,有时候有小朋友小伙伴说卖关子了,嗯。今天我感觉啊,今天讲的这个相对来讲比较抽象,大家可能确实兴致不高,也没有没有多少小伙伴问问题,那既然这样的话,那我们今天直播也就到这里结束了啊,最后呢,小伙伴们呢,一定记得啊呃,大家要签到啊,然后呃,我们今天的直播啊就到这里啊,我们明天晚上继续呃来进行交流。
我来说两句