数据库版本化之路

数据库版本化之路

@(个人博客)[数据库, Migrate, 迁移]

[TOC]

database

当前数据项目的数据库运维工作存在一些问题，主要表现在：

1. 数据库版本管理不规范，全部通过手工修改，什么时候谁做了什么修改都不知道。
2. 当前有多个领域数据库，格式一致。但是经常出现只修改了一个领域，其他领域未同步修改。后续同步数据的时候就会出错。
3. 修改出错也不方便回滚（因为没有历史记录）。

因此，我们考虑引入版本化工具来对数据库修改进行管理。最早得知版本化管理还是从Rails中知道的，有非常成熟的版本化管理工具。我们数据项目大多使用Python，因此我们选择使用alembic来管理我们的数据库。

准备迁移工具

1. 安装Python3.6
2. 修改pip源为公司内部镜像，在C:\Users\用户名\pip目录下添加pip.ini文件，然后编辑其内容如下

   [global]
   trusted-host=cmc-cd-mirror.rnd.huawei.com
   index-url=http://cmc-cd-mirror.rnd.huawei.com/pypi/simple/
   

3. 安装alembic和pymysql

   pip install alembic pymysql
   

4. 输入alembic --help查看是否正常安装

迁移工具安装好之后，我们就可以进行数据库版本管理了。

新增数据迁移项目

我们专门在Gitlab上新建了一个data-processing的项目，用于管理数据库。由于我们的数据库存在多个，因此在准备迁移环境的时候也跟官方有小差异。

创建子领域数据库配置：

mkdir sub_domains
cd sub_domains
alembic init sub_domains

创建主查询库配置：

mkdir query_db
cd query_db
alembic init query_db

我们创建了2个数据库配置，后续操作的时候，都要cd切换到某个配置下面，然后在这个目录下执行alembic的命令。

修改迁移配置

以子领域数据库配置为例，编辑其目录下的alembic.ini文件，主要修改sqlalchemy.url配置：

sqlalchemy.url = mysql+pymysql://***:***@ak-devmysql.beta.hic.cloud:3306/archimedes_data

如果有使用同样数据库Schema格式的不同数据库，只需要复制下alembic.ini文件，修改里面的sqlalchemy.url即可。

配置好之后，我们的迁移环境就准备好了。

增加迁移脚本

切换到某个迁移环境下，就可以调用alembic的命令行来新增迁移脚本了。

使用alembic新增一个迁移脚本，-m参数使用英文来描述本次修改的原因：

alembic revision -m "add tags column to bigdata_p1p2_explain"

Generating D:\work\data-processing\sub_domains\sub_domains\versions\f891ab49c205_add_tags_column_to_bigdata_p1p2_explain.py ... done

每次新增迁移，alembic都会帮我们生成一个python迁移文件，我们要做的事情就是修改这个迁移文件，增加数据库的DDL操作。

我们要修改的就是里面的2个函数upgrade和downgrade。文件中已经自动帮我们import了op和sa，具体使用方式请参考Alembic文档。

def upgrade():
    op.add_column('bigdata_p1p2_explain',
                  sa.Column('tags', sa.String(500), comment="分类搜索标签")
                  )


def downgrade():
    op.drop_column('bigdata_p1p2_explain', 'tags')

我们使用op和sa提供的方法和类型来完成对应的DDL操作。这里有些同学要询问，为什么不用原始SQL？

1. 抽象。alembic底层使用的是sqlalchemy，支持多个数据库的抽象操作。比如我们的数据库如果从MySQL替换为PostgreSQL，只需要修改ini文件中的sqlalchemy.url，其余的就不用管了，帮我们屏蔽了多个数据库之间的差异。
2. 扩展。由于是python脚本，那可以做的事情就多了。完全可以在里面编写合法的python语句，来完成你的特定目的。SQL不一定能够支持（比如我要读取某个第三方API来做一些处理）。

修改迁移脚本时，请尽量编写完整。比如comment之类的。如果comment里面写不下，还可以在py文件中编写注释。多一些说明，少一些问题。

开发模式

data-processing有2个分支：

• develop用于存放部署到测试和类生产的版本
• master用于存放部署到生产环境的版本

一般的开发流程：

1. 本地使用PyCharm从develop新建特性开发分支XXXX
2. 在XXXX分支上新增迁移脚本
3. 推送到Gitlab上，并新建MR进行代码检视
4. 检视通过，代码合并并部署
5. 本地切换到develop并同步
6. 删除本地特性开发分支XXXX