2015 年 1 月 20 日, Facebook 宣布阿里巴巴旗下的阿里云 RDS 团队正式加入 WebScaleSQL。WebScaleSQL 是 Facebook、 Google、Twitter 和 Linkedin 四家公司的 MySQL 团队发起的 MySQL 开源组织,旨在改进 MySQL 在规模和性能等方面的问题。阿里云 RDS 团队有专门的源码小组负责 MySQL 源码级别的改进,他们也经常活跃在 MySQL 社区中,此次受邀加入 WebScaleSQL 组织也是对他们工作的肯定和认可。近日,InfoQ 编辑采访了 RDS 团队的负责人褚霸,听他分享了整个邀请的背景以及接下来的工作重心。
InfoQ:阿里巴巴受邀加入 WebScaleSQL,与 Facebook、Google、Twitter 和 Linkedin 这样的世界顶级团队共同研发 WebScaleSQL,这可以说是中国公司在国际开源项目上的一次亮剑。能介绍下整个受邀的背景和过程吗?
褚霸:阿里云 RDS 团队有 MySQL 源码小组专门负责维护阿里云的 MySQL 分支。团队的主要工作是源码级别上的改进,包括 Bug 修复、性能优化和定制化需求等。在我们改进过程中,如果是 Bug 修复类型的补丁,或者是足够通用的 feature 类型的补丁我们都会同时提交到上游,包括 Oracle 官方、MariaDB 和 Percona 分支。阿里云 RDS 现在有大量的 MySQL 用户,在系统维护和服务用户的过程中会碰到各式各样的问题,我们在解决过程中也经常发起讨论,在社区是一个活跃的团队。
WebScaleSQL 其他四家公司的参与者也是社区内的专家,讨论技术问题时经常互动,我们的工作大家也是比较了解的。因此在希望扩大 WebScaleSQL 的参与人员的时候,会邀请我们是情理之中的。最初是 Facebook 的一位华裔员工先联系的我们,然后我们也很快做了确认答复,整个过程是比较顺畅的。
InfoQ:能介绍下 WebScaleSQL 吗?它有哪些吸引人的特性?接下来阿里云 RDS 是否准备使用 WebScaleSQL?
褚霸:WebScaleSQL 是基于 MySQL 5.6 社区版本改编的 MySQL 通用分支,基于 GPL 开源协议发布。WebScaleSQL 目前已经做了很多性能改进工作,包括:客户端异步协调、逻辑预读、查询限流、服务端线程池优化、InnoDB 大页支持等等。由于我们的分支上本身有一些定制化的需求,因此不会直接使用 WebScaleSQL 分支提供线上服务,但是这些改进对于我们都是很感兴趣的,好的特性会被吸收进来。因为我们有各种各样应用场景的用户,对 MySQL 本身的要求也比较高。比如大并发连接的用户,就需要线程池;存大量历史数据的用户,就要求高的压缩比等等。
WebScaleSQL 上的功能都是很“Web Scale”和接地气的。
比如线程池优化,大家都知道线程池是 Mariadb。WebScaleSQL 基于 Mariadb 的线程池实现进行重写并优化,对读写队列进行分离,重新设计队列优先级策略,避免了饿死现象。要知道线程饿死在有些场景下是很严重的。尤其是在并发连接数往往很大的互联网应用里面。
语句自动超时是一个很“WebScale”的特性。随着数据量的增大,同样的 SQL 的语句执行时间会越来越长。而语句执行期间占用的资源也可能越大。若不加以限制可能几个语句就可能拖垮一个服务,在互联网应用中这种场景更常见。WebScaleSQL 引入了来自 Twitter 工程师的代码,可以设定单语句的执行时间,超时则自动放弃。对数据库起到保护的作用。
GTID 是 Oracle 官方版本 5.6 引入的新概念,在解决主备切换,尤其是级联主备架构的切换方面提供了很大的便利。阿里云 RDS 的只读实例就直接利用了这个特性,其实现上还有可以优化的空间。系统需要维护一个全局的结构,在高并发更新场景下性能非常差。WebScaleSQL 优化了事务提交过程,减少了不必要的 GTID_OWNED SET 的维护。主库高并发更新的性能可以提升 20%。
InfoQ:阿里巴巴加入 WebScaleSQL 团队后,接下来具体会有哪些方面的工作?你们团队会有专职的人去开发 WebScaleSQL 吗?
褚霸:具体的工作其实已经展开,主要包括提交补丁和代码 review。我们团队都是专职的 MySQL 研发,但是不会专职开发 WebScaleSQL,实际上参与 WebScaleSQL 的维护工作都是在晚上和周末时间完成的。在开发和 review 阶段,使用的是 Facebook 内部的一个 review 平台,最终代码合并是在 GitHub 上。
这个是松散的组织,大家都可以主导一个功能。在邮件组里面沟通,之后在 review 平台交互。代码被 review 过后,由发起人提交到主干。团队内部主要的沟通方式还是邮件,也没有固定的 IM 沟通时间,成员之间需要点对点沟通的时候自己约。每个公司有 3~4 个人在里面,人力上不确定,其实是用的都是大家的私人时间。
InfoQ:自从 Oracle 收购 Sun 公司后,MySQL 社区开始走向分裂,出现了很多 MySQL 的分支,你认为像 WebScaleSQL 这样的分支会不会取代 MySQL?它们会影响 MySQL 的发展吗?你建议用户直接在生产环境使用这些分支吗?
褚霸:WebScaleSQL 的目标并不是取代官方的 MySQL,实际上它一直在跟随官方的 GA 版本在同步的升级。WebScaleSQL 本身也在促进 MySQL 的发展。由于这个分支的影响力,我们相信一些补丁的在官方的合并速度会加快。
WebScaleSQL 主干版本都是在官方 GA 版基础上,做了 Bug 修复、性能优化、新增功能等。当然一些细节需要注意,比如官方版本默认是编译了 PERFSCHEMA,而 WebScaleSQL 从默认性能考虑,需要加上 -DWITH_PERFSCHEMA_STORAGE_ENGINE 选项才会包含这个特性。要知道即使是官方版本,每个版本都有 Bug,因此不论使用哪个版本,都必须进行业务测试。新增的代码在合并入主干之前,大多已经长时间运行于各自的生产环境。总体上我认为新增的补丁是高质量的代码,可以用于生产环境。
InfoQ:之前和你也聊过开源方面的话题,新的一年我们看到微软、华为这样的公司都非常重视开源,开源是大势所趋。阿里巴巴此次加入 WebScaleSQL 团队,也是中国公司在开源方面得到认可的一个很好的例子,你认为一个公司如何才能做好开源?
褚霸:其实大家都是开源的受益者,首先就是要保持开源的初心:回馈社区。我们评估后觉得足够通用的补丁都会提交到 WebScaleSQL 或 Oracle 官方。还有坚持参与社区讨论、提交满足主干代码质量的补丁这样的工作其实很耗心力的,持续投入不容易,需要真正的兴趣驱动。
我们公司对团队在开源方面是很支持的。公司有淘蝌蚪这个开源平台,可以说阿里不止是开源的参与者,也是倡导者。我们团队内部对团队同学在社区的贡献也是给予很高的认可。建议和代码被社区接受对工程师个人来说也是很有意义的。仅 2014 年我们团队在社区提交的 Bug 和补丁被确认的就超过 40 个。活跃的个人和团队更容易得到社区的认可,此次 WebScaleSQL 邀请我们参加维护也是如此。社区的认可也更促进个人的活跃,我们觉得这是良性的互动。
参与开源代码的维护,我们能够最快了解业内最新的动态,最大的收获还是在于我们可以学习全球顶级专家的经验,每个代码的方案设计过程、讨论过程、代码 review 过程都和结果一样,可以让我们从中学到很多东西,团队成长也会很快。
评论