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 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
