开发者学堂课程【PolarDB-X 开源系列课程：分布式事务与数据分区（四）】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/1032/detail/15162
分布式事务与数据分区（四）
五、解答问题
那接下来看一下提的一些问题。
首先是一阶段的日志记录在哪里？记录在所有分片上了，根据事物当中的第一条写入落在哪个分片上，那么最终事物日志就会记在这个分片上。
给一个分片是一台 ECS 吗？这个不一定，分片概念是相对独立的，它可以多个分片落在相同的 ECS 上，落在相同的 DN 上，也可能一个分片单独独占一个 DN。
PolarDB-X 底层的分布式存储有可用区的概念吗？这是有的，DN 本身是基于 PX 实现的一个三节点的架构，其中的一些节点可以在不同的可用区中，这个应该是明天分享的主要内容，到时可以也可以再关注一下。
一个表可以有多个句式索引吗？这是可以的，这可能和见到的大多数数据库不太一样，比如说 MYSQL 索引组织表的话，只能有一个局部索引，然后 Oracle cycle server 是除了索引组织表之外，可以允许你再去单独建一个全局聚簇索引，但 PolarDB-X 因为作为分布式数据库，回表的代价非常高，而且除了聚簇索引以外，还支持一种覆盖索引的方式，就是在索引里面指定一些冗余的链，但这两种方式有什么区别？
就是对于一些相对模糊的查询，比如说 slight 这种操作，仅仅采用覆盖索引这种方式，那可能由于加列会导致 slight 性能突然波动，那如果想彻底解决这个问题，就可以去聚簇索引，聚簇索引的特点是它会保持它的表结构和主表完全一样，这样无论是加列还是减列，slight 星查询的性能都不会受到影响。
可以重新指定分区列吗？
是的，现在的 online DDL 是支持变更分区键的，其背后的原理其实也不太复杂，会采取一种 copy 的模式，但这都完全被上次屏蔽掉了，而且不会影响过程当中的读写请求。
分片除了 hash range 还支持其他吗？是的，支持非常全面种类的计算法，可以在官网文档上关注一下。
不同服务间的 PolarDB-X 怎么实现事物？这里说的不同服务间的多个 PolarDB-X 有点像这种跨服务的事物，这个目前已经超出了数据库应该支持范畴，通常是由一些跨服务的事务组件来支持的。
全局索引是保存在 DN 上还是保存在 CN 上？是保存在DN上的，全局索引本身也是一张逻辑表，它只是和主表采用了不同的分区键，并且它是会跟随主表的数据更新而同步更新。它本身还是保存在 DN 上的。
重新指定分区列的过程是动态的吗？数据量会数据量大会锁吗？这个完全采取的是 all scheme change 的过程，其实也可以这么理解，就是重新指令分区键，可以把它的过程理解为先建了一个不同拆分键的聚簇索引，然后再把主表的原数据和聚簇索引交换，再把主表删掉，整个过程是完全的 unless game change 不加任何组。
DN 的 X python 是怎么实现的？这是明天分享的内容，请敬请关注。
索引的数量有限制吗？目前只有一些建议值的限制，在代码层面是没有限制的，但肯定索引是有代价的。第一它会有起放大，就像下一个问题聚簇索引的空间是不是要*2？是要*2的，因为它冗余了主表上的所有列。
第二是索引本身有写入放大的写入的代价，就是因为多一个索引，在写入的过程中就要去维护多一个索引的写入，当然随着索引数量的增多，因采取了并行的写，只要系统资源不成为瓶颈，那么可能 RT 增加不会太多，但也建议就合理的使用索引，这个其实和 MYSQL 一样，所以加太多的效果是一样的。
索引表会随着主表变化吗？这是聚簇索引特有的功能，比如说在加列的时候，聚簇索引会跟随着主表一起加列，在减列的时聚簇索引上也会减，当然普通索引上也会减。这是聚簇索引特有，正常全普通的全局二级索引包括全局唯一的二级索引，它们都不会跟随着主表加列而加列，但是会跟随着主表的变更列而变更列，减列而减列。
索引创建默认是 global 的还是 local 的？首先 PolarDB-X2.0上库分为了两种类型：一种叫auto库，还有一种叫 D2DS 模式的库。先说D2DS模式，D2DS模式的库是兼容了以前 PolarDB-X1.0的使用方式，默认创建的是 local 索引，默认需要去自己指定分区键，如果不指定就是单调。
那现在更推荐的是第二种用法，就是建立 auto 库，那么Auto 库本身的目的是它的设计目标是帮助大家像使用单机数据库一样去使用 PolarDB-X，所以它基本上允许用和单机数据库一样的语法去得到可用的系统，所以建表的时候不要求指定拆分件，默认会去使用主键作用去简，而创建的索引，默认会是 gervnex 全局索引，当然有一些针对性的细节的优化。建议阅读文档来看一下，但大多数场景，创建的都是全局索引，在 Out ku 这种模式下。
某个 DN 挂了会丢失数据吗？
以两阶段提交来看，现在两阶段提交之前先确认一下，就所有 DN 它本身都是一个 MYSQL，首先 MYSQL 会保障数据持久性，那只要数据正常提交到 DN，那数据就一定会 DN crash 不会导致数据丢失，并且还支持了基于差 practice 的三部分，所以更有更强的数据的持久性的保障，那么可能在具体的过程中需要考虑数据会不会丢失，比如说在两阶段提交的过程当中，一个两阶段提交全部成功的情况，首先是在一阶段提交的时候，CN 向每个 DN 都发送了一个 prepare，那么在 prepare 的过程当中，所有的 DN 会尝试将自己的这个 redo not 去进行落盘来确定这个确实是可以提交的，并且记录一下事物状态已经是 prepare 的状态，这个时候只要这些状态都写到了日志里，那么 DN 的 crash 就不会导致这些状态的丢失，接下来如果 CN 上这一条 coming load 写入成功的话，他其实也是写在DN上，只要这条日志成功，那么 DN 的 crash 也不会导致这条日志消失。所以当系统在各种 crash 拉起之后，依然可以看到这样一个分布式事物，已经完成了所有 DN 上的 prepare，并且 commit 的日志确认要继续进行提交操作，那接下来 CN 就可以接着去把所有的 commit 的请求下发到每个 DN 上，那么 DN 就可以继续根据日志里面的内容，把该提交书的内容全部提交掉。所以在某个DN 挂了，在提交阶段是不会导致数据丢失的，在其他的情况下也不会导致数据丢失。
每个 DN 都有多副本吗？是的，目前每个 DN 都是基于 chapters 的三副本。
Join 下推的性能怎么样？这可以分两部分看，第一是 join 下推本身算法的性能怎么样，这个是依赖 plan catch 的，就是首先会对执行计划做参数化，然后根据参数化的结果，当判定这个查询能够下推的话，它后面所有的不同参数的查询到来之后，直接从 plan catch 里面读出来，那就可以下推。
当把 Join 下推到 DN 上执行是否性能提升？那其实对于 TP 来说，大体上是成立的，因为降低网络开销肯定是带来 RT 上的缩短，那但是对于 AP 类的查询有的时候不一定，因为 DN 的计算资源肯定没有 CN 多，那有的时候把一些 AP 类的 Join 下推下去，是不太合理的。所以在做这事的时候，也有基于 CTO 的判断。Cpu 会去智能的识别，它本身的代价模型里会去估算 DN 执行重要的代价和 CN 执行重要的不同代价，如果它下推到DN上代价更高的话，那它会去考虑把这个数据拉到 CN 上来做，所以重要下推性能怎么样，这个问题 TP 场景下大多数时候下推都是可以的。如果下推性能不好的情况下，也可以通过 cpu 来识别出来，将数据拉回到 CN 上，执行下一个问题。
创建全局二级索引对应列的索引 house 规则保存在 GMS 节点吗？是的，全局二级索引本质上也是一张表，所以它的原数据和普通表的原数据存储方式基本一致，都是存放在 GMS 节点上。
Ob 和 PolarDB-X 对应的场景的大概内容？其实大家都是分布式数据库，并且解决的问题都比较接近，硬说适应的场景有什么区别的话，可能现在能理解到最明显的区别就是 PolarDB-X 是一个存储计算分离的架构，那 ocean base 的话，它并没有采用存储计算分离的架构。如果说场景上有什么区别，架构可能会带来一些场景上的不同。
PolarDB-X 怎么支持 AP 查询？支持 AP 查询本身首先是基于存储计算分离的架构，这个在存储计算分离架构上支持了 MPP 引擎的，就是支持将数据拖到 CN 上，然后进行一个分布式的计算。
讲义的PPT可以传到群里吗？
这个要看后面整体的动作。一般会有这个公众号里面的分享，关注一下知乎官方账号，后续会有新的消息。
