看看 Github 是如何升级最核心的数据库架构!
Yet at its core, GitHub.com remained built around one main database cluster (called mysql1
) that housed a large portion of the data used by core GitHub features, like user profiles, repositories, issues, and pull requests.
更为重要的是,从产品角度看,分布式数据库并不是一种用户体验非常好的产品。
分布式数据库,如 Spanner、OceanBase、TiDB 等注定不会成为未来 主流的 OLTP关系型数据库。
by 破产码农 2021年10月12日
”
回到 Github 数据库架构升级案例来看,Github 选择的是对数据库进行垂直拆分。
Github 首先对库表进行梳理,哪些表是随事务一起被访问,然后将其映射到一个虚拟库(Schema Domain)中,以便后期做真实的拆分。
接着编写了两个 SQL Linter 的 SQL 检查工具,以便在开发和测试环境中发现目前存在的跨域(Cross Schema Domain)访问 SQL,然后交由开发人员进行改写。
上述 SQL Linter 检查工具会自动向跨域的 SQL 添加一种特别的注释:/*cross-schema-domain-query-exempted */
这样就能在持续集成环境中确保后续发布的版本没有 SQL 跨域问题。
由于做了垂直拆分,为实现对上层业务访问的透明性,Github 使用了 Vitess 中间件,并使用 Vertical sharding 功能屏蔽下面的数据拆分。
Vitess 在国内并不怎么流行,其架构如下所示,感兴趣的同学可以看下:
对于实际数据的垂直拆分,Github 通过 MySQL 原生的复制技术。
最终,在经过这次数据库的架构升级后,Github 的核心数据库取得了如下的成果:
2019年,mysql1 集群 QPS 为 95W,主节点(Master) QPS 5W;从节点(Slave)的读取 QPS 为 90W;读写比约为 20 : 1。
2021年,mysql1 集群 QPS 为 120W,主节点(Master) QPS 7.5W;从节点(Slave)的读取 QPS 为 112.5W;读写比差不多依然为 20 : 1。
当前硬件技术发展迅猛,百核CPU、半T内存、千兆IOPS都已唾手可得。
加之关系型数据库新版本都在对多核、超速硬盘进行优化。
通过优化,单实例数据库 QPS 达到十数万并不是难事。
对于 Github 的数据库架构改造来说,我相信当然可以设计出一个分布式的 MySQL 架构,也可以设计一个 Redis + MySQL 的架构。
但上述两者的设计,对业务侵入巨大,对程序的限制变多,后期运营成本也是巨大。
真正好的架构设计应该大道至简,做减法而不是不断做加法。
所以,技术应该是服务于业务,而不是让业务去适应技术。
你说是不是呢?欢迎留言。
BTW,想要观看原文分享的同学,请点击下方的原文阅读。
直播预告
往期推荐
刚刚,我成功复活了 MySQL 祖先版本!
用 VSCode 编译和调试 MySQL,每个 DBA 都应 get 的小技能
VScode,yyds!用VScode编译和调试MySQL
老盖除名 Oracle ACE ,旧时代的终结!
收藏!最新《MySQL数据库开发设计规范》