POLARDB的存储可以做到按照使用量来收费，真正做到使用多少就收多少钱，计费周期是一小时
在我们的控制台上，有五种空间统计，分别是磁盘空间使用量，数据空间使用量，日志空间使用量，临时空间使用量和系统文件空间使用量。

磁盘空间使用量是后四者之和，数据空间使用量包括用户创建的所有库，mysql库，test库，performance_schema库，日志空间使用量包括redolog，undolog，ibdata1，ib_checkpoint(存储checkpoint信息)，http://innodb_repl.info(存储切换信息，物理复制信息等)，临时空间使用量包括socket文件，pid文件，临时表(大查询排序用)，审计日志文件，系统文件空间使用量包括错误日志，慢日志，general日志以及主库信息(用于构建复制关系)。虽然有四部分空间使用量，但大多数主要被数据空间和日志空间占用，数据空间比较好理解，主要就是表空间聚集索引和二级索引的占用量，但是这个日志空间很多用户不是很了解，常常提上来的问题是，为什么我的日志空间占了100多个G，而数据空间就几个G，这里简单解释一下。

redolog，主要用来构建物理复制，同时也可以被当做增量日志来支持还原到时间点/克隆实例的任务，类似原生的binlog，文件名按顺序递增，主节点产生日志，只读节点/灾备节点应用日志，同时后台管控任务会定时上传redolog(只要发现新的就立即上传)并且定时删除(目前一小时触发一次删除任务)，具体大小与DML总量有关。

edolog日志占用
redolog日志，由于对数据的修改都会记录redolog，所以对数据修改的越快，redolog产生的速度就会越快，而且上传OSS(保留下来做增量日志)的速度有限，所以在实例导数据阶段，会导致redolog堆积，当导入完成后，redolog会慢慢上传完然后删除，这样空间就会降下来，但是不会完全降为0。具体原因需要介绍一下：目前所有规格，redolog大小都为1G，被删除的redolog不会马上被删除，而是放入一个缓冲池(rename成一个临时文件)，当需要新的redolog时候，先看看缓冲池里面还有没有可用的文件，如果有直接rename成目标文件，如果没有再创建，这个优化主要是为了减少创建新文件时的io对系统的抖动，缓冲池的大小由参数loose_innodb_polar_log_file_max_reuse控制，默认是8，如果用户想减少缓存池的文件个数，就可以减少这个参数从而减少日志空间占用量，但是在压力大的情况下，性能可能会出现周期性的小幅波动。所以当写入大量数据后，即使redolog都被上传，默认也有8G的空间用作缓存。注意，调整这个参数后，缓冲池不会立刻被清空，随着dml被执行，才会慢慢减少，如果需要立即清空，建议联系售后服务。

https://zhuanlan.zhihu.com/p/108431268

POLARDB 是阿里云自主研发的下一代云原生分布式数据库，100%兼容MySQL、PostgreSQL等开源数据库，高度兼容Oracle语法，使用RDS服务的客户不需要修改应用代码，可以一键迁移到POLARDB，体验更大的容量，更高的性能，更低的成本，和更灵活的弹性。

作为基于计算与存储分离架构的新一代云原生数据库，POLARDB的计算节点里主要实现了 SQL 解析和优化、以及查询并行执行与无锁高性能事务处理，计算节点之间通过高吞吐的物理复制协议同步内存状态。

而存储层基于分布式文件系统PolarFS，通过Parallel Raft共识算法实现多数据副本间的强一致性，在存储层进行存储引擎的多版本页管理来支持全集群跨计算节点的Snapshot Isolation隔离级别。

01基于计算与存储分离的先进架构

计算节点与存储节点之间通过理解数据库语义的智能互联协议将filter和projection等算子从计算层下推到存储层执行。为了保证事务和查询语句的低延迟，同时降低计算节点之间状态同步的延迟，计算节点和存储节点之间使用25Gb高速RDMA网络互联，采用Bypass kernel的用户态网络协议层进行通讯。

基于计算与存储分离的先进架构，POLARDB可以从1个计算节点（2个CPU核）弹性伸缩到16个计算节点（最高达到1000核）的事务扩展能力，单实例存储容量从10GB按使用量弹性扩展到100TB。

计算节点与存储节点分离的架构设计给POLARDB带来了实时的水平扩展能力。由于单个数据库实例的计算能力有限，传统的做法是通过搭建多个数据库副本来分担压力，从而提供数据库Scale out 的扩展能力。

然而，这种做法需要存储多份全量数据，并且频繁同步日志数据造成了过高的网络开销。此外，在传统数据库集群上，增加副本需要同步所有增量数据，这带来了同步延迟上涨的问题。

