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

王练 发布于 2017/11/30 07:47
阅读 2K+
收藏 13

历时两年半,开源分布式 NewSQL 数据库 TiDB 终于迎来了 1.0 正式版本的发布。作为全新的数据库类型的“探路者”,TiDB 在这过程中遇到了哪些技术难点?后续又将围绕哪些方面进行突破?本期,【开源访谈】邀请到了 PingCAP 联合创始人、CTO 黄东旭,为我们解读 TiDB 的探索之路及未来方向。

【访谈内容】

1、首先请老师介绍一下自己。

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

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

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

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

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

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

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

技术上有几个重要的点:

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

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

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

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

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

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

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

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

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

6、同样在做 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 在行业内使用更广泛,目前涉及互联网、游戏、金融、政府、电信、制造业等多个领域。

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

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

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

  1. 数据库会随着业务云化,未来一切的业务都会跑在云端,不管是私有云、公有云还是混合云,运维团队接触的可能再也不是真实的物理机,而是一个个隔离的容器或者「计算资源」。这对数据库也是一个挑战,因为数据库天生就是有状态的,数据总是要存储在物理的磁盘上,而移动数据的代价比移动容器的代价可能大很多。目前 TiDB 也与包括腾讯云、UCloud 在内的多家公有云平台完成了整合,提供公有云数据库服务。
  2. 多租户技术会成为标配,一个大数据库承载一切的业务,数据在底层打通,上层通过权限,容器等技术进行隔离;但是数据的打通和扩展会变得异常简单,结合第一点提到的云化,业务层可以再也不用关心物理机的容量和拓扑,只需要认为底层是一个无穷大的数据库平台即可,不用再担心单机容量和负载均衡等问题。
  3. OLAP 和 OLTP 会进一步细分,底层存储也许会共享一套,但是 SQL 优化器这层的实现一定是千差万别的。对于用户而言,如果能使用同一套标准的语法和规则来进行数据的读写和分析,会有更好的体验。
  4. 在未来分布式数据库系统上,主从日志同步这样落后的备份方式会被 Multi-Paxos / Raft 这样更强的分布式一致性算法替代,人工的数据库运维在管理大规模数据库集群时是不可能的,所有的故障恢复和高可用都会是高度自动化的。
  5. 最后就是我前面说过的要拥抱新的硬件,要跟上新硬件的迭代速度,配合设计新的数据结构来适应新的硬件。
加载中
2
N
Nitron

我差点看成黄旭东...

调皮的XD
调皮的XD
我他妈也差点看成他
王练
王练
……哈哈
2
zhjphp
zhjphp
干死黄旭东, 谁来下句
sunday12345
sunday12345
我是专业解说,不可能输得啦!
_鱼_
_鱼_
光头能对空
CrazyPeter
CrazyPeter
飞龙骑脸怎么输。
风华神使
风华神使
蟑螂加两攻
0
枫听烨歌
枫听烨歌
第一眼看成老仙
0
Shazi199
Shazi199

还以为是黄旭东。。

0
昵称非法已被屏蔽

看成黄旭东进来的。。。

0
十有三
十有三

差点看错,第一反应

0
小飞鹤
小飞鹤

第一反应, 头发怎么长出来了。。

达尔文
达尔文
第二反应,怎么瘦了
0
ChpiTer
ChpiTer

不错哦,关注这个产品一段时间了

0
CasparLi
CasparLi

黄旭东!

0
l
lotsbug

旭东老仙,法力无边

祝开源中国越办越好!

返回顶部
顶部