黄东旭解析 TiDB 的核心优势
502
2016-11-10
内容来源:http://mp.weixin.qq.com/s?__biz=MzI3NDIxNTQyOQ==&mid=2247484168&idx=2&sn=5a9516110d30130caa73bbf59cbae1c4&chksm=eb162462dc61ad74be6381f73f973b313527ee14e4b0a3af6a6c47d23a09f32a17d1f0982e5d#rd
编者按: 2016 年 11 月 18 日-20 日,由 CSDN 重磅打造的年度技术盛会,SDCC 2016 中国软件开发者大会将在北京举行,本届大会云集了 100 多位国内外顶尖专家和技术大牛,共设新趋势和新实践 2 大主题会场,12 个技术专题,以及 2 个特色技术活动。
有这样一个开源项目,它仅仅用了两年时间,便成功地挑战了 MySQL 的传统地位,发布了分布式 NewSQL 的产品级实现。它不但快速地赢得了超过 5000 个 GitHub stars,还收获了超过 600+ 的 Fork 以及 50 多个 contributions。无论是从互联网公司和团队在生产环境中使用或测试的反馈,还是从开源社区的活跃程度来看,它在 Go/Rust 语言类项目中都取得了罕见的成功。
但通常大牛会自己发光发热而被众人熟知,在数据库领域近年来我想大家都或多或少知道 PingCAP、TiDB,或者其中的两位代表人物黄东旭和刘奇,而在 SDCC 2016·北京站上我们进行了别致的安排,请黄东旭带来《一个架构的演进和开发哲学》的主题分享,时间为 11 月 18 日 16:30-17:15,地点是:京都信苑饭店三层欧式多功能厅。
与此同时,在大会开始前,我们也有幸邀请到了主人公黄东旭,请他来分享他的技术历程、创业和相关的心得体会,以及那些可能看起来还是很值得学习的事儿。
黄东旭,PingCAP 联合创始人兼 CTO, 资深 Infrastructure 工程师,擅长分布式存储系统的设计与实现,开源狂热分子,开源分布式缓存服务 Codis 的作者,新型开源分布式关系型数据库 TiDB 的架构师和开发者,致力于定义下一代的分布式数据库。
CSDN:请先和大家介绍下您和目前所从事的工作以及关注哪些技术领域?
黄东旭:目前主要从事的工作是分布式系统设计和数据库内核,简单来说就是开源的 NewSQL 实现 TiDB。近几年,一直比较专注分布式存储系统,最近对分布式计算与传统关系数据库理论的结合比较感兴趣,另一个方向就是面向云的数据库的资源隔离和调度框架。
CSDN:据悉,您小学三年级开始写代码,四、五年级学 C 语言,高中时就开始用 Linux,能否分享下您是如何走向技术这条路的?
黄东旭:小学的时候比较喜欢玩游戏,就是红白机那种,后来家长买了台小霸王学习机,当时只有一个 QBasic 的卡带,另外加上在家里翻到的一本应该是我妈的大学教材的 Basic 的手册,一个很偶然的机会就从沉迷游戏变成沉迷写游戏了。在到后来小学四年级左右,家里实在受不了我的死缠烂打,给我买了台 PC,就开始在这条道路上走到黑了,从 VB 到 C/C++。后来上中学以后,也是一个偶然的机会,拿到了一个 Red hat linux 的发行版,后来开始慢慢了解自由软件运动和开源运动,深受影响,一路走到了现在。
CSDN:同时,您还喜欢画画,会玩摇滚……作为一家创业公司的 CTO,如何在工作和生活乐趣之间进行权衡,有什么心得和体会可分享?
黄东旭:我个人的爱好比较广泛,但是每玩一个东西的时候都会比较专注,所以效率还蛮高的,我不太认同创业就必须放弃一切个人生活这种说法,我觉得每周至少花一天时间投入到自己的爱好或者单纯陪在家人身边,会给日常的工作补充能量,让自己效率更高。
另外,把自己搞得筋疲力尽多半是因为方法不对或者时间没有利用好,我觉得寻求更聪明和更高效的办法会更重要。还有就是创业不是单打独斗,一定要相信自己的伙伴们。
CSDN:聊聊目前 PingCAP 的主要业务及团队规模?
黄东旭:目前我们在实现开源的分布式关系型数据库 TiDB,模型上参考了 Google 的 Spanner 和 F1,是 Google 内部的新一代关系型数据库解决方案,我们认为这是关系型数据库未来的方向。目前团队大概 30 人,大多数是资深的分布式系统工程师及数据库内核工程师。
CSDN:而公司目前最具代表性的产品是 TiDB,据说 TiDB 在设计上特别考虑了主流兼容性问题(MySQL),请问是如何设计的?跟中间件方案的区别是什么?
黄东旭: MySQL 兼容是我们早期做的一个很重要的决定,是一方面极大的降低用户的迁移成本,另一方面我觉得更重要的是我们需要从 MySQL 社区中收集大量 MySQL 的测试用例,来确保实现的正确性,目前我们从 MySQL 的源码中,社区的各类 MySQL Driver 和 ORM 中,各类使用基于 MySQL 作为后端的开源软件中收集了千万级别的测试用例,每在 GitHub 上提交一个 PR,我们内部的持续集成系统都会跑这些用例保证正确性。需要做到这个级别的兼容,走中间件的方案是没法做到的,比如举一个最简单的例子,中间件没有办法支持业务透明的跨行事务,而且隔离级别没法保证,这样一来,绝大多数的事务的测试就没法进行,第二中间件并没有强大的 SQL 引擎,很难支持一些 JOIN 或者子查询语句,这样绝大多数的 SQL 正确性测试没法进行。TiDB 其实正是我们看到的 MySQL 分库分表和中间件的种种局限后希望彻底解决 MySQL 扩展性问题的产物,如果还继续走中间件方案是治标不治本的,我们选择完整的重写了整个 SQL 层,从 Parser 到分布式 SQL 的执行计划引擎,除了文法上兼容 MySQL 的文法(即便如此,我们也没有复用 MySQL 的 yacc 文件),整个 TiDB 没有一行 MySQL 的代码,这样的结果就是带来了个更强的兼容性和灵活性,另外对于大多数复杂查询,由于 TiDB 是一个分布式的数据库,可以利用上分布式的优势及计算资源,对于很多复杂查询,会比 MySQL 会快的一个数量级。
CSDN:谈到开源软件公司 PingCAP,无法回避的一个问题是开源和商业化的问题,这里的矛盾纠葛,毕竟也是涉及到了钱,请问您是如何解决的?
黄东旭:国内其实一直以来都没有过一个顶级的开源项目,所以对于开源项目如何商业化一直都没有什么先例可以参考,我说说我的看法,首先开源和商业化并不矛盾,这个在 Red Hat 这样传统的 Lincese + 服务咨询模式已经能验证,至少路径是能走通的,但我觉得这种模式并不高效,未来会有新的模式出现。大客户并不会因为你的源码开放而不付费,因为对他们来说,有价值的并不是你的源码,而是你能解决他们的问题,运维支持,商业选件等都是产品的一部分,另外随着云的普及,对于基础软件来说,是一个绝佳的机会,开源+云会极度高效的触及你的目标客户,而且不会像传统软件那样给用户带来被方案绑架的感觉,而且对于一个分布式数据库来说,Scale 本身就是它的强项,当集群规模越来越大的时候,我们的维护和部署成本的增长是十分缓慢的,但是商业价值是可以不断 Scale 的,不管是资源的利用率还是维护成本,对客户来说一是解决了他们之前没有办法解决的事情,第二是没有方案绑定的风险 (开源+标准的 MySQL 协议),三是成本更低。我认为对于数据库这类对云来说高度标准化的服务来说,未来可能更理想的商业化路径会参考 SasS。至于还有一种说法是开源了被竞争对手抄走了怎么办?对于数据库这样的东西,特别又是大规模的分布式系统,要完全看懂源码花的时间估计和写一遍差不多,不过我们写了大量注释帮助开发者加速理解(笑),很多地方为什么这么设计,为什么不那么做,代码的背后有数不清的思考的过程,这个是没法写出来的。另外 TiDB 的主干分支和 Roadmap 是我们牢牢把控的,第三方分支是如果没有和主干合并,是很难有生命力的,这是开源社区的运行规律,就像不会有第二个 Hadoop,也不会有第二个 Docker,就是这个道理。另外,我们是一家彻底拥抱开源的公司,我们对于我们的设计和代码质量,以及严格代码审核有着充分的自信,所有的运作模式也是按照全球顶级开源项目的方向去的,这点只有开源才能让我们的每个用户直观的感受到这个软件的质量和背后团队的认真,反而会让我们进入正向的循环,这对于基础软件来说尤其重要。
CSDN:曾作为一名架构师,如今的 CTO,能否谈下您对架构的理解?
黄东旭:我认为软件架构首先是对问题的抽象以及一系列坚持的原则,这个抽象会反映作为架构师对于这个问题的理解,有意思的是,随着对问题的理解的深入,抽象本身的演化是渐进的,于是在这演进期间坚持的原则就会变得十分重要,问题的正确抽象会帮助你不断的适应当前,而坚持的原则会让抽象的演进过程能够不偏离主线以适应未来。
CSDN:您认为具备哪些素质才能成为是出色的架构师?
黄东旭:就目前的经历看来,我觉得是全局观。很多时候不能拘泥于细节和实现,当然实现也是很重要的,我是觉得不写代码的架构师就是耍流氓。但很多时候架构师的决策是需要从全局出发的,比如接口的设计,面对不同的技术方案坚持什么,如何从全局来控制复杂度,这些决定对未来都会有深远的影响。
CSDN:PingCAP 未来的路还很长,而停下脚步回忆过往,让您创业之中感触最深的是?以及目前觉得最大的难题是?
黄东旭:目前看来感触最深的就是找到了一群志同道合且在技术上非常厉害的小伙伴,而且在早期的一些比较正确的设计思路和技术选型让我们少走了很多弯路,目前看试上去还是蛮顺利的,和这些聪明人在一起工作真的是享受。在技术上我觉得最大的难题仍然还是测试,虽然我们已经在分布式系统测上走了很远,我们测试的代码量比实际数据库本身还要多,至少在开源世界我觉得少有项目能做到这个程度,但是我仍然觉得也就是刚刚及格,在追求分布式 determinstic test 的路上,其实学术界也没有太多的方法可以参考,目前能做到的也只能是极大的缩短暴露 Bug 的时间,我们在这上面有很多前沿的尝试,其实以后可以好好的分享一下。其实这也是我经常说的一个观点,实现一个数据库并不难,真正难的是证明你是正确的。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。