关于读书:数据密集型应用系统设计-数据模型和查询语言

sjmj《数据密集型利用零碎设计》– 数据模型和查询语言

概览

• 事实世界的 API 和相干程序作用于某个特定畛域解决现实生活的某些问题。
• 存储数据的模型能够使 JSON 也能够是 XML 类型。
• 如何展现以及示意 JSON，以及如何操作和解决数据模型使利用开发人员天职工作。
• 越底层的工程师须要思考的内容越多，须要具备过硬的软硬件常识。

NOSQL 诞生

第一局部讲述了 NOSQL 为什么会主键由关系模型倒退而来。以及介绍了历史长河中已经被尝试的一些模型信息。

NOSQL 之所以越来越受欢迎，次要是上面几个特点：

• 相比关系型数据库更加灵便的存储模式，反对大的数据集和写入吞吐量。
• 对于一些特定查问操作须要 NOSQL 实现。
• 开源收费的产品更加受到欢送。
• 关系型数据固有的一些毛病，NOSQL 更灵便的表现形式。

对象关系匹配问题

所谓对象和关系的匹配问题指的是在一个看似简略的事实对象中，如果通过关系型数据库往往须要较多的表之间造成关联关系能力残缺展现。

而应用 NOSQL 数据模型，则能够间接通过一个 JSON 模型，展现一个对象的多种嵌套关系。

尽管 ORM 框架某些水平上解决了数据库数据和对象模型的映射问题，然而并不能齐全解决灵活性问题，在 NOSQL 上不存在灵活性限度。

最终一对多的关系模型因为不匹配呈现了树状构造：

多对一和多对多

多对一须要应用惟一 ID 进行关联，应用惟一 ID 的益处是一旦创立就不须要更改，自身的无意义特点也决定了不会被轻易扭转的特点。

如果不应用关联，则多对一的展现须要的是屡次关联查问的操作，把一个对象的内容拆分为多个查问搜寻。

所以一个单体对象在最后非常适合应用繁多的关系模型，而在后续得扩大之中发现对象的嵌套应用关系型数据库尽管也能实现，然而带来是臃肿和业务简单的加剧。

显然文档模型在解决关系的层面上更加灵便。

网络模型

网络模型是因为 CODASYL 的标准化被提出，最原始的数据库数据库能够看做是不同厂商施行的 CODASYL 模型。

对于网络模型的历史，能够看看 wiki 的相干介绍：

CODASYL – Wikipedia

CODASYL 属于层次模型的推广，网络模型的架构之下每个记录可能多个父节点，通过一个节点服务多个纪录，实现一对多和多对一的模型。

关系链路和关系模型的主键以及外键不同，应用的是相似链表指针串联的形式连贯，多对多的关系模型，须要正确的找到“父节点”，能力再反复的数据中找到匹配后果。

网络模型仅仅是作为过后历史背景下解决无限硬件资源搜寻慢的问题解决的，最大的毛病和他的特点一样，就是这个 非凡的“父节点”，为了寻找一条关系链路，须要精确找到父节点，显然这种模型是简单并且难以保护的。

CODASYLwiki 解释：CODASYL – Wikipedia

关系模型

关系模型定义了表和元组（行）的汇合，反对任意的条件搜寻和表中主外键清晰的逻辑构造，迅速取代网络模型从而失去疾速倒退。

尽管关系型数据库的扩大带来的是越来越简单的关系模型，然而关系模型的最大特点是只须要构建一次查问优化器就能够使得所有的应用程序都能够通用。最终 查问优化器 解决了网络模型链路查找的痛点问题。

文档模型比拟

文档模型为了解决关系模型的复杂化诞生，文档模型的关系也就是外键信息被叫做文档援用，能够通过间接链接查问和解析嵌套“关系”，所以这种设计并没有遵循网络模型繁多父节点的特点。

文档模型和关系模型

