文档深入探讨了数据架构师、应用架构师和数据库管理员之间的职责，聚焦于数据存储解决方案的选择和表结构设计的规范。同时，讨论了数据库运维规范、监控标准和数据生命周期管理的方法，以应对数据增长带来的性能和管理挑战。文档强调协作与最佳实践的重要性，确保数据的高可用性和一致性。

1. 架构师
• Data Architect
• Data Modeler
• Database Architect
• Application Architect
• System Architect
• 究竟各自负责什么？

2. 应用开发过程中对数据解决方案的需要
• 是否需要一个新的Data Store
• 业务Domain划分（企业架构师）
• 什么时候应该引入新的数据库/Cache/KV/Queue
• 数据应不应该保存在你的domain
应用架构师
• 数据库和缓存选型Guideline
• 究竟应该用什么Data Storage
• 关系数据库，Cache，NoSQL，MQ
应用架构师+DBA
• 表结构设计：
• 表结构设计规范，索引设计
• 工具支持和系统
• 跨Domain的表结构一致性
• 数据的分布和流转
数据架构师
• SQL的审核
• SQL开发最佳实践:wiki 和定期故障/优化分享
• 事先审核(sql review tool)
• 事后发现(slow log report)
• 工具支持
DBA提供工具，开发自己负责
• Data Store的高可用，容量，资源，隔离
• 写库:MySQL MHA, Oracle DataGuard
• 读库:LVS+多个Slave
• 隔离：Docker多实例
• 拆分：sharding 逻辑
• NoSQL: 各自不同
DBA
• 数据生命周期管理和维护
• 什么表，应该保留多久
• 数据字典
• 空间使用率报表
• 统一归档平台
Data Modeler+DBA
*16H2之前数据架构师把关：核心系统（电商平台）的表结构设计和归档

3. 数据架构师的KPI是什么
• 数据架构师：
• 究竟解决什么问题
• KPI是什么
• 对什么负责
• 数据架构师解决“哪些数据该存在在哪里 该去向哪里”
• 为什么要架构师：
• 解决设计和开发的问题
• 由资深开发经验，和运维经验人员担纲
• 抽象和提炼开发和运维过程中会碰到的问题
• 没有很强的开发维护经验，或者脱离开发和维护，就很难

4. DBA现在看到的痛点
• 上面PPT的红色部分，是DBA这边比较不好做的，有痛点的
• 谁负责，谁承担职责
• 痛点：
• 表结构设计不符合规范（越来越少）
• 业务开发Sql review不做（无法强制）：venus + regression 环境
• 业务开发不够积极推动和支持归档（空间和性能问题）
• 数据库/Cache越来越多：
• 究竟应不应该申请，
• 数据保存是否正确，
• 所选技术是否合适
• 滥用新技术

5. 数据架构：应用设计（乱）
• 是不是需要一个新的Data Store？
• 这个数据和其他数据是什么关系？你是Generator？还是一个
replication/reference？
• 是不是应该独立有一份自己的数据？还是调用人家的api？
• Cps 需要的订单信息
• 订单的客服数据：solr？
• 尤其是缓存？
• Goods 的信息你自己是否应该再保存一遍？
• Oauth的信息你自己是否应该再保存一遍？

6. Data Model
• 没有太多讨论的，数据架构师的工作
• 不是太大问题，下沉到各个Domain，基本上可以做好
• 数据字典的梳理

7. 方案选型（采用什么样的data store）
• 我个人认为是应用架构师和DBA一起来决定的
• 需要了解：
• 业务模式：读写量，数据量，读写profile，应用的场景 --应用架构师
• 各类数据解决方案的各自优缺点，团队把控能力 --DBA
• Guideline
产品线分类，PV/UV，前端/后端，最常用的请求对应多少QPS/TPS
• 最佳实践：典型的mongodb/hbase/redis的使用场景和方法
 Memcache常用于商品描述，HTML模板，用户登录Session，无需实施变化的数据，哪怕是缓
存10秒
 Redis常用于抢红包，用户关系，高速KV读写和数据固化/复制/Failover支持
 MongoDB：解决开发快速活动应用开发与设计及其上线的要求（schemaless，如活动设计）。
 Hbase常用于数据持久化存储，同时海量数据做计算。
 对于互联网应用来说，NoSQL一般作为缓存服务来用，数据在较短时间里临时存放，同时解
决大并发量用户访问请求，方便扩展。
 核心应用关系型存储选择是：MySQL/Oracle

