Database Denormalization_系统设计笔记11

写在前面

为了解决数据库层的扩展问题,我们已经讨论了两种方案:

  • Replication:从单库扩展到多库,以承载更多的请求量

  • Partitioning:把单库(表)拆分成多库(表),打破单库的性能瓶颈

在(多机)多库多表的加持下,激增的请求量、数据量已经不再是难题,然而,除却数据量外,还有一个极其影响单库性能的因素——数据的组织方式

例如,在关系型数据库中,数据实体用二维表格(称为实体表)来描述:

实体之间的复杂关联关系(多对多)也通过二维表格(称为关系表)来描述:

因而经常需要多表联查才能得到目标信息,关系越复杂,读取性能越差,并最终像数据量一样成为单库性能瓶颈,制约着数据库层的可扩展性

那么,对于关系型数据库,有办法进一步提升数据读取性能吗?

有,(在一定程度上)改变数据的组织方式,即反范式化(Denormalization)

一.范式化

在讨论反范式化之前,有必要先明确什么是范式化,要反的东西是什么?

Database normalization is the process of structuring a relational database in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity.

范式化(Database normalization),就是按照一系列范式(Normal forms)要求来组织数据模型的过程,目的是减少数据冗余,提高数据完整性

试想,如果相同的信息在多行中重复出现,不相干的信息也凑在同一张表中,就很容易出现一些异常情况:

  • 更新异常:只更新单行,就会出现逻辑上的不一致

  • 插入异常:无法只插入部分信息,除非让其它列先留空

  • 删除异常:删除部分信息的同时,可能会波及其它无关信息

为了避免这些异常情况,人们提出了一些约束规则,即数据库设计范式

二.数据库设计范式

P.S.此外,还有BCNF4NF5NF等等,具体见Normal forms

类比应用层,设计范式相当于数据层的设计模式,对数据表进行解耦,使单表信息更加内聚,彼此边界分明,依赖关系更加清晰

我们一般把满足 3NF 的关系模式(Relation schema)称为规范化的(Normalized),大多数情况下都能规避上面提到的插入、更新和删除异常。然而,在解决这些问题的同时,范式化也带来了另一些问题

三.范式化的弊端

在这些设计范式的约束下,相关联的信息被存储到了不同的逻辑表中

A normalized design will often “store” different but related pieces of information in separate logical tables (called relations).

例如:

3NF

3NF

以致于经常需要多表联查(join操作),关系越复杂,连表查询越慢:

If these relations are stored physically as separate disk files, completing a database query that draws information from several relations (a join operation) can be slow. If many relations are joined, it may be prohibitively slow.

那么,有办法能改善查询性能吗?

有。引入冗余:

  • 允许 DBMS 存储额外的冗余信息,例如索引视图(indexed views)、物化视图(materialized views),但仍遵从设计范式

  • 增加冗余数据,减少join操作,打破设计范式(即反范式化

四.反范式化

所谓反范式化,是一种针对遵从设计范式的数据库(关系模式)的性能优化策略:

Denormalization is a strategy used on a previously-normalized database to increase performance.

P.S.注意,反范式化不等于非范式化Unnormalized form),反范式化一定发生在满足范式设计的基础之上。前者相当于先遵守所有规则,再进行局部调整,故意打破一些规则,而后者全然不顾规则

通过增加冗余数据或对数据进行分组,牺牲一部分写入性能,换取更高的读取性能

In computing, denormalization is the process of trying to improve the read performance of a database, at the expense of losing some write performance, by adding redundant copies of data or by grouping data.

在设计范式的约束下,数据表中没有冗余信息(某个数据只存放在某张表的某个单元格中),为了得到某个数据可能需要一系列的跨表查询,因而读操作性能不佳,但写操作很快,因为更新数据时只需要修改一处

反范式化就是要打破这种约束,把某些数据在不同的地方多放几份,以加快数据检索速度:

The opposite of normalization, denormalization is the process of putting one fact in many places.

具体操作

具体地,常见做法如:

  • 存一些派生数据:类似于往 Redux Store 中塞计算属性,把需要频繁重复计算的结果存起来,例如在一对多关系中,把“多”的数量作为“一”的属性存储起来

  • 预先连接(pre-joined)生成汇总表:把需要频繁join的表提前join

  • 采用硬编码值:把依赖表中的常量值(或者不经常变化的值)直接硬编码到当前表中,从而避免join操作

  • 把详情信息纳入主表中:对于数据量不大的详情表,可以把全部/部分详情信息塞到主表中,以避免join操作

P.S.关于反范式化具体做法的更多信息,见When and How You Should Denormalize a Relational Database

五.反范式化的代价

但除非必要,一般不建议反范式化,因其代价高昂:

  • 失去了数据完整性保障:打破范式,意味着之前通过范式化解决的更新、插入、删除异常问题又将重新冒出来,也就是说,冗余数据的一致性要靠 DBA 自己来保证,而不像索引视图等由 DBMS 来保证

  • 牺牲了写入速度:由于反范式化引入了冗余数据,更新时要修改多处,但大多数场景都是读密集的,写入慢一点问题不大

  • 浪费了存储空间:存储了不必要的冗余数据,自然会浪费一些存储空间,但空间换时间一般是可接受的(毕竟内存、硬盘等资源已经相对廉价了)

P.S.一般通过约束规则(constraints)来保证冗余数据的一致性,但这些规则又会抵消一部分作用

参考资料

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*

code