现今的数据和网络结构通常是文档模型和关系模型的联合，文档模型能够聚合多个关系表的内容仅限一次展现，然而如果存在多对多的关系，因为文档模型的自在肯定水平上须要应用程序进行限度和防备，在这一层面上关系模型显然胜任多对多的解决。

针对关系模型的字段扩大通常须要小心谨慎的实现，比方在 MYSQL 种批改表 alter table 须要建设
新的 BTree 树并且进行拷贝工作，如果表十分大会十分久的停机工夫。

一种解决形式是通过建设新表拷贝旧表的数据导入来实现，能够保障不受影响的状况下实现备份操作。如果须要聚合多个对象的内容，应用文档模型显然更加适合，而应用关系模型则须要保护宏大的多表构造。

查问局限性

文档模型的瓶颈呈现在自身的数据结构上，尤其是 JSON 或者 XML 格局，存储和更新文档模型在文档模型较大的时候磁盘 IO 的开销比拟大，大文档模型的查问效率也会越发效率低下。

对于文档模型的 JSON 以及 XML 优化，将在第一局部的第四章节进行更具体的解说。

关系模型和文档模型交融

支流的数据库在文档模型的倒退之后，逐步引入了对文档模型的兼容，比方 Postgresql 在 9.3 之后引入了 JSON 的 API 以及原生 JSON 的存储反对，反对文本以及二进制的存储。

而在文档数据库方面同样存在反向联合关系数据模型的特点，比方 MongoDB 能够主动解析数据库的援用关系转化为文档模型。

目前看来最终将来两者的模型构造是交融而不是一方取代另一方的模式。

数据查询语言

申明式查问

所谓申明式查问指的是只须要数据模型以及制订后果，通过形象转化数据以及数据显示实现这一个指标实现数据模型展现逻辑上的形象。

换句话说申明式的查问只关注整体的标准，不关注具体的实现，然而在 SQL 中存在诸多限度，所以 SQL 也存在许多的优化空间，太过自在和不够自在是申明式查问的长处和毛病。

以此为代表的的申明式查问有上面几种构造：

• SQL
• WEB 标签

命令式查问

命令式查问的益处是对于业务解决的灵活性十足，相比于申明式的形象和难以排查，命令式的查问则具备较强的逻辑性和可排查行。

当然命令式查问最大的问题是随着逻辑的简单，命令会越发的难以浏览，如果不加以重构最终就会造成无奈浏览的代码。然而不管怎么说相比拟申明式语言，命令式显然更容易了解一些。

MapReduce 查问

MapReduct 是一种编程模型，次要作用是在多机器下面晚餐海量数据处理，最后由 Google 提出。对于这一数据结构的探讨在第十章也有更为具体的探讨。

上面是可供参考的原始论文：

[[Mapreduce.pdf]]（Obsidian）

[[三大论文中文版.pdf]]（Obsidian）

MapReduce 查问是一种介于申明式和命令式之间的一种组件，代码片段能够被解决框架重复调用。

次要的函数分为 map 函数和 reduce 函数。例如，假如 observations 汇合蕴含如下两个文档：

将上面的的 SQL 进行 Map 和 Reduce 函数操作

SELECT date_trunc (’month’, observation_timestamp) AS sum(num_animals) AS total_animals

FRO 问 observations

WHERE family= 'Sharks’GROUP BY observation_month ;

对于这个查问，首先须要编写相干的 map 和 reduce 函数对于实现下面的雷同成果：