8. 部署实现-DBA
• 已经确定有一个业务需求和实现方式了：
• 是用一个新的机器跑一个新的instance？还是读写分离？还是要shard？
• 还是一个现有机器上面起一个新的实例（单机多instance）？
• 还是用一个现有机器上面的现有instance上面新建一个新的db
• 还是用一个现有机器上面的现有instance上面现有db的新加一个表？
• 我的读写分离怎么搞？
• 我的跨机房部署怎么搞？
• 我的系统隔离怎么搞？

9. 数据架构设计：Cache
• 尽量避免同一份数据存在多个domain各自的Cache，避免缓存数据不一
致的问题（减少跨机房之间的调用允许各自cache但需要规范读写场景）
• 尽量避免同一份数据的不同修改入口（API服务）
• 跨机房的Cache调用和更新: 带宽和延迟
• 大对象的Cache的频繁调用: 带宽瓶颈，监控定位
• 热点Key的并发更新和回源: 秒杀
• Cache Server down的处理:
• by design, cache is just cache, just like cache miss , function should be ok
• 中间件的thread/load 瓶颈和连接池超时处理
• Control single instance load/traffic/qps
• 同一服务器Cache instance之间的带宽竞争：快速定位和资源隔离
• Redis/MC设计规范仅仅用于Cache，不做持久化选择。
• 什么时候使用Cache，解决什么问题

10. 定义数据库规范
• 数据库选型，设计和开发规范
• Schema合理设计，减少出问题的概率
• SQL规范（绝大部分的故障来自SQL产生的性能问题）
• 读写分离指导原则
• 方便以后的自动化管理（Review自动化功能）
• 数据生命周期管理
• 数据库运维规范
• 规范部署
• 版本选择
• 硬件选型
• 监控
• Online DDL及DDL规范
• DML数据备份
• 存储引擎选择
• 主从复制
• 可用性
• 水平拆分（sharding）
• 备份
• LVS使用场景

11. 定义数据库开发规范
• 数据库开发规范
• Schema合理设计，减少出问题的概率
 所有字段均定义为NOT NULL，一般字符为default ‘’/数值为default 0/时间为0000-00-00 00:00:00
• 不使用NULL的原因：（1）浪费存储空间，innodb需要额外一个字节存储；（2）影响MySQL优化器的选择，
从而影响性能。
• 有了上面的NOT NULL规范，带default是避免写代码有遗漏，导致线上故障，无法insert/update数据。
id unsigned bigint 自增作为主键的目的
• 适应大部分设计上不知道如何选择业务上什么样的数据是主键，那么定义一个没有业务意义的id增长主
键，方便统一。
• 分页，通过自增ID做分页条件：select id,col from tb where id >N order by id limit N,需要程序
记录上一次的id值。
 禁止存储过程，函数，触发器；禁止外键
• 避免一些bug
• 方便自动化运维
• Online DDL不支持外键，不支持表上有trigger
 统一UTF8（ utf8_general_ci ）
• 必须要统一一种字符集
• UTF8下，N表示的是字符数不是字节数，比如VARCHAR(800)，可以存储一篇字数不超过800字的高考作文

12. 定义数据库开发规范
• 数据库开发规范
• Schema合理设计，减少出问题的概率
 表一旦设计好，字段只允许增加，不允许减少（drop column），不允许改名称（change
column）
• 发布不需停机，避免影响功能或者避免异常数据
• 要求开发写SQL，禁止select */insert into tb value()，必须select col1，。。。colN
from/insert into tb（col1，。。。colN） value()
• 加字段禁止使用after，因为你不确定全局代码里面（如其他团队使用你的表/或者团队内其
他人）是否都insert into table（col，col，col。。。） value，如果你在中间插一个字
段，就导致数据偏移的问题了，影响可大可小，同样select * 有可能会影响数值的偏移
 不要使用TEXT、BLOB、char，请使用VARCHAR(N)
• 更少的存储空间，更少的磁盘IO，更少的网络IO
 所有表必须有create_time（程序维护）和last_update_time（MySQL维护）
• 方便后期数据分析与记录变化排查，哪怕只是配置表，只有10行记录;
• 可以得知数据在什么时间变化，后端BI分析，可以增量抽取
• Last_update_time由MySQL维护（DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP ），开发可以忽略

13. 定义数据库开发规范
• 数据库开发规范
• SQL规范：datatool自主review功能

