codefollower
commented
5 years ago 再再补充：
再往前大胆的想一下，如果应用服务器跟数据库部署在同一个机房，像TDDL做的那样，把PolarDB的计算节点跟应用服务器跑在一起，让jdbc client直接调，那就跟访问应用服务器的本地文件系统一样了，这样的性能只能用无敌来形容了，说得我都好羡慕了，就是用不起RDMA。😂
Closed codefollower closed 5 years ago
codefollower
commented
5 years ago 再再补充：
再往前大胆的想一下，如果应用服务器跟数据库部署在同一个机房，像TDDL做的那样，把PolarDB的计算节点跟应用服务器跑在一起，让jdbc client直接调，那就跟访问应用服务器的本地文件系统一样了，这样的性能只能用无敌来形容了，说得我都好羡慕了，就是用不起RDMA。😂
产生 PolarDB 这类产品的想法还是很容易理解的，但凡做RDBMS的人都知道有redoLog和b-tree这两个东西，如果我们把redoLog中的一个block和b-tree中一个leaf page做一层抽象，变成虚拟的block和leaf page，它们即可以代表本地的也可以代表网络上另一台服务器文件系统中的一块数据。
经过这一层抽象后，整个数据库就像是跑在没有硬盘的服务器上一样，那些虚拟的redoLog block和b-tree leaf page就变成一个指针了，此时的服务器就能很好的充当一个计算节点的角色了。
所以 PolarDB 在思想上并不让人吃惊，关键还是在工程实现的细节上，并且提前尝试RDMA这种远未普及的新技术，让访问本地文件系统跟访问远程存储节点上的数据在延迟上不相上下。
当然其中还有一个Parallel-Raft，使得从计算节点到多个存储节点之间的数据同步是并行的，而不是 计算节点 -> leader存储节点 -> follower存储节点 这样的串行写入流程。
PolarDB 这样的架构，除了计算节点很容易扩容之外，配上RDMA和Parallel-Raft，理论上的写入性能会跟单机版的MySQL接近(jdbc client->MySQL约等于jdbc client->PolarDB 计算节点+RDMA+存储节点)。
我司的数据库产品运行在replica set模式时，是在jdbc client端发起并行复制的(配合服务端完成整个复制协议)，所以在写入性能上跟PolarDB接近。
PolarDB 的这套技术很容易迁移到其他RDBMS中，拿我司的数据库来说，b-tree的leaf page分成了local leaf page和remote leaf page两种，只要把PolarDB如何操作RDMA那一整套东西用到remote leaf page中就行了，如果想用PolarDB的Parallel-Raft，就在jdbc client禁用并行复制。
TiDB/TiKV 就不好弄了，要想使用PolarDB这种架构，必须把TiDB/TiKV合并，然后进一步修改RocksDB，并且TiKV中的Raft实现也可能需要大改或直接废掉。
补充：
PolarDB这种架构依然是传统replica set的范畴，如果将来想扩展到sharding模式，还需要从InnoDB这一层一直往上改到MySQL Server层，sharding模式下频繁出现的分布式事务问题依然很刺手，特别是表和索引的数据块在不同的存储节点上时(比如要支持全局索引)，如何保证执行update/insert/delete时不同的存储节点中的表和索引数据满足ACID。
再补充：
睡不着，刚想了一下，PolarDB可以学我司的Lealone数据库使用leaf page sharding算法，只要leaf page发生切割时让其中的一个子page移到不同的存储节点即可。
这样的话在做分布式聚合时都不用做sql重写了，比如把求平均数重写为count和sum。因此就不用改sql引擎层的代码了。扫描到b-tree的page时哪怕它们在不同节点，也没关系，就像挂载本地硬盘一样。
Lealone因为缺乏RDMA的支持，就必须得重写sql，否则遇到remote leaf page时直接加载远程page是很低效的。
不过PolarDB只允许一个可写的计算节点，这在一定程度上损失了leaf page sharding算法的好处，Lealone可以并行读写。
总之，PolarDB对RDMA的大胆尝试还是值得称赞的，如果我司的Lealone数据库也配上RDMA，那就是个完美的数据库了，合适的时机我再考虑集成RDMA的方案。