db.observations.mapReduce(function map() {@ var year = this. observation Times tamp . getFull Year(); var month = this .observationTimestamp .getMonth() + 1; emit (year +”-”+ mo『1th, this . numAnimals); €>

},

function reduce(key, values) {e return Array . sum(values); ©

query: {family :”Sharks"} , 0 out :”monthlySharkReport”@

每个文档都会调用 一次map 函数，从而产生Emit ('’1995 - 12 4）。随后，reduce 函数将被调用，reduce (“1995 – 12”,【3 ,4】），最终返回总和 7。

留神 在这个例子中 map 以及 reduce 函数须要依赖 纯 JS 函数 来实现操作，传递进去的数据作为输出操作同时不能实现数据库查问的操作。

这些限度保障数据库查问能够在任意的地位运行函数，一旦失败从新运行即可，所以最初发现 MapReduce 特点是一个相当底层的编程模型，用于在计算集群上散布执行。

MapReduce 的一个可用性问题是，必须 编写两个亲密协调的 JavaScript 函数，这通常比编 写单个查问更难，此外 MapReduct 编写高级函数执行相干操作这比写单个查问要还要难上不少。

如果书中的句子难以了解，咱们能够换用 IBM 官网的介绍，集体认为比拟直观的显示这两个函数的意义。

相似上面的状况，如果咱们要对汉堡进行分类，抽出外面的所有内容，首先咱们须要用 map 函数把汉堡分类为一个个局部，而后再通过 reduce 函数对于雷同分类的内容进行合并。

最终后果就像是上面这样，咱们通过汉堡的归类组合，拼接出多种不一样的汉堡：

最终通过 JSON 的形式进行展现

对于不同函数的调用，最终实现不同模式的数据以获取不同的数据统计信息，这种相似灵活运用 SQL 函数的后果，使用 Reduce 的各种变动是十分有意义的。

图数据模型

图数据模型相比其余几个模型来说简单很多，然而理论应用图数据库的厂商通常制订了一套图数据模型查询语言帮忙开发者升高门槛。

集体始终认为图模型才是人类思考的最终模式，因为这种模型实际上更像是对于“网络模型”的变种和拓展，从图中也能够看到“父节点”自身的界线理解的更加清晰。

图的次要思维是顶点（也叫做节点或者实体）以及 边（关系和弧）进行建模。

典型的案例能够间接看上面的图形：

图模型通常具备上面的特点：

1. 弱小的灵活性，顶点和顶点之间的关系不受限制，没有强制的措施否定事物的关联。
2. 利于演变和扩大，编写一个关系模型受到数据模型自身的影响比拟小，在扩大中复杂化数据结构对于图模型自身也具备兼容条件。

上面探讨的内容波及了 Neo4j 为代表的图数据库实现，Neo4j 也是市面上较为成熟的图数据库。

属性图

在属性图模型中，每个顶点包含：惟一的标识符、出边的汇合、人边的汇合、属性的汇合（键-值对）

每个边包含：惟一的标识符、边开始的顶点（尾部顶点）边完结的顶点（头部顶点）形容两个顶点间关系类型的标签、属性的汇合（键-值对）。

通过关系模型表示，属性图相似上面的语句：

属性图存在上面的特点：

• 顶点之间的相互连贯不存在限度。
• 给定顶点能够疾速的找到边和另一个顶点。

Cypher 查询语言

Cypher 是一种用于属性图的申明式查询语言，最早为 Neo4j 图形数据库而创立，另外 Cypher 这个单词出自黑客帝国的一个比拟重要的角色，这个单词的原意叫做“暗号”。

Cypher 的语法结构如下，蕴含一个顶点和一个边，数据的存储是应用相似 JSON 的 key/value 形式。初看可能感觉奇怪，然而了解概念之后意外的非常好上手。

查问显然是依据出生地和居住地这两条关系线找到地位相干的信息，最终返回用户的名称，比拟合乎人的思考习惯。这里再举一个更简略点的例子，比方查找相干的迁出地的人和迁入地的人：

对于下面的查问写法并不是惟一的，其实能够间接从 Location 开始查找欧洲和美国两个顶点，而后依据关系线找到其余的关系也是一种解法。

Neo4j 还是比拟意思的货色，书中只是简略介绍了一下，更多内容能够找一些简略的我的项目联合官网问你大略能够疾速入门和上手。

当然我不举荐你钻研过深，这种货色在国外利用场景也不多见，看起来壮阔的脑图实际上用起来因人而异，至多 OB 软件集体不太喜爱用。

Neo4j 相干浏览参考：
# Neo4 理解
# 装置 Apoc 插件以及 JAVA 集成

SQL 中的图查问

如果下面的案例中的关系应用关系型数据库实现，尽管实现起来可能很简单然而的确是能够实现，须要大量的关系表配合实现，关系型数据库另一项难题是这样的针对“边”的检索能力非常羸弱，所以不倡议去让关系型数据库去干它不善于的货色。

SQL 在遇到图数据库的冲击之后也开始了对于图查问到钻研，目前较为胜利的案例为 PostgreSql 的图查问（Graph Query）。

小贴士：
留神在 SQL:l999 规范当前，查问过程中这种可变的遍历门路能够应用称为 递归专用表表达式（即 WITH RECURSIVE）来示意。这里截取了一部分，然而显然这个查问简单而且显得臃肿不可了解。

这样的查问也更加阐明对于不同的场景抉择适合的数据模型十分重要，不要试图去让一个不适宜的数据模型强行去做另一个模型的特长，不会显得技术牛逼，只会显得白费力气。

三元存储和 SAPRQL

三元存储的形式简直和 SPARQL 统一。只是不同的名词采纳了雷同的思维，三元模型倒退出了不同的工具和语言，所以这里还算要放到“图”的领域思考。

三元的三元别离叫做：主体、谓语、客体。有一丁点儿相似语言中到主谓宾。

在三元模型汇总主体充当图的顶点，客体分为上面两种：

• 原始数据类型的值。这种状况能够认为谓语以及客体相当于主体的键值对的键和值。
• 图的另一个顶点。相当于主从构造的客体局部相似另一个“顶点”，此时谓语是一条“边”。

也就是说主体必然是一个形象的顶点“对象”，而客体能够是另一个“主体”对象，也能够是一个具体的值。

这样形容仍然比拟形象，上面是举个相干的结构图例子：

为了简化书写缩小雷同单词的输出，能够应用分号对于这样的写法进行改进：

吐槽：图数据的介绍这一段显然有点翻译劫难，有些集体认为翻译不是很失当，倡议间接看 Neo4j 的应用更为直观。

语义网

语义网实质指的是将发给人类浏览的文字依照机器自身能够辨认的形式解读？RDF 框架实现了这样的机制，不同网站的数据合并为一个数据网络，也就是实现数据互联。

然而因为它在过来被过分的夸张，所以导致与此沾边的概念会受到牵连，留神 RDF 是不同的数据模型。

RDF 数据模型

Turtle 语言参考：
https://www.w3.org/TR/turtle/

国内有博主做了翻译，很强：
https://www.cnblogs.com/coodr…

一句话 Turle 语言：Turtle 文档是以紧凑的文本模式来形容一个 RDF 图，这种 RDF 图是由 主语、谓词、宾语 组成的三元组形成的。

通过 Turtle 语言实现代表了 RDF 数据的人类可读格局，目前曾经有不少开源组件反对对于这种数据模型格局的转化，比方应用 RDF/XML 语法。

这门语言次要的目标是不同网站之间的数据河流，有一个非凡约定是对于三元构造存在主体、谓语、客体三局部通常为 URL 的设计，采纳这样的设计是避免雷同数据的抵触无奈辨别的问题，这时候通过 URI 辨别是一种比拟好的形式，哪怕后果雷同也不会影响关系的存在。

从 RDF 角度看 URI 不肯定是须要解析，也有可能是一个 URI 占位符号的存在。

SPARQL 查询语言

定义：采纳 RDF 数据模型的三元存储查询语言。名字是 SPARQL Protocol 和 RDF Query Language 的缩写，发音为“sparkle”。留神这要比 Cypher 还要早，并且后者借用了前者的模式匹配，所以不少中央比拟像。上面是这门语言的相干格局：

模式和 Cypher 根本相似，然而 RDF 的区别是不分属性和边。

图数据库和网络模型的比拟

次要的区别如下：

1. 网络模型须要指定哪一条记录嵌套在其余的标记当中，图数据不存在记录嵌套关系以及记录限度，能够为需要提供更多的灵活性。

2. 图数据库能够通过一个顶点索引不同顶点，而网络模型须要惟一的一个入口找寻关系。

   3. 图数据库顶点和边不肯定是有序的，而网络模型则在插入新记录的时候思考记录在汇合中的地位。
   4. 网络模型中所有查问都是命令式，图数据库应用自制语言，能够灵便的组合顶点和边造成网络。

Datalog 根底

Datalog 要比 SPARQL 以及 Cypher 更为古老，作为查询语言的鼻祖比拟重要。理论案例：

• Datomic 零碎的查询语言
• Cascalog 次要是查问大数据集的 Datalog 实现。

Datalog 的模型相似 SPASQL，其中重要的区别是它并不是应用三元而是 二元构造，只是用谓语（主体、客体）的形式表白和解决。

上面为应用 Datalog 的语法实现上述的查问性能，留神和 SPARQL 以及 Cypher 查询语言不同的，是因为它须要每次实现一块性能。

查问逻辑相似“树分叉匹配”的形式解决，通过“蕴含”关系以及二元构造递归整个二三目录产生所有的匹配后果，最终造成上面的最终后果：

在最初一级也就是第三级当中能够指定 who 来查找具体的人。Datalog 尽管看上去比拟繁琐，然而实际上十分弱小，通过规定拆解关系，能够组合一级来重用各种查问，对于简单数据的解决非常不便。

总结

数据模型是形象并且简单的问题，在本书的第二章重点探讨了不同数据模型的优劣，咱们能够显著的看到最后的数据模型实际上是属于“网状”的。

最后人们的构想是通过层级构造和繁多节点作为入口展现节点，后续则发现这种的繁多构造尽管能够解决一对多，然而碰到多对多会十分复杂，这种想法很快被关系模型取代。

关系型数据库倒退之后，开发人员发现对于多关系构造的组合在传统关系数据库表述并不适合，所以呈现了“NOSQL”，而“NOSQL”自身又划分出两个一致线路：

1. 文档数据库设定数据都是文档，文档通常是 独立 的，和其余文档之间关系不大。
2. 图数据库强调节点之间的 强关联，更加贴合最原始的网状模型，特点是所有数据都能产生分割。

文档数据库和图数据库的独特特点是都不会对于存储的模式加以限度，能够更快的适应需要，而关系型数据库则实用于业务逻辑的场景，在目前看来 Btree 为首的数据结构的关系型数据库还能活很长时间。

此外还有一些数据模型也比拟有意思：

• 基因组数据的钻研人员须要智行序列类似的搜寻，所以存在对于基因组的数据库软件，比方 GenBank。
• 粒子物理学家通过大型对撞机（LHC）的我的项目来实 PB 级别的数据管理，须要一些定制的解决方案防止硬件老本失控。
• 全文搜寻能够说一种警察和数据库一起应用的数据模型。

写在最初

集体认为播种比拟大的是从原始到古代理解了一些数据库的不同分支，有的分支还属于战将来的阶段，而有的分支在逐步沦亡，有的分支集体也素来没听过，当然可能一辈子都没有交加，然而非常感激作者一一解说，然而从集体看来什么样的库能贴合商业化和产品话，谁更有可能活下来，因为数据库还是各种存储媒介，最终只有被用上才有意义和价值。

库是很简单的概念，大部分程序员不要妄想去深钻数据库，很可能产生整个计算机都要重修失去自信心，理解到原理的局部点到为止即可，或者说能用它拧出更好的螺丝都并不是非常容易。