单片机|GitHub生产数据库架构优化和数据迁移 excel|操作系统|内存条

文章图片

文章图片

熟悉Git线上仓库平台的同学都应该知道Githb和GitLab的基础机构都是一样，开始的时候都是以Ruby on Rails 为应用服务架构，以Mysql数据库为数据库架构。 Gitlab经过版本迭代在Gitlab 9的时候数据库换成了PostgreSQL 。 Github由于是闭源只提供在线服务所以其架构演变我们对其知之甚少。最近GitHub随机数博客公布其数据库架构发展演变情况，请和虫虫一起来学习一下。
概述GitHub于2007年开发，其初始公司叫Logical Awesome ，三位创始人用Ruby on Rails共同开发。 2008年2月beta版本上线， 4月正式发布， 7月发布代码片段收藏的Gists功能， 12月发布网站托管的pages功能。 2009年issues功能上线，基本功能完备。
其初始的数据架构为Mysql单实例，用来保存其底层元数据。多年来，其数据架构经历了多次迭代，用以支持不断增长的用户规模发展和功能需求。比如某些对某些功能数据进行横向分库，也通过主从副本以，用多个数据库分开来做负载均衡，并通过ProxySQL中间件做统一代理。
GitHub的核心数据架构为一个主要的数据库集群（称为 mysql1) ，其中包含GitHub核心功能服务的大部分数据，例如用户配置文件、存储库、问题和拉取请求等元数据。
2019年，为了应对面临的增长和可用性挑战， GitHub制定了一个数据架构优化计划，以改进其数据架构和关系数据库分区能力。
截止目前，该优化计划取得显著效果，其mysql1数据集群主机的负载减少了50%? ，极大地减少了与数据库相关的事件数量并提高了GitHub用户业务的可靠性。
虚拟分区Github数据架构改进的第一个步是引了数据库模式的虚拟分区的概念。在物理移动数据库表之前，必须确保它们分离虚拟在应用程序层中，并且这必须在不影响开发新功能或现有功能的团队的情况下进行。为此，首先将统一在一起的数据库表分组到schema域中，并使用SQL linter强制执行域之间的边界。这样就可以在后续工作中可以安全地对数据进行分区，而不会以跨越分区的查询事务。
Schema域schema域是用于实现虚拟分区的工具。 Schema域描述了一组紧密耦合的数据库表，这些表在查询（例如，在使用表连接或子查询时）和事务中经常一起使用。例如， gists域包含所有支持GitHub Gist功能的表——比如gists gist_comments和starred_gists表。这些表是同属的，就应该一直在一起。 Schema域是对其进行编码的第一步。
schema域设置了明确的边界，并暴露了功能之间有时隐藏的依赖关系。在Rails应用程序中，信息存储在一个简单的YAML配置文件中
db/schema-domains.yml. 其一个示例如下：
gists:
- gist_comments
- gists
- starred_gists
repositories:
- issues
- pull_requests
- repositories
users:
- avatars
- gpg_keys
- public_keys
- users
linter确保此文件中的表列表与我们的数据库模式相匹配。反过来，同一个 linter强制将schema域分配给每个表。
SQL linter建立在schema域之上，两个新的SQL linter强制域之间的虚拟边界。他们通过添加查询注释并将它们视为豁免来识别跨越schema域的任何违规查询和事务。如果一个域没有违规，它就被虚拟分区并准备好物理移动到另一个数据库集群。
查询 linter查询linter 验证在同一数据库查询中只能引用属于同一schema域的表。如果它检测到来自不同域的表，它会抛出一个异常，并为开发人员提供一条有用的消息提示，以避免该问题。