数据密集型应用系统设计-数据模型与查询语言
date
Dec 10, 2021
slug
reading-notes-ddia-schema-and-query-language
status
Published
tags
读书
系统和网络
summary
type
Page
数据模型
大部分应用都是通过一层一层叠加数据模型来构建的。如业务开发使用对象和数据结构对真实世界的东西建模，这些模型又可以以不同的数据模型如 xml 或 json 的形式存储，存储层又将数据存储到不同的内存、磁盘或网络，更下一层则考虑的是数据的传输。
数据模型就是对数据的建模，是一种抽象，一种概括，不同的数据模型有不同的特性，有擅长做的和不擅长做的，就像数据结构有合适合不合适的场景。
关系模型和文档模型
关系模型最早由 Edgar Codd 于 1970 年在 IBM 工作期间提出，最早用在商业数据处理上，而现在已经应用到了各行各业中。与之对应的是 NoSQL，即不仅仅是 SQL，由于面向对象编程中需要繁琐的将对象和关系模型做映射，虽然有 ORM 提供了样板代码但还是不能隐藏两边的差异。
多对一和多对多
文档模型擅长将信息都存在一个地方，一次查询就够了，如个人简历。但对于引用 ID 一类的属性则不合适，这是可能需要在应用层多查一次，而这对关系模型来说更合适。
文档模型中的模式灵活性 schema flexibility
简单理解为文档模型中不要求数据符合任何模式，只有在读取时按照业务需要的模式解析就可以，有点类似动态类型（运行时）检查，而关系模型中会有要求数据一定遵守默写模式，类似静态类型（编译时）检查，哪个更优并没有准确答案。就像文档模型中增加字段很容易，而关系模型中则需要改动表结构。当数据类型无法确定时文档模型更合适，反之关系模型则更合适。
什么是模式 schema？
模式可理解为是一种定式、规范、限制。具体到 MySQL 中就是表、列、视图等等之上的一个抽象概念，相当于父类，定义了一些必须遵守的规则。到了具体例子中就是前面说的加减字段。
查询数据的局部性
文档模型将数据存储在一起，如果查询的是整个文档，则文档模型存储的局部性就很具有优势，反之如果每次只查询一小部分数据则不具备优势。
另外对于更新文档来说通常会重写整个文档。
总结关系模型和文档模型特点：
- 文档模型：
- 擅长处理一对一关系
- 善于将数据集中化、分层化
- 无模式限制，加减字段更加灵活
- 有局部性限制
- 关系模型：
- 擅长处理多对一多对多关系，
- 善于对数据分解和联接
- 有模式限制，加减字段不灵活
- 无局部性限制
查询语言
命令式查询和声明式查询
命令式查询和声明式查询区别，例如需求是给定一个动物物种的列表，返回列表中的鲨鱼，对比二者区别：
许多编程语言都是命令式的，命令式就是一步步告诉计算机怎么做：
对于关系代数可以这样写：
而 SQL 就遵循上面的关系代数结构：
命令式语言告诉计算机以特定顺序执行某些操作。可以想象一下，逐行地遍历代码，评估条件，更新变量，并决定是否再循环一遍。
在声明式查询语言（如SQL或关系代数）中，你只需指定所需数据的模式 - 结果必须符合哪些条件，以及如何将数据转换（例如，排序，分组和集合） - 但不是如何实现这一目标。这就跟函数式编程有关系了，函数式编程也是通过描述代数函数实现结果的。CSS 就是典型的声明式语言，声明什么样的标签应该有哪些样式。
MapReduce 查询
在 MongoDB 中是使用 MapReduce：
图状数据模型
图由两种对象组成：顶点 vertices，也称为节点 nodes 或实体entities，和边 edges，也称为关系 relationships 或弧 arcs。多种数据可以被建模为一个图形，例如社交网络、公路铁路图。
在属性图模型中，每个顶点（vertex）包括：
- 唯一的标识符
- 一组 出边（outgoing edges）
- 一组 入边（ingoing edges）
- 一组属性（键值对）
每条 边（edge） 包括：
- 唯一标识符
- 边的起点/尾部顶点（tail vertex）
- 边的终点/头部顶点（head vertex）
- 描述两个顶点之间关系类型的标签
- 一组属性（键值对）