PingCAP CTO 黄东旭：我眼中的未来数据库技术趋势
|
举一个例子吧，好比极度一点，各人也许在上世纪八九十年月用过这种 5 寸盘、3 寸盘，我针对这样的磁盘计一律个数据布局，此刻看上去是个笑话是吧?由于各人基础没有人用这样的装备了。在数据库这个行业内里许多的假设，在此刻新的硬件的情形下着实都是不创立的。好比说，为什么 B-Tree 就必然会比 LSM-Tree 要快呢?不必然啊，我跑到 Flash 可能 NVMe SSD 、Optane 乃至将来的耐久化内存这种介质上，那数据布局计划完全就产生变革了。已往也许必要投入许多精神去做的数据布局，此刻暴力就好了。
图 5 连年来软件厘革 同时在软件上也产生了许多许多的厘革，图 5 左上角是 Wisckey 那篇论文里的一个截图，尚有一些漫衍式体系上的新的技能，好比 2014 年 Diego 颁发了 Raft 这篇论文，其它 Paxos 这几年在各类新的漫衍式体系里也用得越来越多。 以是我认为这几年我们遇上了一个较量好的期间，就是不管是软件照旧硬件，照旧漫衍式体系理论上，都有了一些较量大打破，以是我们基本才气够打得较量好。
图 6 Data Type 除了有这样的新的硬件和软件之外，我认为在营业场景上也在产生一些较量大变革。已往，也许十年前就是我刚开始介入事变的时辰，线上的架构根基就是在线和离线两套体系，在线是 Oracle 和 MySQL，离线是一套 Hadoop 可能一个纯离线的数据客栈。但最近这两年越来越多的营业开始夸大火速、微处事和中台化，于是发生了一个新的数据范例，就是 warm data，它必要像热数据这样支持 transaction、支持及时写入，可是必要海量的数据都能存在这个平台上及时查询， 并不是离线数仓这种营业。 以是对 warm data 来说，已往在 TiDB 之前，着实是并没有太好的步伐去很优雅的做一层大数据中台架构的，「the missing part of modern data processing stack」，就是在 warm data 这方面，TiDB 正好去增补了这个位置，以是才气有这么快的增添。虽然这个增添也是得益于 MySQL 社区的风行。
图 7 应用举例 想象一下，我们假如在已往要做这样很简朴的营业(图 7)，好比在美国的订单库跟在中国的订单库也许都是在差异的数据库里，用户库也许是其它一个库，然后差异的营业也许是操纵差异的库。假如我想看看美国的斲丧者内里有哪些在中国有过斲丧的，就是这么一条 SQL。已往假如没有像 TiDB 这样的对象，各人想象这个对象该怎么做?
图 8 已往的办理方案 若是嗣魅这双方的数据量都出格大，然后已经分库分表了。已往也许只能第二天才可以看到前一天的数据，由于中间好比说一个 T+1 要做一个 ETL 到一个 data ware house 里。可能锋利一点的架构师也许会说，我可以做一套及时的 OLAP 来做这个工作，怎么做呢?好比说 MySQL 中间通过一个 MQ 再通过 Hadoop 做一下 ETL，然后再导到 Hadoop 上做一个冷的数据存储，再在上面去跑一个 OLAP 做及时的说明。先不嗣魅这个及时性到底有多「及时」，各人细默算一算，这套架构必要的副本数有几多，好比 M 是我的营业数，N 是每一个体系会存储的 Replica，拍脑壳算一下就是下面这个数字(图 9 中的 R )。
图 9 已往办理方案里必要的 Replica 数目 以是各人着实一开始在已往说，TiDB 这个背后这么多 Replica 欠好，但着实你想想，你本身在去做这个营业的时辰，各人在已往又能怎么样呢?以是我认为 TiDB 在这个场景下去同逐一此中台，是一个大的趋势。本日在社区实践分享上也看到许多用户都要提到了 TiDB 在中台上很是好的应用。
图 10 此刻的办理方案 回首完行业和应用场景连年来的一些变革之后，我们再说说将来。假设要去做一个面向将来的数据库，会行使哪些技能? 1. Log is the new database （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