14. 读写分离规范
• 读写分离指导原则
读写分离的好处
• 在相对简单的付出下可以解决系统读的性能扩展的需求
• 很容易实现读库的99.999%的高可用，如用户系统就算用户无法注册，也要已注册
用户能够登陆
• 可以某种程度上，降低大查询/报表类应用对在线系统的压力
读写分离的坏处
• 应用开发需要清楚知道什么时候读主库，什么时候读从库；避免延迟导致数据异常
（应用容错）
• 对开发的要求更高：不能batch job，时刻关注主库写容量变化预期什么时候达到
瓶颈
• 降低主库的写容量，超过这个容量从库延迟逐步增加，而主库的TPS其实可以到更
高

15. 定义数据库部署规范
• 数据库部署规范
• 部署规范
 一定要使用innoDB引擎（TokuDB引擎仅用于归档数据库，压缩比10+:1）
• 支持事务
• 行锁（MyISAM引擎是读写都会表锁）
• 支持崩溃恢复（未提交事务，可以回滚）
• 更先进的缓存，写策略（buffer_pool）
 数据库隔离级别：设置READ-COMMITTED（MySQL默认是REPEATABLE-READ）
• 容易产生幻读，但也要看业务场景有无必要重复读的要求
 操作系统与文件系统
• Centos 6.6 与 xfs文件系统（DB数据所在分区/sys/block/sdX/queue/scheduler要为deadline、Flash
为noop）
 MySQL版本选型（二进制版本即可）
• MySQL 官方版5.5.44+ 或者MairaDB 10.0.20+
 目录要规范：logs/soft/data
 主从都要求有虚拟IP，方便failover
 主从复制选择row模式(binlog-format=row)
• 保证主从数据一致，MySQL默认是mixed模式，绝大部分是statement方式，容易造成主从数据不一致
• 支持并发复制的MySQL版本需要row模式（如MariaDB 10.0）

16. 定义数据库部署规范
• 数据库运维规范
• 数据库硬件选型
 Faster CPU(more CPU)，例如E5-2697 v3（14core，2.6GHz）
 More Memory(Faster Memory)，例如DDR4-2133
 Faster IO(PCIe SSD, Raid SSD)
• 更多的是选择PCIe SSD，相比10块 * 600GB SAS Raid 10，价格贵30%，性能高100+倍
• 扩容
 对于写流量的扩容，首先上面的硬件Scale up，接下来是
• SQL tuning
• 功能垂直拆分，业务逻辑优化
 写流量的扩容：最后的一根稻草 Scale out
• 水平拆分带来的价值
 极大提升系统的数据处理能力
 极大降低单点失败的影响，100万用户分成128份，单个MySQL只影响100万/128
 备份恢复 变得更高效（要配合自动化）
• 水平拆分带来的挑战
 彻底无法做join
 如何选择合理的拆分key（维度）
 在线报表基本不可能，数据过于分散
 增加代码复杂度
 读流量的扩容：LVS + 多个从库

17. 定义数据库部署规范
• 数据库运维规范
• 备份规范
 每个机房备份中心
 采用分布式文件系统，glusterFS
 Xtrabackup 与mysqldump，每天一个全备
• 更多的是选择xtrabackup
• 高可用
 开源软件选择：MHA
• 不自动切换，手工一键切换（自动化）
• MHA通过调用shell管理虚拟IP
 跨机房failover很困难
• DB能做的是，跨机房从库，异地容灾
 同机房failover
• 写（主库）库failover，MHA配合虚拟IP漂移
• 读（备库）库failover，LVS或者Shell做一键虚拟IP漂移（MHA不保证备库高可用）
 Failover后业务数据会不会异常？
• 需要应用代码配合，保证整个系统”数据”的高可用，避免异常数据的发生。

18. 定义数据库监控标准
• 数据库运维规范
• 非常完善的监控和报警（立身之本）
系统监控
• OS：CPU、MEMORY、IO、NUMA、NETWORK、空间使用情况
• MySQL：TPS(INS/UPD/DEL)、QPS、并发数、连接数、主从复制(延迟/复制状态)、
slowlog、innodb rows status、show processlist、请求来源
业务监控
• 业务数据的监控，通过业务表的last_update_time对业务数据监控系统业务是否正常，
如用户每分钟注册等
• 大规模系统自动化运维
统一备份
统一部署
统一系统监控
统一高可用方案

19. 关于数据生命周期管理（归档）
• 数据生命周期管理
• datatool自动化归档工具
• 预期并避免数据增长超过归档速度，依据数据价值，设置合理的归档策
略
• 谁在关心，谁推动
• Why data archiving?
• 业务/功能开发多一些数据在线，一般不是坏处
• 因为实实在在碰到问题和瓶颈了：空间，性能，可管理性
• 归档，更多的motivation，来自技术能力的不足(有限的存储空间和成本)
• Dev其实一般不关心
• Architect/Ops（DBA）很关心