Protogalaxy

Planet #0

PHSS-Core开发日志#4 再谈主键策略

在PHSS的设计初期,由于数据库设计经验·的不足以及对于数据库跨表ID唯一性的需求,在一番查询之后我选择了UUID作为整个系统的ID类型。但是在实际代码编写的过程中,由于采用了基于JPA的Hibernate Bootstrap方式,在fetching的时候需要使用JPA提供的基于EntityManager的·fetch方法,比如EntityManager.find()与EntityManager.createQuery()。但不尽如人意的是,在主键采用UUID类型的情况下,JPA所提供的Fetching方法出现了不可预知的问题:在UUID具体值已确定的条件下,使用entitymanager.find()方法通过UUID进行fetching,即使UUID正确,也会出现entity无法找到的问题,尝试两种fetching方式后都无法定位,并且Google和Stackoverflow查询未果后,最终还是决定更换主键策略。在更加深入地研究了各种主键策略之后,发现自己以前对数据库主键的理解还是存在一些问题,所以在这里重新总结一下关于数据库主键策略选择的各种要点。

PHSS-Core开发日志#3 预期功能与数据库架构

在开发初期,作为智能家庭服务器(Home server)PHSS在设想下应有以下功能(当然,只是设想。作为一个死宅程序员,其中还夹杂了点私货wwwww): 个人资料库管理:音乐专辑,视频,电影,动漫番组,电子书籍,插画,文档 个人日程与档案管理:日历,日程提醒,便利贴,番组信息,RSS订阅,新闻抓取 本地Git管理 Google Home与Apple Homekit功能接入,包括家庭用电量统计,智能家电自动控制与场景切换 安全性方面,在支持密码登录的基础上,加入生物信息登录与物理key登录 经过简单的初期设计,半成品数据库结构大致如下: 考虑到Google Home与Apple Homekit接入的复杂性,所以暂时搁置,目前只是大致设计出了个人资料库与个人日程档案的大致数据库结构。由于资料库系统在预期情况下可能发生大量文件读取,所以将文件系统的数据库结构做了一些范式化设计。

数据库设计与性能优化笔记整理

数据库设计范式: 总的设计思路大致为:消除数据冗余,避免插入/删除/修改异常 相关名词解释: 码:关系中的某个属性或某几个属性的组合,用于区分数据库中每条记录 函数性依赖:在一张表中,在属性/属性组中的X值确定的情况下,必能确定属性Y的值,这里的函数不是一种特定的数字关系,而是一种抽象的关系概念,比如学号→姓名。 传递函数依赖:有传递性的依赖关系,例如A→B,B→C,则C与A具有传递函数依赖关系。 1NF:即表中的所有属性都不可再分割,1NF为所有关系型数据库的基本要求。 2NF:在1NF的基础上,消除非主属性对于码的部分函数性依赖。 3NF:在2NF的基础上,消除非主属性对于码的传递函数依赖。 范式的优点与缺点: 范式的更新操作通常比反范式要快。 当数据较好的范式化时,就只有很少甚至没有冗余数据,所以修改所带来的开销会相对较少。 范式化的表通常体积较小,可以更好地放在内存中,所以执行操作会更快。 冗余数据较少意味着在查询检索时会更少需要DISTINCT或者GROUP BY语句。 范式化设计的schema的缺点是通常需要关联。稍微复杂一些的查询语句在符合范式的schema上可能需要至少一次甚至更多关联。这不但代价昂贵,也可能使一些索引策略失效。例如,范式化可能将列存放在不同的表中,而这些列如果在一个表中本可以属于同一个索引。 反范式的优点与缺点: 反范式化的schema因为所有的数据都在一张表中,所以可以很好的避免关联。 如果不需要关联表,则对大部分查询最差的情况–即使表没有使用索引–是全表扫描。当数据比内存大时这可能比关联要快得多,因为这样避免了随机I/O。 关于使用自增主键与使用UUID作为主键的主键策略对比(InnoDB): 首先介绍InnoDB的主键索引方式-聚簇索引:聚簇索引定义了表中数据的物理存储顺序,相邻主键的物理位置也是相邻的,按照大小排序。由于·UUID为无序数列,所以在索引时会降低索引性能,造成巨大的IO压力。 存储空间方面:UUID由于长度的关系,在数据量上升时会造成一定的存储压力 数据独立性方面:自增主键在合并表的时候可能会出现主键重复的情况,而UUID不仅是表独立的,而且是库独立的,在数据库切分与合并时比较方便 分布式存储:由于UUID的独立性,相比自增主键而言更适合与分布式存储 关于twitter开源分布式自增ID算法snowflake: Github:https://github.com/twitter/snowflake   部分内容摘自《高性能MySQL》,在这里也向想了解更多关于数据库设计优化的小伙伴推荐这本书,写的还挺不错的。