第二讲-用 PolarDB - X 开发应用(三)|学习笔记

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 快速学习第二讲-用 PolarDB - X 开发应用(三)

开发者学堂课程【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 的架构,如下图所示,

image.png

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 实例。

通过计算可以很精确的算出配连接池时连接数应如何写。下图是连接池基本的参数,

image.png

根据参数查看意思,明确上方的公式后就会明确如何填写连接池的数值。

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分区。

image.pngimage.png

使用方便之外, AUTO 模式有更多的功能,比如可以手动的指定分区以及分区函数,所以 AUTO 模式支持的函数有 HASH / RANGE / LIST /等多种分区, DRDS 模式仅支持使用 HASH 策略。此两种方式的路由算法有很大差别,路由算法是指数据按照什么规则分散到层数节点,分散的规则叫做路由算法。DRDS 模式的路由算法采用简单的 HASH 算法,若分区变更,则需要对所有的数据再一次进行 HASH ,造成一系列不必要的性能损耗,数据过大时耗时长,不够灵活。

分区表的默认算法是使用 range 的一致性 HASH 算法,它的好处是若做分区新增时,只改变目标分区附近的一些数据,不需要对所有的数据进行再 HASH ,此方法造成的影响非常小,并且更加灵活。

AUTO 模式核心特性及典型场景,第一个是热点分裂,分布式数据库下会出现热点数据,热点数据的出现会对整个数据分布的性能造成损耗,所有的资源会集中到热点资源中,非热点数据分配不到资源。

针对此种情况, AUTO 模式启用一种解决方案是,将热点数据单独取出,分成一个新的分区,将新的分区移动到一个新的 DN , DN 专门像热点数据提供服务,这样就将热数据与冷数据分开,不影响其它的非热点业务;如放到单独的 DN 上,还不能支撑业务时,则将热点数据进行再一步的分区,将热点数据打散之后均分到其它数据中。第二个是分区调度, AUTO 存在一个更灵活的调度粒度;传统的 DRDS 模式调度是以库为单位,库与分表的位置是强绑定的,比如一张表非常大,某个分库的数据特别大,不管怎么调度, DN 之间都无法做到数据均衡。

image.png

如上图,在 AUTO 模式中,以分区为度进行迁移,举例说明, p 1 数据量非常大需要做一个均衡,将 p 1 进行划分,划分成两个分区, p 1-1和 p 1-2, p 1-1挪到另一个 DN 上,以分区为度,可以有利的解决 DN 之间的数据不均衡问题。

第三个是 TTL ( Time  To  Live ),一些业务随着时间的推移,旧数据是不需要的,比如可以用修改时间进行分区,每隔一个月分一个区,自动过期,此功能就很好的满足业务,按照分区逐个删除。

第四个是 Locality ,更详细的指定数据放在哪里,有一些特殊的业务场景是需要将数据放在特定的 DN 上,通过 Locality 参数将指定的库、某一张逻辑表放入指定的 DN 上,更细粒度的是按照分区进行业务划分。

功能对比,如下图所示,

image.png

性能对比,如下图,

image.png

自动分区会不会因为做了自动的过程,导致性能会有所损耗,所做了实时的对比,在检查的情况下, AUTO 模式数据库与 DRDS 数据库几乎持平,有略微的下降,因为分区表使用的一致性路由算法比哈希取模的路由算法更为复杂。

在 oltp _ read _ only & oltp _ read _ write 场景中,由于这些场景会出现小范围的查询, SQL 的查询条件表达式会比 oltp _ point _ select 复杂,得益于分区表的裁剪优化,整体吞吐比原来提升约33%。

PolarDB - X 支持读写分离,1.0与2.0都支持。

AUTO 模式自动分区满的时候可以手动添加自动分区,表不存在上限,提供一个手段可以看到 DN 的容量。

读写分离不需要第三方插件,只需要在控制板上做一个简单操作,还可以进行读写比例的调节。

如何查看数据热点,存在一个很直观的界面可以观察到数据量的分布以及访问量的分布。

理论上性能与 CN 是成正比的, CN 越多,接收到的请求越多,处理的数据越大。

