开发者学堂课程【PolarDB-X 开源系列课程:第二讲-用 PolarDB - X 开发应用(三)】学习笔记与课程紧密联系,让用户快速学习知识
课程地址:https://developer.aliyun.com/learning/course/1032/detail/15141
第二讲-用 PolarDB - X 开发应用(三)
三、 POlarDB - X 最佳实践
Spring Boot 与 WordPress 的演示,框架默认使用 MySQL 来做为数据库进行开发。
在演示中,参照文档进行复制,不需要修改任何的配置,使用 PolarDB - X 非常的简单。
接下来讲解 PolarDB - X 的最佳实践,首先回顾 PolarDB - X 的架构,如下图所示,
PolarDB - X 主要有四个部分组成, CN ( computer note 计算节点)、 DN (data note 数据节点)、 CDC (负责和下游做数据同步)、 GMS (源数据中心), 直接与应用联系的是 CN ,一条 sql 发送过来之后,首先会进入 CN ,CN 会做基础校验,做解析,做优化,将优化后的 sql 发送到 DN ,DN 做数据的执行,数据最终存在在 DN 节点内,它们之间通过 GMS 管理元数据,以上就是 PolarDB - X 的架构。
1.连接池的最佳实践
打开 PolarDB - X . com 的页面,是一个官方文档,首先选到如何选择使用应用端链接池,使用任何一款数据库无论是系统开发或是其它,首先需要做的是配数据库的连接,最主要的是配连接池,以此为契合点进行讲解。之前在配连接池时存在一些经验,根据经验配备一个大概的数值,使用 PolarDB - X 通过一个非常精确的公式来计算需要一个多大的连接池。
PolarDB - X 分为前端连接和后端连接,前端连接是应用到 CN 的连接,后端连接是 CN 到 DN 的连接,用户不需要关注后端连接,只需要关注前端连接,如下所讲解的连接都为前端连接。首先讲解两个公式, QPS / RT 与连接数的关系, QPS 为每秒的查询请求数,以秒为单位; RT 为响应时间,通常以毫秒为单位,中间相差了1000 的倍速, PolarDB - X 是兼容了 MySQL 协议的,请求在单个连接上串行执行,不同连接上的请求是可以并行执行的,由此得到单个连接的 QPS 上限 = 1000 / RT 和 应用访问单个 CN 的 QPS 上限 = 单个连接的 QPS 上限 × 连接数,按照平均 RT 为 5 ms 计算,单个连接的 QPS 上限为200,假设应用预估需要的 QPS 为5000,则至少需要建立250个连接。
连接数有一定的限制, PolarDB - X 收到请求之后,在 CN 内存在网络模块做权限认证,权限通过之后从 CN 的线程池里分配一个线程给连接做一个相应的请求, PolarDB - X 会默认一个1024大小的线程池,如并发查询数量超过线程池大小,后续请求会排队等待,由此可以得到以下公式:应用访问单个 CN 的 QPS 上限=单个连接的 QPS 上限× MIN (连接数,线程池大小)和应用访问数据库的 QPS 上限=单个连接的 QPS 上限× MIN (连接数,线程池大小)× CN 数量。
举例说明:
查询的平均 RT 为10 ms ,理想情况下两节点 CN 能提供多少 QPS ,平均 RT 为10 ms ,则单个连接的 QPS 上限为100.理想情况下( CPU 不成为瓶颈),包含2个 CN 节点的 PolarDB - X 实例默认能够提供的 QPS 上限为100×1024×2=204800.这里需要注意, CN 节点能够同时处理的查询数量与 CN 规格和查询复杂度有关,实际场景下通常不能做到1024个线程池完全并行, QPS 上限会低于204800。
在 CN 规格为16C的 PolarDB - X 实例上压测, CPU 刚好跑满时,某查询的平均 RT 为5ms。仅考虑 CN
节点,支撑40w的 QPS 应当如何选择实例和设置应用端连接池?
平均 RT 为5ms,则单个连接的 QPS 上限为200。应用端连接池大小设置为400000/200=2000可以将额外开销降到最低。保持单个 CN 节点上的并行度不趙过1024,需要两个16C节点构成的32C的 PolarDB - X 实例。
通过计算可以很精确的算出配连接池时连接数应如何写。下图是连接池基本的参数,
根据参数查看意思,明确上方的公式后就会明确如何填写连接池的数值。
2. 透明分布式实践
常见的分布式数据库都需要用户设置分库分表键,手动管理分库分表的规则,因此给用户使用分布式数据库提高了门槛,需要对数据库的数据分布以及每一张表的表结构非常清晰。
PolarDB - X 提供了一个透明分布式的概念,所谓透明分布式,分布式的细节对用户是透明的,用单机数据库的方式来使用,这就是透明分布式的理念,大幅度降低用户使用分布式数据库的门槛。 PolarDB - X 从5.4.13版本开始,新增支持 AUTO 模式的数据库(也称为自动分区数据库),与之对应的老版本就是 DRDS 数据库, DRDS 数据库就是用户设置分库分表键,手动管理分库分表的规则, AUTO 数据库则是只需要建立单表的方式,不需要关注分库分表的问题,因此使用起来更加方便。
如何使用 AUTO模式,首先需要在创建数据库时语法中加一个参数 MODE = “ AUTO ”,就是一个自动分区的库;如果在创建数据库时不指定 MODE 参数的值,默认创建 DRDS 模式的数据库。如用户对两个库非常了解,用户想指定参数,在 AUTO 模式中也可以给用户手动去指定分区键以及分区函数,如下图进行对比,第一张图是 DRDS 数据库的图,所创建出的表是一个单表,表只存在于某一个边上;
第二张图是 AUTO 模式的表,所创建的出的表是一个分区表,默认使用主键进行分区,数据会自动的在不同的 DN 之间均衡的打散,通过 CREATE TABLE 来讲解它的结构, PARTITION BY key (” a “)默认分16分区。
使用方便之外, AUTO 模式有更多的功能,比如可以手动的指定分区以及分区函数,所以 AUTO 模式支持的函数有 HASH / RANGE / LIST /等多种分区, DRDS 模式仅支持使用 HASH 策略。此两种方式的路由算法有很大差别,路由算法是指数据按照什么规则分散到层数节点,分散的规则叫做路由算法。DRDS 模式的路由算法采用简单的 HASH 算法,若分区变更,则需要对所有的数据再一次进行 HASH ,造成一系列不必要的性能损耗,数据过大时耗时长,不够灵活。
分区表的默认算法是使用 range 的一致性 HASH 算法,它的好处是若做分区新增时,只改变目标分区附近的一些数据,不需要对所有的数据进行再 HASH ,此方法造成的影响非常小,并且更加灵活。
AUTO 模式核心特性及典型场景,第一个是热点分裂,分布式数据库下会出现热点数据,热点数据的出现会对整个数据分布的性能造成损耗,所有的资源会集中到热点资源中,非热点数据分配不到资源。
针对此种情况, AUTO 模式启用一种解决方案是,将热点数据单独取出,分成一个新的分区,将新的分区移动到一个新的 DN , DN 专门像热点数据提供服务,这样就将热数据与冷数据分开,不影响其它的非热点业务;如放到单独的 DN 上,还不能支撑业务时,则将热点数据进行再一步的分区,将热点数据打散之后均分到其它数据中。第二个是分区调度, AUTO 存在一个更灵活的调度粒度;传统的 DRDS 模式调度是以库为单位,库与分表的位置是强绑定的,比如一张表非常大,某个分库的数据特别大,不管怎么调度, DN 之间都无法做到数据均衡。
如上图,在 AUTO 模式中,以分区为度进行迁移,举例说明, p 1 数据量非常大需要做一个均衡,将 p 1 进行划分,划分成两个分区, p 1-1和 p 1-2, p 1-1挪到另一个 DN 上,以分区为度,可以有利的解决 DN 之间的数据不均衡问题。
第三个是 TTL ( Time To Live ),一些业务随着时间的推移,旧数据是不需要的,比如可以用修改时间进行分区,每隔一个月分一个区,自动过期,此功能就很好的满足业务,按照分区逐个删除。
第四个是 Locality ,更详细的指定数据放在哪里,有一些特殊的业务场景是需要将数据放在特定的 DN 上,通过 Locality 参数将指定的库、某一张逻辑表放入指定的 DN 上,更细粒度的是按照分区进行业务划分。
功能对比,如下图所示,
性能对比,如下图,
自动分区会不会因为做了自动的过程,导致性能会有所损耗,所做了实时的对比,在检查的情况下, AUTO 模式数据库与 DRDS 数据库几乎持平,有略微的下降,因为分区表使用的一致性路由算法比哈希取模的路由算法更为复杂。
在 oltp _ read _ only & oltp _ read _ write 场景中,由于这些场景会出现小范围的查询, SQL 的查询条件表达式会比 oltp _ point _ select 复杂,得益于分区表的裁剪优化,整体吞吐比原来提升约33%。
PolarDB - X 支持读写分离,1.0与2.0都支持。
AUTO 模式自动分区满的时候可以手动添加自动分区,表不存在上限,提供一个手段可以看到 DN 的容量。
读写分离不需要第三方插件,只需要在控制板上做一个简单操作,还可以进行读写比例的调节。
如何查看数据热点,存在一个很直观的界面可以观察到数据量的分布以及访问量的分布。
理论上性能与 CN 是成正比的, CN 越多,接收到的请求越多,处理的数据越大。