【开源访谈】黄东旭:“无人区”的探索者, TiDB 的前行之路

> 日前,我司联合创始人兼 CTO 黄东旭接受了开源中国的【开源访谈】,公开解读了 TiDB 的探索之路及未来方向。本文为专访实录~ :)

记者:王练

口述:黄东旭

首先请老师介绍一下自己

黄东旭,PingCAP 的联合创始人和 CTO,TiDB 的设计者和工程师,一直以来从事的基础软件和分布式系统的研发,很小就开始接触编程和开源,受到开源文化和自由软件运动的影响很深,是一个开源信徒,所以后来基本做东西能开源的尽量都会开源,比如早期的 Codis,现在的 TiDB。

TiDB 从零到 1.0 历时了两年半左右,遇到的难点主要有哪些,是如何解决的呢?

技术上主要的难点,比较具体的我记得是在早期决定不复用 MySQL 代码的同时还需要做到 MySQL 文法和网络协议上的兼容,同时还需要在很短时间内完成一个可用的查询优化器,虽然技术本身不是特别难,但是在早期确实是个工程上的挑战;另外底层存储上我们选用了 Rust 作为开发语言,作为一个比较新的语言,我们花了一些时间和精力帮助 Rust 社区完善一些第三方库,比如 gRPC 的 Rust 实现就是我们贡献和维护的。

其实遇到技术问题也谈不上有什么特别的解决方案,仔细分析和思考,拥抱和相信社区,重视测试,我们的工程师和在 TiDB 社区活跃的 Committer 的能力都很强,我相信大方向没问题,遇到的技术问题都是能解决的。

到现在,因为前方基本已经是无人区,思考得比较多的是未来数据库的形态和一些前沿的技术,比如如何更好利用新时代的硬件,如何和云更好的整合等等。

另一个方面是商业上的难点,我们几个创始人都是技术出身,过去并没有销售和市场的经验,在早期如何搭建商业和市场团队,如何面试这方面的人才,曾经让我们头疼很久,不过工程师嘛,多聊多总结,发挥学习新技术的精神去了解不同行业的东西,另外我们的投资人也帮了我们不少忙,总体来说,保持一个开放学习的心态,放低姿态多和行业里比较资深的人聊,能学到不少。

1.0 之后的 TiDB 将主要围绕哪些方面进行迭代更新?

技术上有几个重要的点:

1. 大集群上的多租户技术,这部分我们一个大的用户 Mobike 的工程师们为 TiDB 提交了这方面很多重要的特性的实现和很多宝贵的建议,在这里特别感谢一下。

2. 实时 OLAP 引擎,TiSpark 项目,TiDB 本身是一个 100% 的 OLTP 数据库,同时它的实时复杂分析能力也会越来越强,1.0 后一个重要的方向就是我们希望能够在 HTAP 上更进一步,打破数据库和数据仓库之间的界限。

3. 进一步减轻用户的迁移成本,我们内部在开发一些工具能够极大加速数据导入和同步线上 MySQL 的速度,降低用户的尝试和使用成本。

4. 拥抱新的硬件,这个时代,新的硬件层出不穷,Optane / NvmeSSD / 万兆网卡的普及,如何设计新的数据结构,使用新的 SDK,Bypass Kernel 使得更好的适应新的硬件。

最后一点,是持续增强稳定性,性能以及测试,这个是一个长期的工作,优化无止境嘛。

1.0 发布之后势必会吸引到更多用户使用,但也有许多用户迫切希望能有更多案例和背书,对此要如何解决?

其实这个是一个鸡生蛋蛋生鸡的问题,你需要得有第一批用户案例,才能吸引更多的用户,我们选在这个时间点发布 1.0 也是因为产品已经完成破冰,我们从 RC (Release Candidate)到 1.0 中间大约经过了一年,这一年时间我们已经默默的服务了很多种子用户,在他们的生产系统中锻炼,我们的早期客户中已经有系统稳定运行 TiDB 大规模集群超过一年了,在确保产品质量和有足够的用户背书的情况下,我们这才谨慎的发布了 1.0,我们随后也会持续的输出案例,给予社区更多的信心。

