系统设计之数据模型

Posted 2021-12-17 cdai

最近终于有时间，拜读了《Designing Data-Intensive Applications》的第一部分。这本书的豆瓣评分高达9.1，被奉为系统设计面试的“圣经”。个人觉得第二章逻辑数据模型和第三章物理存储实现最为经典，这也是这篇读书笔记内容的主要来源。

---

数据模型（或数据结构）可能是软件开发中最重要的部分，因为它不仅影响如何写代码，更重要的是它会影响我们如何思考要解决的问题。著名的《人月神话》里有专门一章讲述数据结构的重要性。其中有句让我印象深刻的话：“”。一个典型的应用程序可能包含很多层次，每一个层次都是由一套数据模型加上API（语言）来定义的。代码构建的一个主要问题就是：如何在下一层数据模型的基础上表示要解决的问题。比如，从最上层的业务逻辑开发，到中间的数据存储，到底层的操作系统。

---

1.数据关系

数据与数据之间的关系可以分为一对多、多对一和多对多，比如人和，人和，人和爱好。为了表示数据和这些关系，人们提出了各种数据模型。在上世纪70年代，IBM的信息管理系统风靡一时。当时它使用了一种最简单的层次模型（hierarchical model）。它类似于现在的文档模型（document model），把相关数据都嵌套保存在一起，因此只能用来处理一对多的数据关系。为了表示多对一和多对多的数据关系，有人提出了关系模型（relational model）和网络模型（network model）。前者就是如今关系型数据库的基石，而后者则为现在图模型的提供了理论基础。

---

2.文档模型

文档模型在现今NoSQL里非常流行，比如Elasticsearch和MongoDB。但不要因此觉得它是新鲜事物，如上文所说，其历史其实可以追溯到1970年IBM的IMS系统。它的核心思想很简单：将所有相关的数据都保存到一个文档（一般为JSON格式），从而实现一对多的关系：

• 优点：
  • 灵活的Schema
  • 更好的Locality
  • 更贴近应用代码里的对象
• 缺点
  • 无法直接访问内层的数据
  • JOIN支持很弱

最后一点对于分析型应用也许根本不是问题，多对多的数据已经保存在一起，可能JOIN即便支持也没有多大用处。

---

3.关系模型

所有数据库课都绕不开的关系模型，可能是我们最熟悉的数据模型。它定义了几种范式，将数据分解为多个关系（数据库表）。不同的关系一般通过唯一的ID来互相引用，实现多对一和多对多。将文档模型的优缺点反过来看，就是关系模型的优缺点。严格的Schema定义，与应用程序中对象天然的阻抗（impedence mismatch），JOIN经常要用到所以支持很强，因为没有嵌套所以可以直接访问任何数据。

书中提到了两个很有趣的趋势：

1. 历史不断被重复：比如层次模型和文档模型，就像流行时尚一样来回往复，换汤不换药；
2. 事物之间不断融合：比如现在的SQL标准里也加入了对多值column的支持，而NoSQL也在完善对JOIN的支持。

---

4.图模型

图模型与关系模型一样，都是为了表示多对多的关系。两者最大的不同是：多对多的关系在图模型里是“一等公民”，作为图的边直接保存到数据库表。查询执行时会遍历图里的很多边，直到找到想要的结果。换句话来说就是，JOIN的个数是事先不清楚的。而在关系模型中，多对多的关系是隐含的。它通过主表里的某一列来存储另一张表的ID（外键），查询时需要给定JOIN的个数。正因为这些区别，图模型很适合表示复杂的关系，比如社交网络。