数据密集型应用中的数据模型与数据语言

思维导图

一般我们在工程中采用分层架构。分层架构都有一个基本的特点：每一层都通过提供一个简洁的数据模型来隐藏下层的复杂性。要是你分层后获取下游数据更复杂或者要理解下游很多信息，那可能分的不好或者采用的数据模型有问题。

关系模型与文档模型

一般常见的数据模型就两种：关系模块和数据模型。关系模块最著名的就是SQL,文档模块现在最常用的应该是MongoDB了吧。

NoSQL

现在含义是“不仅仅是SQL”。现在经常和关系数据库一起使用，称之为“混合持久化”。一般使用NoSQL数据库有几个驱动因素：

• 比关系数据库更好的拓展性需求，性能好，吞吐量大
• 关系模型不能很好地支持一些特定的查询操作
• 关系模型限制性太大，例如不能自由添加字段

对象-关系不匹配

面向对象使我们常用的，SQL数据库也是我们常用的，但是看看我们的代码，一般代码里面定义一个结构体，SQL里面声明一张表，它们之间往往需要一个转换层，尽管字段可能一模一样，但还是要一个转换层，现在常用的orm框架例如大名鼎鼎的GORM就是干这事的，减少了转换层所需的代码量。

一般来说，我们会采用两种方式存储一份对象数据：json化或拆分表。

使用json方式存储，对象和数据库对象之间的差异比较小，但是缺点就是没办法复用，也没有办法反向查询。而消除重复，增加复用性正是我们所追求的。

读时模式和写时模式

读时模式

数据的结果是隐式的，只有在读取时才解释。这就是文档模型的特点。

写时模式

模式是显式的，数据库确保数据写入时都必须遵循。关系模型的常用模式

图模型

图由两种对象组成：顶点(结点或实体)和边(关系或弧)，很多数据都可以建模为图，例如社交网络中，顶点是人，边指哪些人彼此认识。

图强大之处在于，提供了单个数据存储区中的保存完全不同类型对象的一致性方式。

图有利于演化：向应用程序添加功能时，可以很容易地拓展亿适应数据结构的不断变化。