开发者学堂课程【关系型数据库 ACP 认证课程：【视频】-RDS-云关系行数据库的解析与实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14620
【视频】PolarDB-云原生关系型数据库的解析与实践
（3）历史库引擎 X-Engine
X-Engine 是阿里自研的一个存储引擎，其目标是面向大规模的海量数据存储，提供一定高并发的一些事务处理能力，同时最重要的是能够降低存储成本。
首先，X-Engine 的热数据层和数据更新都是适用内存存储的，使用了一些内存数据库的技术。第二点是 X-Engine 做了流水线的事务处理机制，可以把整个受处理的几个阶段并行起来通过，然后把整个吞吐提升上去。第三点是 X-Engine 可以把访问频度低的数据逐渐淘汰，或者是合并到一个持久化的存储存储层中，然后结合多层次的存储设备，最好的是 NVM 非易失性内存， SSD 、HDD 一类的普通硬盘进行存储，因为 LSM TREE是一个分层的架构，特别适合冷热数据区分的一个分层存储，另外对性能影响较大的 Compaction 过程做了很大的优化， Compaction 是 X-Engine 本身的一个流程，需要把这个分层的数据去做 merge ，但我们做的优化可以把整个 X-Engine 的数据存储力度做一个拆分，尽量的去利用数据更新、热点较为集中，然后再合并，合并过程中复用数据以及去精细化的控制， X-Engine 处理的这个形状最核心的其实就是为了减少 Io 和计算代价去缓解合并过程中的写空间放大的问题。另外还使用更细力度的访问控制和缓存机制，去优化读的性能。
（4）并行查询
● 有效利用多核 CPU ，大幅提升长査询的查询性能
● 并行查询支持大部分 SELECT 语句
● 适用轻分析类业务、离线分析场景等
主要适用于大表查询，多表链接计算量比较大的SELECT语句，适合场景:一个场景是轻分析报表类的查询，它SQL相对复杂，相比在线tp业务也会多耗时间，但通过并行查询可以加速单次查询的效率；另外一个场景是有些只读节点系统资源相对空闲，并行查询可以利用更多的系统资源，如果有充足的CPU，充足的内存，就可以使用并行查询，把整个资源利用率和查询效率都提升起来。
第三块是在离线混合的场景，主要是隔离的场景对应上图：PolarDB上不同业务去使用不同的连接地址，底层连接到不同的实际的物理数据库节点上，互相就可以不影响。
例如：可以把某个单节点去开启并行查询执行OLTP类型的请求，所有这些请求就只会通过单节点的地址下对应的只读节点去访问，相当于复杂且耗时的SQL就不会影响核心业务。
并行查询的关键是利用多核的CPU并行处理能力，当查询数量达到一定阈值之后，阈值会提前通过某些算法进行预估，会自动启用并行查询框架，但是可以提前定义好并行查询可以用多少个线程数，对于相关的请求存储层就会把数据分到不同的线程上面，把多个线程做并行计算，最后把结果流水线汇总到总线程，总线程做多个流水线的归并返回给用户可以提高查询效率。有一些分析型场景下测试会有10倍的性能提升。
My SQL是一个SQL请求只会用一个线程，但是PolarDB并行查询上相当于在内核里孵化多个线程充分把资源利用起来，这个功能在开源的 My SQL或者RDS是没有办法实现的。
三、操作
到控制台之后，在正常情况下，如果没有购买的话，该界面应为空，这时要新购一个 PolarDB 集群，创建新的集群。
这里有不同的类型，比较常见的就是包年、包月以及按量付费，还有两个比较特别的是计算包和存储包，因为 PolarDB 是一个存储计算分离的架构，非常方便的就可以实现计算资源以及计算的计费和存储计费去做分离，他们是独立的，相当于如果做包年包月，计算资源和存储资源都是预购好的，按量付费全都不预购，但是整个的价格会没有优惠，是计算包和存储包包年、包月和按量付费的一个中间状态，比如买了计算包，就是先预购了计算的资源，这样计算资源省一点，但是存储资源可能不知道要花多少，可能有段时间非常多，突然优惠变少，这样存储资源就是按量付费的，如果买了存储包，计算资源按量付费，存储包就可以预购好，相当于存储包是包年包月这样的一个模式，所以这两个其实是一个中间状态。
下面有选择地域，创建方式包括支持从集群主集群，这两个其实是 GDN 的一个概念，也支持从 RDS 去做迁移。一般情况下， PolarDB 就是这五种模式。
系列化包括集群版，有多种架构集群版、历史集群版以及单节点的版本，常见的是买集群版。假设买8.0，可以选节点规格，最小的是2核，然后最大是88核和710G的，点立即购买即可。
PC开头的就是其 PolarDB 的一个集群ID，点击这个集群ID进去就可以看到 PolarDB 控制台的主界面。
首先账号管理，新购买需要创建账号。 PolarDB 支持两种账号的模式，分别是高权限账号和普通账号，高权限账号只允许创建一个，普通账号可以支持创建多个。填写账号名，选择高权限账号和普通账号，还可以授权账号用哪些数据库。
数据库管理允许在控制台上去创建一个数据库，创建 test 1，推荐设置字符集就是 UTF8 或 MP4 ，因为默认最常见的，也可以支持特殊字符，如果用其他，可能就会遇到一些 bug ，特别是中文特殊字符。创建数据库可以提前设好要授权在哪个账号，也可以去指定的权限，这些权限创建之后也可以再去修改。
创建数据库后，可以去登录数据库，登陆数据库的话有两种方式，一种是你可以 PolarDB 给的连接串；在控制台上也可以去直接用账号密码登录，数据库是和那个 RDS 是一样的。
例如用已有的账号登录，数据库已经建立好了，就可以做建表的操作。
参数配置：参数支持修改，如果是 PolarDB 基本上都会有文档，可以去参考 PolarDB 官方的一个文档。修改参数的话，有两种类型。一种参数是临时表，比如说像临时表这样的一个参数，是不需要重启的，可以直接去修改，改完以后就实施应用，也不会影响业务，临时表大小的参数，很多人在测试的时候可能会遇到临时表不够大的问题，就可以修改这些参数，重要的是确定以后并不能马上生效，他有一个提交修改的流程，可以一次修改多个参数。
临时表参数不涉及重启实例，较简单。
PolarDB也提供开启Binlog的参数，和普通的不一样有个单独的名字：polar_log_bin。
这个参数是polar是否开启Binlog参数默认是OFF。PolarDB不依赖Binlog，可以把OFF改为ON就相当于PolarDB也开启了Binlog。对PolarDB的影响是它会单独生成一份Binlog数据，这个数据也是存储在共享存储上的，就可以通过像My SQL一样的把Binlog拿走，去做各种各样的分析。
下图这里有表示开启Binlog是要重启，所以涉及到修改这类参数会有切换的行为。
性能监控：把一些常见的My SQL上的指标给抽出来，作为运维人员，有可能会发现近期的db变差或者有什么瓶颈就可以通过性能监控排查出来。
集群维度的信息，例如QPS、TPS、CPU资源的使用率，下图可以看出是有两个只读节点和主节点，这些资源都是有三个节点，每个资源的CPU使用率都能看到。
还包括数据代理的监控，计算节点的监控，比较高级的监控。
