PingCAP CTO 黄东旭：我眼中的未来数据库技术趋势

还有大的趋势是存储计算分离。我觉得现在业界有一个特别大的问题，就是把存储计算分离给固化成了某一个架构的特定一个指代，比如说只有长的像 Aurora 那样的架构才是存储计算分离。那么 TiDB 算存储计算分离吗?我觉得其实算。或者说存储计算分离本质上带来的好处是什么?就是我们的存储依赖的物理资源，跟计算所依赖的物理资源并不一样。这点其实很重要。就用 TiDB 来举例子，比如计算可能需要很多 CPU，需要很多内存来去做聚合，存储节点可能需要很多的磁盘和 I/O，如果全都放在一个组件里 ，调度器就会很难受：我到底要把这个节点作为存储节点还是计算节点?其实在这块，可以让调度器根据不同的机型(来做决定)，是计算型机型就放计算节点，是存储型机型就放存储节点。

7. Everything is Pluggable

图 20 Everything is Pluggable

今天由于时间关系没有给大家演示的插件平台。未来 TiDB 会变成一个更加灵活的框架，像图 20 中 TiFlash 是一个 local storage，我们其实也在秘密研发一个新的存储的项目叫 Unitstore，可能明年的 DevCon 就能看到它的 Demo 了。在计算方面，每一层我们未来都会去对外暴露一个非常抽象的接口，能够去 leverage 不同的系统的好处。今年我其实很喜欢的一篇 Paper 是 F1 Query 这篇论文，基本表述了我对一个大规模的分布式系统的期待，架构的切分非常漂亮。

8. Distributed Transaction

图 21 Distributed Transaction(1/2)

说到分布式事务，我也分享一下我的观点。目前看上去，ACID 事务肯定是必要的。我们仍然还没有太多更好的办法，除了 Google 在这块用了原子钟，Truetime 非常牛，我们也在研究各种新型的时钟的技术，但是要把它推广到整个开源社区也不太可能。当然，时间戳，不管是用硬件还是软件分配，仍然是我们现在能拥有最好的东西， 因为如果要摆脱中心事务管理器，时间戳还是很重要的。所以在这方面的挑战就会变成：怎么去减少两阶段提交带来的网络的 round-trips?或者如果有一个时钟的 PD 服务，怎么能尽可能的少去拿时间戳?

图 22 Distributed Transaction(2/2)

我们在这方面的理论上有一些突破，我们把 Percolator 模型做了一些优化，能够在数学上证明，可以少拿一次时钟。虽然我们目前还没有在 TiDB 里去实现，但是我们已经把数学证明的过程已经开源出来了，我们用了 TLA+ 这个数学工具去做了证明(https://github.com/pingcap/tla-plus/blob/master/OptimizedCommitTS/OptimizedCommitTS.tla)。此外在 PD 方面，我们也在思考是不是所有的事务都必须跑到 PD 去拿时间戳?其实也不一定，我们在这上面也已有一些想法和探索，但是现在还没有成型，这个不剧透了。另外我觉得还有一个非常重要的东西，就是 Follower Read。很多场景读多写少，读的业务压力很多时候是要比写大很多的，Follower Read 能够帮我们线性扩展读的性能，而且在我们的模型上，因为没有时间戳 ，所以能够在一些特定情况下保证不会去牺牲一致性。

（编辑：网站开发网_安阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!