国外和国内的用户在特性方面的需求是否有差异,要怎么来协调?

其实特性需求上差异不大。在中国,大家会遇到 MySQL 的扩展性问题,在美国也会遇到。所以这两个市场对于我们这种基础软件公司来说,不会像 to C 的产品公司那样难以在海外复制,基础软件领域是没有国界限制的,目前我们也在布局海外市场。

同样在做 NewSQL 的 CockroachDB 在更早一点发布了 1.0 版本,能介绍一下二者的差异和相似之处吗?在进度相差不大的情况下,二者的业务是否有所冲突?

CockroachDB 也是一个很好的项目,在很多人看来,TiDB 和 CockroachDB 都是为了解决关系型数据库的可扩展性问题,并且二者都是受 Google Spanner/F1 的启发。 具体细节上,有以下几点不同:

1. 二者兼容性不同,TiDB 是 100% MySQL 协议兼容,CockroachDB 兼容的是 PostgreSQL 。我们的用户可以直接使用 MySQL 的客户端来连接 TiDB ;

2. 架构上的区别,TiDB 产品架构是分层的,由分布式 SQL 层(TiDB)和分布式 KV 存储引擎(TiKV)组成,而 CockroachDB 没有分层,所有的东西都在一个 binary 里面;

3. 事务模型不同,虽然 TiDB 与 CockroachDB 都支持 ACID 事务,但是 TiDB 采用的是 Google Percolator 的模型,这个模型的关键特性是,它需要一个独立的 timestamp allocator,CockroachDB 所采用的是与 Google 相似的 TrueTime API,但是跟 Spanner 不一样的是,CockroachDB 并没有原子钟和 GPS 时钟来保证不同数据中心时间的一致性;

4. TiDB 是一个 HTAP 数据库,既具备 OLTP 的强大在线交易能力,也具备 OLAP 的在线分析能力。CockroachDB 暂时不具备 OLAP ;

5. 二者开发语言不同,CockroachDB 用的 Go 语言,TiDB 整体项目用了两种语言,SQL 层(TiDB)用的是 Go,KV 层(TiKV)用的是 Rust。

应用场景上:TiDB 在行业内使用更广泛,目前涉及互联网、游戏、金融、政府、电信、制造业等多个领域。

从 SQL 到 NoSQL,再到 NewSQL,如何看待数据库的现状和未来发展方向?

个人认为从传统的单机 SQL 到 NoSQL 只是互联网公司在面对大并发量的新业务时的过度的状态,历史是螺旋上升的,现在 SQL 的回归是大势所趋,毕竟 SQL 是一个更好的操作数据的用户接口。

在可见的未来,数据量会是一直在膨胀,业务会越来越复杂。我个人觉得未来的数据库会有几个趋势,这也是 TiDB 项目追求的目标:

1. 数据库会随着业务云化,未来一切的业务都会跑在云端,不管是私有云、公有云还是混合云,运维团队接触的可能再也不是真实的物理机,而是一个个隔离的容器或者「计算资源」。这对数据库也是一个挑战,因为数据库天生就是有状态的,数据总是要存储在物理的磁盘上,而移动数据的代价比移动容器的代价可能大很多。目前 TiDB 也与包括腾讯云、UCloud 在内的多家公有云平台完成了整合,提供公有云数据库服务。

2. 多租户技术会成为标配,一个大数据库承载一切的业务,数据在底层打通,上层通过权限,容器等技术进行隔离;但是数据的打通和扩展会变得异常简单,结合第一点提到的云化,业务层可以再也不用关心物理机的容量和拓扑,只需要认为底层是一个无穷大的数据库平台即可,不用再担心单机容量和负载均衡等问题。

