Vitess

定义

Vitess是一个开源的数据库集群系统,用于对MySQL进行水平扩展^[1]。它位于应用程序与MySQL之间,通过分片把数据分散到多个MySQL实例上,同时向应用呈现统一的数据库接口;查询看起来像是在访问单台MySQL服务器,实际由Vitess自动转发到相应分片^[1]。

从架构定位上看,它属于数据库中间件或称数据库编排系统,支持MySQL与Percona Server for MySQL,可运行在公有云、私有云以及专用硬件环境中^[1]。其目标是让分片路由逻辑不进入应用代码,使应用层对数据分布保持无感。

原理

Vitess的部署由若干相互配合的组件构成^[1]。VTGate是一个轻量代理,接受来自应用的MySQL协议连接并把查询路由到正确的分片;VTTablet是运行在每个MySQL实例旁的代理进程,负责查询与连接管理以及复制;拓扑服务(topology service)保存集群状态,可采用etcd、ZooKeeper或Consul作为后端^[1]。应用使用任意MySQL兼容驱动连接VTGate即可^[1]。

分片的核心是虚拟索引(vindex):它是一个可插拔的函数,把某一列的值映射为keyspace ID,由此决定该行数据落在哪个分片。Vitess内置多种vindex,也允许用户自行扩展,查询规划器在可用的vindex中选择代价最低的一个。对跨越多个分片的查询,VTGate并行下发并合并结果。

系统还承担连接池、查询改写与去重等职责。VTTablet通过连接池把前端的海量连接映射到数量有限的MySQL连接上,从而在应用规模增长时不必相应增加数据库连接^[1]。此外,查询改写会为缺少限制的语句补充约束、避免非确定性更新,查询阻断与查询终止功能则可以拦截或结束可能损害性能的语句^[1]。

重新分片(resharding)通过VReplication完成:它先复制存量数据到新的分片,再持续订阅MySQL二进制日志使新旧分片保持同步,校验数据一致后原子地切换拓扑,切换期间VTGate会对进行中的查询做缓冲,使应用感受到的中断短于1秒。

发展历程

Vitess由YouTube在2010年创建,目的是应对其MySQL数据库遇到的扩展瓶颈^[2]。当时YouTube先为写流量设置主库、为读流量设置副本,读压力过大后又增加副本,写压力最终超过单台主库的处理能力,只能对数据分片,并在应用层写入判断目标分片的逻辑^[2]。Vitess的做法是在应用与数据库之间引入代理,把分片路由与数据库交互管理从应用源码中移除^[2]。首个组件VTTablet正是为限制连接数量而构建的。

该项目以Go语言实现,2012年在代码托管平台公开发布,并在同年的USENIX LISA会议上首次公开介绍。2013年,由于Google要求YouTube数据迁入内部数据中心,Vitess被迫运行在本地磁盘可被回收的调度环境上,由此加入了半同步复制与自动故障转移等机制,这些设计后来直接对应到Kubernetes环境下的运行方式。

2015年3月,Google Cloud Platform介绍了在云上结合Vitess与Kubernetes扩展MySQL的做法^[3]。2018年2月,云原生计算基金会的技术监督委员会投票接纳Vitess为孵化项目,它成为该基金会第16个托管项目;2019年11月,Vitess成为第8个毕业项目^[2]。2019年11月发布的Vitess 4.0扩大了SQL语法覆盖范围,并对VReplication提供了实验性支持^[4]。此后项目改为每12周发布一个版本^[4]。

应用

Vitess在YouTube承担全部数据库流量超过5年^[1]。YouTube最终把最大keyspace扩展到256个分片,单个主库对应80至100个副本,分布在20个数据中心。

在其他场景中,Slack、Square与京东等公司都在生产环境运行Vitess^[1]。京东此前使用基于cobar改造的中间件JProxy管理MySQL,经评估后选择Vitess,用于大规模数据库服务的可伸缩管理以及MySQL的在线扩容,并在Kubernetes容器环境中运行数据库^[5]。

电商平台Etsy自2010年前后采用分片MySQL架构存储大部分生产数据,包含约1000个分片、425 TB数据,每秒处理170万次请求;其团队用约5年时间、提交约2500个拉取请求,把分片管理迁移到Vitess的vindex机制上^[6]。

局限

Vitess兼容MySQL与gRPC服务协议,可在不修改应用代码的情况下替代MySQL服务器,但由于它是分布式系统,兼容性上存在差异^[7]。单分片事务保持MySQL默认的REPEATABLE READ语义,跨分片事务的语义则变为READ COMMITTED^[7]。跨分片写入可以借助两阶段提交实现原子性,但代价是明显的性能损耗^[8]。

在SQL特性方面,存储过程只能在不分片的keyspace或直接指定某个分片时调用,且不能返回结果、只支持IN参数,CREATE PROCEDURE也无法通过Vitess执行^[7]。临时表仅在不分片的keyspace中受支持;窗口函数与公共表表达式在当时尚未获得支持^[7]。分片keyspace中的表不支持auto_increment列属性,因为生成值只在各分片本地有效,Vitess提供序列作为替代。

负载约束方面,Vitess默认对查询执行时间和返回行数施加限制,这种默认模式称为OLTP,可通过设置负载为OLAP来关闭^[7]。因此,依赖大量跨分片事务、跨表外键或存储过程的负载并不适合直接迁移,横向分片本身也会增加数据模型调整的工作量^[6]。

参见

• MySQL —— Vitess 所代理并做水平扩展的关系型数据库。

• 分片 —— Vitess 的核心机制,把数据拆分到多个实例。

• Kubernetes —— Vitess 常在其上以容器方式部署运行。

• 云原生计算基金会 —— Vitess 的托管基金会,项目于 2019 年在此毕业。

• 连接池 —— Vitess 控制数据库连接数量的重要手段。