相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
2月前
|
存储 SQL 安全
应用案例|开源 PolarDB-X 在互联网安全场景的应用实践
中盾集团采用PolarDB-X云原生分布式数据库开源版本,有效解决了大数据量处理、复杂查询以及历史数据维护等难题,实现了业务的高效扩展与优化。
|
4月前
|
存储 Oracle 关系型数据库
关系型数据库Oracle应用场景
【7月更文挑战第5天】
136 3
|
6月前
|
关系型数据库 分布式数据库 数据库
【PolarDB开源】PolarDB资源隔离技术:在多租户环境中的应用与优化
【5月更文挑战第29天】PolarDB,阿里云的云原生数据库,在多租户环境中通过逻辑(Schema/Partition隔离)和物理(分布式存储计算节点)隔离保障数据安全和资源独占。它支持动态资源分配,适应不同租户需求,处理大规模并发,提供租户管理及数据访问控制功能。通过优化资源分配算法、提升事务处理能力和强化监控告警,PolarDB确保性能和稳定性,满足多租户的高效数据库服务需求。
176 1
|
3月前
|
关系型数据库 分布式数据库 数据库
安全可靠的国产自研数据库PolarDB V2.0,让数据库开发像“搭积木”一样简单!
安全可靠的国产自研数据库PolarDB V2.0,让数据库开发像“搭积木”一样简单!
安全可靠的国产自研数据库PolarDB V2.0,让数据库开发像“搭积木”一样简单!
|
2月前
|
存储 物联网 关系型数据库
PolarDB在物联网(IoT)数据存储中的应用探索
【9月更文挑战第6天】随着物联网技术的发展,海量设备数据对实时存储和处理提出了更高要求。传统数据库在扩展性、性能及实时性方面面临挑战。阿里云推出的PolarDB具备高性能、高可靠及高扩展性特点,能有效应对这些挑战。它采用分布式存储架构,支持多副本写入优化、并行查询等技术,确保数据实时写入与查询;多副本存储架构和数据持久化存储机制保证了数据安全;支持动态调整数据库规模,适应设备和数据增长。通过API或SDK接入IoT设备,实现数据实时写入、分布式存储与高效查询,展现出在IoT数据存储领域的巨大潜力。
63 1
|
3月前
|
关系型数据库 分布式数据库 数据库
PolarDB资源隔离技术:在多租户环境中的应用与优化
随着云计算普及,多租户架构助力云服务商提供高效服务。阿里云PolarDB采用独特分布式设计,在多租户环境下确保每个用户数据独立与资源隔离。通过逻辑与物理隔离技术,如Schema和分区,结合分布式存储节点,实现资源独占及安全。此技术不仅保障数据安全,还能动态分配资源,满足高性能需求。通过优化资源分配、增强事务处理及监控机制,进一步提升PolarDB在多租户环境中的表现。
120 4
|
3月前
|
存储 物联网 关系型数据库
PolarDB在物联网(IoT)数据存储中的应用探索
随着物联网技术的发展,海量设备数据对数据库提出实时高效存储处理的新要求。PolarDB作为阿里云的高性能云数据库,展现了其在IoT数据存储领域的潜力。面对IoT数据的规模、实时性和多样性挑战,PolarDB凭借分布式架构,实现了高性能、高可靠性和高扩展性,支持动态扩展和冷热数据分层存储,满足IoT数据实时写入、查询及管理需求,展现出广阔的应用前景。
120 1
|
3月前
|
存储 关系型数据库 大数据
PolarDB 大数据处理能力及其应用场景
【8月更文第27天】随着数据量的爆炸性增长,传统的数据库系统面临着存储和处理大规模数据集的挑战。阿里云的 PolarDB 是一种兼容 MySQL、PostgreSQL 和高度可扩展的关系型数据库服务,它通过其独特的架构设计,能够有效地支持海量数据的存储和查询需求。
88 0
|
4月前
|
关系型数据库 Java 分布式数据库
PolarDB产品使用问题之部署到服务器上的Java应用(以jar包形式运行)无法连接,如何解决
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
4月前
|
Oracle 关系型数据库 数据处理