3. OLAP 和 OLTP 会进一步细分,底层存储也许会共享一套,但是 SQL 优化器这层的实现一定是千差万别的。对于用户而言,如果能使用同一套标准的语法和规则来进行数据的读写和分析,会有更好的体验。

4. 在未来分布式数据库系统上,主从日志同步这样落后的备份方式会被 Multi-Paxos / Raft 这样更强的分布式一致性算法替代,人工的数据库运维在管理大规模数据库集群时是不可能的,所有的故障恢复和高可用都会是高度自动化的。

5. 最后就是我前面说过的要拥抱新的硬件,要跟上新硬件的迭代速度,配合设计新的数据结构来适应新的硬件。

原文链接:https://www.oschina.net/question/2896879_2270570

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏祝威廉

运维之殇

让人推荐快速学习的方式,却也是极度无奈之举。而且运维也不是一日练成的。就算大师提供了很好的指导,也终究是拿自己的线上产品练手了,这样显然是得不偿失的。现如今,一...

512
来自专栏知晓程序

从硅谷到上海,这个技术大神做了个小程序,带你发现城中好去处 | 晓组织 #18

我毕业于美国威斯康星州立大学计算机系,曾任硅谷著名旅游社交公司 Trip.com 高级架构师,带领团队开发的 Trip.com App 多次被 Apple, G...

572
来自专栏程序猿DD

微服务与Serverless对决,谁才是未来之主?

近两年里,微服务的突然崛起让人仿佛看到了架构开发的新世界。摒弃繁杂而不稳定的巨型系统架构城堡,轻装上阵,应用单个开发,基于业务构建,自动化独立部署,不仅缩短了开...

642
来自专栏A周立SpringCloud

Serverless+SCF=打倒服务器,解放程序员 | 技术沙龙

在很多外行人的眼里,程序员就是神一样的存在。他们全年 996,节假日无休,不仅 Java、PHP、C++ 要样样精通,还要会修电脑修音响修手机,做前端要懂运维,...

531
来自专栏FreeBuf

谷歌应用现怪异Bug:搜索特定词条会暴露短信

过去几周里,有安卓用户在其设备上发现了前所未有的有趣bug。当用户在搜索一些特定词条时,设备会暴露用户个人的短信息。不过这个bug只会在使用Google Sea...

1044
来自专栏Forrest随想录

从技术角度谈谈鹿晗这个事儿

关于鹿晗事件拖垮微博这件事,分享下我的理解。只做客观分析,不吹,不喷,不黑,因为这个事情绝对不是像网上传的,什么微博架构烂、技术不行、可扩展性差、控制预算成本所...

752
来自专栏腾讯云技术沙龙

Serverless+SCF=打倒服务器,解放程序员

在很多外行人的眼里,程序员就是神一样的存在。他们全年996,节假日无休,不仅Java、PHP、C++要样样精通,还要会修电脑修音响修手机,做前端要懂运维,做后台...

1622
来自专栏SDNLAB

当SDN遇上NFV 虚拟化5G核心网络掀革

自第一代行动通讯(1G)到第四代行动通讯(4G)的发展过程中,在无线接取网络(RAN)技术上,自FDMA、TDMA、CDMA、到OFDMA,每一世代都明显地被视...

37310
来自专栏祝威廉

为什么需要效率督查团队

上周和杭州某司同学面基,发现我们两同一年毕业,同一年出生,还是老乡,真是颇感意外。本来约好了是聊技术的,结果硬生生的聊成了如何提高团队效率的心得交流会。

822
来自专栏SDNLAB

SDN那些事:传统网络变身SDN、公有云及NFV 网络专题

SDN的概念已经提出很多年了,原以为SDN不会立刻在生产环境下部署,但是SDN的商用历程超出了我们的想象。 特别是很多公有云服务商面临业务快速发展的压力,在网络...

2696

扫码关注云+社区