POLARDB将数据库文件以及Redo log 等日志文件存放在共享存储设备上，确保主实例和所有副本共享同一份全量数据和增量日志数据。节点间只需要同步内存里的元数据信息，通过MVCC机制的保证，就能支持跨节点读取数据的一致性，非常巧妙地解决了主实例和副本之间的数据同步问题，大大节约了跨节点的网络开销，降低副本间的同步延迟。

02提升事务性能 POLARDB内核层面优化揭秘

为了提高事务性能，POLARDB 在内核层面进行了大量优化。把一系列性能瓶颈用无锁（lockless）算法以及各种并行优化算法进行改造，减少甚至消除各种锁之间的相互冲突，大大增加了系统的scalability 能力。

同时，我们依托处理双十一这种大规模高并发场景下的经验, 在 POLARDB 上实现了对库存等热点数据进行优化的功能。对于简单重复的查询，POLARDB支持直接从存储引擎获取结果，从而减少了优化器及执行器的开销。

此外，进一步优化已经高效的物理复制。比如，我们在重做日志加了一些元数据，以减少日志解析CPU开销. 这个简单优化减少了60%日志解析时间。我们也重用 一些数据结构，以减少内存分配器的开销。

POLARDB运用了一系列算法来优化日志应用，比如只有在buffer pool中的数据页面 才需要日志应用。同时我们也优化了page cleaner and double write buffer，大大减少这些工作的成本. 这一系列优化使得在性能上 POLARDB 远超 MySQL ，在sysbencholtp_insert等大量并发写入的基准评测中达到最高6倍于MySQL 的性能。

03支持并行查询（Parallel Query）

为了提高子查询和join等复杂查询（例如TPC-H基准评测）的能力，POLARDB的查询处理器支持并行查询（parallel query），可以将一个查询同时在多个或所有可用CPU核上进行执行。并行查询能够将一个查询任务（当前只支持SELECT语句）划分为多个子任务，多个子任务可以并行进行处理，整体采用Leader-Worker的并发模型。

Leader线程负责生成并行查询计划，协调并行执行过程的其他组件，并行执行计划会包括并行扫描、多表并行连接、并行排序、并行分组、并行聚集等子动作。

Message queue是leader线程和worker线程的通讯层，worker线程通过message queue向leader线程发送数据，而leader线程也会通过message queue向worker线程发送控制信息。

Worker线程负责真正的执行任务。Leader线程解析查询语句生成并行计划，然后同时启动多个worker线程进行并行任务处理，为了高效的执行查询，Worker上的执行不需要进行再次优化，而是直接从Leader上来拷贝生成好的计划分片。这需要实现执行计划树上所有节点的拷贝。

worker线程在进行扫描，聚集，排序等操作后将中间结果集返回给leader，leader负责收集来自worker的所有数据集，然后进行适当的二次处理（比如merge sort，二次group by 等操作），最后将最终结果返回给客户端。

https://zhuanlan.zhihu.com/p/108442296

https://blog.csdn.net/u014730658/article/details/109724450

PolarDB的存储是由一组Chunk Server通过RDMA硬件连接在一起(PFS技术)， 对上层提供块设备接口，而计算节点通过RDMA网络将存储挂载到计算节点中，从上往下看，底层的Chunk对于计算是完全透明的，目前PolarDB提供的最大规格还是限制在100T，主要是考虑一般业务中很少有能超过的oltp业务数据容量，同时过大的存储的确还是会存在一定的运维问题，所以这里的上限限制只是软限制，基于PFS的构成原理，我们其实可以近似认为PFS可以为计算节点提供无限容量的存储。

在支持了海量存储之后，使超大规模的表成为了可能，但由于单机版MySQL时代的大表容量只停留在理论上，没有真正投入生产，所以在出现史无前例的大表后，性能方面的问题才开始逐渐浮出水面，包括且不限于索引分裂，海量更新时数据刷盘等问题。

例如：

大表索引B-tree一定会出现比较一般表高很多层的情况，此时进行SMO操作时，索引上的锁会影响系统并发，我们将Btree 改进成了Blink-Tree，可以以最小代价完成索引层的维护，大大减小SMO的时间和性能成本。
redo落盘时，原生MySQL的方案是尽量使用顺序写以提高情况IO效率，但由PFS的架构可以看出，分布式的写不会带来性能提升，反而会造成热点写的问题，我们将redo改为分桶的方式在不同chunk上分散写，充份利用了分布式存储的优势。

https://zhuanlan.zhihu.com/p/372422876

https://segmentfault.com/a/1190000017195693

https://blog.csdn.net/weixin_34402408/article/details/89612709