专访阿里云RDS团队：WebScaleSQL是一个怎么样的数据库？
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%。
褚霸：WebScaleSQL的目标并不是取代官方的MySQL，实际上它一直在跟随官方的GA版本在同步的升级。WebScaleSQL本身也在促进MySQL的发展。由于这个分支的影响力，我们相信一些补丁的在官方的合并速度会加快。
WebScaleSQL主干版本都是在官方GA版基础上，做了Bug修复、性能优化、新增功能等。当然一些细节需要注意，比如官方版本默认是编译了PERFSCHEMA，而WebScaleSQL从默认性能考虑，需要加上-DWITH_PERFSCHEMA_STORAGE_ENGINE 选项才会包含这个特性。要知道即使是官方版本，每个版本都有Bug，因此不论使用哪个版本，都必须进行业务测试。新增的代码在合并入主干之前，大多已经长时间运行于各自的生产环境。总体上我认为新增的补丁是高质量的代码，可以用于生产环境