你的位置:首页 > 数据库

[数据库]schema设计


Schema设计

 
Schema:表的模式;
 
设计数据的表,索引,以及表和表的关系
  1. 在数据建模的基础上将关系模型转为数据库表
  2. 满足业务模型需要基础上根据数据库和应用特点优化表结构
 
关系模型图:

 

 


Schema关系到应用程序功能与性能
  • 满足业务功能需求
  • 同性能密切相关
  • 数据库扩展性
  • 满足周边需求(统计,迁移等)
 
关系型数据库修改Schema经常是高危操作
     Schema设计要体现一定的前瞻性
 
完全由开发者主导的Schema设计
  • 着眼于实现当前功能
  • 完全基于功能的设计可能存在一些隐患
    •    不合理的表结构或索引设计造成性能问题
    •    没有合理评估到数据量的增长造成空间紧张而且难以维护
    •    需求频繁修改造成表结构经常变更
    •    业务重大调整导致数据经常需要重构订正
 
基于性能的表设计
  • 根据查询需要设计好索引
  • 根据核心查询需求, 适当调整表结构
  • 基于一些特殊业务需求,调整实现方式
 
索引
  • 正确使用索引
  • 更新尽可能使用主键或唯一索引
  • 主键尽可能使用自增ID字段
  • 核心查询使用覆盖索引
    •           用户登录需要根据用户名返回密码用于验证
    •           create index idx_uname_passwd on tb_user (username,passwd);
    •           建立联合索引避免回表取数据
 
 
设计举例

 
1 反范式,冗余必要字段


2 拆分大字段

 


3 避免过多字段或过长行
 
 
4 分页查询:

 
 
 5  热点读数据特殊处理


 
 
 6 热点写数据特殊处理

 

 


7 准实时统计

 


实时统计改进1--触发器实时统计

 


实时统计改进2-缓存实时统计

 



实时统计改进3-最大自增ID获取总数

 

 
8  可扩展性设计

 


9 分区表与数据淘汰
range分区

 



list分区

 


hash分区


 
10 满足周边需求


统计和后台需求


11 自动更新时间戳

 
Schema设计与前瞻性
  • 基于历史经验教训,预防和解决同类问题
  • 把折腾DBA够呛的索引Schema改造的原因记录并分析总结
例子:
业务为了用户信息加密做了大改造
  •  数据库结果大量改动,增加了加密字段,验证策略表,所有表重新订正数据等等
  •  是否所有用到用户信息管理的应用都要去上线就用密文?

 


 总结


 
  •  schema设计关系性能
  •  反范式,冗余必要字段
  •  拆分大字段
  •  避免过多字段或过长字段
  •  分页查询
  •  热点读数据特殊处理:置顶表与普通表分开
  •  热点写数据特殊处理:
    • 微博普通用户发消息,则写入关注他的人的消息列表中;微博大V发消息,则关注他的人都去读他的消息列表;
  •  准实时统计:
    • 定时统计表,更据上次更新时间统计全表中增量sum值,每分钟更新统计表;
  •  实时统计:
    • 触发器实时统计,在用户插入时,更新统计表;
    • 缓存实时统计,应用将用户新增写在内存缓存中,业务平时从缓存中读,缓存失效,从数据库做一次查询,接着写在缓存;
  • 分区表与数据淘汰
  • 满足周边需求:
    • 如后台统计任务而增加特殊索引,
    • 为数据迁移或统计增加时间戳
  • 自动更新时间戳
  • schema设计与前瞻性