开发者学堂课程【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 来讲解它的结构， ＰＡＲＴＩＴＩＯＮ ＢＹ ｋｅｙ （” ａ “）默认分１６分区。
使用方便之外， AUTO 模式有更多的功能，比如可以手动的指定分区以及分区函数，所以 AUTO 模式支持的函数有 HASH ／ ＲＡＮＧＥ ／ ＬＩＳＴ ／等多种分区， DRDS 模式仅支持使用 HASH 策略。此两种方式的路由算法有很大差别，路由算法是指数据按照什么规则分散到层数节点，分散的规则叫做路由算法。DRDS 模式的路由算法采用简单的 HASH 算法，若分区变更，则需要对所有的数据再一次进行 HASH ，造成一系列不必要的性能损耗，数据过大时耗时长，不够灵活。
分区表的默认算法是使用 ｒａｎｇｅ 的一致性 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 越多，接收到的请求越多，处理的数据越大。
