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 能够帮我们线性扩展读的性能，而且在我们的模型上，因为没有时间戳 ，所以能够在一些特定情况下保证不会去牺牲一致性。 9. Cloud-Native Architecture
图 23 Cloud-Native 另外一点就是 Cloud-Native。刚刚中午有一个社区小伙伴问我，你们为什么不把多租户做在 TiDB 的系统内部?我想说「数据库就是数据库」，它并不是一个操作系统，不是一个容器管理平台。我们更喜欢模块和结构化更清晰的一个做事方式。而且 Kubernetes 在这块已经做的足够好了 ，我相信未来 K8s 会变成集群的新操作系统，会变成一个 Linux。比如说如果你单机时代做一个数据库，你会在你的数据库里面内置一个操作系统吗?肯定不会。所以这个模块抽象的边界，在这块我还是比较相信 K8s 的。《Large-scale cluster management at Google with Borg》这篇论文里面提到了一句话，BigTable 其实也跑在 Borg 上。
图 24 TiDB 社区小伙伴的愿望列表 当然最后，大家听完这一堆东西以后，回头看我们社区小伙伴们的愿望列表(图 24)，就会发现对一下 TiDB 好像还都能对得上 :D （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
