关于合并数据库的原因,可行性和实施方案讨论

相关链接

Zhou, Haigen

http://blog.jobbole.com/86708/

http://www.360doc.com/content/15/0407/05/22572810_461168912.shtml

https://jingyan.baidu.com/article/ab69b2709a350b2ca7189fa7.html

现状(我所了解)

数据库分区部署

• 预计每个区可能有定制化需求
• 每个区当不同的公司处理,分开实施,
• 可以分区上线,各个区可以用不同代码版本
• 当前以上问题没有在业务上有表现

当前数据分析方案

• 数据写入通过各分区api
• 数据查询通过union all跨分区数据分析

数据分析潜在问题

• 相同分区虽然不存在重复主键,但合并后必然存在.当前在主键,外键上加 'NR'|| 前缀

部分base部分代码不开源

• 如题

合并数据库方案研究(仅供参考)

当前表结构

• base基础表 需要源代码

• tr业务表

• doc底稿处理表

• efing表

统一主键策略(仅供参考)

• 分清头表,行表,明细表
• 为头表添加分区字段,并更新值为分区标识比如WR,ER,NR.....
• 修改代码中所有model主键为string(36)类型,用于存放uuid数据类型
• 每个表新增一列,作为预备新主键,使用uuid填充新列
• 根据新老主键更新关联表(行表,明细表)外键值
• 删除久的外键,主键相关索引和关系
• 合并不同区数据到一个数据库
• 互换老主键列和预备新主键列 列名
• 业务上能区分用户所属一个区或如同多语言一样能够切换用户所处分区
• 修改代码中的查询逻辑,保证查询的数据和当前所在分区有关
• 修改代码,保证写入的数据能正确填入所在分区标识

需要注意的地方

• 合并数据库后应该不存在分北京上海服务器的使用问题.只能部署在一个环境,否则即使its能做网络延迟优化,网络开销仍然是不可逾越的门槛
• 如果gms单独为一个项目,仍然存在相同问题
• 香港分区因为法律问题.需要独立部署,可能会存在修改代码情况
• 数据库合并后,同一个项目code只有一条,不像现在在各个区有一条数据
• 应用上就不存在四个区的部署环境.只有一套部署
• 待整理

解决方案

• 合并一个数据库作为数据分析使用,合并的复杂程度有主键规则决定
• 数据分析做单独服务.整合数据写入新的数据库 .(T+0.5,T+1......)
  • 将各个分区数据写入报表服务的时候,已经重新处理主键为uuid和插入分区字段的问题